As SQL Server administrators lean on to new availability solutions features in SQL Server 2008, log shipping has somewhere fallen between the cracks. SQL Server 2005 brought to the table new enhancements to this high availability technology, while SQL Server 2008 gave it a miss. Log shipping can be still used as a disaster recovery solution where one or more secondary servers act as warm standbys. Other benefits of log shipping include use of secondary databases for other purposes (such as reporting) and limited read-only access to secondary databases.

There are ways with which you can use this technique meticulously to save time and minimize downtime. Let us peek into those techniques one by one.

Reversing Log Shipping

In times of disaster, it is necessary to fail over to a secondary log shipping server as quickly as possible. In order to reverse the roles of primary and standby servers, the only way out is to get the standby online, perform a full database backup, and then restore it to the original primary database. In case of large databases, this can be time-consuming and a real pain in the neck. In order to save considerable time, you can follow the given procedure to reverse log shipping roles:

• First up, disable the backup job on the primary server.
• Restore the transaction logs onto the standby server to synchronize everything between the primary and secondary server instance.
• Disable the restore jobs on the standby server.
• Perform backup of the transaction log of the primary database using NORECOVERY option.
• Restore the backup created in the above step on the standby server using RECOVERY option.
• Right-click the database on standby server, click ‘Properties’, and then select ‘Transaction Log Shipping’.

Finally, you need to make changes to the backup and secondary server settings.

Switching Between Log Shipping and Database Mirroring

Log shipping and database mirroring techniques have a lot in common. Both techniques use full database backup for initialization and require LSN chain to sync the data of primary and secondary database. Due to specific requirements, you sometimes need to drop your primary disaster recovery solution. In such instances, you can switch between the two techniques easily and avert the risks of some serious downtime. All you need to do is drop one technology and configure the other to make the switch. To do this, follow the given steps:

• Disable all backup jobs on both primary and secondary server instances.
• Drop log shipping (by removing secondary database, disabling all log shipping jobs, and running them in sequence again) or drop database mirroring.
• Configure database mirroring or log shipping (to which you are planning to switch).
• Restart the jobs disabled earlier.

If you need to fail over to the standby server for a short term, then switching between log shipping and database mirroring is your best bet.

• Launch SQL Server Management Studio and connect to the server instance.
• Go to Object Explorer, right-click ‘Databases’, and choose ‘Attach’. The ‘Attach Databases’ window appears on your screen.
• In the ‘Attach Databases’ window, click ‘Add’ below the ‘Databases to attach’ section. Select the ‘.MDF’ file for the database you need to attach in the ‘Locate Database Files’ window and click ‘OK’.
• The selected MDF file will be listed in the bottom-right pane of the ‘Attach Databases’ window. You will see that the window displays ‘Not Found’ message for the associated log file of the database you need to attach to the server. Select this log file and click ‘Remove’ at the bottom. Next, click ‘OK’ to attach the database.
• Once the database is successfully attached to the server without its transaction log, a new log file will be created by the server and stored at the same location as the data file.

Using T-SQL to Attach Your Database with Missing Transaction Log

• First up, you need to create a database using the CREATE DATABASE command with ‘ATTACH’ option. For instance, you can attach ‘Employee.mdf’ file by providing its name and location as follows:

USE [master]
GO
CREATE DATABASE [Employee] ON
( FILENAME = N’C:\Program Files\…\MSSQL\DATA\Employee.mdf’ )
FOR ATTACH
GO

Once you are finished with this, a message appears stating that a new transaction log file was successfully created for the database.

• Next, you need to verify the database consistency using DBCC CHECKDB. To do this run the following command:

DBCC CHECKDB (‘Employee’)
GO

If your database comprised multiple transaction log files that you have lost, you should use ‘ATTACH_REBUILD_LOG’ option with the CREATE DATABASE command.

You may choose to back up your SQL Server database to a tape or disk file. A set of backup media that use the same number and type of backup devices is called a media set. If a single backup operation writes to multiple backup media in a media set it is known as a backup set. Sometimes, various problems are encountered when you try to restore data from these backup sets. A typical SQL Server error that pops up when performing a restore using a backup set is shown below:

Error 3154
Severity Level 16
Message Text
The backup set holds a backup of a database other than the existing ‘%ls’ database.

SQL Server recognizes the backup set and the database to which you are restoring by the same name. It is quite often the case that you first create the database to which you need to restore the backup set with a different CREATE DATABASE statement. This implies that even if the database in the backup set and the database you created have the same name, they are indeed two different databases. When you restore to the database you created, you are very likely to receive the above error.

Resolution
You can remedy this problem using two methods. You may choose to perform overwrite of the existing database by using the ‘WITH REPLACE’ clause with the ‘RESTORE DATABASE’ command. The second option is to use a different database name when restoring the backup set. When you are restoring to a different database name, make sure that the files that will be created as a result of restore are not already present in your system and are not being used by some other database. You may consider deleting the old database and again issue the RESTORE command.

The following example shows how to use ‘WITH REPLACE’ option when issuing the ‘RESTORE DATABASE’ command:

RESTORE DATABASE AdventureWorks FROM DISK = ‘C:\BackupAdventureworks.bak’ WITH REPLACE

Some users end up choosing a wrong backup set for restore. You need to ensure that you choose the backup of the existing database.

The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION. (Microsoft OLE DB Provider for SQL Server)

This is an application error which generally indicates that the DB-Library call dbcancel() which originated from within a user-defined transaction has failed to execute properly. The call dbcancel() cancels the currently executing SQL statement by aborting and roll backing it. At the same time, the outer transaction does not get affected by the call. When this happens, it is necessary to roll back or close the transaction using the ROLLBACK TRANSACTION or COMMIT TRANSACTION statement. If the application does not close the transaction at this stage, you receive the above error on your screen.

It would be worthwhile if the application can identify the level of transaction nesting by requesting a SELECT @@TRANCOUNT. Once the application knows the transaction nesting level, it can send a COMMIT/ROLLBACK to get @@TRANCOUNT to zero. But, this should be done carefully. In case the @@TRANCOUNT at a specific time does not match with what the application expects, the application may end up aborting critical transactions using COMMIT/ROLLBACK. This is because the application is not aware of actual transactions that lead to this unintended nesting level.

A typical example of the above situation is when you use ODBC CALL syntax in a transaction to call a recursive SQL Server stored procedure. There could be two instances where the SQL Server would execute the stored procedure. The first occasion is when SET FMT ONLY is set to ON. In this case, there is a good chance that the maximum nesting level is exceeded and causes the server to roll back the transaction. As this happens internally, you may not see an error. The SQL Server executes the procedure once again. In case the nesting level is exceeded again, you will receive an error. When the SQL Server runs the stored procedure correctly and this does not exceed the maximum nesting level, you will see error 3902 as discussed above.

Workaround

• An easy workaround is to avoid calling the stored procedure via ODBC Call syntax. You can do the same in many ways with the help of ADO. One possible way is to use a command object.
• You can also choose to change settings on the connection manager. SET ‘RetainSameConnection’ property to TRUE.

Repair Won’t Lead To Data Loss
It mainly depends on the repair option being used with the DBCC command. For a majority of corruption errors, the minimum repair level needed to fix corruption is provided in the error itself. If the minimum repair level is ‘REPAIR_ALLOW_DATA_LOSS’, you are very likely to lose your data after the repair. 

Repair Should Always Be Run As Default
It isn’t always necessary or fruitful to perform repair. For instance, if your database contains a large-sized clustered index which is damaged, you won’t be able to rebuild the index unless there is sufficient free space available on your hard disk.

No Checks Are Needed After Running Repair
No, this is not always true. A few types of corruption will prevent the repair command from executing deeper checks. Once the corruption is fixed, you should rerun DBCC CHECKDB to complete all the remaining checks on your database.

