Phần lớn mã T-SQL sản xuất được viết với giả định ngầm định rằng dữ liệu cơ bản sẽ không thay đổi trong quá trình thực thi. Như chúng ta đã thấy trong phần trước của loạt bài này, đây là một giả định không an toàn vì dữ liệu và các mục nhập chỉ mục có thể di chuyển bên dưới chúng ta, ngay cả trong khi thực thi một câu lệnh.
Trong trường hợp lập trình viên T-SQL nhận thức được các loại vấn đề về tính đúng đắn và toàn vẹn dữ liệu có thể phát sinh do các quá trình khác sửa đổi dữ liệu đồng thời, thì giải pháp thường được đưa ra là gói các câu lệnh dễ bị tấn công trong một giao dịch. Không rõ bằng cách nào mà cùng một kiểu suy luận sẽ được áp dụng cho trường hợp câu lệnh đơn, theo mặc định, đã được bao bọc trong một giao dịch tự động cam kết.
Bỏ điều đó sang một bên, ý tưởng bảo vệ một khu vực quan trọng của mã T-SQL với một giao dịch dường như dựa trên sự hiểu lầm về các biện pháp bảo vệ được cung cấp bởi các thuộc tính giao dịch ACID. Yếu tố quan trọng của từ viết tắt đó cho cuộc thảo luận hiện tại là Sự cô lập bất động sản. Ý tưởng là việc sử dụng một giao dịch tự động cung cấp sự cách ly hoàn toàn khỏi các tác động của các hoạt động đồng thời khác.
Sự thật của vấn đề là các giao dịch dưới SERIALIZABLE chỉ cung cấp mức độ của sự cô lập, phụ thuộc vào mức cô lập giao dịch hiệu quả hiện tại. Để hiểu tất cả những điều này có ý nghĩa như thế nào đối với T hàng ngày của chúng ta Thực hành mã hóa SQL, trước tiên chúng ta sẽ xem xét chi tiết mức cô lập có thể tuần tự hóa.
Cách ly có thể nối tiếp hóa
Serializable là mức cô lập nhất trong các mức cô lập giao dịch tiêu chuẩn. Nó cũng là mặc định mức cô lập được chỉ định bởi tiêu chuẩn SQL, mặc dù SQL Server (giống như hầu hết các hệ thống cơ sở dữ liệu thương mại) khác với tiêu chuẩn về mặt này. Mức cô lập mặc định trong SQL Server được cam kết đọc, mức cô lập thấp hơn mà chúng ta sẽ khám phá ở phần sau của loạt bài này.
Định nghĩa về mức cách ly có thể tuần tự hóa trong tiêu chuẩn SQL-92 chứa văn bản sau (tôi nhấn mạnh):
Một thực thi có thể tuần tự hóa được định nghĩa là một thực thi các hoạt động thực thi đồng thời các giao dịch SQL tạo ra hiệu ứng tương tự như một số thực thi nối tiếp của các giao dịch SQL tương tự đó. Thực thi nối tiếp là một thực thi trong đó mỗi giao dịch SQL thực thi để hoàn thành trước khi giao dịch SQL tiếp theo bắt đầu.
Có một sự khác biệt quan trọng cần được thực hiện ở đây giữa thực sự được đăng nhiều kỳ thực thi (trong đó mỗi giao dịch thực sự chỉ chạy để hoàn thành trước khi giao dịch tiếp theo bắt đầu) và có thể tuần tự hóa cô lập, trong đó các giao dịch chỉ được yêu cầu để có tác dụng tương tự như thể chúng được thực hiện tuần tự (theo một số thứ tự không xác định).
Nói một cách khác, hệ thống cơ sở dữ liệu thực được phép chồng chéo về mặt vật lý việc thực hiện các giao dịch có thể tuần tự hóa trong thời gian (do đó tăng tính đồng thời) miễn là ảnh hưởng của các giao dịch đó vẫn tương ứng với một số thứ tự thực hiện nối tiếp có thể có. Nói cách khác, các giao dịch có thể tuần tự hóa có khả năng được tuần tự hóa chứ không phải là thực sự được đăng nhiều kỳ .
Các giao dịch có thể tuần tự hóa một cách hợp lý
Bỏ qua tất cả các cân nhắc vật lý (như khóa) trong giây lát và chỉ nghĩ về việc xử lý hợp lý của hai giao dịch có thể tuần tự hóa đồng thời.
Hãy xem xét một bảng có chứa một số lượng lớn các hàng, năm trong số đó xảy ra để đáp ứng một số vị từ truy vấn thú vị. Một giao dịch có thể tuần tự hóa T 1 bắt đầu đếm số hàng trong bảng phù hợp với vị từ này. Một thời gian sau T 1 bắt đầu, nhưng trước khi nó cam kết, một giao dịch có thể tuần tự hóa thứ hai T 2 bắt đầu. Giao dịch T 2 thêm bốn hàng mới cũng đáp ứng vị từ truy vấn vào bảng và cam kết. Biểu đồ dưới đây cho thấy chuỗi thời gian của các sự kiện:
Câu hỏi đặt ra là truy vấn nên có bao nhiêu hàng trong giao dịch có thể tuần tự hóa T 1 đếm? Hãy nhớ rằng chúng tôi đang suy nghĩ hoàn toàn về các yêu cầu logic ở đây, vì vậy hãy tránh suy nghĩ về việc khóa nào có thể được thực hiện, v.v.
Hai giao dịch trùng lặp về mặt vật lý về thời gian, điều này không sao cả. Cách ly có thể nối tiếp hóa chỉ yêu cầu kết quả của hai giao dịch này tương ứng với một số thực thi nối tiếp có thể xảy ra. Rõ ràng có hai khả năng cho một lịch trình giao dịch nối tiếp hợp lý T 1 và T 2 :
Sử dụng lịch trình nối tiếp đầu tiên có thể có (T 1 sau đó T 2 ) T 1 truy vấn đếm sẽ thấy năm hàng , bởi vì giao dịch thứ hai không bắt đầu cho đến khi giao dịch đầu tiên hoàn thành. Sử dụng lịch trình hợp lý có thể có thứ hai, T 1 truy vấn sẽ đếm chín hàng , bởi vì chèn bốn hàng đã hoàn thành một cách hợp lý trước khi giao dịch đếm bắt đầu.
Cả hai câu trả lời đều đúng về mặt logic trong điều kiện cách ly có thể nối tiếp hóa. Ngoài ra, không thể có câu trả lời nào khác (vì vậy giao dịch T 1 không thể đếm bảy hàng, ví dụ). Kết quả nào trong số hai kết quả có thể được thực sự quan sát được phụ thuộc vào thời gian chính xác và một số chi tiết triển khai cụ thể cho công cụ cơ sở dữ liệu đang sử dụng.
Lưu ý rằng chúng tôi không kết luận rằng các giao dịch thực sự được sắp xếp lại theo thời gian bằng cách nào đó. Quá trình thực thi vật lý không bị trùng lặp như thể hiện trong sơ đồ đầu tiên, miễn là công cụ cơ sở dữ liệu đảm bảo kết quả phản ánh những gì sẽ xảy ra nếu chúng được thực thi theo một trong hai trình tự nối tiếp có thể có.
Có thể nối tiếp và Hiện tượng đồng thời
Ngoài tuần tự hóa lôgic, tiêu chuẩn SQL cũng đề cập rằng một giao dịch hoạt động ở mức cô lập có thể tuần tự hóa không được gặp một số hiện tượng đồng thời nhất định. Nó không được đọc dữ liệu không được cam kết (không có số lần đọc bẩn ); và khi dữ liệu đã được đọc, việc lặp lại cùng một thao tác phải trả về chính xác cùng một tập dữ liệu ( lần đọc có thể lặp lại không có bóng ma ).
Tiêu chuẩn đưa ra quan điểm khi nói rằng những hiện tượng đồng thời đó được loại trừ ở mức cô lập có thể nối tiếp hóa như một hệ quả trực tiếp yêu cầu giao dịch phải được tuần tự hóa một cách hợp lý. Nói cách khác, yêu cầu về khả năng tuần tự hóa là tự nó đủ để tránh hiện tượng đọc bẩn, đọc không lặp lại và hiện tượng đồng thời ảo. Ngược lại, chỉ tránh ba hiện tượng đồng thời là không đủ để đảm bảo khả năng tuần tự hóa, như chúng ta sẽ thấy ngay sau đây.
Theo trực giác, các giao dịch có thể tuần tự hóa tránh tất cả các hiện tượng liên quan đến đồng thời vì chúng được yêu cầu hoạt động như thể chúng đã được thực hiện hoàn toàn cách ly. Theo nghĩa đó, mức cô lập giao dịch có thể tuần tự hóa phù hợp với mong đợi chung của các lập trình viên T-SQL khá chặt chẽ.
Triển khai có thể nối tiếp hóa
SQL Server tình cờ sử dụng triển khai khóa của mức cách ly có thể tuần tự hóa, nơi các khóa vật lý được thu nhận và được giữ đến cuối giao dịch (do đó, gợi ý bảng không được dùng nữa HOLDLOCK như một từ đồng nghĩa với SERIALIZABLE ).
Chiến lược này không hoàn toàn đủ để cung cấp đảm bảo kỹ thuật về khả năng tuần tự hóa đầy đủ, vì dữ liệu mới hoặc đã thay đổi có thể xuất hiện trong một loạt các hàng được xử lý trước đó bởi giao dịch. Hiện tượng đồng thời này được gọi là bóng ma và có thể dẫn đến các hiệu ứng không thể xảy ra trong bất kỳ lịch trình nối tiếp nào.
Để đảm bảo bảo vệ chống lại hiện tượng đồng thời ảo, các khóa do Máy chủ SQL thực hiện ở mức cách ly có thể tuần tự hóa cũng có thể kết hợp khóa phạm vi khóa để ngăn các hàng mới hoặc đã thay đổi xuất hiện giữa các giá trị khóa chỉ mục đã được kiểm tra trước đó. Khóa phạm vi không phải luôn luôn có được dưới mức cách ly có thể nối tiếp hóa; tất cả những gì chúng ta có thể nói chung là SQL Server luôn có đủ khóa để đáp ứng các yêu cầu logic của mức cô lập có thể tuần tự hóa. Trên thực tế, việc triển khai khóa thường thu được nhiều hơn, và khóa chặt chẽ hơn mức thực sự cần thiết để đảm bảo khả năng tuần tự hóa, nhưng tôi lạc đề.
Khóa chỉ là một trong những cách triển khai vật lý có thể có của mức cách ly có thể nối tiếp hóa. Chúng ta nên cẩn thận tách biệt các hành vi cụ thể của việc triển khai khóa SQL Server khỏi định nghĩa logic của serializable.
Là một ví dụ về chiến lược vật lý thay thế, hãy xem việc triển khai PostgreSQL về cách ly ảnh chụp nhanh có thể tuần tự hóa, mặc dù đây chỉ là một phương án thay thế. Tất nhiên, mỗi cách thực hiện vật lý khác nhau đều có điểm mạnh và điểm yếu riêng. Ngoài ra, hãy lưu ý rằng Oracle vẫn không cung cấp việc triển khai hoàn toàn tuân thủ mức cô lập có thể tuần tự hóa. Nó có mức cô lập có tên có thể tuần tự hóa, nhưng nó không thực sự đảm bảo rằng các giao dịch sẽ thực hiện theo một số lịch trình nối tiếp có thể có. Thay vào đó, Oracle cung cấp tính năng cách ly ảnh chụp nhanh khi có thể tuần tự hóa được yêu cầu, giống như cách mà PostgreSQL đã làm trước khi cô lập ảnh chụp nhanh có thể tuần tự hóa ( SSI ) đã được triển khai.
Cách ly ảnh chụp nhanh không ngăn chặn các dị thường đồng thời như lệch ghi, điều này không thể xảy ra trong điều kiện cách ly có thể tuần tự hóa thực sự. Nếu bạn quan tâm, bạn có thể tìm thấy các ví dụ về ghi xiên và các hiệu ứng đồng thời khác được cho phép bằng cách cô lập ảnh chụp nhanh tại liên kết SSI ở trên. Chúng ta cũng sẽ thảo luận về việc triển khai SQL Server mức cô lập ảnh chụp nhanh ở phần sau của loạt bài này.
Chế độ xem thời điểm?
Một lý do mà tôi đã dành thời gian nói về sự khác biệt giữa khả năng tuần tự hóa hợp lý và thực thi tuần tự hóa vật lý là do có thể dễ dàng suy ra các đảm bảo có thể không thực sự tồn tại. Ví dụ:nếu bạn nghĩ về các giao dịch có thể tuần tự hóa là thực tế thực hiện lần lượt, bạn có thể suy ra rằng một giao dịch có thể tuần tự hóa nhất thiết sẽ thấy cơ sở dữ liệu như nó đã tồn tại khi bắt đầu giao dịch, cung cấp chế độ xem theo thời điểm.
Trên thực tế, đây là một chi tiết dành riêng cho việc triển khai. Nhớ lại ví dụ trước, trong đó giao dịch có thể tuần tự hóa T 1 có thể đếm hợp pháp năm hoặc chín hàng. Nếu số lượng là chín được trả về, giao dịch đầu tiên sẽ nhìn thấy rõ ràng các hàng không tồn tại tại thời điểm giao dịch bắt đầu. Kết quả này có thể xảy ra trong SQL Server nhưng không có trong PostgreSQL SSI, mặc dù cả hai triển khai đều tuân thủ các hành vi logic được chỉ định cho mức cô lập có thể tuần tự hóa.
Trong SQL Server, các giao dịch có thể tuần tự hóa không nhất thiết phải xem dữ liệu như nó đã tồn tại khi bắt đầu giao dịch. Thay vào đó, các chi tiết của việc triển khai SQL Server có nghĩa là một giao dịch có thể tuần tự hóa sẽ thấy dữ liệu được cam kết mới nhất, kể từ thời điểm dữ liệu bị khóa để truy cập lần đầu tiên. Ngoài ra, tập hợp dữ liệu được cam kết mới nhất được đọc cuối cùng được đảm bảo không thay đổi tư cách thành viên trước khi giao dịch kết thúc.
Lần tới
Phần tiếp theo của loạt bài này kiểm tra mức cách ly đọc lặp lại, mức này cung cấp các đảm bảo cách ly giao dịch yếu hơn mức có thể tuần tự hóa.
[Xem chỉ mục cho toàn bộ chuỗi]
