แก้ไขข้อมูลฐานข้อมูลการผลิตอย่างปลอดภัย


23

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

  1. เราต้องบันทึกว่าใครเป็นคนค้นหาและสิ่งที่พวกเขาวิ่ง
  2. โดยหลักการแล้วเราจำเป็นต้องให้สิทธิ์การเข้าถึงแก่บุคคลในการเรียกใช้คิวรีกับตารางที่สนใจและเพียงช่วงเวลาสั้น ๆ เท่านั้น
  3. อะไรก็ตามที่กำลังรันเคียวรีจะต้องมีสมาร์ทโฟนบางตัวเพื่อไม่ให้ใช้งานได้นานและล็อค SQL ให้ทำงานโดยไม่ได้รับอนุญาตอย่างชัดเจน
  4. กระบวนการนี้จะต้องเป็นผู้ไม่เชื่อเรื่องพระเจ้า DB หรืออย่างน้อยก็เข้าใจ DB2, Oracle, และ SQL Server

เราพยายามที่จะลดความเสี่ยงของการสืบค้นแบบ ad-hoc prod-up จากการทำสิ่งที่ผิดและในขณะเดียวกันก็เพิ่มความปลอดภัย / audtis ให้กับกระบวนการ ความคิดหรือความคิด?


26
อย่าให้ผู้บริหารคิดว่านี่เป็นขั้นตอนการปฏิบัติงานมาตรฐาน นี่เป็นการผ่าตัดหัวใจแบบเปิดโดยไม่มีหน้ากากหรือถุงมือไม่ใช่วิธีปกติในการจัดการกับข้อบกพร่องที่ควรได้รับการทดสอบ
Dan Pichelman

2
เป็นเพราะคุณต้องการที่จะทำงานในลักษณะนี้ว่าข้อบกพร่องที่เกิดขึ้นในสถานที่แรก
ปฏิกิริยา

7
@MathewFoscarini ที่แสดงความคิดเห็นไม่เพิ่มอะไรเลยในการสนทนา มันก็ผิดที่ฉันไม่เคยพูดว่าฉันต้องการให้สิ่งต่าง ๆ ทำงานด้วยวิธีนี้เท่านั้นที่เรามีข้อควรพิจารณาบางประการที่ต้องเกิดขึ้น คำตอบบางข้อด้านล่างตอบประเด็นทั้งหมดของฉันได้ดี
แอนดรูว์ไวท์

1
@ AndrewWhite คำขอโทษของฉันแอนดรูไม่มีความผิดที่ตั้งใจไว้
ซ้ำ

คำตอบ:


52

ไม่เคยอัปเดตฐานข้อมูลการผลิตด้วยตนเอง

เขียนสคริปต์

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

รวมแบบสอบถามการตรวจสอบหลังการเปลี่ยนแปลงในสคริปต์เหล่านั้น

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

ทดสอบสคริปต์เหล่านั้นกับคลื่นไส้ทดสอบฐานข้อมูล

ทำสำเนาสำรองก่อนที่จะเรียกใช้สคริปต์กับฐานข้อมูลการผลิต

เรียกใช้สคริปต์

ตรวจสอบตรวจสอบและตรวจสอบข้อมูลที่เปลี่ยนแปลงสามครั้งโดยใช้สคริปต์การตรวจสอบหลังการเปลี่ยนแปลง

ทำการตรวจสอบด้วยภาพ

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

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


21
@ แอนดรูว์ไม่มีข้อแก้ตัว: ลืมไปเลยWHEREและฐานข้อมูลของคุณจะไม่ทำงานตลอดทั้งวัน หรือสัปดาห์
CodeCaster

9
@AndrewWhite คุณไม่ถามหาที่ปลอดภัยที่สุดวิธีการแก้ไขข้อมูลไม่ได้เร็วที่สุด :-)
Eric King

9
@AndrewWhite - คุณมีปัญหาแล้ว หากคุณรีบแก้ไขคุณจะพบปัญหาสองอย่างถ้าไม่มากไปและ / หรือคุณอาจทำให้ปัญหาแย่ลงแทนที่จะดีกว่า
Michael Kohne

6
@AndrewWhite - ตรงไปตรงมาว่ามันเป็นกระบวนการที่ไม่สำคัญจะดูเหมือนจะเป็นบวกให้ฉัน ทุกคนจะตระหนักถึงต้นทุนและความเสี่ยงซึ่งต่างจาก "ดีเราเคยทำมาแล้ว 23 ครั้งโดยไม่มีปัญหา" blase-ness ที่ฉันเคยเห็นในหลาย ๆ ที่
DaveE

3
@EricKing: xkcd.com/349
Robin

20

คำตอบของ Marjan Venema นั้นถูกต้องทางเทคนิคและควรปฏิบัติตามเมื่อเป็นไปได้ อนิจจาMarjan ตอบจากมุมมองของนักทฤษฎีหรือผู้ดูแลฐานข้อมูลผู้พิถีพิถันที่ชอบทำสิ่งต่าง ๆ ให้สะอาด ในทางปฏิบัติบางครั้งข้อ จำกัด ทางธุรกิจทำให้เป็นไปไม่ได้ที่จะทำสิ่งต่างๆด้วยวิธีที่สะอาด

ลองนึกภาพกรณีต่อไปนี้:

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

  2. นักพัฒนาทั้งหมดที่อาจแก้ไขข้อผิดพลาดในแอปพลิเคชันไม่สามารถเข้าถึงได้

  3. ขณะนี้ บริษัท กำลังสูญเสียหลายพันดอลลาร์ต่อชั่วโมง (สมมติว่า $ 6,000 ซึ่งหมายถึง $ 100 ต่อนาที)

  4. บั๊กมีผลกระทบกับหลาย ๆ ตารางซึ่งหนึ่งในนั้นมีขนาดใหญ่และมีความกังวลเฉพาะข้อมูลเท่านั้นไม่ใช่สคีมา

  5. เพื่อหลีกเลี่ยงข้อผิดพลาดคุณควรทดลองใช้บิตของข้อมูลซึ่งเกี่ยวข้องกับการลบและเปลี่ยนแปลง

  6. ฐานข้อมูลมีขนาดใหญ่และใช้เวลาสามชั่วโมงในการใช้หรือเรียกคืนการสำรองข้อมูล

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

  8. การสำรองฐานข้อมูลจะถือว่าเชื่อถือได้ พวกเขาได้รับการทดสอบอย่างรุนแรงรวมถึงเมื่อเร็ว ๆ นี้

  9. การสูญเสียข้อมูล 14 ชั่วโมงไม่เป็นที่ยอมรับ แต่การสูญเสียข้อมูลหนึ่งถึงสองชั่วโมงคือ

  10. สภาพแวดล้อมการจัดเตรียมใช้งานเมื่อหกเดือนที่แล้ว ดูเหมือนว่าจะไม่ทันสมัยและอาจต้องใช้เวลาหลายชั่วโมงในการตั้งค่า

  11. ฐานข้อมูลคือ Microsoft SQL Server 2008 Enterprise

วิธีทำความสะอาดสิ่งต่าง ๆ คือ:

  1. คืนค่าการสำรองข้อมูลในสภาพแวดล้อมการจัดเตรียม

  2. ทดลองที่นั่น

  3. ตรวจสอบสคริปต์สุดท้ายสองครั้ง

  4. รันสคริปต์บนเซิร์ฟเวอร์ที่ใช้งานจริง

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

