SQL Performance Analyzer ile SQL komutlarının performans gelişimlerinin izlenmesi

Oracle Database 11g Sürüm 1 (11gR1)  sürümü ile kullanıma sunulan SQL Performance Analyzer aracı, zayıf performans gösteren SQL komutlarının mevcut durumu ve gerekli düzeltme işlemi sonunda  performanslarında meydana gelen değişimleri test ortamında kıyaslayarak, kaynak kullanımında ve çalıştırma planı maliyetinde meydana gelen olumlu/olumsuz gelişimleri okunabilir rapor formatında hazırlayarak, veritabanı yöneticilerine SQL cümlelerinin iyileştirilmesinin veritabanı üzerinde olumlu etkisini kolayca görmesini sağlanır. SQL Performance Analzyer aracında kıyaslama için önceki ve sonraki olarak adlandırılan iki tür şablon kullanılmaktadır. “Önceki” kelimesinden kasıt;  herhangi bir iyileştirme yapılmadan çalıştırılan zayıf SQL komutlarının mevcut durumudur.  “Sonraki” ise; gerekli  yapısal iyileştirme yapıldıktan sonra bu konfigürasyon değişikliğinin sistem üzerinde ne tür performans geliştirmesi yapacağının testine imkan veren bir analiz ve simülasyon metodudur.

Bu makelede, zayıf SQL komutlarının“önceki” ve “sonraki” arasındaki performans değişimlerini  kıyaslama simülasyonu yer alacak ve performans değişim sonuçlarının zengin formatta raporlanması bir örnek ile yapılandırılacaktır. Oracle Enterprise Manager(OEM) grafiksel arayüzünde yer alan adım-adım sihirbazlar yardımıyla oluşturulacak olan SQL Performans Analyzer görevinde “önceki “ve “sonrası” arasındaki değişikliklerinin kıyaslama simülasyonu kolayca yapılmaktadır. Bu işlem için izlenecek adımlar aşağıda sırasıyla  yer almaktadır.

• Oracle veritabanındaki örnek yükü kapsayacak olan zayıf performansa sahip SQL komutlarının yakalanması(SQL Tuning setler yardımıyla).
• Mevcut veritabanı sistemini kullanarak “önceki” olarak adlandırılan imajı/şablonu oluşturmak için örnek işyükünün mevcut performans etkisinin belirlenmesi.
• Oracle veritabanı sisteminde yapılan yapısal değişiklik sonucunda mevcut işyükünün “sonraki” durumuna karşılık değişim göstermiş performansının test edilmesi.
• Yapılan yapısal değişim sonucu hangi işyükü komponentlerinde pozitif veya negatif yönde değişim meydana geldiğinin bulunması için “önceki” ve “sonraki” arasında kıyaslamanın yapılması ,ayrıca hangi işyükü komponentleirnde  değişiklik olmadığının tespiti.
• Zayıf performans gösteren SQL komponentlerinin nasıl en iyi şekilde düzeltileceğinin belirlenmesi, böylece yeni ortamda bu SQL komutlarının en iyi şekilde çalışacağından emin olunması.

SQL Performance Analyzer aracının çalışmasını göstermek için,  bu yazıda kullanılacak olan örnek tabloların oluşturulması ve SQL komutlarının beliritildiği adımları, “önceki” ve “sonraki” değişim simülasyonları ile birlikte aşağıdaki gibi yapılandıracağım.

Uptime izleme aracı ile inaktif oturumların izlenmesi

Uptime izleme aracı ile Oracle veritabanında inaktif oturumlar hakkında uyarıları emaille almak oldukça kolaydır. Bu işlem için uptime izleme aracı içinden “Add service monitor” ile Oracle (basic checks) servisini seçmek yeterlidir. Ardından script altından inaktif oturumlar mevcutsa TRUE değerini döndürecek olan SQL komutunu tanımlanabilir. Servis kıyaslama alanında da değer olarak FALSE tanıtılırsa, ters bir durum oluşma durumunda uptime izleme aracı otomatik email ile bu durumu kritik alert seviyesinde ilgili profile bildirecektir.

 Alttaki örnekte 2 saatten fazla zamandır veritabanına bağlı inaktif oturum olduğunda anında emaille alert olarak döndürecek örnek yer almaktadır.

Uptime ile ilgili geniş bilgiye http://www.uptimesoftware.com/resources.php adresinden erişilebilir.

SQL komutları için delta değerlerinin izlenmesi

V$SQLAREA görünümü library cache içindeki imleçler ile ilişkili tüm alt imleçlerin istatistiklerini birlikte gruplandırır. Buna rağmen gruplandırma bazı işlemleri kolaylaştırırken, “library cache latch” için artan talep sebebiyle bu görünüme erişmek muhtemelen daha fazla kaynak tüketecektir. İstatistikler, sürekli alma(consistent gets) sayısı, diskten blok okumaları, çalıştırmalar, satır alıp getirmeler(fetches), sortlar, bellek kullanımı, yüklemeler, invalidationlar ve bazı diğer alt istatistikler için sağlanmaktadır. 

Oracle 9.2 sürümünden itibaren, bu görünüm tamamlanma süresi(elapsed time) ve CPU kullanımı bilgilerinide sağlamaktadır. Görünüm her 1 saniye ve 5 saniye arasında güncellenmektedir.

V$SQL görünümü tüm alt imleçleri gruplandırmadan benzer bilgiyi sağlamaktadır; böylece görünüme erişmek daha az kaynak tüketmekle beraber, ayrıca “adaptive cursor sharing(uyumlu imleç paylaşımı)”, bağlaç(bind) değişken tanımı/değeri uzunluk değişimleri, değişik optimizer parametreleri çalıştıran oturumlar, istatistik toplama gibi SQL komutu  için “değişken” çalıştırma planına sahip türlü alt imleçler için istatistikleride görmeye imkan vermektedir. Bu görünümde her 1 saniye ve 5 saniye arasında değişmektedir. 

Yüksek “DB Time” değeri hakkında bir inceleme

Yüksek CPU kullanımı ile kendini göstermeyen ve bekleme sebebiyle oluşan performans problemi ile karşılaşılırsa ne yapılır? Bekleme belki mandallar(latches), kilitler veya mesela yavaş disk gibi farklı kaynaklar yüzünden olabilmektedir. Oracle 10g sürümünden itibaren CPU zaman tüketimi ve beklemesini gözönünde bulunduran sözde zaman modeli istatistiklerini sunmaktadır. Bu istatistikler (V$SYS_TIME_MODEL) ve oturum seviyesi için (V$SESS_TIME_MODEL) sistem görünümlerinden elde edilebilir. İşin özünde, veritabanı instance içinde harcanan zaman değerlendirmeye alınmaktadır.

“DB Time”  veritabanı kullanıcı seviyesi çağrılarını yerine getirirken geçen zaman miktarının mikrosaniye bazında toplamıdır. PMON gibi instance arkaplan proseslerinde geçen süre bu hesaplamaya dahil edilmez.

“DB Time” metriğine dahil olan durumlar aşağıda yer almaktadır;

·         DB CPU

·         Bağlantı yönetimi çağrısı esnasında geçen süre

·         Sekuans yüklemesi esnasında geçen süre

·         SQL yürütmesi esnasında geçen süre

·         Ayrıştırma esnasında geçen süre

·         PL/SQL yürütmesi esnasında geçen süre

·         Gelen PL/SQL rpc çağrıları esnasında geçen süre

·         PL/SQL derlemesi esnasında geçen süre

·         Java yürütmesi esnasında geçen süre

TROUG DBA SIG toplantısındaki sunumum

Geçen hafta 31 Mayıs 2012 Perşembe günü Bilginç IT Academy'de düzenlenen TROUG DBA SIG toplantısında yapmış olduğum sunuma linke tıklayarak erişebilirsiniz. Tüm katılımcılara ve oturumu düzenleyen herkese çok teşekkür ederim.

SQL Profiller nelerdir ve neden ihtiyaç duyulur?

DBMS_XPLAN paketi ile SQL komutlarının çalıştırma planının analiz edilmesi istenildiğinde,  bazı durumlarda çalıştırma planı boyunca aşağıdaki satır görülebilmektedir.

Note

-----------

SQL profile "SYS_SQLPROF_012ad8267d9c0000" used FOR this statement

Bunun anlamı şudur; 

·         SQL komutunun değerlendirmesi esnasında harici bir yardımcı nesne kullanılmıştır.

·         Bu yardımcı nesne çalıştırma planını değiştirmiştir veya en azından etkilemiştir.

Bu noktada bir takım yardımlar almak faydalı olacaktır. Mesela, bu profil nesne nedir? Ne iş yapar? Ve en önemliside SQL komutlarını değerlendirirken neden “harici” bir yardıma ihtiyaç duyulmaktadır?

Oracle optimizer ile ilgili problem aslında, geleneksel olarak Oracle optimizer’ın çalıştırma planları oluşturmak için veri istatistiklerine güvenmesinden kaynaklanmaktadır.  İstatistikler aslında gerçek verinin oldukça basitleştirilmiş tanımı şeklinde yer almaktadır. Oldukça büyük GB boyutundaki bir tablonun kolon istatistikleri, sadece belirli şeyleri içermektedir, değerlerin toplamı, benzersiz(distinct) değerlerin miktarı, minimum ve maksimum değerler gibi... Diğer bir deyişle, istatistikler verinin genel şeklini yakalar, ancak pekçok alt seviye detay bilgisi kaybolmaktadır.   

Bu kayıp detay bilgisini telafi etmek ve hala mantıklı ve doğru tahminler sağlamak için, optimizer veri hakkında bazı varsayımları bulundurmaktadır. Bilhassa optimizer bu durumlarda şu şekilde düşünmektedir: 

·         Veri değerleri uniform olarak dağılmıştır(diğer bir deyişle 2 nolu değer sıklıkla 5 nolu değerdir)

·         Kayıtlar uniform olarak dağılmıştır(diğer bir deyişle fiziksel bir kümeleme veya veri sıralaması yoktur).

·         Değerlerin sıralaması aralıksızdır(diğer bir deyişle aralık arasında bir boşluk yoktur)

İlk TROUG DBA SIG toplantısı

Bu ay TROUG’un DBA SIG Toplantısı 31 Mayıs tarihinde Bilginç IT Akademide gerçekleşecek.  Bu Oracle Kullanıcıları Grubunun ilk DBA SIG Toplantısı olacak. Sunumda benimde “Ham izleme dosyalarını okuma metotları” başlığı altında bir konuşmam olacak. 

Sunum konuları olarak, Data Masking, Partitioning, performance tuning, trace (ham izleme) dosyalarını okumak gibi Oracle DBA’lerin genelini ilgilendirecek konular seçildi.

Etkinlik Programı:

13:00-14:00 Açılış Konuşması + Data Masking Nedir? – Zekeriya Besiroglu

İçerik: Data masking kullanarak veritabanının güvenliği arttırmak, test sistemlerinde gerçek veri kullanmadan gerçek veri performansını yakalamak, Data Masking uygulamaları.

14:00-14:15 Kahve Molası

14:15-15:00 Enterprise Manager ile Performance Tuning – Gökhan Atıl

İçerik: Enterprise Manager hakkında ön bilgi, Enterprise Manager Performance Tuning açısından DBA’lere ne gibi olanaklar sağlar, Enterprise Manager Top Acitivity Page nasıl yorumlanır

15:00-15:15 Kahve Molası

15:15-16:00 Oracle Partitioning Nedir ve Nasıl Yönetilir? – Kamil Türkyılmaz

İçerik: Partitioning’in tarihçesi ve gelişimi, Partitioning çeşitleri, Parititioning yöntemine nasıl karar verilir, partitioning kullanımının artıları ve eksileri.

16:00-16:15 Kahve Molası

16:15-17:00 Ham izleme dosyalarını okuma metotları – Uğur İnal

İçerik: Ham izleme dosyalarının okuması, izleme metotları, TKPROF ve trace analyzer araçları, bu araçların farklılıkları, verilerin okunması ve önemli değerler

Kapasite sınırı nedeniyle katılımcıların iletişim formunu kullanarak kayıt yaptırması gerekmektedir. 

Bilginç Ulaşım Bilgileri: http://www.bilginc.com/default.aspx?TABLE=icerikler&ID=7&RELID=0

EXACT_MATCHING_SIGNATURE ve FORCE_MATCHING_SIGNATURE hakkında

Oracle dökümanlarında EXACT_MATCHING_SIGNATURE normalize SQL textinde hesaplanan imzadır şeklinde tanımlanmıştır. Buradaki normalizasyon kavramı beyaz alanların çıkarılması ve gerçek olmayan tüm stringlerin büyük harfe dönüştürülmesidir. CURSOR_SHARING parametresi EXACT olarak ayarlandığında bu imza kullanılırken, FORCE_MATCHING_SIGNATURE kolon değeri ise CURSOR_SHARING parametresi FORCE olarak ayarlandığında Oracle’ın hesapladığı imzadır.  

Şimdi bu kolonların alacağı bazı değerleri ve bunların anlamlarını aşağıda inceleyelim.  

I. SENARYO:

EXACT_MATCHING_SIGNATURE  ve FORCE_MATCHING_SIGNATURE değerleri sıfır olarak ayarlanmıştır. Bu senaryo eğer komut tipi PL/SQL paketi, INSERT,ALTER INDEX,LOCK, SET ROLE ve mevcut SYS tablolarından($,# olanlar, ancak görünümler hariç) SELECT/UPDATE işlemleri  veya dahili Oracle komutları içindir.  Bunun yanında daha fazla komut olabilir, ancak Oracle SQL in yeniden kullanılamayacağını düşünecek ve ardından değerleri 0 olarak işaretleyecektir.

Oracle 11.2 sürümünde DBMS_PARALLEL_EXECUTE paketi

Oracle 11.2 sürümü ile yeni gelen DBMS_PARALLEL_EXECUTE prosedürü, büyük veri setlerini artalan şekilde güncellemeye izin veren bir pakettir. Temel olarak, ROWID veya nümerik kolon veya kullanıcı tabanlı SQL komutuna dayalı satırlara ayırarak daha küçük veri yığınları oluşturulur, ardından bu yığınlar paralel şekilde güncellenir.  Bu paketin avantajları ise; bu yığınlar bireysel olarak commit edilmektedir ve ROWID’e dayalı yığınlar olduğunda daha iyi performansa ulaşılmaktadır.   

DBMS_PARALLEL_EXECUTE neden önemlidir?

1.    Büyük bir tekil işlem birçok işlem yığınına bölünebilmektedir.

2.    Golden Date veya Streams gibi bağlı sistemlerde daha az etki yapmaktadır.

3.    Yığınlar ROWID ve bloklara bağlı olduğunda paralel DML işlemleri ile kıyaslandığında daha iyi performans göstermektedir.

4.    Daha az undo alanına ihtiyaç duyar ve bu sebeple ORA-01555 hatası ile karşılaşma ihtimali daha düşük olmaktadır.

5.    Hata ile karşılaşıldığında rollback işlemine etkisi şiddetli olmamaktadır.

6.    Kilit süresi daha düşüktür.

7.    Hatalı yığın işlemlerini yeniden başlatabilmektedir.

8.    Diğer paralel özelliklerin aksine, DBMS_PARALLEL_EXECUTE  paketi  Enterprise Edition lisansına şimdilik ihtiyaç duymamaktadır.

9.    Manuel kodlama gereksinimini azaltmakta ve paralel işlemler üzerinden daha iyi tekdüze dağıtım yapabilmektedir.

Trace Analyzer aracı ile izleme dosyalarının analizi

Ham formattaki izleme dosyalarını okunabilir formata dönüştürmek için kullanılan en yaygın araç olan TKPROF ne yazıkki bind değişkenlerini rapora ekleyememektedir. Ayrıca  TKPROF içinde aynı anda birden fazla işlem tarafından kullanılan bloklar listelenmemektedir. Bu gibi kısıtlamalar sebebiyle, TKPROF aracına  alternatif olarak Oracle’ın ücretsiz bir aracı olan “Trace Analyzer” aracı Oracle Metalink’ten indirilip kullanılabilir. Böylece, aynı anda birden fazla işlem tarafından kullanılan ve kilite sebebiyet veren segmentler ve ilgili sıcak bloklarda raporlandığı gibi, ilgili SQL komutlarının hash değerleri ve kullanılan farklı bind değerlerinin yaptığı bekleme istatsitikleri ve yürütme planı bilgilerinide görme imkanına sahibiz.

“Trace Analyzer” aracı ile tek bir ham izleme dosyası analiz edilebildiği gibi, istenirse birden fazla ham izleme dosyasıda tek bir rapor gövdesinde alınabilmektedir. Analiz işlemi sonunda elde edilen zip dosyada TKPROF raporu yer aldığı gibi, çok kapsamlı bir HTML formatta raporda yer almaktadır.

Trace Analyzer aracı ile izleme analizinin raporlanması işleminden önce aşağıdaki adımların sırasıyla uygulanması gerekmektedir.

Standalone Oracle 10g veritabanının 10g RAC veritabanına dönüştürülmesi

Standalone Oracle 10g veritabanın Oracle 10g RAC veritabanına dönüştürülmesi işlemi öncesinde tüm düğümlerde clusterware yazılımının kurulmuş olması ve sunucuların RAC yapısında hizmet verecek şekilde fiziksel olarak yapılandırılmış olması gerekmektedir. Bu kurulum öncesi işlemlerin tamamlandığından emin olunduktan sonra daha önceden stand alone olarak hizmet veren bir Oracle 10g veritabanının RAC veritabanına dönüştürme işlemi için aşağıdaki adımların uygulanması yeterli olacaktır.

Veritabanındaki en son bekleme olaylarının analizi

Oracle 11g veritabanında en son bekleme olaylarını gerek kullanıcılar, gerek SQL komutları ve gerekse objeler bazında gözlemlemek ve analiz etmek için V$ACTIVE_SESSION_HISTORY görünümü kullanılabilir. Bu sistem görünümü ile veritabanında oturumların en son bekleme olayları ile ilgili istatistik bilgilerine erişilebilmektedir.  Bu görünümün V$SESSION ve DBA_USERS gibi sistem görünümü ve tabloları ile birleşimi sonucu elde edilen ve faydalı olacağına inandığım bazı analiz sorguları aşağıda yer almaktadır;

Oracle 11.2.0.2 Clusterware ortamında kayıp OCR ve voting disklerin yedekten geri yüklenmesi

Bu yazıda Oracle 11.2.0.2 Clusterware platformunda OCR ve voting diskin kaybedildiği durumda sisteme nasıl geri yükleneceği anlatılmaktadır. Ocssd.bin başlatıldığında, GPnP profili, network ve voting disklerde var olmalıdır. Eğer minimum sayıda gereksinim duyulan voting dosyaları varolmazsa , bu durumda ocssd.bin başlatılamaz.  

OCR varolmadan crsd prosesi başlatılamaz ve ocssd.bin de aktif olmaz.  OCR, CRS tarafından kullanılır, bu da OCR kayıp olduğunda crsd.bin in aktif olamayacağı anlamına gelmektedir. CRSD aktif olmazsa, bu sorunlu düğüm kümeye dahilde olamaz.

Oracle Clusterware her 4 saatte bir OCR'nin yedeğini almaktadır. OCR içinde voting diskin yedeği bulunmaktadır. Bu sebeple voting diski geri yüklemek için var olan bir OCR yedeği yeterlidir. Şimdi bu geri yükleme olayını, OCR'nin yer aldığı ASM disk grubundaki(senaryomda +DATA) disklerde fiziksel bir çökme nedeniyle erişilemez olduğu senaryo çerçevesinde adım adım işleyelim. İlk etapta küme katmanını çalıştırarak sorunun olduğunu gözlemleyelim.

[root@rac1 ~]# crsctl start cluster

CRS-2672: Attempting to start ‘ora.cssdmonitor’ on ‘rac1′

CRS-2676: Start of ‘ora.cssdmonitor’ on ‘rac1′ succeeded

CRS-2672: Attempting to start ‘ora.cssd’ on ‘rac1′

CRS-2672: Attempting to start ‘ora.diskmon’ on ‘rac1′

CRS-2676: Start of ‘ora.diskmon’ on ‘rac1′ succeeded

CRS-2674: Start of ‘ora.cssd’ on ‘rac1′ failed

Bu adımda neyin yanlış olduğunu teyit etmek için log dosyalarına bakılması gerekmektedir.  Clusterware'nin alert.log dosyasında aşağıdaki gibi bir hata mesajına rastlanılacaktır.

Bilgi İşlem Merkezi Yöneticileri (BIMY) Semineri 2012

Bilişim Sektörünün değerli çalışanları, sektörümüze katkı sağlayan bilişim dostları,

Bilindiği üzere Türkiye Bilişim Derneği, Bilişim Sektörünün gelişmesi amacıyla tam 40 yıldır çalışmalarına aralıksız devam etmektedir. Bu kapsamda her yıl düzenlenen ve gelenekselleşen TBD etkinlikleri sizlerin de katkısıyla markalaşmış, sektörel bir sahiplikle sektör zirvesi ve şenliği haline gelmiştir.

Bilgi Teknolojilerinde yaşanan değişimler toplumların yaşam biçimlerini, kurumların ve sektörlerin birbirleriyle iletişimlerini etkilemektedir. Sektörlerin birbirleriyle etkileşimi yerel düzeyde rekabet koşullarını artırmakta, istihdam açısından önemli katkılar sağlanmaktadır. Bu doğrultuda Bilişim Sektöründe çalışan üst ve orta düzey yöneticilerin mesleki gelişimi ve dayanışmalarını geliştirmek amacıyla ana teması “Bilişim Teknolojileri ve Gelecek Öngörüleri” olan “Bilgi İşlem Merkezi Yöneticileri Semineri (BİMY)” düzenlenecektir. Bu yıl 19.sunun yapılması planlanan BİMY etkinliği 29 Mart - 01 Nisan 2012 tarihleri arasında Gloria Golf Resort Hotel' de gerçekleştirilecektir.

Detaylı bilgi ve kayıt için : http://bimy.tbd.org.tr/

Oracle 11.2.0.2 sürümünde Flashback Transaction Query

Flashback Transaction Query, işlem seviyesinde veritabanında yapılan değişiklikleri göstermeyi sağlayan kullanışlı bir Oracle aracıdır. Flashback Transaction Query, bir işlem tarafından yapılan tüm değişikliklerin görülmesini sağlayan bir SQL eklentisidir. Örneğin;

SELECT UNDO_SQL

FROM FLASHBACK_TRANSACTION_QUERY

WHERE XID = '000200030000002D';

Yukardaki komut bu işlemde sonuçlanan tüm değişiklikleri göstermektedir. İlaveten,  yerini dolduran tüm SQL komutlarıda döner ve bu işlem tarafından tüm satırlara yapılan değişiklikler geri alınabilir.  Flashback Transaction Query gibi hassas bir araç kullanarak, veritabanı yöneticileri ve uygulama geliştiriciler veritabanı veya uygulamadaki mantıksal problemleri kesin olarak teşhis edip gerekli düzeltmeleri yapabilirler.  

Clustering factor hakkında bir inceleme

ERP alt sisteminde geçtiğimiz aylarda indeksler için yapılan iyileştirme çalışması sonucunda, bazı indekslerin hala oldukça yüksek “clustering_factor” değeri ürettiğini gözlemledim. Aşağıda bu sorunlu indekslerden birisi yer almakta.

            BTREE   LEAF    DISTINCT  CLUSTERING  INDEX      TABLE     TABLE

INDEX NAME  LEVEL  BLOCKS   KEYS      FACTOR      NUM ROWS   NUM BLKS  NUM ROWS

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

CUSTID_IDX   3     778150  77,842,100  17,163,350  77,842,100 865,805  77,043,200

…         

Yukardaki CUSTID_IDX indeksi gibi, oldukça yüksek clustering_factor değerini -aynen- muhafaza eden indeskler yüzünden, bu indeksler üzerinde aralıklı taramaların(index range scan) kullanıldığı sorgular çok yavaş çalışmaktaydı, çünkü tablodan oldukça fazla sayıda blok ziyaret edilmekteydi. Peki böyle bir durumda ne yapılması gerekmekte?

Bu soru, bazı önemli noktaların tekrardan gözden geçirilmesini zorunlu kılmaktadır. Başlangıç detayı olarak eklenmesi gereken nokta; indeksteki satır sayısının tablodaki satır sayısından daha fazla olmasıdır. Bununda sebebi, istatistik toplamasında %100 altında bir örnekleme değerinin ve “cascade” seçeneğinin kullanılmış olmasıdır. Oracle, sıklıkla indekslerde tabloda belirtilen örnekleme değerinden daha geniş bir değer kullanmaktadır.

Ortalama aktif oturumlar(Average Active Sessions - AAS) ile ani yüklerin zaman aralıklarının bulunması

“Ortalama Aktif Oturumlar”(Average Active Session - AAS) metriği, Oracle veritabanının tüm  çalışma performansının ölçümünde olağandışı bir şekilde basit ve bir o kadar kullanışlı şekilde hizmet sunmaktadır.  AAS metriği, kısaca “DB Time” değerinin “işlem süresi-elapsed time” değerine bölünmesiyle tanımlanmaktadır.

Sırayla, “DB Time”, hem CPU üzerinde hemde boşta olmayan bekleme durumlarında sıkışmış tüm oturumlar tarafından harcanan zaman olarak tanımlanmaktadır. Diğer bir deyişle, “DB Time” tüm aktif oturumlar tarafından harcanan zamanların toplamı olarakta düşünülebilir.

Mesela, bir dakikalık gözlem süresince aktif olan dört oturum olduğunu düşünelim. Her bir oturum toplamda dört dakikalık “DB Time” değerini vercek şekilde numeratörde birer dakikalık toplam  “DB Time” değerine karşılık gelecektir. Bu örnekte, “geçen süre”  paydası bir dakikadır. Her iki değerin bölümü AAS değeri olarak 4 sonucunu vermektedir. Bu örnektende görüldüğü gibi, 4 AAS metriği 4 aktif oturuma sahip olmaya karşılık gelmektedir. Bu örnekte, ortalama olarak dört aktif oturum bulunmaktadır.

Eğer bu örneği çeşitli dönemlerde aktif durumda olan daha fazla oturum ilave ederek genelleştirirsek, AAS metriğinin hesaplaması gözlem periyodu süresince hala ortalama sayıda aktif  oturumlar hakkında bir fikir verecektir. 

AAS metriği CPU sayısı ile kıyaslandığında oldukça kullanışlı olmaktadır.  Eğer AAS metriği CPU sayısını çok aşarsa, bu durumda veritabanı performansı zarar görecektir. Öte yandan, eğer AAS metriği belirgin şekilde CPU sayısından düşükse, o zaman veritabanı performansı iyi olacaktır. Veritabanı perfomansını sekteye uğratan üst sınırdaki AAS metriğinin eşikdeğeri, uygulamanın davranışına ve son kullanıcıların beklentilerine bağlıdır. Bu yüzden, bu eşikdeğeri uygulama bağlamında belirlenmelidir. AAS eşikdeğeri belirlendiğinde, bu metrik oldukça güvenilir, hazır biçimde bütün veritabanı performans sorunlarının teşhisinde hizmet verecektir. Aslında, “DB Time“ metriğinin düşürülmesi Oracle ADDM iyileştirme aracının yegane hedefi olmaktadır.

Oracle 11.2.0.2 Data Guard performansını genel olarak değerlendirmek

Oracle 11.2.0.2 Data Guard standby veritabanlarını yapıya ilave ettikten sonra birincil veritabanı performansını doğru şekilde değerlendirmek için,  aynı uygulama profili ve yüklemesiyle Dataguard yapılandırmasının öncesinin ve  sonrasının V$SYSMETRIC_SUMMARY  görünümünden ve AWR snapshotlarından alınacak istatistik geçmişleriyla kıyaslanması gerekmektedir.

Data Guard standby uygulaması öncesinde ve sonrasında uygulama profilini değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         İşlem başına fiziksel okuma

·         İşlem başına fiziksel yazma

·         İşlem başına CPU kullanımı

·         İşlem başına redo üretimi

Uygulama performansını değerlendirmek için aşağıdaki istatistikler kıyaslanabilir:

·         Saniye başı redo üretimi veya redo oranı

·         Saniye başı kullanıcı commit işlemi veya saniye başı işlem

·         Saniye başı veritabanı zamanı

·         İşlem başına yanıt süresi

·         SQL servisi yanıt süresi

Birleşmelerde sorgu geliştiricinin uygun yürütme planını seçmesi

Sorgu geliştirici, bir yürütme planının seçilmesi esnasında aşağıdakileri değerlendirmeye almaktadır:

·         Sorgu geliştirici, önce en azından bir veya birden fazla tablo birleşmesinin kesinlikle en az bir satır içeren bir satır kaynağı olarak sonuçlanıp sonuçlanmayacağını belirler. Sorgu geliştirici, bu gibi durumları tablodaki UNIQUE ve PRIMARY KEY kısıtlamalarına bağlı olarak  tanımaktadır. Eğer böyle bir durum mevcutsa, o zaman sorgu geliştirici bu tablolaları ilk olarak birleşme sırasına göre yerleştirir. Ardından, geri kalan tablo kümelerinin birleşmesi işlemine gelinir.

·         Dış(outer) birleşme durumları ile birleşme komutları için, dış birleşme operatörü olan tablo, birleşme sırasında bu durum için diğer tablodan daha sonra gelmelidir. Sorgu geliştirici, bu kuralı ihlal eden birleşme sıralarını değerlendirmeye almaz. Benzer olarak,  bir altsorgu yarı birleşme ve anti birleşmelere dönüştürüldüğünde, bu alt sorgunun tabloları dış sorgu bloğunda bağlı olunan veya ilişkideki tablolardan daha  sonra gelmelidir. Ancak, bazı durumlarda karma(hash) anti birleşmelerin ve yarı birleşmelerin(semijoins) bu sıralama durumunu geçersiz kılması mümkün olmaktadır.

Sorgu geliştirici ile muhtemel birleşme sırasına, birleşme metoduna ve uygun erişim yollarına bağlı olarak  bir yürütme planı kümesi oluşturulur. Ardından, herbir planın maliyeti değerlendirilir ve en düşük maliyete sahip olan seçilir. Sorgu geliştirici, bu maliyetleri aşağıdaki şekillerde değerlendirmeye almaktadır:

“Oracle Database Smart Flash Cache” özelliğinin yapılandırılması

AWR raporunun daha fazla buffer cache ihtiyacı olduğuna işaret ettiğini düşünelim. Paylaşımlı havuzun doğru şekilde ayarlandığından eminsiniz. Buffer cache miktarını, paylaşımlı havuzdaki bellek tahsisini azaltarak, daha yüksek bir minimum seviyeye çıkaramıyorsunuz ve ilave olarak Oracle’a tahsis edeceğiniz daha fazla fiziksel bellek imkanıda bulunmuyor.

İşte bu sıkıntılı durumda, işletim sistemine bağlı olarak, Oracle 11.2 sürümü ile yeni gelen “Oracle Database Smart Flash Cache”  özelliği ile, buffer cache için daha fazla miktarda bellek gerektiğini işaret eden durumlarda, harici olarak ekstra bellek genişletmesi yapılabilir. Bu özellik şu an sadece Solaris ve Oracle Linux işletim sistemleri ile sınırlıdır.  

Flash cache özelliğini devreye almak için aşağıdaki parametrelerin ayarlanması gerekmektedir:

RMAN KEEP FOREVER, KEEP UNTIL TIME ve FORCE komutları

Oracle 11g’de KEEP FOREVER seçeneği Oracle 10g’deki yapısına göre oldukça geliştirilmiş ve online yedekleri sürekli tutmaya yarayan arşivlenmiş loglar muhafaza edilmiştir. Oracle 10g’de, yedek alındıktan sonra zaman noktasında geri kurtarmaya izin veren KEEP FOREVER  seçeneğiyle alınan bu yedek ileri sarılabilmekteydi. Oracle 11g’de, KEEP seçeneği sadece yedeği sürekli tutacak gerekli olan arşivlenmiş logları muhafaza edecektir, böylece sadece yedeğin alındığı noktaya kadar geri kurtarmak için gereken bu yedek kullanılabilir. Bu yedek tamamlandıktan sonra oluşturulan arşivlenmiş logların muhafazasına gerek kalmaz ve DELETE OBSOLETE komutu ile bunlar kullanılmaz olarak işaretlenebilir.

Oysaki Oracle 10g’de, KEEP FOREVER komutuyla alınan yedeklerden sonra alınan bütün arşivlenmiş log yedeklerinin muhafaza edilmesi gerekmekteydi.  KEEP FOREVER komutunun çalışması için RMAN kataloğunun kullanılması gerekirken, KEEP UNTIL TIME komutu katalog gerektirmez.

SQL komutlarının ayrıştırılması safhası hakkında

SQL ile ilgili bir performans sorunu oluştuğunda,sorunu anlamak ve ardından bir çözüm bulabilmek için ilk olarak SQL komutlarının veritabanında nasıl işlendiğinin anlaşılması gerekmektedir. Uygulama, veritabanı instance’ına her bağlandığında, eninde sonunda veritabanı sunucusunda yaslı olan bir sunucu prosesine atanır. Bu sunucu prosesi, veritabanı ve son kullanıcı uygulaması arasındaki arayüzü desteklemektedir. Bu proses ayrıca SQL komutu sentaksını kontrol etmek, SQL komutunun nasıl yürütüldüğünün ve sonuçların son kullanıcı uygulamasına nasıl döndüğünün belirlenmesinden sorumludur. SQL komutu, sunucu prosesi tarafından alındığında, “hafif ayrıştırma-soft parse” meydana gelmektedir. Bu safhada komut sentaksı doğruluk için kontrol edilmekte, komut içinde referans verilen objelere kullanıcının erişim yetkisinin olduğu doğrulanmakta ve SQL “karma” değeri(SHV-SQL hash value) komut metninde hesaplanmaktadır. SHV, veritabanı içinde komutu kolayca belirlemek için kullanılan numerik bir değerdir. Ardından, SGA içindeki “library cache” de SHV in halen mevcut olup olmadığının belirlenmesi için araştırılır. Aynı yada diğer bir sunucu prosesi, benzer bir SQL komutunu halihazırda çalıştırdığında bu olay meydana gelir.  Eğer SHV bulunursa, sunucu prosesi komut hakkında “library cache” içinde saklanan bilgiyi getirir. Bu, yürütme planı olarak bilinen, sorgu içinde çeşitli nesnelere erişim için kullanılan algoritmaları içermektedir.  Komut alındıktan sonra, eğer bağlaç değişkenler(bind variables) komut içinde mevcutsa, aslına uygun değerler yerine geçer ve yürütme planı tarafından belirtilen işlemler sunucu prosesi tarafından yapılır. SQL komutlarını yürütürken bütünsel olarak en düşük kaynak maliyetini ürettiği ve en hızlı yanıt süresini verdiğinden dolayı bu arzu edilen bir olaylar dizisi olmaktadır.

Oracle 11.2 ile askıda tutulan istatistikler

Oracle 11g Sürüm 2 (11.2) itibariyle istatistik toparlarken aşağıdaki yeni özellikler işleme girmiştir.

·         Toparlama işlemi sonunda istatistiklerin otomatik olarak yayınlanması(varsayılan işlem)

·         Yeni istatistikleri askıda tutacak şekilde saklamak

Yeni istatistiklerin askıda tutulacak şekilde saklanması istatistik onaylanması işlemine izin verir ve  sadece tatminkar olunduğu durumlarda bunlar yayınlanır. İstatistiklerin toparlanır toparlanmaz, otomatik olarak yayınlanıp yayınlanmayacağını kontrol etmek için aşağıdaki gibi DBMS_STATS paketi kullanılır:

SELECT DBMS_STATS.GET_PREFS('PUBLISH') PUBLISH FROM DUAL;

Yukardaki sorgu TRUE veya FALSE değerini döndürür. TRUE değeri, istatistiklerin toparlandığında yayınlanacağını gösterirken, FALSE değeri istatistiklerin askıda kalacak şekilde tutulacağını göstermektedir.

PUBLISH ayarı şema veya tablo seviyesinde değiştirilebilir. Örneğin, HR şemasında employees tablosunun PUBLISH ayarını FALSE olarak değiştirmek için aşağıdaki sorgu çalıştırılabilir:

Exec dbms_stats.set_table_prefs('HR', 'EMPLOYEES', 'PUBLISH', 'false');

ASMLIB sürücüsünün “update-driver” komutu ile güncellenmesi

ASMLib sürücüsünün bir ASM instance ını yönetmek için kullanıp kullanmamak hala tartışmalı bir konudur, ancak Oracle’ın bu konuda ısrarlı tavsiyeleri sonucunda Linux platformlarda kullanmayı şahsen ben tercih etmekteyim. Bu noktada, linux kernel güncellemesi öncesi veya sonrasında ASMLib sürücüsününde güncellenmesi gerekmektedir, aksi durumda sürücü uyumsuzluğu sebebiyle ASMLib modülü sisteme yüklenemez. 

Bilindiği üzere ASMLib sürücüsü,  kernel bağımlıdır ve aynı kernel versiyonunu ile eşleşmesi gerekmektedir.  Bu noktada, Oracle web sitesinden ASMLib sürücüsünün güncel versiyonu bulunabilir, siteden ücretsiz olarak indirilip, Linux sisteme kurulabilir. Oracleasm-support 2.1.0 sürümünden itibaren “update-driver” gömülü komutu kullanılarak, hem zamandan tasarruf sağlanabilir, hemde ASMLib sürücüsü güncelleme işlemi basitleştirilebilir.

Peki bu komut nasıl çalışmaktadır?Örnek olarak,  kernel sürücüsünü 2.6.18-194.8.1.0.1.el5 x86_64 versiyonuna yükselttik, ancak ASMLib sürücüsü hala eski versiyonda.  Neticede, açılış sonrasında ASMLib modülü yüklenirken aşağıdaki hata mesajı alınacak ve modul başlatılamayacaktır.

Sorgu geliştirici ile ilgili genel kavramlar

Sorgu geliştirici(query optimizer) ile ilgili kullanılan temel kavramlar aşağıda yer almaktadır.

Değerlendirme(Estimation)

Değerlendirici, verilen bir yürütme planının tüm maliyetini saptamaktadır. Bu hedefe ulaşmak için değerlendirici 3 değişik tipte ölçü üretmektedir.

·         Seçicilik(Selectivity):  Bu ölçü, satır setinden satırların bir bölümünü temsil etmektedir. Seçicilik, sorgudaki city=’Pekin’ gibi bir yükleme veya (city=’’Pekin’ AND product=’tomato’) gibi yüklem kombinasyonlarına bağlıdır.

·         Önem(Cardinality): Bu ölçü, satır setindeki satır sayısını temsil etmektedir.

·         Maliyet(Cost): Bu ölçü, kullanılan kaynağın veya işin birimini temsil etmektedir.Sorgu geliştirici, iş birimi olarak  disk I/O sunu, CPU kullanımını ve bellek kullanımını kullanır.

Eğer istatistikler uygunsa, değerlendirici bu ölçümleri birbiriyle kıyaslamak için kullanır. İstatistikler, ölçümlerin doğruluk derecesini artırmaktadır.