3.

Configuracin y administracin del espacio en disco

Una particin de disco, en mantenimiento, es el nombre genrico que recibe cada divisin presente en una sola unidad fsica de almacenamiento de datos. Toda particin tiene su propio sistema de archivos (formato); generalmente, casi cualquier sistema operativo interpreta, utiliza y manipula cada particin como un disco fsico independiente, a pesar de que dichas particiones estn en un solo disco fsico. Una particin de un disco duro es una divisin lgica en una unidad de almacenamiento, en la cual se alojan y organizan los archivos mediante un sistema de archivos. Existen distintos esquemas de particiones para la distribucin de particiones en un disco. Para la gestin 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, extensin, segmento y espacio de tablas.

3.1 Estructuras lgicas de almacenamiento

Para la gestin 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, extensin, segmento y espacio de tablas. Bloques: Se tratan de la unidad ms pequea. Generalmente debe mltiple del tamao de bloque del sistema operativo, ya que es la unidad mnima que va a pedir Oracle al sistema operativo. Si no fuera mltiple del bloque del sistema se aadira un trabajo extra ya que el sistema debera obtener ms datos de los estrictamente necesarios. Se especifica mediante DB_BLOCK_SIZE Extensiones: Se forma con uno o ms bloques. Cuando se aumenta tamao de un objeto se usa una extensin 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 ms datafiles, cada datafile solo puede pertenecer a un determinado tablespace En general, el almacenamiento de los objetos de la base de no se realiza sobre el archivo o archivos fsicos de la base de datos, sino que se hace a travs de estructuras lgicas de almacenamiento que tienen por debajo a esos archivos fsicos, y que independizan por tanto las sentencias de creacin de objetos de las estructuras fsicas de almacenamiento. Esto es til porque permite que a esos "espacios de objetos " les sean asociados nuevos dispositivos fsicos de forma dinmica cuando la base de datos crece de tamao ms de lo previsto. Posibilita adems otra serie de operaciones como las siguientes:

Asignar cuotas especficas 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.

File Manager: proporciona la gerencia de archivos generales y de archivos protegidos grandes. Buffer Manager: proporciona la gerencia de almacenadores intermediarios compartidos. Page Manager: algoritmo DE LRU de las aplicaciones para manejar las pginas. Lock Manager: proporciona cerradurasde tipo lectura y escritura para alcanzar consistencia. IPC: realiza la sincronizacin del escondrijo. Disk Manager: proporciona el interfaz para storage/disk fsico.

El administrador de la base de datos puede crear o borrar nuevos espacios lgicos de objetos, aadir o eliminar ficheros fsicos de soporte, utilizados como espacio temporal de trabajo, definir parmetros de almacenamiento para objetos destinados a ese espacio de datos, todos los gestores relacionales que venimos introduciendo como ejemplos siguen esta filosofa. En el caso de Oracle Postgres, sobre los ficheros fsicos de datos (datafiles) se definen los tablespaces. Por lo tanto, una base de datos Oracle Postgres se compone lgicamente de tablcspaccs, y fsicamente de datafilcs. Su creacin es sencilla, con la sentencia GREAT'', TABLESPACE: CREATE TABLESPACE usuarios DATAFILE `datal.ora' SIZE 50M Tambin 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 ms grande una base de datos, las opciones disponibles son tres:

Cada base de datos contiene un tablespace llamado SYSTEM que es creado automticamente al crear la base de datos. Contiene las tablas del diccionario de datos para la base de datos en cuestin. Es recomendable no cargar datos de usuario en SYSTEM, para dejarlos como espacio de objetos del sistema. Si adems los datos de usuario estn 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 programacin PL-SQL (entorno de programacin 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 ubicarn en el tablespaee indicado en el momento de su creacin con la correspondiente sentencia CREATE. Si no se dice nada, se situarn en el tablespace por defecto asociado al usuario creador 3.1.1. Definicin 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 mayora de las bases de datos se almacenan en las llamadas memorias secundarias, especialmente discos duros, aunque, en principio, pueden emplearse tambin 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 magnticas, discos pticos o similares. Las tcnicas empleadas para almacenar bases de datos son sumamente importantes para la velocidad de acceso y recuperacin de datos. Las tcnicas 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 tcnicas empleadas. Las tcnicas de almacenamiento son independientes de la base de datos, pero, de todas maneras, las mejores tcnicas muchas veces pueden determinarse viendo la estructura de la base de datos, entre otras caractersticas. Los encargados de elegir estas tcnicas son los diseadores y administradores de bases de datos, y dependen tambin de las capacidades del SGBD. En general, el SGBD ofrece diferentes opciones y tcnicas para organizar los datos. La idea es que los encargados de la base de datos encuentren las tcnicas idneas, o sea, aquellas que permitan la mayor velocidad posible de acceso a los datos. Una mala decisin 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 actualizacin de la misma. 3.1.2. Definicin y creacin 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 fsicamente en el disco y, por lo tanto, cmo se accede a stos. Las distintas formas de organizaciones primarias de archivos son: Existe una segunda forma de acceder a los datos llamada organizacin secundaria o estructura de acceso auxiliar. Estas permiten que los accesos a los registros de un archivo basado en campos alternativos, sean ms eficientes que los que han sido utilizados para la organizacin 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 ms 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 clusula on , el DBMS pone la base de datos en uno o ms de los dispositivos predeterminados de base de datos especificados en master..sysdevices Para especificar un tamao (en este ejemplo, 4MB) para una base de datos que se va a almacenar en una ubicacin predeterminada, utilice on default = size de esta forma: create database newpubs on default = 4 Para situar la base de datos en dispositivos especficos, d el nombre del dispositivo o dispositivos en que desea almacenarla. Como la sintaxis indica, puede solicitar que se almacene en ms 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 instruccin 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 pequea o que no sea crucial, site siempre el diario en un dispositivo de base de datos aparte. Si la cantidad de espacio solicitada a un dispositivo especfico 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 mnimo 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. Bitcoras La estructura ms ampliamente usada para grabar las modificaciones de la base de datos es la Bitcora. Cada registro de la bitcora escribe una nica escritura de base de datos y tiene lo siguiente:

1. Nombre de la transaccin: Nombre de la transaccin que realiz la operacin de escritura. 2. Nombre del dato: El nombre nico del dato escrito. 3. Valor antiguo: El valor del dato antes de la escritura. 4. Valor nuevo: El valor que tendr el dato despus de la escritura.

Existen otros registros de bitcora especiales para grabar sucesos importantes durante el proceso de transaccin, tales como:

< T1, inicio > < T1, x, v1, v2 > < T1, commit > Es fundamental que siempre se cree un registro en la bitcora cuando se realice una escritura antes de que se modifique la base de datos. Tambin tenemos la posibilidad de deshacer una modificacin que ya se ha escrito en la base de datos, esto se realizar usando el campo del valor antiguo de los registros de la bitcora. Los registros de la bitcora deben residir en memoria estable como resultado el volumen de datos en la bitcora puede ser exageradamente grande. Ejemplo de una bitcora 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 definira 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 NDBCC INPUTBUFFER( @i ), N@i int, @i=@@spid END Enseguida plantear un ejemplo de una bitcora 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 bitcora sera la siguiente: CREATE TABLE IF NOT EXISTS `bitacora` (`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, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; La bitcora debe registrar todos los movimientos (insertar, eliminar y modificar) que se realicen en las tablas de la base de datos. Para lograr lo anterior es necesario crear un trigger para que se ejecute despus de la operacin de insertar, otro para despus de eliminar y el ltimo para despus de modificar para cada una de las 3 tablas de la base de datos. Los nueve triggers necesarios para que funcione la bitcora son los siguientes: DROP TRIGGER IF EXISTS `bit_carr_ins`; DELIMITER // CREATE TRIGGER `bitacora` AFTER INSERT ON `carrera` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), CARRERA) // DROP TRIGGER IF EXISTS `bit_carr_upd`; CREATE TRIGGER `bit_carr_upd` AFTER UPDATE ON `carrera` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ACTUALIZAR, NOW(), CARRERA) // DROP TRIGGER IF EXISTS `bit_carr_del`; CREATE TRIGGER `bit_carr_del` AFTER DELETE ON `carrera` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ELIMINAR, NOW(), CARRERA) // DROP TRIGGER IF EXISTS `bit_depto_ins`; CREATE TRIGGER `bit_depto_ins` AFTER INSERT ON `departamento` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), DEPARTAMENTO) //

DROP TRIGGER IF EXISTS `bit_depto_upd`; CREATE TRIGGER `bit_depto_upd` AFTER UPDATE ON `departamento` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ACTUALIZAR, NOW(), DEPARTAMENTO) // DROP TRIGGER IF EXISTS `bit_depto_del`; CREATE TRIGGER `bit_depto_del` AFTER DELETE ON `departamento` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ELIMINAR, NOW(), DEPARTAMENTO) // DROP TRIGGER IF EXISTS `bit_mae_ins`; CREATE TRIGGER `bit_mae_ins` AFTER INSERT ON `maestros` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), MAESTROS) // DROP TRIGGER IF EXISTS `bit_mae_upd`; CREATE TRIGGER `bit_mae_upd` AFTER UPDATE ON `maestros` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ACTUALIZAR, NOW(), MAESTROS) // DROP TRIGGER IF EXISTS `bit_mae_del`; CREATE TRIGGER `bit_mae_del` AFTER DELETE ON `maestros` FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),@')+1)), SUBSTRING(USER(),1,(instr(user(),@')-1)), ELIMINAR, NOW(), MAESTROS)

3.1.4 Particiones

El particionado de tablas es una tcnica que se usa para reducir la cantidad de lecturas fsicas a la base de datos cuando ejecutamos consultas, existen dos principales modalidades de particionado: horizontal y vertical. Vamos a los detalles!

Horizontal: Esta modalidad consiste en tener varias tablas con las mismas columnas en cada una de ellas y distribuir la cantidad de registros en estas tablas (generalmente se particiona separando la data por aos, meses, etc). Ejemplo: tenemos tres tablas registro2001, registro2002, registro2003 y en cada tabla guardamos los registros de los aos correspondientes, esto nos garantiza una mejora en el rendimiento considerable cuando realicemos consultas sobre las tablas ya que la data estar distribuida en tres partes y ya sabramos dependiendo del ao en cual tabla buscar. Vertical: Esta modalidad generalmente la aplicamos en nuestros diseos de base de datos sin darnos cuenta, por ejemplo cuando tenemos una columna de tipo BLOB con una fotografa o un texto muy largo que no leemos frecuentemente y decidimos ponerla en otra tabla referenciandola con la clave fornea.

Ahora bien, el particionado horizontal es el que vamos a comentar, ya que el problema radica en cmo hacer para que nuestras aplicaciones sepan en que tabla guardar el registro dependiendo del ao (porque obviamente no le vamos a agregar esas condiciones a nuestra aplicacin); esto se logra agregando una serie de sentencias y condiciones en la definicin de las tablas. Para configurar una tabla con particiones, haga lo siguiente: 1. Crear el "maestro" de mesa, de la que todas las particiones heredarn. Esta tabla contendr ningn dato. No defina las restricciones de verificacin en este cuadro, a menos que vaya a aplicarse por igual a todas las particiones. No hay ningn punto en la definicin de los ndices o restricciones nicas en l, tampoco. 2. Crear varios "nios" tablas que cada heredan de la tabla principal. Normalmente, estas tablas no aade columnas para el conjunto heredado de la maestra. Nos referimos a las tablas secundarias como particiones, aunque son en todos los sentidos normales PostgreSQL tablas. 3. Aadir restricciones de tabla para las tablas de particin para definir los valores de clave permitidas en cada particin.
VER (outletID ENTRE 100 Y 200) VER (outletID ENTRE 200 Y 300)

Tenga en cuenta que no hay diferencia en la sintaxis entre el rango y la lista de particiones, esos trminos son descriptivos solamente. 4. Para cada particin, crear un ndice en la columna de clave (s), as como cualquier otro ndice que podra querer. (El ndice de clave no es estrictamente necesario, pero en la mayora de los casos es de gran ayuda. Si usted tiene la intencin de los valores clave para ser nico, entonces siempre se debe crear una restriccin de unicidad o de clave primaria para cada particin.) 5. Opcionalmente, definir un disparador o una regla para redireccionar los datos insertados en la tabla principal de la particin correspondiente. 6. Asegrese de que el constraint_exclusion parmetro de configuracin no est inhabilitada en postgresql.conf . Si es as, las consultas no sern optimizados como deseado.

CREAR tabla de la medida ( city_id int NOT NULL, fecha no nula logdate, peaktemp int, unitsales int );

Sabemos que la mayora de las consultas se acceden slo los datos de la ltima semana, el mes o el trimestre de la, ya que el uso principal de esta mesa ser la de preparar los informes en lnea para la gestin. Para reducir la cantidad de datos antiguos que necesita ser almacenado, decidimos slo mantener los ms recientes 3 aos valor de los datos. Al principio de cada mes, vamos a eliminar los datos del mes ms antiguo. En esta situacin podemos utilizar particiones para ayudarnos a cumplir todos nuestros requisitos diferentes para la tabla de mediciones. Siguiendo los pasos descritos anteriormente, la particin se puede configurar de la siguiente manera: 1. La tabla principal es la medicin de la tabla, tal y como declar anteriormente. 2. A continuacin, creamos una particin para cada mes activo:

CREATE TABLE INHERITS measurement_y2006m02 () (medicin); CREATE TABLE INHERITS measurement_y2006m03 () (medicin); ... CREATE TABLE INHERITS measurement_y2007m11 () (medicin); CREATE TABLE measurement_y2007m12 () INHERITS (medicin); CREATE TABLE measurement_y2008m01 () INHERITS (medicin);

Cada una de las particiones son tablas completas en s mismas, sino que heredan sus definiciones de la

medicin de la tabla.

Esto resuelve uno de los problemas: borrar datos viejos. Cada mes, todos tendremos que hacer es realizar una

DROP TABLE sobre la mesa ms antiguo nio y crear una nueva tabla

secundaria de los datos del nuevo mes. 3. Debemos proporcionar no superpuestos restricciones de tabla. En lugar de crear las tablas de particin en el caso anterior, el script de creacin de la tabla en realidad debera ser:

CREATE TABLE measurement_y2006m02 ( VER (logdate> = FECHA '2006-02-01 'AND logdate <FECHA '2006-03-01') INHERITS) (medicin); CREATE TABLE measurement_y2006m03 ( VER (logdate> = FECHA '2006-03-01 'AND logdate <FECHA '2006-04-01') INHERITS) (medicin); ... CREATE TABLE measurement_y2007m11 ( VER (logdate> = FECHA '2007-11-01 'AND logdate <FECHA '2007-12-01') INHERITS) (medicin);

CREATE TABLE measurement_y2007m12 ( VER (logdate> = FECHA '2007-12-01 'AND logdate <FECHA '2008-01-01') INHERITS) (medicin); CREATE TABLE measurement_y2008m01 ( VER (logdate> = FECHA '2008-01-01 'AND logdate <FECHA '2008-02-01') INHERITS) (medicin);

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 comnmente 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 tambin para mantener alejados a los usuarios de las tablas que contienen los datos en tiempo real. Cuando reciba una base de datos, debe adentrarse ms all del panel de control para averiguar cmo estn estructurados los datos, pero merece la pena echar un vistazo inicial al panel de control. Le puede ofrecer algn indicio sobre las tareas que el diseador de la base de datos consider que realizaran los usuarios habitualmente con los datos. Puede hacer clic en los vnculos del panel de control para ver qu objetos, como formularios e informes, abren. 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 planificacin para el almacenamiento real de la base de datos. Algunas tecnologas de almacenamiento son ms adecuadas que otras. Sin embargo, la naturaleza mecnica de la unidad de disco los hace ms vulnerables al fracaso de los componentes de otro equipo. Adems, las formas en que las unidades de disco son utilizados por las bases de datos pueden hacer que la gestin 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 misin crtica la integridad de los datos puede ser ms importante que la disponibilidad de datos. Si el soporte es poco fiable y un fallo de las causas de corrupcin de datos, los datos perdidos puede ser ms 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 recuperacin de datos desde medios de almacenamiento lleva mucho ms tiempo en completarse que la recuperacin 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 ms tiempo. Algunos DBMS permiten al tamao de los archivos temporales de expandirse y contraerse de forma automtica. Dependiendo del tipo y la naturaleza de las operaciones de base de datos en proceso, esta fluctuacin puede provocar picos de uso del disco El crecimiento de la capacidad de almacenamiento aumenta an ms la complejidad de la gestin de datos y bases de datos. Muchas organizaciones estn implementando nuevas tecnologas 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 gestin del almacenamiento en el entorno dinmico de hoy es una tarea difcil 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 ms importantes es la cantidad de espacio para permitir la base de datos. El clculo espacial debe tener en cuenta no slo tablas, ndices, sino tambin, 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 ndice de datos. Aislar los logos en otro disco.

