Oracle client libraries: Why they are important for your business
"Why should I use an Oracle ODBC driver that uses the Oracle client libraries, when I have seen other drivers on the Web that connect directly to Oracle and whose vendors claim are faster, easier to deploy and administer, and so on?"
This is an interesting question, and according to the claims made by some vendors, it would seem that using the Oracle client libraries provide no benefits. As is often the case with database access though, it is important to look past the marketing and consider the actual technologies in use. You need to understand the implications of not using the client libraries for your business's current and future access to your Oracle server.
This diagram compares a client-based ODBC driver architecture with a non client-based one:
Background: Why Oracle developed the client libraries
Those of you who were in the IT industry before the rise of the Internet, will remember the chaos that was networking, and how the solution to that chaos was the production of layered protocol stacks. Each layer in that stack had a well-defined and clean set of tasks and responsibilities and a well defined and understood interface to the layer above. One very popular example of this was the OSI 7 layer model. The lowest layer (Physical) talks to the network interface, the next layer (Data Link) uses the Physical layer and provides error correction, flow control, and synchronisation. Above that, the next layer (Network) provides switching and routing and so on up the layers. One of the reasons this layered approach works so well is that each layer has a clearly defined set of tasks, and only needs to concern itself with those tasks. The other powerful advantage of this model is that one layer can be replaced without altering the others, so, for example, if token ring networking is used instead of ethernet, only the Physical and perhaps Data Link layers are affected. This provides the stability and reliability that is required for any network application.
The relevance of this digression into networking history is that the set of problems the OSI model was designed to solve are just as valid today as they were in the past. It is just the same set of problems that the Oracle engineers set out to solve with the design of the Oracle client libraries and the layers beneath. The entire Oracle network model is built on the idea of nested protocol layers, each with a clear task and clean interface. At the top is the Oracle Call Interface (OCI). Moving down the layers, we eventually get to the equivalent of the physical layer, which may be part of the client operating system. This provides the actual interface to the physical network hardware.
By ignoring all this and suggesting that the application (in this case an ODBC driver) should provide all the code down to the lowest layer, is to ignore the hard learned lessons of the last thirty years of enterprise computing.
A perfect example of the power of the layered client interface is the Advanced Security enhancements provided by Oracle. As you will be aware, your business depends on the data that flows to and from your Oracle server. If the information contained in that data flow was compromised, it could mean the end of your company's operation. Because of this, Oracle have provided additional encryption, authentication, and validation options for their servers. To access these features, no software change is required on the client if the Oracle client libraries are in use. Because the Easysoft Oracle ODBC driver makes use of the client libraries, these features are automatically available to your ODBC applications. This is not the case with the so called "wire protocol" driver, which does not use the client libraries.
We will now look in more detail at some of the claims that other vendors make in relation to their client-less driver architecture.
Improved performance and scalability
The first assumption behind this claim is that the additional layers of the protocol stack add unnecessary additional processing. The second assumption is that Oracle have not made their implementation of their protocol talking to their database the best it can possibly be. Oracle's core business (and yours) relies on the performance of those client libraries as they are Oracle's only supported way for applications to interface with their database. Claims from ODBC vendors that imply they can do better than the database vendors should be considered with care.
To investigate this point, Easysoft took one of the client-less driver vendor's products, and using code that the driver vendor provides as evidence of superior performance, compared this product's results with the results for our own driver. We did this on the same machine, connecting to the same database.
The tests measure the fetch performance of each driver for commonly used data types. All test results are based on fetching 1000000 rows. The "All" test retrieves data from each column in the test table. The "Cursor" variant of this test fetches this data by executing a stored procedure that uses a REF CURSOR.
Ease of deployment and administration
It is true that with a client-less ODBC driver, you do not have to install the client. However, this assumes that there are no gains from using the client, and the only consideration is the time taken to install the client. It is true that for earlier versions of Oracle, installing the client components was a lengthy process. However, Oracle were aware that this was the case. That is why, since the introduction of Oracle 10g, there are small, lightweight, client-only installs — what Oracle call their "Instant Client." The choice of name in itself shows that Oracle is aware of the problem these new client installs solve. However, even though the client install is smaller, they still provide a full installation of the Oracle networking stack and give you exactly the same power and flexibility as previous or full Oracle installations.
As to the claim about ease of administration, another way of saying this is "You do not have to know how to administer Oracle to use the client-less ODBC driver." This may be true, but to allow the Oracle database to provide the maximum power and functionality involves understanding how it works and how to get the best out of it. Your investment in training your database administrator and staff is immediately apparent when setting up our ODBC driver. Because it uses the Oracle client, there are no new skills to learn and no unfamiliar files to edit when configuring the connection.
Latest functionality
The functionality of the ODBC driver is not dependent on the method used to connect to the data. If the database provides a feature, a client can make use of this. The way that an ODBC driver connects to the database cannot affect the features the database provides. The reality is that less features are provided by wire protocol drivers because they do not support the features that require the client software. For example, the Oracle Advanced Security features.
Reliability
Oracle databases are reliable. If this was not the case, you would not have chosen Oracle to safeguard your corporate data. You can therefore be confident that Oracle apply the same level of software quality to their client interface libraries. After all, without those client libraries, their database will do nothing. The client libraries are the "customer facing" part of Oracle, and Oracle is fully aware of the importance of great customer relations.
Database vendors are not interested in ODBC access, they only focus their attention on the database
Oracle's area of expertise is the database, but as discussed already, the database includes the client libraries. It is misleading to suggest that it is possible to separate the two. Our area of expertise is in writing ODBC drivers and middleware. We know our drivers will work with the Oracle client libraries now, and we are confident that they will continue to work in the same way in the future.
