Comunidad Oracle Hispana

Como participar en la Comunidad Oracle Hispana

Fernando Garcia — Sun, 07 Dec 2008 21:23:00 +0000

La siguiente presentacion nos da algunas ideas para poder participar de una manera efectiva en el sitio de la Comunidad Oracle Hispana. La Comunidad Oracle Hispana desarrolla sus actividades en la plataforma Ning. Puedes visitar el sitio haciendo click aqui

Redes sociales enfocadas, la nueva tendencia.

Fernando Garcia — Wed, 08 Oct 2008 22:34:47 +0000

Desde hace un tiempo los internautas estamos siendo testigos de la proliferación de un importante número de redes sociales profesionales enfocadas a un determinado sector. En general se trata de sitios para profesionales a los cuales el uso de internet les puede ayudar de forma importante en su trabajo. Así hemos visto tambien la aparición de la Comunidad Oracle Hispana.

Al igual que otras redes sociales, la Comunidad Oracle Hispana esta creada en la plataforma Ning, la aplicación que ya se ha convertido en el estándar para la creación de redes sociales profesionales.

Originalmente, el acceso al sitio estaba abierto solo a aquellas personas que contaban con la membresia. Desde el 17 de noviembre de 2008 el acceso a la pagina principal es publico y la membresia se puede gestionar en el mismo sitio. La direccion del sitio es http://comunidadoraclehispana.ning.com

Ademas, los usuarios de LinkedIn, facebook, Hi5 o Xing pueden estar al tanto de todas las novedades de la Comunidad uniendose al grupo “Comunidad Oracle Hispana” en las respectivas plataformas.

Oracle Magazine, para estar actualizados (y gratis!).

Fernando Garcia — Sat, 06 Sep 2008 03:37:52 +0000

Cuando a quienes forman parte de la Comunidad Oracle Hispana les preguntamos porque eligen formar parte de este grupo, muchos nos contestan “…- para estar al tanto de las novedades de la comunidad Oracle”. Sin duda, la mayoria de los profesionales que trabajamos con tecnologías Oracle, sentimos permanentemente la necesidad de estar actualizados.

Unirse a una comunidad como la Comunidad Oracle Hispana es una excelente alternativa, aunque no la única. Oracle Corporation nos ofrece otra alternativa muy interesante: Oracle Magazine. Oracle Magazine es la revista que emite Oracle en forma bimestral y que podemos recibir en forma gratuita en nuestros hogares u oficinas. Cada edición de Oracle Magazine nos ofrece información actualizada sobre el motor de base de datos Oracle, sobre Oracle Fussion Middleware, sobre Oracle E-business suite y otras herramientas de desarrollo. En Oracle Magazine, además, podremos encontrar noticias y anuncios de terceras partes; como así también artículos técnicos sobre los diversos productos de Oracle. Historias con casos de éxito también son muy frecuentes.

La suscripción vía Web es la forma más sencilla de suscribirse a Oracle Magazine. Para acceder al formulario de suscripción basta con dirigirse a http://www.submag.com/sub/oc?pk=OTNRHL

Y para aquellos que quieran acceder a información mas orientada a ejecutivos Oracle Profit constituye otra alternativa interesante. Para suscribirse a Profit dirigirse a http://www.submag.com/sub/po?pk=pronew

Registración automática del listener y configuración cruzada en RAC

Sebastián D'Alessandro — Fri, 05 Sep 2008 02:08:56 +0000

Previamente a la versión de base 8i, la información sobre la registración de instancias por parte del listener debía ser configurada explícitamente de forma manual en el archivo de configuración listener.ora . A partir de 8i las instancias pueden realizar esta registración de manera automática luego que la instancia levanta y gracias a la ayuda del proceso backgroud PMON el cual lo realiza contra el listener_default, siempre y cuando el parámetro de inicio local_listener no esté definido. Cuando nos referimos a listener default, hablamos del que lleva por nombre LISTENER y escucha en el puerto 1521.

El llamado Automatic Service Registration (ASR), como es de esperar, reduce la sobrecarga de tareas administrativas cuando contamos con una instalación de varias instancias o bases de datos.

Como dijimos antés, básicamente esta tarea de registración es realizada por el proceso PMON el cual le proporciona al listener información propia de la instancia como ser nombre, carga actual y máxima , nombre del servicio proporcionado por la base de datos, información sobre servidores dedicados y/o dispatcher, etc. El PMON realiza esta tarea de envío de información al listener cada 60 segundos y si eventualmente por algún problema que lo afecte no lo hiciera, la información no podría ser registrada contra el listener de manera periódica. Entonces podremos en este caso realizar la resgistración de forma manual utilizando el comando ALTER SYSTEM REGISTER el cual fuerza la registración de la base de datos (instancia) contra el o los listener/s correspondiente. La registracion automática del servicio no requiere de ninguna configuración extra en el archivo listener.ora, pero sí debemos asegurarnos que los siguiente parámetros de inicio este correctamente configurados para que ASR funcione de manera adecuada.

service_name: el cual, como sabemos, se forma de la unión de los parámetros db_name y db_domain

instance_name: Indica efectivamente el SID de la instancia.

Por defecto, el proceso PMON registra información del servicio contra el listener local, como dijimos con configuración default, nombre LISTENER address local y puerto 1521.

Si eventualmente necesitaramos que el proceso PMON registre la instancia contra listeners NO default, es decir con dirección local pero cuyo puerto no sea el estándar 1521 y diferente nombre, debemos configurar el parámetro de inicio local_listener para dar la ubicación de cual será nuestro listener local en este caso.

Otra opción atractiva y altamente recomendable en ambiente RAC es la de registrar la instancia contra un listener remoto, donde obtenemos una opción más para robustecer las opciones de alta disponibilidad. Para realizar esta tarea debemos configurar el parámetro de inicio remote_listener indicando la dirección del listener remoto.

Como realizar la registración cruzada en RAC

Cuando estamos en un ambiente de Real Application Cluster debemos asegurarnos que la registración cruzada entre instancias se lleve a cabo correctamente, como comentamos ántes esto lo realizamos por medio de los parámetros particulares de inicio: local_listener y remote_listener.

A continuación describo los pasos que me han resultado efectivos para realizar esta tarea en un RAC de dos nodos:

1) Crear alias en el archivo tnsnames.ora del servidor (ambos) para el listener local y el remoto

LISTENER_INST1 =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = nodo1)(PORT = 1523))

)

LISTENER_INST2 =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = nodo2)(PORT = 1523))

)

2) Setear los parámetros local_listener y remote_listener referenciando a los alias correspondientes.

INST1.local_listener = LISTENER_INST1 #(local nodo1)

INST1.remote_listener = LISTENER_INST2 #(remoto nodo2)

INST2.local_listener = LISTENER_INST2 #(local nodo2)

INST2.remote_listener = LISTENER_INST1 #(remoto nodo1)

3) Para realizar la prueba podríamos levantar ambos listeners y ambas instancias y luego verificar que los listeners en ambos nodos esten escuchando para cada una de las instancias.

Muchas veces, un repaso a esta configuración puede ahorrarnos dolores de cabeza a la hora de resolver problemas de balanceo de carga y situaciones de failover.

Estimar el tiempo de rollback de una transacción

Sebastián D'Alessandro — Tue, 02 Sep 2008 13:35:40 +0000

Como es de saber, cuando una sesión termina de manera anormal, toda transacción que no ha sido confirmada todavía comenzará un proceso de rollback. En algunos casos y de acuerdo al volumen de datos en cuestión esta operación puede demorar bastante tiempo y es interesante, y a veces necesario, poder estimar cuanto será ese tiempo.
Podemos entonces consultar las vista v$transaction y v$session para poder calcular cuan larga será la espera para que finalice la operación de rollback.
La siguiente consulta nos devolverá la cantidad de bloques de undo utilizados por la transacción

SELECT a.used_ublk
FROM v$transaction a, v$session b
WHERE a.addr = b.taddr SELECT a.used_ublk
FROM v$transaction a, v$session b
WHERE a.addr = b.taddr
AND b.sid = //Sid en cuestión//

Si al correr la consulta nos retorna 85000 bloques y al esperar un minuto y ejecutar nuevamente la consulta tenemos 80000 bloques utilizados, obtenemos una tasa de liberación de 5000 bloques por minuto.
De esta manera estamos en condiciones de calcular que, a una tasa de liberación de 5000 bloques por minuto tardará 16 minutos en liberar los restantes 80000 bloques utilizados.

(80000 bloques)/(50000 bloques/minuto) =16 minutos para finalizar la operación.

Con esta sencilla fórmula podremos estimar con bastante aproximación el tiempo empleado para largas operaciones de rollback.