SQL Server Health Check

prepared for Sample Customer

“This document provides an overview of the health

of your SQL Server Environment”

Report Date: 18-AUG-2004

Server: SQL Sample

Completed By: Reece Mitchell

 Table of Contents

1 Introduction.........................................................................................................................................3

2 Executive Summary ............................................................................................................................3

3 Hardware & Operating System Summary ..........................................................................................4

Disk Sub-Systems.................................................................................................................................4
Hardware & Operating System findings.................................................................................................4

4 SQL Server Configuration ..................................................................................................................6

SQL Server Configuration Findings.......................................................................................................6

5 Databases ............................................................................................................................................8
System Databases ................................................................................................................................8
User Databases.....................................................................................................................................8
Database Findings ..............................................................................................................................10

6 SQL Server Backup & Recovery.......................................................................................................12

SQL Server Backup & Recovery Findings...........................................................................................12

7 Security..............................................................................................................................................13
Security Findings ................................................................................................................................13

Appendix A – SQL Server Best Practice..................................................................................................14

SQL_Health_Check_Report_Sample.doc Effective from 01/08/2004 Pg. 2 of 14

1 Introduction
The following report is aimed at providing an overview of the health state of your SQL Server 2000
environment. It focuses on aspects of SQL Server that are often over looked when it is installed or when
moved from development to production environments. Any findings listed should be treated as an
opportunity to improve/secure the SQL Server environment rather than as criticism of any party for not
having made such changes themselves. It is best to treat this as a positive exercise.

The following key is used to identify key information provided:

Configuration is within expected boundaries, no action required.

A recommendation is made but does not require immediate action

Configuration is outside expected boundaries, action is required.

2 Executive Summary
The Sample SQL Server has sufficient hardware, in most areas, for the current database load and
application usage. However the server only has 1GB of RAM. This is a limited amount of RAM for a SQL
Server, and consideration should be given to upgrading this amount to 2.5GB. SQL Server Standard Edition
can only address a maximum of 2GB of RAM. So upgrading the amount of RAM to a total of 2.5 will allow
SQL Server to address its maximum allowable memory space, and leave an appropriate amount of memory
for the operating system.

The file location for SQL Server should also be addressed. Although there are separate disk sub-systems
for both data and logs, many databases on the server are not utilising this. All databases with both the data
and log file on the same disk system, should have the log file moved to the proper log disk system.

Transaction log backups are also missing from this server. Regularly backing up the transaction logs has
two main benefits. It firstly provides the means to recover a database to a point in time, up to the last
successful log backup. It also provides a means to control the size of the database log files, as each time
the log file is backed up, committed transactions are removed from the log and stop the size of the log file
from growing too large.

Database consistency checks are also not being run. Database consistency checks, or DBCC’s, should be
run on a weekly basis. These checks complete a series of tasks on a database which determine whether the
database is in a healthy state or not. Failure to run these checks puts the database at risk of becoming
corrupt and/or transactions running inconsistently.

The service account which SQL Server runs under also needs altering, as it’s currently setup to run under
the “Local System” account. This opens up the database server to potential security risks, and restricts
access for SQL Server from other servers on the network.

With the server’s current configuration and database setup, the recoverability goals of a maximum amount
of data loss of 4 hours, and the maximum tolerable downtime of 1 hour, would not be achievable in some
circumstances. The implementation of hourly log backups on all production databases would provide the
safety margin required for data loss. However without the use of Log Shipping to a Disaster Recovery server
the goal of a maximum downtime is difficult to achieve. Implementation of Log Shipping provides up to a 30
minute downtime window, where log shipped databases can be recovered and ready to use on a Disaster
Recovery server.

The standard edition of SQL Server does not offer the Microsoft Log Shipping services however SQL
Services has developed a Log Shipping Disaster Recovery service that works with SQL standard edition as
part of our SLA offerings. If assistance is needed in developing a disaster recovery plan, SQL Services can
provide planning and implementation assistance.

