การจัดการรายการเปลีย่ นแปลง

Transaction
Management
Transaction คืออะไร
• Transaction คือ หนวยของการทํางานในเชิงตรรกะ
(Logical unit of work:LUW) หนึ่งหนวย ที่กระทํากับ
ฐานขอมูลเพือ่ อานหรือเปลี่ยนสถานะของขอมูล
จากสถานะหนึ่งไปสูอกี สถานะหนึ่ง
• ภายในหนึ่งรายการเปลี่ยนแปลงอาจประกอบดวย
คําสัง่ ในการทํางานเพียงคําสั่งเดียวหรือหลายคําสั่ง
ก็ได
ผลจากการประมวลผลของ Transaction
ผลจากการประมวลผล Transaction สามารถมีได 2 สถานะ
(อยางใดอยางหนึ่ง)
• COMMIT หมายถึง คําสั่งทุกคําสั่งในรายการเปลี่ยนแปลง
ประมวลผลเสร็จสมบูรณทกุ คําสั่ง มีผลทําใหการเปลี่ยนแปลง
คาในฐานขอมูลคงอยูถาวร
• ROLLBACK หมายถึง มีการประมวลผลคําสั่งในรายการ
เปลี่ยนแปลงไมเสร็จสมบูรณ หรือมีเหตุขดั ของซึ่งเปนผลใหการ
ประมวลผลของรายการเปลี่ยนแปลงไมสมบูรณ หรือโปรแกรม
จบการทํางานแบบไมปกติ ทําใหการเปลี่ยนแปลงขอมูลใน
ฐานขอมูลถูกยกเลิก(aborted)และยอนการทํางานกลับไปยัง
จุดเริ่มตนกอนการประมวลผลรายการเปลี่ยนแปลง
ตัวอยาง Transaction
START TRANSACTION
Display greeting
Get account number , pin , type and amount
SELECT account number , type and balance
If balance is sufficient then
UPDATE account by posting debit
UPDATE account by posting credit
INSERT history record
Display final message and issue cash
Else
Write error message
End If
On Error : ROLLBACK
COMMIT
ตัวอยาง Transaction
START TRANSACTION
Display greeting
Get reservation preference
SELECT departure and return flight records
If reservation is acceptable then
UPDATE seats remaining of departure flight record
UPDATE seats remaining of return flight record
INSERT reservation record
Print ticket if requested
End If
On Error : ROLLBACK
COMMIT
ตัวอยาง Transaction
START TRANSACTION
Display greeting
Get order request
SELECT product records
If product is available then
UPDATE QOH of product record
INSERT order record
Send message to shipping department
End If
On Error : ROLLBACK
COMMIT
คุณสมบัติของ Transaction
เรียกยอๆ วา ACID ซึ่งเปนคุณสมบัติที่ DBMS ตองคง
คุณสมบัติทั้งหมดไวใหแกการทํางานของ
Transaction มี 4 คุณสมบัติ ดังนี้
• Atomicity
• Consistency
• Isolation
• Durability
Atomicity
• เมือ่ ผูใชประมวลผลรายการเปลี่ยนแปลงแลว ทุก
การกระทําของรายการเปลี่ยนแปลงตองเสร็จ
สมบูรณทุกคําสั่ง(committed) หรือ ถามีการทํางาน
ใดในรายการเปลี่ยนแปลงไมสมบูรณก็ตองยกเลิก
(aborted)รายการเปลี่ยนแปลงนั้นและยอนกลับการ
ทํางาน(rolled back) เสมือนวาไมเคยประมวลผล
รายการเปลี่ยนแปลงนั้นเลย
Consistency
• การประมวลผล Transaction จะสงผลใหมีการ
เปลีย่ นแปลงสถานะของฐานขอมูล ดังนั้น
Transaction จะตองรักษาความถูกตองของ
ฐานขอมูลที่สอดคลองกับกฎเกณฑตาง ๆ ที่กําหนด
ไว (Integrity Constraints)
• หลังการประมวลผล Transaction เสร็จ ฐานขอมูล
ตองอยูในสถานะที่ถูกตอง(consistent state)
Isolation
• Transaction ที่มีการทํางานพรอมกันในเวลาเดียวกัน
โดยผูใชหลายคน(Multiusers) จะตองไมรบกวนกัน
• หาก T1 และ T2 ทํางานในเวลาใกลเคียงกัน ดังนี้
T1

T2

• คุณสมบัติ Isolation จะถือเสมือนรายการทั้งสอง

ทํางาน ดังนี้
T1 T2
Durability
• Transaction ที่ทําใหเกิดการเปลี่ยนแปลงของขอมูล
ในฐานขอมูล เมื่อ Transaction ทํางานเสร็จสมบูรณ
(committed) ผลจากการเปลี่ยนนั้นจะยังคงอยูถาวร
• เชน การโอนเงินจาก A ไป B ถาทําสําเร็จ ผลที่ได
จะคงอยูถาวร
Transaction Operations
• BEGIN_TRANSACTION : คําสั่งเริ่มการประมวลผลของ
Transaction
• READ หรือ WRITE : เปนคําสั่งที่ใชในการอานหรือเขียน
ขอมูลบนฐานขอมูล
• END_TRANSACTION : เปนคําสั่งที่จบการอานหรือเขียน
ขอมูลในฐานขอมูล ซึ่งในจุดนี้จะมีการตรวจสอบวาการ
ปรับปรุงขอมูลสําเร็จ(committed)หรือถูกยกเลิก(aborted)
เพื่อเตรียมยอนกลับการทํางาน(rollback)
Transaction Operations
• COMMIT_TRANSACTION : เปนคําสั่งที่บอกวาการหาก
ทํางานของ Transaction เสร็จสมบูรณ การเปลี่ยนแปลง
ตาง ๆ ที่กระทํากับฐานขอมูลจะไมสามารถยอนการ
ทํางานกลับ(undone)ได
• ROLLBACK : เปนคําสั่งที่บอกวาหากการทํางานของ
Transaction ไมเสร็จสมบูรณ การเปลี่ยนแปลงตาง ๆ ที่
กระทํากับฐานขอมูลระหวางการทํางานของ Transaction
จะถูกยกเลิกและยอนกลับไปสูสถานะกอนการเริ่ม
ประมวลผล Transaction
Transaction State
เปนสถานะตาง ๆ ระหวางการประมวลผลของ Transaction

Partially Committed
Committed COMMIT

BOT
Active

Failed Aborted ROLLBACK

Transaction State
• Transaction จะเขาสูสถานะ Active state ทันทีหลังจาก Transactionเริ่ม
ทํางาน
• เมื่อ Transaction ทํางานครบทุกคําสัง่ ก็จะเขาสูสถานะ Partially
committed state ณ จุดนี้จะมีการตรวจสอบความสมบรณของ Transaction
• หากการทํางานของ Transaction ไมมีปญหาและเสร็จสมบูรณ ก็จะเขาสู
สถานะ Committed state ซึ่งหมายถึง การเปลีย่ นแปลงตาง ๆ กับ
ฐานขอมูลจะคงอยูถ าวร
• Transaction สามารถที่จะเขาสูสถานะ Failed state ได ถาระหวางการ
ตรวจสอบความสมบูรณของ Transaction ลมเหลว หรือถูกยกเลิกระหวาง
สถานะ Active state
• หลังจากนัน้ จะเขาสูส ถานะ Aborted state เพือ่ ยกเลิกการทํางานทั้งหมด
ของ Transaction
การควบคุมภาวะพรอมกัน
Concurrency
Control
Concurrency Control
• เปนกระบวนการที่ใชในการจัดการ Transaction
หลายๆ Transaction ที่มีความตองการใชงานขอมูล
ชุดเดียวกันในชวงเวลาเดียวกันจากฐานขอมูล เพือ่
นําขอมูลเหลานั้นมาประมวลผลในแตละ
Transaction
 ตัวอยาง Concurrency

Time

1. Read Account Balance

(Balance = 1000)
1. Read Account Balance
(Balance = 1000)
2. Withdraw 200
(Balance = 800)
2. Withdraw 400
(Balance = 600)
3. Write Account Balance
(Balance = 800)
3. Write Account Balance
(Balance = 600)

ERROR!!
ERROR!!
ปญหาจาก Concurrent Transaction
เมื่อ Transaction ถูกประมวลผลพรอมกันโดยไมไดมีการ
ควบคุม มี 3 ประเภท ดังนี้
• ปญหาการสูญเสียจากการปรับปรุงขอมูล (The lost
update problem)
• ปญหาขอมูลที่ยังไมไดรับการยอมรับความสมบูรณ (The
uncommitted dependency problem)
• ปญหาการวิเคราะหผลลัพธที่ขดั แยงกัน (The inconsistent
analysis problem)
The Lost Update Problem
• เกิดขึ้นจากสาเหตุที่ มี รายการเปลี่ยนแปลง 2
รายการ หรือมากกวา มีการเรียกใชขอมูลเดียวกัน
แลวตางฝายตางปรับปรุงคาของขอมูล โดยไมมี
การปองกันการแกไขจากอีกรายการ
 The Lost Update Problem
Time Transaction Transaction Comments
T1 T2
1 read_item(X) T1 อานขอมูล X จากฐานขอมูล
*** สมมุติ x มีคา 100
2 x := x - 40 read_item(x) T1 ปรับปรุงคาในตัวแปร X (x = 60)
T2 อานขอมูล X (ไดรับคา x = 100)
3 write_item(x) X := x + 20 T1 เขียนคา x ลงในฐานขอมูล (x = 60)
T2 ปรับปรุงคาในตัวแปร X ( x = 120)
4 write_item(x) T2 เขียนคา x ลงในฐานขอมูล ( x ใน
ฐานขอมูลมีคา 120)
The Uncommitted Dependency Problem
• เกิดขึ้นจากกรณีที่ รายการเปลี่ยนแปลง 2 รายการ
หรือ มากกวามีการเรียกใชขอมูลเดียวกัน แตมี
รายการเปลี่ยนแปลงหนึ่งที่มกี ารทํางานยังไมเสร็จ
สมบูรณ และเกิดปญหาขึ้น จึงตองมีการยกเลิกทุกการ
กระทํากอนหนาของรายการเปลี่ยนแปลงนั้น สงผลให
ขอมูลที่รายการเปลี่ยนแปลงนั้นเรียกใชกลับไปมีคา
ตามเดิม และทําให รายการเปลี่ยนแปลงอื่นที่เรียกใช
ขอมูลเดียวกันกอนหนาที่จะ ROLLBACK ไดรับขอมูล
ที่ไมถูกตองดวย
 The Uncommitted Dependency Problem
Time Transaction Transaction Comments
T1 T2
1 read_item(X) T2 อานขอมูล X จากฐานขอมูล
*** สมมุติ x มีคา 100
2 x := x - 20 T2 ปรับปรุงคาในตัวแปร X
3 write_item(x) T2 เขียนคา x ลงในฐานขอมูลชั่วคราว
(x = 80)
4 read_item(X) T1 อานคา x ในฐานขอมูล ( ไดรับคา x
เปน 80)
5 ROLLBACK T2 ทํางานลมเหลว ตองยอนคา x กลับ
เปนคาเดิม (x = 100)
 The dirty read
Time Transaction Transaction Comments
T1 T2
1 read_item(X)
2 x := x - 20
3 write_item(x) T2 เขียนคา x ลงในฐานขอมูลชั่วคราว
4 Read_item(x)
5 x := x + 100
6 write_item(x)
7 COMMIT
8 read_item(y)
… …. …
ROLLBACK T1 ขึ้นกับขอมูลทีย่ ังไมสมบูรณและขาดการ
ปรับปรุง
The Inconsistent Analysis Problem
• เกิดขึ้นในกรณีที่ รายการเปลี่ยนแปลง 2 รายการ หรือมากกวา มี
การใชขอมูลเดียวกัน แตมี รายการเปลี่ยนแปลงหนึ่งที่ไดรับขอมูล
ที่อยูในสถานะไมถูกตองไปใชงาน สงผลใหการประมวลผลของ
รายการเปลี่ยนแปลงนั้น มีการประมวลผลที่ผิดพลาด
• พิจารณาบัญชีทั้ง 3 ดังนี้
ACC1 ACC2 ACC3
40 50 30

• ตองการโอนเงิน 10 บาท จากบัญชี ACC3 ไปยัง ACC1 พิจารณา

ลําดับการทํางานดังตอไปนี้
The Inconsistent Analysis Problem
Tim Transaction T1 Transaction T2 Comments
e
Sum = 0
1 read_item(ACC1)
2 sum := sum + ACC1
3 read_item(ACC2)
4 sum := sum + ACC2 ตอนนี้ sum มีคา 90
5 read_item(ACC3)
6 read_item(ACC1)
7 ACC3 := ACC3 - 10
8 ACC1 := ACC1 + 10
9 write_item(ACC3) ตอนนี้ ACC3 มีคา 20
10 write_item(ACC1) ตอนนี้ ACC1 มีคา 50
11 COMMIT
12 read_item(ACC3) T1 ไดรบ
ั คา ACC3 เปน 20
13 sum := sum + ACC3 sum มีคา
 110 ซึ่งไมถูกตอง
 Concurrency Control
Techniques
• เมื่อเกิดภาวะพรอมกัน(Concurrency) DBMS ตองมี
เทคนิคหรือกระบวนการในการจัดเรียงลําดับการทํางาน
ของแตละ Transaction กอนและหลัง
• เพื่อปองกันการแยงชิงขอมูลที่ประมวลผลยังไมเสร็จไปใช
งานโดย Transaction อื่น
 Locking
• เทคนิคการ Lock ขอมูลนี้ เปนเทคนิคที่ใชในการ
กําหนดสถานะการ Lock ใหกับขอมูล เพื่อบงบอก
ถึงสิทธิในการใชงานขอมูลนัน้ แกแตละTransaction
กลาวคือ กอนที่แตละ Transaction จะเรียกใช
ขอมูลใด ๆ จะตองดูสถานะการ Lock ของขอมูล
ณ ขณะนั้นกอนวา มีสถานะที่บงบอกวาขอมูลนัน้
ถูกเรียกใชโดย Transaction อื่นหรือไม กอนทีจ่ ะ
นําขอมูลนัน้ ไปใชงาน
 ตัวอยางการล็อก
อก
Time
1. Request account balance
(Lock account balance)
2. Read Account Balance 1. Request account balance
(Balance = 1000) (denied)
3. Withdraw 200
(Balance = 800)

4. Write Account Balance wait

(Balance = 800)
5. COMMIT
(Unlock account balance)
2. Read Account Balance
(Balance = 1000)
3. Withdraw 400
(Balance = 600)
4. Write Account Balance
(Balance = 600)
5. COMMIT
(Unlock account balance)
 สถานะของการ Lock
• สถานะของการล็อก แบงออกเปน 2 ประเภท
คือ
– Shared Lock
– Exclusive Lock
 Shared Lock (S Lock)
• เปนการ Lock ขอมูลที่สามารถอานขอมูลไดเพียง
อยางเดียว Transaction ไมสามารถเปลี่ยนแปลง
ขอมูลที่ Lock แบบ S Lock
• สมมุติ รายการขอมูล R ถูก Lock แบบ S โดยการ
ทํางานของ Transaction อื่น ๆ แลว Transaction B
อยากขอ Lock แบบ S เพื่ออานขอมูลบนรายการ
R ก็สามารถทําได
 Exclusive Lock (X Lock)
• เปนการ Lock ขอมูลทีส่ ามารถอานและปรับปรุงขอมูล
ได Transaction
• เพื่อเปนการปองกันการแทรกการทํางานจาก
Transaction อืน่ ระบบจึงอนุญาตใหมีเพียง Transaction
เดียวสามารถ Lock ขอมูลแบบ X ได บนขอมูลที่
ตองการใชงาน
• สมมุติ Transaction A ทําการ Lock ขอมูลแบบ X บน
รายการขอมูล R แลว Transaction B จะไมสามารถ Lock
ขอมูลบนรายการ R แบบ X ได จนกวา Transaction A
จะปลดปลอย X Lock จากรายการ R
 Exclusive & Shared Lock
ประเภทของ Lock ประเภทของ Lock ที่ Transaction A ยึดครองบน
บนขอมูล R ที่ ขอมูล R
Transaction B
Exclusive Lock Shared Lock No Lock
ตองการยึดครอง
Exclusive Lock N N Y
Shared Lock N Y Y
No Lock Y Y Y
 การนํา Locking ไปใชกับปญหา
Lost Update Problem
Time Transaction Transaction Comments
T1 T2

1 read_item(X) จะทําการ Lock แบบ S บนขอมูล X กอนที่จะเริ่ม

(ไดรับ S Lock บน X) ประมวลผลคําสั่ง read

2 x := x - 40 read_item(x) ระหวางที่ T1 กําลังปรับปรุงขอมูล X T2 ก็ทําการ

3 write_item(x)
4 wait
(ไดรับ S Lock บน X) Lock แบบ S Lock บนขอมูล X กอนทําการอาน
ขอมูล
X := x + 20 ระหวางที่ T2 กําลังปรับปรุงขอมูล X T1 ก็ตองการ
Lock ขอมูล X แบบ X Lock เพื่อเขียนขอมูลลงใน
ฐานขอมูล แตตองรอจนกวา T2 จะปลอย S Lock
กอน
write_item(x) T2 ตองการ Lock แบบ X Lock เพื่อเขียนขอมูลลง
ในฐานขอมูล แตก็ตองรอจนกวา T1 จะปลอย S
Lock กอน

5 wait wait ทั้งสอง Transaction T1 และ T2 ตางก็รอใหแตละ

ฝายปลอย Lock ที่ยึดครองไว
 การนํา Locking ไปใชกับปญหา
Uncommitted dependency problem
Time Transaction Transaction Comments
T1 T2
1 read_item(X)
(ตองการ S Lock บน X)

2 x := x - 20

3 write_item(x)
(ไดรับ X Lock บน X)
4 read_item(X) T1 ตองการ S Lock บนขอมูล X แตตอง
(ตองการ S Lock บน X) รอจนกวา T2 จะปลอย X Lock กอน

5 wait

n ฟน : read_item(X) Commit

(ปลอย X Lock บนขอมูล X)

n+1 …
 Two-Phase Locking(2PL)
• เปนการล็อกวิธีหนึ่งซึ่งเปนที่นิยม โดยการล็อกแบบ
2PL นั้นไดกําหนดไววา Transaction สามารถมีอยู 2
เฟสดวยกันคือ
– Growing phase(Lock) เปนชวงทีล่ ็อกขอมูลทุกอยางที่
จะตองใชใน Transaction จะสามารถอานขอมูลได แต
ไมสามารถทําการอัปเดตขอมูลได
– Shrinking phase(UnLock) เปนชวงทีป่ ลดปลอยการล็
อกขอมูลทั้งหมดที่ Transaction ล็อกไวใชงาน
 การแกปญ
 หา Lost Update ดวย 2PL
Time Transaction Transaction Comments
T1 T2

1 write_lock(X) T1 ทําการ Lock แบบ X Lock บนขอมูล x

2 read_item(X) write_lock(X) T1 กําลังประมวลผลคําสั่ง read และ T2 ก็

ตองการ Lock ขอมูล X แตตองรอจนกวา T1 จะ
ปลอย X Lock
3 x := x - 40 wait

4 write_item(x) wait มีการปรับปรุงคา X ในฐานขอมูลโดย T1

5 Commit/Unlock(X) wait T1 ปลอย X Lock จากขอมูล X และ T2 ก็ไดรับ

สิทธิในการ Lock ขอมูล X
6 read_item(X) ประมวลผลคําสั่งอานขอมูล โดย T2
(ไดรับ S Lock บน
ขอมูล X)
7 x := x + 20

8 write_item(X)
(ไดรับ X Lock บน
ขอมูล X)
9 Commit / Unlock(X)
 ภาวะติดตาย(Dead Lock)
• ในการล็อคขอมูล ถึงแมจะแกปญหาตาง ทีท่ ําให
เกิดความไมถูกตองของขอมูล แตถาการล็อค
ขอมูลของแตละ Transaction ไมสัมพันธกันแลว
สงผลใหเกิดปญหาที่แตละ Transaction ตางฝาย
ตางล็อคขอมูล จนกระทั่งทั้ง 2 ฝาย ไมสามารถ
ทํางานตอไปได เนื่องจากตองรอใหอีกฝายปลอย
Lock ขอมูลกอน ซึ่งปญหาการล็อคที่เกิดขึ้นแบบ
นี้เรียกวา การล็อคคาง(DeadLock)
 ภาวะติดตาย(Dead Lock)
Time T7 T8
t1 Begin_Transaction
t2 write_lock(balx) Begin_Transaction
t3 read(balx) write_lock(baly)
t4 balx = balx - 10 read(baly)
t5 write(balx) baly = baly + 100
t6 write_lock(baly) write(baly)
t7 WAIT write_lock(balx)
t8 WAIT WAIT
t9 WAIT WAIT
t10 . WAIT
. .
. .
.
 ภาวะติดตาย(Dead Lock)
• ภาวะติดตายสามารถแกไขไดโดย การสละ Transaction
หนึ่งดวยการปลดล็อก Transaction ใด Transaction หนึ่ง
ออกจากวงจร Dead Lock เพื่อให Transaction อื่นๆ
สามารถใชงานขอมูลที่ถูกล็อกได
• อาจใช Algorithmวิธีใดวิธหี นึ่งในการกําจัด Dead Lock
เชน วิธี Wait-Die หรือ Wound-Die
• โดย Transaction ที่ถูกกําจัดออกไปจะถูกนํามาเริ่มตน
ประมวลผลใหมอีกครั้ง
 ระดับการล็อก
อก(Locking Level)
• รูปแบบของการล็อกขอมูลใน DBMS จะมีอยูหลาย
ระดับใหเลือกใชงานตามความเหมาะสม หรือตาม
ลักษณะงาน
• แบงระดับการล็อกเปนดังนี้
– การล็อกฐานขอมูล(Database Locking)
– การล็อกตาราง(Table Locking)
– การล็อกเรคอรด(Record Locking)
– การล็อกฟลด(Field Locking)
 Database Locking
• เปนการล็อกทัง้ ฐานขอมูล
• เหมาะสมกับการประมวลผลแบบแบตซ(batch processing)
• ในขณะที่ทาํ การประมวลผลอยู ฐานขอมูลทั้งระบบจะถูกล็
อกไมใครคนอืน่ สามารถใชงานไดเลย จนกวาจะปลดล็อก
• เชน การสํารอขอมูล โดยระหวางทีส่ ํารองขอมูลอยูน นั้
ฐานขอมูลจะถูกล็อกไวไมใหใครเขามาใชงาน จนกวาจะ
สํารองขอมูลเสร็จสิน้ แลวจึงปลดล็อก
 Table Locking
• เปนการล็อกรีเลชัน โดยทําการล็อกตารางใดตารางหนึ่งที่
ตองการ สางผลใหผูใชคนอื่น ๆ ไมสามารถอานขอมูล
หรือปรับปรุงขอมูลในตารางนั้นได จนกวาจะมีการปลดล็
อกตารางนั้น
• เหมาะสมกับงานที่ตอ งมีการปรับปรุงขอมูลทั้งตาราง
 Record Locking
• เปนการล็อกขอมูลบางแถวในตาราง ซึ่งแถวขอมูลที่ถูกล็
อกอยูนั้นทําใหผูใชคนอื่นไมสามารถใชขอมูลในแถวนัน้
ได จนกวาแถวขอมูลนั้นจะถูกปลดล็อก
• เหมาะสมกับงานที่ตอ งการปรับปรุงขอมูลบางแถว เชน
ตองการเปลี่ยนแปลงที่อยูของพนักงาน ก็จะล็อกเฉพาะ
แถวขอมูลของพนักงานทีต่ องการเทานั้น ซึ่งในขณะที่ล็
อกแถวขอมูลอยูนั้น ผูใชคนอื่นก็จะไมสามารถใชงาน
ขอมูลแถวนั้นไดชั่วขณะ จนกวาแถวขอมูลจะถูกปลดล็อก
 Field Locking
• เปนการล็อกฟลด/แอตทริบิวต/คอลัมนขอมูลที่มักถูกใช
งานหรือปรับปรุงขอมูลบอย ๆ
• โดยในขณะที่ล็อกฟลดขอมูลอยูนั้น ผูใชคนอื่นสามารถใช
งานขอมูลได ยกเวนขอมูลในฟลดที่ถกู ล็อก
การสํารองและกูคืนขอมูล
Backup
&

Recovery
 การกูคนื ฐานขอมูล(Database Recovery)
• เปนกระบวนการเรียกคืนฐานขอมูลใหกลับสูภาวะเดิมที่
สามารถใชงานได ในกรณีที่เกิดเหตุขัดของบางประการใน
ระหวางการประมวลผล
• ประเภทของการเหตุขัดของที่เกิดกกับฐานขอมูล ไดแก
– System Failure หรือ Soft crash เชน ระบบไฟฟาขัดของทําให
เซิรฟเวอรทํางานไมได เหตุที่เกิดจากหนวยความจํา
– Media Failure หรือ Hard crash เชน แฟมถูกลบ สื่อบันทึก
ขอมูลเกิดความเสียหายเชน ฮารดดิสกพัง เปนตน
 กระบวนการกูคืนขอมูล
• กระบวนการกูคืนขอมูลที่ใช จะขึ้นอยูกับชนิดของ
เหตุขัดของ
• เชนการกูคืนขอมูลที่เกิดจาก Hard crash ทําไดงาย
แตใชเวลานาน ดังนี้
– ฐานขอมูลจะถูกนํามาบันทึกใหมจากการสํารองขอมูล
ครั้งลาสุด
 Transaction Log
• Transaction Log คือ ตารางขอมูลที่มีการจัดเก็บ
ประวัติการเปลี่ยนแปลงขอมูลในฐานขอมูล
บางครั้งเรียกวา Journal ในการกูค ืนขอมูลของ
ฐานขอมูล ตัวจัดการการกูค นื (Recovery manager)
ที่อยูในระบบการจัดการฐานขอมูลจะใชขอมูลใน
Transaction Log ชวยในการกูค นื ขอมูล
 Transaction Log
• โดยทั่วไปในตาราง Log จะมีการจัดเก็บขอมูลดังนี้
– ลําดับหมายเลขรายการ(Log Sequence Number : LSN)
– หมายเลขรายการเปลี่ยนแปลง(Transaction Identifier)
– การกระทํา(Action)
– เวลา(Time)
– ตารางขอมูลที่มีการเปลี่ยนแปลง(Table)
– รายการขอมูลที่มีการเปลี่ยนแปลง(Record)
– ชื่อฟลด(Column)
– คาขอมูลทั้งเกา(Old value) บางครั้งเรียกวา Before Image
– คาขอมูลทั้งใหม(New value) บางครั้งเรียกวา After Image
 Transaction Log
• ในกรณีมีการเพิ่มขอมูลในฐานขอมูลทุกฟลด จะใช
เครื่องหมาย * และคาขอมูล จะระบุหมายเลขรายการใน
ชองขอมูลใหมเทานั้น สวนในกรณีมีการลบขอมูล ก็จะ
บันทึกเฉพาะขอมูลเกาในชองคาขอมูล
• เมื่อระบบเกิดความขัดของขึ้นระบบการจัดการฐานขอมูล
จะดึงขอมูลจาก Transaction Log ขึ้นมาชวยในการกูคืน
ขอมูล
 ตัวอยาง Transaction Log File
LSN TransNo Action Time Table Row Column Old New

1 101001 START 10:29

2 101001 UPDATE 10:30 Acct 10001 AcctBal 100 200

3 101001 UPDATE 10:30 Acct 15147 AcctBal 500 400

4 101001 INSERT 10:32 Hist 25045 * <1002 ,

500,…>

5 101001 COMMIT 10:33

การกูขอ มูลโดยใชจุดตรวจสอบ(Checkpoint)
• การกูค ืนขอมูลที่เกิดจากเหตุขดั ของแบบ System Failure
หรือ Soft crash จะกําหนดใหมจี ดุ ตรวจสอบ(Check Point)
เพื่อใชตรวจสอบการทํางานของรายการเปลีย่ นแปลง
• ซึ่งจะใชหลักการของ Transaction Log โดยการกําหนด
จุดเริ่มตนของรายการเปลีย่ นแปลงทีเ่ ริ่มบันทึกรายการลงใน
Journal ทีเ่ รียกวาจุด Checkpoint ไว
• ดังนั้น หากมีรายการเปลี่ยนแปลงใดทํางานไมสมบูรณ ก็ให
นําขอมูลใน Journal ตั้งแตจดุ Checkpoint ทีก่ ําหนดมา
ประมวลผลใหม โดยไมจาํ เปนตองเอาทุกรายการใน Journal
มาประมวลผลใหม
การกูขอ มูลโดยใชจุดตรวจสอบ(Checkpoint)
tc tf
T T1
R
A T2
N
S T3
A
C T4
T
I
O T5
N
S
Checkpoint System Failure
(Time tc) (Time tf)
 การกูขอ มูลโดยใชจุดตรวจสอบ(Checkpoint)
• รายละเอียดการทํางาน
• T1 : เปนทรานแซคชันที่เกิดขึ้นและเสร็จกอนที่จะถึงจุดตรวจสอบเมื่อระบบ
เกิดความขัดของ ระบบจัดการฐานขอมูลไมตองทํารายการนีใ้ หม
• T2 : เปนรายการทีเ่ ริ่มกอนจะถึงเวลาจุดตรวจสอบ แตทํางานเสร็จหลังจาก
ผานจุดตรวจสอบไปแลว เมื่อระบบเกิดความผิดพลาดและมีการกูร ะบบ
ระบบจัดการฐานขอมูลจะตองทํารายการนีใ้ หม เฉพาะสวนทีอ่ ยูห ลังจุด
ตรวจสอบ
• T3 : เปนรายการทีเ่ ริ่มทํางานหลังจุดตรวจสอบ และทํางานยังไมเสร็จก็เกิด
ความผิดพลาดของระบบขึ้นกอนที่จะทํางานเสร็จ ระบบจัดการฐานขอมูลจะ
ยกเลิกรายการนีท้ ั้งหมด จนถึงกอนจุดตรวจสอบ
• T4 : เปนรายการทีเ่ ริ่มหลังจุดตรวจสอบและทํางานเสร็จกอนถึงจุดทีร่ ะบบ
เกิดความผิดพลาด ระบบจัดการฐานขอมูลจะตองนํารายการนี้กลับมาทําใหม
ทั้งหมด
• T5 : เปนรายการทีเ่ ริ่มทํางานหลังจดตรวจสอบ แตทํายังไมเสร็จระบบก็เกิด
 การกูขอ มูลโดยใชจุดตรวจสอบ(Checkpoint)
การพิจารณาการกู Transaction
1. สรางชุดรายการของทรานแซคชัน คือ UNDO List และ REDO List โดยกําหนดให
UNDO List เก็บทรานแซคชันทั้งหมด ที่เกิดขึ้นระหวางชวงเวลา จากจุดตรวจสอบถึง
เวลาที่ระบบเกิดความขัดของ ทั้งหมดไวใน UNDO List สวน REDO List จะเปนคา
วาง
2. ตรวจสอบขอมูลใน Log file ที่เกิดขึ้น ณ ชวงเวลา จากจุดตรวจสอบ ถึง จุดที่เกิด
ความขัดของของระบบ
3. ถาพบรายการกําลังทํางานอยูใหบนั ทึกลงใน UNDO List
4. ถาพบรายการใดที่ COMMIT กอนเกิดความขัดของ ใหยายรายการนั้นไปไวใน
REDO List
เมื่อสิ้นสุดการประมวลผล จะพบวาใน UNDO List ประกอบดวยทรานแซคชัน T3 และ
T5 ใหยกเลิกการทํางานของทรานแซคชันนั้นโดยการยอนกลับการทํางานกลับสูคา
เริ่มตน สวนใน REDO List ประกอบดวย ทรานแซคชัน T2 และ T4 ใหนําทราน
แซคชันที่อยูใน REDO List มาประมวลผลใหม