Entender Oracle Data Guard

En este artículo, escribiré sobre la solución de recuperación de desastres de Oracle (recuperación de desastres). Voy a dar la terminología básica en una breve información sobre el Data Guard. Como gestores de datos, estamos obligados a tomar las medidas necesarias antes de que ocurran estos desastres. También hay que considerar tomar las acciones necesarias que son muy importantes. Estos son;

• RPO (Recovery Point Objective) - ¿Cuántos datos puede permitirse perder?
• RTO (Recovery Time Objective) - Sin acceso a los datos, ¿Cuanto tiempo puedes soportar?

De acuerdo con las respuestas de estas preguntas debemos establecer el sistema de copia de seguridad. No estamos satisfechos con la instalación de nuestro sistema, y ​​debemos monitorear nuestro sistema.

Ahora, veamos la solución que Oracle propone:  Oracle Data Guard.

Oracle Data Guard es la solución de recuperación de desastres. Protege nuestra base de datos de producción de los desastres, reduciendo la carga de trabajo sobre ella y su uso más efectivo. Technology, introducida por primera vez mediante el establecimiento de la base de datos de reserva manualmente con Oracle 7. Apareció como un Data Guard con Oracle 8i. 

Evolución histórica de Oracle Data Guard

Si examinamos las características de un Data Guard desde el pasado hasta el presente;

• ORACLE 8i
• Base de datos en espera de sólo lectura
• Recuperación gestionada
• Archivo de registro de rehacer archivos remotos

• ORACLE 9i
• Integración "Pérdida de datos cero"
• Data Guard Broker y Data Guard Manager GUI
• Operaciones de Switcover y Failover
• Sincrónico automático
• Base de datos de espera lógica
• Protección máxima

• ORACLE 10g
• Aplicación en tiempo real
• Soporte forzado para Oracle RAC
• Failover de arranque rápido
• Transferencia asíncrona de rehacer
• Base de datos Flashback

• ORACLE 11g
• Base de datos de espera activa (Active Data Guard)
• Instantánea de la instantánea
• Soporte de plataforma heterogénea (Producción -Linux, Standby - Windows)

• ORACLE 12C
• Funciones comunes a Redo Apply y SQL Apply
• Funciones especificas a Redo Apply
• Funciones especificas a  SQL Apply

FLUJO DE DATOS: PHYSICAL STANDBY

Vamos a entender cómo los datos fluyen en la configuración de Oracle Data Guard mostrada arriba en ocho puntos:

• En la base de datos principal, se inician las transacciones. Todos los bloqueos de caché del búfer (bloqueos exclusivos) que se requieren para la transacción se obtienen.
• En la base de datos principal, los bloques de rehacer que describen los cambios (o los vectores de cambio) se generan y almacenan en el Área Global del Programa (PGA) de los procesos. Después de adquirir con éxito el bloqueo de rehacer asignación, el espacio se asigna en el búfer de registro de rehacer. El redo generado se copia de PGA de los procesos en el búfer de registro de rehacer.
• En la base de datos primaria, el proceso de primer plano de oracle le indica a LGWR que limpie los búferes de registro de rehacer en el disco. Recuerde que los bloques de base de datos de la base de datos aún no se han actualizado con los cambios DML. El LGWR descarga los buffers de redo al ORL y reconoce la finalización de la sesión. En este punto, la transacción es persistente en el disco. No se ha cometido hasta el momento.

En algún momento futuro, los buffers de base de datos que fueron cambiados previamente serán escritos en disco por el proceso de escritura de base de datos (DBWR) en el momento del punto de control. Este punto no está marcado en el diagrama anterior.

Tenga en cuenta que antes de que el proceso DBWR haya descargado los búferes de la base de datos a los discos, el proceso LGWR debe haber escrito ya los búferes de rehacer en el disco. Esta secuencia explícita es reforzada por el protocolo de registro anticipado.

También el proceso ARCH en la base de datos primaria archiva los ORL en archivos de registro de archivos. Este punto tampoco está marcado en el diagrama anterior.

• En la base de datos primaria, el proceso LNS lee el redo recientemente descargado del búfer de registro de redo y envía los datos de rehacer a la base de datos en espera utilizando el destino de transporte redo (LOG_ARCHIVE_DEST_n) que definimos durante la creación de la base de datos en espera. Estamos utilizando el método de transporte ASYNC, por lo que el LGWR no espera ningún reconocimiento de la LNS para esta operación de envío de red. No se comunica con el LNS excepto para iniciarlo en la etapa de inicio de la base de datos y después de un fallo de una conexión en espera.

• En la base de datos de espera, el RFS lee el flujo de rehacer desde el socket de red en los búferes de red y, a continuación, escribe este flujo de rehacer a la SRL.

• En la base de datos de espera, el proceso ARCH archiva las SRL en archivos de registro de archivo cuando se produce un cambio de registro en la base de datos primaria. El archivo de registro de archivo generado se registra con el archivo de control de espera.

• En la base de datos de espera, el proceso de recuperación real comienza en este paso. El proceso de recuperación administrado (MRP) leerá de forma asincrónica el rehacer de los SRL o de los registros de rehacer archivados (cuando la recuperación se reduce o no se aplica en tiempo real). Los bloques que requieren redo apply se analizan y se colocan en segmentos de mapa en memoria apropiados.

• En la base de datos en espera, el proceso MRP envía rehacer a los esclavos de recuperación utilizando el marco de comunicación entre procesos de consulta en paralelo (PQ). Medios paralelos

Recuperación (PMR) hace que los bloques de datos requeridos sean leídos en la caché del búfer, y posteriormente redo se aplicará a estos búferes del búfer del búfer.

PROCESOS RELACIONADOS CON BASE DE DATOS EN ESPERA FÍSICA

En la base de datos primaria:

• LGWR: El proceso de escritura de registros vacía los buffers de registro de los archivos SGA a Online Redo Log.
• LNS: El servicio de red de LogWriter (LNS) lee el redo que es descargado de los almacenadores intermediarios del redo por el LGWR y envía el redo sobre red a la base de datos espera. El propósito principal del proceso LNS es liberar el proceso LGWR de realizar el rol redo transport. 
• ARCH: El archivador procesa los archivos de ORL para archivar los archivos de registro. Pueden existir hasta 30 procesos ARCH, y estos procesos ARCH también se utilizan para satisfacer solicitudes de resolución de huecos. Tenga en cuenta que un proceso ARCH tiene un papel especial en que está dedicado al archivo de registro de redo local solo y nunca se comunica con una base de datos en espera.

En la base de datos de reserva:

• RFS: El objetivo principal del proceso de servidor de archivos remotos es realizar una red de recepción de redo transmitida desde el sitio principal y, a continuación, escribe el búfer de red (rehacer datos) a los archivos de redo registro (SRL) en espera.
• ARCH: Los procesos de archivo en el sitio en espera realizan las mismas funciones realizadas en el sitio principal, excepto que en el sitio en espera, un proceso ARCH genera archivos de registro archivados de las SRL.
• MRP: el proceso de recuperación administrado coordina la administración de recuperación de medios. Recuerde que un modo de espera físico está en modo de recuperación perpetua.

Básicamente, podemos categorizar la base de datos de espera física en tres componentes principales:

Data Guard Redo Servicios de Transporte

Para transferir el redo generado por la base de datos primaria a la base de datos en espera.

Data Guard Aplicar Servicios

Para recibir y aplicar el redo enviado por Redo Transport Services a la base de datos en espera.

Data Guard servicios de gestión de roles

Para ayudar en los cambios de rol de la base de datos en los escenarios de conmutación y conmutación por error- Este servicio funciona en segundo plano y se ocupa de los escenarios de conmutación / conmutación por error

Nueva versión de Oracle GoldenGate para Big Data 12.3.1.1

En este artículo vamos a ver, Lo que todo el mundo debe saber sobre Oracle GoldenGate Big Data 12.3.1.1 

Las principales características de esta versión incluyen las siguientes novedades

• Como nuevos objetivos de Oracle GoldenGate 12c se encuentran los siguientes sistemas:
• Amazon Kinesis
• API de Integración Kafka o Kafka Connect Confluent.
• Elasticsearch
• El Motor de Oracle GoldenGate Core 12.3: soporta los formatos de base de datos Oracle Database 12.2 y más recientes

• Nuevas Certificaciones:
• Apache Hadoop 2.8,
• CDH 5.10, 5.11,
• Hive 2.x,
• Kafka 0.10, 0.11,
• Cassandra 3.11
• ...

• Mapeo de plantillas: define plantillas para resolver dinámicamente el nombre de secuencia y la clave de partición en tiempo de ejecución
• Rendimiento: Rendimiento mejorado hasta el 20% en comparación con la versión anterior.

Oracle GoldenGate ofrece una arquitectura modular diseñada para un rendimiento extremo, tolerancia a fallos y flexibilidad. Oracle GoldenGate para Big Data se basa en la misma arquitectura para permitir soluciones extensibles para los grandes entornos de datos de los clientes.

Oracle GoldenGate captura datos de sistemas fuente heterogéneos incluyendo sistemas de mensajería basados en Java, de forma no invasiva y con gastos indirectos insignificantes. Almacena transacciones de base de datos en archivos planos y lo bombea al marco del Adaptador Java.

Oracle GoldenGate para Big Data incluye controladores para diferentes grandes tecnologías de datos, como HDFS, Hive, HBase, Flume, Kafka, NoSQL, JDBC, etc. También incluye tecnología de formateo conectable que puede usarse para transformar datos en formatos estándar como XML , JSON, Avro, Texto delimitado. Está construido utilizando la arquitectura Java extensible, que le permite entregar fácilmente a otros grandes sistemas de datos y soportar casos de uso específicos para satisfacer sus demandas empresariales.

Con la plataforma de streaming en tiempo real de Oracle GoldenGate, puede capturar desde el sistema de origen una vez y entregar todo o una parte de los datos modificados a múltiples destinos sobre cloud, híbridos e incluso bases de datos, sistemas de mensajería y entornos de datos grandes.

En siguientes entradas de blog haremos un ejemlo de uso de GoldenGate con Big Data.

Un DBA en la(s) Nube(s)

No es ningún secreto que los datos son el nuevo Rey Midas, una fuente de creación de riqueza a la par con el capital financiero, dicen algunos. Así que es un poco irónico que un grupo de personas que entienden mejor que nadie cómo administrar los datos se sienten cada vez más excluidos del partido.

Los administradores de bases de datos, o DBA, son y serán los expertos responsables del rendimiento y la seguridad de una creciente lista de tipos de base de datos:

• Nuestras viejas amigas las bases de datos relacionales.
• Las bases de datos en memoria.
• Y las nuevas propuestas tecnológicas ya presentes en el mercado las bases de datos No SQL.

Estas bases de datos proporcionan la tecnología principal de las actividades empresariales digitales como el comercio electrónico, la informática móvil y las redes sociales, y son parte integral de tendencias como los grandes datos, la inteligencia artificial y la Internet de las Cosas. Pero aquí está el problema para los DBA:

 Los proveedores de la nube ahora ofrecen servicios de base de datos totalmente gestionados que asumen muchas de las tareas diarias de los DBA internos de una empresa.

En mi opinión, muchas de las tareas mundanas de un DBA se van ", incluyendo muchas de las tareas en las que los DBA estarían de guardia las 24 horas del día,”. Dichas tareas pueden incluir la aplicación de actualizaciones de software o la copia de seguridad de datos, que se automatizan con un servicio de nube de base de datos. Mientras tanto, las partes del trabajo que son más interesantes y más visibles para una línea de líderes empresariales, como el modelado de datos y la seguridad de los datos, sólo crecerán.

Según mi experiencia y hablando con otros DBA experimentados, existen varias maneras de reinventar la carrera del DBA en la era de la nube.

Dominar la migración hacia la nube

Las empresas en el mundo tardarán mucho tiempo en pasar de las bases de datos locales a un futuro de bases de datos totalmente administradas en la nube. Cuando el equipo de TI mueve una base de datos Oracle a infraestructuras en la nube como Amazon Web Services o Oracle Bare Metal infrastructure, sus bases de datos seguirán gestionadas principalmente por sus propios DBA. Sin embargo, con el tiempo, a medida que las empresas utilicen más aplicaciones basadas en la nube, la base de datos que utilizan será administrada por el proveedor de la nube.

Durante esta transición, hay muchas necesidades tácticas que los DBA pueden ayudar a cumplir. Cuando una empresa está trabajando con tecnología local y Nube, alguien necesita entender el entorno de esta, pero también cosas como acceso VPN, seguridad, principios básicos de infraestructura de redes y base de datos.

El DBA debe de asesorar a su empresa a entender qué aplicaciones deben ser trasladadas a la nube inmediatamente y que deben esperar. Sobre todo, aprovechar las oportunidades que brindan los proveedores de nube para hacer migraciones y pilotos de forma gratuita.

Crecer en nuevos roles tecnológicos

Los cambios son una constante en la carrera del DBA. Hemos visto esto antes en versiones anteriores de la base de datos cuando Oracle introdujo la automatización a un montón de tareas de DBA: administración de almacenamiento automatizada, repositorio automático de carga de trabajo y alguno se hizo la pregunta ¿Voy a perder mi trabajo? Bueno algún ejemplo de este tipo de profesionales si nos lo habremos encontrado, pero hasta ellos mismos se habrán reprendido por hacerse esta pregunta.

Los DBA decidimos aprendier a confiar en la automatización e invertimos nuestro tiempo hacia trabajos de mayor valor.

Ahora puedes explorar herramientas de código abierto como Docker o Ansible, y aprender a usar los servicios REST. Ahora estamos creciendo de nuevo. Es posible que hayas estado haciendo lo mismo durante los últimos 10 años, y ahora está abriendo el libro O'Reilly y leyendo sobre la infraestructura como código y automatización en entornos dela nube. Eso es genial. Eso es crecimiento de carrera tanto como DBA como persona.

Hacerse responsable de asegurar los datos correctos para impulsar una estrategia empresarial

Esta es a mi modo de ver la opción más desafiante y a la que me quiero enfocar.

Hay miles de millones de datos en línea de servicios sociales y de intercambio de datos e IoT. Así que existe ya el papel de poner los datos a disposición de sus usuarios de negocios, y ese papel los DBA lo debemos de hacer nuestro,

Sabemos cómo se mueven los datos es una actividad natural para gente como nosotros. Por ejemplo, si una compañía cualquiera, puede querer analizar datos de múltiples fuentes, lo que requiere es de un DBA que entiende los formatos de datos y puede reunirlos. Un DBA puede ofrecer aún más valor al trabajar para entender el modelo de negocio de la empresa y asesorar sobre qué datos son más valiosos para el negocio.

Seamos sinceros un DBA no es un doctor en Estadística, pero pueden hacer que el papel de científico de datos sea mucho más valioso al conseguir que los datos sean más rápidos y más eficientes y al proporcionar una comprensión real de las diferentes fuentes de datos.

Hay mucho más que los DBA necesitan saber además de cómo administrar una o varias instancias de una base de datos. El DBA necesita tener un pensamiento crítico, necesita tener habilidades de comunicación con el equipo de usuarios del dato, necesita aportar su experiencia en resolución de problemas, bajo presión. El DBA de Oracle con los dedos en el teclado ya no tiene lugar, en cambio tienes que entender como los líderes empresariales quieren utilizar sus datos.

Has de empezar tomando contacto con los analistas de negocios de las distintas líneas de negocio para entender lo que esperan obtener de nuevas fuentes de datos y de la agilidad que proporciona la nube.

Otra competencia del DBA que no va a desaparecer es la de la seguridad de los datos. Alguien tiene que preocuparse por la seguridad de los datos a medida que el negocio amplía el acceso a todas estas formas y fuentes de datos. El proveedor de la nube podrá cifrarlos, pero ni sabe lo que es, ni quiere hacerlo o puede que ni lo ofrezca. Alguien en el lado del cliente de la nube, necesita entender y  clasifica el modelo de privilegios que tienen para quién puede acceder a los datos.

¿Que os parece el futuro de los DBA bajo la nube?

Oracle Database 12c R1: TDE en Pluggable Databases (PDBs)

La base de datos Oracle 12c introdujo una nueva forma de administrar almacenes de claves claves cifradas y datos a securizar mediante el comando:

• ADMINISTER KEY MANAGEMENT. 

Esto reemplaza los comandos:

• ALTER SYSTEM SET ENCRYPTION KEY
• ALTER SYSTEM SET ENCRYPTION WALLET 

para la administración de claves y wallets de versione anteriores La terminología de la documentación mezcla libremente los términos wallet y keystore, pero la intención parece ser pasar al término keystore, de acuerdo con la terminología de Java.

La arquitectura de múltiples terminales complica un poco la gestión de claves, ya que el contenedor raíz necesita un almacén de claves abierto con una clave de cifrado principal activa. El almacén de claves CDBs se utiliza para almacenar claves de cifrado para todos los PDB asociados, pero cada uno necesita su propia clave de cifrado principal. La clave de cifrado maestro para el PDB se debe exportar antes de una operación de desenchufado, por lo que se puede importar después de una operación de complemento posterior.

Aquí vamos a describir las operaciones de administración de claves básicas que se relacionan con Transparent Data Encryption (TDE). Algunas de las funcionalidades del keystore que vamos a ver en el presente artículo son:

• Localización del Almacén de claves
• Como crear un Almacén de claves
• Usar el Keystore para  implementar la opción TDE
• Usar PDBs Con la opción TDE
• Auto-Login en Almacenes de claves

Localización del Almacén de claves

