Archivo por meses: julio 2012

Bloqueos: TX – Allocate ITL Entry

Posted on por

Vamos a ver un evento de espera de fila que no es muy usual.

El TX – Allocate ITL Entry es un evento de espera que suele ir asociado no tanto a problemas del desarrollo sino a problemas de la arquitectura de la base de datos. Este evento se da cuando ha varias transacciones DML compitiendo por el mismo bloque de datos.

La solución para minimizar este tipo de eventos pasa por aumentar el valor del INITRANS del objeto.

Hay que recordar que, un aumento del initrans del obejto no es retroactivo, con lo que , en la mayoria de los casos habrá que  recnonstruir el objeto (a no ser que podamos asumir que solamente se lleve a cabo el cambio en los nuevos registros).

Si sigue apareciendo este evento, habría que aumentar el PCTFRE  del objeto (recordar que este ultimo aumento tendrá consecuencias sobre el uso del espacio de la base de datos).

 

Al final , como siempre , todo esto está perfectamente explicadito en el metalink ,concretamente en  «Enq: TX – Allocate ITL Entry [ID 1472175.1]»

Catalogos privados virtuales en rman

Posted on por

 

Una de las mejoras que ha imlementado Oracle en la gestión del catálogo es la cracion de catalogos privados virtuales . Esta funcionalidad prermite tener en la misma instancia de catálogo (normalment rcat) los catalogos de distintos entornos de manera totalmente estanca.

Para hacer este tipo de catálogo es necesario:

  1. Desde sqlplus crear un esquema en rcat para cada catalogo  (usuario virtual)
  2. Desde sqlplus damos permisos RECOVERY_CATALOG_OWNER al usuario virtual
  3. Desde el RMAN en el catalogo general y sin conectarse al target damos los permisos «GRANT REGISTER DATABASE TO» al usuario virtual
  4. Desde RMAN conectamos con el usuario virutal y ejecutamos «create virtual catalog;»
  5. Desde RMAN registramos la base de datos.

Los catálogos privados virtuales es una funcionalidad de la 11g, así pues, si quieres registrar una base de datos anterior a la 11g el paso 4 deberá de cambiarse por

SQL> CONNECT usuario_virtual/pass@rcat
SQL> exec owner_general.dbms_rcvcat.create_virtual_catalog;

variables en entornos multinstancia

Posted on por

Vamos a por otra de newie.

Que ocurre cuando tenemos que hacer un shell script y hemos de cargar las variables de entorno teniendo varios entornos para el usuario oracle en ese servidor.

Tendremos que usar el oraenv en modo no interactivo.

¿Como se hace esto?

Muy sencillo, poniendo la variable de entorno ORAENV_ASK=NO

Así pues, un script sencillo para lanzar este export sería :

#!/bin/bash
export FECHA=`date +%d-%m-%Y_%H-%M`
export ORACLE_SID=$1
export ORAENV_ASK=NO
. oraenv
${ORACLE_PRODUCT}/bin/expdp system/xx schemas=blog DUMPFILE=blog.dmp DIRECTORY=vgbackup logfile=blog_${FECHA}.log ESTIMATE=STATISTICS

A este script habría que pasarle como parámetro el SID de la instancia  y nos dejará el log del export con la fecha, lo que facilitará ver posibles errores aun despues de volver a lanzar el proceso

 

‘wait for possible quiesce finish’ regenerando la consola

Posted on por

Regenerar el EMC en una 10g es siempre una caja de sorpresas. Como vimos en una entrada anterior la base de datos se pone en modo quiesce  al menos hasta una version de parcheado  , pero  ¨que ocurre si el tiempo pasa y pasa y el proceso no avanza

 

oracle@server:emca -repos recreate
STARTED EMCA at Jun 4, 2012 10:13:56 AM
EM Configuration Assistant, Version 10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.
Enter the following information:
Database SID: ORCL
Listener port number: 1521
Password for SYS user:
Password for SYSMAN user:
Do you wish to continue? [yes(Y)/no(N)]: Y
Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /opt/oracle/product/10.2.0/db_1/cfgtoollogs/emca/produccion/emca_2012-06-04_10-13-56-AM.log.
Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMReposConfig dropRepository
INFO: Dropping the EM repository (this may take a while) ...

Como deciamos en la entrada anterior, muchas veces la instancia se pone en modo «quiesce», pero ,  puede haber sesiones que no le dejen ponerse en ese modo, y por eso no pueda ser capaz de eliminar el repositorio.

Si miramos la sesion en la que estamos haciendo  el   vmos que  esta en un evento de espera ‘wait for possible quiesce finish’

mediante la consulta :

 Select p.spid, s.osuser, s.machine, s.username, s.sid, s.serial#
 from v$session s, v$process p
 where p.addr = s.paddr
 and s.sid in (select sid from v$lock where type = 'TX');

podemos ver que sesiones son y hacer lo que queramos con ellas ( matarlas o esperar ).

En mi experiencia, las veces que me ha ocurrido la solución ha pasado por hacer estos  procesos en una ventana programada  en horario en el que no haya usuarios, ya que, cuando la base de datos tiene este tipo de sesiones no suele ser algo  excpcional, sino que suele ser parte de la carga habitual de la base de datos y este tipo de sesiones irán apareciendo una tras otra  entorpeciendo el proceso de regeneracion de la consola

Como siempre, la solucion la tenía Oracle en la nota [152819.1]

 

Buscando el propietario de los lobs

Posted on por

Hoy vamos con otra entradita sencilla y de uso bastante comun.

¿Cuantas veces nos hemos encontrado con un objeto LOB que no sabemos que o de quien es por que su nombre no es descriptivo?

Para ayudarnos a lidiar con estos casos, oracle tiene la vista dba_lobs y all_lobs.

Gracias a estas vistas, con una sencilla consulta podemos saber a quien pertenece este lob que nos incordia.
SELECT owner, table_name, column_name
  FROM all_lobs
 WHERE segment_name = ‘SYS_LOB0000XXXX$$$’

Despues de saber de que esquema y tabla estamos hablando, seguramente querras saber cuanto ocupa.

select sum(dbms_lob.getlength ( ‘SYS_LOB0000XXXX$$$’))  as bytes  from OWNER.TABLE_NAME;

 

 

Como siempre, si los lobs te vuelven loco, puedes ir a buscar mas informacion en la  Nota :

RDBMS Large Oobejst (LOBS)  [ID 1268771.1]