Repair Can Fix Everything
The repair options of DBCC CHECKDB cannot fix all types of corruptions you may run across. Some common unrepairable corruptions include metadata corruption, PFS Page header corruption, and column value corruption.

Repair Is Safe For Fixing System Databases
As ‘model’ database does not contain user tables, the repair operation is unlikely to fix such type of database corruption. Because the master or tempdb database cannot be switched to single-user mode, no repair is possible for these two databases. If you run repair on ‘msdb’ database, you may run into additional problems.

Repairs Can Be Done Online
In order to run a repair, you need to get your database into single-user mode. This is only possible if you take it offline.

Repairs Always Fix Constraints
The repair operation does not bother about any constraints that exist in your database. You should explicitly run DBCC CHECKCONSTRAINT after a repair to examine the validity of your database constraints.

It Is Safe To Rely On Emergency Mode
If you have issues with your file system, then the Emergency mode repair might fail. Further, you cannot undo a repair done in Emergency mode.

‘Error: 9003, Severity: 20, State: 9.
The log scan number (189624:16:2) passed to log scan in database ‘BPO’ is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf).’

The above error may also occur when you use log shipping in SQL Server 2005 and your secondary database is running in ‘Standby’ mode.

Some common reasons why a database goes into ‘Suspect’ mode:

• Your database has encountered corruption.
• Startup recovery of your database has failed due to insufficient disk space or memory.
• The database files are currently in use by another program and cannot be accessed.
• SQL Server crashed abruptly due to a power spike or hardware failure.

You can get your database out of ‘suspect’ mode by following a few troubleshooting steps. First off, you need to determine all the databases that are marked ‘suspect’ by the server. Follow the below series of steps to recover a suspect database:

Use the below mentioned T-SQL code to get the names of all ‘suspect’ databases:

USE master
GO
SELECT NAME,STATE_DESC FROM SYS.DATABASES
WHERE STATE_DESC=’SUSPECT’
GO

Once you find out which databases are suspect, you can execute the below T-SQL statements to set your database to ‘Emergency’ mode.

‘USE master
GO
ALTER DATABASE BPO SET EMERGENCY
GO’

Once you have brought the database in ‘Emergency’ mode, you can execute queries as before. Further, if you have a good backup, you can restore your database from this. In case you fail to get your database up and running, use professional SQL database recovery software to regain access to your lost data. These advanced tools are adept at fixing all types of corruption in SQL Server databases. Using these tools, you can restore all or select database objects to a new SQL database.

SQL server index speed ups the querying process by offering easy access. It is created on column in the database tables or views. For example; index of a document that helps in finding the information quickly within the document. Sometimes, you may get below error during query processing on the database.

2012-12-06 09:14:53.19 spid61 Error: 644, Severity: 21, State: 5

2012-12-06 09:14:53.19 spid61 could not find the index entry for RID ’16afe06e0100000000ed170000020000′ in index page (1:16904330), index ID 2, database ‘Employee-Historial’…

Cause: Above error message appears when SQL server found index corruption in the database. As indicated by the error message, index is non-clustered because index ID is greater than 1.

Required Action: Follow below steps to solve index corruption in the database

1. Run DBCC CHECKDB: First of all run DBCC CHECKDB command on the database to determine the level of corruption.

Transact-SQL: DBCC CHECKDB Your database Name;

2. Run DBCC CHECKDB with Repair_Rebuild: Now execute DBCC CHECKDB with Repair_Rebuild clause to fix the index corruption issue.

Transact-SQL: DBCC CHECKDB Your database name with repair-rebuild;

3. Drop & Re-Create Index: If problem still persist after running DBCC CHECKDB with repair_rebuild clause then drop and re-create the affected index. To do this, follow below steps:

• Write down the value of index page & index ID from the error message.
• Index Page: (1:16904330) & Index ID: 2
• Now check which table & index match to the index page number.
• Note: If object ID is less the 100 then you can’t drop the index because this object ID corresponds to a system table. Here you have only one option that is restore from clean database backup.
• If object ID is greater than 100, drop and re-create the index using table name & index name.
• Re-execute DBCC CHECKDB on the affected database to verify that problem has been solved.

T-SQL to drop an Index: DROP INDEX Index-name ON Table-name;

T-SQL to re-create an Index: CREATE INDEX index_name ON table_name (column_name);

4. 3^rd Party SQL Repair Program: If problem still persist after performing above three steps then try an advanced SQL repair program from 3^rd party. SQL repair program is able to fix index corruption problem in the database and also supports SQL server 2000.

“Table error: Object ID O_ID, index ID I_ID, page P_ID. Test (TEST) failed. Slot S_ID, offset 0xADDRESS is invalid.”

Root Cause: SQL server gives error 8941when it found invalid offset address for the database table during testing.

How to Resolve: You can resolve SQL server error 8941 by following below steps.

Step 1: Check Hardware Problem

First of all examine the SQL Server error log to see if the error occurred due to hardware failure. If you finds that error has occurred due to hardware problem then immediately run hardware diagnostic tool & fix the problem. If you have persistent SQL database corruption issues then I will recommend you to swap out the hardware with new component.

Step 2: Try to Restore from Updated Backup

If you have verified that error 8941 has not appeared due to hardware problem then try to restore your database from clean & updated backup. If you don’t have a clean backup of the database then go with the next step.

Step 3: Run DBCC CHECKDB Command

Most of the database administrator including me recommend don’t run DBCC CHECKDB command on the database without knowing the effect of it. This command helps to resolve SQL server error 8941 when there is no clean backup available.

First of all execute DBCC CHECKDB command without a repair clause. It will determine the level of SQL database corruption & recommend a repair clause to use. Now execute DBCC CHECKDB with proper repair clause to repair SQL database corruption.

The concept of ‘Page Checksum’ debuted in SQL Server 2005. This feature is superior to the Torn Page Detection’ mechanism for identifying corrupt pages in an SQL database. However, this is achieved at the cost of incurring some amount of overhead. Overhead would be caused during every page read and write. Thus, it may possibly affect your overall performance.

I/O subsystem issues are fairly common in any real-time work environment and the main reasons for causing downtime. Database corruption is often the outcome of problems that occur at the I/O subsystem level. Checksum helps to figure out corruption caused by these failures or possibly take out the faulty I/O device from your system.

Whenever a page is written to the disk, SQL Server computes checksum for this page by verifying its bit pattern and stores the checksum in the page header. The checksum for this page is recomputed before each read and compared to the one stored its header. If the two values do not match, then it is assumed that the page got corrupt by something outside of the SQL Server environment. Checksum is enabled at the database level via ‘Alter Database’ command.

If you enable checksum for a database at the time of its creation, all pages in that database will have this setting enabled. However, if checksum is not enabled for a database initially, it will be calculated for only the pages that are written after the feature has been turned on. There is no inbuilt tool that can be used for enabling checksum computation for the pages that are not preconfigured for this. In reality though, this is not worthwhile as the page that has already become corrupt will have checksum computed based on the invalid data.

In order to verify checksum for all pages in your SQL database, you should run DBCC CHECKDB against the database with ‘PHYSICAL_ONLY’ option. This will perform a consistency check on your database with minimum overhead. After you have detected which pages are corrupt, you can fix this corruption manually by rebuilding the indexes or recovering the damaged files.

You can also take help of professional SQL database recovery software to repair and restore your corrupt database. Using these tools, you can safely recover all the damaged or inaccessible objects to a new database at any user-specified location. Further, these software support MS SQL Server 2012, 2008 R2, 2008, 2005, 2000, and 7.0.

New Added Features: Now Stellar Phoenix SQL Recovery V4.0 will support following features.

• Support for MS SQL Server 2008 R2.
• Support for fast scanning algorithms. Read the rest of this story..