o I think it would seem reasonable to leave decision of whether to wait for unlogged operations to finish up to the caller of the backup. For some set of users waiting is fine, they just want the backup eventually, and they are using the feature because they want normal users to be impacted as little as possible (at least with respect to lock concurrency). Others may need to know imediately why something is blocking their operation.
o I had just assumed that online backup would only work in roll foward mode, so there was really no garbage collection anyway - at least not until we provide a way to move rollforward logs somewhere automatically. I think this is sort of along the lines of what Oystein is saying, would be good to do in future but 1st impl does not need to address. Remember while Derby does not have built in size limits, it does not have features one expects from VLDB (for really large db's you probably want to have multiple threads/devices backup up in parallel along with simultaneous log file moves). Øystein Grøvlen wrote: >>>>>>"ØG" == Øystein Grøvlen <[EMAIL PROTECTED]> writes: > > >>>>>>"ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes: > > ST> My initial thought is to simply disable garbage-collection of log > ST> files for the duration of the backup. unless there are some specific > ST> advantages in writing backup-start log record. > > ØG> Disabling garabage-collection directly is probably the cleanest way to > ØG> do this. > > On second thoughts, for large databases, the time to copy the data > files may be so long that the log volume becomes prohibitively large > if garbage collection is turned off for the entire backup. In that > case, it would be better to copy finished log files in parallel with > the data files and let them be garbage collected at any time after it > has been copied. This probably does not need to be part of a first > implementation, but something one should consider for the future. >
