Перенос большого количества баз данных 1С с устаревшего сервера SQL Server 2008R2 на современный SQL Server 2019 является распространенной, но ответственной задачей. Мы рассмотрим оптимальные методы миграции, обеспечивающие минимальные трудозатраты и высокую надежность, а также разберем необходимые шаги по подготовке нового сервера и устранению возможных проблем. Наша цель – максимально автоматизировать процесс и убедиться в корректной работе всех баз после переноса.
Прежде чем приступать к переносу баз данных, критически важно правильно подготовить новый сервер SQL Server 2019. Эффективность работы 1С:Предприятие напрямую зависит от настроек SQL Server и характеристик оборудования.
Фирма "1С" активно поддерживает использование Microsoft SQL Server для повышения производительности системы, особенно при росте числа пользователей и сложности операций. Для оптимальной работы мы рекомендуем использовать операционную систему Windows Server 2016 или новее (предпочтительно 2019/2022) и SQL Server 2016 или новее (также рекомендуются 2019/2022).
Минимальные требования к оборудованию для сервера 1С и SQL Server включают:
Правильная настройка SQL Server имеет решающее значение для производительности 1С. Разберем ключевые параметры, которые мы должны оптимизировать:
Если сервер 1С и SQL Server расположены на одной физической или виртуальной машине, мы обязательно включаем протокол Shared Memory. Это позволяет приложениям (в нашем случае, серверу 1С) общаться с SQL Server через оперативную память, минуя сетевые интерфейсы. Такой подход значительно ускоряет взаимодействие и снижает задержки.
Мы должны установить максимальный объем памяти для SQL Server. Для этого настраиваем параметр maximum server memory (MB). Важно оставить достаточно оперативной памяти для операционной системы (обычно 2-4 ГБ) и для сервера 1С (приблизительно 1.5 ГБ на каждый процесс rphost). Недостаток памяти для ОС или 1С может привести к общей нестабильности системы и снижению производительности.
Для баз данных с типичной для 1С нагрузкой мы рекомендуем установить параметр MAXDOP (Maximum degree of parallelism) в значение 1. Опыт показывает, что запросы, генерируемые 1С, часто плохо распараллеливаются, и при значении MAXDOP > 1 могут возникать неоправданные задержки. Установка MAXDOP = 1 заставляет SQL Server выполнять каждый запрос в одном потоке, что для многих задач 1С оказывается более эффективным.
Мы должны убедиться, что диски, на которых будут располагаться файлы баз данных (.mdf, .ndf), журналы транзакций (.ldf) и системная база данных tempdb, отформатированы с размером кластера 64 КБ. Этот размер кластера является оптимальным для работы SQL Server.
База данных tempdb является критически важной для производительности SQL Server и 1С. Мы рекомендуем по возможности выделить tempdb на отдельный, максимально быстрый диск (SSD/NVMe). Также важно создать достаточное количество файлов данных для tempdb, чтобы равномерно распределить нагрузку. Общепринятая рекомендация – 1 файл на каждое ядро процессора, но не более 8 файлов. Каждый файл должен быть одинакового размера.
Мы должны создать и настроить планы обслуживания SQL Server. Это включает:
Мы включаем параметр "Lock pages in memory" (Закрепление страниц в памяти) для учетной записи, от имени которой работает служба SQL Server. Эта настройка предотвращает выгрузку страниц памяти SQL Server в файл подкачки (page file), что значительно повышает производительность, особенно при высокой нагрузке на память.
Для переноса 86 баз данных 1С с SQL Server 2008R2 на SQL Server 2019 мы можем использовать несколько методов. Разберем каждый из них, учитывая их особенности и преимущества.
Этот метод является одним из наиболее надежных и широко используемых. Хорошая новость состоит в том, что SQL Server 2019 поддерживает восстановление резервных копий, созданных в SQL Server 2008 и более поздних версиях, при условии, что уровень совместимости базы данных составляет 100 или выше. Если уровень совместимости равен 90 (например, для баз с SQL Server 2005), он будет автоматически повышен до 100 при восстановлении.
На SQL Server 2008R2 для каждой из 86 баз мы создаем полные резервные копии (full backup). Это можно сделать через SQL Server Management Studio (SSMS) или с помощью команды T-SQL BACKUP DATABASE [ИмяБазы] TO DISK = 'ПутьКФайлуБэкапа.bak' WITH NOFORMAT, NOINIT, NAME = N'ИмяБазы-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10;.
Мы копируем все созданные файлы .bak на новый сервер SQL Server 2019.
На SQL Server 2019 мы выполняем процедуру восстановления для каждой базы. Это также можно сделать через SSMS: ПКМ на "Databases" -> "Restore Database...", указываем путь к файлу .bak.
Альтернативно, можно использовать T-SQL команду:
RESTORE DATABASE [ИмяБазы]
FROM DISK = N'ПутьКФайлуБэкапа.bak'
WITH FILE = 1,
MOVE N'ИмяФайлаЛогическойБазы' TO N'ПутьКНовомуMDF.mdf',
MOVE N'ИмяФайлаЛогическогоЖурнала' TO N'ПутьКНовомуLDF.ldf',
NOUNLOAD, REPLACE, STATS = 5;
Важно: Убедитесь, что логические имена файлов (ИмяФайлаЛогическойБазы и ИмяФайлаЛогическогоЖурнала) соответствуют тем, что были в оригинальной базе. Их можно узнать, выполнив RESTORE FILELISTONLY FROM DISK = N'ПутьКФайлуБэкапа.bak';
В процессе восстановления мы можем столкнуться с ошибкой:
ЗАГОЛОВОК: Microsoft SQL Server Management Studio
------------------------------
Ошибка восстановления базы данных "---------". (Microsoft.SqlServer.Management.RelationalEngineTasks)
------------------------------
ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ:
System.Data.SqlClient.SqlError: Инструкцию BACKUP LOG невозможно выполнить, так как не существует резервной копии текущей базы данных. (Microsoft.SqlServer.SmoExtended)
Чтобы получить справку, щелкните:
Эта ошибка возникает, когда SQL Server пытается выполнить "резервное копирование заключительного фрагмента журнала" (tail-log backup), но не находит предыдущих полных бэкапов или для данной операции оно не требуется. Чтобы успешно восстановить базу данных, мы просто снимаем опцию "Создать резервную копию заключительного фрагмента журнала" (Take tail-log backup) в окне восстановления SSMS. После этого восстановление должно пройти без проблем.
Этот метод подразумевает прямое копирование файлов базы данных (.mdf, .ndf, .ldf) со старого сервера на новый. Он часто оказывается быстрее для больших баз, так как не требует создания и восстановления бэкапов.
Для каждой базы мы отсоединяем ее от SQL Server. Это можно сделать через SSMS: ПКМ на базе -> "Tasks" -> "Detach...". Убедитесь, что отмечены опции "Drop Connections" (разорвать соединения) и "Update Statistics" (обновить статистику).
Через T-SQL команда выглядит так:
EXEC sp_detach_db 'ИмяБазы', 'true';
Параметр 'true' означает, что база будет отсоединена, даже если есть активные соединения.
После отсоединения мы можем безопасно скопировать файлы .mdf, .ndf и .ldf всех баз данных из каталога данных старого SQL Server на новый сервер SQL Server 2019.
На новом сервере мы присоединяем скопированные файлы к экземпляру SQL Server. Через SSMS: ПКМ на "Databases" -> "Attach...", затем указываем путь к файлу .mdf и SSMS автоматически найдет соответствующие .ndf и .ldf файлы.
Через T-SQL команда будет следующей:
CREATE DATABASE [ИмяБазы] ON
(FILENAME = N'ПутьКФайлуMDF.mdf'),
(FILENAME = N'ПутьКФайлуLDF.ldf')
FOR ATTACH;
После присоединения базы данных мы должны проверить и при необходимости изменить ее уровень совместимости на новый. Для SQL Server 2019 оптимальным будет 150 (для SQL Server 2019) или 140 (для SQL Server 2017). Это можно сделать через SSMS: ПКМ на базе -> "Properties" -> "Options" -> "Compatibility level". Или с помощью T-SQL:
ALTER DATABASE [ИмяБазы] SET COMPATIBILITY_LEVEL = 150;
Для автоматизации процесса `detach/attach` для 86 баз данных мы можем использовать PowerShell-модуль dbatools. Это мощный инструмент, который объединяет большинство функций миграции в одну команду, включая базы данных, логины, конфигурацию сервера и серверные объекты. Использование dbatools гарантирует, что идентификаторы безопасности пользователей (SID) совпадают на целевом сервере, что позволяет избежать проблем с "осиротевшими" логинами SQL.
Команда Start-DbaMigration может выполнить полный перенос экземпляра, включая базы данных методом `detach/copy/attach` или `backup/restore`.
Например, для переноса баз данных методом `detach/attach` с помощью dbatools, мы можем использовать что-то вроде:
# Установите dbatools, если еще не установлено
# Install-Module -Name dbatools -Force
# Перенос всех баз данных с исходного на целевой сервер
Start-DbaMigration -Source SQL2008R2Server -Destination SQL2019Server -Database all -Method DetachAttach -FileCopy NetworkSharePath
Где SQL2008R2Server и SQL2019Server – имена ваших серверов, а NetworkSharePath – путь к сетевой папке, доступной обоим серверам для временного размещения файлов баз данных.
Помимо баз данных, мы можем захотеть перенести список баз 1С (файл 1Cv8.lst) с сервера 1С. Этот файл обычно находится в папке с серверными компонентами 1С и содержит список зарегистрированных информационных баз.
Хотя Microsoft рекомендует использовать Database Migration Assistant (DMA), мы также можем использовать SQL Server Management Studio (SSMS) для миграции схемы и данных. Этот метод больше подходит для миграции структуры базы данных и данных, когда прямой перенос файлов или бэкапов невозможен или нежелателен.
На старом сервере мы используем функцию SSMS "Generate Scripts" (ПКМ на базе -> "Tasks" -> "Generate Scripts...") для создания скриптов всех объектов базы данных (таблиц, представлений, хранимых процедур, функций, индексов и т.д.). Мы должны выбрать опцию "Script Data" (скрипт данных) для включения данных в скрипт, если базы небольшие, или "Schema Only" (только схема), если данных много.
Мы выполняем сгенерированные скрипты на новом сервере SQL Server 2019 для создания структуры пустых баз данных.
Затем мы используем функцию SSMS "Export Data" (ПКМ на базе -> "Tasks" -> "Export Data...") для переноса данных из таблиц старой базы в новую. При этом важно включить опцию "Enable identity insert" для столбцов первичных ключей (IDENTITY), чтобы сохранить существующие значения ключей. Также мы должны игнорировать столбцы с метками времени (timestamp), так как они могут вызвать ошибки при переносе.
Метод передачи журналов (Log Shipping) поддерживается при миграции с SQL Server 2008 SP3 или более поздней версии (или SQL Server 2008 R2 SP2 или более поздней версии) на SQL Server 2019. Этот метод позволяет поддерживать актуальную копию базы данных на целевом сервере с минимальным временем простоя. Однако, следует учесть, что если произойдет автоматическое или ручное переключение на SQL Server 2019, экземпляр SQL Server 2008/2008 R2, ставший вторичным, не сможет получать изменения от нового первичного сервера. Этот метод более сложен в настройке и управлении, но может быть полезен для критически важных баз с необходимостью минимального простоя.
Независимо от выбранного метода переноса, мы должны провести тщательное тестирование перенесенных баз данных на новом сервере. Особенно это актуально для 1С, где важно проверить не только доступность базы, но и корректность работы всех бизнес-процессов.
Мы начинаем с переноса одной небольшой, но представительной базы данных. Это позволит нам выявить и устранить потенциальные ошибки в правилах конвертации, несоответствия в отчетах старой и новой баз, а также проблемы с корректностью движений по регистрам.
На новом сервере мы открываем перенесенные базы 1С, проводим типовые операции (создание документов, проведение, формирование отчетов), проверяем работу всех подсистем, которые активно используются.
Мы анализируем производительность системы под нагрузкой. Сравниваем время выполнения ключевых операций на старом и новом сервере. Если есть проблемы, возвращаемся к настройкам SQL Server и серверу 1С.
Убедимся, что версия платформы 1С на новом сервере совместима с версией SQL Server 2019. Обычно 1С поддерживает SQL Server на 2-3 версии назад, но всегда лучше проверить актуальную информацию в документации 1С.
При переносе баз данных, особенно методом `detach/attach` или `backup/restore` без использования dbatools, могут возникнуть проблемы с пользователями, если их SID (идентификаторы безопасности) на новом сервере не совпадают с SID, сохраненными в базе данных. В этом случае мы можем увидеть "осиротевших" пользователей. Их можно исправить вручную, связав пользователей базы данных с существующими логинами SQL Server, или используя команду:
ALTER USER [ИмяПользователя] WITH LOGIN = [ИмяЛогина];
При использовании Microsoft SQL Server 2019 для 1С:Предприятие 8 мы должны быть внимательны к вопросам лицензирования. Существуют два основных типа лицензий: Runtime и Full-Use. Важно помнить, что покупатель должен быть владельцем лицензий "1С:Предприятие 8". При потере права на использование 1С, также теряется и право на использование соответствующей лицензии SQL Server.
Перенос 86 баз данных 1С с SQL Server 2008R2 на SQL Server 2019 — это значительный шаг к модернизации инфраструктуры. Мы рассмотрели несколько эффективных методов миграции, включая восстановление из резервных копий и отсоединение/присоединение файлов баз данных, с возможностью автоматизации с помощью dbatools. Мы также выяснили, как решать распространенные проблемы и настраивать новый SQL Server для оптимальной работы 1С.
Помните, что ключевым моментом для успешной миграции является тщательная подготовка, тестирование на одной тестовой базе и планомерный перенос всех остальных баз, по возможности, вне рабочих часов. Это позволит нам минимизировать риски и обеспечить стабильную и быструю работу вашей системы 1С на новом, современном оборудовании.