rman target / Arşivleri - Kamil TÜRKYILMAZ | Oracle BlogKamil TÜRKYILMAZ

11 Mart 2016 by Kamil TURKYILMAZ

ORA-00245: control file backup failed; target is likely on a local file system

RAC sistemlerde controlfile’ in backupını alırken aşağıdaki gibi bir hata alınması durumunda hatanın kaynağını ve nasıl elimine edileceği üzerine konuşuyor olacağız.

RAC olan bir database’ in controlfile’ inin backup’ ını almaya çalıştığınız da controlfile’ in snapshot controlfile backupının alındığı path non shared bir disk olarak set edildiği zaman bu hatayı alırsınız ;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 12/11/2015 11:41:28
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 12/11/2015 11:41:28
ORA-00245: control file backup failed; target is likely on a local file system

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

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

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

RMAN-03002: failure of crosscheck command at 12/11/2015 11:41:28

RMAN-03014: implicit resync of recovery catalog failed

RMAN-03009: failure of full resync command on default channel at 12/11/2015 11:41:28

ORA-00245: control file backup failed; target is likely on a local file system

Snapshot controlfile path’ imizi kontrol edelim ;
Continue reading →

07 Mart 2016 by Kamil TURKYILMAZ

+ASM İçerisindeki Datafile’ lerin Online Olarak Taşınması (ASM to ASM)

Bildiğiniz üzere oracle 12c ile birlikte online olarak datafile taşıyabilir hale gelmiştik. Bununla ilgili olarak ASM kullanılmadığı durumlarda bu işlemi nasıl yapabileceğimiz den aşağıdaki linkdeki yazımda bahsetmiştim. Ancak sonrasında bazı arkadaşlar dan ASM kullanıldığında bunu nasıl yapabiliriz diye sorular aldım. Buna cevaben de bu yazıyı yazmaya karar verdim ;

Testimizi oracle versiyonu 12.1.0.2 olan bir RAC test ortamımda yaptım.

Hangi pluggable database üzerinde çalışacak isek onu set ediyoruz;

SQL> alter session set container=PDB_RAC_CON1;
Session altered.

1 2	SQL> alter session set container=PDB_RAC_CON1; Session altered.

Diskgrouplarımıza bakalım ve örnek olarak datafile’ lerimiz den birini taşımaya karar verelim;
Continue reading →

19 Temmuz 2015 by Kamil TURKYILMAZ

12c – Pluggable Database Üzerinde Point-in-Time Recovery İşlemi

Aslında bu işlemi sadece pluggable database için düşünmemek lazım. Her zaman hata yapılabilir. Eğer bu yapılan hata database’ in sürekliliğini (daha doğrusu tutarlılığını) etkileyecek boyutta ise database hatanın yapıldığı zamanın hemen öncesine dönmemiz gerekebilir. Böylesi bir durumda ne yapabiliriz ona bakıyor olacağız.

Normal restore’ dan farkı point in time recovery ‘ den bashettiğimiz için db’ yi resetlog opsiyonu ile açıyor olmamızdır.

Bir örnek üzerinden gidelim ;

Hangi pluggable db üzerinde çalışıyoruz;

select name, open_mode  from v$pdbs ;

NAME                           OPEN_MODE 
------------------------------ ----------
PDBT11                         READ WRITE
1 row selected.

select name, open_mode from v$pdbs ;

NAME OPEN_MODE

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

PDBT11 READ WRITE

1 row selected.

Test için bir test tablosu oluşturalım.
Continue reading →

23 Mart 2012 by Kamil TURKYILMAZ

Archivelog Restore’ u Üzerine

Aslında komut ve metoloji olarak full backupdan bir farkı bulunmamaktadır. Burada da benzer komutlar ile backup setimiz içerisindeki archivelogları default dizinine veya bizim belirteceğimiz farklı bir dizine restore edebiliriz. Archivelogları neden restore etmeye ihtiyaç duyabilirim şeklinde bir soru gelenler olabilir. Eğer full restore / recover yapıyorsanız ve mutlaka son ana dönmek istiyorsanız mutlaka archive loglarınıza ihtiyaç duyacaksınız demektir, aslında archiveloglarınızı restore etmeniz için mutlaka bir restore / recover durumu olması da gerekmeyebilir. Örneğin production database’ inizde yaşanan bir problem den dolayı backupı alınmış olupda DG’ a henüz işlenmemiş olan logları silmeniz gerekebilir veya DG’ da yaşanan bir problem dolayı apply işlemi durmuş olup DG’ ının geride kalmış olup sizinde primary database ‘ inizin backuğı ile archivelogları sildiğinizi düşünün ki, böyle bir durumda sadece eksik olan arhivelogları bulabilirseniz problemi en kısa yoldan çözmüş olursunuz.

Aslında karşılaşabileceğiniz o kadar çok case varki, tümünden burada bahsetmemiz mümkün değil ancak, sık karşılaşılan durumlardan ve neler yapabileceğimizden bahsedelim ;

Archiveloglar ile ilgili history bilgisine V$LOG_HISTORY view’ inden ulaşabilirsiniz ;
Continue reading →

15 Mart 2012 by Kamil TURKYILMAZ

Recovery Catalog Kullanarak Eski Bir Backupı Farklı Bir Hosta Nasıl Restore Edebiliriz

Anlatacağımız örneğin detayından biraz bahsetmek istiyorum. Bizim örneğimizdeki durum aslında şöyle, production databaselerimizden birinin 2010 yılına ait eski bir backupı, o günkü datalarını görebilmek için farklı bir sunucu üzerine dönmemiz gerekti. Bu çalışma aslında içerisinde birçok testide barındırıyor, rman recovery catalog üzerinden restore işlemi nasıl yapılır, tape içerisindeki eski bir backup farklı bir host üzerine recovery catalog kullanılarak nasıl dönülür gibi bir takım sorulara da cevap olacağını düşünüyorum. Restore öncesinde yapmamız gereken kontrollerden de bahsederek işlemlerimize başlayalım ;

Öncelikle production sunucusu üzerinden rman cataloga bağlanıp döneceğimiz backup’ ın statüsünü bir bakalım;
Continue reading →