I’m working on some text analysis in Python and was looking for some test data. Someone recommended I use the 9/11 Pager Data from Wikileaks. I downloaded the data, ran my program against it (which is the subject of another post) and all was well. Got some great insight and I’ll share that later.

I then started browsing the raw data in vi. After paging down a few times, what did I see?

Paging down some more yielded this gem:

The gears are now spinning…

I wondered how many of these Oracle errors polluted the NYC messaging system. Lets find out – Python to the rescue!

Error		Frequency		Description
ORA-00255	1	error archiving log %s of thread %s, sequence # %s
ORA-00333	1	redo log read error block %s count %s
ORA-00334	1	archived log: '%s'
ORA-01035	1	ORACLE only available to users with RESTRICTED SESSION privilege
ORA-01089	1	immediate shutdown in progress - no operations are permitted
ORA-01401	1	inserted value too large for column
ORA-01410	1	invalid ROWID
ORA-01652	1	unable to extend temp segment by %s in tablespace %s
ORA-01722	1	invalid number
ORA-02050	1	transaction %s rolled back, some remote DBs may be in-doubt
ORA-02068	1	following severe error from %s%s
ORA-03114	1	not connected to ORACLE
ORA-1146	1	cannot start online backup - file %s is already in backup
ORA-12154	1	TNS:could not resolve the connect identifier specified
ORA-1534	1	rollback segment '%s' doesn't exist
ORA-1537	1	cannot add file '%s' - file already part of database
ORA-1553	1	MAXEXTENTS must be no smaller than the %s extents currently allocated
ORA-1593	1	command no longer valid, see ALTER USER
ORA-19502	1	write error on file \"%s\", blockno %s (blocksize=%s)
ORA-20012	1	User-defined
ORA-24324	1	service handle not initialized
ORA-27063	1	number of bytes read/written is incorrect
ORA-7445	1	exception encountered: core dump [%s] [%s] [%s]
ORA-00312	2	online log %s thread %s: '%s'
ORA-10		2	no data found
ORA-11		2	invalid value %s for attribute %s, must be between %s and %s
ORA-16038	2	log %s sequence# %s cannot be archived
ORA-20000	2	The stored procedure 'raise_application_error'
ORA-301		2	error in adding log file '%s' - file cannot be created
ORA-959		2	tablespace '%s' does not exist
ORA-00060	3	deadlock detected while waiting for resource
ORA-07445	3	exception encountered: core dump [%s] [%s] [%s]
ORA-12012	3	error on auto execute of job %s
ORA-00600	4	internal error code, arguments: [%s], [%s], [%s]
ORA-1652	4	unable to extend temp segment by %s in tablespace %s
ORA-00917	10	missing comma
ORA-01013	12	user requested cancel of current operation
ORA-1650	12	unable to extend rollback segment %s by %s in tablespace %s
ORA-20011	21	User-defined error: Execute_system: Err
ORA-1142	33	cannot end online backup - none of the files are in backup

Final analysis? Where can I send my resume?

The Python code is simple – it loops through each line of the 49MB file (448k lines) and checks for an Oracle error using the regexp ORA-[0-9]{1,5} which I intended to mean the letters ORA, followed by a dash, followed by between one and five numbers. Please feel free to correct/improve my regex-fu. If a match is found, then add it to a dictionary as the key, and set the value to the count. If the key is already present in the dictionary, the value gets incremented. Finally, the contents of the dictionary are displayed, sorted by the value(frequency).

#!/usr/bin/python
import re
f=open('messages_all.txt')

pattern = re.compile(r'ORA-[0-9]{1,5}')
errors={}
for line in f:
	err = re.findall(pattern,line)
	if err:
		errors[err[0]] = errors.get(err[0],0)+1
f.close()

for k,v in sorted(errors.items(), key=lambda(k,v):(v,k)):
	print '%s\t%d' % (k,v)

alter session set tracefile_identifier='charging_batch';
exec dbms_monitor.session_trace_enable;

These commands named the tracefile and enabled 10046 logging.

Since I’m lazy(the good kind), I figured I’d use Python to build the commands to run TKPROF for each process. The program expects to be run from the udump directory. As I get more time I’ll enhance it to automatically grab the location of udump from the database.

The script takes an optional parameter for a tracefile identifier. If the parameter is passed, filenames containing the identifier text will be processed. Otherwise, all tracefiles are processed. A to-do item is to make sure the tracefile is an actual 10046 before running TKPROF against it.

The output format is the optional tracefile identifier_process_id.out. The file suffix can be overridden with variable tkprof_suffix. I use .out as an homage to Michael Levy, wherever he may be, who showed me how to use the tool way back in 1998.

#!/usr/local/bin/python
# tkprof.py
# kodner 2009
# and runs a simple tkprof on them
import sys
import os
import re
sort = "fchqry" #parameterize this
tkprof_suffix = 'out' #this too

# find a string to be used as a tracefile identifier
# to limit the tracefiles processed
try:
  tracefile_identifier = sys.argv[1]
  print ""
  print ""
  print "tracefile identifier supplied is: %s" % (tracefile_identifier)
  print ""
  print ""
except:
  tracefile_identifier = None

# lists the files with suffix .trc and contain out suffix .trc
traces=[x for x in os.listdir('.') if x.endswith('.trc')]

for file in traces:
  tracefile = None

  # extract the process id from the filename.
  # I'm sure this could be done better.  i split it into multiple
  # lines for readability.

  processNum = re.findall(r'ora_[0-9]+',file)
  processNum = processNum[0].split('_')[1]

  # if a tracefile_identifier is supplied then make sure our current file
  # contains the string.  we'll also make sure the output filename contains
  # the tracefile identifier.

  if tracefile_identifier:
    if file.find(tracefile_identifier) > 0:
      tracefile = file
      outputfile=tracefile_identifier + '_' + processNum + '.' + tkprof_suffix
  else:
    tracefile=file
    outputfile=processNum + '.' + tkprof_suffix

  if tracefile:
    print "processing tracefile %s ..." % (tracefile)

    # using regexp, find the process number of the file.
    # the process number will be used to name the tkprof output file

    # we will assume that the tracefile name is in the format
    # $ORACLE_SID_ora_$PROCESSNUM.trc
    # and that the tracefile name may contain a tracefile identifier
    # set by using alter session set tracefile_identifier = 'foo';

    # generate the tkprof command use flags sys=no and waits=yes
    command="tkprof %s %s sys=no waits=yes sort=%s" % (tracefile,outputfile,sort)

    # execute the command
    os.system(command)

example

CREATE PROCEDURE bill_employers(in_employer_id DEFAULT NULL)
IS
BEGIN
  FOR employer in
    SELECT  emp.employer_id
         ,  emp.account_number
         ,  emp.bill_amt
      FROM  employer emp
     WHERE  emp.employer_id = NVL(in_employer_id,emp.employer_id)
  LOOP
    --Do stuff here
  END LOOP;
END;

So the real trick is the NVL in the where clause – If I supply a value for in_employer_id that’s the only one that’ll get processed.

exec bill_employers(in_employer_id => 12345);

If I don’t pass a value at all, we’ll process the whole set because of the NVL – if in_employer_id is NULL, then the rvalue becomes the same as the lvalue.

exec bill_employers;

Furthermore, what constitutes table size? Is it the space occupied by data? What about indexes? LOBs? Oracle Text Indexes? Fortunately this schema didn’t contain any LOBs otherwise I’d have to look those sizes up.

Knowing what I do about both the manager and the project, I’m assuming that they wanted size info on these tables, to make sure we have enough room to clone them somewhere. I chose the safest route and opted to produce data + index size for him.

My goal was to write a query that would present the data in a manager-friendly way. A secondary goal(Sounds like I’ve been playing too much Command & Conquer) would be to provide him with a query so he could get this information on his own.

Here’s my first cut at the query(explanation follows the SQL):

with table_list as (select  table_name
                         ,  owner
                         ,  num_rows
                         ,  avg_row_len
                         ,  last_analyzed
            from  all_tables
           where  owner = 'SCHEMANAME'
             and  table_name in ( 'TABLE1'
                                , 'TABLE2'
                                , 'TABLE3'
...
                                , 'TABLE49'))
select  a.owner "table owner"
     ,  a.table_name "table name"
     ,  avg(ROUND(b.bytes/1024/1024,2)) "table size in mb"
     ,  avg(ROUND(b.bytes/1024/1024/1024,2)) "table size in gb"
     ,  COUNT(DISTINCT c.index_name) "number of indexes"
     ,  SUM(ROUND(d.bytes/1024/1024,2)) "index size in mb"
     ,  SUM(ROUND(d.bytes/1024/1024/1024 , 2)) "index size in gb"
     ,  ROUND((avg(b.bytes) + sum(d.bytes))/1024/1024,2) "table + indexes in mb"
     ,  ROUND((avg(b.bytes) + sum(d.bytes))/1024/1024/1024,2) "table + indexes in gb"
     ,  a.num_rows "number of rows"
     ,  a.avg_row_len "average row length"
     ,  a.last_analyzed "last analyzed"
  from  table_list a
     ,  dba_segments b
     ,  all_indexes c
     ,  dba_segments d
 where  a.table_name = b.segment_name
   and  b.segment_type = 'TABLE'
   and  a.owner = b.owner
   and  a.owner = c.owner(+)
   and  c.table_name(+) = a.table_name
   and  c.index_name = d.segment_name(+)
   and  c.owner = d.owner(+)
   and  d.segment_type(+) = 'INDEX'
GROUP BY  a.owner
       ,  a.table_name
       ,  a.num_rows
       ,  a.avg_row_len
       ,  a.last_analyzed
order by a.table_name

I chose to put the hard-coded schema name and table list in a WITH query only to keep it at the top of the statement – so that the manager, or anyone else editing this query, could easily see where the editable items are.

The results look like

So we’re off to a good start. But then I wanted to make the process even more user-friendly. That’s where the idea of putting this into a stored procedure came in to play. I created a pipelined row function which displays all of the table + index information, now with LOB support.

So instead of running the query above, it’s just a matter of executing a function call(for each table):

SQL> select * From table(table_info_pkg.table_info('CLAIMS'));

TABLE_OWNER                      TABLE_NAME
-------------------------------- --------------------------------
TOTAL_TABLE_SIZE_IN_MB TOTAL_TABLE_SIZE_IN_GB TABLE_DATA_SIZE_IN_MB
---------------------- ---------------------- ---------------------
TABLE_DATA_SIZE_IN_GB NUMBER_OF_INDEXES INDEX_SIZE_IN_MB INDEX_SIZE_IN_GB
--------------------- ----------------- ---------------- ----------------
LOB_SIZE_IN_MB LOB_SIZE_IN_GB NUMBER_OF_LOBS LOBINDEX_SIZE_IN_MB
-------------- -------------- -------------- -------------------
LOBINDEX_SIZE_IN_GB  ROW_COUNT AVERAGE_ROW_LENGTH LAST_ANAL
------------------- ---------- ------------------ ---------
CUBS_OWNER                       CLAIMS
                     0                                          108
                  .11                14               89              .09

TABLE_OWNER                      TABLE_NAME
-------------------------------- --------------------------------
TOTAL_TABLE_SIZE_IN_MB TOTAL_TABLE_SIZE_IN_GB TABLE_DATA_SIZE_IN_MB
---------------------- ---------------------- ---------------------
TABLE_DATA_SIZE_IN_GB NUMBER_OF_INDEXES INDEX_SIZE_IN_MB INDEX_SIZE_IN_GB
--------------------- ----------------- ---------------- ----------------
LOB_SIZE_IN_MB LOB_SIZE_IN_GB NUMBER_OF_LOBS LOBINDEX_SIZE_IN_MB
-------------- -------------- -------------- -------------------
LOBINDEX_SIZE_IN_GB  ROW_COUNT AVERAGE_ROW_LENGTH LAST_ANAL
------------------- ---------- ------------------ ---------
             0              0              0                   0
                  0     379029                257 01-JUN-09

The code for table_info_pkg can be found on google code and I welcome any and all feedback, complaints, or anything else you care to throw at me.