Собственно впервые столкнулись с проблемой когда зависает расчет.
Железо нормальное - xeon 4 ядра 16 гб оперативки на сервере приложений, ксеон 4 ядра и 8 гб оперативки на сервере sql 2008. При расчете выпадает в ошибку приложения или виснет просто. платформа 8.2.10.82, УПП 1.3.3.1 . закрывали квартал на такой конфигурации. Базу тестировали и средствами 1с и средствами sql. Пока результат нулевой. У кого мысли есть на сей счет?

как понимаешь что завис расчет? пишешь "закрывали квартал" - он закрылся? или он и виснет?

что есть "ошибку приложения или виснет просто"

Ну сразу - Сейчас текущая версия УПП 1.3.5.1
почему мучаетесь со старьём?

затем.. Текущая платформа давно уже 12-я.. почему мучаетесь со старьём?

и если сыпится по "ошибке приложения" - это явно проблемы уровня виндов (криво стоит 1С, или проблемы с дисками и т.д.)

1. Висит расчет июля месяца - среднне время расчета 1.20 минут. если висит более 6 часов - считаю что висит. не пишет в журнал регистрации.
2. квартал закрыли без проблем. вот и пишу, что в систему нового ничего внесено не было.
3. Меня новый релиз мало пока интересует - там исправления по ЗП в основном- а зп ведем в другой базе.
4. На текущей платформе рассчитывали уже, поэтом не в ней дело.

встречный выпуск есть?

(6) подожди.. ты конкретизируй.. тут или "вылет по ошибке приложения" или же расчёт "уходит в туман". Это разные проблемы.

Если большое время расчёта - нужно смотреть вначале что тормозит.. какая загрузка процессора, ОЗУ, дисковой подсистемы, сетевой подсистемы... А вот вылет по "ошибка приложения" - это другая песня

(8) Андрей ты ли это???

(9) (скромно потупясь и шаркая ножкой)
Если через столько лет отсутствия меня помнят - то да, это я :-))))

90 % случаев просто в туман уходит. Вылетало тока на 1 серванте, но больше на нем не запускаем, там возможно чего то и с самой 1с.
Самое интересное что где то на последних циклах итераций виснет. Хорошо, ещё 1 момент - восстанавливаем базу из бэка, двухдневной давности - расчет проходит. документов влияющих на расчет в этот период времени не вводилось

(0) райд какой?

(12) 5-й если не ошибаюсь

на файловой версии расчте проходит

(14) если на файловой проходит, то тогда сразу вопрос "что за сиквел" и что с настройками СУБД (какой уровень восстановления)?

(13) 5-ый райд - это не хорошо...

sql 2008 утилита SQL Server 2008 R2 BPA  проблем не показала
модель восстановления - полная

(17) а смысл в "полной"? Попробуй тоже самое на Simple
как вариант у тебя трабла с транзат-логами

нет - не в этом дело. базу подняли с полного бэкапа - а там нормально зафиксированные тразакт логи.

(19) так посмотрите в профайлере на чём висит 1с-ка. На какой транзакции...

Но если в файловом считается, то я бы в первую очередь бы попробовал в Simple mode режима восстановления

Но если в файловом считается, то я бы в первую очередь бы попробовал в Simple mode режима восстановления - можно попробовать. но тогда не работает это правило, тогда как бэк 2 х дневной давности рассчитывается замечательно. Щас попробуем базу перенести на другой скуль сервер и там просчитать.

Восстановили из бэкапа, модель рековери  - симпл.
Последнии строки в профайлере sql перед тем как повиснуть (они имеют статус успешно выполеных):

exec sp_executesql N'SELECT DISTINCT
_AccumRg20843_Q_000_T_001._Fld20845RRef AS f_1,
_AccumRg20843_Q_000_T_001._Fld20848_TYPE AS f_2,
_AccumRg20843_Q_000_T_001._Fld20848_RTRef AS f_3,
_AccumRg20843_Q_000_T_001._Fld20848_RRRef AS f_4
FROM
_AccumRg20843 _AccumRg20843_Q_000_T_001 WITH(SERIALIZABLE)
WHERE
_AccumRg20843_Q_000_T_001._Period >= P1 AND _AccumRg20843_Q_000_T_001._Period <= @P2 AND _AccumRg20843_Q_000_T_001._RecordKind = CAST(@P3 AS NUMERIC(1,0)) AND _AccumRg20843_Q_000_T_001._Fld20861RRef = @P4 AND _AccumRg20843_Q_000_T_001._Fld20844RRef = @P5',N'P1 datetime,@P2 datetime,@P3 numeric(1),@P4 varbinary(16),@P5 varbinary(16)','4010-07-01 00:00:00','4010-07-31 23:59:59',1,0xB1C1B65F81E8332F47A5049E67485A6C,0x912F0030849E083511DEA8C4B41FBBBD

TRUNCATE TABLE #tt3

ты хотел на другом скуле посмотреть результат. посмотрел?

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

бывает у меня проскакивает глюк в системе: открываю групповую обработку, выбираю документ, говорю "менять реквизиты" и по нажатии ОК приложение закрывается. без слов и по-английски. Причем это в копии базы, в рабочей нормально (3*тьфу). Обе базы на одном скуле, сервер приложений один, базы одинаковы...грешу на демоническое обновление

(22) А что у тебя в качестве _AccumRg20843_Q_000_T_001 выступает?

(22) и обрати внимание на параметры: '4010-07-01 00:00:00','4010-07-31'

С фига у тебя даты 4010 года????

тестирование полное выполнено
А что у тебя в качестве _AccumRg20843_Q_000_T_001 выступает - а хз, нет желания смотреть. если бы туда запись была - 1 вопрос, а так от туда чтение было, вполне успешное.

С фига у тебя даты 4010 года???? - а потому как при создании базы на сервере приложения выставил смещение в 2000.

Проба на другом скуле не увенчалась успехом.

дата 4010 - правильная.
не хочешь лишних проблем ВСЕГДА ставь смещение 2000!

(29) Вполне возможно я чЁ-то в этой жизни не понимаю. Но никогда смещения дат не ставил и всё работает. Может я не замечаю этого "главного"? :-)

(30) Смещение жить не мешает. Причина не в нем. Мысли есть? Или дальше треп писать будем про смещение?

Эпопея закончилась. единственное что помогло - смена платформы. видимо где накрылись служебные данные. Перевод в файловую и обратная загрузка в скуль проблему не решило. Чего только сделано не было и другой скуль, и 32-х битный сервер приложения т .д тока смена платформы помогла на 8.2.12.78.