ทำความเข้าใจและวิเคราะห์-1018, -1019 และ-1022 Exchange ข้อผิดพลาดของฐานข้อมูล

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 314917 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

บทความนี้ให้ข้อมูลเพื่อช่วยให้คุณทำความเข้าใจ และวิเคราะห์-1018, -1019 และ-1022 อัตราแลกเปลี่ยนฐานข้อมูลผิด บทความนี้อธิบายความแตกต่างระหว่างข้อผิดพลาดเหล่านี้สามและชนิดของการออกใช้ในฐานข้อมูลที่ทำให้เกิดข้อผิดพลาดเหล่านี้สามที่จะรายงานแต่ละ

ข้อมูลเพิ่มเติม

อัตราแลกเปลี่ยนรวมถึงหน้าที่การใช้งานการตรวจสอบความเสียหายของแฟ้มระดับไปยังเพจต่าง ๆ ในฐานข้อมูลของ สามข้อผิดพลาดทั่วไปส่วนใหญ่ที่เกี่ยวข้องกับความเสียหายของแฟ้มระดับอัตราแลกเปลี่ยนฐานข้อมูล มีดังนี้:
  • -1018 JET_errReadVerifyFailure
  • -1019 JET_errPageNotInitialized
  • -1022 JET_errDiskIO
สามระดับต่อไปนี้ของความเสียหายอาจเกิดขึ้นได้ในอัตราแลกเปลี่ยนฐานข้อมูล:
  • ระดับของเพจ (แฟ้มระบบ)
  • ระดับของฐานข้อมูล (ฐานข้อมูลโปรแกรม JET)
  • ระดับของแอพลิเคชัน (จัดเก็บข้อมูล Exchange)
โปรแกรมอรรถประโยชน์ Esefile.exe นี้สามารถตรวจพบข้อผิดพลาดในฐานข้อมูลในระดับเพจ โปรแกรมอรรถประโยชน์ที่หน้าจอพร้อมสามารถตรวจหา และซ่อมแซมปัญหาที่ทั้งระดับหน้าและระดับฐานข้อมูล โปรแกรมอรรถประโยชน์ Isinteg.exe นี้ตรวจหา และซ่อมแซมปัญหาในระดับแอพลิเคชัน

ความเสียหายที่ต่ำกว่าแบบระดับ (ระดับหน้า) เกือบทุกผลลัพธ์ที่เกิดปัญหาในระดับที่สูงขึ้น (ฐานข้อมูลหรือโปรแกรมประยุกต์ระดับ) ดังนั้น หลังจากที่คุณซ่อมแซมฐานข้อมูลที่ มีคำสั่ง Eseutil คุณเกือบทุกต้องใช้ Isinteg หลังจากนั้น

ความเสียหายในระดับฐานข้อมูลและโปรแกรมประยุกต์ที่เกี่ยวข้องกับประเด็น ในการแลกเปลี่ยนรหัส หรือ ในโปรแกรมของบริษัทอื่นที่ผนึกรวมกับอัตราแลกเปลี่ยน ความเสียหายในระดับหน้ามักมีสาเหตุจากโปรแกรมควบคุม เฟิร์มแวร์ หรือ ปัญหาฮาร์ดแวร์ ถึงแม้ว่าความเสียหายหน้าระดับอาจยังเกิดจากปัญหาใน Exchange

หาสาเหตุหลักในระบบต้นแบบที่ขึ้นอยู่กับอัตราแลกเปลี่ยนอย่างหนึ่งสำหรับข้อผิดพลาดในการ-1018 เกือบทุก ไม่แลกเปลี่ยนรหัสตัวเอง ไม่มีข้อยกเว้นกฎนี้น้อยมาก ข้อยกเว้นสำหรับวันที่มีการเกี่ยวข้องกับการแลกเปลี่ยนเงื่อนไข-1018 รายงานไม่เนื่องจากอัตราแลกเปลี่ยนตัวเองเป็นสาเหตุของข้อผิดพลาดในการ-1018 สำหรับข้อมูลเพิ่มเติม ให้คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
237953ข้อผิดพลาด-1018 มีข้อผิดพลาดที่ถูกส่งกลับมาในระหว่างการสำรองข้อมูลออนไลน์
230215 Checksuming สำรองข้อมูลที่ไม่ดำเนินการบนคอมพิวเตอร์ที่ใช้ตัวประมวลผลเดียว
ถึงแม้ว่าส่วนใหญ่ของข้อผิดพลาด-1019 และ-1022 มียังสาเหตุเป็นข้อบกพร่องในระบบการขีดเส้นใต้ คุณไม่สามารถแยกแยะออกว่า -1019 และ-1022 ข้อผิดพลาดอาจเกิดขึ้นเนื่องจากการมีข้อผิดพลาดใน Exchange รหัสเป็นได้อย่างรวดเร็วที่อาจเกิดขึ้น

ข้อผิดพลาด-1018 คือ พลาดบ่อยที่สุด seen ซึ่งบ่งชี้ว่า ฐานข้อมูล Exchange มี suffered ความเสียหายในระดับระบบแฟ้ม ดังนั้น ส่วนใหญ่ของบทความนี้มุ่งเน้นการเกิดข้อผิดพลาด-1018

มีวิธีพื้นฐานสามที่ว่า ข้อมูลบนดิสก์อาจเสียหาย:
  • ข้อมูลที่ไม่ถูกต้องถูกเขียนลงไปยังสื่อเก็บข้อมูล
  • เขียนข้อมูลไปยังตำแหน่งที่ไม่ถูกต้องบนสื่อเก็บข้อมูล
  • ข้อมูลเสียหาย หรือถูกเปลี่ยนหลังจากที่มีเก็บ
แม้ว่ามันเป็นเรื่องยากมากในการป้องกัน หรือแก้ไข 100 เปอร์เซ็นต์ของความเสียหายทั้งหมด เป็นค่อนข้างง่ายเพื่อตรวจหาปัญหาที่เกิดขึ้น อัตราแลกเปลี่ยนตรวจพบข้อมูลที่ไม่ถูกต้อง และเปิดที่วางผิดทั้งในแฟ้มของฐานข้อมูล และรายงานข้อผิดพลาดในการ-1018 หรือข้อผิดพลาด-1019 ถ้าแฟ้มถูกเสียหายอย่างรุนแรง และชิ้นส่วนดังกล่าวขาดหายไปทั้งหมด หรือมีมิฉะนั้นจะไม่สามารถเข้าถึงเมื่อมีการแลกเปลี่ยนพยายามที่จะอ่านไฟล์ มีรายงานข้อผิดพลาดในการ-1022

วิธีคำนวณอัตราแลกเปลี่ยน Checksums และฐานข้อมูลหมายเลขหน้า

เมื่อต้องการทำความเข้าใจเกี่ยวกับวิธีการทำงานของกลไกที่ก่อให้เกิดข้อผิดพลาด-1018 และ-1019 คุณต้องเข้าใจวิธีการฐานข้อมูล Exchange จัดเก็บเพจข้อมูล

ในระดับต่ำสุดแบบลอจิคัล คุณสามารถดูแฟ้มฐานข้อมูลที่มีอัตราแลกเปลี่ยนเป็นชุดของเพจที่ (KB) -4 กิโลไบต์ การลำดับเลขในใบสั่งตามลำดับ ข้อมูลถูกอ่าน และเขียนลงในการแลกเปลี่ยนฐานข้อมูลหนึ่งหน้าในแต่ละครั้ง

แต่ละเพจที่ประกอบด้วยข้อมูลเก็บเลขตัวเองหน้า พร้อม ด้วย checksum ที่คำนวณจากข้อมูลทั้งหมดบนหน้า ค่า checksum ตัวเองเป็นส่วนเดียวของเพจที่ไม่ได้รวมอยู่ในการคำนวณนี้

อัลกอริ checksum ทึม รวมทั้งอัลกอริทึม checksum ที่ใช้อัตราแลกเปลี่ยน กำลัง understood ดี และค่อนข้างง่าย พวกเขาถูกออกแบบมาเพื่อให้โอกาส checksum ที่เดียวกันจะส่งผลให้สำหรับใด ๆ แตกต่างกันสองหน้าเป็นต่ำ แม้ว่าความแตกต่างระหว่างเพจต่าง ๆ เดียวเท่านั้นที่จะบิต

ถึงแม้ว่าการทดสอบนับเป็นเพียงพอต่อการตรวจสอบหรือไม่เพจที่มีการเปลี่ยนแปลงนับตั้งแต่ที่ถูกเขียนขึ้น การทดสอบ checksum ไม่เพียงพอเพื่อให้แน่ใจว่า เพจนั้นอยู่ในตำแหน่งที่ด้านขวา เนื่องจากการนี้ การแลกเปลี่ยนแต่ละหน้า stamps กับหมายเลขหน้าของตนเองเช่นเดียวกับการนับ

จองสอง 4 KB หน้าแรกในฐานข้อมูลสำหรับฐานข้อมูล "หัวข้อ" เมื่อฐานข้อมูลถูกหยุด คุณสามารถใช้อรรถประโยชน์ Eseutil จะ /MH สวิตช์เพื่อดูหัวข้อนี้ หัวข้อที่ประกอบด้วยข้อมูลการระบุเกี่ยวกับฐานข้อมูลทั้งหมด

หลังจากที่หัวข้อที่สองก่อนจเหล่า ทั้งหมดของเพจอื่น ๆ ในฐานข้อมูลมีข้อมูล โครงสร้างที่พบโดยทั่วไปหน้าข้อมูลทั้งหมดที่ใช้ร่วมกัน แต่ละหน้ามีหัวตัวเองหน้า ซึ่งประกอบด้วยข้อมูลการระบุเกี่ยวกับบางเพจ ตาม ด้วยข้อมูลที่แท้จริง

เนื่องจากหน้าแรกของข้อมูลในฐานข้อมูล Exchange จะอยู่หลังจากหน้าแรกของหัวข้อที่สอง หน้า 3 ที่มีอยู่จริงในฐานข้อมูลเป็นแบบลอจิคัลหน้า 1 2 คือ หมายเลขหน้าแบบลอจิคัลของหน้าทางกายภาพ 4 และอื่น ๆ

หมายเลขหน้าแบบลอจิคัลในฐานข้อมูลแมปโดยตรงกับหมายเลขหน้าทางกายภาพ โดยใช้สูตรต่อไปนี้:
หมายเลขหน้าแบบลอจิคัล =หมายเลขหน้าทางกายภาพ - 2
เนื่องจากโครงสร้างหน้าแบบลอจิคัล และทางกายภาพของแฟ้มฐานข้อมูลเกี่ยวข้องมากดังนั้น อัตราแลกเปลี่ยนสามารถกำหนดได้อย่างง่ายดายว่าว่า แต่ละหน้าแบบลอจิคัลอยู่ในตำแหน่งทางกายภาพที่ถูกต้องในแฟ้ม

หน้าเท่านั้นในฐานข้อมูลซึ่งการที่ checksum ไม่ถูกคำนวณเป็น "หน้าเตรียม" เหล่านี้คือบล็อกของเพจที่สร้างขึ้นเมื่อมีขยายขนาดฐานข้อมูลเพื่อให้มีที่ว่างสำหรับข้อมูลเพิ่มเติม เพจที่มีเตรียมเป็นหนึ่งที่มีการนับเป็นศูนย์และหมายเลขหน้าเป็นศูนย์ โดยทั่วไปแล้ว ทุกไบต์ของเพจที่เตรียมจะถูกกรอกข้อมูล ด้วยอักขระ 0x00.

หลังจากที่ไม่ได้ใช้หน้าการเตรียมการสำหรับในครั้งแรก ไม่กลับไปยังสถานะเตรียม แม้ว่าจะมีการลบข้อมูล แทน การกำหนดค่าสถานะบนเพ emptied เพื่อทำเครื่องหมายจะพร้อมใช้งานสำหรับการใช้งานใหม่ หน้ายังคงปฏิบัติแบบหมายเลขหน้าและ checksum แม้ว่าจะเป็นความว่างเปล่า

Exchange Server 2003 Service Pack 1 (SP1) การเปลี่ยนแปลงอัลกอริทึมการนับและรูปแบบหน้าที่ใช้ นอกจากนี้ Exchange Server 2003 SP1 แนะนำข้อผิดพลาดที่อัลกอริทึมรหัส (ECC) เพื่อตรวจหา และแก้ไขข้อผิดพลาดเดียวบิตโดยอัตโนมัติในการแก้ไขสำหรับข้อมูลเพิ่มเติมเกี่ยวกับฟังก์ชันนี้ใหม่ คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
867626การแก้ไขรหัสข้อผิดพลาดใหม่จะรวมอยู่ใน Exchange Server 2003 Service Pack 1

อะไรเป็นสาเหตุของข้อผิดพลาดในการ-1018

แลกเปลี่ยนรายงานพบมีข้อผิดพลาด-1018 เมื่อเพจที่เตรียมใช้งานในแฟ้มฐานข้อมูลไม่ มีเงื่อนไขใด ๆ ต่อไปนี้:
  • Checksum ที่จัดเก็บไว้บนหน้ากระดาษตรงกับผลลัพธ์จากการคำนวณซ้ำการนับที่จะดำเนินการ ตามที่หน้าเป็นแบบอ่านอย่าง
  • หมายเลขหน้าที่จัดเก็บไว้บนหน้ากระดาษตรงกับหมายเลขหน้าที่ควรจะอยู่บนหน้า กำหนดตำแหน่งทางกายภาพของเพจในแฟ้มฐานข้อมูล
อัตราแลกเปลี่ยนอาจเป็นผู้รับผิดชอบสำหรับ self-generating มีข้อผิดพลาด-1018 ถ้าอัตราแลกเปลี่ยนไม่อย่างใดอย่างหนึ่งต่อไปนี้:
  • สร้างเพจที่มีการ checksum ไม่ถูกต้อง
  • สร้างเพจที่ถูกต้อง แต่บอกระบบปฏิบัติการเพื่อเขียนหน้าในตำแหน่งที่ตั้งที่ไม่ถูกต้อง
หลังจากที่ผู้ดูแลระบบพบมีข้อผิดพลาดการ-1018 ถ้าผู้ดูแลเรียกใช้การทดสอบฮาร์ดแวร์การวินิจฉัยเทียบกับเซิร์ฟเวอร์ และการทดสอบเหล่านี้รายงานปัญหาไม่มี ผู้ดูแลอาจทรานการแลกเปลี่ยนต้องเป็นผู้รับผิดชอบสำหรับปัญหาว่า เนื่องจากฮาร์ดแวร์ส่งผ่านการวิเคราะห์เริ่มต้น

เพิ่มอย่างไรก็ตาม ในกรณีหลังจากกรณี เติมสอบสวน โดย Microsoft หรือฮาร์ดแวร์ผู้จัดจำหน่าย uncovered สีสันปัญหาในโปรแกรมควบคุมฮาร์ดแวร์ เฟิร์มแวร์ หรืออุปกรณ์ที่อยู่ผู้รับผิดชอบจริง ๆ สำหรับการทำลายแฟ้มฐานข้อมูล

ปกติการทดสอบการวินิจฉัยอาจพบข้อบกพร่องที่ transient ทั้งหมดด้วยเหตุผลหลายประการ ปัญหาในซอฟต์แวร์เฟิร์มแวร์หรือโปรแกรมควบคุมอาจอยู่นอกความสามารถของโปรแกรมการวินิจฉัย การทดสอบการวินิจฉัยอาจไม่สามารถจำลองเวลาเรียกใช้เวลานานหรือโหลดที่ซับซ้อนอย่างเพียงพอ ยัง การเพิ่มการตรวจสอบหรือการตรวจแก้จุดบกพร่องบันทึกการวินิจฉัยอาจเปลี่ยนระบบเพียงพอเพื่อป้องกันไม่ให้ปัญหานี้ปรากฏอีกครั้ง

ความไม่ซับซ้อนและความเสถียรของกลไกการแลกเปลี่ยนที่สร้าง checksums และเขียนหน้าไปยังแฟ้มฐานข้อมูล คือ เหตุผลอื่นที่มีความน่าเป็นว่า สาเหตุหลักสำหรับข้อผิดพลาดในการ-1018 เป็นประเด็นแลกเปลี่ยนที่ไม่เพียงพอ Checksum และกลไกการตรวจหาเพจที่ไม่ถูกต้องเป็นแบบธรรมดา ความน่าเชื่อถือ และมียังคงภาระเหมือนกันเนื่องจากอัตราแลกเปลี่ยนที่แรกปล่อย ยกเว้นการเปลี่ยนแปลงเพียงเล็กน้อยเมื่อต้องการประยุกต์ใช้ฐานข้อมูลหน้าการเปลี่ยนแปลงรูปแบบระหว่างรุ่นฐานข้อมูล

หมายเพื่ออธิบายเพิ่มเติม checksum ถูกสร้างขึ้นสำหรับเพจที่กำลังจะสามารถเขียนลงดิสก์หลังจากทั้งหมดของข้อมูลที่เขียนลงในหน้ากระดาษ รวมทั้งหน้าเลขตัวเอง หลังจากแลกเปลี่ยนเพิ่ม checksum ที่ไปยังเพจที่ แลกเปลี่ยนแนะนำให้ระบบปฏิบัติการ Microsoft Windows เขียนหน้าไปยังดิสก์ โดยใช้มาตรฐาน เผยแพร่ Windows บเจกต์ (Api)

Checksum อาจถูกสร้างขึ้นอย่างถูกต้องสำหรับเพจ แต่อาจเขียนหน้าไปยังตำแหน่งที่ไม่ถูกต้องแล้ว บนฮาร์ดดิสก์ ซึ่งอาจเกิดจากข้อผิดพลาดหน่วยความจำ transient เช่นแบบ "บิตพลิก ตัวอย่างเช่น สมมติอัตราแลกเปลี่ยนสร้างหน้า 70 รุ่นใหม่ เพจนั้นไม่พบข้อผิดพลาด แต่มีการเปลี่ยนแปลงสำเนาของหมายเลขหน้าถูกใช้ โดยตัวควบคุมดิสก์ หรือ โดยระบบปฏิบัติการแบบสุ่ม ปัญหานี้อาจเกิดขึ้นถ้า 70 (ไบนารี 100110) ได้ถูกเปลี่ยนเป็น 6 (000110 ไบนารี) โดยเซลล์มีหน่วยความจำที่ไม่เสถียร Checksum ของเพจจะยังคงถูกต้อง แต่ตำแหน่งที่ตั้งของเพจในฐานข้อมูลไม่ถูกต้องในขณะนี้ อัตราแลกเปลี่ยนรายงานข้อผิดพลาด-1018 หรับเพจเมื่อตรวจพบว่า หมายเลขหน้าแบบลอจิคัลไม่ตรงกับตำแหน่งที่ตั้งทางกายภาพของเพจ หมายเลขข้อผิดพลาด (ที่เกิดจากการแลกเปลี่ยน) หน้าชนิดอื่นอาจเกิดขึ้นได้ถ้าอัตราแลกเปลี่ยนเขียนหมายเลขหน้าไม่ถูกต้องบนเพจนั้น แต่นี้เป็นสาเหตุของข้อผิดพลาดอื่น ๆ ไม่ผิดพลาด-1018 หากอัตราแลกเปลี่ยนเขียน 71 หน้า 70 แล้ว ไม่นับจากหน้าได้อย่างถูกต้อง หน้าถูกเขียนไปยังตำแหน่งที่ตั้ง 71 และส่งผ่านทั้งสองหน้าหมายเลขและ checksum ทดสอบ

บ่อย มีข้อผิดพลาดการ-1018 เดียวที่มีรายงานในฐานข้อมูล Exchange ไม่ก่อให้เกิดฐานข้อมูลที่จะหยุด หรือทำให้เกิดอาการแบบอื่นนอกเหนือจากสถานะการออนไลน์ของข้อผิดพลาด-1018 ตัวเอง หน้าอาจจะอยู่ในโฟลเดอร์ที่ infrequently มีการเข้าถึง (ยกตัวอย่างเช่น การส่งรายการที่ถูกลบโฟลเดอร์หรือ), หรือ ในสิ่งที่แนบมาที่ seldom เปิด หรือแม้แต่ว่างเปล่าได้

ถึงแม้ว่ามีข้อผิดพลาด-1018 เดียวไม่น่าจะทำให้เกิดการสูญหายของข้อมูลที่ครอบคลุม ข้อผิดพลาด-1018 กันยังคงสาเหตุเกี่ยวกับได้เนื่องจากมีข้อผิดพลาด-1018 proof ว่า ระบบการจัดเก็บข้อมูลของคุณไม่สามารถเชื่อถือเก็บ หรือดึงข้อมูลค่าอย่างน้อยหนึ่งครั้ง ถึงแม้ว่าข้อผิดพลาด-1018 อาจเป็นปัญหาที่ transient ที่จะเกิดขึ้นไม่เคยอีกครั้ง มีมากยิ่งขึ้นว่า ข้อผิดพลาดนี้เป็นข้อเตือนล่วงหน้าของประเด็นที่จะกลายเป็นเรื่อย ๆ worse แม้ว่าจะมีข้อผิดพลาด-1018 ครั้งแรกบนเพจที่มีว่างเปล่าในฐานข้อมูล คุณไม่ทราบว่าหน้าใดบ้างอาจจะเสียหายถัดไป ถ้าตารางที่ส่วนกลางสำคัญเสียหาย ฐานข้อมูลอาจเป็น unstartable และซ่อมแซมฐานข้อมูลอาจไม่ประสบความสำเร็จ หรือสำเร็จบางส่วนเท่านั้น

หลังจากที่มีบันทึกข้อผิดพลาดในการ-1018 คุณต้องพิจารณา และวางแผนสำหรับความล้มเหลว imminent หรือเพิ่มเติมแบบสุ่มเสียหายไปยังฐานข้อมูลที่อาจเกิดขึ้นจนกว่าคุณค้นหา และกำจัดสาเหตุหลัก

การกู้คืนจากข้อผิดพลาด-1018

อัตราแลกเปลี่ยนถือเพจที่ทำงานล้มเหลว ด้วยข้อผิดพลาด-1018 เป็นที่เรียบร้อยไม่สามารถอ่านเพื่อป้องกันไม่ให้ดำเนินการตามข้อมูลที่สุ่มก่อปัญหาในฐานข้อมูล

ไม่สามารถซ่อมแซมได้ หรือ salvaged เพจที่ทำงานล้มเหลว ด้วยข้อผิดพลาดในการ-1018 ดังกล่าวต้อง expunged จากฐานข้อมูล มีสามวิธีที่คุณสามารถใช้เพื่อ expunge หน้าจากฐานข้อมูล:
  • คืนค่าฐานข้อมูลจากการสำรองข้อมูลแบบออนไลน์
  • หน้าจอพร้อมใช้ /D สลับไปที่ทำการจัดเรียงข้อมูลแบบออฟไลน์ของฐานข้อมูล
  • หน้าจอพร้อมใช้ /P หากต้องการสลับไปยังฐานข้อมูลที่ซ่อมแซม

การคืนค่าฐานข้อมูลจากการสำรองข้อมูลแบบออนไลน์

ถ้าพบข้อผิดพลาดในการ-1018 ในระหว่างการสำรองข้อมูลออนไลน์ สำรองข้อมูลหยุด นี้ทำให้แน่ใจว่า หน้าเสียหายไม่มีอยู่ในการสำรองข้อมูลที่สำเร็จครั้งล่าสุด ถ้าปิดใช้งานการเข้าสู่ระบบแบบวงกลม คุณสามารถคืนค่าการสำรองข้อมูลทั้งหมดที่พร้อมใช้งานล่าสุด แล้ว หมุนฐานข้อมูลไปข้างหน้าจากล็อกธุรกรรมในภายหลัง

หน้าจอพร้อมใช้สวิตช์ "/ D" เพื่อทำการจัดเรียงข้อมูลแบบออฟไลน์ของฐานข้อมูล

วิธีการนี้จะมีผลบังคับใช้ถ้ามีรายงานข้อผิดพลาด-1018 บนเพจที่มีที่ว่างเปล่า หากเกิดข้อผิดพลาด-1018 เท่านั้นในระหว่างการสำรองข้อมูลแบบออนไลน์หรือการบำรุงรักษาที่ออนไลน์ nightly นี้บ่งชี้ว่า เพ seldom เข้าถึงได้ หรือว่า แม้แต่อาจว่างเปล่า การจัดเรียงข้อมูลแบบออฟไลน์ละทิ้งหน้าที่ว่างและดัชนีรองในฐานข้อมูลทั้งหมด

ใช้หน้าจอพร้อม " / P " สลับไปยังการซ่อมแซมฐานข้อมูล

หน้าที่ไม่ถูกต้องไม่ได้รับการซ่อมแซมหากคุณใช้วิธีนี้ แต่หน้าไม่ถูกต้องจะถูกยกเลิก ถ้าเพจที่เกี่ยวข้องกับ "การ"โหนดปลายสุดหน้า การสูญหายของข้อมูลบางอย่างเกิดขึ้น หน้าใบไม้ในฐานข้อมูลเป็นหน้าที่ส่งผ่านข้อมูลที่แท้จริง หน้าภายในดำเนินการข้อมูลเฉพาะทางโครงสร้าง และแบบลอจิคัล สร้างโดยส่วนใหญ่ Eseutil สามารถอย่างสมบูรณ์ใหม่ตารางถ้าเพจที่มีภายในจะสูญหายไป อย่างไรก็ตาม เพจในฐานข้อมูลส่วนใหญ่จะเป็นโหนดปลายสุดหน้า

ทำงานฟังก์ชันการทำงานของคำสั่ง Eseutil ซ่อมแซมได้ด้วย และ ในกรณีส่วนใหญ่สามารถคืนค่าฐานข้อมูลเพื่อดำเนินการกับข้อมูลที่น้อยที่สุดสูญหาย อย่างไรก็ตาม ถ้าจะไม่เสียหายหลายหน้า หรือตารางของระบบที่สำคัญ ๆ จะสูญหายไป ข้อมูลสูญหายอาจจะรุนแรง หรือฐานข้อมูลอาจเป็น unrepairable

ซ่อมแซมฐานข้อมูลได้มักจะเป็นกลยุทธ์ที่ inferior เมื่อเปรียบเทียบกับการคืนค่าจากการสำรองข้อมูล และการนำฐานข้อมูลไปข้างหน้าเนื่องจากการซ่อมแซมโดยปกติใช้เวลานานกว่าการคืนค่า และเป็น riskier เลือกการซ่อมแซมเท่านั้นถ้า:
  • คุณไม่มีสำเนาสำรอง
  • คุณไม่สามารถย้อนไปข้างหน้าอย่างสมบูรณ์จากสำเนาสำรองของคุณ
ก่อนที่คุณซ่อมแซม หรือการคืนค่าฐานข้อมูล ทำสำเนาสำรองของแฟ้มฐานข้อมูลปัจจุบันเสมอ ถ้าคืนค่าทำงาน คุณสามารถซ่อมแซมฐานข้อมูลที่มีอยู่ ถ้าทำการซ่อมแซมงาน แต่สำเนาก่อนหน้าของฐานข้อมูลจะยังคง startable คุณอาจสามารถไปยังข้อมูลซากที่น่ามิฉะนั้นจะสูญหายไป

สิ่งสำคัญ หลังจากที่คุณซ่อมแซมฐานข้อมูล คุณต้องตรวจสอบการนับจำนวนการซ่อมแซมในส่วนหัวของฐานข้อมูล ถ้าการตรวจนับจะมากกว่าศูนย์ คุณต้องดำเนินการจัดเรียงข้อมูลแบบออฟไลน์ได้ โดยใช้คำสั่ง Eseutil แล้ว คุณต้องซ่อมแซมฐานข้อมูลในระดับการเก็บข้อมูลด้วยอรรถประโยชน์ Isinteg ถ้าคุณไม่ทำเช่นนั้น ผู้ใช้อาจพบปัญหาที่ เช่นการไม่สามารถเปิดข้อความ หรือสิ่งที่แนบ หรือการอ้างอิงในกล่องจดหมายของพวกเขาเข้ากับสินค้าที่ไม่มีอยู่

เมื่อต้องการตรวจนับการซ่อมแซม ตรวจสอบการแสดงผลหน้าจอที่ถูกสร้างขึ้นเมื่อคุณเรียกใช้คำสั่งต่อไปนี้:
ESEUTIL /MH [database_file_name]
เมื่อต้องการทำการจัดเรียงข้อมูลแบบออฟไลน์ของฐานข้อมูลที่ซ่อมแซม เรียกใช้คำสั่งต่อไปนี้:
ESEUTIL /D [database_file_name]
เมื่อต้องการทำการแก้ไข Isinteg ครอบคลุมขึ้นหลังจากการซ่อมแซมใน Exchange 2000 บริการจัดเก็บข้อมูลต้องทำงาน แต่ต้องสามารถยกฐานข้อมูลที่คุณต้องการซ่อมแซม เรียกใช้คำสั่งต่อไปนี้สำหรับการแก้ไขฐานข้อมูล:
-S ISINTEGserver_name] -แก้ไข - ทดสอบ ALLTESTS
เมื่อต้องการทำ Isinteg ที่ครอบคลุมแก้ไขหลังจากการซ่อมแซมใน Exchange Server 5.5 การจัดเก็บข้อมูลต้องหยุดบริการ เรียกใช้คำสั่งต่อไปนี้ การใช้(สวิตช์ที่เหมาะสม-PRI หรือ -PUB), ขึ้นอยู่กับว่าคุณกำลังเรียกใช้ซ่อมแซมเทียบกับฐานข้อมูลส่วนตัว หรือสาธารณะ:
ISINTEG-PRI|PUB-แก้ไข - ทดสอบ ALLTESTS
หมายเหตุ คุณสามารถเรียกใช้ Eseutil และ Esefile กับแฟ้มฐานข้อมูล raw คำนึงถึงแฟ้มของตำแหน่งที่ตั้งของระบบ แฟ้มฐานข้อมูลไม่จำเป็นแม้แต่อยู่บนเซิร์ฟเวอร์ Exchange แต่คุณต้องเรียกใช้ Isinteg ในขณะที่ฐานข้อมูลอยู่ในตำแหน่งบน Exchange server ที่กำหนดค่าไว้อย่างสมบูรณ์เนื่องจาก Isinteg ดำเนินงานในระดับการจัดเก็บข้อมูล และใช้บริการที่เก็บข้อมูลการเข้าถึงฐานข้อมูล

สำหรับข้อมูลเพิ่มเติม ให้คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
244525วิธีการเรียกใช้ Eseutil บนคอมพิวเตอร์ที่ไม่มี Exchange Server

การกู้คืนจากข้อผิดพลาดในการ-1019

มีรายงานข้อผิดพลาด-1019 (JET_errPageNotInitialized) เมื่อเพจที่จะคาดว่าจะไม่ใช้กำลังเตรียม หรือว่างเปล่า ถ้าเขตข้อมูลหมายเลขหน้าบนเพจที่ใช้งานอยู่คือ 0x00000000 มีข้อผิดพลาด-1019 มีรายงานแทนที่เป็นของมีข้อผิดพลาดการ-1018 ถึงแม้ว่าหน้ายังอาจล้มเหลวของการทดสอบ checksum

วิธีการแก้ไขข้อผิดพลาดในการ-1019 เป็นเหมือนเมื่อต้องการแก้ไขข้อผิดพลาดในการ-1018 โปรดสังเกตว่า ประเด็นที่-1019 อาจไปตรวจไม่พบอีกต่อไปไม่ใช่ประเด็น-1018 เนื่องจากไม่พบปัญหาเกี่ยวกับ-1019 โดยการสำรองข้อมูลออนไลน์

ถึงแม้ว่าสาเหตุหลักของการเกิดข้อผิดพลาดของ-1018 เป็นมากน่าจะอยู่ภายนอกของอัตราแลกเปลี่ยน มีข้อผิดพลาด-1019 อาจเกิดจากอัตราแลกเปลี่ยนถ้าตัวชี้แบบลอจิคัลหรือการเชื่อมโยงระหว่างเพจต่าง ๆ จะไม่ถูกต้อง

อย่างไรก็ตาม เป็นหลักปฏิบัติทั่วไปว่า มีข้อผิดพลาดในการ-1019 เกิดขึ้นเนื่องจากระบบแฟ้มได้รับความเสียหาย หรือได้รับการแมปเพลงในแฟ้มฐานข้อมูลที่ไม่อยู่ในแฟ้ม

การกู้คืนจากข้อผิดพลาดในการ-1022

ถ้าอัตราแลกเปลี่ยนถามคุณว่า ระบบปฏิบัติการสำหรับเพจในฐานข้อมูล และมีข้อผิดพลาดเกิดขึ้นแทนที่เป็นของหน้าข้อมูลที่ส่งคืน ข้อผิดพลาด-1022 (JET_errDiskIO) ผลลัพธ์ ข้อผิดพลาด-1022 มีข้อผิดพลาดทั่วไปที่ปรากฏเมื่อใดก็ ตามดิสก์การรับเข้า/ส่งออก (I/O) ปัญหาทำให้ไม่สามารถแลกเปลี่ยนเข้ามายังหน้าที่ร้องขอในฐานข้อมูล

เหตุผลกันทั่วไปสำหรับข้อผิดพลาดในการ-1022 เป็นแฟ้มฐานข้อมูลที่ได้รับความเสียหายอย่างร้ายแรง หรือตัดทอน หากปัญหานี้เกิดขึ้น อัตราแลกเปลี่ยนร้องขอหมายเลขหน้าที่มีขนาดใหญ่กว่าจำนวนเพจที่อยู่ในแฟ้มฐานข้อมูล และมีข้อผิดพลาด-1022 ผลลัพธ์ ปัญหานี้สามารถเกิดขึ้นได้เนื่องจากปัญหาในระบบแฟ้มด้าน หรือเนื่องจาก การ replay ล็อกของธุรกรรมที่ไม่เหมาะสม

Exchange 2000 ประกอบด้วยการป้องกันที่ครอบคลุมเพื่อป้องกันการ replay ล็อกธุรกรรมที่อาจให้การฐานข้อมูลเป็นอันตรายต่อได้ แต่ใน Exchange Server 5.5 มันเป็นไปได้เมื่อต้อง การเล่นชุดสมบูรณ์ของไฟล์บันทึกของฐานข้อมูลที่ทำให้เสียหาย ตัวอย่างเช่น ปัญหานี้อาจเกิดขึ้นหาก replay ควรเริ่มต้นจากล็อก 9 แต่แทน replay ถูกบังคับให้เริ่มการทำงานจากล็อก 10 อาจถูกบังคับ replay ถ้าผู้ดูแลระบบลบจุดตรวจสอบแฟ้มและแฟ้มบันทึกที่ 9 หากทรานแซคชันในแฟ้มบันทึกที่ 9 ขยายขนาดของฐานข้อมูล แต่ไม่มีเล่นแฟ้มบันทึก 9 ลงในฐานข้อมูล การอ้างอิงในแฟ้มบันทึกที่ 10 ไปยังเพจต่าง ๆ ที่ใหม่ที่ถูกเพิ่มไปยังฐานข้อมูลทำให้มีข้อผิดพลาด-1022 ล้ม เหลว Sudden หยุด (ลอย), และการละเมิดการเข้าถึงได้ด้วยอาการที่พบโดยทั่วไปของ replaying ชุดแฟ้มบันทึกธุรกรรมที่ไม่สมบูรณ์ลงในฐานข้อมูล

ทำความเข้าใจ และการแก้ปัญหาสาเหตุหลักของการเกิดข้อผิดพลาดของ-1022 คือมีความซับซ้อนมากกว่าการแก้ปัญหาสำหรับข้อผิดพลาดที่-1018 หรือ-1019 ถ้าข้อผิดพลาดที่เกิดจากความเสียหายของฐานข้อมูลในระบบไฟล์ คุณจำเป็นต้องตรวจสอบ หรือซ่อมแซมระบบแฟ้ม แล้ว คืนค่าอัตราแลกเปลี่ยนจากการสำรองข้อมูล ถึงแม้ว่าจะซ่อมแซมฐานข้อมูลยังคงเป็นตัวเลือก การซ่อมแซมคือน้อยน่าจะสำเร็จกว่า มีข้อผิดพลาดอื่น ๆ เนื่องจากมีข้อผิดพลาด-1022 สัญญาณเสียหายบ่อยครั้ง

สุดเหตุผลกันทั่วไปสำหรับข้อผิดพลาด-1022 กับฐานข้อมูลที่ไม่เสียหายมีโปรแกรมประยุกต์อื่นเปิดแฟ้มค้างไว้ และทำให้สามารถเก็บข้อมูลบริการจากการเข้าถึงแฟ้มเหล่านั้น ในกรณีเช่น คุณอาจเห็นข้อผิดพลาด-1032 (JET_errFileAccessDenied) เริ่มระบบใหม่ทั้งหมดของบริการ Exchange หรือเซิร์ฟเวอร์การเริ่มระบบใหม่อาจลบล็อก

โปรแกรมของบริษัทอื่น เช่นโปรแกรมสแกนไวรัส อาจบล็อกการเข้าถึงการแลกเปลี่ยนเพื่อแลกเปลี่ยนข้อมูล กำหนดค่าโปรแกรมสแกนไวรัสระดับไฟล์เมื่อต้องการแยกแฟ้มข้อมูลอัตราแลกเปลี่ยนจากการดำเนินการที่ทำการสแกนแฟ้มเสมอ โปรแกรมสแกนไวรัสหลายพร้อมที่ใช้ประโยชน์จากการแลกเปลี่ยนไวรัสที่การสแกนอินเทอร์เฟซเขียนโปรแกรมประยุกต์ (API) เพื่อสแกนข้อความและสิ่งที่แนบมาในเก็บข้อมูล

การวิเคราะห์ข้อผิดพลาด-1018 และ-1019

ข้อมูลในส่วนนี้มีไว้เป็นหลักสำหรับการสนับสนุนด้านเทคนิค และบุคลากรผู้ขายที่เกี่ยวข้องในรากทำให้เกิดการวิเคราะห์

หลังจากที่ผู้ดูแลค้นหาข้อผิดพลาดที่-1018 หรือ-1019 ผู้ดูแลต้องทราบว่าสิ่งที่น้อยสาม:
  • สิ่งที่มีอยู่บนเพเสียหาย
  • โอกาสของการซ่อมแซมเสร็จเรียบร้อยแล้วคืออะไร
  • สิ่งที่ทำให้เกิดความเสียหายในครั้งแรก
-1018 และ-1019 ข้อผิดพลาดอาจเกิดขึ้นที่บรรทัดคำสั่งเมื่อเริ่มบริการ ในแฟ้มบันทึกเหตุการณ์ของโปรแกรมประยุกต์ หรือเอาพุตของโปรแกรมอรรถประโยชน์แลกเปลี่ยนเช่นคำสั่ง Eseutil ไม่อาจจะรายงานข้อผิดพลาด-1018 ในแฟ้มบันทึกเหตุการณ์ของโปรแกรมประยุกต์เมื่อคุณเรียกใช้การตรวจสอบความสอดคล้องของฐานข้อมูลด้วยการ Eseutil /G คำสั่ง ในสถานการณ์นี้ มีแนวโน้มว่า หน้าไม่ถูกต้องว่างเปล่า

ในกรณีส่วนใหญ่ ข้อผิดพลาดจะรายงานในแบบฟอร์มที่ช่วยให้คุณสามารถระบุเพจที่มีการรายงานปัญหา นอกจากนี้คุณยังสามารถสแกนฐานข้อมูลทั้งหมด ด้วย Esefile เพื่อระบุเพจที่ไม่ถูกต้อง สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Esefile คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
248406Esefile ยูทิลิตี้การสนับสนุนสำหรับ Exchange Server 5.5 และ Exchange 2000
ตัวอย่างต่อไปนี้เป็นคำอธิบายข้อผิดพลาด-1018 โดยทั่วไปจากแฟ้มบันทึกเหตุการณ์ของโปรแกรมประยุกต์สำหรับแลกเงิน พร้อมด้วยการวิเคราะห์รายละเอียดข้อผิดพลาดแต่ละรุ่นต่าง ๆ
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.
					
ในตัวอย่างก่อนหน้านี้ คุณสามารถแปลหมายเลขในวงเล็บเป็นดังนี้:
  • (1:3106 1:3106) หมายถึงหน้าในฐานข้อมูลที่ถูกร้องขอ (หน้า 3106), และหมายเลขหน้าที่แท้จริงแล้วมีพบเขียนบนหน้า (หน้า 3106) 1: บ่งชี้ว่า นี่เป็นฐานข้อมูล 1 ซึ่งเป็นแฟ้ม Priv.edb สำหรับ Exchange Server 5.5 ฐานข้อมูล 2 คือ Pub.edb
  • (0-310013) แทน dbtime ค่าที่ถูกเขียนลงบนเพจ ที่ dbtime ค่าคือ ค่าแบบ 64 บิตที่ถูกเขียนลงบนแต่ละเพจที่ correlates อย่างคร่าว ๆ กับระยะเวลาดังกล่าวได้เนื่องจากมีการเปลี่ยนแปลงหน้า
  • (0-312215) หมายถึงปัจจุบัน dbtime ค่าสำหรับฐานข้อมูลทั้งหมด: มีแนวโน้ม dbtime ค่าจะต้องเขียนหน้านี้ถ้ามีการเปลี่ยนแปลงหน้าในขณะนี้ ที่ dbtime ค่าที่มีอยู่แล้วบนหน้าเสมอควรมีขนาดเล็กกว่าปัจจุบัน dbtime ค่า
Given ให้หมายเลขหน้าถูกอ่านได้อย่างถูกต้องจากหน้า และ dbtime ค่าที่มีความเหมาะสม (กับครั้งแรก dbtime มูลค่าต่ำกว่าที่สอง), เพจนี้ถูกไม่ถูกแทนทั้งหมดที่ มีเพจจากภายนอกฐานข้อมูลหรือหน้าที่ที่แตกต่างกัน

