SQL Server 2016 enhanced the use of DBCC Commands by adding support of MAXDOP.

A Max Degree of Parallelism (MAXDOP) is used to define some CPU threads at Server Configuration Level as well as at Query Execution Level.

I have read different SQL Forums, and Blogs about the MAXDOP and everyone is saying that the result of MAXDOP is a different basis on your system configuration.

Yes, it is true 100%. Before using MAXDOP you should check your CPU configuration and load of SQL Server.
Once you have defined MAXDOP, you must check the query execution plan and accordingly you should decide the value of MAXDOP.

We are running DBCC CHECKDB for repairing the database related issues. If your database size is huge, it requires more CPU/IO.
Now you can add MAXDOP to optimize the task of DBCC commands.

DBCC with MAXDOP:

DBCC CHECKDB (AdventureWorks2016CTP3)
WITH MAXDOP = 2;

DBCC CHECKTABLE ('Person.AddressType')
WITH MAXDOP = 2;

Related Article:

SQL Server: Monitor and Manage Database Corruption

In this post, I am sharing a way to check the execution history of DBA command like DBCC CHECKDB in SQL Server.

Why is this important?

DBCC CHECKDB is important for SQL Database which is fixing and showing critical errors. But if your database size is huge and some other DBA already executed DBCC CHECKDB then?

Do you need to run again? – The answer is NO.

If you have a big size of the database, DBCC CHECKDB requires more time to complete the execution.

The solution:

Before executing DBCC CHECKDB, you should check the execution history of it.
You can do using sp_readerrorlog, which is an undocumented system stored procedure.

Using this, you can read the contents of SQL Server error log files, and you can also perform a search using your keywords.

Syntax of sp_readerrorlog:

EXEC sp_readerrorlog  <LogNumber>, <LogType>, <SearchTerm1>, <SearchTerm2>

Log number 0= current log
Log type 1= read SQL Server error logs

EXEC sp_readerrorlog 0, 1, 'DBCC CHECKDB'

Sample result:

In this post, I am sharing DBCC CHECKDB with option EXTENDED_LOGICAL_CHECKS of SQL Server.

If you execute only DBCC CHECKDB, excludes other logical checks like persisted columns, indexed views, filtered indexes which improve the overall performance of it.

If you run DBCC CHECKDB with option EXTENDED_LOGICAL_CHECKS, it does logical checks like indexed views, XML indexes, and spatial indexes.
You can also use EXTENDED_LOGICAL_CHECKS with DBCC CHECKTABLE.

The syntax is:

DBCC CHECKDB(Db_Name) WITH EXTENDED_LOGICAL_CHECKS
GO
DBCC CHECKTABLE(Table_Name) WITH EXTENDED_LOGICAL_CHECKS
GO

I executed DBCC CHECKTABLE on one of my tables, and I got below error.
“table ‘tbl_students’ (ID 6589332541). Data row does not have a matching index row in the index ‘idx_tbl_students_id’ (ID 88). Possible missing or invalid keys for the index row matching.”

The above error is indicating the corruption of index “idx_tbl_students_id” so few records are missing.
If your index corrupted, there are two possible solutions. One is Restore your database backup and Second is Rebuild your corrupted indexes.

People are using REBUILD command for rebuilding the indexes, but in this article, I repaired the index using option REPAIR_REBUILD of DBCC.

You can use the REPAIR_REBUILD option with DBCC CHECKDB and DBCC CHECKTABLE. While executing those DBCC commands, you can repair corrupted indexes.

This can include quick repairs, such as repairing missing rows in non-clustered indexes, and more time-consuming repairs, such as rebuilding an index.

Following are example,

DBCC CHECKDB ('Database_Name', REPAIR_REBUILD)
DBCC CHECKTABLE ('Table_Name', REPAIR_REBUILD)

You can use below article and find script to rebuild all indexes of SQL Server Database:

SQL Server: T-SQL Script to Rebuild all Indexes of a Database

Recently, I shared one article about Database is stuck in “In Recovery” mode after the restart of SQL Server.

SQL Server: After Restart, Database in “In Recovery” status, Can’t Access it

In this post, I am going to share necessary steps to recover a database from the SUSPECT Mode. If your database in SUSPECT mode, you cannot access it.

There are several reasons behind the SUSPECT Mode like a hardware issue, transaction log file is corrupt, missing transaction log file, improper shutdown or restart of SQL Server, page or disk is corrupt and other much more.

You can check the SQL Server error logs which give you more details.

Action steps to recover a database from SUSPECT Mode to ONLINE Mode:

Change the database status to EMERGENCY Mode:

ALTER DATABASE database_name SET  EMERGENCY

Now administrator can access your database and execute DBCC CHECKDB next:

DBCC CHECKDB('database_name')

Bring the SQL Database into Single user mode:

ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Re-Run DBCC CHECKDB with repari options:
It repairs the database and fixes the error, but there are chance of data loss.

DBCC CHECKDB (database_name, REPAIR_ALLOW_DATA_LOSS)

If you get success message, change the database mode from single-user mode to multi-user mode.

ALTER DATABASE database_name SET MULTI_USER

In this post, I am going to provide necessary information to monitor and manage Database Corruption of SQL Server.

As we are Database Administrator, so this is our responsibility to find data corruption of the database before it crashes.

You can monitor corrupted database page using one system table of MSDB.
Please execute below statement to find information about corruption.

SELECT * FROM msdb.dbo.suspect_pages
WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);

This corrupted page logged in different situations.

• 824 error : Torn pages error.
• 823 error: Disk or Hardware error.
• DBCC repaired the page.
• Bad checksum.
• DBCC deallocation.
• Restored Database with Bad marked.

How to deal with this corrupted pages?

The first step, execute DBCC CHECKDB.

DBCC CHECKDB () WITH NO_INFOMSGS, ALL_ERRORMSGS

You should check your database backup strategy and recovery model.
If corruption happens and not resolved yet, you can restore a fresh backup.

Another best practice is to take the full database object script for Database structure.
You can also use any other third-party recovery tools.