Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Guys and Gals, I've been tasked with a doozy of an assignment. The objective is something akin to "laying of hands" on several database servers which work in concert to provide data to various Web, Client-Server and Tablet-Sync'd distributed Client-Server programs.

More specifically, I've been asked to come up with a "Maintenance Plan" which includes recommendations for future work to improve these machines' performance/reliability/security/etc.

Might there be some good articles on teh interwebs ya'll could point me towards which would give me some good basis to start? Articles describing "These are the top 4 overarching categories and this is how you should proceed when drilling down on each of them" sort-of-thing would be fabulous.

The Databases are all SQL 2005, however the compatibility level is 80 and they were originally created with ERwin based on SQL 6.5. The OSs are all Windows Server 2003.

Thanks all!

Tim

share|improve this question
5  
So you've given us no idea what OSes, server types or databases? –  GregD Jan 5 '11 at 15:13
    
@GregD You're right, I've added some basic DB and OS info. –  tcarper Jan 5 '11 at 15:26
    
I'm always right, but thanks for noticing ;) –  GregD Jan 5 '11 at 15:40

1 Answer 1

Don't have a definite answer but here are my 2 cents. In my view there are two ways to approaches to this, one is to leave applications unchanged the other is to move to services and customized applications.

If you don't want to change applications and databases but want more reliable system you should look at the following:

  • Know your recovery point objective and recovery time objective (this defines what you need in terms of architecture, procedures and hardware)
  • Storage architecture (how can us scale, eliminate hot-spots, improve performance);
  • Storage fail-over (like disk mirroring, and possibly off-site mirroring for Disaster Recovery);
  • Hot fail-over server;
  • Tested fail-over plan (this is really important, you need to test DR strategy);
  • Scalability of the Database server (how they grow if you throw more hardware on them);
  • Monitoring and automation are critical.

Changing your application may allow some interesting changes. Sharding your databases may allow larger data-set, one thing that is interesting is splitting read and writes. Many databases have a lot more read than writes, if that is the case having databases dedicated to each role with multiple replicas can do this. This video (Unshackle Your Domain) explores this idea.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.