Tablas que desaparecen en el export

Hola

Vamos hoy con un pequeño expediente X. tenemos una base de datos 11g de la que queremos mover los datos a una base de datos de test. Lo primero que se nos ocurre es hacer un export de la misma con el comando exp  y llevarla a el entorno de test.

Sinembargo, al llegar a allí nos damos cuenta de que faltan objetos.

¿como es posible que nuestro export de toda la vida no haya sacado todas las tablas del esquema?

La respuesta es sencilla : por haber usado nuestro export de toda la vida

Aunque muchas veces sea mas comodo el uso del exp que de el expdp  ( especialmente por no tener que crear un directorio en la instancia),  el uso del exdp debería de ser obligatorio en nuestro día a dia,  ya que nos salvará de quebraderos de cabeza como este.

Pero,  seguramente  os estaréis preguntando a que es debido este problema.

 

Oracle 11g viene con la nueva funcionalidad deferred_segment-creation=TRUE activada por defecto.  Esto provoca que, al crear los objetos del esquema de la aplicacion en la base de datos no cree todos los segmentos de los mismos, sino que solamente creee los segmentos que contienen datos.

Nuestro «export de toda la vida» no es capaz de detectar esto,  exportandonos «solamente» los segmentos exsistentes en la base de datos,  sin embargo,  el nuevo expdp es mas listo,  y es capaz de exportar todos los objetos,  independientemente de que contengan datos  o no.

¿Como saber si tengo este tipo de tablas?

Podemos ver que objetos no están creados con la columna SEGMENT_CREATED  de las vistas del USER_TABLES, USER_INDEXES o USER_LOBS.

pregunta a ver que tablas  no tienen segmentos, si estásen una 11g seguramente te lleves una sorpresa.

select * from user_TABLES where  SEGMENT_CREATED='N'

Y en lo que se refiere a esta nueva funcionalidad de la 11g, cuidadito con ella,  por que,   seguramente nos traera algún que otro susto mas.

 

Bloqueos: TX – Allocate ITL Entry

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

 

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

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

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]