Ошибка в том, что я использую курсор или есть проблема с остальной частью этого сценария? - PullRequest
0 голосов
/ 07 июля 2011

Этот код прекрасно работает в SQL 2005, но, по-видимому, пропускает произвольное количество записей в конце выбора в SQL 2008 или SQL 2008R2.Я использую этот код для резервного копирования баз данных на моих производственных серверах.Сервер 2008 имеет 37 дБ (не считая tempdb), и каждый день он резервирует от 17 до 35 из этих дБ (даже если я запускаю команду select, мне всегда возвращается 37 строк).Задание, в котором оно выполняется, не содержит ошибок, но не создает резервные копии всех баз данных.

DECLARE @today VARCHAR(10)
SELECT @today = Convert(varchar(10),dateadd(day,0,Dateadd(day,datediff(day,0,getdate()),0)),120)

DECLARE @DBName varchar(500)
DECLARE DB_Cursor CURSOR FOR
SELECT name FROM sys.databases 
OPEN DB_Cursor;
FETCH NEXT FROM DB_Cursor INTO @DBNAME
WHILE @@FETCH_STATUS = 0
   BEGIN
IF @DBNAME <> 'tempdb'
BEGIN
    declare @Path varchar(500)              
    select @Path = 'g:\DBBackups\'

    declare @FileName varchar(4000)
    select @FileName = @Path + @DBNAME + '_Full_' + @today + '.bak'

        BACKUP DATABASE @DBName 
            TO DISK = @FileName
            WITH NoInit, NoFormat, SKIP
END

  FETCH NEXT FROM DB_Cursor INTO @DBNAME;
END;
CLOSE DB_Cursor;
DEALLOCATE DB_Cursor;

Ответы [ 2 ]

1 голос
/ 07 июля 2011

Я кратко говорил об этом в следующем совете, «Создание более надежного и гибкого sp_MSforeachdb»:

http://mssqltips.com/tip.asp?tip=2201

Как правило, измените курсор на READ_ONLY LOCAL FORWARD_ONLY STATIC, и на вас не должны влиять блокировки или изменения в базах данных (это единственное сомнение, которое у меня есть для реального объяснения). Это было единственное истинное различие, которое я мог найти во всех случаях, когда загадочный пропуск базы данных не происходил.

Я не пытался исследовать значения @@FETCH_STATUS - возможно, что по мере продвижения курсора это изменится на значения, отличные от 0 и -1 (я обычно проверяю последние, а не первые). Так что, возможно, измените WHILE @@FETCH_STATUS = 0 на WHILE @@FETCH_STATUS <> -1.

0 голосов
/ 07 июля 2011

Или, еще лучше, вообще не используйте курсор.:)

Сценарий сильно испорчен.Он не проверяет состояние базы данных, поэтому, если у вас есть база данных, которая не подключена к сети, например зеркало базы данных или вторичная доставка журналов, процесс завершится неудачно, и все базы данных, которые появятся после этого, не будут сохранены.Кроме того, вы используете неправильные типы данных

...