Mostrando entradas con la etiqueta Oracle 12c R2. Mostrar todas las entradas
Mostrando entradas con la etiqueta Oracle 12c R2. Mostrar todas las entradas

23 febrero 2021

Conceptos básicos de Data Guard de Oracle 12c

 

Data Guard es la verdadera tecnología de protección contra desastres de Oracle 12c. En él, tiene un mínimo de dos bases de datos, principal y en espera. Data Guard tiene opciones para múltiples sitios en espera, así como una configuración activo-activo.

Por activo-activo, significa que ambos / todos los sitios están en funcionamiento, en funcionamiento y accesibles. Esto se opone a los sitios que tienen una ubicación activa y las otras deben iniciarse cuando se necesitan. Este es un ejemplo del diseño arquitectónico general.


Arquitectura de Data Guard y Oracle 12c

Comenzar una descripción con la base de datos primaria es fácil porque se diferencia muy poco de cualquier otra base de datos que pueda tener. La única diferencia es lo que hace con sus registros de rehacer archivados.

La base de datos principal escribe un conjunto de registros de rehacer archivos en un área de recuperación de Flash o en un disco local. Sin embargo, puede configurar uno o más destinos en un entorno de Data Guard.

El parámetro LOG_ARCHIVE_DEST_n puede tener este aspecto para la configuración anterior:

LOG_ARCHIVE_DEST_10 = 'UBICACIÓN = USE_DB_RECOVERY_FILE_DEST'

LOG_ARCHIVE_DEST_1 = 'SERVICIO = PHYSDBY1 ARCH'

LOG_ARCHIVE_DEST_2 = 'SERVICIO = LOGSDBY1 LGWR'

 

·         LOG_ARCHIVE_DEST_10 está configurado para enviar registros de rehacer archivos al Área de recuperación de Flash local. Se requiere un destino local para todas las bases de datos en modo de registro de archivo.

·         LOG_ARCHIVE_DEST_1 está configurado para enviar los registros de archivo a través del proceso de archivado a un sitio remoto PHYSDBY1. El nombre del servicio para este sitio remoto tiene una entrada en el archivo tnsnames.ora en el servidor primario.

·         LOG_ARCHIVE_DEST_2 está configurado para enviar los registros de archivo a través del proceso LGWR a un sitio remoto llamado LOGSDBY1. El nombre del servicio para este sitio remoto también tiene una entrada en el archivo tnsnames.ora en el servidor primario.

 

¿Por qué la diferencia entre los métodos de envío ARCn y LGWR? Eso tiene algo que ver con los modos de protección. Un entorno de Data Guard tiene tres modos de protección.

Disponibilidad máxima

El modo de protección de máxima disponibilidad se compromete entre el rendimiento y la disponibilidad de datos. Funciona mediante el uso de LGWR para escribir simultáneamente para rehacer registros en los sitios principal y en espera. La degradación del rendimiento viene en forma de procesos que tienen que esperar a que las entradas del registro de rehacer se escriban en varias ubicaciones.

Las sesiones que emiten confirmaciones deben esperar hasta que se haya registrado toda la información necesaria en al menos un registro de rehacer de la base de datos en espera. Si una sesión se bloquea debido a su incapacidad para escribir información de rehacer, el resto de la base de datos sigue avanzando.

Protección máxima

El modo de protección máxima es similar a la disponibilidad máxima, excepto que si una sesión no puede verificar que rehacer está escrito en el sitio remoto, la base de datos principal se apaga.

Consejo:  Configure al menos dos sitios en espera para el modo de máxima protección. De esa manera, un sitio en espera que deje de estar disponible no interrumpirá el servicio para toda la aplicación.

 

Este modo verifica que no se producirá ninguna pérdida de datos en caso de desastre a costa del rendimiento.

Rendimiento máximo

El modo de protección de máximo rendimiento separa el proceso de trasvase de registros de la base de datos principal pasándolo al proceso de registro de archivo (ARCn). Al hacer esto, todas las operaciones en el sitio principal pueden continuar sin esperar a que se escriban las entradas de rehacer para rehacer los registros o rehacer el envío.

 

Esto se opone a los modos de trasvase de registros que utilizan el escritor de registros para transferir transacciones. El uso del escritor de registros puede ralentizar el procesamiento de la transacción porque puede verse afectado por la disponibilidad o el rendimiento de la red.

