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

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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>

r_irtbl* stored procedures in msdb

Using SQL 2000 and noticed some r_irtbl* stored procedures in msdb. Are they
part of SQL or part of some 3rd party tool ? I believe its part of SQL as it
seems to be there on all our SQL Servers. IF so, what is it used for ?Have a look here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/repospr/rpconnecting_220j.asp
--
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:eaucM5tiDHA.1808@.TK2MSFTNGP09.phx.gbl...
> Using SQL 2000 and noticed some r_irtbl* stored procedures in msdb. Are
they
> part of SQL or part of some 3rd party tool ? I believe its part of SQL as
it
> seems to be there on all our SQL Servers. IF so, what is it used for ?
>

Quick SQL Server 2000 Locking question

We are running a 3rd party ETL tool to populate a denormailized version of a production database for reports. Everything works fine 95% of the time. However there is a semi-rare occurence of the ETL tool hanging up. The norm is for the tool to take about 5 times longer than usual, but it still works. Over the weekend however it through an error saying:

The SQL Server cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users or ask the system administrator to check the SQL Server lock and memory configuration.

The reports are run through Crystal using stored procs and are all basically select statements

So my question(s) are the following:
1. What kind of lock would a report put on a table (select statement)
2. Would it make sense to change stored procs to use WITH NOLOCK?
3. Or is something else going on?

Your thoughts would be greatly appreciated.1) Select statements put shared locks on tables. These allow other readers, but block writers to the locked portions of the tables. Shared locks are blocked by existing Exclusive locks.

2) If you like partial results, using (nolock) is perfectly fine. I wouldn't suggest it to an accountant, though.

3) Could be, but you would need to monitor the process as it is running to be certain.|||Here is response I received from 3rd party ETL tool:
Tables/rows seem to be locked by another application or process. We have seen users do this with DBArtisan or Query Analyzer. They lock the table and can't figure out why DT/Engine appears to hang for hours. When they close whichever application that is locking the tables, DT/Engine finishes up what it was doing and everything goes back to normal. You may have a DBA tool like Query Analyzer open looking at either the source or target data as it moves which would result in a hang as the engine waits for the release.|||The ETL tool does update some Flag fields just to keep track of what's being moved around. My concern is that the reports run lighting fast with none taking more than 1 second.
The slow down (when it occurs) happens on the same task over and over. You could call it a main enitity table, but its not the largest table. However, most of the reports use it. But we are talking about a 3 hour hang-up on the ETL side. There's no way it wouldn't be able to obtain a lock in that time, right?

Just having query analyzer open is not causing this.

Next steps??
1. Keep a trace going with duration set to more than 10 minutes?
2. Try to track down who's doing what on this server (located across the globe)?|||First step is to prove who is blocking and whether there is blocking at all. A three hour block sounds suspiciously like a maintenance job. A three hour slowdown could be SQL Server got starved for memory by some currently unknown process.

Personally, I would spend a night with this thing, to see if I can spot the reason for the slowdown/stoppage. OK, first thing I would do is write scripts to capture the interesting information (the sysprocesses table is a nice place to start. Pay attention to the blocked, waittype, waitresource, and open_tran columns). But then, I am lazy like that.|||Never used sysprocesses table before. Looking at it for first time I notice a few suspect entries. Is this just a current snapshot or does it keep archive info. It only had 3 pertinent rows out of 22.

Quick 6.5 question

Does anyone know the maximum number of rows a SQL 6.5
table can hold..
I've got an old 3rd party app suddenly throwing out lots
of these errors - 'The server could not expand a table
because the table reached the maximum size. '
Thanks in advance.Does the NT event log say, Event ID 2009'
//Ralph
>--Original Message--
>Does anyone know the maximum number of rows a SQL 6.5
>table can hold..
>I've got an old 3rd party app suddenly throwing out lots
>of these errors - 'The server could not expand a table
>because the table reached the maximum size. '
>
>Thanks in advance.
>.
>|||ok,
It doesn't neccessary need to be table in SQL server,
according to articles I found it is when creating a table
in the memory (system).
http://www.eventid.net/display.asp?eventid=2009&source=
The last section of that page you got links and
explanations about the error....
Good Luck.
//Ralph
>--Original Message--
>yes it does..
>
>>--Original Message--
>>Does the NT event log say, Event ID 2009'
>>//Ralph
>>--Original Message--
>>Does anyone know the maximum number of rows a SQL 6.5
>>table can hold..
>>I've got an old 3rd party app suddenly throwing out
lots
>>of these errors - 'The server could not expand a table
>>because the table reached the maximum size. '
>>
>>Thanks in advance.
>>.
>>.
>.
>|||Ralph, thanks - looks like a very useful link...
Cheers, steve
>--Original Message--
>ok,
>It doesn't neccessary need to be table in SQL server,
>according to articles I found it is when creating a table
>in the memory (system).
>http://www.eventid.net/display.asp?eventid=2009&source=
>The last section of that page you got links and
>explanations about the error....
>Good Luck.
>//Ralph
>
>>--Original Message--
>>yes it does..
>>
>>--Original Message--
>>Does the NT event log say, Event ID 2009'
>>//Ralph
>>--Original Message--
>>Does anyone know the maximum number of rows a SQL 6.5
>>table can hold..
>>I've got an old 3rd party app suddenly throwing out
>lots
>>of these errors - 'The server could not expand a table
>>because the table reached the maximum size. '
>>
>>Thanks in advance.
>>.
>>.
>>.
>.
>