Auditing a SQL Server Environment

  • Hi

    I've been tasked to audit a number of SQL Server environments.

    I'm going to be creating baseline documentations for each environment, documenting statistics (database stats, waits stats, log usage etc.) and having a general mooch around to see what they have in place in terms of daily/weekly maintenance (dbcc check, index rebuilds etc.). Also, I'll be recording general statistic about the server (cpu, ram etc).

    Once complete, I'll list recommendations, with this in mind, is there anything else I should be recording/looking at?

  • wak_no1 (12/5/2013)


    Hi

    I've been tasked to audit a number of SQL Server environments.

    I'm going to be creating baseline documentations for each environment, documenting statistics (database stats, waits stats, log usage etc.) and having a general mooch around to see what they have in place in terms of daily/weekly maintenance (dbcc check, index rebuilds etc.). Also, I'll be recording general statistic about the server (cpu, ram etc).

    Once complete, I'll list recommendations, with this in mind, is there anything else I should be recording/looking at?

    I do this also on a regular basis with the help of SQL Server 2008R2 Policy Management simply to monitor the installations as dictated by Company Policy.

    In addition I also like to check:

    a. Failed user login requests for that period

    b. Logged errors across the Instance, database(s) and within the Server Agent

    c. Long running and expensive query performance

    d. Information about local backups (success/failure)

    e. Datafile growth

    f. Available free space on physical volumes

    g. Free space available over a given period of time within the Transaction Log

    The problem is that there is so much that can be monitored you have to ask yourself "should it be monitored"? Depending on your setup, restrictions on data collection, available resources for data collection and so on you may need to compromise collecting information in some areas. Another question of course is "how long should this information be retained?", a question that raises storage issues in its own right.

    My advice would be to prioritise the information that you need based on your own Company Policy and implement that first. Once it is running you can have a look at the "nice to haves".

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

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