Understanding ORAIO

ORAIO is an Oracle-specific driver that interfaces between the Meridian object cache and Oracle. Every data change inside Meridian needs to be committed to the Oracle database as soon as possible. Due to loads that may be placed on Oracle by other applications and latency induced by the network between the Meridian application server and the SQL Server computer, it can take a significant amount of time for Oracle to commit data changes, which can lead to poor performance. To avoid this bottleneck, ORAIO uses a write-ahead log mechanism illustrated in the figure in Understanding how Meridian works with Oracle.

Instead of directly committing data to Oracle, ORAIO’s main thread commits data to log files (not to be confused with the Oracle database log) stored on the Meridian application server. At this point, the data is considered by Meridian as committed; it can continue its work and the user will experience good responsiveness. A second thread in ORAIO reads the log files and updates the Oracle database.

The actual time to process an ORAIO log file is the time it takes to transport its contents to the Oracle server, after which the log file is deleted. If the connection between the EDM Server and the Oracle driver is lost, no transactions are lost; the EDM Server detects the situation, closes down the database driver (all users will get “Database engine unavailable” errors), and leaves the last one or two log files in the log folder. After the EDM Server is restarted and connected to the Oracle database again, it will continue copying the transaction logs to the Oracle server. The only way one or more transactions can be lost is if the EDM Server computer physically crashes; a hard disk stop responding, for example.

Note    An EDM Server service transaction is different from an Oracle transaction. Each ORAIO log file equals one EDM Server transaction.

The write-ahead log mechanism maintains the integrity of the data. For example, when data needs to be retrieved by the Meridian application server, it requests the data from the object cache. If the data is not cached, it requests the data from ORAIO, which first checks whether this data is in the write-ahead log, and only if it is not found does ORAIO request the data from Oracle.

If a lot of data is changed over a sustained period of time (for example, as the result of a batch import), the number of ORAIO log files will grow because they cannot be processed by Oracle as fast as they are created by the ORAIO driver. This does not have a detrimental effect on the system performance, but the disk could run out of space if the number of log files keeps growing indefinitely. The maximum amount of space used for all log files can be configured as described in Configuring the MaximumLogSize setting. If the total size of all ORAIO log files reaches this limit, performance will drop because new changes will then be committed to the log files only as fast as the existing log files are processed by Oracle. Performance will continue to be affected until the workload of the system diminishes and Oracle can process the backlog of pending log files. There is one exception to this situation: When the EDM Server places an internal recovery point, log files are not processed by Oracle until the last EDM Server transaction has been committed successfully. This allows the EDM Server to roll back the entire update to the last known good state. For example, this happens when a new Field-Path definition is applied.

Oracle stops processing the ORAIO log files when the vault is closed, that is, after the last client closes its connection to the server. Log files that have not been processed by that time will remain until the vault is reopened and the processing starts again. This is not a serious performance issue because Meridian allows for vaults to become available immediately after reopening them; users do not have to wait for the existing log files to be processed.

ORAIO uses an Oracle account to communicate with Oracle. Regardless of the number of users on the system, it takes up only one connection to the database.