• Home
  • Contact

John Sansom

SQL Server DBA Blog

  • About
    • The Blog
    • John Sansom
    • Contact
  • Ebook
  • Archives
    • Start Here
    • Popular Posts
    • All Posts
    • SFTW
  • Becoming a DBA
    • What it’s Really Like
    • Interview Tips
    • Certification
    • FAQ
  • Books
  • Resources
    • Blog Tools and Technology
    • UK Events Schedule
    • References & Resource Lists
  • Subscribe

Simplify Your DBCC CHECKDB Output

July 14, 2010 by John Sansom 2 Comments

Defend Your Data

“Defend Your Data”

If you’re a SQL Server Database Administrator and you don’t know what CHECKDB is then you need to stop whatever it is your are doing right now and read this. Seriously, just go ahead and do it now. It will only take you ten minutes to get to grips with the basics and it could save not only your job but also the company you work for. CHECKDB is arguably the most valuable tool in the DBA toolkit and you would be a fool to miss it.

Now as I’m sure you already know, when you perform a DBCC CHECKDB operation, by default you will be provided with a considerable amount of informational output, not all of which you may be interested in.

If like me, you like to make life easy for yourself and you are really only interested in output pertaining to any errors that have been found, then you will pleased to hear of the handy argument NO_INFOMSGS available to you (see example below). Using this argument with your CHECKDB operations will suppress “informational only” output, leaving you in a position to more easily identify any errors that may have been reported.

DBCC CHECKDB(‘DatabaseName’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Note: Technically you do not need to use the ALL_ERRORMSGS argument for errors to be displayed in the more recent versions of SQL Server as this is the default behaviour however, if like a lot of DBA’s you manage multiple versions of SQL Server then it’s good practice to include it in order to be absolutely certain you will get the output your desire across the board.

Life’s complicated enough as it is, so let’s keep things simple when we can.

Similar Posts on “keeping things simple” and “looking after your data”

  • DBA Survival Skills – Think Defensively
  • TLC and SQL Server Error Log Management
  • SQL Server Essentials – Part 1: The Database Administrator’s Primary Responsibility
  • SQL Server Essentials – Part 2: Why you should be using the FULL Recovery Model

Filed Under: Administration, SQL Server Tips, SQLServerCentral Syndication, SQLServerPedia Syndication

About John Sansom

I’m a Microsoft Certified Master(MCM) of SQL Server. I’ve been working with database technology in a variety of flavors for over fifteen years. I absolutely love what I do and genuinely feel privileged to be a part of our tremendous technology community. Got a question about SQL Server or being a DBA? Ask me!

Popular Articles

  • Top 10 Free SQL Server Tools
  • Performing fast SQL Server delete operations
  • How to identify the most costly SQL Server queries using DMV’s
  • Top 10 Junior DBA Interview Tips
  • The Database Administrator’s Primary Responsibility
  • Your Road to Becoming a DBA: Laying a Strong Foundation
  • Top 5 SQL Forums
  • SQL Server Memory Configuration, Determining MemToLeave Settings
  • Script SQL Server Agent Jobs Using PowerShell
  • Using sys.dm_os_ring_buffers to Troubleshoot Connectivity Issues

Categories

  • Administration (38)
  • Blogging (8)
  • Customer Service (5)
  • Disaster Recovery (5)
  • DMVs (4)
  • Index Optimisation (6)
  • Interviews (1)
  • Link Posts (243)
  • Memory (2)
  • Performance Tuning (15)
  • Professional Development (70)
  • Reporting Services (5)
  • Reviews (1)
  • SQL Server Community (144)
  • SQL Server Tips (11)
  • SQLServerCentral Syndication (112)
  • SQLServerPedia Syndication (116)
  • Tools (7)

Copyright © 2023 · Santech Solutions Limited · Powered by the Genesis Framework · Privacy Policy