Dataguard üzerinde zaman zaman switchover ile Dataguard ve Primary sunucularında rol değişimi yapmamız gerekebilir. Örneğin, Production ortamlarında yaşanacak disaster durumunda Dataguardları Primary olarak açmamız gerekecektir veya Primary olan sunucu üzerinde yapılacak olan (donanımsal bir işlem olabilir) bir çalışma nedeniyle eğer kesinti yapmamıyorsanız DG ‘ ı primary yaparak kullanıcılarının etkilenmeden gerekli işlemi yapıp, sonra tekrar bir switchover ile primary database’ i aktif edebilirsiniz. Bu operasyonu dataguard broker’ ı kullanarak da yapabilirsiniz. DGMGRL ile bu işlemin nasıl yapılacağından daha önce bahsetmiştim. Şimdi bu işlemleri manuel nasıl yapabileceğimizden bahsedelim;
— Öncelikle Primary database’ imizin switchover’ a işlemine hazır olup olmadığı kontrol ediyoruz;
SQL>select switchover_status from v$database ;
Switchover_status
—————–
TO STANDBY
Bu sorgunun sonucu TO STANDBY olmalı, farklı bir sonuç döndürür ise aşağıdaki sorgu ile tüm sessionlar kill edebiliriz. (Bağlı bulunduğunuz session hariç tabiki)
select ‘alter system kill session ”’||s.sid||’,’|| s.serial# ||”’ immediate;’ kill_command, p.spid ospid
from v$session s, v$process p
where s.PADDR = p.addr
and s.type=’USER’
and s.sid not in (select userenv(‘SID’) sid from dual )
KILL_COMMAND OSPID
alter system kill session ‘1610,158’ immediate; 1144
alter system kill session ‘1629,921’ immediate; 4464
— TO_STANDBY sonucunu gördükden sonra primary database’ imizi DG’ a convert etmekle devam ediyoruz;
SQL>alter database commit to switchover to physical standby with session shutdown;
Database altered.
Bu işlem yapılırken Alert logumuza aşağıdaki satırlar düşecektir.
Sun Sep 11 14:43:43 2011
alter database commit to switchover to physical standby with session shutdown
Sun Sep 11 14:44:37 2011
Thread 1 advanced to log sequence 55
Current log# 1 seq# 55 mem# 0: C:\ORACLE\10G\ORADATA\PROD\REDO01.LOG
Sun Sep 11 14:44:47 2011
SMON: disabling tx recovery
Sun Sep 11 14:44:47 2011
Stopping background process QMNC
Sun Sep 11 14:44:47 2011
Thread 1 advanced to log sequence 56
Current log# 2 seq# 56 mem# 0: C:\ORACLE\10G\ORADATA\PROD\REDO02.LOG
Sun Sep 11 14:44:48 2011
Stopping background process CJQ0
Sun Sep 11 14:44:48 2011
Stopping Job queue slave processes
Sun Sep 11 14:44:48 2011
Job queue slave processes stopped
Sun Sep 11 14:44:49 2011
SMON: disabling cache recovery
Sun Sep 11 14:44:49 2011
Shutting down archive processes
Archiving is disabled
Sun Sep 11 14:44:54 2011
ARCH shutting down
ARCa: Archival stopped
Sun Sep 11 14:44:59 2011
ARCH shutting down
ARC9: Archival stopped
Sun Sep 11 14:45:05 2011
ARCH shutting down
ARC8: Archival stopped
Sun Sep 11 14:45:10 2011
Sun Sep 11 14:45:46 2011
Thread 1 closed at log sequence 56
Successful close of redo thread 1
Sun Sep 11 14:45:46 2011
ARCH: Noswitch archival of thread 1, sequence 56
ARCH: End-Of-Redo Branch archival of thread 1 sequence 56
ARCH: Archiving is disabled due to current logfile archival
Clearing standby activation ID 169747395 (0xa1e23c3)
The primary database controlfile was created using the
‘MAXLOGFILES 16’ clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE ‘srl1.f’ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl2.f’ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl3.f’ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl4.f’ SIZE 52428800;
Archivelog for thread 1 sequence 56 required for standby recovery
MRP0 started with pid=10, OS id=5216
Managed Standby Recovery not using Real Time Apply
Online logfile pre-clearing operation disabled by switchover
Media Recovery Log D:\ORACLE\ARCH\ARCH_1_56_757897900_.ARC
Identified End-Of-Redo for thread 1 sequence 56
Sun Sep 11 14:45:56 2011
Media Recovery End-Of-Redo indicator encountered
Sun Sep 11 14:45:56 2011
Media Recovery Applied until change 7526065
Resetting standby activation ID 169747395 (0xa1e23c3)
Sun Sep 11 14:45:57 2011
Waiting for MRP0 pid 5216 to terminate
Completed: alter database commit to switchover to physical standby with session shutdown
Bu işlemler sırasında Standby tarafındaki alertlog dada aşağıdaki satırları görürsünüz;
— standby alertlog file ;
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE ‘D:\ORACLE\ARCH\ARCH_1_54_757897900_.ARC’;
Redo Shipping Client Connected as PUBLIC
— Connected User is Valid
RFS[7]: Assigned to RFS process 2736
RFS[7]: Identified database type as ‘physical standby’
RFS[7]: No standby redo logfiles created
RFS[7]: Archived Log: ‘D:\ORACLE\ARCH\ARCH_1_54_757897900_.ARC’
Sun Sep 11 14:41:55 2011
Media Recovery Log D:\ORACLE\ARCH\ARCH_1_54_757897900_.ARC
Sun Sep 11 14:41:57 2011
Redo Shipping Client Connected as PUBLIC
— Connected User is Valid
RFS[8]: Assigned to RFS process 2900
RFS[8]: Identified database type as ‘physical standby’
RFS[8]: No standby redo logfiles created
RFS[8]: Archived Log: ‘D:\ORACLE\ARCH\ARCH_1_55_757897900_.ARC’
Sun Sep 11 14:42:00 2011
Media Recovery Log D:\ORACLE\ARCH\ARCH_1_55_757897900_.ARC
Media Recovery Waiting for thread 1 sequence 56
Sun Sep 11 14:42:56 2011
Redo Shipping Client Connected as PUBLIC
— Connected User is Valid
RFS[9]: Assigned to RFS process 3836
RFS[9]: Identified database type as ‘physical standby’
RFS[9]: Archived Log: ‘D:\ORACLE\ARCH\ARCH_1_56_757897900_.ARC’
Sun Sep 11 14:43:00 2011
Media Recovery Log D:\ORACLE\ARCH\ARCH_1_56_757897900_.ARC
Identified End-Of-Redo for thread 1 sequence 56
Sun Sep 11 14:43:01 2011
Media Recovery End-Of-Redo indicator encountered
Sun Sep 11 14:43:01 2011
Media Recovery Applied until change 7526065
Resetting standby activation ID 169747395 (0xa1e23c3)
— Eski primary database’ imizi artık kapatıp mount modda açabiliriz;
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 419430400 bytes
Fixed Size 1249320 bytes
Variable Size 150999000 bytes
Database Buffers 260046848 bytes
Redo Buffers 7135232 bytes
Database mounted.
SQL>
— Eski primary database’ imiz standby için hazır, sıra Standby database’ imizi Primary rolünü atamaya geldi. İşleme başlamadan önce standby database’ imizin switchover_statüsünü kontrol ediyoruz;
select switchover from v$database;
Switchover_status
—————–
TO PRIMARY
TO_PRIMARY sonucunun dönmesi gerekiyor. SESSION ACTIVE dönerse apply işlemi devam ediyor olabileceğinden kontrol etmekde fayda olacaktır. TO_PRIMARY sonucunu gördüğümüzü varsayarak devam ediyorum. (Farklı bir değer dönüyor ise primary de olduğu gibi diğer sessipnları kill etmeniz gerekir.)
SQL>alter database commit to switchover to primary with session shutdown ;
Database altered.
alter database open ;
Database opened.
— Yeni standby database’ imizde artık apply işlemini başlatabiliriz;
SQL>alter database recover managed standby database disconnect from session ;
Database altered.
Bu işlemleri tekrar ettiğimizde herşey eski haline dönmüş olacaktır. Aslında switchover operasyonu özetle bu kadar diyebiliriz.
Merhabalar öncelikle böyle bir döküman hazırladıgınız için ellerinize saglık benim sormak istedigim soru ise benim kurulu bir stand by yapım var ben bunun 10 sn senkronizasyonla çalışmasını istiyorum (primary kayıt girdikten 10 sn sonra da stand by ‘a yazmasını istiyorum) bunun için ne yapabilirim.Teşekürler
Mustafa Merhaba,
Primary ile Standby’ ın senkron olmasını istemiyorsan, belirli bir süre geriden gelmesini amaçlıyorsan Delay parametresini kullanabilirsin.
Delay değeri dakika cinsinden dolayısıyla buna göre planlaman gerekiyor.
Kullanımı ile ilgili bir örnek ;
LOG_ARCHIVE_DEST_2=’SERVICE=stby DELAY=10′
İptal etmek istersen bu değeri parametreyi kaldırabilir veya aşağıdaki komutu çalıştırabilirsin.
physical standby database ise;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
Logical standby database ise;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
Merhaba hocam.
Tebrik ederim, ellerine saglik cox iyi olmus.
Mahir M. Quluzade