Skip Headers
Oracle® Database Gateway Installation and Configuration Guide
11g Release 2 (11.2) for Microsoft Windows

Part Number E12061-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

13 Configuring the DRDA Server

This chapter describes tasks you must perform to configure the DRDA server. Each supported operating system is addressed separately. Experience with the given operating system and database is required.

The steps for configuring your remote DRDA server apply to the following DRDA servers:

Configuring a DRDA database to enable access by the gateway requires actions on the DRDA database and on certain components of the host operating system. Although no Oracle software is installed on the host system, access to, and some knowledge of the host system and DRDA database are required during the configuration. Refer to the vendor documentation for complete information about your host system and DRDA database.

This chapter contains the following sections:

13.1 Configuring the DRDA Server for DB2 UDB for z/OS

Perform the following tasks to configure the DRDA server with DB2 on a z/OS system:

  1. Define the user ID that owns the package

    During first gateway usage for a particular DRDA server, an Oracle supplied package will be automatically bound to the DRDA server. The user ID and password that are used (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the package. The followings are minimum authorities needed by this user:

    • Package privileges of BIND, COPY, and EXECUTE, for example:

      GRANT BIND    ON PACKAGE oraclegtw.* TO userid
      GRANT COPY    ON PACKAGE oraclegtw.* TO userid
      GRANT EXECUTE ON PACKAGE oraclegtw.* TO PUBLIC
      
    • Collection privilege of CREATE IN, for example:

      GRANT CREATE IN COLLECTION oraclegtw TO USER userid
      
    • System privileges of BINDADD and BINDAGENT, for example:

      GRANT BINDADD   TO USER userid
      GRANT BINDAGENT TO USER userid
      
    • Database privilege of CREATETAB, for example:

      GRANT CREATETAB ON DATABASE database TO USER userid
      

    Choose a user ID that will own the package and the HS_TRANSACTION_LOG table. Ensure that this user ID is defined to both DB2 and OS/390 (MVS).

  2. Define the recovery user ID

    During gateway configuration, the recovery user ID and password are specified in the gateway initialization file using the HS_FDS_RECOVERY_ACCOUNT and HS_FDS_RECOVERY_PWD parameters. If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password that are defined in these parameters. This user ID must have execute privileges on the package and must be defined in the DRDA database. If the user ID is not specified in HS_FDS_RECOVERY_ACCOUNT, then the gateway attempts to connect to a user ID of RECOVER when a distributed transaction is in doubt.

    Determine the user ID and password that you will use for recovery.

  3. Determine DRDA location name for DB2 instance

    The DRDA location name is required as a gateway parameter. To determine the location name, run the following SQL query from a DB2 SPUFI session:

    SELECT CURRENT SERVER FROM any_table 
    

    where any_table is a valid table with one or more rows.

    If the value returned by this query is blank or null, then the DRDA location name has not been established. Contact the system administrator to arrange to set a location name for the instance.

  4. Configure DB2 Distributed Data Facility for Gateway

    DB2 Distributed Data Facility (DDF) is the component of DB2 that manages all distributed database operations, both DRDA and non-DRDA.

    If your site uses DB2 distributed operations, then DDF is probably operational on the DB2 instance that you plan to access through the gateway. If DDF is not operational, then you must configure it and start it as described in the appropriate DB2 documentation.

    Even if DDF is operational on the DB2 instance, it might be necessary to make changes to the DDF Communication Database (CDB) tables to specify the authorization conduct of DRDA sessions from the gateway. Properly authorized users can do this with a utility such as the DB2 SPUFI utility. If you make changes to CDB tables, then you must stop and restart DDF for the changes to take effect. Refer to Chapter 15, "Security Considerations", for additional CDB tables and security information.

13.2 Configuring the DRDA Server for DB2 UDB for iSeries

Experience with DB2 UDB for iSeries and AS/400 is required to perform the following steps:

  1. Define the user ID that owns the package

    During gateway configuration, you will need to run the Bind Package Stored Procedure to bind the gateway package on the DRDA Server. To properly bind the package, the user ID and password that are used when the procedure is run (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the package. This user ID should be used to create and own the HS_TRANSACTION_LOG table. The user ID that is used to bind or rebind the DRDA package must have the following privileges on the DRDA Server:

    • Use authority on the CRTSQLPKG command

    • Change authority on the library in which the package will be created

    Choose a user ID now that will own the package and the HS_TRANSACTION_LOG table. Ensure that this user ID is defined in DB2 UDB for iSeries and AS/400.

  2. Define the recovery user ID

    During gateway configuration, the recovery user ID and password are specified in the gateway initialization file using the HS_FDS_RECOVERY_ACCOUNT and HS_FDS_RECOVERY_PWD parameters. If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password that are defined in these parameters. This user ID must have execute privileges on the package and must be defined to the DRDA database. If the user ID is not specified in HS_FDS_RECOVERY_ACCOUNT, then the gateway attempts to connect to a user ID of RECOVER when a distributed transaction is in doubt.

    Determine the user ID and password that you will use for recovery.

  3. Determine DRDA location name for DB2 UDB for iSeries instance

    The DRDA location name is required as a gateway parameter. To determine the location name, run the following SQL query from a STRSQL session. If SQL is unavailable on the system, then use the AS/400 command DSPRDBDIRE to identify your LOCAL DRDA Server.

    SELECT CURRENT SERVER FROM any_table
    

    where any_table is a valid table with one or more rows.

    If the value returned by this query is blank or null, then the DRDA location name has not been established. Contact the system administrator to arrange to set a location name for the instance.

13.3 Configuring the DRDA Server for DB2 UDB for Linux, UNIX, and Windows

Experience with DB2/UDB, configuring the communication subsystem of DB2 UDB for Linux, UNIX, and Windows, and the host System Administration tools is required to perform the following steps.

  1. Define the user ID that owns the package

    During first gateway usage for a particular DRDA server, an Oracle supplied package will be automatically bound to the DRDA server. The user ID and password that are used (either implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the package. The followings are minimum authorities needed by this user:

    • Package privileges of BIND and EXECUTE, for example:

      GRANT BIND    ON PACKAGE oraclegtw.* TO userid
      GRANT EXECUTE ON PACKAGE oraclegtw.* TO PUBLIC
      
    • Schema privilege of CREATEIN, for example:

      GRANT CREATEIN ON SCHEMA otgdb2 TO USER userid
      GRANT CREATEIN ON SCHEMA oraclegtw TO USER userid
      
    • Database authorities of CONNECT, BINDADD, and CREATETAB, for example:

      GRANT CONNECT   ON DATABASE TO USER userid
      GRANT BINDADD   ON DATABASE TO USER userid
      GRANT CREATETAB ON DATABASE TO USER userid
      

    Choose a user ID that will own the package and HS_TRANSACTION_LOG table. Ensure that this user ID is defined in both the DB2 instance ID and the operating system.

  2. Define the recovery user ID

    During gateway configuration, the recovery user ID and password are specified in the gateway initialization file using the HS_FDS_RECOVERY_ACCOUNT and HS_FDS_RECOVERY_PWD parameters. If a distributed transaction fails, then the recovery process connects to the remote database using the user ID and password that are defined in these parameters. This user ID must have execute privileges on the package and must be defined to the DRDA database. If the user ID is not specified in HS_FDS_RECOVERY_ACCOUNT, then the gateway attempts to connect to a user ID of RECOVER when a distributed transaction is in doubt.

    Determine the user ID and password that you will use for recovery.

  3. Determine DRDA location name for DB2 UDB for Linux, UNIX, and Windows instance

    The DRDA location name is required as a gateway parameter. To determine the location name, run the following SQL query from a DB2 CLI session:

    SELECT CURRENT SERVER FROM any_table
    

    where any_table is a valid table with one or more rows.

    If the value returned by this query is blank or null, then the DRDA location name has not been established. Contact your system administrator to set a location name for the instance.