İş Zekası Tarihe göre etiket öğelerini görüntüle: oltp
Automatic Workload Repository (AWR) Raporlarının Compare Edilmesi
Bundan önceki yazımda AWR’ ın kullanımı ile giriş yaparak, AWR aracılığı ile snaphotları nasıl create, drop ederizden bahsettik. Şimdi alınan bu snaphotlara ait raporları nasıl compare ederiz buna bakacağız. Özetle şunu yapmaya çalışıyoruz aslında database’ de yaşanan bir performans probleminin ne boyutta olduğuna veya aynı dönemi kapsayan başka bir aralığa göre problemin neden kaynaklandığını, yoğunluk olarak hangi alanlarda artış olduğunu görebilmek ve içinde bulunduğumuz durumu daha iyi yorumlayabilmek için karşılaştırma yapabiliriz.
Şöyle bir problem olduğunu varsayalım. Her gün saat 09:00 ile 11:00 arasında database’ imizin performansı stabil iken, gün içerisinde bu saatler aralığında performansın ciddi bir şekilde düştüğünü varsayalım. Buradaki sorunu tespit içinde dün ile bugün aynı saatler aralığını gösteren AWR raporlarını compare etmeye çalışalım. (bu işlemi konsol üzerinden grafik ekranda çok rahatlıkla yapabilirsiniz ancak biz ortada bir problem var iken konsolun çalışmama riskini gözönünde bulundurarak komut satırından yapmaya çalışacağız)
Bu işlemler için dba yetkisi gerektiğini tekrar hatırlatalım.
Komut satırından scriptimizin yer aldığı awrddrpt.sql dosyasını çalıştırıyoruz.
@$ORACLE_HOME/rdbms/admin/awrddrpt.sql
Sonrasında yapılan işlemlerle ilgili loglarıda ekliyorum ;
SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Id DB Name Inst Num Inst Num Instance
----------- ----------- ------------ -------- -------- ------------
2656835042 2656835042 TEST 1 1 TEST
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: text
Type Specified: text
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 2656835042 1 TEST TEST tester
Database Id and Instance Number for the First Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using 2656835042 for Database Id for the first pair of snapshots
Using 1 for Instance Number for the first pair of snapshots
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing without
specifying a number lists all completed snapshots.
Enter value for num_days: 2
Listing the last 2 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
TEST TEST 6480 22 Feb 2011 00:00 1
6481 22 Feb 2011 01:00 1
6482 22 Feb 2011 02:00 1
6483 22 Feb 2011 03:00 1
6484 22 Feb 2011 04:00 1
6485 22 Feb 2011 05:00 1
6486 22 Feb 2011 06:00 1
6487 22 Feb 2011 07:00 1
6488 22 Feb 2011 08:00 1
6489 22 Feb 2011 09:00 1
6490 22 Feb 2011 10:00 1
6491 22 Feb 2011 11:00 1
6492 22 Feb 2011 12:00 1
6493 22 Feb 2011 12:48 1
6494 22 Feb 2011 12:48 2
6496 22 Feb 2011 14:00 1
6497 22 Feb 2011 15:00 1
6498 22 Feb 2011 16:00 1
6499 22 Feb 2011 17:00 1
6500 22 Feb 2011 18:00 1
6501 22 Feb 2011 19:00 1
6502 22 Feb 2011 20:00 1
6503 22 Feb 2011 21:00 1
6504 22 Feb 2011 22:00 1
6505 22 Feb 2011 23:00 1
6506 23 Feb 2011 00:00 1
6507 23 Feb 2011 01:00 1
6508 23 Feb 2011 02:00 1
6509 23 Feb 2011 03:00 1
6510 23 Feb 2011 04:00 1
6511 23 Feb 2011 05:00 1
6512 23 Feb 2011 06:00 1
6513 23 Feb 2011 07:00 1
6514 23 Feb 2011 08:00 1
6515 23 Feb 2011 09:00 1
6516 23 Feb 2011 10:00 1
6517 23 Feb 2011 11:00 1
6518 23 Feb 2011 12:00 1
6519 23 Feb 2011 13:00 1
6520 23 Feb 2011 14:00 1
6521 23 Feb 2011 15:00 1
6522 23 Feb 2011 16:00 1
Specify the First Pair of Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 6489
First Begin Snapshot Id specified: 6489
Enter value for end_snap: 6491
First End Snapshot Id specified: 6491
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 2656835042 1 TEST TEST tester
Database Id and Instance Number for the Second Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using 2656835042 for Database Id for the second pair of snapshots
Using 1 for Instance Number for the second pair of snapshots
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing without
specifying a number lists all completed snapshots.
Enter value for num_days2: 2
Listing the last 2 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
TEST TEST 6480 22 Feb 2011 00:00 1
6481 22 Feb 2011 01:00 1
6482 22 Feb 2011 02:00 1
6483 22 Feb 2011 03:00 1
6484 22 Feb 2011 04:00 1
6485 22 Feb 2011 05:00 1
6486 22 Feb 2011 06:00 1
6487 22 Feb 2011 07:00 1
6488 22 Feb 2011 08:00 1
6489 22 Feb 2011 09:00 1
6490 22 Feb 2011 10:00 1
6491 22 Feb 2011 11:00 1
6492 22 Feb 2011 12:00 1
6493 22 Feb 2011 12:48 1
6494 22 Feb 2011 12:48 2
6496 22 Feb 2011 14:00 1
6497 22 Feb 2011 15:00 1
6498 22 Feb 2011 16:00 1
6499 22 Feb 2011 17:00 1
6500 22 Feb 2011 18:00 1
6501 22 Feb 2011 19:00 1
6502 22 Feb 2011 20:00 1
6503 22 Feb 2011 21:00 1
6504 22 Feb 2011 22:00 1
6505 22 Feb 2011 23:00 1
6506 23 Feb 2011 00:00 1
6507 23 Feb 2011 01:00 1
6508 23 Feb 2011 02:00 1
6509 23 Feb 2011 03:00 1
6510 23 Feb 2011 04:00 1
6511 23 Feb 2011 05:00 1
6512 23 Feb 2011 06:00 1
6513 23 Feb 2011 07:00 1
6514 23 Feb 2011 08:00 1
6515 23 Feb 2011 09:00 1
6516 23 Feb 2011 10:00 1
Automatic Workload Repository (AWR) Nedir, Nasıl Alınır ?
Bugün database' in performansı ile ilgili belli aralıklarla alınmakta olan snapshotların, bizler için ne ifade ettiğinden, nasıl alınabileceğinden, çalışma şeklinden ve nasıl configure edileceğinden bahsetmek istiyorum.
Automatic Workload Repository (AWR), problemi tespit etmek ve self-tuning yapabilmek amacıyla istatistik toplar. Toplanan bu istastikler ise hem memoryde hem de veritabanında saklanır.
AWR istatistikleri neleri içerir, nelerden oluşur ;
* * Erişim ve kullanım istatistiklerini belirlemek için Object İstatistikleri,
* * Session bazında, zaman modelli istatistikleri (ki alınan bu istatistikleri V$SYS_TIME_MODEL ve V$SESS_TIME_MODEL viewlerinden görebiliriz.)
* * Bazı system ve session istatistiklerini, (bu istatistikleride V$SYSSTAT and V$SESSTAT viewlerinden izleyebiliriz)
* * System üzerinde çalışma süresi ve CPU kullanımında top olan sql statmentları ile ilgili istatistikleri,
* * ASH istastikleri, son sesessionlara ait işlemler ile ilgili istastikleri
İçerir.
Database istatistikleri AWR aracılığıyla toplanır ve defaultunda enable olarak gelir ve bu opsiyon Statistics_level inital parametsiyle kontrol edilir. Awr’ ın çalışabilmesi için statistic_level parametresi mutlaka TYPICAL veya ALL olarak set edilmelidir. Defaultunda Typical olarak geldiği içinde AWR’ ın defaultu enable’ dır. Bu değer BASIC olarak set edildiğinde artık database’ in istatistikleri toplanmayacağı anlamına gelmektedir. (AWR disable olacağından) Bu parametrenin BASIC olması performans açısından da (tabloların zaman içerisinde structure’ ları, size’ ları, indexleri değişeceğinden, çalışan sql’ lere ait execution planları da zamanla yanlış ve yavaş çalışmaya başlayacağından) olumsuz sonuçlar doğuracaktır. Dolayısıyla bu önerilen bir durum değildir. AWR, database’ in istatistiklerini belirli periyodlarda otomatik olarak alır, eğer statistics_level parametresi BASIC ise yani AWR disable ise, manuel olarak DBMS_WORKLOAD_REPOSITORY package’ ı kullanılarak AWR istatistikleri alabilirsiniz. Ancak system istatistiklerinin büyük bir kısmı (segment istatistikleri ve memory advisor bilgileri gibi) disable olacağından anlık olarak alınmaya çalışılan istatistikler tam olmayabilir.
Ne olduğundan bahsettik, şimdi biraz da Automatic Workload Repository ile ilgili kavramlar üzerinde duralım biraz, sonrasında yönetimi ile devam edeceğiz ;
* * Snapshots ;
Snapshots, ADDM tarafından performans karşılaştırmaları yapmak için kullanılan, belirli bir zaman aralığına ait verilerin history bilgisini turarlar. Oracle’ ın kurulumu ile birlikte default olarak her saat başında otomatik olarak çalışır ve saat başında alınan bu snapshot’ larıda 8 gün boyunca saklar. Saat başında otomatik olarak alınmasının yanında, istenildiği anda manuel olarak da snapshot alınabilir. AWR tarafından alınan snapshotlar, Automic Database Diagnostic Monitor (AADDM) tarafında da otomatik olarak incelenmektedir.
AWR raporları, iki dönem arasındaki performansı karşılaştırarak, performans kaybına yol açan sql statementlarının tespit edilmesine yardımcı olur. Oracle 10g ile birlikte tanışmış olduğumuz AWR ve ADDM, kullanıcılardan performans ile ilgili şikayetlerin arttığı zamanlarda sorunun tespiti açısından ciddi rol oynamaktadırlar.
* * Baselines ;
Baseline, belli bir zaman aralığındaki performans ile ilgili dataları içerir.
* * Adaptive Thresholds
Adaptive thresholds’ lar performans ile ilgili sorunları tespit ve monitor etmeye yardımcı olur. Bunu, tanımlayacağınız thresholdlar da otomatik olarak warning/critical alert seviyeleri bazında yapabiliriz.
Atomatic Workload Repository Yönetimi
* * Snapshot Yönetimi
Oracle database kurulumu ile birlikte default olarak her saat başı otomatik olarak snaphot’ ların alınmaktadır. Alınan bu snapshotların saklanmasıda default olarak 8 gün dür. İhtiyaç halinde DBMS_WORKLOAD_REPOSITORY package’ı ile manuel olarak snapshot create, drop veya edit edebiliriz. Bu package kullanabilmek için user’ ın DBA yetkisine sahip olmalıdır. Manuel olarak snapshot create – drop edilmesi işlemi özellikle enterprise manager konsolu kullanamadığımız durumlarda (ki kimiz zaman sistemde yaşanan problemlerden dolayı zaman zaman konsolu kullanamayabiliyoruz) ciddi önemli olduğu durumlarla karşılaşabiliriz. Dolayısıyla sadece bu işlem için değil, database seviyesinde yapacağımız tüm işlemlerin sql komutları ile nasıl yapıldıklarını bilmemiz zaman zaman hayati önem taşıyabiliyor.
Manuel olarak bahsettiğimiz bu işlemleri şimdi sırası ile nasıl yapabileceğimize bakalım;
(aşağıda belirtilen işlemlerin aynısı konsol üzerinden de yapılabilir ben burada sadece konsolu kullanmadan nasıl yapabileceğimiz üzerinde duracağım)
Manuel Snapshot create etmeye çalışalım;
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
PL/SQL procedure successfully completed
Yukarıdaki scriptte snapshot kısmında sonraki “()” alanı doldurmadan direk çalıştırdık. Buraya TYPICAL veya ALL da yazabilirdik. Null olarak gönderdiğimizde statistic_level parametreniz ne olarak set etmişseniz onu dikkate alıyor.
Şimdi almış olduğum son snapshot’ ı drop etmek isteyelim ;
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 6495,
high_snap_id => 6495, dbid => 2656835042);
END;
/
PL/SQL procedure successfully completed
Bu şekilde sadece seçmiş olduğunuz snapshotı drop edebileceğiniz gibi bir aralık içerisindeki tüm snapshotlarıda drop edebilirsiniz.
Snapshot ayarlarını modify etmeye çalışalım ;
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, topnsql => 100, dbid => 3310949047);
END;
/
PL/SQL procedure successfully completed
Yapılan bu değişikliği şöyle tanımlayabiliriz; retention parametresi ile alınan snapshotların saklanma süresi 43200 dakikaya yani 30 güne, interval 30 ile snapshot alınma sıklığı 30 dak’ ya, topnsql 100 ile snapshotlara dikkate alınanacak top sql sayısı 100’ e set edilmektedir. Dbid parametresi ise üzerinde işlem yapmakta olduğunuz database’ in dbis’ sini ifade etmektedir. (select dbid from v$database ile bulunabilir)
Snapshot ayarları ile ilgili yapmış olduğunuz bu değişiliklerin history’ si neDBA_HIST_WR_CONTROL view’ ini select ederek görebilirsiniz.
select * from sys.DBA_HIST_WR_CONTROL
DBID SNAP_INTERVAL RETENTION TOPNSQL
2040370613 +00 01:00:00.000000 +07 00:00:00.000000 DEFAULT
AWR ile tüm testleri 11gR2 ortamında yaptığımdan dolayı farklı versiyonlarda bu selectin sonuçu farklı çıkacaktır. (örneğin 10gR2 de topnsql alanı olmayacaktır)
* * Baseline Yönetimi
Baseline’ lar sistemin optimum olarak çalıştığı bir dönemde create edilip problem oluştuğu dönemde nelerin problem teşkil ettiğini yani iki dönem arasındaki farkı ne olarak görebilmek için alınır. (veya yoğun dönemlerde oluşturulup başka bir aralık ile karşılaştırmamıza olanak sağlar) Baseline’ da iki şekilde create edebiliriz. Konsol üzerinden ve DBMS_WORKLOAD_REPOSITORY package’ ını kullanarak. Package ile nasıl create, drop veya modify baseline yapabiliriz bunlara bakalım kısaca;
create etmek için ;
öncelikle hangi aralığa ait snapshotları kullanarak baseline create edeceğiz buna kara veriyoruz. Aşağıdaki sql’ den mevcut snapshotlara bakabiliriz;
select * from DBA_HIST_SNAPSHOT ;
sonra ;
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 6517,
end_snap_id => 6518, baseline_name => 'deneme baseline',
dbid => 2656835042, expiration => 30);
END;
PL/SQL procedure successfully completed
Artık oluşturmuş olduğumuz yeni baseline’ nıda ;
select * from DBA_HIST_BASELINE
view’ inde görebiliyoruz.
Create scriptinde expiration parametresini null gönderirseniz asla expire olmayacak demiş olursunuz.bizim bu örneğimizde 30 olarak set etmiş olduk.
Drop etmek için ;
Aynı mantıkda, hangi baseline’ i drop etmek istediğimize DBA_HIST_BASELINEtablosundan bakıp karar veriyoruz. (tabi eğer bilmiyorsak)
Sonra;
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'deneme baseline',
cascade => FALSE, dbid => 2656835042);
END;
PL/SQL procedure successfully completed
Ile drop edebiliriz.
Daha önce alınmış olan bir baseline’ nın adını rename etmek için ;
BEGIN
DBMS_WORKLOAD_REPOSITORY.RENAME_BASELINE (
old_baseline_name => 'deneme baseline',
new_baseline_name => 'dene baseline',
dbid => 2656835042);
END;
PL/SQL procedure successfully completed
Ile yapabiliriz.
İşinize yarayacağını düşündüğüm bazı Automatic Workload Repository ile ilgili wievler ;
V$ACTIVE_SESSION_HISTORY = Database’ deki active sessionlara ait bilgilerin turulduğu view,
DBA_HIST_ACTIVE_SESS_HISTORY = memorydeki en son system aktivitelerine ait bilgileri içerir,
DBA_HIST_BASELINE = database’ deki baseline’ leri listeler,
DBA_HIST_BASELINE_DETAILS = baseline’ lar hakkında detaylı bilgileri içerir,
DBA_HIST_BASELINE_TEMPLATE = system tarafından generate edilen baseline template’ leri hakkında bilgiler içerir,
DBA_HIST_DATABASE_INSTANCE = database environment’ ları hakkında bilgileri içeir,
DBA_HIST_SNAPSHOT = database’deki snapshotlar hakkında bilgileri içerir,
DBA_HIST_WR_CONTROL = AWR’ ın kontrol ayarları ile ilgili bilgileri içerir.
AWR raporu create etmek için ;
Yine konsolu kullanmadan awr raporu create etmek için aşağıdaki adımları izleyebiliriz. Tabi bunları yapan kullanıcının dba yetkisine sahip olması gerektiğini de unutmayalım.
Sql komut satırıdan aşağıdaki sql dosyasını çağırıyoruz;
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
[ admin]$ sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 14:43:32 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>
SQL>
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql;
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
2656835042 TEST 1 TEST
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: html
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 2656835042 1 TEST TEST tester1
Using 2656835042 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing without
specifying a number lists all completed snapshots.
Enter value for num_days: 1
Listing the last day's Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
TEST TEST 6506 23 Feb 2011 00:00 1
6507 23 Feb 2011 01:00 1
6508 23 Feb 2011 02:00 1
6509 23 Feb 2011 03:00 1
6510 23 Feb 2011 04:00 1
6511 23 Feb 2011 05:00 1
6512 23 Feb 2011 06:00 1
6513 23 Feb 2011 07:00 1
6514 23 Feb 2011 08:00 1
6515 23 Feb 2011 09:00 1
6516 23 Feb 2011 10:00 1
6517 23 Feb 2011 11:00 1
6518 23 Feb 2011 12:00 1
6519 23 Feb 2011 13:00 1
6520 23 Feb 2011 14:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 6519
Begin Snapshot Id specified: 6519
Enter value for end_snap: 6520
End Snapshot Id specified: 6520
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_6519_6520.html. To use this name,
press to continue, otherwise enter an alternative.
Enter value for report_name: deneme_awr
Using the report name deneme_awr
…
…
…
…
…
Report written to deneme_awr
SQL>
awrrpt.sql’ i komut satırından başlatııkdan sonra sırası ile istenilen bilgileri giriyoruz. Bu bilgileri sırasıyla açıklayalım ;
Enter value for report_type: html
(rapor çıktısının formatını belirliyoruz, text veya html giriyoruz)
Enter value for num_days: 1
(snapshot id’ si seçmek için kaç günlük snapshotları görmek istediğimizi söylüyoruz)
Enter value for begin_snap: 6519
Enter value for end_snap: 6520
(alacağımız raporun hangi snapshotları dikkate alması gerektiğini söylüyoruz)
Enter value for report_name: deneme_awr
(raporun ismini set ediyoruz. Hangi dizinde çalıştırdıysanız o dizin altına belirlediğiniz isimle dosyayı create ediyor)
RAC kullanıyorsanız çalıştıracağınız file’ in ismi awrgrpt.sql olacaktır. (@$ORACLE_HOME/rdbms/admin/awrgrpt.sql)
Spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrrpti.sql olacaktır.
(@$ORACLE_HOME/rdbms/admin/awrrpti.sql)
Bu awrrpti.sql çalıştırıldığından yukarıdakinden farklı olarak sizden hangi instance için almanız gerekiyor ise o instance ait dbis bilgisini girmenizi isteyecektir.
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
----------- -------- ------------ ------------ ------------
3309173529 1 MAIN main examp1690
3309173529 1 TINT251 tint251 samp251
Rac kullanıpda, spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrgrpti.sql olacaktır.
(@$ORACLE_HOME/rdbms/admin/awrgrpti.sql)
Burada da istenilen bilgiler yukarıdaki örnekdeki gibi girilmesi gerekmektedir.
Şimdi işi biraz daha detaylandırıp snapshot içerisinde bizim için problemli olduğunu düşündüğümüz sadece bir sql için awr raporu almaya çalışalım. Bunun için kendi test ortamımda şöyle bir case oluşturdum. 06y3gf61vurz7 id’ li bir sql’ im var ve sabah 08 – 09 arasında sistemde kaynaklanan yoğunluğun bu sql’ den kaynaklandığını düşünelim ve araştıralım ;
Yaptığım işleme ait log ;
[]$ sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 15:20:14 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
2656835042 TEST 1 TEST
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: text
Type Specified: text
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 2656835042 &nbs
(ORA-00313) Redolog grublarından biri (veya birkaçı) Kaybedildiğinde Yapılması Gerekenler
Database’ in olmazsa olmaz koşullarından biri en 2 gruplu bir redolog grubunuzun olmasıdır. Redolog’ lar sistemin son ana döndürülmesinde kritik bir önem taşıdığından dolayı groupların memberlanması son derece önemlidir. Redologların nasıl memberlanacağı ile ilgili http://kamilturkyilmaz.blogspot.com/2010/11/redolog-group-tanmlama-degisiklik-yapma.html
gerekli bilgiyi daha önceki yazımda detaylı olarak anlatmıştım. Redologlarınız member’ lı değilse ve herhangi birini kaybetdiyseniz veritabanını kurtarmak için aşağıdaki işlemleri yapmamız gerekir. Ancak burada unutumaması gereken nokta; commit edilmemiş tüm transactionların geri getirilemeyeceği yani veri kaybı yaşanacağıdır.
Benzer bir case’ i oluşturabilmek için database’ imizi shutdown immediate ile kapatıyoruz.
SQL> shutdown immediate;
Veritabanı kapatıldı.
Veritabanı kullanıma kapatıldı.
ORACLE anı kapatıldı.
SQL>
Redologlardan birini, yer aldığı dizinden siliyorum; Şimdi bu haliyle database’ i açmayı deniyorum (hatayı görebilmek için) ;
SQL> startup
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 222301060 bytes
Database Buffers 381681664 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
ORA-00313: 1 günlük grubunun (thread 1) üyeleri açılamadı
ORA-00312: çevrimiçi günlük 1, thread 1:
'C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG'
Database redologlardan redo01.log dosyasını bulamadığı için açamadı. Ve mount modda kaldı. (hatırlayınız; database’ e startup komutu verildiğinde son aşaması datafile’ leri ve redologları açtığı nokta idi, bu aşamayı geçemediğinden dolayı mount modda kalıyor.) Kontrol etmek için ;
SQL> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
Bu durumdan kurtulmak için şimdi komut satırından database’ i recover ediyoruz. Bu işlem ile kayıp olan redolog dosyası otomatikl olarak daha önce olduğu lokasyona aynı isimle system tarafından otomatik olarak create ediliyor. Bu işlemi “recover database until cancel” komutu ile yapmamızın nedeni gelebildiğimiz kadar son noktaya gelmeye çalıştığımızdan dolayıdır.
SQL> recover database until cancel;
Ortam kurtama tamamlandı.
Bu işlemi başarıyla gerçekleştirdikden sonra yine unutlmaması gereken bir nokta incomplete recovery işlemlerinden sonra mutlaka database’ i open resetlogs komutu ile açabilmemizdir. Zaten open ile açmayı denediğinizde aşağıdaki hatayı alırsınız.
SQL> alter database open ;
alter database open
*
1 satırında HATA:
ORA-01589: veritabanı açma için RESETLOGS veya NORESETLOGS seçeneği kullanılmalı
Rsetlogs ile açıyoruz.
SQL> alter database open resetlogs;
Veritabanı değiştirildi.
Bu şekilde database’ imizi kurtarmış olduk. Bu işlemi yapabilmek için database’ in archive modda olmasına gerek yoktur. Çünkü bu problemi düzeltmek için archive loglara ihtiyaç bulunmamaktadır.
Bu tarz disaster durumlarında veri kaybı çoğu zaman kabul edilebilir bir nokta olmakdan çıkıyor, dolayısıyla yazımın başında belirtmiş olduğum gibi önlemlerimizi zamanında ve doğru bir şekilde alıyor olmamız gerekiyor.
Oracle Data Integrator(ODI) Genel Bakış
OLAP VE ORACLE DATA INTEGRATOR(ODI)
Olap ve Oracle Data Integrator arasinda, tablolama konusunda ortaklik bulunuyor.Aslinda ODI yeni bir teknoloji degildir. Yani bildigimiz manada. Asagida tablolardan da anlasilacagi gibi, ODI sadece yöneticidir. Kendisinin yaptigi bir sey yoktur.Oracle, SQL gibi database sistemlerde bu toollari kullanir.OLAP ile ise zaten OLAP'in kendisi veri bütünlestirme yöntemidir. Oracle'da da ODI ile bu teknolojiyi kullanabiliriz.
ODI Nedir?
ODI: Oracle Data Integrator
ODI daha sonra hedeflere yüklenecek çok sayida verinin saglar.Yeni set edilmis bilesenlere veya herhangi heterojen kaynak(çesitli veriler)lara uzaktan erisimi saglar. Yani onlarin(verilerin) tanimlariyla baglantilar kurar. Kendileri offline olsalar bile; onlarla ilgili islemler yapabilir. Bunu sürükle birak mantigi ile ama yine de bir kod tabani üzerinden yapar.Süreç akisi ve veri haritalama kullanarak,ELT isleme benzer veri entegrasyonu ODI ile gerçeklestirilebilir. Veri birden fazla kaynaktan, çesitli dönüsüm süreçleri gönderilerek ve ayiklanan bir nihaî hedefe yüklenerek; olusturmak istedigimiz tablo kriterlerine uyacak kadar esnek bir yapi ile ODI de(daha dogrusu; yine Oracle'in kendisinde) islenebilir.Dönüsümler kaynak sistemleri veya platformu üzerinden, hedef ortamda özel kodu dahil bilgi modülleri tarafindan tanimlanarak olusabilir.
Oracle Data Integrator(ODI) , yüksek performansli hareket ve veri dönüsümü durumlarina göre; heterojen sistemlerde senkron ve asenkron modlarla gerçek zamanli toplu islemler yaparak; modüler tasarim yaklasimi ile kullanici verimliligini artirir.ODI, grafik modülleri ve yazilim prensipleriyle buna izin verir.Oracle Data Integrator, grafik modulleri ve yazilim maddeleri ile buna izin verir(verimlilik artimina).
• Ters mühendislik uygulama modelleri.
• Veri tutarliligi kontrolu.
• Arabirimleri uygulamalari arasinda Tasarim, test, isletmek ve korumak
• Kontrol edilmis veri arayüzler tarafindan, hata izolasyonu ve/veya geri dönüsüm ile islenmis olarak akmasi • Eksik veri girisi tanimlamak
Oracle Data Integrator(ODI) için tasarlanmistir.
ORACLE DATA INTEGRATOR(ODI) MIMARISI
Mimari Durumu(görünüsü)
ODI mimarisi bilesenlerle, client-server tarzinda bi moduler ambar etrafinda organize edildi. Grafik modülleri ve uygulama araçlari ile bütünüyle java da yazildi.Kullanicilar bilgiye bir arayüz vasitasiyla(designer), mimariye dahil bir web uygulamasi ile erisebilirler.
1 GRAFIK MODULLERI
4 tane grafik Modülü vardir. i)Designer, ii)Operator, iii)Topoloji Yöneticisi ve iiii)Güvenlik Yöneticisi.Bu moduller Java Virtual Machine 1.5(J2SE), grafik platformunda kurulabilir. Windows uygulamalari, Linux, HP-UX, Solaris, AIX ve Mac OS digerlerinin ortasinda dahil edilebilir. Bu topolojilerin grafiksel pozisyonlarina sekilden genel olarak ulasabiliriz.
Designer, data dönüstürümü ve data güvenligi için deklaratif kurallari tanimlar. Tüm proje gelistirmeleri bu modülde alan götürür.Bu alan database ve uygulama metadata getirtilir ve tanimlanir. Designer modül üretim senaryolari olusturmak için kurallar ve metadata kullanir.Bu metadata yönetimi ve gelistirimi isin özendeki ve önemi ciddi seviyede olan bir modüldür.
Operator, üretimi denetler ve yönetir. Üretim operatoru için design edlimistir ve uygulama logaritmalarini hatali sayimlar ile gösterir.
Topology Manager, altyapi sisteminin fiziksel ve mantiksal mimarisini tanimlar. Serverlar, Semalar ve Araçlar bu modulde genellikle altyapi sistemini veya Proje yöneticileri kayitlidir.
Security Manager, kullanici profilleri ve onlarin özel erisimlerini yönetir. Bu modul genellikle güvenlik yöneticileri tarafindan kullanilir.
2 RUNTIME PARÇALARI
Sekil de designer, Operator, Repository(ambar), Sheduler Agent iliskisel çalismalari anlasilabiliyor. Veri ambari raporlama aninda Sheduler Agent iliskisi Designer ve Operator kavramsallasmasi görülüyor.
Senaryo uygulanmasini Sheduler Agent koordine eder.Sheduler Agent herhangi Java platformunda kurulabilir. Sheduler Agent almak-yüklemek seklinde dönüstürmek ile arada bir perform eder ve tasir. Uygulama ambarindan kodu basit bir sekilde alir, düzeltir ve sonra database server'ina, uygulama alanlarina cevap döner.
Veri Ambarı ile OLTP Sistemler Arasındaki Farklar
Veri Ambari
Veri Ambari, veritabani hareketinden çok sorgulama ve analiz için kullanilmak üzere dizayn edilmis iliskisel bir veritabanidir. Genelde
hareket verisinden elde edilmis tarihi bilgiler içerdigi gibi baska kaynaklardan gelen bilgiler de içerebilir. Veritabani hareketlerinden
kaynaklanan is yüküyle analiz yükünü birbirinden ayirir ve bu sayede degisik kaynaklardan toplanan bilgilerin daha kolay bir sekilde
organize edilmesine olanak saglar.
Veri Ambari ile OLTP Sistemler Arasindaki Farklar
Veri Ambari ve OLTP sistemlerin ihtiyaçlari birbirinden çok farklidir.Tipik bir veri ambari ile OLTP sistemler arasindaki bazi farklar sunlardir:
Olap Küpü Nedir
OLAP KÜPÜ NEDİR
İlişkisel veri tabanlarının kullanımı ve sonrasında ortaya çıkan veri ambarlarının büyüklüğü ile beraber, verilere daha hızlı şekilde erişme ve çok boyutlu analiz ihtiyaçları doğmuştur. Çevrimiçi Analitik İşleme (OLAP) veritabanları karar destek sorgularını kolaylaştırır. OLAP, işlemleri işlemek yerine sorgulama ve raporlama için en iyi duruma getirilmiş bir veritabanı teknolojisidir. OLAP'ın kaynak verileri, yaygın olarak veri depolarında depolanan Çevrimiçi İşlem İşleme (OLTP) veritabanlarıdır. OLAP verileri bu geçmiş verilerinden türer ve karmaşık çözümlemelere izin veren yapılar halinde derlenir. OLAP verileri hiyerarşik olarak da düzenlenir ve tablo yerine küplerde depolanır.