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.

Dieses Thema beinhaltet Folgendes:

Allgemeine Empfehlungen

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, so dass 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-Statement, 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 ein Statement 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 (UC_TEMP, UC_TEMP1, UC_TEMP2, UC_TEMP3) zu erstellen. 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-Statements 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-Nachrichtenqueues (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: Das folgende SQL-Statement 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. Fahren Sie das AE-System herunter, wie unter Starten und Beenden von Serverprozessen beschrieben.

Starten Sie das AE-System mit einem Kaltstart (setzen Sie StartMode=COLD in der Datei ucsrv.ini oder über das Kontextmenü im Service Manager-Dialog).

Der Kaltstart des Systems bereinigt die AE-Nachrichtenqueues, was im Wesentlichen bedeutet, dass sie abgeschnitten werden. Falls die Trunkierung manuell durchgeführt werden muss, können Sie die folgenden SQL-Statements 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 || ' Table will be truncated now ...');

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

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

END LOOP;

END;

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 einen Ablauf, der eine solche Reorganisation durchführt, wird mit dem DB-Schema ausgeliefert (UC_REORG im Ordner „Ablauf“ in Ihrer Oracle-Datenbank).

Fragmentierung von MQ-Tabellen überprüfen

Das folgende Statement erzeugt Prüfstatements 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 nehmen und ausführen, 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;

Wenn die Anzahl, die Sie erhalten, 1000 beträgt, ist diese Tabelle ein Kandidat für eine Reorganisation. Führen Sie nun die Schritte folgenden Ablaufs aus:

call uc_reorg('MQ1CP001');

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 Wertes.

Berechnung der Trefferrate des Buffer-Cache:

-- DB_BLOCK_BUFFERS: 'buffer cache hit rate %' should be > 98% execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line('>>>>>> DB_BLOCK_BUFFERS: "buffer cache hit rate %" should be > 98%');

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 hit rate 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 Wertes.

-- SORT_AREA_SIZE: memory hit rate % should be > 99%

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line('>>>>>> SORT_AREA_SIZE: "memory hit rate %" should be > 99%');

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 Wertes.

-- SHARED_POOL_SIZE: 'Misses %' should be << 1%

execute dbms_output.put_line(chr(9));

execute dbms_output.put_line(chr(9));

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

"Misses %" should be << 1%');

 

column 'misses %' format a10

select sum(pins) "Executions",

sum(reloads) "Cache Misses while Executing",

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

"Misses %"

from v$librarycache

Memory Advisor

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

Siehe auch: