Tôi đang đối mặt với một tình huống mà nó hơi khó giải quyết. Tôi cần giúp đỡ để hiểu những gì đang xảy ra.
TL; DR : Mỗi khi Nhật ký giao dịch đầy đủ trong SQL Server, nó cần tắt cơ sở dữ liệu để vào Chế độ khôi phục và khôi phục các giao dịch vi phạm? Điều này luôn được thực hiện bởi thiết kế hay điều này chỉ xảy ra khi có điều gì xấu xảy ra?
Kịch bản:
Một trong những cơ sở dữ liệu sản xuất được sử dụng nhiều của chúng tôi, chạy một số công việc ETL và các lô bảng chạy dài, đã vào Chế độ khôi phục và không thể truy cập được trong một thời gian. Điều này đã xảy ra ba lần trong tuần này (máy chủ này đã hoạt động được 2 năm và chúng tôi đã không nhận thấy vấn đề này trong quá khứ).
Nhìn vào nhật ký lỗi những gì đã xảy ra là rõ ràng: Nhật ký giao dịch đã đầy, cơ sở dữ liệu cần thiết để phục hồi giao dịch, khôi phục thất bại, tắt cơ sở dữ liệu và bắt đầu trong chế độ khôi phục.
DBA bảo vệ điều này như hành vi bình thường của SQL Server. Đó là, theo ông, mỗi khi nhật ký giao dịch đầy đủ và một giao dịch cần phục hồi cơ sở dữ liệu sẽ vào Chế độ khôi phục do thiếu không gian nhật ký. Sau khi khôi phục (chỉ có thể được thực hiện trong Chế độ khôi phục theo anh ta), cơ sở dữ liệu sẽ có sẵn một lần nữa.
Tôi không tìm thấy tài liệu tham khảo cho thông tin này. Vì vậy, tôi rất không đồng ý. Tôi thực sự sẽ đánh giá cao nếu ai đó thuyết phục tôi rằng tôi sai.
Quan điểm của tôi:
Theo hiểu biết của tôi, một DBMS được xây dựng để quản lý / chạy các truy vấn. Nếu nó thiếu không gian, truy vấn sẽ thất bại. Đơn giản như nó là. Và tôi không nói về hiệu suất của bất cứ điều gì khác, nhưng chỉ có sẵn.
Tôi không có ý nghĩa gì khi chấp nhận rằng DBMS cần thiết kế để tự tắt để khôi phục mọi giao dịch. Theo hiểu biết của tôi, không có vấn đề gì nếu tôi đang chạy hàng tấn truy vấn hoặc nếu các truy vấn được thiết kế xấu. Các truy vấn xấu nên thất bại và cuộc sống tiếp tục. Phải không?
Tôi đoán là một cái gì đó khác đang làm cho nó thất bại, và tôi cần theo dõi những gì đang xảy ra.
Là sự hiểu biết của tôi sai hay đây thực sự là cách SQL Server được thiết kế để hoạt động? Giả sử tôi không sai, tôi có thể làm gì khác để theo dõi nguồn gốc của vấn đề này?
Một số thông tin bổ sung
select @@version: Microsoft SQL Server 2012 (SP1) - 11.0.3156.0 (X64) ngày 4 tháng 5 năm 2015 18:48:09 Bản quyền (c) Microsoft Corporation Standard Edition (64-bit) trên Windows NT 6.2 (Build 9200 :)- Cơ sở dữ liệu này là trong mô hình phục hồi đơn giản.
- Có các cơ sở dữ liệu khác trong cùng một ví dụ. Chúng không trình bày cùng một vấn đề, nhưng chúng cũng không được sử dụng nhiều.
- Chỉ có nhật ký giao dịch là đầy đủ, không phải đĩa. Đĩa có nhiều không gian, nhưng kích thước nhật ký cho cơ sở dữ liệu bị hạn chế.
- Chúng tôi giám sát máy chủ này, tải CPU vẫn ổn, sử dụng bộ nhớ tốt, các đĩa sử dụng RAID-5 và bộ điều khiển không có sự cố hoặc lỗi đọc. Có một số đỉnh trong việc sử dụng tài nguyên, nhưng không có gì lạ.
- Tôi biết các truy vấn có thể được cải thiện để sử dụng hiệu quả nhật ký. Tôi cũng biết tôi có thể tăng không gian nhật ký giao dịch. Nhưng đây thực sự không phải là quan điểm của tôi ở đây.
- Một DBA đã được thuê gần đây để chăm sóc cơ sở dữ liệu này. Vì vậy, một số cấu hình đã được thay đổi gần đây, cho mục đích điều chỉnh. Anh ấy làm cho tôi biết về tất cả các thay đổi (như vô hiệu hóa tự động thu nhỏ, tăng kích thước tự động phát triển, v.v.). Tôi không tìm thấy gì có thể gây hại cho cơ sở dữ liệu.
Đăng nhập kết xuất (theo thứ tự xảy ra, loại bỏ trùng lặp)
[02:58:37am ~ 04:47:42pm, 12 times]Lỗi: 845. Mức độ nghiêm trọng: 17. Trạng thái: 1. Đã hết thời gian chờ trong khi chờ bộ đệm loại 3 cho trang (1: 8728760). cơ sở dữ liệu ID 7. FlushCache: đã dọn sạch 10460 bufs với 6709 ghi trong 77540 ms (tránh 864 bufs bẩn mới) cho thông lượng trung bình db 7: 0: 1.05 MB / giây. Độ bão hòa I / O: 107. chuyển đổi ngữ cảnh 391 mục tiêu cuối cùng nổi bật: 4800. avgWriteLatency 0 FlushCache: đã dọn sạch 95448 bufs với 37560 ghi trong 85820 ms (tránh 60465 bufs bẩn mới) cho thông lượng trung bình db 7: 0: 8,69 MB / giây. Độ bão hòa I / O: 17026. chuyển đổi bối cảnh 20713 mục tiêu nổi bật cuối cùng: 446. avgWriteLatency 3.
[02:58:37am ~ 04:47:42pm, 13 times]Đã hết thời gian chờ trong khi chờ chốt đệm - loại 3. bp 000000109B9E69C0. trang 1: 73430228. stat 0x10b. cơ sở dữ liệu id: 7. đơn vị phân bổ Id: 72057594304790528. task 0x00000008BC0850C8: 1. thời gian chờ 300 giây. cờ 0x100000001a. nhiệm vụ sở hữu 0x0000000827B38188. Không tiếp tục chờ đợi.
[02:58:37am ~ 04:47:42pm, 12 times]Lỗi: 5901. Mức độ nghiêm trọng: 16. Trạng thái: 1. Một hoặc nhiều đơn vị khôi phục thuộc cơ sở dữ liệu 'XXXXXXXXXX' không thể tạo điểm kiểm tra. Điều này thường xảy ra do thiếu tài nguyên hệ thống như đĩa hoặc bộ nhớ hoặc trong một số trường hợp do hỏng cơ sở dữ liệu. Kiểm tra các mục trước trong nhật ký lỗi để biết thêm thông tin chi tiết về lỗi này.
[05:14:29pm ~ 05:14:53pm, 9 times]Lỗi: 9002. Mức độ nghiêm trọng: 17. Trạng thái: 4. Nhật ký giao dịch cho cơ sở dữ liệu 'XXXXXXXXXX' đã đầy do 'ACTIVE_TRANSACTION'.
[05:14:53pm, once]Lỗi: 3314. Mức độ nghiêm trọng: 21. Trạng thái: 3. Cơ sở dữ liệu XXXXXXXXXX đã bị tắt do lỗi 3314 trong thói quen 'XdesRMReadWrite :: RollbackToLsn'. Khởi động lại cho cơ sở dữ liệu không chụp nhanh sẽ được thử sau khi tất cả các kết nối đến cơ sở dữ liệu bị hủy bỏ.
[05:14:53pm ~ 05:14:53pm, 16 times]Lỗi: 3314. Mức độ nghiêm trọng: 21. Trạng thái: 3. Trong quá trình hoàn tác thao tác đã ghi trong cơ sở dữ liệu 'XXXXXXXXXX', đã xảy ra lỗi tại ID bản ghi nhật ký (8064074: 20971: 110). Thông thường, lỗi cụ thể được ghi lại trước đây là lỗi trong dịch vụ Nhật ký sự kiện của Windows. Khôi phục cơ sở dữ liệu hoặc tệp từ bản sao lưu hoặc sửa chữa cơ sở dữ liệu.
[05:14:53pm ~ 05:14:53pm, 9 times]Lỗi: 9001. Mức độ nghiêm trọng: 21. Trạng thái: 5. Nhật ký cho cơ sở dữ liệu 'XXXXXXXXXX' không khả dụng. Kiểm tra nhật ký sự kiện cho các thông báo lỗi liên quan. Giải quyết bất kỳ lỗi nào và khởi động lại cơ sở dữ liệu.
[05:14:58, once]Bắt đầu cơ sở dữ liệu 'XXXXXXXXXX'.
[05:15:02, once]Khôi phục cơ sở dữ liệu 'XXXXXXXXXX' (7) hoàn thành 0% (còn lại khoảng 2931 giây). Giai đoạn 1 của 3. Đây chỉ là một thông tin. Không có hành động người dùng được yêu cầu....
[05:51:01pm, once]6 giao dịch được khôi phục trong cơ sở dữ liệu 'XXXXXXXXXX' (7: 0). Đây là tin nhắn mang thông tin đơn thuần. Không có hành động người dùng được yêu cầu.
[05:51:01pm, once]Recovery đang viết một điểm kiểm tra trong cơ sở dữ liệu 'XXXXXXXXXX' (7). Đây là tin nhắn mang thông tin đơn thuần. Không có hành động người dùng được yêu cầu.
[05:56:47pm, once]Đã hoàn tất khôi phục cho cơ sở dữ liệu XXXXXXXXXX (ID cơ sở dữ liệu 7) trong 2505 giây (phân tích 1774 ms làm lại 406623 ms cho đến 1749182 ms.) Đây chỉ là một thông tin. Không có hành động người dùng được yêu cầu.
Tôi không tìm thấy mục nhật ký liên quan nào khác trong Nhật ký lỗi hoặc Trình xem sự kiện. Lỗi gần nhất xảy ra trong Trình xem sự kiện là:
[04:56:45pm ~ 05:27:24pm, 13 times]Cài đặt quyền dành riêng cho ứng dụng không cấp quyền Kích hoạt cục bộ cho ứng dụng COM Server với CLSID {FDC3723D-1588-4BA3-92D4-42C430735D7D} và APPID {83B33982-693D-4824-B42E-7196AE61BB05 Personal.user SID (S-1-5-21-000000000-000000000-0000000000-00000) từ địa chỉ Localhost (Sử dụng LRPC) đang chạy trong bộ chứa ứng dụng SID không khả dụng (Không khả dụng). Quyền bảo mật này có thể được sửa đổi bằng công cụ quản trị Dịch vụ thành phần.
Lỗi này xảy ra khoảng ~ 18 phút trước khi cơ sở dữ liệu bắt đầu quá trình khôi phục và đôi khi lặp lại trong quá trình bắt đầu khôi phục. Nó có phần liên quan đến người dùng DBA, nhưng tôi thực sự không biết nó là gì (tôi chưa có thời gian để hỏi về DBA).