Oracle

Oracle Database

posted on 29 Jun 2008 15:59 by itknow  in Oracle

Oracle Database Server เป็น Object-Relational Database Management System (ORDBMS)
หมายความว่า สามารถทำงานได้ ทั้งในรูปแบบ Rational และบางคุณสมบัติของ Object Oriented ได้
โดย Oracle Database Server นั้น มีความสามารถทำงานร่วมกันกับ Software หลายๆ ตัวได้ จากผู้ผลิตหลายราย และสนับสนุนมาตรฐานระบบเปิดต่าง ๆ

Oracle Database Server จะประกอบด้วย 2 ส่วนหลัก คือ
  1. Oracle Database จะเป็นส่วนของการจัดเก็บข้อมูล
  2. Oracle Server Instance จะประกอบด้วย Memory และ Background Process

ในการติดต่อใช้งานกับ Oracle Database นั้น เราต้องใช้ภาษา SQL ( ซึ่งบางท่านเรียกว่า SEQUEL) ซึ่งเป็นภาษาที่ใช้ในการกำหนด และจัดการกับ Database (DDL, DML) การทำงานกับ Database ที่สนับสนุน การทำงานแบบ Relational Database นั้นหมายความว่า จะมีการจัดเก็บข้อมูล ในลักษณะที่เป็นกลุ่มของข้อมูล ที่มีความสัมพันธ์กัน ใน 1 Database สามารถที่จะมี Table ตั้งแต่ 1 table เป็นต้นไป และในแต่ละ Table นั้น ก็สามารถมีได้หลาย Column หลาย Row ยกตัวอย่างเช่น เราต้องการเก็บข้อมูลของพนักงาน ใน Table ของข้อมูลพนักงานก็จะประกอบด้วย Column ที่ อธิบายชื่อ นามสกุล ที่อยู่ เงินเดือน แผนกที่สังกัด เป็นต้น และใน Table นั้น ก็สามารถที่จะมีข้อมูลพนักงานได้มากกว่า 1 คน ( Row)

 

 

 

  • Data files
  • Control files
  • Redo log files
  • Archived log files
  • Parameter file
  • Password file

Oracle Database  คือส่วนของ Oracle Server ที่จะจัดเก็บข้อมูลต่าง ๆ ไว้ที่ storageที่เป็นลักษณะ Persistence หรือเรียกง่าย ๆ ว่าถ้าปิดไฟฟ้าแล้วข้อมูลต้องยังอยู่ซึ่งแน่นอนว่า Disk เป็น Storage ที่เป็นที่นิยมที่สุด กล่าวโดยสรุปก็คือ Oracle Database จะถูกจัดเก็บบน Disk ในลักษณะเป็น files โดยแบ่งเป็นประเภท ดังนี้

Data Files
คือ ส่วนในการจัดเก็บข้อมูลของระบบฐานข้อมูล ซึ่ง Data File นั้นเป็นชื่อเรียกทาง Physical ในขณะที่ทาง Logical จะเรียกว่า Tablespace โดยจะทำการตัดแบ่งไฟล์ไปจัดเก็บในหน่วยเล็กๆ ที่เรียกว่า Data blocks โดยส่วนหัวของบล็อกจะเรียกว่า Header ซึ่งจะจัดเก็บรายละเอียดของ Data Files เช่นขนาดของไฟล์ ขนาดของบล็อก พื้นที่จัดเก็บตาราง เวลาที่สร้าง เป็นต้น เมื่อมีการเปิดใช้งานข้อมูลในฐานข้อมูล ออราเคิลจะทำการตรวจสอบ รายละเอียดของไฟล์ที่ส่วนหัวนี้ เพื่ออ่านข้อมูลใน Data Files มาเก็บในหน่วยความจำชั่วคราวแบบแคช ทำให้สามารถค้นหาข้อมูลได้รวดเร็วมากขึ้นซึ่งเราจะเรียกส่วนนี้ว่า Database Buffer cache
    • Tablespace อย่างน้อยที่สุดจะต้องมี System Tablespace ซึ่งจะทำหน้าที่เก็บ Data Dictionary ของ Database ทั้งหมด พูดให้ง่ายขึ้นก็คือเป็นข้อมูลอย่างเช่น มี tables ,user หรือ objects อื่น ๆ อะไรบ้าง ใครเป็นเจ้าของ เป็นต้น
    • เวลาที่เราทำงานกับฐานข้อมูลของออราเคิล เพื่อประสิทธิภาพในการทำงานที่ดี ขอแนะนำให้สร้าง Tablespace ใหม่ขึ้นมาเพื่อใช้เก็บข้อมูลของแต่ละงานแยกกัน โดยปกติถ้าเราใช้ DBCA เป็นตัวสร้าง Database ตัว DBCA จะสร้าง tablespace   อื่นนอกเหนือจาก Systems Tablespace ให้เราด้วยแล้ว
 
Control Files
คือไบนารี่ไฟล์ซึ่งเก็บข้อมูลเกี่ยวกับระบบปฏิบัติการที่ใช้งานอยู่ชื่อฐานข้อมูล เวลาที่สร้างชื่อ Data Files และ Online Redo Log Files รวมถึง Archived Redo Log Files ด้วย ทุกครั้งที่มีการ mount ฐานข้อมูลก็จะเกิด Control File ขึ้นเพื่อระบุ Data Files และ Online Redo Log Files ที่ต้องใช้ในการทำงานของระบบฐานข้อมูล ถ้าหากมีการเปลี่ยนแปลง เช่น มีการสร้าง Data File หรือ Redo Log File ใหม่ขึ้นมาก็จะทำการบันทึกลงใน Control File ซึ่งโดยปกติแล้ว ควรจะแยก เก็บเป็น mirror ไว้บนฮาร์ดดิสก์คนละตัวกัน เพื่อป้องกันการ Fail ของฮาร์ดดิสก์ และเก็บเป็นไฟล์นามสกุล . con นอกจากนี้เรายังควรที่จะทำการสำเนาไฟล์นี้เอาไว้เผื่อกรณีฉุกเฉินด้วย
 
Online Redo Log Files
ออราเคิลจะมี Redo Log File เพื่อใช้ในการจัดเก็บการเปลี่ยนแปลงทุกอย่างที่เกิดขึ้นกับ Database เพื่อนำไว้ใช้ ในกรณีที่เกิดเหตุการณ์ไม่ปกติกับ Database อย่างเช่น มีคนซนดึง plug ไฟฟ้าของเครื่องออก โดยที่ยังไม่ได้ทำการ Shutdown Database ก่อน
 
Archived Redo Log Files
ส่วนนี้จัดเก็บข้อมูลจาก Online Redo Log File ที่มีการจัดเก็บจนเต็มแล้ว โดยแยกเก็บในพื้นที่ภายนอก ที่สามารถ ขยายได้ (เนื่องจาก Online Redo Log File นั้นเมื่อบันทึกจนเต็มก็จะย้ายไปทำงานที่ตัวถัดไป จนกระทั่งทุกตัวบันทึก เต็มหมดแล้ว ก็จะกลับมาเริ่มที่ตัวแรกใหม่ ซึ่งจะเริ่มเขียนทับข้อมูลเดิม ดังนั้นออราเคิลจึงได้ทำการย้ายไปเก็บใน Archive Redo Log File แทน ) ทำให้เราสามารถจัดเก็บข้อมูลย้อนหลังได้มากขึ้น เพื่อว่าเวลาที่เกิดปัญหาขึ้น จะได้สามารถนำ ข้อมูลกลับคืนมาได้ครบถ้วน  Archived Redo log files จะเกิดขึ้นในกรณีที่ Database เรากำหนด mode เป็น  ARCHIVELOG Mode ซึ่งจะทำให้เราสามารถกู้ข้อมูลกลับคืนมาได้ทั้งหมด ในกรณีที่มีปัญหาเกิดขึ้น นอกจากนั้นจะมี File ประกอบการทำงานอีก 2 file คือ

 

  • Parameter File ทำหน้าที่ เก็บ Parameter ต่าง ๆ ของ Database ที่เราใช้งานซึ่งรวมไปถึงการกำหนดขนาด
    ของ SGA และพฤติกรรมการทำงานต่าง ๆ ฉะนั้นเวลา DBA เค้าคิดจะ Tuning เจ้าตัว Database เค้าก็จะมาปรับแต่งที่ file นี้
  • Password File ทำหน้าที่เก็บ user และ password ของคนที่มีสิทธิ startup และ shutdown Database ได้

Oracle DB Backup & Recovery Concept

posted on 29 Jun 2008 15:58 by itknow  in Oracle

การดูแล Oracle Database หรือจะเป็น Database หน้าไหนก็ตาม
สิ่งที่ขาดไม่ได้ในการดูแล database นั่นคือเรื่องของการ backup database
ผมเคยใช้เวลาค้นหาเรื่องเกี่ยวกับการ backup ซักระยะแล้ว ก็เริ่มหงุดหงิดกับบทความภาษาไทย ที่บอกไม่ละเอียดเลย มีบอกนั่นนิดมีบอกนี่หน่อย พอกันทีครับไป otn ดีกว่า มือใหม่อย่างผมก็นั่งงมอยู่ซักพักก็เริ่มจับหลักได้
ผมจึงตั้งใจจะเขียนเรื่องการ backup database โดยแบ่งออกมาได้เป็น 3 ตอน

1. Oracle Database Backup & Recovery Concept
2. Oracle Database Backup (RMAN)
3. Oracle Database Recovery

สำหรับตอนนี้เป็นตอนแรกผมอยากให้เข้าใจ concept ของการทำ backup & recovery database กันก่อนให้เข้าใจก่อนว่า failure สามารถเกิดได้ในเหตุการณ์ไหนบ้าง
Backup และ Recovery จะเกี่ยวข้องกับยุทธวิธีและขั้นตอนการป้องกันข้อมูลไม่ให้สูญหายและคืนสภาพให้กับ database เมื่อข้อมูลเสียหาย
Backup คือการ copy ข้อมูลจาก database เพื่อนำมาใช้สร้าง database เมื่อ database มีข้อมูลเสียหาย แบ่งได้เป็น 2 ประเภท

  • Physical backup คือการ backup ข้อมูลจาก physical file เช่น data file, control file, archive redo log file วิธีการ backup มี 2 วิธี
    • Manual Backup คือการเราเข้าไป copy physical database file แต่ต้องทำขณะที่ shutdown database อยู่
    • Recovery Manager (RMAN) เป็น utility ที่ Oracle ทำขึ้นมาเพื่อทำหน้าที่ backup restore and recovery โดยเฉพาะสามารถทำได้ขณะที่ database กำลัง online อยู่
  • Logical backup คือการ backup พวกข้อมูลที่เป็น Logical เช่น Tables, stored procedures ซึ่งอาจใช้ Oracle export utility

Physical backup เป็นรากฐานของการ backup ส่วน Logical backup ทำเพื่อช่วย support physical backup เพราะมันไม่สามารถกู้ Oracle database ส่วนที่เสียหายกลับคืนมาได้ทั้งหมด เช่นถ้า control file เสียหาย Logical backup ไม่สามารถกู้คืนกลับมาได้เนื่องจาก Logical มันเป็นแค่ข้อมูลที่ backup มาจาก data file

เป้าหมายของการทำ backup

  • Mean Time Between Failure (MTBF) หมายถึงเพิ่มเวลาเมื่อเกิด database failure แต่ User ยังสามารถทำงานต่อไปได้โดยไม่รู้สึกว่า database failure
  • Mean Time To Recover (MTTR) คือการใช้เวลาให้น้อยที่สุดในการ recovery database
  • ป้องกันไม่ให้เกิด Database Failure
  • เมื่อ Recovery กลับมาแล้วข้อมูลควรเสียหายน้อยที่สุด และต้องใช้งานได้เหมือนเดิม

Database Failure ที่อาจเกิดขึ้นได้

  • Statement Failure สาเหตุเกิดจาก
    • syntax ไม่ถูกต้อง
    • application logic failure
    • User ไม่มีสิทธิ์ส่งคำสั่งนั้น
    • User ใช้พื้นที่ tablespace เกิน quota ที่กำหนด ถ้าเกิดปัญหาในข้อนี้สามารถแก้ได้โดยให้ dba เพิ่ม quota ให้ user แต่เราสามารถดักให้ error ที่เกิดขึ้นนี้หน่วงเวลาออกไปได้โดยเข้าไปกำหนดใน parameter RESUMABLE_TIME=xxx (วินาที) ซึ่งในระหว่างนี้ให้ dba เข้าไปเพิ่ม quota ให้กับ user ที่เกิดปัญหาหลังจากนั้น statement ที่ error นั้นสามารถทำงานต่อไปได้failure ประเภทนี้ที่ไม่ต้องมี backup และไม่ต้องทำ recovery เพราะไม่มีผลกระทบอะไรกับ database Oracle สามารถจัดการกับปัญหาที่เกิดขึ้นทั้งหมดได้
  • User Process Failure สาเหตุเกิดจาก
    • User ที่ disconnect database แบบผิดปกติ เช่น user ทำ transaction ต่างๆอยู่แล้วยังไม่ commit เกิดข้อผิดพลาดขึ้นใน application ทำให้ application ต้องหยุดการทำงานไปทำให้ user ออกจาก database แบบผิดปกติซึ่งถ้าเกิดความผิดปกติประเภทนี้ เราจะรู้ได้ทันทีจาก background process Process Moniter (PMON) โดยสิ่งที่ Oracle จะแก้ไขปัญหานี้คือ Oracle จะ rollback transaction ที่ทำค้างของ User คนนั้น และปลดล็อคคืนให้กับระบบ failure ประเภทนี้ไม่ต้องมี backup และไม่ต้องทำ recovery
  • Network Failure สาเหตุเกิดจาก
    • Listener Fails เมื่อเกิดเหตุการณ์นี้ client จะไม่สามารถเข้ามาใช้งาน Oracle Database ได้เลย เป็น failure ที่เล็กน้อยแต่เป็นปัญหาใหญ่ การป้องกันไม่ให้เกิด failure ประเภทนี้คือ สร้างเส้นทางสำรองให้กับ listener ทำโดยสร้าง listener process อีก 1 ตัว แล้วเลือก option connection fail over เป็น advance option จากนั้นเราต้องทำให้ client รู้จัก listener รู้จักกับเส้นทางสำรองผ่าน listener โดยการ config tnsname.ora
    • ระบบ network failsปัญหาอย่างนี้ไม่เกี่ยวข้องกับข้อมูลของ database เลยไม่ต้องมี backup ไว้
  • User Error สาเหตุเกิดจาก
    • ความผิดพลาดจาก user เอง เช่นการลบ table ผิดซึ่งพบได้บ่อยมาก ใน Oracle Database 10g จึงได้เพิ่ม feature ใหม่เข้ามาคือ flashback ซึ่งสามารถเอา table ที่ถูกลบไปแล้วกลับมาได้ด้วย user คนนั้นเอง แต่ก็ต้องดูด้วยว่าข้อมูลที่จะ flashback กลับมานั้นยังอยู่ใน undo table หรือไม่ตัวอย่างการใช้คำสั่ง flashback
      SQL> DROP Table hr.job_history;
      Table dropped.
      SQL> FLASHBACK TABLE hr.job_history TO BEFORE DROP;
      Flashback complete.
      ตารางที่ลบไปแล้วจะถูกเปลี่ยนชื่อโดยขึ้นต้นว่า bin ถ้าเราต้องลบ table ที่อยู่ใน recycle bin คำสั่ง PURGE
      ตัวอย่างการใช้คำสั่ง purge
      SQL> purge recyclebin ; อันนี้ลบทั้งหมด
      SQL> purge table … ;
      SQL> purge index … ;
      Failure ประเภทนี้อาจต้องใช้ backup เพื่อทำ recovery เพราะว่าถ้าใช้ คำสั่ง PURGE จะทำให้ table ที่อยู่ใน recycle bin จะถูกลบไปถาวร
  • Media Failure อาจเกิดขึ้นกับ disk ที่ไม่ว่ากรณีใดๆ เมื่อเกิดขึ้นแล้วต้องมี backup และต้องทำ recovery ให้กับ database
  • Instance Failure สาเหตุอาจเกิดจาก
    • ไฟดับ
    • Hardware failure
    • Background processes Failure
    • Emergency shutdown เช่นการส่งคำสั่ง shutdown ABORT และ start FORCEFailure ประเภทนี้ต้องมี backup เพื่อเอาไว้ recovery Failure ประเภทนี้ Oracle สามารถตรวจเจอได้เอง
      การที่ Instance Failure มีโอกาสสูงที่จะทำให้ข้อมูลไม่ synchonize กันเพราะเมื่อมีการส่งคำสั่ง update เข้ามามีผลทำให้ข้อมูลมีการเปลี่ยนแปลง ข้อมูลที่เปลี่ยนแปลงจะถูกเก็บลงใน redo log buffer แล้วเมื่อ user ส่ง commit เข้ามาข้อมูลที่เปลี่ยนแปลงจึงถูกเขียนลงใน redo log file แต่ยังไม่เขียนข้อมูลที่เปลี่ยนแปลงลงใน data file มันจะรอจนถึงกระบรวนการ checkpoint ให้ background process Database Writer (DBWR) เขียนข้อมูลลง data file ให้เป็นข้อมูลเดียวกันระหว่าง redo log file กับ data file ข้อมูลทั้งสอง file จึง synchonize กัน แต่ถ้าระหว่างนี้ เกิดเหตุการณ์ที่ทำให้เกิด Instace Failure ทำให้ข้อมูลที่ถูกเปลี่ยนแปลงล่าสุดจริงๆอยู่ที่ redo log file แต่ Oracle สามารถตรวจจับความผิดปกติตรงนี้ได้และแก้ไขให้เราแต่ต้องอาศัยให้ dba startup database ให้
      ขั้นตอนการทำงานของ Instance Recovery
      ข้อมูลตัวสำคัญที่บอกว่าข้อมูล synchonize กันหรือไม่นั่นค่าของ SCN (System Change Number) ค่า SCN จะบอกว่า ณ ตอนนี้ข้อมูลมีการเปลี่ยนแปลงไปครั้งที่เท่าไหร่แล้ว SCN จะเกิดขึ้นทุกครั้งที่มีการ commit Database จะสร้างเลข SCN ขึ้นมา 1 ตัวและบวกเพิ่มขึ้นไปเรื่อยๆ แล้วเก็บลงใน data file, control file, redo log group
      ตัวอย่าง Instance Failure
      ใน redo log group กับ control file ค่า SCN ล่าสุดคือ 143 แต่ data file ค่า SCN ล่าสุดคือ 140 จะเห็นว่าค่าตอนนี้ไม่ synchonize กัน ซึ่ง background process ที่จะมา stamp ให้ค่า SCN ตรงกันคือ background process Check Point (CKPT) เมื่อมา stamp แล้วเห็นว่าค่า SCN ไม่ตรงกันก็บอกให้รู้แล้วว่า Instance Failure จึงต้องทำ Instance Recovery จากนั้นจะไปเรียกให้ SMON ให้ทำงาน โดย SMON จะทำอยู่ 2 operation นั่นคือ Row forward กับ transaction ที่ commit แล้วคือเอาข้อมูลที่อยู่ใน redo log file ไป update ใน datafile ให้แล้ว, Row backward กับ transaction นั้นถูก rollback หรือถูก force ให้ rollback คือไปเอาข้อมูลใน undo data มาใส่ใน table เหมือนเดิม
    • การทำ Instance จะต้องมีจุดเริ่มทำซึ่งจะเกี่ยวข้องกับ checkpoint คือเริ่มทำในตำแหน่งที่ยังไม่ถูกทำ check point เป็นต้นมา จะเห็นว่า checkpoint ถี่ก็มีข้อดีคือ recvoery เร็วขึ้น แต่ก็ทำให้ performance ตกลงเช่นกันเมื่อทำ checkpoint การจะดูว่าควร checkpoint ถี่แค่ไหนให้ดูจาก MTTR

Mean Time To Recovery (MTTR) ระยะเวลาในการทำ recovery
เราสามารถเข้าไปกำหนดได้ว่าเมื่อมีการ recovery ให้ใช้เวลาเท่าไหร่ ถ้าเข้าไปดูที่ OEM จะมีบอกรายละเอียดด้วยว่าถ้ามีการ recovery ต้องใช้เวลาประมาณเท่าไหร่ หรือเราเข้าไปกำหนดได้ใน Parameter FAST_START_MTTR_TARGET ถ้าเรากำหนดค่าน้อยจะมีผลทำให้ checkpoint บ่อยขึ้น แต่ถ้าใส่ค่ามากจะมีผลทำให้ checkpoint นานขึ้น ซึ่งค่ามากที่สุดคือ 3600 วินาที (1 ชั่วโมง) ค่า default คือ 0 (disable) ซึ่งตรงนี้ถ้าเป็น disable Oracle จะเข้าไปดู paramter ตัวอื่นที่เกี่ยวข้องด้วยคือ LOG_CHECKPOINT_TIMEOUT (วินาที)

การวางแผนเรื่องการ backup

  • ควรมีตารางการ backup เช่น ทุกๆวัน, ทุกๆวันพุธ, ทุกเดือน ซึ่งตรงนี้จะถี่แค่ไหนขึ้นอยู่กับ data ว่ามีการเปลี่ยนแปลงบ่อยแค่ไหน
  • ควรทำ Multiplex Control Files ถ้าไม่มี control files Instance Database จะ statup ไม่ขึ้น
  • ควรทำ Multiplex Redo log groups
  • Production System ควร run อยู่ใน ArchivedLog mode เพื่อป้องกัน loss data
  • สร้าง redundancy ให้กับระบบของเราด้วยการใช้ RAID-based เพื่อให้ระบบสามารถทำงานต่อไปได้เมื่อ disk failure และแถมยังเป็นการการรันตีว่าข้อมูลจะไม่สูญหายไปเมื่อ disk failure
  • ทำการ backup เป็นประจำเพื่อเมื่อถึงเวลาที่ต้องทำการ recovery จะได้กลับไปจุดที่ทำการ backup ครั้งล่าสุดได้ไม่ไกลจากช่วงเวลาปัจจุบันนัก
  • รักษาอุปกรณ์เก็บข้อมูล และมั่นทดสอบว่าข้อมูลที่เก็บอยู่สามารถใช้งานได้จริง
  • run noarchivelog mode เมื่อคุณแน่ใจว่าระบบมีเวลา downtime
  • หลังจากมีการเปลี่ยนแปลงโครงสร้างของ database ควรมีการ backup control file อยู่เสมอ
  • ควรมีการ backup ลงใน tape และ tape ก็ควร backup อีกเช่นกัน
  • ควรมี 2 copies ของ archived redo logs อันนึงเก็บไว้ใน disk และอีกอันเก็บไว้ในอุปกรณ์เก็บข้อมูลอย่างอื่น เพื่อที่ว่าเมื่อมีปัญหาจะได้ดึง archived redo log ที่อยู่ใน disk มาใช้งานได้อย่างรวดเร็วหรือถ้ามีปัญหาอีกก็ดึงจากอุปกรณ์เก็บข้อมูลภายนอก
  • ไฟล์ที่เราควร backup ได้แก่ data files, log files, control files, spfile หรือ init.ora, sqlnet.ora, tnsnames.ora, listener.ora และ password file
  • เก็บมี copy backup อันเก่าไว้ด้วย เผื่อที่ว่า backup ปัจจุบันใช้งานไม่ได้ขึ้นมา(ซึ่งมีโอกาสเป็นไปได้)
  • script backup ควรมีเก็บ log file ได้ด้วยเผื่อมี error เกิดขึ้นระหว่างการ backup จะได้รู้
  • แต่ละ application ควรมีการใช้งานแยก tablespace กันเพื่อที่ว่าถ้า tablespace ใดมีปัญหาเกิดขึ้น application อื่นๆยังคงใช้งานได้ต่อ
  • ใช้ snapshot technology เพื่อเก็บ system backup เพราะว่ามัน backup ได้อย่างรวดเร็วกับ database ขนาดใหญ่
  • ใช้ data pump export utility เพื่อช่วยในการสนับสนุนการ backup

Control Files
เป็น file ควบคุมเก็บสถานะการทำงานของ database โดยสิ่งที่ Control File เก็บเช่น mode การทำงานของ database, เก็บ physical structure เช่นว่า data file กี่ตัวอยู่ path อะไรที่ไหนบ้าง
Control File จะถูกอ่านเมื่อ startup database MOUNT mode แต่ยังไม่ตรวจสอบความถูกต้องของ control file ซึ่งถ้าไม่มี control file จะ startup database ได้แค่ NOMOUNT mode ดังนั้น Oracle จึงแนะนำว่าควรทำ Multiplex Control files ทั้งหมด 3 file และแต่ละตัวควรอยู่คนละ disk กัน ซึ่งตรงนี้ถ้าใช้ DBCA เป็นตัว create database จะสร้าง control file ให้ทั้งหมด 3 file
การทำ Multiplex Control Files ต้องทำ 2 ขั้นตอนคือ

  • ทำในระดับ Database เข้าไปแก้ไข parameter CONTROL_FILE (static parameter) ต้อง shutdown ก่อนจึงจะเห็นผล
    ex. CONTROL_FILES=’’,’’
  • ทำในระดับ OS เริ่มแรกให้ shutdown database ก่อนจากนั้นเข้าไป copy control file ที่ใช้งานอยู่ปัจจุบัน แล้วไปวางใน path ที่ระบุไว้ใน parameter แล้วเปลี่ยนชื่อให้ตรงกับค่าใน paramter ด้วย จากนั้น startup database แล้วเข้าตรวจสอบความถูกต้อง โดยดูได้จาก view V$CONTROLFILEข้อดีของการทำ Multiplex Control Files คือถ้ามี Control File ตัวใดตัวหนึ่งเสียหายไปอีกตัวสามารถทำงานแทนกันได้โดย Database จะไปอ่าน Control File ที่ยังใช้งานได้อยู่จาก paramter CONTROL_FILES

Redo Log Files
เป็น file ที่เก็บข้อมูลที่เปลี่ยนแปลง โดยจะมี background process log writer (LGWR) ทำหน้าที่เขียน redo log file ให้ก่อนที่จะเขียนลงใน redo log file จะมี memory ตัวนึงที่เก็บข้อมูลที่เปลี่ยนแปลงอยู่เรียกว่า redo log buffer และจะเขียนลงใน redo log เมื่อมีคำสั่ง commit หรือเหตุการณ์อื่นๆ
โครงสร้างของ redo log จะเป็น group ในแต่ละ group จะมี redo log file เป็น member ถ้าใช้ DBCA เป็นตัว create database จะสร้าง redo log group ให้ 3 group และ redo log file ให้ group ละ 1 file ซึ่งเป็นค่า default ของ DBCA แต่อย่างนี้ยังไม่เป็น Multiplex redo log file จะเป็น Multiplex redo log file ก็ต่อเมื่อในแต่ละ redo log group มีมากกว่า 1 redo log file และถ้าให้ดีแต่ละ member ควรจะแยกอยู่กันคนละ disk
ข้อดีของการทำ Multiplex Redo Log File คือ ถ้า member ใดใน group นั้นเสียหายไป Database ก็ยังทำงานได้อยู่เพราะยังมี member อีกตัวทำงานแทนกันได้ และถ้าให้ดี member ที่อยู่ใน group
Note: ถ้าใช้ DBCA สร้าง database จะมี mulitplex control file แต่ไม่มี multiplex redo log file

Archived Log Files
เป็น file ที่เก็บ copy ของ redo log file ก่อนที่ LGWR จะเขียนทับลงใน redo log file path ที่เก็บ archive log file โดย default จะเก็บอยู่ที่ตำแหน่งเดียวกับ flash recovery area ดูได้จาก parameter DB_RECOVERY_FILE_DEST ตำแหน่งที่ 10
เราสามารถกำหนด path ของ archive log file เพิ่มเติมได้ นอกจากจะเก็บลงใน default path ยังสามารถกำหนดได้เองอีก 9 path จาก parameter LOG_ARCHIVE_DEST_<1-10>=”"เท่ากับเป็นการ copy archive log file เพิ่มขึ้นเหมือนเป็นการ backup ซึ่งกันและกัน วิธีนี้จะมีประโยชน์ในกรณีที่ archive log file default ใช้งานไม่ได้ database จะย้ายไปใช้อีก path ให้
โดย default archive log file จะมีก็ต่อเมื่อเรา enable archivelog mode แต่ค่า default จะเป็น disable
การตรวจว่า database ขณะนี้ run อยู่ใน mode อะไร
SQL> select archiver from v$instance;
–ถ้าค่าคือ STARTED=archivedlog mode หรือ STOPPED=noarchivedlog mode
หรือ
SQL> select name, log_mode FROM v$database;
หรือ
SQL>ARCHIVE LOG LIST; –ถ้าอยู่ใน archivedlog mode จะแสดงรายละเอียดออกมา
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 18
Next log sequence to archive 20
Current log sequence 20
การเปลี่ยน mode database ให้เป็น archivelog mode หรือ noarchivelog mode
SQL> shutdown
SQL> startup mount
SQL> ALTER DATABASE [ARCHIVELOG | NOARCHIVELOG]
SQL> ALTER DATABASE OPEN;