ORA-01034 while DB13 offline backup running

[JPReyes]

Hi All,

Ok, here is a wierd one that is driving me crazy...

After upgrade to ERP6 EHP5 every time that an schedule whole database offline backup runs my logs (dev_w*) get filled with entries like this:

ORA-01034: ORACLE not available

ORA-27101: shared memory realm does not exist

Linux-x86_64 Error: 2: No such file or directory

*** ERROR => CONNECT failed with sql error '1034'

SAPUSER error or connect error 99=DBSL_ERR_DB, oerr=1034.

reconnect failed for connection 0

and SM21,

Error in DB rollback/SyFlush, return code 000256

Now, its pretty obvious that if the DB is down for backup Oracle will not be available but should I be getting this entries in the log?.... The processes should hold until reconnection is possible after the backup.

Other than the log entries theres no impact on the system and the backup is perfectly good...

I have tried almost everything... including updating kernel, some note pointed to listener.ora and tnsnames.ora which are completely fine, theres no Notes related to this and I'm running out of ideas.

Anyone?

Regards, Juan

[Former Member · Accepted solution]

Hi Juan,

Bit confused here. Please let me know if my understanding is correct: These errors are filling up trace files when the backup is still running and not after the backup has been completed and a reconnect is being made to the now available DB. I suppose it is the 1st case. In that case reconn params need to be checked. Please have a look at OSS note 98051.It discusses some important params as well as offline back up scenario (though it is as old as 3.1H 🙂 ) . Have a look at parameter: rsdb/reco_sosw_for_db as well.

Regards.

Ruchit.

[JPReyes · Accepted solution]

Hi Ruchit,

All parameters in Note 98051 are set to default and according to the Note, also the reconnection happens without problems... its just leaving a lot of garbage on the developer traces and lots of "Error in DB rollback/SyFlush, return code 000256" on SM21 during the time of the backup.

Also, workprocess do nor restart, they wait for the DB to be available and reconnect.

Regards, Juan

[Former Member · Accepted solution]

Hi Juan, 

May be raising an OSS would be a good idea. Else you may think about removing the error code from the parameter rsdb/reco_add_error_codes (though I am not sure of this approach and actually won't recommend it without checking with SAP). It is an irritant but not a show stopper so may be you can probably ignore it as well :-). In case you still have an EHP4 system available just check this parameter's value and that of other reconn parameters to find if any changes have occured due to the upgrade.

But I guess checking with SAP AG isn't such a bad idea after all.

Regards.

Ruchit.

[Former Member · Accepted solution]

It could also be that this Ora error code has been added to class DBSL_EC_RESTART. Also you don't need to remove the error code as such . Assigning a "-" would mean removal or "+" would mean addition. OSS note 41678 gives the idea. But still please check with SAP before you try to make any change.

Regards.

Ruchit

[JPReyes · Accepted solution]

Thanks Ruchit,

The system was upgraded directly from 4.7 and there was no such parameter configured before the upgrade and use to do the backups via DB13 without leaving any traces on the logs... its really doing my head. I'm going to open an OSS and see what they come back with.

Regards,

Juan

[Former Member · Accepted solution]

Okay seems it may not be a good idea since reconnect is anyways happening and any change might cause problems with something already working :-). Please ignore it.

Regards.

Ruchit.

[Former Member · Accepted solution]

Hi Juan,

I agree. Please go to SAP. But anyways what are the values of this profile parameter. I think +1034 should be there. Just interested. No access to an oracle EHP5 system as of now so just curious.

Regards.

Ruchit.

[JPReyes · Accepted solution]

Just got a message back from SAP,

Quote,

"above mentioned ora- errors in SM21 log is the expected behaviour of Kernel 7.20 but you can ignore these errors safely."

I'm hoping that a few more message exchanges may lead to a further investigation and maybe a fix as didn't get this errors while running kernel 6.40 and i can't see a reason why it would be acceptable to have them in kernel 7.20.

Regards, Juan

[Former Member · Accepted solution]

Well I can't say much  as they agree with one of my viewpoints of ignoring this message 🙂

May be few more OSS messages like yours and they will fix it in a later day patch.

Regards.

Ruchit.

[JPReyes · Accepted solution]

Well after a few months of messages with SAP, seems like a fix its going to be released today on a new Kernel. So finges crossed.

Regards, Juan

[Former Member · Accepted solution]

Hello Juan,

I just have same issue since a Kernel upgrade (701 to 720 300)

Could you let me know how did you solved your issue please?

rgds,

[JPReyes · Accepted solution]

Yeah... They realised the fix on dw (Disp+work) package 313, so make sure you have the latest kernel + dw 313 or above.

Regard, Juan

[Former Member]

Juan,

Have you tried setting any of these parameters related to DB Connection properties with SAP work processes - http://help.sap.com/saphelp_nw70/helpdata/en/08/5744914ae611d1894f0000e829fbbd/content.htm ?

Regards,

Josh

[JPReyes]

Hi Josh,

Thanks for the comment.

DB reconnection is not a problem, it happens without any issues. The thing is that those reconnect attempts leave a trail of errors on SM21 and dev_w*... and they should not be filling the logs as far as I know.

Regards, Juan

[Former Member]

Juan,

Just to be clear, you're saying this behavior started after EHP5 and the offline backup process was the same before that? 

Would it be an acceptable alternative to script the offline backup process instead with  stopsap, brbackup and then startsap?

Either way, if the answer to the first question is yes then it sounds like you hit on a kernel bug with the application of EHP5.  I'm interested to hear the final explanation on this for future reference, if you end up opening an OSS message.

Good luck!

- Josh

[JPReyes]

Just to be clear, you're saying this behavior started after EHP5 and the offline backup process was the same before that?

Yes, there was no mesages before the upgrade.

Would it be an acceptable alternative to script the offline backup process instead with  stopsap, brbackup and then startsap?

As i mentioned before the messages are not stopping the backup been successful, they are just contaminating the logs.

I will keep this thread up to date, it might end been something simple.

Regards, Juan

[Former Member]

Juan,

Have you tried updating your BRTOOLS to that latest version? Or did you do this when updating your kernel?

Regards

Ryan

[JPReyes]

I'm using the latest kernel 201 for Linux x86_64 and also the latest BRTOOLS 720 (patch 23) available. An also tried with the 2 previous kernels.

Regards, Juan