On Wed, Oct 30, 2013 at 2:26 PM, mike matrigali <[email protected]> wrote:
> 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 >> > > Thanks for your answer Mike. I'll add a low priority JIRA for making the documentation a bit more explicit about not accessing a backup created with the log-archive mode, but that the SYSCS_UTIL.SYSCS_BACKUP_DATABASE creates an effective copy. I saw the space difference with a customer's database, about which I know little and about which I cannot disclose more. I did try to make a repro for the space-difference behavior, but in my experiments so far got no difference between backed-up and original version. Myrna
