GERR, не хочу ставить под сомнение мнения Ваших друзей, но я бы так категоричен не был. Сколько копьев на этой ниве уже поломано... А сколько еще будет! :)

Да, действительно не стоит))
Тем более я сам довольно поверхностно знаю 1С.

Подробности в студию, страна должна знать своих героев :)

Даже не предполагаю кого Вы называете героем...

Ну тогда по порядку:
Для начала отрубил сервер от сети, и посмотрел на него в состоянии покоя - это чтоб отсечь системные сбои.
Затем проверил диски на всевозможные ошибки и бэд-секторы - это чтоб отсечь проблемы с накопителями.
Затем были отключены все не системные базы данных и подключен обратно к сети - это чтоб отсечь всяческие вирусняки или происки каких-нить конкурентов (вдруг кто специально наш сервер ложит... да-да паранойя всегда со мной :) )
После всего этого сервер ни разу даже не чихнул. Значит дело в каком-то криво написанном и работающим с SQL софтом. Этот вывод вызвал маленькое недоумение, поскольку весь софт в конторе, общающийся с сервером (не считая 1С, конечно), написан лично мной (или в команде со мной), и работает уже не один год. 1С тоже давно на нем прописалась. Семерка с 2006 года, восьмерка с октября 2008 года. По идее подобные косяки уже должны были бы велезти наружу. Ан нет...

Поиски "преступного" приложения, которое могло бы вызвать столь масштабное действо с базой tempdb, решил искать так: отключались вообще все базы, а затем по одной подключались обратно и наблюдалась деятельность пользователей.
Мне жутко повезло, что бухгалтера оказались самыми нахальными, и в первую очередь по одной были запущены базы для 1С v7.7. Сервер это пережил нормально (оно и понятно, все таки семерка мало чего делает непосредственно на сиквеле - в основном тока данные туда-сюда гоняет).
Через полчаса была запущена база конфигурации ЗУП уже для 1С восьмерки. Тоже все прошло нормально.
Еще через полчаса была запущена база для восьмерочной бухгалтерии. И вот оно - не прошло и пяти минут сервер уже стонал от бессилия и его инстинкт самосохранения остановил сервис с выше обозначенными сообщениях в логах. Личность преступника установлена. :)

Дальше начались поиски "точки входа в косяк". Это оказалось самым геморройным делом. Поскольку пользователей куча, приходилось выяснять то, что-же кто делал в момент остановки сервера. Свелось это к банальному опросу юзеров, потому что одинэсовский журнал регистрации событий имеет маленькую, но очень неприятную, особенность - он регистрирует события уже по факту их происшествия. Все попытки действий не дошедшие до своего логического завершения там не фиксируются. На просьбу вспомнить свои манипуляции, естественно мало кто чего вразумительного отвечал, в основном - "Работала!" :) Поэтому опять-таки по одному пускались юзеры в базу и наблюдалась их активность. Так нашелся бухгалтер - виновник торжества.

Маленькая ремарка:
Платформа 1С восьмерки наконец-таки дала возможность почти полноценно работать с базами данных. Строить сложные запросы, в том числе и с использованием временных таблиц. Это очень удобно и эффективно, но в этом кроются и подводные камни. Наверно уже понятно зачем я эту ремарку вставил. :)

Так вот определив документ, который вызывал крах (им оказался документ "Списание материалов из эксплуатации"), я внимательно стал смотреть чего-же в нем понаписали программисты 1С. Увидел множество запросов к базе с использованием тех самых временных таблиц в рамках одной процедуры. Еще ремарка: уж так устроена платформа, что уничтожение временных таблиц (а тем самым и очистка базы tempdb на SQL сервере) происходит после того, как все операторы процедуры будут выполнены (если их очистка не вызвана явно в теле процедуры). Как можно догадаться принудительно никто их не очищал, данные копились. В определенный момент достигался предел (хотя мне трудно представить, чего же там такого огромного было), по каким-то причинам база tempdb не могла увеличиться, сервер останавливался. Сил выяснять причины такого поведения SQL уже не было (шел 13-й час борьбы с проблемой, и дело близилось к полуночи :) ) - решением проблемы стало дробление документа на два.

Резюмируя хочется верить, что это отдельно взятая беда SQL Server 2000, на ряду с ограничением на количество в 256 таблиц участвующих в одном запросе. Как не хотелось мне переходить на более современный сиквел, но по ходу дела придется.

Если полиси позволяют, то почему бы ине перейти? 2005 получше чем 2000. Так что ура апгрейду :)

Kir, Да основным тормозом перехода была 1С семерка. Она официально не работает с 2005 сервером. Не говоря уже об 2008. А всяческого рода запилы (есть вариант правки нескольких dll из состава 1С) мне не очень по душе...
И потом при переходе (давно правда это было) с версии SQL 6.5 на версию 7.0 пришлось много чего править, из-за отличий в синтаксисе. Вроде бы с 2000 переход легче осуществляется, но кто обещаниям Билли верит!? :)