UnDomain Un friki suelto por la red

oracle


Parámetros no documentados de Oracle

hay veces que toca modificar parametros "raros". Son esos parametros que comienzan por el simbolo "_" y que no vemos por ningún lado en la vista V$PARAMETERS.

Bueno, pues que sepais que existen unas tablas que nos dicen que parametros hay y cuales son sus valores actuales.

Podeis sacar todos esos parametros con la siguiente query:


SELECT
a.ksppinm "Parameter",
a.ksppdesc "Description",
b.ksppstvl "Session Value",
c.ksppstvl "Instance Value"
FROM
x$ksppi a,
x$ksppcv b,
x$ksppsv c
WHERE
a.indx = b.indx
AND a.indx = c.indx
AND a.ksppinm LIKE '/_%' escape '/';

Además, con una simple modificación puedes ver TODOS los parametros. Especialmente util para provar parametros en "tiempo real":


SELECT
a.ksppinm "Parameter",
a.ksppdesc "Description",
b.ksppstvl "Session Value",
c.ksppstvl "Instance Value"
FROM
x$ksppi a,
x$ksppcv b,
x$ksppsv c
WHERE
a.indx = b.indx
AND a.indx = c.indx;

Eso si, esta vista se ha dejecutar con el usuario SYS.

La query la he sacado de http://oraclenotepad.blogspot.com/2010/04/listar-parametros-indocumentad...

Database Packages and Types Inválido

Bueno, pues aquí estamos, actualizando como locos todas las BDD Oracle a la versión 10.2.0.4 e instalando el último PSU.

Durante estas actualizaciones, hay un caso en el que nos hemos encontrado con que el componente Database Packages and Types se nos ha quedado en estado Invalido.

Lo primero que he pensado es "mierda!, voy a tener que hacer una marcha atrás!". Pero no.

Gracias al tito Metalink, he encontrado la solución, y es bastante sencilla.

Resulta que si objeto DBMS_SQLPA queda invalido, todo el componente Database Packages and Types se ve también invalido.

Lo que hay que hacer es corregir este componente, y eso se hace con los siguientes pasos:

-- como SYSDBA:
drop table plan_table;
@?/rdbms/admin/utlxplan
@?/rdbms/admin/prvtspao.plb
@?/rdbms/admin/utlrp.sql
select * from dba_registry;

Espero que os sea de utilidad ;)

Como configurar el Enterprise Manager en Oracle 11g R2

Cuando instalamos una BDD es posible que no configuremos el Enterprise Manager (EM) pensando que no lo usaremos. Esto suele pasar cuando tiene el EM local de la 9i, o el EM Console, y no te quieres complicar la vida instalando estos servicios (que consumen lo suyo en el servidor) en cada BDD. Sobretodo si tienes una media de 5 por servidor :P

Ahora nos hemos encontrado con que un proyecto "necesita" esta consola, asi que se la tenemos que configurar. Lo bueno es que estos pasos no requieren parar la BDD :)

Antes de hacer nada, hemos de tener configurado bien las variables de entorno:

  • ORACLE_HOME=[Path oracle home]
  • ORACLE_SID=[SID]
  • ORACLE_UNQNAME=[SID]

Para arrancar el EM solo tenemos que ejecutar el siguiente comando:
$ORACLE_HOME/bin/emctl start dbconsole

Si no tenemos configurado el EM esto nos dará un error como el siguiente:
OC4J Configuration issue.
/<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<HOSTNAME>_<DBNAME> not found.

Basciamente nos está diciendo que no tiene la configuración de esta BDD para poder arrancar el EM. Así que tenemos que crearla... Para eso, solo tenemos que lanzar el siguiente comando:
$ORACLE_HOME/bin/emca -config dbcontrol db -repos create

Esto te pedirá el password del usuario SYS, DBSNMP y SYSMAN (este lo creará nuevo) y el puerto del listener.

Es posible que ya existan datos de repositorio. si es así, al crear la configuración nos dará un error. Si miramos el log que nos indica veremos que hay un ORA-20001.
Para solucionar esto, simplemente tenemos que borrar el repositorio y crearlo de nuevo. Para borrar el repositorio, ejecutamos el siguiente comando:
$ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop

Después de un rato, nos dirá que se ha eliminado completamente. Ahora ya podemos crearlo con el comando del principio.

Si tenemos algún otro problema, yo recomendaría visitar el Metalink ;)

Salud!

Tags:

Identificar parametros de inicio obsoletos

Cuando migramos un Oracle a una versión mas nueva y la arrancamos por primera vez, nos pueden salir algunos mensajes del tipo "Deprecated or obsolete parameter option", pero sin ninguna pista mas...

¿Como identificamos cuales de los parámetros son los que están obsoletos?

Pues muy fácil, con la siguiente query:

SELECT NAME FROM V$OBSOLETE_PARAMETER WHERE ISSPECIFIED = 'TRUE';

Algo sencillo y la mar de útil :)

Tags:

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.

Distribuir contenido

Afiliados:


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