ภารกิจการสำรองข้อมูลตามกำหนดเวลาไม่ได้ทำการสำรองฐานข้อมูลทั้งหมดเสมอ

ฉันมีงานใน SQL 2008 ที่รัน proc ที่เก็บไว้เพื่อสำรองฐานข้อมูลทั้งหมด สิ่งนี้รันทุกวันผ่านงานตัวแทนเซิร์ฟเวอร์ sql

มันหยุดทำงานด้วยความสำเร็จทุกวัน แต่บางวันก็หยุดทำงานด้วยความสำเร็จหลังจากทำการสำรองฐานข้อมูลบางส่วนเท่านั้น อาจเป็นจำนวนฐานข้อมูลที่แตกต่างกันในแต่ละครั้ง วันส่วนใหญ่จะสำเร็จการสำรองฐานข้อมูลทั้งหมด แต่บางครั้งการสำรองข้อมูล 2 สำเร็จบางครั้ง 5 เป็นต้น

ฉันไม่เห็นข้อผิดพลาดใด ๆ ในประวัติงาน, ตัวแสดงเหตุการณ์หรือบันทึกเซิร์ฟเวอร์ sql

กำลังสำรองข้อมูลไปยังดิสก์ภายในเครื่องแม้ว่าโฟลเดอร์จะเป็น "จุดเชื่อมต่อ" ไปยังโฟลเดอร์บนไดรฟ์ข้อมูลที่เก็บข้อมูลแบบขยายได้

ระบบปฏิบัติการ Windows 2003 64 บิตที่เรียกใช้ Sql Server 2008 web edition 64 บิตเป็นเครื่องเสมือนที่ทำงานบนโฮสต์ Vmware ESXi 5

ขั้นตอนการเก็บ:

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

ข้อเสนอแนะใด ๆ โปรด?

ฉันจะเพิ่มบล็อค TRY / CATCH เพื่อจัดการข้อผิดพลาดและบันทึก ฐานข้อมูลอาจอยู่ในผู้ใช้คนเดียวการกู้คืนหรืออะไรก็ตาม

หากปราศจากสิ่งนี้ข้อผิดพลาดสามารถยกเลิกได้ในลักษณะที่ไม่มีข้อผิดพลาดในการบันทึก (คำสั่งแบทช์ขอบเขตการเชื่อมต่อ ฯลฯ )

ด้วย TRY / CATCH ทุกอย่างยกเว้นข้อผิดพลาดในการคอมไพล์หรือการยกเลิกการเชื่อมต่อจะถูกบันทึกไว้หรือไม่? แต่ฉันสงสัยว่าเป็นกรณีนี้

ฉันยังใช้sys.databasesซึ่งแทนที่ sysdatabase และอ่านค่าสถานะเพิ่มเติม:

-- 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

ตรวจสอบข้อผิดพลาดหลังจากคำสั่ง "backup" ส่งอีเมลของคุณเองออกเพื่อตรวจพบข้อผิดพลาด

สิ่งนี้จะช่วยให้คุณเป็นจุดเริ่มต้นเพื่อดูว่าเกิดอะไรขึ้นและรับประกันว่าจะแจ้งเตือนคุณถึงปัญหาใด ๆ จนกว่าคุณจะมีปัญหาการแยกงาน

วางคำสั่งซื้อบนเคอร์เซอร์ ฉันเห็นเคอร์เซอร์ไปที่ sys.database มี "ปัญหา" เมื่อคุณอนุญาตให้ SQL เลือกลำดับข้อมูลที่ส่งคืน การสั่งซื้อด้วยชื่อควรจะเพียงพอ

การสำรองข้อมูลทำงานในเวลาเดียวกับการสำรองข้อมูลไปยังเทปหรือกระบวนการอื่น ๆ ในการคัดลอกหรือเข้าถึงไฟล์สำรองข้อมูลหรือไม่ ถ้าเป็นเช่นนั้นฉันคิดว่ามันล้มเหลวในการเขียนทับไฟล์เพราะใช้งานอยู่ หากคุณมีที่ว่างสำหรับสำเนาสำรองหลายชุดคุณสามารถเปลี่ยน proc ของคุณเพื่อเพิ่มการประทับวันที่ลงในไฟล์เอาต์พุตได้ แต่จากนั้นคุณต้องมีชุดคำสั่งการล้างข้อมูล

ด้วยการแนะนำของ SQL Server 2005 เคอร์เซอร์วนซ้ำผ่าน sysdatabase และแม้กระทั่ง sys.database ดูเหมือนจะเปลี่ยนแปลงดังนั้นมันจึงไม่น่าเชื่อถือ - และการเปลี่ยนแปลงในพฤติกรรมนี้สามารถเห็นได้ด้วย sp_foreachdb เช่นกัน

ฉันพบว่าการเปลี่ยนประเภทของเคอร์เซอร์ช่วย (ฉันคิดว่ามันเร็วไปข้างหน้า) แต่ในที่สุดฉันก็เปลี่ยนไปใช้โซลูชันเช่นโซลูชันสำรองและบำรุงรักษาของ Ola Hallengren เช่นเดียวกับสิ่งส่วนใหญ่ที่มีความสำคัญเช่นการสำรองข้อมูลคุณยังต้องตรวจสอบฐานข้อมูลทั้งหมดเพื่อให้แน่ใจว่ามีการสำรองข้อมูลแม้กระทั่งกับโซลูชันที่มีศักยภาพเหล่านี้และคุณก็ทำได้ดีมาก!

ประเภทเคอร์เซอร์: http://msdn.microsoft.com/en-us/library/ms378405(v=SQL.90).aspx

โซลูชันการบำรุงรักษาของ Ola: http://ola.hallengren.com/

ฉันมีปัญหาเดียวกันโดยเฉพาะในขณะที่สำรองฐานข้อมูลขนาดใหญ่

@@fetch_statusเป็นตัวแปร GLOBAL ดังนั้นจึงอาจมีการเปลี่ยนแปลง (ตั้งค่าเป็น 0) โดยเคอร์เซอร์อื่นกว่าของคุณ ฉันแก้ไขมันโดยทำสิ่งต่อไปนี้ (ในระบบหลอก):

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

ฉันพยายามที่จะเข้าใจปัญหานี้และดูเหมือนว่าผู้ใช้หลายคนโพสต์วิธีแก้ปัญหาว่าถ้าคุณทำให้การประกาศเคอร์เซอร์ไม่รู้สึกตัวก็จะเริ่มทำงาน ดังนั้นฉันจึงทดสอบและใช่มันแค่ทำให้แน่ใจว่าคุณเคอร์เซอร์ประกาศว่าเป็นแบบคงที่และจะเริ่มทำงาน

ความจริงที่มันล้มเหลวคือ - ตรวจสอบการตั้งค่าเคอร์เซอร์ระดับเซิร์ฟเวอร์ของคุณ - ถ้ามันถูกกำหนดค่าเป็น -1 นั่นหมายความว่าเคอร์เซอร์ทั้งหมดจะถูกซิงโครนัสพร้อมกันในคำอื่น ๆ ในขณะที่พยายามอ่านข้อมูล อ่านในเวลาเดียวกัน ถ้าเราเปลี่ยนค่านี้เป็น 0 ที่บอกให้เซิร์ฟเวอร์ SQL ทำการประชากรแบบอะซิงโครนัสในเคอร์เซอร์คำง่าย ๆ สามารถดึงข้อมูลในขณะที่ชุดคีย์จะยังคงอยู่และคุณจะเห็นว่าหลังจากทำการเปลี่ยนแปลงในระดับเซิร์ฟเวอร์แล้วคุณจะไม่พลาดฐานข้อมูลใด ๆ เคอร์เซอร์

การแก้ปัญหา: ประกาศการตั้งค่าระดับเคอร์เซอร์คงที่หรือเปลี่ยนระดับเซิร์ฟเวอร์ "เกณฑ์เคอร์เซอร์" เป็น 0 จาก -1

ขอบคุณ Gaurav Mishra | DBA อาวุโส