สำหรับผู้ดูแลฐานข้อมูล Oracle ที่จัดการสำรองข้อมูลไปยังเทปหรือที่เก็บข้อมูลบนคลาวด์ เหตุการณ์รอ (wait event) Backup: MML write backup piece อาจก่อให้เกิดความสับสน และบางครั้งก็ทำให้หงุดหงิดได้ เหตุการณ์นี้มักปรากฏเมื่อการสำรองข้อมูลช้าลงหรือค้างอยู่ สิ่งนี้หมายถึงอะไร และทำไมจะเกิดขึ้น ในคู่มือนี้ เราจะอธิบายสิ่งที่เกิดขึ้นเบื้องหลังเมื่อคุณเห็นข้อความนี้ เราจะแนะนำขั้นตอนการวินิจฉัยปัญหาอย่างเป็นลำดับ ตั้งแต่การตรวจสอบพื้นฐานไปจนถึงการแก้ไขปัญหาขั้นสูง และนำเสนอแนวทางที่ได้ผลเพื่อป้องกันปัญหาในสภาพแวดล้อมการสำรองข้อมูลของคุณ สุดท้าย คุณจะได้เรียนรู้ว่า Vinchin สามารถช่วยทำให้การปกป้องข้อมูล Oracle ง่ายขึ้นได้อย่างไร
MML ในการสำรองข้อมูลคืออะไร
Media Management Layer (MML) ทำหน้าที่เป็นสะพานเชื่อมระหว่าง Oracle Recovery Manager (RMAN) และอุปกรณ์จัดเก็บข้อมูลภายนอก เมื่อคุณใช้ RMAN เพื่อสำรองฐานข้อมูล ระบบสามารถเขียนข้อมูลโดยตรงไปยังดิสก์ หรือส่งต่อข้อมูลไปยังซอฟต์แวร์จัดการสื่อของบุคคลที่สามผ่าน MML ได้ สิ่งนี้ช่วยให้คุณสามารถจัดเก็บข้อมูลสำรองไว้ในห้องเก็บเทปหรือพื้นที่จัดเก็บข้อมูลบนคลาวด์แทนที่จะเป็นเพียงดิสก์ในเครื่องเท่านั้น
MML จัดการงานต่างๆ เช่น การเขียนบล็อกข้อมูล การติดป้ายกำกับชิ้นส่วนสำรองข้อมูล การติดตามตำแหน่งของชิ้นส่วนเหล่านั้นบนสื่อจัดเก็บทางกายภาพ และการรายงานสถานะกลับไปยัง RMAN โดยการแยกหน้าที่เหล่านี้ออกจากการทำงานหลักของฐานข้อมูล Oracle ทำให้มั่นใจว่าการสำรองข้อมูลสามารถขยายขนาดได้ครอบคลุมระบบจัดเก็บข้อมูลระดับองค์กรหลายประเภท
Write Backup Piece หมายถึงอะไร
เมื่อคุณเห็น Backup: MML write backup piece เป็นเหตุการณ์รอในเครื่องมือตรวจสอบหรือบันทึกของ Oracle หมายความว่า RMAN ได้มอบข้อมูลสำรองชุดหนึ่ง หรือ "ชิ้นส่วนสำรอง" ให้กับ Media Management Layer เพื่อทำการเขียนลงในพื้นที่จัดเก็บภายนอก
กระบวนการนี้ถือเป็นเรื่องปกติทุกครั้งที่ตำแหน่งจุดหมายปลายทางของการสำรองข้อมูลของคุณใช้ไดรฟ์เทปหรือเป้าหมายระยะไกล/คลาวด์ที่จัดการโดยซอฟต์แวร์บุคคลที่สาม เหตุการณ์นี้แสดงว่า Oracle กำลังรออยู่ระหว่างที่อุปกรณ์ภายนอกเขียนข้อมูลออกไป โดยทั่วไปมักเกิดขึ้นอย่างรวดเร็ว แต่หากใช้เวลานานเกินไปหรือหยุดนิ่งทั้งหมด อาจหมายความว่ามีบางสิ่งผิดพลาดกับเส้นทางการจัดเก็บข้อมูลของคุณ
ทำไมสิ่งนี้สำคัญ เพราะการรอเป็นเวลานานที่นี่จะทำให้งานสำรองข้อมูลทั้งหมดของคุณช้าลง และอาจนำไปสู่ความล้มเหลวได้ หากไม่ได้รับการแก้ไขอย่างทันท่วงที
ทำไมจะเกิดข้อผิดพลาดในการเขียนชิ้นส่วนสำรอง
ปัญหาส่วนใหญ่ที่เกี่ยวข้องกับการเขียนชิ้นส่วนสำรองไม่ได้เกิดจากข้อผิดพลาดในตัว Oracle เอง แต่มักเป็นอาการของปัญหาที่เกิดขึ้นที่อื่นในโครงสร้างพื้นฐานของคุณ
สาเหตุทั่วไป ได้แก่
ไดรฟ์เทปที่กำลังยุ่งกับงานอื่น ๆ หรือถึงขีดจำกัดด้านประสิทธิภาพแล้ว
อุปกรณ์จัดเก็บข้อมูล (เช่น อุปกรณ์ NAS หรือเกตเวย์คลาวด์) ที่ประสบกับความล่าช้าสูงหรือหยุดทำงาน
ความแออัดของเครือข่ายระหว่างเซิร์ฟเวอร์ฐานข้อมูลของคุณและเป้าหมายการจัดเก็บระยะไกล
ช่องทางหรือพารามิเตอร์ที่ตั้งค่าไม่ถูกต้องภายในการตั้งค่า RMAN/MML
ความล้มเหลวของฮาร์ดแวร์ เช่น สายเคเบิลเสีย ดิสก์/เทปเสื่อมสภาพ หรือทรัพยากรของระบบหมดไปที่ปลายทางใดปลายทางหนึ่ง
เมื่อส่วนใดส่วนหนึ่งของโซ่การทำงานนี้ทำงานช้าลง ไม่ว่าจะเป็นเพราะฮาร์ดแวร์โอเวอร์โหลดหรือการตั้งค่าที่ผิดพลาด ชั้นการจัดการมีเดียจะไม่สามารถรองรับข้อมูลขาเข้าจากรายการ RMAN ได้ทัน ส่งผลให้รายการเหล่านั้นเข้าสู่สถานะรอจนกว่าพื้นที่ว่างจะกลับมาพร้อมใช้งานอีกครั้ง
บางครั้งการรอเหล่านี้จะหายไปเองภายในไม่กี่วินาที แต่บางครั้งก็ยังคงอยู่ต่อไปจนกว่าจะต้องมีการเข้าแทรกแซงด้วยตนเอง
การแก้ปัญหาเกี่ยวกับชิ้นส่วนสำรองข้อมูลล้มเหลวทำอย่างไร?
การแก้ปัญหาเริ่มต้นด้วยการระบุตำแหน่งที่เกิดความล่าช้า ภายใน Oracle เอง หรือที่ใดก็ตามตามเส้นทางไปยังที่จัดเก็บข้อมูลภายนอก
ผู้ดูแลระบบระดับเริ่มต้นควรเริ่มจากการตรวจสอบเหตุการณ์รอปัจจุบันภายใน Oracle:
รันคำสั่ง SQL นี้:
SELECT SID, EVENT, SECONDS_IN_WAIT, STATE
FROM V$SESSION_WAIT
WHERE EVENT LIKE '%MML%';
หากคุณเห็นเซสชันที่ทำงานอยู่และกำลังรอที่ Backup: MML write backup piece โปรดสังเกตว่าพวกเขารออยู่นานแค่ไหน (SECONDS_IN_WAIT) การรอเป็นเวลานานบ่งชี้ถึงปัญหาที่อยู่นอกเหนือการประมวลผลหลักของฐานข้อมูล โดยมักเกิดที่ระดับอุปกรณ์
ขั้นตอนต่อไปขึ้นอยู่กับประเภทของอุปกรณ์ที่ใช้สำรองข้อมูลสำรองของคุณ:
สำหรับห้องสมุดเทป:
สำหรับการจัดเก็บข้อมูลผ่านเครือข่ายหรือระบบคลาวด์:
ผู้ใช้ระดับกลางควรตรวจสอบบันทึกผลลัพธ์ของ RMAN และบันทึกของสื่อจัดการควบคู่กันไปด้วย:
ค้นหาข้อความแสดงข้อผิดพลาดเกี่ยวกับการเขียนล้มเหลว ("ข้อผิดพลาด I/O" "หมดเวลา" ฯลฯ)
ยืนยันว่าข้อผิดพลาดเกิดขึ้นเฉพาะในช่วงเวลาหนึ่งเท่านั้น (ช่วงเร่งด่วนหรือไม่) สิ่งนี้บ่งชี้ถึงปัญหาการแข่งขันทรัพยากร มากกว่าความล้มเหลวโดยตรง
หากคุณสงสัยว่ามีปัญหาเกี่ยวกับการตั้งค่า:
ตรวจสอบให้แน่ใจว่าการตั้งค่าแบบขนานสอดคล้องกับสิ่งที่ฮาร์ดแวร์ของคุณสามารถจัดการได้โดยไม่ทำให้ส่วนประกอบใดส่วนหนึ่งทำงานเกินขีดจำกัด
ตรวจสอบพารามิเตอร์ทั้งหมดที่เกี่ยวข้องซึ่งส่งเข้าไปยังเลเยอร์การจัดการมีเดียว่าถูกต้องตามเอกสารของผู้ให้บริการ
ผู้ใช้ระดับสูงอาจจำเป็นต้องปิดกระบวนการที่ค้างไว้ หากงานไม่สามารถดำเนินการให้เสร็จสิ้นได้:
1. ระบุรหัสประจำตัวเซสชัน/กระบวนการโดยใช้:
SELECT s.SID, p.SPID, s.PROGRAM
FROM V$PROCESS p JOIN V$SESSION s ON p.ADDR = s.PADDR
WHERE s.PROGRAM LIKE '%rman%';
2. ใช้คำสั่งของระบบปฏิบัติการ (เช่น kill บน Linux) เพื่อเป้าหมาย SPID เหล่านั้น แต่ควรตรวจสอบก่อนเสมอว่าการยุติจะรบกวนงานสำคัญอื่นๆ ที่กำลังทำงานอยู่ภายใต้รหัสกระบวนการนี้หรือไม่
โปรดจำไว้: ควรปรึกษาเอกสารอย่างเป็นทางการทุกครั้งก่อนจะบังคับยุติงานที่จัดการโดยซอฟต์แวร์ฝั่งที่สาม การยุติอย่างไม่เหมาะสมอาจทำให้เหลือไฟล์กำพร้าที่ต้องดำเนินการล้างข้อมูลในภายหลัง
การวินิจฉัยคอขวดของเครือข่ายและฮาร์ดแวร์
ปัญหาความล่าช้าที่เกิดจากการ write backup piece อย่างต่อเนื่อง มักเกิดไม่เพียงแต่จากซอฟต์แวร์เท่านั้น แต่ยังมาจากคอขวดของโครงสร้างพื้นฐานทางกายภาพ โดยเฉพาะเมื่อมีการสำรองข้อมูลฐานข้อมูลขนาดใหญ่ผ่านเครือข่ายที่ใช้ร่วมกันหรือระบบเทปที่มีอายุการใช้งานมานาน
เริ่มการวินิจฉัยที่ระดับระบบปฏิบัติการ:
บนเซิร์ฟเวอร์ Linux/Unix:
ใช้ iostat ขณะทำการสำรองข้อมูล สังเกตค่า %iowait ที่สูง ซึ่งบ่งชี้ถึงคอขวดของดิสก์
รันรายงาน sar ทุกชั่วโมง/ทุกวัน สังเกตแนวโน้มที่อัตราการผ่านระบบลดลงต่ำกว่าค่าปกติที่คาดไว้ในระหว่างงานที่กำหนดเวลาไว้
สำหรับการใช้แชร์ที่ติดตั้งผ่าน NFS เป็นเป้าหมาย: ให้รัน nfsstat ก่อน/ระหว่าง/หลังการสำรองข้อมูล; การเพิ่มขึ้นของการส่งซ้ำบ่งชี้ถึงความไม่เสถียรของเครือข่ายที่ส่งผลต่อการเขียนไฟล์
ตรวจสอบสุขภาพของเครือข่ายโดยตรง:
ผู้ดูแลห้องสมุดเทปควรเข้าสู่ระบบแผงควบคุมการจัดการของตนเป็นประจำ:
ตรวจสอบแผงควบคุมสถานะไดรฟ์เพื่อดูสัญญาณการสึกหรอหรือความล้มเหลว ("ต้องการทำความสะอาด", "ข้อผิดพลาดของสื่อ")
ตรวจสอบสถิติอัตราการถ่ายโอนข้อมูลเทียบกับข้อมูลจำเพาะของผู้ผลิต หากอัตรา MB/s ที่ได้จริงต่ำกว่าความเร็วที่ระบุไว้อย่างมาก แม้หลังจากทำความสะอาดหรือดูแลรักษาแล้ว ก็ควรพิจารณาเปลี่ยนฮาร์ดไดรฟ์หรือสื่อบันทึกข้อมูลที่ใช้งานมานานโดยเร็ว
เชื่อมโยงผนในแต่ละระดับพบว่า หากเมตริกในระดับ OS และการรอที่สูงใน Backup: MML write backup piece เพิ่มสูงขึ้นพร้อมกัน คุณน่าจะพบต้นเหตุแล้ว
การป้องกันความล้มเหลวของการเขียนชิ้นส่วนสำรองทำอย่างไร
การป้องกันหมายถึงการสร้างความยืดหยุ่นในทุกลิงก์ระหว่างฐานข้อมูลต้นทางและสื่อปลายทางสุดท้าย รวมถึงการตรวจสอบเชิงรุก เพื่อไม่ให้ปัญหาเล็กน้อยกลายเป็นปัญหาใหญ่ในภายหลัง
ขั้นตอนแรกเกี่ยวข้องกับการตรวจสุขภาพเป็นประจำ: ตรวจสอบให้มั่นใจว่าอุปกรณ์ขับเทป/เครื่องจัดเก็บข้อมูลทุกชิ้นปฏิบัติตามกำหนดการบำรุงรักษาของผู้ผลิต รวมถึงรอบการทำความสะอาด การอัปเดตเฟิร์มแวร์ และการเปลี่ยนชิ้นส่วน เคเบิล ดิสก์ หรือเทปที่สึกหรออย่างสม่ำเสมอตามความจำเป็น อย่าปล่อยให้การบำรุงรักษาที่ล่าช้าสร้างความเสี่ยงที่มองไม่เห็น!
ตั้งค่าการจัดสรรช่องอย่างพิถีพิถัน:
ช่องทางขนานมากเกินไปจะทำให้อุปกรณ์ที่ช้าล้นเกิน ช่องทางน้อยเกินไปจะทำให้แบนด์วิธที่มีอยู่สูญเปล่า ปรับค่า PARALLELISM เพิ่มขึ้นทีละน้อยในขณะที่เฝ้าสังเกตเมตริกประสิทธิภาพแบบเรียลไทม์ผ่าน V$SESSION_WAIT จนกว่าผลลัพธ์จะเริ่มลดลง จากนั้นจึงลดค่าลงเล็กน้อยเพื่อความเสถียร
ตั้งขีดจำกัดที่เหมาะสมโดยใช้ MAXPIECESIZE เพื่อให้ไฟล์แต่ละไฟล์ไม่เกินขีดจำกัดที่อุปกรณ์ปลายทางสามารถจัดการได้อย่างมีประสิทธิภาพ ซึ่งสำคัญอย่างยิ่งเมื่อจัดเก็บฐานข้อมูลขนาดใหญ่ลงในเทปเก่าหรือช่องทางคลาวด์ที่มีแนวโน้มจะหมดเวลาในการถ่ายโอนกลางคัน ตรวจสอบทุกอย่างอย่างต่อเนื่อง ไม่ใช่แค่หลังจากเกิดความล้มเหลว
ตรวจสอบมุมมองการสอบถาม เช่น V$SESSION, V$SESSION_WAIT, V$RMAN_STATUS รายวัน/รายสัปดาห์/รายเดือน ขึ้นอยู่กับขนาดของสภาพแวดล้อม/โปรไฟล์ความเสี่ยง ตั้งค่าการแจ้งเตือนผ่านสคริปต์/เครื่องมือทุกครั้งที่เกิดการเพิ่มขึ้นผิดปกติในช่วงเหตุการณ์สำคัญ เช่น "MML write"
รักษาซอฟต์แวร์/ไดรเวอร์ทั้งหมดให้มีการอัปเดตอยู่เสมอ เวอร์ชันที่ล้าสมัยจะทำให้เกิดปัญหาความไม่เข้ากันหรือประสิทธิภาพลดลงที่วินิจฉัยได้ยาก
การปรับแต่งการกำหนดค่า RMAN สำหรับประสิทธิภาพ MML
การปรับแต่งการตั้งค่า RMAN อย่างละเอียดมีความสำคัญอย่างมากเมื่อทำงานกับการตั้งค่าการจัดการสื่อที่ซับซ้อน โดยเฉพาะเมื่อมีขนาดใหญ่
เริ่มต้นอย่างง่าย: แสดงรายการการกำหนดช่องทาง/อุปกรณ์ปัจจุบันภายใน RMAN shell โดยใช้:
RMAN> LIST DEVICE TYPE ALL;
สิ่งนี้ยืนยันว่าอินเทอร์เฟซ/ช่องทาง SBT (System Backup Tape) ใดได้รับการลงทะเบียนไว้ และช่วยตรวจพบข้อผิดพลาดในการตั้งค่าแต่เนิ่นๆ ก่อนที่จะก่อให้เกิดปัญหาในระบบการผลิต
ปรับความขนานอย่างระมัดระวังตามผลลัพธ์ที่สังเกตได้ ไม่ใช่จากการคาดเดาเพียงอย่างเดียว เริ่มต้นด้วยหนึ่งช่องทางต่อฮาร์ดดิสก์หรือจุดเชื่อมต่อเครือข่ายแต่ละรายการ จากนั้นค่อยๆ เพิ่มจำนวนขึ้นเฉพาะในกรณีที่ไม่มีคอขวดใหม่ปรากฏในสถิติของระบบปฏิบัติการหรือเครือข่าย หรือไม่มีการรอ "เขียน MML" เพิ่มขึ้น
ใช้การจำกัดอัตราอย่างชัดเจนเมื่อจำเป็นผ่าน:
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=...' RATE=50M;
สิ่งนี้ควบคุมความเร็วการถ่ายโอนเพื่อป้องกันไม่ให้จุดปลายทางที่ช้าถูกครอบงำโดยการรบกวนจาก CPU /ดิสก์ที่รวดเร็วกว่า
สำหรับพื้นที่ตารางงานหรือไฟล์ข้อมูลที่มีขนาดใหญ่มาก ควรพิจารณาแบ่งภายในโดยใช้พารามิเตอร์ SECTION SIZE เพื่อให้หลายสตรีมสามารถป้อนข้อมูลไปยังเป้าหมายเดียวกันพร้อมกันได้ โดยไม่เกินขีดจำกัดต่อไฟล์/อุปกรณ์
ตัวอย่างรูปแบบ:
BACKUP AS BACKUPSET DATABASE SECTION SIZE = 10G;
ตรวจสอบความเปลี่ยนแปลงเสมอโดยใช้ภาระงานจริง ไม่ใช่แค่การทดสอบในห้องปฏิบัติการ เพื่อให้มั่นใจว่าความน่าเชื่อถือจะยังคงอยู่ภายใต้สภาวะที่มีการใช้งานสูงสุด
การทำให้การป้องกันข้อมูล Oracle ง่ายขึ้นด้วย Vinchin Backup & Recovery
เพื่อเพิ่มความน่าเชื่อถือและประสิทธิภาพในการปกป้องสภาพแวดล้อมของ Oracle จากปัญหา "Backup: MML write backup piece" องค์กรต่างๆ สามารถใช้Vinchin Backup & Recovery ซึ่งเป็นโซลูชันระดับองค์กรที่ได้รับการยอมรับสำหรับฐานข้อมูลหลักในปัจจุบัน เช่น Oracle (รวมถึง MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro และ TiDB) สำหรับผู้ใช้งาน Oracle ที่ให้ความสำคัญเป็นพิเศษกับการป้องกันอย่างมีประสิทธิภาพในระหว่างการทำงานที่ซับซ้อน เช่น การสำรองข้อมูลแบบเพิ่มเติม และงานฐานข้อมูลแบบชุดที่เกี่ยวข้องกับตัวจัดการสื่อภายนอก (MML) Vinchin Backup & Recovery มีคุณสมบัติต่างๆ เช่น การสนับสนุนการสำรองข้อมูลแบบเพิ่มเติม ความสามารถในการสำรองข้อมูลฐานข้อมูลแบบชุด นโยบายเก็บรักษาข้อมูลที่ยืดหยุ่น รวมถึงตัวเลือกนโยบายการเก็บรักษา GFS กลไกตรวจสอบความสมบูรณ์ของข้อมูลเพื่อรับประกันการกู้คืนได้จริงสำหรับแต่ละงาน โดยใช้การทดสอบตรวจสอบผ่านสคริปต์ SQL ก่อนดำเนินการกู้คืนข้อมูล ทั้งหมดนี้ออกแบบมาเพื่อความมั่นใจสูงสุดในการปฏิบัติงาน พร้อมทั้งช่วยเพิ่มประสิทธิภาพด้านต้นทุนและตอบโจทย์ข้อกำหนดด้านความสอดคล้องตามกฎระเบียบในโครงสร้างพื้นฐานแบบไฮบริด
คอนโซลเว็บที่ใช้งานง่ายช่วยปรับปรุงการทำงานทุกขั้นตอน ด้วยสี่ขั้นตอนที่เรียบง่ายและออกแบบมาโดยเฉพาะสำหรับสภาพแวดล้อมของ Oracle:
ขั้นตอนที่ 1 เลือกฐานข้อมูล Oracle ที่ต้องการสำรองข้อมูล
ขั้นตอนที่ 2 เลือกพื้นที่จัดเก็บข้อมูลสำรอง
ขั้นตอนที่ 3 กำหนดกลยุทธ์การสำรองข้อมูล
ขั้นตอนที่ 4 ส่งงาน
เป็นที่ยอมรับไปทั่วโลกด้วยคะแนนสูงสุดในหมู่ลูกค้าองค์กรที่ต้องการโซลูชันป้องกันข้อมูลที่เชื่อถือได้ ด้วยผู้ใช้งานนับพันที่วางใจเทคโนโลยีที่ได้รับการพิสูจน์แล้ว คุณสามารถทดลองใช้ Vinchin Backup & Recovery โดยไม่มีความเสี่ยง ด้วยเวอร์ชันทดลองฟรีที่มีฟีเจอร์ครบถ้วน ใช้งานได้ 60 วัน คลิกดาวน์โหลดเดี๋ยวนี้และสัมผัสประสบการณ์ความง่ายยุคใหม่ด้วยตัวคุณเอง
คำถามที่พบบ่อยเกี่ยวกับ Backup MML Write Backup Piece
คำถามที่ 1 ผมจะทราบได้อย่างไรว่าปัญหาของผมเกี่ยวข้องเฉพาะกับ "การสำรองข้อมูล: การเขียน MML" ต่างจากประเภทการรอ I/O อื่นๆ?
ตรวจสอบการรอในเซสชันที่ V$SESSION_WAIT แล้ว"MML write" บ่งชี้ถึงความล่าช้าในการเขียนผ่านตัวจัดการสื่อ ในขณะที่ "datafile i/o" ชี้ไปที่การอ่านไฟล์ต้นทางแทน
คำถามที่ 2 ผมสามารถรีสตาร์ทงานที่ถูกขัดจังหวะซึ่งติดอยู่ที่ "เขียนชิ้นส่วนสำรอง" ได้อย่างปลอดภัยโดยไม่เสี่ยงต่อความเสียหายได้ไหม?
ได้ ตราบใดที่ชิ้นส่วนที่ไม่สมบูรณ์ถูกลบออกก่อนตามแนวทางของผู้ให้บริการ ก่อนดำเนินงานที่ได้รับผลกระทบใหม่ตั้งแต่เริ่มต้น
คำถามที่ 3 การตรวจสอบอย่างรวดเร็วใดบ้างที่ช่วยระบุปัญหาพื้นฐานของเครือข่ายที่ทำให้การเขียนข้อมูลช้าลง?
ทดสอบการเชื่อมต่อโดยใช้ PING STORAGE_IP จากนั้นตรวจสอบผลลัพธ์ของ IOSTAT/NFSSTAT ระหว่างการถ่ายโอนตัวอย่าง
บทสรุป
การเข้าใจว่าทำไมจึงเกิด "Backup MML Write Backup Piece" จะช่วยให้ผู้ดูแลระบบสามารถแก้ไขปัญหาความช้าได้อย่างรวดเร็ว ตั้งแต่การตรวจสอบสุขภาพของอุปกรณ์ไปจนถึงการปรับพารามิเตอร์ขั้นสูงภายใน RMAN โดยมีการตรวจสอบอย่างต่อเนื่องพร้อมโซลูชันที่แข็งแกร่งอย่าง Vinchin ซึ่งมีให้ใช้งานในปัจจุบัน ทำให้การรักษาความปลอดภัยของข้อมูลสำรองที่สำคัญต่อภารกิจเป็นเรื่องง่ายกว่าที่เคย
