RAC, Data Guard และ Stream เป็นเครื่องมือสามตัวในระบบความพร้อมใช้งานสูงของ Oracle ซึ่งเครื่องมือแต่ละตัวสามารถใช้งานได้อย่างอิสระหรือใช้ร่วมกันก็ได้ โดยมีจุดเน้นที่แตกต่างกันและเหมาะสมกับสถานการณ์ที่แตกต่างกัน
RAC มีความโดดเด่นในการจัดการปัญหาจุดล้มเหลวเพียงจุดเดียวและการกระจายภาระงาน ดังนั้น RAC มักถูกนำมาใช้ในระบบสำคัญที่ต้องทำงานตลอด 24 ชั่วโมงทุกวัน อย่างไรก็ตาม ในโซลูชัน RAC ข้อมูลมีอยู่เพียงสำเนาเดียว แม้ว่าจะสามารถหลีกเลี่ยงความล้มเหลวของหน่วยความจำได้ผ่านกลไกเช่น RAID แต่ตัวข้อมูลเองไม่มีความซ้ำซ้อน ทำให้มีความเสี่ยงต่อการล้มเหลวจากจุดเดียว
Data Guard ให้การป้องกันข้อมูลผ่านข้อมูลซ้ำซ้อน โดยใช้กลไกการซิงค์ข้อมูลบันทึก เซิร์ฟเวอร์ Data Guard จะทำให้มั่นใจได้ว่าข้อมูลซ้ำซ้อนและข้อมูลหลักมีความสอดคล้องกัน การซิงค์ข้อมูลนี้สามารถทำได้หลายรูปแบบ เช่น แบบเรียลไทม์ แบบหน่วงเวลา แบบซิงโครนัส หรือแบบแอสซิงโครนัส Data Guard มักถูกใช้ในโซลูชันสำรองข้อมูลกรณีภัยพิบัติระยะไกล และโซลูชันความพร้อมใช้งานสูงสำหรับองค์กรขนาดเล็ก แม้ว่าจะอนุญาตให้ดำเนินการสอบถามแบบอ่านอย่างเดียวบนเครื่องสำรองเพื่อลดแรงกดดันด้านประสิทธิภาพของฐานข้อมูลหลัก แต่จุดประสงค์หลักของ Data Guard ไม่ใช่โซลูชันด้านประสิทธิภาพ
Stream ซึ่งสร้างบน Oracle Advanced Queue ช่วยให้สามารถซิงค์ข้อมูลและนำเสนอการตั้งค่าที่ยืดหยุ่นได้ในหลายระดับ เนื่องจาก Oracle จัดเตรียมการสนับสนุนด้านการพัฒนาอย่างกว้างขวาง รวมถึง API ที่หลากหลาย Stream จึงเหมาะกับการใช้แบ่งปันข้อมูลในระดับแอปพลิเคชันมากกว่า
Data Guard คืออะไร
ในสภาพแวดล้อมของ Data Guard จะมีฐานข้อมูลอย่างน้อย 2 แห่ง หนึ่งแห่งอยู่ในสถานะเปิดเพื่อให้บริการภายนอก เรียกว่า ฐานข้อมูลหลัก (Primary Database) อีกแห่งหนึ่งอยู่ในสถานะกู้คืน เรียกว่า ฐานข้อมูลสำรอง (Standby Database) ระหว่างการทำงาน ฐานข้อมูลหลักจะให้บริการแก่ลูกค้า และการดำเนินการของผู้ใช้จะถูกบันทึกไว้ในบันทึกออนไลน์และบันทึกที่จัดเก็บไว้ จากนั้นจะส่งไปยังฐานข้อมูลสำรองผ่านเครือข่าย บันทึกเหล่านี้จะถูกเล่นซ้ำบนฐานข้อมูลสำรองเพื่อให้ข้อมูลระหว่างสองฐานข้อมูลมีความซิงค์กัน
Oracle Data Guard ยังเพิ่มประสิทธิภาพให้กับกระบวนการนี้ โดยทำให้การส่งและการกู้คืนบันทึกอัตโนมัติและราบรื่นมากขึ้น พร้อมทั้งให้พารามิเตอร์และคำสั่งต่างๆ เพื่อช่วยให้งานของผู้ดูแลระบบฐานข้อมูล (DBAs) ง่ายขึ้น
หากมีปัจจัยที่คาดการณ์ล่วงหน้าซึ่งต้องการให้ฐานข้อมูลหลักหยุดทำงาน เช่น การอัปเกรดซอฟต์แวร์หรือฮาร์ดแวร์ ฐานข้อมูลสำรองสามารถสลับเพื่อทำหน้าที่เป็นฐานข้อมูลหลักและดำเนินการให้บริการแก่ผู้ใช้ต่อไปได้ สิ่งนี้จะช่วยลดระยะเวลาที่บริการหยุดชะงักและรับประกันความสมบูรณ์ของข้อมูล ในกรณีที่เกิดปัญหาไม่คาดคิดจนทำให้ฐานข้อมูลหลักไม่สามารถใช้งานได้ ฐานข้อมูลสำรองสามารถถูกบังคับสลับให้กลายเป็นฐานข้อมูลหลักและดำเนินการให้บริการต่อไปได้ ระดับการสูญหายของข้อมูลในกรณีดังกล่าวขึ้นอยู่กับระดับการป้องกันข้อมูลที่กำหนดไว้ ดังนั้น ฐานข้อมูลหลักและฐานข้อมูลสำรองจึงเป็นบทบาทเชิงแนวคิดที่ไม่ได้ถูกผูกตายตัวกับฐานข้อมูลใดฐานข้อมูลหนึ่ง
สถาปัตยกรรมของ Data Guard
สถาปัตยกรรมของ Data Guard สามารถแบ่งออกเป็นสามส่วนหน้าที่หลักได้ดังนี้
1) การส่ง Redo อีกครั้ง
ในช่วงเวลาที่ฐานข้อมูลหลักทำงาน บันทึก redo จะถูกสร้างขึ้นอย่างต่อเนื่องและจำเป็นต้องส่งไปยังฐานข้อมูลสำรอง การส่งดังกล่าวสามารถดำเนินการได้โดยกระบวนการ LGWR หรือ ARCH ของฐานข้อมูลหลัก ปลายทางต่างๆ สำหรับการจัดเก็บอาจใช้วิธีการที่แตกต่างกันได้ แต่สำหรับปลายทางเฉพาะเจาะจงจะเลือกได้เพียงวิธีเดียวเท่านั้น การเลือกกระบวนการมีผลกระทบอย่างมากต่อความสามารถในการป้องกันข้อมูลและความพร้อมใช้งานของระบบ
2) รับซ้ำ
กระบวนการ RFS (Remote File Server) ในฐานข้อมูลสำรองจะรับบันทึกและเขียนลงในไฟล์บันทึก redo สำรองหรือไฟล์บันทึกเก็บไว้ ขึ้นอยู่กับวิธีการส่งบันทึกของฐานข้อมูลหลักและตำแหน่งที่ตั้งของฐานข้อมูลสำรอง หากบันทึกถูกเขียนลงในไฟล์บันทึก redo สำรอง เมื่อมีการสลับบันทึกบนฐานข้อมูลหลัก จะทำให้เกิดการสลับบันทึกบนบันทึก redo สำรองของฐานข้อมูลสำรอง และทำการเก็บบันทึก redo สำรองนั้นไว้ หากบันทึกถูกเขียนลงในบันทึกเก็บไว้ การกระทำนี้สามารถถือเป็นการดำเนินการเก็บบันทึกได้เลย
3) ทำซ้ำการใช้งาน
บริการทำซ้ำการใช้งานมีหน้าที่ในการเล่นซ้ำบันทึกของฐานข้อมูลหลักบนฐานข้อมูลสำรอง ทำให้เกิดการซิงค์ข้อมูลระหว่างฐานข้อมูลทั้งสอง
ขึ้นอยู่กับว่าฐานข้อมูลสำรองจะเล่นบันทึกซ้ำอย่างไร จะมีสองประเภท ได้แก่ Physical Standby และ Logical Standby
ขึ้นอยู่กับช่วงเวลาที่ Redo Apply เกิดขึ้น จะมีอยู่ 2 ประเภทด้วยกัน
ก) การประยุกต์ใช้แบบเรียลไทม์ วิธีนี้จำเป็นต้องใช้ Standby Redo Log เมื่อใดก็ตามที่มีการเขียน log ลงใน Standby Redo Log จะทำให้เกิดกระบวนการกู้คืน ข้อดีของวิธีนี้คือช่วยลดเวลาที่ต้องใช้ในการสลับฐานข้อมูล เนื่องจาก log ที่เหลือจะถูกกู้คืนแบบเรียลไทม์อยู่แล้ว
ข) ใช้ที่การเก็บถาวร วิธีนี้จะนำบันทึกมาใช้เมื่อเกิดการสลับบันทึกบนฐานข้อมูลหลัก และกระตุ้นการจัดเก็บถาวรบนฐานข้อมูลสำรอง การกู้คืนจะเริ่มขึ้นหลังจากกระบวนการจัดเก็บถาวรเสร็จสิ้น ซึ่งยังเป็นโหมดการกู้คืนเริ่มต้นด้วยเช่นกัน
สแตนด์บายทางกายภาพ เทียบกับ สแตนด์บายเชิงตรรกะ
มีฐานข้อมูลสำรองสองประเภท ได้แก่ สแตนด์บายทางกายภาพ และสแตนด์บายเชิงตรรกะ
1. สแตนด์บายทางกายภาพ
ฐานข้อมูลสแตนด์บายทางกายภาพมีลักษณะเหมือนกับฐานข้อมูลหลักทุกประการ Data Guard จะดูแลรักษาฐานข้อมูลสแตนด์บายทางกายภาพโดยใช้การนำ REDO มาประยุกต์ใช้ โดยทั่วไปเมื่อฐานข้อมูลสแตนด์บายทางกายภาพไม่ได้นำ REDO มาประยุกต์ใช้อยู่ สามารถเปิดใช้งานในโหมดอ่านอย่างเดียว (READ ONLY) ได้ หากมีการกำหนดพื้นที่แฟลชแบ็ค (Flashback Area) ไว้ในฐานข้อมูล ก็สามารถเปลี่ยนไปใช้โหมดอ่านและเขียน (READ WRITE) ชั่วคราวเพื่อดำเนินการต่างๆ ได้ด้วย เมื่อดำเนินการที่จำเป็นเสร็จเรียบร้อยแล้ว สามารถเรียกคืนฐานข้อมูลกลับไปยังสถานะก่อนเข้าสู่โหมด READ WRITE ได้โดยใช้ฟีเจอร์ Flashback Database ทำให้สามารถดำเนินการนำข้อมูล REDO จากฐานข้อมูลหลักมาประยุกต์ใช้ต่อไปได้
หมายเหตุ: ฟังก์ชันการใช้งานของ Physical Standby ได้รับการปรับปรุงใน Oracle 11g ในเวอร์ชันนี้ Physical Standby สามารถดำเนินการใช้ข้อมูล REDO ต่อไปได้แม้อยู่ในโหมด OPEN READ ONLY สิ่งนี้ช่วยเพิ่มความสามารถในการใช้งานของฐานข้อมูล Physical Standby อย่างมาก
คุณสมบัติของ Physical Standby
1) การกู้คืนภัยพิบัติและความพร้อมใช้งานสูง: โคลนสำรองทางกายภาพให้โซลูชันที่แข็งแกร่งและมีประสิทธิภาพสำหรับการกู้คืนภัยพิบัติและความพร้อมใช้งานสูง ซึ่งช่วยให้การจัดการการสลับหรือการเปลี่ยนการทำงานกรณีขัดข้องทำได้ง่ายขึ้น และลดเวลาการหยุดทำงานทั้งที่วางแผนไว้และไม่คาดคิด
2) การป้องกันข้อมูล: ด้วยฐานข้อมูลสำรองทางกายภาพ Data Guard จะช่วยให้มั่นใจได้ว่าการสูญเสียข้อมูลจะถูกลดให้น้อยที่สุด แม้จะเผชิญกับภัยพิบัติที่ไม่สามารถคาดการณ์ได้
3) ลดภาระงานของฐานข้อมูลหลัก: ด้วยการโอนถ่ายงานบางอย่าง เช่น การสำรองข้อมูลและการสอบถามที่อ่านได้อย่างเดียว ไปยังฐานข้อมูลสำรองแบบกายภาพ จะช่วยประหยัดทรัพยากร CPU และ I/O บนฐานข้อมูลหลักได้
4) ประสิทธิภาพที่ดีขึ้น: กลไกการใช้งาน REDO ที่ใช้ในฐานข้อมูลสำรองแบบ Physical Standby จะทำงานในระดับการกู้คืนที่ต่ำที่สุด โดยข้ามการดำเนินการรหัส SQL ซึ่งส่งผลให้มีประสิทธิภาพและสมรรถนะสูงที่สุด
2. สแตนด์บายเชิงตรรกะ
ฐานข้อมูลสแตนด์บายเชิงตรรกะถูกสร้างขึ้นโดยอิงจากฐานข้อมูลหลัก (หรือสำเนาสำรอง หรือรูปแบบจำลองของมัน เช่น สแตนด์บายทางกายภาพ) ดังนั้นในตอนเริ่มต้นจึงคล้ายกับฐานข้อมูลสแตนด์บายทางกายภาพ อย่างไรก็ตาม เนื่องจากสแตนด์บายเชิงตรรกะนำข้อมูล REDO มาใช้ผ่านการรันคำสั่ง SQL โครงสร้างของไฟล์ทางกายภาพ และแม้กระทั่งโครงสร้างเชิงตรรกะของข้อมูล อาจแตกต่างจากฐานข้อมูลหลักได้
ต่างจาก Physical Standby ซึ่งโดยปกติจะเปิดในโหมด READ WRITE ทำให้ผู้ใช้สามารถเข้าถึงได้ตลอดเวลา อีกนัยหนึ่งหมายความว่าการดำเนินการ SQL เกิดขึ้นขณะที่ Logical Standby อยู่ในสถานะเปิด ซึ่งมีทั้งข้อดีและข้อเสีย เนื่องจากลักษณะของการดำเนินการ SQL จึงมีข้อจำกัดในการดำเนินงานเกี่ยวกับประเภทข้อมูลบางประเภท และคำสั่ง DDL/DML บางคำสั่งใน Logical Standby คุณสามารถตรวจสอบประเภทข้อมูลที่ไม่รองรับได้จากมุมมอง DBA_LOGSTDBY_UNSUPPORTED หากมีการใช้งานประเภทข้อมูลดังกล่าว อาจไม่สามารถรับประกันความสมบูรณ์ของข้อมูลในฐานข้อมูลได้อย่างครบถ้วน
การเปิดโหมด READ WRITE ของ Logical Standby จะทำให้เหมาะสำหรับใช้เป็นระบบรายงาน โดยช่วยลดภาระงานของระบบ
คุณสมบัติของ Logical Standby
นอกเหนือจากคุณลักษณะที่กล่าวมาแล้วสำหรับ Physical Standby เช่น การกู้คืนจากภัยพิบัติ ความพร้อมใช้งานสูง และการป้องกันข้อมูล Logical Standby ยังมีคุณสมบัติดังต่อไปนี้
1) การใช้ทรัพยากรฮาร์ดแวร์บนเซิร์ฟเวอร์สำรองอย่างมีประสิทธิภาพ: ฐานข้อมูลสำรองเชิงตรรกะสามารถใช้ในการสร้างดัชนีเพิ่มเติม มุมมองแบบวัสดุ และตอบสนองความต้องการทางธุรกิจเฉพาะได้ ยังสามารถสร้างสคีมาใหม่ (ซึ่งไม่มีอยู่ในฐานข้อมูลหลัก) และดำเนินการคำสั่ง DDL หรือ DML ที่อาจไม่เหมาะสมต่อการดำเนินการบนฐานข้อมูลหลักได้อีกด้วย
2) ถ่ายโอนภาระงานจากฐานข้อมูลหลัก: โดยการเปิดใช้งานฐานข้อมูลสำรองเชิงตรรกะไว้ตลอดเวลาในขณะที่ยังคงซิงค์กับฐานข้อมูลหลัก ทำให้สามารถรองรับทั้งการป้องกันข้อมูลและการออกรายงานได้ ซึ่งช่วยลดภาระงานด้านรายงานและการสอบถามข้อมูลออกจากฐานข้อมูลหลัก ประหยัดทรัพยากร CPU และ I/O ที่มีค่า
3) การอัปเกรดที่ราบรื่น: Logical Standby สามารถใช้สำหรับการดำเนินงานต่างๆ เช่น การอัปเกรดข้ามเวอร์ชันและการปรับปรุงแก้ไขฐานข้อมูล
โหมดการป้องกันข้อมูล
Data Guard อนุญาตให้มีสามโหมดการป้องกันข้อมูล ได้แก่ สูงสุดในการป้องกัน สูงสุดในการใช้งาน และสูงสุดในด้านประสิทธิภาพ
1. การป้องกันสูงสุด
โหมดนี้มั่นใจได้ว่าจะไม่มีการสูญเสียข้อมูลเลย เพื่อให้บรรลุเป้าหมายนี้ รายการทั้งหมดจะต้องไม่เพียงแต่เขียนลงใน Online Redo Logs ในเครื่องเท่านั้น แต่ยังต้องถูกเขียนพร้อมกันไปยัง Standby Redo Logs ในฐานข้อมูลสำรองด้วย ข้อมูล REDO จะต้องสามารถเข้าถึงได้อย่างน้อยหนึ่งฐานข้อมูลสำรอง (หากมีหลายตัว) ก่อนที่จะทำ Commit บนฐานข้อมูลหลักได้ หากฐานข้อมูลสำรองไม่สามารถใช้งานได้เนื่องจากเกิดความผิดพลาด (เช่น การหยุดชะงักของเครือข่าย) ฐานข้อมูลหลักจะถูกปิดเพื่อป้องกันการสูญเสียข้อมูล
การเปิดใช้งานโหมดนี้จำเป็นต้องกำหนดค่าฐานข้อมูลสำรองให้มี Standby Redo Logs และฐานข้อมูลหลักต้องใช้โหมด LGWR, SYNC, AFFIRM สำหรับการจัดเก็บข้อมูลไปยังฐานข้อมูลสำรอง
2. การใช้งานสูงสุด
โหมดนี้ให้กลยุทธ์การป้องกันข้อมูลในระดับสูงที่สุด โดยไม่กระทบต่อความสามารถในการใช้งานของฐานข้อมูลหลัก (Primary database) ซึ่งมีแนวทางการดำเนินการคล้ายกับโหมดการป้องกันสูงสุด (Maximum Protection) ที่ธุรกรรมในท้องถิ่นจะต้องถูกเขียนไปยัง Standby Redo Logs ของฐานข้อมูลสำรอง (Standby database) อย่างน้อยหนึ่งแห่ง ก่อนที่จะทำการยืนยัน (commit) อย่างไรก็ตาม ความแตกต่างคือ หากเกิดข้อผิดพลาดที่ทำให้ไม่สามารถเข้าถึงฐานข้อมูลสำรองได้ ฐานข้อมูลหลักจะเปลี่ยนไปใช้โหมดประสิทธิภาพสูงสุด (Maximum Performance mode) โดยอัตโนมัติ แทนที่จะปิดระบบ เมื่อฐานข้อมูลสำรองกลับมาทำงานได้ ฐานข้อมูลหลักจะสลับกลับไปใช้โหมดการใช้งานสูงสุดโดยอัตโนมัติ
แม้ว่าโหมดนี้จะมีจุดประสงค์เพื่อลดการสูญเสียข้อมูลให้น้อยที่สุด แต่ก็ไม่สามารถรับประกันความสอดคล้องของข้อมูลอย่างสมบูรณ์ได้ เช่นเดียวกับโหมด Maximum Protection โหมดนี้ต้องการให้ฐานข้อมูลสำรองถูกกำหนดค่าพร้อม Standby Redo Logs และให้ฐานข้อมูลหลักใช้โหมด LGWR, SYNC, AFFIRM ในการเก็บบันทึกข้อมูลไปยังฐานข้อมูลสำรอง
3. ประสิทธิภาพสูงสุด
โหมดนี้ให้ระดับกลยุทธ์การป้องกันข้อมูลสูงที่สุด โดยไม่กระทบต่อประสิทธิภาพของฐานข้อมูลหลัก การทำธุรกรรมสามารถยืนยันได้ตลอดเวลา และข้อมูล REDO จากฐานข้อมูลหลักในปัจจุบันจำเป็นต้องถูกเขียนไปยังฐานข้อมูลสำรองอย่างน้อยหนึ่งแห่ง แม้ว่าจะสามารถทำได้แบบไม่ซิงโครไนซ์ก็ตาม ภายใต้สภาวะเครือข่ายที่เหมาะสม โหมดนี้สามารถให้การป้องกันข้อมูลใกล้เคียงกับโหมดความพร้อมใช้งานสูงสุด ในขณะที่มีผลกระทบเพียงเล็กน้อยต่อประสิทธิภาพของฐานข้อมูลหลัก นี่คือโหมดการป้องกันเริ่มต้นเมื่อมีการสร้างฐานข้อมูลสำรอง สามารถทำได้โดยใช้กระบวนการ LGWR ASYNC หรือ ARCH และไม่จำเป็นต้องใช้ Standby Redo Logs สำหรับฐานข้อมูลสำรอง
ขั้นตอนการแก้ไขโหมดการป้องกันข้อมูล
1. ปิดฐานข้อมูลแล้วเริ่มต้นใหม่ในสถานะ Mount หากเป็นการตั้งค่า RAC ให้ปิดทุกอินสแตนซ์และเริ่มอินสแตนซ์เดียวเท่านั้นในสถานะ Mount
2. แก้ไขโหมดโดยใช้รูปแบบต่อไปนี้
ALTER DATABASE ตั้งค่า STANDBY DATABASE เพื่อเพิ่มสูงสุด {PROTECTION | AVAILABILITY | PERFORMANCE};
ตัวอย่างเช่น: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. เปิดฐานข้อมูล: ALTER DATABASE OPEN;
4. ยืนยันโหมดการป้องกันข้อมูลที่แก้ไขแล้ว
SQL>select protection_mode,protection_level from v$database;
บริการประยุกต์ใช้ลอจ
Data Guard รักษามาตรฐานความสอดคล้องระหว่างฐานข้อมูลหลักและฐานข้อมูลสำรองโดยการใช้ REDO ซึ่งอยู่เบื้องหลังกระบวนการนี้คือ บริการประยุกต์ใช้ลอจอันมีชื่อเสียง ซึ่งมีอยู่ 2 ประเภท
1. การประยุกต์ใช้ REDO
เฉพาะสำหรับฐานข้อมูล Standby แบบกายภาพเท่านั้น ซึ่งทำให้ฐานข้อมูลเหล่านี้มีความสอดคล้องกับฐานข้อมูลหลักผ่านการกู้คืนด้วยสื่อ
2. การประยุกต์ใช้ SQL
มีไว้สำหรับฐานข้อมูล Standby แบบลอจิคัลโดยเฉพาะ โดยฟังก์ชันหลักจะวิเคราะห์คำสั่ง SQL ผ่าน LogMiner และดำเนินการคำสั่งนั้นที่ด้าน Standby
ดังนั้น เมื่อประยุกต์ใช้ข้อมูล REDO ฐานข้อมูล Standby แบบฟิสิคัลจะต้องอยู่ในสถานะ MOUNT ขณะที่ฐานข้อมูล Standby แบบลอจิคัลจะเปิดในโหมด READ WRITE เพื่อการประยุกต์ใช้ข้อมูล REDO อย่างไรก็ตาม ออบเจ็กต์ที่ถูกจัดการจะถูกตั้งค่าเป็นแบบอ่านอย่างเดียวโดยค่าเริ่มต้น และไม่สามารถแก้ไขได้โดยตรงจากฝั่ง Standby แบบลอจิคัล
ปกป้องฐานข้อมูล Oracle ด้วยวิธีการระดับมืออาชีพ
Oracle Data Guard เป็นโซลูชันที่แข็งแกร่งสำหรับความพร้อมใช้งานสูง การป้องกันข้อมูล และการกู้คืนจากภัยพิบัติ ซึ่งเป็นเครื่องมือสำคัญสำหรับธุรกิจที่ไม่สามารถยอมรับการหยุดทำงานหรือการสูญเสียข้อมูลได้ อย่างไรก็ตาม เพื่อเพิ่มการปกป้องสภาพแวดล้อมฐานข้อมูลของคุณ ขอแนะนำให้สำรองข้อมูลฐานข้อมูล Oracle ด้วยโซลูชันสำรองข้อมูลและการกู้คืนจากภัยพิบัติระดับมืออาชีพ
Vinchin Backup & Recovery มีฟังก์ชันการทำงานที่ทรงพลังในการปกป้องฐานข้อมูลของคุณทั้งในเครื่องเสมือนและเซิร์ฟเวอร์จริง ซึ่งค่อนข้างอัตโนมัติ มีความยืดหยุ่น และมีประสิทธิภาพ ยังให้การป้องกันฐานข้อมูลหลายประเภท ได้แก่ Oracle DB, MySQL, SQL Server, Postgres Pro และ MariaDB รองรับการบีบอัดฐานข้อมูล การจัดการงานแบบรวมศูนย์ กลยุทธ์การสำรองข้อมูลอัจฉริยะ การสำรองข้อมูลฐานข้อมูลขณะทำงาน (hot backup) และการสนับสนุนขั้นสูงสำหรับ SQL Server/Oracle นอกจากนี้ ยังรองรับคุณสมบัติการป้องกันแรนซัมแวร์ที่มีประสิทธิภาพ และการโยกย้าย V2V ข้ามแพลตฟอร์มเสมือนมากกว่า 10 แพลตฟอร์ม
Vinchin Backup & Recovery ได้รับการเลือกใช้โดยบริษัทหลายพันแห่งทั่วโลก และคุณก็สามารถเริ่มใช้งานระบบอันทรงพลังนี้ได้ด้วยการทดลองใช้ฟีเจอร์ครบถ้วนฟรี 60 วัน นอกจากนี้ ติดต่อ Vinchin โดยตรง และแจ้งความต้องการของคุณ แล้วคุณจะได้รับโซลูชันที่เหมาะสมกับสภาพแวดล้อมไอทีของคุณ
บทสรุป
Oracle Data Guard เป็นองค์ประกอบสำคัญสำหรับการติดตั้งฐานข้อมูล Oracle ในระดับองค์กร ซึ่งนำเสนอวิธีการที่ครอบคลุมสำหรับการกู้คืนจากภัยพิบัติ ความพร้อมใช้งานสูง การป้องกันข้อมูล และการกระจายภาระงาน สถาปัตยกรรมที่ยืดหยุ่นและการดำเนินงานในหลายโหมดทำให้สามารถปรับให้เหมาะสมกับความต้องการทางธุรกิจและความต้องการในการปฏิบัติงานที่หลากหลายได้
คุณสามารถเลือก Vinchin Backup & Recovery เพื่อสำรองข้อมูลและกู้คืนฐานข้อมูล Oracle ของคุณได้อย่างง่ายดาย อย่าพลาดการทดลองใช้งานฟรี
