вижу

ну хозяин барин

такой подход к работе ? те девелоперы которых знаю я таки смотрят в планы выполнения и wait events, там "либо выполнилось либо нет" не канает.

будет, надо только один раз вникнуть в то как работает тот или инной продукт. Иначе потом появляются вопросы как у ТС. Плюс обиды что советуют "не по теме".
По мнению не безизвестного тома кайта грош цена девелоперу для которого база blackbox.

wait event'ами нельзя управлять. wait events это индикатор того что происходит с запросом и с базой в целом. На них надо реагировать, а не управлять.

девелоперы которых знаю я таки смотрят в
------
Днями шеф принес лог трассировки доступа к сайту... 170 однвременных аплоудов (не довнладов) - потолок.
Спашивает - Что можешь сделать? - отвечаю - Смотрел поверхностно, могу улучшить примерно в два раза.
Больше - не уверен, надо смотреть детали, но туда надо лезть после вот этого и вот этого. - гворит он мне
- Ладно, делай что считаешь нужным, потом еще раз потестим и подумаем.
За полдня Я поднял производительность примерно в 5 раз. Никаких планов запросов и тому подобной
чепухи - прямой анализ того, что лишнего делает система и урезание узких мест - там были ненужные
перезапросы. Производительность, на сегодня, устраивает. Можно повысить еще раза в три... для этого
надо всего лишь переработать... базовый код примерно 300 сайтов.
не канает.
------
Канает. Я бы просто выгнал прикладника, который полез бы базу, вместо грамотного использования
предоставленного интерфейса.
Но в тоже время - вигрыз бы мозги ДБА если бы интерфейс не покрывал требования задачи...
По мнению не безизвестного тома
------
...а кто такой этот Пикасо?
На них надо реагировать
------
Неа... У меня вот сейчас аналог этого эвента... с задержкой на 20-25 часов... Шеф, когда Я обяснил что
и зачем там делается, просто кипятком писает - полная асинхроника там, где до этого юзери по 10-15
минут ждали синхронного ответа системы... А работа - хоть по шедуллеру, хоть по идлу, хоть по внешнему
запросу... и пофиг на то, сколько там ждать - она отработает вовремя и гарантированно.

смотреть статистику которую тебе дает база и есть грамотное ее использование девелопером.

пожалуй самый знаменитый эксперт по базам (в особенности оракловым)

дальше можешь не рассказывать, все ясно короче :)

смотреть статистику
------
Для ДБА. Прикладнику там делать нефиг...
самый знаменитый
------
А... ну бог с ним... Помнится, надо было что-то починить... мелочевка какая-то... ну да только разработчики смогли разобраться что да как...
Про экспертов - это отдельная пеСТня... Скоро оно будет классифицироваться как ругательство... по крайней мере в известной с(т)ране...
все ясно
-----
Так оно и до начала было ясно...

Такое поведение говорит о том, что база битая.
Иногда помогает прибить индекс и заново его создать.
По правильному в зависимости от нагрузки должны отрабатывать Maintenance Plans. Например ночью часа в 3.
Если Maintenance проваливается дальше Repair без разрешения исправлений и потом по результатам с разрешением.
Естественно не забывать про бакап, который должен быть по расписанию. Обрезание также по расписанию.

меня на sql.ru облили с ног до головы за то что я обрезаю log а потом делаю shrinkdatabase.
посмотрел в нете, помоему закономерная последовательность. но похоже все равно что то не так.
могут быть какие то проблемы если так сделать?
backup log @db_name with no_log
dbcc shrinkfile (2,0)
backup режется в процедуре до и после выполнения update's ночью.. днем работает приложение, вечером в 10 backup. в 3 ночи updates.
так работает все несколько лет. в одной из баз наблюдаю выше описанное. таблицы создаются тоже в процедуре, потом к ним добавляются индексы, все отрабытывается, таблицы удаляются.
саму процедуру разбил на шаги.. по 200-300 datensätze..всего околко 10 тыс.
раз процедура отрабытывает за 2 часа, второй раз виснет в одном из запросов (место не фиксировано). меняю шаг, опять все отрабытывется.. не пойму че за хрень..

Форум sql.ru на самом деле полезный.
Лог файл - это файл в котором выполняются транзакции, он и называется Transaction Log. Если к базе никто не обращается, то его можно сжать, если модель не FULL(не требуется хранить транзакции), а потом делать бакап(просто места меньше, если бакап не инкрементальный). Естественно он растет в момент выполнения процедуры, и если прервать транзакцию, то все должно вернуться назад. Естественно после выполнения процедуры его сжимать не надо.
DBCC CHECKDB - проверяет целостность базы если у Вас целостность в порядке, то дело в процедуре.
Может быть все, что угодно вплоть до распределенных транзакций (которые выплняются на двух или более серверах).
Да и выполнение процедуры 1 час -- не радует изначально. Для чистки лучше 60 раз по секунде(это не опечатка), кстати и лог расти не будет.

ошибку дает
The In-row data USED page count for object "Liz_Avail_Lizenz_Mandant", index ID 2, partition ID 603070911152128, alloc unit ID 603070911152128 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
после DBCC UPDATEUSAGE Job отработал без ошибок ночью. спасибо за инфо.