Wszystkie nasze File Systemy (w DB2)

Często pracując na  bazie danych DB2 nie zastanawiamy się w jaki sposób zostały skonfigurowane FS’y dla naszego motoru. Sam proces instalacji umożliwia nam wskazanie jednego domyślnego file systemu oraz późniejszą prace na nim. W celu zapewnienia lepszej wydajności oraz uporządkowania danych wydaje się dobrym pomysłem jest przydzielenie odpowiedniej przestrzeni dyskowej do różnego typu danych.

Proces ten możemy rozpocząć od sprawdzenia katalogu HOME dla instancji:

$ echo $INSTHOME
/db2/TK

Kolejnym krokiem jest sprawdzenie, które file systemy są przypisane do naszej bazy operacyjnej:

$ db2 -tvf sel_dbpartition.sql

select dbpartitionnum , substr(type,1,18) as type , substr(path,1,70) as path from sysibmadm.dbpaths

DBPARTITIONNUM TYPE                                         PATH
-------------------------  --------------------------------  ----------------------------------------------------
0                                    LOGPATH                                /db2/TK/data1/db2inst1/NODE0000/SQL00004/SQLOGDIR/
0                                    DB_STORAGE_PATH          /db2/TK/data1/
0                                    LOCAL_DB_DIRECTORY   /db2/TK/data1/db2inst1/NODE0000/sqldbdir/
0                                    DBPATH                                  /db2/TK/data1/db2inst1/NODE0000/SQL00004/
4 record(s) selected.

Kolejne ważne ścieżki w bazie danych to :

$ db2 get db cfg for tstdb |grep PATH

Changed path to log files                  (NEWLOGPATH) =
Overflow log path                 (OVERFLOWLOGPATH) =
Mirror log path                           (MIRRORLOGPATH) =
Failover log archive path               (FAILARCHPATH) =

Oraz

$ db2 get dbm cfg |grep DIAGPATH

Diagnostic data directory path                               (DIAGPATH) = /db2/TK/sqllib/db2dump/
Alternate diagnostic data directory path   (ALT_DIAGPATH) =

Chciałbym zwrócić przy tym uwagę że file system ten może zajmować całkiem dużo przestrzeni z informacjami diagnostycznymi.
W moim środowisku testowym gdzie nie dzieje się dużo wyszło mi około 2 GB danych

/db2/TK/sqllib/db2dump
$ du -g .
0.00   ./DART0000
0.01   ./events
0.04   ./stmmlog
1.93   .

Jeśli ktoś z Was używał polecenia db2 „INSPECT” to wynik tej komendy zostaje również zapisany w pliku binarnym w katalogu HOME /db2dump Sam często korzystam z tego polecenia w celu sprawdzenia miejsca w poszczególnych tablespacach.

Przykład takiego polecenia:

db2 inspect check database results keep insp_out.bin 

DATABASE: TSTDB
Tablespace ID: 2  Object ID: 8
Result file name: insp.out
   Table phase start (ID Signed: 8, Unsigned: 8; Tablespace ID: 2) : DBA.SNAPSTMT
    Data phase start. Object: 8  Tablespace: 2
    The index type is 2 for this table.
      Traversing DAT extent map, anchor 7943136.
      Extent map traversal complete.
        Expansion dictionary size: 32768 bytes.
        Compression dictionary size: 38016 bytes.
    DAT Object Summary: Total Pages 1140096 - Used Pages 872740 - Free Space 23 %
Data phase end.

W sekcji DAT przydatne informacje o zużytych stronach ver. strony zaalokowane co może nam pomoc w podjęciu decyzji o odzyskaniu miejsca za pomocą REORG’a.

Jednym z ostatnich FS-ów, który powinniśmy mieć dedykowany dla naszych danych jest miejsce na kopie bezpieczeństwa.

select location from sysibmadm.db_history where operation='B' with ur

LOCATION  
-----------------------------------------------------
/db2/TK/backup11 
1 record(s) selected.

Mam nadzieję że ten krótki artykuł pozwoli Wam określić  jakie FS’y nasze DB2 używa 🙂

Autorem wpisu jest: Kraszucki Tomasz