Làm cách nào để hạn chế một thủ tục lưu trữ SQL được chạy bởi một người tại một thời điểm?

Tôi có một thủ tục được lưu trữ về cơ bản chọn các giá trị từ một bảng và chèn chúng vào một bảng khác, một kiểu lưu trữ. Tôi muốn tránh nhiều người làm điều đó cùng một lúc.

Trong khi thủ tục này đang chạy, tôi không muốn bất kỳ ai khác có thể bắt đầu nó, tuy nhiên tôi không muốn tuần tự hóa, người khác chạy thủ tục sau khi tôi hoàn thành nó.

Những gì tôi muốn là cho người khác cố gắng khởi động nó để nhận được một lỗi, trong khi tôi đang chạy thủ tục.

Tôi đã thử sử dụng sp_getapplock, tuy nhiên tôi không thể quản lý để ngăn chặn hoàn toàn người đó chạy quy trình.

Tôi cũng đã thử tìm thủ tục với sys.dm_exec numquests và chặn thủ tục, trong khi điều này không hoạt động, tôi nghĩ nó không tối ưu vì trên một số máy chủ tôi không có quyền chạy sys.dm_exec_sql giác (sql_handle).

Cách tốt nhất để tôi làm điều này là gì?

Để thêm vào câu trả lời của @ Tibor-Karaszi, đặt thời gian chờ khóa không thực sự gây ra lỗi (Tôi đã gửi PR cho các tài liệu). sp_getapplock chỉ trả về -1, vì vậy bạn phải kiểm tra giá trị trả về. Vì vậy, như thế này:

create or alter procedure there_can_be_only_one 
as
begin
begin transaction

  declare @rv int
  exec @rv = sp_getapplock 'only_one','exclusive','Transaction',0
  if @rv < 0
   begin
      throw 50001, 'There is already an instance of this procedure running.', 10
   end

  --do stuff
  waitfor delay '00:00:20'


commit transaction
end

Sử dụng sp_getapplock vào đầu Proc và đặt thời gian chờ khóa thành giá trị rất thấp. Bằng cách này bạn sẽ gặp lỗi khi bạn bị chặn.

Một tùy chọn khác là xây dựng một bảng để kiểm soát truy cập vào thủ tục. ví dụ dưới đây cho thấy một bảng có thể cũng như một quy trình có thể sử dụng nó.

CREATE TABLE dbo.ProcedureLock
    (
    ProcedureLockID INT NOT NULL IDENTITY(1,1)
    , ProcedureName SYSNAME NOT NULL
    , IsLocked BIT NOT NULL CONSTRAINT DF_ProcedureLock_IsLocked DEFAULT (0)
    , UserSPID INT NULL
    , DateLockTaken DATETIME2(7) NULL
    , DateLockExpires DATETIME2(7) NULL
    , CONSTRAINT PK_ProcedureLock PRIMARY KEY CLUSTERED (ProcedureLockID)
    )

CREATE UNIQUE NONCLUSTERED INDEX IDXUQ_ProcedureLock_ProcedureName
    ON dbo.ProcedureLock (ProcedureName)

INSERT INTO dbo.ProcedureLock
    (ProcedureName, IsLocked)
VALUES ('dbo.DoSomeWork', 0)

GO

CREATE PROCEDURE dbo.DoSomeWork
AS
BEGIN

    /** Take Lock */
    UPDATE dbo.ProcedureLock
    SET IsLocked = 1
        , UserSPID = @@SPID
        , DateLockTaken = SYSDATETIME()
        , DateLockExpires = DATEADD(MINUTE, 10, SYSDATETIME())
    WHERE ProcedureName = 'dbo.DoSomeWork'
        AND (IsLocked = 0
            OR (IsLocked = 1 AND DateLockExpires < SYSDATETIME())
            )

    IF COALESCE(@@ROWCOUNT, 0) = 0
    BEGIN
        ;THROW 50000, 'This procedure can only be run one at a time, please wait', 1;
    END

    /** DO WHATEVER NEEDS TO BE DONE */

    /** Release the lock */
    UPDATE dbo.ProcedureLock
    SET IsLocked = 0
        , UserSPID = NULL
        , DateLockTaken = NULL
        , DateLockExpires = NULL
    WHERE ProcedureName = 'dbo.DoSomeWork'

END

Tôi nghĩ rằng bạn đang cố gắng giải quyết vấn đề một cách không chính xác. Những gì bạn muốn là bảo vệ tối đa tính nhất quán của cơ sở dữ liệu. Nếu hai người chạy một thủ tục được lưu trữ cùng một lúc, tính nhất quán của cơ sở dữ liệu có thể bị vi phạm.

