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
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.
 
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
 
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.
 
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.
 
How are we starting the schedule daemon?
What is the full syntax?

Good luck,
Sias
 
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 &
 
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.
 
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.
 
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.
 
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.
 
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>
 
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.
 
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.
 
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
Back
Top