Prerequisites for Federated Partitions
Before you can create a federated partition, you need to provision an Oracle Autonomous Database Serverless instance with the Autonomous Data Warehouse workload type, deploy Essbase to the same Oracle Cloud Infrastructure tenancy using Marketplace, and perform other setup tasks.
Setup tasks must be completed before you can create a federated partition in Essbase.
Review the following checklists, and then proceed to Federated Partitions Workflow to learn the order of tasks for implementation.
Table 18-2 Cloud Deployment Prerequisites
| Requirement | Reason | What to Do / More Information |
|---|---|---|
|
Essbase and Autonomous Data Warehouse 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 Data Warehouse Serverless stores the data for your Essbase cube. |
|
|
Essbase uses the Autonomous Data Warehouse as its schema repository. |
The following schemas in Autonomous Data Warehouse 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 Partitions |
|
The Essbase deployment is configured to use OCI object storage. |
To enable data load from Essbase to Autonomous Data Warehouse, the Essbase file catalog storage must be integrated with Oracle cloud storage. |
Table 18-3 Database Prerequisites
| Requirement | Reason | What to Do / More Information |
|---|---|---|
|
Your organization deploys an Autonomous Data Warehouse 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 Data Warehouse also handles the data storage for Essbase. Whether you require fastest query performance, highly concurrent workloads, or a mixture of both, Autonomous Data Warehouse provides the right service you need to meet those data access requirements. |
Provision an Autonomous Data Warehouse for Federated Partitions |
|
The Database Administrator for Autonomous Data Warehouse creates a new schema. |
A dedicated schema is needed for working with federated partition. A new Autonomous Data Warehouse user is equivalent to a new, empty schema. In the remainder of this federated partition documentation, we will refer to the owner of the dedicated schema as DB User. |
Create Users on Autonomous Database (if you want to use the OCI Console) or CREATE USER (to create the Autonomous Data Warehouse user/schema using any SQL client tool) |
|
The Database Administrator for Autonomous Data Warehouse grants resource privileges to the DB User. |
The Database user in Autonomous Data Warehouse needs to be able to:
|
Manage User Roles and Privileges on Autonomous Database Provision an Autonomous Data Warehouse for Federated Partitions |
|
The DB User creates a fact table in the schema. |
A fact table in Autonomous Data Warehouse is needed to store the Essbase cube data. |
Table 18-4 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 partition cubes should not share an application with other cubes. The fact table should not be shared among multiple cubes. |
An Essbase outline is required for federated partitions, to map the cube to the fact table in Autonomous Data Warehouse. |
|
|
The Essbase service administrator or application manager defines a connection. |
Essbase must have connectivity with Autonomous Data Warehouse. |