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. Read the rest of this entry »
There exists an abundance of situations where you do not have complete backup of your SQL Server database and you require restoring the database on a server without its transaction log. There are methods using which you can attach your primary database file (‘.MDF’) to the server without having the associated transaction log file. However, you need to shut down your database cleanly in order for accomplishing the desired task successfully without errors. You can do so either using SQL Server Management Studio or by running a set of T-SQL statements. Let us delve deeper into the situation and discuss these two workarounds: Read the rest of this entry »
Backups are the best line of defense against data disasters. This rule of thumb holds true even for SQL Server databases. MS SQL Server includes a backup and restore component that enables you to create backups of SQL Server databases and restore these backups as and when needed. With this useful functionality, you can easily do away with all forms of media errors and user errors. Further, you can mitigate the risk of permanent loss of a server. Read the rest of this entry »
All uncommitted SQL Server transactions lead to transaction log filling up. Log space exhaustion can have serious implications for your database, such as failed UPDATE, DELETE, or INSERT queries. In a typical situation, an uncommitted transaction can give you the following error message: Read the rest of this entry »
Database repair has always been a matter of great debate and confusion among the users. Some inexperienced users believe that simply repairing the database can help them break free from all types of corruption errors and bring their database back online. However, the method used to perform repair determines how running repair is going to impact your database. In general, it is not wise to go for a repair immediately after finding corruption in the database. Let us quickly walk you through some of the common misconceptions that need to be corrected in order to better understand the purpose and scope of database repair:
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. Read the rest of this entry »
It is not uncommon for SQL Server users to have their database marked as ‘suspect‘ by the server. It is no surprise to claim that maximum percentage of downtime comes from these cases. When the database is marked ‘suspect’, you cannot connect to the database to access your data. The reason why SQL Server sets a ‘suspect’ flag is to secure your database against any potential loss of data. A typical error that shows up everytime you launch SQL Server and attempt to connect to your ‘suspect’ database is Error 9003. This error gets logged in the SQL Server error log as follows: Read the rest of this entry »
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’… Read the rest of this entry »
Getting an error message in SQL server is probably one of the most worst nightmares in database administrator life. It results in database down, customers frustration, managers shouting and so many other unpleasant things. In this article, I’m going to explain some of the steps to solve SQL server error message 8941.
“Table error: Object ID O_ID, index ID I_ID, page P_ID. Test (TEST) failed. Slot S_ID, offset 0xADDRESS is invalid.” Read the rest of this entry »
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. Read the rest of this entry »
Are you facing Access Violation error in MS SQL Server? Are you unable to access the database and its objects? Access Violation is a situation where application can not access the data because the data is either damaged or the application does not own the data. In both the cases, your database remains inaccessible and unusable. This behavior may lead to significant data loss and needs SQL Database Recovery to be fixed. Read the rest of this entry »