SQLA v17 HA live rebuild

[RiclWash]

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.

[VolkerBarth]

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.

[RiclWash]

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.

[VolkerBarth]

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

[RiclWash]

I will test to confirm that tomorrow.

[RiclWash]

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?

[RiclWash]

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"

[RiclWash]

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.

[RiclWash]

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.