มาถึง ตอนสุดท้าย ของ RMAN แล้วนะครับ .. หลังจากเรียนเรื่อง backup มา 3 ตอน ... ตอนนี้ก็เป็นตอนสำคัญแล้ว
ตำราพิชัยสงครามกล่าวเอาไว้ว่า "เลี้ยงทหารพันวัน เพื่อเอาไว้ใช้งานวันเดียว" .. ชีวิต DBA ก็เหมือนกันครับ .. ฺ Backup Database พันวัน เอาไว้ใช้วันสำคัญวันเดียว ... วันที่ฐานข้อมูลมีปัญหา !!! .. แต่ถ้าเป็นไปได้ ก็ไม่อยากให้ถึงวันนั้นครับ -_-''
แต่อะไรที่มันจะเกิด มันก็ต้องเกิด .. แต่เนื่องจาก เรามีการแบ็คอัพข้อมูลอย่างสม่ำเสมอ รวมถึง เปิด archive log mode เอาไว้แล้ว อยู่มาวันหนึ่ง datafiles เรามีปัญหา เช่น มีมือที่มองไม่เห็นมาลบ data files หรือ ตัว datafile เองเกิด disk corrupt .. ก็ถึงเวลาที่เราต้องทำการ recovery data แล้วครับ
โปรดสังเกตว่า เมื่อ data files พัง เวลาเรา restart database จะ start ได้แค่ถึงโหมด MOUNT เท่านั้น
ในที่นี้ เราจะใช้ RMAN ทำการ recovery ฐานข้อมูลแบบง่ายที่สุด แต่ได้ข้อมูลมาถึงปัจจุบันมากที่สุด ก่อนฐานข้อมูลพัง
ขอเตือนความจำอีกครั้ง ผมกล่าวตั้งแต่ Part 1 แล้วว่า จุดประสงค์หลักของ RMAN เอาไว้กู้คืนฐานข้อมูล เวลามีปัญหาที่ data files นะครับ ถึงแม้มันจะใช้เวลามี control file มีปัญหาได้ด้วย แต่วิธีที่ดีที่สุดของ control files , redo log files คือ ทำ multiplex
RMAN> RUN {
restore database ;
recover database ;
sql ' alter database open ' ;
}
คำอธิบาย
RUN {
......
}
เป็นการ run คำสั่งแบบเป็นชุด ไม่ต้อง enter ทีละคำสั่ง
restore database ;
เป็นการนำไฟล์ที่ RMAN แบ็คเอาเอาไว้ กลับมาลงที่เดิม สังเกตว่า เราไม่ต้องระบุว่า ต้องไปดึงไฟล์แบ็คอัพมาจากที่ไหน? เนื่องจากเราตั้งค่าใน Part 1 แล้ว
recover database ;
เนื่องจากไฟล์แบ็คอัพที่นำมาลงกู้คืนนั้น เป็นไฟล์ที่อายุเก่ากว่า ไฟล์อื่นๆ และ control file ในปัจจุบัน ทำให้ SCN (System Change Number ) เป็น SCN ที่เก่ากว่า ทำให้ยังไม่สามารถเปิดฐานข้อมูลในไปโหมด OPEN ได้
การ recover database จึงเป็นการทำให้ SCN ของไฟล์แบ็คอัพที่เอามากู้คืน เท่ากับ SCN ปัจจุบัน โดยดึง transaction ที่เก็บใน archivelog files มาเติมเต็ม ดังนั้น SCN จึงได้มาเท่าปัจจุบัน และ ข้อมูลจะกลับมาเท่าเดิมก่อนที่ฐานข้อมูลจะพัง
sql ' alter database open ' ;
เป็นการสั่งให้ฐานข้อมูล เปิดขยับขึ้นเป็นโหมด OPEN ซึ่งเป็นโหมดที่ทุกคน สามารถใช้งานได้ตามปรกติ |
