1. Using Oracle Essbase
  2. Integrate Essbase with Autonomous Database Using Federated Partitions
  3. Federated Cube Maintenance and Troubleshooting

Federated Cube Maintenance and Troubleshooting

Use the following guidelines to maintain or troubleshoot Essbase federated partitions.

This topic assumes you have created a federated partition and reviewed the information detailed in the preceding topics.

Model and Test Federated Cubes

When designing a federated partition cube, follow these testing guidelines if the partition creation takes too long. These guidelines can be useful for taking a phased approach to troubleshoot or monitor performance.

  • Begin the federated partition project on a test environment.

  • Start with cube models that have the following characteristics:

    • not many levels

    • not many shared members or attributes

  1. When creating a federated partition, schedule offline operations when queries are not allowed against the instance.

  2. Gradually disconnect active Essbase user sessions, using MaxL alter application disable commands and/or connects (to prevent any new user activity), followed by alter system logout session and/or kill request (if you need to terminate any active sessions that don't need to complete). Note that MaxL cannot terminate any requests that may be running in Autonomous Data Warehouse. If you disable commands in the application, remember to re-enable commands after creating the federated partition.

  3. Perform timeout tuning:
    • HTTPS proxy on customer network - adjust customer network timeouts
    • Load balancer - increase LoadBalance timeout to 1260 seconds (21 minutes)
    • Increase HTTPD timeouts to 21 minutes
      /etc/httpd/conf.d/00_base.conf:ProxyTimeout 1260
      /etc/httpd/conf.d/00_base.conf:Timeout 1260
    • APS/JAPI timeout:
      • On the Console page in the Essbase web interface, select Configuration, and note the value of olap.server.netSocketTimeOut. A value of 200 ms means that every count of 5 for these properties gives 1 second of time-wait.
      • To set APS/JAPI timeout limit to 30 minutes, set olap.server.netRetryCount to 9000.
  4. Create the federated partition.
  5. Revert the timeout adjustments in step 3.
  6. Enable users back onto the system using alter application enable commands and/or connects, if these were disabled previously.
  7. For reports on an Essbase cube with a federated partition, tune QRYGOVEXECTIME to be larger than the expected time to execute queries against federated partitions. Note that QRYGOVEXECTIME cannot terminate any requests that may be running in Autonomous Data Warehouse.
  8. After development environment testing and tuning are completed, then use the above steps 1 through 7 to add the federated partition into a production environment.

Note:

If you see a "Failed to save outline" error when creating the federated partition, wait for the sessions to complete, then refresh the browser. If the federated partition has been created, then validate it in SQL Developer. If it validates in SQL Developer then the federated partition is ready for use. If it does not validate in SQL Developer, then the model needs to be fixed and timeout tuning is needed as described above in step 3.

Metadata Precautions for Federated Partition Cubes

When Essbase has a federated partition, take care when editing the cube outline. If you add or rename members, ensure that the metadata changes are also represented in the fact table in Autonomous Data Warehouse.

If the Essbase outline becomes out of sync with the fact table in Autonomous Data Warehouse, the federated partition will become invalid or not function correctly. To fix it, you will need to drop the federated partition, make changes to the outline and fact table, and then re-create the federated partition.

If a federated partition becomes invalid, you may encounter an error beginning with Essbase Error(1040235): Remote warning from federated partition.

The following types of Essbase outline changes will cause a federated partition to become invalid:

  • Adding, renaming, or removing dimensions

  • Adding, renaming, or removing stored members in the pivot dimension

  • Changing any member from stored to dynamic

For other types of Essbase outline changes not indicated above (for example, adding or renaming a non-pivot-dimension member), you should make the corresponding change to the affected data row in the fact table. Otherwise, the federated partition may not function correctly.

If you know in advance that Essbase outline metadata will change, it is better to remove the federated partition first, make the outline changes, update the fact table, and then recreate the federated partition.

However, if the Essbase metadata changed and caused the partition to become invalid, take the following action:

  1. Remove the federated partition, and the connection associated with it (if otherwise unused), as described in Remove a Federated Partition.

    From the federated-partition user schema in Autonomous Data Warehouse, manually delete any Essbase-generated tables and other objects that failed to be removed with the partition.

  2. Ensure that the outline changes are completed in the Essbase cube.

  3. Create the fact table again. See Create the Fact Table.

  4. Re-create the connection to Autonomous Data Warehouse. This may be a global connection (under the main Sources icon in Essbase web interface), or it may be in the Sources defined just for the application. Follow the instructions in Create a Connection for Federated Partitions.

  5. Re-create the federated partition, as described in Create a Federated Partition.

What to Do if the Database Connection Details Changed

If the Autonomous Data Warehouse connection details that Essbase uses for a federated partition have changed, you will need to drop and re-create the federated partition.

You will need to drop and re-create the federated partition if any of the following events occur after the federated partition was created:

  • The Autonomous Data Warehouse port changes

  • The connection name changes

  • The connection uses a wallet, and you switch from one service name to another (to make performance or concurrency changes)

  • An outline update changes the member mapping to the fact table, causing the partition to become out of sync. See Metadata Precautions for Federated Partition Cubes for details.

If you know in advance that the connection details will change, it is better to remove the federated partition before the change occurs, and create it again after. However, if the connection changed and caused the partition to become invalid, take the following action:

Fix Invalid Federated Partition

  1. Remove the federated partition, and the connection associated with it (if otherwise unused), as described in Remove a Federated Partition.

    From the federated-partition user schema in Autonomous Data Warehouse, manually delete any Essbase-generated tables and other objects that failed to be removed with the partition.

  2. Re-create the connection to Autonomous Data Warehouse. This may be a global connection (under the main Sources icon in Essbase web interface), or it may be in the Sources defined just for the application. Follow the instructions in Create a Connection for Federated Partitions. Make sure to Test and Save the connection.

  3. Re-create the federated partition, as described in Create a Federated Partition.

  4. If you continue to see a connection error such as Essbase Error(1350012): Attempt to connect to OCI failed, check https://support.oracle.com/rs?type=doc&id=2925030.1.

Back up and Restore a Federated Partition Application

Federated partitions are not migrated with Essbase applications. When preparing to move your application and cube to another server or to migrate to another Essbase version, you need to delete the federated partition and recreate it in the new environment.

To back up your federated cube,

  1. Back up the application, without the data, but including everything else you may need (such as configuration properties, filters, variables, calculation scripts, and other artifacts). To do this, use LCM export (or the Export LCM job in the Essbase web interface).

  2. Back up the fact table. See Backing Up and Restoring Autonomous Database.

  3. Delete the federated partition definition from the cube, following the steps in Remove a Federated Partition.

To restore your federated cube from backup,

  1. Re-create the application, using LcmImport: Restore Cube Files (or the Import LCM job in the Essbase web interface).

  2. If necessary, restore the fact table on Autonomous Data Warehouse.

  3. Re-create the connection to Autonomous Data Warehouse. It is recommended to use a new connection name to avoid encountering errors.

  4. Re-create the federated partition.