Empfehlungen für Oracle

Als Datenbankadministrator möchten Sie, dass Ihre Datenbank Spitzenleistungen erbringt. Dieses Thema enthält grundlegende Wartungsempfehlungen für Installationen mit Oracle-Datenbanken.

Diese Seite beinhaltet Folgendes:

Allgemeine Empfehlung

Konfigurationsempfehlungen

Regelmäßige Wartung der Oracle-Datenbank

Statistik

Die Zugriffsstatistiken der Datenbanktabellen sollten regelmäßig aktualisiert werden. Dies geschieht bei einem täglichen Aktualisierungsjob (GATHER_STATS_JOB), der im Rahmen der Datenbankinstallation automatisch eingeplant wird, es sei denn, Sie deaktivieren diese Option explizit. Sie können den Zeitpunkt, zu dem die tägliche Aktualisierung erfolgen soll, frei wählen. Vorzugsweise findet sie bei hoher Belastung des AE-Systems statt, sodass Sie repräsentative Werte erhalten. Wenn es keine automatische von Oracle gesteuerte Aktualisierung gibt, können Sie eine Aktualisierung in der Datei Automation Engine festlegen.

Beispiele

SQL-Anweisung, um die Statistiken der Datenbank UC4 (1 Zeile) zu aktualisieren:

exec dbms_stats.gather_schema_stats('UC4',options=>'GATHER AUTO', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

Sie können eine Anweisung auch verwenden, um besser geeignete Statistiken zu erstellen:

exec dbms_stats.gather_schema_stats('UC4',options=>'GATHER AUTO', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO', cascade => TRUE);

Um zu überprüfen, ob und wann die Statistiken zuletzt aktualisiert wurden, verwenden Sie die Ansicht USER_TABLES:

sqlplus>select TABLE_NAME,NUM_ROWS,LAST_ANALYZED from USER_TABLES;

Ausnahme

Es ist nicht sinnvoll, Zugriffsstatistiken für die UC_TEMP *-Tabellen zu erstellen (UC_TEMP, UC_TEMP1, UC_TEMP2, UC_TEMP3). Daher müssen Sie alle Statistiken löschen, die für diese Tabellen verfügbar sein könnten, und die Tabellen sperren, damit neue Statistiken erstellt werden können.

SQL-Anweisungen zur automatischen Erstellung von Statistiken:

exec dbms_stats.delete_table_stats('uc4','UC_TEMP');

exec dbms_stats.lock_table_stats('uc4','UC_TEMP');

exec dbms_stats.delete_table_stats('uc4','UC_TEMP1');

exec dbms_stats.lock_table_stats('uc4','UC_TEMP1');

exec dbms_stats.delete_table_stats('uc4','UC_TEMP2');

exec dbms_stats.lock_table_stats('uc4','UC_TEMP2');

exec dbms_stats.delete_table_stats('uc4','UC_TEMP3'); e

exec dbms_stats.lock_table_stats('uc4','UC_TEMP3');

Fragmentierung

Es kann vorkommen, dass die Anzahl der Einträge in den AE-Meldungsqueues (MQ*-Tabellen) aufgrund einer Fehlfunktion stark zugenommen hat (mehrere 10000 Einträge), und diese Tabellen können stark fragmentiert sein. Dies kann die Performance des AE-Systems negativ beeinflussen, da diese Tabellen am häufigsten verwendet werden. Um das Fragmentierungsproblem zu lösen, gibt es zwei Möglichkeiten, offline und online.

Liste der MQ-Tabellen

MQ-Tabellen sind Tabellen mit "MQ" als Tabellennamenspräfix. Je nach AE-Systemeinrichtung sind unterschiedlich viele MQ-Tabellen vorhanden , insbesondere kann die Anzahl der "MQnCP*"-Tabellen variieren.

Beispiel: Die folgende SQL-Anweisung ruft eine Liste von MQ-Tabellen ab.

select TABLE_NAME from user_tables where TABLE_NAME like 'MQ%';

Offline-Reorganisation aller MQ-Tabellen

Dies erfordert eine Downtime des AE-Systems. Weitere Informationen zum Herunterfahren des AE-Systems finden Sie unter Starten und Beenden von Serverprozessen.

Starten Sie das AE-System mit einem Kaltstart (setzen Sie StartMode=COLD in der INI-Datei (ucsrv.ini) der Automation Engine, siehe Automation Engine), oder über das Kontextmenü im Dialogfeld des Service Managers).

Der Kaltstart des Systems bereinigt die AE-Meldungsqueues, was im Wesentlichen bedeutet, dass sie abgeschnitten werden. Falls die Kürzung manuell durchgeführt werden muss, können Sie die folgenden SQL-Anweisungen verwenden, während das AE-System ausgeschaltet ist.

Wichtig! Erstellen Sie ein Backup, bevor Sie mit der Änderung der Datenbank beginnen.

SET SERVEROUTPUT ON

BEGIN

FOR c IN (SELECT TABLE_NAME FROM user_tables WHERE TABLE_NAME LIKE 'MQ%')

LOOP

dbms_output.put_line (c.TABLE_NAME || ' Tabelle wird jetzt abgeschnitten ...');

EXECUTE immediate 'truncate table ' || c.TABLE_NAME ;

dbms_output.put_line (c.TABLE_NAME || ' Table was truncated.');

END LOOP;

ENDE;

Online-Reorganisation

Das AE-System bleibt in diesem Fall online.

Es wird empfohlen, dass ein DBA die Online-Reorganisation der Tabellen durchführt, um sicherzustellen, dass die Datenbank (MQ*-Tabellen) während der Reorganisation für die AE verfügbar bleibt. Auf diese Weise können Sperrsituationen vermieden oder sofort erkannt und behoben werden.

Ein Best Practice-Beispiel für ein Verfahren, das eine solche Reorganisation durchführt, wird mit dem DB-Schema ausgeliefert (UC_REORG im Ordner Procedure in Ihrer Oracle-Datenbank).

Wenn die Anzahl, die Sie erhalten, 1000 beträgt, ist diese Tabelle ein Kandidat für eine Reorganisation. Führen Sie nun das folgende Verfahren durch:

call uc_reorg('MQ1CP001',3);

Der zweite Parameter, v_method, muss eine Zahl sein und kann einen der folgenden Werte haben:

Wichtig!

Fragmentierung von MQ-Tabellen überprüfen

Die folgende Anweisung erzeugt Prüfanweisungen für jede MQ-Tabelle. Beachten Sie, dass Sie es als Schemabesitzer ausführen müssen:

select 'select get_block_count(''' || table_name || ''') from dual;' ResultToExecute from user_tables where table_name like 'MQ%';

Sie können das Ergebnis nutzen, um die aktuelle Fragmentierung zu sehen. Abhängig von Ihrer Umgebung kann eine Blockanzahl über 64 als Kandidat für einen Reorganisationsprozess angesehen werden. Ab 64 können Sie eine Reorganisation durchführen und die Fragmentierung in Normal- und Spitzenlastsituationen überwachen. Wenn die Anzahl steigt, können Sie sie als Grundlage für Ihr System verwenden.

Beispiel

Ergebnisabfrage:

select get_block_count('MQ1CP001') from dual;

Datenbankparameter einstellen

Trefferrate des Buffer-Cache

Grundsätzlich sollte die Trefferrate des Buffer-Cache mehr als 98 % betragen. Das folgende Script ist ein Beispiel für die Berechnung des aktuellen Werts.

Berechnung der Trefferrate des Buffer-Cache:

-- DB_BLOCK_BUFFERS: 'Buffer-Cache-Trefferrate %' sollte > 98 % sein execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line('>>>>>> DB_BLOCK_BUFFERS: "Buffer-Cache-Trefferrate %" sollte > 98 % sein');

execute dbms_output.put_line(chr(9)); declare dbg number;

cg number;

pr number;

 

begin

select value into dbg from v$sysstat

where name = 'db block gets'; select value into cg

from v$sysstat

where name = 'consistent gets'; select value into pr

from v$sysstat

where name = 'physical reads'; dbms_output.put_line('db block gets

|'||to_char(dbg,'999G999G999G999')); dbms_output.put_line('consistent gets

|'||to_char(cg,'999G999G999G999')); dbms_output.put_line('physical reads

|'||to_char(pr,'999G999G999G999'));

dbms_output.put_line('---------------------------------------- ');

dbms_output.put_line('Buffer-Cache-Trefferrate in % |'|| to_char (round(100*(1-(pr/(dbg+cg))),2),'999D00')); end;

/

Memory-Trefferrate

Grundsätzlich sollte die Memory-Trefferrate des Sortierbereichs größer als 99 % sein. Das folgende Script ist ein Beispiel für die Berechnung des aktuellen Werts.

-- SORT_AREA_SIZE: Memory-Trefferrate % sollte > 99 % sein

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line('>>>>>> SORT_AREA_SIZE: "Memory-Trefferrate %" sollte > 99 % sein');

execute dbms_output.put_line(chr(9));

declare sm number;

sd number;

begin

select value into sm

from v$sysstat

where  name = 'sorts (memory)';

 

select value into sd

from v$sysstat

where name = 'sorts (disk)';

dbms_output.put_line('sorts (memory)

|'||to_char(sm,'999G999G999'));

dbms_output.put_line('sorts (disk)

|'||to_char(sd,'999G999G999'));

 

dbms_output.put_line('-------------------------------');

 

dbms_output.put_line('memory hit Rate %

|'|| to_char (round(100-(100*sd/sm),2),'999D00'));

end;

/

Größe des gemeinsamen Pools

Von der Gesamtzahl aller Zugriffe sollte der Prozentsatz der erfolglosen Zugriffe auf den Bibliotheks-Cache innerhalb des gemeinsamen Pools in der Regel deutlich unter 1 % liegen. Das folgende Script ist ein Beispiel für die Berechnung des aktuellen Werts.

-- SHARED_POOL_SIZE: 'Misses %' sollte << 1% sein

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line('>>>>>> SHARED_POOL_SIZE:

"Erfolglose Zugriffe %" sollte << 1% sein');

 

column 'misses %' format a10

select sum(pins) "Executions",

sum(reloads) "Cache-Fehler bei der Ausführung",

to_char(sum(reloads)/(sum(pins)+sum(reloads))*100,'990D0000')

"Fehler %"

from v$librarycache

Memory Advisor

Sie können dazu auch den Memory Advisor verwenden. PGA_AGREGATE_TARGET sollte verwendet werden.

Siehe auch: