Nhiệm vụ sao lưu theo lịch trình không phải lúc nào cũng sao lưu tất cả các cơ sở dữ liệu mặc dù luôn nói rằng công việc thành công

Tôi có một công việc trong SQL 2008 chạy một Proc được lưu trữ để sao lưu tất cả các cơ sở dữ liệu. Điều này chạy hàng ngày thông qua công việc đại lý máy chủ sql.

Nó thoát khỏi thành công mỗi ngày nhưng một số ngày nó thoát khỏi thành công chỉ sau khi sao lưu một vài cơ sở dữ liệu. Nó có thể là số lượng cơ sở dữ liệu khác nhau mỗi lần. Hầu hết các ngày nó sao lưu thành công tất cả các cơ sở dữ liệu nhưng đôi khi 2 sao lưu thành công, đôi khi 5, v.v.

Tôi không thấy bất kỳ lỗi nào trong lịch sử công việc, trình xem sự kiện hoặc nhật ký máy chủ sql.

Các bản sao lưu đang diễn ra vào một đĩa cục bộ, mặc dù thư mục là một "điểm nối" với một thư mục trên một dung lượng lưu trữ có thể mở rộng.

HĐH là Windows 2003 64bit chạy phiên bản web Sql Server 2008 64 bit dưới dạng máy ảo chạy trên máy chủ Vmware ESXi 5.

Thủ tục lưu trữ:

ALTER PROCEDURE [dbo].[backup_all_databases] 
@path VARCHAR(255)='c:\backups\'

AS

DECLARE @name VARCHAR(50) -- database name  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name 
DECLARE @dbIsReadOnly sql_variant -- is database read_only?
DECLARE @dbIsOffline sql_variant -- is database offline?

DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM master.dbo.sysdatabases 
WHERE name NOT IN ('tempdb')
AND version > 0 AND version IS NOT NULL

OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

WHILE @@FETCH_STATUS = 0   
BEGIN   
SET @fileName = @path + @name + '.bak'

SET @dbIsReadOnly = (SELECT DATABASEPROPERTY(@name, 'IsReadOnly')) -- 1 = Read Only
SET @dbIsOffline = (SELECT DATABASEPROPERTY(@name, 'IsOffline')) -- 1 = Offline

IF (@dbIsReadOnly = 0 OR @dbIsReadOnly IS NULL) AND @dbIsOffline =0
BEGIN
    BACKUP DATABASE @name TO DISK = @fileName  WITH INIT
    WAITFOR DELAY '00:00:20'
END

FETCH NEXT FROM db_cursor INTO @name 
END   

CLOSE db_cursor   
DEALLOCATE db_cursor

Có gợi ý nào không?

Tôi sẽ thêm các khối TRY / CATCH để xử lý lỗi và ghi lại chúng. DB có thể ở một người dùng, được khôi phục hoặc bất cứ điều gì.

Nếu không có điều này, các lỗi có thể hủy bỏ theo cách không có lỗi nào được ghi lại (câu lệnh, lô, phạm vi, kết nối, v.v.)

Với TRY / CATCH thì mọi thứ trừ lỗi biên dịch hoặc hủy kết nối đều được ghi lại? nhưng tôi nghi ngờ đây là trường hợp.

Tôi cũng sử dụng cơ sở dữ liệu sys.dat thay thế cơ sở dữ liệu sysdat và đọc thêm cờ:

-- declares etc

BEGIN TRY

    DECLARE db_cursor CURSOR FOR  
    SELECT name, state, user_access
    FROM sys.databases 
    WHERE name NOT IN ('tempdb')

    OPEN db_cursor   
    FETCH NEXT FROM db_cursor INTO @name, @state, @user_access

    WHILE @@FETCH_STATUS = 0   
    BEGIN   

        SET @fileName = @path + @name + '.bak'
        IF @state = 0 AND user_access = 0
        BEGIN
            BEGIN TRY
                BACKUP DATABASE @name TO DISK = @fileName  WITH INIT
            END TRY
            BEGIN CATCH
                -- log but do not rethrow so loop continues
            END CATCH
            WAITFOR DELAY '00:00:20'
        END
        ELSE
           --log user and/or state issues

        FETCH NEXT FROM db_cursor INTO @name 
    END   

    CLOSE db_cursor   
    DEALLOCATE db_cursor

END TRY
BEGIN CATCH
  -- some useful stuff here
END CATCH

Kiểm tra lỗi sau lệnh "sao lưu", gửi email của riêng bạn xem có lỗi nào được phát hiện không.

Điều này sẽ cung cấp cho bạn một điểm khởi đầu để xem những gì đang xảy ra và đảm bảo cảnh báo cho bạn về bất kỳ vấn đề nào cho đến khi bạn giải quyết được vấn đề công việc.

Đặt một đơn đặt hàng trên con trỏ. Tôi đã thấy các con trỏ đến sys.database có "vấn đề" khi bạn cho phép SQL chọn thứ tự dữ liệu được trả về. Đặt hàng theo tên nên là đủ.

Là bản sao lưu đang chạy cùng lúc với bản sao lưu vào băng hoặc một số quá trình sao chép hoặc truy cập các tệp sao lưu? Nếu vậy, tôi cá là nó không ghi đè lên tệp vì nó đang được sử dụng. Nếu bạn có chỗ cho nhiều bản sao lưu, bạn có thể thay đổi Proc của mình để thêm dấu ngày vào tệp đầu ra, nhưng sau đó bạn sẽ cần một thói quen dọn dẹp.

Với sự ra đời của SQL Server 2005, vòng lặp con trỏ thông qua sysdatabase và thậm chí sys.database dường như thay đổi nên không đáng tin cậy - và cũng có thể thấy sự thay đổi hành vi này với sp_foreachdb.

Tôi thấy việc thay đổi loại con trỏ đã giúp (tôi nghĩ rằng nó đã chuyển tiếp nhanh), nhưng cuối cùng tôi đã chuyển sang các giải pháp như giải pháp sao lưu và bảo trì của Ola Hallengren. Giống như hầu hết những thứ quan trọng như sao lưu, bạn vẫn cần kiểm tra chéo tất cả các cơ sở dữ liệu để đảm bảo chúng được sao lưu ngay cả với các giải pháp tiềm năng này - và rõ ràng là bạn đã làm rất tốt!

Các loại con trỏ: http://msdn.microsoft.com/en-us/l Library / ms378405 (v = MySQL.90) .aspx

Giải pháp bảo trì của Ola: http://ola.hallengren.com/

Tôi đã có cùng một vấn đề, đặc biệt là trong khi sao lưu các DB lớn.

@@fetch_statuslà một biến GLOBAL, do đó, nó có thể bị thay đổi (đặt thành 0) bởi một con trỏ khác so với con trỏ của bạn. Tôi đã giải quyết nó bằng cách làm như sau (bằng mã giả):

create a temp table with dbNames
select top 1 in a variable (use order by)
while variable is null
do your thing

set variable = null
delete top 1(use order by)
select top 1 in a variable (use order by)
loop

Tôi đã cố gắng tìm ra vấn đề này và có vẻ như nhiều lần người dùng đã đăng giải pháp rằng nếu bạn thực hiện khai báo con trỏ không nhạy cảm thì nó bắt đầu hoạt động. Vì vậy, tôi đã thử nghiệm nó và vâng, nó chỉ đảm bảo rằng con trỏ của bạn khai báo là tĩnh và nó bắt đầu hoạt động.

Thực tế là nó không thành công là - Kiểm tra cài đặt ngưỡng con trỏ ở cấp máy chủ của bạn - nếu nó được định cấu hình là -1 thì điều đó có nghĩa là tất cả các con trỏ đang được đồng bộ hóa trong các từ khác trong khi cố gắng đọc dữ liệu của bộ con trỏ là đồng bộ và tất cả đều cố gắng đọc cùng một lúc Nếu chúng tôi thay đổi giá trị này thành 0, yêu cầu máy chủ SQL thực hiện một quần thể không đồng bộ bằng các từ đơn giản, con trỏ có thể tìm nạp các bản ghi trong khi bộ khóa vẫn sẽ được điền và bạn sẽ thấy rằng sau khi thực hiện thay đổi này ở cấp máy chủ, bạn sẽ không bao giờ bỏ lỡ bất kỳ cơ sở dữ liệu nào bằng cách sử dụng con trỏ

Giải pháp: Hoặc khai báo cài đặt cấp độ con trỏ tĩnh hoặc thay đổi cài đặt cấp độ "Ngưỡng con trỏ" thành 0 từ -1.

Cảm ơn, Gaurav Mishra | DBA cao cấp