คุณสามารถทำสิ่งนี้แทน:

  1. สร้างสแน็ปช็อต (Microsoft SQL Server รองรับและใช้เวลาไม่กี่วินาทีในการเปลี่ยนกลับ (และไม่มีอะไรที่จะสร้าง) สแน็ปช็อตของฐานข้อมูลที่ใช้เวลาหนึ่งชั่วโมงในการสำรองข้อมูลฉันจินตนาการว่าผลิตภัณฑ์ฐานข้อมูลอื่นสนับสนุนสแนปชอต

  2. ทดลองโดยตรงกับฐานข้อมูลการผลิตย้อนกลับไปยังสแน็ปช็อตหากมีข้อผิดพลาดเกิดขึ้น

ในขณะที่คนพิถีพิถันจะแก้ไขฐานข้อมูลในวิธีที่สะอาดและยังมีความเสี่ยงในการไขสิ่งต่าง ๆ ตามแรงกดดันด้านเวลาในขณะที่เสียเงินมากกว่า $ 20,000 จาก บริษัท ของเขาผู้ดูแลระบบฐานข้อมูลที่รับข้อ จำกัด ทางธุรกิจ ซึ่งจะช่วยลดความเสี่ยง (ขอบคุณภาพรวม) ในขณะที่ทำมันได้อย่างรวดเร็ว

ข้อสรุป

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

หากคนไอทีบางคนต้องการทำสิ่งต่าง ๆ อย่างสะอาดหมดจดเพื่อความสะอาดในขณะที่มันทำให้ บริษัท ต้องสูญเสียเงินหลายพันดอลลาร์คนไอทีคนนี้มีความเข้าใจผิดในงาน


2
และทำงานนอกเวลาทำการถ้าเป็นไปได้ - เมื่อกิจกรรมลูกค้าจริงอย่างน้อยที่สุด
Dan Pichelman

3
แม้ว่าฐานข้อมูลของคุณจะมีขนาดใหญ่และสำรองข้อมูลใช้เวลานานคุณอาจจะสามารถใช้ส่วนย่อยของข้อมูลนั้นและทำการทดสอบกับมัน
Radu Murzea

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

3
@CodeCaster: มันน่าเศร้า แต่บ่อยครั้งที่ฉันเห็นสิ่งนี้ในทางปฏิบัติรวมถึงใน บริษัท ขนาดใหญ่
Arseni Mourzenko

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

4

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

มันเป็นวิธีปฏิบัติที่ไม่ดีและเป็นประตูเชิญสำหรับปัญหาและปัญหาข้อมูลเพิ่มเติม มีแม้กระทั่งวลีที่อธิบายวิธีการนี้ว่า " รวดเร็วและสกปรก "

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

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

มีจำนวนแนวปฏิบัติที่ดีที่กล่าวถึงในแนวทางปฏิบัติที่ดีหลังการจัดเตรียมฐานข้อมูล

ชุดการอ้างอิงที่ดีที่ควรพิจารณาคือ:


2

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

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

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

ทุกธุรกิจมีความเป็นเอกลักษณ์และความเสี่ยงในการอัพเดทข้อมูลบางอย่างนั้นชัดเจนกว่าในธุรกิจอื่น ๆ

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


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

2

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

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

ถัดไปสคริปต์ทั้งหมดเพื่อเปลี่ยนข้อมูลการผลิตควรมีสิ่งต่อไปนี้:

พวกเขาควรจะอยู่ในการทำธุรกรรมที่ชัดเจนและมีบล็อกลอง TRY

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

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

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

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


0

ฉันอัปเดตข้อมูลหลายครั้งในการรันฐานข้อมูลการผลิต ฉันเห็นด้วยกับคำตอบข้างต้นว่าจะไม่เป็นขั้นตอนการปฏิบัติงานมาตรฐาน

มันจะมีราคาแพงด้วย (เราจะดูไหล่ของแต่ละคนและคุยกัน 2 หรือ 3 คน)

และกฎทอง: สร้างคำสั่ง select เพื่อแสดงสิ่งที่ต้องทำก่อนทำคำสั่ง update / delete / insert

กฎทองถูกบังคับใช้โดยคนสองคนในทีม!


0

เรื่อง: คำตอบของ MainMa ...

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

  • คุณจะรู้ได้อย่างไรว่ามันเป็น "บั๊ก" ข้อมูลไม่สอดคล้องกันตามกฎที่ผู้พัฒนาผลิตภัณฑ์ซอฟต์แวร์กำหนดไว้

นักพัฒนาทั้งหมดที่อาจแก้ไขข้อผิดพลาดในแอปพลิเคชันไม่สามารถเข้าถึงได้

ขณะนี้ บริษัท กำลังสูญเสียหลายพันดอลลาร์ต่อชั่วโมง (สมมติว่า $ 6,000 ซึ่งหมายถึง $ 100 ต่อนาที)

  • เห็นได้ชัดว่าการสูญเสีย $ 100 / นาทีนั้นไม่สำคัญพอสำหรับการจัดการ บริษัท สำหรับพวกเขาในการค้นหาและประกันว่านักพัฒนาที่มีความสามารถกลับมาเพื่อแก้ไขข้อผิดพลาดและช่วยให้คุณกู้คืนฐานข้อมูล

บั๊กมีผลกระทบกับหลาย ๆ ตารางซึ่งหนึ่งในนั้นมีขนาดใหญ่และมีความกังวลเฉพาะข้อมูลเท่านั้นไม่ใช่สคีมา

  • ปัญหาฐานข้อมูลทั้งหมด "กังวล" สคีมา วิธีการออกแบบ schema เป็นสิ่งที่จะกำหนดวิธีการแก้ปัญหานี้

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

  • นั่นคือสิ่งที่ฐานข้อมูลการแสดงละครของคุณมีไว้สำหรับ คุณอาจจำเป็นต้อง repopulate ด้วยข้อมูล "เสียหาย" จากฐานข้อมูลการผลิตทันทีหลังจากที่คุณทำการสำรองข้อมูลออนไลน์แบบเต็มของการผลิต

ฐานข้อมูลมีขนาดใหญ่และใช้เวลาสามชั่วโมงในการใช้หรือเรียกคืนการสำรองข้อมูล

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

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

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

การสำรองฐานข้อมูลจะถือว่าเชื่อถือได้ พวกเขาได้รับการทดสอบอย่างรุนแรงรวมถึงเมื่อเร็ว ๆ นี้

  • ยอดเยี่ยม จากนั้นคุณอาจไม่ต้องกู้คืนฐานข้อมูลมากกว่าหนึ่งครั้ง

การสูญเสียข้อมูล 14 ชั่วโมงไม่เป็นที่ยอมรับ แต่การสูญเสียข้อมูลหนึ่งถึงสองชั่วโมงคือ

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

สภาพแวดล้อมการจัดเตรียมใช้งานเมื่อหกเดือนที่แล้ว ดูเหมือนว่าจะไม่ทันสมัยและอาจต้องใช้เวลาหลายชั่วโมงในการตั้งค่า

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

ฐานข้อมูลคือ Microsoft SQL Server 2008 Enterprise

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