ทรัพยากรสำหรับ DBA โดยไม่ตั้งใจ [ปิด]

ภายในแพลตฟอร์ม Microsoft โปรแกรมระดับองค์กรส่วนใหญ่ (SharePoint, แอป System Center ใด ๆ , แอป Dyamics ใด ๆ ฯลฯ ) ทั้งหมดทำงานบน SQL Server สำหรับผู้ดูแลระบบของโปรแกรมเหล่านี้ SQL Server มักจะมีกล่องดำที่ติดตั้งเป็นข้อกำหนดเบื้องต้นสำหรับโปรแกรมใดก็ตามที่เป็นจุดสนใจหลัก เป็นผลให้มีการวางแผนน้อยมาก (ถ้ามี) ที่เข้าสู่ด้าน SQL ของการติดตั้งซึ่งนำไปสู่ปัญหาที่เกิดขึ้นที่ใดที่หนึ่งบนต้นน้ำ

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

ดังนั้น ... ปัญหาประเภทใดที่ "DBA ที่ไม่ตั้งใจ" มีแนวโน้มที่จะได้รับผลกระทบและทรัพยากรใดบ้างที่จะช่วยให้ DBA ที่เกิดขึ้นไม่ได้ตั้งใจเพิ่มความเร็วในการวางแผน SQL การจัดการและการปรับแต่งประสิทธิภาพพื้นฐาน

ชำระเงินชุดบทความและคอลัมน์ถามตอบที่ฉันเขียนให้กับนิตยสาร TechNet - ส่วนใหญ่เขียนด้วย Accidental (เราเรียกว่า DBA โดยไม่สมัครใจ) DBA

เคล็ดลับยอดนิยมสำหรับการบำรุงรักษาฐานข้อมูลที่มีประสิทธิภาพถูกเขียนขึ้นเป็นพิเศษสำหรับ DBA โดยไม่สมัครใจเพื่อทำความเข้าใจปัญหาการบำรุงรักษาฐานข้อมูล

ทำความเข้าใจเกี่ยวกับการบันทึกและการกู้คืนใน SQL Server

ปัญหาและวิธีแก้ไขปัญหาความปลอดภัยของเซิร์ฟเวอร์ SQL ทั่วไป

ทำความเข้าใจกับการสำรองข้อมูล SQL Server - ตอนที่ 1 ของซีรี่ส์ 3 ส่วน ส่วนที่ 2 จะใช้การกู้คืน (ในปัญหา 09 ก.ย. ) และส่วนที่ 3 จะทำการกู้คืนโดยไม่มีการสำรองข้อมูล (ในปัญหา พ.ย. 09)

คุณควรเช็คเอาต์บล็อกของฉันและบล็อกภรรยาของฉัน (ไม่ใช่การโฆษณาหรือข้อมูลใด ๆ ) - เราทั้งบล็อกเป็นจำนวนมากในระดับเทคนิคที่หลากหลาย

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

เราเข้าใจสิ่ง DBA โดยไม่สมัครใจจริง ๆ แล้วอันที่จริง Kimberly และฉันสอนสองสามวันของชั้นเรียน Microsoft Certified Certified ของ Microsoft SharePoint ดังนั้นผู้ดูแล SharePoint รู้ว่าจะทำอย่างไรกับเซิร์ฟเวอร์ SQL ของพวกเขา (เรายังสอน SQL หนึ่งสัปดาห์เต็มด้วย) .

หวังว่านี่จะเป็นประโยชน์กับคุณ

ฌอนฉันเข้าใจว่าคุณมาจากไหน

เราอยู่ในเรือลำเดียวกันที่นี่อย่างที่ฉันคาดหวังว่าจะมีอีกหลายคน ไม่ทนต่อเศรษฐกิจในปัจจุบัน

แม้จะมีการร้องเรียนซ้ำ ๆ เกี่ยวกับการจัดการ (รวมถึงการจัดการธุรกิจระดับสูง) สถานการณ์ของเราคือ "DBA" ที่ได้รับการแต่งตั้งด้วยตัวเอง (แยกกัน, `ทีมพัฒนา 'บนอีกชั้นหนึ่ง) น่าเสียดายที่รู้น้อยกว่าผู้อยู่ใต้บังคับบัญชาหนังสือโอเรลลีสองเล่มและการถ่ายโอนข้อมูล KB เธอมีงานทำและยอดเยี่ยมในการเทน้ำผึ้งลงไปในหูของคนที่เทน้ำผึ้งลงในหูของโคลนที่ใหญ่ที่สุด

แน่นอนว่ามันจะเหมาะอย่างยิ่งที่จะสามารถเรียนรู้ DBA "การค้า" แต่อีกครั้ง .. สิ่งที่เราต้องการและสิ่งที่เราสามารถมีได้มักแตกต่างกันมาก :)

ฉันโดยส่วนตัวได้พบกับปัญหาต่อไปนี้ซึ่ง (เพื่อสะท้อนเสียงทุ้มของ squillman แต่ไม่ถูกต้องทั้งหมด) ไม่ต้องการ googling มาก

• Tranlogs คุณถูก. ห่าเป็นอะไรพวกนี้เหรอ? ดังนั้นเราต้องกู้คืนฐานข้อมูลและเซิร์ฟเวอร์ `เล่นซ้ำบันทึก tran 'หมายความว่าอย่างไร :)
• เดี๋ยวก่อนคุณหมายถึงอะไรฐานข้อมูลเหล่านี้ใหญ่ขึ้นเรื่อย ๆ ? เราจะลดขนาดพวกเขาได้อย่างไร หรืออย่างน้อยก็รักษาอัตราการเติบโต
• มาตรฐานของการติดตั้งข้ามเซิร์ฟเวอร์ที่แตกต่างกัน (ภาพนี้ใช้สำหรับ "dev" รูปภาพนี้ใช้สำหรับ "prod" และภาพเล็ก ๆ นี้ร้องไห้ตลอดทางกลับบ้านจากตลาด :)
• สคริปต์การบำรุงรักษาและวิธีการจัดการฐานข้อมูลเป็นระยะเวลานาน (ชนิดของ houseplants ที่เพิ่มขึ้นและทำให้แน่ใจว่าพวกเขาจะไม่กลายเป็นคุดสุ)
• ตรวจสอบให้แน่ใจเสมอ proggies ไปที่ C: \, การบันทึกและ / หรือฐานข้อมูลไปที่ D: \, ซึ่งเป็นสูตรมาตรฐานของเรา, (C: \ เป็นดิสก์ที่มิร์เรอร์สองตัว, D: \ มักเป็น RAID5 .)
• ต้องซื้อสิทธิ์ใช้งาน SQL แยกต่างหากและไคลเอนต์สำหรับการสำรองข้อมูล
• ตรวจสอบการจัดการผู้ใช้ว่าทีมพัฒนากำหนดให้กับฐานข้อมูล SQL ของตัวเองจัดการบทบาท DBO และอื่น ๆ ให้แน่ใจว่าคุณมีรูปแบบการรักษาความปลอดภัยที่ดีเมื่อพูดถึงสิทธิ์ของผู้ใช้ในฐานข้อมูล
• วิจัยบัญชีบริการโดเมนที่บริการ SQL สามารถดำเนินการได้เช่น สิทธิ์ใดที่บัญชีบริการต้องการหากมีเลย

(คุณได้โพสต์ข้อความดีๆในโพสต์ของคุณ)

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

อย่างไรก็ตามเหนือสิ่งอื่นใดลองใช้มารเพื่อรับ DBA กับเจ้าหน้าที่ :)

ฉันได้รับตำแหน่ง DBA guy ประมาณปีหนึ่งในงานของฉัน ประมาณ 5 เดือนที่แล้ว ตั้งแต่นั้นมาผมได้รับการอ่านบล็อกต่างๆจาก 500,000 ฟุตดูไป (บางครั้งตีดาดฟ้ายากที่ 500 ฟุต) 250,000 มุมมองไปที่ มุมมอง 500 ฟุต นอกจากนี้SQLServerPediaยังเป็นเพื่อนของคุณ พวกเขามีสิ่งที่ดีมากมายสำหรับ DBA โดยไม่ได้ตั้งใจ

ฉันถูกโยนลงไปในสถานการณ์ที่ทำให้ฉันรู้สึกไม่สบายใจ ตัวอย่างเช่นฉันทำการสำรองข้อมูลตั้งแต่ฉัน“ ได้รับ” งานนี้ดังนั้น Fulls, diffs และ t-log ก็อยู่ในมือสำหรับการกู้คืนข้อมูลการผลิตครั้งแรกของฉันไม่มีใครดูเหมือนตกใจเลยดังนั้นฉันจึงคิดว่าฉันไม่สามารถแสดงได้ ฉันรู้สึกอย่างไร หลายครั้งมากกว่าที่ฉันจะลงน้ำเมื่อฉันใส่หมวก DBA ของฉัน แต่ฉันคิดว่ามันไม่ใช่งานเต็มเวลาของฉัน (ผู้ดูแลระบบเครือข่าย) ดังนั้นฉันควรจะปลอดภัยกว่าขอโทษด้วย

เคล็ดลับยอดนิยมสำหรับการบำรุงรักษาฐานข้อมูลที่มีประสิทธิภาพ

เริ่มต้นด้วยความพยายามทางยุทธวิธี หากฐานข้อมูลของคุณหยุดทำงานหรือทำงานไม่ดีให้มุ่งเน้นที่การแก้ไขปัญหาเหล่านั้น

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

หากคุณไม่มีฮาร์ดแวร์เพื่อทดสอบการเปลี่ยนแปลงที่สำคัญและสิ่งต่าง ๆ เช่นการสำรองข้อมูล / เรียกคืน - หาวิธีการรับ

เมื่อฉันจ้าง Junior DBA ฉันซื้อ Companion ของผู้ดูแลระบบMicrosoft® SQL Server (TM) 2005 ให้เธอ มันเป็นหนังสือที่ฉันหวังว่าฉันมีเมื่อฉันเริ่มต้น