ODBC and Network Performance Oracle Database Tips by Donald Burleson

The Open Database Connectivity (ODBC) product was initially developed by Microsoft as a generic database driver. Its architecture has now been generalized and many different vendors are offering open database connectivity products that are based on ODBC. ODBC consists of more than 50 functions that are invoked from an application using a call-level Application Programming Interface ( API). The ODBC API does not communicate with a database directly. Instead, it serves as a link between the application and a generic interface routine. The interface routine, in turn, communicates with the database drivers via a Service Provider Interface (SPI).

ODBC has become popular with database vendors such as Oracle, and Oracle is creating new ODBC drivers that will allow ODBC to be used as a gateway into their database products. Essentially, ODBC serves as the traffic cop for all data within the client/server system. When a client requests a service from a database, ODBC receives the request and manages the connection to the target database. ODBC manages all of the database drivers, checking all of the status information
as it arrives from the database drivers.

It is noteworthy that the database drivers should be able to handle more than just SQL. Many databases have a native API that requires ODBC to map the request into a library of functions. An example would be a SQL Server driver that maps ODBC functions to database library function calls. Databases without a native API (i.e., non-SQL databases) can also be used with ODBC, but they go through a much greater transformation than the native API calls.

Database connectivity using ODBC has a high amount of overhead in many Oracle applications. The inherent flexibility of ODBC means that the connection process to Oracle is not as efficient as a native API call to the database. Most companies that experience ODBC-related performance problems will abandon ODBC and replace it with a native communications tool such as the Oracle Call Interface (OCI). In sum, ODBC is great for ad hoc database queries from MS Windows, but it is too slow for most production applications. Now let's turn our attention to Oracle replication and see how the replication parameters can affect Oracle performance.

Tuning with Oracle Replication

Oracle replication was first introduced as a method to allow Oracle tables to reside on widely separated servers. Replication was a godsend for companies that needed to have synchronized databases across the globe. Of course, it is still far faster to process a table on a local host than it is to process a remote table across the Oracle NET distributed communication lines.

Several factors influence the decision about replicating Oracle tables. The foremost considerations are the size of the replicated table and the volatility of the tables, as shown in Figure 7-2. Large, highly active tables with many updates, deletes, and inserts will require a lot of system resources to replicate and keep synchronized with the master table. Smaller, less active tables would be ideal candidates for replication, since the creation and maintenance of the replicated table would not consume a high amount of system resources.

Figure 7-37: The replication alternatives based on size and volatility

Oracle's advanced replication facility is relatively mature, and Oracle now supports multimaster replication whereby many sites can accept new rows and propagate them to the other snapshots.

From a performance perspective, we need to be concerned about how often the snapshots are refreshed. We can refresh the replicated table in full, we can re-create the snapshot at will, we can choose periodic refreshes of the snapshot, and we can use database triggers to propagate changes from a master table to the snapshot table. Although the choice of technique depends upon the individual application, some general rules apply.

Tiny Static Tables

If a replicated table is small and relatively static, it is usually easier to drop and re-create the snapshot than to use Oracle's REFRESH COMPLETE option. A crontab file can be set up to invoke the drop and re-creation at a predetermined time each day, completely refreshing the entire table.

Another popular alternative to the snapshot is using Oracle's distributed
SQL to create a replicated table directly on the slave database. In the following example, the New York database creates a local table called emp_nc, which contains New York employee information from the master employee table at corporate headquarters:

L 7-13

CREATE TABLE emp_nc
AS SELECT
   emp_nbr,
   emp_name,
   emp_phone,
   emp_hire_date
FROM
   emp@hq
WHERE
   department = 'NC';

For highly static tables that seldom change, we can also specify refreshes to run quarterly. The example here refreshes a table completely on the first Tuesday of each quarter:

L 7-14

Large Dynamic Tables

Very large replicated tables will consume too much time if you drop and recreate the snapshot, or if you use the REFRESH COMPLETE option. For static tables, a snapshot log would not contain very many changes?we could direct Oracle to propagate the changes to the replicated table at frequent intervals. Let's take a look at the different refresh intervals that can be specified for a snapshot:

L 7-15

CREATE SNAPSHOT
   cust_snap1
REFRESH FAST
    START WITH SYSDATE
    NEXT SYSDATE+7
AS
SELECT
   cust_nbr, cust_name
FROM
   customer@hq
WHERE
   department = 'NC';

Now that we have covered the parameters and techniques that affect network performance, let's look at how we can use STATSPACK to see the network activity.

 

This is an excerpt from "Oracle9i High Performance tuning with STATSPACK" by Oracle Press.