Konfigurowanie połączenia DB2 na Windows z TSM

Jestem, że tak powiem, windowsowo niepełnosprawny, więc pewne rzeczy, które odkryłem, mogą być dla większości oczywiste :-)

Dokumentacja, na którą skieruje nas życzliwy wujek "g" jest, jak się okazuje, równie szowinistyczna względem łindołsów jak i ja. Niby w tytule jest "Linux, Unix and Windows", ale jakoś wszystkie przykłady mają w ścieżkach "/" a nie "\".

W skrócie wszystko wygląda dobrze:
Żeby podłączyć DB2 do TSM wystarczy instancji ustawić 3 zmienne środowiskowe:

• DSMI_DIR - wskazującą na katalog gdzie jest agent dsmtca.
• DSMI_CONFIG - pokazującą na plik "dsm.opt" jakiego DB2 ma użyć do połązczeń.
• DSMI_LOG - katalog, do którego ma zostać zapisany log dsierror.log. 

Jasne? Tak, ale.
Ale nr 1 - na Windows nie ma dsmtca. Na Unixach to narządko jest odpowiedzialne za odpalanie części klienta na prawach roota (ma suid). Na wiodącym systemie jest to załatwiane inaczej, dlatego na Windzie ta zmienna powinna po prostu wskazywać na katalog "baclient", czyli przeważnie c:\Program Files\Tivoli\TSM\baclient.
Ale nr 2 - Na Windows można ustawiać zmienne środowiskowe na dwa sposoby: Po bożemu: w skrypcie, albo jakoś dziwnie, klikając prawym klawiszem gryzonia na "My Computer" itd.. Oba sposoby działają... połowicznie. To znaczy da się to wszystko ustawić, ale działa tylko częściowo: daje się bazie ustawić hasło z jakim ma się zgłaszać do TSMa, ale sam backup i restore nie działają. I tu dochodzimy do...
... Ale nr 3 - Zmienne środowiskowe dla instancji bazy DB2 należy ustawiać w jej własnym rejestrze zmiennych, którym manipuluje się poleceniem db2set. Ale (nr 4) nie bezpośrednio. Otóż przy pomocy zmiennej DB2_VENDOR_INI, ustawianej tymże narzędziem, wskazuje się plik, w którym ustawia się zmienne DSMI_*. To "Ale nr 4" to już moja złośliwość, bo to tak naprawdę fanaberia DB2 a nie systemu, bo na Unixach jest tak samo. To tyle komentarzy, poniżej zawarłem zatem nieco uściślony algorytm konfigurowania styku DB2 i TSM.

Ustawienia DB2

1. Stworzyć plik c:\db2tsm\db2tsm.env (nazwa i lokalizacja dowolna, liczy się treść) i umieścić w nim zmienne środowiskowe potrzebne do znalezienia TSMa przez DB2:

DSMI_DIR=c:\Program Files\Tivoli\TSM\baclient

DSMI_CONFIG=c:\db2tsm\db2-dsm.opt

DSMI_LOGS=c:\tsmlogs

Tak na prawdę to pliki db2-dsm.opt może leżeć gdzie się chce i nazywać się może dowolnie. Ważne, żeby istniał :-P i miał sensowną treść, o czym później.

Poleceniem db2set ustawić zmienną DB2_VENDOR_INI:

1. Uruchomić "Narzędzia wiersza poleceń" gdzieś z menu Start->DB2-> bla ->bla ->bla. Pewnie wybrać opcję "Jako administrator".
2. Sprawdzić ile mamy instancji, bo może być więcej.

db2ilist

3. Dla każdej instaencji, która ma mieć kontakt z TSM ustawić DB2_VENDOR_INI. UWAGA: Najprawdopodobniej, każdej instancji trzeba będzie ustawić inny plik  *.opt!

db2set -i INSTANCJA DB2_VENDOR_INI=c:\db2tsm\db2tsm.env

4. Zatrzymać i wystartować database managera (każda instancja ma własnego), dlatego jesli nie pracujesz z jedyną/domyślną/porządaną to najpier wybierz, ustawiając zmienną DB2INSTANCE:

set DB2INSTANCE=INSTANCJA   (to jest jedna z nazw zwróconych przez db2ilist)

a potem, restart instancji:

db2stop
db2start

A po stronie TSM...

TSM nie wymaga specjalnej gimnastyki. Należy tylko zarejestrować klienta dla każdej instancji DB2 jaką będziemy backupować, być może warto się tu zastanowić czy nie chcemy oddzielić klientów bazodanowych od plikowych, np inną domeną. Ja w przykładach posłuże się oddzielną domeną o odkrywczej i nieoczywistej nazwie DB2.

Drugą rzeczą do rozważenia, jest kwestia polityki backupu. TSM w tym wypadku jest zredukowany do roli worka na dane. Cała mądrość jest po stronie bazy, dlatego polityka bezpieczeństwa po stronie TSM może wyglądać na nieco ubogą.

1. Zarejestrować domenę na klientów DB2:

def dom DB2 descr="Bazy DB2"

2. Zdefiniować politykę backupową 

def pol db2 prod

def mgmt db2 prod db2_standard

def copyg db2 prod db2_stndard t=b dest=jakaś_pula vere=1 verd=0 rete=0 reto=0

assign defmgmt db2 prod db2_standard

3. Sprawdzić i zaktywoawać politykję:

val pol db2 prod (będzie marudzić na brak copy grupy archiwalnej, i pewnie na mig destination. te komunikaty można zignorować, ważne żeby powiedział że policy set prod jest ready for activation)

act pol db2 prod (znowu będzie marudzić. Olać).

4. Zarejestrować klienta naszej (naszych)  instancji:

reg node db2inst1 ibm123 dom=db2 backdel=y userid=none

Istotne jest tu, żeby pozwolić mu kasować swoje backupy. Każdy backup zrobiony przez DB2 będzie, z punktu widzenia TSMa, oddzielnym obiektem, dlatego nie ma wersjonowania, a co za tym idzie wygasania nadmiarowych wersji. To baza będzie odpowiedzialna za usuwanie nadmiarowych backupów. 

I jeszcze raz DB2

Teraz przyszedł czas na dokończenie konfigurowania DB2. 

1. Ustawić hasło API TSM:

dsmapipw   (zapyta o hasło, podać to z rejestracji noda, w przykładzie to ibm123)

Sprawdzić w activity logu TSMa, czy węzeł się podłączył. Jeśli nie to pewnie w %DSMI_LOG%\dsierror.log bedzie jakaś informacja o tym co się stało.

2. Zrobić jakiś prosty backup z DB2:

db2 backup db sample use tsm

db2 list history backup for db sample

Na koniec

To co napisałem, to wędka, a nie ryby. Pewnie powinienem o tym wspomnieć na początku :-P Zasadniczo to nic nie powinno się popsuć. Psucie zacznie się wtedy, gdy będziemy odtwarzać bazy, dlatego nie piszę o tym, tylko dosyłam do solidnego przeczytania ze zrozumieniem przynajmniej tego rozdziału dokumentacji.

Zanim uznamy rozwiązanie za kompletne, wypadałoby się także pochylić nad następującą tematyką:

•  Przestawienie bazy w tryb logowania archiwalnego (domyślnie, logi są cykliczne, więc jedyny możliwy backup, to pełny, offline - nic ciekawego)
• Włączenie śledzenia zmodyfikowanych stron - umożliwia backupy typu delta.
• Ustawienie długości historii backupów.
• Ustawienie automatycznego kasowania backupów.
• Ustawienie ilości przechowywanych backupów.
• Wymyślenie metody archiwizacji i retencji logów bazy.