Брошенные базы 1С Предприятия.

Приветствую друзья! на связи Богдан.

Хочу поделиться с Вами некоторыми своими выводами, которые сделал совсем недавно относительно обслуживания баз данных «1С Предприятия» в клиент-серверном варианте их работы.

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

 БРОШЕННЫЕ  базы 1С Предприятия!

Вследствие чего ряд вытекающих проблем, но  о них мы поговорим немножко позже,  сейчас разберемся, почему так происходит, почему «бросают» базы 1С.

Нередко, после внедрения “1С Предприятия” в организации, мало кто занимается обслуживанием баз данных, дело в лучшем случаи  доходит до не регулярного  «бэкапа»  который не редко располагается  еще и на том  же физическом  диске  :-)))

В таких случаях не приходится говорить о производительности « 1С Предприятия», здесь стоят вопросы куда важнее:  безопасность, надежность.

И причин здесь много, вот некоторые из них:

1. «Задача внедрить 1С Предприятие  –  выполнена» остальное не волнует.
2. Раньше работали в файловом варианте – привычка )
3. Поклонники правила «Работает не трожь»
4. Не опытный обслуживающий персонал.

 

Все это приводит к серьёзным последствиям «брошенные базы», особенно в клиент-серверном варианте работы, нуждаются в ежедневном правильном обслуживании  это главная мысль,  которую я надеюсь донести при помощи этой статьи.

Если Вы наблюдаете частые сбои в работе с «1С Предприятием» , вылетают различные ошибки, падает производительность  это вполне могут быть последствия плохого обслуживания баз данных.

И так вопрос логический  –  первый.

Как мы можем обслуживать базу данных 1С Предприятия в клиент-сервере ?

Конечно, лучше всего это делать при помощи инструментов вашей СУБД.

Одна из самых распространённых СУБД-шек которая часто используется в связке с 1С 8 это конечно

MS SQL server.

Эта СУБД отличается простотой и удобством в обслуживании и имеет огромный инструментарий для работы с базами данных.

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

 

 

Многие считают мол «сделал бэкап и спи спокойно», уверяю Вас  это великое заблуждение!

 

Почему одних «бэкапов» мало ?

Дайте ответ на такой вопрос.

Что можно восстановить из «бэкапа» когда база уже находилась на грани краха ?

Думаю, что на этом вопросе можно было бы закрыть эту под тему  

Но я также уверен, что Вам будет интересно копнуть вглубь и все же получить ответ на этот вопрос, поэтому мы продолжим.

И так если все обслуживание баз данных 1С Предприятия сводится к созданию  «бэкапа»  тогда Вы гарантированно столкнетесь с такими проблемами

Типичные проблемы в  SQL server,  когда база 1С Предприятия «брошена» или не обслуживается корректно.

 

Фрагментация индексов.

SQL Server автоматически поддерживает состояние индексов при выполнении операций вставки, обновления или удаления в отношении базовых данных.

Однако со временем эти изменения могут привести к тому, что данные в индексе окажутся разбросанными по базе данных (фрагментированными).

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

 

 

Переполнение журнала транзакций.

Если не удалять записи из журнала транзакций, уже совсем скоро они заполнят  все доступное место на диске, заполнят то место, где хранятся файлы журнала.

Процесс автоматического усечения журнала освобождает место в логическом журнале для повторного использования журналом транзакций.

Чистка журналов транзакции может выполняться автоматически, это происходит когда, к примеру, есть  простая  модель восстановления базы данных,  тогда чистка будет произведена автоматически после достижения контрольной точки.

В том случаи, если имеется «полная» модель восстановления или  с неполным протоколированием

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

 

Не обновленная статистика.

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

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

Чтобы быть максимально полезной для оптимизатора запросов, статистика должна быть обновленной.

 

Не проводится чистка процедурного кеша.

Оптимизатор MS SQL обработке запроса кеширует данные плана запроса. Это сделано для лучшей производительности системы.

Но, так же как в примере со статистикой, это может и помешать оптимальному выполнению запроса.

Выполнять обязательно сразу  после обновления статистики.

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

 

1.       Ежедневный мониторинг.

2.       Делать дефрагментацию индексов.

3.       Обновлять статистику.

4.       Чистить процедурный кеш.

5.       Проводить чистку журналов транзакций.

 

 

Конечно можно закрыть глаза на все выше сказанное скрестить пальцы на руках и ногах и ждать что пронесет :- )

Но как показывает практика все чего можно дождаться так это как минимум падение производительности ,  а иногда и самой базы 1С, что будет куда печальней.  :- (

Что ж надеюсь, что я сумел убедить Вас в том, что не стоит «Бросать» базы данных, а заниматься их ежедневным обслуживанием.

 

+ Еще несколько советов

Уже начиная с установки SQL server нужно учесть специфику работы «1С Предприятия»

Лог и базу обязательно разнесите на разные физические  диски.

К примеру, стоит обратить внимание на системную базу данных tempdb

В работе с 1С Предприятием  часто используются временные таблицы, а это  использование базы tempdb. Соответственно нужен быстрый доступ к этой базе,  организовать его можно разными способами: например выделить часть оперативки и поместить туда tempdb, или задуматься о покупке SSD диска и туда вынести базу.

Также размер базы данных tempdb может повлиять на производительность системы. Например, если размер базы данных tempdb слишком мал, система может быть слишком занята автоматическим увеличением этой базы данных для обеспечения требований рабочей нагрузки при каждом запуске SQL Server. Можно избежать этой перегрузки путем увеличения размера базы данных tempdb.

Негативно на производительности также сказывается и «полная» модель восстановления, которая по умолчанию установлена в SQL.

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

---

 

 

Друзья, если Вы хотите, научится корректно обслуживать базы «1С Предприятия»  в клиент-серверном варианте их работы, хотите научиться, по-мастерски управляется с  SQL сервером

И закрепить полученные знания на практике удаленно на наших серверах.

Тогда у нас есть отличная новость, как раз сейчас мы работаем над новым видеокурсом

«1С 8 и Microsoft SQL server 2014 Standard»

На просьбы наших подписчиков «упаковать мастер-класс: 1С 8 и Microsoft SQL server 2014 Standard», который был объявлен ранее, в формат видеокурса.

Мы пошли Вам на встречу и к концу февраля планируем его выход, уже как видеокурса.

Надеюсь, статья Вам понравилась, оставляйте комментарии, задавайте вопросы, буду рад на них ответить.

С уважением, Богдан.

http://administrator.kuharbogdan.com/index.html