Oracle 11g Veritabanları için Yüksek Erişilebilirliğe Giriş Serisi

Transkript

TROUG
[Oracle 11g Veritabanları için
Yüksek Erişilebilirliğe Giriş
Serisi]
RMAN
(Recovery Manager)
Ergem PEKER
TROUG
[Oracle 11g Veritabanları için Yüksek Erişilebilirliğe Giriş Serisi]
RMAN (Recovery Manager)
Giriş
Veritabanı yöneticisinin temel görevleri ve sorumlulukları olan tablespace ve disk doluluk
oranlarının takibi, kullanıcı hesaplarının yönetimi, performansı düşük sorguların
iyileştirilmesi, yama yönetimi, veri güvenliği gibi birçok günlük operasyonel iş arasında
kendisini kaybetmesi aslında cok daha kritik olan bir görevini kendisine unutturur,
unutturmasa bile oldukça geri planlara itmesine neden olabilir. Bahsedilen en kritik görev
ve sorumluluk aslında "Veri Yedekleme ve Kurtarma" 'dir. Bir veritabanı yöneticisinin
duzenli ve çalışır bir yedekleme planı olmaması kabul edilemez. Diğer yandan sadece
yedekleme planı olması da yeterli değildir. Yedeği alınan veritabanın, herhangi bir sebeple
kaybolan verilerin geri kurtarılmasını sağlaması gerekmektedir. Aslında gün içerisinde pek
te aklımıza gelmeyen bu işlem, bir veritabanı yöneticisinin en kritik görevidir.
Bir Oracle Veritabanının yedeklenmesi ve kurtarılmasi birçok farklı senaryo ve araç ile
sağlanabilir. En cok kullanılan araçlar arasında export/import ve Oracle Veritabanı 10g
versiyonu ile birlikte kullanıma sunulan datapump ürünleri sayilabilir. Bu araçların yanında
işletim sistemi dosya kopyalama yöntemini esas alan "User Managed" yedekleme ve
kurtarma yöntemleri de vardır. Diğer yandan depolama ürünlerinin sağladığı bazı çözümler
de veritabanı yedekleme yöntemleri arasında gösterilebilir. Bu kısa yazıda az önce
bahsedilen yöntemlerin hiç birisine değinmeden Oracle 'in önerdiği ve desteklediği veri
yedekleme ve kurtarma ürünü olan RMAN (Recovery MANager) başlığını kısaca
inceleyeceğiz.
Öncelikle RMAN 'in diğer çözümlere kıyasla sağladığı avantajlara bir göz atmak gerekir.
Diğer araçlara kıyasla RMAN block seviyesinde çalıştığı için bazı kazanımlari vardır.
Örneğin Incremental Yedek işlemlerini diğer araçlar ile sağlayamiyor iken RMAN ‘de bu
özellik var. Dolayısıyla her seferinde tüm veritabanı dosyalarının tamamını kopyalamak
yerine, bir önceki full yedek üzerine sadece yedeği alınmamış fark blocklari yazabilirsiniz.
Block seviyesinde çalışmanın getirdiği bir diğer önemli özellik ise block kurtarma. Bir veri
dosyasının tamamının değil fakat bir kısmının hatta daha küçük seviyede sadece bazı block
larının herhangi bir sebepten dolayı bozulması RMAN öncesinde tum tablespace ‘in
yedekten geri dönülmesi ile mümkün olabilirken, RMAN ile sadece birkac komut ile sadece
bozulan block ‘lar kurtarılabiliyor.
Yedekleme performansida RMAN ile daha kolay yönetilebilir halde. Özellikle Parallel yedek
almak için diğer araçlarda veritabanı yöneticisinin kişisel katkısı gerekirken, RMAN ile
kanallar (channel) üzerinden parallel yedekleme işlemleri cok daha kolay yönetilebilir hale
gelmiş durumda.
1
TROUG
Eğer Oracle ASM ürününü kullanıyorsanız, RMAN ‘in getirdiği bir çok kullanışlı özellik bir
çok veritabanı yöneticisi için vazgeçilmez hale gelebilir. Zira ASM üzerinde bulunan tüm
Oracle veritabanı dosyaları RMAN ile yedeklenebilir, kopyalanabilir, ASM’den dosya
sistemine veya tam ters yönlu olarak aktarılabilir ve çok daha önemli bir özellik olan
veritabanı klonlama işlemleri yine RMAN ile yapılabilir.
Tüm bu özelliklerin yanı sıra RMAN ‘in bir diğer kullanışlı özelliği, daha önce alınmış olan
tüm veritabanı ve archivelog yedeklerinin controlfile içerisinde bulunan kütüphaneden
sorgulanabilmesi. Birden fazla veritabanının olması durumda bu kütüphane bir veritabanı
(catalog database) üzerinde de tutulabilir.
RMAN ‘i başlatma ve temel ayarlar
Başlamadan önce iki varsayımda bulunmak gerekir. Aşağıdaki komut ve yöntemlerin
çalışması için versiyonu 11gR2 olan bir Oracle Veritabanı kurulumunun halihazırda var
olduğunu ve veritabanının “archivelog mode” da olduğunu varsayıyoruz.
RMAN, bir veritabanı kurulumu yapıldığında, veritabanı yazılımının kurulu oldugu dizin
içerisinde varsayılan bir araç olarak gelir ve Oracle kurulum dizini (bundan sonra
$ORACLE_HOME olarak bahsedilecektir) içerisinde tum binary dosyalarının bulunduğu
“bin” klasöru içerisinde yer alir.
[oracle@localhost ~]$ ls $ORACLE_HOME/bin/rman
/home/oracle/app/oracle/product/11.2.0/dbhome_2/bin/rman
[oracle@localhost ~]$ which rman
~/app/oracle/product/11.2.0/dbhome_2/bin/rman
RMAN ‘i çalıştırmak için sadece “rman” komutunu yazıp enter ‘a basmak yeterli olacaktir.
Fakat RMAN işlemlerinin yapılacağı bir veritabanına bağlanmanız gerekir. Bu
veritabanından bundan sonra “target” veritabanı olarak bahsedilecektir. Target
veritabanını RMAN’i çalıştırdıktan sonra veya çalıştırırken bildirebilirsiniz.
[oracle@localhost ~]$ rman
Recovery Manager: Release 11.2.0.2.0 - Production on Tue Nov 29 13:56:00 2011
2
TROUG
Copyright (c) 1982, 2009, Oracle and/or its affiliates.
All rights reserved.
RMAN> connect target /
connected to target database: ORCL (DBID=1229390655)
RMAN> exit
Recovery Manager complete.
[oracle@localhost ~]$ rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Tue Nov 29 13:56:32 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN>
RMAN ‘i çalıştırdıktan ve target veritabanına bağlandıktan sonra, bir veritabanı yedeği
almak oldukça kolay. Tek yapmanız gereken “backup database” komutunu girmek ve komut
çıktılarini takip etmek. Burada dikkat edilmesi gereken husus yeterli disk alanına sahip olup
olmadığınızdır. Zira RMAN varsayılan yedekleme klasöru olarak $ORACLE_HOME/dbs altını
seçecektir. Eğer “db_recovery_file_dest” sistem parametresi ayarlanmış ise bu durumda bu
alana yedek alacaktır. Alınan veritabanı yedekleri hakkında RMAN’e soru sormak isterseniz
“list backup of database [summary]” komutunu aşağıdaki örnekteki gibi kullanabilirsiniz.
RMAN> backup database;
Starting backup at 29-NOV-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=143 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
input datafile file number=00001 name=/home/oracle/app/oracle/oradata/orcl/system01.dbf
input datafile file number=00004 name=/home/oracle/app/oracle/oradata/orcl/users01.dbf
input datafile file number=00003
name=/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
name=/home/oracle/app/oracle/oradata/orcl/example01.dbf
name=/home/oracle/app/oracle/oradata/orcl/APEX_1265209995679366.dbf
channel ORA_DISK_1: starting piece 1 at 29-NOV-11
channel ORA_DISK_1: finished piece 1 at 29-NOV-11
piece
handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_11_29/o1_mf_nnnd
f_TAG20111129T143635_7fbqmmkb_.bkp tag=TAG20111129T143635 comment=NONE
3
TROUG
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45
including current control file in backup set
including current SPFILE in backup set
piece
handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_11_29/o1_mf_ncsn
f_TAG20111129T143635_7fbqo1vb_.bkp tag=TAG20111129T143635 comment=NONE
Finished backup at 29-NOV-11
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------2
Full
1.97G
DISK
00:00:44
29-NOV-11
BP Key: 2
Status: AVAILABLE Compressed: NO Tag: TAG20111129T143635
Piece Name:
/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_11_29/o1_mf_nnndf_TAG20
111129T143635_7fbqmmkb_.bkp
List of Datafiles in backup set 2
File LV Type Ckp SCN
Ckp Time Name
---- -- ---- ---------- --------- ---1
Full 9118670
29-NOV-11 /home/oracle/app/oracle/oradata/orcl/system01.dbf
2
Full 9118670
29-NOV-11 /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
3
Full 9118670
29-NOV-11 /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
4
Full 9118670
29-NOV-11 /home/oracle/app/oracle/oradata/orcl/users01.dbf
5
Full 9118670
29-NOV-11 /home/oracle/app/oracle/oradata/orcl/example01.dbf
6
Full 9118670
29-NOV-11
/home/oracle/app/oracle/oradata/orcl/APEX_1246426611663638.dbf
7
Full 9118670
29-NOV-11
RMAN yedekleme işlemi boyunca target veritabanı dosyalarını okurken, çıkış arabirimi
olarak ta channel’lari kullanir. Channel ayarlarını yaparak backup süresinde iyileştirmeler
yapabilir, yedekleme dosyalarının formatlarını dilediğiniz gibi ayarlayabilirsiniz. Herhangi
bir ayar yapmadığımız durumda RMAN’in hangi durumda hangi klasöre yedek aldığını bir
önceki örnekte görmüştük . Ayarlarda herhangi bir özelleştirme yapılmadığı taktirde RMAN
varsayılan olarak ORA_DISK_1 isimli bir channel olusturur ve bu channel’i
$ORACLE_HOME/dbs altına veya “flash recovery area” özelliği ayarlı ise
db_recovery_file_dest’te belirtilen klasöre yönlendirir. Simdi channel ayarları ile biraz daha
yakından ilgilenebiliriz. Şöyle ki;
4
TROUG
RMAN> show default device type;
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
RMAN> configure channel device type disk format
'/home/oracle/app/oracle/admin/orcl/%U';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
RMAN> show channel;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
Bu yeni ayarlarlar ile birlikte RMAN yedeklerinin belirtilen klasöre alınmasını bekliyoruz.
Bakalım gerçekten öyle mi?
RMAN> backup database;
Starting backup at 30-NOV-11
name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
name=/home/oracle/app/oracle/oradata/orcl/system01.dbf
name=/home/oracle/app/oracle/oradata/orcl/users01.dbf
5
TROUG
piece handle=/home/oracle/app/oracle/admin/orcl/07msua9a_1_1
tag=TAG20111130T062649 comment=NONE
piece handle=/home/oracle/app/oracle/admin/orcl/08msuaan_1_1
Finished backup at 30-NOV-11
RMAN> list backup of database summary;
List of Backups
===============
Key
TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --6
B F A DISK
30-NOV-11
1
1
NO
TAG20111130T062649
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------6
Full
1.97G
DISK
00:00:43
30-NOV-11
BP Key: 6
Piece Name: /home/oracle/app/oracle/admin/orcl/07msua9a_1_1
Ckp Time Name
---- -- ---- ---------- --------- ---1
Full 9182550
30-NOV-11
/home/oracle/app/oracle/oradata/orcl/system01.dbf
2
Full 9182550
30-NOV-11
/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
3
Full 9182550
30-NOV-11
/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
6
TROUG
4
Full 9182550
30-NOV-11
/home/oracle/app/oracle/oradata/orcl/users01.dbf
5
Full 9182550
30-NOV-11
/home/oracle/app/oracle/oradata/orcl/example01.dbf
6
Full 9182550
30-NOV-11
7
Full 9182550
30-NOV-11
Evet gerçekten öyle. Bu esnada dikkat etmemiz gereken bir diğer önemli konu ise RMAN’in
aldığı yedekleri dosya sisteminde nasıl tuttuğu. RMAN aldığı her yedeği bir backupset
(yedek kumesi) mantıksal yapısı içerisinde tutar ve bu backupset’i belirleyici bir TAG ile
işaretler. Bu backupset içerisinde de backuppiece (yedek parcasi) adı verilen fiziksel
dosyaları görebilirsiniz. Her backupset’te bir veya birden fazla backuppiece bulabilirsiniz.
“list backupset” komutu ile almış olduğunuz yedeklerin backupset’lerini bu backupset’lerin
içerisindeki backuppiece’leri ve bu backuppiece’lerin içerisindeki veritabanı dosyalarını
görebilirsiniz.
RMAN> list backupset;
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------6
Full
1.97G
DISK
00:00:43
30-NOV-11
BP Key: 6
Piece Name: /home/oracle/app/oracle/admin/orcl/07msua9a_1_1
Ckp Time Name
---- -- ---- ---------- --------- ---1
Full 9182550
30-NOV-11
2
Full 9182550
30-NOV-11
3
Full 9182550
30-NOV-11
4
Full 9182550
30-NOV-11
5
Full 9182550
30-NOV-11
6
Full 9182550
30-NOV-11
7
Full 9182550
30-NOV-11
7
TROUG
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------7
Full
9.36M
DISK
00:00:03
30-NOV-11
BP Key: 7
Piece Name: /home/oracle/app/oracle/admin/orcl/08msuaan_1_1
SPFILE Included: Modification time: 30-NOV-11
SPFILE db_unique_name: ORCL
Control File Included: Ckp SCN: 9182567
Ckp time: 30-NOV-11
İlk bölümden değinmemiz gereken bir diğer ayar ise “retention policy”. Bu ayar kaç adet
sağlıklı veritabanı yedeğini disk üzerinde tutmak istedigimizle ilgili. Bu ayar iki temel birim
üzerinden yapılabilir. Birincisi zaman temelli bir policy belirleyebilirsiniz. Ikincisi backup
adedi üzerinden bir policy belirleyebilirsiniz. Örneğin, Aşağıdaki ayarı yapmak ile son 7
günlük yedekleri RMAN repository’sinde tutmak istediğimizi RMAN’e bildiriyoruz, böylece
RMAN gereksiz yedekleri silerken son 7 gunden önceki yedekleri silmeye özen
gösterecektir.
RMAN> configure retention policy to recovery window of 7 days;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Diğer yandan, aşağıdaki ayarı yapmakla RMAN’e son 7 adet yedeği repository’de tutması
gerektiğini bildiriyoruz. Böylece RMAN’in eski yedeklerden kastı son 7 adet yedek’ten daha
önceki dosyalar olacaktir.
RMAN> configure retention policy to redundancy 7;
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
Eğer hergün sadece tek bir yedek alıyorsak bu yukarıdaki iki farklı ayar aynı sonucu
verecektir. Fakat haftada bir full veritabanı yedeği alıyorsak, ilk ayar sadece bir adet
8
TROUG
veritabanı yedeğini repository’de barındırırken, ikinci ayar son 7 haftalık yedeği
repository’de barındıracaktır. Bu ikisinin farkı, özellikle disk’e alınan yedeklerde önem arz
edecektir, zira disk doluluk oranını etkileyen bir etkendir.
Simdi bir örnekle beraber süresi dolan yedekler ve arşivlog’lar nasıl listelenir ve silinir bir
bakalım. Diskteki yer kısıtı dolayısıyla ben retention policy ‘i son bir yedeği tutacak sekilde
ayarladım. Süresi dolan yedekleri sildikten sonra veritabanı yedeklerini listeledigimde
sadece son veritabanı yedeğinin repository’de kaldığına dikkat edebilirsiniz. Ayrıca son
veritabanı yedeğinden daha önce üremiş olan arşivlog’larinda silindiğine dikkat ediniz, zira
bu log’lar son yedeğe geri dönebilmek için gerekli olan dosyalar arasında değiller.
RMAN> configure retention policy to redundancy 1;
old RMAN configuration parameters:
RMAN> report obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of obsolete backups and copies
Type
Key
Completion Time
Filename/Handle
-------------------- ------ ------------------ -------------------Archive Log
1
29-NOV-11
/home/oracle/app/oracle/admin/orcl/1_388_701609923.dbf
Backup Set
1
29-NOV-11
Backup Piece
1
29-NOV-11
/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_11_29/o1_mf_nc
snf_TAG20111129T143039_7fbq8k1k_.bkp
Archive Log
2
29-NOV-11
/home/oracle/app/oracle/admin/orcl/archive/1_389_701609923.dbf
Archive Log
3
29-NOV-11
Backup Set
3
29-NOV-11
Backup Piece
3
29-NOV-11
snf_TAG20111129T143635_7fbqo1vb_.bkp
Archive Log
4
30-NOV-11
Archive Log
5
30-NOV-11
Backup Set
5
30-NOV-11
9
TROUG
Backup Piece
5
30-NOV-11
/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/06msu8pu_1_1
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Deleting the following obsolete backups and copies:
Type
Key
Completion Time
Filename/Handle
-------------------- ------ ------------------ -------------------Backup Set
1
29-NOV-11
Backup Piece
1
29-NOV-11
snf_TAG20111129T143039_7fbq8k1k_.bkp
Archive Log
2
29-NOV-11
Archive Log
3
29-NOV-11
Backup Set
3
29-NOV-11
Backup Piece
3
29-NOV-11
snf_TAG20111129T143635_7fbqo1vb_.bkp
Archive Log
4
30-NOV-11
Archive Log
5
30-NOV-11
Backup Set
5
30-NOV-11
Backup Piece
5
30-NOV-11
/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/06msu8pu_1_1
Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece
handle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_11_29/o
1_mf_ncsnf_TAG20111129T143039_7fbq8k1k_.bkp RECID=1 STAMP=768493841
deleted archived log
archived log file
name=/home/oracle/app/oracle/admin/orcl/archive/1_389_701609923.dbf RECID=2
STAMP=768494151
archived log file
STAMP=768495061
backup piece
1_mf_ncsnf_TAG20111129T143635_7fbqo1vb_.bkp RECID=3 STAMP=768494241
10
TROUG
archived log file
STAMP=768549201
archived log file
STAMP=768549618
backup piece
handle=/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/06msu8pu_1_1
RECID=5 STAMP=768549696
Deleted 7 objects
List of Backups
===============
Key
TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --6
B F A DISK
30-NOV-11
1
1
NO
TAG20111130T062649
Temel Yedekleme İşlemleri
Veritabanı yedeğini almak için girmemiz gereken komutu bir önceki bölümde zaten
incelemistik. Bu bölümde de veri dosyaları dışında kalan fakat yine de olası bir geri dönüş
senaryosunda ihtiyacımız olabilecek diğer veritabanı dosyaları olan controlfile, spfile ve
arşivlog’ların yedeklemesine göz atacağız.
Yukarıdaki “backup database” çıktılarına bakacak olursanız, her veritabanı yedeği sonunda
backupset içerisine bir backuppiece, içerisinde de controlfile ve spfile yedeklerinin
otomatik olarak alındığını görebilirsiniz.
Eğer controlfile yedeğinin Ayrıca alınmasını istiyorsanız o halde “backup current
controlfile” komutunu kullanabilirsiniz. Aynı şekilde spfile yedeği içinde “backup spfile”
komutu yeterli olacaktir. Ayrıca yine “list backup of controlfile [summary]” veya “list
backup of spfile [summary]” komutları ile alınan yedekleri kontrol edebilirsiniz.
11
TROUG
RMAN> backup current controlfile;
Starting backup at 05-DEC-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting piece 1 at 05-DEC-11
channel ORA_DISK_1: finished piece 1 at 05-DEC-11
piece handle=/home/oracle/app/oracle/admin/orcl/09mtduk8_1_1
Finished backup at 05-DEC-11
Starting Control File and SPFILE Autobackup at 05-DEC-11
piece handle=/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/c-122939065520111205-00 comment=NONE
Finished Control File and SPFILE Autobackup at 05-DEC-11
RMAN> backup spfile;
piece handle=/home/oracle/app/oracle/admin/orcl/0bmtdukp_1_1
RMAN> list backup of controlfile summary;
List of Backups
===============
Key
TY LV S Device Type
------- -- -- - ----------7
B F A DISK
TAG20111130T062649
8
B F A DISK
TAG20111205T044600
Completion Time #Pieces #Copies Compressed Tag
--------------- ------- ------- ---------- --30-NOV-11
1
1
NO
05-DEC-11
1
1
NO
12
TROUG
9
B F A DISK
TAG20111205T044602
11
B F A DISK
TAG20111205T044618
05-DEC-11
1
1
NO
05-DEC-11
1
1
NO
RMAN> list backup of spfile summary;
List of Backups
===============
Key
TY LV S Device Type
------- -- -- - ----------7
B F A DISK
TAG20111130T062649
9
B F A DISK
TAG20111205T044602
10
B F A DISK
TAG20111205T044617
11
B F A DISK
TAG20111205T044618
--------------- ------- ------- ---------- --30-NOV-11
1
1
NO
05-DEC-11
1
1
NO
05-DEC-11
1
1
NO
05-DEC-11
1
1
NO
RMAN> list backup of controlfile;
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------7
Full
9.36M
DISK
00:00:03
30-NOV-11
BP Key: 7
Piece Name: /home/oracle/app/oracle/admin/orcl/08msuaan_1_1
Ckp time: 30-NOV-11
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------8
Full
9.33M
DISK
00:00:02
05-DEC-11
BP Key: 8
Piece Name: /home/oracle/app/oracle/admin/orcl/09mtduk8_1_1
Ckp time: 05-DEC-11
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------9
Full
9.36M
DISK
00:00:00
05-DEC-11
BP Key: 9
Piece Name: /home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/c1229390655-20111205-00
Ckp time: 05-DEC-11
13
TROUG
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------11
Full
9.36M
DISK
00:00:00
05-DEC-11
BP Key: 11
Status: AVAILABLE Compressed: NO Tag:
TAG20111205T044618
Piece Name: /home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/c1229390655-20111205-01
Ckp time: 05-DEC-11
Controlfile yedekleri için ayrıca dikkat edilmesi gereken bir durum vardır. İleride controlfile
kurtarma bölümünde daha detaylı değineceğiz ama yine de burada bir giriş yapmak yerinde
gözüküyor. RMAN aldığı tüm yedeklerin metadatasini controlfile içerisinde tutar (catalog
veritabanı kullanılmadığı durumda). Dolayısıyla controlfile kaybı RMAN için oldukça kritik
bir durum, zira controlfile yedeklerinin kendisi de RMAN backupset ‘leri içerisinde. Bu
ikilemden kurtulmak için controlfile auto backup özelliğini ayarlayabiliriz. Bunun için
“controlfile auto backup” parametresini “on” olarak ayarlamanız gerekir. Bu parametreyi
“on” olarak ayarladıktan sonra RMAN her veritabanı yedeğinden sonra controlfile
yedeklerini otomatik olarak $ORACLE_HOME/dbs dizini altına da alır. Veri kurtarma
kısmında bu yedeğin ne kadar önemli olacağını göreceğiz.
RMAN> configure controlfile autobackup on;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> show controlfile autobackup;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Arşivlog’ların da yedeğini alıp daha sonra orjinal arşivlog’ları disk kullanımını azaltmak için
dosya sisteminden silebilirsiniz veya RMAN’e arşivlog yedeklerini aldıktan sonra yedeğini
aldığı arsivleri dosya sisteminden (veya ASM üzerinden) kaldırmasini bildirebilirsiniz.
Arşivlog’ları silerken dikkat edilmesi gereken bir diğer nokta ise, arşivlog dosyalarının
dosya sistemi komutları ile değil de RMAN komutları ile silmekte fayda vardır. Aksi
14
TROUG
taktirde RMAN silinen arşivlog’ların kaydını tutamayacak ve bir sonraki arşivlog yedeğinde,
bulamadigi arşivlog’lar için hata verecektir. Bunu önlemek için RMAN içerisinde “crosschek
archivelog all” komutu ile RMAN’in dosya sistemindeki arşivlog dosyalarından haberdar
olması sağlanabilir. Son örnek olarak ta, bir arsiv sequence numarasi ile arsiv yedekleyip
listeleyebilirsiniz. Şöyle ki;
RMAN> backup archivelog all;
current log archived
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=393 RECID=6 STAMP=769058085
piece handle=/home/oracle/app/oracle/admin/orcl/0dmte263_1_1
RMAN> backup archivelog from time 'sysdate-1';
piece handle=/home/oracle/app/oracle/admin/orcl/0fmte3nk_1_1
15
TROUG
RMAN> backup archivelog all delete all input;
piece handle=/home/oracle/app/oracle/admin/orcl/0hmte3o8_1_1
channel ORA_DISK_1: deleting archived log(s)
archived log file
name=/home/oracle/app/oracle/admin/orcl/archive/1_393_701609923.dbf
STAMP=769058085
archived log file
STAMP=769067203
archived log file
STAMP=769068788
archived log file
STAMP=769068808
RECID=6
RECID=7
RECID=8
RECID=9
RMAN> list backup of archivelog all;
List of Backup Sets
===================
BS Key Size
------- ---------- ----------- ------------ ---------------
16
TROUG
12
14.53M
DISK
00:00:01
05-DEC-11
BP Key: 12
TAG20111205T054643
Piece Name: /home/oracle/app/oracle/admin/orcl/0dmte263_1_1
List
Thrd
---1
1
of Archived Logs in backup set 12
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------393
9180048
30-NOV-11 9203907
394
9203907
05-DEC-11 9214261
Next Time
--------05-DEC-11
05-DEC-11
BS Key Size
------- ---------- ----------- ------------ --------------14
16.28M
DISK
00:00:00
05-DEC-11
BP Key: 14
TAG20111205T061308
Piece Name: /home/oracle/app/oracle/admin/orcl/0fmte3nk_1_1
List
Thrd
---1
1
1
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------393
9180048
30-NOV-11 9203907
394
9203907
05-DEC-11 9214261
395
9214261
05-DEC-11 9215764
Next Time
--------05-DEC-11
05-DEC-11
05-DEC-11
BS Key Size
------- ---------- ----------- ------------ --------------16
16.28M
DISK
00:00:01
05-DEC-11
BP Key: 16
TAG20111205T061328
Piece Name: /home/oracle/app/oracle/admin/orcl/0hmte3o8_1_1
List
Thrd
---1
1
1
1
RMAN>
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------393
9180048
30-NOV-11 9203907
394
9203907
05-DEC-11 9214261
395
9214261
05-DEC-11 9215764
396
9215764
05-DEC-11 9215790
Next Time
--------05-DEC-11
05-DEC-11
05-DEC-11
05-DEC-11
list backup of archivelog from sequence 394 until sequence 394;
List of Backup Sets
===================
BS Key Size
------- ---------- ----------- ------------ ---------------
17
TROUG
12
14.53M
DISK
00:00:01
05-DEC-11
BP Key: 12
TAG20111205T054643
Piece Name: /home/oracle/app/oracle/admin/orcl/0dmte263_1_1
List
Thrd
---1
Seq
Low SCN
Low Time Next SCN
Next Time
------- ---------- --------- ---------- --------394
9203907
05-DEC-11 9214261
05-DEC-11
BS Key Size
------- ---------- ----------- ------------ --------------14
16.28M
DISK
00:00:00
05-DEC-11
BP Key: 14
TAG20111205T061308
Piece Name: /home/oracle/app/oracle/admin/orcl/0fmte3nk_1_1
List
Thrd
---1
Seq
Low SCN
Low Time Next SCN
Next Time
------- ---------- --------- ---------- --------394
9203907
05-DEC-11 9214261
05-DEC-11
BS Key Size
------- ---------- ----------- ------------ --------------16
16.28M
DISK
00:00:01
05-DEC-11
BP Key: 16
TAG20111205T061328
Piece Name: /home/oracle/app/oracle/admin/orcl/0hmte3o8_1_1
List
Thrd
---1
Seq
Low SCN
Low Time Next SCN
Next Time
------- ---------- --------- ---------- --------394
9203907
05-DEC-11 9214261
05-DEC-11
Incremental (Arttırımlı) Yedekleme
RMAN’in bir diğer önemli özelliği “incremental” (arttırımlı) yedek alabilmesidir. Özellikle
çok büyük veritabanlarının günlük alınan yedeklerini barındırmak oldukça maliyetli bir
duruma gelebiliyor. Dolayısıyla hergün tüm veritabanının tamamının yedeğini almak yerine
sadece değişen block’larin yedeğini almak hem toplam yedek alma süresini kısaltıyor hem
de alınan yedeğin, disk üzerinde daha az yer kaplamasını sağlıyor.
Temel Olarak iki seviye arttırımlı yedek alma seçeneğimiz var. Bunlardan ilki level-0
(seviye-0) arttırımlı yedek, ikincisi ise level-1 (seviye-1) arttırımlı yedek. Seviye-0 yedeği
18
TROUG
aslında bir tam veritabanı yedeğine eşdeğer olarak algılanabilir, aradaki tek fark seviye-0
yedek kendinden sonra gelecek olan seviye-1 yedeklere bir baz teskil eder. Örnek vermek
gerekirse, her pazar bir seviye-0 tam yedek alıp hafta içi günlük seviye-1 yedekler alınabilir.
Seviye-1 yedek ise iki sınıfa ayrılır. “differential backup” (fark yedeği) ve “cumulative
backup” (toplu yedek). Fark yedeği kendinden hemen önce alınan seviye-0 veya seviye-1
arttırımlı yedekten sonra değişmiş olan block’ları yedeklerken, toplu yedek ise kendinden
önce gelen sadece seviye-0 arttırımlı yedekten sonra değişen block’lari yedekler. Gayet
açıktır ki, seviye-1 fark yedekleri sadece günlük farklari içerirken, seviye-1 toplu yedek
boyutu bir sonraki seviye-0 yedeğe kadar hergün artarak ilerleyecektir. Aradaki bu farkı
veri kurtarma senaryoları arasında detaylı bir sekilde inceleyeceğiz. Aşağıdaki iki şemada
seviye-1 fark ve toplu arttırımlı yedeklerin farklarini görebilirsiniz.
Seviye-1 fark yedeğine örnek. (Level-1 differential backup)
19
TROUG
Seviye-1 toplu yedeğe bir örnek. (Level-1 cumulative backup)
Aşağıdaki örnekte, seviye-0 ve seviye-1 yedeklerin nasıl alındığıni, komutları ve komut
çıktılarini inceleyebilirsiniz.
RMAN> backup incremental level 0 database;
channel ORA_DISK_1: starting incremental level 0 datafile backup set
20
TROUG
piece handle=/home/oracle/app/oracle/admin/orcl/0qmtger0_1_1
RMAN> backup incremental level 1 database;
piece handle=/home/oracle/app/oracle/admin/orcl/0lmtgddj_1_1
21
TROUG
List of Backups
===============
Key
TY LV S Device Type
------- -- -- - ----------6
B F A DISK
TAG20111130T062649
18
B 0 A DISK
TAG20111205T072847
20
B 1 A DISK
TAG20111206T031043
--------------- ------- ------- ---------- --30-NOV-11
1
1
NO
05-DEC-11
1
1
NO
06-DEC-11
1
1
NO
RMAN> backup incremental level 1 cumulative database;
piece handle=/home/oracle/app/oracle/admin/orcl/0nmtgdhh_1_1
22
TROUG
List of Backups
===============
Key
TY LV S Device Type
------- -- -- - ----------6
B F A DISK
TAG20111130T062649
18
B 0 A DISK
TAG20111205T072847
20
B 1 A DISK
TAG20111206T031043
22
B 1 A DISK
TAG20111206T031249
--------------- ------- ------- ---------- --30-NOV-11
1
1
NO
05-DEC-11
1
1
NO
06-DEC-11
1
1
NO
06-DEC-11
1
1
NO
Veri Kurtarma Senaryoları
Yaptığımız tum yedek planlarının ve aldığımız tüm yedeklerin tek bir amacı vardır.
İstenmeyen muhtemel bir durum sonrasında meydana gelebilecek veri kaybını engellemek
veya kısaca veri kurtarmak (recovery). Aldığımız yedeklerin tutarlılığını ve kullanılırlığını
test etmek için düzenli olarak veri geri dönüş test senaryoları yaratmak, ileride meydana
gelebilecek veri kayıplarını en kısa yoldan çözerek, veri tabanı downtime süresini en azda
tutmak için cok yararlıdır. Zira aldığımız yedeklerin bozuk olup olmadığının, yedekleme
planımizin duzenli ve tutarli olup olmadığının en doğrudan ispatı, elimizdeki bu
yedeklerden sağlıklı bir şekilde geri dönüp dönemediğimizi kendi gözümüzle görmektir.
Aynı yedek almak gibi geri dönüş de RMAN ile oldukça kolaydır. Veri kurtarmanın iki
aşaması vardır. Birincisi “restore” aşaması ikincisi “recover” aşamasıdir. Restore aşaması
veri dosyalarının RMAN yedek dosyalarından geri dönülmesini saglar. Recover işlemi ise,
yedeğin alındığı zamandan itibaren veritabanı kapanmadan son ana kadar olan
değişiklikleri restore edilen veri dosyalarına uygular. Kısaca “restore database” komutunu
çalıştırarak veritabanının en son yedeğindeki veri dosyalarını ASM veya dosya sistemine
yeniden kopyalar, ardından çalıştıracağınız “recover database” komutu ile veritabanının
son anına tekrar geri dönebilirsiniz. Bunun için tum arşivlog ‘ların ve rman
backupset’lerinin ulaşılabilir olması yeterlidir. Genellikle bu komut, olası bir fiziksel
problem (disk kaybi, veri bozulması) dolayısıyla kaybolabilecek veri dosya veya
dosyalarını geri dönmek için kullanılabilir.
SQL> select name from v$datafile;
NAME
23
TROUG
-----------------------------------------------------------------------------/home/oracle/app/oracle/oradata/orcl/system01.dbf
7 rows selected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@localhost ~]$ cd /home/oracle/app/oracle/oradata/orcl/
[oracle@localhost orcl]$ ls
APEX_1246426611663638.dbf control01.ctl redo01.log redo03.log
system01.dbf undotbs01.dbf
APEX_1265209995679366.dbf example01.dbf redo02.log sysaux01.dbf temp01.dbf
users01.dbf
[oracle@localhost orcl]$ rm *.dbf
[oracle@localhost orcl]$ ls
control01.ctl redo01.log redo02.log redo03.log
[oracle@localhost orcl]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Tue Dec 6 04:55:45 2011
Copyright (c) 1982, 2010, Oracle.
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 456146944 bytes
Fixed Size
1344840 bytes
Variable Size
394267320 bytes
Database Buffers
54525952 bytes
Redo Buffers
6008832 bytes
Database mounted.
SQL> exit
24
TROUG
[oracle@localhost orcl]$ rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Tue Dec 6 04:56:03 2011
connected to target database: ORCL (DBID=1229390655, not open)
RMAN> restore database;
Starting restore at 06-DEC-11
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to
channel ORA_DISK_1: reading from backup piece
/home/oracle/app/oracle/admin/orcl/0qmtger0_1_1
channel ORA_DISK_1: piece
handle=/home/oracle/app/oracle/admin/orcl/0qmtger0_1_1 tag=TAG20111206T033455
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 06-DEC-11
RMAN> recover database;
Starting recover at 06-DEC-11
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 06-DEC-11
25
TROUG
RMAN> sql 'alter database open';
sql statement: alter database open
RMAN> exit
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
SQL> select open_mode, name from v$database;
OPEN_MODE
NAME
-------------------- --------READ WRITE
ORCL
Eğer sadece bir veri dosyası kaybetmiş olsaydık, tüm veritabanını geri dönmek yerine
sadece kaybolan veri dosyasını da dönebilirdik. Böyle bir durumda “restore datafile
‘<datafile_name>’ | ‘<datafile_number>’ ” komutunu kullanabilirdik. Hatta bunun için
veritabanını kapatmak zorunda bile olmazdık. Şöyle ki;
SQL> select name from v$tablespace;
NAME
-----------------------------SYSTEM
SYSAUX
UNDOTBS1
USERS
TEMP
EXAMPLE
APEX_1246426611663638
APEX_1265209995679366
8 rows selected.
SQL> select name from v$datafile;
26
TROUG
NAME
------------------------------------------------------------------------------/home/oracle/app/oracle/oradata/orcl/system01.dbf
7 rows selected.
SQL> alter tablespace example offline;
Tablespace altered.
RMAN> restore datafile '/home/oracle/app/oracle/oradata/orcl/example01.dbf';
RMAN> recover datafile '/home/oracle/app/oracle/oradata/orcl/example01.dbf';
archived log for thread 1 with sequence 398 is already on disk as file
27
TROUG
archived log file
name=/home/oracle/app/oracle/admin/orcl/archive/1_398_701609923.dbf thread=1
sequence=398
archived log file
sequence=1
SQL> alter tablespace example online;
Tablespace altered.
Diğer yandan her zaman veritabanının kapanmadan önceki son anına dönmek istemeyiz.
Örneğin kullanıcı veya otomasyon kaynaklı hatalarda muhtemel yanlış veri girişi veya
silinmesi söz konusu olabilir. Böyle durumlarda hatanın oluşmadan önceki haline geri
dönmek isteyebiliriz. Bunun için de “restore database until time ‘<date>’ ” ve “recover
database until time ‘<date>’ ” komutunu vererek zaman içerisindeki daha önceki bir
duruma geri dönebiliriz (restore point in time). Burada dikkat edilmesi gereken bir durum,
veritabanını açarken resetlogs opsiyonu ile açmanız gerektiğidir. Sebebi ise oldukça basit,
geri dönüşünü gercekleştirdiğimiz veritabanı aslında bir önceki veritabanından farklı bir
veritabanı, eğer aynı veritabanı olsaydı veritabanı kapanmadan hemen önceki halinde
olması gerekirdi. Dolayısıyla aynı veritabanının farklı bir haliyle çalışmaya başlıyoruz
(incarnation).
RMAN> restore database until time "to_date('2011-12-06:13:00:00','YYYY-MMDD:HH24:MI:SS')";
28
TROUG
RMAN> recover database until time "to_date('2011-12-06:13:00:00','YYYY-MMDD:HH24:MI:SS')";
RMAN>
sql 'alter database open resetlogs';
sql statement: alter database open resetlogs
Şimdiye kadar sadece veri dosyası kayıplarını nasıl kurtarılabileceğinden bahsettik. Bundan
sonra da, controlfile, spfile gibi diğer veritabanı dosyalarının kaybını nasıl kurtaracağımıza
bakabiliriz. Dikkat ederseniz, RMAN repository controlfile üzerinde duruyor. Dolayısıyla
controlfile’i kaybetmek aldığımız tum yedeklerin bilgilerini (metadata) kaybetmek
anlamına geliyor. Her ne kadar RMAN yedeklerimiz disk üzerinde duruyor olsa da hangi
backupset’te hangi backuppiece ve bu backuppiece’lerde hangi veritabanı dosyalarının
tutulduğu bilgisi controlfile içerisindeki repository’de durur (catalog veritabanı olmadığı
durumlarda). Dolayısıyla controlfile’in güvenilirliği RMAN için oldukça önemlidir. Öyleyse
aşağıdaki örnekte olası bir controlfile kaybında yedekten nasıl kurtarabileceğimize bakalım.
Hatırlarsanız önceki bölümlerde bir komuttan bahsetmiştik “configure controlfile auto
backup on”, ve controlfile auto backup ‘in öneminden bu bölümde bahsedeceğimizi de
belirtmiştik. Şimdi controlfile kaybında veritabanımızı nasıl kurtaracağımıza bakalım.
29
TROUG
Öncelikle controlfile dosyası olmadığı için veritabanı mount mode’a gelemeyecektir. Şu
durumda veritabanını sadece nomount mode’da açabiliriz. Mount olmayan bir
veritabanının DBID (veritabanı tanımlayıcı) değeri de olamayacağından RMAN hangi
veritabanına baglı olduğunu bilemeyecektir. Dolayısıyla çalıştırmamız gereken ilk komut
SET DBID komutu olmalıdır. Şu halde DBID değerini nereden alabilecegimiz sorusu
gündeme gelir. Bu sorunun birkaç çözümu var. Birincisi daha önceki RMAN log’larında (tabi
eğer dosya sisteminde hala duruyorlarsa), RMAN, target veritabanına ilk bağlandığında,
hangi veritabanına bağlandığını belirtmek için DBID değerini ilk başta çıktısına yazar. Bir
diğer yöntem ise controlfile auto backup’dır. “show configure controlfile autobackup
format” komutuyla birlikte controlfile otomatik yedeklerinin alındığı dosya adını
görebilirsiniz. Varsayılan olarak bu dosya adi %F formatındadır. Bunun anlamı dosya
adında DBID’nin de bulunacagidir. Aşağıdaki kod bloğunda daha detaylı olarak görülebilir.
[oracle@localhost dbs]$ pwd
/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs
[oracle@localhost dbs]$ ls -l
total 28796
-rw-rw---- 1 oracle oracle 9830400 Dec 6 03:35 c-1229390655-20111206-02
-rw-rw---- 1 oracle oracle 9830400 Dec 6 05:55 c-1229390655-20111206-03
-rw-rw---- 1 oracle oracle
1544 Oct 2 2010 hc_DBUA0.dat
1544 Dec 6 05:55 hc_orcl.dat
-rw-r--r-- 1 oracle oracle
2851 May 15 2009 init.ora
-rw-r----- 1 oracle oracle
621 Oct 2 2010 initorcl.ora
24 Oct 2 2010 lkORCL
1536 Oct 2 2010 orapworcl
-rw-rw---- 1 oracle oracle 9748480 Dec 6 05:55 snapcf_orcl.f
3584 Dec 6 05:47 spfileorcl.ora
[oracle@localhost dbs]$ sqlplus / as sysdba
Connected to:
Database closed.
SQL> exit
30
TROUG
[oracle@localhost orcl]$ ls -l
total 2578308
2105344 Dec 6 07:17 APEX_1246426611663638.dbf
8396800 Dec 6 07:17 APEX_1265209995679366.dbf
9748480 Dec 6 07:17 control01.ctl
85991424 Dec 6 07:17 example01.dbf
52429312 Dec 6 07:17 redo01.log
52429312 Dec 6 05:55 redo02.log
52429312 Dec 6 05:55 redo03.log
-rw-rw---- 1 oracle oracle 1158684672 Dec 6 07:17 sysaux01.dbf
-rw-rw---- 1 oracle oracle 845160448 Dec 6 07:17 system01.dbf
20979712 Dec 6 07:00 temp01.dbf
-rw-rw---- 1 oracle oracle 138420224 Dec 6 07:17 undotbs01.dbf
-rw-rw---- 1 oracle oracle 230694912 Dec 6 07:17 users01.dbf
[oracle@localhost orcl]$ mv control01.ctl control01.ctl.delete
[oracle@localhost orcl]$ ls -lrt
total 2578308
52429312 Dec 6 05:55 redo03.log
52429312 Dec 6 05:55 redo02.log
20979712 Dec 6 07:00 temp01.dbf
52429312 Dec 6 07:17 redo01.log
85991424 Dec 6 07:17 example01.dbf
8396800 Dec 6 07:17 APEX_1265209995679366.dbf
2105344 Dec 6 07:17 APEX_1246426611663638.dbf
9748480 Dec 6 07:17 control01.ctl.delete
SQL> startup;
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
456146944
1344840
394267320
54525952
6008832
bytes
bytes
bytes
bytes
bytes
31
TROUG
ORA-00205: error in identifying control file, check alert log for more info
SQL> exit
connected to target database: ORCL (not mounted)
RMAN>
show controlfile autobackup format ;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
default
RMAN> set dbid 1229390655;
executing command: SET DBID
RMAN> restore controlfile from autobackup;
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20111206
channel ORA_DISK_1: AUTOBACKUP found: c-1229390655-20111206-03
channel ORA_DISK_1: restoring control file from AUTOBACKUP c-122939065520111206-03
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=/home/oracle/app/oracle/oradata/orcl/control01.ctl
output file
name=/home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl
RMAN> sql 'alter database mount';
sql statement: alter database mount
32
TROUG
/home/oracle/app/oracle/oradata/orcl/redo01.log
archived log file name=/home/oracle/app/oracle/oradata/orcl/redo01.log
thread=1 sequence=1
RMAN> sql 'alter database open resetlogs';
Eğer controlfile autobackup yedeği elimizde yoksa bu durumda içerisinde controlfile yedeği
olduğunu bildigimiz bir backupset’e ihtiyacımız vardır. Ihtiyacımız olan bir diğer parametre
ise DBID değeridir. Elimizdeki RMAN yedek loglarından bu bilgileri elde edebilirsek bu
durumda Aşağıdaki şekilde controlfile autobackup’ı olmaksızın veritabanı controlfile’ını
kurtarabiliriz.
[oracle@localhost ~]$ rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Fri Dec 16 14:00:48 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> list backup of controlfile;
List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------16
Full
9.36M
DISK
00:00:00
06-DEC-11
BP
Key:
16
Status:
AVAILABLE
Compressed:
NO
Tag:
TAG20111206T165549
Piece
Name:
/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2011_12_06/o1_mf_s
_769193749_7fxgdojs_.bkp
Ckp time: 06-DEC-11
RMAN> exit
33
TROUG
[oracle@localhost ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Fri Dec 16 15:03:16 2011
Connected to:
Database closed.
SQL> exit
[oracle@localhost orcl]$ mv control01.ctl control01.ctl.old
SQL*Plus: Release 11.2.0.2.0 Production on Fri Dec 16 15:50:15 2011
SQL> startup nomount;
Total System Global Area 456146944 bytes
Fixed Size
1344840 bytes
Variable Size
390073016 bytes
Database Buffers
58720256 bytes
Redo Buffers
6008832 bytes
SQL> exit
Recovery Manager: Release 11.2.0.2.0 - Production on Fri Dec 16 15:50:25 2011
connected to target database: ORCL (not mounted)
RMAN> set DBID 1229390655;
executing command: SET DBID
RMAN>
restore
controlfile
from
'/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2011_12_06/o1_mf_
s_769193749_7fxgdojs_.bkp';
34
TROUG
channel ORA_DISK_1: restoring control file
output file name=/home/oracle/app/oracle/oradata/orcl/control01.ctl
output
name=/home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl
file
RMAN> sql 'alter database mount';
sql statement: alter database mount
Starting implicit crosscheck backup at 16-DEC-11
Crosschecked 6 objects
Finished implicit crosscheck backup at 16-DEC-11
Starting implicit crosscheck copy at 16-DEC-11
Finished implicit crosscheck copy at 16-DEC-11
searching for all files in the recovery area
cataloging files...
cataloging döne
List of Cataloged Files
=======================
File
Name:
/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2011_12_06/o1_mf_s
_769193749_7fxgdojs_.bkp
archived
log
file
name=/home/oracle/app/oracle/oradata/orcl/redo03.log
thread=1 sequence=390
archived
log
file
archived
log
file
35
TROUG
RMAN>
Redolog kayıplarında durum şimdiye kadar ele aldığımız kadar kolay değil. RMAN redolog
yedeklerini almadığı için, redolog gruplarının mutlaka birden fazla redolog dosyası ile farklı
disk gruplarına mirrorlanması önerilir. Eğer buna rağmen redolog kaybı yaşanırsa, son
arşivlog dosyasına kadar recover işlemi (recover until cancel) yapılıp veritabanını resetlogs
opsiyonu ile açmamiz gerekir. Aşağıdaki örnekte detaylı olarak incelenebilir.
[oracle@localhost orcl]$ mv redo01.log redo01.log.delete
[oracle@localhost orcl]$ ls -l
total 2578316
2105344 Dec 6 09:34 APEX_1246426611663638.dbf
8396800 Dec 6 09:34 APEX_1265209995679366.dbf
9748480 Dec 6 09:34 control01.ctl
85991424 Dec 6 09:34 example01.dbf
52429312 Dec 6 09:34 redo01.log.delete
20979712 Dec 6 08:28 temp01.dbf
SQL> startup nomount;
Total System Global Area
Fixed Size
Variable Size
456146944 bytes
1344840 bytes
394267320 bytes
36
TROUG
Database Buffers
54525952 bytes
Redo Buffers
6008832 bytes
SQL> alter database mount;
Database altered.
[oracle@localhost archive]$ ls -l
total 15204
-rw-rw---- 1 oracle oracle 5017600 Dec
-rw-rw---- 1 oracle oracle 10520576 Dec
6 07:21 1_1_769154109.dbf
6 05:55 1_398_701609923.dbf
RMAN> restore database;
RMAN> recover database until sequence 1;
37
TROUG
archived log file
sequence=398
archived log file
sequence=1
Silinen arşivlog’ları geri dönmek oldukça kolaydır. Tek yapılması gereken “recover
archivelog” komutunu gerekli opsiyonlar ile kullanmak. Burada dikkat edilmesi gereken
gerekli opsiyonlar kısmı olmalı. Eğer oldukça haraketli bir veritabanınız varsa arşivlog
üretimi de oldukça fazla olacağından disk alanı kullanımınızı önemli ölçüde arttırabilirsiniz.
Dolayısıyla sadece recovery işlemi için gerekli olan arşivleri dönmekte fayda var.
Bahsedilen opsiyonlardan bazılarını aşağıdaki örnekte görebilirsiniz;
RMAN> list backup of archivelog all;
List of Backup Sets
===================
BS Key Size
------- ---------- ----------- ------------ --------------29
2.49M
DISK
00:00:00
06-DEC-11
BP Key: 29
TAG20111206T101015
Piece Name: /home/oracle/app/oracle/admin/orcl/11mth607_1_1
List
Thrd
---1
1
1
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------1
9261705
06-DEC-11 9263976
2
9263976
06-DEC-11 9263999
3
9263999
06-DEC-11 9264023
Next Time
--------06-DEC-11
06-DEC-11
06-DEC-11
38
TROUG
1
1
4
5
9264023
9264061
06-DEC-11 9264061
06-DEC-11 9264109
06-DEC-11
06-DEC-11
RMAN> list backup of archivelog from sequence 2 until sequence 4;
List of Backup Sets
===================
BS Key Size
------- ---------- ----------- ------------ --------------29
2.49M
DISK
00:00:00
06-DEC-11
BP Key: 29
TAG20111206T101015
Piece Name: /home/oracle/app/oracle/admin/orcl/11mth607_1_1
List
Thrd
---1
1
1
Seq
Low SCN
Low Time Next SCN
------- ---------- --------- ---------2
9263976
06-DEC-11 9263999
3
9263999
06-DEC-11 9264023
4
9264023
06-DEC-11 9264061
Next Time
--------06-DEC-11
06-DEC-11
06-DEC-11
RMAN> restore archivelog from sequence 2 until sequence 4;
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=2
/home/oracle/app/oracle/admin/orcl/11mth607_1_1
handle=/home/oracle/app/oracle/admin/orcl/11mth607_1_1 tag=TAG20111206T101015
39
TROUG
RMAN ile block corruption hatalarını gidermek
Herhangi bir donanım arızasından veya erişim süresinin dolması sebebiyle bir veri
dosyasının bir veya birkaç bloğu zarar görebilir. Bu gibi durumlarda tüm veritabanını veya
sadece ilgili veri dosyasını geri dönmek her ne kadar işimizi gorse de, gerek operasyon,
gerekse downtime süresinin uzunluğu açısından oldukça maliyetli bir işlemdir. RMAN
yedekleri blok seviyesinde çalıştığı için bir veri dosyasının sadece bir bloğunu
kurtarabiliriz. RMAN’in bize sağladığı en büyük avantajlardan birisi de budur.
Bu işlem için öncelikle hangi veri dosyasının hangi block’larının bozulduğunu
tanımlamamız gerekir. Bunun için bir kaç yöntem vardır. En bilinen yöntem daha eski
veritabanı versiyonlarindan beri süregelen “dbverify” aracıdır. Bu aracı $ORACLE_HOME
/bin/dbv olarak kullanabilirsiniz. Fakat bu bir RMAN dökümanı olduğu için bozulan
blok’ları (corrupted blocks) RMAN komutları ile kurtaracağız. Tabi öncelikle bir veri
dosyasının bir bloğunu bozmamız gerekiyor, hemen ardından “backup validate database”
komutu ile bozulan blokların v$database_block_corruption tablosuna yazılmasını ve
ardından “blockrecover datafile <datafile#> block <block#> | corruption list” komutu ile
RMAN’in bozulan blok’ları kurtarmasını bekliyoruz.
Burada “backup validate database” komutu, RMAN’in tüm veri dosyalarını sanki yedeğini
alacakmış gibi okumasını fakat yedeğini almamasını sağlıyor. Aslında bir yedekleme
simulasyonu yaparak veritabanı yedeğini sağlıklı bir şekilde alıp alamayacağını test ediyor.
Aşağıda örneğini göreceğimiz özel durumda, veri dosyasının birisinde corrupt block
olduğundan dolayı, RMAN’in bu yedeği gerçekleştiremeyeceğini logladığını görüyoruz.
[oracle@localhost orcl]$ dd if=/dev/zero
of=/home/oracle/app/oracle/oradata/orcl/users01.dbf bs=8k conv=notrunc seek=10
count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.00071387 seconds, 11.5 MB/s
[oracle@localhost orcl]$
RMAN> backup validate database;
40
TROUG
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ---------1
OK
0
13118
103170
9265409
File Name: /home/oracle/app/oracle/oradata/orcl/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ---------------Data
0
70965
Index
0
15417
Other
0
3668
---- ------ -------------- ------------ --------------- ---------2
OK
0
15264
141509
9265440
File Name: /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
---------- -------------- ---------------Data
0
31161
Index
0
18204
Other
0
76811
---- ------ -------------- ------------ --------------- ---------3
OK
0
0
16904
9265440
File Name: /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
---------- -------------- ---------------Data
0
0
Index
0
0
Other
0
16896
---- ------ -------------- ------------ --------------- ----------
41
TROUG
4
FAILED 0
2825
28162
8571853
File Name: /home/oracle/app/oracle/oradata/orcl/users01.dbf
---------- -------------- ---------------Data
0
3735
Index
0
1539
Other
1
20061
---- ------ -------------- ------------ --------------- ---------5
OK
0
1580
10501
5843748
File Name: /home/oracle/app/oracle/oradata/orcl/example01.dbf
---------- -------------- ---------------Data
0
3947
Index
0
1110
Other
0
3859
---- ------ -------------- ------------ --------------- ---------6
OK
0
1
257
7045119
File Name: /home/oracle/app/oracle/oradata/orcl/APEX_1246426611663638.dbf
---------- -------------- ---------------Data
0
0
Index
0
0
Other
0
255
---- ------ -------------- ------------ --------------- ---------7
OK
0
235
1025
7570545
File Name: /home/oracle/app/oracle/oradata/orcl/APEX_1265209995679366.dbf
---------- -------------- ---------------Data
0
194
Index
0
102
Other
0
493
validate found one or more corrupt blocks
See trace file
/home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8677.trc for
details
List of Control File and SPFILE
===============================
42
TROUG
File Type
Status Blocks Failing
------------ ------ -------------SPFILE
OK
0
Control File OK
0
Blocks Examined
--------------2
594
RMAN> backup validate tablespace users;
List of Datafiles
=================
---- ------ -------------- ------------ --------------- ---------4
FAILED 0
2825
28162
8571853
---------- -------------- ---------------Data
0
3735
Index
0
1539
Other
1
20061
validate found one or more corrupt blocks
See trace file
/home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8677.trc for
details
SQL> select * from v$database_block_corruption;
FILE#
BLOCK#
BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ --------4
10
1
0 ALL ZERO
RMAN> blockrecover datafile 4 block 10;
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00004
43
TROUG
/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_12_06/o1_mf_nn
ndf_TAG20111206T160407_7fxccrx8_.bkp
1_mf_nnndf_TAG20111206T160407_7fxccrx8_.bkp tag=TAG20111206T160407
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:03
RMAN> backup validate tablespace users;
List of Datafiles
=================
---- ------ -------------- ------------ --------------- ---------4
OK
0
4116
28160
8571853
---------- -------------- ---------------Data
0
3820
Index
0
1542
Other
0
18682
SQL> select * from v$database_block_corruption;
no rows selected
RMAN’de Script Kullanımı
RMAN içerisinde scriptler yazarak ardışıl komutları cağırabilirsiniz. Bunun için yazmak
istediğiniz ardışıl komutları alt alta yazarak bir “run” bloğu içerisine koyabilirsiniz. Ayrıca
44
TROUG
bu blok için bir dosya hazırlayıp RMAN’e bu dosyayı çalıştırmasını bildirebilirsiniz. Örneğin
bir veritabanı yedeği almak için tek tek komutları çalıştırıp çıktılarını beklemek yerine
aşağıdaki gibi bir script hazırlanabilir.
Script’lerde dikkat edilmesi gereken noktalardan birisi de, run bloğu içerisinde tanımlanan
tüm parametrelerin blok sonunda etkisini yitirmesidir. Dolayısıyla bu dökümanın en
basında ayarladığımız channel ayarlarını run bloğu içerisinde ezebilir ve sadece ilgili blok
içerisinde tanımlanmış channel ayarlarını kullanarak yedek alabilirsiniz. Hem de RMAN
varsayılan değerlerini değiştirmiş olmazsınız.
RMAN> run{
allocate channel disk1 device type disk format
'/home/oracle/app/oracle/admin/orcl/backup/%U';
crosscheck archivelog all;
backup archivelog all delete all input;
backup database;
backup current controlfile;
backup spfile;
}
veya bu script’i bir dosya içerisine yazıp RMAN’e bu dosyayı çalıştırmasını söyleyebilirsiniz.
[oracle@localhost backup]$ rman target / cmdfile backup.rman
RMAN> run{
2> allocate channel disk1 device type disk format
'/home/oracle/app/oracle/admin/orcl/backup/%U';
3> crosscheck archivelog all;
4> backup archivelog all delete all input;
5> backup database;
6> backup current controlfile;
7> backup spfile;
8> }
9>
allocated channel: disk1
channel disk1: SID=39 device type=DISK
45
TROUG
Script olarak çalıştırılabilecek bir başka örnek ise block corruption validasyonlarının
düzenli olarak yapılması ve herhangi bir veri dosyasında block corruption bulunduğunda
blockrecover komutunun çalıştırılması. Aslında oldukça basit bir script ile bu iş
halledilebilir.
RMAN> run{
2> backup validate database;
3> blockrecover corruption list;
4> }
46

Oracle 11g Veritabanları için Yüksek Erişilebilirliğe Giriş Serisi

Transkript

Benzer belgeler

OEM Grid Control 11gR1 Kurulumu - Talip Hakan Öztürk`s ORACLE

oracle database 11g r2 kurulumu

RAC

PDF versiyonu - Çağatay ÇEBİ

RAC Kurulumu