DERS 27: Database Performans Yönetimi

Performans yönetimi 3 aşama ile gerçekleşir.

·         Performans planlaması

·         Instance ayarlaması

·         SQL ayarlaması

Performans Planlaması: Hardware, software, işletim sistemi, network yapısı gibi işlemler bazlı performans palanlaması yapılabilir. Hardware derken server’ın donanımı ile ilgili planlama, software derken oracle’ın hangi sürümü ve gereken yazılımlar ile ilgili planlama, oracle’ın kurulu olduğu işletim sistemi ile ilgili planlama ve network hızı bazında performans palanlamaları yapılabilir.

Instacne Ayarlamaları: Veri tabanının en iyi performansta çalışabilmesi için Oracle veri tabanı ve işletim sitemi parametrelerinin en güncel şekilde ayarlanması işlemleri yapılabilir. Ya işletim sistemi tarafındaki paramatreler ya da veri tabanındaki parametrelerin değişikliği ile yapıla bilen işlemlerdir.

SQL Ayarlamaları: SQL’lerin daha iyi nasıl yazılması gerektiği işlemi için söylenen kavramdır.

Performans Planlaması:

Performans planlamasının birkaç boyutu vardır. Planlama performans (hızI), maliyet ve güvenilirlik arasında bir denge içermelidir. Performans açısından donanım ve yazılım planlaması da çok önemlidir.

Performans planlaması bir uygulamanın gücünü ölçmek için önemlidir. Bu şua anlama gelir, sistemin genel performansı üzerinde büyük bir etkiye neden olmadan, daha fazla kullanıcı, client, session, oturumları ya da işlemleri yönetebiliriz.

Performans planlaması yapılırken belli başlı kurallar vardır.

Spesific: normalde spesifik olacak şekilde bir parametre değişikliği yapıldığında, bu değişikliği monitör ederken değişikliğin iyimi kötümü, bu değerlendirmenin yapılması gerekmektedir.

Ölçülebilirlik:   Ölçülebilir olması demek, örneğin belirli bir SQL Tuning ayarı olduğunu düşünürsek, içerisinde de yazılı bulunan 5 tane SQL ifade var, bu SQL’ler ayarlamak istenirse bu sql ifadelerin kaç saniyede çalıştığını tespit edip çalıştığı süreyi kısaltmaya çalışmak işlemidir.

Ulaşılabilirlik: Ölçülebilirliğe benzer bir yapıdır. Bir değişiklik yapıldığında bunun yapılabilir olmasıdır. 30 dakikada yapılan işler 3 saniyeye düşürülemez. Belki olabilir ancak hedef bu olamaz, ilk hedef biraz aşağıya indirilebilir olmalıdır.

Akla Yatkın olması: Hiç kullanılmayan şeyler olmaması, oracle’daki bütün parametreleri bileceğiz diye bir kural yok bizler bildiğimiz parametreleri değiştirebiliriz. Hiç kullanılmayan işleri ayarlamak durumda değiliz. Bizim için önemli olan bildiğimiz işleri tune etmek hedef olmalıdır.

Zaman: Belirli bir süre içerisinde bütün işlemleri gerçekleştiriyor olmak gerekecektir. Yani belirli bir zaman aralığında yapılmalıdır.

Data file’lerin mümkün olduğunca hızlı disklerde tutmak gerekmektedir. Çünkü I/O işlemlerinde mümkün olduğunca hızlı işlem yapmak adına gereklidir.

Performans Tuning Yöntemleri:

Tuning adımları olarak aşağıdakileri inceleyelim.

Tune adımları olarak sırasıyla dizayn, uygulama kodu, instance olarak sıralandırılır.

v  Dizayn: Veri tabanı olan yerlerde dizayn işlemi yapılmıştır. Dizaynı olan yapıların değiştirilmesi yapılmaz. Dizayn işine örnek olarak tek bir tabloda toplanabilecek veriyi 1 den fazla tabloda toparlarsak bu bize iş yükü sağlar ve performansı olumsuz etkileyecektir. Dizayn işi veri tabanının ilk kurulduğu anda yapılacak bir operasyondur. Mümkün olduğunca verileri az tablodan çekmek performans açısından gereklilik gösterir. Dizayn düşünüldüğünde veri tabanı en iyi şekilde kurulmuş olsa da şema dizaynını, tablo bağlantılarını, index’leri, foreign key, primary key ilişkileri yanlış yapılırsa sorgunun iyi yazılması sorgunun iyi geleceği anlamına gelmeyecektir. Yani performans olarak ciddi sorunlar yaşayabiliriz. Dataware House ortamlardaki dizayn farklı olur, Transactional ortamlarda ise farklı dizayn olur. Transacaitonal ortamlarda index’ler Dataware House ortamlara göre daha çok olacaktır. Çünkü Dataware House ortamlarda veri toplu olarak sorgulanır ancak transactional ortamlarda genelde tek sonuç dönen sorgular yapılacaktır. Bu nedenle eğer index’ler ile ilgili bir problem olursa performansta problem olacaktır.

v  Uygulama kodu: yanlış yazılmış kodlar olabilir. Bu durumda Database Adminsitrator olarak Database Developer’a bu durum iletilir ve değişiklik yapılması gerekmekteyse yaptırılır. Eğer yapılabiliyorsa değişiklik yapılabilir.

v  Instance: Instance ile ilgili problemler oluşabilir.

Performans Monitoring:

 

Bu işlem enterprise manger üzerinden çok basit yapılmaktadır. Bir sıkıntı, problem olması durumunda Enterprise Manager’da perofrmans tabına gelindiğinde bütün problemleri orada görmekteyiz.

Performansı tune ederken istatistikler çok çok önemli. Server donanım yapısı ne kadar güçlü olursa olsun server üzerindeki veri tabanı için istatistikler ne kadar güncelse o kadar performanslı çalışılır, ne kadar güncel değilse o kadar yavaş çalışır. Çünkü execution planları bu istatistiklere göre oluşturulur. Oracle veri tabanı için istatistikler olabildiğince güncel tutulmalıdır.

·         SQL Performans Tuning: doğru istatistiklerin toplanmasına bağlıdır.

·         İstatistikleri en iyi hale getirmek:

§  Obje istatistikleri

§  İşletim sistemi istatistikleri

·         İstatistik toplama yolları:

§  Otomatik olarak: otomatik yönetim görevleri

§  Manuel olarak: DBMS_STATS paketi

§  Veri tabanı başlangıç parametrelerini ayarlayarak

§  Diğer bir veri tabanından istatistikleri import ederek

Optimizer istatistikleri veri tabanı objeleri hakkında detayları belirleyen verinin toplamıdır. Bu istatistikler her bir SQL ifadesi için en iyi execution planı seçmeye sorgu optimizerı için gereklidir. Bu istatistikler peryodik olarak toplanırlar.

Tavsiye edilen istatistik toplama işlemi oracle veri tabanının otomatik olarak istatistikleri toplamasıdır. Otomatik yönetim görevleri veri tabanı oluşturulduğu zaman otomatik olarak oluşturulur ve scheduler tanımlayabiliriz. Varsayılan olarak ya hatalı ya da bozulmuş olan optimizer istatistiklere sahip olan veri tabanındaki bütün objelerdeki istatistikleri toparlar. Maximum 4 saat olmak üzere gece saat 10’da çalışmaya başlar. Bu ayarları automatic maintaince tasks sayfasından default konfigurasyon değiştirilebilir.

