Why I don't like ASM

From: Dave Morgan <oracle_at_1001111.com>
Date: Thu, 23 Jan 2014 20:13:48 -0700
Message-ID: <52E1DA6C.5080205_at_1001111.com>

Because it adds complexities and dependencies.

Don't get me wrong, when I was a junior the primary job of the intermediates was to manage 200 x 2GB, 15K rpm JBOD. Redo and archive logs had to be on separate "everything". Hot spots due to file access and file sizes were huge limitations.

And where was ASM .................. in the future

Now, a basic install is 3 mount points of 500GB, on 3 different arrays.
- 1 for data (preferably SSD)

• 2 for redo, archive, backups and work space The 2 biggest physical limitations, file size and hot spots disappear.

So, why is it common for me to come across database installs using ASM in the above scenario? What is the benefit from using ASM in the above scenario?

What I'm really looking for is appropriate use cases for ASM.

One of them, I believe, having done both, is: ASM is easier than managing raw disk, therefore RAC installs should use ASM.

Is the above true? What about ASM vs Veritas? Other shared disk managers?

Opinions are welcome, opinions backed by data and scripts are valued :)

Dave

-- 
Dave Morgan
Senior Consultant, 1001111 Alberta Limited
dave.morgan_at_1001111.com
403 399 2442
--
http://www.freelists.org/webpage/oracle-l

Received on Fri Jan 24 2014 - 04:13:48 CET