Приветствую друзья! на связи Богдан.
Хочу поделиться с Вами некоторыми своими выводами, которые сделал совсем недавно относительно обслуживания баз данных «1С Предприятия» в клиент-серверном варианте их работы.
Вот уже последних несколько лет наблюдаю одну и ту же картину в разных организациях, как маленьких где например 20 пользователей работают в 1С Предприятии, так и больших с оборотами в миллионы долларов и огромным количеством пользователей, ситуация зачастую одинакова —
БРОШЕННЫЕ базы 1С Предприятия!
Вследствие чего ряд вытекающих проблем, но о них мы поговорим немножко позже, сейчас разберемся, почему так происходит, почему «бросают» базы 1С.
Нередко, после внедрения «1С Предприятия» в организации, мало кто занимается обслуживанием баз данных, дело в лучшем случаи доходит до не регулярного «бэкапа» который не редко располагается еще и на том же физическом диске :-)))
В таких случаях не приходится говорить о производительности « 1С Предприятия», здесь стоят вопросы куда важнее: безопасность, надежность.
И причин здесь много, вот некоторые из них:
- «Задача внедрить 1С Предприятие — выполнена» остальное не волнует.
- Раньше работали в файловом варианте – привычка )
- Поклонники правила «Работает не трожь»
- Не опытный обслуживающий персонал.
Все это приводит к серьёзным последствиям, базы 1С, особенно в клиент-серверном варианте работы, нуждаются в ежедневном правильном обслуживании это главная мысль, которую я надеюсь донести при помощи этой статьи.
Если Вы наблюдаете частые сбои в работе с «1С Предприятием» , вылетают различные ошибки, падает производительность это вполне могут быть последствия плохого обслуживания баз данных.
И так вопрос логический — первый.
Как мы можем обслуживать базу данных 1С Предприятия в клиент-сервере ?
Конечно, лучше всего это делать при помощи инструментов вашей СУБД.
Одна из самых распространённых СУБД-шек которая часто используется в связке с 1С 8 это конечно
MS SQL server.
Эта СУБД отличается простотой и удобством в обслуживании и имеет огромный инструментарий для работы с базами данных.
Одним слов все что нужно для того чтоб Ваша база 1С оставалась в целостности и сохранности и имела высокую производительность, доступность, все это возможно поддерживать инструментами SQL сервера.
Многие считают мол «сделал бэкап и спи спокойно», уверяю Вас это великое заблуждение!
Почему одних «бэкапов» мало ?
Дайте ответ на такой вопрос.
Что можно восстановить из «бэкапа» когда база уже находилась на грани краха ?
Думаю, что на этом вопросе можно было бы закрыть эту под тему 🙂
Но я также уверен, что Вам будет интересно копнуть вглубь и все же получить ответ на этот вопрос, поэтому мы продолжим.
И так если все обслуживание баз данных 1С Предприятия сводится к созданию «бэкапа» тогда Вы гарантированно столкнетесь с такими проблемами
Типичные проблемы в SQL server, когда база 1С Предприятия «брошена» или не обслуживается корректно.
Фрагментация индексов.
SQL Server автоматически поддерживает состояние индексов при выполнении операций вставки, обновления или удаления в отношении базовых данных.
Однако со временем эти изменения могут привести к тому, что данные в индексе окажутся разбросанными по базе данных (фрагментированными).
Фрагментация имеет место в тех случаях, когда в индексах содержатся страницы, для которых логический порядок, основанный на значении ключа, не совпадает с физическим порядком в файле данных. Значительно фрагментированные индексы могут серьезно снижать производительность запросов и служить причиной замедления откликов приложения.
Переполнение журнала транзакций.
Если не удалять записи из журнала транзакций, уже совсем скоро они заполнят все доступное место на диске, заполнят то место, где хранятся файлы журнала.
Процесс автоматического усечения журнала освобождает место в логическом журнале для повторного использования журналом транзакций.
Чистка журналов транзакции может выполняться автоматически, это происходит когда, к примеру, есть простая модель восстановления базы данных, тогда чистка будет произведена автоматически после достижения контрольной точки.
В том случаи, если имеется «полная» модель восстановления или с неполным протоколированием
Тогда чистка будет стартовать после создания резервной копии журналов, при условии, что со времени предыдущей операции резервного копирования была достигнута контрольная точка.
Не обновленная статистика.
Когда выполняется запрос, оптимизатор запросов, пробует построить оптимальный план выполнения, оперируя той информацией которая у него имеется на текущий момент .
И если статистика будет содержать устаревшие данные, могут быть выбраны менее эффективные операции, которые приведут к созданию медленных планов выполнения.
Чтобы быть максимально полезной для оптимизатора запросов, статистика должна быть обновленной.
Не проводится чистка процедурного кэша.
Богдан, спасибо, отличная статья многое взял на заметку!
Огромное вам спасибо, обязательно воспользуюсь вашими советами.
Рад помочь.
Интересно, о многих вещах и не догадывался, признаюсь также ограничивался стандартным backup.
Спасибо!!! отличная статья!
Я по должности ведущий бухгалтер, но одновременно приходится вести базу 1С: бухгалтерия в клиент-серверном варианте.
Признаюсь честно, навыков работы с SQL не имею.
Вначале программа работала с достаточной скоростью, сейчас все жалуются на медленную работу.
Возникает вопрос куда сунуться в первую очередь???
Здравствуйте, Владимир.
Вам рекомендую для начала, сузить круг поиска проблемы производительности 1С Предприятия.
Может быть, что проблема совсем не в базе 1С или настройках СУБД.
В самом начале стоит смотреть на «код» провести оптимизацию там. (привести в порядок запросы, оптимизировать и тд)
Затем смотреть в сторону «железа» (дисковая подсистема, процессор, сеть) и только после копать в СУБД ее администрирование, оптимизацию и настройки.
1. «КОД»
2. «ЖЕЛЕЗО»
3. «СУБД»
Дельный совет можно дать только после тестирования и проверки.
В данной статье я поднял вопрос администрирования баз 1С в клиент-сервере используя СУБД SQL server (то есть пункт номер три).
Статьи познавательные, огромное спасибо!!!