Pemecahan masalah DBCC kesalahan 2570 dalam SQL Server 2005 dan versi

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 923247 - Melihat produk di mana artikel ini berlaku.
Perbesar semua | Perkecil semua

Pada Halaman ini

PENGENALAN

Artikel ini menjelaskan 2570, apa yang menyebabkan galat SQL Server kesalahan, dan bagaimana untuk menyelesaikan masalah.

INFORMASI LEBIH LANJUT

DATA_PURITY cek

Dalam SQL Server 2005, opsi baru, DATA_PURITY, telah ditambahkan ke perintah DBCC CHECKDB dan DBCC CHECKTABLE. Ketika Anda menjalankan DBCC CHECKDB atau DBCC CHECKTABLE perintah dengan opsi ini diaktifkan, perintah akan melakukan "data kemurnian" validasi pada setiap kolom nilai dalam semua baris Daftar Tabel atau Daftar Tabel dalam database. Pemeriksaan baru ini dilakukan untuk memastikan bahwa nilai-nilai yang disimpan di kolom berlaku (yaitu nilai-nilai yang tidak out-of-range untuk domain terkait dengan jenis data kolom). The sifat validasi dilakukan tergantung pada jenis data kolom. The mengikuti non-daftar yang lengkap memberikan beberapa contoh:
Perkecil tabel iniPerbesar tabel ini
tipe data kolomJenis validasi data yang dilakukan
Karakter UnicodePanjang data yang harus beberapa dari 2.
DateTimeBidang hari harus antara 1 Januari 1753 dan Desember 31 9999. Bidang waktu harus lebih awal daripada '11:59:59:999 PM'.
Nyata dan mengapungPeriksa keberadaan valid nilai-nilai titik mengambang seperti SNAN, QNAN, NINF, ND, PD, PINF.
Tidak semua tipe data diperiksa untuk validitas kolom data. Hanya orang-orang di mana dimungkinkan untuk memiliki nilai tersimpan yang cek keluar dari kisaran diperiksa. Sebagai contoh, tipe data tinyint memiliki jangkauan 0 melalui 255 berlaku dan disimpan dalam satu byte (yang hanya dapat menyimpan nilai-nilai dari 0 hingga 255), jadi memeriksa nilai ini tidak diperlukan.

Cek validasi kemurnian data tidak diaktifkan secara otomatis untuk semua database. Cek diaktifkan tergantung pada beberapa faktor-faktor:
  • Untuk database dibuat dalam SQL Server 2005 dan versi yang lebih baru, pemeriksaan ini diaktifkan secara asali dan tidak dapat dinonaktifkan, sehingga penggunaan opsi DATA_PURITY ketika mengeksekusi perintah DBCC CHECKDB atau DBCC CHECKTABLE tidak relevan.
  • Untuk database yang dibuat dalam versi sebelumnya dari SQL Server, seperti SQL Server 2000, SQL Server 7.0 dan versi upgrade ke SQL Server 2005, pemeriksaan ini tidak diaktifkan secara asali. Dalam rangka untuk pemeriksaan harus dilakukan, Anda harus menentukan pilihan DATA_PURITY di DBCC CHECKDB atau DBCC CHECKTABLE perintah. Hal ini dapat mengakibatkan dua hal:
    • Perintah DBCC selesai dan laporan bahwa database bersih, termasuk semua data kemurnian cek. Fakta ini tercatat dalam database header. Berikutnya DBCC CHECKDB atau DBCC CHECKTABLE perintah semua eksekusi akan melihat informasi ini dan akan secara otomatis menjalankan data kemurnian cek, seperti yang akan terjadi untuk database yang dibuat pada SQL Server 2005. Dalam kata lain, setelah database yang dikenal sebagai "bersih," pemeriksaan kemurnian data yang selalu dilakukan.
    • Perintah DBCC selesai tetapi laporan masalah tentang data inkonsistensi. Jika hal ini terjadi, Anda akan memiliki untuk membersihkan database untuk Hapus inkonsistensi dan kemudian mencoba untuk menjalankan perintah DBCC lagi. Anda akan harus menentukan pilihan DATA_PURITY untuk perintah DBCC sampai database ini dilaporkan menjadi bersih.
  • Jika opsi PHYSICAL_ONLY ditentukan ketika DBCC CHECKDB atau DBCC CHECKTABLE perintah dijalankan, cek kemurnian data tidak dilakukan.

GEJALA

Data yang tidak sah atau out of range mungkin telah disimpan dalam SQL Server database di versi sebelumnya untuk alasan berikut:
  • Data yang tidak sah telah hadir dalam sumber sewaktu menggunakan massal Masukkan metode, seperti utilitas bcp.
  • Data tidak sah melewati RPC acara panggilan yang dibuat ke SQL Server.
  • Potensial lain penyebab galat data fisik yang tersisa kolom nilai dalam keadaan yang tidak sah.
Jika Anda memiliki data yang tidak sah dalam Kolom Bertumpuk, Anda mungkin mengalami masalah tergantung pada jenis operasi yang dilakukan terhadap data yang tidak sah. Namun, dimungkinkan juga bahwa tidak ada masalah akan muncul, dan data yang tidak sah akan tidak ditemukan sampai Anda mengeksekusi perintah DBCC CHECKDB atau DBCC CHECKTABLE pada SQL Server 2005 dan versi yang lebih baru.

Beberapa gejala Anda mungkin melihat berkat adanya data yang tidak sah termasuk (namun tidak terbatas kepada):
  • pelanggaran akses atau jenis lain dari pengecualian sementara mengeksekusi query terhadap kolom yang terpengaruh.
  • Hasil yang tidak benar dikembalikan oleh query dijalankan terhadap kolom yang terpengaruh.
  • Kesalahan atau masalah ketika statistik sedang dibangun terhadap kolom yang terpengaruh.
  • Pesan galat seperti berikut:
    MSG 9100, Tingkat 23, negara bagian 2, baris 1 mungkin indeks korupsi terdeteksi. Menjalankan DBCC CHECKDB.

DATA_PURITY laporan masalah

Ketika Anda menjalankan perintah DBCC CHECKDB atau DBCC CHECKTABLE dengan DATA_PURITY pilihan diaktifkan (atau data kemurnian cek menjalankan secara otomatis), dan data yang tidak sah dalam Daftar Tabel Diperiksa oleh DBCC perintah, DBCC output meliputi tambahan pesan yang menunjukkan masalah dengan data. Beberapa contoh pesan galat yang menunjukkan data kemurnian masalah ditunjukkan di bawah ini:
DBCC hasil untuk "account_history".
MSG 2570, tingkat 16, negara bagian 2, garis jatuh berseri 1
Halaman (1:1073), slot 33 di objek ID 1977058079, indeks ID 0, partisi ID 129568478265344, alloc unit ID 129568478265344 (tipe "di baris data"). Kolom "account_name_japan" nilai adalah cek keluar dari jangkauan untuk tipe data "nvarchar". Update kolom ke nilai yang sesuai.
MSG 2570, tingkat 16, negara bagian 2, garis jatuh berseri 1
Halaman (1:1156), slot 120 dalam objek ID 1977058079, indeks ID 0, partisi ID 129568478265344, alloc unit ID 129568478265344 (ketik "Di baris data"). Kolom "account_name_japan" nilai cek keluar jangkauan untuk tipe data "nvarchar". Update kolom ke nilai yang sesuai.
Ada adalah 153137 baris di 1080 halaman untuk objek "account_history".
CHECKDB yang ditemukan 0 alokasi kesalahan dan 338 konsistensi kesalahan dalam Daftar Tabel "account_history" (objek ID 1977058079).
CHECKDB ditemukan kesalahan 0 alokasi dan 338 konsistensi kesalahan dalam database 'BadUnicodeData'.
DBCC eksekusi selesai. Jika DBCC dicetak pesan galat, hubungi administrator sistem Anda.
DBCC hasil untuk 'table1'.
MSG 2570, tingkat 16, Negara bagian 3, garis jatuh berseri 1
Halaman (1:154), slot 0 dalam obyek ID 2073058421, indeks ID 0, partisi ID 72057594038321152, alloc unit ID 72057594042318848 (tipe "Di baris data"). Kolom "col2" nilai adalah cek keluar dari jangkauan untuk tipe data "nyata". Update kolom ke nilai yang sesuai.
Ada 4 baris dalam 2 halaman untuk objek "table1".
CHECKDB ditemukan kesalahan alokasi 0 dan 1 konsistensi kesalahan dalam Daftar Tabel 'table1' (objek ID 2073058421).
CHECKDB ditemukan kesalahan alokasi 0 dan konsistensi 1 kesalahan dalam database 'realdata'. DBCC eksekusi selesai. Jika DBCC dicetak kesalahan pesan, hubungi administrator sistem Anda.
DBCC hasil untuk 'table2'.
MSG 2570, tingkat 16, Negara bagian 3, garis jatuh berseri 1
Halaman (1:155), slot 0 dalam obyek ID 2105058535, indeks ID 0, partisi ID 72057594038452224, alloc unit ID 72057594042449920 (tipe "Di baris data"). Kolom "col2" nilai adalah cek keluar dari jangkauan untuk tipe data "desimal". Update kolom ke nilai yang sesuai.
Ada 4 baris di halaman 1 untuk objek "table2".
CHECKDB ditemukan kesalahan alokasi 0 dan 1 konsistensi kesalahan dalam Daftar Tabel 'table2' (objek ID 2105058535).
CHECKDB ditemukan kesalahan alokasi 0 dan konsistensi 1 kesalahan dalam database 'realdata'. DBCC eksekusi selesai. Jika DBCC dicetak kesalahan pesan, hubungi administrator sistem Anda.
DBCC hasil untuk 'table3'.
MSG 2570, tingkat 16, Negara bagian 3, garis jatuh berseri 1
Halaman (1:157), slot 0 dalam obyek ID 2121058592, indeks ID 0, partisi ID 72057594038517760, alloc unit ID 72057594042515456 (tipe "Di baris data"). Kolom "col2" nilai adalah cek keluar dari jangkauan untuk tipe data "datetime". Update kolom ke nilai yang sesuai.
Ada 3 baris di halaman 1 untuk objek "table3".
CHECKDB ditemukan kesalahan alokasi 0 dan 1 konsistensi kesalahan dalam Daftar Tabel 'table3' (objek ID 2121058592).
CHECKDB ditemukan kesalahan alokasi 0 dan konsistensi 1 kesalahan dalam database 'realdata'. DBCC eksekusi selesai. Jika DBCC dicetak kesalahan pesan, hubungi administrator sistem Anda.
Untuk setiap baris yang berisi nilai kolom tidak sah, kesalahan 2570 dihasilkan.

Memperbaiki masalah kemurnian Data

2570 Kesalahan yang tidak dapat diperbaiki dengan menggunakan salah satu perbaikan DBCC pilihan. Hal ini karena itu mustahil untuk DBCC untuk menentukan nilai apa harus digunakan untuk menggantikan nilai kolom tidak sah. Dengan demikian, nilai kolom harus diperbarui secara manual.

Untuk melakukan manual update, Anda harus menemukan baris yang memiliki masalah. Ada dua cara untuk mencapai hal ini.
  • Mengeksekusi Daftar Tabel pertanyaan yang berisi nilai tidak sah untuk menemukan baris yang berisi nilai-nilai yang tidak sah.
  • Gunakan informasi dari kesalahan 2570 untuk mengidentifikasi baris yang memiliki nilai tidak sah.
Kita akan membahas kedua metode ini secara rinci di bawah ini, menggunakan contoh untuk menemukan baris yang memiliki data yang tidak sah.

