Re: Storage array advice anyone?
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "Oracle-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 17 Dec 2004 15:26:13 -0000
Notes in-line
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated Sept 19th
----- Original Message -----
From: "Matthew Zito" <mzito@xxxxxxxxxxx>
To: <jonathan@xxxxxxxxxxxxxxxxxx>
Cc: "Oracle-L" <oracle-l@xxxxxxxxxxxxx>
Sent: Friday, December 17, 2004 2:04 PM
Subject: Re: Storage array advice anyone?
:
: When I'm talking about virtualization, I am talking about using large
: numbers of spindles to satisfy I/O, and in better examples, software on
: the array to rebalance I/O.
In that case, your argument should FIRST be:
"You need a lot of spindles per application."
The fact that you might have some cutesy bit of software that
makes it easier to handle a lot of spindles is a minor detail.
:
: We can look at the other case - I could have a bunch of RAID-10 volumes
: and any given read could span two drives. When I then have 64 I/Os
: that are pending against that lone RAID-10 volume, wouldn't I be better
: off having those I/Os against 50 disks instead of 14?
:
You might be ... but another way of looking at it is that if you're going
to do a bad database design and write appalling code (that's a rhetorical
"you", not a personal "you") then I'd rather you wrecked the I/O performance
on your set of 14 discs than wreck my performance by hammering
my set of 14 disks as well.
: And as far as sharing disks, even EMC's RAID-1 implementation splits a
: disk into a set of volumes and mirrors them to another drive. There's
: always the possibility of spindle contention with any RAID group,
: including a RAID-10 volume.
Which is just one example of why virtualization can be seen
as is a con-trick. The vendor "virtualizes" a small number of spindles
into a large number of hypervolumes, then tells you that
your LUN is striped across lots of hypervolumes - but
forgets to mention that your LUN is striped, checkered,
zig-zagged and self-contending on a small set of spindles.
Then when you ask for the management tools to investigate
your performance problem, they either don't exist, or cost
a small fortune - "but you don't need to know because it's
virtualized and striped and there can't be a problem."
: How well an array copes with
that is a
: factor of workload, cache, and the elegance/functionality of the array
: OS. Like everything else in the world, quality makes a difference.
: That's why I suggested that you vet your vendors heavily.
I thought that was a practice that died out in the late 18th century
:
: Thanks,
: Matt
:
: --
: Matthew Zito
: GridApp Systems
: Email: mzito@xxxxxxxxxxx
: Cell: 646-220-3551
: Phone: 212-358-8211 x 359
: http://www.gridapp.com
:
:
:
--
//www.freelists.org/webpage/oracle-l
Other related posts:
