Load any data into Oracle in just a few clicks. Plus there is no need to create any scripts or learn command line tools just point and click.

Learn how you can do it now:

There are several ways of loading data into the Oracle database

  • Conventional path load
  • Direct path load
  • Using Oracle ODBC Driver
  • Using Ole DB

Conventional path load

A conventional path load executes SQL INSERT statements to populate tables in an Oracle database.

When Advanced ETL Processor or Visual Importer performs a conventional path load, it competes equally with all other processes for buffer resources, which can significantly slow the load.

Let's consider loading data into the customer's table using conventional path loading.

Some of the data is already inserted and there are duplicates in our source data.  

insert into customers

 What would happen if the primary key is violated? 

If we run all our inserts within one transaction we won't be able to load any data

  • lots of inserts
  • commit

or we can insert one record at the time committing after every insert 

  • insert one record
  • commit
  • insert one record
  • commit
  • ETC

This approach allows us to load as much as we can, however, there is a problem with that it is slow because it involves a lot of OCI calls and consumes a lot of server resources.

We use a slightly different approach at DB Software Laboratory.

We build an array of records in memory then insert the entire array in one go.

  • insert 100 records
  • commit
  • insert 100 records
  • commit
  • insert 100 records
  • commit

if the insert fails OCI lets us know that record number 52 within the array violates primary key.

  • our insert is rolled back
  • insert records from 1 till 51
  • commit
  • insert records from 53 till 100
  • commit

If the second insert failed we attempt to insert records one by one

  • our insert is rolled back
  • insert record 53
  • commit
  • insert record 54
  • commit
  • ...
  • Insert record 100
  • commit

Once we inserted 100 records one by one, we build an array and try to insert the entire array again

Direct path load

A direct path load eliminates much of the database overhead by formatting Oracle data blocks and writing the data blocks directly to the database files. It does not compete with other users for database resources, so it can usually load data at near disk speed.

There are several restrictions to using direct path load

During a direct path load

  • CHECK constraints,
  • Referential constraints (FOREIGN KEYS),
  • Insert triggers

are automatically disabled


  • PRIMARY KEY (unique-constraints on not-null columns)



NOT NULL constraints are checked at column array build time.
Any row that violates the NOT NULL constraint is rejected.
UNIQUE constraints are verified when indexes are rebuilt at the end of the load.
The index will be left in an Index Unusable state if a violation of a UNIQUE constraint is detected.


(Pronounced as separate letters) Short for Open DataBase Connectivity, a standard database access method developed by the SQL Access group in 1992. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant -- that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them

The current Oracle ODBC driver conforms to the ODBC 3.52 specifications and certified against MDAC 2.8 (Microsoft Data Access Components) on Windows 32bit and 64bit platforms. It supports all core APIs and a subset of Level 1 and Level 2 functions. Microsoft supplies the Driver Manager components for the Windows Platform. The Oracle ODBC Driver is also available as part of the Oracle Instant Client installation and can be found at

All our ETL Tools provide full support ODBC including ODBC connection strings.
In case of loading data into Oracle, it works slower than Conventional path load and Direct path load.


OLE DB (or Object Linking and Embedding, Database) is an API designed by Microsoft for accessing data from a variety of sources in a uniform manner. It is a set of interfaces implemented using the Component Object Model (COM); it is otherwise unrelated to OLE. It was designed as a higher-level replacement for, and successor to, ODBC, extending its feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL.

OLE DB separates the datastore from the application that needs access to it through a set of abstractions that include the data source, session, command and rowsets. This was done because different applications need access to different types and sources of data and do not necessarily want to know how to access functionality with technology-specific methods. OLE DB is conceptually divided into consumers and providers. The consumers are the applications that need access to the data, and the provider is the software component that implements the interface and therefore provides the data to the consumer. OLE DB is part of the Microsoft Data Access Components (MDAC) stack. MDAC is a group of Microsoft technologies that interact together as a framework that allows programmers a uniform and comprehensive way of developing applications for accessing almost any data store. OLE DB providers can be created to access such simple data stores as a text file and spreadsheet, through to such complex databases as Oracle, MS SQL Server and Sybase ASE. It can also provide access to hierarchical datastores such as email systems.

However, because different datastore technologies can have different capabilities, OLE DB providers may not implement every possible interface available to OLE DB. The capabilities that are available are implemented through the use of COM objects - an OLE DB provider will map the data store technologies functionality to a particular COM interface. Microsoft describes the availability of an interface as "provider-specific," as it may not be applicable depending on the database technology involved. Note also that providers may augment the capabilities of a data store - these capabilities are known as services in Microsoft parlance.

All our ETL Tools fully support OLE DB. However, it is one of the slowest ways of accessing the data and when working with large datasets it tends to use a lot of memory.

More Information:

Direct link, no registration required.