Issue Details (XML | Word | Printable)

Key: CORE-2539
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Roman Simakov
Reporter: Van den Wouwer Danny
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

delta file (backup mode)

Created: 05/Jul/09 10:23 AM   Updated: 23/Feb/10 07:01 AM
Component/s: None
Affects Version/s: 2.1.0, 2.5 Alpha 1, 2.1.1, 2.1.2, 2.5 Beta 1, 2.1.3
Fix Version/s: 2.5 Beta 2, 2.1.4

Time Tracking:
Not Specified

Environment:
Windows XP SP3
Windows 2003 RC2

Planning Status: Unspecified


 Description  « Hide
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

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 05/Jul/09 11:35 AM
You run Classic, correct?

Van den Wouwer Danny added a comment - 05/Jul/09 12:45 PM
Yes, I m using classic on windows

Dmitry Yemanov added a comment - 05/Jul/09 01:28 PM
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.

Van den Wouwer Danny added a comment - 05/Jul/09 03:10 PM
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

Dmitry Yemanov added a comment - 24/Oct/09 04:18 PM
This is expected to be fixed in v2.5, accordingly to Roman Simakov.

Roman Simakov added a comment - 19/Feb/10 01:07 PM
I ported the fix from 2.5 to 2.1 branch. Please, try snapshot.