Cloud Migration Made Easy

Considering a move to the cloud? Axial SQL brings you proven migration strategies to streamline your transition. Our expert team ensures a smooth, efficient shift, keeping your data safe and accessible. Start your journey to the cloud with confidence!

SQL Performance Optimization

Is your SQL running slower than expected? Don't let sluggish performance hinder your business. Our optimization experts at Axial SQL specialize in tuning your databases for peak performance. Speed up your SQL and supercharge your data processing today!

Database Stability Solutions

Tired of frequent database outages? Discover stability with Axial SQL! Our comprehensive analysis identifies and resolves your database vulnerabilities. Enhance reliability, reduce downtime, and keep your operations running smoothly with our expert guidance.

Expert Database Team Evaluation

Questioning your database team's efficiency? Let Axial SQL provide an expert, unbiased analysis. We assess your team's strategies and workflows, offering insights and improvements to boost productivity. Elevate your database management to new heights!

Data Security Assurance

Concerned about your database security? Axial SQL is here to fortify your data defenses. Our specialized security assessments identify potential risks and implement robust protections. Keep your sensitive data secure and your peace of mind intact with our expert services.

Published on

July 26, 2019

Understanding SQL Server DBCC CHECKDB WITH PHYSICAL_ONLY

As a SQL Server professional, I often come across various issues and bugs that can be quite puzzling. Recently, I encountered a strange bug related to the DBCC CHECKDB command in SQL Server 2017. In this blog post, I will share my experience and explain the details of this bug.

One of my clients, who had previously used my Comprehensive Database Performance Health Check service, reached out to me with a peculiar problem. They were facing an error when running DBCC CHECKDB WITH PHYSICAL_ONLY, but the same command succeeded when running DBCC CHECKDB. This inconsistency was quite surprising, as usually, if DBCC CHECKDB WITH PHYSICAL_ONLY fails, it is also caught by DBCC CHECKDB.

Upon further investigation, I discovered that the issue was related to the presence of a ColumnStore index on one of the tables in the database. When we removed the ColumnStore index, the error disappeared. Intrigued by this behavior, I decided to search for more information on the internet.

My search led me to a bug report related to the latest version of SQL Server 2017. It turns out that if a database contains a table with a clustered ColumnStore index, running the statement DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS, PHYSICAL_ONLY generates a dump file with an error message. This bug has been acknowledged by Microsoft, and they claim to have fixed it in Cumulative Update 11. However, it seems that the bug still persists in the latest version of SQL Server.

Until this bug is completely resolved, I recommend relying solely on DBCC CHECKDB without the PHYSICAL_ONLY option. This will ensure that you do not encounter any unexpected errors related to ColumnStore indexes.

As SQL Server professionals, it is important for us to stay updated with the latest bugs and issues in the software we work with. By being aware of such problems, we can avoid potential pitfalls and provide better solutions to our clients.

I hope this blog post has shed some light on the strange bug related to DBCC CHECKDB WITH PHYSICAL_ONLY in SQL Server 2017. If you have any questions or have encountered similar issues, feel free to leave a comment below.

Click to rate this post!

[Total: 0 Average: 0]

Let's work together

Send us a message or book free introductory meeting with us using button below.

Comprehensive 360 Degree Assessment

Data Replication

Performance Optimization

Data Security

Database Migration

Expert Consultation