oracledba.ru

OraSRP with Google Charts

2007-12-20T13:25:00.000+03:00

OraSRP now is able to generate charts using Google Chart API. Actually, OraSRP is just generates a hyperlink and Google generates *.png picture.

This feature is disabled by default and you can enable it by specifying --google-charts flag.

10046 trace file content

2007-04-25T13:37:00.000+04:00

Robert Freeman wrote in one of his articles:

The 10046 trace file contents differ greatly between different versions of Oracle.

Indeed, format of trace files changes sometimes between Oracle versions but definitely not greatly.

Somewhere near 9.2.0.2 STAT lines changed a bit (row source execution statistics was added).
Instead of just:
STAT #2 id=1 cnt=1 pid=0 pos=1 obj=17 op='TABLE ACCESS FULL FILE$'
they started look like this:
STAT #2 id=1 cnt=1 pid=0 pos=1 obj=17 op='TABLE ACCESS FULL FILE$ (cr=4 pr=0 pw=0 time=91 us)'

And in 10.2 format of WAIT lines and BINDS sections changed significantly.

BINDS sections can not be processed by tkprof in any versions of Oracle so I just skip them.

As for WAIT lines, here's the pre-10.2 WAIT line:
WAIT #4: nam='SQL*Net message from client' ela= 2794957 p1=1111838976 p2=1 p3=0 p3=62
Compare it with 10.2:
WAIT #4: nam='SQL*Net message from client' ela= 2794957 driver id=1111838976 #bytes=1 p3=0 obj#=62 tim=42601199281

Wait events parameters (p1,p2,p3) got a meaningful name (as a side note: but sometimes not a meaningful value -- #bytes in 'SQL*Net messages' still always equal to 1) and every WAIT line now have tim-stamp.

The funny thing is that tkprof from Oracle 9.2 correctly process trace files from 10.2! Looks like tkprof parses WAIT line by splitting line on '=' character and just gets the first three values.

In summary, I beleive that when tkprof from old version can correctly process trace files from the new one then it's more natural to say that 'trace files contents does not differ greatly between different versions of Oracle'.

event 'events in waitclass Other' in Oracle 10.2

2006-05-30T12:04:00.000+04:00

From release to release Oracle constantly increases the number of events (select count(*) from v$event_name). For example, Oracle 9i has 405 events, Oracle 10.1 has 811 events and Oracle 10.2 has 874 ones.

We can monitor session's wait events via v$session_event and system's ones via v$system_event.

The tricky point here is that in 10.2 a number of events (588, to be exact) are grouped into one event in v$session_event. It's almost all events of wait class (v$event_name.wait_class) 'Other'. In Oracle 10.2 there are 590 events of wait class 'Other' and 284 remaining events:


SQL> select count(*) from v$event_name where wait_class='Other';

COUNT(*)
----------
590

SQL> select count(*) from v$event_name where wait_class!='Other';

COUNT(*)
----------
284

And v$session_event can store information only for 286 events out of 874 ones. Here's some kind of proof:

v$session_event is based on fixed table x$ksles. Below is the definition of gv$session_event taken from v$fixed_view_definition:


select
s.inst_id,               -- INST_ID NUMBER
s.kslessid,              -- SID NUMBER
d.kslednam,              -- EVENT VARCHAR2(64)
s.ksleswts,              -- TOTAL_WAITS NUMBER
s.kslestmo,              -- TOTAL_TIMEOUTS NUMBER
round                    -- TIME_WAITED NUMBER
  (s.kslestim / 10000),
round                    -- AVERAGE_WAIT NUMBER
  (s.kslestim / (10000 * s.ksleswts), 2),
round                    -- MAX_WAIT NUMBER
  (s.kslesmxt / 10000),
s.kslestim,              -- TIME_WAITED_MICRO NUMBER
d.ksledhash,             -- EVENT_ID NUMBER
d.ksledclassid,          -- WAIT_CLASS_ID NUMBER
d.ksledclass#,           -- WAIT_CLASS# NUMBER
d.ksledclass             -- WAIT_CLASS VARCHAR2(64)
from
x$ksles s,
x$ksled d
where
s.ksleswts != 0 and s.kslesenm = d.indx

Note that x$ksles is a fixed table. It means that it resides in fixed area of SGA and it can't be changed (grow/shrink) when instance is running. In other words, it's just a fixed piece of memory which changes its size only after you change 'sessions' parameter.

The field x$ksles.kslesenm is an event# from v$event_name.

Let's see how many events indexes we have in x$ksles:


SQL> select count(distinct kslesenm) from x$ksles;

COUNT(DISTINCTKSLESENM)
-----------------------
                    286

286! If we select events from v$session_event ordered by event# then first 286 events will be exactly these events.


SQL> select event#,name,wait_class from v$event_name order by event#;
     0 null event                           Other
     1 pmon timer                           Idle
     2 rdbms ipc message                    Idle
...
   283 JS kill job wait                     Administrative
   284 JS coord start wait                  Administrative
   285 events in waitclass Other            Other

See that last event with event#=285 ? Named as 'events in waitclass Other'. It's some kind of pseudo-event. When session generates any events with event# more than 285 (all of such events are in class 'Other') then they are reflected in v$session_events as one event 'events in waitclass Other'.

"Optimizing Oracle Performance" in Russian

2006-01-08T08:25:00.000+03:00

� �� 2005 �� -�� "Optimizing Oracle Performance" �� "Oracle. �� ". ISBN �� 5-93286-078-2. �� 2000 ��.

undocumented flags in tkprof

2005-11-11T12:30:00.000+03:00

verbose=yes instructs tkprof to display SQL Text address and SQL Text Hash Value for every statement and print Oracle commands count for a whole trace file.
diag=filename instructs tkprof to generate some debugging information (helpful probably only to tkprof's developers).

link to podcast with Ray Lane

2005-10-17T08:07:00.000+04:00

Venture Gang is a podcast with Ray Lane who will be the keynote speaker at Hotsos Symposium 2006.

what's on your miniCD?

2005-10-06T12:10:00.000+04:00

I have one miniCD (handmade remastered) with the following contents:

Damn Small Linux -- desktop Linux with number of useful applications (word-processor, spreadseet, email client, icq, firefox, vnc/rdesktop clients, pdf viewer, perl, python, cd/mp3 player, tetris, etc).
Full Oracle Database 10.2 documentation in html format.
Oracle instant client and sqlplus with support of command line editing and word-completion (like in bash).
TOra -- Toolkit for Oracle which aims to help the DBA or developer of database application. Features PL/SQL debugger, SQL worksheet with syntax highlighting, DB browser and a comprehensive set of DBA tools.

All of this software resides on one small (80mm in diameter) miniCD with 210Mb of raw capacity.

Amazing, isn't it?

OraSRP v2.1

2005-09-27T05:43:00.000+04:00

Well, it seems that after OOW (specifically, after presentation of Kyte and Millsap) everyone knows that Oracle enhanced format of 'WAIT' lines in trace files. By the way, OraSRP recognizes new 'WAIT' format starting from v1.8 (released in July).

But in 10.2 Oracle also slightly changed format of 'BINDS' section. Yesterday I added support of this new format of 'BINDS' into OraSRP v2.1

Also improved processing of 'RPC CALL/EXEC' entries (previously, when trace file contained more than one 'RPC EXEC' per one 'RPC CALL' then results were wrong).

Removed irrelevant numbers (for 'Total' row) in 'Statement Resource Profile' section.

Some fixes for preventing OraSRP from crashes when analyzing "inconsistent" traces.

rather big plan

2005-09-23T12:49:00.000+04:00

Want to see a big plan with little efforts?
Just execute 'select count(*) from all_policies;'

10gR2 generates 161-lines plan for this statement!

[ below the same in Russian ]

�� , � �� , ��
�� 'select count(*) from all_policies;'.

10gR2 �� select'� �� 161 ��!

reading documentation

2005-09-22T13:45:00.000+04:00

Just a citation from docs:

"The additional overhead of running the SQL Trace facility against an application with performance problems is normally insignificant compared with the inherent overhead caused by the application's inefficiency."

OraSRP v2.0

2005-09-08T15:38:00.000+04:00

I released OraSRP v2.0

Starting from v1.6 I promised to implement 'statements tree' feature. Five(!) versions after that I finally implemented this feature. From now on resource profile contain section 'Statements Recursive Relationship' where you can see statements tree for session. By the way, sometimes it's just interesting to see how one user statement (like drop table) generates a lot of recursive statements!

In this version I added calculation of elapsed time separately for every bind set. Bind values sets now sorted by elapsed time. By default only one bind set for statement is displayed. And it will be the set with the most elapsed time spent.

Added check for presence of line '*** DUMP FILE SIZE IS LIMITED TO' in trace file. In that case a warning is displayed.

OraSRP v1.11

2005-08-17T14:40:00.000+04:00

Ok, yesterday I failed to parse 1.5Gb trace file with OraSRP v1.10 on Linux machine with 512Mb RAM. It reminds me to some inefficiency in internal data representation.

So, I fixed this problem and released OraSRP v1.11 which succesfully parses that 1.5Gb file.

Also in this version I splitted 'CPU service' pseudo-event into three events: 'CPU service, PARSE calls', 'CPU service, EXEC calls' and 'CPU service, FETCH calls'.

And starting from v1.11 OraSRP shouldn't crash on trace files with malformed lines (this may happens when trace file reached the limit of max_dump_file_size).

OraSRP v1.10

2005-08-05T15:41:00.000+04:00

I released OraSRP v1.10

Added printing of 'optimizer goal' info for every statement.

Added <!DOCTYPE> string into html output and changed a little CSS stylesheet.

Added --binds flag: specify maximum number of binds sets to display (1 by default).

It means that from now on OraSRP is able to process bind values in trace files. By default OraSRP displays only most frequent bind values set but you can change it via --bind flag (i.e. when you specify, f.e. --binds=999999, then OraSRP will display all bind values; and if you will specify --binds=0 then OraSRP will just ignore bind values).

OraSRP v1.9

2005-07-26T13:13:00.000+04:00

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

2005-07-25T08:05:00.000+04:00

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

2005-07-19T21:40:00.000+04:00

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

2005-07-11T11:02:00.000+04:00

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

2005-07-09T14:31:00.000+04:00

�� 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

2005-07-08T16:43:00.000+04:00

�� , �� fixed views (�� v$fixed_view_definition, �� ) � �� fixed views �� Oracle Database 10G Release 2 � �� .

orasrp v1.7

2005-06-27T15:12:00.000+04:00

� �� OraSRP �� 1.7

�� .

�� 'RPC CALL'/'RPC EXEC'.

�� CSS style sheet, � �� html-�� OEM 10g.

�� .

�� oracle-l

2005-06-16T05:44:00.000+04:00

�� ?
�� : �� rm -f *.dbf �� rm -f * .dbf
�� : �� , �� rm -rf ./dir �� rm -rf ./ dir

�� URLT (Update Resume Leave Town) moment.

�� ?

2005-05-11T20:40:00.000+04:00

�� (unix) ��?
�� . �� $ORACLE_HOME, �� .

�� .

Connor McDonald � �� oracle-l �� , �� 130 (�� ) instance'��! �� /�� instance.

fast export - import

2005-04-12T13:56:00.000+04:00

�� export - import?

�� "�� export - import".

orasrp v1.6

2005-03-30T10:46:00.000+04:00

� �� OraSRP v1.6

�� -- �� '--aggregate-statements'. �� On. �� OraSRP �� (� �� bind variables) statements.

��, ��


select * from table1 where column1='value1' �
select * from table1 where column1='value2'

�� . �� , � �� , �� 'similar statements: 1'

�� , �� Hotsos Profiler'�.
�� , ��, �� statements, �� bind variables. ��, �� 'Parse' � �� bind variables.

�� --aggregate-statements=off, �� , �� tkprof. �� , �� .

� �� --cache � --ignore-statements.

�� OraSRP �� .

�� 'statements tree', �� .

��

2005-03-22T12:37:00.000+03:00

�� -�� account'�� ?

�� , �� (� �� ) ��.

�� , �� .