RAID 5 Issues

Someone posted a link a while back to a website that discussed potential
problems with RAID 5. I think it dealt mainly with spare sectors on IDE
drives, but I can't seem to find the link.
Does anyone have anything about why you should not use RAID 5 with a
database?
Thanks,
Rick Sawtell
RAID 5 is slower for write intensive operations. If your database requires
a lot of updates/inserts/deletes (maybe more than 15% write operations), I
would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be put
on RAID 5 since they are write intensive by definition.
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:uL922T5XFHA.712@.TK2MSFTNGP14.phx.gbl...
> Someone posted a link a while back to a website that discussed potential
> problems with RAID 5. I think it dealt mainly with spare sectors on IDE
> drives, but I can't seem to find the link.
> Does anyone have anything about why you should not use RAID 5 with a
> database?
>
> Thanks,
>
> Rick Sawtell
>
|||"Michael C#" <howsa@.boutdat.com> wrote in message
news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> RAID 5 is slower for write intensive operations. If your database
requires
> a lot of updates/inserts/deletes (maybe more than 15% write operations), I
> would look into RAID 1 or RAID 1+0. Also, Transaction Logs shouldn't be
put
> on RAID 5 since they are write intensive by definition.
>
All good points Michael, but I am still looking for the link.
There is a "movement" to get rid of RAID 5 for database usage. The article
is a bit inflammatory, however it was good food for thought.
Rick
|||Rick Sawtell wrote:
> "Michael C#" <howsa@.boutdat.com> wrote in message
> news:OC5asj5XFHA.2124@.TK2MSFTNGP14.phx.gbl...
> All good points Michael, but I am still looking for the link.
> There is a "movement" to get rid of RAID 5 for database usage. The
> article is a bit inflammatory, however it was good food for thought.
>
> Rick
No sure any of these are what you wanted. I remember an article from a
few months ago (can't find the link). The drive away from RAID 5 has a
lot to do with reduced performance if a drive fails and also drive
prices falling in recent years. It's not the right choice for log files
or tempdb, but for many databases is can be adequate if you can deal
with the possible performance issues during a drive rebuild.
http://www.talkaboutdatabases.com/gr...es/179342.html
http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
David Gugick
Imceda Software
www.imceda.com
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.server:392623
In article <OD9OuX6XFHA.2796@.TK2MSFTNGP09.phx.gbl>, davidg-
nospam@.imceda.com says...
> Rick Sawtell wrote:
> No sure any of these are what you wanted. I remember an article from a
> few months ago (can't find the link). The drive away from RAID 5 has a
> lot to do with reduced performance if a drive fails and also drive
> prices falling in recent years. It's not the right choice for log files
> or tempdb, but for many databases is can be adequate if you can deal
> with the possible performance issues during a drive rebuild.
> http://www.talkaboutdatabases.com/gr...es/179342.html
> http://www.dba-oracle.com/oracle_tips_raid5_bad.htm
I think, from my experience, the time when you see the most impact is
when the array consists of less than 5 drives. I've seen simple 3 x
drive R5 arrays kill a systems performance when on drive fails, but on 8
drive systems, when a drive fails, it's hardly noticed.
In these days when designers are less technical/experienced, we see a
lot of crappy solutions using something that someone has got from a
friend and failed to properly research.
I've seen soooooo many 3 x drive R5 solutions in the last 2 years that
I'm starting to wonder if I should put a question about R5 performance
on our employment test to weed out those that know from those that think
they know.
--
spam999free@.rrohio.com
remove 999 in order to email me
|||> > > "Michael C#" <howsa@.boutdat.com> wrote in message[vbcol=seagreen]
http://www.talkaboutdatabases.com/gr...es/179342.html[vbcol=seagreen]
Thanks Michael, it was on a link from a link of yours.
http://www.baarf.com/
This is what I was looking for.
Rick
|||Holy Cow...."AMEN"
We have been feverishly interviewing Sr. DBA Candidates to fill multiple
positions here.
We are getting some very impressive looking resumes.
However, I am blown away by the fact that whenever I ask even the most
simple quesiton about RAID nearly every single Candidate just stairs at me
with an open mouth.....
(Remember we're interviewing for "Senior" positions)...
The same thing is happening when we ask questions about Clustered Indexes,
PerfMon, Locking, etc.
Safe to say (At least in our market), you'll weed out a large percentage of
your candidates almost immediately by discussing RAID.
Greg Jackson
PDX, Oregon
|||Hi, Greg
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
I'm glad to see that American economy is recovering. Does your company
support H1B ?:-)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage
of
> your candidates almost immediately by discussing RAID.
>
> Greg Jackson
> PDX, Oregon
>
|||In article <#PYvRy6XFHA.3840@.tk2msftngp13.phx.gbl>,
GregoryAJackson@.Hotmail.com says...
> Holy Cow...."AMEN"
>
> We have been feverishly interviewing Sr. DBA Candidates to fill multiple
> positions here.
> We are getting some very impressive looking resumes.
> However, I am blown away by the fact that whenever I ask even the most
> simple quesiton about RAID nearly every single Candidate just stairs at me
> with an open mouth.....
> (Remember we're interviewing for "Senior" positions)...
> The same thing is happening when we ask questions about Clustered Indexes,
> PerfMon, Locking, etc.
> Safe to say (At least in our market), you'll weed out a large percentage of
> your candidates almost immediately by discussing RAID.
Yea, I always ask about clustered indexes, locking, query plans, and
perfmon, then I give them a couple diagrams and see if they understand.
I had one that I always ask people about. The customer that you built an
application for about 1 year ago calls and tells you that all of their
queries from the web server fails for reports, but it works fine for
other queries, they say that some times the smaller ones fail too. Now,
you ask them run run the query in the QA and it works fine, but it takes
forever - what's the problem? If they don't mention reindexing the
database and maintenance I discount them and show them the door...
It's funny how senior production DBA's don't know about rebuilding
indexes to return query performance, or how the number of spindles in an
array makes a difference.
--
spam999free@.rrohio.com
remove 999 in order to email me
|||Last company I worked at Had the EXACT problem in production.
It took me 3 months (LITERALLY) to convice the Executives to over ride the
production DBAs recommendation and that we rebuild indexes.
Turns out we did not have a SINGLE clustered index in production (only a
handful of nonclustered), and there was NO index maintenance.
The Prod DBAs response was that "Index Maintenance is too expensive in a
24x7 operation so we just have to live with it"
After losing our largest customer, the execs Finally agreed to try Ol'
Jacksons trick and BAM no more problems...
GAJ
sql