Submitted by dave on Wed, 09/05/2007 - 15:51
I know using Perl backticks call I can execute an OS command and easily get the output.
I know using Perl system() call I can execute an OS command and easily get the return value.
Today I found out a way to get both.
Submitted by dave on Sat, 07/28/2007 - 13:22
A friend of mine just turned me on to Pentaho.
From the site:
Submitted by dave on Fri, 07/20/2007 - 16:01
So I took my first hands-on class from Oracle this month.
I'm usually of the 'sit down with a book and computer' camp when I need to learn something new, but where I work we needed RMAN proficiency quickly. I thought it might be better to get out of the office for a few days and buckle down on the topic.
Submitted by dave on Mon, 06/25/2007 - 15:57
Statspack Reports can be useful for diagnosing performance problems, but they are only useful if they are generated and available!
Submitted by dave on Wed, 05/23/2007 - 13:33
I found an interesting article by Scott W. Ambler on Doctor Dobbs Journal today called "Questioning Traditional Data Management".
Scott points out 6 assumptions data management professionals often make and points out why he believes they are not valid assumptions. Assumptions like: It's expensive to evolve a database schema and Review and inspections are an effective way to ensure quality.
At this point in my career I have worked as a DBA about as long as I was a Software Developer so I can see both sides of this issue.
Submitted by dave on Thu, 04/19/2007 - 18:42
So my last post was about administration on Linux. After running Oracle on Windows for way too many years we migrated our Oracle systems to 64-bit Linux over the past year.
Now that we're on Linux I needed a lightweight way to capture and graph some performance data. The performance data was a mix of OS utilities and 3rd party utilities, but all the utilities output text, so I knew I could screen scrape the output, massage it a little, and save the data to a file. After I had the data in a file I knew I could run it through GnuPlot to graph it.
Submitted by dave on Thu, 04/19/2007 - 14:29
…is not as hard as it is on Windows. I went searching for articles on the topic and couldn't really find any. Now I know why.
In Windows land to move binaries for an instance from one machine to another you have to worry about oradim/registry dependencies. Because of all of this I usually just install Oracle binaries off of the original disks and patch to appropriate level and the move the Database (data files, control files, etc) and recreate the database on the new machine.
Assuming the source and target are the same architecture on Linux I had to:
Submitted by dave on Thu, 04/19/2007 - 06:42
There may come a time when you need to return an error code from SQLPlus, either to a calling batch file, shell script, or Perl script.
SQLPlus has a WHENEVER directive available for handling errors it encounters. This command controls the behavior of SQLPlus when an OS or SQL error occurs. There are many options for this behavior.
More after the jump…
SQL errors include errors thrown by a single command entered into SQLPlus or an error raised by a PL/SQL block:
Submitted by dave on Tue, 04/10/2007 - 19:08
Did you know you can make your own Long Running Operation that is available to the V$SESSION_LONGOPS system view?
At the bottom of the Oracle documentation for DBMS_APPLICATION_INFO is some example code: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_appinf.htm#i999254
In a previous post I posted Perl source code for a script that monitors V$SESSION_LONGOPS and reports progress of all current long operations: TODO
Submitted by dave on Tue, 04/10/2007 - 19:03
I've recently been working on improving the Database Change procedures and Deployment procedures where I work. We like to turn around releases every 2-4 weeks or so but sometimes the friction of keeping a sane and organized development process slows us down. At this point I would rather be slow than to introduce errors to our production environments but I am always looking for ways to improve accuracy and speed of our processes.