UnDomain Un friki suelto por la red

oracle


Oracle Total Recall

Hace tiempo que no ponia ningún articulo serio, así que para variar un poco, vamos a poner algo de Oracle.

si, ya se que suena como la peli de nuestro amigo el Chuache, pero este es un post serio (o al menos lo intenta, pobrecito).

El Total Recall de Oracle es una función la mar de interesante, que permite almacenar los valores historicos de los registros de una tabla. La manera en que los almacena hace posible que podamos consultar el valor de determinado registro en determinada fecha sin necesidad de acceder a un moledo de datos paralelo o a un Data WareHouse. Aunque también podemos acceder a las tablas donde se almacena esta información para poder hacer nuestros propios informes y consultas personalizadas.

Este componente viene por defecto en la BDD y no puedes escojer si lo quieres instalar o no (al menos, yo no lo he visto), aunque tiene una licencia a parte a la BDD. Se encuentra disponible en las versiones 10g y superiores, pero no se si también está en las 9i y anteriores.

Lo bueno que tiene es que no se tiene que instalar nada y es muy facil de administrar, además de útil.
El problema es que la BDD crecerá una burrada.

Vamos a ver como configurar nuestro propio Total Recall.

Tags:

¿Tengo instalado un Oracle CPU?

Antes de empezar, explicar que un Oracle CPU es un Critical Patch Update, usease, un paquete de actualizaciones criticas.

Estos parches los genera Oracle cada 3 meses y engloba todas las actualizaciones de seguridad "imprescindibles" para que nuestra BDD sea segura.
Oracle recomienda instalar siempre estos parches, pero hay ocasiones en las que no es precisamente recomendado (como cuando tienes SAP) o realmente no es necesario (redes muy muy muy seguras o sin acceso desde el exterior).
Estos parches son acumulativos, es decir, el último de todos tiene lo mismo que el anterior, mas todo lo nuevo que ha salido durante estos tres meses, y su instalación reemplaza el anterior (en muchos casos hay que desinstalarlo a mano.... un peñazo).

Esta semana pasada me he encontrado con mi primera instalación de un CPU de Oracle... y la primera pregunta que me ha surgido es "¿como se si tengo ya instalado un CPU?".

Lo primero que hice fue lo siguiente:

opatch lsinventory

Pero el problema es que los CPUs son parches normales que no se diferencian de los anteriores (al menos en HP-UX son un grupo de parches, por lo que es mas dificil de ver de esta manera), así que me quedé en las mismas.

Después de probar y rebuscar un poco he encontrado una manera la mar de sencilla de saberlo, y es con esta simple consulta:

SELECT * FROM SYS.REGISTRY$HISTORY;

Si tenemos una CPU instalada nos dirá unos datos como estos:

ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS
11/20/2009 17:32:34,753698 CPU SERVER 10.2.0.3.0 7592354 CPUJan2009

Y listos!!! ya sabemos que CPU tiene instalada y cuando se instaló.

Y vosotros, ¿sabes alguna otra manera de verlo?

Tags:

LogMiner - Buceando en los redo

No se vosotros, pero a mi me ha tocado escarbar un poco entre los redo log (online y offline) para averiguar que le pasa a una BDD que se nos ha vuelto un poco loca.

Yo no sabia de esta herramienta, pero ha sido tener la necesidad de usarla y enseguida me la han recomendado... así que como es algo útil y hace tiempo que no pongo nada en el blog, voy a poner como se usa esta fantástica herramienta.

El LogMiner es un paquete que viene por defecto instalado en la BDD y su función es la de poder interpretar el contenido de los REDO de una manera cómoda y sencilla. Tan cómoda y sencilla como puede ser consultar unas vistas de la BDD.

Para poder utilizar este paquete necesitamos tener definido el parámetro 'utl_file_dir', y conocer la ruta a la que apunta:
select value from v$parameter where name='utl_file_dir';

Si no lo tenemos definido, lo tenemos que configurar, pero ojo, que es un parámetro estático. Tendremos que reiniciar la BDD para modificarlo:
alter system set utl_file_dir='[ruta]' scope=spfile;

A partir de aquí, todo se ha de realizar con el usuario SYS y solo es valido para la sesión actual. Es decir, no puedes realizar todo esto con un usuario, y luego abrir otro para consultar los datos. Una vez se cierra la sesión de SYS con la que se ha hecho todo, también se cierra la sesión de LogMiner.

Esa ruta la necesitaremos para poder crear el "diccionario", que no es más que un fichero de texto de unos 20MB con un churro de sentencias SQL.

Este fichero es que el usará Oracle para interpretar los ficheros que le indiquemos y se ha de crear con la BDD con la que se han creado los redo. Usease, no puedes utilizar un fichero de diccionario de otra BDD.

Para crear este fichero solo se ha de indicar como parámetros el nombre del fichero y la ruta donde se quiere crear. Esta ruta ha de formar parte del directorio indicado en el parámetro 'utl_file_dir' o de lo contrario, no se podrá crear.
exec DBMS_LOGMNR_D.BUILD( DICTIONARY_FILENAME =>'[nombre del fichero]', DICTIONARY_LOCATION => '[ruta donde crear el fichero]');

Ahora que tenemos creado el fichero de diccionario solo tenemos que indicar los ficheros que queremos investigar.
Eso es tan fácil como esto:
exec DBMS_LOGMNR.add_logfile('[fichero REDO con ruta completa]');

Si quieres investigar varios ficheros, solo hay que repetir el comando con los ficheros deseados, tanto ON-LINE como OFF-LINE.

Para eliminar un fichero que hemos añadido por error, o simplemente porque no tiene la informacion que quieres, se utiliza este comando (tranquilo, no borra nada):
exec DBMS_LOGMNR.REMOVE_LOGFILE (LOGFILENAME => '[fichero REDO con ruta completa]');

Una vez tenemos "añadidos/eliminados" todos los ficheros solo tenemos que "iniciar la sesión" de LogMiner, para lo que necesitaremos los datos del diccionario que hemos creado al principio:
exec DBMS_LOGMNR.START_LOGMNR(DICTFILENAME =>'[ruta y nombre del diccionario]');

Y con esto ya podemos ver todo lo que se ha hecho en la BDD.... pero no solo eso, sino que también tendremos la sentencia SQL para deshacerlo:
select sql_redo, sql_undo from v$logmnr_contents;

Por descontado, hay mas vistas, pero de momento solo he necesitado mirar en esta....
Si queréis sacar mas chica, no dudéis en hacer un "select *" a las siguientes vistas:

  • V$LOGMNR_CONTENTS
  • V$LOGMNR_DICTIONARY
  • V$LOGMNR_LOGS
  • V$LOGMNR_PARAMETERS
  • V$LOGMINER_CONTENTS

Para finalizar la sesión de LogMiner solo es necesario lanzar el siguiente comando:
exec DBMS_LOGMNR.END_LOGMNR;

Por descontado, si se cierra la conexión con la BDD se cierra automaticamente la sesión de LogMiner.

De momento no he tenido que trastear mucho con esta utilidad, así que si alguien puede aportar algo, será bien venido :)

Tags:

Pasar de RBS a UNDO

¿Que qué es el RBS y el UNDO?
Pues el RBS es el RollBack Segment y es la forma en la que las BDD anteriores a la 9i gestionan los rollback. El UNDO es el método nuevo (a partir de la 9i) y es gestionado automáticamente creando y eliminando los segmentos de rollback a medida que los necesita.

Si tienes una BDD migrada de una versión anterior a la 9i posiblemente tengas un tablespace llamado RBS o algo así por el estilo.
En este caso, no estaría de mas hacer una pequeña modificación y pasar a UNDO, que además, hace juego con mi alias y mi web ^_^

Tanto si lo necesitas como si es simplemente por curiosidad, vamos a ver paso a paso como hacer esta modificación... y tranquilo, es muy fácil y rápido :)

Tags:

Desactivar WebCache en OAS... y algo más...

¿Alguien sabe lo que es el WebCache del OAS? Pues es el componente del OAS que hace la función de cachear los JAVAs publicados y redirigir las peticiones al Apache (servidor HTTP).

Pues bien, resulta que si tenemos un OAS en el que no tenemos ningún JAVA publicado (se entiende con esto como una aplicación deployada) este componente solo hace la función de PROXY. ¿Y que pasa con esto? Pues que tenemos un componente "inútil" que consume recursos del servidor, retarda el tiempo de respuesta de la aplicación (a la hora de cargar, al menos) y que puede ser una fuente de problemas y dolores de cabeza (cosa que me esta pasando) ya que si se cae, dejan de funcionar todas las aplicaciones publicadas, sean JAVA, Forms o HTML.

Precisamente por esto, Oracle recomienda desactivar este componente si solo publicamos aplicaciones Forms (o que no son JAVA).... pero esto tiene un pequeño "problema".
Resulta que por defecto, el Apache esta escuchando en el puerto 7778 y/o 7777 y es el WebCache el que se encarga de redirigir las peticiones del puerto 80 a estos, con lo que acceder si tenemos IPs virtuales se hace mas "puñetero", o incluso imposible para el usuario medio/básico (también conocido como "luser"), ya que se ha de indicar específicamente el puerto al que se quiere acceder.

Esto, aunque puede ser fácil para alguien que conozca bien todos estos componentes, para el resto de mortales no es tan trivial.
Así que vamos a ver como podemos desactivar el WebCache y que "nadie" se entere de ello.

Como esto es lo que he hecho yo para conseguirlo y mis conocimientos al respecto son mas bien escasos, es posible que haga alguna burrada, así que pido perdón de antemano y agradeceré todas las correcciones y sugerencias que tengáis :)

Ahora, vamos al meollo del asunto...

Tags:

Recrear Phisical StandBy en DataGuard con Oracle 10g

El otro día me encontré con que el DataGuard que monté hace unas semanas tenia la StandBy sin actualizar.
Resulta que al ser maquinas de prueba, el disco se llenó sin que saltaran alarmas, con lo que algunos Archivers no se replicaron y los que si se replicaron no se pudieron ejecutar.

Cuando te encuentras con estos casos tienes dos posibilidades:
1) Recuperar la StandBy partiendo de un backup de los archivers de la BDD Primary.
2) Recrear la StandBy desde cero.

La primera opción tiene la ventaja de que no requiere parar en ningún momento la Primary, y los archivers se siguen replicando (aunque sin ejecutarse).

En mi caso, al ser un entorno de pruebas que no tiene ni backup ni monitorización ni nada por el estilo, me toca la opción... y eso es lo que voy a explicar: Como recrear la Standby desde cero.

Afectación en rendimiento/seguridad de datos en DataGuard

Siguiendo con este articulo, toca detallar la afectación de rendimiento en una BDD al montar un DataGuard y su seguridad de datos (el riesgo de pérdida de datos).

Hay que tener en cuenta que cuanto mas seguridad de datos queramos, mayor será la afectación al rendimiento de la Primay existirá. Así que lo ideal al montar el DataGuard es tener claro cual es la prioridad.
Tranquilos, esto se puede modificar sin problemas ni riesgos.

La diferencia entre un tipo de DataGuard y otro no es mas que el método en que replica los Archivers de la BDD Primary a la StandBy.

Esta configuración se realiza en el fichero de configuración de la BDD StandBy, mas concretamente en el parámetro LOG_ARCHIVE_DEST_2:

*.LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'

De este parámetro nos quedamos con el final de la primera línea, donde vemos LGWR ASYNC. Estos campos son los que hacen referencia al tipo de Dataguard que tenemos, o mejor dicho, al modo de transferencia de los Archivers (o Redo Log) de la Primary a la Standby.

En un libro de McGraw Hill (lo siento, no recuerdo cual, solo recuerdo que está en ingles, para variar) encontré una tabla que me guardé como referencia, y que es de lo mas útil para esto:

Tipo de escritura de Redo Log Metodo de transmisión por red Escritura en disco del Archive Log Impacto en rendimiento Riesgo de pérdida de información
LGWR SYNC AFFIRM Altísimo Mínimo
LGWR SYNC NOAFFIRM Muy alto Bajo
LGWR ASYNC AFFIRM Alto Moderado
LGWR ASYNC NOAFFIRM Moderado Moderado
ARCH SYNC AFFIRM Moderado Moderado
ARCH SYNC NOAFFIRM Bajo Alto

Veamos las opciones que tenemos para cada uno de los parametros...

Preview de tunning en una BDD

Uno de los principales puntos clave en una BDD es el rendimiento, y también es una de las cosas más complicadas.
Muchas veces, los problemas de rendimiento son "culpa" de los programas (aquí incluyo el modelo de datos). Otras veces es cosa de la configuración de la propia BDD, que no se ajusta a los requerimientos de la aplicación o a su evolución.

La siguiente "query" nos sirve para saber el estado general de una BDD, de manera que nos hace una especie de "preview" para poder oriental las acciones de tunning de la BDD. Nos indica algunos de los parámetros clave a modificar (generalmente ampliar) dependiendo de los resultados.

Como montar un Oracle DataGuard con Phisical Standby en Oracle 10g

Durante los días de vacaciones (vacaciones de mis compañeros de trabajo, claro), me he dedicado, entre otras cosas, a montar un DataGuard en Oracle 10g con una Standby física en unas máquinas de taller que me han montado muy amablemente para esto.

Como todo buen padawan que se precie, cuando toca hacer algo que nunca has hecho, lo primero que se hace es preguntárselo al Maestro Google, que para eso sabe mucho y es el maesto.

Mi primera sorpresa es la poca información que encontré en cristiano... todo venia en el idioma de la Pérfida Albión.
También es posible que yo no lo supiera buscar correctamente...

Puesto que me tocaba tragarme mi opinión sobre el idioma de los hijos de la Gran Bretaña, decidí finalmente seguir "fil parranda" los pasos indicados por la documentación original y oficial de Oracle.

Utilizando el manual oficial de oracle dedicado a los DataGuard y guiado por una nota oficial del MetaLink (343424.1), conseguí montar con éxito, pero no sin esfuerzo, el correspondiente Dataguard.

A continuación indico paso a paso como lo he hecho...

Distribuir contenido

Mientras tanto, en "¿Alguien ha visto mi martillo?"...


Inicio de sesión


Todo el contenido mostrado ha sido obtenido libremente por la red. Las marcas indicadas son propiedad de sus legítimos dueños y se muestran a modo informativo de manera libre y voluntaria, sin intención publicitaria ni ánimo de lucro. Todo el material propio, y salvo que se indique lo contrario, se encuentra bajo licencia Creative Commons. Si tienes el Copyright de algún contenido o has detectado algna anomalia, por favor, infórmalo al correo undomain@gmail.com para ser corregido cuanto antes. El autor de esta Web no se hace responsable del contenido de terceras personas y de sites ajenos a este.

Powered by Drupal, an open source content management system