Cơ sở dữ liệu luôn khởi động ở chế độ phục hồi


11

Mỗi khi tôi khởi động lại máy chủ của mình, cơ sở dữ liệu luôn ở chế độ phục hồi và mất khoảng 20 phút để nó hoạt động như bình thường. Điều này luôn luôn và chỉ xảy ra khi tôi khởi động lại máy chủ, vì vậy tôi có một vài câu hỏi ...

  1. Tôi đã nói điều này có thể được gây ra bởi một tệp nhật ký lớn? Điều đó có thể đúng không? Nếu không thì những nguyên nhân khác có thể là gì?
  2. Tôi cần phải giảm không gian của tệp nhật ký để ngăn phục hồi. Điều gì là tốt hơn: thu hẹp hoặc cắt ngắn?
  3. Làm cách nào tôi có thể thu nhỏ hoặc cắt bớt tệp nhật ký / cơ sở dữ liệu để giảm kích thước? Cú pháp là gì?

Tôi hiện đang sử dụng Microsoft SQL Server 2008.


Bạn có xu hướng có các giao dịch lớn trong chuyến bay khi bạn tắt máy? Khoảng thời gian phục hồi được đặt là gì?
Martin Smith

không có hành động nào được thực hiện 20 phút trước khi máy chủ khởi động lại, ngoài các câu lệnh chọn, khoảng thời gian được đặt là 0.

Bạn có thường xuyên bắt đầu lại không? Làm thế nào thường xuyên bạn sao lưu cơ sở dữ liệu? Tôi tự hỏi tại sao bạn lại khởi động máy chủ một cách thường xuyên? Để hoàn thành, bạn có thể kiểm tra thủ công cơ sở dữ liệu (xóa nhật ký) nếu cần.
Lynn Langit

"Để hoàn thành, bạn có thể kiểm tra thủ công một cơ sở dữ liệu (sẽ xóa nhật ký) nếu cần." làm thế nào có thể được thực hiện? và khi bạn nói xóa nhật ký, ý bạn là không sử dụng hay đơn giản là xóa sạch nhật ký?

Không đủ thông tin. Mô hình phục hồi? Bạn đang sử dụng các tính năng như phản chiếu hoặc nhân rộng? Kích thước của cơ sở dữ liệu và các tập tin liên quan? Liệu cơ sở dữ liệu xử lý bất kỳ giao dịch lớn?
Jon Seigel

Câu trả lời:


6

Tôi có cùng một vấn đề và tôi tin rằng tôi đã giải quyết nó nhưng tôi chưa thể kiểm tra đầy đủ để xác nhận.

Tôi tin rằng các vấn đề liên quan đến số lượng VLF bạn có trong tệp nhật ký của bạn chứ không phải kích thước của nó. Nếu bạn có một logfile lớn, có khả năng nó đã tăng trưởng hữu cơ thông qua các sự kiện tăng trưởng tự động và đó không phải là sự tăng trưởng theo kế hoạch có chủ ý. Nếu đó là trường hợp, bạn có thể có hàng ngàn VLF bên trong các tệp nhật ký.

Đây là một truy vấn để xem bạn có bao nhiêu VLF mà tôi đã sử dụng từ đây :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Để được giải thích thêm về những gì VLF đang xem liên kết này .

Tôi tin rằng vấn đề là với rất nhiều VLF, máy chủ SQL phải mất một thời gian dài để đánh giá trạng thái của chúng và sau đó đưa cơ sở dữ liệu ra khỏi phục hồi. Nếu bạn thu nhỏ tệp nhật ký của mình đến kích thước nhỏ nhất bạn có thể, thường là kích thước của VLF đầu tiên được tạo trong tệp nhật ký, thì bạn có thể ngay lập tức cố tình phát triển lại và do đó tạo ra số lượng VLF phù hợp (ít hơn 16).

Khi điều này hoàn tất, tôi tin rằng bạn sẽ có thể thấy rằng cơ sở dữ liệu của bạn được khôi phục nhanh hơn nhiều.

Tôi chưa có cơ hội kiểm tra thất bại đối với các trường hợp sản xuất của chúng tôi sau khi tôi giải quyết các vấn đề về VLF của chính chúng tôi vì vậy tôi sẽ rất tò mò nếu bạn có thể xác nhận đây là nguyên nhân cốt lõi của vấn đề. Thực nghiệm tôi đã thấy thời gian cần thiết để khôi phục lại trong môi trường dàn dựng của chúng tôi giảm đáng kể do điều này vì vậy hy vọng đó là nó.



2

Từ bài viết MSDN này :

Các giao dịch không được cam kết kéo dài làm tăng thời gian phục hồi cho tất cả các loại điểm kiểm tra.

Thông thường không nên chạy bất kỳ loại DBCC nào trên cơ sở dữ liệu sản xuất. Đồng thời đăng nhập hành vi cắt ngắn đã thay đổi từ các phiên bản trước sang năm 2008 (cảm ơn @Edward) - trên mỗi blog này :

Nhật ký sao lưu với trucate_only không còn được hỗ trợ trong SQL 2008. Nếu cơ sở dữ liệu của bạn ở dạng mô hình khôi phục hàng loạt hoặc khôi phục đầy đủ thì hãy lên lịch sao lưu T-Log theo định kỳ và nó sẽ giữ cho nhật ký t của bạn được định hình.

Một lần nữa, tôi sẽ đề cập, tần suất bạn sao lưu cơ sở dữ liệu? Thông thường, sao lưu thường xuyên "quản lý" kích thước nhật ký tốt nhất.


0

Giảm kích thước của nhật ký giao dịch trực tuyến có thể khắc phục sự cố, tức là tăng tốc cơ sở dữ liệu trực tuyến, nhưng bạn nên suy nghĩ về việc khắc phục thảm họa trước khi bạn làm điều đó. Lưu ý rằng nếu bạn đang ở trong mô hình khôi phục Đơn giản, bạn sẽ không thể khôi phục đến một thời điểm. Mặt khác, nếu bạn đang ở trong mô hình phục hồi ĐẦY ĐỦ, cách tốt nhất để giữ kích thước của nhật ký giao dịch trực tuyến là tạo bản sao lưu nhật ký giao dịch trên cơ sở thông thường (lên lịch).

Cắt bớt nhật ký giao dịch không có dung lượng đĩa cứng vật lý miễn phí, nó chỉ cho phép SQL Server sử dụng lại không gian đó cho các giao dịch đã xảy ra kể từ CHEKPOINT cuối cùng (kể từ lần sao lưu nhật ký giao dịch cuối cùng).

Nếu bạn thu nhỏ cơ sở dữ liệu, bạn sẽ giảm kích thước của tệp. Để thu nhỏ cơ sở dữ liệu MyDB 15 phần trăm:

DBCC SHRINKDATABASE (MyDB, 15); ĐI

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.