Course All lectures for VI purposes - Lecture: Mức cô lập giao dịch

2.1 Đọc không cam kết

"Mức cô lập giao dịch" đề cập đến mức độ bảo vệ được cung cấp bởi các cơ chế nội bộ của DBMS (nghĩa là không yêu cầu lập trình đặc biệt) khỏi tất cả hoặc một số loại dữ liệu không nhất quán xảy ra trong quá trình thực hiện song song các giao dịch. Tiêu chuẩn SQL-92 xác định thang đo gồm bốn mức cô lập:

Đọc không cam kết
Đọc cam kết
đọc lặp lại
tuần tự hóa

Cái đầu tiên là yếu nhất, cái cuối cùng là mạnh nhất, mỗi cái tiếp theo bao gồm tất cả những cái trước đó.

Mức cô lập thấp nhất (đầu tiên). Nếu một số giao dịch song song cố gắng sửa đổi cùng một hàng trong bảng, thì hàng cuối cùng sẽ có giá trị được xác định bởi toàn bộ tập hợp các giao dịch đã hoàn tất thành công. Trong trường hợp này, có thể đọc không chỉ dữ liệu không nhất quán về mặt logic mà cả dữ liệu chưa ghi lại các thay đổi.

Một cách điển hình để thực hiện mức cô lập này là khóa dữ liệu trong khi lệnh thay đổi đang được thực thi, điều này đảm bảo rằng các lệnh sửa đổi trên cùng một hàng chạy song song thực sự được thực hiện tuần tự và không có thay đổi nào bị mất. Các giao dịch chỉ đọc không bao giờ bị chặn dưới mức cô lập này.

2.2 Đọc cam kết

Hầu hết các DBMS công nghiệp, cụ thể là Microsoft SQL Server, PostgreSQL và Oracle, sử dụng mức này theo mặc định. Ở cấp độ này, khả năng bảo vệ chống lại bản nháp, khả năng đọc "bẩn" được cung cấp, tuy nhiên, trong quá trình thực hiện một giao dịch, một giao dịch khác có thể được hoàn thành thành công và những thay đổi do giao dịch đó thực hiện được khắc phục. Do đó, giao dịch đầu tiên sẽ hoạt động với một tập dữ liệu khác.

Việc triển khai đọc hoàn chỉnh có thể dựa trên một trong hai cách tiếp cận: chặn hoặc tạo phiên bản.

Chặn dữ liệu có thể đọc và có thể thay đổi.

Nó bao gồm thực tế là giao dịch viết chặn dữ liệu có thể thay đổi để đọc các giao dịch hoạt động ở mức đọc đã cam kết hoặc cao hơn cho đến khi nó hoàn thành, do đó ngăn chặn việc đọc "bẩn" và dữ liệu bị khóa bởi giao dịch đọc được giải phóng ngay sau khi hoàn thành thao tác SELECT(do đó, tình huống "đọc không thể lặp lại" có thể xảy ra ở một mức cô lập nhất định).

Lưu nhiều phiên bản của các hàng thay đổi song song.

Mỗi khi một hàng được thay đổi, DBMS sẽ tạo một phiên bản mới của hàng này, trong đó giao dịch đã thay đổi dữ liệu tiếp tục hoạt động, trong khi bất kỳ giao dịch “đọc” nào khác trả về phiên bản đã cam kết cuối cùng. Ưu điểm của phương pháp này là nhanh hơn vì nó ngăn chặn. Tuy nhiên, so với cái đầu tiên, nó đòi hỏi mức tiêu thụ RAM lớn hơn đáng kể, được dành cho việc lưu trữ các phiên bản hàng.

Ngoài ra, khi nhiều giao dịch thay đổi dữ liệu song song, nó có thể tạo ra tình huống trong đó một số giao dịch đồng thời thực hiện các thay đổi không nhất quán đối với cùng một dữ liệu (vì không có khóa nên sẽ không có gì ngăn cản điều này xảy ra). Sau đó, giao dịch thực hiện trước sẽ lưu các thay đổi của nó trong cơ sở dữ liệu chính và các giao dịch song song còn lại sẽ không thể thực hiện được (vì điều này sẽ dẫn đến mất cập nhật của giao dịch đầu tiên). Điều duy nhất mà DBMS có thể làm trong tình huống như vậy là khôi phục phần còn lại của các giao dịch và đưa ra thông báo lỗi “Bản ghi đã được thay đổi”.

Một phương pháp triển khai cụ thể được lựa chọn bởi các nhà phát triển DBMS và trong một số trường hợp, nó có thể được tùy chỉnh. Vì vậy, theo mặc định, MS SQL sử dụng khóa, nhưng (trong phiên bản 2005 trở lên) khi cài đặt tham READ_COMMITTED_SNAPSHOTsố cơ sở dữ liệu, nó chuyển sang chiến lược lập phiên bản, Oracle ban đầu chỉ hoạt động theo sơ đồ được lập phiên bản. Trong Informix, bạn có thể ngăn xung đột giữa các giao dịch đọc và ghi bằng cách đặt tùy chọn cấu hình USELASTCOMMITTED(kể từ phiên bản 11.1) khiến giao dịch đọc nhận dữ liệu được cam kết mới nhất.

2.3 Đọc lặp lại

Mức độ mà một giao dịch đọc "không nhìn thấy" thay đổi dữ liệu mà nó đã đọc trước đó. Đồng thời, không có giao dịch nào khác có thể thay đổi dữ liệu được đọc bởi giao dịch hiện tại cho đến khi nó kết thúc.

Khóa ở chế độ chia sẻ được áp dụng cho tất cả dữ liệu được đọc bởi bất kỳ hướng dẫn nào trong giao dịch và được giữ cho đến khi giao dịch hoàn tất. Điều này ngăn các giao dịch khác sửa đổi các hàng đã được đọc bởi giao dịch đang chờ xử lý. Tuy nhiên, các giao dịch khác có thể chèn các dòng mới phù hợp với các điều kiện tìm kiếm cho các hướng dẫn có trong giao dịch hiện tại. Khi câu lệnh được khởi động lại bởi giao dịch hiện tại, các hàng mới sẽ được tìm nạp, dẫn đến đọc ảo.

Cho rằng các khóa dùng chung được giữ cho đến khi kết thúc giao dịch, thay vì được giải phóng ở cuối mỗi câu lệnh, mức độ đồng thời thấp hơn mức cô lập READ COMMITTED. Do đó, thông thường không nên sử dụng cấp độ giao dịch này và cao hơn một cách không cần thiết.

2.4 Có thể tuần tự hóa

Mức độ cô lập cao nhất; các giao dịch hoàn toàn tách biệt với nhau, mỗi giao dịch được thực hiện như thể không có giao dịch song song. Chỉ ở cấp độ này, các giao dịch đồng thời không chịu hiệu ứng "đọc ảo".

2.5 Hỗ trợ cách ly giao dịch trong DBMS thực

DBMS giao dịch không phải lúc nào cũng hỗ trợ cả bốn cấp độ và cũng có thể giới thiệu các cấp độ bổ sung. Ngoài ra còn có các sắc thái khác nhau trong việc cung cấp vật liệu cách nhiệt.

Vì vậy, về nguyên tắc, Oracle không hỗ trợ mức 0, vì việc triển khai các giao dịch của nó không bao gồm "đọc bẩn" và chính thức không cho phép đặt mức đọc lặp lại, tức là nó chỉ hỗ trợ ( theo mặc định) Read committedvà Serializable. Đồng thời, ở cấp độ các lệnh riêng lẻ, nó thực sự đảm bảo khả năng đọc lặp lại (nếu một lệnh SELECTtrong giao dịch đầu tiên chọn một tập hợp các hàng từ cơ sở dữ liệu và tại thời điểm này, giao dịch thứ hai song song sẽ thay đổi một số hàng này, thì tập hợp kết quả mà giao dịch đầu tiên nhận được sẽ chứa các hàng không thay đổi, như thể không có giao dịch thứ hai). Oracle cũng hỗ trợ cái gọi là READ-ONLYgiao dịch, tương ứng với Serializable, nhưng không thể tự thay đổi dữ liệu.

Và Microsoft SQL Server hỗ trợ tất cả bốn cấp độ cách ly giao dịch tiêu chuẩn và ngoài ra, cấp độ SNAPSHOT, tại đó giao dịch nhìn thấy trạng thái dữ liệu đã được cam kết trước khi nó được khởi chạy, cũng như các thay đổi do chính nó thực hiện, nghĩa là nó hoạt động như nếu nó nhận được khi khởi động, ảnh chụp nhanh dữ liệu DB và hoạt động với nó. Sự khác biệt so với Serialized là không có khóa nào được sử dụng, nhưng kết quả là, việc thực hiện các thay đổi có thể không thực hiện được nếu một giao dịch đồng thời đã thay đổi cùng một dữ liệu trước đó; trong trường hợp này, giao dịch thứ hai khi cố gắng thực hiện COMMITsẽ đưa ra thông báo lỗi và bị hủy bỏ.