Oracle servis mantığında her database için 2 internal servis (SYS$BACKGROUND, SYS$USERS) ve 116 application servisi olmak üzere toplamda 118 servis kullanılmasına izin verir. Application servislerinden 1 tanesi ise hali hazırda database SID si ile ilişkilendirilmiş olan servisdir. Bir database için yaratılmış olan servisleri service_names parametresini kullanarak görebiliriz.
Bu servisleri monitor etmenin birkaç yöntemi bulunmaktadır.
- Service üzerinden gelen bütün sessionların trace olması için:
execute DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE('service_name');
execute DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE('service_name');
- Service, module ve action trace için;
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(
'service_name', 'module_name', 'action_name');
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(
'service_name', 'module_name', 'action_name');
- Özellikle bir session trace için (v$session viewından alınan sid ve serial#)
execute dbms_monitor.SESSION_TRACE_enable(session_id => 8, serial_num=>88);
execute dbms_monitor.SESSION_TRACE_disable(session_id => 8, serial_num=>88);
- Bütün database session bilgilerini trace için;
execute dbms_monitor.DATABASE_TRACE_ENABLE(TRUE,TRUE);
execute dbms_monitor.DATABASE_TRACE_DISABLE();
Bu trace bilgileri Oracle 11g Release 1 ile beraber aşağıdaki yol izlenerek bulunabilir ve trcsess/tkprof kullanılarak formatlanıp okunabilir.
Linux à $ORACLE_BASE/diag/rdbms/sid/sid/trace/
Windows à $ORACLE_BASE\diag\rdbms\sid\sid\trace
17 Ocak 2009
30 Haziran 2008
SQL ve Tuning
‘SQL Tuning’, hem Database Adminler hem de Developerlar için olmazsa olmaz kavramlar arasındadır. Sistem performansı açısından admin ve developerların sürekli iletişim içerisinde bulunup, sisteme yük getiren sorguların tune edilmesini sağlamaları gerekmektedir.
SQL Tuning’in temel prensipleri arasında kendimize bir tuning metodolojisi belirleyip bu metodolojiyi takip etmek geliyor. Bizim tune işlemindeki öncelikli hedeflerimiz arasında response time’ı en aza indirgemek ve kaynak kullanımını minimalize etmek gelmelidir. Bunları yapabilmemiz için ise özellikle Oracle 11g ile birlikte çok gelişmiş bir ara yüze sahip olan Enterprise Manager bize yardımcı olacaktır. Enterprise Manager ile birlikte ADDM (Automatic Database Diagnostics Management), Top SQL Raporları ve dinamik performans viewlarını effektif bir şekilde kullanabilir ve sistemimizin son durumunu kontrol altında tutabiliriz. Özellikle manuel değilde otomatik tuning yapıyorsak SQL Tuning Advisor ve SQL Access Advisor hertürlü detayı gözler önüne seriyor.
Automatic Database Diagnostics Management sistemimizdeki SQL’lerin alınmış olan istatistiklerini inceler, tavsiyelerde bulunur, high load SQL’leri listeler. AWR raporları sayesinde istediğimiz zaman sistemimizin geçmiş dönemlerdeki performanslarını mukayese etme olanağı sağlar.
Özellikle Oracle 11g ile birlikte istatistiki verilerin önemi bir kat daha artmış durumdadır. Arka planda çalışan istatistikler sayesinde kendi en iyi execution planını çıkarıp, aynı sorgular geldiği zaman bu planı defalarca kullanıp bize istediğimiz minimal response time ve resourse usage’ı sağlayabiliyor. Fakat bu şu demek değildir: her zaman kendi oluşturduğu execution plan en iyisidir. Bu tamamıyle arz talep kavramına dayalı göreceli bir kavramdır. Nedeni ise; Oracle Optimizer’ı ‘cost base’ dir. Yani yaptığı her işi en düşük cost ve ortalama minimum süre için yani optimal cost’a göre hesaplar ve bu doğrultuda execution planını oluşturur ve uygular. Fakat bizim için costun değilde zamanın daha değerli olduğu durumlarda mevcut olacaktır elbet. İşte bu gibi durumlarda da yardımımıza ‘hint’ ler yetişiyor. Hint kavramı bize kendi execution planını değilde, bizim force ettiğimiz planı uygulaması gerektiğini söyler ve kullandırır. Aslında bir bakıma kılavuzluğu biz elimize almış oluruz. O yüzden dikkatli olmakta fayda var.
Buarada SQL Tuning Advisor ve SQL Access Advisor’ıda kullanmayı unutmamalıyız. Kötü yazılmış SQL Statementlarımızı daha iyi nasıl yazabilirizi örneklerle bize gösteriyor. Tavsiye ettiği SQL’leri uygun bulursak kullanabiliriz.
Aslına bakılıcak olursa cost ve time arasında bir karar vermemiz gerekir. Şundan emin olabilirizki en düşük cost’u Oracle bize default olarak sunuyor.
SQL Tuning’in temel prensipleri arasında kendimize bir tuning metodolojisi belirleyip bu metodolojiyi takip etmek geliyor. Bizim tune işlemindeki öncelikli hedeflerimiz arasında response time’ı en aza indirgemek ve kaynak kullanımını minimalize etmek gelmelidir. Bunları yapabilmemiz için ise özellikle Oracle 11g ile birlikte çok gelişmiş bir ara yüze sahip olan Enterprise Manager bize yardımcı olacaktır. Enterprise Manager ile birlikte ADDM (Automatic Database Diagnostics Management), Top SQL Raporları ve dinamik performans viewlarını effektif bir şekilde kullanabilir ve sistemimizin son durumunu kontrol altında tutabiliriz. Özellikle manuel değilde otomatik tuning yapıyorsak SQL Tuning Advisor ve SQL Access Advisor hertürlü detayı gözler önüne seriyor.
Automatic Database Diagnostics Management sistemimizdeki SQL’lerin alınmış olan istatistiklerini inceler, tavsiyelerde bulunur, high load SQL’leri listeler. AWR raporları sayesinde istediğimiz zaman sistemimizin geçmiş dönemlerdeki performanslarını mukayese etme olanağı sağlar.
Özellikle Oracle 11g ile birlikte istatistiki verilerin önemi bir kat daha artmış durumdadır. Arka planda çalışan istatistikler sayesinde kendi en iyi execution planını çıkarıp, aynı sorgular geldiği zaman bu planı defalarca kullanıp bize istediğimiz minimal response time ve resourse usage’ı sağlayabiliyor. Fakat bu şu demek değildir: her zaman kendi oluşturduğu execution plan en iyisidir. Bu tamamıyle arz talep kavramına dayalı göreceli bir kavramdır. Nedeni ise; Oracle Optimizer’ı ‘cost base’ dir. Yani yaptığı her işi en düşük cost ve ortalama minimum süre için yani optimal cost’a göre hesaplar ve bu doğrultuda execution planını oluşturur ve uygular. Fakat bizim için costun değilde zamanın daha değerli olduğu durumlarda mevcut olacaktır elbet. İşte bu gibi durumlarda da yardımımıza ‘hint’ ler yetişiyor. Hint kavramı bize kendi execution planını değilde, bizim force ettiğimiz planı uygulaması gerektiğini söyler ve kullandırır. Aslında bir bakıma kılavuzluğu biz elimize almış oluruz. O yüzden dikkatli olmakta fayda var.
Buarada SQL Tuning Advisor ve SQL Access Advisor’ıda kullanmayı unutmamalıyız. Kötü yazılmış SQL Statementlarımızı daha iyi nasıl yazabilirizi örneklerle bize gösteriyor. Tavsiye ettiği SQL’leri uygun bulursak kullanabiliriz.
Aslına bakılıcak olursa cost ve time arasında bir karar vermemiz gerekir. Şundan emin olabilirizki en düşük cost’u Oracle bize default olarak sunuyor.
Kaydol:
Kayıtlar (Atom)