Здравствуйте, формирую в УТ (переписанная 10.3.5.1, платформа 8.1.13.41) отчет "Продажи по оплате за период". Интервал формирования - один месяц, группировка всего лишь одна - Покупатель.Основной менеджер покупателя, измерение одно - Сумма продажи, по одному фильтру по подразделению и группе номенклатуры. База совсем небольшая (оптовая торговля) - примерно 700 реализаций в месяц, в каждой в среднем 5 позиций. Заказов - 1200 в месяц.

После продолжительного зависания выскивает ошибка "Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных "tempdb" заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы sys.databases
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: Error state=4, Severity=11, native=9002, line=1
SQLSrvr: Error state=4, Severity=11, native=9002, line=1"

Отчего такое может быть?

"Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы sys.databases" - тебе вслух прочитать?

(1) Нее... Ты по слогам прочти. А лучше скажи что делать-то?

(2) Я ж тогда его зряплату буду требовать :)

А ху-ху не хо-хо? :))

Перезагрузите сервер с MS SQL Server. Или службу перезапустите. tempdb пересоздастся. Если места все равно будет мало - перенесите файл журнала tempdb на диск где больше свободного места, или сделайте дополнительный файл журнала templog на другом жестком диске.

(1) мда уж, помощник из тебя никудышний.

+(5) А "отчего" - оттого что у вас активно tempdb используется, лог растет и, дорастая до определенного момента, больше не может увеличиться, вероятно из-за того, что место на диске кончается

Одно из двух: или места на дисве уже нет, или это действительно ошибка SQL. Что у автора?

Это не одно из двух. Это одно и то же. Нет места на диске => templog.ldf не может увеличиться => ошибка. Есть еще вариант, что файлу жестко задан максимальный размер, который и достигается в ходе выполнения его процедуры, но думаю, что если бы он сам занимался сайзингом файлов, такого вопроса как (0) - не было бы

(6) Всяко лучше, чем из тебя работник.

(9) Сорри, опровергая меня, Вы сами себе противоречите :( Вариантов, на самом деле, может быть множество. Особенно если кривые ручки приложить к SQL :)

http://www.google.ru/search?hl=ru&newwindow=1&q=SQL+log+simple+site%3Aforum.mista.ru&btnG=Поиск&lr=&aq=f&aqi=&aql=&oq=&gs_rfai=

(11) Да я не то что опровергаю.. Просто это ошибка, вызванная, скорее всего, нехваткой места на диске.. А не так, что "или нет места на диске", или "ошибка". К формулировке, в общем, придрался (:
А (12) вряд ли автору поможет. tempdb по умолчанию использует модель восстановления simple

(13) скоре всего всё-таки, товарищ написал запрос, котрый пишет в tempdb сотни гигабайт.

(1)(10) Парнишка, ты сильно переоцениваешь свои остаточные знания после начальных классов.
Веди себя нормально, и пиши по делу. Строить из себя умника любой дурак может.

(5)(8) Перезагруз сделал, tempdb пересоздался. Место и до этого в принципе имелось - 25 гигов. Знаю, что это не сильно уж много. Скажите, пожалуйста, на сколько такой объем критичен.
Сама база весит: mdf - 4Гб, ldf - 16Гб. После перезагруза стало свободно 33 гига.

Образовалась еще одна странная ситуация. Вообще вышеописанная ошибка выскочила у пользователя, у которого стоит 1Ска и он напрямую цепляется к базе. А если коннектишься из-под сессии терминального сервера (на который не все юзеры хотят заходить), то отчет "Продажи по оплате за период" просто напросто виснет, и хоть сколько угодно будет висеть, ниче не сформирует.

(14) Отчет стандарный, не модифицированный, у регистров накопления измерения не трогал, ниче не менял.

Сделал select к таблице sys.databases, в столбце log_reuse_wait_desc для торговой базы значение равно "LOG_BACKUP", что до перезагруза, что после. В этом же столбце для tempdb значение равно "ACTIVE_TRANSACTION" (это во время того, как база висит).
Завтра попробую заглянуть в этот же столбец после того, как тот пользователь с 1Ской у себя на компе попробует сформировать отчет.

(0)Господи, ну сколько вас учить то еще....
http://yandex.kz/yandsearch?text=HRESULT%3D80040E14&lr=162&stpar2=%2Fh1%2Ftm1456%2Fs4&stpar4=%2Fs4&stpar1=%2Fu0

(5)(8)
Пока отчет висит в терминалах, наблюдаю за скулем. База tempdb за полчаса разрослась почти на 2 гига. Т.е. уже четко ясно, что дело в запросе отчета.
Пробую сформировать отчет за месяц - все ок, формируется быстро, в течение полминуты. Если беру интервал: два месяца, полгода. Висит... уже больше часа висит. И проц при этом на скуль-сервере загружен на четверть.

(17)
Рейв, спросил у Яндекса по твоей ссылке, но толком ниче не нашел, все да не то. Там ошибка 80040E14 много че означает.
Скажи, пожалуйста, куда копать? В изменение размера tempdb все-таки?

(19)Я, извини,не телепат. Тебе на месте скорее всего придется решать самому.

(19)Обрати внимание на (9).Попробуй на скуле установить больший максимальный размер templog.ldf, также задай больший размер динамического увеличения этого файла.

(21)
начальный размер - 8Mb, увеличение размера файлов - 10%, макс.размер файла - рост не ограничен.

Че именно поменять, скажите?

(22) Ничего менять не надо. Раз у вас размер ldf файла не ограничен, значит ошибка в (0) следствие того, что на диске где лежит templog.ldf закончилось место.
"ACTIVE_TRANASACTION" в столбце log_reuse_wait_desc говорит вам о том, что есть незавершенная транзакция, которая не дает повторно использовать место в файле журнала транзакций.
У вас ошибка "Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных "tempdb" заполнен." повторяется? В момент ошибки на диске с templog.ldf есть 25 свободных гигабайт?