Поддержка и оптимизация MS SQL Server
Поддерживаем работоспособность ваших систем: ускорение, отказоустойчивость, разбор аварий. 30 лет практики, 38 инстансов под сопровождением прямо сейчас.
Если уже упало
Подключаемся в день обращения, когда:
- база в состоянии suspect или recovery pending - «база данных ожидает восстановления» и не открывается;
- в логах «The transaction log for the database is full» - журнал транзакций переполнен, ошибка 9002, запись остановилась;
- служба SQL Server не запускается - ошибка 3417 после сбоя, перезагрузки или обновления;
- AlwaysOn не переключился - группа доступности развалилась, реплики не синхронизируются;
- повреждены страницы данных - ошибки 823/824, CHECKDB находит ошибки.
Что делать прямо сейчас: не перезапускайте службу повторно, не отсоединяйте базу и не запускайте ремонтные команды из первой найденной статьи - половина безвозвратных потерь данных, которые мы видели, случилась на этом шаге. Пошаговый разбор пяти самых частых аварий - в блоге.
Написать по аварииMS SQL Server - наша работа вот уже 30 лет
Самый нагруженный наш прод - банковский процессинг: 90 баз на одном сервере, 144 ядра, терабайт памяти. Восемь миллионов логических чтений в секунду - средняя нагрузка прайм-тайма, в пиках до 15. Самая большая база - 22 ТБ, ERP Axapta, продажи и склад ритейла. В обоих случаях ограничения возникали на уровне схемы данных и запросов и снимались оптимизацией. До предела возможностей самой СУБД не дошла ни одна из этих систем.
Собственный журнал транзакций, собственный бэкап, восстановление на любой момент времени независимо. Те 90 баз процессинга держались на одном сервере именно поэтому: авария одной не затрагивала остальные, а память и ядра сервер перераспределял между всеми динамически. Из распространённых СУБД такую изоляцию даёт только MS SQL.
Query Store, динамические представления, Extended Events - полная наблюдаемость сервера входит в любую редакцию. Диагностировать проблему инструментами самой СУБД - норма нашей работы.
Что делаем
Находим и ускоряем тяжёлые запросы: планы выполнения, индексы, статистики, блокировки, настройка памяти и параллелизма. Результат измеряем в секундах выполнения - до и после.
Проектируем и настраиваем AlwaysOn, георепликацию, автоматическое переключение. Проводим учения по переключению: когда наступает настоящая авария, сценарий уже отработан.
Строим схему восстановления под ваши требования к простою и потере данных: полные, разностные и журнальные бэкапы, восстановление на момент времени, управление журналом транзакций. Каждую схему проверяем восстановлением.
СУБД под 1С и другие ERP
Мы не внедряем и не дорабатываем 1С - для этого есть франчайзи. Наша зона - этаж ниже: СУБД, на которой работает ваша 1С. Обслуживание баз 1С в MS SQL Server: настройка сервера под характер нагрузки 1С, план обслуживания - индексы, статистики, проверки целостности, - автоматическое резервное копирование с проверкой восстановимости, разбор блокировок и медленных проводок. Тот же контур умеем для Axapta и других ERP: самая большая база под нашим сопровождением выросла из Axapta.
Типичная точка входа: «проводки идут минутами, франч говорит - дело в сервере, админ говорит - дело в 1С». Диагностика одного инстанса за 3 дня заканчивает этот спор цифрами.
Microsoft ушла - поддержка осталась
Если вы купили бессрочные лицензии MS SQL Server до 2022 года - они ваши и работают законно. Обновления безопасности технически доступны. Потеряли вы две вещи: вендорскую поддержку и возможность легально докупать лицензии.
Первую роль закрываем мы: диагностика, аварии, оптимизация, регламентное обслуживание - тот же контур работ, который раньше стоял за подпиской Software Assurance, только ближе и на русском языке. Вторая решается архитектурно: существующий прод остаётся на MS SQL, рост планируется на PostgreSQL - мы сопровождаем обе СУБД и умеем строить такой гибрид. Если задумаетесь о полном переезде - начните с аудита с прямым вердиктом: каждый третий наш заказчик после него остаётся.
Поддержка SQL Server 2016 закончилась в июле 2026 года, у 2017 заканчивается в 2027, у 2019 - в 2030. Версии продолжат работать, но патчи безопасности выходить перестанут. Учитывайте эти сроки в планах заранее.
Удалённый резерв высокой готовности
У классического AlwaysOn есть граница, о которой вспоминают поздно. Группа доступности, даже разнесённая по разным городам, живёт внутри отказоустойчивого кластера Windows и опирается на доменную инфраструктуру: общий домен, общий кворум, служба кластера на каждом узле. Именно она принимает решение о переходе по отказу. Пока катастрофа локальная - упал сервер, пропала площадка, - схема работает как задумано. Но когда происходит нечто, затрагивающее саму корпоративную инфраструктуру, реплики оказываются её частью и уходят вместе с ней.
Речь про сценарии крайнего порядка: по домену прошёл шифровальщик, оборудование изъяли, на площадке пожар. Здесь нужен резерв, который к этой инфраструктуре не принадлежит вовсе.
Мы разворачиваем такой инстанс вне домена и вне корпоративного периметра, данные в нём актуализируются потоково. Сервер остаётся скрытым от корпоративной публичности: его нет в домене, нет в общей инвентаризации, нет в списках доступа, которыми оперирует злоумышленник, получивший права администратора домена. При крахе основной площадки бизнес продолжает работу с резерва.
Конфиденциальность соблюдается: данные и бэкапы зашифрованы, ключи хранятся отдельно от площадки, провайдер видит только нечитаемые файлы. Площадка может быть российской или зарубежной - по выбору заказчика; для персональных данных учитываем требования 152-ФЗ. Как это устроено технически - наша работа; состав и регламент обсуждаем по вашей ситуации.
Расскажите о задачеПримеры из практики
База падала 2-3 раза в неделю, каждый простой - 2-4 часа. После аудита и настройки нового сервера - ноль падений за шесть месяцев.
Ключевые отчёты формировались дольше 40 минут и блокировали пользователей. После оптимизации запросов и индексов те же отчёты выполняются за 90 секунд.
Мы публикуем разборы своих аварий - так вы видите, как мы думаем: инцидент AlwaysOn на 7,5 часов, как compatibility level превратил реиндекс в инцидент.
Как начать
Диагностика одного инстанса - 30 000 ₽, 3 рабочих дня, письменный отчёт с находками и планом. Онбординг входит в эту сумму: мы не просто смотрим, а сразу инвентаризируем инстанс и снимаем базовые метрики. Каждый следующий инстанс - 5 000 ₽, поэтому обследовать сразу весь парк серверов выходит намного дешевле, чем по одному.
Если сразу берёте абонентское обслуживание, диагностика достаётся вам бесплатно - она всё равно нужна нам, чтобы начать работу. Само обслуживание - 150 000 ₽/мес за пять инстансов, каждый дополнительный - 15 000 ₽/мес.
Частые вопросы
Журнал транзакций переполнен - что делать?
Не удаляйте лог-файл и не переводите базу в simple recovery по совету с форума - оба действия ломают цепочку восстановления. Причина почти всегда одна из пяти: нет бэкапов журнала, зависшая транзакция, репликация, группа доступности или tempdb. Подробный разбор по каждой причине - в нашей статье. Если прод стоит прямо сейчас - пишите, подключаемся в день обращения.
База «ожидает восстановления» - что делать прямо сейчас?
Не перезапускайте службу повторно и не отсоединяйте базу - оба действия способны превратить восстановимую ситуацию в потерю данных. Обычно причина в недоступности файлов данных или журнала: не смонтировался диск, кончилось место, сменились права. Снимите файловую копию каталогов, если они доступны, и напишите нам - подключаемся в день обращения.
Служба SQL Server не запускается, ошибка 3417 - это лечится?
Лечится, чаще всего без потери данных: типичные причины - повреждение master, права на каталоги, сбой диска. Главное - не переустанавливать SQL Server поверх: переустановка не чинит данные и уничтожает сценарии восстановления. Диагностируем удалённо по журналам.
Сервер тормозит после обновления. Это совпадение?
Как правило, нет. Смена compatibility level меняет модель оценки кардинальности и режимы выполнения - часть планов запросов деградирует. Лечится точечно, через Query Store и статистику запросов, откат обновления не требуется. Мы разбирали такой случай на живом инциденте: как compatibility level превратил реиндекс в инцидент.
У нас группы доступности AlwaysOn. Вы с ними работаете?
Да: настройка и диагностика групп доступности, свидетель и кворум, синхронные и асинхронные реплики, поведение приложений при переключении. Проводим учения по failover на живых системах.
Можно ли ускорить сервер, не переписывая приложение?
В большинстве случаев да. Индексы, статистики, настройки памяти, tempdb, режим блокировок - оптимизация на уровне СУБД снимает основную часть проблем производительности. Переписывать код приходится только при логических ограничениях, и это выясняется на диагностике, до каких-либо работ.
Вы обслуживаете базы 1С?
Да, на уровне СУБД: сервер, план обслуживания, резервное копирование, производительность проводок и отчётов. Конфигурации 1С не трогаем - работаем в связке с вашим франчайзи или программистом.
Поддержка Microsoft в России закончилась. Работать на MS SQL дальше - можно?
Можно и законно: бессрочные лицензии не имеют срока действия. Серверы работают, обновления безопасности технически доступны. Нет двух вещей - вендорской поддержки и возможности легально докупать лицензии. Первую закрываем мы, вторая решается гибридной архитектурой. Подробнее - в блоке «Microsoft ушла - поддержка осталась» выше.
Расскажите о задаче - мы предложим подходящий формат.