Subject | AW: [firebird-support] nbackup / gbak interoperation |
---|---|
Author | Steffen Heil |
Post date | 2009-12-15T00:34:48Z |
No
Completely forget that.
The delta file works at block level. There is no semantic information that
is merged later, there are simply blocks that will overwrite blocks in the
real database.
If you modify the database in any way this "merge" will destroy the file.
The operating system should however prevent you to change it, because it is
still locked exclusively for write access.
And back to the comments you already got: Simply don't try to reclaim that
"unused" space in a working environment. The server will reuse it later.
Afaik there are only two good reasons to get rid of that space: Either for
backups (but gbak handles this itself, nbackup does not) or if the database
is later only opened readonly, but if you switch the very basic type of
access to the database, you can do a backup/restore: You don't change such
aspects on the fly.
-----Ursprüngliche Nachricht-----
Von: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Im Auftrag von dkeith2
Gesendet: Montag, 14. Dezember 2009 21:35
An: firebird-support@yahoogroups.com
Betreff: [firebird-support] nbackup / gbak interoperation
Since nbackup locks a db and causes a delta file to be created and written
to for the duration of the file lock, would it be possible/feasible in an
OLTP environment to:
Lock a file using nbackup
Backup the file using gbak
Restore the file using gbak, overwriting the original file
Unlock the file using nbackup, causing the delta file to be merged
???
I'm thinking this would be a way to reclaim lost space in an OLTP system's
db file without kicking off the users during the backup and without losing
any data.
How much load can this delta file handle? How long does it take to merge
back x amount of data in a delta? When the transition from main file to
delta takes place, are there any hiccups/delays, or is it completely
transparent to the system performance?
Thanks for any responses.
David Keith
------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !
Also search the knowledgebases at http://www.ibphoenix.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yahoo! Groups Links
[Non-text portions of this message have been removed]
Completely forget that.
The delta file works at block level. There is no semantic information that
is merged later, there are simply blocks that will overwrite blocks in the
real database.
If you modify the database in any way this "merge" will destroy the file.
The operating system should however prevent you to change it, because it is
still locked exclusively for write access.
And back to the comments you already got: Simply don't try to reclaim that
"unused" space in a working environment. The server will reuse it later.
Afaik there are only two good reasons to get rid of that space: Either for
backups (but gbak handles this itself, nbackup does not) or if the database
is later only opened readonly, but if you switch the very basic type of
access to the database, you can do a backup/restore: You don't change such
aspects on the fly.
-----Ursprüngliche Nachricht-----
Von: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] Im Auftrag von dkeith2
Gesendet: Montag, 14. Dezember 2009 21:35
An: firebird-support@yahoogroups.com
Betreff: [firebird-support] nbackup / gbak interoperation
Since nbackup locks a db and causes a delta file to be created and written
to for the duration of the file lock, would it be possible/feasible in an
OLTP environment to:
Lock a file using nbackup
Backup the file using gbak
Restore the file using gbak, overwriting the original file
Unlock the file using nbackup, causing the delta file to be merged
???
I'm thinking this would be a way to reclaim lost space in an OLTP system's
db file without kicking off the users during the backup and without losing
any data.
How much load can this delta file handle? How long does it take to merge
back x amount of data in a delta? When the transition from main file to
delta takes place, are there any hiccups/delays, or is it completely
transparent to the system performance?
Thanks for any responses.
David Keith
------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !
Also search the knowledgebases at http://www.ibphoenix.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yahoo! Groups Links
[Non-text portions of this message have been removed]