Sistema de notificacion de Alarmas

[Alexis]

Que sistema de notificacion de alarmas me recomiendan para programar umbrales y errores, ejemplo , un tablespace llego al 85% y me notifique via email, entiendo que teniendo licenciado el diagnostic pack se puede hacer notificacioin de alarmas pero que opcion existe cuando no tengo para la licencia del diagnostic pack o tengo la version standar de oracle 11g.

gracias a todos

[Marcelo Burgos]

Hola Alexis

Para variar, no voy a responder tu pregunta sino que voy a cuestionártela... perdona el atrevimiento

En tu lugar me aseguraría que ningún tablespace quedara escaso de lugar asegurándome la extensión automática en discos de capacidades ilimitadas, para que en el aeropuerto nunca tengan que decirme "espere a abordar el avión que el tablespace se me quedó sin lugar"

Lo que sí me aseguraría de llevar el control de cuales cambios se han producido y en comparación de lo que se consideró al momento del diseño de la base de datos

Saludos, Marcelo

[Alexis]

Hola Marcelo el tema del tablespace lo describi mas  como un ejemplo, si tienes alguna alternativa me comentas.

 

gracias

[Edgar J. Guzman M.]

Que tal alexis , efectivamente fijate con la instalacion Enterprise de un manejador puedes configurar la consola administrativa y alli puedes utilizar o configurar algunas alarmas importantes tal como se hace con el Grid , ciertamente no se puede hacer todo lo que se hace con el grid pero sirve como herramienta de monitoreo . Otras opcion es utilizar vias externas (crontab-shells-cmd-bat) esto dependiendo de tu sistema Operativo podrias hacer consultas de almacenamaineto o status a la base de datos y hacer que la salida interactue con tu servidor de correo y que te las haga llegar a un buzon.

[Fernando J. Andrade]

Alternativas al OEM 11g o al Cloud Control 12c pueden ser muchas yo sé de gente que ha tenido buenas experiencias con Nagios y Cacti que los dos son libres ( asumo ) para monitorizar bases Oracle.

Aquí hay una comparativa http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems.

Y por cierto Marcelo no te recomiendo tener los datafiles de los tablespaces en autoextensibles en producción simplemente porque vas a tener mucho problema para paralelizar el backup, la idea es que sean del mismo tamaño para que al paralelizar cada proceso tome un datafile o datafiles del mismo tamaño.

[Alexis]

Hola Fernando gracias por la respuesta, lo que tengo entendido es que esas herramientas toman informacion de las tablas que se poblan cuando tienes activado el diagnostic pack y el tuning pack.

[Fernando J. Andrade]

Si y no necesariamente, las tablas que hay que tener cuidado son las del V$ASH que son las del active session history, esas tablas si es necesario licenciar. El resto de vistas V$ en su gran mayoría no tienen problemas de licenciamiento, la mayoría de estos productos de monitorización no usan ASH.

ASH es poderosísimo eso si, puedes crear una especie de TOP para Oracle con él en un simple query, pero la pega que tiene es el licenciamiento como bien tu lo comentas Alexis.

Saludos!

[Alexis]

Hola Fernando gracias por tu respuesta,

[Marcelo Burgos]

Hola Fernando

Como siempre es una hemorragia de placer escuchar tus consejos

La paralelización del backup (y de todo) no hay duda que es una posibilidad que da la base de datos que no debe desperdiciarse. Es más, si no lo hacemos estamos haciendo funcionar nuestra base de datos como se hacía 5 o 10 años atrás, pero justamente, y volviendo "atrás", que es cuando yo estudié profundamente los porqué de las BD Oracle, se explicaba que los backups sólo guardan los bloques utilizados, con lo que si quiero paralelizar dos tablespaces de igual tamaño, tanto la cantidad de segmentos con que cuenta cada TS, como la cantidad de bloques usados en cada extensión, desde mi ignorancia me parece no encontrar ventajas a que los tamaños de los TS sean iguales

Pero, como vos seguro que sabés cuales son las ventajas, seguro nos las explicarás, y nosotros estaremos felices en haber aprendido algo nuevo

Saludos!

Fernando J. Andrade dice:

Alternativas al OEM 11g o al Cloud Control 12c pueden ser muchas yo sé de gente que ha tenido buenas experiencias con Nagios y Cacti que los dos son libres ( asumo ) para monitorizar bases Oracle.

Aquí hay una comparativa http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems.

Y por cierto Marcelo no te recomiendo tener los datafiles de los tablespaces en autoextensibles en producción simplemente porque vas a tener mucho problema para paralelizar el backup, la idea es que sean del mismo tamaño para que al paralelizar cada proceso tome un datafile o datafiles del mismo tamaño.

[Fernando J. Andrade]

Marcelo perdón por responder tan tarde.

Mira es sencillo Oracle crea un proceso por cada datafile que lea, si quieres que lea varios datafiles al mismo tiempo tienes que crear varios procesos. Si los datafiles tienen un tamaño diferente la paralelización demorará tanto como el archivo más grande es por ello que es conveniente tenerlos del mismo tamaño.

Oracle hace un trabajo magnifico simplemente con el filesperset creando set de un tamaño similiar para paralelizar, pero que los archivos tengan el mismo tamaño ayuda mucho. En sistemas con Bigfile Tablespaces era complicado paralelizar por eso en 11g salió la posibilidad de poder partir un datafile desde el RMAN, es decir lanzar varios procesos sobre un solo archivo pero a menos que se lo digas explicitamente eso no funciona así.

Y eso es todo, no confundir la paralelización de SQL con la paralelización de RMAN, en SQL se generan esclavos de SQL en RMAN tenemos procesos de lectura y de escritura los cuales se paralelizan de forma independiente, por eso puedes tener problemas de lectura de datafiles o de escritura del backup.

Slds