I've been following a number of threads on forums.oracle.com recently - the quality of discussion seems to have improved markedly there since I gave up on it in 2001. Anyway there was a thread about interpreting the AWR report that Oracle provides (at extra cost) and which is very smilar to the Statspack report. The report in question comes from a siebel system and there were some interesting snippets of information from Joe Coffey about the specifics of working with SIEBEL which would likely trap the unwary (like me) when using sqlplus to investigate an application performance problem. The specifics are in this post but are that siebel specifically alters the standard oracle environment on login with 4 ALTER SESSION statements - namely

• alter session set optimizer_mode = first_rows_10;
• alter session set hash_join_enabled = false;
• alter session set "_optimizer_sortmerge_join_enabled" = false;=
• alter session set "_optimizer_join_sel_sanity_check" = true;

Now first_rows_10 is rather sensible for a reporting application where the end user is going to look at pages of results - I'm rather less convinced about the wisdom of avoiding hash_joins and sortmerge joins altogether, but the base point to remember here - for myself as much as any reader - is that when conducting tests using sqlplus (or toad or any other query environment ) it matters that you ensure that your session mimics effectively the one the users will be using.  

I'm just starting an installation of Oracle APEX 3.1.1 into one of our development ebs instances for 2 reasons.

1. To provide a small applet to a project team
2. To provide the infrastructure for the dbas to write their own little applets.

I chose this method for the following reasons (unordered)

• it's fairly cool
• we know pl/sql much better than java
• we don't much like forms.
• you can integrate really easily.
• deployment is pretty simple.

Those of you that have installed apex frequently will know it's a pretty quick install on decent hardware. So the following came as rather a surprise.

timing for: English Dictionary
Elapsed: 00:03:16.71
-- Updating user account expiration. -------
timing for: Upgrade
Elapsed: 00:00:00.43
...End of install if runtime install
...create null.sql
timing for: Development Installation
Elapsed: 01:03:48.57

That's right over an hour. The reason for this is that with 3.1.1 APEX calls DBMS_STATS.GATHER_DICTIONARY_STATS('APEX'); this spend almost 55 minutes performing inappropriate index lookups on the data dictionary for us. This might be solvable, though to be honest it's probably not worth it, but just a heads-up really, the APEX install may take longer than you think in a large environment and with the latest version of the software.