UNIDAD 3: Configuración y administración del espacio en disco
Para la gestión del almacenamiento de una base de datos
existen 4 conceptos bien definidos que deben ser conocidos para poder
comprender la forma en la que se almacenan los datos. Vamos a ver la diferencia
entre bloque, extensión, segmento y espacio de tablas.
3.1.- Estructuras lógicas de almacenamiento
Para la gestión del almacenamiento de una base de datos
existen 4 conceptos bien definidos que deben ser conocidos para poder
comprender la forma en la que se almacenan los datos. Vamos a ver la diferencia
entre bloque, extensión, segmento y espacio de tablas.
Bloques: Se tratan de la unidad más pequeña. Generalmente
debe múltiple del tamaño de bloque del sistema operativo, ya que es la unidad
mínima que va a pedir Oracle al sistema operativo. Si no fuera múltiple del
bloque del sistema se añadiría un trabajo extra ya que el sistema debería
obtener más datos de los estrictamente necesarios. Se especifica mediante
DB_BLOCK_SIZE
Extensiones: Se forma con uno o más bloques. Cuando se
aumenta tamaño de un objeto se usa una extensión para incrementar el espacio.
Segmentos: Grupo de extensiones que forman un objeto de la
base de datos, como por ejemplo una tabla o un índice.
Espacio de tablas: Formado por uno o más datafiles, cada
datafile solo puede pertenecer a un determinado tablespace
En general, el almacenamiento de los objetos de la base de
datos (tablas e índices fundamentalmente) no se realiza sobre el archivo o
archivos físicos de la base de datos, sino que se hace a través de estructuras
lógicas de almacenamiento que tienen por debajo a esos archivos físicos, y que
independizan por tanto las sentencias de creación de objetos de las estructuras
físicas de almacenamiento. Esto es útil porque permite que a esos
"espacios de objetos " les sean asociados nuevos dispositivos físicos
(es decir, más espacio en disco) de forma dinámica cuando la base de datos
crece de tamaño más de lo previsto. Posibilita además otra serie de operaciones
como las siguientes:
- Asignar cuotas específicas de espacio a usuarios de la base de datos.
- Controlar la disponibilidad de los datos de la base de datos, poniendo fuera de uso alguno de esos espacios de tablas individualmente.
- Realizar copias de seguridad o recuperaciones parciales de la base de datos.
- Reservar espacio para almacenamiento de datos de forma cooperativa entre distintos dispositivos.
El administrador de la base de datos puede crear o borrar
nuevos espacios lógicos de objetos, añadir o eliminar ficheros físicos de
soporte, utilizados como espacio temporal de trabajo, definir parámetros de
almacenamiento para objetos destinados a ese espacio de datos, todos los
gestores relacionales que venimos introduciendo como ejemplos siguen esta
filosofía.
En el caso de Oracle, sobre los ficheros físicos de datos
(datafiles) se definen los tablespaces. Por lo tanto, una base de datos Oracle
se compone lógicamente de tablcspaccs, y físicamente de datafilcs. Su creación
es sencilla, con la sentencia
GREAT'', TABLESPACE:
CREATE TABLESPACE usuarios DATAFILE `datal.ora' SIZE 50M
También es sencillo ampliar el espacio destinado a un tablespace
utilizando el comando ALTER TABLESPACE:
ALTER TABLESPACE
usuarios ADD DATAFILE 'data2.ora' SIZE 25M
Para hacer más grande una base de datos, las opciones
disponibles son tres:
Cada base de datos contiene un tablespace llamado SYSTEM que
es creado automáticamente al crear la base de datos.
Contiene las tablas del diccionario de datos para la base de
datos en cuestión. Es recomendable no cargar datos de usuario en SYSTEM, para dejarlos
como espacio de objetos del sistema. Si además los datos de usuario están en
tablespaces sitos en otros dispositivos, el rendimiento mejorará porque las
tablas del diccionario de datos se acceden frecuentemente y por lo tanto son un
cuello de botella potencial desde el punto de vista del acceso a disco.
A la hora de estimar el espacio necesario para cl tablespace
sys-nsm hay que tener en cuenta que las unidades de programación PL-SQL
(entorno de programación SQL proporcionado por Oracle) almacenadas en la base
de datos (procedimientos, paquetes, disparos y funciones) almacenan sus datos
en SYSTEM.
De acuerdo con lo comentado anteriormente, tablas e índices
se ubicarán en el tablespaee indicado en el momento de su creación con la
correspondiente sentencia CREATE. Si no se dice nada, se situarán en el
tablespace por defecto asociado al usuario creador.
3.1.1.- Definición de espacio de almacenamiento
Las bases de datos suelen ser creadas para almacenar grandes
cantidades de datos de forma permanente. Por lo general, los datos almacenados
en éstas suelen ser consultados y actualizados constantemente.
La mayoría de las bases de datos se almacenan en las
llamadas memorias secundarias, especialmente discos duros, aunque, en
principio, pueden emplearse también discos ópticos, memorias flash, etc.
Las razones por las cuales las bases de datos se almacenan
en memorias secundarias son:
En cuanto al respaldo de las bases de datos (ver backup),
suelen emplearse tanto discos duros, como cintas magnéticas, discos ópticos o
similares.
Las técnicas empleadas para almacenar bases de datos son
sumamente importantes para la velocidad de acceso y recuperación de datos. Las
técnicas dependen del tipo de almacenamiento, el uso que se le da o se le dará
a la base de datos, la estructura de la misma, el SGBD empleado, etc.
Esta dependencia no significa necesariamente que haya que
cambiar la estructura de la base de datos si se cambian las técnicas empleadas.
Las técnicas de almacenamiento son independientes de la base de datos, pero, de
todas maneras, las mejores técnicas muchas veces pueden determinarse viendo la
estructura de la base de datos, entre otras características.
Los encargados de elegir estas técnicas son los diseñadores
y administradores de bases de datos, y dependen también de las capacidades del
SGBD. En general, el SGBD ofrece diferentes opciones y técnicas para organizar
los datos.
La idea es que los encargados de la base de datos encuentren
las técnicas idóneas, o sea, aquellas que permitan la mayor velocidad posible
de acceso a los datos. Una mala decisión en esta área puede resultar en una
menor velocidad de acceso a la base de datos, o en un uso excesivo del espacio
de almacenamiento, o incluso, puede aumentar la velocidad de consulta de una
base de datos, pero disminuir la velocidad de actualización de la misma.
3.1.2.- Definición y creación del espacio asignado para cada
base de datos
Las bases de datos se almacenan en ficheros o archivos.
Existen diferentes formas de organizaciones primarias de archivos que
determinan la forma en que los registros de un archivo se colocan físicamente
en el disco y, por lo tanto, cómo se accede a éstos.
Las distintas formas de organizaciones primarias de archivos
son:
Existe una segunda forma de acceder a los datos llamada
organización secundaria o estructura de acceso auxiliar. Estas permiten que los
accesos a los registros de un archivo basado en campos alternativos, sean más
eficientes que los que han sido utilizados para la organización primaria de
archivos.
El DBMS asigna espacio de almacenamiento a las bases de
datos cuando los usuarios introducen create database o alter database. El
primero de los comandos puede especificar uno o más dispositivos de base de
datos, junto con la cantidad de espacio en cada uno de ellos que será asignado
a la nueva base de datos.
Si se utiliza la palabra clave default o se omite
completamente la cláusula on , el DBMS pone la base de datos en uno o más de
los dispositivos predeterminados de base de datos especificados en master.sysdevices
Para especificar un tamaño (en este ejemplo, 4MB) para una
base de datos que se va a almacenar en una ubicación predeterminada, utilice on
default = size de esta forma:
create database newpubs
on default = 4
Para situar la base de datos en dispositivos específicos, dé
el nombre del dispositivo o dispositivos en que desea almacenarla. Como la
sintaxis indica, puede solicitar que se almacene en más de un dispositivo de
base de datos, con una cantidad de espacio diferente en cada uno. Todos los
dispositivos mencionados en create database deben estar enumerados en sysdevices.
En otras palabras, deben haberse inicializado con disk init.
La instrucción
siguiente crea la base de datos newdb y asigna 3MB en mydata y 2MB en newdata. Como
en el ejemplo anterior, la base de datos y el diario de transacciones no se
separan:
create database newdb on mydata = 3, newdata = 2
Warning! A menos que cree una base de datos pequeña o que no
sea crucial, sitúe siempre el diario en un dispositivo de base de datos aparte.
Si la cantidad de espacio solicitada a un dispositivo
específico de base de datos no está disponible, el DBMS crea la base de datos
con tanto espacio como sea posible en cada dispositivo y muestra un mensaje
informando el espacio asignado en cada uno. (Esto no se considera un error.) Si
hay menos espacio del mínimo necesario para una base de datos en el dispositivo
especificado (o en el predeterminado, si no se especifica un nombre), el
comando create database falla.
3.1.3.- 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:
Nombre de la transacción que realizó la operación de escritura.
Nombre del dato: El
nombre único del dato escrito.
Valor antiguo: El
valor del dato antes de la escritura.
Valor nuevo: El valor
que tendrá el dato después de la escritura.
Existen otros registros de bitácora especiales para grabar
sucesos importantes durante el proceso de transacción, tales como:
< T1, inicio >
< T1, x, v1,
v2 >
< T1, commit
>
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.
Ejemplo de una bitácora de instrucciones:
CREATE TABLE [dbo].[Bitacora] (
[BitacoraID] [int] IDENTITY (1, 1) NOT NULL ,
[EventType] [char] (14) NOT NULL ,
[Status] [int] NOT NULL ,
[EventInfo] [varchar] (1000) NOT NULL ,
[Usuario] [varchar] (20) NOT NULL ,
[Fecha] [smalldatetime] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Bitacora] WITH NOCHECK ADD
CONSTRAINT [DF_Bitacora_Usuario] DEFAULT (suser_sname()) FOR
[Usuario],
CONSTRAINT [DF_Bitacora_Fecha] DEFAULT (getdate()) FOR
[Fecha]
Y, por otro lado, el trigger en la tabla lo definiría de la
siguiente manera:
/* Trigger de Monitoreo */
CREATE TRIGGER trig_tablabitacora
ON TABLA
FOR DELETE, INSERT, UPDATE
AS
BEGIN
DECLARE @NUMERO INT
INSERT INTO Bitacora (EventType,Status,EventInfo)
exec sp_executesql N’DBCC INPUTBUFFER( @i )’, N’@i int’,
@i=@@spid
END
3.1.4.- Particiones
Una partición es una división de una base de datos lógica o
sus elementos constituyentes en partes independientes. La partición de bases de
datos se hace normalmente por razones de mantenimiento, rendimiento o manejo.
Una aplicación popular y favorable es en un Sistema de
Administración de Base de Datos Distribuida. Cada partición puede ser extendida
hasta múltiples nodos, y los usuarios en el nodo pueden hacer transacciones
locales en la partición. Esto aumenta el rendimiento en sitios que tienen
transacciones regularmente involucrando ciertas vistas de datos, y manteniendo
la disponibilidad y la seguridad.
Esta partición puede hacerse creando bases de datos más
pequeñas separadas (cada una con sus propias tablas, índices, y registros de
transacciones) o dividiendo elementos seleccionados, por ejemplo, solo una
tabla.
Partición horizontal consiste en poner diferentes filas en
diferentes tablas. Por ejemplo, clientes con códigos postales menores que 50000
están almacenados en la tabla ClientesEste, mientras que los clientes con
códigos postales mayores o iguales a 50000 están almacenados en la tabla
ClientesOeste. Las dos tablas de partición son entonces ClientesEste y
ClientesOeste, mientras que una vista con una unión podría ser creada con las
dos tablas para poder dar una vista completa de todos los clientes.
Partición vertical consiste en crear miles de tablas con
miles de columnas y crear tablas para poner las columnas restantes.
Se puede particionar una tabla de 5 maneras diferentes:
Por rango: para construir nuestras particiones especificamos
rangos de valores. Por ejemplo, podríamos segmentar los datos en 12
particiones: una para los contratos de 1950 a 1960, otra para los años 60, los
70, 80, 90, la década del 2000 y la década actual
ALTER TABLE contratos
PARTITION BY RANGE(YEAR(fechaInicio)) (
PARTITION
partDecada50 VALUES LESS THAN (1960),
PARTITION
partDecada60 VALUES LESS THAN (1970),
PARTITION
partDecada70 VALUES LESS THAN (1980),
PARTITION
partDecada80 VALUES LESS THAN (1990),
PARTITION
partDecada90 VALUES LESS THAN (2000),
PARTITION
partDecada00 VALUES LESS THAN (2010),
PARTITION
partDecada10 VALUES LESS THAN MAXVALUE);
Por listas: para construir nuestras particiones especificamos listas de valores concretos.
Por listas: para construir nuestras particiones especificamos listas de valores concretos.
ALTER TABLE contratos
PARTITION BY LIST(YEAR(fechaInicio)) (
PARTITION partDecada50 VALUES IN (1950, 1951, 1952, 1953,
1954, 1955, 1956, 1957, 1958, 1959),
PARTITION partDecada60 VALUES IN (1960, 1961, 1962, 1963,
1964, 1965, 1966, 1967, 1968, 1969),
PARTITION partDecada70 VALUES IN (1970, 1971, 1972, 1973,
1974, 1975, 1976, 1977, 1978, 1979),
PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983,
1984, 1985, 1986, 1987, 1988, 1989),
PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993,
1994, 1995, 1996, 1997, 1998, 1999),
PARTITION partDecada00 VALUES IN (2000, 2001, 2002, 2003,
2004, 2005, 2006,
2007, 2008, 2009),
PARTITION partDecada10 VALUES IN (2010, 2011, 2012, 2013,
2014, 2015, 2016,
2017, 2018, 2019));
Por hash: MySQL se encarga de distribuir las tuplas
automáticamente usando una operación de módulo. Sólo hay que pasarle una
columna o expresión que resulte en un entero (el hash) y el número de particiones
que queramos crear.
ALTER TABLE contratos
PARTITION BY HASH(YEAR(fechaInicio))
PARTITIONS 7;
Por clave: similar a la partición por hash, pero en este
caso no necesitamos pasarle un entero; MySQL utilizará su propia función de
hash para generarlo. Si no se indica ninguna columna a partir de la que generar
el hash, se utiliza la clave primaria por defecto.
ALTER TABLE contratos
PARTITION BY KEY()
PARTITIONS 7;
Compuesta: podemos combinar los distintos métodos de
particionado y crear particiones de particiones
Por último, un pequeño ejemplo de cómo afectaría el
particionado a una consulta sencilla como obtener el número total de tuplas que
cumplen una condición. Estas son las estadísticas de la consulta sin
particionado (ni índices)
EXPLAIN SELECT COUNT(*)
FROM contratos
WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'
select_type
|
table
|
type
|
key
|
rows
|
Extra
|
SIMPLE
|
contratos
|
ALL
|
239796
|
Using where
|
Y este el resultado de añadir las particiones (nótese la
palabra clave PARTITIONS para que nos muestre también la información relativa a
las particiones)
EXPLAIN PARTITIONS SELECT COUNT(*)
FROM contratos
WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'
select_type
|
table
|
partitions
|
type
|
key
|
rows
|
Extra
|
SIMPLE
|
contratos
|
partDecada50
|
ALL
|
8640
|
Using where
|
El número de tuplas que MySQL tiene que comprobar se ve
disminuido en 2 órdenes de magnitud.
3.1.5.- Espacios privados
Un «espacio privado» permite que los administradores y
redactores gestionen el conjunto de datos del sitio. Algunas bases de datos
tienen estos espacios privados llamados comúnmente paneles de control, que son
formularios que aparecen al abrir la base de datos.
Los paneles de control sirven de "puerta
principal" o "recibidor" de una base de datos en el sentido de
que dirigen a las personas hacia determinadas tareas, como introducir o buscar
datos. Sirven también para mantener alejados a los usuarios de las tablas que
contienen los datos en tiempo real.
Cuando reciba una base de datos, debe adentrarse más allá
del panel de control para averiguar cómo están estructurados los datos, pero
merece la pena echar un vistazo inicial al panel de control. Le puede ofrecer
algún indicio sobre las tareas que el diseñador de la base de datos consideró
que realizarían los usuarios habitualmente con los datos.
Puede hacer clic en los vínculos del panel de control para
ver qué objetos, como formularios e informes, abren.
3.1.6.- Espacios para
objetos
Espacios Para Objetos
Los DBMS se basan en archivos para almacenar datos, y estos
archivos, o conjuntos de datos, residen en medios de almacenamiento, o
dispositivos. Una buena parte del trabajo del DBA implicará la planificación
para el almacenamiento real de la base de datos.
Algunas tecnologías de almacenamiento son más adecuadas que
otras. Sin embargo, la naturaleza mecánica de la unidad de disco los hace más
vulnerables al fracaso de los componentes de otro equipo. Además, las formas en
que las unidades de disco son utilizados por las bases de datos pueden hacer
que la gestión del almacenamiento impredecibles, como la barra lateral
"Modern DBMS de uso de disco“ Puede usarse RAID para mejorar la seguridad
de los datos.
Para aplicaciones de misión crítica la integridad de los
datos puede ser más importante que la disponibilidad de datos. Si el soporte es
poco fiable y un fallo de las causas de corrupción de datos, los datos perdidos
puede ser más de un problema que el tiempo de inactividad. Es imperativo, por
tanto, que las soluciones de almacenamiento de base de datos para protegerlos a
toda costa. La recuperación de datos desde medios de almacenamiento lleva mucho
más tiempo en completarse que la recuperación de datos desde la memoria caché o
la memoria.
El rendimiento de la base de datos depende de la entrada y
salida a disco. La cantidad de datos almacenados es mayor que nunca antes, y
los datos se almacenados por más tiempo.
Algunos DBMS permiten al tamaño de los archivos temporales
de expandirse y contraerse de forma automática. Dependiendo del tipo y la
naturaleza de las operaciones de base de datos en proceso, esta fluctuación
puede provocar picos de uso del disco
El crecimiento de la capacidad de almacenamiento aumenta aún
más la complejidad de la gestión de datos y bases de datos. Muchas
organizaciones están implementando nuevas tecnologías de almacenamiento, tales
como almacenamiento en red (NAS) y redes de área de almacenamiento (SAN), para
ayudar a controlar la cantidad cada vez mayor de almacenamiento necesario para
los usos modernos. La gestión del almacenamiento en el entorno dinámico de hoy
es una tarea difícil DBA.
Hay muchos problemas de almacenamiento que deben ser
resueltos antes de que un DBA pueda crear una base de datos. Uno de los temas
más importantes es la cantidad de espacio para permitir la base de datos.
El cálculo espacial debe tener en cuenta no sólo tablas,
índices, sino también, y dependiendo del DBMS, el registro de transacciones.
Cada una de estas entidades probablemente requerirá un archivo separado o
conjunto de datos, para el almacenamiento persistente.
3.2.- Segmentos
Un segmento contiene
un tipo específico de objetos de la base de datos, como por ejemplo una tabla.
Un segmento está compuesto de extensiones que definen el tamaño disponible para
el segmento. A medida que se llenan las extensiones se van añadiendo nuevas
extensiones, es aquel espacio reservado por la base de datos, dentro de un
datafile, para ser utilizado por un solo objeto. Así una tabla (o cualquier
otro objeto) está dentro de su segmento, y nunca podrá salir de él, ya que si
la tabla crece, el segmento también crece con ella.
Físicamente todo objeto en base de datos no es más que un
segmento dentro de un datafile. Se puede decir que, un segmento es a un objeto
de base de datos, lo que un datafile a un tablespace; el segmento es la
representación física del objeto en base de datos (el objeto es solo una
definición lógica).
Los segmentos son los
equivalentes físicos de los objetos que almacenan datos. El uso efectivo de los
segmentos requiere que el DBA conozca los objetos, que utiliza una aplicación,
cómo los datos son introducidos en esos objetos y el modo en que serán
recuperados.
Un segmento está constituido por secciones llamadas
extensiones, que son conjuntos contiguos de bloques. Una vez que una extensión
existente en un segmento no puede almacenar más datos, el segmento obtendrá del
espacio de tabla otra extensión. Este proceso de extensión continuará hasta que
no quede más espacio disponible en los ficheros del espacio de tablas, o hasta
que se alcance un número máximo de extensiones por segmento.
Existen 5 tipos de segmento:
- De datos.
- De índices.
- De rollback.
- Temporales.
- De bootstrap.
3.3.- Memoria Compartida
La memoria compartida contiene todos los datos intervenidos, como:
La memoria compartida contiene todos los datos intervenidos, como:
- Grupo de memorias intermedias
- Tabla de bloqueos
- Memoria intermedia del registro, que contiene las entradas del registro que esperan a ser volcadas en el almacenamiento estable
- Planes de consulta en caché, que se pueden reutilizar si se envía de nuevo la misma consulta
La exclusión mutua se puede implementar por medio de
funciones del sistema operativo llamadas semáforos. Implementaciones
alternativas, con menos sobrecargas, utilizan instrucciones atómicas especiales
soportadas por el hardware de la computadora; un tipo de instrucción atómica
comprueba una posición de la memoria y la establece a uno automáticamente. Los
mecanismos de exclusión mutua también se utilizan para implementar pestillos.
3.4.- Instancias múltiples
Se llama instancia múltiple al hecho de poder ejecutar un
programa más de una vez al mismo tiempo. Hay programas que no admiten más que
una sola instancia, es decir que si ya se está ejecutando, por más que lo
cliquees de nuevo en el icono o en el menú no aparecerá un nuevo ejemplar del
programa. Con las bases de datos se complica un poco porque si un usuario
modifica un registro que otro usuario tiene también abierto, la modificación
que se haga en una instancia debe reflejarse de inmediato (actualizarse) en
cualquier otra instancia abierta de la misma base de datos.
Sin embargo, en las bases de datos se puede seleccionar la
opción en el diseño de la BD, y se reflejarán de inmediato las modificaciones
en todas las instancias abiertas
En programación, una instancia se produce con la creación de
un objeto perteneciente a una clase (se dice que se instancia la clase). El
objeto que se crea tiene los atributos, propiedades y métodos de la clase a la
que pertenece. Los objetos y sus características se usan en la construcción de
programas, ya sea como contenedores de datos o como partes funcionales del
programa. Los objetos también puede ser ocurrencia de las clases.
UNIDAD 4: Operación y mantenibilidad
4.1.- Bitácoras de Trabajo del DBMS
Una bitácora es una herramienta (archivos o registros) que
permite registrar, analizar, detectar y notificar eventos que sucedan en
cualquier sistema de información utilizado en las organizaciones.
La estructura más ampliamente usada para grabar las acciones
que se llevan en la base de datos.
Nos ayuda a recuperar la información ante algunos incidentes
de seguridad, detección de comportamiento inusual, información para resolver
problemas, evidencia legal, es de gran ayuda en las tareas de computo forense.
Permite guardar las transacciones realizadas sobre una base
de datos en específico, de tal manera que estas transacciones puedan ser
auditadas y analizadas posteriormente.
4.1.1.- Funciones Específicas 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 comprometen o anulan todas las modificaciones realizadas
por el programa desde el punto de sincronización anterior.
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.
4.1.2.- Recuperación (Rollback)
En tecnologías de base de datos, un rollback 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 (RDBMS), para
que el estado de los datos sea "rolled back"(devuelto) a la forma en
que estaba antes de que aquellos cambios tuvieran lugar.
Una sentencia ROLLBACK también publicará cualquier savepoint
existente que puediera estar en uso.
En muchos dialectos de SQL, los ROLLBACK son específicos de
la conexión. Esto significa que si se hicieron dos conexiones a la misma base
de datos, un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras
conexiones. Esto es vital para el buen funcionamiento de la concurrencia.
La funcionalidad de rollback está normalmente implementada
con un Log de transacciones, pero puede también estar implementada mediante
control de concurrencia multiversión.
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.
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
publicará 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.
4.2.- Definición de los Modos de Operación de un DBMS (Alta,
Baja, Recovery)
La vida de todo archivo comienza cuando se crea y acaba
cuando se borra. Durante su existencia es objeto de constante procesamiento,
que con mucha frecuencia incluye acciones de consulta o búsqueda y de
actualización. En el caso de la estructura archivos, entenderemos como
actualización, además de las operaciones, vistas para vectores y listas
enlazadas, de introducir nuevos datos (altas) o de eliminar alguno existente
(bajas), la modificación de datos ya existentes, (operación muy común con datos
almacenados). En esencia, es la puesta al día de los datos del archivo.
Una operación de alta en un archivo consiste en la adición
de un nuevo registro. En un archivo de empleados, un alta consistirá en
introducir los datos de un nuevo empleado. Para situar correctamente un alta,
se deberá conocer la posición donde se desea almacenar el registro
correspondiente: al principio, en el interior o al final de un archivo.
El algoritmo de ALTAS debe contemplar la comprobación de que
el registro a dar de alta no existe previamente. Una baja es la acción de eliminar
un registro de un archivo. La baja de un registro puede ser lógica o física.
Una baja lógica supone el no borrado del registro en el archivo. Esta baja
lógica se manifiesta en un determinado campo del registro con una bandera,
indicador o “flag” -carácter *. $, etc.,-, o bien con la escritura o rellenado
de espacios en blanco en el registro dado de baja
- Altas
La operación de dar de alta un determinado registro es
similar a la de añadir datos a un archivo. Es importante remarcar que en un
archivo secuencial sólo permite añadir datos al final del mismo.
En otro caso, si se quiere insertar un registro en medio de
los ya presentes en el archivo, sería necesaria la creación nueva del archivo.
El algoritmo para dar de alta un registro al final del
fichero es:
- algoritmo altas
- leer registro de alta
- inicio
- abrir archivo para añadir
- mientras haya más registros hacer {algunos lenguajes ahorran este bucle}
- leer datos del registro
- fin_mientras
- escribir (grabar) registro de alta en el archivo
- cerrar archivo
- fin
- Bajas
Existen dos métodos para dar de baja a un registro en un
archivo secuencial, donde no es fácil eliminar un registro situado en el
interior de una secuencia: Para ello podemos seguir dos métodos:
1) Utilizar y por tanto crear un segundo archivo auxiliar
transitorio, también secuencial, copia del que se trata de actualizar. Se lee
el archivo completo registro a registro y en función de su lectura se decide si
el registro se debe dar de baja o no. En caso afirmativo, se omite la escritura
en el archivo auxiliar. Si el registro no se va a dar de baja, este registro se
reescribe en el archivo auxiliar
Tras terminar la lectura del archivo original, se tendrán
dos archivos: original (o maestro) y auxiliar. El proceso de bajas del archivo
concluye borrando el archivo original y cambiando el nombre del archivo
auxiliar por el del inicial.
2) Guardar o señalar los registros que se desean dar de baja
con un indicador o bandera que se guarda en un array; de esta forma los
registros no son borrados físicamente, sino que son considerados como
inexistentes.
Inevitablemente, cada cierto tiempo, habrá que crear un
nuevo archivo secuencial con el mismo nombre, en el que los registros marcados
no se grabarán.
Propósito de Backup y Recuperación
Como administrador de copia de seguridad, la tarea principal
es diseñar, implementar y gestionar una estrategia de backup y recuperación. En
general, el propósito de una estrategia de recuperación de copia de seguridad y
es para proteger la base de datos contra la pérdida de datos y reconstruir la
base de datos después de la pérdida de datos. Normalmente, las tareas de
administración de seguridad son las siguientes:
- Planificación y probar las respuestas a diferentes tipos de fallas.
- Configuración del entorno de base de datos de copia de seguridad y recuperación.
- La creación de un programa de copia de seguridad
- Seguimiento de la copia de seguridad y entorno de recuperación
- Solución de problemas de copia de seguridad
- Para recuperarse de la pérdida de datos en caso de necesidad
Como administrador de copia de seguridad, es posible que se
le pida que realice otros deberes que se relacionan con copia de seguridad y
recuperación:
- La preservación de datos, lo que implica la creación de una copia de base de datos para el almacenamiento a largo plazo
- La transferencia de datos, lo que implica el movimiento de datos de una base de datos o un host a otro.
4.3.- Comandos de Activación para 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 sesion).
- 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 hara roolback
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á roolback 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.
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.
Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre aquellos
campos sobre los cuáles se hacen búsquedas frecuentes.
4.4.1.- Tipos de Índices
Índices Compuestos
Un índice compuesto, también llamado índice concatenado, 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.
Los índices compuestos pueden acelerar la recuperación de
datos para las instrucciones SELECT en la que el DONDE referencias cláusula
totalidad o la parte principal de las columnas en el índice compuesto. Por lo
tanto, el orden de las columnas utilizadas en la definición es importante. En
general, las columnas de acceso más común van primero.
Índices Únicos y no Únicos
Los índices pueden ser únicos o no únicos. Índices únicos
garantizar que no hay dos filas de una tabla tienen valores duplicados en la
columna de clave o columna. Por ejemplo, dos empleados no pueden tener el mismo
ID de empleado. Por lo tanto, en un índice único, existe una ROWID para cada
valor de datos. Los datos de los bloques de hojas se ordenan sólo por clave.
Índices no únicas permiten valores duplicados en la columna
o columnas indexadas. Por ejemplo, la columna 'nombre de la tabla de empleados
puede contener varios valores Mike. Para un índice no único, el ROWID se
incluye en la clave de forma ordenada, por lo que los índices no únicos se
ordenan por la clave de índice y ROWID (ascendente).
Tipos de Índices
- Los Índices de Árbol B
Estos índices son el tipo de índice estándar. Son excelentes
para la clave principal y los índices altamente selectivos. Utilizado como
índices concatenados, B-tree índice pueden recuperar los datos ordenados por
las columnas de índice. Índices B-tree tienen los siguientes subtipos:
- Índice de Tablas Organizadas
Una tabla de índice-organizada difiere de un
montón-organizado porque los datos es en sí mismo el índice.
En este tipo de índice, los bytes de la clave de índice se
invierten, por ejemplo, 103 se almacena como 301. La inversión de bytes
extiende inserta en el índice durante muchos bloques.
- Índices Descendentes
Este tipo de índice almacena los datos en una columna o
columnas de concreto en orden descendente.
- Índices B-Tree de Racimo
Este tipo de índice se utiliza para indexar una clave de
clúster tabla. En lugar de apuntar a una fila, los puntos clave para el bloque
que contiene filas relacionadas con la clave de clúster.
- Mapa de Bits y los Índices Bitmap Join
En un índice de mapa de bits, una entrada de índice utiliza
un mapa de bits para que apunte a varias filas. En cambio, los puntos de
entrada de un índice B-tree en una sola fila. Un índice de combinación de mapa
de bits es un índice de mapa de bits para la unión de dos o más tablas.
Consulte "Indicadores de mapa de bits".
- Índices Basados en Funciones
Este tipo de índice incluye columnas que, o bien se
transforman por una función, tales como la función UPPER, o incluidos en una
expresión. Índices B-tree o mapa de bits puede ser basado en las funciones.
- Índices de Dominio de Aplicación
Este tipo de índice se crea por un usuario para los datos en
un dominio específico de la aplicación. El índice físico no tiene que utilizar
una estructura de índice tradicional y se puede almacenar ya sea en la base de
datos Oracle como tablas o externamente como un archivo. Consulte
"Indicadores de dominio de aplicación".
- Índices B-Tree
Árboles B, abreviatura de árboles balanceados, son el tipo
más común de índice de base de datos. Un índice B-tree es una lista ordenada de
valores dividida en rangos. Mediante la asociación de una tecla con una fila o
rango de filas, los árboles B proporcionan un excelente rendimiento de la
recuperación para una amplia gama de consultas, incluyendo coincidencia exacta
y búsquedas por rango.
4.4.2.- Reorganización de Índices.
Un factor clave para conseguir una E/S de disco mínima para
todas las consultas de bases de datos es asegurarse de que se creen y se
mantengan buenos índices. Una vez creados los índices, se debe procurar
mantenerlos para asegurarse que sigan trabajando en forma óptima. A medida que
se agregan, modifican o borran datos se produce fragmentación. Esta
fragmentación puede ser buena o mala para el rendimiento del sistema,
dependiendo de las necesidades del trabajo de la base de datos.
Fragmentación de los Índices
La fragmentación es consecuencia de los procesos de
modificación de los datos (instrucciones INSERT, UPDATE y DELETE) efectuados en
la tabla y en los índices definidos en la tabla. Como dichas modificaciones no
suelen estar distribuidas de forma equilibrada entre las filas de la tabla y
los índices, el llenado de cada página puede variar con el paso del tiempo.
Para las consultas que recorren parcial o totalmente los índices de una tabla,
este tipo de fragmentación puede producir lecturas de páginas adicionales. Esto
impide el recorrido paralelo de los datos. Existen dos tipos de fragmentación:
Interna: Fragmentación dentro de páginas individuales de
datos e índices con espacios libres que generan la necesidad de más operaciones
de E/S y más memoria para su lectura. Este hecho disminuye el rendimiento en
ambientes de lectura, pero en algunos casos puede beneficiar las inserciones,
que no requieren una división de páginas con tanta frecuencia.
Externa: Cuando el orden lógico de las páginas no es correcto,
porque las páginas no son contiguas. El acceso a los datos es mucho más lento
por la necesidad de búsqueda de los datos.
La fragmentación de índices se puede reparar reorganizando
un índice o reconstruyéndolo. Para los índices fraccionados que fueron construidos
en una estructura partida se puede usar cualquiera de estos métodos o bien en
un índice completo o bien en un único fragmento del índice.
Detección de Fragmentación
El primer paso para decidir qué método de desfragmentación
se va a utilizar consiste en analizar el índice para determinar el nivel de
fragmentación. Si se usa la función del sistema sys.dm_db_index_physical_stats,
se puede detectar la fragmentación de los índices de la base de datos
thuban-homologada.
La grilla de resultados emitida por la anterior sentencia
incluye las siguientes columnas:
Una vez que se toma conciencia del nivel de fragmentación,
se debe utilizar la tabla a continuación para determinar el mejor método para
su corrección.
La reconstrucción del índice puede ejecutarse tanto en línea
como fuera de línea. La reorganización de los índices debe ejecutarse siempre
en línea. Para adquirir una disponibilidad similar a la de la opción de
reorganización, los índices deben ser reconstruidos en línea.
Estos valores proveen una estricta guía para determinar el
punto en el que se debe cambiar de ALTER INDEX REORGANIZE a ALTER INDEX
REBUILD.
Los niveles muy bajos de fragmentación (menores que el 5 por
ciento) no deben ser corregidos por ninguno de estos comandos porque el beneficio
de la remoción de una cantidad tan pequeña de fragmentación es casi siempre
superado ampliamente por el costo de reorganización o reconstrucción de
índices.
Reorganización de Índices
Para reorganizar uno o más índices se debe usar la sentencia
ALTER INDEX con la cláusula REORGANIZE. Por ejemplo:
ALTER INDEX PK_LOGS ON THUBAN_LOGS REORGANIZE
El proceso de reorganización de índices se realiza siempre
en línea y el consumo de recursos es bajo por lo que no mantiene bloqueos por
mucho tiempo.
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 éste han sido accedidas con
mayor frecuencia que otras. Como resultado de este suceso podemos obtener
problemas de contención de disco o cuellos de botella en el sistema.
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.
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.
ALTER INDEX <index_name> REBUILD;
Para reconstruir una partición de un índice podríamos hacer lo
siguiente:
ALTER INDEX <index_name> REBUILD PARTITION
<nb_partition> NOLOGGING;
