Herramientas de Administración Para Oracle Database 12c

Transcripción

1 Newsletter Julio 2014 Contenido Herramientas de Administración Para Oracle Database 12c Página: 1 Herramientas de Administración Para Oracle Database 12c 5 Optimización de Procesos Automáticos que Utilizan DDL en Aplicaciones o Base de Datos Parte 1 7 Reducir el Tamaño del Tablespace UNDO Por Ing. Alejandro Lau alau@datum.com.gt 5a. Ave Zona14,Edificio Euro Plaza Torre En II, Nivel versiones 12 previas a Oracle Database 12c, existen varias alternativas para Teléfono: (502) Fax: (502) administrar la base de datos: .info@datum.com.gt Editores Generales Pagina 1/10 Enterprise Manager Database Console (EM DB Console o DB Console): Esta Francisco Barrundia herramienta se configura y corre en el mismo servidor de base de datos. Alejandro Lau Ofrece una funcionalidad completa para administrar y afinar la base de datos. Débora Morán Se accede desde un browser. Autores Contribuyentes Alejandro Lau Marlon Pérez Francisco Barrundia Enterprise Manager Grid Control (abreviado Grid Control): Ofrece la mayor funcionalidad de administración. Se pueden integrar muchos targets en una única consola: bases de datos, hosts, servidores de aplicación, agentes, listeners, etc. Otros: Adicionalmente, hay otras herramientas que ofrecen alguna funcionalidad administrativa limitada. Por ejemplo Oracle SQL Developer, Enterprise Manager cliente (java), herramientas de terceros. SQL Plus: Siempre se dispone de sqlplus como herramienta de administración. Claro que se deben conocer los comandos SQL para realizar las tareas a este nivel. Página 1

2 Cambios en Oracle Database 12c Con la versión de la base de datos, tenemos nuevas herramientas de administración: Enterprise Manager Database Express (DB Express): A partir de Oracle Database 12c, dejó de existir DB Console. En su lugar tenemos DB Express. No confundir con la base de datos Express Edition. DB Express ofrece una funcionalidad más limitada que DB Console y está pensada para una administración diaria. Ofrece cierta administración de rendimiento, diagnóstico, afinación, configuración. DB Express es más liviano que DB Console y consume muy poco recurso de disco, CPU y memoria en el servidor de base de datos. Tiene una interfaz web con un menú jerárquico. Enterprise Manager Cloud Control (abreviado Cloud Control): La recomendación de Oracle es utilizar EM Cloud Control, que sustituye al EM Grid Control. Esta sigue siendo la herramienta más completa de administración. Su interfaz también es web y maneja un menú jerárquico estilo drop-down, en vez de links. Página 2

3 Una razón para no implementar Cloud Control 12c de inmediato es que requiere un servidor separado, de igual forma que Grid Control, pero con más recurso de memoria y procesador para un buen desempeño. Se recomiendan 16 GB de RAM. SQL Developer 4.0.1: La versión más reciente de SQL Developer ofrece un navegador para DBAs. Se accede desde el menú View -> DBA y ofrece más funcionalidad que las versiones previas. Su principal uso es para tareas de configuración. Como observamos en la gráfica siguiente, se pueden ejecutar operaciones de: Configuración de base de datos (parámetros de inicialización, UNDO, restore points) Tareas de Data Pump (export, import, monitorización) Administración de rendimiento (snapshots, baselines, ADDM, ASH, AWR) Tareas y configuración de RMAN (settings, generar backups, monitorización) Administración de Resource Manager y Scheduler Administración de seguridad (usuarios, roles, perfiles) y almacenamiento Página 3

4 Adicional a este navegador para DBAs, en el menú Tools hay varias opciones de administración como: Database Copy: copia objetos, esquemas o un tablespace de una base de datos a otra Database Diff: muestra diferencias entre objetos de dos esquemas, de la misma o distintas bases de datos Database Export: genera scripts DDL (SQL) para objetos de la base de datos Migration: para migrar bases de datos de terceros hacia Oracle Monitor SQL: muestra SQLs en memoria y su plan de ejecución Monitor Sessions: muestra sesiones en la base de datos, sus SQLs asociados Otras Página 4

5 Optimización de Procesos Automáticos que Utilizan DDL en Aplicaciones o Base de Datos Parte 1 Por Ing. Marlon Pérez mperez@datum.com.gt Introducción En muchas ocasiones, al desarrollar aplicaciones empresariales, se desarrollan procesos que se ejecutan automáticamente para procesar grandes volúmenes de información con el objetivo de resumir, conciliar o procesar información recopilada durante un período de tiempo. Frecuentemente, estos procesos tienden a degradarse y a requerir mucho tiempo para su ejecución. Por este motivo, es necesario establecer una metodología para optimizar procesos automáticos y para verificar que el rendimiento cumpla con los requerimientos y expectativas de los usuarios. Metodología para optimizar el acceso a los datos en los procesos automáticos Para optimizar un proceso automático, se puede realizar una serie de tareas que permiten identificar y mejorar el rendimiento de los accesos a la información que el proceso automático requiere para su operación. A continuación se presentan las tareas sugeridas para esta optimización. 1. Estandarizar código y comentarios escritos: Esta tarea facilita la comprensión de las operaciones DML 1, esto incluye filtros, relaciones y condiciones, así como el uso de la información. Este proceso facilita identificar datos que no son necesarios y procesos que podrían optimizarse. Por ejemplo, disminuir la cantidad de instrucciones UPDATE. 2. Analizar uso de tablas e información: Revisar el uso de instrucciones IN, ORDER BY y DISTINCT para buscar formas de lograr el mismo resultado utilizando opciones distintas. Por ejemplo EXISTS y no utilizar datos calculados en la cláusula ORDER BY, es mucho más eficiente calcular los datos en las columnas de la sección SELECT y luego referenciarlos desde la sección ORDER BY. Es una buena práctica analizar los planes de ejecución de cada consulta y realizar pruebas de ejecución con datos masivos para establecer el tiempo que toma realizar consultas que utilizan distintas cláusulas. De esta forma se logra elegir la opción más óptima para el set de datos que se desea recuperar. 3. Analizar objetivo de los datos recuperados: Es conveniente analizar el motivo por el cual se recuperan los datos, es decir, si se obtiene un CONTEO de registros, verificar su uso, y analizar si se puede realizar la actividad con solo saber la existencia de algún registro que cumpla la condición, o si realmente se necesita contar los registros, ya que esto requiere recuperar todos los registros que cumplan las condiciones definidas. 4. Incluir una bitácora para monitorizar rendimiento: Es muy conveniente desarrollar una bitácora para medir los tiempos exactos de cada proceso, de esta forma se facilita identificar puntos con problemas de rendimiento. Esto permite enfocar los esfuerzos los componentes que provocan un bajo rendimiento para el proceso. Esta práctica también permite definir tiempos esperados para cada sección del proceso automático. 1 DML = Data ManipulationLanguage Página 5

6 Utilizar una bitácora de monitorización para procesos automáticos A continuación se presenta un modelo sencillo para desarrollar una versión básica de bitácora para monitorizar el rendimiento de cualquier proceso automático. La bitácora puede utilizarse para llevar información al detalle que sea necesario. La figura 1 muestra el modelo utilizado para desarrollar la bitácora básica para seguimiento del rendimiento de procesos automáticos. Fig. 1 ERD para gestión de bitácora de procesos automáticos El modelo de la figura 1 permite establecer, por cada proceso que se ejecute automáticamente (entidad BIT_PROCESO), si se desea monitorizar o no. En ese caso, para cada instancia de proceso 2 se genera una bitácora maestra única (puede haber concurrencia sin que exista conflicto) y cada registro maestro genera n registros detalle que describen el comportamiento del proceso automático. El desarrollador definirá el nivel al cual desee monitorizar cada proceso, para establecer si se está ejecutando de forma eficiente y si está realizando el trabajo para el cual fue concebido. Este modelo puede ampliarse a mayores funcionalidades y controles en el futuro. En la segunda parte de este artículo se presentarán algunos tips para escribir consultas que pueden ser de mucha utilidad en los procesos automáticos, principalmente con modelos de datos extensos. Se presentarán algunos ejemplos de utilización. 2 Una instancia de proceso se refiere a la ejecución específica del proceso en un momento dado, para ciertos parámetros especificados. Página 6

7 Reducir el Tamaño del Tablespace UNDO Por Lic. Francisco Barrundia En ocasiones vemos que el tablespace UNDO ha crecido mucho y lo queremos hacer más pequeño para reclamar ese espacio. La forma más sencilla de hacerlo es borrarlo y crearlo de nuevo. Para determinar qué tablespace UNDO estamos usando en nuestra base de datos y cuánto espacio ocupa, podemos realizar la siguiente consulta: SQL> SELECT file_name, tablespace_name, bytes/1024/1024 SIZE_MB, SUM(bytes/1024/1024) OVER() TOTAL_SIZE_MB FROM dba_data_files d WHERE EXISTS (SELECT 1 FROM v$parameter p WHERE LOWER (p.name)='undo_tablespace' AND p.value=d.tablespace_name); FILE_NAME TABLESPACE_NAME SIZE_MB TOTAL_SIZE_MB /database/dba11g/undotbs01.dbf UNDOTBS Antes de borrar el tablespace UNDO, deberemos crear el nuevo. La forma de crearlo es la siguiente: CREATE UNDO TABLESPACE undotbs2 DATAFILE '/database/dba11g/undotbs02.dbf' SIZE 300M AUTOEXTEND ON NEXT 1M; En este caso hemos creado un nuevo tablespace de 300M. Una vez creado, establecemos este tablespace para la base de datos. ALTER SYSTEM SET UNDO_TABLESPACE=undotbs2; Una vez realizado esto, podemos comprobar si lo hemos realizado bien, lanzando de nuevo la consulta: SQL> SELECT file_name, tablespace_name, bytes/1024/1024 SIZE_MB, SUM(bytes/1024/1024) OVER() TOTAL_SIZE_MB FROM dba_data_files d WHERE EXISTS (SELECT 1 FROM v$parameter p WHERE LOWER (p.name)='undo_tablespace' AND p.value=d.tablespace_name); FILE_NAME TABLESPACE_NAME SIZE_MB TOTAL_SIZE_MB /database/dba11g/undotbs02.dbf UNDOTBS Ahora, ya podemos borrar el tablespace UNDO antiguo. Lo hacemos de la siguiente forma: SQL> DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES; Página 7

8 Nota: Las operaciones flashbackup necesitan tener establecida la variable UNDO_RETENTION para poder funcionar correctamente. En este caso podríamos establecerlo de la siguiente forma. Si queremos modificar el parámetro de UNDO_RETENTION, lo podemos hacer con la siguiente sentencia. En este caso, lo modificamos a 900. ALTER SYSTEM SET UNDO_RETENTION = 900 scope=both; SQL> show parameter undo NAME TYPE VALUE undo_management string AUTO undo_retention integer 900 undo_tablespace string UNDOTBS2 Tip Técnico del Mes Eliminar Registros Duplicados. Si por algún motivo se insertaron registros duplicados en una tabla, ya sea porque han eliminado la llave primaria o ni siquiera la han creado y ahora la consideran necesaria; por aquí les dejo una sentencia que los puede ayudar a eliminar esos registros innecesarios: delete from tabla where rowid not in (select min(rowid) from tabla group by (col_pk1, col_pk2, col_pk3...); Donde tabla indica la tabla en cuestión y las col_pkn son las columnas que forman la llave primaria. Por Lic. Francisco Barrundia fbarrundia@datum.com.gt Página 8