В связи в увеличением размера базы возникла необходимости перехода с DBF базы на SQL, увеличился документооборот в день порядка 1000 документов делается в системе, при этом система стала тормозить что уже сил никаких нет :(
Начитался форумов, переписал основные модули документов на 1С++ с прямыми запросами, вроде лучше стало, но осталась одна проблема для которой никак решения пока нейти не удалось :( При снятии проведения или перепроведении документа задним числом система просто умирает :(
Про то что проводить документы задним числом не стоит это и так понятно ... но что можно сделать в этом случае???

Сервер P4 3.4GHz HT/3Гб, два комплекта винты 2x40Gb SATA в рейде
MS SQL 2000 SP4
размер базы около 6Gb.

пользователи работают в терминале, под SQL выделил 2Gb фиксированно и один из процов, обычно работают порядка 10 пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(16) нашел и "убил" монопольные блокировки помог материал
http://www.itpb.ru/forum4/topic.php?id=1017&page=-1#8
http://www.itpb.ru/forum4/topic.php?id=732&page=-1%A0
более менее ожило :)

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

(20) ой дурак..

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

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

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

(24) мне тоже было смешно :) но заработало :)
прочитал про проблему
http://www.erp-volga.com/hare/forum/index-tred-101-223.html
и решил попробывать :) помогло :)

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

Книга знаний: Исправление ошибки 1С:Предприятие 7.7/8.0 - 100% загрузка процессора при ожидании блокировки
а это читал?

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

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

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

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

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