Oracle8i Distributed Database Systems Release 2 (8.1.6) A76960-01 |
|
This chapter describes considerations important when developing an application to run in a distributed database system. Oracle8i Concepts describes how Oracle eliminates much of the need to design applications specifically to work in a distributed environment.
The topics covered include:
Oracle8i Administrator's Guide for a complete discussion of implementing Oracle8i applications, and Oracle8i Application Developer's Guide - Fundamentals for more information about application development in an Oracle environment.
See Also:
In a distributed database environment, coordinate with the database administrator to determine the best location for the data. Some issues to consider are:
When a global object name is referenced in a SQL statement or remote procedure call, database links establish a connection to a session in the remote database on behalf of the local user. The remote connection and session are only created if the connection has not already been established previously for the local user session.
The connections and sessions established to remote databases persist for the duration of the local user's session, unless the application or user explicitly terminates them. Note that when you issue a SELECT statement across a database link, a transaction lock is placed on the rollback segments. To re-release the segment, you must issue a COMMIT or ROLLBACK statement.
Terminating remote connections established using database links is useful for disconnecting high cost connections that are no longer required by the application. You can terminate a remote connection and session using the ALTER SESSION command with the CLOSE DATABASE LINK parameter. For example, assume you issue the following transactions:
SELECT * FROM emp@sales; COMMIT;
The following statement terminates the session in the remote database pointed to by the SALES database link:
ALTER SESSION CLOSE DATABASE LINK sales;
To close a database link connection in your user session, you must have the ALTER SESSION system privilege.
If a part of a distributed statement fails, for example, due to an integrity constraint violation, Oracle returns error number ORA-02055
. Subsequent statements or procedure calls return error number ORA-02067
until a rollback or rollback to savepoint is issued.
Design your application to check for any returned error messages that indicate that a portion of the distributed update has failed. If you detect a failure, you should roll back the entire transaction before allowing the application to proceed.
Oracle does not permit declarative referential integrity constraints to be defined across nodes of a distributed system. In other words, a declarative referential integrity constraint on one table cannot specify a foreign key that references a primary or unique key of a remote table. Nevertheless, you can maintain parent/child table relationships across nodes using triggers.
If you decide to define referential integrity across the nodes of a distributed database using triggers, be aware that network failures can limit the accessibility of not only the parent table, but also the child table. For example, assume that the child table is in the SALES database and the parent table is in the HQ database. If the network connection between the two databases fails, some DML statements against the child table (those that insert rows into the child table or update a foreign key value in the child table) cannot proceed because the referential integrity triggers must have access to the parent table in the HQ database.
See Also:
Oracle8i Concepts for more information about using triggers to enforce referential integrity. |
The local Oracle database server breaks the distributed query into a corresponding number of remote queries, which it then sends to the remote nodes for execution. The remote nodes execute the queries and send the results back to the local node. The local node then performs any necessary post-processing and returns the results to the user or application.
You have several options for designing your application to optimize query processing. This section contains the following topics:
The most effective way of optimizing distributed queries is to access the remote databases as little as possible and to retrieve only the required data.
For example, assume you reference five remote tables from two different remote databases in a distributed query and have a complex filter (for example, WHERE r1.salary + r2.salary > 50000
). You can improve the performance of the query by rewriting the query to access the remote databases once and to apply the filter at the remote site. This rewrite causes less data to be transferred to the query execution site.
Rewriting your query to access the remote database once is achieved by using collocated inline views. The following terms need to be defined:
Oracle Corporation recommends that you form your distributed query using collocated inline views to increase the performance of your distributed query. Oracle's cost-based optimization can transparently rewrite many of your distributed queries to take advantage of the performance gains offered by collocated inline views.
In addition to rewriting your queries with collocated inline views, the cost-based optimization method optimizes distributed queries according to the gathered statistics of the referenced tables and the computations performed by the optimizer.
For example, cost-based optimization analyzes the following query. The example assumes that table statistics are available. Note that it analyzes the query inside a CREATE TABLE statement:
CREATE TABLE AS ( SELECT l.a, l.b, r1.c, r1.d, r1.e, r2.b, r2.c FROM local l, remote1 r1, remote2 r2 WHERE l.c = r.c AND r1.c = r2.c AND r.e > 300 );
and rewrites it as:
CREATE TABLE AS ( SELECT l.a, l.b, v.c, v.d, v.e FROM ( SELECT r1.c, r1.d, r1.e, r2.b, r2.c FROM remote1 r1, remote2 r2
WHERE r1.c = r2.c AND r1.e > 300 ) v, local l WHERE l.c = r1.c );
The alias v
is assigned to the inline view, which can then be referenced as a table in the above SELECT statement. Creating a collocated inline view reduces the amount of queries performed at a remote site, thereby reducing costly network traffic.
The optimizer's main task is to rewrite a distributed query to use collocated inline views. This optimization is performed in three steps:
After the query is rewritten, it is executed and the data set is returned to the user.
While cost-based optimization is performed transparently to the user, it is unable to improve the performance of several distributed query scenarios. Specifically, if your distributed query contains any of the following, cost-based optimization is not effective:
If your distributed query contains one of the above, see "Using Hints" to learn how you can modify your query and use hints to improve the performance of your distributed query.
After you have set up your system to use cost-based optimization to improve the performance of distributed queries, the operation is transparent to the user. In other words, the optimization occurs automatically when the query is issued.
You need to complete the following tasks to set up your system to take advantage of Oracle's optimizer:
To enable cost-based optimization, set the OPTIMIZER_MODE initialization parameter to CHOOSE or COST. You can persistently set this parameter by:
Issue one of the following statements to set the OPTIMIZER_MODE parameter at the session level:
ALTER SESSION OPTIMIZER_MODE = CHOOSE; ALTER SESSION OPTIMIZER_MODE = COST;
See Also:
Oracle8i Designing and Tuning for Performance manual for information on setting the |
In order for cost-based optimization to select the most efficient path for a distributed query, you must provide accurate statistics for the tables involved.
One way to generate statistics for a table is to execute an ANALYZE statement. Note that when you execute this statement, Oracle locks the tables being analyzed. For example, if you reference the EMP and DEPT tables in your distributed query, execute the following to generate the necessary statistics:
ANALYZE TABLE emp COMPUTE STATISTICS; ANALYZE TABLE dept COMPUTE STATISTICS;
The statistics are stored in the following locations:
See Also:
Oracle8i SQL Reference for additional information on using the ANALYZE statement, and Oracle8i Designing and Tuning for Performance to learn how to generate statistics for more than one object at a time and to learn how to automate the process of keeping statistics current. |
You can also collect statistics using the DBMS_ STATS package. The following procedures enable the gathering of certain classes of optimizer statistics, with possible performance improvements over the ANALYZE command:
For example, assume that distributed transactions routinely access the SCOTT.DEPT table. To ensure that the cost-based optimizer is still picking the best plan, execute the following:
BEGIN DBMS_STATS.GATHER_TABLE_STATS ('scott', 'dept'); END;
See Also:
Oracle8i Supplied PL/SQL Packages Reference for additional information on using the DBMS_STATS package. |
If a statement is not sufficiently optimized, then you can use hints to extend the capability of cost-based optimization. Specifically, if you write your own query to utilize collocated inline views, instruct the cost-based optimizer not to rewrite your distributed query.
Additionally, if you have special knowledge about the database environment (that is, statistics, load, network and CPU limitations, distributed queries, etc.), you can specify a hint to guide cost-based optimization. For example, if you have written your own optimized query using collocated inline views that are based on your knowledge of the database environment, specify the NO_MERGE hint to prevent the optimizer from rewriting your query.
This technique is especially helpful if your distributed query contains an aggregate, subquery, or complex SQL. Because this type of distributed query cannot be rewritten by the optimizer, specifying NO_MERGE causes the optimizer to skip the steps described in the "Using Hints" section.
The DRIVING_SITE hint allows you to define a remote site to act as the query execution site. This hint is especially helpful when the remote site contains the majority of the data. In this way, the query executes on the remote site, which then returns the data to the local site.
The NO_MERGE hint prevents Oracle from merging an inline view into a potentially non-collocated SQL statement (see "Using Hints"). This hint is embedded in the SELECT statement and can appear either at the beginning of the SELECT statement with the inline view as an argument or in the query block that defines the inline view.
/* with argument */ SELECT /*+NO_MERGE(v)*/ t1.x, v.avg_y FROM t1, (SELECT x, AVG(y) AS avg_y FROM t2 GROUP BY x) v, WHERE t1.x = v.x AND t1.y = 1; /* in query block */ SELECT t1.x, v.avg_y FROM t1, (SELECT /*+NO_MERGE*/ x, AVG(y) AS avg_y FROM t2 GROUP BY x) v, WHERE t1.x = v.x AND t1.y = 1;
Typically, you use this hint when you have developed an optimized query based on your knowledge of your database environment.
See Also:
Oracle8i Designing and Tuning for Performance for more information about the NO_MERGE hint. |
The DRIVING_SITE hint allows you to specify the site where the query execution is performed. It is best to let the cost-based optimization determine where the execution should be performed, but if you want to override the optimizer, you can specify the execution site manually.
Following is an example of a SELECT statement with a DRIVING_SITE hint:
SELECT /*+DRIVING_SITE(dept)*/ * FROM emp, dept@remote.com WHERE emp.deptno = dept.deptno;
See Also:
Oracle8i Designing and Tuning for Performance for more information about the DRIVING_SITE hint. |
An important aspect to tuning distributed queries is analyzing the execution plan. The feedback that you receive from your analysis is an important element to testing and verifying your database. Verification is increasingly important when you want to compare the execution plan for a distributed query optimized by cost-based optimization versus the plan for a query manually optimized using hints, collocated inline views, etc.
See Also:
Oracle8i Designing and Tuning for Performance for detailed information about execution plans, the EXPLAIN PLAN command, and how to interpret the results. |
Before you can view the execution plan for the distributed query, prepare the database to store the execution plan. You can perform this preparation by executing a script. Execute the following script to prepare your database to store an execution plan:
SQL> @utlxplan.sql
After you execute the utlxplan.sql
file, a PLAN_TABLE is created in the current schema to temporarily store the execution plan.
After you have prepared the database to store the execution plan, you are ready to view the plan for a specified query. Instead of directly executing a SQL statement, append the statement to the EXPLAIN PLAN FOR clause. For example, you can execute the following:
EXPLAIN PLAN FOR SELECT d.dname FROM dept d WHERE d.deptno IN (SELECT deptno FROM emp@orc2.world GROUP BY deptno HAVING COUNT (deptno) >3 ) /
After you have executed the above SQL statement, the execution plan is stored temporarily in the PLAN_TABLE that you created earlier. To view the results of the execution plan, execute the following script:
@utlxpls.sql
Executing the utlxpls.sql
script displays the execution plan for the SELECT statement that you specified. The results are formatted as follows:
Plan Table -------------------------------------------------------------------------------- | Operation | Name | Rows | Bytes| Cost | Pstart| Pstop | -------------------------------------------------------------------------------- | SELECT STATEMENT | | | | | | | | NESTED LOOPS | | | | | | | | VIEW | | | | | | | | REMOTE | | | | | | | | TABLE ACCESS BY INDEX RO|DEPT | | | | | | | INDEX UNIQUE SCAN |PK_DEPT | | | | | | --------------------------------------------------------------------------------
If you are manually optimizing distributed queries by writing your own collocated inline views or using hints, it is best to generate an execution plan before and after your manual optimization. With both execution plans, you can compare the effectiveness of your manual optimization and make changes as necessary to improve the performance of the distributed query.
To view the SQL statement that will be executed at the remote site, execute the following select statement:
SELECT other FROM plan_table WHERE operation = 'REMOTE';
Following is sample output:
SELECT DISTINCT "A1"."DEPTNO" FROM "EMP" "A1" GROUP BY "A1"."DEPTNO" HAVING COUNT("A1"."DEPTNO")>3
When Oracle executes a procedure locally or at a remote location, four types of exceptions can occur:
ORA-00900
and ORA-02015
.
When using local procedures, you can trap these messages by writing an exception handler such as the following:
BEGIN ... EXCEPTION WHEN ZERO_DIVIDE THEN /* ... handle the exception */ END;
Notice that the WHEN clause requires an exception name. If the exception does not have a name, for example, exceptions generated with RAISE_APPLICATION_ERROR, you can assign one using PRAGMA_EXCEPTION_INIT. For example:
DECLARE null_salary EXCEPTION; PRAGMA EXCEPTION_INIT(null_salary, -20101); BEGIN ... RAISE_APPLICATION_ERROR(-20101, 'salary is missing'); ... EXCEPTION WHEN null_salary THEN ... END;
When calling a remote procedure, exceptions can be handled by an exception handler in the local procedure. The remote procedure must return an error number to the local, calling procedure, which then handles the exception as shown in the previous example. Note that PL/SQL user-defined exceptions always return ORA-06510
to the local procedure.
Therefore, it is not possible to distinguish between two different user-defined exceptions based on the error number. All other remote exceptions can be handled in the same manner as local exceptions.
|
![]() Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|