วิธีการป้องกันไม่ให้บันทึกธุรกรรมเต็มระหว่างการจัดระเบียบดัชนีใหม่


19

เรามีหลายเครื่องที่เราได้จัดสรรขนาดของบันทึกการทำธุรกรรมไว้ที่ 50GB ขนาดของตารางที่ฉันพยายามจัดระเบียบใหม่คือ 55 - 60 gb แต่จะเพิ่มขึ้นอย่างต่อเนื่อง เหตุผลหลักที่ฉันต้องการจัดระเบียบใหม่คือการเรียกคืนพื้นที่และผลประโยชน์ใด ๆ เนื่องจากเป็นโบนัสเพิ่มเติม

ระดับการแตกแฟรกเมนต์ของตารางคือ 30 - 35% ในเครื่องเหล่านี้บางเครื่องฉันได้รับข้อผิดพลาด "transaction log full" และการจัดระเบียบใหม่ล้มเหลว ขนาดบันทึกธุรกรรมสูงสุดถึง 48gb เป็นวิธีที่ดีในการตอบโต้สิ่งนี้คืออะไร? เราไม่ได้เปิดการเพิ่มอัตโนมัติและฉันลังเลที่จะทำเช่นนั้น

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

คำตอบ:


7

วิธีปฏิบัติที่ดีที่สุดคือการREORGANIZEกระจายตัวต่ำกว่าประมาณ 30% และREBUILDสูงกว่านี้ เพียงแค่REBUILDทำสำเนาสะอาดREORGANIZEไม่ได้ในแหล่งกำเนิด

ตรวจสอบสิ่งที่คุณกำลังทำจริง ๆ : คุณไม่มีแผนการบำรุงรักษาที่ทำทั้งสองอย่าง

ในตารางที่ใหญ่กว่า (ตารางกำลังมาถึง 50GB) ฉันเห็นว่าREORGANIZEใช้พื้นที่บันทึกธุรกรรมทั้งหมดหากคุณปฏิบัติตามกฎนี้ ไม่บ่อย: มีเพียงระบบเดียวที่มีรูปแบบการโหลดที่แน่นอน สิ่งที่REORGANIZEเพิ่งดำเนินการจนกระทั่งบันทึกขยายตัวและใช้พื้นที่ดิสก์ทั้งหมด

เราเปลี่ยนไปREBUILDใช้แทนโดยไม่มีปัญหา แต่ให้ละเว้นการกระจายตัวที่ต่ำกว่า 25% สิ่งนี้ใช้ได้ผลดีกว่าสำหรับเรา: คุณจะต้องดูว่ามันเหมาะกับคุณ

REBUILDอาจส่งผลกระทบต่อประสิทธิภาพมากกว่าREORGANIZEในการผลิต แต่บางครั้งสิ่งนี้สามารถบรรเทาลงได้ด้วยONLINEตัวเลือก (จำเป็นต้องมี Enterprise Edition)


ตัวเลขจากกฎของหัวแม่มือและการพูดคุยทั้งในเชิงคุณภาพและเชิงปริมาณมีประโยชน์มาก
Robino

6

REORGANIZE (เหมือนใน ALTER INDEX ... REORGANIZE) เป็นการดำเนินการที่รวดเร็วมาก (ส่วนใหญ่ ... ) ซึ่งต้องการบันทึกจำนวนเล็กน้อยสามารถถูกขัดจังหวะได้ทุกเวลาและกลับมาทำงานในภายหลังในธุรกรรมชุดเล็ก :

การจัดเรียงข้อมูลจะดำเนินการเป็นชุดของธุรกรรมระยะสั้นดังนั้นการบันทึกขนาดใหญ่จึงไม่จำเป็นหากมีการสำรองข้อมูลบันทึกเป็นประจำหรือหากการตั้งค่ารูปแบบการกู้คืนเป็นเรื่องง่าย

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

ดูเหมือนว่าฉันกำลังสร้างใหม่ซึ่งเป็นการดำเนินการที่ยอดเยี่ยมจริงๆคุณไม่ควรทำจนกว่าคุณจะมีเหตุผลที่คิดมาก คุณกำลังเรียกคืนพื้นที่ชนิดใด มีอะไรที่DBCC CLEANTABLEไม่สามารถจัดการได้ คุณได้ตรวจสอบโครงสร้างทางกายภาพของตารางแล้วมันลอยไปจากโครงสร้างแบบลอจิคัล (ดูรายละเอียดในคอลัมน์คอลัมน์ SQL Server ภายใต้ประทุน )

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

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


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

สถานการณ์เดียวกันที่นี่ 2008R2, จัดระเบียบดัชนีใหม่ (ไม่สร้างใหม่) และแม้ในโหมดง่าย ๆ (!) tlog จะเติบโตขึ้นมากกว่าขนาดของตารางที่ใหญ่ที่สุดซึ่ง> 40 GB เมื่ออยู่ในโหมดการกู้คืนเต็มรูปแบบการทำสำเนาสำรอง 5 นาทีจะไม่ช่วยอย่างใดอย่างหนึ่งไฟล์สำรอง TRN ขนาดใหญ่เพียงไฟล์เดียวเท่านั้นที่ถูกสร้างขึ้นในระหว่างการจัดทำดัชนีใหม่ ดูเหมือนจะไม่สมเหตุสมผล แต่เป็นพฤติกรรมเดียวกันกับเซิร์ฟเวอร์ที่แตกต่างกันสองตัว ความคิดใด ๆ วิธีการจริงแยกนี้ในการทำธุรกรรมชุดเล็กเป็นเอกสาร?
realMarkusSchmidt

5

ฉันเคยมีปัญหานี้มาก่อน

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

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

นี่คือสิ่งที่คุณทำ มันค่อนข้างยาว แต่ตรงไปตรงมา

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

    • วัตถุ: SQLServer: ฐานข้อมูล
    • ตัวนับ: เปอร์เซ็นต์การบันทึกที่ใช้
    • อินสแตนซ์: (ชื่อฐานข้อมูลขนาดใหญ่ของคุณ)
    • แจ้งเตือนหากตัวนับเพิ่มขึ้นด้านบน: 80
    • การตอบสนอง: ดำเนินการงาน ('จัดระเบียบเช็คใหม่')
  • สร้างงาน ('จัดระเบียบเช็คใหม่')

    • ในการตรวจสอบงาน msdb.dbo.sysjobactivity เพื่อดูว่างาน 'จัดระเบียบใหม่' กำลังทำงานอยู่หรือไม่ และถ้าเป็น ...
    • หยุดงานและสำรวจความคิดเห็นจนกว่าจะหยุด อาจใช้เวลาสองสามวินาที
    • (หากคุณอยู่ในโหมดเต็มรูปแบบ) ทริกเกอร์งานสำรองข้อมูลบันทึกของคุณและยืนยันเมื่อเสร็จสิ้น
    • ตรวจสอบ sys.dm_os_performance_counters อีกครั้งว่าตัวนับพื้นที่ว่างสำหรับบันทึกของคุณลดลงต่ำกว่าขีด จำกัด ของคุณ
    • เริ่มงาน 'จัดระเบียบใหม่'
  • ทดสอบสิ่งเหล่านี้ได้จากที่ไหนสักแห่งแม้แต่แซนด์บ็อกซ์สำหรับการพัฒนาเพื่อให้แน่ใจว่ามันทำงานได้อย่างถูกต้องก่อนที่จะนำไปใช้กับเซิร์ฟเวอร์ที่ใช้งานจริงของคุณ

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

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

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

ตราบใดที่มันปลอดภัยตรรกะทดสอบและมีเอกสารที่ดีก็ไม่น่าจะมีปัญหา


1

นี่คือสิ่งที่ฉันมักจะทำ (ฉันยังมีตารางไม่กี่ตารางที่มี 80 + GB ขนาดใหญ่แต่ละรายการ) สำหรับดัชนี reorg (เพราะดัชนี reorg สามารถหยุดได้ตลอดเวลาโดยไม่สูญเสียงาน reorg ก่อนหน้านี้)

  1. ในช่วงดัชนีใหม่ฉันจะเพิ่มการสำรองข้อมูล tlog จากความถี่ 30 นาทีปกติของฉันทุก ๆ 10 นาที
  2. ฉันมีเซสชันอื่นที่ทำการตรวจสอบพื้นที่ว่างของ tlog ทุก ๆ 1 นาทีและถ้าพื้นที่ว่างของ tlog ต่ำกว่าขีด จำกัด ฉันจะหยุดเซสชันดัชนี reorg และเริ่ม (หรือรอ) สำรองข้อมูล tlog จากนั้นเริ่มดัชนีใหม่อีกครั้ง

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


1

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

ปัญหาเกิดจากการจำลองแบบของทรานแซคชัน เห็นได้ชัดว่าบันทึกไม่สามารถสำรองได้จนกว่าการREORGANIZEดำเนินการจะเสร็จสิ้น ฉันอ่านบางที่มันเป็นปัญหาที่รู้จักกันโดย Microsoft แต่ฉันไม่แน่ใจว่าอยู่ที่ไหน

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


0

ฉันสมมติว่าคุณกำลังใช้งานบางอย่างตาม:

แก้ไขดัชนีบนการจัดระเบียบใหม่

น่าเสียดายที่ไม่มีวิธีการเรียกใช้การจัดระเบียบบางส่วน (เช่นคุณสามารถย่อขนาดไฟล์ล็อกตัวอย่าง) วิธีที่ฉันสามารถคิดแก้ปัญหานี้คือ:

1) ตั้งค่าฐานข้อมูลเป็นโหมดการกู้คืนอย่างง่ายในขณะที่คุณเรียกใช้การจัดระเบียบใหม่ แต่คุณบอกว่าไม่เป็นที่ยอมรับ

2) แบ่งพาร์ติชั่นดัชนี - ถ้านึกถึงวิธีแบ่งพาร์ติชั่นดัชนีเพื่อให้ได้พาร์ติชั่นที่มีขนาดเท่ากันโดยประมาณคุณจะสามารถจัดระเบียบใหม่ (หรือสร้างใหม่ด้วยออปชั่นออนไลน์) แต่ละพาร์ติชั่นอิสระ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.