Oracle’a ilgi duyan, Oracle ile tanışmak isteyen, Neden Oracle diyen ve kariyer hedefim Oracle DBA diyen tüm öğrenci arkadaşlarımı beklerim.

6 Aralık  salı günü buluşmak üzere…

Adres: Fatih Üniversitesi, 34500 Büyükçekmece, İstanbul

Veritabanı temel kavramlar, veritabanı olmazsa neler olur, Oracle veritabanı mimarisi ve veritabanı bileşenlerini küçük demolarla öğreneceğiz. İkinci bölümde Oracle veritabanı yöneticisi  olmak için kariyer basamaklarını nasıl çıkacağımız konusunda fikir sahibi olacağız.

26 Kasım cumartesi günü buluşmak üzere…

Sunumun 1. bölümü için tıklayınız.

Oracle & High availability

Oracle veritabanı yüksek kullanılabilirlik (High Availability) özelliklerini kapsamlı bir şekilde sunan, sektörde benzersiz bir üründür. Real Application Clusters (RAC), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Online Reorganization, Edition-based Redefinition gibi yüksek kullanılabilirlik özelliklerini barındırır. Bu özellikler ile entegre bir şekilde çalışabilen Oracle Secure Backup ve Oracle GoldenGate gibi tamamlayıcı ürünler, planlı ve plansız kesintileri azaltacak en iyi çözümü sunmaktadır. Bu seminerde yüksek kullanılabilirlik hakkında bilgi sahibi olacağız.

Oracle & High availability (Azerice)

Oracle verilənlər bazası yüksək mövcudluq (High Availability) xüsusiyyətlərini əhatəli bir şəkildə təqdim edən, sektorda bənzərsiz bir məhsuldur. Real Application Clusters (Rac), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Qonaqlar Reorganization, Edition-based Redefinition kimi yüksək mövcudluq xüsusiyyətlərini saxlayır. Bu xüsusiyyətlər ilə inteqrasiya bir şəkildə işləyə bilən Oracle Secure Backup və Oracle GoldenGate kimi tamamlayıcı məhsullar, planlı və plansız kəsilməyə azaldacaq ən yaxşı həlli təqdim etməkdədir. Bu seminarda yüksək mövcudluq haqqında məlumat sahibi olacağıq.

Oracle & High availability

Oracle veritabanı yüksek kullanılabilirlik (High Availability) özelliklerini kapsamlı bir şekilde sunan, sektörde benzersiz bir üründür. Real Application Clusters (RAC), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Online Reorganization, Edition-based Redefinition gibi yüksek kullanılabilirlik özelliklerini barındırır. Bu özellikler ile entegre bir şekilde çalışabilen Oracle Secure Backup ve Oracle GoldenGate gibi tamamlayıcı ürünler, planlı ve plansız kesintileri azaltacak en iyi çözümü sunmaktadır. Bu seminerde yüksek kullanılabilirlik hakkında bilgi sahibi olacağız.

Oracle & High availability

Oracle verilənlər bazası yüksək mövcudluq (High Availability) xüsusiyyətlərini əhatəli bir şəkildə təqdim edən, sektorda bənzərsiz bir məhsuldur. Real Application Clusters (Rac), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Qonaqlar Reorganization, Edition-based Redefinition kimi yüksək mövcudluq xüsusiyyətlərini saxlayır. Bu xüsusiyyətlər ilə inteqrasiya bir şəkildə işləyə bilən Oracle Secure Backup və Oracle GoldenGate kimi tamamlayıcı məhsullar, planlı və plansız kəsilməyə azaldacaq ən yaxşı həlli təqdim etməkdədir. Bu seminarda yüksək mövcudluq haqqında məlumat sahibi olacağıq.

Bu makalemde Oracle ın felaket kurtarma (disaster recovery) çözümü olan Data Guard temel terminolojisi hakkında kısa kısa bilgi vereceğim.

Öncelikle Felaket(Disaster) kelimesini anlamaya çalışalım. Televizyon, radio, gazete v.s. medya aracılığı ile dünyanın bir çok yerinde bazı felaketlerin meydana geldiğini hepimiz görmekteyiz. Endonezyadaki tsunami, Amerikadaki kasırga ve hortumlar, yakın geçmişte yaşadığımız 1999 depremi bunlardan bazılarıdır. İşte bu gibi olaylara felaket (disaster), diğer bir söylemle afet diyoruz. Doğal afetler sonucu veri merkezimizi (datacenter) kaybedecek olursak, bunun bize olan bedeli eminim ki çok ağır olacaktır. Verilerimiz bizim için çok değerlidir hatta şirketimizin hazinesidir diyebiliriz. Sadece doğal afetler değil, anlık elektrik kesintisi, disk arızaları ve kullanıcı hataları gibi olaylarda verilerimizi kaybetmeye sebebiyet verebilmektedir.

Bizler veri yöneticileri olarak tüm bu felaketler oluşmadan gerekli aksiyonları almakla yükümlüyüz. Gerekli aksiyonları alırken de göz önünde bulundurmamız gereken önemli bileşenler vardır. Bu bileşenler;

RPO (Recovery Point Objective) – Ne kadar veri kaybetmeyi göze alabilirsiniz?

RTO (Recovery Time Objective) - Veri erişimi olmadan kaç dakika ayakta durabilirsiniz ?

Bu sorulara vereceğimiz mantıklık cevaplara göre hızlıca yedek sistemimizi kuruyor olmalıyız. Sistemimizi sadece kurmakla yetinmeyip, canlı verilerimizle yedek sistemimizi besmeli ve bu beslemeyide sıkı takip ediyor olmalıyız.

Şimdi ORACLE ın bu konudaki güzel çözümü Data Guard ı tanıyalım.

Data Guard ORACLE ın felaket kurtarma (disaster recovery) çözümüdür. Canlı (production) veritabanınızı felaketlerden korur, üzerindeki iş yükünü azaltır ve daha efektif kullanılmasını sağlar. Teknoloji, ilk olarak Oracle 7 ile manuel standby veritabanı oluştururarak kullanılmaya başlandı. Oracle 8i ile Data Guard olarak karşımıza çıktı. Geçmişten günümüze Data Guard a gelen özellikeleri inceleyecek olursak;

ORACLE 8i

Read-Only Standby Veritabanı

Managed recovery

Redo Log dosyalarını Uzak(Remote) arşivlenmesi

ORALCE 9i

“Zero Data Loss” Entegrasyonu

Data Guard Broker ve Data Guard Manager GUI

Swithcover ve Failover işlemleri

Otomatik senkronizasyon

Logical Standby Veritabanı

Maximum Protection

ORACLE 10g

Real-Time Apply

RAC için güçlendirilmiş destek

Fast-Start Failover

Asenkron redo transferi

Data Guard switchover karşı Flashback Database

ORACLE 11g

Active Standby Veritabanı(Active Data Guard)

Snapshot Standby

Heterojen platform desteği (Production –Linux, Standby – Windows)

Özellikleri ile zaman içinde gelişerek bugünkü halini almıştır. Bugün 11g ile sağladığı özellikler bakımından DBA lerin vazgeçemediği bir sistemdir.

DATA GUARD 11g PROCESS MİMARİSİ SENKRON REDO TRANSFERİ (SYNC)-SIFIR VERİ KAYBI (ZERO DATA LOSS)

İşlem akışı kısaca;

1 – Kullanıcı bir transaction başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar

2 – LNS (LogWriter Network Service) commitlenmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – RFS verinin başarılı işlendiği bilgisini LNS e gönderir. LNS bu bilgiyi LGWR a aktarır. Son olarak kullanıcıya başlatmış olduğu işlemin (transaction) commit edildiği bilgisi gönderilir.

Senkron redo transferi ile veri transferi garanti altına alınır. Ama bir dezavatajı vardır. canlı veritabanı (Primary) ile yedek veritabanı (Standby) arasında bir network kesintisi oluşursa veya bir şekilde Primary veritabanı standby veritabanına erişemezse, primary veritabanı standby veritabanı cevap verene kadar hang olur. Yani hizmet veremez duruma düşer. Böyle bir durum oluşmaması için “NET_TIMEOUT” parametresi kullanılması bence en mantıklı olanıdır. Bu parametre ile timeout süresi belirleyebiliriz. Kesinti durumunda primary timeout süresi kadar bekler ve bu süre dolduğunda hizmet vermeye devam eder. Data Guard 10g de bu parametre varsayılan 180 sn iken, Data Guard 11g de varsayılan 30 sndir.

DATA GUARD 11g PROCESS MİMARİSİ ASENKRON REDO TRANSFERİ (ASYNC)

Asenkron redo transferinde işlem akışı;

1 – Kullanıcı bir işlem (transaction) başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar.

2 – LNS (LogWriter Network Service) commit edilmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – Redo Buffer bir şekilde recycle edilirse LNS otomatik olarak redo log dosyalarını okur ve redoları buradan göndermeye başlar.

RFS verinin başarılı işlendiği (commit) hakkında LNS e geri bildirimde bulunmaz.

En çok kullanılan process mimarisidir. Asenkron redo transferi sıfır veri kaybını garanti altına almaz. Sistem en az veri kaybı ile kurtarılabilir durumdadır.

DATA GUARD KORUMAN(PROTECTION) MODLARI

3 koruma (protection) modu vardır. Aşağıdaki tablo ile özetleyebiliriz.

PHYSICAL STANDBY – REDO APPLY

Physical Standby Database, canlı (primary) veritabanının blok-blok kopyasıdır. Değişiklikleri uygulamak için Veritabanı Kurtarma Fonksiyonunu kullanır. Redo Apply aktifken, raporlama ve sorgu için read-only modda açılabilir(Active Data Guard -11g ile gelen bir özellik). Canlı (Primary) veritabanına ekstra yük bindirmemek için backup işlemlerinde kullanılabilir. Read-Write modda açılabilmesi için veritabanını flashbacklog modu açık olmalıdır. Flashbacklog aktif edildikten sonra restore point oluşturularak read-write modda açılabilir. Ve tekrar restore pointe geri dönülerek standby olarak çalışması sağlanabilmektedir. Yukarıda açıklamış olduğum modlardan istenilen bir tanesi ile redo transferi yapılabilir. Bir sonraki yazacağım makalede RMAN ile aktif veritabanı üzerinden physical standby veritabanı kurulumunu detaylı olarak sizlere anlatıyor olacağım.

İsteğe bağlı olarak primary veritabanından standby veritabanına taşınan redo kayıtları gecikmeli olarak stanby veritabanına uygulanabilir. Mesela standby veritabanımızın 2 saat arkadan gelmesini sağlayabiliriz. Böylelikle canlı (primary) veritabanımızda 2 saat içinde meydana gelebilecek kullanıcı hatalarını standby veritabanımızdan çok hızlı bir şekilde kurtarabiliriz. Gecikmeli apply aktif edildiğinde real-time apply doğal olarak devre dışı kalacaktır. Real-time apply aşağıdaki gibi aktif edilebilir.

SQL>alter database recover managed standby database using current logfile disconnect;

Redolar yukarıdaki şekilde olduğu gibi direk standby redo log dosyasından okunarak MRP veya LSP prosesine bildirilir. Gecikmeli apply ise aşağıdaki gibi aktif edilebilir. Ve redolar arşiv log dosyalarından okunarak MRP veya LSP prosesine bildirilir.

SQL> alter database recover managed standby database delay 10;

SNAPSHOT STANDBY(11g)

Read-write modda açılabilen ve tekrar physical standby veritabanına dönüştürülebilinen standby veritabanıdır. 11g ile aramıza katılmıştır ve oldukça kulanışlıdır. Snapshot standby aktif edildiğinde redo apply durdurulur ve arşiv log olarak yedeklenir. Physical standby a geri dönüldüğünde apply kaldığı yerden arşiv log dosyalarını apply ederek devam eder. Read-write modda açılarak test, patch, v.s gibi işlemler test edilebilir.

LOGICAL STANDBY – SQL APPLY

Logical Standby veritabanı açık, aktif ve bağımsız olan bir veritabanıdır. Canlı (Primary) veritabanı ile aynı mantıksal bilgilere (row) sahiptir. Redo verileri SQL olarak apply edilirken raporlama amaçlıda kullanılabilir. Veritabanı read-write modda açık olabilir. Primary veritabanından replica olan tablolarda değişikliklere izin vermez. Logical standby veritabanının bazı kısıtlamaları vardır. LONG, LONG RAW, BFILE, ROWID, kullanıcı tanımlı tippler (user-defined types) veri tipli tablolar üzerinde yapılan işlemler apply edilememektedir. Desteklenmeyen tabloları görmek için aşağıdaki sorguları çalıştırabilirsiniz.

 select * from DBA_LOGSTDBY_UNSUPPORTED;

 select * from LOGSTDBY_UNSUPPORTED_TABLES;

ACTIVE DATA GUARD (11g)

11g ile gelen bu özellik sayesinde redo apply edilirken standby veritabanı read-only modda açık olabilmektedir (Read-Only with Apply). Bundan dolayı Active Standby Veritabanı adı verilmiştir. Active data guard ın bize sağladığı avantajlar açısından bakacak olursak; Real-time raporlama (redo apply devam ederken), yedek alma gibi işlemlerimizi active standby veritabanı üzerinden yapabilir durumdayız. Böylelikle Canlı(production) veritabanımız üzerindeki raporlama,yedek alma gibi işlem yükünü azaltmış olacağız. Canlı veritabanımız müşterilerimize daha efektif olarak hizmet verecektir.

11g R2 ile gelen diğer bir güzelliğide sizlerle paylaşmadan yapamayacağım g R2 öncesine kadar canlı (primary) veritabanımızın aynı anda maksimum 9 standby veritabanı olabilmekteydi. Bu rakam 11g R2 ile 32 ye çıkarılmıştır. Yukarıdaki şeklimize göre canlı veritabanımız 4 standby veritabanına real-time redo apply edebilmekte ve aynı anda rapor kullanıcılarımız real-time raporlama yapabilmektedirler.

SWITCHOVER & FAILOVER

Son olarak Switchover ve Failover terimlerinden kısaca bahsetmek istiyorum. Switchover, planlı role değişimidir. Yani canlı (primary) veritabanının standby olarak, standby veritabanının ise primary olarak hizmet vermesidir. Tekrar yeni bir veritabanı kurulumu gerektirmez. OS ve hardware bakımı, standby veritabanının çalışabilirliğini test etmek için kullanılabilir. Failover ise manuel olarak SQL ile veya basit bir GUI arayüzüyle (Data Guard Broker, Enterprise Manager) aktifleşebilen, canlı (Primary) veritabanının plansız bozulmasıdır. Böyle bir durumda standby veritabanının yeniden oluşturulması gerekir. Switchover için yapılması gereken işlem adımlarını ilerleyen makalelerimde sizlere anlatıyor olacağım.

Resimler için kullandığım kaynaklar:

http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/toc.htm

Oracle Data Guard 11g Handbook – Charles Kim

Talip Hakan Öztürk

Merhaba,

Bu yazımda RMAN ile alınan yedekten geri dönme yöntemlerimizi madde madde anlatacağım.

1- Bütün datafile lar kaybedildiğinde, tüm yedeğin geri dönülmesi için;

SQL> startup mount;
RMAN> restore database;
RMAN> recover database;
SQL> alter database open;

2- Bir tablespace kaybedildiğinde, kaybedilen tablespace in geri dönülmesi için;

 SQL> alter tablespace users offline;
RMAN> restore tablespace users;
RMAN> recover tablespace users;
SQL> alter tablespace users online;

Tablespace offline yapılamazsa aşağıdaki yol izlenmelidir.

$ sqlplus “/ as sysdba”
SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore tablespace users;
RMAN> recover tablespace users;
SQL> alter database open;

3- Bir datafile kaybedildiğinde, kaybedilen datafile ın geri dönülmesi için;

SQL> alter database datafile '/oracle/oradata/users.dbf' offline;
RMAN> restore datafile '/oracle/oradata/users.dbf'
RMAN> recover datafile '/oracle/oradata/users.dbf'
SQL> alter database datafile '/oracle/oradata/users.dbf' online;

Datafile offline yapılamazsa aşağıdaki yol izlenmelidir.

$ sqlplus “/ as sysdba”
SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore datafile '/oracle/oradata/users.dbf';
RMAN> recover datafile '/oracle/oradata/users.dbf';
SQL> alter database open;

4- Controlfile lar kaybedildiğinde, kaybedilen controlfile ın geri dönülmesi için;

$ sqlplus “/ as sysdba”
SQL> shutdown abort;
SQL> startup nomount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> set dbid = 3970640872;
RMAN> restore controlfile;
SQL> alter database mount;
SQL> alter database open;

Controlfile yedekten geri dönüldükten sonra, veritabanının açılması esnasında aşağıdaki gibi ORA-01589 hatası ile karşılaşılabilir.

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

Bu durumda aşağıdaki işlemler yapılmalıdır.

SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> recover database;
SQL> alter database open resetlogs;
RMAN> reset database;

Veritabanı “resetlogs” ile açıldığı için controlfile daki SCN numarası sıfırlanacaktır. Bu durumda önceki alınan yedekler geçersiz olacaktır. Yeniden full yedek alınması zorunludur.

5- Özel bir durum gerekebilir. Ve bizden belirli bir zamana dönmemiz istenebilir. Belirli bir zamana dönmek için 3 yöntem mevcuttur. Zamana göre, Arşiv sıra nosuna göre ve SCN (System Change Number) ye göre incomplete recovery (Belirli bir zamana dönme işlemi) yapabiliriz.

A. Zamana göre (Time-Based) incomplete recovery;

$ sqlplus "/ as sysdba"
SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore database until time "to_date('06/05/11 12:0:00','DD/MM/YY HH24:MI:SS')";
RMAN> recover database until time "to_date('06/05/11 12:0:00','DD/MM/YY HH24:MI:SS')";
SQL> alter database open resetlogs;

B. Sistem değişiklik numarasına göre (SCN-Based) incomplete recovery;

$ sqlplus "/ as sysdba"
SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore database until scn 1000;
RMAN> recover database until scn 1000;
SQL> alter database open resetlogs;

C. Arşiv dosyası sequence numarasına göre incomplete recovery;

$ sqlplus "/ as sysdba"
SQL> shutdown abort;
SQL> startup mount;
$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore database until sequence 9923;
RMAN> recover database until sequence 9923;
SQL> alter database open resetlogs;

6- Alınan yedekte arşiv dosyaları varsa ve belirli arşiv dosyalarının geri dönülmesi gerekirse;

$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN> restore ARCHIVELOG FROM TIME 'SYSDATE-1' UNTIL TIME 'SYSDATE';

Ya da

RMAN> restore ARCHIVELOG FROM TIME "to_date('07/11/05 00:00:01','MM/DD/YY HH24:MI:SS')
UNTIL TIME 'SYSDATE';

7- Herhangi bir datafile ın bir bloğunda corruption oluşursa aşağıdaki gibi bir hata alınır ve ilgili datafile ın ilgili bloğu aşağıdaki gibi kurtarılır.

Hata:

ORA-01578: ORACLE data block corrupted (file # 8, block # 13)

ORA-01110: data file 8: ‘/oracle/oradata/users.dbf’

Kurtarmak için:

$ rman target / catalog_user/catalog_user_password@catalogdb
RMAN>blockrecover datafile 8 block 13;

Kurtarmak için özel bir backup set verebiliriz;

# backupset den kurtarma
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
# image copy den kurtarma
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19
      FROM DATAFILECOPY;
# "FULL" taglı olan backupset den kurtarma
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 199
       FROM TAG = FULL;

Backup esnasında veya “Backup Validate” komutuyla RMAN bulduğu corrupted blokları V$DATABASE_BLOCK_CORRUPTION viewına yazar. Corrupt olan blok recover edildiğinde RMAN otomatik bu view ı günceller. Geçmişe yönelik tüm corruption listesi V$BACKUP_CORRUPTION ve V$COPY_CORRUPTION viewlarından bakılabilir. Aşağıdaki komut çalıştırıldığında RMAN, V$DATABASE_BLOCK_CORRUPTION viewında bulunan tüm corrupted blokları recover eder.

RMAN>BLOCKRECOVER CORRUPTION LIST
  RESTORE UNTIL TIME 'SYSDATE-10';

8- 2. veri dosyamızda problem olduğunda, 2. veri dosyamızı “image copy” yedeğe switch etmek için;

RMAN>sql ‘alter database datafile 2 offline’;
RMAN>switch datafile 2 to copy;
RMAN>recover datafile 2;
RMAN>sql ‘alter database datafile 2 online’;

Sağlam yedekli, problemsiz veritabanlarınız olması dileğiyle …

Talip Hakan Öztürk

Bu yazımda RMAN in önemli konfigürasyonlarını sizlere açıklıyor olacağım. Bu konfigürasyonları bir kere yapıp yedeklerimizi bu konfigürasyon ayarları ile alabileceğimiz gibi, yedek scriptimiz içinde de bu konfigürasyonları scriptimize özel set edebiliriz.

CONFIGURE RETENTION POLICY

2 farklı seçenek ile kullanılır. Recovery Window veya Redundancy

Redundancy: CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

Redundacy 1 set edildiğinde, RMAN geçmişe yönelik 1 yedek saklar. 2. Yedek alındığında 1. Yedeği obsolete olarak işaretler. Şayet FRA da yer kalmazsa RMAN bunu otomatik algılar ve obsolete yedeği siler. Veya biz “delete obsolete” ile manuel silebiliriz.

Recovery Windows: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Recovey windows 3 gün set edildiğinde 3 günden eski yedekler obsolete olarak işaretlenir. Recovery window da özel bir durum vardır. RMAN 3 günlük geri dönmeyi garanti eder. Bunu bir örnekle açıklamak gerekirse;

Elimizde 4 yedeğimiz olsun. Ve yedek alınma tarihleri 16 mayıs, 18 mayıs, 21 mayıs ve 23 mayıs olsun. Recovery window 3 set edildiğinde normalde 16 mayıs ve 18 mayıs ın obsolete olması gerekir. (23-3=20 yani 20 mayıs ve öncekiler obsolete olmalı).Ama 20 mayıs a geri dönülmesi gerektiğinde 18 mayıs yedeğinin gerekli olmasını RMAN otomatik algılar ve 18 mayısı obsolete olarak set etmez.

CONFIGURE DEFAULT DEVICE TYPE

2 farklı lokasyona yedek alınabilir. Tape ve Disk

Diske yedek: CONFIGURE DEFAULT DEVICE TYPE TO DISK;

Tape kartuşa yedek: CONFIGURE DEFAULT DEVICE TYPE TO SBT;

CONFIGURE CONTROLFILE AUTOBACKUP ON/OFF

Controlfile ın her yedek almada otomatik yedeklenip yedeklenmeyeceği buradan set edilir. On ise otomatik yedek alınır, off ise yedek alınmaz.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’;

Controlfile yedeği varsayılan FRA alanına unique bir isimde alınacağını bildirir. %f nin karşılığı c-‘IIIIIIIIII-YYYYMMDD-QQ’ şeklindedir . Burada ‘IIIIIIIIII’ DBID yi ‘YYYYMMDD’ tarihi ve ‘QQ’ ise hex decimal bir yedek idsidir. Biz istersek aşağıdaki gibi farklı yerlere alabiliriz.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘ora_home/oradata/cf_%F’;

Ve aşağıdaki gibi konfigürasyonumuzu resetleyebiliriz.

CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK CLEAR;

Aşağıdaki gibi RUN scriptinin içerisinde yazıldığında varolan konfigürasyonu ezdirebiliriz

RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'controlfile_%F';
RMAN> BACKUP AS COPY DATABASE;
RMAN> RUN {
       SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck';
       BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE;
      }

CONFIGURE BACKUP OPTIMIZATION OFF/ON

On olması halinde daha önce yedeği alınmış ve herhangi bir değişikliğe uğramamış objeler yedeklenmez. Bunun için aşağıdaki kriterleri göz önünde bulundurur

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET
Alınan yedeklerin kaç paralel olarak kaç kanaldan yazılacağını belirlediğimiz konfigurasyondur. Device type oalrak disk veya sbt olduğunu belirtmeliyiz.

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 3

Datafile yedeklerinin kopya adedi olarak kaç tane alınacağı bu konfigürasyonla belirlenir. Yukarıdaki örneğime göre 3 kopya alınacaktır. Mirror yedek olarak bilinir. FORMAT opsiyonu ile 3 farklı lokasyon verilebilir. 3 yedeğin id side aynı olacaktır.
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT
‘/tmp/%U’,'?/oradata/%U’,'?/%U’;

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1

Arşiv dosya yedeklerinin kopya adedi olarak kaç tane alınacağı bu konfigürasyonla belirlenir. 2 ve daha çok kopya için ayrı ayrı lokasyon verilmelidir yoksa yedek hata alır.(Yukarıdaki gibi FORMAT opsiyonu ile)

CONFIGURE MAXSETSIZE TO UNLIMITED

Normal backup size maximum FRA alanı kadar olabilmektedir. İstenirse maxsetsize verilerek yedeğin bu boyutta olması sağlanabilir. Bu kiritik bir değerdir. Maxsetsize ım yedek aldığım data file ın size ından küçükse yedek hatalı sonuçlanmaktadır. Varsayılan ‘UNLIMITED’ olarak gelmektedir.

CONFIGURE ENCRYPTION FOR DATABASE OFF/ON

Encryption kullanılıp kullanılmayacağına karar verilir. Encryption kullanılacaksa hangi algoritmanın kullanılacağı ise aşağıdaki konfigürasyon ile belirtilir.

CONFIGURE ENCRYPTION ALGORITHM ‘AES128′

Encryption kullanılacaksa hangi algoritmanın kullanılacağı ise aşağıdaki konfigürasyon ile belirtilir.

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE

11g ile gelen bir özelliktir. 2 Farklı zipleme metodu mevcuttur. ZLIB ve BZIP2. ZLIB daha az cpu tüketir ama sıkıştırma oranı düşüktür. BZIP2 ise cpu kullanımı fazladır ama sıkıştırma oranı yüksektir. Aşağıdaki gibi kullanılabilir.

CONFIGURE COMPRESSION ALGORITHM ‘ZLIB’;

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE

Arşiv yedeği alındıktan sonra obsolete olup olmayacağı set edilir. Varsayılan None dur. “APPLIED ON STANDBY” set edilebilir.

10g de aşağıdaki gibi set edilebilir.

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO {ARCHIVERETENTION};

11g de aşağıdaki gibi set edilebilir.

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE

Yedek dosyasının MAXPIECESIZE kadar parçalar halinde alınmasını sağlar. Örneğin aşağıdaki konfigürasyonla alınan yedek 2GB lık parçalar halinde alınır.

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G;

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/oracle/ora10g/dbs/snapcf_test10g.f’

Controlfile ın snapshot ının lokasyonunun set edildiği konfigürasyondur. Controlfile ın kopyasıdır. RMAN özellikle catalog db ile kullanılırken resync için snapshot controlfile a ihtiyaç duyar.

Kaynak:
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmconfb.htm#i1014902

Talip Hakan ÖZTÜRK

Yedek raporlama işlemleri

Backup gerekiyor mu raporu:

RMAN>report need backup;

Obsolete backup raporu:

RMAN>report obsolete;

Yedek alma işlemleri
Tüm veritabanının varsayılan konfigürasyona göre yedeğini almak:

RMAN>backup database;
veya
RMAN> backup incremental level 0 database;

Tüm veritabanının arşiv loglar ile birlikte yedeğini almak:

RMAN>backup database plus archivelog;

Controlfile yedeğini almak:

RMAN>backup as copy current controlfıle;

Tüm veritabanının arşiv loglar ile birlikte yedeğini almak ve yedeği alınan arşiv logları silmek:

RMAN>backup database plus archivelog delete input;

Belirli bir tablespace i yedek almak:

RMAN>backup as backupset
format '/backup/df_%d_%s.bck'
tablespace users;

Belirli bir veri dosyasını yedek almak:

RMAN>backup datafile 5;

Hergün değişen blokları yedeklemek (Differential Incremental Backup):

RMAN> backup incremental level 1 database;

Son full yedekten sonra tüm blokları yedeklemek (Cumulative Incremental Backup):

RMAN>backup incremental level 1 cumulative database;

Image Copy yedek almak:

RMAN>backup as copy database;

Yedek silme işlemleri
Backup sıra nosuna göre silme:

RMAN>delete backuppiece 101;

Dosya adına göre silme:

RMAN>DELETE CONTROLFILECOPY '/tmp/control01.ctl';

Arşiv dosyalarını silme:

RMAN>DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300;
RMAN>DELETE NOPROMPT ARCHIVELOG ALL;

Not:NOPROMPT, yedek silme esnasında Yes/No onay sorusunu sormaz.

Tag verilen yedeği tag adına göre silme:

RMAN>DELETE BACKUP TAG='before_upgrade';

Bütün yedekleri silme:

RMAN>DELETE BACKUP;

Tape kasete yedeği alınmış yedeklerin disk üzerinden silinmesi:

RMAN>DELETE ARCHIVELOG ALL BACKED UP 3 TIMES TO sbt;

Image copy yedeği silme:

RMAN>DELETE COPY;

Obsolete yedek silme
RMAN kurtarma işlemi için gerekli olmayan yedekleri obsolete olarak işaretler. (redundancy veya recovery window set edilmiş ise)

Obsolete yedekleri silmek için:

RMAN>delete obsolete;

3 gün öncesi obsolete yedekleri silmek için:

RMAN> delete obsolete recovery window of 3 days;

Expired yedek silme

RMAN>delete expired backup;

Crosscheck kontrolü
Crosscheck komutu, RMAN repository de bulunan yedeğin disk veya tape üzerinde fiziksel olup olmadığını kontrol eder. Eğer dosya disk veya tape üzerinde fiziksel olarak yoksa (işletim sistemi üzerinden silinmiş olabilir) RMAN repository de ilgili yedeği “EXPIRED” olarak işaretler. Sonrasında, “DELETE EXPIRED” komutuyla RMAN repository den yedek bilgileri silinebilir.

Arşiv dosyaları crosscheck ile kontrol etme:

RMAN>crosscheck archivelog all;

Alınan bütün yedeği crosscheck ile kontrol etme:

RMAN>crosscheck backup;

Image copy yedeği crosscheck ile kontrol etme:

RMAN>crosscheck copy;

Tag verilen yedeği crosscheck ile kontrol etme:

RMAN>crosscheck backuppiece tag = 'nightly_backup';

Yedek listesini görmek

RMAN>list backupset of database;

RMAN>list backup;

Yedek önizlemesini görmek (İçerisinde hangi objeler olduğu listelenir):

RMAN> restore database preview;

RMAN> restore tablespace users preview;

Konfigürasyon işlemleri

Konfigürasyon ayarlarını görmek:

RMAN>show all;

Varsayılan konfigürasyona dönmek:Sonuna “clear” ifadesi yazılır

RMAN>configure backup optimization clear;

Set edilmiş bir konfigürasyonu görmek:Başına “show” ifadesi yazılır

RMAN>show controlfile autobackup format;

Bir ayarı konfigüre etmek:Başına “configure” ifadesi yazılır

RMAN>configure device type disk backup type to copy;

RMAN>configure retention policy to recovery window of 7 days;

RMAN>configure retention policy to redundancy 3;

Yedek ve Geri Dönme işlemlerini doğrulama (validate)
Alınan tüm yedeği doğrulamak:

RMAN>backup validate;

Arşiv dosyaların yedeğini doğrulamak:

RMAN>backup validate database archivelog all;

Tüm veritabanı geri dönme işlemini doğrulama:

RMAN>restore database validate;

Controlfile geri dönme işlemini doğrulama:

RMAN>restore controlfile validate;

Spfile geri dönme işlemini doğrulama:

RMAN>restore spfile validate;

Belirli bir tablespace geri dönme işlemini doğrulama:

RMAN>restore tablespace users validate;

Yedek sıkıştırma işlemleri (11g ile geldi)
Backupseti sıkıştırma:

RMAN>backup as compressed backupset database;

Yedek şifreleme işlemleri
Encryption set etme:

RMAN> Set  encryption identified by passwprd;

Decryption set etme:

RMAN> Set  decryption identified by passwprd;

Enable & Disable Block change tracking
Sadece değişen blokları takip etmek için bct aktif edilmesi:

SQL>alter database enable block change tracking using file '/rman_bkups/change.log';

Block change tracking iptal edilmesi:

SQL>alter database disable block change tracking;

RMAn yedeğin debug edilmesi ve trace alınması

$rman target=/ debug=all trace=rman.trc

Yedeğin Log dosyasını oluşturmak

$export NLS_DATE_FORMAT=’dd.mm.yyyy hh24:mi:ss’;

$rman target=/ log=rman.log

Recovery area size bilgisini görmek

select name
,        floor(space_limit / 1024 / 1024) "Size MB"
,        ceil(space_used  / 1024 / 1024) "Used MB"
from   v$recovery_file_dest
order by name
/

RMAN Catalog DB işlemleri

1. Catalog DB üzerinde kullanıcı oluşturulur.

  CREATE USER rman IDENTIFIED BY rman
  TEMPORARY TABLESPACE temp
  DEFAULT TABLESPACE users
  QUOTA UNLIMITED ON users;

1. Recovery Catalog owner yetkisi verilir

GRANT RECOVERY_CATALOG_OWNER TO rman;

1. Catalog veritabanına bağlanılıp catalog oluşturulur.

rman CATALOG rman/rman@catalog

RMAN> create catalog;

1. Yedeği alınacak target veritabanı register edilir.

rman TARGET sys/oracle@test10g CATALOG rman/rman@catolog

RMAN> register database;

RMAN de kanal açma ve objeleri manuel kanallara dağıtma

Örnek script:

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server1)";
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server2)";
  ALLOCATE CHANNEL c3 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server3)";
  BACKUP
   (DATAFILE 1,2,3
    CHANNEL c1)
   (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf'
     CHANNEL c2)
   (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1
     CHANNEL c3);
}

Talip Hakan Öztürk

TROUG ( Türk Oracle Kullanıcıları Grubu)  21 Nisan’da Türk Oracle kullanıcılarını “TROUG Day” ‘de buluşturuyor. Katılımın ücretsiz olacağı bu etkinlikte, konusunun uzmanlarından teknik sunumlar ve katılımcıların sorularıyla yönlendireceği “TROUG Panel” oturumu yer alacak.

Program
09:00-10:00 Açılış & Thinking About Joins: Jonathan Lewis
10:00-10:50 20+ Soruda Exadata: Ferhat Şengönül & Hüsnü Şensoy
10:50-11:00 Kahve Molası
11:00-12:00 Enterprise Manager 11g Grid Control: Gökhan Atıl
12:00-13:00 Öğle Yemeği Molası
13:00-14:00 Oracle Dataguard: Nasıl Daha Efektif Kullanırız? Emre Baransel & Ogan Özdoğan
14:00-14:50 ASM Best Practices: Orhan Bıyıklıoğlu
14:50-15:00 Kahve Molası
15:00-16:00 11g Backup & RecoveryNew Features: Kamran Agayev & Zekeriya Beşiroğlu
16:00-16:50 PL/SQL ile Web 2.0: JavaScript ve Javacılar nasıl kıskançlıktan çatlatılır? Yalım K. Gerger
16:50-17:00 Kahve Molası
17:00-18:00 TROUG Panel: H.Tonguç Yılmaz, Kamran Agayev,O. Yasin Saygılı, Talip Hakan Öztürk, Gökhan Atıl, Emre Baransel

