28 Eylül 2010 Salı

Starting control autobackup

Merhabalar,

OTN forumlarını okumanın faydalarını görmek gerçekten beni çok mutlu ediyor. Aşağıdaki forum sayesinde Oracle adına bilmediğim bir özellik öğrendim. Aslında işleyişini biliyordum ama 11gR2'de nasıl davrandığını bilmiyordum;

controlfile autobackup in 11.2.0.1

10g ve öncesinde, bir tablespace'e datafile eklemek gibi veritabanının yapısını değiştiren durumlarda kontrol dosyasının otomatik olarak yedeği alınır ve ilgili dizine kaydedilirdi. Bunu da alert.log dosyasında "Starting control autobackup" olarak görürdünüz. Örneğin arka arkaya 10 tane datafile eklediğiniz tablespace'ler oldu ve bunun sonunda 10 tane kontrol dosyası yaratılıyordu. Şimdiki dokümantasyonlarda ise aşağıdaki yorum bulunuyor;

"
Starting with Oracle 11g Release 2, RMAN creates a single autobackup file encompassing all of the structural changes that have occurred within a few minutes of each other rather than creating a new backup of the controlfile on each structural change to the database.
"

11g Release2 ile birlikte, veritabanında, çok kısa dakikalar arasında gerçekleşen yapısal değişikliklerin herbiri için kontrol dosyası yaratılması yerine RMAN tek bir kontrol dosyası otomatik yedeği yaratacaktır.

Aslında buradaki ucu açık ve gri olan alan "few minutes" yani birkaç dakikanın aslında ne demek olduğu?

Çok uzun bir koruma süreniz (retention period) varsa RMAN için ve veritabanınızda sık sık yapısal değişiklikler meydana geliyorsa bu durumda kontrol dosyalarının otomatik yedeklerinin tutulduğu alanda yüzlerce yedek görmeye hazır olun! :)

İyi akşamlar.

Ogan

22 Eylül 2010 Çarşamba

enq: CF - contention / log_archive_max_processes

Selamlar,

Bu aralar bekleme olayları (wait event) üzerinde duruyoruz madem, yine onlarla devam edelim.

Other statüsü içerisinde bulunan ve "enq: CF - contention" olarak adlandırılan bir bekleme olayı bulunmaktadır. Bu beklemelerin nedeni "Control File - contention" yani, kontrol dosyası üzerindeki çekişmelerdir. Kısaca kontrol dosyası bir türlü paylaşılamamaktadır! :)

Peki kontrol dosyasını kim, neden paylaşamaz? "Kontrol dosyasında da bekleme olayı olur mu?" diye sorduğunuzu duyar gibiyim, evet olabilir. Kontrol dosyasına paralel bir erişim sağlandığı zaman, kontrol dosyaları üzerinde beklemeler oluşabilmektedir. Kontrol dosyasının okunmasına ihtiyaç duyulduğu anlarda, örneğin; online redolog dosyalarının arşivlenmesi, online redolog geçişleri sırasında, yedekleme komutu gönderildiği zaman, gibi.

Oracle veritabanında "log_archive_max_processes" isimli bir parametre bulunmaktadır. Bu parametre çalıştırılacak paralel ARCn işlemlerinin adedini bildirmektedir. "Veritabanında çok fazla ARCn olsun, daha hızlı ve paralel yazarlar, herşey çok güzel olur" gibi bir yorumla geldiğiniz zaman ve bu log_archive_max_processes parametresini 30-50 gibi garip sayılara eşitlerseniz alabileceğiniz bekleme olayının adı "enq: CF - contention". Zaten 10'a kadar tanımlanabilen bir parametre olduğunu da söylemem gerekiyor. Bu parametre ile çok fazla oynamamanız ve varsayılan ile gitmeniz, Oracle tarafından tavsiye edilmektedir.

log_archive_max_processes parametresinin amacı arşivleyici görevin adedine belirlemektir. Bu parametrenin varsayılan değeri 2'dir. 1'den 30'a kadar değer alabilir ancak ARC0 - ARC9 arasında tanımlıdır. 10'den büyük bir değer girerseniz harflerle kodlamaya başlar ve ARC görev miktarı da artar. Bu parametrenin ARCn görevlerini üretmesi için LOG_ARCHIVE_START komutunu "TRUE" yapmanıza, Oracle'ın 10gR1 sürümünden sonra gerek olmadığını da eklemem gerekiyor. Versiyonunuz 10gR1'den önce ise LOG_ARCHIVE_START komutunu kullanabilirsiniz ancak 10gR1 ve sonrası ise bu parametere "deprecated" olmuştur, yani artık desteklenmemektedir ve kullanılmaması gerekmektedir. 10gR1 ve sonrası için bu parametreyi tanımlamak isterseniz veritabanının başlangıcında bilgilendirme mesajı alacaksınız (deprecated parametre tanımlandı).

enq: CF - contention bekleme olayının artmasındaki sebeplerden biri olan log_archive_max_processes parametresini dikkatli tanımlamak gerekmektedir. Aksi halde bir datafile küçültmek(shrink) etmek ya da veritabanına yeni bir redolog grubu eklemek istediğiniz zaman ciddi beklemeler yaşayabilirsiniz. Bir de redolog'larınız boyutu yüksek ise ve ARCn görevlerinin işini zorlaştırmış iseniz işiniz zor :)

İyi çalışmalar.

Ogan

18 Eylül 2010 Cumartesi

Sihirli Kelime "Partitioning"

Selamlar,

Partitioning başlığı ile ilgili çok kısa bir yazı yazmak istiyorum. Amacı, bilgilendirme diyebilirim.

Partitioning üzerine son sürümlerde ciddi anlamda geliştirme sağlanmış ve 11g sürümü ile inanılmaz bir konuma gelmiştir. 11g ile birlike partitioning'in geldiği noktayı birkaç yazı önce belirtmiştim.

OTN forumlarını takip ederken bir başlık ile karşılaştım. Kullanıcı, tablolarının fragmente olduğunu ve sürekli insert ve delete işlemleri yaptığını söylüyordu. Bu durumda tablonun performansı negatif yönde etkileniyor ve belirli bir zaman sonra, tablo üzerinde koştuğu sorguların inanılmaz yavaşladığını görüyordu. Bu sebepten dolayı düzenli olarak tek bir tablo için seferber oluyor, tablonun HWM değerini düşürmek ve tahsis ettiği gereğinden fazla alanları bıraktırmak için uğraşıyordu. Bu şekilde koştuğu sorgular eski hızına kavuşuyor ancak yine belirli bir zaman sonra yavaşlamaya başlıyordu. Sonuç olarak otomatiğe bağlanamayan görevler ve başından kalkamadığı bir performans problemi ile mücadele etmek zorunda kalıyordu.

Oracle'ın sunduğu Partitioning özelliği ile yüksek performans elde ediliyor ve tablonun fragmente olması engelleniyor. Ancak bu özelliği kullanmanın bir lisans maliyeti var ve Enterprise Edition kullanmak zorundasınız. Geliştirilen veya geliştirdiğiniz uygulamanın Oracle ile çalışmasını istiyorsanız ve uygulamanızda insert / delete / update işlemleri yoğun ise mutlaka Partitioning özelliğini ciddi anlamda düşünmelisiniz.

Dip Not: Oracle tahsis ettiği alanları kendiliğinden bırakmaz. Bunun sebebi ise yeniden kullanabilme yeteneğinin olması.

Aşağıdaki komut ile yeni extent tahsis edilebilir;

SQL> ALTER TABLE TABLO_ADI ALLOCATE EXTENT [SIZE 10K];

Tahsis edilen ancak kullanılmayan alanın bıraktırılması içinse;

SQL> ALTER TABLE TABLO_ADI DEALLOCATE UNUSED;

İyi geceler.

Ogan

16 Eylül 2010 Perşembe

Private strand flush not complete / Checkpoint not complete

Selamlar,

Başlığı okuyan ve konuyu biraz bilen ya da bilmese bile veritabanlarının alert.log dosyasında gören insanların tüylerinin diken diken olduğunu görür gibiyim.

"private strand flush not complete" ve "checkpoint not complete" alert.log dosyasında yazan ve her online redolog değişiminde, belirli parametrelere bağlı olarak yazılma ihtimali olan bilgi mesajlarıdır. İki mesajında amacı aynı sayılırken yazılma nedenleri biraz farklıdır. Her iki mesaj da redo log değişiminden kaynaklanmaktadır. Bu iki mesajın en büyük özelliği ise gerçekten çok fazla aratılan ve merak edilen parametreler olmalarıdır. Internet üzerinde ciddi boyutlarda makale bulunmaktadır.

Google'da arama yaptığınız zaman, bu mesajların çok önemli olmadığını hatta kimi yerde ki gayet ciddi olduğunu düşündüğüm makalelerde ise ciddiye dahi alınmaması gerektiği yazmaktadır. Bu yorumlar ve bilgilendirmeler kesinlikle gerçeği yansıtmamaktadır. Bu mesajları gördüğünüz zaman alert.log dosyanızdan silmek için çalışmanız gerektiğini düşünüyorum zira çok yüksek transaction'ı ve bu transaction'ların yükü fazla olan veritabanlarında çok ciddi bekleme olaylarına neden olmaktadırlar.

Bu mesajları gördüğünüz zaman temel olarak şunu düşünebilirsiniz; LGWR yeni bir redo log geçişinden sonra sırada online redolog grubuna veri yazmak ister ancak sıradaki redo log henüz üzerine yazılması için hazır değildir. Yani bir checkpoint başlamıştır ancak redo log içerisinde bilgilerin fiziksel veri dosyalarına yazımı tamamlanamamıştır. Kimi uzman bu durumu gidermek için büyük boyutlu online redo log dosyaları kullanılmasını önermektedir ancak bana göre ne büyük ne de küçük, önemli olan bunun dengesini oturtmak. Çok küçük boyutlarda olduğu zaman fazla log geçişi olacağından bu hataları görme olasılığınız artabilecek iken çok büyük boyutlarda olduğu zaman bu hataları görmeyecek olsanız bile bu durumda da büyük log file yavaş yazma istatistiği ve eğer bir data guard kurulumunuz varsa da geç archivelog yaratılması ve senkronizasyon problemlerine kadar gider.

"private strand flush not complete" ve "checkpoint not complete" mesajlarını veritabanınızda görmek istiyorsanız eğer çok basit bir deneme yapabilirsiniz. 2 adet redolog grubu yaratın ve boyutlarını da 2GB kadar büyük tanımlayın. Arka arkaya "ALTER SYSTEM SWITCH LOGFILE" komutunu gönderin ve herhangi bir CKPT tetikleyici unsura başvurmayın. Eğer log_checkpoint_interval ve log_checkpoint_timeout parametleri tanımlıysa da bunları 0'a ayarlayın. Ardından alert.log dosyanıza bakın ve ilgili mesajlara rastlayacaksınız. Bunun dışında v$log görüntüsünden de redo log'un statüsünün "ACTIVE" olduğunu da gözlemlerseniz eğer LGWR henüz aktif olan ve DBWR arkaplan görevinin kullanmakta olduğu redo log'u yeniden kullanmak isteyecek ancak kullanabilmesi için biraz beklemesi gerekecek. İşte bu beklemelerin neden olduğu yavaşlığı gerçekten acil olarak çözmeniz gerekebilir çünkü bütün veritabanının genel performansını negatif yönde etkileyecektir.

Peki ne gibi çözümler önerilmektedir?

Önerilen en büyük çözüm redo log dosyalarınızı daha hızlı ve fiziksel veri dosyalarından ayrı olacak şekilde konumlandırmanız. Bu şekilde akış ayrı yerlerden paralel olarak devam edecek, redo log dosyalarına yazım gücünüz artacaktır. Bununla birlikte daha hızlı disk konfigürasyonları kullanmanız da yararlı olacaktır. Örneğin RAID5 yerine RAID1 diskler kullanmak gibi. Eğer AWR raporlarında ya da enterprise manager'da "log file sync" bekleme olaylarına da rastlamakta iseniz bu değişiklikler birlikte log_buffer'ı da arttırmayı düşünebilirsiniz. Redo log'lardaki sorunlarınızı giderebilmenin bir diğer yolu ise ağır kalan CKPT görevinin tetiklenmesini sağlamak. Yalnız bunu tek başına yapmak ne yazık ki problemi ve bekleme olaylarını çözmeyebilir. Bir redo log geçişinden sonra tetiklenen checkpoint'i, parametrelerle de sağlamanız mümkün değil, bunu şu anlamda söylüyorum; alert.log dosyasında "Completed checkpoint" ve "Incremental checkpoint" bilgilerini görürseniz EĞER log_checkpoint_to_alert parametreniz "true" ise. Complete bilgisi redo log geçişlerinden sonra gelir ancak incremental checkpoint, yani geçiş ya da ara checkpoint işleri log_checkpoint_timeout ve log_checkpoint_interval parametreleri ile kontrol edilebilir. log_checkpoint_interval'ın aldığı değer OS blok değeridir ve redo log'larla ilgili biraz karmaşık bir parametredir. Bu parametre tanımlandığı zaman mttr tavsiyesi devre dışı kalabilir. Bununla birlikte log_checkpoint_timeout parametresi ise saniye cinsindendir ve örneğin 40 değerini verirsek her 40 saniyede bir incremental checkpoint tetiklenecektir. Yanılmıyorsam 8i versiyonu ile bu parametrenin varsayılan değeri 1800 saniye olarak atanmıştır. Internet üzerinde okuduğum yorumların arasında "neden sık sık checkpoint yapmak isteyim?" gibi yorumlar geliyor. Checkpoint zaten biz istesekte istemesekte olması zorunlu bir ilerleyiştir. Redo log'lara transaction'ların commit ederek yazdığı verilerin bir yerde saklanması gerekmektedir. Burada bizim söylediğimiz sadece bunun hızlandırılabiliyor ya da insan tarafından kontrol edilebiliyor olmasıdır.

