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).