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.

Allgemeine Empfehlungen

• Reorganisieren Sie die Automation Engine-Datenbank (einschließlich aller Mandanten) regelmäßig neu.

• Gigabit-Netzwerkverbindung zwischen den Instanzen der Automation Engine und der Datenbank mit möglichst wenigen aktiven Komponenten im Pfad.

• Wenn die Datendateien der Datenbank extern gespeichert werden, müssen Sie die Geschwindigkeit des externen Festplatten-Subsystems sowie dessen leistungsstarke Verbindung (z.B. Fibre Channel) berücksichtigen.

• Es wird empfohlen, für alle Clusterknoten die gleiche Hardware zu verwenden.

• Informationen zu Installationsvoraussetzungen finden Sie unter Automic Automation Systemanforderungen und Dimensionierung.

Konfigurationsempfehlungen

• Begrenzen Sie den Ressourcenverbrauch nicht. Transaktionen, die wegen Einschränkungen in der Datenbankeinstellung immer wieder abbrechen, können die Verarbeitung im Automation Engine-System behindern. Des Weiteren können inkonsistente Datenbankinhalte entstehen, die Folgefehler oder Endlosschleifen auslösen.

• Setzen Sie in der Variablen UC_HOSTCHAR_DEFAULT den Parameter REPORT_BLKSIZE= auf 8000, siehe UC_HOSTCHAR_DEFAULT - Host-Charakteristika

• Legen Sie in der Variablen UC_SYSTEM_SETTINGS Folgendes fest:

  • REPORT_BLKSIZE=8000

  • LAST_USE=0

    Dieser Parameter wirkt sich insbesondere auf die Performance in der RAC/Data Guard-Umgebung aus, kann aber auch zu einer Verbesserung der Performance von eigenständigen Datenbanken führen.

    Weitere Informationen finden Sie unter UC_SYSTEM_SETTINGS - Systemübergreifende Einstellungen.

• Optimieren Sie die TCP/IP-Verbindung. Setzen Sie in der Datei SQLNET.ORA tcp.nodelay = yes (gültig für Datenbankserver und Mandant).
  Wenn eine Nachricht länger ist als ein logischer Transportblock, muss sie in mehrere Blöcke aufgeteilt werden. Die obige Einstellung hat den Effekt, dass dies geschehen kann, ohne auf eine TCP/IP-Antwort zu warten. Auf diese Weise kann die Performance von Oracle gesteigert werden.

• Aktivieren Sie die Erkennung von toten Verbindungen (Dead Connection Detection), da Oracle diese Einstellung benötigt, um zuverlässig zu erkennen, dass Automation Engine abgestürzt ist. Setzen Sie in der Datei SQLNET.ORA SQLNET.EXPIRE_TIME auf maximal 1 Minute (gültig für den Datenbankserver). Dies ist das Intervall, in dem der Datenbankserver prüft, ob bestehende Mandantensessions noch aktiv sind. Der Datenbankserver schließt nicht antwortende Sessions.

• Setzen Sie den Betriebssystemparameter tcp_keepalive < = 5 Minuten (gültig für den Datenbank-Client).
  Dieser Parameter ist notwendig, um sicherzustellen, dass ein Verbindungsabbruch auf der Seite des Datenbank-Clients erkannt werden kann, wenn der Datenbankserver nicht mehr in der Lage ist, eine Datenbanksession zu beenden, entweder kontrolliert oder mit Hilfe der Dead Connection Detection. Bestehende TCP-Verbindungen werden im vorgegebenen Intervall überprüft und wenn der Verbindungspartner nicht antwortet, wird die Verbindung automatisch beendet. Die zugehörige Datenbanksession wird beendet und der Oracle-Mandant kann einen Fehlerreport an die AE senden, damit eine neue Verbindung aufgebaut werden kann.

• Setzen Sie in der Datei TSNAMES.ORA enable = broken (gültig für den Datenbank-Client).
  Dieser Parameter muss der erste des vollständigen Eintrags in tnsnames sein, wie unten gezeigt:

  UC4P =

  (DESCRIPTION =

  (ENABLE=BROKEN)

  (ADDRESS = (PROTOCOL = TCP)(HOST = dbhost)(PORT = 1521))

  (CONNECT_DATA =

  (SERVER = DEDICATED) (SERVICE_NAME = UC4P)

  )

  )

• Beim Einrichten der Datenbank müssen die Tabellen die entsprechenden Größen haben. Die folgende Tabelle bietet eine Übersicht über die empfohlenen Größen in Prozent. Die Datenbank in einer produktiven Umgebung sollte eine Größe von 2-4 GB haben. Bei sehr komplexen Installationen kann die Datenbankgröße 10 bis 20 mal so groß sein. Erweitern Sie die Tabellen automatisch um eine fixe Größe und stellen Sie kein Limit für die Erweiterungen ein.

  • RT: 40 % - 60 %

  • AH: 20 % - 30 %

  • MELD: 10 % - 20 %

  • AJPP: 5 %

  • RH: 5 %

  • Sonstige Tabellen: < 1 %

• Achten Sie darauf, dass die Indizes regelmäßig reorganisiert werden.

Regelmäßige Wartung der Oracle-Datenbank

• Erstellen Sie Tablespaces für die Automation Engine mit ASSM (Automatic Segment Space Management).

  Neben mehreren Performance-Vorteilen beim Einfügen von Daten ermöglicht ASSM auch eine transparente Reorganisation von Tabellen.

• Verwendung von lokalen Festplatten

  Wenn die Datenbank nicht auf einem externen Festplatten-Subsystem installiert ist, sollten die Datendateien sowohl des Index als auch der Daten-Tablespaces (UC4_INDEX, UC4_DATA) auf physisch getrennten Laufwerken gespeichert werden, um einen maximalen I/O-Durchsatz zu erreichen.

  Um die I/O weiter zu verbessern, sollten die Tabellen E*, A*, R* und MELD sowie die temporären AE-Tabellen (UC_TEMP*, MQ*) in eigenen Tablespaces oder Datendateien auf physisch getrennten Festplatten abgelegt werden. Zu diesem Zweck müssen Sie zusätzliche Daten-Tablespaces (z. B. UC4_DATA_E, UC4_DATA_A, UC4_DATA_R, UC4_DATA_M, UC4_DATA_T) erstellen. Die endgültige Verteilung der Datendateien hängt jedoch immer von Ihren Anforderungen und der verfügbaren Infrastruktur ab.

• Reorganisation mit Datenbankmitteln

  Sie sollten hier den Oracle SEGMENT ADVISOR verwenden. Er erzeugt eine Liste aller Tabellen/Indizes, die reorganisiert werden müssen. Sie können dies auch manuell nachholen, aber dies beinhaltet umfangreiche Änderungen in der AE-Datenbank.

  Beispiel

  Reorganisation des Online-Index:

  sqlplus> alter index <index_name> rebuild online;

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 UC4-Datenbank (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 der Blöcke, die Sie abrufen, hoch ist (über dem normalen Wert für diese Umgebung, z. B. über 128 Blöcke für die MQ*-Tabelle), ist diese Tabelle ein Kandidat für eine Reorganisation. Führen Sie nun das folgende Verfahren durch:

call uc_reorg('<Tabellenname>', <Modus>, <DetaillierteAusgabe>);

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

• 1: STANDARD (Standard)

  Verhalten bleibt unverändert (Verkleinern des Speicherplatzes wird verwendet)

• 2: MOVE ONLINE (optional)

  Die Tabelle wird mit ALTER TABLE MOVE ONLINE neu organisiert

• 3: DBMS_REDEF (optional)

  Die Tabelle wird mit dem DBMS_REDEF. REDEF_TABLE-Prozess neu organisiert

  Zulässige Werte: TRUE oder FALSE

  Wenn der Wert auf TRUE gesetzt ist, stellen Sie sicher, dass DBMS.OUTPUTfür die Session aktiviert ist, um ausführlichere Informationen zu erhalten

Wichtig!

• Die Werte 2 und 3 reorganisieren BASICFILE und SECUREFILE LOBs und funktionieren mit den Versionen 12c und höher.

• Um den Wert 3 zu verwenden, benötigt der UC4-Anwender die folgenden Berechtigungen, andernfalls funktionieren DBMS_REDEF-Aufrufe nicht:

  grant execute on sys.dbms_redefinition to <uc4-user>;
  grant redefine any table to <uc4-user>;
  grant create table to <uc4-user>;

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;

-- RESTULT: 200

-- Stellen Sie sicher, dass DBMS.OUTPUT in der Session aktiviert ist, da Parameter 3 auf true gesetzt ist, – um die Reorganisation der Tabelle mit ONLINE MOVE durchzuführen:

call uc_reorg('MQ1CP001', 2, TRUE);

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 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 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: "Misses %" sollte << 1% sein');

 

column 'misses %' format a10;

select sum(pins) "Ausführungen", sum(reloads) "Cache-Misses bei der Ausführung", zo_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:

• Die AE-Datenbank vorbereiten - Oracle
• Oracle-Parameter
• Automation Engine Datenbank
• Die AE- und Analytics-Datenbanken für die Container-Installation vorbereiten