Filesystem

SAP Speicherverwaltung für Dummies mit ABAP Kernel 7.40/7.41 und Linux

Die richtige Einstellung der SAP Speicherverwaltung ist nicht immer einfach. Zum einen kommt es auf die Anforderungen an das System an, zum anderen natürlich auf die vorgegebene Umgebung und verfügbare Ressourcen. Früher zunächst nur für die Windows-Systemschiene bei SAP verfügbar gibt es seit einiger Zeit das SAP Zero Administration Memory Management auch für Linux. Eine nette Sache! Richtig eingesetzt macht es gerade in virtuellen Umgebungen richtig Sinn. Den über einen prozentuale Angabe des zu benutzenden RAMs ist es möglich, dass das SAP System sich zum Großteil automatisch an die RAM Veränderung anpasst. Man gibt also der virtuellen Maschine mehr Arbeitsspeicher, startet die entsprechende Instanz durch und viola – das System ist gleich passend für die wichtigsten Kenngrößen gesized ohne das auch nur an das Instanzprofil gedacht werden muss.

Wie geht man nun am Besten vor? Zunächst als <sid>adm ein cdpro absetzen um ins Profilverzeichnis (/sapmnt/<SID>/profile) zu wechseln und eine Sicherungskopie des aktuell aktiven Instanzprofils anlegen – safety first 🙂 Dreh- und Angelpunkt während der Anpassung ist der Parameter PHYS_MEMSIZE. Über diesen wird angegeben, wie viel Arbeitsspeicher für die Instanz genutzt werden soll. Die Angabe kann in Absoluten- und in Prozentwerten erfolgen. Somit kann man recht einfach für einen Application Server ohne Datenbank je nach Speicherausstattung 96 oder mehr Prozent angeben um dem Application Server möglichst viel Arbeitsspeicher zur Verwendung zu überlassen. Der Rest bleibt dann entsprechend für das OS übrig. In einer Shared Host Installation mit viel RAM kann so ggf. auch jeder Instanz 10% zugewiesen werden. Über das Konstrukt ist es dann ebenfalls möglich Instanzen mit hören Anforderungen über den Parameter gezielt mehr Speicher zuzuordnen ohne immer wieder an mehreren Parametern in mehreren Profilen schrauben zu müssen. Wird die Instanz auf dem Datenbankhost betrieben sollte hier zuvor genau errechnet werden wie viel Speicher das Datenbanksystem allein benötigt. In neueren SAP Releases geht das sehr einfach über die Transaktion DB02, die eine genaue Auflistung erstellt, die nicht nur die SGA enthält. Ansonsten muss man die Oracle Parameter auswerten und manuell errechnen.

Die für das jeweilige Kernelrelease unterstützen Formeln, die für das Memory Management herangezogen werden erhält man über sappfpar. Hierfür bietet sich folgendes Statement an: [Read more…]

Oracle patchen ohne oraInventory? Geht nicht? Geht doch!

Man benötigt es nicht wirklich oft – aber wenn es defekt ist oder gar komplett fehlt wird das oraInventory auf einen Schlag plötzlich sehr wichtig. Ohne oraInventory kann man das Oracle weder Patchen noch Updaten. Eigentlich sollte es kein Problem sein das Verzeichnis einfach aus einem Backup wieder herzustellen. Eigentlich. Denn manchmal kommt es eben anders als man denkt. Man wollte z.B. nur schnell einen Oracle SBP einspielen und dann meldet der OPatch folgende Fehlermeldung:

OPatch failed to locate Central Inventory.
Possible causes are: 
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.
LsInventorySession failed: OPatch failed to locate Central Inventory.
Possible causes are: 
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.

Es gibt nun zwei Möglichkeiten:

  • Eine Neuinstallation der kompletten Oracle Software
  • Das orainventory einfach wieder herstellen

(Bitte nicht auf die Idee kommen das Verzeichnis einfach von einer anderen Oracle Installation zu kopieren – das ist keine gute Idee!)
Da mir die erste Lösung zu viel Aufwand mit sich bringt bin ich eher ein Freund des zweiten Lösungsansatzes. Die Umsetzung funktioniert im Übrigen auch viel schneller. [Read more…]

Oracle Commit Performance – Filesystem I/O

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:

AWR Report Wait Class

AWR Report Wait Class

Alternativ kann man auch direkt im Oracle schauen:

[Read more…]