เมื่อต้นเดือนที่ผ่านมาได้รับโจทย์ให้ไปดูแล Oracle Database ที่ไซต์ของลูกค้า และสิ่งที่ขาดไม่ได้ในการดูแล database นั่นคือเรื่องของการ backup database เลยใช้เวลาหาเรื่องเกี่ยวกับการ backup ซักระยะแล้วก็เริ่มหงุดหงิดกับบทความภาษาไทยที่บอกไม่ละเอียดเลย มีบอกนั่นนิดมีบอกนี่หน่อย พอกันทีครับไป otn ดีกว่า มือใหม่อย่างผมก็นั่งงมอยู่ซักพักก็เริ่มจับหลักได้
ผมจึงตั้งใจจะเขียนเรื่องการ backup database โดยแบ่งออกมาได้เป็น 3 ตอน
1. Oracle Database Backup & Recovery Concept
2. Oracle Database Backup (RMAN)
3. Oracle Database Recovery
แล้วจะค่อยๆทยอยเขียนให้อ่านเรื่อยๆถ้ายังไม่เบื่อกันก่อน ok เข้าเรื่องเลย
สำหรับตอนนี้เป็นตอนแรกผมอยากให้เข้าใจ 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
เป้าหมายของการทำ 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
- Media Failure อาจเกิดขึ้นกับ disk ที่ไม่ว่ากรณีใดๆ เมื่อเกิดขึ้นแล้วต้องมี backup และต้องทำ recovery ให้กับ database
- Instance Failure สาเหตุอาจเกิดจาก
- ไฟดับ
- Hardware failure
- Background processes Failure
- Emergency shutdown เช่นการส่งคำสั่ง shutdown ABORT และ start FORCE Failure ประเภทนี้ต้องมี backup เพื่อเอาไว้ recovery Failure ประเภทนี้ Oracle สามารถตรวจเจอได้เอง
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 จะถูกลบไปถาวร
การที่ 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 ถี่แค่ไหนให้ดูจาก MTTRMean 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>="
โดย 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;
ถ้าสงสัยตรงไหนหรืออยากให้เพิ่มตรงไหนบอกได้ครับ
สำหรับตอนนี้ขอจบไว้เพียงแค่นี้ครับ ตอนหน้าเทคนิคเน้นๆทำ backup ให้เห็นกันจะๆครับ
3. เลือก Customers Entity Object มาไว้ข้างขวา
6. แสดง SQL ที่ถูกสร้างขึ้นเพื่อไปดึงข้อมูลมาเก็บใน Entity Object แต่ละตัว เพื่อให้ View Object นำมาแสดงผลครับ ตรงนี้เราสามารถที่จะ เพิ่ม Where Clause หรือคำส่ง Order By ได้
7. หลังจากนั้นกด Finish ก็จะได้ Component CustomersView เกิดขึ้น โดยถ้ามองที่ Structure ก็จะประกอบไปด้วย 2 file คือ
1. CustomersView.xml เป็น configuration file ที่บอกว่า View ตัวนี้เชื่อมต่อกับ Entity Object ตัวไหน ใช้ SQL อะไรในการดึงข้อมูลครับ
?
3. ใน CustomersServicesImpl.java จะมี Main Class อยู่แล้ว ผมจะ Comment ตรงส่วน Code ที่ Jdeveloper ให้มา จากนั้นเพิ่มโค้ดตามรูป
โดย Configuration.createRootApplicationModule จะทำหน้าสร้าง Instance ของ Application Module ที่ต้องการใช้ จากนั้นเราทำการ Casting เป็น Application Module ที่เราต้องการ ก็จะสามารถเรียก Method นั้นได้เลย
คราวหน้าเรามาสร้าง View Object กันต่อครับ
... ง่ายขนาดนั้นเลยเหรอ ไว้มาเขียนในตอนต่อไป)
