10 febrero 2021

Auditoría de la base de datos Oracle

 

La auditoría de la base de datos es la actividad de monitorear y registrar las acciones configuradas de la base de datos de los usuarios de la base de datos y los usuarios que no lo son, para garantizar la seguridad de las bases de datos.

Un administrador puede realizar auditorías en acciones individuales, como el tipo de declaración de lenguaje de consulta estructurado (SQL) ejecutada, o en combinaciones de datos que pueden incluir el nombre de usuario, la aplicación o la marca de tiempo, por ejemplo. Los auditores deben auditar tanto las actividades exitosas como las fallidas, e incluir o excluir a usuarios específicos de la auditoría:

La auditoría adecuada de una base de datos garantizará la protección de la base de datos, lo que significa que la instalación de la base de datos y sus funciones, la cuenta predeterminada, los parches, los servicios, la política de contraseñas, la política de bloqueo de cuentas y la política de auditoría han demostrado que la auditoría es un proceso continuo.

Los principales tipos de actividades de riesgo incluyen:

  • Error: no mantener u operar la base de datos como se requiere conduce a la divulgación accidental de información, y los cambios no autorizados dan lugar a divulgaciones, inserciones, actualizaciones o eliminaciones accidentales y no autorizadas.
  • Uso indebido: no mantener los derechos de acceso a la base de datos conduce al abuso del acceso privilegiado y la filtración de información.
  • Acción maliciosa: si no se mantiene una configuración lógica y segura de la base de datos, se produce el robo de datos o un ataque de denegación de servicio (DoS).

Vulnerabilidades comunes encontradas en ataques a bases de datos

Muchos ataques comienzan con la ingeniería social:

  • El phishing es un método de fraude por correo electrónico en el que el perpetrador envía correos electrónicos de apariencia legítima en un intento de recopilar información personal y financiera de los destinatarios. Por lo general, los mensajes parecen provenir de sitios web conocidos y confiables. Los sitios web que frecuentemente son falsificados por phishers incluyen PayPal, eBay, MSN, Yahoo y Best Buy, por ejemplo.
  • La inyección SQL es una técnica que se utiliza para aprovechar las vulnerabilidades de entrada no validadas para pasar comandos SQL a través de una aplicación web para su ejecución por una base de datos back-end. Los atacantes aprovechan el hecho de que los programadores a menudo encadenan comandos SQL con parámetros proporcionados por el usuario y, por lo tanto, pueden incrustar comandos SQL dentro de estos parámetros. El resultado es que el atacante puede ejecutar consultas SQL arbitrarias y / o comandos en el servidor de base de datos back-end a través de la aplicación web.
  • La exfiltración de datos es la copia, transferencia o recuperación no autorizada de datos de una computadora o servidor. La exfiltración de datos es una actividad maliciosa realizada a través de diversas técnicas, generalmente por ciberdelincuentes a través de Internet u otra red. La exfiltración de datos también se conoce como extrusión de datos, exportación de datos o robo de datos.
  • El servidor de ensayo es un servidor que permite ensamblar, implementar y probar un software o un sitio web en una instancia de servidor, similar al servidor de producción. Normalmente, el software o un sitio web se implementa en el servidor de ensayo desde el servidor de desarrollo cuando se completa el desarrollo. Un servidor intermedio ayuda a identificar el comportamiento, la experiencia y el rendimiento del software o del sitio web, ya que será visible en el servidor de producción. Esto ayuda a los desarrolladores de software o al personal de control de calidad (QA) a identificar y resolver cualquier problema, error, problemas de rendimiento o usabilidad u otros problemas antes de que el software o el sitio web se implemente en el servidor de producción. El servidor intermedio puede ser un servidor de base de datos intermedio, un servidor de sitio web intermedio o un servidor de aplicaciones intermedias, por ejemplo.
El análisis de la configuración de la base de datos es fundamental para determinar las vulnerabilidades y garantizar la auditoría estándar. La auditoría de la base de datos incluye:

  1. Encontrar privilegios y datos confidenciales
  2. Impedir el acceso a los datos
  3. Validar que los mecanismos de detección y alerta estén en su lugar
  4. Hay varios mecanismos disponibles que deben estar en su lugar cuando se configuran las bases de datos, que incluyen:
  • La redacción de datos proporciona una redacción selectiva y sobre la marcha de datos confidenciales en los resultados de las consultas SQL, antes de la visualización de la aplicación, para que los usuarios no autorizados no puedan ver los datos confidenciales. Permite la redacción coherente de las columnas de la base de datos en los módulos de la aplicación que acceden a la misma información de la base de datos. La redacción de datos minimiza los cambios en las aplicaciones porque no altera los datos reales en los búferes, cachés o almacenamiento de la base de datos internos, y conserva el tipo de datos y el formato originales cuando los datos transformados se devuelven a la aplicación. La redacción de datos no tiene ningún impacto en las actividades operativas de la base de datos, como copia de seguridad y restauración, actualización y parche, y en clústeres de alta disponibilidad.
  • El enmascaramiento de datos confunde los datos confidenciales reemplazándolos con otros datos, generalmente caracteres que cumplirán los requisitos de un sistema diseñado para probar o seguir funcionando con los resultados enmascarados. El enmascaramiento garantiza que partes vitales de la información de identificación personal (PII), como los primeros cinco dígitos de un número de seguro social, se oculten o se desidentifiquen.
  • El cifrado de datos implica convertir y transformar datos en texto cifrado codificado, a menudo ilegible, utilizando algoritmos y cálculos matemáticos no legibles. Restaurar el mensaje requiere un algoritmo de descifrado correspondiente y la clave de cifrado original.

Pasos de auditoría de la base de datos

Se deben seguir los siguientes pasos para la auditoría de la base de datos.

Paso 1: determinar si las cuentas predeterminadas se han modificado o desactivado
Las cuentas de Oracle privilegiadas predeterminadas siguen siendo el problema de mayor riesgo que se encuentra comúnmente. Es un problema fácil de solucionar y prevenir. Después de la instalación, Oracle tiene varias cuentas predeterminadas, cada una con un valor predeterminado predeterminado. Después de la instalación de la base de datos, el asistente de configuración de la base de datos de Oracle (DBCA) bloquea automáticamente y expira la mayoría de las cuentas de usuario predeterminadas de la base de datos. Además, DBCA cambia la cuenta SYSTEM al valor especificado durante la rutina de instalación.

Si una base de datos de Oracle se instala manualmente, el DBCA nunca se ejecuta y esas peligrosas cuentas con privilegios predeterminados nunca se bloquean ni caducan. Por defecto, su contraseña es la misma que su nombre de usuario. Estas serán las primeras credenciales que un hacker intentará utilizar para conectarse a la base de datos. Como práctica recomendada, cada una de estas cuentas debe configurarse con una contraseña única segura y, si no se requiere una cuenta, debe bloquearse y caducar.




Paso 2: auditar la solidez de Oracle Database SID
El ID del sistema de Oracle (SID) es un valor único que se requiere para que todos los clientes se conecten a la base de datos de Oracle. Debido a que debe ser única, no puede haber más de una base de datos con el mismo SID en el mismo servidor Oracle.

Si una conexión de cliente utiliza un SID incorrecto para conectarse a una base de datos de Oracle, recibirá el mensaje "ORA-12505: TNS: el oyente no conoce actualmente el SID proporcionado en el descriptor de conexión". Sin embargo, los SID pueden ser de fuerza bruta. Existen numerosas herramientas para forzar el SID de Oracle, incluidos los módulos Metasploit, las pruebas de aceptación operativa (OAT) y SIDGuess.

La clave para frustrar los ataques de fuerza bruta de SID es seleccionar un SID que sea fuerte. Al crear un SID de Oracle, la selección debe:

  • No ser una palabra de diccionario
  • Tener al menos 10 caracteres de longitud
  • Incluya al menos un carácter especial
La incorporación de estos elementos asegura que el SID sea fuerte, es decir, difícil para un atacante utilizar la fuerza bruta.

¿Por qué es importante un SID fuerte cuando el SID se almacena como un valor de texto sin cifrar dentro del archivo de configuración del cliente de Oracle, TNSNAME.ora, en cada sistema que está configurado para conectarse a la base de datos? Es importante porque siempre que un atacante pueda comprometer al menos un sistema que está configurado para conectarse a la base de datos de Oracle, obtener el SID del archivo TNSNAMES.ORA es trivial. Sin embargo, es importante considerar los casos en los que el atacante es externo a la organización y ha comprometido un solo host que no tiene configurada una conexión de cliente de Oracle. Un SID sólido no impedirá por sí mismo que los piratas informáticos obtengan una conexión con la base de datos Oracle de una organización, pero es una buena práctica como parte de un enfoque de seguridad de defensa en profundidad.


Paso 3: auditar las actualizaciones de parches críticos de Oracle
Esta es una de esas recomendaciones de mejores prácticas de seguridad con las que la mayoría de las organizaciones luchan comúnmente. Dependiendo del esquema de la base de datos, las actualizaciones de parches críticos (CPU) de Oracle pueden tener un impacto significativo en la base de datos de Oracle, lo suficientemente significativo como para que la organización tenga que realizar pruebas de regresión exhaustivas para garantizar que la aplicación de las últimas CPU de Oracle no afecte la funcionalidad de la base de datos.

Oracle lanza CPU trimestralmente el martes más cercano al día 17 del mes. Oracle tiene una página de boletín especial que describe todas las actualizaciones y advertencias de parches críticos de Oracle más recientes.2 Afortunadamente, las CPU son de naturaleza acumulativa. Uno puede simplemente instalar la última CPU de Oracle para obtener todos los parches de seguridad desde el lanzamiento inicial del producto.

La clave para un proceso de parches de CPU eficaz es crear un proceso de prueba de regresión reglamentado que corresponda a los cuatro lanzamientos programados de Oracle cada año. Incluso en organizaciones con los procesos de prueba de regresión más estrictos, las CPU generalmente se pueden diseñar de tal manera que se puedan aplicar no más de tres meses después de la última versión de la CPU. Además, todos los administradores de bases de datos deben registrarse en el servicio de asesoramiento de alertas de seguridad por correo electrónico de Oracle3 para garantizar la notificación oportuna de los parches y alertas de seguridad de Oracle.

También existe un mecanismo que Oracle emplea si se descubre una vulnerabilidad crítica que justifica la publicación inmediata del parche. Oracle se refiere a los parches lanzados inmediatamente bajo este programa como "alertas de seguridad fuera de horario". Desde que comenzó el programa de CPU en 2005, solo ha habido unas pocas veces en las que Oracle lanzó parches bajo este proceso de emergencia. Las organizaciones deben desarrollar un método para aplicar estos parches lanzados de emergencia, pero dado su bajo volumen histórico, la atención debe centrarse en la aplicación rutinaria de parches de CPU cada trimestre.4

Paso 4: Auditar el rol PÚBLICO para la identificación de privilegios innecesarios
En Oracle, existen rutinas extendidas que permiten a los usuarios con privilegios mínimos ejecutar funciones que de otro modo no podrían ejecutar. Estas rutinas extendidas se denominan paquetes y son aproximadamente equivalentes a los procedimientos almacenados extendidos en Microsoft SQL Server. Un rol especial, llamado PUBLIC, actúa como un rol predeterminado asignado a cada usuario en la base de datos de Oracle. Cualquier usuario de la base de datos puede ejecutar los privilegios otorgados a PUBLIC. Esto se aprovecha comúnmente para la escalada de privilegios de la base de datos.

Estos paquetes y subtipos deben revocarse de PUBLIC y hacerse ejecutables para una aplicación solo cuando sea absolutamente necesario.

Paso 5: Verifique que la auditoría de la base de datos esté habilitada
Para identificar las actividades maliciosas o autorizadas en una base de datos, es importante verificar que las opciones de auditoría de la base de datos estén habilitadas. Para asegurarse de que la auditoría de la base de datos esté habilitada, es necesario realizar las siguientes actividades durante la auditoría de la base de datos:

  • Auditoría de operaciones SYS: de forma predeterminada, las bases de datos de Oracle no auditan los comandos SQL ejecutados por el SYS privilegiado y los usuarios que se conectan con privilegios SYSDBA o SYSOPER. Si se piratea una base de datos, estos privilegios serán el primer objetivo del pirata informático. Afortunadamente, auditar los comandos SQL de estos usuarios privilegiados es muy simple: 
sqlplus> alter system set audit_sys_operations = true scope = spfile.
  • Habilitar la auditoría de la base de datos: de nuevo, de forma predeterminada, la auditoría de Oracle de los comandos SQL no está habilitada. La auditoría debe estar activada para todos los comandos SQL. La auditoría de la base de datos se activa con el parámetro audit_trail: sqlplus> alter system set audit_trail = DB, EXTENDED scope = spfile. (Nota: El comando habilita la auditoría desde la base de datos, pero no la información de la bóveda de la base de datos, en la tabla SYS. AUD $.) En realidad, hay cuatro tipos de auditoría de bases de datos: OS, DB, EXTENDED y XML.
  • Habilite la auditoría en objetos importantes de la base de datos: una vez que se ha habilitado la auditoría, se puede activar para los objetos en los que una pista de auditoría es importante.
Paso 6: Auditoría para garantizar que los activadores de la base de datos para la auditoría de esquemas y los eventos de inicio / cierre de sesión estén configurados
Para auditar eficazmente los cambios de esquema y los eventos de inicio y cierre de sesión, Oracle proporciona activadores de lenguaje de definición de datos (DDL) para auditar todos los cambios de esquema y puede informar el cambio exacto, cuándo se realizó y qué usuario.

  • Activador de inicio de sesión: al usar un activador de inicio de sesión, se pueden enviar eventos de inicio y cierre de sesión en tiempo real a otro sistema. Piense en ello como un demonio syslog para los eventos de su base de datos. El siguiente ejemplo enviaría todos los eventos de inicio y cierre de sesión a un servidor web en tiempo real.
SQL> crear o reemplazar el disparador sec_logon después de iniciar sesión en la base de datos.

  • Activador DDL: mediante los activadores DDL, un administrador de bases de datos de Oracle puede realizar un seguimiento automático de todos los cambios en la base de datos, incluidos los cambios en las tablas, los índices y las restricciones. Los datos de este activador son especialmente útiles para el control de cambios para Oracle DBA. El siguiente ejemplo envía eventos para GRANT, ALTER, CREATE, DROP.
  • Disparador de error: los disparadores de error son mensajes de error de Oracle. Pueden ser útiles para detectar ataques de inyección SQL y otros métodos de ataque.
Paso 7: Auditoría para garantizar que se implemente una solución DAM
Si una organización puede permitirse el gasto adicional de un producto de software adicional, una solución de monitoreo de base de datos puede ser muy útil. Resuelve el problema de no poder monitorear la actividad del DBA a nivel organizacional. También proporciona información útil sobre consultas SQL peligrosas y modificaciones de roles que podrían indicar que un atacante ha comprometido una base de datos. La clave para todas las soluciones de monitoreo de actividad de bases de datos (DAM) es que operan dentro de la memoria del servidor Oracle y operan independientemente de las funciones nativas de auditoría y registro de la base de datos. Para cualquiera que esté familiarizado con los sistemas de detección de intrusiones en la red (IDS), los DAM tienen una función análoga: operan dentro de la capa de la base de datos en el servidor en lugar de en cualquiera de las capas de la red.

Paso 8: Auditoría para garantizar que la administración de contraseñas para todos los inicios de sesión de Oracle esté habilitada
Oracle proporciona una gestión de contraseñas bastante sólida para los inicios de sesión de Oracle. Desafortunadamente, ninguno de estos se aplica en el perfil de cuenta de Oracle predeterminado.

En Oracle, a los inicios de sesión se les asigna una política de cuenta a través de un perfil de Oracle. Cada inicio de sesión se puede aplicar a un solo perfil de Oracle. Si no se especifica ningún perfil de Oracle cuando se crea el inicio de sesión, se le asigna el perfil de Oracle predeterminado.

Paso 9: Verifique para asegurarse de que se realizan evaluaciones regulares de seguridad de la base de datos
Cada configuración segura que se ha discutido podría detectarse fácilmente con una herramienta de vulnerabilidad de base de datos automatizada. Las herramientas automatizadas de vulnerabilidad de bases de datos proporcionan una manera excelente de validar rápidamente las configuraciones seguras de Oracle de una organización. Obviamente, este tipo de herramientas solo son útiles si uno tiene privilegios. Están pensados ​​para que los administradores de bases de datos, auditores y profesionales de la seguridad realicen evaluaciones periódicas. Estas herramientas son propensas a generar falsos positivos y, desafortunadamente, falsos negativos, pero sus beneficios superan con creces el riesgo.

Paso 10: Determine que el tráfico de la base de datos está cifrado
Esta recomendación rara vez se implementa, excepto en las organizaciones más seguras. Oracle admite el cifrado a nivel de red mediante Secure Sockets Layer (SSL), utilizando certificados firmados X.509v3 y cifrado nativo sin certificados.

La conclusión con el cifrado a nivel de red no es solo que los datos confidenciales en tránsito están protegidos cuando se emplea el cifrado, sino también que el SID está protegido. Sin cifrado, el SID se puede enumerar fácilmente mediante ataques man-in-the-middle.

Paso 11: Audite las amenazas y contramedidas a la seguridad adecuadamente
Una organización debe crear una política de seguridad escrita para enumerar las amenazas de seguridad contra las que está tratando de protegerse y las medidas específicas que debe tomar la organización. Las amenazas a la seguridad se pueden abordar con diferentes tipos de medidas:

  • Procedimientos, como exigir a los empleados del centro de datos que muestren credenciales de seguridad
  • Físico, como asegurar computadoras en instalaciones de acceso restringido
  • Técnico, como la implementación de requisitos de autenticación sólidos para sistemas comerciales críticos
  • Relacionado con el personal, como la realización de verificaciones de antecedentes o la investigación de antecedentes de personal clave

Conclusión

Los datos son un recurso muy decisivo para cualquier negocio debido al blindaje; La auditoría periódica de la base de datos nunca debe dejarse al azar ni a soluciones de mosaico. Durante el período de auditoría, las partes interesadas deben identificar que un sistema está configurado según el estándar que garantiza la mitigación del riesgo de datos.

Se debe implementar una solución de auditoría completa e integral que pueda lograr fácilmente cada uno de los siguientes:

  • Auditoría de acceso y autenticación
  • Auditoría de usuarios y administradores
  • Auditoría de actividades sospechosas
  • Auditoría de vulnerabilidades y amenazas
  • Auditoría de cambios
Sin una solución de auditoría que lo abarque todo, las organizaciones ponen en riesgo datos valiosos. Los datos corruptos, inexactos o comprometidos equivalen a pérdida de ingresos, tiempo perdido y relaciones comprometidas con clientes y empleados.

La auditoría es un proceso continuo y continuo sin importar qué sistema o proveedor esté en uso. Incluso los aspectos básicos deben revisarse periódicamente para evitar una falsa sensación de seguridad. La base de datos es un componente sensible en los negocios; por lo tanto, es importante asegurarse de que la base de datos esté configurada correctamente para garantizar la seguridad de los datos comerciales.

20 enero 2021

Oracle Database 12c R2 Nueva función: Cifrado de tablespaces en línea y automática


Transparent Data Encryption, en adelante TDE,  le permite cifrar datos confidenciales, como números de tarjetas de crédito o porcentaje de invalidez, dentro de la base de datos  Oracle 12C.



Oracle Database utiliza autenticación, autorización y mecanismos de auditoria para proteger los datos en la base de datos, pero no en los archivos de datos del sistema operativo donde se almacenan los datos. Para proteger estos archivos de datos, Oracle Database proporciona Transparent Data Encryption (TDE). TDE cifra los datos confidenciales almacenados en archivos de datos. Para evitar el descifrado no autorizado, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos, denominado almacén de claves.

El cifrado transparente de datos (TDE) permite cifrar datos confidenciales tales como números de tarjetas de crédito almacenados en tablas y espacios de tabla. Los datos cifrados se descifran de forma transparente para una aplicación o un usuario de base de datos que tenga acceso a los datos. TDE ayuda a proteger los datos almacenados en medios en caso de sustracción de los medios de almacenamiento o los archivos de datos. Oracle usa mecanismos de autenticación, autorización y auditoría para proteger los datos de la base de datos, pero no los archivos de datos del sistema operativo donde se almacenan datos. Para proteger estos archivos de datos, Oracle proporciona TDE. TDE cifra los datos confidenciales almacenados en los archivos de datos. Para evitar descifrados no autorizados, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos.

Estas son algunas de las ventajas del uso de TDE:

  • Como administrador de seguridad tendrá la tranquilidad de que los datos confidenciales estén protegidos en caso de sustracción de los medios de almacenamiento o de los archivos de datos.
  • La implementación de TDE ayuda a abordar los aspectos de cumplimiento reglamentario relacionados con la seguridad.
  • No es necesario crear desencadenadores ni vistas para descifrar los datos para una aplicación o usuario autorizados. Los datos de las tablas se descifran de forma transparente para la aplicación y el usuario de la base de datos.
  • No es necesario que las aplicaciones y usuarios de base de datos sepan que los datos a los que acceden están almacenados en modo cifrado. Los datos se descifran de forma transparente para las aplicaciones y usuarios de base de datos.
  • No hace falta modificar las aplicaciones para controlar los datos cifrados. La base de datos administra el cifrado y descifrado de datos.
  • Las operaciones de administración de claves están automatizadas. El usuario o la aplicación no necesitan administrar las claves de cifrado.

Oracle 12c

Para obtener más información sobre la configuración del cifrado de espacios de tablas de TDE, consulte la documentación de Oracle.

Configuración manual del TDE
El siguiente procedimiento muestra cómo configurar manualmente TDE.

  • Cree el directorio keystore.
        mkdir $ORACLE_HOME/admin/$ORACLE_SID/wallet

  • Modifique el archivo SQLNET.ORA si desea administrar la cartera de cifrado.
        La ubicación predeterminada de la cartera de cifrado es             $ORACLE_BASE/admin/<nombre_db_global>/wallet. Si desea permitir que Oracle administre una cartera en la ubicación predeterminada, no necesita establecer el parámetro ENCRYPTION_WALLET_LOCATION en el archivo sqlnet.ora.

Para Windows


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=C:/oracle/admin/%ORACLE_SID%/wallet/)))

Para Linux


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=/app/oracle/admin/$ORACLE_SID/wallet/)))

  • Compruebe el parámetro de inicialización COMPATIBLE para el número correcto de versión. Debería ser 12.x.
Nota:
Utilice SQL*Plus. No utilice Oracle SQL Developer.

ORA> sqlplus /nolog SQL> connect /as sysdba Connected. SQL> select instance_name,status,database_status from v$instance;
INSTANCE_NAME    STATUS       DATABASE_STATUS
---------------- ------------ -----------------
mcs1              OPEN         ACTIVE
SQL> show parameter compatible NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      12.1.0.0.0
  • Cree el keystore.
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";


  • Abra el keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Comprueba el estado 
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

  • Haga una copia de seguridad de un software keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'keystore_bkp' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
  • Cree la clave principal de cifrado.
Cree una clave principal para la CBD y todas las PDB.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_all_bkp' CONTAINER=ALL;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
Exporte la clave principal.

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
  • Si lo desea, cree la contraseña principal para el contenedor actual. Puede omitir este paso si ha completado el paso anterior.
Base de datos de contenedor (CDB):

ALTER SESSION SET CONTAINER = CDB$ROOT;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_cdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
Base de datos conectable (PDB): bathypdb

ALTER SESSION SET CONTAINER = bathypdb;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_bathypdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_bathypdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

  • Comprobar estado
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type, creator,creator_instance_name, creator_pdbname from v$encryption_keys;

  • Establezca el keystore local de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
--the cwallet.sso file appears in the keystore location. The ewallet.p12 file is the password-based wallet. --Note:
--Do not remove the PKCS#12 wallet (ewallet.p12 file) after you create the auto login keystore (.sso file). 
--You must have the PKCS#12 wallet to regenerate or rekey the TDE master encryption key in the future. 
--By default, this file is located in the $ORACLE_HOME/admin/ORACLE_SID/wallet directory.

  • Abra el keystore de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN CONTAINER=ALL;
-- check the status
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
Sugerencia:
Para cerrarlo, puede usar la siguiente instrucción.

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Se recomienda que verifique el estado de la configuración TDE utilizando las instrucciones SQL siguientes.
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type from v$encryption_keys;
select key_id from v$encryption_keys;
select keystore_type from v$encryption_keys;
select wrl_parameter from v$encryption_wallet;
select status from v$encryption_wallet;
select * from v$encrypted_tablespaces;
select tablespace_name, encrypted from dba_tablespaces;
select * from dba_encrypted_columns;

¿Hay vida más allá de Oracle? TIBERO, la base de datos


Tibero es sistema de gestión de bases de datos relacional (RDBMS) desarrollado por TmaxSoft (Corea del Sur).

Si quieres tener información de primera mano, echa un ojo a su web.

Tibero es un sistema de administración de bases de datos relacionales (RDBMS) de alto rendimiento, altamente seguro y altamente escalable para empresas que desean aprovechar al máximo sus datos de misión crítica. En un mundo donde los datos son el núcleo de todo, Tibero ofrece una visión mejorada del procesamiento, la gestión y la protección de bases de datos a gran escala.

Tibero ofrece muchos beneficios que incluyen:

  • Altamente compatible con Oracle, en algunos casos hasta un 97% de compatibilidad
  • Alta disponibilidad (agrupación activa-activa)
  • Modelo de licencia simple similar al precio de suscripción de SaaS
  • Procesamiento de transacciones de alto rendimiento
  • Se escala con hardware básico en lugar de costosos servidores de bases de datos propietarios
  • Capacidad de base de datos en espera activa o pasiva
  • Arquitectura de hiperproceso
  • Cifrado de base de datos de alta seguridad
  • Recuperación en paralelo de varios nodos
  • Servidor compartido confiable
  • Tibero Enterprise Edition es todo incluido, sin productos adicionales para comprar

Tibero es un RDBMS que cierra la brecha entre las bases de datos relacionales heredadas y las cargas de trabajo en ejecución en un entorno de nube como AWS o Microsoft Azure

TmaxSoft, ofrece la posibilidad de bajar la base de datos en modo prueba de 30 días.

Dentro de las posibilidades que ofrece Tibero, podemos disfrutar de un buen ejemplo de despliegue. Hay un buen manual de como montar un cluster Tibero en AWS, en esta página: DBA Junior



Oracle: ¿Obtienes lo que pagas?

Oracle es el líder del mercado por una razón. Ofrece un alto rendimiento y buenas funciones y características que incluyen seguridad, ajuste y otros paquetes opcionales. La tecnología de escalamiento horizontal con RAC proporciona clústeres activo-activo (sin compartir nada). Debido a que es un proveedor comercial, sus desarrolladores son parte de la organización y son una cantidad conocida. Oracle es especialmente popular entre las grandes empresas y tiene una gran comunidad de desarrolladores y administradores.

Se recomienda Oracle para implementaciones a gran escala. Los procedimientos almacenados, que están integrados en la base de datos, se pueden ejecutar de forma independiente o activados por ciertos eventos. Es compatible con la partición de datos y requiere un nombre de usuario, contraseña y validación de perfil para iniciar sesión.

Sus inconvenientes incluyen la falta de soporte para CPU virtuales, costos ocultos para modelos de seguridad y particiones "opcionales" y altos CapEX (la licencia) y OpEX (el acuerdo de mantenimiento). Oracle tiene un modelo de licencia RDBMS mediante el cual, en un entorno de virtualización con particiones suaves, sus clientes deben pagar el 100% de los núcleos físicos disponibles, incluso si no se utilizan. Con este tipo de restricciones sobre cómo utilizar Oracle, muchas empresas, quizás incluso la suya, se sienten atrapadas en un monolito inflexible.

Código abierto: ¿Las mejores cosas de la vida son realmente gratuitas?

MySQL es rápido, escalable, fácil de usar y flexible. Permite la confirmación, la recuperación de fallos y la reversión de transacciones. Se usa comúnmente con scripts PHP para crear aplicaciones empresariales del lado del servidor o basadas en la web, y es compatible con Windows, Linux, MacOS y otros con C, C ++ y Java. Aunque las grandes empresas utilizan MySQL, es más popular entre las empresas más pequeñas porque no hay tarifas de licencia.

Otro RDBMS de código abierto popular es PostgreSQL, que es similar a MySQL. La eficiencia de su algoritmo central le permite superar a muchas bases de datos comerciales si trabaja con grandes conjuntos de datos, para los que los procesos de E / S pueden convertirse en un cuello de botella.

Las desventajas de las ofertas de código abierto también son similares. Tienen menos características y funciones que Oracle y no ofrecen RAC ni particiones de datos. Debido a que no son compatibles con Oracle, se necesitan más recursos y más tiempo para la migración, lo que aumenta los costos. Debido a que su código fuente está abierto a una comunidad, esto puede crear un riesgo de seguridad y la documentación principal no siempre está actualizada. El servicio y el soporte no están tan fácilmente disponibles porque estos no son productos comerciales.

TmaxSoft Tibero: ¿El secreto RDBMS mejor guardado?

  • Si la adopción de bases de datos fuera parte del concurso Let's Make a Deal, Oracle estaría detrás de la puerta # 1. 
  • Un RDBMS de código abierto como MySQL o PostgreSQL estaría detrás de la puerta # 2. Se estaría preguntando si desea sacrificar la estabilidad, la seguridad y las características y funcionalidades enriquecidas sin tarifas de licencia, desarrollo web y compatibilidad con más idiomas. 
  • En el juego RDBMS, al igual que en Let's Make a Deal, hay una puerta n. ° 3; sin embargo, TmaxSoft Tibero, que está detrás de él, es más un secreto que un misterio.

Tibero es un sistema de administración de bases de datos relacionales (RDBMS) de alto rendimiento, altamente seguro y altamente escalable. La alta disponibilidad se logra con activo-activo (igual que con RAC), el rendimiento se mejora con una arquitectura multiproceso y multiproceso, y para la recuperación ante desastres, hay activo-en espera. En términos de compatibilidad, Tibero es compatible con SQL estándar e interfaces como JDBC, ODBC y CLI, es compatible con Oracle PL / SQL, tipos de datos y funciones. También obtiene la ventaja adicional de la CPU virtual (no disponible con Oracle). Incluso puedes usar tu conjunto de habilidades de Oracle en Tibero.




Monitoreo de índices de bases de datos

 


Para aquellos que no están familiarizados con él, el monitoreo de índices es la forma de Oracle de rastrear si se está utilizando un índice, lo que le permite saber si es necesario. 

Dos cosas a tener en cuenta: 

  • No siempre marca un índice como usado, incluso si se usa. Si no se usa en un plan de ejecución, pero se usa para hacer cumplir una clave externa o restricción única, no se marcará como usado. 
  • La vista utilizada para observar el uso de índices es específica del esquema. Es posible que esté monitoreando índices, pero los índices no aparecerán en v $ object_usage a menos que inicie sesión como propietario del esquema. Es mejor ir directamente a la consulta subyacente para ver todos los índices supervisados (consulta a continuación).
Dado que la supervisión de índices es de muy bajo costo, tiene sentido activarla para todos los índices candidatos. Los índices en FK y los índices únicos funcionan incluso si no se utilizan en los planes de ejecución, por lo que no son candidatos para descartarse. Aquí está la consulta para obtener todos los índices no únicos, que no son de FK (se supone que no hay PK concatenados; si tiene eso, la consulta se vuelve más complicada):

SELECT 'ALTER INDEX '||ic.index_name||' MONITORING USAGE;'

  FROM all_ind_columns ic, all_indexes i

 WHERE i.uniqueness = 'NONUNIQUE' --don't monitor unique indexes

   AND i.table_owner = 'SCHEMA_OWNER_HERE'

   AND ic.index_owner = i.owner

   AND ic.index_name = i.index_name

   AND ic.position = 1

   AND NOT EXISTS (SELECT 'x' --Don't monitor indexes on FK's

                     FROM all_cons_columns cc, all_constraints c

                    WHERE ic.table_name = cc.table_name

                      AND ic.column_name = cc.column_name

                      AND c.constraint_name = cc.constraint_name

                      AND c.constraint_type IN ('R'));

Aquí está la consulta para ver los objetos monitoreados si no ha iniciado sesión como propietario del esquema:

select d.username, io.name, t.name,
       decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
       decode(bitand(ou.flags, 1), 0, 'NO', 'YES'),
       ou.start_monitoring,
       ou.end_monitoring 
from sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou,
     dba_users d
where io.owner# = d.user_id
  AND d.username = 'SCHEMA_OWNER_HERE'
  and i.obj# = ou.obj#
  and io.obj# = ou.obj#
  and t.obj# = i.bo#;

Y aquí hay un ejemplo de monitoreo de índices en acción, incluido el uso de índice único que no se marca:
CREATE TABLE test_monitoring AS SELECT level id, dbms_random.value(1,1000) value FROM dual CONNECT BY LEVEL <= 5000;

Table created.

CREATE UNIQUE INDEX test_monitoring_idx ON test_monitoring(id);

Index created.

ALTER INDEX test_monitoring_idx MONITORING USAGE;

Index altered.

--Using index for PK enforcement - does not flag the index as used:
INSERT INTO test_monitoring VALUES (100,0);
INSERT INTO test_monitoring VALUES (100,0)
*
ERROR at line 1:
ORA-00001: unique constraint (BAYPAS.TEST_MONITORING_IDX) violated 

SELECT index_name, used FROM v$object_usage WHERE index_name = UPPER('test_monitoring_idx');

INDEX_NAME                     USE                                              
------------------------------ ---                                              
TEST_MONITORING_IDX            NO                                               

--But we run a select that will use the index


SELECT * FROM test_monitoring WHERE id = 100;

        ID      VALUE                                                           
---------- ----------                                                           
       100   255.5571                                                           

--And now the index shows up as used:
SELECT index_name, used FROM v$object_usage WHERE index_name = 'TEST_MONITORING_IDX';

INDEX_NAME                     USE                                              
------------------------------ ---                                              
TEST_MONITORING_IDX            YES

Oracle RAC Highly Available IP (HAIP)




Oracle 11gR2 introdujo el RAC Highly Available IP (HAIP) para la Interconexión de Clúster para ayudar a eliminar un único punto de falla. Si el nodo en el clúster solo tiene un adaptador de red para la red privada, y ese adaptador falla, entonces el nodo ya no podrá participar en las operaciones del clúster. No podrá realizar su latido con el clúster. Eventualmente, los otros nodos desalojarán el nodo defectuoso del clúster. Si el clúster solo tiene un único conmutador de red para la Interconexión de Clúster y el conmutador falla, entonces todo el clúster quedará comprometido. 

Cada nodo del clúster tiene acceso a redes privadas duales. Los puntos únicos de falla han sido eliminados. Tenga en cuenta que los adaptadores de red duales sirven como interfaces para conmutadores de red duales.

No se puede simplemente levantar una segunda red privada y esperar que el software de clusterware comience a utilizar ambas redes. Sin ninguna configuración adicional, solo se usaría una red privada y la otra estaría inactiva.




Antes de Oracle 11gR2, los arquitectos de sistemas que estaban preocupados con el punto único de falla aprovecharían la agregación de enlaces. Los términos vinculación de NIC, formación de equipos de NIC o enlace de puertos también se utilizan para el mismo concepto. La idea central detrás de la agregación de enlaces es hacer que dos redes privadas actúen como una sola. Las dos redes privadas se combinan para mostrarse al sistema operativo como una unidad. Para el sistema operativo, los adaptadores de red se ven como un adaptador. Si uno de los adaptadores de red física fallara, el sistema operativo apenas notaría y el tráfico de red pasaría a través del adaptador restante.

Este no es un artículo sobre la arquitectura de máxima disponibilidad y en este punto se estará preguntando qué tiene que ver la agregación de enlaces con la optimización del rendimiento de Oracle RAC. Además de una mayor disponibilidad para el clúster, la agregación de enlaces mejora el rendimiento de la red privada. Dos redes privadas tienen el doble de capacidad y, por lo tanto, el doble del rendimiento de una sola red privada. Cuando el tráfico en la Interconexión de Clúster satura una red privada singular, otra opción es aprovechar la agregación de enlaces para mejorar el rendimiento de la transferencia de la memoria caché global.

Oracle Grid Infrastructure, desde la versión 11g,  proporciona RAC HAIP, que es la agregación de enlaces, movida al nivel de clusterware. En lugar de vincular los adaptadores de red en el lado del sistema operativo, se le indicó a Grid Infrastructure que use múltiples adaptadores de red. Grid Infrastructure seguirá iniciando HAIP incluso si el sistema está configurado con un solo adaptador de red privado. 

A continuación, se muestra el nombre del recurso ora.cluster_interconnect.haip está en línea.

Primea instalación

Durante mi primera instalación y configuración, tuve que aprender mucho sobre los requisitos de la red para implementar la base de datos RAC. Los conceptos dirección IP, dirección VIP, SCAN y una red de interconexión privada rápida, tuvieon que hacerse presentes en mi cabeza y asimilar que era lo que tendía que hacer.

Lo que me llamó la atención es esta extraña dirección IP en la interfaz virtual de mi red privada:

inet 169.254.42.186/19 brd 169.254.42.255 alcance global eth2: 1

Esto sucede cuando HAIP está activo y configurado.

Así que comprobaré

crsctl stat res -t -init

ora.cluster_interconnect.haip
1 ONLINE ONLINE srvpcaoraent1 ESTABLE

Ok, tenía HAIP, pero ¿Qué es HAIP?

IP de alta disponibilidad es una función que le ayuda a minimizar los desalojos de nodos debido a frecuentes eventos de caída de NIC privados, vinculación, trunking, formación de equipos o tecnología similar para hacer uso de conexiones de red redundantes entre los nodos. Oracle Clusterware ahora ofrece una solución integrada que garantiza el "uso de interconexión redundante", ya que admite la conmutación por error de IP.

¡Excelente!

Leí y encontré cómo ver la dirección IP utilizada globalmente

seleccione inst_id, name, ip_address de gv $ cluster_interconnects;

INST_ID NAME IP_ADDRESS
———- ————— ———————————————-
1 eth2: 1 169.254.31.186
2 eth2: 1 169.254.27.70

Y también

oifcfg getif
eth0 10.1.0.0 público global
eth2 192.168.181.0 global cluster_interconnect, asm

oifcfg le permite agregar y eliminar interfaces fácilmente

$ oifcfg setif -global <interface> / <subnet>: cluster_interconnect>
$ oifcfg delif -global <nombre_si>

Según la documentación 18c
 
De forma predeterminada, el software Oracle Grid Infrastructure utiliza todas las direcciones HAIP para la comunicación de red privada, lo que proporciona equilibrio de carga en el conjunto de interfaces que identifica para la red privada. Si una interfaz de interconexión privada falla o deja de ser comunicativa, Oracle Clusterware mueve de manera transparente la dirección HAIP  




19 enero 2021

¿Cómo seguir utilizando Flash en 2021? Para poder ejecutar Oracle Database Control

 

¿Cómo seguir utilizando Flash en 2021?

Lo más indicado es no utilizar Flash desde 2021 en adelante, pero sabemos que algunas empresas y organismos no han actualizado a tiempo sus sistemas para que eso sea posible. Algunos organismos públicos están enviando comunicaciones sobre cómo seguir utilizando Adobe Flash a partir del 1 de enero. 

  • Descargar un navegador que no deshabilite el funcionamiento de Flash
  • Actualización de Adobe Flash Player
  • Configurar Adobe Flash Player para que permita el acceso al servicio afectado
Hay que tener en cuenta que, dado que uno de los pasos del proceso consiste en la actualización de Adobe Flash Player, la fecha límite para poder realizarlo es el 31 de diciembre de 2020. Lo primero es descargar Pale Moon, un navegador libre basado en el navegador Firefox que ha garantizado la continuidad del funcionamiento de Adobe Flash Player. Una vez instalado, descargado el idioma español (o el deseado), es necesario tener Adobe Flash Player actualizado a la última versión.

Ahora crearemos un archivo con el bloc de notas y el siguiente contenido:

EnableAllowList=1
AllowListRootMovieOnly=1
AllowListUrlPattern=https://LAPTOP-3RJGV85G:1158/em
SilentAutoUpdateEnable=0
AutoUpdateDisable=1
EOLUninstallDisable=1

Ese fichero lo guardaremos como mms.cfg y lo copiaremos en:

32 bits

  • C:/Windows/system32/Macromed/Flash

64 bits
  • C:/Windows/SysWOW64/Macromed/Flash
  • C:/Windows/system32/Macromed/Flash



Se recomienda hacer una copia de seguridad del fichero mms.cfg original, antes de nada. En caso de necesitar acceder a otras aplicaciones flash es necesario añadir al archivo mms.cfg una línea por cada aplicación:

AllowListUrlPattern=http[s]://[DOMINIO_APLICACION/

Desinstalación manual y limpia de Oracle 11g Enterprise Edition para Windows

 



Advertencia: la edición del registro puede causar problemas en su PC. Si tiene problemas al intentar desinstalar Oracle de su estación de trabajo de Windows, o no puede desinstalar las instalaciones de Oracle de manera limpia y adecuada, se pueden utilizar los siguientes pasos para desinstalar todos los productos de Oracle instalados actualmente en la estación de trabajo:

  • Desinstale todos los componentes de Oracle mediante Oracle Universal Installer (OUI).
  • Elimine la clave HKEY_LOCAL_MACHINE / SOFTWARE / ORACLE que contiene entradas de registro para todos los productos de Oracle utilizando regedit.
  • Elimine cualquier referencia a servicios / componentes de Oracle en la siguiente ubicación de registro: HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services /. Busca entradas clave que comiencen con "Ora" que obviamente están relacionadas con Oracle.
  • Reinicie la estación de trabajo.
  • Elimina el directorio ORACLE_BASE. (es decir, C: \ Oracle)
  • Elimine el directorio C: \ Archivos de programa \ Oracle.
  • Vacíe el directorio temporal.
  • Vacía la papelera de reciclaje.
Con esto, la computadora está más o menos libre de cualquier componente de Oracle, lo que le permite reinstalar Oracle si es necesario.

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;