Mustafa Bektaş Tepe

Oracle veritabanı ilk piyasaya sürüldüğü yıllarda, bir SQL cümlesinin nasıl çalıştırılacağına RBO (Rule Based Optimizer) isimli bir optimizer karar veriyordu. Bu kurallara sıra atanıyor ve sıra değeri en yüksek olan kural işletiliyordu.

Rule Based Optimizer(RBO) : Adı üstünde “execution plan” çıkarırken belli bir sırada tanımlı kural tablosundan faydalanır.Bu kural tablosu aşağıdaki şekildedir :

1. Single Row by Rowid
2. Single Row by Cluster Join
3. Single Row by Hash Cluster Key with Unique or Primary Key
4. Single Row by Unique or Primary Key
5. Clustered Join
6. Hash Cluster Key
7. Indexed Cluster Key
8. Composite Index
9. Single-Column Indexes
10. Bounded Range Search on Indexed Columns
11. Unbounded Range Search on Indexed Columns
12. Sort Merge Join
13. MAX or MIN of Indexed Column
14. ORDER BY on Indexed Column
15. Full Table Scan

Daha sonra Oracle 7 ile birlikte CBO (Cost Based Optimizer) isimli daha kompleks bir optimizer oluşturuldu. Bu optimizer partitioning, paralel çalışma ve en önemlisi de verinin segmentler üzerinde nasıl dağıldığını da hesaba katacak şekilde geliştirildi.

CBO, mümkün olan tüm planları inceleyerek, COST değeri en düşük olan execution planı seçer. Buradaki COST’dan kastımız ise, verilen planın ne kadar kaynak kullanılacağının bir tahminidir. Bu tahminin gerçeğe yakın olabilmesi ve dolayısı ile COST’un yaklaşık olarak hesaplanabilmesi için CBO’nun tablo, index vb. segmentler hakkında ve bu segmentler üzerindeki veri dağılımlarının, density(yoğunluk), selectivity vb. bilgilerinden haberdar olması gerekmektedir. İşte bu bilgilere “OPTIMIZER STATISTICS”, veritabanı istatistiği denir.

NOT : Density değeri 0 ve 1 arasında bir decimal değerdir. 1’e yakın değerler kolonun unselective, 0’a yakın değerler ise selective (seçici) olduğunu gösterir. Density değerinin oluşabilmesi için tablo üzerinde gather statistics işlemi çalıştırılmalıdır. Density hesaplamak için “DENSITY = 1 / (NULL olmayan distinct değer sayısı)” örneğin “DENSITY = 1 / 2000 = 0,0005 ” dir.

İstatistik bilgileri USER_TAB_STATISTICS, USER_TAB_COL_STATISTICS… gibi data dictionary tabloları içerisinde saklanır.

Aşağıdaki sorguyu inceleyelim;

SELECT count(*) FROM deneme WHERE salary=3000;
40960

Sorgunun döneceği kayıt sayısı 40960, fakat sorgu çalıştırılmadan önce bunu CBO’nun bir şekilde hesaplıyor olması gerekir, nasıl hesapladığını inceleyelim:

SELECT NUM_ROWS FROM DBA_TAB_STATISTICS WHERE OWNER='HR' AND TABLE_NAME='DENEME';
2191360

SELECT NUM_DISTINCT FROM DBA_TAB_COL_STATISTICS WHERE OWNER='HR' AND TABLE_NAME='DENEME' AND COLUMN_NAME='SALARY';
58
2191360/58=37782,069

İstatistiklere baktığımız zaman, çok yaklaşık bir değer bulduğumuzu görüyoruz. Bunun bir sebebi de istatistiklerin güncel olmasıdır.

Bu hesaplama metodu, veriler tablo üzerine düzgün-uniform dağılımlar gösterdiğinde gayet başarılı sonuçlar verir, fakat verinin düzgün olmayan-non-uniform dağılımı varsa yani veri SKEWED (verilerin satırlar arasında eşit dağıtılmadığı durumlar) bir yapıda ise CBO yanılabilir.

HISTOGRAM : Verinin uniform(düzgün) olmayan dağılımlarnda, o kolon için HISTOGRAM tanımı yapılır. HISTOGRAM varlığı yukarıdaki CARDINALITY hesabını değiştirir ve daha isabetli tahminler yürütülmesini sağlar.  Oracle bir kolonun HISTOGRAMA ihtiyacı olup olmadığını SYS.COL_USAGE$ tablosuna bakarak anlar. Histogram konusu başka bir yazıda detaylı olarak anlatılacaktır.

İstatistik stratejimiz ne olmalı? İşte bazı öneriler

Automatic Optimizer Statistics Collection : 10g’den itibaren, veritabanı günlük olarak istatistikleri otomatik olarak toplar. Varsayılan istatistik işi yıllar boyunca çok fazla eleştiriye uğradı, ancak bunun değeri yönettiğiniz sistemlerin türüne bağlı. Bu eleştirinin çoğu, büyük veri ambarları gibi son vakaları tartışan insanlardan geldi. Görece mütevazi performans gereksinimlerine sahip birçok küçük veritabanını yönetiyorsanız, Oracle’ın istatistiklerin söz konusu olduğu durumlarda kendi işini yapmasına izin verebilirsiniz. Herhangi bir özel probleminiz varsa, bunlarla durum bazında ilgileniniz.

Karışık Yaklaşım (Mixed Approach) : İstatistik koleksiyonunun çoğunluğu için otomatik job’a güveniyorsunuz, ancak çok spesifik istatistik gereksinimlerine sahip belirli tablolarınız veya şemalarınız var. Bu durumlarda, söz konusu objelerin tercihlerini ayarlayabilir veya job’un bunları değiştirmesini önlemek için belirli tabloların / şemaların istatistiklerini kilitleyebilir, ardından bu tablolar / şemalar için özel bir çözüm tasarlayabilirsiniz.

Manual: Otomatik istatistik koleksiyonunu tamamen devre dışı bırakır ve veritabanının tamamı için özel bir çözüm tasarlarsınız.

Bu yaklaşımlardan hangisine, duruma göre karar vermelisiniz. Hangi rotayı kullanıyorsanız kullanın, istatistiklerinizi yönetmek için DBMS_STATS paketini kullanıyor olacaksınız.

İstatistik toplama

DBMS_STATS paketi, 8i ile birlikte aramıza katılan ve Oracle veritabanının kurulumu ile gelen bir “built-in” pakettir. Oracle DBMS_STATS, parallel çalıştırma, uzun süreli istatistik depolama ve sunucular arasında istatistik aktarımı dahil olmak üzere kullanmanın çeşitli faydalarını listeler. Bu paketin amacı Cost Based Optimizer (CBO) için gerekli istatistikleri, objeler üzerinde toplamaktır. DBMS_STATS paketini ya da ANALYZE ifadesini kullanarak istatistikleri toplamanız mümkündür ancak Oracle 9i ile birlikte DBMS_STATS paketinin kullanılması tavsiye edilmektedir.

DBMS_STATS paketini kullanarak bir tablonun, indeksin veya cluster’ın fiziksel depolama karakteristikleri ile ilgili istatistikleri toplayabilirsiniz. Bu istatistikleri data dictionary olarak adlandırdığımız alanda tutulmaktadır ve gerektiği taktirde CBO tarafından direkt olarak kullanılmaktadır ve CBO bu istatistikleri göre bir SQL planı çıkartmaktadır. Bu bağlamda objelerin üzerindeki istatistikleri güncel olması kimi zaman ciddi önem taşımaktadır (performans açısından).

İstatistikleri data dictionary dışında da tutulabilmektedir ve optimizer’ı etkilemeden manipüle edilebilmektedir. Toplanan istatistikleri başka bir veritabanına da kopyalayabilir, taşıyabilirsiniz. Birkaç DBMS_STATS paketi objesi örneği vermem gerekirse;

• GATHER_DATABASE_STATS
• GATHER_DICTIONARY_STATS
• GATHER_FIXED_OBJECTS_STATS
• GATHER_INDEX_STATS
• GATHER_SCHEMA_STATS
• GATHER_SYSTEM_STATS
• GATHER_TABLE_STATS

DBMS_STATS paketi yalnızca optimizer istatistikleri ile ilgili işlemlere izin vermektedir. Oracle’ın GATHER_STATS_JOB isminde bir otomatik istatistik toplayan görevi bulunmaktadır ve hafta içi 22:00’den sonra ve hafta sonu sabah saatlerinde otomatik olarak devreye girerek, veritabanı istatistiklerini toplamaktadır. DBMS_STATS paketiyle toplamak istediğiniz diğer obje istatistikleriyle ilgilenebilirsiniz.

Tablo İstatistiği – GATHER_TABLE_STATS

DBMS_STATS.GATHER_TABLE_STATS ( 
	ownname VARCHAR2, 
	tabname VARCHAR2, 
	partname VARCHAR2 DEFAULT NULL, 
	estimate_percent NUMBER DEFAULT to_estimate_percent_type (get_param('ESTIMATE_PERCENT')), 
	block_sample BOOLEAN DEFAULT FALSE, 
	method_opt VARCHAR2 DEFAULT get_param('METHOD_OPT'), 
	degree NUMBER DEFAULT to_degree_type(get_param('DEGREE')), 
	granularity VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'), 
	cascade BOOLEAN DEFAULT to_cascade_type(get_param('CASCADE')), 
	stattab VARCHAR2 DEFAULT NULL, 
	statid VARCHAR2 DEFAULT NULL, 
	statown VARCHAR2 DEFAULT NULL, 
	no_invalidate BOOLEAN DEFAULT to_no_invalidate_type ( get_param('NO_INVALIDATE')), 
	force BOOLEAN DEFAULT FALSE);

Örnek Tablo İstatitiği :

BEGIN
   DBMS_STATS.GATHER_TABLE_STATS (ownname            => 'HR',
                                  tabname            => 'EMPLOYEES',
                                  estimate_percent   => 100,
                                  CASCADE            => TRUE);
END;
/

Şema İstatitiği – GATHER_SCHEMA_STATS

DBMS_STATS.GATHER_SCHEMA_STATS ( 
   ownname          VARCHAR2, 
   estimate_percent NUMBER   DEFAULT to_estimate_percent_type 
                                                (get_param('ESTIMATE_PERCENT')), 
   block_sample     BOOLEAN  DEFAULT FALSE, 
   method_opt       VARCHAR2 DEFAULT get_param('METHOD_OPT'),
   degree           NUMBER   DEFAULT to_degree_type(get_param('DEGREE')), 
   granularity      VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'), 
   cascade          BOOLEAN  DEFAULT to_cascade_type(get_param('CASCADE')), 
   stattab          VARCHAR2 DEFAULT NULL, 
   statid           VARCHAR2 DEFAULT NULL, 
   options          VARCHAR2 DEFAULT 'GATHER', 
   objlist          OUT      ObjectTab,
   statown          VARCHAR2 DEFAULT NULL, 
   no_invalidate    BOOLEAN  DEFAULT to_no_invalidate_type (
                                     get_param('NO_INVALIDATE')),
  force             BOOLEAN DEFAULT FALSE,
  obj_filter_list  ObjectTab DEFAULT NULL);

Örnek Şema İstatistiği :

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'HR', estimate_percent => 15, cascade => TRUE);

Veritabanı İstatistiği GATHER_DATABASE_STATS

Bu procedure, veritabanındaki tüm objelerin istatistiklerini toplar.

DBMS_STATS.GATHER_DATABASE_STATS (
   estimate_percent NUMBER   DEFAULT to_estimate_percent_type 
                                                (get_param('ESTIMATE_PERCENT')),
   block_sample     BOOLEAN  DEFAULT FALSE,
   method_opt       VARCHAR2 DEFAULT get_param('METHOD_OPT'),
   degree           NUMBER   DEFAULT to_degree_type(get_param('DEGREE')),
   granularity      VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'), 
   cascade          BOOLEAN  DEFAULT to_cascade_type(get_param('CASCADE')),
   stattab          VARCHAR2 DEFAULT NULL, 
   statid           VARCHAR2 DEFAULT NULL,
   options          VARCHAR2 DEFAULT 'GATHER',
   objlist          OUT      ObjectTab,
   statown          VARCHAR2 DEFAULT NULL,
   gather_sys       BOOLEAN  DEFAULT TRUE,
   no_invalidate    BOOLEAN  DEFAULT to_no_invalidate_type (
                                     get_param('NO_INVALIDATE')),
   obj_filter_list ObjectTab DEFAULT NULL);

Örnek Veritabanı İstatistiği :

EXEC DBMS_STATS.gather_database_stats;
EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15);
EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15, cascade => TRUE);

Sistem İstatistiği – GATHER_SYSTEM_STATS

Oracle 9iR1’de sunulan GATHER_SYSTEM_STATS prosedürü, sisteminizin İ/O ve CPU performansına ilişkin istatistikleri toplar. Optimizer’a bu bilgiyi vermek, execution plan seçimini daha doğru bir hale getirir, çünkü sistemin hem CPU hem de I/O profillerini kullanarak işlemlerin göreceli maliyetlerini ölçebilir. İki tür sistem istatistiği vardır:

Noworkload : Tüm veritabanları varsayılan bir noworkload istatistik grubuyla birlikte gelir, ancak daha doğru bilgilerle değiştirilebilirler. Noworkload istatistiklerini toplarken, veritabanı bir dizi rasgele I/O yayınlar ve CPU’nun hızını test eder. Tahmin edebileceğiniz gibi, bu toplama aşamasında sisteminize bir yük koyar.

EXEC DBMS_STATS.gather_system_stats; 

Workload : Start/stop veya aralık parametreleri kullanılarak başlatıldığında, veritabanı tüm sistem işlemlerini takip etmek için sayaçları kullanır ve sistemin performansı hakkında doğru bir fikir verir. Eğer workload istatistikleri mevcutsa, noworkload istatistiklerine göre bunlar kullanılacaktır.

-- Sistem aktivitesinin temsili bir zamanını (birkaç saat) örneklemeye manuel olarak başlayın ve durdurun.

EXEC DBMS_STATS.gather_system_stats('start');

EXEC DBMS_STATS.gather_system_stats('stop');

-- Belirli bir dakikaya göre almak istersek
DBMS_STATS.gather_system_stats('interval', interval => 180);

Mevcut sistem istatistikleriniz AUX_STATS $ tablosu sorgulanarak görüntülenebilir.

SELECT pname, pval1 FROM sys.aux_stats$ WHERE sname = 'SYSSTATS_MAIN'; 

Tüm veritabanı bazında eskimiş istatistikleri görüntüleme

DECLARE
   ObjList   DBMS_STATS.OBJECTTAB;
BEGIN
   DBMS_STATS.
    GATHER_DATABASE_STATS (objlist => ObjList, options => 'LIST STALE');

   FOR i IN ObjList.FIRST .. ObjList.LAST
   LOOP
      DBMS_OUTPUT.
       put_line ( ObjList (i).ownname || '.' || ObjList (i).ObjName || ' --> ' || ObjList (i).ObjType || '' || ObjList (i).partname);
   END LOOP;
END;
/

Belli bir Şema altındaki eskimiş istatistikleri görüntüleme

DECLARE
   ObjList   DBMS_STATS.OBJECTTAB;
BEGIN
   DBMS_STATS.
    GATHER_SCHEMA_STATS (ownname   => HR,
                         objlist   => ObjList,
                         options   => 'LIST STALE');

   FOR i IN ObjList.FIRST .. ObjList.LAST
   LOOP
      DBMS_OUTPUT.
       put_line (
            ObjList (i).ownname || '.' || ObjList (i).ObjName || ' --> ' || ObjList (i).ObjType || '' || ObjList (i).partname);
   END LOOP;
END;
/

Tablo, sütun ve indeks istatistikleri aşağıdaki gibi silinebilir.

EXEC DBMS_STATS.delete_database_stats;
EXEC DBMS_STATS.delete_schema_stats('SCOTT');
EXEC DBMS_STATS.delete_table_stats('SCOTT', 'EMP');
EXEC DBMS_STATS.delete_column_stats('SCOTT', 'EMP', 'EMPNO');
EXEC DBMS_STATS.delete_index_stats('SCOTT', 'EMP_PK');
EXEC DBMS_STATS.delete_dictionary_stats;

NOT 1 : İstatistikleri Lock’lı olan tabloları bulmak:

select owner,table_name, stattype_locked,last_analyzed from dba_tab_statistics where stattype_locked is not null order by 1 ;

Aşağıda ki sorgu ile lock’u kaldırabiliriz.

exec DBMS_STATS.UNLOCK_TABLE_STATS ('HR','Test'); 

NOT 2 : İstatisk bilgilerinin geçmişe dönük  kaç gün sakladığımıza aşağıdaki gibi bakabiliriz.

select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual; 

Bu değeri değiştirmek isterseniz aşağıdaki komutu kullanabilirsiniz;

execute DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (45); 

30 günlük history saklıyoruz ama kullanılabilir history istatistiğimiz olup olmadığını kontrol etmek için  aşağıdaki komutu kullanabiliriz;

select DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY from dual; 

NOT 3 : Oracle 10g’den bu yana, DBMS_STATS prosedürleri için varsayılan parametre değerlerinin birçoğu değişmiştir. Oracle 10g’de, bu tercihler SET_PARAM prosedürü kullanılarak değiştirilebilir.

EXEC DBMS_STATS.set_param('DEGREE', '5'); 

11g’de, SET_PARAM prosedürü, tercihlere yönelik katmanlı bir yaklaşım lehine kaldırılmıştır. Dört tercih seviyesi aşağıdaki prosedürlerle değiştirilir.

• SET_GLOBAL_PREFS: Otomatik istatistik toplama işine özgü de dahil olmak üzere genel tercihleri ayarlamak için kullanılır.
• SET_DATABASE_PREFS: Tüm veritabanı için tercihleri ayarlar.
• SET_SCHEMA_PREFS: Belirli bir şema için tercihleri ayarlar.
• SET_TABLE_PREFS: Belirli bir tablo için tercihleri ayarlar.

EXEC DBMS_STATS.set_global_prefs('AUTOSTATS_TARGET', 'AUTO');
EXEC DBMS_STATS.set_database_prefs('STALE_PERCENT', '15');
EXEC DBMS_STATS.set_schema_prefs('SCOTT','DEGREE', '5');
EXEC DBMS_STATS.set_table_prefs('SCOTT', 'EMP', 'CASCADE', 'FALSE');

Öneriler;

10g’den önce, SYS şeması için istatistik toplamak sistemin daha hızlı çalışmasını yavaşlatabilir.

İstatistik toplama, sunucu için çok yoğun bir kaynak olabilir, bu nedenle yoğun iş yükü sürelerinde istatistik başlatmaktan kaçınmalıyız veya yalnızca eski istatistikleri toplamılıyız..

Zamanlanmış istatisktik toplama job’ımız olsa bile, veritabanı bakımı veya büyük veri yüklemelerinden sonra yeni istatistikler toplamak gerekebilir.

Otomatik İstatistik Toplama

Oracle, tüm veritabanı objelerinin istatistiklerini otomatik olarak toplar ve bu istatistikleri düzenli olarak zamanlanmış bir bakım işinde tutar. Otomatik istatistik toplama, optimizerı yönetmeyle ilişkili manuel görevlerin çoğunu ortadan kaldırır ve eksik veya eski istatistikler nedeniyle kötü execution planları alma şansını önemli ölçüde azaltır.

GATHER_STATS_JOB

Optimizer için gerekli istatiskler otomatik olarak GATHER_STATS_JOB adlı job ile toplanır.  Bu job, veritabanındaki tüm objelerin istatistiklerini toplar:

Bu job, veritabanı oluşturulurken otomatik olarak oluşturulur ve scheduler tarafından yönetilir. Scheduler, maintenance window açıldığında bu jobı çalıştırır. Varsayılan olarak, maintenance window her gece 10: 00’dan başlar 6’ya kadar devam eder.

stop_on_window_close özelliği maintenance window kapandığında GATHER_STATS_JOB’nin devam edip etmeyeceğini kontrol eder.

stop_on_window_close özelliği için varsayılan ayar TRUE’dur, Scheduler da maintenance window kapanması GATHER_STATS_JOB’ın sonlandırmasına neden olur. Kalan objeler daha sonra bir sonraki maintenance window işlenir.

GATHER_STATS_JOB jobu, DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC prosedürünü çağırarak optimizer istatistiklerini toplar. GATHER_DATABASE_STATS_JOB_PROC prosedürü objeler için daha önce toplanmış istatistiklere sahip olmadığında veya varolan istatistikler eski olduğunda, yada obje önemli ölçüde değiştirildiğinden (satırların% 10’undan fazlası) eskimiş olduğundan, veritabanı objeleri üzerinde istatistikler toplar. DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC internal bir procedure dür, ancak GATHER_AUTO seçeneğini kullanarak DBMS_STATS.GATHER_DATABASE_STATS prosedürüne çok benzer şekilde çalışır. Birincil fark, DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC prosedürünün, istatistik gerektiren veritabanı nesnelerine öncelik vermesidir, böylece en çok güncellenen istatistiklere ihtiyaç duyan objeler önce işlenir. Bu, en çok ihtiyaç duyulan istatistiklerin maintenance window kapanmadan önce toplanmasını sağlar.

Otomatik İstatistik Toplamayı Etkinleştirme : Otomatik istatistik toplama, bir veritabanı oluşturulduğunda veya daha önceki bir veritabanı sürümünden bir veritabanı yükseltildiğinde varsayılan olarak etkindir. İşin var olduğunu DBA_SCHEDULER_JOBS görünümünü görüntüleyerek doğrulayabilirsiniz:

SELECT * FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'GATHER_STATS_JOB'; 

Otomatik istatistik toplamayı devre dışı bırakmak istediğiniz durumlarda, en doğrudan yaklaşım GATHER_STATS_JOB’ı aşağıdaki gibi devre dışı bırakmaktır:

BEGIN
  DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
/

Otomatik istatistik toplama, “Eski İstatistikleri Belirleme” bölümünde açıklanan değişiklik izleme özelliğine dayanır. Bu özellik devre dışı bırakılırsa, otomatik istatistik toplama işi eski istatistikleri algılayamaz. Bu özellik STATISTICS_LEVEL parametresi TYPICAL veya ALL olarak ayarlandığında etkindir. TYPICAL, varsayılan değerdir.

Maintenance Window

Oracle Veri Tabanı bazı rutin veri tabanı bakım görevlerini yerine getirecek şekilde yapılandırılmıştır, böylece sistem yükünün hafif olması beklenen zamanlarda bunları çalıştırabilirsiniz. Böyle bir süre için bu bakım görevlerinin kaynak tüketimini kontrol eden bir kaynak planı belirleyebilirsiniz.

Oracle Veritabanı kurulumunda iki Zamanlayıcı önceden tanımlanmıştır:

• WEEKNIGHT_WINDOW : Hafta içi 10: 00’da başloyor sabah 6’da bitiyor.
• WEEKEND_WINDOW : Cumartesi ve Pazar günlerini kapsar.

Bu işler birlikte, tüm sistem bakım görevlerinin zamanlandığı MAINTENANCE_WINDOW_GROUP’ı oluşturur. Oracle Database, otomatik istatistik toplama, alan yönetimi ve diğer bazı dahili sistem bakım işleri için bakımın gerçekleştirileceği saat aralığını kullanır.

DBMS_SCHEDULER.SET_ATTRIBUTE prosedürünü kullanarak önceden tanımlanmış bakımın gerçekleştirileceği saat aralığını veritabanı ortamınıza uygun bir zamana ayarlayabilirsiniz. Örneğin, aşağıdaki komut dosyası WEEKNIGHT_WINDOW’yu hafta içi her sabah saat 08: 00’ye taşır:

EXECUTE DBMS_SCHEDULER.SET_ATTRIBUTE(
   'WEEKNIGHT_WINDOW', 
   'repeat_interval',
   'freq=daily;byday=MON, TUE, WED, THU, FRI;byhour=0;byminute=0;bysecond=0');

Bakımın gerçekleştirileceği saat aralığının süresinin zaten sekiz saat olduğunu, bu nedenle komut dosyasının değiştirilmesine gerek olmadığını unutmayın.

SET_ATTRIBUTE prosedürünü bir pencerenin diğer özelliklerini ayarlamak için de kullanabilirsiniz. Örneğin, aşağıdaki komut dosyası WEEKNIGHT_WINDOW için DEFAULT_MAINTENANCE_PLAN kaynak planını ayarlar:

EXECUTE DBMS_SCHEDULER.SET_ATTRIBUTE (
   'WEEKNIGHT_WINDOW',
   'resource_plan',
   'DEFAULT_MAINTENANCE_PLAN');

Aşağıdaki view lerden yararlanabiliriz.

• DBA_AUTOTASK_CLIENT_JOB
• DBA_AUTOTASK_CLIENT
• DBA_AUTOTASK_JOB_HISTORY
• DBA_AUTOTASK_WINDOW_CLIENTS
• DBA_AUTOTASK_CLIENT_HISTORY

VALIDATE STRUCTURE

Bir tablonun, indeksin, clusterın veya materialized view’ın yapısının bütünlüğünü doğrulamak için, ANALYZE ifadesini VALIDATE STRUCTURE seçeneğiyle kullanın. Yapı geçerliyse, hata döndürülmez. Ancak, yapı bozuksa, bir hata mesajı alırsınız.

Örneğin, donanım veya diğer sistem arızaları gibi nadir durumlarda, bir index bozulabilir ve doğru şekilde çalışmayabilir. İndexi doğrularken, dizindeki her girişin ilişkili tablonun doğru satırına işaret ettiğini doğrulayabilirsiniz. İndex bozuksa, bırakıp yeniden oluşturabilirsiniz.

Aşağıdaki ifade emp tablosunu analiz eder:

ANALYZE TABLE emp VALIDATE STRUCTURE; 

CASCADE seçeneğini ekleyerek bir objeyi ve tüm bağımlı objeleri (örneğin, dizinleri) doğrulayabilirsiniz. Aşağıdaki ifade emp tablosunu ve ilişkili tüm dizinleri doğrular:

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE; 

Varsayılan olarak CASCADE seçeneği tam bir doğrulama yapar. Bu işlem kaynak yoğun olabileceğinden, FAST yan tümcesini kullanarak doğrulamanın daha hızlı bir sürümünü gerçekleştirebilirsiniz. Bu sürüm, optimize edilmiş bir kontrol algoritması kullanarak corruptions varlığını kontrol eder, ancak corruption hakkındaki ayrıntıları bildirmez. FAST kontrol bir bozulma bulursa, FAST yan tümcesi olmadan CASCADE seçeneğini kullanabilirsiniz. Aşağıdaki ifade emp tablosunda ve ilişkili tüm dizinlerde hızlı bir doğrulama gerçekleştirir:

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE FAST; 

Doğrulama yapılan objeye karşı DML gerçekleşirken, ONLINE olarak yapı doğrulaması yapmak istediğinizi belirleyebilirsiniz. Hedefi etkileyen devam eden DML ile doğrulanırken küçük bir performans etkisi olabilir, ancak bu, çevrimiçi ANALYZE gerçekleştirebilme esnekliği ile dengelenir. Aşağıdaki ifade emp tablosunu ve ilişkili tüm dizinleri çevrimiçi olarak doğrular:

ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE ONLINE;

https://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_stats.htm#i1044360
https://oracle-base.com/articles/misc/cost-based-optimizer-and-database-statistics
http://www.oganozdogan.com/2011/05/dbmsstats-paketi-nedir-ve-kullanm.html
https://hakkioktay.wordpress.com/2007/03/15/optimizer-execution-plan-kavramlari-ve-optimizer-cesitleri/
https://docs.oracle.com/cd/B28359_01/server.111/b28310/general002.htm#ADMIN11526

Mustafa Bektaş Tepe
İyi Çalışmalar