Tải bản đầy đủ (.docx) (25 trang)

đồ án công nghệ thông tin Bài nhóm Mô hình giao dịch lồng an toàn và mở tương tranh và phục hồi

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (437.93 KB, 25 trang )

Mô hình giao dịch lồng an toàn và mở : tương
tranh và phục hồi
Giáo viến hướng dẫn: TS Nguyễn Đức Anh
Nhóm thực hiện : Nhóm 09
Họ và tên MSSV
Lê Xuân Tùng 20083004
Nguyễn Tuấn Anh 20080115
Nguyễn Viết Anh 20080125
Lê Văn Đạo 20080700
Lê Văn Hội 20081289
Lớp Hệ thống thông tin_K53
1
Mục lục
2
Tóm tắt
Trong bài báo này, chúng tôi trình bày một mô hình giao dịch lồng mở an toàn. Chúng tôi
thảo luận về điều khiển tương tranh và các thuật toán phục hồi cho mô hình của chúng tôi.
Mô hình giao dịch lồng của chúng tôi sử dụng các khái niệm của giao dịch con điểm phục
hồi trong cây giao dịch lồng. Nó kết hợp một thao tác prewrite trước mỗi thao tác write để
tăng tương tranh tiềm năng. Mô hình giao dịch gọi là “mở và an toàn” do các thao tác
prewrite cho phép đọc trước( trước khi những hành dộng write được thực hiện trên đĩa)
mà không có tầng hủy bỏ. Hệ thống khởi động lại và các hoạt động quản lý bộ đệm cũng
được mô hình hóa giống như các giao dịch lồng nhau để khai thác các tương tranh có thể
trong suốt quá trình khởi động lại. Các thuật toán điều khiển tương tranh được đề xuất
trong cơ sở dữ liệu cũng được sử dụng để điều khiển các hoạt động phục hồi tương tranh.
Chúng tôi đã đưa ra một ảnh chụp một hoạt động giao dịch hoàn chỉnh, cấu trúc dữ liệu
liên quan và xây dựng một vùng khởi động lại trong trường hợp phục hồi sụp đổ
1. Giới thiệu
1.1. Tổng quan về các mô hình giao dịch lồng nhau và thuật toán phục hồi
1.1.1. Mô hình giao dịch lồng đóng
Trong mô hình giao dịch lông đóng (Moss, 1985), một giao dịch con có thể chứa các thao


tác được thực hiện đồng thời, hoặc các thao tác mà có thể được hủy bỏ một cách độc lập
với các giao dịch liên quan. Như vậy các thao tác được coi là các giao dịch con của giao
dịch gốc. Quan hệ cha con này tạo ra một cây giao dịch lồng và các giao dịch được gọi là
các giao dịch lồng (Moss,1985). Những giao dịch con không thành công có thể được sửa
chữa bằng việc thay thế chúng bằng những giao dịch khác nhằm thực hiện thành công
toàn bộ giao dịch. Mỗi giao dịch phải kiếm được khóa tương ứng trước khi truy cập vào
một đối tượng dữ liệu. Kết quả của một giao dịch con không thể nhìn thấy ở ngoài giao
dịch cha của chúng (Vì thế nó được gọi là đóng). Một giao dịch con truy cập vào dữ liệu
khóa bởi cha của nó. Khi một giao dịch ghi một đối tượng dữ liệu, một phiên bản mới của
đối tượng được tạo ra. Phiên bản này được lưu trữ trong một bộ nhớ ổn định. Khi một
giao dịch con xác nhận thì phiên bản cập nhật của đối tượng được gửi tới giao dịch cha
của chúng. Nếu giao dịch mà bị hủy, phiên bản mới của đối tượng đó cũng bị hủy luôn. Uỷ
thác cha chỉ sau khi tất cả các giao dịch con của nó kết thúc. Khi Giao dịch trên cùng xác
nhận, phiên bản hiện thời của mỗi đối tượng sẽ được cất vào bộ nhớ ổn định.
Trong Mô hình giao dịch lồng đóng, có hạn chế là phạm vi của mỗi giao dịch con bị giới
hạn chỉ trong giao dịch cha của chúng. Điều này buộc một giao dịch con phải gửi tất cả các
khóa cùng các phiên bản của đối tượng dữ liệu cập nhật tới giao dịch cha của chúng trên
cơ chế xác nhận, kết quả của việc xác nhận giao dịch con chỉ tồn tại lâu dài khi xác nhận
3
được thực hiện tại giao dịch trên cùng. Trong nhiều ứng dụng, không thể chấp nhận được
rằng công việc của một ứng dụng mất một thời gian dài chờ đợi để hoàn tác khi sử dụng
một trong các kỹ thuật trên trong trường hợp bị lỗi ở khâu cuối cùng. Chiến lược hiện tại
buộc các giao dịch với thời gian sống ngắn chờ đợi trước khi thay khóa cho đến khi giao
dịch mước cao nhất xác nhận và giải phóng khóa của chúng. Do vậy hệ thống không thích
hợp cho hệ thống chứa các giao dịch dài và ngắn.
1.1.2. Mô hình giao dịch lồng mở
Để khai thác ngữ nghĩa cụ thể tại mỗi tầng của hoạt động lồng. Weikem đã đưa ra một mô
hình giao dịch đa tầng (Weikum, 1991, Weikum et at 1990). Mô hình này không thực hiện
một cách không chính tắc bởi tính đến tính chất giao hoán của ngữ nghĩa các hoạt động ở
mỗi cấp dữ liệu trừu tượng mà thực hiện mức tương tranh cao hơn. Một giao dịch con cho

phép giải phóng khóa trước khi xác nhận đến giao dịch ở cấp cao hơn. Các khóa ở mức lá
được giải phóng sớm chỉ khi ngữ nghĩa của các thao tác được biến trước và thao tác bù
tương ứng được định nghĩa. Khi hủy một giao dịch ở mức cao, kết quả của nó được hoàn
tác bằng cách thực thi một thao tác nghịch đảo bù vào giao dịch đã hoàn tất. Phục hồi một
hệ thống bị sự cố bằng cách thực hiện hoàn tác giao dịch ở mức cao đồng thời làm lại các
thao tác ở mức lá. Mỗi cấp được cung cấp với một cấp cơ chế phục hồi cụ thể. Mô hình này
cũng đã được đề cập tới trong nghiên cứu về các hệ cơ sở dữ liệu hướng đối tượng trong
Muth et al (1993) và Rensende et al. (1994)
Trong nhiều ứng dụng, ngữ nghĩa của giao dịch có thể không rõ ràng do đó rất khó khăn
để cung cấp một thi hành không chính tăc. Trong trường hợp thời gian thực, có các lớp
khác của các thao tác không thể được bù. Có những thao tác mà không có thao tác đảo
ngược như việc chuyển một số tiền lớn tại một máy rút tiền tự động. Hoạt động như vậy
phải được trì hoãn cho đến khi mức cao nhất xác nhận, đó là những hoạt động bị hạn chế
sẵn có (như tăng thời gian phản ứng)
1.1.3. Thuật toán khôi phục giao dịch lồng.
Thuật toán phục hồi intentions-list và undo-logging được Fekete et al.(1993) đưa ra nhằm
phục hồi các giao dịch bị hủy trong môi trường giao dịch lồng bằng cách khai thác tính
chất giao hoán của các thao tác. Thuật toán intention-list làm việc bằng cách duy trì một
danh sách các hoạt động cho mỗi giao dịch. Khi một giao xác nhận, danh sách được kết
nối tới giao dịch cha. Khi nó bị hủy intention-list cũng bị loại theo.Khi giao dịch gốc xác
nhận, intention-list của nó được truyền tới nhật ký. Chương trình chỉ giúp phục hồi các
giao dịch hủy không điều khiển sự cố hệ thống. Để tăng đồng thời trong suốt quá trình
phục hồi undo-logging, chương trình cho phép một vài thi hành không nghiêm ngặt. Nó
cho phép một giao dịch chia sẻ các bản cập nhật không xác nhận được thực hiện bởi các
giao dịch khác bằng cách khai thác tính giao hoán của các thao tác. Trên sự thi hành của
một thao tác,hồ sơ của các đối tượng dữ liệu thay đổi trạng thái và trạng thái của của
chúng được chuyển tới nhật ký. Khi một giao dịch bị hủy , Ngược với thuật toán intentions-
list, tất các các giao dịch thi hành bởi các giao dịch trên đối tượng được hoàn tác từ trạng
thái hiện hời và sau đó chúng cũng được gỡ khỏi nhật ký. Thuật toán này không quan tăm
tới phụ hồi từ hệ thống đổ vỡ.

4
Trong cả hai thuật toán intentions-list và undo-logging, một giao dịch chưa hoàn chỉnh
được phép không xác nhận cập nhật sẵn có tới những giao dịch mà thực hiện một thao tác
giao hoán. Tuy nhiên đây lại là hạn chế đối với những giao dịch cùng cấp trừu tượng hóa.
Điều này có giới hạn. Trong cả hai thuật toán, tất cả các công việc được thực hiện ở các
giao dịch mức dưới bị loại bỏ trong trường hợp hủy bỏ tại một giao dịch mức cao. Điều
này có thể xảy ra và không được mọng muốn trong nhiều ứng dụng thời gian thực. Trong
thuật toán undo-logging algorithm, khi một hủy bỏ một giao dịch, ngươc với thuật toán
intentions-list, tất cả các thao tác thi hành bởi các giao dịch mức dưới của giao dịch được
hoàn tác từ trạng thái hiện tại và được gỡ khỏi nhật ký ngay sau đó. Trong cả hai thuật
toán, một giao dịch chưa hoàn thành được cho phép không xác nhận cập nhật tới những
giao dịch mà thực hiện các thao tác giao hoán. Đây là giới hạn cho những giao dịch ở cùng
mức trừu tượng.
Hai mô hình phục hồi trên chỉ chú ý đến ngữ nghĩa của các thao tác tại mức lá. Hệ thống R
(Gray et al., 1981) khai thác lớp ngữ nghĩa đặc biệt nhưng hạn chế đến 2 mức của giao
dịch lồng. Trong hệ thống R, Để thực hiện phục hồi, cập nhật được hoàn tác bằng cách thi
hành một bộ các thao tác ngược tại tầng đó. Để thực hiện điều này System R ghi tập các
cập nhật và một bản ghi. Để phục hồi từ hệ thống bị sự cố, cơ sở dữ liệu trước tiên phải
được khôi phục tại một số tần phù họp. Nói cách khác, một cơ chế phục hồi cấp thấp là cần
thiết để tạo ra một bộ thao tác nguyên tử.
Trong Moss(1987), một kỹ thuật phục hồi sự cố tương tự đã được đề xuất cho môi trường
giao dịch lồng trên cơ sở phương pháp undo/redo nhật ký. Trong điều kiện của logging, cả
nhật ký undo/redo đề được sử dụng. Mohan et al (1992,1989) cũng đề cập đến “write
ahead logging” căn cứ vào thuật toán phục hồi sự cố sử dụng mô hình gia dịch lồng. Kiểu
undo/redo của mô hình giao dịch này khai thác tính chất của mô hình giao dịch lồng. Các
thao tác của một giao dịch được hoàn tác trước sẽ không được hoàn tác lại trong trường
hợp có thêm lỗi. Đó là một lợn thế hơn thuật toán phục hồi đa mức của Weikum mà yêu
cầu hoàn tác hoàn toàn khi có thêm một đổ vỡ.
1.2 Đóng góp của chúng tôi
Trong bài báo này, chúng tôi giới thiệu một mô hình giao dịch lồng mở an toàn trong môi

trường các thao tác đọc ghi bình thường để loại bỏ các khiếm khuyết ở trên, và nâng cao
khả năng hữu dụng và cung cấp kết quả phục hồi sự cố. Mô hình của chũng tôi hỗ trợ cả
giao gichj nội bộ và liên giao dịch Chúng tôi giả định rằng tính chất cảu các giao dịch tại
nhiều cấp trong mô hình lồng là chưa được biết đến. Có hai động lực chính cho mô hình
giao dịch của chúng tôi. Thứ nhất, đó là mong muốn các giao dịch tồn tại với thời gian dìa
nên phát hành khóa trươc khi giao dịch gốc xác nhận. Thứ hai trong trương hợp có thể có
thể lùi lại hoặc lấy lại những kết quả quan trọng trong các giao dịch ở mức dưới đã xác
nhận sau khi có lỗi giao dịch cấp cao hơn do bị hủy hoặc sự cố hệ thống. Chúng tôi trình
bày khái niệm của một “điểm phục hồi giao dịch con” của một giao dịch gốc trong cây giao
dịch lông. Nó cơ bản là một giao dịch con sau xác nhận trong đó giao dịch phía trên của nó
không được phép quay lại. Nói cách khác, một điểm phục hồi giao dịch con của giao dịch
gốc đã được xác nhận, tất cả các giao dịch ở trên của nó phải được buộc phải được xác
5
nhận. Trong trường hợp nó bị hủy bỏ, tổ tiên của nó có thể chọn một cahcs thay thế để
hoàn thành công việc. Mô hình gia dịch lồng của chúng tôi sử dụng một thao tác prewrite
trowcs mỗi thao tác write thực tế để làm tăng tương tranh. Cây giao dịch lồng của mô
hình bao gồm các thao tác cơ sở dữ liệu, các thao tác phục hồi hệ thống ( như là phân tích
và thao tác phục hội) và các thao tác quản lý bộ đệm đặc biệt quy định cho giao dịch lồng.
Các thao tác read, prewrite và write là mô hình tại lớp lá trong hệ thống cấp bậc các giao
dịch. Thao tác phục hôi được giới hạn trong các giao dịch lồng để tăng tương tranh trong
suốt quá trình khởi động lại hệ thống. Thuật toán khóa của chúng tôi điểu khiển thi ành
của cả hai thao tác bình thường giống như những thao tác phục hồi. Chúng tôi cũng bàn
về cấu trúc dữ liệu cần thiết cho thuật toán phục hồi. Chúng ta bàn về một ảnh chụp của
thuật toaans phục hồi và điều khiển tương tranh với trợ giúp của các ví dụ. Một tổng hợp
ngắn gọn về thuật toán phục hồi sự cố của chúng tôi đã từng được đề cập trong nghiên
cứu của Madria(1997c). Tính đúng đắn của thuật toán điều khiển tương tranh sử dụng
mô hình vào ra tự động động đã được đề cấp đến trong báo cáo madira et al(1997b).
Phần còn lại của báo cáo được trình bày như sau. Trong phần 2 chúng tôi trình bày về các
ví dụ và tổng quan về mô hình giao dịch lồng mà mô hình phục hồi. Trông phần 3 chúng
tôi thảo luận về mô hình hệ thống giao dịch lồng và thực hiện . Phần 4 trình bày về thao

tác khởi động lại hệ thống. Chúng tôi trình bày về ảnh chụp của xử lý giao dịch, đăng nhập
và phục hồi trong phần 5. Tổng kết trong phần 6
2.Thuật toán Phục hồi mô hình giao dịch lồng nhau
Trong chương này chúng ta sẽ đề cập đến: mô hình giao dịch lồng nhau với một vài ví dụ
và cung cấp một vài hình ảnh về mô hình và thuật toán khôi phục nó.
Chuyển sang ví dụ: Hãy xem xét một phần mô hình giao dịch lồng nhau là chuyển khoản từ
một nhóm người tới người khác. Trong giao dịch cây, hãy để T
s
là một giao dịch trên ,T
s1
gọi là giao dịch dưới để thu thập (truy cập) vốn từ tài khoản khác. Một khi T
s1
được xác
nhận, T
s
gọi T
s2
để các khoản tiền tín dụng cuối cùng được đưa vào tài khoản khác.
Giả sử sau một giao dịch Tw đã thu hồi tất cả số tiền,Ts xác nhận. Nếu bất kỳ giao dịch nào
ở trên Ts hủy bỏ thì nó mong muốn cho các giao dịch hoàn thanh thành công trên giao dịch
phục hồi. Điểu này bởi là vì nó không thể sửa chữa thành công của giao dịch bởi một số
thao tác đền bù . Một khả năng khác là trì hoãn hoạt động của Ts cho đến khi mức giao
dịch ở trên xác nhận hạn chế sẵn có. Ví dụ một giao dịch cân bằng phải chờ đến khi giao
dịch có mức xác nhận cao nhất.
Một kịch bản trong giao dịch lồng nhau, giao dịch con sẽ quyết định sự thành công hay
thất bại của giao dịch ở mức đỉnh. Giả sử cây mô hình giao dịch lồng nhau này hoạt động
khác nhau có liên quan tới một kinh doanh du lịch . Một số hoạt động là rất quan trọng
trong việc xác định sự hoàn thành các hoạt động ở cấp cao nhất. Ví dụ như xác nhận của
“fund” và “visa” là thao tác liệu sẽ đi du lịch xác nhận hay không, đó là xác nhận ở mức
dưới Sẽ xác định xác nhận ở mức cao hơn xác nhận hay không đến số phận của các giao

