การใช้ RMAN Transportable Tablespace เพื่อการย้ายข้อมูล Oracle อย่างรวดเร็วทำอย่างไร?

การย้ายข้อมูลจำนวนมากระหว่างฐานข้อมูล Oracle เป็นความท้าทายทั่วไปสำหรับทีมปฏิบัติการด้านไอที การหยุดทำงานจะต้องถูกลดให้น้อยที่สุดเพื่อรักษางานธุรกิจให้ดำเนินไปอย่างราบรื่น คุณสมบัติ RMAN transportable tablespace มีโซลูชันที่มีประสิทธิภาพสำหรับการโยกย้ายเหล่านี้ โดยอนุญาตให้คุณย้าย tablespace ได้อย่างรวดเร็ว แม้กระทั่งข้ามแพลตฟอร์มที่แตกต่างกัน โดยการทำงานในระดับไฟล์ทางกายภาพ แทนที่จะส่งออกและนำเข้าข้อมูลทุกแถว

ในบทความนี้ เราจะอธิบายว่า RMAN transportable tablespace คืออะไร ทำไมสำคัญต่อผู้ดูแลฐานข้อมูล และวิธีการใช้งานทีละขั้นตอน นอกจากนี้เรายังจะครอบคลุมถึงการตรวจสอบก่อนการย้ายข้อมูลที่สำคัญ ซึ่งสามารถช่วยประหยัดเวลาในการแก้ไขปัญหาในภายหลังได้หลายชั่วโมง เพื่อการเปรียบเทียบ เราจะพิจารณาการใช้ Data Pump เป็นทางเลือกหนึ่ง สุดท้าย เราจะแสดงให้คุณเห็นวิธีการปกป้องฐานข้อมูล Oracle ของคุณหลังการโยกย้ายด้วย Vinchin

RMAN Transportable Tablespace คืออะไร?

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

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

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

ทำไมต้องใช้ RMAN Transportable Tablespace?

สำหรับผู้ดูแลระบบปฏิบัติการที่ได้รับมอบหมายให้ย้ายข้อมูลปริมาณมากในขณะที่ลดช่วงเวลาหยุดทำงานให้น้อยที่สุด การเลือกเครื่องมือที่เหมาะสมจึงมีความสำคัญ มาดูกันว่าทำไม RMAN transportable tablespace โดดเด่น

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

ประการที่สอง คุณสามารถย้ายข้อมูลระหว่างระบบปฏิบัติการหรือแพลตฟอร์มฮาร์ดแวร์ที่ต่างกันได้ตราบเท่าที่รูปแบบไบต์ตรงกัน หรือใช้ความสามารถในการแปลงของ RMAN หากไม่ตรงกัน

ประการที่สาม ด้วยการรองรับการกู้คืนข้อมูล ณ จุดเวลาที่กำหนดในเวิร์กโฟลว์ของ RMAN (โดยใช้ SCN หรือ timestamp) คุณจะได้รับความยืดหยุ่นสำหรับสภาพแวดล้อมการรายงานผล หรือการโคลนข้อมูลการผลิตอย่างปลอดภัย

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

มันเปรียบเทียบกับ Data Pump อย่างไร นี่คือภาพเปรียบเทียบอย่างรวดเร็ว:

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

การตรวจสอบก่อนการย้ายข้อมูลที่สำคัญ

ก่อนเริ่มต้นการย้ายข้อมูลใดๆ โดยใช้ tablespace แบบพกพา ไม่ว่าจะผ่าน RMAN หรือ Data Pump สิ่งสำคัญคือต้องตรวจสอบข้อกำหนดหลักหลายประการล่วงหน้า การข้ามขั้นตอนเหล่านี้มักนำไปสู่ความล้มเหลวในการย้ายข้อมูล หรือเกิดข้อผิดพลาดที่ไม่คาดคิดในระหว่างกระบวนการ

ข้อแรก ตรวจสอบการแยกตัวเอง

พื้นที่ตารางแบบแยกตัวเองได้ หมายความว่า อ็อบเจกต์ทั้งหมดของมันอยู่ภายในตัวมันเองอย่างสมบูรณ์ โดยไม่มีการอ้างอิงไปยังส่วนอื่นนอกเหนือจากพื้นที่ตารางอื่น ๆ ยกเว้น SYSTEM/SYSAUX ซึ่งอนุญาตให้ทำได้ เพื่อตรวจสอบสิ่งนี้:

EXEC DBMS_TTS.TRANSPORT_SET_CHECK('TBS1,TBS2', TRUE);
SELECT * FROM TRANSPORT_SET_VIOLATIONS;

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

ข้อที่สอง ตรวจสอบความเข้ากันได้ของแพลตฟอร์ม

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

SELECT * FROM V$TRANSPORTABLE_PLATFORM;

เปรียบเทียบค่า PLATFORM_NAME ระหว่างฐานข้อมูลต้นทางและปลายทาง หากมีความแตกต่างกันในเรื่อง endianness (คอลัมน์ ENDIAN_FORMAT) ให้วางแผนการใช้คำสั่ง CONVERT ของ RMAN ระหว่างกระบวนการย้ายข้อมูล

ข้อที่สาม ขนาดบล็อกและการเข้ากันได้ของชุดอักขระ

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

ข้อที่สี่: ความต้องการพื้นที่

ตรวจสอบให้แน่ใจว่ามีพื้นที่ดิสก์เพียงพอ:

• ในเซิร์ฟเวอร์ต้นทาง สำหรับการสร้างอินสแตนซ์เสริม

• ในไดเรกทอรีปลายทางเสริม สำหรับการจัดเก็บชั่วคราว

• ในเซิร์ฟเวอร์เป้าหมาย สำหรับไฟล์ข้อมูลขาเข้าพร้อมพื้นที่สำรองสำหรับการขยายตัว

ข้อที่ห้า สิทธิพิเศษและการเข้าถึง

คุณต้องมีสิทธิ์ระดับผู้ดูแลระบบ เช่น บทบาท SYSDBA หรือ SYSBACKUP บนทั้งสองฐานข้อมูล รวมถึงบทบาท EXP_FULL_DATABASE/IMP_FULL_DATABASE เพื่อรันยูทิลิตี้ Data Pump ภายใน Oracle

การใช้เวลาในตอนนี้จะทำให้ขั้นตอนต่อไปเป็นไปอย่างราบรื่น

วิธีที่ 1. ใช้ RMAN สำหรับการย้าย Tablespace แบบพกพา

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

นี่คือวิธีที่มันเปิดเผยออกมา:

ขั้นตอนที่ 1 เตรียมสภาพแวดล้อมของคุณ

เชื่อมต่อในฐานะผู้ใช้ที่มีสิทธิ์ SYSDBA, SYSBACKUP หรือสิทธิ์เทียบเท่าในฐานข้อมูลต้นทางและปลายทางทั้งสองระบุว่าจะย้าย tablespace ใด ตรวจสอบชื่อของ tablespace เหล่านั้นกับผลลัพธ์จากการตรวจสอบ containment ก่อนหน้าเพื่อให้แน่ใจว่าไม่มีสิ่งใดถูกละเว้นโดยไม่ได้ตั้งใจ

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

ขั้นตอนที่ 2 รันคำสั่ง TRANSPORT TABLESPACE ใน RMAN

เริ่มต้นโปรแกรม Recovery Manager ไคลเอ็นต์ (rman) ที่เชื่อมต่อกับอินสแตนซ์ฐานข้อมูลต้นทางของคุณ:

RMAN> TRANSPORT TABLESPACE tbs1,tbs2
    AUXILIARY DESTINATION '/tmp/aux'
    TABLESPACE DESTINATION '/tmp/tts';

ที่นี่

• ปลายทางเสริม ชี้ไปยังไดเรกทอรีที่ Oracle สร้างอินสแตนซ์เสริมซึ่งใช้ชั่วคราวระหว่างการกู้คืน; ตรวจสอบให้แน่ใจว่ามีพื้นที่ว่างเพียงพอที่นี่ ไม่ใช่แค่สำหรับไฟล์ข้อมูลของผู้ใช้เท่านั้น แต่รวมถึงสำเนา SYSTEM/SYSAUX/UNDO/TEMP ด้วย

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

หมายเหตุ: ถ้ามีการย้ายข้ามแพลตฟอร์มที่มีรูปแบบไบต์ออร์เดอร์ต่างกัน ให้เพิ่ม:

RMAN> CONVERT TABLESPACE tbs1,tbs2 TO PLATFORM 'Linux x86 64-bit' FORMAT '/tmp/convert/%U';

การแปลงนี้จะเปลี่ยนแต่ละไฟล์ให้อยู่ในรูปแบบที่เหมาะสมพร้อมสำหรับการนำเข้าที่ปลายทาง

ขั้นตอนที่ 3 ให้ RMAN ดำเนินการขั้นตอนหลักโดยอัตโนมัติ

เบื้องหลังในขณะนี้:

1. อินสแตนซ์เสริมจะเริ่มทำงานโดยอัตโนมัติภายใต้ /tmp/aux

2. การกู้คืนพื้นที่ตารางเป้าหมายถึง SCN/เวลา ที่กำหนดไว้

3. แต่ละรายการจะกลายเป็นแบบอ่านอย่างเดียวภายในสภาพแวดล้อมเสริม

4. ส่งออร์เมตาดาต้าผ่านการเรียกใช้ภายในไปยังยูทิลิตี้ Data Pump

5. เอาต์พุตทั้งหมดอยู่ภายใน /tmp/tts อย่างเป็นระเบียบ

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

ขั้นตอนที่ 4 ย้ายไฟล์ระหว่างเซิร์ฟเวอร์

คัดลอกไฟล์ .dbf ที่ได้ผลรวมทั้งข้อมูลดัมป์ที่ส่งออก (dmpfile.dmp) อย่างปลอดภัยจากเซิร์ฟเวอร์ต้นทางผ่านเครือข่ายไปยังเครื่องหรือตำแหน่งเป้าหมายโดยใช้ SCP/SFTP/การเชื่อมต่อ NFS หรือวิธีใดก็ตามที่เหมาะสมกับนโยบายความปลอดภัยของคุณที่สุด

ตรวจสอบความถูกต้องของไฟล์อีกครั้งหลังการถ่ายโอนโดยการเปรียบเทียบค่าเช็คซัม หากทำได้ เพราะการสำเนาที่เสียหายจะทำให้สูญเสียเวลาอันมีค่าในภายหลังเมื่อลองนำเข้าข้อมูล!

ขั้นตอนที่ 5 เสียบ tablespaces เข้ากับฐานข้อมูลเป้าหมาย

ในระบบเป้าหมาย ให้เชื่อมต่ออีกครั้งในฐานะผู้ใช้งานที่มีสิทธิพิเศษ จากนั้นรันสคริปต์ SQL ที่จัดเตรียมไว้ (impscrpt.sql) ซึ่งสร้างไว้ก่อนหน้า หรือใช้เครื่องมือนำเข้าข้อมูลแบบ Data Pump มาตรฐานดังนี้:

impdp system/password \
   dumpfile=dmpfile.dmp \
   directory=DATA_PUMP_DIR \
   transport_datafiles='/tmp/tts/tbs1.dbf','/tmp/tts/tbs2.dbf' \
   logfile=tts_import.log

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

ขั้นตอนที่ 6 ตั้งค่าพื้นที่ตารางที่นำเข้ากลับเป็นอ่านและเขียนได้

หลังจากนำเข้าสำเร็จ ให้สลับพื้นที่ตารางที่ขนส่งแต่ละรายการกลับมาออนไลน์:

ALTER TABLESPACE tbs1 READ WRITE;
ALTER TABLESPACE tbs2 READ WRITE;

ขณะนี้ผู้ใช้/แอปพลิเคชันสามารถกลับมาดำเนินกิจกรรมตามปกติได้ทันที

ขั้นตอนที่ 7 ตรวจสอบความสำเร็จของการย้าย

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

EXEC DBMS_TTS.TRANSPORT_SET_CHECK('TBS1,TBS2', TRUE);
SELECT * FROM TRANSPORT_SET_VIOLATIONS;

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

วิธีที่ 2. ใช้ Data Pump สำหรับการย้าย Tablespace แบบพกพา

บางครั้งอาจไม่ต้องใช้ระบบอัตโนมัติ หรือบางทีคุณอาจต้องการควบคุมสิ่งที่ต้องย้ายอย่างละเอียดมากกว่าความเร็วเพียงอย่างเดียว? ในกรณีเหล่านี้พิจารณาใช้ชุดเครื่องมือการส่งออก/นำเข้าเชิงตรรกะในตัวของ Oracle ที่รู้จักกันในชื่อ Data Pump แทน:

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

นี่คือลักษณะของขั้นตอนการทำงานทั่วไป:

ขั้นตอนที่ 1 ตรวจสอบความสมบูรณ์ของตนเองอีกครั้ง

เช่นเดียวกับการรันด้านบน:

EXEC DBMS_TTS.TRANSPORT_SET_CHECK('TBS1,TBS2', TRUE);
SELECT * FROM TRANSPORT_SET_VIOLATIONS;

แก้ไขข้อผิดพลาดที่ระบุไว้ทั้งหมดก่อนดำเนินการต่อ…

ขั้นตอนที่ 2 ตั้งค่า tablespaces ต้นทางให้อ่านอย่างเดียว

ล็อกพื้นที่เป้าหมายเพื่อไม่ให้มีการเปลี่ยนแปลงระหว่างการส่งออก

ALTER TABLESPACE tbs1 READ ONLY;
ALTER TABLESPACE tbs2 READ ONLY;

ยืนยันสถานะผ่านการสอบถามมุมมอง DBA_TABLESPACES หากไม่แน่ใจ…

ขั้นตอนที่ 3 ส่งออกเมตาดาต้าโดยใช้ยูทิลิตี้ expdp

เริ่มต้นการส่งออกโดยระบุพารามิเตอร์ที่เกี่ยวข้อง รวมถึงพื้นที่ใดบ้างที่เข้าร่วม/การตั้งค่าการบันทึกข้อมูล ฯลฯ

expdp system/password \
   dumpfile=tts_exp.dmp \
   directory=DATA_PUMP_DIR \
   transport_tablespaces=TBS1,TBS2 \
   transport_full_check=Y \
   logfile=tts_export.log

ติดตามความคืบหน้าและผลลัพธ์อย่างใกล้ชิด โดยเฉพาะข้อผิดพลาด ORA ที่บ่งชี้ปัญหาสิทธิ์การเข้าถึงหรือการพึ่งพาที่หายไป เป็นต้น

เคล็ดลับ: สำหรับการย้ายข้ามแพลตฟอร์ม ให้แปลงไฟล์ .dbf ที่เป็นรูปธรรมล่วงหน้าโดยใช้คำสั่ง CONVERT เดียวกันที่อธิบายไว้ก่อนหน้านี้ภายใต้วิธีที่ #1 ข้างต้น

ขั้นตอนที่ 4 คัดลอกไฟล์ผลลัพธ์ผ่านเครือข่ายไปยังเซิร์ฟเวอร์เป้าหมาย

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

ตรวจสอบความสมบูรณ์หลังการถ่ายโอนทุกครั้งเมื่อเป็นไปได้...

ขั้นตอนที่ 5 เสียบ Spaces เข้ากับอินสแตนซ์ฐานข้อมูลใหม่

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

impdp system/password \
    dumpfile=tts_exp.dmp \
    directory=DATA_PUMP_DIR \
    transport_datafiles='/path/to/tbs1.dbf','/path/to/tbs2.dbf' \
    logfile=tts_import.log

ตรวจสอบผลลัพธ์ในไฟล์บันทึกเพื่อยืนยันการดำเนินการสำเร็จ/ไม่มีคำเตือนหรือข้อผิดพลาดที่ยังคงค้างอยู่...

คำแนะนำ: ถ้าพบข้อผิดพลาด "ORA-" ให้ตรวจสอบบันทึกการส่งออกและการนำเข้าอย่างระมัดระวัง มักจะชี้ไปยังสาเหตุหลักที่ต้องดำเนินการแก้ไขตามลำดับต้นน้ำหรือปลายน้ำอย่างเหมาะสม...

ขั้นตอนที่ 6 กู้คืนสถานะการอ่านและเขียนหลังจากการนำเข้า

นำพื้นที่ที่เพิ่งนำเข้าใหม่กลับมาใช้งานได้อีกครั้งในโหมดทำงานเต็มรูปแบบ...

ALTER TABLESPACE tbs1 READ WRITE;
ALTER TABLESPACE tbs2 READ WRITE;

การปกป้อง Oracle Database ของคุณหลังจากการย้ายข้อมูลด้วย Vinchin Backup & Recovery

หลังจากการย้ายข้อมูลที่ประสบความสำเร็จ การรักษาความปลอดภัยให้กับสภาพแวดล้อม Oracle ของคุณถือเป็นสิ่งสำคัญอันดับแรก Vinchin Backup & Recovery เป็นโซลูชันระดับองค์กรที่รองรับฐานข้อมูลหลักในปัจจุบัน ได้แก่ Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro และ TiDB พร้อมความสามารถในการทำงานร่วมกันอย่างแข็งแกร่งที่ออกแบบมาโดยเฉพาะเพื่อตอบสนองความต้องการปฏิบัติงานของสภาพแวดล้อม Oracle เช่นเดียวกับของคุณเป็นอันดับแรก

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

ด้วยอินเทอร์เฟซเว็บคอนโซลของ Vinchin Backup & Recovery การสำรองข้อมูล Oracle ฐานข้อมูลของคุณจะใช้เพียง 4 ขั้นตอนง่ายๆ เท่านั้น

ขั้นตอนที่ 1 เลือกฐานข้อมูล Oracle ที่ต้องการสำรองข้อมูล

ขั้นตอนที่ 2 เลือกที่จัดเก็บข้อมูลสำรอง

ขั้นตอนที่ 3 กำหนดกลยุทธ์การสำรองข้อมูลของคุณ

ขั้นตอนที่ 4 ส่งงาน

ได้รับการยอมรับในระดับโลกโดยองค์กรต่างๆ ด้วยความน่าเชื่อถือและใช้งานง่าย  พร้อมคะแนนรีวิวจากลูกค้าที่ยอดเยี่ยม  Vinchin Backup & Recovery มอบทดลองใช้ฟรี 60 วันเพื่อให้คุณได้สัมผัสประโยชน์ด้วยตนเอง คลิกด้านล่างเพื่อเริ่มใช้งานได้เลยวันนี้

คำถามที่พบบ่อยเกี่ยวกับ RMAN transportable tablespace

คำถามที่ 1. หากแหล่งที่มาของผมมีพื้นที่เข้ารหัส ใช้พื้นที่ตารางแบบพกพาด้วย RMAN ได้ไหม?

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

คำถามที่ 2. หากแพลตฟอร์มทั้งสองของผมมีรูปแบบเอนเดียนต่างกันจะเกิดอะไรขึ้น?

ใช้คำสั่ง CONVERT ภายในกระบวนการทำงานของ Recovery Manager เพื่อแปลงไฟล์ .dbf ที่เกี่ยวข้องโดยตรง ก่อนดำเนินการเชื่อมต่อในขั้นตอนถัดไป

คำถามที่ 3. อะไรคือสาเหตุที่ทำให้การรัน TRANSPORT TABLESPACE ล้มเหลวบ่อยที่สุด?

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

สรุป

RMAN transportable tablespace มอบวิธีการที่รวดเร็วและน่าเชื่อถือให้กับทีมปฏิบัติการในการย้ายข้อมูล Oracle จำนวนมหาศาล แม้ข้ามแพลตฟอร์ม ด้วยความหยุดชะงักน้อยที่สุดเมื่อเทียบกับวิธีการเดิม ขณะเดียวกันยังคงมีตัวเลือกสำรอง เช่น Data Pump เมื่อต้องการความเฉพาะเจาะจงมากกว่า จากนั้นรับประกันความปลอดภัยของทุกอย่างได้อย่างง่ายดายด้วยโซลูชันสมัยใหม่ เช่น Vinchin ที่นำเสนอการป้องกันแบบอัตโนมัติอย่างราบรื่นในทุกขั้นตอนของการดำเนินการต่อไป