Để bảo vệ chống lại các loại mâu thuẫn cơ sở dữ liệu khác nhau, tiêu chuẩn SQL có bốn mức cách ly giao dịch:

• ĐỌC KHÔNG HOÀN THÀNH khi các giao dịch về cơ bản mất giá trị, các giao dịch khác nhìn thấy dữ liệu bẩn. Đừng dùng cái này!
• ĐỌC CAM KẾT nơi các giao dịch chỉ nhìn thấy dữ liệu đã cam kết, nhưng có thể có sự không nhất quán khi hai giao dịch có thể bước qua các ngón chân của nhau
• ĐỌC LẠI ĐỌC nơi mà một loại không nhất quán, đọc không lặp lại, được giải quyết
• SERIALIZABLE đảm bảo rằng tồn tại một số thứ tự ảo trong đó thực hiện các giao dịch sẽ dẫn đến kết quả mà việc thực hiện của chúng dẫn đến

Tuy nhiên, tiêu chuẩn SQL có cách tiếp cận dựa trên khóa cho các sự không nhất quán của cơ sở dữ liệu này và vì lý do hiệu năng, nhiều cơ sở dữ liệu sử dụng cách tiếp cận dựa trên ảnh chụp nhanh, về cơ bản có các mức này:

• ĐỌC CAM KẾT giống như trong khóa cơ sở dữ liệu
• SNAPSHOT ISOLATION trong đó cơ sở dữ liệu nhìn thấy ảnh chụp nhanh của tất cả dữ liệu và nếu nó cố cập nhật một hàng đã được cập nhật bởi một số giao dịch khác, nó sẽ bị hủy, nhưng có một số dị thường nổi tiếng có thể xảy ra
• SERIALIZABLE giống như trong việc khóa cơ sở dữ liệu dựa trên cơ sở dữ liệu, nhưng lần này được thực hiện theo một cách khác, không phải bằng cách khóa mà bằng cách đảm bảo không có vi phạm tuần tự hóa và nếu phát hiện vi phạm đó, hãy hủy giao dịch

Việc hủy giao dịch trong các cơ sở dữ liệu dựa trên cách ly ảnh chụp này nghe có vẻ đáng lo ngại, nhưng sau đó, mọi cơ sở dữ liệu sẽ hủy giao dịch do bế tắc, do đó, bất kỳ ứng dụng hợp lý nào cũng cần có thể thử lại giao dịch.

Những gì bạn muốn là mức cô lập SERIALIZABLE : nó đảm bảo rằng nếu các giao dịch được thực hiện độc lập hết lần này đến lần khác trong trạng thái tốt, thì bất kỳ việc thực hiện song song nào của giao dịch cũng dẫn đến trạng thái tốt. May mắn thay, Michael Cahill đã có trong luận án tiến sĩ của mình để tìm ra mức độ cô lập SERIALIZABLE có thể được hỗ trợ bởi các cơ sở dữ liệu bị cô lập nhanh chóng với ít nỗ lực.

Nếu sử dụng mức cô lập SERIALIZABLE trong cơ sở dữ liệu bị cô lập nhanh, nếu hai người cố gắng chạy quy trình được lưu trữ đồng thời và họ sẽ giẫm lên các ngón chân của nhau, một trong các giao dịch sẽ bị hủy.

Bây giờ, SQL Server có thực sự hỗ trợ mức cô lập SERIALIZABLE (thay vì giả mạo cách ly ảnh chụp nhanh phía sau từ khóa SERIALIZABLE ) không? Thành thật mà nói, tôi không biết: cơ sở dữ liệu duy nhất tôi biết hỗ trợ nó là PostgreQuery.

Mặc dù tôi không thể đưa ra lời khuyên cụ thể cho SQL Server, tuy nhiên tôi vẫn đăng câu trả lời này, vì người dùng PostgreQuery và người dùng cơ sở dữ liệu khác có thể xem xét chuyển sang PostgreQuery có thể hưởng lợi từ câu trả lời của tôi. Ngoài ra, người dùng cơ sở dữ liệu không phải là PostgreQuery không thể chuyển sang PostgreQuery có thể gây áp lực cho nhà cung cấp cơ sở dữ liệu yêu thích của họ để cung cấp mức cách ly SERIALIZABLE chính hãng .

Tôi nhận ra vấn đề 'thực tế' có thể phức tạp hơn.

Trong trường hợp không phải là: nếu bạn thực hiện lưu trữ với trình kích hoạt chèn và / hoặc cập nhật, bạn có thể tránh được sự cố bạn đang cố gắng giải quyết.

Hy vọng rằng sẽ giúp,
-Chris C.