Results 1 to 5 of 5
  1. #1
    Join Date
    Apr 2015
    Posts
    4
    Provided Answers: 1

    Question Answered: TSM has been uninstalled and now db2 reports SQL2071N error with Reason code 1

    Hello db2 experts

    TSM has been uninstalled on our SUSE server hosting SAP and now db2 reports [ SQL2071N An error occurred while access the shared library /db2/TCK/sqllib/adsm/libtsm.a. Reason code: "1" ] when attempting to access the db.

    For example.......

    host-name:db2tck 91> db2 select schemaname from syscat.schemata
    SQL2071N An error occurred while accessing the shared library
    "/db2/TCK/sqllib/adsm/libtsm.a". Reason code: "1".

    host-name:db2tck 92> db2adutl query
    db2adutl: error while loading shared libraries: libApiTSM64.so: cannot open shared object file: No such file or directory
    host-name:db2tck 93>

    How do I resolve this?

  2. Best Answer
    Posted by solo_2

    "As it turns out library libApiTSM64.so was missing on my system. I was able to copy it from another system and all is good now. I am able to start db2 and startsap.

    Thanks for your help db2mor."


  3. #2
    Join Date
    Apr 2012
    Posts
    1,034
    Provided Answers: 18
    That depends on whether or not you need TSM...for log-archival, backup, and recovery (something omitted from your post, along with other omissions such as the DB2 version and fixpack and edition). You did not explain whether the uninstallation was accidental or deliberate. Is this a production environment?

    Most likely you do need the TSM, probably it was the TSM client that got uninstalled.

    If you do need TSM then re-install the same version TSM client (preferably from the same image as previously used), using the same path as the previous installation, configure it, and verify it works for log archival, backup, and recovery.

    If you definitely don't need TSM , and you have a different proven working solution for log-archival and backup/recovery then remove the TSM configuration settings from the db cfg, from the instance profile. The method depends on the DB2 version, but most likely LOGARCHMET1, LOGARCHMETH2, and possibly logarchopt1/logarchopt2. (These changes are effective after deactivate database, those variables need to be set to suit your new archival/backup approach). Also unset the variables DSMI_DIR, DSM_CONFIG, DSMI_LOG wherever they are set (e.g. in the .profile or db2profile or userprofile etc) for this db2-instance. After all these changes, bounce the db2-instance.

  4. #3
    Join Date
    Apr 2015
    Posts
    4
    Provided Answers: 1
    This was my first post. I apologize for not providing complete information.

    The uninstall was intentional and was done by a 3rd party. We are using another means of backup; basically a db2 on-line backup followed by a COMMVAULT backup of the Linux host and db2 backup file.
    The db2 version is DB2 v9.7.0.9, at Fix Pack 9.
    This is a sandbox environment for an implementation of a product called Data Liberator.

    Does this version change your response?

    Your input is appreciated.

  5. #4
    Join Date
    Apr 2012
    Posts
    1,034
    Provided Answers: 18
    I would ensure TSM is decommissioned fully (from DB2) before switching to Commvault.

    That means: can activate the database, deactivate the database, archive logs, backup to disk, restore from disk, rollforward etc without TSM and without issue (before activating Commvault).

    Hence any mention of TSM in any of the DBM CFG and /or DB CFG or DB2 registry settings needs to be removed -per my previous post.

    You don't specify whether you plan to use the Commvault agent (integrated with DB2 for log archival/retrieval), but that is unrelated to proper decommissioning of TSM. If you do then you will need to configure logarchmeth1/2 logarchopt1/2 vendoropt etc according to Commvault documentation. If you don't plan to integrate Commvault with DB2 (and instead use only flat file backups by Commvault) then you will need to manage the archive logs via appropriate scripting, and additionally you will need to assess the RTO/RPO (possibly archiving to dual locations to achieve the RPO).

    I recommend you exhaustively test your DB2 archival and recovery if using Commvault, because I previously had quality issues with that solution some years ago, but time may have resolved the issues.

  6. #5
    Join Date
    Apr 2015
    Posts
    4
    Provided Answers: 1

    Thumbs up

    As it turns out library libApiTSM64.so was missing on my system. I was able to copy it from another system and all is good now. I am able to start db2 and startsap.

    Thanks for your help db2mor.

Tags for this Thread

Posting Permissions

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