Documentación de Oracle Cloud Infrastructure

Carga de trabajo de Lakehouse con base de datos de IA autónoma

La base de datos de IA autónoma configura y optimiza tu base de datos en función de tu carga de trabajo.

Características de una base de datos con carga de trabajo de Lakehouse:

  • Los datos por defecto y las tablas temporales de la base de datos se configuran automáticamente. No se permite agregar, eliminar ni modificar tablespaces. La base de datos de IA autónoma crea uno o varios tablespaces automáticamente en función del tamaño de almacenamiento.

  • El conjunto de caracteres de las bases de datos es Unicode AL32UTF8. Consulte Elección de un juego de caracteres para una base de datos de IA autónoma para obtener más información.

  • La compresión está activada por defecto. La base de datos de IA autónoma utiliza la compresión de columnas híbridas para todas las tablas por defecto. Puede especificar diferentes métodos de compresión para las tablas mediante la cláusula de compresión en los comandos CREATE TABLE o ALTER TABLE.

  • La caché de resultados de Oracle Database está activada por defecto para todas las sentencias SQL.

Acceso a una Base de Datos:

  • No tiene acceso directo al nodo de base de datos. Puede crear y borrar directorios con CREATE DIRECTORY y DROP DIRECTORY, como se describe en Creación y gestión de directorios en base de datos de IA autónoma.

    Puede utilizar procedimientos DBMS_CLOUD, como DBMS_CLOUD.DELETE_FILE, DBMS_CLOUD.GET_OBJECT y DBMS_CLOUD.PUT_OBJECT, con archivos y objetos. No tiene acceso directo al sistema de archivos local.

Ejecución en Paralelo con Carga de Trabajo de Lakehouse:

  • El servicio de base de datos determina el paralelismo. Consulte Database Service Names for Autonomous AI Database para obtener más información. para obtener más información sobre el soporte de paralelismo para cada servicio de base de datos.

  • Cuando desee desactivar operaciones DML paralelas en la sesión, utilice el siguiente comando SQL:

    ALTER SESSION DISABLE PARALLEL DML;

    Consulte VLDB and Partitioning Guide para ver más información sobre las operaciones DML paralelas.

Gestión del rendimiento y la compresión de DML para cargas de trabajo de lakehouse

La base de datos de IA autónoma con cargas de trabajo de Lakehouse utiliza la compresión de columnas híbridas para todas las tablas por defecto. Esto proporciona la mejor relación de compresión y un rendimiento óptimo para las operaciones de carga de ruta de acceso directa, como las cargas realizadas mediante el paquete DBMS_CLOUD. Si realiza operaciones DML como UPDATE y MERGE en las tablas, esto puede hacer que el ratio de compresión de las filas afectadas disminuya, lo que lleva a tamaños de tabla más grandes. Estas operaciones también pueden tener un rendimiento más lento en comparación con las mismas operaciones en una tabla sin comprimir.

Para obtener la mejor relación de compresión y un rendimiento óptimo, Oracle recomienda utilizar operaciones masivas como cargas de ruta de acceso directa y sentencias CREATE TABLE AS SELECT. Sin embargo, si la carga de trabajo necesita operaciones DML frecuentes, como UPDATE y MERGE, en grandes partes de una tabla, puede crear esas tablas como tablas sin comprimir para lograr un mejor rendimiento de DML. Por ejemplo, la siguiente sentencia crea la tabla SALES como una tabla sin comprimir: 

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;

En cualquier momento, puede utilizar la sentencia ALTER TABLE MOVE para comprimir estas tablas sin afectar a las consultas que acceden a ellas. Por ejemplo, la siguiente sentencia comprime la tabla SALES mediante la compresión de columnas híbridas. 

ALTER TABLE sales MOVE COLUMN STORE COMPRESS FOR QUERY HIGH;

Creación de tablas temporales para cargas de trabajo de lakehouse

Autonomous AI Database soporta tablas temporales optimizadas para cargar datos en un lakehouse.

Una tabla temporal es una tabla con el juego de propiedades STAGING. Esto aplica las siguientes características:

  • Cualquier forma de compresión se desactiva explícitamente y no se permite en una tabla temporal para cualquier carga de datos. No se permite el comando ALTER TABLE COMPRESS.

  • La definición de la propiedad STAGING en una tabla existente no afecta al almacenamiento de datos existentes, pero sí afecta a futuras cargas de datos.

  • La base de datos de IA autónoma utiliza el muestreo dinámico para las estadísticas de las tablas con el juego de propiedades temporales y no recopila estadísticas sobre las tablas temporales.

  • Al borrar tablas temporales, se elimina inmediatamente la tabla y se omite la papelera de reciclaje. Al definir el parámetro de inicialización recyclebin en el valor ON no se activa la papelera de reciclaje.

Las características de las tablas temporales particionadas de la base de datos de IA autónoma incluyen lo anterior, además de lo siguiente:

  • Cualquier forma de compresión se desactiva y no se permite explícitamente en todas las particiones y subparticiones de la tabla.

  • No puede cambiar los atributos por defecto de la tabla para utilizar la compresión con ALTER TABLE MODIFY DEFAULT ATTRIBUTES.

  • No puede realizar operaciones de mantenimiento de particiones que muevan datos y compriman los datos. Por ejemplo, no se permite lo siguiente al intentar aplicar la compresión: ALTER TABLE con MOVE PARTITION, MERGE PARTITIONS, SPLIT PARTITION o SPLIT SUBPARTITION.

  • No puede volver a particionar una tabla con ALTER TABLE MODIFY PARTITION y especificar cualquier partición resultante que se va a comprimir.

Defina las tablas temporales cuando cree una tabla o modifique una tabla existente de la siguiente manera:

  1. Cree una tabla con la propiedad STAGING.

    Por ejemplo:

    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. Cambie una tabla existente para definir la propiedad STAGING.

    Por ejemplo:

    ALTER TABLE staging_table FOR STAGING;
  3. Puede verificar la propiedad STAGING de una tabla mediante una de las siguientes vistas: USER_TABLES, ALL_TABLES o DBA_TABLES.

    En estas vistas, la columna STAGING indica la propiedad de la tabla temporal, el valor YES indica una tabla STAGING y el valor NO se muestra para el resto de tablas.

Puede modificar una tabla para eliminar la propiedad STAGING. Por ejemplo: 

ALTER TABLE staging_table NOT FOR STAGING;

Tenga en cuenta lo siguiente para modificar una tabla con NOT FOR STAGING:

  • Después de modificar una tabla con NOT FOR STAGING, el atributo de compresión y los datos existentes no se ven afectados y se mantienen sin comprimir hasta que se modifica explícitamente la tabla y se especifica la compresión. Puede cambiar la compresión de la tabla y se permite ALTER TABLE COMPRESS.

  • La modificación de una tabla con NOT FOR STAGING no dispara la recopilación de estadísticas. Después de cambiar la propiedad de tabla con NOT FOR STAGING, puede recopilar estadísticas, ya sea de forma manual o automática.

  • Después de modificar una tabla con NOT FOR STAGING, cuando la papelería de reciclaje está activada para borrarla, la tabla se coloca en la papelería de reciclaje.