miércoles, 17 de agosto de 2011

Problema clonando un nuevo ORACLE_HOME bug 3823729 en 11.2.0.2

En estos dias estamos tratando de crear un nuevo ORACLE_HOME que contenga el PSU de Julio asi como unos parches que requerimos, para disminuir el tiempo que necesitamos bajar la base de datos al aplicar los parches al ORACLE_HOME actual, decidimos crear un nuevo ORACLE_HOME aplicar los parches en este nuevo ORACLE_HOME, clonar este ORACLE_HOME a los servidores necesarios y nada mas mover la base de datos al nuevo ORACLE_HOME. Todo iba bien, hasta que llego el punto de clonar el nuevo ORACLE_HOME, nos topamos con un bug en donde si ya tenemos un ORACLE_HOME previo, detecta procesos arriba y no te permite continuar con la clonacion


oracle@localhost /mount/oracle
oracle $ $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="/mount/oracle" ORACLE_HOME="/mount/oracle/product/11.2.0.2v2" ORACLE_HOME_NAME=11gR202v2
.
.
.
oracle $ cat /mount/oracle/oraInventory/logs/silentInstall2011-08-15_02-12-06AM.log
silentInstall2011-08-15_02-12-06AM.log
Oracle Universal Installer has detected that there are processes running in the currently selected Oracle Home. The following processes need to be shutdown before continuing:
/mount/oracle/product/11.2.0.2v1/bin/tnslsnr PSAESRV PSDSTSRV PSMONITORSRV PSMSTPRC PSPRCSRV PSRUN ora_mman_DBATEST
Oracle Universal Installer has detected that there are processes running in the currently selected Oracle Home. The following processes need to be shutdown before continuing:
/mount/oracle/product/11.2.0.2v1/bin/tnslsnr PSAESRV PSDSTSRV PSMONITORSRV PSMSTPRC PSPRCSRV PSRUN ora_mman_DBATEST
This silent installation was unsuccessful.

Como al dia de hoy no existe un parche para este bug, hicimos los siquientes pasos para poder instalar el nuevo ORACLE_HOME Con el usuario de root

root@localhost /root
root $ which fuser
/sbin/fuser

root@localhost /root
root $ mv /sbin/fuser /sbin/fuser.18082011

root@localhost /root
root $ touch /sbin/fuser

root@localhost /root
root $ chmod +x /sbin/fuser

Una vez que hicimos los pasos anteriores como root, volvemos a intentar con el usuario de oracle la clonacion del nuevo ORACLE_HOME

oracle@localhost /mount/oracle
oracle $ $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="/mount/oracle" ORACLE_HOME="/mount/oracle/product/11.2.0.2v2" ORACLE_HOME_NAME=11gR202v2
.
.
.
oracle $ cat silentInstall2011-08-16_06-56-02PM.log
silentInstall2011-08-16_06-56-02PM.log
WARNING:
The following configuration scripts need to be executed as the "root" user.
/mount/oracle/product/11.2.0.2v2/root.sh
To execute the configuration scripts:
1. Open a terminal window
2. Log in as "root"
3. Run the scripts

The cloning of 11gR202v2 was successful.

Ya terminada la clonacion, ahora nada mas regresamos el archivo fuser que movimos al principio a su locacion original

root@localhost /root
root $ mv /sbin/fuser.16082011 /sbin/fuser
mv: overwrite `/sbin/fuser'? y

Conclusion 
Espero que este bug con el me tope te sirva si te llegas a topar tu con el, segun oracle esto se va a corregir en la version 11.2.0.3.

domingo, 17 de julio de 2011

ADR - Un nuevo concepto para diagnosticar errores en 11g

Aqui de regreso con el blog, en 11g se introdujo un nuevo concepto para el repositorio de los archivos de diagnostico de la base de datos, llamado ADR (Automatic Diagnostic Repository por sus siglas en ingles) , anteriormente se utilizaban los parametros BACKGROUND_DUMP_DEST,CORE_DUMP_DEST y USER_DUMP_DEST , en estos lugares podiamos ver los archivos que nos ayudaban a hacer un diagnostico de errores de la base de datos. A partir de 11g, se introdujo la variable DIAGNOSTIC_DEST, en donde Oracle esta tratando de estandarizar la estructura de directorios para manejar los archivos relacionados a fallas y alertas. La estructura del repositorio ADR para la base de datos es de la siguiente manera:


Un cambio muy importante que se da en 11g es que el formato del archivo de alertas de la base de datos es en formato .xml, ya que lo puedes ahora visualizar de una mejor manera en OEM, pero tambien lo puedes encontrar en su formato anterior. Si quieres ver como tienes la estructura en tu base de datos, lo puedes hacer con el siguiente query

DBATEST> SELECT * FROM V$DIAG_INFO;

INST_ID NAME VALUE
---------- ------------------------------ ----------------------------------------------------------------------------------------------------
1 Diag Enabled TRUE
1 ADR Base /mount/dump01/oracle/DBATEST
1 ADR Home /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST
1 Diag Trace /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace
1 Diag Alert /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/alert
1 Diag Incident /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/incident
1 Diag Cdump /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/cdump
1 Health Monitor /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/hm
1 Default Trace File /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_18035.trc
1 Active Problem Count 1
1 Active Incident Count 75

De la misma manera, Oracle trae ahora una herramienta muy util llamada adrci, esta herramienta te permite manejar el repositorio ADR,muy importante, es que antes de mandar a llamar a la herramienta, las variables de ambiente ORACLE_HOME,PATH y ADR_HOME esten bien iniciadas. Puedes ver el archivo de alertas de la base de datos de la siguiente manera:

adrci> SHOW ALERT -TAIL 5
2011-07-17 18:04:41.207000 -04:00
Archived Log entry 4735 added for thread 1 sequence 4735 ID 0xffffffffb7363f82 dest 1:
2011-07-17 21:00:49.339000 -04:00
Thread 1 advanced to log sequence 4737 (LGWR switch)
Current log# 3 seq# 4737 mem# 0: /mount/u01/oracle/DBATEST/log/redo03a.log
Current log# 3 seq# 4737 mem# 1: /mount/u01/oracle/DBATEST/log/redo03b.log
Archived Log entry 4736 added for thread 1 sequence 4736 ID 0xffffffffb7363f82 dest 1:

Pero algo que a mi me ha gustado mucho, es la manera en que puedes ver un incidente en esta herramienta

adrci> show incident

ADR Home = /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
3041 ORA 4031 2010-11-15 05:58:35.042000 -05:00
3105 ORA 4031 2010-11-15 05:58:35.272000 -05:00
3017 ORA 4031 2010-11-15 05:58:35.272000 -05:00
2873 ORA 4031 2010-11-15 05:58:35.279000 -05:00
3153 ORA 4031 2010-11-15 05:58:35.280000 -05:00
57051 ORA 4031 2011-06-26 23:15:13.983000 -04:00
57027 ORA 4031 2011-06-26 23:15:14.239000 -04:00
56707 ORA 4031 2011-06-26 23:15:28.575000 -04:00
57019 ORA 4031 2011-06-26 23:15:32.650000 -04:00
57052 ORA 4031 2011-06-26 23:15:39.050000 -04:00
10 rows fetched

Una vez que visualizas los errores, puedes ver el detalle de ellos, asi como el trace que se genero para ese error

adrci> SHOW INCIDENT -MODE DETAIL -P "INCIDENT_ID=57052"

ADR Home = /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST:
*************************************************************************

**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 57052
STATUS ready
CREATE_TIME 2011-06-26 23:15:39.050000 -04:00
.
.
.
KEY_NAME Client ProcId
KEY_VALUE oracle@localhost.13299_1
KEY_NAME SID
KEY_VALUE 151.3
OWNER_ID 1
INCIDENT_FILE /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/incident/incdir_57052/DBATEST_dw03_13299_i57052.trc
OWNER_ID 1
INCIDENT_FILE /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_dw03_13299.trc
1 rows fetched

Esta herramienta te permite crear un paquete si asi lo requieres para enviar a Oracle, esto te evita el trabajo de andar buscando los archivos que necesitas enviar a MOS para crear un Servie Request

adrci> IPS PACK INCIDENT 57052 in '/mount/copy01';
Generated package 1 in file /mount/copy01/ORA4031_20110717222427_COM_1.zip, mode complete

Conclusion 
Espero que ahora que ya conociste la estructura y herramienta de adrci, la empieces a utilizar con mas frecuencia y sacarle todo el jugo que se pueda.

miércoles, 8 de junio de 2011

Como hacer un trace con oradebug de otra sesion

Algo muy comun que tenemos que hacer es buscar informacion de otras sesiones, ya que normalmente no son nuestras sesiones las que causan algun problema en nuestra base de datos, si no las sesiones de la aplicacion y para poder determinar que estan haciendo, una muy buena herramienta es hacer un trace de ellas. Vamos a decir que detectamos una sesion que esta haciendo mucho I/O

DBATEST>SELECT s.sid, s.serial#, s.username, s.program,s.client_info,i.block_changes
2 FROM v$session s, v$sess_io i
3 WHERE s.sid = i.sid and username not in ('SYS','SYSTEM')
4 ORDER BY 5 desc, 1, 2, 3, 4;


SID SERIAL# USERNAME PROGRAM CLIENT_INFO BLOCK_CHANGES
---------- ---------- -------------------- -------------------- ------------------------------ -------------
139 2933 HR DBATESTplus@localhost APP DE PRUEBA 1112706
(TNS V1-V3)

Lo primero que tenemos que hacer en SQLPlus es obtener la informacion de la sesion que a la que le vamos a hacer un trace

DBATEST> SELECT '''' || s.sid || ',' || s.serial# || '''' "SID,Serial"
2 ,p.pid "Oracle Process Id (PID)"
3 ,p.spid "OS Oracle Process Id (SPID)"
4 ,s.osuser "OS Client User" --
5 ,s.process "OS Client Process Id(Unix PID)"--
6 ,s.client_info "Client Info"
7 ,command
8 FROM V$SESSION S,
9 V$PROCESS P
10 WHERE (s.paddr = p.addr(+))
11 and (s.USERNAME is not null)
12 and (NVL(s.osuser,'x')<>'SYSTEM')
13 and (s.type<>'BACKGROUND')
14 and (s.sid in ('&SID'))
15 ORDER BY s.process;
Enter value for sid: 139
old 14: and (s.sid in ('&SID'))
new 14: and (s.sid in ('139'))

SID,Serial Oracle Process Id (PID) OS Oracle Process Id OS Client User OS Client Process Id Client Info COMMAND
-------------------- ----------------------- -------------------- -------------------- -------------------- ------------------------------ -------
'139,2933' 69 25963 oracle 25961 APP DE PRUEBA 2

Una vez que localizamos el PID de la sesion , vamos a utilizar la opcion de setorapid de la utileria oradebug para empezar a hacer el trace

DBATEST> oradebug setorapid 69
Oracle pid: 69, Unix process pid: 25963, image: oracle@cihcisddb102 (TNS V1-V3)

Ahora vamos a hacer le trace, con un nivel 12, este nivel te muestra las estadisticas de los eventos de espera y las variables bind


DBATEST> oradebug event 10046 trace name context forever, level 12
Statement processed.

Con este comando puedes ver el nombre del archivo trace que se esta generando

DBATEST> oradebug tracefile_name
/mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_25963.trc

Cuando queramos que termine de hacer el trace, con el siguiente comando lo apagamos


DBATEST> oradebug event 10046 trace name context off
Statement processed.

DBATEST> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the OLAP, Data Mining and Real Application Testing options

Por ultimo, usamos la utileria de tkprof para darle formato al archivo trace y ahora si buscar que esta haciendo la sesion y poder atacar el problema, en este caso la espera estaba en la escritura de los redo log files


oracle@localhost [DBATEST] /mount/oracle
oracle $tkprof /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_25963.trc prueba.txt sys=no

oracle@localhost [DBATEST] /mount/oracle
oracle $ more prueba.txt

TKPROF: Release 11.2.0.2.0 - Development on Thu Jun 9 01:23:50 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Trace file: /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_25963.trc
.
.
.
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
log file switch completion 10 0.10 1.00
log file switch (checkpoint incomplete) 20 3.06 13.13
db file scattered read 2 0.01 0.01
reliable message 28 0.00 0.00
rdbms ipc reply 28 0.00 0.00

Conclusion 
Espero que este manera de hacer un trace te ayude a encontrar esas sesiones que a veces nos causan dolor de cabeza.

martes, 31 de mayo de 2011

Como exportar un Esquema de tu Base de Datos con Datapump y con Export

Como exportar un Esquema de tu Base de Datos con Datapump y con Export
El otro dia recibi una pregunta de como hacer un respaldo de un esquema, y la respuesta es que puede ser con dos herramientas, una que es el clasico
export de Oracle y la otra con una herramienta llamada Datapump. Y aunque con las dos puedes completar el mismo trabajo, la razon para utilizar una o la otra
son muy distintas.

Una razon muy util para usar datapump es que si llegas a tener una falla, vamos a decir por falta de espacio o hasta por que se reinicio la instancia,
tiene un comando llamado START_JOB, para poder reiniciarlo, de la misma manera podemos definir el numero de procesos paralelos para efectuar el trabajo,
y entre otras de las ventajas que tiene, es que te permite estimar el tiempo que se va a tardar.

Pero una de las grandes ventajas que tiene la utileria de Export, es que esta crea los archivos en el cliente, y no en el servidor como Datapump lo hace,
y si no tienes acceso al servidor, esta es realmente la mejor manera de exportar tu informacion.

Aqui dos ejemplos de como exportar un esquema, primero con Datapump y luego con la utileria Export

Como te mencionaba arriba, Datapump crea los archivos en el servidor, asi que lo primero que tenemos que hacer, es crear un directorio en la base de datos
donde queremos que se generen los archivos dump.

DBATEST> CREATE OR REPLACE DIRECTORY DATA_PUMP_DIR AS '/mount/copy01/DBATEST/export01';

Directory created.


Una vez que creamos el directorio, creamos un archivo de parametros en donde le vamos a decir que esquema vamos a exportar, asi como el nombre del trabajo,cuantos procesos en paralelo queremos que corra y
el nombre del archivo con un comodin %U para que se generen automaticamente el numero de archivos tipo dump.

oracle $ cat expdp.par
LOGFILE=SCHEMA_EXPORT.log
DIRECTORY=DATA_PUMP_DIR
VERSION=COMPATIBLE
JOB_NAME=SCHEMA_EXPORT
PARALLEL=5
DUMPFILE=SCHEMA_EXPORT_%U.dmp
SCHEMAS=HR


Ahora si, ejecutamos Datapump con el archivo de parametros que acabamos de crear

oracle $ expdp system parfile=expdp.par

Starting "SYSTEM"."SCHEMA_EXPORT": system/******** parfile=expdp.par
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 640 KB
. . exported "HR"."COUNTRIES" 6.367 KB 25 rows
. . exported "HR"."DEPARTMENTS" 7.007 KB 27 rows
. . exported "HR"."EMPLOYEES" 16.85 KB 108 rows
. . exported "HR"."JOBS" 6.992 KB 19 rows
. . exported "HR"."JOB_HISTORY" 7.062 KB 11 rows
. . exported "HR"."LOCATIONS" 8.273 KB 23 rows
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
. . exported "HR"."REGIONS" 5.476 KB 4 rows
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Master table "SYSTEM"."SCHEMA_EXPORT" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SCHEMA_EXPORT is:
/mount/copy01/DBATEST/export01/SCHEMA_EXPORT_01.dmp
/mount/copy01/DBATEST/export01/SCHEMA_EXPORT_02.dmp
/mount/copy01/DBATEST/export01/SCHEMA_EXPORT_03.dmp
Job "SYSTEM"."SCHEMA_EXPORT" successfully completed at 23:29:20


A diferencia de datapump, con export no necesitamos crear un directorio en la base de datos, el archivo tipo dump, se va a generar en la locacion donde
ejecutemos el export. Vamos a crear un archivo de parametros para el export en donde de igual manera que Datapump definimos el esquema,

oracle $ cat exp.par
file=EXP_SCHEMA_EXPORT.dmp
log=EXP_SCHEMA_EXPORT.log
buffer=10000000
owner=HR
statistics=none


Igual, ejecutamos la utileria export con el archivo de parametros que creamos arriba

oracle $ exp system parfile=exp.par

Export: Release 11.2.0.2.0 - Production on Fri May 27 02:10:39 2011

About to export specified users ...
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user HR
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user HR
About to export HR's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
. about to export HR's tables via Conventional Path ...
. . exporting table COUNTRIES 25 rows exported
. . exporting table DEPARTMENTS 27 rows exported
. . exporting table EMPLOYEES 108 rows exported
. . exporting table JOBS 19 rows exported
. . exporting table JOB_HISTORY 11 rows exported
. . exporting table LOCATIONS 23 rows exported
. . exporting table REGIONS 4 rows exported
. exporting synonyms
. exporting views
. exporting stored procedures
. exporting operators
. exporting referential integrity constraints
. exporting triggers
. exporting indextypes
. exporting bitmap, functional and extensible indexes
. exporting posttables actions
. exporting materialized views
. exporting snapshot logs
. exporting job queues
. exporting refresh groups and children
. exporting dimensions
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully without warnings.


Conclusion
Aqui hay dos maneras de exportar un esquema de nuestra base de datos, es sencillo y muchas veces de gran utilidad y junto con este script, puedes exportar los metadatos del Usuario Lo unico que te recomiendo, es que no utilices este metodo como un metodo valido de respaldos, ya que carece de muchas propiedades de un verdadero respaldo de la Base de Datos.

jueves, 19 de mayo de 2011

Error ORA-27102 en Solaris 10 cuando si tenemos memoria en el Servidor

Error ORA-27102 en Solaris 10 cuando si tenemos memoria en el Servidor Solaris 10 tiene una funcionalidad de manejar recursos para el usuario, y existen varias comandos para administrarlos, como projadd,projmod, projdel, etc. Esto es importante saber por que, que pasa cuando sabemos que en el servidor si tenemos memoria libre pero cuando tratas de levantar la instancia te encuentras con el siguiente error


DBATEST >startup
ORA-27102: out of memory
SVR4 Error: 22: Invalid argument

Lo primero es asegurarnos que el servidor si tenga la memoria suficiente para poder levantar la instancia, con el comando top, podemos ver esta informacion:


root $ top
load averages: 0.70, 0.71, 0.73; up 39+18:13:12 23:19:17
442 processes: 430 sleeping, 11 stopped, 1 on cpu
CPU states: 99.4% idle, 0.1% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Memory: 32G phys mem, 8024M free mem, 36G total swap, 36G free swap

Como podemos ver, tenemos un poco menos de 8g de memoria libre en nuestro servidor, pero no podemos levantar una instancia con una configuracion de 2g memoria. Lo primero que tenemos que hacer es detectar el id al proyecto que el usuario oracle pertenece


root $ id -p
uid=1001(oracle) gid=110(dba) projid=100(user.oracle)

Una vez que logramos identificar el proyecto al que pertenece nuestro usuario, vamos a verificar los recursos que esta utilizando


root $ prstat -J
.
.
.
PROJID NPROC SWAP RSS MEMORY TIME CPU PROJECT
100 251 14G 13G 42% 37:45:26 0.1% user.oracle

Como podemos ver arriba, el usuario oracle esta usando 13g de la memoria del servidor, ahora vamos a verificar cuanto tiene asignado el proyecto


root $ prctl -n project.max-shm-memory -i project 100
project: 100: user.oracle
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 14.0GB - deny -
system 16.0EB max deny -

Ahora que verificamos que el proyecto al que esta asignado nuestro usuario esta restringido hasta los 14g, vamos a incrementarlo para poder levantar la instancia


root $ prctl -n project.max-shm-memory -r -v 16G -i project 100

Volevemos a checar la memoria asignada a nuestro proyecto, y ahora vemos que tenemos un maximo de 16g


root $ prctl -n project.max-shm-memory -i project 100

project: 100: user.oracle
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 16.0GB - deny -
system 16.0EB max deny -

Y ahora ya podemos levantar la instancia


DBATEST >startup
ORACLE instance started.

Total System Global Area 2088402944 bytes
Fixed Size 2159904 bytes
Variable Size 1375734496 bytes
Database Buffers 570425344 bytes
Redo Buffers 140083200 bytes

Conclusion
Espero que esta entrada te ayude a comprender el resource manager de Solaris y que te ayude cuando te enfrentes a este tipo de situaciones.

Conectarse a la Base de datos cuando cualquier otro metodo no lo permite

Conectarse a la Base de datos cuando cualquier otro metodo no lo permite Te vas a topar situaciones en donde te vas a tratar de conectar a la base de datos y por cualquier metodo que intentas no vas a poder, este metodo es para ayudarte a analizar la razon por la cual no te puedes conectar, se le conoce como metodo preliminar


root $ sqlplus -prelim / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Thu May 19 22:14:53 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.

DBATEST >

o tambien de la siguiente manera


root $ sqlplus /nolog
SQL*Plus: Release 11.2.0.2.0 Production on Thu May 19 22:17:50 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.

>set _prelim on
>connect / as sysdba
Prelim connection established
DBATEST >

Una vez que te hayas conectado, vamos a hacer un trace para que te ayude a diagnosticar el problema.


DBATEST >oradebug hanganalyze 3
Statement processed.

DBATEST >oradebug setmypid
Statement processed.

DBATEST >oradebug dump systemstate 10
Statement processed.

Como podemos ver en el log, se genero el siguiente archivo trace


Thu May 19 22:19:46 2011
System State dumped to trace file /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_5145.trc

Conclusion 
Espero que esta pequeña entrada te ayude cuando te enfrentes a esta situacion.

miércoles, 4 de mayo de 2011

Falla al coleccionar estadisticas para un esquema ( ORA-20000 y ORA-06512 Statistics collection failed for all objects in schema )

Aqui de regreso con un post mas, estos ultimos dos meses he estado algo ocupado por eso no he podido mantener el paso de 1 post por semana, pero aqui tengo uno que si se lo topan les puede ayudar en un futuro o un problema actual.

Tengo un proceso personalizado que corre diario buscando objetos que no tienen estadisticas, este proceso llevaba corriendo mas de un año sin ningun problema, y hace unos pocos dias empezo a fallar y ahora si que me agarro por sorpresa este error, pero pudimos arreglarlo despues de investigar un rato.

Lo que sucedio fue que dias atras se corrio un proceso con Datapump, si no conoces esta herramienta de Oracle, es usada para exportar/importar informacion; Este proceso fallo y algunas veces cuando eso sucede, deja una tabla externa, que eso era lo que estaba causando que fallara la coleccion de estadisticas para mi base de datos.

Para poder encontrar y solucionar el error hicimos lo siguiente:
Alteramos nuestra sesion para generar trace del error que estaba marcando, una vez que alteramos la sesion, corremos la generacion de estadisticas.

DBATEST >alter session set events '6512 trace name errorstack level 3';

Session altered.

DBATEST >begin
2 dbms_stats.gather_schema_stats( ownname => 'HR',
3 estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
4 degree => 8,cascade => TRUE,
5 options => 'GATHER EMPTY',
6 method_opt => 'FOR ALL COLUMNS SIZE AUTO' );
7 end;
8 /
*
ERROR at line 1:
ORA-20000: Statistics collection failed for all objects in schema
ORA-06512: at "SYS.DBMS_STATS", line 24189
ORA-06512: at "SYS.DBMS_STATS", line 24130
ORA-06512: at line 2

Como podemos ver en el trace, aqui es donde nos esta diciendo que la tabla externa es la causante de nuestro problema

----- Error Stack Dump -----
ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
KUP-11024: This external table can only be accessed from within a Data Pump job.
ORA-06512: at "SYS.DBMS_STATS", line 20184

Siguiendo la nota de MOS 336014.1, pudimos limpiar esta tabla, lo primero es ver si el proceso de Datapump no esta realmente corriendo:

DBATEST >SET lines 200
DBATEST >COL owner_name FORMAT a10;
DBATEST >COL job_name FORMAT a20
DBATEST >COL state FORMAT a11
DBATEST >COL operation LIKE state
DBATEST >COL job_mode LIKE state

-- localizar jobs de Data Pump :

DBATEST >SELECT owner_name, job_name, operation, job_mode,
2 state, attached_sessions
3 FROM dba_datapump_jobs
4 WHERE job_name NOT LIKE 'BIN$%'
5 ORDER BY 1,2;

OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE ATTACHED_SESSIONS
---------- -------------------- ----------- ----------- ----------- -----------------
HR SYS_IMPORT_FULL_01 IMPORT FULL NOT RUNNING 0

Despues pasamos a encontrar la tabla maestra de datapump
DBATEST >SELECT o.status, o.object_id, o.object_type,o.owner||'.'||object_name "OWNER.OBJECT"
2 FROM dba_objects o, dba_datapump_jobs j
3 WHERE o.owner=j.owner_name AND o.object_name=j.job_name
4 AND j.job_name NOT LIKE 'BIN$%' ORDER BY 4,2;


STATUS OBJECT_ID OBJECT_TYPE
--------------------- ----------
OWNER.OBJECT
-------------
VALID 44461 TABLE
HR.SYS_IMPORT_FULL_01

Una vez que localizamos la tabla maestra del job, tiramos la tabla, si llegaras a encontrar mas de una tabla, antes de tirarla, cerciorate que estas sean de un proceso de Datapump fallido.

DBATEST >drop table HR.SYS_IMPORT_FULL_01;

Table dropped.

Ahora pasamos a encontrar la tabla externa y de la misma manera tirarla.

DBATEST >set linesize 200 trimspool on
DBATEST >set pagesize 2000
DBATEST >col owner form a30
DBATEST >col created form a25
DBATEST >col last_ddl_time form a25
DBATEST >col object_name form a30
DBATEST >col object_type form a25
DBATEST >
DBATEST >select OWNER,OBJECT_NAME,OBJECT_TYPE, status,
2 to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created
3 ,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time
4 from dba_objects
5 where object_name like 'ET$%'
6 /

OWNER OBJECT_NAME OBJECT_TYPE STATUS CREATED LAST_DDL_TIME
------------------------------ ------------------------------ ------------------------- --------------------- -------------------------
HR ET$01A305940001 TABLE VALID 27-apr-2011 13:32:45 28-apr-2010 08:15:28

DBATEST >select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE
2 from dba_external_tables
3 order by 1,2
4 /

OWNER TABLE_NAME DEFAULT_DIRECTORY_NAME ACCESS_TYPE
------------------------------ ------------------------------ ------------------------------ ---------------------
HR ET$01A305940001 DATA_PUMP CLOB

DBATEST >spool off

DBATEST >drop table HR.&1 purge;
Enter value for 1: ET$01A305940001
old 1: drop table HR.&1 purge
new 1: drop table HR.ET$01A305940001 purge

Table dropped.

Una vez que completamos los pasos mencionados arriba, volvemos a correr las estadisticas,y vamos a ver que el proceso termina sin ningun error.

DBATEST >begin
2 dbms_stats.gather_schema_stats( ownname => 'HR',
3 estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
4 degree => 8,cascade => TRUE,
5 options => 'GATHER EMPTY',
6 method_opt => 'FOR ALL COLUMNS SIZE AUTO' );
7 end;
8 /

PL/SQL procedure successfully completed.

Conclusion
Como podemos ver, aunque es simple la solucion, poder encontrar el problema y solucionarlo nos puede llevar algo de tiempo, asi como hay que asegurarnos siempre que falle un proceso de Datapump, limpiar las tablas que genera, aunque este deberia ser algo que Oracle deberia de hacer internamente, pero al dia de hoy no lo hace, asi que con cuidado y espero que te sirva esta entrada.