Background Job is Cancelled while taking Offline Backup

[Former Member]

Hi all,

Background jobs which are scheduled before Databse Offline Backup are always cancelled. Reconnect WP does not happen even if following parameters are set.

We had set profile parameters in all Application Server like

rsdb/reco_trials = 15

rsdb/reco_sleep_time = 60

rsdb/reco_add_error_codes = +3113 +3114 +1012 +1014 +1033 +1034 +1089 +1089 +1090 +1092

R3 Production server (640 Kernel, Patch 175 , SAP_BASIS 620 , SAP_APPL 470)

Database : Oracle 9.2.0.6

SYSLOG Msg : SM21

<b> Communication error, CPIC return code 020, SAP return code 497

> CPI-C function: CMINIT(SAP)

Operating system call gethostbyname failed (error no. 0 )

Operating system call gethostbyname failed (error no. 0 )

Communication error, CPIC return code 020, SAP return code 497

> CPI-C function: CMINIT(SAP)

Communication error, CPIC return code 020, SAP return code 497

> CPI-C function: CMINIT(SAP)

Communication error, CPIC return code 020, SAP return code 497

> CPI-C function: CMINIT(SAP)

........ More Msg

Work process has left reconnect status

Run-time error "DBIF_REPO_SQL_ERROR" occurred

> Short dump "070924 223110 r3apps5 BASIS " generated

Transaction Canceled 00 671 ( DBIF_REPO_SQL_ERROR 20070924223110r3apps5 BASIS 5001 )

</b>

I had checked with SAP Note :24806 , 98051 , 544881

Thanks & Regards.

Naba

[fidel_vales]

Hi,

I'm not sure if I understand what you mean.

<quote>

<b>Background jobs which are scheduled before Databse Offline Backup are always cancelled.</b>

</quote>

I understand that you have a job that start at ( example ) 12:00

at 12:30 the job still is running

at 12:30 the database is shutdown for backup

at 12:30 the job crash

is this correct?

If so, I think it is normal.

The database is stopped, no access to it is possible.

The reconnect is meant for the SAP system to stay "alive" during the the offline backup. It will restart the workprocess not the "Job" that was running.

Please take a look at the note 98051 for a proper explanation of the architecture.

As mentioned, if you need the jobs to be executed during the backup, then you must do an online backup not an offline one.

[Former Member]

Hi,

You could visualize the problem exactly.

I had re-read the Note 98051,Your explanation to the problem may be correct

( Refer Point No 14).

I thought any Job will be restarted after backup is over.

The Work Process survives without losing buffer contents and therefore without

losing performance. I had expected the Job to be restarted from the start.

Offline backup we take only on Sunday weekly once. For online(Mon-Sat) backup

we have no problem.

Thank & Regards.

Naba

[Former Member]

Hello,

Since you are using Oracle 9i and sap kernel 640, why don't you look at Online backup option?

From note 98051, it advises you to log a support call with SAP if you face any of such issues.

Note 98051 - Database Reconnect: Architecture and function:

23. Problem analysis

24. Reconnect scenarios should basically run as described above. If problems occur, it is helpful to analyze the trace files. In particular, the entries described in the FUNCTIONS section (B **LOG BYM=> ...) should appear in the dev_w developer traces.

25. If you contact SAP concerning your problem, make sure to describe the error scenario as accurately as possible.

26. Special attention should be given to the following points:

a) The work process fails to set up the reconnect time and time again, despite the fact that the database(connection) is working:

b) Does the system continue to write entries concerning the unsuccessful reconnect attempts into the developers trace files of the affected work processes, although the database(connection) is available again? Using another tool (for example, R3trans -d), try to determine whether important connect information is perhaps not accessible (anymore), for example a configuration file.Can the work process restore the database connection after restart (for example using transaction SM50)?

c) The affected work process was (automatically) restarted:

d) This can be seen from the developer traces and SYSLOG. The case described under the section 'Restrictions' exists when you restart: no reconnect occurs.It is therefore important to find the reason for the restart.One cause could be the fact that the database return code does not (yet) belong in the reconnect class (note 24806).This can be corrected with the profile parameter rsdb/reco_add_error_codes (note 41678).Is there a core file in the "work" directory?This may contain information on the cause of process termination.It is most likely that the background and cause of the errors are to be found with SAP Support.

e) One or all work processes hang:

f) In the event of a database failure or also when shutting down the database, you may find that the following situation arises in the interaction of database software, communication software and operating system:an SQL statement or a connect call up issued by the work process hangs, that is, the subroutine call of the database library, which should trigger the corresponding action, no longer returns.In this situation, the work process is unable to break out of this status and must eventually be terminated.You can track down signs for this using the R/3 Tool dpmon.The developers traces may also enable such an interpretation.For SAP and the database produce to process the error, you should describe your configuration in this case as accurately as possible.