Prerequisites for Federated Cubes

Once you have decided you want to try a federated cube with Essbase, you need make a decision about storage management. Then, you need to provision an Autonomous AI Lakehouse, deploy Essbase, and complete required setup tasks.

Note:

After you create a federated partition, your Essbase cube becomes a federated cube.

Before you can create a federated partition,

  1. Based on your use case, decide on a data storage management option. See Data Load Options for Federated Cubes.

  2. Provision an Oracle Autonomous Database Serverless instance with the Autonomous AI Lakehouse workload type.

  3. Deploy Essbase to the same Oracle Cloud Infrastructure tenancy using Marketplace.

  4. Perform the setup tasks listed below.

The following setup tasks must be completed before you can create a federated partition in Essbase.

Review the following checklists, and then proceed to Federated Cube Deployment Workflow to learn the order of tasks for implementation.

Table 15-1 Cloud Deployment Prerequisites

Requirement Reason What to Do / More Information

Essbase and Autonomous AI Lakehouse are deployed together in a shared Oracle Cloud Infrastructure tenancy, using the Marketplace listing.

Oracle Cloud Infrastructure enables Essbase to take advantage of flexible and scalable cloud computing architectures.

Autonomous AI Lakehouse Serverless stores the data for your Essbase cube.

Marketplace

Deploy Essbase from Marketplace for Federated Cubes

Essbase uses the Autonomous AI Lakehouse as its schema repository.

The following schemas in Autonomous AI Lakehouse have different purposes for Essbase:

The Repository Creation Utility (RCU) schemas are created automatically during Essbase deployment, and hold information about platform artifacts and components.

The Database user schema is home to the fact table that holds Essbase data.

Caution:

These are separate schemas by design. Do not use any of the RCU schemas for the fact table.
Deploy Essbase from Marketplace for Federated Cubes

The Essbase deployment is configured to use OCI object storage.

The Essbase file catalog storage must be integrated with the OCI Object Storage Bucket.

Deploy Essbase from Marketplace for Federated Cubes

Table 15-2 Database Prerequisites

Requirement Reason What to Do / More Information

Your organization deploys an Autonomous AI Lakehouse Serverless.

Configuration, tuning, storage, backups, and updates are all Oracle managed, so you can use Essbase in a cloud environment without spending time on infrastructure.

Autonomous AI Lakehouse also handles the data storage for Essbase.

Whether you require fastest query performance, highly concurrent workloads, or a mixture of both, Autonomous AI Lakehouse provides the right service you need to meet those data access requirements.

Provision Autonomous AI Lakehouse for Federated Cubes

The Database Administrator for Autonomous AI Lakehouse creates a new schema.

You need a schema in Autonomous AI Lakehouse that will contain the data for your federated cube.

Note:

Oracle recommends using a dedicated schema.

A new Autonomous AI Lakehouse user is equivalent to a new schema.

In the remainder of this documentation, we will refer to the owner of the schema as DB User.

Create Users on Autonomous Database (if you want to use the OCI Console)

or

CREATE USER (to create the Autonomous AI Lakehouse user/schema using any SQL client tool)

The Database Administrator for Autonomous AI Lakehouse grants resource privileges to the DB User.

The Database user in Autonomous AI Lakehouse needs to be able to:

  • create a connection to Autonomous AI Lakehouse

  • create a fact table to store Essbase data

Manage User Roles and Privileges on Autonomous AI Database

Provision Autonomous AI Lakehouse for Federated Cubes

Optional: The DB User creates a fact table in the schema.

Note:

This prerequisite does not apply if you plan to let Essbase manage the data storage. See Data Load Options for Federated Cubes.

A fact table in Autonomous AI Lakehouse is needed to store the Essbase cube data.

Note:

You can load data into Autonomous AI Database using Data Studio tools. See The Data Load Page.

Identify the Pivot Dimension and Set up the Fact Table

SQL Session Governor is enabled.

You can cancel SQL sessions that are running on Autonomous AI Lakehouse. SQL cancellation may be necessary if an Essbase calculation is taking too long, or if the federated cube needs backup or recovery.

If Essbase calculations, data loads, or aggregations running on federated cubes generate long running SQL statements, it is possible to cancel the sessions, even though they are running on Autonomous AI Lakehouse.

Cancel Long Running SQL on Federated Cubes

Note:

Steps 1 and 2 are required. Step 2 is a validation of step 1. If it fails, repeat step 1, correcting any errors.

Table 15-3 Essbase Platform Prerequisites

Requirement Reason What to Do / More Information

An Essbase application and cube are created.

The cube does not need to have any data in it.

The cube must be within its own uniquely-named application. Federated cubes should not share an application with other cubes. Do not use the same Autonomous AI Lakehouse schema for multiple instances of Essbase.

An Essbase outline is required, to map the cube to the fact table in Autonomous AI Lakehouse.

Create a Cube from an Application Workbook

The Essbase service administrator or application manager defines a connection.

Essbase must have connectivity with Autonomous AI Lakehouse.

Create a Connection for Federated Cubes

This is a prerequisite for creating a federated partition.

One or more individuals configures DBMS_CLOUD credentials.

Before creating a federated partition, you'll need to enable cloud credentials, so that Essbase can store data and metadata in Autonomous AI Lakehouse.

Set up Credentials for Federated Cubes