Hello Jared, Thanks for sending me the file. One can see that the DBM Server has problem to access Backint for MaxDB's output and error output after Backint for MaxDB was killed by that same DBM Server: Can not open file 'E:\sapdb\BOO\db\backups\io\backint.output'. (System error 32; The process cannot access the file because it is being used by another process.) ... Copying output of Backint for SAP DB to this file. ---------- Begin of output of Backint for SAP DB (E:\sapdb\BOO\db\backups\io\backint.output)---------- Have encountered error -24919: Can not open file 'E:\sapdb\BOO\db\backups\io\backint.output'. (System error 32; The process cannot access the file because it is being used by another process.) ... Not removing Backint for SAP DB's temporary output file (E:\sapdb\BOO\db\backups\io\backint.output).
Copying error output of Backint for SAP DB to this file. ---------- Begin of error output of Backint for SAP DB (E:\sapdb\BOO\db\backups\logs\backint.err)---------- Have encountered error -24919: Can not open file 'E:\sapdb\BOO\db\backups\logs\backint.err'. (System error 32; The process cannot access the file because it is being used by another process.) ---------- End of error output of Backint for SAP DB (E:\sapdb\BOO\db\backups\logs\backint.err)---------- ... Not removing Backint for SAP DB's temporary error output file (E:\sapdb\BOO\db\backups\logs\backint.err). As those files can not be read in that moment by the DBM Server, it leaves them in the file system for further analysis by the user. Unfortunately the user has to be remove the before the next backup attempt manually. I guess we need to look into the inheritance of file handles between DBM Server, Backint for MaxDB and child processes of Backint for MaxDB once more, as it seems that a killed Backint for MaxDB can still keep a file inaccessible. Thank you for your help. Best regards, Tilo Heinrich SAP Labs Berlin ________________________________ From: Jared Still [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 7:55 PM To: Heinrich, Tilo Cc: [email protected] Subject: Re: MaxDB backups I've attached dbm.ebl Jared On 12/22/05, Heinrich, Tilo <[EMAIL PROTECTED]> wrote: Hallo Jared, >When the MaxDB backup fails, it does not cleanup its log files. Do you mind sending a dbm.ebl to the mailing list, so that I might be able to find out the reason for this? Thank you, Tilo Heinrich SAP Labs Berlin ________________________________ From: Jared Still [mailto: [EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 9:10 PM To: Heinrich, Tilo Cc: [email protected] Subject: Re: MaxDB backups Hi Tilo, Comments inline: After the backup got canceled, there should be more information within dbm.ebp, then just the "Waiting... is running"-blocks you presented. Could you please explain further on the usefulness of dbm.ebp and the number of backups attempts? NetBackup makes 3 attempts to run a job. If the 1st one fails, it tries again. If that one also fails, it will try a 3rd time. After the 3rd failure, NetBackup gives up and returns an error. When the MaxDB backup fails, it does not cleanup its log files. When the next attempt to run the job sees that those log files still exists, it throws an error. Since this second attempt to run has overwritten dbm.ebp, the log of the initial failed backup job is lost. Here is an example from dbm.epl: Error thrown by 2nd backup attempt: Have encountered error -24927: The file 'E:\sapdb\BOO\db\backups\io\backint.output' already exists. The real error appeared in the previous backup attempt as recorded in dbm.epl. The number of retries is probably configurable. I haven't checked yet, but it would be useful to set this to 1 for troubleshooting purposes. Within dbm.prt only the issued DBM Server commands are accumulated not any logs. Did you mean dbm.ebl? Yes, I did mean dbm.ebl. -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist
