ABD - U3-Mysql5 - 7

Ingeniería en Sistemas Computacionales Administración de Bases de Datos
Unidad 3. Configuración y administración del espacio en disco.

3.1 Estructuras lógicas de almacenamiento
3.1.1. Definición de espacio de almacenamiento
3.1.2. Definición y creación del espacio asignado para cada base de datos
3.1.3. Bitácoras
3.1.4 Particiones
3.1.5 Espacios privados
3.1.6 Espacios para objetos
3.2. Segmentos
3.3. Memoria Compartida.
3.4. Instancias múltiples
3.1 Estructuras lógicas de almacenamiento

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 general, las bases de datos son demasiado grandes para entrar en la memoria primaria.
 La memoria secundaria suele ser más barata que la memoria primaria (aunque esta última tiene
mayor velocidad).
 La memoria secundaria es más útil para el almacenamiento de datos permanente, puesto que la
memoria primaria es volátil.
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 ser un múltiplo 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 el 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 archivos 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 tablespaces, y físicamente de datafiles. Su creación es sencilla, con la sentencia CREAT
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 situados en otros dispositivos, el
rendimiento decaerá 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 tablespace 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.
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.
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.
Las distintas formas de organizaciones primarias de archivos son:
 Archivos de Montículos (o no Ordenados): esta técnica coloca los registros en el disco sin un
orden específico, añadiendo nuevos registros al final del archivo.
 Archivos Ordenados (o Secuenciales): mantiene el orden de los registros con respecto a algún
valor de algún campo (clave de ordenación).
 Archivos de Direccionamiento Calculado: utilizan una función de direccionamiento calculado

aplicada a un campo específico para determinar la colocación de los registros en disco.
 Árboles B: se vale de la estructura de árbol para las colocaciones de registros.
 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 (por ejemplo, 4MB) para una base de datos que se va a almacenar en una
ubicación predeterminada, se utiliza: 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.
Es una herramienta que permite registrar, analizar, detectar y notificar eventos que suceden en
cualquier sistema de información utilizado en las organizaciones.
La información contenida en una bitácora es muy importante y útil cuando ocurre cualquiera de las
siguientes situaciones:
 Incidentes de seguridad.
 Al realizar una auditoría de sistemas.
 Al presentarse un comportamiento inusual de la información.
 Si se presenta algún problema, la información de la bitácora puede ayudar a resolverlos.
 Si se requiere información que sirva de evidencia legal.
Una bitácora es de gran ayuda en las tareas de cómputo forense.
Una bitácora también 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.
La bitácora puede registrar datos específicos de una transacción como son:
 El nombre de la transacción u operación que se realizó (por ejemplo: INSERT, UPDATE o

DELETE).
 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.
 Fecha y hora de la transacción.
 Usuario de la BD que realizó la transacción.
 Equipo o host donde se realizó.
 El programa o aplicación que realizó la transacción.
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, es decir guardar los valores antiguos.
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 creación de una bitácora en MySQL
Enseguida plantearé un ejemplo de una bitácora desarrollada para la siguiente base de datos de MySQL,
llamada proyecto, que tiene las tablas carrera, departamento y maestros.
CREATE DATABASE proyecto;
USE proyecto;
CREATE TABLE IF NOT EXISTS `carrera` (`clave_carrera` int(11) NOT NULL, `nom_carrera` varchar(20) NOT
NULL, `num_depto` int(11) NOT NULL, PRIMARY KEY (`clave_carrera`), KEY `num_depto` (`num_depto`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `departamento` ( `num_departamento` int(11) NOT NULL,`nombre_dept` varchar(20)
NOT NULL, `jefe_num_tarjet` int(11) NOT NULL, PRIMARY KEY (`num_departamento`), KEY `jefe_num_tarjet`
(`jefe_num_tarjet`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `maestros` (`num_tarjeta` int(11) NOT NULL DEFAULT 0,`nombre` varchar(50)
DEFAULT NULL, PRIMARY KEY (`num_tarjeta`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;
La estructura de la tabla bitácora sería la siguiente:

/* Script para crear la tabla bitácora_carr */
CREATE TABLE IF NOT EXISTS `bitacora_carr` (

ìd` int(11) NOT NULL AUTO_INCREMENT,
òperacion` varchar(10) DEFAULT NULL,
ùsuario` varchar(40) DEFAULT NULL,
`host` varchar(30) NOT NULL,
`modificado` datetime DEFAULT NULL,
`tabla` varchar(40) NOT NULL,
òldclavecarr` int(11) DEFAULT NULL,
òldnomcarr` varchar(20) DEFAULT NULL,
òldnumdepto` int(11) DEFAULT NULL,
`newclavecarr` int(11) DEFAULT NULL,
`newnomcarr` varchar(20) DEFAULT NULL,
`newnumdepto` int(11) DEFAULT NULL,
PRIMARY KEY (ìd`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
La bitácora debe registrar todos los movimientos (insertar, eliminar y modificar) que se realicen en las
tablas de la base de datos además de conservar los valores anteriores cuando son sustituidos por valores
nuevos. Para lograr lo anterior es necesario crear un trigger para que se ejecute después de la operación
de insertar, otro para después de eliminar y el último para después de modificar para cada una de las 3
tablas de la base de datos. Los tres triggers necesarios para que funcione la bitácora con la tabla carrera
son los siguientes (Se le deja al alumno como ejercicio que elabore los demás triggers para las tablas
departamento y maestros) :
/* Triger INSERT para la Tabla carrera */
DROP TRIGGER IF EXISTS `bit_carr_ins`;

CREATE DEFINER=`root`@`localhost` TRIGGER `bit_carr_ins` AFTER INSERT ON `carrera`
FOR EACH ROW
INSERT INTO `proyecto`.`bitacora_carr` (òperacion`, ùsuario`, `host`, `modificado`,
`tabla`, òldclavecarr`, òldnomcarr`, òldnumdepto`, `newclavecarr`, `newnomcarr`,
`newnumdepto`) VALUES ('INSERTAR', SUBSTRING(USER(),1,(INSTR(USER(),'@')-1)),
SUBSTRING(USER(),(INSTR(USER(),'@')+1)), NOW(), 'carrera', NULL, NULL, NULL,
NEW.clave_carrera, NEW.nom_carrera, NEW.num_depto)
/* Triger DELETE para la Tabla carrera */
DROP TRIGGER IF EXISTS `bit_carr_del`;CREATE DEFINER=`root`@`localhost` TRIGGER

`bit_carr_del` AFTER DELETE ON `carrera` FOR EACH ROW

`newnumdepto`) VALUES ('ELIMINAR', SUBSTRING(USER(),1,(INSTR(USER(),'@')-1)),
SUBSTRING(USER(),(INSTR(USER(),'@')+1)), NOW(), 'carrera', OLD.clave_carrera,
OLD.nom_carrera, OLD.num_depto, NULL, NULL, NULL)
/* Triger UPDATE para la Tabla carrera */
DROP TRIGGER IF EXISTS `bit_carr_upd`;

CREATE DEFINER=`root`@`localhost` TRIGGER `bit_carr_upd` AFTER UPDATE ON `carrera`
FOR EACH ROW

`newnumdepto`) VALUES ('ACTUALIZAR', SUBSTRING(USER(),1,(INSTR(USER(),'@')-1)),
SUBSTRING(USER(),(INSTR(USER(),'@')+1)), NOW(), 'carrera', OLD.clave_carrera,
OLD.nom_carrera, OLD.num_depto, NEW.clave_carrera, NEW.nom_carrera, NEW.num_depto)
Ahora lo correspondiente par la table departamento:
/* Script para crear la tabla bitacora_depto */
CREATE TABLE IF NOT EXISTS `bitacora_depto` (
òldnum_departamento` int(11) DEFAULT NULL,
òldnombre_dept` varchar(20) DEFAULT NULL,
òldjefe_num_tarjet` int(11) DEFAULT NULL,
`newnum_departamento` int(11) DEFAULT NULL,
`newnombre_dept` varchar(20) DEFAULT NULL,
`newnum_departamento` int(11) DEFAULT NULL,
PRIMARY KEY (ìd`)

/* Triger INSERT para la Tabla departamento */
DROP TRIGGER IF EXISTS `bit_depto_ins`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_ins` AFTER INSERT ON

`departamento` FOR EACH ROW
INSERT INTO `proyecto`.`bitacora_depto`
(òperacion`, ùsuario`, `host`, `modificado`, `tabla`, òldnum_departamento`,

òldnombre_dept`, òldjefe_num_tarjet`, `newnum_departamento`, `newnombre_dept`,
`newnum_departamento`) VALUES ('INSERTAR', SUBSTRING(USER(),1,(INSTR(USER(),'@')-1)),
SUBSTRING(USER(),(INSTR(USER(),'@')+1)), NOW(), 'departamento', NULL, NULL, NULL,
NEW.num_departamento, NEW.nombre_dept, NEW.jefe_num_tarjet)
/* Triger DELETE para la Tabla departamento */
DROP TRIGGER IF EXISTS `bit_depto_del`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_del` AFTER DELETE ON


`newnum_departamento`) VALUES (VALUES ('ELIMINAR',
SUBSTRING(USER(),1,(INSTR(USER(),'@')-1)), SUBSTRING(USER(),(INSTR(USER(),'@')+1)),
NOW(), departamento, OLD.num_departamento, OLD.nombre_dept, OLD.jefe_num_tarjet,
NULL, NULL, NULL)
/* Triger UPDATE para la Tabla departamento */
DROP TRIGGER IF EXISTS `bit_depto_upd`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_upd` AFTER UPDATE ON


`newnum_departamento`) VALUES ('ACTUALIZAR', SUBSTRING(USER(),1,(INSTR(USER(),'@')-
1)), SUBSTRING(USER(),(INSTR(USER(),'@')+1)), NOW(), departamento,
OLD.num_departamento, OLD.nombre_dept, OLD.jefe_num_tarjet, NEW.num_departamento,
NEW.nombre_dept, NEW.jefe_num_tarjet)
/* Script para crear la tabla bitacora_maestros */
CREATE TABLE IF NOT EXISTS `bitacora_maestros` (
òldnum_tarjeta` int(11) DEFAULT NULL,
òldnombre` varchar(20) DEFAULT NULL,
`newnum_tarjeta` int(11) DEFAULT NULL,
`newnombre` varchar(20) DEFAULT NULL,
PRIMARY KEY (ìd`)
/* Triger INSERT para la Tabla maestros */
DROP TRIGGER IF EXISTS `bit_maestros_ins`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_maestros_ins` AFTER INSERT ON

`maestros` FOR EACH ROW
INSERT INTO `proyecto`.`bitacora_maestros`
(òperacion`, ùsuario`, `host`, `modificado`, `tabla`, òldnum_tarjeta`,

òldnombre`, `newnum_tarjeta`, `newnombre`) VALUES ('INSERTAR',
NOW(), 'maestros', NULL, NULL, NEW.num_tarjeta, NEW.nombre)
/* Triger DELETE para la Tabla maestros */
DROP TRIGGER IF EXISTS `bit_maestros_del`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_maestros_del` AFTER DELETE ON


òldnombre`, `newnum_tarjeta`, `newnombre`) VALUES ('ELIMINAR',
NOW(), 'maestros', OLD.num_tarjeta, OLD.nombre, NULL, NULL)
/* Triger UPDATE para la Tabla maestros */
DROP TRIGGER IF EXISTS `bit_maestros_upd`;
CREATE DEFINER=`root`@`localhost` TRIGGER `bit_maestros_upd` AFTER UPDATE ON


òldnombre`, `newnum_tarjeta`, `newnombre`) VALUES ('ACTUALIZAR',
NOW(), 'maestros', OLD.num_tarjeta, OLD.nombre, NEW.num_tarjeta, NEW.nombre)
3.1.4 Particiones
Cuando alguna de las tablas de una base de datos llega a crecer tanto que el rendimiento empieza a ser
un problema, es hora de empezar a conocer algo sobre optimización. Una característica de MySQL son
las particiones.
Particionar tablas en MySQL nos permite rotar la información de nuestras tablas en diferentes
particiones, consiguiendo así realizar consultas más rápidas y recuperar espacio en disco al borrar los
registros. El uso más común de particionado es según la fecha.
Para ver si nuestra base de datos soporta particionado simplemente ejecutamos:
SHOW VARIABLES LIKE '%partition%';
En el siguiente ejercicio debe crear y pone en uso la siguiente base de datos:
CREATE DATABSE industria;
USE industria;
Se puede particionar una tabla de 5 maneras diferentes:

Por Rango: para construir las particiones se especifican rangos de valores.
CREATE TABLE IF NOT EXISTS èmpleados` (
ìd` int(11) NOT NULL,

Àpellido` varchar(30) DEFAULT NULL,
`Nombre` varchar(30) DEFAULT NULL,
èntrada` date NOT NULL DEFAULT '1970-01-01',
`renuncia` date NOT NULL DEFAULT '9999-12-31',
`job_code` int(11) DEFAULT NULL,
`store_id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (year(renuncia)) (
PARTITION p0 VALUES LESS THAN (1991) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN MAXVALUE ENGINE = InnoDB
);
La última partición (partDefault) tendrá todos los registros que no entren en las particiones anteriores.
De esta manera nos aseguramos que la información nunca dejará de insertarse en la tabla.
Por Listas: para construir nuestras particiones especificamos listas de valores concretos.
ALTER TABLE contratos
PARTITION BY LIST (YEAR (fechaInicio)) (
PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988, 1989),
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.
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.

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.
Borrar Particiones
Lo bueno de trabajar con particiones es que podemos borrar rápidamente registros sin tener que
recorrer toda la tabla e inmediatamente recuperar el espacio en disco utilizado por la tabla.
Por ejemplo si queremos borrar la partición más antigua simplemente ejecutamos:
ALTER TABLE reports DROP PARTITION p201111;
Añadir particiones
En el ejemplo anterior las 2 últimas particiones creadas han sido:
PARTITION p201205 VALUES LESS THAN (TO_DAYS ("2012-06-01")),
PARTITION pDefault VALUES LESS THAN MAXVALUE
El problema es que todos los INSERT que se hagan después de mayo de 2012 se insertarán en pDefault.
La solución sería añadir particiones nuevas para cubrir los próximos meses:
ALTER TABLE reports REORGANIZE PARTITION pDefault INTO (
PARTITION p201206 VALUES LESS THAN (TO_DAYS ("2012-07-01")),
PARTITION pDefault VALUES LESS THAN MAXVALUE);
En el caso que no tuviéramos una partición del tipo pDefault simplemente ejecutamos:
ALTER TABLE reports ADD PARTITION (PARTITION p201206 VALUES LESS THAN (TO_DAYS ("2012-07-
01")));
Ejemplo de añadir una partición por key a una tabla en mysql:
Primero se muestra el script de la tabla sin partición.
SHOW CREATE TABLE folio;
Se agrega con ALTER TABLE la partición por key en la tabla folio:
Se vuelve a mostrar la estructura de la tabla

SHOW CREATE TABLE folio;
Y se observa que la tabla ya quedo particionada por key.

Consultar Particiones
Para consultar información de particiones creadas en una tabla así como también los registros que
contiene cada una ejecutamos:
SELECT PARTITION_NAME, TABLE_ROWS FROM information_schema. PARTITIONS
WHERE TABLE_NAME = 'reports';
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 se recibe una base de datos, se averiguar cómo están estructurados los datos, revisar de manera
general el panel de control. 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.
3.1.6. 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.
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 son 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.
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.
El DBA debe separar en diferentes discos a los archivos para:
 Mejorar el rendimiento
 Separar índices de datos
 Aislar los logros en otro disco
3.2 Segmentos
Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima unidad de espacio físico, y
es un múltiplo del bloque del SO (2 Kb usualmente). El tamaño del bloque Oracle se fija por el parámetro
DB_BLOCK_SIZE del fichero init.ora. Un tamaño grande de bloque mejora la eficiencia del cache de E/S,
pero el tamaño de la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa un
problema de memoria.
Una serie de bloques contiguos es una extensión, que es una unidad lógica de almacenamiento. Una
serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensión en su
segmento. Cuando el objeto crezca, necesitará más espacio y se reservarán más extensiones.
Cada segmento tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:
initial: tamaño de la extensión inicial (10k).
next: tamaño de la siguiente extensión a asignar (10k).
minextents: número de extensiones asignadas en el momento de la creación del segmento (1).
maxextents: número máximo de extensiones (99).
pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con
la última extensión utilizada (50).
pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque
asignado al segmento (10).
pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede
ser utilizado para insertar filas nuevas en él.
tablespace: nombre del espacio de tablas donde se creará el segmento.
Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el
crecimiento de las tablas. A continuación se hacen algunas consideraciones sobre la gestión del espacio
para los diferentes segmentos.
Segmentos de Datos
El espacio del diccionario de datos se suele mantener más o menos constante, aunque es crítico que
tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. Así, hay que tener cuidado de
colocar las tablas de usuario, los índices, segmentos temporales y los segmentos de rollback en otros
espacios de tablas.
Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de su espacio disponible.
Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas
SYSTEM.
Las tablas crecen proporcionalmente con el número de filas, ya que se puede suponer que la longitud de
las filas es constante.
Segmentos de Índice
Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los datos en la tabla son
modificados frecuentemente. La gestión del espacio es mejor si se mantienen los índices de tablas
grandes en espacios de tablas separados.
Segmentos de Rollback
Los segmentos de rollback almacenan la imagen anterior a una modificación de un bloque. La
información en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el
valor en el segmento de rollback se copia en el bloque de datos) y la recuperación.
Es importante comprender cuál es el contenido de un segmento de rollback. No almacenan el bloque de
datos modificado entero, sólo la imagen previa de la fila o filas modificadas. La información del
segmento de roolback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en
una tabla, el undo necesitará sólo el rowid de la fila insertada, ya que para volver atrás la insercion sólo
hay que realizar un delete. En la operación de actualización, se almacenará el valor antiguo de las
columnas modificadas. El segmento de rollback asegura que la información undo se guardan durante la
vida de la transacción.
Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin
embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este último las
extensiones se utilizan de manera circular. Así, habrá que tener cuidado a la hora de fijar el tamaño del
segmento de rollback para que la cabeza no pille a la cola.
Segmentos Temporales
Los segmentos temporales se crean cuando se efectúan las siguientes operaciones:
Create Index
Select con distinct, order by, union, intersect y minus.
uniones no indexadas.
Ciertas subconsultas correlacionadas.
Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal, pero si la tabla es
grande se realiza en disco. El parámetro SORT_AREA_SIZE determina el lugar donde se hace la
ordenación. Incrementándole se reduce la creación de segmentos temporales.
3.3 Definición de Memoria Compartida

Un servidor Oracle es un sistema que permite administrar bases de datos y que ofrece un medio de
gestión de información abierto, completo e integrado.
Un servidor Oracle está constituido de una instancia y una base de datos.

Instancia de Oracle
Una instancia de Oracle permite acceder a la base de datos Oracle y permite abrir únicamente una sola
base de datos.
La instancia de Oracle está compuesta de:
Procesos en segundo plano que administran y aplican las relaciones entre las estructuras físicas y las
estructuras de memoria. Existen dos categorías:
 Procesos en Segundo Plano Obligatorios: DBWN, PMON, CKPT, LGWR, SMON

 Procesos en Segundo Plano Facultativos: ARCn, LMDn, RECO, CJQ0, LMON, Snnn, Dnnn, Pnnn,
LCKn, QMNn
Estructuras de Memoria: compuestas básicamente de dos áreas de memoria: el área de memoria
asignada a la SGA (System Global Area): asignada al inicio de la instancia y representa un componente
fundamental de una instancia de Oracle.
Está compuesta de varias áreas de memoria:
Área de memoria compartida
Buffer caché de la base de datos
Log buffer
Así como otras estructuras para la gestión de bloqueos externos (lock), internos (match), datos
estadísticos, etc.
Eventualmente también es posible configurar al nivel de la SGA
Área de memoria LARGE POOL
Área de memoria Java
Área de Memoria Asignada a la PGA (Program Global Area): Ésta es asignada al inicio del proceso de
servidor. Es reservada a cada proceso de usuario que se conecte a la base de datos Oracle y liberada al
final del proceso.
El Proceso de Usuario: Es el programa que solicita una interacción con la base de datos iniciando una
conexión. Se comunica únicamente con el proceso de servidor correspondiente.
El Proceso de Servidor
Representa el programa que entra directamente en interacción con el servidor Oracle. Responde a todas
las peticiones y envía los resultados. Puede estar dedicado a un servidor cliente o compartido por varios.
3.4 Definición de Múltiples Instancias de un DBMS

Cuando comenzamos a trabajar con Oracle una de las primeras cosas que aprendemos es a diferenciar
entre estos conceptos: base de datos, instancia e instancia de base de datos.
Una instancia es el conjunto de procesos que se ejecutan en el servidor así como la memoria que
comparten para ello.
Cuando se habla de base de datos, nos referimos a los archivos físicos que componen nuestra base de
datos.
Si queremos referirnos a los procesos que se ejecutan en memoria como a los archivos de base de datos
tendremos que utilizar el término instancia de base de datos.
La instancia en Oracle describe varios procesos residentes en la memoria del computador(es) y un área
de memoria compartida por aquellos procesos. En arquitecturas de bases de datos tales como, Microsoft
SQL Server e IBM BD2, la palabra instancia indica una colección de bases de datos que comparten
recursos de memoria en común, o sea, la relación entre instancia y bases de datos es 1 a N. Pero la
relación entre la instancia de Oracle y la base de datos es 1 a 1 o n a 1. Cuando hay una relación N a 1, la
configuración es llamada RAC (Real Application CLuster), donde la base de datos reside en discos
compartidos y las instancias en múltiples computadores anexados a la base de datos.
La instancia de Oracle es el motor que procesa los requerimientos de datos desde la base de datos. Está
compuesta por procesos en primer plano, en segundo plano y un área de memoria compartida (SGA).
Una instancia de Oracle es un conjunto de estructuras de memoria que están asociadas con los archivos
de datos (datafiles) en una máquina. Una base de datos es una colección de archivos físicos.
Instancia de Oracle
La integran los procesos 'background' y la SGA. Abre una y sólo una BDO, y permite acceder a ella.
Nota: con Oracle Real Application Cluster (RAC), más de una instancia usarán la misma BD.
En la máquina donde reside el servidor Oracle, la variable ORACLE_SID identifica a la instancia con la que
estamos trabajando.
Vistas
V$DATABASE (Base de datos).
V$INSTANCE (Instancia).
V$SGA (SGA).
V$SGAINFO (Gestión dinámica de la SGA).
V$SGASTAT (SGA detallada).
V$BUFFER_POOL (Buffers en la caché de datos)
V$SQLAREA (Sentencias SQL).
V$PROCESS (Procesos).
V$BGPROCESS (Procesos background).
V$DATAFILE (Ficheros de datos de la BD).
V$CONTROLFILE (Ficheros de control de la BD).
V$LOGFILE (Ficheros redo log de la BD).
DBA_TABLESPACES (Tablespaces de la BD).
DBA_SEGMENTS (Segmentos que hay en los tablespaces).
DBA_EXTENTS (Extensiones que componen los segmentos).
DBA_USERS (Usuarios de la BD).
Oracle RAC (Real Application CLuster).

En un Rac de Oracle, múltiples instancias permiten el acceso a una única Base de datos. En un RAC las
instancias corren en múltiples Nodos (servidores), y acceden a un conjunto común de datafiles que
comprender a una 'Única' Base de datos."
En contraste, en un ambiente de una única instancia, una base de datos Oracle es usada por sólo UNA
Instancia corriendo en el servidor. Por lo Tanto, los usuarios accediendo a la base de datos pueden
conectarse a ésta, sólo a través de ese 'Único' servidor.
En un Oracle RAC, una base de datos puede ser montada por más de una instancia, y en cualquier punto,
una instancia será parte de sólo una Base de datos. El almacén no volátil para archivos de datos que
comprende la Base de datos es igualmente disponible a todos los nodos, para el acceso de lectura y
escritura. De lo anterior se desprende que un RAC de Oracle necesita coordinar y regular el acceso
“simultaneo” a los datos desde múltiples servidores (nodos), por ende, debe existir una red privada que
sea eficiente, confiable y de alta rapidez, entre los nodos del clúster para enviar y recibir datos
Crear Instancias MySQL
Tener dos instancias o más tiene entre otras las siguientes justificaciones. Una se dedicará a desarrollo,
para hacer las modificaciones y pruebas necesarias y otra al de producción.
Proceso
Copiar la carpeta data que se encuentra en nuestro caso en c:\MySQL, como data2
Copiar y pegar la configuración de MySQL. Es decir, del archivo my.ini (en linux my.cnf) generamos una
copia que podría llamarse my2.ini.
Ahora con cuidado editamos my2.ini, procure no tocar my,ini a menos que este seguro de lo que hace.
Iniciamos configurando el puerto por donde escuchara MySQL la segunda instancia y la ruta de datos el
archivo de datos.
Iniciar Instancia desde Consola

Desde la consola de ms-dos en modo administrador. [Tecla Win] + [X] y damos clic en Símbolo de
Sistema (Administrador). Ahora introduzca desde la línea de comandos:
cd /MySQL/MySQL Server 5.6/bin
mysqld --defaults-file=my2.ini --explicit_defaults_for_timestamp = TRUE
mysql -u root -port 3307 -p
Establecer la Instancia como Servicio

Procederemos a instalar la nueva instancia como servicio. Desde la consola de ms-dos en modo
administrador. En windows 8 pulse la [Tecla Win] + [X] y damos clic en Símbolo de Sistema
(Administrador):

ABD - U3-Mysql5 - 7

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ABD - U3-Mysql5 - 7

Cargado por

Copyright:

Formatos disponibles

Ingeniería en Sistemas Computacionales Administración de Bases de Datos

Unidad 3. Configuración y administración del espacio en disco.

3.1 Estructuras lógicas de almacenamiento

En general, el almacenamiento de los objetos de la base de datos (tablas e índices fundamentalmente)

 Asignar cuotas específicas de espacio a usuarios de la base de datos.

También es sencillo ampliar el espacio destinado a un tablespace utilizando el comando ALTER

ALTER TABLESPACE usuarios ADD DATAFILE 'data2.ora' SIZE 25M

Las distintas formas de organizaciones primarias de archivos son:

 Archivos de Direccionamiento Calculado: utilizan una función de direccionamiento calculado

 Árboles B: se vale de la estructura de árbol para las colocaciones de registros.

create database newpubs on default = 4

create database newdb on mydata = 3, newdata = 2

Si la cantidad de espacio solicitada a un dispositivo específico de base de datos no está disponible, el

 El nombre de la transacción u operación que se realizó (por ejemplo: INSERT, UPDATE o

La estructura de la tabla bitácora sería la siguiente:

CREATE TABLE IF NOT EXISTS `bitacora_carr` (

DROP TRIGGER IF EXISTS `bit_carr_ins`;

/* Triger DELETE para la Tabla carrera */

DROP TRIGGER IF EXISTS `bit_carr_del`;CREATE DEFINER=`root`@`localhost` TRIGGER

INSERT INTO `proyecto`.`bitacora_carr` (`operacion`, `usuario`, `host`, `modificado`,

/* Triger UPDATE para la Tabla carrera */

DROP TRIGGER IF EXISTS `bit_carr_upd`;

INSERT INTO `proyecto`.`bitacora_carr` (`operacion`, `usuario`, `host`, `modificado`,

Ahora lo correspondiente par la table departamento:

/* Script para crear la tabla bitacora_depto */

CREATE TABLE IF NOT EXISTS `bitacora_depto` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`operacion` varchar(10) DEFAULT NULL,

`usuario` varchar(40) DEFAULT NULL,

`host` varchar(30) NOT NULL,

`modificado` datetime DEFAULT NULL,

`tabla` varchar(40) NOT NULL,

`oldnum_departamento` int(11) DEFAULT NULL,

`oldnombre_dept` varchar(20) DEFAULT NULL,

`oldjefe_num_tarjet` int(11) DEFAULT NULL,

`newnum_departamento` int(11) DEFAULT NULL,

`newnombre_dept` varchar(20) DEFAULT NULL,

`newnum_departamento` int(11) DEFAULT NULL,

PRIMARY KEY (`id`)

/* Triger INSERT para la Tabla departamento */

DROP TRIGGER IF EXISTS `bit_depto_ins`;

CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_ins` AFTER INSERT ON

INSERT INTO `proyecto`.`bitacora_depto`

(òperacion`, ùsuario`, `host`, `modificado`, `tabla`, òldnum_departamento`,

/* Triger DELETE para la Tabla departamento */

DROP TRIGGER IF EXISTS `bit_depto_del`;

CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_del` AFTER DELETE ON

INSERT INTO `proyecto`.`bitacora_depto`

(òperacion`, ùsuario`, `host`, `modificado`, `tabla`, òldnum_departamento`,

/* Triger UPDATE para la Tabla departamento */

DROP TRIGGER IF EXISTS `bit_depto_upd`;

CREATE DEFINER=`root`@`localhost` TRIGGER `bit_depto_upd` AFTER UPDATE ON

INSERT INTO `proyecto`.`bitacora_depto`

(òperacion`, ùsuario`, `host`, `modificado`, `tabla`, òldnum_departamento`,

/* Script para crear la tabla bitacora_maestros */

CREATE TABLE IF NOT EXISTS `bitacora_maestros` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`operacion` varchar(10) DEFAULT NULL,

`usuario` varchar(40) DEFAULT NULL,

`host` varchar(30) NOT NULL,

`modificado` datetime DEFAULT NULL,

`tabla` varchar(40) NOT NULL,

`oldnum_tarjeta` int(11) DEFAULT NULL,