Handle Error: array

Showing posts with label array. Show all posts

Monday, March 12, 2012

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAID
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-Dan
Hi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan
|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low in
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAID
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-DanHi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:
> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low in
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:
> We are configuring a new database server at work. I have decided to do a RAID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years by
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to our
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

Hardware planning for growth

We are configuring a new database server at work. I have decided to do a RAI
D
1 Array for the transaction log and a RAID 5 array for the data.
The fastest growing part of our database is a table that stores photos. It
is currently about 12Gb in size. We expect it to grow the next few years by
17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year 5
that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
Although these are rough projections, I still need to be able to begin
planning accordingly.
What is the best hardware configuration to allow this kind of growth? I
would like something that is expandable, so that I can buy according to our
current needs, and add to it as needed.
Any advice is greatly appreciated.
-DanHi
In effect, you can only plan for the next 3-4 years. By then, the current
disk subsystems will need to be retired.
In effect, you need about 150Gb for Data and probably 400Gb for backups
during this period. A few 147Gb drives will do the job nicely.
For best performance have a seperate SCSI controller for the logs, backup
and data drives. You may want to split the data up into 2 drive sets to get
better throughput.
With the size and price of drives, do you really need RAID-5? What about
RAD-10? The write performance is just so much better.
Do you need high abailabilty? If so, you need to look at Windows Clusters.
This will guide you in the direction of the drive enclosure as it will need
to be a SAN. EMC has a few nice babies.
Regards
Mike
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a R
AID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years b
y
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year
5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to ou
r
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan|||Hi Dan,
Statistically speaking the company you are working for will not be in
business in 10 years! Anyhow. Let me tell you what I did for one of our
businesses that had a quad-processor (700 MHZ) server running SQL Server:
1-got a dual processor (3 GHZ) server.
2-Got 15000 RPM drives (50% in disk speed increase right of the bat!)
3-Created 3 RAID 1 arrays: one for OS, one for DB and one of transaction
log. Make sure that your controller supports split seeks, which devides the
read I/Os among the mirrored pair, allowing two disks to seek simultaneously
.
Ideally you can use RAID 10.
4-be carefull with the edition of SQL Server. The server edition will limit
SQL to use a max. of 2 GB. Also, you will not be able to create indexes on
views.
Microsoft SQL Administrator's companion book has a section on Capacity
Planning (for memory, processor, disk-subsystem) that you can have a look.
The problem we had with our quad-processor server was that we had to pay
close to 10,000$ to get 2 more CPUs since they were older CPUs. Note also
that storage often becomes a problem. With 200 servers to maintain by our
team, we often need to plan some upgrades for servers that are running low i
n
HD space (after few years) so make sure you have enough space on your
database server. Last think, it is very hard to load balance a SQL Server
(manual process as far as I know) because chances are that new servers will
get data from your database server in the future and/or the load will
increase.
"Dan" wrote:

> We are configuring a new database server at work. I have decided to do a R
AID
> 1 Array for the transaction log and a RAID 5 array for the data.
> The fastest growing part of our database is a table that stores photos. It
> is currently about 12Gb in size. We expect it to grow the next few years b
y
> 17Gb, 26Gb, 33Gb, then platueau at 37Gb growth a year. At the end of year
5
> that puts us at about 165Gb, and at the end of year 10 at about 500Gb.
> Although these are rough projections, I still need to be able to begin
> planning accordingly.
> What is the best hardware configuration to allow this kind of growth? I
> would like something that is expandable, so that I can buy according to ou
r
> current needs, and add to it as needed.
> Any advice is greatly appreciated.
> -Dan

Hardware Logical Drives or OS Level Partitions?

