Fassen Sie die Speicherzuweisung und Abstimmung des Oracle-Lernens zusammen und organisieren Sie sie

Dieser Artikel vermittelt Ihnen relevantes Wissen über „Oracle“, in dem hauptsächlich Probleme im Zusammenhang mit der Speicherzuweisung und -optimierung vorgestellt werden. Der Speicher von Oracle kann aus der Sicht von Shared und Private in einen globalen Systembereich unterteilt werden. Schauen wir sie uns gemeinsam an. Ich hoffe, dass es für alle hilfreich ist.

Empfohlenes Tutorial: „

Oracle Learning Tutorial

“

1. Übersicht

Der Speicher von Oracle kann aus der Sicht von Shared und Private, also SGA, in einen systemglobalen Bereich und einen prozessglobalen Bereich unterteilt werden und PGA (Process Global Area oder Private Global Area). Für den Speicher im SGA-Bereich muss er global gemeinsam genutzt werden. Unter UNIX muss ein gemeinsames Speichersegment (eins oder mehrere) für Oracle festgelegt werden, da Oracle unter UNIX ein Multiprozess ist, während Oracle unter WINDOWS Single ist Prozess (mehrere Threads), daher besteht keine Notwendigkeit, gemeinsam genutzte Speichersegmente einzurichten. PGA ist ein privater Prozessbereich (Thread). Wenn Oracle den Shared Server-Modus (MTS) verwendet, wird ein Teil des PGA, also UGA, im gemeinsam genutzten Speicher „large_pool_size“ abgelegt.

Veröffentlichen Sie ein Bild der Zusammensetzung der Oracle-Speicherarchitektur. Gemäß der obigen Anzeige können Sie die wichtigsten Parameter und Parameternamen auf einen Blick sehen:

Für den SGA-Teil können wir sehen es durch SQLplus-Abfrage:

SQL> select * from v$sga; 
  
NAME                VALUE 
  
----------             --------------------
  
Fixed Size                   454032 
  
Variable Size             109051904 
  
Database Buffers             385875968 
  
Redo Buffers                667648

Feste Größe:

Oracle kann auf verschiedenen Plattformen und Versionen unterschiedlich sein, es handelt sich jedoch um einen festen Wert für eine bestimmte Umgebung. Es speichert Informationen zu jeder Komponente von SGA und kann als Bereich zur Steuerung der Einrichtung von SGA betrachtet werden.

Variable Größe:

Enthält shared_pool_size, java_pool_size, large_pool_size und andere Speichereinstellungen

Datenbankpuffer:

bezieht sich auf den Datenpuffer:

In 8i umfasst es drei Teile des Speichers: db_block_buffer*db_block_size, buffer_pool_keep und buffer_pool_recycle.​ ​

In 9i umfasst es db_cache_size, db_keep_cache_size, db_recycle_cache_size, db_nk_cache_size.

Redo-Puffer:

bezieht sich auf den Protokollpuffer log_buffer. Ein weiterer zu beachtender Punkt ist, dass die Abfragewerte für v$parameter, v$sgastat und v$sga unterschiedlich sein können. Der Wert in v$parameter bezieht sich auf das anfängliche

des Benutzers

Der in der Initialisierungsparameterdatei v$sgastat festgelegte Wert ist die tatsächlich von Oracle zugewiesene Protokollpuffergröße (da der Zuweisungswert des Puffers tatsächlich diskret ist und nicht im Block als kleinste Einheit zugewiesen wird),

Der in v$sga abgefragte Wert ist, dass nach der Zuweisung des Protokollpuffers durch Oracle zum Schutz des Protokollpuffers einige Schutzseiten eingerichtet werden. Normalerweise werden wir feststellen, dass die Größe der Schutzseite etwa 11 KB beträgt kann in verschiedenen Umgebungen unterschiedlich sein).​ ​

​

2. SGA-interne Parameter und Einstellungen: ​ ​ ​ ​

​ 2.1 Log_buffer

​

Ich glaube normalerweise nicht, dass es zu viele Vorschläge zum Festlegen der Größe des Protokollpuffers gibt, denn nachdem wir uns die von LGWR geschriebenen Triggerbedingungen angesehen haben, werden wir feststellen, dass eine Überschreitung von 3 MB normalerweise nicht sehr aussagekräftig ist. Als formales System,

Sie können diesen Teil zunächst auf die Größe log_buffer=3-5M einstellen und ihn dann entsprechend der spezifischen Situation anpassen.

log_buffer ist der Puffer des Redo-Logs.

Hier müssen Sie also das Triggerereignis (LGWR) des Redo-Logs verstehen

1 Wenn die Kapazität des Redo-Log-Puffers 1/3 erreicht

2 erreicht, im Allgemeinen sind es 3 Sekunden.

3. Die Redo-Log-Kapazität im Redo-Log-Puffer erreicht 1M

4. Bevor DBWn die Daten in den Puffer schreibt

5.

Die obige Schlussfolgerung lässt sich mit anderen Worten sagen:

1 Wenn der Inhalt in log_buffer 1/3 voll ist, wird der Cache einmal aktualisiert.

2. Das maximale Intervall beträgt 3 Sekunden, der Cache wird einmal aktualisiert

3 Die Daten in log_buffer erreichen 1M, der Cache wird einmal aktualisiert.

4. Bei jeder Übermittlung einer „Transaktion“ wird der Cache aktualisiert

2.2 Large_pool_size

Für die Einstellung eines großen Pufferpools wird empfohlen, dass MTS nicht verwendet wird 20-30 Millionen reichen aus. Dieser Teil wird hauptsächlich zum Speichern einiger Informationen während paralleler Abfragen verwendet und kann von RMAN während der Sicherung verwendet werden.

Wenn MTS eingerichtet ist, muss die Größe dieses Teils umfassend berücksichtigt werden, da der UGA-Teil hierher verschoben wird, basierend auf der Anzahl der Serverprozesse und den Einstellungen der zugehörigen Sitzungsspeicherparameter.

2.3 Java_pool_size

Wenn die Datenbank kein JAVA verwendet, denken wir normalerweise, dass die Beibehaltung von 10-20 Millionen ausreicht. Tatsächlich kann es weniger sein, sogar mindestens 32 KB, aber es hängt von den Komponenten bei der Installation der Datenbank ab (z. B. http-Server).

2.4 Shared_pool_size

Der Overhead für Shared_pool_size sollte normalerweise innerhalb von 300 MB gehalten werden. Es sei denn, das System verwendet eine große Anzahl gespeicherter Prozeduren, Funktionen und Pakete,

Anwendungen wie Oracle ERP können 500 Millionen oder sogar mehr erreichen. Wir gehen also von einem System mit 1G Speicher aus, das wir vielleicht in Betracht ziehen

Stellen Sie diesen Parameter auf 100 MB ein. Erwägen Sie bei 2G-Systemen die Einstellung auf 150 MB.

2.5SGA_MAX_SIZE Pools, und die meisten von ihnen können ihre Größe über bestimmte Parameter angeben. Da es sich jedoch um eine teure Ressource handelt, ist die physische Speichergröße eines Systems begrenzt.

Obwohl die tatsächliche Größe des physischen Speichers nicht unbedingt mit der Adressierung des CPU-Speichers in Zusammenhang stehen muss (dies wird später im Detail vorgestellt), führt eine übermäßige Nutzung des virtuellen Speichers zum Ein-/Ausblättern von Seiten,

beeinträchtigt die Leistung des Systems erheblich und kann sogar zum Absturz des Systems führen. Daher ist ein Parameter erforderlich, um die maximale Größe des von SGA verwendeten virtuellen Speichers zu steuern. Dieser Parameter ist SGA_MAX_SIZE. Wenn die Instanz gestartet wird,

Jeder Speicherbereich weist nur die von der Instanz benötigte Mindestgröße zu. Bei nachfolgenden Vorgängen werden ihre Größen nach Bedarf erweitert und ihre Gesamtgröße ist durch SGA_MAX_SIZE begrenzt.

Informationen zum OLTP-System finden Sie unter:

.

Systemspeicher	SGA_MAX_SIZ E-Wert
1G	400-500M
2G	1G
4G	2500M
8G	5G

2.6 PRE_PAGE_SGA

