Wenn man im SAP System feststellt, dass die Commit Performance unter steigender Last immer schlechter wird muss das nicht zwangsläufig etwas mit falscher Parametrisierung der Oracle Datenbank zu tun haben. SAP gibt in den EWA (Early Watch Alert) Berichten eine Indikation für Performanceprobleme mit an. So sind durchschnittliche Zeiten von <=15ms noch OK. Was aber tun wenn hier 20 oder mehr ms angegeben werden. Gerade in einem stark ausgelasteten ERP System kann sich dieser Umstand recht schnell negativ auf die Performance auswirken und zieht sich somit durch das komplette System.
Um zu sehen wie es um die Waits steht gibt es im Oracle und SAP mehrere Wege nach Rom. Ich nutze oft den AWR Workloard Report über die TX DB02:
Alternativ kann man auch direkt im Oracle schauen:
set pages 200 lines 200 select WAIT_CLASS, TOTAL_WAITS, round(100 * (TIME_WAITED / SUM_TIME),2) PCT_TIME from (select WAIT_CLASS, TOTAL_WAITS, TIME_WAITED from V$SYSTEM_WAIT_CLASS where WAIT_CLASS != 'Idle'), (select sum(TOTAL_WAITS) SUM_WAITS, sum(TIME_WAITED) SUM_TIME from V$SYSTEM_WAIT_CLASS where WAIT_CLASS != 'Idle') order by 3 desc;
WAIT_CLASS TOTAL_WAITS PCT_TIME ---------------------------------------------------------------- ----------- ---------- System I/O 246768191 33.53 User I/O 84937746 29.43 Commit 26410809 23.67 Administrative 18449134 10.89 Application 2826515 1.11 Network 1587402009 .96 Other 1035082 .3 Concurrency 875457 .08 Configuration 8637 .01 9 rows selected.
In dem Screenshot sieht man, dass die Commit Zeiten in dem untersuchten System fast 1/3 der kompletten DB Zeit stellen und mit 33ms mehr als doppelt so hoch liegen wie die von der SAP als bedenkliche Indikation festgelegten 15ms. Es besteht also Handlungsbedarf. Sofern die Oracle Parameter geprüft sind und auch die Konfiguration der Redologgruppen und Member (Anzahl, Größe) zutreffend sind muss man etwas tiefer ins System einsteigen.
1) Performance Filesysteme
Hier sollte sichergestellt sein, dass die Anbindung an den Storage kein Engpass ist. Die Filesysteme von origlog*/mirlog* sollten jeweils auf einzelnen Platten liegen um bestmöglichen I/O und kurze Latenzen zu ermöglichen
2) Das Filesystemlayout
Oftmals vergessen und total unterschätzt ist das Layout des Filesystems – also dessen Alignment. Ist hier etwas nicht korrekt eingerichtet kann die verwendete Hardware noch so schnell sein, es stellen sich trotzdem unter hoher Last negative Performance Effekte ein. Im zugegeben schon etwas älteren SAP Hinweis #323270 ist dies für die verschiedenen Betriebssystemarchitekturen beschrieben. In dem Hinweis ist eine Auflistung für die verschiedenen Architekturen enthalten:
Windows NT -> 512 Bytes Solaris -> 512 Bytes AIX -> 512 Bytes HP-UX -> 1024 Bytes Digital Unix -> 1024 Bytes
Das bedeutet, dass die Log Block Size von X Byte in die Datei geschrieben wird. Wenn jetzt ein Filesystem mit einer anderen Blocksize angelegt wurde kommt es zu fragmentierungen der Blöcke, da die Informationen Größer oder Kleiner als die Blöcke sein können und somit unnötig I/O generiert wird (Entweder es wird zu viel gelesen oder zu viel geschrieben). Wenn Beispielsweise ein Dateisystem mit 4K Blockgröße angelegt wurde und die Redologs in 512 Byte Happen geschrieben werden muss bei jedem schreiben ein 4K Block für die 512 Byte Informationen belegt werden. Andersherum wird beim lesen eines 512 Byte Happen der ganze 4K Block von der Platte gelesen. Noch schlimmer wäre es z.B, wenn die Filesystemeinstellung ein Alignment von 512 Bytes hat und die Log Block Size im Oracle aber auf 1024 Bytes eingestellt ist. Für jeden logischen Oracle Block in der Redolog Datei würden dann 2 I/Os auf dem Filesystem benötigt, da die Information nicht in einem einzigen Block abgelegt werden kann. Auch wenn sich das bei heutiger Technik und Leistungsfähigkeit der SAN System eher unwichtig anhört darf man nicht vergessen, dass dies bei jedem Commit mehrfach passiert.
Im Oracle kann man das eingestellte Alignment für die Log Block Size wie folgt auslesen:
SQL> select max(lebsz) log_block_size from x$kccle where inst_id = userenv('Instance');
LOG_BLOCK_SIZE
--------------
512
SQL>
Nun sollte also geprüft werden, dass die Filesysteme für die Redologs mit dem gleichen Alignment angelegt wurden. Ansonten wird hier sehr viel Overhead (demoted I/O) produziert. Demoted I/O bedeutet hier, dass auf die (langsamere) normale I/O Varinate zurück geschlatet wird, wenn direct I/O oder concurrent I/O zuvor fehlgeschlagen sind. Wenn man also direct I/O oder wie in der Regel als Default vom Oracle (11.2.0.3) bei AIX 6.1 genutzt concurrent I/O für die Zugriffe nutzt und die Log Block Size nicht mit dem FS Alignement zusammen passt sieht das so aus:
bash >trace -aj 59B,59C; sleep 1; trcstop bash >trcrpt -o redlog_zugriff.txt bash >grep demoted redlog_zugriff.txt 59B 0.002085550 0.031898 JFS2 IO dio demoted: vp = F1000A0408682020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000 59B 0.002144787 0.023143 JFS2 IO dio demoted: vp = F1000A0408672020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000 59B 0.004384119 0.038100 JFS2 IO dio demoted: vp = F1000A0408672020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000 59B 0.004484242 0.041274 JFS2 IO dio demoted: vp = F1000A0408682020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000
Hier zeigt sich, dass absolut jeder I/O auf die Files auf das normale I/O zurückgestuft wird. Das ist natürlich der Performance nicht zuträglich. Oracle schreibt in diesem Beispiel mit der angegebenen Log Block Size von 512 Bytes, das Filesystem hat jedoch eine Blocksize von 4096 Bytes.
IBM hat 2012 einen Performanceguide für Oracle unter AIX herausgebracht in dem dieses Thema ebenfalls anschaulich erläutert wird. Anbei eine wie ich finde sehr aussagekräftige Veranschaulichung welche Auswirkungen ein demoted I/O auf die Antwortzeit hat (ORA: 512 Bytes, FS: 4096 Bytes):
Der Unterschied zwischen direct I/O und dem normalen I/O beträgt satte 26ms oder anders ausgedrückt ist um Faktor 14 (!) langsamer. Bei Nutzung von CIO (cuncurrent I/O) sieht das wieder anders aus. Daher die dringende Empfehlung die Filesysteme mit dem richtigen Alignment anzulegen und schon klappts auch mit dem I/O 😉
Stellt sich oftmal die Frage woher kommen die 4K im FS? Zum einen könnte es schlichtweg Unwissenheit sein, zum anderen könnte es daran liegen, dass es die Standard Größe für das Alignment beim Anlegen des Filesystems ist.
Bei den Datafiles gibt es daher diese Probleme in der Regel nicht. Hier ist die Regel, dass wenn die Oracle Block Size >=4K ist, das Alignment des FS ebenfalls 4K sein soll. Wie die Blocksize eingestellt ist lässt sich im Oracle wie folgt ermitteln:
SQL> show parameter db_block_size NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_size integer 8192 SQL>
Hier ist die DB Blocksize entsprechend auf 8K eingestellt (Standard, Oracle für SAP).
Für AIX kann man das Filesystem Alignment („Block Size“) mit dem Befehl lsfs -q <Filesystem> ermitteln:
server:/root # lsfs -q /oracle/SAP/sapdata1 Name Nodename Mount Pt VFS Size Options Auto Accounting /dev/lvsapdata1 -- /oracle/SAP/sapdata1 jfs2 4156555264 rw,noatime yes no (lv size: 4156555264, fs size: 4156555264, block size: 4096, sparse files: yes, inline log: yes, inline log size: 1982, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no) server:/root #