3.2. Segmentos
Un segmento contiene un tipo especfico de objetos de la base de datos, como por ejemplo una tabla. Un segmento est compuesto de extensiones que definen el tamao disponible para el segmento. A medida que se llenan las extensiones se van aadiendo 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 tambin crece con ella.

Fsicamente todo objeto en base de datos no es ms 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 representacin fsica del objeto en base de datos (el objeto es solo una definicin lgica). Los segmentos son los equivalentes fsicos de los objetos que almacenan datos. El uso efectivo de los segmentos requiere que el DBA conozca los objetos, que utiliza una aplicacin, cmo los datos son introducidos en esos objetos y el modo en que sern recuperados. Un segmento est constituido por secciones llamadas extensiones, que son conjuntos contiguos de bloques. Una vez que una extensin existente en un segmento no puede almacenar ms datos, el segmento obtendr del espacio de tabla otra extensin. Este proceso de extensin continuar hasta que no quede ms espacio disponible en los ficheros del espacio de tablas, o hasta que se alcance un nmero mximo de extensiones por segmento. Existen 5 tipos de segmento: De datos. De ndices. De rollback. Temporales. De bootstrap.

En postgres los segmentos se pueden ver en: pg_xlog (WAL): Diarios de escritura adelantada. Utilizada para recuperaciones. Conjunto de segmentos de un tamao de 16 MB y divididos en pginas de 8KB. Se van creando de acuerdo a las necesidades.

3.3. Memoria Compartida.

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 enva de nuevo la misma consulta La exclusin mutua se puede implementar por medio de funciones del sistema operativo llamadas semforos. Implementaciones alternativas, con menos sobrecargas, utilizan

instrucciones atmicas especiales soportadas por el hardware de la computadora; un tipo de instruccin atmica comprueba una posicin de la memoria y la establece a uno automticamente. Los mecanismos de exclusin mutua tambin se utilizan para implementar pestillos. Memoria compartida

SHMMAX: Tamao mximo de un segmento de memoria compartida (bytes) SHMMIN: Tamao mnimo de un segmento de memoria compartida (bytes) SHMALL: Cantidad mxima de memoria compartida disponible (bytes pfinas) SHMSEG: Nmero mximo de segmentos de memoria compartida por proceso SHMMNI: Nmero mximo de segmentos de memoria compartida en todo el sistema

SHMMAX: Varios MB. El valor por defecto del ncleo es 32MB, un valor muy bajo en muchos casos. Existen varios parametros en postgresql.conf que determinan cuanta memoria compartida necesitaremos, el ms importante de ellos y el principal causante de que necesitemos aumentar SHMMAX es shared_buffers. El valor de SHMMAX (bytes) no puede ser menor que el valor definido en shared_buffers. PostgreSQL se negar a arrancar si el valor de SHMMAX es muy pequeo.

SHMMIN: Como mnimo 1. SHMALL: Como mnimo SHMMAX/PAGE_SIZE. En donde el valor de PAGE_SIZE lo podeis obtener ejecutando el comando getconf PAGESIZE. El valor por defecto del ncleo es 2097152 pages (8192MB) Si teneis varios clusters de PostgreSQL ejecutandose en la mquina otros programas que usen memoria compartida, tendreis que definir un valor de SHMALL lo suficientemente grande para poder ejecutar todos estos programas a la vez.

SHMSEG: Solamente se necesita 1. El valor por defecto es mucho ms grande. SHMMNI: Como mnimo SHMSEG + lo necesario por otras aplicaciones. El valor por defecto del ncleo es 4096. Pocas veces hay que modificar este valor.

3.4. Instancias mltiples

Se llama instancia mltiple al hecho de poder ejecutar un programa ms de una vez al mismo tiempo. Hay programas que no admiten ms que una sola instancia, es decir que si ya se est ejecutando, por ms 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 tambin abierto, la modificacin 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 opcin en el diseo de la BD, y se reflejarn de inmediato las modificaciones en todas las instancias abiertas En programacin, una instancia se produce con la creacin de un objeto perteneciente a una clase (se dice que se instancia la clase). El objeto que se crea tiene los atributos, propiedades y mtodos de la clase a la que pertenece. Los objetos y sus caractersticas se usan en la construccin de programas, ya sea como contenedores de datos o como partes funcionales del programa. Los objetos tambin puede ser ocurrencia de las clases.
La idea es poder tener multiples instancias (clusters) de PostgreSQL en un mismo servidor, escuchando en diferentes puertos. De esta forma podremos tener configuraciones de seguridad diferentes para cada una de ellas, levantarlas o pararlas de forma independiente, etc. Como ejemplo tendremos dos instancias, una principal en el puerto 5432 y otra adicional para desarrollo en el 5433.

Como en RHEL5 En primer lugar creamos un enlace simblico al script de inicio de postresql, para la instancia de desarrollo. # ln -s /etc/init.d/postgresql /etc/init.d/postgresql-desa Creamos un fichero de configuracin de la nueva instancia, en este caso /etc/sysconfig/pgsql/postgresql-desa. GDATA=/var/lib/pgsql/data-desa PGPORT=5433 PGLOG=/var/lib/pgsql/pgstartup-desa.log

Inicializar la nueva instancia de BDD: # service postgresql-desa initdb # service postgresql-desa start Podemos comprobar como ha creado el nuevo directorio data, as como el log de arranque: # ls /var/lib/pgsql backups data data-desa pgstartup.log pgstartup-desa.log Para configurar el arranque automtico, la instancia se configura como un servicio mas: # chkconfig --level 235 postgresql-desa on Como en Debian En Debin la gestin de instancias es mucho mas sencilla, ya que se incluyen herramientas para gestionarlas. Incluso contemplan tener instacias de versiones diferentes de postgresql. Creamos una segunda instancia para desarrollo: # pg_createcluster -p 5433 8.3 desa Creating new cluster (configuration: /etc/postgresql/8.3/desa, data: /var/lib/postgresql/8.3/desa)... Moving configuration file /var/lib/postgresql/8.3/desa/postgresql.conf to /etc/postgresql/8.3/desa... Moving configuration file /var/lib/postgresql/8.3/desa/pg_hba.conf to /etc/postgresql/8.3/desa... Moving configuration file /var/lib/postgresql/8.3/desa/pg_ident.conf to /etc/postgresql/8.3/desa... Listar las instancias (clusters): # pg_lsclusters Version Cluster Port Status Owner Data directory Log file 8.3 desa 5433 down postgres /var/lib/postgresql/8.3/desa /var/log/postgresql/postgresql-8.3-desa.log 8.3 main 5432 online postgres /var/lib/postgresql/8.3/main /var/log/postgresql/postgresql-8.3-main.log

La nueva instancia se inicia/para/reinicia automticamente por el script de inicio de postgresql: # /etc/init.d/postgresql-8.3 restart Restarting PostgreSQL 8.3 database server: desa main. Trabajar con las instancias: Cuando trabajemos con las herramientas de consola de postgresql, podemos indicar la instancia en la que operar con la opcin --cluster, unos ejemplos: - Listar BBDD: <a href="mailto:postgres@idescac">postgres@idescac</a>:~$ psql --cluster 8.3/desa -l Listado de base de datos Nombre | Dueo | Codificacin -----------+----------+-------------postgres | postgres | UTF8 template0 | postgres | UTF8 template1 | postgres | UTF8 (3 filas) - Crear un usuario: $ createuser -P -s -e user_desa --cluster 8.3/desa - Crear una BDD: $ createdb bdd_desa --o user_desa --cluster 8.3/desa