Sử dụng SPID trong Bảng DB (thay vì Bảng biến)

Cơ sở dữ liệu giao dịch được sử dụng để đặt phòng ...

Nhà cung cấp của chúng tôi đã được yêu cầu thay thế #teemables bằng @tablevariabled (vì các khóa biên dịch nặng) nhưng thay vào đó họ thay thế bằng một bảng thực tế có thêm SPID dưới dạng cột để đảm bảo quy trình được lưu trữ chỉ hoạt động trên các hàng áp dụng.

Bạn có thấy bất kỳ rủi ro trong phương pháp hoạt động này? Trước khi tất cả các giao dịch bị cô lập trong giao dịch của riêng họ ... Tôi lo lắng chúng tôi có thể sẽ khóa bảng này một loạt nhưng ý kiến ​​của họ là SQL sử dụng khóa cấp hàng và điều này sẽ không tạo ra nhiều khóa hơn.

Phiên bản máy chủ SQL: Doanh nghiệp 2016 - 13.0.5216.0

CREATE TABLE dbo.qryTransactions (
    ID int IDENTITY (0,1) NOT NULL CONSTRAINT pk_qryTransactions PRIMARY KEY CLUSTERED,
    spid int NOT NULL,
    OrderID int,
    ItemID int,
    TimeTransactionStart datetime,
    TimeTransactionEnd datetime,
...other fields
    )

CREATE INDEX idx_qryTransactions_spidID ON qryTransactions (spid, ID) INCLUDE (ItemID, OrderID, TimeTransactionStart, TimeTransactionEnd)

Một chút lan man hơn có thể phù hợp trong một khối nhận xét ... và muốn làm nổi bật một nhận xét mà OP đưa ra để trả lời câu trả lời của Ray:

• cha mẹ (Common_InsertOrder_1) tạo bảng tạm thời
• một Proc con (insertOrder) truy vấn bảng tạm thời
• khóa biên dịch đang được nhìn thấy cho Proc con (Chèn)

Tiếp tục đi một chút trong một phút ... về những gì sẽ xảy ra với kịch bản này là Sybase ASE ...

• mỗi bảng tạm thời có một id đối tượng duy nhất (chắc chắn, id đối tượng có thể được sử dụng lại tại một số điểm nhưng điều này rất hiếm và chắc chắn sẽ không xảy ra cho các phiên đồng thời)
• Sybase ASE thường sẽ buộc biên dịch lại trên mỗi lần thực hiện của Proc con vì sự thay đổi id đối tượng cho bảng tạm thời
• Sybase ASE cũng sẽ buộc biên dịch lại Proc con nếu thấy rằng cấu trúc của bảng tạm thời đã thay đổi (ví dụ: số lượng cột khác nhau, tên cột / kiểu dữ liệu / nullable khác nhau) giữa các yêu cầu của Proc được lưu trữ
• Các phiên bản gần đây hơn của Sybase ASE có cấu hình (có hiệu quả) báo cho trình biên dịch bỏ qua các thay đổi trong id đối tượng bảng tạm thời, do đó loại bỏ việc biên dịch lại Proc con (LƯU Ý: việc biên dịch lại vẫn sẽ xảy ra nếu cấu trúc bảng thay đổi)

Quay lại vấn đề của OP (khóa biên dịch trên Proc con) ...

• có khả năng một số dấu tích của hành vi Sybase ASE vẫn có thể cư trú trong SQL Server (từ khi hai sản phẩm này đậu trong một nhóm) không?
• Có bất kỳ cấu hình SQL Server nào có thể làm giảm (loại bỏ?) các biên dịch lại của Proc con (nếu do thay đổi trong id đối tượng) không?
• OP có thể xác minh rằng Proc cha đang tạo bảng tạm thời với cùng cấu trúc / DDL chính xác không?

Đối với ý tưởng sử dụng một bảng vĩnh viễn duy nhất có @@ SPID để phân biệt các hàng giữa các phiên ... đã ở đó, thấy rằng ... yuck ; vấn đề định kỳ:

• Làm thế nào / khi nào để dọn sạch các hàng mồ côi
• Việc sử dụng lại @@ SPID bởi công cụ cơ sở dữ liệu có thể dẫn đến các vấn đề về độ chính xác của dữ liệu nếu dữ liệu mồ côi tồn tại (hoặc trong khi dọn dẹp dữ liệu mồ côi, ví dụ: xóa trong đó @@ SPID = 10 nhưng có phiên mới / hiện tại / hoạt động với @ @ SPID = 10 => việc dọn dẹp xóa quá nhiều dữ liệu)
• tiềm năng leo thang khóa từ khóa hàng sang khóa trang / bảng
• nếu bảng có chỉ mục thì khóa (b) tiềm năng khi cập nhật chỉ mục
• tùy thuộc vào cơ sở dữ liệu nào mà bảng nằm trong bạn có thể xem xét nhiều hoạt động hơn để ghi vào thiết bị ghi nhật ký (trong Sybase ASE, có thể, vô hiệu hóa, đăng nhập tempdb một cách hiệu quả)
• ngay cả các khóa cấp hàng (độc quyền) có thể chặn các phiên khác (tùy thuộc vào mức cô lập và liệu phiên có thể quét quá khứ / bỏ qua các khóa độc quyền đã nói hay không)

Tôi muốn quay lại và (điều tra lại) vấn đề gốc (khóa biên dịch lại trên Proc con) và xem liệu có cách nào để giảm (loại bỏ?) Các khóa biên dịch nói không. [Thật không may, kiến ​​thức về Máy chủ SQL của tôi về các vấn đề này là ... NULL ... vì vậy sẽ quan tâm đến đầu vào từ một số chuyên gia biên dịch SQL Server.]

Dường như với tôi sử dụng @@SPIDnhư thế là yêu cầu rắc rối.

ID phiên được sử dụng lại thường xuyên; ngay khi kết nối người dùng đăng xuất, ID phiên đó có sẵn để được sử dụng lại và có khả năng sẽ được sử dụng bởi phiên tiếp theo đang cố gắng kết nối.

Để làm cho nó hoạt động ít nhất là bán đáng tin cậy, bạn cần một trình kích hoạt đăng nhập để loại bỏ các hàng trước khỏi bảng với cùng @@SPID. Nếu bạn làm điều đó, bạn có thể sẽ thấy rất nhiều khóa trên bàn bằng cách sử dụng @@SPIDcột.

SQL Server thực sự sử dụng khóa hàng, nhưng nó cũng sử dụng khóa trang và khóa bảng. Tất nhiên, bạn có thể giảm thiểu điều đó thông qua việc lập chỉ mục tốt, nhưng điều này vẫn giống như một mô hình chống đối với tôi.

Nếu thủ tục được lưu trữ là phương pháp duy nhất được sử dụng để truy cập vào các bảng bị ảnh hưởng, bạn có thể điều tra bằng cách sử dụng khóa ứng dụng, thông qua sp_getapplockđể tuần tự hóa truy cập vào các phần có liên quan. Tài liệu cho sp_getapplock đang ở đây . Erik Darling có một bài viết thú vị về nó ở đây .

Vâng, tôi thấy rủi ro. Thật ngây thơ khi tính vào SQL bằng cách sử dụng Row Locking. Ví dụ: tôi khá chắc chắn việc chèn và xóa sẽ sử dụng khóa trang ít nhất. SQL Engine chọn loại khóa dựa trên một số yếu tố và không có yếu tố nào trong số đó bao gồm "ý kiến ​​của họ". Các giải pháp chăn như thay đổi bảng tạm thời thành các biến bảng nói chung cũng là những ý tưởng tồi. Biến bảng rất hữu ích trong một số trường hợp nhưng chúng có những hạn chế và vấn đề về hiệu năng. Tôi thích bảng tạm thời trong hầu hết các trường hợp. Đặc biệt khi bàn sẽ chứa hơn vài chục hàng. Tôi sẽ yêu cầu nhà cung cấp giải thích lý do tại sao hệ thống gặp phải "khóa biên dịch nặng" và hiệu suất bị suy giảm như thế nào. Hãy nhớ rằng, bất cứ khi nào bạn nhìn bạn sẽ tìm thấy "ổ khóa nặng" nào đó. Điều đó không nhất thiết có nghĩa là ổ khóa là một vấn đề. Tối đa ' Nhận xét về @@ SPID cũng quan trọng. Ngoài ra, mô hình giao dịch và xử lý lỗi có thể là vấn đề lớn. Nếu hệ thống của bạn gặp sự cố bế tắc hoặc vấn đề chất lượng dữ liệu đầu vào thì việc xử lý lỗi tiêu chuẩn có thể dẫn đến phiên bị chấm dứt mà bảng qryTransilities được đặt lại đúng cách. IMO cách tiếp cận giải pháp sai cho vấn đề ban đầu.