FAQ
Hello expert,

My environment has 10 Oracle databases. The job is run called up by
UNIX script. The job may need to sign on with different User IDs to
different Oracle database instance in order to get the batch job
running. To avoid to logon with a wrong database instance, the
current practice is to hard-code the logon ID, password, and the
Connect String on the UNIX script.

If I want to remove the hard-code of the logon information, would you
mind to share your experience how to handle this change? How to set
up the UNIX User environment based on the job so that the script can retrieve the Connect String
easily?

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.

Search Discussions

  • Tanel Põder at Aug 15, 2004 at 3:42 am

    If I want to remove the hard-code of the logon information, would you
    mind to share your experience how to handle this change? How to set
    up the UNIX User environment based on the job so that the script can
    retrieve the Connect String
    easily?
    Set TWO_TASK environment variable in Unix to required connect string (LOCAL
    in Windows). That way your client connects to connect string specified in
    env variable if you don't ask for an excplicit string.

    Also, in your scripts you can check the connect string using sqlplus
    "_connect_identifier" variable or query v$instance...

    SQL> select host_name, instance_name, '&_connect_identifier' conn, user from
    v$instance;
    old 1: select host_name, instance_name, '&_connect_identifier' conn, user
    from v$instance
    new 1: select host_name, instance_name, 'test.world' conn, user from
    v$instance

    HOST_NAME INSTANCE_NAME CONN USER

    ---------- ---------------- ---------- ----------
    PORGAND test test.world ADMIN

    Tanel.

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Wes Brooks at Aug 15, 2004 at 8:57 am
    Hello Tanel,

    Thank you for your input.

    I would like to clarify my question here. Yes, I agree that the TWO_TASK environment variable can
    be set if there is only one database. However, I have 10 database instances in two servers. I
    need to tell the script which database instance should be logon.

    The design is:

    Put all the User ID and password inside e.g. password.ksh script. But there will be a lot of IF
    and CASE statements because the the logon information is determined by the Connect String and the
    Oracle User ID.

    The calling script will call the password.ksh to retrieve the password and Oracle user ID. But I
    have problem to retrieve the Connect String unless I have to hardcode in the UNIX script e.g.
    ORACLE_DATABASE=ABC_SID.

    Do we have a better way to handle this hard-coding?

    Tanel_Põder wrote:
    If I want to remove the hard-code of the logon information, would you
    mind to share your experience how to handle this change? How to set
    up the UNIX User environment based on the job so that the script can
    retrieve the Connect String
    easily?
    Set TWO_TASK environment variable in Unix to required connect string (LOCAL
    in Windows). That way your client connects to connect string specified in
    env variable if you don't ask for an excplicit string.

    Also, in your scripts you can check the connect string using sqlplus
    "_connect_identifier" variable or query v$instance...


    SQL> select host_name, instance_name, '&_connect_identifier' conn, user from
    v$instance;
    old 1: select host_name, instance_name, '&_connect_identifier' conn, user
    from v$instance
    new 1: select host_name, instance_name, 'test.world' conn, user from
    v$instance

    HOST_NAME INSTANCE_NAME CONN USER
    ---------- ---------------- ---------- ----------
    PORGAND test test.world ADMIN

    Tanel.


    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared Still at Aug 15, 2004 at 10:17 am

    On Sun, 2004-08-15 at 07:01, Wes Brooks wrote:

    The calling script will call the password.ksh to retrieve the password and Oracle user ID. But I
    have problem to retrieve the Connect String unless I have to hardcode in the UNIX script e.g.
    ORACLE_DATABASE=ABC_SID.
    Do we have a better way to handle this hard-coding?
    Use the password server in the PDBA toolkit.

    Passwords are stored in a configuration file, and
    served up to clients by a server listening on a
    port.

    http://www.oreilly.com/catalog/oracleperl/pdbatoolkit/

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedAug 14, '04 at 11:33p
activeAug 15, '04 at 10:17a
posts4
users3
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase