We have been running SQLA in a highly available cluster for years. We 'rebuild' the database at least twice a year. We do this using a batch file and command lines taken from the help file.

dbunload -c "server=dbpartner_node;host=xxx.xxx.xxx.xxx:55502;DBN=Exodus;uid=xxx;pwd=xxxx" -dt D:\RebuildTest -ao "D:\RebuildTest\Database.db"

We recently went from v17.0.11.7312 to v17.0.11.7458.

When attempting the rebuild, the first part of the rebuild, the backup, is behaving in a way that it seems it will never finish. It used to take less than two hours (typically around 1 hour).

The echo to the console keeps repeating, "waiting for transactions to complete.", between counting up the number of pages backed up.

Could the software version be the issue? Some bug? Any thoughts would be appreciated.

asked 21 Feb, 11:28

ricwash's gravatar image

accept rate: 0%

See the info from the docs on dbunload -ao:

If the conditions below cannot be met, then consider rebuilding the database using dbunload -aob:

There must be regular times when there are no outstanding transactions on the production server as dbbackup -wa must be used to take the initial backup to ensure that no transactions are lost.
Multiple backups to the production server and transaction log renames on the production server must be acceptable.

I would assume there are still active transactions, so dbunload has to wait for them to finish. If that won't happen (and you cannot start dbunload at a "quiet time"), have a look at -aob.

(21 Feb, 11:59) Volker Barth

Again, we are doing this the way we always have for years. The DB is in the same state it has been in the past for doing a rebuild. We are able to do backup normally, and it takes at most 2 hours. I can even run the dbbackup remotely and it only takes an hour and a half. So for the rebuild backup step to run 6, 8 10 hours seems that there is something wrong.

(21 Feb, 12:20) ricwash
Replies hidden

Does a dbbackup -wa also finish within that time frame?

(21 Feb, 12:29) Volker Barth

I will test to confirm that tomorrow.

(21 Feb, 14:28) ricwash

The test shows that a backup using -wa took 1.5 hours, just like the nightly regular backups. So, back to square one, why is the backup part of the dbunload taking multiple hours longer?

(22 Feb, 09:08) ricwash

The command line used: dbbackup -c "server=partner2_node;host=xxx.xxx.xxx.xxx:55502;DBN=Exodus;uid=xxx;pwd=xxx" -wa "d:\NewBackupTest" -o "d:\backuptest_log.txt"

(22 Feb, 09:10) ricwash

Backing the software version from v7458 back to v7312 solved the backup issue for us. Now, we have to test to see if the latest EBF, v7672, has the same issue as v7458 or not.

(04 Mar, 07:25) ricwash

I tested v7672 on an isolated environment with a copy of the production database, and everything worked. Well, after updating production to v7672, the backup part of the rebuild does the same thing, has the 'waiting for transaction...' thing, and does not move after hours of doing that. This is very frustrating.

(02 Apr, 14:32) ricwash
More comments hidden
showing 5 of 8 show all flat view
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 21 Feb, 11:28

question was seen: 174 times

last updated: 02 Apr, 14:35