| Oracle® Database Heterogeneous Connectivity Adminis
trator's Guide 10g Release 1 (10.1) Part Number B10764-01 |
Home Contents Index <
br>
Master Index![]() Feedback |
|
View PDF |
This chapter explains how to use Het erogeneous Services (HS) agents. It contains the following sections:
This section explains the generic steps to configure access to a n on-Oracle system.
The steps for setting up access to a non-Oracle system are:
Step 1: Configure Oracle Net Services to Access Heterogeneous Services Agents
Step 2: Create the Da tabase Link to the Non-Oracle System
To initiate a connection to the non-Oracle system, the Oracle server starts an agent process through the Oracle Net listen er. For the Oracle server to be able to connect to the agent, you must:
(HS=OK) clause to ensure the connection uses Oracle Heterogeneous Services. The description of this service n
ame is defined in tnsnames.ora, the Oracle Names server, or in third-party name servers using the Oracle naming adapter.
The following is a sample entry for service name in the tnsnames.ora file
:
Sybase_sales= (DESCRIPTION= (ADDRESS=( PROTOCOL=tcp) (HOST=dlsun206) (PORT=1521) ) (CONNECT_DATA = (SERVICE_NAME=SalesDB) ) (HS = OK) )
The following is a sample entry for the lis
tener in listener.ora:
LISTENER = (ADDRESS_LI ST = (ADDRESS= (PROTOCOL=tcp) (HOST = dlsun206) (PORT = 1521) ) ) ... SID_LIST_LISTENER = (SID_LIST = (SID_D ESC = (SID_NAME=SalesDB) (ORACLE_HOME=/home/oracle/megabase/9.0.1) (PROGRAM=tg4mb80) (ENVS=LD_LIBRARY_PATH=non_orac le_system_lib_directory) ) )
The value associated with the PROGRAM keyword defines the name of the agent executable. T
he full path of the directory which contains the DLL that is loaded by the Heterogeneous Services agent is specified by LD_LIBR
ARY_PATH. Typically, you use SID_NAME to define the initialization parameter file for the agent.
| See Also:
|
To create a database link to the non-Oracle system, use the CREATE DATABASE LINK stat
ement. The service name that is used in the USING clause of the CREATE DATABASE LINK statement is the Oracl
e Net service name.
Use quotes with the username and password to avoid differences in case- sensitive behavior between Oracle and non-Oracle databases. For example, enter a statement like the following:
CREATE DATABASE LINK sales CONNECT TO "sales1" IDENTIFIED BY "Sales1" USING 'Sybase_sales';
T
o test the connection to the non-Oracle system, use the database link in a SQL or PL/SQL statement. If the non-Oracle system is a SQL
-based database, you can execute a SELECT statement from an existing table or view using the database link. For example:
SELECT * FROM product@sales WHERE product_name like '%pencil%';
When you try to access the non-Oracle system for the first time, the Heterogeneous Services agent uploads information into the Heterogeneous Services data dictionary. The uploaded information includes:
| See Also:
Heter ogeneous Services Data Dictionary Views and Appendix C, "Data Dicti onary Translation Support" |
As mentioned in "Configuring Heterogeneous Services", y ou can configure the gateway using initialization parameters. This is done by creating an initialization file and setting the desired parameters in this file
Heterogeneous Services initialization parameters are distinct from
Oracle database server initialization parameters. Heterogeneous Services initialization parameters are set in the Heterogeneous Serv
ices initialization file and not in the Oracle database server initialization parameter file (init.ora file). There is a
Heterogeneous Services initialization file for each gateway instance.
The name of the file is initsid
em>.ora, where sid is the Oracle system identifier used for the gateway.
In the case of Generic Connectivity, the Heterogeneous Services initialization file is located in the directory $ORACLE_HOME/product_name/
admin where product_name is the name of the product. So, the Sybase gateway initialization file is loc
ated in the directory $ORACLE_HOME/tg4sybs/admin.
The initialization file contains a list of initialization parameter settings each of which should be o n a separate line. The syntax to set an initialization parameter is:
[set] [private] parameter = parameter_value
The set and private keywords are optional. If the set keyword is present then the variable will also be set in the environment. If the private keyword is present, the parameter will not be uploaded to the server. In general, it recommended that this keyword not be used - unless the initialization parameter value contains sensitive information (like a password) that should not be sent over th e network from gateway to Oracle server.
In the initialization parameter syntax, all keywor
ds (SET, PRIVATE and IFILE) are case insensitive. Initialization parameter names and values ar
e case sensitive. Most initialization parameters names are uppercase. String values for Heterogeneous Services parameters must be low
ercase. Exceptions to this rule are explicitly noted.
Another initialization file can be in
cluded in an Heterogeneous Services initialization file by using the IFILE directive. The syntax for this is:
IFILE = path name for file to be included
Gateway initialization parameters can be divided into two groups. One is a set of generic initialization parameters that are common to all gateways and the other is a set of initialization parameters that ar e specific to individual gateways. The following list of generic initialization parameters are the only ones discussed in this docume nt:
HS_CALL_NAMEHS_DB_DOMAINHS_DB_INTERNAL_NAMEHS_DB_NAMEHS_DESCRIBE_CACHE_HWMHS_FDS_CONNECT_INFOHS_FDS_DEFAULT_SCHEMA_NAMEHS_FDS_TRACE_LEVELHS_LANGUAGEHS_LONG_PIECE_TRANSFER_SIZEHS_NLS_DATE_FORMATHS_NLS_DATE_LANGU
AGEHS_NLS_NCHARHS_N
LS_NUMERIC_CHARACTERSHS_NLS_TIMESTAMP_FORMATHS_NLS_TIMESTAMP_TZ_FORMATHS_OPEN_CURSORS
HS_ROWID_CACHE_SIZEHS_RPC_FET
CH_REBLOCKINGHS_RPC_FETCH_SIZEHS_TIME_ZONEDo not use
the PRIVATE keyword when setting any of these parameters. Doing that would prevent the parameter from being uploaded to
the server and could cause errors in SQL processing. None of these parameters are required to be set in the environment, so the
See Also:
|
When an application fetches data from a non-Oracle system using Heterogeneous Services, d ata is transferred:
Oracle optimizes all three data transfers, as illustrated in Figure 4-1.
Text description of the illustration heter009.gif
This section contains the following topics:
You can optimize data transfers betw een your application and the Oracle server by using array fetches. See your application development tool documentation for informatio n about array fetching and how to specify the amount of data to be sent or each network round trip.
When Oracle retrieves data from a non-Ora
cle system, the Heterogeneous Services initialization parameter HS_RPC_FETCH_SIZE defines the number of bytes sent for e
ach fetch between the agent and the Oracle server. The agent fetches data from the non-Oracle system until one of the following occur
s:
The initialization parameter HS_FDS_FETCH_ROWS determines the number of rows to be retrieved from a n
on-Oracle system. Note that the array fetch must be supported by the agent. See your agent-specific documentation to ensure that your
agent supports array fetching.
B
y default, an agent fetches data from the non-Oracle system until it has enough data retrieved to send back to the server. That is, i
t keeps going until the number of bytes fetched from the non-Oracle system is equal to or higher than the value of HS_RPC_FETCH
_SIZE. In other words, the agent reblocks the data between the agent and the Oracle database server in
sizes defined by the value of HS_RPC_FETCH_SIZE.
When the non-Oracle system s
upports array fetches, you can immediately send the data fetched from the non-Oracle system by the array fetch to the Oracle database
server without waiting until the exact value of HS_RPC_FETCH_SIZE is reached. That is, you can stream the data from the
non-Oracle system to the Oracle database server and disable reblocking by setting the value of initialization parameter HS_RPC
_FETCH_REBLOCKING to OFF.
For example, assume that you set HS_RPC
_FETCH_SIZE to 64 kilobytes (KB) and HS_FDS_FETCH_ROWS to 100 rows. Assume that each row is approximately 600 byt
es in size, so that the 100 rows are approximately 60 KB. When HS_RPC_FETCH_REBLOCKING is set to ON, the ag
ent starts fetching 100 rows from the non-Oracle system.
Because there is only 60 KB of dat a in the agent, the agent does not send the data back to the Oracle database server. Instead, the agent fetches the next 100 rows fro m the non-Oracle system. Because there is now 120 KB of data in the agent, the first 64 KB can be sent back to the Oracle database se rver.
Now there is 56 KB of data left in the agent. The agent fetches another 100 rows from
the non-Oracle system before sending the next 64 KB of data to the Oracle database server. By setting the initialization parameter <
code>HS_RPC_FETCH_REBLOCKING to OFF, the first 100 rows are immediately sent back to the Oracle server.
Registration is an operation through which Oracle stores information about an agent in the data dictionary. Agents do not have to be registered. If an agent is not regist ered, Oracle stores information about the agent in memory instead of in the data dictionary; when a session involving an agent termin ates, this information ceases to be available.
Self-registration is an operation in which a database administrator sets an initialization parameter that lets the agent automatically upload infor
mation into the data dictionary. In release 8.0 of the Oracle database server, an agent could determine whether to self-register. In
Oracle9i and later, self-registration occurs only when the HS_AUTOREGISTER initialization parame
ter is set to TRUE (default).
This section contains the following topics:< /p>
To ensure correct operation over heterogeneous
database links, agent self-registration automates updates to Heterogeneous Services configuration data that describe agents on remote
hosts. Agent self-registration is the default behavior. If you do not want to use the agent self-registration feature, then set the
initialization parameter HS_AUTOREGISTER to FALSE.
Both the serve r and the agent rely on three types of information to configure and control operation of the Heterogeneous Services connection. These three sets of information are collectively called HS configuration data:
< table summary="" class="RuleInformal" border="1" width="100%" cellpadding="3" cellspacing="0" dir="ltr" title="">Heterogeneous Services init ialization parameters
Provide control over various connection-spe cific details of operation.
Capability definitions
Identify details like SQL language features supported by the non-Oracle data source.
Data dictionary translations
Map references to Oracle data dictionary tables and views into equivalents specific to the non-Oracle data source.
HS configuration data is stored in the Oracle database server's data dictionary. Because the agent is possibly remo te, and may therefore be administered separately, several circumstances can lead to configuration mismatches between servers and agen ts:
Agent self-registration permits successful operation of Heterogeneous Services in all these scenarios. Specifically, agent self-registration enhances interoperability between any Oracle database server and any Heterogeneous Services ag ent, if each is at least as recent as Version 8.0.3. The basic mechanism for this functionality is the ability to upload HS configura tion data from agents to servers.
Self-registration provides automatic updating of HS confi guration data residing in the Oracle database server data dictionary. This update ensures that the agent self-registration uploads ne ed to be done only once, on the initial use of a previously unregistered agent. Instance information is uploaded on each connection, not stored in the server data dictionary.
The Heterogeneous Services agent self-registration feature can:
The information required for agent self-registration is accessed in the server data d ictionary by using these agent-supplied names:
FDS_CLASS
FDS_CLASS_VERSION
|
See Also:
"Heterogeneous Services Data Dictionary Views" to learn how to use the Hetero geneous Services data dictionary views |
FDS_CLASS and FDS_CLASS_VERSION are defined by Oracle or by third-party vendors
for each individual Heterogeneous Services agent and version. Oracle Heterogeneous Services concatenates these names to form F
DS_CLASS_NAME, which is used as a primary key to access class information in the server data dictionary.
FDS_CLASS should specify the type of non-Oracle data store to be accessed and FDS_CLASS_VERSI
ON should specify a version number for both the non-Oracle data store and the agent that connects to it. Note that when any co
mponent of an agent changes, FDS_CLASS_VERSION must also change to uniquely identify the new release.
Instance-specific information can be stored in the server data dictiona
ry. The instance name, FDS_INST_NAME, is configured by the DBA who administers the agent; how the DBA performs this conf
iguration depends on the specific agent in use.
The Oracle database server uses FDS_I
NST_NAME to look up instance-specific configuration information in its data dictionary. Oracle uses the value as a primary key
for columns of the same name in these views:
Server data dictionary accesses that use FDS_CLASS_NAME to uniquely identify configuration information rows. For example, if you
port a database from class Sybase8.1.6 to class Sybase8.1.7, both databases can simultaneously operate with instance name SCOTT
and use separate sets of configuration information.
Unlike class information, insta nce information is not automatically self-registered in the server data dictionary.
The Oracle database server initial
ization parameter HS_AUTOREGISTER enables or disables automatic self-registration of Heterogeneous Services agents. Note
that this parameter is specified in the Oracle initialization parameter file, not the agent initialization file. For example, you ca
n set the parameter as follows:
HS_AUTOREGISTER = TRUE
When set to TRUE, the agent uploads information describing a previously unknown agent cl
ass or a new agent version into the server's data dictionary.
Oracle recommends that you us
e the default value for this parameter (TRUE), which ensures that the server's data dictionary content always correctly
represents definitions of class capabilities and data dictionary translations as used in Heterogeneous Services connections.
| See Also:
Oracle Database Reference for a description of this parameter |
To disable agent self-registration, set the HS_AUTOREGISTER initialization parameter as follows:<
/p>
HS_AUTOREGISTER = FALSE
Disabling agent self-registration entails that agent information is not stored in the data dictionary. Consequently, the Heterogeneo us Services data dictionary views are not useful sources of information. Nevertheless, the Oracle server still requires information a bout the class and instance of each agent. If agent self-registration is disabled, the server stores this information in local memory .
The gateway rewrites SQL st atements when the statements need to be translated or post-processed.
For example, consider a program that requests the following from the non-Oracle database:
SELECT "COL_A" FROM "t est"@remote_db WHERE "COL_A" = INITCAP('jones');
The non-Oracle database does not recognize INITCAP, so the Oracle database server does a table scan of t
est and filters the results locally. The gateway rewrites the SELECT statement as follows:
SELECT "COL_A" FROM "test"@remote_db;
The res ults of the query are sent to the gateway and are filtered by the Oracle database server.
C
onsider the following UPDATE request:
UPDATE "test"@remote_db WHERE "COL_A" = INITCAP('jones');
In this case, the Oracle database server and th e gateway cannot compensate for the lack of support at the non-Oracle side, so an error is issued.
If you are performing operations on large amounts of data stored in the non-Oracle database, keep in mind that some functions require data to be moved to the integrating Oracle database server before processing can occur.
You can execute user-defined functions in a remote non- Oracle database. For example:
SELECT getdeptforemp@Remote_DB(7782) FROM dual;
In this example, the user issues a SELECT
statement that executes a user-defined function in the remote database that returns department information for employee 7782.
When the remote function resides in an Oracle database, then the Oracle database automatically ens ures that the remote function does not update any database state (such as updating rows in a database or updating the PL/SQL package state). The gateway cannot verify this when the remote function resides in a non-Oracle database. Therefore, the user is responsible for ensuring that the user-defined functions do not update the state in any database. Ensuring no updates to the database is required to guarantee read consistency.
As a security measure, you must specify the functions that
you want to execute remotely and their owners in the HS_CALL_NAME parameter in the gateway-specific initialization param
eter file. For example:
HS_CALL_NAME = "owner1.A1, owner2.A2, "
owner1andowner2are the remote function owner names.A1 andA2are the remote function names. You do not need to specify the remote function owner in the SQL statement. By default, the remote function needs to reside in the schema that the Transparent Gateway connects to. If this is not the case, then y ou must specify the owner of the remote function in the SQL statement.Some other examples of executing user-defined remote functions are: as follows:
The function uses the employee_id column dat
a to retrieve the department_id from the EMPLOYEES table in the remote database. The outer query then deter
mines all department numbers in the remote database that match the returned list.
SELEC T * FROM departments@remotedb WHERE department_id IN (SELECT getdeptforemp@remotedb(employee_id) FROM employees@remotedb); < /a>
This query returns the maximum salary of all employees on the remote database.< /p>
SELECT max(getsalforemp@remotedb(employee_id)) FROM employe es@remotedb;
The statement uses the output from a user-defined query in the remote database to update the salary colu mn with new salary information.
UPDATE employee_history SET salary = emp_changed_salary@remote_db;
In these exampl es, the Oracle database passes the function name and owner to the Transparent Gateway. The user-defined function is executed on the r emote database.
| See Also: font> |
| See Also:<
/font>
Orac le Database Administrator's Guide for information about synonyms |
The following statement joins data between the Oracle database server, an I BM DB2 database, and a Sybase database:
SELECT O.CUSTNAME, P.PROJNO, E.ENAME, SUM(E.RATE*P. "HOURS") FROM ORDERS@DB2 O, EMP@ORACLE9 E, "PROJECTS"@SYBS P WHERE O.PROJNO = P."PROJNO" AND P."EMPNO" = E.EMPNO GROUP BY O.CUSTNAME, P."PROJNO", E .ENAME;
Through a combination of views and synonyms, using the following SQL statements, the process of distributed queries is transparent to the user:
CREATE SYNONYM ORDERS FOR O RDERS@DB2; CREATE SYNONYM PROJECTS FOR "PROJECTS"@SYBS; CREATE VIEW DETAILS (CUSTNAME,PRO JNO,ENAME,SPEND) AS SELECT O.CUSTNAME, P."PROJNO", E.ENAME, SUM(E.RATE*P."HO URS") SPEND FROM ORDERS O, EMP E, PROJECTS P WHER E O.PROJNO = P."PROJNO" AND P."EMPNO" = E.EMPNO GROUP BY O.CUSTNAME, P."PROJN O", E.ENAME;
Use the following SQL statement to retrieve informat ion from the data stores in one statement:
SELECT * FROM DETAILS; pre>The statement retrieves the following table:
CUS TNAME PROJNO ENAME SPEND -------- ------ ----- ----- ABC Co. 1 Jones 400 ABC Co. 1 Smith 180 XYZ Inc. 2 Jones 400 XYZ Inc. 2 Smith 180
Copying Data from the Oracle Database Server to the Non-Oracle Database System In Oracle9i, release 2 and later, Heterogen eous Services supports callback links. This enables SQL statements like the following to be executed:
INSERT INTO table_name@dblink SELECT column_list FROM table_name; a>Even though Heterogeneous Services supports the callback functionality, not all gatew ays have implemented it. If the gateway that you are using has not implemented this functionality, then the preceding
INSERT statement returns the following error message:ORA-02025: All tables in the SQL statem ent must be at the remote databaseFor gateways that do not support callback links, you can u se the SQL*Plus
COPYcommand. The syntax is as follows:COPY FROM username /password@db_name - INSERT destination_table - USING query; em>The following example selects all rows from the local Oracle
emptable, inserts them into theemptable on the non-Oracle database, and commits the transaction:COPY FROM SCOTT/TIGER@inst1 - INSERT EMP@remote_db - USING SELECT * FROM EMP;The
COPYcommand supportsAPPEND,CREATE,INSERT, andREPLACEoptions. However,INSERTis the only option supported when copying to non-Oracle. The SQL*PlusCOPYcommand does not support copying to tables with lowercase table names. Us e the following PL/SQL syntax with lowercase table names:DECLARE v1 oracle_table.column1%TYPE; v2 oracle_table.column2%TYPE; v3 oracle_table.column3 %TYPE; . . . CURSOR cursor_name IS SELECT * FROM oracle_table; BEGIN OPEN cursor_name; LOOP FETCH cursor_name INTO v1, v2, v3, ... ; < /a> EXIT WHEN cursor_name%NOTFOUND; INSERT INTO destina tion_table VALUES (v1, v2, v3, ...); < /a> END LOOP; CLOSE cursor_name; EN D; /< /div>
See Al so: SQL*Plus User's Guide and Reference for more information about the
COPYcommandCopying Data from the Non-Oracle Database System to the Oracle Database Server
The
CREATE TABLEstatement lets you copy data from a non-Oracle database to the Oracle database server. To create a table on the local database and insert rows from the non-Oracle table, use the following syntax:CREATE TABLE table_name AS query;The following example creates the table
empin the local Oracle database and inserts the rows fro m theEMPtable of the non-Oracle database:CREATE TABLE table1 AS SELECT * FR OM "EMP"@remote_db;Alternatively, you can use the SQL*Plus
COPYcommand to copy data from the non-Oracle database to the Oracle database server.
See Also: SQL*Plus User's Guide and Reference for more inform ation about the
COPYcommand< font face="Arial, Helvetica, sans-serif" color="#330099">Heterogeneous Services Data Dictionary Views
You can use the Heterogeneous Services data dictionary views to access information about Heterogene ous Services. This section addresses the following topics:
- Understanding the Types of Views
- Understanding the Sources of Data Dictionary Information
- Using the General Views
- Using the Transaction Service Views
- Using the SQL Service Views
Understanding the Types of Views
The Heterogeneo us Services data dictionary views, which all begin with the prefix
HS_, can be divided into four main types:Most of the data dictionary views are defined for both classes and instances. Consequently, for m ost types of data there is a
*_CLASSand an*_INSTview.Table 4-1 Data Dictionary Views for Hete rogeneous Services
Like all Oracle data dictionary tables, these views are read-only. Do not change the content of any of the underlying tables.
Understanding the Sources of Data Dictionary Information
The values used for data dictionary content in any particular connection on a Heterogeneous Services database link can come from any of the following sources, in order of precedence:
- In stance information uploaded by the connected Heterogeneous Services agent at the start of the session. This information overrides cor responding content in the Oracle data dictionary, but is never stored into the Oracle data dictionary.
- Instance information stored in the Oracle data dictionary. This data overrides any corresponding content for the connected class.
- Class information stored in the Oracle data dictionary.< /li>
If the Oracle database server runs with the
HS_AUTOREGISTERserver initi alization parameter set toFALSE, then no information is stored automatically in the Oracle data dictionary. The equival ent data is uploaded by the Heterogeneous Services agent on a connection-specific basis each time a connection is made, with any inst ance-specific information taking precedence over class information.You can determine the values of Heterogene ous Services initialization parameters by querying the
VALUEcolumn of theV$HS_PARAMETERview. Note that t heVALUEcolumn ofV$HS_PARAMETERtruncates the actual initialization parameter value from a maximum of 255 characters to a maximum of 64 characters, and it truncates the parameter name from a maximum of 64 characters to a maximum of 30 cha racters.Using the General Views
The views that are common for all services a re as follows:
View Contains
HS_FDS_INSTNames of the instances and classes that are uploaded into the Oracle data dictionary
table>
HS_CLASS_INITInformation about the Heterogeneous Services initialization parameters
For example, you can access multiple Sybase gateways from an Oracle database server. Aft er accessing the gateways for the first time, the information uploaded into the Oracle database server could appear as follows:
< pre class="CE">SQL> SELECT * FROM hs_fds_class; FDS_CLASS_NAME FDS_CLASS_COMMENTS FDS_CLASS_ID --------------------- ------------------------------ ------ ------ Sybase816 Uses Sybase driver, R1.1 1 Sybase817 Uses Sybase driver, R1.2 21Two classes are u ploaded: a class that accesses Sybase816 and a class that accesses Sybase817. The data dictionary in the Oracle database server now c ontains capability information, SQL translations, and data dictionary translations for both Sybase816 and Sybase817.
In addition to this information, the Oracle database server data dictionary also contains instance informat ion in the
HS_FDS_INSTview for each non-Oracle system instance that is accessed.Using the Transaction Service Views
When a non-Oracle system is involved in a distributed transaction, the transact ion capabilities of the non-Oracle system and the agent control whether it can participate in distributed transactions. Transaction c apabilities are stored in the
HS_CLASS_CAPStables.The ability of the non-Ora cle system and agent to support two-phase commit protocols is specified by the 2PC type capability, which can specify one of the foll owing five types:
The transaction model supported by the driver and non-Oracle system can be queried from Heterogeneous Services' data dictionary view
HS_CLASS_CAPS. One of the capabilities is of the 2PC type:
SELECT cap_description, translation FROM hs_class_caps WHERE cap_de scription LIKE '2PC%' AND fds_class_name LIKE 'SYBASE%'; CAP_DE SCRIPTION TRANSLATION ---------------------------------------- ----------- 2PC type (RO-SS-CC-PREP/2P-2PCC) CCW hen the non-Oracle system and agent support distributed transactions, the non-Oracle system is treated like any other Oracle server. When a failure occurs during the two-phase commit protocol, the transaction is recovered automatically. If the failure persists, the in-doubt transaction may need to be manually overridden by the database administrator.
Using the SQL Service Views
Data dictionary views that are specific for the SQL service contain information about:
- SQL capabilities and SQL translations of the non-Oracle data source
- Data dictionary translations to map Oracle data dictionary views to the data dic tionary of the non-Oracle system
Using Views for Capabilities and Translations
The
HS_*_CAPSdata dictionary tables contain information about the SQL capabilities of the non-Oracle data source and r equired SQL translations. These views specify whether the non-Oracle data store or the Oracle database server implements certain SQL language features. If a capability is turned off, then Oracle does not send any SQL statements to the non-Oracle data source that req uire this particular capability, but it still performs post-processing.Using Views for Data Dictionary Translations
Using the Heterogeneous Services Dynamic Performance Views
Deter mining Which Agents Are Running on a Host
The following view shows g eneration information about agents:
View Purpose
V$HS_AGENT Identifies the set of Heterogeneous Services agents currently running on a given host, using one row for each agent process.
Use this view to determine general information about the agents running on a specified host. The following table show s the most relevant columns (for a description of all the columns in the view, see Oracle Database Reference):
Table 4-2 V$HS_AGENT
< strong>Column Description
AGENT_IDOracle Net session identifier used for connections to agent (
listener.ora SID)
MACHINEOperating system machine name
PROGRAMProgram name of agent
a>
AGENT_TYPEType of agent
FDS_CLASS_IDp>The ID of the foreign data store class
FDS_INST_IDThe instance name of the foreign data store
Determining the Open Heter ogeneous Services Sessions
The following view shows which Heterogene ous Services sessions are open for the Oracle database server:
View Purpose
V$HS_SESSIONLists the sessi ons for each agent, specifying the database link used.
The follow ing table shows the most relevant columns (for an account of all the columns in the view, see Oracle Database Reference):
Table 4-3 V$HS_SESSION
Determining the Heterogeneous Services Parameters
The following view shows which Heterogeneous Services parameters are se t in the Oracle database server:
View Purpose tr>
V$HS_PARAMETERLists Heterogeneous Services parameters and values registered in the Oracle database server.
The following t able shows the most relevant columns (for an account of all the columns in the view, see Oracle Database Reference):
Table 4-4 V$HS_SESSION
Column Description
HS_SESSION_IDUnique Heterogeneous Services session identifier
PARAMETERThe name of the Heterogeneous Services parameter
VALUEThe value of the Heterogeneous Services parameter
Information ab out the database link that was used for establishing the distributed connection, the startup time, and the set of initialization para meters used for the session is also available.
All of the runtime information is derived fr om dynamically updated tables. The Distributed Access Manager has a refresh capability available through the menu and toolbar that al lows users to rerun queries if necessary and update the data. When the data is refreshed, the tool verifies that the set of registere d agents remains the same. If it is not, the global view is updated.
See Also: Oracle Enterprise Manager Administrator's Guide and online help for more info rmation about the Distributed Access Manager