Next, you are going to find out a little
bit about the network configuration settings on the database server
with the query shown in Listing 12.
LISTING 12: TCP Listener information
-- Get information about TCP Listener for SQL Server
SELECT listener_id, ip_address, is_ipv4, port, type_desc, state_desc, start_time
FROM sys.dm_tcp_listener_states WITH (NOLOCK) OPTION (RECOMPILE);
-- Helpful for network and connectivity troubleshooting
This DMV, which was added in SQL Server 2008 R2
SP1, tells you which TCP ports are being used by the TCP Listener — for
T-SQL, the Service Broker, and database mirroring. This is useful
information for troubleshooting general network connectivity and
firewall issues. It is also useful for investigating connectivity
issues with SQL Server AlwaysOn availability replicas.
The next query, shown in Listing 13, provides SQL Server–related information collected from the Windows Registry, using the sys.dm_server_registry DMV that was added in SQL Server 2008 R2 SP1.
LISTING 13: SQL Server Registry information
-- SQL Server Registry information
SELECT registry_key, value_name, value_data
FROM sys.dm_server_registry WITH (NOLOCK) OPTION (RECOMPILE);
-- This lets you safely read some SQL Server related
-- information from the Windows Registry
This query, which was added in SQL Server 2008 R2
SP1, gives you quite a bit of useful information about your SQL Server
instance, such as which network protocols are enabled, where the SQL
Server main executable is located, and where the SQL Server Agent
executable is installed. This is safer and easier to use than the old xp_instance_regread extended stored procedure, although it admittedly does not allow you to query as many different values.
Next, to investigate whether this instance of SQL Server has been generating any memory dumps, you can use the query shown in Listing 14.
LISTING 14: SQL Server memory dump information
-- Get information on location, time and size of any memory dumps from SQL Server
SELECT [filename], creation_time, size_in_bytes
FROM sys.dm_server_memory_dumps WITH (NOLOCK) OPTION (RECOMPILE);
-- This will not return any rows if you have
-- not had any memory dumps (which is a good thing)
This query, which was also added in SQL Server
2008 R2 SP1, tells you if and when your SQL Server instance has
generated any memory dumps. Hopefully, you will not see any results for
this query. If you do, start looking in the SQL Server Error Log(s)
that correspond to the times for the SQL Server memory dumps to see if
you can find any relevant information about what happened to generate
the memory dump. You should also look at the Windows Event logs, and
maybe even get ready to open a support case with Microsoft.
Next, to find out how many databases are running
on your SQL Server instance, and where they are located, use the query
shown in Listing 15.
LISTING 15: Database filenames and paths
-- File Names and Paths for Tempdb and all user databases in instance
SELECT DB_NAME([database_id])AS [Database Name],
[file_id], name, physical_name, type_desc, state_desc,
CONVERT( bigint, size/128.0) AS [Total Size in MB]
FROM sys.master_files WITH (NOLOCK)
WHERE [database_id] > 4
AND [database_id] <> 32767
OR [database_id] = 2
ORDER BY DB_NAME([database_id]) OPTION (RECOMPILE);
-- Things to look at:
-- Are data files and log files on different drives?
-- Is everything on the C: drive?
-- Is TempDB on dedicated drives?
-- Are there multiple data files?
This query returns the file paths and sizes for the data and log files for all the user databases and tempdb. If the type_desc column is ROWS, that means you have a data file, whereas LOG
means a transaction log file. This query tells you how many user
databases are running on the instance and how large they are, which
gives you some idea of the complexity of the server’s workload.
You should be looking to see whether the data and
log files are on different drive letters. Some SAN administrators like
to provision just one large LUN, which makes it harder to track what is
going on from SQL Server and Windows. You also want to ensure that
tempdb is not running on the C: drive of the database server (which is
what happens with a default standalone installation of SQL Server). You
can also see whether there are multiple tempdb data files instead of
just one , and whether the larger user databases have
multiple data files instead of just one large data file.
Next, you are going to discover some key database properties for all the databases on the instance, using the query shown in Listing 16.
LISTING 16: Database property information
-- Recovery model, log reuse wait description, log file size, log usage size
-- and compatibility level for all databases on instance
SELECT db.[name] AS [Database Name], db.recovery_model_desc AS [Recovery Model],
db.log_reuse_wait_desc AS [Log Reuse Wait Description],
ls.cntr_value AS [Log Size (KB)], lu.cntr_value AS [Log Used (KB)],
CAST(CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)AS DECIMAL(18,2)) *
100 AS
[Log Used %], db.[compatibility_level] AS [DB Compatibility Level],
db.page_verify_option_desc AS [Page Verify Option], db.is_auto_create_stats_on,
db.is_auto_update_stats_on, db.is_auto_update_stats_async_on,
db.is_parameterization_forced,
db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on,
is_auto_shrink_on, is_auto_close_on
FROM sys.databases AS db WITH (NOLOCK)
INNER JOIN sys.dm_os_performance_counters AS lu WITH (NOLOCK)
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls WITH (NOLOCK)
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N’Log File(s) Used Size (KB)%’
AND ls.counter_name LIKE N’Log File(s) Size (KB)%’
AND ls.cntr_value > 0 OPTION (RECOMPILE);
-- Things to look at:
-- How many databases are on the instance?
-- What recovery models are they using?
-- What is the log reuse wait description?
-- How full are the transaction logs ?
-- What compatibility level are they on?
This query returns all the databases on the
instance, including the system databases. For each database, a number
of important database properties are listed. First is the recovery
model for the database, which can be SIMPLE, FULL, or BULK-LOGGED.
Knowing the recovery model for each of your user databases is
critically important! Next, you get the log reuse wait description for
each database, which tells you what is preventing the active portion of
the transaction log from being reused.
One of the most common mistakes made by novice DBAs is to have a database running in the default recovery model of FULL
without taking regular transaction log backups. When this happens, the
transaction log eventually fills up completely and attempts to autogrow
the transaction log file (if autogrow is enabled). If the transaction
log is able to autogrow, it continues to do so each time it fills up,
until at some point it completely fills up the disk where it is
located. When this happens, you will have a read-only database until
you do something to correct the issue. While this is happening, your
log reuse wait description for that database will show up as LOG BACKUP.
Regularly monitoring your log reuse wait
description for each database also alerts you about other problems you
need to investigate. For example, if you are using database mirroring
and there are any problems with mirroring (such as not being able to
send the log activity to the mirror or not being able to apply the log
activity fast enough on the mirror), you will see a log reuse wait
description of DATABASE MIRRORING. Other common log reuse wait descriptions that bear further investigation include REPLICATION and ACTIVE TRANSACTION.
This query also tells you how large your
transaction log file is for each database, and how full it is, which is
good information to know! I don’t like to see a transaction log become
more than 50% full. If that is happening, you can either make the
transaction log file bigger or take more frequent transaction log
backups.
Finally, you are retrieving a number of
other important database-level properties for each database on the
instance, including the compatibility level, the page verify option,
auto create statistics, auto update statistics, auto update statistics
asynchronously , forced parameterization, and the
snapshot isolation level.
