INSTITUTO TECNOLGICO DE LZARO

CRDENAS



CARRERA: INGENIERIA EN SISTEMAS
COMPUTACIONALES



MATERIA: ADMINISTRACIN DE BASES DE DATOS



UNIDAD IV OPERACIN Y MANTENIBILIDAD



SEMESTRE: 6



INTEGRANTES DE EQUIPO:

BASURTO PEALOZA MINERVA - 11560463
LUIS DAVID GALVEZ ESPINOSA - 11560112






LZARO CRDENAS MICHOACAN 28 DE MAYO DEL 2014
Unidad 4 - Operacin y Mantenibilidad
4.1 Bitcoras de trabajo del DBMS.

Qu es el Redo Log?
La estructura ms importante para las operaciones de recuperacin es el registro
de rehacer, que consiste en dos o ms archivos pre asignados que almacenan
todos los cambios realizados en la base de datos a medida que ocurren. Cada
instancia de una base de datos Oracle tiene un registro de rehacer asociado para
proteger la base de datos en caso de fallo de instancia.

Rehacer Realizar registro

Rehacer los archivos de registro se llena de registros de rehacer. Un registro de
rehacer, tambin llamado una entrada de rehacer, se compone de un grupo de
vectores de cambio, cada uno de los cuales es una descripcin de un cambio
realizado en un solo bloque en la base de datos. Por ejemplo, si cambia un valor
salarial en una tabla de empleados, se genera un registro de rehacer contienen
vectores de cambio que describen cambios en el segmento de bloque de datos de
la tabla, el bloque de datos de deshacer segmento, y la mesa de operaciones de
los segmentos de deshacer.

Vuelva a realizar entradas de datos de registro que puede utilizar para reconstruir
todos los cambios realizados en la base de datos, incluyendo los segmentos de
deshacer. Por lo tanto, el registro de rehacer tambin protege los datos de
rollback. Al recuperar la base de datos utilizando datos redo, la base de datos lee
los vectores de cambio en los registros de rehacer y aplica los cambios a los
bloques correspondientes.

Registros Redo se almacenan en forma circular en el bfer del registro de rehacer
de la SGA (ver "Cmo Oracle Database escribe a los Redo Log") y se escriben en
uno de los archivos de registro de rehacer por el escritor Log (LGWR) proceso en
segundo plano base de datos. Cuando se confirma una transaccin, LGWR
escribe los registros de rehacer las transacciones desde el buffer de redo log del
SGA en un archivo de registro de rehacer, y asigna un nmero de cambio de
sistema (SCN) para identificar los registros de rehacer para cada transaccin
confirmada. Slo cuando todos los registros de rehacer asociados a una
transaccin determinada son con seguridad en el disco en los registros en lnea es
el proceso de usuario notificado de que la transaccin haya sido cometida.




Registros Redo tambin se pueden escribir en un archivo de registro de rehacer
antes de que se confirme la transaccin correspondiente. Si el buffer de redo log
se llena, u otra transaccin se confirma, sofocos LGWR todas las entradas de
registro de rehacer en el buffer de redo log en un archivo de registro de rehacer, a
pesar de que algunos registros de rehacer no podrn ser comprometidos. Si es
necesario, la base de datos se puede revertir estos cambios.

Cmo Oracle Database escribe a los Redo Log

El registro de rehacer de una base de datos consiste en dos o ms archivos de
registro de rehacer. La base de datos requiere un mnimo de dos archivos de
garantizar que uno est siempre disponible para la escritura, mientras que el otro
est siendo archivado (si la base de datos est en modo ARCHIVELOG). Consulte
"Administracin de registros de rehacer archivados" para obtener ms informacin.
LGWR escribe a rehacer los archivos de registro de forma circular. Cuando el
archivo de registro de rehacer actual llena, LGWR comienza a escribir al siguiente
archivo de registro de rehacer disponible. Cuando el ltimo archivo de registro de
rehacer disponible est llena, LGWR vuelve al primer archivo de registro de
rehacer y escribe en l, comenzando el ciclo otra vez. Los nmeros al lado de
cada lnea indican el orden en que LGWR escribe a cada archivo de registro de
rehacer.

Los archivos de registro de rehacer rellenos estn disponibles para LGWR para su
reutilizacin en funcin de si el archivo est activado.

Si el archivo est desactivado (la base de datos est en modo
NOARCHIVELOG), un archivo de registro de rehacer lleno est disponible
despus de los cambios registrados en l se han escrito en los archivos de datos.

Si est habilitado el archivado (la base de datos est en modo ARCHIVELOG),
un archivo de registro de rehacer lleno est disponible para LGWR despus de los
cambios registrados en l se han escrito en los archivos de datos y el archivo se
ha archivado.

Archivos Redo Log activo (actual) e inactivas

Base de datos Oracle utiliza slo uno los archivos de registro de rehacer a la vez
para almacenar los registros de rehacer escritos del bfer del registro de rehacer.
El archivo de registro de rehacer LGWR que est escribiendo activamente se
llama el archivo de registro de rehacer actual.

Rehacer los archivos de registro que se requieren para la recuperacin de la
instancia se denominan archivos de registro de rehacer activos. Rehacer los
archivos de registro que ya no son necesarios para la recuperacin de la instancia
se denominan archivos de registro de rehacer inactivos.

Si ha habilitado el archivado (la base de datos est en modo ARCHIVELOG),
entonces la base de datos no se puede reutilizar o sobrescribir un archivo de
registro en lnea activa hasta que uno de los procesos en segundo plano
archivador (ARCn) ha archivado su contenido. Si el archivo est desactivado (la
base de datos est en modo NOARCHIVELOG), a continuacin, cuando el ltimo
archivo de registro de rehacer est llena, LGWR sigue sobrescribiendo el archivo
de registro siguiente en la secuencia cuando est inactivo.

Interruptores y Nmeros de secuencia de registro Entrar

Un cambio de registro es el punto en el que la base de datos deja de escribir en un
archivo de registro de rehacer y comienza a escribir a otro. Normalmente, un
cambio de registro se produce cuando el archivo de registro de rehacer actual est
completamente lleno y la escritura debe seguir el siguiente archivo de registro de
rehacer. Sin embargo, puede configurar switches de registro que se produzca a
intervalos regulares, con independencia de que el archivo de registro de rehacer
actual est completamente lleno. Tambin puede forzar interruptores de registro
de forma manual.

Oracle Database asigna a cada registro de rehacer presentar un nuevo nmero de
secuencia de registro cada vez que se produce un cambio de registro y LGWR
comienza a escribir a la misma. Cuando los archivos de base de datos rehacer los
archivos de registro, el registro de archivado retiene su nmero de secuencia de
registro. Un archivo de registro de rehacer que se encenda de nuevo para su uso
se le da el siguiente nmero de secuencia de registro disponible.

Cada archivo de registro de rehacer en lnea o archivados se identifica por su
nmero de secuencia de registro. Durante el accidente, instancia o la recuperacin
de medios, la base de datos se aplica correctamente los archivos de registro de
rehacer en orden ascendente utilizando el nmero de secuencia de registro de los
archivos de registro archivados y rehacer necesarias.


Planificacin de la Redo Log

Esta seccin proporciona pautas que debe tener en cuenta al configurar una
instancia de base de datos de registro de rehacer y contiene los siguientes temas:
Archivos de registro Redo Multiplexacin
La colocacin de Ingreso de Miembros Rehacer en diferentes discos
Planificar el tamao de los archivos de registro de rehacer
Planificar el tamao del bloque de los archivos de registro de rehacer
Seleccin del nmero de archivos de registro Redo
Control Lag Archivo

Archivos Redo Log Multiplexacin

Para proteger contra un fallo que implica la redo log en s, Oracle Database
permite un registro de rehacer multiplexados, lo que significa que dos o ms
copias idnticas de la redo log se pueden mantener de forma automtica en
lugares separados. Para obtener el mayor beneficio, estos lugares deben estar en
discos separados. Incluso si todas las copias del registro de rehacer estn en el
mismo disco, sin embargo, la redundancia puede ayudar a proteger contra errores
de E / S, corrupcin de archivos, etc. Cuando los archivos de registro de rehacer
son multiplexadas, LGWR escribe simultneamente la misma informacin de
registro de rehacer en varios archivos de registro de rehacer idnticas, lo que
elimina un punto nico de fallo de registro de rehacer.

Multiplexacin se realiza mediante la creacin de grupos de archivos de registro
de rehacer. Un grupo consta de un archivo de registro de rehacer y sus copias
multiplexadas. Cada copia idntica se dice que es un miembro del grupo. Cada
grupo de registro de rehacer se define por un nmero, tal como el grupo 1, grupo
2, y as sucesivamente.

Cada miembro de un grupo de archivos de registro es simultneamente activo, es
decir, al mismo tiempo escrita por LGWR-como lo indican los registros idnticos
nmeros de secuencia asignados por LGWR. Oracle recomienda multiplex sus
archivos de registro de rehacer. La prdida de los datos del archivo de registro
puede ser catastrfico si se requiere la recuperacin. Tenga en cuenta que cuando
se multiplex el registro de rehacer, la base de datos debe aumentar la cantidad de
E / S que se realiza. Dependiendo de su configuracin, esto puede afectar al
rendimiento de base de datos global.

En respuesta a rehacer fracaso Log

Siempre LGWR no puede escribir en un miembro de un grupo, la base de datos
marca ese miembro como no vlido y escribe un mensaje de error en el archivo de
rastreo LGWR y para el registro de alertas de bases de datos para indicar el
problema con los archivos inaccesibles.
La reaccin especfica de LGWR cuando un miembro del registro de rehacer no
est disponible depende de la razn de la falta de disponibilidad, tal como se
resume en la tabla que sigue.
Condition LGWR Action
LGWR puede escribir con xito en al
menos un miembro de un grupo
Escritura procede como normal. LGWR escribe
a los miembros disponibles de un grupo e
ignora a los miembros de carcter.
LGWR no puede acceder el siguiente
grupo en la conmutacin de registro ya
que el grupo debe archivarse
Operacin de base de datos se detiene
temporalmente hasta que el grupo est
disponible o hasta que el grupo se archiva.
Todos los miembros del grupo
siguiente son inaccesibles para el
LGWR en una conmutacin de registro
debido a fallas en los medios
Base de datos Oracle devuelve un error, y
cierra la instancia de base de datos. En este
caso, puede que necesite realizar la
recuperacin de los medios de comunicacin
sobre la base de datos de la prdida de un
archivo de registro de rehacer. Si el puesto de
control de la base de datos ha ido ms all del
log de redo perdidas, recuperacin de los
medios de comunicacin no es necesario,
porque la base de datos ha salvado los datos
registrados en el registro de rehacer a los
archivos de datos. Slo necesita soltar el grupo
de registro de rehacer inaccesibles. Si la base
de datos no archiva el registro mal, usar sin
alterar la base de datos claro LOFGILE archivar
para desactivar el archivo antes de que el
registro se puede caer.
Todos los miembros de un grupo de
repente sean inaccesibles para el
LGWR mientras est escribiendo en
ellos
Base de datos Oracle devuelve un error y la
instancia de base de datos se apaga
inmediatamente. En este caso, puede que
necesite para llevar a cabo la recuperacin de
los medios de comunicacin. Si los medios de
comunicacin que contiene el registro no est
realmente perdido--por ejemplo, si
inadvertidamente se apag la unidad para el
registro - recuperacin de los medios de
comunicacin no necesite. En este caso, usted
slo necesita vuelva a encender la unidad y
deje que la base de datos a realizar la
recuperacin automtica de la instancia.







Configuraciones legales e ilegales


En la mayora de los casos, un registro de rehacer multiplexados debe ser
simtrica: todos los grupos de registro de rehacer deben tener el mismo nmero
de miembros. Sin embargo, la base de datos no requiere que un registro de
rehacer multiplexados ser simtrica. Por ejemplo, un grupo puede tener slo un
miembro, y otros grupos pueden tener dos miembros. Esta configuracin protege
contra fallos de disco que afecten temporalmente a algunos miembros de registro
de rehacer, pero dejan intactos los dems.

El nico requisito para un registro de rehacer ejemplo es que tenga al menos dos
grupos.

La colocacin de Ingreso de Miembros Rehacer en diferentes discos

Cuando la creacin de un registro de rehacer multiplexados, lugar miembros de un
grupo en diferentes discos fsicos. Si un disco falla, entonces slo uno de los
miembros de un grupo se convierte en no disponible para LGWR y otros miembros
siguen siendo accesibles a LGWR, por lo que el ejemplo puede seguir
funcionando.
Si el archivo del registro de rehacer, se extendi rehacer miembros de registro a
travs de los discos para eliminar la discordia entre los procesos de fondo y ARCN
LGWR. Por ejemplo, si tiene dos grupos de miembros del registro de rehacer
multiplexados (un registro de rehacer doble cara), coloque cada miembro en un
disco diferente y establecer su destino de archivado con un quinto disco. Si lo
hace, evitar la contencin entre LGWR (escrito a los miembros) y ARCn (lectura
de los miembros).
Archivos de datos tambin deben ser colocados en diferentes discos a partir de
archivos de registro de rehacer para reducir la contencin en escribir bloques de
datos y rehacer los registros.


Planificacin del tamao de los archivos de registro de rehacer

Al ajustar el tamao de los archivos de registro de rehacer, considere si se le
archivando el registro de rehacer. Rehacer los archivos de registro deben ser de
un tamao que un grupo de llenado puede ser archivado en una sola unidad de
medios de almacenamiento fuera de lnea (tal como una cinta o disco), con la
menor cantidad de espacio en el medio no se lo usa. Por ejemplo, supongamos
que slo un grupo de redo log lleno puede caber en una cinta y un 49% de la
capacidad de almacenamiento en cinta sigue sin ser utilizado. En este caso, es
mejor para reducir el tamao de los archivos de registro de rehacer ligeramente,
de modo que dos grupos de registro podran ser archivados en cada cinta.
Todos los miembros de un mismo grupo de registro de rehacer multiplexados
deben ser del mismo tamao. Los miembros de los diferentes grupos pueden
tener diferentes tamaos. Sin embargo, no hay ninguna ventaja en mayor o menor
tamao de archivo entre los grupos. Si los controles no estn ajustados a
producirse entre los switches de registro, hacer que todos los grupos del mismo
tamao para garantizar que los puestos de control se producen a intervalos
regulares.

El tamao mnimo permitido para un archivo de registro de rehacer es de 4 MB.
Vea tambin:

Su sistema operativo especfico de documentacin de Oracle. El tamao por
defecto de los archivos de registro de rehacer es el sistema operativo
dependiente.

Planificacin del tamao de bloque de los archivos de registro de rehacer

A diferencia del tamao de bloque de base de datos, que puede ser entre 2 K y 32
K, rehacer los archivos de registro siempre predeterminada a un tamao de bloque
que es igual al tamao de sector fsico del disco. Histricamente, esto ha sido
tpicamente 512 bytes (512B).

Algunas unidades de disco nuevas de alta capacidad ofrecen 4K bytes (4K)
tamaos de sector, tanto para aumentar la capacidad ECC y la mejora de la
eficiencia de formato. La mayora de las plataformas de base de datos Oracle son
capaces de detectar este tamao de sector ms grande. La base de datos se crea
automticamente los archivos de registro de rehacer con un tamao de bloque de
4K en esos discos.

Sin embargo, con un tamao de bloque de 4K, hay una mayor desperdicio redo.
De hecho, la cantidad de desperdicio de rehacer en bloques de 4K frente a
bloques 512B es significativa. Se puede determinar la cantidad de desperdicio
redo viendo las estadsticas almacenadas en el V $ SESSTAT y V $ SYSSTAT
vistas.

SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage';

NAME VALUE
-------------------------------- ----------
redo wastage 17941684

Para evitar el desperdicio redo adicional, si est utilizando el modo de emulacin
de unidades de disco del tamao del sector disks-4K que emulan un tamao de
sector 512B en la Interfaz del disco-puede invalidar el tamao de bloque de 4K
predeterminado para registros de rehacer especificando un tamao de bloque
512B o, para algunas plataformas, un tamao de bloque de 1K. Sin embargo, se le
cobrar una degradacin significativa del rendimiento cuando un registro de
escritura redo no est alineada con los principios del sector fsico de 4K. Debido a
siete de las ocho ranuras 512B en un sector fsico de 4K no estn alineados, la
degradacin del rendimiento que normalmente ocurre.
Por lo tanto, se debe evaluar el equilibrio entre el rendimiento y el desperdicio de
disco en la planificacin del tamao de bloque de redo log en los discos en modo
de emulacin de tamao de sector de 4 KB.

A partir de Oracle Database 11g versin 2, puede especificar el tamao del bloque
de archivos de registro de rehacer en lnea con la palabra clave BLOCKSIZE en el
CREATE DATABASE, ALTER DATABASE, y CREATE CONTROLFILE. Los
tamaos de los bloques permitidos son 512, 1024 y 4096.

La siguiente declaracin se suma un grupo de archivos de registro de rehacer con
un tamao de bloque de 512B. La clusula BLOCKSIZE 512 es vlido pero no es
necesario para los discos de tamao de sector 512B. Para los discos de modo de
emulacin de tamao de sector de 4 KB, la clusula BLOCKSIZE 512 anula el
tamao de 4K defecto.

ALTER DATABASE orcl ADD LOGFILE
GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log')
SIZE 100M BLOCKSIZE 512 REUSE;
Para determinar el tamao de bloque del archivo de registro de rehacer, ejecute la
siguiente consulta:
SQL> SELECT BLOCKSIZE FROM V$LOG;

BLOCKSIZE
---------
512
Seleccin del nmero de archivos de registro Redo

La mejor manera de determinar el nmero apropiado de archivos de registro de
rehacer de una instancia de base de datos es para probar diferentes
configuraciones. La configuracin ptima con los grupos de menor nmero posible
sin obstaculizar LGWR de escribir la informacin de registro de rehacer.
En algunos casos, un ejemplo de base de datos puede requerir slo dos grupos.
En otras situaciones, una instancia de base de datos puede requerir grupos
adicionales para garantizar que un grupo reciclado est siempre disponible para
LGWR. Durante la prueba, la forma ms fcil para determinar si la configuracin
del registro de rehacer actual es satisfactoria es examinar el contenido del archivo
de rastreo LGWR y el registro de alertas de bases de datos. Si los mensajes de
indicar que LGWR tiene con frecuencia que esperar a que un grupo debido a un
puesto de control no se ha completado o un grupo no han sido archivados,
agregar grupos.

Tenga en cuenta los parmetros que pueden limitar el nmero de archivos de
registro de rehacer antes de crear o modificar la configuracin de un registro de
rehacer instancia.
Los siguientes parmetros limitan el nmero de archivos de registro de rehacer
que se pueden agregar a una base de datos:

El parmetro MAXLOGFILES utilizado en la instruccin CREATE
DATABASE determina el nmero mximo de grupos de archivos de registro
de rehacer para cada base de datos. Los valores del grupo pueden variar
de 1 a MAXLOGFILES. Cuando el nivel de compatibilidad se establezca
antes de 10.2.0, la nica manera de cambiar este lmite superior es volver a
crear la base de datos o el archivo de control. Por lo tanto, es importante
tener en cuenta este lmite antes de crear una base de datos. Cuando la
compatibilidad se establece en 10.2.0 o posterior, puede superar el lmite
MAXLOGFILES, y los archivos de control de ampliar segn sea necesario.
Si MAXLOGFILES no se especifica la instruccin CREATE DATABASE, la
base de datos utiliza un sistema de valores por defecto especficos de
funcionamiento.

El parmetro MAXLOGMEMBERS utilizado en la instruccin CREATE
DATABASE determina el nmero mximo de miembros de cada grupo. Al
igual que con MAXLOGFILES, la nica manera de cambiar este lmite
superior es volver a crear el archivo de base de datos o de control. Por lo
tanto, es importante tener en cuenta este lmite antes de crear una base de
datos. Si no se especifica ningn parmetro MAXLOGMEMBERS para la
instruccin CREATE DATABASE, la base de datos utiliza el valor por
defecto del sistema operativo.








4.1.1. Funciones especfica de la bitcora y la ubicacin de los archivos en
disco de la misma.

Control Lag Archivo

Puede forzar temas de registro de rehacer habilitados para cambiar sus registros
actuales a intervalos de tiempo regulares. En una configuracin primario / en
espera de base de datos, los cambios se ponen a disposicin de la base de datos
standby archivando registros de rehacer en el sitio primario y luego enviarlos a la
base de datos standby. Los cambios que se estn aplicando en la base de datos
standby puede quedarse atrs de los cambios que se estn produciendo en la
base de datos principal, debido a que la base de datos standby debe esperar a
que los cambios en el registro de rehacer la base de datos primaria a archivar (en
el registro de rehacer archivados) y luego enviado a la misma. Para limitar este
retraso, puede establecer el parmetro de inicializacin ARCHIVE_LAG_TARGET.
Al establecer este parmetro permite especificar en segundos el tiempo que el
retraso puede ser.



Ajuste de la inicializacin de parmetros ARCHIVE_LAG_TARGET

Cuando se establece el parmetro de inicializacin ARCHIVE_LAG_TARGET, que
causa la base de datos para examinar el registro de rehacer actual de la instancia
peridicamente. Si se cumplen las siguientes condiciones, el ejemplo cambia el
registro:

El registro actual se cre antes de n segundos atrs, y el tiempo estimado para el
archivo de registro actual es m segundo (proporcional al nmero de bloques de
rehacer utilizados en el registro actual), donde n + m excede el valor de la
inicializacin ARCHIVE_LAG_TARGET parmetro.
El registro actual contiene registros de rehacer.

En un entorno Real Application Clusters de Oracle, la instancia tambin causa
otros temas para cambiar y archivar sus registros si se estn quedando atrs. Esto
puede ser particularmente til cuando una instancia del clster es ms ocioso que
los otros casos (como cuando se est ejecutando una configuracin primario /
secundario de 2 nodos de Oracle Real Application Clusters).
El parmetro de inicializacin ARCHIVE_LAG_TARGET proporciona un lmite
superior para el tiempo (en segundos) que el registro actual de la base de datos
puede abarcar. Debido a que tambin se considera el tiempo estimado de archivo,
este no es el momento exacto interruptor de registro.
La siguiente configuracin de parmetros de inicializacin establece el intervalo de
cambio de registro de 30 minutos (un valor tpico).

ARCHIVE_LAG_TARGET = 1,800

Un valor de 0 desactiva esta funcionalidad de conmutacin de registro basado en
el tiempo. Esta es la configuracin por defecto.

Puede establecer el parmetro de inicializacin ARCHIVE_LAG_TARGET incluso
si no hay ninguna base de datos standby. Por ejemplo, el parmetro
ARCHIVE_LAG_TARGET se puede configurar especficamente para forzar
registros para ser conmutados y archivados.

ARCHIVE_LAG_TARGET es un parmetro dinmico y se puede configurar con el
comando SET ALTER SISTEMA.

Precaucin:
El parmetro ARCHIVE_LAG_TARGET debe establecerse en el mismo valor en
todas las instancias de un entorno Real Application Clusters de Oracle. En caso
contrario, los resultados por lo que un comportamiento impredecible.

Factores que influyen en la configuracin de ARCHIVE_LAG_TARGET

Tenga en cuenta los siguientes factores al determinar si desea establecer el
parmetro ARCHIVE_LAG_TARGET y para determinar el valor de este parmetro.

Registros Overhead de conmutacin (as como el archivo)
Con qu frecuencia ocurren los interruptores de registro normales como
resultado de las condiciones de registro completo
Prdida de redo Cunto se tolera en la base de datos standby

Configuracin ARCHIVE_LAG_TARGET no puede ser muy til si cambia de
registro naturales ya se producen con ms frecuencia que el intervalo
especificado. Sin embargo, en el caso de las irregularidades de la velocidad de
generacin de redo, el intervalo proporciona un lmite superior del intervalo de
tiempo cada registro actual cubre.
Si el parmetro de inicializacin ARCHIVE_LAG_TARGET se establece en un
valor muy bajo, no puede haber un impacto negativo en el rendimiento. Esto
puede obligar a interruptores de registro frecuentes. Ajuste el parmetro a un valor
razonable a fin de no degradar el rendimiento de la base de datos primaria.











4.1.2 Como funciona la Recuperacin (rollback) y la Permanencia (commit)
en la base de datos.

Los ficheros redo log contienen los cambios realizados sobre la BD. Conviene
presentar algunos conceptos relacionados con ellos.
Vector de Cambio describe un cambio simple en un bloque de datos de la BD.
Entre otros datos, contiene el nmero de versin, el cdigo de la transaccin, y la
direccin del bloque afectado.
Registro Redo log es un conjunto de vectores de cambio que describen un cambio
atmico sobre la BD. La transaccin es tambin la unidad de recuperacin.
Evolucin de Redo log por da se puede calcular ejecutando el comando archive
log list en dos das consecutivos y calculando la diferencia del nmero de
secuencia de los ficheros redo log, multiplicado por el tamao de un fichero redo
log:

SVRMGR> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /opt/app/oracle/admin/demo/arch/arch.log
Oldest online log sequence 3
Current log sequence 5

System Change Number, SCN es un dato que define la versin confirmada de la
BD en este instante de tiempo. Cuando una transaccin es confirmada, se le
asigna un SCN que la identifica unvocamente. Los ficheros redo log son
marcados con dos SCN. Cuando se abre un nuevo fichero redo log se le marca
con un SCN, low SCN, que es uno ms que el SCN mayor del anterior fichero redo
log; y su high SCN es puesto a infinito. Los SCN tambin se asocian al fichero de
control, ya que cuando se para una BD, un tablespace o fichero de datos, se
almacena para cada fichero de datos su stop SCN en el fichero de control.
Cambio de redo log es el proceso mediante el cual se deja de utilizar un
fichero redo log y el LGWR cambia al siguiente fichero redo log disponible. Se
puede hacer con el comando alter system switch logfile;.

Checkpoints son activados automticamente durante el funcionamiento normal de
la instancia, pero pueden ser activados manualmente con el comando alter system
checkpoint local o alter system checkpoint global dependiendo si nos referimos a
la instancia en la que estamos, o si queremos que afecte a todas las instancias
activas, respectivamente. Cada checkpoint lleva implcito un SCN, y Oracle
asegura que todos los cambios con un SCN menor que el del checkpoint dado han
sido escritos en el disco.


4 .2 Definicin de cules son los modos de operacin del DBMS. (Alta, Baja,
Recovery, etc.)


DBMS - Oracle

Una base de datos de Oracle puede estar uno de los siguientes estados:
STARTED, MOUNTED, OPEN o
OPEN MIGRATE. Valor contenido en el campo STATUS de la vista
V$INSTANCE.


Una base de datos de Oracle pasa por las siguientes fases cuando se sale de un
estado de cierre (shutdown state) a un estado de base de datos abierta (open
databas state):

1. La instancia es iniciada sin montar la base de datos.- Se inicia la instancia,
pero an no se asocia con una base de datos.

2. Montado de la base de datos.- Se inicia la instancia y se asocia con una
base de datos mediante la lectura de su archivo de control. La base de datos
est cerrada a los usuarios.

3. Abrir la base de datos.- Se inicia la instancia y es asociada con una base de
datos abierta. Los datos contenidos en los archivos de datos son accesibles a
los usuarios autorizados.



La base de datos Oracle realiza automticamente los siguientes pasos cada vez
que una base de datos abierta (open database) se apaga (shutdown)
consistentemente:

1. Base de datos cerrada.- La base de datos est montada, pero los archivos de
datos (data files) en lnea y los archivos de registro de rehacer (redo log files)
estn cerrados.
2. Desmontar la base de datos.- La instancia esta iniciada, pero ya no est
asociada con el archivo de control de la base de datos.

3. Apaga la instancia de Base de datos.- La instancia de base de datos ya no
est iniciada.

La base de datos de Oracle no pasa por todos los pasos anteriores en una
falla de la instancia o si se ejecuta el comando SHUTDOWN ABORT, que
finaliza inmediatamente la instancia.

En resumen: Arranque y parada de la base de datos de Oracle.














4.3 Comandos (opciones) utilizados para la activacin de los diferentes
modos de operacin del DBMS.

DBMS - Oracle

Arrancar una base de datos de ORACLE


El arranque de una base de datos ORACLE requiere tres etapas:

1. Arrancar la base de datos.- En esta parte del arranque se generan los
procesos background.

SQLPLUS> startup nomount

Oracle Instance started

2. Montar la base de datos.- En esta parte del proceso de arranque se produce
la conexin al/los archivo/s de control.

SQLPLUS> alter database mount

Database mounted

En caso de que se quiera iniciar la base de datos en este estado,
basta el siguiente comando: SQLPLUS> startup mount
Oracle Instance started
Database mounted

3. Abrir base de datos.- En esta parte de proceso se abren todos los archivos
asociados a los tablespaces y los archivos de Redo Log. Si es necesaria una
recuperacin (por un fallo de luz o CPU), se produce
en este momento.

SQLPLUS> alter database open

Database opened

En caso de que se quiera iniciar la base de datos en este estado
bastara con hacer lo siguiente: SQLPLUS> startup
Oracle Instance started
Database opened

Ms alternativas para el arranque de base de datos

Arranque solo para usuarios con el privilegio
RESTRICTED SESSION SQLPLUS> startup
restrict
Arranque forzado

SQLPLUS> startup force

Parada de la base de datos de ORACLE

La parada de una base de datos de Oracle se realiza mediante el comando
SHUTDOWN. Existen tres tipos de shutdown:

1. Shutdown normal.- Espera a que los usuarios conectados actualmente
finalicen TODAS las operaciones. Evita nuevas conexiones. Los
usuarios que intentan conectarse reciben el mensaje "Shutdown in
progress". Cierra y desmonta la base de datos. Cierra la SGA para los
procesos background. No necesita recuperacin al arrancar la base de
datos.

SQLPLUS> shutdown normal

2. Shutdown immediate.- Espera a que las transacciones actuales se
completen. Evita nuevas transacciones y nuevas conexiones. Los usuarios
que intentan conectarse o los que ya estn conectados al intentar realizar
una nueva transaccin reciben el mensaje "Shutdown in progress". El
proceso PMON finaliza las sesiones no activas y realiza ROLLBACK de
aquellas transacciones que no estn validadas. Cierra y desmonta la base
de datos. Cierra la SGA para los procesos background. No necesita
recuperacin al arrancar la base de datos.

SQLPLUS> shutdown immediate


3. Shutdown abort.- Parada drstica, no espera a que los usuarios conectados
actualmente finalicen sus transacciones. El usuario conectado recibe el
mensaje "No logged on". No se realiza ROLLBACK de las transacciones
pendientes. El proceso PMON finaliza las sesiones no activas y realiza
ROLLBACK de aquellas transacciones que no estn validadas. SI necesita
recuperacin al arrancar la base de datos.

SQLPLUS> shutdown abort



4.4. Manejo de ndices

Un ndice en una base datos Oracle 11g es un objeto opcional normalmente
asociado a una tabla pero que su uso es casi imprescindible. Una de las misiones
de los ndices es permitir que las consultas de datos sean ms rpidas
devolviendo su resultado, sobre todo en tablas con miles o millones de lneas. Una
tabla pude tener ms de un ndice y estos pueden estar compuestos por una o
varias columnas.
El estamento bsico para crear ndices en una base de datos Oracle 11g es:
1.CREATE INDEX nombre_indice ON nombre_tabla (columna, columna1,.);
En el artculo - Introduccin a la creacin de tablas en Oracle 11g - creamos la
tabla clientes, vamos a utilizarla como base para practicar la creacin de ndices.
En primer lugar vamos a crear un ndice sobre la columna CIF para que nuestras
bsquedas por esta columna sean lo ms rpidas posible:
1.CREATE INDEX factura.clientes_idx1 ON factura.clientes (CIF)
2.TABLESPACE FACTURA_IDX01;
Vamos a crear otro ndice compuesto por las columnas NombreCli y DireccionCli:
1.CREATE INDEX factura.clientes_idx2 ON factura.clientes (NombreCli,
DireccionCli)
2.TABLESPACE FACTURA_IDX01;
Como podis ver he aadido la clusula TABLESPACE para indicar que el ndice
se cree en el tablespace FACTURA_IDX01, si omitimos esta clusula el ndice se
crear en el DEFAULT TABLESPACE que tenga definido el usuario FACTURA.
El usuario que vaya a crear el ndice tiene que tener privilegio de CREATE INDEX
y UNLIMITED TABLESPACE o CUOTA sobre el tablespace FACTURA_IDX01.










4.4.1 Que Tipos de ndices son soportados

En oracle existen tres tipos de indices:
1) Table Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col [ASC | DESC]) index_clause index_attribs
2) Bitmap Join Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col_expression [ASC | DESC])
FROM [esquema.]table_name [tbl_alias]
WHERE condition [index_clause] index_attribs
3) Cluster Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON CLUSTER [esquema.]cluster_name index_attribs
las index_clauses posibles son:
LOCAL STORE IN (tablespace)

LOCAL STORE IN (tablespace)
(PARTITION [partition
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause]
[STORE IN {tablespace_name|DEFAULT]
[SUBPARTITION [subpartition [TABLESPACE tablespace]]]])

LOCAL (PARTITION [partition
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause]
[STORE IN {tablespace_name|DEFAULT]
[SUBPARTITION [subpartition [TABLESPACE tablespace]]]])

GLOBAL PARTITION BY RANGE (col_list)
( PARTITION partition VALUES LESS THAN (value_list)
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause] )

INDEXTYPE IS indextype [PARALLEL int|NOPARALLEL] [PARAMETERS
('ODCI_Params')]
{Esto es solo para table index, no para bitmap join Index}
Y adems index_attribs puede ser cualquier combinacin de los siguientes:
NOSORT|SORT
REVERSE
COMPRESS int
NOCOMPRESS
COMPUTE STATISTICS
[NO]LOGGING
ONLINE
TABLESPACE {tablespace|DEFAULT}
PCTFREE int
PCTUSED int
INITRANS int
MAXTRANS int
STORAGE storage_clause
PARALLEL parallel_clause
Si usamos la opcion PARALLEL esta debe estar al final.
create index es una de las pocas sentencias que pueden usar nologging option.
create index requiere un segmento temporal si no hay espacio en memoria
suficiente.
Crear indices basados en funciones require que query_rewrite_enabled este a true
y query_rewrite_integrity este a trusted.
Un ejemplo de indices basados en funciones para bsquedas en maysculas:
CREATE INDEX idx_case_ins ON my_table (UPPER(empname));

SELECT * FROM my_table WHERE UPPER(empname) = 'KARL';


































4.4.2 Como se realiza la Reorganizacin de ndices

Indiscriminado de ndices tienen seria desventajas tanto es espacio fsico como en
operaciones de insert y update. Los ndices son utilizados para acelerar el
acceso en bsquedas.

Es recomendado la separacin fsica de los ndices del tablespace de las tablas,
esto para que el proceso de bsqueda se realice en un HD mientras que la carga
de los datos se realice en otro HD. Tambin es recomendado la separacin de
tablespace TMP que se utiliza para realizar ordenamientos en las consultas, en
resumen una arquitectura ptima requiere como mnimo
4 discos duros: uno de datos, otro de ndices, otro de TEMP y el diccionario de
datos separados
(SYS
TEM)
.

Existen diferentes tipos de ndices en Oracle, cada uno de ellos es ms til para
ciertas aplicaciones.


ndice tipo rbol
B+

Un rbol B+ es un rbol equilibrado, esto significa que la altura del ndice es el
mismo para todos los valores asegurando as que la recuperacin de los datos
para cualquier valor toma en promedio el mismo tiempo.






Este tipo de ndice se utiliza mejor cuando cada valor tiene una cardinalidad alta
(bajo nmero de ocurrencias), por ejemplo, ndices de clave primaria o ndices
nicos. Un punto importante a tener en cuenta es que los valores NULL no se
indexan.

Para crear un ndice de este tipo se utiliza la siguiente
consulta:



SQL> CREATE INDEX <nombre_indice> ON
<tabla>(<columnas>);

Por ejemplo, la tabla t2 tiene como
columna a:

SQL> CREATE INDEX T2_UNIQUE ON
t2(a);



ndice Hash
Cluster

En este caso, el ndice es una funcin hash que apunta directamente la llave a la
fila en la tabla. El ndice no est separado, por lo que la funcin est dentro de la
tabla. Este ndice es especialmente til cuando se realizan consultas como X = Y



CREATE CLUSTER hashDemo (cedula int) size 50 hash is cedula hashkeys
50
00
;

CREATE TABLE
persona(
cedula int,
nombre
varchar(50), edad
int
) cluster hashDemo(cedula);


Actualizaciones y cuyas columnas tienen una cardinalidad baja (es decir, hay
pocos valores distintos). En este tipo de ndice de Oracle almacena un mapa de
bits para cada valor distinto en el ndice con un bit por cada fila de la tabla. Estos
mapas de bits son caros de mantener y, por tanto, no es adecuado para
aplicaciones que hacen escrituras a los datos.


Suponga que el registro civil de Costa Rica quiere realizar un estudio de minera
de datos, para ello quiere segmentar a la poblacin en las provincias del pas. De
esta forma cada persona va est en una categora de provincia. Es justamente
esta segmentacin lo que hace al bitmap laeleccin ideal para hacer consultas
por categoras.



<bitmap> CEDULA NOMBR EDAD PROVINCIA
E
1 4020706049 HEREDIA
1 4020706050 HEREDIA
1 4020706051 HEREDIA
2 1030706049 CARTAGO
1 4020706090 GUANACAS
TE
4 3020706049 HEREDIA


CREATE BITMAP INDEX <nombre_indice> ON <nombre_tabla>(<datos>)
REVERSE;

RECONSTRUCCION DE LOS INDICES
Se utilizan comnmente cuando el ndice est fragmentado, esto se debe a que la
estructura de los arboles B+ realizan un borrado lgico de los nodos y no as de
forma fsica. Por lo que con el tiempo estos ndices reducen su eficiencia.


La instruccin para reconstruir los
ndices es:

SQL> ALTER INDEX <nombre>
REBUILD




Monitorear los ndices

Podemos registrar un ndice en especfico para que Oracle nos provea
estadsticas relacionadas con un ndice.

SQL> ANALYZE INDEX <nombre> VALIDATE STRUCTURE

Si queremos ver las estadsticas generadas, debemos consultar la vista:


SQL> SELECT * FROM INDEX_STATS;





Borrado de los ndices INDICES

La consulta para borrar ndices es:

SQL> DROP INDEX <nombre>;