Mike Matrigali wrote:
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.
That is a good point, but to provide both the options; new backup
procedures that takes an extra parameter for the users to specify
wait/fail are required.
I am thinking of providing following two additional backup procedures
for this case:
1) Full backup
SYSCS_UTIL.SYSCS_BACKUP_DATABASE(IN BACKUPDIR VARCHAR(),
IN WAIT_FOR_NONLOGGED_OPERATIONS SMALLINT)
and
2) Full backup with log archive mode:
SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
(IN BACKUPDIR VARCHAR(32672), IN SMALLINT DELETE_ARCHIVED_LOG_FILES,
IN WAIT_FOR_NONLOGGED_OPERATIONS SMALLINT))
WAIT_FOR_NONLOGGED_OPERATIONS :
A non-zero input argument of type SMALLINT will make backup procedures
to wait for the non-logged operation that are currently running to
commit, while an argument of 0 will make backup fail if there are any
uncommitted non-logged operations.
Please note that the signature of the these procedures is same as
the current procedures , except for the additional argument.
Current procedures has to be maintained for backward compatibility
reasons. They will work in non-blocking mode(I doubt any user will
complain about it!). Existing backup procedures will wait for
non-logged operations commit.
Any comments ?
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).
Mike, I think it will be more helpful to the users if Derby supports
non-blocking simple full backups, not just non-blocking backups only
with log archive mode enabled.
I believe Øystein is referring to the non lograchive mode scenario, if
there are checkpoints when backup is in progress; log space can
released by copying the log files to the backup in parallel to the
data files copy operation. I also think, this enhancement is not
essential for first implementation of real time online backup.
Thanks
-suresht
Ø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.
