Search

Tuesday, January 4, 2011

How to Recover Mismatch Error in the Object ID of SQL Server

DBCC CHECKALLOC is a general command which is used by database administrators to check the consistency of disk space. This command comprehensively finds the used and allocation of all database pages in your specified database. However, if examining a pages, the command shows an error message, then it means that your database pages have been damaged or corrupted. Furthermore, the records stored in the database become inaccessible after the error message appears. The best way to access your data in such situation is by restoring the data from a clean backup. But if in case, your backup is not updated, then you will need to use SQL Database Recoverysoftware to repair your database.

Take a practical scenario, you encounter the below error message when you try to run DBCC CHECKALLOC command:

"Table error: Page %S_PGID is allocated to object ID %d, index ID %d, not to object ID %d, index ID %d found in page header."

After the above error message appears on your screen, the data (record) stored in the database becomes inaccessible.

Cause

The main cause for the occurrence of above error message is that DBCC CHECKALLOC command has found a mismatch in the Object ID between extents and sysindexes.

Resolution

For resolving the above error message, you will have to follow the below mentioned steps:

1.Find the index ID which is connected with the page number highlighted in the error message to find error occurred on table data or on the index.

2. After that, restore the database after analyzing the below situations:

  • If the Value of Object ID in the error message contains less than or equal to hundred, that means system table is corrupted. In this situations, restore the database from an updated backup.

  • If the Value of Object ID in the error message is greater than 100, that means error is in user table. In this case restore the table only.

However, if the above procedure fail to resolve your problem and the above error message still persists, then you will need to use a third-party sql database repair software to repair your database.

Monday, January 3, 2011

What should you do when CHECKTABLE ends abruptly resulting in Error 8921 in MS SQL Server

In MS SQL Server 2000, there are various tools to check the integrity of the database pages. One of these tools is CHECKTABLE that checks various types of pages including data, index, text, ntext, and image of the selected table. However, at times this tool is unable to run and ends abruptly because of corruption in the MDF (Master Database File) file. On such occasions, you should use suitable methods to repair SQL database. If none of the methods works in this scenario, then I would recommend you to use a third-party SQL repair software to repair SQL database.

Consider a scenario wherein you are using the CHECKTABLE tool when you get the following error message in MS SQL Server 2000 database:

“CHECKTABLE terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.”

Cause:

The CHECKTABLE tool abruptly ended because of encountering some error because of corruption issues in a system table.

Resolution:

To overcome this problem, you should look for ways to repair MDF file. For this, the following methods can be performed:

  • Addressing hardware corruption issues: As is seen in such cases, most instances occur because of corruption in the hardware parts. To overcome hardware corruption, you can adopt following measures:

    • Running hardware diagnostics and fixing any error that you find

    • Checking error logs and check if any error has occurred because of faulty hardware components

    • Swapping the hardware components to narrow down to find out the exact error

    • Formatting the hard drives and reinstalling the operating system

  • Using database backup: If the hardware parts are alright, then use the database backup if it is updated and clean.

  • Running DBCC CHECKDB: If the database backup does not provide solution, then run the DBCC CHECKDB tool with the suggested repair clause.

Now, try to run the CHECKTABLE tool again. If the problem does not appear, then it means that the MDF file is repaired. However, if the problem persists then there is a need to use a third-party MDF file repair software. Non-destructive repair techniques and simple yet interactive interface are some of the advantages of using these MS SQL repair tools.

10 reasons why SQL Server 2008 is going to rock

Just like its predecessor, SQL Server 2008 is taking its sweet time to actually ship. However, unlike its predecessor, it won't just be a "worthwhile upgrade". It will kick ass.
Here are the top 10 reasons why.
10. Plug-in model for SSMS. SSMS 2005 also had a plug-in model, but it was not published, so the few developers that braved that environment were flying blind. Apparently for 2008, the plug-in model will be published and a thousand add-ins will bloom.
9. Inline variable assignment. I often wondered why, as a language, SQL languishes behind the times. I mean, it has barely any modern syntactic sugar. Well, in this version, they are at least scratching the the tip of the iceberg.
Instead of:
DECLARE @myVar int 
SET @myVar = 5

you can do it in one line:
DECLARE @myVar int = 5

Sweet.
8. C like math syntax. SET @i += 5. Enough said. They finally let a C# developer on the SQL team.
7. Auditing. It's a 10 dollar word for storing changes to your data for later review, debugging or in response to regulatory laws. It's a thankless and a mundane task and no one is ever excited by the prospect of writing triggers to handle it. SQL Server 2008 introduces automatic auditing, so we can now check one thing off our to do list.
6. Compression. You may think that this feature is a waste of time, but it's not what it sounds like. The release will offer row-level and page-level compression. The compression mostly takes place on the metadata. For instance, page compression will store common data for affected rows in a single place.
The metadata storage for variable length fields is going to be completely crazy: they are pushing things into bits (instead of bytes). For instance, length of the varchar will be stored in 3 bits.
Anyway, I don't really care about space savings - storage is cheap. What I do care about is that the feature promised (key word here "promises") to reduce I/O and RAM utilization, while increasing CPU utilization. Every single performance problem I ever dealt with had to do with I/O overloading. Will see how this plays out. I am skeptical until I see some real world production benchmarks.
5. Filtered Indexes. This is another feature that sounds great - will have to see how it plays out. Anyway, it allows you to create an index while specifying what rows are not to be in the index. For example, index all rows where Status != null. Theoretically, it'll get rid of all the dead weight in the index, allowing for faster queries.
4. Resource governor. All I can say is FINALLY. Sybase has had it since version 12 (that's last millennium, people). Basically it allows the DBA to specify how much resources (e.g. CPU/RAM) each user is entitled to. At the very least, it'll prevent people, with sparse SQL knowledge from shooting off a query with a Cartesian product and bringing down the box.
Actually Sybase is still ahead of MS on this feature. Its ASE server allows you to prioritize one user over another - a feature that I found immensely useful.
3. Plan freezing. This is a solution to my personal pet peeve. Sometimes SQL Server decides to change its plan on you (in response to data changes, etc...). If you've achieved your optimal query plan, now you can stick with it. Yeah, I know, hints are evil, but there are situations when you want to take a hammer to SQL Server - well, this is the chill pill.
2. Processing of delimited strings. This is awesome and I could have used this feature...well, always. Currently, we pass in delimited strings in the following manner:
exec sp_MySproc 'murphy,35;galen,31;samuels,27;colton,42'

Then the stored proc needs to parse the string into a usable form - a mindless task.
In 2008, Microsoft introduced Table Value Parameters (TVP).
CREATE TYPE PeepsType AS TABLE (Name varchar(20), Age int) 
DECLARE @myPeeps PeepsType 
INSERT @myPeeps SELECT 'murphy', 35 
INSERT @myPeeps SELECT 'galen', 31 
INSERT @myPeeps SELECT 'samuels', 27 
INSERT @myPeeps SELECT 'colton', 42
 
exec sp_MySproc2 @myPeeps 

And the sproc would look like this:
CREATE PROCEDURE sp_MySproc2(@myPeeps PeepsType READONLY) ...

The advantage here is that you can treat the Table Type as a regular table, use it in joins, etc. Say goodbye to all those string parsing routines.
1. Intellisense in the SQL Server Management Studio (SSMS). This has been previously possible in SQL Server 2000 and 2005 with use of 3rd party add-ins like SQL Prompt ($195). But these tools are a horrible hack at best (e.g. they hook into the editor window and try to interpret what the application is doing).
Built-in intellisense is huge - it means new people can easily learn the database schema as they go

Saturday, January 1, 2011

Generating SQL Server Test Data with Visual Studio 2010

Generating SQL Server Test Data with Visual Studio 2010

Difference between LINQ and Stored Procedures?

There are couple of advantage of LINQ over stored procedures.

1. Debugging - It is really very hard to debug the Stored procedure but as LINQ is part of .NET, you can use visual studio's debugger to debug the queries.

2. Deployment - With stored procedures, we need to provide an additional script for stored procedures but with LINQ everything gets complied into single DLL hence deployment becomes easy.

3. Type Safety - LINQ is type safe, so queries errors are type checked at compile time. It is really good to encounter an error when compiling rather than runtime exception!