Menü

Oracle RMAN Backup and Recovery'yi Doğrulayın (Uygulamalı Eğitim)

validate oracle rman backup

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Oracle RMAN Backup Nasıl Oluşturulur ve Doğrulanır: RMAN Komutları ve Kurtarma süreciyle öğrenin

java nesne dizisi nasıl oluşturulur

Bu eğiticide, Oracle veritabanı yedeklerinizin doğrulanmasını ve test edilmesini tartışacağız. Veritabanı yedeklemeleri hakkında ne, neden ve nasıl gibi kavramları ve yedeklemeyi test etme yöntemlerini açıklayacağız.

Biz alacağız Oracle veritabanı bu eğitim için bir vaka çalışması olarak.

Vaka Analizi: Oracle RMAN Veritabanı Yedeklemelerini Test Etme:

Oracle RMAN Yedekleme ve Kurtarma Testi

Ne öğreneceksin:

RMAN Kullanarak Oracle Veritabanı Yedekleme Doğrulama Süreci

Aşağıdaki dört bölüme ayırdık

  1. Yedek nedir?
  2. Neden yedekleme?
  3. Nasıl yedeklenir?
  4. Veritabanı yedeklemenizi nasıl test edebilir / doğrulayabilirsiniz - Kurtarma Stratejileri?

Ayrıca oku=> Veritabanı testi hakkında her şey

Veritabanı Yedeklemesi nedir?

Yedeklemeler hakkında daha fazla bilgi edinmeye başlamadan önce, bir kuruluşun en önemli varlığı olan Verileri anlamamız gerekir. Kuruluşunuzun Oracle veritabanı üzerinde çalıştığını düşünün. 'Veritabanı' terimini anlamak için, Oracle Database Testing serisi burada .

Bir kuruluşun verileri, bir kuruluşun en ayrılmaz parçasıdır. Bir perakende, bankacılık şirketi düşünün. Hepsinde muazzam miktarda veri vardır - kullanıcı, sistem, vb. Bir veritabanı yöneticisi olarak, Sistem yöneticisi veya bu verileri korumak için görevlendirilen herhangi bir personel, verilerin bir kuruluş için ne kadar önemli olduğunun farkında olmalıdır. Verilerin her zaman ulaşılabilir olduğundan nasıl emin olunur? Bu verileri yedekleyin.

Yedek, herhangi bir veri kaybı durumunda verilerinizi yeniden yapılandırmanıza yardımcı olabilecek, veritabanınızın tam bir kopyasıdır.

Veritabanı yedeklemesini test et 1

Neden Yedekleme Veritabanı?

Hesap numaraları, isimler, adaylar, banka bakiyesi ve kuruluş açısından milyonlarca müşteriyle ilgili verilere sahip olan bankacılık organizasyonunuzun tüm verilerini kaybettiği basit bir durumu düşünün, müşterileri buna nasıl tepki verirdi? Organizasyon bu kadar çok veriyi kaybetmenin baskısıyla nasıl başa çıkacak? Bu kadar çok müşteri memnuniyetsizliğine nasıl cevap verebilirler?

Bu nedenle, bir diskin (depolama), disk denetleyicisinin (depolama denetleyicisinin) herhangi bir arızası durumunda, yedeklememize her zaman güvenebilmemiz için bu verileri yedeklememizin nedeni budur. müşteriler herhangi bir verilerini kaybeder.

Varsayımsal olarak, milyonlarca müşteri olduğunu ve her birinin milyonlarca işlem gerçekleştirdiğini ve veri tabanının yanlışlıkla çöktüğünü ve verilerini kaybettiğini varsayalım, tüm bu müşterilerimizden verilerini yeniden girmelerini ister miydik? Bu kadar çok veriyi kaybetmekle nasıl başa çıkabilirsiniz? Bu kesinlikle kabul edilemez.

Benzer şekilde, milyonlarca müşteriyi destekleyen ve telefon numaraları, adresler, kullanılan kredi, bekleyen ödemeler ile ilgili tüm verilerine sahip bir telekomünikasyon şirketi düşünün. Ya onların tüm verilerini kaybedersek? Şirket ölüme mahkumdur ve muhtemelen organizasyonu durma noktasına getiren büyük maliyetler üstlenmek zorunda kalacaktır. Kesinlikle büyük bir felaket olur.

Veritabanı Nasıl Yedeklenir?

Oracle Veritabanında verileri yedeklemek için birkaç yöntemimiz var. Genel olarak fiziksel ve mantıksal yedeklemeler olarak sınıflandırılabilirler

Yöntem 1)Fiziksel Yedeklemeler :

  1. 3rdparti yedekleri - Veritas NetBackup, SAP, IBM Tivoli Manager, EMC, HP gibi
  2. Kullanıcı tarafından yönetilen yedeklemeler - Copy (windows), cp (Unix) gibi işletim sistemi yardımcı programlarını kullanarak bir veritabanının yedeklenmesi.
  3. Oracle Güvenli Yedekleme
  4. En sevdiğim ve en çok tercih edilen Oracle yardımcı programı - Recover Manager ( RMAN ).

Yöntem 2)Mantıksal yedeklemeler:

  1. Geleneksel Dışa Aktarma / içe aktarma yardımcı programları ve Veri pompası yardımcı programları. Mantıksal yedekleme, mantıksal verilerin yedeğidir - yukarıdaki nesnelerin konumundan bağımsız bir veritabanının bileşenleri olan tablolar, dizinler vb. Nesneler.

Bir veritabanının fiziksel ve mantıksal depolama yapılarını anlamak için başvurabilirsiniz bu ve bu oracle belgeleri .

Veritabanı Yedeklemesi için en iyi yöntem hangisidir?

Bu yedekleme stratejilerinin her birinin kendi artıları ve eksileri vardır ve bu makalede bunlarla çok fazla ilgilenmeyeceğiz.

Fiziksel bir yedeklemeniz olmadıkça, yalnızca mantıksal bir yedeklemeye sahip olmanın fiziksel veri bozulması, donanım depolama sorunları için her zaman güvenli olmadığını anlamamız gerekir. Geçerli ve iyi bir fiziksel yedeklemeye sahip olmak, onu iyi bir yedekleme ve kurtarma stratejisi haline getirir. Her zaman yerinde fiziksel bir yedeğiniz olduğundan emin olun.

Gerçekte, yukarıdaki yöntemlerden herhangi birini kullanabiliriz, ancak bir veritabanının işleyişi sırasında herhangi bir gereksiz aksaklıktan kaçınmak için her zaman iyi bir yedekleme ve kurtarma stratejisine sahip olduğumuzdan emin olmamız gerekir. Geri ve kurtarma stratejilerinizi yansıtılmış bir test sisteminde test etmeniz her zaman tavsiye edilir, böylece öngörülemeyen herhangi bir durumda veritabanınızı çalışır duruma getirmek için gereken süreyi tahmin edebiliriz.

Bu yazıda esas olarak RMAN yedeklemelerine odaklanacağız. Bu bizi yedeklemeyi tam olarak nasıl gerçekleştirdiğimizi bilme noktasına getiriyor.

Oracle RMAN (Oracle Recovery Manager) Yedekleme Komutları

Verileri Enterprise Manager (GUI) modu yardımıyla veya işletim sistemi komut satırı istemi aracılığıyla yedekleyebiliriz.

Veritabanı yedeklemesini test et 2

RMAN Oracle tarafından yedekleme ve kurtarma gerçekleştirmek için sağlanan sağlam, gelişmiş bir araçtır.

RMAN Oracle veritabanını kurduğunuzda otomatik olarak kurulur, böylece kullanmak için herhangi bir ek kurulum gerekmez RMAN .

RMAN çevre iki bileşenden oluşur:

1) Hedef veritabanı (yedekleyeceğiniz, kurtaracağınız ve

2) Hedef Veritabanına bağlanırken kullanıcı komutlarını yorumlayan ve kullanıcı adına yürüten istemci olan RMAN istemcisi.

RMAN kullanarak veritabanına bağlanmak için basit bir komut aşağıdaki gibidir:

C:Usersxyz> rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Sun Sep 28 17:32:48 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1361070653) RMAN>

Buradaki DBID, birlikte çalışmayı planladığımız her veritabanı için benzersiz olan benzersiz tanımlayıcıdır.

Bu örnekte, adlı bir veritabanıyla uğraşıyoruz ORCL .

ORCL veritabanına ait verileri yedekleyeceğiz.

Yedekleme, veritabanınızın fiziksel bir kopyası olduğundan, onları kaydedebileceğimiz bir konuma / dizine ihtiyacımız var.

Bunu başarmak için adında özel bir dizin kullanabiliriz. db_recovery_file_dest yedekleme konumu olarak hizmet eder. Bu parametrenin boyutunu şu şekilde tanımlayın: db_recovery_file_dest_size bu yedekleme konumunun boyutunu gösterir.

Yedeklerinizi sıkıştırmanın birkaç yolu ve bir yedeklemenin boyutunu azaltabilecek çeşitli teknikler olsa da, en azından DB_RECOVERY_FILE_DEST_SIZE veritabanınızdaki gerçek verilerinizin bir boyutuna. Veri bloklarınızdaki değişiklikleri kaydeden çevrim dışı yineleme günlüklerinden başka bir şey olmayan arşiv günlüklerini de hesaba kattığınızdan emin olun.

Yedekleme stratejiniz, veri dosyaları, kontrol dosyaları, parametre dosyaları, ağ ile ilgili dosyalar, arşivlenmiş yineleme günlük dosyaları gibi veritabanıyla ilgili tüm dosyalardan oluşur.

RMAN veya diğer herhangi bir fiziksel yedekleme aracı, veri dosyalarını, kontrol dosyalarını, parametre dosyalarını, arşivlenmiş tekrarlama günlük dosyalarını yedekleyebilir. Ağ ile ilgili dosyaların cp veya copy gibi işletim sistemi yardımcı programları kullanılarak manuel olarak yedeklenmesi gerekir.

Kullandığımız bir veritabanını yedeklemek için:

'Yedekleme veritabanı' - bu kadar basit. Öyleyse, ORCL veritabanımızı yedeklemeye başlayalım.

Hedef veritabanına (ORCL) zaten bağlandığımız için, “veritabanı yedekleme” komutunu çalıştırıyoruz.

Veritabanı yedeklemesini test etme 3

RMAN> backup database; Starting backup at 05-OCT-14 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=198 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=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:04:27 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04 Finished backup at 05-OCT-14

Burada veritabanının ilgili tüm dosyalarının - veri dosyaları, kontrol dosyaları, spfile (parametre dosyası) yedeğinin tamamlandığını görüyoruz. Yedekleme işlemi yaklaşık 4 dakika 27 saniye sürdü (Geçen süre). Bu, yalnızca 5 veri dosyası içeren küçük bir test veritabanıdır, bu nedenle yedeklemesi çok daha kısa sürer.

Dev kuruluşların veritabanlarından veri yedeklemek istediğimiz durumlarda, yüzlerce veri dosyası olabilir ve her veri dosyası terabayt boyutlarında olabilir ve veritabanının tam bir yedeğini almak potansiyel olarak saatler sürebilir.

Yeni oluşturduğumuz yedeklemeyle ilgili ayrıntıları bilmek için şunları yapacağız:

RMAN> yedekleme listesi;

Veritabanı yedeklemesini test et 4

List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5 Full 9.58M DISK 00:00:06 05-OCT-14 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP SPFILE Included: Modification time: 05-OCT-14 SPFILE db_unique_name: ORCL Control File Included: Ckp SCN: 9705762 Ckp time: 05-OCT-14

Bu yedekleme, D: APP1 SUNTYADA FLASH_RECOVERY_AREA olarak tanımlanan DB_RECOVERY_FILE_DEST konumuna yerleştirilir.

SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string D:app1suntyadaflash_recovery_area db_recovery_file_dest_size big integer 3912M

Yedek konumumuz için tanımlanan boyut 3912 MB'dir.

Veritabanı dosyalarını ve yedeklemeleri kontrol etmek için VALIDATE kullanın:
RMAN> VERİ TABANI DOĞRULA;

RMAN Yedeklemesini Doğrula

Herhangi bir kriz anında veri tabanımızı kurtarabileceğimizi nasıl test ederiz veya onaylarız?

Donanım arızası veya depolama disklerinizin bir miktar bozulması nedeniyle, bu bozuk verileri geri yüklemek için iyi bir yedeklemeye ihtiyacımız olacak, böylece bu depolama dosyalarına ait olan hiçbir veriyi kaybetmeyeceğiz.

Her şey yedeklemeleri nasıl tasarladığınıza, yedeklemelerin planlandığı aralıklara, tam bir yedekleme alıp almadığınıza ve artımlı yedeklemelere sahip olup olmadığınıza bağlıdır.

