I'm in setup new server mode so I'm just checking a few things.
Say you had 8, 12 or 16 disks purely for data (log on other disks).
Do you think it's best to create a single big raid 10 set for a single
filegroup with a single database file.
Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
indexes and data or even by tables that are hit heavy (not easy to get right
when you have 100's of tables)
Create 2 or more raid 10 sets and have a single filegroup that owns a file
on each raid 10 set.
I know this is application specific but when you have a complex system you
could spend forever trying to work out the details.
Raid 10 will give me the megs per second but I was thinking maybe I'd be
better splitting the data up to get the transactions per second.
Paul
On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
<xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>I'm in setup new server mode so I'm just checking a few things.
>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>Do you think it's best to create a single big raid 10 set for a single
>filegroup with a single database file.
Why so many disks? Is the database humongous?
>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>indexes and data or even by tables that are hit heavy (not easy to get right
>when you have 100's of tables)
>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>on each raid 10 set.
>I know this is application specific
Right.
> but when you have a complex system you
>could spend forever trying to work out the details.
>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>better splitting the data up to get the transactions per second.
One big, fat RAID 10 will probably get you 80% of peak performance
with 20% of the bother. You can use SQLServer filegroups to optimize
wihin, if you like. Two more more smaller RAIDS might help, depending
on the app, depending on whether you NEED more help!
J.
|||Hi,
We should remember that the more heads/spindals you have for the RAID
the better the performance. With the disk technology today and the RPM
speeds I think you could get away with a large RAID and splice it up on
the OS level into different drives/devices.
Just a note from my SysAdmin days [those were the days ;-].
Shahryar
jxstern wrote:
>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>
>Why so many disks? Is the database humongous?
>
>
>Right.
>
>
>One big, fat RAID 10 will probably get you 80% of peak performance
>with 20% of the bother. You can use SQLServer filegroups to optimize
>wihin, if you like. Two more more smaller RAIDS might help, depending
>on the app, depending on whether you NEED more help!
>J.
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohi
bited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.
|||Lot's of disks because we are i/o bound on our current system and because
they are relatively cheap compared to the price of staff for one thing.
I could spend days and days fine tuning what tables/indexes get hit, when
and by whom. There are over 500 users and their usage can be quite
heterogeneous at times.
I've always thought raid 5 should be avoided, therefore raid 10.
I have prepared the system with fat raid 10's but I was thinking maybe I was
getting obsessed with i/o throughput and not thinking about random access.
All the heads on an array will be rushing to the same stripe at the same
time and then on to the next requested block of data.
However, say I had two smaller raid 10 sets then maybe I'd get a higher
transaction throughput although a slighly lower data rate per transaction.
Shahryar, I know you are correct. These new disks are blindingly quick but
disks haven't come on as much as cpu and memory speeds in the last few
years. They have mainly got bigger which is not necessarily best for rdbms.
Paul
"Shahryar G. Hashemi" <shahryar.hashemi@.infospace.com> wrote in message
news:eDAnkYM4FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> We should remember that the more heads/spindals you have for the RAID the
> better the performance. With the disk technology today and the RPM speeds
> I think you could get away with a large RAID and splice it up on the OS
> level into different drives/devices.
> Just a note from my SysAdmin days [those were the days ;-].
> Shahryar
> jxstern wrote:
>
> --
> Shahryar G. Hashemi | Sr. DBA Consultant InfoSpace, Inc. 601 108th Ave NE
> | Suite 1200 | Bellevue, WA 98004 USA Mobile +1 206.459.6203 | Office
> +1 425.201.8853 | Fax +1 425.201.6150 shashem@.infospace.com |
> www.infospaceinc.com
> This e-mail and any attachments may contain confidential information that
> is legally privileged. The information is solely for the use of the
> intended recipient(s); any disclosure, copying, distribution, or other use
> of this information is strictly prohibited. If you have received this
> e-mail in error, please notify the sender by return e-mail and delete this
> message. Thank you.
sql
Showing posts with label mode. Show all posts
Showing posts with label mode. Show all posts
Wednesday, March 28, 2012
Raid 10 with lots of disks. Where to place datafiles
I'm in setup new server mode so I'm just checking a few things.
Say you had 8, 12 or 16 disks purely for data (log on other disks).
Do you think it's best to create a single big raid 10 set for a single
filegroup with a single database file.
Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
indexes and data or even by tables that are hit heavy (not easy to get right
when you have 100's of tables)
Create 2 or more raid 10 sets and have a single filegroup that owns a file
on each raid 10 set.
I know this is application specific but when you have a complex system you
could spend forever trying to work out the details.
Raid 10 will give me the megs per second but I was thinking maybe I'd be
better splitting the data up to get the transactions per second.
PaulOn Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
<xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>I'm in setup new server mode so I'm just checking a few things.
>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>Do you think it's best to create a single big raid 10 set for a single
>filegroup with a single database file.
Why so many disks? Is the database humongous?
>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>indexes and data or even by tables that are hit heavy (not easy to get right
>when you have 100's of tables)
>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>on each raid 10 set.
>I know this is application specific
Right.
> but when you have a complex system you
>could spend forever trying to work out the details.
>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>better splitting the data up to get the transactions per second.
One big, fat RAID 10 will probably get you 80% of peak performance
with 20% of the bother. You can use SQLServer filegroups to optimize
wihin, if you like. Two more more smaller RAIDS might help, depending
on the app, depending on whether you NEED more help!
J.|||Hi,
We should remember that the more heads/spindals you have for the RAID
the better the performance. With the disk technology today and the RPM
speeds I think you could get away with a large RAID and splice it up on
the OS level into different drives/devices.
Just a note from my SysAdmin days [those were the days ;-].
Shahryar
jxstern wrote:
>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>
>>I'm in setup new server mode so I'm just checking a few things.
>>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>>Do you think it's best to create a single big raid 10 set for a single
>>filegroup with a single database file.
>>
>Why so many disks? Is the database humongous?
>
>>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>>indexes and data or even by tables that are hit heavy (not easy to get right
>>when you have 100's of tables)
>>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>>on each raid 10 set.
>>I know this is application specific
>>
>Right.
>
>> but when you have a complex system you
>>could spend forever trying to work out the details.
>>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>>better splitting the data up to get the transactions per second.
>>
>One big, fat RAID 10 will probably get you 80% of peak performance
>with 20% of the bother. You can use SQLServer filegroups to optimize
>wihin, if you like. Two more more smaller RAIDS might help, depending
>on the app, depending on whether you NEED more help!
>J.
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.|||Lot's of disks because we are i/o bound on our current system and because
they are relatively cheap compared to the price of staff for one thing.
I could spend days and days fine tuning what tables/indexes get hit, when
and by whom. There are over 500 users and their usage can be quite
heterogeneous at times.
I've always thought raid 5 should be avoided, therefore raid 10.
I have prepared the system with fat raid 10's but I was thinking maybe I was
getting obsessed with i/o throughput and not thinking about random access.
All the heads on an array will be rushing to the same stripe at the same
time and then on to the next requested block of data.
However, say I had two smaller raid 10 sets then maybe I'd get a higher
transaction throughput although a slighly lower data rate per transaction.
Shahryar, I know you are correct. These new disks are blindingly quick but
disks haven't come on as much as cpu and memory speeds in the last few
years. They have mainly got bigger which is not necessarily best for rdbms.
Paul
"Shahryar G. Hashemi" <shahryar.hashemi@.infospace.com> wrote in message
news:eDAnkYM4FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> We should remember that the more heads/spindals you have for the RAID the
> better the performance. With the disk technology today and the RPM speeds
> I think you could get away with a large RAID and splice it up on the OS
> level into different drives/devices.
> Just a note from my SysAdmin days [those were the days ;-].
> Shahryar
> jxstern wrote:
>>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
>><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>>I'm in setup new server mode so I'm just checking a few things.
>>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>>Do you think it's best to create a single big raid 10 set for a single
>>filegroup with a single database file.
>>
>>Why so many disks? Is the database humongous?
>>
>>Create 2 or more raid 10 sets and split the data in a controlled manner.
>>Eg indexes and data or even by tables that are hit heavy (not easy to get
>>right when you have 100's of tables)
>>Create 2 or more raid 10 sets and have a single filegroup that owns a
>>file on each raid 10 set.
>>I know this is application specific
>>Right.
>>
>> but when you have a complex system
>> you could spend forever trying to work out the details.
>>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>>better splitting the data up to get the transactions per second.
>>
>>One big, fat RAID 10 will probably get you 80% of peak performance
>>with 20% of the bother. You can use SQLServer filegroups to optimize
>>wihin, if you like. Two more more smaller RAIDS might help, depending
>>on the app, depending on whether you NEED more help!
>>J.
>>
>
> --
> Shahryar G. Hashemi | Sr. DBA Consultant InfoSpace, Inc. 601 108th Ave NE
> | Suite 1200 | Bellevue, WA 98004 USA Mobile +1 206.459.6203 | Office
> +1 425.201.8853 | Fax +1 425.201.6150 shashem@.infospace.com |
> www.infospaceinc.com
> This e-mail and any attachments may contain confidential information that
> is legally privileged. The information is solely for the use of the
> intended recipient(s); any disclosure, copying, distribution, or other use
> of this information is strictly prohibited. If you have received this
> e-mail in error, please notify the sender by return e-mail and delete this
> message. Thank you.
Say you had 8, 12 or 16 disks purely for data (log on other disks).
Do you think it's best to create a single big raid 10 set for a single
filegroup with a single database file.
Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
indexes and data or even by tables that are hit heavy (not easy to get right
when you have 100's of tables)
Create 2 or more raid 10 sets and have a single filegroup that owns a file
on each raid 10 set.
I know this is application specific but when you have a complex system you
could spend forever trying to work out the details.
Raid 10 will give me the megs per second but I was thinking maybe I'd be
better splitting the data up to get the transactions per second.
PaulOn Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
<xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>I'm in setup new server mode so I'm just checking a few things.
>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>Do you think it's best to create a single big raid 10 set for a single
>filegroup with a single database file.
Why so many disks? Is the database humongous?
>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>indexes and data or even by tables that are hit heavy (not easy to get right
>when you have 100's of tables)
>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>on each raid 10 set.
>I know this is application specific
Right.
> but when you have a complex system you
>could spend forever trying to work out the details.
>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>better splitting the data up to get the transactions per second.
One big, fat RAID 10 will probably get you 80% of peak performance
with 20% of the bother. You can use SQLServer filegroups to optimize
wihin, if you like. Two more more smaller RAIDS might help, depending
on the app, depending on whether you NEED more help!
J.|||Hi,
We should remember that the more heads/spindals you have for the RAID
the better the performance. With the disk technology today and the RPM
speeds I think you could get away with a large RAID and splice it up on
the OS level into different drives/devices.
Just a note from my SysAdmin days [those were the days ;-].
Shahryar
jxstern wrote:
>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>
>>I'm in setup new server mode so I'm just checking a few things.
>>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>>Do you think it's best to create a single big raid 10 set for a single
>>filegroup with a single database file.
>>
>Why so many disks? Is the database humongous?
>
>>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>>indexes and data or even by tables that are hit heavy (not easy to get right
>>when you have 100's of tables)
>>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>>on each raid 10 set.
>>I know this is application specific
>>
>Right.
>
>> but when you have a complex system you
>>could spend forever trying to work out the details.
>>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>>better splitting the data up to get the transactions per second.
>>
>One big, fat RAID 10 will probably get you 80% of peak performance
>with 20% of the bother. You can use SQLServer filegroups to optimize
>wihin, if you like. Two more more smaller RAIDS might help, depending
>on the app, depending on whether you NEED more help!
>J.
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.|||Lot's of disks because we are i/o bound on our current system and because
they are relatively cheap compared to the price of staff for one thing.
I could spend days and days fine tuning what tables/indexes get hit, when
and by whom. There are over 500 users and their usage can be quite
heterogeneous at times.
I've always thought raid 5 should be avoided, therefore raid 10.
I have prepared the system with fat raid 10's but I was thinking maybe I was
getting obsessed with i/o throughput and not thinking about random access.
All the heads on an array will be rushing to the same stripe at the same
time and then on to the next requested block of data.
However, say I had two smaller raid 10 sets then maybe I'd get a higher
transaction throughput although a slighly lower data rate per transaction.
Shahryar, I know you are correct. These new disks are blindingly quick but
disks haven't come on as much as cpu and memory speeds in the last few
years. They have mainly got bigger which is not necessarily best for rdbms.
Paul
"Shahryar G. Hashemi" <shahryar.hashemi@.infospace.com> wrote in message
news:eDAnkYM4FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> We should remember that the more heads/spindals you have for the RAID the
> better the performance. With the disk technology today and the RPM speeds
> I think you could get away with a large RAID and splice it up on the OS
> level into different drives/devices.
> Just a note from my SysAdmin days [those were the days ;-].
> Shahryar
> jxstern wrote:
>>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
>><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>>I'm in setup new server mode so I'm just checking a few things.
>>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>>Do you think it's best to create a single big raid 10 set for a single
>>filegroup with a single database file.
>>
>>Why so many disks? Is the database humongous?
>>
>>Create 2 or more raid 10 sets and split the data in a controlled manner.
>>Eg indexes and data or even by tables that are hit heavy (not easy to get
>>right when you have 100's of tables)
>>Create 2 or more raid 10 sets and have a single filegroup that owns a
>>file on each raid 10 set.
>>I know this is application specific
>>Right.
>>
>> but when you have a complex system
>> you could spend forever trying to work out the details.
>>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>>better splitting the data up to get the transactions per second.
>>
>>One big, fat RAID 10 will probably get you 80% of peak performance
>>with 20% of the bother. You can use SQLServer filegroups to optimize
>>wihin, if you like. Two more more smaller RAIDS might help, depending
>>on the app, depending on whether you NEED more help!
>>J.
>>
>
> --
> Shahryar G. Hashemi | Sr. DBA Consultant InfoSpace, Inc. 601 108th Ave NE
> | Suite 1200 | Bellevue, WA 98004 USA Mobile +1 206.459.6203 | Office
> +1 425.201.8853 | Fax +1 425.201.6150 shashem@.infospace.com |
> www.infospaceinc.com
> This e-mail and any attachments may contain confidential information that
> is legally privileged. The information is solely for the use of the
> intended recipient(s); any disclosure, copying, distribution, or other use
> of this information is strictly prohibited. If you have received this
> e-mail in error, please notify the sender by return e-mail and delete this
> message. Thank you.
Raid 10 with lots of disks. Where to place datafiles
I'm in setup new server mode so I'm just checking a few things.
Say you had 8, 12 or 16 disks purely for data (log on other disks).
Do you think it's best to create a single big raid 10 set for a single
filegroup with a single database file.
Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
indexes and data or even by tables that are hit heavy (not easy to get right
when you have 100's of tables)
Create 2 or more raid 10 sets and have a single filegroup that owns a file
on each raid 10 set.
I know this is application specific but when you have a complex system you
could spend forever trying to work out the details.
Raid 10 will give me the megs per second but I was thinking maybe I'd be
better splitting the data up to get the transactions per second.
PaulOn Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
<xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>I'm in setup new server mode so I'm just checking a few things.
>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>Do you think it's best to create a single big raid 10 set for a single
>filegroup with a single database file.
Why so many disks? Is the database humongous?
>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>indexes and data or even by tables that are hit heavy (not easy to get righ
t
>when you have 100's of tables)
>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>on each raid 10 set.
>I know this is application specific
Right.
> but when you have a complex system you
>could spend forever trying to work out the details.
>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>better splitting the data up to get the transactions per second.
One big, fat RAID 10 will probably get you 80% of peak performance
with 20% of the bother. You can use SQLServer filegroups to optimize
wihin, if you like. Two more more smaller RAIDS might help, depending
on the app, depending on whether you NEED more help!
J.|||Hi,
We should remember that the more heads/spindals you have for the RAID
the better the performance. With the disk technology today and the RPM
speeds I think you could get away with a large RAID and splice it up on
the OS level into different drives/devices.
Just a note from my SysAdmin days [those were the days ;-].
Shahryar
jxstern wrote:
>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>
>Why so many disks? Is the database humongous?
>
>
>Right.
>
>
>One big, fat RAID 10 will probably get you 80% of peak performance
>with 20% of the bother. You can use SQLServer filegroups to optimize
>wihin, if you like. Two more more smaller RAIDS might help, depending
>on the app, depending on whether you NEED more help!
>J.
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is
legally privileged. The information is solely for the use of the intended
recipient(s); any disclosure, copying, distribution, or other use of this in
formation is strictly prohi
bited. If you have received this e-mail in error, please notify the sender
by return e-mail and delete this message. Thank you.|||Lot's of disks because we are i/o bound on our current system and because
they are relatively cheap compared to the price of staff for one thing.
I could spend days and days fine tuning what tables/indexes get hit, when
and by whom. There are over 500 users and their usage can be quite
heterogeneous at times.
I've always thought raid 5 should be avoided, therefore raid 10.
I have prepared the system with fat raid 10's but I was thinking maybe I was
getting obsessed with i/o throughput and not thinking about random access.
All the heads on an array will be rushing to the same stripe at the same
time and then on to the next requested block of data.
However, say I had two smaller raid 10 sets then maybe I'd get a higher
transaction throughput although a slighly lower data rate per transaction.
Shahryar, I know you are correct. These new disks are blindingly quick but
disks haven't come on as much as cpu and memory speeds in the last few
years. They have mainly got bigger which is not necessarily best for rdbms.
Paul
"Shahryar G. Hashemi" <shahryar.hashemi@.infospace.com> wrote in message
news:eDAnkYM4FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> We should remember that the more heads/spindals you have for the RAID the
> better the performance. With the disk technology today and the RPM speeds
> I think you could get away with a large RAID and splice it up on the OS
> level into different drives/devices.
> Just a note from my SysAdmin days [those were the days ;-].
> Shahryar
> jxstern wrote:
>
>
> --
> Shahryar G. Hashemi | Sr. DBA Consultant InfoSpace, Inc. 601 108th Ave NE
> | Suite 1200 | Bellevue, WA 98004 USA Mobile +1 206.459.6203 | Office
> +1 425.201.8853 | Fax +1 425.201.6150 shashem@.infospace.com |
> www.infospaceinc.com
> This e-mail and any attachments may contain confidential information that
> is legally privileged. The information is solely for the use of the
> intended recipient(s); any disclosure, copying, distribution, or other use
> of this information is strictly prohibited. If you have received this
> e-mail in error, please notify the sender by return e-mail and delete this
> message. Thank you.
Say you had 8, 12 or 16 disks purely for data (log on other disks).
Do you think it's best to create a single big raid 10 set for a single
filegroup with a single database file.
Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
indexes and data or even by tables that are hit heavy (not easy to get right
when you have 100's of tables)
Create 2 or more raid 10 sets and have a single filegroup that owns a file
on each raid 10 set.
I know this is application specific but when you have a complex system you
could spend forever trying to work out the details.
Raid 10 will give me the megs per second but I was thinking maybe I'd be
better splitting the data up to get the transactions per second.
PaulOn Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
<xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>I'm in setup new server mode so I'm just checking a few things.
>Say you had 8, 12 or 16 disks purely for data (log on other disks).
>Do you think it's best to create a single big raid 10 set for a single
>filegroup with a single database file.
Why so many disks? Is the database humongous?
>Create 2 or more raid 10 sets and split the data in a controlled manner. Eg
>indexes and data or even by tables that are hit heavy (not easy to get righ
t
>when you have 100's of tables)
>Create 2 or more raid 10 sets and have a single filegroup that owns a file
>on each raid 10 set.
>I know this is application specific
Right.
> but when you have a complex system you
>could spend forever trying to work out the details.
>Raid 10 will give me the megs per second but I was thinking maybe I'd be
>better splitting the data up to get the transactions per second.
One big, fat RAID 10 will probably get you 80% of peak performance
with 20% of the bother. You can use SQLServer filegroups to optimize
wihin, if you like. Two more more smaller RAIDS might help, depending
on the app, depending on whether you NEED more help!
J.|||Hi,
We should remember that the more heads/spindals you have for the RAID
the better the performance. With the disk technology today and the RPM
speeds I think you could get away with a large RAID and splice it up on
the OS level into different drives/devices.
Just a note from my SysAdmin days [those were the days ;-].
Shahryar
jxstern wrote:
>On Thu, 3 Nov 2005 19:26:24 -0000, "Paul Cahill"
><xyzpaul.xyzcahill@.dsl.pipex.com> wrote:
>
>Why so many disks? Is the database humongous?
>
>
>Right.
>
>
>One big, fat RAID 10 will probably get you 80% of peak performance
>with 20% of the bother. You can use SQLServer filegroups to optimize
>wihin, if you like. Two more more smaller RAIDS might help, depending
>on the app, depending on whether you NEED more help!
>J.
>
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is
legally privileged. The information is solely for the use of the intended
recipient(s); any disclosure, copying, distribution, or other use of this in
formation is strictly prohi
bited. If you have received this e-mail in error, please notify the sender
by return e-mail and delete this message. Thank you.|||Lot's of disks because we are i/o bound on our current system and because
they are relatively cheap compared to the price of staff for one thing.
I could spend days and days fine tuning what tables/indexes get hit, when
and by whom. There are over 500 users and their usage can be quite
heterogeneous at times.
I've always thought raid 5 should be avoided, therefore raid 10.
I have prepared the system with fat raid 10's but I was thinking maybe I was
getting obsessed with i/o throughput and not thinking about random access.
All the heads on an array will be rushing to the same stripe at the same
time and then on to the next requested block of data.
However, say I had two smaller raid 10 sets then maybe I'd get a higher
transaction throughput although a slighly lower data rate per transaction.
Shahryar, I know you are correct. These new disks are blindingly quick but
disks haven't come on as much as cpu and memory speeds in the last few
years. They have mainly got bigger which is not necessarily best for rdbms.
Paul
"Shahryar G. Hashemi" <shahryar.hashemi@.infospace.com> wrote in message
news:eDAnkYM4FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> We should remember that the more heads/spindals you have for the RAID the
> better the performance. With the disk technology today and the RPM speeds
> I think you could get away with a large RAID and splice it up on the OS
> level into different drives/devices.
> Just a note from my SysAdmin days [those were the days ;-].
> Shahryar
> jxstern wrote:
>
>
> --
> Shahryar G. Hashemi | Sr. DBA Consultant InfoSpace, Inc. 601 108th Ave NE
> | Suite 1200 | Bellevue, WA 98004 USA Mobile +1 206.459.6203 | Office
> +1 425.201.8853 | Fax +1 425.201.6150 shashem@.infospace.com |
> www.infospaceinc.com
> This e-mail and any attachments may contain confidential information that
> is legally privileged. The information is solely for the use of the
> intended recipient(s); any disclosure, copying, distribution, or other use
> of this information is strictly prohibited. If you have received this
> e-mail in error, please notify the sender by return e-mail and delete this
> message. Thank you.
Friday, March 9, 2012
Quick question about security and MS SQL 2000
OK, we have a couple of MS SQL 2000 servers running in a Win2k AD domain.
Both machines are using mixed mode security, the issue appears to be this.
If I go into AD and change a groups name that has been granted access to
the SQL server, it doesn't seem to pick up on the name change.
I also can't add the new name to the SQL server, because of a conflict of a
SID.
So how do I get the MS SQL server to refresh the names of the native NT
groups that have been granted access, then have the names changed ??I think you need to drop the old name and add the new one. Why are you doing this? Experimenting?|||Its not uncommon to have a native AD Security group renamed to match
a changed "department" name lets say.
SQL 2000 doesn't seem to see the name change in AD, where is this info stored in
the SQL server ?? is there a SP to refresh the cache or this table ?|||I'd say changing a department name should result in a change of an OU, not a group. But that's just me.
Both machines are using mixed mode security, the issue appears to be this.
If I go into AD and change a groups name that has been granted access to
the SQL server, it doesn't seem to pick up on the name change.
I also can't add the new name to the SQL server, because of a conflict of a
SID.
So how do I get the MS SQL server to refresh the names of the native NT
groups that have been granted access, then have the names changed ??I think you need to drop the old name and add the new one. Why are you doing this? Experimenting?|||Its not uncommon to have a native AD Security group renamed to match
a changed "department" name lets say.
SQL 2000 doesn't seem to see the name change in AD, where is this info stored in
the SQL server ?? is there a SP to refresh the cache or this table ?|||I'd say changing a department name should result in a change of an OU, not a group. But that's just me.
Wednesday, March 7, 2012
Quick Question
I have a client that's insisting on deploying SQL Server 2000 as Windows Authntication mode only (not mixed mode). I've always done mixed mode in the past and I'm just looking for some input here. So, what's everyone think?Either form of authentication will do. If NT Authentication will do everything that the client needs, it is certainly a workable solution.
NT Authentication is more secure than SQL Authentication, but it means that you need better "digital plumbing" to make it work, especially over a WAN. You need more bandwidth, more complex router/link settings, a more capable firewall, etc. If you have these things, and can absolutely rely on them, then NT Authentication is simpler and safer than SQL Authentication from a SQL user/administrator perspective.
-PatP|||I suppose my assumption was that I'd issue access based on Windows Auth, but I had intended on leaving it in mixed mode for those times when sa has to step in. Should I ignore SQL Auth altogether, or leave sa as the only SQL Auth user as an "in case of emergency break glass" user?
Thanks in advance!|||As long as you have an NT Admin, you really don't need sa for much of anything. The only case I can see where you might want sa is if you need to dial in remotely, and can't support NT Authentication. That is a considerable stretch of the imagination, and if you have VPN access or an on-site administrator it isn't even relevant.
-PatP|||I have only one small problem with the Windows Authentication. Suppose you have a Web server that runs several websites. All of those websites would have to log into the SQL Server as a single account under Windows Authentication. Namely, the windows account that the web service runs under (at least, with my simple understanding of IIS). This has the rather unfortunate effect of making all of the databases only as secure as the least secure website. If you have a single page on a single one of these websites that allows SQL Injection, then all of the security on all of the other websites is quite simply cooked. Microsoft has a very unsettling attitude towards security on SQL Server. They keep banging the "Least Privilege" model drum, but put out applications like SMS and Sharepoint that blatantly break that model.
NT Authentication is more secure than SQL Authentication, but it means that you need better "digital plumbing" to make it work, especially over a WAN. You need more bandwidth, more complex router/link settings, a more capable firewall, etc. If you have these things, and can absolutely rely on them, then NT Authentication is simpler and safer than SQL Authentication from a SQL user/administrator perspective.
-PatP|||I suppose my assumption was that I'd issue access based on Windows Auth, but I had intended on leaving it in mixed mode for those times when sa has to step in. Should I ignore SQL Auth altogether, or leave sa as the only SQL Auth user as an "in case of emergency break glass" user?
Thanks in advance!|||As long as you have an NT Admin, you really don't need sa for much of anything. The only case I can see where you might want sa is if you need to dial in remotely, and can't support NT Authentication. That is a considerable stretch of the imagination, and if you have VPN access or an on-site administrator it isn't even relevant.
-PatP|||I have only one small problem with the Windows Authentication. Suppose you have a Web server that runs several websites. All of those websites would have to log into the SQL Server as a single account under Windows Authentication. Namely, the windows account that the web service runs under (at least, with my simple understanding of IIS). This has the rather unfortunate effect of making all of the databases only as secure as the least secure website. If you have a single page on a single one of these websites that allows SQL Injection, then all of the security on all of the other websites is quite simply cooked. Microsoft has a very unsettling attitude towards security on SQL Server. They keep banging the "Least Privilege" model drum, but put out applications like SMS and Sharepoint that blatantly break that model.
Subscribe to:
Posts (Atom)