jueves, 15 de septiembre de 2011

Datapump y el error ORA-06502

El otro dia tuvimos un requerimiento de exportar mas de 2000 tablas con un opcion de QUERY. Una vez que construimos nuestro archivo de parametros que contenia mas de 4000 caracteres y lo lanzamos y nos aparece el siguiente error

 ORA-06502 PL/SQL: numeric or value error: character string buffer too small

Lo que sucedio fue que Oracle tiene un bug interno, que por lo visto en 11.2.0.2 todavia no esta resuelto, en donde un buffer interno es excedido por los parametros INCLUDE or TABLES, falla con el error mencionado arriba. Lo que hicimos para corregir este error fue lo siguiente 1.- Creamos una tabla que tenga tres columnas, owner,object_name y object_type, y una vez creada, insertamos los valores de las tablas que queremos exportar.


DBATEST >CREATE TABLE expdp_tab (owner VARCHAR2(30), object_name VARCHAR2(128), object_type VARCHAR2(19));

Table created.

DBATEST >INSERT INTO expdp_tab VALUES ('HR','TEST_TABLE_1','TABLE');

1 row created.

DBATEST >INSERT INTO expdp_tab VALUES ('HR','TEST_TABLE_2','TABLE');

1 row created.

.
.
.

DBATEST >INSERT INTO expdp_tab VALUES ('HR','TEST_TABLE_N','TABLE');

1 row created.

DBATEST >commit;

Commit complete.

2.-Ya que finalizamos de insertar las tablas que queremos exportar a la tabla expdp_tab, vamos a crear un archivo de parametros para el export de datapump.


DIRECTORY=DATA_PUMP_DIR  
SCHEMAS=SYSADM
DUMPFILE=DUMP_FILE_NAME.dmp 
CONTENT=DATA_ONLY 
QUERY= "WHERE LOCATION='TEST'"
INCLUDE=TABLE:"IN (SELECT object_name FROM expdp_tab where owner='HR')"

3.-Correr el job de datapump expdp hr/hr_pass@DBATEST parfile=parameter_file_name.par


;;; 
Export: Release 11.2.0.2.0 - Production on Wed Sep 14 20:45:40 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
;;; 
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the OLAP, Data Mining and Real Application Testing options
Starting "HR"."SYS_EXPORT_SCHEMA_01":  HR/******** parfile=parameter_file_name.par 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 230.1 MB
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/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "HR"."TEST_TABLE"                13.59 MB   64509 rows
.
.
. . exported "HR"."TEST_TABLE_N"                    10.96 KB      20 rows
Master table "SYSADM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSADM.SYS_EXPORT_SCHEMA_01 is:
  /mount/export01/DBATEST/DUMP_FILE_NAME.dmp
Job "SYSADM"."SYS_EXPORT_SCHEMA_01" successfully completed at 21:15:13

4.-Una vez finalizado el export, tiramos la tabla que creamos al principio

DBATEST >drop table expdp_tab;

Table dropped.

Conclusion
Aunque Oracle en MOS indica que este bug interno ya se encuentra arreglado, nosotros no lo topamos en la version 11.2.0.2.3, asi que si te lo llegas a topar, aqui esta la manera de como trabajar alrededor de el.

domingo, 28 de agosto de 2011

Como vincular los binarios de Oracle

En este cuarto de año, mi equipo y yo estamos aplicando una seria de parches y el PSU de Julio 2011 a nuestras bases de datos, decidimos que para reducir el tiempo de baja de las Bases de Datos, vamos a construir un nuevo ORACLE_HOME con estos parches y PSU, y solamente bajar la instancia,cambiar la variable de ambiente ORACLE_HOME a la nueva y empezar la instancia.

En este metodo, lo que hicimos fue construir un solo ORACLE_HOME y clonarlo a los demas servidores, pero en este proceso nos dimos cuenta que nuestra copia "base", habia sido borrado el archivo $ORACLE_HOME/network/admin/shrept.lst. Esto causaba que la clonacion a la hora de vincular los binarios de Oracle con el sistema operativo fallaba con el siguiente error:

INFO: Calling Action unixActions10.2.0.3.0 make
registerOnly = false
installMakePath = /usr/ccs/bin/make
installMakeFileName = /mount/oracle/product/11.2.0.2v2/rdbms/lib/ins_rdbms.mk
installTarget = client_sharedlib
undoMakeFileName =
installArguments = ORACLE_HOME=/mount/oracle/product/11.2.0.2v2
logFile = /mount/oracle/product/11.2.0.2v2/install/make.log
undoTarget =
progMsg = Building Client Shared Libraries

INFO: The output of this make operation is also available at: '/mount/oracle/product/11.2.0.2v2/install/make.log'
INFO:

INFO: Start output from spawned process:
INFO: ----------------------------------
INFO:

INFO: /mount/oracle/product/11.2.0.2v2/bin/genclntsh

INFO: genclntsh: Could not locate /mount/oracle/product/11.2.0.2v2/network/admin/shrept.lst
genclntsh: exiting ...

INFO: make: Fatal error: Command failed for target `client_sharedlib'

INFO: *** Error code 1

Para poder entender lo que hicimos para solucionar este problema, hay que entender que en cualquier distribucion de un sistema operativo basado en Unix, el software de Oracle viene como archivos tipo objeto (object files) o como archivos tipo fuente (source files), estos al ser instalados en Unix se vinculan con las librerias del sistema operativo para generar el ejecutable de oracle.

Lo primero que tuvimos que hacer es recrear el archivo, ya sea de otra instalacion de 11.2.0.2 que tuviera el archivo o lo puedes extraer del cd de instalacion (Metalink id 340978.1), en este caso el contenido de nuestro archivo, es como se menciona abajo:

oracle@localhost [DBATEST] /mount/oracle/product/11.2.0.2v2/network/admin
root $ cat shrept.lst
# function entry points for genclntsh.sh

network : snaumihi_inithostinfo
network : snaumbg_gmt
network : naedpwd_encrypt
network : naumbsb_bld_singlebyte
network : ztapis
network : nlgh

Una vez que reconstruimos el archivo con el usuario oracle y permisos 644, bajamos todas las instancias y listeners que estuvieran corriendo en el ORACLE_HOME donde fallo la instalacion, y utilizamos el comando $ORACLE_HOME/bin/relink all

oracle@localhost [DBATEST] /mount/oracle/product/11.2.0.2v2/bin
root $ ./relink all
writing relink log to: /mount/oracle/product/11.2.0.2v2/install/relink.log

Este comando no te regresa un mensaje de exito, es mas bien si ocurre un error durante esta fase te muestra el mensaje de falla, como por ejemplo

'Fatal error', 'Ld: fatal', 'Exit Code 1'

Si te llega a suceder un error, lo mas recomendable es buscar en metalink, si hay otro suceso de este error o abrir un SR con oracle para resolverlo.

Conclusion
El comando de relink all es una herramienta muy util, sobre todo cuando por alguna razon los vinculos se perdieron entre Oracle y las librerias del sistema operativo.

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.

domingo, 10 de abril de 2011

Un commit hace que mi informacion se escriba en los datafiles?

El otro día recibí la pregunta que si en el momento que hago commit, los datos los encuentro en los datafiles?

Para poder entender esta pregunta, primero debemos conocer un poco los procesos y las estructuras de memoria que tiene Oracle, te invito a que vayas a la entrada Instancia es igual a procesos y memoria para que tengas una mejor idea de varios de los procesos que vamos a hablar aqui.

Lo primero que hay que entender es que el DBWn es un proceso flojo,ya que no es un proceso que cada n segundos este escribiendo los datos del Buffer Cache a los datafiles, si no que es activado por otro proceso (Como CKPT por ejemplo).

Tomemos el siguiente ejemplo,supon que yo siendo el todopoderoso, incremento mi salario de 1 USD a 5 USD en la tabla employees, e inmediatamente despues hago un commit.

Pregunta, si yo ya hice un commit, encontraría el valor de 5 USD en los datafiles?

Antes de responder esta pregunta, vamos a poner otra situación con el mismo ejemplo, en lugar de cometer mis datos después del incremento salarial que me di,decido esperarme el fin de semana para reflexionar en este cambio, solamente dejo la sesión abierta sin cometer los datos.
El lunes que regreso, y verifico los datos directamente en los datafiles, que valor encontraría, 1 o 5 USD?

La lógica me llevaría a decir que, 1 USD, ya que nunca cometí mis datos, cierto?

Una ultima pregunta con este escenario,acuerdate que no hemos cometido los datos,si yo checara los datos en el Online Redo Log, que valor encontraria, 1 o 5 USD?

Si tu respuesta fue 1 USD, seria la mas lógica, ya que no he cometido los datos y no son necesarios para el proceso de recuperación en caso de que mi base de datos se cayera, si respondiste 5 USD, entonces como explicarías el proceso de recuperación en caso de que se haya caído la instancia, si cuando se hace una recuperación los procesos leen del Online Redo Log, y el valor que se encuentra es el de 5 USD?

Antes de empezar, y para que no se te quemen las habas,las respuestas son 1,5 y 5 USD

Vamos a tratar de explicarlo aquí abajo

Crea un tablespace pequeño, en este casa de 1M, y crea en el usuario hr, una tabla llamada prueba_salario, y en esta tabla inserta el dato de salario


TESTDB >create tablespace prueba datafile '/mount/u01/oracle/TESTDB/data/pruebas01.dbf' size 1m;

Tablespace created.

TESTDB >create table hr.prueba_salario (salario varchar2(200)) tablespace prueba;

Table created.

TESTDB >insert into hr.prueba_salario values ('1_USD');

1 row created.

TESTDB >commit;

Commit complete.

Una vez que completes esto, recicla la base de datos, ya que no queremos que nada se encuentre en memoria, y si te fijas, el dato de 1_USD lo puedes ver
en el datafile

oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data
root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf

z{|}
5wXTESTDB
PRUEBA
1_USD

Y ahora haz un update a la tabla hr.prueba_salario y realiza un commit, inmediatamente después verifica de nuevo el datafile, y te vas a dar cuenta
que este dato que acabas de actualizar no se encuentra en el datafile, que sigues viendo el valor de 1_USD

TESTDB >update hr.prueba_salario set salario = '5_USD';

1 row updated.

TESTDB >commit;

Commit complete.

oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data
root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf

z{|}
5wXTESTDB
PRUEBA
1_USD

En el momento que mandamos llamar al proceso de CKPT, es cuando los buffers "sucios" se escriben a disco, despues de que hagas un checkpoint,
verifica de nuevo el datafile, y te vas a dar cuenta que el datafile esta actualizado con el nuevo valor de 5_USD.


TESTDB >alter system checkpoint;

System altered.

oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data
root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf

z{|}
5wXTESTDB
PRUEBA
5_USD

Ahora vamos a hacer otra prueba, tira la tabla prueba_salario, vuelvela a crear, vuelve a insertar el dato de 1_USD y una vez que finalices esto, recicla la base de datos para asegurarnos que no se encuentre nada en memoria.

Ahora vamos a hacer un update a la tabla de prueba salario, y no vamos a hacer un commit, solamente vamos a llamar al proceso de CKPT.

TESTDB >update hr.prueba_salario set salario = '5_USD';

1 row updated.

TESTDB >alter system checkpoint;

System altered.

Si te fijas abajo, el dato de 5_USD es el que se encuentra en el datafile y no el de 1_USD, aunque no hemos hecho un commit de los datos.


oracle@localhost [TESTDB] /mount/u01/oracle/TESTDB/data
root $ strings /mount/u01/oracle/TESTDB/data/pruebas01.dbf

z{|}
5wXTESTDB
PRUEBA
5_USD

Abre una nueva sesión y haz un query a la tabla y te fijaras que el dato de 1_USD es el que te arroja, que es el correcto ya que no hemos cometido los datos


TESTDB >select * from hr.prueba_salario;

SALARIO

------------------------

1_USD

Una de las preguntas que te has de estar haciendo en este momento, es como Oracle sabe que información arrojar, si en el datafile se encuentra el valor de 5_USD. Oracle logra esto a través de un flujo que se llama Consistencia de Lectura (Read Consistency [RC]).

Antes de continuar hay que conocer que es el SCN (System Change Number), este es el punto logico
en el tiempo en el que los cambios se hacen a la base de datos.

El flujo de RC funciona con el SCN para garantizar el orden de las transacciones, cuando lanzaste el query en la sesión nueva, la base de datos determina el SCN registrado en el momento que el query se empezó a ejecutar.

Este select requiere una versión de los bloques de datos que sean consistentes con los cambios que únicamente se encuentran cometidos. Oracle copia los bloques que se encuentran en los bloques actuales a un buffer de datos nuevo y le aplica datos de undo para reconstruir las versiones anteriores de los bloques de datos. A estas copias se le conocen como clones de consistencia de lectura(Consistency Read Clones).

Para saber si la transaccion esta cometida o no, Oracle utiliza una tabla de transacciones llamada lista de transacciones de interes (Interested Transaction List [ITL]), esta lista se encuentra en la cabecera del bloque.

Para terminar y regresar al punto, si sabemos que el DBWn es un proceso flojo, y que aunque haga un commit de mis datos, estos pueden que no se encuentren en los datafiles.

¿De donde toma Oracle la información para esto si se me llegara a caer la base de datos antes de que el CKPT mandara a llamar al DBWn?

La respuesta esta en el Online Redo Log y cuando encuentra el marcador de commit, como ya habíamos platicado de lo que es el Online Redo Log, no voy a entrar mas a detalle en este tema, pero como puedes ver por los ejemplos anteriores, el Online Redo Log, es critico para la consistencia de nuestros
datos.

Conclusion

Espero que con esta explicación puedas comprender la importancia de los Online Redo Logs, ya que si los llegaras a perder, puedes tener perdida de información en tu base de datos, también vimos un poco de como funciona el undo y como se logra la consistencia de lectura a través de sesiones sin cometer.

P.D. Quiero Agradecer a Arup Nanda por permitirme utilizar gran parte de su material para esta entrada, 100 Things You Probably Didn't Know.

Actualización

04/Dec/2012: No me habia fijado que el formato de SQL de esta entrada se habia perdido, asi que se lo volvi a poner.

jueves, 31 de marzo de 2011

Instancia es igual a Procesos y Estructuras de memoria

La definicion de una instancia es sencilla y basica, es un conjunto de estructuras de memoria que manejan los archivos de la base de datos, cuando inicia la instancia, con ella inician procesos de fondo (Background Process), como el LGWR, PMON, etc.

Importante saber que al menos una base de datos activa o mejor dicho que esta corriendo, debe de tener una instancia asociada. De la misma manera, como la instancia existe en memoria y la base de datos existe en disco, una instancia puede existir sin una base de datos y una base de datos puede existir sin una instancia, si no me crees esto, haz la prueba, arranca la instancia en modo nomount y veras que sin existir los datafiles,controlfiles y redo logs puedes iniciar la instancia


TESTDB >startup nomount

ORACLE instance started.
Total System Global Area 1369989120 bytes
Fixed Size 2158184 bytes
Variable Size 268439960 bytes
Database Buffers 1090519040 bytes
Redo Buffers 8871936 bytes

oracle@localhost [TESTDB] /mount/dba01/oracle/TESTDB/admin
oracle $ ps -eaf | grep TESTDB

oracle 27411 1 0 01:21:35 ? 0:00 ora_pmon_TESTDB

oracle 27448 1 0 01:21:37 ? 0:00 ora_ckpt_TESTDB

oracle 27435 1 0 01:21:37 ? 0:00 ora_dia0_TESTDB

oracle 27439 1 0 01:21:37 ? 0:00 ora_dbw0_TESTDB

oracle 27454 1 0 01:21:37 ? 0:00 ora_mmon_TESTDB

oracle 27415 1 0 01:21:35 ? 0:00 ora_psp0_TESTDB

oracle 27444 1 0 01:21:37 ? 0:00 ora_dbw1_TESTDB

oracle 27431 1 0 01:21:37 ? 0:00 ora_diag_TESTDB

oracle 27446 1 0 01:21:37 ? 0:00 ora_lgwr_TESTDB

oracle 27452 1 0 01:21:37 ? 0:00 ora_reco_TESTDB

oracle 27450 1 0 01:21:37 ? 0:00 ora_smon_TESTDB

Aqui abajo esta una pequeña grafica de como se conforma una instancia:


Y debido a lo que platicamos arriba, es lo que permite la configuracion para RAC (Real Application Cluster), asi tambien es importante saber que una instancia no puede tener asociada una sola base de datos a la vez, o sea que no puedes montar dos base de datos en una instancia.

Memoria
La memoria SGA tiene 3 estructuras básicas:

Database buffer cache.- Es el área de memoria que almacena copias de los bloques de datos leídos de los data files.Tambien a esta área se le conoce nada mas como Buffer Cache. Esta seccion de la memoria tiene tres estados.
  • Sin Usar (Unused).-El buffer esta disponible por que nunca se ha usado o actualmente esta sin usar.
  • Limpia (Clean).-Este buffer fue usado previamente, y ahora contiene una version consistente del bloque de datos en un punto en tiempo. El bloque contiene datos, pero este se puede decir que esta limpio, ya que no se le necesita hacer un checkpoint a los datos.
  • Sucia (Dirty).-El buffer contiene datos que no han sido escrito a disco, Oracle necesita hacer un checkpoint del bloque de datos antes de reusarlo.
  • Para manejar estos estados, Oracle tiene un algortimo llamado LRU (Least Recently Used), lo que hace este algoritmo es sacar del buffer a los bloques de datos menos usados y que ya se le hayan hecho un checkpoint para asi poder subir al Buffer Cache nuevos datos y evitar sacar del Buffer Cache los datos que se usan con frecuencia.

Shared Pool .- Esta área de memoria guarda SQL analizado (Parsed),parámetros del sistema y el diccionario de datos (Data Dictionary Cache y Library Cache).

Redo Log Buffer.- Esta estructura de memoria en el SGA, que guarda los registros de Redo, estos contienen la información necesaria para reconstruir los cambios hechos por DDLs o DMLs a la base de datos.

Procesos
Existen varios que son obligatorios, como los mencionados aqui abajo, de la misma manera existen muchos procesos que se inician una vez que añades alguna funcionalidad, como el ARCn, que es cuando la base de datos esta en modo archivelog.

PMON.- La funcionalidad de este proceso es la de monitorear que los demás procesos de la instancia estén corriendo, a su vez es responsable de limpiar el Database Buffer Cache y limpiar recursos que el cliente haya utilizado.

SMON.-La tarea principal de este proceso es la de limpieza a nivel sistema, y también una de las tareas principales de este proceso es llevar a cabo la recuperación al iniciar la instancia cuando anteriormente finzalizo de una manera abrupta, como un shutdown abort o un crash del servidor.

CKPT.-Su función es la de actualizar las cabeceras de los control files y de los data files, con información de Checkpoint (SCN, Posición de Checkpoint, etc), a su vez la avisa al DBWn que debe de escribir los bloques del Buffer Cache a disco. Muy importante saber, que el CKPT no escribe los datos, ni al Redo Log ni a los data files.

DBWn.-Este proceso escribe los contenidos sucios del buffer Cache, a este proceso se le conoce como un proceso flojo, ya que por si solo no escribe a disco, este unicamente escribe a disco cuando no hay bloques de datos limpios en el buffer cache o cuando CKPT le informa que debe hacerlo.

LGWR.- De lo que se encarga es de escribir los Redo Log Buffers a disco (Online Redo Log). Este proceso utiliza un método que se le conoce como Fast Commit. Cuando un usuario ejecuta un commit, a la transacción se le asigna un SCN (System Change Number), LGWR pone una marca de commit en el Buffer Cache e inmediatamente escribe a disco, cuando se han escrito estos datos en el Online Redo Log, el proceso actualiza el Buffer Cache haciendo mención de que estos ya se escribieron a disco.

Conclusion
Espero que esta pequeña explicación te ayude a comprender la diferencia entre la Instancia y lo que en Oracle se conoce como Base de Datos. De la misma manera los procesos basicos y memoria basica de la instancia, para los procesos y la memoria existen mas de los mencionados aqui, pero estos son los minimos necesarios en una configuracion de Oracle.