Etkinlik Yer ve Zamanı

Tarih: 21 Nisan Perşembe
Yer: Bahçeşehir Üniversitesi /Beşiktaş Kampüsü – İstanbul

Detaylı Bilgi : http://www.troug.org/?p=406
Ücretsiz kaydolmak için: http://apex.oracle.com/pls/apex/f?p=38448:2

Rman ile bir database’ i farklı bir sunucu üzerine taşımak başlıklı yazımda rman backup diske alındığında nasıl restore edileceğinden bahsetmiştik. Orada catalog database’ ini orada aslında kullanmamıştık çünkü alınan rman backupı, restore yapılacak sunucu üzerinde rman’ in istemiş olduğu path’lere kopyalamıştık dolayısıyla orada işimiz daha kolaydı.

Burada ise catalog database’ ini kullanarak (rutin işleyişe birebir örnek oluşturması açısından) kartuşa alınan bir backupı hiçbir kopyalama işlemi yapmadan nasıl başka bir ortama taşıyacağımızdan bahsetmek istiyorum. Yine burda da bir takım öngörülerimiz var. Öncelikle, pathlerimiz burda da farklı olarak kabul ediyoruz.  (eğer pathler restore yapılacak sunucu ile birebir aynı ise, aşağıdaki scriplerdeki )Sonrasında yapacağımız işlemlerle ilgili olarak adım adım anlatamaya çalışayım ;

• Backupı dönülecek olan sunucu üzerinden rman catalog database’ i ile database’ in backupı kartuşa alınır.

run {

allocate channel 'dev_0' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_1' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_2' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_3' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

backup incremental level

format 'Betasetcms2_PRDTEST<%t:%p>.dbf'

restore database;

sql 'alter system archive log current';

backup

filesperset 1

format 'Betasetcms2_PRDTEST<%t:%p>.dbf'

archivelog like '/data2/arch/%';

}

Datafile’ leri farklı pathlere restore edeceğimiz için aşağıdaki bilgileri mutlaka biliyor olmamız gerekiyor. Sonrasında file# numarasına göre yeni path’ lere set edeceğiz.

Database’ deki datafile’ lerin listesinide alıyoruz.

SQL> select name from v$datafile;

FILE#   NAME

1            /data2/prdtest/system01.dbf

2            /data2/prdtest/undotbs01.dbf

3            /data2/prdtest/sysaux01.dbf

4            /data2/prdtest/users01.dbf

5            /data2/prdtest/example01.dbf

6            /data2/prdtest/kamil_deneme1_01.dbf

7            /data2/prdtest/kamil_deneme1_02.dbf

8            /data2/prdtest/kamil_deneme2_01.dbf

9            /data2/prdtest/kamil_deneme2_02.dbf

Redologlar hakkında aşağıdaki bilgileri alıyoruz.

Select * from v$logfile;

GROUP#           STATUS    TYPE                                  MEMBER

3                     ONLINE    /data2/prdtest/redo03.log        NO

2                     ONLINE    /data2/prdtest/redo02.log        NO

1                     ONLINE    /data2/prdtest/redo01.log        NO

Ayrıca bu database’ e ait dbid bilgisinide öncesinde bilmemiz gerekiyor. Kullanmakta olduğunuz tüm database’ lerin dbid’ lerini saklamanızda fayda var. Bu değer sonradan değişmeyen ve her database için unique olan bir değerdir.

SQL> select dbid from v$database ;

DBID

———-

165917862

Bundan sonraki adımda aslında şunu düşünüyoruz, bu database herhangi bir problemden dolayı down oldu ve temin edilen farklı bir sunucuya data kaybı olmadan restore etmeniz gerekiyor. Şimdi almış olduğumuz backupı başka bir sunucu üzerine restore etmeye çalışalım.

• Restore yapılacak server üzerine sadece oracle software kurulumu yapıyoruz.

• Pfile, initfile, pwd, tns, sqlnet ora gibi (parametre) dosyaları yeni sunucumuz üzerine üzerine kopyalıyoruz. (veya elimizde backupları yoksa yenilerini create ediyoruz. Zaman zaman prod ortamlarından bu tarz kritik file’ lerin backupının alınması ciddi zaman kazançları sağlıyor)

Parametre dosyaları restore yapılacak olan servera kopyalandıkdan sonra içerisinde gerekli değişiklikleri yapmamız gerekiyor. Örneğin memory parametreleri yeni sunucuya göre set edilir veya backup alınan sunucu ile restore yapılacak olan sunucunun path’ leri farklı olabileceğinden buradaki controlfile parametresinin restore yapılacak olan sunucuda nerde olması gerekiyor ise ilgili path bilgisi buraya girilir.

Örneğin bizim örneğimizde backup alınan sunucudaki control file parametresi  ;

*.control_files=’/data2/prdtest/control01.ctl’,'/data2/prdtest/control02.ctl’,'/data2/prdtest/control03.ctl’

Restore yapılacak sunucudaki olması gereken path ise (burada böyle bir path olmadığından dolayı) ;

*.control_files=’/data/oracle/oradata/prdtest/control01.ctl’,'/data/oracle/oradata/prdtest/control02.ctl’,'/data/oracle/oradata/prdtest/control03.ctl’

• Sonra yeni sunucumuzdaki database sys olarak bağlanıp nomount modda database’ i start ediyoruz.

oracle@betasetapp2:/data/oracle/product/10.1.0/db:>sqlplus “/as sysdba”

SQL*Plus: Release 10.1.0.5.0 – Production on Mon Nov 29 09:22:50 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 – 64bit Production

With the Partitioning, OLAP and Data Mining options

SQL> startup nomount

ORACLE instance started.

Total System Global Area  419430400 bytes

Fixed Size                  1330696 bytes

Variable Size             122401272 bytes

Database Buffers          293601280 bytes

Redo Buffers                2097152 bytes

• Database’ i nomount moda aldıkdan sonra yine bu sunucu üzerinden önce rman’e sonra catalog database’ ine bağlanıyoruz.

oracle@betasetapp2:/data/oracle:>rman target /

Recovery Manager: Release 10.1.0.5.0 – 64bit Production

Copyright (c) 1995, 2004, Oracle.  All rights reserved.

connected to target database: prdtest (not mounted)

RMAN> connect catalog RMAN_PRDTEST/r10011002@RMAN

connected to recovery catalog database

RMAN>

Catalog database’ ine bağlanmak için kullandığımız user bizim backup aldığımız veritabanını catalog database’ ine register ederken kullanmış olduğumuz user’ ı ifade ediyor. @RMAN ise rman catalog database’ inin tns kaydıdır.

• Rman ile restore işlemine artık başlıyabiliriz, öncelikle işlem yapacağımız database’ in dbid bilgisini set ediyoruz.

RMAN> set dbid=165917862

executing command: SET DBID

database name is “PRDTEST” and DBID is 165917862

• İlk olarak controlfile’ i dönmemiz gerekiyor.

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> restore controlfile;

7> }

released channel: ORA_DISK_1

allocated channel: dev_0

channel dev_0: sid=159 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_1

channel dev_1: sid=157 devtype=SBT_TAPE

channel dev_1: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_2

channel dev_2: sid=160 devtype=SBT_TAPE

channel dev_2: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_3

channel dev_3: sid=161 devtype=SBT_TAPE

channel dev_3: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

Starting restore at 30-NOV-10

channel dev_0: starting datafile backupset restore

channel dev_0: restoring controlfile

[Normal] From: OB2BAR_Oracle8@betasetapp2 “PRDTEST”  Time: 11/30/10 10:47:22

Starting OB2BAR Restore: betasetcms2:c-165917862-20101125-02 “Oracle8″

[Normal] From: OB2BAR_Oracle8@betasetapp2 “PRDTEST”  Time: 11/30/10 10:47:24

Completed OB2BAR Restore: betasetcms2:c-165917862-20101125-02 “Oracle8″

channel dev_0: restored backup piece 1

piece handle=c-165917862-20101125-02 tag=TAG20101125T141314

channel dev_0: restore complete

output filename=/data/oracle/oradata/prdtest/control01.ctl

output filename=/data/oracle/oradata/prdtest/control02.ctl

output filename=/data/oracle/oradata/prdtest/control03.ctl

Finished restore at 30-NOV-10

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

RMAN>

Ben testimde, channel allocate ederken,  rman’ in backup alırken allocate ettiği kadar channel’ lar allocate ettim, istenirse daha az veya daha fazla channel allocate edilebilir.

Örneğin;

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> allocate channel 'dev_4' type 'sbt_tape';

7> allocate channel 'dev_5' type 'sbt_tape';

8> allocate channel 'dev_6' type 'sbt_tape';

9> restore controlfile;

10> }

allocated channel: dev_0

channel dev_0: sid=159 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_1

channel dev_1: sid=157 devtype=SBT_TAPE

channel dev_1: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_2

channel dev_2: sid=160 devtype=SBT_TAPE

channel dev_2: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_3

channel dev_3: sid=161 devtype=SBT_TAPE

channel dev_3: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_4

channel dev_4: sid=156 devtype=SBT_TAPE

channel dev_4: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_5

channel dev_5: sid=155 devtype=SBT_TAPE

channel dev_5: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_6

channel dev_6: sid=154 devtype=SBT_TAPE

channel dev_6: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

Starting restore at 30-NOV-10

…………………….

RMAN> run {
2> allocate channel 'dev_0' type 'sbt_tape';
3> restore controlfile;
4> }

allocated channel: dev_0

channel dev_0: sid=159 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

Starting restore at 30-NOV-10

…………………….

• Controlfile’ lerimizi döndükden sonra database’ imizi artık mound moda çekebiliriz.

SQL> alter database mount;

database mounted.

Rman Catalog Database’ i Kullanarak, Kartuşa Alınan Backupı Farklı bir Sunucuya Dönme -2 ile devam ediyoruz.

• Sıra datafile’ leri restore/recover etmeye geldi ;

Pathler backupı alınan database’ deki pathler ile aynı olmadığından öncelikle bu değişikliği yapmamız gerekiyor.

Aşağıdaki script ile datafile’ leri bizim belirttiğimiz yeni lokasyonlarına restore ediyoruz.

Bundan sonraki kısım aslında iki aşamalı olarak düşünebiliriz, birinci aşamamız restore, sonraki aşamamız ise recover aşamasıdır.  Datafile’ ler restore edilirken farklı seuence numaralarına sahip olarak restore edilir, yani db içerisindeki tün datafile’ lerin sequence değerleri biririnden farklılık gösterecektir. Bu farklılığı ortadan kaldırıp max sequence değeri altında datafile’ lerin hepsini aynı noktaya çeken işlem ise recover aşamasıdır. Bu konuyla  ilgili olarak aşağıdaki iki script ve arasındaki fark aslında konuyu açıklamak için yeterli diye düşünüyorum.

Aşağıdaki scripti çalıştırdığımda restore işleminin en sonunda  “RMAN-06054: media recovery requesting unknown log: thread 1 seq 686 lowscn 2858652“ böyle bir hata verdi. Almış olduğumuz backup full backupdı ve backuplanan son archive log numarası 684 idi. Recover işlemini hangi sequence değerine kadar yapılmasını belirtmediğim için aşağıdaki hatayı aldım.

RMAN> run {
2> allocate channel 'dev_0' type 'sbt_tape';
3> allocate channel 'dev_1' type 'sbt_tape';
4> allocate channel 'dev_2' type 'sbt_tape';
5> allocate channel 'dev_3' type 'sbt_tape';
6> set NEWNAME for datafile 1 to '/data/oracle/oradata/prdtest/system01.dbf';
7> set NEWNAME for datafile 2 to '/data/oracle/oradata/prdtest/undotbs01.dbf';
8> set NEWNAME for datafile 3 to '/data/oracle/oradata/prdtest/sysaux01.dbf';
9> set NEWNAME for datafile 4 to '/data/oracle/oradata/prdtest/users01.dbf';
10> set NEWNAME for datafile 5 to '/data/oracle/oradata/prdtest/example01.dbf';
11> set NEWNAME for datafile 6 to '/data/oracle/oradata/prdtest/kamil_deneme1_01.dbf';
12> set NEWNAME for datafile 7 to '/data/oracle/oradata/prdtest/kamil_deneme1_02.dbf';
13> set NEWNAME for datafile 8 to '/data/oracle/oradata/prdtest/kamil_deneme2_01.dbf';
14> set NEWNAME for datafile 9 to '/data/oracle/oradata/prdtest/kamil_deneme2_02.dbf';
15> restore database;
16> switch datafile all;
17> recover database;
18> }

allocated channel: dev_0

channel dev_0: sid=161 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_1

channel dev_1: sid=160 devtype=SBT_TAPE

channel dev_1: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_2

channel dev_2: sid=159 devtype=SBT_TAPE

channel dev_2: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_3

channel dev_3: sid=156 devtype=SBT_TAPE

channel dev_3: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 01-DEC-10

channel dev_0: starting datafile backupset restore

channel dev_0: specifying datafile(s) to restore from backup set

restoring datafile 00005 to /data/oracle/oradata/prdtest/example01.dbf

restoring datafile 00006 to /data/oracle/oradata/prdtest/kamil_deneme1_01.dbf

restoring datafile 00007 to /data/oracle/oradata/prdtest/kamil_deneme1_02.dbf

channel dev_1: starting datafile backupset restore

channel dev_1: specifying datafile(s) to restore from backup set

restoring datafile 00002 to /data/oracle/oradata/prdtest/undotbs01.dbf

restoring datafile 00003 to /data/oracle/oradata/prdtest/sysaux01.dbf

restoring datafile 00004 to /data/oracle/oradata/prdtest/users01.dbf

channel dev_2: starting datafile backupset restore

channel dev_2: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /data/oracle/oradata/prdtest/system01.dbf

restoring datafile 00008 to /data/oracle/oradata/prdtest/kamil_deneme2_01.dbf

restoring datafile 00009 to /data/oracle/oradata/prdtest/kamil_deneme2_02.dbf

[Normal] From: OB2BAR_Oracle8@betasetapp2 “”  Time: 12/01/10 09:55:10

Starting OB2BAR Restore:

…

…

…

Finished restore at 01-DEC-10

Starting recover at 01-DEC-10

starting media recovery

channel dev_0: starting archive log restore to default destination

channel dev_0: restoring archive log

archive log thread=1 sequence=685

[Normal] From: OB2BAR_Oracle8@betasetapp2 “”  Time: 12/01/10 09:57:35

Starting OB2BAR Restore: …

…

…

channel dev_0: restore complete

archive log filename=/data/oracle/flash_recovery_area/PRDTEST/archivelog/2010_12_01/o1_mf_1_685_6hczzhn4_.arc thread=1 sequence=685

channel default: deleting archive log(s)

archive log filename=/data/oracle/flash_recovery_area/PRDTEST/archivelog/2010_12_01/o1_mf_1_685_6hczzhn4_.arc recid=681 stamp=736595856

unable to find archive log

archive log thread=1 sequence=686

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 12/01/2010 09:57:43

RMAN-06054: media recovery requesting unknown log: thread 1 seq 686 lowscn 2858652

Until seq vererek çalıştırdığım zaman ;

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> set NEWNAME for datafile 1 to '/data/oracle/oradata/prdtest/system01.dbf';

7> set NEWNAME for datafile 2 to '/data/oracle/oradata/prdtest/undotbs01.dbf';

8> set NEWNAME for datafile 3 to '/data/oracle/oradata/prdtest/sysaux01.dbf';

9> set NEWNAME for datafile 4 to '/data/oracle/oradata/prdtest/users01.dbf';

10> set NEWNAME for datafile 5 to '/data/oracle/oradata/prdtest/example01.dbf';

11> set NEWNAME for datafile 6 to '/data/oracle/oradata/prdtest/kamil_deneme1_01.dbf';

12> set NEWNAME for datafile 7 to '/data/oracle/oradata/prdtest/kamil_deneme1_02.dbf';

13> set NEWNAME for datafile 8 to '/data/oracle/oradata/prdtest/kamil_deneme2_01.dbf';

14> set NEWNAME for datafile 9 to '/data/oracle/oradata/prdtest/kamil_deneme2_02.dbf';

15> set until sequence 686 thread 1;

16> restore database;

17> switch datafile all;

18> recover database;

19> }

allocated channel: dev_0

channel dev_0: sid=161 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_1

channel dev_1: sid=160 devtype=SBT_TAPE

channel dev_1: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_2

channel dev_2: sid=159 devtype=SBT_TAPE

channel dev_2: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_3

channel dev_3: sid=156 devtype=SBT_TAPE

channel dev_3: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET until clause

Starting restore at 01-DEC-10

channel dev_0: starting datafile backupset restore

channel dev_0: specifying datafile(s) to restore from backup set

restoring datafile 00005 to /data/oracle/oradata/prdtest/example01.dbf

restoring datafile 00006 to /data/oracle/oradata/prdtest/kamil_deneme1_01.dbf

restoring datafile 00007 to /data/oracle/oradata/prdtest/kamil_deneme1_02.dbf

channel dev_1: starting datafile backupset restore

channel dev_1: specifying datafile(s) to restore from backup set

restoring datafile 00002 to /data/oracle/oradata/prdtest/undotbs01.dbf

restoring datafile 00003 to /data/oracle/oradata/prdtest/sysaux01.dbf

restoring datafile 00004 to /data/oracle/oradata/prdtest/users01.dbf

channel dev_2: starting datafile backupset restore

channel dev_2: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /data/oracle/oradata/prdtest/system01.dbf

restoring datafile 00008 to /data/oracle/oradata/prdtest/kamil_deneme2_01.dbf

restoring datafile 00009 to /data/oracle/oradata/prdtest/kamil_deneme2_02.dbf

[Normal] From: OB2BAR_Oracle8@betasetapp2 “”  Time: 12/01/10 10:06:54

Starting OB2BAR Restore: …

…

…

media recovery complete

Finished recover at 01-DEC-10

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

RMAN>

• Redologların path’ ini düzeltiyoruz.

Recover işlemi başarı ile bittikden redologların yeni pathlerini set etmemiz gerekiyor. Yeni pathleri vermeden açmaya çalışırsak aşağıdaki hatayı alırız.

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-00344: unable to re-create online log ‘/data2/prdtest/redo01.log’

ORA-27040: file create error, unable to create file

IBM AIX RISC System/6000 Error: 2: No such file or directory

Redologların pathlerini düzeltmek için ;

SQL> alter database rename file '/data2/prdtest/redo03.log' to '/data/oracle/oradata/prdtest/redo03.log';

Database altered.

SQL> alter database rename file '/data2/prdtest/redo02.log' to '/data/oracle/oradata/prdtest/redo02.log';

Database altered.

SQL> alter database rename file '/data2/prdtest/redo01.log' to '/data/oracle/oradata/prdtest/redo01.log';

Database altered.

Kontol etmek için ;

SQL> select member from v$logfile ;

MEMBER

—————————————————–

/data/oracle/oradata/prdtest/redo03.log

/data/oracle/oradata/prdtest/redo02.log

/data/oracle/oradata/prdtest/redo01.log

• Sıra en son ve zevkli kısmına geldi , database’ i açıyoruz

SQL> alter database open resetlogs ;

Database altered.

Kartuşa alınan bir database’ in backupını, farklı bir sunucu üzerine farklı pathler de olacak şekilde restore etmiş olduk. Backup – restore testleri bir dba için oldukça önemli konular diye düşünüyorum. Zira esas önemli olan herhangi bir disaster durumunda paniklemeden soğukkanlılıkla ve benzer senaryoları daha önceden  test etmiş olmanın rahatlığı içerisinde soruna çözüm üretmekde yatıyor.  Umarım faydalı olur.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com