Memperbaiki halaman yang tidak konsisten dalam database

Kami memiliki SQL 2000 DB. Server macet karena kegagalan susunan raid. Sekarang ketika kita menjalankan DBCC CHECKDB, kita mendapatkan kesalahan bahwa ada 27 kesalahan konsistensi dalam 9 halaman.

Ketika kami menjalankan PAGE DBCC di halaman ini, kami mendapatkan ini:

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

Karena indeks yang ditunjukkan adalah non-cluster dan dibuat oleh constarint unik yang mencakup 2 kolom, kami mencoba menjatuhkan dan membuat ulang indeks. Ini menghasilkan kesalahan berikut:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

Namun berjalan

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

mengembalikan 0 baris.

Inilah yang kami rencanakan untuk dilakukan:

Kembalikan salinan crash DB dari server dan jalankan DBCC CHECKDB
Jika itu kembali bersih, lalu kembalikan lagi tanpa pemulihan
Terapkan semua cadangan TLOG yang mendasarinya
Hentikan aplikasi produksi, ambil cadangan log ekor, dan terapkan juga
Jatuhkan prod DB dan ganti nama DB yang baru dipulihkan untuk membuatnya prod
Mulai aplikasi prod

Bisakah seseorang tolong melubangi pendekatan ini? Mungkin, menyarankan pendekatan yang berbeda? Yang kami butuhkan adalah downtime minimum.

SQL 2000 DB Ukuran 94 GB Tabel yang memiliki halaman rusak memiliki 460 Juta + baris data

Terima kasih untuk bantuannya.

Raj

sql-server dbcc

Saya suka pendekatan Anda. Masuk akal bagi saya. Mungkin menyimpan database yang rusak di samping, sebagai asuransi ...

— user24161

Juga, ketika segalanya beres, rencanakan peningkatan 2008 atau 2008 Anda :-)

— user24161

(yaitu, peningkatan 2005 atau 2008)

— user24161

+1 karena memiliki rencana pemulihan yang valid dan sangat cocok

— Andrew

Jawaban:

Solusi pemulihan Anda adalah cara buku teks untuk melanjutkan. Dengan asumsi Anda memiliki cadangan yang sesuai dan asalkan Anda dapat membuat cadangan log transaksi untuk database yang korup, maka strategi Anda adalah buku teks yang harus diimplementasikan.

Namun sebelum melanjutkan, apakah Anda sudah mempertimbangkan kemungkinan untuk membuat ulang hanya tabel yang terpengaruh?

Kadang-kadang Anda bisa lolos dengan membuat salinan persis dari tabel yang terpengaruh dengan melakukan a

select *
into NewTableFromOld
from DamagedTable

Kemudian cukup jatuhkan / tukar tabel yang rusak dengan yang baru, ingat untuk menambahkan batasan dan indeks yang sesuai.

— John Sansom
sumber

Terima kasih atas tanggapannya. Pendekatan Anda terlihat bagus, tetapi masalahnya adalah, mengingat tabel tersebut memiliki 461 juta baris data, apa dampaknya terhadap produksi ketika saya melakukan pemilihan *? Bukankah itu memerlukan kunci dan tekan kinerja?

Tidak jika Anda menggunakan petunjuk dengan (nolock), no. Namun, Anda mungkin ingin memvalidasi bahwa tidak ada yang berubah antara tabel sumber dan target saat Anda mengambil salinannya. Ini kemungkinan akan diperlukan selama pembuatan tabel jika Anda tidak menghentikan aplikasi dari membuat perubahan. Akan ada overhead kinerja disk dalam operasi semacam itu.

— John Sansom

Secara pribadi saya akan mencoba pendekatan ini terlebih dahulu, Anda dapat melakukannya dengan opsi nolock untuk pengujian, Anda dapat memeriksa waktu yang diperlukan juga. Jika berfungsi sebagaimana mestinya, saya kemudian akan menempatkan db dalam mode pengguna tunggal saat melakukannya lagi, untuk memastikan bahwa tidak ada perubahan yang terjadi saat proses sedang berjalan. Downtime akan jauh lebih pendek selama pendekatan ini, jika berhasil.

— Botak

Jika Anda akan melakukan ini, saya akan merekomendasikan membuat tabel terlebih dahulu (dengan membuat skrip dari tabel asli). Kemudian gunakan "INSERT INTO newTable SELECT" vs "SELECT INTO". Anda dapat mengalami masalah kinerja dengan "SELECT INTO".

— SQL3D

Saya akan mencoba membengkokkan data ke file pertama dan kemudian massal kembali ke tabel baru. SELECT INTO tidak sesuai (IMO) untuk jumlah catatan itu ...

— m4rty
sumber