Skip navigation.

Cheap DBA

Syndicate content
Updated: 8 years 1 week ago

Another change to and

Sun, 2008-05-18 12:01

Sorry for the inconvenience but I have made a drastic move to merge the individual websites I maintain into one. Over the next couple of weeks, hopefully sooner, Everything, websites & blogs will be merged into a single website: This will enable me to communicate via a single website and hopefully make it easier on you and myself. You will quickly notice that I have taken a huge leap of faith and am using a blogging interface for this. So come stop by, take a look around, and let me know what you think. Just remember I am just now begging the transition so be a bit patience. But I DO want your comments.

Please change bookmarks, RSS, etc. as,, and will be going away soon.

James has moved

Fri, 2008-05-16 19:37

Please visit my personal blog at

Measuring Disk I/O—Oracle’s ORION Tool

Thu, 2008-05-15 21:16

©Mr. Physics
Orion NebulaTo increase your ability to model the physical aspects of an Oracle database it is advantageous for the designer to test a disk configuration before they actually install an Oracle database on top of it. For this reason I suggest you take a look at Oracle’s ORION tool to help benchmark your storage architecture. The proper benchmarking can be the difference between the same hardware having poor or excellent performance. Through the use of Oracle’s ORION workload tool Database Architects can effectively develop a workload that can mimic and stress a storage array in the same manner as the planned application with an Oracle backend database. Because the ORION tool does not require a running Oracle database, multiple configurations can be tested such that an optimal storage configuration can be obtained while providing for reliability, stability, and scalability.

Take a look at this introductory article Measuring Disk I/O - Oracle’s ORION Tool

Measuring Disk I/O - A Vendor View

Thu, 2008-05-08 09:24

How do you know if the disks you will be using from ANY particular vendor can muster up the IOPS and MBPS required to satisfy your current or future workloads?

In the article, Measuring Disk I/O, we took a quick look at the amount of IOPS and MBPS, or workload, that our Oracle database is generating. These numbers are very important when we start to look at our system for available throughput, especially out to the disk subsystem. Why are these numbers important? As a very simple example, and no real meaning, suppose you, after running the scripts from that article, find out that your database is requesting, and getting, 100,000 IOPS. Well, if your disk subsystem has 1,000 disks and if every disk is participating in satisfying 100,000 IOPS, you could sort of say that each disk is performing about 100 IOPS. You then have to ask yourself the following questions:

Is this good on a per disk basis?
Do I have room to grow if my throughput were to double or triple?
How much breathing room do I really have?

So let’s take a quick dive into these from a truly vendor perspective in the article : Measuring Disk I/O - A Vendor View

Measuring Disk I/O

Wed, 2008-05-07 16:56

Do you know how your disk subsystem actually is performing?

I have just posted an article on that will take a look at extracting some I/O statistics so that you can monitor and determine just how well your disks are doing within Oracle.

How can I separate Oracle I/O to maximize performance?
Should I separate data files from index files?
Should I separate redo logs”

These question(s), AND many more, seem to flood our minds as database administrators. They are easy to answer with generalities but in practice can be very difficult to come to a conclusion on unless we take a look at how our disk subsystem is actually performing.

Take a look at this article for some guidance : Measuring Disk I/O

Cheep-man’s archive log mover for Oracle

Wed, 2008-04-23 18:55

Now, before I get too many comments on why this won’t work, let me just say that this really is a cheap-man’s archive log mover. AND it does assume that you know your archive log process very well and the number of logs defined within your database. Setting the KEEPLOGS parameter inside this script is VERY CRITICAL. Setting this variable to a number higher than the number of redo logs in your database ensures it will never move a log file that is still being written to. This script will move archive logs from one directory to another. It does this based on reverse order of archive log creation and then, depending on how many logs to keep, will skip the first number of logs defined by KEEPLOGS and then move the rest.

TITLE move_archive_lgos.bat

REM move_archive_lgos.bat
REM =====================
REM This script will move archive logs from one directory to another.
REM It does this based on reverse order of archive log creation and
REM   then, depending on how many logs to keep, will skip the first
REM   number of logs defined by KEEPLOGS and then move the rest.
REM It is advisable to set KEEPLOGS greater than the number of logs
REM   defined and alowing for time for them to write out to disk.


SET c=1

DIR %FROMDIR% /O-D /B > begdir.lst
FOR /F %%I IN (begdir.lst) DO call :MOVELOGFILE %%I
DIR %FROMDIR% /O-D /B > enddir.lst
goto :EOF

goto :EOF
SET /a c=%c%+1
goto :EOF

Oracle - looking at snapshot ranges

Sat, 2008-04-19 06:27

A lot of the AWR reports ask for, before spitting out their report, the number of days back you would like to go before entering your beginning and ending snapshot IDs. When they report on all the snapshot IDs they have left out, I think, one very important piece of information that just might cloud our judgment when selecting the proper snapshot range. This would be whether, during the snapshot period, there has been a bounce of the database–reseting the statistics to zero.

This script I have here is very similar to the ones in the AWR reports ($ORACLE_HOME/rdbms/admin/awr*) but also shows when the database has been bounced during a snapshot. We can do this by the following SQL which joins the DBA_HIST_DATABASE_INSTANCE and DBA_HIST_SNAPSHOT views—showing historical information on the snapshots in the Workload Repository. We obviously need to join these tables on the dbid, instance_number, and, the important part, startup_time. We also make sure that we only bring back snapshots that are newer than the number of days back specified by the user by comparing the time of the actual snapshot (end_interval_time). Please note that this script will output a status of ‘**db restart**’ for those times that the database was down and unavailable. This is very important as it shows us those times that Oracle was not collecting statistics (the database was down) and more importantly the statistic counters were zeroed. We can report on a bounce condition if the startup_time and begin_interval_time are the same.

prompt Enter the number of days to look for snapshot IDs
prompt ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
select dhdi.instance_name,
       to_char(dhs.begin_interval_time,'MM/DD/YYYY:HH24:MI') begin_snap_time,
       to_char(dhs.end_interval_time,'MM/DD/YYYY:HH24:MI')   end_snap_time,
       decode(dhs.startup_time,dhs.begin_interval_time,'**db restart**',null) db_bounce
  from dba_hist_snapshot dhs,
       dba_hist_database_instance dhdi
 where dhdi.dbid             = dhs.dbid
   and dhdi.instance_number  = dhs.instance_number
   and dhdi.startup_time     = dhs.startup_time
   and dhs.end_interval_time >= to_date(sysdate - &&num_days_back)
 order by db_name, instance_name, snap_id;

Install Oracle11g on Linux CentOS-5

Fri, 2008-04-11 16:49

Glad to be back. It HAS been awhile and hopefully you forgive thecheapdba for staying away.
BUT this post, I am sure you will like. It is an installation guide for Oracle 11g on Linux CentOS-5.
As the installation is quite lengthy I will just provide you with a link to the main, new and “improved” website location.

So just visit to take a look at it!

Cheers, and it won’t be this long in between posts again.