1С 8.0 + SQL Server: как мы переводили сорок пользователей с файловой базы

Когда два года назад мы разбирали механику файловой 1С, клиент-серверный вариант был реально дорогим: 1С 7.7 SQL требовала отдельной лицензии на SQL Server, отдельных навыков администрирования и вообще выглядела как история для крупных. У большинства клиентов было пять-двенадцать пользователей, и файловый режим их устраивал с оговорками.

Сейчас в работе другой кейс: торгово-производственная компания, сорок рабочих мест, одна общая 1С 7.7 на файловой базе. Сорок - это уже не «устраивает с оговорками». Это «по понедельникам база встаёт, бухгалтерия звонит матом в 9:20».

Почему 8.0, а не просто 7.7 на SQL

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

На 7.7 переход на SQL тоже возможен, но это тупик: платформа старая, конфигурации развивать сложнее, и 8.0 уже реально работает у нескольких наших клиентов. Обновить систему и убрать боль блокировок одним движением - разумнее, чем продлевать жизнь семёрке.

Что болело в файловом режиме

Картина классическая. При сорока пользователях в пиковые часы:

• Открытие большого документа - 15-40 секунд, потому что клиент тащил по сети куски таблиц целиком.
• Проведение при занятом регистре - очередь, пользователь ждёт, иногда вылетает с ошибкой блокировки.
• Конец месяца - закрытие периода превращалось в событие на полдня; все остальные в это время не могли работать нормально.
• Полная остановка раз в неделю - где-то рвался файловый доступ, и база требовала «Тестирования и исправления» на копии перед следующим запуском.

Что сделали перед миграцией

Самое важное - не тащить боевую базу сразу. Мы подготовили стенд: SQL Server 2000 на отдельной машине, пустая конфигурация 8.0, загрузили туда выгрузку базы в формате 7.7 через штатный конвертер. Обнаружили ряд вещей, которые в файловом режиме молча проглатывались, а SQL сервер не принял.

Что проверять до перевода боевой базы:

• Уникальность кодов номенклатуры. В файловой базе накопились дубли - одна позиция с двумя одинаковыми кодами в разных регистрах. SQL на уникальные индексы среагировал жёстко, конвертер падал без внятного сообщения.
• Битые ссылки. Документы, у которых была удалена аналитика, но остались движения - в файловой базе они просто существовали, в SQL загрузка прерывалась.
• Объём базы и время загрузки. Конвертация файловой базы на 8 ГБ заняла чуть больше двух часов. Это важно для планирования окна обслуживания.
• Регламентные задания. В 8.0 они настраиваются отдельно; если про это забыть, закрытие месяца не запустится автоматически.

На стенде прогнали несколько итераций конвертации, пока база не загрузилась чисто. Только после этого назначили дату перехода.

Сам переход

Пятница вечером, после окончания работы. Сделали полный бэкап файловой базы, конвертировали, загрузили в SQL, подняли сервер приложений 1С 8.0. Установили клиентов на рабочие места - клиент 8.0 умеет обновляться с сервера автоматически, часть машин подняли через терминальный сервер, это сократило раскатку до нескольких часов вместо обхода всех машин.

К понедельнику пользователи пришли уже на новую базу.

Что изменилось

Открытие документов - первое, что заметили сами пользователи. То, что раньше грузилось 15-20 секунд, теперь открывается за 2-3 секунды. Объяснение простое: клиент больше не тащит данные через шару; сервер приложений выполняет запрос к SQL и отдаёт только то, что нужно.

Блокировки стали строчными вместо табличных. Двое могут одновременно проводить документы в одном регистре - они друг другу не мешают, если не пишут в одну строку. Конец месяца перестал быть событием.

Жалоба «база встала» за первые две недели не поступила ни разу. Файловых обрывов больше нет по смыслу: клиент работает с сервером приложений по TCP, SQL Server держит транзакцию сам.

Что осталось работой

Переход на 8.0 - это не просто смена движка. Часть привычных отчётов написана на языке запросов 7.7 и не работает в новой платформе: там другой язык, другая объектная модель. Несколько отчётов пришлось переписывать вручную или искать аналоги в стандартной конфигурации.

Интеграция с внешними системами - отдельная история. У клиента была самописная выгрузка в Excel для склада, написанная под COM-объекты 7.7. Пересогласовали с подрядчиком, переписали под 8.0 API.

Ещё момент: SQL Server 2000 требует нормального администрирования. Регулярный DBCC CHECKDB, план обслуживания с перестройкой индексов, резервные копии самой SQL-базы отдельно от бэкапа сервера. Это новая операционная нагрузка, которой при файловом режиме не было. Клиенту честно сказали до перехода - теперь это наша совместная зона ответственности, а не «скопировал папку и спишь спокойно».

Пока прошло две недели. Жалоб нет, производительность лучше, пользователи перестали ждать. Посмотрим на конец месяца - вот там и будет настоящий тест.