Date: Mon, 20 Oct 2008 14:39:47 -0500
I understand what you are saying. Most DBA's today are doing the work we used to have 3-4 DBA's doing in the early 90's. Sometimes it seems impossible to investigate new technology even if we're convinced it would make our lives easier. Unfortunately in our industry if we don't keep up we'll get left behind. I like the example Riyaj gave when he said it reminded him of the "old threads discussing rman vs user managed backups".
Your Linux environment would in deed be a good place to take it for a test drive because as long as you have at least one extra disk on the system you can partition it to simulate multiple drives.
Here are a few of things to consider.
- Setting up a non-clustered ASM environment shouldn't take more than a couple of hours to install once you've done a little homework to understand what's involved. Once you have it installed & configured with a few disks it is a simple thing to use DBCA to create a scratch database inside it.
- Once you get comfortable with ASM and are ready to migrate your
"real" databases to it keep in mind that you can do this a file at a time
over the course of weeks if you want. There is nothing wrong with running in mixed mode for as long as you need to. This really takes the preasure off to
"get it all done in one shot" and eases the transition. By the way it is
also an excellent way to do a little benchmarking of your own.
- Sometimes all a person needs is an example to follow. A lab rat to poke with a stick as it were. I know this is going to sound like a shameless plug but it really isn't. This is where a consultant can really help you out. Most ASM implementations I do are cases where I do the first one then walk the client through doing one for themself. After that he/she can carry the ball from there.
I think you may find the transition to ASM storage easier than you thought it would be.
From: Jared Still [mailto:jkstill_at_gmail.com]
Sent: Monday, October 20, 2008 1:07 PM
Subject: Re: ASM
Thanks Randy, you've made some great arguments for using ASM.
I have just one more argument against using ASM that I haven't yet mentioned.
Time. I simply don't have time to do it, and haven't had for some, well, time.
As a consultant you go in and focus on the task of installing db's, at least
the cases you mentioned. The day to day production and development DBA work is done by someone else.
In my case, I am the only DBA in a company with 8 instances of SAP, 3
or Oracle eBiz apps, 3 instances of Agile, some ClearQuest DB's, and a number of
other databases for custom and smaller apps.
This includes monitoring, backup, recovery, making sure the backups are
fixing them when they don't, etc.
Plus the 3 new instances of SAP that are being installed, trying to fix SSO
in eBiz, and moving several databases to a new linux box.
The new linux box would be a great opportunity to use ASM, but I would first
use it on a dev box or two to become comfortable with it. And the deadline for the
new server doesn't allow that.
Sorry to be so long winded, but the point is that new technology is
used for reasons that have nothing to do with technology.
I'm fairly convinced at this point that I should give ASM another chance,
time is limited.
Certifiable Oracle DBA and Part Time Perl Evangelist
On Mon, Oct 20, 2008 at 7:14 AM, Randy Johnson <oraclelist_at_sbcglobal.net> wrote:
I tried not to be too long winded with this post but as you can see I didn't quite pull it off. So for those of you who are patient enough here is my input on the topic.Received on Mon Oct 20 2008 - 14:39:47 CDT