delta file (backup mode) [CORE2539]

[firebird-automations]

Submitted by: Van den Wouwer Danny (dannyvdw)

Situation 1
1. alter database begin backup
.. NOP on database
2. alter database end backup

a) No transactions are started / active before point 1 and between point 1 and point 2
--> cleanup of .delta file. OK

Situation 2
1. alter database begin backup
2. alter database end backup

a) Do some select/DML work on DB between point 1 and 2
b) Do some select/DML work on DB, started before point 1 and stopping before point 2
c) Do some select/DML work on DB, started before point 1 and stopping after point 2

PS
The select-statments are using a read-only read-commtted transaction
The DML are using the default isolation level, nl. concurrency write

Whatever I did, a), b) or c) I got :

--> cleanup of .delta file. Not done !
--> but backup state is gone from 1=stalled ->2=merge ->0=normal, so i guess all ok

After full validation it seems that the DB is ok, but the existence of the delta file worries me, why it isn't cleaned up in these situations ?
Our customer tested this on their test-environments, and he asked to me what is wrong with that delta file, he got the same results as I ?

So, if the .delta file still exists after alter database end backup, does this mean that merge wasn't completely successful?

BTW,
We get the same situation if we are using nBackup utility.

Before I give a green light for the production system to use the nBackup utility I want some clear answers in this case.
1) If .delta file still exists after end backup
--> Does this means, it's ok, next begin backup will create a new .delta
--> it's not ok, something went wrong, ? is Db still consistent then
etc..

Danny

Commits: 9508720

[firebird-automations]

Commented by: @dyemanov

You run Classic, correct?

[firebird-automations]

Commented by: Van den Wouwer Danny (dannyvdw)

Yes, I m using classic on windows

[firebird-automations]

Commented by: @dyemanov

It's a known issue. In your cases, the backup process is finished successfully, but the delta file is not deleted. In Classic, the delta is removed as soon as merge had finished and all the worker processes had acknowledged this fact. The latter happens when they access any page in the buffer cache. But if any user connection was idle after the backup has ended, then the appropriate worker process will keep the delta file open. It's not fatal per se, but the next backup attempt will fail due to the already existing delta file.

This issue is expected to be fixed in v2.5. You might want to validate it there.

[firebird-automations]

Commented by: Van den Wouwer Danny (dannyvdw)

This is strange:
Your comment "But if any user connection was idle after the backup has ended, then the appropriate worker process will keep the delta file open. It's not fatal per se, but the next backup attempt will fail due to the already existing delta file."

I tried this and it seems it delete the existing delta file and put the database in stalled mode

[firebird-automations]

Commented by: @dyemanov

This is expected to be fixed in v2.5, accordingly to Roman Simakov.

[firebird-automations]

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 2 [ 10300 ]

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

[firebird-automations]

Modified by: @romansimakov

assignee: Roman Simakov [ roman-simakov ]

[firebird-automations]

Modified by: @romansimakov

Fix Version: 2.1.4 [ 10361 ]

[firebird-automations]

Commented by: @romansimakov

I ported the fix from 2.5 to 2.1 branch. Please, try snapshot.

[firebird-automations]

Modified by: @dyemanov

Version: 2.1.3 [ 10302 ]

Version: 2.5 Beta 1 [ 10251 ]

Version: 2.5 Alpha 1 [ 10224 ]

[firebird-automations]

Modified by: @dyemanov

Version: 2.1.0 [ 10041 ]

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test