Öncelikle Windows ortamlarda
oracle> set ORACLE_SID=deneme komutu ile,
Linux ortamlarda ise
oracle> export ORACLE_SID=deneme komutu ile instance ismimizi belirtiriz.
Kontrol edelim,
Windows için --> oracle> echo %ORACLE_SID%
Linux için --> oracle> echo $ORACLE_HOME
Daha sonra yapılacak işlem ise bir servis üzerinden (servislerle ilgili yazımda anlatmıştım) idle olan database bağlantısını gerçekleştirmek.
Bu arada D:\app\oracle\product\11.2.0\dbhome_1\database\initdeneme.ora dosyasını yaratıp içerisine sadece DB_NAME=deneme yazıp kaydedelim. Bu dizin Linux için u01/app/oracle/product/11.2.0/dbhome_1/dbs/initdeneme.ora olmalıdır.
oracle> sqlplus /nolog
SQL> conn sys/oracle@deneme as sysdba
SQL> create database deneme
LOGFILE GROUP 1 ('D:\app\oracle\oradata\deneme\redo01.log') SIZE 50M,
GROUP 2 ('D:\app\oracle\oradata\deneme\redo02.log') SIZE 50M,
GROUP 3 ('D:\app\oracle\oradata\deneme\redo03.log') SIZE 50M
character set WE8ISO8859P1
national character set utf8
datafile 'D:\app\oracle\oradata\deneme\system01.dbf' size 100M autoextend on next 10M maxsize unlimited extent management local
sysaux datafile 'D:\app\oracle\oradata\deneme\sysaux.dbf' size 100M autoextend on next 10M maxsize unlimited
undo tablespace undotbs1 datafile 'D:\app\oracle\oradata\deneme\undotbs1.dbf' size 100M
default temporary tablespace temp tempfile 'D:\app\oracle\oradata\deneme\temp01.dbf' size 100M;
Sample schema ları daha sonradan kurmak istersek USERS Tablespace ide hazırda bulunsun.
SQL> CREATE TABLESPACE users DATAFILE 'D:\app\oracle\oradata\deneme\users01.dbf' SIZE 25M AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;
Evet, geriye kalan
SQL> alter database mount;
SQL> alter database open;
SQL> select instance_name,version,status,database_status from v$instance;
INSTANCE_NAME VERSION STATUS DATABASE_STATUS
---------------- ----------------- ------------ -----------------
deneme 11.2.0.1.0 STARTED ACTIVE
Hayırlı olsun ....
28 Şubat 2011
23 Şubat 2011
SQL92_SECURITY parametresi
SQL92_SECURITY, Oracle initialization parametrelerinden biridir.
Default değeri "FALSE" dir. Static bir parametredir yani değişmesi durumunda database restart gerekmektedir. Eğer "TRUE" ya getirir isek; kullanıcılar bir tabloya UPDATE veya DELETE yaparken set veya where koşullarında geçen alanlara SELECT çekme hakkınada sahip olması gerekliliğini aramaktadır. Örneğin;
update table_name
set column_name1=yeni_deger
where column_name2=kosul;
Yukarıdaki statementi çalıştıran kimse aşağıdaki select ide çalıştırabiliyor olmalı koşulunu arar.
select column_name1,column_name2 from table_name;
DBA_TAB_PRIVS ve ROLE_TAB_PRIVS view larından bu haklara sahip olmayan kullanıcılar belirlenebilir.
Default değeri "FALSE" dir. Static bir parametredir yani değişmesi durumunda database restart gerekmektedir. Eğer "TRUE" ya getirir isek; kullanıcılar bir tabloya UPDATE veya DELETE yaparken set veya where koşullarında geçen alanlara SELECT çekme hakkınada sahip olması gerekliliğini aramaktadır. Örneğin;
update table_name
set column_name1=yeni_deger
where column_name2=kosul;
Yukarıdaki statementi çalıştıran kimse aşağıdaki select ide çalıştırabiliyor olmalı koşulunu arar.
select column_name1,column_name2 from table_name;
DBA_TAB_PRIVS ve ROLE_TAB_PRIVS view larından bu haklara sahip olmayan kullanıcılar belirlenebilir.
17 Şubat 2011
Geri Dönüş
Merhaba,
2008 yılında açtığım bloğumu pek fazla kullanmadığımı (hiç kullanmadığımı demek daha doğru olacaktır) farkettim ve bugün itibari ile işinize yarayabileceğini düşündüğüm ufak tefek bilgileri sizinle paylaşmaya çalışacağım. Sizlerinde paylaşmak istedikleri yazılar olursa bunlarıda değerlendirmeyi düşünüyorum.
Mail adresim: burak.uysal@yahoo.com
görüşmek üzere ....
2008 yılında açtığım bloğumu pek fazla kullanmadığımı (hiç kullanmadığımı demek daha doğru olacaktır) farkettim ve bugün itibari ile işinize yarayabileceğini düşündüğüm ufak tefek bilgileri sizinle paylaşmaya çalışacağım. Sizlerinde paylaşmak istedikleri yazılar olursa bunlarıda değerlendirmeyi düşünüyorum.
Mail adresim: burak.uysal@yahoo.com
görüşmek üzere ....
tkprof – trcsess trace komutları
Bu yazım boyunca trcsess ve tkprof komutlarının nasıl kullanılacağını anlatıyor olacağım. Öncelikle bir komut satırı açarak trace ettiğimiz session ve/veya servisler ile ilgili trace file ların bulunduğu dosya altına gidiyoruz. Bu dosya Oracle 11g R1 ve sonrası için aşağıdaki uzantılarda bulunabilir.
Linux --> $ORACLE_BASE/diag/rdbms/sid/sid/trace/
Windows --> $ORACLE_BASE\diag\rdbms\sid\sid\trace
trcsess komutunun parametreleri aşağıdaki gibidir:
trcsess [output=output_file_name] [session=session_id] [clientid=client_identifier] [service=service_name] [action=action_name] [module=module_name] []
Daha sonra trcsess komutuna input dosyarını vermelisiniz. Örneğin;
oracle> trcsess output=tracedosyam.trc $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc
Input dosyalarını verirken belirli kısıtlamalar yapabiliriz. Örneğin;
oracle> trcsess output=tracedosyam.trc service=service_name module=module_name $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc
Bu kısıtlamalar trcsess komutunun oluşturacağı output dosyasının büyüklüğünü ve sizin aradığınız verileri bulmanızda zorlanmamanızıda sağlayacaktır.
trcsess komutunun output dosyasına bir örnek:
*** [ Unix process pid: 1907 ]
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
…
====================
PARSING IN CURSOR #4 len=23 dep=0 uid=82 oct=3 lid=82 tim=1256987632548698 hv=4584569525 ad='34b8f852' sqlid='f34brkbt8brk5'
select * from mytable
END OF STMT
PARSE #4:c=45698,e=52459,p=35,cr=403,cu=0,mis=1,r=0,dep=0,og=1,tim=1254589632547895
EXEC #4:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1478596541235896
FETCH #4:c=1000,e=581,p=6,cr=6,cu=0,mis=0,r=1,dep=0,og=1,tim=1124589632545896
FETCH #4:c=0,e=45,p=0,cr=1,cu=0,mis=0,r=15,dep=0,og=1,tim=1785421358965412
…
FETCH #4:c=0,e=49,p=0,cr=1,cu=0,mis=0,r=1,dep=0,og=1,tim=1456785412563987
STAT #4 id=1 cnt=107 pid=0 pos=1 obj=70285 op='TABLE ACCESS FULL MYTABLE (cr=15 pr=6 pw=6 time=0 us cost=3 size=7276 card=107)'
*** [ Unix process pid: 1908 ]
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
Bu dosyayı formatlamak için kullandığımız komut ise tkprof
tkprof inputfile outputfile [waits=yes|no] [sort=option] [print=n] [aggregate=yes|no] [insert=sqlscritfile] [sys=yes|no] [width=n] [table=schema.table] [explain=user/password] [record=statementfile]
Örneğin;
oracle> tkprof inputfile= tracedosyam.trc outputfile= selecttrace.trc sys=no table=schema.mytable
...
select max(column_name)
from mytable
where column_name=’Literal’
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- -------
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.21 0.20 307 311 0 1
------- ------ -------- ---------- ---------- ---------- ---------- -------
total 4 0.22 0.11 307 311 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 31
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=307 pr=311 pw=0 time=52845 us)
77 TABLE ACCESS FULL MYTABLE (cr=307 pr=311 pw=0 time=11524 us)
Linux --> $ORACLE_BASE/diag/rdbms/sid/sid/trace/
Windows --> $ORACLE_BASE\diag\rdbms\sid\sid\trace
trcsess komutunun parametreleri aşağıdaki gibidir:
trcsess [output=output_file_name] [session=session_id] [clientid=client_identifier] [service=service_name] [action=action_name] [module=module_name] []
Daha sonra trcsess komutuna input dosyarını vermelisiniz. Örneğin;
oracle> trcsess output=tracedosyam.trc $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc
Input dosyalarını verirken belirli kısıtlamalar yapabiliriz. Örneğin;
oracle> trcsess output=tracedosyam.trc service=service_name module=module_name $ORACLE_BASE/diag/rdbms/orcl/orcl/trace/*.trc
Bu kısıtlamalar trcsess komutunun oluşturacağı output dosyasının büyüklüğünü ve sizin aradığınız verileri bulmanızda zorlanmamanızıda sağlayacaktır.
trcsess komutunun output dosyasına bir örnek:
*** [ Unix process pid: 1907 ]
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
*** 2011-02-02 05:19:19.19
…
====================
PARSING IN CURSOR #4 len=23 dep=0 uid=82 oct=3 lid=82 tim=1256987632548698 hv=4584569525 ad='34b8f852' sqlid='f34brkbt8brk5'
select * from mytable
END OF STMT
PARSE #4:c=45698,e=52459,p=35,cr=403,cu=0,mis=1,r=0,dep=0,og=1,tim=1254589632547895
EXEC #4:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1478596541235896
FETCH #4:c=1000,e=581,p=6,cr=6,cu=0,mis=0,r=1,dep=0,og=1,tim=1124589632545896
FETCH #4:c=0,e=45,p=0,cr=1,cu=0,mis=0,r=15,dep=0,og=1,tim=1785421358965412
…
FETCH #4:c=0,e=49,p=0,cr=1,cu=0,mis=0,r=1,dep=0,og=1,tim=1456785412563987
STAT #4 id=1 cnt=107 pid=0 pos=1 obj=70285 op='TABLE ACCESS FULL MYTABLE (cr=15 pr=6 pw=6 time=0 us cost=3 size=7276 card=107)'
*** [ Unix process pid: 1908 ]
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
*** 2011-02-02 05:29:29.29
Bu dosyayı formatlamak için kullandığımız komut ise tkprof
tkprof inputfile outputfile [waits=yes|no] [sort=option] [print=n] [aggregate=yes|no] [insert=sqlscritfile] [sys=yes|no] [width=n] [table=schema.table] [explain=user/password] [record=statementfile]
Örneğin;
oracle> tkprof inputfile= tracedosyam.trc outputfile= selecttrace.trc sys=no table=schema.mytable
...
select max(column_name)
from mytable
where column_name=’Literal’
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- -------
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.21 0.20 307 311 0 1
------- ------ -------- ---------- ---------- ---------- ---------- -------
total 4 0.22 0.11 307 311 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 31
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=307 pr=311 pw=0 time=52845 us)
77 TABLE ACCESS FULL MYTABLE (cr=307 pr=311 pw=0 time=11524 us)
17 Kasım 2010
Adaptive Cursor Sharing
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.
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 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)