Home

Hanging issues

Prev Page Next Page
Introduction
Recovery models
Main backup types
Backing up the database files by copying
The transaction log
Transaction log restore sequence
Log sequence numbers
Truncating and shrinking the transaction log
Backing up the tail
Inside the transaction log
So, what's in a backup file?
Test: A full backup does not contain deleted data
Verifying backup files
Verifying backup files on a budget
Cumulative backups
Recovering individual tables
Backup and restore history details
Backup reads and writes
Speeding up backups
Backup speed details
Speeding up restores
Restore state affects speed too
Backup and restore rights
Log shipping
Log shipping in SQL Server 2000
Setting up log shipping using Enterprise Manager
Checking the set up
Failover
Log shipping in SQL Server 2005
Setting up log shipping using Management Studio
Checking the set up
Log shipping status report
Failover
Log shipping in SQL Backup
Using the CopyTool utility
Failover
3rd party backup applications
VDI
VDI versions
VDI errors
SQL Backup - beyond compression
Restoring a chain of transaction log backups
Restoring to the latest possible state
Backing up multiple databases
Backup retention
Making a copy of the backup file
Backup file naming conventions
Restoring the latest backup set
Network resilience
Encryption
Integrated database verification
Database file relocation
Improved backup retention
RESTORE HELP
High-availability group support
Common SQL Backup issues
Installation checklist
Setting up rights
Configuring service rights
Backup data
Hanging issues
Common backup and restore errors
Error 3201 - when performing a backup to a network share
Full database backup file is larger than database size
Error 3205 - Too many backup devices specified for backup or restore
Error 4305 - an earlier transaction log backup is required
Bringing a database that is in recovery or read-only mode online
Using bulk-logged recovery model but transaction log backup is still large
Error 14274 - unable to delete SQL Server Agent job
Error messages when restoring from different versions of SQL Server.
Pending
vdi error codes
Restore speed details
Help, my transaction log file is huge!
Mirror or log ship



In cases where you find that running SQL Backup via the extended stored procedure seems to have hanged, there are a couple of things you can do to help Red Gate Support in identifying and addressing your issues faster.

In most cases, the SQL Backup process has either encountered a critical error, or is taking an extremely long time performing a specific task.

Critical errors

When SQL Backup encounters a critical error, it generates a stack trace to a log file named SQBCoreService_<instance name>_bugreport.txt.  So for a local instance, the file is named SQBCoreService_(LOCAL)_bugreport.txt, and for a instance named SQL2008, the file is named SQBCoreService_SQL2008_bugreport.txt.

In SQL Backup versions 5 and earlier, this file is generated in the folder where the SQL Backup Agent service (SQBCoreService.exe) is installed.  In version 6 and newer, the file is generated in the '<system drive>\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log' folder.  On Windows Vista and newer operating systems, the file can be found in the '<system drive>:\ProgramData\Red Gate\SQL Backup\Log' folder.

If you do not find such a file in that folder, there may be 2 possibilities:

·SQL Backup has never encountered any critical errors since it was installed

·The SQL Backup Agent service startup account has no rights to create that file in that folder.  To verify this, run the following and check if the file was generated:

 

EXEC master..sqbutility 9997

 

If the file was not generated, you would need to grant the necessary rights to the SQL Backup Agent service startup account to create files in that folder.

 

Abnormal execution time

If SQL Backup seems to be taking too long to perform a task, and you do not find the log files described above, you can run the following code:

EXEC master..sqbutility 9997

to generate a stack trace of the SQL Backup process.  The stack trace is saved to the log file described above, and is invaluable to the support team in identifying what exactly is happenning in SQL Backup.  However, when generating the stack trace, please ensure that there are as little unnecessary tasks running within SQL Backup as possible.  Also note that the extended stored procedure will just return a NULL value.

E.g. if you backup hangs, first ensure that no SQL Backup GUI is connected to the server.  Then check that no other SQL Backup backups or restores are running.  Only then should you generate the stack trace.  This is to minimise the 'noise' in the trace file.

When you then contact Red Gate Support with your issue, you should provide the following:

·a description of the issue you are facing

·the log file containing the stack trace

·the SQL Backup command that was ran at the time SQL Backup became responsive

Thank you.




Document history
11/4/2010    Added folder details on Vista and newer OSs'.    
10/21/2009    Initial release.    
 
Copyright 2008 - 2017 Yohz Ventures Sdn Bhd. All rights reserved.
All product and company names are trademarks or registered trademarks of their respective owners.