Oracle 11.2.0.2 Data Guard performansını genel olarak değerlendirmek

Oracle 11.2.0.2 Data Guard standby veritabanlarını yapıya ilave ettikten sonra birincil veritabanı performansını doğru şekilde değerlendirmek için,  aynı uygulama profili ve yüklemesiyle Dataguard yapılandırmasının öncesinin ve  sonrasının V$SYSMETRIC_SUMMARY  görünümünden ve AWR snapshotlarından alınacak istatistik geçmişleriyla kıyaslanması gerekmektedir.

Data Guard standby uygulaması öncesinde ve sonrasında uygulama profilini değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         İşlem başına fiziksel okuma

·         İşlem başına fiziksel yazma

·         İşlem başına CPU kullanımı

·         İşlem başına redo üretimi

Uygulama performansını değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         Saniye başı redo üretimi veya redo oranı

·         Saniye başı kullanıcı commit işlemi veya saniye başı işlem

·         Saniye başı veritabanı zamanı

·         İşlem başına yanıt süresi

·         SQL servisi yanıt süresi

Oracle 11g Dataguard mimarisinde medya recovery hizmetlerinin iyileştirilmesi

Media recovery hizmetlerinin amacı, bir veritabanını uygun zaman dilimine geri döndürmek veya primary veritabanındaki tüm aktif işlemlerin birebir olarak fiziksel standby veritabanındada uygulanmasıdır. Zaten bu yazınında amacı Data Guard mimarisinde primary veritabanındaki işlemlerin fiziksel standby veritabanınında da uygulanması esnasında muhtemel darboğazlarını işaret etmek ve bunlarla ilgili gerekli iyileştirme işlemlerinin neler olduğunun gösterilmesidir.

Dataguard ortamında RMAN silme(deletion) ilkesinin yapılandırılması

Dataguard ortamında RMAN arşivlog silme(deletion) ilkesini tek bir merkez noktadan kontrol etmek için aşağıdaki adımlar izleyenebilir.

“Archivelog deletion” ilkesinin yapılandırılması

APPLIED ON STANDBY – Zorunlu standby olarak belirlenen standby sunucusu üzerinde uygulanan arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir.

NONE – Üçüncü derece cihazlara yedeklenen ve yapılandırılmış backup retention ilkesina bağlı olarak geçerliliğini yitirmiş arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir. Bu varsayılan ayardır.

CLEAR – Silme ilkesini temizler ve konfigürasyonu varsayılan değere döndürür.

Standby veritabanında “ORA-02290: check constraint (RMAN.AL_C_STATUS) violated” hata mesajı

Bu hata mesajı ile birkaç hafta önce uzun bir tatil dönüşü sonunda bir yedekleme sorunu üzerinde çalışırken karşılaştım. Yedek, standby veritabanında alınmakta ve recovery katalog kullanılmaktaydı. Oracle sürümü ise Oracle 10.2.0.4

Stanby veritabanında RMAN operasyonu ile katalog veritabanı bağlantı denemeleri aşağıdaki hata mesajı ile sonlandırılmaktaydı:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of list command at 06/27/2011 09:01:57

RMAN-03014: implicit resync of recovery catalog failed

RMAN-03009: failure of partial resync command on default channel at 06/27/2011 09:01:57

ORA-02290: check constraint (RMAN.AL_C_STATUS) violated

Görünüşe göre hiçbir yedek yok! Halbuki primary veritabanında aynı işlemi yaptığımda bir hata ile karşılaşmıyorum, ancak primary üzerinde ise yedek almak için yeterli boş alan yok.

LOG_ARCHIVE_MAX_PROCESSES değerinin ayarlanması

Oracle LOG_ARCHIVE_MAX_PROCESSES parametresi Oracle tarafından başlangıçta çağrılan aktif ARCH proseslerinin(ARC0-ARCn) sayısını belirtir. LOG_ARCHIVE_MAX_PROCESSES parametresinin değeri,Oracle 10g itibariyle LOG_ARCHIVE_START başlangıç parametresinin geçersiz olmasına rağmen TRUE olarak ayarlandığında değerlendirmeye alınır. Oracle’da yüksek uygunluğa erişmek, Oracle’ı enterprise veritabanı olarak kullanan herkesin hayalidir ve bu hedefe ulaşmak için öncelikle LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesi sıklıkla tavsiye edilmektedir. Bu yazıda, LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesinin her zaman veritabanı sisteminde en iyi çözüm olmadığını ve LOG_ARCHIVE_MAX_PROCESSES  değerini ayarlarken neden dikkatli olunmasını inceleyeceğiz.

Oracle 11g aktif standby veritabanında otomatik blok bozulması tamiri işlemi

Oracle 11g Active Data Guard özelliğinde gerçek zamanlı sorgu yeteneğinin yanında, Otomatik Blok Medya Düzeltme(Automatic Block Media Repair) özelliği ile daha yüksek erişilebilirlik yeteneği olduğu gözükmektedir. Primary veritabanındaki veri blok bozulmalarını standby siteden bu bozulan blokları elde etmek suretiyle ABMR arkaplan prosesi tarafından tamir edilebilmektedir.

Aynı fonksiyon, aktif standby sitedeki blok bozulmalarını primary siteden aynı şekilde bozulmamış blokların elde edilmesiyle tamir edilmesi yoluylada  kullanılabilmektedir. Aşağıdaki senaryoda bu durumu test edeceğiz.

Bu test senaryosunda kullanılmak üzere bir tablo oluşturup USERS tablespace içine atayacağız.

SQL> create table testtbl
tablespace users
as select * from hr.emp;

Table created.

DBMS_ROWID fonksiyonunu kullanarak bu tablonun kullandığı blokları belirliyoruz.

SQL> select * from
(select distinct dbms_rowid.rowid_block_number(rowid)
from testtbl)
where rownum < 6;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
12
13
14
15
16

Ardından bu bloklardan herhangi birisini bozuyoruz (senaryomda 13 numaralı bloğu bozuyorum, bu testi kesinlikle gerçek üretim veritabanınızda yapmayın!)

Eşzamanlı redo taşıma cevap süresinin izlenmesi

V$REDO_DEST_RESP_HISTOGRAM görünümü her bir redo taşıma hedefi için taşıma esnasındaki cevap süresi bilgilerini kaydeder. Bu cevap süresi verisi, eşzamanlı redo taşıma yöntemiyle gönderilen redo taşıma mesajlarında iyileştirme yapmak amacıyla kullanılmaktadır. Bilhassa birden fazla standby veritabanı olan ve primary veritabanı ile WAN bağlantısı yoluyla veri iletişimi yapan standby sunucularda bu değerin ölçümü proaktif iyileştirme için önem kazanmaktadır.

Her istikametteki veri, her bir cevap süresi bir satırdan olmak üzere dizi dizi satır serilerinden meydana gelir. Kayıt tutmayı kolaylaştırmak için 300 saniyeden düşük cevap süreleri en yakın tam sayıya yuvarlanır. 300 saniyeden büyük cevap süreleri ise 600,1200,2400 veya 9600 saniyeye yuvarlanır.

Oracle 11.2 Dataguard ortamında Oracle Restart servisi ile Fast Application Notification(FAN) olayları

Oracle 11g Dataguard mimarisinde FAN(Fast Application Notification) olaylarının Oracle Restart servisi yoluyla etkinleştirilmesi için öncelikle Oracle Restart sunucularını ve entegre istemcilerini içeren Oracle Notification Service(ONS) networkunun oluşturulması gerekmektedir. Bu entegre istemciler Oracle Bağlantı Yöneticisi(CMAN), Java Veritabanı Bağlayıcısı(JDBC) veya Universal Connection Pool(UCP) istemcileri olabilir.  ONS networku ile primary veritabanında meydana gelen bir failover durumunda, FAN olayları DOWN durumunu işaret ederek standby sunuculara Dataguard Broker tarafından yayınlanacaktır. CMAN, JDBC ve UCP ile bağlı olan uygulamalar, Fast Connection Failover(FCF) özelliği kullanılarak, failover durumundan etkilenmeden otomatik olarak yeni primary veritabanına bağlantı açarlar.

Oracle Restart primary veritabanını izleyerek DOWN olayı meydana geldiğinde istemcilere, bu düşen veritabanı ile bağlantılarını sonlandırması için FAN duyurusu yapar ve UP olayı meydana geldiğindede yeni bir FAN duyurusu ile yeni primary rolüne bürünenen eski standby veritabanı üzerinden yeni bağlantılar açılır.

Oracle 11g Dataguard platformunda, Oracle Restart servisinin etkinleştirilerek ASM, listener ve servislerin otomatik olarak başlatılması için gereken yapılandırma ile birlikte FAN olaylarının Oracle Restart içerisinde kayıt edilmesi adımları aşağıda yer almaktadır. Senaryoda Oracle Restart özelliği Dataguard yapılandırmasından sonra etkinleştirilmiştir.

1. Primary ve standby sunucularda Oracle DataGuard Broker kurulduğundan emin olun. Oracle DataGuard kurulumu ile ilgili yazımı inceleyebilirsiniz.
2. Hem primary hem standby sunucularda root hesabından oturum açarak,Oracle Restart özelliği etkinleştiriliyor. Böylece sunucunun her açılışında açılışı sağlayacak olan Oracle High Availability Servisi, namı diğer “Oracle Restart” otomatik başlamaya ayarlanmış oluyor.

# crsctl enable has

CRS-4622 Oracle High Availability Services autostart is enabled.

3. Primary sunucu üzerinde, ilgili primary veritabanı Oracle Restart konfigürasyonuna eklenmelidir. Ardından, bu primary sunucu üzerindeki Oracle Restart konfigürasyonuna varsa ASM instance ve listenerda eklenmelidir.

$ srvctl add database -d orcldg –r primary -o /u01/app/oracle/product/11.2.0/db_1 à DB_UNIQUE_NAME=orcldg olan ve –o ile belirtilen db_home dizininde primary rolünde olan veritabanı Oracle Local Registry(OLR) içine ekleniyor

Data Guard Broker mimarisinde Fast-Start failover özelliğinin etkinleştirilmesi

Primary veritabanına olan bağlantı kaybolduğu durumlarda daha önceden seçilen standby veritabanına Data Guard Broker prosesinin otomatik olarak failover işlemini yapması özelliğidir.  Fast-Start Failover özelliği sadece Data Guard Broker yapılandırması içinde kullanılır ve DGMRL komut satırı veya Enterprise Manager konsolu üzerinden etkinleştirilir.

Hem maksimum erişilebilirlik hemde maksimum performans modunda çalışabilmektedir.Maksimum erişilebilirlik modu seçili olduğunda sıfır veri kaybı garanti edilmektedir.  Maksimum performans modu seçili olduğu durumda ise FastStartFailoverLagLimit konfigürasyon parametresi ile belirlenen saniye içerisindeki veriden daha fazlasının kaybı önlenmiş olmaktadır.

Herhangi bir failover durumunda broker’ın kesintisiz çalışmasını sağlamak için, gözlemciyi primary ve standby veritabanları dışında bir makineye kurmak faydalı olacaktır. Hem Dataguard Broker hemde standby veritabanı, primary veritabanı ile bağlantıyı FastStartFailoverThreshold parametresinde belirlenen süreden daha uzun sürede kaybettiği zaman, broker standby veritabanına doğru fast-start failover işlemini tetikler. Buna ilaveten, eğer FastStartFailoverPmyShutdown parametresi TRUE olarak ayarlanmışsa, FastStartFailoverThreshold parametresindeki süreden daha uzun süreli kesinti durumunda primary veritabanı kapatılır.

Data Guarda bağlı bekleme olayları

Primary veritabanından standby veritabanına redo gönderirken ayrılan zaman iki ana bölüme ayrılır, networkun bir ucundan diğer ucuna geçerken zaman ve standby sunucu üzerinde diske yazarken geçen zaman. I/O olurken geçen zaman esnasında primary veritabanında sağlanan toplam zamanı ele geçiren bekleme olayları standby üzerinde izlenebilir.

Primary veritabanınından standby veritabanına ARCH veya LGWR prosesleri ile redo gönderirken meydana gelen bekleme olayları altta yer almaktadır. Bu veriler primary veritabanından elde edilir.

Olay İsmi	Proses	Tanımı
ARCH wait on ATTACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından yeni RFS bağlantıları meydana getirme süresindeki geçen süreyi izler.
ARCH wait on SENDREQ	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından arşiv dosyalarını standbya yazmakla birlikte lokal diskede yazma esnasında geçen süreyi izler.
ARCH wait on DETACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından RFS bağlantısını silme esnasında geçen süreyi izler.
LNS wait on ATTACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından  yeni bir RFS bağlantısı meydana getirme süresindeki geçen süreyi izler.
LNS wait on SENDREQ	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından alınan redoları diske yazmakla birlikte standby arşiv redo dosyalarını açmak ve kapatmak sırasında geçen süreyi izler.
LNS wait on DETACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından RFS bağlantısını silme sürecindeki geçen süreyi izler.
LGWR wait on LNS	LGWR	Bu bekleme olayı LNS prosesinden alınan mesajları beklerken LGWR prosesince geçen süreyi izler.
LNS wait on LGWR	LGWR	Bu bekleme olayı LGWR prosesinden alınan mesajları beklerken LNS prosesince geçen süreyi izler.
LGWR-LNS wait on channel	LGWR	Bu bekleme olayı  LGWR tarafından geçen zamanı veya mesajları almak için bekleyen LNS prosesleri tarafından geçen süreyi izler.

Bunun yanında primary veritabanında izlenmesi gereken önemli I/O olayları ise altta yer almaktadır.

Maksimum Erişilebilirlik Mimarisinde OCI bağlantılarında SCAN kullanımı

Bu konuyu anlatmak için geniş yelpazade dağıtık bir maksimum erişilebilirlik mimarisi senaryosu üzerinden gitmek daha faydalı olacak diye düşünüyorum, şöyleki...

Yukardaki örnekte primary sitede 6 düğüm, standby sitedede 6 düğüm mevcut. Toplamda 6 servis oluşturulacak. 3 servis primary site üzerinde yazma amaçlı, 3 serviste raporlama amaçlı standby site üzerinden kullanılacak. Server pools teknolojisi kullanarak servislerin işyüküne uygun olarak donanımsal kaynak tahsisi yapacağız. Dataguard broker gözlemcisi primary siteyi izleyecek ve servislerden birinde düşme meydana gelirse otomatik olarak failover işlemini tetikleyecek.

Primary sitede;

3 sunucu havuzu olacak. Öncelik sırası ise SALES>CRM>MRP

MRP servisi için à En az 1, en fazla 2 server tahsisi gerekli

SALES servisi için à En az 2, en fazla 3 server tahsisi gerekli

CRM servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Standby sitede;

3 sunucu havuzu olacak. Öncelik sırası ise MRP>CRM>SALES

MRP_READ servisi için à En az 2, en fazla 2 server tahsisi gerekli

SALES_READ servisi için à En az 1, en fazla 3 server tahsisi gerekli

CRM_READ servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Bu senaryoyu gerçeğe dönüştürürken 3 aşamalı bir iş akışı üzerinden gideceğim.

1. İlgili servislerin ve TAF işlevinin eklenmesi
2. tnsnames.ora dosyalarında gerekli değişikliklerin yapılması
3. Server pools oluşturulması ve ilgili servislerin eklenmesi

Sonraki yazılarımda her üç aşamayı teker teker açacağız…

Oracle 11g R2 (11.2.0.2) RAC mimarisinde Data Guard kurulumu ve yönetimi

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri  yapıp hemde standby siteden SELECT  sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

-----------------------------------------------------------------------------------

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

----------------------------------------------------------------------------------------------

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

Standby veritabanında bazı data dosyalarına redo uygulamasının durması

Eğer primary veritabanı üzerinde FORCE LOGGING etkin değilse, kullanıcıların NOLOGGING takısını kullanarak yapacakları girişler standby sunucuda ilgili tablonun veya tablolaların tutulduğu veri dosyalarına taşınmayacaktır. Bu durumdada standby üzerinde bu veri dosyalarında blok bozulmaları meydana gelecektir. Fiziksel standby veritabanındaki veri dosyalarının bir kısmının log transferini yapamadığı durumlarda bu veri dosyalarını en son SCN ye güncelleme ve kesintisiz loglamaya devam etmesini sağlamak için aşağıdaki adımları uygulayabiliriz. Tabii bu olay ile karşılaşmamak için eğer primary veritabanında FORCE LOGGING etkin değilse etkinleştirilmelidir.

1. Öncelikle standby üzerindeki hangi veri dosyalarının redo uygulamasında eksik kaldığını tespit etmemiz gerekecektir. Bunu bulmak için aşağıdaki örnekte görüldüğü üzere V$DATAFILE görünümüne sorgu çekmemiz gerekmektedir.

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE

        2> WHERE FIRST_NONLOGGED_SCN > 0;

FILE#              FIRST_NONLOGGED_SCN

----------         ------------------------------------

   3                   145957

   4                   150164

Fiziksel standby sunucuya primary rolünü switch etme

Primary veritabanın rolünü standby sunucuya olağan durumlarda devretme olayına switchover denir. Genellikle primary veritabanında işletim sistemi güncellemesi veya donanım yükseltmesi gibi planlanan kesintiler olacağı zaman meydana gelir. Switchover esnasında herhangi bir veri kaybı yaşanmaz. Switchover sonrasında her veritabanı yeni rolünde görev yapmaya başlar. Standby veritabanına primary rolününe switchover yapma adımları aşağıda yer almaktadır.

Primary/Standby veritabanı ortamında failover işlemi

Dataguard ortamında failover primary veritabanının erişilemez olduğu durumlarda kullanılır. Belirli bir sure zarfında servisi geri yükleme imkanı olmaz. Failover durumu meydana geldiğinde eğer primary veritabanı “maksimum koruma” modunda çalışıyorsa, öncelikle standby veritabanı “maksimum performans” moduna geçirilmelidir.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE

PERFORMANCE;

Standby veritabanı maksimum performans moduna geçtikten sonra aşağıdaki adımlar ile failover işlemi gerçekleşir.

Primary veritabanında en uygun veri koruma yönteminin seçimi

Standby veritabanında redo boşluklarının olmaması için primary veritabanı üzerinde uygun veri koruma modunun seçimi gerekmektedir. Oracle Dataguard mimarisinde üç çeşit veri koruma modu vardır.

• Maksimum uygunluk

Bu koruma modu primary veritabanının erişilebilirliğinde taviz vermeden en yüksek seviyede veri koruma seviyesini belirtir. İşlemler, herhangi bir çökmede geri kurtarmayı sağlayacak verinin online redo log dosyalarına yazılmadan ve bu redo log dosyalarının en azından bir standby veritabanına senkronize olmadan COMMIT işlemine izin vermez. Bu mod sıfır veri kaybı sağlar, ancak birkaç saniyelik düşmeler redo veri setlerinin standby veritabanına taşınmasını engellemez ve bu birkaç saniyelik düşmelerin olduğu zaman zarfında veri kaybı yaşanma ihtimali yüksektir.

• Maksimum performans

Bu koruma modu primary veritabanının performansını etkilemden un yüksek seviyede veri koruma seviyesini belirtir. İşlemler, online redo log dosyasına yazılır yazılmaz COMMIT olur. Redo verisi daha sonra eşzamanlı olmadan standby veritabanına yazılır. Böylece bu mod aktifken, primary veritabanı eşzamanlı redo taşıması esnasındaki gecikmelerden kaynaklanan performans sıkıntısını yaşamaz. Bu mod varsayılan koruma modudur ve primary veritabanı performansı üzerinde etkisi sınırlıdır.

• Maksimum koruma

Bu koruma modu primary veritabanı çöktüğü zaman sıfır veri kaybını sağlar. İşlem commit olmadan önce aynı maksimum uygunluk modunda olduğu gibi hem primary redo log dosyalarına yazılmalı hemde en az bir standby veritabanına yazılması gerekmektedir. Veri kaybının yaşanmaması eğer redo dosyalarını en az bir standby veritabanına yazamazsa primary veritabanı kendini kapatır, böylece veri kaybı ihtimalini ortadan kaldırır. En az 2 standby veritabanı kullanıldığı Dataguard mimarilerinde bu modun seçimi tavsiye edilir.

