Podręcznik Data Recovery and High Availability Guide

Przegląd zagadnień dotyczących tworzenia kopii zapasowej

Należy pamiętać o następujących ograniczeniach:

• Uruchomienie operacji tworzenia kopii zapasowej otwartej bazy danych dla obszaru tabel DMS jest dopuszczalne nawet wtedy, gdy tabela z tego samego obszaru tabel jest reorganizowana w trybie otwartej bazy danych. W fazie obcinania mogą występować okresy oczekiwania na blokady dla operacji reorganizacji.
• Uruchomienie operacji tworzenia kopii zapasowej otwartej bazy danych dla obszaru tabel SMS jest niedopuszczalne, gdy tabela z tego samego obszaru tabel jest reorganizowana w trybie otwartej bazy danych. Obie operacje wymagają blokady na wyłączność.

Korzystanie z narzędzia do tworzenia kopii zapasowych

Z programem narzędziowym do tworzenia kopii zapasowych wiążą się następujące ograniczenia:

• Operacji tworzenia kopii zapasowej obszaru tabel i operacji odtwarzania obszaru tabel nie można uruchamiać jednocześnie, nawet dla różnych obszarów tabel.
• Aby mieć możliwość odtwarzania zmian w środowisku partycjonowanej bazy danych, należy regularnie tworzyć kopie zapasowe bazy danych z listy węzłów i trzeba dysponować co najmniej jednym obrazem kopii zapasowej pozostałych węzłów systemu (nawet tych, które nie zawierają danych użytkownika z tej bazy danych). Posiadanie kopii zapasowej obrazu partycji bazy danych na serwerze partycji, który nie zawiera danych użytkownika z bazy danych, jest wymagane w dwóch sytuacjach:
  • Serwer partycji bazy danych został dodany do systemu bazy danych po wykonaniu ostatniej kopii zapasowej i trzeba wykonać odtwarzanie do przodu na tym serwerze partycji bazy danych.
  • Stosowane jest odtwarzanie do określonego momentu, które wymaga, aby wszystkie partycje bazy danych w systemie były w stanie odtwarzania zmian w toku.
  • Operacje tworzenia kopii zapasowej otwartej bazy danych dla obszarów tabel DMS są niekompatybilne z następującymi operacjami:
    • Ładowanie.
    • Reorganizacja (tylko zamkniętej bazy danych); (reorganizacja otwartej tabeli z obszaru tabel, dla którego tworzona jest kopia zapasowa, może być wykonywana, chociaż mogą występować oczekiwania na blokady w fazie obcinania).
    • Usuwanie obszaru tabel.
    • Obcinanie tabel.
    • Tworzenie indeksu.
    • Klauzula not logged initially (używana w instrukcjach CREATE TABLE i ALTER TABLE).

Przegląd zagadnień dotyczących usuwania skutków awarii w środowiskach o wysokiej dostępności

Podczas wykonywania komend START HADR, STOP HADR i TAKEOVER HADR mogą zostać wygenerowane odpowiednie kody błędów: SQL01767N, SQL01769N lub SQL01770N z kodem przyczyny 98. Kod przyczyny oznacza, że na serwerze, na którym została uruchomiona komenda, nie ma zainstalowanych licencji HADR. Aby rozwiązać ten problem, należy zainstalować poprawną licencję HADR za pomocą komendy db2licm lub zainstalować wersję serwera, która zawiera poprawną licencję HADR jako część pakietu dystrybucyjnego.

Obsługa tworzenia i odtwarzania kopii zapasowych na różnych platformach

Program DB2 Universal Database (UDB) obsługuje operacje tworzenia i odtwarzania kopii zapasowych na różnych platformach.

Bazy danych utworzone w programie DB2 UDB, wersja 8, na 32-bitowej platformie systemu Windows można odtwarzać w programie DB2 UDB, wersja 8, na 64-bitowej platformie systemu Windows; można również wykonać operację odwrotną.

Bazy danych utworzone w programie DB2 UDB, wersja 8, na 32-bitowej platformie systemu Linux x86 można odtwarzać w programie DB2 UDB, wersja 8, na 64-bitowej platformie Linux x86-64 lub IA64; można również wykonać operację odwrotną.

Bazy danych utworzone w programie DB2 UDB, wersja 8, na 32- lub 64-bitowych platformach systemów AIX, HP-UX, Linux PPC, Linux zSeries lub w Środowisku Operacyjnym Solaris można odtwarzać w programie DB2 UDB, wersja 8, na platformach systemów AIX, HP-UX, Linux PPC, Linux zSeries lub w Środowisku Operacyjnym Solaris (32- lub 64-bitowych).

Tworzenie kopii zapasowej na taśmie (system Linux)

Maksymalna wielkość bloku dla urządzeń taśmowych 3480 i 3490 w systemie Linux wynosi 61 440 bajtów.

Tivoli Storage Manager

Podczas wywoływania komend BACKUP DATABASE lub RESTORE DATABASE można określić, że do zarządzania operacją tworzenia lub odtwarzania kopii zapasowej bazy danych albo obszaru tabel ma być używany produkt Tivoli Storage Manager (TSM). Minimalny wymagany poziom interfejsu API klienta TSM to wersja 4.2.0, z wyjątkiem następujących środowisk:

• 64-bitowe systemy Solaris, które wymagają interfejsu API klienta TSM w wersji 4.2.1.
• 64-bitowe systemy operacyjne Windows NT, które wymagają interfejsu API klienta TSM w wersji 5.1.
• 32-bitowe systemy Linux dla iSeries i pSeries, które wymagają interfejsu API klienta TSM w wersji przynajmniej 5.1.5.
• 64-bitowe systemy Linux dla iSeries i pSeries, które wymagają interfejsu API klienta TSM w wersji przynajmniej 5.3.
• 64-bitowe systemy Linux na platformach AMD Opteron, które wymagają interfejsu API klienta TSM w wersji przynajmniej 5.2.0.
• 64-bitowe systemy Linux dla zSeries, które wymagają interfejsu API klienta TSM w wersji przynajmniej 5.2.2.

Ograniczenia wartości dla parametrów lokalnego hosta HADR i usług lokalnych

Wartości parametrów lokalnego hosta i lokalnych usług mechanizmu usuwania skutków awarii w środowiskach o wysokiej dostępności (HADR_LOCAL_SVC i HADR_REMOTE_SVC) określane w ramach przygotowywania komendy aktualizacji konfiguracji bazy danych muszą być portami, które nie są używane przez żadną inną usługę. Jeśli parametry te są konfigurowane za pomocą wiersza komend systemu Linux lub UNIX, ich wartości należy ustawić również w pliku /etc/services.

Dodatkowe wymagania systemowe mechanizmu usuwania skutków awarii w środowiskach o wysokiej dostępności

Jeśli po utworzeniu obszaru tabel w podstawowej bazie danych odtworzenie protokołu w rezerwowej bazie danych nie powiedzie się, ponieważ kontenery są niedostępne, podstawowa baza danych nie zostanie poinformowana o tym niepowodzeniu komunikatem o błędzie.

Aby sprawdzić błędy odtwarzania protokołu, należy podczas tworzenia obszarów tabel monitorować protokół db2diag.log i protokół administracyjny w rezerwowej kopii bazy danych.

W razie przełączenia awaryjnego nowy obszar tabel nie będzie dostępny w nowej podstawowej bazie danych. W tej sytuacji należy odtworzyć obszar tabel w nowej bazie podstawowej z kopii zapasowej.

W poniższym przykładzie obszar tabel MÓJ_OBSZAR_TABEL jest odtwarzany w bazie danych MOJA_BAZA_DANYCH przed użyciem tej bazy jako podstawowej bazy danych:

