Dimoniy

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

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

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

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

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

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

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