Polticas de Administracin del Espacio en los Ambientes de Trabajo con Oracle i. DATOS GENERALES i.1 Autor. Ing.

Alfonso Jess Trevio Cant. i.2 Departamento. Ingeniera de Informacin. i.3 Nombre del documento. PolticasEspacio.doc i.4 Fecha de creacin. 21/Ago/98. i.5 Fecha de ltima actualizacin. 2/Sep/98. I. INTRODUCCION. 1.1 Objetivo del documento. El objetivo del presente documento es el de presentar las polticas que regulan la administracin del espacio de las bases de datos. Este documento se enfocar al ambiente Banner del ITESM, el cual utiliza Oracle como RDBMS. II. ORGANIZACIN DEL ESPACIO EN UNA BASE DE DATOS DE ORACLE. 2.1 Cmo se organiza el espacio en Oracle?. Esta seccin explica brevemente los fundamentos de organizacin del espacio en una base de datos con Oracle 7 sobre un sistema operativo UNIX. El sistema operativo administra el espacio en los discos a travs de file systems o raw devices, mas para efectos del presente documento, dado que Oracle sugiere utilizar file systems para esquemas de operacin como el nuestro (los raw devices se sugieren con Oracle paralelo), se hablar slo de file systems. En los file systems se alojan los archivos y directorios con que los usuarios, aplicaciones y el mismo sistema operativo trabajan. Dependiendo de la implementacin de UNIX (AIX, Solaris, etc.) los file systems pueden crecer dinmicamente o tener un tamao fijo. Para manejar las tablas, ndices y dems elementos de una base de datos, el RDBMS los aloja en particiones llamadas tablespaces, las cuales se componen de datafiles, los cuales son archivos que se pueden encontrar en uno o ms file systems. La adecuada definicin de datafiles y tablespaces la realizaa el administrador de la base de datos, y el adecuado alojamiento de los mismos los realiza en conjunto con el administrador del sistema. 2.2 Clusulas de almacenamiento. Cuando se crea una tabla o ndice en la base de datos debe siempre de especificarse en qu tablespace se almacenar. No hacer lo anterior es muy peligroso, pues el objeto ser creado en el tablespace de system, el cual debe usarse exclusivamente para el almacenamiento del diccionario de datos y para los usos que internamente lo utiliza el RDBMS. Cmo se sabe de qu tamao se crea una tabla o ndice? Cuando el administrador crea un tablespace, l define una serie de clusulas de almacenamiento para ese tablespace; en caso de no proporcionar estas clusulas, el tablespace se crear con una serie de valores default. Qu son las clusulas de almacenamiento? Son indicadores que informan al RDBMS el tamao inicial y los factores de crecimiento de los objetos que se creen en ese tablespace. Sin embargo, una tabla o ndice puede crearse con clusulas de almacenamiento diferentes a las del tablespace donde reside, y esto se hace indicando las clusulas para la tabla en el estatuto create de la misma. Esto ltimo es lo sugerido para una mejor administracin del espacio utilizado por las tablas e ndice para que sea de acuerdo a las necesidades de crecimiento derivadas del volumen de informacin utilizado. Tomando en cuenta el contenido del prrafo anterior, ya es posible saber de qu tamao se crea una tabla o ndice: una tabla o ndice se crear del tamao especificado en la clusula de almacenamiento initial. Al crear una tabla se separa el espacio indicado por initual, aunque ste no se use por completo. Conforme se va

poblando la tabla, el espacio libre de initial se va agotando, cuando ste se termina por completo, se aloja a la tabla un extent (extensin) del tamao especificado por la clusula del mismo nombre. De igual manera, cuando se llena el extent se aloja otro a la tabla. El tamao de los extents subsecuentes al primero puede ser el mismo que el tamao del primero o pueden irse incrementando un cierto porcentaje, indicado en la clusula pctincrease. Ejemplo: Si definimos que el tamao definido en la clusula extent de una tabla es de 10K y definimos que el pctincreae es de 10%, tendremos que los tamaos de los extents que se alojen a la tabla sern: Primer extent 10K. Segundo extent 11K " 10K + 10K * 10% = 10K + 1K.. Tercer extent 12.1K = 11K + 11K * 10% = 11K + 1.1K. Se alojarn tantos extents como sea necesario conforme crece la tabla hasta que se cumplan cualquiera de estas dos condiciones: Se haya llegado al lmite de extents asignables a la tabla o ndice. Este lmite lo indica la clusula maxextents. El nmero mximo de extents que puede especificarse con este parmetro es de 249 (este lmite de 249 extents ya no existe en versiones de Oracle iguales o superiores a 7.3, sin embargo, para efectos del sistema Banner 2.0.x, la versin de Banner que se utiliza al momento de la escritura del presente documento es la versin 7.2.3). No haya espacio disponible en el tablespace para alojar un extent del tamao requerido. Las siguientes grficas ilustran lo explicado anteriormente.

