Oracle 11.2.0.2 Clusterware ortamında kayıp OCR ve voting disklerin yedekten geri yüklenmesi

Bu yazıda Oracle 11.2.0.2 Clusterware platformunda OCR ve voting diskin kaybedildiği durumda sisteme nasıl geri yükleneceği anlatılmaktadır. Ocssd.bin başlatıldığında, GPnP profili, network ve voting disklerde var olmalıdır. Eğer minimum sayıda gereksinim duyulan voting dosyaları varolmazsa , bu durumda ocssd.bin başlatılamaz.  

OCR varolmadan crsd prosesi başlatılamaz ve ocssd.bin de aktif olmaz.  OCR, CRS tarafından kullanılır, bu da OCR kayıp olduğunda crsd.bin in aktif olamayacağı anlamına gelmektedir. CRSD aktif olmazsa, bu sorunlu düğüm kümeye dahilde olamaz.

Oracle Clusterware her 4 saatte bir OCR'nin yedeğini almaktadır. OCR içinde voting diskin yedeği bulunmaktadır. Bu sebeple voting diski geri yüklemek için var olan bir OCR yedeği yeterlidir. Şimdi bu geri yükleme olayını, OCR'nin yer aldığı ASM disk grubundaki(senaryomda +DATA) disklerde fiziksel bir çökme nedeniyle erişilemez olduğu senaryo çerçevesinde adım adım işleyelim. İlk etapta küme katmanını çalıştırarak sorunun olduğunu gözlemleyelim.

[root@rac1 ~]# crsctl start cluster

CRS-2672: Attempting to start ‘ora.cssdmonitor’ on ‘rac1′

CRS-2676: Start of ‘ora.cssdmonitor’ on ‘rac1′ succeeded

CRS-2672: Attempting to start ‘ora.cssd’ on ‘rac1′

CRS-2672: Attempting to start ‘ora.diskmon’ on ‘rac1′

CRS-2676: Start of ‘ora.diskmon’ on ‘rac1′ succeeded

CRS-2674: Start of ‘ora.cssd’ on ‘rac1′ failed

Bu adımda neyin yanlış olduğunu teyit etmek için log dosyalarına bakılması gerekmektedir.  Clusterware'nin alert.log dosyasında aşağıdaki gibi bir hata mesajına rastlanılacaktır.

Oracle 11.2.0.2 sürümünde Flashback Transaction Query

Flashback Transaction Query, işlem seviyesinde veritabanında yapılan değişiklikleri göstermeyi sağlayan kullanışlı bir Oracle aracıdır. Flashback Transaction Query, bir işlem tarafından yapılan tüm değişikliklerin görülmesini sağlayan bir SQL eklentisidir. Örneğin;

SELECT UNDO_SQL

FROM FLASHBACK_TRANSACTION_QUERY

WHERE XID = '000200030000002D';

Yukardaki komut bu işlemde sonuçlanan tüm değişiklikleri göstermektedir. İlaveten,  yerini dolduran tüm SQL komutlarıda döner ve bu işlem tarafından tüm satırlara yapılan değişiklikler geri alınabilir.  Flashback Transaction Query gibi hassas bir araç kullanarak, veritabanı yöneticileri ve uygulama geliştiriciler veritabanı veya uygulamadaki mantıksal problemleri kesin olarak teşhis edip gerekli düzeltmeleri yapabilirler.  

RMAN KEEP FOREVER, KEEP UNTIL TIME ve FORCE komutları

Oracle 11g’de KEEP FOREVER seçeneği Oracle 10g’deki yapısına göre oldukça geliştirilmiş ve online yedekleri sürekli tutmaya yarayan arşivlenmiş loglar muhafaza edilmiştir. Oracle 10g’de, yedek alındıktan sonra zaman noktasında geri kurtarmaya izin veren KEEP FOREVER  seçeneğiyle alınan bu yedek ileri sarılabilmekteydi. Oracle 11g’de, KEEP seçeneği sadece yedeği sürekli tutacak gerekli olan arşivlenmiş logları muhafaza edecektir, böylece sadece yedeğin alındığı noktaya kadar geri kurtarmak için gereken bu yedek kullanılabilir. Bu yedek tamamlandıktan sonra oluşturulan arşivlenmiş logların muhafazasına gerek kalmaz ve DELETE OBSOLETE komutu ile bunlar kullanılmaz olarak işaretlenebilir.

Oysaki Oracle 10g’de, KEEP FOREVER komutuyla alınan yedeklerden sonra alınan bütün arşivlenmiş log yedeklerinin muhafaza edilmesi gerekmekteydi.  KEEP FOREVER komutunun çalışması için RMAN kataloğunun kullanılması gerekirken, KEEP UNTIL TIME komutu katalog gerektirmez.

Standby üzerinde backup retention ilkesinin değiştirilmesi

Standby veritabanı oluşturulduğu anda yedek alıkoyma(retention) ilkesini değiştirmek mümkün olmamaktadır. Standby sunucu üzerindeki disk alanı yetersiz duruma geldiğinde veya diğer başka kısıtlamalar sebebiyle, primart veritabanından yedek alıkoyma ilkesinin değiştirilme ihtiyacı duyulabilmektedir. Bu değişiklik işlemi  esnasında ise aşağıdaki hata mesajı ile karşılaşılmaktadır.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 days;

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

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

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

RMAN-03002: failure of configure command at 08/18/2011 14:42:35

RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file

Yedekleme alıkoyma ilkesinin –eğer mümkünse- değiştirmenin en kolay yolu; bir switchover işlemi(standby veritabanını primary yapmak), ardından alıkoyma ilkesini değiştirmek ve sonrada orjinal primary veritabanına bir switchover işlemi yapmaktır. Ancak, bu her sefer mümkün olmamaktadır, özellikle dataguard yapılandırması asimetrik ise ve standby sistem daha çok bir felaketten geri kurtarma senaryosu için “veri koruma” modunda kullanılmaktaysa...

RMAN raporlaması

Her firma için en değerli nokta verilerdir ve en iddialı iş ise bir felaket anında bu verilerin en kısa sürede herhangi bir kayıp yaşanmadan sisteme geri yüklenmesidir. Pek çok durumda veritabanı yöneticileri hangi veri dosyalarının yedeğinin alınmasının gerektiğini bilmeden ve hangi veri dosyalarının yedeklendiğini bilmeden eksik geri kurtarma işlemi yapmaktadırlar. Veritabanının etkili olarak yedeklendiğinin ve gerektiği zamanda da başarılı şekilde geri yükleme yapılacağından emin olunması gerekmektedir. RMAN raporlaması, başarılı geri yükleme için veritabanı yedeklerini belirlemede en etkili ve en kolay yolu sağlamaktadır.

Genellikle, bir katalog görünümü(view) tüm veritabanlarının metadatasını içermektedir ve kullanışlı yedek bilgisini alabilmek için komplike bir sorgu yazılması gerekmektedir. Ancak, RMAN raporlaması ile LIST ve REPORT komutlarını kullanarak aynı bilgiler daha kolay yoldan elde edilebilmektedir.  RMAN raporlaması, Oracle sürümleri arttıkça gelişme göstermekte ve artık hangi veri dosyalarının yedeğinin alınmadığını veya başarılı bir geri yükleme için hangi yedekler gerekecektir gibi pek çok sorunun cevabını belirlemede oldukça yararlı olmaktadır. 

RMAN raporlamasını verimli kullanarak, nelerin yedeklendiği ile ilgili tereddütlü durumların üstesinden gelinmekte ve eksik geri kurtarma gibi can sıkıcı durumlardan kurtulunabilmektedir. Yedekleme ve geri kurtarma stratejesinin bir parçası olarak, bu raporlar aşağıdaki durumları tespit etmek amacıyla belirli periyotlarla çalıştırılmalıdır.

1) Neyin yedeğinin alındığını gözlemlemek.
2) Hangi veri dosyalarının yedeğinin alınması gerekmekte veya güncel olarak hangi veri dosyasının yedeği alınmamış.
3) Bir problem meydana geldiğinde RMAN hangi yedeği kullanarak geri kurtarma yapabilecek.
4) RMAN görevlerinin geçmiş bilgisinin gözlemlenmesi

Dataguard ortamında RMAN silme(deletion) ilkesinin yapılandırılması

Dataguard ortamında RMAN arşivlog silme(deletion) ilkesini tek bir merkez noktadan kontrol etmek için aşağıdaki adımlar izleyenebilir.

“Archivelog deletion” ilkesinin yapılandırılması

APPLIED ON STANDBY – Zorunlu standby olarak belirlenen standby sunucusu üzerinde uygulanan arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir.

NONE – Üçüncü derece cihazlara yedeklenen ve yapılandırılmış backup retention ilkesina bağlı olarak geçerliliğini yitirmiş arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir. Bu varsayılan ayardır.

CLEAR – Silme ilkesini temizler ve konfigürasyonu varsayılan değere döndürür.

ADRCI aracı ile kaza paketlerinin oluşturulması

Automatic Diagnostic Repository Command Interface (ADRCI), Oracle veritabanı teşhis verisini yönetmek için kullanılan bir komut satırı aracıdır. ADRCI, Oracle 11g sürümü ile kullanıma sürülmüş ve aşağıdaki işlemleri yapmaktadır;

• Otomatik Tanı Ambarı(ADR) içindeki tanı verisini görüntüler.
• Sağlık izleme raporlarını görüntüler.
• Kaza ve problem bilgilerini Oracle Desteğe iletmek için zip dosyasına paketler.

Tanı verisi; kaza ve problem tanımlarını, izleme dosyalarını, dumpları, sağlık izleme raporlarını, alert log girişlerini ve daha fazlasını içermektedir.

ADRCI zengin komut setine sahiptir ve gerek scriptler içinde gerekse interaktif modda kullanılabilmektedir. İlave olarak SQL*Plus üzerinden SQL ve PL/SQL komutlarının çalıştırılması gibi aynı şekilde ADRCI komutları içeren scriptlerde çalıştırılabilmektedir.

Oracle 11g Recycle Bin (Geri Dönüşüm Kutusu)

Recycle bin(Geri Dönüşüm Kutusu) düşürülmüş objelerin bilgilerini tutan bir çeşit veri dizin tablosudur. Silinmiş tablolar ve bu tablolara bağlı olan indeskler, kısıtlayıcılar, nested tablolar ve diğerleri gibi objeler silinmez ve hala alan kaplar. Geri dönüşüm kutusundan silinmeden veya tablespace alan kısıtlamaları gibi sebeplele veritabanından kalıcı olarak silinmeden, bu objeler hala kullanıcı alan kotası dahilinde yer kaplar.

Her kullanıcı kendine ait geri dönüşüm kutusu olduğunu düşünür, çünkü bir kullanıcı SYSDBA haklarına sahip olmadan Geri dönüşüm kutusu içerisinde erişebildiği ve gördüğü objeler kendi sahip olduklarıdır. Aşağıdaki komut ile her kullanıcı geri dönüşüm kutusu içindeki silinen objelerini görebilir.

SELECT * FROM RECYCLEBIN;

Bir tablespace içerikleri ile beraber düşürüldüğünde bu tablespace’e ait objeler geri dönüşüm kutusu içerisinde yer almaz. Veritabanı aynı zamanda geri dönüşüm kutusu içinde bu düşürülen tablespace’e ait olan nesneleride kalıcı olarak siler.

• Bir kullanıcıyı düşürdüğünüzde bu kullanıcıya ait objeler geri dönüşüm kutusu içerisine yerleştirilmez ve geri dönüşüm kutusunda bu kullanıcıya ait olan objeler varsa bunlarda kalıcı olarak otomatikman silinir.
• Bir küme(cluster) düşürüldüğünde bu kümenin üye tabloları geri dönüşüm kutusu içerisine yerleştirilmez ve geri dönüşüm kutusu içinde varsa üye tablolar bunlarda otomatikman kalıcı silinir.
• Bir tip(type) düşürüldüğünde ise bu tipe bağlı alt nesneler geri dönüşüm kutusuna yerleştirilmez ve herhangi bir alt nesne varsa geri dönüşüm kutusunda, kalıcı olarak otomatikman silinir.

Oracle 11g R2 (11.2.0.2) RAC mimarisinde Data Guard kurulumu ve yönetimi

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri  yapıp hemde standby siteden SELECT  sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

-----------------------------------------------------------------------------------

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

----------------------------------------------------------------------------------------------

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

Üst sürümlerden alt sürümlere EXPORT ve IMPORT işlemleri

Export aracı ile Oracle alt sürümlerde oluşturulan dump dosyalar, tüm üst Oracle sürümlerine import ile sorunsuzca taşınabilmektedir. Ancak, üst sürümlerden export edilen dump dosyaların alt sürümlere import edilebilmesi noktasında bir takım kısıtlamalar mevcuttur. Alt versiyon uyumlu dump dosyası elde edebilmek için aşağıdaki adımlara uyulması gerekmektedir.

• Data Pump export  kullanırken mevcut versiyonun datapump export aracını kullanın , ancak VERSION parametresinde hedef veritabanının eski sürümünü işaret edin.
• Export aracı kullanılacaksa, export işleminin yapılacağı veritabanında hedef veritabanı ile uyumlu versiyonda export aracını yükleyip bu export (exp) aracını kullanarak dump dosyası oluşturun. Sonra, hedefte orijinal import aracı ile dump dosyasını import edin.Örneğin; Oracle 10g veritabanının export aracı ile export editen bir dump dosyasını Oracle 9i üzerinde import aracı ile import edemezsiniz. Bu durumda Oracle 10g veritabanı üzerine Oracle 9i uyumlu exp aracının yüklenmesi ve bu araç ile export işleminin yapılması gerekmektedir.

Aşağıda üst sürümlerden alta sürümlere yapılacak export/import işlemlerinde kullanılacak VERSION bilgileri yer almaktadır.

Yukardaki tabloda yer alan herhangi bir üst sürümden uyumlu bir alt sürüme yapılacak export işleminde, öncelikle export işlemi yapılacak üst sürüm veritabanında CATEXP.SQL scripti çalıştırılmalıdır. Bu scriptin, hedefteki alt sürüm veritabanından export işleminin yapılacağı üst sürüm veritabanına kopyalanmış olması gerekmektedir. Bu script çalıştırıldıktan sonra expdp aracı ile export işlemi yapılabilir.

Export ve import işlemleri öncesinde DBMS_FILE_TRANSFER paketi kullanarak ASM’den diğer bir ASM’ye dosya transferi

Oracle 10g sürümünden itibaren DBMS_FILE_TRANSFER paketi ile aracı lokal dosya oluşturmadan direkt olarak ASM’den başka bir sunucu üzeridenki ASM’ye dosya transferi yapılabilmektedir.

Bu transfer işlemi için 2 farklı metot vardır. get_file ile uzak lokasyondan lokal sunucudaki ASM’ye dosya kopyalanabilmekte, put_file ilede lokal sunucudaki  bir dosya uzak bir ASM’ye kopyalanabilmektedir. İsterseniz bu iki farklı metodun uygulamalarını yapalım.

Network linki kullanarak EXPDP ve IMPDP işlemlerinin yapılması

Export ve import pompalama işlemlerinde kaynak veriyi hedef veritabanı sunucusuna taşımak için network bağlantısı methodunu kullanmak faydalı olabilmektedir.impdp işleminde veritabanından başka bir veritabanına herhangi bir aracı dosya kullanmadan direk taşıma yapılabilmektedir. Bu işlemin adım adım uygulandığı bir senaryo aşağıda yer almaktadır.

1. Kaynak veritabanında tnsnames.ora dosyası içinde hedef veritabanı için bir TNS girişi oluşturuyoruz ve bu TNS girişini kullanarakta bir veritabanı linki oluşturuyoruz.

TARGET_DB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.20.2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = testdb2)
) )

SQL> create database link target_db connect to hr identified by hr using 'TARGET_DB';

2. Bu veritabanı linkini impdp veya expdp komutunda belirtiyoruz.

Standby veritabanında bazı data dosyalarına redo uygulamasının durması

Eğer primary veritabanı üzerinde FORCE LOGGING etkin değilse, kullanıcıların NOLOGGING takısını kullanarak yapacakları girişler standby sunucuda ilgili tablonun veya tablolaların tutulduğu veri dosyalarına taşınmayacaktır. Bu durumdada standby üzerinde bu veri dosyalarında blok bozulmaları meydana gelecektir. Fiziksel standby veritabanındaki veri dosyalarının bir kısmının log transferini yapamadığı durumlarda bu veri dosyalarını en son SCN ye güncelleme ve kesintisiz loglamaya devam etmesini sağlamak için aşağıdaki adımları uygulayabiliriz. Tabii bu olay ile karşılaşmamak için eğer primary veritabanında FORCE LOGGING etkin değilse etkinleştirilmelidir.

1. Öncelikle standby üzerindeki hangi veri dosyalarının redo uygulamasında eksik kaldığını tespit etmemiz gerekecektir. Bunu bulmak için aşağıdaki örnekte görüldüğü üzere V$DATAFILE görünümüne sorgu çekmemiz gerekmektedir.

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE

        2> WHERE FIRST_NONLOGGED_SCN > 0;

FILE#              FIRST_NONLOGGED_SCN

----------         ------------------------------------

   3                   145957

   4                   150164

Farklı platformlar arasında Oracle veritabanını taşıma

Aynı endian formatına sahip işletim sistemleri arasında Oracle veritabanını tümüyle taşımak Oracle 10g R2 sürümünden itibaren gerçekleştirilebilmektedir. Örneğin, Windows platformunda çalışıp performans sıkıntısı yaşadıktan sonra Linux’a geçiş yapmak isteyenler için oldukça basit ve hızlı bir çözüm olmaktadır. Bunun yanında, benimde kısa zaman once başıma gelen,  kurumsal enterprise anlaşmalarında üretici firma değişikliği sonucunda, donanım ve işletim sistemlerinin radikal olarak değiştiği durumlarda Oracle DBA lere gerçekten  faydalı ve kestirme çözümler sunmakta.

Tabii, burada unutulmaması gereken en önemli nokta hedef ve kaynak işletim sistemlerinin aynı debian formatında olmasıdır. Farklı olduğu durumda taşınabilir tablespace metodunu kullanmak gerekecektir. Her iki platformun atnı debian formatında olup olmadığını  anlamak için V$TRANSPORTABLE_PLATFORM görünümüne sorgu çekmek yeterli olacaktır.

Senaryomuz gereği Windows 2003-32 bit platformdan Linux x86-64 bit platformuna  Oracle 10g R2 veritabanının nasıl taşınacağını adım-adım inceleyelim.

İlk aşamada DBMS_TDB.CHECK_DB prosedürü çalıştırılarak veritabanının hedef platforma taşınmasının mümkün olup olmadığının anlaşılması gerekecektir.Bu prosedürü çalıştırmadan once veritabanını Windows sunucuda READ ONLY modda yeniden başlatıyoruz.

Farklı endian formatında işletim sistemleri arasında tablespace taşıma

Oracle 10g sürümünden itibaren farklı endian formatına sahip işletim sistemi platformları arasında tablespace taşıması yapılabilmektedir. Farklı endian formatına sahip işletim sistemi platformlarında taşınabilir tablespace ihraç ve ithal aşamaları aşağıdadır.

Adım 1: Hedef ve kaynak veritabanında işletim sistemi byte sıralamasını buluyoruz.

SQL > select * from v$transportable_platform

            order by platform_id;

PLATFORM_ID                   PLATFORM_NAME                          ENDIAN_FORMAT
-----------------                         --------------------------                             -------------------------
1                                              Solaris[tm] OE (32-bit)                         Big
2                                              Solaris[tm] OE (64-bit)                         Big
3                                              HP-UX (64-bit)                                     Big
4                                              HP-UX IA (64-bit)                                 Big
5                                              HP Tru64 UNIX                                    Little
6                                              AIX-Based Systems (64-bit)                 Big
7                                              Microsoft Windows IA (32-bit)              Little
8                                              Microsoft Windows IA (64-bit)              Little
9                                              IBM zSeries Based Linux                    Big
10                                            Linux IA (32-bit)                                   Little
11                                            Linux IA (64-bit)                                   Little
12                                            MS Windows 64-bit for AMD                Little

Aynı endian formatındaki işletim sistemleri arasında tablespace taşıma

Transportable(taşınabilir) tablespace export ve  import işlemleri farklı platformlar arasında yapılabilmektedir,ancak sadece meta verisi ihraç edilmektedir. Farklı işletim sistemlerinde verilerin taşıması basit ve hızlı olmaktadır. Bu mod için EXP_FULL_DATABASE rolüne üye olunması gerekmektedir.

Farklı platfomlar arasında taşınabilir tablespace meta verisinin ithal ve ihraç işlemleri için aşağıdakilerin gözönünde bulundurulması gerekmektedir.

1. Kaynak ve hedef veritabanı aynı karakter setinde ve ulusal karakter setinde olmalıdır.

2. Hedef veritabanında aynı isimde tablespace bulunmamalıdır.

3. Taşınabilir tablespace ihracı durduğu zaman tekrardan başlatılamaz.
4. Hedef veritabanı kaynak veritabanı ile aynı sürümde veya daha üst sürümde olmalıdır.

Aynı endian formatına sahip farklı işletim sistemleri arasında tablespace taşıması aşağıda adım adım anlatılmaktadır;

Bozuk veya kayıp arşiv log dosyası sonrası standby veritabanını geri kurtarma

Fiziksel standby veritabanı, primary veritabanından kendisine arşivlenmiş logların sürekli uygulanması ve bu senkronizasyonun sürekli devam etmesi esasına dayanmaktadır. Oracle 10g öncesinde arşivlenmiş loglardan birinin kaybolması veya bozulması durumunda standby veritabanının yeniden inşa edilmesi gerekmekteydi.

Ancak, Oracle 10g sürümünden itibaren kayıp veya bozulmuş arşiv loglarla karşılaşıldığında artalan yedekten standby veritabanını geri kurtarabilmekteyiz.

Aşağıdaki senaryoda uygulanacağı üzere standby veritabanına senkronize edilmesi gereken 234 ve 235 sıra numaralı arşivlenmiş loglar primary veritabanından kazara silinmiştir. Şimdi bu durumda standby veritabanını geri yükleme ve çalışmaya devam etmesini adım adım inceleyelim.

RMAN-03002, RMAN-03015, RMAN-06053,RMAN-06025 hata mesajları

Sorun:
RMAN-03002: failure of Duplicate Db command at 12/25/2010 04:15:24
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 21 lowscn 674529 found to restore
RMAN-06025: no backup of log thread 1 seq 20 lowscn 674626 found to restore
Sebebi: RMAN arşiv log geri yüklemesini varsayılan istikamete yapamıyor.

Çözümü:
DUPLICATE komutu kullanılırken NOFILENAMECHECK parametresini ekleyin.
DUPLICATE TARGET DATABASE TO "clonedb" NOFILENAMECHECK;

Tüm kontrol dosyalarının silinmesinden sonra RMAN ile geri kurtarma

Bu senaryoda uygulamak amacıyla TESTTBL adlı bir tablo oluşturacağım ve içini kayıtlarla dolduracağım. En son kontrol dosyalarından veritabanını geri kurtarıp ardından felaket anından tamamlanmamış(incomplete) geri kurtarma uygulaması yapacağım. Linux platformunda Oracle 10g veritabanı kullanmaktayım.

SQL> insert into TESTTBL select * from TESTTBL;

21244 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from testtbl;

  COUNT(*)

----------

   182659   à Geri kurtarma sonrası bu kaydı kontrol etmemiz gerekecek

SQL> archive log list

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     7

Next log sequence to archive   9

Current log sequence           9

Not: Mevcut log sırası 9 dur ve henüz arşivlenmemiştir, ancak en son COMMIT işleminden sonraki bilgiler bu log dosyası içindedir.

ASM olmayan Oracle veritabanından duplike bir ASM veritabanı oluşturma

ASM olmayan dosya sistemine sahip bir Oracle veritabanından ASM dosya sistemli veritabanı klonlama yapmak veya duplike bir ASM dosya sistemli veritabanı oluşturmak için izlenecek basit adımlar altta yer almaktadır.

1. Hedef makinede statik bir listener.ora dosyası oluşturun.

(SID_DESC =

     (GLOBAL_DBNAME = DUBDB)

     (ORACLE_HOME = /u01/oracle/product/ORCL)

     (SID_NAME = DUBDB)

    )

2. Kaynak makinede tns alias oluşturun.Bu auxiliary veritabanı için kullanılacak.

DUPDBAUX =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux1)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = DUBDB)

    )

  )

3. init.ora ve password dosyasını kaynak makineden hedef makinedeki $ORACLE_HOME/dbs dizinine kopyalayın.