Hi Andre, we distinguish between explicit and implicit migrations. The migration from version 7.3 to 7.4/7.5 is an explicit migration preluded by "util_execute migrate". This was necessary because we changed the physical behaviour of the database, for example : - complete new log layout; split of undo and redo logs - no systemdevspace; converter pages are scattered over the data area - new info pages are stored in front of each volume
These are changes we never could do implict by restart of the db server in 7.4, therefore we decide to build a special command to prepare the database for these things. If there is a small migration needed we do it implicit, so nobody can see it, for example in 7.3.0.23-7.3.0.26 there were some catalog migrations and there will be an implicit migration from 7.5 to 7.6 because we changed something in the configuration. If we need an explicit migration in the future we will implement a new migration command. In your example a) no migration is needed because you didn't change the database version. Backup/Restore will work, if the swap behaviour is the same! In your example b) no migration is needed, because we didn't change the physical layout. It's sufficient to stop the database, upgrade the software and restart the database. Since 7.4 the token MIGRATION in backup_start has no meaning, because it was used in the past to distinguish between data backups with savepoint or checkpoint. Since 7.4 we have only savepoints, which is very good, because of the performance. Caused by the changes in the log handling - undo entries are stored in the data area and redo entries are stored in the log area - each data backup is consistent concerning of uncommited transaction, i.e. if you have a 7.4 data backup you will be able to recover/restart the database without any logs! Open transactions will be rollbacked with the undo information stored IN the data backup! In 7.3 it is a problem if you have a data backup with savepoint (-> perhaps open transactions) and no log (-> no undo entries in the data area!) because you need the log to rollback the uncommitted transactions. In 7.3 "backup for migration" means something like: You will be able to recover and restart the new database without log! I hope this additional information is helpful! Regards, Torsten SAP Labs Berlin -----Original Message----- From: Andre Reitz [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 9. Juni 2004 17:54 To: Strahl, Torsten Cc: [EMAIL PROTECTED] Subject: Re: AW: Backup procedures. OK, but what would I have to do if "migrating" from 7.4: a) from 7.4 to 7.4 (to another server) b) from 7.4 to 7.5 is the following procedure correct for a) and b)? backup_media_put medname /tmp/bak.dmp FILE DATA 0 8 YES util_connect DBM,password backup_start medname MIGRATION DATA util_release Greetings, Andre' On Wed, 9 Jun 2004 16:23:06 +0200 "Strahl, Torsten" <[EMAIL PROTECTED]> wrote: > 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] -- __________________________________________________________________________ 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]
