cara memeriksa Database konsisten setelah pemulihan tidak lengkap

Anda dapat memulihkan database dari cadangan dan menerapkan banyak arsip agar konsisten. Sekarang  Anda ingin memastikan log penyetelan ulang terbuka berjalan dengan baik.
Berikut ini cara memeriksa konsistensi Database setelah pemulihan tidak lengkap

Pernyataan di bawah ini menyetel format tanggal ke formulir yang diperluas karena kami akan memerlukan ini berkali-kali  dalam analisis kami

SQL> mengubah set sesi nls_date_format='DD-MON-YYYY HH24:MI:SS';

Periksa 1

Tujuan:Memverifikasi bahwa file data dipulihkan ke titik waktu yang diinginkan (PIT) dan konsisten (FUZZY=NO)
Meminta status saat ini dan PIT (Titik waktu hingga waktu file data telah dipulihkan) file data dengan membaca header file data langsung dari file data fisik:

SQL> pilih fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) dari grup v$datafile_header berdasarkan fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;

• Pastikan bahwa checkpoint_time / checkpoint_change# sesuai dengan yang Anda inginkan SAMPAI WAKTU/SCN. Jika tidak, pulihkan database lebih lanjut jika Anda memiliki lebih banyak arsip log yang tersedia.
• Jika FUZZY=YES untuk beberapa file data, berarti diperlukan lebih banyak pemulihan. Jika tidak ada lagi arsip log yang tersedia, identifikasi file data tersebut dan tentukan apakah kami dapat membuatnya offline karena kami akan kehilangan data dalam file data tersebut. Jika file data milik SYSTEM atau UNDO tablespace, kita dapat / HARUS tidak membawa file data tersebut secara offline tanpa analisis yang tepat. Silakan berkonsultasi dengan Dukungan Oracle untuk tindakan lebih lanjut.

SQL> pilih file#, substr(nama, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# dari v$datafile_header where fuzzy='YES';

Terkadang, jika nama tablespace tidak menunjukkannya sebagai UNDO tablespace, jika kita melihat nilai bukan nol di kolom UNDO_OPT_CURRENT_CHANGE#, ini menunjukkan bahwa file data berisi segmen undo.

Untuk membuat file data offline :

SQL> mengubah database file data offline;

Pemeriksaan 1 dapat dianggap Lulus ketika :
+ Diverifikasi bahwa semua file data telah dipulihkan hingga titik waktu yang diinginkan.
+ Fuzzy=NO untuk SYSTEM, UNDO dan semua file data yang dimaksud. Untuk file data dengan Fuzzy=YES, pulihkan lebih lanjut atau OFFLINE jika tidak ada arsip log lebih lanjut yang tersedia.

Periksa 2

Tujuan:Pastikan file dengan status=RECOVER tidak OFFLINE secara tidak sengaja

SQL> pilih status, diaktifkan, hitung(*) dari v$datafile grup berdasarkan status, diaktifkan;STATUS  DIAKTIFKAN      COUNT(*)------- ---------- --- -------SYSTEM  DINONAKTIFKAN            1ONLINE  ​​BACA TULIS         1114PEMULIHAN DINONAKTIFKAN           2

Jika file dalam status RECOVER, verifikasi apakah OFFLINE :

SQL> pilih file#, substr(nama, 1, 50), status, kesalahan, pulihkan dari v$datafile_header;

Jika Anda ingin data untuk file-file ini dapat diakses, maka bawa ONLINE :

SQL> mengubah database datafile ONLINE;

Jika sebuah file tetap offline pada saat OPEN RESETLOGS, datafile tidak dapat dibawa kembali online lagi dalam database OPENED yang sama.
Cek 2 dapat dianggap Lulus ketika:
a) Semua file data yang dimaksud adalah tidak OFFLINE

Periksa 3

Tujuan:Pemeriksaan Fuzzy Tambahan (Pemeriksaan Fuzzy Absolut)

Kadang-kadang, dimungkinkan untuk melihat Fuzzy=NO dan checkpoint_change# yang sama untuk semua file data yang dimaksud; masih beberapa file data mungkin kabur dan OPEN RESETLOGS akan mengembalikan kesalahan, mis.

SQL> pilih fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, restore, checkpoint_change#, checkpoint_time;FUZ STATUS  ERROR         REC CHECKPOINT_CHANGE#      CHECKPOINT_ (*)--------- --------------- ------------------------- - ------------------- ----------TIDAK ONLINE                             5375858580 31-OCT-2011 23:10:14         7SQL> ALTER DATABASE BUKA RESETLOGS;ORA -01194:file 14 membutuhkan lebih banyak pemulihan agar konsistenORA-01110:file data 3:'/u01/app/Oracle/oradata/TEST/undotbs02.dbf'Oleh karena itu, kita harus melakukan pemeriksaan fuzzy tambahan yang dikenal sebagai Pemeriksaan Fuzzy Absolut: 
SQL> pilih hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN dari x$kcvfh dimana fhafs!=0;
 

 Catatan:Kolom Min_PIT_SCN akan mengembalikan nilai yang sama bahkan untuk beberapa baris karena kami telah menerapkan fungsi ANALYTICAL “MAX() OVER ()” di atasnya.
 

 Permintaan di atas menunjukkan bahwa pemulihan harus dilakukan setidaknya SCN 5311524 untuk membuat file data konsisten dan siap untuk DIBUKA. Karena checkpoint_change# lebih kecil dari Min_PIT_SCN, file data akan meminta lebih banyak pemulihan.
 

 Pemeriksaan 3 dapat dianggap Lulus ketika,
a) Tidak ada baris yang dipilih dari kueri di atas (yaitu Min_PIT_SCN adalah 0 (Nol) untuk semua file data)
b) Min_PIT_SCN dikembalikan kurang dari Checkpoint_Change#
 

 Periksa 4:Log Arsip Diperlukan 
 

 Minta file kontrol untuk menemukan log arsip terbaru yang diperlukan untuk pemulihan. Katakanlah pencadangan selesai pada 31-AUG-2011 23:20:14:
 
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME DARI V$ARCHIVED_LOG
WHERE '31 -AUG-11 23:20:14' ANTARA FIRST_TIME DAN NEXT_TIME;
 

 Jika kueri di atas tidak mengembalikan baris apa pun, mungkin informasi tersebut telah keluar dari file kontrol – jalankan kueri berikut terhadap v$log_history.
 
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> pilih a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
dari V$ LOG_HISTORY a
dimana FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME 
Urutan# yang dikembalikan oleh kueri di atas adalah urutan log saat ini pada saat pencadangan berakhir - katakanlah 530 utas 1.
 

 Untuk penggunaan pemulihan minimum:(Urutan# seperti yang dikembalikan +1 )
 
RMAN> RUN
{
SET SAMPAI SEQUENCE 531 THREAD 1;
PEMULIHKAN DATABASE;
}
 

 Jika ini adalah implementasi RAC, gunakan SQL ini sebagai gantinya untuk menanyakan file kontrol:
 
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' ANTARA FIRST_TIME DAN NEXT_TIME;
 

 Untuk pemulihan minimum, gunakan urutan log dan utas yang memiliki NEXT_CHANGE# terendah yang dikembalikan oleh kueri di atas.
 

 Pemeriksaan 4 dapat dianggap LULUS jika:
 

 Semua arsip log dari waktu pencadangan hingga akhir pencadangan tersedia untuk digunakan selama pemulihan
 

 Centang 5 (Setelah berhasil BUKA RESETLOGS) : 
 

 Pantau alert.log untuk waktu aktivitas OPEN RESETLOGS. Anda mungkin melihat beberapa pesan seperti di bawah ini selama pemeriksaan kamus:
 

 Membuat file OFFLINE 'MISSING00004' di controlfile
 

 jika Anda menemukan file tersebut, coba ganti namanya. Jika tidak, kami dapat menonaktifkan file data atau menghapus tablespace terkait:
 
SQL> pilih file#, status, diaktifkan, substr(nama, 1, 50) dari v$datafile di mana nama seperti '%MISSING%';FILE#    STATUS  ENABLED    SUBSTR(NAME,1,50)---- ---- ------- ---------- ----------------------------- ---------------------       4 OFFLINE DISABLED   //MISSING000       7 OFFLINE DISABLED   //MISSING000SQL> ubah database datafile 4 online;ubah database datafile 4 online*ERROR pada baris 1:ORA-01157:tidak dapat mengidentifikasi/mengunci file data 4 - lihat DBWR trace fileORA-01111:nama untuk file data 4 tidak diketahui - ganti nama menjadi file yang benarORA-01110:file data 4:'//dbs/MISSING00004'SQL> ubah nama file database 'MISSING00004' menjadi '//users01.dbf';Database diubah.SQL> ubah nama file database 'MISSING00007' menjadi '//users02.dbf';Database diubah.SQL> pilih tablespace_name, status from dba_tablespaces where tablespace_name in (pilih tablespace_name dari dba_data_files where file_id in (4, 7)); TABLESPACE_NAME             STATUS------------------ ---------- -- --------- PENGGUNA                        OFFLINESQL> ALTER TABLESPACE PENGGUNA ONLINE;Tabel diubah.
 

 Semoga ini bisa membantu tentang cara memeriksa Database konsisten setelah pemulihan yang tidak lengkap. Harap berikan umpan balik 
 

 Juga Dibaca 
cara menemukan nomor urut arsip log di oracle
perintah pencadangan RMAN
perintah pencadangan daftar RMAN
Cara memulihkan basis data menggunakan RMAN