All lines in /oracle/S1P/saparch/archS1P.log till line X will be ignored (no resetlogs)

[Former Member]

Hi

We are constantly getting the "All lines in /oracle/S1P/saparch/archS1P.log till line X will be ignored" error message when trying to restore redo logs to our standby system. We have NOT done a resetlogs (which is what most searches on this error reveal).

An example command and errors follow:

brrestore -a 826599,826600,826601,826604,826605,826606,826607,826608,826674,826686,826687,826718,826733,826734,826735,826751,826768,826769,826770 -d

util_file -r initS1P-arch_1.utl

BR0461W Redolog sequence number in line 2444 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 2444 will be ignored

BR0461W Redolog sequence number in line 7132 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 7132 will be ignored

BR0461W Redolog sequence number in line 25200 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 25200 will be ignored

BR0461W Redolog sequence number in line 27458 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 27458 will be ignored

BR0461W Redolog sequence number in line 30763 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 30763 will be ignored

BR0461W Redolog sequence number in line 31127 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 31127 will be ignored

BR0461W Redolog sequence number in line 33676 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 33676 will be ignored

BR0461W Redolog sequence number in line 37224 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 37224 will be ignored

BR0461W Redolog sequence number in line 37674 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 37674 will be ignored

BR0461W Redolog sequence number in line 42410 of /oracle/S1P/saparch/archS1P.log not ascending

BR0462W All lines in /oracle/S1P/saparch/archS1P.log till line 42410 will be ignored

BR0459W Backup aeiuqspt.sve terminated with errors

BR0459W Backup aeiursvj.sve terminated with errors

BR0459W Backup aeiusged.sve terminated with errors

BR0459W Backup aeiusllt.sve terminated with errors

BR0459W Backup aeiusnfr.sve terminated with errors

BR0438W Redolog sequence number 826768 not found in /oracle/S1P/saparch/archS1P.log

BR0438W Redolog sequence number 826769 not found in /oracle/S1P/saparch/archS1P.log

BR0438W Redolog sequence number 826770 not found in /oracle/S1P/saparch/archS1P.log

BR0414I Offline redolog files for restore of database instance S1P:

826599,826600,826601,826604,826605,826606,826607,826608,826674,826686,

826687,826718,826733,826734,826735,826751

We have previously hacked out lines up until the largest line number (42410) of the copy of archS1P.log on the standby for restoring purposes, to avoid this error, but if the redo log we require was backed up in a backup before that line then we can't restore it!

I've had a look at line 42410 (line starting "#ARCHIVE.. 825730") and the lines surrounding it are as follows:

#ARCHIVE.. 825738  /oracle/S1P/saparch/S1Parch1_825738_654987192.dbf  2012-06-18 02.35.01  1473901056     6855036719915  1

#SAVED.... aeiuhjwm sve  *1339983350       2012-06-18 03.41.25 ........... ............

#COPIED... aeiuhmcu cpd  *1339984859       2012-06-18 04.03.50 ........... ............

#DELETED.. aeiuhmcu cpd  2012-06-18 04.03.50

#

#ARCHIVE.. 825739  /oracle/S1P/saparch/S1Parch1_825739_654987192.dbf  2012-06-18 02.37.12  1487450112     6855036909002  1

#SAVED.... aeiuhjwm sve  *1339983347       2012-06-18 03.41.28 ........... ............

#COPIED... aeiuhmcu cpd  *1339984877       2012-06-18 04.05.42 ........... ............

#DELETED.. aeiuhmcu cpd  2012-06-18 04.05.42

#

#* S1P  util_file  aeiuhjwm sve  2012-06-18 03.35.32  2012-06-18 03.42.18  5  ...........    825730   825752        0        0  ------- 7.10

(42)  @0654987192

#

#ARCHIVE.. 825730  /oracle/S1P/saparch/S1Parch1_825730_654987192.dbf  2012-06-18 02.21.25  1476884480     6855035070474  1

#SAVED.... aeiuhkii sve  *1339983684       2012-06-18 03.43.50 ........... ............

#COPIED... ........ ...  ................. .......... ........ ........... ............

+DELETED.. ........ ...  .......... ........

#

#ARCHIVE.. 825731  /oracle/S1P/saparch/S1Parch1_825731_654987192.dbf  2012-06-18 02.25.09  1482507776     6855035269655  1

#SAVED.... aeiuhkii sve  *1339983679       2012-06-18 03.44.59 ........... ............

#COPIED... ........ ...  ................. .......... ........ ........... ............

+DELETED.. ........ ...  .......... ........

#

Indeed, 825730 isn't in ascending order after 825739...

I've looked at the backups referenced:

cgiu285a:oras1p 2> ls -ltr *aeiuhjwm*

-rw-r--r--    1 oras1p   dba            5424 Jun 18 03:42 aeiuhjwm.sve

cgiu285a:oras1p 3> ls -ltr *aeiuhmcu*

-rw-r--r--    1 oras1p   dba            8252 Jun 18 04:07 aeiuhmcu.cpd

cgiu285a:oras1p 4> ls -ltr *aeiuhkii*

-rw-r--r--    1 oras1p   dba            6717 Jun 18 03:45 aeiuhkii.sve

So aeiuhkii.sve which backs up the offending 825730 actually runs after the one which backs up 825739... it's doing the first sve backup of log 730 3 minutes after it does the backup of log 739, why is that?!?!

Checked the start times of these backups - aeiuhjwm.sve (log 739) starts & ends:

03.35.32

03.42.18

Whereas aeiuhkii.sve (log 730) starts and ends after BUT it actually starts WHILST the other backup is running...?!?!

03.40.40

03.45.34

Is that the issue - that we have overlapping backups?

Thanks

Ross

[Former Member · Accepted solution]

Start the brrestore with "-b" option with the particular log file. Check the link, below;

http://help.sap.com/saphelp_45b/helpdata/en/a0/897415dc4ad111950d0060b03c6b76/content.htm

Best regards,

Orkun Gedik

[Former Member · Accepted solution]

Thanks for the replies... I've gone through the rest of the log and can see that it does appear to be the two brarchives running simultaneously that is the issue. I've noticed that they are slightly different:

brarchive -s -c -u / -n 23 -d util_file -r initS1P-arch_1.utl

brarchive -s -c -u / -d util_file -r initS1P-arch_1.utl

Recalled that a colleague set up a script to use the -n parameter on a dynamic basis (to avoid long running redo log backups and the risk of saparch filling up) so this is obviously that script kicking in - looks like we have a scheduling issue! Will get this changed so only one runs at a time

Note that with the -b option you can't also use the -a option, i.e. don't seem to be able to restore a specific log...

Cheers

Ross

[Former Member]

Hi Ross,

It is weird to execute parallel brarchive commands at the same time. This is because the system locks the br operations while one is running. In your case overlappling two backups does not make a sense, unless the ".lock.bra" file has been deleted manually, during the backup.

Secondly, offline redolog files must be in the sequence in the "arch<SID>.log". There must be a problem during the backup. Plus, you shouldn't hack the log files, manually.

Best regards,

Orkun Gedik