DB2 UDB

DB2 Grundinstallation

DB2 von 32Bit auf 64Bit aufrüsten

Uncomplete recovery from TSM restore

DB2 Fehlermeldungen

Stoppen der DB

DB2 Prozesse

DB2 auf RAID-5

DB2 Version abfragen

Grundinstallation

Zu den Voraussetzungen auf dem AIX Server gehört, daß AIO aktiviert ist. Bis einschließlich AIX 5.3 muß das manuell gemacht werden, ab AIX 6 ist AIO per default aktiv.

<nach oben>

DB2 von 32Bit auf 64Bit updaten

Die hochzurüstende Instanz muß gestopt sein. Das db2iupdt muß als root gestartet werden.

/usr/opt/db2_08_01/instance 35$ ./db2iupdt -w 64 db2inst1

DBI1070I Program db2iupdt completed successfully.

(0)dbserver:/usr/opt/db2_08_01/instance 37$ su - db2inst1

$ db2level

DB21085I Instance "db2inst1" uses "64" bits and DB2 code release "SQL08015" with level identifier "02060106". Informational tokens are "DB2 v8.1.1.48", "s040212", "U496793", and FixPak "5". Product is installed at "/usr/opt/db2_08_01".

$ db2start

01-04-2005 12:05:34 0 0 SQL1063N DB2START processing was successful.

SQL1063N DB2START processing was successful.

$

<nach oben>

DB2 uncomplete restore

# db2 list db directory

# db2 connect to <database>

# db2adutl query full

nach Sicherung grepen wg. Erstellungsdatum, anschließend restore

# db2 restore db <database> use tsm taken at 20041228115853

# activate db <database>

# db2 connect to <database>

# db2 terminate

<nach oben>

DB2 Fehlermeldungen

SQL1402N Unable to authenticate user due to unexpected system error.

Diese Fehlermeldung tritt aus verschiedenen Gründen auf.

<nach oben>

Stoppen der Datenbank

Zunächst stoppt man einen etwaigen query-patroller mit qpstop <dbname>. I.d.R. reicht ein db2stop als Instanzbesitzer aus. Wenn db2stop nicht ausgeführt wird, kann man mit

db2 force application all

dafür sorgen, daß es doch funktioniert. Wenn danach noch Prozesse übrig sind, kann man diese mit db2_kill gewaltsam beenden. Es ist jedoch sehr wichtig, daß dieses Kommando nur angewendet wird, wenn in der DB nicht mehr geschrieben wird! Welche Prozesse der Instanz im Zshg. mit der DB noch aktiv sind, kann man mit db2_ps prüfen.

<nach oben>

DB2 Prozesse

Die wichtigsten DB2 Prozesse sind:

db2sysc     DB2 system controller process

db2gds     Global daemon spawner that spawns new processes

db2ipccm     Local client connection listener process

db2tcpcm     TCP/IP protocol listener process

db2resyn     Resync agent process that scans the global rsync list

db2wdog     Watchdog process that handels abnormal terminations

I.d.R. reicht es aber einen einzigen Prozess von DB2 zu überwachen, da sich die Prozesse gegenseitig beobachten. D.h. wenn einer dieser Prozesse down ist, sind alle anderen meist ebenfalls down. Das ist Standardverhalten von DB2.

<nach oben>

DB2 auf RAID-5

Wichtig ist, daß bevor die tablespaces angelegt werden die Umgebungsvariable DB2_STRIPED_CONTAINERS=ON gesetzt wird. Die tablespaces selbst, die auf den RAID devices angelegt werden, müssen in der Umgebungsvariable DB2_PARALLEL_IO genannt sein (* für alle tablespaces). Jetzt kommt m.W. der Knackpunkt: wenn DB2_PARALLEL_IO gesetzt ist, bekommt die tablespace PREFETCHSIZE eine besondere Bedeutung. Die PREFETCHSIZE wird durch die EXTENDSIZE geteilt, um den gewünschten Grad der Parallelsierung zu erreichen. Wenn die Umgebungsvariable nicht gesetzt ist, dann ergibt sich der Grad der Parallelität aus der Anzahl der container. Weil RAID aber oft nur einen einzigen container hat muß die PREFETCHSIZE auf ein Mehrfaches der EXTENTSIZE sein, damit eine genügende Anzahl an IO_SERVERS (mindestens 1 pro physischer Platte) zur Verfügung steht und um dem tablespace einen bufferpool zur Verfügung zu stellen, der groß genug ist um die prefetch Zugriffe bedienen zu können. Wenn prefetch I/O nicht gewollt ist (z.B. bei OLTP) dann darf die tablespace ID nicht von der DB2_PARALLEL_IO Variable erfaßt werden oder die PREFETCHSIZE muß gleich der EXTENTSIZE sein. Beispiel: bei einem RAID5 (6+1) mit 64k stripe size müßte die EXTENTSIZE 6*64/4=96 sein. Bei einem container per RAID5 wäre PREFETCHSIZE dann hier 96*6=384.

<nach oben>