Oracle Standard Edition One 11G standby
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
- Zbieramy informacje:
- 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.
- 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
- 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
- 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
- Położenie wszystkich plików danych
- 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
- 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
- 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.
- Ustawiamy ścieżki dla archivelogów:
SQL> alter system set log_archive_dest_1='location=d:\archivelog' scope=both;
- Wyłączamy na chwilę obie bazy (primary i standby)
SQL> shutdown immediate
- 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;
- Startujemy baze primary
SQL> startup
- Robimy kopię pliku kontrolnego dla bazy standby i kopiujemy go na serwer standby:
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'd:\control_primary.ctl';
- 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. 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
- 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'
- Sprawdzamy czy ścieżka do katalogu z archivelogami się zgadza:
*.log_archive_dest_1='location=d:\Archivelog'
- 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'
- Startujemy bazę standby w trybie nomount:
sqlplus /nolog SQL> connect /as sysdba SQL> startup nomount pfile=d:\pfile_primary.ora
- Aktywujemy bazę:
SQL> alter database mount standby database;
- Teraz w celu synchronizacji kopiujemy archivelogi z primary na standby i wczytujemy:
SQL> recover standby database;
SPRAWDZAMY
- W celu sprawdzenia przełączamy bazę w tryb read only i dopiero wtedy możemy robić selecty:
SQL> alter database open read only;
- 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
- 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:
- 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;
- 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
- 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ł)
- Innym sposobem jest udostępnienie zasobu za pomocą NFS.
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ę 😉
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.
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 ?
W przypadku awarii baza standby może być zmieniona w primary, ale już odwrotnie nie.
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
RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;
vous aimeriez louer un box en Suisse ? Easystock
vous recommande des box individualisés et a le pouvoir de vous accompagner pour votre nouvelle
installation en louant un véhicule utilitaire instantanément chez eux.
Certains objets sont employés dans la vie de tous les jours alors pourquoi pas les customiser avec votre
marque ou avec votre publicité ? le site internet magic-print.
com est apte à vous accompagner pour les réaliser.