Data Guard

To, co zrobiono z Standby Database podczas przejścia z 8i na 9i zasługuje na wyrazy zachwytu:
  1. Oracle9i Data Guard + Oracle Data Guard Broker - to zwyczajna zmiana nazwy ze Standby Database w 8i. Data Guard Broker to framework upraszczający zarządzanie Data Guardem: zapewnia interfejs GUI + CLI do sterowania DataGuardem (DG).
  2. no data loss - można ustawić taki tryb pracy instancji standby, w którym baza główna zatwierdzi modyfikacje dopiero po otrzymaniu potwierdzenia od standby.
  3. no data divergence - w charakterze gadżetu.
  4. Database switchover - Interesujące - ma zapewniać możliwość płynnego przechodzenia pomiędzy bazą główną (primary), a standby i z powrotem. Bez konieczności dodatkowej synchronizacji.
  5. archive gaps are automatically detected and transmitted
  6. adding new datafiles - automatycznie dodawanie plików na standby.
  7. background managed recover mode - recovery w tle, SQLPlus do dyspozycji.
  8. standby redo logs, archiver process on standby database - zupełna nowość do rozpoznania.
  9. changes to archiving online redo logs - archive current redo log, archive an online redo log when a backup controlfile is being used.
  10. archive log repository - archivelogi transportowane do standby i tam dopiero archiwizowane.

Wymagania w standby database

  1. Baza produkcyjna w trybie archivelog.
  2. Ten sam release bazy produkcyjnej i standby.
  3. Ten sam system operacyjny bazy produkcyjnej i standby, tutaj release może się różnić. Czyli, teoretycznie baza produkcyjna może być na Solaris 2.9, a standby na Solaris 2.7.
  4. Hardware i architektura systemu musi być ta sama (sparc, intel). Produkcyjna instancja 64-bitowa musi mieć 64-bitową instancję standby.
  5. Struktura katalogów może być inna niż w bazie produkcyjnej.

Ograniczenia Logical Standby Database

  1. wspierane typy danych:
  2. typy niewspierane: NLOB, LONG, LONG RAW, BFILE, ROWID, UROWID
  3. niewspierane tabele i sekwencje:
Widok DBA_LOGSTDBY_UNSUPPORTED służy do wylistowania obiektów nieadekwatnych do umieszczenia w logical standby database.

Wiersze w tabelach przeznaczonych do umieszczenia w logicznej bazie standby muszą być jednoznacznie identyfikowane. Oracle Corp. nalega na umieszczenie PK na każdej tabeli. Jeżeli brak PK lub unikalnego indeksu, do dzieła zaprzęgany jest tzw. supplemental logging. Tabele nieposiadające PK, i w związku z tym wymuszające supplemental logging, można znaleźć w widoku DBA_LOGSTDBY_NOT_UNIQUE. Jeżeli jest to możliwe, warto zdefiniować PK, aby zwiększyć wydajność, eliminując supplemental logging.

Słowniczek

Supplemental Logging

Normalnie tylko minimalna ilość informacji zapisywana jest w plikach dziennika powtórzeń. W pewnych sytuacjach jest ona niewystarczająca i do logów może trafiać więcej danych. Przykładowo: Standardowo supplemental logging jest całkowicie wyłączony. Włączenie supplemental loggingu na minimalnym poziomie nie ma większego wpływu na degradację wydajności. Z drugiej strony, włączenie maksymalnego loggingu na poziomie bazy danych wpłynie negatywnie na wydajność.

Rodzaje supplemental loggingu:

Supplemental logging jest szczegółowo omówiony w DAG 9-19.

Literatura

  1. [DAG]Database Administrator Guide 9.2

© 11.03.2004 Jerzy Kędra