Standby database

[ERP]

Good morning,

We have a 4.70 R/3 instance running under HPUX with a Oracle database that we want to create a standby database at a disaster recovery site. I would apprcaite any help on how to configure BRARCHIVE to push archives to the standby system and configure standby to accept archives.

Thank you.
ERP

[Portal]

You can change log_archive_dest_1 and add archive_log_dest_2 in your init[SID].ora file. this will create 2 copies of your offline redologs. Use paths so that the second copy is copied on your standby server.

[ERP]

Hello,

We are moving along with this project and I have a question about BRARCHIVE. We created a separate database on our Q/A box. Can BRARCHIVE be used to test archiving with a non-SAP database?

This is the command I issued, I modified the uid/password for this posting.
/usr/sap/QSZ/SYS/exe/run/brarchive -s -p initPOCTEST.arc -c -u <uid>/<password>
-f

I ask this because we are getting some errors. The success /error message are as follows.
BR0002I BRARCHIVE 7.00 (16)
BR0925I Public synonym SAP_SDBAH created successfully for table SAPR3.SDBAH
BR0925I Public synonym SAP_SDBAD created successfully for table SAPR3.SDBAD
BR0925I Public synonym SAP_MLICHECK created successfully for table SAPR3.MLICHECK
BR0925I Public synonym SAP_SAPLIKEY created successfully for table SAPR3.SAPLIKEY

BR0301W SQL error -4045 at location BraDbLogOpen-5, SQL statement:
'INSERT INTO SAP_SDBAH (BEG, FUNCT, SYSID, OBJ, RC, ENDE, ACTID, LINE) VALUES ('
20091229161537', 'sve', 'POCTEST', 'stage', '9999', ' ', 'aecfxjkj', ' ')'
ORA-04045: errors during recompilation/revalidation of PUBLIC.SAP_SDBAH
ORA-00980: synonym translation is no longer valid
BR0324W Insertion of database log header failed

BR0011I 30 offline redo log files found for processing, total size 504.163 MB

BR0278E Command output of 'LANG=C rcp -p /oracle/QSZ/102_64/dbs/initPOCTEST.ora
orapse@spg11:/oracle/PSE/oraarch/POCTEST':
remshd: Login incorrect.

ERP.

[Portal]

Try reading SAP note 320457 - Installing BR tools on a non-ABAP database.

It might do the trick.

[ERP]

Hi All,

I have configured brarchive to ship the redo logs to the standby database, this is a success. What I cannot get going is the applying of the redo logs on the standby database once the logs arrive.

On the standby database, the following is the brarchive command I have put together:
/usr/sap/DSZ/SYS/exe/run/brarchive -s -p initPOCTEST.arc -u / -c -f -m >/scripts
/brarchx.log_POC 2>&1

The result of the above command is:
BR0280I BRARCHIVE time stamp: 2010-03-23 15.10.11
BR0301W SQL error -1033 at location BrDbConnect-2, SQL statement:
'CONNECT /@POCTEST'
ORA-01033: ORACLE initialization or shutdown in progress
BR0310W Connect to database instance POCTEST/PRIMARY failed

My gut feeling as to why I am failing to connect to the database is because brarchive is issuing the @POCTEST in the connect command. When I go into sqplus /nolog and then connect as system/**** all is good. When I go into sqplus /nolog and then connect as system/****@POCTEST I get the exact message when using brarchive.

Any help in stopping brarchive from adding @POCTEST would be greatly appreciated.

Best regards,
ERP

[Ramma]

Originally Posted by ERP

BR0310W Connect to database instance POCTEST/PRIMARY failed...

...When I go into sqplus /nolog and then connect as system/****@POCTEST I get the exact message when using brarchive.

Really?
Does it really complain about PRIMARY ?

And by the way, what is POCTEST?
Primary or standby db? Or what else?

Afaik (I am not using brarchive to apply logs) brarchive on the standby system will always try to connect to the primary db, in order to store logs.
For this it will need an entry primary_db = <PRIM_NAME> in its brarchive profile, and an entry for <PRIM_NAME> in the tnsnames.ora file. And of course a network connection to the primary db. Did you configure these?

Regards,
Ramma.

[ERP]

POCTEST is the sid of our test db and standby db for working with this project. It is a non SAP database, but BRARCHIVE works with it after applying note 320457. After hoinz said that brarchive will always try to connect to the primary db we made this happen. We already had primary_db = POCTEST defined. We did not have tnsnames.ora configured correctly, this we changed. We now have brarchive shipping redo logs to the standby database. On the standby database brarchive is now applying the redo logs to the standby database.

We have one last hurdle to get over. When an redo log arrives on the standby database brarchive applies the log and then immediately tries to apply the very same redo log and then fails, which causes brarchive to terminate. I have set up parameters to copy the log to a different directory on disk, and then delete. Yet in the archive directory the redo log remains and in the original destination directory the redo log has not been copied. When I look in the brarchive log I see that disk has been chosen as the media type and I see that the archive copy directory is correct. I used the parameter -sd in the brarchive command. Did I miss something in regards to telling brarchive to save and delete?

Best regards,
ERP.

[Ramma]

Does SAP note 1360542 apply?

[ERP]

Hello again,

I looked closely at the note and I looked closely at my alert_SID.log. The issue is ‘slightly’ different between note 1360542 and what I saw in my alert log.

The note shows brarchive applying the redo logs like this: log6, log7, log6, log7. The first two log6 and log7 apply correctly. The second log6 and log7 fails.

My alert log shows the following: log_196, log_196, log_197, log_197. The first log_196 and log_197 are applied correctly. The second log_196 and log_197 fails. brarchive process then dies.

We were on patch level 16 for brarchive, I brought down the latest version of BR*TOOLS. We are now on brarchive 7.00 (46) for brarchive on the disaster recover server. After bringing BR*Tools up to the latest I see the same results in my alert log.

Any path that you can send me down to research this issue is appreciated.

ERP.

[ERP]

Hello All,

I would like to report back on the conclusion of shipping the redo logs to the standby database server and applying the redo logs to the standby database.

Our Basis release is 6.20. Our kernel release is 6.40. Our Oracle is 10g. Since we are on 10g we must use BR*Tools 7.00 or higher. We were on BR*Tools 7.00 (46). The shipping of the redo logs worked well, for months now using BR*Tools 7.00 (46). The automatic applying of the redo logs to the standby database failed. We opened up a message to SAP. We were asked to run BRARCHIVE with option –TRC 15 and send SAP the log file. I returned the log file and this file was turned over to SAP development. The end result was I was asked to: “please download the corrected version of BR*Tools 7.10(30+)”. We are now systematically and automatically shipping redo logs to the standby database server and applying the redo logs to the standby database. All who wish to use the BRARCHIVE process in conjunction with a standby database please ensure that you are using a valid version of BR*TOOLS.

Best regards,
ERP.