By default, OpenEdge databases are designed with continuous operation in mind. Whether you are upgrading from a previous version of OpenEdge, or building your application for the first time, OpenEdge databases are built to be robust.

While a database cannot be load balanced like the PAS for OpenEdge instances, you must ensure continual access to it. If your production database, database machine, or network becomes unavailable you can quickly transition to the replicated database with minimal outage.

ABL sessions and databases have continuous operation features that reduce the time needed to restart a database or reconnect to a database replica. When you run multiple copies of a replicated target database, if the source goes down, a target transitions to the source database.

If you have replication plus, an opt-in OpenEdge feature, you can also use a target database as a READ-ONLY database, taking that work off of the source database machine.

Another critical aspect of database continuous operation is maintaining an ABL session’s database connection. To maintain that connection, use the following ABL continuous operation capabilities:
  • ABL session database connection options— These options permit an automated reconnection process to initiate if the initial connection is interrupted. While this option does not permit transparent reconnections, it moves the responsibility for detecting and restoring a disconnect from your application to the OpenEdge database.
  • Enhancements to the OpenEdge database that reduce the time a database is available for a client reconnection.

However, there are times when you need to perform maintenance or to push updates to your updates. In the past this meant that you might need to take your database down, causing disruption to your users. To minimize down time and, by extension, to prevent disruption to users, OpenEdge is designed to be able to push updates, schema changes, and parameter modifications to your database all while your application is still up and running.

Change database parameters while the database is online

OpenEdge offers over 100 different parameters that you can modify while your database is running, giving you versatility in an ever-changing business environment. For example, it might become necessary for you to change the maximum number of clients per server to support increased load without bringing your database down. With an OpenEdge database, you can do that and more.

For more information on modifying database parameters, see the following topics:

Manage indexes online

As database blocks can become fragmented, index blocks can become underused over time. The optimal degree of index block utilization depends on the type of database access performed. Retrieval-intensive applications generally perform better when the index blocks are close to full because the database engine must access fewer blocks to retrieve a record. The larger the index, the greater the potential for improving uptime by compacting the index. Update-intensive applications, on the other hand, perform better with loosely packed indexes because there is room to insert new keys without allocating more blocks. Index analysis provides the utilization information that you need to make decisions. Choose a balance between tightly packed indexes and underused indexes, depending on your data and applications.

For more information on managing indexes, see the following topics:

Manage database brokers

To support continuous operation, OpenEdge databases log secondary broker parameters, keep secondary brokers running during recovery transitions, and let you disconnect secondary brokers without a process kill signal.

Secondary brokers let you manage the configuration for a specific group of end users such as ABL clients, SQL clients, or both.

OpenEdge features like these help you manage brokers to support continuous operation:
  • Brokers keep running during recovery transitions—To finish transitions faster, database brokers continue running on single targets and replication sets. This improves both manual and automatic recovery transitions. For more information, see Plan for transition in Use Database Replication.
  • You can disconnect secondary brokers using PROMON—A PROMON option lets you disconnect secondary brokers without issuing a process kill signal.

    This option reduces potential database downtime. For more information, see Server Options in Manage the OpenEdge Database.

  • The database log file (.lg) logs secondary broker parameters—The database log file captures information that helps you understand the circumstances surrounding a failure. The log now records start up parameters for secondary brokers.

    Although you can list broker parameters for running servers by using PROMON R&D Status or Virtual System Tables (VST), the database log file lets you troubleshoot environment or connection issues after server failure. You can easily determine which brokers were active during an event.

    For an example, see Find connected brokers and servers in Manage the OpenEdge Database.