[
https://issues.apache.org/jira/browse/DERBY-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811412#comment-13811412
]
Kim Haase commented on DERBY-6399:
----------------------------------
This seems like a very helpful improvement. I'm working on providing clearer
steps in the roll-forward recovery topic and clarifying the difference between
regular backups and log-archive-mode ones.
I notice that the topic "Using the logDevice=logDirectoryPath attribute"
(http://db.apache.org/derby/docs/10.10/adminguide/tadminlog800206.html) says
that "This attribute is meaningful only when you are creating a database."
However, it appears that if you moved the database, you also need to specify it
when you recover the database. Perhaps we need to correct the topic. The
Reference Manual topic on the logDevice attribute does mention that it can be
used with the rollForwardRecoveryFrom attribute.
> clarify backup section in Derby Server and Administration Guide regarding
> connecting to the backed up db
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6399
> URL: https://issues.apache.org/jira/browse/DERBY-6399
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Reporter: Myrna van Lunteren
> Assignee: Kim Haase
> Priority: Minor
>
> The Derby Server and Administration Guide could clarify better that a backup
> created using the SYSCS_UTIL.SYSCS_BACKUP_DATABASE is effectively a copy
> (with the caveats regarding non-logged data).
> But when using the
> SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE the resulting
> backed up directory is *not* a full copy of the database, and connecting to
> it directly could be missing data, and possibly invalidate the backup.
> Also, it might be helpful to add an example to the rollforwardrecovery page
> that is more of a scenario, whereby first the old, perhaps corrupted
> database, gets renamed, and then a new one is created in its place, but based
> on the backup and using the logDevice text, maybe something like:
> Should a problem have developed with a database, the best approach is to
> shutdown the original database, rename the original database directory, use
> the rollForwardRecovery with the logDevice attribute, for instance in a linux
> shell, if the database wombat was previously backed up to directory /backups:
> mv /databases/wombat /databases/brokenwombat
> cd /databases
> then do the following in ij:
> connect
> 'jdbc:derby:wombat;rollForwardRecoveryFrom=/backups/wombat;logDevice=/databases/brokenwombat';
--
This message was sent by Atlassian JIRA
(v6.1#6144)
