Merhaba,
Başlıktaki hataların ne ifade ettiğini belirtmem gerekiyor;
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'SYSTEM01.dbf'
Bu hatayı ne zaman almış olabilirsiniz?
SQL> recover database until cancel;
ORA-00279: change 22188599501 generated at 06/14/2010 01:01:50 needed for
thread 1
ORA-00289: suggestion : /backup/1_15651_679577014.dbf
ORA-00280: change 22188599501 for thread 1 is in sequence #15651
Burada önemli olan Oracle hata kodu "ORA-01194". Oracle veritabanının bu hatayı vermesinin nedeni system01.dbf datafile'ının control dosyası ile tutarlı olmaması ve daha fazla archivelog'a ihtiyacı olması. Archivelog'ları üzerine restore ederek bu hatadan kurtulup, veritabanınızı "open resetlogs" komutunu göndererek açabilirsiniz.
Öncelikle bu komutu göndermeye çalışalım;
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'SYSTEM01.dbf'
Şimdi recovery manager bağlantısını kuralım;
$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Mon Jun 14 10:50:05 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: OPTTEST (DBID=750193206, not open)
Bu noktada "restore" işlemini yapmanıza gerek yok. Recover database demek yeterli zira sadece archivelog'u yama yapacağız.
RMAN> shutdown immediate;
RMAN> startup mount;
Oracle instance started
database mounted
Total System Global Area 2147483648 bytes
Fixed Size 2057568 bytes
Variable Size 738200224 bytes
Database Buffers 1392508928 bytes
Redo Buffers 14716928 bytes
RMAN> recover database;
Starting recover at 14-JUN-10
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1487 devtype=DISK
starting media recovery
archive log thread 1 sequence 15651 is already on disk as file redo7.rdo
archive log filename=redo7.rdo thread=1 sequence=15651
media recovery complete, elapsed time: 00:00:30
Finished recover at 14-JUN-10
RMAN> alter database open resetlogs;
database opened
Recovery manager'ın gördüğü eksiklik redo7.rdo archivelog dosyasında bulundu ve gerekli olan datafile için bu güncelleştirme yapıldı. Bu bir çeşit incomplete recovery olduğu için resetlogs komutuyla veritabanını başarılı bir şekilde açabildik.
Yukarıdaki örnekte herhangi bir yedekten dönmedik ya da yararlanmadık. Kullandığımız tek şey bir adet archivelog'du ve bunun kararını da RMAN'e bıraktık.
İyi çalışmalar,
Ogan
14 Haziran 2010 Pazartesi
2 Haziran 2010 Çarşamba
"Ask Tom Live" Semineri
Merhaba,
17-18 Mayıs tarihlerinde İstanbul'a Thomas Kyte geldi ve iki günlük bir seminer düzenledi. Seminer konuları arasında materialized view'lar, depolama teknikleri, binding (bind variables) gibi konular vardı. Gerçekten çok başarılı bir seminer oldu ve bana oldukça iyi bir vizyon kattı. Zaten bu seminer'lerin amacı genelde teknik bilgi yığını sağlamak değil, konuların ne olduğunu, püf noktalarının nasıl öğrenilmesi gerektiğini anlatmak. Bunu da çok çok iyi bir biçimde başardı.
Günün anısı bir fotoğraf çekilmişti ancak bulanık çıkmış. Onu da ekliyorum.
İyi çalışmalar,
Ogan
29 Mayıs 2010 Cumartesi
Flashback Query!
Merhabalar,
Benim izlenimlerim arasında bir Oracle özelliği var ki; gerçekten şimdiye kadar geliştirilmiş en güzel Oracle veritabanı özelliği olduğunu düşünüyorum. Bir RAC ya da Data Guard gibi veya ASM gibi ileri düzey ve sistem seviyesinde de çalışmakta olan bir özellik değil ancak hayat kurtarabiliyor. Bu arkadaşımızın adı ise "Flashback". Bu konuyla ilgili daha önce de yazı yazmıştım ve "Flashback Database" komutu ile veritabanını bir yedekleme sistemi kullanmadan nasıl eski tarihe döndürebiliriz onu açıklamıştım.
Öncelikle birkaç örnek vermek istiyorum;
Bir kullanıcınız var ve aktif olarak sorgu çalıştırıyor, tablolara erişip veri siliyor, tablo yaratıyor, paket yaratıyor ya da değiştiriyor. Bunları yaparken de bir tabloda silmemesi gereken bir veriyi, bir arayüz ya da yazdığı sorgu aracılığı ile siliyor ve commit gönderiyor. Geçmiş olsun mu demek lazım ya da soğuk su mu ikram etmek lazım? Cevap, hiçbiri çünkü undo tablespace'in segment'lerinde bundan önceki tablonun şekli de tutuluyor! Bu noktada bir hatırlatma, Flashback bir 10g özelliğidir.
Kullanıcının yapması gereken veritabanı yöneticisi olan kişiye durumu acil bildirecek. İlk yapması gereken budur. Çünkü bu tablodan silinen kayıtların da undo'larda tutulduğu bir süre bulunuyor. Bu süreyi de undo_retention parametresi, saniye türünden belirliyor. Bu parametreyi ne kadar uzun tutarsanız o kadar geriye dönebilir ve görmek istediğiniz verileri görebilirsiniz. Yüksek tutarsanız alandan kaybedersiniz, düşük tutarsanız da geriye dönebildiğiniz zaman aralığı azalır. Bu noktada tercih merkezi veritabanı yöneticisidir.
Kullanım yöntemi ve şeklini ise birkaç örnekle göstermem gerekirse;
SQL> select * from tablo_adi as of timestamp sysdate-3/24; (3 saat önceki tablonuz).
SQL> select * from tablo_adi as of scn scn_sayisi (belirtilen scn'deki tablonuz).
Insert ya da update komutları ile de alt sorgu mahiyetinde de kullanabilirsiniz. Bu noktada PK ya da FK varsa dikkat edilmeli.
Flashback query undo segment'lerini kullanmaktayken rollback komutu ise system segment'lerini kullanıyor. Bu farkı da unutmamak gerekir.
İyi çalışmalar,
Ogan
Benim izlenimlerim arasında bir Oracle özelliği var ki; gerçekten şimdiye kadar geliştirilmiş en güzel Oracle veritabanı özelliği olduğunu düşünüyorum. Bir RAC ya da Data Guard gibi veya ASM gibi ileri düzey ve sistem seviyesinde de çalışmakta olan bir özellik değil ancak hayat kurtarabiliyor. Bu arkadaşımızın adı ise "Flashback". Bu konuyla ilgili daha önce de yazı yazmıştım ve "Flashback Database" komutu ile veritabanını bir yedekleme sistemi kullanmadan nasıl eski tarihe döndürebiliriz onu açıklamıştım.
Öncelikle birkaç örnek vermek istiyorum;
Bir kullanıcınız var ve aktif olarak sorgu çalıştırıyor, tablolara erişip veri siliyor, tablo yaratıyor, paket yaratıyor ya da değiştiriyor. Bunları yaparken de bir tabloda silmemesi gereken bir veriyi, bir arayüz ya da yazdığı sorgu aracılığı ile siliyor ve commit gönderiyor. Geçmiş olsun mu demek lazım ya da soğuk su mu ikram etmek lazım? Cevap, hiçbiri çünkü undo tablespace'in segment'lerinde bundan önceki tablonun şekli de tutuluyor! Bu noktada bir hatırlatma, Flashback bir 10g özelliğidir.
Kullanıcının yapması gereken veritabanı yöneticisi olan kişiye durumu acil bildirecek. İlk yapması gereken budur. Çünkü bu tablodan silinen kayıtların da undo'larda tutulduğu bir süre bulunuyor. Bu süreyi de undo_retention parametresi, saniye türünden belirliyor. Bu parametreyi ne kadar uzun tutarsanız o kadar geriye dönebilir ve görmek istediğiniz verileri görebilirsiniz. Yüksek tutarsanız alandan kaybedersiniz, düşük tutarsanız da geriye dönebildiğiniz zaman aralığı azalır. Bu noktada tercih merkezi veritabanı yöneticisidir.
Kullanım yöntemi ve şeklini ise birkaç örnekle göstermem gerekirse;
SQL> select * from tablo_adi as of timestamp sysdate-3/24; (3 saat önceki tablonuz).
SQL> select * from tablo_adi as of scn scn_sayisi (belirtilen scn'deki tablonuz).
Insert ya da update komutları ile de alt sorgu mahiyetinde de kullanabilirsiniz. Bu noktada PK ya da FK varsa dikkat edilmeli.
Flashback query undo segment'lerini kullanmaktayken rollback komutu ise system segment'lerini kullanıyor. Bu farkı da unutmamak gerekir.
İyi çalışmalar,
Ogan
Kaydol:
Kayıtlar (Atom)