Тоже интересно, только желательно всё же на русском языке.
Oracle. Основы стоимостной оптимизации - хороша, но устарела, так как вышла аж 11 лет назад, когда первая 11.0.1 версия вышла(

dbms_photoshop,

это всё понятно, правда с sql trace (event 10046) не соглашусь, так как в промышленной среде проще сделать как раз его, tkprofнуть и понять в чем причина. к тому же у нас есть обертка, позволяющая получать обработанный tkprofом результат прям в приложении, не лазя на сервер.
Говоря о том, что книга устарела я имел в ввиду только то, что появилось довольно много новых фич с тех времен, и хотелось бы видеть переиздание книги с описанием всех этих новомодных штучек

dbms_photoshop,

заказчик говорит что медленно работает бизнес-операция на проде, куда у нас нет доступа.
гораздо проще запросить трассировку с wait и по её результатам быстро выявить виновный запрос/событие
ASH не столь информативен если собирать по sid, а по всей системе вообще относительно бесполезен.
к тому же трассировка и результат снимаются прям из приложения самим пользователем, что быстрее, нежели подключать админов и просить AWR/ASH/SQL monitor

xtender,

xtenderТ.е. у вас пользователь может включить трассировку по всей системе?
По своей сессии, а не по всей системе.
xtenderВообще-то ASH как раз удобнее для анализа всей системы в целом Согласен, но для анализа конкретной бизнес-операции удобнее именно трассировка
xtenderИ самое главное, ASH/RTSM позволяют получить информацию "прямо сейчас", а не дожидаться когда "бизнес-операция" на проде выполнится целиком, тем более что для уже работающей "бизнес-операции" - это может оказаться бесполезным, если проблемная часть уже завершилась и придется перезапускать с трассировкой с самого начала
Не понял что такое RTSM, гугл сходу тоже ответа не дал. Обычно если пользователь говорит о проблеме, то это проблема воспроизводимая и не составляете никакого труда снача тыркнуть галочку "включить трассировку", запустить операцию, а после выполнения нажать кнопочку "Показать результат". а в случае с ASH нужно дополнительно подключать администратора, при этом ASH по сессии менее информативен.
xtenderОбычно если 10046 и нужно, то нужно в сыром виде, а не обработанный огрызок. Я вынужден не согласится, так как в большинстве случаев в сыром виде в нашем случае она как раз не нужна. Чаще всего мне интересно узнать какие запросы работают дольше всего, сколько раз выполняются и какие у них планы. tkprof в данном случае гораздо удобнее. Более того, я честно говоря, так сразу даже и не могу представить какие-то более-менее стандартные ситуации, когда нужна была бы именно сырая трасса, да может в каких-то особо сложных/непонятных случаях она и нужна, но в большистве случаев tkprof или ORASrp мне предоставят всю необходимую информацию для поиска виновника.
xtenderну и вы же понимаете, что 10046 не на все даст ответы? понимаю, но если трассировка не даёт мне ответов, никто же мне не мешает использовать дополнительные инструменты?
dbms_photoshop Просил предоставить пример - я его предоставляю и говорю лишь о том, что использование трассировки, как инструмента для первичного анализа в моём случае очень хорошо себя зарекомендовало и в большинстве случае такой подход позволяет сразу же находить виновников

Stax, да именно так

xtender,

Не стоит так бомбить. Судя по приведенным ссылкам на дискуссии, у старожилов просто начинает бомбить после того, как они слышат, что кто-то использует трассировку.
По сабжу - я привел вполне конкретный сценарий, вы же его начинаете расширять за те рамки, где трассировка действительно будет бесполезной, возможно я как-то некорректно описал сценарий, попробую еще раз:
Есть клиент на поддержке, у клиента возникает проблема с конкретной бизнес-операцией, в одной сессии , работающей 5 минут вместо 2-3 секунд. При этом доступа на прод у нас абсолютно нет .
Зато в приложении, через которое запускаются операции есть возможность включить трассировку своей же сессии, а затем так же через приложение,самим пользователем, получить tkprofнутый результат.
Повторюсь, у нас при этом доступа к проду нет и xtenderхахъ, админы вам гранты на включение трассировки дали, читать файлики позволили, и они вам не нужны, а вьюшки поселектить без админов никак? мы не можем поселектить вьюшки.
При этом проблема в 90% случаев будет в корявом запросе, который эта самая ненавистная tkprofнутая трассировка сразу же покажет в самом верху.

Речь не идёт о проблемах с блокировками/латчами/мьютексами
Речь не идёт о каких-то много-сессионных операциях и параллельных вычислениях
Речь не идёт о xtenderно как насчет такой частой вещи как автоматические процессы
Речь не идёт об общем падении производительности по базе
Речь не идёт о проблемах с железом
При возникновении подобных ситуаций будут меняться и инструменты

Речь идёт о вполне конкретном сценарии, с вполне конкретными условиями и возможностями получения информации.
И в таких условиях получить и отправить результат tkprof-нутой трассировки может сам пользователь бизнес-операции, что гораздо проще и быстрее, нежели привлекать админов и просить ASH/AWR/SQL monitor отчёты.