-
-
Notifications
You must be signed in to change notification settings - Fork 233
delta file (backup mode) [CORE2539] #2949
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Commented by: @dyemanov You run Classic, correct? |
Commented by: Van den Wouwer Danny (dannyvdw) Yes, I m using classic on windows |
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. |
Commented by: Van den Wouwer Danny (dannyvdw) This is strange: I tried this and it seems it delete the existing delta file and put the database in stalled mode |
Commented by: @dyemanov This is expected to be fixed in v2.5, accordingly to Roman Simakov. |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5 Beta 2 [ 10300 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @romansimakovassignee: Roman Simakov [ roman-simakov ] |
Modified by: @romansimakovFix Version: 2.1.4 [ 10361 ] |
Commented by: @romansimakov I ported the fix from 2.5 to 2.1 branch. Please, try snapshot. |
Modified by: @dyemanovVersion: 2.1.3 [ 10302 ] Version: 2.5 Beta 1 [ 10251 ] Version: 2.5 Alpha 1 [ 10224 ] |
Modified by: @dyemanovVersion: 2.1.0 [ 10041 ] |
Modified by: @pavel-zotovQA Status: No test |
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
The text was updated successfully, but these errors were encountered: