If you are experimenting with gathering system statistics it might be helpful to archive your current settings and any intermediate settings you come up with along the way.

There is a way to save stats to a table using DBMS_STATS.CREATE_STAT_TABLE and gathering with DBMS_STATS.GATHER into that table, but the format is cryptic and it is nice to have the descriptive parameter names tagging along with the data. (In a future post I will cover format of the CREATE_STAT_TABLE format).

#!/usr/bin/bash
#---------------------------------------------------------------------------
# Written by : David Mann @ http://ba6.us
# Script Name : alldatafiles.sh
# Description : Provides list of all datafiles for each running database on
# on a machine
#---------------------------------------------------------------------------

ORATAB=/etc/oratab
echo "INSTANCE_NAME, FILE_NAME"

# Step through running instances
ps -ef | grep ora_smon_ | grep -v grep | cut -b61-70 | while read LINE
do
# Assign the ORACLE_SID
ORACLE_SID=$LINE

If you ever used the Solaris ps -ef command to view programs that are running you may not always see the arguments the original program was started with. This command usually shows about 80 characters.

Try the following commands, they usually give you more information about the command that started the process running. Depending on the patch level of your OS you may see 200 characters or more.

/usr/ucb/ps
/usr/ucb/ps -auxwww

-Dave

I ran across Orion in a Kevin Closson blog post. From the OTN site:

"ORION (Oracle I/O Calibration Tool) is a standalone tool for calibrating the I/O performance for storage systems that are intended to be used for Oracle databases. The calibration results are useful for understanding the performance capabilities of a storage system, either to uncover issues that would impact the performance of an Oracle database or to size a new database installation. Since ORION is a standalone tool, the user is not required to create and run an Oracle database. "

As I get deeper into tuning with Statistics and the CBO I have been paying a lot more attention to hints.

In the past I always tried to avoid hints. After working with the CBO and staistics in recent versions I believe they are necessary at times to give guidance to the CBO.

The Oracle Database SQL Language Reference has a comprehensive list of hints included in the documentation of SQL Comments. The list for 11g is available here: link.

I have been making use of the GATHER_PLAN_STATISTICS hint more and more lately. In the interest of getting the most accurate data I usually log in as the user that normally executes the query. These are usually non-privileged accounts that just have access to their own objects.

In order to use DBMS_XPLAN.DISPLAY_CURSOR in a session that does not have DBA or SELECT CATALOG ROLE, grant the following permissions to them:

SQL> GRANT SELECT ON V_$SESSION TO &&MYUSER;
SQL> GRANT SELECT ON V_$SQL TO &&MYUSER;

For the past few weeks I have been using the TriVaDis eXtended Tracefile Analysis Tool as a replacement for TKPROF.

TKPROF is available with all Oracle installations but is has some drawbacks. Early versions of TKPROF do not provide any information about bind variables. It also tends to lose detail because it aggregates data. When performing analysis it is unwise to make inferences about detailed execution based on aggregates. TVD$XTAT provides aggregates but also provides detail on each SQL Statement so you can zero in on the statement of interest.

I was recently looking for old (not ancient, just old) install media to support a database migration. The usual collection of download links on OTN usually just has the last 2 releases. If you need older versions (in this case 9i) then hit up the EDelivery site and you should be able to find them.

http://edelivery.oracle.com/

If you need a much older version (like 8i or gasp! 7) I have heard you may be able to obtain it through an SR if you have a current support contract but luckily I have not had to test that route.

On Oracle-L there was a recent discussion about detecting block corruption.

One suggestion was to do an Export to /dev/null. While this may get you 95% of the way there it is mainly relying on side effects of data access to detect any issues. If blocks are cached then it might not root out physical corruption.

Iggy Fernandez covers the topic of who is better suited to tune SQL - Developers or DBAs. Also listed are 5 Dangerous Beliefs which may influence the answer to that question.

https://iggyfernandez.wordpress.com/2009/07/12/who-should-tune-sql-the-dba-or-the-developer/

-Dave