Como puede verse en la grfica anterior, una tabla o ndice se crea con un espacio igual al parmetro initial; al ser llenado este espacio, se le asigna un extent a la tabla o ndice, asignndose otro extent cuando el extent se llena. Como se mencion anteriormente, el proceso de aadir extents a una tabla o ndice se detiene al momento en que la tabla alcanza el nmero mximo de extents que se indic en la cliusula correspondiente, o cuando no es posible alojar un extent por falta de espacio en el tablespace. En las siguientes secciones se discuten las soluciones a estas situaciones. Lmite de extents menor a 249. Cuando una tabla o ndice se llena por completo, alcanzndose el lmite de extents indicado en la clusula de almacenamiento correspondiente y si este lmite es menor que 249, la solucin consiste en que el dueo del modelo al que pertenece la tabla modifique con un estatuto alter table la clusula de maxextents del objeto. Lmite de extents igual a 249. Cuando se alcanz el lmite de extents indicado para la tabla o ndice, y este lmite es igual a 249, el administrador de datos debe reconstruir la tabla o ndice, para lo cual realiza lo siguiente: Obtener el nmero de registros de la tabla en cuestin (si se trata de un ndice pase al paso 2). Calcular nuevos parmetros de almacenamiento del objeto. Si se trata de una tabla: utilizar el oraschema con la clusula E para calcular los nuevos parmetros de initial de la tabla: oraschema d base_de_datos o dueo t objeto s E #_de_registros.

NOTA: Si no se especifica un nmero de registros en el parmetro E, el oraschema calcular los parmetros de almacenamiento para la cantidad actual de registros que posee la tabla. Si se trata de un ndice, obtener su esquema con el oraschema y modificar en el script resultante la clusula de initial, ponindole como nuevo tamao la suma del initial actual ms la suma de los tamaos de los extents. En el caso de los ndices, tambin se puede utilizar el oraschema, donde la cantidad de registros especificada en el parmetro E es el nmero de registros que contiene la tabla que es indexada por dicho ndice. En el caso de reconstruccin de tablas, respaldar los datos de la misma.. Recrear el objeto con el script generado por el oraschema. En el caso de que el objeto reconstruido sea una tabla, cargar los datos que previamente se haban salvado. NOTA TECNICA: Cmo calcula el oraschema los parmetros de almacenamiento para tablas e ndices? Para las tablas obtiene el nmero de registros de la tabla y cuenta el nmero de bloques (un bloque es una unidad de almacenamiento de Oracle, su tamao default es de 4K) ocupados que tiene la tabla y aplica una regla de 3 para saber cuntos bloques se requerir ocupar para la cantidad de registros especificados en el parmetro E, con lo que puede calcular el tamao del initial para la tabla. En el caso de los ndices, el oraschema realiza un analyze index, obteniendo de la tabla dba.index_stats el nmero de bytes para el ndice. Si se especifico una cantidad de registros para la tabla a la cual el ndice indexa, el oraschema aplica una regla de 3 para calcular el nuevo tamao de initial del ndice. Espacio del tablespace agotado. En este caso es necesario pedir ayuda al DBA. En el caso de que este problema se presente en una base de datos de produccin, el espacio es asignado al tablespcae de inmediato. En el caso de que este problema se presente en las bases de datos de pruebas o desarrollo, el DBA har la reorganizacin que l crea conveniente. Fragmentacin. Un tablespace por lo general es compartido por ms de un objeto. Se recomienda que los ndices se separen de las tablas, ubicando cada tipo de objeto en un tablespace diferente. En un caso ideal todos los objetos que van a residir en un tablespace dado se crean al mismo tiempo, asignndoseles su rea de initial a cada tabla, de tal manera que las tablas queden contiguas. Conforme se van alojando extents a las tablas, stos se alojaran al final del tablespace despus del ltimo espacio asignado previamente. Sin embargo, durante la vida de casi cualquier tabla se borran registros, dejando espacios vacos en las reas de initial o de extent, dependiendo de dnde se encontraban los registros eliminados. Este espacio libre no se vuelve a reutilizar, lo que genera que el tablespace tenga lo que se llama fragmentacin. Defragnmentacin y reorganizacin de objetos. Es tarea del DBA el realizar defragmentaciones y reorganizaciones peridicas de los objetos. Por defragmentacin entenderemos el proceso de reutilizar el espacio que queda vaci en los tablespaces a lo largo del tiempo (el proceso de fragmentacin que se explic en el punto anterior), mientras que por reorganizacin se referir al proceso de reacomodar objetos que no se encuentren en sus correspondientes tablespaces para moverlos a los tablespaces correspondientes. En base a la experiencia se ha observado que se necesita realizar una defragmentacin de las bases de datos una vez cada seis meses (depende de las transacciones que se realicen en la base de datos). Es necesario monitorear la fragmentacin de los objetos para planear con tiempo una operacin de defragmentacin y anunciarla a los desarrolladores con al menos una semana de anticipacin. III. CRECIMIENTO DE BASES DE DATOS.

3.1 Factores que modifican la cantidad de espacio de una base de datos. Existen varios factores que deben de tenerse en cuenta antes de presentar los lineamientos a seguir en el manejo del espacio de las bases de datos. Estos factores se enlistan a continuacin: Crecimiento planeado de tablas (y por consiguiente de ndices) en uno o ms tablespaces. Crecimiento no planeado (no se conoca con certeza la razn de crecimiento de una tabla) o el tablespace se llen por haber mucha fragmentacin. Copia de una base de datos origen a una destino (por lo general sta es una operacin de crecimiento, ya que seguido se requiere copiar informacin del ambiente de produccin al ambiente de pruebas). Defragmentacin y reorganizacin de objetos (estas operaciones puede ocasionar incrementos o decrementos en los tamaos de los tablespaces, pero el resultado final es un decremento en el espacio total asignado a la base de datos). Los anteriores factores de crecimiento se detallan en las siguientes secciones. 3.1.1 Crecimiento planeado. Este crecimiento es calculado por los administradores de cada modelo. Este crecimiento generalmente se calcula previa entrada a produccin de un nuevo sistema, previos cambios importantes en el ambiente en que opera un sistema ya existente (por ejemplo, una carga masiva de nueva informacin). El monitoreo del uso del espacio de tablas e ndices puede ayudar a siempre tener informacin para calcular crecimientos subsecuentes de dichos objetos. 3.1.2 Crecimiento no planeado. El crecimiento no planeado se presenta cuando el espacio asignado a un tablespace o a sus tablas e ndices es insuficiente en un punto del tiempo, por lo que es necesario realizar una reconstruccin correctiva o asignar ms espacio al tablespace, dependiendo de la situacin. Esta situacin se puede corregir a travs de monitoreo, reconstrucciones preventivas y mantenimiento preventivo del espacio de la base de datos (defragmentacin, reorganizacin y asignacin de espacio preventiva). 3.1.3 Copia de base de datos. El copiar la informacin contenida en una base de datos a otra tiene como resultado el alterar el espacio utilizado por la base de datos destino, salvo en el rarsimo caso en que ambas bases de datos sean del mismo tamao. En la prctica, ms del 95% de las copias de bases de datos tienden a incrementar el espacio requerido por la base de datos destino, pues por lo general se requiere tener una copia de la informacin de produccin en alguna de las bases de datos que se requieren para desarrollar o probar. Slo en muy pocos casos se mueve informacin de un ambiente de pruebas a una de produccin y cuando se hace esto, por lo general slo se mueven algunos objetos, incrementndose en estos casos el tamao de la base de datos de produccin. 3.1.4 Defragmentacin y reorganizacin. Durante las actividades de defragmentacin y reorganizacin del espacio, los objetos de la base de datos son acomodados en sus tablespaces correspondientes (si por alguna razn no se encontraban en ellos) y se compactan los tablespaces, eliminando la fragmentacin. Debido a que algunas tablas pueden haber estado acomodadas en tablespaces que no les corresponden, al moverlas a sus tablespaces correspondientes, stos pueden crecer, mas los tablespaces de donde son movidas se reducen de tamao. El resultado global de estos procesos siempre es una reduccin del espacio de la base de datos. 3.2 Operaciones destructivas. Dada la complejidad, tiempo requerido y tiempo que puede estar la base de datos no disponible para los usuarios y/o desarrolladores, la

mayora de las operaciones descritas anteriormente, deben de calendarizarse para ser realizadas en periodos en que la base de datos no est prestando servicio alguno. Dado que los requerimientos de copia o de administracin de espacio pueden ser originados por diferentes grupos de desarrolladores, stos deben ser centralizados y administrados por el DBA. Sin embargo, es necesario tener en cuenta que a veces las peticiones que se hacen pueden ser destructivas entre ellas mismas, por lo que cada peticin debe ser analizada por el DBA, quien debe tener la visin global de la operacin de las bases de datos y ste ser quin deba sugerir cmo resolver conflictos. Un ejemplo de operaciones destructivas puede ser el siguiente: En la semana 1 se pide al DBA un incremento de espacio en la base de datos de prueba para realizar una carga de datos en un cierto tablespace; la semana 2 se pide que copie la base de datos de produccin a la de pruebas, pero la base de datos de produccin an no contiene las modificaciones ni los datos cargados en la semana 1 al tablespace que en la semana 1 se modific en pruebas. Qu se puede hacer? Una opcin es cambiar las fechas de las operaciones, para que stas ocurran en orden inverso o pudiera hacerse una copia parcial de base de datos en la semana 2, donde slo se copien los tablespaces que le interesen a la persona que realiz la peticin, pero puede existir el riesgo de violar la integridad al copiar parcialmente la base de datos. El DBA debe sugerir caminos de accin realistas a sus usuarios para solucionar este tipo de problemas. 3.3 Origen de los requerimientos de mantenimiento del espacio. Los requerimientos de crecimiento de tablas e ndices, tanto planeados como no planeados provienen por lo general de los desarrolladoresdores, al igual que las peticiones de copia de bases de datos. Los requerimientos de defragmentacin y reorganizacin son originados por el Departamento de Ingeniera de Informacin. IV. ADMINISTRACION DEL ESPACIO DE LAS BASES DE DATOS. Polticas de administracin del espacio de las bases de datos. En este apartado se presentarn las polticas para la administracin del espacio de las bases de datos. Peticin del espacio. Las peticiones de espacio para las bases de datos o de copia de bases de datos (ya sean totales o parciales), junto con las fechas en que dichas operaciones se requieren, debern hacerse por los responsables de los diferentes modelos indicndolo as en las formas de "Planeacin de Proyectos" que el Departamento de Ingeniera de Informacin proporciona. Estas formas sirven para que DII lleve un mejor control de la calendarizacin de actividades importantes. Se debe de especificar la(s) base(s) de datos para la cual se hace el requerimiento. Este tipo de requerimiento debe hacerse de acuerdo con las siguientes reglas: Dos revisiones por semestre. A inicios de cada semestre (febrero, agosto) se deber de recibir los requerimientos de espacio para las mquinas administrativas. A mediados de cada semestre (mediados de octubre, mediados de abril) se deber revisar con los departamentos de desarrollo estos requerimientos en caso de que necesiten ajustarse. El Departamento de Ingeniera de Informacin revisar estos requerimientos con el Departamento de Tecnologa Computacional y de Informacin para que se realicen las compras de disco que sean necesarias. Especificacin de las necesidades. DII revisar el detalle de cada una de las peticiones de espacio con el responsable de cada modelo. El responsable de cada modelo deber entregar a DII la siguiente informacin: Estimado inicial. Para cada tabla se deber de entregar el estimado inicial del nmero de registros que va a contener, junto con la fecha en que esta carga se va a realizar.

Estimados de crecimiento. Para cada tabla se deber entregar el nmero estimado de registros que se espera vaya creciendo la misma, especificando la periodicidad de este crecimiento. Planeacin del espacio. DII, tomando en cuenta los datos anteriores, revisar con DTCI la disponibilidad de espacio actual en los equipos y la llegada de los nuevos discos. El DBA deber planear con base a la informacin proporcionada por los responsables de modelo, los tamaos de los tablespaces y revisar con el administrador del equipo el alojamiento de los tablespaces en los file systems. Aviso de conflictos. DII deber revisar el calendario de operaciones con bases de datos para descubrir posibles problemas al ejecutar las operaciones de crecimiento o copia de bases de datos en el orden que lo necesitan los diferentes responsables de modelo. DII deber dar a conocer estos problemas y posibles soluciones a la brevedad posible despus de haber recibido los requerimientos de espacio o copia. De igual manera, DII deber de estar en contacto con DTCI para poder avisar con tiempo cualquier problema que exista con la obtencin de disco que se pueda llegar a necesitar para completar las operaciones. Monitoreo del uso del espacio. El DBA deber de realizar un plan de monitoreo del uso del espacio y revisarlo con los responsables de los modelos para estar seguros de que los requerimientos de espacio fueron estimados debidamente. Este monitoreo debe de sr peridico y debe de tenerse al tanto a DTCI de cualquier desviacin de las estimaciones que previamente se haban hecho. DII deber adems monitorear el espacio para planear actividades de defragmentacin y reorganizacin, las cuales debern de planearse y anunciarse a los desarrolladores con al menos 1 semana de anticipacin. Tiempos de entrega de los discos. Es importante tener en cuenta este punto al moemtnjo de hacerse la planeacin y/o revisin del espacio requerido en las bases de datos, ya sea para crecimiento u otras operaciones. Los discos que se compran al proveedor que se maneja tardan en entregarse de 6 a 8 semanas despus de haberse colocado el pedido. Si los discos se piden a un tercero, el tiempo de entrega de los mismos es de 4 semanas despus de haber sido colocada la orden.