Adaptive Cursor Sharing (ACS), Oracle 11g R1 ile beraber kullanılmaya başlanılan Oracle’ın yeni özelliklerinden biridir. Cost Based Optimizer (CBO)’ın execution planları oluştururken bir statement için daha fazla execution plan tutmasına olanak sağlayan yapı olarak ön plana çıkmaktadır. Bir statement için birden fazla execution planı tutuyor olmak daha önceki versiyonlardan farklı olarak ilk hard parse olan statement’ın planını daha sonra tekrar tekrar farklı parametrelerle çalışan aynı statementlarıda kullanmak zorunda bırakmamak anlamınada geliyor olacaktır.
Bind variable kavramındaki execution planları ortak kullandırma mantığının aynı plana sahip olmaması gereken 2 cümle için ortak plan kullandırdığı zaman ne kadar maliyetli (costu yüksek) olduğunu görebiliriz. Örneğin;
select * from table_name where id= :dept_id
dept_id değeri ilk olarak 1 daha sonra 2 değerleri gönderilerek sorgulanmış olsun. Bu statement 1 için çalıştığında tablodaki kayıtlardan sadece 1’ i geliyor olsun yani selectivity’si yüksek olsun ve execution plan index üzerinden datayı getirsin. Bu statement 2 için çalıştığında ise tablodaki kayıtların yarısı geliyor olsun ve full table scan (FS) ile dataya erişiyor olsun. Tahmin edileceği gibi bu statement daha birçok kez çalışacaktır. Eğer ACS olmasa idi ilk hard parse olan yani dept_id 1’e göre oluşan execution plan dept_id 2 içinde uygulanacaktı ve FS ile gelmesi gereken bir tablo index üzerinden getirilmeye çalışılacak ve response time’ı düşecekti ve sorgunun sonucu daha uzun sürede oluşacaktır.
Oracle 11g R1 ile beraber aşağıdaki tablolar bind variable larda cursor share edilip edilmediğini takip edip, yorumlayabilmemiz için geliştirilmiş ve 3 adette yeni view eklenmiştir.
V$SQL tablosunda - IS_BIND_SENSITIVE, IS_BIND_AWARE columnları
V$SQL_CS_HISTOGRAM view à SQL statementının bind sensitive olup olmadığını 3 adet frequency histogram ile yorumlamamızı sağlar. Child cursorların kaçar kere çalıştığı bilgisinide içerir.
V$SQL_CS_SELECTIVITY view à Statement ile beraber gelen where koşullarındaki değerleri, bunların selectivitysini ve high value – low value aralığını tutar.
V$SQL_CS_STATISTICS view à Adaptive Cursor’ın nekadar paylaşıldığını gösteren istatistiki tablodur.
17 Kasım 2010
17 Mayıs 2009
Oracle Service Yönetimi
Oracle Clientları ve applicationlar, Oracle Serverlara erişirken “service” ler üzerinden bağlantı sağlarlar ve servisleri monitor ediyor olmak database üzerindeki iş yükünün dağılımını ve kaynak yönetimi (resource management) yapmamızıda kolaylaştırıyor olmak anlamına gelmektedir.
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. Yeni bir servis yaratmak için;
- execute DBMS_SERVICE.CREATE_SERVICE('service_name','db_unique_name’);
- execute DBMS_SERVICE.START_SERVICE('service_name');
Applicationların connection stringlerinede bu servis isimlerini vererek yarattığımız servis üzerinden database imize bağlanmalarını sağlayabiliriz.
url="jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=node-1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-2vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-3vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-4vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"
Eğer gerek duyulursa bu servisi kullanarak bağlanan application userları için resource management yapılabilir yani eğer bir user bu servis üzerinden connection açmış ise, diğer bu servis üzerinden bağlanmış kullanıcılar ile ortak bir havuzu kullanıyorlarmış gibi yönetilebilirler. Örneğin, toplam session açma sayıları, idle kalabilme süreleri, parallel çalışabilme miltarları gibi kısıtlamalar yapılabilir.
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. Yeni bir servis yaratmak için;
- execute DBMS_SERVICE.CREATE_SERVICE('service_name','db_unique_name’);
- execute DBMS_SERVICE.START_SERVICE('service_name');
Applicationların connection stringlerinede bu servis isimlerini vererek yarattığımız servis üzerinden database imize bağlanmalarını sağlayabiliriz.
url="jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=node-1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-2vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-3vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-4vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"
Eğer gerek duyulursa bu servisi kullanarak bağlanan application userları için resource management yapılabilir yani eğer bir user bu servis üzerinden connection açmış ise, diğer bu servis üzerinden bağlanmış kullanıcılar ile ortak bir havuzu kullanıyorlarmış gibi yönetilebilirler. Örneğin, toplam session açma sayıları, idle kalabilme süreleri, parallel çalışabilme miltarları gibi kısıtlamalar yapılabilir.
17 Ocak 2009
Service Aggregation ve DBMS_MONITOR
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
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
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)