Kullanıcı hataları durumunda - verilerin gereksiz yere manipüle edilmesi gibi, mantıksal yedeklemeler yoluyla değiştirilen verilerin bir kısmını veya tüm verileri geri yükleyebiliriz.

Uygulamada, gelecekte oluşabilecek hataların farkında olmalı ve öngörebilmeli ve bunlardan kaçınmak için her stratejiyi test etmeliyiz.

Yedekleme dosyalarını doğrulamak için BACKUP VALIDATE komutunu kullanın:

Yalnızca fiziksel bozulma kontrolü komutu:

RMAN> YEDEKLE DOĞRULA
VERİ TABANI
TÜM ARŞİVELOG;

Fiziksel ve mantıksal bozulma kontrolü için komut:

RMAN> YEDEKLE DOĞRULA
MANTIKI KONTROL ET
VERİ TABANI
TÜM ARŞİVELOG;

RMAN> YEDEKLEME DOĞRULAMA VERİTABANI ;

Test veritabanı yedeklemesi 5 yeni

Starting backup at 05-OCT-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DB input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DB input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 OK 0 13430 106376 9708800 File Name: D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 75217 Index 0 12706 Other 0 5015 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 2 OK 0 21161 95409 9708826 File Name: D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 23010 Index 0 21760 Other 0 29429 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 3 OK 0 0 5762 9708826 File Name: D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 5760 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 4 OK 1125 228 5765 9528788 File Name: D:APP1SUNTYADAORADATAORCLUSERS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 2295 Index 0 39 Other 0 3198 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 5 OK 0 1687 10498 9585679 File Name: D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 4760 Index 0 1261 Other 0 2788 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined ------------ ------ -------------- --------------- SPFILE OK 0 2 Control File OK 0 608 Finished backup at 05-OCT-14

Yukarıda görebileceğiniz gibi, her dosyanın Durumu ' TAMAM MI 'Bu, bunların kullanılabilir olduğu ve dosyaları herhangi bir zamanda geri yüklemek için kullanılabileceği anlamına gelir.

Veritabanı geri yüklemesinin bir ön izlemesini yapabiliriz. Bu size dosyaları gerçekten geri yüklemeden dosyaların güzel bir listesini ve kullanılabilirliklerini verir.

Yedeklemeyi doğrulamak için RESTORE komutunu kullanın:

RMAN> VERİ TABANINI GERİ YÜKLE VALIDATE;
ARŞİVELOĞU GERİ YÜKLE TÜMÜNÜ DOĞRULAYIN;

RMAN> VERİTABANI ÖNİZLEMESİNİ GERİ YÜKLE;

Veritabanı yedeklemesini test et 6

Starting restore at 05-OCT-14 using channel ORA_DISK_1 List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF List of Archived Log Copies for database with db_unique_name ORCL ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 367 1 366 A 02-OCT-14 Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLARCHIVELOG2014_10_05O1_MF_1_366_B32925TJ_.ARC Media recovery start SCN is 9684060 Recovery must be done beyond SCN 9704654 to clear datafile fuzziness Finished restore at 05-OCT-14

Sonuç

Bunlar sadece basit tekniklerdir Oracle RMAN yedeklerinizi doğrulayın. Çeşitli önemli RMAN komutlarının yardımıyla RMAN yedekleme ve kurtarma sürecini net bir şekilde anladığınızı umuyoruz.

Gerçek durumda verilerin boyutuna dayalı senaryolar olmasına rağmen, birkaç yüz veri dosyamız olabilir ve iyi bir yedekleme stratejisine sahip olmak için her birini yedeklediğimizden emin olmalıyız. Ayrıca, kurtarmayı test et Üretimde aynı teknikleri kullanabileceğinizden emin olmak için test sistemlerinde.

Kritik / test veritabanlarınızı yedeklemek için farklı yöntemler ve bunları test etmek için çeşitli yöntemler ele aldık. Zaten defalarca önerildiği gibi, iyi bir yedekleme ve kurtarma stratejisine sahip olmak işinizi ve kuruluşunuzu kurtaracaktır.

Oracle veya diğer Veritabanı yedekleme ve kurtarma testleri ile ilgili herhangi bir sorunuz varsa bize bildirin.

Önerilen Kaynaklar

^