Hello Leo,
Here is a brief update on the problems, that you encountered:
A) "-126,Databackup missing (Backuphistory lost)"
In dbm.prt one finds, that this resulted from:
2006-08-25 13:54:22 0x000005f7 0 DBM command
db_activate
2006-08-25 14:12:28 0x000005f7 0 DBM command
recover_start incrHourly
2006-08-25 14:12:31 0x000005f7 0 DBM command db_online
2006-08-25 14:12:32 0x000005f7 0 DBM command
autolog_on
2006-08-25 14:12:32 0x000005f7 ERR -24988 DBM ERR_SQL: sql
error
0x000005f7 ERR -24988 DBM -126,Databackup
missing (Backuphistory lost)
After recovering the database and restarting it, the history of log
backups is lost and although new log backups could be based on the data
backup that was used for the recovery MaxDB could not differentiate
currently between the old series of log backups and the new one.
Therefore to be sure a new complete backup is requested by MaxDB. Future
MaxDB versions will be more flexible in this regard. A "backup_start ...
DATA ..." would have allowed you to switch on the automatic log backup.
B) "Logrecovery is not allowed, because state of log volume is
'HistoryLost' (log must be cleared)"
One finds, that the following events lead to this message:
2006-08-25 13:54:22 0x000005f7 0 DBM command
db_activate
2006-08-25 14:12:28 0x000005f7 0 DBM command
recover_start incrHourly
2006-08-25 14:12:31 0x000005f7 0 DBM command db_online
...
2006-08-25 14:16:12 0x000006cf 0 DBM command db_admin
2006-08-25 14:16:29 0x000006cf 0 DBM command
recover_start ARCH LOG 6142
After recovering you changed the database into mode ONLINE and thereby
started a new log history. Even some new log entries were written during
that db_online. Therefore the recovery of log information must fail,
because it does not match the new database, especially not the log
entries written during and after db_online. Either restart with a
"db_activate recover ..." or go on by doing a "backup_start ...".
C) Database "crashes" during db_activate (aka. -104,DBM command
impossible at this time)
In knldiag one finds, that the database shuted down during a recovery
attempt:
2006-08-25 14:57:56 15 ERR 8 Admin ERROR 'backup_not_running'
CAUSED EMERGENCY SHUTDOWN
One finds in dbm.prt that at that time a check data was running:
2006-08-25 14:30:02 0x0000078d 0 DBM command db_admin
-f
2006-08-25 14:30:14 0x0000078d 0 DBM command
db_execute CHECK DATA
...
2006-08-25 14:57:50 0x00000811 0 DBM command
db_activate
2006-08-25 14:57:51 0x00000811 ERR -24988 DBM ERR_SQL: sql
error
0x00000811 ERR -24988 DBM -104,DBM command
impossible at this time
This problem is still under investigation, usually the database should
not shut down under this circumstances.
Best regards,
Tilo Heinrich
SAP Labs Berlin
-----Original Message-----
From: Leo Eraly
Sent: Montag, 4. September 2006 10:04
To: Heinrich, Tilo
Cc: [email protected]
Subject: Re: Maxdb 7.5 backup
Hi,
Did someone managed to found some things out of the posted files?
Kind regards,
On Tue, Aug 29, 2006 at 11:01:01AM +0200, Leo Eraly wrote:
> Hi,
> On Tue, Aug 29, 2006 at 10:43:34AM +0200, Heinrich, Tilo wrote:
> > Hello Leo,
> >
> > Sorry for the delay. Please provide us with files dbm.prt and
dbm.utl
> > too.
> >
> The files are also added on http://support.kangaroot.net/maxdb
>
> >
> > You asked me last week on the maxdb mailinglist to supply you extra
> > information for investigating a crash.
> > You can find all relevant information on
> > http://support.kangaroot.net/maxdb/
> >
>
> Kind regards,
>
>
> --
--
------------------------------------------------------------------------
Leo Eraly Kangaroot Linux Solutions
System Adminstrator / Developer Grote Steenweg 91
[EMAIL PROTECTED] 2600 Berchem
Tel: +32 3 286 17 10 Belgium
Fax: +32 3 281 23 49
PGP/GnuPG key: 1024D/F05EED4E
Key available at wwwkeys.pgp.net
------------------------- http://www.kangaroot.net ---------------------
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
