20 Şubat 2011 Pazar

TROUG - Nisan 2011 Konferansı

Merhabalar,

TROUG (Turkish Oracle User Group) 2011 yılının ilk konferansı Nisan'da düzenlenecektir. Bütün gelişmeleri TROUG adresinden veya FriendFeed sayfasından takip edebilirsiniz.

Konuyla ilgili detaylı bilgiyi aşağıdaki adreslerden bulabilirsiniz;

H. Tonguç Yılmaz
Zekeriya Beşiroğlu

İyi çalışmalar,

Ogan

--Güncelleme--


Konferans, 21 Nisan 2011'de Bahçeşehir Üniversitesi Beşiktaş Kampüsünde 09:00 - 17:00 arasında düzenlecektir. Yurtiçi ve yurtdışından katılımcılarla gerçekleştirilecek konferansa katılım TROUG üyelerine ücretsizdir.

19 Şubat 2011 Cumartesi

Okuma Tipleri - db file sequential read / db file scattered read

Selamlar,

Bir Oracle veritabanı üzerindeki bekleme olaylardan birisi olan "db file sequential read" ve "db file scattered read" okuma tiplerinden bahsetmek istiyorum.

DB FILE SEQUENTIAL READ

llgili bağlantı (session) ardışık okuma (sequential read) gerçekleşirken beklemektedir. Bu okuma buffer cache içerisindeki bloklardan gerçekleşmektedir. AWR, ADDM veya dinamik performans görüntülerinde bu olayı görüyorsanız şu anlama gelmektedir; bir kullanıcı işlemi veritabanında bulunan buffer cache içerisindeki bloklardan okuma gerçekleştiriyor ve bir fiziksel I/O bekliyor demektir. Ardışık okuma tekli blok okumasıdır. Tekli blok okumaları genelde indeks kullanımı gerçekleştiği durumlarda görülmektedir. "Full table scan" gerçekleştiği durumlarda ise nadiren de olsa ardışık okuma gözlemlenmektedir ve bunun nedeni kimi zaman FTS yapılırken okunması istenen veri/blok tamamen buffer cache'de olabilir ya da FTS tek bir bloğa sığmaktadır (çok minik objelerden bahsediyorum). İşte bu okumalar çok büyük bir oranla "db file sequential read" olayı ile sonuçlanacaktır.

V$SESSION_WAIT dinamik performans görüntüsünde bulunan kolonlardan;

P1 - Gerçek obje numarası
P2 - Okunmakta olunan blok
P3 - Blokların sayısı (1 olmalı)

Şimdi, bekleme olayı demiştim ve eminim aklınıza veritabanını yavaşlatan bir olay olabileceği gelmektedir. Aslında böyle bir şey tam olarak değil. Oracle'a göre sağlıklı bir sistemde durağan beklemelerden (idle waits) sonra gelmesi gereken en büyük bekleme olayı fiziksel okuma beklemeleridir. Aşağıdaki örnekleme ardışık, dağınık ve direkt yol okuma olayları (direct path read) ile SGA - PGA arasındaki ilişkiyi göstermektedir.

Bu görüntüden de anlaşılacağı gibi db file sequential read okumaları SGA'nın içerisindeki belli bir tekil bloğu isterken, db file scattered read yani dağınık okuma yöntemi ile SGA'nın buffer cache'i içerisinde birden çok ve dağınık bloklar okunmakta ve kullanıcı görevi tarafından Oracle veritabanından istenmektedir.

DB FILE SCATTERED READ

db file sequential read'in yaptığı işin aynısını yapmaktadır ancak bunu birden çok veri bloğu için yapmaktadır.

Dağınık okuma bir indeksin "fast full scan" özelliğini ve bir FTS gördüğünüz zaman gerçekleştiğini ifade edebiliriz. Burada bir obje için bütün okumadan kastettiğimiz bütün buffer cache'in okunması değildir. Buffer cache içerisinde bulunan ve bizim sorguda istediğimiz bütün blokların, buffer cache üzerinde ardışık değil ama dağınık olarak bulunması (Bkz. yukarıdaki görüntü).

Sağlıklı bir sistemde db file sequential read ve scattered read'lerin olması gerektiğini ifade etmiştim ancak tabii ki bir yere kadar. Fiziksel okuma yerine buffer cache'de blok bulabilmek oldukça güzel ama bunu bulmanın bu iki tipi arasında da bir kontrol sahibi olabiliriz. db file sequential read > db file scattered read olması gerekirken db file sequential read'lerin de sürekli çoğalması ve bir veritabanının neredeyse bütün bekleme olaylarını oluşturması da iyi bir durum olmayabilir. Böyle bir durumla karşılaşırsanız, v$sqlarea dinamik performans görüntüsünü sorgulayabilir ve SQL_ID'lerini aldığınız yoğun okuma yapan sorguları "sql access advisor" veya "sql tuning advisor"a iletebilirsiniz. 

Dağınık okumaların ardışık okumalardan fazla olduğu durumlarda çok yoğun DML aktiviteleri ve I/O yapılmaktadır denebilir. Bu tarz aktivitelerin kontrolünü sağlayabilmek için;

1) SQL Tuning yaparak anormal I/O'nun azaltılması,
2) İşyükünü dengeleyerek, I/O ihtiyacını azaltmak,
3) Sistem istatistiklerini toplamak ve güncel tutmak (DBMS_STATS),
4) ASM (Automatic Storage Management) kullanımına geçmek,
5) Daha fazla disk ekleyerek, I/O dağılımını dengelemek,
6) Gereksiz index ve parallel hint'lerini sorgudan kaldırmak.

I/O'nun artmasına başka sebep olarak ise;

1) Buffer cache hit ratio (aradığımız bloğu buffer cache'de bulma oranı) düşük.
2) Ardışık ve dağınık okuma o kadar fazladır ki cevap verme (response time) süresi azalır.

Aşağıdaki sorguyu kullanarak hangi bağlantının nasıl beklediğini görebilirsiniz (ardışık ve dağınık okuma için);

SELECT SQL_ADDRESS, SQL_HASH_VALUE
FROM V$SESSION
WHERE EVENT_LIKE 'db file%read';

Dağınık okumaları görüntülemek ve mümkünse ardışık okumalara çevirebilmek için plan yapmadan önce;

SELECT ROW_WAIT_OBJ#
FROM V$SESSION
WHERE EVENT = 'db file scattered read';

Yukarıdaki sorgudan gelen cevap ile;

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = $row_wait_obj#;

AWR raporunun en çok görünen bekleme olayları arasında ardışık ve dağınık okumaları görüyorsanız çokta fazla üzülmeyin, bu kötü bir durum olduğunu ifade etmiyor ama fazla I/O varsa da nedenini bulmak ve gereksiz I/O'ları azaltmak gerekmektedir. Bunu yapmazsanız veritabanının cevap verme süresi azalacaktır. Bununla birlikte ben 3 kırmızı diyorum, "Commit, Concurrency, Application" bekleme olaylarını görmekten iyidir çünkü bu tipte bekleme olayları daha fazla veritabanı zamanı tüketmekte ve ciddi beklemelere, zaman kayıplarına neden olmaktadır. Commit redolog'lar ve LGWR ile ilgiliyken, Concurrency ve Application bekleme olaylarında geçen zamanların artması ve AWR raporunda göze batması kötü uyarlanmış ve çalışmakta olan uygulamanız ile ilgili olabilir. Bu arada 3 kırmızı dememin nedeni EM performans sekmesinde kırmızı renk tonlarında gözüküyor olmalarıdır. Dikkat ederseniz CPU ve User I/O daha canlı (yeşil ve mavi) renklerde olup bana kalırsa biraz daha masumluğu sembolize etmektedir :)

İyi çalışmalar.

Ogan

17 Şubat 2011 Perşembe

Real Application Testing - Database Replay

Real Application Testing - Database Replay

Oracle'ın 10gR2 versiyonu ile aramıza katılan Real Application Testing opsiyonu ve database replay özelliğini anlatmaya çalışacağım. Database replay'in özelliğini, ana veritabanındaki workload'u yani yükü kayıt altına alarak, (capture) test veritabanında yeniden oynatılması olarak ifade edebiliriz. 

Sistemle ilgili bir değişiklik planladığınız zaman, bu bir sürüm yükseltme çalışması ya da işletim sistemi yamasının yüklenmesi olabilir, database replay özelliğini kullanarak işlerin nasıl olabileceğini görebilirsiniz. Tabii bunu yapabilmeniz için bir test ortamınızın olması gerekmektedir. Veritabanının kayıt altına aldığı bu iş yükünü değiştirerek, hızlandırarak veya yavaşlatarak, asenkron uygulamalarla çalıştırarak test ortamında yeniden oynatabilirsiniz. Bu özelliğin bize kattığı ek fayda ise halihazırda olan hataların çözümünün de öngörülebilmesini sağlamaktadır. 

Database replay'in 11g ile kazandırdığı en büyük yenilik şüphesiz yeni oluşturacağımız konfigürasyonun önceden nasıl çalışabileceğini görebilmemizdir. Bir örnek daha vermem gerekirse tek instance koşan veritabanınızda birden fazla instance olmasını yani RAC kurmayı planlıyorsunuz. RAC'i önce test ortamında kurun ve ardından database replay özelliğini kullanarak RAC sisteminizin production üzerinde nasıl performanslı çalışacağını görün. Database replay debug işlemleri için de kullanılabilir. Bilinen bir bug'ın sizi nasıl etkileyebileceğini, upgrade ile çözülüp çözülmeyeceğini görebilirsiniz.

İşyükünün Kaydedilmesi

Database replay özelliğini kullanabilmek için öncelikli olarak bir işyüküne sahip olmamız gerekiyor. Bu işyükü kaydını da ana veritabanından alıyoruz. İşyükünün kayıt altına alınmasının emrini Oracle veritabanına verdiğimiz zaman bize "capture files" adı verilen ve işletim sistemi üzerinde bulunan binary dosyalar üretecektir. Bu dosyaların içerisinde de Oracle veritabanına dışarıdan bağlanan client'ların yaptıkları kayıt altına alınacaktır. Dilerseniz Oracle'ın oluşturduğu bu binary dosyaları farklı konumlarda da kaydettirebilirsiniz. Peki, "client'ların yaptıkları" derken neyi kastediyorum? SQL cümleleri, bind variable'lar, işlem (transaction) gibi bilgileri belirtmek istiyorum. Arka plan görevlerinin oluşturduğu aktiviteler ve veritabanındaki zamanlandırılmış görevler  (scheduler jobs - DBMS_SCHEDULER) bu işyükü kapsamında ilgili binary dosyalara yazılmazlar. Bu binary dosyalar aynı zamanda platform bağımsızdır ve herhangi başka bir sisteme taşınabilir. 

İşyükünün başlatılmasından önce yapılması gereken bazı işlemler bulunmaktadır. İlk önce test sistemini nasıl ayağa kaldıracağınızın planını kurmanız gerekmektedir. Bunu yapabilmek için izleyebileceğiniz yöntemler arasında;

1) Recovery Manager'ın DUPLICATE komutu,
2) Snapshot Standby özelliği,
3) Data Pump import ve export özelliği bulunmaktadır.

Bir anlamda ana veritabanı ile oluşacak yeni test veritabanını mantıksal ve fiziksel olarak eşlemeye çalışmaktayız. Tabii birebir aynı olması söz konusu değil zira buradaki amacımız oldukça benzer veritabanlarını test etmektir. 

Bi işyükünün oluşmasını başlatmadan önce Oracle'ın tavsiye ettiği yöntemler bulunmaktadır. Mesela bir tanesi veritabanının yeniden başlatılmasıdır. Peki neden? Veritabanını yeniden başlattığınız zaman var olan bütün transaction'lar sonlanmış, kimi commit edilmiş kimi de rollback edilmiş olacaktır. Veritabanı işyükünün başlangıç noktasında tutarlı bir veritabanımız olacaktır. Bu, testin yapılması için önemlidir ve testin kalitesini etkiler. Eğer veritabanını yeniden başlatmadan bir işyükü kaydına başlarsak, halihazırda iş yapan işlemlerin önceki kayıtları database replay özelliği tarafından kaydedilemeyecektir. Kalitesini etkiler ifadesini kullanmıştım, aslında kalitesinin sonuçları hata ile de sonuçlanabilir. Veritabanının yeniden başlatılması demek işlerin kesintiye uğraması demektir. Bunu yapacağınız zamanı iyi planlamanız gerekmektedir. Nasıl bir yedeği alacağınız zaman RMAN'in java pool'u kullanacağını bildiğiniz ve veritabanı performansını çok da olmasa yine de etkileyebileceğini bildiğiniz gibi database replay'e de aynı hakları tanımanız gerekmektedir. Uykusuz bir başka gece istiyorsanız database replay sizi bekliyor diyebilirim. 

Veritabanını yeniden başlattınız, sonra yapmanız gereken işyükü kaydını hiçbir kullanıcı işlemi başlamadan önce devreye almanızdır. Aksi halde veritabanını yeniden başlatmanızın amaca hizmet etmesi yine ortadan kalkacaktır. Veritabanını restricted modda açmak (STARTUP RESTRICT) ve RESTRICTED SESSION hakkı olmayan kimseyi veritabanına almamak bir yöntem olabilir. ALTER SYSTEM DISABLE RESTRICTED SESSION ile veritabanını restricted session özelliğinden çıkartabilirsiniz. 

Varsayılan olarak bütün kullanıcı işlemleri ve bağlantıları database replay'in işyükü kaydı tarafından kayıt altına alınacaktır. Bunu gerçekten ister misiniz yoksa bir filtreleme olsa fena olmaz mı? İşyükünü kaydı sırasında dilediğiniz kullanıcı session'ını işlem içerisine alabilir ya da dışarıda bırakabilirsiniz. Yalnız burada şöyle bir durum söz konusu, işyükü için filtrelemeyi ya dahil ederek ya da hariç tutarak yapabilirsiniz. Hem belirli kullanıcıları dahil ederek hem de belirli kullanıcıları hariç tutarak işyükü kaydına başlayamıyorsunuz. Bu özelliği belki de gelecekteki sürümler için saklıyor olabilirler mi?

Yine bir işyüküne başlamadan önce az önce bahsettiğim binary dosyaların nerede oluşturulacağına karar verebilirsiniz. Burada dikkatli olmalısınız ve binary dosyaların oluşturulacağı alanın boyutu %100 olmamalı. Aksi halde işyükünün kayıt edilmesi duracaktır. İşyükünün kaydedeceği dosya boyutunu önceden tahmin etmek isterseniz 3-5 dakikalık bir işyükü kaydı oluşturun ve istediğiniz süreye göre boyutlandırın. Bu boyutlandırma sonrasında binary'leri kaydedeceğiniz disk'i ve disk boyutunu belirleyebilirsiniz. 

İşyükü Kaydının Kısıtlamaları

Bir işyükü kaydı sırasında aşağıdaki özellikler kayıt altına alınmamaktadır;

1) SQL*Loader gibi araçlar tarafından yapılan ve dışarıdaki dosyalardan gelen direkt yazma işlemleri,
2) PL/SQL tabanlı olmayan Advanced Queuing özelliğinin kullanılması,
3) Flashback sorgularının tamamı,
4) OCI tabanlı obje taramaları,
5) SQL tabanlı olmayan obje erişimleri,
6) "Distributed Transaction" yani 2PC ve uzak veritabanlarına yapılan işlemler kaydedilmemektedir.

Bunlara ek olarak yukarıda bahsettiğim arka plan görevlerini ve zamanlanmış görevleri de ekleyebilirsiniz.

İşyükünün Devreye Alınması ve Devreden Çıkartılması

10gR2'nin EM ekranlarını incelediyseniz Database Replay özelliğini görmüş ve farkına varmış olmalısınız. Vaysayılan olarak işyükü kaydı bir 10gR2 veritabanı için kapalı gelmektedir. Bu özelliği devreye almak ya da devreden çıkartmak için PRE_11G_ENABLE_CAPTURE parametresinin yardımına başvurabilirsiniz. Bu parametre yalnızca 10gR2 için geçerlidir ve 11gR1 ve sonrası versiyonlar için database replay zaten varsayılan olarak kullanılabilir haldedir. 11gR1 ve sonrası için bu parametreye ihtiyacınız yoktur. 

Bir 10gR2 veritabanı için işyükü kaydınız devreye aşağıdaki script'i kullanarak alabilirsiniz;

SQL> @$ORACLE_HOME/rdbms/admin/wrrenbl.sql

wrrenbl.sql script'i bir ALTER SYSTEM komutu çalıştırarak PRE_11G_ENABLE_CAPTURE parametresini TRUE yapacak ve bu değişikliği hem memory'de hem de spfile içerisinde yapacaktır. Yani dinamik olarak değiştirilebilen bir parametredir tabii veritabanı spfile kullanıyorsa. 

Bir 10gR2 veritabanı için işyükü kaydınız devreden aşağıdaki script'i kullanarak çıkartabilirsiniz;

SQL> @$ORACLE_HOME/rdbms/admin/wrrdsbl.sql

enbl, enable, dsbl disable'ı simgelemektedir. Aynı şekilde yukarıdaki script bir ALTER SYSTEM komutu çalıştıracak ve PRE_11G_ENABLE_CAPTURE parametresini FALSE yapacaktır. 

İşyükünün Kaydının Başlatılması

Bir işyükü kaydını enterprise manager veya ilgili API'leri kullanarak yapabilirsiniz. Eğer enterprise manager yoksa çıkış yolunuz her zamanki gibi vardır. Ben her iki yolu da açıklamaya çalışacağım;

Enterprise Manager Aracılığıyla Başlatmak;

1) EM ana ekranından "Software and Support" alanına geçiyoruz ve Real Application Testing içinde bulunan "Database Replay" tuşuna basıyoruz.


2) "Go to Task" kolonunda bulunan işyükü görevlerinin ilgili olanına tıklıyoruz. 


3) Devam etmeden önce bütün önkoşulları sağladığınızdan bir kere daha emin olunuz. Bu yazımda önkoşullardan bahsetmiştim. Bütün koşulların sağlandığına kanaat getirdiğiniz zaman "Next" tuşuna basınız.


4) İşyükü kaydının opsiyonlarını seçiniz. Seçimlerinizi tamamladıktan sonra "Next" tuşuna basınız.


5) İşyükü kayının parametrelerini seçiniz. Seçimlerinizi tamamladıktan sonra "Next" tuşuna basınız. Buradaki veritabanı kapatma opsiyonlarını önceki yazılarımdan öğrenebilirsiniz.


6) "Job Parameters"ın altındaki bilgileri giriniz ve zamanlanacak görevi, içeriği ile birlikte tanımlayınız.
7) "Job Schedules"ın altındaki bilgileri giriniz ve zamanlanacak görevin hangi zaman diliminde çalışmasını istediğini ifade ediniz. 
8) "Job Credentials"ın altındaki bilgileri giriniz ve işletim sistemi ve veritabanı için bağlantı tanımlamalarını ifade ediniz. 6, 7 ve 8nci maddeleri tamamladığınız zaman "Next" tuşuna basınız.


9) Zamanlanmış görevin bilgilerini yeniden kontrol ediniz ve çalışmasını istiyorsanız "Submit" değişmesini istediğiniz parametreler veya bilgiler varsa "Back" tuşuna basınız ya da "Cancel" ile yaptıklarınızı iptal ediniz. 
10) İşyükünün çalışması ve kayıt altına alınması başladığı zaman yine EM aracılığı ile bu süreci takip edebilirsiniz.

İşyükü Kaydının Enterprise Manager Aracılığıyla Takip Edilmesi

Database Replay özelliği ile devreye aldığımız işyükü kaydının gözlenmesinin ana aracı Enterprise Manager'dır. EM kullanarak;

a) Aktif bir işyükünü gözlemleyebilir veya durdurabilirsiniz.
b) Tamamlanmış bir işyüküne bakabilir veya silebilirsiniz.

Aktif bir işyükü kaydının gözlemlenmesi için;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız.
2) "Active Capture and Replay" altındaki iş yükünü seçerek, "View" tuşuna basınız;



3) "Summary" altında işyükü ile ilgili gerekli bilgiler sunulmaktadır.
4) İşyükünün profilini görmek isterseniz "Workload Profile" tuşuna tıklayınız. 
5) İşyükü filtrelemelerini incelemek isterseniz "Workload Filters" tuşuna tıklayınız. 
6) "OK" tuşuna basarak Database Replay sayfasına dönebilirsiniz.

Aktif bir işyükü kaydını durdurmak için;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız.
2) "Active Capture and Replay" altındaki ilgili işyükünü seçiniz ve "Stop" tuşuna basınız.
3) Seçtiğiniz işyükünü gerçekten durdurmak istiyorsanız işleminizi "Yes" tuşuna basarak onaylayınız. Bunu yaptığınız zaman karşınıza "Export AWR Data" sayfası gelecektir.
4) AWR verisinin export etmek isterseniz "Yes" tuşuna basınız. Bu sayede yarıda kestiğiniz işyükü kaydının AWR raporunu elde edebilir ve olanları görebilirsiniz. "No" tuşuna basmış olsanız bile sonradan da ilgili AWR raporunu görüntüleyebilirsiniz.

Tamamlanmış bir işyükü kaydınız yönetmek için ise;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız.
2) "Workload Capture History" tuşuna basınız ve aşağıdaki ekranı görünüz.


3) Seçtiğiniz işyükünü silmek isterseniz "Delete" tuşuna basınız. Bu komut ile belirttiğiniz dizindeki binary kayıt dosyaları silinecektir.
4) "Export AWR Data" tuşuna basarak bu süreçteki AWR raporunu görebilirsiniz ve export edebilirsiniz.
5) Seçtiğiniz işyükünün detaylarını "View" tuşuna basarak görüntüleyebilirsiniz.
6) "Summary" altında seçtiğiniz işyükünün özelliklerini ve ilgili bilgilerini görüntüleyebilirsiniz.
7) "Workload Profile" altında işyükünün profillerini görebilirsiniz.
8) "Workload Filters" altıda işyüküne dahil olan veya olmayan bütün filtreleri görebilirsiniz.
9) "Database Replay" ekranına "OK" tuşuna basarak geri dönebilirsiniz.

API Aracılığıyla Başlatmak;

Enterprise Manager'ımız yoksa Database Replay'i kullanamayacağımız sonucu ortaya çıkmamaktadır. DBMS_WORKLOAD_CAPTURE paketi kurulum sırasında tanımlanan bir pakettir.

Öncelikli olarak bir filtre tanımlama nasıl yapılır ve bir filtre nasıl silinir bunlara bakalım;

BEGIN
DBMS_WORKLOAD_CAPTURE.ADD_FILTER(
fname=>'OGAN_FILTRE',
fattribute=>'KULLANICI',
fvalue=>'DENEME_KULLANICI'
);
END;
/

Bir işyükünden filtreyi kaldırmak içinse;

BEGIN
DBMS_WORKLOAD_CAPTURE.DELETE_FILTER(
fname=>'OGAN_FILTRE',
);
END;
/

İşyükünü yine API aracılığı ile başlatabilmek için kullanabileceğiniz örnek script aşağıdadır;

BEGIN
DBMS_WORKLOAD_CAPTURE.START_CAPTURE(
name=>'OGAN_CAPTURE',
dir=>'ogan_dizin',
duration=>1200,
capture_sts=>TRUE,
sts_cap_interval=>450
);
END;
/


Burada açıklamak istediğim START_CAPTURE parametresi capture_sts'dir. Bu parametre TRUE ise SQL tuning set'leri de işyükü kaydına dahil edilecektir. Bu özellik RAC veritabanları için geçerli değildir. sts_cap_interval ise saniye cinsinden bir değerdir ve SQL tuning set'lerin kaydedileceği cursor aralığını vermektedir. Varsayılan değeri eğer belirtmezsek 300 saniyedir. 300 saniyeden daha az değerler atamak tavsiye edilmemektedir zira performansı düşürebilmektedir (yeni cursor'lar sürekli açılacaktır).

API aracılığı ile çalışmakta olan bir bir işyükünü durdurmak için aşağıdaki script'i koşabilirsiniz;

BEGIN
DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();
END;
/

Buraya kadar umarım her şey yolundadır. API kullanarak bazı sistemleri oluşturmak ve kullanmak EM'ye göre nispeten daha kolay olsa da (burada olduğu gibi) siyah beyaz karışık bir ekrana bakmak kimi zaman canınızı sıkabilir. Öğrenmek ve bilginizi pekiştirmek için database replay kullanacaksanız benim tavsiyem API kullanmanızdır. EM aracılığı ile her zaman yapabilirsiniz fakat gerçek hayatta her gittiğiniz yerde veya çalıştığınız ortamda EM kurulu olmayabilir. Benim gördüğüm kurulu olsa da çoğu zaman patlamış, çalışmaz halde oluyor ve emca repository'sinin yeniden yaratılması ile karşılaşıyorum. Çok alakasız olacak ama hemen bir dip not vereceğim, kızmak yok. EM repository'si yaratılırken ve düşürülürken veritabanı QUIESCE moduna alınır ve işlem bittiği zaman çıkartılır. Quiesce modunda olan bir veritabanının durumunu v$instance dinamik performans görüntüsünden görebilirsiniz. Bu modda bağlı olan kullanıcıların hiçbir işlem yapması uygun görülmez ve asılı kalırlar. Mesai saatleri içerisinde yaparsanız Oracle danışmanlığını bir kenara bırakmanız gerekebilir, aman dikkat.

Gelelim API kullanarak AWR export'unu nasıl alabileceğinize;

BEGIN
DBMS_WORKLOAD_CAPTURE.EXPORT_AWR(capture_id=>1);
END;
/


Evet, API ile EM'nin yapabildiklerinin tamamını yapabileceğimizi ifade etmiştim. Şimdi ise gözlemleme kısmında neler yapabileceğimiz. Bakmanız gerekecek iki tane data dictionary görüntüsü bulunmaktadır.

Bunlar;

DBA_WORKLOAD_CAPTURES ve DBA_WORKLOAD_FILTERS.

İşyükünü tanımladık, başlattık ve aldık. Şimdi ise uygulama kısmına geldik. Sıradaki konuda aldığımız işyükünü nasıl uygulayacağımızı göstereceğim.

İşyükünün Yeniden Oynatılması

Replay, yani yeniden oynatma olarak adlandıralım. Yeniden oynatmaya başlamadan önce test veritabanımızın ve sistemimizin hazır olduğuna emin olmalıyız. RMAN DUPLICATE komutu ile test veritabanımızı oluşturduktan sonra test sistemi üzerindeki sistem zamanını da işyükü kaydının başladığı zamana döndürmemiz tavsiye edilmektedir. Bu, gerçek sonucu elde etmeniz için önemlidir.

İşyükünün binary dosyalarının test sistemine kopyalanmış olması gerekmektedir ve sistem üzerinde, ilgili dizin altında bulunmalıdır. 

İşyükünü yeniden oynatmak için her zmaanki gibi iki seçeneğiniz bulunmaktadır, EM ve API.

Enterprise Manager aracılığı ile işyükünün yeniden oynatılması;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız.
2) "Go to Task" altındaki ilgili ikona basınız.


3) "Directory Object" listesindeki ilgili dizini seçiniz. Bu dizin işyükü kayıt binary dosyalarının bulunduğu dizin olmalıdır. 


4) Daha geniş bilgiye sahip olmak isterseniz "Capture Details" tuşuna basınız ve gerekli bilgileri görünüz.
5) "Set Up Replay" tuşuna basınız. 
6) Yine daha önce bahsettiğim önkoşulların sağlandığını bir defa daha kontrol ediniz.
7) Yeniden oynatılması planlanan işyükünün birincil opsiyonlarını inceleyiniz.


8) "Replay Name" alanından bu yeniden oynatım için bir isim verebilirsiniz.
9) "SQL Performance Analyzer" altından SQL tuning set içerisinde SQL cümlelerinin kaydedilip kaydedilmeyeceğini belirleyebilirsiniz.
10) "Next" tuşuna bastığımız zaman karşımıza "Customize Options" sayfası gelecektir.


11) Bağlantı dizilerini yeniden ayarlayınız ve test veritabanında olacak şekilde olduğundan emin olunuz. Aksi halde client'ların yapacağı operasyonlar yapılamayacaktır. Burası oldukça önemli. "Test Connection" tuşuna basarak tanımladığınız bağlantıyı test edebilirsiniz.
12) Yeniden oynatmayla ilgili parametreleri bu maddede seçiyoruz. İlgili parametrelerle ilgili gerekli açıklamaları EM ekranından görebilirsiniz.


13) Yeniden oynatım sırasında kullanılacak client'ların hazır olduğuna emin oluyoruz. wrc işletim sistemi çalıştırılabilirini kullanarak client'ların hazır olduğundan bir defa daha emin oluyoruz ve "Wait for Client Connections" ekranını görüyoruz.


14) Yeniden oynatım client'larını başlatınız. Bütün client'lar bağlandığı zaman "Next" tuşuna basınız. Bu sayede "Review Page" ekranına yönlendirileceksiniz.


15) "Submit" tuşuna basarak yeniden oynatımı devreye alınız.

Şimdi bu yaptıklarımızı bir de API kullanarak tekrarlayalım;

DBMS_WORKLOAD_REPLAY paketinin diğer prosedür ve fonksiyonlarını kullanarak yolumuza devam ediyoruz.

BEGIN
DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(
replay_name=>'OGAN_REPLAY',
replay_dir=>'OGAN_DIZIN'
);
END;
/

Yukarıdaki komut ile OGAN_REPLAY'ine ait binary'ler OGAN_DIZIN'den çıkartıldı.

Client'ların bağlanması için bağlantı dizilerini yeniden tanımlıyoruz.

BEGIN
DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION(
connection_id=>100,
replay_connection=> 'ogan_database:4433/ogan_servis'
);
END;
/


Yeniden oynatımla ilgili opsiyonları tanımlamak için aşağıdaki PL/SQL bloğunu koşuyoruz;

BEGIN
DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(
synchronization=>TRUE
capture_sts=> FALSE
sts_cap_interval=>300
);
END;
/


Bu noktada filtre eklemek ve silmek daha önce gösterdiğim PL/SQL blokları aracılığı ile yapılmaktadır. Burada ek olarak bir filtre seti nasıl yaratılır ve atanır, onu göstereceğim;

BEGIN
DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET(
replay_dir=>'OGAN_DIZIN',
filter_set=>'oganreplayfiltreleri'
default_action=>'INCLUDE'
);
END;
/


BEGIN
DBMS_WORKLOAD_REPLAY.USE_FILTER_SET(
filter_set=>'oganreplayfiltreleri'
);
END;
/


Yeniden oynatımla ilgili bir "timeout" süresi tanımlayabilirsiniz. İşler kötü gittiği zaman operasyonu yarıda kesebilecek bir opsiyondur. SET_REPLAY_TIMEOUT prosedürü ile bu süreci Oracle'a anlatabilirsiniz.

BEGIN
DBMS_WORKLOAD_REPLAY.SET_REPLAY_TIMEOUT(
enabled=>TRUE,
min_delay=>10,
max_delay=>95,
delay_factor=>10
);
END;
/

max_delay ve min_delay parametreleri bu sefer dakika cinsindendir, saniye değildir. min_delay için varsayılan değer 10 dakika iken, max_delay için 120 dakikadır. Boş geçtiğiniz zaman bu değerler atanacaktır. delay_factor parametresi ise min_delay ile max_delay arasındaki gecikme zaman faktörünü belirlemektedir. Varsayılan değeri 8 kattır.

Yeniden oynatım timeout ayarlamalarını görüntülemek için aşağıdaki bloğu koşabilirsiniz;

DECLARE
enabled boolean;
min_delay number;
max_delay number;
delay_factor number;
BEGIN
DBMS_WORKLOAD_REPLAY.GET_REPLAY_TIMEOUT(
enabled,
min_delay,
max_delay,
delay_factor
);
END;
/

Aldığımız işyükü kaydının özelliklerini ve nasıl çalışmasını istediğimizi API kullanarak ifade ettik. Şimdi ise sıra yine API aracılığı ile nasıl çalıştıracağımızı göstermekte. Bize yardımcı olacak ilk prosedür START_REPLAY'dir.

BEGIN
DBMS_WORKLOAD_REPLAY.START_REPLAY();
END;
/


Çalışmakta olan ve halihazırda operasyona devam eden bir yeniden oynatım işyükünü duraklatmak ve duraklattığımız bir yeniden oynatım işyükünü yeniden koşturmak için sırasıyla;

BEGIN
DBMS_WORKLOAD_REPLAY.PAUSE_REPLAY();
END;
/


BEGIN
DBMS_WORKLOAD_REPLAY.RESUME_REPLAY();
END;
/


Beğenmediniz, tamamen iptal etmeye karar verdiniz. Aşağıdaki blok sizin için;

BEGIN
DBMS_WORKLOAD_REPLAY.CANCEL_REPLAY();
END;
/


Bir de yine AWR raporlarını export olarak alabiliyorsunuz bunun için de önceden gösterdiğim EXPORT_AWR prosedürünü kullanabilirsiniz.

İşyükü yeniden oynatımının nasıl gittiğini anlamak için EM'ye ihtiyacınız olmasa da yine karanlıklar diyarına bir yolculuk yapabilir ve aşağıdaki data dictionary görüntülerini ve dinamik performans görüntüsünü kullanabilirsiniz;

DBA_WORKLOAD_CAPTURES
DBA_WORKLOAD_FILTERS
DBA_WORKLOAD_REPLAYS
DBA_WORKLOAD_REPLAY_DIVERGENCE
DBA_WORKLOAD_REPLAY_FILTER_SET
DBA_WORKLOAD_CONNECTION_MAP
V$WORKLOAD_REPLAY_THREAD

Peki, şimdi ise Enterprise Manager'a geri dönelim ve koştuğumuz bir işyükü yeniden oynatımının nasıl gittiğini görelim;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız
2) "Active Capture and Replay" altındaki iş yükünü seçerek, "View" tuşuna basınız;



3) "Status" kısmından yeniden oynatımın ne durumda olduğunu görünüz. "In Progress" durumunda olan bir yeniden oynatımının yanında "Stop Replay" tuşu gözükecektir. Yeniden oynatımı durdurmak için bu tuşa basınız. 

Bitmiş bir yeniden oynatımı incelemek ve görüntülemek içinse;

1) "Software and Support" EM sayfasında "Real Application Testing" opsiyonu altındaki "Database Replay" tuşuna basınız
2) "Go to Task" altındaki ilgili ikona basınız.
3) "Directory Object" altında hangi dizinde binary'lerimizin bulunduğunu gösterelim.
4) "Replay History" ekranından ilgili işyükü kaydının daha önce nasıl oynatıldığını inceleyebiliriz. İlgili yeniden oynatımı seçip, "View" tuşuna basınız.
5) "Summary" altında yeniden oynatımla ilgili detaylı bilgileri bulabilirsiniz.
6) "Workload Profile" altından işyükü profilleri ile ilgili bilgilere sahip olabilirsiniz. Aşağıdaki ekran görüntüleri inceleyebileceğiniz verileri göstermektedir. Başlatılan zaman, geçen zaman, kullanıcıların çağırdıkları işlemler ve detaylı kıyaslama bilgileri gösterilmektedir.




7) "Connection Mapping" altından bağlantı dizileri (kullanılan) bilgilerine erişebilirsiniz.
8) "Replay Parameters" altından yeniden oynatım sırasında kullanılan parametre listesini görüntüleyebilirsiniz.
9) "Report" sekmesi altından dilediğiniz raporu çekebilirsiniz.


Yukarıda EM ve API aracılığı ile yeniden oynatım ve işyükü bilgilerinin nasıl izlenebileceğini, iptal edilebileceğini, duraklatılıp, yeniden nasıl başlatılabileceğini gösterdim.

İşin aslı çok kapsamlı bir makale hazırlamadan, direkt olarak Real Application Testing opsiyonunu ve Database Replay'i açıklamak istemiştim ama database replay'den hiç bahsetmediğimi ve nasıl kullanabileceğini göstermediğimi hatırladım. Umarım faydalı bir makale olmuştur. Database Replay gerçekten kullanılabilecek bir özelliktir fakat ifade ettiğim üzere çoğu zaman bir test ortamı bulamıyoruz. Test ortamının olduğu sistemlerde de test ile ana veritabanının işletim sistemi düzeyleri ve özellikleri farklı olabiliyor. Velhasıl eğer sağlam bir test sisteminiz varsa ve ana veritabanının bulunduğu sunucu ile aynı özelliklere sahipse ve siz bir "test" yapmak istiyorsanız, bu makaleden faydalanmanızı ümit ediyorum.

Son olarak bir itirafta bulunmak istiyorum. Real Application Testing'i ilk gördüğüm zaman ne olduğunu anlamam zaman almıştı. Database Replay ile 10gR2 kullanırken tanıştığım zaman ilgi alanıma girmişti fakat çok kullanıldığına rastlamamıştım. İşin aslı birlikte çalıştığım veritabanı yöneticilerinden de bugüne kadar "Database Replay" konusunda bir tek kelime bile duymadım. Heralde farklı sebepleri vardır :)

Database Replay ve Real Application Testing konusu "Oracle Database 11g: Performance Tuning" eğitimlerinde gösterilmektedir. Ek bilgi olarak bu eğitimi aldıktan sonra Oracle Certified Expert olabilmek için 1Z0-054 kodlu sınavı satın alabilirsiniz. Eğer OCP sertifikanız varsa eğitime katılmadan, direkt olarak sınava girebilirsiniz. Detaylı bilgi için;

http://education.oracle.com/
http://certification.oracle.com/

İyi geceler.

Ogan

14 Şubat 2011 Pazartesi

Kullanıcı Takibi ve Hatalı Girişlerin Belirlenmesi

Selamlar,

Veritabanına bağlanan kullanıcıları takip edebilmenin birden fazla yolu bulunmaktadır. Bunların arasında audit ve logon trigger gibi yöntemler bulunmaktadır.

