Oracle Procedural Gateway® for WebSphere MQ Installation and User's Guide, 10g Release 2 (10.2) for Windows Part Number B16216-02 |
|
|
PDF · Mobi · ePub |
After installing the gateway, follow the instructions in this chapter to configure the gateway. This chapter contains the following sections:
The gateway works with several components and products to communicate between the Oracle server and WebSphere MQ queues:
Oracle Net
The gateway and the integrating server communicate using Oracle Net in a server-to-server manner. You must configure both the gateway and the integrating server to have Oracle Net communication enabled by configuring the tnsnames.ora
and listener.ora
files.
Gateway initialization files and parameters
The gateway has initialization files and parameters that you must customize for your installation. For example, you must choose your gateway system identifier (SID) and provide other information, such as the gateway log file destination.
The gateway is installed and preconfigured using default values for the gateway SID, directory names, file names, and gateway parameter settings. The default SID values are:
This is the default SID that is used when the gateway resides on the same system as the WebSphere MQ software.
A basic gateway initialization file is also installed, and values in this file are set based on the information you enter during the installation phase.
If you are configuring one gateway instance, and if you have no need to change any of the default values, then most of the gateway configuration process is completed by Oracle Universal Installer. In this case, perform the following actions:
Skip all steps under Changing Default Values.
Skip Step 1: Configure the Oracle Net TNS Listener for the Gateway
Begin with Step 2: Stop and start the TNS listener for the Gateway, and continue to the end of the chapter.
If multiple instances of the gateway are being configured, or to modify the default values set during the installation phases, then begin with the steps under Changing Default Values and continue to the end of the chapter.
When changing default values, choose a gateway SID and customize the gateway initialization file.
The gateway SID is a string of 1 to 64 alphanumeric characters that identifies a gateway instance. The SID is used in the gateway boot file and as part of the file name for the gateway parameter file. Choose a SID different from the default SID and different from pg4mqs
and pg4mqc
.
You need a distinct gateway instance and SID for each queue manager you want to access. If you want to access two different queue managers, then you need two gateway SIDs, one for each instance of the gateway. If you have one queue manager and want to access it sometimes with one set of gateway parameter settings and at other times with different gateway parameter settings, then you can do this by having multiple gateway SIDs for one queue manager.
The gateway initialization file (init
sid
.ora
) supports all procedural gateway initialization parameters described in the Oracle Open Gateway Guide for SQL-Based and Procedural Gateways and in Appendix C, "Gateway Initialization Parameters". The initialization file must be available when the gateway is started.
During installation, a default initialization file is created in . ORACLE_HOME
\pg4mq\admin\init
sid.
ora
, where sid
is the default SID of pg4mqs
or pg4mqc
. If you chose an SID other than the default, then rename this file using the SID you chose in Step 1: Choose a System ID for the Gateway. Customize the default initialization file as necessary.
The following entries might appear in an initialization file:
LOG_DESTINATION=log_file QUEUE_MANAGER=manager_name AUTHORIZATION_MODEL=auth_model TRANSACTION_MODEL=tx_model TRANSACTION_LOG_QUEUE=tx_queue_name TRANSACTION_RECOVERY_USER=rec_user TRANSACTION_RECOVERY_PASSWORD=rec_password TRACE_LEVEL=0 MQSERVER=channel MQCCSID=character_set
In this file:
log_file
specifies the full path name of the gateway log file.
manager_name
is the name of the WebSphere MQ queue manager to access.
auth_model
is the authorization model to use. The default is RELAXED.
tx_model
is the transaction model to use. The default value is SINGLE_SITE
.
tx_queue_name
is the name of the queue for logging transaction IDs for distributed transactions. This is used only when tx_model
is set to COMMIT_CONFIRM
.
rec_user
specifies the user name that the gateway uses to start recovery of a distributed transaction. This is used only when auth_model
is set to STRICT
and tx_model
is set to COMMIT_CONFIRM
.
rec_password
specifies the password of the user name that the gateway uses to start recovery of a distributed transaction.
channel
specifies the location of the WebSphere MQ server and the communication method to use. The channel format is:
channel_name/connection_type/hostname [(port_number)]
For example:
MQSERVER=CHAN9/TCP/dolphin(1425)
character_set
specifies the coded character set number used by the gateway when communicating with the WebSphere MQ queue manager. This is an optional parameter.
This parameter is set only if the system that is running the WebSphere MQ queue manager uses a different encoding scheme than the system that runs the gateway. When set, the value of character_set
is used by the WebSphere MQ client software on the gateway system to convert the data.
Refer to IBM publications for more information.
See Chapter 8, "Gateway Running Environment"for more information on transaction and security models.
See Also:
Refer to Oracle Database Net Services Administrator's Guide and Oracle Database Net Services Reference for additional informationThe gateway requires Oracle Net to provide transparent data access to and from the Oracle integrating server. Oracle Net uses the TNS listener to receive incoming connections from an Oracle Net client. In the case of the gateway, the TNS listener listens for incoming requests from the Oracle integrating server. For the TNS listener to listen for the gateway, information about the gateway must be added to the TNS listener configuration file (listener.ora
). This file is located in the ORACLE_HOME
\network\admin
directory by default, where ORACLE_HOME
is the directory under which the gateway is installed. The default values in this file are set for you during the installation process by Oracle Universal Installer.
If you are configuring one gateway instance, and if you donot need to change any of the default values, then no further configuration related to the gateway is necessary for Oracle Net. Perform only "Step 2: Stop and start the TNS listener for the Gateway".
If you intend to use the Oracle Net listener for multiple gateway instances, or if you need to modify some of the default values set during the installation phase, then perform Step 1 and Step 2 in this section.
In Step 1, you add gateway information or change default information in the listener.ora
file in the gateway directory ORACLE_HOME
\network\admin
.
Two entries must be added to the listener.ora
file:
A list of Oracle Net addresses for the TNS listener to listen on
The gateway process that the TNS listener should start in response to incoming connection requests
Note:
The TNS listener and the gateway must reside on the same node. If you already have a TNS listener running on the node, then you make the changes suggested in Steps 1 and 2 to your existinglistener.ora
and tnsnames.ora
files.
After making the changes, you can reload the changes by running the reload
command in the lsnrctl
utility without shutting down the TNS listener.
Specifying Oracle Net Addresses for the TNS Listener
If you are using Oracle Net and the TCP/IP protocol adapter, then the syntax of an entry in the listener.ora
file is:
LISTENER= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=TCP) (HOST=host_name) (PORT=port_number) ) )
In this entry:
host_name
is the name of the system where the gateway is installed.
port_number
specifies the IP port number used by the TNS listener. If you have other listeners running on host_name
, such as the listener of an Oracle integrating server on the same system, then the value of port_number
must be different from the other listener port numbers.
If you are using Oracle Net and the interprocess socket call (IPC) protocol adapter, the syntax of the entry in listener.ora
file is:
LISTENER=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=IPC)
(KEY=key_name)
)
)
In this entry:
IPC
specifies that the protocol used for connections is IPC.
key_name
is the unique user-defined service name.
To configure the TNS listener to listen for a gateway instance in incoming connection requests, add an entry to the listener.ora
file using the following syntax:
SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (SID_NAME=gateway_sid) (ORACLE_HOME=gateway_directory) (PROGRAM=driver) ) )
In this entry:
When you add an entry for multiple gateway instances, add the entry to the existing SID_LIST
syntax:
SID_LIST_LISTENER= (SID_LIST= (SID_DESC=. . . ) (SID_DESC=. . . ) (SID_DESC= (SID_NAME=gateway_sid) (ORACLE_HOME=gateway_directory) (PROGRAM=driver) ) )
The following is an example of an entry made to the listener.ora
file:
(SID_DESC = (SID_NAME=pg4mqs) (ORACLE_HOME=C:\oracle\app\oracle\product\pg4mq) (PROGRAM=pg4mqs) )
Refer to Oracle Database Net Services Administrator's Guide and Oracle Database Net Services Reference for more information about changing listener.ora
.
The TNS listener must be started or reloaded to initiate the new settings.
listener.ora
and tnsnames.ora
files. After making the changes, you can reload the changes by running the reload
command in the lsnrctl
utility without shutting down the TNS listener.
Refer to the Note in "Step 1: Configure the Oracle Net TNS Listener for the Gateway".
Set the gateway directory name:
> set TNS_ADMIN=ORACLE_HOME\network\admin
ORACLE_HOME
specifies the directory where the gateway software is installed.
If the listener is already running, then use the lsnrctl
command to reload the listener with the new settings:
> ./lsnrctl reload your_listener_name
Check the status of the listener with the new settings:
> ./lsnrctl status listener_name
The following is an example of the output from a lsnrctl
status check:
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=ORAIPC)) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Solaris: version 10.2.0 - Production Start Date 21-AUG-04 18:16:10 Uptime 0 days 0 hr. 2 min. 19 sec Trace Level off Security OFF SNMP OFF Listener Parameter File C:\oracle\app\oracle\product\pg4mqs\network\admin\listener.ora Listener Log File C:\oracl\app\oracle\product\pg4mqs\network\log\listener.log Services Summary... pg4mqs has 1 service handler(s) The command completed successfully
In this example , pg4mqs
is the default SID value that was assigned during installation. You can use any valid ID for the SID, or keep the default.
Note:
You must use the same SID value in thetnsnames.ora
file, the listener.ora
file, and the GATEWAY_SID
environment variable in the gateway initialization file for each gateway instance being configured.Any Oracle application that has access to an Oracle integrating server can also access WebSphere MQ through the gateway. Before you use the gateway to access WebSphere MQ, you must configure the Oracle integrating server so that it can communicate with the gateway by using Oracle Net. To configure the server, add connect descriptors to the tnsnames.ora
file.
Any Oracle integrating server that accesses the gateway needs a service name entry or a connect descriptor name entry in the tnsnames.ora
file on the server to tell the Oracle integrating server how to make connections. This file, by default, is located in the ORACLE_HOME
\network\admin
directory, where ORACLE_HOME
is the directory in which the Oracle integrating server is installed. The tnsnames.ora
file is required by the Oracle integrating server that is accessing the gateway, and not by the gateway itself.Refer to Configuration Overview and to Configuring the Gateway
See Also:
Refer to Oracle Database Net Services Administrator's Guide and Oracle Database Net Services Reference for more information about changing thetnsnames.ora
file.The Oracle Universal Installer creates and preconfigures a tn
snames.ora
file in the ORACLE_HOME
\network\admin
directory, where ORACLE_HOME
is the directory in which the gateway software is installed. If you use the default values, and if you do not need to configure additional gateway instances, then you can append the contents of this file to the tnsnames.ora
file of each Oracle integrating server that accesses the gateway.
If you need to change some of the default settings, use the examples in this section to guide you.
An Oracle integrating server accesses the gateway using Oracle Net and the TCP/IP protocol adapter. The syntax of the connect descriptor entry in tnsnames.ora
is:
tns_name_entry= (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=host_name) (PORT=port_number) ) (CONNECT_DATA= (SID=gateway_sid) ) (HS=OK) )
In this example:
tns_name_entry
is the tns_name_entry
of the CREATE DATABASE LINK
statement. Refer to "Creating Database Links" for more information.
TCP
specifies that the protocol used for connections is TCP/IP.
port_number
is the port number used by the Oracle Net TNS listener that listens for the gateway. This port number can be found in the listener.ora
file that is used by the TNS listener. Refer to Specifying Oracle Net Addresses for the TNS Listener.
host_name
specifies the system on which the gateway is running. The TNS listener host name can be found in the listener.ora
file used by the TNS listener that listens for the gateway. Refer to Specifying Oracle Net Addresses for the TNS Listener.
gateway_sid
specifies the SID of the gateway and matches the SID specified in the listener.ora
file of the TNS listener that listens for the gateway.
An Oracle integrating server accesses the gateway using Oracle Net and the IPC protocol adapter. The syntax of the connect descriptor entry in tnsnames.ora
is:
tns_name_entry= (DESCRIPTION= (ADDRESS= (PROTOCOL=IPC) (KEY=key_name) ) (CONNECT_DATA= (SID=gateway_sid) ) (HS=OK) )
In this example:
tns_name_entry
is the tns_name_entry
of the CREATE DATABASE LINK
statement. Refer to "Creating Database Links" for more information.
IPC
specifies that the protocol used for connections is IPC.
key_name
is the service name.
gateway_sid
specifies the SID of the gateway and matches the SID specified in the listener.ora
file of the TNS listener that is listening for the gateway.
When the TRANSACTION_MODEL
parameter in the gateway initialization file is set to COMMIT_CONFIRM
to enable distributed transactions, then an additional configuration step is required to perform the following tasks:
Create a WebSphere MQ queue.
Set the TRANSACTION_LOG_QUEUE
, TRANSACTION_RECOVERY_USER
, and TRANSACTION_RECOVERY_PASSWORD
parameters in the gateway initialization file.
Refer to Commit-Confirm Transactions for more information about the commit-confirm transaction model and Appendix C, "Gateway Initialization Parameters" for information about the TRANSACTION_LOG_QUEUE
, TRANSACTION_RECOVERY_USER
, and TRANSACTION_RECOVERY_PASSWORD
parameters.
See Also:
Refer to IBM publications for information about creating and configuring a queueFor the gateway to recover distributed transactions, a recovery account and queue must be set up in the queue manager by the WebSphere MQ system administrator. This account must be a valid WebSphere MQ user, and it must have authorization to access the recovery queue. Refer to Authorization for WebSphere MQ Objects for more information about access privileges.
The gateway uses the recovery queue to check the status of failed transactions that were started at the queue manager by the gateway and were logged in this queue. The information in this queue is vital to the recovery process and must not be used, accessed, or updated except by the gateway.
A connection to the gateway is established through a database link when it is first used in an Oracle session. In this context, connection refers to the connection between the Oracle integrating server and the gateway. The connection persists until the Oracle session ends. Another session or user can access the same database link and get a distinct connection to the gateway and the queue manager.
Database links are active for the duration of a gateway session. To close a database link during a session, use the ALTER SESSION
statement. .
See Also:
Refer to the Oracle Database Administrator's Guide for more information about using database linksAn alias library is a schema object that represents a library in PL/SQL. Procedural Gateway for WebSphere MQ 10g release 2 uses an alias library to access the shared library installed with Procedural Gateway for WebSphere MQ. To create the alias library, you must have the CREATE LIBRARY
privelege. The alias library used by Procedural Gateway for WebSphere MQ is libpg4mq
and is defined in the pgmobj.sql
script, which is created when the Procedural Gateway for WebSphere MQ deployment scripts are executed.
To create a database link, use the CREATE DATABASE LINK
statement.The CONNECT TO
clause specifies the WebSphere MQ user ID and password when the security model is defined as STRICT
with the AUTHORIZATION_MODEL
parameter. If you do not include the CONNECT TO
clause, then the current user ID and password are used.
When the AUTHORIZATION_MODEL
parameter is set to RELAXED
, you need not specify a user ID and password because the Oracle integrating server uses the user ID and password of the user account that started the TNS listener for the gateway. If you specify a user ID and password with the CONNECT TO
clause, then the Oracle integrating server and gateway ignore those values. Refer to Security Models for more information.The USING
clause points to a connect descriptor in the tnsnames.ora
file.
The syntax of CREATE DATABASE LINK
is as follows:
CREATE [PUBLIC] DATABASE LINK dblink [CONNECT TO userid IDENTIFIED BY password] USING 'tns_name_entry';
where:
dblink
is the database link name.
userid
is the user ID used to establish a session at the queue manager. It is only used when AUTHORIZATION_MODEL
is set to STRICT
in the init
sid
.ora
file. The user ID must be authorized to access all WebSphere MQ objects and database links referenced in PL/SQL command.
The userid
must be in the password file on the system on which WebSphere MQ and the gateway are installed. Otherwise, the userid
must be published in the Microsoft Windows Domain when WebSphere MQ and the gateway are installed on different systems. If userid
contains lowercase letters or nonalphanumeric characters, then you must enclose userid
in quotation marks ("). Refer to your WebSphere MQ documentation for more information about userid
.
password
is the password used to establish a session at the queue manager. It is used only when AUTHORIZATION_MODEL
is set to STRICT
in the init
sid
.ora
file.
The password
must be in the password file on the system on which WebSphere MQ and the gateway are installed. Otherwise, the password
must be published in the WindowsMicrosoft Windows Domain when WebSphere MQ and the gateway are installed on different computers.
If password
contains lowercase letters or nonalphanumeric characters, then surround password
with quotation marks(").
tns_name_entry
is the Oracle Net TNS connect descriptor name specified in the tnsnames.ora
file.
The data dictionary of each database stores the definitions of all the database links in that database. The USER_DB_LINKS
view shows the database links that are defined for a user. The ALL_DB_LINKS
data dictionary views show all the defined database links.
Create the Procedural Gateway for WebSphere MQ alias library, libpg4mq,
by using the PG4MQ deployment scripts. During the installation, the appropriate shared library name is defined in ORACLE_HOME
\pg4mq\admin\deploy\pgmobj.sql
based on the Procedural Gateway for WebSphere MQ model you choose.
For a remote model, the orapg4mqc.dll
shared library is used. For example:
CREATE OR REPLACE LIBRARY libpg4mq AS 'ORACLE_HOME\lib\orapg4mqc.dll' transactional;
For a local model, the orapg4mqs.dll
shared library is used. For example:
CREATE OR RELPLACE LIBRARY libpg4mq AS 'ORACLE_HOME\lib\orapg4mqs.dll' transactional;
Install the Visual Workbench repository by following the steps in this section.
You can skip installing the Visual Workbench repository if you do not plan to use the Visual Workbench, or if you are preparing your production Oracle server where you do not need a Visual Workbench repository, but instead need a Procedural Gateway for WebSphere MQ deployment. Refer to the Preparing the Production Oracle Server for details.
The following steps describe the preinstallation tasks.
A repository server is an Oracle integrating server on which the Visual Workbench repository is installed.
The Visual Workbench repository installation scripts are installed with the Visual Workbench. If the repository is to be installed on the same system as the Visual Workbench, then your repository server already has all the required installation scripts. Proceed to step 3.
Create a directory on the repository server to be the script directory. For example:
> md ORACLE_HOME\pg4mq\admin\repo
Use a file transfer program to transfer the repository zip file (repos
XXX.
zip
, where XXX
is the release number) or move all script files with the .sql
suffix from the script file directory (ORACLE_HOME
\pg4mqvwb\server\admin
) on the Visual Workbench system to the script file directory on the repository server system.
All data mapping packages generated by the Visual Workbench use the UTL_RAW
package, which provides routines for manipulating raw data.
From SQL*Plus, issue the following statement as the user SYS
:
SQL> DESCRIBE UTL_RAW
If the DESCRIBE
statement is successful, then your repository server already has UTL_RAW
installed, and you can proceed to Step 4. If the DESCRIBE
statement fails, then install UTL_RAW
.
From SQL*Plus, as user SYS
, run the utlraw.sql
and prvtrawb.plb
scripts that are in the ORACLE_HOME
\rdbms\admin
directory. You must run the utlraw.sql
script first.
SQL> @utlraw.sql SQL> @prvtrawb.plb
The sample programs and installation verification programs on the installation media use the standard DBMS_OUTPUT
package.
From SQL*Plus, issue the following statement as the SYS
user:
SQL> DESCRIBE DBMS_OUTPUT
If the DESCRIBE
statement is successful, then your repository server has DBMS_OUTPUT
installed, and you can proceed to Step 6.
If the DESCRIBE
statement fails, then install DBMS_OUTPUT
.
See Also:
Refer to Oracle Database Administrator's Guide for more informationCreate a database link on your Oracle Production System Server to access the Oracle Procedural Gateway for WebSphere MQ.
If you do not already have a database link, then refer to Administering the Database Links Alias Library for more information about creating database links.
Use pgvwbrepos.sql
to install the Visual Workbench repository on Oracle10g. To run pgvwbrepos.sql
, ensure that you are currently in the ORACLE_HOME\pg4mq\admin\repo
directory, and then enter the following command:
sqlplus /nolog @pgvwbrepos.sql
Note:
If you are installing the Visual Workbench repository on Oracle8i or older, then you must usepgvwbrepos8.sql
. All the examples in this section are provided with the assumption that you are installing on Oracle9i and later.The script takes you through the following steps:
Use the default value of LOCAL
by pressing Enter.Next, you are prompted to enter the passwords for the SYSTEM
and SYS
accounts of the Oracle integrating server. Press Enter after entering each password.
The script stops if any of the information is incorrect. Verify the information before rerunning the script.
The script checks for an existing Visual Workbench repository and for the data dictionary. If neither is found, then the script proceeds to Step 3.
If the data dictionary exists, then the script stops. Choose another Oracle integrating server and rerun the script, starting at "Step 1: Choose a Repository Server".
If a Visual Workbench repository exists, then the script gives you the following options:
Upgrade the existing private repository to public status and proceed to Step 3 .
Replace the existing repository with the new private repository and proceed to Step 3 .
Stop the script.
The script checks for the existence of the UTL_RAW
, DBMS_OUTPUT
, and DBMS_PIPE
packages on the Oracle integrating server. If this software exists, then the script proceeds to Step 4 .
The script stops if this software does not exist. Refer to your Oracle integrating server Database Administrator's Guide about the missing software. After the software is installed, rerun the script.
The script checks for the existence of the UTL_PG
package. If it does not exist, then the UTL_PG
package is installed. The script then proceeds to Step 5.
If UTL_PG
exists, then you are prompted to reinstall it. Press Enter to reinstall UTL_PG
.
This step creates the administrative user for the Visual Workbench repository as PGMADMIN
with the initial password of PGMADMIN
. This user owns all objects in the repository.
After this step, a private Visual Workbench repository, which includes the PGM_SUP
, PGM_BQM
, and PGM_UTL8
packages, is created in the Oracle integrating server, which only the PGMADMIN
user can access.
This is an optional step to change the private access privileges of the Visual Workbench repository. The private status enables only the PGMADMIN
user to have access to the repository. If you enter N
and press Enter, then the repository retains its private status.
A public status enables the granting of access privileges to other users besides PGMADMIN
. If you want to give the repository public status, then enter Y
and press Enter.
After creating the Visual Workbench repository, there is one optional step, granting development privileges for the Visual Workbench repository to users.
To permit users other than the PGMADMIN
user to perform development operations on the Visual Workbench repository, PGMADMIN
must grant them the necessary privileges. To do this, perform the following:
Ensure that the repository has a public status. It has public status if you create it by using Step 1 through Step 6 of the pgvwbrepos.sql
script. If you did not use Step 6, then rerun the script. When you get to Step 2 of the script, enter A
at the prompt to upgrade the private repository to public status.
Use SQL*Plus to connect to the repository as the PGMADMIN
user and grant the PGMDEV
role to each user. For example:
SQL> GRANT PGMDEV TO SCOTT;
To uninstall a Visual Workbench repository on Oracle10g, use the repository script pgvwbremove.sql
. To run this script, ensure that you are currently under the Oracle integrating server ORACLE_HOME
\pg4mq\admin\repo
directory (where you copied the scripts), and then enter the following command:
sqlplus /nolog @pgvwbremove.sql
Note:
If you are uninstalling the Visual Workbench repository on Oracle8i or earlier, then you need to usepgvwbremove8.sql
. All the examples in this section are provided with the assumption that you are installing on Oracle9i and later.The script takes you through the following steps:
Use the default value of LOCAL
by pressing Enter. Next, you are prompted to enter the passwords for the SYSTEM
, SYS
, and PGMADMIN
accounts of the Oracle integrating server. Press Enter after entering each password.
The script stops if any of the information is incorrect. Verify the information before rerunning the script.
Enter Y
and press Enter for the prompt to remove public synonyms and development roles. This returns the repository to private status. You can exit the script now by entering N
and pressing Enter, or you can proceed to the next prompt under this step.
If you are certain you want to remove the private repository, then enter Y
and press Enter. The script removes all the repository tables and related packages.
These preparations include preparing, installing, and removing PL/SQL packages on the production server.
Before you can compile MIPs on a production Oracle server, the following PL/SQL packages must be present on the production Oracle server:
DBMS_PIPE
, DBMS_OUTPUT
, and UTL_RAW
These packages are shipped with each Oracle server and are typically preinstalled.
PGM
, PGM_BQM
, PGM_SUP
, and UTL_PG
These packages are shipped with your Oracle Procedural Gateway for Message Queuing. They are installed during the creation process of the Visual Workbench repository. Do not execute deployment script on the Oracle server with an installed Visual Workbench repository. If the Oracle server used for the repository is different from the Oracle server used in the production environment, then you must install these packages on the production Oracle server.
This section describes how to run the following:
To install the necessary PL/SQL packages, perform the following actions:
Run the deployment script by entering:
$ sqlplus /nolog @pgmdeploy.sql
At the script prompt: Enter the connect string for the Oracle server... [LOCAL], press [Return] to use the default value of LOCAL
.
At the script prompt Enter the following required Oracle server password, enter the password of the SYS
account.
After the script verifies the SYS
account password, it connects to the production Oracle server. The script verifies and reports on which PL/SQL packages are installed there:
If any of the Oracle server packages DBMS_OUTPUT, DBMS_PIPE or UTL_RAW are missing, the script stops. Have your DBA install the missing packages and re-run the deployment script.
If any of the Oracle packages PGM, PGM_BQM, PGM_SUP, and UTL_PG are missing, the script installs them on the production Oracle server.
You can remove the PL/SQL packages that were installed by the pgmdeploy.sql
script if, for example, none of your applications in the production environment uses a MIP. To remove these packages, perform the following steps:
On your production Oracle server system, change to the directory containing the deployment scripts by entering the following command:
> cd ORACLE_HOME\pg4mq\admin\deploy
Run the script by entering:
> sqlplus /nolog @pgmundeploy.sql
At the script prompt: Enter the connect string for the Oracle server... [LOCAL], press [Return] to use the default of LOCAL.
At the script prompt, enter the required Oracle server passwords, enter the password of the SYS account.
After the script verifies the SYS account password, it connects to the production Oracle server and removes the packages installed by the pgmdeploy.sql
script.
After the pgmundeploy.sql
script completes successfully, applications on the production Oracle server fail if they attempt to reference any of the MIPs that are compiled there.