• dba92081

    SSC Eights!

    Points: 934

    The database environment I currently manage is a 64-bit clustered SQL 2005 instance. It is running on a 10+ year old SAN that my manager would like to retire out re: maintenance/support/etc. When we upgrade to SQL 2008 later in the year, I would like to remove the old SAN aspect from the environment at that time. Basically leave the 2005 instance going & migrate to a new 2008 environment.

    Our database environment is small. The largest database we have is 10 GB. Total databases (production, test & dev) is 75 GB. Getting my manager to purchase a new SAN for our database environment will be a very challenging sell due to not having terrabytes of data. I've been considering getting a nice box with 100 GB drives, hardware RAID, etc, separating the test & dev databases to VM's instead & doing log shipping or replication for production instead of clustering.

    With the small environment we have, would you recommend keeping it in a clustered SAN environment? Or is log shipping or replication a more reasonable approach? Test & dev databases should be separated out from production, correct?

    Any advice or guidance is most appreciated.

  • GSquared

    SSC Guru

    Points: 260824

    I'd definitely isolated test/dev from prod. Physically isolate if at all possible. After all, you should be TRYING to crash your test box, otherwise you won't know if it'll crash in production.

    A SAN seems like overkill for less than 100 Gig of data, unless you're planning on major growth in the near-mid term. Couple of 1 Tb drives in RAID 1 would cover that, most likely, and be cheaper. Unless you plan to keep it clustered, in which case a small SAN is useful.

    Clustering is good as a first DR step, since it allows for one server to be patched while the other does the work, and so on. Real DR/BC would include clustering for local server issues, and a remote location with log shipping or replication or whatever for things like your power is out for a few days during a hurricane/earthquake/building fire/the janitor is on vacation and nobody else knows how to reset the breaker box, kind of situation.

    It really depends on what the business needs and how much they can spend to get it. Everyone wants 100% uptime, very few can/will pay for it.

    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Chuck Hottle

    SSCarpal Tunnel

    Points: 4777

    You might want to search for sql server high availability options using your favorite serach engine and do some reading. Your choice will depend on a combination of business requirements with regards to acceptable downtime (seconds, minutes, hours, days) and cost. This is an overview of some of the considerations.

  • dba92081

    SSC Eights!

    Points: 934

    Thanks, GSquared for the advice. I was thinking a SAN was a bit of an overkill in this environment too.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply