Как восстановить резервную копию базы данных MS SQL Server 2000 на сервере MS SQL 2008?

Системный администратор IT и автоматизация бизнеса
← На главную

Перенос рабочей базы данных между серверами СУБД разных поколений — стандартная задача при модернизации инфраструктуры. Однако при попытке развернуть бэкап, созданный в MS SQL Server 2000, на более современном MS SQL Server 2008, администраторы часто сталкиваются с ошибками восстановления. Разберем основные причины сбоев и пошагово рассмотрим правильные алгоритмы миграции базы данных.

Причины ошибок при восстановлении базы на новом сервере

Проанализируем ключевые факторы, которые приводят к ошибкам при разворачивании базы:

  1. Несовпадение путей к файлам данных и журналов: резервная копия хранит исходные абсолютные пути к файлам .mdf и .ldf. Если на целевом сервере отсутствует нужная буква диска или каталог, процедура завершится ошибкой.
  2. Попытка перезаписи существующей базы: если на целевом сервере предварительно создана чистая база с таким же именем, SQL Server заблокирует перезапись без явного указания параметра замещения.
  3. Несовместимость сборок СУБД: прямой перенос бэкапа на SQL Server 2008 поддерживается только в том случае, если исходный SQL Server 2000 обновлен до уровня Service Pack 3 (SP3) или Service Pack 4 (SP4) (номер сборки не ниже 8.00.760). Если исходный экземпляр работает на версиях RTM, SP1 или SP2, процедура обновления структур завершится критическим сбоем.

Способ 1. Восстановление средствами T-SQL с параметрами WITH MOVE и WITH REPLACE

Наиболее надежным и контролируемым методом разворачивания бэкапа является выполнение скрипта в SQL Server Management Studio (SSMS). Сначала определим логические имена файлов внутри резервной копии:


RESTORE FILELISTONLY 
FROM DISK = 'C:\bu\mm.bak';

В результате выполнения запроса в колонке LogicalName мы увидим имена файлов базы данных и журнала транзакций. Теперь выполним команду восстановления, явно перенаправив файлы в актуальные каталоги нового сервера с помощью параметра WITH MOVE, а также применив WITH REPLACE для перезаписи существующей целевой базы:


RESTORE DATABASE NewDBName 
FROM DISK = 'C:\bu\mm.bak' 
WITH 
    MOVE 'OldDB' TO 'C:\Data\new_mm.mdf', 
    MOVE 'OldDB_Log' TO 'C:\Data\new_mm_log.ldf',
    REPLACE,
    STATS = 10;

Параметр STATS = 10 выводит прогресс выполнения операции с шагом в 10%, что позволяет отслеживать процесс разворачивания больших баз данных.

Способ 2. Перенос через физическое копирование и операцию Attach

Если бэкап по каким-либо причинам не разворачивается, рассмотрим альтернативный вариант — прямое подключение файлов базы данных (Attach):

  1. Останавливаем службу SQL Server на старом сервере или переводим базу данных в режим OFFLINE.
  2. Копируем файлы .mdf и .ldf на новый сервер.
  3. На новом сервере SQL 2008 выполняем подключение базы данных с помощью команды T-SQL:

CREATE DATABASE NewDBName 
ON (FILENAME = 'C:\Data\new_mm.mdf'), 
   (FILENAME = 'C:\Data\new_mm_log.ldf') 
FOR ATTACH;

Промежуточная миграция через MS SQL Server 2005

Если исходная база SQL Server 2000 не имела установленных пакетов SP3/SP4 и обновить старый сервер невозможно, прямой перенос на SQL 2008 завершится ошибкой. В такой ситуации разберем промежуточный этап: разворачиваем бэкап на временном экземпляре MS SQL Server 2005, делаем свежую резервную копию и после этого успешно восстанавливаем её на целевом MS SQL Server 2008.

Обязательные действия после восстановления базы 1С

После успешного завершения команды RESTORE база переходит в рабочий режим, однако для стабильной работы платформы 1С необходимо выполнить регламентные шаги:

  1. Проверка целостности данных: в SQL 2000 отсутствовал строгий контроль корректности типов datetime. Обязательно выполним команду: DBCC CHECKDB ('NewDBName') WITH DATA_PURITY;
  2. Перевод уровня совместимости и обновление статистики: для оптимизации планов выполнения запросов 1С переведем базу на актуальный уровень и выполним полный пересчет статистик:
    
    ALTER DATABASE NewDBName SET COMPATIBILITY_LEVEL = 100;
    GO
    USE NewDBName;
    GO
    EXEC sp_updatestats;
    
  3. Устранение «осиротевших» пользователей (Orphaned Users): при переносе базы идентификаторы безопасности пользователей базы (SID) теряют связь с учетными записями сервера (Logins). Для восстановления прав учетной записи 1С выполним:
    
    USE NewDBName;
    GO
    EXEC sp_change_users_login 'Auto_Fix', 'ИмяПользователя1С';
    
  4. Проверка параметров сортировки (Collation): убедимся, что параметры сортировки восстановленной базы и системной базы tempdb совпадают (для русскоязычных конфигураций 1С стандартным является Cyrillic_General_CI_AS). Несовпадение Collation приведет к падению запросов с временными таблицами.

Почему выгрузка через .dt не заменяет бэкап СУБД?

Рассмотрим вопрос использования штатной выгрузки информационной базы в файл .dt средствами конфигуратора 1С. Выгрузка в .dt предназначена для переноса данных между разными типами СУБД или перехода в файловый режим. На базах объемом в десятки гигабайт штатная выгрузка и загрузка не гарантируют целостность данных, создают пиковую нагрузку на сервер и могут завершиться аварийно по нехватке памяти. Единственным надежным способом резервного копирования и миграции высоконагруженных систем 1С остается создание и восстановление бэкапов средствами самой СУБД MS SQL Server.

← На главную