Standards Are a Good Thing

  • Standards are important, mainly to make things easy to find. We've got 60+ SQL Servers, 30 of which I manage. We have a standard hardware setup, 3 physical arrays min for all db servers. So we have

    c: - OS and SQL

    z: - SQL data and backups

    y: - SQL Logs

    arguably it should be different, but it works. We then have \mssql\data for all mdf files, \mssql\logs for ldfs, and \mssql\backup for backups with a sub for each db. \mssql\logs holds the logs and maint reports.

    This is an easy way that ensures that we know where everything is. Need a report? map to \\servername\z$\mssql\logs and I've got reports. Easy to manage and find things.

    Steve Jones

    sjones@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/sjones

    http://www.dkranch.net

  • I agree 100%

    I have a data warehouse and I had to reorganise all datafile and log files , plus move msdb, tempdb from D into a less OS drive

    Now, when I increase the space for my files I know my limits and I don't need to jump too much between drives

    I like the comment about the replicated db. I could not move that one.So now I know I have to stop the replication first 🙂

  • Hi there

    I believe many SQL Server DBA's can leaver off the Oracle OFA (flexible architecture) in terms of structuring data/log and install directories for your SQL Server databases. Generally its all common sense though.

    I tend to following this:

    x:\dbdata\<instance-name>\<db-name>\*.*

    x:\dblog\<instance-name>\<db-name>\*.*

    this will change slightly if we are also using Oracle or another DB on the same box.

    The standards flow into the location of your binaries and importantly, your backup files!

    In terms of large numbers of DBs on a box and bucket loads of database files, its very difficult to come up with some magical solution, especially when most have very different IO characteristics. The generic RAID-5 solition is a generally a good one for probably 80% of cases (especially in hosted envs). The trick here is a large cache and leaving write/read on at the controller.

    Cheers

    Ck


    Chris Kempster
    www.chriskempster.com
    Author of "SQL Server Backup, Recovery & Troubleshooting"
    Author of "SQL Server 2k for the Oracle DBA"

  • In my oppinion standars are very importent. I (among a couple of collegues) manage 500+ sql-servers. The servers that requier the most time from us are the ones that does not follow standard (there are a few).

    We've have arranged the server like follows:

    C: OS and SQL binary

    D: SQL systemdatabases

    E: Pure backupdisk

    F: User SQL logfiles

    G: User SQL datafiles

    H: Application disk

    We have split the log-, data- and backupdisk on three different diskes in order to be safe whenever/however one server might crash or crash caused by diskcrash.

    And like previous commeter says, it's so easy to find information on each server. Mapping a drive and not finding the information I need there (on non-standard servers) will make me go crazy for the extra time I need to spend to find what I need.

    robbac


    robbac
    ___the truth is out there___

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

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