The fallback state database maintains a secondary copy of the state database in Oracle Database, while the primary state database is stored on the embedded Berkeley DB.

The state database is stored on each peer for all channels that the peer is joined to. Oracle Blockchain Platform uses Berkeley DB as the embedded database on peer nodes. If a peer crashes or restarts, the state database can get corrupted. Oracle Blockchain Platform automatically detects and rebuilds a corrupted state database from the ledger, but this can take a significant amount of time depending on the ledger size and number of blocks. The peer node is not available for endorsing or committing transactions during the rebuild process.

The hybrid state database model adds an external Oracle Database as a fallback. In normal operation, peers complete synchronous block commits to the Berkeley DB state database and asynchronous commits to the fallback database. If the embedded state database fails, the peer automatically switches to use Oracle Database for synchronous commits while the Berkeley DB state database is asynchronously rebuilt. After the rebuild process completes, the peer switches back to normal operation.

You must use Oracle Autonomous Transaction Processing as the fallback database.

Use the console to provide database connection information and select the peers where you want to configure a fallback state database.

1. Go to the console and click the More Actions icon in the title bar, where the name of the instance is also displayed.
2. Click Configure Fallback State Database.
   The Configure Fallback State Database window is displayed.
3. Specify the connection information for Oracle Autonomous Transaction Processing.
   1. If you have already configured the rich history database and you want to use the same connection information for the fallback state database, click Use Rich History Database Configuration to use the same instance of Oracle Database as the fallback state database. Otherwise, specify a User Name, Password, and Connection String, and optionally upload a wallet file. For more information on connection strings, see Create the Oracle Database Classic Cloud Service Connection String.
   2. To configure the fallback database for every peer in the network, click Enable for all peers.
   3. To configure the fallback database for any newly added (scaled) peer, click Enable for newly scaled peers.
   4. Click Save.
      All selected peers restart when you apply the configuration.
4. To enable or disable the fallback state database on a specific peer, edit the peer configuration.
   1. Click the Nodes tab.
   2. In the nodes table, for the peer that you want to modify click the More Actions icon and then click Edit Configuration.
   3. Under Fallback State Database, select ENABLE or DISABLE, and then click Submit.

After you configure a fallback state database on a peer node, you can monitor the state database status.

1. Go to the console and click the Nodes tab.
2. In the nodes table, click the More Actions icon for the peer node that you want to monitor, and then click Monitor State Database.
   A table is displayed that contains the following information about the state database status.

   Channel Name

   The channel that the peer is joined to.

   Active Database

   The database that is currently accepting synchronous block commits, either the primary database (Berkeley DB) or the fallback database (Oracle Database).

   Ledger Block Height

   The number of blocks currently stored in the ledger.

   Primary Database State

   • SYNC_COMMITS: The database is operating normally in synchronous mode.
   • ASYNC_RECOVERY: The database is processing commits in asynchronous mode and attempting to catch up to the ledger block height.
   • ASYNC_ABORTED: A persistent error occurred while the database was processing commits in asynchronous mode, or the asynchronous block queue is full. In either case, the underlying issue must be corrected and the peer must be restarted.

   Primary Database Block Height

   The number of blocks currently stored in the primary state database.

   Fallback Database State

   • ASYNC_COMMITS: The database is operating normally as a fallback, in asynchronous mode.
   • SYNC_COMMITS: The database is operating in synchronous mode, because there was a problem with the primary database or because the primary database block height was below the ledger block height while the fallback database ledger height was equal to the ledger block height.
   • ASYNC_RECOVERY: The database is processing commits in asynchronous mode and attempting to catch up to the ledger block height.
   • ASYNC_ABORTED: A persistent error occurred while the database was processing commits in asynchronous mode, or the asynchronous block queue is full. In either case, the underlying issue must be corrected and the peer must be restarted.

   Fallback Database Block Height

   The number of blocks currently stored in Oracle Database (the fallback database).

   Async Queue Length

   The number of blocks in the queue awaiting asynchronous processing by the current asynchronous database.

   Last Async Error

   The most recent error related to the asynchronous database, which can include connection or credentials issues or problems with the asynchronous queue or key sizes.