April 24, 2009 at 7:21 am
Friends,
I need to centralize the databases across the systems of my compnay.
So please provide me some required info.
Thanks and I believe in Server Central
April 24, 2009 at 8:35 am
Purchase a really large server...
Seriously though, you need to evaluate the amount of storage you'll require on a single box. You need to understand which databases can share drives and which ones should be placed on their own. You'll need to understand the CPU & Memory usage of all existing servers so that you can purchase enough CPU and memory in the new box. You'll need to evaluate security across all the databases and applications to see which need ridiculous access, such as 'sa' (usually 3rd party apps). These you might want to put onto different instances on your central server to protect other data appropriately.
That's off the top of my head. I'm sure there's lots more obvious stuff I didn't think of.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2009 at 7:04 am
There is no easy answer to the question you have asked. What is required before you jump into this project is some careful analysis of your existing SQL Server environments and what SQL server projects are in the pipeline. This is going to provide you with the essential information you will require in order to plan out how to consolidate your environments.
There are many aspects which you will have to cover/consider in order to do a good job. I will try to identify some of the though processes that I went through when I was looking to consolidate our existing SQL Server environments.
You will need to get a decent set of performance bench marks figures so you can start to understand the performance and growth patterns of your instances/databases.
You need to understand the type of processing work loads for each instance/database. The size of your databases and ensure that you have sufficient disk space to meet with the current and future growth needs.
You need to understand the backup and restore requirements of each instance/database so that you can plan a backup and recovery strategy to meet those requirements (and test it does). You will need to ensure you have sufficient space to meet your backup needs (disk/tape). You will also need to understand the impact on performance that the backups will have. You need to understand Recovery requirements and how long each recovery should take and test it.
Maintenace and backup plans - ensure that you know what is required for each database, the frequency and the impact this has on the system. Understand the size of your maintenance window. Backup, DBCC, Re Orgs, Stats etc .. all take time you need to understand each ones requirements to ensure you have a sufficiently large enough window to meet them
You need to know the security requirements such as Windows authenticate or mixed mode. You also need to understand if there are any vendor specific security requirements. You sometimes see vendors wanting there accounts to have sysadmin role. Have a login migration planned including the passwords and code to ensure you deal with orphan users.
Carefully plan the security requirements and where possible try to restirct the access to 'sa' account or sysadmin role privilges.
Consider the High Availability option and Disaster Recovery (clustering, database mirroring, replication , log shipping etc)
Consider the SQL Server edition that you are going to install (Enterprise, Standard etc). I would suggest using a 64 Bit architecture so that you can address the higher memory ranges without having to use WOW.
Consider the possibilty of using more than one server to consolidate onto it maybe you can spred the work load across two or more servers.
Thinking about the sort order and collation set requirements and any language requirements.
Think about the possible use of using a single server and a number of databases or the possibility of a single server and some named instances. Obviously with the named instances you have to be aware of each of their requirements.
I actually used a collection of SQL Servers and had named instances residing on them all on 64 bit architecture.
Make sure the hardware is powerful enough for the job, you have a set of fast disks and enough of them (SAN attached preferably).
Think about monitoring and alerting solutions.
Which SQL services are going to be required and secure accounts used to start them.
The list goes on unfortunately I have run out of time, however you get the idea and I'm sure many people can pitch in other thoughts and experiences.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply