UnDomain Un friki suelto por la red

oracle


Objetos cerca del MAX_EXTENTS

A veces, el sistema de monitorización nos avisa de que hay objetos en la BDD que están llegando la máximo de extents, pero no nos dice cual es.

Así que para eso, y para ver como van los extents de los objetos, utilizo esta query:

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, EXTENTS, MAX_EXTENTS, DECODE(MAX_EXTENTS,0,0,ROUND(EXTENTS*100/MAX_EXTENTS,2)) AS PERCENT_OCUPADO, MAX_EXTENTS-EXTENTS AS FREE_EXTENTES
FROM DBA_SEGMENTS
where DECODE(MAX_EXTENTS,0,0,ROUND(EXTENTS*100/MAX_EXTENTS,2)) > 75
ORDER BY 7, 8 DESC;

Tags:

Clonar binarios Oracle (Oracle Home)

Algunas veces, necesitamos copiar una BDD entera, pero instalar los binarios desde el principio puede ser un poco pesado si tenemos una gran cantidad de parches instalados.

Esto no suele ser mucho problema si se tratan de servidores distintos, pero si es en el mismo servidor, la cosa cambia.

Para estos casos, una buena opción es clonar la BDD mediante una clonación de binarios (Oracle Home) y una posterior copia homogénea de datos (datafiles, controlfiles, etc...) a nivel de ficheros.

Por el momento, vamos a ver como realizar una clonación completa del Oracle Home.

Tags:

ORA-600: kqd-objerror$

Renombrando una tabla, un usuario ha dejado un trigger en estado invalido. Al intentar recompilar o borrar el trigger, el sistema nos da un error ORA-603 causado por un ORA-600 (algunas veces solo el ORA-600).

Buscando algo por el Metalink de Oracle, y después de no encontrar nada, Google me remitió a la solución esta web: http://oracleblues.blogspot.com/2010/08/ora-600-kqd-objerror.html

Aunque la nota a la que hace referencia (1160244.1) no la he encontrado, los pasos para solucionarlo son sencillos, aunque alguno da un poco de miedo.

El error se debe a que el trigger no se encuentra en la lista de objetos inválidos de la BDD. Al intentar hacer algo con él, se intenta actualizar dicho registro, pero como no existe, se produce el error. En resumen: es un error de inconsistencia de datos del sistema.

El error que nos produce es como el siguiente:
ORA-00600: código de error interno, argumentos: [kqd-objerror$], [D], [0], [90], [OBJETO], [], [], [], [], [], [], []

Es posible que el código varíe en el segundo argumento, ya que la [D] corresponde a un Delete y una [U] a un Update (además de indicar el objeto en cuestión).

La solución se basa en añadir este objeto a la lista de objetos inválidos de la BDD. Esta lista es la tabla de sistema OBJERROR$.

Pero hay un paso imprescindible, que da un poco de miedo: shutdown abort.
Esto se hace para evitar que la modificación que hemos hecho manualmente sea eliminada por el propio sistema.

Los pasos a seguir son los siguientes:

INSERT INTO SYS.OBJERROR$ VALUES(SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME='nombre_objeto');
COMMIT;
SHUTDOWN ABORT
STARTUP

Después de esto, ya podremos hacer lo que necesitemos con el objeto en cuestión.

Espero que sea de utilidad.

Clonar BDD Oracle

Este procedimiento es el que utilizamos para crear un clon de una BDD Oracle, pero con un nombre y HOME distinto.

La idea es poder crear una segunda BDD con exactamente los mismos datos, usuarios y configuración que una BDD ya existente, pero con un nombre distinto, lo cual nos permite tener las dos en el mismo servidor sin que se den de tortas entre ellas.

También sirve para clonar entornos, haciendo que las diferencias entre ellos sea totalmente nulas (y evitar que los programadores nos lloren :P). En este último caso, el procedimiento es el mismo (salvo algunos pequeños detalles que se comentan) pero el destino no es una BDD nueva sino una ya existente.

Vamos a ello:

Tags:

Informes en blanco con AWR en Oracle 11g

Esta semana me ha pasado una cosa curiosa. Cuando he ido a sacar unos reportes con el AWR en una BDD 11g, me he encontrado con que el reporte salía sin datos.

¿A que se debe esto? Pues muy sencillo.

Resulta que en Oracle 11g Standard Edition el AWR viene desactivado por defecto, teniéndolo que activar tu a mano en caso de tener la licencia.
Tu verás que el job interno sigue realizando las capturas, pero cuando saques un informe con el AWR te saldrá sin datos y con un tiempo de BDD de cero (con su correspondiente aviso en la cabecera del mismo).

Para activar el AWR no tenemos mas que modificar el parámetro CONTROL_MANAGEMENT_PACK_ACCESS de la siguiente manera:

ALTER SYSTEM SET CONTROL_MANAGEMENT_PACK_ACCESS=DIAGNOSTIC SCOPE=BOTH;

Por suerte, este parámetro se puede modificar en caliente, con lo que no necesitamos reiniciar la BDD.

Otro valor opcional a DIAGNOSTIC es DIAGNOSTIC+TUNING (es el valor por defecto en el caso de una Enterprise Edition), lo cual nos permite el uso de los paquetes específicos para el tuning de querys, como el SQL Tuning Advisor.
Como en mi caso no lo necesito, lo dejo en DIAGNOSTIC.

Ahora, solo tenemos que esperar a que se generen nuevos snapshots (por defecto, se generan cada hora) para sacar nuestro flamante informe.

NOTA: Esto mismo también vale para activar el ADDM.

NOTA 2: Si ya tienes una Enterprise Edition y sigues teniendo este problema, verifica que el parámetro TIMED_STATISTICS está a TRUE.

Tags:

Recrear tablespace temporal en caliente

Alguna vez me ha pasado (la última, hoy mismo) en la que se me queda algún tablespace con el autoextend activado. Esto no es muy grave, salvo que sea el temporal y estemos justos de espacio.

¿Porque? pues porque basta con que un proceso/programa se salga de madre para que te la líe parda y te llene todo el espacio del disco en cuestión de segundos (estos programadores...).

Una vez ocurrido esto, basta con modificar el tamaño del tablespace para solucionarlo... pero no todo va a ser tan fácil. Lo mas seguro es que tengamos una WaterMark que nos impida reducir el tamaño dándonos un bonito error al intentarlo:

ORA-03297: file contains used data beyond requested RESIZE value

¿Y ahora que? Pues nada, vamos a tener que recrear el tablespace temporal. Y vamos a hacerlo en caliente.
Los pasos son los siguientes:

CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/database/oradata/temp2_01.dbf' SIZE 10M REUSE AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
ALTER DATABASE TEMPFILE '/database/oradata/temp01.dbf' DROP INCLUDING DATAFILES;
ALTER TABLESPACE temp ADD TEMPFILE '/database/oradata/temp01.dbf' SIZE 512M AUTOEXTEND OFF;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;

Con esto ya tenemos el temporal al tamaño que hace falta y con el autoextend desactivado.

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:
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