ทำไมการสำรองข้อมูลบันทึกธุรกรรมของคุณจึงสำคัญ


14

ขณะนี้เรากำลังใช้โซลูชันสำรองสำหรับลูกค้าและโซลูชัน ERP ของพวกเขาใช้ SQL Server

โซลูชัน ERP ถูกตั้งค่าโดย บริษัท อื่น และพวกเขากำลังบอกฉันว่ามันสำคัญอย่างยิ่งที่จะต้องสำรองและตัดทอนบันทึกธุรกรรม

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

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


ปิดหัวข้อที่นี่ - มีเว็บไซต์สำหรับที่: dba.stackexchange.com
TomTom


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

1
@TomTom: ขออภัยฉันยังไม่คุ้นเคยกับ Stack Exchange ฉันเข้าใจผิดอย่างชัดเจนว่า "การจัดเก็บข้อมูลองค์กรการสำรองข้อมูลและการกู้คืนความเสียหาย" ครอบคลุมอะไรบ้าง ขอบคุณที่แสดงให้ฉันเห็นทาง
Der Hochstapler

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

คำตอบ:


11

คุณจะต้องทำสิ่งนี้ก็ต่อเมื่อ DB Recovery Mode ของคุณถูกตั้งค่าเป็น "เต็ม" หากตั้งไว้ที่ "ง่าย" คุณไม่จำเป็นต้องสำรองข้อมูลบันทึกธุรกรรม แต่ระวังความแตกต่างระหว่างสองทางเลือกนี้!

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

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

อีกประเด็นหนึ่งคือการสำรองข้อมูลบันทึกโดยปกติเร็วกว่าการสำรองข้อมูลเต็มรูปแบบ

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

ถ้าคุณพูดว่า: โอเคถ้าฉันสามารถคืนค่าฐานข้อมูลเป็นชั่วโมงสุดท้ายทุกอย่างไม่เป็นไร -> คุณสามารถนึกถึงการตั้งค่าโหมดการกู้คืนเป็น "ง่าย" หากคุณต้องการเก็บข้อมูลสำรองไว้ทุกชั่วโมง

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

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


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

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

@OliverSalzburg มันขึ้นอยู่กับ คุณหมายความว่าอย่างไรกับ "การสำรองข้อมูลรายชั่วโมงของเซิร์ฟเวอร์ทั้งหมด" ดูเหมือนว่าคุณจะไม่ทำการสำรองข้อมูล SQL ใช่ไหม? หากสิ่งนี้ถูกต้องและคุณทำบางสิ่งบางอย่างเช่นการสำรองข้อมูล Snapshot ของทั้งเซิร์ฟเวอร์ / VM คุณอาจมีปัญหาว่าฐานข้อมูลของคุณไม่สอดคล้องกันในการสำรองข้อมูล คุณควรใช้บางอย่างกับ VSS แต่ฉันยังพูดกับผู้เชี่ยวชาญที่กล่าวว่าฉันไม่ควรเชื่อถือ backuptools จริง ๆ ว่าพวกเขาสำรองระบบและฐานข้อมูลในสถานะที่สอดคล้องกัน ... ดังนั้นฉันจะแยกระบบและการสำรองฐานข้อมูล (ถ้าเป็นไปได้ในสภาพแวดล้อมของคุณ)
frupfrup

เพิ่ม: ฉันไม่คิดว่า. trn บันทึกรวมอยู่ในการสำรองข้อมูล SQL แบบเต็มปกติ ... ในการสำรองข้อมูลเฉพาะฐานข้อมูลที่รวมอยู่กับข้อมูลทั้งหมด แต่ในบันทึกธุรกรรมคือการเปลี่ยนแปลงของฐานข้อมูล ฐานข้อมูลของคุณทำงานโดยไม่มีข้อมูลเหล่านี้ ดังนั้นฉันไม่คิดว่าพวกเขาจะรวม นี่เป็นอีกสาเหตุหนึ่งที่ทำให้คุณต้องสำรองข้อมูลบันทึกหากคุณต้องการใช้คุณสมบัตินี้เพื่อกลับไปยังช่วงเวลาที่ระบุ แต่ตอนนี้ฉันสงสัยว่า ... คุณทำให้ฉันสับสนเล็กน้อย :-)
frupfrup

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

3

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

ใช่มันจะคืนค่าไปยังจุดที่ระบุในเวลาเช่นกัน ลงไปที่นาที อย่าง Twinkle บอกว่าใช่คนวางโต๊ะและชอบ

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


1

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

แต่แน่นอนมันขึ้นอยู่กับสถานการณ์ หากคุณไม่มีงานอัตโนมัติ ฯลฯ คุณสามารถสำรองข้อมูลได้ทุกชั่วโมง


1

มีสาเหตุหลายประการที่คุณต้องการ:

  1. ระบบฐานข้อมูลมักจะไม่ว่างอาจทำธุรกรรมหลายพันรายการต่อวินาที ข้อมูลสามารถกระจายออกไปหลายไฟล์ในระบบไฟล์ที่แตกต่างกัน ไม่สำคัญที่จะตรวจสอบให้แน่ใจว่าฐานข้อมูลอยู่ในสถานะที่สอดคล้องกัน (หรือใช้งานได้) หลังจากกู้คืน หากโซลูชันการสำรองข้อมูลของคุณขึ้นอยู่กับงานนั้นยอดเยี่ยม แต่คุณควรแน่ใจก่อน
  2. ตัวอย่าง: ใครบางคนวางตารางด้วยข้อมูลที่สำคัญโดยไม่ได้ตั้งใจ หากคุณมีการสำรองฐานข้อมูลที่มีความสามารถในการกู้คืน ณ เวลานั้นคุณสามารถกู้คืนข้อมูลได้อย่างรวดเร็วโดยไม่ต้องกู้คืนทั้งระบบ
  3. ถ้าฐานข้อมูลอยู่ในโหมดการกู้คืนแบบเต็มล็อกธุรกรรมของ SQL Server จะเติบโต พื้นที่เก็บข้อมูลในบันทึกธุรกรรมจะถูกนำกลับมาใช้ใหม่หากบันทึกธุรกรรมได้รับการสำรองแล้ว หากคุณไม่สำรองข้อมูลบันทึกธุรกรรมเป็นประจำระบบไฟล์ของคุณจะเต็มจนกว่าจะไม่มีพื้นที่เหลือ ณ จุดนี้ทุกสิ่งจะหยุดทันทีเนื่องจากไม่มีธุรกรรมใหม่ที่สามารถเริ่มต้นได้

1

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

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

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

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

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

อย่างไรก็ตามหากธุรกิจของคุณถือว่าระบบ ERP เป็นสินทรัพย์ที่สำคัญสำหรับการดำเนินงาน (ไม่ใช่ทั้งหมด) ให้กำหนดเวลาการกู้คืนที่ยอมรับได้สูงสุด (aka RTO, Object Time Recovery Objective) สำหรับบริการที่สำคัญของคุณจะเป็นการตัดสินใจทางธุรกิจ

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

คำตอบหากคุณถามพวกเขาอาจเป็น "ไม่มีข้อมูลใดสูญหายได้! ระบบ ERP ต้องพร้อมให้บริการตลอด 24/7/365!" ... ซึ่งเราทุกคนรู้ว่าไม่น่าจะมีประสิทธิภาพสูง หากคุณแสดงให้พวกเขาเห็นด้วยค่าใช้จ่ายที่เกี่ยวข้องกับการสร้างระบบที่ซ้ำซ้อนและไม่หยุดยั้งเช่นนั้นพวกเขาจะได้ตัวเลขที่สมเหตุสมผลมากขึ้น .. ;)

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


+1 สำหรับการกู้คืนคือ crux ไม่ใช่การสำรองข้อมูล และนำผู้ใช้ทางธุรกิจมาสู่การตัดสินใจ
RateControl

1

ทุกคนมีการตอบสนองที่ยอดเยี่ยม แต่ฉันต้องการเพิ่มบันทึกย่อที่สำคัญอื่น ๆ ... หรือสองรายการ

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

มีการประเมินผลิตภัณฑ์ที่คล้ายกันเมื่อเร็ว ๆ นี้ประเด็นสำคัญที่คุณอาจต้องถามคือ:

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

หวังว่านี่จะเป็นประโยชน์

ประสบการณ์ที่ทีมของฉันมีกับการประเมินล่าสุดของเราให้คำตอบที่น่าสนใจกับคำถามข้างต้น มีสิ่งหนึ่งที่แน่นอนว่าการสำรองข้อมูลมีความซับซ้อนมากขึ้นสำหรับเราด้วยผลิตภัณฑ์สำรองข้อมูล VSS


0

ดังที่คนอื่น ๆ บอกไว้แล้วหากคุณใช้เครื่องมือของบุคคลที่สามในการสำรองข้อมูล / สแน็ปช็อต VM หรือที่เก็บข้อมูลคุณยังคงเสี่ยงต่อการไม่มีการสำรองข้อมูลที่ถูกต้อง เครื่องมือของบุคคลที่สามทั้งหมดที่จัดการการสำรองข้อมูล SQL Server จะนำไปใช้และเชื่อมต่อกับ SQL Server โดยใช้ VSS มันทำเช่นนี้เพื่อร้องขอให้ SQL Server quiesce I / O ทั้งหมดไปยังไฟล์ข้อมูลเพื่อให้สามารถถ่ายภาพที่สอดคล้องกัน ถ้าไม่เช่นนั้นคุณสามารถมีธุรกรรมจำนวนมากในสถานะต่าง ๆ และการคืนค่าจะไม่ทราบว่าธุรกรรมเหล่านั้นสามารถย้อนไปข้างหน้าหรือข้างหลัง

ฉันไม่ได้ทำงานกับเครื่องมือ snapshot VM / Storage ของบุคคลที่สามทุกคน แต่เครื่องมือที่ฉันได้ทำงานด้วยไม่สามารถจัดเก็บที่ฐานข้อมูลของระบบได้ - SQL Server ไม่สามารถหยุดฐานข้อมูลเหล่านั้นได้ พวกเขาทั้งหมดทำการสำรองฐานข้อมูลเหล่านั้นในลักษณะที่มีการสตรีมนั่นคือ ... การออกคำสั่ง BACKUP DATABASE แล้วหักแฟ้มสำรองข้อมูลเอง

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

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


0

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

การสำรองไฟล์บันทึกของคุณบ่อยๆนั้นมีสองสิ่ง:

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

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

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

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


0

คนอื่นได้ให้เหตุผลส่วนใหญ่แล้วสำหรับการสำรองข้อมูล translog เป็นต้นมีข้อสงสัยว่าทำไมนี่เป็นกลยุทธ์ที่ดีเมื่อคุณสำรองข้อมูลเซิร์ฟเวอร์อยู่แล้ว

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

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

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