ADG Оставить заявку
Блог Данные и аналитика 5 мин чтения

SQL Server 2008 SP1 и миграция 1С:Предприятие 8.1: прирост производительности есть

Мигрировали базы 1С:Предприятие 8.1 с SQL Server 2005 на 2008 SP1. Прирост производительности запросов - реальный. Регламент обновления пришлось писать с нуля.

Контекст момента

SQL Server 2008 SP1 вышел в феврале 2009, существенно улучшив стабильность и производительность после первых волн миграций

В феврале Microsoft выпустил SP1 для SQL Server 2008, и это оказался удобный момент для разговора, который мы откладывали с осени: надо ли переводить клиентов на 2008, если они уже переехали на 2005 и в целом живут нормально? Ответ не очевидный, но после нескольких пилотных миграций он у нас есть.

Три года назад мы методично переводили клиентов с SQL Server 2000 на 2005 - тогда дождались SP1 и только потом пошли в прод. С 2008 история повторяется: RTM-версия вышла в конце 2008, первые волны миграций собрали часть шишек, а SP1 подчистил наиболее болезненные места. Сейчас картина примерно такая же, как была с 2005 после его первого сервис-пака.

С чего начали

Два клиента из тех, кого мы ведём в рамках сопровождения, работают на 1С:Предприятие 8.1 с SQL Server 2005 SP3. Конфигурации - типовые, с умеренными доработками. Объём баз - средний для небольшого производственного предприятия. До сих пор производительность устраивала, но на горизонте у обоих стояли задачи роста: больше пользователей, тяжелее отчёты.

Пилот начали на тестовом стенде: взяли резервную копию боевой базы, развернули рядом два экземпляра - один на 2005 SP3, второй на 2008 SP1. Поднял лаб-среду с тем же железом, нагрузили одинаковым набором запросов, сравнили.

Что показал тест

Результат оказался интереснее, чем мы рассчитывали. По набору тяжёлых аналитических запросов - отчёты по остаткам за квартал, взаиморасчёты с контрагентами, агрегация по движениям регистров - время выполнения упало на 15-30% без каких-либо изменений в запросах и без новых индексов.

Несколько наблюдений:

  • Оптимизатор SQL Server 2008 строит планы заметно лучше на запросах с несколькими JOIN-ами и подзапросами. Планы выполнения в Management Studio хорошо видно: там, где 2005 уходил в Nested Loop с большим числом итераций, 2008 выбирал Hash Match и выигрывал на объёме.
  • Параллелизм на многоядерных конфигурациях агрессивнее - видно по операторам Parallelism в плане. На однопроцессорном стенде разница меньше, на двухпроцессорном - более ощутимая.
  • Статистика в 2008 обновляется точнее при том же объёме авто-апдейтов. Это не сразу видно, но через несколько дней работы с реальными данными планы запросов у 2008 начинали выглядеть лучше.

Цифры 15-30% - не маркетинг, но и не гарантия: это диапазон по конкретной нагрузке на конкретных данных. Другие конфигурации 1С с другими паттернами запросов покажут своё.

Где потребовалась дополнительная работа

Собственно, ради этого и нужен был пилот, а не сразу прод.

Compatibility level. После attach базы с SQL Server 2005 экземпляр 2008 поднимает её в режиме совместимости 90 (SQL Server 2005). Перед переключением в 100 (SQL Server 2008) нужно проверить хранимые процедуры и запросы - в режиме 100 оптимизатор строже, и несколько конструкций, которые 2005 молча принимал, могут не пройти. У нас нашлось три хранимки с неявным приведением типов - починили до переключения.

Collation и кодировки. При переносе базы 1С всегда нужно контролировать collation - типичная ловушка. Если экземпляр SQL Server 2008 поставить с другим collation, чем был у 2005, данные встанут нормально, но сравнения строк поедут в случае кастомных запросов. Оба клиента у нас с Cyrillic_General_CI_AS - проверили явно.

Регламент обновления. Это отдельная история. Когда мы переезжали с 2000 на 2005, процедура была понятная: backup, detach, attach на новом экземпляре, проверка, переключение строк подключения. С 2008 в целом то же самое, но добавились шаги проверки compatibility level, аудита хранимых процедур и теста ключевых операций в 1С на стенде. Без этого регламента можно нарваться на сюрприз уже в прод-окне.

Регламент написали, теперь он у нас есть как отдельный документ для миграций с 2005 на 2008.

Как прошёл продуктивный переезд

Первого клиента перевели в прошлые выходные. Окно обслуживания - суббота ночь, три часа с запасом.

Порядок:

  • Полный бэкап SQL-базы и базы 1С
  • Остановка сервера приложений 1С
  • Detach базы с 2005, attach на 2008 SP1
  • Проверка integrity, compatibility level переводим в 100
  • Запуск сервера приложений, тест операций в 1С: проведение документа, отчёт по остаткам, закрытие документа
  • Переключение строк подключения на новый сервер

К воскресному утру всё работало. Понедельник прошёл без звонков.

Что сейчас

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

Прирост производительности реальный и заметный пользователям - тяжёлые отчёты, которые раньше уходили на несколько минут, укладываются быстрее. Для баз 1С, которые растут и нагружаются всё больше, это существенно.

Основной вывод: SQL Server 2008 SP1 - нормальный момент для миграции с 2005. Дождались того же, чего ждали в своё время с 2005 SP1. Регламент нужен - без него рискуешь потратить больше времени на разбор сюрпризов, чем сэкономить на прогнозируемом переезде.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.