RE: ASM or not to ASM

  • From: "Storey, Robert (DCSO)" <RStorey@xxxxxxxxxxxxxxxxxx>
  • To: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>, <tim@xxxxxxxxx>
  • Date: Mon, 11 Jul 2011 12:45:05 -0500

2nd error number too in my posting.
 
Smallish database.  less than 100gigs total.  30 tablespaces max, about 340 
tables.
 
no RAC in my future that I can see.

________________________________

From: alanbort@xxxxxxxxx on behalf of Guillermo Alan Bort
Sent: Mon 7/11/2011 12:37 PM
To: tim@xxxxxxxxx
Cc: Storey, Robert (DCSO); Oracle L
Subject: Re: ASM or not to ASM


well, I tend to agree with Tim... for me it simplifies administration a lot. 
there are some servers where we have /u01 through /u20 and tablespaces with 
dozens of datafiles, the databases we have on ASM have bigfile tablespaces, 
which essentially makes tablespace management easy. Plus, with autoextend you 
only need to worry about proper capacity planning. Furthermore, ASM requires 
very little "tuning" to work well and it's very easy to scale. It's also fairly 
simple to convert a database on ASM to RAC, should you ever want to do so.

On the other hand, it is true that ASM introduces another layer of possible 
bugs, but it's very unlikely you will hit a bug that is unresolved, and if you 
do Oracle will come up with a patch pretty soon, it's one of their flagship 
products (or at least part of).

hth
Alan.-



On Mon, Jul 11, 2011 at 1:55 PM, Tim Gorman <tim@xxxxxxxxx> wrote:


        Robert,
        
        My $0.02...
        
        The main thing that is happening is that stuff which used to "belong" 
in the realm of "root" and the Sys Admins are being moved under the realm of 
DBA.  So, there is a huge political aspect to the adoption of ASM that often 
overshadows the technical aspect, and this political "shift of power" from Sys 
Admin to DBA can be more of an obstruction than any other aspect of ASM 
adoption.  Not sure what things are like in your shop, but that is not a 
trivial concern.
        
        It would be inaccurate to consider ASM to be "extra overhead".  Along 
with that shift of "power" from SysAdmin to DBA comes the shift in 
responsibility from "root" to "oracle" accounts.  If you are dealing with LUNs, 
volume managers, and file-systems, then from a techical perspective using ASM 
is the exact equivalent.  You still have LUNs, but instead of a volume manager 
and a file-system you have ASM.  Very very similar, but running under "oracle" 
instead of "root".  So you can see that the big shift is human perception and 
responsibilities amongst the humans -- the machine is still doing the same 
things.
        
        ASM is simpler to configure optimally for Oracle than all of the 
flavors of file-system out there.  Maybe you're already comfortable with that, 
maybe not?  Some folks constantly like to fiddle with FS block-size, with 
direct-I/O, wish they could use asynch-I/O, etc.  With ASM, its part of 
enchilada from the start.
        
        Maybe you're using VxFS or some other file-system with licensing 
issues; this is one area that Oracle actually saves you a few bucks.
        
        Looking downstream, there are advantages with platform 
migration/rehosting that come with ASM; not sure if that's slamming down the 
turnpike toward you.
        
        Another big selling point with me personally is the ease by which 
database files can be moved safely and without downtime from one SAN to another 
using ASM; much easier than most other storage options.  Run ALTER DISKGROUP 
... ADD DISK ..., ALTER DISKGROUP ... DROP DISK ..., then ALTER DISKGROUP ... 
REBALANCE, and done.
        
        It's tough to answer with detail without knowing present configuration, 
but that's my seat-of-the-pants reaction to your question.  If what you've got 
has worked well so far, then stick with it, but if you reflect on things and 
realize that you're trying to make the square peg of Oracle fit into the round 
hole of file-systems, then ASM can make life easier and remove one more 
variable to worry about from the whole performance optimization environment.
        
        Hope this helps!
        
        Thanks!
        
        -Tim
        
        
        
        

                -----Original Message-----
                From: Storey, Robert (DCSO) [mailto:RStorey@xxxxxxxxxxxxxxxxxx]
                Sent: Monday, July 11, 2011 10:30 AM
                To: 'Oracle L'
                Subject: ASM or not to ASM
                
                Going through a 11gR2 new features class. First half day is all 
about ASM and installing grid infrastructure for a standalone structure, My 
question is why would I, on my single server with a single instance, using a 
SAN for my storage, bother with ASM? Why do all of this overhead just for a 
single instance? -- //www.freelists.org/webpage/oracle-l 


--
//www.freelists.org/webpage/oracle-l


Other related posts: