Mostrando entradas con la etiqueta Data Pump. Mostrar todas las entradas
Mostrando entradas con la etiqueta Data Pump. Mostrar todas las entradas

28 noviembre 2020

Copias de seguridad gestionadas por el usuario en Oracle

 

Empezaremos esta entrada en el blog, con la ortodoxia de una definición canónica de copia de seguridad (backup).

Definición: La copia de seguridad es una copia real y coherente de los datos de la base de datos que podría usarse para reconstruir los datos después de un incidente.

Hay dos tipos de respaldo
  • Copia de seguridad física
  • Copia de seguridad lógica


Copia de seguridad física (Physical Backup)

Copia de todos los archivos de datos físicos necesarios para realizar la restauración y recuperación de la base de datos,
Este tipo de copia de seguridad incluye una copia de los archivos siguientes
  • Archivos de información
  • Controlar archivos
  • Archivos de parámetros
  • Archivos de registro archivados
Las diferentes opciones para realizar copias de seguridad físicas son
  • Técnicas gestionadas por el usuario
  • RMAN (Recovery Manager)

Copia de seguridad lógica (Logical Backup)

Oracle utiliza la bomba de datos de Oracle para permitirnos generar una copia de seguridad lógica que se puede utilizar para migrar datos, incluso hacer una recuperación parcial o total de la base de datos.
  • exp / expdp
  • imp / impdp

Diferencia entre restauración y recuperación

Restaurar: acto que implica la restauración de todos los archivos que serán necesarios para recuperar su base de datos a un estado consistente. por ejemplo, copiando todos los archivos de respaldo desde una ubicación de respaldo como TAPE o DISK

Recuperar: es un proceso para aplicar todos los registradores de transacciones en el registro de archivo, avanzando su base de datos hasta un punto en el tiempo.

Copias de seguridad gestionadas por el usuario

Backpup en Frio

Esta es la única forma posible para que el DBA realice una copia de seguridad coherente de la base de datos independientemente del modo de la base de datos (archivelog o noarchivelog). A continuación se explican los pasos:
  • Si la base de datos se está ejecutando, bájela completamente en un modo consistente (usando el apagado (solo NORMAL / INMEDIATO / TRANSACCIONAL). Esto asegurará que el encabezado de todos los archivos de la base de datos se actualice al mismo SCN
  • Copia de seguridad de todos los archivos de datos, archivos de control, archivos de parámetros mediante el comando de copia del sistema operativo
  • Iniciar la base de datos
  • Archive todos los registros de rehacer no archivados utilizando el siguiente comando y cópielos en la ubicación de la copia de seguridad.
alter tablespace SIGE_TBS offline normal;

Copia de seguridad de datos sin conexión (Offline)

Suponga que desea realizar una copia de seguridad sin conexión de uno o más espacios de tabla, el método de copia de seguridad sin conexión le ayudará a lograr lo mismo, tenga en cuenta que el espacio de tabla SYSTEM y el espacio de tabla UNDO con deshacer activo no se pueden desconectar.
suponga que el espacio de tabla es SIGE_TBS:

  • Identifique todos los archivos de datos asociados con el espacio de tabla mediante la vista dba_data_files

select tablespace_name,file_name from dba-data_files from dba_data_files where tablespace_name='SIGE_TBS';

  • Ponga el espacio de tabla fuera de línea usando la prioridad normal (no use temporal e inmediato, requerirá recuperación en el momento de poner el espacio de tabla en línea)

alter tablespace SIGE_TBS offline normal;

  • Haga una copia de seguridad de todos los archivos de datos relacionados con el espacio de tabla mediante el comando de copia del sistema operativo.
  • Ponga el tablespace en línea.

alter tablespace SIGE_TBS online;

Archive todos los registros de rehacer no archivados y copie el registro archivado en la ubicación de la copia de seguridad.

alter system archive log current;

Backups en caliente

Esto se ha introducido en la versión 6 de Oracle, pero inicialmente estaba vinculado solo al espacio de tabla, a partir de la versión 10 también incluían toda la base de datos. Esto nos permite realizar copias de seguridad en caliente de la base de datos o el espacio de tabla sin necesidad de cerrar la base de datos.
Al realizar una copia de seguridad en caliente, Oracle deja de registrar puntos de control en todos los archivos de datos asociados.
A continuación se muestran dos cosas que suceden internamente mientras la base de datos se pone en modo BEGIN BACKUP:

  • Se establece una bandera de respaldo activo en el encabezado del archivo de datos
  • Se produce un punto de control, parpadeo de todos los bloques sucios de la memoria al disco, sincronizando todos los encabezados de los archivos de datos al mismo SCN y congelando los encabezados para lograr coherencia, protección y capacidad de recuperación.
Se pueden realizar copias de seguridad en caliente en toda la base de datos, el espacio de tabla o incluso a nivel de contenedor, esto requiere un proceso de recuperación después de que se restaure la copia de seguridad, por lo que siempre realice una copia de seguridad de todos los archivos de registro archivados necesarios.

Copia de seguridad en caliente de toda la base de datos
Para realizar este tipo de copia de seguridad, debemos poner nuestra base de datos en modo de copia de seguridad usando 'alter database begin backup;'
Este es el tipo más común de copia de seguridad administrada por el usuario que utiliza DBA en todo el mundo.
A continuación se muestran los pasos:
  • Coloque la base de datos en modo de respaldo.
alter database begin backup;
  • Haga una copia de seguridad de todos los archivos de datos y archivos de parámetros utilizando el comando de copia del sistema operativo-
  • Saque la base de datos del modo de respaldo.
alter database end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo.
  • Crear copia del archivo de control como seguimiento.
alter system archivelog current;
  • modifique el archivo de control de copia de seguridad de la base de datos a '/control_file.trc;
alter system archive log current;


Copia de seguridad en caliente de la base de datos de contenedores
Como se introdujo en Oracle 12c, puede realizar una copia de seguridad administrada por el usuario de toda la base de datos del contenedor o del único PDB raíz o individual.

Base de datos de contenedores completa:

A continuación se muestran los pasos mencionados:
  • Inicie sesión en la base de datos utilizando un usuario que tenga privilegios de sysdba o sysbackup.
sqlplus /nolog

connect system@container1

  • Coloque su base de datos en modo de respaldo.ç
alter database begin backup;
  • Modificar la base de datos comenzar la copia de seguridad;
select file_name from dba_data_files;
  • Identifique todas las bases de datos relacionadas con la base de datos del contenedor usando el siguiente comando.
select file_name from dba_data_files;
  • Copie toda la base de datos usando el comando de copia del sistema operativo.
  • Saque la base de datos del modo de respaldo.
alter database end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo.
alter system archivelog current;
  • Crear copia del archivo de control como seguimiento.
alter database backup controlfile to '/control_file.trc;

ROOT solo o PDB individual

A continuación se muestran los sencillos pasos para completar la copia de seguridad en caliente de root contenedor o base de datos conectable individual.

  • Conectar a la raíz o base de datos conectable individuo con usuario tenga privilegios SYSDBA o sysbackup.
sqlplus /nolog
connect system

alter session set container= tech_pdb;

  • Identifique todos los archivos de datos que forman parte de PDB usando la vista dba_data_files.

select file_name from dba_data_files;
  • Coloque la base de datos conectable en modo de respaldo.
alter pluggable database tech_pdb begin backup;
  • Copie todos los archivos de datos usando el comando de copia del SO.
  • Saque la PDB del modo de inicio de copia de seguridad.
alter pluggable database tech_pbd end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo
alter system archivelog current;
  • Crear una copia del archivo de control como seguimiento

alter database backup controlfile to '/control_file.trc;

Controlar la copia de seguridad de archivos
Hay dos formas de recuperar el control
  • Copia de seguridad binaria
  • Copia de seguridad de archivos de texto
Tener una copia de seguridad válida del archivo de control de una base de datos es crucial para la recuperación exitosa de la base de datos.

Copia de seguridad binaria
Se puede realizar una copia binaria del archivo de control mediante una declaración SQL. Esta copia contiene información adicional, como el historial de registro de rehacer archivado, rango fuera de línea para espacios de tabla de solo lectura y fuera de línea, entradas de archivos temporales y conjuntos de respaldo de RMAN y copias de datos.
comando para tomar una copia de seguridad binaria.

alter database backup controlfile to '';

Copia de seguridad de archivos de texto
Este tipo de copia de seguridad contiene una instrucción create controlfile basada en el archivo de control actual en uso. Este tipo de copia de seguridad se puede realizar mientras la base de datos está en modo de montaje o abierto. Esto se genera como archivo de seguimiento y se puede modificar fácilmente.
A continuación se muestran algunas declaraciones utilizadas para crear una copia de seguridad basada en texto del archivo de control.

1. alter database backup controlfile to trace;
2. alter database backup controlfile to trace resetlogs;
3. alter database backup controlfile to trace noresetlogs;
4. alter database backup controlfile to trace as '';
5. alter database backup controlfile to trace as '' reuse;
6. alter database backup controlfile to trace as '' resetlogs;
7. alter database backup controlfile to trace as '' noresetlogs;

16 octubre 2020

Nuevas características en Oracle database 19c



Esta versión de la base de datos viene con algunas mejoras interesantes para hacer su trabajo más rápido y más fácil. Si bien el enfoque principal de este ciclo de desarrollo ha sido la estabilidad, hay algunas características nuevas enfocadas en la automatización y optimización para el cliente. Veamos algunas de estas mejoras.
  • Redireccionamiento DML de Active Data Guard.
  • Indexación automática.
  • Tablas híbridas particionadas (Big Data).
  • Compatibilidad con JSON.
  • Más estabilidad y disponibilidad.

Redireccionamiento DML de Active Data Guard.



las bases de datos de respaldo en espera son una parte necesaria de muchos planes de recuperación de desastres, pero pueden ser costosas de llevar como potencia de procesamiento inactiva. Oracle ha trabajado para hacer que estas bases de datos sean más valiosas en su estrategia desde el lanzamiento de Active Data Guard en 11c. Esa característica, que le permite utilizar los recursos de la base de datos en espera para ejecutar informes y copias de seguridad, obtiene una actualización en 19c. Esta versión agrega la capacidad de ejecutar transacciones mediante la creación de un redireccionamiento inmediato a la base de datos principal. Las transacciones que se ejecutan en la copia de seguridad se envían y almacenan inmediatamente en las bases de datos primarias y luego en las de respaldo. No importa si sus bases de datos están en la nube o en la versión local, con Active Data Guard Redirect, ahora puede usar su base de datos en espera para obtener aún más ventajas.

Indexación automática.

La indexación de elementos lleva tiempo y puede significar una gran cantidad de trabajo para su equipo de TI. Con la indexación automática, el 19c de Oracle utiliza algoritmos de aprendizaje automático para identificar elementos, mapear y validar las opciones de indexación e indexar automáticamente para usted. Estos algoritmos aprenden sobre la marcha, por lo que solo se vuelven más eficientes y precisos en el tiempo. La automatización es la clave para mejorar el proceso. Con esta herramienta puede ahorrar tiempo y recursos al automatizar su indexación y enfocar sus energías en otros lugares.

Tablas híbridas particionadas.

Big Data significa almacenamiento grande, y con más y más información almacenada durante largos períodos de tiempo, es esencial encontrar las opciones más eficientes para manejar la creciente carga. Las tablas particionadas híbridas de Oracle se resienten al permitirle particionar los datos y luego seleccionar qué particiones deben almacenarse en la base de datos para acceder a las consultas y cuáles deben guardarse como archivos de solo lectura en ubicaciones externas. De esa manera, puede minimizar la carga en la base de datos en vivo mientras mantiene datos importantes para el almacenamiento y el acceso a largo plazo.

Cuarentena de consulta.



El desempeño general de un data mart o de un almacén de datos puede verse afectado cuando un usuario ejecuta una consulta que consume una cantidad excesiva de recursos de E/S y de computación. Oracle Database 19c “puede poner estas consultas en cuarentena automáticamente y garantizar que no se vuelvan a ejecutar”, esto da como resultado un desempeño uniforme para todos los usuarios de la base de datos. Se acabó ralentizar una instancia en Producción por ejecutar la "Query de la muerte".

Base de datos "JSON friendly".



Esta versión también incluye numerosas mejoras de JSON, así como funciones para optimizar inserciones de datos, estadísticas en tiempo real y más. Los servicios de base de datos de Oracle están diseñados teniendo en cuenta las necesidades del cliente. La compatibilidad de Oracle Database con JSON se incluyó a partir de Oracle Database 12c, con el almacenamiento nativo de documentos JSON y el acceso SQL, y continuó en 18c, con los análisis de alto desempeño para los documentos JSON, como si se hubiera realizado la ingesta de datos JSON en las filas y columnas de tabla de la base de datos.

Se ha mejorado y simplificado la sintaxis para nuestras funciones de JSON y se ha introducido la capacidad de realizar una actualización parcial de JSON, por lo que es posible actualizar un solo atributo de un gran documento JSON, en lugar de actualizar todo.

Más estabilidad y disponibilidad.

Las nuevas características son importantes en cada una de las versiones de Oracle Database. La estabilidad para las aplicaciones y las instalaciones de base de datos on-premises también es importante, y Oracle Database 19c también ofrece dicha estabilidad.

La estabilidad es uno de los principales objetivos de Oracle Database 19c; se trata de una versión con soporte a largo plazo hay clientes de productos "on-premises" cuentan con ciclos de actualización prolongados, y esta versión, Oracle Database 19c, es la que mucha gente estaba esperando para poder realizar la actualización a partir de Oracle Database 11g u Oracle Database 12c.

Para obtener más información sobre las bases de datos 19c de Oracle y una lista completa de las nuevas funciones, visite la página de Características de la base de datos de Oracle.

Migrar la base de datos a Oracle Autonomous Database Cloud

 

Data Pump, SQL Loader, DBMS_CLOUD, GoldenGate

En esta entrada el blog vamos a dar una descripción general de alto nivel de las opciones disponibles para migrar la base de datos de On-Premise a Autonomous Database Cloud.
Primero, echaremos un ojo a las diferentes opciones disponibles para cargar los datos.

Opciones de carga de datos:

Cuando migra la base de datos a la base de datos autónoma, hay dos opciones disponibles para cargar datos:
  • Desde "on-premise": puede cargar directamente sus datos desde su servidor local a la base de datos autónoma.
  • Desde Object Storage Cloud: también puede cargar sus datos en Cloud Object Storage primero y luego migrar a la base de datos autónoma desde Object Storage Cloud. Este es un proceso rápido para la migración de bases de datos.

Diferentes métodos para migrar a la nube de base de datos autónoma:

Ahora, llegando a los diferentes métodos disponibles para migrar la base de datos de On-Premise a Autonomous Database Cloud, existen principalmente cuatro métodos de migración:
  • Usando el paquete DBMS_CLOUD
  • Uso de Data Pump
  • Uso de SQL Loader
  • Uso de Oracle GoldenGate

Usando DBMS_CLOUD:



El paquete DBMS_CLOUD admite la carga desde archivos en los siguientes servicios en la nube: Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure Object Storage Classic, Azure Blob Storage y Amazon S3. Para cargar datos desde archivos en la nube, primero debe almacenar sus credenciales de almacenamiento de objetos en su Autonomous Data Warehouse y luego usar el procedimiento DBMS_CLOUD.COPY_DATA para cargar los datos.
A continuación se muestra el proceso de migración de alto nivel utilizando DBMS_CLOUD:
  • Copia todos los archivos de datos (datafiles) en Object Storage on Cloud.
  • Almacena sus credenciales de almacenamiento de objetos en su base de datos autónoma (ADB).
  • Copia el archivo de datos en una tabla existente usando:
            DBMS_CLOUD.COPY_DATA
  • Verifica el estado de la operación.

Utilizando Data Pump:

Oracle Data Pump proporciona un movimiento de datos masivo muy rápido entre las bases de datos de Oracle y el almacén de datos autónomo. Con este método, puede importar datos de archivos de Data Pump guardados en:
  • Oracle Cloud Infrastructure Object Storage
  • Microsoft Azure
  • AWS S3
  • Oracle Cloud Infrastructure Object Storage Classic. 
Puede guardar sus datos en su Cloud Object Store y usar Oracle Data Pump para cargar datos en Autonomous Data Warehouse. A continuación se muestra el proceso de migración de alto nivel utilizando Oracle Data Pump:
  • Exporta datos en el modo de esquema.
  • Copia los archivos de volcado en el objeto Storage on Cloud.
  • Almacena las credenciales de almacenamiento de objetos en ADB.
  • Importa utilizando el método impdp.
  • Consulta los archivos de "log" para ver si hay algún problema.

Usando SQL Loader:

Puede utilizar Oracle SQL Loader para cargar datos desde archivos locales en su máquina a Oracle Autonomous Data Warehouse. El uso de SQL Loader es adecuado para cargar pequeñas cantidades de datos, ya que el rendimiento de la carga depende del ancho de banda de la red entre su cliente y Autonomous Data Warehouse. A continuación se muestra el proceso de migración de alto nivel utilizando SQL Loader:

  • Configura el "Wallet"de conexión y las variables.
  • Reúne uno o más archivos de datos.
  • Crea un archivo de control (esto es opcional).
  • Crea una tabla en la base de datos de destino.
  • Carga utilizando SQL Loader.
  • Comprueba los archivos de registro, incorrectos y descartados.

Usando Oracle GoldenGate:

También puede utilizar GoldenGate para replicar datos en Autonomous Data Warehouse utilizando Oracle GoldenGate On-Premises y Oracle GoldenGate Cloud Service. 

Asegúrese de utilizar las versiones 12.3.0.1.2 y posteriores de Oracle GoldenGate On-Premises como fuente, ya que solo estas versiones están certificadas con Oracle Autonomous Data Warehouse Cloud

Otras fuentes pueden ser Oracle Database Cloud Service u Oracle Exadata Cloud Service en Oracle Cloud. Sin embargo, no puede configurar Oracle Autonomous Data Warehouse Cloud Database como una base de datos de origen para Oracle GoldenGate On-Premises y solo las réplicas no integradas son compatibles con Oracle Autonomous Data Warehouse Cloud. A continuación se muestra el proceso de migración de alto nivel utilizando Oracle GoldenGate:

  • Configura la base de datos autónoma para la replicación creando el esquema requerido, las tablas de destino, el nuevo usuario de destino, etc.
  • Obtén las credenciales del cliente de Autonomous Database.
  • Configura Oracle GoldenGate On-Premises para la replicación transfiriendo el archivo zip de las credenciales del cliente, configurando sqlnet.ora y tnsnames.ora, etc.
  • Configura Oracle GoldenGate Manager y las réplicas no integradas para entregar a la base de datos autónoma.

Se trata de la migración a una base de datos autónoma y los métodos disponibles para la misma en pocas palabras.