แผนการบำรุงรักษาเซิร์ฟเวอร์ SQL - วิธีปฏิบัติที่ดีที่สุดสำหรับงานและการกำหนดตารางเวลา

ฉันได้รับมอบหมายให้วางแผนการบำรุงรักษาสำหรับฐานข้อมูล SQL Server 2005 ของเรา ฉันรู้ว่าสำหรับการสำรองข้อมูลฉันต้องการสำรองข้อมูลฐานข้อมูลเต็มรูปแบบทุกวันและสำรองข้อมูลบันทึกธุรกรรมทุก 15 นาที ปัญหาของฉันมาเพื่อหางานอื่นที่ฉันต้องการทำและความถี่ที่ฉันควรทำ

ดังนั้นฉันจึงมีสิ่งนี้อยู่ในใจ แก้ไขฉันหากมีข้อบกพร่องใด ๆ ในความคิดของฉันหรือวิธีที่ดีกว่าในการทำเช่นนี้

1. สำรองข้อมูล - ตารางทั้งหมดสำรองข้อมูลเต็มรูปแบบ (รายวัน)
2. สำรองข้อมูล - ตารางที่เลือก, สำรองข้อมูลเต็มรูปแบบ (รายชั่วโมง)
3. สำรองข้อมูล - บันทึกธุรกรรม (ทุก 15 นาที)
4. ตรวจสอบความสมบูรณ์ของฐานข้อมูล (รายวัน)
5. จัดระเบียบดัชนีใหม่ (ทุกวัน)
6. อัปเดตสถิติ (ทุกวัน)
7. ย่อขนาดฐานข้อมูล (รายสัปดาห์)
8. สร้างดัชนีใหม่ (ทุกสัปดาห์)
9. การบำรุงรักษาล้าง (ทุกวัน)

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

จอช

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

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

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

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

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

แผนการบำรุงรักษานั้นใช้ได้ แต่ยากที่จะได้รับสิ่งที่ดีที่สุดในการปรับแต่งเหล่านี้เว้นแต่คุณจะสามารถลงชื่อเข้าใช้ SSIS และปรับแต่ง MP ของ นั่นเป็นเหตุผลที่ฉันไม่ต้องการใช้และใช้สคริปต์ฟรีของ Ola Hallengrenที่แข็งแกร่งกว่า MP นอกจากนี้ฉันขอแนะนำให้ติดตามบทความอ้างอิงโดย Paul Randal ในหัวข้อนี้

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

นี่ไม่ใช่คำตอบที่ครอบคลุมสำหรับคำถามของคุณ แต่เป็นจุดเริ่มต้นที่ดี HTH และแจ้งให้เราทราบหากคุณมีคำถาม / ความคิดเห็นเพิ่มเติม

ฉันจะแบ่งปันประสบการณ์ของฉันแม้ว่าคุณจะได้รับคำตอบแล้ว อาจจะเป็นประโยชน์ :-)

1. การสำรองข้อมูลรายวันแบบเต็ม (รายวัน) - ยอดเยี่ยม แต่อย่าลืมตรวจสอบพื้นที่และลบไฟล์เก่าหลังจากเวลาที่กำหนดไว้ล่วงหน้า
2. สำรองตารางที่เลือก (ทุกชั่วโมง) - ไม่เข้าใจว่าทำไมคุณต้องใช้สิ่งนี้คุณควรไปกับการสำรองข้อมูลที่แตกต่างกัน คุณสำรองข้อมูลเฉพาะบางตารางได้อย่างไร: SSIS, สคริปต์, bcp เกี่ยวกับการสำรองข้อมูลต่าง ๆ อย่ากำหนดเวลาบ่อยเกินไปเนื่องจากคุณจะขโมยบทบาทการสำรองข้อมูล
3. สำรองข้อมูลบันทึกธุรกรรม (ทุก ๆ 15 นาที) - เยี่ยมมากคุณแน่ใจหรือว่าต้องการฐานข้อมูลทั้งหมด? ฐานข้อมูลทั้งหมดใช้รูปแบบการกู้คืนเต็มหรือไม่?
4. ตรวจสอบ db integrity - ใช่ แต่คุณต้องแน่ใจว่าคุณไม่ได้ฆ่าสิ่งแวดล้อม คำสั่งตรวจสอบของ DBCC นั้นค่อนข้างเห็นแก่ตัวเกี่ยวกับทรัพยากรและสแกน dbs ที่สมบูรณ์ดังนั้นพวกเขาจำเป็นต้องถูกกำหนดเวลาทำงานนอกเวลางาน
5. จัดระเบียบดัชนีใหม่ (ทุกวัน) - อย่าบังคับให้ทำถ้าจำเป็นเท่านั้น ตรวจสอบดัชนี DMV เกี่ยวกับการแตกแฟรกเมนต์และจัดระเบียบใหม่ตามความต้องการเท่านั้น ฉันจะย้ายการดำเนินการดัชนีและสถิติทั้งหมดในงานสัปดาห์เดียว
6. อัปเดตสถิติ (ทุกวัน) - โปรดดูคำตอบของคำถามก่อนหน้านี้ แทนที่จะบังคับให้อัปเดตสถิติทั้งหมดทุกวันคุณควรตรวจสอบว่ามีการอัปเดตสถิติล่าสุดหรือไม่และในบางกรณีจะอัปเดตสถิติเท่านั้น
7. ลดขนาดฐานข้อมูล (รายสัปดาห์) - โอ้ไม่ โปรดอ่านบทความของ Paul Randal เกี่ยวกับการลดขนาดไฟล์
8. สร้างดัชนีใหม่ (ทุกสัปดาห์) - ดู 5

9. การทำความสะอาดการบำรุงรักษา (ทุกวัน) - ตกลงกับสิ่งนั้น

10. คุณควรเพิ่มงานในการตรวจสอบการสำรองข้อมูลของคุณ - มีคำสั่ง RESTORE เวอร์ชันหนึ่ง (ตรวจสอบเฉพาะ .. หากฉันจำได้ถูกต้อง) - สมมติว่าทุกสัปดาห์ แต่ฉันชอบทุกวัน

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

คำตอบล่าช้า แต่สามารถใช้กับผู้อ่านรายอื่นได้

โปรดทราบว่ามีงานบำรุงรักษาหรือการรายงานจำนวนมากคุณสามารถสร้างที่มีความเสี่ยงที่มองไม่เห็นที่เกี่ยวข้อง

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

พิจารณาว่างานต่าง ๆ มีปฏิสัมพันธ์กันอย่างไรและใช้เวลาในการทำงานที่ไม่ซ้ำซ้อนในงานที่ละเอียดอ่อนหรืองานที่ต้องใช้ทรัพยากรมาก

ฉันขอแนะนำให้อ่านบทความนี้ก่อน: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

มันอธิบายถึงวิธีการทำงานบำรุงรักษาที่สำคัญใน SQL Server - ปราศจากความเสี่ยง ตัวอย่างเช่น - คุณสามารถสร้างการตรวจสอบอย่างง่ายในงานบำรุงรักษาของคุณที่ตรวจสอบทรัพยากรที่มีอยู่รวมถึงสิ่งที่การดำเนินการจะต้องใช้ก่อนที่จะดำเนินการ สิ่งนี้ช่วยให้คุณมั่นใจได้ว่าสภาพแวดล้อมของคุณสามารถจัดการสิ่งที่คุณกำลังจะทำและยกเลิกด้วยข้อผิดพลาดที่มีความหมายหากทรัพยากรไม่เพียงพอ

1. ดูเหมือนว่าดี

2. คุณอาจได้รับประโยชน์จากการสำรองข้อมูลต่างกันที่นี่ มองเข้าไปในพวกเขาอย่างแน่นอน

3. ดูเหมือนว่าดี

4. ดูเหมือนว่าดี

5. ตามที่ระบุไว้ก่อนหน้านี้การลดขนาดฐานข้อมูลไม่ดีเนื่องจากสร้างการกระจายตัวของข้อมูลและไฟล์บันทึกของคุณซึ่งทำให้ IO อ่านแบบสุ่มมากขึ้น

5, 6 และ 8: ดูต่อไปนี้

สิ่งเหล่านี้เข้ากันได้เป็นอย่างดีเนื่องจากดัชนีพึ่งพาสถิติที่ทันสมัยและลำดับของการดำเนินการเหล่านี้ค่อนข้างสำคัญ วิธีการพื้นฐานที่ฉันจ้างซึ่งเป็นที่ยอมรับอาจไม่ได้ผลสำหรับทุกคนคือฉันทำการบำรุงรักษาดัชนีสองรอบ ครั้งแรกฉันทำดัชนีคลัสเตอร์และจากนั้นดัชนี nonclustered วิธีที่ฉันใช้สำหรับทั้งสองวิธีมีดังต่อไปนี้ หากดัชนีมีขนาดใหญ่เพียงพอและมีการแยกส่วนมากพอ (sys.dm_db_index_physical_stats) ฉันจะสร้างดัชนีใหม่ (ซึ่งรวมถึงการอัพเดตสถิติด้วยการสแกนแบบเต็ม) หากดัชนีมีขนาดเล็กเกินไปสำหรับการสร้างใหม่หรือมีการแยกส่วนไม่เพียงพอสำหรับการสร้างใหม่ (น้อยกว่า 100 หน้าและระหว่าง 5% ถึง 15% การกระจายตัวของข้อมูล) ฉันจะทำการจัดระเบียบดัชนีใหม่ก่อน ฉันจะทำการอัปเดตสถิติด้วยการสแกนแบบเต็ม

ตอนนี้ครอบคลุมสถิติดัชนี แต่ไม่สนใจที่จะทำอะไรกับสถิติคอลัมน์ ฉันจะอัปเดตสถิติคอลัมน์ทุกสัปดาห์

ฉันหวังว่านี่จะช่วยได้บ้าง!

ฉันเอียงที่ "การสูญเสียข้อมูลของคุณอาจมีผลประโยชน์ทางกฎหมายที่นี่" ความคิดเห็น

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

มีการสำรองข้อมูลเป็นสิ่งหนึ่ง การรู้วิธีใช้พวกเขาในกรณีฉุกเฉินเป็นอีกเรื่องหนึ่ง

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

ที่ทำงานของฉันฉันสามารถกู้คืน / กู้คืนฐานข้อมูล 350Gb ไปยังจุดใด ๆ ภายในระยะเวลา 5 นาทีสำหรับสัปดาห์ที่แล้วโดยใช้ DPM ด้วยอินเตอร์เฟส GUI มันคุ้มค่าในหนังสือของฉัน

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

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