Sistem istatistikleri I/O ve CPU performansı ve kullanımı gibi konularda sistemin donanım yapısını tanımlar. Bir execution plan seçerken, optimizer her sorgu için gerekli olan I/O ve CPU kaynaklarını tahmin eder. Sistem istatistikleri en doğru I/O ve CPU gereksinimlerini tahmin eder ve böylece daha iyi bir execution (çalışma) planı seçer. System istatistikleri DBMS_STATS.GATHER_SYSTEM_STATS paketi kullanılarak toparlanır. Oracle veri tabanı sistem istatistiklerini toplayacağı zaman, belirli zamanlarda sistem aktivitelerini analiz eder. System istatistikleri otomatik olarak toplanmaz. Oracle şirketi sistem istatistiklerini toplamak için DBMS_STATS paketini kullanmamızı tavsiye eder.

Eğer otomati istatistik toplamayı kullanmamayı seçersek, sonra manuel olarak sistem şemaları da dahil olmak üzere bütün şema istatistiklerini toplamamız gerekecektir. Veri tabanındaki veriler düzenli olarak değişmekteyse, ayrıca düzenli olarak istatistiklerin toplanması gerekmektedir. İstatistikleri manuel olarak toplamak için, DBMS_STATS paketi kullanılır. bu PL/SQL paketi ayrıca istatistikleri değiştirmek, görüntülemek, export etmek, import etmek ve silmek için kullanılabilir.

Veri tabanı başlangıç parametrelerini kullanarak optimizer ve istatistik toplama işlemlerini yönetebiliriz. Örneğin:

·         OPTIMIZER_DYNAMIC_SAMPLING parametresi optimizer tarafından gerçekleştirilen dinamik örnekleme düzeyini denetler. Tablo ve ilgili indexler için istatistikleri tahmin etmek için dinamik sampling (örnekleme: yani benzer başka bir tablodan örnek alma)  kullanılabilir.

·         STATISTICS_LEVEL parametresi tüm önemli istatistikleri koleksiyonları veya veritabanındaki uyarıların kontrol ve veritabanı istatistiklerini toplama düzeyini ayarlar. Bu parametre için değerler BASIC, TYPICAL ve ALL olarak atanır. Bu parametreler STATISTICAL_LEVELparameter tarafından etkilendiğini belirlemek için V $ STATISTICS_LEVELview sorgulayabilirsiniz.

 

Automatic olarak istatistikleri toplama özelliği, optimizer istatistiklerinin yönetiminin yükünü azaltmak için 10G ile bir- likte gelmiştir. Ancak 10G sürümünde bir başarı yakalayamadığı için kullanılamadı.

Yukarıdaki resim baz alındığında, yukarıdaki işlemlerin hepsini statement seviyesinde, table se viyesinde, şehma seviyesinde, database seviyesinde ve global seviyede yapabilmekteyiz.

İstatistik Tercihlerinin Kullanılması:

 

İstatistik tercihleri 11g ile birlikte gelen bir özelliktir. Normal şartlarda bir oracle veri tabanında bir veri tabanı objesinin, tablo içerisindeki satır sayısı %10 değişirse istatistik toplanır.

Yukarıdaki komutta ise SH kullanıcısının SALES tablosunun STALE_PERCENT parametresi değerini %10’dan %13 e çıkarılmış. 

 

Bu özellik obje ya da şema seviyesinde otomatik optimizer istatistik toplama görevi ve GATHER_*_STATS prosedurünün varsayılan hareket tarzını geçersiz yapan istatistik toplama seçeneklerini ilişkilenrmemizi sağlar.

Toplanan istatistiklerin seçeneklerini yönetmek için DBMS_STATS paketini kullanabiliriz.

 

Tablo, şema, veri tabanı ve global seviyede bu seçenekleri import, export, delete, alabilir ve ayarlayabiliriz. Global seçenekler seçeneklere sahip olmayan tablolar için kullanılır.

Oysaki veri tabanı ayarları bütün tablolardaki seçenekleri ayarlamak için kullanılır.

 

Global Seçenekleri Enterprise Manager ile Ayarlamak:

 

Enterprise Manager üzerinde global seçenekleri ayarlamak için server tabında, query optimizer altında manage optimizer statistics sayfasına gelerek, global statistics gethering options sayfasına gelinir.

İstenilen ayarlamalar yapılarak apply butonuna tıklanır ve ayarlama bitirilir.

Oracle Wait Event’lar:

 

Performans problemine yol açan, wait’ler enterprise ile detaylı bir şekilde monitör edilebilir.

Wait (bekleme): Aynı bloğu okumaya çalışan birden fazla sorgunun olması durumunda  library cache pin beklemesi çok fazla görülür.Yani cache’de bir bloğu veya blokları bir sorgu kullanıyor diğer sorgularda kuyruğa girmesi işlemine denir. Aynı bloğa iki farklı sessiondan sorgu geldiğinde lock oluşacaktır, bunun sonucunda wait orataya çıkacak. Enterprise managerde top activity’ye tıklanınca wait olduğunu göreceğizdir. Bu wait endeninin ne olduğunu ve kimin yaptığını görebilir ve müdahale edebiliriz. Ki bu konuya DBA1’de fazlasıyla değinmiştik. Ancak 9i sistemlerde enterprise manager olmadığı için komutlar kullanarak parametreler ile bu durumlar çözümlenebilir. Wait durumlarını biz çözmediğimiz sürece devam edecektir.

Enterprise Manager üzerinden Top Activity sayfası aşağıdaki gibidir.

 

Yukarıdaki sayfa Top Activity sayfasıdır ki bu sayfadan session’lara ait aktiviteleri çok rahat monitör edebilmekteyiz ve müdahale edebilmekteyiz. Bu sayfaya gelebilmek için performans tabına gelerek, top activity sayfasının linkini tıklarız.

Session ile ilgili İstatistikleri Görütülemek:

 

Session ile ilgili istatistikleri görüntülemek için V$SESSION view’ını sorgulayabiliriz. Örneğin, oturumun bir kullanıcı tarafındanmı ya da veri tabanı server process (background) tarafındanmı oluşturulup oluşturulmadığnı V$SESSION view’ın kullanarak öğrenebiliriz.

Aktif Session’larda beklemeler için eventlar ya da kaynakları belirlemek için V$SESSION_WAIT ya da V$SESSION viewları sorgulanabilir.

V$SESSTAT’daki kullanıcının session istatistiklerini görüntüleyebiliriz. V$SESSION_EVENT view’ı ise bir session tarafından event için wait’ler hakkındaki bilgileri lsiteler.

İnstance istatistikleri için cumulative (toplanmış) değerler V$SESSTAT ve V$SYSSTAT gibi dinamik performans view’ları genellikle kullanılır. Dinamik viewlardaki cumulative değerler veri tabanı instance kapandığında resetlenirler.

V$MYSTAT view’ı geçerli session’daki istatistikleri görüntüler.

Ayrıca bütün aktiv session’lar için performans metric değerlerini görüntülemek için V$SESSMETRIC view’ı sorgulanır. Performans metric CPU kullanımı, fiziksel okuma sayısı, harddisk bölümlemeleri gibi işlemlerdir.

Troubleshooting ve Tuning View’ları:

 

Yukarıda arkaplanda çalışan dinamik performans view’larıdır. Bunları bilmemiz gerekmektedir. Ancak bunların hepsini zaten enterprise manager üzerinden görebiliyoruz. Ancak unutulmamalıki enterprise manager’da da bu performans view’ları kullanılmakta. Bilmekte çok fayda vardır.

Dictionary View’ları:

Blirli database objelerinin optimizer istatsitiklerinin detaylarına bakmamız gerektiğinde, DBMS_STATS paketini kullanabiliriz.

Arka palanda DBA_TABLES veri tabanındaki bütün tabloları görüntüler, DBA_TAB_COLUMNS veri tabanındaki tablolardaki kolonları görüntüler, DBA_CLUSTERS cluster yapıları görüntüler, DBA_INDEXES veri tabanındaki index’leri görüntüler, DBA_TAB_HISTOGRAMS veri tabanındaki tabloların histogramlarını görüntüler. Yani aslına bakılırsa veri tabanındaki bütün herşey data dictionary view’larının içerisinde. Eğer DBMS_STATS paketini kullanacaksak, arkaplanda içrdeki tablolar, indexler, kolonlar vs. gibi obje ya da yapılar DBMS_STATS paketinin içerisine kullanmak zorundayız.

Automatic Workload Repository:

 

DBA1 de detaylı bir şekilde incelemiştik şimdi yine biraz bu konuya değineceğiz. Automatic Workload Repository (AWR) SYS kullanıcısına ait kalıcı sistem performans istatistiklerinin toplanmasıdır ve raporlanması işlemidir. AWR SYSAUX tablespaceinde bulunur.

Bu raporların hepsi her saat başı performans raporlarını alır. INTERVAL paramatresini değiştirerek bu süreyi uzata bilir ya da kısaltabiliriz. Ve bu snapshot’lar sonucunda Automatic Database Diagnostic Monitor (ADDM) bu snapshot’lar sonucunda bize advise (çözümler) sunmakta. ADDM’nin verdiği çözümleri yapmak ya da yapmamak bizim elimizde. Her bir snapshot AWR’deki unique olan snapshot sequence numarası(snap_id) ile tanımlanır. Çünkü veri tabanı danışmanları sistemde bir problem olduğunda bu snapshot’lara bakarak problemleri çözümler. Örneğin INTERVAL parametresi 4 saat olarak ayarlanırsa, 60 dakikalık bir sürede farkedilebilecek şeyleri gözden kaçırabiliriz. Snapshot toplamlarını kontrol eden ayarları değiştirmek için database control ya da DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS saklama prosedürünü kullanabiliriz.

Automatic Workload Repository View’larının Kullanımı:

• DBA_HIST_DB_CACHE_ADVICE • DBA_HIST_DISPATCHER • DBA_HIST_DYN_REMASTER_STATS • DBA_HIST_IOSTAT_DETAIL • DBA_HIST_SHARED_SERVER_SUMMARY

DBA_HIST_DB_CACHE_ADVICE her bir satıra ait cache size için fiziksel okumanın tarihsel tahminlerini görüntüler.

DB_HIST_DISPATCHER snapshot zamanında  her bir gönderici işlem için tarihsel bilgileri görüntüler.

DBA_HIST_DYN_DETAIL_STATS dinamik remastering process’i hakkında istatistiksel bilgileri görüntüler.

DBA_HIST_DYN_DETAIL fonksiyon ve dosya tipi tarafından tarihsel I/O birleşilerini görüntüler.

DBA_HIST_SHARED_SERVER_SUMMARY shared server aktivitesi, yaygın kuyruklar, ve gönderici kuyrukları gibi shared server için tarihsel bilgileri görüntüler.

Yukarıda bahsedilen view’ların hepsi 11g R2 ile birlikte gelimşitir.

Gerçek Ugulama Testleri Genel Bakış: Veri tabanı Tekrarı

 

Capture işlemi veri tabanından almak istediğimiz her şeyi almak işlemine denir. Bir nevi export etmek gibi işlemdir. Replay ise capture edilen şeyleri test veri tabanına deneme amaçlı ve ya geçiş amaçlı geçirme işlemine denir. Bir nevi import etmek gibi bir işlemdir. Software Support kısmında Database Replay ile yapılır.

Yapılacak işlem, Production sistemde client’ler, uygulama serverları falan var. Production sistemde bellibaşlı performans raporlarını ya da veri tabanı yapısını ya da parametreleri ya da memory ayarlamları gibi şeyleri belirli dosyalara işlenir. Alınan dosyalar diğer tarafta diğer test veri tabanına restor etmek işlemidir. Sonrasında test verit abanında istenilen her neyse monitör edilir. Bu işlem genelde bir üst versiyonu denemek için kullanılabilir. Yada veri tabanı ile ilgili her hangi yeniliği test etmek adına.

 

 

İsmail Aktaş

 

Kaynaklar

Oracle Eğitimi ve Kitapları

Internet