ถัดจากตอนที่แล้ว เรื่องในตอนนี้จะเกี่ยวกับการ Database Recovery เมื่อเกิด Database Files ทั้งหลายเสียหายเราต้องมีวิธีแก้ไข ซึ่งตรงนี้ได้แบ่งการแก้ปัญหาแต่ละ file ดังนี้
Control File เสียหาย
เมื่อ Control File เสียหายจะทำให้ startup database ไม่ขึ้น ถ้าเราพยายาม startup database ถึงแค่ nomount mode ตัวอย่าง ถ้ามี control file 03 เสียหาย
NOTE: เมื่อ database มีปัญหาเราควรเข้าไปดู alert log ของ database ซึ่ง path จะถูกกำหนดที่ parameter BACKGROUND_DUMP_DEST (default path:/admin//bdump/alertlog)
Redo Log File เสียหาย
ถ้าใน 1 group มี 2 member แล้วเสียหายไป 1 member database ยังทานได้โดยไม่ส่งผลกระทบอะไรยัง startup database ได้เหมือนเดิม ซึ่งจะไม่เหมือนกับ control file ที่จะ startup database ไม่ได้ ส่วน DBA จะรู้ก่อนต่อเมื่อเข้าไปดูใน alert log
วิธีแก้เมื่อ redo log file เสียหาย ให้ shutdown database จากนั้นเข้าไป copy redo log file ที่ใช้งานได้แล้วนำไปวางใน path ของ redo log file ที่เสียหายแล้ว rename ให้ชื่อเหมือนเดิม
Data File เสียหาย
Control File เสียหาย
เมื่อ Control File เสียหายจะทำให้ startup database ไม่ขึ้น ถ้าเราพยายาม startup database ถึงแค่ nomount mode ตัวอย่าง ถ้ามี control file 03 เสียหาย
- จะมีวิธีแก้อยู่ 2 วิธี
- ให้ oracle มาใช้งานแค่ control file 01, 02 แทน โดยแก้ parameter CONTROL_FILES=’…’, ‘…’ ใหม่ให้อ่าน Control file แค่ 2 ตัวที่ใช้งานได้
- สร้าง control file แทนที่ตัวที่เสียหาย Shutdown database ก่อน แล้วเข้าไปที่ path control file ที่ใช้งานได้แล้ว copy control file ไปวางไว้ใน path control file ที่เสียหาย จากนั้น rename ให้ชื่อเหมือน control file ตัวที่เสียหาย แล้ว startup database ตามปกติก็ใช้งานได้เหมือนเดิม
NOTE: เมื่อ database มีปัญหาเราควรเข้าไปดู alert log ของ database ซึ่ง path จะถูกกำหนดที่ parameter BACKGROUND_DUMP_DEST (default path:
Redo Log File เสียหาย
ถ้าใน 1 group มี 2 member แล้วเสียหายไป 1 member database ยังทานได้โดยไม่ส่งผลกระทบอะไรยัง startup database ได้เหมือนเดิม ซึ่งจะไม่เหมือนกับ control file ที่จะ startup database ไม่ได้ ส่วน DBA จะรู้ก่อนต่อเมื่อเข้าไปดูใน alert log
วิธีแก้เมื่อ redo log file เสียหาย ให้ shutdown database จากนั้นเข้าไป copy redo log file ที่ใช้งานได้แล้วนำไปวางใน path ของ redo log file ที่เสียหายแล้ว rename ให้ชื่อเหมือนเดิม
Data File เสียหาย
- ถ้า data file เสียหายจะแบ่งออกได้เป็น 2 แบบคือ
- Noarchivedlog mode แก้ปัญหาโดย shutdown database ก่อนจากนั้น เอา backup มา restore แต่ข้อมูลที่ได้กลับมาจะเป็นข้อมูลที่ backup ครั้งล่าสุดเอาไว้
- Archivedlog mode การแก้ต้องทำ 2 ขั้นตอนคือ restore + recovery แบ่งออกเป็น 2 ประเภท
- Startup database mount mode
- ALTER DATABASE DATAFILE <หมายเลข datafile ที่เสียหาย> offline;
- ALTER DATABASE OPEN;
- ALTER tablespace <ชื่อ tablespace> offline
- RMAN sys/oracle (อีก session)
- RESTORE TABLESPACE <ชื่อ tablespace> ที่จะทำการ resotre); ลองดูใน database physical path น่าจะกลับมาแล้ว
- RECOVER TABLESPACE <ชื่อ tablespace> online
- ALTER DATABASE DATAFILE <หมายเลข datafile ที่เสียหาย> online;
- Shutdown database
- Startup mount
- RMAN sys/oracle
- RESTORE TABLESPACE <…>
- RECOVER TABLESPACE <…>
- ALTER DATABASE OPEN;
- 1. Noncritical data file ก็ต่อเมื่อ data file ที่เสียหายนั้นไม่ได้เป็นของ Tablespace system, undo สำหรับเครื่อง production เราต้องทำให้ database กลับมา open ให้ได้ก่อนเพื่อให้ใช้งาน tablespace อื่นที่ไม่เสียหายไปก่อน โดยการ
- 2. Critical data file การแก้ปัญหาต้องทำที่ mount mode เท่านั้น เพราะ tablespace system, undo offline ไม่ได้ จึงไม่สามารถแก้ไขให้ database open เริ่มแก้ไขโดยการ
1 comment:
ขอบคุณครับ หามานานแ้ล้วครับ บทความเคลียๆอย่างนี้ ^o^
Post a Comment