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]

 

Buscando el propietario de los lobs

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

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

Que version tengo de oracle ?

Hoy vamos a añadir una nueva entrada «para dummies».

La respuesta a la pregunta del título es muy facil, podemos obtenerla de la  tabla PRODUCT_COMPONENT_VERSION , o bien mirando simplemente la vista dinámica v$version .

Si quremos mirar la primera desde sqlplus, lo mejor será el dar formato previamente a las columnas,  la consulta sería algo similar a .

set linesize 120;
column PRODUCT format a60;
column VERSION format a20;
column STATUS format a20;
select * from product_component_version;

También podemos obtener información de que hay instalado y la version con


set linesize 120;
column comp_name format a60;
column VERSION format a20;
column STATUS format a20;
SELECT comp_name, version, status
FROm dba_registry
ORDER BY 1;

Si con esto no estais satisfechos, podeis  hurgar en el inventory de Oracle y ver con mas detalle que se ha puesto, especialmente los parches instalados .

Esto puedes hacerlo con

$ORACLE_HOME/OPatch/opatch lsinventory

 

Hay un caso en el que  esto no puede servirnos, y es cuando tenemos una 10g,11g que no ha sido creado desde el DBCA, en ese caso puede que el banner de la version de oracle no nos indique si es una version Estandard o Enterprise.

Para averiguarlo en ese caso modemos mirarlo en el fichero

$ORACLE_HOME/inventory/Components21/oracle.server/*/context.xml

En este fichero xml podemos mirar la propiedad s_serverInstallType donde nos dira si es estandard (SE) o Enterprise (EE).

En la version 11g el fichero a buscar es el
$ORACLE_HOME/inventory/globalvariables/oracle.server/globalvariables.xml
y tenemos que buscar la variable oracle_install_db_InstallType