Se debe crear un almacén de claves para mantener la clave de cifrado. El orden de búsqueda para encontrar el almacén de claves es el siguiente.

• Si está presente, la ubicación especificada por el parámetro ENCRYPTION_WALLET_LOCATION en el archivo "sqlnet.ora".
• Si está presente, la ubicación especificada por el parámetro WALLET_LOCATION en el archivo "sqlnet.ora".
• La ubicación predeterminada para el almacén de claves. Si se establece $ ORACLE_BASE, esto es "$ ORACLE_BASE / admin / DB_UNIQUE_NAME / wallet", de lo contrario es "$ ORACLE_HOME / admin / DB_UNIQUE_NAME / wallet", donde DB_UNIQUE_NAME proviene del archivo de parámetros de inicialización.

Los almacenes de claves no se deben compartir entre los CDB, por lo que si se ejecutan varios CDB desde el mismo ORACLE_HOME, debe realizar una de las siguientes acciones para mantenerlos separados.

• Utilice la ubicación predeterminada keystore, por lo que cada base de datos CDB tiene su propia almacén de claves.
• Especifique la ubicación mediante el método $ ORACLE_SID

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

• Tenga un "sqlnet.ora" por separado para cada base de datos, asegurándose de que la variable TNS_ADMIN está establecida correctamente.

Independientemente de dónde coloque el almacén de claves, asegúrese de no perderlo. Oracle 12c es extremadamente sensible a la pérdida del keystore. Si lo pierdes o cometes un error tendrás que tener que recrear la instancia limpia una y otra vez.

Crear un Almacén de claves

Debemos de editar el fichero sqlnet.ora, añadiendo la siguiente entrada al fichero:

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

Crea el directorio para mantener el almacén de claves.

mkdir -p /u01/app/oracle/admin/$ORACLE_SID/encryption_keystore

Conecta al contenedor raíz y crea el almacén de claves

CONN / AS SYSDBA

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/admin/cdb1/encryption_keystore/' IDENTIFIED BY myPassword;

HOST ls /u01/app/oracle/admin/cdb1/encryption_keystore/

ewallet.p12

SQL>

Puedes abrir y cerrar el almacén de claves desde el contenedor raiz usando los siguientes comandos. 

Para abrir:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword CONTAINER=ALL;

Para cerrar:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY myPassword CONTAINER=ALL;

Es necesario crear y activar una clave maestra en el contenedor de raíz y una en cada una de las bases de datos conectables. Utilizar la cláusula CONTAINER = ALL lo hace en un solo paso. Si se omite la cláusula CONTAINER = ALL, sólo se realizará en el contenedor actual y se deberá volver a realizar para cada PDB individualmente. La información sobre la clave maestra se muestra usando la vista V $ ENCRYPTION_KEYS.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY myPassword WITH BACKUP CONTAINER=ALL;

SET LINESIZE 100

SELECT con_id, key_id FROM v$encryption_keys;

    CON_ID KEY_ID

---------- ------------------------------------------------------------------------------

         0 AdaYAOior0/3v0AoZDBV8hoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

         0 AYmKkQxl+U+Xv3UHVMgSJC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA

SQL>

La información sobre el almacén de claves se muestra usando la vista V $ ENCRYPTION_WALLET.

SET LINESIZE 200

COLUMN wrl_parameter FORMAT A50

SELECT * FROM v$encryption_wallet;

WRL_TYPE             WRL_PARAMETER                                      STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC     CON_ID

-------------------- -------------------------------------------------- ------------------------------ -------------------- --------- --------- ----------

FILE                 /u01/app/oracle/admin/cdb1/encryption_keystore/    OPEN                           PASSWORD             SINGLE    NO                 0

SQL>

Conectar al PDB. Si no creó la clave en el paso anterior, cree una nueva clave maestra para el PDB.

CONN sys@pdb1 AS SYSDBA

SELECT con_id, key_id FROM v$encryption_keys;

    CON_ID KEY_ID

---------- ------------------------------------------------------------------------------

         0 DSrc9RAE//v/jcxEDSGIEEEEEEEEEEEEEEEEEEEEEEEEEEE

SQL>

Usar el Almacén de claves con la opción TDE

Ahora debe ser capaz de crear una tabla con una columna cifrada en el PDB.

CONN test/test@pdb1

-- Encrypted column

CREATE TABLE tde_test (

  id    NUMBER(10),

  data  VARCHAR2(50) ENCRYPT

);

INSERT INTO tde_test VALUES (1, 'This is a secret!');

COMMIT;

También podemos crear tablespaces cifrados

CONN sys@pdb1 AS SYSDBA

CREATE TABLESPACE encrypted_ts

DATAFILE SIZE 128K

AUTOEXTEND ON NEXT 64K

ENCRYPTION USING 'AES256'

DEFAULT STORAGE(ENCRYPT);

ALTER USER test QUOTA UNLIMITED ON encrypted_ts;

CONN test/test@pdb1

CREATE TABLE tde_ts_test (

  id    NUMBER(10),

  data  VARCHAR2(50)

) TABLESPACE encrypted_ts;

INSERT INTO tde_ts_test VALUES (1, 'This is also a secret!');

COMMIT;

Si se reinicia el PDB, el almacén de claves debe abrirse en el PDB antes de que se pueda acceder a los datos.

CONN sys@pdb1 AS SYSDBA

SHUTDOWN IMMEDIATE;

STARTUP;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword;

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1 This is a secret!

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 This is also a secret!

SQL>

Si se reinicia el CDB, el almacén de claves debe estar abierto tanto en el CDB como en los PDB.

CONN / AS SYSDBA

SHUTDOWN IMMEDIATE;

STARTUP;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY myPassword CONTAINER=ALL;

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1 This is a secret!

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 This is also a secret!

SQL>

Auto-Login en Almacenes de claves

La creación de un almacén de claves de inicio automático significa que ya no es necesario abrir explícitamente el almacén de claves después de reiniciarlo. La primera referencia a una clave hace que el almacén de claves se abra automáticamente, como se muestra a continuación.

CONN / AS SYSDBA

ADMINISTER KEY MANAGEMENT CREATE LOCAL AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/cdb1/encryption_keystore/' IDENTIFIED BY myPassword;

SHUTDOWN IMMEDIATE;

STARTUP

CONN test/test@pdb1

SELECT * FROM tde_test;

        ID DATA

---------- --------------------------------------------------

         1  Esto es un texto secreto

SQL>

SELECT * FROM tde_ts_test;

        ID DATA

---------- --------------------------------------------------

         1 Esto es otro texto secreto

SQL>

¿Hay vida más allá de Oracle? Malebolge el lenguaje infernal

Malbolge es un lenguaje de programación esotérico de dominio público desarrollado por Ben Olmstead en 1998. Se llamó así por el octavo círculo del infierno en La Divina Comedia, escrito por Dante.

Malbolge es peculiar porque se diseñó para ser el lenguaje más difícil. Sin embargo, varios de los trucos utilizados para hacerlo difícil de entender pueden ser evitados.

Este lenguaje tiene una utilidad muy buena, que al ser el más difícil de entender y al conocer este lenguaje tan poca gente, si te roban el código una empresa, tardarán muchos años y mucho dinero en personal en entender qué hace. Sin embargo, para cosas más complejas es imposible usarlo. Como muestra gráfica de ello, decir que Hisashi Iizawa, programador de Malbolge, tardó 7 años en realizar un programa que muestre por pantalla la canción completa de 99 Bottles of Beer.

Este es el Hola Mundo en Malebolge:

 (=<`:9876Z4321UT.-Q+*)M'&%$H"!~}|Bzy?=|{z]KwZY44Eq0/{mlk**

 hKs_dG5[m_BA{?-Y;;Vb'rR5431M}/.zHGwEDCBA@98\6543W10/.R,+O<

Si quieres saber mas:

• https://esolangs.org/wiki/Talk:Malbolge
• http://www.lscheffer.com/malbolge.shtml

V$SESSION : Sácale partido a esta vista

¿Qué es V$SESSION?

La vista V$SESSION es la base de toda la información relacionada con el estado actual del sistema:

• ¿Cuántas sesiones hay actualmente corriendo en la base de datos?
• ¿Qué consulta se está ejecutando?
• ¿Cuánto tardan en ejecutarse estas consultas?

 V$SESSION es el primer lugar cuando DBA comienza a buscar información relacionada con el rendimiento  e información de la ejecución de las consultas, un DBA puede llegar a consultar un centenar de veces al día esta vista, así que arrojemos un poco de luz sobre esta vista.

A efectos prácticos este artículo está basado en una base de datos Oracle 11g, usaremos:

• V$session: para una estancia sencilla.
• GV$session: para una instalación en cluster (RAC).

Listado de las sesiones ejecutándose

Lo primero que un DBA busca en nuestra vista favorita es la lista de sesiones de usuario de bases de datos. Hay dos tipos de sesiones de base de datos, principalmente background y sesiones de usuario. La sesión background se utiliza para la funcionalidad básica de la base de datos como dbwr, arch, smon, pmon etc. La sesión del usuario es la sesión que realiza las operaciones del usuario.

Cada vez que se conecta a los datos se crea una sesión en la base de datos para realizar sus operaciones. Un DBA puede ver fácilmente esto consultando la vista de sistema V$SESSION.

Actualmente sólo hay una sesión de usuario en ejecución. 

SQL> select count(*),type from v$session group by type;
  COUNT(*) TYPE
---------- ----------
         1 USER
        49 BACKGROUND

En el caso del entorno RAC, DBA debe utilizar GV$SESSION en lugar de V$SESSION.
   

SQL> select count(*),type,INST_ID from gv$session group by type,inst_id;
 COUNT(*) TYPE              INST_ID
----------  ---------- ----------
        21  USER            1
        48  BACKGROUND       1
        49  BACKGROUND       2
        17  USER         2

Supongamos que tenemos dos nodos RAC, la instancia 1 tiene 21 usuarios y 48 sesiones en background, mientras que la instancia 2 tiene 17 usuarios y 49 sesiones en background. Esta información es útil cuando se produce el siguiente error "ORA-00020: maximum number of processes (%s) exceeded" error. Puede utilizar la consulta siguiente para identificar qué usuario está creando un número alto de sesiones.

SQL> select SID,USERNAME,COMMAND,PROCESS,TERMINAL,PROGRAM from gv$session where type='USER';
       SID USERNAME                          COMMAND PROCESS                  TERMINAL                       PROGRAM
---------- ------------------------------ ---------- ------------------------ ------------------------------ --------
        16 SYS                                    47 17978                                                   oraagent.bin@dbarm2 (TNS V1-V3)
        19 DBSNMP                                  0 1234                     unknown                        JDBC Thin Client
        25 SYSMAN                                  0 1234                     unknown                        OMS
        26 DBSNMP                                  0 1234                     unknown                        JDBC Thin Client

• SID es la ID de la sesión, USERNAME es el nombre del usuario de la base de datos.
• Process es el número de proceso. 
• Terminal es el nombre del sistema que esta ejecutando la consulta. 
• Program muestra el nombre del programa que esta usando la consulta.

Terminal y Program son los campos más importantes para encontrar las sesiones culpables de los errores ORA-00020.

Es una lista del uso de la vista V$SESSION, he enumerado algunos de ellos aquí. Por favor, comparte en los comentarios si sabéis más.

Encontrar sesiones bloqueantes

Una queja común al administrador de la base de datos por el usuario es "mi conexión de la base de datos es muy lenta". En este caso DBA debe comprobar dos cosas O toda la base de datos se está ejecutando lento o Sólo una sesión de usuario es lenta. Para comprobar el estado completo de la base de datos, DBA puede utilizar Top Command, Watcher de OS e Informe AWR.

Si está seguro de que sólo una sesión única se está ejecutando lento entonces V$session o gv$session es el lugar perfecto para empezar. He visto muchos casos en los que una sesión está bloqueando otra sesión debido a transacciones no confirmadas.

SQL> select sid, username,command,status,program,sql_id,BLOCKING_INSTANCE,BLOCKING_SESSION,WAIT_CLASS from gv$session where BLOCKING_SESSION is not null;
       SID USERNAME      COMMAND STATUS   PROGRAM                                          SQL_ID        BLOCKING_INSTANCE BLOCKING_SESSION WAIT_CLASS
---------- ---------- ---------- -------- ------------------------------------------------ ------------- ----------------- ---------------- ---------------
        47 SCOTT               6 ACTIVE   sqlplus@database.example.com (TNS V1-V3)         2rbwgj3zdsnus                 1               34 Application

En el caso anterior, el usuario scott no recibía ninguna respuesta de su consulta. Comprobé utilizando la consulta anterior en la que "BLOCKING_SESSION" muestra el detalle de la sesión que está bloqueando la sesión de usuario SCOTT. 

Los campos: 

• SID, 
• USERNAME,
• COMMAND, 
• STATUS, 
• PROGRAM y 
• SQL_ID 

son detalles del usuario SCOTT, BLOCKING_INSTANCE significa en qué instancia se está ejecutando la sesión de bloqueo, BLOCKING_SESSION es el ID de sesión de la sesión de bloqueo.
Ahora el siguiente plan de acción para DBA es comprobar lo que está causando que la sesión 34 bloquee la sesión de scott. El DBA puede utilizar la consulta siguiente para averiguar los detalles de la sesión 34.

SQL> select sid,username,command,status,program,sql_id,BLOCKING_INSTANCE,BLOCKING_SESSION,WAIT_CLASS from gv$session where sid=34;
SID USERNAME      COMMAND STATUS   PROGRAM  SQL_ID BLOCKING_INSTANCE             BLOCKING_SESSION     WAIT_CLASS
--- ---------- ---------- -------- ------------------------------------------------ ------------- ------------
34 SCOTT               3 INACTIVE sqlplus@database.example.com (TNS V1-V3)         17d40vwcct4g6       Idle

Sin embargo, podría haber muchas razones para este tipo de problema. Uno de ellos lo he discutido aquí.

Archivos redo log

En Oracle RDBMS, los redo logs comprenden archivos en un formato propietario que registra un historial de todos los cambios realizados en la base de datos. Cuando algo se cambia en un datafile, Oracle registra los cambios a la base de datos.

¿Qué es Online Redo Log?

El Online Redo log, es una estructura física que consiste de mínimo de dos archivos, estos a su vez pueden estar multiplexados en dos o más copias idénticas, que a estos se le conocen como miembros de un grupo de Redo log. Como mencionamos, el Online Redo Log consiste de mínimo dos archivos, esto permite que Oracle escriba en un archivo de Online Redo Log mientras el otro se archiva (si la base de datos se encuentra en modo ARCHIVELOG). 

En los Online Redo logs se almacenan registros de Redo, los cuales están conformados por vectores de cambio (change vectors), cada uno de estos vectores describe los cambios a un bloque de datos.

Todos los registros de tipo redo tiene metadatos relevantes, incluyendo:

• SCN y la estampa de tiempo del cambio
• El ID de la transacción que ha generado el cambio
• SCN y la estampa de tiempo cuando la transacción fue cometida (commit)
• Tipo de operación que efectuó el cambio
• Nombre y tipo del segmento de dato modificado.

Los Online Redo Log son usados únicamente en el proceso de la recuperación de la base de datos. Básicamente, lo que hay que entender como principio, es que cuando algún DML (insert, update o delete) o un DDL (alter, create, drop) sucede en nuestra base de datos, Oracle registra los cambios en memoria, en un buffer llamado Redo Log Buffer, que con este buffer hay un proceso asociado llamado LGWR.

El proceso LGWR de lo que se encarga es de escribir de la estructura de memoria (Redo) Log Buffer a los Online Redo Logs, y muy importante es saber cuáles son las circunstancias que hacen que el LGWR escriba al Online Redo Log:

• Cuando un usuario hace un commit a la transacción
• Cuando sucede un cambio (log switch) de archivo de Redo Log
• Cuando han pasado tres segundos desde la ultima escritura del LGWR hacia el Online Redo Log
• Cuando el Redo Log Buffer esta 1/3 lleno o contiene mas de 1Mb de datos en el buffer.
• Cuando el proceso DBWn necesita escribir datos del Database Buffer Cache hacia disco.

El proceso LGWR escribe a los archivos de Online Redo Log de manera circular, cuando el LGWR escribe en el ultimo archivo de Online Redo Log disponible, el LGWR se regresa a escribir al primer archivo de Online Redo Log.

-- Consultamos las vistas del diccionario de datos relativas a los redo logs
select * from v$logfile;
select * from v$log;
-- Rotamos los logs
alter system switch logfile;
-- Comprobamos los logs
select * from v$log;

Tareas de un DBA (primera parte)

Esta es una compilación de tareas que un administrador de base de datos ha de ejecutar  de forma diaria, semanal, mensual y otras sin un periodo definido.

Actividad diaria 

En esta entrada nos centraremos en las tareas diarias.

Comprueba si la instancia Oracle está funcionando o no.

1.     Sistema operativo Windows: mirar el programa services.msc

2.     Sistema operativo Unix: ps -ef | grep pmon

3.     SQL: SQL> select status from v$instance;

Comprueba si los listeners Oracle están funcionando o no

Para que desde fuera del servidor donde está instalada la base de datos Oracle se pueda acceder a la misma el servicio denominado listener ha de estar activado, o como se suele decir, el listener de Oracle ha de estar escuchando.

Puede pasar que la base de datos esté correctamente levantada y no se pueda conectar desde otros servidores, que también están correctamente configurados (TNSNAMES correcto, etc.). En estos casos puede ser que el listener tenga algún problema, o simplemente que no haya sido iniciado. En ese caso tan sólo habría que arrancar el listener.

Consultar el estado del mismo, arrancarlo o pararlo es muy sencillo. Sólo hay que abrir una sesión de línea de comandos (consola, terminal, etc. ) con el usuario con el que se ha instalado la base de datos, y ejecutar el comando lsnrctl con los siguientes parámetros para cada caso:

·         Comprobar su estado: > lsnrctl status

·         Parar el listener:          > lsnrctl stop

·         Levantar el listener:     > lsnrctl start

Comprueba si hay sesiones que bloquean otras sesiones 

En Oracle hay una vista v$lock que nos indica los objetos que se encuentran en bloqueo, el identificador de usuario y sesión y el tipo de bloqueo.

Una “join” con la tabla dba_objects nos proporciona además el nombre y tipo de los objetos bloqueados:

Existen principalmente dos tipos de bloqueo:

·         Bloqueos de tablas (TM) 

·         Bloqueos a nivel de fila (TX)

Los bloqueos a nivel de tabla son creados cuando se ejecuta una sentencia DML del tipo: update, insert, delete, select ..for update sobre la tabla entera. 

Los bloqueos a nivel de fila se crean cuando se ejecutan sentencias DML contra un conjunto de registros específicos.

Una consulta sobre esta vista nos permite rápidamente saber que procesos están bloqueados y si además hacemos un join con v$open_cursor podemos ver que consulta es la que se encuentra parada a la espera de que se produzca el desbloqueo para poder ejecutarse. En la consulta siguiente podemos ver las sentencias paradas y el id de proceso que las está bloqueando.

Esta consulta permite ver los objetos que están esperando a que termine un bloqueo y la sentencia que quieren ejecutar. el id de proceso nos da la pista de quien esta bloqueando:

select /*+ ordered
no_merge(L_WAITER)
no_merge(L_LOCKER) use_hash(L_LOCKER)
no_merge(S_WAITER) use_hash(S_WAITER)
no_merge(S_LOCKER) use_hash(S_LOCKER)
use_nl(O)
use_nl(U)
*/
/* first the table-level locks (TM) and mixed TM/TX TX/TM */
S_LOCKER.OSUSER OS_LOCKER,
S_LOCKER.USERNAME LOCKER_SCHEMA,
S_LOCKER.PROCESS LOCKER_PID,
S_WAITER.OSUSER OS_WAITER,
S_WAITER.USERNAME WAITER_SCHEMA,
S_WAITER.PROCESS WAITER_PID,
'Table lock (TM): '||U.NAME||'.'||O.NAME||
' - Mode held: '||
decode(L_LOCKER.LMODE,
0, 'None', /* same as Monitor */
1, 'Null', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Exclusive', /* X */
'???: '||to_char(L_LOCKER.LMODE))||
' / Mode requested: '||
decode(L_WAITER.REQUEST,
0, 'None', /* same as Monitor */
1, 'Null', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Exclusive', /* X */
'???: '||to_char(L_WAITER.REQUEST))
SQL_TEXT_WAITER
from
V$LOCK L_WAITER,
V$LOCK L_LOCKER,
V$SESSION S_WAITER,
V$SESSION S_LOCKER,
sys.OBJ$ O,
sys.USER$ U
where S_WAITER.SID = L_WAITER.SID
and L_WAITER.TYPE IN ('TM')
and S_LOCKER.sid = L_LOCKER.sid
and L_LOCKER.ID1 = L_WAITER.ID1
and L_WAITER.REQUEST > 0
and L_LOCKER.LMODE > 0
and L_WAITER.ADDR != L_LOCKER.ADDR
and L_WAITER.ID1 = O.OBJ#
and U.USER# = O.OWNER#
union
select /*+ ordered
no_merge(L_WAITER)
no_merge(L_LOCKER) use_hash(L_LOCKER)
no_merge(S_WAITER) use_hash(S_WAITER)
no_merge(S_LOCKER) use_hash(S_LOCKER)
no_merge(L1_WAITER) use_hash(L1_WAITER)
no_merge(O) use_hash(O)
*/
/* now the (usual) row-locks TX */
S_LOCKER.OSUSER OS_LOCKER,
S_LOCKER.USERNAME LOCKER_SCHEMA,
S_LOCKER.PROCESS LOCK_PID,
S_WAITER.OSUSER OS_WAITER,
S_WAITER.USERNAME WAITER_SCHEMA,
S_WAITER.PROCESS WAITER_PID,
'TX: '||O.SQL_TEXT SQL_TEXT_WAITER
from
V$LOCK L_WAITER,
V$LOCK L_LOCKER,
V$SESSION S_WAITER,
V$SESSION S_LOCKER,
V$_LOCK L1_WAITER,
V$OPEN_CURSOR O
where S_WAITER.SID = L_WAITER.SID
and L_WAITER.TYPE IN ('TX')
and S_LOCKER.sid = L_LOCKER.sid
and L_LOCKER.ID1 = L_WAITER.ID1
and L_WAITER.REQUEST > 0
and L_LOCKER.LMODE > 0
and L_WAITER.ADDR != L_LOCKER.ADDR
and L1_WAITER.LADDR = L_WAITER.ADDR
and L1_WAITER.KADDR = L_WAITER.KADDR
and L1_WAITER.SADDR = O.SADDR
and O.HASH_VALUE = S_WAITER.SQL_HASH_VALUE

Comprueba el “alert log” si hay errores

El registro de alertas es un registro cronológico de mensajes y errores, e incluye los siguientes elementos:

• Todos los errores internos (ORA-600),
• Errores de corrupción de bloques (ORA-1578)
• Errores de bloqueo (ORA-60)
• Operaciones administrativas, como sentencias CREATE, ALTER y DROP y instrucciones STARTUP, SHUTDOWN y ARCHIVELOG.
• Mensajes y errores relacionados con las funciones de los procesos de servidor compartido y despachador.
• Errores que ocurren durante la actualización automática de una vista materializada.
• Los valores de todos los parámetros de inicialización que tenían valores no predeterminados al iniciarse la base de datos y la instancia.

Los archivos de seguimiento se escriben en nombre de los procesos del servidor siempre que se produzcan errores críticos. Además, al establecer el parámetro de inicialización SQL_TRACE = TRUE, el recurso de rastreo SQL genera estadísticas de rendimiento para el procesamiento de todas las sentencias SQL de una instancia y las escribe en el repositorio de diagnóstico automático. 
Opcionalmente, puede solicitar que se generen archivos de seguimiento para los procesos del servidor. Independientemente del valor actual del parámetro de inicialización SQL_TRACE, cada sesión puede habilitar o deshabilitar el registro de trazas en nombre del proceso del servidor asociado mediante la instrucción SQL ALTER SESSION SET SQL_TRACE. 

Este ejemplo habilita el recurso de rastreo de SQL para una sesión específica:

ALTER SESSION SET SQL_TRACE TRUE;

Puede ver y cambiar las configuraciones de umbral para las métricas de alertas del servidor mediante los procedimientos SET_THRESHOLD y GET_THRESHOLD del paquete de PL / SQL, DBMS_SERVER_ALERTS.

SELECT
    metrics_name,
    warning_value,
    critical_value,
    consecutive_occurrences
FROM
    dba_thresholds
WHERE
    metrics_name LIKE '%CPU Time%';

Vista	Descripción
DBA_THRESHOLDS	Enumera los valores de umbral definidos para la instancia
DBA_OUTSTANDING_ALERTS	Describe las alertas pendientes de la base de datos
DBA_ALERT_HISTORY	Enumera un historial de alertas que se han borrado
V$ALERT_TYPES	Proporciona información como grupo y tipo para cada alerta
V$METRICNAME	Contiene los nombres, identificadores y otra información sobre las métricas del sistema
V$METRIC	Contiene valores de métrica a nivel de sistema
V$METRIC_HISTORY	Contiene un historial de valores de métrica a nivel de sistema

Utilice los paquetes DBMS_SESSION o DBMS_MONITOR si desea controlar el seguimiento de SQL para una sesión.

El paquete DBMS_MONITOR le permite utilizar PL / SQL para controlar el rastreo adicional y la recopilación de estadísticas.

Proceso PLSQL	Descripción
CLIENT_ID_STAT_DISABLE	Inhabilita la recopilación estadística habilitada previamente para un identificador de cliente determinado
CLIENT_ID_STAT_ENABLE	Permite la recopilación estadística de un determinado identificador de cliente
CLIENT_ID_TRACE_DISABLE	Deshabilita la traza activada previamente para un identificador de cliente determinado globalmente para la base de datos
CLIENT_ID_TRACE_ENABLE	Habilita la traza de un identificador de cliente determinado globalmente para la base de datos
DATABASE_TRACE_DISABLE	Deshabilita la traza de SQL para toda la base de datos o una instancia específica
DATABASE_TRACE_ENABLE	Habilita la traza de SQL para toda la base de datos o una instancia específica
SERV_MOD_ACT_STAT_DISABLE	Inhabilita la recopilación estadística activada para una combinación dada de Nombre del servicio, MÓDULO y ACCIÓN
SERV_MOD_ACT_STAT_ENABLE	Permite la recopilación de estadísticas para una combinación dada de Nombre del servicio, MÓDULO y ACCIÓN
SERV_MOD_ACT_TRACE_DISABLE	Deshabilita la traza para TODAS las instancias habilitadas para una combinación o una combinación dada de Nombre de servicio, MÓDULO y ACCIÓN nombre globalmente
SERV_MOD_ACT_TRACE_ENABLE	Habilita el rastreo de SQL para una combinación dada de Nombre de servicio, MÓDULO y ACCIÓN globalmente a menos que se especifique un nombre_instancia
SESSION_TRACE_DISABLE	Deshabilita la traza previamente habilitada para un identificador de sesión de base de datos (SID) en la instancia local
SESSION_TRACE_ENABLE	Habilita la traza de un identificador de sesión de base de datos (SID) en la instancia local

Comprueba si hay dbms jobs ejecutándose y comprueba los estados del mismo.

ORACLE ofrece una cola para planificar operaciones rutinarias en una base de datos. La funcionalidad de los Jobs de Oracle es parecida al cron de UNIX en el cual se puede planificar una tarea, a una determinada hora y con una periodicidad concreta pero en base de datos.

El paquete encargado de hacer esta planificación es DBMS_JOB.

Para que cualquier Job de Oracle se pueda ejecutar tenemos que tener en cuenta el parámetro job_queue_processes no esté a cero, ya que es el que nos indica el número de colas que gestionarán nuestros jobs. Este parámetro debe de ser mayor del número de jobs que se desee ejecutar de forma simultánea (el máximo es 1000 para Oracle).

Las vistas que podemos usar para manejar los jobs son:

• DBA_JOBS: Muestra la información de todos los jobs de la base de datos.
• ALL_JOBS: Muestra la misma información que dba_jobs pero sólo los jobs a los cuales puede acceder el usuario actual con el que se está realizando la consulta.

Para consultar todos los jobs:

select * from all_scheduler_jobs;

Consultar log de ejecución de jobs:

select * from all_scheduler_job_log order by log_date desc;

Consultar los jobs que están en ejecución:

select * from all_scheduler_running_jobs;

Detener un job:

exec dbms_scheduler.stop_jop('USER.JOB');

Se puede forzar la parada de un job ejecutando la siguiente query como usuario system:

exec dbms_scheduler.stop_job('USER.JOB', true);

Deshabilitar un Job:

exec dbms_scheduler.disable('USER.JOB');

Se puede forzar la deshabilitación de un job ejecutando la siguiente query como system:

exec dbms_scheduler.disable('USER.JOB', true);

Habilitar un Job:

exec dbms_scheduler.enable('USER.JOB');

Arrancar un Job:

exec dbms_scheduler.run_job('USER.JOB');