Yasin DEMİR

Oracle’ın üzerine kuruldugu yapı “Fiziksel Yapı” ve “Mantıksal Yapı” olmak üzere 2 çeşittir.
Fiziksel yapıyı oluşturan bileşenler de şu şekilde özetlenebilir :

1. Datafiles
2. Control Files
3. Redo Log Files
4. Archive Log Files
5. Parameter Files
6. Alert ve Trace Log Files
7. Backup Files

Şimdi bunlara kısaca göz atalım.

Datafiles : Her Oracle Veritabanı bir ya da daha fazla sayıda datafile içerebilir. Tablo, indeks gibi matıksal yapıların barındırdığı fiziksel bilgileri tutar.Belli başlı özellikleri:

• Bir datafile sadece bir veritabanı ile ilişkilidir.
• Bir ya da daha fazla datafile mantıksal yapılardan olan tablesace’leri oluştururlar.
• Gerektiğinde kendilerini otomatik olarak büyütme(extend) özellikleri vardır.

Örneğin bir tablodan veri okunmak istediğinde bu hafızada(memory) yoksa ilgili datafile’dan okunarak hafızaya çekilir ve okunur.Datalar üzerinde değişiklik yapıldığında ise hemen datafile’a bu değişikşik yansıtılmaz.I/O miktarını düşük tutmak amacıyla bu işlem “Database Writer Process(DBWn)” adı verilen bir arkaplan işlemi (background process) tarafından karar verilen anlarda yapılır.

Control Files : Her Oracle veritabanının bir “control file”’ ı vardır.Veritabanının fiziksel yapısı hakkındaki (database adı, datafile ve redo log file’ların adı ve yerlerinin bilgisi vb…) bilgileri tutar.
Bu dosyadaki bilgiler çok önemli olduğu için Oracle bu dosyayı çoğullama özelliğine sahiptir.Eş zamanlı olarak dosyaları güncel tutar.
Her Oracle instance başladığında bu dosyadan bilgiler okunur.Yeni datafile ya da redo log dosyası database’de tanımlandığı anda Oracle control file’ı günceller.(Ayrıca bu dosya kurtarma(recovory) durumunda da kulanılır.)

Redo Log Files : Veriye yapılan tüm değişiklik işlemlerini tutmakla yükümlüdür.Datafile’lara (bir şekilde) değişen bilgi yazılamadığı durumlarda redo loglardan bu işlemler görülebilir ve yapılan işlemin kaybı önlenir.
Bu dosyalarında çoğullanma imkanı vardır.Farklı diskler üzerinde 2 ya da daha fazla kopyası tutulabilir.
Bu dosyanın amacı özetle sistem ya da donanım kaynaklı(harddisk göçmesi vs.) olası hatalarda datafile’lara kalıcı şekilde yazılamayan bilgileri kurtarmaktır.Örneğin bir elektrik kesintisinde henuz datafile’lara yazılmayan ve memory de bulunan bilgiler kaybedilir.Sistem tekrar ayağa kalktığında Oracle ilk önce redo log lara bakar.Kalıcı olarak datafile’a yazılamayan bilgi olduğunu görür ve yarım kalan işlemi sonlandırır.Bu sayede veritabanı elektrik kesintisi olmadan evvelki konuma gelinmiş olur.

Archive Log Files : Oracle veritabanı ARCHIVELOG modunda ise redo log dosyaları bu dosyalara otomatik olarak arşivlenir.

Parameter Files (PFILEs): Veritabanı ve çalışan instance ile ilgili konfirigasyon parametrelerini içerir.”init.ora” bir parameter file’dır. init.ora server tarafta bulunur.Ancak client’tan (uzak erişim) ile veritabanın ulaşmak için gereklidir, static’tir.Gerektiğinde (text dosya olduğundan) elle de değişiklik yapılabilir.

9i sürümüyle birlikte “Server Parameter File(SPFILE)” kavramı geldi.SPFILE PFILEs’dan oluşturulabilir.Bu PFILE gibi bir text dosya değil binary bir dosyadır ve sadece “ALTER SYSTEM SET” komutu ile değişir.Lokal makinadan veritabanını başlatmak için bir kopyasını lokalde tutmaya gerek kalmamaktadır.

SPFILES kullanmak PFILE kullanmaktan daha avantajlıdır.Çünkü :
• RMAN ile backup’ı alınabilir.(RMAN, PFILE backup’ı alamaz)
• Server tarafında tutulduğundan ve değişiklik yapılıpta olur verilmeden evvel sistem tarafından kontrol edildiğinden insan kaynaklı hataların önüne geçilmiş olur.
• Uzaktan veritabanını başlatmak için lokal makina da bir dosya tutulmasına gerek kalmaz.

Oracle veritabanı PFILE’dan ya da SPFILE’dan başlatılmış olabilir.bunu anlamak için aşağıdaki sorgu kullanılabilir :

SELECT DECODE(value, NULL, ‘PFILE’, ‘SPFILE’) “Init File Type”
FROM sys.v_$parameter WHERE name = ’spfile’;
PFILE’dan SPFILE ya da SPFILE’dan PFILE oluşturmak mümkündür :

• CREATE PFILE FROM SPFILE;
• CREATE SPFILE FROM PFILE;
• CREATE SPFILE=’/oradata/spfileORCL.ora’ from PFILE=’/oradata/initORCL.ora’;

Alert ve Trace Log Files : Her bir server ya da arka planda çalışan işlemlerin kendileri ile ilişkili bir “trace” dosyası vardır.Örneğin herhangibir hata (internal error) durumunda ilgili trace dosyasına ilgili bilgiler yazılır.Bunun dışında instance ve uygulamaları iyileştirmek için de referans olarak kullanılırlar.
Alert dosyaları(log) ise özel trace dosyalarıdır.Veritabanın mesaj ve hatalarını kronolojik sırada tutarlar.

Backup Files : Bir dosyayı kurtarmak (restore) demek onu backup dosyası ile değiştirmek demektir.Kullanıcı istediği anda ya da sistemde belirtilen anlarda bu dosyaları oluşturabilir.

Bir evvelki yazımda Oracle veritabanının fiziksel yapısından bahsetmiştik.Şimdide mantıksal kısımdan “kısaca” bahsedeceğiz.
Mantıksal kısım başlıca 4 e ayrılır :

1. Tablespaces
2. Data Blocks
3. Extents
4. Segments

Tablespaces : Her bir veritabanı bir ya da daha fazla tablespace’den oluşur.Buradaki verileri tutmak içinde her bir tablespace için bir ya da daha fazla datafile oluşturulur.
Her Oracle veritabanında kullanıcın isteği dışında kurulumu esnasında SYSTEM ve SYSAUX adlarında 2 adet tablespace oluşturulur.Bunlar aslında “smallfile tablespace” olarak adlandırılan küçük ölçekli alanlardır.

Bunun dışında uygulamaya göre daha büyük ölçekli “bigfile tablespace”’ler oluştutulabilir.Bu durumda özelikle 64bit sistemlerde çok büyük alanlar oluşturulmasına imkan vermektedir.(Maksimum 8 exabyte).Bu da onlarca küçük alan ile ugrasmaktan kullanıcıyı kurtarır.

NOT:
kilobyte(kB) 210 bytes, gigabyte(GB) 230 bytes, exabyte (EB) 260 bytes

Bir tablespace “online=ulaşılabilir” ya da ”offline=ulaşılamaz” olabilir.”online” normal çalışır halidir.”offline” duruma alınınca(mesela offline backup almak için) bu tablespace’i referans veren objlere için işlem yapılmasına izin verilmez.

Data Blocks : Oracle da veriler en düşük seviye de “data block”’larda tutulurlar.Disk üzerinde bir data block byte olarak belli bir alanı işgal eder.Bu alan DB_BLOCK_SIZE parametresi ile belirlenir.

Extents : Ardışık blockların bir araya gelmesi ile oluşurlar.

Segments : Bir ya da daha fazla extent’in bir araya gelmesi ile oluşurlar. Bu extent lerin ardışık olmaları gerekmez.Bir segment’in extent’leri tamamen doldugunda Oracle bu segment için yeni bir extent alanı ayırır.

4 farklı segment çeşidinden bahsedilebilir :

1. Data Segment
2. Index Segment
3. Temporary Segment
4. Rollback Segment

Data Segment, bir tablo oluşturulur oluşturulmaz daha veri girilmeden alanı ayrılan yapıdır.Dolduğunda otomatik olarak extent’ler bu data segment için ayrılır.
Indeks segment , her bir index’in verisi için oluşturulur.Temporary segment bir SQL çalıştığında gerek duyulursa Oracle tarafından kullanılır. İşlem bitiğinde bu alan sistemin kullanımı için serbest bırakılır.Rollback Segment adı üstünde rollback işlemlerinde kullanılır.

Veritabanı üzerinde tasarım yaparken verileri tutmak igin ihtiyaca yvnelik tablo geşidi kullanmalıdır.Oracle ın kullanıcıya sundugu tablo geşitlerinden sık karşımıza gıkabilecek olanları kısaca agıklayalım :

Heap Organized Tables : Create table. Şeklinde standart bir tablo oluşturdugunuzda siz aslında bir Heap Organized Tablo oluşturmuşunuz demektir.Varsayılan tablo türüdür.Veri tabloya girileceğinde ilk bulduğu uygun yere atılır.Veri silindiğinde agılan yere INSERT ya da UPDATE ile yeni veriler gelebilir.

Index Organized Tables : Tablonun indeks mantığına gvre tutulması esasına dayanır.Bu da verilerin kendi igersinde bir sıra ile tutulmasını sağlar.Heap organized tablodan farklı olarak ilk boş uygun yere değil primary key değerine gvre olması gereken sırada ve yerde tabloya atılır.Sorgulama işlemlerinde peformans sağlar.

Partitioned Tables :Tablonun kendi iginde pargalara ayrılmış hali (tablo iginde daha kügük tablolar) olarak düşünülebilir.4 tiptir :Range Partitioning ,List Partitioning ,Hash Partitioning ve Composite Partitioning.Veri hangi pargaya (partiton) girileceği bir “partition key” ile belirlenir.(NOT : Bu konuya ilerki günlerde detay olarak girilecektir.)

Clustered Tables : Aynı data blockları paylaşan ve sık kullanılan tablolar grubundan oluşan bir yapıdır aslında.(Cluster).Tablolar birbirine bir Cluster key ile bağlıdır ve bu anahtar B*Tree mantıgına gvre oluşturulur.

Hash Clustered Tables : B*Tree yerine hash mantığına gvre dataların tutulduğu clustered tablolardır.Veri aslında tutulan indekstir şeklinde bir yaklaşım yapılabilir.Vzellikle, eşitlik sorgulayan işlemlerde uygundur.

Nested Tables : Kabaca bir başka tablo iginde tutulan tablodur şeklinde ifade edilebilir. Aşağıdaki vrnek size bir fikir verecektir.

CREATE OR REPLACE TYPE CourseList AS TABLE OF VARCHAR2(64);

CREATE TABLE department (
name VARCHAR2(20),
director VARCHAR2(20),
office VARCHAR2(20),
courses CourseList)
NESTED TABLE courses STORE AS courses_tab;

INSERT INTO department(name, director, office, courses)
VALUES(′English′, ′Lynn Saunders′, ′Breakstone Hall 205′,
CourseList(
′Expository Writing′,
′Film and Literature′,
′Modern Science Fiction′,
′Discursive Writing′,
′Modern English Grammar′,
′Introduction to Shakespeare′,
′Modern Drama′,
′The Short Story′,
′The American Novel′)
);

“CREATE TABLE”  veritabanı  ile uğraşan herkesin sıklıkla kullandığı bir komuttur.Genellikle

CREATE TABLE owner.T (
ID    NUMBER(30),
STR   VARCHAR2(200),
STR2  VARCHAR2(200)
);

şeklinde kısaca yazar geçeriz.Halbuki bu kısa kodun arkasında pek çok varsayılan parametre set edilmektedir.Bu parametreleri tablo oluşurken ya da oluşturduktan sonra belirlemek mümkün.Oracle’da ”CREATE TABLE” komutu uzun hali ile yazılmak istenirse mesela aşağıdaki gibi olacaktır :

CREATE TABLE owner.T (
ID    NUMBER(30),
STR   VARCHAR2(200 BYTE),
STR2  VARCHAR2(200 BYTE)
)
TABLESPACE theTableSpace
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
LOGGING

Görüldüğü üzere bir dizi parametre var.Şimdi “en sık karşımıza çıkacak olanlara” kısaca değinmeye çalışalım:

TABLESPACE : Tablonun oluşturulacağı “tablespace”’i belirtir.Bir değer girilmezse tablonun bulunduğu şemanın(schema) varsayılan “tablespace”’inde oluşturulur.

PCTFREE : Tablonun her bir “data block”’unda update’ler sonucu oluşan değişiklikler için tutulan alandır.0-99 arası değer alır, varsayılan değeri 10’dur.Yüzde “%” ile ifade edilir.”0” verilirse “data block”’un tamamının “insert”  için kullanılacağı anlamına gelir.Bu alanın değerinin seçimi önemlidir.Sık “update” gören bir tabloda 5-10 gibi küçük değerler verilmesi “update” sonucu oluşan yeni verinin başka “data block”lara taşınmasına sebeb olur.Bu da tabloya ulaşımda, sorgularda performans problemine yol açar.

PCTUSED : 1-99 arası değer alır.Varsayılan değeri 40’tır. Yüzde “%” ile ifade edilir.Bir “data block” belirlenen pctused değerinin altına düşünce “insert” işlemi yapılmaya aday blok anlamına gelir.Mesela bu değerimiz %40 ise “data block”’un kullanılan alan % değeri de %40 ın altına düşerse bu data block insert” için kullanılabilir demektir.
PCTFREE ve PCTUSED parametrelerinin toplamı 100’den az olmalıdır.Tablo oluştururken her ikisi birden kullanılbileceği gibi ayrı ayrı da belirlenebilirler.

INITRANS : 1-255 arası değer alır.Varsayılan değer “1”dir ve bunun dışında belirlenmemesi önerilir.Bir “data block” ta yapılan her update bir “transction entry” gerektir.Bunun değerini belirtir.

MAXTRANS : Varsayılan değer dışında belirlenmemesi önerilir.1-255 arası değer alırlar.10g ile birlikte otomatik olarak ayarlanmaktadır.Oracle gerektiğinde bu değeri kendisi 255e kadar otomatik arttırmaktadır.

LOGGING-NOLOGGING : Tablo oluşturma işleminin loglanıp loglanmaması bilgisidir.Varsaylan “LOGGING”’tir.NOLOGGING yapmak istersek örnek :

create table T nologging as select * from T2;

Tablo oluşturken kullanılan bundan başka parametrelerde vardır(CACHE, COMPRESSED,PARALLEL, ROW MOVEMENT,…).Bunlar hakkında detay bilgiye Oracle dökümanlarından bakılabilir.

Oracle klasik olan ve  verilerin kalıcı olarak tutulduğu tablo tiplerinden farklı olarak, verilerin geçici olarak tutulabildiği tablo desteği de sağlamaktadır.Geçicilikten kasıt bu tabloların transaction ya da session bazlı olarak tutulmasıdır.Yani bu tür tablolardaki veriler ya transaction sonunda “COMMIT” edilene kadar ya da session sonlandırılana kadar tutulur.

Genel olarak incelemek gerekirse aşağıdaki noktalara değinmekte fayda var:

1) Geçici tablolar , geçici segmentleri (temporary segments)  kullanırlar.Normal tablolardan farklı olarak, kendileri (ve oluşturulduysa indeks(ler)i) oluşturuldukları zaman değil INSERT (ya da CREATE TABLE AS SELECT) işleminden sonra veritabanında yer işgal etmeye başlarlar. Transaction bazlı ise transaction sonlandıgında (COMMIT), session bazlı ise session sonlandığında geçici segmentte yazılan bilgiler silinir.

2) Bu tabloları oluşturmak için “CREATE GLOBAL TEMPORARY TABLE” anahtar sözcükleri kullanılır.Temel olarak session bazlıdırlar.Bundan kasıt aynı geçici tabloyu kullanacak olan 2 farklı session diğer session’da kullanılan geçici tablodan bağımsızdır, veri o session’a özgüdür.(Bu sebeble DML lock mekanizmasına ihtiyaç yoktur.)Örneğin bir session’da geçici tabloya yapılan truncate işlemi diğer session’daki geçici tabloyu etkilemez.Diğer session’daki tablo truncate olmaz.Session herhangibir sekilde sonlandıgında geçici tablodaki bilgiler otomatik olarak silinir, kaybedilir.Her session kendi session’ındaki geçici tablo bilgilerini görür.

3) Geçici tablolar üzerinde yapılan herhangibir DML sonrasında veri değişikliği sebebi ile bir “redo log” üretimi olmaz.Bununla birlikte veri için “undo log” ve “undo log”’lar için de bir redo log üretimi olur.(Redo log: commit yapılmadan evvel tüm değişikliklerin tutulduğu yer, Undo : -rollback- ,verinin DML yapılmadan (değiştirilmeden) evvelki hali)

4) Geçici de olsalar bu tablolar üzerinde CREATE INDEX ile indeks oluşturmak mümkündür.Tabi bu indekste tablonun kendisi gibi geçicidir.Oluşturulan indeks bilgisi de session bazlıdır.Diğer session’lar bunu görmez.Hatta bu tablolar ile VIEW lar da oluşturulabilir , üzerlerinde trigger bile yazılabilir.Yine bu tabloların tanımları (verileri değil) EXPORT ve IMPORT yapılabilir.

5) Transaction bazlı geçici tablolar o transaction ya da bu transaction’ın alt transaction’ları tarafından ulaşılabilirdirler.Bununla birlikte aynı session içersindeki transctionlar gecici tabloyu “concurrent” olarak kullanamazlar.Örneğin bir transaction geçici tablota bir INSERT yaptığında bu transaction’ın alt transaction’ları  artık bu geçici tabloyu kullanamazlar.Tersi durumda yani alt transaciton INSERT yaparsa , bu transaciton sonunda veri kaybolur ve ne kendisi ne de ana transaction tabloya ulaşamaz.

Kullanıma örnekler verecek olursak : transaction sürerken ara sonuçları tutabileciğimiz bir tablo olarak kullanılbileceği gibi ,çok fazla “redo” üretileceği ama bunu istemediğimiz durumlarda ya da bir rapor cekileceğinde referans tablo olarak uygun şekilde kullanılabilir.

sentaks

Transaction bazlı geçici tablo oluşturmak için (Her commit’te veriler silinir):
create global temporary table
table_name [ table definition ]
on commit delete rows;

Session bazlı geçici tablo oluşturmak için (veriler session sonuna kadar tutulur.)
create global temporary table
table_name [ table definition ]
on commit preserve rows;

Optimizer ve Execution Plan :
Optimizer, bir SQL çalıştırıldığında veriye ulaşmak için gerekli en etkili yolu bulmaktan sorumludur.
En etkin yoldan kasıt Oracle’ın çıkaracağı ve “execution plan” olarak bilinen “çalış(tır)ma planı”’dır.Bir DML çalıştırıldığında verinin fiziksel olarak veritabanında nerede nasıl tutuldugundan , bunları kullanıcının kullanımına hazır hale getirmeye kadar olan geniş bir yelpazede işlemler ve adımlar gercekleşmektedir.Bunları sağlarken tek bir yöntem değil birden çok yöntem vardır.Toparlamak gerekirse “execution plan” , kullanıcı isteğinin karşılanması için gerekli adımlar toplamıdır.

Oracle hali hazırda 2 farklı optimizer kullanmaktadır :
1) Rule Based Optimizer(RBO)
2) Cost Based Optimizer(CBO)

Oracle, 10g sürümü ile birlikte RBO desteğini kesmiş ve kullanıcılardan CBO’a yönelik uygulama geliştirmesini beklemektedir.Zaten 10g sürümünde sadece CBO modları secilebilmektedir.Hangisi kullanılırsa kullanılsın bir “execution plan” oluşturulmaktadır.Şimdi bu optimizer çeşitlerine daha yakından bakalım.

1) Rule Based Optimizer(RBO) : Adı üstünde “execition 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

Peki bu kural tablosu ve sırası nasıl kullanılıyor?Örneğin :

select * from theTable where id = 12345

şeklinde bir sorgumuz olsun.Ilgili veriyi getirmek için ilk akla gelen yöntemler ya varsa index üzerinden gidilmesi ya da indeks yoksa tüm tablo taranmasıdır.(Full Table Scan(FTS)).Indeks yukarıdaki kural tablosunda FTS’dan önce geldiği için RBO , execution plan’ı “indeks üzerinden gidilecek” şeklinde oluşturur.

İlk bakışta (örnekten hareketle) bu kural tablosu tüm durumlar için en optimum sırayı barındırıyor gibi görünse de bazı durumlarda en etkili yol daha evvel sırada olmadığı için en etkili “execution plan” çıkarılmış olmaz.Bu aşamada bir başka yaklaşıma ihtiyaç duyulmaktadır.Bu da CBO ile sağlanmaktadır.

2) Cost Based Optimizer(CBO) : Oracle’ın 7.1 sürümü ile birlikte ortaya çıkmış ve her yeni sürümde bir evvekinden daha gelişmiş olarak 10g sürümü ile birlikte son halini almış bir program olarak ifade edilebilir.Program dedim çünkü işlevi aslında analiz olan bir yapı.CBO , RBO dan farklı olarak execution plan çıkartırken belli kurallardan değil istatistiklerden hareket eder.Kendisine baz olarak “maliyet”i (cost) alır.

Peki bu istatistik nedir?İstatistikten kasıt ilgili tablodaki satır sayısı, verilerin tutulduğu block’ların durumu , indeks bilgileri, tablodaki bir satır uzunluğu ve adedi vs.. bilgilerdir.Tüm bu bilgiler ışığında CBO, farklı varyasyonlar oluşturur ve maliyeti (cost) en az olan “execution plan”’ ı seçer.Tüm bu işlemler uzun sürer gibi gözükse de aslında milisaniye mertebesinde oldukça kısa süren işlemlerdir.

Burada en önemli nokta kullanılan bu istatistiklerin “güncel” olmasıdır.Eğer güncel değilse çıkarılan “execution plan” maliyeti en düşük olan sanılır ama aslında böyle olmayabilir.Bu da beklenmedik sorgu , işlem vs. süreleri ile karşılaşmamıza sebep olur.

İstatistik toplamanın klasik yöntemi “analyze table” ve “dbms_utility”
kullanmaktır.Ama 8i sürümü ile ortaya çıkan ve Oracle’ın tercih ettiği “dbms_stats” paketi kullanmak en etkin şekilde istatistik toplanmasını sağlayacaktır.Aşağıda bunların kullanımına uygun örnekler ve açıklamaları bulabilirsiniz :

ANALYZE kulanımı hakkında :
Belli bir tablo, indeks ya da cluster için kullanılabilir.Tüm tablo için istatistik toplatılabileceği gibi bir satır sayısı ya da yüzde vererekte “tahmini” istatistik toplatılabilir.

ANALYZE TABLE employees COMPUTE STATISTICS;
ANALYZE INDEX employees_pk COMPUTE STATISTICS;
ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 100 ROWS;
ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 15 PERCENT;

DBMS_STATS kullanımı hakkında :
Özellikle pararel çalışma işlemleri(parrarel execution) ve istatistikleri server’lar arası taşıma özelliği DBMS_STAT’ı öne çıkaran özellikleridir.(Toplanan istatistikler bu paket ile silinebilmektedir.)

EXEC DBMS_STATS.gather_database_stats;
EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15);
EXEC DBMS_STATS.gather_schema_stats(’SCOTT’);
EXEC DBMS_STATS.gather_schema_stats(’SCOTT’, estimate_percent => 15);
EXEC DBMS_STATS.gather_table_stats(’SCOTT’, ‘EMPLOYEES’);
EXEC DBMS_STATS.gather_table_stats(’SCOTT’, ‘EMPLOYEES’,
estimate_percent => 15);
EXEC DBMS_STATS.gather_index_stats(’SCOTT’, ‘EMPLOYEES_PK’);
EXEC DBMS_STATS.gather_index_stats(’SCOTT’, ‘EMPLOYEES_PK’,
estimate_percent => 15);
EXEC DBMS_STATS.delete_database_stats;
EXEC DBMS_STATS.delete_schema_stats(’SCOTT’);
EXEC DBMS_STATS.delete_table_stats(’SCOTT’, ‘EMPLOYEES’);
EXEC DBMS_STATS.delete_index_stats(’SCOTT’, ‘EMPLOYEES_PK’);

Istatistikleri sistemler üzerinde taşıyabilme özelliğine dikkat çekmek istiyorum.Test verilerinin gerçek ortamdaki veriler kadar büyük ve gerçekçi olması her zaman mümkün olmamaktadır.Gerçek ortamda 100 Milyon kayıt içeren bir tablonun test ortamında çokdaha az sayıda kayıt içermesi söz konusudur.Ama bu özellikle performans testleri için önemli bir kısıttır.Ancak istatistiklerin taşınabilmesi sayesinde , optimizer için test ortamı gercek ortammış gibi kullandırılabilir.Baska bir deyişle test ortamındaki tablonuzdada 100 Milyon kayıt varmış gibi bir execution plan çıkarttırmak mümkün olmaktadır.

Yasin DEMİR