Professional Documents
Culture Documents
DBCC stands for database consistency checker. There are many DBCC command in SQL Server. We generally use these
commands to check the consistency of the databases, i.e., maintenance, validation task and status checks.
Dynamic management views and functions return internal, implementation-specific state data. Their schemas and the data they
return may change in future releases of SQL Server. Therefore, dynamic management views and functions in future releases may
not be compatible with the dynamic management views and functions in this release. For example, in future releases of SQL Server,
Microsoft may augment the definition of any dynamic management view by adding columns to the end of the column list. We
recommend against using the syntax SELECT * FROM dynamic_management_view_name in production code because the number
of columns returned might change and break your application.
When you execute one of these DBCC commands, the Database Engine creates a database snapshot and brings it to a
transactionally consistent state. The DBCC command then runs the checks against this snapshot. After the DBCC command is
completed, this snapshot is dropped.
Sometimes an internal database snapshot is not required or cannot be created. When this occurs, the DBCC command executes
against the actual database. If the database is online, the DBCC command uses table-locking to ensure the consistency of the
objects that it is checking. This behavior is the same as if the WITH TABLOCK option were specified.
An internal database snapshot is not created when a DBCC command is executed:
• Against master, and the instance of SQL Server is running in single-user mode.
• Against a database other than master, but the database has been put in single-user mode by using the ALTER DATABASE
statement.
• Against a read-only database.
• Against a database that has been set in emergency mode by using the ALTER DATABASE statement.
• Against tempdb. In this case, a database snapshot cannot be created because of internal restrictions.
1. Object Integrity
2. Linkages for text, ntext, and image pages
3. Index and data pages are correctly linked.
4. Indexes are in their proper sort order.
5. Pointers are consistent.
6. The data on each page is reasonable (Allocation Checks).
7. Page offsets are reasonable.
DMVs can be used in the gathering of baseline information and for diagnosing performance problems. Few important dmvs are:
1. sys.dm_os_performance_counters
2. sys.dm_db_index_physical_stats
3. sys.dm_db_index_usage_stats
6) Please explain DMV Categories?
Category Prefix
Database Sys.dm_db_*
Indexing Sys.dm_db_index_*
Execution Sys.dm_exec_*
I/O Sys.dm_io_*
Replication Sys.dm_repl_*
Transactions Sys.dm_tran_*
Object Sys.dm_sql_*
Sys.dm_xe_*
SQL Server Extended Events
Sys.dm_cryptographic_*
Sys.dm_provider_*
Security
Sys.dm_audit_*
7) What are all the SQL Server Dynamic Management Views(DMV) and Dynamic management functions(DMF) available
in SQL Server?
Use below query to list out all available DMVs present in a SQL Installation :-
SELECT name, type, type_desc FROM sys.system_objects WHERE name LIKE ‘dm[_]%’
ORDER BY name
11) While viewing activity on SQL Server , for example, sp_who2 – the status column displays different states –
RUNNABLE – SUSPENDED – RUNNING. Could you explain the difference?
Some background information on the SQL Schedulers , will make understanding the RUNNABLE – SUSPENDED –
RUNNING model clearer.
Schedulers are made up of three parts . A thread cycles though these three parts
1) Processor
2) Waiter list – threads waiting for resources. Use Sys.dm_os_waiting_tasks to view resource waits for the resources
3) Runnable – thread has all the resources and waiting for the processor. Explore runnable status with the sys.dm_os_schedulers
and sys.dm_exec_requests DMVs
This leads us into the RUNNABLE – SUSPENDED – RUNNING
1) RUNNING – thread is executing on the server
2) SUSPENDED – thread is waiting for resources to become available.
3) RUNNABLE – the thread is waiting to execute on the processor
18) Which DBCC command is used to store the Procedure cache related information?
DBCC PROCCACHE – This command will show you information about the procedure cache and how much is being used.
20) How can you check if any transaction is running on a database or not?
We can use DBCC OPENTRAN to check any running transaction on the database. It is one of the most commonly used DBCC
command along with DBCC CHECKDB, DBCC SHRINKFILE, DBCC SQLPERF(logspace) etc.
21) Can anyone predict how long DBCC Checkdb will run on any database?
As far as estimating how long DBCC CHECKDB will take to run on a given database, it’s very difficult to tell because there are so
many variables involved. The following are some factors that affect DBCC CHECKDB’s run time:
• The size of the database. This one’s not so obvious—it’s not the size of the database that matters, it’s the amount of data that’s
in it.
• The load on the system. DBCC CHECKDB is extremely resource hungry—I like to say it’s the most resource-intensive operation
you can run on SQL Server. Therefore, if the server is already heavily loaded, DBCC CHECKDB will be competing for resources
and will take a lot longer to run.
• The capabilities of the system. If the database being consistency checked is very large and structurally complicated, but the
server and/or I/O subsystem are heavily underpowered, this will have a knock-on effect on the ability of the server to provide the
resources DBCC CHECKDB needs, slowing it down.
• The options specified. If the WITH PHYSICAL_ONLY option is specified, the amount of processing that DBCC CHECKDB does
is drastically cut down, which usually leads to a significant reduction in run time.
• The complexity of the database schema. The more features that you use in the database, the more structures there are to be
consistency checked, so DBCC CHECKDB will take longer to run.
• The corruptions that are found. Some corruptions require deeper reprocessing of data to figure out exactly where the corruption
is. This can lead to a much longer run time for DBCC CHECKDB.
• The tempdb configuration. DBCC CHECKDB uses a lot of memory to store intermediate consistency checking data, and that
storage usually spills out to the tempdb database. If tempdb isn’t configured well, it can be a bottleneck for DBCC CHECKDB and
slow it down.
As you can see, there are too many factors involved to be able to make a good guess. The best way to know how long DBCC
CHECKDB will take is to run it.
22) What is the effect of DBCC CHECKDB and DBCC DBREINDEX on the Transaction log?
DBCC DBREINDEX is an offline operation is used to rebuild the indexes of a table dynamically. This operation requires enough
space in the data files. If the space is not enough DBCC DBREINDEX may be unable to rebuild the indexes.
DBCC CHECKDB is used to produce a consistent view of the data by performing a physical consistency check on indexed views,
validating integrity of the indexes, objects etc. in earlier versions of SQL, this required locking. Newer versions involve reading the
transaction log of the oldest active transaction. REDO and UNDO of the transactions affect the volatile changes to available free
space.
23) How can DMVs help with performance tuning?
Helps to find out the queries that are causing memory or CPU pressure on your system
Helps to investigate caching, and query plan reuse
Helps to identify index usage patterns
Helps to track fragmentation in clustered indexes and heaps
Gives full details on blocking and blocked transactions
25) How are DMV’s and DMF’s changing the memory consumptions of SQL Server? consider the dm_exec_* which store
the results of the current workload.
DMV’s are in-memory structures and are anyway’s used by SQL Server internally. It is with SQL Server 2005 that we started
exposing them in an official manner rather than doing bit-manipulations with some DBCC commands. Hence there is nothing to be
worried about the load or memory consumptions. It is not as alarming as you think.
26) Which DMV give me query plan or I will use old method to find query plan?
Below DMVs can be used to provide query plan related information :-
sys.dm_exec_query_stats
sys.dm_exec_sql_text
sys.dm_exec_query_plan
sys.dm_db_file_space_usage
sys.dm_db_partition_stats
sys.dm_db_session_space_usage
sys.dm_db_task_space_usage
30) Which DMVs are useful to gather information about database mirroring :-
sys.dm_db_mirroring_connections
sys.dm_db_mirroring_auto_page_repair
31) What are the most important DMVs\DMFs from a DBA perspective.
Execution Related
• sys.dm_exec_connections
• sys.dm_exec_sessions
• sys.dm_exec_requests
• sys.dm_exec_cached_plans
• sys.dm_exec_query_plans
• sys.dm_exec_sql_text
• sys.dm_exec_query_stats
Index Related
• sys.dm_db_index_physical_stats
• sys.dm_db_index_usage_stats
SQL Server Operating System
• sys.dm_os_performance_counters
• sys.dm_os_schedulers
• sys.dm_os_nodes
• sys.dm_os_waiting_tasks
• sys.dm_os_wait_stats
I/O Related
• sys.dm_io_virtual_file_stats