Hi Andre,
yes you are right "util_execute migrate" is not supported since version 7.4,
because this is a special command to migrate the internal structure of 
the database from 7.3 to 7.4/7.5 and therefore it's needed in 7.3 only.

util_execute migrate has nothing in common with "backups for recovery" or
"backups for migration"! The term "backup for migration" in the backup wizard
of the dbmgui in 7.3(!) means that the database kernel executes a checkpoint to
"determine" the pages to be relevant for the data backup. Checkpoint means that 
no transaction is active and therefore the data backup could be restored without 
log backups.
If you select "backup for recovery" the kernel executes only a savepoint to
"determine" the relevant pages for the backup and therefore it could be possible 
that you need a log backup for a complete database recovery (rollback of not
committed transactions).

BTW:
If you want to migrate your database from 7.3 to 7.4/7.5 you have to execute
"util_execute migrate" before you start the database backup. If you start 
"backup for migration" without "util_execute migrate" you will not be able to 
restore this backup in 7.4/7.5! (see step 4 of the migration guide)

http://dev.mysql.com/doc/maxdb/en/88/c290d224d9e140a9c7048ffff0c233/content.htm 


Regards,
Torsten

SAP Labs Berlin

 

-----Urspr�ngliche Nachricht-----
Von: Andre Reitz [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 9. Juni 2004 12:54
An: Heinrich, Tilo
Cc: [EMAIL PROTECTED]
Betreff: Re: Backup procedures.


Hi all,

  dbmcli -> util_execute migrate

doesn't work since Version 7.4....

It will never bee needed, because: "...there is no difference between
   backups for recovery and backups for migration"

Am I right?

Greetings, Andre'


On Mon, 7 Jun 2004 18:57:29 +0200 
"Heinrich, Tilo" <[EMAIL PROTECTED]> wrote:

> Hello Michael,
> 
> >Currently we are backing up every hour.
> >Due to a type of failure we had recently where memory in our db server
> >failed and DELETED some database config files and some data 
> >files I do all
> >backups for MIGRATION.
> 
> If your database version is 7.4 or above, there is no difference between
> backups for recovery and backups for migration. Backups do not contain any
> configuration data except the database parameters
> 
> >Currently I am backing up complete once per night, and 
> >incremental every
> >hour, but not the log ( although autolog is on of course ).
> >
> >
> >I was backing up the log every hour too, however as I don't 
> >need the log to
> >get my data back from a migration backup, and it created so many files
> >I decided I would just leave it autolog backup.
> 
> If you backup log every hour you should get at maximum 24 log backups more, as if 
> using
> autolog backup.
> 
> >Would this be considered to be a perfectly good way to do my 
> >backups, or
> >would it be better if I also backed up the logs each night 
> >along with the
> >migration data backup?
> 
> That depends of course on your backup aims. Log backups are usually needed, if as 
> much data must be restored as possible after a failure of the drive containing the 
> log volume. They also are useful if a needed data backup turns out to be on defect 
> storage media and a previous data backup is still available.
> 
> Best Regards,
> Tilo Heinrich
> SAP Labs Berlin
> 
> >
> >regards
> >Michael Andrewes - Software Director
> >C O M M U N I C A T O R   Interactive Marketing
> > 
> >P +612 9719 1469  F +612 9719 1796  M +61 410 677 458 PAGER 
> >+612 9214 8752
> >W www.communicator.com.au
> >Copyright Communicator Interactive Marketing Pty Limited 2004
> > 
> >CONFIDENTIAL INFORMATION owned exclusively by Communicator Interactive
> >Marketing Pty Limited. The information in this email and any
> >attachments is
> >privileged and confidential, intended only for the use of the 
> >recipient or
> >the intended recipient. If you are not the intended recipient, 
> >any use of
> >the information is strictly prohibited. If you have received this
> >communication in error, please inform us immediately and 
> >delete the message
> >and any attachments 
> >
> >
> >-- 
> >MaxDB Discussion Mailing List
> >For list archives: http://lists.mysql.com/maxdb
> >To unsubscribe:    
> >http://lists.mysql.com/maxdb?>[EMAIL PROTECTED]
> >
> 
> -- 
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]
> 


-- 
__________________________________________________________________________

Als Technologieunternehmen konzipieren und entwickeln wir ma�geschneiderte Feedback- 
und
Monitoring-Systeme - wie beispielsweise L�sungen f�r Beschwerde- und Ideenmanagement.
Mit dem Inquery� Survey Server bieten wir eine der leistungsf�higsten Standardl�sungen 
f�r
Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an.
__________________________________________________________________________


Inworks GmbH
Andre Reitz, Leiter Entwicklung
H�rvelsinger Weg 39, 89081 Ulm, Germany
Tel +49 (0) 731 / 93807-21
Fax +49(0)731/93807-18
Internet: http://www.inworks.de



-- 
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to