Lecture 2

สรุปคําบรรยาย
วิชา
Advanced Database Systems
บรรยายโดย
รศ.ดร. ศุภมิตร จิตตะยโศธร
ภาคเรียนที่ 1/2549
คณะเทคโนโลยีสารสนเทศ
สถาบันเทคโนโลยีพระจอมเกลาเจาคุณทหารลาดกระบัง
Advanced Database Systems 1/49-IS20.2
สารบัญ
Transaction Processing Concept......................................................................5
ACID Properties ของ Transaction...........................................................................................................................7
Transaction State.....................................................................................................................................................9
Recovery ..........................................................................................................9
Failure Classification..............................................................................................................................................9
Transaction Recovery Problem Statement............................................................................................................11
หลักการ Transaction Recovery ..............................................................................................................................11
Idempotent............................................................................................................................................................12
อะไรจะเกิดขึ้นเมื่อ BIJ เต็ม .......................................................................................................................................13
อะไรจะเกิดขึ้นเมื่อ AIJ เต็ม .......................................................................................................................................13
ประเภทของ Log-based recovery............................................................................................................................13
แยกประเภทตาม Database Modification Technique................................................................................................15
Check point...........................................................................................................................................................16
Buffer Management .......................................................................................18
Log-record Buffering............................................................................................................................................19
Operating System Role in Buffer Management....................................................................................................19
Shadow Paging .....................................................................................................................................................21
Database Backup Concept .............................................................................22
Database Export/Import........................................................................................................................................23
Concurrent Execution ....................................................................................24
Conflict Serializability..........................................................................................................................................27
View Serializability ..............................................................................................................................................27
Recoverability.......................................................................................................................................................29
Cascadeless Schedule ...........................................................................................................................................30
Levels of consistency............................................................................................................................................30
2
ปญหา 4 ขอใน Concurrency control........................................................................................................................31
Concurrency Control......................................................................................33
Lock-based Protocol .............................................................................................................................................33
2-Phase Locking Protocol .....................................................................................................................................34
Multiple Granularity .............................................................................................................................................35
Weak Level of Consistency..................................................................................................................................37
Timestamp-Base Protocol.....................................................................................................................................37
Timestamp-Ordering Protocol ..............................................................................................................................38
Thomas’ Write Rule .............................................................................................................................................39
Multiversion Timestamp Ordering .......................................................................................................................39
Multiversion 2-phase locking ...............................................................................................................................40
Query Processing ...........................................................................................41
Relational algebra .................................................................................................................................................42
ตัวอยาง Database statistics.....................................................................................................................................45
Selection Operation ..............................................................................................................................................45
A1. Linear search .....................................................................................................................................45
A2. Binary search.....................................................................................................................................45
A3. Primary index, equality on key .........................................................................................................46
A4. Primary index, equality on non-key ..................................................................................................47
A5.1 Secondary index, equality on key .....................................................................................................47
A5.2 Secondary index, equality on non-key ..............................................................................................47
Join Operation.......................................................................................................................................................48
1. Nested-Loop Join...................................................................................................................................48
2. Block Nested-Loop Join........................................................................................................................49
3. Indexed Nested-Loop Join.....................................................................................................................49
4. Hash Join...............................................................................................................................................51
Hash Index............................................................................................................................................................52
3
Temporal Database ........................................................................................53

Valid-Time State Table.........................................................................................................................................53
Duplication Concept .............................................................................................................................................54
นิยามของ Temporal Database ................................................................................................................................55
Temporal Join.......................................................................................................................................................57
Modifying Valid-Time State Table.......................................................................................................................59
Current Delete.......................................................................................................................................................60
Current Update......................................................................................................................................................61
Sequence Insert.....................................................................................................................................................61
Sequence Delete....................................................................................................................................................61
Sequence Update ..................................................................................................................................................63
Temporal SQL (Back in the Pens)........................................................................................................................64
Transaction-Time State Table...............................................................................................................................65
Bitemporal Table ..................................................................................................................................................66
4
Transaction Processing Concept
นิยามของ Transaction จะแบงออกไดเปน 3 ยุค
ยุคแรก
คือ File ที่เก็บรายการเปลี่ยนเแปลง (Transaction File) จากแฟมขอมูลหลัก (Master file) ซึ่งเปนระบบ Sequential File
มีการ sort ไวอยางเรียบรอย
ยุคที่สอง
เริ่มมีการใช Disk ซึ่งจะไมไดเปน Sequential File แลว Transaction จะหมายถึงแตละกิจกรรมที่กระทําบน Data File
ยุคปจจุบัน
A Transaction is a logical unit of work in which integrity constraint to be violated. (LUW)
กลุมของคําสั่งในภาษาฐานขอมูลในระดับ Logical ที่ยอมใหมีการละเมิด integrity constraint เปนการภายในได
ซึ่ง Integrity constraint กฏที่บังคับความถูกตองของฐานขอมูล รวมถึง business rule ตางๆ ดวย โดยที่จะเก็บอยูใน
Database และบังคับใชโดย DBMS
ตัวอยาง
R1: รถทุกคันในบริษัทจะตองมีพนักงานรับผิดชอบ
เหตุการณ มีรถคันใหมเขามาในบริษัท
สิ่งที่ตองทําคือ
Insert รถคันใหม (ซึ่งจะไมมีทาง insert ไดเนื่องจากผิดกติกา)
Assign พนักงานรับผิดชอบรถ
เราตองทําทั้งสองกิจกรรมนี้ใหเปนหนวยเดียวกัน
Begin transaction Synchronization Point (จุดเริ่มตน/จุดสุดทายของ Transaction)
Insert รถคันใหม R1 ถูกละเมิด
Assign พนักงานรับผิดชอบรถ
End transaction Database สอดคลองตาม R1
R2: การโอนเงินจะตองไมมียอดเงินหายไปจากระบบ
เหตุการณ โอนเงินจาก A ไปยัง B จํานวน x บาท
สิ่งที่ตองทําคือ
Begin Transaction
ถอน A จํานวน x บาท R2 ถูกละเมิด
ฝาก B จํานวน x บาท
End Transaction Database สอดคลองตาม R2
5
1 Transaction มี 1 คําสั่งหรือมากกวาก็ได
เหตุการณ Update หมูเลือดของคนในประเทศจาก A เปน Z
Begin Transaction
Update A Æ Z ในระหวางปฏิบัติงานจะมีทั้ง A และ Z อยูใน Database
End Transaction Database สอดคลองกัน
(Q) กรณีที่มีการ Update ขอมูลที่เปน Volume transaction กระทบ 1 ลาน rows
กรณีที่วิ่งไปได 9 แสน Rows แลวเจออุปสรรค Transaction ไปตอไมได
ทําใหมีการ Rollback ซึ่งอาจจะทําใหเสียงานได อยากทราบวา solution คืออะไร
(A) ควรแบงเปน Transaction ยอยๆ
Synchronization point ในภาษา SQL ซึ่งเปนจุดเริ่มตนและลงทาย Transaction จะมีอยู 3 ตัวคือ
1. Commit work เปนการยืนยันการเปลี่ยนแปลงตั้งแต Sync point ลาสุดจนถึงจุด commit
เปนเหมือนคําสัญญาวาถาหลังจากนั้นขอมูลจะไมหายแน
2. Rollback work เปนการยกเลิกการเปลี่ยนแปลงตั้งแต Sync point ลาสุดจนถึงจุด Rollback
3. Set autocommit off - ถาเปน autocommit on นี่เสร็จหนึ่งคําสั่งก็จะ commit เลย
แตถาเปน autocommit off เสร็จ แตละคําสั่งจะยังไม commit จะ commit ก็ตอเมื่อ
มีคําสั่ง commit อยางชัดเจน
On error rollback
set autocommit off
update acc set amount=amount - x where acc# = ‘A’
update acc set amount=amount + x where acc# = ‘B’
commit
เราตองแยกการ Commit กับการถายโอน data จาก DB Buffer ลงสู DB Space เลย Transaction
จะเลนกับขอมูลใน DB Buffer เทานั้น
(Q) ทุกครั้งที่มีการ commit มีการ save การเปลี่ยนแปลงไปยัง DB Space หรือไม
(A) ไม –จะมีการ save เมื่อไมมีใครใชแลว หรือ buffer เต็ม ตัวอยาง Update หมูเลือดจาก A -> Z 20 ลาน row ระหวางวิ่ง
transaction ก็จะมีการถาย Data ลง DB Space
เนื่องจาก Buffer เต็ม ดังนั้นการ Save ลง DB Space อยูกอนหรือหลัง commit ก็ได
6
ACID Properties ของ Transaction
Transaction มีคุณสมบัติ 4 ประการคือ
1. Atomicity : คําสั่งทั้งหลายใน transaction นั้นถาสําเร็จตองสําเร็จดวยกัน ถา Fail ตอง Fail ดวยกันทั้งหมด
หมายเหตุ Transaction ทั้งหลายจะเปนไปตาม Atomicity นี้ยกเวน long duration transaction
Long duration transaction หมายถึง Transaction ที่มีมนุษยเขามาเกี่ยวของ (human intervention) โดยที่จะมีการนํา
nested transaction เขามาชวย
**** ไมควรทํา transaction processing ใน mode interactive SQL****
Begin TX
Begin savepoint
:
Commit savepoint
Begin savepoint
:
Commit savepoint
End TX
*** Atomicity นี้เปนหนาที่โดยตรงของ DBMS ***
2. Consistency : การปฏิบัติ TX โดยอิสระ จะตองรักษาความถูกตองของฐานขอมูลตาม Integrity rule
(หนาที่สวนใหญจะอยูที่โปรแกรมเมอร) โปรแกรมเมอร จะตองใส begin – end ใหถูกตอง ตัวอยางโอนเงิน
Begin TX
ถอน A
Commit TX
ถือวาไม Consistency
Begin TX
ฝาก B
Commit TX
*** Consistency นี้เปนหนาที่ของโปรแกรมเมอร 60 % และ DBMS 40 % ***
7
3. Isolation : TX ที่วิ่งรวมกันในชวงเวลาเดียวกันจะตองไมรบกวนกัน
ถามี Ti และ Tj วิ่งรวมกัน
|------------- Ti-------------| Concurrent schedule
|------------- Tj -------------|
สิ่งที่เกิดขึ้นจะเปนไปได 2 กรณีคือ
1) |------------- Ti -------------|------------- Tj -------------| Serial schedule
2) |------------- Tj -------------|------------- Ti -------------|
Ti และ Tj วิ่ง concurrent แตใหผลลัพธเหมือนกันวิง่ Serial เราเรียกวา Concurrent Serializable schedule
สรุปวากิจกรรมที่ Ti ทําแต Tj ไมเห็น แตถาอยากใหเห็นโปรแกรมเมอรก็สามารถทําได
(Q) T1 = sum account
T2 = เปดบัญชีใหม
|----------------------- T1 -----------------------|
|------------- T2-------------|
ถามวาตามหลัก Isolation แลวผลจากการ sum account จะมีรายการของ บัญชีใหมหรือไม
(A) ตามหลัก isolation แลว T1 ไมควรเห็นรายการของ T2 ผลลัพธควรจะมีลักษณะ T1 นํา T2 ตาม
(Q) จากคําถามขางตน ถาใช Row-level locking ซึ่งเปนการ lock ที่ละ row ที่เราตองการทํางาน
เมื่อใชเสร็จก็ปลด Lock ถามวา บัญชีใหมที่ insert โดย T2 จะเขาไปเปนผลลัพธของ T1 หรือไม
(A) ตอบวาเห็น ซึ่งอธิบายไดวาจาก row ทั้งหมด 10 ลาน row จะถูก lock เพียง 1 row เทานั้น
ดังนั้นในขณะเดียวกันก็สามารถที่จะโอนเงินหรือทํารายการอื่นๆ ได
หมายเหตุ แตในยุคนี้ถามีการ Sum แบบนี้ DBMS จะทําการ lock table ซึ่งการ insert ก็จะทําไมได
นอกจากนั้น DBMS ที่ฉลาดบางตัวเชนถามีการ sum เฉพาะสาขาบางเขน DBMS จะ lock เฉพาะ row
ของสาขาบางเขน ซึ่งสาขาอื่นจะทํารายการได การทํางานคือ DBMS จะเขาไป lock index entry
แตสําหรับ Oracle จะใช timestamp เขามาชวยทําใหคนที่ sum ก็ sum ไป คนที่ insert ก็ insert ไดโดยไมมีการ
wait
*** Isolation นี้จัดการโดย DBMS ***
4. Durability : เมื่อ TX ปฏิบัติเสร็จแลวการเปลี่ยนแปลงนั้นจะตองอยูถาวร นั่นคือหลังจากที่มีการ commit แลว
ไมวาจะเกิดอะไรขึ้น DBMS เปนผูรับผิดชอบ
8
Transaction State
สถาะของ TX มีอยู 5 สถานะคือ
1. Active : คําสั่งใน TX กําลังถูกปฏิบัติงานอยู
2. Partially committed : คําสั่งสุดทายใน TX ถูกปฏิบัติแลว
3. Failed : TX ไมสามารถถูกปฏิบัติตอไปได
4. Aborted : TX ถูก rollback แลว
5. Committed : TX ยืนยันการเปลี่ยนแปลงเรียบรอยแลว ถามีการ lock จะมีการปลด lock ที่จุด commit
ทั้ง Partially committed และ Partially

Committed
Active สามารถที่จะ Failed ได Committed
มีการเปลี่ยนจาก Partially committed ไป

Active เปน committed เร็วเทาไหรก็จะยิ่งดี
Failed Aborted
Recovery
เราจะ ทิ้งบทที่ 15 ไวแคนี้กอนไปดูเรื่อง Recovery ในบทที่ 17 กันกอน
Failure Classification
การ Fail จะมีดวยกัน 3 รูปแบบคือ
1. Transaction Failure: เปนการ Failure เฉพาะ TX นั้น ทําใหไมสามารถปฏิบัติตอไปอีกไดซึ่งจะ Rollback ในที่สุด
- Logical Error: เกิดจาก code program ไมถูก, input ผิด format
- System Error: เกิดจาก Database System software อยูในสถาะอันไมพึงประสงค
เชน Deadlock, log file เต็ม
2. System Crash : คือพังทั้งระบบทําใหระบบไมสามารถทํางานตอไปได ซึ่งอาจจะเกิดจาก Hardware, Software
malfunction บางตัวมีปญหา โดยที่ Disk ไมได crash เชน power fail, main board เสีย, network card พัง,
Memory พัง หรือในบาง DBMS เมื่อ buffer มีการขยายขนาดจนเต็มทําใหแฮงคไป ซึ่งเปน Bug ของ software
Failure ในแบบที่ 1 และ 2 นี้มนุษยไมจําเปนตองเขามาเกี่ยวของในสวนของ Recovery
3. Disk Crash: Disk มีปญหา ซึ่งการ recovery จะตองมีมนุษยเขามาเกี่ยวของดวย
9
Storage Structure
1. Volatile storage : ไฟดับแลวหาย
2. Nonvolatile storage : ไฟดับไมหาย DB Space จะถูกเก็บไวใน nonvolatile storage
3. Stable storage : เปน Storage ที่ไมมีวันหาย log file จะถูกเก็บไวใน stable storage ซึ่งถา log file
เสียหายจะ Recover ไมได
Data Access
Physical block: block ที่อยูใน disk ซึ่งหมายถึง OS block
Logical block: database block
Select * from S where S# = S1
จะได Output 1 row แต DBMS หยิบขึ้นมา 1 database block ซึ่งอาจจะประกอบไปดวยหลาย OS block ก็ได
Input และ Output หมายถึงการถายขอมูลระหวาง DB Buffer กับ DB space
ซึ่ง Input และ output นั้นจะเปนการดูแลรวมกันระหวาง OS และ DBMS และอยูนอกเหนือการควบคุมของ application

program แตอาจจะเกี่ยวของกับ input ได Read และ Write เปนการถายโอนขอมูลระหวางโปรแกรมกับ DB Buffer ซึ่งถาขอมูล
ยังไมอยูใน Buffer
หมายเหตุ ทั้ง Read และ Write เกี่ยวของกับ input แตจะไมเกี่ยวของกับ output เลย
อธิบายไดวา ถาจะ Read ขอมูลที่ยังไมมีอยูใน Buffer DBMS ก็จะ ทําการ input ขอมูลจาก DB Space เขามาไวใน
Buffer กอนแลวจึงจะ Read ไดและถาตองการ Update ขอมูลที่ไมมีใน Buffer DBMS ก็จะ ทําการ input ขอมูลจาก DB Space
เขามาไวใน Buffer กอนแลวจึงจะ Update ได
(Q) แลว output จะทําเมื่อไหร
(A) เมื่อ DBMS และ OS เห็นสมควรคือเมือ่ ไมมีใครใช buffer นั้นแลว (Release recently used) หรือ buffer เต็ม ซึ่ง
จะทํากอนหรือหลัง commit ก็ได
10
Transaction Recovery Problem Statement
ปญหาที่เกี่ยวของกับการทํา Transaction Recovery มีดวยกัน 2 ขอ
1. มี Transaction ที่ commit แลวแตยังไม output ลง DB Space ถาเกิด failure ทําอยางไรจึงจะอยูถาวรบน DB
Space?
2. มี Transaction ที่ยังไม commit แตการเปลี่ยนแปลงบางสวนไดถูก output ลง DB Space เรียบรอยแลว
ถาเกิด Failure ขึ้นมาทําอยางไรจึงจะยกเลิกการเปลี่ยนแปลงเหลานั้นออกจาก DB Space?
ปญหาทั้ง 2 ขอนั้นมีทางแกซึ่งจะใช Logfile เขามาชวยในการ recovery เราเรียกวา Log-based recovery
Logfile หรือ journal นั้นเก็บรายการเปลี่ยนแปลงที่เกิดขึ้นทุกครั้งทั้งที่ commit และ ไม commit มีลักษณะเปน Text
File ทําใหมีการบันทึกไดงายกวา
Logfile ก็จะมี Log record
<Ti start> Æ จุดที่ Transaction Ti เริ่มตนขึ้น
<Ti, Xj, V1, V2> Æ Xj =data item อะไร record ไหน row ไหน, V1 =old value, V2 =new value
<Ti commit> Æ Transaction มีการ commit
(ตรงนี้มีรูป)
(Q) ถาถามวา Commit จริงๆคืออะไร อยูตรงไหน
(A) ถามีการ output log record สําเร็จเมื่อไหรจุดนั้นจะเรียกวา Physical commit
*** จุดสําคัญคือ log record จะถูก output ไป logfile กอน DB Buffer จะ output ลง DB Space ได
เปน Protocol สําคัญเรียกวา Write Ahead Protocol หรือ Write Ahead Logging (WAL) ***
หลักการ Transaction Recovery
กรณีของ System crash หลังจากที่แกปญหาตนตอแลว restart recovery process (start database) โดยมีขั้นตอนการทํางานคือ
- DBMS สวน recover จะทําการ search Logfile ยอนหลังโดยยอนจากทายเพื่อสํารวจวา TX ใด commit TX ใด
fail
- หลังจากนั้นจะนํา TX id ที่ commit ไปไวใน redo list และนํา TX id ของ TX ที่ fail ไปไวใน undo list
- สําหรับแตละ TX ใน undo list ใหเอาคา old value ไป undo DB Space
- สําหรับแตละ TX ใน redo list ใหเอาคา new value ไป redo DB Space
11
(Q) เมื่อไหรจะมีการ output จาก log buffer ไปลง logfile
(A) คําตอบมี 2 แนว
- As soon as possible - พอมี commit record เกิดขึ้นเมื่อไหรจะรีบไลลง logfile ทันที
- Group commit - รวบรวม Log record ใหเต็ม block เสียกอนแลวคอย output ลง log file เนื่องจากอาจจะมี
commit ไดหลายๆ คําสั่งทําให I/O busy นอยลง Log File เต็มชาลง แต user รับความเสี่ยงมากขึ้น ปจจุบันนี้ถือวา group
commit เปนวิธีที่นิยม เหตุผลเบื้องหลังคือ เมือ่ กอน Hardware ไมคอยเสถียรเมื่อเจอ commit ก็ตองรีบลง logfile แตในปจจุบัน
Hardware เสถียรมาก group commit จึงเปนวิธีที่ดีกวา
(Q) ทําไม logfile เก็บ old value กับ new value แทนที่จะเก็บคําสั่ง
(A) Recovery process จะตอง idempotent ซึ่งการเก็บ old value กับ new value จะ implement idempotent ไดงายกวา
Idempotent
Idempotent – ปฏิบัติงานหลายๆครั้งไดผลเหมือนกับปฏิบัติเพียงครั้งเดียว
(Q) เมื่อไหร content ของ logfile จะถูกบันทึกลง DB Space?
(A) ในภาวะการณปกติ content ของ log file ไมเคยจะตอง output ลง DB Space แตในขณะ recovery
Old value ใน undo list จะไป undo DB Space
New value ใน redo list จะไป redo DB Space
ปจจุบันมีการแยกเก็บระหวาง New value และ old value
New value จะถูกเก็บไวใน logfile ที่เรียกวา after image journal (AIJ) บางระบบเรียกวา redo logfile
Old value จะถูกเก็บไวใน logfile ที่เรียกวา before image journal (BIJ)
<Tx start> <Tx start>