คุณสามารถใช้ Esefile ในการแสดงผลหน้าตัวเอง ด้วยคำสั่งที่คล้ายกับข้อความต่อไปนี้:
Esefile /d database.edb 3106 > 3106.txt
เนื่องจากเพจนี้ปรากฏเป็นสภาพเดิมที่เกี่ยวข้องกับโครงสร้าง คุณอาจยังสามารถใช้คำสั่ง Eseutil เพื่อดูข้อมูลเพิ่มเติมแบบลอจิคัลที่เกี่ยวกับหน้า คุณสามารถใช้คำสั่ง Eseutil รุ่น Exchange 2000 ได้เมื่อต้องการดูข้อมูลโครงสร้างหน้าจากฐานข้อมูลทั้ง Exchange 2000 และ Exchange Server 5.5

คำเตือน อย่าใช้ Exchange 2000 รุ่น Eseutil เทียบกับฐานข้อมูลที่มี Exchange Server 5.5 ในโหมดใด ๆ เขียนไปยังฐานข้อมูล เมื่อต้องการจะเซฟ ใช้เฉพาะ /M สวิตช์ และไม่เคยใช้ /P, /Gหรือ /R. นอกจากนี้ ไม่ต้องคัดลอก Exchange 2000 รุ่นหน้าจอพร้อมและ Ese.dll กับคอมพิวเตอร์มี Exchange Server 5.5 การคัดลอกแฟ้มเหล่านี้ไปยังเซิร์ฟเวอร์ระยะไกลแทน และใส่เส้นทางแบบแผนการตั้งชื่อสากล (UNC) บรรทัดคำสั่งอย่างชัดเจนไปยังฐานข้อมูลที่คุณกำลังตรวจสอบ

คำสั่งที่คล้ายกับคำสั่งต่อไปนี้แสดงผลข้อมูลแบบลอจิคัลสำหรับเพลงในแฟ้มข้อความ:
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
จากผลลัพธ์นี้ คุณสามารถดูได้ว่า เพจนั้นเป็นเพใบไม้ ซึ่งหมายความ ว่า มีข้อมูลที่แท้จริงนั้น ถ้าคุณซ่อมแซมฐานข้อมูลนี้ การซ่อมแซมจะมีผลขาดทุนของน้อยข้อมูลนี้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการค้นหาตารางหรือกล่องจดหมายที่เพจนั้นเป็นสมาชิกใด คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
262196วิธีการตรวจสอบที่กล่องจดหมายใดเป็นเจ้าของหน้าใดหน้าหนึ่งในฐานข้อมูล
ถ้าผลลัพธ์ Eseutil รายการหน้าใบไม้สำหรับหน้า โอกาสที่ซ่อมแซมจะ ทำงานอย่างสมบูรณ์ได้สูง มากที่สุดภายใน หรือแบบมีโครงสร้างหน้าสามารถถูกสร้างขึ้นอย่างสมบูรณ์ใหม่ตามกระบวนการซ่อมแซม

แสดงผลอาจยังแสดงนี้เป็น "หน้าที่ว่าง ในกรณีนี้ การจัดเรียงข้อมูลแบบออฟไลน์จะละทิ้งหน้าไม่ถูกต้องจากฐานข้อมูล

อย่าลืมว่า ถ้าเพจที่ถูกอย่างสมบูรณ์แทน ด้วยบล็อกของข้อมูลที่ไม่ได้เป็นของในแฟ้มฐานข้อมูล การเอาพุ Eseutil อาจไม่มีความหมาย

ข้อผิดพลาดต่อไปนี้คือ ตัวอย่างอื่น:
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.
ในตัวอย่างนี้ หมายเลขหน้าจริง ๆ อ่านจากหน้า (3688618971) ไม่ตรงกับเพจที่ร้องขอ ซึ่งหมายความ ว่า พื้นที่หัวกระดาษหน้าที่จัดเก็บหมายเลขหน้าเสียหาย Probable ว่า หมายเลขหน้าไม่มีแม้แต่อยู่ในฐานข้อมูลได้ เพื่อตรวจสอบว่า เป็นกรณีนี้ คูณเลขหน้า ด้วย 4,096 และการเปรียบเทียบตัวเลขนั้นเป็นขนาดไบต์ของแฟ้มฐานข้อมูลแล้ว ในกรณีนี้ หมายเลขหน้าไม่น่าเป็นชนิดหนึ่งที่อัตราแลกเปลี่ยน เขียนไว้ตั้งแต่ต้นว่านอกจากฐานข้อมูลเป็น terabytes 15 ในขนาด (3,688,618,971 x 4,096 = 15,108,583,305,216)

นอกจากนี้ ขอให้สังเกตที่แรก dbtime ค่าทำซ้ำรูปแบบหมายเลขหน้าอย่างแน่นอน ถ้าคุณแปลง 3688618971 ให้เป็นเลขฐานสิบหก (ใช้ Calc.exe ในโหมดของวิทยาศาสตร์), มันกลายเป็น 0xDBDBDBDB ใน Exchange 2000 และ Exchange Server 5.5, 8 ไบต์ dbtime ค่าถูกเก็บไว้หลังจากค่าหมายเลขหน้า 4 ไบต์ เนื่องจากการนี้ คุณทราบว่า น้อย 12 ไบต์ต่อเนื่องสำหรับเขตข้อมูลที่แตกต่างกันสองถูกเขียนทับ ด้วยลวดลายที่เฉพาะเจาะจง ถ้าคุณใช้ Esefile ในการดูเพจนี้โดยตรง คุณอาจจะค้นพบว่า หน้าทั้งหมดถูกเขียนทับ ด้วยลวดลาย 0xDB ลวดลายไบต์ไม่ถูกต้องบ่อยครั้ง seen อื่นคือ 0xFF ถ้านี้เกิดขึ้นในกรณีสำหรับข้อผิดพลาดข้างต้น การ dbtime ค่าจะต้องเป็น 4294967295

ข้อผิดพลาดต่อไปนี้แสดงรายละเอียดของหน้ากระดาษ เป็นออฟเซตของไบต์ลงในแฟ้ม ไม่เป็นไป ตามหมายเลขหน้า:
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.
					
คุณสามารถแปลงออฟเซตที่แรกไปยังหมายเลขหน้าได้ โดยการเอาเลขศูนย์ที่ต่อท้ายสาม การลบ 1 และการแปลงผลลัพธ์ไปที่เลขฐานสิบ ในตัวอย่างนี้ 0x00000000000db - ไว้คือ 218 1 = 0xda = ตัวเลขทศนิยม คุณสามารถใช้หมายเลขฐานสิบหน้านี้ได้ ด้วยการ Esefile หรือคำสั่ง Eseutil

หมายเหตุ คุณลบเพียง 1 แทนที่เป็นของ 2 การบัญชีสำหรับหัวข้อที่สองหน้าในฐานข้อมูลได้เนื่องจากการปรับค่าเริ่มต้นในการตรวจนับที่ 0x0 แทนของ 0x1 ถ้าคุณต้องการตรวจสอบเพจต่าง ๆ ของหัวข้อที่ มี Esefile หรือคำสั่ง Eseutil อ้างอิงหน้า -1 และหน้า 0

จริง ๆ กับหัวข้อการแลกเปลี่ยนฐานข้อมูลต้องมีหน้ากระดาษเดียวเท่านั้น หน้าที่สองคือ สำเนา "เงา" ของหัวข้อ Checksums ที่มีรายงานเมื่อคุณใช้การ Esefile /D ฟังก์ชันการถ่ายโอนข้อมูลหน้าควรจะเสมอเหมือนกันสำหรับหน้า -1 และ 0 หลังจากฐานข้อมูลถูกปิดลงสตรี ถ้าหัวข้อที่ถูกเขียนขึ้นเมื่อระหว่างระบบล้มเหลว แลกเปลี่ยนใช้การคัดลอกหัวข้อที่ มี checksum ที่สะอาดเมื่อรีสตาร์ท Exchange

ดำเนินการต่อไป ด้วยตัวอย่างก่อนหน้า checksums อยู่จริงมากใกล้กัน แตกต่างกันในสองเฉพาะอักขระ เมื่อ checksums กำลังปิด นี้บ่งชี้ว่า การเปลี่ยนแปลงบนหน้ากระดาษได้น้อยที่สุด: เดียวเท่านั้นที่อาจเกิดข้อผิดพลาดที่บิต มันเป็นไปได้ว่า หน้านี้ยังคงประกอบด้วยเพียงพอของโครงสร้างของทางตรรกะเพื่อให้คุ้มค่ากับการวิเคราะห์ด้วย Eseutil /P การ /M.

Checksum ที่คาดไว้ในข้อความแสดงข้อผิดพลาดถูกนับที่จะอ่านจากหน้าจริง ๆ หน้าที่อยู่ในขณะนี้ในฐานข้อมูล Checksum ที่แท้จริงในข้อความแสดงข้อผิดพลาดถูกนับที่อัตราแลกเปลี่ยนแบบไดนามิก re-calculates เป็นโปรแกรมอ่านหน้า

ถ้านับจริงบนเพ 0x89abcdef หน้าประกอบด้วยอักขระทั้งหมดของ 0x00 ถ้านับที่แท้จริงคือ 0x76543210 เพจนี้ประกอบด้วยอักขระ 0xFF ทั้งหมด

ตัวอย่างต่อไปนี้จะมีข้อผิดพลาด-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.
					
ในระหว่างการดำเนินงานโดยทั่วไป ถ้าเพจที่สามารถรายงานข้อผิดพลาดในการ-1019 หรือมีข้อผิดพลาดการ-1018 ข้อผิดพลาด-1019 มีระดับความสำคัญ และมีรายงาน อย่าลืมว่า มีข้อผิดพลาดในการ-1019 เกิดขึ้นเมื่อใดก็ ตามที่หมายเลขหน้าถูกเขียนลงบนเพจคือ 0x00000000 แต่แลกเปลี่ยนคาด page เพื่อที่จะใช้งานอยู่ ดังกล่าวอาจเป็นเรื่องยากเพื่อพิสูจน์ ว่ามีข้อผิดพลาด-1019 เกิดขึ้นเนื่องจากระบบแฟ้มได้รับการแมปบล็อกของเลขศูนย์ลงในแฟ้มฐานข้อมูล หรือเนื่อง จากอัตราแลกเปลี่ยนทำรูปผิด และการอ้างอิงในเพจที่ไม่ได้ใช้งานเป็น "ในใช้

คุณไม่สามารถบอกจากข้อผิดพลาดก่อนหน้านี้ ว่าเพจนั้นก็จะเตรียม หรือ ในบางสถานะ คุณต้องใช้ Esefile และคำสั่ง Eseutil เพื่อเพิ่มเติม ให้ตรวจสอบหน้า ในตัวอย่างนี้ หมายเลขหน้าถูก 408 เลขฐานสิบ (ที่ได้รับมาจาก 0x199)

คุณสามารถใช้คำสั่ง Eseutil เพื่อเพิ่มเติม ให้ตรวจสอบหน้า ที่ pgnoThis ค่าควรตรงกับหมายเลขหน้าที่ถูกสอบถาม และ ulChecksumParity ค่ารายงานเพิ่มเติม ** checksum คำนวณ ค่าถ้านับจากหน้าไม่ถูกต้อง คุณสามารถใช้ Esefile /D สลับการดูเพ raw เพื่อตรวจสอบว่า เป็นเตรียม (ทั้งหมด 0x00 อักขระ)

ข้อผิดพลาด-1018 false

มีข้อผิดพลาด "false"-1018 เกิดขึ้นเมื่อหน้าบนดิสก์ไม่ถูกต้อง แต่ระบบ I/O จะดึงข้อมูลไม่ถูกต้อง ข้อผิดพลาดเช่นมัก transient และยากที่จะแยก แต่แม้แต่เป็น "เท็จ" -1018 พลาด deserves ความสนใจที่ร้ายแรง ยังคงมีละเมิดความเชื่อถือของระบบจัดเก็บข้อมูล และระบบอาจอยู่ในดิจิทัลของปัญหาอื่น ๆ หรือความล้มเหลว

หากคุณสงสัยว่าข้อผิดพลาดการอ่าน transient ในระบบของคุณ ใช้ Esefile /D สลับ หรือ Eseutil /P การ /M เมื่อต้องการตรวจสอบแต่ละเพจที่เกี่ยวข้อง ถ้าคุณใช้โปรแกรมอรรถประโยชน์อย่างใดอย่างหนึ่งเพื่อสแกนฐานข้อมูลทั้งหมด คุณต้องใส่ต้องระบบ I/O ที่อาจส่งผลให้ทำเพิ่มเติม false

Exchange Server 5.5 Service Pack 2 (SP2) เพิ่มฟังก์ชันการทำงานเพื่อช่วยระบุข้อผิดพลาดการอ่าน transient อัตราแลกเปลี่ยน re-reads หน้า 16 ครั้งหลังจากความล้มเหลวในการตรวจสอบที่อ่าน ถ้าหน้าการอ่านเพี้ยนสำเร็จหลังจากพยายามเข้าสู่หลาย บ่งชี้ว่า เป็นประเด็นที่ระบบในการอ่านจากดิสก์เชื่อถือ แม้ว่าอ่าน 16 ทั้งหมดล้มเหลว มันไม่ conclusively พิสูจน์ว่า เพจนั้นก็จะไม่ถูกต้อง ทำการทดสอบที่รองกับ Esefile หรือคำสั่ง Eseutil

Zeroing ในฐานข้อมูล

ฐานข้อมูล zeroing มีวัตถุประสงค์เพื่อบดบังถูกลบข้อมูลในฐานข้อมูลที่มีอัตราแลกเปลี่ยนเพื่อให้มันไม่สามารถกู้คืน หรืออ่านได้ โดยการตรวจสอบแฟ้มฐานข้อมูลโดยตรง สำหรับข้อมูลเพิ่มเติมเกี่ยวกับฐานข้อมูล zeroing คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
223161ข้อมูลเกี่ยวกับ ESE zeroing
ถ้า zeroing ในฐานข้อมูลถูกเปิดใช้งาน ส่วนของหน้าว่างเปล่า หรือว่างเปล่าเป็นบางส่วนอาจถูกเขียนทับ ด้วยลวดลายของอักขระเฉพาะ แต่หน้าจะยังคงไม่กลับไปยังสถานะเตรียม

คุณสมบัติ

หมายเลขบทความ (Article ID): 314917 - รีวิวครั้งสุดท้าย: 24 พฤษภาคม 2554 - Revision: 1.1
ใช้กับ
  • 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
Keywords: 
kbinfo kbmt KB314917 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:314917

ให้ข้อเสนอแนะ

 

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