So basically you raise 3 excellent points
1. ZFS can handle updates/deletes
2. oracle shouldn't be creating volume managers - ASM is slow
3. Our organization isn't structured so DBA should be messing with disks
1. Yes zfs will handle updates and deletes very quickly but start with a say
100G database on ZFS, time a full table scan, update/delete 10% of the data and
do another full table scan the time will be much worse. - So from an oracle
perspective ZFS makes updates/deletes fast but full table scans are slow - this
is bad :(
2. ASM is a tool that runs on most OS oracle supports so to get the best
performance out of it you must do some tuning which is OS & storage dependent.
ASM is basically a "free" (once you've paid for your oracle licence)
clusterable extent based filesystem. So while you could say there are other
clusterable / extent based filesystems (veritas & SAMFS) neither are free.
3. when it comes to solving business problems I find that often the company
policy of who can do what in many IT organizations is a big contributor to the
problem, I think with the move towards Xen etc will only make this problem
worse - I have no solution to this.
Rgds
Robin
snip
> For my understanding, the ZIL should be able to
> handle the
> update/delete part. Are there any simulated real
> world tests? I would
> really like to deploy ZFS in a couple of month for
> Oracle Databases.
>
> I haven't had the time to do any DB on ZFS testing,
> but I don't like
> SM. IMHO, Oracle should do things in their domain
> (database stuff) and
> keep their fingers out of functionality that is the
> domain of Unix
> (namely storage). Maybe there are some environments
> where ASM is ok
> (small machines, development machines etc.), but I
> don't see any use for
> it in bigger in environments, where we have a
> segregation of duty.
>
> If Oracle wants to play with Unix, they can start
> converting their
> services to Solaris' SMF :-)
>
> Mika
snip
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