<Tx Q, NV> <Tx Q, OV>
<Tx commit> <Tx commit>
AIJ BIJ
เหตุผลที่ตองแยกก็เพื่อที่จะประหยัด Space เพราะวา content ของ BIJ เมื่อ commit เรียบรอยแลวก็สามารถที่จะ recycle ได
** มีคํากลาววาการมี Logfile เหลานี้ชวยให recover ไดก็จริง แตจะทําให performance มีปญหาเนื่องจากจะทําให I/O เพิ่มขึ้น ซึ่ง
เปนคํากลาวที่ผิด **
ซึ่งปญหาที่ Commit ชา มักจะเกิดจากการไมมี logfile เนื่องจากการ output ไปยัง DB Space ทําไดยากกวา output ไปยัง logfile
12
(Q) เวลาทํา redo นั้นจะ redo ตั้งแตจุดไหน
(A) จะทําการ redo ตั้งแตหลังจุด check point ซึ่งเปนจุดที่บังคับให DB Buffer มีการ output ไปยัง DB Space พรอม
กับทิ้ง Marker
อะไรจะเกิดขึ้นเมื่อ BIJ เต็ม
(Q) อะไรเปนสาเหตุให BIJ เต็ม
(A) เกี่ยวของกับ Volume Transaction ซึ่งทําให BIJ เต็มแลวยังไม Commit
เมื่อ BIJ เต็ม Transaction ตัวตนเหตุจะถูก Rollback ซึ่ง BIJ ก็จะถูก clear พรอมที่จะมา recycle ไดตอไป
แตปญหาอยูที่วาเมื่อ Transaction ถูก rollback จะทําใหเสียงานไดแนวทางแกไขคือ
1. ขยายขนาดของ BIJ เพิ่มใหเพียงพอซึ่งควรจะทํา online ไดโดยไมตอง shutdown database
2. by pass BIJ หรือวิ่ง no log option ซึ่งเปนเรื่องที่เสี่ยงพอสมควร
3. แบง Transaction ใหญออกเปน Transaction ยอยเชนการ Update หมูเลือดถาทําเปนจังหวัด ๆ ก็สามารถทําได
อะไรจะเกิดขึ้นเมื่อ AIJ เต็ม
ถา AIJ เต็มจะทําใหกระทบทั้งระบบซึ่งการ rollback จะไมชวยเลย solution ในการแกปญหามี 2 วิธีคือ
1. rollback transaction ตัวตนเหตุแลวให system หยุดทํางาน เพราะถือวาเปนเรื่องเสี่ยงทีจ่ ะทํางานตอ
แตในบางระบบ AIJ จะเปน File ที่ขยายขนาดได ดังนั้นหากพบวา System หยุดทํางานก็ใหดูวา AIJ ทําให Disk เต็ม
หรือไม
2. by pass AIJ โดยมี message แจงให DBA รับทราบวาขณะนี้กําลังรับความเสี่ยงอยู ปจจุบันนี้ DBMS ยี่หอ Top นั้น
AIJ จะไมมีวันเต็ม หลักการคือ จะให AIJ มีหลายชุดเมื่อเต็มชุดหนึ่งก็จะ switch ไปใชอีกชุดหนึ่ง
จากนั้น AIJ ตัวเกาก็จะ archive log เพื่อเก็บไวใชตอน recovery และ AIJ ก็สามารถที่จะ clear ได
ประเภทของ Log-based recovery
(1) BIJ Only (ไมมี AIJ)
การ Recovery ทํางานไดตามปกติตาม logically การ Commit จะเปนการ output DB Buffer ที่เกี่ยวของกับ
Transaction นั้นลง DB Space ครบถวน ถา Fail กอน commit ก็ไมเปนไรเพราะวา Old value ยังอยูสามารถที่จะเอามา
13
undo ได ถา Commit แลว old value ก็ recycle ได ถา Commit แลว Fail ก็ไมตอง redo เลยเพราะไดลง DB Space ไป
หมดแลว
ขอดี
1. ประหยัด space ในสวนของ AIJ
2. Recovery เร็วขึ้นอีกเนื่องจากไมตอง redo
3. ไมเกิดปญหา AIJ เต็ม
ขอเสีย
1. Commit ชาเนื่องจากตองรอใหลง DB Space ครบถวนเสียกอนทําให Transaction อื่นตองรอใชทรัพยากร
Case Study
Begin TX
30,000 รอบ Insert into t1 value (…)
Display date/time
End TX ไมมี AIJ ใชเวลา 19 ชั่วโมง แตถามี AIJ ใชเวลาแค 8 นาที
Display date/time
8 นาทีก็นับวาชามากเปนเพราะเวลาดังกลาวเปน Test system แตถาเปน production มีงานที่วิ่งอยูมากมายทําให DB
Buffer เต็มเร็ว จึงมีการ output ไปยัง DB Space ไดเร็วขึ้น
(2) AIJ Only (ไมมี BIJ)
AIJ
DB Buffer DB Space
การ Commit เปนการบันทึก commit record ลง logfile ถายังไม Commit ก็จะไมมีการ output modified buffer ของ
transaction นั้นลง DB Space
ขอดี
1. commit เร็วมาก (Fast Commit) เนื่องจากระหวางการปฏิบัติ transaction มีการ output ของ logfile
เทานั้น
2. ประหยัด space ในสวนของ BIJ
3. ตัดปญหา BIJ เต็ม
4. Recovery เร็วเนื่องจากไมตอง undo
14
ขอเสีย
1. ไมเหมาะกับ Volume transaction เพราะ Buffer อาจจะเต็มกอนที่จะมีการ commit ได ซึ่ง DBMS มีทาง
แกคือจะ swap DB Buffer ลง swap area ของ OS แตในทางปฏิบัติ DB Buffer เต็มก็ Hang แลว
(3) มีทั้ง AIJ และ BIJ
ขอดี
1. commit เร็วมาก เนื่องจาก AIJ จะดูแลในเรื่อง Fast Commit
2. สามารถทํา Volume transaction ไดเนื่องจากมี BIJ ดูแลในเรื่อง Volume transaction อยู
แยกประเภทตาม Database Modification Technique
เปนการถาย Data จาก DB Buffer ลงสู DB Space
(1) Deferred database modification Æ commit กอนจึงจะถายจาก DB Buffer ลงสู Db Space ไดเทียบกับ AIJ Only
T0 : Read(A) T1 : Read(C)
A := A – 50 C := C + 100
Write(A) Write(C)
Read(B)
B := B + 50
Write(B)
ให A = $1000, B = $2000, C = $700 ถานํา T0 และ T1 มาวิ่ง concurrent จะไดวา
< T0 start>
< T0, A, 950>
< T0, B, 2050>
< T0 commit>
< T1 start>
< T1, C, 600>
< T1 commit>
(2) Immediate database modification Æ DB Buffer จะถูก out ลง DB Space ไดหลังจากที่มีการ output log record
ลง Logfile เรียบรอยแลว ซึ่งอาจจะกอนหรือหลัง Commit ก็ไดเทียบไดวาเปน BIJ Only หรือมีทั้ง AIJ และ BIJ ก็ได
ทั้ง 2 วิธีจะตองเปนไปตาม Write Ahead Protocol
15
Check point
(Q) เมื่อเกิด Failure ขึ้นจะมีการ redo และ undo ถามวา undo ยอนถึงไหน และ redo ยอนถึงไหน
(A) Undo จะยอนถึง Sync point ลาสุด
Redo จะตองมี Check point เขามาเกี่ยวของ โดยเปนจุดที่บอกวา ณ จุดนี้ไดมีการ Output ไปยัง DB Space
เรียบรอยแลวซึง่ สามารถบอกไดวาจะทํา Redo ถึงไหน
กิจกรรมที่ DBMS ทําเมื่อถึงจุด Check point
1. เอา log record ลง logfile
2. เอา DB Buffer ลง DB Space
3. ลง check point record เปน marker ไวใน logfile ในทางปฏิบัติจะมีการลง sequence number ไวดว ยวาเปน check
point หมายเลขเทาไหร
TC TF
T1
Redo
T2
Undo
T3 Redo
T4
Undo
T5
TC = จุด Check point
TF = จุดที่ Fail
T1 = คือ commit กอน check point
T2 = คือ commit หลัง check point
T3 = คือ start กอน check point แลว fail
T4 = คือ start และ commit หลัง check point
T5 = คือ start หลัง check point แลว fail
(Q) จุด check point ควรทําถี่แคไหน
(A) ถา check point ถี่การกูคืนก็จะทําไดเร็ว แตอาจจะทําให system สะดุดเปนชวงๆ ได เพราะระหวางนี้มันทํางานอื่นไมได
ในกรณีที่มี AIJ หลาย file รอยตอระหวาง file คือจุด default check point
16
ถาตัวที่ 1 เต็มและมาใชตัวที่ 2 มีการ Fail เกิดขึ้น ในการ redo ทําถึงจุอ Check point ลาสุดคือจะอางถึง content ของ logfile
ปจจุบันเทานั้น ไมจําเปนตองไปอางถึง Content ของ logfile กอนหนา
จุด Default Check point

จุด Fail
17
Buffer Management
(Q) การทํา buffer management ควรเปนหนาที่ของ OS หรือ DBMS หรือชวยกัน
(A) เนื่องจาก Write Ahead Protocol มี DBMS เทานั้นที่ทราบ ดังนั้นจึงเปนหนาที่ของ DBMS แตอาจจะมี OS ชวยได
Program
Result SQL
DBMS
Database Block
OS File Manager By pass File Manager
OS Block
OS Disk Manager
Bit & Byte
Stored
การสราง DB Space
1. มีการเตรียม File วามีกี่ Block ซึ่งอาจจะไมไดอยูบน drive เดียวกัน
2. เมื่อได File มาแลวก็ทําการ create DB Space ทํา File ตางๆ เหลานั้นใหเปนกอนเดียวกัน
3. ก็จะได DB Space ที่มี File ตางเหลานั้นมีลักษณะเปน black box ซึ่งจะมองไมเห็นในสายตา programmer
แต DBMS จะชวยใหมอง Database เปน Table
เราสามารถ Set ไดวา 1 database block มีกี่ OS block ขึ้นกับประเภทของงาน
Logical block = Database block
Physical block = OS block
(Q) ถา File Manager กับ DBMS คุยกันไมคอยรูเรือ่ ง จะเกิดอะไรขึ้น
(A) จะเห็นวาคอขวดจะไปอยูที่ File Manager
18
Log-record Buffering
มีกติกาดังนี้
1. Commit คือการเอา commit record ลง logfile สําเร็จเมื่อไหรก็ถอื วา commit
2. commit record ตองเปน record สุดทายของ transaction นั้น
3. กอนที่ block ของ data จะ output ลง DB Space ไดนั้น log record จะตอง output ลง stable storage เสียกอน
Database ฺBuffering
(1) Log File
Log buffer
B1
(2)
DB Space
(3)
B2
ตัวอยางกรณีที่ตองการอาน B2 เขามาใน DB Buffer ที่เต็ม

1. ตองการอาน B2 แต Buffer เต็ม ดังนั้นจึงตองไลของเกากอนโดยการบันทึก log record ของ B1 ลง logfile
2. ไล B1 ลง DB Space
3. อาน B2 เขามาใน DB Buffer
กรณีที่ DBMS กับ File manager ไมเขาคูกัน เราสามารถ by pass ให DBMS ลงเลนกับ Disk Manager โดยตรง
เราเรียกวา Raw Device Option ซึ่งจะเร็วขึ้นอีก 20 %
Operating System Role in Buffer Management
1. DBMS จองเนื้อที่ใน memory สําหรับทําเปน DB Space และดูแลเอง
DB Buffer Fixed DBMS จัดการ

Size
Virtual memory ของ OS
การทํา Database Buffer ทําตาม Protocol ที่คุยกันไวทั้งหมดเพียงแต DBMS เปนคนจัดการ
19
User
DBMS
DBMS
DB Space Disk Manager
เปนการยก 1 Device ใหเปน 1 DB Space

2. DBMS ใชเนื้อที่ของ Virtual memory สําหรับทําเปน DB Space ซึ่งอยูภายใตการจัดการของ OS
DB Buffer User
Virtual memory ของ OS

DBMS
File Manager
Disk Manager
DB Space จะเปน File ซึ่ง OS ดูแล
DBMS
DB Buffer
แบบที่ 1
1. เร็วขึ้นในกรณีที่ DBMS และ File Manager ทํางานไมสัมพันธกัน
2. ขนาดของ Buffer fix ทําใหใชประโยชนไมเต็มที่ หาก Buffer เหลือก็ไมสามารถเอาไปใชกับงานอื่นได
และหาก Buffer ไมพอก็ไมสามารถขยายขนาดได เนื่องจาก Fix ขนาดอยู (ขนาดของ Buffer สามารถกําหนด
เปน Parameter ในการทํา performance tuning)
20
แบบที่ 2
1. ใช memory ไดอยางคุมคา ทําใหการใชทรัพยากรดีขึ้น
2. เปนไปไดวาถาไมใช Buffer ไปซักระยะ ก็จะถูก page-out และเมื่อตองการใชงานก็ตองเสียเวลา page-in เขามาอีก
สรุปวาถา DBMS กับ OS ถูกคูกันก็ใชแบบที่ 2 และถาไมถูกคูกันก็ใชแบบที่ 1
Shadow Paging (หัวขอนี้ใน 5th edition ตัดทิ้ง)
การใช Log-based recovery มีขอเสียคือตองใชเวลาในการ redo undo การใช shadow paging จะเหมือนกับโทรทัศน
คือเปดปุบติดปบ ไมตองรอ แตจะใชกับระบบเล็กๆ
Page Table Page on disk

กลาวคือจะมีการจัด Page บน disk แลวก็มี page table ที่ชี้ไปยังที่ตางๆ บน page นั้น ซึ่งเปน page table ที่ DBMS จัด
Shadow Page Table Current Page Table

Page on disk
หลักของ Shadow paging
1. เมื่อมี begin transaction ก็จะสราง current page table ขึ้นมาอีกตัวหนึ่ง แลว page table เกากลายเปน shadow page
2. เมือ่ ตองการแกไขก็จะกอบ page ที่ตองการแกไขมาเปน page ใหมซึ่ง current page table จะชี้ไปยัง page ใหมและจะ
แกไขที่ Page ใหม แต shadow page จะชี้ไปที่ page เกาเสมอ
3. ถาเกิด Failure ขึ้นก็จะทิ้ง current page ไปใช shadow page แทน เราเรียกวา Instance Rollback
4. แตถา commit ก็จะเปนการ save current page อยางถาวรและโยน Shadow Page ทิ้งไป
21
Database Backup Concept
เราทํา Backup เพื่อกู database กรณีเกิด Disk Failure แบงเปน 2 ลักษณะคือ
1. Volume Backup Î เปนการ Backup ทั้ง DB Space ซึ่งถาขอมูลไมมากนัก จะทํา Volume Backup ทุกวันก็ได
2. Incremental Backup Î เปนการ Backup เฉพาะสวนเปลี่ยนแปลง หรือ log achieve (AIJ)
SAT Vol. SAT Vol. backup Volume Backup
SUN log SUN log achieve
MON log MON log achieve
Incremental Backup
THU log THU log achieve
FRI log FRI log achieve
ตัวอยาง กรณี Disk crash วันพุธ 11:00
SAT Vol. 2nd Vol. Back 2nd Volume Backup

Merge
SUN log Mon morning
Merge
MON log Tue morning
Merge
TUE log Wed morning
Merge
WED log Wed 11:00
วิธีการตามรูปนี้เรียกวา Rollforward Activity เราสามารถทํา Rollforward ลวงหนาไดโดยการทํา Cumulative Backup
22
(Q) การทํา Backup มีกี่วิธี อะไรบาง
(A) ?
Database Export/Import
วัตถุประสงคของการทํา Export/Import
- เพื่อทํา DB Transportation จากระบบหนึ่งไปเปนอีกระบบหนึ่ง โดยที่ Design เหมือนเกา
- Physical Database Reorganization
เมื่อใชงานไปไดซักระยะหนึ่ง จะเกิด Fragmentation การ Export/Import จะชวยจัดระเบียบ Physical Data
ลักษณะการทํางานจะเปนการ convert data ไปเปน command เชน
Create …
:
Insert …
- นอกจากนี้ยังใชขยาย Physical limit ของ tables ซึ่ง คําสั่ง create table จะทําการสราง initial blocks
30 blocks
20 extensions
Max no of ext = 999
20 extensions
Parameter เหลานี้จะไปอยูใน DB Space Definition
23
Concurrent Execution
การที่ Transaction ถูกปฏิบัติรวมกันในเวลาเดียวกัน โดยอาศัยหลักการที่วา CPU ทํางานเร็วกวา I/O
Feature ของการทํา transaction
1. Correctness - จะเนนวาขอมูลที่ไดจะตองถูกตอง
2. Productivity – ทํางานเสร็จไดเร็วขึ้น
Outline ในการบรรยาย
1) ความถูกตองคืออะไร ในการทํา Concurrent Execution
2) ถาอยากไดความถูกตองเราตอง Set server/application อยางไรบาง ซึ่งจะมีหลายระดับ
3) ปญหาอุปสรรคที่ตองฝาฟน 4 ประการ
4) Set isolation แลวจะแกปญหาอะไร
5) DBMS ใชเทคโนโลยีแบบไหนถึงจะไดความถูกตองเหลานัน้
Concurrent Execution
ACID Properties เรื่องของ Concurrent Execution คือวาถามี 2 Transaction วิ่งรวมกันจะตองไมเห็นกัน
ถามี Ti และ Tj วิ่งรวมกัน |------------- Ti-------------|
Serializable Concurrent schedule
|------------- Tj -------------|
ใหผลลัพธเหมือนกับ |------------- Ti -------------|------------- Tj -------------| Serialize Schedule
ตัวอยาง Schedule 1 การโอนเงินซึ่งเปน Serial Schedule ที่ T1 นํา T2 ตาม
T1 T2
Read(A) หมายเหตุ
A := A – 50 Schedule เปนการจัดลําดับการปฏิบัติงานของคําสั่งใน Transaction
Write(A)
Read(B)
B := B + 50
Write(B)
Read(A)
temp := A * 0.1
A := A – temp
Write(A)
Read(B)
B := B + temp
Write(B)
24
Schedule 2 การโอนเงินซึ่งเปน Serial Schedule ที่ T2 นํา T1 ตาม
T1 T2
Read(A)
temp := A * 0.1
A := A – temp
Write(A)
Read(B)
B := B + temp
Write(B)
Read(A)
A := A – 50
Write(A)
Read(B)
B := B + 50
Write(B)
Schedule 3 การโอนเงินซึ่งเปน Concurrent Schedule ซึ่งผลลัพธเหมือนกัน Schedule 1

T1 T2
Read(A)
A := A – 50
Write(A)
Read(A)
temp := A * 0.1
A := A – temp
Write(A)
Read(B)
B := B + 50
Write(B)
Read(B)
B := B + temp
Write(B)
การที่จะดูวาผลลัพธสุดทายเหมือนหรือไมเหมือน DBMS ดูไดยากและ overhead สูง
25
(Q) Write (A) ใน T2 และ Read(B) ใน T1 สลับที่กันไดหรือไม
(A) สลับไดเพราะวาเปนคําสั่งที่ปฏิบัติบนคนละ Data item กันจะกลาวไดวาเปนคําสั่งที่ไม conflict
15.7, 15.8, 15.9 เปน Conflict Equivalent Schedule ซึ่งแปลงรูปไปมาซึ่งกันและกันได โดยการสลับตําแหนงคําสั่งที่ไม
conflict
15.7, 15.8 เปน Conflict Serializable Schedule เพราะวา Conflict Equivalent กับ Serial Schedule
(Q) ถาใหรูปมาแลวถามวา Conflict Serializable Schedule หรือไม
(A) ใหดูวาสลับแลวจะกลายเปน Serial Schedule หรือไม สามารถสลับตําแหนงคําสั่งที่ไม conflict กันไดมั๊ย
(Q) ถาถามวาสลับแลวผลลัพธถูกตองหรือไม
(A) ใชวิธีแทนคาไดเลย
สรุปนิยามของ Conflict
Transaction จะ conflict กันไดก็ตอเมื่อ 2 คําสั่งนั้นมาจากคนละ transaction กันและปฏิบัติงานบน Data item เดียวกัน
1 ใน 2 นั้นเปนคําสั่ง write
T3 T4
Read(Q) ผลลัพธสุดทายไมเหมือน Serial Schedule
Write(Q)
Write(Q) และ conflict
(Q) จากรูป 15.11 ถามวาถูกตองหรือไม
T1 T5
Read(A)
A := A – 50
Write(A)
Read(B)
B := B – 10
Write(B)
Read(B)
B := B + 50
Write(B)
Read(A)
A := A + 10
Write(A)
(A) ถูกตอง
26
(Q) Conflict Serializable หรือไม
(A) ไม เนื่องจากมีการ read กับ write บน B ดวยกัน จึงสลับกันไมได ดังนั้นจึงไม Conflict Serializable
(Q) จากรูป 15.12 ถามวาถูกตองหรือไม
T3 T4 T6
Read(Q)
Write(Q)
Write(Q)
Write(Q)
(A) ถูกตอง
(Q) Conflict Serializable หรือไม
(A) ไม เนื่องจากมีการ write บน Q ดวยกัน จึงสลับกันไมได ดังนั้นจึงไม Conflict Serializable
Conflict Serializability
15.11 15.10 ผิดและไม Conflict Serializable Schedule
15.12 ถูกตองแตไม Conflict Serializable Schedule
15.7 ถูกตองเปน View Serializable แตไม Conflict Serializable Schedule
15.8
ถูกตองและ Conflict Serializable Schedule
นิยาม
Schedule นี้จะเปน Conflict Serializable Schedule ก็ตอเมื่อ Schedule นั้น Conflict Equivalent กับ Serial
Schedule
View Serializability
จากรูป 15.12 จะเห็นวาคําตอบถูกตองแตไม Conflict Serializable ดังนั้นจึงมีอีกมาตรฐานหนึ่งขึ้นมาเรียกวา View
Serializable Schedule
นิยาม
Schedule นี้จะเปน View Serializable Schedule ก็ตอเมือ่ Schedule นั้น View Equivalent กับ Serial Schedule
27
กําหนดให S และ S’ เปน 2 Schedule ซึ่งมี Transaction ในชุดเหมือนๆ กัน การที่จะบอกไดวา S และ S’ เปน View
Equivalent กันไดนั้นจะตองมีคุณสมบัติ 3 ขอดังนี้
1) สําหรับแตละ data item Q ใดๆ ถา Transaction Ti Read(Q) เปนคนแรกใน Schedule S ก็จะตอง Read(Q) เปน
คนแรกใน Schedule S’ดวย
2) ใน Schedule S ถา Ti Read(Q) ซึ่งถูก Write(Q) โดย Tj ใน Schedule S’ Ti ก็จะตอง Read(Q) ซึ่งถูก
Write(Q) โดย Tj เชนกัน
3) สําหรับแตละ data item Q ใดๆ ถา Transaction Ti Write(Q) เปนคนสุดทายใน Schedule S ก็จะตอง Write(Q)
เปนคนสุดทายใน Schedule S’ดวย
*** Schedule ใดก็ตามที่ Conflict Serializable ก็ยอมจะ View Serializable ดวยเชนกัน ***
T1 T2 T1 T2
Read(A) Read(A)
Write(A) Write(A)
Read(A) Read(B)
Write(A) Write(B)
Read(B) Read(A)
Write(B) Write(A)
Read(B) Read(B)
Write(B) Write(B)
Schedule S Schedule S’
จะเห็นวา
1) ใน Schedule S T1 Read(A) เปนคนแรกใน Schedule S’ T1 ก็ Read(A) เปนคนแรกเชนเดียวกัน
2) ใน Schedule S T1 Read(B) เปนคนแรกใน Schedule S’ T1 ก็ Read(B) เปนคนแรกเชนเดียวกัน คุณสมบัติขอ 1 ผาน
3) ใน Schedule S T2 Write(A) เปนคนสุดทายใน Schedule S’ T2 ก็ Write(A) เปนคนสุดทายเชนเดียวกัน
4) ใน Schedule S T2 Write(B) เปนคนสุดทายใน Schedule S’ T2 ก็ Write(B) เปนคนสุดทายดังนั้น คุณสมบัติขอ 3 ผาน
5. ใน Schedule S T2 Read(A) ซึ่งถูก Write(A) โดย T1 ใน Schedule S’ T2 Read(A) ซึ่งถูก Write(A) โดย T1
เชนเดียวกัน
6. ใน Schedule S T2 Read(B) ซึ่งถูก Write(B) โดย T1 ใน Schedule S’ T2 Read(B) ซึ่งถูก Write(B) โดย T1
เชนเดียวกันคุณสมบัติขอ 2 ผาน และสรุปไดวา 2 Schedule นั้น View Equivalent กัน ดังนั้น Schedule S จึงเปน View
Serializable Schedule
28
Conflict Serializable เปน Subset ของ View Serializable
View Serializable
View Serializable แตไม Conflict Serializable
ซึ่งไดแก Blind write คือ Write โดยที่ไมมีการ Read ลวงหนา
Conflict Serializable
Recoverability
ขอสังเกตุคือทั้ง Conflict Serializable และ View Serializable นั้นดูเฉพาะคําสั่ง read และ write เทานั้น ยังไมไดมี
Failure เขามาเกี่ยวดวย ดังนั้นจึงมี Recoverable Schedule ซึ่งจะมีการพิจารณา Failure เกิดขึ้น
T8 T9
Read(A)
Write(A)
Read(A)
Read(B)
:
Fail
จากตารางจะเห็นวา T9 จากมีการ Read(A) ซึ่ง Write(A) โดย T8 แตสุดทาย T8 Fail และ Rollback ดังนั้นทําให T9 Read(A) ที่
ผิด ๆ ไป ซึ่งมองตามหลักการแลวนาจะ Rollback T9 ดวย แตเปนไปไมไดเนื่องจากวา T9 ได commit ไปแลว ลักษณะการจัด
แบบนี้เรียกวา Nonrecoverable Schedule ซึ่งเราไมอยากได
นิยาม
Tj จะ Read คาที่ Write จาก Ti ไดนั้นจะตองมีหลักอยูว า Ti ตอง commit กอนที่ Tj จะ commit ได
T10 T11 T12
Read(A)
Read(B)
Write(A)
Read(A)
Write(A)
Read(A)
จากตารางจะไดวา T12 ตอง commit กอน T11 และ T11 ตอง commit กอน T1 0 ซึ่งจะเกิดปญหา Cascading Rollback
Problem ถา T1 0 Fail จะทําให T11 และ T12 ถูก Rollback ไปดวย ซึ่งเราไมตองการ เราตองการ Cascadeless Schedule
29
Cascadeless Schedule
นิยาม
Tj จะ Read คาที่ Write จาก Ti ไดนั้นจะตองมีหลักอยูวา Ti ตอง commit กอนที่ Tj จะ read ได
ที่กลาวมาแลวทั้งหมด จะกลาวถึงความถูกตอง 100 % แตในทางปฏิบัติแลวเราอาจจะไมตองการความถูกตองขนาดนั้นก็ได
ซึ่งในระดับ SQL ก็จะสามารถทําได ซึ่งมีตั้งแต SQL92 แลว
สรุป
Cascadeless Schedule ทั้งหลายยอม Recoverable ได
Levels of consistency
เปนระดับของความถูกตอง (Isolation Level)
1) Serializable – จะไดวาเปน Conflict Serializable และ View Serializable (มีบาง Schedule ถูกตองแตไมออก)
แกปญหา Cascadeless และ Phantom phenomenon
|------------- T1 = sum (acct) -----------|
เรียกวา Phantom phenomenon
|------ T2 ------|
(Q) ผลลัพธของ T1 ควรจะเห็น T2 หรือไม

(A) ไมควรเห็น เนือ่ งจากจะตองจะตองทํางานเสมือนกับวา T1 นํา T2 ตาม
2) Repeatable read เกือบเหมือน Serializable ยกเวนไมไดแกปญหา phantom phenomenon คือ insert เขาได
3) Read committed (spec) หรือ Cursor Stability (algorithm) รับประกันเพียง Cascadeless เทานั้น
4) Read uncommitted หรือ dirty read ไมรับประกันอะไรเลย
(Q) สมมุติวา Cursor ชี้ที่ row แรกมีคา x ถา cursor เดินหนาไปแลวถอยหลังกลับมา ถามวาจะมีโอกาสที่จะเห็น x เปนคาเปน
y หรือไม
30
(A) การที่จะเห็นคาเกาหรือไม ไมไดขึ้นกับภาษาแตจะขึ้นกับการ set isolation level ซึ่งถา set เปน dirty read ก็จะเห็น
แตถา Set เปน repeatable read ก็จะเห็นคาเกาเสมอ
ปญหา 4 ขอใน Concurrency control
1. Lost update problems
TA TB
Fetch(R)
: Fetch(R)
Update(R)
Update(R)
จากตาราง การ Update(R) ของ TA ไดหายไป
2. The uncommitted dependency problems
TA TB
: Update(R)
Fetch(R) :
: Rollback(R)
จากตารางไดวา TA ไดอานคา R ซึ่งถูก Update โดย TB และยังไม commit ถาหาก TB Rollback ภายหลังก็จะไดวา TA
ไดนําคาที่ผิดๆ ไปใช
31
3. The inconsistency analysis problems
Acc1 [40] Acc2 [50] Acc3 [30]
TA TB
Fetch(Acc1) [40]
Sum = 40
Fetch(Acc2) [50]
Sum = 90
Fetch(Acc3) [30]
Update Acc3 [30] Æ [20]
Fetch(Acc1) [40]
Commit
Fetch(Acc3) [20]
Sum = 110 not 120
เปนการวิเคราะหขอมูลที่ผิดๆ ซึ่งถานํา TA มาวิ่งเดี่ยวๆ ก็จะไดคา Sum = 120
4. The Phantom Phenomenon
เปนปญหาการ Insert
การใช Locking นั้นจะแกปญหาที่เกิดขึ้น ณ จุดเวลา แตปญหาทั้ง 4 ขอที่กลาวมาแลวเปนปญหาที่เกิดขึ้น ณ ชวงเวลา
ทําใหเราไมสามารถ Lock ตามสบายใจได ดังนั้นเราจึงตองใช Lock Protocol เขามาชวย
เราสามารถใช Isolation level มาแกปญหาทั้ง 4 ขอนี้ไดดังนี้
1) Serializable - จะแกปญหาทั้ง 4 ขอ
2) Repeatable Read - แกปญหาขอ 1, 2, 3
3) Read Committed – แกปญหาขอ 2
4) Read Uncommitted - ไมไดแกปญหาขอไหนเลย
32
Concurrency Control
Lock-based Protocol
การทํา Concurrency control โดยใช Locking มีปจจัย 3 อยางคือ
1) Lock primitives Æ คําสั่งที่ใชในการ Lock มี 2 อยาง
- X-lock - Data Item สามารถ Read และ Write ได
- S-lock – Data Item สามารถ Read ไดอยางเดียว
2) Compatibility Matrix Æ คําเปนการบอกวาถาเราทํา Lock primitives ไวแลวคนอื่นจะ Lock Primitives อะไรไดบาง
S X
S T F
X F F
T1 T2 DBMS
Lock-X(B) Grant หมายถึงใหสิทธิ
Grant-X(B, T1)
Read(B)
B := B – 50 จะไดวาคําตอบไมถูกเนื่องจากวา
Write(B) T1 ได Modify คา B ไปแลว
Unlock(B) T2 แลวมา Read คา A ซึ่งเปน A เกา
Lock-S(A)
Grant-S(A, T2) แตพอ T2 Read คา B เปน B ใหม
Read(A) สรุปวาใน Schedule นี้ T2 Read คา A เกา และ B ใหม
Unlock(A) ซึ่งเปน Inconsistence Analysis ในรูปแบบหนึ่ง
Lock-S(B)
Grant-S(B, T2) ถาจะใหถูกแลวผลลัพธจะตองเสมือนวา T1 นํา T2 ตาม
Read(B)
Unlock(B)
Display(A+B)
Lock-X(A)
Grant-X(A, T2)
Read(A)
A :+ A + 50
Write(A)
Unlock(A)
33
3) Locking Protocol Æ คือขั้นตอนในการใชคําสั่ง Lock และ Unlock ไมใชวาจะ Lock เมื่อไหรก็ไดตามสบายใจ
ซึ่ง Protocol ที่นิยมใชคือ 2-phase locking protocol
2-Phase Locking Protocol
แบงไดเปน 2 Phase คือ
- Growing phase Æ คําถา Lock ตอง Lock ใหหมดเสียกอน และ Lock ไดอยางเดียว Unlock ไมได
- Shrinking phase Æ ถา Unlock แลวก็จะ Lock อีกไมได
Lock A
รับประกัน Conflict Lock B Phase I
Serializable ซึ่งจะ Lock C
แกปญหาขอ 1 และขอ :
3 แตขอ 2 ยังมีโอกาส Unlock B
เกิดขึ้นได Unlock A Phase II
Unlock C
พิจารณาปญหา
1) ปญหาขอที่ 1 เมื่อนํา 2-phase Locking ไปใชกับตัวอยางที่ผานมาพบวาคําตอบที่เคยผิดก็ไมผิด แตจะเกิดเปน Deadlock แทน
2) ปญหาขอที่ 2 ยังมีโอกาศเกิดขึ้นไดเนื่องจากยังมีโอกาศเกิด Transaction Fail ขึ้นได
3) ปญหาขอที่ 3 คือวิเคราะหขอมูลอยูมีคนเขามา Update ก็ติด Deadlock เชนกัน
4) ปญหาขอที่ 4 นั้น 2-phase locking ยังไมไดแกเนื่องจาก Insert สามารถเขาได
วิธีแกปญหาขอที่ 1 และ 2 จาก Deadlock
Lock-X ใหเรียบรอยตั้งแตตน ซึ่งตองเพิ่มเงือ่ นไขจะวา Lock-X ไปปลด Lock ที่จุด Sync Point เทานั้น
เราเรียกวา Strict 2-phase Locking
วิธีแกปญหาขอที่ 3 จาก Deadlock และ 4
ใชวิธี Lock ที่ระดับใหญกวา row ซึ่งจะเรียกวา multiple granularity
นั่นคือถาใช Strict 2-phase Locking รวมกับ multiple granularity ก็จะแกปญหาครบทั้ง 4 ขอ
34
Multiple Granularity
เปนความสามารถในการ Lock เล็ก Lock ใหญ เพื่อแกปญหาขอ 3, 4 และชวยลด overhead ขณะ off-peak กลาวคือ
Lock เล็กๆ ขณะ peak แตเมื่อเวลาที่ไมมีใครใชงานก็สามารถ Lock ใหญๆไปเลยได
Lock Promotion หรือ Lock Escalation เปนการ Lock เล็กไปหาใหญ
(Q) ถา DBMS ตองการ Lock ขนาดใหญจะทราบไดอยางไรวามี Lock ที่ขนาดเล็กกวาใชงานอยู
(A) จะมีการใช Intention locking เขามาชวย
1. Lock primitives สําหรับ Intention Locking
- Intention-share (IS) Æ ถา IS node ไหน subtree ใต node นั้นจะถูก share
- Intention-exclusive (IX) Æ ถา IX node ไหน subtree ใต node นั้นจะถูก exclusive จริง
- Shared and intention-exclusive (SIX) Æ ถา SIX node ไหน node นั้นจะถูก share และ subtree ใต node
นั้นจะถูก exclusive
2. Compatibility Matrix สําหรับ Intention Locking
IS IX S SIX X
IS T T T T F
IX T T F F F
S T F T F F
SIX T F F F F
X F F F F F
ตัวอยาง IS
จากรูปเมื่อตองการ Select sum ตาราง DBMS ก็จะปฏิบัติตามขั้นตอนตอไปนี้

Fb
1. ทําการ intention share DB space เพื่อใหรวู ามีการ share จริงอยูขางใต

2. จากนั้นก็ทําการ intention share A1
35
3. share Fb
4. ถามีคนตองการจะ Exclusive r
b1 ก็จะเริ่ม IX ณ จุด DB ซึ่งจะพบวา DB ถูก IS อยูกอนแลว
จาก Compatibility Matrix จะไดวา IS กับ IX จะเปน True
5. ลงมาทําการ IX ณ จุด A1 จะพบวา A1 ถูก IS ซึ่งจะไดเปน True
6. ลงมา IX ณ จุด Fb ซึ่งจะพบวา Fb ถูก S และเมื่อ IX เจอกับ S ก็จะไดเปน False ซึ่งจะตอง Wait
ตัวอยาง SIX
ยังงงอยู
36
Weak Level of Consistency
จะมีงานบางงานที่ตองการ Response time ดีๆ ซึ่งถาใช Serializability จะไมไหว ทําใหตองลดความถูกตองลง
1) Degree-Two Consistency
มีเจตนาที่จะแกปญหาขอ 2 เทานั้นคือหลีกเลี่ยง Cascading Abort ไมสนใจ Serializability กลาวคือ จะตอง Commit กอน
ถึงจะread ได มีการใช X-Lock และ S-Lock โดยที่จะมีการ S-Lock ทั้ง Result และจะ unlock ทีละ Row เมื่อ Cursor วิ่ง
ผานแตถามีการ Write ก็จะทําการ X-Lock ซึ่งจะ Unlock ที่จุด Sync Point เทานั้น
2) Cursor Stability
จะ S-Lock และ Unlock ในแตละ Row แตถามีการ Write ก็จะทําการ X-Lock ซึ่งจะ Unlock ที่จุด Sync Point เทานั้น
ซึ่งไมวาจะ Move Cursor ไปขางหนาหรือถอยหลังก็อาจจะเห็นของใหมได
(Q) Degree-Two Consistency และ Cursor Stability ตางกันอยางไร
(A) - Cursor Stability นั้นถา Cursor ชี้ Row ไหนก็จะ Lock Row นั้นถามีการ Move Cursor ก็จะปลด Lock แลวไป Lock
Row ใหม (Cursor ผานไปแลวก็ Unlock เลย) ถามีการ Update Row ไหน Row นั้นจะถูก X-Lock แลวไปปลด Lock
ที่จุด Sync Point
- Degree-Two Consistency เมื่อ Open Cursor ก็จะ S-Lock ทั้งกอนเลย ซึ่งเมื่อ Move Cursor ไปขางหนาก็จะมีการปลด
Lock ไปทีละ Row นั่นคือปลด Lock ขางหลังแตไมไดปลด Lock ขางหนา ถามีการ Update Row ไหน Row นั้นจะถูก
X-Lock แลวไปปลด Lock ที่จุด Sync Point
Timestamp-Base Protocol
หลีกเลี่ยง Deadlock โดยใชเวลาเขามาเกี่ยวของ 3 สวนคือ
1) Timestamp ของ transaction
เปนการ Mark วา Transaction เกิดขึ้นอาจใช real-time clock หรือ logical counter ซึ่ง oracle จะใช logical counter
ซึ่ง Transaction ใดเกิดขึ้นกอนก็จะมี Timestamp นอยกวา Transaction ใดเกิดหลังก็จะมี Timestamp มาก
2) Write Timestamp
Timestamp ของ transaction เด็กสุดที่ write ไดสําเร็จ
3) Read Timestamp
Timestamp ของ transaction เด็กสุดที่ read ไดสําเร็จ
37
Timestamp-Ordering Protocol
รับประกัน Conflict Serializability
1) กรณี Read
a. ถา TS( Ti ) < W-Timestamp(Q) แลว Ti จะ Read(Q) ไมได และตอง Rollback
b. ถา TS( Ti ) ≥ W-Timestamp(Q) แลว Ti จึงจะ Read(Q) ไดสําเร็จและทําการบันทึก TS( Ti ) เปน R-
Timestamp(Q)
2) กรณี Write
a. ถา TS( Ti ) < R-Timestamp(Q) แลว Ti จะ Write(Q) ไมได และตอง Rollback
b. ถา TS( Ti ) < W-Timestamp(Q) แลว Ti จะ Write(Q) ไมได และตอง Rollback
c. นอกนั้นก็ Write(Q) ไดสําเร็จและทําการบันทึก TS( Ti ) เปน W-Timestamp(Q)
พิจารณาปญหา Acc1 [40] Acc2 [50] Acc3 [30]
TA TB
Fetch(Acc1) [40]
Sum = 40
Fetch(Acc2) [50]
Sum = 90
Fetch(Acc3) [30]
Fetch(Acc1) [40]
Commit
Fetch(Acc3) [20]
Sum = 110 not 120
1) ปญหาขอ 1 Lost update problem ถาเอา Timestamp protocol มาจับดูจะไดวา Transaction A จะ Rollback
ตามกติกาขอ 1a
2) ปญหาขอ 2 นี้ Timestamp protocol ไมไดดูแลเลย เพราะวาไมมีการเช็คเลยวามีการ commit แลวหรือไม
และเพื่อแกปญหาขอ 2 ก็จะใหมี Commit bit ขึ้นสําหรับแตละ transaction หรืออีกวิธีหนึ่งคือใช X-Lock เขาชวย
กลาวคือถา Update แลวยังไม commit ก็ใหติด X-Lock ไวกอนแลวไปปลด Lock ที่จุด Sync Point
(Q) ถาหาก Timestamp Protocol เอา X-Lock เขามาเพื่อชวยแกปญหาขอ 2 แลว จะมีกรณีเกิด Deadlock ขึ้นหรือไม
(A) จะไมเกิด Deadlock เพราะโอกาศที่ transaction ที่มากอนรอจะไมเกิดขึ้น จะมีก็แต transaction ที่มาทีหลังรอ
38
3) ปญหาขอ 3 Transaction A ไมสามารถ Fetch(Acc3) ไดเนื่องจาก Acc3 ถูก Write ดวย Transaction B ซึ่งเด็กกวา
ดังนั้น Transaction A จึง Rollback ตามกติกาขอ 1a
4) ปญหาขอ 4 หาก Transaction B เปลี่ยนจาก Update Acc1 เปน Insert Acc4 และ Transaction A ไมสามารถ
Fetch(Acc4) ไดเนื่องจาก Acc4 ถูก Write โดย Transaction B ซึ่งเด็กกวาดังนั้น Transaction A จะ Rollback
Thomas’ Write Rule
แตปญหาที่เกิดขึ้นคือมีการ Rollback บอยมาก ซึ่งจะตองหาทางวาไมให Rollback พรอมกับผลลัพธก็ไมผิดดวย
T3 T4 T6
Read(Q)
Write(Q)
Write(Q)
Write(Q)
จากตารางขางตนจะเห็นวา T3 ไมสามารถ Write (Q) ไดเนื่องจาก Q ถูก Write โดย T4 ซึ่งเด็กกวาดังนั้น T3 จึง Rollback
แตจากตารางจะเห็นวาทายสุด Q จะถูก Write โดย T6 ดังนัน้ จึงมีผูคิดคนกฏขึ้นวาถาเจอกรณีแบบนี้ ให T3 Ignore Write
Schedule นี้ก็สามารถวิ่งได
Multiversion Timestamp Ordering
ใน Timestamp Protocol Ti ไมสามารถ read r ซึ่งถูก write โดย Tj ซึ่งเด็กกวา ดังนั้น Ti จึง Rollback และ Multiversion ก็จะ
เขามาแกปญหานี้โดยการไมให Ti write ทับแตจะใหตั้งเปน version ใหม ซึ่ง Ti จะ read คา r เกา
Ti r 0
r 1
Tj
แนวคิด
Write Version ใหมเสมอไมทับของเกา เวลา read ก็ read ใหถูก version เปนการแกปญหาขอ 3 และ ขอ 4
สนับสนุน Flash Back Query หมายถึงการถามยอนอดีต
(Q) จากแนวคิดนี้ปญหามีอยูวา Version พวกนี้อยูนานเทาไหร
(A) เมื่อ Write TS ของ version นั้นๆ แกกวา Transaction ที่แกที่สุด
(Q) จากรูปขางบนในทางปฏิบัติ r 0 อาจจะไมไดอยูใน buffer แลวก็ได เมื่อ Ti ตองการใชงานจะหา r 0 มาจากไหน
(A) จาก BIJ เนื่องจาก BIJ จะเก็บ old value ใน oracle จะเก็บ BIJ ไวใน DB Space เรียกวา Rollback Segment เพื่อ
ไปสนับสนุน Multiversion engine กรณีที่ Ti หา r 0 ใน DB Buffer หรือ Rollback Segment ไมพบ Oracle
จะขึ้น message วา “Serializability cannot be achived”
39
กรณี Read
Ti จะ Read(Q) ที่มี W-Timestamp เด็กสุดที่มากกวา TS(Ti)
กรณี Write
กรณี Ti จะ Write(Qk+1) แต Tj ซึ่งเด็กวาได Read(Qk) ไปกอนแลวกรณีนี้ Ti จะ Write(Qk+1) ไมได Ti จะตอง
Rollback นอกนั้นจะ Write ได (กติกานี้เอาไวดูแลปญหาขอ 1)
พิจารณาปญหา
1) ปญหาขอ 1 ยังมีการ Rollback
Ti Tj
Read(Qk)
Read(Qk)
Write(Qk+1)
Ti มีไมสามารถ Write(Qk+1) ไดเนื่องจาก Qk ถูก Read โดย Tj ซึ่งเด็กกวากอนดังนั้น Ti จึง Rollback
2) ปญหาขอ 2 มีการใช commit bit
3) ปญหาขอ 3 ผาน และก็ไม wait
4) ปญหาขอ 4 ผาน เพราะวาคน write ก็ Write ไดโดยไมตอง Wait สวนคนเกาก็จะขามไปโดยไมหยิบมาอาน
(Multiversion Timestamp Ordering นี้ไมไดรับประกัน Recoverability และ Cascadeless)
Multiversion 2-phase locking
กรณี Read Only Transaction
Ti จะ Read
รับประกัน Recoverability และ Cascadeless ซึ่งจะดูแลปญหาขอ 1 และขอ 2 ซึ่งเปนวิธีที่ Oracle ใช
40
Query Processing
(เนื้อหาบทที่ 13 ในหนังสือ)
เปนภาษาของ Relational Database
ภาษาที่ User หรือ program ใชติดตอกับ DBMS เปนภาษาตระกูล what ซึ่งเปน definition ของ result ที่ตองการโดยไม
ตองบอกวาทําอยางไร เริ่มแรกมาจาก Relational calculus ซึ่ง result ออกมาจะตรง 100 % ตางจาก information retrieval ซึ่งเปน
procedural language ภาษาที่ใชภายใน DBMS เปนภาษาตระกูล how ซึ่งทําอยางไรจึงจะได result และภาษาที่ support how คือ
ภาษา relational algebra ซึ่งเปน Non procedural language ภาษาตระกูล how จะเปรียบเหมือนกับ machine language ของ
database
Query = ภาษา SQL ใดๆ

Parser and translator = ตรวจไวยากรณและแปลเปน relational algebra
Database statistics = เก็บขอมูลตางๆ ที่จําเปนในการทํา cast-based opt.
Optimizer = คนหาเสนทางที่ดีที่สุดโดยใช database statistics ซึ่งถาไมมี
สถิติเหลานี้ Optimizer จะทํา rule-based optimization
หมายเหตุ
ถานํา 2 table มา join กัน table1 เก็บสถิติ table2 ไมเก็บสถิติ การทํางานจะเก็บสถิติสดๆ ของ table2 ณ ตอน query เลย
ทําให Query ชามากกวาไมไดเก็บสถิติทั้ง 2 tables
41
ตัวอยาง SQL statement
SELECT balance FROM account WHERE balance < 2500
แปลงเปน Relational algebra แลวจะได
σ balance < 2500

Relational algebra
เปน Procedural language มี 8 operator หลักๆ โดยสวนของ Data ใหเขียนตัวเล็ก สวนของ schema ใหเขียนตัวใหญ
1) SELECT หรือ Restrict แทนดวย σ
เลือกเฉพาะ Tuple ที่สอดคลองตามเงื่อนไข
s σ QTY = ' London '

s
2) PROJECT แทนดวย π
เลือกเฉพาะ Column ที่ตองการ
s
π S #, STATUS
s
3) Natural Join แทนดวย เปนการ Match value ที่เหมือนกันของ common attribute ซึ่ง common attribute ที่
ที่ปรากฏที่ Output เพียงครั้งเดียว
s x y r x z
x1 y1 x1 z1
x2 y2 x2 z2
x3 y3 x3 z3
s r
x y z
x1 y1 z1
x2 y2 z2
x3 y3 z3
42
ให List S#, STATUS ของ supplier ใน London
πS#, STATUS (σCITY=’London’ s)
SELECT balance FROM account WHERE balance < 2500
เขียนเปน Relational algebra ได 2 คําสั่ง
1. σ BALANCE < 2500 (πBALANCE(account))
2. πBALANCE (σBALANCE < 2500 (account))
จากนั้น Optimizer จะดูวาวิธไี หนดีกวา ซึ่งจะดูวาวิธีไหนมี disk block access นอยกวา ก็จะเลือกวิธีนนั้
** ปจจุบัน DBMS จะเลือก select (วิธีที่ 2) กอนเนื่องจากการเก็บ data จะเก็บเปน row จากนั้นจึงคอยนํามาตัดเปน column ใน
memory **
πBALANCE
|
σBALANCE < 2500
|
account
S ( S #, SNAME, CITY ) SP( S # , P #, QTY )
List SNAME ของ London Supplier ที่ Supply P2

SELECT SNAME FROM S, SP WHERE S.S# = SP.S# AND CITY = ‘London’ AND P# = ‘P2’
1) πSNAME (σP# =’P2’ (σCITY =’London’ (s sp)))
πSNAME
|
σP# =’P2’
|
σCITY =’London’
|
/ \
s p
43
2)
πSNAME
|
/ \
πS#,SNAME πS#
| |
σCITY =’London’ σP# =’P2’
| |
s p
Optimizer จะเลือก unary operator กอน ถา optimizer เลือก plan 1 เปนไปไดวาไมไดทํา index ซึ่งจะตองทํา
Full table scan ดังนั้นถาทํา index ไว optimizer จะเลือก plan 2
การทํา Query จะมี 3 ฝายเขามาเกี่ยวของ
1. คน -> เขียนคําสั่ง SQL
2. DBA -> สราง index, เก็บ statistics
3. Optimizer -> เลือกเสนทางที่ดีที่สุด
(Q) ถาตองการ result หนึ่งจะใชวิธี join หรือเรียกใช subquery จึงจะทํางานไดเร็วกวา
Select sname
From S
Where s# in (
Select s#
From SP
Where p# = ‘P2’)
And city = ‘London’
(A) ในการที่จะเลือกใช join หรือ subquery นั้นขึ้นกับปจจัยหลายอยาง เชนยี่หอ DBMS ก็มีสวนเชน oracle จะ join
เร็วกวา
แตถา DB2 เลือกใช subquery ก็จะเร็วกวา
จาก SQL Statement เปนการ join ที่เรียกวา semi-join ซึ่งจะแบงเปน 2 แบบคือ
- semi join positive
- semi join negative
ในปจจุบันมีการทํา Semantic optimization ซึ่งใช business rule มาชวยในการคนหา
44
ฐานขอมูลมี Business rule คือยืมหนังสือไดไมเกิน 5 เลม ถาตองการ query จํานวนนักศึกษาที่ยืมหนังสือ 8 เลม
DBMS ตรวจสอบพบวาขัดกับ business rule ก็จะ return result เปน not found กลับมาโดยไมจําเปนตองอาน disk เลย
ตัวอยาง Database statistics
(1) n r = จํานวน tuple ของ relation r
(2) b r = จํานวน block ของ relation r
(3) f r = blocking factor ของ relation r (จํานวน tuple ใน 1 block)
(4) V ( A, r ) = จํานวน distinct value ของ attribute A
ของ Relation r (จํานวนที่ไมซ้ํา)
เชน V (CITY , s) Æ มีเมืองกี่เมืองอยูในตาราง s
(5) SC ( A, r ) Æ Selection cardinality คือจํานวน tuple ที่มีคา attribute value ของ A
ตามที่กําหนดให (No of row retrieved)
Selection Operation
เปน Algebra operator ซึ่งจะ implement ไดหลายวิธี
A1. Linear search
ใชในกรณีที่ไมมี Index เปนการทํา Full Table Scan

Cost ของการทํา Linear Search = b r
กรณีเปน Key attribute จะใช
b
Cost = r
2
A2. Binary search
ใชในกรณีที่ไมมี Index และ data sort ตาม physical เรียบรอยแลว หรือมีการทํา clustering เรียบรอยแลว
การทํา Clustering หมายถึงการนํา row ที่ใชดวยกันบอยๆ (Logical adjacent rows) มาเก็บไวดวยกัน (ใน
block เดียวกันหรือ Block ใกลเคียงกัน) และมีการ Sort data ในระดับ physically ทําไดดวยคําสั่ง
Alter table cluster …
⎡ ⎤
Cost ของการทํา binary search = ⎡log 2 (b r )⎤ + ⎢ nr
⎥ −1
⎢V ( A, r ). f r ⎥
45
ตารางมี 1000 rows n r = 1000
มีเมืองทั้งหมด 100 เมือง V ( A, r ) = 100
Blocking factor คือ 20 f r = 20
จาก
⎡ nr ⎤
br = ⎢ ⎥
⎢ f r⎥
จะไดวา
1000
br = = 50
20
⎡ ⎤
Cost = ⎡log 2 (b r ) ⎤ + ⎢
nr
จาก ⎥ −1
⎢V ( A, r ). f r ⎥
จะไดวา
⎡ 1000 ⎤
Cost = ⎡log 2 (50) ⎤ + ⎢ −1
⎢100 × 20 ⎥⎥
= ⎡⎢ log 50 ⎤⎥ + ⎡0.5⎤ − 1
⎢ log 2 ⎥
= ⎡1.699 ⎤
⎢⎢ 0.301⎥⎥ + 1 − 1
= ⎡5.645⎤
= 6 block accesses
จาก Search Condition
(Q) Index กับ key ตางกันอยางไร
(A) Index ไมใชสวนหนึ่งของ relation แตเปนกลไกในการเขาถึงขอมูลใหเร็วขึ้น ซึ่งอาจจะมีซ้ํา
Key เปน Identifier ซึ่งจะเนน Uniqueness และเปนสวนหนึ่งของ relation
(Q) Primary Index คืออะไร
(A) คือการทํา Index บน Column ที่ระบุ Consequence ของ table หรือกลาวอีกอยางหนึ่งวา เปน Index ที่ Sort ทาง
เดียวกับ Data หรือ cluster index สวน Secondary Index คือ Index ที่ Sort คนละทางกับ Data
A3. Primary index, equality on key
จะใชกรณีที่ Search key เปน Primary Index และทําการ search บน column ที่เปน candidate key
Cost = HTi + 1
โดยที่ HTi เปนความสูงของ index
46
A4. Primary index, equality on non-key
จะใชกรณีที่ Search key เปน Primary Index และทําการ search บน column ที่เปน non-key
Cost = HTi + b r
ซึ่ง
SC ( A, r )
br =
fr
A5.1 Secondary index, equality on key
จะใชกรณีที่ Search key เปน Secondary Index และทําการ search บน column ที่เปน candidate key
Cost = HTi + 1
A5.2 Secondary index, equality on non-key
จะใชกรณีที่ Search key เปน Secondary Index และทําการ search บน column ที่เปน non-key
Cost = HTi + SC ( A, r ) assume วา 1 row มี 1 block
I1(PI) I2(SI)
Select * From s
Where CITY=’PARIS’ Æ 200 rows
And STATUS = 30 Æ 20 rows
กําหนดให Blocking Factor = 25 จะไดวา
CITY เปน Primary Index
SC ( A, r ) 200
br = = =8
fr 25
STATUS เปน Secondary Index
b r = SC ( A, r ) = 20
ดังนั้น Search CITY จะใช 8 blocks แต Search STATUS ใช 20 blocks ดังนั้นเลือก CITY ดีกวา
จะไดวา Cost CITY = 'PARIS ' = HTi + 8
Cost STATUS =30 = HTi + 20
47
Join Operation
1. Nested-Loop Join
ใชสัญลักษณ θ θ = Join Condition ซึ่งไมจําเปนตองเปน เทากับ

กําหนดให S SP
S มี 200 rows Æ 10 blocks
SP มี 200,000 rows Æ10,000 blocks
Blocking factor = 20
กําหนดใหทั้งสองตารางไมมี Index
กรณีที่ 1 S เปน Loop นอก SP เปน Loop ใน
S SP
S 1 rows ใช SP 10,000 blocks

S 200 rows ใช SP 2,000,000 blocks
จาก
จํานวน Block = b s + (b s × b sp)
ดังนั้นใช S = 2,000,000 + 10 = 2,000,010 blocks
กรณีที่ 2 SP เปน Loop นอก S เปน Loop ใน
SP S
SP 1 rows ใช S 10 blocks

SP 2,000,000 rows ใช S 10 blocks
(เนื่องจากวา S 10 block นอยมาก สามารถเก็บใน Buffer ไดตลอดไมวา SP เปลี่ยนไปก็ยังใช S 10 block เดิมได)
จาก
จํานวน Block = b s + b sp
ดังนั้นใช SP = 10,000+10 = 10,010 blocks
สรุปไดวาเอาตารางที่มีขนาดใหญไวขางนอกดีกวา
48
2. Block Nested-Loop Join
เมื่อ 2 ตารางที่ Join กันนั้นมีขนาดใหญเกินกวาที่จะอยูใน Main memory ได ซึ่ง memory จะมีที่ใหลงอยางละ block
เทานั้นในแตละ table
กําหนดให r s
1 block ของ r ใช s b s block
b r Block ของ r ใช s b s × b r block
ดังนั้น จํานวน Disk block = br + (b s × br )

สรุปวาถาเอาตารางเล็กไวขางนอกถึงจะดี
3. Indexed Nested-Loop Join
Search key เปน attribute หรือ set of attribute ที่ใชในการ lookup record ใน files
(Q) Search key กับ Candidate key แตกตางกันตรงไหน
(A) Search key กลาวถึง Search Condition สวน Candidate Key กลาวถึง Unique Identifier
Dense Index เปน index ที่มี search key ครบทุก key value
Sparse Index เปน index ที่มี search key ไมครบทุก key value
Sparse index นั้นจะไดเปรียบขอเดียวตรงที่ประหยัด space โดยที่ sparse index จะชี้ไปที่ตน block แลวหยิบ
มาทั้ง block จากนั้นจะเขาไปหาใน block วา row ที่ตองการอยูที่ไหน
(Q) Dense index เร็วกวา sparse index ตรงไหน
(A) Dense Index มีครบทุก search key และ sort จึงสามารถใช binary search ในการคนหา index ได
Sparse Index มีไมครบทุก search key ดังนั้นการคนหา index จะตองใช linear search
แบง Search space ออกเปนชวงๆ จะไดไมตอง search ทั้งหมด มีลักษณะเปน tree และ B±Tree คือ Balance Tree
n มากจึงจะดีเพราะวา tree ตนเตี้ย

ในทางปฏิบัติ n จะขึ้นกับขนาดของ search key ถา search key เล็ก n จะมาก
49
(Q) ตารางนี้มีกี่ row
(A) สามารถนับที่ Dense Index Entry ไดเลย
HT คือความสูงของ tree
⎡ ⎤
HT <= ⎢ log n ( K ) ⎥
⎢ 2 ⎥ K = Search Key Value
B-Tree
B±Tree
(Q) B-Tree ตางกับ B±Tree ตรงไหน
(A) B-Tree นั้นแตละ node จะชี้ไปยัง dataset ไดเลย แตถา B±Tree ทุกตัวจะตอง search จาก root ไปยัง leaf
ดังนั้น B±Tree จึงมี overhead ในเรื่องการ insert และ delete แตใชงานเอนกประสงคกวา และทํา balance tree ได
งายกวา
50
4. Hash Join
Static Hashing
Hashing เปนการเขาถึง Data โดยไมตองใช index แตใชการคํานวณ โดยใช Hash Function
Search Hash Function Dataset
David
Peter
John
David Somchai
H(search key) => dataset address

จะใชในกรณีที่มี Data ไมมากแต database จะเลี่ยง collision ไมได เราตองเลือก Hash Function ใหเหมาะสม
Hash Function ที่เหมาะสมกับ 10,000 rows อาจใชไมไดกับ 100,000 rows นอกจากนั้นก็เปนเรื่องของขนาดและ data type
ของ search key
วิธีที่ Database ที่จะแกปญหาการเกิด collision
1 bucket จะมีหลาย database block
จะตองขยายขนาดเปน Bucket จะได Hash Cluster ถา bucket เต็มจะเกิด Overflow Bucket
Bucke t0
Bucke t1
Bucke t2 Overflow Bucket for Bucket 1
Bucke t3
51
Hash Index
จากรูปมีการสราง Bucket เปนดานหนาแลวชี้ไปยัง Data ตริง

ขอดี
มีไดลาย Hash Index ตอ 1 Dataset
Bucket เปลาๆจะถูกสรางขึ้นมาตอนสราง index จํานวน bucket นั้นจะขึ้นอยูกับ Hash function ที่ใช และเมื่อเกิด overflow ขึ้นก็
จะมีการ chain bucket ขึ้นมา ซึ่งปกติแลว Hash Index จะมี HTi = 1 เสมอ
(Q) กรณีที่ Hash Index Overflow เยอะเราจะทําอยางไร
(A) Drop index เดิมทิ้ง
Create index ใหมโดยใช Hash Function ที่เหมาะสม ซึ่งไมมีผลใดๆกับ application
52
Temporal Database
มีคําถามวาใน 10 ปที่ผานมามีใครเคยอยูบานเดียวกับคุณบาง ถาเปนฐานขอมูลธรรมดาจะไมสามารถตอบไดเลย
คําถามนี้เปนการเช็คชวงเวลา เพื่อตอบคําถามเหลานี้จึงมี Research เกิดขึ้นมากมายและนําไปสู Temporal Database
ในสหรัฐมีเด็กแฝด 7 คนซึ่งจะมีการเก็บสถานะของสุขภาพของเด็กแตละคนในแตละชวงเวลาดังตาราง
Max Value ของ Data Type Date

หรือ Infinity หมายถึงยังเปนจริง
จนถึงปจจุบัน
ตารางนี้เปนชวงเวลาที่กําหนดเปน Close-Open Format ซึ่งหมายถึง From Date นั้นจะรวมเวลาที่ Fact Valid แต To Date นั้น
ไมรวม จากรูปจะเห็นวา Joel Steven จะ Critical ตั้งแต 1997-11-19 จนถึง 1997-11-20 (ไมรวม) พอถึง 1997-11-20 Joel Steven
จะเปลี่ยนสถานะเปน Serious ไปจนถึง 1998-01-03 (ไมรวม)
Valid-Time State Table
หมายถึง Table ที่เก็บวา Fact นั้น valid ตั้งแตเมื่อไหรถงึ เมือ่ ไหร ใชกับตารางที่มีการเปลี่ยนสถานะไปเรื่อยๆ เชน
เงินเดือน, ชื่อ เปนตน
(Q) จากตารางขางตนเปนไปไดหรือไมวาเก็บเฉพาะ From Date แตไมเก็บ To Date
(A) ทําได แตการเช็คชวง Overlap จะทําไดยากและอาจจะมีปญหาเรื่อง Fact ไมตอเนื่องเชนการเปนสมาชิกชมรมกีฬาตางๆ
EMP ( E # , ENAME , ADDR , DEPT , SALARY )
ตารางนี้เดิมเปน 5NF แตหลังจากที่เพิ่ม fromdate และ todate เขาไปแลวจะไดวาถามีการเปลี่ยน Address ทําใหเกิด Row ใหมซึ่ง
มี Key value เดิมทําใหเกิดขอมูลซ้ําซอนเปนจํานวนมาก
ดังนั้น Primary Key ก็จะซ้ํา ซึ่งถาจะใหไมซ้ําก็ตองเอามา combine กับ valid time
53
EMP E# ENAME ADDR DEPT SALARY
Temporal Attribute From date To date

จากรูปไมสามารถ Implement ใน relational database ไดเนื่องจากมี repeating group (แต implement ดวย object relational
database ได) ซึ่งจะตองทําการแยกตารางโดยแยกเฉพาะ attribute ที่เปน temporal attribute ออกมาเปนตารางใหม ตอมาไดมีการ
ออก 6NF สําหรับ Temporal Database ขึ้นโดยมีนิยามคือ
นิยาม
6NF คือ ตารางที่ไมสามารถ Split ไดอีกตอไปแลว ซึ่งเอาไวใชกับ temporal database โดยเฉพาะ
Duplication Concept
Nonsequenced duplicate – เปนกรณี duplicate ปกติซึ่งมอง fromdate และ todate เปน attribute ธรรมดาเชน
Value Equivalent duplicate– duplicate เฉพาะ value โดยไมสนใจเวลาเชน
Current Duplicate – duplicate เฉพาะ value ณ เวลานี้ ตัวอยางเชน

ถาวันนี้เปนวันที่ 1998-01-06 จะไดวา Current duplicate คือ
ซึ่งถาเวลาเปลี่ยนไปก็อาจจะมีการเปลี่ยนแปลงได
Sequenced Duplicate – duplicate ในชวงเวลาใดๆ ก็ได ตัวอยางเชน
หรืออีกตัวอยางคือเคยอยูบานเดียวกันบางแตอาจจะไมจําเปนตองอยูในเวลาเดียวกันก็ได
54
สรุปเปนตารางไดดังนี้
ซึ่งรูปนี้อาจารยบอกวาอาจจะไมถูก
นิยามของ Temporal Database
นิยามที่ 1
Database ที่เก็บขอมูลที่มีการเปลี่ยนแปลงตามเวลา (Time-varying) (นิยามนี้ยังไมถือวาเปนทางการ)
เนื่องจากสิ่งของบางอยางไมมกี ารเปลี่ยนแปลงแตความสามารถในการวัดเปลี่ยนแปลงไปเชนความสูงของยอดเขาเมื่อ 80 ป
ที่แลวกับปจจุบันไมเทากัน, ความสวางของดวงดาว ซึ่งวัดเมือ่ 80 ปกอนกับปจจุบันไมเทากัน
นิยามที่ 2 (เปนทางการ)
Database ที่สนับสนุน แงมุมบางแงมุมของเวลา แตไมนับ user-defined time โดย user-defined time คือ
Date-time ที่เปนสวนหนึ่งของ fact เชนวันเกิด เปนตน
หมายเหตุ
ถาเวลาเปนสวนหนึ่งของ Fact จะไมเรียก temporal database เชนนาย ก เกิดวันที่ xx/xx/xxx แตจะถือเปน
user-defined time แตถาเวลาเปนตัวระบุวา fact นั้น valid ตั้งแตเมื่อไหรถงึ เมื่อไหรจะถือเปน temporal database
เปนเรื่องของปศุสัตวในประเทศสหรัฐ ซึ่งมีอยูชวงหนึ่งมีการตรวจพบวามีเนื้อแชจํานวนหนึ่งติดเชื้อรายแรง จึงตองมีการ
Recall เนื้อแชแข็งเหลานั้น ปญหาคือจะตอง track ใหไดวาเนื้อเหลานี้มาจากโรงฆาสัตวไหน มาจากปศุสัตวฝูงไหน และ track
ตอไปอีกวามีฝงู ไหนบางที่เคยอยูคอกเดียวกับฝูงนี้ แตเนื้องจากไมมี information เหลานี้ทําใหตอง recall เนื้อทั้งประเทศทําใหเกิด
ความเสียหายมาก จึงจําเปนที่จะตองเก็บขอมูลเรื่องเวลาไวดว ย
ลานใหอาหาร หมายเลขฝูง คอก จํานวนสัตว
55
จากตารางเห็นวาฝูง 219 อยูในคอกที่ 1 จํานวน 43 ตัว ตั้งแตวันที่ 1998-02-25 จนถึงสิ้นเดือนกุมภาแตพอถึงเดือนมีนาก็มี
การจับแยกไปอยูคอกที่ 2 จํานวน 23 ตัว จนถึงวันที่ 1998-03-14 ก็เอา 20 ตัวในคอกที่ 1 มารวมกันในคอกที่ 2 จนถึงปจจุบัน
(Q) ฝูง 219 อยูใ นคอกไหนกี่ตัว
(A) คําถามลักษณะนี้จะเรียกวา non-temporal query ซึ่งเปน query ที่ไมเวลาของ fact เขามาเกี่ยวของ นอกจากนี้ยังเปน
Non-sequenced query ซึ่งเปน query ที่ไมสนใจเรื่องของเวลา ซึ่งจะไดวา
ผลลัพธคือ
(Q) ปจจุบันฝูง 219 อยูในคอกไหนกี่ตัว

(A) คําถามลักษณะนี้จะเรียกวา current query ซึ่งเปน query ที่สนใจเฉพาะปจจุบันซึ่งจะไดวา
ผลลัพธคือ เปนตัวระบุวาเปนเวลาปจจุบัน
(Q) ฝูง 219 เคยอยูในคอกไหนมาบาง

(A) คําถามลักษณะนี้จะเรียกวา sequenced query ที่สนใจเรื่องเวลาดวยซึง่ จะไดวา
56
Temporal Join
(Q) ฝูงไหนอยูใ นคอกเดียวกันบาง
(A) ทําไดโดยการ Join ตารางเดียวกันเขาดวยกัน ซึ่งจะไดวา
เหตุผลที่ใช < ก็เพราะตองการไมให

(Q) ณ เวลานี้ฝูงไหนอยูในคอกเดียวกันบาง ผลลัพธออกมาซ้ํา
(A) ซึ่งจะไดวา
(Q) ฝูงไหนเคยอยูในคอกเดียวกันมาบางในชวงเวลาที่แตกตางกัน (ไมจําเปนตองอยูพรอมกันในเวลาเดียวกันก็ได)

(A) คําถามนี้เปน non-sequenced query ซึ่งจะไดวา
(Q) ฝูงไหนเคยอยูในคอกเดียวกัน.ในชวงเวลาเดียวกัน (อดีต, ปจจุบัน, อนาคต)

(A) คําถามนี้เปน sequenced query ซึ่งจะมีได 4 กรณี
1) L2 มาอยูกอ น จากนั้น L1 ตามมาแลวออกไปกอน แลว L2 ออกตามไป
57
2) L2 มาอยูกอ น จากนั้น L1 ตามมา แลว L2 ออกตามดวย L1
3) เหมือนกรณีที่ 1 แต L1 และ L2 สลับกัน

4) เหมือนกรณีที่ 2 แต L1 และ L2 สลับกัน
ดังนั้นจะไดวา
กรณีที่ 1
ดังนั้นการเช็คจะตองเช็คทั้ง 4 กรณีแลวเอามา Union กัน
58
Modifying Valid-Time State Table
ความยากของเรื่องไมไดมีแค Select เทานั้นแตยากที่ modify ดวย
ตัวอยางนี้เปนการตอนวัว ดัง Diagram ขางลางนี้
ลูกวัวตัวผู วัวตัวผู
วัวตัวผูที่ตอนแลว
ลูกวัวตัวเมีย วัวตัวเมีย
วัวตัวเมียที่ตอนแลว
จากตารางจะไดวาฝูง 101 เปน c (calf) ตั้งแต 1998-01-01 ถึง1998-03-23

และ 1998-03-23 ก็ถูกตอนจนถึงปจจุบัน
Insert
ถามีการ Insert Fact ที่เริ่มเปนจริงตั้งแตวันนี้ จะไดวา
Delete
ถามีการ Delete Lot 101 ในปจจุบัน เราไมสามารถที่จะใชวา
ซึ่งเปน Logical delete แตตองใชวา
59
ในเรื่องของการ Update หรือ Delete จะมี 2 มุมมอง
(1) General Scenario
Insert, Update, Delete ไดทุกชวงเวลา
(2) Restricted Scenario
Insert, Update, Delete ไดเฉพาะ Current เทานั้น
Current Delete
จากตารางขางตน
ฝูง Lot 234 เปน Calf ตั้งแต 1998-02-17 และ Plan ที่จะตอนในวันที่ 1998-10-17
สมมุติวาวันนี้เปนวันที่ 29 กรกฎา 1998 ถาเราจะ delete ฝูง 234 ออกจาก row วันนี้จะเกิดอะไรขึ้น
ถาหากวาใหขอมูลในอดีตยังอยู
วิธีคิด
234 row แรกตองแก to-date เปนวันนี้ และลบ row ที่ 4 ทิ้ง
ดังนั้นจะไดวา
สรุปวาการ Delete ปจจุบันนั้นจะตองมองไปถึงอนาคตดวย
60
Current Update
จะตองเช็คในครบทั้ง 3 กรณีคือ
Sequence Insert
ถาจะ Insert Sequence ตองบอกดวยวา valid ตั้งแตเมื่อไหรถึงเมือ่ ไหร
Sequence Delete
ถาจะ Delete จะตองบอกดวยวาจะ delete เมื่อไหรถงึ เมื่อไหร ซึ่งจะมีการ Update ชวงเวลาใหม
ซึ่งจะมี 4 กรณีดังนี้
Update to_date Insert
Update to_date
61
Update from_date
Delete PV
โดย
PV = Period of Validity (ชวงเวลาที่ Fact เดิมเปนจริงอยู)
PA = Period of Application (ชวงเวลาที่จะ Delete)
ตองการ Delete ฝูง 234 ในชวงเวลาตั้งแต 1998-10-01 ถึง 1998-10-22

เราจะตองทําใหครบทั้ง 4 กรณีขางตนจะไดวา
62
Sequence Update
Insert
Update to_date
Insert
Update to_date
Insert
Insert
Update to_date
Update from_date and to_date
63
Temporal SQL (Back in the Pens)
From_date และ to_date ให DBMS ดูแล
Select
(Q) ปจจุบันมีฝูง 219 กี่ตัว
(A) เปน current query
(Q) ในอดีตฝูง 219 เคยอยูคอกไหนกี่ตัว

(A) เปน sequenced query
(Q) ในอดีตฝูง 219 เคยอยูคอกไหน เมื่อไหร กี่ตัว

(A) เปน non-sequenced query
(Q) ปจจุบันฝูงไหนอยูคอกเดียวกันบางในปจจุบัน
(A)
(Q) ฝูงไหนเคยอยูคอกเดียวกันดวยกันบาง
(A) เปน sequenced query
(Q) ฝูงไหนเคยอยูคอกเดียวกันบาง (ไมตองอยูพรอมกันก็ได)

(A) เปน non-sequenced query
(หมายเหตุ Temporal SQL ยังไมถูก implement ใน DBMS ยี่หอใดๆ)
64
Modify
(Q) Insert ฝูง 234 ตั้งแต 1998-03-26 ถึง 1998-04-14
(A) เปน Sequenced insert
(Q) เอาฝูง 234 ออกตั้งแต 1998-10-01 จนถึง 1998-10-22

(A) เปน Sequenced Delete
(R) Update ฝูง 234 เปน s ตั้งแต 1998-03-01 จนถึง 1998-04-01

(B) เปน Sequenced Update
จะเห็นวาใชงานไดงายขึ้นมาก แต DBMS ก็ทํางานหนักขึ้นเยอะ
Transaction-Time State Table

จะเก็บขอมูลที่ไมไดเปลี่ยนแปลงตามเวลา แตขอมูลที่เปลี่ยนแปลงไปนั้นขึ้นอยูกับเครื่องมือหรือความสามารถใน
การวัดคาในขณะนั้น จากตัวอยางขางลางเปนการบันทึกความสวางของดวงดาว
เวลาที่บันทึก
ตําแหนงของดาวบนทองฟา ชื่อดาว ความสวาง
65
Bitemporal Table
มีการเก็บขอมูลทั้งในสวนของ Valid-Time และ Transaction Time
Valid-time
เปนเวลาที่ Fact นั้น valid
Transaction-time
เปนเวลาที่เชื่อวา Fact นั้น valid (เวลาที่มีการบันทึก)
จากตาราง
ดาว A-1248 วัดครั้งแรกเมือ่ 1998-03-12 เราเชื่อวาดาว A-1248 สวาง 12.0 ตั้งแต 1922-05-14
ถึง 9999-12-31 ตอมาเมื่อถึง 1995-11-15 มีการบันทึกใหมและคนพบวามีความสวาง 10.5
66

Lecture 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 2

Uploaded by

Copyright:

Available Formats

สรุปคําบรรยาย

Advanced Database Systems

รศ.ดร. ศุภมิตร จิตตะยโศธร

Temporal Database ........................................................................................53

ทั้ง Partially committed และ Partially

มีการเปลี่ยนจาก Partially committed ไป

ซึ่ง Input และ output นั้นจะเปนการดูแลรวมกันระหวาง OS และ DBMS และอยูนอกเหนือการควบคุมของ application

<Ti commit> Æ Transaction มีการ commit

<Tx start> <Tx start>

จุด Default Check point

(1) Log File

ตัวอยางกรณีที่ตองการอาน B2 เขามาใน DB Buffer ที่เต็ม

DB Buffer Fixed DBMS จัดการ

การทํา Database Buffer ทําตาม Protocol ที่คุยกันไวทั้งหมดเพียงแต DBMS เปนคนจัดการ

DB Space Disk Manager

เปนการยก 1 Device ใหเปน 1 DB Space

Virtual memory ของ OS

DB Space จะเปน File ซึ่ง OS ดูแล

Page Table Page on disk

Shadow Page Table Current Page Table

SAT Vol. SAT Vol. backup Volume Backup

SUN log SUN log achieve

MON log MON log achieve

THU log THU log achieve

FRI log FRI log achieve

ตัวอยาง กรณี Disk crash วันพุธ 11:00

SAT Vol. 2nd Vol. Back 2nd Volume Backup

Parameter เหลานี้จะไปอยูใน DB Space Definition

Schedule 3 การโอนเงินซึ่งเปน Concurrent Schedule ซึ่งผลลัพธเหมือนกัน Schedule 1

(Q) ผลลัพธของ T1 ควรจะเห็น T2 หรือไม

จากรูปเมื่อตองการ Select sum ตาราง DBMS ก็จะปฏิบัติตามขั้นตอนตอไปนี้

1. ทําการ intention share DB space เพื่อใหรวู ามีการ share จริงอยูขางใต

Query = ภาษา SQL ใดๆ

σ balance < 2500

s σ QTY = ' London '

List SNAME ของ London Supplier ที่ Supply P2

ใชในกรณีที่ไมมี Index เปนการทํา Full Table Scan

A5.1 Secondary index, equality on key

A5.2 Secondary index, equality on non-key

ใชสัญลักษณ θ θ = Join Condition ซึ่งไมจําเปนตองเปน เทากับ

S 1 rows ใช SP 10,000 blocks

SP 1 rows ใช S 10 blocks

ดังนั้น จํานวน Disk block = br + (b s × br )

n มากจึงจะดีเพราะวา tree ตนเตี้ย

H(search key) => dataset address

Bucke t2 Overflow Bucket for Bucket 1

จากรูปมีการสราง Bucket เปนดานหนาแลวชี้ไปยัง Data ตริง

Max Value ของ Data Type Date

EMP E# ENAME ADDR DEPT SALARY

Temporal Attribute From date To date

Value Equivalent duplicate– duplicate เฉพาะ value โดยไมสนใจเวลาเชน

Current Duplicate – duplicate เฉพาะ value ณ เวลานี้ ตัวอยางเชน

(Q) ปจจุบันฝูง 219 อยูในคอกไหนกี่ตัว

(Q) ฝูง 219 เคยอยูในคอกไหนมาบาง

เหตุผลที่ใช < ก็เพราะตองการไมให

(Q) ฝูงไหนเคยอยูในคอกเดียวกัน.ในชวงเวลาเดียวกัน (อดีต, ปจจุบัน, อนาคต)

3) เหมือนกรณีที่ 1 แต L1 และ L2 สลับกัน

ดังนั้นการเช็คจะตองเช็คทั้ง 4 กรณีแลวเอามา Union กัน

จากตารางจะไดวาฝูง 101 เปน c (calf) ตั้งแต 1998-01-01 ถึง1998-03-23

ซึ่งเปน Logical delete แตตองใชวา

สรุปวาการ Delete ปจจุบันนั้นจะตองมองไปถึงอนาคตดวย

Update to_date Insert

ตองการ Delete ฝูง 234 ในชวงเวลาตั้งแต 1998-10-01 ถึง 1998-10-22

Update from_date and to_date