Oracle Veritabanı: AWR Raporlarını Okumak - Reading AWR Reports

Awr raporlarını daha çok bir performans sorunu yaşadığımızda çıkarırız. Awr raporları ile veritabanındaki aktiviteleri rahatça görebiliriz. Bu raporlarda performansla ilgili bilgiler güzelce ayarlanmışlardır. Awr raporlarını çıkarırken 1 saatten daha uzun aralıkları kontrol etmemiz genel sorunları fark etmemiz için daha yararlı olur.

AWR Raporları Nasıl Yaratılmaktadır?

Her 60 dakikada bir veritabanında bir snapshot alınır. Snapshot da veritabanın durumu ile ilgili o andaki bilgiler toplanır. Sonrasında bu bilgiler data dictionary de depolanır. Bu snapshot'lar bir id ile işaretlenir.

AWR Raporu:

Veritabanında asıl olarak aradığımız sorun performans olduğu için sistemin ne için beklediğini görmek yani wait event'lerini araştırmak daha önemlidir. Process'ler beklediğinde genelde başka process'ler tarafından bekletildikleri için beklerler.

Raporun başlangıcında sistem ile ilgili genel bilgiler verilir. Sistemin kullandığı hafıza, bu hafızanın nerelere ayrıldığı, sistemdeki CPU kullanımı gibi bilgiler yer almaktadır.

Raporun içerisinde Wait Event'leriyle ilgili, Memory kullanımı ile ilgili ve diğer veritabanı içerisindeki ana modüllerdeki kullanım istatistikleri gösterilir.

Bazı incelediğimiz başlıklar aşağıdaki gibidir:

Load Profile:

Bu bölümde SQL'lerle ilgili profil bilgileri yer alınır. Üretilen redo log'lar fiziksel okuma ve yazmalar, transaction'lar, Parse edilen SQL sayıları ve bunların istatistikleri yer alır. Sisteme göre bunların sayılarının fazla mı az mı olduğunu tahmin edebiliriz. Aşağıdaki örneğimize bakaraktan sisteme girişilerin(logons) az olduğunu, transaction'ların fazla olmadığını, hard parse'ların minimum değerlerde olduklarını görebiliriz. Buradan da sistemin üzerindeki yükün çok fazla olmadığını anlayabiliriz.

DB Time: Kullanıcının veritabanında harcadığı zamandır. Bu değer kullanıcının background process'leriyle beklediği süreyi vermez. Kendi session'ımız için olan bekleme süresini görmek için  aşağıdaki gibi bir sorgu yazabiliriz.

select * from v$sess_time_model where stat_name='DB time' and SID=2;

Diğer bir sorgu ise bütün veritabanı için geçerlidir.bütün session'ların db_time'ının toplanmasıyla bulunur.

 select * from v$sys_time_model where stat_name='DB time'; 

DB CPU: Kullanıcının CPU'da geçirdiği zamandır. Değerler mikrosaniye cinsindendir.

Sequence Load Elapsed Time: Sequence'larda gelecek numaranın elde edilmesi için geçirilen zamandır. Eğer sequence'lar cache'lenirse bu miktar sıfırlanır.

Redo Size: Üretilen redo verileridir.

Logical Reads:

Physical Reads: I/O isteklerine neden olan okumalar. Veritabanı bloklarından direk okumalar

Block Changes: O aralıkta değiştirilen blok sayısı

Physical Writes: Bloklara yazma işlemleri

User Calls: Kullanıcılar tarafından gönderilen sorgular

Parses: Hard ve Soft parse'ların toplamı

Hard Parse: Cache'de olmayan ve tamamen yeni bir SQL parse'ı gerektiren sorgular. Bu sorgular analiz edilerek planları çıkartılır.

Soft Parse: Geçmiş Hard Parse edilmiş sorgulardan çıkartılırlar. Hard Parse'lara göre daha az kaynak tüketirler. Örneğin çalışanlar tablosu Cache'de yokken sorgulandıysa Hard Parse edilir. Sonrasında bu tabloyla ilgili başka bir bilgi istendiğinde bu sorgu artık Hard Parse edilmez. Daha önceki kullanımdan kalan bilgilerle Soft Parse edilir.

Failed Parse Elapsed Time: Parse hatasıyla sonunda fail eden sorgulardır.

Logons: Uygulamaya yapılan girişler

Executes: Çalıştırılan SQL'ler. Select ifadeleri için bu istatistiğin içine sonuçların getirilmesi de eklenir.

Background CPU Time: Veritabanının background process'leri tarafından harcanan zaman

Transactions: Yapılan Transaction'lar.

Not: Transaction Nedir?
Transaction olarak belirttiğimiz sorgular ya DML ifadeleridir ya da DDL ifadeleridir. DDL ifadeleri gönderildiğinde otomatik olarak commit edilirken, DML ifadeleri gönderildiğinde ertesinde commit veya rollback sorgularıda gönderilmelidirler ki transaction bitsin.

Bütün istatistikleri görmek için v$statname sorgusu kullanılmalıdır.

 select * from v$statname; 

Time Model Örneği:

Buradaki örneğimize göre SQL'lerin çalışma zamanı en fazla zaman alan işlem. Awr raporunun alındığı aralıkta PL/SQL prosedürünün çalıştırılması en fazla zaman alan 3. işlemdir.

Session'ımızdaki Toplanmış İstatistikler:
Buradan da session'ımızla ilgili istatistikleri awr raporu çıkarmadan görebiliriz.

select * from v$mystat a inner join v$statname b on a.statistic#=b.statistic#;

Session'ımızı başka session'larla karşılaştırmak istersek aşağıdakinin benzeri bir sorgu yazabiliriz. Bu sorgu kısaca session pga memory'si 30mb'dan büyük olan session'ları bulmak üzerinedir.

 select t.sid,username,name,value from   
 v$statname n,v$session s, v$sesstat t  
  where s.sid=t.sid   
  and n.statistic#=t.statistic#  
  and s.type='USER'  
  and s.username is not null  
  and n.name='session pga memory'  
  and t.value> 30000;  

Instance Efficency Percentages:

Bu bölümde memory'nin hangi bölümlerine ne kadar gidildiği belirlenir. Bu oranlar bir data parçasının hangi bölümde ne kadar çok bulunduğunu gösterir. Hepsinin değerleri %100'e yakın olmalıdır. Aşağıdaki örnek te Execute Parse % ve Parse CPU to Parse Elapsed % yüzdeleri aşağıdaki örnekte düşük olmalarının nedeni  parse etmeyle ilgili bir problem olabilir. Bind değişkenlerinin kullanılmaması veya Shared Pool'un yetersiz olması nedeniyle bu kadar düşük olabilir.

Buffer Hit: Bu oran aranan blokun diskten okuması yerine, buffer cachede kaç kere bulunduğunu gösterir.

Buffer Nowait: Data'nın yüzde kaç oranında hiç beklemeden bulunduğunu gösterir.

Library Hit: SQL ve PL/SQL'in  shared pool içerisinde yüzde kaç oranında bulunduğunu gösterir.

In-Memory Sort: Sort(Düzenleme) işlerinin disk yerine hafıza kısmında okumasının yapılmasının oranının kaç olduğunu gösterir.

Soft Parse: Shared Pool içerisine depolanmış SQL'in ne kadar çok kullanıldığını gösterir.

Latch Hit: Latch işlemlerinin hiç bekletilmeden ne kadar oranda erişildiğini gösterir.

Shared Pool Statistics:

Buradaki istatistikler hafızanın ne kadarının kullanıldığını göstermektedir. Hafızanın yüzde 90'ından fazlası kullanılıyorsa burada Shared Pool için ayrılan hafıza konusunda eksiklikler olduğu öngörülebilir.

Advisory Statistics:

Advisory İstatistiklerinde veritabanında kullanılan hafıza parçaları ile ilgili çeşitli tavsiye edilen hafıza miktarları ve hangi hafıza oranında artışların sisteme ne kadar etki edeceğini gösteren tablolar bulunur.

IO Stats:

IO Stats'da dosya okuma yazma işlemleriyle ilgili bilgiler bulunur. Hangi dosyalarını ne kadar okunduğu, hangi tablespace'lerde ne kadar okuma yapıldığı ve bunların oranlarr, hangi fonksiyonların okuma yazma işlemlerini nasıl ve ne kadar yaptığını  gösterir. Bu şekilde hangi dosya veya tablespace'lerde okuma yazma yoğunluğu olduğunu keşfedebiliriz.

Top 5 Timed Events:

Bu bölümde bütün session'lar için bekleme istatistikleri ve ne için beklenildiği ölçülür. En çok karşılaşılan Wait Event'leri sıralanmıştır. En önemli bölümdür. Wait Class bölümünde sorunun neyle ilgili olduğunu görebiliriz. Waits sütünu kaç kere bekleme gerçekleştiğini göstermektedir. Time sütunu ise veritabanında toplam ne kada CPU zamanı geçirildiğini gösterir.

Buradaki wait olaylarına göre nerelerde sıkışıklık olduğu görülebilinir. Veritabanında çok fazla okumamı var, yoksa okumalar mı yavaş gerçekleşiyor bunları görebiliriz. Wait Class'larına bakarak hangi konularla ilgili sorunlar olduğu bulunabilinir.

İlk 5 problem arasında Latch Wait'leri varsa bu araştırılması gereken sorundur. Veritabanı genel olarak yavaş ise  ve "CPU", "Db  file sequential read", "Db file scattered read" bilgilerini içeriyorsa  SQL'lerle ilgili bir sorun olma ihtimali vardır.

Db file scattered read: Bu wait event'i full table scans ve index fast full scan'leri gösterir. Bunu engellemek için index'lerin düzgün yaratılması ve tabloları sorgularken index scan'i tercih edecek şekilde düzenlenmiş sql'ler kullanılması gerekir. Full Table Scan'in gerçekleştiği tabloları görmek istersek Segment Statistics altında Segment By Physical Reads tablosuna bakabiliriz.

Db file sequential read:  Sequential read yapıldığında, scattered read'in tersi olarak index'lerle okuma yapıldığını gösterir. Bu işlemin çok olması uygulamanın yüksek bir istek sayısına sahip olduğunu gösterebilir.

Buffer busy wait: Belli bir blok'a olan erişimin fazla olması veya birden çok kaynak tarafından kullanılması "buffer busy wait" olayına neden olur.

Enq:TX - row lock contention: Herhangi bir SQL'in bir blok'u etkilemesi, modifiye etmesi durumunda bu blok üzerinde bir kilit konur. Bu kilit olarak belirttiğimiz lock'lar, başka bir SQL'den gelen istek sonrasında o SQL'in bekletilmesine neden olurlar. Diğer SQL'in işini bitirene kadar o blok üzerinde kilit yerleştirmesi, bu wait event'i tetikler.

SQL İstatistikleri:

Awr raporları SQL'lerle ilgili bir sürü rapor sunmaktadır.

Bu raporlarda çeşitli kriterlere göre elde edilmiş istatistikli SQL'ler konulara ayrılmıştır. En fazla CPU tüketenler, en fazla okuma yapanlar, en fazla parse edilmiş olanlar gibi konular vardır. Hangi konuyu düzeltmek istiyorsak o konudaki SQL'lere gitmeliyiz. O konularda değişiklikler yaptıktan sonra tekrar istatistik toplayarak sorunla ilgili gözlemler yapabiliriz. Örneğin sorunumuz Parse edilmiş sql'ler ise bunların parse edilmesini engellemek için tek bir kere sorgulayıp memory'e yerleştirebilir ve hep aynı şekilde sorgulanmasını sağlayabiliriz. Başka bir örnek verirsek eğer SQL ordered by Elapsed Time konusuna göre ayrılmış SQL'leri inceleyip bu SQL'lerle ilgili gözlemler yapıp bunların niye çok sürdüğünü, bir lock yüzünden mi bu kadar uzun sürdüğünü veya çok fazla mı fiziksel okuma yaptığını inceleyebiliriz.

Buradaki başlıklardan SQL ordered by CPU Time başlığı da çok kullanılan başlıklardandır. Burada en fazla kaynak tüketen SQL ve PL\SQL'ler gösterilmektedir. Buradaki SQL ve PL\SQL'leri veritabanına etkilerini azaltmak içindüzenleyebiliriz.

Referans:
http://mallinenisrihari.blogspot.com.tr/2012/02/awr-report-analysing.html
http://www.bash-dba.com/2011/09/how-to-read-awr-reports-1.html

Oracle Veritabanı: SQL Çalışma Sırası - Problemli Sql İncelemesi - SQL Sequence - Analysing a SQL Statment - SQL Parsing

SQL incelemelerini yapmak için SQL'lerin nasıl işlendiğini bilmek gerekir. SQL işlenmesi 4 ana kısımdan oluşur.

SQL çalıştırılınca ilk aşamada parse edilir. Syntax kontrolü ve yetki  ve mantık kontrolü yapılır. Sorgu doğru yazılmış mı, sorgu doğru yazıldıysa sorgu da yer alan kaynaklara erişilebilinir mi, sorgu çalışabilir durumdaysa anlamlı bir ifade mi oluşturmuştur gibi sorular sorulabilinir. Bundan sonra olay sorgu içerisindeki kaynakların Shared Pool'da olup olmadığının aranmasıdır. Sorgunun arayacağı datalar shared pool'da varsa soft parse edilir. Daha önceden yoksa hard parse edilir. Execution plan'ı çıkarılır.  Sorgu eskiden bire bir şekilde çalıştırıldıysa direk cache'den çekilir. SQL sorgularımızda bind değişkenleri kullanırsak hard parse'lara gerek kalmaz.

Shared Pool içerisinde yer alan library cache ve sqlarea PL/SQL ve SQL ifadelerini saklamak içindir. Bir sorgu çalıştırıldığında ilk önce bu cache ortamı aranır.

Bind aşamasına gelindiğinde sorgu içerisinde bind değişkenleri aranır. Bu bind değişkenleri varsa ifadeye değerler atanır. Bu şekilde çalıştırılında sorgu soft parse edilir. Böylece kaynaklar daha az kullanılmış olur.

Execute ile sorgu için gerekli işlemler yapılmaya başlanır. Tablolar sorgulanır.

Fetch ile sonuçlar geri döndürülür. Düzenlenmesi gerekiyorsa düzenlenir.

Execution Plan Nedir?

Execution plan Oracle Optimizer tarafından belirlenen adımlar serisidir. SQL'ler çalıştırılırken işlemler sıralanır. Sorguda sıralama varsa Sort işlemi, başka bir tabloyla birleştirildiyse join işlemi bu plana eklenir. Bu planlardan sorunlar tespit edilebilinir. Eğer index  yerine full table scan yapılıyorsa, hint kullanılmıyorsa doğal olarak kaynaklar fazla kullanılıyor demektir.

Execution planına göre  çeşitli parametre değişiklikleri yapmamız gerekebilir. İndex yaratıp silmemiz gerekebilir. İstatistik toplamamız gerekip gerekmediğini görebiliriz.

Execution Plan'lerin Görüntülenmesi:

-"Explain Plan" komutu ile optimizer'ın kullanmayı seçtiği yolu görebiliriz. Explain Plan komutunda sorgu çalıştırılmaz; sadece optimizer seçebileceği yol gösterilir.

-V$SQL_PLAN view'ı ile çalıştırılan SQL komutlarının planlarını görebiliriz. Bir durum örneği vermemiz gerekirse ilk önce istenen SQL'in id'si bulunur. Oradaki SQL id V$SQL_PLAN içerisinde aranır ve orada seçilen operasyonlar görülür.

select prev_sql_id from v$session where sid =392;  
   
 select * from v$sql_plan where sql_id=(select prev_sql_id from v$session where sid =392);

V$SQL_PLAN'de gerçekten çalıştırılmış SQL gösterilir. EXPLAIN PLAN'de ise teorik olarak belirlenmiş bir SQL bulunur.

V$SQL_PLAN dışında incelenebilecek 2 tane daha önemli tablo bulunur. Bunlar V$SQL_PLAN_STATISTICS ve v$SQL_PLAN_STATISTICS_ALL'dur.  V$SQL_PLAN_STATISTICS_ALL view'ı V$SQL_PLAN,V$SQLPLA_STATISTICS ve V$SQL_WORKAREA tablolarının bileşiminden oluşur.
  
Problemli SQL İncelemesi:

Problemli SQL'leri incelerken önce bazı konulara dikkat etmemiz gerekir. Bunlara hızlıca bakmak iyi olur. Çünkü bunlar temel konulardır. SQL index'inin incelenmesi, SQL'lerde hint kullanılması, SQL sorgularının
biçimlendirilmesi gibi konular için inceleme yapmamız gerekir.

Problemli SQL'ler genelde çok kaynak tüketirler. Uzun parse sürelerine sahiptirler. CPU tüketimi fazladır. Fazladan wait'lere neden oluyordur. Çok fazla I/O yapıyorlardır. Kaynaklar bakımından sorgular AWR raporlarında listelenirler. Buradan hangi sorgularda değişiklik yapılabilineceği araştırılabilinir.

Sql'leri nasıl inceleyebiliriz? Eğer "Toad" programını kullanıyorsak, üst bardaki ambulans görüntülü tuşu incelemek istediğimiz SQL'i seçtikten sonra tıklayabiliriz. Sqlplus'ta çalıştırıyorsak "set autotrace=on" şeklide sorgumuzu çalıştırmadan önce ifademizi çalıştırmamız gerekir.

 Bu konuları eğer sıralarsak:

-Tablolar ve index'ler analiz edildi mi?

Index ve tabloların en son analiz edildiği zaman

-SQL Hint'leri kullanılmış mı?

SQL Hint'leri

-Cartesian Product kullanılmış mı?

Kartezyen çarpım bir sorgunun sırasında kullanıldıysa bu sorgu çok fazla kaynak harcamaktadır. Bu sorgunun tekrar düzenlenmesi gerekebilir. O yüzden buna dikkat edilmelidir.

-Full Table Scan mi kullanıyor?

Full Table Scan yapılması gereken zamanlarda sorgularımızı iyice incelememiz gerekir. Çünkü full table scan bayağı maliyetli olabilir. Eğer tablomuz çok küçükse, tablonun büyük bir kısmını sonuç olarak getiriyorsa full table scan iyi bir sorgulama yöntemiyken, tablo çok büyükse ve çok az bir sonuç için full table scan yapılıyorsa kötü bir sorgulama yöntemine dönüşür.

-Sorgu içerisinde kaç tablo join edilmiş?

Sorgu içerisinde join edilen tablolar arttıkça "Cost Based Optimizer" 'ın aralarından seçeceği yöntem sayısı artıyor. Seçenek artınca kullanılan zaman artıyor. Bu sorunu sorgumuzu "Explain Plan" ile test edip, sonuç olarak A-B-C-E-D şeklinde sıralama yaptıysa tespit edebiliriz. A-B-C-D-E şeklinde olsaydı kullanım daha başarılı olurdu. Bu sorunu hint kullanımı ile aşabiliriz ancak hint kullanımı önceden de belirttiğimiz gibi çok tercih edilmemektedir.

-Sorgu planı içerisinde "Remote" sözcüğü var mı?

Bunun anlamı sorgunun sonuçlarının çekilmesi için uzak bir veritabanı bağlantısı yapılmakta; yani dblink kullanılıyor olabilmektedir. Bu durum doğal olarak sonuçların gelmesini geciktirebilir.

-Trigger bulunan bir tabloya DML ifadelerimi uygulanmakta?

Bu soru sorgunun performansını çok ilgilendirmektedir; çünkü her bir DML ifadesinde(Insert,Update,Delete) sorgu her çalıştığında trigger'ı da tetikleyeceği için zaman kaybına neden olacaktır.

 SELECT *  
 FROM  dba_triggers  
 WHERE table_name = 'tablo_adı';

-INSERT/UPDATE/DELETE yavaşlığı:

Bu durum ise ancak sorguların birbirini lock'lamasıyla oluşabilir. Eskiden çok kısa süren DML işlemleri şimdi çok uzun sürüyorsa eğer sistemdeki "lock"'lar araştırılmalıdır. Aşağıdaki 2 sorgu bu konuda bize yardımcı olabilir.

Bu sorgu bize sistemdeki kilitli durumları verir:

Bu sorguda işletim sistemi kullanıcısını parametre olarak vermek yeterlidir. Client PID veya Server PID'de sorup bu sorguyu daha detaylı hale getirebiliriz.

 SELECT  s.osuser  
 ,  s.process  
 ,  p.spid  
 ,  s.username  
 ,  decode (s.status,'INACTIVE','I'  
   ,  'ACTIVE' ,'A'  
   ,  'KILLED','K'  
   ,  s.status)  status  
 ,  w.event  
 ,  w.wait_time  
 ,  t.sql_text  
 FROM  sys.v_$session s  
 JOIN  sys.v_$process p ON (p.addr = s.paddr)  
 LEFT OUTER JOIN  
   sys.v_$session_wait w ON (w.sid = s.sid)  
 LEFT OUTER JOIN  
   sys.v_$sqltext t  
   ON (  
     t.address = s.sql_address  
   AND  t.hash_value = s.sql_hash_value  
   )  
 WHERE  p.background IS NULL  
 AND  s.audsid != userenv('SESSIONID')  
 AND  (  
     upper(s.osuser) like upper('&response')  
   OR  s.process = '&response'  
   )  
 AND  (  
     p.username = 'oracle'  
   OR  p.username = s.osuser  
   )  
 UNION ALL  
 SELECT  s.osuser  
 ,  s.process  
 ,  p.spid  
 ,  s.username  
 ,  decode (s.status,'INACTIVE','I'  
   ,  'ACTIVE' ,'A'  
   ,  'KILLED','K'  
   ,  s.status)  status  
 ,  w.event  
 ,  w.wait_time  
 ,  t.sql_text  
 FROM  sys.v_$process p  
 JOIN  sys.v_$session s ON (p.addr = s.paddr)  
 LEFT OUTER JOIN  
   sys.v_$session_wait w ON (w.sid = s.sid)  
 LEFT OUTER JOIN  
   sys.v_$sqltext t  
   ON (  
     t.address = s.sql_address  
   AND  t.hash_value = s.sql_hash_value  
   )  
 WHERE  p.background IS NULL  
 AND  s.audsid != userenv('SESSIONID')  
 AND  p.spid = '&response'  
 AND  (  
     p.username = 'oracle'  
   OR  p.username = s.osuser  
   )  
 ORDER BY 1,2,3  
 /  

Buradaki sorgu ise bekleyen ve bekleten kullanıları ve bekleme tiplerini listelemektedir.

 SELECT waitsess.osuser || '(' || waiter.sid || ')' waiter,  
   waiter.type,  
   case waiter.request  
     when 0 then null  
     when 1 then null  
     when 2 then 'row-S'  
     when 3 then 'row-X'  
     when 4 then 'share'  
     when 5 then 'sRowX'  
     when 6 then 'excl'  
   end req,  
   holdsess.osuser || '(' || holder.sid || ')' holder,  
   case holder.lmode  
     when 0 then null  
     when 1 then null  
     when 2 then 'row-S'  
     when 3 then 'row-X'  
     when 4 then 'share'  
     when 5 then 'sRowX'  
     when 6 then 'excl'  
   end held,  
   nvl(obj.object_name, waiter.id1 || ',' || waiter.id2) object  
 FROM sys.v_$lock holder  
 JOIN sys.v_$lock waiter  
   ON (  
     holder.id1 = waiter.id1  
   AND  holder.id2 = waiter.id2  
   AND  holder.type = waiter.type  
   )  
 JOIN sys.v_$session holdsess  
   ON (holdsess.sid = holder.sid)  
 JOIN sys.v_$session waitsess  
   ON (waitsess.sid = waiter.sid)  
 LEFT OUTER JOIN sys.v_$lock tmhold  
   ON (tmhold.type = 'TM' and tmhold.sid = holder.sid)  
 LEFT OUTER JOIN sys.v_$lock tmwait  
   ON (tmwait.type = 'TM'  
   AND tmwait.sid = waiter.sid)  
 LEFT OUTER JOIN dba_objects obj  
   ON (obj.object_id = tmwait.id1)  
 WHERE holder.request = 0  
 AND holder.block = 1  
 AND waiter.request > 0  
 AND nvl(tmhold.id1,0) = nvl(tmwait.id1, 0)  
 /  

Oracle Veritabanı: Hints - Hint'ler - Hint Kullanımı

Aşağıdaki doküman bize hint'lerle ilgili bilgiler vermektedir. Bazı sorgularda "hint" kullanımını görebiliriz. Bu kullanım bazen kullanılan SQL'lerin yavaş çalışmasına neden olabilirken bazen de amacına uygun çalışabilmektedir. Oracle tarafından tavsiye edilen ise bu hint'lerin mümkün olan en az şekilde kullanılmasıdır.

Genel Kullanım Syntax'ı

select /*+ hint_adı */ kolon_adı from tablo_adı 

Hint	Purpose	Use when...
Hints for Access Methods
FULL(tab)	Force a Full Table Scan on tab.	Used to stop Oracle from performing an index scan.
ROWID(tab)	Force a table access by Rowid on tab	Given an equals condition on a rowid, Oracle will alwayse use it. This hint is used to force a Rowid Range scan on tab.
CLUSTER(tab)	Force a cluster scan on tab	This would be rare. A cluster scan is pretty good, so Oracle will normally select it automatically. If it doesn't, this hint will force a cluster scan.
HASH(tab)	Force a hash access on tab if tab is hash clustered.	Typically an equals predicate on a hash clustered table will always use hash access, unless the table is very small indeed. This hint may be required if accessing a hash clustered table via an IN list, or an IN subquery
INDEX(tab [ ind ...])	Force an index scan on table tab	Specifying just the table name (or alias) is the preferred method of stopping a Full Table Scan. If the statistics are calculated against the tables and indexes, Oracle should choose the best available index. The second form is dangerous, as it assumes the name of the index to be used will not change. Only use it if there are many indexes and Oracle will not choose the right one. Better yet, use NO_INDEX to disable the index you want to avoid. If you supply multiple indexes, Oracle will usually choose the best one from the list specified. Beware though that you don't fall into the AND-EQUAL trap.
INDEX_COMBINE(tab [ ind ...])	Forces a bitmap index access path on tab	Primarily this hint just tells Oracle to use the bitmap indexes on table tab. Otherwise Oracle will choose the best combination of indexes it can think of based on the statistics. If it is ignoring a bitmap index that you think would be helpful, you may specify that index plus all of the others taht you want to be used. Note that this does not force the use of those indexes, Oracle will still make cost based choices.
INDEX_JOIN(tab [ ind ...])	Use the Index Join technique to avoid a table access.	All columns in your SQL for a given table are contained in two or more indexes. Oracle can merge the indexes to avoid a table lookup. If there are different possible combinations of indexes that could be used, specify the index names as well if there is a particular combination that would be faster.
INDEX_DESC(tab [ ind ...])	Same as the INDEX hint, except process range scans in descending order	Use this hint if you are using an index to sort rows instead of an ORDER BY.
INDEX_FFS(tab [ ind ...])	Forces a Fast Full Scan on one of tab's indexes	If all columns required for a SQL reside in one index, then a Fast Full Scan may be used instead of a Full Table Scan to avoid a table access.
NO_INDEX(tab [ ind ...])	Forces Oracle to ignore indexes	Used with just the table name (or alias), Oracle will ignore all indexes on that table. This is equivalent to a FULL hint unless the table is clustered. If index names are specified, they will not be used. If Oracle has two indexes to choose from, this could be used to disable an index, instead of using the INDEX hint to force the use of the other index.
AND_EQUAL(tab ind ind [ ind...])	Forces Oracle to scan all nominated single column indexes used in AND col = ... predicates	Don't use this. You will probably never come across a good implementation of this technique. See the AND-EQUAL trap.
USE_CONCAT	Expand OR predicates or IN lists into UNIONs	Each predicate in the list of ORs can individually use and index, and collectively the ORs return less than 4% of the table. Also useful in a join query where each of the OR predicates is indexed and on a different table.
NO_EXPAND	Stops Oracle from expanding ORs and IN lists into UNIONs. See USE_CONCAT.	If in Explain Plan you see that Oracle is expanding ORs or IN lists into UNIONs, and you think a full table scan would be faster because the UNIONs collectively return more than 4% of the table, then use this hint to check it out.
REWRITE([view ...])	Forces Oracle to resolve the query using a meterialized view instead of the tables in the FROM clause.	Use when the materialized view resolves the same joins or aggregates as are used in the query.
NO_REWRITE	Forces Oracle to stop using query rewrite.	Use when the session or database parameter QUERY_REWRITE_ENABLED is set to true, but you want to avoid using the materiazed view because it may be out of date.
Hints for Join Orders
ORDERED	Join the tables in the FROM clause in the order they are specified	Use if Oracle is joining table in the wrong order. Can also be used to encourage Oracle to use a non-correlated WHERE col IN sub-query as the driving table in a SELECT and then join back to the outer table. If you just want to suggest the best table to lead the join, try the LEADING hint instead.
STAR	Forces Oracle to use a star query plan.	Avoid using this. Star queries are deprecated in favour of STAR_TRANSFORMATION which uses bitmap indexes in favour of cartesian joins. See Star Query.
Hints for Join Operations
USE_NL(tab [tab..])	Use a Nested Loops join	Use when Oracle is using a Hash or Sort Merge join (high volume SQLs), and you want it to use a Nested Loops join (low volume SQLs). Older versions of Oracle required this hint to be used in conjunction with the ORDERED hint. This is still advisable to avoid unexpected results.
USE_MERGE(tab [tab..])	Use a Sort-Merge join on tab	Use when Oracle is using a Nested Loops join, and you have a high volume join using range predicates. Older versions of Oracle required this hint to be used in conjunction with the ORDERED hint. This is still advisable to avoid unexpected results.
USE_HASH(tab [tab..])	Use a Hash join on tab	Use when Oracle is using a Nested Loops or Merge join, and you have a high volume join using equals predicates. Older versions of Oracle required this hint to be used in conjunction with the ORDERED hint. This is still advisable to avoid unexpected results.
DRIVING_SITE(tab)	Forces Oracle to evaluate a join involving a remote table on the remote table's database.	Firstly, try not to join to remote tables. If you must, use this hint when you are joining a local table to a remote table, and the local table is smaller. See Remote Table.
LEADING(tab)	Forces tab to be the leading table in a join	Use instead of the ORDERED hint if you only want to suggest the best starting table. Oracle can have trouble choosing a leading table if there a two of more in the SQL with non-indexed WHERE clauses.
HASH_AJ	Use a Hash Anti-Join to evaluate a NOT IN sun-query.	Use this when your high volume NOT IN sub-query is using a FILTER or NESTED LOOPS join. See High Volumne Nested Loops Joins. Check Explain Plan to ensure that it shows HASH JOIN (ANTI). Try MERGE_AJ if HASH_AJ refuses to work. The HASH_AJ hint is sepcified from within the sub-query, not in the main SQL statement.
MERGE_AJ	Use a Merge Anti-Join to evaluate a NOT IN sun-query.	Use this when HASH_AJ does not work. MERGE_AJ will probably not work either, but it's worth a try.
HASH_SJ	Use a Hash Semi-Join to evaluate a correlated EXISTS sub-query.	Use this when you have a high volume outer query, and a correlated single table sub-query with equals joins back to the outer query, and no DISTINCT / GROUP BY clause. Check Explain Plan to ensure that it shows HASH JOIN (SEMI). Try MERGE_SJ if HASH_SJ refuses to work. The HASH_SJ hint is sepcified from within the sub-query, not in the main SQL statement.
MERGE_SJ	Use a Merge Semi-Join to evaluate a correlated EXISTS sub-query.	Use this when HASH_SJ does not work. MERGE_SJ will probably not work either, but it's worth a try.
Hints for Parallel Execution
Parallel Query hints have been deliberately omitted because they are a lazy way to tune and wreak havoc for DBAs if over-used. Speak to your DBA about using parallel query.
Additional Hints
APPEND	Direct Path Insert	Use Direct Path data load to append inserted rows to the end of the table, rather than searching for free space in previously used data blocks.
CACHE	Cache blocks from Full Table Scan	Usually Full Table Scans will not bump other blocks out of cache, the theory being that they probably won't be used again. Use this hint if you are going to perform another Full Table Scan on the same table straight away.
NO_CACHE	Do not cache blocks from a Full Table Scan	This is the default behaviour, so you should never need it. Perhaps if the CACHE hint were hard coded into a view, the NO_CACHE hint on a select from the view would override it. Just guessing.
MERGE	Enables Complex View Merging	Use when you join to a view that contains a GROUP BY or DISTINCT. See Selecting from Views
NO_MERGE	Disable Complex View Merging	Complex View Merging is a good thing. Don't use this hint unless you are curious to see how much faster complex view merging can be.
UNNEST	A global panacea for badly written sub-queries. Can be used in place of Anti-joins and Semi-joins if you are not really sure what you're doing.	If you can't get your sub-query to stop using a FILTER step, try UNNEST. It uses internal cleverness to rewrite your query.
NO_UNNEST	Forces Oracle not to Unnest sub-queries.	If UNEST_SUBQUERY initialisation parameter is set, Oracle will automatically try to unnest sub-queries. Use this hint to stop it from doing that for a particular sub-query.
PUSH_PRED(view)	Push a join predicate between a view (or inline view) and a table into the view.	Use with a Nested Loop join to a view when the view is the outer (2nd) table in the join. The join condition will be pushed into the view, potentially enabling an index use. See Selecting from Views.
NO_PUSH_PRED(view)	Stop Oracle from pushing join predicates.	Pushing Join Predicates is a good thing - don't use this hint.
PUSH_SUBQ	Force Oracle to evaluate sub-query before other non-indexed predicates.	Use this if you have lots of non-indexed predicates, most of which almost always come out true, and a non-merged sub-query that reduces the number of rows significantly. The performance benefit will only be noticeable over larger data volumes. Over those volumes you will probably be better off merging the sub-query (see the UNNEST hint).
STAR_TRANSFORMATION	Use bitmap indexes for a Star Transformation execution path.	Use this when joining a fact table with bitmap indexes to dimension tables keyed by those bitmap indexed columns. See Star Query.
ORDERED_PREDICATES	Execute the non-indexed non-join predicates in the order in which they are supplied.	If one predicate eliminates a row for a query, Oracle does not evaluate the others. If you order your predicates with the ones most likely to fail first, then this hint can reduce the total number of predicates evaluated. Also see PUSH_SUBQ.

Oracle Veritabanı: Trcsess Aracı - Trcsess Tool

Trcsess aracı ile trace dosyaları belirli kriterlere göre birleştirilir. Trace dosyaları olarak belirttiğimiz dosyalar, session üzerindeki aktiviteyi gözlemleyip loglarını tutan dosyalardır. Bu trace'lerdeki bilgiler performans sorunlarını gözlemlememiz için ve bunların çözümünü bulmamız için büyük bir önem taşımaktadır. Ancak bu trace dosyaları session'ların farklı farklı zamanlarını tuttukları için bize veritabanının genel resmini göstermezler.

Trcsess tool'u ile veritabanındaki aktiviteleri daha kompakt ve birleşik şekilde görebiliriz. Bu birleştirme işini de belirli kriterlere göre hallederiz. Bu kriterler:

-Session_id (Session_id nasıl bulunur?)
-Client_id
-Service
-Action
-Module

Genel Syntax:

 trcsess [output=output_file_name]  
 [session=session_Id]  
 [clientid=client_Id]  
 [service=service_name]  
 [action=action_name]  
 [module=module_name]  
 [trace_files]  

Output: Bizim çıktımız olacak.
Session: İlgili session ile bilgileri toparlar.
Clientid: İlgili client ile trace bilgileri sıralar.
Service: İlgili servis bilgilerini ayırır.
Action: İlgil aksiyonları gruplar.
Module: Modülleri gruplar.
Trace_files: Bununla da gerekli trace dosyaları listelenir.

Trcsess Örneği:

İlk olarak trace dosyalarını birleştiririz.

 trcsess output=abc.trc service=XXX *.trc  

Service ismi olarak XXX kullanılan bütün trace dosyaları toplanılıp tek bir "abc.trc" adlı dosyasına konur.

Bu birleştirme işlemi ertesinde tkprof komutumuz ile bu dosyadan okunabilir tek bir dosya oluşturabiliriz.

 tkprof abc.trc abcd.trc  

Burada dikkat edilmesi gereken konu eğer bu işlemlerin öncesinde trace enabled edilmediyse pek bir bilgi bulunamayacağıdır.

Trace Session Bazında Nasıl Açılır?

 alter session set enable_trace=true;  

Session'ın Yazdığı Trace Dosyası Nasıl Bulunur? 

 select tracefile from v$session join v$process on (addr=paddr) and sys_context('userenv','sessionid')=audsid ;