For the last few years, I've largely been laying out Oracle storage on
SAN's, rather than on DASD, so I'm feeling a bit out of practise with
today's drives and drive arrays.

To make a long story short, I've got a new Oracle server in a remote
data center that I didn't order or configure; it comes like it comes.

Its a 32G 8 core intel box with 8 300G 15k SAS drives in it and a
decent raid controller. Database in question is somewhere between a
data warehouse and OLTP e.g. its read heavy, but there's still a very
significant amount of write activity.

I've got a colleague who, wants to build out the box something like:

Disk0 .. RedoA
Disk1 .. RedoB
Disks 2..3 RAID 1 OS and Index tablespace
Disks 4..7 Raid 10 Data tablespace

My instinct is that buildout "wastes" too many spindles and ends up
starving the index and data volumes.

The counterproposal is to just make one big raid group like:

Disk 0..7 Raid 10

What are folks doing these days with these bold 'old 300G disks? It
seems supremely wasteful to use an entire 300G drive hold 20G worth of
red.

Any recommendations, advice, etc would be appreciated.

On Nov 25, 6:18*am, Pat <pat.ca... (AT) service-now (DOT) com> wrote:
You might want to take a look at ORION here:
http://www.oracle.com/technology/sof...ion/index.html, and
setup a few experiments with different disk layouts and workloads to
have an idea of what to expect in different configurations and what
would work best for your particular implementation.

In theory, dedicating a couple of spindles (or better yet, SSDs)
purely for redo mirrors would minimize redo log sync waits, which
could be beneficial for OLTP, but with today's high-performance RAID
controllers with large built-in battery-backed write caches this is
probably an overkill and does not worth the disk space wasted unless
you really need top performance (in which case you'd probably look
towards Exadata v2 anyway.) Though you could procure a couple of
smaller disks for this (in 80-100GB range,) their price difference is
really negligible and you will still waste most of their capacity.

And then there's ASM, which you can use to build a single disk group
with external redundancy on top of your RAID10 volume and store
everything there (and let Oracle handle different file types
automagically.) ORION will help you test this approach as well as
native ASM striping (that is, no hardware RAID, treat the array as
JBOD and do redundancy and load balancing in Oracle software.)

And results of your experiments might constitute for a nice blog
entry.

Regards,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com

On Nov 24, 7:18*pm, Pat <pat.ca... (AT) service-now (DOT) com> wrote:
The essential problem is the difference in write characteristics for
redo. Spreading everything among spindles is good, but the limiting
characteristic will be whether the controller buffering will be
saturated. If it saturates, performance will go downhill at
unpredictable times, and fast. The redo is critical. "A decent
controller," does that mean one path?

It is difficult to come up with a showing that separating out indices
and data is good for performance. Some people thought that in the
past, but it is simply an artifact of splitting I/O among drives. A
much better split may come from seeing which tablespaces use the most
I/O. For my OLTP type systems (aside from redo), I see most I/O going
towards (drum roll, please)... undo. YMMV. The important point is to
test the configurations with your load.

Will someone please tell the manufacturers that size of disk is less
important than number of spindles for us db types?

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2...reak-brussels/

On Nov 25, 2:18*pm, Pat <pat.ca... (AT) service-now (DOT) com> wrote:

Would you believe RAID 5? For most *sequential* workloads, it works
perfectly and is as good as RAID1+0, besides being much more efficient
in disk usage. Contrary to what most folks believe. But you'll need
an odd number of disks so in your case 7 is the magic number. Leaves
you a spare drive for the odd bits.
I hope that controller has multiple paths? Otherwise you're in
serious I/O performance trouble...
So, what is "sequential" in an Oracle db server?
Redo, SYSTEM, OS, software itself, archived redos, FRA.
And unless you are trying to run the latest 10000000000 concurrent
user OLTP benchmark-winning system in such a hardware configuration,
I'd say your data and index areas will likely be mostly sequential I/
O.
Temp and Undo might not but then again it's highly contingent on the
workload. If you have big serial updates the Undo will be mostly
sequential in nature.
Temp is a different animal, it can be all kinds. But then again, you
can't keep everyone happy!

Note that by "sequential" I don't mean ordered! A FTS for example is
an example of sequential. So is an index FFS, an unqualified update, a
long batch insert, etcetc.
What is random? Lots and lots of queries and updates to a single row
or a very small number of rows, in many tables.

You got them. Pity you're not in Sydney, we're talking about precisely
this at the Sydney Oracle Meetup this Friday evening:
http://dbasrus.blogspot.com , bottom half.

On Nov 24, 10:18*pm, Pat <pat.ca... (AT) service-now (DOT) com> wrote:

snip

You are kind of limited from the get go with 8 disks.

Is the application "commit happy"? Lots of single row updates
followed by commits? In that case you might really want 2 dedicated
disks RAID 1 for online logs to reduce the impact of log file sync.

Where is the operating system and swap space going to go?

Are you going to use hot spares or if not how are you going to monitor
when ( not if ) a disk fails?

Your idea of using all 8 disks in a RAID 10 is probably the way I
might lean unless you are aware that the app is real commit happy.

"Pat" <pat.casey (AT) service-now (DOT) com> wrote

I would take 2 disks and put them in RAID-1 for the online redo logs
(although 300 GB is a lot of space for these alone) and make a RAID-10 array
out of the other ones for the rest. I would definitely not use separate
disks for indices and data.

Matthias

Thanks for the feedback guys, that's exactly what I was looking for.

Oracle 10.2.0.4, OS is Red-Hat ES 5 (64 bit). Controller does support
multiple paths, and we'll be running the database with asynchronous IO
enabled (although I'm not thinking that'll impact disk layout, but
I've been wrong before).

A couple of comments (in no particular order) based on some questions
folks asked:

1) Somebody mentioned aligning the multiblock read count with the raid
stripe size ... we've gotten in the habit with 10.2 of unsetting
db_file_multiblock_read_count and just letting Oracle set it based on
how it observers the IO subsystem behaving. So far, that's seemed to
worked out pretty well for us, since my experience is not everybody
gets it right if they have to hand tune it.

2) App isn't all that commit happy. It generates a fair amount of
redo, but it tends to commit reasoanbly large transactions at once so
the number of commits doesn't usually saturate the IO subsystem, at
least it doesn't on my netapp installations and they have much larger
transaction volume than I'm expecting to see here.

3) RAID 5 ... with todays' controllers is that getting used more
often? It was drilled into my head years ago that you don't put OLTP
data on RAID 5, but then it was drilled into my head that you never
mount your tablespace over NFS too and that changed

In any event it sounds like now that pretty much everyone's agreed
that splitting "index" from "data" on a config like this is probably
counterproductive. The main open questions are just how to lay out
redo on whether or not RAID5 is an option.

On Nov 27, 7:45*am, Pat <pat.ca... (AT) service-now (DOT) com> wrote:

I'm a BAARFer by nature, but I have to admit, as long as it isn't in
degraded mode and nobody does anything stupid like yanking out two
drives and you aren't near saturating volumes of data movement, it
actually works pretty well on at least the specific configuration we
have, which is quite different than yours. Just get management to at
least agree to go away from it if some actual evidence of severe
performance degradation occurs. I see it during mass app upgrades,
which do things like add columns to every row in the largest tables,
but that just is a matter of waiting until things are done.
Performance issues during normal ops seem to skew towards cpu issues,
for my configuration. Generally they are due to DSS type operations
on my OLTP system. Which are decided upon by management, so are easy
to turn around into "hardware enhancement requirements."

jg
--
@home.com is bogus.
http://failmanifesto.org/

joel garry wrote:
forgotten: any disk failure on a degraded RAID-5 will make your data
go POOF!
Stop worrying, go SAME (Stripe And Mirror Everything, or RAID 0+1)

--

Regards,
Frank van Bortel (BAARF #287)

On Dec 11, 7:02*am, Frank van Bortel <frank.van.bor... (AT) gmail (DOT) com>
wrote:


and pay twice the price for the same storage capacity...