Жутко тормозит 1С 77 работающая на Sql,Как сделать гибкие блокировки на 1С 7.7 с помощью T-sql

1. Yan_Malyakov 32 25.07.18 09:28 Сейчас в теме
Привет всем.такая ситуёвина
Жутко тормозит 1С 77 работающая на Sql,анализ на sql сервере показал что блокируется MsJourn,при массовом проведении расходных накладных
принято решение сделать свои "гибкие" блокировки на T-sql
правда не знаем с какого бока подступиться
накидали план
1)При проведении расходной накладной будем с помощью хранимой процедуры (t-sql) определять заблокирован ли MsJourn 0 и/или таблица документа
2) необходимо реализовать с помощью хранимой процедуры счетчик прирастания номера что бы напрямую записывать данные в MsJourn
3) кроме того предполагаем что нужно будет как то перекидывать данные подготовленные для записи в регистр во временные таблицы на Sql а от туда записывать на прямую в талицы регистра.

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


Знаю что существует решение от софтПоинта называющаяся гибкие блокировки,но оно для нас дороговато от (170 тыщ в год.)+ пред.обследование
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. CheBurator 3119 25.07.18 10:42 Сейчас в теме
в типовой ТиС накладные по 300-500 строк с партионкой проводятся нормально и особых блокировок не создают (конечно, может у вас там 200 таких накладных за 5 минут..).
1. Избавьтесь от проведения накладных задним числом (заднее число - это даже -1 сек от ТА) - это основная причина тормозов (расчет временных итогов)
2. Период хранения итогов установите = 5 дней. Это увеличит размер таблицы итогов, но существенно ускорит процедуры проведения (особенно если "ну никак мы не можем не работать задним числом")
3. Каридинально наведите период в базе в партионном учете. РЕГИСТРЫ ДОЛЖНЫ БЫТЬ ЗАКРЫТЫ. Одно дело когда для списания партий тянется небольшая табличка итогов по КАЖДОЙ номенклатуре, и совсем другое когда на каждую строку накладной система тянет по 40-50 МБ неактуальных партий, которые потом игнорирует в переборе итогов.
4. Занулите нулевые итоги, см. мою https://infostart.ru/public/180018/ - там есть ссылка для скуля
5. Настройте скуль в соответствии с правильными рекомендациями (увеличьте дельту прироста файлов базы и пр.)
6. Сделайте (регулярно) дефрагментацию диска, не знаю как нас куле - на дбф ускорение после этого заметно, для скуля. я думаю, вреда тоже не принесет.
Yan_Malyakov; +1 Ответить
3. DarkUser 25.07.18 13:16 Сейчас в теме
В 2006 году внедрял гибкие блокировки от СофтПойнта. По результату могу сказать что прирост конечно есть, но "из коробки" оно работает не очень хорошо. Допиливать блокировки и дописывать проведение документов для достижения качественного результата всё равно придется, и существенно.
Однако, зачем такие сложности, если можно всё же начать постепенный переход на 8-ю версию? На это придется затратить время, силы и ресурсы, но это стратегически выгоднее, чем пробивать головой потолок возможностей старой семерки.
4. DarkUser 25.07.18 13:19 Сейчас в теме
Для уменьшения времени блокировок на 7.7 критична производительность компьютера клиента. Если у вас есть клиенты, работающие с базой по сети и/или с медленными компьютерами, то стоит исключить их или перевести на терминалку.
5. Dnki 4 27.07.18 10:29 Сейчас в теме
Автор не сказал ничего про масштаб ситуации:
- сколько пользователей
- количество документов за день
- размер базы
Когда у меня, в свое время, стали проблемы с 50 пользователями, я не переводил в SQL
Она заведомо проигрывает в скорости файловой.
* Использовал псевдо-sql - V7DBNet 2.5 автор ООО "Вирт", но проверил, сайт уже закрыл.
* плюс все пользователи в терминале того же комп-ра, где БД
* SSD диски
6. Yan_Malyakov 32 27.07.18 14:09 Сейчас в теме
50 ~ 70 пользователей
2-3 тысячи док.в день
размер базы 25 ГГБ
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот