Data Guard

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:
   • CHAR, NCHAR, VARCHAR, VARCHAR2, NVARCHAR2, NUMBER, DATE
   • TIMESTAMP, TIMESTAMP WITH TIMEZONE
   • INTERVAL YEAR TO MONTH, INTERVAL YEAR TO SECOND
   • RAW CLOB BLOB
2. typy niewspierane: NLOB, LONG, LONG RAW, BFILE, ROWID, UROWID
3. niewspierane tabele i sekwencje:
   • tabele i sekwencje schematu SYS
   • tabele dla indeksów funkcyjnych (?)
   • tabele dla materializowanych widoków
   • global temporary tables

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

• Logiczna baza standby działa na zasadzie rekonstruowania wyrażenia SQL i aplikowania go do wybranych tabel. Ponieważ logiczna baza standby jest jednak inną bazą od produkcyjnej (nie tak jak w przypadku physical standby database), w przypadku wyrażenia modyfikującego wiersz nie może być stosowany normalnie zapisywany w redo ROWID, jednoznacznie identyfikujący wiersz w przypadku bazy produkcyjnej lub fizycznej bazy standby. W takim przypadku zachodzi potrzeba użycia klucza głównego jako identyfikatora wiersza. Te zaś standardowo nie są zapisywane do dziennika powtórzeń, o ile ich wartość nie zmienia się.
• Niektórym aplikacjom pomocne byłoby zapisywanie do pliku dziennika powtórzeń całego obrazu wiersza przed modyfikacją, a nie tylko modyfikowanej kolumny.

Rodzaje supplemental loggingu:

• database supplemental logging
  • minimal - dostarcza niezbędnych danych do identifikacji i łączenia operacji DML aby wspierać łańcuchowanie i m.in. klastry. W większość wypadków należy włączyć przynajmniej minimalne logowanie na tym poziomie za pomocą wyrażenia: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
  • identification key logging - włącza logowanie obrazu (before-image) PK lub indeksów unikalnych podczas wszystkich zmian. Dzięki temu można identyfikować modyfikowane wiersze w sposób logiczny, zamiast ROWID. Identification key logging potrzebne jest dla logicznej bazy danych. Włącza się za pomocą:

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS

    Jeżeli tabela nie ma PK, a ma klucze unikalny - jeden z nich jest arbitralnie wybierany do supplemental loggingu. Zaś gdy tabela w ogóle nie ma PK ani UK, są logowane wszystkie kolumny za wyjątkiem tych z typami LONG i LOB. Niezależnie od włączonego logowania, zawsze zapisywany jest ROWID.

    Database supplemental logging na poziomie minimal lub identification key logging wyłącza się wyrażeniem:

    ALTER DATABASE DROP SUPPLEMENTAL LOG DATA

• table supplemental logging
  • unconditional log groups - podczas zmian wiersza logowany jest obraz (before-image) specyfikowanych kolumn bez względu na to czy ich wartości są modyfikowane. Tzw. ALWAYS log group.

    ALTER TABLE scott.emp ADD SUPPLEMENTAL LOG GROUP emp_parttime (empno, ename, deptno) ALWAYS

    Powyższe tworzy grupę emp_parttime składającą się z wymienionych kolumn. Będą one logowane za każdym razem gdy UPDATE będzie odnosić się do tabeli scott.emp.

  • conditional log groups - podczas zmian wiersza logowany jest obraz specyfikowanych kolumn jeżeli przynajmniej jedna z nich jest modyfikowana podczas zmiany.

    ALTER TABLE scott.emp ADD SUPPLEMENTAL LOG GROUP emp_fulltime (empno, ename, deptno)

    Kolumna może należeć do więcej niż jednej grupy.

1. [DAG]Database Administrator Guide 9.2