Results 1 to 9 of 9
  1. #1
    Newcomer
    Join Date
    Aug 2011
    Posts
    17
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default TDP schedules failing after instance name change

    Hi,


    I have a problem with a certain TDP backup for an Oracle11 DB running on a Unix-AIX server.
    The DB and TDP worked fine since they were first configured, until the Oracle instance name had to be changed.

    After the instance name has been changed, the scheduled backups won't run anymore.
    I have changed the instance name in the TDP/RMAN scripts, as well as in the configuration files. The schedule on the node has been restarted.
    The dsmerror file only states that the schedule had failed with an error code of 1, the dsmsched file gives more or less the same output.

    The TDP/RMAN scripts are known to work OK, since they manually complete successfully.

    My best guess is that I might have forgotten to update the instance name in any of the configuration files, so I'd like to verify which files exactly are to be changed in the scenario.
    Also, if you have any other ideas that could help...

    Thanks

  2. #2
    Newcomer
    Join Date
    Aug 2011
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    pls check schedule scripts

  3. #3
    Newcomer
    Join Date
    Aug 2011
    Posts
    17
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by nopalh View Post
    pls check schedule scripts
    The scripts are OK - the instance name has been changed, and they work fine when run manually.

    This is as far as I know for now:
    The TSM scheduler is running, and it does start to run the script configured under "description". The dsmsched.log records that the scheduled task (the script) has started to run, and then no other output is added, also the next scheduled backups on this node fail to start - most ptobably meaning that the script is "stuck", making the scheduler think that it is still running.

    I have tried to run the script manually with the same users/priviliges the TDP scheduler uses, and it works just fine. I'm not sure what other differences between running the script manually and running it with the TDP scheduler could affect its way of work.

  4. #4
    Member
    Join Date
    Jan 2011
    Posts
    108
    Thanks
    13
    Thanked 3 Times in 2 Posts

    Default

    did you check the permission for the script file?

    usually rman is run with the oracle id which has sufficient previlages to the databases.

    may be you should add a line to" su to the oracle id " to the script and try t run it again!

  5. #5
    Newcomer
    Join Date
    Aug 2011
    Posts
    17
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by tsmdumber View Post
    did you check the permission for the script file?

    usually rman is run with the oracle id which has sufficient previlages to the databases.

    may be you should add a line to" su to the oracle id " to the script and try t run it again!
    Yes, I have checked the permission as well.

    The RMAN scripts indeed usually run with the oracle user. I have tried running the scripts manually with the oracle user, as well as running them with a "su" command from the root user (which is how the TDP scheduler runs them). It worked in both cases manually, but still nothing when running the scheduler.

    Is it possible that the TDP installation gets some properties from the DB when being installed, and therefore has issues with instances that have been changed/installed after the TDP? My best guess for now is to reinstall the TDP client, but I'd rather find a solution than this workaround.

  6. #6
    Newcomer
    Join Date
    Aug 2011
    Posts
    17
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Hi,


    Sorry to bump this old thread, but the problem hasn't been resolved yet, and I now need once again to deal with this server.
    Last thing I tried was making the scheduler run a very simple script (only an "echo"), at which it has also failed with a return code 1, meaning the problem is surely not in the scripts but rather in the TSM/TDP configuration somewhere.

    Are there any other tests I could run?

  7. #7
    Member
    Join Date
    Jan 2010
    Location
    San Nicolas de los Garza NL
    Posts
    176
    Thanks
    0
    Thanked 8 Times in 8 Posts

    Default

    try reset daemon dsmcad

    regards

  8. #8
    Newcomer
    Join Date
    Sep 2008
    Location
    India
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Hi mmbdcis,

    Could you please copy & paste error message from "tdpoerror.log" and oracle logs.

  9. #9
    Member
    Join Date
    Jan 2010
    Location
    San Nicolas de los Garza NL
    Posts
    176
    Thanks
    0
    Thanked 8 Times in 8 Posts

    Default

    please, review "tdpoconf password", if you change instance name you have to relink the same with tdpo to make up the backup

    regards

Similar Threads

  1. Report on schedules failing on 7 consecutive days
    By ianmitchell in forum Administrative Client
    Replies: 5
    Last Post: 04-07-2011, 10:57 AM
  2. Opinion on TDP schedules
    By etchingsj in forum Microsoft SQL Server
    Replies: 0
    Last Post: 04-22-2009, 05:48 PM
  3. Replies: 1
    Last Post: 11-10-2007, 01:08 AM
  4. Domino TDP and Schedules
    By Aaron S. in forum Domino
    Replies: 3
    Last Post: 10-23-2007, 12:31 PM
  5. How to change Schedules
    By benmartins in forum Backup / Archive Discussion
    Replies: 1
    Last Post: 06-05-2007, 06:47 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •