đề thi quản trị cơ sở dữ liệu phân tán 11

CHƯƠNG V: PHỤC HỒI SỰ CỐ (số tiết 5 )
(sự cố trong csdlptan/ Dự phòng lỗi (sao lưu)/các giải pháp

5.1 Sự cố trong CSDL phân tán
1/ Hoạt động
PHÂN LOẠI VÙNG NHỚ
- Vùng nhớ Volatile:
 Không còn sau khi sập hệ thống.
 VD: bộ nhớ chính, bộ nhớ cache
- Vùng nhớ Nonvolatile:
 Còn sau khi sập hệ thống.
 VD: disk, tape, flash memory, non-volatile (dùng pin) RAM
- Vùng nhớ ổn định:
 Dạng đặc biệt của vùng nhớ, vẫn còn giữ dữ liệu sau mọi sự cố.
 Gần với việc duy trì nhiều bán sao trên phương tiện nonvolatile khác nhau.
THỰC HIỆN TRÊN VÙNG NHỚ ỔN ĐỊNH
- Duy trì nhiều bản sao của mỗi khối trên các đĩa riêng rẽ.
 Các bản sao có thể ở các site xa bảo vệ chống thảm họa như cháy, ngập.
- Sự cố trong truyền dữ liệu có thể vẫn có các dữ liệu không nhất quán: Chuyển khối có thể
là:
 Thành công hoàn toàn.
 Sự cố riêng phần: khối đích có thông tin không đúng.
 Sự cố tổng thể: Khối đích không bao giờ được cập nhật
- Bảo vệ vùng nhớ phương tiện tránh sự cố khi truyền dữ liệu(1 giải pháp):
 Vận hành thao tác output như sau(giả thiết mỗi khối có 2 bản sao):
1. Viết thông tin lên khối vật lý đầu tiên.
2. Khi việc viết khối đầu đã thành công, viết cùng thông tin lên khối vật lý
thứ hai.
3. Việc output được hoàn tất chỉ sau việc hoàn tất viết thứ hai
TRUY NHAP Dữ LIệU
Các khối vật ly là các khối trên đĩa.

Các khối bộ đệm là các khối tạm thời nằm trong bộ nhớ chính.
Việc chuyển các khối giữa đĩa và bộ nhớ chính được khởi tạo qua 2 bước sau:

 input(B) chuyển khối vật lý B vào bộ nhớ chính.
 output(B) Chuyển khối bộ đệm B vào đĩa và thay thế khối vật lý tương ứng ở đây.
Mỗi giao dịch Ti có vùng làm việc riêng, trong đó giữ các bản sao của mọi hạng mục dữ liệu được
truy nhập và cập nhật bởi nó


 Bản sao cục bộ của Ti hạng mục dữ liệu X là xi.
Để đơn giản ta giả thiết mỗi hạng mục dữ liệu là phù hợp và được lưu trong một khối đơn.
Giao dịch chuyển các hạng mục dữ liệu giữa các khối bộ đệm hệ thống và vùng làm việc riêng dùng
các thao tác sau:

 read(X) gán giá trị của hạng mục X cho biến cục bộ xi.
 write(X) gán giá trị của biến cục bộ xi cho hạng mục dữ liệu {X} trong khôi bộ
đệm.
 Cả 2 lệnh này có thể cần công bố một chỉ thị input(Bx) trước khi gán nếu khối BX
trong X không có sẵn trong bộ nhớ.
Các giao dịch

 Thực hiện read(X) trong khi truy nhập X cho lần đầu tiên
 Mọi truy nhập tiếp theo là đối với bản sao cục bộ.
 Sau truy nhập cuối cùng, giao dịch vận hành write(X).
output(BX) không cần theo ngay sau write(X). Hệ thống có thể thực hiện thao tác output khi thấy
phù hợp.

MINH HOẠ TRUY NHẬP DỮ LIỆU

2/Các sư cố

CÁC ĐịNH NGHĨA CƠ BẢN


-

Failure: Sự chuyển hướng một hệ thống khỏi mô tả đã đặc tả của nó
Erronous State: Trạng thái của hệ thống trong đó tồn tại các hoàn cảnh việc xử lý hơn
nữa theo thuật toán thông thường dẫn đến sự cố không định trước.
Errors: Một phần trạng thái làm việc không đúng
Faults: Lỗi trạng thái nội tại của các thành phần hệ thống hay thiết kê hệ thống.

Fault to Failure

CÁC NGUYÊN NHÂN LỖI (CAUSE OF DOWNTIME): Có thể có 2 kiểu (Bất thường và có kế
hoạch)

•
•
•
•
•
•
•
•
•

Unplanned downtime (Hỏng hóc/Con người/Thảm họa)
Corruptions
Logical corruptions
Physical corruptions

Human Errors
Accidentally drops, truncates a table
Accidentally delete, update rows in a table
Accidentally delete a data file or drop a tablespace
Disasters
War, terrorism
Earthquake, flood, fire or hurricane
No power for a long period
Server crush, malfunction of hardware
Planned downtime (bảo trì: SAO LƯU/nâng cấp/btri dữ liệu )
Database Maintenance
Backup
Upgrade/Patching
Operating System Maintenance
Upgrade/Patching
Periodic reboot server
Hardware Maintenance
Adding memory and CPUs
Replacing parts
Network Maintenance


CÁC KIỂU SỰ CỐ
Sự cố giao dịch.
Giao dịch không thể hoàn tất do điều kiện lỗi bên trong nào đó. Thoát các giao dịch(đơn phương
hay do khóa chết )
Trung bình 3% của các giao dịch thoat bất thường
Các sự cố hệ thống(site)
Sự cố bộ xử lý, bộ nhớ chính, ngồn cấp
Nội dung bộ nhớ chính mất, nhưng vẫn còn trên bộ nhớ thứ câp

Sự cố riêng và tổng thể
Sự cố phương tiện
Sự cố thiết bị vùng nhớ thứ cấp(dữ liệu được lưu) mất
Hỏng đầu(head crash)/sự cố bộ điều khiển.
Sự cố truyền thông
Mất/không trao đổi được các thông điệp.
Mạng bị phân chia

MÔ HÌNH SỰ CỐ

Sự kiện -> Yêu cầu
Không yêu cầu -> Chờ đợi
Không chờ đợi
Các sự kiện chờ đợi: xem các tài liệu sản phẩm
Các sự kiện không chờ đợi:
Hệ thống sự cố
• Mất bộ nhớ
• Dừng CPU, thiết lập lại
Có nghĩa là : mọi vấn đề còn lại!
VD:
• Dữ liệu đĩa mất


•
•

Bộ nhớ mất không có dừng CPU
CPU sập quét toàn bộ ( implodes-đổ sụp- wiping out universe.)

Mô hình này có phù hợp trong môi trường CSDL phân tán ?

Cách tiếp cận:
Bổ sung các kiểm tra mức thấp+ dư thừa để tăng mô hình xác suất giữ tin cậy.
VD: Nhân bản bộ nhớ đĩa (bộ nhớ ổn định)+ parity bộ nhớ + kiểm tra CPU
Thực hiện Phân cấp bộ nhớ

Các thao tác
•
•
•
•

Input(x) : khối với x -> bộ nhớ
Output(x): khối với x-> đĩa
Read(x,t): thực hiện input(x) nếu cần t nhận giá trị của x trong khối
Write(x,t): thực hiện input(x) nếu cần giá trị của x trong khối nhận t

Vấn đề cơ bản: giao dịch không kết thúc
VD Ràng buộc: A=B
T1: A <- A x 2
B <- B x 2
T1: Read(A,t); t<- t x 2
Write (A,t);
Read(B,t); t<- t x 2
Write (B,t);
Output(A);
Sự cố
Output(B);

•

Cần tính nguyên tử: Hoặc vân hành mọi hoạt động giao dịch hoặc không gì cả


•

Một giải pháp: nhật ký undo(biến đổi trung gian)

T1: Read(A,t); t<- t x 2
Write (A,t);
Read(B,t); t<- t x 2
Write (B,t);
Output(A);
Output(B);

A=B

Một “sự phức tạp”
• Nhật ký được ghi đầu tiên vào bộ nhớ
• Không được ghi vào đĩa trên mỗi hoạt động
 Nhật ký luôn bám sát giá trị thay đổi đúng

Phần này trình bày sau


3/Đo lường

MTBF: Mean time between failures
MTTD: Mean time to Detect
MTTR: Mean time to repair

Đo lường dung sai lỗi


- Độ tin cậy
• Mô tả sự thành công của 1 hệ thống tuân thủ(conform) đặc tả chính
thức(authortative) nào đó các hành vi của nó
• Xác suất mà hệ thống không sự cố trong một thời gian cho trước
• Thường dùng để mô tả hệ thống không bị sửa chữa hay thao tác làm việc găng ở
đâu
- Tính sẵn sàng
• Phần thời gian mà hệ thống gặp đặc tả của nó
• Xác suất hệ thống làm việc trong thời gian t đã cho

ĐO LƯỜNG HIGH AVAILABILITY MEASUREMENTS
Có 3 độ đo cho độ sẵn sàng cao:
• The mean time to recovery (mttr) THỜI GIAN ĐỂ PHỤC HỒI.
Đo lường Thời gian trung bình để khôi phục/nạp 1 hệ thống sau mỗi sự cố.
• The mean time between failures (mtbf) THờI GIAN GIỮA CÁC Sự Cố
Đo lường tần suất xuất hiện sự cố hệ thống. Nó nói chung được áp dụng nhiều hơn cho
độ đo sẵn sàng phần cứng .
• Total Uptime In a Year (%) THờI GIAN LÀM VIỆC TRONG MỘT NĂM
Đo lường phần trăm thời gian làm việc trên thời gian có sẵn trong năm. Bảng cho thấy
thời gian làm việc của hệ thống từ 5 phút đén 2 ngày không làm việc. T_up cang lớn càng
tốt.
t_up/t_year=t_up/(t_up+t_down).


Minutes of Downtime
Minutes of Uptime

Minutes in a Year
Total Uptime in a Year (%)

5
525595
525600
99.9990%

60
525540
525600
99.9886%

1440
524160
525600
99.7260%

2880
522720
525600
99.4521%

5.2 Dự phòng lỗi
Nhân bản(Replication)
-

Một trong những cơ chế hiệu quả nhất trong csdl phân tán.
Tăng cường
o Tính sẵn sàng

 Nếu 1 site nhân bản bị down, dữ liệu có thể được truy nhập từ site khác
o Hiệu năng
 Truy vấn có thể vận hành hiệu quả hơn vì chúng có thể truy nhập cục bộ hay các
ban sao ở gần
 Cập nhật chậm hơn vì mọi bản sao phải được cập nhật.

n Cac bản sao có thể khác nhau do sự cố trong thao tác output. Để phục hồi từ sự cố:
- Trước hết tìm các khối không nhất quán
o Giải pháp tốn kém: so sánh 2 bản sao của mọi khối đĩa
o Better solution: (bám vết tiến trình)
 Đĩa bản ghi trong quá trình ghi lên vùng nhớ Nonvolatile .
 Sử dụng thông tin này trong quá trình phục hồi để tìm các khối có thể
không nhất quán và chỉ so sánh các khối này.
 Được sử dụng trong các hệ thống RAID.
- Nếu bản sao một khói không nhất quán có lỗi(checksum) được đè lên bởi bản sao kia.
Nếu cả hai không lỗi nhưng khác nhau thì lấy khối trước đè khối thứ hai

PHụC HồI VA NGUYÊN Tử
- Việc thay đổi csdl không có sự đảm bảo giao dịch sẽ chuyển giao có thể dẫn đến trạng
thái csdl không nhất quán.
- Xem một giao dịch Ti chuyển $50 từ tài khoản A sang tài khoản B; mục đích là hoặc thực
hiện mọi thay đổi csdl bới Ti hoặc không làm gì cả
- Một vài thao tác output có thể yêu cầu với Ti(đưa ra A và B). Một sự cố có thể xuất hiện
sau khi thay đổi A mà chưa thay đổi B.


-

-

Để đảm bảo tính nguyên tử dù có các sự cố, đầu tiên chúng ta đưa ra các thông tin mô tả
sự thay đổi vào vùng nhớ ổn định mà không thay đổi chính csdl.
Ta nghiên cứu 2 cách tiếp cận:
o Phục hồi dựa trên nhật ký, và
o Trang shadow
Ta cũng giả thiết rằng giao dịch chay nối tiếp cái này sau cái kia.

TRONG ORACLE - CÁC CÔNG CỤ QUẢN TRỊ CHO MÔI TRƯỜNG NHÂN BẢN (ADMINISTRATION
TOOLS FOR REPLICATION ENVIRONMENT (3) LÀ:
ORACLE ENTERPRISE MANAGER: quy mô lớn/
REPLICATION MANAGEMENT API : Tập các lệnh PL/SQL dùng môi trường Advanced
Replication environment./
REPLICATION CATALOG: chứa thông tin quản trị về lặp lại các đtượng, các nhóm trong môi
trường lặp

2/ Sao lưu
Giới thiệu: Sao lưu và phục hồi sự cố tạo nên sự bảo vệ CSDL chống sự mất dữ liệu , tái cấu
trúc dữ liệu . Đạt được thông qua các phương tiện phục hồi nhiều tao tác liên quan đến , rolling
forward, và rolling back một sao lưu file CSDL
Backup: sao chép dữ liệu . Bản sao có thể bao gồm những phần quan trọng của CSDL như file
điều khiển và file dữ liệu.. Có thể có 2 loại: physical backups và logical backups.
 Physical backups: copy các file CSDL vật lý. Có thể dùng tiện ích Recovery Manager
(RMAN)
 Logical backups: chứa các dữ liệu logic (VD, tables và stored procedures) lấy với một
tiện ích Oracle và lưu dạng file nhị phân, hỗ trợ physical backups.
•

•

•

Chiến lược sao lưu có thể bao gồm:
– Toàn bộ csdl (whole)
– Một phần csdl (partial)
Các kiểu sao lưu có thể chỉ ra bao gồm :
– Toàn bộ thông tin từ toàn bộ các file dữ liệu (full)
– Chỉ những thông tin đã thay đổi kể từ những lần sao lưu trước
(incremental)
Các chế độ sao lưu có thể


– Offline (consistent, cold)
– Online (inconsistent, hot)
Việc sao lưu có thể được lưu như:
-

Các bản sao ảnh ( mọi dữ liệu của các file)
Các tập hợp sao lưu (tập hợp logic các file thành các piece có cấu trúc mà chỉ
RMAN xử lý được . Có 2 loai backup set :
• cho dữ liệu và điều khiển- có thể dùng nén và
* cho các nhật ký(không nén)

Data file #1

Data file #2

Data file #3

Data file #4

Data file #5

Data file #6

Sao lưu nhất quán và không nhất quán
consistent backup: file được sao lưu chứa toàn bộ sự thay đổi của cùng số thay đổi hệ thống
system change number (SCN).
inconsistent backup: : sao lưu một hay nhiều file CSDLđược thực hiện khi file mở hay đóng bất
thường (không tốt)?
Tổng quan Consistent Backups
A consistent backup of a database or part of a database is a backup in which all read/write
datafiles and control files are checkpointed with the same SCN.


The only way to make a consistent whole database backup is to shut down the database with the
NORMAL, IMMEDIATE, or TRANSACTIONAL options and make the backup while the
database is closed. If a database is not shut down cleanly, for example, an instance fails or you
issue a SHUTDOWN ABORT statement, then the database's datafiles are always inconsistent—
unless the database is a read-only database.
Oracle makes the control files and datafiles consistent to the same SCN during a database
checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are
read-only and offline normal tablespaces, which are still consistent with the other datafiles in the
backup because no changes have been made to them.
The important point is that you can open the database after restoring a consistent whole database
backup without needing recovery because the data is already consistent: no action is required to
make the data in the restored datafiles correct. Hence, you can restore a year-old consistent
backup of your database without performing media recovery and without Oracle performing
instance recovery. Of course, when you restore a consistent whole database backup without
applying redo, you lose all transactions that were made since the backup was taken.
A consistent whole database backup is the only valid backup option for databases operating in

NOARCHIVELOG mode, because otherwise recovery is necessary for consistency. In
NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs
might not exist on disk. A consistent whole backup is also a valid backup option for databases
operating in ARCHIVELOG mode. When this type of backup is restored and archived logs are
available, you have the option of either opening the database immediately and losing transactions
that were made since the backup was taken, or applying the archived logs to recover those
transactions.
Tổng quan Inconsistent Backups
Không chứa toàn bộ sự thay đổi ở mọi SCNs (một vài thay đổi có thể mất). Khi khôi phục đọc
mọi logs redo online và archived với SCN sớm nhất(?)trong bất kỳ datafile headers file dữ liệu
và áp dụng những thay đổi này và các data file.
Nếu 24/7(online backup) và chạy CSDL trong chế độ ARCHIVELOG mode. Nếu vậy không cần
backup toàn bộ CSDL tại một thời điểm
Oracle khuyến cáo không chạy inconsistent, backup CSDL được đóng trong NOARCHIVELOG
mode. Sẽ mất CSDL


Các khái niệm Archiving/ Unarchived Redo Log Files/ Backing Up the Archived Logs and the
Control File

Sao lưu toàn phần và riêng phần CSDL( Whole Database and Partial Database
Backups)
Sao lưu toàn bộ dữ liệu-Whole Database Backups
A whole database backup sao lưu mọi file dữ liệu trong CSDL và các file điều khiển. Kiểu chung
của sao lưu. Có thể là ARCHIVELOG / NOARCHIVELOG. Cần lưu ý trước sao lưu
Figure 15-1 illustrates the valid configuration options given the type of backup that is performed.
Figure 15-1 Whole Database Backup Options

Description of "Figure 15-1 Whole Database Backup Options"
Cũng có thể sao lưu consistent backup / inconsistent backup.

Sao lưu không gian bảng hay file dữ liệu/điều khiển.
Sao lưu không gian bảng-Tablespace Backups
Sao lưu các file chứa tablespace. Có thể online/ offline, chỉ hợp lệ khi lam việc ARCHIVELOG
mode do redo yêu cầu phục hồi tablespace chứa các tablespaces trong CSDL.
Sao lưu các file dữ liệu-Datafile Backups
datafile backup là sao lưu một file dữ liệu đơn. Không chung như tablespace backups là hợp lệ
trong CSDL ARCHIVELOG . Chỉ hợp lệ trong NOARCHIVELOG mode khi :


•
•

Mọi file dữ liệu được backup .Không thể khôi phục nêu các file CSDL chưa backup
Các datafiles là read only /hay offline-normal.

5.3 Các giải pháp

5.3.1. Phục hồi
Các vấn đề khi phục hồi

CÁC GIAO THỨC TIN CẬY PHÂN TÁN.
-

-

-

Các giao thức chuyển giao
• Xác định các lệnh chuyển giao cho các giao dịch phân tán như thế nào

• Công bố: Đảm bảo tính nguyên tử và bền vứng như thế nào?
Các giao thức kết thúc
• Nếu sự cố xuất hiện, làm sao có thể duy trì các site liên quan làm việc bình
thường
• Non-blocking: Sự xuất hiện sự cố không nên buộc các site chờ cho tới khi sự cố
được sửa để kết thúc giao dịch.
Các giao thức phục hồi
• Khi sự cố xuất hiện, các site ở đó làm việc thế nào?
o Bộ phối hợp có thể sự cố trong trạng thái khởi tạo, Chờ hay Quyết định.
o Các tham gia có thể sự cố trong trạng thái Initial, Prepared, Aborted/Committed
•

-

Independent: site sự cố có thể xác định đầu ra của 1 giao dịch mà không cần
giành được thông tin ở xa.
Phục hồi độc lập=> kết thúc không khóa(non-blocking)

CAC GIAI THUAT PHụC HồI
- Các giải thuật phục hồi là cac kỹ thuật đảm bảo tính nhất quán dữ liệu và tính nguyên tử
và bền vững của giao dịch dù có sự cố
- Các giải thuật phục hồi sự cố có 2 phần:
 Các hoạt động được lấy trong xử lý giao dịch thông thường để đảm bảo sự tồn tại
thông tin đầy đủ để phục hồi.
 Các hoạt động được lấy sau sự cố đẻ phục hồi nội dung csdl đến trạng thái đảm
bảo tính nguyên tử, nhất quán và bền vững


5.3.2. Nhật ký
Lập nhật ký

Nhật ký chứa các thông tin được dùng bởi tiến trình khôi phục nhằm nạp lại tính nhất quán của
một hệ thống. Thông tin này bao gồm:

Định danh giao dịch

Kiểu thao tác(hoạt động)

Các hạng mục được truy nhập bởi giao dịch để thực hiện hoạt động

Giá trị(trạng thái) cũ của hạng mục (ảnh trước)

Giá trị(trạng thái) mới của hạng mục (ảnh sau)
Tại sao lập nhật ký?
Khi phục hồi:
 Mọi ảnh hưởng của T1 nên được phản ánh trong csdl (REDO nếu cần do sự cố)
 Không một ảnh hưởng của T2 được phản ánh trong csdl (UNDO nếu cần)

Giao thức REDO
• REDO một hoạt động có nghĩa là thực hiện nó lại một lần nữa
• thao tác REDO sử dụng thông tin nhật ký và thực hiện hoạt động mà hoạt động
phải được thực hiện trước hay không làm do sự cố.
• thao tác REDO phát sinh hình ảnh mới


Giao thức UNDO:
• UNDO một hoạt động có nghĩa là nạp lại đối tượng đến hnhf ảnh trước của nó
• Thao tác UNDO sử dụng thông tin nhật ký và nạp lai giá trị cũ của đối tượng

KHi nào thì ghi các bản ghi nhật ký vào vùng nhớ ổn định?
Giả thiết 1 giao dịch T cập nhật một trang P

• Trường hợp may mắn
o Hệ thống viết P vào csdl ổn định
o Hệ thống cập nhật nhật ký ổn định cho việc cập nhật này
o Sự Cố Hệ THốNG XUấT HIệN...(trước khi T COMMIT)
Chúng ta có thể phục hồi(undo) bằng cách nạp lại P đến trạng thái cũ nhờ dùng nhật ký.
• Trường hợp không may mắn
o Hệ thống viết P vào csdl ổn định
o Sự Cố Hệ THốNG XUấT HIệN...(trước khi nhật ký ổn định được cập
nhật)
Chúng ta không thể phục hồi sự cố này vì không có bản ghi nhật ký để nạp lại giá trị cũ
• Giải pháp: Giao thức Nhật ký viết trước (WAL)
Giao thức Nhật ký viết trước (WAL)
• Chú ý:
o Nếu hệ thống crash Trước khi giao dịch chuyển giao thì mọi thao tác phải được undo.
Chỉ cần ảnh trước(phần undo của nhật ký)


o Ngay sau khi giao dịch được chuyển giao, một số hoạt động nào đó phải được redo.
Cần ảnh sau(phần redo của nhật ký)
• Giao thức WAL:
1/Trước khi csdl ổn định được cập nhật, phần undo của nhật ký sẽ được viết vào
nhật ký ổn định
2/ Khi giao dịch chuyển giao , phần redo của nhật ký phải được ghi vào nhật ký
ổn định trước khi cập nhật csdl ổn định.
Giao tiếp lập nhật ký

PHụC HồI DỰA TRÊN NHậT KÝ
- Nhật ký được giữ trên vùng nhớ ổn định.
 Nhật ký là chuỗi các bản ghi nhật ký , duy trì một bản ghi các hoạt động cập nhật trên
csdl .

- Khi giao dịchTi bắt đầu chính nó đăng ký bằng cách viết một bản ghi nhật ký
start>
- Trước khi Ti vận hành write(X), một bản ghi nhật ký <Ti, X, V1, V2> sẽ được viết (Chú
ý V1 và V2) với X.
 Bản ghi nhật ký lưu ý Xj có giá trị V1 trước và V2 sau khi viết.
- Khi Ti kết thúc câu lệnh cuối cùng, bản ghi nhật ký <Ti commit> sẽ được viét.
- Ta giả thiết rằng bản ghi nhật ký được đưa trực tiếp đên vùng nhớ ổn định.(chúng không
được đệm)
- Hai cách tiếp cận dùng nhật ký
 Biến thể cơ sở dữ liệu trì hoãn
 Biến đổi cơ sở dữ liệu tức thời
BIếN ĐổI Dữ LIệU DEFFERED(trì hoãn)Chỉ redo viết vào những phần đã chuyển giao-trì
hoãn cho đến khi chuyển giao-

Lược đồ biến đổi dữ liệu trì hoãn ghi lại mọi biến đổi vào nhật ký nhưng trì hoãn mọi
thao tác viết lên sau chuyển giao riêng phần.
Giả thiết mọi giao dịch là nối tiếp nhau


-

Giao dịch bắt đầu bằng viết bản ghi <Ti start> vào nhật ký.
1 Thao tác write(X) thu được trên bản ghi nhật ký <Ti, X, V> , ở đay V là giá trị mới của
X
o Chú ý: giá trị cũ không cần cho lược đồ này
Việc viết X không thực hiện trong thời gian này mà được trì hoãn.
Khi Ti chuyển giao riêng phần <Ti commit> được viết vào nhật ký.
Cuối cùng, các bản ghi nhật ký được đọc và được dùng để vận hành thực tế các viêc ghi
trước đó.

Trong khi phục hồi sau crash, các giao dịch cần redo nếu và chỉ nếu có cả hai <Ti start>
and<Ti commit> trong nhật ký.
Redo một giao dịch Ti ( redoTi) thiết lập giá trị mới cho mọi hạng mục dữ liệu được cập
nhật bởi giao dịch với các giá trị mới.
Crashes có thể xuất hiện trong khi:
o Giao dịch vận hành cập nhật dữ liệu original, hay
o Trong khi hoạt động phục hồi xảy ra
Ví dụ các giao dịch T0 and T1 (T0 vận hành trước T1):
T0: read (A)
T1 : read (C)
A: - A - 50
C:C- 100
Write (A)
write (C)
read (B)
B:- B + 50
write (B)

Ta xem nhật ký khi nó xuất hiện ở 3 thực hiện thời gian khác nhau:

Nếu nhật ký trên vùng nhớ ổn định tại thời điểm sập là trong trường hợp:
(a) Không cần hoạt động redo xảy ra
(b) redo(T0) phải được thực hiện do co <T0 commit>
(c) redo(T0) phải được thực hiện tiếp sau bởi redo(T1) do có mặt
<T0 commit> and <Ti commit> are present
BIếN ĐổI Dữ LIệU tức thời


-

Lược đồ biến đổi csdl tức thời cho phép csdl cập nhật giao dịch không chuyển giao được
viết như đã công bố

Do việc undo là cần nên việc cập nhật nhật ký phải có cả giá trị cũ và mới.
- Việc cập nhật bản ghi nhật ký cần được viết trước hạng mục csdl được viết.

Ta giả thiết rằng bản ghi nhật ký được đưa trực tiếp đên vùng nhớ ổn định.

Có thể mở rộng để hoãn (postpone) đưa ra bản ghi nhật ký, vì thế trước khi vận
hành thao tác output(B) cho khối dữ liệu B, mọi bản ghi nhật ký tương ứng với hạng mục
B phải được flush vao vùng nhớ ổn định.
- Việc output các khối được cập nhật có thể xẩy ra tại bất kỳ thời điểm nào trươc hay sau
khi giao dịch chuyển giao.
- thứ tự trong các khối đưa ra(output) có thể khác với thứ tự trong khi chúng được viết.
Log
<T0 start>
<T0, A, 1000, 950>
To, B, 2000, 2050

Write

Output

A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600>
C = 600
BB, BC

thứ tự output không nhất thiết như chuyển giao.

<T1 commit>
BA
- Chú ý : BX ký hiệu khối chứa X
- Thủ tục phục hồi có 2 thao tác thay cho 1:
 undo(Ti) restores the value of all data items updated by Ti to their old values, going
backwards from the last log record for Ti
 redo(Ti) sets the value of all data items updated by Ti to the new values, going forward
from the first log record for Ti
- Cả 2 thao tác pahir là lũy đẳng( idempotent)
 Tức là nếu thao tác thực hiện nhiều lần, ảnh hưởng của nó như nhau nếu nó thực hiện 1 lần
 Rất cần do thao tác có thể vận hành lại trong khi phục hồi.
- Khi phục hồi sau sự cố:
 Giao dịch Ti cần undo nếu nhật ký chứa bản ghi <Ti start> nhưng không chứa bản ghi,
<Ti commit>.
 Giao dịch Ti cần redo nếu nhật ký chứa bản ghi <Ti start> và bản ghi, <Ti commit>.
- Các thao tác undo thực hiện trươc hết rroif mới đến thao tác redo
Ví dụ BIếN ĐổI Dữ LIệU PHụC HồI DB tức thời
Below we show the log as it appears at three instances of time.


Recovery actions in each case above are:
(a) undo (T0): B cần nạp lai 2000 và A là 1000
(b) undo (T1) and redo (T0): C cần nạp 700, A và B thiết lập 950 và 2050.
(c) redo (T0) and redo (T1): A and B là 950 và 2050, C là 600

PHỤC HỐI VỚI GIAO DịCH TƯƠNG TRANH
- Chúng ta thay đổi lược đồ phục hồi dựa trên nhật ký để cho phép nhiều giao dịch vận

hành tương tranh.
 Mọi giao dịch chia xẻ một bộ đệm đĩa và nhật ký đơn.
 Một khối bộ đệm có thể có cac hạng mục dữ liệu được cập nhật bởi 1 hay nhiều
giao dịch.
- Ta giả thiết điều khiển tương tranh dùng khóa 2 pha nghiêm ngặt.;
 Tức là việc cập nhật của các giao dịch không chuyển giao không nhìn thấy được
đói với các giao dịch khác.
 Otherwise làm thế nào thực hiện undo nếu T1 cập nhật A, rồi giao dịch T2
cập nhật A và chuyển giao , và cuối cùng T1 phải abort?
- Việc lập nhật ký được thực hiện như đã mô tả ở trên.
 Các bản ghi nhật ký của các giao dịch khác nhau có thể được rải trên nhật ký.
- Kỹ thuật điểm kiểm tra và hoạt động lấy trên phục hồi phải được thay đổi.
 Do một vài giao dịch có thể active khi 1 điểm kiểm tra được thực thi.
- Các điểm kiểm tra được thực hiện như trên, ngoại trừ bản ghi nhật ký giời đây có dạng
< checkpoint L>
ở đây L là danh sách các giao dịch active tại thời điểm kiểm tra.
 Ta giả thiết không cập nhật trong quá trình khi điểm kiểm tra đang được thực
hiện(xem sau).
- Khi hệ thống phục hồi từ crash, đầu tiên nó làm như sau:
 Khởi tạo undo-list and redo-list vè rỗng
 Quét ngược nhật ký từ cuối, dừng khi tìm thấy bản ghi <checkpoint L> đầu tiên
 Với mỗi bản ghi tìm thấy trong quet ngược:
 Nếu bản ghi là <Ti commit>, thêm Ti vào redo-list
 Nếu bản ghi là <Ti start>, nếu Ti không trong redo-list, thêm Ti vào undolist
 Với mọi Ti trong L, nếu Ti không trong redo-list, thêm Ti vào undo-list


-

Tại thời điểm này undo-list bao gồm các giao dịch không hoàn tất chuyển giao và phải

undo, redo-list bao gồm các giao dịch chuyển giao hoàn tất và phải redo.
Việc phục hồi thực hiện tiếp như sau:
 Quét ngược nhật ký từ bản ghi gần nhất, dừng khi các bản ghi
<Ti start> đã kiểm tra được co mọi Ti trong undo-list.
 Trong khi quét, thực hiện ud cho từng bản ghi nhật ký thuộc về 1 giao dịch
trên undo-list
 Định vị bản ghi <checkpoint L> gần nhất
 Quét xuôi nhật ký từ bản ghi <checkpoint L>..đến cuối nhật ký.

 Trong khi quét, thực hiện redo cho từng bản ghi nhật ký thuộc về 1 giao
dịch trên redo-list

Ví dụ PHỤC HỐI VỚI GIAO DịCH TƯƠNG TRANH
n Go over the steps of the recovery algorithm on the following log:
<T0 start>
<T0, A, 0, 10>
<T0 commit>
<T1 start>
/* Scan at step 1 comes up to here */
<T1, B, 0, 10>
<T2 start>
<T2, C, 0, 10>
<T2, C, 10, 20>
<checkpoint {T1, T2}>
<T3 start>
<T3, A, 10, 20>
<T3, D, 0, 10>
<T3 commit>

5.3.3 Điểm kiểm tra :

Giải pháp : Điểm kiểm tra (phiên bản đơn giản ) Định kỳ
(1) Không chấp nhận các giao dịch mới
(2) Chờ đến khi mọi giao dịch kết thúc
(3) Dồn mọi bản ghi nhật ký lên đĩa (nhật ký)
(4) Dồn mọi bộ đệm lên đĩa (DB)-không dập bộ đệm
(5) Viết bản ghi “điểm kiểm tra” lên đĩa(nhật ký)
(6) Tiếp tục xử lý giao dịch
-

Vấn đề trong thủ tục phục hồi như đã bàn ở trên:
Tìm kiếm toàn bộ nhật ký là tiêu tốn thời gian.
1.


Ta phải redo các giao dịch không cần thiết(đã làm rồi )
output các bản cập nhật của chúng ra csdl
3.
Streamline thủ tục phục hồi bằng thực hiện điểm kiểm tra chu kỳ
Output mọi bản ghi nhật ký hiện nằm trong bộ nhớ chính vào vùng nhớ ổn định.
1.
Output mọi khối bộ đệm đã thay đổi lên đĩa.
2.
Viết 1 bản ghi nhật ký <checkpoint> vào vùng nhớ ổn định.
3.
Trong khi phục hồi, ta chỉ xem xét giao dịch Ti gần nhất bắt đầu trước điểm kiểm tra và
các giao dịch khởi động lại sau Ti.
Quét ngược từ cuối của nhật ký để tìm ra điểm kiểm tra gần nhât
1.
Tiếp tục quét ngược cho tới khi tìm được <Ti start>
2.

Chỉ cần xem xét phần nhật ký tiếp sau bản ghi start ở trên. Phần sớm hơn của
3.
nhật ký có thể bỏ qua trong khi phục hồi, và có thể được xóa khi nào yêu cầu.
Với mọi giao dịch (bắt đầu từ Ti hay sau) không có <Ti,COMMIT> vận hành
4.
undo(Tj)(chỉ làm trong trường hợp biến đổi immediate)
Quét xuôi nhật ký, với mọi giao dịch bắt đầu từ Ti hay sau đó với <Ti commit> ,
5.
vận hành <Ti commit>, execute redo(Ti).
2.

-

-

Ví dụ điểm kiểm tra





T1 có thể được bỏ qua (cập nhật đã output đên đĩa do checkpoint)
T2 và T3 redone.
T4 undone

Các tiến trình nền và phục hồi: Checkpoint (CKPT)
CKPT chịu trách nhiệm để:
• Báo hiệu DBW n ở điểm kiểm tra .
• Cập nhật các header file dữ liệu với các thông tin kiểm tra.
• Cập nhật thông tin điều khiển với các thông tin kiểm tra.

5.3.4 Cập nhật thông tin phục hồi
Quản trị phục hồi cục bộ- Kiến trúc
• Vùng nhớ bay hơi
o Bao gồm bộ nhớ chính của hệ thống máy tính.
• Vùng nhớ ổn định
o Đàn hồi với sự cố và mất dữ liệu chỉ khi có sự cố phương tiện(VD hỏng đầu đĩa)
o Được thực hiện qua tổ hợp của các thành phần phần cứng(vùng nhớ không bay hơi) và phần
mềm(đọc-ổn định, ghi-ổn định,dọn dẹp)


Các chiến lược cập nhật
• Cập nhật vào đúng vị trí
o Mỗi cập nhật gây ra sự thay đổi trong một hay nhiều giá trị dllieu trên
trang trong bộ đệm csdl
• Cập nhật vào vị trí khác
o Mỗi cập nhật gây ra sự thay đổi (các) giá trị mới của các hmuc dữ liệu
được lưu tách khỏi (các) giá trị cũ

Thông tin phục hồi cập nhật đúng vị trí
Nhật ký CSDL: Mọi hoạt động của giao dịch không chỉ thực hiện hoạt động mà còn phải viết 1
bản ghi nhật ký vào 1 file chỉ (nối) append

Cập nhật thông tin phục hồi ở nơi khác
• Shadowing
o Khi cập nhật, không thay đổi trang cũ mà tạo trang shadows với giá trị mới và viết nó vào
csdl ổn định
o Cập nhật đường truy nhập sao cho các truy nhập kết tiếp là đến trang shadow mới
o Trang cũ được duy trì cho phục hồi

•

Các file khác
o Với mỗi file F, duy trì
•
•
•

1 Phần file chỉ đọc FR
1 file khác nhất quán của dữ liệu đưa thêm DF+ và phần xóa DFNhư vậy, F=(FR ∪ DF+)-DF-