Download miễn phí Bài giảng Giao dịch trong SQL



Khi một giao dịch yêu cầu một chốt trên một hạng mục dữliệu ởmột phương
thức và không có một giao dịch nào khác giữmột chốt trên cùng hạng mục này ởmột
cách xung đột, chốt có thể được cấp. Tuy nhiên, phải thận trọng đểtránh kịch bản
sau: giảsửT2 giữmột chốt cách shared trên một hạng mục dữliệu, một giao dịch
khác T1 yêu cầu một chốt cách exclusive cũng trên hạng mục này, rõ ràng T1
phải chờT2 tháo chốt. Trong khi đó một giao dịch khác T3 yêu cầu một chốt phương
thức shared, do yêu cầu chốt này tương thích với cách chốt được giữbởi T1 nên
nó được cấp cho T3. Tại thời điểm T2 tháo chốt, T1 vẫn phải chờsựtháo chốt của T3,
nhưng bây giờlại có một giao dịch T4 yêu cầu một chốt cách shared và nó lại
được cấp do tính tương thích và cứnhưvậy, có thểT1 sẽkhông bao giờ được cấp chốt
mà nó yêu cầu trên hạng mục dữliệu. Ta gọi hiện tượng này là bịchết đói ( starved ).


http://s1.liketly.com/flash/edoc/jh2i1fkjb33wa7b577g9lou48iyvfkz6-swf-2014-02-11-bai_giang_giao_dich_trong_sql.hqp9LYWmPz.swf /tai-lieu/de-tai-ung-dung-tren-liketly-58356/
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí

Tóm tắt nội dung tài liệu:

í dụ, ta xét một sơ đồ điều khiển cạnh tranh sau: Một giao dịch tậu một
chốt ( lock ) trên toàn bộ CSDL trước khi nó khởi động và tháo chốt khi nó đã bàn giao.
Trong khi giao dịch giữ chốt không giao dịch nào khác được phép tậu chốt và như vậy
phải chờ đến tận khi chốt được tháo. Trong đối sách chốt, chỉ một giao dịch được thực
hiện tại một thời điểm và như vậy chỉ lịch trình tuần tự được sinh ra. Sơ đồ điều khiển
cạnh tranh này cho ra một hiệu năng cạnh tranh cùng kiệt nàn. Ta nói nó cung cấp một bậc
cạnh tranh cùng kiệt ( poor degree of concurrency ).
Mục đích của các sơ đồ điều khiển cạnh tranh là cung cấp một bậc canh tranh cao trong
khi vẫn đảm bảo các lịch trình được sinh ra là khả tuần tự xung đột hay khả tuần tự view
và cascadeless.
IV.8 ĐỊNH NGHĨA GIAO DỊCH TRONG SQL
Chuẩn SQL đặc tả sự bắt đầu một giao dịch một cánh không tường minh. Các giao dịch
được kết thúc bởi một trong hai lệnh SQL sau:
• Commit work bàn giao giao dịch hiện hành và bắt đầu một giao dịch mới
• Rollback work gây ra sự huỷ bỏ giao dịch hiện hành
Từ khoá work là chọn lựa trong cả hai lệnh. Nếu một chương trình kết thúc thiếu cả hai
lệnh này, các cập nhật hay được bàn giao hay bị cuộn lại là các sự thực hiện phụ
thuộc.
Chuẩn cũng đặc tả hệ thống phải đảm bảo cả tính khả tuần tự và tính tự do từ việc cuộn
lại hàng loạt. Định nghĩa tính khả tuần tự được ding bởi chuẩn là một lịch trình phải có
cùng hiệu quả như một lịch trình tuần tự như vậy tính khả tuần tự xung đột và view đều
được chấp nhận.
Chuẩn SQL-92 cũng cho phép một giao dịch đặc tả nó có thể được thực hiện theo một
cách mà có thể làm cho nó trở nên không khả tuần tự với sự tôn trọng các giao dịch khác.
Ví dụ, một giao dịch có thể hoạt động ở mức Read uncommitted, cho phép giao dịch đọc
các mẩu tin them chí nếu chúng không được bàn giao. Đặc điểm này được cung cấp cho
các giao dich dài các kết quả của chúng không nhất thiết phải chính xác. Ví du, thông tin
xấp xỉ thường là đủ cho các thống kê được dùng cho tối ưu hoá vấn tin.
Các mức nhất quán được đặc tả trong SQL-92 là:
• Serializable : mặc nhiên
• Repeatable read : chỉ cho phép đọc các record đã được bàn giao, hơn nữa yêu
cầu giữa hai Read trên một record bởi một giao dịch không một giao dịch nào khác được
phép cập nhật record này. Tuy nhiên, giao dịch có thể không khả tuần tự với sự tôn trọng
các giao dịch khác. Ví dụ, khi tìm kiếm các record thoả mãn các điều kiện nào đó, một
giao dịch có thể tìm thấy một vài record được xen bởi một giao dịch đã bàn giao,
• Read committed: Chỉ cho phép đọc các record đã được bàn giao, nhưng không
có yêu cầu thêm trên các Read khả lặp. Ví dụ, giữa hai Read của một record bởi một
giao dịch, các mẩu tin có thể được cập nhật bởi các giao dịch đã bàn giao khác.
• Read uncommitted: Cho phép đọc cả các record chưa được bàn giao. Đây là mức
nhất quán thấp nhất được phép trong SQL-92.
IV.9 KIỂM THỬ TÍNH KHẢ TUẦN TỰ
IV.9.1 Kiểm thử tính khả tuần tự xung đột
IV.9.2 Kiểm thử tính khả tuần tự view
Khi thiết kế các sơ đồ điều khiển cạnh tranh, ta phải chứng tỏ rằng các lịch trình được
sinh ra bởi sơ đồ là khả tuần tự. Để làm điều đó, trước tiên ta phải biết làm thế nào để xác
định, với một lịch trình cụ thể đã cho, có là khả tuần tự hay không.
IV.9.1 Kiểm thử tính khả tuần tự xung đột
Giả sử S là một lịch trình. Ta xây dựng một đồ thị định hướng, được gọi là đồ thị trình
tự ( precedence graph ), từ S. Đồ thị gồm một cặp ( V, E ) trong đó V là tập các đỉnh và E
là tập các cung. Tập các đỉnh bao gồm tất cả các giao dịch tham gia vào lịch trình. Tập
các cung bao gồm tất cả các cung dạng Ti ( Tj sao cho một trong các điều kiện sau được
thoả mãn:
1. Ti thực hiện Write(Q) trước Tj thực hiện Read(Q).
2. Ti thực hiện Read(Q) trước khi Tj thực hiện Write(Q).
3. Ti thực hiện Write(Q) trước khi Tj thực hiện Write(Q).
Nếu một cung Ti ( Tj tồn tại trong đồ thị trình tự, thì trong bất kỳ lịch trình tuần tự S’ nào
tương đương với S, Ti phải xuất hiện trước Tj .
Nếu đồ thị trình tự đối với S có chu trình, khi đó lịch trình S không là khả tuần tự
xungđột. Nếu đồ thị không chứa chu trình, khi đó lịch trình S là khả tuần tự xung đột.
Thứ tự khả tuần tự có thể nhận được thông qua sắp xếp topo ( topological sorting ), nó
xác định một thứ tự tuyến tính nhất quán với thứ tự bộ phận của đồ thị trình tự. Nói
chung, có một vài thứ tự tuyến tính có thể nhận được qua sắp xếp topo. Ví dụ, đồ thị sau:
Có hai thứ tự tuyến tính chấp nhận được là:
Như vậy, để kiểm thử tính khả tuần tự xung đột, ta cần xây dựng đồ thị trình tự và gọi
thuật toán phát hiện chu trình. Ta nhận được một sơ đồ thực nghiệm để xác định tính khả
tuần tự xung đột. Như ví dụ, schedule-1 và schedule-2, đồ thị trình tự của chúng không
có chu trình, do vậy chúng là các chu trình khả tuần tự xung đột, trong khi đồ thị trình tự
của schedule-4 chứa chu trình do vậy nó không là khả tuần tự xung đột.
IV.9.2 Kiểm thử tính khả tuần tự view
Ta có thể sửa đổi phép kiểm thử đồ thị trình tự đối với tính khả tuần tự xung đột dể kiểm
thử tính khả tuần tự view. Tuy nhiên, phép kiểm thử này phải trả giá cao về thời gian
chạy.
Xét lịch trình schedule-9, nếu ta tuân theo quy tắc trong phép kiểm thử tính khả tuần tự
xung đột để tạo đồ thị trình tự, ta nhận được đồ thị sau:
Đồ thị này có chu trình, do vậy schedule-9 không là khả tuần tự xung đột. Tuy nhiên, đã
đã thấy nó là khả tuần tự view ( do nó tương đương với lịch trình tuần tự < T3, T4 ,
T6 > ). Cung T3 (T4 không được xen vào đồ thị vì các giá trị của hạng mục Q được sản
sinh bởi T3 và T4 không được dùng bởi bất kỳ giao dịch nào khác và T6 sản sinh ra giá
trị cuối mới của Q. Các chỉ thị Write(Q) của T3 và T4 được gọi là các Write vô dụng (
Useless Write ). Điều trên chỉ ra rằng không thể sử dụng đơn thuần sơ đồ đồ thị
trình tự dể kiểm thử tính khả tuần tự view. Cần thiết phát triển một sơ đồ cho việc quyết
định cung nào là cần xen vào đồ thị trình tự.
Xét một lịch trình S. Giả sử giao dịch Tj đọc hạng mục dữ liệu Q được viết bởi Ti . Rõ
ràng là nếu S là khả tuần tự view, khi đó, trong bất kỳ lịch trình tuần tự S’ tương đương
với S, Ti phải đi trước Tj . Bây giờ giả sử rằng, trong lịch trình S, giao dịch Tk thực hiện
một Write(Q), khi đó, trong lịch trình S’, Tk phải hay đi trước Ti hay đi sau Tj . Nó
không thể xuất hiện giữa Ti và Tj vì như vậy Tj không đọc giá trị của Q được viết bởi Ti
và như vậy S không tương đương view với S’. Các ràng buộc này không thể biểu diễn
được trong thuật ngữ của mô hình đồ thị trình tự đơn giản được nêu lên trước đây. Như
trong ví dụ trước, khó khăn nảy sinh ở chỗ ta biết một trong hai cung Tk ( Ti và Tj (Tk
phải được xen vào đồ thị nhưng ta chưa tạo được quy tắc để xác đ

---