Databases

Databases (47)

Sometimes you may encounter data integrity issues with one or more tables on a Microsoft SQL server. These errors may be found during a data integrity check using DBCC CHECKDB, or even via general use of the database. There are 3 options to correct the database integrity issues; safe repair, restore, and non safe repair (in that order).

Its always good practice to take an extra backup before any of these commands are run (specifically the non-safe repair option).

Safe repair using REPAIR_REBUILD:

Change the database to single user mode.

ALTER DATABASE <database_name> SET SINGLE_USER

Repair the database using a safe repair that will not cause data loss (if possible).

DBCC CHECKDB ('<database_name>', REPAIR_REBUILD)

Change the database to back to multi user mode.

Symptoms

You may receive the following message in your Microsoft SQL Server Logs:

A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.

In particular, you may find this error appears in your Microsoft SQL Server logs while performing an XML Backup, which subsequently fails.

Diagnosis

You may receive this message even if the correct isolation level is set. Execute the following query (replacing confluence-database with your database name):

Overview

Forwarded records can be bad for performance, but few are actually doing anything about it.

Lots of free space on your pages means more pages to scan, bigger backups etc.

Both forwarded records and free space on pages can be considered a type of fragmentation for a heap. This stored procedure rebuilds all fragmented heaps on a SQL Server.

Here are a couple of blog posts on the topic:

Knowing about 'Forwarded Records' can help diagnose hard to find performance issues(http://blogs.msdn.com/b/mssqlisv/archive/2006/12/01/knowing-about-forwarded-records-can-help-diagnose-hard-to-find-performance-issues.aspx)
Geek City: What's Worse Than a Table Scan?(http://sqlblog.com/blogs/kalen_delaney/archive/2008/05/25/whats-worse-than-a-table-scan.aspx)
The table scan from hell(http://sqlblog.com/blogs/hugo_kornelis/archive/2006/11/03/The-table-scan-from-hell.aspx)

Versions etc.
This script was written and tested on SQL Server 2012. It should also work on 2008 and 2008 R2.
See comment block in procedure source code for version history of the procedure.

Overview

Reading the SQL Server and SQL Server Agent errorlog files from time to time is a good idea. You can find errors that shouldn't be there. You can find messages that indicates misconfiguration. Or security issues. Also, to know the frequency for some messages can be valuable. The problem is that nobody wants to open a text file with thousands and thousands of messages and read through it.

There are of course tools and software out there to help with this, but sometimes nothing beats actually looking at the errorlog file. Every time I have look in an error file on a production server, I find surprising messages. This is regardless of whatever monitoring software is in place. Every time.

When going through an errorlog file, we want to make sure we catch the serious errors and other unexpected messages. We also quickly want to discard messages that we aren't interested in. And you don't want to spend more than about 30 minutes per SQL Server the first time you go through its errorlog files. Over time, you probably trim things so this process is just a few minutes. Here you find how I handle these things.

Overview

Encountering a suspect database or corruption in a database is a rare thing. It can happen, however, most often due to faulty hardware or operational mistakes (like deleting a transaction log file).

More information

The points below are recommendations for handling a situation where you have some type of corruption in a database or if the database goes into suspect status.

Details

This can happen following things like hardware failure, power outages, database files being locked by the Operating System (Anti-Virus, backup software etc.) or actual corruption of the database.

Attempting the repair procedure below is really a last resort.  If you have good and recent backups, then if at all possible I would perform point-in-time recovery of the database concerned, as this emergency repair can (as the name suggests) result in data loss.

If you’ve gone through all of this like I once did though, and all other avenues failed, here are the steps that fixed it for me:
EXEC sp_resetstatus 'YourDBName'
ALTER DATABASE 'YourDBName' SET EMERGENCY
(You won’t be able to query the database until it’s in EMERGENCY mode!)
DBCC CHECKDB ('YourDBName')
ALTER DATABASE YourDBName SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB ('YourDBName') WITH NO_INFOMSGS, ALL_ERRORMSGS
DBCC CHECKDB ('YourDBName', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE YourDBName SET MULTI_USER
In the end, I just had to rebuild a couple of indexes after the repair process and everything was recovered….phew!
ALTER INDEX ALL ON [YourTableName] REBUILD
Again, it’s worth stressing that this is a last resort – use a good backup/standby etc. first, if you have one!

If the master database fails, Microsoft SQL Server can be brought to its knees. See how to recognize this event and learn the steps for recovering the master database using the Enterprise Manager and the Query Analyzer.

As a Microsoft SQL Server administrator, you must know how to recover a corrupt master database. The master database stores your logins and, most importantly, the pointers to all of your databases. Without the master database, you can't successfully start SQL Server. I'm going to walk you through the process of recovering the master database in the event of corruption and show you how to rebuild the master database, if necessary.

Have a plan

It is important to have a plan for dealing with the corruption and/or failure of your master database. That will help you follow a methodical approach when disaster strikes, rather than acting too quickly under pressure. I have been in many situations where it would have been easy to panic, but I've managed to weather the storm by remaining calm and following the proper methodology when dealing with a problem.

In SQL Server 2005, we introduced a different method than in previous versions to rebuild system databases (affectionately known as "rebuild master"). You were required to use the setup.exe program with command line switches.

This is no different in SQL Server 2008 but the command line switches have changed some and the process behind the scenes to rebuild the system databases (master, model, and msdb) is also a bit different.

Currently the SQL Server 2008 Books Online only mention an option for setup called /REBUILDDATABSES (See this link) but this information is not correct so I'll outline how to do this here in this blog post. We will also get our documentation updated to reflect this information.

The syntax for using setup.exe to rebuild the system databases is as follows:

setup.exe
/QUIET
/ACTION=REBUILDDATABASE
/INSTANCENAME=instance_name
/SQLSYSADMINACCOUNTS= accounts
[/SAPWD=password]
[/SQLCOLLATION=collation_name]

Here are the details about how to use this syntax and how it works:

Hello Folks,
You might have seen my last blog post, which was a brief introduction about DBCC CHECKDB. If you want to refer it again, then please check the link;

Well I have concentrated this blog-post mainly on how to repair the database Using DBCC CHECKDB.

I have made some keynotes about it:

  • If there’s an error and DBCC CHECKDB can fix it up, then DBCC CHECKDB indicates the repair level that is needed to repair the specific errors.
  • Most of the times if the error is reported by DBCC CHECKDB, it is recommended to restore the database from a known good backup.
  • If there’s happen to be no good backup, then you have to use the repair option with DBCC CHECKDB.
  • You should also keep in mind that repairing the database is a separate operation from the normal DBCC CHECKDB because the database needs to be placed in a single user-mode with the ALTER DATABASE command before a DBCC CHECKDB can be executed with the REAPIR option.
  • So now if you want to place AdventureWorks2008R2 sample database in a single-user mode, then write the code:  
How To Repair A Suspect Database In MSSQL

Issue

You have a database in MS SQL that is tagged as (suspect) and you are unable to connect to the database.

Possible Causes

  • The database could have become corrupted.
  • There is not enough space available for the SQL Server to recover the database during startup.
  • The database cannot be opened due to inaccessible files or insufficient memory or disk space.
  • The database files are being held by operating system, third party backup software etc.
  • There was an unexpected SQL Server Shutdown, power failure or a hardware failure.

Resolution

These steps require you to have Microsoft SQL Server Management Studio installed on your computer.  If you do not have this installed please follow the steps outlined in the following article: How To Connect To Your MS SQL Database

Always back up the website before making any changes to the database . Shared hosting customers can do this through the Control Panel. Refer to Back Up Your Website Using Plesk. Dedicated server customers can back up the site either through the Control Panel, or through the Control Suite. Refer to How to Back Up a Domain Using Control Suite.

Get Help Now

Thank you for contacting us.
Your Private Investigator will call you shortly.