DATAGUARD Onemli ozellikler.

Dataguard çalışma modları:

•Maximum Performance Mode
–Default mode
-hız önemlidir
•Maximum Protection Mode
–Data güvenliği önemlidir
–En az bir tane ikinciye ihtiyaç vardır
•Maximum Availability Mode
–Uptime hedef alınmıstır.
–Kesintinin olmaması ve devam edilme üzerine tasarlanmıstır.


Disaster recovery senaryolarında fiziksel stanby ve logical standby olabilir.
Data protection olaylarında fiziksel standby ve logical standby olabilir.
Performance konularında fiziksel standby redoların uygulaması ile olusur. sql seviyelerini atlayabilir.logical standbylarda ise redolar sql donusurler.
Ana databasein iş yukunu azaltmak konularında fiziksel standbylar cok etkili değildirler. Logical standbylarda ise raporlama basarılı bir sekilde yapılabilir.ting
Extra schema yapıları logical standbylarda fazlası ile mümkündür.
Logical standbylarda long ve lob data tipleri uygulamazken fizikselde böyle bir kısıtlama yoktur.


orcl.oracle.com=
(DESCRIPTION=
(SDU=32767)
(ADDRESS=(PROTOCOL=tcp)
(HOST=galatasaray)(PORT=1521))
(CONNECT_DATA=
(SID=orcl))

sqlnet.ora dosyasındaki session data unit parametresini unutmak gerekir:
–DEFAULT_SDU_SIZE=32767
sdu buffer sizenın büyüklüğü önemlidir. buffer size buyukse netwok gelen giden performansıda buyuk olacagından daha hızlı olabilir.

standy tarafinda
listener.ora:
SID_LIST_listener_name=
(SID_LIST=
(SID_DESC=
(SDU=32767)
(GLOBAL_DBNAME=orcl.oracle.com)
(SID_NAME=orcl)
(ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1)))
gigabit netwok tercih edilmelidir.

örnek olarak dusunursek
BDP= 1,000 Mbps * 20msec (.020 sec)
1,000,000,000 * .020 olarak dusunebiliriz.

NIC divice queu size artarmamız iyi olur 100 den 10000 cekebiliriz.

–ifconfig eth1 txqueuelen 10000

TCP_NODELAY=yes olmalıdır.

Arsiv loglarının gidisatını hızlandırmak için
Max_connection parametresini max değere cekelim defualt 2 dir 5 yapalım.
LOG_archive_max_process sayısını artıralım defaultu 2 dir 20 lere cıkabiliriz.
Yeni cıkan commit nowait seceneğini ciddi bir sekilde dusunelim bu özellik sayesinde Oracle commitlerin bitmesini beklemeden devam edebilir.

Tabi redologlarlar ilgili yıllardır bahsettiğimiz özelikkleride unutmamız gerekir.
Özelikle redoların hızlı disklerde olması,Raid5 gibi bir mimairde olmaması,raid10 veya raid1 olması gerekir.

Checkpoint surecinedikkat etmemiz gerekir
log switch sırasında LOG_CHECK_TIMEOUT expire oldugu zaman ve LOG_CHECKOUT_INTERVAL ulasıldıgında checkpoint atacaktır.
bizim yapmamız gereken sıksık log switch yapılmasını önlemektir ideal zaman 15-20 dakika aralıgıdır
Baska bir taraftanda redo log sizemizi 1gb ustunde vermemiz dogru olmaz gerekirse sayıyı artırıp size 1gb tutmalıyız.

Ne kadar sıklıkla checkpoint attıgımızı görmek istiyorsanız

SELECT NAME, VALUE, TO_CHAR(SYSDATE, ‘HH:MI:SS’) TIMEFROM V$SYSSTAT WHERE NAME = 'DBWR checkpoints' kullanabilirsiniz.

Paralel recovery icin cpu sayısını parametre olarak verebiliriz.
db_cache_size secondary birinciden yuksek olamalıdır.

wait eventleri icindeki archive ve LGWR,RFS kaynaklı olanlara dikkat etmek gerekir.

Butun bunları söyledikten sonrada 11g ile gele snapshot standy özeliklerinide unutmamanızı tavsiye ederim özelikle mayıs ayındaki yazılarımda o konulara değinmiştim artık

Fiziksel standy read write modda calısıtırbiliyoruz. BUDA inanılmaz önemli ve gerçek test denemeleri yapmamıza imkan verebiliyor.