Skip to content
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

delta file (backup mode) [CORE2539] #2949

Closed
firebird-issue-importer opened this issue Jul 5, 2009 · 13 comments
Closed

delta file (backup mode) [CORE2539] #2949

firebird-issue-importer opened this issue Jul 5, 2009 · 13 comments

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2009

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2009

Commented by: @dyemanov

You run Classic, correct?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2009

Commented by: Van den Wouwer Danny (dannyvdw)

Yes, I m using classic on windows

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2009

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2009

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 24, 2009

Commented by: @dyemanov

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 24, 2009

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 2 [ 10300 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2009

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 19, 2010

Modified by: @romansimakov

assignee: Roman Simakov [ roman-simakov ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 19, 2010

Modified by: @romansimakov

Fix Version: 2.1.4 [ 10361 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 19, 2010

Commented by: @romansimakov

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 23, 2010

Modified by: @dyemanov

Version: 2.1.3 [ 10302 ]

Version: 2.5 Beta 1 [ 10251 ]

Version: 2.5 Alpha 1 [ 10224 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 23, 2010

Modified by: @dyemanov

Version: 2.1.0 [ 10041 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 18, 2016

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment