Lakehouse Workload with Autonomous AI Database

Autonomous AI Database configures and optimizes your database for you, based on your workload.

Characteristics of a database with Lakehouse workload:

Accessing a database:

Parallel Execution with Lakehouse workload:

Manage DML Performance and Compression for Lakehouse Workloads

Autonomous AI Database with Lakehouse workloads uses Hybrid Columnar Compression for all tables by default. This gives the best compression ratio and optimal performance for direct-path load operations like the loads done using the DBMS_CLOUD package. If you perform DML operations like UPDATE and MERGE on your tables these may cause the compression ratio for the affected rows to decrease leading to larger table sizes. These operations may also perform slower compared to the same operations on an uncompressed table.

For the best compression ratio and optimal performance Oracle recommends using bulk operations like direct-path loads and CREATE TABLE AS SELECT statements. But, if your workload requires frequent DML operations like UPDATE and MERGE on large parts of a table, you can create those tables as uncompressed tables to achieve better DML performance. For example, the following statement creates the table SALES as an uncompressed table:

CREATE TABLE sales (
    prod_id             NUMBER          NOT NULL,
    cust_id             NUMBER          NOT NULL,
    time_id             DATE            NOT NULL,
    channel_id          NUMBER          NOT NULL,
    promo_id            NUMBER          NOT NULL,
    quantity_sold       NUMBER(10,2)    NOT NULL,
    amount_sold         NUMBER(10,2)    NOT NULL)
NOCOMPRESS;

At any point in time you can use the ALTER TABLE MOVE statement to compress these tables without impacting queries accessing them. For example, the following statement compresses the table SALES using Hybrid Columnar Compression.

ALTER TABLE sales MOVE COLUMN STORE COMPRESS FOR QUERY HIGH;

Create Staging Tables for Lakehouse Workloads

Autonomous AI Database supports staging tables that are optimized for loading data into a lakehouse.

A staging table is a table with the STAGING property set. This applies the following characteristics:

The characteristics of Autonomous AI Database partitioned staging tables includes the above, plus the following:

Define staging tables when you create a table or by altering an existing table as follows:

  1. Create a table with the STAGING property.

    For example:

    CREATE TABLE staging_table (col1 number, col2 varchar2(100)) FOR STAGING;
    
    CREATE TABLE part_staging_table (col1 number, col2 varchar2(100))
    PARTITION BYRANGE (col1)
          (PARTITION p1 VALUESLESS THAN (100),
           PARTITION pmax VALUESLESS THAN (MAXVALUE)) FOR STAGING;
  2. Change an existing table to set the STAGING property.

    For example:

    ALTER TABLE staging_table FOR STAGING;
  3. You can verify the STAGING property for a table using one of the following views: USER_TABLES, ALL_TABLES, or DBA_TABLES.

    In these views, the STAGING column indicates the staging table property, a value YES indicates a STAGING table, a value NO is shown for all other tables.

You can alter a table to remove the STAGING property. For example:

ALTER TABLE staging_table NOT FOR STAGING;

Note the following for altering a table with NOT FOR STAGING: