Memahami dan menganalisis-1018, -1019, dan-1022 Exchange database kesalahan

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

Pada Halaman ini

RINGKASAN

Artikel ini menyediakan informasi untuk membantu Anda memahami dan menganalisis kesalahan database Exchange-1019,-1018, dan-1022. Artikel ini menjelaskan perbedaan antara tiga kesalahan dan jenis masalah dalam database yang menyebabkan masing-masing dari kesalahan ini tiga harus dilaporkan.

INFORMASI LEBIH LANJUT

Exchange meliputi fungsi untuk mendeteksi tingkat file kerusakan halaman dalam database yang. Tiga kesalahan yang paling umum yang terkait dengan kerusakan tingkat file database pertukaran adalah sebagai berikut:
  • -1018 JET_errReadVerifyFailure
  • JET_errPageNotInitialized -1019
  • -1022 JET_errDiskIO
Berikut tiga tingkat kerusakan dapat terjadi di Exchange database:
  • Tingkat halaman (sistem berkas)
  • Tingkat database (JET database engine)
  • Level aplikasi (pertukaran informasi toko)
Utilitas Esefile.exe dapat mendeteksi kesalahan dalam database pada tingkat halaman. Utilitas Eseutil.exe dapat mendeteksi dan memperbaiki masalah pada tingkat halaman dan tingkat database. Utilitas Isinteg.exe mendeteksi dan perbaikan masalah di level aplikasi.

Kerusakan lebih rendah tingkat (tingkat halaman) hampir selalu mengakibatkan masalah di tingkat yang lebih tinggi (database atau aplikasi tingkat). Oleh karena itu, setelah Anda memperbaiki database dengan Eseutil, Anda hampir selalu perlu untuk menggunakan Isinteg sesudahnya.

Kerusakan pada tingkat database dan aplikasi terkait isu-isu dalam pertukaran kode atau program pihak ketiga yang mengintegrasikan dengan Exchange. Kerusakan pada halaman tingkat biasanya disebabkan oleh sopir, firmware, atau masalah perangkat keras, meskipun halaman-tingkat kerusakan mungkin juga disebabkan oleh masalah dalam pertukaran.

Anda hampir selalu mencari akar penyebab kesalahan-1018 dalam salah satu sistem yang mendasari Exchange tergantung pada, tidak dalam pertukaran kode itu sendiri. Ada beberapa pengecualian terhadap peraturan ini. Pengecualian untuk tanggal telah berkaitan dengan Exchange laporan kondisi-1018, bukan karena ASX menyebabkan kesalahan-1018. Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
237953Salah-1018 kesalahan kembali selama cadangan online
230215 Cadangan checksuming tidak dijalankan pada prosesor tunggal komputer
Meskipun sebagian besar kesalahan-1019 dan-1022 juga disebabkan oleh kesalahan dalam sistem yang mendasari, Anda tidak dapat mengesampingkan kemungkinan bahwa kesalahan-1019 dan-1022 mungkin terjadi karena kesalahan dalam pertukaran kode dengan cepat.

Kesalahan-1018 adalah kesalahan yang paling sering dilihat, yang menunjukkan bahwa Exchange database telah menderita kerusakan pada tingkat sistem file. Oleh karena itu, sebagian besar dari artikel ini berfokus pada kesalahan-1018.

Ada tiga cara mendasar bahwa data pada disk dapat menjadi rusak:
  • Data yang salah menulis untuk media penyimpanan.
  • Data ditulis ke tempat yang salah pada media penyimpanan.
  • Data rusak atau diubah setelah disimpan.
Meskipun sangat sulit untuk mencegah atau memperbaiki 100 persen dari semua kerusakan, relatif mudah untuk mendeteksi masalah yang telah terjadi. Exchange mendeteksi salah dan tempatnya data dalam file database dan laporan -1019 kesalahan atau kesalahan-1018. Jika file rusak parah dan bagian-bagian itu hilang sepenuhnya atau sebaliknya tidak dapat diakses ketika Exchange mencoba untuk membaca berkas, kesalahan-1022 dilaporkan.

Bagaimana Exchange menghitung checksum dan Database nomor halaman

Untuk memahami bagaimana mekanisme yang memicu kesalahan-1018 dan -1019 bekerja, Anda harus memahami bagaimana Exchange database menyimpan halaman data.

Tingkat terendah logis, Anda dapat melihat file database Exchange sebagai satu set dari 4-Kilobita (KB), nomor halaman di berurutan. Data dibaca dan ditulis untuk Exchange database satu halaman pada satu waktu.

Setiap halaman yang berisi data toko sendiri nomor halaman, bersama dengan checksum yang dihitung dari semua data pada halaman. Checksum nilai itu sendiri adalah satu-satunya bagian dari halaman yang tidak termasuk dalam perhitungan ini.

Checksum algoritma, termasuk algoritma checksum yang menggunakan Exchange, dipahami dengan baik dan relatif sederhana. Mereka dirancang sehingga kemungkinan bahwa checksum yang sama akan menghasilkan untuk setiap dua halaman yang berbeda rendah, bahkan jika perbedaan antara halaman adalah hanya satu bit.

Meskipun tes checksum cukup untuk menentukan apakah halaman telah berubah sejak itu ditulis, tes checksum ini tidak cukup untuk memastikan bahwa halaman di tempat yang tepat. Because of this, pertukaran prangko setiap halaman dengan nomor halaman sendiri serta checksum.

Dua 4-KB halaman pertama dalam database disediakan untuk database "header." Ketika database berhenti, Anda dapat menggunakan utilitas Eseutil /MH saklar untuk melihat header ini. Header berisi informasi identitas tentang database secara keseluruhan.

Setelah halaman dua header ini, semua halaman lain dalam database adalah data. Halaman data semua berbagi struktur umum. Setiap halaman memiliki header halaman sendiri, yang berisi informasi identitas tentang halaman tertentu, diikuti oleh data aktual.

Karena halaman data pertama dalam Exchange database terletak setelah header dua halaman pertama, fisik halaman 3 dalam database adalah logis Halaman 1. 2 adalah jumlah halaman logis fisik Halaman 4, dan seterusnya.

Angka-angka logis halaman dalam database peta langsung ke nomor halaman fisik dengan rumus sebagai berikut:
nomor halaman logis = nomor halaman fisik - 2
Karena struktur halaman yang logis dan fisik database file begitu erat terkait, Exchange dapat dengan mudah menentukan apakah setiap halaman logis di lokasi fisik yang benar dalam file.

Satu-satunya halaman dalam database yang checksum tidak dihitung adalah "halaman uninitialized." Berikut adalah serangkaian halaman yang dibuat ketika ukuran database diperpanjang untuk membuat ruang untuk lebih banyak data. Halaman uninitialized adalah salah satu yang memiliki checksum nol dan sejumlah halaman nol. Biasanya, setiap byte uninitialized halaman penuh dengan karakter 0x00.

Setelah halaman uninitialized digunakan untuk pertama kalinya, itu tidak kembali ke uninitialized negara, bahkan jika itu dikosongkan. Sebaliknya, bendera diatur pada halaman dikosongkan untuk menandai tersedia untuk digunakan kembali. Halaman masih membawa nomor halaman dan checksum, bahkan ketika itu kosong.

Exchange Server 2003 Paket Layanan 1 (SP1) berubah algoritma checksum dan format halaman yang digunakan. Juga, Exchange Server 2003 SP1 Memperkenalkan memperbaiki kode (ECC) algoritma untuk mendeteksi dan untuk secara otomatis memperbaiki kesalahan single-bit error.Untuk informasi lebih lanjut mengenai fungsi baru ini, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
867626Kesalahan baru memperbaiki kode disertakan di Exchange Server 2003 Paket Layanan 1

Apa yang menyebabkan kesalahan-1018

Exchange laporan kesalahan-1018 ketika halaman diinisialisasi di file database yang ditemukan dengan salah satu dari kondisi berikut:
  • Checksum yang disimpan pada halaman tidak cocok hasil recalculation checksum yang dilakukan saat halaman membaca.
  • Nomor halaman yang disimpan pada halaman tidak cocok nomor halaman yang harus pada halaman, diberikan halaman lokasi fisik di database file.
Exchange mungkin bertanggung jawab atas self-generating-1018 kesalahan jika pertukaran melakukan salah satu tindakan berikut:
  • Akan membuat halaman yang memiliki checksum salah.
  • Konstruksi halaman dengan benar, tetapi mengatakan sistem operasi untuk menulis halaman di lokasi yang salah.
Setelah administrator sistem pertemuan-1018 kesalahan, jika administrator menjalankan tes diagnostik keras terhadap server dan tes ini melaporkan tidak ada masalah, administrator mungkin menyimpulkan bahwa pertukaran harus bertanggung jawab untuk masalah karena hardware berlalu analisis awal.

Namun, dalam kasus setelah kasus, lebih penyelidikan oleh Microsoft atau perangkat keras vendor ditemukan halus masalah pada pengandar perangkat keras, firmware, atau perangkat yang benar-benar bertanggung jawab untuk merusak database file.

Tes diagnostik biasa mungkin tidak mendeteksi semua kesalahan sementara karena beberapa alasan. Isu-isu di firmware atau pengandar perangkat lunak mungkin jatuh di luar kemampuan program diagnostik. Tes diagnostik mungkin tidak dapat secara memadai mensimulasikan jangka panjang kali atau kompleks beban. Juga, penambahan diagnostik pemantauan atau debug penebangan mungkin mengubah sistem cukup untuk mencegah masalah muncul lagi.

Kesederhanaan dan stabilitas Exchange mekanisme yang menghasilkan checksum dan menulis halaman untuk database file adalah alasan lain yang probabilitas bahwa akar penyebab kesalahan-1018 adalah masalah Exchange rendah. Checksum dan halaman salah deteksi mekanisme sederhana, dapat diandalkan dan tetap pada dasarnya sama sejak pertukaran pertama rilis, kecuali untuk perubahan kecil untuk beradaptasi dengan perubahan format Halaman database antara database versi.

Untuk menjelaskan lebih lanjut, checksum dihasilkan untuk halaman yang akan ditulis ke disk setelah semua data yang telah ditulis ke halaman, termasuk halaman nomor itu sendiri. Setelah pertukaran menambahkan checksum ke halaman, pertukaran memerintahkan sistem operasi Microsoft Windows untuk menulis halaman ke disk dengan menggunakan standar, diterbitkan Windows aplikasi pemrograman antarmuka (api).

Checksum mungkin dihasilkan dengan benar untuk halaman, namun kemudian halaman mungkin ditulis ke lokasi yang salah pada hard disk. Ini mungkin disebabkan oleh kesalahan memori sementara, seperti "sedikit flip." Misalnya, pertukaran akan membuat versi baru dari halaman 70. Halaman itu sendiri tidak mengalami kesalahan, tetapi salinan nomor halaman yang digunakan oleh disk controller atau oleh sistem operasi secara acak berubah. Masalah ini dapat terjadi jika 70 (biner 100110) telah berubah untuk 6 (biner 000110) oleh sel memori tidak stabil. Halaman checksum masih benar, tapi lokasi halaman dalam database sekarang salah. Exchange laporan kesalahan-1018 untuk halaman ketika mendeteksi bahwa nomor halaman logis tidak cocok lokasi fisik halaman. Jenis lain halaman penomoran (disebabkan oleh Exchange) kesalahan mungkin terjadi jika pertukaran menulis nomor halaman salah pada halaman itu sendiri. Tapi ini menyebabkan kesalahan lain, tidak-1018 kesalahan. Jika pertukaran menulis 71 pada halaman 70, dan kemudian Apakah checksum pada halaman dengan benar, halaman ditulis ke lokasi 71 dan melewati kedua halaman nomor dan checksum tes.

Sering, satu-1018 kesalahan yang dilaporkan dalam database Exchange tidak menyebabkan database untuk menghentikan atau mengakibatkan gejala lain dari kehadiran-1018 kesalahan itu sendiri. Halaman mungkin dalam folder yang jarang diakses (misalnya, dikirim atau item dihapus map), atau dalam lampiran yang jarang dibuka, atau bahkan kosong.

Meskipun kesalahan tunggal di-1018 tidak akan menyebabkan kehilangan data yang luas,-1018 kesalahan yang masih penyebab untuk perhatian karena kesalahan-1018 bukti bahwa sistem penyimpanan Anda gagal untuk dapat dipercaya toko atau mengambil data setidaknya sekali. Walaupun-1018 kesalahan mungkin masalah sementara yang tidak akan pernah terjadi lagi, ianya lebih mungkin bahwa kesalahan ini adalah peringatan dini isu yang akan menjadi semakin buruk. Bahkan jika kesalahan pertama kali-1018 pada halaman kosong dalam database, Anda tidak dapat mengetahui halaman yang mungkin rusak berikutnya. Jika tabel global kritis rusak, database mungkin menjadi unstartable, dan database perbaikan mungkin tidak berhasil atau hanya sebagian sukses.

Setelah kesalahan-1018 login, Anda harus mempertimbangkan dan berencana untuk kemungkinan kegagalan dekat atau lebih acak kerusakan database sampai Anda menemukan dan menghilangkan akar penyebab.

Pulih dari kesalahan-1018

Exchange memperlakukan halaman yang gagal dengan kesalahan-1018 sebagai benar-benar tidak terbaca untuk mencegah tindakan pada data acak menyebabkan masalah lebih lanjut dalam database.

Halaman yang gagal dengan-1018 galat tidak dapat diperbaiki atau menyelamatkan. Itu harus expunged dari database. Ada tiga metode yang dapat Anda gunakan untuk kedua halaman dari database:
  • Memulihkan database dari cadangan online.
  • Menggunakan Eseutil.exe BUMI beralih ke melakukan defragmentation offline database.
  • Menggunakan Eseutil.exe P saklar untuk memperbaiki database.

Memulihkan Database dari cadangan Online

Jika kesalahan-1018 ditemukan selama online backup, backup berhenti. Hal ini memastikan bahwa halaman rusak tidak ada cadangan sukses terakhir. Jika melingkar penebangan dimatikan, Anda dapat mengembalikan cadangan lengkap tersedia terbaru, dan kemudian roll database maju dari log transaksi berikutnya.

Menggunakan Eseutil.exe Switch "/ D" untuk melakukan Defragmentation Offline database

Metode ini sangat efektif jika kesalahan-1018 melaporkan pada halaman kosong. Jika terjadi kesalahan-1018 hanya selama cadangan online atau malam pemeliharaan online, ini menunjukkan bahwa halaman yang jarang diakses atau bahwa itu bahkan mungkin kosong. Defragmentasi offline membuang semua halaman kosong dan sekunder indeks di database.

Menggunakan Eseutil.exe "/ P" Switch untuk memperbaiki Database

Halaman buruk tidak diperbaiki jika Anda menggunakan metode ini, tetapi halaman buruk dibuang. Jika halaman yang terlibat adalah "halaman daun," terjadi beberapa data rugi. Daun halaman dalam database adalah halaman yang membawa data aktual. Interior halaman membawa informasi hanya struktural dan logis. Dalam kebanyakan kasus, Eseutil dapat benar-benar merekonstruksi meja jika halaman interior hilang. Namun, sebagian besar halaman di database yang daun halaman.

Eseutil's perbaikan fungsi bekerja dengan baik, dan dalam kebanyakan kasus dapat memulihkan database untuk operasi dengan kehilangan minimal data. Namun, jika banyak halaman rusak, atau sistem kritis tabel hilang, kehilangan data mungkin bencana atau database mungkin unrepairable.

Memperbaiki database biasanya adalah strategi yang lebih rendah dibandingkan dengan memulihkan dari cadangan dan rolling basis data ke depan karena perbaikan biasanya membutuhkan waktu lebih lama daripada pemulihan dan berisiko. Pilih perbaikan hanya jika:
  • Anda tidak memiliki cadangan.
  • Anda tidak bisa roll ke depan benar-benar dari cadangan Anda.
Sebelum Anda memperbaiki atau mengembalikan database, selalu membuat salinan cadangan dari file database saat ini. Jika pemulihan tidak bekerja, Anda dapat memperbaiki database yang ada. Jika perbaikan tidak bekerja, tetapi sebelumnya salinan database masih startable, Anda mungkin dapat menyelamatkan data yang kalau tidak akan hilang.

Penting Setelah Anda memperbaiki database, Anda harus memeriksa menghitung perbaikan di database header. Jika jumlah yang lebih besar dari nol, Anda harus melakukan off-line defragmentasi dengan menggunakan Eseutil, dan kemudian Anda harus memperbaiki database pada tingkat toko informasi dengan utilitas Isinteg. Jika Anda tidak melakukannya, pengguna mungkin mengalami masalah, seperti ketidakmampuan untuk membuka pesan atau lampiran, atau referensi dalam kotak surat untuk item yang tidak lagi ada.

Untuk memeriksa jumlah perbaikan, memeriksa layar output yang dihasilkan ketika Anda menjalankan perintah berikut:
ESEUTIL /MH [database_file_name]
Untuk melakukan defragmentation offline database diperbaiki, jalankan perintah berikut:
ESEUTIL [BUMIdatabase_file_name]
Untuk melakukan perbaikan Isinteg komprehensif setelah perbaikan dalam Exchange 2000, layanan penyimpanan informasi harus berjalan, tetapi database yang ingin Anda perbaiki harus turun. Jalankan perintah berikut untuk memperbaiki database:
ISINTEG [-SSERVER_NAME]-MEMPERBAIKI - TEST ALLTESTS
Untuk melakukan Isinteg komprehensif memperbaiki setelah perbaikan di Exchange Server 5.5, toko informasi layanan harus dihentikan. Jalankan perintah berikut, menggunakan saklar sesuai (-PRI atau -PUB), tergantung pada apakah Anda menjalankan perbaikan terhadap database pribadi atau publik:
ISINTEG-PRI|PUB-MEMPERBAIKI - TEST ALLTESTS
Catatan Anda dapat menjalankan Eseutil dan Esefile terhadap file database mentah terlepas dari file mereka sistem lokasi. File database tidak bahkan perlu berada di Exchange server. Tapi Anda harus menjalankan Isinteg sementara database di tempat pada server Exchange sepenuhnya dikonfigurasi karena Isinteg beroperasi pada tingkat toko informasi dan menggunakan layanan penyimpanan informasi untuk mengakses database.

Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
244525Bagaimana menjalankan Eseutil pada komputer tanpa Exchange Server

Pulih dari galat -1019

Kesalahan -1019 (JET_errPageNotInitialized) melaporkan ketika halaman yang diperkirakan akan digunakan uninitialized atau kosong. Jika bidang nomor halaman pada halaman dalam penggunaan 0x00000000, kesalahan -1019 dilaporkan bukannya kesalahan-1018, meskipun halaman mungkin juga gagal tes checksum.

Metode untuk memperbaiki kesalahan -1019 adalah sama dengan orang-orang untuk memperbaiki kesalahan-1018. Perhatikan bahwa masalah -1019 mungkin terdeteksi lebih dari masalah-1018 karena masalah -1019 tidak terdeteksi oleh cadangan online.

Meskipun akar penyebab kesalahan-1018 sangat mungkin di luar Exchange, kesalahan -1019 mungkin disebabkan oleh Exchange jika pointer logis atau link antara halaman yang tidak sah.

Namun, hal ini lebih umum bahwa kesalahan -1019 disebabkan karena sistem berkas rusak atau dipetakan halaman ke file database yang tidak termasuk dalam file.

Pulih dari galat-1022

Jika pertukaran sistem operasi meminta halaman dalam database, dan terjadi kesalahan bukannya dari halaman data yang dikembalikan, kesalahan-1022 (JET_errDiskIO) hasil. Kesalahan-1022 adalah sebuah kesalahan umum yang muncul setiap kali disk input/output (I/O) masalah mencegah Exchange dari memperoleh akses ke halaman yang diminta dalam database.

Alasan paling umum untuk kesalahan-1022 adalah sebuah file database yang sangat rusak atau terpotong. Apabila masalah ini terjadi, pertukaran permintaan nomor halaman yang lebih besar daripada jumlah halaman di database file, dan kesalahan-1022 hasil. Masalah ini dapat terjadi karena isu-isu dalam sistem file atau karena transaksi pantas log replay.

Exchange 2000 berisi luas pengamanan untuk mencegah replay log transaksi yang mungkin membahayakan database, tapi di Exchange Server 5.5 itu mungkin untuk bermain set lengkap file log dan merusak database. Misalnya, masalah ini mungkin terjadi jika replay harus mulai dari log 9, tetapi sebaliknya replay dipaksa untuk memulai dari log 10. Replay mungkin memaksa jika administrator akan menghapus file pos pemeriksaan dan log 9. Jika transaksi dalam log 9 meluas ukuran database, tapi log 9 tidak bermain ke dalam database, referensi dalam log 10 untuk halaman baru yang ditambahkan ke database menyebabkan kesalahan-1022. Mendadak crash, berhenti (menggantung), dan pelanggaran akses juga gejala umum memutar set log transaksi tidak lengkap ke dalam database.

Memahami dan memecahkan akar penyebab kesalahan-1022 adalah lebih kompleks daripada pemecahan masalah untuk galat-1018 atau -1019. Jika kesalahan tersebut disebabkan oleh kerusakan database dalam sistem file, Anda perlu untuk memverifikasi atau memperbaiki sistem berkas, dan kemudian mengembalikan Exchange dari cadangan. Meskipun memperbaiki database masih pilihan, perbaikan tidak cenderung menjadi sukses daripada dengan kesalahan lain karena kesalahan-1022 sering sinyal kerusakan.

Sejauh alasan paling umum untuk kesalahan-1022 dengan database rusak aplikasi lain memegang file terbuka dan mencegah toko informasi layanan dari mengakses mereka. Dalam kasus tersebut, Anda mungkin juga melihat kesalahan-1032 (JET_errFileAccessDenied). Restart semua layanan pertukaran atau me-restart server mungkin menghapus kunci.

Program pihak ketiga, seperti virus scanner, mungkin memblokir akses Exchange ke Exchange data. Selalu mengkonfigurasi tingkat file virus scanner untuk mengecualikan file data Exchange dari file pemindaian operasi. Beberapa virus scanner tersedia yang memanfaatkan pemindaian antarmuka pemrograman aplikasi (API) untuk memindai pesan dan lampiran di toko informasi virus Exchange.

Menganalisis kesalahan-1018 dan -1019

Informasi dalam bagian ini dimaksudkan terutama untuk dukungan teknis dan vendor personil yang terlibat dalam akar penyebab analisis.

Setelah administrator menemukan kesalahan-1018 atau -1019, administrator perlu tahu setidaknya tiga hal:
  • Apa yang ada di halaman rusak
  • Apakah kemungkinan berhasil perbaikan
  • Apa yang menyebabkan kerusakan di tempat pertama
-1018 dan -1019 kesalahan yang mungkin terjadi pada baris perintah ketika Anda mulai menjalankan layanan, dalam log peristiwa aplikasi, atau output dari Exchange utilitas seperti Eseutil. -1018 Kesalahan dalam log peristiwa aplikasi mungkin tidak dilaporkan ketika Anda menjalankan pemeriksaan integritas database dengan Eseutil /G perintah. Dalam situasi ini, mungkin bahwa halaman buruk kosong.

Dalam kebanyakan kasus, kesalahan dilaporkan dalam bentuk yang memungkinkan Anda untuk mengidentifikasi halaman yang melaporkan masalah. Anda juga dapat memindai seluruh database dengan Esefile untuk mengidentifikasi halaman yang buruk. Untuk informasi lebih lanjut tentang Esefile, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
248406Esefile dukungan utilitas untuk Exchange Server 5.5 dan Exchange 2000
Contoh berikut adalah khas-1018 kesalahan deskripsi dari log peristiwa aplikasi untuk berbagai versi Exchange, bersama dengan analisis rinci dalam setiap kesalahan.
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
Dalam contoh sebelumnya, Anda dapat menafsirkan angka-angka dalam tanda kurung sebagai berikut:
  • (1:3106 1:3106) mewakili halaman dalam database yang diminta (halaman 3106), dan nomor halaman yang sebenarnya ditemukan tertulis pada halaman (halaman 3106). 1: Menunjukkan bahwa ini adalah database 1, yang Priv.edb untuk Exchange Server 5.5. Database 2 adalah Pub.edb.
  • (0-310013) mewakili dbtime nilai yang sedang ditulis pada halaman. The dbtime nilai adalah nilai 64-bit yang ditulis pada setiap halaman yang kira-kira berkorelasi dengan berapa lama sudah sejak halaman diubah.
  • (0-312215) mewakili saat ini dbtime nilai untuk database secara keseluruhan: mungkin dbtime nilai yang akan ditulis pada Halaman ini jika halaman diubah sekarang. The dbtime nilai sudah pada halaman harus selalu menjadi lebih kecil daripada saat ini dbtime nilai.
Mengingat bahwa nomor halaman membaca dengan benar dari halaman, dan dbtime nilai-nilai masuk akal (dengan yang pertama dbtime nilai lebih rendah dari kedua), Halaman ini tidak sepenuhnya diganti dengan halaman dari luar basis data atau halaman yang berbeda.

Anda dapat menggunakan Esefile untuk menampilkan halaman dengan perintah yang mirip dengan berikut ini:
Esefile bumi database.edb 3106 mengatakan 3106.txt
Karena Halaman ini tampaknya secara substansial utuh berkenaan dengan struktur, Anda mungkin juga dapat menggunakan Eseutil untuk melihat informasi lebih logis tentang halaman. Anda dapat menggunakan versi Exchange 2000 Eseutil untuk melihat halaman struktur informasi dari Exchange 2000 dan Exchange Server 5.5 database.

Warning Tidak menggunakan versi Exchange 2000 Eseutil terhadap Exchange Server 5.5 database dalam mode apa pun yang menulis ke database. Untuk amannya, hanya menggunakan LISTRIKNYA switch, dan tidak pernah menggunakan P, /G, atau /R. Juga, jangan tidak menyalin Exchange 2000 versi Eseutil.exe dan Ese.dll ke komputer Exchange Server 5.5. Sebaliknya, salin file ini ke server jauh dan menyediakan jalur baris perintah eksplisit Konvensi Penamaan Universal (UNC) ke database yang Anda periksa.

Perintah yang mirip dengan perintah berikut output logis informasi untuk halaman ke file teks:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
Dari output ini, Anda dapat melihat bahwa halaman adalah halaman daun, yang berarti bahwa ia memiliki data sebenarnya di atasnya. Jika Anda memperbaiki database ini, perbaikan akan mengakibatkan hilangnya setidaknya data ini. Untuk informasi lebih lanjut tentang cara untuk mengetahui mana meja atau kotak surat milik halaman, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
262196Cara menentukan kotak pesan memiliki halaman tertentu dalam database
Jika Eseutil output tidak daftar daun halaman untuk halaman, kemungkinan bahwa perbaikan akan bekerja benar-benar tinggi. Paling interior atau struktural halaman benar-benar dapat direkonstruksi oleh proses perbaikan.

Output mungkin juga menunjukkan ini sebagai "Halaman kosong". Dalam kasus ini, defragmentasi offline akan membuang halaman yang buruk dari database.

Ingat bahwa jika halaman yang benar-benar telah digantikan oleh blok data yang tidak termasuk dalam database file, Eseutil output mungkin bermakna.

Galat berikut adalah contoh lain:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
Dalam contoh ini, jumlah halaman yang benar-benar membaca dari halaman (3688618971) tidak cocok halaman yang diminta, yang berarti bahwa daerah header halaman di mana halaman nomor rusak. Mungkin bahwa nomor halaman bahkan tidak ada di database. Untuk menentukan apakah hal ini terjadi, kalikan jumlah halaman dengan 4,096, dan kemudian membandingkan bahwa jumlah byte ukuran database file. Dalam kasus ini, nomor halaman tidak mungkin salah satu yang pertukaran awalnya menulis, kecuali database 15 Terabyte ukuran (3,688,618,971 x 4,096 = 15,108,583,305,216).

Juga perhatikan bahwa pertama dbtime nilai mengulangi pola nomor halaman yang tepat. Jika Anda mengubah 3688618971 menjadi heksadesimal (menggunakan Calc.exe dalam mode yang ilmiah), menjadi 0xDBDBDBDB. Di Exchange 2000 dan Exchange Server 5.5, 8-byte dbtime nilai disimpan segera setelah nilai angka 4-byte halaman. Karena ini, Anda tahu bahwa setidaknya dua belas bersebelahan byte untuk dua bidang yang berbeda ditimpa dengan pola tertentu. Jika Anda menggunakan Esefile untuk melihat halaman ini secara langsung, Anda mungkin akan menemukan bahwa seluruh halaman ditimpa dengan pola 0xDB. Lain sering terlihat tidak sah byte pola adalah 0xFF. Jika ini adalah kasus kesalahan di atas, dbtime nilai akan 4294967295.

Galat berikut memberikan informasi halaman sebagai byte offset ke file, bukan sebagai nomor halaman:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
Anda dapat mengkonversi offset pertama untuk nomor halaman dengan menghapus tiga angka nol-trailing, mengurangi 1 dan mengubah hasilnya untuk desimal. Dalam contoh ini, 0x00000000000db - 1 = 0xda = 218 desimal. Anda dapat menggunakan angka desimal Halaman ini dengan Esefile atau Eseutil.

Catatan Anda mengurangi hanya 1, bukan 2, untuk memperhitungkan dua header halaman dalam database karena offset mulai menghitung 0x0 bukan dari 0x00000001. Jika Anda ingin memeriksa halaman header dengan Esefile atau Eseutil, referensi Halaman-1 dan 0.

Exchange database header benar-benar membutuhkan hanya satu halaman. Halaman kedua adalah salinan "bayangan" header. Checksum yang dilaporkan ketika Anda menggunakan Esefile bumi Halaman dump fungsi selalu harus sama untuk halaman-1 dan 0 setelah database dimatikan bersih. Jika header ulang selama kecelakaan, pertukaran menggunakan salinan header dengan checksum bersih ketika Exchange restart.

Melanjutkan dengan contoh sebelumnya, checksum yang benar-benar sangat dekat dengan satu sama lain, berbeda dalam dua karakter. Ketika checksum dekat, ini menunjukkan bahwa perubahan pada halaman yang minimal: mungkin hanya satu sedikit kesalahan. Sangat mungkin bahwa Halaman ini masih mengandung cukup struktur logis untuk membuat menganalisis dengan layak Eseutil listriknya p.

Checksum diharapkan dalam pesan galat adalah checksum yang benar-benar membaca dari halaman seperti yang ada sekarang di database. Checksum sebenarnya dalam pesan galat adalah checksum yang pertukaran secara dinamis re-calculates seperti membaca halaman.

Apakah checksum sebenarnya pada halaman 0x89abcdef, halaman berisi semua 0x00 karakter. Jika checksum sebenarnya adalah 0x76543210, halaman berisi semua 0xFF karakter.

Contoh berikut adalah kesalahan -1019:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
Selama operasi khas, jika halaman dapat melaporkan kesalahan -1019 atau-1018 kesalahan, kesalahan -1019 diprioritaskan dan dilaporkan. Ingat bahwa kesalahan -1019 terjadi setiap kali nomor halaman yang ditulis pada halaman 0x00000000, tapi Exchange mengharapkan halaman yang akan digunakan. Ini bisa sulit untuk membuktikan apakah kesalahan -1019 disebabkan karena sistem berkas dipetakan blok nol ke database file, atau karena Exchange membuat kesalahan dan direferensikan halaman tidak digunakan sebagai "dalam penggunaan."

Anda tidak bisa mengatakan dari kesalahan sebelumnya apakah halaman uninitialized atau di beberapa negara lain. Anda harus menggunakan Esefile dan Eseutil untuk lebih lanjut memeriksa halaman. Dalam contoh ini, jumlah halaman adalah 408 desimal (berasal dari 0x199).

Anda dapat menggunakan Eseutil untuk lebih lanjut memeriksa halaman. The pgnoThis nilai harus cocok dengan nomor halaman yang bertanya, dan ulChecksumParity nilai laporan tambahan ** dihitung checksum nilai jika checksum pada halaman salah. Anda dapat menggunakan Esefile BUMI saklar untuk melihat halaman mentah untuk menentukan apakah uninitialized (semua 0x00 karakter).

Palsu-1018 kesalahan

"Palsu"-1018 kesalahan terjadi ketika halaman pada disk benar, tetapi sistem I/O mengambil data salah. Kesalahan seperti ini biasanya sulit untuk mengisolasi dan sementara. Tapi bahkan kesalahan-1018 "palsu" layak perhatian serius. Kehandalan sistem penyimpanan masih terganggu, dan sistem mungkin berada dalam bahaya dari masalah tambahan atau kegagalan.

Jika Anda mencurigai sementara membaca kesalahan dalam sistem Anda, menggunakan Esefile BUMI mengaktifkan atau Eseutil listriknya p untuk memverifikasi halaman individu yang terlibat. Jika Anda menggunakan utilitas baik untuk memindai seluruh database, Anda meletakkan tekanan pada sistem I/O yang mungkin mengakibatkan lebih palsu positif.

Exchange Server 5.5 Paket Layanan 2 (SP2) menambahkan fungsionalitas untuk membantu mengidentifikasi sementara membaca kesalahan. Exchange re-reads halaman sebanyak 16 kali setelah kegagalan baca verifikasi. Jika halaman membaca akhirnya berhasil setelah beberapa kali, itu menunjukkan bahwa ada masalah sistem dalam membaca terpercaya dari disk. Bahkan jika semua 16 membaca gagal, itu tidak meyakinkan membuktikan bahwa halaman buruk. Melakukan tes sekunder dengan Esefile atau Eseutil.

Database Zeroing

Database zeroing dimaksudkan untuk mengaburkan dihapus informasi dalam database Exchange sehingga tidak dapat ditemukan atau dibaca oleh pemeriksaan langsung dari database file. Untuk informasi lebih lanjut tentang database zeroing, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
223161Informasi tentang ESE zeroing
Jika database zeroing diaktifkan, bagian halaman kosong atau sebagian kosong mungkin ditimpa dengan pola karakter tertentu, tetapi halaman masih tidak kembali ke negara uninitialized.

Properti

ID Artikel: 314917 - Kajian Terakhir: 24 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Kata kunci: 
kbinfo kbmt KB314917 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:314917

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