Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








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

   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

    NEXT NEXT_DAY(ADD_MONTHS(trunc(sysdate,'Q'),3),'TUESDAY')
   cust_nbr, cust_name
   department = 'NC';

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

   cust_nbr, cust_name
   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.

If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.