Mostrando entradas con la etiqueta Oracle Database. Mostrar todas las entradas
Mostrando entradas con la etiqueta Oracle Database. Mostrar todas las entradas

03 enero 2019

¿Oracle 18c for Exadata en Virtualbox? ¡Sí se puede!

El software Oracle Database 18c está disponible para las instalaciones de Exadata y se puede descargar desde aquí

  • La versión 18c se dió a conocer en el mes de julio de 2018.
  • Esto está en línea con la política de Oracle Cloud & Engineered Systems First.

Esta primera instalación de Oracle Database 18c ahora se está ejecutando en una VM de VirtualBox, está claro que solo vale para para jugar con las nuevas funciones.

El mérito del siguiente truco a añadir a nuestro grimorio no es mio sino de  @andrewlacy2.

Aquí están los pasos que he tomado:

  • Como VM: Oracle virtual box OEL 7.4 instalación mínima
  • ssh conectar como root a mi instancia de vbox
  • configurar oracle yum repo
  • yum install oracle-database-server-12cR2-preinstall   
  • usermod -a -G vboxsf oracle #grant permiso para el acceso compartido de archivos vbox
  • mkdir -p / u01 / app /
  • chown oracle: oinstall / u01 / app
  • su - oracle
  • mkdir -p /u01/app/oracle/product/18.0.0/dbhome_1
  • cd /u01/app/oracle/product/18.0.0/dbhome_1
  • Descomprima /media/sf_CSoftware/Oracle/Ora18c/V974953-01.zip
  • export DISPLAY = <my-vbox-ip>: 0.0
  • export ORACLE_HOME = / u01 / app / oracle / product / 18.0.0 / dbhome_1
  • cd $ ORACLE_HOME
  • ./runInstaller & 
Sólo instalamos el software y luego creamos la base de datos mediante DBCA
  • ./bin/dbca -createDatabase -initParams „_exadata_feature_on = true“


Et Voilá, ya tenemos una VM con una base de datos 18c con características EXADATA, para cacharrear. Ni que decir tiene los años luz, que estamos de un verdadero EXADATA amiguitos.

04 octubre 2018

PL/SQL: Server Result cache otra herramienta más en nuestro cinturón


Una característica desde Oracle 11g, el llamado Result Cache, es una herramienta poderosa que se puede usar para almacenar en la memoria resultados de consultas y funciones. La información almacenada en caché se almacena en un área dedicada dentro de la Shared Pool donde puede ser compartida por otros programas PL/SQL que realizan cálculos similares. Si los datos almacenados en este caché cambian, los valores que se almacenan en el caché pierden su validez. Esta función es útil para las bases de datos con sentencias que necesitan acceder a un gran número de filas y devolver solo algunas de ellas. Como puede ocurrir en tiendas online, bancos, etc, ...

La caché de resultados se configura utilizando el parámetro de inicialización result_cache_mode con uno de estos tres valores:

  • auto: los resultados que deben almacenarse se resuelven mediante el optimizador de Oracle
  • manual: Almacene en caché los resultados indicando la declaración usando la sugerencia result_cache | no_result_cache
  • force: todos los resultados serán cacheados.

El paquete dbms_result_cache se usa para proporcionar las opciones de administración de DBA de la memoria utilizada tanto por la caché de resultados de SQL como por la caché de resultados de la función PL / SQL. Estos son los procedimientos y funciones del paquete dbms_result_cache:


A continuación se describe una descripción práctica de cómo utilizar estos procedimientos y funciones.

Para este ejemplo, la result cache de SQL se muestra y se explica cómo limpiar la memoria caché de resultados y cómo utilizar las sugerencias para corregir los resultados de una consulta en la memoria caché de resultados. Primero, eche un vistazo a los parámetros de inicialización del caché de resultados. Todos están configurados en sus valores predeterminados; por lo tanto, es necesario usar la sugerencia result_cache para mantener los resultados de las consultas en la memoria, ya que el parámetro de inicialización result_cache_mode es manual.



Ahora consulta las vistas de caché de resultados que proporcionan información como objetos en memoria, dependencias de relación y estadísticas de caché de resultados.


Seguimos con la comprobación



Ejecute la operación "flush" para eliminar todos los objetos de la memoria caché de resultados. Existe la opción de conservar o liberar la memoria y / o las estadísticas según sea necesario. Aquí se encuentran todas las posibilidades de vaciar el caché de resultados:


Es muy fácil mantener los resultados de las consultas en la memoria, pero presta atención a la columna de invalidaciones de la tabla v $ result_cache_objects. Esta columna muestra cuándo los resultados asociados a un objeto en la memoria dejan de ser válidos debido a una modificación de los datos.

El parámetro result_cache se usa para que los resultados devueltos por esta función se almacenen en la memoria caché hasta que se modifiquen los datos de la tabla de empleados, lo que invalidará los resultados almacenados en caché para esta función.



24 noviembre 2017

Dimensionamiento de la base de datos.

Toca crear una base de datos para un nuevo proyecto y llegan las ¡Vaya preguntas!  como por ejemplo: ¿Cuánto disco necesito para mi nueva base de datos Oracle? Suponemos que nuestra instalación no tiene ASM instalado, de ser esto cierto, no necesitas seguir leyendo mas este artículo, bueno tendrás que leer algo si quieres tener en cuenta los demás componentes de tu instalación.

ASM es un administrador de volúmenes y un sistema de archivos para bases de datos Oracle que admite configuraciones de base de datos Oracle de una sola instancia y Oracle Real Application Clusters (Oracle RAC). ASM es la solución de administración de almacenamiento recomendada de Oracle que proporciona una alternativa a los administradores de volúmenes convencionales, sistemas de archivos y dispositivos sin formato.

Pasemos a mi receta:

  • 8-10 veces el volumen de datos en bruto para un sistema OLTP
  • 2-4 veces el volumen de datos en bruto para un Almacén de datos.
  • Cuanto más grande sea la base de datos, más cerca estará de los factores de multiplicación inferiores.

Aclaración: Por supuesto, esta es solo mi opinión, basada en alguna que otra experiencia. Si usas las cifras anteriores para un proyecto real y no obtienes el espacio total en disco que necesitas, no me eches las culpas ;P. Si lo haces y está bien, entonces por supuesto, ahora me debes una cerveza :)

Muchos de nosotros probablemente hemos tenido que calcular el tamaño esperado de una base de datos antes (bajo la atenta mirada del manager, en el momento de hacer el pliego de una oferta), pero la base de datos real es solo un componente de todo lo que necesita para ejecutar Oracle en tu sistema. También debe dimensionar los demás componentes:

  • Registros de rehacer archivados (redo logs), 
  • Área de preparación de copias de seguridad, 
  • Área de transferencia de datos. 
  • Archivos externos, si los hubiera. 
  • El sistema operativo. 
  • Espacio de intercambio (swap), 
  • Espacio para los ficheros log, trace, dump
  • Los "benditos" binarios de Oracle (que generalmente aumentan cada año) etc ...


En primer lugar, debe saber la cantidad de "datos sin procesar" que tiene. Con esto me refiero a lo que se convertirá en la tabla de datos. Ya a principios de este siglo, este podía ser el tamaño total de los archivos planos que usaba el sistema anterior, incluso el tamaño de los datos tal como estaba en las hojas de cálculo. Un archivo de exportación de Oracle del sistema también da una idea bastante buena del volumen de datos en bruto. Al carecer de todo esto, entonces necesitas un tamaño aproximado de tus datos brutos. Haz un cálculo esta manera:

  • "numero_de_filas * Suma_de_columnas" para tus 10 tablas más grandes. Y no tengas la tentación de sobreestimar, mis multiplicadores te permiten el relleno.

Digamos que ya has hecho esto y son 60GB de datos sin formato para un sistema OLTP. Deja que los chicos de almacenamiento sepan que probablemente querrás 500GB de espacio. Luego mentalmente lo dejarán como "sin consecuencias", ya que probablemente tengan muchos terabytes de almacenamiento. Luego he de aclarar una cosa: No estoy considerando la redundancia en absoluto, en el espacio que se proporciona. 

Si obtienes 5TB de datos brutos para un sistema DW, necesitará alrededor de 12-15 TB de almacenamiento en disco.

Si obtienes más de un Terabyte de datos en bruto para un sistema OLTP o de 10 a 20 Terabytes para un DW, cuando le das cifras a los chicos de almacenamiento , entonces es posible que palidezcan y digan algo como " ¡tienes que estar bromeando!". Esto es parte de por qué el factor de multiplicación para Data Warehouses y sistemas más grandes en general es menor, ya que se lo fuerza a tener más cuidado con el espacio que asigna y cómo lo usa.

La sobrecarga del espacio total en el disco sobre los datos Raw se reduce a medida que la base de datos se agranda por varias razones:

  • El tamaño de los binarios de Oracle y el sistema operativo no cambia a medida que la base de datos crece.
  • El tamaño del espacio de intercambio no aumenta en línea con la base de datos ya que, en términos generales, si aumenta el tamaño de la base de datos de 100 GB a 1 TB, no puede darse el lujo de aumentar la memoria del sistema de su servidor. Probablemente se duplique.
  • Las bases de datos muy grandes tienden a tener algo que las hace grandes, como imágenes o documentos incrustados, que no están indexados. Por lo tanto, la relación de segmentos de tabla a segmentos de índice aumenta.
  • Si tienes una base de datos muy grande, empieza a eliminar índices (a menudo aquellos que soportan restricciones) para ayudar al rendimiento de la carga y administración de datos, nuevamente mejorando la proporción de segmentos de tabla a segmentos de índice.
  • Las copias de seguridad se vuelven parciales o incrementales para reducir el tamaño y la duración de la copia de seguridad.
  • Como se mencionó anteriormente, el tamaño del sistema es tal que se debe tener más cuidado al limpiar las áreas de trabajo, reducir las áreas archivadas de registro de rehacer (esos archivos se comprimen bien) y otras áreas.
  • Si las cosas se vuelven extremas usted comienza a alterar PCTFREE y verificando el tamaño de las extensiones, aunque estos problemas de dimensionamiento desaparecen con Oracle ASM.

20 noviembre 2017

¿Hay vida más allá de Oracle? El Oráculo en la nube de las amazonas



Como bien reza el título del artículo sacado de una película de serie b de los cincuenta, en este artículo vamos a abordar como Amazon Web Services (AWS) te ofrece la posibilidad de ejecutar nuestra base de datos favorita en su nube pública. 

La ejecución de Oracle Database en la nube de AWS es muy similar a  ejecutar Oracle Database en su centro de datos. Para un administrador o desarrollador de base de datos, no hay diferencias entre los dos entornos. Sin embargo, hay una serie de consideraciones de la plataforma AWS relacionadas con

  • La seguridad
  • El almacenamiento de la información
  • La gestión de la configuración 
  • Administración y monitoreo de la base de datos

que nos facilitan a obtener lo mejor de su base de datos Oracle implementación en AWS

En este artículo proporcionaremos las mejores prácticas para lograr  un mejor rendimiento, disponibilidad y confiabilidad óptimas, y, por supuesto, un menor coste  (TCO) mientras ejecuta Oracle Database en AWS

El público objetivo para este artículo incluye administradores de bases de datos, arquitectos empresariales, administradores de sistemas y desarrolladores que deseen ejecutar su base de datos Oracle en AWS.


Introducción a AWS

Amazon Web Services (AWS) proporciona un conjunto integral de servicios y herramientas para implementar Oracle Database en la infraestructura confiable y segura de nube de AWS. AMAZON ofrece a sus clientes dos opciones para ejecutar Oracle Database en AWS:

Amazon RDS para bases de datos Oracle

Utilizando Amazon Relational Database Service (Amazon RDS) para Oracle, que es un servicio de base de datos administrado que ayuda a simplificar el aprovisionamiento y la administración de bases de datos Oracle. Amazon RDS facilita la configuración, el funcionamiento y la escalabilidad de una base de datos relacional en la nube al automatizar la instalación, el aprovisionamiento y la administración del disco, el parcheo, las actualizaciones menores de la versión, el reemplazo fallido de instancias y las tareas de respaldo y recuperación.

La función Multi-AZ de Amazon RDS opera dos bases de datos en múltiples zonas de disponibilidad con replicación síncrona, creando así un entorno de alta disponibilidad con failover automático. La función de escalado de botón de Amazon RDS le permite escalar la instancia de la base de datos hacia arriba y hacia abajo fácilmente para una mejor gestión de costos y rendimiento. Amazon RDS también viene con una opción de licencia incluida, que permite pagar por uso por hora.

Base de datos Oracle autogestionada Amazon EC2

Ejecución de una base de datos Oracle autogestionada directamente en Amazon Elastic Compute Cloud (Amazon EC2). Esta opción le brinda control total sobre la configuración de la infraestructura y el entorno de la base de datos. Ejecutar la base de datos en Amazon EC2 es muy similar a ejecutar la base de datos en su propio servidor. Tu tienes el control  total de la base de datos y tienes acceso a nivel de sistema operativo, por lo que puedes ejecutar agentes de supervisión y administración y usar tu elección de herramientas para la replicación de datos, la copia de seguridad y la restauración. Además, tiene la capacidad de utilizar cada módulo opcional disponible en Oracle Database. Sin embargo, esta opción requiere que se configure, administre y ajuste todos los componentes, incluidas las instancias de Amazon EC2, los volúmenes de almacenamiento, la escalabilidad, las redes y la seguridad, según las mejores prácticas de arquitectura de AWS.


Arquitecturas para seguridad y rendimiento

Ya sea que elijas ejecutar Oracle Database en Amazon RDS o Amazon EC2, la optimización de cada componente de la infraestructura mejorará la seguridad, el rendimiento y la confiabilidad. En las siguientes secciones, analizaremos las mejores prácticas para optimizar la configuración de la red, el tipo de instancia y el almacenamiento de la base de datos en una implementación de Oracle Database en AWS.

Configuración de la red

La nube privada virtual de Amazon (Amazon VPC) le permite aprovisionar una sección aislada lógicamente de la nube de AWS que está dedicada a su cuenta. Tiene control total sobre su entorno de red virtual, incluida la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de rutas y puertas de enlace de red, y la configuración de seguridad.
Una subred es un rango de direcciones IP en su Amazon VPC. Puede iniciar los recursos de AWS en una subred que seleccione. Utilice una subred pública para recursos que deben estar conectados a Internet, y una subred privada para recursos que no estarán conectados a Internet.
Para proteger los recursos de AWS en cada subred, puede usar varias capas de seguridad, incluidos los grupos de seguridad y las listas de control de acceso a la red (ACL).
La siguiente tabla describe las diferencias básicas entre los grupos de seguridad y las ACL de red.


Amazon VPC proporciona aislamiento, seguridad adicional y la capacidad de separar instancias de Amazon EC2 en subredes, y permite el uso de direcciones IP privadas. Todos estos son importantes en la implementación de la base de datos. Implemente la instancia de Oracle Database en una subred privada y permita que solo los servidores de aplicaciones dentro de Amazon VPC, o un host Bastion dentro de Amazon VPC, accedan a la instancia de la base de datos. Cree grupos de seguridad apropiados que permitan el acceso solo a direcciones IP específicas a través de los puertos designados. Estas recomendaciones se aplican a Oracle Database independientemente de si está utilizando Amazon RDS o Amazon EC2.

Sobre las licencias Oracle

Como se indica en el documento de Oracle en el site My Oracle Support Doc ID: 2174134.1, Oracle es totalmente compatible con la implementación de Oracle Database en AWS. (Si quieres ver el documento, ha de registrarse para obtener una cuenta de Oracle, que es gratuita.) Las licencias de Oracle Database en AWS se basan en el tamaño de la instancia en la que está instalada la base de datos. 
Algunos puntos clave:

  • El recuento de núcleos virtuales de las instancias de Amazon EC2 se considera igual al recuento de núcleos físicos para fines de licencia. Para conocer el recuento de núcleos virtuales de cada tipo de instancia de Amazon EC2, consulte Núcleos virtuales de Amazon EC2 y Tipo de instancia de base de datos de RDS.
  • Oracle Database Standard Edition solo puede tener licencia en instancias de Amazon EC2 que tengan hasta 16 núcleos virtuales.
  • Oracle Standard Edition One y Standard Edition Two solo pueden tener licencia en instancias de Amazon EC2 que tengan hasta 8 núcleos virtuales.
  • Para Oracle Database Standard Edition, Standard Edition One o Standard Edition Two, las instancias de Amazon EC2 con 4 o menos núcleos virtuales se cuentan como un solo socket.
  • Para Oracle Database Enterprise Edition, las instancias de Amazon EC2 con 2 o menos núcleos virtuales se cuentan como un solo socket.

Portabilidad de licencia de Oracle a AWS

Sujeto a los términos y condiciones del acuerdo de licencia específico, las licencias de Oracle pueden ser transferibles a AWS. En otras palabras, sus licencias existentes se pueden transferir para su uso en AWS. Éstas incluyen:

  • Licencias basadas en servidor (basadas en CPU utilizadas)
  • Acuerdos de licencia empresarial (ELA)
  • Acuerdos de licencia ilimitados (ULA)
  • Licencias de Business Process Outsourcing (BPO)
  • Licencias de Oracle PartnerNetwork (OPN)
  • Licencias de User Plus con nombre

Es posible que se apliquen condiciones o limitaciones adicionales (incluidos los posibles costos) para las licencias que se transfieren a AWS. Verifique su contrato de licencia específico para obtener detalles y limitaciones adicionales.

Las licencias de Oracle se aplican de manera similar a Oracle Database en Amazon RDS y en Amazon EC2, con la excepción de que las licencias por hora solo están disponibles en Amazon RDS.

Conclusión

Dependiendo de su escenario de uso, puede utilizar Amazon RDS para Oracle Database o ejecutar una base de datos Oracle autogestionada en Amazon EC2. Independientemente de su elección, seguir las mejores prácticas proporcionadas en este artículo te ayudará a aprovechar tu implementación de Oracle Database en AWS.

01 octubre 2017

¿Sabías que existía la herramienta ORAchk?


La herramienta de Oracle ORAchk incluye funciones EXAchks y RACcheck y reemplaza las herramientas más antiguas. Ya no es sólo una herramienta de base de datos, sino que también realiza comprobaciones sobre E-Business Suite Financials, el repositorio de Cloud Management para Enterprise Manager, GoldenGate y Sun Systems.

La utilidad ORAchk (Oracle Check) se conocía anteriormente como RACchk. En su encarnación más antigua, RACchk examinó la configuración del sistema Oracle RAC buscando las áreas que necesitaban mejoras. Oracle Corporation decidió extender la utilidad para incluir algo más que una base de datos Oracle y centrarse en toda la pila de software de Oracle. ORAchk ahora examina las siguientes áreas.


  • Oracle Database (tanto RAC como de instancia única)
  • Control de la nube de Enterprise Manager 12c
  • Servidores Oracle Sun
  • Oracle E-Business Suite


Independientemente del componente de software de Oracle que se esté examinando, ORAchk está analizando la configuración buscando problemas. Puede proporcionar un informe que muestre riesgos para la salud. Se recomienda que el administrador de la base de datos ejecute un informe antes y después de los cambios de configuración del software para comprender si esos cambios pueden causar problemas futuros. Dado que este libro es para el rendimiento de la base de datos Oracle RAC, sólo se discutirá el primer componente de Oracle en la lista anterior. Los otros 3 componentes de software están fuera del alcance de este libro.


La utilidad ORAchk se puede descargar de la Nota 1268927.1 de Oracle My Support. La descarga es un simple archivo zip. Después de descargar el archivo, utilice la utilidad OS unzip para extraer su contenido. La instalación se completa después de descomprimir el archivo. Ejecute el ejecutable orachk para iniciar el análisis. De forma predeterminada, orachk le pedirá que verifique la ubicación actual de Grid Infrastructure. A continuación, orachk verifica la equivalencia de usuario ssh.

Características de ORAchk:


  • Escanea de forma proactiva los problemas conocidos más impactantes a través de todo su sistema, así como varias capas de su apilar Simplifica y optimiza la forma de investigar y analizar qué problemas conocidos presentan un riesgo para usted.
  • La herramienta ligera funciona dentro de nuestro entorno; no se enviarán datos a Oracle..
  • Los informes de alto nivel muestran los riesgos para la salud del sistema con la capacidad de profundizar en problemas específicos y entender sus resoluciones.
  • Se puede configurar para enviar notificaciones por correo electrónico cuando detecta problemas.
  • Administrador de recopilación, una aplicación complementaria Application Express proporciona una vista única de las colecciones en toda la empresa.
  • ORAchk se expandirá en el futuro con un mayor impacto; controles en áreas de productos existentes y adicionales. 


Para obtener más información sobre la herramienta ORAchk, cómo descargarlo, qué hay de nuevo en ORAchk, lea MOS Nota 1268927.2. Si no tienes acceso a MOS, aquí hay una entrada de blog que describen bastante bien la herramienta:




11 septiembre 2017

¿Qué es CPU, PSU, SPU?



Esta es una pequeña entrada para explicar ciertos conceptos y terminologia de la herramienta de actualización de las bases de datos, Oracle Critical Patch.

Todo comenzó en enero de 2005 con Actualizaciones críticas de parches, CPU. A continuación, las Actualizaciones de conjuntos de parches (PSU) se agregaron como parches acumulativos que incluían correcciones de prioridad y arreglos de seguridad. A partir de la actualización de revisión crítica de octubre de 2012, Oracle ha cambiado la terminología para diferenciar mejor los tipos de parches. Esta terminología se utilizará para la base de datos Oracle, Enterprise Manager, Fusion Middleware y WebLogic.

Actualización de revisión crítica (CPU) ahora se refiere a la liberación general de revisiones de seguridad cada trimestre en lugar de la revisión de seguridad de base de datos acumulativa para el trimestre. Piense en la CPU como la versión trimestral general y no como un solo parche.

Patch Set Updates (PSU) son los mismos parches acumulativos que incluyen las correcciones de seguridad y las correcciones de prioridad. La clave con las PSU es que son actualizaciones menores de la versión (por ejemplo, 11.2.0.1.1 a 11.2.0.1.2). Una vez que se aplique una PSU, sólo se pueden aplicar PSU en trimestres futuros hasta que la base de datos se actualice a una nueva versión base.

La terminología de Actualización de revisión de seguridad (SPU) se presenta en la actualización de revisión crítica de octubre de 2012 como el término para el parche de seguridad trimestral. Los parches SPU son los mismos que los parches anteriores de la CPU, sólo un nuevo nombre. Para la base de datos, las SPU no se pueden aplicar una vez que se hayan aplicado PSU hasta que la base de datos se actualice a una nueva versión base.

Bundle Patches son los parches trimestrales para Windows y Exadata que incluyen tanto los parches de seguridad trimestrales como las revisiones recomendadas.

Etiqueta:
El nombre de un conjunto de cambios (por ejemplo, la fijación de un error) en el código fuente; la salida de una etiqueta es un conjunto de archivos C (* .c, * .h etc)

Conflicto. Dos o más correcciones de errores que modifican los mismos archivos de código fuente; si este es el caso, sólo se puede aplicar uno, de lo contrario el código de las correcciones tendrá que ser "fusionado" para producir una nueva etiqueta

Interim Patch. Este es el nombre oficial para un parche único. Solución de errores única.

Merge Patch:Esta es una combinación de etiquetas; si por ejemplo tiene dos correcciones de errores que tocan los mismos archivos, entonces tendría que tener esas revisiones fusionadas, produciendo un nuevo parche con una nueva etiqueta

Overlay Patch: Cuando un parche interino de una sola vez entre en conflicto con una PSU, se requiere un parche de superposición. Esto es básicamente una fusión del parche que desea y la PSU.

Overlay PSU: Durante el ciclo de vida de un patchset, las PSU normalmente se publicarán cada trimestre. A medida que el patchset alcanza su madurez, se podría esperar que haya errores menos críticos que puedan ser considerados como candidatos para su inclusión en PSU.
En algún momento el número de correcciones de errores incluidas en cada PSU alcanzará un número suficientemente bajo que ya no se considera que vale la pena hacer la PSU acumulativa.
En este punto, la PSU anterior se convierte en una línea de base y todas las futuras PSU se liberan como "superposición de PSU".

Si quieres ahondar mas en esta nomenclatura consulta la siguiente nota del Oracle Metalink, sí lo sigo llamando ¡así! : Nueva Nomenclatura de Patches para Productos Oracle [ID 1430923.1]

31 julio 2017

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>


28 noviembre 2016

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í.

23 noviembre 2016

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;


21 noviembre 2016

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');