Monday, March 19, 2012
choosing server and raid. -- Repost
advice is grattly appriciated.
I'd like to get some feed back on what I can setup with these systems. I have
very limmited budget. One is primary server and the other is a
backup/recovery system. The intent is to setup logshipping between the two.
The database is currently 30 GB / data 4 GB Log and we expect it to grow 5
GB per year.
server (A) / primary server
DL380G3 server
Smart Array 5i Plus Controler
1 36 GB HD (currently OS and runtimes)
3 72 GB ULTRA320 10,000 rmp HD (currently everything else)
server (b) / backup/recovery
Dell PowerEdge 1600SC
PERC4 Single Channel
5 36 GB 15,000 rmp HD (raid 5) / 2 partitions (OS,database files)
My usumption
server (a) makeit the backup server
buy another 36 GB dribe and raid 1 with current
server (b)
buy another 36 GB harddrive
setup 2 HD in Raid 1 setup
setup 4 HD in raid 5 or raid 10 setup for database
? where should I place TEMPDB, transaction logs
What about backup of transaction log? should I partition the hard drivesjccondor wrote:
> server (A) / primary server
> DL380G3 server
> Smart Array 5i Plus Controler
> 1 36 GB HD (currently OS and runtimes)
> 3 72 GB ULTRA320 10,000 rmp HD (currently everything else)
The OS should be on a mirrored set if possible. That would require you
add another 36GB HD and set it up for RAID 1. Three disks does not leave
you with many options for the databases, log files, and tempdb. While
you can RAID 5 them, three disks is not ideal and having the data and
log files on the same array is not the best option either. Unless this
is a really small database with limited OLTP activity. So your
assumption about purchasing another 36GB drive sounds like a good idea.
If this is just for backups and are looking for the best write speed,
then a RAID 5 array is not the best choice since it has high overhead
for writing. But it may work for you if you need the redundancy. I
assume you want some redundancy on the disks and RAID 5 is the cheapest,
despite its write performance issues. Of course, if you only need
redundancy for the backups, then you could use one of the 72GB drives
for the OS, RAID 1 the other two and store backups there, and then move
the 36GB drive to the other server.
> server (b) / backup/recovery
> Dell PowerEdge 1600SC
> PERC4 Single Channel
> 5 36 GB 15,000 rmp HD (raid 5) / 2 partitions (OS,database files)
Partitioning a RAID 5 array into two partitions really gives you nothing
performance-wise. For best performance on a server, it's best to isolate
the OS/Program Files, the database files, and the log files. On a busy
server you can even isolate tempdb. It all depends on your database and
the type and level of activity. With 6 drives, you could use three RAID
1 arrays, a RAID 1 array for the OS and a RAID 1+0 for the database and
log files.
Since we know little about your database, the type of activity, the
level of activity, reads vs writes, the size, and the expected growth,
it's difficult to recommend a solution.
David Gugick
Quest Software
www.imceda.com
www.quest.com
Sunday, March 11, 2012
choosing a collation in SQL 2005
I have been searching for advice on the 'right' collation to choose in SQL 2005. I am US based and can assume any language required not supported by Latin1_General will be in unicode. I have SQL 2000 servers using SQL_Latin1_General_CP1_CI_AS and SQL_Latin1_General_CP850_CI_AS. The ones using CP850 will be converted to whatever collation is chosen in SQL 2005. I do not know the implications of choosing the default SQL collation as opposed to choosing Latin1_General_CI_AS. I have seen warning messages when installing analysis services if the SQL_Latin1_General_CP1_CI_AS is chosen saying that analysis services will use the colaltion Latin1_General_... . I also use non-updating subscribers in transactional replication currently in teh SQL 2000 environment and will continue to use replication in SQL 2005.
What are the implications of choosing the windows vs. SQL collation if the choice is between SQL_Latin1_General_CP1_CI_AS and Latin1_Gernal_CI_AS ? I do not want a collation mixture like I currently have in SQL 2000.
There's a helpful topic in Books Online that addresses this:
http://msdn2.microsoft.com/en-us/library/ms144260.aspx
Buck Woody
|||Thank you very much. This is the information I needed to see. I am not sure why searching BOL myself did not turn up this information.|||If I am doing a fresh installation of SQL 2005 for a new application which will utilize databse engine, report server and analysis services is my best choice Latin_General_BIN2?
Thank you,
Alex Ivanoff
choosing a collation in SQL 2005
I have been searching for advice on the 'right' collation to choose in SQL 2005. I am US based and can assume any language required not supported by Latin1_General will be in unicode. I have SQL 2000 servers using SQL_Latin1_General_CP1_CI_AS and SQL_Latin1_General_CP850_CI_AS. The ones using CP850 will be converted to whatever collation is chosen in SQL 2005. I do not know the implications of choosing the default SQL collation as opposed to choosing Latin1_General_CI_AS. I have seen warning messages when installing analysis services if the SQL_Latin1_General_CP1_CI_AS is chosen saying that analysis services will use the colaltion Latin1_General_... . I also use non-updating subscribers in transactional replication currently in teh SQL 2000 environment and will continue to use replication in SQL 2005.
What are the implications of choosing the windows vs. SQL collation if the choice is between SQL_Latin1_General_CP1_CI_AS and Latin1_Gernal_CI_AS ? I do not want a collation mixture like I currently have in SQL 2000.
There's a helpful topic in Books Online that addresses this:
http://msdn2.microsoft.com/en-us/library/ms144260.aspx
Buck Woody
|||Thank you very much. This is the information I needed to see. I am not sure why searching BOL myself did not turn up this information.|||If I am doing a fresh installation of SQL 2005 for a new application which will utilize databse engine, report server and analysis services is my best choice Latin_General_BIN2?
Thank you,
Alex Ivanoff