1. db2 connect to moja_baza_danych
2. db2 list tablespaces show detail
   Uwaga:
   Uruchom komendę db2 list tablespaces show detail, aby wyświetlić status wszystkich obszarów tabel i uzyskać numer identyfikacyjny obszaru tabel wymagany w kroku 5.
3. db2 stop hadr on database moja_baza_danych
4. db2 "restore database moja_baza_danych tablespace (mój_obszar_tabel) online redirect"
5. db2 "set tablespace containers for identyfikator_mojego_obszaru_tabel_# ignore rollforward container operations using (path '/ścieżka_do_mojego_nowego_kontenera/')"
6. db2 "restore database moja_baza_danych continue"
7. db2 rollforward database moja_baza_danych to end of logs and stop tablespace "(mój_obszar_tabel)"
8. db2 start hadr on database moja_baza_danych as primary

Operacje niereplikowane i mechanizm usuwania skutków awarii w środowiskach o wysokiej dostępności

W dokumentacji wersji 8.2 napisano:

Obiekty BLOB i CLOB nie są replikowane, jednak jest im przydzielane miejsce w rezerwowej bazie danych.

Zdanie to powinno wyglądać następująco:

Nieprotokołowane obiekty BLOB i CLOB nie są replikowane, jednak jest im przydzielane miejsce w rezerwowej bazie danych.

Mechanizm HADR nie obsługuje surowych operacji we/wy dla protokołów

Mechanizm usuwania skutków awarii w środowiskach o wysokiej dostępności (HADR) nie obsługuje surowych operacji we/wy (bezpośredni dostęp do dysku) dla plików protokołów bazy danych. Jeśli mechanizm HADR jest uruchamiany komendą START HADR lub jeśli baza danych jest restartowana ze skonfigurowanym mechanizmem HADR i zostaną wykryte surowe operacje we/wy dla protokołów, powiązana komenda nie powiedzie się z błędem SQL1768N, kod przyczyny "9".

Porównanie monitora uszkodzeń i monitora poprawności

Monitor poprawności i monitor uszkodzeń są to narzędzia działające na pojedynczej instancji bazy danych. Monitor poprawności używa indykatorów poprawności w celu oceny poprawności konkretnych aspektów wydajności menedżera bazy danych lub wydajności bazy danych. Indykator poprawności mierzy poprawność pewnych aspektów konkretnej klasy obiektów bazy danych, takich jak obszar tabel. Indykatory poprawności można ocenić w porównaniu do konkretnych kryteriów w celu określenia poprawności tej klasy obiektów bazy danych. Ponadto indykatory poprawności mogą generować alerty w celu powiadomienia użytkownika, gdy indykator przekroczy próg lub gdy obiekt bazy danych nie jest w normalnym stanie

W porównaniu monitor uszkodzeń jest odpowiedzialny wyłącznie za zapewnienie działania i dostępności monitorowanej instancji. Jeśli monitorowana instancja programu DB2 UDB zostanie nieoczekiwanie zakończona, monitor uszkodzeń zrestartuje daną instancję. Monitor uszkodzeń jest niedostępny w systemie Windows.

Wyłączanie monitorowania uszkodzeń

Aby wyłączyć monitorowanie uszkodzeń dla instancji bazy danych DB2INST1, należy wpisać następującą komendę w oknie komend programu DB2 UDB:

   db2fm -i db2inst1 -f no

Aby potwierdzić, że monitor uszkodzeń już nie działa dla instancji DB2INST1, należy w systemach UNIX wpisać następującą komendę:

   ps -ef|grep -i fm

W systemach Linux należy wpisać następującą komendę:

   ps auxw|grep -i fm

Wpis zawierający termin db2fmd i DB2INST1 oznacza, że monitor uszkodzeń nadal działa dla danej instancji. Aby wyłączyć monitor uszkodzeń, należy wpisać następującą komendę jako właściciel instancji:

   db2fm -i db2inst1 -D