My problem is when you have 100+ luns divided between OS and DB, keeping track of what's for what can become problematic. It becomes even worse when you start adding luns -- the chance of accidentally grabbing a DB lun instead of one of the new ones is non-trivial (then there's also the chance that your storage guy might make a mistake and give you luns already mapped elsewhere on accident -- which I have seen happen before). And when you're forced to do it at 3am after already working 12 hours that day.... well safeguards are a good thing.
On Sat, Feb 13, 2010 at 2:13 PM, Allen Eastwood <mi...@paconet.us> wrote: > >> There is of course the caveat of using raw devices with databases (it >> becomes harder to track usage, especially as the number of LUNs >> increases, slightly less visibility into their usage statistics at the >> OS level ). However perhaps now someone can implement the CR I filed >> a long time ago to add ASM support to libfstyp.so that would allow >> zfs, mkfs, format, etc. to identify ASM volumes =) > > While that would be nice, I would submit that if using ASM, usage becomes > solely a DBA problem. From the OS level, as a system admin, I don't really > care…I refer any questions back to the DBA. They should have tools to deal > with all that. > > OTOH, with more things stacked on more servers (zones, etc.) I might care if > there's a chance of whatever Oracle is doing affecting performance elsewhere. > > Thoughts? > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
