Test for hardware problems with PHYSICAL_ONLY

The PHYSICAL_ONLY option in SQL Server 2000 allows you to test your database for hardware problems that may result in data loss. Contributor Serdar Yegulalp explains how to use this option.

The DBCC CHECKDB command acquired a new option in SQL Server 2000: PHYSICAL_ONLY. This option allows DBCC CHECKDB...

to perform a limited series of tests to determine whether or not the database has suffered damage that occurs when there's a physical problem with the database. Such problems may include disk errors, controller issues or other hardware-based problems that usually result in data loss, but may not show up immediately.

The syntax is simple enough:

USE
DBCC CHECKDB WITH PHYSICAL_ONLYA successful run without errors will look like this:

DBCC results for ' '.
CHECKDB found 0 allocation errors and 0 consistency errors in database ' '.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

PHYSICAL_ONLY is designed to run with as little overhead as possible, so it only checks the physical integrity of pages, as well as indexes and allocation structures. For that reason, PHYSICAL_ONLY is a good, fast way to look for torn pages, usually the most obvious sign of a hardware problem. Subtler damage, such as the logical consistency of the database's internal structures, won't be covered by this option -- but major damage caused by hardware issues gives you something much bigger to worry about!

PHYSICAL_ONLY cannot be run with any repair options, such as REPAIR_REBUILD or REPAIR_ALLOW_DATA_LOSS. If a scan with PHYSICAL_ONLY uncovers problems, you probably can't repair them on a software level. To do so might risk further damaging available data. The best plan to prevent data integrity loss is to regularly back up to another medium; running a lossy repair against a database should only be a last resort.

More information from SearchSQLServer.com

Step-by-Step Guide: Ensuring data integrity in SQL Server

Tip: Enforcing referential integrity through triggers

Tip: Preserving Unicode data integrity

If you don't have a current backup, another option to consider when faced with data loss is to run DBCC CHECKTABLE with REPAIR_ALLOW_DATA_LOSS, then make a parallel restoration of the database (restore the database from its most recent backup under a different, separate name) and selectively copy over any data that changed since the last backup to the "good" copy. This allows you to work from a known good copy and preserve whatever changes were made since the last backup.

About the author:
Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

Next Steps

MAXDOP is a new option for DBCC CHECKDB in SQL Server 2016

This was last published in September 2005

Dig Deeper on Microsoft SQL Server Performance Monitoring and Tuning

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close