Media recoveryhizmetlerinin 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.

 

 

filesystemio_options='setall'

media_recovery_read_batch=[512 veya 1024]

5.  V$RECOVERY_PROGRESS görünümünden oturumdaki anlık media recovery performansını izleyin ve sonuçları değerlendirin.

6.  V$SYSTEM_EVENT görünümünden media recovery optimizasyonuna liderlik yapabilecek bekleme olaylarını izleyin ve sonuçları değerlendirin.

 

 

Redo uygulamasının primary’den alınan tüm redo verisini geri kurtardığından emin olmak için V$DATAGUARD_STATS görünüme sorgu çekilerek standby veritabanında ne kadar süre boyunca redo alımı olmadığı gözlemlenebilir.

 

SQL> SELECT * V$DATAGUARD_STATS

           WHERE NAME=’apply lag’;

 

NAME              VALUE             TIME_COMPUTED

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

apply lag           +00 0:00:05       22-DEC-2010 14:24:35

 

Yukardaki örnekte görüldüğü üzere son 5 saniyeden beri standby veritabanı redo alımı yapmamıştır. Eğer apply lag değeri olduğundan yüksek seviyede olursa bu durumda standby ile primary arasında veri bütünlüğü noktasında eksiklikler olabilir.Bu tür eksikliklerinin olup olmadığını belirlemek için alttaki sorguyu hem primary hemde standby veritabanlarında çalıştırıp sonucu görebiliriz.

 

select 'Instance'||thread#||': Last Applied='||max(sequence#)||' (resetlogs_change#='||resetlogs_change#||')'

from v$archived_log

where applied = (select decode(database_role, 'PRIMARY', 'NO', 'YES')

from v$database) and thread# in (select thread# from gv$instance) and resetlogs_change# = (select resetlogs_change# from v$database)

group by thread#, resetlogs_change#

order by thread#;

 

Eğer eksiklik yoksa ancak hala media recovery primary’de tıkanıyorsa, o zaman ilk adım iyileştirme işlemine başlamak olacaktır. Bunun için ilk adım olarak mevcut performansı değerlendirin ve bu değerleri baz olarak kullanın. Gözlemleme olarak V$RECOVERY_PROGRESS görünümündeki alttaki kolonlar kullanılabilir.

 

Average Apply Rate: Redo Applied / Elapsed Time, redonun ulaşması sırasındaki  bekleme süresi ve aktif olarak bu redonun uygulama esnasında geçen süreyi içerir

Active Apply Rate: Redo Applied / Active Time ise son 3 dakikanın ortalama hareketini verir.Bu oran redonun ulaşması sırasındaki bekleme süresini içermez

Apply Time per Log: Log dosyasına uygulanan aktif redo için harcanan ortalama süre.

Checkpoint Time per Log: Log başına checkpoint için harcanan ortalama süre.

Last Applied Redo: En son uygulanan redonun SCN ve zaman mührü(Timestamp) bilgisi yer alır. Redo akıntısı içinde saklanan zamanı gösterir, böylece standby veritabanının primary veritabanına bağlı olduğu zamanlarda karşılaştırma yapmak için kullanılabilir.

 

Average Apply Rate değerinin doğru sonuç vermesi için geri kurtarmayı durdurup bir kaç arşiv log dosyası biriktirdikten sonra tekrar başlatabilirsiniz. Böylece ortalama uygulama oranından boş(idle) zaman kalkmış olur.

 

Fiziksel standby mimarisinde standby veritabanının primary veritabanın oluşturduğu redo’dan çok daha hızlı şekilde  redo ulaşımı sağladığını saptamak önemlidir. Uygulama akışını belirlemenin en kolay yolu AWR raporlarını kullanarak primary veritabanının normal ve yoğun kullanım zamanlarında kaç byte/saniye redo verisi oluşturduğunu saptamaktır. Böylece ortalama uygulama oranı veya aktif uygulama oranı ile yapılacak redo hızı kıyaslaması neticesinde standby veritabanının akışı devam ettirip ettiremediği anlaşılır. 

 

Primary veritabanında V$SYSSTAT görünümünden “redo blocks written” istatistiğinden zaman aralığını(T) ayırarak P1 ve P2 olarak iki tane snapshot alalım. Şipşak primary redo oluşturma oranı şu şekil sağlanır.

 

(P2 – P1) / T

 

Standby veritabanında V$SYSSTAT görünümünden “redo blocks read for recovery” istatistiğinden yukardaki aynı zaman aralığı(T) değerinebağlı kalarak S1 ve S2 olarak iki tane snapshot alalım. Şipşak uygulama oranı şu şekil sağlanır.

 

(S2 – S1) / T

Media recovery hizmetlerinde iyileştirmenin gerekip gerekmediğini alttaki tablodan karşılaştırmalı olarak belirleyebilirsiniz.

 

 

 

 

 

 

Primary instance çok fazla CPU kullanan işlemlerle birlikte %95 ve daha fazla sorgu aktiviteleri oluşturabilirken, recovery instance(veya  standby veritabanı) çok fazla yazma ve güncelleme yoğunluğundadır. Recovery instance’in hedefi, değişiklikleri veri bloklarına uygulamak ve bunları veri dosyalarına yazmaktır. Pek çok durumda recovery instance az çok etraflı olarak CPU kaynaklarına ihtiyaç duysada eşit veya daha yüksek I/O veya bellek kapasitesine ihtiyaç duyar. Primary’de muhtemel yüzlerce sayıda yoğun CPU kullanan operasyonlar yerine sadece media recovery koordinatörü(PID bilgisi V$PROCESS görünümünde bulunur) veya MRP prosesi (MRP0 PID bilgisi V$MANAGED_STANDBY görünümünde bulunmaktadır) genellikle CPU yoğunlukludur. Pek çok durumda, sayı olarak az ancak daha hızlı CPU lar media recovery performansını yükseltir. Standby veritabanı kullanımını önceden kestirmek için basit bir formül yoktur. Media recovery iyileştirmesinde pekçok ortamda genel olarak gözlemlenenler altta yer almaktadır.

 

 

İyileştirme için gerekli verilerin toplanabilmesi hem primary hemde standby veritabanında timed_statistics başlangıç parametresinin TRUE olarak ayarlandığından emin olun.

 

 

select name, value, to_char(sysdate, 'DD-MON-YYYY HH:MI:SS')

from v$sysstat

where value > 0

order by name;

 

 

select event, total_waits, time_waited, average_wait*10

from v$system_event

where time_waited > 100 and event not like 'rdbms ipc %'

and event not like '%timer%' and lower(event) not like '%idle%'

and lower(event) not like 'sql%net%' and event not like 'ges%'

order by time_waited;

 

 

 

select to_char(start_time,'dd-mon-yyyy HH:MI:SS') start_time,

type, item, units, sofar, total,

 to_char(timestamp,'dd-mon-yyyy HH:MI:SS') timestamp

from v$recovery_progress;