Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Auditing a SQL Server Environment Expand / Collapse
Author
Message
Posted Thursday, December 5, 2013 10:58 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Today @ 12:13 AM
Points: 68, Visits: 317
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?
Post #1520246
Posted Friday, December 6, 2013 3:45 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 6:13 AM
Points: 307, Visits: 475
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".
Post #1520486
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse