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. Регламент нужен - без него рискуешь потратить больше времени на разбор сюрпризов, чем сэкономить на прогнозируемом переезде.
- SQL Server 2005 SP1 и методичка миграции с 2000: первый клиент переехал · 11 июля 2006
- 1С:Предприятие 8.1 - тестируем миграцию с 8.0 и пишем чеклист · 28 сентября 2006