El rendimiento máximo proporciona el nivel más alto de rendimiento en el sitio principal a expensas de la divergencia de datos. La divergencia de datos se produce cuando los datos de los dos sitios comienzan a de sincronizarse. Los datos de rehacer del archivo no se envían hasta que se llena todo el registro de rehacer del archivo. En el peor de los casos, la pérdida de un sitio completo podría resultar en la pérdida de todos los datos de un registro de rehacer de archivo (archive redo log).

 

Realización de operaciones de conmutación y conmutación por error

Puede cambiar el procesamiento a su sitio en espera de dos maneras:

·         La conmutación (switchover) es un cambio planificado que puede ocurrir si desea realizar mantenimiento en el sitio principal que requiere que no esté disponible. Esta operación puede requerir unos minutos de inactividad en la aplicación, pero si tiene que realizar un mantenimiento que dure una hora o más, el tiempo de inactividad podría valer la pena. Esta operación se denomina cambio elegante porque convierte el sitio principal en su sitio en espera y su sitio en espera en el principal. Además, puede volver fácilmente al sitio principal original sin tener que volver a crearlo desde cero.

·         La conmutación por error (failover) ocurre cuando el sitio principal se ha visto comprometido de alguna manera. Quizás fue una pérdida total del sitio, o quizás descubrió daños físicos en un archivo de datos. No siempre, pero por lo general después de una conmutación por error, debe volver a crear completamente el sitio principal o recuperarlo de una copia de seguridad y reinstalarlo. Por lo general, realiza una conmutación por error solo cuando ha determinado que reparar el sitio principal llevará el tiempo suficiente para que prefiera no tener una interrupción de la aplicación durante todo el tiempo.

Para realizar un cambio, siga estos pasos:

1.        En el primario actual, inicie sesión en SQL * Plus y escriba lo siguiente:

<alter database commit to switchover to physical standby;>

 Deberías ver esto:

< Base de datos alterada >

.

2.       Apague la base de datos primaria:

 <shutdown immediate>

Deberías ver esto::

Database closed.
Database dismounted.
ORACLE instance shut down.

3.       Inicie la base de datos primaria en modo nomount:

  <startup nomount>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

4.       Monte la base de datos en espera:

<alter database mount standby database;>

Deberías ver esto:

Database altered.

5.       Iniciar la recuperación:

<recover managed standby database disconnect;>

Ves esto:

Media recovery complete.

6.       Inicie sesión en SQL * Plus en el modo de espera actual y escriba lo siguiente:

<alter database commit to switchover to physical primary;>

Deberías ver esto:

Database altered.

7.       Apague la base de datos en espera:

 <shutdown immediate>

Deberías ver esto:

Database closed.

Database dismounted.

ORACLE instance shut down.

8. Asegúrese de que todos los parámetros de inicialización apropiados estén configurados para que esta base de datos se comporte correctamente como primaria.

9.       Empiece normalmente:

<startup>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

Database mounted.

Database opened.


Asegúrese de que los usuarios y las aplicaciones puedan conectarse y utilizar la nueva instancia principal.



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;

12 septiembre 2020

The road to become a better DBA: Prepara tu laboratorio

Este es el inicio de una serie de artículos que me he propuesto llevar a cabo no solo para ilustrar a la gente de como prepararse para trabajar como DBA, sino para que Yo mismo mejore mis habilidades como administrador de base de datos y afronte todos los desafíos tecnológicos que estamos hartos de que nos bombardeen los partners, los clientes y los mandos. Y ya de paso me saque alguna certificación que no viene mal para el CV.

Como tenemos muchos casos de uso y escenarios, mi recomendación es crear 6 máquinas virtuales utilizando Oracle Virtualbox:
  • Una VM con Oracle DB 12c R2 Single Instance + Oracle Data Guard
    •  RAM: 4G
    • / = 10G; SWAP = 8G; / u01 = 40G (Binarios Oracle + Archivos de datos)
  • Una VM con Oracle Enterprise Manager 13c + Oracle Data Guard
    • RAM: 6G
    • / = 10G; SWAP = 8G; / u01 = 70G (Binarios Oracle + Binarios EM + Archivos de datos)
  • Una VM con Oracle Real Application Clusters 12c Nodo 1 - Hub
  • Una VM con Oracle Real Application Clusters 12c Node 2 - Hub
  • Una VM con Oracle Real Application Clusters 12c Node 3 - Hub
  • Una VM con Oracle Real Application Clusters 12c Nodo 4 - Leaf
    Para todos los RACs:

  •     RAM: (hub con mgmtdb: 4G / otros hubs: 3.4G / Leafs: 1.6G)
  •     / = 10G; SWAP = 8G; / u01 = 16G (Binarios Ora)

Con esos 6 servidores, puedes practicar:
  • Instancias individuales (CDB + Clone no CDB + PDB) y EM utilizando los servidores 1 y 2 anteriores.
  • DataGuard con Primary + Far Sync + Physical / Logical Stdby, que también utiliza los servidores 1 y 2. Puede simular instancias de Far Sync al crearlas en el mismo servidor.
  • RAC (nodos Hub o Leaf) con los Servidores 3 a 6 (use los Servidores 5 y 6 para jugar agregando / eliminando nodos)



Como el objetivo no es enseñar a instalar Oracle Linux ni la Base de datos vamos a obviar estos pasos hay cientos de web que te explican paso a paso como hacerlo. Recomiendo usar Oracle Linux 6 o 7 y como guía usaría las sabias palabras de Tim Hall en su entrada del blog:
Cuando se utiliza un portátil con memoria de 16 GB para practicar con las máquinas virtuales de Virtualbox, será difícil tener todas las máquinas en funcionamiento al mismo tiempo. Así que solo se  activan las máquinas que son necesarias para cada escenario.

Es bueno crear máquinas virtuales con la menor memoria RAM y disco posible asignadas.

Utilización de la memoria RAM de Oracle Linux 6/7 con w / o Grid u software de Oracle - 157 MB.
Por lo tanto, 4 GB de RAM deberían ser suficientes para todos los escenarios (excepto la máquina de EM, que recomiendo 6 GB)

En todos los servidores recomiendo alrededor de 10G para "/" y 8G para SWAP (mantenga sus instaladores descomprimidos en una carpeta externa compartida).

En los servidores RAC, agregue discos externos para discos ASM.

Con todas estas indicaciones nos servirá para empezar al trabajar con nuestras bases de datos y ahondar en los temas de administración que merecen repaso durante estos meses.

06 febrero 2019

Oracle 12C: Dos características interesantes en cuanto a seguridad

Hay muchas características nuevas en la base de datos de 12c que me gustan y que he discutido y hablado sobre ellas con varios colegas. Dos simples adiciones a la base de datos 12c hacen mi vida mucho más fácil en lo relativo a la seguridad de las bases de datos. El requisito era bloquear las cuentas de usuario que no hayan iniciado sesión en la base de datos durante 60 días consecutivos.

Last Login Time 

En las versiones anteriores a Oracle Database 12c (12.1) para averiguar cuándo un usuario inició sesión por última vez con éxito en la base de datos, debemos habilitar la auditoria de sesión, lo que conlleva cierta sobrecarga y el DBA debe configurar rutinas para limpiar la tabla de auditoria, etc. En 11g En la base de datos, tuve que habilitar la auditoría de sesión (mantener los registros de auditoria de la sesión durante al menos 61 días) y escribir un SQL que consultara a DBA_USERS y DBA_AUDIT_SESSION para enumerar a todos los usuarios activos que no usaron la base de datos durante 60 días.

En 12.1, Oracle registra automáticamente el tiempo de inicio de sesión exitoso en la tabla SYS.USER $ y está visible en DBA_USERS. La columna LAST_LOGIN de DBA_USERS muestra la última hora de inicio de sesión del usuario en la base de datos. En la base de datos 12.1, mi requisito se cumple al escribir un SQL simple contra DBA_USERS utilizando la columna LAST_LOGIN. No se requiere auditoria. El resultado se utiliza para crear SQL dinámico para bloquear cada cuenta mediante la instrucción ALTER USER ACCOUNT LOCK (similar a 11g).
Por cierto, notó que cuando inicie sesión en la base de datos utilizando SQL * Plus, también verá el último tiempo de inicio de sesión.

Bloqueo de cuenta inactiva

Mi requerimiento se automatizó completamente en la base de datos 12.2. Oracle introdujo el parámetro INACTIVE_ACCOUNT_TIME para los perfiles de usuario. El parámetro del perfil INACTIVE_ACCOUNT_TIME bloquea una cuenta de usuario que no ha iniciado sesión en la instancia de la base de datos en un número específico de días. El valor predeterminado para INACTIVE_ACCOUNT_TIME es 35. La configuración mínima es 15 y la máxima es 24855.

12 octubre 2018

Auditoría unificada en Oracle Database 12c


Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Aunque si bien hay muchos aspectos relacionados a la aplicación de la misma, no siempre todos son utilizados en todos las empresas. Pero a pesar de esto, puede que un DBA no tenga que llegar a implementar una solución de autenticación basada en Kerberos pero siempre va a tener la responsabilidad de saber que está pasando en su base de datos. Es decir, quien se está conectado, que sentencias se están ejecutando, etc,.... La auditoria ha sido desde hace años la manera de satisfacer esta necesidad. No solamente es fácil de implementar y administrar, sino que además cubre todos los aspectos necesarios que un DBA tiene que cuidar cuando se trata de proteger su base de datos.

La política de auditoria unificada es como un grupo de opciones de auditoria con diferentes condiciones. Para habilitar la auditoria, primero debe crear una política con diferentes opciones de auditoria y luego debe habilitar o deshabilitar para todos o pocos usuarios, según los requisitos que tengamos. Todos los registros de auditoria se almacenarán en la tabla UNIFIED_AUDIT_TRAIL

Por defecto, hay 7 políticas de auditoria que estarán presentes en una base de datos Oracle 12c.

En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoria. Estas son:

Auditoria obligatoria: Este tipo de auditoria está siempre habilitada y monitoriza las operaciones que involucren el inicio o apagado de la base de datos. Además de estas acciones, en cualquier momento que alguien utilice los roles predefinidos del sistema SYSDBA, SYSASM o SYSOPER esa acción será auditada.

Auditoria estándar: Este tipo de auditoria se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multicapa. Este tipo de auditoria se define y controla completamente a nivel de base de datos.



Auditoria basada en valores: La auditoria basada en valores fue introducida para poder capturar los valores reales que se cambian cada vez que algún tipo de sentencia DML es ejecutada en todas o determinadas filas de una tabla. Este tipo de auditoria aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.



Auditoria de grano fino: La auditoria de grano fino se centra en una auditoria de nivel  mas granular y las acciones auditadas se capturan basándose en el contenido accedido o modificado. Se puede simplemente crear políticas para disparar eventos de auditoria cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.



Auditoria SYS: Este tipo de auditoria en realidad permite monitorizar las actividades de un administrador del sistema. Los usuarios que se conecten como SYS serán auditados y los registros de sus acciones serán escritos en un archivo de sistema operativo para evitar que sean borrados de la tabla AUD$ dentro de la base de datos. El parámetro de inicialización AUDIT_SYS_OPERATIONS se utiliza para activar y desactivar la auditoria de SYS.

Auditoria mixta: por defecto está habilitada en 12c. Permite utilizar tanto la auditoria tradicional como los métodos de auditoria unificada. Es decir. Además de la auditoria tradicional, podemos usar todas las características de la auditoria unificada. Una vez que nos sentimos cómodos con el concepto unificado, podemos migrar la configuración de auditoria existente a una política unificada, podemos habilitar la auditoria pura.
Esto sirve como un buen mediador para un cambio fácil y sin problemas a la auditoria Unificada preferida.

Auditoria pura: una vez que se habilita la auditoria pura. No podemos utilizar los métodos de auditoria tradicionales.


  • Valor: FALSE  -> AUDITORIA MIXTA
  • Valor: TRUE   -> AUDITORIA PURA


¿Qué modo de auditoria unificado está habilitado para mi base de datos?


¿Cómo cambiar de una auditoria mixta a pura?



Políticas por defecto en la base de datos Oracle 12c:



Pero no todos están habilitados. Consulta AUDIT_UNIFIED_ENABLED_POLICIES para buscar, qué políticas están habilitadas.



Consulta para comprobar las opciones de auditoria incluidas en una política:



Incluso si no se crea una nueva política en la base de datos, la acción de auditoria de las opciones de auditoria anteriores se registrará en UNIFIED_AUDIT_TRAIL.

Eliminamos la política de auditoria:



Purgamos la pista de auditoria:



07 octubre 2018

Migrar de Oracle 11g a Oracle 12c: ¿Qué hacemos con la auditoria?



Si estas pensando en migrar a Oracle Database 12c, sin importar el tipo de entorno implicado (desarrollo, prueba, certificación producción), una de las muchas decisiones que debes consolidar con tu equipo es definir qué hacer con la auditoria. La nueva característica más importante en esta área es la denominada Auditoría Unificada, que captura información de auditoria de diferentes fuentes, como por ejemplo registros de auditoria "normales" y FGA, contextos de aplicación, RMAN o DataPump más algunas otras y las almacena en un formato y lugar comunes. , que es de solo lectura, tabla particionada en el esquema AUDSYS, que reside de forma predeterminada en el tablespace SYSAUX y utiliza la función Oracle SecureFiles.

