OraSRP v1.9

I released OraSRP v1.9

A little changes in outputs (only get rid of irrelevant numbers in Summary section).

Added three new flags:
--stdin tells orasrp to read data from stdin. By using this flag its possible to analyze gzipped/compressed trace files on the fly. Like this:
$ gzip -cd trace_file.trc.gz | orasrp.py -s --stdin > trace_profile.html

--pattern flag is used in http server mode. It tells OraSRP to show/process only those files which names contain specified pattern.

--htpasswd flag is also used in http server mode. It instructs OraSRP to use .htpasswd file for client authentication. To create .htpasswd file one can use either htpasswd utility from apache web server or htpasswd.py supplied with new versions of OraSRP.

Combination of --pattern and --htpasswd flags allows DBA to grant access to developer for analyzing of his/her own trace files without breaking security. I mean, that by default Oracle server process generates trace files accessible only to DBA. And this is good from security point of view (and, btw, setting up _trace_files_public=true is bad from security point of view). But, contrary, disallowing developer to access to his/her own trace files is bad from performance point of view. Here's the three-step solution for this dilemma:

1. DBA tells developer to use unique tracefile_identifier (alter session set tracefile_identifier='uniq_devid') before enabling extended SQL trace.
2. DBA creates .htpasswd file in user_dump_dest and adds an entry in this file for this developer.
3. DBA runs OraSRP on the server (let's call it prod01) like this:
$ orasrp.py -d /path/to/user_dump_dest --htpasswd --pattern=uniq_devid --port=3000

After that DBA just provide the developer with the link (http://prod01:3000/).

Voila! Developer can now analyze his/her own trace files. But he/she still doesn't have access to other's traces and is not able to view raw traces (with systemstate dump, for example).

what to do with hanging database

Here's the citation from article 'Oracle Database 10g: Top Features for DBAs: Part 3—Performance Features' by Arup Nanda:

Let's assume that you use Oracle Enterprise Manager to diagnose and solve performance issues. One day, a nasty issue arises: a badly designed application is causing serious library-cache lock issues and the database appears to be hung. You have to quickly identify the culprit sessions and kill them quickly.

You could bring up Oracle Enterprise Manager to diagnose this issue. But, wait! If the entire database is saturated with hung sessions, wouldn't the query from Oracle Enterprise Manager hang as well?

With Oracle Database 10g Release 2, the answer is "no."

Actually, the answer is "no" for 8i, 9i and 10g r1 also!

I mean that even we can't use Enterprise Manager still we can use hanganalyze event (starting from 8.1.6) as quick (real quick on hanging databases) and easy way to solve 'hanging database' issue.

And remember, that we can use hanganalyze event even if we can't connect to database at all -- I explained how to do it in my previous post.

another way to generate systemstate/hanganalyze events

It's a known fact that we can generate systemstate dump by directly attaching to oracle process. Like this:

$ cd $ORACLE_HOME/bin
$ gdb oracle <oracle_pid_to_attach>
(gdb) call ksudss(10) # at this point attached process should do smth, i.e. it shouldn't sleep

Search for 'ksudss' in Metalink for more detailed info.

But if, instead of ksudss() we will call ksdhng() then hanganalyze trace (which is way more readable than systemstate dump and often is enough for analyzing 'hang database' issue) will be generated.

[below the same in Russian]

Известно, что мы можем сгенерить systemstate dump с помощью gdb, приаттачившись к любому oracle процессу. Примерно вот так:

$ cd $ORACLE_HOME/bin
$ gdb oracle <oracle_pid_to_attach>
(gdb) call ksudss(10) # процесс в это время должен что-нибудь делать, т.е. не находиться в ожидании

Поиск по 'ksudss' на Metalink'е дает более подробное описание.

Но если вместо ksudss сделать вызов ksdhng(), то сгенерится hanganalyze trace, который читается легче чем systemstate dump и которого, как правило, достаточно для разрешения проблемы 'почему_моя_база_зависла?'

new fields in v$session

While one known 'balabol' blows at every corner about the fact that 'The 10046 wait interface becomes obsolete ', Oracle in its new version 10.2 added three new fields in view v$session, intended only for the work with 10046 wait interface and wrote three new procedures in package dbms_monitor, utilized for the same.

Fields named SQL_TRACE, SQL_TRACE_WAITS, SQL_TRACE_BINDS make it possible to see whether session is traced and if yes, then with what parameters. However, finesse in the fact that the correct values in these fields are advanced only during use dbms_monitor, i.e., if we establish tracing with the aid of 'alter session set events' or via straight call of dbms_system.set_ev, then v$session will not show that the session is is traced. Looks like hint from Oracle about what interface we should use to enable extended SQL trace.

[below the same in Russian]
В то время, как один известный балабол трубит на каждом углу о том, что 'The 10046 wait interface becomes obsolete', Oracle в своей новой версии 10.2 добавил три новых поля во view v$session, предназначенных только для работы с 10046 wait interface'ом и написал пару новых процедур в пакете dbms_monitor, используемый для того же.

Поля под названиями SQL_TRACE, SQL_TRACE_WAITS, SQL_TRACE_BINDS позволяют увидеть, трассируется ли сессия и если да, то с какими параметрами. Однако тонкость в том, что корректные значения в этих полях выставляются только во время использования dbms_monitor, т.е. если установить трассировку с помощью 'alter session set events' или путем прямого вызова 'dbms_system.set_ev', то v$session не покажет, что сессия трассируется. Похоже, таким образом Oracle недвусмысленно намекает, как именно надо включать extended sql trace.

новый формат extended sql trace файла в 10.2

На протяжении многих лет Oracle не менял формат extended sql trace файла. К примеру, версия 7.2, вышедшая в 1994 году генерит практически такой же trace файл, что и версия 10.1

Однако, с выходом версии 10.2 инженеры корпорации Oracle решились на небольшое изменение формата trace файла. Если ранее 'WAIT'-строки выглядели примерно так:

WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1 p3=0

то в 10.2 они выглядят так:

WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1650815232 #bytes=1 p3=0 obj#=43442 tim=1094547545117701

Т.е. названия параметров p1/p2/p3 тут же расшифровываются исходя из значения nam.
Для каждого WAIT'а пишется возможный номер объекта, вызвавший ожидание. Ну и, наконец, ставится timestamp, что слегка облегчает задачу анализаторам trace файлов.

Однако, tkrpof из 10.2 генерит отчет, ничем не отличимый от предыдущих версий. Возможно, в дальнейшем это изменится. Либо мы увидим какую-нибудь новую тулзу, учитывающую новый формат trace файла.

fixed view definitions in Oracle Database 10.2

Для любопытных персон, которые время от времени разглядывают определения fixed views (находящихся в v$fixed_view_definition, но в неотформатированном виде) я выложил определения fixed views из Oracle Database 10G Release 2 в человеческом виде.