I have been tasked with setting up a brand new PowerEdge 2650 for
SharePoint, SQL 2000 and Windows 2003. This server has 5 physical disks,
all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
My question is in regards to the best possible RAID setup for SQL
performance as well as retaining as much disk space as possible.
If I read the docs correctly SQL is best suited to have the tempdb,
application files and log files all on separate physical disks.
I cannot find a way to do this without losing a lot of my available disk
space.
The way I see it, as well as my SQL admin, there are 3 factors to consider.
1. Speed (performance), 2. Reliability 3. Capacity.
If I configure everything in one big RAID 5 array I would have excellent
reliability, and have (73x4) 292GB free for data, probably 270GB after
application installations.
If I configure disk 1 for OS and apps, disk 2 for log files and disks 3,4
and 5 for data I would have 219GB available for data with no redundancy, if
I add RAID 5 across those 3 disks I would get 146GB useable space,
dramatically less than the 292GB from the other config.
A third option is to create a 10GB (or 20GB) partition on disk 1, mirror
that to disk 2 and configure all 5 disks in a RAID 5 configuration. The
problem with this is that I can only use 63GB of each disk, giving me 315GB
minus parity drive, for a total useable size of 252GB. However, I don't
think this configuration would give me much of a performance gain in SQL.
So my questions are this : what would you recommend, taking into account
that this machine will be running W2k3, SQL 2000 and SharePoint 2003. The
server will have about 50GB of local data *eventually*, and will be indexing
around 150GB of data residing on a NAS device.
Also, I have heard that SharePoint doesn't really tax SQL that bad and that
I'm over-analyzing the problem. Just set it up as one big RAID 5 and be
done with it. Thought?
Sorry for the long post.Hi,
Follow the below URL which gives idea on What RAID Levels
to choose for SQL Boxes and why so. Of Course More replies
to come from experts.
http://www.sql-server-performance.com/q&a38.asp
HTH
THIRUMAL REDDY MARAM
System Admin / SQL DBA
>--Original Message--
>I have been tasked with setting up a brand new PowerEdge
2650 for
>SharePoint, SQL 2000 and Windows 2003. This server has 5
physical disks,
>all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
>My question is in regards to the best possible RAID setup
for SQL
>performance as well as retaining as much disk space as
possible.
>If I read the docs correctly SQL is best suited to have
the tempdb,
>application files and log files all on separate physical
disks.
>I cannot find a way to do this without losing a lot of my
available disk
>space.
>The way I see it, as well as my SQL admin, there are 3
factors to consider.
>1. Speed (performance), 2. Reliability 3. Capacity.
>If I configure everything in one big RAID 5 array I would
have excellent
>reliability, and have (73x4) 292GB free for data,
probably 270GB after
>application installations.
>If I configure disk 1 for OS and apps, disk 2 for log
files and disks 3,4
>and 5 for data I would have 219GB available for data with
no redundancy, if
>I add RAID 5 across those 3 disks I would get 146GB
useable space,
>dramatically less than the 292GB from the other config.
>A third option is to create a 10GB (or 20GB) partition on
disk 1, mirror
>that to disk 2 and configure all 5 disks in a RAID 5
configuration. The
>problem with this is that I can only use 63GB of each
disk, giving me 315GB
>minus parity drive, for a total useable size of 252GB.
However, I don't
>think this configuration would give me much of a
performance gain in SQL.
>So my questions are this : what would you recommend,
taking into account
>that this machine will be running W2k3, SQL 2000 and
SharePoint 2003. The
>server will have about 50GB of local data *eventually*,
and will be indexing
>around 150GB of data residing on a NAS device.
>Also, I have heard that SharePoint doesn't really tax SQL
that bad and that
>I'm over-analyzing the problem. Just set it up as one
big RAID 5 and be
>done with it. Thought?
>Sorry for the long post.
>
>.
>|||Every case is unique per the Budget , Scope, SLAs etc... to come up with teh
right configuration.
It also depends upon the Access Patterns, Number of Data files and groups,
Index and TempDB Placement.
I would recommend that you start at the MSFT Operations guide at
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/operate/opsguide/default.asp
And look at Chapter 6, which talks about Capacity Planning.
--
HTH
Satish Balusa
Corillian Corp.
"cyberpunk" <blah@.anon.com> wrote in message
news:eONEAKr3DHA.1404@.TK2MSFTNGP11.phx.gbl...
> I have been tasked with setting up a brand new PowerEdge 2650 for
> SharePoint, SQL 2000 and Windows 2003. This server has 5 physical disks,
> all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
> My question is in regards to the best possible RAID setup for SQL
> performance as well as retaining as much disk space as possible.
> If I read the docs correctly SQL is best suited to have the tempdb,
> application files and log files all on separate physical disks.
> I cannot find a way to do this without losing a lot of my available disk
> space.
> The way I see it, as well as my SQL admin, there are 3 factors to
consider.
> 1. Speed (performance), 2. Reliability 3. Capacity.
> If I configure everything in one big RAID 5 array I would have excellent
> reliability, and have (73x4) 292GB free for data, probably 270GB after
> application installations.
> If I configure disk 1 for OS and apps, disk 2 for log files and disks 3,4
> and 5 for data I would have 219GB available for data with no redundancy,
if
> I add RAID 5 across those 3 disks I would get 146GB useable space,
> dramatically less than the 292GB from the other config.
> A third option is to create a 10GB (or 20GB) partition on disk 1, mirror
> that to disk 2 and configure all 5 disks in a RAID 5 configuration. The
> problem with this is that I can only use 63GB of each disk, giving me
315GB
> minus parity drive, for a total useable size of 252GB. However, I don't
> think this configuration would give me much of a performance gain in SQL.
> So my questions are this : what would you recommend, taking into account
> that this machine will be running W2k3, SQL 2000 and SharePoint 2003. The
> server will have about 50GB of local data *eventually*, and will be
indexing
> around 150GB of data residing on a NAS device.
> Also, I have heard that SharePoint doesn't really tax SQL that bad and
that
> I'm over-analyzing the problem. Just set it up as one big RAID 5 and be
> done with it. Thought?
> Sorry for the long post.
>
Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts
Monday, March 12, 2012
Help Needed on Hardware Setup
I have been tasked with setting up a brand new PowerEdge 2650 for
SharePoint, SQL 2000 and Windows 2003. This server has 5 physical disks,
all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
My question is in regards to the best possible RAID setup for SQL
performance as well as retaining as much disk space as possible.
If I read the docs correctly SQL is best suited to have the tempdb,
application files and log files all on separate physical disks.
I cannot find a way to do this without losing a lot of my available disk
space.
The way I see it, as well as my SQL admin, there are 3 factors to consider.
1. Speed (performance), 2. Reliability 3. Capacity.
If I configure everything in one big RAID 5 array I would have excellent
reliability, and have (73x4) 292GB free for data, probably 270GB after
application installations.
If I configure disk 1 for OS and apps, disk 2 for log files and disks 3,4
and 5 for data I would have 219GB available for data with no redundancy, if
I add RAID 5 across those 3 disks I would get 146GB useable space,
dramatically less than the 292GB from the other config.
A third option is to create a 10GB (or 20GB) partition on disk 1, mirror
that to disk 2 and configure all 5 disks in a RAID 5 configuration. The
problem with this is that I can only use 63GB of each disk, giving me 315GB
minus parity drive, for a total useable size of 252GB. However, I don't
think this configuration would give me much of a performance gain in SQL.
So my questions are this : what would you recommend, taking into account
that this machine will be running W2k3, SQL 2000 and SharePoint 2003. The
server will have about 50GB of local data *eventually*, and will be indexing
around 150GB of data residing on a NAS device.
Also, I have heard that SharePoint doesn't really tax SQL that bad and that
I'm over-analyzing the problem. Just set it up as one big RAID 5 and be
done with it. Thought?
Sorry for the long post.Every case is unique per the Budget , Scope, SLAs etc... to come up with teh
right configuration.
It also depends upon the Access Patterns, Number of Data files and groups,
Index and TempDB Placement.
I would recommend that you start at the MSFT Operations guide at
http://www.microsoft.com/technet/tr...ide/default.asp
And look at Chapter 6, which talks about Capacity Planning.
HTH
Satish Balusa
Corillian Corp.
"cyberpunk" <blah@.anon.com> wrote in message
news:eONEAKr3DHA.1404@.TK2MSFTNGP11.phx.gbl...
consider.
if
315GB
indexing
that
SharePoint, SQL 2000 and Windows 2003. This server has 5 physical disks,
all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
My question is in regards to the best possible RAID setup for SQL
performance as well as retaining as much disk space as possible.
If I read the docs correctly SQL is best suited to have the tempdb,
application files and log files all on separate physical disks.
I cannot find a way to do this without losing a lot of my available disk
space.
The way I see it, as well as my SQL admin, there are 3 factors to consider.
1. Speed (performance), 2. Reliability 3. Capacity.
If I configure everything in one big RAID 5 array I would have excellent
reliability, and have (73x4) 292GB free for data, probably 270GB after
application installations.
If I configure disk 1 for OS and apps, disk 2 for log files and disks 3,4
and 5 for data I would have 219GB available for data with no redundancy, if
I add RAID 5 across those 3 disks I would get 146GB useable space,
dramatically less than the 292GB from the other config.
A third option is to create a 10GB (or 20GB) partition on disk 1, mirror
that to disk 2 and configure all 5 disks in a RAID 5 configuration. The
problem with this is that I can only use 63GB of each disk, giving me 315GB
minus parity drive, for a total useable size of 252GB. However, I don't
think this configuration would give me much of a performance gain in SQL.
So my questions are this : what would you recommend, taking into account
that this machine will be running W2k3, SQL 2000 and SharePoint 2003. The
server will have about 50GB of local data *eventually*, and will be indexing
around 150GB of data residing on a NAS device.
Also, I have heard that SharePoint doesn't really tax SQL that bad and that
I'm over-analyzing the problem. Just set it up as one big RAID 5 and be
done with it. Thought?
Sorry for the long post.Every case is unique per the Budget , Scope, SLAs etc... to come up with teh
right configuration.
It also depends upon the Access Patterns, Number of Data files and groups,
Index and TempDB Placement.
I would recommend that you start at the MSFT Operations guide at
http://www.microsoft.com/technet/tr...ide/default.asp
And look at Chapter 6, which talks about Capacity Planning.
HTH
Satish Balusa
Corillian Corp.
"cyberpunk" <blah@.anon.com> wrote in message
news:eONEAKr3DHA.1404@.TK2MSFTNGP11.phx.gbl...
quote:
> I have been tasked with setting up a brand new PowerEdge 2650 for
> SharePoint, SQL 2000 and Windows 2003. This server has 5 physical disks,
> all 73GB, 2GB of RAM and a 3.06Ghz Xeon processor.
> My question is in regards to the best possible RAID setup for SQL
> performance as well as retaining as much disk space as possible.
> If I read the docs correctly SQL is best suited to have the tempdb,
> application files and log files all on separate physical disks.
> I cannot find a way to do this without losing a lot of my available disk
> space.
> The way I see it, as well as my SQL admin, there are 3 factors to
consider.
quote:
> 1. Speed (performance), 2. Reliability 3. Capacity.
> If I configure everything in one big RAID 5 array I would have excellent
> reliability, and have (73x4) 292GB free for data, probably 270GB after
> application installations.
> If I configure disk 1 for OS and apps, disk 2 for log files and disks 3,4
> and 5 for data I would have 219GB available for data with no redundancy,
if
quote:
> I add RAID 5 across those 3 disks I would get 146GB useable space,
> dramatically less than the 292GB from the other config.
> A third option is to create a 10GB (or 20GB) partition on disk 1, mirror
> that to disk 2 and configure all 5 disks in a RAID 5 configuration. The
> problem with this is that I can only use 63GB of each disk, giving me
315GB
quote:
> minus parity drive, for a total useable size of 252GB. However, I don't
> think this configuration would give me much of a performance gain in SQL.
> So my questions are this : what would you recommend, taking into account
> that this machine will be running W2k3, SQL 2000 and SharePoint 2003. The
> server will have about 50GB of local data *eventually*, and will be
indexing
quote:
> around 150GB of data residing on a NAS device.
> Also, I have heard that SharePoint doesn't really tax SQL that bad and
that
quote:
> I'm over-analyzing the problem. Just set it up as one big RAID 5 and be
> done with it. Thought?
> Sorry for the long post.
>
Friday, March 9, 2012
Help needed - URGENT!
Hi all,
I need help urgent :
I did a very stupid mistake and haven't backed up my database.
I had a hardware problem and when the database server came up again I saw that my most important database is in suspected mode.
I tried detaching it with no success , so I copied the mdf file to another dirctory and then deleted the database from the server, thinking I would be able to use sp_attach_single_file_db. However, when I try to do that I am getting an error about the log file as follows:
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database 'smmdb'. CREATE DATABASE is aborted.
Device activation error. The physical file name 'D:\MSSQL7\data\smmdb_log.LDF' may be incorrect.
note : I am using SQL 2000 SP3 , although the name of directory is shows otherwise.
Do I have any chance to do something (and save my job..)?>> I did a very stupid mistake and haven't backed up my database.
lol.
Treat it as a valuable learning experience.
You shouldn't lose your job as it's your bosses fault for not putting someone who knows about database development in charge of you.
Try creating a new database the same size, stop the server, replace the mdf with your dubious one.
This should come up suspect.
In sysdatabases set the starus of the database to 32768 (emergency mode) - you will have to allow updates to system tables.
restart the server and you may be able to access it and retrieve data.
In future take backups and do test restores.
If you don't test the backups then you still can't say you have a backup strategy.
I need help urgent :
I did a very stupid mistake and haven't backed up my database.
I had a hardware problem and when the database server came up again I saw that my most important database is in suspected mode.
I tried detaching it with no success , so I copied the mdf file to another dirctory and then deleted the database from the server, thinking I would be able to use sp_attach_single_file_db. However, when I try to do that I am getting an error about the log file as follows:
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database 'smmdb'. CREATE DATABASE is aborted.
Device activation error. The physical file name 'D:\MSSQL7\data\smmdb_log.LDF' may be incorrect.
note : I am using SQL 2000 SP3 , although the name of directory is shows otherwise.
Do I have any chance to do something (and save my job..)?>> I did a very stupid mistake and haven't backed up my database.
lol.
Treat it as a valuable learning experience.
You shouldn't lose your job as it's your bosses fault for not putting someone who knows about database development in charge of you.
Try creating a new database the same size, stop the server, replace the mdf with your dubious one.
This should come up suspect.
In sysdatabases set the starus of the database to 32768 (emergency mode) - you will have to allow updates to system tables.
restart the server and you may be able to access it and retrieve data.
In future take backups and do test restores.
If you don't test the backups then you still can't say you have a backup strategy.
Subscribe to:
Posts (Atom)