Migrar a base de datos de Exadata

Origen: plataforma de Oracle Database, como Oracle Exadata Database, Oracle RAC o una instancia independiente de Oracle Database en Linux.

Destino: Oracle Exadata Database que se ejecuta en Oracle AI Database@Google Cloud.

• Un cubo que contiene los archivos de datos como archivo de volcado de Oracle Data Pump

• Para Oracle Database, está soportada la conectividad a Internet o el enlace privado que utiliza Oracle Interconnect for Google Cloud.
• Para Oracle AI Database@Google Cloud, la conectividad interna dentro de la misma región de nube está soportada por defecto.

• Clave y secreto de acceso a Google Cloud (clave HMAC) con permisos de acceso al cubo.

1. Crear credenciales de acceso a Google Cloud Storage
   1. En la consola de Google Cloud, vaya a Almacenamiento en la nube.
   2. Seleccione Configuración en el menú de la izquierda y, a continuación, seleccione el separador Interoperabilidad.
   3. Desplácese hacia abajo hasta la sección Claves de acceso para su cuenta de usuario y seleccione el botón Crear una clave para generar una Clave de acceso y un Secreto. Tome nota de la clave de acceso y el secreto, ya que son necesarios para autenticar el acceso a Oracle Database.
2. Determinar URL de objeto
   1. En la consola de Google Cloud, vaya a Almacenamiento en la nube.
   2. En el menú de la izquierda, seleccione Cubos y, a continuación, seleccione el cubo de destino que está utilizando.
   3. En la página Detalles de cubo, busque el objeto. Por ejemplo, el archivo de exportación de Oracle Data Pump que desea importar.
   4. Cree la URL de objeto público en el formulario.

      https://<bucket_name>.storage.googleapis.com/<object_name>

      Por ejemplo:

      • Nombre de cubo: exadbtest
      • Nombre de objeto: emp.dmp
      • URL de objeto: https://exadbtest.storage.googleapis.com/emp.dmp
      

1. Crear Credencial de Oracle
   1. Mediante el procedimiento PL/SQL DBMS_CLOUD.CREATE_CREDENTIAL, cree una credencial en la base de datos que almacene la clave de acceso y el secreto de GCS:

      BEGIN DBMS_CLOUD.CREATE_CREDENTIAL( credential_name => '<Credential_Name>', username => '<GCS_Access_Key>', password => '<GCS_Secret>' ); END; /

      Por ejemplo:

      BEGIN DBMS_CLOUD.CREATE_CREDENTIAL( credential_name => 'GCP_CRED', username => 'GOOGXXXXXXXXXXXX', password => 'xs9njBZ+hykXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' ); END; /

   2. Después de ejecutar el procedimiento PL/SQL, la credencial se almacena y está lista para su uso por parte de DBMS_CLOUD. Para obtener más información sobre los parámetros, consulte CREATE_CREDENTIAL Procedure.
2. Verificar el acceso a Google Cloud Storage
   1. Para asegurarse de que la base de datos puede acceder a su cubo de Google Cloud Storage, ejecute lo siguiente:

      SELECT object_name FROM dbms_cloud.list_objects( credential_name => 'GCP_CRED', uri => 'https://exadbtest.storage.googleapis.com' );

   2. La salida debe mostrar los objetos, lo que confirma el acceso correcto. Por ejemplo:

      OBJECT_NAME
      --------------------------------------------------------------------------------
      emp.dmp
      employee.csv

Después de crear la credencial necesaria para Google Cloud Storage, puede cargar o acceder a datos en Oracle Database mediante cualquiera de los siguientes métodos: procedimiento DBMS_CLOUD.COPY_DATA, importación de Oracle Data Pump (impdp), DBMS_CLOUD.CREATE_EXTERNAL_TABLE, DBMS_CLOUD.CREATE_EXTERNAL_PART_TABLE, herramienta de carga de Data Studio (IU en la base de datos de Exadata) o DBMS_CLOUD.CREATE_HYBRID_PART_TABLE para tablas particionadas híbridas.

Este paso muestra DBMS_CLOUD.COPY_DATA, así como la importación de Oracle Data Pump (impdp).

1. Uso del procedimiento DBMS_CLOUD.COPY_DATA
   1. Cree una tabla en la base de datos en la que desee cargar los datos.

      CREATE TABLE emp (id NUMBER, name VARCHAR2(64));

   2. Importe datos del cubo de Google Cloud Storage a su base de datos de Exadata.
   3. Especifique el nombre de tabla y el nombre de credencial de GCP seguido de la URL de objeto de Google Cloud Storage.
   4. Utilice el procedimiento DBMS_CLOUD.COPY_DATA para cargar datos del cubo de Google Cloud Storage en una tabla. El parámetro file_uri_list especifica la ruta de acceso a los archivos en Google Cloud Storage.

      BEGIN
      
        DBMS_CLOUD.COPY_DATA(
      
          table_name    => 'YOUR_TARGET_TABLE',
      
          credential_name => 'GOOGLE_CLOUD_CRED',
      
          file_uri_list => 'https://exadbtest.storage.googleapis.com/employee.csv', -- Or a list of files
      
          format        => json_object('type' value 'CSV', 'skipheaders' value '1') -- Specify file format options
      
        );
      
      END;
      
      /

      Para obtener más información sobre los parámetros, consulte COPY_DATA Procedure.

   5. Una vez que haya importado correctamente los datos de Google Cloud Storage a la base de datos de Exadata, puede ejecutar esta sentencia y verificar los datos de la tabla.

      SELECT * FROM emp;

2. Importación de datos mediante pump de datos

   El comando de importación se puede ejecutar en el cluster de VM o en una máquina virtual externa con acceso autorizado de SQL*Plus a la base de datos de destino.

   1. Cree un archivo de parámetros imp_gcp.par con el siguiente contenido:

      directory=DATA_PUMP_DIR
      credential=GCP_CRED
      schemas=emp
      remap_tablespace=USERS:DATA
      dumpfile=https://exadbtest.storage.googleapis.com/emp.dmp

   2. Ejecute la importación desde el cliente o el cluster de VM de Exadata. Asegúrese de que el cliente de Oracle está instalado y de que puede conectarse a la base de datos de Exadata:

      impdp userid=ADMIN@demo_db parfile=imp_gcp.par

   3. Una ejecución correcta carga los datos en Oracle Database. Ejemplo de un mensaje de finalización correcta:

      Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed.

1. Introduzca un nombre único en el campo ID de instancia de la instancia de Google Cloud Filestore. El ID debe contener letras en minúscula, números y guiones. Debe empezar por una letra.
2. El campo Descripción es opcional.
3. En la sección Configurar nivel de servicio, seleccione un nivel de servicio adecuado en función de los requisitos de carga de trabajo de migración. En la sección Tipo de instancia, seleccione el tipo de instancia. El tipo de instancia afecta a la capacidad, el rendimiento, la escalabilidad, la durabilidad y el costo.
4. Seleccione el tipo de almacenamiento según sus requisitos.
5. Después de seleccionar el tipo de almacenamiento, introduzca el valor de capacidad en el campo Capacidad.
   Para obtener un mejor rendimiento y un menor costo de red, coloque la instancia en la misma región que las máquinas virtuales que se conectarán a ella. La elección es permanente.

   1. Seleccione el rango de capacidad que se ajuste a su sistema de archivos.
   2. Configure el rendimiento en función de la carga de trabajo y la escala.
6. Seleccione la región y la zona en la que se creará la instancia de Google Cloud Filestore. Esto debe coincidir con la ubicación de red de los hosts de base de datos que accederán al recurso compartido de archivos.
7. En la sección Configurar conexiones, seleccione la red y el rango de direcciones que los clientes utilizarán para acceder a la instancia.
   • En la lista desplegable Red de VPC, seleccione la VPC.
   • En la sección Rango de IP asignadas, seleccione la opción Usar un rango de IP asignado automáticamente (recomendado). Este rango de IP se utilizará para crear subredes.
8. En la sección Configurar el recurso compartido de archivo, introduzca el nombre del recurso compartido de archivo en el campo. La elección es permanente. Puede usar letras en minúsculas, números y caracteres de subrayado. El archivo compartido debe empezar por una letra. Seleccione el control de acceso.
9. Las secciones Crear etiquetas y Etiquetas son opcionales.
10. Revise la información y seleccione el botón Crear.

1. Para instalar las utilidades NFS antes del montaje, ejecute el siguiente comando:

   # RHEL / CentOS 
   sudo yum update && sudo yum install nfs-utils

1. Cree un directorio en el cliente donde se montará el recurso compartido Filestore:

   sudo mkdir -p /mnt/filestore-share

Para montar un recurso compartido de archivos NFS, utilice el comando mount. Sustituya FQDN or IP Address of Fileshare y Mount Path por sus valores. En el siguiente ejemplo, los valores se utilizan desde la sección de punto de montaje NFS del recurso compartido de archivos de Google Cloud Filestore testfs.

Si ha configurado un nombre de dominio completo (FQDN), puede usarlo en lugar de la dirección IP. Consulte la sección Migración a una base de datos de IA autónoma para obtener orientación sobre la creación de un FQDN y la configuración de la resolución de DNS.

1. Ejecute el siguiente comando después de actualizar con los valores:

   sudo mount -o rw <FQDN or IP Address of Fileshare> <Mount Path>

   Por ejemplo:

   sudo mount -o rw 10.210.123.202:/testfs /mnt/filestore-share

1. Para comprobar que el recurso compartido Filestore esté montado, ejecute el siguiente comando:

   df -h --type=nfs

2. Después de montar el recurso compartido base, puede crear y montar subdirectorios:

   sudo mkdir -p /mnt/filestore-share/subdir
   sudo mount IP_ADDRESS:/share_name/subdir /mnt/filestore-share/subdir

3. Para activar el montaje automático, agregue la entrada de montaje a /etc/fstab. Para el montaje dinámico, utilice autofs. Para obtener más información sobre todas las opciones de montaje, consulte la documentación de Mounting Filestore file share.

1. Utilice el almacén de archivos montado como ubicación temporal compartida para los archivos de volcado de Oracle Data Pump (.dmp).
2. Coloque archivos de exportación grandes de entornos locales u otros entornos directamente en el recurso compartido Filestore. Por ejemplo:

   /mnt/filestore-share/datapump/

3. Ejecute impdp desde los nodos de base de datos de Exadata o las máquinas virtuales de cliente, haciendo referencia a la ruta de montaje local en lugar de a las URL de Google Cloud Storage.
4. Ejemplo de comando de un cliente montado o un cluster de VM de Oracle Exadata.

   impdp system/password@exadata_pdb \
     directory=DATA_PUMP_DIR \
     dumpfile=/mnt/filestore-share/datapump/sales_export.dmp \
     logfile=import.log \
     schemas=SALES_APP \
     parallel=8

1. Active las funciones necesarias como SYS:

   
   ALTER DATABASE FORCE LOGGING;
   ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(<primary_unique_name>,<standby_unique_name>)' SCOPE=BOTH;
   ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH;

2. Agregar redo logs en espera (por ejemplo, para 3 grupos en línea, agregar 4 grupos en espera).

   ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 4 ('/u01/oradata/standby_redo04.log') SIZE 100M;
   -- Repeat for additional groups.

3. Cree una copia de seguridad de la base de datos primaria mediante RMAN (incluir archive logs para la sincronización):

   CONNECT TARGET / BACKUP DATABASE FORMAT '/backup/db_%U' PLUS ARCHIVELOG FORMAT
         '/backup/arc_%U'; BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT
         '/backup/standby_ctl.ctl';

4. Copie los archivos de copia de seguridad, el archivo de contraseñas (orapw<sid>) y el archivo de parámetros (init.ora o spfile) en el servidor de destino.

1. Instalar el software de Oracle (coincidencia o versión superior para la actualización).
2. Cree los directorios necesarios:

   mkdir -p /u01/oradata/<db_name>mkdir -p /u01/fra/<DB_UNIQUE_NAME_upper>mkdir -p /u01/app/oracle/admin/<db_name>/adump

3. Edite el archivo de parámetros copiado en espera:
   • Defina DB_UNIQUE_NAME en el valor en espera.
   • Defina FAL_SERVER en el nombre de TNS principal.
   • Ajuste las rutas si es necesario. Por ejemplo, CONTROL_FILES, DB_RECOVERY_FILE_DEST.
4. Inicie la instancia en espera en NOMOUNT:

   CREATE SPFILE FROM PFILE='/path/to/init.ora';STARTUP NOMOUNT;

1. Utilice RMAN para duplicar la base de datos de la base de datos activa:

   CONNECT TARGET sys/<password>@primary_tns CONNECT AUXILIARY sys/<password>@standby_tns
             DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER
             NOFILENAMECHECK;

   Alternativa: si utiliza archivos de copia de seguridad, duplique la base de datos para la base de datos en espera desde una ubicación de copia de seguridad:

   DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/backup'
       NOFILENAMECHECK;

2. En espera, inicie la recuperación gestionada:

   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

1. En primario, defina el registro remoto:

   ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=<standby_tns> ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=<standby_unique_name>' SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;ALTER SYSTEM SET FAL_SERVER='<standby_tns>' SCOPE=BOTH;

2. En espera:

   ALTER SYSTEM SET FAL_SERVER='<primary_tns>' SCOPE=BOTH;

3. (Opcional) Active Data Guard Broker para una gestión más sencilla:
   • Defina DG_BROKER_START=TRUE en ambos.
   • Creación de la configuración:

     DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS <primary_unique_name> CONNECT IDENTIFIER IS <primary_tns>;

   • Agregar en espera:

     DGMGRL> ADD DATABASE <standby_unique_name> AS CONNECT IDENTIFIER IS <standby_tns>;

   • Active la configuración:

     DGMGRL> ENABLE CONFIGURATION;

1. En primaria, fuerce los cambios de log:

   ALTER SYSTEM SWITCH LOGFILE;

2. En espera, compruebe el estado de aplicación:

   SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM v$managed_standby;

   Busque MRP0 aplicando logs.

3. Compruebe si hay huecos:

   SELECT * FROM v$archive_gap;

   La salida no debe devolver ninguna fila.

4. Demora del monitor:

   SELECT NAME, VALUE FROM v$dataguard_stats WHERE NAME = 'apply lag';

Permita tiempo para la sincronización completa antes de la migración.

1. Detenga las aplicaciones conectadas a la base de datos principal (el tiempo de inactividad mínimo comienza aquí).
2. Verifique que no haya espacios y detenga la recuperación en espera:

   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3. Uso de Broker (recomendado):

   DGMGRL> SWITCHOVER TO <standby_unique_name>;

   • Alternativa manual:
     • En principal:

       ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

     • En la base de datos principal antigua (ahora en espera):

       STARTUP MOUNT; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

     • En la nueva base de datos principal (antigua en espera):

       ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY WITH SESSION SHUTDOWN; ALTER DATABASE OPEN;

4. Verifique los roles:

   SELECT DATABASE_ROLE FROM v$database;

   El nuevo principal debe ser PRIMARY.

5. Redirigir aplicaciones a la nueva principal.
6. (Opcional) Retire la base de datos principal antigua o manténgala en espera nueva.