PC Treasures, Inc./pctreasures.mdf/WINDOWS/adabas/f_0001/misc/x_wiz.txt

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

23
ADABAS D   Performanceanalyse und Tuning
_______________________________________________________________
____________

Jochen           Hartmann,          Tel.          [phone]
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.