Herramientas de Administración Para Oracle Database 12c

Newsletter Julio 2014
Herramientas de Administración Para Oracle
Database 12c
Contenido
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. 5-55 Zona14,Edificio Euro Plaza TorreEn
II, Nivel
12
versiones
Teléfono: (502)2364-5300Fax: (502)2364-5311
previas a Oracle Database 12c, existen varias alternativas para
administrar la base de datos:
Pagina 1/10
Email.info@datum.com.gt
Editores Generales
Francisco Barrundia

Enterprise Manager Database Console (EM DB Console o DB Console): Esta
herramienta se configura y corre en el mismo servidor de base de datos.
Ofrece una funcionalidad completa para administrar y afinar la base de datos.
Se accede desde un browser.

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.
Alejandro Lau
Débora Morán
Autores
Contribuyentes
Alejandro Lau
Marlon Pérez
Francisco Barrundia
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 1
Cambios en Oracle Database 12c
Con la versión 12.1.0 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.
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 2
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
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 3
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
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 4
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
1
operaciones DML , 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
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 5
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
2
proceso 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.
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 6
Reducir el Tamaño del Tablespace UNDO
Por Lic. Francisco Barrundia
fbarrundia@datum.com.gt
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
------------------------------ --------------- ------/database/dba11g/undotbs01.dbf UNDOTBS1
TOTAL_SIZE_MB
-------------
600
600
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 UNDOTBS2
300
300
Ahora, ya podemos borrar el tablespace UNDO antiguo. Lo hacemos de la siguiente forma:
SQL> DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 7
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
undo_retention
string
integer
AUTO
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
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
newsletter@datum.com.gt
Página 8