Is it better to divide an array into multiple partitions (or volumes) at the
OS level or into multiple logical drives at the hardware level? Does it make
any difference to track alignment? Will one give greater future flexibility
over the other?
I have to install SQL Server on an HP Proliant server with 6 drives bays - I
would prefer more, but that is what I have available. I plan to create 3
RAID 1 arrays using the HP Array Configuration Manager to use as follows:
Array 1 (disks 0 & 1)
C:\ OS
S:\ SQL Server Installation
T:\ TempDB
Array 2 (disks 2 & 3)
P:\ Page File
D:\ Data
Array 3 (disks 4 & 5)
L:\ Transaction Logs
X:\ Backups
All partitions will be formatted with NTFS. I plan a stripe and cluster
size of 64KB for the data and TempDB partitions - all the others will be
default sizes. DB backups will be made to a local drive and then backed up
to tape over the network.
This configuration gives good separation for resillience. It should reduce
file fragmentation and I hope will give reasonable performance.
Thanks for any commentsWhy not use disks 2-5 as RAID0+1 and move tempdb to it. You can still create
partitions to split stff up if you want.
Jason Massie
www: http://statisticsio.com
rss: http://feeds.feedburner.com/statisticsio
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> Is it better to divide an array into multiple partitions (or volumes) at
> the
> OS level or into multiple logical drives at the hardware level? Does it
> make
> any difference to track alignment? Will one give greater future
> flexibility
> over the other?
> I have to install SQL Server on an HP Proliant server with 6 drives bays -
> I
> would prefer more, but that is what I have available. I plan to create 3
> RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> Array 1 (disks 0 & 1)
> C:\ OS
> S:\ SQL Server Installation
> T:\ TempDB
> Array 2 (disks 2 & 3)
> P:\ Page File
> D:\ Data
> Array 3 (disks 4 & 5)
> L:\ Transaction Logs
> X:\ Backups
> All partitions will be formatted with NTFS. I plan a stripe and cluster
> size of 64KB for the data and TempDB partitions - all the others will be
> default sizes. DB backups will be made to a local drive and then backed
> up
> to tape over the network.
> This configuration gives good separation for resillience. It should
> reduce
> file fragmentation and I hope will give reasonable performance.
> Thanks for any comments|||Partitioning at the OS level does nothing to enhance or degrade performance.
The underlying RAID container has exactly the same IO capacity no matter how
you partition it. RAID containers can and do segment IO loads and can have
significant impact on performance.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> Is it better to divide an array into multiple partitions (or volumes) at
> the
> OS level or into multiple logical drives at the hardware level? Does it
> make
> any difference to track alignment? Will one give greater future
> flexibility
> over the other?
> I have to install SQL Server on an HP Proliant server with 6 drives bays -
> I
> would prefer more, but that is what I have available. I plan to create 3
> RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> Array 1 (disks 0 & 1)
> C:\ OS
> S:\ SQL Server Installation
> T:\ TempDB
> Array 2 (disks 2 & 3)
> P:\ Page File
> D:\ Data
> Array 3 (disks 4 & 5)
> L:\ Transaction Logs
> X:\ Backups
> All partitions will be formatted with NTFS. I plan a stripe and cluster
> size of 64KB for the data and TempDB partitions - all the others will be
> default sizes. DB backups will be made to a local drive and then backed
> up
> to tape over the network.
> This configuration gives good separation for resillience. It should
> reduce
> file fragmentation and I hope will give reasonable performance.
> Thanks for any comments|||thanks Geoff
by RAID container I take it you mean a logical drive created at hearware
level with the array.
"Geoff N. Hiten" wrote:
> Partitioning at the OS level does nothing to enhance or degrade performance.
> The underlying RAID container has exactly the same IO capacity no matter how
> you partition it. RAID containers can and do segment IO loads and can have
> significant impact on performance.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "andrew" <andrew@.discussions.microsoft.com> wrote in message
> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> > Is it better to divide an array into multiple partitions (or volumes) at
> > the
> > OS level or into multiple logical drives at the hardware level? Does it
> > make
> > any difference to track alignment? Will one give greater future
> > flexibility
> > over the other?
> >
> > I have to install SQL Server on an HP Proliant server with 6 drives bays -
> > I
> > would prefer more, but that is what I have available. I plan to create 3
> > RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> >
> > Array 1 (disks 0 & 1)
> > C:\ OS
> > S:\ SQL Server Installation
> > T:\ TempDB
> >
> > Array 2 (disks 2 & 3)
> > P:\ Page File
> > D:\ Data
> >
> > Array 3 (disks 4 & 5)
> > L:\ Transaction Logs
> > X:\ Backups
> >
> > All partitions will be formatted with NTFS. I plan a stripe and cluster
> > size of 64KB for the data and TempDB partitions - all the others will be
> > default sizes. DB backups will be made to a local drive and then backed
> > up
> > to tape over the network.
> >
> > This configuration gives good separation for resillience. It should
> > reduce
> > file fragmentation and I hope will give reasonable performance.
> >
> > Thanks for any comments
>|||Thanks Jason
I did consider this, but thought I would be better with the separation. Do
you think 1 RAID 10 array would perform better than 2 RAID 1?
"jason" wrote:
> Why not use disks 2-5 as RAID0+1 and move tempdb to it. You can still create
> partitions to split stff up if you want.
>
> --
> Jason Massie
> www: http://statisticsio.com
> rss: http://feeds.feedburner.com/statisticsio
>
> "andrew" <andrew@.discussions.microsoft.com> wrote in message
> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> > Is it better to divide an array into multiple partitions (or volumes) at
> > the
> > OS level or into multiple logical drives at the hardware level? Does it
> > make
> > any difference to track alignment? Will one give greater future
> > flexibility
> > over the other?
> >
> > I have to install SQL Server on an HP Proliant server with 6 drives bays -
> > I
> > would prefer more, but that is what I have available. I plan to create 3
> > RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> >
> > Array 1 (disks 0 & 1)
> > C:\ OS
> > S:\ SQL Server Installation
> > T:\ TempDB
> >
> > Array 2 (disks 2 & 3)
> > P:\ Page File
> > D:\ Data
> >
> > Array 3 (disks 4 & 5)
> > L:\ Transaction Logs
> > X:\ Backups
> >
> > All partitions will be formatted with NTFS. I plan a stripe and cluster
> > size of 64KB for the data and TempDB partitions - all the others will be
> > default sizes. DB backups will be made to a local drive and then backed
> > up
> > to tape over the network.
> >
> > This configuration gives good separation for resillience. It should
> > reduce
> > file fragmentation and I hope will give reasonable performance.
> >
> > Thanks for any comments
>|||Correct.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:D1EA04BC-EA2F-4F42-85B5-4057C9231E5C@.microsoft.com...
> thanks Geoff
> by RAID container I take it you mean a logical drive created at hearware
> level with the array.
> "Geoff N. Hiten" wrote:
>> Partitioning at the OS level does nothing to enhance or degrade
>> performance.
>> The underlying RAID container has exactly the same IO capacity no matter
>> how
>> you partition it. RAID containers can and do segment IO loads and can
>> have
>> significant impact on performance.
>> --
>> Geoff N. Hiten
>> Senior SQL Infrastructure Consultant
>> Microsoft SQL Server MVP
>>
>>
>> "andrew" <andrew@.discussions.microsoft.com> wrote in message
>> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
>> > Is it better to divide an array into multiple partitions (or volumes)
>> > at
>> > the
>> > OS level or into multiple logical drives at the hardware level? Does
>> > it
>> > make
>> > any difference to track alignment? Will one give greater future
>> > flexibility
>> > over the other?
>> >
>> > I have to install SQL Server on an HP Proliant server with 6 drives
>> > bays -
>> > I
>> > would prefer more, but that is what I have available. I plan to create
>> > 3
>> > RAID 1 arrays using the HP Array Configuration Manager to use as
>> > follows:
>> >
>> > Array 1 (disks 0 & 1)
>> > C:\ OS
>> > S:\ SQL Server Installation
>> > T:\ TempDB
>> >
>> > Array 2 (disks 2 & 3)
>> > P:\ Page File
>> > D:\ Data
>> >
>> > Array 3 (disks 4 & 5)
>> > L:\ Transaction Logs
>> > X:\ Backups
>> >
>> > All partitions will be formatted with NTFS. I plan a stripe and
>> > cluster
>> > size of 64KB for the data and TempDB partitions - all the others will
>> > be
>> > default sizes. DB backups will be made to a local drive and then
>> > backed
>> > up
>> > to tape over the network.
>> >
>> > This configuration gives good separation for resillience. It should
>> > reduce
>> > file fragmentation and I hope will give reasonable performance.
>> >
>> > Thanks for any comments
>>|||You said "DB backups will be made to a local drive and then backed up to
tape over the network."
I don't know what way you'll use to copy your backups thru your network
however I just wanted to stress that "BACKUP ... to TAPE" can not be used to
backup a database to a tape which is attached to a remote machine even if it
would be in the same network. The backup tape must be connected directly to
the SQL Server server to backup a database to tape.
Also, storing the OS and SQL Server binaries on the same drive would be OK
If tempdb is used in your environment frequently then you may consider
putting it on a dedicated disk which could be (if you don't need redundancy
or if you don't have enough resource for RAID1) RAID0.
However as Geoff mentioned, it would not make any difference to separate a
disk logically. You need physical disks to gain performance benefit for this
purpose.
You will want to give enough physical file space to your Transaction Log
file and Data files if you want less fragmentation.
--
Ekrem Ã?nsoy
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> Is it better to divide an array into multiple partitions (or volumes) at
> the
> OS level or into multiple logical drives at the hardware level? Does it
> make
> any difference to track alignment? Will one give greater future
> flexibility
> over the other?
> I have to install SQL Server on an HP Proliant server with 6 drives bays -
> I
> would prefer more, but that is what I have available. I plan to create 3
> RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> Array 1 (disks 0 & 1)
> C:\ OS
> S:\ SQL Server Installation
> T:\ TempDB
> Array 2 (disks 2 & 3)
> P:\ Page File
> D:\ Data
> Array 3 (disks 4 & 5)
> L:\ Transaction Logs
> X:\ Backups
> All partitions will be formatted with NTFS. I plan a stripe and cluster
> size of 64KB for the data and TempDB partitions - all the others will be
> default sizes. DB backups will be made to a local drive and then backed
> up
> to tape over the network.
> This configuration gives good separation for resillience. It should
> reduce
> file fragmentation and I hope will give reasonable performance.
> Thanks for any comments|||Thanks Ekrem
Our backup plan is to run SQL backups to disk, then backup these files using
an enterprise backup solution along with system state etc. This eliminates
some of the additional complexities of backing up across the network (the
backup is less likely to fail if there are network problems or the other
server isn't available) and also means we have a local backup if we need it
for a partial restore or corrupt database.
I would love to put TempDB on a separate disk, but that is not possible in
this server as it only has 6 drive bays. I think separating logs and data
probably has a higher priority. I would hesitate to put TempDB on RAID 0 as
it still needs to be present, even if there is no data to preserve, or SQL
Server will fail.
We desperately need to replace some very old hardware right now and we
already have this server. Buying replacement hardware is a project for the
future - that box will have more drives!
"Ekrem Ã?nsoy" wrote:
> You said "DB backups will be made to a local drive and then backed up to
> tape over the network."
> I don't know what way you'll use to copy your backups thru your network
> however I just wanted to stress that "BACKUP ... to TAPE" can not be used to
> backup a database to a tape which is attached to a remote machine even if it
> would be in the same network. The backup tape must be connected directly to
> the SQL Server server to backup a database to tape.
> Also, storing the OS and SQL Server binaries on the same drive would be OK
> If tempdb is used in your environment frequently then you may consider
> putting it on a dedicated disk which could be (if you don't need redundancy
> or if you don't have enough resource for RAID1) RAID0.
> However as Geoff mentioned, it would not make any difference to separate a
> disk logically. You need physical disks to gain performance benefit for this
> purpose.
> You will want to give enough physical file space to your Transaction Log
> file and Data files if you want less fragmentation.
> --
> Ekrem Ã?nsoy
>
> "andrew" <andrew@.discussions.microsoft.com> wrote in message
> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> > Is it better to divide an array into multiple partitions (or volumes) at
> > the
> > OS level or into multiple logical drives at the hardware level? Does it
> > make
> > any difference to track alignment? Will one give greater future
> > flexibility
> > over the other?
> >
> > I have to install SQL Server on an HP Proliant server with 6 drives bays -
> > I
> > would prefer more, but that is what I have available. I plan to create 3
> > RAID 1 arrays using the HP Array Configuration Manager to use as follows:
> >
> > Array 1 (disks 0 & 1)
> > C:\ OS
> > S:\ SQL Server Installation
> > T:\ TempDB
> >
> > Array 2 (disks 2 & 3)
> > P:\ Page File
> > D:\ Data
> >
> > Array 3 (disks 4 & 5)
> > L:\ Transaction Logs
> > X:\ Backups
> >
> > All partitions will be formatted with NTFS. I plan a stripe and cluster
> > size of 64KB for the data and TempDB partitions - all the others will be
> > default sizes. DB backups will be made to a local drive and then backed
> > up
> > to tape over the network.
> >
> > This configuration gives good separation for resillience. It should
> > reduce
> > file fragmentation and I hope will give reasonable performance.
> >
> > Thanks for any comments
>|||Data and Log files have more priority for sure.
--
Ekrem Ã?nsoy
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:13CD654F-8041-424B-903F-60389E725823@.microsoft.com...
> Thanks Ekrem
> Our backup plan is to run SQL backups to disk, then backup these files
> using
> an enterprise backup solution along with system state etc. This
> eliminates
> some of the additional complexities of backing up across the network (the
> backup is less likely to fail if there are network problems or the other
> server isn't available) and also means we have a local backup if we need
> it
> for a partial restore or corrupt database.
> I would love to put TempDB on a separate disk, but that is not possible in
> this server as it only has 6 drive bays. I think separating logs and data
> probably has a higher priority. I would hesitate to put TempDB on RAID 0
> as
> it still needs to be present, even if there is no data to preserve, or SQL
> Server will fail.
> We desperately need to replace some very old hardware right now and we
> already have this server. Buying replacement hardware is a project for
> the
> future - that box will have more drives!
>
> "Ekrem Ã?nsoy" wrote:
>> You said "DB backups will be made to a local drive and then backed up to
>> tape over the network."
>> I don't know what way you'll use to copy your backups thru your network
>> however I just wanted to stress that "BACKUP ... to TAPE" can not be used
>> to
>> backup a database to a tape which is attached to a remote machine even if
>> it
>> would be in the same network. The backup tape must be connected directly
>> to
>> the SQL Server server to backup a database to tape.
>> Also, storing the OS and SQL Server binaries on the same drive would be
>> OK
>> If tempdb is used in your environment frequently then you may consider
>> putting it on a dedicated disk which could be (if you don't need
>> redundancy
>> or if you don't have enough resource for RAID1) RAID0.
>> However as Geoff mentioned, it would not make any difference to separate
>> a
>> disk logically. You need physical disks to gain performance benefit for
>> this
>> purpose.
>> You will want to give enough physical file space to your Transaction Log
>> file and Data files if you want less fragmentation.
>> --
>> Ekrem Ã?nsoy
>>
>> "andrew" <andrew@.discussions.microsoft.com> wrote in message
>> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
>> > Is it better to divide an array into multiple partitions (or volumes)
>> > at
>> > the
>> > OS level or into multiple logical drives at the hardware level? Does
>> > it
>> > make
>> > any difference to track alignment? Will one give greater future
>> > flexibility
>> > over the other?
>> >
>> > I have to install SQL Server on an HP Proliant server with 6 drives
>> > bays -
>> > I
>> > would prefer more, but that is what I have available. I plan to create
>> > 3
>> > RAID 1 arrays using the HP Array Configuration Manager to use as
>> > follows:
>> >
>> > Array 1 (disks 0 & 1)
>> > C:\ OS
>> > S:\ SQL Server Installation
>> > T:\ TempDB
>> >
>> > Array 2 (disks 2 & 3)
>> > P:\ Page File
>> > D:\ Data
>> >
>> > Array 3 (disks 4 & 5)
>> > L:\ Transaction Logs
>> > X:\ Backups
>> >
>> > All partitions will be formatted with NTFS. I plan a stripe and
>> > cluster
>> > size of 64KB for the data and TempDB partitions - all the others will
>> > be
>> > default sizes. DB backups will be made to a local drive and then
>> > backed
>> > up
>> > to tape over the network.
>> >
>> > This configuration gives good separation for resillience. It should
>> > reduce
>> > file fragmentation and I hope will give reasonable performance.
>> >
>> > Thanks for any comments|||Yes especially with the limited amount of drives. You are separating the
data and logs but you are also dividing the max throughput. BTW, in a small
hp config like this, I would set the stripe size in the ACU at 64k and the
cache to 0% read and 100% write(providing you have enough RAM). Sector align
with diskpart using a 128k offset as well.
Jason Massie
www: http://statisticsio.com
rss: http://feeds.feedburner.com/statisticsio
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:2BD76934-6814-46D7-BA51-EDBF09438BF0@.microsoft.com...
> Thanks Jason
> I did consider this, but thought I would be better with the separation.
> Do
> you think 1 RAID 10 array would perform better than 2 RAID 1?
> "jason" wrote:
>> Why not use disks 2-5 as RAID0+1 and move tempdb to it. You can still
>> create
>> partitions to split stff up if you want.
>>
>> --
>> Jason Massie
>> www: http://statisticsio.com
>> rss: http://feeds.feedburner.com/statisticsio
>>
>> "andrew" <andrew@.discussions.microsoft.com> wrote in message
>> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
>> > Is it better to divide an array into multiple partitions (or volumes)
>> > at
>> > the
>> > OS level or into multiple logical drives at the hardware level? Does
>> > it
>> > make
>> > any difference to track alignment? Will one give greater future
>> > flexibility
>> > over the other?
>> >
>> > I have to install SQL Server on an HP Proliant server with 6 drives
>> > bays -
>> > I
>> > would prefer more, but that is what I have available. I plan to create
>> > 3
>> > RAID 1 arrays using the HP Array Configuration Manager to use as
>> > follows:
>> >
>> > Array 1 (disks 0 & 1)
>> > C:\ OS
>> > S:\ SQL Server Installation
>> > T:\ TempDB
>> >
>> > Array 2 (disks 2 & 3)
>> > P:\ Page File
>> > D:\ Data
>> >
>> > Array 3 (disks 4 & 5)
>> > L:\ Transaction Logs
>> > X:\ Backups
>> >
>> > All partitions will be formatted with NTFS. I plan a stripe and
>> > cluster
>> > size of 64KB for the data and TempDB partitions - all the others will
>> > be
>> > default sizes. DB backups will be made to a local drive and then
>> > backed
>> > up
>> > to tape over the network.
>> >
>> > This configuration gives good separation for resillience. It should
>> > reduce
>> > file fragmentation and I hope will give reasonable performance.
>> >
>> > Thanks for any comments|||Agreed on the relative priority of how to split data files.
I do disagree on backing up and restoring across the network. I do it all
the time, even with third-party compression tools, and have very little
trouble. Once you get the permissions correct, it is a snap. Here is a KB
article on how to do it with SQL 2000. The same permission rules apply to
SQL 2005. Getting the backup onto another system quickly to safeguard
against hardware failure is worth the extra hassle of setting it up.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"andrew" <andrew@.discussions.microsoft.com> wrote in message
news:13CD654F-8041-424B-903F-60389E725823@.microsoft.com...
> Thanks Ekrem
> Our backup plan is to run SQL backups to disk, then backup these files
> using
> an enterprise backup solution along with system state etc. This
> eliminates
> some of the additional complexities of backing up across the network (the
> backup is less likely to fail if there are network problems or the other
> server isn't available) and also means we have a local backup if we need
> it
> for a partial restore or corrupt database.
> I would love to put TempDB on a separate disk, but that is not possible in
> this server as it only has 6 drive bays. I think separating logs and data
> probably has a higher priority. I would hesitate to put TempDB on RAID 0
> as
> it still needs to be present, even if there is no data to preserve, or SQL
> Server will fail.
> We desperately need to replace some very old hardware right now and we
> already have this server. Buying replacement hardware is a project for
> the
> future - that box will have more drives!
>
> "Ekrem Ã?nsoy" wrote:
>> You said "DB backups will be made to a local drive and then backed up to
>> tape over the network."
>> I don't know what way you'll use to copy your backups thru your network
>> however I just wanted to stress that "BACKUP ... to TAPE" can not be used
>> to
>> backup a database to a tape which is attached to a remote machine even if
>> it
>> would be in the same network. The backup tape must be connected directly
>> to
>> the SQL Server server to backup a database to tape.
>> Also, storing the OS and SQL Server binaries on the same drive would be
>> OK
>> If tempdb is used in your environment frequently then you may consider
>> putting it on a dedicated disk which could be (if you don't need
>> redundancy
>> or if you don't have enough resource for RAID1) RAID0.
>> However as Geoff mentioned, it would not make any difference to separate
>> a
>> disk logically. You need physical disks to gain performance benefit for
>> this
>> purpose.
>> You will want to give enough physical file space to your Transaction Log
>> file and Data files if you want less fragmentation.
>> --
>> Ekrem Ã?nsoy
>>
>> "andrew" <andrew@.discussions.microsoft.com> wrote in message
>> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
>> > Is it better to divide an array into multiple partitions (or volumes)
>> > at
>> > the
>> > OS level or into multiple logical drives at the hardware level? Does
>> > it
>> > make
>> > any difference to track alignment? Will one give greater future
>> > flexibility
>> > over the other?
>> >
>> > I have to install SQL Server on an HP Proliant server with 6 drives
>> > bays -
>> > I
>> > would prefer more, but that is what I have available. I plan to create
>> > 3
>> > RAID 1 arrays using the HP Array Configuration Manager to use as
>> > follows:
>> >
>> > Array 1 (disks 0 & 1)
>> > C:\ OS
>> > S:\ SQL Server Installation
>> > T:\ TempDB
>> >
>> > Array 2 (disks 2 & 3)
>> > P:\ Page File
>> > D:\ Data
>> >
>> > Array 3 (disks 4 & 5)
>> > L:\ Transaction Logs
>> > X:\ Backups
>> >
>> > All partitions will be formatted with NTFS. I plan a stripe and
>> > cluster
>> > size of 64KB for the data and TempDB partitions - all the others will
>> > be
>> > default sizes. DB backups will be made to a local drive and then
>> > backed
>> > up
>> > to tape over the network.
>> >
>> > This configuration gives good separation for resillience. It should
>> > reduce
>> > file fragmentation and I hope will give reasonable performance.
>> >
>> > Thanks for any comments|||Thanks guys, this is all really helpful stuff.
The whole area of storage config for SQL Server seems to be one where there
are lots of differing views out there on the web. It would be nice to have
the time to study the I/O patterns in detail over several weeks and
experiment with different setups, but it's difficult to justify that amount
of time in a busy schedule.
"Geoff N. Hiten" wrote:
> Agreed on the relative priority of how to split data files.
> I do disagree on backing up and restoring across the network. I do it all
> the time, even with third-party compression tools, and have very little
> trouble. Once you get the permissions correct, it is a snap. Here is a KB
> article on how to do it with SQL 2000. The same permission rules apply to
> SQL 2005. Getting the backup onto another system quickly to safeguard
> against hardware failure is worth the extra hassle of setting it up.
> HowTo: Backup to UNC name using Database Maintenance Wizard
> http://support.microsoft.com/kb/555128
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "andrew" <andrew@.discussions.microsoft.com> wrote in message
> news:13CD654F-8041-424B-903F-60389E725823@.microsoft.com...
> > Thanks Ekrem
> >
> > Our backup plan is to run SQL backups to disk, then backup these files
> > using
> > an enterprise backup solution along with system state etc. This
> > eliminates
> > some of the additional complexities of backing up across the network (the
> > backup is less likely to fail if there are network problems or the other
> > server isn't available) and also means we have a local backup if we need
> > it
> > for a partial restore or corrupt database.
> >
> > I would love to put TempDB on a separate disk, but that is not possible in
> > this server as it only has 6 drive bays. I think separating logs and data
> > probably has a higher priority. I would hesitate to put TempDB on RAID 0
> > as
> > it still needs to be present, even if there is no data to preserve, or SQL
> > Server will fail.
> >
> > We desperately need to replace some very old hardware right now and we
> > already have this server. Buying replacement hardware is a project for
> > the
> > future - that box will have more drives!
> >
> >
> > "Ekrem Ã?nsoy" wrote:
> >
> >> You said "DB backups will be made to a local drive and then backed up to
> >> tape over the network."
> >>
> >> I don't know what way you'll use to copy your backups thru your network
> >> however I just wanted to stress that "BACKUP ... to TAPE" can not be used
> >> to
> >> backup a database to a tape which is attached to a remote machine even if
> >> it
> >> would be in the same network. The backup tape must be connected directly
> >> to
> >> the SQL Server server to backup a database to tape.
> >>
> >> Also, storing the OS and SQL Server binaries on the same drive would be
> >> OK
> >> If tempdb is used in your environment frequently then you may consider
> >> putting it on a dedicated disk which could be (if you don't need
> >> redundancy
> >> or if you don't have enough resource for RAID1) RAID0.
> >>
> >> However as Geoff mentioned, it would not make any difference to separate
> >> a
> >> disk logically. You need physical disks to gain performance benefit for
> >> this
> >> purpose.
> >>
> >> You will want to give enough physical file space to your Transaction Log
> >> file and Data files if you want less fragmentation.
> >>
> >> --
> >> Ekrem Ã?nsoy
> >>
> >>
> >>
> >> "andrew" <andrew@.discussions.microsoft.com> wrote in message
> >> news:9498413C-FE6F-4DCA-B042-00B84890086B@.microsoft.com...
> >> > Is it better to divide an array into multiple partitions (or volumes)
> >> > at
> >> > the
> >> > OS level or into multiple logical drives at the hardware level? Does
> >> > it
> >> > make
> >> > any difference to track alignment? Will one give greater future
> >> > flexibility
> >> > over the other?
> >> >
> >> > I have to install SQL Server on an HP Proliant server with 6 drives
> >> > bays -
> >> > I
> >> > would prefer more, but that is what I have available. I plan to create
> >> > 3
> >> > RAID 1 arrays using the HP Array Configuration Manager to use as
> >> > follows:
> >> >
> >> > Array 1 (disks 0 & 1)
> >> > C:\ OS
> >> > S:\ SQL Server Installation
> >> > T:\ TempDB
> >> >
> >> > Array 2 (disks 2 & 3)
> >> > P:\ Page File
> >> > D:\ Data
> >> >
> >> > Array 3 (disks 4 & 5)
> >> > L:\ Transaction Logs
> >> > X:\ Backups
> >> >
> >> > All partitions will be formatted with NTFS. I plan a stripe and
> >> > cluster
> >> > size of 64KB for the data and TempDB partitions - all the others will
> >> > be
> >> > default sizes. DB backups will be made to a local drive and then
> >> > backed
> >> > up
> >> > to tape over the network.
> >> >
> >> > This configuration gives good separation for resillience. It should
> >> > reduce
> >> > file fragmentation and I hope will give reasonable performance.
> >> >
> >> > Thanks for any comments
> >>
>

Monday, March 12, 2012

Hardware planning for growth

Hardware planning for growth

Hardware planning for growth

Hardware Logical Drives or OS Level Partitions?

Hardware Logical Drives or OS Level Partitions?

Hardware Logical Drives or OS Level Partitions?

Handle Error

Blog Archive

About Me