Archivo del Autor: admin

Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

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]

 

Como evitar los .aud

Posted on por

Hoy tenemos uno de los parámetros mas sencillos de modificar y que nos evitaran quebraderos de cabeza.

Muchas veces   a la hora de revisar el filesysten encuentras muchisimos ficheros .aud , estos ficheros con poca utilidad real en el día a día pueden llegar a generar verdaderos problemas de rendimiento en las operaciones con los directorios que los continen.

¿Que hacemos con estos ficheros?

La respuesta es facil, si no los vas a usar,deshabilitalos.

Solo has de cambiar el parámetro  audit_sys_operations=FALSE

 

Otra opcion es rotarlos y/o borrarlos, la manera de saber donde van parar y rotarlos, para ello puedes consultar lel parámetro   audit_file_dest

 

QL> show parameter audit_file_dest

NAME                                 TYPE        VALUE
———————————— ———– ——————————
audit_file_dest                      string      /opt/oracle/app/product/11.2.0/grid/rdbms/audit