TDP for Oracle RMAN schedule backup fails

adsm04

ADSM.ORG Member
Joined
Jul 11, 2006
Messages
99
Reaction score
0
Points
0
Website
Visit site
PREDATAR Control23

TDP for Oracle RMAN schedule backup fails with error 129.
Below is the error in the client schedule log:

10/04/09 13:42:43 Finished command. Return code is: 129
10/04/09 13:42:43 ANS1909E The scheduled command failed.
10/04/09 13:42:43 ANS1512E Scheduled event 'ORACLEDB' failed. Return code = 129.
10/04/09 13:42:43 Sending results for scheduled event 'ORACLEDB'.

Below from client tdperror log:
10/04/09 13:42:43 ANS1909E The scheduled command failed.
10/04/09 13:42:43 ANS1512E Scheduled event 'ORACLEDB' failed. Return code = 129.

Please advise.
 
PREDATAR Control23

What operating system that is hosting the TDP/Oracle?

If its Windows, more than likely the schedule service does not have enough permssion to run the cmd file.
Update the schedule service to the user account or an admin account or a domain account.

If its Unix, root should be starting the schedule daemon.

Good Luck,
Sias
 
PREDATAR Control23

OS is AIX 5.3
I have started dsmc schedule using root authority. when i run the schedule script manually it runs fine without any issues.
 
PREDATAR Control23

Error on TSM server:
08/10/09 12:47:23 ANR2579E Schedule ORACLEDB in domain ORACLE for node
node_TDP failed (return code 129). (SESSION:
39142)

------------------------------------------Error on Client side
10/08/09 12:44:04 ANS1909E The scheduled command failed.
10/08/09 12:44:04 ANS1512E Scheduled event 'ORACLEDB' failed. Return code = 129.
 
PREDATAR Control23

How are we starting the schedule daemon?
What is the full syntax?

Good luck,
Sias
 
PREDATAR Control23

Hi,
I'm adding the scheduler entry in inittab
itsm:: once:/usr/bin/dsmc sched > /dev/null 2>&1 # TSM scheduler (Inittab )

and also starting it in the background using this command:

nohup dsmc schedule -servername=TSMbackup 2> /dev/null &
 
PREDATAR Control23

Is this node also in charge of the filesystem backup? If so are those backups completing succesfully, also are filesystem and database backups scheduled for the same time - if so you will need two schedulers running.
 
PREDATAR Control23

I thought with TDP it was the database that started the backup, not TSM?

It is, but he's referring to what schedules the start. He's using TSM scheduler to do that. In my shop we kick off Oracle backups with an enterprise scheduler instead of TSM scheduler.
 
PREDATAR Control23

It is, but he's referring to what schedules the start. He's using TSM scheduler to do that. In my shop we kick off Oracle backups with an enterprise scheduler instead of TSM scheduler.

Right, we use a separate instance of dsmcad so that the filesystem and database backups don't interfere with each other.
 
PREDATAR Control23

Ah... in my all important world - we have a TSM client for the Database OS, then install the TDPO client, which the DBA sets up the database backup. He does have TDPO backup files several times a day, plus nightly, and weekly full backups.
 
PREDATAR Control23

OS is AIX 5.3
I have started dsmc schedule using root authority. when i run the schedule script manually it runs fine without any issues.

can you list the schedule in detailed format?

example from my environment would be:
tsm: INUTSM10>q sched tdp-oracle rman_arch_0045 f=d
Policy Domain Name: TDP-ORACLE
Schedule Name: RMAN_ARCH_0045
Description: rman_arch.sh @ 0045
Action: Command
Options:
Objects: su - oracle -c /home/oracle/scripts/rman/rman_arch.sh
Priority: 3
Start Date/Time: 06/26/2009 00:45:00
Duration: 15 Minute(s)
Schedule Style: Classic
Period: 1 Day(s)
Day of Week: Any
Month:
Day of Month:
Week of Month:
Expiration:
Last Update by (administrator): $$CONFIG_MANAGER$$
Last Update Date/Time: 07/17/2009 16:52:15
Managing profile: STANDARD


tsm: INUTSM10>
 
PREDATAR Control23

Hi Tenpin,
Have configured 2 TSM nodes on the server, one for Filesystem bacup and another for TDP oracle using RMAN. The filesys backups run fine, no probs. The issue is with TDP oracle schedule.
 
PREDATAR Control23

I just uncovered this same problem. the culprit was an error in the ORACLE user's .profile file. The specific problem was a "stty erase" command that would fail when there was no TTY (like when a background job is running). the error in the .profile would cause TSM to report a RC=129 result. removing the STTY corrected the issue.
 
PREDATAR Control23

I just uncovered this same problem. the culprit was an error in the ORACLE user's .profile file. The specific problem was a "stty erase" command that would fail when there was no TTY (like when a background job is running). the error in the .profile would cause TSM to report a RC=129 result. removing the STTY corrected the issue.


can you please elaborate , i have the same failure but when i checked the Oracle .profile i didnt find stty erase or anything of that sort
Please advice
 

Attachments

  • profile.txt
    1.9 KB · Views: 1
Top