Sisteme bağlanan her kullanıcının takip edilebilmesi için aşağıdaki gibi bir trigger yaratılabilir;


CREATE OR REPLACE TRIGGER OPTPROD_LOGON_TRIGGER
after logon on database
declare
    hostadi varchar2(100);
    ipadresi varchar2(100);
    schema_adi varchar2(100);
    db_adi varchar2(100);
    terminaladi varchar2(100);
    zaman date;
    os_user varchar2(100);
begin
    select sys_context('USERENV','HOST')
    into hostadi
    from dual;
    
    select sys_context('USERENV','IP_ADDRESS')
    into ipadresi
    from dual;   
    
    select sys_context('USERENV','SESSION_USER')
    into schema_adi
    from dual;
    
    select sys_context('USERENV','DB_NAME')
    into db_adi
    from dual;
    
    select sys_context('USERENV','TERMINAL')
    into terminaladi
    from dual;
    
    select sysdate
    into zaman
    from dual;
    
    SELECT sys_context('USERENV', 'OS_USER')
    into os_user 
    FROM dual;
    
    insert into OPTPROD_LOGON
    values(user, hostadi, ipadresi, schema_adi, db_adi, terminaladi, zaman, os_user);
    END IF;
end;
/

Bu basit trigger ile veritabanına yapılan her girişten sonra OPTPROD_LOGON tablosu içerisine kullanıcı bilgileri girilecektir.

Peki veritabanına yapılabilecek olası bir kullanıcı giriş zorlamasını nasıl algılarsınız? Öncelikle buna bir önlem olarak Oracle profillerini kullanarak, belirlenen bir profil grubu için maksimum şifre deneyebilme özelliğini, resource_limit parametresini TRUE yapmadan ayarlayabilir ve zorlama yapan kişi örneğin 3 defa yanlış girdikten sonra ilgili hesabı kilitleyebilirsiniz. Böyle bir güvenliğin yanı sıra neler olduğunu takip etmek isterseniz, audit özelliğini rahatlıkla kullanabilirsiniz. Öncelikli olarak AUDIT_TRAIL parametresini DB veya DB_EXTENDED olarak değiştirmeniz, bunu SPFILE'a yazmanız ve veritabanını yeniden başlatmanız gerekmektedir.

SQL> alter system set audit_trail='DB_EXTENDED' scope=spfile;
SQL> startup force;
SQL> show parameter audit_trail;

Şimdi ise yukarıda bahsettiğim bilgiye sahip olmak için yapılacak aksiyonu gösteriyorum;

SQL> audit create session by access;
Audit succeeded.

Bu değişikliğin nerede bulunduğunu takip etmek isterseniz SYS kullanıcısının sahip olduğu bir görüntü var ve adı DBA_PRIV_AUDIT_OPTS

SQL> select privilege, success, failure
2 from sys.dba_priv_audit_opts;

PRIVILEGE                  SUCCESS           FAILURE
-----------------------------------------------------------
CREATE SESSION     BY ACCESS      BY ACCESS

Veritabanına yapılan girişleri kontrol edeceğiniz görüntü ise DBA_AUDIT_SESSION.

SQL> select "OS_USERNAME","USERNAME","USERHOST","TERMINAL","TIMESTAMP","ACTION_NAME","LOGOFF_TIME","LOGOFF_LREAD","LOGOFF_PREAD","LOGOFF_LWRITE","LOGOFF_DLOCK","SESSIONID","RETURNCODE",
CASE WHEN TO_CHAR(RETURNCODE) = '1017' THEN 'ORA-01017: geçersiz kullanıcı adı/parolası; oturum açma reddedildi'
     WHEN TO_CHAR(RETURNCODE) = '28000' THEN 'ORA-28000: hesap kilitli'
     WHEN TO_CHAR(RETURNCODE) = '28009' THEN 'ORA-28009: SYS şeklindeki bağlantı SYSDBA veya SYSOPER olarak yapılmalıdır'
     WHEN TO_CHAR(RETURNCODE) = '604' THEN 'ORA-00604: özyinelemeli SQL düzeyinde hata oluştu'
     ELSE TO_CHAR(RETURNCODE) END "RETURNMESSAGE",
"CLIENT_ID","SESSION_CPU","EXTENDED_TIMESTAMP","PROXY_SESSIONID","GLOBAL_UID","INSTANCE_NUMBER","OS_PROCESS" 
from dba_audit_session
where returncode > 0;

RETURNCODE bize bağlantının nasıl sonlandığını göstermektedir. Benim gösterdiğim örnekte genelde gelen returncode'lar bulunmaktadır ama duruma göre sayısı tabii ki artabilir. DBA_AUDIT_SESSION bir SYS objesidir ve SYSTEM tablespace'i üzerinde bulundurulmaktadır. Konfigürasyonu bu şekilde bırakacaksanız tablespace'in durumunu kontrol altında tutmalısınız ve bu tablespace'in dolmasını önlemelisiniz. Bu genelde karşılaşılan audit problemleri arasında yer almaktadır, onun için audit açtıktan sonra mutlaka ilerleyişini ve boyutlandırmasını inceleyiniz.

DBA_AUDIT_SESSION'ın script'i;

select os_username,  username, userhost, terminal, timestamp, action_name,
       logoff_time, logoff_lread, logoff_pread, logoff_lwrite, logoff_dlock,
       sessionid, returncode, client_id, session_cpu, extended_timestamp,
       proxy_sessionid, global_uid, instance_number, os_process
from dba_audit_trail
where action between 100 and 102;

DBA_AUDIT_TRAIL'in script'i;

select spare1           /* OS_USERNAME */,
       userid           /* USERNAME */,
       userhost         /* USERHOST */,
       terminal         /* TERMINAL */,
       cast (           /* TIMESTAMP */
           (from_tz(ntimestamp#,'00:00') at local) as date),
       obj$creator      /* OWNER */,
       obj$name         /* OBJECT_NAME */,
       aud.action#      /* ACTION */,
       act.name         /* ACTION_NAME */,
       new$owner        /* NEW_OWNER */,
       new$name         /* NEW_NAME */,
       decode(aud.action#,
              108 /* grant  sys_priv */, null,
              109 /* revoke sys_priv */, null,
              114 /* grant  role */, null,
              115 /* revoke role */, null,
              auth$privileges)
                        /* OBJ_PRIVILEGE */,
       decode(aud.action#,
              108 /* grant  sys_priv */, spm.name,
              109 /* revoke sys_priv */, spm.name,
              null)
                        /* SYS_PRIVILEGE */,
       decode(aud.action#,
              108 /* grant  sys_priv */, substr(auth$privileges,1,1),
              109 /* revoke sys_priv */, substr(auth$privileges,1,1),
              114 /* grant  role */, substr(auth$privileges,1,1),
              115 /* revoke role */, substr(auth$privileges,1,1),
              null)
                        /* ADMIN_OPTION */,
       auth$grantee     /* GRANTEE */,
       decode(aud.action#,
              104 /* audit   */, aom.name,
              105 /* noaudit */, aom.name,
              null)
                        /* AUDIT_OPTION  */,
       ses$actions      /* SES_ACTIONS   */,
       logoff$time      /* LOGOFF_TIME   */,
       logoff$lread     /* LOGOFF_LREAD  */,
       logoff$pread     /* LOGOFF_PREAD  */,
       logoff$lwrite    /* LOGOFF_LWRITE */,
       decode(aud.action#,
              104 /* audit   */, null,
              105 /* noaudit */, null,
              108 /* grant  sys_priv */, null,
              109 /* revoke sys_priv */, null,
              114 /* grant  role */, null,
              115 /* revoke role */, null,
              aud.logoff$dead)
                         /* LOGOFF_DLOCK */,
       comment$text      /* COMMENT_TEXT */,
       sessionid         /* SESSIONID */,
       entryid           /* ENTRYID */,
       statement         /* STATEMENTID */,
       returncode        /* RETURNCODE */,
       spx.name          /* PRIVILEGE */,
       clientid          /* CLIENT_ID */,
       auditid           /* ECONTEXT_ID */,
       sessioncpu        /* SESSION_CPU */,
       from_tz(ntimestamp#,'00:00') at local,
                                   /* EXTENDED_TIMESTAMP */
       proxy$sid                      /* PROXY_SESSIONID */,
       user$guid                           /* GLOBAL_UID */,
       instance#                      /* INSTANCE_NUMBER */,
       process#                            /* OS_PROCESS */,
       xid                              /* TRANSACTIONID */,
       scn                                        /* SCN */,
       to_nchar(substr(sqlbind,1,2000))      /* SQL_BIND */,
       to_nchar(substr(sqltext,1,2000))      /* SQL_TEXT */
from sys.aud$ aud, system_privilege_map spm, system_privilege_map spx,
     STMT_AUDIT_OPTION_MAP aom, audit_actions act
where   aud.action#     = act.action    (+)
  and - aud.logoff$dead = spm.privilege (+)
  and   aud.logoff$dead = aom.option#   (+)
  and - aud.priv$used   = spx.privilege (+)
/

Yukarıda da gördüğünüz gibi DBA_AUDIT_SESSION görüntüsünün bilgileri aldığı yer aslında aud$ tablosu. Bu tablo da SYS'nin objesidir ve SYSTEM tablespace'i içerisinde bulunur.

Kolay gelsin.

Ogan

13 Şubat 2011 Pazar

Paylaşmak, Paylaşım

Selamlar,

Teknik bir yazı yazmak istemiyorum şu anda ama biraz kafamdakileri aktarmak istiyorum. Oracle'dan çok fazla uzaklaşmadan, "paylaşmak" hakkında birkaç bilgi vermek istiyorum.

Benim bir kardeşim yok ve hayatta paylaşmanın ne kadar güzel bir şey olduğunu bu günlüğü oluşturana kadar fark etmemiştim. Tek çocuk sendromum çok fazla olmadı ama paylaşmazdım da. Bu fikrimi değiştiren bir insan oldu ve bu şekilde bir günlük oluşturmaya karar verdim ve paylaşmaya başladım. Paylaştıkça coşkum, bilgim ve heyecanım arttı. Birilerinin makalelerimi okuduğunu, bunlardan yararlandığını ve gerçekten bir şeyler öğrendiğini gördüğüm zaman tarif edilemez bir mutluluk hissettim. O zaman anlamaya başladım paylaşmanın ne kadar güzel bir his olduğunu. Benim kişisel inancım sahip olduğum bütün bilgilerin toprağa değil, diğer insanlara da akması gerektiğidir. Sonuçta bulunduğumuz çağda bilgi saklanabilecek, gizlenebilecek ve kendinize saklayabileceğiniz bir olgu değildir.

Paylaşırken ne kazanırsınız? Diyelim yaptığınız bütün paylaşımları bir amaç için yapıyorsunuz, biraz acımasız olalım ve sizin, diğer insanları önemsemediğinizi düşünelim. Bu amacınız bir ödül olabilir, başka herhangi bir amaç olabilir ama sonuç olarak paylaştığınız için bilginiz taze kalır ve her gün yeni bir şeyler eklersiniz kendinize. Bunu karanlık taraf olarak düşünün :) Peki diğer tarafta ne var? İnsanlık, kardeşlik ve paylaşımın keyfi ile pekişen bilgi gücü var. Hiçbir zaman unutmayınız ki artık güç kas değil, bilgidir. Bilgi ise çok adi, kısır ve ne yazık ki çok çabuk eskiyen bir lanettir. Her zaman okumak, öğrenmek ve daha çok bilmek zorunda kalırsınız. Bilgi, dayanabileceğiniz bir destektir ama siz dayandıkça kırılmaya yönelir ve esner. Bir gün bu bilgiyi kuvvetlendirmezseniz kırılır ve sizi desteklemez. Buradan şunu ifade etmek istiyorum, paylaştığımız zaman sadece bütün bir topluluğun iyiliği için değil, aslında kendimiz için de çok iyi bir şey yapıyoruz demektir. Aslında hepsi birbirine bağlı. Google'a bir konu hakkında bir aramada bulunduğunuz zaman karşınıza sizin günlüğünüz çıkması ne kadar güzel bir şey biliyor musunuz? Eğer hiç paylaşmadıysanız bilmiyorsunuzdur...

Buradan bütün Oracle uzmanlarına, Oracle bildikleri için para kazanan yani profesyonel olan kişilere sesleniyorum. Paylaşın, paylaşın ki Türkiye'deki bütün Oracle heveslileri, isteklileri ve gönülleri öğrensin, siz öğrenin ve biz kazanalım. Artık Türkiye'deki Oracle topluluğunun ne kadar birbirine bağlı, paylaşan ve yetkinlik seviyesi yüksek bir topluluk olduğunu gösterelim herkese. Neden bir UKOUG (United Kingdom Oracle User Group) kadar aktif ve kuvvetli olmayalım? Neden daha fazla OCP, OCM veya ACE üye sahibi olmayalım? Bunu yapamayacak kadar mıyız, bence hiç de değil...

Ben bütün yazdıklarımızın bir amacı olduğuna gönülden inanıyorum ve özellikle Türkçe konusunda sayısı artan makalelerin, günlüklerin ve Oracle paylaşımlarının varlığını görmek müthiş bir mutluluk. Herkese güvenim sonsuz ve gelin birlikte Türkiye'de de Oracle konusunda çok ciddi bir yetkinlik olduğunu bütün bir topluluğa gösterelim. TROUG'u destekleyin ve paylaşmaya devam edin. Umarım bu yazımı birileri okuduktan sonra günlük oluşturamaya karar verir ve paylaşmanın ne kadar güzel olduğunu anlama fırsatı olur. Ben tek çocuk olarak bunu anladıysam herkes anlayabilir. Bu yazıyı okuyan ve günlük oluşturmaya karar verenlere sınırsız desteğim olacağını ifade etmek isterim.

Son zamanlarda gerçekleşen paylaşımların artması, makale paylaşımlarına bulunan sitelerdeki yazarların çoğalması, daha da kaliteli teknik makalelerin sayısının artması, bunlar neleri başarabileceğimizin sadece ufak bir göstergesi. Herkese başarılar ve bol paylaşımlar.

İyi geceler.

Ogan

12 Şubat 2011 Cumartesi

SQL Access Advisor

Merhaba,

Oracle veritabanının yönetiminin olmazsa olmasa danışmanlardan bugün "SQL Access Advisor" olanını anlatmak istiyorum. 10g versiyonu ve sonrası için geçerli olan bu danışmanlar arasında, SQL Tuning Advisor, Data Recovery Advisor, SQL Access Advisor, Memory Advisor, Undo Advisor ve Segment Advisor bulunmaktadır. Her birinin amacı farklıdır ve aynı zamanda AWR ve ADDM tarafından da kullanılmaktadırlar. Arka plandaki görevini üstenen görev ise MMON ve bir üst kademe olan MMAN'dır.

SQL Access Advisor

Bu danışmanın görevi verinin erişimi için kullanılan yollar hakkında tavsiyelerde bulunmaktır. Bir sorgunun geçtiği yolları en optimum nasıl belirleyebilirim, ne gibi önlemler alarak daha iyi yollardan geçmesini sağlayabilirim gibi konuları araştırır. Bu danışmanın bize performansı arttırmak için verebileceği tavsiyeler arasında partitioning kullanımı, materialized view kullanımı, index tanımlanması veya materialized view logs yaratılması ile ilgili tavsiyeler yer almaktadır. Bir sorgu için partitioning ve index oldukça önemlidir ve sorgu performansını direkt olarak iyileştirebilir. Bu sebepten dolayı SQL Access Advisor bu konular üzerine yoğunlaşmaktadır. Bu danışmanın bir diğer faydalı yanı ise bu tavsiyelerde bulunurken iş yüküne göre de hareket etmektedir. Index ve partitioning eklemek performansı arttırabilir ancak fiziğin temel kanunu olarak bir yandan enerji gelirken diğer yandan enerji çıkmalıdır. Buradaki durumda ise çıkan kaybettiğimiz disk alanı, giren ise artan performansdır. SQL Access Advisor bunun da optimum düzeyde gerçekleşmesini sağlar ve orantılı bir ölçüde tavsiyelerde bulunur. 

SQL Access Advisor Enterprise Manager kullanılarak çalıştırılabilir, görüntülenebilir ya da izlenebilir. Bunun yanı sıra DBMS_ADVISOR paketi kullanılarak da aynı işlemler yapılabilir. Takdir size kalmış ama EM kullanırsanız rakamlarla boğuşmak yerine grafiksel, hoş bir görüntüye bakmış olursunuz. 

SQL Access Advisor'a Genel Bir Bakış

Geçtiğimiz günlerde bir ACE Director olan Daniel Morgan'ın ( http://www.morganslibrary.com/ ) bir konuşmasını izliyordum. Partitioning ile ilgili konuşuyordu ve şunları söyledi; "Partitioning yalnızca oldukça satır sayısı içeren tablolar için geçerli değil, artık küçük veritabanları ve küçük tablolar için de kullanımı yaygınlaşmakta. Bunun en büyük etkisi insanların artık veriyi daha hızlı görmek ve vakitten kazanmak istiyor olmalarıdır". Benim "Interval Partitioning" ile ilgili yazdığım bir konu var ve burada detaylı olarak bahsediyorum. SQL Access Advisor'ın da ilgilendiği konu bu çünkü çok ciddi boyutlarda performans arttırabilir ve verinin son kullanıcıya hızlı bir şekilde sunulmasını sağlayabilir. Tabii, az önce de bahsettiğim gibi bu performansın da bir götürüsü olması gerekiyor. Partitioning ve indeksler için temel sorun daha fazla yer kaplamaları. 11gR2'deki ileri düzey sıkıştırma algoritmaları ile bu problemi CPU'nun üzerine bindirmeye başlayabilirsiniz ancak buradaki konumuzla ilgili olmadığı için detayına girmiyorum.

SQL Access Advisor'un bize sunduğu index tavsiyeleri arasında, b-tree index, bitmap index and function-based index'ler yer almaktadır. Bu 3 tip index'in kullanım amacı ve yeri farklıdır ancak varsayılan olarak yaratılan ve daha sık kullanılan index tipi b-tree index'tir. Materialized view olarak verdiği tavsiyeler ise MV'nin fast ya da full olarak tazelenmesi üzerinedir. Bu danışman, TUNE_MVIEW prosedürünü kullanarak karar vermektedir ve aynı zamanda bir MV'nin nasıl optimize edileceğini açıklar.

SQL Access Advisor'ın sırasıyla yapabileceklerine bir örnek vermem gerekirse, partitioned olmayan bir tablo için önce partition yaratılması için, ardından index ve MV yaratılması için tavsiye verebilir. Aşağıdaki diagram bize SQL Access Advisor'ın nasıl çalıştığını göstermektedir. Eğer tanımladığımız bir workload yoksa SQL Access Advisor farazi olarak bir workload oluşturarak ölçüm de yapabilmektedir. 


Bu danışmanın bize sunduğu bir fikri, tavsiyeyi beğenmezsek bunu EM aracılığı ile silebiliriz veya işaretleyebiliriz. 

SQL Access Advisor Kullanımı

SQL Access Advisor'ı kullanmanın en kolay yolu Enterprise Manager olarak gösterilmektedir. "Advisor Central" sayfası altında ilgili danışmanı görebilirsiniz. 

Bir Görev Yaratın

Bir danışman görevi data dictionary içerisindeki bilgilerin derlendiği ve sonuçların analiz safhasında ilgili danışman tarafından kullanıldığı görevlerdir. SQL Access Advisor'un bize bir tavsiye sunabilmesi için öncelikle bir görev yaratmamız gerekmektedir. Bunu yerine getirmek için DBMS_ADVISOR_QUICK_TUNE prosedürünü kullanabilirsiniz ya da DBMS_ADVISOR.CREATE_TASK prosedürü de bir görev yaratacaktır. EM üzerinden de yapabilirsiniz tabii ki. Bir görevin özelliklerini değiştirmek isterseniz ise DBMS_ADVISOR.SET_TASK_PARAMETER prosedürünü kullanabilirsiniz.

Workload Tanımlama

Bir workload SQL sorgularından oluşmaktadır. Bunun yanı sıra her SQL sorgusu için istatistikler ve özelliklerini içermektedir. İki tip workload bulunmaktadır, bunlar full ve partial'dır. Full olan tipte bütün SQL sorguları için veriler tutulmakta iken partial için sadece SQL sorgularının alt kümeleri saklanmakadır. Bu ikisi arasındaki farklardan birisi de full workload işe yaramayan ve kullanılmayan MV'ler için de bilgi içermektedir. 

SQL Access Advisor'ı bir workload olmadan kullanamazsınız. Veritabanı, bir workload'u SQL Tuning Set olarak saklamaktadır. DBMS_SQLTUNE paketi ile workload'a ulaşabilir ve diğer danışman görevleri ile paylaşabilirsiniz. Workload bağımsız bir obje olduğu için DBMS_ADVISOR.ADD_STS_REF prosedürünü kullanarak kimin için tanımlanacağını belirleyebilirsiniz. 

Tavsiyeleri Oluşturma

Görevler oluşturulduktan ve bu görevlere bir workload atandıktan sonra DBMS_ADVISOR.EXECUTE_TASK prosedürü kullanılarak ilgili görev çalıştırılabilir. Ortaya çıkan bütün tavsiyeler SQL Access Advisor Repository'sinde bulundurulmaktadır. Oluşan her bir tavsiye bir veya birden çok adımdan oluşabilmektedir. 

Tavsiyeleri Görüntüleme ve Kabul Etme

Katalog, yani data dictionary görüntüleri kullanılarak oluşturulan tavsiyeleri görüntüleyebilirsiniz. Bununla birlikte DBMS_ADVISOR.GET_TASK_SCRIPT prosedürü ile de bir script yarattırabilirsiniz. Enterprise Manager üzerinden görüntülemek isterseniz "Viewing Recommendation" kısmı karşınıza gelecektir. 

Bütün tavsiyeleri kabul edeceksiniz diye bir koşul elbette bulunmamaktadır. Ancak şöyle bir durum bulunmaktadır ki örneğin SQL Access Advisor bize bir tablo üzerinde partition yaratmamız gerektiğini iletti. Bu yerine gelmeden tablo üzerinde bir lokal indeks tanımlayamazsınız. Tavsiyelere uyduktan veya bir kısmına uymadıktan sonra yapacağımız en son aşama ise ilgili sorgunun performansı arttı mı yoksa artmadı mı bunu incelemektir.

SQL Access Advisor Repository

Veritabanındaki data dictionary'nin bir parçası olan bu repository, oluşturulacak olan tavsiyelerin saklanmasını üstlenmektedir. SQL Access Advisor için workload'ları toparlar, geçmişe yönetlik verinin desteklenmesine yarar ve sunucu tarafından yönetilmektedir. 

İyi çalışmalar.

Ogan
Takip et: @oganozdogan