Ćwiczenie było następujące:
Według stanu na dziś, IBM nie supportuje lin_tape w wersji 1.76 na RHEL 6.3. Faktycznie nie działa to stabilnie, więc pod prawie gotowym TSMem trzeba było zdowngradeować (to moj blog, więc mogę tworzyć nowe słowa :-P) RedHata do 6.2.
Po instalacji systemu i prerequisitów TSMa, zainstalowałem samego TSMa.
Po tej operacji zaimportowałem ponownie grupę wolumenów na której miałem zainstalowaną instancję TSMa. Oczywiście katalogowanie już stworzonej instancji TSMa w database managerze jest nie wspierane, więc wyczyściłem katalogi/filesystemy pod active i archive logiem oraz filesystemy z dbspace.
Przez dsmicfgx stworzyłem, jak mi się wówczas wydawało bliźniaczą instancję.
Podłożyłem devconfig i volhista (nie trzeba było nic zmieniać, bo system był ten sam) i puściłem:
dsmserv restore db todate=today totime=<czas ostatnigo snapshotu> source=dbs
Serwer się poniósł, wszystko działało prawie ok. Prawie, bo trigger od automatycznego backupu oszalał. Co 10 minut zaczął robić full backup bazy. Set dbrecovery mam ustawione na klasę plikową więc szybko skończylo mi się mi miejsce na dyskach, w efekcie backup przestał się wykonywać.
To samo na testowej instancji (wszystkie katalogi TSMa w jednym filesystemie) skończyło się śmiercią TSMa: brak miejsca na actlogu.
Wytłumaczenie jest proste - TSM po restore gdzieś pamięta stary rozmiar ACTIVELOGSIZE. Jeśli nowa instancja ma ustawione mniej to trigger głupieje.
Rozwiązanie: Przy disaster recovery TSMa, zawsze ustawiać ACTIVELOGSIZE na nie mniej niż oryginał.
Przypuszczam, że sprawa dotyczy wszystkich wersji 6.x. Zgłoszę na to PMRa, więc jak coś wyjaśnią to zaktualizuję ten wpis.
[update 21/02/2013]
No i jest odpowiedź z supportu. Jakiś sprawny inaczej jestem, bo sobie tego sam nie wygooglełem, a było, zanim zgłosiłem problem: http://www-01.ibm.com/support/docview.wss?uid=swg21618987
Według stanu na dziś, IBM nie supportuje lin_tape w wersji 1.76 na RHEL 6.3. Faktycznie nie działa to stabilnie, więc pod prawie gotowym TSMem trzeba było zdowngradeować (to moj blog, więc mogę tworzyć nowe słowa :-P) RedHata do 6.2.
Po instalacji systemu i prerequisitów TSMa, zainstalowałem samego TSMa.
Po tej operacji zaimportowałem ponownie grupę wolumenów na której miałem zainstalowaną instancję TSMa. Oczywiście katalogowanie już stworzonej instancji TSMa w database managerze jest nie wspierane, więc wyczyściłem katalogi/filesystemy pod active i archive logiem oraz filesystemy z dbspace.
Przez dsmicfgx stworzyłem, jak mi się wówczas wydawało bliźniaczą instancję.
Podłożyłem devconfig i volhista (nie trzeba było nic zmieniać, bo system był ten sam) i puściłem:
dsmserv restore db todate=today totime=<czas ostatnigo snapshotu> source=dbs
Serwer się poniósł, wszystko działało prawie ok. Prawie, bo trigger od automatycznego backupu oszalał. Co 10 minut zaczął robić full backup bazy. Set dbrecovery mam ustawione na klasę plikową więc szybko skończylo mi się mi miejsce na dyskach, w efekcie backup przestał się wykonywać.
To samo na testowej instancji (wszystkie katalogi TSMa w jednym filesystemie) skończyło się śmiercią TSMa: brak miejsca na actlogu.
Wytłumaczenie jest proste - TSM po restore gdzieś pamięta stary rozmiar ACTIVELOGSIZE. Jeśli nowa instancja ma ustawione mniej to trigger głupieje.
Rozwiązanie: Przy disaster recovery TSMa, zawsze ustawiać ACTIVELOGSIZE na nie mniej niż oryginał.
Przypuszczam, że sprawa dotyczy wszystkich wersji 6.x. Zgłoszę na to PMRa, więc jak coś wyjaśnią to zaktualizuję ten wpis.
[update 21/02/2013]
No i jest odpowiedź z supportu. Jakiś sprawny inaczej jestem, bo sobie tego sam nie wygooglełem, a było, zanim zgłosiłem problem: http://www-01.ibm.com/support/docview.wss?uid=swg21618987
