Zarejestruj się na BitBay.net
Home > Oracle > Oracle Standard Edition One 11G standby

Oracle Standard Edition One 11G standby

oracle Rezerwowa baza standby jest fizyczną lub logiczną kopia bazy podstawowej i działa na zasadzie rekonstruowania wyrażeń SQL ze zarchiwizowanego dziennika powtórzeń i aplikowania ich do wybranych tabel. Przeważnie utrzymywana jest ona na osobnym komputerze i w przypadku awarii bazy podstawowej, rezerwowa bazy przechodzi z trybu standby w tryb read write i przejmuje obowiązki głównej bazy.

Ponieważ Oracle Standard Edition One 11G nie posiada funkcjonalności Oracle Data Guard (Data Guard is a semi-automated standby/failover database for database replication.), sami musimy się zatroszczyć o kopiowanie archivelogów z bazy podstawowej do zapasowej.

Wymagania dla tego opisu:

  • Baza produkcyjna w musi działać w trybie archivelog.
  • Ten sam release bazy produkcyjnej i standby.
  • Zakładamy że lokalizacje wszystkich plików bazy danych standby są takie same jak na bazie podstawowej (primary).
  • Instalujemy czystą bazę standby – nie tworzymy żadnych tablespace itd.
  • Opis dotyczy bazy zainstalowanej na Windows 2008, ale na linuxie jest analogicznie.

BAZA PRIMARY

  1. Zbieramy informacje:
    1. Położenie wszystkich plików danych
      SQL> select status, enabled, name from V$DATAFILE;

      lub

      SQL> select file_name from dba_data_files;
      
      FILE_NAME
      -------------------------------
      
      D:\DB-DANE\HARTX\USERS01.DBF
      D:\DB-DANE\HARTX\UNDOTBS01.DBF
      D:\DB-DANE\HARTX\SYSAUX01.DBF
      D:\DB-DANE\HARTX\SYSTEM01.DBF
      D:\DB-DANE\HARTX\HART02.DBF
      D:\DB-DANE\HARTX\HART07.DBF
      D:\DB-DANE\HARTX\HART09.DBF
      D:\DB-DANE\HARTX\HART10.DBF
      D:\DB-DANE\HARTX\HART01.DBF
      D:\DB-DANE\HARTX\HART04.DBF
      D:\DB-DANE\HARTX\HART03.DBF
      D:\DB-DANE\HARTX\HART11.DBF
      D:\DB-DANE\HARTX\HART12.DBF
      D:\DB-DANE\HARTX\HART05.DBF
      D:\DB-DANE\HARTX\HART06.DBF
      D:\DB-DANE\HARTX\HART08.DBF
      
      16 wierszy zostało wybranych.
    2. Położenie plików Redo Logów
      SQL> select MEMBER from V$LOGFILE;
      MEMBER
      -----------------------------
      
      D:\DB-DANE\HARTX\REDO03.LOG
      D:\DB-DANE\HARTX\REDO02.LOG
      D:\DB-DANE\HARTX\REDO01.LOG
    3. Położenie plików kontrolnych
      SQL> select NAME from V$CONTROLFILE;
      NAME
      -------------------------------
      
      D:\DB-DANE\HARTX\CONTROL01.CTL
      D:\DB-DANE\HARTX\CONTROL02.CTL
      D:\DB-DANE\HARTX\CONTROL03.CTL
    4. Położenie pliku z parametrami startowymi bazy
      SQL> select value from v$parameter where name like 'spfile';
      VALUE
      ------------------------------------------------------------------
      
      C:\APP\ADMINISTRATOR\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEHARTX.ORA
  2. Sprawdzanie czy baza działa w trybie archiwizacji redo logów
    select LOG_MODE from v$database;

    Jeśli nie – przełączamy ją w tryb archivelog
    Spradzamy czy działa:

    SQL> archive log list;
    Tryb dziennika bazy danych              Tryb archiwizacji
    Automatyczna archiwizacja             Włączona
    Miejsca archiwizowania            d:\Archivelog
    Najstarsza sekwencja dziennika online     1010
    Nastŕpna sekwencja dziennika do archiwizacji   1012
    Bieżąca sekwencja logowania           1012
  3. Normalnie tylko minimalna ilość informacji zapisywana jest w plikach dziennika powtórzeń co w przypadku replikacji bazy jest niewystarczające, dlatego też uruchamiamy logowania do redo logów wszystkich obiektów:
    SQL> ALTER DATABASE FORCE LOGGING;

    Sprawdzamy czy działa:

    SQL> SELECT force_logging FROM v$database
  4. Ustawiamy STANDBY_FILE_MANAGEMENT na auto:
    SQL> alter system set standby_file_management=auto scope=both;

    Ustawiony na AUTO tworzy lub usuwa automatycznie pliki po stronie bazy standby (jeśli nastąpiły takie zmiany w bazie podstawowej). W wersjach wcześniejszych wszelkie zmiany w strukturze bazy podstawowej trzeba było wprowadzać ręcznie po stronie bazy standby.

  5. Ustawiamy ścieżki dla archivelogów:
    SQL> alter system set log_archive_dest_1='location=d:\archivelog' scope=both;
  6. Wyłączamy na chwilę obie bazy (primary i standby)
    SQL> shutdown immediate
  7. Kopiujemy (cloud copy) wszystkie plików bazodanowe z punktu 1.a,b,c łącznie z redologami z serwera primary do standby.
    UWAGA: Jeśli nie chcemy wyłączać bazy możemy ją przełączyć w tryb backup i po skopiowaniu plików spowrotem w tryb nomrlany:

    SQL> ALTER DATABASE BEGIN BACKUP;
    SQL> ALTER DATABASE END BACKUP;
  8. Startujemy baze primary
    SQL> startup
  9. Robimy kopię pliku kontrolnego dla bazy standby i kopiujemy go na serwer standby:
    SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'd:\control_primary.ctl';
  10. Robimy kpie pliku startowego z bazy primary dla bazy standby i kopjujemy go na server standby:
    SQL> create pfile='d:\pfile_primary.ora' from spfile;

BAZA STANDBY
Zakładamy że odpowiednie pliki z serwera podstawowego są już skopiowane do standby w lokalizacje analogiczne jak na serwerze primary.
(controlfile, redologs, archivelogs, data files)

  1. 1. Podmieniamy pliki kontrolne na plik kopii control_primary.ctl:
    cd  D:\DB-DANE\hartx
    ren CONTROL01.CTL CONTROL01.CTL_old
    ren CONTROL02.CTL CONTROL02.CTL_old
    ren CONTROL03.CTL CONTROL03.CTL_old
    copy d:\CONTROL_PRIMARY.CTL D:\DB-DANE\hartx\CONTROL01.CTL
    copy d:\CONTROL_PRIMARY.CTL D:\DB-DANE\hartx\CONTROL02.CTL
    copy d:\CONTROL_PRIMARY.CTL D:\DB-DANE\hartx\CONTROL03.CTL
  2. Edytujemy pfile_primary.ora i sprawdzamy czy wszystkie ścieżki do plików kontrolnych się zgadzają:
    *.control_files='D:\DB-DANE\hartx\control01.ctl','D:\DB-DANE\hartx\control02.ctl','D:\DB-DANE\hartx\control03.ctl'
  3. Sprawdzamy czy ścieżka do katalogu z archivelogami się zgadza:
    *.log_archive_dest_1='location=d:\Archivelog'
  4. Jeśli pliki bazodanowe lub redologi na serwerze standby leżą w innej lokalizacji niż te na serwerze primary, musimy zmienić ich lokalizację ponieważ w controlfile będą ścieżki z bazy primary. Służą do tego poniższe wpisy:
    db_file_name_convert=’[datafile_primary_dir_path]‘,’[datafile_standby_dir_path]‘
    log_file_name_convert=’[redolog_primary_dir_path]‘,’[redolog_standby_dir_path]'

    czyli np:

    log_file_name_convert=’C:\app\Administrator\oradata\hartx‘,’D:\DB-DANE\HART'
  5. Startujemy bazę standby w trybie nomount:
    sqlplus /nolog
    SQL> connect /as sysdba
    SQL> startup nomount pfile=d:\pfile_primary.ora
  6. Aktywujemy bazę:
    SQL> alter database mount standby database;
  7. Teraz w celu synchronizacji kopiujemy archivelogi z primary na standby i wczytujemy:
    SQL> recover standby database;

SPRAWDZAMY

  1. W celu sprawdzenia przełączamy bazę w tryb read only i dopiero wtedy możemy robić selecty:
    SQL> alter database open read only;
  2. Później aby ponownie synchronizować, trzeba z powrotem uruchomić bazę standby w trybie w mount:
    SQL> shutdown immediate
    SQL> startup mount pfile=d:\pfile_primary.ora
  3. Możemy też na stałe podmienić plik startowy:
    SQL> shutdown immediate;
    SQL> create spfile from pfile='d:\pfile_primary.ora';
    SQL> startup mount

UŁATWIENIA
W celu automatyzacji procesu kopiowania i wczytywania archivelogów, można zrobić 2 proste skrypty:

  1. Skrypt do generowania i kopiowania archivelogów z primary do standby:
    ==copy_arch.cmd==

    set ORACLE_SID=hartx
    set ORACLE_HOME=C:\app\Administrator\product\11.1.0\db_1
    %ORACLE_HOME%\bin\sqlplus sys/password @copy_arch.sql
    ping 127.0.0.1
    robocopy D:\Archivelog \\192.168.1.113\d\Archivelog /MIR /COPY:DT /FFT /log:d:\copy_arch.log
    

    ==copy_arch.sql==

    ALTER SYSTEM SWITCH LOGFILE;
    exit;
  2. Skrypt do wczytywania archivelogów po stronie standby:
    ==apply_arch.cmd==

    set ORACLE_SID=hartx
    set ORACLE_HOME=C:\app\Administrator\product\11.1.0\db_1
    %ORACLE_HOME%\bin\sqlplus /nolog @ apply_arch.sql
    

    ==aply_arch.sql==

    connect sys/password as sysdba;
    set timing on
    set echo on
    spool apply_arch.log
    recover standby database;
    AUTO
    spool off
    exit
  3. W przypadku linuxa używamy rsynca:
    $ rsync -e ssh -Pazv /u01/oracle/arch/ oracle@oracles:/u01/oracle/arch/

    (oczywiście aby linux nie pytał się o hasło, trzeba zrobić uwierzytelnianie za pomocą certyfikatów a nie haseł)

  4. Innym sposobem jest udostępnienie zasobu za pomocą NFS.
Kategorie:Oracle Tagi:,
  1. Oracle
    Styczeń 11th, 2012 at 13:48 | #1

    Pamiętaj kolego, że komenda „alter database mount standby database;” jest częścią Oracle Data Guard, więc klient musi mieć licencję Oracle Database Enterprise Edition. Pochwal się u jakiego klienta zrobiłeś taką konfigurację 😉

  2. Styczeń 18th, 2012 at 15:10 | #2

    Aktywacja Data Guarda, łączy się z czymś więcej niż wywołanie tego mini-skryptu. Nie łamie to licencji SEO. Taką odpowiedź dostałem od Oracla. Pozdrawiam.

  3. mk
    Maj 29th, 2012 at 09:40 | #3

    a czy mogę potem w druga stronę ?
    czyli zamienić PRIMERY na STAND-BY i tak pracować a w potrzebie znowu się przełączyć używające tego samego mechanizmu ?

  4. Maj 29th, 2012 at 19:07 | #4

    W przypadku awarii baza standby może być zmieniona w primary, ale już odwrotnie nie.

  5. michal
    Lipiec 13th, 2016 at 11:44 | #5

    Wszystko fajnie, mam bazę standby ale teraz primary uległa awarii i co dalej 🙂 ? Jak przełączyć bazę w tryb read/write a później odtworzyć z niej uszkodzoną primary?

    Pozdrawiam

  1. Brak jeszcze trackbacków

*