6
dịch khác cây giao dịch. Chú ý rằng Xác nhận giữa fund và visa, giao dịch ở mức trên sẽ
được bắt buộc để xác nhận (kể cả một vài trì hoản hay bắt đầu lại )
Tính năng nổi bật của mô hình của chúng tôi: Mô hình của chúng tôi cho phép một số giao
dịch đặc biệt trước khi có xác nhận giao dịch của họ tổ tiên. Điều này cho phép một số
giao dịch khác có được các yêu cầu khóa sớm hơn. mô hình giao dịch lồng nhau của chúng
tôi có thể xử lý các tình huống ở nơi mà kết quả của các giao dịch mức thấp đã được xác
nhận không thể làm lại hoặc bồi thường trong trường hợp mức giao dịch cao hơn thất
bại.
Một ngữ nghĩa của giao dịch có thể gồm một điểm nhất định, nó có thể không
phục hồi lại hoàn toàn hoặc không nên bị mất. Chúng tôi đạt được điều này bằng cách giới
thiệu các khái niệm về “giao dịch điểm phục hồi“ (recovery point substransaction)của một
giao dịch cấp cao nhất trong một cây giao dịch lồng nhau. Đó là bản chất là một giao dịch
sau khi có xác nhận, tổ tiên của nó là không được phép để phục hồi lại trạng thái cũ. Trong
trường hợp một giao dịch cấp trên hủy bỏ hoặc các hệ thống bị lỗi sau xác nhận của các
điểm khôi phục của giao dịch, các giao dịch bị lỗi không thể hoàn tất trên hệ thống phục
hồi. Thực hiện giao dịch như vậy cho phép một giao dịch phục hồi điểm tiết lộ kết quả của
nó cho các giao dịch khác tại bất kỳ mức độ nào trước khi giao dịch cha của nó xác nhận.
Kết quả của một điểm giao dịch phục hồi được tạo ra một cách bền vững trước xác nhận
của giao dịch mức đỉnh. Điều này có trong sự hồi phục của các thuộc tính độc lập của giao
dịch (Harder và Reuter, 1983)
Để tránh hoàn tác thao tác và các hậu quả hủy bỏ và làm tăng độ sẵn sàng, chúng tôi giả
định mỗi giao dịch phát ra một thao tác prewrite trước một thao tác write (Madria,Năm
1995; Madria và cộng sự, 1999;. Madria và Bhargava, 1997a) của đối tượng mà nó dự
định ghi. Mỗi thao tác prewrite chứa kết quả của giao dịch user-visiable và đứng trước
phương thức ghi cuối cùng được liên kết. Một hoạt động prewrite thực sự không làm thay
đổi trạng thái của dữ liệu nhưng nó chỉ đưa ra giá trị đối tượng dữ liệu sẽ có sau khi
phương thức write đươc liên kêt với nó được thực hiên. Lợi thế của prewrite là một thao
tác đọc của các giao dịch khác có thể lấy được các giá trị trước khi trạng thái của một đối
tượng dữ liệu cập nhập lên bộ nhớ ổn định và do đó làm tăng tính sẵn dùng của các giá trị

dữ liệu mới.
Hoạt động Prewrite này đặc biệt hữu ích trong các ứng dụng thiết kế kỹ thuật (Kim và
cộng sự, 1984.) CAD (Korth và cộng sự, 1990.), Thiết kế dự án phần mềm lớn (Korth và
Speegle, 1990) vv nơi giao dịch dài. Một giao dịch con kích hoạt các giao dịch con truy
nhập prewrite khác tại mức lá cho các đối tượng dữ liệu là định nghĩa để trở thành một
giao dịch con phục hồi điểm. Giao dịch con prewrite giải phóng khóa trước khi các giao
dịch tổ tiên của chúng xác nhận. Loại bỏ một vài trong số các prewrite trước xác nhận của
giao dịch con điểm phục hồi sẽ không bắt đầu việc hủy bỏ khi các giá trị prewrite được làm
rõ chỉ sau xác nhận của giao dịch con phục hồi điểm.
7
2.1. Thuật toán phục hồi sự cố
2.1.1. Mục tiêu cơ bản của thuật toán phục hồi sự cố hệ thống
• Khôi phục trạng thái cơ sở dữ liệu của các đối tượng dữ liệu mà cơ sở dữ không chứa các
giá trị được xác nhận cuối cùng với các dữ liệu liên quan khi lỗi hệ thống xảy ra
• Khôi phục các giá trị prewrite (lưu giữ tại vùng đệm ghi prewrite-buffer) của các đối
tượng dữ liệu đã được công bố xác nhận điểm phục hồi giao dịch con trước khi hệ thống
thất bại.
• Để xác định đối tượng dữ liệu, đối tượng bảng dirty object table phải được phục hồi.
Bảng này được sử dụng để theo dõi các đối tượng dữ liệu mà (thường bằng văn bản )giá
trị không phù hợp với giá trị trong cơ sở dữ liệu ổn định. Bảng này cũng giữ thông tin về
các đối tượng dữ liệu có các giá trị prewrite, được công bố bởi xác nhận điểm phục hồi các
giao dịch con, không được ghi tuần tự lên cơ sở dữ liệu trước khi một hệ thống sụp đổ.
• Một hệ thống sụp đổ tạo ra thêm một vấn đề về sự hoàn thành của các giao dịch mức
đỉnh mà các giao dịch con điểm phục hồi của chúng đã được xác nhận trước khi hệ thống
sụp đổ. . Họ phải làm lại có được các khóa được giữ bởi chúng tại thời điểm sụp đổ trước
khi giao dịch mới có được khóa như vậy.
• Để xử lý trên, các giao dịch, bảng khóa phải được hồi phục. Bảng giao dịch giữ một danh
sách của tất cả các giao dịch đang hoạt động trong hệ thống bất cứ lúc nào.
Bảng giao dịch phục hồi sẽ nhận ra những thao tác của những giao dịch ở mức đỉnh mà
các giao dịch con điểm phục hồi đã được xác nhận trước khi hệt hống gặp sự cố. Bảng

khóa gồm các loại khóa được tổ chức bởi các giao dịch khác nhau về dữ liệu đối tượng bất
kỳ lúc nào. Bảng khóa phục hồi sẽ giúp đỡ trong tái tạo lại các khóa được tổ chức bởi hoạt
động - mức giao dịch và con cháu của họ vào thời điểm đó thất bại.
• Để kích hoạt giao dịch ở mức đỉnh mới ngay sau khi dirty object, giao dịch, và các bảng
khóa gồm các trạng thái của việc ghi và ghi bộ đệm của dirty data đối tượng được tái lập.
2.1.2 các bước phục hồi hệ thống
Để đạt được mục đích phục hồi ở tren, chúng ta cần làm các bước sau để khởi động lại hệ
thống :
Revival of dirty table ( phục hồi bảng dirty object ) Bảng dirty object cần thiết phải được
checkpoint một cách định kỳ bằng cách truyền một bản sao của nó vào nơi lưu trữ ỏn định
trong suốt quá trình xử lý bình thường. Giá trị viết trước và after-images được ghi nhật ký
trên nơi lưu trữ trong suốt quá trình thực hiện để xây dựng bảng dirty object lâu dài trong
trường hợp có lỗi hệ thống xảy ra trước khi lần checkpoint kế tiếp được tiến hành. 1 giao
dịch không được chấp nhận hoàn thành cam kết xử lý của nó cho đến khi phần làm lại của
giao dịch đó được ghi lên nơi lưu trữ. Phần làm lại của một bản ghi nhật ký cung cấp
thông tin cho biết như thé nào để redo lại các thay đổi được thực hiện bởi các giao dịch đã
8
cam kết ở trước. Trong suốt quá trình khởi động lại hệ thống, bảng dirty object được phục
hồi với sự trợ giúp của hầu hết các bản sao đã được checkpoint gần đây của bảng dirty
object và được sủa với sự trợ giúp của nhật ký lưu trữ sau lần checkpoint cuối cùng.
Revival of transaction and lock table ( phục hồi các giao dịch và các bảng khóa )
Các giao dịch và các bảng khóa được checkpoint bằng cách truyền một bản sao copy của
mỗi cái vào nơi lưu trữ một cách định kỳ trong suốt quá trình xử lý bình thường. Bất cứ
khi nào một giao dịch con được tạo ra hoạt động hoặc khi bất kỳ giao dịch nào có được
hoặc giải phóng một khóa, thông tin này cũng dược ghi nhật ký để xây dựng một trạng
thái ổn định cho các bảng này. Tuy nhiên, những thông tin này có thể không được ghi nhật
ký cho các giao dịch con truy cập chỉ đọc và viết trước. khi chúng bị lờ đi trong trường hợp
hệ thống bị hỏng. Nếu một checkpoint được tiến hành trong suốt quá trình phục hồi , sau
đó nội dung của các giao dịch và các bảng khóa cũng sẽ dược bao gồm trong checkpoint.
Sự ghi vào thích hợp với tất cả các giao dịch khác loại trừ những nội dung kia được khởi

đồng lại, bị gỡ bỏ khỏi giao dịch và các bảng khóa. Để làm điều này, ta càn tìm các nơi lưu
trữ có chứa các trạng thái cam kết( commit-state) của điểm phục hồi giao dịch con của
mỗi giao dịch bậc cao. Thong tin trạng thái cam kết bao gồm dữ liệu riêng tư và các thông
tin khác, định danh của giao dịch con cam kết cũng như của các giao dịch cha của nó.
Một thông tin cam kết trạng thái của một giao dịch con T1 xác định trạng thái của giao
dịch cha T2 của nó ở thời diểm cam kết của T1. Thông tin cam kết trạng thái trợ giúp việc
xác thực lại trạng thái khởi động của lại của một giao dịch bậc cao theo thứ tự để hoàn
thành công việc của nó. Không một giao dịch con nào mà toàn bộ ảnh hưởng không thể
được làm xong trong trường hợp hệ thống hỏng có thể được xem xét hoàn toàn cho đến
khi thông tin cam kết trạng thái của nó và tất cả dữ liệu của nó được ghi lại một cách an
toàn vào nơi lưu trữ. Nếu nơi lưu trữ không bao gồm cam kết trạng thái của điểm phục hồi
giao dịch con của một giao dịch bậc cao thì tất cả việc ghi vào thích hợp đến nó và tất cả
các giao dịch con của nó bị gỡ bỏ khỏi bảng. Ngược lại, giao dịch bậc cao hoàn thành công
việc còn lại của nó.
Revival of buffer ( phục hồi bộ đệm ) để phục hồi nọi dung của bộ đệm ghi của một đối
tượng dirty data, chúng ta copy giá trị của đối tượng dữ liệu từ stable-db đến bộ đệm ghi.
Tuy nhiên, phiên bản cơ sở dữ liệu lâu dài của đối tượng dữ liệu có thể không bao gồm một
số hoặc tất cả các cập nhật của các giao dịch cam kết………
Transaction logging and recovery (phục hồi và ghi nhật ký giao dịch ) các bản ghi nhật ký
được viết thay mặt các giao dịch phụ luôn luôn liên kết với các bản ghi cuối cùng của cha
của chúng tương ứng với cây giao dịch trong nhật ký. Bất cứ khi nào một truy cập viết
trước được truyenf tới giao dịch cha của nó thì thông tin cam két của nó và giá trị viết
trước được truyền tới giao dịch cha của nó , đấy là sự phục hồi điểm giao dịch phụ. Khi sự
phục hồi điểm giao dịch phụ quyết dịnh sự cam kết, thông tin cam kết trạng thái của nó và
giá trị viết trước được ghi nhật ký. Cam kết trạng thái này cho biết lịch trình( hay quy
trình ) tính từ thời diểm này, ảnh hưởng của giao dịch phụ cam kết không thể bị mất đi
dưới bất kỳ hoàn cảnh nào. Sự cam kết của điểm phục hồi giao dịch con chỉ xảy ra khi tất
9
cá các giao dịch con truy cập viết trước đã cam kết và bằng cách đó , cam kết trạng thái
của điểm phục hồi giao dịch con ảnh hưởng đến tất cả các con cháu truy cập viết trước đã

cam kết của nó. Cam kết trạng thái của điểm phục hồi các giao dịch phụ là cam kết đầu
tiên ghi vào trong nhật ký lưu trữ. Nếu hệ thống bị sự cố một cách trực tiếp sau cam kết
của sự phục hồi điểm giao dịch con của nó, scheduler sẽ khởi động lại hoạt động giao dịch
bậc cao của nó từ cam kết trạng thái( trong nhật ký) chở đi.
Bất cứ khi nào một gioa dịch con truy cập ghi ở mức lá quyết định cam kết, cam kết trạng
thái và giá trị ghi của nó được ghi trong nhật ký. Thông tin cam kết được truyền tới giao
dịch cha của nó mà giúp chấm dứt giao dịch cha. Quá trình ghi nhật ký cam kết trạng thái
sẽ vẫn tiếp tục cho đến khi giao dịch bậc cao cam kết. Trong trường hợp có lỗi, những nhật
ký này sẽ giúp phục hồi lại một giao dịch bậc cao. Quá trình ruyền một cam kết trạng thái
hoặc giá trị viết trước của một giao dịch tới nhật ký lưu trữ được gọi là transaction
checkpointing. Các cam kết trạng thái , giá trị viết và viết trước của các giao dịch phụ phải
được sắp thứ tự để giúp hoàn thành một sự thực hiện lại của một giao dịch bậc cao hoạt
động. Transaction checkpointing sẽ giữ tất cả các trạng thái cam kết logic cũng như giá trị
viết và viết trước, ma không thể bị mất.
Các giao dịch chỉ đọc không yêu cầu earrly write khi chúng không thay đổi một trạng thái
của một trạng thái của đối tượng dữ liệu.
Để hoàn thành các giao dịch bậc cao hoạt động, tất cả điểm phục hồi giao dịch con được
cam kết trước khi hệ thống bị sự cố, scheduler sẽ khởi dộng lại các trạng thái để khởi tạo
lại các giao dịch đó. Nếu cam kết của điểm phục hồi các giao dịch con chỉ là các bản ghi
cam kết trong nhật ký lưu trữ, thì giao dịch bâc cao hoạt động của nó khởi động lại từ các
cam kết trạng thái này. Mặt khác, scheduler tìm ra cam kết trạng thái được ghi trong nhật
ký cuối cùng sau khi cam kết của điểm phục hồi giao dịch con trước khi system crash theo
thứ tự để khởi động lại giao dịch từ trạng thái cuối cùng. Chỉ khi trạng thái khởi động lại
được xác thực, scheduler lấy lại dạng của các khóa giao dịch bậc cao hoạt động và tất cả
con cháu hoạt động của nó được giữ ở thời điểm có sự cố. Chỉ khi các khóa được lấy lại, sự
thực thi của một giao dịch bậc cao bắt đầu lại từ trạng thái khởi động lại
2.2.Cấu trúc dữ liệu
Ở đây chúng ta thảo luận về cấu trúc dữ liệu được sử dụng trong mô hình khôi phục thực
thi logic.Hầu hết các cấu trúc dữ liệu này cần thiết trong việc thực thi vật lý. Đầu tiên
chúng ta thảo luận về một số lĩnh vực hiển thị trong các loại bản ghi đăng nhập khác nhau

LSN: Cho địa chỉ bản ghi đăng nhập trống.Nó là một giá trị tăng.Nó hiển thị loại dữ liệu
bản ghi đăng nhập. Điều này có thể bao gồm các bản ghi đăng nhập khác nhưng không bắt
buộc.
Transaction-id: nhận dạng giao dịch tham gia trong bản ghi đăng nhập
Object-id:Nhận dạng các đối tượng tham gia vào bản ghi đăng nhập.Nó hiển thi bản ghi
đăng nhập "dữ liệu" và "khóa" các loại
10
Value: Đây là dữ liệu mô tả thực thi cập nhật .Bao gồm việc ghi lại giá trị.
Commit-state: Mô tả bản ghi nhật ký được gi trong suốt thời gian xác nhận của một giao
dịch con. Nó bao gồm dữ liệu liên, biến cục bộ… của giao dịch con được xác nhận
Active: Hiển thị bản ghi đăng nhập trong phiên giao dịch con.Bao gồm dữ liệu cá nhân,biến
cục bộ,etc, của phiên giao dịch con cam kết
Lock: Hiển thị bản ghi được đăng nhập khi phiên giao dịch con bẻ được khóa.Thông tin
không khóa bao gồm "giữ lại" hoặc "tổ chức" giao dịch.
Các bản ghi log có thể được phân loại như sau:
“Data”: Định dạng dữ liệu của hồ sơ đăng nhập: (LSN, transaction-id, Object-id, giá trị
priwrite hoặc write)
“Transaction”: Định dạng giao dịch của hồ sơ đăng nhập (transaction- id,trạng thái). Lưu
ý rằng trạng thái là giá trị "hoạt động" hoặc là "Xác nhận"
“Lock”: Định dạng khóa (transaction-id, lock type, Object-id).
Chúng ta tham khảo cấu trúc hoàn chỉnh bản ghi log (hồ sơ nhìn thấy) cùng với loại thông
tin của nó (END-CHK-POINT) là một hồ sơ để xác định kết thúc của một hoạt động.
2.2.1 Giao dịch và các bảng khóa
Để phân biệt giữa các giao dịch khác nhau và để biết về trạng trạng thái của chúng ( hoạt
động hay không ) trong hệ thống, chúng ta cần giữ transaction-id và trạng thái của mỗi giao
dịch, để làm việc đó ta sử dụng một transaction table. Xa hơn nữa, để ánh xạ tới cây giao dịch
mỗi transaction-id cũng là để chứa các tùy chỉnh của chúng như là thể hiện cảu giao dịch cha
chủa chúng. Định dạng này của transaction-id giúp trình lập kế hoạch trong báo cáo hủy hoặc
xác nhận của một giao dịch tới cha củ nó. Thêm vào đó một yêu cầu hủy cũng chứa thể hiện
của tất cả các tổ tiên của nó.

Để cho trình lập kế hoạch biết được là một giao địch hoạt động hay không. Nó là đủ để một
giao dịch có thể giữ chỉ một trạng thái mang tên “active”. Từ khi quan hệ cha con của xác
nhận giao dịch con là để lưu trữ trong log một cách riêng biệt bởi việc liên kết tới các bản
ghi log của các giao dịch con tới các giao dịch cha của chúng, các bảng giao dịch không cần
lưu thông tin về các giao dịch con đã được xác nhận. Một giao dịch con ghi vào trạng thái
“active” ngay khi nó được kịch hoạt và vẫn “active” cho đến khi nó xác nhận hoặc hủy bo.
Khi một giao dịch con xác nhận, mục này của nó được gỡ khỏi bảng giao dịch. Sau khi xác
nhận của giao dịch con điểm phục hồi, trạng thái của các giao dịch con trên của nó vẫn giữ
“active” trong trường hợp hủy tại một cấp cao hơn bởi vì chúng phairhoanf thành công việc
của chugs nên vẫn phải thi hành các công việc phục hồi. Trên hệ thống phục hồi, một khi các
giao dịch múc đỉnh “active” được quyết định, các giao dịch mức đỉnh “actve” khác và các
giao dịch con cháu “active” của chúng cũng bị dỡ khỏi bảng.
11
Bảng khóa giữ thông tin về các khóa giữ vởi tất cả các giao dịch hoạt động trong hệt hống tại
các thời điểm. Mỗi mục của bảng giữ thông tin về transaction-id, dạng khóa đươc giữ và
object-id. Khi một giao dịch có được một khóa trên đối tượng dữ liệu, một, mục được tạo ra
trên bảng khóa. Khi một giao dịch xác nhận hoặc hủy bỏ, mục giao dịch tương ứng được bỏ
đi khỏi bảng. Một mục mới được tao ra ccho giao dịch mà kế thừa khóa từ giao dịch đã bị
hủy hoặc xác nhận.
2.2.2. Bảng dirty data object
Mỗi lần nhập dữ liệu vào trong bảng đối tượng dữ liệu thô gồm trường Object-ID.
RccLSN(Dãy số khôi phục đăng nhập) ghi lại và ghi các hoạt động.Giá trị của hoạt động
ghi RCCLSN trong đăng nhập có thể được cập nhật,không bị mất dữ liệu cho dù bị mất
điện.Giá trị nhỏ nhất RccLSN trong bảng cho điểm bắt đầu kích hoạt lại. Tất cả bản ghi
đăng nhập phải ghi lại, LSNs lớn hơn giá trị nhỏ nhất RccLSN,yêu cầu làm lại các bản ghi
đăng nhập không có tác dụng chuyển đổi thành các cơ sở dữ liệu ổn định.Giá trị hoạt động
ghi lại của RccLSN nhỏ nhất lớn hơn RccLSN tối đa của tất cả các hoạt động ghi cho các
điểm khởi đầu để làm lại các hoạt động ghi lại.Tất cả các bản ghi đăng nhập ghi lại mà
LSNS lớn hơn RccLSN nhỏ nhất được yêu cầu làm lại mà không phải hoạt động .Bởi vậy,
các bản ghi đăng nhập ghi lại cần được làm lại.Mỗi khi các giá trị ghi được yêu cầu , tương

ứng với phần bảng đối tượng dữ liệu thô được xóa đi.Tương tự,mỗi khi đối tượng dữ liệu
được lưu trữ ổn định,các lần nhập tương ứng được lấy ra từ bảng.
3. Mô hình hệ thống giao dịch lồng và cài đặt
Mô hình hệ cơ sở dữ liệu giao dịch lồng của chúng ta chính thức bao gồm các thành phần
sau: Quản trị giao dịch (Transaction Managers- TMs), quản trị phục hồi (Recovery
Manager – RMs) và quản trị dữ liệu (Data Managers – DMs). DMs mô hình hóa các đối
tượng dữ liệu. Mỗi một Data Manager giữ một bản sao của đối tượng dữ liệu trong bộ nhớ
thứ cấp, gọi là stable-db. Giá trị của priwrite và write của mỗi đối tượng được giữ trong bộ
đệm tương ứng tại DMs tương ứng. Ứng với quá trình đó chúng được gọi là prewrite-
buffer và write-buffer. Thực chất, chỉ có một tập con của các DMs sẽ priwrite va write các
giá trị của đối tượng dữ liệu trong bộ đệm tương ứng. Một thao tác read lấy dữ dữ liệu
của đối tượng dữ liệu cần tham chiếu từ bộ đệm prewrite (nếu có) nếu không thì nó lấy kết
quả từ bộ đệm write. Nếu DM không có một bản sảo của đối tượng dữ liệu trong write-
buffer, chức năng read lấy dữ liệu từ bản sao stable-db của đối tượng dữ liệu. Nội dung
của write-buffer của một đối tượng dữ liệu được truyền một cách định kì tới bộ nhớ lâu
dài. Ngoài ra mỗi một DM duy trì một nhật ký ứng với đối tượng của dữ liệu. Mỗi một DM.
Mỗi một DM cũng chia sẻ một nhật ký chung.
Xem xét cấu hình trên, Mô hình của chúng tôi có 4 TMs khác nhau cho mỗi hành dộng read
(read-TM), write (write-TM) , của thao tác phân tích khởi động lại hệ thống (analysis-TM)
và phục hồi (redo-TM). Trong số này read-TM và write-TM được khởi xướng bỏ các giao
dịch user-visiable. Một tác tử bên ngoài giống như hệ điều hành gọi analysis-TMs và redo-
TMs. Một giao dịch ma là sự kết hợp của giao dịch write-TM và redo-TM để điều phối chức
12
năng quản lý bộ đệm. Để đạt được các khái niệm về tính minh bạch và tự phát trong thao
tác quản lý bộ đệm, các giao dịch ma gọi và xác nhận với các giao dịch liên quan đến nó.
TMs được đặt ở một giao dịch user-visible. Các cấp tiếp theo của hệ thống giao dịch có 6
phục hồi khác nhau để phối hợp: read-RM, priwrite-RM, write-RM, tranfer-RM và các phân
tích của hệ thống khởi động lại (analysis-RM) và redo-RM. Những RMs hoạt động bởi các
TMs tương ứng. Trong suốt quá trình của giao dịch ma, một deamon có thể được khởi
xướng bởi rất nhiều tranfer-RMs. Điều này sẽ giúp quá trình chuyển giao được thực hiện

trong thời gian thao tác phục hồi diễn ra. Những RMs đó khởi xướng truy cập các giao
dịch con ở mức lá. Mỗi read, prewrite và write-RM khởi xướng truy cập đọc, ghi trước và
ghi vào giao dịch con tùy từng cái. Một truy nhập read đọc giá trị hoặc từ prewrite hoặc từ
write-buffer của đối tượng dữ liệu trong khi một giao dịch write chỉ truy cập write-buffer
cấu thành bởi đối tượng dữ liệu. Một transfer-RM khởi xướng một truy cập truyền (giống
như truy cập read nhưng không trả lại giá trị) để truyền nội dung của write-buffer của đối
tượng dữ liệu tới stable-db. Analysis-RM khởi xướng truy cập copy, read, write và read-
analysis giao dịch con. Một bản sao giao dịch khởi tạo lại các bảng trong trong bộ nhớ
thay đổi được trong khi read truy cập vào đọc toàn bộ nhật ký sau khi check-point và các
truy cập write cuối cùng cập nhập các bảng để mang đi các tráng thái của chúng như là
thời điểm của sự cố. Một read-analysis giao dịch con trả lại thông tin về dirty object tại
thời gian hệ thống bị sự cố. Nó cũng trả lại một danh sách các hoạt động giao dịch( và
trạng thái khởi động lại) để được khởi động lại trên hệ thống khởi động lại. Một redo-RM
khởi xướng truy cập copy, read, prewrite và write các giao dịch con. Tại đây, một bản sao
giao dịch đặt bản sao stable-db của đối tượng và trong write-buffer của nó. Một truy cập
read khởi xướng redo-RM đọc một mục đăng nhâp tương ứng để một đối tượng dữ liệu
đăng nhập sau bản ghi checkpoint cuối cùng. Một truy cập prewrite(write) tạo ra một giá
trị thích hợp của prewrite-buffer (write-buffer). Cấu trúc cây giao giao dịch lồng được
trình bày trong hình 1(a) (Cho các thao tác chuẩn) và hình 1(b)( cho thao tác khởi động
lại hệ thống)
13
Chúng ta giả định rằng mỗi một giao dịch user biết write-set của nó trước khi khởi động
một write-TM để ghi tất cả các đối tượng dữ liệu. Một write-TM trước tiên khởi xướng một
prewrite-RM, sau đó nó tiếp thục khởi xướng prewrite truy cập các giao dịch con để thông
báo các prewrites cho tất cả các đối tượng dữ liệu chứa trong write-set. Giá trị của mỗi đối
tượng được ghi trong prewrite-buffer phân bố vào bộ nhớ tạm thời. Mô hình hóa
prewrites tại lớp lá cung cấp cho user minh bạch các hoạt động prewrite. Chúng ta chính
thức chỉ rõ prewirte-RM như là điểm phục hồi giao dịch con của giao dịch gốc. Một khi
prewrite-RM đã xác nhận, các giá trị priwrite trở nên có thể thấy được bên ngoải giao dịch
cha tại bất kỳ mức nào của cây mà không cần đòi hỏi bất kì xác nhận nào cảu các giao dịch

phía trên của nó. Sau xác nhận của prewrite-RM, write-TM khởi xướng một write-RM để
cập nhật tất cả các đối tượng dữ liệu mà có các giá trị prewrites đã được công bố trước
đây. Cập nhật cuối cùng được ghi trong write-buffer phân bố trong bột nhớ tạm thời tại
mỗi DM. Với việc gọi mỗi write-TM tự động, một daemon transaction được khởi xướng tự
động rồi tiếp tục khỏi xướng các transfer-RMs. Một tranfer-RM khởi xướng một truy cập
truyền giao dịch con để truyền giá trị của write-buffer tới stable-db. Nội dung của write-
buffer có thể được truyền mà không thông qua xác nhận của giao dịch gốc vì write-values,
một khi được ghi không thể hoàn tác hoặc biến mất.
Để đáp ứng giao dịch và đảm bỏa phục hồi dữ liệu, hệ thống duy trì một nhật ký tương
ứng cho mỗi đối tượng dữ liệu tại DM tương ứng. Hệ thống cũng duy trì một nhật ký
chung (được chia sẻ bởi tất cả DMs) để giữ thông tin về xử lý của giao dịch và dữ liệu liên
quan, khóa của chúng nắm giữ thông tin….Thuật toán của chúng tôi khẳng định tất cả các
bản ghi nhật ký ghi lạ những thay đổi để một số dữ liệu phải được lưu giữ ổn định trước
khi dữ liệu thay thế được cho phép được thay thế các phiên phản trước của dữ liệu trên
14
bô nhớ ngoài. Bản ghi nhật ký tương ứng với mỗi đối tượng dữ liệu được chỉ định một
trình tự đăng nhập duy nhất ( log sequence number – LSH) tại thời điểm bản ghi được đưa
vào nhật ký. Các LSN được phân theo thứ tự tăng dần. Khi một giá trị prewrite được công
bố, LSN của một bản ghi nhật ký prewrite được ghi lại vào trowng trường LSN của giá trị
prewrite trong prewrite bufer. Tương tự, khi giá trị của đối tượng dữ liệu được cập nhật
vào write-buffer, LSN của bản ghi nhật ký được đưa vào trong trường LSN của đối tượng
dữ liệu được cập nhật trong write bufer. Giá trị này của LSN sẽ được nhiều hơn giá trị của
LSN được liên kết với giá trị prewrite của cùng đối tượng dữ liệu. LSN với mỗi giá trị
prewrite và write trong trường LSN liên kết giữ các trạng thái của đối dữ liệu. Ngoài ra,
khi một giá trị của write-buffer được truyền tới stable-db, Các afterimages LSN được đặt
trong trường LSN của stable-db. Thẻ này của LSN cho phép theo dõi chính xác các trạng
thái của đối tượng với bản cập nhật của đối tượng dữ liệu cho mục đích khởi động lại hệ
thống. Mỗi write-buffer cũng ddowwocj liên kết với một trường stableLSN. Trường
stableLSN là LSN của bản sao stable-db của đối tượng. Một giá trị của write-buffer được
truyền tới bộ nhớ ổn định nếu stabeLSN của write-buffer lớn hơn LSN của write-bufer.

Điều này sã tránh truy cập LSN của stable-db để kiểm tra xem việc truyền các giá trị của
đối tượng để lưu trữ là cần thiết hay không.
3.1. Thuật toán điều khiển tương tranh
Trong mục này, chúng tôi thảo luận về các dạng tương tranh thường xảy ra trong mô hình
và phục hồi các thao tác và các khóa cần thiết để điều khiển chúng. Chú ý rằng chúng ta sử
dụng giống như giao thức điều khiển tương tranh để điều khiển các thi hành đồng thời
của các thao tác phục hồi và các thao tác cơ sở dữ liệu (xem hình 2). Các thao tác cơ sở dũ
liệu là read, write và prewrite. Các khóa cần để điểu khiển các thi hành đồng thời là read-
lock(RL) cho read, write-lock (WL) và prewrite –lock (PL) cho thao tác prewrite tương
ứng. Suốt thao tác phục hồi, các thao tác truy cập được thực hiện là copy, read, write,
tranfer, read-analysis và prewrite. Thao tác copy, read, tranfer và read-analysis được đọc
khóa và do đó kéo theo giao thức read-locking như trong hình 2. Write và prewrite được
write-lock và prewrite-lock do đó chũng cũng thực hiện theio các giao thức khóa đưa ra
dưới đây. Đối với write-lock và prewrite-lock. Một cuộc thảo luận chi tiết hơn về tínhđứng
đắn của thuật toán điều khiển tương tranh đã được trình bày trong nghiên cứu của Maria.
Một cách chính thức, chúng tôi có các thuật toán như mô tả ở hình 2.
15
16
4. Thao tác khởi động hệ thống
-khởi động lại hệ thống thực hiện hai bước: analysis pass(bước phân tích) và bước redo .
Sau bước redo Của các bản ghi nhật ký, bảng giao dịch sẽ bao gồm danh sách các giao dịch
ở thời điểm bị hỏng, bảng khóa sẽ khóa các mục tương ứng để hoạt động các giao dịch, và
bảng dirty object sẽ bao gồm danh sách các đối tượng mà ở thời điểm bị hỏng. Hoạt động
redo (làm lại) được thực hiện trong lần thứ hai theo thứ tự để lưu trữ các đối tượng dirty
data đến giá trị bền vững(làm dài) với thông tin được giủ trong nhật ký lưu trữ .
Bước được mô phỏng như là một phân tích analysis –TM mà khởi tạo một analysis –RM .
the analysis-RM khởi tạo nên một bản sao truy cập, mà khởi tạo khóa , giao dịch các bảng
dirty Object bằng cách đặt các bản sao lưu trữ lâu dài của chúng trong bộ đệm sau bản ghi
check print cuối cùng. The analysis –RM với sự giúp đỡ của các truy cập ghi cập nhật các
bảng này như sau: nếu một bản ghi nhật kí tương ứng với bảng giao dịch bắt gặp mà sự

đồng nhất thực sự xuất hiện trong bảng. Bảng giao dịch được sửa đổi để giữ các giao dịch
được hoạt động ở thời điểm xảy ra sự cố. 1 cách tương tự, 1 bản ghi nhật kí tương ứng với
bảng dirty Object được nhập với LSNhieenj tại trong bảng dirty Object nếu nó không thực
sự ở đó, theo một cách tương tự, bảng khóa cũng được cập nhật. Bất cứ khi nào một bản
ghi cam kết được bắt gặp một danh sách các bản ghi cam kết được làm ra. Diều này giúp
xác thực trạng thái khởi động lại của các giao dịch được thực hiện lại. 1 read- analysis trả
về 1 tập các RESLSN nhỏ nhất: đối tuongj dirty data với sự chú ý đẻ viết trước các thao
tác. Nó cũng trả về một danh sách các giao dịch hoạt động và trạng thái khởi động lại của
chúng.Thông tin ở trên sẽ là đầu ra của một analysis-TM. 1 check point lấy ở điểm cuối
của analysis pass
Hoạt động làm lại được thực hiện sử dụng giá tự viết trước và ảnh sau lấy từ nơi lưu trữ
hoạt động làm lại có thể đươc bỏ nếu không có đối tượng dirty data. Cây thừa kế giao dịch
cho phép hoạt động này gồm 1 redo- TM cho mỗi đối tượng, 1 redo-TM ở mức tiếp theo và
truy cập các giao dịch phụ ở mức lá. Mỗi redo-TM khởi tạo một redo-RM mà các trigger
copy , đọc viết trước và viết truy nhập các giao dịch con để làm lại thao tác biểu diển trong
nhật kí lưu trử tương ứng với các đối tuongj dữ liệu sau bản ghi check point cuối cùng. 1
bản sao giao dịch khở tạo lại write-buffer bằng cách sao chép nột dung của stable-db đến
write-buffer (bộ đệm viết) . 1 sự truy cập viết trước với sự trợ giúp của giá trị bản ghi
nhật kí viết truocs nếu giá trị cuarLSN được liên kết với bản ghi nhật kí viết trướ là lón
hơn LSNs của tất cả các bản ghi sau được lấy từ nơi lưu trữ . 1 truy cập viết thay thế giá
trị của đối tượng dữ liệu từ nhật kí trong bộ đệm viết liên kết của đối tượng dữ liệu nếu
LSN của đối tượng dữ liệu tyrong bộ đêm viết được tìm thấy nhỏ hơn LSN của bản ghi
nhật kí.
Dacmon transaction liên kết với redo-TM khởi tạo lại tranffer-RMs để truyền nội dung bộ
đệm viết đến stable –db. Sau cam kết của redo-TM . 1 check point được giữ.
Hoạt động phân tích và làm lại trong dạng giao dịch lồng cung cấp sự phục hồi nhanh
hơn từ 1 redo-TM cho mỗi đói tượng dữ liệu có thể được khở tạo song song . Cũng vậy nếu
một lỗi hệ thống xãy ra trong suốt quá trình thực hiện của 1 analysis-TM hoặc redo-TM,sự
17
tương ứng TM mới có thể được bẫy lỗi trên sự khởi động lại hệ thống. Tất cả các hànd

động của giao dịch con đã cam kết của TM bị hỏng không được yêu cầu bị bỏ đi(bỏ qua)
trong trường hợp của một hệ thống hỏng.
4.1 Buffer management operations (Các thao tác quản lý buffer)
Việc truyền một giá trị của đối tượng từ bộ đếm viết đên nơi lưu trữ được khởi tạo với sự
giúp đở của
Một demon transaction liên kết với mỗi write-TM và redo-TM . The demon transaction
dẫn 1 transfer –RM mà truyền giá trị của đối tượng dữ liệu từ bộ đệm viết của nó trong
volatile memory đến Stable –db trên nơi lưu trữ phụ. Vì mục đích đều , và theo thứ tự để
mô hình đúng đắn các yêu cầu nhỏ nhất, tranfer –RMs được mô hình như là các giao dịch
và được đặt ở vị trí là con cháu của write-TMs và redo – TMs trong cây giao dịch. Một thứ
có thể giống như là chấp nhận thao tác truyền để thay thế với mục đích những TM này
không điều khiển sự viện dẫn của chúng. Bằng cách này , chúng ta liên kết với một demon
transaction với mỗi write-TM và redo-TM. 1 demon transaction cam kết với sự chấp nhận
của TM liên kết với nó. Bằng cách đó, có thể việ dẫn nhiều tranfer-TM trong suốt phiên bản
của nó. Tuy nhiên chúng ta biết là sự liên tục (hay tuần tự) của các thao tác truyền cho
một đối tượng dữ liệu dọc –ghi từ bộ đệm viết đến Stable –db là giống nhau khi truyền lần
viết cuối cùng . Diều này cho phép the demon transaction khởi tạo nhiều tranfer –RM và
các cam kết mà không có sự cam kết cảu tất cả các giao dịch con transfer-RM nó.The
demon transaction đạt được các hành vi tự nhiên và rỏ ràng của truyền định kì của dữ liệu
từ volatile memory đến nơi lưu trữ .
Việc truyền bộ đệm viết đến Stable-db thay thế nếu: the stable LSN của bộ đệm viết lớn
hơn LSN của bộ đệm viết chỉ khi việc truyền của giá trị cùng với LSN được hoàn thành,
quyền ghi nhật kí từ stable log bị gỡ bỏ và stable LNS của bộ đệm viết được đặt là LNS của
bộ đẹm viết.
18
5.Ảnh chụp về xử lý , khai thác và phục hồi giao dịch
Xét cây cấu trúc giao dịch lồng.
U là người sử dụng giao dịch
T1 và T2 lần lượt là các read-TMs và write-TMs
T’2 là giao dịch daemon tương ứng.

T11,T21,T22 lần lượt là read-RMs, prewrite-RMs, và write-RMs
T’23 là transfer-RM.
T111 la quá trình truy nhập đọc
T211 và T212 lần lượt là quá trình truy nhập ghi lại
T221 và T222 lần lượt là quá trình truy nhập ghi
T’231 và T’’232 các giao dịch con truyền truy nhập. Các đối tượng dữ liệu hỗ trợ được truy
nhập bỏi các giao dịch là X và Y.
Ngay khi cấp giao dịch cao nhất U được thiết lập,trạng thái của nó được thiết lập “active”
trong bảng giao dịch. Thông tin này được thêm vào nhật ký trên bộ nhớ ổn định. Ngay sau
khi giao dịch T2,T21,T211 và T212 được kích hoạt,thông tin được ghi vào trong bảng giao
dịch như là được ghi lại trên bộ nhớ ổn định. Trạng thái của bảng giao dịch được hiển thị
trong hình 4(a)
Giao dịch T21 được khởi xướng bởi truy cập prewrite giao dịch con T211 và T
21
để lần lượt
loan báo giá trị priwrite của đối tượng dữ liệu X và Y. Ngay sau khi priwrite truy cập giao
T
211(
T
212
) lấy priwrite-lock trên DM tương được tới đối tượng dữ liệu X(Y), một mục trong
19
lock table được tạo ranhw trong hình 4(b). Khi một giá trị prewrite của đối tượng X(Y)
được thông báo bởi T
211
(T
212
) quyết định, LSN của bản ghi nhật ký để ddowcj ghi được đặt
trong trường LSN liên kết với giá trị prewrite. Khi T
211

(T
212
) quyết định xác nhận, thông tin
xác nhận và giá trị prewrite cùng với LSN được thông qua thới các giao dịch cha T
21
của
chúng. Prewrite-lock được giữ bởi T
212
được gửi qua prewrite-RM T
21
trên xác nhận của
chúng và các mục tương ứng được thục hiện trong bảng khóa. Cập nhật của dirty object
table, đăng nhập của giá trị prewrite và khóa giữ thông tin liên kết với T
211
và T212 được
hoãn lại cho đến khi các xác nhận của điểm phục hồi giao giao dịch con T21. Đó là vì trong
trường hợp hệ thống sự cố, kết quả của T211 và T212 là để hủy. Trên xác nhận của T21,
Giá trị prewrite được truyền tới các nhật ký riêng của định dạng (LSN, transaction-id,
object-id, priwrite value)
Để duy trì hiệu lực của điểm khôi phục giao dịch con T21 trong trường hợp hệ thống bị sự
cố, thông tin trạng thái xác nhận (commit-state) của nó mà bao gồm tất cả các biến, dữ
liệu riêng của nó và giá trị prewrite cùng với LSNs cũng được đăng nhập. Đăng nhập của
của trngj thái phục hồi được lặp lại cho đến khi giao dịch mưc trên cùng xác nhận. Khi
prewrite RM T
21
xác nhận, khóa giải phóng bởi T
21
được thừa hưởng bởi U ( an toàn để
giải phóng khóa để U ở đây kể từ khi tổ tiên của các điểm phục hồi giao dịch con,
prewrite-RM không thể được hủy bỏ trong bất kỳ trường hợp nào). Thông tin này cũng

được ghi trong lock table cũng như như đăng nhập lưu trữ ổn định. Trạng thái của giao
dịch, khóa và dirty object tabless sau xác nhận của T
21
được thể hiện trong hình 5(a)-(c).
Chú ý rằng những bảng cập nhật cũng check pointed định kì trong suốt thời gian xử lý
bình thường, giảm bớt công việc của hệ thống khởi động lại trong trường hợp hệ thống
gặp sự cố.

20
Sau xác nhận của prewrite-RM T
21
, write-TM T
2
kích hoạt write RM T
22
để ghi đối tượng dữ
liệu X và Y của giả giá prewrite được loan truyền trước đó. Write-RM T
22
tiếp tục kích hoạt
21
giao truy nhập write giao dịch con T
221
và T
222
mà lần lượt cập nhật đối tưowngj X và Y lần
cuối. Khi một cập nhật được thực hiện, bản ghi nhật kí được viết cùng với LSN và giá trị đó
của LSN cũng được đặt tại trường LSN của giá trị cập nhật của đối tượng dữ liệu như thể
hiện trong hình 6. Write-lock được giữ bởi T
221 (
T

222)
cũng được kế thừ bởi U và thông tin
được ghi lại trong lock table giống như logged trên bộ nhớ ổn định. Các trạng thái của các
bảng sau xác nhận của T
2
được thể hiện trong hình 7(a)-(c). Khi write-Tm T
2
được kích
hoạt, giao dịch daemon liên kết T
2
’ cũng được gọi tự động. Giao dịch daemon kích hoạt
tranfer-RM T’
23´
mà tiếp tục kích hoạt các giao dịch con truy cập truyền T’
231
và T’
232
để lần
lượt truyền các giá trị cập nhật của đối tượng X và Y tới stable-db. Thông tin các giao dịch
được kích hoạt cũng ddowcj ghi trong lock table. Khi việc truyền của đối tượng gữ liệu giá
trị của X và Y từ write buffer tới stable-db được hàn tất, mục tương ứng từ dirty object
table cũng như từ nhật ký cũng được hủy luôn. Khi bất cứ giao dịch chỉ đọc T
1,
T
11
và T
111
được kích hoạt, thông tin được ghi trong bảng giao dịch. Giống như khi đọc một read-lock
được thừa nhận hoặc hủy bỏ, lock table cũng ddowcj cập nhât. Tuy nhiên thông tin này
chưa được lưu trũ ổn định giống như những mà dịch mà để hủy bỏ trong trường hợp hệ

thống gặp sự cố. Khi giao dịch cao nhất U xác nhận. tất cả các mục tương ứng bị hủy từ
bảng và nhật ký.
5.1. Xử lý khởi động lại hệ thống
5.1.1 Xử lý Bước phân tích
Dưới đây là một cho thấy bước phân tích hoạt động như thế nào đưa ra trong mục được
thực hiện. Giả sử trong bộ nhớ ổn định, các bảng đang ở trong trạng thái giống như trong
hình 7(a)-(c) và nhật ký dẫn ra các mục sau lần checkpoint cuối cùng bản ghi tịa thời
điểm hệ thống sự cố.
Trên hệ thống khởi động lại, tác tử bên ngoài kích hoạt một analysis-TM để thao tác bước
phân tích (hình 8). Analysis-TM gọi analysis-RM T
aa
tại giao dịch ở cấp tiếp theo trong hệ
thống giao dịch. Analysis-RM tiếp tục kích hoạt các giao dịch con truy cập copy, read và
read-analysis. Giao dịch copy T
ci
(i=1,3) copy tất cả các bảng từ bộ nhớ ổn định vào trong
bộ nhớ tạm thời. Giao dịch đọc T
ri
(i=1,4) đọc từng bản ghi nhật ký một từ các nhật lý
tương ứng tói mối đối tượng dữ liệu và nhật ký chúng. Truy cập ghi tương ứng (i=1,4) cập
nhật các bảng như sau: từ các mục ducar cacsc bản ghi nhật ký dạng cơ sở dũ liệu không
có trong dirty object table; do đó các mục được đưa vào trong bản. Tương tự ,các bảng
khác cũng được cập nhật. Ngoài ra T
221
đã xác nhận mục tương ứng trong bảo giao dịch
được hủy bỏ. Các read-analysis trả lại RecLSN (RedoLSN) nhỏ nhất của 102 cho hoạt động
22
ghi của đối tượng dữ liệu X và RecLSN (RedoLSN) của 101 cho hoạt động prewrite của đối
tượng dữ liệu Y. Nó cũng trả lại thông tin mà U và T
2

đang hoạt động giao dịch cùng với
khóa nắm giữ thông tin về giao dịch đó. Các giao dịch này sẽ được khởi động lại như
recovery point suctrasaction T
21
của chúng đã xác nhận.
5.1.1.1. Điều khiển tương tranh bằng bước phân tích
Để giải thích điều khiển tương tranh giữa các giao dịch truy cập của bước phân tích,
Chúng tôi giả định rằng có một giao dịch con truy cập copy, một giao dịch con truy cập
read, một write và một read analysis . Các truy cập copy, read và read analysis yêu cầu một
read-lock trước khi truy cập một DM trong khi truy cập write yêu cầu write-lock trước khi
truy cập một DM. Khi một giao dịch truy nhập xác nhận, khóa được truyền tới giao dịch
cah của chúng. Khi một giao dịch không truy cập, khó của chúng được chuyển tới tác tử
ngoài. Khi một giao dịch hủy, khóa của chúng được gửi tới giao dịch ma mà không hủy bỏ
kết quả của giao dịch bị hủy. Trong trường hợp hệ thống sự số, analysis pass được khởi
động lại. Trong trường hợp một giao dịch hủy, một giao dịch mới có thể được kích hoạt.
Các quy định khóa giống như đưa ra cho hệ thống hoạt động bình thường như trong 3.1
5.1.2 Xử lý bước redo
Trong mục này, chúng tôi giải thích các thao tác bước redo trong mục 4 với sự trợ giúp
của các ví dụ cho dưới đây. Xem xét các bản ghi nhật ký cơ sở dữ liệu tương ứng với các
đối tượng dữ liệu tại thời điểm lỗi hệ thống
23
Giả sử RedoLSN của đối tượng dữ liệu X đối với các hoạt động write trong bảng dirty
object được tổ chức lại là 222. Để RecLSN( RedoLSN) min của các thao tác prewrite mà
lớn hơn RecLSNs max của các thao tác ghi trong bảng dirty object là 225. Xem xét hình 9
Trong suốt thao tác redo, giao dịch redo-TM T
s
kích hoạt một giao dịch redo-RM T
s1

trong khởi đọng kích hoạt một giao dịch copy T

c
mà kcish hoạt lại write buffer của đối
tượng dữ liệu X bằng cách sao chép giá trị của nó từ stable-db cùng với LSN. Nó đặt
stableLSN của nó và trường LSN để bằng với LSN của stable-db. Sau xác nhận của nó, giá
trị trong write-buffer sẽ trở thành x2 với LSN 222. Sau đó T
s1
kích hoạt một giao dịch con
truy cập read T
r1
với RecLSN 222. Nó đọc cơ sở dữ liệu bản ghi nhật ký write của LSN mà
lớn hơn hoặc bằng 222. Tương tự như vậy T
r2
và T
r3
được kcihs hoạt để lần lượt đọc các
mục nhật ký write và prewrite. Giao dịch con truy nhập write T
w1
được gọi bởi T
s1
thế chỗ
giá trị write-buffer của đối tượng dữ liệu X bằng x
2
nếu LSN của bản ghi nhật ký lớn hơn
stableLSN của đối tượng trong writer-buffer. LSN(222) của bản ghi nhật ký không lớn hơn
stableLSN(222) của đối tượng trong write-buffer và do đó T
w
xác nhận mà không cần cập
nhật giá trị trong write-buffer với việc trả lại thông điệp “not to be redone” (Không được
hoàn tác) . T
s1

sau đó sẽ kích hoạt giao dịch con truy cập write T
w2
tiếp theo thay thế các
writebuffer của đối tượng bằng x
3
như LSN(224) của nó lớn hơn stableLSN(222). T
s1
cũng
đồng thời kích hoạt một giao dịch con truy cập prewrite T
p
để kích hoạt lại giá trị prewrite
trong prewrite-bufer nếu giá trị LSN của bản ghi nhật ký prewrite lớn hơn Giá trị max
RecLSN của tất các thao tác write. T
p
kích hoạt lại một prewrite buffer với giá trị prewrite
x, như giá trị LSN(225) là lớn hơn giá trị max RecLSN 224 của tất cả thao tác ghi. Trong
suốt thời gia của thao tác redo, giao dịch daemon T’
s
kết hợp vớiT
s
cũng được gọi tự động.
T
s
trong việc khởi động kích hoạt một giao dịch con truy cập transfer để truyền nội dung
của write-buffer của đối tượng dữ liệu tới stable-db. T
t
là giao dịch mà đối tượng dữ liệu
truyền giá trị write-bufer của X nếu LSN của nó lớn hơn stable-LSN của đối tượng dữ liệu
trong write-buffer.
24

5.1.2.1. Điều khiển tương tranh cho bước redo .
Xem xét hình 9. Nơi T
s
là một redo-TM và T’
s
là giao dịch daemon kết hợp. T
s1
và T’
s1
lần lượt
là redo-RMs và transfer-RM. T
c,
{T
r1,
T
r2
} , T
p
và T
t
lần lượt là ký hiệu các giao dịch con
truy cập copy, read, prewrite và transfer . Trong ví dụ này, để đơn giản chúng ta đã giả sử
rằng chỉ đọc một bản ghi nhật ký write và prewrite. Giống như trươc, copy, read và
transfer yều cầu truy cập read-lock trong khi truy cập prewrite và write lần lượt yêu cầu
prewrite-lock và write-lock. Khi một giao dịch con truy cập xác nhận, khóa của nó truyền
tới cha mẹ của nó và như vậy ngoại trừ việc các truy cập write và transfer gửi khóa của
mình tới tác tử ngoài . Khi một giao dịch hủy khóa của nó được gửi tới cha mẹ chúng. Các
quy định khóa giống như trong 3.1.
6. Kết luận
Một mô hình giao dịch lồng, các thuật toán điều khiển tương tranh và phục hồi của nó đã

được trình bày trong bài báo này. Chúng ta đã giới thiệu nội dung của một điểm phục hồi
giao dịch và thao tác prewrite trong mô hình cho phép tương tranh cao. Thuật toán phục
hồi bào gồm các thao tác khởi động lại hệ thông ; các thao tác phân tích và phục hồi và các
thao tác quản lý bộ đệm, mà được mô hình hóa trong khuôn khổ của mô hình giao dịch
lồng. Mô hình hóa các chức năng phục hồi trong khuôn khổ các giao dịch con tăng tính
đồng thời trong suốt quá trình khởi động lại hệ thống. Trong tương lai mô hình này cần
phải mở rộng ra trong môi trường phát triển nhanh chóng của ngôn ngữ lập trình
25

×