RESTORE POINT (KURTARMA NOKTASI)
Bazen öyle durumlar olur ki veritabanınızı bir an önce kapatmanız gerekebilir.
böyle durumlarda SHUTDOWN IMMEDIATE demek yeterli olmayacaktır. SHUTDOWN ABORT komutunu kullanmak isteyeceksiniz.
fakat shutdown abort komutunun bazı dezavantajları var, veri kaybı yaşayabilrsiniz. Bu tip durumları aşmak için öncelik ile
restore point(kurtarma noktası) oluşturuyoruz.
Veritabanımızın kurtarma noktası özelliğini kullanabilmemiz için flashback modu'nun açılmış olması gerekmektedir.
Bu konu ilgili bilgiyi buradan alabilirsiniz.
Database'i kapatmadan hemen önce bir kurtarma noktası oluşturuyorum.
SQL> create restore point kapatmadan_once;
Geri yükleme noktası yaratıldı.
database'i hızlı bir şekilde kapatmak için
SQL> shutdown abort;
ORACLE anı kapatıldı.
daha sonra mount modda açıyoruz.Bu şekilde kullanıcıların sisteme erişmelerini kısıtlamış oluyoruz.
SQL> startup mount;
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 234883972 bytes
Database Buffers 369098752 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
En son aldığımız restore point'e dönüyoruz.
SQL> flashback database to restore point kapatmadan_once;
Gerisinyal tamamlandı.
Son olarak Veritabanını bütün kullanıcıları açıyoruz. Hadi hayırlısı.
SQL> alter database open resetlogs;
Veritabanı değiştirildi.
oluştuşturduğumuz restore point silmek için
SQL> drop restore point kapatmadan_once;
Geri yükleme noktası bırakıldı.
SQL> drop restore point deneme1;
Geri yükleme noktası bırakıldı.
restore point(kuratma noktaları) listelemek için
SQL> select scn,name from v$restore_point ;
satır seçilmedi
http://www.oracle.com/technology/oramag/oracle/06-nov/o66recovery.html
Showing posts with label YEDEKLEME. Show all posts
Showing posts with label YEDEKLEME. Show all posts
Tuesday, September 1, 2009
DATABASE FLASHBACK AYARLARI
Veritabanımızın flashback özelliğini açmak için aşağıdaki adımları izlemiz yeterli olacaktır.
Bu işlemleri yapmaya başlamadan önce bazı FLASHBACK parametrelerini ayarlamamız gerekecektir.
* DB_RECOVERY_FILE_DEST
* DB_RECOVERY_FILE_DEST_SIZE
* DB_FLASHBACK_RETENTION_TARGET
Bu parametreleri kısaca açıklamak gerekir ise
DB_RECOVERY_FILE_DEST FLASHBACK için kullanılacak olan dosyaların yerini belirtiyoruz.
DB_RECOVERY_FILE_DEST_SIZE ne kadarlık bir alanı bu iş için ayrıcağımızı belirtiyoruz. Bu parametreyi belirlerken FLASHBACK özelliğini kaç gün (ne kadarlık bir zaman dilimi ) için kullanacağız, Bu zaman diliminde üretilmesini tahmin ettiğimiz veri miktarı ne olacak, son olarak disk kapasitemiz ne kadar. Bu iş için ayırdığımız 500GB lik bir diskimiz var ise bunun tamamını buraya tahsis etmeyelim 450 GB sini verelim olurda disk dolar ve database'de işlemler devam ederken DB_RECOVERY_FILE_DEST_SIZE alanı doldu doluyor uyarısı alırsak tam dolmadan önlem alabiliriz.
DB_FLASHBACK_RETENTION_TARGET parametresi verileminiz ne kadarlık bir zaman dilimi için saklayacağimi belirtiyor. Burada 24 saat (1 günlük) olsun derseniz 24*60=1440 değerini belirlememiz gerekir. Anlaşılacağı gibi dakika olarak belirliyoruz.
DB_FLASHBACK_RETENTION_TARGET ve DB_RECOVERY_FILE_DEST_SIZE parametreleri sizin de farkedebileceğiniz gibi birbirleri ile ilişki içerisindeler.
senaryomuzun şu şekilde olduğunu varsayarsak benim günlük olarak 100 gb flashback datam oluşuyor, flashback dönme süremi 7 gün olarak belirliyorum.
bu durumda en az 700 GB lik bir DB_RECOVERY_FILE_DEST_SIZE alanına ihtiyacım olacak.
ORA-38700: Limit of %s flashback database logs has been exceed
Bu hata ile karşılaşmanız kaçınılmaz olacaktır.
Kurulum ile beraber varsayılan olarak gelen parametreler aşağıdaki sorgu ile görülebilir.
select * from v$parameter where name like '%db_recovery%' or name like '%db_flashback%'
Şimdi parametreleri ayarlamaya geldi sıra. Dosyalarımızı nerede saklayacağımızı belirliyoruz.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='C:\flashback_alani\';
Ne kadarlık bir süre için saklayacağımızı belirliyoruz.
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=10080; -- 1 hafta haftalık full backup aldığımı varsayıyorum. Yeterli alanımda var :))
FLASHBACK için ayırdığım disk alanını belirliyorum.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=30G; -- 30 Gb olarak belirledim.
Evet flashback parametrelerini belirdik. Şimdi veritabanımızı flashback moda geçirelim. Ben makinamda yaptığım adımları aşağıda belirtiyorum.
Veritabanını açıyoruz.
SQL> startup;
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 201329540 bytes
Database Buffers 402653184 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
Veritabanı açıldı.
SQL>
Hangi modda olduğunu görelim. Ben daha önce ARCHIVELOG moda almıştım (RMAN için). Flashback özelliğinin ARCHIVELOG mod istediğini belirtmek için
gecici olarak NOARCHIVELOG moda gececeğim.
SQL> select name,log_mode from v$database;
NAME LOG_MODE
--------- ------------
ORCL ARCHIVELOG
FLASHBACK özelliğini kontrol ediyoruz.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
SQL> shutdown immediate;
Veritabanı kapatıldı.
Veritabanı kullanıma kapatıldı.
ORACLE anı kapatıldı.
SQL> alter database noarchivelog;
alter database noarchivelog
*
1 satırında HATA:
ORA-01034: ORACLE not available
SQL> startup mount
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 205523844 bytes
Database Buffers 398458880 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
SQL> alter database noarchivelog;
Veritabanı değiştirildi
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
NOARCHIVELOG modda olmadığını görüyoruz.
SQL> alter database flashback on;
alter database flashback on
*
1 satırında HATA:
ORA-38706: FLASHBACK VERITABANI günlüge kaydetme açilamiyor.
ORA-38707: Ortam kurtarma etkin degil.
SQL> ALTER DATABASE FLASHBACK ON;
ALTER DATABASE FLASHBACK ON
*
1 satırında HATA:
ORA-38706: FLASHBACK VERITABANI günlüge kaydetme açilamiyor.
ORA-38707: Ortam kurtarma etkin degil.
SQL> alter database archivelog;
Veritabanı değiştirildi
ve işlem tamam.
SQL> ALTER DATABASE FLASHBACK ON;
Veritabanı değiştirildi
SQL> alter database open;
ve işlem tamam. Artık anlık olarak yedekten dönebileceğiz. Kullanıcıların yanlışlık ile sildiği tablolar geri gelebicek.
Veritabanı değiştirildi
SQL>
FLASHBACK alanının son durumunu görmek için
SELECT NAME, TO_CHAR (space_limit, '999,999,999,999') AS flashback_max_size,
TO_CHAR (space_limit - space_used + space_reclaimable,
'999,999,999,999'
) AS flashback_kalan_alan,
ROUND ((space_used - space_reclaimable) / space_limit * 100,
1
) AS pct_full
FROM v$recovery_file_dest;
ayrıntılı bilgili buradan alabilirsiniz.
http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm
http://www.cagataycebi.com/oracle/oracle_flashback_db.pdf
Bu işlemleri yapmaya başlamadan önce bazı FLASHBACK parametrelerini ayarlamamız gerekecektir.
* DB_RECOVERY_FILE_DEST
* DB_RECOVERY_FILE_DEST_SIZE
* DB_FLASHBACK_RETENTION_TARGET
Bu parametreleri kısaca açıklamak gerekir ise
DB_RECOVERY_FILE_DEST FLASHBACK için kullanılacak olan dosyaların yerini belirtiyoruz.
DB_RECOVERY_FILE_DEST_SIZE ne kadarlık bir alanı bu iş için ayrıcağımızı belirtiyoruz. Bu parametreyi belirlerken FLASHBACK özelliğini kaç gün (ne kadarlık bir zaman dilimi ) için kullanacağız, Bu zaman diliminde üretilmesini tahmin ettiğimiz veri miktarı ne olacak, son olarak disk kapasitemiz ne kadar. Bu iş için ayırdığımız 500GB lik bir diskimiz var ise bunun tamamını buraya tahsis etmeyelim 450 GB sini verelim olurda disk dolar ve database'de işlemler devam ederken DB_RECOVERY_FILE_DEST_SIZE alanı doldu doluyor uyarısı alırsak tam dolmadan önlem alabiliriz.
DB_FLASHBACK_RETENTION_TARGET parametresi verileminiz ne kadarlık bir zaman dilimi için saklayacağimi belirtiyor. Burada 24 saat (1 günlük) olsun derseniz 24*60=1440 değerini belirlememiz gerekir. Anlaşılacağı gibi dakika olarak belirliyoruz.
DB_FLASHBACK_RETENTION_TARGET ve DB_RECOVERY_FILE_DEST_SIZE parametreleri sizin de farkedebileceğiniz gibi birbirleri ile ilişki içerisindeler.
senaryomuzun şu şekilde olduğunu varsayarsak benim günlük olarak 100 gb flashback datam oluşuyor, flashback dönme süremi 7 gün olarak belirliyorum.
bu durumda en az 700 GB lik bir DB_RECOVERY_FILE_DEST_SIZE alanına ihtiyacım olacak.
ORA-38700: Limit of %s flashback database logs has been exceed
Bu hata ile karşılaşmanız kaçınılmaz olacaktır.
Kurulum ile beraber varsayılan olarak gelen parametreler aşağıdaki sorgu ile görülebilir.
select * from v$parameter where name like '%db_recovery%' or name like '%db_flashback%'
Şimdi parametreleri ayarlamaya geldi sıra. Dosyalarımızı nerede saklayacağımızı belirliyoruz.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='C:\flashback_alani\';
Ne kadarlık bir süre için saklayacağımızı belirliyoruz.
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=10080; -- 1 hafta haftalık full backup aldığımı varsayıyorum. Yeterli alanımda var :))
FLASHBACK için ayırdığım disk alanını belirliyorum.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=30G; -- 30 Gb olarak belirledim.
Evet flashback parametrelerini belirdik. Şimdi veritabanımızı flashback moda geçirelim. Ben makinamda yaptığım adımları aşağıda belirtiyorum.
Veritabanını açıyoruz.
SQL> startup;
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 201329540 bytes
Database Buffers 402653184 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
Veritabanı açıldı.
SQL>
Hangi modda olduğunu görelim. Ben daha önce ARCHIVELOG moda almıştım (RMAN için). Flashback özelliğinin ARCHIVELOG mod istediğini belirtmek için
gecici olarak NOARCHIVELOG moda gececeğim.
SQL> select name,log_mode from v$database;
NAME LOG_MODE
--------- ------------
ORCL ARCHIVELOG
FLASHBACK özelliğini kontrol ediyoruz.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
SQL> shutdown immediate;
Veritabanı kapatıldı.
Veritabanı kullanıma kapatıldı.
ORACLE anı kapatıldı.
SQL> alter database noarchivelog;
alter database noarchivelog
*
1 satırında HATA:
ORA-01034: ORACLE not available
SQL> startup mount
ORACLE anı başlatıldı.
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 205523844 bytes
Database Buffers 398458880 bytes
Redo Buffers 7135232 bytes
Veritabanı kullanıma açıldı.
SQL> alter database noarchivelog;
Veritabanı değiştirildi
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
NOARCHIVELOG modda olmadığını görüyoruz.
SQL> alter database flashback on;
alter database flashback on
*
1 satırında HATA:
ORA-38706: FLASHBACK VERITABANI günlüge kaydetme açilamiyor.
ORA-38707: Ortam kurtarma etkin degil.
SQL> ALTER DATABASE FLASHBACK ON;
ALTER DATABASE FLASHBACK ON
*
1 satırında HATA:
ORA-38706: FLASHBACK VERITABANI günlüge kaydetme açilamiyor.
ORA-38707: Ortam kurtarma etkin degil.
SQL> alter database archivelog;
Veritabanı değiştirildi
ve işlem tamam.
SQL> ALTER DATABASE FLASHBACK ON;
Veritabanı değiştirildi
SQL> alter database open;
ve işlem tamam. Artık anlık olarak yedekten dönebileceğiz. Kullanıcıların yanlışlık ile sildiği tablolar geri gelebicek.
Veritabanı değiştirildi
SQL>
FLASHBACK alanının son durumunu görmek için
SELECT NAME, TO_CHAR (space_limit, '999,999,999,999') AS flashback_max_size,
TO_CHAR (space_limit - space_used + space_reclaimable,
'999,999,999,999'
) AS flashback_kalan_alan,
ROUND ((space_used - space_reclaimable) / space_limit * 100,
1
) AS pct_full
FROM v$recovery_file_dest;
ayrıntılı bilgili buradan alabilirsiniz.
http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm
http://www.cagataycebi.com/oracle/oracle_flashback_db.pdf
Monday, August 17, 2009
ALTER SYSTEM SWITCH LOGFILE;
LOGFILE'LERİ KAYDETMEK
ALTER SYSTEM SWITCH LOGFILE;
LGWR (Log Writer) Bir redo log grubuna yazmayı bitirdiğinde diğer gruba gecer. LGWR bir log group dolduğunda diğerine yazma işlemlerini otomatik olarak yapar . Yazmakta olduğu grup active durumdadır. Yazma işlemini bitirdikleri ise inactive duruma gecer.
Redo loglarda düzenleme yapmak için bazen active durumdaki grupları inactive yapmak gerekebilir. Örneğin active olan bir redo group'u silmek istiyorsunuz. active olan bir redo grup'u inactive olana kadar silemezsiniz. Öncelik ile buradaki verilerin datafilelere yazılması gerekir. Şu şekilde bir senaryoda yaratabiliriz. Şu anda active olan bir redolog groubunu arşivlemek istiyorsak bu grubun dolmasını beklememiz gerekiyor. Bazen redo log gruplarımız o kadar büyük olur ki dolamsını beklemek uzun zaman alabilir.
Log dosyalrını kaydetmek için ALTER SYSTEM yetkimizin olması gerekiyor.
ALTER SYSTEM SWITCH LOGFILE; komutu işimizi görüyor.
Redo loglarımız datafilelere yazıyoruz. Bu işlemden sonra backuplama arşivleme işlemini yapabiliriz.
Kullanıldığı birkaç yere örnek vermek gerekir ise
1- full backup almadan önce redo loglardaki verileri datafilelere yazmak isteyebilirsiniz.
2- Database NOACRHIVELOG moddan ARCHIVELOG moda alma sırasında kullanabilirsiniz.
Aşağıdaki sorgu ile loglarımızın durumunu görebilriz.
select GROUP#, ARCHIVED, STATUS from v$log;
Active durumdaki bir redolog file'ı silmek isteğimizde aşağıdaki hatayı alırız.Bu durumda
ALTER SYSTEM SWITCH LOGFILE ile inactive hale getirdikten sonra silebiliriz.
ORA-01624: 2 günlügü, orcl (thread 1) aninin çökme durumunda kurtarilmasi için gerekli
ORA-00312: çevrimiçi günlük 2, thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG'
Yeni bir redolog file eklemek için aşağıdaki scripti kullanabiliriz
ALTER DATABASE
ADD LOGFILE ('C:\oracle\product\10.2.0\oradata\ORCL\REDO03.LOG') SIZE 50000K;
ALTER SYSTEM SWITCH LOGFILE;
LGWR (Log Writer) Bir redo log grubuna yazmayı bitirdiğinde diğer gruba gecer. LGWR bir log group dolduğunda diğerine yazma işlemlerini otomatik olarak yapar . Yazmakta olduğu grup active durumdadır. Yazma işlemini bitirdikleri ise inactive duruma gecer.
Redo loglarda düzenleme yapmak için bazen active durumdaki grupları inactive yapmak gerekebilir. Örneğin active olan bir redo group'u silmek istiyorsunuz. active olan bir redo grup'u inactive olana kadar silemezsiniz. Öncelik ile buradaki verilerin datafilelere yazılması gerekir. Şu şekilde bir senaryoda yaratabiliriz. Şu anda active olan bir redolog groubunu arşivlemek istiyorsak bu grubun dolmasını beklememiz gerekiyor. Bazen redo log gruplarımız o kadar büyük olur ki dolamsını beklemek uzun zaman alabilir.
Log dosyalrını kaydetmek için ALTER SYSTEM yetkimizin olması gerekiyor.
ALTER SYSTEM SWITCH LOGFILE; komutu işimizi görüyor.
Redo loglarımız datafilelere yazıyoruz. Bu işlemden sonra backuplama arşivleme işlemini yapabiliriz.
Kullanıldığı birkaç yere örnek vermek gerekir ise
1- full backup almadan önce redo loglardaki verileri datafilelere yazmak isteyebilirsiniz.
2- Database NOACRHIVELOG moddan ARCHIVELOG moda alma sırasında kullanabilirsiniz.
Aşağıdaki sorgu ile loglarımızın durumunu görebilriz.
select GROUP#, ARCHIVED, STATUS from v$log;
Active durumdaki bir redolog file'ı silmek isteğimizde aşağıdaki hatayı alırız.Bu durumda
ALTER SYSTEM SWITCH LOGFILE ile inactive hale getirdikten sonra silebiliriz.
ORA-01624: 2 günlügü, orcl (thread 1) aninin çökme durumunda kurtarilmasi için gerekli
ORA-00312: çevrimiçi günlük 2, thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG'
Yeni bir redolog file eklemek için aşağıdaki scripti kullanabiliriz
ALTER DATABASE
ADD LOGFILE ('C:\oracle\product\10.2.0\oradata\ORCL\REDO03.LOG') SIZE 50000K;
silmek içinde
select GROUP#, ARCHIVED, STATUS from v$log;
sorgusu ile inactive durumda olan redologun group nosunu öğrendikten sonra
ALTER DATABASE DROP LOGFILE GROUP 3; komutunu kullanabiliriz.
Thursday, August 13, 2009
REDO LOG DOSYALARININ BOZULMASI VE KURTARMA
Redo Log Dosyalarının bozulması durumunda aşağıdaki hataları alabilirsiniz.
ORA-16038 log %s sequence# %s cannot be archived
ORA-367 checksum error in log file header
ORA-368 checksum error in redo log block
ORA-354 corrupt redo log block header
ORA-353 log corruption near block change time
Solution:- bu durumda log fileleri temezlemektir.bu işlemi yaparken database'i kapatmaya gerek yoktur.
alter database clear logfile group 1;
alter database clear unarchived logfile group 1;
Eğer sadece iki tane log grubunuz var ise ve logfile CURRENT/ACTIVE durumundaysa silinmiş yada bozulmuş olan redologlar kurtarmak mümkün değildir.Bu durumdan kurtulmak için instance recovery yapmak gerekir. Aksi halde ORA-01624: günlüğü, (thread ) anının çökme durumunda kurtarılması için gerekli. hatasını alabilirsiniz.
ALTER SYSTEM SWITCH LOGFILE; ile ACTIVE durumdakileri inactive statusüne çekebilirsiniz.
ORA-16038 log %s sequence# %s cannot be archived
ORA-367 checksum error in log file header
ORA-368 checksum error in redo log block
ORA-354 corrupt redo log block header
ORA-353 log corruption near block change time
Solution:- bu durumda log fileleri temezlemektir.bu işlemi yaparken database'i kapatmaya gerek yoktur.
alter database clear logfile group 1;
alter database clear unarchived logfile group 1;
Eğer sadece iki tane log grubunuz var ise ve logfile CURRENT/ACTIVE durumundaysa silinmiş yada bozulmuş olan redologlar kurtarmak mümkün değildir.Bu durumdan kurtulmak için instance recovery yapmak gerekir. Aksi halde ORA-01624: günlüğü, (thread ) anının çökme durumunda kurtarılması için gerekli. hatasını alabilirsiniz.
ALTER SYSTEM SWITCH LOGFILE; ile ACTIVE durumdakileri inactive statusüne çekebilirsiniz.
Tuesday, August 11, 2009
RMAN İLE DATAFILE KURTARMA
Bozuk yada silinmiş olan bir datafile kurtarma işlemlerini basit bir senaryo ile anlatmaya çalıştım.
Öncelik ile bir tablespace yaratalım
CREATE SMALLFILE TABLESPACE "DENEME1" DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' SIZE 100M REUSE AUTOEXTEND ON NEXT 1024K MAXSIZE 32767M , 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME3' REUSE LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
Şimdi bu tablespace'e bir datafile ekleyelim.
ALTER TABLESPACE "DENEME1" ADD DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' SIZE 102400K REUSE AUTOEXTEND ON NEXT 1024K MAXSIZE 32767M
daha sonra bu tablespace de bir user oluşturalım.
CREATE USER "RMAN_DEN" PROFILE "DEFAULT" IDENTIFIED BY "*******" DEFAULT TABLESPACE "DENEME1" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK
GRANT UNLIMITED TABLESPACE TO "RMAN_DEN" WITH ADMIN OPTION
GRANT "CONNECT" TO "RMAN_DEN" WITH ADMIN OPTION
GRANT "RESOURCE" TO "RMAN_DEN" WITH ADMIN OPTION
şimdi bu user altında bir tablo oluşturalım.
CREATE TABLE rman_den.tablom
AS
SELECT *
FROM all_objects
son durumu özetlemek gerekir ise elimizde bir tablespace bu tablecpace'yi kullanan bir user (schema) sonra bu tablespace'de tanımlanmış bir datafile var . Biz burada ne yapacağiz; Datafile bozulmuş senaryosu yaratacağız.
Önce RMAN ile ilgili datafile'in backupını alıyoruz.
RMAN> backup datafile 6;
elimizde backupımız var.
RMAN> LIST BACKUP of datafile 6;
aşağıdaki komut ile datafile'i siliyoruz.
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
OFFLINE DROP;
şimdi datafile üzerinde işlem yapmaya çalışalım.
select * from rman_den.tablom
ORA-00376: 6 dosyasi su anda okunamiyor
ORA-01110: veri dosyasi 6: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
Bu hatayı alıyoruz. Bunun ne anlama geldiğini şimdi daha iyi anlayabiliriz.
Bu hatadan kurtulmak için backupdan dönme işlemini gerçekleştiriyoruz.
işletim sisteminde de dosyayı sildikten sonra
RMAN> restore datafile 6;
RMAN> recover datafile 6;
İle geri yükleme ve kurtarma işlemini tamalıyoruz. Bu işlemden sonra offline durumda olan datafile'i online yapmaktır.
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' ONLINE
online yapma işlemini RMAN'de de yapabiliriz bunun için bir run scripti hazırlıyoruz.
Kurtarma işleminden sonra RMAN ilgili sql'i çalıştıracktır.
RMAN>RUN{
restore datafile 6;
recover datafile 6;
SQL "ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' ONLINE";
}
select * from dba_data_files -- sorgusu ile datafile'lerimizin son halini görelim.
Bu sorgu ile hem datafilelelerin konumlarını, isimlerini ve numaraları öğrenebiliriz.
Bozuk olan bir Datafile'dan RMAN ile dönme işlemini gerçekleştirmiş olduk.
Aşağıdaki hatalarda da yukarıdaki işlemleri yapılabilir.
SYS aliates 11/08/2009 >alter database open;
alter database open
*
1 satırında HATA:
ORA-01122: 6 veritabani dosyasi onaylama kontrolünü geçemedi
ORA-01110: veri dosyasi 6: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
ORA-01251: Dosya numarasi 6 için bilinmeyen Dosya üstbilgiler Sürümü okundu
ORA-01157: 6 veri dosyasi tanimlanamaz veya kilitlenemez - DBWR izleme
bu hatalardan kurtulmanın bir diğer yöntemi ise ilgili datafileleri offline duruma çekmektir.
SYS aliates 11/08/2009 >alter database datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME4' offline;
SYS aliates 11/08/2009 >alter database open;
Veritabanı değiştirildi.
/////////////////////////////////////////////////////////////////////
offline olan datafile'yi rman ile kurtarabiliriz.
örneğin
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' offline dediniz ve datafile offline oldu
herhangibi bir sorgu çalıştırdığınızda
ORA-00376: 9 dosyasi su anda okunamiyor
ORA-01110: veri dosyasi 9:
hatasınız alırsınız bundan kurulmak için
C:\Documents and Settings\rdcaates>rman target /
Kurtarma ¦darecisi : Release 10.2.0.1.0 - Production on Sal Au 25 21:21:21 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
hedef veritaban²na balanıldı: ORCL (DBID=1223590477)
RMAN> recover datafile 9;
recover başlatılıyor; saat 25/08/2009
kurtarma katalou yerine hedef veritabanı kontrol dosyası kullanılıyor
ayr²lan kanal: ORA_DISK_1
ORA_DISK_1 kanalı: sid=133 aygt³r³=DISK
ortam kurtarmayı başlatma
ortam kurtarma tamamlandı , geçen süre: 00:00:02
recover tamamlandı; saat 25/08/2009
RMAN>
işleminden sonra kurtarma işlemi başarılı bir şekilde tamamlanmış oldu.
Burada eğer datafileniz silindiyse yada yerinde yok ise o zaman yukarıdaki adımları yapmalısınız.
Öncelik ile bir tablespace yaratalım
CREATE SMALLFILE TABLESPACE "DENEME1" DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' SIZE 100M REUSE AUTOEXTEND ON NEXT 1024K MAXSIZE 32767M , 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME3' REUSE LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
Şimdi bu tablespace'e bir datafile ekleyelim.
ALTER TABLESPACE "DENEME1" ADD DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' SIZE 102400K REUSE AUTOEXTEND ON NEXT 1024K MAXSIZE 32767M
daha sonra bu tablespace de bir user oluşturalım.
CREATE USER "RMAN_DEN" PROFILE "DEFAULT" IDENTIFIED BY "*******" DEFAULT TABLESPACE "DENEME1" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK
GRANT UNLIMITED TABLESPACE TO "RMAN_DEN" WITH ADMIN OPTION
GRANT "CONNECT" TO "RMAN_DEN" WITH ADMIN OPTION
GRANT "RESOURCE" TO "RMAN_DEN" WITH ADMIN OPTION
şimdi bu user altında bir tablo oluşturalım.
CREATE TABLE rman_den.tablom
AS
SELECT *
FROM all_objects
son durumu özetlemek gerekir ise elimizde bir tablespace bu tablecpace'yi kullanan bir user (schema) sonra bu tablespace'de tanımlanmış bir datafile var . Biz burada ne yapacağiz; Datafile bozulmuş senaryosu yaratacağız.
Önce RMAN ile ilgili datafile'in backupını alıyoruz.
RMAN> backup datafile 6;
elimizde backupımız var.
RMAN> LIST BACKUP of datafile 6;
aşağıdaki komut ile datafile'i siliyoruz.
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
OFFLINE DROP;
şimdi datafile üzerinde işlem yapmaya çalışalım.
select * from rman_den.tablom
ORA-00376: 6 dosyasi su anda okunamiyor
ORA-01110: veri dosyasi 6: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
Bu hatayı alıyoruz. Bunun ne anlama geldiğini şimdi daha iyi anlayabiliriz.
Bu hatadan kurtulmak için backupdan dönme işlemini gerçekleştiriyoruz.
işletim sisteminde de dosyayı sildikten sonra
RMAN> restore datafile 6;
RMAN> recover datafile 6;
İle geri yükleme ve kurtarma işlemini tamalıyoruz. Bu işlemden sonra offline durumda olan datafile'i online yapmaktır.
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' ONLINE
online yapma işlemini RMAN'de de yapabiliriz bunun için bir run scripti hazırlıyoruz.
Kurtarma işleminden sonra RMAN ilgili sql'i çalıştıracktır.
RMAN>RUN{
restore datafile 6;
recover datafile 6;
SQL "ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' ONLINE";
}
select * from dba_data_files -- sorgusu ile datafile'lerimizin son halini görelim.
Bu sorgu ile hem datafilelelerin konumlarını, isimlerini ve numaraları öğrenebiliriz.
Bozuk olan bir Datafile'dan RMAN ile dönme işlemini gerçekleştirmiş olduk.
Aşağıdaki hatalarda da yukarıdaki işlemleri yapılabilir.
SYS aliates 11/08/2009 >alter database open;
alter database open
*
1 satırında HATA:
ORA-01122: 6 veritabani dosyasi onaylama kontrolünü geçemedi
ORA-01110: veri dosyasi 6: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2'
ORA-01251: Dosya numarasi 6 için bilinmeyen Dosya üstbilgiler Sürümü okundu
ORA-01157: 6 veri dosyasi tanimlanamaz veya kilitlenemez - DBWR izleme
bu hatalardan kurtulmanın bir diğer yöntemi ise ilgili datafileleri offline duruma çekmektir.
SYS aliates 11/08/2009 >alter database datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME4' offline;
SYS aliates 11/08/2009 >alter database open;
Veritabanı değiştirildi.
/////////////////////////////////////////////////////////////////////
offline olan datafile'yi rman ile kurtarabiliriz.
örneğin
ALTER DATABASE DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DENEME2' offline dediniz ve datafile offline oldu
herhangibi bir sorgu çalıştırdığınızda
ORA-00376: 9 dosyasi su anda okunamiyor
ORA-01110: veri dosyasi 9:
hatasınız alırsınız bundan kurulmak için
C:\Documents and Settings\rdcaates>rman target /
Kurtarma ¦darecisi : Release 10.2.0.1.0 - Production on Sal Au 25 21:21:21 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
hedef veritaban²na balanıldı: ORCL (DBID=1223590477)
RMAN> recover datafile 9;
recover başlatılıyor; saat 25/08/2009
kurtarma katalou yerine hedef veritabanı kontrol dosyası kullanılıyor
ayr²lan kanal: ORA_DISK_1
ORA_DISK_1 kanalı: sid=133 aygt³r³=DISK
ortam kurtarmayı başlatma
ortam kurtarma tamamlandı , geçen süre: 00:00:02
recover tamamlandı; saat 25/08/2009
RMAN>
Burada eğer datafileniz silindiyse yada yerinde yok ise o zaman yukarıdaki adımları yapmalısınız.
Friday, August 7, 2009
ORA-04031: unable to allocate 27992 bytes of shared memory While Taking RMAN Backup.
RMAN ile backup alırken aşağıdaki hatayı alabiliriz.
ORA-04031: unable to allocate NNNNNN bytes of shared memory While Taking RMAN Backup.
Bu hatanın sebebi yeterli LARGE_POOL_SIZE olmamasıdır. Bu alanı arttırmnın gerekecektir. Bu alanın ne kadar olduğunu görmek için
SQL> show parameter large
NAME TYPE VALUE
------------------------------------ -----------
large_pool_size big integer 0
burada değeri 0 görüyoruz bunun sebebi daha önceden belirlememiş olmamız. Sistemimizin özellikleri, RAM miktarımız ,databasede yapılan işlemler vs.. 'e göre kendimiz bir değer verebiliriz.
SQL> ALTER SYSTEM set LARGE_POOL_SIZE = 20 M;
Sistem dei■tirildi.
SQL> show parameter large
NAME TYPE VALUE
------------------------------------ ----------- -------------
large_pool_size big integer 20M
burada 20MB değerini görüyoruz ben burada deneme amaçlı olarak sallama bir değer verdim.
Unix makinada ram miktarınızı görmek için
prtconf |grep Mem
Memory Size: 255232 MB
Good Memory Size: 255232 MB
not : HDD gibi RAM makinada :)))
ALTER SYSTEM set SHARED_POOL_SIZE = 20m;
Bunuda arttırmanız da fayda var.
ORA-04031: unable to allocate 127384 bytes of shared memory ("shared pool","CREATE TABLE SHARED_POOL_DENEME...","sql area","qry_text : qcpisqt")
hatasında aldığında share pool ayarlamak yerine yada shared pool alanının yeterli oldugunu kodda hata olduğunu düşünüyor iseniz.
alter system flush shared pool
diyip reallocate edebilirsiniz.
ORA-04031: unable to allocate NNNNNN bytes of shared memory While Taking RMAN Backup.
Bu hatanın sebebi yeterli LARGE_POOL_SIZE olmamasıdır. Bu alanı arttırmnın gerekecektir. Bu alanın ne kadar olduğunu görmek için
SQL> show parameter large
NAME TYPE VALUE
------------------------------------ -----------
large_pool_size big integer 0
burada değeri 0 görüyoruz bunun sebebi daha önceden belirlememiş olmamız. Sistemimizin özellikleri, RAM miktarımız ,databasede yapılan işlemler vs.. 'e göre kendimiz bir değer verebiliriz.
SQL> ALTER SYSTEM set LARGE_POOL_SIZE = 20 M;
Sistem dei■tirildi.
SQL> show parameter large
NAME TYPE VALUE
------------------------------------ ----------- -------------
large_pool_size big integer 20M
burada 20MB değerini görüyoruz ben burada deneme amaçlı olarak sallama bir değer verdim.
Unix makinada ram miktarınızı görmek için
prtconf |grep Mem
Memory Size: 255232 MB
Good Memory Size: 255232 MB
not : HDD gibi RAM makinada :)))
ALTER SYSTEM set SHARED_POOL_SIZE = 20m;
Bunuda arttırmanız da fayda var.
ORA-04031: unable to allocate 127384 bytes of shared memory ("shared pool","CREATE TABLE SHARED_POOL_DENEME...","sql area","qry_text : qcpisqt")
hatasında aldığında share pool ayarlamak yerine yada shared pool alanının yeterli oldugunu kodda hata olduğunu düşünüyor iseniz.
alter system flush shared pool
diyip reallocate edebilirsiniz.
Friday, June 26, 2009
BLOCK CHANGE TRACKING
BLOCK CHANGE TRACKING (BCT)database'deki değişkliklerin yapıldığı block'ları tutan dosyadır. RMAN ile incremantal (artalan) yedekleme işlemi yaparken yapılan değilişliklerin hangi blocklarda yada nerelerde olduğunu tespit etmek için BTC dosyasına bakıyor. Bunun bize sağladığı avantaj ise bütün verileri tek tek tarayarak zaman kaybetmekten ise buradan bakıp ilgili blockları yedeklemek.
Bu özelliğin aktif olup olmadığını görmek için aşağıdaki sorguyu kullanabiliriz.
SELECT filename, status, BYTES
FROM v$block_change_tracking;
Enable yapmak için aşağıdaki komuyu kullanabiliriz. Bu işlemleri yapak için SYS user'ı ile bağlanmanız gerekiyor.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
--dosyayı ben belirliyorum.
USING FILE 'c:\oracle\product\flash_recovery_area\ORABASE\bctf01.log';
disable yapmak için ise
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
disable yaptığınızda dosyanız silinecektir.
dosyanın adını ve konumunu değiştirmek için MOUNT moda geçtikten sonra aşağıdaki işlemi yapmak gerekiyor.Aksi halde aşağıdaki hataları alırsınız.
ORA-01511: günlük/veri dosyalarını adlandırmada hata
ORA-19771: veritabanı açıkken değişiklik izleme dosyası yeniden adlandırılamaz.
ALTER DATABASE RENAME FILE
'c:\oracle\product\flash_recovery_area\ORABASE\bctf01.log'
TO 'c:\oracle\product\flash_recovery_area\ORABASE\new_name.log';
Eğer siz derseniz benim database'im kritik öyle canım istedikce Mount moda alamam. Ve bu dosyanın (bctf01.log) konumunu ve adını değiştirmek istiyorum o zaman önce disable yap sonra enable yaparkende yeni FILENAME ver.
BCT yi aktif duruma getirip sistemdeki değişiklikleri takip ediyor ve belirlediğimiz dosyaya(bctf01.log) kaydediyoruz. Sonra belirli sebeblerden pasif (enable) yapıp sonra tekrar aktif yaparsanız belirlediğimiz dosya yeniden oluşturulacaktır. İçerisi boşalacaktır.
readonly tablespace'de RMAN ile incremantal backup alırken BLOCK CHANGE TRACKING i kullanmaz. Readyonly bir yapıda zaten bir değişiklik olmayacağı için BCT yi kullanmak performans kaybına neden olacaktır.
kaynak : http://www.oracle.com/technology/oramag/oracle/04-nov/o64rman.html
Bu özelliğin aktif olup olmadığını görmek için aşağıdaki sorguyu kullanabiliriz.
SELECT filename, status, BYTES
FROM v$block_change_tracking;
Enable yapmak için aşağıdaki komuyu kullanabiliriz. Bu işlemleri yapak için SYS user'ı ile bağlanmanız gerekiyor.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
--dosyayı ben belirliyorum.
USING FILE 'c:\oracle\product\flash_recovery_area\ORABASE\bctf01.log';
disable yapmak için ise
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
disable yaptığınızda dosyanız silinecektir.
dosyanın adını ve konumunu değiştirmek için MOUNT moda geçtikten sonra aşağıdaki işlemi yapmak gerekiyor.Aksi halde aşağıdaki hataları alırsınız.
ORA-01511: günlük/veri dosyalarını adlandırmada hata
ORA-19771: veritabanı açıkken değişiklik izleme dosyası yeniden adlandırılamaz.
ALTER DATABASE RENAME FILE
'c:\oracle\product\flash_recovery_area\ORABASE\bctf01.log'
TO 'c:\oracle\product\flash_recovery_area\ORABASE\new_name.log';
Eğer siz derseniz benim database'im kritik öyle canım istedikce Mount moda alamam. Ve bu dosyanın (bctf01.log) konumunu ve adını değiştirmek istiyorum o zaman önce disable yap sonra enable yaparkende yeni FILENAME ver.
BCT yi aktif duruma getirip sistemdeki değişiklikleri takip ediyor ve belirlediğimiz dosyaya(bctf01.log) kaydediyoruz. Sonra belirli sebeblerden pasif (enable) yapıp sonra tekrar aktif yaparsanız belirlediğimiz dosya yeniden oluşturulacaktır. İçerisi boşalacaktır.
readonly tablespace'de RMAN ile incremantal backup alırken BLOCK CHANGE TRACKING i kullanmaz. Readyonly bir yapıda zaten bir değişiklik olmayacağı için BCT yi kullanmak performans kaybına neden olacaktır.
kaynak : http://www.oracle.com/technology/oramag/oracle/04-nov/o64rman.html
BOZUK BLOCK'LARIN BELİRLENMESİ
Database'de bozuk olan block'ların belirlemek için
select * from V$DATABASE_BLOCK_CORRUPTION
sorgusunu kullanabiliriz.
örneğin bir tablo yaratalım ve içerisini dolduralım.
--boş tablomuzu yaratalım
create table bozuk_deneme as select * from user_objects where 1=3
--ekleme işlemini yapalım.
insert into bozuk_deneme select * from user_objects
select * from bozuk_deneme;
bozuk bir block'ta olan tabloya erişmeye çalışdığımızda aşağıdaki hatayı alırız.
ORA-01578: ORACLE data block corrupted (file # 6, block # 256)
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/orcl/bozuk_dosya.dbf’
aklımıza ilk gelen durum burada RMAN ile bağlanarak aşağıdaki sorguyu çalıştırmaktır.
BLOCKRECOVER DATAFILE 6 BLOCK 256;
eger bunun ile bir çözum bulamaz isek datafileden dönme yapılmalıdır. Ilgili datafile recovery yapılabilir.
--arkamızda tablo bırakmalım ortalık tablo ile dolmasın.
drop table bozuk_deneme
kaynak :http://www.sc.ehu.es/siwebso/KZCC/Oracle_10g_Documentacion/server.101/b10734/rcmrecov.htm#1006579
select * from V$DATABASE_BLOCK_CORRUPTION
sorgusunu kullanabiliriz.
örneğin bir tablo yaratalım ve içerisini dolduralım.
--boş tablomuzu yaratalım
create table bozuk_deneme as select * from user_objects where 1=3
--ekleme işlemini yapalım.
insert into bozuk_deneme select * from user_objects
select * from bozuk_deneme;
bozuk bir block'ta olan tabloya erişmeye çalışdığımızda aşağıdaki hatayı alırız.
ORA-01578: ORACLE data block corrupted (file # 6, block # 256)
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/orcl/bozuk_dosya.dbf’
aklımıza ilk gelen durum burada RMAN ile bağlanarak aşağıdaki sorguyu çalıştırmaktır.
BLOCKRECOVER DATAFILE 6 BLOCK 256;
eger bunun ile bir çözum bulamaz isek datafileden dönme yapılmalıdır. Ilgili datafile recovery yapılabilir.
--arkamızda tablo bırakmalım ortalık tablo ile dolmasın.
drop table bozuk_deneme
kaynak :http://www.sc.ehu.es/siwebso/KZCC/Oracle_10g_Documentacion/server.101/b10734/rcmrecov.htm#1006579
Subscribe to:
Posts (Atom)
