1С 7.7 SQL тормозит #267021

В связи в увеличением размера базы возникла необходимости перехода с DBF базы на SQL, увеличился документооборот в день порядка 1000 документов делается в системе, при этом система стала тормозить что уже сил никаких нет :( Начитался форумов, переписал основные модули документов на 1С++ с прямыми запросами, вроде лучше стало, но осталась одна проблема для которой никак решения пока нейти не удалось :( При снятии проведения или перепроведении документа задним числом система просто умирает :( Про то что проводить документы задним числом не стоит это и так понятно ... но что можно сделать в этом случае??? Сервер P4 3.4GHz HT/3Гб, два комплекта винты 2x40Gb SATA в рейде MS SQL 2000 SP4 размер базы около 6Gb. пользователи работают в терминале, под SQL выделил 2Gb фиксированно и один из процов, обычно работают порядка 10 пользователей.

какой-то хлипенький сервачек

если по форумам походить то народ несколько лет назад и на более хлипком оборудовании работал

На форумах тебе еще не такой хрени наговорят.

да не говорили :) искал решение проблемы читал и сравнивал :)

когда в DBF формате база крутилось нормально работало, даже запас был по производительности. счас после переписки на 1С++ стало заметно быстрее шевелиться :) но блин когда документ предыдущего периода делается не проведенным то система колом встает :(

Разнести терминал и SQL по разным машинам, поставить нормальный дисковый массив.

Странно, не фонтан конечно, но "умирать"...

При открытии нового периода система не умирает?

Издеваешься? Конечно умирает... если автор специально не заточил мега-модуль под проведение задним числом :)

Совет автору: для решения проблемы фразу "система просто умирает" перевести в язык  выражающий физические характеристики системы: загрузка процессора, объем свободной физической памяти, очередь диска и т.д. Далее изучать мат. часть: SQL, архитектура компьютера и т.д. Станет  легче. По крайней мере в голове.

При распроведении документов задним числом он каждый раз пересчитывает итоги - отсюда и тормоза. Вариантов решения 2: 1). Закрыть период в базе (предпочтительней); 2). Тонкая оптимизация: поиск "висячих итогов", уменьшение размерностей регистров (очень малоэффективно - уж больно база большая).

Да не такая это большая база, чтобы при пересчете "вставала колом", по выражению автора...

Сколько регистров двигает "умирающий" документ ?

(+13)И сколько из них не закрывается?

Все...  погиб...

Разнести по разным компам пока не получиться :( "система умирает" - производится пересчет итогов по регистрам и т.к. энтот процесс ОЧЕНЬ длительный происходит блокировка таблицы и никто из пользователей из других пользователей не может работать :( по поводу размера мне тоже так думается что база не насколько большая чтоб этот процесс занимал столько времени

В зависимости от документа бывает что только один регистр, но ситуация одинаковая вне зависимости от кол-ва регистров.

а ты сделай пересчет итогов запросом. посмотри план. подумай. убери монопольную блокировку.

при проведении я так и делаю, сам итоги считаю, но при проведении в предыдущим периоде система сама начинает пересчет :( убрать "монопольную блокировку" это где?

нашел и "убил" монопольные блокировки помог материал более менее ожило :) но при перепроведении в предыдущем периоде все равно томозит, тормозит даже мягко сказано :( при этом выполняется процедура _1sp_RAXXXX_ClearRecalcDocActs которая выполняет очистку движения регистра по документу, насколько я понял. только не понятно как энту проблему можно решить :( может кто сталкивался? с чем это может быть связано?

ой дурак..

наверно :) с ClearRecalcDocActs проблема решилась следующим образом у пользователя под которым подключаюсь к 1С выставил язык English. :)

точнее из 1С к SQL :)

Если монитор протереть, то еще быстрее все заработает.

мне тоже было смешно :) но заработало :) прочитал про проблему и решил попробывать :) помогло :)

И где ты находишь всякую чушь?

а это читал?

было сделанно сразу же. без компоненты загрузка действительно была при блокировке 100%

снятие блокировок отключил :) теперь и без них нормально система работает :) SQL потребляет под себя порядка 1,5Гб памяти из двух выделенных, при этом загрузка на один проц идет средняя 30%, все остальное под работу в терминале хватает :) так что решение с переходом на другое железо откладывается :)

"нормально работает" лучше скажи через месяц работы. Когда в регистрах всякие "артефакты" полезут. SQL всегда отъедает порядка 1,7 Гигов. Больше он просто не умеет скушать без манипулирования AWE/PAE. Это совершенно не значит, что ему достаточно ресурсов системы. Ты у нас не студент случайно?

не студент :) AWE и РАЕ выставлены в 1 :)

про PAE погоричился :( это не к этому, в boot.ini прописал /3Gb, AWE для сервера  включен