Có sự khác biệt về hiệu suất trong việc cam kết và khôi phục giao dịch chỉ đọc không?


8

Tôi mở một giao dịch (đọc lặp lại) ( BEGIN TRAN) để thực hiện một số công việc trên một số hồ sơ nhất định. Điều đầu tiên tôi làm là kiểm tra xem dữ liệu tôi cần thay đổi có trong cơ sở dữ liệu hay không. Trong một số trường hợp sẽ có và sau đó tôi tiến hành thay đổi của mình. Nhưng trong một số trường hợp sẽ không có gì để làm. Trong trường hợp này, tôi hoặc COMMIT TRANhoặc ROLLBACK TRANtrở về từ thủ tục được lưu trữ. Tại thời điểm này, không có thay đổi nào được thực hiện đối với dữ liệu, do đó, hiệu quả của cam kết và khôi phục là như nhau.

Có bất kỳ cân nhắc nào tôi nên biết về việc lựa chọn giữa cam kết và rollback không? Có chi phí hiệu suất khác nhau? Những ý kiến ​​khác?

Câu trả lời:


10

Đã chạy nó thông qua một phiên gỡ lỗi (để làm mới bộ nhớ bị lỗi của tôi):

  • Rollback thực hiện nhiều kiểm tra hơn một cam kết, nhưng nó không dẫn đến công việc bổ sung hoặc có ảnh hưởng đáng chú ý đến hiệu suất trong tình huống bạn mô tả.
  • Giao dịch đọc-ghi không thực sự bắt đầu trừ khi và cho đến khi sửa đổi dữ liệu được thực hiện.

Bạn có thể thấy nhiều điều này bằng cách sử dụng DMV, ví dụ:

-- Temporary procedure to show the state of the transaction
CREATE PROCEDURE #TranState
    @Comment varchar(100)
AS
BEGIN
    SELECT 
        @Comment AS Comment,
        DTCT.transaction_id,
        database_name =
            CASE DTDT.database_id
                WHEN 32767 THEN N'resource'
                ELSE DB_NAME(DTDT.database_id)
            END,
        tran_begin_time = DTDT.database_transaction_begin_time,
        tran_type =
            CASE DTDT.database_transaction_type
                WHEN 1 THEN 'read/write'
                WHEN 2 THEN 'read only'
                WHEN 3 THEN 'system'
            END,
        tran_state =
            CASE DTDT.database_transaction_state
                WHEN 1 THEN 'The transaction has not been initialized.'
                WHEN 3 THEN 'The transaction has been initialized but has not generated any log records.'
                WHEN 4 THEN 'The transaction has generated log records.'
                WHEN 5 THEN ' The transaction has been prepared.'
                WHEN 10 THEN 'The transaction has been committed.'
                WHEN 11 THEN 'The transaction has been rolled back.'
                WHEN 12 THEN 'The transaction is being committed. In this state the log record is being generated, but it has not been materialized or persisted.'
            END
    FROM sys.dm_tran_current_transaction AS DTCT
    JOIN sys.dm_tran_database_transactions AS DTDT
        ON DTDT.transaction_id = DTCT.transaction_id;
END;

Thử nghiệm trên AdventureWorks:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Begin Tran';

SELECT TOP (1)
    P.Name
FROM Production.Product AS P
ORDER BY 
    P.Name;

EXECUTE dbo.#TranState @Comment = 'After Select';

UPDATE Production.Product
SET Name = N'New Blade'
WHERE Name = N'Blade';

EXECUTE dbo.#TranState @Comment = 'After Update';

-- Or Commit
ROLLBACK TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Tran';

Đầu ra:

Sau khi bắt đầu Trần

Sau khi chọn

Sau khi cập nhật

Sau khi giao dịch

Từ quan điểm hoàn toàn thực tế (như Aaron đã lưu ý trong một bình luận), có lẽ sẽ an toàn hơn khi đưa ra một bản rollback để đảm bảo không có thay đổi nào được thực hiện, trong trường hợp mã được sửa đổi trong tương lai. Vì vậy, đó là tất cả về ý định: không thay đổi = rollback.

Trong vượt qua, REPEATABLE READlà một mức cô lập bất thường để lựa chọn; nó không phải lúc nào cũng hoạt động như mọi người mong đợi bằng trực giác . Tùy thuộc vào yêu cầu của bạn, bạn có thể thấy SNAPSHOTsự cô lập là phù hợp hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.