Transaktionen:
Profile & Profilparameter
AL11 Die SAP Verzeichnisse die auf dem Betriebssystem zufinden sind
RZ10 Profile und Profilparameter bearbeitung
RZ11 Dokumentation und tiefere Einblicke von Profilparametern
TU02 Sehen wer zuletzt welchen Profilparamter geändert hat
Die Welt der Datenbank
DB02 Tabellen und Indizes - Space Overview, Tablespace Platz, usw….
DB12 Übersicht DBK - Übersicht der Backups und Redologs
DB13 CheckDB - Oracle-Meldungen, Fehler, Alerts, Checkpoints
DB14 DBA-Operationsprotokoll für Datenbank / BRCONNECT, BRBACKUP,archive...
DB50 DB-Überwachung. Logs einsehen nach bestimmter Uhrzeit, etc.
DB59 MaxDB / Livecache - Systemübersicht - Nur bei MaxDB interessant
DBACOCKPIT Pflege der Systemkonfigurationen - Hier kann man alle Einstellungen über der Datenbank vornehmen
DBCO Sicht anzeige DBK - Sicht "Beschreibung von Datenbank-Verbindungen" anzeigen: Übersicht
Berechtigung
SU53 gucken welche Berechtigung einem User fehlen
PFCG Rolle für User erstellen und den User zulassen
For your interests
SM04 gucken wo wer angemeldet ist
TU02 Parameteränderungen anschauen ("History to file" -> und dann nach Datum Filtern)
SMICM Kontrolle der http und https services (Springen -> Services)
Sperreinträge & Verbuchungen
SM12 Sperreinträge - Sperreinträge von Tabellen, Lese, Schreibrechte, etc...Wenn etwas gesperrt ist!!!!!!!!!!!
SM13 Verbuchungsaufträge - Abgebrochen, noch zu verbuchen, etc….
Drucker
SP01 Spooler - Fehlerhafte Spools, etc….
Troubleshooting
SM21 Systemlog, SysLog - Log über alle Datensätze, Fehlerhafte, Grüne, etc…. oder gelöschte RFC-Destinations
SM32 / SE16 inhalt einer tabelle anzeigen
SM35 Batchinputmappen - Fehlerhafte Batche mit Uhrzeit und User, etc…
ST03N Performanceüberwachung - Expert-Modus: Systemlasten, Antwortzeitverteilung, etc…
ST06 Fielsystem - Display Analyse Menu: FileSys, etc…..
ST11 Fehlerprotokolldatei
ST22 ABAP Laufzeitfehler - auch gut zur Fehleranalyse
ST33 Globala Perfomance Analyse: Anzeige Performancedaten
SE03 Transport Organizer Tool
ST03N Performanceüberwachung - Expert-Modus: Systemlasten, Antwortzeitverteilung, etc…
Informationen sind sehr WICHTIG!!!
SM66 Workprozess Übersicht (Global)
ST02 Tune summary - man kann z.B. schauen wann der Server Neugestartet wurde
ST04 Systeminfos - Zeigt auch Betriebssystem Infos an
SCC4 / SE06 Systemänderbarkeiten
SM51 Serverübersicht - Server-Name, Rechnername, etx (Release Informationen)
Jobs im Hintergrund (Schildkröten mein Freund...)
SM36 standard jobs einplanen
SM37 Jobs / Hintergrundverarbeitung - Abgebrochene, Fertige, Aktive, etc… JOBS
Tabellen & Co.
SM32 / SE16 inhalt einer tabelle anzeigen
SE38 Mit versch. Reporten kann man z.B. Tabellen sichern oder wiederherstellen
Batch Prozesse
SM35 Batchinputmappen - Fehlerhafte Batche mit Uhrzeit und User, etc…
SM64 Batch Events - Übersicht und Verwaltung der Batch Events
Von SAP zu OS
CG3Y Download aus dem SAP (auch OS Dateien wie hosts datei)
CG3Z Download aus dem SAP (auch OS Dateien wie hosts datei)
Fehlersuche
ANST bei alten Releasen ANST_SEARCH_TOOL. Bei Programmfehlern ausführen
Reports:
Reports:
RPU12W0S Sichern/Löschen einer Backup-Version der Tabelle T512W (Mit TA: SE38) im Arbeitsmandanten
BTCTRNS1 Alle Jobs ausplanen...wichtig beim einspielen von großen Stacks oder viele HR Komponenten (mit TA: SE38)
BTCTRNS2 Alle Jobs werden wieder eingeplant (Mit TA: SE38)
RTCCTOOL Dieser Report checkt ob es noch Sachen gibt die man tun sollte. Schau einfach mal rein (SE38)
TMS_UPDATE_PWD_OF_TMSADM dieser Report ist ganz speziell, man kann in der TA: SE38 das Password von dem TMSADM ändern
/SSA/BTC Batch Job Analyse
RSCCEXPT Falls DDIC unterschiede bei Remotekopie hat (Option: NO_RFCCHK)
RSBDCOS0 (OS Befehle absetzen für alle Plattformen)
Nützliche Linuxbefehle: lscpu, free -m
ACHTUNG: der Report wird geloggt und taucht unter der SM21 auf.
RN2LN205N (Ausführen in TA: SE38) - Applikationsserver Directory: Upload/Download, etc
/SSA/BTC (Ausführen in TA: SE38) - Batch job analyse
Reset Buffers:
/$CUA Reset CUA buffers of the application server
/$NAM Reset name tab buffers of the application server
/$SYNC Reset all buffers of the application server
/$DYNP Reset screen buffer of the application server
/$DYN Reset screen buffer of the application server
/$TAB Reset table buffers of the application server
/$TAB RSADMIN Refreshes buffers for specific tables e.g. RSADMIN
/$OBJ Reset the shared buffer of the application server
/$ST Executing transaction memory usage
/$PXA Resets the Program (PXA) Buffer of the application server.
/$ESM Resets the Exp./ Imp. Shared Memory Buffer of the application server
Weiterhin gibt es Methoden in gängigen Transaktionen gewisse Buffer zu leeren.
SU53 -> authorization values -> Reset User Buffer.
SU01 -> environment -> mass changes -> reset all user buffers
PFUD oder Report : RHAUTUPD_NEW = Benutzerstammsätze / Benutzerzuordnungen abgleichen
SE38 und führe das Programm aus: RSUSR405 = Reset all user buffers in all clients
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
Inhalt zur Performanceanalyse
SE03 Transport Organizer Tool
ST03N Performanceüberwachung - Expert-Modus: Systemlasten, Antwortzeitverteilung, etc…
Informationen sind sehr WICHTIG!!!
SM66 Workprozess Übersicht (Global)
ST02 Tune summary - man kann z.B. schauen wann der Server Neugestartet wurde
ST04 Systeminfos - Zeigt auch Betriebssystem Infos an
SCC4 / SE06 Systemänderbarkeiten
SM51 Serverübersicht - Server-Name, Rechnername, etx (Release Informationen)
Jobs im Hintergrund (Schildkröten mein Freund...)
SM36 standard jobs einplanen
SM37 Jobs / Hintergrundverarbeitung - Abgebrochene, Fertige, Aktive, etc… JOBS
Tabellen & Co.
SM32 / SE16 inhalt einer tabelle anzeigen
SE38 Mit versch. Reporten kann man z.B. Tabellen sichern oder wiederherstellen
Batch Prozesse
SM35 Batchinputmappen - Fehlerhafte Batche mit Uhrzeit und User, etc…
SM64 Batch Events - Übersicht und Verwaltung der Batch Events
Von SAP zu OS
CG3Y Download aus dem SAP (auch OS Dateien wie hosts datei)
CG3Z Download aus dem SAP (auch OS Dateien wie hosts datei)
Fehlersuche
ANST bei alten Releasen ANST_SEARCH_TOOL. Bei Programmfehlern ausführen
Reports:
Reports:
RPU12W0S Sichern/Löschen einer Backup-Version der Tabelle T512W (Mit TA: SE38) im Arbeitsmandanten
BTCTRNS1 Alle Jobs ausplanen...wichtig beim einspielen von großen Stacks oder viele HR Komponenten (mit TA: SE38)
BTCTRNS2 Alle Jobs werden wieder eingeplant (Mit TA: SE38)
RTCCTOOL Dieser Report checkt ob es noch Sachen gibt die man tun sollte. Schau einfach mal rein (SE38)
TMS_UPDATE_PWD_OF_TMSADM dieser Report ist ganz speziell, man kann in der TA: SE38 das Password von dem TMSADM ändern
/SSA/BTC Batch Job Analyse
RSCCEXPT Falls DDIC unterschiede bei Remotekopie hat (Option: NO_RFCCHK)
RSBDCOS0 (OS Befehle absetzen für alle Plattformen)
Nützliche Linuxbefehle: lscpu, free -m
ACHTUNG: der Report wird geloggt und taucht unter der SM21 auf.
RN2LN205N (Ausführen in TA: SE38) - Applikationsserver Directory: Upload/Download, etc
/SSA/BTC (Ausführen in TA: SE38) - Batch job analyse
Reset Buffers:
/$CUA Reset CUA buffers of the application server
/$NAM Reset name tab buffers of the application server
/$SYNC Reset all buffers of the application server
/$DYNP Reset screen buffer of the application server
/$DYN Reset screen buffer of the application server
/$TAB Reset table buffers of the application server
/$TAB RSADMIN Refreshes buffers for specific tables e.g. RSADMIN
/$OBJ Reset the shared buffer of the application server
/$ST Executing transaction memory usage
/$PXA Resets the Program (PXA) Buffer of the application server.
/$ESM Resets the Exp./ Imp. Shared Memory Buffer of the application server
Weiterhin gibt es Methoden in gängigen Transaktionen gewisse Buffer zu leeren.
SU53 -> authorization values -> Reset User Buffer.
SU01 -> environment -> mass changes -> reset all user buffers
PFUD oder Report : RHAUTUPD_NEW = Benutzerstammsätze / Benutzerzuordnungen abgleichen
SE38 und führe das Programm aus: RSUSR405 = Reset all user buffers in all clients
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
Inhalt zur Performanceanalyse
Hardwareanalyse
Datenbankanalyse
R/3 Speicherkonfiguration
R/3 Workprozessanalyse
R/3 Workloadanalyse mit ST03
Analyse von ABAP-Programmen
RFC
GUI
Tabellenpufferung
Optimieren von SQL-Anweisungen durch Sekundärindizes
Performanceanalyse
<---- KLICKE AUF WEITERLESEN
Hardwareanalyse <back>
CPU:
ST06 -> idle im Stundenmittel (Detail Analysis | Previous Hours) < 35% -> Richtwert unterschritten
< 20% -> Problem
Noch CPU-Kapazität auf anderen Rechnern? -> bessere Lastverteilung
Prozesse mit hohem CPU-Bedarf suchen -> Detail Analysis | Top CPU Processes
R/3-Workprozesse? -> Identifizieren mit SM50
-> Verschieben in den Nachtbetrieb möglich?
-> Detailanalyse mit ABAP-Trace SE30
DB-Prozesse ?:
ST04 -> DB-Prozessmonitor -> Detailanalyse teure SQL-Statements
Externe Prozesse? -> abklemmen
ST06 -> Load average (Anzahl der Prozesse, die im Mittel auf CPU warten) sollte bei Null sein. Liegt der Wert der letzten 15 Minuten über 3.00, so sollte nach der Ursache geforscht werden.
Hauptspeicher:
Hauptspeicherengpässe können CPU-Engpässe verursachen. (Vermehrtes Swapping)
Swap: 3mal physischer Hauptspeicher. Minimal 3,5 GB. (20 GB auf 64-bit Systemen)
ST06 -> Pagingrate pro Stunde (Detail Analysis | Previous Hours) > 20% des phsyischen Hauptspeichers (Pages out; NT: Pages in) -> Hauptspeicherengpaß
- Noch freie CPU-Kapazität auf anderen Rechnern? -> bessere Lastverteilung
- Prozesse mit hohen Memorybedarf suchen -> ST02 Modusliste
-> SM04 Memory
- File System Cache auf 7-10% des physischen Hauptspeichers minimieren.
(HP-UX: dbc_max_pct, AIX: maxperm, NT: Network | Services | Server | Maximize Throughput for Network Appl.)
ST06 -> Sehr hohe Werte von “physical memory free” deuten darauf hin, dass die
Speicherzuordnung in den R/3-Profilen noch erhöht werden kann. Niedrige Werte können zu Engpässen z.B. auf Betriebssystemebene führen.
I/O:
ST06 -> Detail Analysis | Disk -> Auslastung (Util.) > 50% -> Problem
Bessere Verteilung der Daten.
Ziel: gleichmäßig belastete Platten
Netz:
ST06 -> Detail Analysis | LAN Check by Ping
Applicationserver – Datenbankserver sollte < 10 ms sein.
Applicationserver – Frontend -> s. Abschnitt GUI
Parameter:
Unter UNIX werden Parameteränderungen verfolgt mit:
ST06 -> Detail Analyse | Parameter Changes | History of File
Datenbankanalyse <back>
Datenbankmonitor ST04
Oracle
- Datenpuffer
- Data buffer: Size
- logische Zugriffe: Read, physische Zugriffe: Physical Read
- init<sid>.ora: DB_BLOCK_BUFFERS in 8KB-Blöcken
- Qualität rule-based Optimizer >= 97%
- Qualität cost-based Optimizer >= 95%
- Buffer busy waits > 5% -> Detailanalyse
- Undo-head, undo-block > 1% -> u.U. Rollbacksegmente hinzufügen
- data-block > 1% -> u.U. Data Buffer vergrößern
- Shared Pool (bildet zusammen mit dem Datenpuffer die SGA)
- Enthält Verwaltungsinformationen in
- Row Cache (Data-Dictionary-Cache: Namen und Eigenschaften von Tabellen, Benutzern…)
- DD-Cache quality > 90%
- Shared SQL Area (Ausführungspläne und Statistiken von SQL-Statements)
- Pinratio >= 98%
- Init<sid>.ora: SHARED_POOL_SIZE in Byte
- Ist noch Platz im Shared Pool frei? -> V$SGASTAT -> Free memory
- Redo Log Buffers
- init<sid>.ora: LOG_BUFFER als Vielfaches von DB_BLOCK_SIZE
- Alloc fault rate > 1% -> u.U. Online Redologs vergrößern
- Calls
- User Calls: Aus der Anwendung stammende SQL-Zugriffe
- Recursive Calls: Zusätzlich durch das Oracle generierte Zugriffe, z.B. bei Misses im Data-Dictionary Cache oder beim Anlegen neuer Tabellenextents
- User Calls/Recursive Calls < 1 – 2 -> Shared Pool vergrößern, init<sid>.ora: row_cache_cursors > 100 (prüfen), sapdba -next
- rollbacks: Hoher Wert -> Auf fehlerhafte Transaktionen prüfen; Oracle-Alert-Log prüfen
- Parses: Anzahl der Parse-Vorgänge für SQL-Statements
- User Calls/Parses < 4 -> Shared SQL Area u.U. zu klein
- Reads/User Calls > 30 -> Prüfen auf „Teure SQL-Statements“ (s.u.)
- Time Statistik
- busy wait time: Die Oracle-Schattenprozesse warten auf eine Resource
- idle wait time: Die Oracle-Schattenprozesse haben nichts zu tun
- total wait time: busy + idle wait time
- busy wait time/total wait time sollte klein sein
- Sessions busy: (CPU-time + busy wait time)/(CPU-time + total wait time)
- Details finden sich über ST04 -> Detail Analysis | Wait Events
- Program Global Area (prozesslokaler Speicher)
- Variabel (Richtwert 2,5 – 5 MB pro Prozess)
- Prozesse: ST04 -> Detail Analysis | Oracle Sessions
SQL-Server
- Datenpuffer (Data cache)
- Data cache KB: Size
- Cache hit ratio > 95%
- Größe: Rest des Server-Speichers
- Procedure-Puffer (Procedure Cache)
- Stored Procedures und Ausführungspläne für SQL-Statements
- ST04 Procedure cache KB, Procedure cache KB in use
- Größe wird dynamisch festgelegt.
- Fester Speicheranteil für Connections, Sperren… (ca. 20-100 MB)
- Größe wird dynamisch festgelegt.
- Server-Speicher (Summe der 3 vorhergehenden Arten)
- ST04 Dynamic memory KB
- Variiert zwischen Maximum (Minimum) memory KB oder 0 und 2 GB bei Auto Growth
- Parameter MAX (MIN) SERVER MEMORY
- Empfehlung: Kein Auto Growth
DB2/OS390
- Datenpuffer (Buffer-Pools und Hiperpools)
- Puffert Daten- und Index-Pages
- Read Random Hit Ratio >= 95%
- Hiperpool Efficency >= 10%
- EDM-Pool
- Globaler Teil des Dynamic Statement Cache
- Global Cach Hit Ratio >= 95%
- Tread-lokale Caches
- Lokaler Teil des Dynamic Statement Cache
- Local Cache Hit Ratio >= 50%
- Reprepare Ratio (Verdrängung) < 50%
Teure SQL-Statements
- können zu Hardwareengpässen führen (z.B. CPU, I/O)
- blockieren R/3-Workprozesse
- verdrängen andere Daten aus dem DB-Datenpuffer
Aktuell laufende SQL-Statements (Oracle):
ST04 -> Detail Analysis | Oracle Sessions -> mehrfach auffrischen
- zugehöriges R/3-Programm in SM50 ermitteln -> Nachtbetrieb?
- Ansonsten Analyse wie bei „Statistik von SQL-Anweisungen auswerten“
Statistik von SQL-Anweisungen auswerten (Shared SQL Area) (Oracle):
ST04 -> Detail Analysis | SQL Request
- sortieren nach Buffer Gets
- Buffer Gets/ST04-Reads = Prozentualer Anteil der Anweisung an der Gesamtlast
- Disk Reads/ST04-Physical Reads analog
- wenige Statements > 5% Gesamtlast? -> Tuning erforderlich
- SQL-Statement ermitteln
- Wird ein passender Index verwendet (Explain)?
- Kann ein neuer oder modifizierter Sekudärindex weiterhelfen? Kandidaten sind SQL-Statements, bei denen das Verhältnis von „Buffer Gets“ zu „Records“ schlechter als 10 zu 1 ist.
- SAPNet-Recherche mit „Performance“ und Tabellenname
- ABAP-Optimierung (Kandidaten sind SQL-Statements, die viele Gets/Execution aufweisen, also möglicherweise unnötig viele Daten lesen.)
DB2/OS390:
Aktuell laufende SQL-Statements: DB2 -> Thread Activity
Statistik von SQL-Anweisungen: DB2 -> Statement Cache Statistics
Datenbank I/O
ST04 -> Detail Analyse | Filesystem Request -> I/O pro Datei -> Hoch?
ST04 -> Goto | Statistics | Filesystem Waits -> Wartesituationen?
-> Auslastung der Platte untersuchen (ST06), gegebenenfalls Datenverteilung ändern
Lastintensiv:
- Redo-Logs (Oracle)
- (PSAPROLL)
- (saparch)
- Transaction Log (SQL-Server)
- (Tempdb)
Exclusive Lockwaits
DB01 -> über Client-Host, Client-PID und SM50 zugehörigen R/3 Prozess ermitteln
- falls kein R/3 Prozess -> Datenbankprozess beenden
Parameter
Änderungen von Datenbankparametern werden verfolgt mit
ST04 -> Detail Analyse | Parameter Changes | History of File
Tabellenstatistiken für Datenbankoptimierer
Regelmäßige Ausführung mit DB13 prüfen.
Datenbankindizes
Missing Indizes mit DB02 prüfen.
R/3 Speicherkonfiguration <back>
R/3-Puffer:
ST02 -> Buffer -> Swaps? -> Entsprechenden Profilparameter erhöhen
Ausnahme: Beim Programm-Puffer können bis zu 10000 Swaps pro Tag toleriert werden.
ST02 -> Buffer -> Hitratio sollte über 98% liegen.
Ausnahmen: Program, Single record und Export/Import-Buffer.
Alle Puffer sollten mindestens 20% Free Space aufweisen. Ausnahmen: Nametab, CUA, screen und Calender-Buffer, die in produktiven Umgebungen nur einem geringen Wachstum unterliegen.
SAP-Memory:
Extended Memory ist im Shared Memory abgebildet und wird beim Kontextwechsel in den Adressraum eines Workprozesse hineingemapped. Initial allokiert das System Extended Memory in der Grösse em/initial_size_MB. Für einen einzelnen Benutzerkontext steht maximal Extended Menory in der Grösse von ztta/roll_extension zur Verfügung. (NT s.u.)
Roll Memory wird beim Kontextwechsel aus dem Roll-Puffer (shared) in den lokalen Speicher des Workprozesses kopiert (was aufwendiger ist).
Heap Memory ist lokal zu einem Workprozess. Kontextwechsel sind nicht mehr möglich. Heap Memory wird erst mit Durchstarten des entsprechenden Workprozesses wieder freigegeben.
Reihenfolge der Speicherbelegung durch Dialogworkprozesse (NT auch sonstige):
- Roll Speicher bis ztta/roll_first (Minimum ca. 100 KB)
- Extended Memory bis nichts mehr da ist, oder die Grenze ztta/roll_extention bzw. em/address_space_MB erreicht ist.
- Roll Speicher bis ztta/roll_area erschöpft ist
- Heap Speicher
ST02 -> Extended Memory -> Max. use > 80% in memory? -> Problem
-> Benutzer mit hohem Speicherverbrauch? -> Detailanalyse
(ztta/roll_extention nutzen)
-> em/initial_size_MB erhöhen, notfalls auf Kosten anderer Speicherbereiche.
Faustregel: 6-10 MB pro Benutzer, 70 –120% des physical Memory.
ST02 -> Roll area -> Max. Use > in memory -> Problem
-> rdisp/ROLL_SHM erhöhen, falls genügend physical Memory.
NT: Zero-Administration Memory (Hinweis 88416)
- PHYS_MEMSIZE 70-100% des phys. Memory
- Alle anderen Speicherparameter löschen.
- Das Extended Memory vergrössert sich bei Bedarf dynamisch
- In den Adressraum eines Workprozesses wird Extended Memory in der Grösse von em/address_space_MB eingebunden (ztta/roll_extention ist hier obsolet). Es lässt sich also trotz des 32-bit Charakters von NT auch RAM von mehr als 2 GB effektiv nutzen, da er auf die Workprozesse verteilt wird.
Insgesamt allokierter Speicher:
ST02 -> Detail analysis | Storage
Storage shared between processes (R/3-Puffer)
+ User storage for all work processes
+ Size of Extended Memory
= Beim Starten von R/3 allokierter Speicher
Kann wachsen um
+ Maximum heap area for all work processes (abap/heap_area_total)
aktueller Wert: ST02 -> Heap memory -> Current use
Hinzu kommt noch
+ von der Datenbank allokierter Speicher -> ST04
+ 50 – 100 MB für das Betriebssystem
Die Summe des allokierten Speichers sollte den physisch vorhandenen um maximal 50% übersteigen.
Der maximal allokierbare Speicher darf die Summe aus phys. Memory und Swap nicht überschreiten!!
R/3 Workloadanalyse
Lokale Workprozessübersicht:
Infos zu den verschiedenen Gründen für den Status „hält“ und zu den verschiedenen Semaphoren mit F1.
Semaphore: Resourcen, wie der Roll-Buffer, die serialisiert werden müssen. (Grün: WP hält Semaphore, Rot: WP wartet auf Semaphore) Die Bedeutung der Semaphore ist in Hinweis 33873 erklärt.
SM50 -> Es sollten genügend frei Workprozesse (Status „wartet“) jeden Typs vorhanden sein.
SM50 -> Programm mit hohem Zeit-Wert? -> Mit Benutzer klären, ob alles klar ist.
SM50 -> mehr als 20% der Workprozesse im PRIV-Mode -> möglicherweise Speicherproblem
SM50 -> mehr als 40% der Workprozesse in einer DB-Aktion -> möglicherweise DB-Problem
SM50 -> mehr als 20% der Workprozesse lesen dieselbe Tabelle
-> möglicherweise Problem mit teuren SQL-Statements oder exclusive Locks
SM50 -> Aktion „Report laden“ oder Semaphore 1 -> Program-Buffer prüfen
SM50 -> Aktion „Roll In, Out“ oder Semaphore 6 -> Extended Memory und Roll-Buffer prüfen
SM50 -> Status „hält“, Grund „CPIC“ -> Probleme im Zielsystem?
SM50 -> CPU -> WPs einer Art weichen von „Dreiecksform“ ab (Betriebsartenumschaltungen berücksichtigen.)
-> Anzahl WPs prüfen
-> Lastverteilung prüfen
SM50 -> WPs im Status „beendet“ und nicht mehr zu starten?
-> Prozesses | Trace | Anzeigen -> dev-Trace lokal speichern.
Globale Workprozessübersicht:
SM66 bietet Zusatzinformationen wie Transaktionscode, Name des aufrufenden Programmes, Jobname, aktuelle Extended Memory Belegung, aktuelle Heap Memory Belegung. Bei ausgeschaltetem RFC werden Informationen vom Message Server geholt und sind möglicherweise veraltet.
Dispatcher-Queue:
SM51 -> Springen | Queue Info -> Höchststand wartenden Anfragen gibt Info zu WP-Mangel.
Workprozessübersicht auf Betriebssystemebene:
dpmon pf=/usr/sap/<SID>/SYS/profile/Instanzprofilname
R/3 Workloadanalyse mit ST03 (ST03N ab 4.6) <back>
Av. response time = Wait time + Load+gen time + Roll-in time + Roll-wait time + Processing time +
DB time + Enqueue time + GUI time (ab 4.6)
Die Aussage von ST03 zur av. response time kann durch einzelne langlaufende oder auch regelmäßig ausgeführte schlecht programmierte Programme verzerrt werden. Eine solche Verzerrung kann über STAT/STAD ermittelt werden.
Wird der Schnitt nicht durch solche Ausreißer kaputt gemacht, kann man sich an folgenden Richtwerten orientieren
Richtwerte Dialog:
Av. response time sollte nicht größer als ca. 1000 ms sein.
Av. CPU time sollte bei 40% der av.response time liegen.
Wait time >> 10% der av. Response time allgemeines Problem
>> 50 ms z.B. zu wenig WPs * oder WPs blockiert
Load+gen time >> 50 ms Programmpuffer (CUA- oder Screen- Puffer) zu klein oder CPU-Engpass
Roll-in time >> 20 ms Roll-Puffer oder Extended Memory zu klein oder CPU-Engpass
Roll-wait time >> 200 ms Problem in der Frondend-Kommunikation
(ab 4.6; zusammen mit hoher GUI-Zeit) oder Komunikationsproblem mit externer Komponente bei sonstigem synchronem RFC
GUI-Zeit >> 200 ms (ab 4.6) Probleme mit Frontendkommunikation (zusammen mit Hoher Roll-wait time)
Enqueue time >> 5 ms Problem mit Enqueue oder Netz
Processing time >> 2 x CPU-time CPU-Engpass oder
(Processing time verstreicht, ohne dass CPU Workprozess im Zustand “hält” (SM50)
genutzt werden kann) (s. auch „Fehlende Zeiten“ bei der
Einzelsatzstatistik weiter unten)
DB request time >> 40% von (av. Response time Datenbank-, Netz- oder CPU-Problem - Wait time) Richtwert (200 – 600 ms)
Time per DB request >> 5 ms Datenbankproblem
Direct Reads >> 2 ms Datenbankproblem
Sequential Reads >> 10 ms Datenbankproblem
Changes and commits >> 25 ms Datenbankproblem
Av. RFC+CPIC time >> 10 ms Kommunikationsproblem
Die Processing time ist die Differenz von av. Response time und allen Zeiten, in denen keine CPU-Zeit benötigt wird. Sie berechnet sich aus
Av. Response time – Wait (for workprocess) time – DB request time – Enqueue time – Roll in time – Roll wait time – Load+gen time.
Richtzeit für die durchschnittliche Roll in/out time: 10 ms.
Die Roll-out time geht nicht in die av. Response time ein.
___________________________
* Die Erhöhung der Anzahl der Workprozesse bringt nur etwas, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten (z.B. PRIV-Mode oder Sperrsituationen auf der Datenbank), UND CPU und Speicher des Rechners noch nicht voll ausgelastet sind. Im Zweifel ist das Warten auf CPU teurer als das Warten auf Workprozesse. Bei CPU- bzw Hauptspeicherengpässen und hoher Processing-time kann die Reduzierung der Anzahl der Workprozesse die Performance verbessern.
___________________________
Die Av. RFC+CPIC time ist bei asynchronem RFC die Zeit, die zum Aufbau der Verbindung und zur initialen Datenübergabe benötigt wird (Richtwert < 50 ms). Beim synchronen RFC ist es die Gesamtzeit des Aufrufs inclusive der Roll wait time und der Zeit für die Übergabe der Ergebnisdaten.
Die Roll wait time ist die Zeit in der ein Programm auf die Antwort eines synchronen RFC-Aufrufes wartet. In dieser Zeit ist das Programm aus dem Speicher herausgerollt, die Antwortzeit läuft aber weiter. Im gerufenen System wird ein Statistiksatz des Task-Typs RFC erstellt. Ab 4.6 entsteht Roll wait time auch bei der Kommunikation mit dem GUI.
Aktivität oder Durchsatz := Anzahl Transaktionsschritte pro Zeiteinheit
Last := Gesamte Antwortzeit
Richtwerte Update:
Direct Reads Richtwert 10 ms
Sequential Reads Richtwert 15 ms
Changes and commits Richtwert 40 ms
RFC-Profile:
Client-/Server-Destinationen
- Summenstatistiken zu einzelnen Destinationen. (Angaben zu Funktionsbausteinen haben hier keine Bedeutung und werden in neueren Releases nicht mehr aufgeführt.)
Client Profil
- das lokale System stellt den RFC-Request (Sender)
Server Profil
- das lokale System bearbeitet den RFC-Request (Empfänger)
Call time/Aufrufzeit (gemessen im Sender-System)
Call time – Execution time > 20% von Call time
-> Probleme in der Verbindung zwischen Sender und Empfänger
-> SM59 Verbindungstest bzw. RFC-Trace
Execution time/Ausführungszeit (gemessen im Empfänger-System)
Sichten:
Funktionsbausteine
- Es werden Statistikinformationen zu den 5 teuersten Funktionsbausteinen gesammelt. (Anzahl -> stat/rfcrec im Profil)
Allgemeine Performanceprobleme:
Indikatoren: Wait time, DB request time, Processing time oder av. Response time zu hoch.
Zeitliche Einordnung: ST03 -> Auswahl von „Total“, „Dialog“, „Background“... -> Time Profile.
Interessant ist z.B., ob die Hintergrundlast Ursache für eine hohe Gesamtlast zu Hauptarbeitszeiten ist.
Lastverteilung zwischen Servern:
ST03 -> Goto | Performance Database | Analyse all Servers | Compare all Servers
- Bei gleichen Rechnern sollte die „CPU time total“ ungefähr gleich sein.
- Starke Unterschiede in den Datenbankzeiten weisen auf Netzprobleme hin. **
___________________________
** Dies gilt auch für datenbankintensive Batchjobs: Wenn Batchjobs auf dem Datenbankserver schneller als auf Applicationservern laufen, so ist dies ein Indikator für Netzprobleme.
___________________________
Spezielle Performanceprobleme:
Einzelne Übeltäter findet man über:
ST03 -> Auswahl von „Total“, „Dialog“, „Background“... -> Transaction Profile
Interessant sind
- die erzeugte Systemlast, insbesondere von selbstgestrickten Transaktionen
- die mittlere Antwortzeit der Kerntransaktionen
- Datenbanklast (Datenbankzeit > 60% der Gesamtzeit -> SQL-Trace)
- CPU-Last (CPU-Zeit > 60% der Gesamtzeit -> ABAP-Trace)
Einige Exoten:
- MainMenu: Aktionen im Menü <= 100 ms (Richtwert Antwortzeit)
- AutoAbap: läuft periodisch im Hintergrund < 1000 ms
- Buf.Sync: Puffersynchronisation < 1000 ms
- RSM13000: Alle Verbuchungsbausteine, die nicht einer Transaktion zugeordnet werden können < 3000 ms
ST03 -> Auswahl von „Total“, „Dialog“, „Background“... -> Memory Profile
Performanceprobleme nach Anwendung:
Der Anwendungsmonitor ST07 schlüsselt nach Benutzern pro Modul auf. Durch Doppelklick steigt man in der Hierarchie in die Tiefe.
Last pro Anwendung: ST07 -> Antwortzeit
Pufferverbrauch pro Anwendung: ST07 -> SAP-Puffer
Analyse von ABAP-Programmen <back>
Einzelstatistik:
STAT/STAD -> Auswahl der verdächtigen Transaktion/des verdächtigen Programms
Doppelklick zur Einzelauswahl -> All Details
Hohe Datenbankzeiten -> Datenbankproblem
Häufig: “Note: Tables were saved in the table-buffer” -> Verdrängung/Invalidierung im Tabellenpuffer.
Hohe Roll wait time, hohe GUI time -> Möglicherweise Kommunikationsproblem
Hohe CPU-Zeiten -> Aufwendige Berechnungen o. häufige Zugriffe auf den
Tabellenpuffer. CPU > 50% -> ABAP-Trace oder ABAP-Debug.
„Fehlende Zeiten“ bei langlaufenden Jobs können anhand der Processing time (s.o.)
ermittelt werden. Die Processing time sollte im Wesentlichen die Zeit sein, in
der die CPU genutzt wird. Ist die Processing time deutlich grösser als die CPU-Zeit,
so könnte:
- Ein Statistik-Couter einen Overflow haben
- Ein Paging-Problem oder ein CPU-Engpass vorliegen
- Eine zum Application-Server lokale Datei verarbeitet werden (auch Sort mit Auslagerung auf Platte)
- Ein Batch-Job „Commit work and wait“ abgesetzt haben
SQL-Trace:
ST05 -> Vor dem Trace Programm einmal ausführen, um Puffer zu füllen.
Trace zu lastarmen und lastintensiven Zeiten wiederholen.
Der Trace läuft lokal dort, wo er eingeschaltet wurde. ***
List Trace -> Ausführen
Zeiten in Mikrosekunden.
Direct Read (Rec = 1 !) 2-10 ms. Nur in Einzelfällen höher.
Sequential Read nutzt Array Fetch. Es passen umso mehr Sätze in einen Array rein, um so weniger Felder beim Select gewählt wurden. Richtzeit für einen optimalen Array Fetch 5 ms im Mittel (< 10 ms) pro selektiertem Satz oder < 100 ms pro Fetch im Mittel. Fetch > 250 ms und nur wenige Sätze selektiert -> Möglicherweise kann ein neuer oder modifizierter Sekundärindex weiterhelfen.
Goto | Summary | Verdichten -> Sortieren nach Laufzeit liefert die teuersten SQLs.
Goto | Identical Selects -> liefert Mehrfachzugriffe, die sich vielleicht einsparen lassen.
RFC-Trace:
ST05 -> Object: Name des Empfängers
Oper: „Client“ (Instanz, auf der der Trace läuft ist Client) oder „Server“
Statement: U.a. Name des Funktionsbausteins, übertragene Datenmenge
Enqueue-Trace:
ST05 -> Object: Name des Enqueue-Objektes
Oper: Einzelne Enqueues setzen/freigeben (ENQUEUE/DEQUEUE);
DEQ ALL zu Objekt oder zum Ende der Transaktion; ENQPERM vererbt
die Sperre an die Verbuchung
ABAP-Trace:
SE30 -> Zu analysierendes Programm zunächst einmal ohne Analyse durchführen, um alle
Puffer entsprechend zu füllen. Analyse zu lastarmen und lastintensiven Zeiten wiederholen.
___________________________
*** Performancebeeinträchtigung durch den Trace ca. 5%
___________________________
Auswerten
Hitliste: Ausführungszeiten je Anweisung sortiert nach Bruttozeiten ****
Hierarchie: Chronologischer Ablauf
Bruttozeiten enthalten alle enthaltenen Aufrufe. (z.B. Perform: Brutto > Netto)
Analyse: Einstieg in die Hitliste – Sortieren nach Nettolaufzeit zur Ermittlung der Anweisungen mit der höchsten Nettolaufzeit
Analyse komplexer Programme: Analyse des gesamten Programmes mit voller Aggregierung und ohne Analyse von Operationen auf interne Tabellen (Default-Variante) – Ermitteln der Modularisierungseinheiten mit hoher Laufzeit – Detailanalyse mit aktiviertem Trace für Operationen auf interne Tabellen und ohne Aggregation
ABAP-Debugger:
Der ABAP-Debugger setzt u.U. Commits ab, erzeugt also möglicherweise inkonsistente Datenbestände!
Starten des Progamms -> mit SM50 | Debugging mehrfach in das Programm springen -> identifiziert Coding-Stellen mit hohem CPU-Bedarf.
Springen | Weitere Bilder | Speicherverbrauch -> Aktueller Hauptspeicherbedarf (Richtwerte: Dialogprogramm <= 100 MB, Batchprogramm <= 1GB)
Springen | System | Systembereiche -> ITAB -> Liste der internen Tabellen.
FILL -> Anzahl der Einträge
Hauptspeicherbedarf = FILL * Leng
Prüfen: Werden nicht mehr benötigte interne Tabellen mit REFRESH bzw. FREE freigegeben?
Werden interne Tabellen mit dem Zusatz BINARY SEARCH durchsucht?
(READ TABLE … WITH KEY … BINARY SEARCH auf sortierte Tabellen)
(4.0: verwenden von SORTED TABLE oder HASHED TABLE)
___________________________
**** Der ABAP-Trace ist performanceaufwendig. Alle ermittelten Zeiten werden daher „korrigiert“ und sind niedriger, als die Zeiten der parallel geschriebenen Statistiksätze.
___________________________
RFC <back>
RFC dient der Kommunikation zwischen verschiedenen Systemen oder – innerhalb eines Systems – der Kommunikation zwischen Instanzen bzw. zwischen der Applikationsebene und der Präsentationsebene sowie der Parallelisierung von Prozessen. RFC wird immer von Dialog-Workprozessen ausgeführt.
Zwei Systeme lassen sich auf „harte“ und „weiche“ Art koppeln.
Hart: Ist der Partner nicht erreichbar, bricht die Funktion, die RFC verwendet, ab.
Weich: Gegenseitige Verfügbarkeit wird nicht vorausgesetzt. (Beispiel: ALE)
Man unterscheidet 4 Arten von RFC:
- Synchroner RFC: Der Sender (Client) wartet, während der RFC beim Empfänger (Server) läuft -> Roll wait time. (CALL FUNCTION ... DESTINATION ...)
- Asynchroner RFC: Der Sender setzt seine Arbeit nach Start des RFC fort. -> Parallelisierung möglich. (CALL FUNCTION ... STARTING NEW TASK ... DESTINATION ...)
- Transaktionaler RFC: Asynchroner RFC. tRFCs werden nach COMMIT WORK als LUW ausgeführt. (CALL FUNCTION ... IN BACKGROUND TASK DESTINATION ...)
- Queued RFC: tRFC, bei dem die Reihenfolge der Abarbeitung im Zielsystem der der Erstellung entspricht.
Ablauf:
- Der Sender stellt die Verbindung zum Empfänger her. SM50: hält CPIC CMINIT
- Die erforderlichen Daten werden zum Empfänger übertragen. SM50: hält CPIC CMSEND
- Der synchrone RFC wartet. (Roll Out, Roll wait, SM04: Terminal APPC-TM, SMGW: offene Kommunikationsverbindung)
- Der Empfänger „weckt“ den Sender des synchronen RFCs und schickt Daten zurück. SM50: hält CPIC CMRECEIVE
- Abbau der Verbindung
SM59 Verbindungstest: TCP/IP-Timeout ->
- Empfängersystem verfügbar?
- TCP/IP: Gateway korrekt definiert? S. auch Hinweis 63930 und 44844.
SM59 Verbindungstest: Partnerprogramm nicht registriert ->
- Empfängerprozess starten
SM59 Verbindungstest: > 100 ms ->
- Netzwerkverbindung zu langsam/überlastet (Prüfen mit „ping“, Richtwert für gute Verbindung 10 – 30 ms)
- Empfängersystem überlastet (Alle Workprozesse belegt?)
- TCP/IP: Prüfen, wie viele parallele Empfangsprozesse für IDOCs gestartet sind
Zur Begrenzung des Resourcenverbrauchs durch asynchronen RFC s. Hinweis 74141. Über das Programm RSARFCLD könne die Quotas dynamisch konfiguriert werden.
SM58: Fehlerkontrolle für tRFCs
Für Verbindungen mit mehr als 50 tRFCs täglich sollte die automatisch Einplanung des Batchjobs RSARFCSE bei Kommunikationsfehlern unterdrückt werden. Stattdessen das Programm RSARFCEX mit der Destination und dem aktuellen Tag in der Periode 30 Minuten einplanen.
Bei hohem tRFC-Aufkommen müssen die Tabellen ARFCSSTATE und ARFCSDATA reorganisiert werden. (RSARFC01, s. auch Hinweis 375566)
GUI <back>
Ab R/3 4.6 wird für die Kommunikation zwischen Präsentations- und Applikationsebene die Control-Technik genutzt. Controls sind Softwarekomponenten, die im GUI eigenständig laufen. Bei Listen z.B. wird nicht nur der aktuelle Screen, sondern eine größere Datenmenge übertragen. Operationen wie Blättern erfolgen dann auf dem Front-End und erfordern keine Kommunikation mit dem Application-Server mehr.
Zum Aufbau eines Bildschirms sind u.U. mehrere Interaktionen (Roundtrips) zwischen Präsentations- und Applikations-Server erforderlich. Pro Roundtrip werden Daten per synchronem RFC von der Applikationsebene an den Gui übertragen.
Die GUI-Zeit eines Transaktionsschritts umfasst die Roll wait time, die beim RFC anfällt.
Analyse von Problemen mit der GUI-Kommunikation bei Controls mit STAD:
- Select Fields: Roll wait time, No. of round-trips, GUI time, Terminal in-Message, Terminal out-Message (App. -> GUI, unkomprimiert)
- Interessant sind hohe GUI-Zeit oder hohe Datenübertragungsmenge
- Datenübertragung: Im Mittel 1 KB pro 100 ms; häufig über 1 sek -> Netzwerkproblem oder Hardwareengpass auf dem Präsentationsserver
- Datenmenge: Im Mittel 5-8 KB/Transaktionsschritt; häufig über 50 KB -> Problem beim Programm(design). -> Transaktionsvariante nutzbar? (Hinweis 332210)
Analyse von Problemen mit der GUI-Kommunikation bei Controls mit ST05:
- SQL-, Enqueue- und RFC-Trace aktivieren
- Suchen nach RFC-Bausteinen mit Ziel Präsentation-Server (Spalte: Objekt)
- Anteil der Antwortzeit an der Gesamtantwortzeit relevant?
- Bewerten (s.o) des Verhältnisses von Antwortzeit (duration) zur übertragenen Datenmenge (bytes sent nach Zeilenauswahl)
Analyse des Netzwerks zwischen Application- und Presentation-Server mit „Lan Check by Ping“:
- Zu analysierende Präsentation-Server markieren
- 10 x Ping; Typische Antwortzeiten:
- LAN < 20 ms
- WAN < 50 ms
- Modem < 250 ms
- Keine „Losses“
Im WAN oder bei langsamen Netz sollte die Low Speed Connection genutzt werden. (Hinweis 164102) (Bei der Low Speed Connection steht die Vorschlags-Funktion für alte Eingaben nicht zur Verfügung.)
Bei Hardwareengpässen auf dem Presentation-Server auf das Classic-Design umschalten.
Tabellenpufferung <back>
Tabellen können im Einzelsatzpuffer TABLP oder im generischen Tabellenpuffer TABL gepuffert werden.
Zur Synchronisation der Tabellenpuffer verschiedener R/3-Instanzen wird in regelmäßigen Abständen (rdisp/bufreftime) die Tabelle DDLOG ausgelesen, wenn rdisp/bufrefmode auf ..,exeauto steht.
Tabellenpufferinhalte werden in den Einheiten invalidiert, in denen sie gefüllt werden.
Tabellen puffern, wenn
- sie klein sind
- häufig auf sie zugegriffen wird
- ihre Änderungsrate klein ist
- kurzzeitige Inkonsistenzen zwischen den Applikationsservern akzeptiert werden können
- bei generisch n-gepufferten Tabellen der Zugriff mindestens über die ersten n Schlüsselfelder erfolgt.
Prüfen: Sind die im Customizing generierten Konditionstabellen Annn, Bnnn, Cnnn, Dnnn, KOTEnnn, KOTFnnn, KOTGnnn und KOTHnnn, (nnn = 500 – 999 sind Kundentabellen) korrekt gepuffert?
Tabellenpufferung überwachen:
ST02 -> freier Platz > 10%, freie Einträge > 20%.
Symptome für Tabellenpufferprobleme:
- Benutzer klagen über sporadisch auftretende lange Antwortzeiten in Transaktionen
- In der Shared SQL Area oder bei SQL-Traces finden sich teure Anweisungen mit Bezug auf gepufferte Tabellen.
- ST03 / STAD: Häufig: Note: Table were saved in Table buffer.
ST10 – Status:
Valid - Tabelle gültig im Puffer
Invalid - Tabelle invalidiert. Es läuft gerade eine Aktion die noch nicht mit Commit
abgeschlossen wurde.
Pending - Tabelle invalidiert. Karenz läuft gerade.
Loadable - Tabelle invalidiert. Kann geladen werden.
Absent, displaced - Tabelle noch nicht geladen oder verdrängt.
Multiple - Einige generische Bereiche sind gültig, andere invalidiert.
Error - Fehler beim Laden der Tabelle
Analyse gepufferter Tabellen:
ST10 - sortieren nach DB activity: Rows affected -> sollte klein sein
- sortieren nach Changes o. Invalidierungen -> Changes/Request (Änderungsrate) sollte klein sein.
- sortieren nach Tabellengröße: < 1MB -> Änderungsrate < 1%, < 5MB -> ÄR < 0,1% (4.0B)
Analyse nicht gepufferter Tabellen:
ST10 - sortieren nach Requests Total -> Hoch: Tabelle ist Pufferungskandidat, wenn sie die
Kriterien oben erfüllt und gepuffert werden darf.
DB05 - Die Anzahl Sätze, die nach einer Invalidierung neu gelesen werden müssen und
andererseits die Anzahl der generischen Regionen dürfen nicht zu hoch sein.
Z.B. 150000 Sätze (-> volle Pufferung lohnt sich kaum, wenn die Änderungsrate nicht sehr
gering ist): Bei Invalidierung maximal 10000 Sätze, 1500 gen. Regionen ist ok.
Die Pufferung von Tabellen soll die Zugriffe auf die Datenbank vermindern, also das Verhältnis von Requests zu Rows affected klein halten. Bewirkt eine Änderung der Tabellenpufferung dies nicht, so muss sie überdacht werden.
Shared SQL Area bzw. SQL-Trace:
Nachdem ein System eine Weile läuft, sollten keine teuren SQL-Statements auftreten, die zu Pufferladevorgängen gehören. Solche SQL-Statements sehen folgendermaßen aus:
- In der Where-Bedingung einer generisch-n-gepufferten Tabelle sind die ersten n Felder mit Gleichbedingungen angegeben. (Voll gepuffert = generisch-1: Mandt)
- Die SQL-Anweisung enthält eine Order-by-Bedingung, die alle Felder des Schlüssels enthält.
Optimieren von SQL-Anweisungen durch Sekundärindizes <back>
Teure SQL-Statements, bei denen das Verhältnis von „Buffer Gets“ zu Treffern schlecht ist können möglicherweise durch neue oder modifizierte Sekundärindizes verbessert werden.
- Bei SQL-Statements aus SAP-Standard-Programmen, nach einem passenden Hinweis suchen.
- Keine Sekundärindizes auf SAP-eigene Tabellen mit Bewegungsdaten -> Matchcodes usw.
- Bei kundeneigenen Programmen nach Möglichkeiten suchen, vorhandene Indizes zu nutzen. (Z.B. durch Ergänzung von Where-Bedingungen durch fehlende unselektive Felder oder durch alternative Zugriffspfade. Für die Logistikmodule s. Hinweise 185530, 187906 und 191492)
- Neue Indizes machen nur Sinn, wenn sie die Ergebnismenge einer Abfrage signifikant einschränken. (Treffermenge kleiner 5% der Tabelle.) Es müssen also selektive Felder verwendet werden.
- Je selektiver ein Feld, um so weiter muss es vorne im Index stehen.
- Ein Index sollte nur wenige Felder umfassen. Richtwert <= 4.
- Gelegentlich kann es erforderlich sein, auch nicht selektive Felder, wie den Mandanten aufzunehmen.
- Indizes sollten weitgehend disjunkt gehalten werden.
- Bei Tabellen, die häufig geändert werden, sind in der Regel mehr als 5 Indizes nicht empfehlenswert.
Die Anlage von Indizes zu großen Tabellen kann lange dauern. Während der Anlage wird die gesamte Tabelle gesperrt.
Keine Kommentare:
Kommentar veröffentlichen