El monitoreo de bases de datos es una necesidad prioritaria en un entorno que las usa.

Debe
tomarse en cuenta que las bases de datos tienen una relacin profunda con el rendimiento
general de aplicaciones y servidores, por lo que la recoleccin y anlisis de datos estadsticos
del funcionamiento de las bases de datos y su relacin con los recursos disponibles (CPU,
memoria, etc.) deben ser claros y fciles a los ojos del administrador del entorno.
Desafortunadamente, es muy comn que estos datos sean muy difciles de manejar con las
herramientas estndar de las bases de datos. Es decir, sera complicado configurar todas las
herramientas disponibles para monitorear una base de datos de tal manera que se pueda ver
fcilmente el uso de recursos por parte de la misma, aislando las dems funciones de un
servidor. Otro problema puede presentarse al utilizar mquinas virtuales (lo cual es cada vez ms
comn hoy en da), y monitorear stas mquinas con sus matices especficos.
Para solucionar estos problemas y otros, el mercado ofrece una cantidad considerable de
herramientas, cada una con sus caractersticas particulares. En esta ocasin revisar una
aplicacin que se destaca por su flexibilidad, facilidad de uso y un enfoque en mquinas
virtuales novedoso. Estoy hablando de IgniteFree.

Mantenimiento de la base de datos

Una tarea muy importante en la administracin de proyectos, es realizar un
afinamiento peridico a la base de datos que sirve de repositorio de procesos de
Bizagi.
Tenga en cuenta que cada motor de base de datos (SQL Server u Oracle) ofrece las
herramientas necesarias para realizar monitoreo preventivo, diagnsticos
(herramientas de perfilamiento), o acciones de afinamiento sobre la base de datos.
Ante esto, recomendamos al DBA lo siguiente:
1. Monitorear los logs de la base de datos.
2. Utilizar las herramientas especializadas de las bases de datos para realizar
perfilamiento y grabar trazas. Con ello se puede monitorear ciertos comportamientos
de las transacciones en la base de datos y tambin llevar a cabo diagnsticos sobre
los aspectos ms relevantes (p.e, el rendimiento).
De esta manera, el monitoreo de la instancia puede anticipar una situacin no
deseable (bloqueos, demoras, etc), y tambin conllevar a
una indicacin sobre las tareas de afinamiento.
3. Llevar a cabo un afinamiento de base de datos peridico.

Los siguientes lineamientos proveen un punto de partida as como tambin recomendaciones tiles para las
tareas de monitoreo, diagnstico y afinamiento de base de datos.
Sin embargo, estos lineamientos no abarcan extensivamente todas las tareas que un DBA debe realizar para
un mantenimiento de la base de datos (la informacin siguiente es enunciativa y no exhaustiva o taxativa).

Lineamientos para el monitoreo y diagnstico

1. No ejecutar el perfilamiento (profiler) desde el mismo servidor de base de datos.

2. Ejecute un perfilamiento que deje la traza cuando el servidor no se encuentre en

horas muy ocupadas (horario crtico de operaciones).
Podr ser til generar una traza sobre el horario crtico si el escenario lo amerita, sin
embargo, considere un muestreo para evitar afectar el rendimiento del servidor.
3. Incluya filtros en el perfilamiento (por ejemplo, inicialmente slo registre la actividad
de su base de datos).
4. Capture solamente la informacin relevante y necesaria en las trazas en cuanto a
los eventos de informacin que se graban.
Por ejemplo, en SQL Server, podr considerar los procedimientos almacenados:
RPC:Completed y TSQL--SQL:BatchCompleted.
5. Capture solamente la informacin relevante y necesaria en las trazas en cuanto a
las columnas de informacin.
Analice qu aspectos son clave para indicar el estatus del rendimiento de su base de
datos.
Por ejemplo, en SQL Server, podr considerar: el consumo de CPU, la cantidad de
escrituras
writes-, lecturas, y el tiempo de inicio y de fin.
6. De acuerdo a lo anterior, tambin podr usar filtros para alertar las transacciones
potencialmente problemticas.
Por ejemplo, puede iniciar por obtener slo aquellas cuya duracin es mayor a 3
segundos o cuyo nmero de registros afectados es muy alto.

No se recomienda que los software Antivirus realicen un escaneo sobre los archivos fsicos de la base de datos.
Lo anterior puede conllevar a bloqueos y demoras de la aplicacin al intentar persistir la informacin a la base
de datos.

Lineamientos de afinamiento
Las tareas de afinamiento se deben realizar en horarios no laborales, y considere que
tambin pueden tomar un tiempo significativo.

1. Verifique la integridad de la base de datos.

2. Reorganice y mantenga los ndices actualizados.

Dentro de esta tarea, asegrese de recrear indices los cuales estn altamente
fragmentados, o reordenar su definicin de acuerdo al orden las columnas
consultadas (especialmente cuando hablamos de ndices compuestos).

3. Actualice las estadsticas de la base de datos.

4. Realice de manera peridica tareas para reducir la base de datos (shrink) .

5. Monitoree el crecimiento y comportamiento de las siguientes tablas de Bizagi:

Workitem
Workitemcl
Wfcase
Wfcasecl

De acuerdo a lo observado, podr revisar cmo est fragmentada la informacin (p.e,

los filegroups en SQL Server o los tablespaces en Oracle).

6. Lleve a cabo tareas adicionales de afinamiento como las recomienda el motor de

base de datos y sus herramientas especficas (o de lo observado a partir de las trazas
y logs).

Tipos de evaluacin: monitoreo, resultado e

impacto

Monitoreo (proceso, formativo, evaluacin de mitad de perodo)

El monitoreo es una forma de evaluacin o apreciacin, aunque a diferencia de la evaluacin
de resultado o impacto, tiene lugar poco despus que comenz una intervencin (evaluacin
formativa), en el curso de la intervencin (evaluacin del proceso) o a mitad de camino en la
intervencin (evaluacin de mitad de perodo).
El monitoreo no es un fin en s mismo. El monitoreo permite que los programas determinen
qu est funcionando y qu no, as se pueden hacer ajustes a lo largo del camino. Permite
que los programas evalen qu est pasando realmente, versus lo que se planific.
El monitoreo permite a los programas hacer lo siguiente:

Implementar medidas correctivas para poner a los programas nuevamente en curso y

que sean responsables de los resultados que se espera que el programa logre.

Determinar cmo deberan ser distribuidos los fondos en todas las actividades
programticas.

Recolectar informacin que puede usarse en el proceso de evaluacin.

Cuando las actividades de monitoreo no las llevan a cabo directamente los tomadores de
decisiones del programa, es crucial que los hallazgos de las actividades monitoreadas se
coordinen y se los retroalimente.
Tambin se puede difundir Informacin de la actividades de monitoreo a diferentes grupos
fuera de la organizacin. Esto promueve la transparencia y da la oportunidad de conocer la
opinin de los interesados.
No existen herramientas y mtodos de monitoreo estndar. Varan de acuerdo con el tipo de
intervencin y los objetivos que se plantean en el programa. Algunos ejemplos de monitoreo
son:

Informes de monitoreo de actividades

Revisin de registros de prestacin de servicios (por ejemplo. informes policiales,

registros de caso, formularios y registros de uso de servicios de salud, otros)

Entrevista de salida con clientes (sobrevivientes)

Tcnicas cualitativas para medir actitudes, conocimiento, habilidades, comportamiento

y las experiencias de sobrevivientes, prestadores de servicios, agresores y otros a quienes
puede dirigirse la intervencin.

Revisiones estadsticas de bases de datos administrativas (es decir, en los sectores

salud, justicia e interior, albergues, oficinas de bienestar social y otros)

Otras tcnicas cuantitativas.

Evaluacin de resultados
La evaluacin de resultados mide tanto los resultados a corto plazo como lo resultados a a
largo plazo de los programas.

Por ejemplo, en un programa para fortalecer la respuesta del sector salud en casos de
violencia contra las mujeres, un resultado de corto plazo puede ser el uso de protocolos y
procedimientos estandarizados por parte de los profesionales en un centro de salud.

Un resultado a largo plazo puede ser la integracin de esas polticas en todo el sector
y el sistema de salud.

Es importante establecer claramente desde el principio de un proyecto o intervencin,

cules son los objetivos y resultados esperados, e identificar qu cambios especficos se
espera para qu poblacin en particular.

Evaluacin del impacto

La evaluacin del impacto mide la diferencia entre lo que pas habiendo implementado el
programa y lo que hubiera pasado sin l .Responde a la pregunta, Cunto del cambio
observado en la poblacin meta (si lo hubo) ocurri debido al programa o la intervencin?
Para este nivel de evaluacin se necesitan diseos de investigacin rigurosos. Es el tipo de
evaluacin ms compleja e intensiva; incorpora mtodos como la seleccin aleatoria, grupos
de control y de comparacin. Estos mtodos sirven para:

Establecer vnculos causales, o relaciones, entre las actividades que se llevan a cabo
y los resultados deseados.

Identificar y aislar todo factor externo que pueda influir en el resultado deseado.
Por ejemplo, una evaluacin del impacto de una iniciativa dirigida a la prevencin de
agresiones sexuales a mujeres y nias en el pueblo x mediante mejoras de infraestructura
(iluminacin, pasajes ms visibles, etc.) tambin puede comparar datos de otra comunidad
(pueblo y) para evaluar si las reducciones en el nmero de agresiones al finalizar el programa
pueden atribuirse a esas mejoras. El propsito es aislar otros factores que puedan haber
influido en la reduccin del nmero de agresiones, tales como la capacitacin de la polica o
nueva legislacin.
Mientras el impacto de las evaluaciones puede considerarse el estndar dorado para el
monitoreo y la evaluacin, su medicin puede representar un desafo y puede no ser viable
por muchas razones, entre ellas:

Requieren un importante volumen de recursos y tiempo, que muchas organizaciones

pueden no tener.

Para hacerlo adecuadamente, tambin necesitan que la recoleccin de datos siga una
metodologa estadstica especfica, a lo largo de un perodo de tiempo, desde una variedad de
grupos de control y de intervencin, que puede ser difcil para algunos grupos.
Puede que las evaluaciones de impacto no sean siempre necesarias o, incluso apropiadas,
para las necesidades de la mayora de los programas e intervenciones que buscan monitorear
y evaluar sus actividades.

Para medir el impacto del programa, generalmente se hace una evaluacin al principio
(llamada lnea de base o evaluacin ex-ante) y luego otra vez al final (llamada evaluacin expost) de un programa. Tambin se recaban mediciones de un grupo de control con
caractersticas similares a las de la poblacin meta, pero no se trata de recibir la intervencin
para poder comparar a ambas.

Para atribuir los cambios de resultados a una intervencin en particular, es necesario

descartar todas las otras explicaciones posibles y controlar todos los factores externos o
factores que confunden y que pueden dar cuenta de esos resultados. Una evaluacin
del impacto de una campaa para concienciar sobre las disposiciones de una ley,
recientemente aprobada, sobre violencia contra la mujer, por ejemplo, debera incorporar:
Datos de base sobre el conocimiento de las disposiciones de la ley antes de la

campaa en el grupo de la intervencin.

Datos finales sobre el conocimiento de las provisiones despus de la campaa

en el grupo de intervencin.
Datos de base o conocimiento de las disposiciones de la ley antes de la

campaa en un grupo de control que no fue expuesto a la campaa en especial para

observar si hubo factores externos/adicionales que puedan haber influido en su nivel de
conocimiento.

Si el diseo del estudio no incluye un grupo de control designado aleatoriamente, no

es posible llegar a una conclusin en cuanto a las diferencias en los resultados entre reas
con el programa y reas sin el programa.

Sin embargo, si no se pueden realizar estudios de base estadsticamente rigurosos

con grupos de control designados aleatoriamente, an se puede recabar informacin de base
muy til y valida as como informacin final.
La evaluacin requiere experiencia y entrenamiento tcnico. Si el programa no tiene
capacitacin internamente, se deben contar con asistencia de valuadores externos.

Los problemas con los cuales nos encontramos al trabajar con bases de datos grandes son distintos a
los problemas que tienen las bases de datos pequeas.
Como las empresas constantemente estn almacenando ms y ms datos las tablas van creciendo de
tamao diariamente, quizs minuto a minuto. Llega un momento en que la Base de Datos ya puede
considerarse grande.
Cundo una Base de Datos es grande?
Como muchas otras cosas en Informtica, sta tambin depende del punto de vista. Para alguien podra
ser grande y para otros pequea, aunque en general se considera grande a las bases de datos que
alcanzan o superan un tamao de 10 Gigabytes. En este blog se considera que:

Pequea. Es una Base de Datos con tamao menor a 1 Gb

Mediana. Es una Base de Datos cuyo tamao est entre 1 Gb y 10 Gb

Grande. Es una Base de Datos cuyo tamao es mayor que 10 Gb

Normalmente, si no se almacena multimedia (archivos grficos, de sonido, de vdeo, etc.) las bases de
datos van creciendo a un ritmo bastante parejo y predecible, por ejemplo podramos tener una que crece
alrededor de 1 Megabyte por da. Desde luego que algunos das crece ms y algunos das crece menos,
pero siempre est por ah cerca.
Problemas tpicos con las bases de datos pequeas

Consultas lentas

Stored procedures o triggers lentos

Soluciones tpicas a esos problemas

Optimizar las instrucciones SQL.

Realizar un ciclo backup/restore con el programa GBAK

El optimizar las instrucciones SQL (principalmente las cuatro principales: INSERT, UPDATE, DELETE,
SELECT) conduce a una notoria mejora en la velocidad. Muy relacionado con esto se encuentra el
correcto manejo de las transacciones. Ante alguna corrupcin restaurar el backup realizado con GBAK
suele ser suficiente.
Problemas tpicos con las bases de datos grandes

No se sabe donde est el problema

No se sabe por qu sucede

Realizar un ciclo backup/restore puede ser una gran prdida de tiempo, porque la restauracin
puede demorarse un da o ms, y no asegura que se haya solucionado el problema
Tareas administrativas diarias en las bases de datos grandes
Si ocurre un problema, puede demorarse mucho la solucin as que lo ms inteligente es evitar que
ocurra. Para ello:
1.

Debe realizarse un backup con GBAK todos los das

2.

Debe verificarse el rendimiento de todas las transacciones

3.

Debe verificarse que todas las instrucciones SQL estn optimizadas

4.

Debe verificarse cada ndice y la estadstica de cada ndice

5.

Debe verificarse que la estructura de la Base de Datos sea la ms conveniente

6.

Debe verificarse el archivo FIREBIRD.LOG varias veces por da

Aunque realizar un ciclo backup/restore no nos asegura que solucionaremos todos los problemas, tener
una Base de Datos grande sin backups actualizados es un suicidio. En las transacciones lo ms
importante es que ninguna demore mucho en completarse (mucho es relativo, pero en general si tarda
ms de un minuto entonces est tardando una eternidad). Las instrucciones SQL no optimizadas hacen
perder tiempo, algo que no se puede permitir en estas circunstancias. Y no debemos olvidar que una
instruccin SQL que hoy est optimizada y funciona perfectamente podra dejar de estarlo dentro de
unos meses cuando la Base de Datos haya aumentado mucho de tamao. Por eso la verificacin debe
hacerse diariamente.
El archivo FIREBIRD.LOG es el mejor lugar para verificar que todo est correcto, si hay algn problema
casi siempre aparecer en ese archivo.
Cmo realizar el ciclo backup/restore?
Es bastante frecuente, aunque errneo, hacerlo de esta manera:
Base de Datos > Backup con el mismo nombre anterior
Por ejemplo, la Base de Datos se llama CONTA.FDB y el archivo de backup siempre se
llama CONTA.FBK, cul es el problema potencial? Que si la Base de Datos est corrupta entonces el
nuevo backup no servir y el anterior no podr ser utilizado porque fue sobre-escrito.
Lo correcto, por lo tanto, es hacer el backup de esta manera:
Base de Datos > Backup con un nombre distinto al anterior

Esto evidentemente implica que tendremos varios archivos de backup, pero es preferible que sobren y
no que falten.
El archivo delta
Cuando se ejecuta el programa GBAK para realizar un backup, ste hace el backup de todo el contenido
que tiene en ese momento la Base de Datos. Es como si le tomara una fotografa. Nada que se realice
con posterioridad se guardar en el backup ni en la Base de Datos, slo lo que exista en el momento de
iniciarse GBAK. Pero y qu pasa con los datos que los usuarios continan insertando, actualizando o
borrando? Que no se guardan en la Base de Datos original sino en un archivo temporario llamado delta.
Cuando GBAK finaliza, entonces todo el contenido del archivo delta se copia dentro de la Base de
Datos.
Cuando hacemos backup de bases de datos pequeas no vale la pena preocuparse por ese
archivo delta pero cuando es una Base de Datos grande s, porque no podemos permitirnos que est
corrupto. Un motivo podra ser que no haya suficiente espacio en el disco duro para el archivo delta.
La restauracin
Aqu, es obligatorio que al finalizar un backup se realice un restore (en otro disco duro y preferiblemente
en otra computadora) para asegurarnos de que se encuentre en perfectas condiciones y pueda ser
utilizado en caso de necesidad.
Nada hay peor que creer que se tiene un backup actualizado pero eso no es cierto porque el backup se
encuentra inservible. No ocurre frecuentemente, pero a veces ocurre, y no se puede tomar ese riesgo.
Los ndices
Los ndices en Firebird se utilizan en las bsquedas y en los filtros (clusula WHERE) y cuando
deseamos que los resultados aparezcan en un cierto orden (clusula ORDER BY)
Para saber si un ndice es el adecuado, es necesario, y se encuentra en buena salud, debemos verificar
sus estadsticas. En Firebird los ndices pueden degradarse y no debemos permitir que tal cosa ocurra.
Acciones a tomar si se descubre un problema
Estas son recomendaciones que a veces podran no aplicarse, dependen de cada caso, pero servirn
de gua:
1.

Una transaccin est demorando mucho. Detectar cual es la transaccin, cual es el

programa culpable, y desconectar al usuario

2.

Una consulta est demorando mucho. Verificar cual es la consulta, mirar su PLAN y si es
necesario crear un nuevo ndice

Programas que se pueden utilizar cuando se trabaja con grandes bases de datos

Aunque detectar los problemas y solucionarlos podra hacerse manualmente, eso requerir que la
persona encargada conozca mucho del tema y que tenga suficiente tiempo y ganas para dedicarle a esa
tarea. Para estos casos se justifica adquirir software que ayude en la deteccin y correccin. Los
recomendados son:

FBDataGuard. Se ejecuta en la misma computadora donde se encuentra la Base de Datos. Su

principal tarea es prevenir que se corrompa. Monitorea el rendimiento, realiza el backup en la forma

correcta, obtiene estadsticas, y si descubre algn problema entonces enva un e-mail describindolo
FBScanner. Verifica cada instruccin SQL que el Cliente le enva al Servidor, puede realizar un
anlisis detallado de cada consulta, PLAN, transaccin y conexin, de esta manera sirve para detectar
los cuellos de botella, las transacciones que se demoran mucho, los usuarios que se desconectan de

mala manera, y monitorea lo que un usuario o una aplicacin estn realizando.

IBTM. Monitorea y analiza transacciones dinmicas. Obtiene los valores de OIT, OAT, OST, NT
y visualiza como se van moviendo. Detecta transacciones que se demoran mucho, los momentos en
que muchas transacciones se estn ejecutando, los momentos en que ocurre el sweep, la basura

dejada por los ROLLBACKs.

IBAnalyst. Analiza las estadsticas de la Base de Datos e identifica posibles problemas que
causan un bajo rendimiento: transacciones que demoran mucho, cantidad de versiones de los
registros, registros que han sido borrados pero an permanecen en la Base de Datos y por lo tanto
demoran la lectura, promedio de transacciones por da, conexiones perdidas, ndices no usados,

ndices con muchos valores repetidos, etc.

FBMonLogger. Detecta consultas lentas, transacciones que tienen un aislamiento incorrecto,

basura que debe ser recolectada, uso de la memoria, etc.

Sintica. Monitorea a la Base de Datos en tiempo real, ayudando a detectar los procesos que
consumen muchos recursos o que producen cuellos de botella, adems de las transacciones que
demoran mucho en finalizar.
Conclusin:
Aunque realizar las tareas administrativas de backup, verificacin de las estadsticas de los ndices,
revisar el archivo FIREBIRD.LOG, etc. deberan hacerse regularmente con cualquier Base de Datos,
cuando stas son de gran tamao esas tareas ya son una obligacin imprescindible porque no se puede
correr el riesgo de que se corrompa o de que funcione muy lentamente, muchas veces tales bases de
datos deben funcionar 365/24/7 (o sea, los 365 das del ao, durante las 24 horas, de cada uno de los 7
das de la semana) y cualquier demora o detencin puede ser muy grave.
En estos casos, suele ser recomendable contratar a una persona cuya funcin sea la de Administrador
de la Base de Datos y proveerle de las herramientas informticas adecuadas para que pueda realizar
efectivamente su labor.
Artculos relacionados:
El ndice del blog Firebird

El foro del blog Firebird21

Artculos

Usando Trace Manager

17 diciembre 2013
wrov PROGRAMAS manager, monitoreo, trace, trace
manager, transaccin,transacciones 2 comentarios
Con la versin 2.5 de Firebird se agreg algo que puede ser muy til: Trace Manager.
Qu hace Trace Manager?
Nos permite conocer todas las conexiones realizadas a una Base de Datos y todas las transacciones, en
tiempo real, o sea apenas ocurren.
El programa que realiza esta tarea se llama FBTRACEMGR.EXE y lo encontrars en la carpeta \BIN\ de
tu instalacin del Firebird.
Tarea a realizar:
Queremos monitorear todas las actividades que realiza el Servidor del Firebird, para ello necesitaremos
hacer lo siguiente:
1.

2.
3.

Crear un archivo de configuracin donde podremos determinar, entre otras cosas:

o

Monitorear todo lo que ocurre en una conexin

Monitorear todas las actividades de un usuario

Monitorear todas las transacciones en una o varias bases de datos

Ejecutar el programa FBTRACEMGR.EXE con el archivo de configuracin anterior
Opcionalmente (y preferiblemente) en lugar de enviar los resultados a la pantalla del monitor

podemos enviarlos a un archivo de texto y de esa manera ser muy fcil posteriormente revisar ese
archivo de texto y conocer exactamente lo que ocurri en la Base de Datos

Enconces, empezaremos creando con el bloc de notas del Windows un archivo de texto donde
guardaremos la configuracin a utilizar:

Captura 1. Si haces clic en la imagen la vers ms grande

Las de arriba no son las nicas opciones posibles, hay ms, en la Captura 2 las encontrars a todas:

Captura 2. Si haces clic en la imagen la vers ms grande

Ahora que ya hemos creado un archivo de configuracin podemos ejecutar el
programa FBTRACEMGR.EXE y empezar a monitorear todo lo que acontece dentro de la Base de
Datos.

Captura 3. Si haces clic en la imagen la vers ms grande

En lugar de localhost: puedes necesitar escribir la direccin IP de tu Servidor, opcionalmente seguido
por una barra y el nmero del puerto de conexin, algo como:

192.168.0.1/3051:
Abrimos ahora otra ventana Smbolo del sistema y ejecutamos en ella el programaISQL.EXE y nos
conectamos a una Base de Datos para ver lo que sucede con nuestro monitoreo:

Captura 4. Si haces clic en la imagen la vers ms grande

Y en la otra ventana del sistema (en la cual habamos ejecutado el programaFBTRACEMGR.EXE)
vemos esto:

Captura 5. Si haces clic en la imagen la vers ms grande

Trace session ID 3 started nos indica que esta es la tercera sesin del TraceManager que hemos
iniciado hoy.
TRACE_INIT nos indica que se inici el Trace.
COMMIT_TRANSACTION nos indica que una transaccin termin con un COMMIT.
ATT_4979 nos indica que esta es la conexin nmero 4.979 a la Base de Datos desde que fue creada.

SYSDBA nos indica quien fue el usuario que se conect a la Base de Datos. El :NONE despus de
su nombre nos indica que no us un rol para conectarse. Si un usuario utiliza un rol, el nombre de ese
rol aparecer aqu.
XNET:WALTER-PC nos indica la forma de conexin (a travs de XNET en este caso, tambin podra
haber sido a travs de una direccin IP) y el nombre de la computadora (o la direccin IP si aplica).
C:\Archivos de programa\ es el nombre del programa que se us para conectarse a la Base de
Datos. En este caso el nombre de ese programa fue ISQL.EXE pero lo normal es que se trate del
nombre de tu aplicacin (Contabilidad, Facturacin, Ventas, Sueldos, etc.)
TRA_90742 es el nmero de la transaccin. En este caso fue la transaccin nmero 90.742.
CONCURRENCY | WAIT | READ_WRITE indican los parmetros de la transaccin. En este caso la
transaccin fue SNAPSHOT, WAIT, READ WRITE, en otros casos podra ser: READ COMMITTED, NO
WAIT, READ ONLY, REC_VERSION, NO_REC_VERSION, etc.
START_TRANSACTION nos indica que se inici una transaccin.
EXECUTE_TRIGGER_FINISH nos indica que finaliz la ejecucin de un trigger cuyos datos vemos un
poco ms abajo.
Y bueno, puede mostrarte ms informacin relacionada pero ya la puedes descubrir por t mismo, para
eso eres lo suficientemente inteligente como para entender lo que ocurre.
Si quieres que el programa FBTRACEMGR.EXE no enve la informacin a la pantalla sino que la enve
a un archivo de texto le puedes redireccionar la salida con el smbolo mayor que, como se muestra a
continuacin:

Captura 6. Si haces clic en la imagen la vers ms grande

Entonces, ms tarde podrs revisar el contenido del archivo MONITOREO1.TXT (desde luego que ese
nombre es un ejemplo, t puedes elegir cualquier otro nombre).

Captura 7. Si haces clic en la imagen la vers ms grande

Conclusin:
Poder trazar las operaciones que ocurren dentro de una Base de Datos puede resultarnos muy pero
muy til cuando vemos que hay problemas con ella, por ejemplo si hay transacciones que no terminan
eso nos indica un problema con una aplicacin (Contabilidad, Facturacin, Ventas, etc.) y debemos
encontrar cual es el mdulo que abri una transaccin pero nunca la cerr porque las transacciones que
se abren y nunca se cierran solamente pueden causar problemas y nunca nos otorgarn algn
beneficio. Tambin podemos saber si un usuario se conect hoy, a que hora se conect, que
operaciones realiz, etc.
Artculo relacionado:

5.3 Monitoreo y Auditora de la Base de Datos

La auditora y la proteccin de bases de datos (DAP) representa un avance evolutivo importante con
respecto a anteriores herramientas de monitoreo de actividad en bases de datos (DAM). Los gerentes
de seguridad, los administradores de bases de datos (DBAs) y otros interesados, que estn
preocupados con proteger datos sensibles en las bases de datos, deben evaluar estas herramientas.
5.3.1 Monitoreo
El trmino Monitoreo es un trmino no incluido en el diccionario de la Real Academia Espaola (RAE).
Su origen se encuentra en monitor, que es un aparato que toma imgenes de instalaciones filmadoras o

sensores y que permite visualizar algo en una pantalla. El monitor, por lo tanto, ayuda a controlar o
supervisar una situacin.
Esto nos permite inferir que monitoreo es la accin y efecto de monitorear, el verbo que se utiliza para
nombrar a la supervisin o el control a travs de un monitor. Por extensin, el monitoreo es cualquier
accin de este tipo, ms all de la utilizacin de un monitor.
5.3.1.1 Monitoreo general de un DBMS
DAP un trmino que Gartner desarroll para remplazar el anterior concepto de DAM se refiere a las
suites de herramientas que se utilizan para apoyar la identificacin y reportar comportamiento
inapropiado, ilegal o de otra forma indeseable en las RDBMSs, con mnimo impacto en las operaciones
y la productividad del usuario. Estas suites han evolucionado de herramientas DAM que ofrecan
anlisis de la actividad del usuario en las RDBMSs y alrededor de ellas para abarcar un conjunto ms
integral de capacidades, que incluyen:
Descubrimiento y clasificacin.
Gestin de vulnerabilidades.
Anlisis al nivel de aplicacin.
Prevencin de intrusin.
Soporte de seguridad de datos no estructurados.
Integracin de gestin de identidad y acceso.
Soporte de gestin de riesgos.

5.3.1.2 Monitoreo de espacio en disco

El espacio en disco.
El abaratamiento de los discos ha reducido considerablemente la incidencia del espacio ocupado por los
usuarios. No obstante, los discos requieren administracin: hay que instalarlos, darles formato,
montarlos en otras mquinas, respaldarlos, monitorearlos. Aunque el espacio en disco sea suficiente, es
preciso insistir ante los usuarios para hacer un uso racional del recurso.
Comandos para el monitoreo del espacio en disco

quot
du
El comando
du
da un resumen del uso de disco en una rama de directorios.
du -s /export/home/*
Muestra el total para cada rama de subdirectorio bajo /export/home;
Esto no es efectivo para ver el consumo total de cada usuario si los usuarios tienen archivos en otras
partes del sistema.
df
El comando
df
da un resumen del uso del espacio a nivel de todo el sistema:
df
Muestra el espacio utilizado en cada sistema de archivos, incluso a veces en los que estn montados
va NFS. Si se indica uno en particular, da el espacio utilizado en ese sistema de archivos: df /dev/hda2.
El comando
quot
informa sobre el espacio en disco consumido por los usuarios en cada sistema de archivos: quot -f
/dev/hda2
Proporciona una lista de la cantidad de bloques y archivos a nombre de cada usuario.

5.3.1.3 Monitoreo de logs

Monitorear el log de transacciones es una de las actividades ms importantes para los administradores
de bases de datos, ya que en caso de que este llegara a llenarse, no podran llevarse a cabo ms
transacciones sobre esta base de datos quedando fuera de servicio.
Monitoreando el log de transacciones(SQL SERVER)
Monitorear el log regularmente puede ayudarnos a resolver varios problemas dentro de nuestros
sistemas, ya que este puede indicarnos si existen demasiadas transacciones realizadas por una sola
aplicacin, que podra resultar en un mal diseo o simplemente la necesidad de planear mejor los
recursos de log en nuestro servidor de base de datos.
Monitoreo de Logs
Una de ellas es mediante un comando desde el analizador de consultas:
Desde el analizador de consultas ejecutar el comando DBCC SQLPERF(LOGSPACE).

Monitoreo de Logs
La otra utilizando los contadores de SQL Server desde el sistema operativo.
Monitoreo de Log transacciones

5.3.1.4 Monitoreo de Memoria compartida

SGA de Oracle (Sistema de rea Global)
Es un conjunto de reas de memoria compartida "instancia" (un ejemplo es los programas de bases de
datos y la memoria RAM).
Sirve para facilitar la transferencia de informacin entre usuarios y tambin almacena la informacin
estructural de la BD ms frecuentemente requerida.
La SGA se divide en varias partes:
Buffers de BD, Database Buffer Cache
Es el cach que almacena los bloques de datos ledos de los segmentos de datos de la BD, tales como
tablas, ndices y clusters. Los bloques modificados se llamas bloques sucios. El tamao de buffer cach
se fija por el parmetro DB_BLOCK_BUFFERS del fichero init.ora.
Buffer Redo Log
Los registros Redo describen los cambios realizados en la BD y son escritos en los ficheros redo log
para que puedan ser utilizados en las operaciones de recuperacin hacia adelante, roll-forward, durante
las recuperaciones de la BD. Pero antes de guardar cambios en los ficheros redo log, son escritos en un
cach de la SGA llamado redo log buffer.
rea de SQL Compartido, Shared SQL Pool
En esta zona se encuentran las sentencias SQL que han sido analizadas. El anlisis sintctico de las
sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL
analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia
SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si
es as, no la analiza y pasa directamente a ejecutar la que mantiene en memoria. De esta manera se
premia la uniformidad en la programacin de las aplicaciones.

5.3.1.5 Monitoreo de Base de Datos

Procedimiento Monitoreo de la Base
de Datos Oracle10g
Se establece que se debe realizar una revisin peridica mensual de la base de datos institucional
(Oracle10g), con la finalidad de identificar oportunamente cualquier anomala que pueda afectar el
rendimiento de la misma. El encargado de realizar este proceso es el Administrador de la Base de
Datos, en la Unidad de Informtica del CATIE.
Revisin de las Tablas del Esquema APLIC
A. Verificar que el tablespace este asignado correctamente a uno vlido para el Esquema.
B. Que no se encuentre particionada.
D. Que el nmero de registros no exceda el tamao segn la funcionalidad de cada tabla.
Revisin de los ndices del Esquema APLIC
A. Verificar que el tablespace este asignado correctamente a uno vlido para el Esquema
B. Que no se encuentre particionado

C. Que el estado sea vlido.

Revisin de los Procedimientos del Esquema APLIC
A. Verificar que el estado sea vlido
Revisin de los Tablespaces en Almacenamiento
A. Verificar el estado sea ONLINE
B. Que el espacio usado no sobre pase el 85%, si no debe asignrsele ms espacio en disco.
Revisin de los Archivos de Datos en Almacenamiento
A. Verificar el estado sea ONLINE
B. Si el espacio usado no sobre pase el 85%, debe asignrsele ms espacio en disco, creando un nuevo
archivo de datos.
Revisin de los Segmentos de RollBack en Almacenamiento
A. Verificar el estado sea ONLINE

5.3.1.6 Monitoreo de modos de operacin

MONITOREO DE BASE DE DATOS
Revisin del espacio fsico desde el S.O. del servidor ADMIN. (root)
A. Ejecutar el comando:
$ df -k | grep dsk
5.3.1.6 MONITOREO DE MODOS DE OPERACION
Varios Consejos tcnicos y libros se han escrito en los ltimos aos sobre la modalidad de operaciones
continua para garantizar copias de seguridad adecuadas en la Base de Datos.
Sin embargo, poco se ha dicho acerca de la supervisin en este modo de operacion,por ello se ha
escrito este consejo tecnico para saber como hacer copias de seguridad mas fluidas.
CUAL ES EL MODO DE FUNCIONAMIENTO CONTINUO?
*Es un modo especial en las bases de datos especializadas.

*Permite realizar copias de seguridad instantanea en su entorno.

*Se puede realizar en cualquier momento del dia.
*Escribe un archivo fisico independiente llamado
"archivo delta"
*Se obtiene una copia de seguridad que incluye el estado de la base de datos
en un solo momnto en el tiempo.
5.3.1.7 Monitoreo de espacios espejeados

Una de las tareas de un DBA es monitorear el espacio de la base de datos, debido a que esto consume
mucho tiempo cuando se tienen varias DBs es bueno automatizar tareas repetitivas y tediosas. Una
manera de realizar la automatizacin del monitoreo de DBs en UNIX es por medio del crontab, el
siguiente es un ejemplo de como usar el crontab para monitorear los tablespaces.
Los siguientes scripts permiten obtener el espacio utilizado y libre de los tablespaces, uno lo
obtiene en base el porcentaje libre de espacio y el otro obtiene el espacio en base a los MB libres. Estos
scripts reciben dos parametros: &1 .- es el directorio y archivo donde se va a crear el reporte(spool) y &2
que es el limite ya sea porcentaje (99) o Mb(99999).
tablespace_size_pct.sql
SET line 132
SET pages 50
SET pause OFF
SET feedback OFF
SET echo OFF
SET verify OFF
COLUMN c1 heading "Tablespace|Name"
COLUMN c2 heading "File|Count"
COLUMN c3 heading "Allocated|in MB"
COLUMN c4 heading "Used|in MB"
COLUMN c5 heading "%|free" format 99.99
COLUMN c6 heading "Free|in MB"
COLUMN c7 heading "%|used" format 99.99
spool &1;
SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2
FROM(
SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,
mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,
NVL (mbytes_free, 0) c6,
((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,
100
- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,
b.files c2
FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name
FROM SYS.dba_free_space
GROUP BY tablespace_name) a,
(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,
COUNT (file_name) files
FROM SYS.dba_data_files
GROUP BY tablespace_name) b
WHERE a.tablespace_name(+) = b.tablespace_name
UNION ALL
SELECT f.tablespace_name,
SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)
) "total MB",
SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",
SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)

)
/ 1024
/ 1024,
2
)
) "Free MB",
(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
100
- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
COUNT (d.file_name)
FROM SYS.v_$temp_space_header f,
dba_temp_files d,
SYS.v_$temp_extent_pool p
WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id
AND p.file_id(+) = d.file_id
GROUP BY f.tablespace_name)
WHERE C1 NOT IN('USERS')
AND C7 >= &2
ORDER BY c6 ASC;
spool off;
exit;
tablespace_size_spc.sql
SET line 132
SET pages 50
SET pause OFF
SET feedback OFF
SET echo OFF
SET verify OFF
COLUMN c1 heading "Tablespace|Name"
COLUMN c2 heading "File|Count"
COLUMN c3 heading "Allocated|in MB"
COLUMN c4 heading "Used|in MB"
COLUMN c5 heading "%|free" format 99.99
COLUMN c6 heading "Free|in MB"
COLUMN c7 heading "%|used" format 99.99
spool &1;
SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2
FROM(
SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,
mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,
NVL (mbytes_free, 0) c6,
((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,
100
- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,
b.files c2
FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name
FROM SYS.dba_free_space
GROUP BY tablespace_name) a,
(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,
COUNT (file_name) files
FROM SYS.dba_data_files
GROUP BY tablespace_name) b
WHERE a.tablespace_name(+) = b.tablespace_name

UNION ALL
SELECT f.tablespace_name,
SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)
) "total MB",
SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",
SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)
)
/ 1024
/ 1024,
2
)
) "Free MB",
(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
100
- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)
/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),
COUNT (d.file_name)
FROM SYS.v_$temp_space_header f,
dba_temp_files d,
SYS.v_$temp_extent_pool p
WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id
AND p.file_id(+) = d.file_id
GROUP BY f.tablespace_name)
WHERE C1 NOT IN('USERS')
AND C6 <= &2
ORDER BY c6 ASC;

SPOOL OFF;
exit;
Con el siguiente script podemos ejecutar

los SQL scripts anteriores dependiendo los

parametros que le enviemos. La forma de ejecutar el script es la siguiente:

Para reportar en base al espacio, despues del parametro -d debe seguir el nombre de
la instancia (SID), despues del parametro -s sigue la cantidad minima que puede tener libre un
tablespace:
tbs_monitor.ksh -d DEVELOPMENT -s 500
Connected.
Instance: DEVELOPMENT
Tablespaces with usage < 500 MB.

Tablespace
Allocated
Used
Free
%
%
File
Name
in MB
in MB
in MB used free
Count
------------------------------ ---------- ---------- ---------- ------ ------ --------- SYSTEM
600 403.13 196.88 67.19 32.81
1
IDX1
11741
11363
378 96.78 3.22
3
Para reportar en base al porcentaje, en lugar de utilizar el parametro -s se utiliza el parametro -p
seguido del porcentaje maximo que puede tener un tablespace:
tbs_monitor.ksh -d DEVELOPMENT -p 80
o Connected.
o Instance: DEVELOPMENT
o Tablespaces with usage >= 80%.
o
o Tablespace
Allocated
Used
Free
%
%
File
o Name
in MB
in MB
in MB used free
Count
o ------------------------------ ---------- ---------- ---------- ------ ------ ---------o IDX1
11741
11363
378 96.78 3.22
3
o IDX2
3201
2696
505 84.22 15.78
2
o IDX5
18385
17394
991 94.61 5.39
3

o DATA02
13312 11520.13 1791.88 86.54 13.46
o DATA03
33797 31709.13 2087.88 93.82 6.18
o DATA01
56629 46606.38 10022.63 82.30 17.70
tbs_monitor.ksh
#!/bin/ksh
#######################################################################
#
# SCRIPT
: tbs_monitor.ksh
#
# DESCRIPTION : This script will monitor usage in tablespaces of a database.
#
If the usage is >= 90% it will send an email to the DBA group.
#
# INPUT FILES : [oracle_sid] only one database is processed
#
# OUTPUT FILES : NONE
#
# CALLED OBJECT: $SCRIPTS/switchdb.ksh
# ASSUMPTIONS : NONE
#
# SETUP INSTRUCTIONS : NONE
#
# COMMAND LINE EXECUTION: tbs_monitor.ksh -d [oracle_sid] [-s sizeinMB] [-p pct]
#
# EXAMPLE: tbs_monitor.ksh -d DEV -s 300
# EXAMPLE: tbs_monitor.ksh -d DEV -p 85
#
# RESTART INSTRUCTIONS: rerun script
# SPECIAL CONSIDERATIONS: NONE
#######################################################################
# Modification Log:
# Version Date
Name
Description
#######################################################################
# 1.0 04-Jul-2006 Delfino Nunez Initial Creation
#######################################################################
########################################################################
# FUNCTION : showHelp
# DESCRIPTION: Print the help for using the script
########################################################################
function showHelp {
echo " Argument
Description"
echo " ------------ ----------------------------------------------"
echo " -d [sid] Oracle sid to check."
echo " -p xx
Report on percentage usage(pct > xx)."
echo " -s xxxxxx Report on MB size usage(sizeMB < xxxxxx)."
echo " -h
This help."
echo " \n\n EXAMPLE: "
echo "
Report tablespaces that have more than 95% space used"
echo "
tbs_monitor.ksh -s EDS2TSDE -p 95"
echo "
Report tablespaces that have less than 300Mb space"
echo "
tbs_monitor.ksh -s EDS2TSDE -s 300"
}
########################################################################
# Main Program start here
########################################################################
# Verify input paramtter and set environment variables
#parm_list=$@
. $DBA_BASE/init

2
4
7

#set -- $parm_list
#check parameters
if [ "$1" != "" ]
then
while [ "$#" != "0" ]
do
case $1 in
-s)
shift
if [ "$1" != "" ]; then
export RPTTYPE="SIZE"
export PSIZE=$1
shift
fi
;;
-d)
shift
if [ "$1" != "" ]; then
export ORACLE_SID=$1
shift
fi
;;
-p)
shift
if [ "$1" != "" ]; then
export RPTTYPE="PCT"
export PSIZE=$1
shift
fi
;;
-h)
showHelp
exit 0;
;;
*)
echo "Bad argument: $1"
showHelp
exit 1;
;;
esac
done
else
showHelp
exit 1
fi
. $SCRIPTS/switchdb.ksh $ORACLE_SID
BOXNAME=`uname -n`
MAILIDS=`cat $DBA_BASE/.forward`
# point to where the rpt file will go
export RPTFILE=$TMP/${ORACLE_SID}_tablespace_rpt.txt
export EMAILMSG=$TMP/tbs_email.txt
export dbpass=`cat $PWDFILE`

# should not need to be changed

export DATE=$(date +%y-%m-%d.%H:%M:%S)
#remove any previous file
if [ -a $RPTFILE ]
then
rm $RPTFILE
fi
if [ -a $EMAILMSG ]
then
rm $EMAILMSG
fi
#Run the status report.
case "$RPTTYPE" in
"PCT")
MESSAGE="Tablespaces with usage >= $PSIZE%."
sqlplus -s /nolog <
connect $dbpass
prompt Instance: $ORACLE_SID
prompt Tablespaces with usage >= $PSIZE%.
@$SQL/tablespace_size_pct.sql $RPTFILE $PSIZE
EOF
;;
"SIZE")
MESSAGE="Tablespaces with usage <= $PSIZE Mb."
sqlplus -s /nolog <
connect $dbpass
prompt Instance: $ORACLE_SID
prompt Tablespaces with usage < $PSIZE MB.
@$SQL/tablespace_size_spc.sql $RPTFILE $PSIZE
EOF
;;
esac

#tablespace with problems

if [[ -s $RPTFILE ]]; then
echo "The following database have problems with the size of their tablespaces:\n" >>
$EMAILMSG
echo "Instance: $ORACLE_SID" >> $EMAILMSG
echo $MESSAGE >> $EMAILMSG
cat $RPTFILE >> $EMAILMSG
mailx -s "ALERT!!! Tablespace Usage Problems - $BOXNAME:$ORACLE_SID $DATE" $MAILIDS <
$EMAILMSG
fi
Y el ultimo script nos permite obtener el reporte para todas las bases que se encuentran en el
servidor. Este script lee el archivo ORATAB y saca todas las bases de datos registradas en el servidor.
Este script se puede poner en el crontab de la siguiente manera:
00 00-01,06-23 * * * /home/oracle/dba/scripts/all.tbs_monitor -p >/dev/null 2>&1
Aqui le estamos diciendo al crontab que ejecute el script cada hora excepto de 2am-5am, esto
por cuestiones de respaldos.
Si no se quiere procesar todas las bases de datos y solo se quiere verificar algunas entonces es
necesario de calendarizar el script tbs_monitor.ksh por cada una de las bases de datos.
all.tbs_monitor
#!/bin/ksh
#######################################################################

#
# SCRIPT
: all.tbs_monitor
#
# DESCRIPTION : This script will call tbs_monitor script for all databases
#
# INPUT FILES : $DBA_BASE/init - configuration file
#
-a all databases are processed
#
-p production (*PD) databases are processed
#
# OUTPUT FILES : NONE
#
# CALLED OBJECT: tbs_monitor
# ASSUMPTIONS : NONE
#
# SETUP INSTRUCTIONS : Need to switchdb first to a default.
#
# COMMAND LINE EXECUTION:
#
# EXAMPLE:
#
# RESTART INSTRUCTIONS: rerun script
# SPECIAL CONSIDERATIONS: NONE
#######################################################################
# Modification Log:
# Version Date
Name
Description
#######################################################################
# 1.0 04-Jul-2006 Delfino Nunez Initial Creation
#######################################################################
############################################################################
# MAIN PROGRAM STARTS HERE
############################################################################
. $HOME/dba/init
priority=1
########################################################################
# FUNCTION : showHelp
# DESCRIPTION: Print the help for using the script
########################################################################
function showHelp {
echo " Argument
Description"
echo " ------------ ----------------------------------------------"
echo " -p
Only production databases."
echo " -a
All databases."
echo " -h
This help."
echo " \n\n EXAMPLE: all.tbs_monitor -a"
echo "
all.tbs_monitor -p"
}
########################################################################
# Main Program start here
########################################################################
if [ -f /var/opt/oracle/oratab ]
then
export ORATAB='/var/opt/oracle/oratab'
elif [ -f /etc/oratab ]
then
export ORATAB='/etc/oratab'

else
# following code from Steve Larson
FOUND_ORATAB=$( find / -name oratab 2>/dev/null | head -1 )
if [ "$FOUND_ORATAB" ] && [ -f "$FOUND_ORATAB" ]
then
ORATAB="$FOUND_ORATAB"
else
exit 1
fi
fi
#check parameter
if [ "$1" != "" ]
then
while [ "$#" != "0" ]
do
case $1 in
-p)
export INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB|grep "PD"`
shift
;;
-a)
export INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB`
shift
;;
-h)
showHelp
exit 0;
;;
*)
echo "Bad argument: $1"
echo ""
showHelp
exit 1;
;;
esac
done
else
showHelp
exit 1
fi
if [ "$#" != "0" ]
then
ORACLE_SID=$1
shift
export ORACLE_SID
else
for ORACLE_SID in $INSTANCES
do
swdb $ORACLE_SID
tbs_monitor.ksh -d $ORACLE_SID -s 300
done
fi
Los scripts utilizan otros scripts o archivos que no estan incluidos aqui y que voy a ir publicando, pero
estos scripts pueden usarse como base para crear unos personalizados.

5.3.2 Auditora
Es la actividad consistente en la emisin de una opinin profesional sobre si el objeto sometido a
anlisis presenta adecuadamente la realidad que pretende reflejar y/o cumple con las condiciones que le
han sido prescritas.
5.3.2.1 Habilitacin y deshabilitar el modo de auditora
Funcionamiento comando audit (Oracle):
El comando audit permite iniciar los tipos de auditora que a continuacin se detallan. Este comando
puede funcionar aunque no est activada la auditora de la base de datos, pero no dejar constancia,
para que funcione correctamente es necesario que la auditora est activada.
Sintaxis:
AUDIT
{ sql_statement_clause | schema_object_clause | NETWORK }
[ BY { SESSION | ACCESS } ]
[ WHENEVER [ NOT ] SUCCESSFUL ] ;

sql_statement_clause
: activa la auditora para una sentencia SQL concreta.

schema_object_clause
: activa la auditora para un objeto concreto de la base de datos.

WHENEVER SUCCESSFUL
: activa la auditora slo para operaciones e instrucciones SQL en objetos de esquema que se
completen con xito.

WHENEVER NOT SUCCESSFUL

: activa la auditora slo para operaciones e instrucciones SQL en objetos de esquema que originen
error.
Funcionamiento comando noaudit:
La instruccin noaudit se utiliza para detener la actividad de auditora que se haba activado
previamente con la instruccin audit. Esta instruccin no influye en el parmetro audit_trail.
Sintaxis:
NOAUDIT
{ sql_statement_clause | schema_object_clause | NETWORK}
[WHENEVER [NOT] SUCCESSFUL];

sql_statement_clause
: detiene la auditoria de una sentencia SQL concreta.

schema_object_clause

: detiene la auditora para un objeto concreto de la base de datos.

WHENEVER SUCCESSFUL
: detiene la auditora slo para operaciones e instrucciones SQL en objetos de esquema que se
completen con xito.

WHENEVER NOT SUCCESSFUL

: detiene la auditora slo para operaciones e instrucciones SQL en objetos de esquema que originen
error.
5.3.2.2 Consultas de las tablas vistas con informacin de la auditora
Dependiendo del tipo de auditora que queramos consultar utilizaremos una u otra consulta SQL.
Para el caso de la auditora de inicio de sesin utilizaremos la siguiente consulta SQL:
selectOS_UsernameUsuario_SO,
UsernameUsuario_Oracle, Terminal ID_Terminal,
DECODE (Returncode, '0', 'Conectado', '1005', 'Fallo - Null',
1017, 'Fallo', Returncode) Tipo_Suceso,
TO_CHAR(Timestamp, 'DD-MM-YY HH24:MI:SS') Hora_Inicio_Sesion,
TO_CHAR(Logoff_Time, 'DD-MM-YY HH24:MI:SS') Hora_Fin_Sesion
from DBA_AUDIT_SESSION;
Para el caso de la auditora de accin utilizaremos la siguiente consulta SQL:
selectOS_UsernameUsuario_SO,
UsernameUsuario_Oracle, Terminal ID_Terminal,
OwnerPropietario_Objeto,
Obj_NameNombre_Objeto,
Action_NameAccion,
DECODE (Returncode, '0', 'Realizado', 'Returncode') Tipo_Suceso,
TO_CHAR (Timestamp, 'DD-MM-YY HH24:MI:SS') Hora
from DBA_AUDIT_OBJECT;

5.4 Herramientas de software y hardware para monitoreo y administracin automtica

Herramientas de Microsoft SQL Server
Estas herramientas son el Profiler y el Performance monitor.
*Permiten ver los procesos en ejecucion del servidor
*Ayudan a ver como esta el rendimiento del sistema
PROFILER
-Permite crear trace para dar seguimiento a las ejecuciones y consultas que se ejecutan en el servidor
-Podemos tener acceso en la direccin Start>Program Files > Microsoft SQL Server >Profiler.
-Se pueden filtar traces especificando el nombre de la aplicacion a la que se le quiere dar seguimiento.

PERFORMANCE MONITOR
-Con esta herramienta se visualiza como se esta comportando el disco duro
-A demas de como la base de datos utiliza la memoria y el procesador del servidor los cuales deberan
mantenerse por debajo de un 20%
Herramientas de MySql
MySQL-Proxy
es una herramienta para monitorear y optimizar consultas y bsquedas.
1.- Hacer un Log de todas las consultas que recibe el Servidor
2.- Denegar consultas peligrosas que puedan daar nuestra base de datos
3.- Generar Alias de comandos comunes por ejemplo SLE se podra convertir en SELECT
4.- Balancear la carga entre varios servidores de MySQL en un esquema de Master/Slave
5.- Dar prioridad a ciertas consultas para acelerar la respuesta del servidor

Leer ms: http://proyecto359.webnode.mx/unidad5/

Crea tu propia web gratis: http://www.webnode.es

5.3. MONITOREO Y AUDITORA DE LA BASE DE DATOS

Qu es la Auditora de BD
Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los
accesos a la informacin almacenada en las bases de datos incluyendo la
capacidad de determinar:
Quin accede a los datos.
Cundo se accedi a los datos.
Desde qu tipo de dispositivo/aplicacin.
Desde que ubicacin en la Red.
Cul fue la sentencia SQL ejecutada.
Cul fue el efecto del acceso a la base de datos.
Es uno de los procesos fundamentales para apoyar la responsabilidad delegada a
IT por la organizacin frente a las regulaciones y su entorno de negocios o
actividad.
Objetivos Generales de la Auditora de BD
Disponer de mecanismos que permitan tener trazas de auditora completas y
automticas relacionadas con el acceso a las bases de datos incluyendo la
capacidad de generar alertas con el objetivo de:
Mitigar los riesgos asociados con el manejo inadecuado de los datos.
Apoyar el cumplimiento regulatorio.
Satisfacer los requerimientos de los auditores.

 Evitar acciones criminales.

Evitar multas por incumplimiento.
La importancia de la auditora del entorno de bases de datos radica en que es el
punto de partida para poder realizar la auditora de las aplicaciones que utiliza esta
tecnologa.
La Auditora de BD es importante porque:
Toda la informacin financiera de la organizacin reside en bases de datos y
deben existir controles relacionados con el acceso a las mismas.
Se debe poder demostrar la integridad de la informacin almacenada en las
bases de datos.
Las organizaciones deben mitigar los riesgos asociados a la prdida de datos y
a la fuga de informacin.
La informacin confidencial de los clientes, son responsabilidad de las
organizaciones.
Los datos convertidos en informacin a travs de bases de datos y procesos de
negocios representan el negocio.
Las organizaciones deben tomar medidas mucho ms all de asegurar sus
datos.

5.3.12 MONITOREO DE ESPACIO EN DISCO.

Como DBA una de las responsabilidades es supervisar el espacio en disco.
Siempre hay que asegurarse de que se tiene suficiente para sus bases de datos,
copias de seguridad de bases de datos y cualquier otro tipo de archivos que va a
almacenar en el servidor. Si no controla su espacio en disco y se asegura de que
tienes espacio suficiente, con el tiempo uno de sus procesos crticos de bases de
datos o componentes va a fracasar porque no se puede asignar el espacio en
disco que necesita.

Dentro de SQL Server hay un procedimiento no documentado que nos puede

ayudar a cumplir este cometido. El procedimiento es XP_FIXEDDRIVES, no lleva
parmetros ni nada y nos regresa todos los discos a los que tiene acceso SQL
Server y su espacio disponible en Megabytes.
Es muy sencillo utilizarlo, solo basta con ejecutar el comando xp_fixeddrives de
vez en cuando desde el Analizador de consultas para revisar la cantidad de
espacio libre, aunque este mtodo consume demasiado tiempo para los
administradores de bases de datos. Un mtodo mejor sera automatizar la
ejecucin de este comando peridicamente para revisar la cantidad de espacio
libre.
Algunas tareas de DBA donde la informacin de espacio libre puede ser til:
- La primera que se alerte al DBA cuando el espacio libre cae por debajo de un
umbral especfico en cualquier unidad de SQL Server.
- La segunda sera la de realizar un seguimiento de la historia el espacio libre para
la gestin de la capacidad de espacio en disco.
La forma de construir un proceso para alertar a la DEA, cuando cualquiera de las
unidades de disco de SQL Server cae por debajo de un umbral predeterminado.
Para obtener la informacin xp_fixeddrives en una tabla temporal que se utiliza el
siguiente T-SQL.
create table #FreeSpace(
Drive char(1),
MB_Free int)
insert into #FreeSpace exec xp_fixeddrives
A continuacin, por cada unidad se recupera la informacin de espacio libre a
partir de esta tabla temporal y se compara con un umbral que se ha fijado para
cada unidad. Si la cantidad de espacio libre cae por debajo del valor umbral
determinado para la unidad, enviar alerta al DBA mediante xp_sendmail. Aqu est
una muestra de un cdigo que hace precisamente eso.
declare @MB_Free int
create table #FreeSpace(
Drive char(1),
MB_Free int)
insert into #FreeSpace exec xp_fixeddrives
select @MB_Free = MB_Free from #FreeSpace where Drive = 'C'
-- Free Space on C drive Less than Threshold
if @MB_Free < 1024

exec master.dbo.xp_sendmail
@recipients ='greg.larsen@netzero.net',
@subject ='SERVER X - Fresh Space Issue on C Drive',
@message = 'Free space on C Drive has dropped below 1 gig'
Esta alerta de espacio libre bajo permite tiempo al DBA para resolver el problema
de espacio libre antes de que sea crtico, y provoque procesos fallidos. Tenga en
cuenta que el cdigo anterior tiene un umbral diferente de espacio libre

5.3.13. MONITOREO DE LOGS.

Monitorear el log regularmente puede ayudarnos a resolver varios problemas
dentro de nuestros sistemas, ya que este puede indicarnos si existen demasiadas
transacciones realizadas por una sola aplicacin, que podra resultar en un mal
diseo o simplemente la necesidad de planear mejor los recursos de log en
nuestro servidor de base de datos.
Es muy importante tener en cuenta que si el log de transacciones llegara a
saturarse, SQL Server no podr realizar ms cambios dentro de nuestra base de
datos.
La manera de monitorear un log de transacciones, puede llevarse a cabo de 2
maneras, una de ellas es mediante un comando desde el analizador de consultas
y la otra utilizando los contadores de SQL Server desde el sistema operativo.

Desde el analizador de consultas ejecutar el comando DBCC

SQLPERF(LOGSPACE).

Utilizando los contadores de SQL Server que se describen a continuacin.

http://administracionbd.weebly.com/unidad-5.html
http://proyecto359.webnode.mx/unidad5/