cursor :pin S wait on X ve Library Cache Lock

cursor :pin S wait on X ve Library Cache Lock

Bazen sistem üzerinden alacağınız AWR raporlarında yada oluşan dar boğazlarda  cursor :pin S wait on X wait ve Library Cache Lock eventlerini görebilirsiniz.

Bu durum ciddi sıkıntıların habercisi olabilir. Yada artık çok geç olup sistem üzerinde concurrency ler yaşıyor olabilirsiniz. Lafı çok uzatmadan nedenleri üzerinde konuşalım.

Bu sorun Veri Tabanın konfigürasyonu AMM (Automic Memory Menagment) olduğu sistemlerde görebiliriz.  Burada Memory_Target kullanımının oluşturduğu sıkıntı, shared_pool grow shrink sırasında sistemde cursor:pin S wait on X waitlerine yol açar. Aksiyon olarak Memory_Target yerine manuel memory değerleri set edilebilir.

V$SGA_RESIZE_OPS Talosundan resize sürelerini bakarsınız

Bu örnekden görülüceği üzere 2 dk ara ile shared pool shrink olmuş. Bu sırada sistem üzerinde cursor:pin S wait on X waitlerine takılabilirsiniz.

P.S: MOS dökümanından yararlanabilirsiniz [High 'Cursor: Pin S Wait On X', 'Library Cache Lock' And "Latch: Shared Pool" Waits due to Shared Pool/Buffer Cache Resize Activity (Doc ID 742599.1) ]

Bunun yanında sistem üzerindeki Hard Parse değerlerine de bakmak gerekir. Hard parse değerlerinin artışı contention lara yol açar. Bu sebeple AWR üzerinden SQL Statistics de parse calls, version count değerlerine bakıp doğru analiz yapmak gerekiyor.  Bunun için dump analizide yapılabilir.

P.S: MOS dökümanından yararlanabilirsiniz  [Troubleshooting 'cursor: pin S wait on X' waits. (Doc ID 1349387.1)]

İyi Çalışmalar..

Usta

 

Shell Script to Delete Archive Log with crontab

Shell Script for RMAN Delete Archive Log

Öncelikle neden böyle bir ihtiyaç doğar ki ? Diye sorabilirsiniz elbette. Bunu manuel yapabileceğiniz gibi aynı zamanda RMAN scripti içine de ekleyip ihtiyaç olmayan Archive Loglar FRA (Flash Recovery Area) dan temizleyebilirsiniz.

Bazı zamanlar geliyor bu şekilde emniyet alınabiliyor. Örneğin RMAN backup fail edebilir  yada henüz backup alınmaya başlanmamış fakat Arşiv log üretiyorsunuzdur. Böyle durumlar için bir crontab sh yazılıp belli periyotlar içersin de çalışması sağlanarak eski arşiv loglarını silebilirsiniz.

Ben şu şekilde bir örnek vereceğim.

Önce sh dosyamızı yaratalım:

[oracle@prodb01 scripts]$ vi Delete_Archive_Log.sh

#!/bin/bash

_xvcTime=`date "+%Y%m%d%H%M%S"`

echo "================ START Session: $_xvcTime - Delete_Archive_Log, log follows:" >> /tmp/Delete_Archive_Log.log

echo "Current timestamp: `date "+%Y%m%d%H%M%S"`" >> /tmp/Delete_Archive_Log.log

echo >> /tmp/Delete_Archive_Log.log

rman target / << EOF >> /tmp/Delete_Archive_Log.log

list archivelog all;  /**Test amaçlı list komutu koydum,Direk silinebilir. **/

delete archivelog until time 'sysdate-10';

crosscheck archivelog all;

exit;

EOF

echo "================ END Session: $_xvcTime - Delete_Archive_Log, log follows:" >> /tmp/Delete_Archive_Log.log

[oracle@prodb01 scripts]$

Tercihiğim her adımı Log’a yazmak bu yüzden login olmadan, yapılanlara kadar “/tmp/Delete_Archive_Log.log” yazdırdım. Sonra yarattığım “Delete_Archive_Log.sh” crontab –e ile otomatik çalışacak şekilde schedule ediyorum.

İyi Çalışmalar..

Usta

enq: TM – contention

enqueue TM bir DML lock wait event dir. Pek çok lock çeşitlerinden birisi olan enq:TM – contention idex olmayan FK constraintler üzerinde sıklık ile görülür. Aynı zamanda uygulama mantığı olarak tablo, aynı anda DML işlemleri içinde lock bırakıldığı anlarda bu durum gözlenebilir.  Özet olarak şöyle sıralayabiliriz:

1. Indexi olmayan FK column üzerinde
2. Yoğun Truncate işlemlerinde
3. Tablo üzerinde Bitmap Index varsa (Küçük bir ihtimal olsada)
4.  /*+APPEND*/ Hinti kullanımlarında eğer Transaction commit işlemi oluşmadığında bir yığılma meydana gelir.