Unidad IV
UNIDAD 4. OPERACIÓN Y MANTENIBILIDAD
4.1 Bitácoras de trabajo del DBMS
En
muchos DBMS la bitácora incluye todo tipo de consulta incluyendo aquellas que
no modifican los datos.
La
operación ROLLBACK está basada en el uso de una bitácora. El DBMS (Sistema Manejador
de Bases de Datos) mantiene una bitácora o diario en cinta o en disco,
comúnmente, en el cual se registran los detalles de todas las operaciones de
actualización, en particular, los valores iniciales y final del objeto
modificado. Por tanto, si resulta necesario anular alguna modificación
específica, el sistema puede utilizar la entrada correspondiente de la bitácora
para restaurar el valor original del objeto restaurado.
Equipo:
Nancy Yessenia García Mayorga
Yariseth Lizbeth Guerrero García
Yesenia Lizbeth Guerrero García
Isidro Vidal Ibarra
4.1.1 Funciones especifica de las bitácoras
La
estructura más ampliamente usada para grabar las modificaciones de la base de
datos es la Bitácora. Cada registro de la bitácora escribe una única escritura
de base de datos y tiene lo siguiente:
·
Nombre de la Transacción
·
Valor antiguo
·
Valor Nuevo
Es
fundamental que siempre se cree un registro en la bitácora cuando se realice
una escritura antes de que se modifique la base de datos. También tenemos la
posibilidad de deshacer una modificación que ya se ha escrito en la base de
datos, esto se realizará usando el campo del valor antiguo de los registros de
la bitácora.
Los registros de la bitácora deben residir en
memoria estable como resultado el volumen de datos en la bitácora puede ser
exageradamente grande.
Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de
sincronización lo cual representa el límite entre dos transacciones
consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto
en el cual la base de datos esta (o debería estar) en un estado de
consistencia. Las únicas operaciones que establecen un punto de sincronización
son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de
sincronización:
Se
pierde todo posible posicionamiento en la base de datos. Se liberan todos los
registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las
transacción, no el programa.
Equipo:
Diana Patricia Guerrero Rodríguez.
Raymundo Cesar Salas Flores.
Manuel Ivan Almanza Calleros.
Jaaziel Alba Leal.
4.1.2 Recuperación (Rollback)
En
tecnologías de base de datos, un rollback o reversión es una operación que
devuelve a la base de datos a algún estado previo. Los Rollbacks son
importantes para la integridad de la base de datos, a causa de que significan
que la base de datos puede ser restaurada a una copia limpia incluso después de
que se han realizado operaciones erróneas. Son cruciales para la recuperación
de crashes de un servidor de base de datos; realizando rollback (devuelto)
cualquier transacción que estuviera activa en el tiempo del crash, la base de
datos es restaurada a un estado consistente.
En SQL, ROLLBACK es un
comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION
sean descartados por el sistema de gestión de base de datos relacional.
Una sentencia
ROLLBACK también publicará cualquier savepoint existente
que pudiera estar en uso.
La funcionalidad de
rollback está normalmente implementada con un Log de transacciones, pero puede
también estar implementada mediante control de concurrencia multiversión.
SQL Server comienza a
hacer un rollback de todas las transacciones que no fueron confirmadas además
de las que fueron rechazadas, dejando de esta manera la base de datos en un
estado consistente.
En el lenguaje SQL se
denomina ROLLBACK a cancelar_cambios.
Equipo:
Ayala Cazares Paola.
Ramírez Martínez Gabriela
Guadalupe.
Sosa Castillo Juan Ernesto.
Torres Cedillo Dulce Karina.
4.1.3 Permanencia (Commit)
En el contexto de la Ciencia de la computación y la
gestión de datos, commit (acción de comprometer) se refiere a la idea de
consignar un conjunto de cambios "tentativos, o no permanentes". Un
uso popular es al final de una transacción de base de datos.
En el lenguaje SQL se denomina COMMIT a aplicar_cambios.
Una sentencia COMMIT en SQL finaliza una transacción de base
de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone
visibles todos los cambios a otros usuarios. El formato general es emitir una
sentencia BEGIN WORK,
una o más sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede
emitir, la cual deshace todo el trabajo realizado desde que se emitió BEGIN WORK. Una
sentencia COMMIT
eliminará cualquiera de los savepoints (puntos de recuperación) existentes que
puedan estar en uso.
En términos de transacciones, lo opuesto de commit para
descartar los cambios "en tentativa" de una transacción, es un
rollback.
Equipo:
Ayala Cazares Paola.
Ramírez Martínez Gabriela
Guadalupe.
Sosa Castillo Juan Ernesto.
Torres Cedillo Dulce Karina.
4.2 Definición de los modos de operación de un DBMS (alta, baja, recovery)
El sistema de gestión de bases de datos es esencial para
el adecuado funcionamiento y manipulación de los datos contenidos en la base.
Se puede definir como: "El Conjunto de programas, procedimientos,
lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los
analistas, programadores o al administrador, los medios necesarios para
describir, recuperar y manipular los datos almacenados en la base, manteniendo
su integridad, confidencialidad y seguridad". Las funciones esenciales de
un SGDB son:
·
Descripción: Incluye la descripción de: Los
elementos de datos, su estructura, sus interrelaciones, sus validaciones. Tanto
a nivel externo como lógico global e interno esta descripción es realizada
mediante un LDD o Lenguaje de Descripción de Datos.
·
Manipulación: Permite Buscar, Añadir, Suprimir
y Modificar los datos contenidos en la Base de Datos. La manipulación misma
supone definir un criterio de selección, Definir la estructura lógica a
recuperar, Acceder a la estructura física. Esta manipulación es realizada mediante
un LMD o Lenguaje de Manipulación de Datos.
·
Utilización: La utilización permite acceder a
la base de datos, no a nivel de datos sino a la base como tal, para lo cual:
Reúne las interfaces de los usuarios y suministra procedimientos para el
administrador.
En términos ideales, un DBMS debe contar con estas
funciones, sin embargo, no todos las poseen, así existen algunos manejadores
que no cumplen la función de respaldo o de seguridad, dejándola al usuario o
administrador; sin embargo un DBMS que sea completo y que deba manejar una base
de datos multiusuario grande, es conveniente que cuente con todas estas
operaciones.
Equipo:
Jesús Gerardo De León Andrio
Irene Calzada Terrazas
4.3 Comandos de activación de los modos de operación.
Para ser uso de los diferentes comandos para un modo de
operación debemos estar como administrador o asuma un rol que incluya el perfil
de derechos Service Management.
·
Comando STARTUP: Para el arranque de una base de datos
hay tres fases de arranque, para realizar estas fases podemos utilizar startup
más un comando, las tres fases son las siguientes:
ü Fase de no Montaje: se leen los
parámetros del sistema, se inician las estructuras de memoria y los procesos de
segundo plano. La instancia se arranca sin asociarla a la base de datos.
Normalmente se utiliza cuando se modifica o se necesita crear el archivo de
control:
startup nomount;
ü Fase de Montaje: se asocia la
instancia con la base de datos. Se usa el archivo de parámetros para localizar
los archivos de control, que contienen el nombre de los archivos de datos y los
registros rehacer. Los archivos de datos y los registros de rehacer no están
abiertos, así que no son accesibles por usuarios finales para tareas normales.
Para realizar esta fase se pueden utilizar dos comandos:
startup mount;
alter database mount;
ü Fase de Apertura: se abren los
archivos de datos y los registros rehacer. La base de datos queda disponible
para las operaciones normales. Es necesario que existan registros rehacer de lo
contrario si no hay registros usamos el comando resetlogs, que crea registros
nuevos. Para esta fase se pueden usar dos comandos:
startup open;
alter database open; Si es necesario utilizar
resetlogs:
startup open resetlogs;
alter database open resetlogs;
startup restrict (sólo permite la conexión de
usuarios con el privilegio restricted sesión). Startup force (hace shutdown abort y arranca la BD).
·
Comando SHUTDOWN: El comando SHUTDOWN lo utilizamos parar una base de datos la cual consiste en
varias cláusulas:
ü Shutdown Normal: Este es el valor
por defecto, durante el proceso de parada no admite nuevas conexiones y espera
que las conexiones actuales finalicen. En el próximo arranque la base datos no
requiere procedimientos de recuperación.
ü Shutdown Immediate: Se produce una
parada inmediata de la base de datos, durante el proceso de parada no permite
nuevas conexiones y las actuales la desconecta, las transacciones que no estén
commit se hará rollback de ellas. En el próximo arranque la base datos no
requiere procedimientos de recuperación.
ü Shutdown Transactional: Se
produce una parada hasta que hayan terminado las transacciones activas, no
admite nuevas conexiones y tampoco nuevas transacciones, una vez que las
transacciones activas van terminando va desconectando a los usuarios. En el
próximo arranque la base datos no requiere procedimientos de recuperación.
ü Shutdown Abort: Aborta todos los
procesos de una base de datos, durante el proceso de parada no permite nuevas
conexiones y las actuales la desconecta, las transacciones que no estén commit
se hará rollback de ellas. En el próximo arranque la base datos puede requerir
procedimientos de recuperación.
·
Comando Describe: Este comando permite conocer la
estructura de una tabla, las columnas que la forman y su tipo y restricciones: DESCRIBE f1;
·
Comando SHOW TABLES y SHOW CREATE TABLE: El comando SHOW
TABLES muestra las tablas dentro de una base de datos y SHOW CREATE TABLES
muestra la estructura de creación de la tabla.
·
Modificación: Para realizar una modificación utilizamos
el comando ALTER TABLE. Para usar ALTER TABLE, necesita permisos ALTER, INSERT
y CREATE para la tabla.
Equipo:
Jesús Gerardo De León Andrio
Irene Calzada Terrazas
4.4 Manejo de índices.
El
índice de una base de datos es una estructura alternativa de los datos en una
tabla. El propósito de los índices es acelerar el acceso a los datos mediante
operaciones físicas más rápidas y efectivas. En pocas palabras, se mejoran las
operaciones gracias a un aumento de la velocidad, permitiendo un rápido acceso
a los registros de una tabla en una base de datos.
En
MySQL se manejan comúnmente dos tipos de índices, los cuales son:
·
Índices agrupados:
Son aquellos que definen
el orden en que almacenan las filas de la tabla.
La clave del índice agrupado es el elemento clave para esta ordenación; se
implementa como una estructura de árbol b que ayuda a que la recuperación de
las filas a partir de los valores de las claves del índice agrupado sea más
rápida.
·
Índices No Agrupados:
Los índices no
agrupados tienen la misma estructura de árbol b que los índices agrupados, con
algunos matices en los índices no-agrupados, en
el nivel de hoja del índice, hay un puntero a la localización física de la fila
correspondiente en el índice agrupado. Además, la ordenación de las filas del
índice está construida en base a la(s) columna(s) indexadas, lo cual no quiere
decir (a diferencia de los índices agrupados), que la organización física de
las páginas de datos corresponda con el índice.
Equipo:
Nestor Iván Torres Gaytán
José Luis Vanoye Bocanegra
José Roberto Jiménez Flores
4.4.1 Tipos de índices
Existen diferentes tipos de
índices algunos de ellos son:
·
Índices agrupados: Son los que definen el orden en que almacenan las
filas de la tabla (nodos hoja/página de datos de la imagen anterior). La clave
del índice agrupado es el elemento clave para esta ordenación; el índice
agrupado se implementa como una estructura de árbol b que ayuda a que la
recuperación de las filas a partir de los valores de las claves del índice
agrupado sea más rápida. Debemos tener en cuenta:
ü Columnas selectivas
ü Columnas afectadas en consultas
ü Columnas accedidas "secuencialmente"
ü Columnas implicadas en JOIN, GROUP BY
ü Acceso muy rápido a filas: lookups
·
Índices no agrupados: tienen
la misma estructura de árbol b que los índices agrupados, con algunos matices;
como hemos visto antes, en los índices agrupados, en el último nivel del índice
(nivel de hoja) están los datos; en los índices no-agrupados, en el nivel de
hoja del índice, hay un puntero a la localización física de la fila
correspondiente en el índice agrupado.
·
Índices compuestos: es un índice de varias columnas de una tabla. Las
columnas de un índice compuesto que deben aparecer en el orden que tenga más
sentido para las consultas que recuperar datos y no necesita ser adyacente en
la tabla.
·
Índices descendientes: Este
tipo de índice almacena los datos en una columna o columnas de concreto en
orden descendente.
Equipo:
Nestor Iván Torres Gaytán
José Luis Vanoye Bocanegra
José Roberto Jiménez Flores
4.4.2 Reorganización de índices
Un
paquete puede usar la tarea Reorganizar índice para reorganizar los índices de
una base de datos individual o de varias bases de datos. Si la tarea solo
reorganiza los índices de una base de datos individual, puede elegir las vistas
o las tablas cuyos índices reorganiza la tarea. La tarea Reorganizar índice
también incluye la opción de compactar datos de objetos grandes. Los datos de
objetos grandes son datos de tipo image, text, ntext, varchar (max), nvarchar (max),
varbinary (max) o xml.
La
tarea Reorganizar índice encapsula la instrucción ALTER INDEX de Transact-SQL.
Si elige compactar datos de objetos grandes, la instrucción utiliza la cláusula
REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece
LOB_COMPACTION en OFF. Dentro de las tareas habituales de Mantenimiento de las
Bases de Datos se encuentran aquellas destinadas al control y respaldo de las
mismas como ser:
·
Control de Integridad
·
Chequeo de Consistencia
·
Copias de Seguridad o
Compactación de las bases.
Pero
también es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el
de mantener la performance de las bases de datos y evitar su degradación. Esos
trabajos son:
·
La Reorganización de Índices
·
La Actualización de Estadísticas.
Estos
trabajos son independientes del estado de la base de datos. Puede ocurrir que a
la base le falten estudios de optimización pero, al menos, mantendremos la
performance actual.
Si
la base se encuentra optimizada, entonces más aún, son necesarios para evitar
la degradación producto del uso continuo.
La instrucción DBCC
DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para
una tabla. La reorganización de realiza dinámicamente sin necesidad de conocer
la estructura de la misma o las restricciones que ella tenga.
La sintaxis de esta instrucción
es:
DBCC DBREINDEX
( ’basededatos.dueño.nombre_de_tabla‘ [
, índice [ , fillfactor ] ] ) [ WITH NO_INFOMSGS ]
Fillfactor
es el porcentaje de espacio de página destinado a ser ocupado.
WITH
NO_INFOMSGS se suprimen los mensajes generados en la ejecución.
Equipo:
Aylin Amairani
Salazar Alvarez
Alberto Sanchez
Fonseca
Rolando Leal Arizpe
4.4.3 Reconstrucción de índices
Es
importante periódicamente examinar y determinar qué índices son susceptibles de
ser reconstruidos. Cuando un Índice está descompensado puede ser porque algunas
partes de Normalmente reconstruimos un Índice con el comando ALTER INDEX.
Es
importante tener actualizadas las estadísticas de la base de datos. Para saber
si las estadísticas se están lanzando correctamente podemos hacer una consulta
sobre la tabla dba_indexes y ver el campo last_analyzed para observar cuando se
ejecutaron sobre ese Índice las estadísticas.
La
sentencia es la siguiente:
·
SELECT index_name, last_analyzed
FROM dba_indexed
WHERE table_owner=’nb_usuario’
FROM dba_indexed
WHERE table_owner=’nb_usuario’
Nota:
Siendo nb_usuario el nombre del esquema del usuario para el que queramos
validar las estadísticas. (Lanzar con usuario SYS)
Para
actualizar las estadísticas utilizamos el paquete DBM_STATS. Podemos
actualizar las estadísticas de todos los objetos de un esquema de la siguiente
forma:
·
Execute
DBMS_STATS.gather_schema_stats (‘Esquema’);
Nota:
Sustituimos esquema por el nombre de nuestro esquema a actualizar (lanzar con
usuario SYS)
Una vez actualizadas las estadísticas de los Índices de la base de datos lanzamos la siguiente consulta:
Una vez actualizadas las estadísticas de los Índices de la base de datos lanzamos la siguiente consulta:
·
SELECT index_name, blevel,
DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2,
'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OK
FROM dba_indexes where table_owner='Propietario';
DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2,
'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OK
FROM dba_indexes where table_owner='Propietario';
Nota:
Sustituimos Propietario por el esquema o propietario que queramos verificar
(lanzar con usuario SYS)
Con
esta sentencia obtendremos el nombre del Índice, el blevel y si es correcto.
|
INDEX_NAME
|
BLEVEL
|
OK
|
|
INX_CUENTA
|
1
|
OK
BLEVEL
|
|
INX_TRABAJO
|
0
|
OK
BLEVEL
|
|
INX_DINERO
|
|
BLEVEL
HIGH
|
.
Blevel
(branch level) es parte del formato del B-tree del Índice e indica el número de
veces que ORACLE ha tenido que reducir la búsqueda en ese Índice. Si este valor
está por encima de 4 el Índice deberá de ser reconstruido.
Comando ALTER INDEX
Como
hemos comentado esta sentencia se utiliza para cambiar o reconstruir un Índice
existente en la base de datos.
Para
poder ejecutar este comando el Índice debe de estar en el propio esquema donde
intentes ejecutarlo o deberías de tener el privilegio alter any index.
Para
reconstruir un Índice bastaría con lazar la siguiente sentencia:
·
ALTER INDEX REBUILD;
Para reconstruir una partición de un Índice podríamos hacer lo siguiente
·
ALTER INDEX REBUILD
PARTITION NOLOGGING;
Nota:
En algunos casos cuando alguno de los Índices tiene algún tipo de corrupción no
es posible reconstruirlo. La solución en este caso es borrar el Índice y
recrearlo.
Equipo:
Aylin Amairani
Salazar Alvarez
Alberto Sanchez
Fonseca
Rolando Leal Arizpe
|
EQUIPOS
|
TEMAS
|
CUMPLIMIENTO
|
|
Equipo 1:
Diana Patricia Guerrero Rodríguez
Raymundo Cesar Salas Flores
Jaaziel Alba Leal
Manuel Iván Almanza Calleros
|
4.1.1 Funciones especifica de las
bitácoras.
|
ü CUMPLIÓ
|
|
Equipo 2:
Dulce Karina Torres Cedillo
Paola Ayala Cazares
Juan Ernesto Sosa Castillo
Gabriela Guadalupe Ramírez Martínez
|
4.1.2 Recuperación (Rollback)
4.1.3 Permanencia (Commit)
|
ü CUMPLIÓ
|
|
Equipo 3:
Jesús Gerardo De León Andrio
Irene Calzada Terrazas
|
4.2 Definición de los modos de operación de
un DBMS (alta, baja, recovery)
4.3 Comandos de activación de los modos de
operación.
|
ü CUMPLIÓ
|
|
Equipo 4:
Nestor Iván Torres Gaytán
José Luis Vanoye Bocanegra
José Roberto Jiménez Flores
|
4.4
Manejo de índices.
4.4.1
Tipos de índices
|
ü CUMPLIÓ
|
|
EQUIPOS
|
TEMAS
|
CUMPLIMIENTO
|
|
Equipo 5:
Aylin Amairani Salazar Alvarez
Alberto Sanchez Fonseca
Rolando Leal Arizpe
|
4.4.2 Reorganización de índices
4.4.3 Reconstrucción de índices
|
ü CUMPLIÓ
|
|
Equipo 6:
Nancy Yessenia García Mayorga
Yariseth Lizbeth Guerrero García
Yesenia Lizbeth Guerrero García
Isidro Vidal Ibarra
|
4.1
Bitácoras de trabajo del DBMS
|
ü CUMPLIÓ
|
|
Equipo 7:
Jessica Janet Alanís Ruvalcaba
Zuleica Janet Olguín González
Angel Balleza de León
Jesús Alberto Resendez Mata
|
No
alcanzo tema.
|
ü CUMPLIÓ
|
