Selamlar,
Başlıktaki hata ile ilgili çok kısa bilgilendirmede bulunmak istiyorum;
# rman target / catalog rman_backup/backup@oracle_sid
Recovery Manager: Release 10.2.0.4.0 - Production on Fri Jul 2 10:31:15 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ABC (DBID=1921262300)
connected to recovery catalog database
RMAN> resync catalog;
-- Bu noktaya kadar herşey normal. recovery catalog veritabanına ve ana veritabanına bağlandık ve resync catalog gönderdik. Snapshot control dosyasını güncellemek isterken;
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
-- Bu hatanın nedeni bir başka bağlantının, resync catalog komutumuz ile aynı anda resync yapmaya çalışıyor olması. Bu ve bunun gibi hataları genelde çok almayacaksınız ancak eğer bir taraftan tape'ten data guard replikasyonu ile uğraşırken, diğer yandan da resync catalog komutunu gönderirseniz bu hatayı alırsınız. Çözülmesi için diğer bağlantıyı sonlandırdık. Devam edersek;
starting full resync of recovery catalog
full resync complete
RMAN>
İyi çalışmalar,
Ogan
2 Temmuz 2010 Cuma
30 Haziran 2010 Çarşamba
Physical Standby Automatic Archivelog Deletion / Maintenance
Selamlar,
Genelde yazılarımın başlıklarını Türkçe, içeriği Türkçe ve mümkün olan bütün kelimeleri de yine Türkçe yazmaya özen ve dikkat gösteriyorum. Ancak bu sefer başlığı İngilizce yazmamın nedeni birçok insanın İngilizce olarak arama yapması ancak Türkçe bulduğu zaman daha işlerine yaramasını sağlayabilmek. Etiket olarakta ayrıca ekledim.
Geçtiğimiz gün tarafıma iletilen bir soru üzerine çözüm ürettim ancak ürettiğim çözümün internet üzerinde, bu başlık ile ilişkilendirilmediğini gördüm. Konu şu; bir fiziksel veritabanımız var ve veritabanınızın v$archived_log fixed view'ını görüntülediğiniz zaman "applied" başlığı altındaki en güncel archivelog'un, fiziksel veritabanınıza işlendiğini gördünüz. v$dataguard_status view'ında da işler yolunda gidiyor. Peki bu oluşan archivelog'lar neden silinmiyor? Buradaki önemli sorulardan birisi budur aslında. Archivelog'ların bakımı (silinmesi, yedeklenmesi) ile ilgili inanılmaz boyutlarda soru - cevap internet üzerinde mevcut ancak data guard söz konusu olunca işler değişiyor.
Bunu sağlayabilmenin iki tane yolu var. Archivelog'ları Oracle'a otomatik olarak sildirtebilirsiniz ya da yedeği alınırken silinebilir. Her iki yolu da anlatacağım.
1) Archivelog'ların Oracle Tarafından Otomatik Olarak Silinmesi:
Bunu sağlayabilmek için 2 tane parametre tanımlamamız gerekiyor. Bir tanesi db_recovery_file_dest ve diğeri de db_recovery_file_dest_size. Bu parametreleri 10g için SGA_TARGET, 11g için MEMORY_TARGET gibi düşünebilirsiniz (mantık aynı, görevleri farklı). Oracle oluşan archivelog'ları tanımlamış olduğunuz db_recovery_file_dest alanına;
/db_recovery_file_dest/ORACLE_SID/archivelog/DATE/%arc_%s_%t şeklinde tanımlar. Buradaki archivelog formatını ise log_archive_format parametresi belirler. Oracle oluşan archivelog'ları gün gün ayırır, silinmesi gerekenleri siler. Silinmesi gerekenler nedir? db_recovery_file_dest_size parametresine tanımladığınız bilgi eğer %100'e yaklaşmış ise size uyarıda bulunur. Tepki vermezseniz kendisi otomatik olarak siler! Bu arada bu iki parametreyi de eğer spfile kullanıyorsanız dinamik olarak tanımlayabilirsiniz. (alter system ... scope=both);
Bu uyarının çıktısı ise şöyle olacaktır;
Errors in file /usr/ORACLE/u01/oracle/admin/smstby/udump/smstby_rfs_18686.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 97.09% used, and has 31258624 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Uyarının nedeni db_recovery_file_dest_size'ın neredeyse dolmuş olması. Yukarıdaki örnekte %97 dolu durumda gözüküyor. Peki bu 4 maddeyi yapmazsanız Oracle ne yapıyor? O da aşağıda;
Wed Jun 30 09:31:40 2010
RFS[13]: Archived Log: '/usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48375_62oqpf58_.arc'
Primary database is in MAXIMUM PERFORMANCE mode
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48372_62on259d_.arc
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48373_62oojwrq_.arc
Veritbanının devamlılığını sağlayabilmek için bu archivelog dosyalarını otomatik olarak siliyor.
Bu veritabanı için db_recovery_file_dest parametresini /usr/ORACLE/archive/SMSTBY/ olarak tanımladım ancak Oracle archivelog'ları /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/ altında oluşturdu. Bu da kendisinin yönettiğini gösteriyor. Bunu da yapabilmek için ilgili dizinde Oracle kullanıcısının (unix) okuma ve yazma hakkının olması gerekiyor. Bu bilgiyi işletim sistemi yöneticisinden alabilirsiniz.
2) RMAN ile Archivelog'ların Silinmesi:
Bir diğer yöntem ise her zaman geçerli olan Recovery Manager ile archivelog'ların yedeklenmesi. Bu başlıkta kendi içerisinde ikiye ayrılabilir. Birincisi kişinin *nix üzerinde oluşan archivelog'ları elle silmesi, diğer de bu log'ları RETENTION PERIOD belirleyerek "obsolete" hale getirerek Recovery Manager tarafından sildirmesi. Ben ikinci yolu her zaman daha olumlu buluyorum çünkü elle silindiği zaman ek işler ve masraf devreye giriyor.
Elle sildiğimiz zaman bunu Oracle'a bildirmek zorundayız. Oracle otomatik olarak bu archivelog'ların silindiğini anlayamaz. Yedekleme yaparken hata alırsınız ve yedeklemeye çalışır sonra da bulamıyorum der. Bunun için;
RMAN> crosscheck archivelog all;
Komutunu amacı archivelog'ları Oracle'a göstertmek ve varlığını öğretmek. Crosscheck komutundan sonra "obsolete" archivelog'ları silebilmek için;
RMAN> delete noprompt obsolete;
Bu yöntemler eski archivelog'lardan kurtulabilirsiniz. Diğer yöntemde ise recovery catalog değil de control dosyasını yedek listelemede kullandığınızı varsayıyorum. Control dosyasının yedek bilgilerini tuttuğunu ve aşağıdaki parametreye göre bakımını yapması gerektiğini söyleyebilirim;
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Yukarıdaki komut aldığınız yedeklerin, archivelog'ların vb. 7 gün boyunca "expired" ya da "obsolete" olmayacağını garanti eder.
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;
Yukarıdaki komut ise aldığınız 5 tane veritabanı yedeğinden sonraki 6ncı ile birlikte, 1ncinin "expired" yani aslında kullanılamaz olarak etiketlenmesini sağlar.
Peki bu komutların standby archivelog'ları ile ne ilgisi var? Bir diğer parametrenin tanımlanması ile;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Varsayılan değeri NONE olan yukarıdaki parametreyi APPLIED ON STANDBY ile değiştirirseniz eğer "obsolete" olan archivelog'lar yedekleme sırasında standby veritabanından silinecektir.
Eğer yedekleme işlemini birincil veritabanında yapıyorsanız;
Birincil veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
Yedek veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Eğer yedeklemeyi yedek veritabanında yapıyorsanız;
Birincil veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Yedek veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
Oracle dokümantasyonuna göre (11g) yedekleme işlemine gerek kalmadan, APPLIED ON STANDBY derseniz mantıksal ya da fiziksel yedeğin archivelog'ları silinecektir.
Yukarıdaki genel bilgiler ışığında benim tercih ettiğim method ilk olarak anlattığım. "Flash recovery area" bilgisinin tanımlanmış olması önemli bir kriter zira birçok veritabanı archivelog'ların şişmesi ve eksik bakım yapıldığından çökebiliyor. Ölümcül bir hata değil, veritabanı bir süre daha varlığını devam ettirebiliyor ancak bir süre sonra ARCHn görevi ölüyor ve archive alınması işlemini veritabanı terk ediyor. Bu durumda veritabanını kapatmanız, archivelog'ların artık bulunmadığını Oracle'a öğretmeniz (eğer elle silmişseniz) ve veritabanını yeniden açmanız gerekecektir.
İyi çalışmalar,
Ogan
Genelde yazılarımın başlıklarını Türkçe, içeriği Türkçe ve mümkün olan bütün kelimeleri de yine Türkçe yazmaya özen ve dikkat gösteriyorum. Ancak bu sefer başlığı İngilizce yazmamın nedeni birçok insanın İngilizce olarak arama yapması ancak Türkçe bulduğu zaman daha işlerine yaramasını sağlayabilmek. Etiket olarakta ayrıca ekledim.
Geçtiğimiz gün tarafıma iletilen bir soru üzerine çözüm ürettim ancak ürettiğim çözümün internet üzerinde, bu başlık ile ilişkilendirilmediğini gördüm. Konu şu; bir fiziksel veritabanımız var ve veritabanınızın v$archived_log fixed view'ını görüntülediğiniz zaman "applied" başlığı altındaki en güncel archivelog'un, fiziksel veritabanınıza işlendiğini gördünüz. v$dataguard_status view'ında da işler yolunda gidiyor. Peki bu oluşan archivelog'lar neden silinmiyor? Buradaki önemli sorulardan birisi budur aslında. Archivelog'ların bakımı (silinmesi, yedeklenmesi) ile ilgili inanılmaz boyutlarda soru - cevap internet üzerinde mevcut ancak data guard söz konusu olunca işler değişiyor.
Bunu sağlayabilmenin iki tane yolu var. Archivelog'ları Oracle'a otomatik olarak sildirtebilirsiniz ya da yedeği alınırken silinebilir. Her iki yolu da anlatacağım.
1) Archivelog'ların Oracle Tarafından Otomatik Olarak Silinmesi:
Bunu sağlayabilmek için 2 tane parametre tanımlamamız gerekiyor. Bir tanesi db_recovery_file_dest ve diğeri de db_recovery_file_dest_size. Bu parametreleri 10g için SGA_TARGET, 11g için MEMORY_TARGET gibi düşünebilirsiniz (mantık aynı, görevleri farklı). Oracle oluşan archivelog'ları tanımlamış olduğunuz db_recovery_file_dest alanına;
/db_recovery_file_dest/ORACLE_SID/archivelog/DATE/%arc_%s_%t şeklinde tanımlar. Buradaki archivelog formatını ise log_archive_format parametresi belirler. Oracle oluşan archivelog'ları gün gün ayırır, silinmesi gerekenleri siler. Silinmesi gerekenler nedir? db_recovery_file_dest_size parametresine tanımladığınız bilgi eğer %100'e yaklaşmış ise size uyarıda bulunur. Tepki vermezseniz kendisi otomatik olarak siler! Bu arada bu iki parametreyi de eğer spfile kullanıyorsanız dinamik olarak tanımlayabilirsiniz. (alter system ... scope=both);
Bu uyarının çıktısı ise şöyle olacaktır;
Errors in file /usr/ORACLE/u01/oracle/admin/smstby/udump/smstby_rfs_18686.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 1073741824 bytes is 97.09% used, and has 31258624 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Uyarının nedeni db_recovery_file_dest_size'ın neredeyse dolmuş olması. Yukarıdaki örnekte %97 dolu durumda gözüküyor. Peki bu 4 maddeyi yapmazsanız Oracle ne yapıyor? O da aşağıda;
Wed Jun 30 09:31:40 2010
RFS[13]: Archived Log: '/usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48375_62oqpf58_.arc'
Primary database is in MAXIMUM PERFORMANCE mode
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48372_62on259d_.arc
Deleted Oracle managed file /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/o1_mf_1_48373_62oojwrq_.arc
Veritbanının devamlılığını sağlayabilmek için bu archivelog dosyalarını otomatik olarak siliyor.
Bu veritabanı için db_recovery_file_dest parametresini /usr/ORACLE/archive/SMSTBY/ olarak tanımladım ancak Oracle archivelog'ları /usr/ORACLE/archive/SMSTBY/flash_recovery_area/SMSTBY/archivelog/2010_06_30/ altında oluşturdu. Bu da kendisinin yönettiğini gösteriyor. Bunu da yapabilmek için ilgili dizinde Oracle kullanıcısının (unix) okuma ve yazma hakkının olması gerekiyor. Bu bilgiyi işletim sistemi yöneticisinden alabilirsiniz.
2) RMAN ile Archivelog'ların Silinmesi:
Bir diğer yöntem ise her zaman geçerli olan Recovery Manager ile archivelog'ların yedeklenmesi. Bu başlıkta kendi içerisinde ikiye ayrılabilir. Birincisi kişinin *nix üzerinde oluşan archivelog'ları elle silmesi, diğer de bu log'ları RETENTION PERIOD belirleyerek "obsolete" hale getirerek Recovery Manager tarafından sildirmesi. Ben ikinci yolu her zaman daha olumlu buluyorum çünkü elle silindiği zaman ek işler ve masraf devreye giriyor.
Elle sildiğimiz zaman bunu Oracle'a bildirmek zorundayız. Oracle otomatik olarak bu archivelog'ların silindiğini anlayamaz. Yedekleme yaparken hata alırsınız ve yedeklemeye çalışır sonra da bulamıyorum der. Bunun için;
RMAN> crosscheck archivelog all;
Komutunu amacı archivelog'ları Oracle'a göstertmek ve varlığını öğretmek. Crosscheck komutundan sonra "obsolete" archivelog'ları silebilmek için;
RMAN> delete noprompt obsolete;
Bu yöntemler eski archivelog'lardan kurtulabilirsiniz. Diğer yöntemde ise recovery catalog değil de control dosyasını yedek listelemede kullandığınızı varsayıyorum. Control dosyasının yedek bilgilerini tuttuğunu ve aşağıdaki parametreye göre bakımını yapması gerektiğini söyleyebilirim;
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Yukarıdaki komut aldığınız yedeklerin, archivelog'ların vb. 7 gün boyunca "expired" ya da "obsolete" olmayacağını garanti eder.
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;
Yukarıdaki komut ise aldığınız 5 tane veritabanı yedeğinden sonraki 6ncı ile birlikte, 1ncinin "expired" yani aslında kullanılamaz olarak etiketlenmesini sağlar.
Peki bu komutların standby archivelog'ları ile ne ilgisi var? Bir diğer parametrenin tanımlanması ile;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Varsayılan değeri NONE olan yukarıdaki parametreyi APPLIED ON STANDBY ile değiştirirseniz eğer "obsolete" olan archivelog'lar yedekleme sırasında standby veritabanından silinecektir.
Eğer yedekleme işlemini birincil veritabanında yapıyorsanız;
Birincil veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
Yedek veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Eğer yedeklemeyi yedek veritabanında yapıyorsanız;
Birincil veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
Yedek veritabanında;
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
Oracle dokümantasyonuna göre (11g) yedekleme işlemine gerek kalmadan, APPLIED ON STANDBY derseniz mantıksal ya da fiziksel yedeğin archivelog'ları silinecektir.
Yukarıdaki genel bilgiler ışığında benim tercih ettiğim method ilk olarak anlattığım. "Flash recovery area" bilgisinin tanımlanmış olması önemli bir kriter zira birçok veritabanı archivelog'ların şişmesi ve eksik bakım yapıldığından çökebiliyor. Ölümcül bir hata değil, veritabanı bir süre daha varlığını devam ettirebiliyor ancak bir süre sonra ARCHn görevi ölüyor ve archive alınması işlemini veritabanı terk ediyor. Bu durumda veritabanını kapatmanız, archivelog'ların artık bulunmadığını Oracle'a öğretmeniz (eğer elle silmişseniz) ve veritabanını yeniden açmanız gerekecektir.
İyi çalışmalar,
Ogan
23 Haziran 2010 Çarşamba
Automatic Workload Repository & Create Snapshot
Merhabalar,
Oracle 10g ile birlikte aramıza katılan bir özellik olan Automatic Workload Repository (AWR), diagnostic pack bedelini ödediğiniz zaman kullanabileceğiniz bir özelliktir. AWR ve statspack farklı araçlardır ancak amaçları aynıdır ve istenildiği zaman statspack kullanımı yine söz konusudur.
Bugün bahsetmek istediğim konu bu raporları elle nasıl yaratabiliriz? Oracle aslında bizim için bunu her saat başı yapıyor ve sistemi kontrol edebilmemiz bir bize bir AWR raporu sunuyor. Bu noktada çok kısa bahsetmek istiyorum ki AWR dışında bir de ADDM denen bir kavram vardır, yani Automatic Database Diagnostic Monitor. ADDM'in amacı AWR raporlarını inceleyerek, bize taleplerde bulunması. Örneğin AWR raporunda bir SQL veritabanını çok fazla yormuş. ADDM bu SQL'i inceleyerek bize; tablo üzerinde index mi yaratmalıyız, index var ancak bitmap olmalı ya da yeni bir SQL profili geliştirmek gibi faydalı bilgiler sunar.
Gelelim konumuza. AWR raporlarını genelde enterprise manager (EM) aracılığı ile kontrol edebilirsiniz. Ancak bazı durumlarda saatlik alınan AWR raporunu okumayı değil, kendi aldığınız AWR raporunu incelemeyi tercih edebilirsiniz. Bunu tercih etmenizdeki en büyük etken ise o andaki performans problemlerini teşhis edebilmek olabilir.
Aşağıdaki komut ile manuel olarak snapshot'ımızı alabiliriz;
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
Ya da
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
Bir snapshot aralığını silmek ve veritabanının bilgisinden çıkartmak isterseniz eğer;
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 1, high_snap_id => 10 dbid => 1921262300);
END;
/
Peki bu noktada şöyle bir soru sorabilirsiniz; "Neden AWR raporları Oracle tarafından her saatinde başında alınmakta ve bunu değiştiremez miyiz?" Cevap, evet değiştirebilirsiniz. Hemen bir örnek göstereyim;
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 14400,
interval => 15, dbid => 1921262300);
END;
/
Retention period değeri AWR raporunun kaç gün boyunca saklanacağını, internal değeri ise kaç dakikada bir snapshot alınması gerektiğini temsil etmektedir. Daha sık ya da daha geç AWR raporu görmek isterseniz eğer yukarıdaki MODIFY_SNAPSHOT_SETTINGS sizin için biçilmiş kaftan diyebilirim.
DBA_HIST_WR_CONTROL data dictionary view'u ise size veritabanınızın AWR ayarlarını gösterecektir. MODIFY_SNAPSHOT_SETTINGS ile herhangi bir değişikliği yerine getirmeniz durumunda DBA_HIST_WR_CONTROL view'unu sorgulayarak en son halini görüntüleyebilirsiniz.
AWR snapshot'larını aldıktan sonra da awrrpt.sql isimli script'i koşmanız gerekiyor. Bu script'in amacı size bir AWR raporu hazırlamak.
awrrpt.sql scripti ise aşağıdaki dizinde bulunmaktadır;
$ORACLE_HOME/rdbms/admin/
Bu script'i çalıştırmak için;
cd $ORACLE_HOME/rdbms/admin/
sqlplus / as sysdba
SQL> @awrrpt.sql
İyi çalışmalar,
Ogan
Oracle 10g ile birlikte aramıza katılan bir özellik olan Automatic Workload Repository (AWR), diagnostic pack bedelini ödediğiniz zaman kullanabileceğiniz bir özelliktir. AWR ve statspack farklı araçlardır ancak amaçları aynıdır ve istenildiği zaman statspack kullanımı yine söz konusudur.
Bugün bahsetmek istediğim konu bu raporları elle nasıl yaratabiliriz? Oracle aslında bizim için bunu her saat başı yapıyor ve sistemi kontrol edebilmemiz bir bize bir AWR raporu sunuyor. Bu noktada çok kısa bahsetmek istiyorum ki AWR dışında bir de ADDM denen bir kavram vardır, yani Automatic Database Diagnostic Monitor. ADDM'in amacı AWR raporlarını inceleyerek, bize taleplerde bulunması. Örneğin AWR raporunda bir SQL veritabanını çok fazla yormuş. ADDM bu SQL'i inceleyerek bize; tablo üzerinde index mi yaratmalıyız, index var ancak bitmap olmalı ya da yeni bir SQL profili geliştirmek gibi faydalı bilgiler sunar.
Gelelim konumuza. AWR raporlarını genelde enterprise manager (EM) aracılığı ile kontrol edebilirsiniz. Ancak bazı durumlarda saatlik alınan AWR raporunu okumayı değil, kendi aldığınız AWR raporunu incelemeyi tercih edebilirsiniz. Bunu tercih etmenizdeki en büyük etken ise o andaki performans problemlerini teşhis edebilmek olabilir.
Aşağıdaki komut ile manuel olarak snapshot'ımızı alabiliriz;
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
Ya da
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
Bir snapshot aralığını silmek ve veritabanının bilgisinden çıkartmak isterseniz eğer;
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 1, high_snap_id => 10 dbid => 1921262300);
END;
/
Peki bu noktada şöyle bir soru sorabilirsiniz; "Neden AWR raporları Oracle tarafından her saatinde başında alınmakta ve bunu değiştiremez miyiz?" Cevap, evet değiştirebilirsiniz. Hemen bir örnek göstereyim;
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 14400,
interval => 15, dbid => 1921262300);
END;
/
Retention period değeri AWR raporunun kaç gün boyunca saklanacağını, internal değeri ise kaç dakikada bir snapshot alınması gerektiğini temsil etmektedir. Daha sık ya da daha geç AWR raporu görmek isterseniz eğer yukarıdaki MODIFY_SNAPSHOT_SETTINGS sizin için biçilmiş kaftan diyebilirim.
DBA_HIST_WR_CONTROL data dictionary view'u ise size veritabanınızın AWR ayarlarını gösterecektir. MODIFY_SNAPSHOT_SETTINGS ile herhangi bir değişikliği yerine getirmeniz durumunda DBA_HIST_WR_CONTROL view'unu sorgulayarak en son halini görüntüleyebilirsiniz.
AWR snapshot'larını aldıktan sonra da awrrpt.sql isimli script'i koşmanız gerekiyor. Bu script'in amacı size bir AWR raporu hazırlamak.
awrrpt.sql scripti ise aşağıdaki dizinde bulunmaktadır;
$ORACLE_HOME/rdbms/admin/
Bu script'i çalıştırmak için;
cd $ORACLE_HOME/rdbms/admin/
sqlplus / as sysdba
SQL> @awrrpt.sql
İyi çalışmalar,
Ogan
Kaydol:
Kayıtlar (Atom)