Wenn die Oracle-Instanz startet, wird nur die kleinste Größe jedes Speicherbereichs geladen. Und anderer SGA-Speicher wird nur als virtueller Speicher zugewiesen,

Erst wenn der Prozess die entsprechende Seite berührt, wird sie im physischen Speicher ersetzt. Aber wir können hoffen, dass, sobald die Instanz gestartet ist, alle SGA

sind alle dem physischen Gedächtnis zugeordnet. Zu diesem Zeitpunkt kann der Zweck durch Festlegen des Parameters PRE_PAGE_SGA erreicht werden. Der Standardwert dieses Parameters

ist FALSE, was bedeutet, dass nicht alle SGA im physischen Speicher abgelegt werden. Wenn es auf TRUE gesetzt ist, werden beim Instanzstart alle SGA in die physische verschoben

In Erinnerung. Dadurch kann die Instanz ihren maximalen Leistungszustand erreichen, die Startzeit wird jedoch auch länger sein (da um alle SGA

werden im physischen Speicher abgelegt und der Oracle-Prozess muss alle SGA-Seiten berühren. 2.7 LOCK_SGA

Der Standardwert dieses Parameters ist FALSE. Wenn er als TRUE angegeben ist, können alle SGA im physischen Speicher gesperrt werden. Natürlich,

Einige Systeme unterstützen keine Speichersperre, daher ist dieser Parameter ungültig.

2.8 SGA_TARGET

Was ich hier vorstellen möchte, ist ein sehr wichtiger Parameter, der in Oracle10g eingeführt wurde. Vor 10g verschiedene Speicherbereiche von SGA Die Größen von

müssen über ihre jeweiligen Parameter angegeben werden und dürfen den Wert der durch die Parameter angegebenen Größe nicht überschreiten, obwohl ihre Summe möglicherweise nicht ist

Die maximale SGA-Grenze wurde nicht erreicht. Darüber hinaus kann der Speicher in jedem Bereich nach seiner Zuweisung nur von diesem Bereich verwendet werden und kann nicht gemeinsam genutzt werden.

Nehmen Sie die beiden wichtigsten Speicherbereiche in SGA, Buffer Cache und Shared Pool. Sie haben den größten Einfluss auf die Leistung der Instanz

Aber es gibt einen solchen Widerspruch: Wenn die Speicherressourcen begrenzt sind, ist der Bedarf an zwischengespeicherten Daten manchmal sehr groß,

Um den Buffer Hit zu erhöhen, ist es notwendig, den Buffer Cache zu vergrößern, dieser kann jedoch aufgrund des begrenzten SGA nur aus anderen Bereichen „geraubt“ werden – etwa durch die Reduzierung des Shared Pools,

Puffer-Cache erhöhen; manchmal werden große Teile des PLSQL-Codes analysiert und im Speicher gespeichert, was zu einem unzureichenden Shared Pool führt,

Sogar ein 4031-Fehler tritt auf und der Shared Pool muss erweitert werden. Zu diesem Zeitpunkt ist möglicherweise ein menschliches Eingreifen erforderlich, um den Speicher aus dem Puffercache wiederherzustellen.

Mit dieser neuen Funktion lässt sich dieser Speicherkonflikt in SGA leicht lösen. Diese Funktion wird als automatische Shared-Memory-Verwaltung bezeichnet

(Automatische Shared-Memory-Verwaltung ASMM). Der einzige Parameter, der diese Funktion steuert, ist SGA_TARGE.

Nach dem Festlegen dieses Parameters müssen Sie nicht mehr die Größe für jeden Speicherbereich angeben. SGA_TARGET gibt die maximale Speichergröße an, die SGA verwenden kann,

Die Größe jedes Speichers in SGA wird von Oracle selbst gesteuert und muss nicht manuell angegeben werden. Oracle kann die Größe jedes Bereichs jederzeit anpassen, um ein System zu erreichen

Die angemessenste Größe für eine optimale Systemleistung und deren Summe so steuern, dass sie innerhalb des durch SGA_TARGET angegebenen Werts liegt. Sobald Sie einen Wert für SGA_TARGET

angeben

(Der Standardwert ist 0, d. h. ASMM ist nicht aktiviert), die ASMM-Funktion wird automatisch aktiviert.

三、oracle 内存调优办法   

当项目的生产环境出现性能问题，我们如何通过判断那些参数需要调整呢？   

3.1 检查ORACLE实例的Library Cache命中率:   

 标准:一般是大于99％                   检查方式:

select 1-(sum(reloads)/sum(pins)) "Library cache Hit Ratio" from v$librarycache;

 处理措施:    如果Library cache Hit Ratio的值低于99%，应调高shared_pool_size的大小。通过sqlplus连接数据库执行如下命令，调整shared_pool_size的大小：    

SQL>alter system flush shared_pool;
    
SQL>alter system set shared_pool_size=设定值 scope=spfile;

3.2 检查ORACLE实例的Data Buffer（数据缓冲区）命中率:   

 标准:一般是大于90%     检查方式:    

select 1 - (phy.value / (cur.value + con.value)) "HIT RATIO"
    from v$sysstat cur, v$sysstat con, v$sysstat phy
   
 where cur.name = 'db block gets'
    and con.name = 'consistent gets'
     and phy.name = 'physical reads';

处理措施:    

如果HIT RATIO的值低于90%，应调高db_cache_size的大小。通过sqlplus连接数据库执行如下命令，    

调整db_cache_size的大小    

SQL>alter system set db_cache_size=设定值 scope=spfile

3.3 检查ORACLE实例的Dictionary Cache命中率:     

标准:一般是大于95%       

检查方式:       

select 1 - (sum(getmisses) / sum(gets)) "Data Dictionary Hit Ratio"       
  from v$rowcache;

处理措施:       

如果Data Dictionary Hit Ratio的值低于95%，应调高shared_pool_size的大小。通过sqlplus连接数据库执行如下命令，调整shared_pool_size的大小：       

SQL>alter system flush shared_pool;       
SQL>alter system set shared_pool_size=设定值 scope=spfile;

3.4  检查ORACLE实例的Log Buffer命中率:     

标准:一般是小于1%       

检查方式:      

select (req.value * 5000) / entries.value "Ratio"       
  from v$sysstat req, v$sysstat entries       
 where req.name = 'redo log space requests'       
   and entries.name = 'redo entries';

处理措施:       

如果Ratio高于1％，应调高log_buffer的大小。通过sqlplus连接数据库执行如下命令，调整log_buffer的大小：       

SQL>alter system set log_buffer=设定值 scope=spfile;

3.5 检查undo_retention:     

标准:undo_retention 的值必须大于max(maxquerylen)的值       

检查方式:       

col undo_retention format a30
      
select value "undo_retention" from v$parameter where name='undo_retention';
      
select max(maxquerylen) From v$undostat Where begin_time>sysdate-(1/4);

处理措施:       

如果不满足要求，需要调高undo_retention 的值。通过sqlplus 连接数据库执行如下命令，调整undo_retention 的大小：       

SQL>alter system set undo_retention= 设定值 scope=spfile;

注：    

32bit  和 64bit  的问题    

对于 oracle 来说，存在着 32bit 与 64bit 的问题。这个问题影响到的主要是 SGA 的大小。在 32bit 的数据库下，通常 oracle 只能使用不超过 1.7G 的内存，即使我们拥有 12G 的内存，但是我们却只能使用 1.7G，这是一个莫大的遗憾。假如我们安装 64bit 的数据库,我们就可以使用很大的内存，我们几乎不可能达到上限。但是 64bit 的数据库必须安装在 64bit 的操作系统上，可惜目前 windows 上只能安装 32bit 的数据库，我们通过下面的方式可以查看数据库是 32bit 还是 64bit     

Aber unter einem bestimmten Betriebssystem können bestimmte Mittel bereitgestellt werden, die es uns ermöglichen, mehr als 1,7 GB Speicher zu nutzen und so mehr als 2 GB oder sogar mehr zu erreichen.

Empfohlenes Tutorial: „Oracle Tutorial“

Das obige ist der detaillierte Inhalt vonFassen Sie die Speicherzuweisung und Abstimmung des Oracle-Lernens zusammen und organisieren Sie sie. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!