3.2 -> 4.0 Upgrade Problems

appwright · January 27, 2006 8:59PM

I upgraded from 3.2 to 4.0 and SQL Backup stopped working as seen in other posts. Got the "Could not load dll" error.

I run SQL 2K on an instance and noticed in this post:
http://www.red-gate.com/messageboard/vi ... php?t=1780

that SQL Backup does not install on instances!! What's up with that?!?!

Anyway, I followed those instructions in the post and it is now running from what I can tell.

I do have one other problem. The little info window in the GUI says that I am on a 14 day trial however I have a full license and support agreement and was told I would get this update for free. I have emailed support on this topic, hopefully they will take care of it.

[UPDATE] - It seems I needed to activate the product again as it lost my registration? Anyway - as soon as I activated, it immediately locked up the GUI and I had to kill it. HOWEVER, my key will not work on the Log Rescue so I'm still not complete yet.

Another issue - the GUI crashes on exit or locks up. I think this 4.0 release is bit half baked! :? This is a database server product guys - mission critical stuff. No room for issues like this!!!

Please, Red-Gate, make these installs cleaner!! Also, let me know if there are any tests I can run that can verify I have a fully clean install.

petey · January 27, 2006 11:50PM

When the GUI crashes, was there a dialog reporting the crash, and is there a debug text file in the GUI folder?

To verify your install:

- check that the SQL Backup Agent is installed and running
- check that xp_sqlbackup.dll version 4.0.0.113 is in your SQL Server's Binn folder
- check that when you run

sqlbackup

from within Query Analyzer, the column header states that the DLL version is 4.0.0.113.

appwright · January 28, 2006 12:12AM

Yes - I emailed the log to support.

appwright · January 28, 2006 1:51AM

More Problems :x

My backups are failing to run. Here is the error I get in the log:

1/28/2006 12:49:15 AM: VDI error 1000: Failed to create virtual device. Check that the SQL Server instance you are trying to connect to is running. Error code: (-2139684857: Failed to recognize the SQL Server instance name.)

Loosing patience quick!!

petey · January 28, 2006 7:19AM

When you run

sqlbackup ''

in Query Analyzer, what does the column header display? Thanks.

appwright · January 28, 2006 11:17AM

SQL Backup (DLL v4.0.0.113)
Login paramerters...etc...

Correct version.

If you can instant message me I can give you access to this server via GotoMYPC so you can look at it yourself.

appwright · January 29, 2006 5:50PM

Just an update to everyone. My server has the same name as the instance name of SQL Server. Ther server also has no default instance.

This seems to cause a problem in SQL Backup and it will not work according to support at this time. I am waiting for a software update to see if they can fix the problem.

Brian Donahue · January 30, 2006 1:00PM

We have a patch for this available now. If you can please send an email to support@red-gate.com, we can send an updated extended stored procedure and a service executable.

appwright · January 31, 2006 11:57PM

I have loaded the patch and it does fix the stored proc. The command line interface still fails however.

Also - when using the GUI it deadlocked on the MSDB table and failed to delete some backup history. I looked at the deadlocks and noticed that SQL Backup was deadlocked against itself. Seems this version is still pretty unstable - when are the fixes going into release?

One other note, when running the GUI it initially took a very long time for it to load. Most likely due to the fact that I had a very long history of backups. Don't forget I'm backing up over 300 databases every night!

petey · February 1, 2006 4:09AM

The patched files set you received did not contain the updated command line application, so it's not surprising that it's not working. The 4.1 release will include the fix.

The deadlock issue is interesting, because a single backup/restore operation does not issue SQL commands across multiple threads. It's more likely that there were 2 or more SQL Backup operations running concurrently, but even then all of them will run the SQL commands in the same order. Are your default connection transaction settings set to autocommit mode?

The long loading time is unlikely to be due to the backup history, as only the last 200 backups and restores operations are displayed. Could you pls run Profiler and confirm that this is indeed the cause? Thanks.

appwright · February 1, 2006 10:13AM

Here is what I think happened. The GUI crashed after I tried to close it (I've sent you guys bug reports on that). That left some jobs running on SQL Server. When I ran the second job it deadlocked with the old job.

Also - on loading the tree at the left. It takes about 5 minutes to load the tree remotely with 353 databases in the tree. I have other products that do the same in about 2 seconds. You might want to find a faster way to retreive the list of databases.

Brian Donahue · February 1, 2006 12:57PM

I think there is a possibility of getting an error message if you close the GUI while it's trying to read from a connection. This is something we're looking into.

petey · February 1, 2006 1:58PM

The tree displays a lot more than just the database name. It also displays the database file sizes and the last backups made, of each type.

The query bottleneck lies with the msdb..backupset table, as the system indexes are not well suited to SQL Backup's queries. As a test, try creating an index with the following definition

CREATE INDEX ix_sqb_01 ON backupset(database_name, type, backup_finish_date desc)

and see if the query execution time improves. The usual caveats about creating indexes on system tables apply.

appwright · February 1, 2006 8:11PM

It was faster but still takes a good while to load. Why not load the tree with database objects only and go retreive all that other data when you actually click on a database?

petey · February 1, 2006 10:01PM

Since this is a backup application, we are going to tell you which database backups are due, when the connection to the server is first made. It would be far more troublesome to click on each of the 350 databases to find out which backups are overdue.

If there are users who feel that this information is unimportant, we might consider delaying the retrieval of this information.

appwright · February 1, 2006 10:45PM

Yes I agree, however the listview displays very quickly with the data in the grid. The + on the tree takes forever to come up.

kennyguo · November 17, 2007 7:46PM

Oh It was faster but still takes a good while to load. Why not load the tree with database objects only and go retreive all that other data when you actually click on a database?

3.2 -> 4.0 Upgrade Problems

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk

3.2 -&gt; 4.0 Upgrade Problems

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk

3.2 -> 4.0 Upgrade Problems