SQL_Health_Check_Report_Sample.doc Pg. 3 of 14
3 Hardware & Operating System Summary
Given that SQL Server will only perform optimally on appropriate hardware and operating systems, these
have been analysed against best practice and its appropriateness for this SQL Server environment.

The Sample SQL Server is Sample Customer’s general purpose SQL Server. Which holds various
databases for various systems. The biggest database housed on this server is the <DB_NAME> database,
which is used for storing statistical information on Sample’s system.

Disk Sub-Systems
Drive sub RAID Level Drive Drive Purpose Logical Free Space
system Letter Size (GB) (GB)
2 x 18.2 GB RAID 1 C: Operating System 16.9 3.5
10,000 RPM SQL Binaries
Page File
7 x 18.2 GB RAID 5 F: Some SQL Log 101.7 16.4
Files
10,000 RPM
2 x 18.2 GB RAID 1 H: SQL System 16.9 6.0
Databases
10,000 RPM
SQL Data Files
Some SQL Log
Files

Hardware & Operating System findings

Status Configuration Comments

Server Make Compaq Servers are well proven as stable and reliable in
 Compaq
production environments, with a good local supply of parts.

Server Model The Compaq ML530 has a maximum CPU limit of 2

 Proliant ML530
processors and 12 local disks. This should be suitable
initially but should the number of concurrent user grow to
more than 200 a quad processor capable server may be
needed. .
Processor Speed The dual 1.0GHz CPU’s appear to be sufficient for a SQL
 2 x 1.0 Ghz
Server environment of this size. More in-depth analysis of
the CPU load should be completed to confirm this. A SQL
Services Performance and Tuning audit is available if
required.
RAM A total of 1GB of RAM for is low for a server of this size,
running databases which are in excess of 10GB.
1,024 MB
SQL Server 2000 Standard Edition supports up to 2GB of
physical memory. Upgrading the amount of physical memory
to 2.5GB should be considered. This would allow SQL Server
to address the a full 2GB of memory, while leaving sufficient
memory for the Windows operating system.

SQL_Health_Check_Report_Sample.doc Pg. 4 of 14
 Status Configuration Comments

Disk RAID Level The RAID level for the underlying disk sub-system is not
configured optimally for a SQL Server performance in a high
See above end database server. The SQL Data files should reside on a
high performance RAID 0+1 disk that offers a high degree of
fault tolerance and is high performance. It is recommended
that this disk subsystem be monitored using Performance
Monitor to determine if it is causing a bottleneck.
The RAID 1 disks for the O/S and SQL logs is appropriate
and recommended.
File Locations While the disk RAID level for this server is appropriate the
location of the SQL related files is not optimal. Some SQL
See above
data and log files reside on the same drive sub-systems
which increases the potential for disk bottlenecks with high
data and log activity.
In addition recoverability of SQL Server data in event of a
system crash can be enhanced if the SQL log files are on a
separate disk to the data device files. It is recommended to
move the SQL log file to either the C-Drive or H-Drive.
Disk Space Given the current application requirements, there appears to
 See above
be sufficient disk space.

Operating System Windows 2000 Server Standard Edition is installed along

 Windows 2000
with Service Pack 4. This is appropriate and recommended.

Standard Server – SP4

Server Role The server has been setup as a backup domain controller.
 Domain Controller
Running a SQL Server on the same server as a domain
controller is not recommended, as the load put on the server
by being a domain controller can be detrimental to SQL
Servers performance.
Windows Event Logs The Windows 2000 event logs have been scanned. No errors
 of relevance were found.

SQL_Health_Check_Report_Sample.doc Pg. 5 of 14
4 SQL Server Configuration
SQL Server has several configurable options, in this section these options are reviewed for their
appropriateness for this particular SQL Server environment and against best practice.

SQL Server Configuration Findings

Status Configuration Comments

SQL Server Edition SQL Server 2000 Enterprise Edition is installed on

 Standard
Sample. This is appropriate as it contains the full
functionality of SQL Server.
SQL Server Service Pack SQL Server 2000 is installed with Service Pack 3
 SP3
(8.00.760). This is appropriate as SP3 has proven as a
stable and reliable version for production environments.
Startup Parameters The SQL Server startup parameters are correctly
 -
configured.

dF:\MSSQL\data\master.mdf

-
eF:\MSSQL\log\ERRORLO
G

-lF:\MSSQL\data\mastlog.ldf
Network Protocols SQL Server is configured to listen on TCP/IP and
 TCP/IP
named pipes. This is appropriate and recommended.

Named Pipes
SQL Memory Settings SQL Server is set to configure all RAM dynamically.
 Min: 0
This is appropriate as SQL Server is the only application
on this server. It is recommended to run performance
monitor on the server to ensure that the server is not
Max: <Max server memory> paging.
SQL Priority Boost The "Boost SQL on Windows" option is disabled. This is
 Disabled
recommended and should not be enabled as it can
cause server stability problems. Priority boost should
only be used if following Microsoft support
recommendations and then only on a computer
dedicated to SQL Server, and with a symmetric
multiprocessor (SMP) configuration.
Max Degree of Parallelism The Max Degree of Parallelism is set to 0. This enables
parallel querying. It is recommended to set this to 1
0 which will prevent SQL Server from using parallel query
plans which may cause longer query durations and
inconsistent result sets
Maximum Connections The maximum connections is correctly set to 0, allowing
 0
unlimited connections to SQL Server

SQL_Health_Check_Report_Sample.doc Pg. 6 of 14
 Status Configuration Comments

SQL Server Service The service that runs SQL Server is inappropriately
Account configured to run under the Local System account. SQL
Server should be set to run under a dedicated domain
Local System account, with a password set to not expire, which is also
set as a local administrator of the SQL Server.
SQL Agent Service Account The service that runs the SQL Server Agent should be
 Local System
set to run under the same domain account as is used for
SQL Server.
SQL Mail SQL Mail has not been configured. This is appropriate
 Disabled
as SQL Mail can cause stability issues for SQL Server,
with a worst case situation involving the SQL Server
having to be rebooted to resolve SQL Mail issues.
SQL Alerts SQL Alerts have been not been configured. It is
 Disabled
recommended to configure alerts via e-mail and/or
pager for proactive notifications from the SQL Server.
OLAP Data Warehousing The OLAP Data Warehousing Tools are not installed on
 Tools
Not installed
the server, this is appropriate as this server is not a data
warehouse.
SQL Replication SQL Server Replication is not configured on this server.
 Not Enabled
SQL Agent Error Log The SQL Agent error log has been scanned for errors of
 relevance. No errors of relevance were found.

SQL Server Error Log The SQL Server error log has been scanned for errors
 of relevance. No errors of relevance were found.
However it appears that this server is regularly (weekly)
shutdown. This is not recommended for SQL Server as
each time SQL starts it goes through a “warm-up” phase
were it caches the most frequently used data and query
plans. It is recommended to minimise the number of
restarts for SQL Server.

SQL_Health_Check_Report_Sample.doc Pg. 7 of 14
5 Databases

System Databases
Database Name Owner Data Log Options
File File
Size Size
(Mb) (Mb)
Master sa 15.0 2.0 Status=ONLINE, Updateability=READ_WRITE,
UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Model sa 1.0 1.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=FULL, Version=539,
Collation=Latin1_General_CI_AS, SQLSortOrder=0,
IsTornPageDetectionEnabled, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Msdb sa 15.0 1.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Tempdb sa 23,963.0 46.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsAutoCreateStatistics,
IsAutoUpdateStatistics

User Databases
The following users databases are on Sample
Database Name Owner Data Log Options
File File
Size Size
(Mb) (Mb)
Database One sa 2,603 39 Status=ONLINE, Updateability=READ_WRITE,
UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Two sa 4.0 3.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=FULL,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Three sa 541.0 160.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=FULL,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Four mike 120.0 54.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

SQL_Health_Check_Report_Sample.doc Pg. 8 of 14
 Database Name Owner Data Log Options
File File
Size Size
(Mb) (Mb)
Database Five sa 757.0 6.0 Status=ONLINE, Updateability=READ_WRITE,
UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Six mike 11.0 6.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Seven mike 3.0 6.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Eight sa 6.0 6.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Nine mike 3.0 6.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Ten sa 68.0 2.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics, IsRecursiveTriggersEnabled

Database Eleven sa 369.0 1585.0 Status=ONLINE, Updateability=READ_ONLY,

UserAccess=RESTRICTED_USER,
Recovery=SIMPLE, Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Twelve sa 9.0 46.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER,
Recovery=BULK_LOGGED, Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Thirteen sa 9.0 46.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER,
Recovery=BULK_LOGGED, Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Fourteen sa_admin 30,643.0 4565.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

SQL_Health_Check_Report_Sample.doc Pg. 9 of 14
 Database Name Owner Data Log Options
File File
Size Size
(Mb) (Mb)
Database Fifteen sa 11,000.0 49.0 Status=ONLINE, Updateability=READ_WRITE,
UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Sixteen sa 3.0 1.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database sa 75.0 25.0 Status=ONLINE, Updateability=READ_WRITE,

Seventeen UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Eighteen sa 75.0 25.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Nineteen sa 10.0 110.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539,
Collation=SQL_Latin1_General_CP1_CI_AS,
SQLSortOrder=52, IsAutoCreateStatistics,
IsAutoUpdateStatistics

Database Twenty sa 1.0 1.0 Status=ONLINE, Updateability=READ_WRITE,

UserAccess=MULTI_USER, Recovery=SIMPLE,
Version=539, Collation=Latin1_General_CI_AS,
SQLSortOrder=0, IsTornPageDetectionEnabled,
IsAutoCreateStatistics, IsAutoUpdateStatistics

Database Findings
Status Configuration Comments

Database Owner Not all databases are owned by the SQL Login “sa”. It is
 See above
recommended that all databases are owned by “sa” as this is
the only login that cannot be dropped.
Database Options Some databases have the recovery mode set to Simple. For
production databases this is not recommended as it reduces
See above
the recoverability of the transaction logs.
Transaction Log Sizes The transaction log size for some of the production
databases appear too large compared to the data size. This
See above
has been caused by no transaction log backups being run on
the databases. The result of this is the transaction logs are
never truncated. It is recommended to shrink the transaction
log files to approximately 20% of the size of their data files.
This along with transaction log backups (see Backup &
Recovery section) will manage the size of the transaction
logs.

SQL_Health_Check_Report_Sample.doc Pg. 10 of 14
 Status Configuration Comments

Tempdb Tempdb is set to a size of 23,963MB and set to auto-grow.

 See above
This is a large file size of the tempdb, for an environment of
this size. Investigations should be considered to determine
why the tempdb data file is growing to this amount.
Database Consistency No database consistency checks have been completed on
 Checks (DBCC)
None
this server and none are scheduled.
It is strongly recommended that DBCC checks are scheduled
at least weekly, and the output of the checks reviewed.
Non-Production It appears that several non-production databases exist on
Databases this server. It is recommended to move these databases to a
non-production server.
See above

SQL_Health_Check_Report_Sample.doc Pg. 11 of 14
6 SQL Server Backup & Recovery
Given the critical nature of the data stored in these SQL databases and the high cost of data lost, all
databases have been analysed for their ability to be recovered,

From the interviews conducted as part of this health check up to 4 hours data loss is tolerable. After an
outage it is expected that the databases will be available again is 24 hours.

SQL Server Backup & Recovery Findings

Status Configuration Comments

Full database backups All databases have are backed up daily. This is appropriate
 and recommended.

Transaction log No transaction log backups are scheduled on this server. All
 backups production databases should have at least hourly transaction
log backups scheduled. These backups should be kept on
disk for at least 48 hours. This reduces the potential data
loss from 24 hours to 1 hour.
Backup file locations The database backups that are running on this server are not
backing up the databases to a local disk, these are being
F:\MSSQL\BACKUP
backed up to Veritas Backup Agent, backing up directly to
tape.
Best practice methods recommend hat databases first be
backed up to local disk, and then the database backup files
are backed up to tape. This is recommended because
backups to local disk are more reliable and faster than
backing up to tape or backing up over a network.
If backing up to a local disk first, it is also recommended to
backup to a different physical disk group than the main data
files. This improves recoverability in the case of the main
data file disk failing.
Tape Backup Schedule This is appropriate.
 Tape Library at approx.
10:00pm
Log Shipping Log shipping to a standby server is not configured for this
server. Given that only 4 hours downtime is tolerable, log
Not used
shipping should be considered as a disaster recovery option.
SQL Services provide disaster recovery expertise, involving
log shipping, if required.
Clustering This server is not installed on a Cluster Server. Given the
 Not Clustered
up-time requirements, clustering is not required.

Documentation It is recommended that the entire backup and restore

process is documented and tested. This will help speed the
recovery of the databases in the event of a disaster.

SQL_Health_Check_Report_Sample.doc Pg. 12 of 14
7 Security

Security Findings
Status Configuration Comments

System Administrators The members of the SQL Server System Administrator role
 sa
should be restricted to:
 sa
BUILTIN\Administrators
 SampleDomain\SQLExec (the account used to run
SQL)
No other users should have System Administrator rights.
“sa” password The “sa” password has been set. and is only know by
system administrators.
Set
However the “sa” password has never been changed since
the installation of SQL Server. The “sa” password should
be changed on a regular basis, and kept in a secure and
safe place.
Authentication Mode The SQL Server authentication mode is set to both
 Mixed
Windows and SQL standard authentication. It is
recommended with SQL Server 2000 to utilise Windows
Authentication only, which improves database security
implementation and administration. However historical
application may require SQL Server authentication
Login Auditing Login auditing function should be configured to capture
 None
failed SQL Server logins. This ensures login failures are
tracked and reported which helps identify user side
connectivity issues that are often difficult to isolate
File System All SQL server files are located on NTFS volumes which is
 NTFS
appropriate from a security perspective.

Security Documentation Consideration should be given to developing a SQL Server

Security model for applications overall. This would help
standardise connectivity to SQL Server, reduce security
risks and lower ongoing security administration
requirements.

SQL_Health_Check_Report_Sample.doc Pg. 13 of 14
Appendix A – SQL Server Best Practice
The following items are recommendations relating to best practice for SQL Server that are appropriate for
this environment:
Daily backups including both the system and user databases. The SQL backups should be
completed to disk and before the nightly tape backups starts.
Transaction Log backups of user databases on at least an hourly rate. This will allow a point-in-time
recovery.
Fully documenting and testing of the recovery process will validate SQL Server and database
recoverability.
The use of proactive monitoring tools such as SQL Mail or SMTP mail will verify backup
completion.
Monitoring system alerts using proactive tools such as SQL Mail.
Regular running Database Consistency Checks (DBCC) on both the system and user databases will
detect any data corruption.
Regular database re-indexing to ensure database fragmentation is kept to a minimum.
Reviewing of the Windows Event Logs and SQL Server error logs and resolve issues as they come
up.
Regular reviews of SQL Server security requirement.
Monitoring available disk space and the growth of database devices in order to proactively plan for
future requirements.
Regular liaison with database users regarding performance and connectivity issues.
Production databases should be reviewed on a regular basis, e.g. monthly, to ensure they are set to
“Full Recovery”.
Test databases should be reviewed on a regular basis, e.g. monthly, to ensure they are set to
“Simple Recovery”.

SQL_Health_Check_Report_Sample.doc Pg. 14 of 14