Как протестировать sql базу 1с

Обновлено: 04.07.2024

У каждого администратора в процессе работы с 1С периодически встает вопрос об объеме базы данных, ее производительности, а также исправлении ошибок при "падении" базы данных.

Опыт решения подобных проблем при работе с большими базами данных 1С (около 1ТБ) вылился в написание данной обработки, в которую вошли базовые алгоритмы проверки БД:

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

Для того, чтобы использовать данную обработку, необходимо иметь доступ администратора (sa) к серверу MS SQL.

Настройка обработки заключается только в настройке доступа к MS SQL:

На закладке "Поставщик данных" выбираем Microsoft OLE DB Provider for SQL Server

На закладке "Соединение" указываем имя сервера, пользователя, пароль и имя базы данных. Внимание, флажок "Разрешить сохранение пароля" ОБЯЗАТЕЛЕН. Базу данных необходимо выбрать ту же самую, из которой запущена обработка.

Далее нажимаем кнопку "ОК". Состояние соединения будет указано на форме.

После этого можете выполнять проверки. Некоторые проверки могут занимать продолжительное время в зависимости от объема базы данных, производительности сервера или конфигурации.

Используется только для клиент-серверной версии 1С, у которой база данных хранится под управлением MS SQL Server.
Конфигурация 1С значения не имеет.

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

Для того, чтобы использовать данную обработку, необходимо иметь доступ администратора (sa) к серверу MS SQL.

Настройка обработки заключается только в настройке доступа к MS SQL:

На закладке "Поставщик данных" выбираем Microsoft OLE DB Provider for SQL Server

Далее нажимаем кнопку "ОК". Состояние соединения будет указано на форме.

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

Будут как простые инструменты создания новых пользователей и мониторинга "все ли вышли из базы", так и более изощренные интерфейсы проверки целостности базы и ее перемещения.

Как у большинства сложных приложений, у 1С через некоторое время работы вылезают странные ошибки, и возникает порой необъяснимое поведение. Специальные люди по 1С советуют в таких случаях почистить кэш.

Если запустить 1С с параметром /ClearCache, то будут очищены только клиент-серверные запросы. Локальные метаданные останутся и их нужно удалять отдельно на уровне файлов и папок. Эти данные хранятся в профиле пользователя, в папках с длинными названиями из GUID баз данных. Если баз на сервере немного, то такой кэш нетрудно удалить руками. Но если БД исчисляется десятками, то чистке вручную вы не обрадуетесь.

В подобных ситуациях выручит скрипт на Powershell, который запускается каждый раз при выходе пользователя из системы:

И никаких связанных со старым кэшем проблем.

Для исправления испорченной файловой базы в поставку 1С входит утилита chdbfl.exe, которая просто считывает содержимое базы во временный файл. Если какие-то данные считать не может — пропускает. При этом у нее нет ключей запуска для автоматизации, и проверку приходится запускать вручную.

Вообще, правильнее запускать проверку БД конфигуратором, но этот процесс проходит значительно дольше. Если же использовать только проверку физической целостности средствами chdbfl.exe, то не забывайте делать резервную копию из-за возможной потери данных.

Для баз 8.1 Андрей Скляров создал хороший инструмент Check1CD, с двумя параметрами запуска: "исправлять найденные ошибки" и “путь к базе”.

Но в Check1CD не хватает двух вещей:

Раз есть "хотелка" и немного свободного времени, то почему бы не попробовать решить вопрос самостоятельно?

Доработать код для передачи параметров через ключи командной строки — дело техники.

С выходом 1С 8.2 возникла проблема — путь к chdbfl менялся с установкой нового релиза. Что ж, дополним скрипт:

Надо сказать, недавно был опубликован исходный код Check1CD. Да, тоже на AutoIT.

Аналогичный механизм можно применять и для автоматического запуска различных регламентных механизмов, где нужно запускать 1С и ждать завершения операции.

При различных регламентных операциях с 1С (ночное обновление конфигурации или бэкап в .dt) важно обеспечить отсутствие подключенных к ней пользователей. Можно конечно запускать 1С: Предприятие с ключом /C ЗавершитьРаботуПользователей, но это не всегда удобно, да и хочется же потом написать личное письмо с рекомендациями по устранению склероза.

Можно использовать штатную возможность подключения к 1С через COMConnector и скрипт на AutoIT. Код написан под 1С 8.1 и позволяет выкинуть пользователей из базы с записью в журнал.

Но операцию иногда нужно проворачивать по просьбе самого пользователя, который запустил "тяжелый" отчет и повесил 1С. Если не хотите решать эти вопросы самостоятельно, то просто выведите любителям “тяжелых” отчётов ярлык на скомпилированный скрипт:

Еще COMConnector помогает проверить наличие обновлений конфигурации, получить какую-то информацию из базы, и автоматизировать заведение пользователей в 1С.

На мой взгляд, создавать новых пользователей 1С должен системный администратор, а не программист 1С. Но последнему нужно сделать процесс максимально простым. Чтобы администратору не приходилось "заглядывать" в каждую базу отдельно, можно использовать еще один скрипт.

Для примера приведу функцию создания пользователей в типовой Бухгалтерии 2.0.

Юрлиц развелось слишком много — нужно разбивать на столбцы.

Занятно, но после смены нескольких поколений администраторов в одной компании из далекого прошлого новенькие уже не знали как создать пользователя вручную.

Если нужно перенести базу 1С: Предприятия вместе с ее данными в SQL на другой сервер, то делать это вручную целесообразно только для 1-2 БД.

При большем их числе рутина станет утомительной - лучше воспользоваться скриптом.

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

Конечно, это далеко не все, что можно автоматизировать в связке с 1С. Но разного рода обмены, получение real-time информации из 1С в других приложениях и прочие сценарии не попали в этот обзор из-за узкой направленности и специфики.

Наверняка у вас тоже есть свой набор "ноу хау" для администрирования 1С — будет здорово если поделитесь с коллегами в комментариях.

Скрипты и ноу-хау предоставлены avelor, за что ему огромное спасибо!

Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.

Аппаратный уровень

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

Уровень операционной системы

привести в порядок файловую систему;
отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
проверить оптимальность настроек операционной системы.

проверке логической структуры диска;
удалении временных и ненужных файлов;
дефрагментации файловой системы.

Уровень служб

В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска.
Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.

Уровень баз

Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант.
У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.

Заключение

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

Читайте также: