Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 5 Nov 2013 02:00:18 +0000 (UTC)
From: "Myrna van Lunteren (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12676921.1383243585638.20279.1383616818590@arcas>
In-Reply-To: <JIRA.12676921.1383243585638@arcas>
References: <JIRA.12676921.1383243585638@arcas>
Subject: [jira] [Commented] (DERBY-6399) clarify backup section in Derby
 Server and Administration Guide regarding connecting to the backed up db
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813552#comment-13813552 ] 

Myrna van Lunteren commented on DERBY-6399:
-------------------------------------------

Thanks for picking this up Kim.

The changes look good overall.
I have the following comments:
- re cadminhubbkup01.html
  I am wondering if we can move the new text to behind the section starting with 'The SYSCS_UTIL.SYSCS_BACKUP_DATABASE procedure puts the database into a state in which it can be safely copied [...] at any time..' 
  This section already implies that the resulting backup is a full copy. So perhaps we can leave it as is, and only add the section about the enable_archive_mode calls creating a backup that is *not* a copy.

- re cadminrollforward.html:
  The text above the example says the backup goes to d:/backup, but it's now a linux/unix example, so that should say /backup.

I also noticed that in tadminlog800206.html we actually tell people to modify service.properties to change the logDevice setting. service.properties is one of the files that has a 'do not touch' header...But there's no other way to change the logDevice setting, you can only set that at database creation time. So I guess we can leave this as is...


> 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
>    Affects Versions: 10.10.1.1
>            Reporter: Myrna van Lunteren
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-6399.diff, DERBY-6399.stat, DERBY-6399.zip
>
>
> 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)