exec dbo.sqbstatus 1 -- 0 Processed (Bytes) after hours

johnzabroski · September 28, 2010 11:44AM

SQL Server 2008, brand new install.
Trying to restore from SQL Server 2005 database backup w/ Redgate SQL Backup.

exec dbo.sqbstatus 1
-- shows that the database I am restoring has 0 Processed (Bytes) after hours spent in Restore mode

SQL Server Management Studio Activity Monitor reveals I have a process blocking SQL Backup from continuing: PREEMPTIVE_OS_GETPROCADDRESS.

Searching for that, I found this article: http://blogs.msdn.com/b/psssql/archive/ ... ation.aspx

According to that article, that process is a figment of SQL Server 2008's imagination (if I understand it).

I tried the DBCC TRACEON commands for logging restore-related stuff, and they print nothing. The issue seems to be that when TSQL processes the SQL Backup command, the associated DLL entry point gets hung while searching for the DLL and/or something along that line of thought.

This article: http://social.msdn.microsoft.com/Forums ... a2da662f4b says that I might either have a misconfigured database driver or have not registered a DLL.

What DLLs should I have registered?

Any other debugging tips? I basically have already browsed the whole Redgate SQL Backup FAQ searching for answers and/or clues (which is how I found out the DBCC TRACEON trick). Maybe I overlooked one?

petey · September 28, 2010 7:44PM

Could you please send me the SQL Backup Agent stack trace file described in this article?

Thanks.

johnzabroski · November 3, 2010 10:30AM

I am using SQL Backup6 with Windows Server 2008 R2 Standard and SQL Server 2008 Standard, and don't know where the equivalent folder mentioned in your link is (I cannot find "\All Users\Application Data\Red Gate\SQL Backup\Log").

I tried:

EXEC master..sqbutility 9997

and the result was:

result
------
NULL

...with no output messages.

I did this while the restore job was hung in its usual place.

Afterward I used the file system search to find the file, and it still did not show up. This leads me to believe that SQL Backup 6 doesn't have permission to write to the folder, and maybe is trying to write to a folder name that doesn't exist on Windows Server 2008 R2. Or SQL Backup 6 is smart enough to know the directory structure of all Windows OSes using some environment variables I don't know about, and then the issue would simply be fixing permissions.

Edit:

I found a post on the MSDN Forums explaining that Windows Server 2008 R2 hides the ability to unhide files, and that you need to press the 'ALT' key once while focused on the Windows Explorer window. This will cause a standard menu to appear below the backward-forward-enter-url widget.

This helped reveal that '\All Users\Application Data\' on Windows Server 2008 R2 is actually 'Users\Default\AppData'. I'll examine the permissions and update again.

petey · November 4, 2010 5:34AM

You're right, the document is outdated. I've updated it now.

As for the exact directory, on my Window Vista and Windows 2008 setups, the directory where the stack trace is found is C:\ProgramData\Red Gate\SQL Backup\Log', and not '\All Users\Application Data\'.

johnzabroski · November 4, 2010 11:37PM

The article can be improved further. It states:

When SQL Backup encounters a critical error, it generates a stack trace to a log file named SQBCoreService_bugreport.txt.

On my machine the file is titled SQBCoreService_(LOCAL)_bugreport.txt

It might also make sense to break out the differences across OS versions in a table, rather than a paragraph. It is easier to digest that way IMHO.

johnzabroski · November 15, 2010 10:43AM

This problem has been solved by uninstalling Redgate, downloading a new installer, and then reinstalling everything Redgate-related on the server where the restore job was failing.

exec dbo.sqbstatus 1 -- 0 Processed (Bytes) after hours

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk