Những rủi ro nào nếu chúng ta cho phép đọc ảnh chụp nhanh đã cam kết trong máy chủ sql?

Tôi đã đọc ở đây rằng một số dữ liệu bổ sung sẽ được lưu trữ trên mỗi hàng để chúng ta có thể thấy sự suy giảm hiệu suất nhưng những rủi ro khác là gì?

ví dụ. Điều này sẽ ảnh hưởng đến sự phục hồi của cơ sở dữ liệu? Có điều gì khác chúng ta cần làm để tận dụng lợi thế này không?

Tôi dự định thực hiện các lệnh này:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Tôi tin rằng điều này sẽ cung cấp cho chúng tôi một cái gì đó gần hơn với lời tiên tri trong đó nếu một giao dịch đang cập nhật các giao dịch khác vẫn có thể đọc dữ liệu cũ. Điều này có đúng không?

Tôi đang xem xét vấn đề này vì tôi chán việc khóa các vấn đề trong SQL Server 2005. Tôi hy vọng điều này có thể làm giảm các bế tắc thường xuyên mà người dùng của chúng tôi thấy, giúp hiệu suất tổng thể của ứng dụng của chúng tôi và khuyến khích các nhà phát triển của chúng tôi thực hiện nhiều hơn một thao tác cho mỗi giao dịch mà không cần nỗi sợ.

Tóm lược

1. Nếu bạn gặp vấn đề về khóa thì bạn gặp vấn đề với mã của mình: đó không phải là công cụ cơ sở dữ liệu
2. Nó không phải là một viên đạn ma thuật
3. Bạn có thể thêm nhiều vấn đề

Tải

Nó cũng sẽ tăng tải cho tempdb và CPU của bạn . Cũng thấy:

• "Tác động Hiệu suất: Chi phí Tiềm năng của Read_Commned_Snapshot" (Linchi Shea)

Sự an toàn

Quan trọng nhất, cách ly ảnh chụp nhanh không an toàn trong nhiều trường hợp theo mặc định . Đọc "Cách ly ảnh chụp" (Wikipedia) để biết thêm về các dị thường ghi-xiên. Phần tiếp theo là "Tạo cách ly ảnh chụp nhanh cách ly" để giải quyết vấn đề này.

Do đó, nói chung, cách ly ảnh chụp nhanh đặt ra một số vấn đề trong việc duy trì các ràng buộc không tầm thường đối với người dùng, những người có thể không đánh giá cao những cạm bẫy tiềm năng hoặc các giải pháp có thể. Ưu điểm của việc chuyển nhượng này là hiệu suất tốt hơn.

Cũng thấy:

• "Nguy cơ tiềm ẩn của cấp độ cô lập ảnh chụp cam kết đã đọc" (JimMcLeod, tranh cãi trong các bình luận của Alex Kuznetsov)
• Bế tắc!: "Đọc ảnh chụp nhanh đã cam kết" Giải thích (Nick Berardi)
• Cấp độ cách ly so với ảnh chụp nhanh, vấn đề Ngũ hành (Craig Freedman)
• Các bài đọc liên quan đến UDF trong READ_COMMITTED_SNAPSHOT có thể không nhất quán (Alex Kuznetsov)

Tôi biết đây là một chủ đề cũ nhưng tôi sẽ nói với một sự cô lập ảnh chụp mức độ lớn là một viên đạn ma thuật. Nó sẽ loại bỏ tất cả sự ngăn chặn của bạn giữa độc giả và nhà văn. Tuy nhiên, nó sẽ không ngăn cản các nhà văn chặn các nhà văn khác. Không có cách nào xung quanh đó.

Theo kinh nghiệm của tôi, tải bổ sung trên TEMPDB là không đáng kể và lợi ích của việc tạo phiên bản hàng trong việc giảm độc giả bị chặn là rất lớn.

Để tham khảo, hàng versioning (ảnh chụp cô lập) là phương pháp Oracle đã sử dụng trong nhiều thập kỷ để đạt được cách ly mà không ngăn chặn độc giả và Oracle DBS Tôi đã làm việc trong gần 20 năm kinh nghiệm đến nay vấn đề ngăn chặn ít hơn SQL Server thực hiện. Hầu hết các nhà phát triển SQL đều do dự khi sử dụng cách ly ảnh chụp nhanh vì họ chỉ kiểm tra mã của họ dựa trên cơ sở dữ liệu sử dụng cài đặt mặc định.

Vài điểm bổ sung để thêm vào các câu trả lời khác:

SET ALLOW_SNAPSHOT_ISOLATION ONchỉ cho phép cách ly ảnh chụp nhanh trong cơ sở dữ liệu. Để tận dụng lợi thế của nó, bạn phải mã hóa lại và SET TRANSACTION ISOLATION LEVEL SNAPSHOTcho các giao dịch bạn muốn áp dụng. Mã cuộc gọi sẽ cần phải được thay đổi để xử lý các lỗi xung đột cập nhật.

Sau đó SET READ_COMMITTED_SNAPSHOT ON, các câu lệnh đã đọc cam kết sử dụng phiên bản hàng. Lưu ý, đây là phiên bản hàng mức câu lệnh chỉ để đọc . Đối với các bản cập nhật, hàng "thực" được lấy và khóa cập nhật được áp dụng. Xem phần Tóm tắt về hành vi trong Tìm hiểu các mức cô lập dựa trên phiên bản hàng

Dù là tuyến đường nào, mà không cần kiểm tra toàn diện, bạn có thể sẽ giới thiệu một bộ vấn đề hoàn toàn mới cho hệ thống.

Tôi tin rằng điều này sẽ cung cấp cho chúng tôi một cái gì đó gần hơn với lời tiên tri trong đó nếu một giao dịch đang cập nhật các giao dịch khác vẫn có thể đọc dữ liệu cũ. Điều này có đúng không?

Vâng, điều này là chính xác .

Rất đáng để đọc các liên kết trong câu trả lời của gbn và tôi tin điều tương tự cũng áp dụng cho MVCC mặc định của Oracle cũng như đối với SQL Server ở chế độ Cách ly Ảnh chụp. Tôi sẽ nói thêm rằng nếu bạn hiểu những cạm bẫy tiềm ẩn, IMO những lợi ích vượt xa những khó khăn thêm vào (nói theo quan điểm của Oracle) - và tất nhiên một số vấn đề khóa đã biến mất một cách hợp pháp, đó là điểm của MVCC (cũng có một lớp khóa các vấn đề sẽ không biến mất do vấn đề mã, nhưng tôi giả sử bạn hiểu điều này).

Chúng tôi đang sử dụng SNAPSHOT ISOLATION trong tất cả các dự án sử dụng SQL Server DB. Không có thêm 1205 lỗi SQL, nguyên nhân không phải do mã ứng dụng sai, mà từ hành vi khóa trang mặc định và khóa hàng.

Tác động hiệu suất là tối thiểu và cho đến nay đã 7 năm trôi qua, hàng trăm triệu hoạt động đã được xử lý trong các hệ thống khác nhau, không có vấn đề gì liên quan đến ISAATION SNAPSHOT.

Các tình huống trong đó một số luồng khác nhau đang cập nhật thông tin quan trọng về kinh doanh theo một hàng song song là cực kỳ đặc biệt và khả năng SNAPSHOT ISOLATION sẽ là nguyên nhân của bất kỳ vấn đề không nhất quán nào gần như bằng không.

Nếu bạn có hệ thống OLTP, bằng cách thiết kế cập nhật một hàng dựa trên dữ liệu hàng hiện tại trong nhiều luồng, tất nhiên SNAPSHOTS không được chấp nhận trong các trường hợp như vậy.

chúng tôi đã kích hoạt nó và một câu lệnh sql chọn kỳ lạ chạy 4 đã chặn toàn bộ db cho dù có bao nhiêu lõi và tất cả. Tắt RCSI đã sửa. Tôi sẽ bật nó lên một khi bạn phải đối mặt với những bế tắc khác, không phải mặc định.