db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: some questions regarding backups...
Date Wed, 30 Oct 2013 21:26:39 GMT
On 10/28/2013 10:26 AM, Myrna van Lunteren wrote:
> Hi,
>
> I have some questions regarding backups, and I hope the community can
> help answer these...
>
> 1. Can a backup of a database be used as a database?
> The directory structure of a backed up database looks very similar to a
> normal database.
It is important when asking this question to specify what kind of backup
you are talking about.  Derby support 2 different kinds of backup, and 
the answer is different depending on what kind.

The first type creates a complete backup of the db at a specific point
in time.   It is created with:
SYSCS_UTIL.SYSCS_BACKUP_DATABASE()

In this case the db probably can be accessed directly, because all bits
including tranasaction log files and database files are copied and
independent from the original database.

The second type of backup is one that takes advantage of the 
roll-forward recovery feature and is taken using:
SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE()

In this case the backup of the database depends not only on the files 
located in the backup area, but also on all of the log files created
in the original database since the backup was taken.  The only supported
way to access this kind of backup is to use the restore from backup
as documented in the admin guide.   I think derby will allow you to
directly access this backup as if it is a complete db, but in so doing
you may corrupt the backup such that it can not be used to restore from.

> 1.b. What's the difference, if any?
> I think though that actually using a backed up database as if it is a
> database destroys it as a back-up, that is, once you start using it,
> even just for selects, the most recent transaction log will conflict
> with the ones in the original database.

With respect to point in time db, I think no harm is done, other than
you may be changing it.

With respect to the roll forward recovery backup, accessing the db
could make changes to the seg0 files which will then conflict when a
restore is attempted that runs the roll forward recovery algorthim
using the log file files from original db on the seg0 files in the backup.
> 1.c. Is this interpretation correct?
> 1.d. What would the expected behavior be if someone would use such a
> compromised backup to restore?
>
> 2. If no other activity has taken place, should the file sizes for the
> .dat files in the seg0 be the same in a backed up database as the
> database from which it was taken?
I would have thought that no size differences should be noted as backup
looks like it does a simple read a page/write a page algorithm.  But it
does look at data structures to know when to stop the end of the file 
rather than just seeing how big the file looks to the OS.  I believe
when allocating, for performance reasons, that there is some "fuzziness"
in the absolute pages at the end of file and that in some situations the
software "knows" that if it asks to read a newly allocated page at the
end of the file and gets and EOF it can recover by just growing the file
and creating a new empty file page on the fly.  I am guessing that given
what concurrent activity is going on during the online backup this might
explain seeing absolute file size differences in cNNN.dat files between
backup and original db.

To understand this more it would be easiest if there was a repro from
scratch showing the behavior.
>
> Thanks,
> Myrna


Mime
View raw message