I have a DB on a Raid 5 of 4 disks. One of the disks failed, freezed the
screen and everything else,
I was obliged to reboot
After reboot, My DB was in suspectmode, First question, if I am not
mistaken, as far as it is raid 5, the DB must not be in suspect mode
Ok, I used the last good full backup, DB came back on line. 2 hours or more
the same thing happened.
I wonder what is the efficiency of RAID 5
Perhaps the database was exactly in the middle of IOs and the Raid did not
cover it...Was the Raid array continuously available?
Asingle disk failure on Raid 5 should not have affected anything.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"SalamElias" <eliassal@.online.nospam> wrote in message
news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> I have a DB on a Raid 5 of 4 disks. One of the disks failed, freezed the
> screen and everything else,
> I was obliged to reboot
> After reboot, My DB was in suspectmode, First question, if I am not
> mistaken, as far as it is raid 5, the DB must not be in suspect mode
> Ok, I used the last good full backup, DB came back on line. 2 hours or
more
> the same thing happened.
> I wonder what is the efficiency of RAID 5
|||Thanks for your response, when you say DB was in the middle of IOs, I
understand when reading Books on line or any other docs regarding DBs
recovery plan should be able to handle these events (rol back or roll forward
in case of disk failure. AmI mistaken?
I confirm it wa a one disk failure. Also one more strange thing happened, I
changed the faulty disk, deleted the database, tried to recreate it, It was
not possible (got error messages). I changed the physical datafile place (on
the raid 0 log disk), DB was created. Any ideas or thoughts.
Thanks again
"Wayne Snyder" wrote:
> Perhaps the database was exactly in the middle of IOs and the Raid did not
> cover it...Was the Raid array continuously available?
> Asingle disk failure on Raid 5 should not have affected anything.
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> www.mariner-usa.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
> "SalamElias" <eliassal@.online.nospam> wrote in message
> news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> more
>
>
Showing posts with label raid. Show all posts
Showing posts with label raid. Show all posts
Friday, March 30, 2012
Raid5 and Suspect DB
I have a DB on a Raid 5 of 4 disks. One of the disks failed, freezed the
screen and everything else,
I was obliged to reboot
After reboot, My DB was in suspectmode, First question, if I am not
mistaken, as far as it is raid 5, the DB must not be in suspect mode
Ok, I used the last good full backup, DB came back on line. 2 hours or more
the same thing happened.
I wonder what is the efficiency of RAID 5Perhaps the database was exactly in the middle of IOs and the Raid did not
cover it...Was the Raid array continuously available?
Asingle disk failure on Raid 5 should not have affected anything.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"SalamElias" <eliassal@.online.nospam> wrote in message
news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> I have a DB on a Raid 5 of 4 disks. One of the disks failed, freezed the
> screen and everything else,
> I was obliged to reboot
> After reboot, My DB was in suspectmode, First question, if I am not
> mistaken, as far as it is raid 5, the DB must not be in suspect mode
> Ok, I used the last good full backup, DB came back on line. 2 hours or
more
> the same thing happened.
> I wonder what is the efficiency of RAID 5|||Thanks for your response, when you say DB was in the middle of IOs, I
understand when reading Books on line or any other docs regarding DBs
recovery plan should be able to handle these events (rol back or roll forwar
d
in case of disk failure. AmI mistaken?
I confirm it wa a one disk failure. Also one more strange thing happened, I
changed the faulty disk, deleted the database, tried to recreate it, It was
not possible (got error messages). I changed the physical datafile place (on
the raid 0 log disk), DB was created. Any ideas or thoughts.
Thanks again
"Wayne Snyder" wrote:
> Perhaps the database was exactly in the middle of IOs and the Raid did not
> cover it...Was the Raid array continuously available?
> Asingle disk failure on Raid 5 should not have affected anything.
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> www.mariner-usa.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
> "SalamElias" <eliassal@.online.nospam> wrote in message
> news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> more
>
>
screen and everything else,
I was obliged to reboot
After reboot, My DB was in suspectmode, First question, if I am not
mistaken, as far as it is raid 5, the DB must not be in suspect mode
Ok, I used the last good full backup, DB came back on line. 2 hours or more
the same thing happened.
I wonder what is the efficiency of RAID 5Perhaps the database was exactly in the middle of IOs and the Raid did not
cover it...Was the Raid array continuously available?
Asingle disk failure on Raid 5 should not have affected anything.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"SalamElias" <eliassal@.online.nospam> wrote in message
news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> I have a DB on a Raid 5 of 4 disks. One of the disks failed, freezed the
> screen and everything else,
> I was obliged to reboot
> After reboot, My DB was in suspectmode, First question, if I am not
> mistaken, as far as it is raid 5, the DB must not be in suspect mode
> Ok, I used the last good full backup, DB came back on line. 2 hours or
more
> the same thing happened.
> I wonder what is the efficiency of RAID 5|||Thanks for your response, when you say DB was in the middle of IOs, I
understand when reading Books on line or any other docs regarding DBs
recovery plan should be able to handle these events (rol back or roll forwar
d
in case of disk failure. AmI mistaken?
I confirm it wa a one disk failure. Also one more strange thing happened, I
changed the faulty disk, deleted the database, tried to recreate it, It was
not possible (got error messages). I changed the physical datafile place (on
the raid 0 log disk), DB was created. Any ideas or thoughts.
Thanks again
"Wayne Snyder" wrote:
> Perhaps the database was exactly in the middle of IOs and the Raid did not
> cover it...Was the Raid array continuously available?
> Asingle disk failure on Raid 5 should not have affected anything.
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> www.mariner-usa.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
> "SalamElias" <eliassal@.online.nospam> wrote in message
> news:C7D83256-BDCA-41D4-A45C-214CF0F47202@.microsoft.com...
> more
>
>
RAID1 vs RAID5 for transaction log
I was hoping that someone could point me to some good documentation on
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advance
Raid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>
|||I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>
|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>
sql
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advance
Raid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>
|||I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>
|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>
sql
Labels:
configuration,
database,
documentation,
heavy,
log,
microsoft,
mysql,
onselecting,
optimum,
oracle,
performing,
point,
raid,
raid1,
raid5,
server,
sql,
transaction,
updatesduring
RAID1 vs RAID5 for transaction log
I was hoping that someone could point me to some good documentation on
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advanceRaid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>|||I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>
>
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advanceRaid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>|||I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>
>
Labels:
configuration,
database,
documentation,
heavy,
log,
microsoft,
mysql,
onselecting,
optimum,
oracle,
performing,
point,
raid,
raid1,
raid5,
server,
sql,
transaction,
updatesduring
RAID1 vs RAID5 for transaction log
I was hoping that someone could point me to some good documentation on
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advanceRaid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>|||This is a multi-part message in MIME format.
--060704050306020201010502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>
--060704050306020201010502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>I've always found this website to be a good RAID level overview
(even though it's a vendor website):<br>
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=http://www.acnc.com/raid.html</a><br>">http://www.acnc.com/raid.html">http://www.acnc.com/raid.html</a><br>
<br>
It's not very detailed, just brief pros & cons and how the RAID
level is constructed, but it's good info nonetheless.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
TJT wrote:
<blockquote cite="miduDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl" type="cite">
<pre wrap="">I was hoping that someone could point me to some good documentation on
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advance
</pre>
</blockquote>
</body>
</html>
--060704050306020201010502--|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
--
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>>I was hoping that someone could point me to some good documentation on
>>selecting an optimum RAID configuration. While performing heavy updates
>>during upgrades - I've noticed dramatic performance difference between
>>RAID
>>1 and RAID 5 for the transaction log.
>>It seems that it is less important for the data files themselves (RAID 5
>>doesn't seem to hurt that much).
>>Does this make sense where the RAID Configuration for the T-Log is more
>>important than the Data?
>>If someone could shed some light on this or point me to some good
>>documantation - I would greatly appreciate it.
>>Thanks in advance
>>
>>
>
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advanceRaid 5 performs very poorly on writes as does hp/compaq's ADG (Advanced data
guarding).
If your database is mainly reads then raid 5 is ok for the datafiles.
Also consider that if a disk fails and the array is having to construct a
phantom disk on the fly then the performance of your system will probably
make it unusable.
It's worth pulling a disk on a system before it goes live and practice the
recovery.
Personally I use a raid 10 array of 4 disks for my log (and raid 10 arrays
for my data too). A mirror pair may do for your log.
Paul
"TJT" <TJT@.nospam.com> wrote in message
news:uDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl...
>I was hoping that someone could point me to some good documentation on
> selecting an optimum RAID configuration. While performing heavy updates
> during upgrades - I've noticed dramatic performance difference between
> RAID
> 1 and RAID 5 for the transaction log.
> It seems that it is less important for the data files themselves (RAID 5
> doesn't seem to hurt that much).
> Does this make sense where the RAID Configuration for the T-Log is more
> important than the Data?
> If someone could shed some light on this or point me to some good
> documantation - I would greatly appreciate it.
> Thanks in advance
>|||This is a multi-part message in MIME format.
--060704050306020201010502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I've always found this website to be a good RAID level overview (even
though it's a vendor website):
http://www.acnc.com/raid.html
It's not very detailed, just brief pros & cons and how the RAID level is
constructed, but it's good info nonetheless.
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
TJT wrote:
>I was hoping that someone could point me to some good documentation on
>selecting an optimum RAID configuration. While performing heavy updates
>during upgrades - I've noticed dramatic performance difference between RAID
>1 and RAID 5 for the transaction log.
>It seems that it is less important for the data files themselves (RAID 5
>doesn't seem to hurt that much).
>Does this make sense where the RAID Configuration for the T-Log is more
>important than the Data?
>If someone could shed some light on this or point me to some good
>documantation - I would greatly appreciate it.
>Thanks in advance
>
>
--060704050306020201010502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>I've always found this website to be a good RAID level overview
(even though it's a vendor website):<br>
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=http://www.acnc.com/raid.html</a><br>">http://www.acnc.com/raid.html">http://www.acnc.com/raid.html</a><br>
<br>
It's not very detailed, just brief pros & cons and how the RAID
level is constructed, but it's good info nonetheless.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
TJT wrote:
<blockquote cite="miduDWYpug5FHA.1248@.TK2MSFTNGP14.phx.gbl" type="cite">
<pre wrap="">I was hoping that someone could point me to some good documentation on
selecting an optimum RAID configuration. While performing heavy updates
during upgrades - I've noticed dramatic performance difference between RAID
1 and RAID 5 for the transaction log.
It seems that it is less important for the data files themselves (RAID 5
doesn't seem to hurt that much).
Does this make sense where the RAID Configuration for the T-Log is more
important than the Data?
If someone could shed some light on this or point me to some good
documantation - I would greatly appreciate it.
Thanks in advance
</pre>
</blockquote>
</body>
</html>
--060704050306020201010502--|||RAID5 is terrible for heavily updated data, and the Transaction Log is the
prototypical worst case. Go for RAID 1. For database files/filegroups it
really depends on the update load. In general the feeling has been that
RAID 10 (aka 1+0) is better for databases since you get maximum performance
and availability. But if you have lightly updated tables then RAID 5 is
going to be OK.
If I remember correctly Kalen Delaney's "Inside SQL Server 2000" book has a
good discussion about this.
--
Hal Berenson, President
PredictableIT, LLC
www.predictableit.com
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message
news:e6mn%23ll5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I've always found this website to be a good RAID level overview (even
> though it's a vendor website):
> http://www.acnc.com/raid.html
> It's not very detailed, just brief pros & cons and how the RAID level is
> constructed, but it's good info nonetheless.
> --
> *mike hodgson*
> blog: http://sqlnerd.blogspot.com
>
> TJT wrote:
>>I was hoping that someone could point me to some good documentation on
>>selecting an optimum RAID configuration. While performing heavy updates
>>during upgrades - I've noticed dramatic performance difference between
>>RAID
>>1 and RAID 5 for the transaction log.
>>It seems that it is less important for the data files themselves (RAID 5
>>doesn't seem to hurt that much).
>>Does this make sense where the RAID Configuration for the T-Log is more
>>important than the Data?
>>If someone could shed some light on this or point me to some good
>>documantation - I would greatly appreciate it.
>>Thanks in advance
>>
>>
>
Labels:
configuration,
database,
documentation,
heavy,
log,
microsoft,
mysql,
optimum,
oracle,
performing,
point,
raid,
raid1,
raid5,
selecting,
server,
sql,
transaction,
updates
RAID System
What is the best RAID system to use in a SAN environment.
Is it ok to use RAID 5 on everything like data, log, etc
when using a SAN shared storage.In certain cases it may make sense to use other
configuration or use different raid levels for tempdb
(raid 0), log (raid 1+0), databases (raid 5) etc. Here you
have to be sure that you will be getting excellent
cooperation from the network/hardare support departments,
or if you are responsible for SAN and sql server.
Generally I would say it is ok to use raid 5 for
everything, because thats what I decided to use when we
configured SAN for sql server.
>--Original Message--
>What is the best RAID system to use in a SAN environment.
>Is it ok to use RAID 5 on everything like data, log, etc
>when using a SAN shared storage.
>.
>|||Every system has different requirements, but one is generally true - using
RAID 5 for logs is usually a bad idea because the parity calculation
requires additional overhead to read bits (disk i/o), parity calculation
(cpu, hba etc) & then the parity writes (more disk i/o).
Generally speaking, logs are far better off on a mirror, perhaps striped as
well, but not raid 5.
Regards,
Greg Linwood
SQL Server MVP
"Aboki" <waco361@.hotmail.com> wrote in message
news:13ac01c381e7$58753290$a401280a@.phx.gbl...
> What is the best RAID system to use in a SAN environment.
> Is it ok to use RAID 5 on everything like data, log, etc
> when using a SAN shared storage.
Is it ok to use RAID 5 on everything like data, log, etc
when using a SAN shared storage.In certain cases it may make sense to use other
configuration or use different raid levels for tempdb
(raid 0), log (raid 1+0), databases (raid 5) etc. Here you
have to be sure that you will be getting excellent
cooperation from the network/hardare support departments,
or if you are responsible for SAN and sql server.
Generally I would say it is ok to use raid 5 for
everything, because thats what I decided to use when we
configured SAN for sql server.
>--Original Message--
>What is the best RAID system to use in a SAN environment.
>Is it ok to use RAID 5 on everything like data, log, etc
>when using a SAN shared storage.
>.
>|||Every system has different requirements, but one is generally true - using
RAID 5 for logs is usually a bad idea because the parity calculation
requires additional overhead to read bits (disk i/o), parity calculation
(cpu, hba etc) & then the parity writes (more disk i/o).
Generally speaking, logs are far better off on a mirror, perhaps striped as
well, but not raid 5.
Regards,
Greg Linwood
SQL Server MVP
"Aboki" <waco361@.hotmail.com> wrote in message
news:13ac01c381e7$58753290$a401280a@.phx.gbl...
> What is the best RAID system to use in a SAN environment.
> Is it ok to use RAID 5 on everything like data, log, etc
> when using a SAN shared storage.
RAID stripe size confusion
setting up a new ibm xserve server.
The SCSI serveRAID controller says to use 16kb stripe for generic
"transaction processing database" (not sql server specific). but the
IBM SQL server 2005 on xserve guide says to use 64kb stripes.
posts I have seen say to use scsi controller defaults unless a reason.
which should we choose?this is for RAID10 data drives.
THe redpaper 64kb setting up with a san which we do not have.
but 16k stripe size seems odd for sql server.sql
The SCSI serveRAID controller says to use 16kb stripe for generic
"transaction processing database" (not sql server specific). but the
IBM SQL server 2005 on xserve guide says to use 64kb stripes.
posts I have seen say to use scsi controller defaults unless a reason.
which should we choose?this is for RAID10 data drives.
THe redpaper 64kb setting up with a san which we do not have.
but 16k stripe size seems odd for sql server.sql
RAID stripe size confusion
setting up a new ibm xserve server.
The SCSI serveRAID controller says to use 16kb stripe for generic
"transaction processing database" (not sql server specific). but the
IBM SQL server 2005 on xserve guide says to use 64kb stripes.
posts I have seen say to use scsi controller defaults unless a reason.
which should we choose?this is for RAID10 data drives.
THe redpaper 64kb setting up with a san which we do not have.
but 16k stripe size seems odd for sql server.
The SCSI serveRAID controller says to use 16kb stripe for generic
"transaction processing database" (not sql server specific). but the
IBM SQL server 2005 on xserve guide says to use 64kb stripes.
posts I have seen say to use scsi controller defaults unless a reason.
which should we choose?this is for RAID10 data drives.
THe redpaper 64kb setting up with a san which we do not have.
but 16k stripe size seems odd for sql server.
RAID setup.
Hello.
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.
The info you ahve given would not be sufficient to recommend 'the best option
to setup this server'. But if I have to make a decision, I'd probably use two
disks to create a mirror for the OS, and use the other four disks to create a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.
The info you ahve given would not be sufficient to recommend 'the best option
to setup this server'. But if I have to make a decision, I'd probably use two
disks to create a mirror for the OS, and use the other four disks to create a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
RAID setup.
Hello.
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.The info you ahve given would not be sufficient to recommend 'the best option
to setup this server'. But if I have to make a decision, I'd probably use two
disks to create a mirror for the OS, and use the other four disks to create a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.The info you ahve given would not be sufficient to recommend 'the best option
to setup this server'. But if I have to make a decision, I'd probably use two
disks to create a mirror for the OS, and use the other four disks to create a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
RAID setup.
Hello.
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.The info you ahve given would not be sufficient to recommend 'the best optio
n
to setup this server'. But if I have to make a decision, I'd probably use tw
o
disks to create a mirror for the OS, and use the other four disks to create
a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover
,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and
MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
I would like to know the point of view of the experts at this forum.
I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
six internal hot swapable SCSI hard drives of 73.4 Gb each.
I will setup that Server with MS Windows 2003 Server Standard Edition and MS
SQL Server 2000.
I will load the Server with 5 databases:
1.- MRP production database, very intensive in writing data and also on be
red for reports and other applications. Current size about 1.5 Gb.
2.- MRP test database, same than (1) but only to be used when testing
something new, not very often. Current size about 1.5 Gb.
3.- Payroll database, used ligthly about two days a week, just collecting
employee's checks ins and outs from employees the remaining time of the
week. Current size about 700 Mb
4. - Other small database, very few usage. Current size 100 Mb.
What would be the best option to setup this Server, number of logical
drives, RAID levels, stripe size, write cache settings?
I would like also to implement log shipping in this Server, do I need
exactly the same configuration for the secondary Server?
Thanks for your help...!
Alex.The info you ahve given would not be sufficient to recommend 'the best optio
n
to setup this server'. But if I have to make a decision, I'd probably use tw
o
disks to create a mirror for the OS, and use the other four disks to create
a
RAID5 set.
For log shipping, you don't absolutely need the same configurations for the
standby server. The key factor to consider is what/how you'll use your
standby server. If you don't want any performance degradation after failover
,
use an identical server. If the standby server is intended for temporary
relief and your customers are okay with performance degradation while the
primary server is beign restored/recovered, you may consider a less powerful
server config. We typically use the same class of servers for both the
primary and the secondary.
Linchi
"Microsoft Newsgroups" wrote:
> Hello.
> I would like to know the point of view of the experts at this forum.
> I have one IBM xSeries 236 Server with just one ServeRAID 7 controller and
> six internal hot swapable SCSI hard drives of 73.4 Gb each.
> I will setup that Server with MS Windows 2003 Server Standard Edition and
MS
> SQL Server 2000.
> I will load the Server with 5 databases:
> 1.- MRP production database, very intensive in writing data and also on be
> red for reports and other applications. Current size about 1.5 Gb.
> 2.- MRP test database, same than (1) but only to be used when testing
> something new, not very often. Current size about 1.5 Gb.
> 3.- Payroll database, used ligthly about two days a week, just collecting
> employee's checks ins and outs from employees the remaining time of the
> week. Current size about 700 Mb
> 4. - Other small database, very few usage. Current size 100 Mb.
> What would be the best option to setup this Server, number of logical
> drives, RAID levels, stripe size, write cache settings?
> I would like also to implement log shipping in this Server, do I need
> exactly the same configuration for the secondary Server?
> Thanks for your help...!
> Alex.
>
>
Raid Setup
We have just bought a new box for our SQL Database's.. ..We have three
database's, 1 is by far the most intensive, it's a 3rd party application
database and is around 20gb.. ..it uses the temp db heavily.. ..and the
transaction log gets up to about 750mb - 1gb before it's backed up every
15minutes. The other databases are 20gb and 10gb respectively, the 20gb
database contains 15gb of BLOB's.
The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
Array.
My initial views for the RAID configuration were as follows:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (10xSATA) All Datafiles
Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
Although I have also looked at:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (6xSATA) All Datafiles
Array 5, RAID 10 (2xSATA) File containing BLOB's
Array 6, RAID 1 (2xSATA) Transaction Log 2
Array 7, RAID 1 (2xSATA) Transaction Log 3
And:
Array 1, RAID 1 (2xSCSI) OS
Array 2, RAID 1 (2xSCSI) PageFile
Array 3, RAID 1 (2xSCSI) TempDB
Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
Array 6, RAID 1 (2xSATA) File containing BLOB's
Array 7, RAID 1 (2xSATA) Transaction Log 1
Array 8, RAID 1 (2xSATA) Transaction Log 2
Array 9, RAID 1 (2xSATA) Transaction Log 3
...I'll be doing some further reading, but just wondered if anyone had any
input on this?
Thanks in advance BenHi Ben
Why did you buy so many disks & such a small amount of memory? Are you using
SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
important factors as they define your memory constraints & influence whether
you should configure any of your disks for specialist read / write activity.
The less memory you have, the more you push IO down to your disk
sub-system..
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> We have just bought a new box for our SQL Database's.. ..We have three
> database's, 1 is by far the most intensive, it's a 3rd party application
> database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> transaction log gets up to about 750mb - 1gb before it's backed up every
> 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> database contains 15gb of BLOB's.
> The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> Array.
> My initial views for the RAID configuration were as follows:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (10xSATA) All Datafiles
> Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> Although I have also looked at:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (6xSATA) All Datafiles
> Array 5, RAID 10 (2xSATA) File containing BLOB's
> Array 6, RAID 1 (2xSATA) Transaction Log 2
> Array 7, RAID 1 (2xSATA) Transaction Log 3
> And:
> Array 1, RAID 1 (2xSCSI) OS
> Array 2, RAID 1 (2xSCSI) PageFile
> Array 3, RAID 1 (2xSCSI) TempDB
> Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> Array 6, RAID 1 (2xSATA) File containing BLOB's
> Array 7, RAID 1 (2xSATA) Transaction Log 1
> Array 8, RAID 1 (2xSATA) Transaction Log 2
> Array 9, RAID 1 (2xSATA) Transaction Log 3
> ...I'll be doing some further reading, but just wondered if anyone had any
> input on this?
> Thanks in advance Ben|||We're using Windows 2003 Standard Edition, and SQL Standard Edition... ...so
more memory wasn't really an option.. ..the cost of disks are cheap in
comparison to the upgrade to Enterprise Edition of SQL - we have to purchase
the processor licenses. We haven't actually purchased the disks yet, if
there's only a small benefit between say 12 and 18 disks we'll only buy the
12...
"Greg Linwood" wrote:
> Hi Ben
> Why did you buy so many disks & such a small amount of memory? Are you usi
ng
> SQL 2000 or SQL 2005? Which version of Windows? These are actually all qui
te
> important factors as they define your memory constraints & influence wheth
er
> you should configure any of your disks for specialist read / write activit
y.
> The less memory you have, the more you push IO down to your disk
> sub-system..
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>
>|||Hi Ben
This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
Memory.
That's why I asked whether you're using SQL 2000 or SQL 2005.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...[vbcol=seagreen]
> We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> ...so
> more memory wasn't really an option.. ..the cost of disks are cheap in
> comparison to the upgrade to Enterprise Edition of SQL - we have to
> purchase
> the processor licenses. We haven't actually purchased the disks yet, if
> there's only a small benefit between say 12 and 18 disks we'll only buy
> the
> 12...
> "Greg Linwood" wrote:
>|||Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence I'm
trying to compensate with disks and find the best raid config I can...
"Greg Linwood" wrote:
> Hi Ben
> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bi
t
> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standar
d
> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> Memory.
> That's why I asked whether you're using SQL 2000 or SQL 2005.
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>
>|||OK, I just wanted to check up on these points first, because they're often
missed with new SQL server implementations.
Back to your original qns then:
Firstly, drop the idea of a seperate Array for your page file b/c well
configured, dedicated database servers should perform very little IO against
page files. Page files are for machines where many processes need to share
virtual memory & dedicated servers generally do very little of this -
certainly not enought to warrant dedicating an array to. Far better to
dedicate this array to a tlog or some other useful purpose
Seperating objects down to the granularity you've outlined in the last
option. The problem with this approach is that you're making assumptions
about how your IO should be partitioned where it's often far easier to leave
these objects on a single array & let SQL Server spread the load accross
them. Another way of looking at this scenario is that if any one object type
experiences heavy IO, it has fewer disks to achieve its workload with.
Short of more specific information about the actual workload performed by
the various DB objects, I'd say that your initial configuration is a very
good starting point.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...[vbcol=seagreen]
> Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> I'm
> trying to compensate with disks and find the best raid config I can...
> "Greg Linwood" wrote:
>|||Smashing thanks Greg, in the original configuration I have 2 transaction log
s
sharing an array... ...these logs don't grow above 250mb over 15minutes...
...but I'm wondering whether it's worth splitting them out onto seperate
arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
room... ...but I've read it's best to seperate Transaction Logs onto
seperate arrays so they can be sequential... ...I'm unsure if the benefit of
having them on seperate disks would be less than having the 10 disks in the
RAID 10 array... ...I guess it's one of those things I'll find out with some
testing :-) Anyway thanks again for the responses..
"Greg Linwood" wrote:
> OK, I just wanted to check up on these points first, because they're often
> missed with new SQL server implementations.
> Back to your original qns then:
> Firstly, drop the idea of a seperate Array for your page file b/c well
> configured, dedicated database servers should perform very little IO again
st
> page files. Page files are for machines where many processes need to share
> virtual memory & dedicated servers generally do very little of this -
> certainly not enought to warrant dedicating an array to. Far better to
> dedicate this array to a tlog or some other useful purpose
> Seperating objects down to the granularity you've outlined in the last
> option. The problem with this approach is that you're making assumptions
> about how your IO should be partitioned where it's often far easier to lea
ve
> these objects on a single array & let SQL Server spread the load accross
> them. Another way of looking at this scenario is that if any one object ty
pe
> experiences heavy IO, it has fewer disks to achieve its workload with.
> Short of more specific information about the actual workload performed by
> the various DB objects, I'd say that your initial configuration is a very
> good starting point.
> Regards,
> Greg Linwood
> SQL Server MVP
>
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
>
>|||Hi Ben
I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
quite moderate & you could probably find better uses for those disks.
Speaking of which - one thing I missed when I first looked at your
suggestions is that you don't have a local drive for backups. Are you
planning to do these off onto a network or tape? If not, I suggest you don't
forget a backup volume in your plan & those extra disks might come in handy
for this purpose...
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...[vbcol=seagreen]
> Smashing thanks Greg, in the original configuration I have 2 transaction
> logs
> sharing an array... ...these logs don't grow above 250mb over 15minutes...
> ...but I'm wondering whether it's worth splitting them out onto seperate
> arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> room... ...but I've read it's best to seperate Transaction Logs onto
> seperate arrays so they can be sequential... ...I'm unsure if the benefit
> of
> having them on seperate disks would be less than having the 10 disks in
> the
> RAID 10 array... ...I guess it's one of those things I'll find out with
> some
> testing :-) Anyway thanks again for the responses..
> "Greg Linwood" wrote:
>|||We currently backup over the network and then onto tape.. ..but it's worth
thinking about, thanks again for the help :-)
"Greg Linwood" wrote:
> Hi Ben
> I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
> quite moderate & you could probably find better uses for those disks.
> Speaking of which - one thing I missed when I first looked at your
> suggestions is that you don't have a local drive for backups. Are you
> planning to do these off onto a network or tape? If not, I suggest you don
't
> forget a backup volume in your plan & those extra disks might come in hand
y
> for this purpose...
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
>
>sql
database's, 1 is by far the most intensive, it's a 3rd party application
database and is around 20gb.. ..it uses the temp db heavily.. ..and the
transaction log gets up to about 750mb - 1gb before it's backed up every
15minutes. The other databases are 20gb and 10gb respectively, the 20gb
database contains 15gb of BLOB's.
The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
Array.
My initial views for the RAID configuration were as follows:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (10xSATA) All Datafiles
Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
Although I have also looked at:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (6xSATA) All Datafiles
Array 5, RAID 10 (2xSATA) File containing BLOB's
Array 6, RAID 1 (2xSATA) Transaction Log 2
Array 7, RAID 1 (2xSATA) Transaction Log 3
And:
Array 1, RAID 1 (2xSCSI) OS
Array 2, RAID 1 (2xSCSI) PageFile
Array 3, RAID 1 (2xSCSI) TempDB
Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
Array 6, RAID 1 (2xSATA) File containing BLOB's
Array 7, RAID 1 (2xSATA) Transaction Log 1
Array 8, RAID 1 (2xSATA) Transaction Log 2
Array 9, RAID 1 (2xSATA) Transaction Log 3
...I'll be doing some further reading, but just wondered if anyone had any
input on this?
Thanks in advance BenHi Ben
Why did you buy so many disks & such a small amount of memory? Are you using
SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
important factors as they define your memory constraints & influence whether
you should configure any of your disks for specialist read / write activity.
The less memory you have, the more you push IO down to your disk
sub-system..
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> We have just bought a new box for our SQL Database's.. ..We have three
> database's, 1 is by far the most intensive, it's a 3rd party application
> database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> transaction log gets up to about 750mb - 1gb before it's backed up every
> 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> database contains 15gb of BLOB's.
> The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> Array.
> My initial views for the RAID configuration were as follows:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (10xSATA) All Datafiles
> Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> Although I have also looked at:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (6xSATA) All Datafiles
> Array 5, RAID 10 (2xSATA) File containing BLOB's
> Array 6, RAID 1 (2xSATA) Transaction Log 2
> Array 7, RAID 1 (2xSATA) Transaction Log 3
> And:
> Array 1, RAID 1 (2xSCSI) OS
> Array 2, RAID 1 (2xSCSI) PageFile
> Array 3, RAID 1 (2xSCSI) TempDB
> Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> Array 6, RAID 1 (2xSATA) File containing BLOB's
> Array 7, RAID 1 (2xSATA) Transaction Log 1
> Array 8, RAID 1 (2xSATA) Transaction Log 2
> Array 9, RAID 1 (2xSATA) Transaction Log 3
> ...I'll be doing some further reading, but just wondered if anyone had any
> input on this?
> Thanks in advance Ben|||We're using Windows 2003 Standard Edition, and SQL Standard Edition... ...so
more memory wasn't really an option.. ..the cost of disks are cheap in
comparison to the upgrade to Enterprise Edition of SQL - we have to purchase
the processor licenses. We haven't actually purchased the disks yet, if
there's only a small benefit between say 12 and 18 disks we'll only buy the
12...
"Greg Linwood" wrote:
> Hi Ben
> Why did you buy so many disks & such a small amount of memory? Are you usi
ng
> SQL 2000 or SQL 2005? Which version of Windows? These are actually all qui
te
> important factors as they define your memory constraints & influence wheth
er
> you should configure any of your disks for specialist read / write activit
y.
> The less memory you have, the more you push IO down to your disk
> sub-system..
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>
>|||Hi Ben
This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
Memory.
That's why I asked whether you're using SQL 2000 or SQL 2005.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...[vbcol=seagreen]
> We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> ...so
> more memory wasn't really an option.. ..the cost of disks are cheap in
> comparison to the upgrade to Enterprise Edition of SQL - we have to
> purchase
> the processor licenses. We haven't actually purchased the disks yet, if
> there's only a small benefit between say 12 and 18 disks we'll only buy
> the
> 12...
> "Greg Linwood" wrote:
>|||Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence I'm
trying to compensate with disks and find the best raid config I can...
"Greg Linwood" wrote:
> Hi Ben
> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bi
t
> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standar
d
> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> Memory.
> That's why I asked whether you're using SQL 2000 or SQL 2005.
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>
>|||OK, I just wanted to check up on these points first, because they're often
missed with new SQL server implementations.
Back to your original qns then:
Firstly, drop the idea of a seperate Array for your page file b/c well
configured, dedicated database servers should perform very little IO against
page files. Page files are for machines where many processes need to share
virtual memory & dedicated servers generally do very little of this -
certainly not enought to warrant dedicating an array to. Far better to
dedicate this array to a tlog or some other useful purpose
Seperating objects down to the granularity you've outlined in the last
option. The problem with this approach is that you're making assumptions
about how your IO should be partitioned where it's often far easier to leave
these objects on a single array & let SQL Server spread the load accross
them. Another way of looking at this scenario is that if any one object type
experiences heavy IO, it has fewer disks to achieve its workload with.
Short of more specific information about the actual workload performed by
the various DB objects, I'd say that your initial configuration is a very
good starting point.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...[vbcol=seagreen]
> Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> I'm
> trying to compensate with disks and find the best raid config I can...
> "Greg Linwood" wrote:
>|||Smashing thanks Greg, in the original configuration I have 2 transaction log
s
sharing an array... ...these logs don't grow above 250mb over 15minutes...
...but I'm wondering whether it's worth splitting them out onto seperate
arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
room... ...but I've read it's best to seperate Transaction Logs onto
seperate arrays so they can be sequential... ...I'm unsure if the benefit of
having them on seperate disks would be less than having the 10 disks in the
RAID 10 array... ...I guess it's one of those things I'll find out with some
testing :-) Anyway thanks again for the responses..
"Greg Linwood" wrote:
> OK, I just wanted to check up on these points first, because they're often
> missed with new SQL server implementations.
> Back to your original qns then:
> Firstly, drop the idea of a seperate Array for your page file b/c well
> configured, dedicated database servers should perform very little IO again
st
> page files. Page files are for machines where many processes need to share
> virtual memory & dedicated servers generally do very little of this -
> certainly not enought to warrant dedicating an array to. Far better to
> dedicate this array to a tlog or some other useful purpose
> Seperating objects down to the granularity you've outlined in the last
> option. The problem with this approach is that you're making assumptions
> about how your IO should be partitioned where it's often far easier to lea
ve
> these objects on a single array & let SQL Server spread the load accross
> them. Another way of looking at this scenario is that if any one object ty
pe
> experiences heavy IO, it has fewer disks to achieve its workload with.
> Short of more specific information about the actual workload performed by
> the various DB objects, I'd say that your initial configuration is a very
> good starting point.
> Regards,
> Greg Linwood
> SQL Server MVP
>
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
>
>|||Hi Ben
I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
quite moderate & you could probably find better uses for those disks.
Speaking of which - one thing I missed when I first looked at your
suggestions is that you don't have a local drive for backups. Are you
planning to do these off onto a network or tape? If not, I suggest you don't
forget a backup volume in your plan & those extra disks might come in handy
for this purpose...
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...[vbcol=seagreen]
> Smashing thanks Greg, in the original configuration I have 2 transaction
> logs
> sharing an array... ...these logs don't grow above 250mb over 15minutes...
> ...but I'm wondering whether it's worth splitting them out onto seperate
> arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> room... ...but I've read it's best to seperate Transaction Logs onto
> seperate arrays so they can be sequential... ...I'm unsure if the benefit
> of
> having them on seperate disks would be less than having the 10 disks in
> the
> RAID 10 array... ...I guess it's one of those things I'll find out with
> some
> testing :-) Anyway thanks again for the responses..
> "Greg Linwood" wrote:
>|||We currently backup over the network and then onto tape.. ..but it's worth
thinking about, thanks again for the help :-)
"Greg Linwood" wrote:
> Hi Ben
> I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
> quite moderate & you could probably find better uses for those disks.
> Speaking of which - one thing I missed when I first looked at your
> suggestions is that you don't have a local drive for backups. Are you
> planning to do these off onto a network or tape? If not, I suggest you don
't
> forget a backup volume in your plan & those extra disks might come in hand
y
> for this purpose...
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
>
>sql
Raid Setup
We have just bought a new box for our SQL Database's.. ..We have three
database's, 1 is by far the most intensive, it's a 3rd party application
database and is around 20gb.. ..it uses the temp db heavily.. ..and the
transaction log gets up to about 750mb - 1gb before it's backed up every
15minutes. The other databases are 20gb and 10gb respectively, the 20gb
database contains 15gb of BLOB's.
The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
Array.
My initial views for the RAID configuration were as follows:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (10xSATA) All Datafiles
Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
Although I have also looked at:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (6xSATA) All Datafiles
Array 5, RAID 10 (2xSATA) File containing BLOB's
Array 6, RAID 1 (2xSATA) Transaction Log 2
Array 7, RAID 1 (2xSATA) Transaction Log 3
And:
Array 1, RAID 1 (2xSCSI) OS
Array 2, RAID 1 (2xSCSI) PageFile
Array 3, RAID 1 (2xSCSI) TempDB
Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
Array 6, RAID 1 (2xSATA) File containing BLOB's
Array 7, RAID 1 (2xSATA) Transaction Log 1
Array 8, RAID 1 (2xSATA) Transaction Log 2
Array 9, RAID 1 (2xSATA) Transaction Log 3
...I'll be doing some further reading, but just wondered if anyone had any
input on this?
Thanks in advance BenHi Ben
Why did you buy so many disks & such a small amount of memory? Are you using
SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
important factors as they define your memory constraints & influence whether
you should configure any of your disks for specialist read / write activity.
The less memory you have, the more you push IO down to your disk
sub-system..
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> We have just bought a new box for our SQL Database's.. ..We have three
> database's, 1 is by far the most intensive, it's a 3rd party application
> database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> transaction log gets up to about 750mb - 1gb before it's backed up every
> 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> database contains 15gb of BLOB's.
> The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> Array.
> My initial views for the RAID configuration were as follows:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (10xSATA) All Datafiles
> Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> Although I have also looked at:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (6xSATA) All Datafiles
> Array 5, RAID 10 (2xSATA) File containing BLOB's
> Array 6, RAID 1 (2xSATA) Transaction Log 2
> Array 7, RAID 1 (2xSATA) Transaction Log 3
> And:
> Array 1, RAID 1 (2xSCSI) OS
> Array 2, RAID 1 (2xSCSI) PageFile
> Array 3, RAID 1 (2xSCSI) TempDB
> Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> Array 6, RAID 1 (2xSATA) File containing BLOB's
> Array 7, RAID 1 (2xSATA) Transaction Log 1
> Array 8, RAID 1 (2xSATA) Transaction Log 2
> Array 9, RAID 1 (2xSATA) Transaction Log 3
> ...I'll be doing some further reading, but just wondered if anyone had any
> input on this?
> Thanks in advance Ben|||We're using Windows 2003 Standard Edition, and SQL Standard Edition... ...so
more memory wasn't really an option.. ..the cost of disks are cheap in
comparison to the upgrade to Enterprise Edition of SQL - we have to purchase
the processor licenses. We haven't actually purchased the disks yet, if
there's only a small benefit between say 12 and 18 disks we'll only buy the
12...
"Greg Linwood" wrote:
> Hi Ben
> Why did you buy so many disks & such a small amount of memory? Are you using
> SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
> important factors as they define your memory constraints & influence whether
> you should configure any of your disks for specialist read / write activity.
> The less memory you have, the more you push IO down to your disk
> sub-system..
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >
> > We have just bought a new box for our SQL Database's.. ..We have three
> > database's, 1 is by far the most intensive, it's a 3rd party application
> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> > transaction log gets up to about 750mb - 1gb before it's backed up every
> > 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> > database contains 15gb of BLOB's.
> > The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> > Array.
> >
> > My initial views for the RAID configuration were as follows:
> >
> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> > Array 2, RAID 1 (2xSCSI) TempDB
> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> > Array 4, RAID 10 (10xSATA) All Datafiles
> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >
> > Although I have also looked at:
> >
> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> > Array 2, RAID 1 (2xSCSI) TempDB
> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> > Array 4, RAID 10 (6xSATA) All Datafiles
> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >
> > And:
> >
> > Array 1, RAID 1 (2xSCSI) OS
> > Array 2, RAID 1 (2xSCSI) PageFile
> > Array 3, RAID 1 (2xSCSI) TempDB
> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >
> > ...I'll be doing some further reading, but just wondered if anyone had any
> > input on this?
> >
> > Thanks in advance Ben
>
>|||Hi Ben
This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
Memory.
That's why I asked whether you're using SQL 2000 or SQL 2005.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> ...so
> more memory wasn't really an option.. ..the cost of disks are cheap in
> comparison to the upgrade to Enterprise Edition of SQL - we have to
> purchase
> the processor licenses. We haven't actually purchased the disks yet, if
> there's only a small benefit between say 12 and 18 disks we'll only buy
> the
> 12...
> "Greg Linwood" wrote:
>> Hi Ben
>> Why did you buy so many disks & such a small amount of memory? Are you
>> using
>> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
>> quite
>> important factors as they define your memory constraints & influence
>> whether
>> you should configure any of your disks for specialist read / write
>> activity.
>> The less memory you have, the more you push IO down to your disk
>> sub-system..
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >
>> > We have just bought a new box for our SQL Database's.. ..We have three
>> > database's, 1 is by far the most intensive, it's a 3rd party
>> > application
>> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
>> > transaction log gets up to about 750mb - 1gb before it's backed up
>> > every
>> > 15minutes. The other databases are 20gb and 10gb respectively, the
>> > 20gb
>> > database contains 15gb of BLOB's.
>> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
>> > disks
>> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
>> > Smart
>> > Array.
>> >
>> > My initial views for the RAID configuration were as follows:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> > Array 2, RAID 1 (2xSCSI) TempDB
>> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> > Array 4, RAID 10 (10xSATA) All Datafiles
>> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >
>> > Although I have also looked at:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> > Array 2, RAID 1 (2xSCSI) TempDB
>> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> > Array 4, RAID 10 (6xSATA) All Datafiles
>> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >
>> > And:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS
>> > Array 2, RAID 1 (2xSCSI) PageFile
>> > Array 3, RAID 1 (2xSCSI) TempDB
>> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >
>> > ...I'll be doing some further reading, but just wondered if anyone had
>> > any
>> > input on this?
>> >
>> > Thanks in advance Ben
>>|||Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence I'm
trying to compensate with disks and find the best raid config I can...
"Greg Linwood" wrote:
> Hi Ben
> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> Memory.
> That's why I asked whether you're using SQL 2000 or SQL 2005.
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> > ...so
> > more memory wasn't really an option.. ..the cost of disks are cheap in
> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> > purchase
> > the processor licenses. We haven't actually purchased the disks yet, if
> > there's only a small benefit between say 12 and 18 disks we'll only buy
> > the
> > 12...
> >
> > "Greg Linwood" wrote:
> >
> >> Hi Ben
> >>
> >> Why did you buy so many disks & such a small amount of memory? Are you
> >> using
> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
> >> quite
> >> important factors as they define your memory constraints & influence
> >> whether
> >> you should configure any of your disks for specialist read / write
> >> activity.
> >> The less memory you have, the more you push IO down to your disk
> >> sub-system..
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >
> >> > We have just bought a new box for our SQL Database's.. ..We have three
> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> > application
> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> >> > transaction log gets up to about 750mb - 1gb before it's backed up
> >> > every
> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
> >> > 20gb
> >> > database contains 15gb of BLOB's.
> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
> >> > disks
> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
> >> > Smart
> >> > Array.
> >> >
> >> > My initial views for the RAID configuration were as follows:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >
> >> > Although I have also looked at:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >
> >> > And:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS
> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >
> >> > ...I'll be doing some further reading, but just wondered if anyone had
> >> > any
> >> > input on this?
> >> >
> >> > Thanks in advance Ben
> >>
> >>
> >>
>
>|||OK, I just wanted to check up on these points first, because they're often
missed with new SQL server implementations.
Back to your original qns then:
Firstly, drop the idea of a seperate Array for your page file b/c well
configured, dedicated database servers should perform very little IO against
page files. Page files are for machines where many processes need to share
virtual memory & dedicated servers generally do very little of this -
certainly not enought to warrant dedicating an array to. Far better to
dedicate this array to a tlog or some other useful purpose
Seperating objects down to the granularity you've outlined in the last
option. The problem with this approach is that you're making assumptions
about how your IO should be partitioned where it's often far easier to leave
these objects on a single array & let SQL Server spread the load accross
them. Another way of looking at this scenario is that if any one object type
experiences heavy IO, it has fewer disks to achieve its workload with.
Short of more specific information about the actual workload performed by
the various DB objects, I'd say that your initial configuration is a very
good starting point.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> I'm
> trying to compensate with disks and find the best raid config I can...
> "Greg Linwood" wrote:
>> Hi Ben
>> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32
>> bit
>> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
>> Standard
>> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
>> Memory.
>> That's why I asked whether you're using SQL 2000 or SQL 2005.
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
>> > ...so
>> > more memory wasn't really an option.. ..the cost of disks are cheap in
>> > comparison to the upgrade to Enterprise Edition of SQL - we have to
>> > purchase
>> > the processor licenses. We haven't actually purchased the disks yet,
>> > if
>> > there's only a small benefit between say 12 and 18 disks we'll only buy
>> > the
>> > 12...
>> >
>> > "Greg Linwood" wrote:
>> >
>> >> Hi Ben
>> >>
>> >> Why did you buy so many disks & such a small amount of memory? Are you
>> >> using
>> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
>> >> quite
>> >> important factors as they define your memory constraints & influence
>> >> whether
>> >> you should configure any of your disks for specialist read / write
>> >> activity.
>> >> The less memory you have, the more you push IO down to your disk
>> >> sub-system..
>> >>
>> >> Regards,
>> >> Greg Linwood
>> >> SQL Server MVP
>> >>
>> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >> >
>> >> > We have just bought a new box for our SQL Database's.. ..We have
>> >> > three
>> >> > database's, 1 is by far the most intensive, it's a 3rd party
>> >> > application
>> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and
>> >> > the
>> >> > transaction log gets up to about 750mb - 1gb before it's backed up
>> >> > every
>> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
>> >> > 20gb
>> >> > database contains 15gb of BLOB's.
>> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
>> >> > disks
>> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
>> >> > Smart
>> >> > Array.
>> >> >
>> >> > My initial views for the RAID configuration were as follows:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> > Array 4, RAID 10 (10xSATA) All Datafiles
>> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >> >
>> >> > Although I have also looked at:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> > Array 4, RAID 10 (6xSATA) All Datafiles
>> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >> >
>> >> > And:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS
>> >> > Array 2, RAID 1 (2xSCSI) PageFile
>> >> > Array 3, RAID 1 (2xSCSI) TempDB
>> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >> >
>> >> > ...I'll be doing some further reading, but just wondered if anyone
>> >> > had
>> >> > any
>> >> > input on this?
>> >> >
>> >> > Thanks in advance Ben
>> >>
>> >>
>> >>
>>|||Smashing thanks Greg, in the original configuration I have 2 transaction logs
sharing an array... ...these logs don't grow above 250mb over 15minutes...
...but I'm wondering whether it's worth splitting them out onto seperate
arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
room... ...but I've read it's best to seperate Transaction Logs onto
seperate arrays so they can be sequential... ...I'm unsure if the benefit of
having them on seperate disks would be less than having the 10 disks in the
RAID 10 array... ...I guess it's one of those things I'll find out with some
testing :-) Anyway thanks again for the responses..
"Greg Linwood" wrote:
> OK, I just wanted to check up on these points first, because they're often
> missed with new SQL server implementations.
> Back to your original qns then:
> Firstly, drop the idea of a seperate Array for your page file b/c well
> configured, dedicated database servers should perform very little IO against
> page files. Page files are for machines where many processes need to share
> virtual memory & dedicated servers generally do very little of this -
> certainly not enought to warrant dedicating an array to. Far better to
> dedicate this array to a tlog or some other useful purpose
> Seperating objects down to the granularity you've outlined in the last
> option. The problem with this approach is that you're making assumptions
> about how your IO should be partitioned where it's often far easier to leave
> these objects on a single array & let SQL Server spread the load accross
> them. Another way of looking at this scenario is that if any one object type
> experiences heavy IO, it has fewer disks to achieve its workload with.
> Short of more specific information about the actual workload performed by
> the various DB objects, I'd say that your initial configuration is a very
> good starting point.
> Regards,
> Greg Linwood
> SQL Server MVP
>
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> > I'm
> > trying to compensate with disks and find the best raid config I can...
> >
> > "Greg Linwood" wrote:
> >
> >> Hi Ben
> >>
> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32
> >> bit
> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
> >> Standard
> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> >> Memory.
> >>
> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> >> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> >> > ...so
> >> > more memory wasn't really an option.. ..the cost of disks are cheap in
> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> >> > purchase
> >> > the processor licenses. We haven't actually purchased the disks yet,
> >> > if
> >> > there's only a small benefit between say 12 and 18 disks we'll only buy
> >> > the
> >> > 12...
> >> >
> >> > "Greg Linwood" wrote:
> >> >
> >> >> Hi Ben
> >> >>
> >> >> Why did you buy so many disks & such a small amount of memory? Are you
> >> >> using
> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
> >> >> quite
> >> >> important factors as they define your memory constraints & influence
> >> >> whether
> >> >> you should configure any of your disks for specialist read / write
> >> >> activity.
> >> >> The less memory you have, the more you push IO down to your disk
> >> >> sub-system..
> >> >>
> >> >> Regards,
> >> >> Greg Linwood
> >> >> SQL Server MVP
> >> >>
> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >> >
> >> >> > We have just bought a new box for our SQL Database's.. ..We have
> >> >> > three
> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> >> > application
> >> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and
> >> >> > the
> >> >> > transaction log gets up to about 750mb - 1gb before it's backed up
> >> >> > every
> >> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
> >> >> > 20gb
> >> >> > database contains 15gb of BLOB's.
> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
> >> >> > disks
> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
> >> >> > Smart
> >> >> > Array.
> >> >> >
> >> >> > My initial views for the RAID configuration were as follows:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >> >
> >> >> > Although I have also looked at:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >> >
> >> >> > And:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS
> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >> >
> >> >> > ...I'll be doing some further reading, but just wondered if anyone
> >> >> > had
> >> >> > any
> >> >> > input on this?
> >> >> >
> >> >> > Thanks in advance Ben
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>|||Hi Ben
I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
quite moderate & you could probably find better uses for those disks.
Speaking of which - one thing I missed when I first looked at your
suggestions is that you don't have a local drive for backups. Are you
planning to do these off onto a network or tape? If not, I suggest you don't
forget a backup volume in your plan & those extra disks might come in handy
for this purpose...
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
> Smashing thanks Greg, in the original configuration I have 2 transaction
> logs
> sharing an array... ...these logs don't grow above 250mb over 15minutes...
> ...but I'm wondering whether it's worth splitting them out onto seperate
> arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> room... ...but I've read it's best to seperate Transaction Logs onto
> seperate arrays so they can be sequential... ...I'm unsure if the benefit
> of
> having them on seperate disks would be less than having the 10 disks in
> the
> RAID 10 array... ...I guess it's one of those things I'll find out with
> some
> testing :-) Anyway thanks again for the responses..
> "Greg Linwood" wrote:
>> OK, I just wanted to check up on these points first, because they're
>> often
>> missed with new SQL server implementations.
>> Back to your original qns then:
>> Firstly, drop the idea of a seperate Array for your page file b/c well
>> configured, dedicated database servers should perform very little IO
>> against
>> page files. Page files are for machines where many processes need to
>> share
>> virtual memory & dedicated servers generally do very little of this -
>> certainly not enought to warrant dedicating an array to. Far better to
>> dedicate this array to a tlog or some other useful purpose
>> Seperating objects down to the granularity you've outlined in the last
>> option. The problem with this approach is that you're making assumptions
>> about how your IO should be partitioned where it's often far easier to
>> leave
>> these objects on a single array & let SQL Server spread the load accross
>> them. Another way of looking at this scenario is that if any one object
>> type
>> experiences heavy IO, it has fewer disks to achieve its workload with.
>> Short of more specific information about the actual workload performed by
>> the various DB objects, I'd say that your initial configuration is a very
>> good starting point.
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>>
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
>> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows...
>> > ...hence
>> > I'm
>> > trying to compensate with disks and find the best raid config I can...
>> >
>> > "Greg Linwood" wrote:
>> >
>> >> Hi Ben
>> >>
>> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 &
>> >> 32
>> >> bit
>> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
>> >> Standard
>> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to
>> >> 32Gb
>> >> Memory.
>> >>
>> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
>> >>
>> >> Regards,
>> >> Greg Linwood
>> >> SQL Server MVP
>> >>
>> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>> >> > We're using Windows 2003 Standard Edition, and SQL Standard
>> >> > Edition...
>> >> > ...so
>> >> > more memory wasn't really an option.. ..the cost of disks are cheap
>> >> > in
>> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
>> >> > purchase
>> >> > the processor licenses. We haven't actually purchased the disks
>> >> > yet,
>> >> > if
>> >> > there's only a small benefit between say 12 and 18 disks we'll only
>> >> > buy
>> >> > the
>> >> > 12...
>> >> >
>> >> > "Greg Linwood" wrote:
>> >> >
>> >> >> Hi Ben
>> >> >>
>> >> >> Why did you buy so many disks & such a small amount of memory? Are
>> >> >> you
>> >> >> using
>> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually
>> >> >> all
>> >> >> quite
>> >> >> important factors as they define your memory constraints &
>> >> >> influence
>> >> >> whether
>> >> >> you should configure any of your disks for specialist read / write
>> >> >> activity.
>> >> >> The less memory you have, the more you push IO down to your disk
>> >> >> sub-system..
>> >> >>
>> >> >> Regards,
>> >> >> Greg Linwood
>> >> >> SQL Server MVP
>> >> >>
>> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >> >> >
>> >> >> > We have just bought a new box for our SQL Database's.. ..We have
>> >> >> > three
>> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
>> >> >> > application
>> >> >> > database and is around 20gb.. ..it uses the temp db heavily..
>> >> >> > ..and
>> >> >> > the
>> >> >> > transaction log gets up to about 750mb - 1gb before it's backed
>> >> >> > up
>> >> >> > every
>> >> >> > 15minutes. The other databases are 20gb and 10gb respectively,
>> >> >> > the
>> >> >> > 20gb
>> >> >> > database contains 15gb of BLOB's.
>> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have
>> >> >> > 18
>> >> >> > disks
>> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in
>> >> >> > a
>> >> >> > Smart
>> >> >> > Array.
>> >> >> >
>> >> >> > My initial views for the RAID configuration were as follows:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
>> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >> >> >
>> >> >> > Although I have also looked at:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
>> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >> >> >
>> >> >> > And:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS
>> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
>> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >> >> >
>> >> >> > ...I'll be doing some further reading, but just wondered if
>> >> >> > anyone
>> >> >> > had
>> >> >> > any
>> >> >> > input on this?
>> >> >> >
>> >> >> > Thanks in advance Ben
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>|||We currently backup over the network and then onto tape.. ..but it's worth
thinking about, thanks again for the help :-)
"Greg Linwood" wrote:
> Hi Ben
> I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
> quite moderate & you could probably find better uses for those disks.
> Speaking of which - one thing I missed when I first looked at your
> suggestions is that you don't have a local drive for backups. Are you
> planning to do these off onto a network or tape? If not, I suggest you don't
> forget a backup volume in your plan & those extra disks might come in handy
> for this purpose...
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
> > Smashing thanks Greg, in the original configuration I have 2 transaction
> > logs
> > sharing an array... ...these logs don't grow above 250mb over 15minutes...
> > ...but I'm wondering whether it's worth splitting them out onto seperate
> > arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> > room... ...but I've read it's best to seperate Transaction Logs onto
> > seperate arrays so they can be sequential... ...I'm unsure if the benefit
> > of
> > having them on seperate disks would be less than having the 10 disks in
> > the
> > RAID 10 array... ...I guess it's one of those things I'll find out with
> > some
> > testing :-) Anyway thanks again for the responses..
> >
> > "Greg Linwood" wrote:
> >
> >> OK, I just wanted to check up on these points first, because they're
> >> often
> >> missed with new SQL server implementations.
> >>
> >> Back to your original qns then:
> >>
> >> Firstly, drop the idea of a seperate Array for your page file b/c well
> >> configured, dedicated database servers should perform very little IO
> >> against
> >> page files. Page files are for machines where many processes need to
> >> share
> >> virtual memory & dedicated servers generally do very little of this -
> >> certainly not enought to warrant dedicating an array to. Far better to
> >> dedicate this array to a tlog or some other useful purpose
> >>
> >> Seperating objects down to the granularity you've outlined in the last
> >> option. The problem with this approach is that you're making assumptions
> >> about how your IO should be partitioned where it's often far easier to
> >> leave
> >> these objects on a single array & let SQL Server spread the load accross
> >> them. Another way of looking at this scenario is that if any one object
> >> type
> >> experiences heavy IO, it has fewer disks to achieve its workload with.
> >>
> >> Short of more specific information about the actual workload performed by
> >> the various DB objects, I'd say that your initial configuration is a very
> >> good starting point.
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> >> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows...
> >> > ...hence
> >> > I'm
> >> > trying to compensate with disks and find the best raid config I can...
> >> >
> >> > "Greg Linwood" wrote:
> >> >
> >> >> Hi Ben
> >> >>
> >> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 &
> >> >> 32
> >> >> bit
> >> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
> >> >> Standard
> >> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to
> >> >> 32Gb
> >> >> Memory.
> >> >>
> >> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
> >> >>
> >> >> Regards,
> >> >> Greg Linwood
> >> >> SQL Server MVP
> >> >>
> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> >> >> > We're using Windows 2003 Standard Edition, and SQL Standard
> >> >> > Edition...
> >> >> > ...so
> >> >> > more memory wasn't really an option.. ..the cost of disks are cheap
> >> >> > in
> >> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> >> >> > purchase
> >> >> > the processor licenses. We haven't actually purchased the disks
> >> >> > yet,
> >> >> > if
> >> >> > there's only a small benefit between say 12 and 18 disks we'll only
> >> >> > buy
> >> >> > the
> >> >> > 12...
> >> >> >
> >> >> > "Greg Linwood" wrote:
> >> >> >
> >> >> >> Hi Ben
> >> >> >>
> >> >> >> Why did you buy so many disks & such a small amount of memory? Are
> >> >> >> you
> >> >> >> using
> >> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually
> >> >> >> all
> >> >> >> quite
> >> >> >> important factors as they define your memory constraints &
> >> >> >> influence
> >> >> >> whether
> >> >> >> you should configure any of your disks for specialist read / write
> >> >> >> activity.
> >> >> >> The less memory you have, the more you push IO down to your disk
> >> >> >> sub-system..
> >> >> >>
> >> >> >> Regards,
> >> >> >> Greg Linwood
> >> >> >> SQL Server MVP
> >> >> >>
> >> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >> >> >
> >> >> >> > We have just bought a new box for our SQL Database's.. ..We have
> >> >> >> > three
> >> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> >> >> > application
> >> >> >> > database and is around 20gb.. ..it uses the temp db heavily..
> >> >> >> > ..and
> >> >> >> > the
> >> >> >> > transaction log gets up to about 750mb - 1gb before it's backed
> >> >> >> > up
> >> >> >> > every
> >> >> >> > 15minutes. The other databases are 20gb and 10gb respectively,
> >> >> >> > the
> >> >> >> > 20gb
> >> >> >> > database contains 15gb of BLOB's.
> >> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have
> >> >> >> > 18
> >> >> >> > disks
> >> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in
> >> >> >> > a
> >> >> >> > Smart
> >> >> >> > Array.
> >> >> >> >
> >> >> >> > My initial views for the RAID configuration were as follows:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >> >> >
> >> >> >> > Although I have also looked at:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >> >> >
> >> >> >> > And:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS
> >> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >> >> >
> >> >> >> > ...I'll be doing some further reading, but just wondered if
> >> >> >> > anyone
> >> >> >> > had
> >> >> >> > any
> >> >> >> > input on this?
> >> >> >> >
> >> >> >> > Thanks in advance Ben
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
database's, 1 is by far the most intensive, it's a 3rd party application
database and is around 20gb.. ..it uses the temp db heavily.. ..and the
transaction log gets up to about 750mb - 1gb before it's backed up every
15minutes. The other databases are 20gb and 10gb respectively, the 20gb
database contains 15gb of BLOB's.
The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
Array.
My initial views for the RAID configuration were as follows:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (10xSATA) All Datafiles
Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
Although I have also looked at:
Array 1, RAID 1 (2xSCSI) OS & Pagefile
Array 2, RAID 1 (2xSCSI) TempDB
Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
Array 4, RAID 10 (6xSATA) All Datafiles
Array 5, RAID 10 (2xSATA) File containing BLOB's
Array 6, RAID 1 (2xSATA) Transaction Log 2
Array 7, RAID 1 (2xSATA) Transaction Log 3
And:
Array 1, RAID 1 (2xSCSI) OS
Array 2, RAID 1 (2xSCSI) PageFile
Array 3, RAID 1 (2xSCSI) TempDB
Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
Array 6, RAID 1 (2xSATA) File containing BLOB's
Array 7, RAID 1 (2xSATA) Transaction Log 1
Array 8, RAID 1 (2xSATA) Transaction Log 2
Array 9, RAID 1 (2xSATA) Transaction Log 3
...I'll be doing some further reading, but just wondered if anyone had any
input on this?
Thanks in advance BenHi Ben
Why did you buy so many disks & such a small amount of memory? Are you using
SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
important factors as they define your memory constraints & influence whether
you should configure any of your disks for specialist read / write activity.
The less memory you have, the more you push IO down to your disk
sub-system..
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> We have just bought a new box for our SQL Database's.. ..We have three
> database's, 1 is by far the most intensive, it's a 3rd party application
> database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> transaction log gets up to about 750mb - 1gb before it's backed up every
> 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> database contains 15gb of BLOB's.
> The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> Array.
> My initial views for the RAID configuration were as follows:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (10xSATA) All Datafiles
> Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> Although I have also looked at:
> Array 1, RAID 1 (2xSCSI) OS & Pagefile
> Array 2, RAID 1 (2xSCSI) TempDB
> Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> Array 4, RAID 10 (6xSATA) All Datafiles
> Array 5, RAID 10 (2xSATA) File containing BLOB's
> Array 6, RAID 1 (2xSATA) Transaction Log 2
> Array 7, RAID 1 (2xSATA) Transaction Log 3
> And:
> Array 1, RAID 1 (2xSCSI) OS
> Array 2, RAID 1 (2xSCSI) PageFile
> Array 3, RAID 1 (2xSCSI) TempDB
> Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> Array 6, RAID 1 (2xSATA) File containing BLOB's
> Array 7, RAID 1 (2xSATA) Transaction Log 1
> Array 8, RAID 1 (2xSATA) Transaction Log 2
> Array 9, RAID 1 (2xSATA) Transaction Log 3
> ...I'll be doing some further reading, but just wondered if anyone had any
> input on this?
> Thanks in advance Ben|||We're using Windows 2003 Standard Edition, and SQL Standard Edition... ...so
more memory wasn't really an option.. ..the cost of disks are cheap in
comparison to the upgrade to Enterprise Edition of SQL - we have to purchase
the processor licenses. We haven't actually purchased the disks yet, if
there's only a small benefit between say 12 and 18 disks we'll only buy the
12...
"Greg Linwood" wrote:
> Hi Ben
> Why did you buy so many disks & such a small amount of memory? Are you using
> SQL 2000 or SQL 2005? Which version of Windows? These are actually all quite
> important factors as they define your memory constraints & influence whether
> you should configure any of your disks for specialist read / write activity.
> The less memory you have, the more you push IO down to your disk
> sub-system..
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >
> > We have just bought a new box for our SQL Database's.. ..We have three
> > database's, 1 is by far the most intensive, it's a 3rd party application
> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> > transaction log gets up to about 750mb - 1gb before it's backed up every
> > 15minutes. The other databases are 20gb and 10gb respectively, the 20gb
> > database contains 15gb of BLOB's.
> > The box we have bought has dual xeons and 4gb of RAM, and we have 18 disks
> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a Smart
> > Array.
> >
> > My initial views for the RAID configuration were as follows:
> >
> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> > Array 2, RAID 1 (2xSCSI) TempDB
> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> > Array 4, RAID 10 (10xSATA) All Datafiles
> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >
> > Although I have also looked at:
> >
> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> > Array 2, RAID 1 (2xSCSI) TempDB
> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> > Array 4, RAID 10 (6xSATA) All Datafiles
> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >
> > And:
> >
> > Array 1, RAID 1 (2xSCSI) OS
> > Array 2, RAID 1 (2xSCSI) PageFile
> > Array 3, RAID 1 (2xSCSI) TempDB
> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >
> > ...I'll be doing some further reading, but just wondered if anyone had any
> > input on this?
> >
> > Thanks in advance Ben
>
>|||Hi Ben
This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
Memory.
That's why I asked whether you're using SQL 2000 or SQL 2005.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> ...so
> more memory wasn't really an option.. ..the cost of disks are cheap in
> comparison to the upgrade to Enterprise Edition of SQL - we have to
> purchase
> the processor licenses. We haven't actually purchased the disks yet, if
> there's only a small benefit between say 12 and 18 disks we'll only buy
> the
> 12...
> "Greg Linwood" wrote:
>> Hi Ben
>> Why did you buy so many disks & such a small amount of memory? Are you
>> using
>> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
>> quite
>> important factors as they define your memory constraints & influence
>> whether
>> you should configure any of your disks for specialist read / write
>> activity.
>> The less memory you have, the more you push IO down to your disk
>> sub-system..
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >
>> > We have just bought a new box for our SQL Database's.. ..We have three
>> > database's, 1 is by far the most intensive, it's a 3rd party
>> > application
>> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
>> > transaction log gets up to about 750mb - 1gb before it's backed up
>> > every
>> > 15minutes. The other databases are 20gb and 10gb respectively, the
>> > 20gb
>> > database contains 15gb of BLOB's.
>> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
>> > disks
>> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
>> > Smart
>> > Array.
>> >
>> > My initial views for the RAID configuration were as follows:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> > Array 2, RAID 1 (2xSCSI) TempDB
>> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> > Array 4, RAID 10 (10xSATA) All Datafiles
>> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >
>> > Although I have also looked at:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> > Array 2, RAID 1 (2xSCSI) TempDB
>> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> > Array 4, RAID 10 (6xSATA) All Datafiles
>> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >
>> > And:
>> >
>> > Array 1, RAID 1 (2xSCSI) OS
>> > Array 2, RAID 1 (2xSCSI) PageFile
>> > Array 3, RAID 1 (2xSCSI) TempDB
>> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >
>> > ...I'll be doing some further reading, but just wondered if anyone had
>> > any
>> > input on this?
>> >
>> > Thanks in advance Ben
>>|||Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence I'm
trying to compensate with disks and find the best raid config I can...
"Greg Linwood" wrote:
> Hi Ben
> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32 bit
> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server Standard
> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> Memory.
> That's why I asked whether you're using SQL 2000 or SQL 2005.
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> > ...so
> > more memory wasn't really an option.. ..the cost of disks are cheap in
> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> > purchase
> > the processor licenses. We haven't actually purchased the disks yet, if
> > there's only a small benefit between say 12 and 18 disks we'll only buy
> > the
> > 12...
> >
> > "Greg Linwood" wrote:
> >
> >> Hi Ben
> >>
> >> Why did you buy so many disks & such a small amount of memory? Are you
> >> using
> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
> >> quite
> >> important factors as they define your memory constraints & influence
> >> whether
> >> you should configure any of your disks for specialist read / write
> >> activity.
> >> The less memory you have, the more you push IO down to your disk
> >> sub-system..
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >
> >> > We have just bought a new box for our SQL Database's.. ..We have three
> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> > application
> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and the
> >> > transaction log gets up to about 750mb - 1gb before it's backed up
> >> > every
> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
> >> > 20gb
> >> > database contains 15gb of BLOB's.
> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
> >> > disks
> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
> >> > Smart
> >> > Array.
> >> >
> >> > My initial views for the RAID configuration were as follows:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >
> >> > Although I have also looked at:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >
> >> > And:
> >> >
> >> > Array 1, RAID 1 (2xSCSI) OS
> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >
> >> > ...I'll be doing some further reading, but just wondered if anyone had
> >> > any
> >> > input on this?
> >> >
> >> > Thanks in advance Ben
> >>
> >>
> >>
>
>|||OK, I just wanted to check up on these points first, because they're often
missed with new SQL server implementations.
Back to your original qns then:
Firstly, drop the idea of a seperate Array for your page file b/c well
configured, dedicated database servers should perform very little IO against
page files. Page files are for machines where many processes need to share
virtual memory & dedicated servers generally do very little of this -
certainly not enought to warrant dedicating an array to. Far better to
dedicate this array to a tlog or some other useful purpose
Seperating objects down to the granularity you've outlined in the last
option. The problem with this approach is that you're making assumptions
about how your IO should be partitioned where it's often far easier to leave
these objects on a single array & let SQL Server spread the load accross
them. Another way of looking at this scenario is that if any one object type
experiences heavy IO, it has fewer disks to achieve its workload with.
Short of more specific information about the actual workload performed by
the various DB objects, I'd say that your initial configuration is a very
good starting point.
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> I'm
> trying to compensate with disks and find the best raid config I can...
> "Greg Linwood" wrote:
>> Hi Ben
>> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32
>> bit
>> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
>> Standard
>> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
>> Memory.
>> That's why I asked whether you're using SQL 2000 or SQL 2005.
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
>> > ...so
>> > more memory wasn't really an option.. ..the cost of disks are cheap in
>> > comparison to the upgrade to Enterprise Edition of SQL - we have to
>> > purchase
>> > the processor licenses. We haven't actually purchased the disks yet,
>> > if
>> > there's only a small benefit between say 12 and 18 disks we'll only buy
>> > the
>> > 12...
>> >
>> > "Greg Linwood" wrote:
>> >
>> >> Hi Ben
>> >>
>> >> Why did you buy so many disks & such a small amount of memory? Are you
>> >> using
>> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
>> >> quite
>> >> important factors as they define your memory constraints & influence
>> >> whether
>> >> you should configure any of your disks for specialist read / write
>> >> activity.
>> >> The less memory you have, the more you push IO down to your disk
>> >> sub-system..
>> >>
>> >> Regards,
>> >> Greg Linwood
>> >> SQL Server MVP
>> >>
>> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >> >
>> >> > We have just bought a new box for our SQL Database's.. ..We have
>> >> > three
>> >> > database's, 1 is by far the most intensive, it's a 3rd party
>> >> > application
>> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and
>> >> > the
>> >> > transaction log gets up to about 750mb - 1gb before it's backed up
>> >> > every
>> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
>> >> > 20gb
>> >> > database contains 15gb of BLOB's.
>> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
>> >> > disks
>> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
>> >> > Smart
>> >> > Array.
>> >> >
>> >> > My initial views for the RAID configuration were as follows:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> > Array 4, RAID 10 (10xSATA) All Datafiles
>> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >> >
>> >> > Although I have also looked at:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> > Array 4, RAID 10 (6xSATA) All Datafiles
>> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >> >
>> >> > And:
>> >> >
>> >> > Array 1, RAID 1 (2xSCSI) OS
>> >> > Array 2, RAID 1 (2xSCSI) PageFile
>> >> > Array 3, RAID 1 (2xSCSI) TempDB
>> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >> >
>> >> > ...I'll be doing some further reading, but just wondered if anyone
>> >> > had
>> >> > any
>> >> > input on this?
>> >> >
>> >> > Thanks in advance Ben
>> >>
>> >>
>> >>
>>|||Smashing thanks Greg, in the original configuration I have 2 transaction logs
sharing an array... ...these logs don't grow above 250mb over 15minutes...
...but I'm wondering whether it's worth splitting them out onto seperate
arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
room... ...but I've read it's best to seperate Transaction Logs onto
seperate arrays so they can be sequential... ...I'm unsure if the benefit of
having them on seperate disks would be less than having the 10 disks in the
RAID 10 array... ...I guess it's one of those things I'll find out with some
testing :-) Anyway thanks again for the responses..
"Greg Linwood" wrote:
> OK, I just wanted to check up on these points first, because they're often
> missed with new SQL server implementations.
> Back to your original qns then:
> Firstly, drop the idea of a seperate Array for your page file b/c well
> configured, dedicated database servers should perform very little IO against
> page files. Page files are for machines where many processes need to share
> virtual memory & dedicated servers generally do very little of this -
> certainly not enought to warrant dedicating an array to. Far better to
> dedicate this array to a tlog or some other useful purpose
> Seperating objects down to the granularity you've outlined in the last
> option. The problem with this approach is that you're making assumptions
> about how your IO should be partitioned where it's often far easier to leave
> these objects on a single array & let SQL Server spread the load accross
> them. Another way of looking at this scenario is that if any one object type
> experiences heavy IO, it has fewer disks to achieve its workload with.
> Short of more specific information about the actual workload performed by
> the various DB objects, I'd say that your initial configuration is a very
> good starting point.
> Regards,
> Greg Linwood
> SQL Server MVP
>
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows... ...hence
> > I'm
> > trying to compensate with disks and find the best raid config I can...
> >
> > "Greg Linwood" wrote:
> >
> >> Hi Ben
> >>
> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 & 32
> >> bit
> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
> >> Standard
> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to 32Gb
> >> Memory.
> >>
> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> >> > We're using Windows 2003 Standard Edition, and SQL Standard Edition...
> >> > ...so
> >> > more memory wasn't really an option.. ..the cost of disks are cheap in
> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> >> > purchase
> >> > the processor licenses. We haven't actually purchased the disks yet,
> >> > if
> >> > there's only a small benefit between say 12 and 18 disks we'll only buy
> >> > the
> >> > 12...
> >> >
> >> > "Greg Linwood" wrote:
> >> >
> >> >> Hi Ben
> >> >>
> >> >> Why did you buy so many disks & such a small amount of memory? Are you
> >> >> using
> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually all
> >> >> quite
> >> >> important factors as they define your memory constraints & influence
> >> >> whether
> >> >> you should configure any of your disks for specialist read / write
> >> >> activity.
> >> >> The less memory you have, the more you push IO down to your disk
> >> >> sub-system..
> >> >>
> >> >> Regards,
> >> >> Greg Linwood
> >> >> SQL Server MVP
> >> >>
> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >> >
> >> >> > We have just bought a new box for our SQL Database's.. ..We have
> >> >> > three
> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> >> > application
> >> >> > database and is around 20gb.. ..it uses the temp db heavily.. ..and
> >> >> > the
> >> >> > transaction log gets up to about 750mb - 1gb before it's backed up
> >> >> > every
> >> >> > 15minutes. The other databases are 20gb and 10gb respectively, the
> >> >> > 20gb
> >> >> > database contains 15gb of BLOB's.
> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have 18
> >> >> > disks
> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in a
> >> >> > Smart
> >> >> > Array.
> >> >> >
> >> >> > My initial views for the RAID configuration were as follows:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >> >
> >> >> > Although I have also looked at:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >> >
> >> >> > And:
> >> >> >
> >> >> > Array 1, RAID 1 (2xSCSI) OS
> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >> >
> >> >> > ...I'll be doing some further reading, but just wondered if anyone
> >> >> > had
> >> >> > any
> >> >> > input on this?
> >> >> >
> >> >> > Thanks in advance Ben
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>|||Hi Ben
I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
quite moderate & you could probably find better uses for those disks.
Speaking of which - one thing I missed when I first looked at your
suggestions is that you don't have a local drive for backups. Are you
planning to do these off onto a network or tape? If not, I suggest you don't
forget a backup volume in your plan & those extra disks might come in handy
for this purpose...
Regards,
Greg Linwood
SQL Server MVP
"BenUK" <BenUK@.discussions.microsoft.com> wrote in message
news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
> Smashing thanks Greg, in the original configuration I have 2 transaction
> logs
> sharing an array... ...these logs don't grow above 250mb over 15minutes...
> ...but I'm wondering whether it's worth splitting them out onto seperate
> arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> room... ...but I've read it's best to seperate Transaction Logs onto
> seperate arrays so they can be sequential... ...I'm unsure if the benefit
> of
> having them on seperate disks would be less than having the 10 disks in
> the
> RAID 10 array... ...I guess it's one of those things I'll find out with
> some
> testing :-) Anyway thanks again for the responses..
> "Greg Linwood" wrote:
>> OK, I just wanted to check up on these points first, because they're
>> often
>> missed with new SQL server implementations.
>> Back to your original qns then:
>> Firstly, drop the idea of a seperate Array for your page file b/c well
>> configured, dedicated database servers should perform very little IO
>> against
>> page files. Page files are for machines where many processes need to
>> share
>> virtual memory & dedicated servers generally do very little of this -
>> certainly not enought to warrant dedicating an array to. Far better to
>> dedicate this array to a tlog or some other useful purpose
>> Seperating objects down to the granularity you've outlined in the last
>> option. The problem with this approach is that you're making assumptions
>> about how your IO should be partitioned where it's often far easier to
>> leave
>> these objects on a single array & let SQL Server spread the load accross
>> them. Another way of looking at this scenario is that if any one object
>> type
>> experiences heavy IO, it has fewer disks to achieve its workload with.
>> Short of more specific information about the actual workload performed by
>> the various DB objects, I'd say that your initial configuration is a very
>> good starting point.
>> Regards,
>> Greg Linwood
>> SQL Server MVP
>>
>> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
>> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows...
>> > ...hence
>> > I'm
>> > trying to compensate with disks and find the best raid config I can...
>> >
>> > "Greg Linwood" wrote:
>> >
>> >> Hi Ben
>> >>
>> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 &
>> >> 32
>> >> bit
>> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
>> >> Standard
>> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to
>> >> 32Gb
>> >> Memory.
>> >>
>> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
>> >>
>> >> Regards,
>> >> Greg Linwood
>> >> SQL Server MVP
>> >>
>> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
>> >> > We're using Windows 2003 Standard Edition, and SQL Standard
>> >> > Edition...
>> >> > ...so
>> >> > more memory wasn't really an option.. ..the cost of disks are cheap
>> >> > in
>> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
>> >> > purchase
>> >> > the processor licenses. We haven't actually purchased the disks
>> >> > yet,
>> >> > if
>> >> > there's only a small benefit between say 12 and 18 disks we'll only
>> >> > buy
>> >> > the
>> >> > 12...
>> >> >
>> >> > "Greg Linwood" wrote:
>> >> >
>> >> >> Hi Ben
>> >> >>
>> >> >> Why did you buy so many disks & such a small amount of memory? Are
>> >> >> you
>> >> >> using
>> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually
>> >> >> all
>> >> >> quite
>> >> >> important factors as they define your memory constraints &
>> >> >> influence
>> >> >> whether
>> >> >> you should configure any of your disks for specialist read / write
>> >> >> activity.
>> >> >> The less memory you have, the more you push IO down to your disk
>> >> >> sub-system..
>> >> >>
>> >> >> Regards,
>> >> >> Greg Linwood
>> >> >> SQL Server MVP
>> >> >>
>> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
>> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
>> >> >> >
>> >> >> > We have just bought a new box for our SQL Database's.. ..We have
>> >> >> > three
>> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
>> >> >> > application
>> >> >> > database and is around 20gb.. ..it uses the temp db heavily..
>> >> >> > ..and
>> >> >> > the
>> >> >> > transaction log gets up to about 750mb - 1gb before it's backed
>> >> >> > up
>> >> >> > every
>> >> >> > 15minutes. The other databases are 20gb and 10gb respectively,
>> >> >> > the
>> >> >> > 20gb
>> >> >> > database contains 15gb of BLOB's.
>> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have
>> >> >> > 18
>> >> >> > disks
>> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in
>> >> >> > a
>> >> >> > Smart
>> >> >> > Array.
>> >> >> >
>> >> >> > My initial views for the RAID configuration were as follows:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
>> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
>> >> >> >
>> >> >> > Although I have also looked at:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
>> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
>> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
>> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
>> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
>> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
>> >> >> >
>> >> >> > And:
>> >> >> >
>> >> >> > Array 1, RAID 1 (2xSCSI) OS
>> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
>> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
>> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
>> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
>> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
>> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
>> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
>> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
>> >> >> >
>> >> >> > ...I'll be doing some further reading, but just wondered if
>> >> >> > anyone
>> >> >> > had
>> >> >> > any
>> >> >> > input on this?
>> >> >> >
>> >> >> > Thanks in advance Ben
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>|||We currently backup over the network and then onto tape.. ..but it's worth
thinking about, thanks again for the help :-)
"Greg Linwood" wrote:
> Hi Ben
> I suggest you don't seperate those logs out then, as 250Mb in 15 mins is
> quite moderate & you could probably find better uses for those disks.
> Speaking of which - one thing I missed when I first looked at your
> suggestions is that you don't have a local drive for backups. Are you
> planning to do these off onto a network or tape? If not, I suggest you don't
> forget a backup volume in your plan & those extra disks might come in handy
> for this purpose...
> Regards,
> Greg Linwood
> SQL Server MVP
> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> news:ADDF9C2C-FC93-447F-9F44-E554316C36F6@.microsoft.com...
> > Smashing thanks Greg, in the original configuration I have 2 transaction
> > logs
> > sharing an array... ...these logs don't grow above 250mb over 15minutes...
> > ...but I'm wondering whether it's worth splitting them out onto seperate
> > arrays? - I'd have to drop the RAID 10 array from 10 to 8 disks to make
> > room... ...but I've read it's best to seperate Transaction Logs onto
> > seperate arrays so they can be sequential... ...I'm unsure if the benefit
> > of
> > having them on seperate disks would be less than having the 10 disks in
> > the
> > RAID 10 array... ...I guess it's one of those things I'll find out with
> > some
> > testing :-) Anyway thanks again for the responses..
> >
> > "Greg Linwood" wrote:
> >
> >> OK, I just wanted to check up on these points first, because they're
> >> often
> >> missed with new SQL server implementations.
> >>
> >> Back to your original qns then:
> >>
> >> Firstly, drop the idea of a seperate Array for your page file b/c well
> >> configured, dedicated database servers should perform very little IO
> >> against
> >> page files. Page files are for machines where many processes need to
> >> share
> >> virtual memory & dedicated servers generally do very little of this -
> >> certainly not enought to warrant dedicating an array to. Far better to
> >> dedicate this array to a tlog or some other useful purpose
> >>
> >> Seperating objects down to the granularity you've outlined in the last
> >> option. The problem with this approach is that you're making assumptions
> >> about how your IO should be partitioned where it's often far easier to
> >> leave
> >> these objects on a single array & let SQL Server spread the load accross
> >> them. Another way of looking at this scenario is that if any one object
> >> type
> >> experiences heavy IO, it has fewer disks to achieve its workload with.
> >>
> >> Short of more specific information about the actual workload performed by
> >> the various DB objects, I'd say that your initial configuration is a very
> >> good starting point.
> >>
> >> Regards,
> >> Greg Linwood
> >> SQL Server MVP
> >>
> >>
> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> news:94A8EB85-786A-415D-BA47-8E75777744A1@.microsoft.com...
> >> > Memory isn't an option, it's 32bit SQL 2000 on 32bit windows...
> >> > ...hence
> >> > I'm
> >> > trying to compensate with disks and find the best raid config I can...
> >> >
> >> > "Greg Linwood" wrote:
> >> >
> >> >> Hi Ben
> >> >>
> >> >> This depends entirely on whether you're using SQL 2000 or SQL 2005 &
> >> >> 32
> >> >> bit
> >> >> vs 64 bit. For example, if you're using 64 bit Windows 2003 Server
> >> >> Standard
> >> >> Edition and 64 bit SQL 2005 Standard Edition, you can access up to
> >> >> 32Gb
> >> >> Memory.
> >> >>
> >> >> That's why I asked whether you're using SQL 2000 or SQL 2005.
> >> >>
> >> >> Regards,
> >> >> Greg Linwood
> >> >> SQL Server MVP
> >> >>
> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> news:12B8799F-C62C-4D25-BD05-2122305040A9@.microsoft.com...
> >> >> > We're using Windows 2003 Standard Edition, and SQL Standard
> >> >> > Edition...
> >> >> > ...so
> >> >> > more memory wasn't really an option.. ..the cost of disks are cheap
> >> >> > in
> >> >> > comparison to the upgrade to Enterprise Edition of SQL - we have to
> >> >> > purchase
> >> >> > the processor licenses. We haven't actually purchased the disks
> >> >> > yet,
> >> >> > if
> >> >> > there's only a small benefit between say 12 and 18 disks we'll only
> >> >> > buy
> >> >> > the
> >> >> > 12...
> >> >> >
> >> >> > "Greg Linwood" wrote:
> >> >> >
> >> >> >> Hi Ben
> >> >> >>
> >> >> >> Why did you buy so many disks & such a small amount of memory? Are
> >> >> >> you
> >> >> >> using
> >> >> >> SQL 2000 or SQL 2005? Which version of Windows? These are actually
> >> >> >> all
> >> >> >> quite
> >> >> >> important factors as they define your memory constraints &
> >> >> >> influence
> >> >> >> whether
> >> >> >> you should configure any of your disks for specialist read / write
> >> >> >> activity.
> >> >> >> The less memory you have, the more you push IO down to your disk
> >> >> >> sub-system..
> >> >> >>
> >> >> >> Regards,
> >> >> >> Greg Linwood
> >> >> >> SQL Server MVP
> >> >> >>
> >> >> >> "BenUK" <BenUK@.discussions.microsoft.com> wrote in message
> >> >> >> news:5109C752-1078-4576-B5EF-F7929AB104DE@.microsoft.com...
> >> >> >> >
> >> >> >> > We have just bought a new box for our SQL Database's.. ..We have
> >> >> >> > three
> >> >> >> > database's, 1 is by far the most intensive, it's a 3rd party
> >> >> >> > application
> >> >> >> > database and is around 20gb.. ..it uses the temp db heavily..
> >> >> >> > ..and
> >> >> >> > the
> >> >> >> > transaction log gets up to about 750mb - 1gb before it's backed
> >> >> >> > up
> >> >> >> > every
> >> >> >> > 15minutes. The other databases are 20gb and 10gb respectively,
> >> >> >> > the
> >> >> >> > 20gb
> >> >> >> > database contains 15gb of BLOB's.
> >> >> >> > The box we have bought has dual xeons and 4gb of RAM, and we have
> >> >> >> > 18
> >> >> >> > disks
> >> >> >> > to play with, 6 SCSI's @.15krpm in the box and 12 @.7.2rpm SATA in
> >> >> >> > a
> >> >> >> > Smart
> >> >> >> > Array.
> >> >> >> >
> >> >> >> > My initial views for the RAID configuration were as follows:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> >> > Array 4, RAID 10 (10xSATA) All Datafiles
> >> >> >> > Array 5, RAID 1 (2xSATA) Remaining 2 Transaction Logs
> >> >> >> >
> >> >> >> > Although I have also looked at:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS & Pagefile
> >> >> >> > Array 2, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 3, RAID 1 (2xSCSI) The intensive database's transaction log
> >> >> >> > Array 4, RAID 10 (6xSATA) All Datafiles
> >> >> >> > Array 5, RAID 10 (2xSATA) File containing BLOB's
> >> >> >> > Array 6, RAID 1 (2xSATA) Transaction Log 2
> >> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 3
> >> >> >> >
> >> >> >> > And:
> >> >> >> >
> >> >> >> > Array 1, RAID 1 (2xSCSI) OS
> >> >> >> > Array 2, RAID 1 (2xSCSI) PageFile
> >> >> >> > Array 3, RAID 1 (2xSCSI) TempDB
> >> >> >> > Array 4, RAID 1 (2xSATA) Clustered Index's of all DB's
> >> >> >> > Array 5, RAID 1 (2xSATA) Non-Clustered Index's of all DB's
> >> >> >> > Array 6, RAID 1 (2xSATA) File containing BLOB's
> >> >> >> > Array 7, RAID 1 (2xSATA) Transaction Log 1
> >> >> >> > Array 8, RAID 1 (2xSATA) Transaction Log 2
> >> >> >> > Array 9, RAID 1 (2xSATA) Transaction Log 3
> >> >> >> >
> >> >> >> > ...I'll be doing some further reading, but just wondered if
> >> >> >> > anyone
> >> >> >> > had
> >> >> >> > any
> >> >> >> > input on this?
> >> >> >> >
> >> >> >> > Thanks in advance Ben
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
Subscribe to:
Posts (Atom)