Резервное копирование всех баз данных + сценарии создания индекса? - PullRequest
1 голос
/ 27 августа 2011

Я пытался сделать резервную копию всех своих баз данных SQL Server и наткнулся на следующий скрипт из здесь :

DECLARE @name VARCHAR(50) -- database name  
DECLARE @path VARCHAR(256) -- path for backup files  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name 

SET @path = 'C:\Backup\'  

SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) 

DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM master.dbo.sysdatabases 
WHERE name NOT IN ('master','model','msdb','tempdb')  

OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

WHILE @@FETCH_STATUS = 0   
BEGIN   
       SET @fileName = @path + @name + '_' + @fileDate + '.BAK'  
       BACKUP DATABASE @name TO DISK = @fileName  

       FETCH NEXT FROM db_cursor INTO @name   
END   

CLOSE db_cursor   
DEALLOCATE db_cursor

Это прекрасно работает, за исключением того, что я думаю, что я 'Придется восстановить все индексы базы данных после того, как я восстановлю ее.Я хотел знать, можно ли вывести операторы CREATE для всех индексов, чтобы я мог повторно запустить их за один раз после восстановления всех этих баз данных?

1 Ответ

2 голосов
/ 27 августа 2011

Это регулярная операция резервного копирования? Если нет, то он должен добавить предложение WITH COPY_ONLY, в противном случае он разрывает цепочку резервного копирования.

В качестве обычной резервной копии для технического обслуживания это довольно плохо:

  • игнорирует каждую модель восстановления базы данных (может отличаться)
  • он не справляется с задачей планирования полного / разностного / резервного копирования журнала (т. Е. Использует слишком много дискового пространства и приводит к слишком большой потере данных при аварийном восстановлении)
  • это небезопасно, одна ошибка дБ приведет к сбою всего цикла
  • не очищает сгенерированные имена файлов (например, база данных с именем [a:b] создаст недопустимое имя файла и всегда завершится ошибкой).
  • не поддерживает старые резервные копии и не освобождает дисковое пространство от устаревших резервных копий
  • он не допускает такие вещи, как сжатие резервных копий
  • резервное копирование на тот же диск, что и база данных, - бесполезная иллюзия безопасности, вы все равно потеряете все данные при потере диска

Но в конечном итоге фундаментальная проблема заключается в том, что вы смотрите на это с неправильной точки зрения. Ваша цель - не иметь план резервного копирования, а иметь план восстановления . Подробнее читайте здесь: Важность тестирования вашего плана аварийного восстановления . И, кстати, вам нужен план восстановления для master тоже.

Что касается вашего вопроса об индексах, я не думаю, что вы понимаете, как работает резервное копирование SQL Server. Начните здесь: SQL Server: восстановление после аварийных ситуаций с использованием резервных копий

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...