Here are some thoughts I'm throwing together (I haven't caught up on email so some of these might be repetitious): 1. Oracle is dropping support for RAW devices (except for ASM) Doc ID 357492.1 Doc ID 754305.1 *http://docs.oracle.com/cd/E16655_01/server.121/e17642/deprecated.htm#UPGRD60120 <http://docs.oracle.com/cd/E16655_01/server.121/e17642/deprecated.htm#UPGRD60120>* 2. ASM for a single instance is additional overhead and complexity *however* migrations to new servers are easier I think. ASM gives you some flexibility there. 3. ASM gives you the ability to do plaid striping - perhaps can be done without the ASM layer not sure (again, typing this from memory) Chris On Thu, Jan 23, 2014 at 9:13 PM, Dave Morgan <oracle@xxxxxxxxxxx> wrote: > 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@xxxxxxxxxxx > 403 399 2442 > -- > //www.freelists.org/webpage/oracle-l > > >