Làm thế nào để đảm bảo rằng CHỌN VÀ CHỌN đồng thời trên một bảng sẽ không làm bế tắc?

Tôi có bảng sau trong cơ sở dữ liệu SQL Server 2008 của mình:

CREATE TABLE [dbo].[SomeTable]
(
   [Id] [bigint] IDENTITY(1,1) NOT NULL,
   [Column1] [varchar](30) NOT NULL,
   [Column2] [varchar](30) NOT NULL,
   [Column3]  [varchar](50) NOT NULL,
   CONSTRAINT [PK_SomeTable] PRIMARY KEY CLUSTERED 
   (
  [Id] ASC
   )
 )

Một quy trình chèn dữ liệu vào bảng này, một quy trình khác đọc tất cả dữ liệu từ bảng này. Cả hai quá trình làm việc đồng thời.

one process:
INSERT INTO dbo.SomeTable VALUES ('col1', 'col2', 'col3')

another process:
SELECT Id, Column1, Column2, Column3 FROM dbo.SomeTable

Tôi thấy truy vấn thứ hai thực hiện quét toàn bộ bảng, nhưng tôi cần lấy tất cả dữ liệu từ bảng này để xử lý thêm (nó sẽ không phải là một bảng rất lớn, vì nó sẽ được làm sạch định kỳ. Nó sẽ chứa các hàng 1K-2K ).

Có cách nào để đảm bảo rằng những bế tắc sẽ không bao giờ xảy ra đối với hai truy vấn này không?

Bế tắc sẽ luôn xảy ra tại một số điểm theo chiến lược khóa mặc định. Tuy nhiên, không có khả năng trong kịch bản đã cho của bạn do quét bảng thẳng.

Tuy nhiên, nhiều khả năng nếu bạn có một số CHỌN và CHỌN đồng thời.

Sử dụng NOLOCK có nghĩa là đọc bẩn và không phải là cách thực hành tốt nhất. Mọi người dường như đề nghị họ mặc dù ...

Cách khác là sử dụng các chế độ cách ly ảnh chụp nhanh : CHỌN sẽ đọc dữ liệu được cam kết cuối cùng, thay vì bị chặn bởi INSERT.

Nếu bạn có thể sống với các lần đọc bẩn, bạn có thể chỉ định gợi ý truy vấn bảng NOLOCK . Nếu các hoạt động duy nhất đang xảy ra là chèn và bạn không tham gia với dữ liệu trong các bảng khác, đây có thể là một giải pháp khả thi.

Xin lưu ý rằng gợi ý NOLOCK đã bị lạm dụng và lạm dụng trong nhiều tình huống. Ngoài ra, lưu ý rằng đó là một gợi ý, và không phải là một chỉ thị. Nói cách khác, tôi không tin rằng nó được đảm bảo để ngăn chặn khóa trong tất cả các tình huống.

CHỌN COUNT (*) TỪ Sinh viên VỚI (NOLOCK)

Nhưng nó có thể dẫn đến vấn đề nhất quán dữ liệu khác nếu chúng ta đang sử dụng nó trong một môi trường phức tạp. Ví dụ: nếu Chèn là một phần của Giao dịch và bạn đọc ra bằng cách chọn và Giao dịch bị lỗi. Sau đó, trong kịch bản này, câu lệnh chèn của bạn có thể khôi phục và kết quả được chọn bị hỏng. Vì vậy, nếu bạn muốn sử dụng nó, hãy đảm bảo Chèn không phải là một phần của Giao dịch. Để hiểu rõ hơn bạn có thể tham khảo trang này

http://www.techrepublic.com/article/USE-nolock-and-readpast-table-hints-in-sql-server/6185492