Primary veritabanında veri koruma modunu değiştirmek için aşağıdaki adımları izleyebilirsiniz.

DUPLICATE komutu ile Oracle 11g Fiziksel Standby Veritabanı Yapılandırması

Bu yazıda, Oracle 11g ile birlikte gelen RMAN servisinden çalıştırılan DUPLICATE ... FROM ACTIVE DATABASE komutunu kullanarak, primary veritabanının herhangi bir yedeğini almadan ve ayrıca yedeğede ihtiyaç duymadan, primary veritabanı açıkken fiziksel bir standby veritabanı oluşturmasını adım-adım uygulayacağız. Senaryomda her iki sunucuda aynı Oracle dizin lokasyonlarını kullanmaktadır.

Senaryoda kullanılan sistem

Primary veritabanı DB_UNIQUE_NAME: orclprm

Standby veritabanı DB_UNIQUE_NAME: orclstdby

ORACLE_SID: orcl

Primary hostname: linux1 (OEL Linux 5.3)

Standby hostname: linux2 (OEL Linux 5.3)

Oracle software versiyonu: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 

1. Primary veritabanından fiziksel standby yapılandırmasına başlamadan once, veritabanına loglanmamış direkt yazma işlemlerini engellemek için primary veritabanında “Force Logging” özelliğini etkinleştiriyoruz.

SQL> alter database force logging;

Database altered.

2. Standby veritabanına primary veritabanındaki password dosyasını kopyalıyoruz.

$ scp $ORACLE_HOME/dbs/orapworcl.ora linux2:$ORACLE_HOME/dbs/

3. Network yapılandıma dosyalarında standby için gerekli güncellemeleri yapıyoruz.

Hem primary hemde standby veritabanı üzerindeki tnsnames.ora dosyasında aşağıdaki güncellemeleri yapıyoruz.

orclprm =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux1)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = orclprm)

    )

  )

orclstdby =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux2)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = orclstdby)

    )

  )

Bu dosyada gerekli değişiklikleri yaptıktan sonra standby sunucudaki aynı lokasyona kopyalıyoruz.

Bozuk veya kayıp arşiv log dosyası sonrası standby veritabanını geri kurtarma

Fiziksel standby veritabanı, primary veritabanından kendisine arşivlenmiş logların sürekli uygulanması ve bu senkronizasyonun sürekli devam etmesi esasına dayanmaktadır. Oracle 10g öncesinde arşivlenmiş loglardan birinin kaybolması veya bozulması durumunda standby veritabanının yeniden inşa edilmesi gerekmekteydi.

Ancak, Oracle 10g sürümünden itibaren kayıp veya bozulmuş arşiv loglarla karşılaşıldığında artalan yedekten standby veritabanını geri kurtarabilmekteyiz.

Aşağıdaki senaryoda uygulanacağı üzere standby veritabanına senkronize edilmesi gereken 234 ve 235 sıra numaralı arşivlenmiş loglar primary veritabanından kazara silinmiştir. Şimdi bu durumda standby veritabanını geri yükleme ve çalışmaya devam etmesini adım adım inceleyelim.

Primary veritabanı “row cache enqueue lock “ bekleme olayı hatası ve çözümü

Oracle 10.2.0.3.0 Data Guard with Broker konfigürasyonunda herhangi bir şekilde standby veritabanını READ ONLY modda yeniden başlatmayı denediğinizde aşağıdaki hata mesajını alırsınız.

ERROR: WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12170: TNS:Connect timeout occurred
PING[ARC6]: Error 3113 when pinging standby
ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)

“ORA01665 control file is not a standby control file” hata mesajı

Standby veritabanını geri yüklerken alter database recover managed standby database disconnect from session komutu sonucunda “ORA-01665: control file is not a standby control file” şeklinde hata mesajı alınabilir.

SQL> alter database recover managed standby database disconnect from session;
alter database recover managed standby database disconnect from session
*
ERROR at line 1:
ORA-01665: control file is not a standby control file