Forum

Hallo Gernot,

das hat schon geholfen!

Mir war aufgefallen, dass … Self tuning memory                    (SELF_TUNING_MEM) = ON (Active)                ON
eingestellt ist. Ich habe dieses Feature immer nur mit Problemen erlebt. Weder auf Windows 2000 noch AIX hat "STM" fehlerfrei funktioniert. Empfehlung (testweise): OFF, Database Memory aber COMPUTED.

STMM funktioniert offenbar auch an Solaris nicht fehlerlos, besonders mit enabled intra-parallelism. Wir hatten inzwischen auch andere Probleme, sogar DB2 server zusammenbruch. Seitdem die Konfiguration aber auf INTRA_PARALLEL=NO umgestellt wurde, läuft der server reibungslos, und ist db2diag.log "sauber" von den früheren jdbc Fehlern.

Automatic reorganization               (AUTO_REORG) = ON            
Besser mal ausschalten und das REORG Utility in Ruhezeiten (nachts, am Wochenende) ausführen.

Ja, das ist zu überlegen. Das muss man aber extra implementieren, crontab ins Betrieb setzen, weil im Control Center die auto-maintanance feature erlaubt nur ein einziges Fenster für online maintanance abzugeben.  

Automatic Runstats sollte ok sein. Die Frage ist nur, wie der Automatic Maint Scheduler konfiguriert wurde: Wann laufen die Aktionen?

Ich definiere dieses online maintanance Fenster, und erlaube RUNSTATS durchgehend.

Max number of existing agents               (MAXAGENTS) = 400                      
Sind wirklich soviele Agents notwendig?

Ich musste die Zahl erhöhen, 200 waren nicht genug, aber ein Kompromiss von 300 scheint entsprechend zu sein. Tja, hier geht es um ein Datenmodell, wo die grundsätzlichen, sogenannten "Stammdaten" in einer separaten Datenbank gelegt sind, und die Anwendungen aus den 3 Hauptdatenbanken greifen ständig und intensiv (durch agents) auf diesen federated Tabellen zu.

Enable intra-partition parallelism     (INTRA_PARALLEL) = YES
Empfehlung: OFF/NO.

Danke für den Rat! Inzwischen habe ich einige SQL-s getunt, infolgedessen bemerken wir gar nicht, dass die Leistung langsamer wäre.  

Außerdem ist mir eine riesige Anzahl von DB2 Prozessen aufgefallen. Das hängt natprlich mit MAXAGENTS etc zusammen.

Schafft Solaris überhaupt soviele Prozesse?

Ja, schon. Dieses ist ein großes, kompliziertes MQ-Broker System, mit etwa 50 parallel laufenden Komponenten und queues.

Wie siehen die User Limits für den Instance User db2inst1 aus? <ulimit -a>

core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 65535
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16341
virtual memory        (kbytes, -v) unlimited

Was sagt DB2 zu den Solaris Kernel Info? <db2osconf>

Leider nichts. Ob warum? Da wir haben eine zone? Oder eine nicht-ünterstützte Solaris-Version?

[db2inst2@db2zone:~] # db2osconf
kopen: cannot stat /dev/kmem
kvm_open: No such file or directory
Error: Failed to get kernel parameters
[db2inst2@db2zone:~] #

Kennst Du übrigens schon mein "DB2 Administrator’s Unix Command Surival Sheets (AIX + Solaris)" unter https://www.ruban.de/DB2_luw/UnixCmdQuickRef.PDF.

Bisher nicht, sieht aber nützlich aus!

Danke vielmals für die Ideen

Katalin