CETURK Akademi Grubu‘nda söz verdiğimiz gibi Ege Üniversitesi Bilgisayar Mühendisliği Kulubü işbirliği ile 28-29 Nisan 2012 tarihinde 2 günlük ücretsiz Mehmet Aca ile Android Programlama ve Talip Hakan Öztürk ile  Oracle eğitimleri gerçekleştirilecektir. Katılımcıları Ege Üniversitesi Bilgisayar Mühendisliği Kulubü belirleyecektir.

Düzenlenen eğitimler :

Uygulamalı Android Programlama Eğitimi

Kontenjan     : 30 Kişi
Eğitmen       : Mehmet Aca

Oracle Seminerleri

Kontenjan     : 60 Kişi
Eğitmen       : Talip Hakan Öztürk

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