INSTANCIA DE LA BASE DE DATOS

[hacer figuras en la pizarra y que le hagan fotos para incluirlas]

Una base de datos Oracle se divide en dos partes fundamentales: la instancia y la base de datos
propiamente dicha. Esta ltima parte se compone de un conjunto de ficheros que veremos ms
adelante.
La instancia de una base de datos est formada por las estructuras de memoria principal (SGA,
System Global Area) y por los procesos de respaldo que estudiaremos en detalle en otros temas.
Ahora vamos a ver cmo interactuar con la instancia estudiando aspectos como la configuracin, el
arranque o la parada de la misma. La instancia est formada por estructuras de memoria y procesos,
por por est se puede arrancar y parar.

4.1 CONFIGURACIONES DE LA INSTANCIA

Es posible configurar Oracle en una de las dos siguientes modalidades, mutuamente exclusivas, con
una o con varias instancias. Independientemente de la configuracin, una instancia de base de datos
est asociada con una nica base de datos en un momento dado. No es posible montar dos bases de
datos simultneamente con la misma instancia, aunque una base de datos puede estar asociada a una
o ms instancias simultneamente (Oracle RAC).

4.1.1 Identificador del sistema

El identificador del sistema (SID, System Identifier) es un nombre nico que caracteriza a una
instancia de Oracle en un host concreto. Cuando los clientes se conectan a una instancia, especfican
el SID en Oracle Net Connection o utilizan un servicio de red. Oracle convierte el nombre del
servicio en ORACLE_HOME y ORACLE_SID.
La variable ORACLE_HOME es: ORACLE_HOME=$ORACLE_BASE/product/10.2.0/server
ORACLE_BASE se establece en el fichero de arranque, por ejemplo intXE.ora o spfilexe.ora de
K:\oraclexe\app\oracle\product\11.2.0\server\dbs en nuestra instalacin, donde XE es el SID.
xe.__oracle_base='K:\oraclexe\app\oracle' #ORACLE_BASE set from
environment

Se puede ver con SQL*Plus:

SQL> set autopri on
SQL> var oracle_home varchar2(255)
SQL> exec dbms_system.get_env('ORACLE_HOME', :ORACLE_HOME)
PL/SQL procedure successfully completed.
ORACLE_HOME
-----------------------------------------------K:\oraclexe\app\oracle\product\11.2.0\server

En algn sitio del registro de windows aparece tambin este directorio:

Al instalar informa de:

Destination Folder: K:\oracle11xe\
Oracle Home: K:\oracle11xe\app\oracle\product\11.2.0\server\
Oracle Base:K:\oracle11xe\
Port for 'Oracle Database Listener': 1521
Port for 'Oracle Services for Microsoft Transaction Server': 2030
Port for 'Oracle HTTP Listener': 8080

4.1.2 Parmetros de inicializacin

Oracle proporciona gran cantidad de parmetros de inicializacin para optimizar su funcionamiento
en varios entornos. Solo algunos de estos parmetros deben ser configurados explcitamente,
porque los valores por defecto son adecuados para la mayora de los casos. Todos los parmetros
tienen un valor por defecto, excepto el DB_NAME.
Los ficheros de parmetros, que se leen durante el arranque de la instancia, contienen los parmetros
de inicializacin.
Oracle llg divide los parmetros en bsicos y avanzados y recomienda configurar de manera
explcita nicamente los parmetros bsicos. El valor actual de los parmetros bsicos (aquellos que
deben tenerse en cuenta en toda base de datos) puede averiguarse consultando la vista
V$PARAMETER de la siguiente forma:
SELECT * FROM V$PARAMETER WHERE isbasic = 'TRUE';
Existen varias opciones a la hora de cambiar los valores de los parmetros de inicializacin, que
son:
Si se utiliza un fichero de parmetros (PFILE), con un editor de texto bastar.
Si se utiliza un fichero de parmetros en el servidor (SPFILE), los cambios se introducen con la
sentencia ALTER SYSTEM.
A travs de la consola grfica del DBCA (Data Base Control Assistant) del Enterprise Manager.

4.1.3 Ficheros de parmetros (PFILE)

Como hemos dicho en nuestra instalacin est en:
K:\oraclexe\app\oracle\product\11.2.0\server\dbs
Un fichero de parmetros es un fichero de texto que contiene una lista de parmetros de
inicializacin. Este tipo de ficheros de parmetros es una implementacin tradicional que se
caracteriza por:
Al arrancar o parar la base de datos, el fichero de parmetros debe residir en la misma mquina que
la aplicacin cliente que se conecta a la base de datos.
Se trata de ficheros de texto, no de ficheros binarios.
Oracle lee el fichero pero no puede escribir en l. Los cambios en los parmetros deben hacerse de
manera manual con un editor de textos.
Los cambios realizados en los parmetros de inicializacin utilizando ALTER SYSTEM solo
afectan a la instancia actual. Deben incluirse manuahnente en el fichero de parmetros si se quiere
que la prxima vez que arranque la instancia tome el nuevo valor.
4.1.4 Ficheros de parmetros en el servidor (SPFILE)
Un fichero de parmetros en el servidor es un repositorio de parmetros de inicializacin que es
gestionado por Oracle. Un fichero de parmetros en el servidor tiene las siguientes caractersticas:
Solo puede existir uno en una base de datos dada. Este fichero debe residir en el equipo que tiene
instalada la base de datos.
Est escrito para ser ledo y escrito por Oracle, no por usuarios humanos.
Es un fichero binario que no puede modificarse desde un editor de texto.
Los parmetros de inicializacin se guardan dc manera persistente.
Un fichero de parmetros en el servidor elimina la necesidad de mantener varios ficheros de
parmetros de texto para las aplicaciones clientes. Un fichero de parmetros en el servidor se
construye inicialmente a partir de un fichero de texto con CREATE SPFILE o con el DBCA:
CREATE SPFILE [='spfilename'] FROM PFILE [='pfilename']

4.1.5 Modificacin de los parmetros de inicializacin

Es posible ajustar los parmetros de inicializacin para modificar el comportamiento de la base de
datos. La clasificacin de los parmetros como estticos o dinmicos permite determinar cmo
pueden modificarse. La tabla resume las diferencias:

Caracterstica

Esttico

Dinmico

Necesita modificar el fichero de parmetros (texto o servidor)

No

Necesita reiniciar la instancia de la base de datos antes de que los

cambios surtan efecto

Si

No

Descrito como 'Modificable' en la entrada del parmetro de

inicializacin de la base de datos Oracle de referencia (Oracle
Database Reference)

No

Modificable solo por la base de datos o la instancia

No

Los parmetros dinmicos se agrupan en parmetros a nivel de sesin y parmetros a nivel de

sistema. El mbito del cambio del parmetro depende de cundo el cambio tenga efecto. Con la
sentencia ALTER SESSION SET se modifica el valor del parmetro, pero dicho cambio afecta
nicamente a la sesin actual:
ALTER SESSION SET NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS';
Cuando una instancia se ha arrancado con un fichero de parmetros en el servidor, es posible utilizar
la sentencia ALTER SYSTEM SET para cambiar los valores del sistema de la siguiente manera:
ALTER SYSTEM SET NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS';
Adems, la sentencia ALTER SYSTEM permite definir si queremos hacer o no los cambios
permanentes a travs del modificador SCOPE:
SCOPE=MEMORY: los cambios se aplican solo a la instancia de la base de datos. No persistir si
la base de datos se para y se vuelve a arrancar.
SCOPE=SPFILE: los cambios se escriben en el fichero de parmetros del servidor pero no afectan
a la instancia actual. Por tanto, el cambio no tendr efecto hasta que no se reinicie la instancia.
SCOPE=BOTH: los cambios se escriben tanto en memoria como en el fichero de parmetros. Es el
mbito por defecto cuando la base de datos utiliza un fichero de parmetros en el servidor.
As pues, la siguiente consulta modificara el parmetro NLS_DATE_FORMAT de la sesin actual
y no del SPFILE:
ALTER SYSTEM SET NLS_DATE_FORMAT='DD/MM/YYYY HH24:M:SS' SCOPE=MEMORY ;

Ejemplo:
SQL> show parameter nls_date_format
NAME
TYPE
VALUE
------------------------------------ ----------- ------------------nls_date_format
string DD/MM/RR
SQL> alter system set nls_date_format='DD-MM-YYYY' scope=SPFILE;
System altered.
Y podemos ver la entrada que oracle ha insertado en el fichero:
K:\oraclexe\app\oracle\product\11.2.0\server\dbs\spfilexe.ora que aunque binario se puede ver con el
editor de texto:
*.job_queue_processes=4
*.memory_target=1024M
*.nls_date_format='DD-MM-YYYY'
*.open_cursors=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=20
*.shared_servers=
SQL> alter system set nls_date_format='DD/MM/RR HH24:M:SS' scope=SPFILE;
System altered.

*.job_queue_processes=4
*.memory_target=1024M
*.nls_date_format='DD/MM/RR HH24:M:SS'
*.open_cursors=300
*.remote_login_passwordfile='EXCLUSIVE'

Por tanto, puede ocurrir que el valor de algn parmetro sea distinto en el SPFILE y en la sesin
actual. Para saber cules estn en esta situacin es posible lanzar la siguiente consulta:
SELECT *
FROM V$SPPARAMETER S JOIN V$PARAMETER p ON s.name=p.name
WHERE p.isbasic='TRUE';
La vista V$SPPARAMETER muestra los contenidos del fichero SPFILE de arranque de la
instancia. Su columna ISSYS_MODIFIABLE indica si el parmetro puede cambiarse
dinmicamente con ALTER SYSTEM o no. El valor DEFERRED significa que el cambio no tendr
efecto hasta que no se inicie una nueva sesin. Por otra parte, el valor IMMEDIATE indica que el
cambio afectar, de manera inmediata, a todas las sesiones abiertas.

4.2 ARRANQUE Y PARADA DE LA INSTANCIA

Para arrancar y parar una instancia de Oracle es necesario conectarse con losprivilegios adecuados.
Por defecto existen dos cuentas de usuario autorizadas para ello: SYSDBA, con permiso para
realizar cualquier operacin sobre la base de datos; y SYSOPER, capaz de arrancar y parar la
instancia, pero con menos privilegios administrativos. Auntenticarse con uno de estos dos usuarios
solo es posible a travs del sistema operativo o con un fichero de contraseas.
4.2.1 Arranque de la instancia
Cuando Oracle arranca, se inicializan las estructuras de memoria y los procesos de respaldo con el
fin de que los usuarios finales puedan conectarse a la base de datos Oracle. Partiendo del estado
SHUTDOWN, durante el arranque atraviesa tres estados (NOMOUNT, MOUNT y OPEN) que
garantizan el arranque consistente de la base de datos. En el caso tpico, la instancia se arranca,
monta y abre la base de datos manualmente, dejndola disponible para las aplicaciones de usuario.

As pues, una base de datos atraviesa las siguientes etapas desde que est parada hasta que se abre:
Inicializacin de la instancia (NOMOUNT): se arranca la instancia sin montar la base de datos.
Montado de la instancia (MOUNT): una vez arrancada la instancia, se le asocia una base de datos
leyendo el fichero de control.
Arranque de la instancia (OPEN): se abre la base de datos y los ficheros de datos son accesibles a
los usuarios autorizados.
El arranque de la instancia puede realizarse de forma manual mediante el comando de SQL*Plus
STARTUP, que realiza todas las etapas del proceso de arranque. Tambin es posible indicarle que
realice una nica etapa, tal y como veremos a continuacin.

Inicializacion de la instancia
Esta etapa constituye la transicin del estado SHUTDOWN al estado NOMOUNT. Puede llevarse a
cabo de forna manual ejecutando el comando STARTUP NOMOUNT.
En esta etapa se realizan los siguientes pasos bsicos:
a.- Buscar un fichero de parmetros. Oracle lanza una bsqueda jerrquica del fichero de parmetros
en unas rutas predeterminadas y en el siguiente orden:
ORACLE_HOME/dbs/spfileSID.ora
ORACLE_HOME/dbs /spfile.ora
ORAcLE_HoME/dbs/initSID.ora
Si el fichero de parmetros no se encuentra en ninguna de las ubicaciones anteriores o si se prefiere
arrancar la instancia con un fichero de parmetros diferente, es posible especificarlo en el comando
STARTUP, tal y como se muestra a continuacin:
STARTUP PFILE = /PATH/TO/INIT.ORA
b.- Leer el fichero de parmetros para deterninar los valores de los parmetros de inicializacin.
c.- Configurar y asignar la SGA dependiendo de los valores de los parmetros de inicializacin.
d.- Arrancar los procesos de respaldo de la instancia.
f.- Abrir el alert log y los ficheros de traza y escribir explcitamente los valores de los parmetros de
inicializacin.
En esta etapa, no hay ninguna base de datos asociada a la instancia, por lo que no es posible que los
usuarios regulares se conecten. Es en este estado cuando se puede crear la base de datos o el fichero
de control.
En ocasiones, la instancia no podr evolucionar al estado siguiente (MOUNT) y permanecer en
estado NOMOUNT. Esto ocurre, por ejemplo, si Oracle ha tenido problemas de acceso a los
ficheros de control, ya que estos contienen informacin crtica. Hasta que no se solucione este
problema la instancia permanecer en estado NOMOUNT.
Si el comando STARTUP NOMOUNT falla, la causa ms probable es que no se encuentra el fichero
de control o alguna limitacin del sistema operativo que evita la reserva de memoria y/o procesos.

Una forma de ver el estado de una instancia con el SQLDeveloper:

Montado de la instancia
Esta etapa constituye la transicin del estado NOMOUNT al estado MOUNT. Puede llevarse a cabo
de forma manual ejecutando el comando STARTUP MOUNT.
Para montar una base de datos, la instancia obtiene los nombres de los ficheros de control
especificados en la seccin CONTROL_FILES de los parmetros de inicializacin y los abre.
Oracle lee los ficheros de control para encontrar los nombres y ubicacin de los ficheros de datos y
de los redo logs a los que intentar acceder cuando abra la base de datos. Si todo va bien, la
instancia pasar al estado MOUNT.
En una base de datos montada, la base de datos est cerrada y es accesible nicamente a los
administradores. Los administradores pueden mantener la base de datos cerrada mientras se
terminan tareas especficas de mantenimiento como renombrar ficheros de datos o de redo log,
habilitar/deshabilitar el ARHIVELOG o recuperar la instancia. Sin embargo, la base de datos no
estar disponible para operaciones convencionales.

Ejercicio. En una sesin de SQL*Plus:

SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
629145792 bytes
Database Buffers
436207616 bytes
Redo Buffers
4591616 bytes
Database mounted.
SQL>
En otra sesin de SQL*Plus:
SQL*Plus: Release 11.2.0.2.0 Production on Jue Sep 19 17:31:04
2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL> conn usu1/usu1
Connected.
SQL> disc
Disconnected from Oracle Database 11g Express Edition Release
11.2.0.2.0 - Prod
ction
SQL> conn usu1/usu1
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Process ID: 0
Session ID: 0 Serial number: 0
SQL> conn sys/Admin2013 as sysdba
Connected.
SQL>
Apertura de la base de datos
Esta etapa constituye la transicin del estado MOUNT al estado OPEN. Puede llevarse a cabo de
forma manual ejecutando el comando STARTUP OPEN.
Abrir una base de datos la deja disponible para operaciones convencionales. Cuando se abre, Oracle
lleva a cabo las siguientes acciones:
Abrir los ficheros de datos en los espacios de tablas que no sean de undo. Si un espacio de tablas
estaba off-line cuando la base de datos se par, l y sus ficheros de datos estarn off-line cuando la
base de datos se reabra.
Adquirir un espacio de tablas de undo. Si existen varios espacios de tablas de undo, entonces el
parmetro de inicializacin UNDO_TABLESPACE determina cul utilizar. Si no est presente, se
escoger el primero que est disponible.
Abre los ficheros de redo log on-line.
Una vez realizadas estas operaciones, la instancia est en estado OPEN y la base de datos queda

disponible para todos los usuarios. Si alguno de los ficheros de datos o redo log no estuvieran
presentes cuando la instancia intenta abrir la base de datos, o si los ficheros estn presentes pero
fallan los test de consistencia, la base de datos devolver un error y puede que haya que realizar una
recuperacin de medios.
Por defecto, la base de datos se abre en modo de lectura/escritura. En este modo, los usuarios
pueden cambiar los datos, generando infonnacin de redo en los ficheros redo log on-line. No
obstante, es posible abrir la base de datos en modo de solo lectura (STARTUP OPEN READ
ONLY) para evitar que las transacciones de usuario modifiquen los datos, en cuyo caso no es
posible escribir ni en los ficheros de datos ni en los ficheros de redo log on-line. Sin embargo, la
base de datos puede llevar a cabo una recuperacin u operaciones que cambien el estado de la base
de datos sin generar redo. Por ejemplo, en modo de solo lectura:
Los ficheros de datos pueden ponerse off-line u on-line. Sin embargo, no es posible poner off-line
los espacios de tablas permanentes.
Los ficheros de datos y los espacios de tablas off-line pueden recuperarse.
El fichero de control permanece disponible para actualizaciones sobre el estado de la base de datos.
Los espacios de tablas temporales creados con CREATE TEMPORARY TABLESPACE (esta
sentencia SQL se ver ms adelante) son de lectura y escritura.
Escribe la auditoria del sistema operativo, traza los ficheros y los alert log pueden continuar.
Finalmente, es posible abrir la base de datos para lanzar la recuperacin de la instancia con
STARTUP OPEN RECOVER.
Si la base de datos ya est abierta, no es posible retomarla al estado MOUNT o NOMOUNT
utilizando el comando ALTER. SYSTEM. Es necesario pararla y arrancarla en el estado apropiado.
Otras funciones del comando STARTUP
Si no es posible arrancar la instancia de manera convencional, se puede utilizar el comando
STARTUP FORCE desde cualquier estado de la instancia y su efecto ser el de un SHUTDOWN
ABORT y un reinicio de la misma.
Por otro lado, el comando STARTUP RESTRICT arranca la instancia y abre la base de datos solo
para los usuarios con el privilegio RESTRICTED SESSION, por lo que los usuarios regulares no
podrn conectarse. Se utiliza para labores de mantenimiento. Una vez que stas han terminado, se
puede abrir la base de datos completamente con:
ALTER SYSTEM DISABLE RESTRICTED SESSION;

4.2.2 Parada de Ia instancia

Durante la parada de la instancia, sta atraviesa los mismos estados que en el arranque, pero en
orden inverso. As pues, partiendo del estado OPEN, atraviesa los estados MOUNT y NOMOUNT
para alcanzar finalmente el estado SHUTDOWN, donde la instancia se encuentra parada. La figura
muestra la progresin desde que una base est abierta hasta que se para:

Las etapas enla parada dela base de datos son las siguientes:
Cierre de la base de datos (MOUNT). La base de datos se cierra. Est montada, pero los ficheros
de datos y los redo logs on-line estn cerrados.
Desmontado de la base de datos (NOMOUNT). La base de datos se desmonta. La instancia est
arrancada, pero no est asociada a ningn fichero de control.
Parada de la base de datos (SHUTDOWN). La base de datos se para.

Una instancia Oracle pued pararse mediante el comando SQL*Plus SHUTDOWN, que en su modo
NORMAL atraviesa todas las etapas anteriores. Sin embargo, esto no ocurre as si se produce un
fallo en la instancia o si se lanza un SHUTDOWN ABORT, tal y como se explica a continuacin.
Cierre y desmontado de la base de datos
El cierre de una base de datos est implcito en la parada. La naturaleza de la operacin depende de
si la parada es normal o anormal.
Cuando una base de datos se cierra como parte de una parada normal (toda aquella que no es
iniciada por SHUTDOWN ABORT), Oracle escribe los datos de la SGA en los ficheros de datos y

en los redo logs on-line y, seguidamente, cierra estos ficheros. Todos los ficheros de los espacios de
tablas off-line han sido cerrados ya. Cuando la base de datos se reabre, cualquier espacio de tablas
que estaba off-line, pernanece off-line. En esta etapa, la base de datos est cerrada e inaccesible para
la operacin normal. Los ficheros de control permanecen abiertos despus de que la base de datos se
cierra.
Si, por el contrario, el cierre es anormal, la instancia se cierra y la base de datos se para
innediatamente. Oracle no escribe los buffers de la SGA en los ficheros de datos y los ficheros de
redo log on-line, por lo que cuando la base de datos se reabra ser necesaria la recuperacin de la
instancia, algo que Oracle har automticamente.
Una vez que la base de datos se ha cerrado, Oracle desmonta la base de datos, la disocia de la
instancia y cierra los ficheros de control. En este momento, la instancia permanece en memoria.
Parada de la base de datos
El paso final en la parada de la instancia es borrar la SGA y parar los procesos de respaldo. Es muy
poco comn que no ocurra limpiamente, y que las estructuras de memoria no se borren o algn
proceso de respaldo no se pare. Cuando existe cierta remanencia de la instancia previa, puede
ocurrir que el arranque de la nueva instancia falle. En estos casos, se puede forzar el arranque de la
nueva instancia borrando la remanencia de una instancia anterior y luego arrancando una nueva
instancia o forzando un SHUT DOWN ABORT.
Modos de parada de la instancia

Comportamiento

Abort

Immediate

Transactional

Normal

Permite nuevas conexiones de usuario

No

No

No

No

Espera hasta que las sesiones abiertas

finalizan

No

No

No

Si

Espera hasta que las transacciones

abiertas finalizan

No

No

Si

Si

Realiza un checkpoint y cierra los

ficheros abiertos

No

Si

Si

Si

As pues, desde en entorno SQL*PLUS la parada de la instancia, en sus diferentes modos, se lanza
con:
SHUTDOWN [NORMAL |

TRANSACTIONAL

| ABORT

IMMEDIATE]

Shutdown normal
Es el tipo de parada por defecto. En este modo, es necesario tener en cuenta las siguientes
consideraciones:
No se permitirn nuevas conexiones desde el momento en que se lanza el comando SHUTDOWN
NORMAL.
Oracle esperar a que todas las sesiones activas se desconecten antes de empezar el proceso de
parada.

Puesto que Oracle aguarda hasta que todos los usuarios se desconecten, es posible que la parada se
retrase de manera indefinida si un usuario conectado no lleva a cabo ninguna accin. Esto puede
suponer un trabajo extra, puesto que habra que identificar las conexiones activas y notificar a sus
usuarios que las cierren o, en su defecto, matarlas.
Este tipo de parada es limpio porque al arrancar de nuevo no es necesaria una recuperacin de la
instancia.
Shutdown transactional
Se trata de un modo ms agresivo que el anterior que se caracteriza por:
No se permitirn nuevas conexiones desde el momento en que se lanza el comando SHUTDOWN
TRANSACTIONAL.
No se permitir que las conexiones activas comiencen una nueva transaccin desde el momento en
que se lanza el comando.
Una vez que las transacciones activas se completan, todos los clientes son desconectados.
Una parada TRANSACTIONAL permite al usuario acabar la transaccin antes de la desconexin, lo
que evita que se pierdan trabajos, especialmente en el caso de transacciones largas. Este tipo de
parada tampoco necesita recuperar la instancia en un arranque posterior.
Shutdown immediate
Este tipo de parada se caracteriza por:
No se permitirn nuevas conexiones desde el momento en que se lanza el comando SHUTDOWN
IMMEDIATE.
Las transacciones no confirmadas sufrirn un ROLLBACK. Por tanto, los usuarios con una
transaccin en curso perdern su trabajo.
Oracle no espera a que los usuarios se desconecten. Cualquier transaccin en curso sufre un
ROLLBACK y sus conexiones terminan.
Es el modo ms adecuado para llevar a cabo paradas mediante scripts automticos sin la
intervencin de un operador y se quiere garantizar que la parada no se colgar. Tampoco es
necesaria la recuperacin de la instancia en el arranque posterior.

Shutdown abort
Es el modo ms agresivo de parada. Se caracteriza por:
No se permitirn nuevas conexiones desde el momento en que se lanza el comando SHUTDOWN
ABORT.
Se termina cualquier sentencia SQL en ejecucin, independientemente de su estado.
Las transacciones en curso no sufren ROLLBACK.
Oracle desconecta alos usuarios inmediatamente.
Este modo est pensado para situaciones de emergencia, como cuando ningun otro modo de parar la
instancia funciona. Es el modo de parada ms rpido. Sin embargo, abrir la base de datos despus
puede llevar ms tiempo, puesto que ser necesario recuperar la instancia para dejar los ficheros de
datos en un estado consistente.
Puesto que SHUTDOWN ABORT no hace un checkpoint de los ficheros de datos abiertos, la
recuperacin de la instancia es necesaria antes de que la base de datos pueda raeabrirse. Los otros
modos de parada no requieren recuperar la instancia.

4.3 CHECKPOINTS
Un checkpoint es un mecanismo clave en las paradas consistentes de la base de datos, la
recuperacin de la instancia y, en general, en cualquier operacin de la base de datos. El trmino
checkpoint tiene los siguientes signifcados:
Una estructura de datos que indica la posicin del checkpoint, que es el SCN en el fujo de redo al
que la instancia debe recuperarse cuando arranca. Esta posicin est determinada por el buffer
DIRTY ms antiguo en la database bufer cach. La posicin del checkpont acta como un puntero
al fujo de redo y se almacena en el fchero de control y en la cabecera de cada fchero de datos.
La escritura de la database buffer cach en disco. Generahnente, el DBWn escribe unos cuantos
bloques DIRTY de la database buffer cach a los fcheros de datos. Sin embargo, cuando ocurre un
chcckpoint, se escriben todos.
Oracle utiliza los checkpoints para conseguir los siguientes objetivos:
Reducir el tiempo necesario para la recuperacin en caso de que una fallo de la instancia o de los
medios.
Asegurar que los buffers sucios en la database buffer cach son escritos en disco regularmente.
Asegurar que todos los datos confirmados se escriben en disco durante una parada consistente.
El proceso CKPT (Checkpoint Process) es responsable de escribir los checkpoints en las cabeceras
de los ficheros de datos y del fichero de control. Los checkpoints ocurren en gran cantidad de
situaciones:
Checkpoints incrementales: un checkpoint incremental es un tipo de checkpoint cuyo objetivo es
evitar, parcialmente, escribir un gran nmero de bloques cuando se produce una conmutacin de
redo log. El DBWn comprueba, cada 3 segundos, qu tiene que hacer. Si el DWBn escribe buffers
sucios, avanza la posicin del checkpont, haciendo que el CKPT escriba la posicin del checkpoint
en el fichero de control, pero no en las cabeceras de los ficheros de datos.
Checkpont completo: ocurre cuando todos los buffers DIRTY se escriben en disco. Durante la
ejecucin normal, el DBWn escribe un cierto nmero de bufers en cada checkpoint incremental. En
un checkpoint completo, los escribe todos, lo que supone una carga enorme de CPU y de uso en
disco, lo que disminuye las prestaciones para las sesiones de usuario. Por esta razn, los checkpoints
completos solo deben lanzarse en dos circunstancias: una parada ordenada o a peticin del DBA.
Los checkpoints completos ocurren solo en paradas ordenadas o bajo peticin; los checkpoints
parciales automticamente o bajo demanda.
Cuando la base de datos se para con las opciones NORMAL, IMMEDIATE o TRANSACTIONAL
se produce un checkpoint: el DBWn vuelca todos los buffers DIRTY en disco antes de cerrar la base
de datos y desmontarla. Esto significa que cuando la base de datos vuelva a abrirse, no se necesitar
la recuperacin de la instancia. Por ello, siempre se prefiere una parada limpia, sobre todo antes de
algunas operaciones (como habilitar el modo ARCHIVELOG o flashback de base de datos). Un
checkpont completo se puede forzar bajo demanda con la sentencia:
ALTER SYSTEM checkpoint;
Los checkpoints lanzados manualmente no deberan ser necesarios en condiciones normales de
funcionainiento, aunque son tiles cuando se desea probar el efecto de algn ajuste.

Checkpoints parciales: ocurren automticamente como parte de ciertas operaciones. Dependiendo

de la operacin concreta, el checkpont afectar a diferentes buffers (ver tabla).
OperacinBuffers liberados de la cachPoner un tablespace en estado off-lineTodos los bloques
que forman parte del tablespacePoner un fichero de datos en estado off-line
Todos los bloques
que forman parte del fichero de datosBorrar un segmento Todos los bloques que forma parte del
segmentoTruncar una tablaTodos los bloques que forman la tablaPoner un tablespace en modo
BACKUPTodos los bloques que forman parte del tablespace

4.4 FICHEROS DE DIAGNOSTICO

Oracle incluye una infraestructura de diagnstico de fallos para la prevencin, deteccin,
diagnstico y resolucin de problemas de la base de datos, que se organiza en un repositorio de
ficheros llamado Oracle ADR (Automatic Diagnostic Repository) que almacena informacin de
diagnstico como los ficheros de traza, el alert log e informes de monitorizacin.
Los aspectos clave del ADR son los siguientes:
Estructura de directorios unificada.
Fornatos de datos de diagnstico consistentes.
Conjunto de herramientas unificado.
Las anteriores caracteristicas permiten a los clientes y a Oracle Support correlar y analizar los datos
de diagnstico sobre mltiples instancias, componentes y productos de Oracle.
ADR est fuera de la base de datos, lo que permite a Oracle acceder y gestionar ADR cuando la base
de datos no est fisicamente disponible. Una instancia puede crear ADR antes de que la base de
datos se haya creado.
Vemos la estructura y localizacin de la jerarqua de directorios del ADR de una instancia de la base
de datos.
K:\oraclexe\app\oracle\diag\rdbms\xe\xe

Como muestra el siguiente ejemplo, cuando se arranca una instancia Oracle crea un ADR por
defecto utilizando el SID y nombre como raz del ADR:
SQL*Plus: Release 11.2.0.2.0 Production on Mar Sep 17 18:21:55 2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
620757184 bytes
Database Buffers
444596224 bytes
Redo Buffers
4591616 bytes
Database mounted.
Database opened.
SQL> SELECT name, value FROM v$diag_info;
NAME

------------------------Diag Enabled
ADR Base
ADR Home
Diag Trace
Diag Alert
Diag Incident
Diag Cdump
Health Monitor
Default Trace File
Active Problem Count
Active Incident Count

VALUE

----------------------------------------------------TRUE
K:\ORACLE11XE\APP\ORACLE
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe\trace
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe\alert
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe\incident
K:\oracle11xe\app\oracle\diag\rdbms\xe\xe\cdump
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe\hm
K:\ORACLE11XE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_ora_3412.trc
0
0

11 filas seleccionadas

4.4.1 El alert log

Cada base de datos tiene un alert log, que es un fichero XML que contiene, por orden cronolgico,
un log de mensajes y errores de la base de datos. El alert log contiene lo siguiente:
Todos los errores internos (ORA-600), los errores de corrupcin de bloques (ORA-1578) y errores
de deadlock (ORA-60).
Operaciones administrativas como sentencias DDL y los comandos STARTUP, SHUTDOWN,
ARCHIVELOG y RECOVER.
Algunos mensajes y errores relacionados con las funciones de servidor compartido y los
dispatchers.
Errores ocurridos durante el refresco automtico de una vista materializada.

Oracle utiliza el alert log como una alternativa a mostrar la informacin en la interfaz grfica del
Enterprise Manager. Si una operacin administrativa tiene xito, Oracle escribe el mensaje en el
alert log como completed junto con una marca temporal.
Oracle crea un alert log en el directorio alert cuando se arranca la instancia por primera vez, incluso
si todava no se ha creado la base de datos.

El siguiente ejemplo muestra un fragmento del alert log en modo texto xml, log.xml de
K:\oracle11xe\app\oracle\diag\rdbms\xe\xe\alert
<msg time='2013-09-17T18:08:36.029+02:00' org_id='oracle' comp_id='rdbms'
msg_id='opistr_real:948:3971575317' type='NOTIFICATION' group='startup'
level='16' host_id='ADOLFO-PC' host_addr='fe80::47d:a2ac:a97:bcf%14'
pid='4744' version='1'>
<txt>Starting ORACLE instance (normal)
</txt>
</msg>
<msg time='2013-09-17T18:08:36.059+02:00' org_id='oracle' comp_id='rdbms'
msg_id='ksunfy:15972:2937430291' type='NOTIFICATION' group='startup'
level='16' host_id='ADOLFO-PC' host_addr='fe80::47d:a2ac:a97:bcf%14'
pid='4744'>
<txt>LICENSE_MAX_SESSION = 0
</txt>
</msg>

..
..
..
<msg time='2013-09-17T18:43:05.920+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='ADOLFO-PC' host_addr='fe80::47d:a2ac:a97:bcf%14' module=''
pid='3260'>
<txt>O/S-Error: (OS 1) Funcin incorrecta. !
</txt>
</msg>
Es interesante ver el log.xml despus de hacer shutdown...
...
<msg time='2013-09-17T18:45:29.144+02:00' org_id='oracle' comp_id='rdbms'
msg_id='opistp_real:1646:503144415' type='NOTIFICATION' group='shutdown'
level='16' host_id='ADOLFO-PC' host_addr='fe80::47d:a2ac:a97:bcf%14'
pid='3812'>
<txt>Instance shutdown complete
</txt>
</msg>

La vista V$DIAG_INFO indica la ubicacin del alert log.

Ficheros de traza
Un fichero de traza es un fichero administrativo que contiene los datos utilizados para investigar los
problemas y proporciona una guia para ajustar las aplicaciones o la instancia.
Existen varios tipos de traza. Por un lado, los procesos servidores y los de respaldo escriben
peridicamente, cada uno en un fichero, informacin acerca de su entorno, estado, actividades y
errores. Tambin es posible trazar sentencias SQL individuales de manera que se registre
informacin sobre las prestaciones de dichas sentencias. Para habilitar el trazado para un
identificador de cliente, servicio, mdulo, accin, sesin, instancia o base de datos, se deben
ejecutar los procedimientos adecuados en el paquete DBMS_MONITOR o utilizar el Enterprise
Manager.
Un volcado es un tipo especial de fichero de traza. Mientras una traza tiende a ser una salida
continua de datos de diagnstico, un volcado es tpicamente una salida nica de datos de
diagnstico que se produce en respuesta a un evento (como una incidencia). Cuando ocurre una
incidencia, la base de datos escribe uno o mas volcados en el directorio de incidencias creado para
dicha incidencia. Los volcados de incidencias contienen el nmero de incidencia en el nombre del
fichero.
Ubicacin de los ficheros. ADR guarda las trazas en el subdirectorio de trazas. Los nombres
dependen de la plataforma y tienen la extensin .trc.
Generalmente, los nombres de las trazas de los procesos de respaldo de 1a base de datos contienen
el SID, el nombre de proceso de respaldo y el nmero del proceso sistema operativo. Por ejemplo, la
traza para el proceso RECO pordra ser miSID_reco_13l3.trc.
Los nombres de las trazas de los procesos servidores contienen el SID, la cadena ora y el nmero
de procesos del sistema operativo. Por ejemplo, un proceso servidor podra tener un fichero de traza
con el nombre miSID_ora_l304_ trc.
En ocasiones, las trazas tienen asociado un fichero . trm que contiene informacin estructural sobre
la traza y que se emplea para la bsqueda y navegacin.