Подскажите несведущему: большой размер TEMPDB #345784

MS SQL 2000, база УТ - 40 Гб. TEMPDB - 70Гб. 1. Хорошо ли это? 2. Если хорошо, до до каких размеров? 3. Если не хорошо, то что сделать?

рестартани скуль

шринк ему

кому?

темпдбе

Ужас какой!!! Что это за таблица, по-твоему?

Делали. Скуля не знаю, могу предположить, что это какой-то кэш.

там временные таблицы и всякий хлам для текущих операций находится...

+ ктати, там лог такой, или данные?

И что? Он при старте заново создается...

я знаю что это такое. а что криминального в его сжатии ?

блин так что такого страшного в сжатии tempdb ?

Не могу сказать, что происходит при перезагрузке, т.к. к SQL серверу доступа не имею. Перегружались несколько дней назад.

может последовательность кто-то за пару лет восстановил?

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

хм. напугали и молчат. шринкать темпдб можно или нет ?

почему бы и нет?

Да вот же, спасибо Господину ПЖ, я чего-то найти не мог, из : Effects of Execution of DBCC SHRINKDATABASE or DBCCSHRINKFILE While Tempdb Is In Use If tempdb is in use and you attempt to shrink it by using the DBCC SHRINKDATABASE or DBCC SHRINKFILE commands, you may receive multiple consistency errors similar to the following type and the shrink operation may fail: Server: Msg 2501, Level 16, State 1, Line 1 Could not find table named '1525580473'. Check sysobjects. -or- Server: Msg 8909, Level 16, State 1, Line 0 Table Corrupt: Object ID 1, index ID 0, page ID %S_PGID. The PageId in the page header = %S_PGID. Although error 2501 may not be indicative of any corruption in tempdb, it causes the shrink operation to fail. On the other hand, error 8909 could indicate corruption in the tempdb database. Restart SQL Server to re-create tempdb and clean up the consistency errors. However, keep in mind that there could be other reasons for physical data corruption errors like error 8909 and those include input/output subsystem problems. По-моему, рестартануть скуль надёжнее, чтобы он сам зачистил эту таблицу. Хотя, если уверен, что с ней никто не работает, то шринкай.

в написали что ужас. но по ссылке господинаПЖ типо шринканьем ТЕМПДБ вначале пугают но потом грят что типо вперед.

ИМХО лог растет, а его шринкать и при работающей базе можно

+ кстати, ответа на так и не было...

Где написано что "вперед"?

ошибка перевода. мдя. если я правильно понял грозят физическим повреждениями изза проблем ввода вывода.

(21,22) так надо шринкать лог, если он выроос, а данные не трогать...

типо если 2501 считай повезло а если 8909 то не очень ))

а зачем вобще давать расти логу темпдб ?

ну мог же он вырасти? и если таблички временные все-таки уничтожаются после использования (ну или в конце сеанса), то лог-то куда денется?

вобшем спасибо опытным товарищам. выгонять из 5 баз 140 человек конечно муторно но рисковать базами глупо.

кстати да... я все не мог понять про лог какой базы речь идет...

темпдб, вестимо, какой же еще?

а что ставить ограничение на размер лог файла TEMPDB тоже какая то хитрость запрещает ?

а вдруг его нету? (у мну 8 метров полет нормальный)

+ я вообще-то спросил в об этом, но ответа нету... что-то у меня разрывы к концу дня, похоже, начинаются...

я думал про базу ну кончится он у тебя на самом интересном месте - кого мордой по столу возить будут? йопт.. 5 баз по 140 а темпдб то одна...

имхо как то туповато. если может быть критическая ошибка с потерей данных нафиг вобще разрешать шринкать ТЕМПДБ. аргумент что это безопасно если с ней никто не работает несерьезен. отследить это нереально.

там не про шринкать темпДБ, вообще-то написано, а про шринкать вообще

вернее конкретно там про темпдб, но это предупреждение ко всем базам относится...

да логи у меня как то интересно настроены что расти не умеют. спрошу в понедельник того кто настраивал как он это сделал ;)

ну реальные базы в работе я и так не жму. лан после 30 часов без сна как то все не очень дается. не 5 по 140 а всего 140 ;) и то это макс. реально меньше

grow by 0% наверное

нет. тогда 1с в некий момент рухнет.

а вообще - если скуль 2000 то он с временными таблицами очень хреново работает... так что вполне может быть, что восстановление последовательности было - а он их удалить забыл....