Speedup msdb backup history clean-up procedure

Applicable to SQL 2005 and 2008 (R2)
 
msdb system database stores backup/restore history information. On any server where there are lots of TRN log backup and restore operations (like a production server with 5 min trn log backup for tens or hundreeds databases) msdb database could get quite large and to clean backup/restore data that is old and not needed the following stored procedure is used:
 
sp_delete_backuphistory
 
Sample SP execution is shown below:
 

DECLARE @cut_off_date DATETIME

SET @cut_off_date = DATEADD(m, -6, getdate())

EXEC msdb.dbo.[sp_delete_backuphistory] @cut_off_date

 
The SP is used with a date as an input parameter indicating that all the data prior to specified date should be removed. Naturally this operation is very slow, takes a lot of time to remove few thousands rows not to mention millions also the SP causes many locks on key MSDB tables that are involved in the backup/restore process – the lock will cause TRN log backup or Full backup process to be blocked untill the SP finishes.
 
One of the ways to improve performance of the clean-up process and to make the SP run faster is to add indexes by running a script below:
 

USE [msdb]

GO

CREATE NONCLUSTERED INDEX idx_backupset_media_set_id

ON [dbo].[backupset] ([media_set_id])

USE [msdb]

GO

CREATE NONCLUSTERED INDEX idx_restorefile_restore_history_id

ON [dbo].[restorefile] ([restore_history_id])

USE [msdb]

GO

CREATE NONCLUSTERED INDEX idx_restorefile_restore_history_id

ON [dbo].[restorehistory] ([restore_history_id])

Error after restoring published DB: The process could not execute ‘sp_repldone/sp_replcounters’

Having to restore a published database on SQL 2008 (R2), log reader issues the following error message right after the resotre is done:

“The process could not execute ‘sp_repldone/sp_replcounters’”

Reason:

The last LSN in Transaction Log is less than what the LSN Log Reader is trying to find. An old backup may have been restored on top of Published Database. After the restore, the new Transaction Log doesn’t contain the data now distributor & subscriber(s) have.

How to fix:

If an old backup was restored on top of published database then use sp_replrestart

If going back to the most recent transaction log backup is not an option then execute sp_replrestart  on publisher in published database. This stored procedure is used when the highest log sequence number (LSN) value at the Distributor does match the highest LSN value at the Publisher.

This stored procedure will insert compensating LSNs (No Operation) in the publisher database log file till one the compensating LSN becomes more than the highest distributed LSN in distribution database for this published database. After this it inserts this new high LSN in the msrepl_transactions table in the distribution database and executes sp_repldone on published database to update the internal structures to mark a new starting point for log reader agent.

Ensure that the log reader agent is stopped and there is no incoming transactions on the published database, when this SP is executed.

The following article is a valuable read covering strategies for Backup and Restore databases that are part of Snapshot or Transactional replication.

Strategies for Backing Up and Restoring Snapshot and Transactional Replication

Windows Server – Performance Counter Quick Guidance

Traditionally we have shied away from noting specific values or thresholds that are indicative of good or bad performance.  One reason for this is because coming up with good values is quite hard to do, and people sometimes see that a particular value is outside of some threshold and become fixated on that being the issue when in reality it may not be.  For example, the Windows NT Resource Kit had a section that stated that a disk queue length greater than two to three times the number of disk spindles was indicative of a performance problem.  When working with SQL Server this is not always true, especially if read ahead activity is driving the disk queue length. Just because there is a queue waiting for IO does not necessarily mean that SQL Server is stalled waiting for the IO to complete.  We have seen disk queue lengths up in the 20-30 range (on much fewer than 10 disks) where SQL Server performance was just fine.

Error: 17207 and 17204 restoring system databases to another drive

Doing a DR (disaster recovery) exercise and restore entire server on a new machine. The new server had different drive letters of SAN partitions, so all my systems databases ended up on a new drive. Clearly the SQL server didn’t start and returned the following error messages:

Event Type:    Error
Event Source:    MSSQLSERVER
Event Category:    (2)
Event ID:    17207
Date:        4/7/2009
Time:        10:19:30 AM
User:        N/A
Computer:    DRPRVM
Description:
FileMgr::StartLogFiles: Operating system error 2(The system cannot find the file specified.)
occurred while creating or opening file ‘T:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\mssqlsystemresource.ldf’.
Diagnose and correct the operating system error, and retry the operation.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Clean-up replication leftover after DB restore to another server

This one is simple yet very often overlooked execution that sometime causes problems.

You have a database “charlie” with physical files:

c:\data\charlie\charlie_Data.mdf and c:\data\charlie\charlie_log.ldf

“charlie” database is configured as a publisher for a transactional replication.

You make a copy of that database to another server by:

1. Creating a new database “bravo” with alike called physical files:

c:\data\bravo\charlie_Data.mdf and c:\data\bravo\charlie_log.ldf

2. Taking “bravo” database offline

3. Taking “charlie” database offline

4. Copy “charlie” mdf and ldf files over replacing similar files for bravo database

5. Bringing “bravo” database online

SQL 2008 SSIS failed to connect to MSDB for stored packages

On our new production server that is being installed and configured as cluster. SSIS service failed to retrieve stored in MSDB packages.

Our SQL Server version is:

Microsoft SQL Server 2008 (RTM) – 10.0.1600.22 (X64)   Jul  9 2008 14:17:44   Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.0 <X64> (Build 6001: Service Pack 1)

SSIS service was up and running and had no errors. Using SQL Server Management Studio connecting to Integration Services on that server was not an issue. Yet once navigating to “Stored Packages -> MSDB” there was an error:

Error: Cannot connect to WMI provider

Recently on a new installation of our production Microsoft SQL Server in a cluster environment I started to receive the following error message:

Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager.

The paging file is too small for this operation to complete [0x800705af]

Somewhere posted solution with recreating .mof file was not applicable as there were no .mof files whatsoever.

Twitter Delicious Facebook Digg Stumbleupon Favorites More
Designed by: Free Cell Phones | Thanks to Highest CD Rates, Domain Registration and Registry Software