Setelah Anda menemukan berturut-turut benar, keputusan harus dibuat pada nilai baru yang akan digunakan untuk mengganti ada data yang tidak sah. Keputusan ini telah dibuat sangat hati-hati berdasarkan rentang nilai-nilai yang bekerja untuk aplikasi seperti apa akal logis untuk baris tertentu data. Pilihan-pilihan yang Anda miliki adalah:
  • Jika Anda tahu apa nilai harus, set ke yang nilai tertentu.
  • Set ke nilai asali yang dapat diterima.
  • Tetapkan nilai kolom ke NULL.
  • Tetapkan nilai kolom ke nilai maksimum atau minimum untuk data jenis kolom.
  • Jika Anda merasa baris tertentu yang tidak digunakan tanpa nilai yang valid untuk kolom, Anda dapat menghapus baris yang sama sekali.

Mencari baris dengan nilai-nilai yang tidak sah menggunakan T-SQL query

Jenis pertanyaan yang Anda butuhkan untuk menjalankan untuk menemukan baris yang nilai-nilai tidak sah tergantung pada jenis data kolom yang melaporkan masalah. Jika Anda melihat pesan kesalahan 2570, Anda akan melihat dua potongan penting informasi yang akan membantu Anda dengan ini. Dalam contoh berikut, kolom "account_name_japan" nilai adalah cek keluar dari jangkauan untuk tipe data "nvarchar." Kita dapat dengan mudah mengidentifikasi kolom yang memiliki masalah serta jenis data kolom terlibat. Jadi, sekali Anda mengetahui data jenis dan kolom terlibat, Anda dapat merumuskan query untuk menemukan baris yang berisi nilai-nilai tidak sah untuk itu kolom, memilih kolom yang diperlukan untuk mengidentifikasi baris (sebagai predicates di klausul WHERE) untuk setiap lebih lanjut memperbarui atau menghapus.

tipe data Unicode:
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan 
FROM account_history
WHERE DATALENGTH(account_name_japan) % 2 != 0

Mengambang tipe data:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB output

SELECT col1, col2 FROM table1
WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

tipe data nyata:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB output

SELECT col1, col2 FROM testReal 
WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38)) 
ORDER BY col1; -- checks for real out of range
Desimal dan numerik tipe data:
SELECT col1 FROM table2
WHERE col2 > 9999999999.99999 
OR col1 < -9999999999.99999
Perlu diingat bahwa Anda akan perlu untuk menyesuaikan nilai-nilai yang didasarkan pada presisi dan skala yang sudah Anda tetapkan kolom desimal atau angka. Dalam contoh di atas, kolom didefinisikan sebagai col2 decimal(15,5).

Tanggal waktu data jenis:
Anda akan perlu untuk melaksanakan dua pertanyaan yang berbeda untuk mengidentifikasi baris yang berisi nilai-nilai tidak sah untuk kolom tanggal waktu.
SELECT col1 FROM table3
WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'

SELECT col1 FROM table3 WHERE
((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333)) 
> 25919999

Mencari baris dengan nilai tidak sah menggunakan lokasi fisik:

Anda dapat menggunakan metode ini jika Anda tidak dapat menemukan baris bunga metode T-SQL yang dibahas di atas. Dalam pesan kesalahan 2570, lokasi fisik baris yang berisi nilai tidak sah dicetak. Untuk contoh, melihat pesan berikut:
Halaman (1:157), Slot 0 dalam obyek ID 2121058592, indeks ID 0, partisi ID 72057594038517760, alloc unit ID 72057594042515456 (tipe "di baris data"). Nilai kolom "col2" cek keluar dari jangkauan untuk tipe data "datetime". Kolom update untuk hukum nilai.
Dalam pesan ini, Anda akan melihat informasi: Halaman (1:157), Slot 0. Ini adalah informasi yang Anda butuhkan untuk mengidentifikasi baris. FileId adalah 1, PageInFile 157, dan SlotId 0. Setelah Anda memiliki informasi ini, Anda akan perlu menjalankan perintah, sebagai berikut:
DBCC TRACEON ( 3604 )
DBCC PAGE ( realdata , 1 , 157 , 3 )
Perintah ini akan mencetak seluruh isi halaman. Parameter untuk Perintah DBCC halaman adalah:
  • nama database
  • FileId
  • PageInFile
  • pilihan cetak
Setelah Anda menjalankan perintah ini, Anda akan melihat output yang berisi informasi yang mirip dengan format berikut:
Slot 0 Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000
		  ffffffff ffffffff ?................ 00000010:
		  0200fc???????????????????????????????... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000
		  0ba96301 f8970000 ?..........c..... 00000010:
		  0200fc???????????????????????????????... Slot 1 Column 0 Offset 0x4 Length 4
		  col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2
		  Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =
		  NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301
		  f8970000 ?..........c..... 00000010: 0200fc???????????????????????????????...
		  Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length
		  8 col2 = Jul 8 2006 9:34PM 
Dalam output ini Anda dapat dengan jelas melihat nilai-nilai kolom untuk baris menarik bagi Anda. Dalam kasus ini, Anda perlu baris yang disimpan di slot 0 halaman. Dari pesan galat, Anda tahu col2 itu adalah satu dengan masalah. Sehingga Anda dapat membawa nilai col1 untuk Slot 0 dan menggunakannya sebagai predikat dalam klausul WHERE pernyataan pembaruan Anda atau Hapus pernyataan.

Peringatan Kami menyarankan agar Anda menggunakan metode pertama (yaitu menggunakan T-SQL query untuk menemukan informasi yang diperlukan). Penggunaan halaman DBCC perintah hanya sebagai Last resort. Mengambil sangat hati-hati saat Anda menggunakan perintah ini dalam produksi lingkungan. Dianjurkan untuk memulihkan database produksi pada tes server, kemudian mendapatkan semua informasi yang diperlukan yang menggunakan DBCC halaman, dan kemudian melakukan pembaruan pada server produksi. Seperti biasa, pastikan untuk menjaga cadangan siap kalau-kalau sesuatu yang tidak beres dan Anda perlu untuk kembali ke sebuah kopi karbon sebelumnya database.

REFERENSI

Untuk informasi lebih lanjut tentang pernyataan DBCC CHECKDB, lihat Pengembang Microsoft berikut topik "DBCC CHECKDB (Transact-SQL)" situs web Network (MSDN):
http://msdn2.Microsoft.com/en-us/library/ms176064.aspx
Untuk informasi lebih lanjut tentang dikenal isu-isu dalam SQL Server 2000, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
900335FIX: Operasi pemulihan otomatis database SQL Server 2000 mungkin tidak berhasil jika index berisi tipe data MENGAMBANG atau tipe data yang nyata, dan tipe data ini berisi nilai NaN
Untuk informasi lebih lanjut tentang peristiwa-peristiwa RPC, lihat "Calling disimpan prosedur (OLE DB)" topik di situs Website MSDN berikut:
.aspx http://msdn2.Microsoft.com/en-us/library/aa198358 (SQL.80)
Untuk informasi lebih lanjut tentang jenis data, lihat "Calling disimpan prosedur (OLE DB)" topik di situs Website MSDN berikut:
http://msdn2.Microsoft.com/en-us/library/ms187752.aspx
Untuk informasi lebih lanjut tentang nilai titik mengambang Konvensi, kunjungi Intel Website berikut:
http://www.Intel.com/Design/pentiumii/Manuals/243191.htm
Microsoft menyediakan informasi kontak pihak ketiga untuk membantu Anda menemukan dukungan teknis. Informasi kontak ini dapat berubah tanpa pemberitahuan. Microsoft tidak menjamin ketepatan dari informasi kontak pihak ketiga ini.

Properti

ID Artikel: 923247 - Kajian Terakhir: 22 Maret 2012 - Revisi: 1.0
Berlaku bagi:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Express Edition with Advanced Services
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium-based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium-based Systems
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2008 Standard Edition for Small Business
Kata kunci: 
kbtshoot kbexpertiseadvanced kbsql2005engine kbinfo kbmt KB923247 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini:923247

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com