com!online 2002 April

home *** CD-ROM | disk | FTP | other *** search

/ com!online 2002 April / comcd0402.iso / vollver / adabas / f_0001 / misc / x_wiz.txt < prev

Wrap

Text File | 1999-02-22 | 58.0 KB | 1,257 lines

23 ADABAS D Performanceanalyse und Tuning _______________________________________________________________ ____________ Jochen Hartmann, Tel. 030/390903-77 18.09.95 13:19 ADABAS D Performanceanalyse und Tuning x_wizard x_wiztrc x_wizbit Vorabversion Rel. 6.1.1 Nur fⁿr internen SAG-Gebrauch x_wizard - Engpa▀analyse der laufenden Adabas-Datenbank AUFRUF x_wizard [-t Zeitintervall] [-x] [-p|-a] [-b] [-s] [-D] [- L] [-k|-K] [-l Sprache] BESCHREIBUNG x_wizard versucht eine Analyse der Bottlenecks des aktuellen Datenbanklaufs. Grundlage bilden das DB- Monitoring sowie die Datenbankkonsole x_cons. Erkannte EngpΣsse werden in Textform ausgegeben, um Datenbankadministratoren einen schnellen ▄berblick ⁿber m÷gliche Ursachen von Performanceproblemen zu erm÷glichen1. Die Analyse kann entweder einmalig erfolgen oder ⁿber die Option -t in regelmΣ▀igen ZeitabstΣnden wiederholt werden. Der Aufruf von x_wizard sollte m÷glichst auf dem Datenbankserver erfolgen, da die DB-Konsole x_cons nicht remotefΣhig ist. Ist nur ein Remote-Aufruf m÷glich, kann lediglich eine Analyse der Monitoring-Daten vorgenommen werden. In diesem Fall darf die Option -x nicht genutzt werden. VORAUSSETZUNGEN - Adabas D ab Release 6.1.12 - Das Datenbankmonitoring mu▀ eingeschaltet sein3 (MONITOR ON, erfolgt bei Verwendung der Option -t automatisch, ansonsten mittels xquery -S adabas manuell einschalten). - Der Connect an die Datenbank erfolgt ⁿber den DEFAULT-Key in xuser. Ist kein XUSER-File vorhanden, mⁿssen die Connect- Parameter ⁿber die Shellvariable SQLOPT ⁿbergeben werden. OPTIONEN -t Zeitintervall RegelmΣ▀ige Auswertung nach Zeitintervall Sekunden. Die erste x_wizard- Ausgabe zeigt die Analyse fⁿr die Zeit seit Start des Datenbankmonitorings, alle weiteren Ausgaben beziehen sich auf das zurⁿckliegende Zeitintervall. Die Cache- Hitraten werden fⁿr jedes Intervall neu berechnet. -x ZusΣtzliche Auswertung der x_cons-Daten. Diese Option kann nur beim Aufruf von x_wizard auf dem Datenbankserver verwendet werden. -p Protokollierung der Ergebnisse in der Datei x_wizard.prt -a Protokollierung der Ergebnisse in der Datei x_wizard.prt im Append-Modus -b Protokollierung der Me▀daten (BinΣrformat) in der Datei x_wizard.bin zur spΣteren Auswertung durch x_wiztrc. -D Erzeugung von Protokollfiles yyyymmdd.wiz (Protokoll der Warnungstexte bei Option -p) bzw. yyyymmdd.wbi (Datenfile zur Verwendung durch x_wiztrc bei Option -b). Fⁿr jeden Tag werden neue Files angelegt. Existierende Files werden appended. -L Erzeugen eines Lockfiles x_wizard.lck im Adabas-Rundirectory. Fⁿr eine Serverdb kann genau ein x_wizard gelockt werden. -k Stoppt ein mit Lockfile gestartetes x_wizard (ohne Neustart). -K Stoppt ein mit Lockfile gestartetes x_wizard und startet x_wizard mit den ⁿbrigen Optionen neu. -s Keine Ausgabe auf stdout. -l Sprache Ausgabe der Warnungstexte in der Sprache Sprache. M÷gliche Werte fⁿr Sprache: e (englisch), d (deutsch, Default). BEMERKUNGEN Fⁿr eine routinemΣ▀ige ▄berwachung des Datenbankbetriebs in Produktivsystemen ist ein Interall von 15 Minuten ausreichend (-t 900), wobei die Protokollierung (-p) aktiviert werden sollte, um dem Adabas-Support einen ▄berblick ⁿber die DB-AktivitΣten zu erm÷glichen. Sollen hingegen gezielt EngpΣsse mit Hilfe des Tools x_wizbit gesucht werden, empfiehlt sich ein Me▀intervall von 30 Sekunden. Die erkannten EngpΣsse werden entsprechend ihrer Wichtigkeit klassifiziert (I : Info, W1 bis W3: Engpa▀warnungen leichten bis schweren Grades). Die Klassifizierung der Warnungen bezieht sich auf eingeschwungene Applikationen. Warnungen beim Hochfahren eines Systems k÷nnen in der Regel ignoriert werden. Nicht alle Ausgaben von x_wizard mⁿssen zwangslΣufig echte EngpΣsse als Ursache haben. So k÷nnen Tablescans in bestimmten Situationen sinnvoll sein, lange Laufzeiten von Kommandos bei gro▀en Datenmengen zwangslΣufig entstehen etc. . Insbesondere beim Verdacht auf schlechte Select- Strategien (Rows Read/Rows Qual) wird man um eine genauere Vtrace-Analyse nicht herumkommen (x_wizbit). Meldungstexte von x_wizard Niedrige Datacache Hitrate : <Prozentsatz> % <Anzahl> Zugriffe, <Anzahl> erfolgreich, <Anzahl> nicht erfolgreich Die Trefferquote beim Zugriff auf den Datenbankcache ist zu niedrig. Bei einer eingeschwungenen DB-Anwendung sollte die Datacache Hitrate nicht unter 99 % liegen, da ansonsten zu viele Daten physisch gelesen werden mⁿssen. Kurzzeitig kann es zu niedrigeren Hitraten kommen, falls z.B. Tabellen erstmals gelesen werden oder bei wiederholten Tablescans die Tabelle nicht in 10% des Datacaches pa▀t (nur bei DEFAULT_LRU=YES). Im Viertelstundenmittel sind Datacache-Hitraten unter 99% zu vermeiden. Aktion Neben einer Vergr÷▀erung des Datacaches (auf Paging-Gefahr im Betriebssystem achten) sollte die Ursache der hohen LeseaktivitΣten gesucht werden. HΣufig verursachen einzelne Kommandos einen hohen Anteil an der gesamten logischen und physischen LeseaktivitΣt. Eine Vergr÷▀erung des Caches verlagert die Last lediglich von der Platte auf die CPU, obwohl z.B. durch einen zusΣtzlichen Index aus einem leseintensiven Tablescan ein preiswerter Direktzugriff werden k÷nnte (s. x_wizbit) Niedrige Catalogcache Hitrate : <Prozentsatz> % <Anzahl> Zugriffe, <Anzahl> erfolgreich, <Anzahl> nicht erfolgreich Die Trefferquote beim Zugriff auf den Catalogcache, in dem die geparsten SQL-Kommandos verwaltet werden, ist zu niedrig. Bei einer eingeschwungenen DB-Anwendung sollte die Catalogcache Hitrate bei ca. 90% liegen. Werden neue Programmteile oder Programme gestartet, kann die Hitrate kurzfristig auf sehr kleine Werte sinken. Sie sollte im Viertelstundenmittel jedoch nicht unter 85% liegen. Aktion Die Gr÷▀e des Catalogcaches sollte ca. 100 Pages pro Datenbanksession betragen4, was mittels xparam anhand der Parameter MAXUSERTASKS und CATALOG_CACHE_PAGS ⁿberprⁿft werden sollte. Der Catalogcache wird von den aktiven DB-Sessions dynamisch vergr÷▀ert und beim Release wieder freigegeben. Die aktuell belegten Cachegr÷▀en k÷nnen mittels SHOW USER CONNECTED ermittelt werden. Sollten Sessions erheblich mehr als 100 Pages ben÷tigen, so empfiehlt sich mittelfristig eine entsprechende Vergr÷▀erung des Catalogcaches, falls das Memory des Rechners dies zulΣ▀t. Niedrige Convertercache Hitrate : <Prozentsatz> % <Anzahl> Zugriffe, <Anzahl> erfolgreich, <Anzahl> nicht erfolgreich Die Trefferquote beim Zugriff auf den Convertercache, in dem die Zuordnung von logischen zu physikalischen Datenpages verwaltet wird, ist zu niedrig. Bei einer eingeschwungenen DB- Anwendung sollte die Convertercache Hitrate bei mindestens 98% liegen. Da bei dem Zugiff auf Datenpages, die sich nicht im Datencache befinden, zunΣchst deren physische Position in den Datendevices im Konverter gesucht werden mu▀, kann es bei zu kleinem Convertercache hΣufiger zu zusΣtzlichen I/Os kommen. Aktion Die Gr÷▀e des Convertercaches sollte ⁿber den xparam-Parameter CONV_CACHE_PAGES vergr÷▀ert werden. Cache Verdraengungen: <Anzahl> Pages/sec Es findet eine VerdrΣngung von geΣnderten Pages aus dem Datencache auf Platte statt, da die von den Applikationen verwendeten Daten nicht vollstΣndig im Datencache gehalten werden k÷nnen. Bei ausreichendem Datencache wⁿrde das physische Schreiben bis zum nΣchsten Savepoint verz÷gert und dann asynchron erfolgen. CacheverdrΣngungen fⁿhren demgegenⁿber zu synchronem I/O und sollten m÷glichst vermieden werden. Bei lΣngeren LadelΣufen (Datenimport) kommt es allerdings fast zwangslΣufig zu VerdrΣngungserscheinungen, da das importierte Datenvolumen in der Regel die Gr÷▀e des Caches weit ⁿbersteigt. Aktion Vergr÷▀erung des Daten- (und ggf. auch des Converter-) caches. Insbesondere bei gr÷▀eren Datenimporten sollten die sog. Bufwriter fⁿr regelmΣ▀ige asynchrone Bufferflushs zwischen den Savepoints aktiviert werden5 (x_param-Parameter NUM_BUFREADER, BR_SLEEPTIME, BR_IF_IOCNT_LT). Fⁿr BR_SLEEPTIME und BR_IF_IOCNT_LT kann dies wΣhrend des laufenden Betriebs mittels x_cons $DBNAME putparam ... erfolgen. Hohe Lese-Rate (physisch): <Anzahl> Pages pro Kommando <Anzahl> Physical Reads , <Anzahl> Kommandos Die Anwendung enthΣlt Kommandos, die sehr viele physische Lesezugriffe auf die Datenbank absetzen, da die angeforderten Daten nicht im Datencache gefunden werden. Wird auf eine Tabelle zum ersten Mal zugegriffen oder wurde sie lΣngere Zeit nicht mehr benutzt und daher aus dem Datencache verdrΣngt, so ist dieses Verhalten unproblematisch. Aktion LΣ▀t sich die LeseaktivitΣt nicht aus dem erstmaligen Zugriff auf eine Tabelle erklΣren, sollte die Gr÷▀e des Datencaches und die Datacache Hitrate ⁿberprⁿft werden. Au▀erdem ist m÷glichst auszuschlie▀en, da▀ die von der Anwendung abgesetzten SQL- Kommandos erheblich mehr Daten lesen, als eigentlich zur Abarbeitung ben÷tigt werden (Tablescans oder ungⁿnstige Select- Strategien, ggf. Vtrace auswerten). Bei Tablescans mu▀ beachtet werden, da▀ bei DEFAULT_LRU=YES (xparam) nur 10% des Caches fⁿr die Zwischenspeicherung der Tabelle genutzt wird, so da▀ die Tabelle eventuell nicht komplett im Cache gehalten werden kann und beim nΣchsten Scan erneut physisch gelesen werden mu▀. Hohe Lese-Aktivitaet (physisch), <Anzahl> Pages/sec Es erfolgen sehr viele physische Lesezugriffe auf die Datenbank, da die von den Applikationen angeforderten Daten nicht im Datencache gefunden werden. Wird auf Tabellen zum ersten Mal zugegriffen oder wurden sie lΣngere Zeit nicht mehr benutzt und daher aus dem Datencache verdrΣngt, so ist dieses Verhalten unproblematisch. Aktion LΣ▀t sich die LeseaktivitΣt nicht aus dem erstmaligen Zugriff auf Tabellen erklΣren, sollte die Datacache Hitrate ⁿberprⁿft und der Datencache gegebenenfalls vergr÷▀ert werden. Au▀erdem ist m÷glichst auszuschlie▀en, da▀ die von der Anwendung abgesetzten SQL-Kommandos erheblich mehr Daten lesen, als eigentlich zur Abarbeitung ben÷tigt werden (Tablescans oder ungⁿnstige Select-Strategien, ggf. Vtrace auswerten). Bei Tablescans mu▀ beachtet werden, da▀ bei DEFAULT_LRU=YES (xparam) nur 10% des Caches fⁿr die Zwischenspeicherung der Tabelle genutzt wird, so da▀ die Tabelle eventuell nicht komplett im Cache gehalten werden kann und beim nΣchsten Scan erneut physisch gelesen werden mu▀. Hohe Schreib-Aktivitaet (physisch), <Anzahl> Pages/sec Es erfolgen sehr viele physische Schreibzugriffe auf die Datendevices, da die von den Applikationen verwendeten Daten nicht vollstΣndig im Datencache gehalten werden k÷nnen. Daraufhin findet eine VerdrΣngung von Pages aus dem Cache auf Platte statt. Bei lΣngeren LadelΣufen (Datenimport) kommt es fast zwangslΣufig zu VerdrΣngungserscheinungen, da das importierte Datenvolumen in der Regel die Gr÷▀e des Caches weit ⁿbersteigt. In regelmΣ▀igen AbstΣnden (Default: 10 Min.) kommt es zudem beim sog. Savepoint zu einem Flush des Datencaches, bei dem alle geΣnderten Pages aus dem Cache auf Platte geschrieben werden, um so einen konsistenten Datenbankzustand auf den Devices zu erzeugen. Zu diesem Zeitpunkt steigt die I/O- AktivitΣt stark an (Plattenauslastung nahe 100%), ohne da▀ es sich dabei um einen echten Engpa▀ handelt. Im Normalbetrieb sollten au▀erhalb der Savepoints keine nennenswerten SchreibaktivitΣten gemessen werden k÷nnen. Aktion Werden im Normalbetrieb hohe SchreibaktivitΣten beobachtet, sollte zunΣchst ausgeschlossen werden, da▀ wΣhrend des (ggf. zu kurzen) Messintervalls ein Savepoint aktiv war. Ansonsten kann nur eine Vergr÷▀erung des Datencaches die Notwendigkeit zu Cache-VerdrΣngungen verhindern. Hohe Lese-Rate (virtuell) <Anzahl> Pages pro Kommando <Anzahl> Virtual Reads , <Kommandozahl> Kommandos Die Anwendung enthΣlt Kommandos, die zu sehr vielen logischen Lesezugriffen auf den Datenbankcache fⁿhren. Ob es sich dabei um ein Problem handelt, kann nur anhand des Anwendungsprofils entschieden werden. EnthΣlt eine Anwendung z.B. zahlreiche Massenselects mit relativ unspezifischen Where-Bedingungen, kommt es schnell zu einer gro▀en Anzahl virtueller Reads. Aktion Es sollte ⁿberprⁿft werden, ob die von der Anwendung abgesetzten SQL-Kommandos nicht erheblich mehr Daten lesen, als eigentlich zur Abarbeitung ben÷tigt werden (z.B. durch Tablescans oder ungⁿnstige Select-Strategien, ggf. Vtrace mittels x_wizbit auswerten). Hohe Parse-Aktivitaet, <Anzahl> Prepares pro Kommando <Anzahl> Kommandos (Executes), <Anzahl> Prepares Die Anzahl von ParsevorgΣngen ist bezogen auf die Gesamtzahl der ausgefⁿhrten Kommandos sehr hoch. Vor der erstmaligen Ausfⁿhrung eines SQL-Kommandos mu▀ zunΣchst der SQL- Kommandostring analysiert (geparst) werden, wobei Adabas u.a. die m÷glichen Zugriffsstrategien ermittelt und das Kommando in kompakter Form in der Datenbank ablegt. Bei jeder weiteren Ausfⁿhrung wird nur noch auf diese internen Informationen zugegriffen und das Kommando direkt ausgefⁿhrt (executed). Wurde die Anwendung mittels statischem SQL und Adabas- Precompiler erstellt, so sorgt der Adabas-Precompiler dafⁿr, da▀ der Parsevorgang pro Kommando nur ein einziges Mal stattfindet. Bei Verwendung von dynamischem SQL oder des Call- Interfaces ist der Entwickler selbst fⁿr die Verwaltung der Parse- bzw. ExecuteauftrΣge verantwortlich. Hohe Parse- AktivitΣten im laufenden Betrieb k÷nnen daher auf die fehlende Implementierung eines Cursor-Caches hindeuten. Beim erstmaligen Start von Programmen oder Programmteilen ist eine hohe ParseaktivitΣt normal. Aktion Von Datenbankseite ist keine spezifische Aktion m÷glich. Niedrige Hitrate bei Tablescans : <Prozentsatz>% <Anzahl> Scans, <Anzahl> Rows Read, <Anzahl> Rows Qual Bei Tablescans ist das VerhΣltnis zwischen gelesenen und gefundenen (qualifizierten) SΣtzen schlecht. Dies deutet in fast allen FΣllen auf eine schlechte Select-Strategie hin, die entweder durch die Anwendung (fehlende oder unzureichende Indexe etc.) oder durch ein Problem bei der kostenbasierenden Select-Optimierung des DB-Kerns verursacht wird. Das Durchscannen von gro▀en Tabellen kann die Performance des Gesamtsystems wegen der zahlreichen negativen Auswirkungen (I/O, ▄berschreiben des Datacaches, CPU-Belastung etc.) gravierend vermindern. Aktion ZunΣchst sollte probiert werden, ob durch einen Neuaufbau der internen Datenbankstatistiken der Adabas-Optimierer eine geeignetere Select-Strategie findet und Tablescans dadurch vermieden werden. Ein Statistikupdate kann entweder mittels UPDATE STAT * bzw. UPDATE STAT <tablename> ⁿber xquery o.Σ. erfolgen oder aus der Betriebssystem-Kommandozeile mit Hilfe des Tools updcol. Da eventuell sehr gro▀e Datenmengen untersucht werden mⁿssen, k÷nnen diese Kommandos sehr lange laufen und sollten (auch wegen m÷glicher Sperrkonflikte) m÷glichst nicht wΣhrend aktiver Anwendungen ausgefⁿhrt werden (stopsap r3 - Update Statistics - startsap r3). Fⁿhrt dies nicht zum Erfolg, sollte das Kommando gesucht werden, das den Tablescan ausl÷st. Dies geschieht entweder durch Einschalten geeigneter Traces (Precompiler-Trace durch SQLOPT=-X, SQL-Trace in R/3) und einer anschlie▀enden Suche nach langlaufenden Kommandos, bei denen die vom Optimierer angewandte Select-Strategie mit Hilfe des EXPLAIN-Kommandos ⁿberprⁿft wird, oder durch Anwendung des Tools x_wizbit auf den Datenbanktrace. Niedrige Hitrate bei Zugriffen via <Optimizer-Strategie>: <Prozentsatz> % <Anzahl> Zugriffe, <Anzahl> Rows Read, <Anzahl> Rows Qual Bei der Anwendung einer bestimmten Zugriffsstrategie durch den Adabas-Optimizer ist das VerhΣltnis zwischen gelesenen und gefundenen (qualifizierten) SΣtzen schlecht. Es gilt prinzipiell das unter Niedrige Hitrate bei Tablescans gesagte. Aktion ZunΣchst sollte probiert werden, ob durch einen Neuaufbau der internen Datenbankstatistiken der Adabas-Optimierer eine geeignetere Select-Strategie findet. Ein Statistikupdate kann entweder mittels UPDATE STAT * bzw. UPDATE STAT <tablename> ⁿber xquery oder aus der Betriebssystem-Kommandozeile durch den Aufruf des Tools updcol erfolgen. Da eventuell sehr gro▀e Datenmengen untersucht werden mⁿssen, k÷nnen diese Kommandos sehr lange laufen und sollten (auch wegen m÷glicher Sperrkonflikte) m÷glichst nicht wΣhrend aktiver Anwendungen ausgefⁿhrt werden (stopsap r3 - Update Statistics - startsap r3). Fⁿhrt dies nicht zum Erfolg, sollte das Kommando gesucht werden, das die ungⁿnstige Select-Strategie ausl÷st. Dies geschieht entweder durch Einschalten geeigneter Traces (Precompiler-Trace durch SQLOPT=-X, SQL-Trace in R/3) und einer anschlie▀enden Suche nach langlaufenden Kommandos, bei denen die vom Optimierer angewandte Select-Strategie mit Hilfe des EXPLAIN-Kommandos ⁿberprⁿft wird, oder durch Anwendung des Tools x_wizbit auf den Datenbanktrace. Niedrige Hitrate bei <Deletes/Updates>: <Prozentsatz> % <Anzahl> Rows Read, <Anzahl> Rows Qual Bei Deletes bzw. Updates ist das VerhΣltnis zwischen gelesenen und geΣnderten SΣtzen schlecht. Bevor bei Updates und Deletes SΣtze geΣndert bzw. gel÷scht werden k÷nnen, mⁿssen diese zuvor in der entsprechenden Tabelle lokalisiert werden. Dabei werden die gleichen Zugriffsstrategien wie beim Select verwendet. Aktion ZunΣchst sollte probiert werden, ob durch einen Neuaufbau der internen Datenbankstatistiken der Adabas-Optimierer eine geeignetere Select-Strategie findet. Ein Statistikupdate kann entweder mittels UPDATE STAT * bzw. UPDATE STAT <tablename> ⁿber xquery oder aus der Betriebssystem-Kommandozeile durch den Aufruf des Tools updcol erfolgen. Da eventuell sehr gro▀e Datenmengen untersucht werden mⁿssen, k÷nnen diese Kommandos sehr lange laufen und sollten (auch wegen m÷glicher Sperrkonflikte) m÷glichst nicht wΣhrend aktiver Anwendungen ausgefⁿhrt werden (stopsap r3 - Update Statistics - startsap r3). Fⁿhrt dies nicht zum Erfolg, sollte das Kommando gesucht werden, das die schlechte Hitrate ausl÷st. Dies geschieht entweder durch Einschalten geeigneter Traces (Precompiler-Trace durch SQLOPT=-X, SQL-Trace in R/3) und einer anschlie▀enden Suche nach langlaufenden Update/Delete-Kommandos, oder durch Anwendung des Tools x_wizbit auf den Datenbanktrace. æPhysical Temp Page WritesÆ hoch : <Pages> pro Kommando Eventuell Aufbau grosser Ergebnismengen Beim Erzeugen temporΣrer Datenbankpages zum Aufbau von (Zwischen-)Ergebnismengen, z.B. bei Joins, ORDER BY-Kommandos etc. reicht der Datencache zur Aufnahme der Temp-Pages nicht aus, so da▀ eine Auslagerung auf Platte erfolgen mu▀. Da diese Pages im Rahmen der weiteren Verarbeitung des SQL-Kommandos wieder eingelesen werden mⁿssen, sollte das physische Schreiben temporΣrer Pages vermieden werden. HΣufig sind Probleme im Anwendungsdesign (fehlende Indexe etc.) oder im Adabas- Optimizer die Ursache fⁿr den Aufbau von Ergebnismengen. Der Aufbau gro▀er Ergebnismengen kann die Performance des Gesamtsystems wegen der zahlreichen negativen Auswirkungen (I/O, ▄berschreiben des Datacaches, CPU-Belastung etc.) gravierend vermindern. Aktion ZunΣchst sollte probiert werden, ob durch einen Neuaufbau der internen Datenbankstatistiken der Adabas-Optimierer eine geeignetere Select-Strategie findet und der Aufbau gro▀er Ergebnismengen damit vermieden wird. Ein Statistikupdate kann entweder mittels UPDATE STAT * bzw. UPDATE STAT <tablename> ⁿber xquery o.Σ. oder aus der Betriebssystem-Kommandozeile mit Hilfe des Tools updcol erfolgen. Da eventuell sehr gro▀e Datenmengen durchsucht werden mⁿssen, k÷nnen diese Kommandos sehr lange dauern und sollten (auch wegen m÷glicher Sperrkonflikte) m÷glichst nicht bei laufender Anwendung ausgefⁿhrt werden. Fⁿhrt dies nicht zum Erfolg, mu▀ versucht werden, das Kommando zu finden, das den Ergebnismengenaufbau ausl÷st. Dies erfolgt am einfachsten durch Einschalten geeigneter Traces (Precompiler- Trace durch SQLOPT=-X, SQL-Trace in R/3) und einer anschlie▀enden Suche nach langlaufenden Kommandos, bei denen die vom Optimierer angewandte Select-Strategie mit Hilfe des EXPLAIN-Kommandos ⁿberprⁿft wird (Result is copied). Hohe Kollisionsrate auf SQL-Sperren, <mittl. Anzahl> pro Schreibtransaktion <Anzahl> Schreibtransaktionen, <Anzahl> SQL-Kollisionen Es kommt bei einem hohen Prozentsatz von Schreibtransaktionen6 zu Sperren auf SQL-Objekten (Zeilen, Tabellen). Dadurch entsteht in der Anwendung ein Wartezustand, bis die sperrende Anwendungstask die Sperre mittels COMMIT freigibt. In der Regel liegt das Problem eher im Anwendungsdesign als in der Datenbank, doch kann es bei sehr hohen Sperrzahlen zu einem CPU- Bottleneck auf der Adabas-Lockliste kommen. Adabas versucht, sperrende Tasks innerhalb des Datenbankkerns mit h÷herer PrioritΣt auszufⁿhren, falls diese Sperren von anderen Sessions angefordert werden (die sich dann im Vwait befinden), um so den Aufbau von Warteschlangen vor SQL-Sperrobjekten zu vermeiden. Aktion Die Anwendung sollte daraufhin ⁿberprⁿft werden, ob sie sich fⁿr den Isolation Level 0 (dirty read) eignet, um so Lesesperren zu vermeiden (SAP R/3 lΣuft bereits im Isolation Level 0). Ferner sollte ⁿberprⁿft werden, ob der Zeitraum zwischen dem Ziehen der Sperre und dem Commit verringert werden kann (keine Sperren wΣhrend Dialog-Sessions halten!). Treten im Multiuser-Betrieb hΣufiger hohe Kollisionsraten auf, kann in xparam der Parameter PRIO_TASK auf den Wert 203 (bei MAXCPU > 1 auf 207) gesetzt werden, wodurch comittende Transaktionen priorisiert werden. Ein weiterer Engpa▀ kann im Log-Schreiben bestehen, da erst nach erfolgreichem physischem Log-I/O des Commits die SQL- Sperren der entsprechenden Transaktion freigegeben werden k÷nnen. Daher ist es sinnvoll, den Log auf m÷glich schnelle Devices zu legen. Anhand der maximalen LΣnge der Log Queue (Monitoring) kann festgestellt werden, ob es beim Schreiben des Logs zeitweise zu EngpΣssen kommt. Im R/3-Umfeld ist ein drastischer Anstieg der SQL-Kollisionen zu beobachten, wenn R/3-Applikationsserver CPU- oder Memory- bound werden. Insbesondere steigen in diesem Fall die Kollisionen auf den Tabellen NRIV und GLT0, da die Applikation die sperraufl÷senden Commits nicht schnell genug an die Datenbank schickt. Bei hohen Kollisionsraten sollte daher in jedem Fall ⁿberprⁿft werden, ob R/3 nicht in einen Engpa▀ gelaufen ist (wait time mittels Transaktion /nst03 ⁿberprⁿfen). Hohe Wartezeiten bei SQL-Kollisionen: <Dauer> Sek pro Vwait (<Anzahl> Vwaits) Bei Kollisionen auf SQL-Objekten ist die Wartezeit auf die Freigabe der SQL-Sperre sehr hoch. Eine SQL-Sperre wird von der sperrenden Applikation durch das Commit freigegeben. Daher liegt die Ursache fⁿr hohe Wartezeiten hΣufig in zu langen Transaktionen, bei denen von der Applikation eine SQL-Sperre ⁿber einen lΣngeren Zeitraum gehalten wird. Daneben treten lange Wartezeiten auch dann auf, wenn viele Applikationen das gleiche Objekt sperren wollen, da es in diesem Fall zu einer Queue vor der entsprechenden SQL-Sperre kommen kann. Infolge einer Sequentialisierung wird diese Warteschlange hΣufig nur langsam abgebaut (insbesondere bei Multi-CPU-Systemen). Adabas versucht daher, sperrende Tasks innerhalb des Datenbankkerns mit h÷herer PrioritΣt auszufⁿhren, falls deren Sperren von anderen Sessions angefordert werden (die sich dann im Vwait befinden), um so den Aufbau von Warteschlangen vor SQL- Sperrobjekten zu vermeiden. Die aktuelle Sperrsituation kann im laufenden Betrieb mittels SHOW STATISTICS LOCK abgefragt werden. Aktion Die Anwendung sollte daraufhin ⁿberprⁿft werden, ob sie sich fⁿr den Isolation Level 0 (dirty read) eignet, um so Lesesperren zu vermeiden (SAP R/3 lΣuft bereits im Isolation Level 0). Ferner sollte ⁿberprⁿft werden, ob der Zeitraum zwischen dem Ziehen der Sperre und dem Commit verringert werden kann (keine Sperren wΣhrend Dialog-Sessions halten!). Beim Autreten von Warteschlangen vor SQL-Objekten sollte die Applikation daraufhin ⁿberprⁿft werden, ob nicht z.B. durch einen Splitt von Tabellen gleichzeitige Locks auf dieselbe Zeile vermieden werden k÷nnen. In xparam kann der Parameter PRIO_TASK auf den Wert 207 gesetzt werden, wodurch zusΣtzlich comittende Transaktionen priorisiert werden. Im R/3-Umfeld ist ein drastischer Anstieg der SQL-Kollisionen zu beobachten, wenn R/3-Applikationsserver CPU- oder Memory- bound werden. Insbesondere steigen in diesem Fall die Kollisionen auf den Tabellen NRIV und GLT0 an, da R/3 die sperraufl÷senden Commits nicht schnell genug an die Datenbank schickt. Bei hohen Kollisionsraten sollte daher in jedem Fall ⁿberprⁿft werden, ob R/3 nicht in einen Engpa▀ gelaufen ist (Transaktion /nst03). Warteschlange bei SQL-Kollisionen: Coll/Vwait = <VerhΣltnis> <Anzahl> Lock List Collisions, <Anzahl> Vwaits Es treten Warteschlangen vor SQL-Sperren auf, d.h. es wartet mehr als eine Task auf die Freigabe dieser Sperre. Eine SQL- Sperre wird von der sperrenden Applikation durch das Commit freigegeben. Daher liegt die Ursache fⁿr Queuebildungen hΣufig in zu langen Transaktionen, bei denen von der Applikation eine SQL-Sperre ⁿber einen lΣngeren Zeitraum gehalten wird. Infolge von Sequentialisierungserscheinungen werden Warteschlangen hΣufig nur langsam abgebaut (insbesondere bei Multi-CPU- Systemen). Adabas versucht daher, sperrende Tasks innerhalb des Datenbankkerns mit h÷herer PrioritΣt auszufⁿhren, falls deren Sperren von anderen Sessions angefordert werden (die sich dann im Vwait befinden), um damit den Aufbau von Warteschlangen vor SQL-Sperrobjekten zu vermeiden. Die aktuelle Sperrsituation kann im laufenden Betrieb mittels SHOW STATISTICS LOCK abgefragt werden. Aktion Die Anwendung sollte daraufhin ⁿberprⁿft werden, ob sie sich fⁿr den Isolation Level 0 (dirty read) eignet, um so Lesesperren zu vermeiden (SAP R/3 lΣuft bereits im Isolation Level 0). Ferner sollte ⁿberprⁿft werden, ob der Zeitraum zwischen dem Ziehen der Sperre und dem Commit verringert werden kann (keine Sperren wΣhrend Dialog-Sessions halten!). Die Anwendungslogik sollte m÷glichst so geΣndert werden, da▀ gleichzeitige Locks auf dieselbe Zeile vermieden werden. In xparam kann der Parameter PRIO_TASK auf den Wert 203 (bei MAXCPU >1 auf 207) gesetzt werden, wodurch zusΣtzlich comittende Transaktionen priorisiert werden. Im R/3-Umfeld ist ein drastischer Anstieg der SQL-Kollisionen zu beobachten, wenn R/3-Applikationsserver CPU- oder Memory- bound werden. Insbesondere steigen in diesem Fall die Kollisionen auf den Tabellen NRIV und GLT0 an, da R/3 die sperraufl÷senden Commits nicht schnell genug an die Datenbank schickt. Bei hohen Kollisionsraten sollte daher in jedem Fall ⁿberprⁿft werden, ob R/3 nicht in einen Engpa▀ gelaufen ist (Transaktion /nst03). Lock Eskalationen (<Anzahl> Tabellensperren) Die Anzahl von SQL-Satzsperren auf eine Tabelle durch eine Transaktion hat einen Schwellwert ⁿberschritten, so da▀ die Einzelsatzsperren in eine Tabellensperre umgewandelt wurden. In der Regel werden SQL-Sperren auf einzelne SΣtze einer Tabelle gesetzt. Da die Verwaltung von Einzelsatzsperren mit zunehmender Anzahl teurer wird und nur eine beschrΣnkte Zahl von Sperren in der DB-Lockliste verwaltet werden k÷nnen, wird ab einem konfigurierbaren Schwellwert versucht, die Tabelle exklusiv fⁿr die entsprechende Transaktion zu sperren. Als Nachteil mu▀ dabei in Kauf genommen werden, da▀ bis zum Commit andere Transaktionen in dieser Tabelle keine SΣtze mehr sperren k÷nnen. Aktion Die maximale Anzahl von Einzelsatzsperren, die von der Datenbank verwaltet werden k÷nnen, kann ⁿber den xparam- Parameter MAXLOCKS konfiguriert werden. Die Eskalation wird versucht, wenn eine Task mehr als 0,1*MAXLOCKS Einzelsatzsperren auf einer Tabelle hΣlt. Bei hΣufigerem Auftreten von unerwⁿnschten Eskalationen sollte der Parameterwert erh÷ht werden (max. 2,3 Mio.). Ob Lockeskalationen zum Problem werden, hΣngt sehr stark von der jeweiligen Anwendung ab. Treten Lockeskalationen auf, sollte die Anwendung daraufhin untersucht werden, ob ─nderungstransaktionen, die sehr viele SΣtze sperren, nicht durch zwischenzeitliche Commits entzerrt werden k÷nnen. In R/3 kann es insbesondere bei Batch Inputs zu Eskalationen auf den Tabellen APQD und APQI kommen. Log Queue Overflows (<Anzahl>), Parameter æLOG_QUEUE_PAGESÆ (<Pagezahl>) zu klein Die Queue zur Aufnahme von LogeintrΣgen ist ⁿbergelaufen. Beim Schreiben von LogeintrΣgen durch ─nderungstransaktionen werden die LogeintrΣge zunΣchst in einer Queue zwischengespeichert, bevor sie vom sog. Logwriter auf das Logdevice geschrieben werden. In der Regel besteht diese Queue nur aus einer einzigen Page, doch kann es insbesondere bei Massenkommandos (Massendeletes, Array-Inserts etc.) vorkommen, da▀ kurzfristig wesentlich mehr LogeintrΣge erzeugt werden, als gleichzeitig physisch auf die Platte geschrieben werden k÷nnen. Kommt es zum ▄berlauf der Log Queue, so k÷nnen keinerlei LogauftrΣge mehr angenommen werden, was innerhalb kⁿrzester Zeit zu zahlreichen DB-internen Wartesituationen (Vsuspend) fⁿhrt. Da Transaktionen, die LogeintrΣge schreiben, SQL-Sperren halten, werden damit auch andere Transaktionen behindert. Aktion Der xparam-Parameter LOG_QUEUE_PAGES sollte erh÷ht werden (Max. 200). Au▀erdem sollte ⁿberprⁿft werden, ob die Logdevices nicht auf schnellere Platten gelegt werden k÷nnen, um damit das physische Log-I/O zu beschleunigen. æLog Queue PagesÆ zu klein : Total <Pages> , Max. Used <Pages> Die Queue zur Aufnahme von LogeintrΣgen ist vermutlich zu klein. Beim Schreiben von LogeintrΣgen durch ─nderungstransaktionen werden die LogeintrΣge zunΣchst in einer Queue zwischengespeichert, bevor sie vom sog. Logwriter auf das Logdevice geschrieben werden. In der Regel besteht diese Queue nur aus einer einzigen Page, doch kann es insbesondere bei Massenkommandos (Massendeletes, Array-Inserts etc.) vorkommen, da▀ kurzfristig wesentlich mehr LogeintrΣge erzeugt werden, als gleichzeitig physisch auf die Platte geschrieben werden k÷nnen. Kommt es zum ▄berlauf der Log Queue, so k÷nnen keinerlei LogauftrΣge mehr angenommen werden, was innerhalb kⁿrzester Zeit zu zahlreichen DB-internen Wartesituationen (Vsuspend) fⁿhrt. Da Transaktionen, die LogeintrΣge schreiben, SQL-Sperren halten, werden damit auch andere Transaktionen behindert. Aktion Obwohl es bisher noch nicht zu ▄berlΣufen der Log-Queue gekommen ist, sollte mittelfristig der xparam-Parameter LOG_QUEUE_PAGES erh÷ht werden. Au▀erdem sollte ⁿberprⁿft werden, ob die Logdevices nicht auf schnellere Platten gelegt werden k÷nnen, um damit das physische Log-I/O zu beschleunigen. Hohe Log-Aktivitaet, <Pages> Pages/sec Die Anzahl der pro Zeiteinheit geschriebenen Logpages liegt sehr hoch. Je nach LeistungsfΣhigkeit der aktuellen Logplatten besteht die Gefahr, da▀ das physische Schreiben des Logs zum Engpa▀ wird. Da zu jedem Commit auch bei nicht gefⁿllter 4KB- Logpage diese auf Platte geschrieben werden mu▀, kann es bei vielen kurzen ─nderungstransaktionen vorkommen, da▀ eine Logpage mehrmals hintereinander physisch geschrieben wird. In einem Multiusersystem wird von Adabas versucht, die Commits mehrerer Anwendungstasks zu sog. Group Commits zusammenzufassen. Aktion Falls die gemessene I/O-Rate an der Leistungsgrenze der Logplatten liegt, sollte ⁿber den Wechsel des Logs auf schnellere Platten nachgedacht werden. Bei Anwendungsprogrammen mit sehr vielen kurzen parallelen Schreibtransaktionen kann versucht werden, die Anzahl der Group Commits ⁿber den xparam- Parameter DELAY_LOGWRITER=YES zu erh÷hen. Wegen der relativ kleinen Zahl von Datenbanksessions und der besonderen Art des R/3-internen Dispatchings ist dies fⁿr SAP R/3 jedoch nicht ratsam. Lange Schreibtransaktionen: <Anzahl> Log Pages pro Transaktion <Anzahl>7 Schreibtransaktionen, <Anzahl> Log Pages Die von der Applikation abgesetzten Schreibtransaktionen sind sehr lang und fⁿhren zu sehr vielen physischen SchreibvorgΣngen auf dem Log. Bei batchartigen Anwendungen ist dieses Verhalten unproblematisch. Lange Schreibtransaktionen k÷nnen jedoch dann zu EngpΣssen werden, wenn andere Sessions auf SQL-Objekte (Zeilen, Tabellen) zugreifen mⁿssen, die von der langen Schreibtransaktion gesperrt werden. Au▀erdem kann es durch sehr lange Transaktionen zu einer Verz÷gerung des sog. Checkpoints kommen, da zum Checkpointzeitpunkt das Commit aller offenen Schreibtransaktionen abgewartet werden mu▀. Da bis zum Ende des Checkpoints keine neuen Schreibtransaktionen zugelassen werden, fⁿhrt dies fast zwangslΣufig zu einem zeitweisen Stillstand des Datenbankbetriebs (alle Tasks im Status Vwait). Ob ein Checkpoint geschrieben wird, lΣ▀t sich anhand des Kommandos SHOW LOCK CONFIG aus xquery o.Σ. feststellen (Ausgabe: CHECKPOINT WANTED TRUE) Aktion Keine Einflu▀m÷glichkeit von DB-Seite. Bei hΣufigeren Verz÷gerungen infolge Checkpoints sollten die Logsegmente vergr÷▀ert werden, da ein Checkpoint bei jedem Abschlu▀ eines Logsegmentes geschrieben wird. Treten langlaufende Transaktionen bei Dialogapplikationen auf, so sollte untersucht werden, ob die lange Transaktion nicht durch zusΣtzliche Commits entzerrt werden kann. Hohe Kollisionsrate auf <Name>-Region: <Prozentsatz> % <Anzahl> Zugriffe (von insges. <Anzahl>), <Anzahl> Kollisionen Die Kollisionsrate beim Zugriff auf geschⁿtzte Bereiche im Memory des Adabas-Kernels ist sehr hoch. Zugriffe auf kritische Bereiche im von mehreren Tasks gemeinsam genutzten Memory des Adabas-Datenbankkernels werden durch sog. Regions geschⁿtzt. Durch die exklusive Reservierung einer Region durch Datenbanktasks wird u.a. verhindert, da▀ gleichzeitig mehrere DB-Prozesse/Threads eine globale Speicherstelle manipulieren. Wird fⁿr Adabas nur ein Prozessor verwendet (x_param-Parameter MAXCPU=1), so kann es aufgrund des sog. internen Taskings praktisch nie zu Kollisionen auf Regions kommen (Ausnahme: parallele Connects, Savepoint). Kommt es im Multi-CPU-Betrieb zu hohen Kollisionsraten auf Regions, so besteht die Gefahr der Sequentialisierung des gesamten DB-Betriebs auf den Regionzugriffen. Die Nutzung zusΣtzlicher CPUs kann dann aufgrund der zusΣtzlichen SynchronisationsaufwΣnde sogar zu einem Performancerⁿckgang fⁿhren. Aktion Handlungsbedarf besteht bei Kollisionsraten von mehr als 10%. Generell steigt die Kollisionswahrscheinlichkeit mit wachsender Anzahl von UKPs (x_param-Parameter MAXCPU). Es sollte daher geprⁿft werden, ob bei Multiprozessorsystemen die Datenbank die Applikationsanforderungen auch mit weniger genutzten CPUs befriedigen kann. Im R/3-Umfeld liegt das VerhΣltnis des CPU- Verbrauchs zwischen Datenbank und R/3 bei ca. 1:4; auf einer 8- CPU-Maschine reichen daher i.d.R. zwei CPUs fⁿr Adabas aus. Entsprechende Rechnungen lassen sich auch fⁿr Client-Server Architekturen anstellen. Treten in Multiprozessor-Zentralsystemen hohe Region- Kollisionsraten auf, so sollte ⁿberprⁿft werden, ob die Maschine CPU-bound ist und daher die UKPs durch die Applikation blockiert werden. In diesem Fall sollten diejenigen UKPs, die Usertasks enthalten, vom Betriebssystem real time priority erhalten. Fⁿr HP lΣ▀t sich dies durch den x_param-Parameter REAL_TIME_PRIORITY=<0 ... 127> erreichen. Dabei mu▀ jedoch unbedingt sichergestellt sein, da▀ MAXPU um mindestens eins kleiner als die Anzahl realer CPUs ist. ZusΣtzliche Ma▀nahmen: ╖ DATAn-, SPLITTn-, TREEn-Region: Die Segmentierung des Datacaches kann mit den xparam-Parametern DATA_CACHE_REGIONS, SPLITT_REGIONS, TREE_REGIONS erh÷ht werden, wodurch die Kollisionswahrscheinlichkeiten sinken. Gleichzeitig sollte (mu▀ aber nicht) der Datacache (DATA_CACHE_PAGES) etwas vergr÷▀ert werden, damit die Subcaches nicht zu klein werden. Problematisch ist, wenn die Kollisionsrate nur auf einer Subregion der DATA-, SPLITT- oder TREE-Strukturen hoch liegt. In diesem Fall arbeiten mehrere Anwendungen offenbar parallel auf der gleichen Page oder zumindest hochfrequent auf der gleichen Tabelle (Rootpage). Hier kann nur die ─nderung in der Applikationslogik eine Verbesserung bringen. ╖ LOCK -Region: Die Kollisionswahrscheinlichkeit auf der LOCK-Region steigt mit steigender Zahl von SQL-SperreintrΣgen in der Lockliste. Eine Verringerung der Sperrzahl fⁿhrt in der Regel zu einer drastischen Reduktion der Region-Kollisionen. M÷gliche Ma▀nahmen in der Anwendung: Isolation Level 0, kurze Transaktionen, Tabellen- statt Zeilensperren. M÷gliche Ma▀nahmen in xparam: Parameter PRIO_TASK=203 bei einem UKP bzw. PRIO_TASK=207 bei mehreren UKPs (d.h. MAXCPU > 1). ╖ TRACE-, BUFWRTR -Region: Vtrace immer nur vorⁿbergehend zur Lokalisierung eines DB- Problems einschalten. Hohe TAS-Kollisionsrate, <Anzahl> pro Regionzugriff <Anzahl> TAS-Kollisionen, <Anzahl> Regionzugriffe Die Kollisionsrate beim Zugriff auf Adabas-interne Semaphoren im Umfeld von Regionzugriffen (s.o.) ist sehr hoch. Bei korrekter Parameterisierung ist dieses PhΣnomen nur bei Multi- CPU-Maschinen und hohen CPU- bzw. UKP-Zahlen (x_param Parameter MAXCPU > 4) zu beobachten. Aktion Die TAS-Kollisionswahrscheinlichkeit steigt mit wachsender Anzahl von UKPs (x_param-Parameter MAXCPU). Es sollte daher geprⁿft werden, ob bei Multiprozessorsystemen die Datenbank die Applikationsanforderungen auch mit weniger genutzten CPUs befriedigen kann. Im R/3-Umfeld liegt das VerhΣltnis des CPU- Verbrauchs zwischen Datenbank und R/3 bei ca. 1:4; bei einer 8- CPU-Maschine reichen daher i.d.R. zwei CPUs fⁿr Adabas aus. Entsprechende Rechnungen lassen sich auch fⁿr Client-Server Architekturen anstellen. Sollte die Datenbank auf einem reinen Datenbankserver laufen (Client-Server), so sollte ab vier CPUs die Anzahl der UKPs um mindestens 1 kleiner sein als die Anzahl der CPUs. Falls weiterhin TAS-Kollisionen auftreten, sollte der x_param- Parameter REG_DIRTY_READ auf YES gesetzt werden. Treten in Multiprozessor-Zentralsystemen hohe TAS-Kollisionen bei weniger als 4 UKPs auf, sollte ⁿberprⁿft werden, ob die Maschine CPU-bound ist und daher die UKPs durch die Applikation blockiert werden. In diesem Fall sollten diejenigen UKPs, die Usertasks enthalten, vom Betriebssystem real time priority erhalten. Fⁿr HP lΣ▀t sich dies durch den x_param-Parameter REAL_TIME_PRIORITY=<0 ... 127> erreichen. Dabei mu▀ jedoch unbedingt sichergestellt sein, da▀ MAXPU um mindestens eins kleiner als die Anzahl realer CPUs ist. Hohe Anzahl langlaufender Kommandos (> 1 Sek.): <Prozentsatz> % <Anzahl> Langlaeufer, <Anzahl> Kommandos Eine hoher Prozentsatz von SQL-Kommandos hat Laufzeiten von mehr als einer Sekunde im Adabas-Kernel. Ob dies wirklich ein Engpa▀ ist, hΣngt von der Anwendungsstruktur ab. So fⁿhren Massenkommandos bei Batchverarbeitungen hΣufig zu hohen Laufzeiten. Auch kommt es bei Lock-Situationen auf SQL-Objekten zu Wartezeiten, die ebenfalls die Bearbeitungsdauer verlΣngern. Das Auftreten von langlaufenden Kommandos ist damit nur ein Warnsignal. Aktion Falls es keine weiteren Hinweise durch x_wizard gibt, sollte u.a. ⁿberprⁿft werden, ob der Datenbankserver CPU-bound ist. Hohe Kommandolaufzeit im DB-Kernel (Receive/Reply): <Dauer> Sek. Die mittlere Bearbeitungszeit der SQL-Kommandos durch den Adabas-Kernel liegt ⁿber 100 ms. Ob dies wirklich ein Engpa▀ ist, hΣngt von der Anwendungsstruktur ab. So fⁿhren Massenkommandos bei Batchverarbeitungen hΣufig zu hohen Laufzeiten. Daneben fⁿhren Lock-Situationen auf SQL-Objekten, physisches I/O, Dispatching infolge Priorisierung anderer Tasks etc. zu kernelinternen Wartesituationen, die ebenfalls die Bearbeitungsdauer verlΣngern. Aktion Falls es keine weiteren Hinweise durch x_wizard gibt, sollte u.a. ⁿberprⁿft werden, ob der Datenbankserver CPU-bound ist. Hohe Anzahl von Self-Suspends (Dispatches): <Anzahl> pro Kommando Die Anzahl von Adabas-internen TaskverdrΣngungen ist sehr hoch. Langlaufende Kommandos werden in ihrer Abarbeitung nach einer bestimmten Laufzeit (xparam-Parameter REGION_LOCK_SLICE) unterbrochen, damit die Datenbank nicht durch LanglΣufer fⁿr andere Sessions blockiert wird (Σhnlich wie Timeslices in Betriebssystemen). Ob es sich bei diesem Verhalten um ein Problem handelt, kann nur bei Kenntnis des Anwendungsprofils entschieden werden. So fⁿhren z.B. aufwendige Suchen im Datencache fast zwangslΣufig zu einer drastischen Zunahme von Selfsupends. Eine hohe Zahl von Self-Suspends ist in jedem Fall ein Indiz fⁿr einen hohen Anteil langlaufender Kommandos. Eine Task kann zudem ein Self-Suspend ausfⁿhren, wenn eine andere, h÷her priorierte Task vom wartenden in den lauffΣhigen Zustand ⁿbergeht (nur bei xparam DYN_DISP_QUE_SRCH=YES). Aktion Bei batchartigen Anwendungen kann die Zahl der Self-Suspends durch Erh÷hung des xparam-Parameters REG_LOCK_SLICE verringert werden. Dies kann infolge einer Sequentialisierung der abzuarbeitenden Kommandos zu einer Verbesserung des Durchsatzes fⁿhren, doch werden kurzlaufende Kommandos damit benachteiligt (h÷here Dialog-Antwortzeit). Falls die Analyse der DB-Anwendung keinen Hinweis auf komplexe Kommandos ergibt, sollte ⁿberprⁿft werden, ob die SQL-Kommandos nicht erheblich mehr Daten lesen, als eigentlich zur Abarbeitung ben÷tigt werden (z.B. durch Tablescans oder ungⁿnstige Select-Strategien, ggf. Vtrace mittels x_wizbit auswerten). Hohe Vsuspend-Zeiten bei User-Tasks: <Dauer> Sek. pro Vsuspend (<Anzahl> Vsuspends) Die Dauer Adabas-interner WartezustΣnde ist sehr hoch. Damit sind nicht Kollisionen auf SQL-Sperrobjekten gemeint (diese fⁿhren zum sog. Vwait), vielmehr WartezustΣnde auf unterschiedliche Ereignisse, wie z.B. das Schreiben eines Log- Eintrags, die Freigabe eines B*-Baumes nach einer StrukturΣnderung etc. . Aktion Keine. Eine genauere Analyse kann nur durch den Adabas-Support erfolgen. Hohe Anzahl an Vsleeps bei User Tasks: <Anzahl> pro Kommando <Anzahl> Vsleeps, <Anzahl> Kommandos Die HΣufigkeit des Adabas-internen Wartezustandes Vsleep ist sehr hoch. Aktion Keine. Eine genauere Analyse kann nur durch den Adabas-Support erfolgen. x_wiztrc - Zeitlicher Verlauf von internen Adabas-Me▀werten AUFRUF x_wiztrc [-i Filename] [-P lines] -o|-c|-t|-O|-C|-g|-s|-S|- l|-r|-R|-T|-d|-p BESCHREIBUNG x_wiztrc wertet die durch x_wizard gesammelten Daten aus und gibt sie chronologisch in Tabellenform aus8. Die ausgegebenen Me▀werte beziehen sich dabei stets auf das zwischen zwei Messungen liegende Zeitintervall. VORAUSSETZUNGEN - Adabas D ab Release 6.1.19. - Vorausgegangener Start von x_wizard mit den Optionen æ-t sec -b ...Æ OPTIONEN -i Filename Eingabe-Datenfile mit den Me▀werten aus x_wizard (Default: x_wizard.bin). -P lines Neue ▄berschrift nach jeweils lines Zeilen. -o Overview. Wichtigste Me▀daten. -c Commands. Ausgefⁿhrte Kommandos (Select, Update, Delete...). -t Transactions. Ausgefⁿhrte Transaktionen (Commits, Rollbacks ...). -O I/O. I/O-AktivitΣten. -C Caches. Zugriffe und Hitraten der Datenbankcaches. -g Log. Logging-AktivitΣten. -s Strategy. Zugriffsstrategien des kostenbasierten Adabas-Optimizers (1). -S Strategy. Zugriffsstrategien des kostenbasierten Adabas-Optimizers (2). -l Lock. SQL-Sperren. -r Regions. Zugriffe und Kollisionen auf Regions (1). -R Regions. Zugriffe und Kollisionen auf Regions (2). -T Temp. AktivitΣten auf Temp-Pages. -d Dispatching. ▄bersicht der Dispatcher- AktivitΣten. -p Prioritization. Taskpriorisierungen im Dispatcher. BEMERKUNGEN Zielgruppe fⁿr x_wiztrc sind nicht Endanwender, sondern Mitarbeiter von Adabas-Support und -Entwicklung. Daher wird auf eine genaue ErklΣrung der ausgegebenen Parameter verzichtet. x_wiztrc-Ausgabetabellen Overview DaH Datacache Hitrate [%] CaH Catalogcache Hitrate [%] Exe Anzahl Executes Wtr Anzahl Write Transactions PhR Anzahl Physical Reads PhW Anzahl Physical Writes LgW Anzahl Physical Log Writes WaC Anzahl SQL Kollisionen (Vwait) WaTm Mittl. Dauer einer SQL-Kollision [s] SuC Anzahl Vsuspends SuTm Mittl. Dauer eines Vsuspends [s] RRTm Mittl. Kommandobearbeitungszeit im DB-Kernel [s] LoC Anzahl von Kommandobearbeitungszeiten > 1 Sekunde Rcol mittl. Kollisionsrate auf Regions [%] CSwp10 Anzahl Cache-VerdrΣngungen (Physical Writes) Commands SeA Anzahl Selects SeQ Anzahl selektierter SΣtze SeH Trefferrate (gefunden/gelesen) beim Select [%] InsA Anzahl Inserts InsQ Anzahl eingefⁿgter SΣtze UpdA Anzahl Updates UpdQ Anzahl geΣnderter SΣtze UpdH Trefferrate (geΣndert/gelesen) beim Update [%] DelA Anzahl Deletes geΣndert DelQ Anzahl gel÷schter SΣtze DelH Trefferrate (gel÷scht/gelesen) beim Delete [%] Transactions Sql Anzahl SQL Kommandos Pre Anzahl Prepares (Parses) Exe Anzahl Executes WTr Anzahl Schreibtransaktionen Com Anzahl Commits Rol Anzahl Rollbacks I/O PhR Anzahl Physical Reads PhW Anzahl Physical Writes USio Anzahl I/O via UKP (User-Task) USioT mittl. I/O-Zeit via UKP (User-Task) UDio Anzahl I/O via DEV-Proze▀ (User-Task) UDioT mittl. I/O-Zeit via DEV-Proze▀ (User-Task) SSio Anzahl I/O via UKP (Server-Task) SSioP Anzahl geschriebener Pages via UKP (Server-Task) SSioT mittl. I/O-Zeit via UKP (Server-Task) SDio Anzahl I/O via DEV-Proze▀ (Server-Task) SDioP Anzahl geschriebener Pages via DEV-Proze▀ (Server- Task) SDioT mittl. I/O-Zeit via DEV-Proze▀ (Server-Task) Caches DaA Anzahl Zugriffe auf Datacache DaH Datacache Hitrate [%] CaA Anzahl Zugriffe auf Catalogcache CaH Catalogcache Hitrate [%] CoA Anzahl Zugiffe auf Convertercache CoH Convertercache Hitrate [%] DnRC KollisionshΣufigkeit auf Datacache-Regions [%] CoRC KollisionshΣufigkeit auf Convertercache-Region [%] CSwp Anzahl Cache-VerdrΣngungen (Physical Writes) Log LgI Anzahl Log Queue Inserts Lov Anzahl Log Queue Overflows LgW Anzahl Physical Log Writes LgR Anzahl Physical Log Reads Sio Anzahl Logwrite-AuftrΣge via UKP (Self I/O) SioP Anzahl geschriebener Logpages via UKP (Self I/O) SioT mittl. I/O-Zeit eines Logauftrags via UKP (Self I/O) [s] Dio Anzahl Logwrite-AufrΣge via DEV-Proze▀ DioP Anzahl geschriebener Logpages via DEV-Proze▀ DioT mittl. I/O-Zeit eines Logauftrags via DEV-Proze▀ [s] Strategy (1)11 TscA Anzahl Zugriffe ⁿber Strategie æTable ScanÆ TscR Anzahl gelesener SΣtze bei Strategie æTable ScanÆ TscQ Anzahl qualifizierter SΣtze bei Strategie æTable ScanÆ KeyA Anzahl Zugriffe ⁿber Strategie æKeyÆ KeyR Anzahl gelesener SΣtze bei Strategie æKeyÆ KeyQ Anzahl qualifizierter SΣtze bei Strategie æKeyÆ KRaA Anzahl Zugriffe ⁿber Strategie æKey RangeÆ KRaR Anzahl gelesener SΣtze bei Strategie æKey RangeÆ KRaQ Anzahl qualifizierter SΣtze bei Strategie æKey RangeÆ IndA Anzahl Zugriffe ⁿber Strategie æIndexÆ IndR Anzahl gelesener SΣtze bei Strategie æIndexÆ IndQ Anzahl qualifizierter SΣtze bei Strategie æIndexÆ Strategy (2) IRaA Anzahl Zugriffe ⁿber Strategie æIndex RangeÆ IRaR Anzahl gelesener SΣtze bei Strategie æIndex RangeÆ IRaQ Anzahl qualifizierter SΣtze bei Strategie æIndex RangeÆ IsIA Anzahl Zugriffe ⁿber Strategie æIsolated IndexÆ IsIR Anzahl gelesener SΣtze bei Strategie æIsolated IndexÆ IsIQ Anzahl qualifizierter SΣtze bei Strategie æIsolated IndexÆ IIRA Anzahl Zugriffe ⁿber Strategie æIsolated Index RangeÆ IIRR Anzahl gelesener SΣtze bei Strategie æIsolated Index RangeÆ IIRQ Anzahl qualifizierter SΣtze bei Strategie æIsolated Index RangeÆ IISA Anzahl Zugriffe ⁿber Strategie æIsolated Index ScanÆ IISR Anzahl gelesener SΣtze bei Strategie æIsolated Index ScanÆ IISQ Anzahl qualifizierter SΣtze bei Strategie æIsolated Index ScanÆ Lock LocR Anzahl Lock List Entries (Row) LocT Anzahl Lock List Entries (Table) LoCol Anzahl Lock List Collisions WaC Anzahl SQL-Sperrkollisionen (Vwaits) WaTm mittl. Kollisionsdauer [s] LcRG Anzahl Zugriffe auf Lock-Region LcRC Kollisionsrate auf Lock-Region [%] Kb05 Anzahl KB05-AuftrΣge Regions (1)12 CoRG Anzahl Zugriffe auf CONVERT-Region CoRC Kollisionsrate auf CONVERT-Region [%] LcRG Anzahl Zugriffe auf LOCKRegion LcRC Kollisionsrate auf LOCK-Region [%] DnRG Anzahl Zugriffe auf DATAn-Regions DnRC Kollisionsrate auf DATAn-Regions [%] TnRG Anzahl Zugriffe auf TREEn-Regions TnRC Kollisionsrate auf TREEn-Regions [%] SnRG Anzahl Zugriffe auf SPLITTn-Regions SnRC Kollisionsrate auf SPLITTn-Regions [%] Regions (2) LoRG Anzahl Zugriffe auf LOG-Region LoRC Kollisionsrate auf LOG-Region [%] LwRG Anzahl Zugriffe auf LOGWRITER-Region LwRC Kollisionsrate auf LOGWRITER-Region [%] PdRG Anzahl Zugriffe auf PERMFDIR-Region PdRC Kollisionsrate auf PERMFDIR-Region [%] TdRG Anzahl Zugriffe auf TEMPFDIR-Region TdRC Kollisionsrate auf TEMPFDIR-Region [%] TrRG Anzahl Zugriffe auf TRACE-Region TrRC Kollisionsrate auf TRACE-Region [%] Temp TPR Anzahl Physical Temp Page Reads TPW Anzahl Physical Temp Page Writes TPVR Anzahl Virtual Temp Page Reads TPVW Anzahl Virtual Temp Page Writes Dispatching13 ToDC Anzahl Dispatcher Calls ToVwa Anzahl Vwaits ToSus Anzahl Vsuspends ToSle Anzahl Vsleeps TRegA Anzahl Regionzugriffe TReCo Anzahl Regionkollisionen TReWa Anzahl Regionwaits (Sem-Queue) TBgTC Anzahl TAS-Kollisionen im Vbegexcl TEnTC Anzahl TAS-Kollisionen im Vendexcl Prioritization ToDC Anzahl Dispatcher Calls ToTCo Anzahl Kommandos TotPr Anzahl Task-Priorisierungen TPrFO Anzahl Task-Priorisierungen durch andere UKPs TPrCQ Anzahl Task-Priorisierungen in Com-Queue TPrRQ Anzahl Task-Priorisierungen in Rav-Queue TPrCo Anzahl Task-Priorisierungen bei Commits x_wizbit - Suche nach EngpΣssen im Adabas Kerneltrace AUFRUF x_wizbit [-d] [-t time] [-r rel] [-p pags] [-s] [-l lines] [-L line] Vtracefile BESCHREIBUNG x_wizbit sucht im Adabas Kerneltrace (dem sog. Vtrace) nach SQL-Kommandos, die aufgrund ihrer Laufzeit, einer ungⁿnstigen Suchstrategie oder einer gro▀en Anzahl gelesener Datenbankpages einen Datenbank-Engpa▀ der laufenden Anwendung verursachen k÷nnen. VORAUSSETZUNGEN - Adabas D ab Release 6.1.1 - Das Datenbankmonitoring mu▀ eingeschaltet sein14. - Der TIME-Vtrace mu▀ eingeschaltet sein (xutil: DIAGNOSE VTRACE DEFAULT TIME ON) - Die Speicherung der geparsten Kommandos mu▀ eingeschaltet sein (xutil: DIAGNOSE PARSEID ON) - Der Connect an die Datenbank erfolgt ⁿber den DEFAULT-Key in xuser. Ist kein XUSER-File vorhanden, mⁿssen die Connect- Parameter ⁿber die Shellvariable SQLOPT ⁿbergeben werden. OPTIONEN -d Suche der kritischen Kommandos in der internen Adabas-Tabelle SYSPARSEID. Nur durch diese Option wird zu den Me▀werten das zugeh÷rige SQL-Kommando angezeigt. -t time Ausgabe aller SQL-Kommandos mit einer h÷heren Laufzeit als time Sekunden. Default: 1 -r rel Ausgabe aller SQL-Kommandos, bei denen das VerhΣltnis zwischen gelesenen und qualifizierten (d.h. gefundenen) SΣtze h÷her als rel ist. Default: 10 -p pags Ausgabe aller SQL-Kommandos, bei denen wΣhrend der Abarbeitung mehr als pags Pages virtuell oder physisch gelesen werden mu▀ten. Default: 1000 -s Ausgabe aller Table Scans -l lines Keine Ausgabe von Kommandos, die weniger als lines Zeilen im Vtrace geschrieben haben. -L line Ausgabe des Vtraceoutputs ab Zeile line bis zum Ende des Kommandos. Die Option -L kann nicht gleichzeitig mit den ⁿbrigen Optionen verwendet werden (ggf. ⁿbersteuert sie diese). BEMERKUNGEN Zur Analyse des Vtraces mittels x_wizbit sind einige Vorbereitungen erforderlich. So mu▀ vor dem Start des Applikationsprogramms (z.B. vor startsap r3) die Speicherung der SQL-Kommandos in der Datenbank aktiviert werden (xutil: DIAGNOSE PARSEID ON). Am Ende der Messungen sollte die weitere Speicherung deaktiviert werden (DIAGNOSE PARSEID OFF), da jedes gespeicherte Kommando bis zu 4 Kilobyte Platz in der Datenbank ben÷tigt. Daneben mu▀ der TIME-Vtrace eingeschaltet sein. Da unter Hochlast das Schreiben des Vtraces sehr kostenintensiv sein kann, sollte in Produktivsystemen der Vtrace nur wΣhrend der erforderlichen Me▀periode aktiviert werden, ggf. auch nur fⁿr eine ausgewΣhlte Session. Der Vtracebereich (xparam- Parameter KERNELTRACESIZE) sollte mindestens 1000 Pages betragen. Der Vtrace wird am besten mittels kernprot -dn $DBNAME akbt im Adabas-Rundirectory erzeugt und ausgewertet. Die Optionen -t, -r,-s und -p sind additiv, d.h. es erfolgt eine Ausgabe, wenn mindestens eines der Ausgabekriterien erfⁿllt ist. Sollen dagegen nur jene Kommandos ausgegeben werden, fⁿr die genau ein Kriterium erfⁿllt ist, so k÷nnen bei den ⁿbrigen Optionen Maximalwerte angegeben werden (Beispiel: Zeige alle Kommandos mit einem VerhΣltnis Rows Read / Rows Qual > 10: x_wizbit -r 10 -t 10000 -p 10000 -d $DBNAME). HΣufig kommen hohe Laufzeiten nur dadurch zustande, da▀ Kommandos infolge interner WartezustΣnde auf I/O, SQL- Sperren etc. unterbrochen (dispatched) wurden. Um diese unkritischen Kommandos auszufiltern, kann die Option -l benutzt werden. ErfahrungsgemΣ▀ verursachen Kommandos keine EngpΣsse, die weniger als 50 Zeilen Vtrace-Output erzeugen. Gezielte Suche nach teuren SQL-Kommandos ╖ Datenbank starten und restarten ╖ xutil: DIAGNOSE VTRACE DEFAULT TIME ON ╖ xutil: DIAGNOSE PARSEID ON ╖ xquery (adabas Mode): MONITOR ON ╖ M÷glichst zweites Window ÷ffnen, dort in Adabas- Rundirectory wechseln ╖ Im 1. Window x_wizard -x -t 30 ╖ Applikation starten ╖ Sobald die Meldung Niedrige Hitrate via <Strategie> ... erscheint, im zweiten Window den Vtrace mit kernprot -dn $DBNAME akbt ziehen. ╖ Vtrace auswerten mit x_wizbit -l 50 -d $DBNAME.prt > wizbit.prt ╖ im File wizbit.prt die langlaufenden Kommandos analysieren. Dazu mittels xquery ⁿberprⁿfen, ob die WHERE- Qualifikation ⁿber den KEY oder einen Index abgehandelt werden k÷nnte. Eventuell Select-Strategie mittels EXPLAIN in xquery ⁿberprⁿfen. _______________________________ 1 In SAP R/3 wird x_wizard ab Release 3.0 automatisch mit einem Me▀intervall von 15 Minuten gestartet. Die Auswertung ist ⁿber die Transaktion st04 abrufbar (englische Meldungstexte). 2 Mit eingeschrΣnkter FunktionalitΣt steht x_wizard auch fⁿr Adabas D Release 3.1.2 zur Verfⁿgung. 3 Bei SAP R/3 wird das Adabas-Monitoring automatisch eingeschaltet. Es sollte wΣhrend des laufenden R/3- Produktivbetriebs nicht durch MONITOR ON neu initialisiert werden, da in diesem Fall die R/3-interne Statistikauswertung verfΣlscht wird. 4 Dieser Richtwert gilt fⁿr SAP R/3. Fⁿr andere Anwendungen ist hΣufig ein wesentlich kleinerer Catalogcache ausreichend. 5 Diese Bufwriter-Parameter befinden sich derzeit (August 95) in einer Erprobungsphase und k÷nnen daher kurzfristig geΣndert werden oder entfallen. Typische Werte sind NUM_BUFREADER=2, BR_SLEEPTIME=30, BR_IF_IOCNT_LT=300). 6 Genaugenommen trifft die Aussage quantitativ fⁿr einen Isolation Level > 0 nicht zu, da nur solche Transaktionen als Schreibtransaktionen gezΣhlt werden, die mindestens eine Schreibsperre setzen, aber auch Kollisionen auf Lesesperren gezΣhlt werden. Qualitativ deutet eine hohe Kollisionsrate aber in jedem Fall auf Sperrprobleme hin. 7 0 (Null) als Anzahl bedeutet, da▀ wΣhrend des Me▀intervalls eine Schreibtransaktion aktiv war, die noch nicht committed ist. 8 In SAP R/3 k÷nnen ab Release 3.0 die Tabellen ⁿber die Transaktion st04 ausgegeben werden. 9 Mit eingeschrΣnkter FunktionalitΣt steht x_wiztrc auch fⁿr Adabas D Release 3.1.2 zur Verfⁿgung. 10 Nur bei Ausgabe ⁿber SAP R/3, Transaktion st04 11 Bei SAP R/3, Transaktion st04 werden die Strategie-Tabellen in einer Ausgabe zusammengefa▀t. 12 Bei SAP R/3, Transaktion st04 werden die Region-Tabellen in einer Ausgabe zusammengefa▀t. 13 Bei SAP R/3, Transaktion st04 werden die Dispatching- und Prioritization-Tabellen in einer Ausgabe zusammengefa▀t. 14 Bei SAP R/3 wird das Adabas-Monitoring automatisch eingeschaltet. Es sollte wΣhrend des laufenden R/3- Produktivbetriebs nicht durch MONITOR ON neu initialisiert werden, da in diesem Fall die R/3-interne Statistikauswertung verfΣlscht wird.