INTRODUCCIONEn este capítulo se describe la naturaleza y las relaciones de las estructuras lógicas de almacenamiento. Estas estructuras se crean y reconocen por la Base de datos Oracle y no están reconocidas por el sistema operativo. Las estructuras de datos utilizadas para el almacenamiento y recuperación de la información son muchas veces altamente complejas con el objeto de crear un sistema eficiente. OBJETIVO Es lograr la representación de un sistema del “mundo real” de manera que pueda ser manejado en un mundo informático. El presente trabajo tiene como objetivo efectuar un análisis comparativo que sirva como referencia para la selección en un determinado sistema de gestión de base de datos 1.- ESTRUCTURAS LOGICAS DE ALMACENAMIENTO ESTRUCTURA LÓGICA: Desde el punto de vista lógico, la base de datos debe tener al menos 1 “FileGroup” el cual contiene a toda la metadata de la misma base de datos, es decir tablas y vistas de sistema, a este “FileGroup” inicial se le conoce como “Primario” y está presente en todas las bases de datos. Todos los objetos de usuario que contengan data, ya sean tablas o índices, deben estar ligados a un “FileGroup”, esto se puede definir al momento de ejecutar la sentencia DDL de creación del objeto, si no se indica a que “FileGroup” estará ligado ese objeto, este pertenecerá al “FileGroup” por defecto definido en la base de datos. La base de datos solo puede tener definido 1 solo default “FileGroup”. Las bases de datos pueden tener hasta 32767 “FileGroups” definidos, según los límites establecidos para la última versión de SQL Server, la cual es SQL Server 2008 R2. Uno de los propósitos de los “FileGroups” es poder distribuir la data a través de varios discos duros físicos, de esta manera se puede obtener mayor rendimiento en las operaciones de I/O debido a que más de un disco trabajara al mismo tiempo. Otro de los propósitos es poder esconder la ubicación física real de la información a los programadores, ya que para ellos la tabla “X” pertenece al “FileGroup” “A”, pero no saben en que data files físicamente se encuentra la información de la tabla “X”. Los “FileGroups” pueden contener 1 o más “Datafiles”, y cada uno de estos datafiles se pude encontrar en un discos diferentes, lo cual también agilizara las consultas y los ingresos de información a las tablas que se encuentren asignadas a este “FileGroup”, debido a que SQL Server distribuirá la información uniformemente a través de todos los “DataFiles” del “FileGroup”. Para la gestión del almacenamiento de una base de datos existen 4 conceptos bien definidos que deben ser conocidos para poder comprender la forma en la que se almacenan los datos. Vamos a ver la diferencia entre bloque, extensión, segmento y espacio de tablas. Bloques: Se tratan de la unidad más pequeña. Generalmente debe múltiple del tamaño de bloque del sistema operativo, ya que es la unidad mínima que va a pedir Oracle al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un trabajo extra ya que el sistema debería obtener más datos de los estrictamente necesarios. Se especifica mediante DB_BLOCK_SIZE Extensiones: Se forma con uno o más bloques. Cuando se aumenta tamaño de un objeto se usa una extensión para incrementar el espacio. Segmentos: Grupo de extensiones que forman un objeto de la base de datos, como por ejemplo una tabla o un índice. Espacio de tablas: Formado por uno o más datafiles, cada datafile solo puede pertenecer a un determinado tablespace En general, el almacenamiento de los objetos de la base de datos (tablas e índices fundamentalmente) no se realiza sobre el archivo o archivos físicos de la base de datos, sino que se hace a través de estructuras lógicas de almacenamiento que tienen por debajo a esos archivos físicos, y que independizan por tanto las sentencias de creación de objetos de las estructuras físicas de almacenamiento. Esto es útil porque permite que a esos "espacios de objetos " les sean asociados nuevos dispositivos físicos (es decir, más espacio en disco) de forma dinámica cuando la base de datos crece de tamaño más de lo previsto. Posibilita además otra serie de operaciones como las siguientes: • Asignar cuotas específicas de espacio a usuarios de la base de datos. • Controlar la disponibilidad de los datos de la base de datos, poniendo fuera de uso alguno de esos espacios de tablas individualmente. • Realizar copias de seguridad o recuperaciones parciales de la base de datos. • Reservar espacio para almacenamiento de datos de forma cooperativa entre distintos dispositivos. El administrador de la base de datos puede crear o borrar nuevos espacios lógicos de objetos, añadir o eliminar ficheros físicos de soporte, utilizados como espacio temporal de trabajo, definir parámetros de almacenamiento para objetos destinados a ese espacio de datos, todos los gestores relacionales que venimos introduciendo como ejemplos siguen esta filosofía. En el caso de Oracle, sobre los ficheros físicos de datos (datafiles) se definen los tablespaces. Por lo tanto, una base de datos Oracle se compone lógicamente de tablcspaccs, y físicamente de datafilcs. Su creación es sencilla, con la sentencia GREAT'', TABLESPACE: CREATE TABLESPACE usuarios DATAFILE `datal.ora' SIZE 50M También es sencillo ampliar el espacio destinado a un tablespace utilizando el comando ALTER TABLESPACE: ALTER TABLESPACE usuarios ADD DATAFILE 'data2.ora' SIZE 25M Para hacer más grande una base de datos, las opciones disponibles son tres: Cada base de datos contiene un tablespace llamado SYSTEM que es creado automáticamente al crear la base de datos. Contiene las tablas del diccionario de datos para la base de datos en cuestión. Es recomendable no cargar datos de usuario en SYSTEM, para dejarlos como espacio de objetos del sistema. Si además los datos de usuario están en tablespaces sitos en otros dispositivos, el rendimiento mejorará porque las tablas del diccionario de datos se acceden frecuentemente y por lo tanto son un cuello de botella potencial desde el punto de vista del acceso a disco. A la hora de estimar el espacio necesario para cl tablespace sys-nsm hay que tener en cuenta que las unidades de programación PL-SQL (entorno de programación SQL proporcionado por Oracle) almacenadas en la base de datos (procedimientos, paquetes, disparos y funciones) almacenan sus datos en SYSTEM. De acuerdo con lo comentado anteriormente, tablas e índices se ubicarán en el tablespaee indicado en el momento de su creación con la correspondiente sentencia CREATE. Si no se dice nada, se situarán en el tablespace por defecto asociado al usuario creador. 1.1 DEFINICION 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. Los espacios de almacenamiento son unidades virtuales que aparecen en el Explorador de archivos. Puede usarlos como cualquier otra unidad, por lo que es fácil trabajar con los archivos que contienen. Puede crear grandes espacios de almacenamiento y agregar más unidades a ellos cuando la capacidad del grupo sea insuficiente. Si tiene dos o más unidades en el grupo de almacenamiento, puede crear espacios de almacenamiento que no se verán afectados por un error en la unidad, o incluso en dos unidades, si crea un espacio de almacenamiento de reflejo triple. Entre las unidades de medición de almacenamiento, es decir, el tamaño o espacio disponible en cada uno de estos dispositivos, se cuentan: - el bit o dígito binario: un bit es la unidad de información más pequeña que el procesador manipula y físicamente se representa con un elemento como un pulso o un punto. Ocho bits constituyen un byte. - el byte o unidad de almacenamiento: cuenta con 8 bits. Equivale a un sólo carácter, como una letra o un número. - el kilobyte (kB): equivale a 1.024 bytes y a menudo es la unidad en la que se registra el almacenamiento de archivos pequeños como documentos de texto o imágenes en baja resolución. - el megabyte (MB): equivale a más de un millón de bytes, y comúmente archivos de tamaño considerable se almacenan en esta unidad. Por ejemplo, imágenes en alta resolución, archivos, carpetas, documentos y hasta programas. - el gigabyte (GB): equivale a mil millones de bytes. Es la unidad que más típicamente se maneja hoy en día, y los ordenadores más comunes proveen de un espacio de más de 100 GB para memoria. Los archivos de todo un ordenador de tamaño considerable se miden en GB. - el terabyte (TB): equivale a 1024 Gigabytes y es una medida que se utiliza para referir a ordenadores de alta complejidad. 1.2 DEFINICION Y CREACION DEL ESPACIO ASIGNADO PARA CADA BASE DE DATOS. Las bases de datos se almacenan en ficheros o archivos. Existen diferentes formas de organizaciones primarias de archivos que determinan la forma en que los registros de un archivo se colocan físicamente en el disco y, por lo tanto, cómo se accede a éstos. Las distintas formas de organizaciones primarias de archivos son: Existe una segunda forma de acceder a los datos llamada organización secundaria o estructura de acceso auxiliar. Estas permiten que los accesos a los registros de un archivo basado en campos alternativos, sean más eficientes que los que han sido utilizados para la organización primaria de archivos. El DBMS asigna espacio de almacenamiento a las bases de datos cuando los usuarios introducen create database o alter database. El primero de los comandos puede especificar uno o más dispositivos de base de datos, junto con la cantidad de espacio en cada uno de ellos que será asignado a la nueva base de datos. Si se utiliza la palabra clave default o se omite completamente la cláusula on , el DBMS pone la base de datos en uno o más de los dispositivos predeterminados de base de datos especificados en master..sysdevices Para especificar un tamaño (en este ejemplo, 4MB) para una base de datos que se va a almacenar en una ubicación predeterminada, utilice on default = size de esta forma: Create database newpubs on default = 4 Para situar la base de datos en dispositivos específicos, dé el nombre del dispositivo o dispositivos en que desea almacenarla. Como la sintaxis indica, puede solicitar que se almacene en más de un dispositivo de base de datos, con una cantidad de espacio diferente en cada uno. Todos los dispositivos mencionados en create database deben estar enumerados en sysdevices. En otras palabras, deben haberse inicializado con disk init . La instrucción siguiente crea la base de datos newdb y asigna 3MB en mydata y 2MB en newdata. Como en el ejemplo anterior, la base de datos y el diario de transacciones no se separan: Create database newdb on mydata = 3, newdata = 2 Warning! A menos que cree una base de datos pequeña o que no sea crucial, sitúe siempre el diario en un dispositivo de base de datos aparte. Si la cantidad de espacio solicitada a un dispositivo específico de base de datos no está disponible, el DBMS crea la base de datos con tanto espacio como sea posible en cada dispositivo y muestra un mensaje informando el espacio asignado en cada uno. (Esto no se considera un error.) Si hay menos espacio del mínimo necesario para una base de datos en el dispositivo especificado (o en el predeterminado, si no se especifica un nombre), el comando create database falla. La propiedad de la base de datos DbStorageLocation especifica la carpeta donde Analysis Services crea y administra todos los archivos de metadatos y datos de la base de datos. Todos los archivos de metadatos están almacenados en la carpeta DbStorageLocation, con la excepción del archivo de metadatos de la base de datos, que está almacenado en la carpeta de datos del servidor. Hay dos consideraciones importantes al establecer el valor de propiedad de la base de datos DbStorageLocation: La propiedad de base de datos DbStorageLocation se debe establecer en una ruta UNC de carpeta existente o en una cadena vacía. De manera predeterminada, la carpeta de datos del servidor es una cadena vacía. Si la carpeta no existe, se producirá un error al ejecutar un comando Create, Attach o Alter. La propiedad de la base de datos DbStorageLocation no se puede establecer para que apunte a la carpeta de datos del servidor ni a ninguna de sus subcarpetas. Si la ubicación apunta a la carpeta de datos del servidor o a cualquiera de sus subcarpetas, se producirá un error al ejecutar un comando Create, Attach o Alter. 1.3 BITACORAS Cada base de datos en SQL Server tiene un Transaction Log asociado con ella. El Transaction log (en español bitácora de transacciones) es un componente esencial de SQL Server, el cual la utiliza para registrar un historial de cada modificación que sufre la base de datos como resultado de las transacciones. Dicho registro es de vital importancia para mantener la integridad de los datos y poder deshacer los cambios resultantes de transacciones incompletas ya sea por error del sistema o por la cancelación por parte de los usuarios. Durante la operación de la base de datos la escritura a la bitácora tiene prioridad, es decir, todos los cambios primero se escriben a la bitácora y luego se aplican a la base de datos. Debido a su importancia, es imperativo respaldar la bitácora regularmente ya que de no hacerlo, será imposible recuperar la base de datos en caso de falla. La estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente: 1. Nombre de la transacción: Nombre de la transacción que realizó la operación 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 después de la escritura. Existen otros registros de bitácora especiales para grabar sucesos importantes durante el proceso de transacción tales como : < T1, inicio > < T1, x, v1, v2 > < T1, commit > Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que se modifique la base de datos. También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora. Los registros de la bitácora deben residir en memoria estable como resultado el volumen de datos en la bitácora puede ser exageradamente grande. 1.4 PARTICIONES La creación de particiones en una base de datos mejora el rendimiento y simplifica el mantenimiento. Al dividir una tabla grande en tablas individuales más pequeñas, las consultas que tengan acceso únicamente a una parte de los datos pueden ejecutarse con mayor rapidez, ya que deben recorrer menos datos. Las tareas de mantenimiento (por ejemplo, volver a generar los índices o hacer copias de seguridad de una tabla), pueden ejecutarse con mayor rapidez. Se puede conseguir la creación de particiones sin dividir las tablas si las tablas se colocan físicamente en unidades de disco individuales. La colocación de una tabla en una unidad física y de las tablas relacionadas en una unidad independiente puede mejorar el rendimiento de las consultas, debido a que, cuando se ejecutan consultas que implican combinaciones entre las tablas, varios encabezados de discos leen los datos al mismo tiempo. Se pueden utilizar grupos de archivos de SQL Server para especificar los discos en los que se colocarán las tablas. Una partición es una división de una base de datos lógica o sus elementos constituyentes en partes independientes. La partición de bases de datos se hace normalmente por razones de mantenimiento, rendimiento o manejo. Una aplicación popular y favorable es en un Sistema de Administración de Base de Datos Distribuida. Cada partición puede ser extendida hasta múltiples nodos, y los usuarios en el nodo pueden hacer transacciones locales en la partición. Esto aumenta el rendimiento en sitios que tienen transacciones regularmente involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la seguridad. Esta partición puede hacerse creando bases de datos más pequeñas separadas (cada una con sus propias tablas, índices, y registros de transacciones) o dividiendo elementos seleccionados, por ejemplo, solo una tabla. Partición horizontal consiste en poner diferentes filas en diferentes tablas. Por ejemplo, clientes con códigos postales menores que 50000 están almacenados en la tabla ClientesEste, mientras que los clientes con códigos postales mayores o iguales a 50000 están almacenados en la tabla ClientesOeste. Las dos tablas de partición son entonces ClientesEste y ClientesOeste, mientras que una vista con una unión podría ser creada con las dos tablas para poder dar una vista completa de todos los clientes. Partición vertical consiste en crear miles de tablas con miles de columnas y crear tablas para poner las columnas restantes. Para crear y administrar particiones, deberá usar el cuadro de diálogo Administrador de particiones. Para ver el cuadro de diálogo Administrador de particiones, en SQL Server Data Tools, haga clic en el menú Tabla y en Particiones. Para crear una nueva partición 1. En el diseñador de modelos, seleccione la tabla en la que desea definir una partición. 2. Haga clic en el menú Tabla y en Particiones. 3. En Administrador de particiones, en el cuadro de lista Tabla, compruebe o seleccione la tabla en la que desea crear particiones y, a continuación, haga clic enNuevo. 4. En Nombre de partición, escriba un nombre para la partición. De forma predeterminada, el nombre de la partición predeterminada se incrementará numéricamente para cada nueva partición. 5. Puede seleccionar las filas y las columnas que se incluirán en la partición mediante el modo de vista previa de tabla o mediante una consulta SQL creada con el Editor de consultas. Para utilizar el modo de vista previa de tabla (valor predeterminado), haga clic en el botón Vista previa de la tabla cerca de la esquina superior derecha de la ventana de vista previa. Seleccione las columnas que desea incluir en la partición activando la casilla situada junto al nombre de cada columna. Para filtrar las filas, haga clic con el botón secundario en un valor de celda y, a continuación, haga clic en Filtrar por valor de celda seleccionado. Para utilizar una instrucción SQL, haga clic en el botón Editor de consultas cerca de la esquina superior derecha de la ventana de vista previa y, a continuación, escriba o pegue una instrucción de consulta SQL en la ventana de consulta. Para validar la instrucción, haga clic Validar. Haga clic en Diseño para abrir el Diseñador de consultas. Para copiar una partición 1. En Administrador de particiones, en el cuadro de lista Tabla, compruebe o seleccione la tabla que contiene la partición que desea copiar. 2. En la lista Particiones, seleccione la partición que desea copiar y haga clic en Copiar. 3. En Nombre de partición, escriba un nuevo nombre para la partición. Para eliminar una partición 1. En Administrador de particiones, en el cuadro de lista Tabla, compruebe o seleccione la tabla que contiene la partición que desea eliminar. 2. En la lista Particiones, seleccione la partición que desea eliminar y haga clic en Eliminar. 1.5 ESPACIOS PRIVADOS El espacio que consumen estas bases de datos de usuario crece a una velocidad que es mucho más rápida que la tasa típica. Dependiendo de los parámetros de crecimiento automático de estas bases de datos de usuario, los archivos de base de datos pueden crecer con más frecuencia que crecen en casos típicos. La parte no utilizada del espacio que consumen estas bases de datos de usuario será mayor que la parte sin usar típica. Al ver las propiedades de las estructuras de almacenamiento de información de estas bases de datos de usuario, como la estructura de almacenamiento de información del montón, el árbol de la imagen de texto y el índice agrupado, verá que gran cantidad de espacio no utilizado. El espacio reservado para las entradas de índice en la tabla sysindexes se aumenta en múltiplos de 8. Sin embargo, el espacio utilizado para las entradas de índice en la tabla sysindexes aumenta por un pequeño número, como 1 o 2. Es decir, para cada ocho páginas asignadas en una nueva extensión, nunca se utilizan sólo unas pocas páginas desde ese punto. Un «espacio privado» permite que los administradores y redactores gestionen el conjunto de datos del sitio. Algunas bases de datos tienen estos espacios privados llamados comúnmente paneles de control, que son formularios que aparecen al abrir la base de datos. Los paneles de control sirven de "puerta principal" o "recibidor" de una base de datos en el sentido de que dirigen a las personas hacia determinadas tareas, como introducir o buscar datos. Sirven también para mantener alejados a los usuarios de las tablas que contienen los datos en tiempo real. Cuando reciba una base de datos, debe adentrarse más allá del panel de control para averiguar cómo están estructurados los datos, pero merece la pena echar un vistazo inicial al panel de control. Le puede ofrecer algún indicio sobre las tareas que el diseñador de la base de datos consideró que realizarían los usuarios habitualmente con los datos. Puede hacer clic en los vínculos del panel de control para ver qué objetos, como formularios e informes, abren. 1.6 ESPACIOS PARA OBJETOS Estimar el tamaño de los objetos de base de datos es una tarea imprecisa. Causado por la fragmentación del disco, espacio libre, y el uso de columnas de longitud variable hace que la estimación del tamaño difícil, porque hay una amplia gama de posibilidades para los tipos de columnas y longitudes de fila. Después de comenzar a estimar el tamaño de su base de datos, cree una base de datos de prueba y llenarla con datos representativos. Desde el Centro de control, puede acceder a una serie de utilidades que están diseñados para ayudarle a determinar los requisitos de tamaño de los objetos de bases de datos diferentes: Usted puede seleccionar un objeto y luego usar el "Tamaño estimado" de utilidad. Esta utilidad le puede decir el tamaño actual de un objeto existente, como una tabla. A continuación, puede cambiar el objeto y la utilidad calcular nuevos valores estimados para el objeto. La utilidad le ayudará requisitos aproximados de almacenamiento, teniendo en cuenta el crecimiento futuro. Se proporciona rangos posibles de tamaño para el objeto: tanto el tamaño más pequeño, sobre la base de valores de corriente, y el mayor tamaño posible. Puede determinar las relaciones entre los objetos mediante la opción "Mostrar relacionada" ventana. Usted puede seleccionar cualquier objeto de base de datos en la instancia de solicitud y "Generar DDL". Esta función utiliza la utilidad db2look para generar estados de definición de datos para la base de datos. En cada uno de estos casos, o la opción "Mostrar SQL" o el botón "Mostrar Command" está disponible para usted. Puede guardar las declaraciones resultantes de SQL o mandatos en archivos de script que se utilizará más adelante. Todas estas utilidades han ayuda en línea para ayudarle. Sigue estas utilidades en cuenta al planificar su base de datos física Cuando se estima el tamaño de una base de datos, la contribución de los siguientes debe ser considerada: Las tablas de catálogo del sistema Tabla de datos de usuario Los datos de campo largo De objetos grandes (LOB) Índice de espacio Entrar espacio de ficheros Espacio de Trabajo Temporal Los requisitos de espacio relacionados con los siguientes no se discuten: La base de datos local del directorio de archivos La base de datos del directorio de archivos del sistema La sobrecarga de gestión de archivo requerido por el sistema operativo, incluyendo: Archivo de tamaño de bloque Directorio de espacio de control Los DBMS se basan en archivos para almacenar datos, y estos archivos, o conjuntos de datos, residen en medios de almacenamiento, o dispositivos. Una buena parte del trabajo del DBA implicará la planificación para el almacenamiento real de la base de datos. Algunas tecnologías de almacenamiento son más adecuadas que otras. Sin embargo, la naturaleza mecánica de la unidad de disco los hace más vulnerables al fracaso de los componentes de otro equipo. Además, las formas en que las unidades de disco son utilizados por las bases de datos pueden hacer que la gestión del almacenamiento impredecibles, como la barra lateral "Modern DBMS de uso de disco“ Puede usarse RAID para mejorar la seguridad de los datos. Para aplicaciones de misión crítica la integridad de los datos puede ser más importante que la disponibilidad de datos. Si el soporte es poco fiable y un fallo de las causas de corrupción de datos, los datos perdidos puede ser más de un problema que el tiempo de inactividad. Es imperativo, por tanto, que las soluciones de almacenamiento de base de datos para protegerlos a toda costa. La recuperación de datos desde medios de almacenamiento lleva mucho más tiempo en completarse que la recuperación de datos desde la memoria caché o la memoria. El rendimiento de la base de datos depende de la entrada y salida a disco. La cantidad de datos almacenados es mayor que nunca antes, y los datos se almacenados por más tiempo. Algunos DBMS permiten al tamaño de los archivos temporales de expandirse y contraerse de forma automática. Dependiendo del tipo y la naturaleza de las operaciones de base de datos en proceso, esta fluctuación puede provocar picos de uso del disco El crecimiento de la capacidad de almacenamiento aumenta aún más la complejidad de la gestión de datos y bases de datos. Muchas organizaciones están implementando nuevas tecnologías de almacenamiento, tales como almacenamiento en red (NAS) y redes de área de almacenamiento (SAN), para ayudar a controlar la cantidad cada vez mayor de almacenamiento necesario para los usos modernos. La gestión del almacenamiento en el entorno dinámico de hoy es una tarea difícil DBA. Hay muchos problemas de almacenamiento que deben ser resueltos antes de que un DBA pueda crear una base de datos. Uno de los temas más importantes es la cantidad de espacio para permitir la base de datos. El cálculo espacial debe tener en cuenta no sólo tablas, índices, sino también, y dependiendo del DBMS, el registro de transacciones. Cada una de estas entidades probablemente requerirá un archivo separado o conjunto de datos, para el almacenamiento persistente. El DBA debe separar en diferentes discos a los archivos para: 2.-SEGMENTOS Un segmento de datos es una característica de optimización que ayuda a dirigir consultas a los datos de las particiones adecuadas. Los segmentos de datos no sustituyen ni son una alternativa a la especificación del origen de la partición. Es decir, los segmentos de datos no se deben usar para limitar los datos seleccionados de la tabla de hechos de la partición ni los datos incluidos en la partición. Los segmentos de datos solo son aplicables a objetos que utilizan el método de almacenamiento ROLAP. Con el Asistente para particiones, puede especificar un segmento de datos cuando cree una partición. Un sector de datos de una partición debería reflejar lo más fielmente posible los datos de la partición. Por ejemplo, si una partición está limitada a los datos de 2004, el segmento de datos de la partición debería especificar el miembro 2004 de la dimensión de tiempo. No siempre es posible especificar un segmento de datos que refleje el contenido exacto de una partición. Por ejemplo, si una partición contiene datos solamente para enero y febrero, pero los niveles de la dimensión de tiempo son año, trimestre y mes, el Asistente para particiones no puede seleccionar los miembros de enero y febrero a la vez. En estos casos, seleccione el miembro primario de los miembros que reflejen el contenido de la partición. Un segment 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 el, ya que si la tabla crece, el segmento tambien crece con ella. Físicamente todo objeto en base de datos no es mas que un segmento dentro de un datafile. Se puede decir que, un segmento es a un objeto de base de datos, lo que un datafile a un tablespace; el segmento es la representación física del objeto en base de datos (el objeto es solo una definición lógica). Los segmentos son los equivalentes físicos de los objetos que almacenan datos. El uso efectivo de los segmentos requiere que el DBA conozca los objetos, que utiliza una aplicación, cómo los datos son introducidos en esos objetos y el modo en que serán recuperados. Un segmento está constituido por secciones llamadas extensiones, que son conjuntos contiguos de bloques Oracle. Una vez que una extensión existente en un segmento no puede almacenar más datos, el segmento obtendrá del espacio de tabla otra extensión. Este proceso de extensión continuará hasta que no quede más espacio disponible en los ficheros del espacio de tablas, o hasta que se alcance un número máximo de extensiones por segmento. Existen 5 tipos de segmento: De datos. De índices. De rollback. Temporales. De bootstrap. 3.- MEMORIA COMPARTIDA Las conexiones a Microsoft SQL Server desde un cliente que se ejecuta en el mismo equipo utilizan el protocolo de memoria compartida. La memoria compartida no tiene propiedades que se puedan configurar. Memoria compartida es el protocolo que se intenta utilizar en primer lugar y no se puede desplazar de la posición prioritaria de la lista Protocolos habilitados de la lista Propiedades de los protocolos de cliente. El protocolo de memoria compartida se puede deshabilitar, lo que resulta útil para solucionar problemas con los demás protocolos. No es posible crear un alias con el protocolo de memoria compartida, pero si el protocolo está habilitado, al conectarse al Motor de base de datos por nombre se crea una conexión de memoria compartida. Las cadenas de conexión de memoria compartida utilizan el formato lpc:<servername>[\instancename]. Los sistemas de memoria compartida distribuida (DSM) representan la creación hibrida de dos tipos de computación paralelos: la memoria distribuida en sistemas multiprocesador y los sistemas distribuidos. Ellos proveen la abstracción de memoria compartida en sistemas con memorias distribuidas físicamente y consecuentemente combinan las mejores características de ambos enfoques. Modelos de Consistencia. La cuestión de la consistencia adquiere importancia en los sistemas DSM que replican el contenido de la memoria compartida mediante su almacenamiento en las cachés de computadores separados. Cada proceso tiene un gestor de réplicas local, el cual está encargado de mantener copias en caché para los objetos. En la mayor parte de las implementaciones, los datos se leen desde las réplicas locales por cuestiones de eficiencia, pero las actualizaciones deben propagarse al resto de gestores de réplica. El gestor de réplica local se implementa mediante una combinación del middleware (el nivel DSM en tiempo de ejecución en cada proceso) y del núcleo. Es normal que el middleware realice la mayor parte del procesamiento DSM. Incluso en las implementaciones de DSM basadas en páginas, el núcleo normalmente proporciona únicamente una correspondencia de páginas básica, el manejo de fallos de página y los mecanismos de comunicación, mientras que el middleware es responsable de implementar las políticas de compartición de páginas. Si los segmentos DSM son persistentes, entonces uno o más servidores de almacenamiento (por ejemplo, servidores de archivos) actuarán también como gestores de réplicas. Además de la gestión de la caché, una implementación DSM puede almacenar las actualizaciones y reducir los costes de comunicación mediante la propagación de múltiples actualizaciones a la vez. Un modelo de consistencia de memoria (Mosberger 1993) especifica las garantías de consistencia que un sistema DSM realiza sobre los valores que los procesos leen desde los objetos, dado que en realidad acceden sobre una réplica de cada objeto y que múltiples procesos pueden actualizar los objetos. Téngase en cuenta que esto es diferente de la noción de consistencia de alto nivel y dependiente de aplicación. Sin embargo, la mayor parte de las aplicaciones tienen requisitos de consistencia muy estrictos. Es preciso proporcionar a los programadores un modelo que se ajuste razonablemente al comportamiento que la memoria debería tener. Mosberger (1993) realiza un bosquejo de un conjunto de modelos que han sido pensados para multiprocesadores de memoria compartida y sistemas DSM software. Los principales modelos de consistencia que se pueden implementar en la práctica en sistemas DSM son la consistencia secuencial y los modelos basados en consistencia débil. Memoria Compartida Distribuida con base en páginas. El esquema de DSM propone un espacio de direcciones de memoria virtual que integra la memoria de todas las computadoras del sistema, y su uso se realiza mediante paginación. Las páginas quedan restringidas a estar necesariamente en un único nodo. Cuando un programa intenta acceder a una posición virtual de memoria, se comprueba si esa página se encuentra de forma local. Si no se encuentra, se provoca un fallo de página, y el sistema operativo solicita la página al resto de nodos. El sistema funciona de forma análoga al sistema de memoria virtual tradicional, pero en este caso los fallos de página se propagan al resto de ordenadores, hasta que la petición llega al nodo que tiene la página virtual solicitada en su memoria local. A primera vista este sistema parece más eficiente que el acceso a la memoria virtual en disco, pero en la realidad ha mostrado ser un sistema demasiado lento en ciertas aplicaciones, ya que provoca un tráfico de páginas excesivo. Memoria Compartida Distribuida con Variables. Un método más estructurado que la DSM con base a páginas consiste en compartir sólo ciertas variables y estructuras de datos necesarias para más de un proceso. Ahora el problema pasa a ser la forma de mantener una base de datos distribuida, en potencia duplicada, consistente en las variables compartidas. Uno de los aspectos más importantes a tratar de estos sistemas es el de si las variables compartidas deben o no duplicarse, y de qué manera, parcial o total. Si se duplicasen existiría más potencial que en un sistema DSM basado en páginas, en términos de actualización, dado que las escrituras en las variables compartidas individuales se pueden aislar. Dos de los ejemplos más interesantes de este tipo de sistemas son el Munin y el Midway; el primero se basa en una implantación software de la consistencia de liberación, y el segundo consiste en compartir las estructuras de datos individuales, permitiendo que los programas multiprocesador existentes y los nuevos se ejecuten de manera eficiente en las multicomputadores, con ligeros cambios de código. Aquí las comunicaciones entre los diferentes procesadores se realizan a través de accesos a un espacio compartido de direcciones. Entre sus principales ventajas se encuentra la facilidad de programación. Esta memoria define: Munin: -Consistencia de liberación. -Protocolos múltiples. -Directorios. -Sincronización. Munin: Se basa en objetos del software (usa MMU). a) Variables ordinarias. b) Variables de datos compartidos. c) Variables de sincronización. Operación básica con variables ordinarias: a. No se comparten. b. Solo son accedidas por el proceso que las creo. Operación básica con variables de datos compartidos: Son declaradas como tales. Operación básica con variables de sincronización: -Son accedidas mediante procedimientos de acceso proporcionados por el sistema. -Cerraduras: lock y unlock. -Barreras: increment y wait. Midway: -Consistencia de entrada. -Implantación. Memoria Compartida Distribuida basada en objetos. Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria. Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no modulares y se consideran incompatibles. Puesto que en muchos lenguajes de programación los datos se encuentran organizados como objetos y no como variables simples, los sistemas de MCD basados en objetos intentan transportar datos por la red utilizando como unidad de manipulación el objeto y no las páginas o las variables. Los procesos que se ejecutan en los distintos computadores que componen el sistema tienen acceso a un espacio de objetos compartidos, en lugar de a un espacio lineal de direcciones. El sistema es responsable de la ubicación y administración de es- tos objetos compartidos. Un proceso puede invocar métodos de un objeto compartido, independientemente de la ubicación del proceso y del objeto. Los objetos están protegidos por el ocultamiento de información, por lo que los procesos no pueden acceder directamente al estado interno de ningún objeto compartido. Esto facilita algunas optimizaciones dentro del sistema. Por ejemplo, puede relajarse el modelo de consistencia sin que el programador tenga conocimiento alguno. Al igual que en el caso de la granularidad a nivel de variables compartidas, cuando se utiliza el objeto como unidad para compartir es posible eliminar el false sharing. Además, también en este caso es factible utilizar un protocolo de actualización en vez de uno de invalidación. Sin embargo, quizás la mayor ventaja de este modelo es su modularidad y flexibilidad, a la vez que permite una integración limpia con la sincronización. La principal desventaja es el aumento en el overhead que se produce por la manipulación aun más indirecta de la memoria. En realidad, este es un problema inherente al uso de objetos. Un ejemplo de un sistema de MCD basado en objetos es Linda [11], un sistema basado en una memoria compartida altamente estructurada y que es accedida a través de un pequeño conjunto de primitivas que se agregan a lenguajes tradicionales como C y Fortran. El espacio de objetos se llama tuple space, o espacio de tuplas. Los procesos pueden insertar y remover tuplas al espacio, desde cualquier computador. Casos de estudio. La memoria compartida distribuida se implementa utilizando uno de los siguientes métodos o bien una combinación de ellos, hardware especializado, memoria virtual paginada convencional o middleware: Hardware: las arquitecturas multiprocesador de memoria compartida basadas en una arquitectura NUMA (por ejemplo, Dash [Lenoski y otros 1992] y PLUS [Bisiani y Ravishankar 1990] se basan en hardware especializado para proporcionar a los procesadores una visión consistente de la memoria compartida. Gestionan las instrucciones de acceso a memoria LOAD y STORE de forma que se comuniquen con la memoria remota y los módulos de caché según sea necesario para almacenar y obtener datos. Esta comunicación se realiza sobre sistemas de interconexión de alta velocidad similares a una red. El prototipo del multiprocesador Dash tiene 64 nodos; conectados mediante una arquitectura NUMA. Memoria virtual paginada: muchos sistemas, incluyendo Ivy [Li y Hudak 1989], Munin [Carter y otros 1991], Mirage [Fleisch y Popek 1989], Clouds [Dasgupta y otros 1991], Choices [Sane y otros 1990], COOL (Lea y otros 1993] y Mether [Minnich y Farber 1989], implementan DSM como una región de memoria virtual que ocupa el mismo rango de direcciones en el espacio de direcciones de cada proceso participante. Este tipo de implementación normalmente sólo es factible sobre una colección de computadores homogéneos con formatos de datos y de paginación comunes. Middleware: algunos lenguajes del tipo de Orca [Bal y otros 1990] y middleware como Linda [Carriero y Gelernter 1989] junto con sus derivados JavaSpaces y TSpaces [Wyckoff y otros 1998] proporcionan DSM sin necesidad de soporte hardware o de paginación, de una forma independiente de la plataforma. En este tipo de implementación, la computación se implementa mediante la comunicación entre instancias del nivel de soporte de usuario en los clientes y los servidores. Los procesos realizan llamadas a este nivel cuando acceden a datos en DSM. Las instancias de este nivel en los diferentes computadores acceden a los datos locales y se intercambian información siempre que sea necesario para el mantenimiento de la consistencia. 4.-INSTANCIAS MULTIPLES Una instancia de Motor de base de datos es una copia del ejecutable de sqlservr.exe que se ejecuta como un servicio de sistema operativo. Cada instancia administra varias bases de datos del sistema y una o varias bases de datos de usuario. Cada equipo puede ejecutar varias instancias de Motor de base de datos. Las aplicaciones se conectan a la instancia para realizar el trabajo en una base de datos administrada por la instancia. Una instancia de Motor de base de datos funciona como un servicio que controla todas las solicitudes de aplicación para trabajar con datos de cualquiera de las bases de datos administradas por dicha instancia. Es el destino de las solicitudes de conexión (inicios de sesión) de aplicaciones. La conexión se ejecuta en una conexión de red si la aplicación y la instancia están en equipos independientes. Si la aplicación y la instancia están en el mismo equipo, la conexión de SQL Server se puede ejecutar como una conexión de red o una conexión en memoria. Cuando una conexión se ha completado, una aplicación envía instrucciones Transact-SQL a través de la conexión hasta la instancia. La instancia resuelve las instrucciones de Transact-SQL en operaciones con los datos y objetos de las bases de datos y, si se han concedido los permisos necesarios a las credenciales de inicio de sesión, realiza el trabajo. Los datos recuperados se devuelven a la aplicación, junto con cualesquiera mensajes como errores. Puede ejecutar múltiples instancias de Motor de base de datos en un equipo. Una instancia puede ser la instancia predeterminada. La instancia predeterminada no tiene nombre. Si una solicitud de conexión especifica solo el nombre del equipo, se establece la conexión a la instancia predeterminada. Una instancia con nombre es una instancia en la que se especifica un nombre de instancia al instalar la instancia. Una solicitud de conexión debe especificar el nombre del equipo y el nombre de instancia para conectar a la instancia. No hay ningún requisito para instalar una instancia predeterminada; todas las instancias que se ejecutan en un equipo pueden ser instancias con nombre. La memoria compartida contiene todos los datos intervenidos, como: • Grupo de memorias intermedias • Tabla de bloqueos • Memoria intermedia del registro, que contiene las entradas del registro que esperan a ser volcadas en el almacenamiento estable • Planes de consulta en caché, que se pueden reutilizar si se envía de nuevo la misma consulta La exclusión mutua se puede implementar por medio de funciones del sistema operativo llamadas semáforos. Implementaciones alternativas, con menos sobrecargas, utilizan instrucciones atómicas especiales soportadas por el hardware de la computadora; un tipo de instrucción atómica comprueba una posición de la memoria y la establece a uno automáticamente. Los mecanismos de exclusión mutua también se utilizan para implementar pestillos. CONCLUSION Después de un breve análisis en el trabajo podemos llegar a conclusión que cada sistema tiene diferentes características, ventajas así como inconvenientes por tal razón la elección de uno u otro sistema para gestionar una base de datos vendrá definida por las necesidades de cada usuario. Por ejemplo nos dimos cuenta que cuanto mayor es la base de datos mayores son lo requerimientos de hardware. BIBLIOGRAFÍA http://www.estructurayprogramacion.com/materias/administracion-de-base-de- datos/estrucrturas-logicas-de-almacenamiento/23/08/2012 AUTOR: JOSE FERNANDEZ OCA RUIZ. http://share.pdfonline.com/cafcc187cd58446684afe42bbbaa7be2/torres%20gon zalez%20victor%20alfonso%20conceptos.htm/016/05/2O11/AUTOR: FRANCISCO REYES ALVARADO. http://ylez.wordpress.com/2010/03/20/bitacoras-de-bases-de-datos/03/10/2000 AUTOR: JOAQUIN GONZALEZ FIERRO http://share.pdfonline.com/cafcc187cd58446684afe42bbbaa7be2/torres%20gon zalez%20victor%20alfonso%20conceptos.htm 22/03/2013 AUTOR: Víctor Alfonso torres González Conceptos del 3 http://www.estructurayprogramacion.com/materias/administracion-de-base-de- datos/espacios-de-objetos/05/07/2013 AUTOR: PEDRO LARA DE LEON. http://tavoberry.com/blog/crear-una-bitacora-en-mysql/--- MTRO. GUSTAVO REYES HERNÁNDEZ - JUN• 09•10