Bu noktada akla gelebilecek bir soru bütün bu parametrelerin varsayılan ve genelde bütün veritabanları için sabit sayılabilecek değerlerinin olup olmadığıdır. Hayır, böyle birşey söz konusudu kesinlike değildir. Her veritabanının yapısı ve transaction mantığı, adedi ve boyutu farklıdır. Yalnız herşey de olduğu gibi burada da heryeşin fazlası zarardır görüşü geçerlidir. Bir veritabanında nasıl çok hızlı ve fazla redo log grup geçişi zararlı olabiliyorsa 4 saatte bir yapılan redo log geçişleri de o kadar kötüdür. Bunun en muhtemel nedeni ise olası redo log kaybından 3 saat 54 dakikanın elinizden kaybolabileceği gerçeğidir, tabii standby redo log'lu bir data guard kurulumunuz yoksa :)

Alert.log dosyanızı eğer *nix kullanmakta iseniz "tail -f" komutu ile izleyin ve bu mesajları gördüğünüz zaman ki sequence numarasına bakın. Örneğin mesajın geldiği zamanki numara 68500 ama geçmesi gereken yeni sequence numarası 68501. 68501'e geçemediğini, daha doğrusu geçemediğini göreceksiniz. Ardından belirli bir zaman sonra 68501'e geçtiğini göreceksiniz. Bunu da ek bir bilgi olarak saklayabilirsiniz.

İyi geceler.

Ogan

LGWR, CKPT, DBWR ve LOG_BUFFER

Merhaba,

Bir oracle veritabanı arka plan görevi olan LGWR'ın (log writer) amacı log buffer'daki bulunan ve online redo log'lara yazılmayı bekleyen bilgileri online redo log'lara aktarmaktır.

LGWR görevi bu işlemi 4 farklı aşama tetiklendiği zaman gerçekleştirmektedir;

1) Her 3 saniyede bir redo log buffer'ı,
2) Redo log buffer'ın 1/3'ü dolduğu zaman,
3) Redo log buffer 1 megabyte olduğu zaman,
4) Herhangi biri "commit" ederse,

Redo log buffer boşaltılır ve online redo log'lara veriler aktarılır. Online redo log gruplarının boyutlandırması ne kadar önemli ise redo log buffer'ın da boyutlandırılması o kadar önemlidir. Hatalı boyutlandırıldıkları durumlarda veritabanın bekleme olayları meydana gelmektedir.

Aslında DBWR ve LGWR birbiri ile senkronize çalışmaktadır diyebiliriz zira bir transaction içerisinde iken devreye ilk giren görev LGWR'dır. LGWR'ın online redo log'lara yazdığı transaction kayıtları CKPT görevinin tetiklenmesi ve DBWR aracılığı ile fiziksel veri dosyalarına yazılmaktadır. Dolayısıyla bu döngü içerisinde bir aksama meydana geliyorsa, diğerleri de mutlaka etkilenecek demektir.

LGWR'ı CKPT ve DBWR'dan ayıran bir özellik ise yukarı saydığım 4 maddenin değiştirilemez ve değiştirilmesi de teklif edilemez olmasıdır :) Bu işleyişe log writer'ın kendine özel hareketleri de diyebiliriz ancak CKPT ve DBWR için aynı şey geçerli değildir. CKPT ve DBWR görevlerinin tuning'i yapılabilir ve belirli durumlarda da yapılması gerekmektedir.

Örneğin CKPT görevini elle çalıştırabilirsiniz;

SQL> ALTER SYSTEM CHECKPOINT [GLOBAL];

Aynı şekilde bir veritabanı üzerinde ne kadar DBWR çalışabileceğini sisteme gösterebilirsiniz;

SQL> ALTER SYSTEM SET DB_WRITER_PROCESSES=CPU_COUNT/8 SCOPE=SPFILE;

Veritabanının üzerinde bulunduğu sistemin CPU adedi bölü 8 bize kaç adet DBWR görevi olabileceğini göstermektedir. Bu sayıdan fazla da DBWR görevi tanımlanabilir.

İyi çalışmalar.

Ogan
Takip et: @oganozdogan