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.
- Media recovery hizmetlerinin parallel işlemlerinde kullanacağı proses sayısını kontrol etmesine imkan verin. Media recovery hizmetleri, paralel recover işlemleri için CPU_COUNT başlangıç parametresini kullanmaktadır.
- PARALLEL_EXECUTION_MESSAGE_SIZE değerini 65535 olarak atayın. Bu başlangıç parametresi tüm parallel sorgu operasyonları tarafından kullanılır ve shared pool’dan bellek çekmeye yarar. Bu sebeple bu ayarı düzenlerken paylaşımlı belleğin yeterli büyüklükte olmasından emin olun. Bu parametre değeri maksimum 64k değerini alabilir.
- DB_BLOCK_CHECKING başlangıç parameterisinin etkinleştirilmesi tüm media recovery işlemlerinde olumsuz etkiler meydana getirebilir. Bu parametrenin FALSE olarak tanımlanması media recovery esnasında redo uygulama oranında 2 kata kadar performans artışı sağlar. Buna karşılık bu oranın FALSE olarak değiştirilmesi sadece çok sık darboğazlar meydana gelen standby veritabanında yapılmalı, kesinlikle primary veritabanında FALSE olarak değiştirilmemesi veri bütünlüğünün kontrolü için zaruridir.
- I/O sistemini iyileştirin. Etkin media recovery oranlarına erişmek için en kritik faktör, I/O alt sisteminin iyileştirilmesidir. I/O sistemini media recovery için iyileştirme sürecinde alttaki işlemler önem kazanacaktır.
- Oracle sisteminin ASYNC I/O özelliğini kullanabildiğinden emin olun. Kurulumda Oracle zten ASYNC I/O kullanabilmek üzere ayarlanmıştır, ancak bunun için işletim sisteminde host bus adaptor(HBA) sürücüsünün ve depolama dizisininde düzgün şekilde konfigüre edilmiş olması gerekmektedir.
- I/O yazma boyutunu baştan sona tüm I/O yığın katmanlarında yükseltin. Bu katmanlar işletim sistemi async yazma boyutu, donanım sürücüleri, depolama network transfer boyutu ve disk yığınlarını içermektedir.
- DISK_ASYNC_IO başlangıç parametresinin değerinin TRUE olduğundan emin olun. Eğer eşzamanlılık(ASYNC) özelliğini kullanmak mümkün değilse, eş zamanlı olmayan I/O taklidi yapmak için DBWR_IO_SLAVES başlangıç parametresini kullanabilirsiniz.Buna ilaveten ASYNC I/O nun olmadığı durumlarda aynı işlevi sağlamak amacıyla, Oracle 10g için Veritas Storage Foundation sürümü ile birlikte gelen Oracle Disk Manager(ODM) kullanılabilir. ODM’i kullanabilmek için alttaki iki başlangıç parametresinde şu şekil değişiklik yapılması gereklidir.
filesystemio_options='setall'
media_recovery_read_batch=[512 veya 1024]
- Free buffer waits ve/veya checkpoint completed bekleme olaylarının Oracle bekleme olayları listesinde tavan yaptığı durumlarda ve ASYNC I/O nunda etkin olduğu zaman DB_WRITER_PROCESSES başlangıç parametresi değerinin 1’den fazla olmasını sağlayın. Ancak çoklu DBWR prosesi yeterli sayıda CPU ve I/O bant genişliğinde uygulanabilmektedir.
- Tüm bu değişiklikler sonucunda free buffer waits bekleme olayı hala en fazla bekleme olaylarından ise tampon belleği(buffer cache) artırın.
- Checkpoint süresi sayısını azaltmak için primary ve standby veritabanlarındaki online ve standby redo dosyalarının boyutunu arttırın.
- En iyi performans değerlerine erişmek için online ve standby redo dosyalarını ASM disk gruplarına yerleştirin.
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.
Media recovery performansını değerlendirme süreci
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 * FROM 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
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#;
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
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.
Redo oluşturma oranına karşılık Redo uygulama oranı | Değerlendirme ve tavsiyeler |
2 * Maksimum primary veritabanı redo oluşturma oranı < redo uygulama oranı | Çok iyi – Herhangi bir iyileştirmeye gerek yoktur. |
Maksimum primary veritabanı redo oluşturma oranı < redo uygulama oranı | İyi – İyileştirme sizing isteğinize bağlıdır,ama gerekli değildir. |
Ortalama primary veritabanı redo oluşturma oranı < redo uygulama oranı | Normal – İş yükündeki yoğunluğu ayarlamak amacıyla iyileştirme işlemlerine başlanabilir. |
Ortalama primary veritabanı redo oluşturma oranı > redo uygulama oranı | Kötü – İyileştirme gereklidir. Alttaki iyileştirme tavsiyeleri yardımcı olacaktır. |
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.
- Primary veritabanında daha yüksek okuma oranı olsada primary ile standby veritabanları arasında CPU kullanım farklılığı daha fazladır.
- Yüksek sayıda sortlar ve kompleks sorgular primary veritabanı üzerinde daha fazla CPU kullanır. Sorgular ve sortear ilave redo oluşturmadığından dolayı standby üzerinde ilave yük oluşturmaz.
İyileştirme için gerekli verilerin toplanması
İyileştirme için gerekli verilerin toplanabilmesi hem primary hemde standby veritabanında timed_statistics başlangıç parametresinin TRUE olarak ayarlandığından emin olun.
- 60 saniye aralıkla hem primary hemde standby veritabanlarının Linux/UNIX sistemininde sar komutu sonuçları.
- Standby için media recovery periyodununu bulmak için Linux/UNIX’te vmstat komutunun sonucu.
- Primary üzerindeki AWR raporu.
- 60 saniye aralıkla standby üzerinde altta çalıştırılan komutun sonucu.
select name, value, to_char(sysdate, 'DD-MON-YYYY HH:MI:SS')
from v$sysstat
where value > 0
order by name;
- 60 saniye aralıkla standby üzerinde altta çalıştırılan komutun sonucu.
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;
- Standby üzerinde media recovery operasyonunun tamamlanması esnasında bir kez çalıştırılan alttaki komutun sonucu
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;
Kayıtlar
0 yorum:
Yorum Gönder