Afortunadamente, Oracle nos dio flexibilidad en cuanto a las opciones de migración disponibles. Por ejemplo, en 12c todavía es posible utilizar la auditoría tradicional, de manera similar a como lo haciamos en la versión 11g. Incluso existe la posibilidad de realizar auditorias de modo mixto, en las que se completan las pistas de auditoria tradicionales y unificadas. Por supuesto, usar solo un enfoque unificado también es posible.

Independientemente del modo que desees utilizar después de la migración, es una buena idea habilitar la auditoria unificada desde el principio, volviendo a vincular los binarios de la base de datos con el parámetro uniaud_on. Esto le permitirá evitar la no disponibilidad si decide realizar una auditoria unificada (o de modo mixto) en una etapa posterior. Utilice la siguiente consulta para encontrar si está correctamente habilitado:


Todos los parámetros de inicialización de auditoria utilizados anteriormente:
  • audit_trail
  • audit_file_dest
  • audit_sys_operations
  • audit_syslog_level

No tienen significado (en caso de usar solo auditoria unificada). Sin embargo, todavía están disponibles, ya que son necesarios para los modos tradicional y mixto.

Teniendo en cuenta las migraciones, también debe decidir qué hacer con los registros de auditoria antiguos. Incluso cuando la auditoria tradicional está deshabilitada, todavía existe la posibilidad de archivar y luego purgar los registros de auditoria de las pistas de auditoria tradicionales utilizando el paquete dbms_audit_mgmt, por lo que podría hacerse antes, durante o después de la actualización.

¿Qué debería convencerlo de que la auditoria unificada es una mejora significativa en comparación con el enfoque tradicional?

Probablemente la ventaja más importante está incorporada en la palabra "unificada": el hecho de que todos los registros de auditoria están disponibles a través de la vista unificada_audit_trail y en el caso de un entorno multitenant en la vista cdb_unified_audit_trail, que proporciona registros de auditoria de cada PDB (disponible solo en la raíz). Parece que Oracle ha analizado todas las opciones y características de auditoria disponibles en versiones anteriores y ha diseñado la auditoria unificada como más consistente, segura y más fácil de administrar. 
A partir de 12c, podría olvidarse del manejo diferente de los registros ubicados en aud $, fga_log $ o archivos del sistema operativo. Aún así, cuando la base de datos no se puede escribir (por ejemplo, cerrada, montada, abierta de solo lectura), los registros de auditoría se colocarán en archivos del sistema operativo (ubicados en $ ORACLE_BASE / audit / $ ORACLE_SID, que desafortunadamente parece no ser modificable). Se debe hacer de esa manera: es crucial para auditar operaciones como la conexión como sysdba, pero, por supuesto, no puede persistir en una base de datos que no se pueda escribir. Afortunadamente, actualmente existe la posibilidad de cargar archivos de auditoria ubicados en este directorio en la base de datos utilizando el procedimiento dbms_audit_mgmt.load_unified_audit_files. Posteriormente, podrían manejarse como otros registros de auditoria, sin la necesidad de implementar analizadores dedicados, etc.

Gestión de auditoria distinta, pero más sencilla

Hablando de una gestión de auditoria más fácil, debemos recordar no solo el manejo de los registros de auditoria, sino también la configuración de lo que se debe auditar. Es muy diferente en comparación con 11g, ahora se define en las políticas de auditoria. Podría tener muchas de estas políticas definidas y habilitarlas / deshabilitarlas de forma independiente, pero tenga en cuenta que, según la documentación de Oracle, la cantidad de políticas de auditoria habilitadas al mismo tiempo en la base de datos debe ser limitada.

Como puede encontrar en el archivo $ ORACLE_HOME / rdbms / admin / secconf.sql, hay 3 políticas de auditoría predeterminadas definidas para nuevas instalaciones de 12c: 
  • ora_account_mgmt
  • ora_database_parameter
  • ora_secureconfig.
Solo el último está habilitado de forma predeterminada, pero es una buena idea borrar la configuración predeterminada y usarla como punto de partida para diseñar su propia política de auditoria. Al hacer eso, tenga en cuenta que hay una serie de actividades que se auditan obligatoriamente.

La administración en términos de acceso a los datos de auditoria también se simplifica, gracias a la introducción de dos nuevos roles, con nombres autodescriptivos: audit_admin y audit_viewer.


Desde el punto de vista de la seguridad, esta era una limitación bastante grande, que actualmente, como resultado del nuevo diseño  de la auditoria en la versión 12c de la base de datos, se ha eliminado.