miércoles, 31 de mayo de 2017

Unidad 5: Seguridad

5.1 Respaldo y Recuperación
El respaldo es uno de los pasos más importantes que puedes dar para proteger tu información. Cuando algo sale mal, como fallas en disco duro, borrado accidental de archivos o infecciones por malware, son tu último recurso. En esta edición, te explicamos cómo respaldar tu información y preparar una estrategia adecuada para ti.

Qué Respaldar y Cuándo

Existen dos aspectos fundamentales para decidir qué respaldar: la información que hayas generado o que sea importante para ti, como documentos, fotografías o videos; o toda, incluyendo tu sistema operativo y cualquier programa que hayas instalado. El primer aspecto limita el proceso de respaldo, mientras que el segundo hace que sea más fácil recuperar el sistema en caso de un fallo completo. Si no estás seguro de qué respaldar, respalda todo. A continuación, tendrás que decidir qué tan seguido respaldar tu información. Lo más común es hacerlo cada hora, diariamente, semanalmente, etc. Para usuarios caseros, los programas de respaldo personal como Time Machine de Apple o Copias de seguridad y restauración de Windows, permitirán fijar un horario automático de respaldo “prográmalo y olvídate”. Otras soluciones ofrecen “protección continua”, en la cual los archivos nuevos o modificados son respaldados inmediatamente tan pronto sean cerrados. Si perteneces a una organización con muchas computadoras, quizás te gustaría definir tu propio calendario. Sería bueno que consideraras cuánta información estás dispuesto a perder en el peor de los casos. Por ejemplo, si respaldas diariamente, puedes perder una jornada de trabajo si tu computadora falla al final del día. Muchas organizaciones programan respaldos diarios fuera de las horas pico para minimizar el impacto la operación normal.

Cómo Respaldar

En general, existen dos recursos en los que puedes respaldar tu información: medios físicos o almacenamiento en la nube. Ejemplos de medios físicos incluyen DVD’S, dispositivos USB, cintas magnéticas o discos duros adicionales. Evita respaldar en el mismo dispositivo que contiene los archivos originales. Cuando uses medios físicos asegúrate de etiquetarlos, tanto interna (en el nombre del archivo) como externamente (sobre el dispositivo), para que puedas identificar fácilmente fecha y hora del respaldo.

Puedes almacenar el respaldo en un contenedor con llave, a prueba de fuego y de agua, dependiendo del medio que elegiste. Una opción más robusta es almacenar copias de tus respaldos fuera de las instalaciones. Para respaldos personales, puede ser tan simple como almacenarlos en casa de un miembro de la familia o en una caja de seguridad. Las organizaciones quizá deseen contratar un servicio profesional para transportar y almacenar los respaldos de forma segura. Dependiendo de qué tan sensibles sean y dónde se almacenen los respaldos, tal vez convenga cifrarlos.

Muchos de estos problemas se solucionan con respaldos en la nube. Realizar copias de seguridad en la nube es tan sencillo como instalar o configurar una aplicación en tu computadora. Después de configurar las opciones de respaldo, archivos nuevos y modificados son respaldados automáticamente a través de Internet en servidores del centro de datos del proveedor.

Finalmente, necesitas decidir por cuánto tiempo conservarás tus respaldos. Es probable que los usuarios caseros no necesiten mantenerlos por más de treinta días. Algunas organizaciones cuentan con políticas o requerimientos legales para resguardar por periodos más largos, así como reglas para la destrucción de respaldos obsoletos. Si estás respaldando información de tu organización, verifica con el grupo de TI, legal o de gestión de registros para estar seguro. Respecto a las opciones de respaldo en la nube, es posible que te cobren con base a la cantidad de datos que respaldes, así que es importante ser cuidadoso de no acumular una gran deuda.

Recuperación

Respaldar tu información es sólo la mitad de la batalla; ahora tienes que asegurarte de que puedes recuperarla fácilmente. Practica regularmente tu proceso de recuperación, tal y como harías en un simulacro de sismo, esto te ayudará a asegurar que todo funcione correctamente en caso de necesitarlo. Comprueba por lo menos una vez al mes que el programa de respaldos está funcionando adecuadamente. Por lo menos trata de recuperar un archivo. Para una prueba más robusta, sobre todo para las organizaciones, considera hacer la recuperación completa del sistema y verifica que sea recuperable. Si no cuentas con hardware externo para la prueba de recuperación completa del sistema, restaura archivos y carpetas importantes en una ubicación diferente y luego verifica si recuperaste y puedes abrir todo.

5.1.1 Espejeo (Mirroring)

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de dase de datos, ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los otros dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

5.1.1.1 Beneficios del Espejeo de Datos en un DBMS

La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes ventajas:

Incrementa la disponibilidad de una base de datos. Si se produce un desastre en el modo de alta seguridad con conmutación automática por error, la conmutación por error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos. Para obtener más información, vea Conmutación de roles, más adelante en este tema.

Aumenta la protección de los datos. La creación de reflejo de la base de datos proporciona una redundancia completa o casi completa de los datos, en función de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener más información, vea Modos de funcionamiento, más adelante en este tema.

Un asociado de creación de reflejo de la base de datos que se ejecute en SQL Server 2008 Enterprise o en versiones posteriores intentará resolver automáticamente cierto tipo de errores que impiden la lectura de una página de datos. El socio que no puede leer una página, solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la copia sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de los casos. Para obtener más información, vea Reparación de página automática (grupos de disponibilidad/creación de reflejo de base de datos).

Mejora la disponibilidad de la base de datos de producción durante las actualizaciones. Para minimizar el tiempo de inactividad para una base de datos reflejada, puede actualizar secuencialmente las instancias de SQL Server que hospedan los asociados de creación de reflejo de la base de datos. Esto incurrirá en el tiempo de inactividad de solo una conmutación por error única. Esta forma de actualización se denomina actualización gradual. Para obtener más información, vea Instalar un Service Pack en un sistema con un tiempo de inactividad mínimo para bases de datos reflejadas.

5.1.2. Réplica (Replication)
La replicación es el proceso de copiar y mantener actualizados los datos en varios nodos de bases de datos ya sean estos persistentes o no. Éste usa un concepto donde existe un nodo amo o maestro (master) y otros sirvientes o esclavos (slaves).

La replicación de discos y particiones es la respuesta a una parte importante de esas dos acciones de mantenimiento. La replicación es el proceso mediante el cual se genera una copia exacta de parte del sistema. Esa parte puede ser desde un archivo hasta una carpeta, una partición, un disco o incluso varios discos.

La replicación es útil para:

· Copia de Seguridad

En condiciones normales, una base de datos replicada de forma correcta es válida como copia de seguridad.

Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor maestro.

· Mejorar la Escalabilidad

Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados.

Podríamos usar herramientas como MySQL Proxy para balancear las consultas de lectura entre los servidores replicados y enviar las consultas de actualización de datos al maestro.

· Alta Disponibilidad

En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados de manera que si uno se cae se continue prestando servicio.

El Log Binario

El log binario es un archivo binario gestionado por el servidor de base de datos en el que se registran todas las sentencias SQL de modificación de datos o estructura.

En el caso de la replicación es importante saber que cada servidor esclavo se conecta al servidor maestro y le solicita que le envíe las sentencias registradas en los logs binarios a partir de una posición, para ello, cada esclavo mantiene un archivo a modo de índice en donde registra la posición actual de la replicación.

Gracias a esto, podemos detener el esclavo (STOP SLAVE), que haya un corte de red, etc... De manera que cuando se vuelva a iniciar la replicación (START SLAVE) o se reestablezca la comunicación... Pase el tiempo que pase) el esclavo solicitará al maestro todas las sentencias a ejecutar desde su estado actual y las irá ejecutando secuencialmente de manera que en cuestión de segundos ambos servidores tendrán las bases de datos con el mismo contenido y estructura.

Probando la Replicación

1. En el servidor esclavo ejecute el comando SHOW SLAVE STATUS y observe que el mensaje que le muestra es un mensaje que indica que está esperando eventos del maestro...

2. Modifique algo en el maestro y verifique que instantáneamente se replica en el esclavo.

3. Detenga el esclavo durante un tiempo, realice cambios (cree tablas, modifique registros...) en el maestro e inicie el esclavo. En cuestión de milisegundos ambas bases de datos deberían de ser iguales.

5.1.2.1 Beneficios de la Réplica de Datos en un DBMS

La replicación se usa mucho en sistema de acceso a datos por varios motivos:

· Rendimiento: Normalmente y dependiendo del caso, hay más lectura que escritura en una base de datos, por lo que tener varios nodos solo procesando la lectura puede traer un gran beneficio de rendimiento en una base de datos muy consultada.

· Prueba de Fallas: Un esclavo estando casi sincrónicamente actualizado puede ser útil en caso de que el nodo maestro caiga, este puede reemplazarlo y así no detener el servicio.

· Fiabilidad: Muchas veces se puede tener una replicación para tener la seguridad de que los datos están siendo copiados a otro nodo, en caso de sufrir un desperfecto en el maestro.

· Generación de Bloqueos: aunque ésta es más precisa, también se puede usar para procesos que necesiten leer datos, generando bloqueos, al hacerlo sobre un esclavo esto no interviene en el funcionamiento de todo el sistema, es muy usado para por ejemplo, hacer copias de seguridad, o extraer grandes cantidades de datos para generar estadísticas.

5.1.3 Métodos de Respaldo de un DBMS

En mySQL existen varios métodos para la realización de un backup y esto se debe principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se esté manejando (InnoDB, MyISAM, ISAM). Así por ejemplo para la presente práctica se utilizó el tipo de tabla InnoDB y el método de backup utilizado es el que funciona con este tipo de tablas.

InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de codigo abierto. Entre sus características principales estan que soporta transacciones con características ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), tiene bloque de registros e integridad referencial (cosa que no maneja ISAM, ni myISAM). Esta última es una de sus características más importantes pues una base de datos sin integridad referencial, es nada más un conjunto de datos que no denotan información.

Este tipo de almacenamiento también ofrece una alta fiabilidad y consistencia. El mismo gestiona el control de los datos y no se lo deja al sistema operativo, una de sus desventajas es que no tiene una buena compresión de datos, por lo que ocupa un poco más de espacio que myISAM.

5.1.3.1 Elementos y Frecuencia de Respaldo

Normalmente cuando uno plantea que va a respaldar los datos de su PC a una persona en una compañía uno tiene que definir muy bien cuál es la información crítica para la empresa, por ejemplo la música que guarde un empleado en su PC no es crítica para las actividades de la empresa ni lo son las fotos de su última fiesta. En cambio su correo electrónico, proyectos, informes y papeles administrativos si lo suelen ser y tener un respaldo de estos es clave para el funcionamiento de la empresa en caso de cualquier eventualidad.

Normalmente lo datos o información que es respaldada por las empresas es:

· Archivos creados por aplicaciones, como por ejemplo .doc, .odt, .xls, .mdb, .pdf, .ppt entre otros.

· Archivos de correo electrónico

· Directorios telefónicos y de contactos

· Favoritos de los navegadores como Firefox e Internet Explorer

· Base de datos

· Configuraciones de los equipos

· Archivos de CAD, PSD, XCF, etc.

· Imágenes y Fotografías de proyectos

· Configuraciones de servicios

Clasificación de Respaldos

· Copias de Información (Backups)

Estos respaldos son sólo duplicados de archivos que se guardan en "Tape Drives" de alta capacidad. Los archivos que son respaldados pueden variar desde archivos del sistema operativo, bases de datos, hasta archivos de un usuario común. Existen varios tipos de Software que automatizan la ejecución de estos respaldos, pero el funcionamiento básico de estos paquetes depende del denominado archive bit.

Este archive bit indica un punto de respaldo y puede existir por archivo o al nivel de "Bloque de Información" (típicamente 4096 bytes), esto dependerá tanto del software que sea utilizado para los respaldos así como el archivo que sea respaldado. Este mismo archive bit es activado en los archivos (o bloques) cada vez que estos sean modificados y es mediante este bit que se llevan a cabo los tres tipos de respaldos comúnmente utilizados:

· Respaldo Completo ("Full")

Guarda todos los archivos que sean especificados al tiempo de ejecutarse el respaldo. El archive bit es eliminado de todos los archivos (o bloques), indicando que todos los archivos ya han sido respaldados.

· Respaldo de Incremento ("Incremental")

Cuando se lleva a cabo un Respaldo de Incremento, sólo aquellos archivos que tengan el archive bit serán respaldados; estos archivos (o bloques) son los que han sido modificados después de un Respaldo Completo. Además cada Respaldo de Incremento que se lleve a cabo también eliminará el archive bit de estos archivos (o bloques) respaldados.

· Respaldo Diferencial ("Differential")

Este respaldo es muy similar al "Respaldo de Incremento", la diferencia estriba en que el archivo bit permanece intacto.

Frecuencia de Actualización de la Información

Hay dos puntos importantes en cuanto a la actualización de la información:

· Que tan frecuentemente se actualiza la información

· Si queremos guardar un histórico de la información o no

No toda la información se actualiza con la misma frecuencia, hay información que puede durar años sin ser modificada y otra que se actualice constantemente todos los días, es importante definir qué información se actualiza y en qué momento para hacer una política de respaldo más eficiente.

La mayoría de las aplicaciones de respaldos hacen esto automáticamente fijándose en la fecha de modificación del archivo y comparándola con la que tiene en el respaldo.

El otro punto es si queremos hacer un respaldo con históricos o duplicados, en este caso tenemos que indicarle al programa que no queremos que nos borre o sobrescriba ningún archivo y que vaya guardando los archivos con su respectiva fecha y con qué frecuencia queremos hacer el respaldo.



En caso de que haya información que se pueda sobrescribir o actualizar, se realiza un respaldo incremental donde sólo se actualiza lo que ha cambiado del archivo lo que mejora la eficiencia de nuestro sistema. Esto realmente va a depender del tipo de información y varía de empresa a empresa pero es algo importante que tengamos que tomar en cuenta ya que toda la información no es igual.

5.1.3.2 Comandos para Respaldo de Datos

A continuación vamos a exponer los pasos y comandos para realizar la replicación de una base de datos en un único servidor esclavo. Si quisiéramos configurar más esclavos, los pasos a realizar serían los mismos sobre cada uno de los esclavos.

1. Creamos un usuario MySQL en el servidor maestro con privilegios de replicación.

2. El servidor esclavo se autentificará frente al servidor maestro como un usuario normal.

3. Para crear el usuario debemos ejecutar desde la consola de comandos de mysql las siguientes sentencias SQL:

CREATE USER '<replication_user>'@'<slave_address>' IDENTIFIED BY '<replication_user_password>'

GRANT REPLICATION SLAVE ON *.* TO '<replication_user>'@'<slave_address>'

4. Con la sentencia anterior el usuario sólo tendría permiso de acceso desde la máquina <slave_address>, en caso de no requerir esta medida de seguridad puedes sustituir el comodín % por el parámetro <slave_address>.

Configuración del Servidor Maestro

1. Deberemos agregar las siguientes líneas al final del archivo de configuración del servidor MySQL, por defecto: <MySQL_HOME>/my.ini

2. Identificador único del servidor MySQL dentro de todos los servidores implicados en la replicación.

Server – id = 1

3. Al especificar el parámetro log-bin estamos activando el log binario.

4. No especificamos un valor para el parámetro de configuración (por defecto será <nombre_maquina > - bin).

Log – bin =

5. El log binario sólo tendrá las actualizaciones realizadas sobre la base de datos "bd_autentia"

6. Si además quisiéramos replicar otras bases de datos, duplicaríamos este parámetro para cada base de datos.

Binlog – do – db = bd_autentia

Configuración del Servidor Esclavo

1. Deberemos agregar las siguientes líneas al final del archivo de configuración del servidor MySQL, por defecto: <MySQL_HOME>/my.ini

2. Identificador único del servidor MySQL dentro de todos los servidores implicados en la replicación.

Server – id = 2

3. Nombre del archivo binario que almacena las instrucciones pendientes de ejecutar, por defecto: <host_name> - relay - bin.index

Relay – log =

4. Nombre o dirección IP del maestro.

Master – host = <master_address>

5. El esclavo se conecta a través de un usuario al maestro. Identificador del usuario.

Master – user = <replication_user>

6. El esclavo se conecta a través de un usuario al maestro. Contraseña del usuario.

Master – password = <replication_user_password>

7. Número de segundos que esperará el esclavo para reintentar conectarse al maestro en caso de una pérdida de conexión.

Master – connect – retry = 50

8. Número de reintentos de reconexión

Master – retry – count = 5000

9. Realizamos una copia de seguridad de la base de datos del maestro sobre el servidor esclavo.

Desde la consola ejecutamos los siguientes comandos:

[Maestro]: <MYSQL_HOME>/bin/mysql -u root –password = <contraseña> -e "FLUSH TABLES WITH READ LOCK"

Para limpiar las caches y bloquear el acceso de cualquier aplicación a la base de datos.

[Maestro]: <MYSQL_HOME>/bin/mysqldump --u root –password = <contraseña> --opt bd_autentia > backup.sql

Realizamos una copia completa de la base de datos en el archivo backup.sql.

[Esclavo]: <MYSQL_HOME>/bin/mysql --user=root –password = <contraseña> bd_autentia < backup.sql

Para Restaurar la Copia de Seguridad en el Esclavo

[Esclavo]: <MYSQL_HOME>/bin/mysqladmin -u root –password = <contraseña> shutdown

Detenemos el Servidor Esclavo

[Maestro]: <MYSQL_HOME>/bin/mysqladmin -u root –password = <contraseña> shutdown

Detenemos el servidor maestro (Se desbloquearán las tablas de las bases de datos previamente bloqueadas)

[Esclavo]: <MYSQL_HOME>/bin/mysqld-nt –defaults file="<MYSQL_HOME>\my.ini" MySQL

Iniciamos el Servidor, el cual Tomará la Nueva Configuración:



[Maestro]: <MYSQL_HOME>/bin/mysqld-nt --defaults-file="<MYSQL_HOME>\my.ini" MySQL

5.1.3.3 Métodos de Recuperación de un DBMS

Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema guarda las información sobre los cambios de las transacciones esta información se guarda en el registro del sistema.

1. Si hay un fallo como la caída del disco, el sistema restaura una copia se seguridad del registro, hasta el momento del fallo.

2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para restaurar a un estado consistente. En este caso no se necesita una copia archivada.

Actualización Diferida: No se actualiza físicamente la base de datos Hasta que no haya alcanzado su punto de confirmación.

Actualización Inmediata: La base de datos puede ser actualizada por Algunas Operaciones antes de que esta última alcance su punto de confirmación.

Tipos de Almacenamiento

· Almacenamiento Volátil: no sobrevive a las caídas del sistema.

· Almacenamiento no Volátil: disco, cinta...: existen accidentes.

· Almacenamiento Estable Frente al no Estable: la información no se pierde “nunca”, se repite en varios medios no volátiles (disco) con modos de fallo independientes.

Almacenamiento en Caché (Búfer) de los Bloques de Disco

El proceso de recuperación se entrelaza con funciones del sistema operativo en particular con el almacenamiento en caché o en búfer en la memoria principal, Normalmente se reserva una colección de búferes en memoria, denominados caché DBMS. Se utiliza un directorio para rastrear los elementos de la base de datos que se encuentra en los búferes.

Bit Sucio: que puede incluirse en la entrada del directorio, para indicar si se ha modificado o no el búfer.

Pin: Un pin dice que una página en caché se está accediendo actualmente.

Actualización en el Lugar (In Place): Escribe en el búfer la misma ubicación de disco original.

Shadowing (en la Sombra): Escribe un búfer actualizado en una ubicación diferente.

BFIM (Before Image): Imagen antes de la actualización.

AFIM (After Image): Imagen después de la actualización.

Registro Antes de la Escritura, Robar/No-Robar y Forzar no Forzar

En este caso, el mecanismo de recuperación debe garantizar la grabación de la BFIM de los datos en la entrada apropiada del registro del sistema y que esa entrada se vuelque en el disco antes que la BFIM sea sobrescrita con la AFIM de la base de datos del disco.

Puntos de Control en el Registro del Sistema y Puntos de Control Difusos

Otro tipo de entrada en el registro es el denominado punto de control (checkpoint). En este punto el sistema escribe en la base de datos, en disco, todos los búferes del DBMS que se han modificado.

No tienen que rehacer sus operaciones, es decir, ESCRIBIR en caso de una caída del sistema.

El gestor de recuperaciones de un DBMS debe decidir en qué intervalos tomar un punto de control.

La toma de un punto de control consiste en las siguientes acciones:

1. Suspender temporalmente la ejecución de las transacciones.

2. Forzar la escritura de disco de todos los búferes de memoria que se hayan modificado.

3. Escribir un registro (checkpoint) en el registro del sistema y forzar la escritura del registro en el disco.

4. Reanudar la ejecución de las transacciones.

Diarios para Recuperación

· Se utilizan también los términos log y journal.

· Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos.

· Esta información permite recuperar.

· Se almacena en disco.

· Operaciones posibles a reflejar:

[start, T]

[write, T, X, valor_viejo, valor_nuevo] (Opcional)

[read, T, X]

[commit, T]

[abort, T]

undo, redo





5.3.1.6 Monitoreo de Modos de Operación

Las operaciones forman parte de las actividades diarias relacionadas con el hardware y software utilizado en las organizaciones. Esta función es particularmente importante cuando se ejecutan tares de cómputos centralizados y destacan las siguientes:

1. Administración de Recursos: La administración es responsable de asegurar que los recursos necesarios estén disponibles para realizar las actividades.

2. Normas y Procedimientos: La administración es responsable por establecer las normas y los procedimientos necesarios para todas las operaciones en conformidad con las estrategias y políticas generales del negocio.

3. Monitoreo de los Procesos de Operación: La administración es responsable de monitorear y medir la efectividad y eficiencia de los procesos de operación. La administración es responsable de monitorear y medir la efectividad y eficiencia de los procesos de operación, de modo que los procesos sean mejorados a través del tiempo.

4. Operaciones de Plataforma de Hardware

5. Soporte Técnico

6. Cronogramas de Ejecución de Trabajos

7. Control de Entrada/Salida de Datos

8. Aseguramiento de Calidad

9. Control de Cambios

10. Administración de la Configuración

11. Función de Bibliotecario

12. Procedimientos de Administración de Problemas

13. Procedimientos para Monitorear el Uso Eficaz y Eficiente de los Recursos

14. Administración de la Seguridad Física y del Ambiente



15. Administración de la Seguridad de Información

5.3.1.7 Monitoreo de Espacios Espejeados

La administración de espejeado protege la integridad de los datos mediante el almacenamiento de copias de los datos en varios discos. El tipo e grupo de discos determina los niveles de creación de reflejo con el que se crean los archivos en un grupo de discos.

Cuando se crea un grupo de discos, se especifica un tipo de grupo de discos ASM basado en los siguientes 3 niveles de redundancia.

· Normal de 2 vías de reflejo

· Alta de 3 vías de reflejo



· Externa a no utilizar la creación de reflejos ASM

5.3.2 Auditoría

Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la información almacenada en las bases de datos incluyendo la capacidad de determinar:

· Quién accede a los datos

· Cuándo se accedió a los datos

· Desde qué tipo de dispositivo/aplicación

· Desde que ubicación en la Red

· Cuál fue la sentencia SQL ejecutada

· Cuál fue el efecto del acceso a la base de datos

La auditoría se ha convertido en una herramienta importante en los últimos 10 años, para el análisis de las violaciones de datos.

La auditoría es el control y registro de las acciones de la base de datos de usuarios seleccionados, tanto de los usuarios de bases de datos y no usuarios de la base de datos.

Normalmente se utiliza la auditoría para realizar las siguientes actividades:

· Activar la Rendición de Cuentas de las Acciones: Estas incluyen acciones tomadas de un determinado esquema, tabla o fila, o que afecten a un contenido específico.

· Disuadir a los usuarios (o los otros, como intrusos) de acciones inapropiadas basadas en la rendición de cuentas.



· Investigar actividades sospechosas.

5.3.2.1 Habilitación y Deshabilitar el Modo de Auditoría

La activación de la auditoría en Oracle Database viene definida por el valor del parámetro: audit_trail. Para comprobar si la auditoría de la base de datos está activada ejecutaremos el siguiente comando SQL:

select name, value

from v$parameter

where name like 'audit_trail'

Posibles valores del parámetro AUDIT_TRAIL:

Para activar la auditoría:

ALTER SYSTEM SET audit_trail = "DB" SCOPE=SPFILE;

Para desactivar la auditoría ejecutaremos el siguiente comando:

ALTER SYSTEM SET audit_trail = "NONE" SCOPE=SPFILE;

· DBA_AUDIT_TRAIL: Muestra la auditoría estándar (de la tabla AUD$) relativa al usuario actual. Es una lista de todas las entradas en la tabla SYS.AUD$ colectada por el comando audit.

· DBA_AUDIT_OBJECT: Lista las opciones de entrada de auditorías para auditar objetos de la base de datos.

· DBA_AUDIT_EXISTS: Es una lista de entradas de auditoría generadas por la opción EXISTS en el comando AUDIT.

· DBA_AUDIT_SESSION: Muestra las entradas de auditoría generadas por conexiones o desconexiones de sesiones.

· DBA_AUDIT_STATEMENT: Es una lista de entradas de auditorías, con la información recolectada de las opciones de sentencias en el comando audit.

Las principales vistas para obtener resultados de la auditoría, son las siguientes:

Funcionamiento del Comando AUDIT

Permite iniciar los tipos de auditoría que a continuación se detallan. Este comando puede funcionar aunque no esté activada la auditoría de la base de datos, pero no dejara constancia, para que funcione correctamente es necesario que la auditoría esté activada.

Sintaxis:

AUDIT

{sql_statement_clause \ schema_object_clause | NETWORK}

[BY {SESSION \ ACCES}]

[WHENEVER [NOT] SUCCESFUL];

Funcionamiento del Comando NOAUDIT

Se utiliza para detener la actividad de auditoría que se había activado previamente con la instrucción AUDIT.

Sintaxis:

NOAUDIT

{sql_statement_clause | schema_object_clause | NETWORK}



[WHENEVER [NOT] SUCCESFUL];

5.3.2.2 Consultas de las Tablas Vistas con Información de la Auditoría

El diccionario de la BD contiene una tabla llamada SYS.AUD$ que puede contener información sobre las operaciones realizadas por los usuarios.

Para más fácil manejo de esta tabla, existen una serie de vistas que se crean ejecutando el script de SQL CATAUDIT.SQL que son de mucha utilidad a la hora de visualizar la información recogida. Esas vistas se borran con el script CATNOAUD.SQL



Dependiendo de los objetos auditados se recoge distinto tipo de información. En cualquier caso, siempre se recoge sobre el usuario, sesión, terminal, objeto accedido, operación realizada y finalización de la operación.

5.4 Herramientas de Software y Hardware para Monitoreo y Administración Automática

Monitorizar es una tarea imprescindible del administrador. Obviamente no podemos monitorizar en todo momento y debemos hacerlo con cierta regularidad y de la manera más automatizada posible. Existen multitud de programas que permiten monitorizar, no solo nuestro servidor de base de datos, si no múltiples servicios en redes de toda clase.

Herramientas:

1. Consolas Administrativas Ilimitadas.

2. Consultas Personalizadas para agregar dentro de la Interfaz en forma Ilimitada.

3. Base de datos Abierta para integraciones personalizadas de otros dispositivos (equipos de comunicación, servidores etc.

· Control de Activos Tangibles y no Tangibles.

· Capacidad de cruzar información automática recolectada con la información insertada en forma manual.

· Creación y personalización en forma ilimitada por consultas Editables que nos permitirá adaptar necesidades reales que requiera la CMDB.

4. Bitácora de Uso de software por Día y Mes de los aplicativos brindado los minutos y horas de su utilización por PC.

Unidad 4: Operación y Mantenibilidad

4.1 Bitácoras de Trabajo del DBMS

Una bitácora es una herramienta (archivos o registros) que permite registrar,analizar, detectar y notificar eventos que sucedan en cualquier sistema de información utilizado en las organizaciones.
La estructura más ampliamente usada para grabar las acciones que se llevan en la base de datos.

Nos ayuda a recuperar la información ante algunos incidentes de seguridad, detección de comportamiento inusual, información para resolver problemas, evidencia legal, es de gran ayuda en las tareas de computo forense.
Permite guardar las transacciones realizadas sobre una base de datos en específico, de tal manera que estas transacciones puedan ser auditadas y analizadas posteriormente.


4.1.1 Funciones Específicas de las Bitácoras

La estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente:

Nombre de la Transacción
Valor antiguo
Valor Nuevo
Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que se modifique la base de datos.
También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora.

Los registros de la bitácora deben residir en memoria estable como resultado el volumen de datos en la bitácora puede ser exageradamente grande.
Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronización:

Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.

Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.

4.1.2 Recuperación (Rollback)

En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback (devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.



En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.

Una sentencia ROLLBACK también publicará cualquier savepoint existente que puediera estar en uso.

En muchos dialectos de SQL, los ROLLBACK son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras conexiones. Esto es vital para el buen funcionamiento de la Concurrencia.

La funcionalidad de rollback está normalmente implementada con un Log de transacciones, pero puede también estar implementada mediante control de concurrencia multiversión.

4.1.3 Permanencia (Commit)

En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción de comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no permanentes". Un uso popular es al final de una transacción de base de datos.

Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitió BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los savepoints (puntos de recuperación) existentes que puedan estar en uso.

En términos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transacción, es un rollback.

4.2 Definición de los Modos de Operación de un DBMS (Alta, Baja, Recovery)

La vida de todo archivo comienza cuando se crea y acaba cuando se borra. Durante su existencia es objeto de constante procesamiento, que con mucha frecuencia incluye acciones de consulta o búsqueda y de actualización. En el caso de la estructura archivos, entenderemos como actualización, además de las operaciones, vistas para vectores y listas enlazadas, de introducir nuevos datos (altas) o de eliminar alguno existente (bajas), la modificación de datos ya existentes, (operación muy común con datos almacenados). En esencia, es la puesta al día de los datos del archivo.

Una operación de alta en un archivo consiste en la adición de un nuevo registro. En un archivo de empleados, un alta consistirá en introducir los datos de un nuevo empleado. Para situar correctamente un alta, se deberá conocer la posición donde se desea almacenar el registro correspondiente: al principio, en el interior o al final de un archivo.

El algoritmo de ALTAS debe contemplar la comprobación de que el registro a dar de alta no existe previamente. Una baja es la acción de eliminar un registro de un archivo. La baja de un registro puede ser lógica o física. Una baja lógica supone el no borrado del registro en el archivo. Esta baja lógica se manifiesta en un determinado campo del registro con una bandera, indicador o “flag” -carácter *. $, etc.,-, o bien con la escritura o rellenado de espacios en blanco en el registro dado de baja

Altas
La operación de dar de alta un determinado registro es similar a la de añadir datos a un archivo. Es importante remarcar que en un archivo secuencial sólo permite añadir datos al final del mismo.

En otro caso, si se quiere insertar un registro en medio de los ya presentes en el archivo, sería necesaria la creación nueva del archivo.

El algoritmo para dar de alta un registro al final del fichero es como sigue:
algoritmo altas
leer registro de alta
inicio
abrir archivo para añadir
mientras haya más registros hacer {algunos lenguajes ahorran este bucle}
leer datos del registro
fin_mientras
escribir (grabar) registro de alta en el archivo
cerrar archivo
fin
Bajas
Existen dos métodos para dar de baja a un registro en un archivo secuencial, donde no es fácil eliminar un registro situado en el interior de una secuencia: Para ello podemos seguir dos métodos:

1) Utilizar y por tanto crear un segundo archivo auxiliar transitorio, también secuencial, copia del que se trata de actualizar. Se lee el archivo completo registro a registro y en función de su lectura se decide si el registro se debe dar de baja o no. En caso afirmativo, se omite la escritura en el archivo auxiliar. Si el registro no se va a dar de baja, este registro se reescribe en el archivo auxiliar

Tras terminar la lectura del archivo original, se tendrán dos archivos: original (o maestro) y auxiliar. El proceso de bajas del archivo concluye borrando el archivo original y cambiando el nombre del archivo auxiliar por el del inicial.
2) Guardar o señalar los registros que se desean dar de baja con un indicador o bandera que se guarda en un array; de esta forma los registros no son borrados físicamente, sino que son considerados como inexistentes.

Inevitablemente, cada cierto tiempo, habrá que crear un nuevo archivo secuencial con el mismo nombre, en el que los registros marcados no se grabarán.

Propósito de Backup y Recuperación

Como administrador de copia de seguridad, la tarea principal es diseñar, implementar y gestionar una estrategia de backup y recuperación. En general, el propósito de una estrategia de recuperación de copia de seguridad y es para proteger la base de datos contra la pérdida de datos y reconstruir la base de datos después de la pérdida de datos. Normalmente, las tareas de administración de seguridad son las siguientes:

Planificación y probar las respuestas a diferentes tipos de fallas.
Configuración del entorno de base de datos de copia de seguridad y recuperación.
La creación de un programa de copia de seguridad
Seguimiento de la copia de seguridad y entorno de recuperación
Solución de problemas de copia de seguridad
Para recuperarse de la pérdida de datos en caso de necesidad

Como administrador de copia de seguridad, es posible que se le pida que realice otros deberes que se relacionan con copia de seguridad y recuperación:

La preservación de datos, lo que implica la creación de una copia de base de datos para el almacenamiento a largo plazo

La transferencia de datos, lo que implica el movimiento de datos de una base de datos o un host a otro.

4.3 Comandos de Activación para los Modos de Operación


Para ser uso de los diferentes comandos para un modo de operación debemos estar como administrador o asuma un rol que incluya el perfil de derechos Service Management.

Comando STARTUP
Para el arranque de una base de datos hay tres fases de arranque, para realizar estas fases podemos utilizar startup más un comando, las tres fases son las siguientes:

Fase de no Montaje: se leen los parámetros del sistema, se inician las estructuras de memoria y los procesos de segundo plano. La instancia se arranca sin asociarla a la base de datos. Normalmente se utiliza cuando se modifica o se necesita crear el archivo de control:
startup nomount ;

Fase de Montaje: se asocia la instancia con la base de datos. Se usa el archivo de parámetros para localizar los archivos de control, que contienen el nombre de los archivos de datos y los registros rehacer. Los archivos de datos y los registros de rehacer no están abiertos, así que no son accesibles por usuarios finales para tareas normales. Para realizar esta fase se pueden utilizar dos comandos:

startup mount;

alter database mount;

Fase de Apertura: se abren los archivos de datos y los registros rehacer. La base de datos queda disponible para las operaciones normales. Es necesario que existan registros rehacer de lo contrario si no hay registros usamos el comando resetlogs, que crea registros nuevos. Para esta fase se pueden usar dos comandos:

startup open;
alter database open;
Si es necesario utilizar resetlogs:
startup open resetlogs;
alter database open resetlogs;
startup restrict (sólo permite la conexión de usuarios con el privilegio restricted sesion).
startup force (hace shutdown abort y arranca la BD).

Comando SHUTDOWN
El comando SHUTDOWN lo utilizamos parar una base de datos la cual consiste en varias cláusulas.

Shutdown Normal: Este es el valor por defecto, durante el proceso de parada no admite nuevas conexiones y espera que las conexiones actuales finalicen. En el próximo arranque la base datos no requiere procedimientos de recuperación.

Shutdown Immediate: Se produce una parada inmediata de la base de datos, durante el proceso de parada no permite nuevas conexiones y las actuales la desconecta, las transacciones que no estén commit se hara roolback de ellas. En el próximo arranque la base datos no requiere procedimientos de recuperación.

Shutdown Transactional: Se produce una parada hasta que hayan terminado las transacciones activas, no admite nuevas conexiones y tampoco nuevas transacciones, una vez que las transacciones activas van terminando va desconectando a los usuarios. En el próximo arranque la base datos no requiere procedimientos de recuperación.

Shutdown Abort: Aborta todos los procesos de una base de datos, durante el proceso de parada no permite nuevas conexiones y las actuales la desconecta, las transacciones que no estén commit se hará roolback de ellas. En el próximo arranque la base datos puede requerir procedimientos de recuperación.

Comando Describe

Este comando permite conocer la estructura de una tabla, las columnas que la forman y su tipo y restricciones.
DESCRIBE f1;

Comando SHOW TABLES y SHOW CREATE TABLE

El comando SHOW TABLES muestra las tablas dentro de una base de datos y SHOW CREATE TABLES muestra la estructura de creación de la tabla.

Modificación
Para realizar una modificación utilizamos el comando ALTER TABLE. Para usar ALTER TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla.

4.4- Manejo de Índices

El índice de una base de datos es una estructura alternativa de los datos en una tabla. El propósito de los índices es acelerar el acceso a los datos mediante operaciones físicas más rápidas y efectivas. En pocas palabras, se mejoran las operaciones gracias a un aumento de la velocidad, permitiendo un rápido acceso a los registros de una tabla en una base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuáles se hacen búsquedas frecuentes.
4.4.1 Tipos de Índices

Índices Compuestos

Un índice compuesto, también llamado índice concatenado, es un índice de varias columnas de una tabla. Las columnas de un índice compuesto que deben aparecer en el orden que tenga más sentido para las consultas que recuperar datos y no necesita ser adyacente en la tabla.

Los índices compuestos pueden acelerar la recuperación de datos para las instrucciones SELECT en la que el DONDE referencias cláusula totalidad o la parte principal de las columnas en el índice compuesto. Por lo tanto, el orden de las columnas utilizadas en la definición es importante. En general, las columnas de acceso más común van primero.

Índices Únicos y no Únicos
Los índices pueden ser únicos o no únicos. Índices únicos garantizar que no hay dos filas de una tabla tienen valores duplicados en la columna de clave o columna. Por ejemplo, dos empleados no pueden tener el mismo ID de empleado. Por lo tanto, en un índice único, existe una ROWID para cada valor de datos. Los datos de los bloques de hojas se ordenan sólo por clave.

Índices no únicas permiten valores duplicados en la columna o columnas indexadas. Por ejemplo, la columna 'nombre de la tabla de empleados puede contener varios valores Mike. Para un índice no único, el ROWID se incluye en la clave de forma ordenada, por lo que los índices no únicos se ordenan por la clave de índice y ROWID (ascendente).

Tipos de Índices
Los Índices de Árbol B

Estos índices son el tipo de índice estándar. Son excelentes para la clave principal y los índices altamente selectivos. Utilizado como índices concatenados, B-tree índice pueden recuperar los datos ordenados por las columnas de índice. Índices B-tree tienen los siguientes subtipos:

Índice de Tablas Organizadas

Una tabla de índice-organizada difiere de un montón-organizado porque los datos es en sí mismo el índice.

En este tipo de índice, los bytes de la clave de índice se invierten, por ejemplo, 103 se almacena como 301. La inversión de bytes extiende inserta en el índice durante muchos bloques.

Índices Descendentes

Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
Índices B-Tree de Racimo

Este tipo de índice se utiliza para indexar una clave de clúster tabla. En lugar de apuntar a una fila, los puntos clave para el bloque que contiene filas relacionadas con la clave de clúster.

Mapa de Bits y los Índices Bitmap Join

En un índice de mapa de bits, una entrada de índice utiliza un mapa de bits para que apunte a varias filas. En cambio, los puntos de entrada de un índice B-tree en una sola fila. Un índice de combinación de mapa de bits es un índice de mapa de bits para la unión de dos o más tablas. Consulte "Indicadores de mapa de bits".

Índices Basados ​​en Funciones

Este tipo de índice incluye columnas que, o bien se transforman por una función, tales como la función UPPER, o incluidos en una expresión. Índices B-tree o mapa de bits puede ser basado en las funciones.

Índices de Dominio de Aplicación

Este tipo de índice se crea por un usuario para los datos en un dominio específico de la aplicación. El índice físico no tiene que utilizar una estructura de índice tradicional y se puede almacenar ya sea en la base de datos Oracle como tablas o externamente como un archivo. Consulte "Indicadores de dominio de aplicación".

Índices B-Tree

Árboles B, abreviatura de árboles balanceados, son el tipo más común de índice de base de datos. Un índice B-tree es una lista ordenada de valores dividida en rangos. Mediante la asociación de una tecla con una fila o rango de filas, los árboles B proporcionan un excelente rendimiento de la recuperación para una amplia gama de consultas, incluyendo coincidencia exacta y búsquedas por rango.

4.4.2 Reorganización de Índices.


Un factor clave para conseguir una E/S de disco mínima para todas las consultas de bases de datos es asegurarse de que se creen y se mantengan buenos índices. Una vez creados los índices, se debe procurar mantenerlos para asegurarse que sigan trabajando en forma óptima. A medida que se agregan, modifican o borran datos se produce fragmentación. Esta fragmentación puede ser buena o mala para el rendimiento del sistema, dependiendo de las necesidades del trabajo de la base de datos.

Fragmentación de los Índices

La fragmentación es consecuencia de los procesos de modificación de los datos (instrucciones INSERT, UPDATE y DELETE) efectuados en la tabla y en los índices definidos en la tabla. Como dichas modificaciones no suelen estar distribuidas de forma equilibrada entre las filas de la tabla y los índices, el llenado de cada página puede variar con el paso del tiempo. Para las consultas que recorren parcial o totalmente los índices de una tabla, este tipo de fragmentación puede producir lecturas de páginas adicionales. Esto impide el recorrido paralelo de los datos. Existen dos tipos de fragmentación:

Interna: Fragmentación dentro de páginas individuales de datos e índices con espacios libres que generan la necesidad de más operaciones de E/S y más memoria para su lectura. Este hecho disminuye el rendimiento en ambientes de lectura, pero en algunos casos puede beneficiar las inserciones, que no requieren una división de páginas con tanta frecuencia.

Externa: Cuando el orden lógico de las páginas no es correcto, porque las páginas no son contiguas. El acceso a los datos es mucho más lento por la necesidad de búsqueda de los datos.

La fragmentación de índices se puede reparar reorganizando un índice o reconstruyéndolo. Para los índices fraccionados que fueron construidos en una estructura partida se puede usar cualquiera de estos métodos o bien en un índice completo o bien en un único fragmento del índice.

Detección de Fragmentación

El primer paso para decidir qué método de desfragmentación se va a utilizar consiste en analizar el índice para determinar el nivel de fragmentación. Si se usa la función del sistema sys.dm_db_index_physical_stats, se puede detectar la fragmentación de los índices de la base de datos thuban-homologada.


4.4.3 Reconstrucción de Índices

Es importante periódicamente examinar y determinar qué índices son susceptibles de ser reconstruidos. Cuando un índice está descompensado puede ser porque algunas partes de éste han sido accedidas con mayor frecuencia que otras. Como resultado de este suceso podemos obtener problemas de contención de disco o cuellos de botella en el sistema. Normalmente reconstruimos un índice con el comando ALTER INDEX.

Es importante tener actualizadas las estadísticas de la base de datos. Para saber si las estadísticas se están lanzando correctamente podemos hacer una consulta sobre la tabla dba_indexes y ver el campo last_analyzed para observar cuando se ejecutaron sobre ese índice las estadísticas.

Blevel (branch level) es parte del formato del B-tree del índice e indica el número de veces que Oracle ha tenido que reducir la búsqueda en ese índice. Si este valor está por encima de 4 el índice deberá de ser reconstruido.

ALTER INDEX <index_name> REBUILD;

Para reconstruir una partición de un índice podríamos hacer los siguiente:

ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING;




Unidad 3: Configuración y Administración del Espacio en Disco

3.1 Estructuras Lógicas de Almacenamiento

Para la gestión del almacenamiento de una base de datos existen 4 conceptos bien definidos que deben ser conocidos para poder comprender la forma en la que se almacenan los datos. Vamos a ver la diferencia entre bloque, extensión, segmento y espacio de tablas.

Bloques: Se tratan de la unidad más pequeña. Generalmente debe múltiple del tamaño de bloque del sistema operativo, ya que es la unidad mínima que va a pedir Oracle al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un trabajo extra ya que el sistema debería obtener más datos de los estrictamente necesarios. Se especifica mediante DB_BLOCK_SIZE

Extensiones: Se forma con uno o más bloques. Cuando se aumenta tamaño de un objeto se usa una extensión para incrementar el espacio.

Segmentos: Grupo de extensiones que forman un objeto de la base de datos, como por ejemplo una tabla o un índice.

Espacio de Tablas: Formado por uno o más datafiles, cada datafile solo puede pertenecer a un determinado tablespace

En general, el almacenamiento de los objetos de la base de datos (tablas e índices fundamentalmente) no se realiza sobre el archivo o archivos físicos de la base de datos, sino que se hace a través de estructuras lógicas de almacenamiento que tienen por debajo a esos archivos físicos, y que independizan por tanto las sentencias de creación de objetos de las estructuras físicas de almacenamiento. Esto es útil porque permite que a esos "espacios de objetos " les sean asociados nuevos dispositivos físicos (es decir, más espacio en disco) de forma dinámica cuando la base de datos crece de tamaño más de lo previsto. Posibilita además otra serie de operaciones como las siguientes:

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

· Controlar la disponibilidad de los datos de la base de datos, poniendo fuera de uso alguno de esos espacios de tablas individualmente.

· Realizar copias de seguridad o recuperaciones parciales de la base de datos.

· Reservar espacio para almacenamiento de datos de forma cooperativa entre distintos dispositivos.

El administrador de la base de datos puede crear o borrar nuevos espacios lógicos de objetos, añadir o eliminar ficheros físicos de soporte, utilizados como espacio temporal de trabajo, definir parámetros de almacenamiento para objetos destinados a ese espacio de datos, todos los gestores relacionales que venimos introduciendo como ejemplos siguen esta filosofía. En el caso de Oracle, sobre los ficheros físicos de datos (datafiles) se definen los tablespaces. Por lo tanto, una base de datos Oracle se compone lógicamente de tablespaces, y físicamente de datafiles. 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:

3.1.1 Definición de Almacenamiento de Bases de Datos

Las bases de datos suelen ser creadas para almacenar grandes cantidades de datos de forma permanente. Por lo general, los datos almacenados en éstas suelen ser consultados y actualizados constantemente.

La mayoría de las bases de datos se almacenan en las llamadas memorias secundarias, especialmente discos duros, aunque, en principio, pueden emplearse también discos ópticos, memorias flash, etc.

Las razones por las cuales las bases de datos se almacenan en memorias secundarias son:

· En general, las bases de datos son demasiado grandes para entrar en la memoria primaria.

· La memoria secundaria suele ser más barata que la memoria primaria (aunque esta última tiene mayor velocidad).

· La memoria secundaria es más útil para el almacenamiento de datos permanente, puesto que la memoria primaria es volátil.


3.1.2.- Definición y Creación del Espacio Asignado para cada Base de Datos

Las bases de datos se almacenan en ficheros o archivos. Existen diferentes formas de organizaciones primarias de archivos que determinan la forma en que los registros de un archivo se colocan físicamente en el disco y, por lo tanto, cómo se accede a éstos.

Las distintas formas de organizaciones primarias de archivos son:

· Archivos de Montículos (o no Ordenados): esta técnica coloca los registros en el disco sin un orden específico, añadiendo nuevos registros al final del archivo.

· Archivos Ordenados (o Secuenciales): mantiene el orden de los registros con respecto a algún valor de algún campo (clave de ordenación).

· Archivos de Direccionamiento Calculado: utilizan una función de direccionamiento calculado aplicada a un campo específico para determinar la colocación de los registros en disco.

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

· Organización Secundaria o Estructura de Acceso Auxiliar: Estas permiten que los accesos a los registros de un archivo basado en campos alternativos, sean más eficientes que los que han sido utilizados para la organización primaria de archivos.

El DBMS asigna espacio de almacenamiento a las bases de datos cuando los usuarios introducen create database o alter database. El primero de los comandos puede especificar uno o más dispositivos de base de datos, junto con la cantidad de espacio en cada uno de ellos que será asignado a la nueva base de datos.

Si se utiliza la palabra clave default o se omite completamente la cláusula on, el DBMS pone la base de datos en uno o más de los dispositivos predeterminados de base de datos especificados en master.sysdevices.

Para especificar un tamaño (por ejemplo, 4MB) para una base de datos que se va a almacenar en una ubicación predeterminada, se utiliza: on default = size de esta forma:

create database newpubs on default = 4

3.1.3.- Bitácoras

Son estructuras ampliamente utilizadas para grabar las modificaciones de la base de datos.

Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente:

· Nombre de la Transacción: Nombre de la transacción que realizó la operación de escritura.

· Nombre del Dato: El nombre único del dato escrito.

· Valor Antiguo: El valor del dato antes de la escritura.

· Valor Nuevo: El valor que tendrá el dato después de la escritura.

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.

La instrucción en MySQL para crear una bitácora en .txt se crea antes de acceder a la base de datos con la instrucción:

"xampp>mysql>bin>mysql -hlocalhost -uroot --tee=C:bitacora.txt"

La bitácora 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 después de la operación de insertar, otro para después de eliminar y el último para después de modificar para cada una de las 3 tablas de la base de datos.

3.1.4.- Particiones

Cuando alguna de las tablas de una base de datos llega a crecer tanto que el rendimiento empieza a ser un problema, es hora de empezar a conocer algo sobre optimización. Una característica de MySQL son las particiones.

Particionar tablas en MySQL nos permite rotar la información de nuestras tablas en diferentes particiones, consiguiendo así realizar consultas más rápidas y recuperar espacio en disco al borrar los registros. El uso más común de particionado es según la fecha.

Para ver si nuestra base de datos soporta particionado simplemente ejecutamos:

SHOW VARIABLES LIKE '%partition%';

Se puede particionar una tabla de 5 maneras diferentes:

· Por Rango: para construir las particiones se especifican rangos de valores.

ALTER TABLE contratos

PARTITION BY RANGE (YEAR (fechaInicio)) (

PARTITION partDecada80 VALUES LESS THAN (1990),

PARTITION partDecada90 VALUES LESS THAN (2000),

PARTITION partDecada00 VALUES LESS THAN (2010),

PARTITION partDefault VALUES LESS THAN MAXVALUE

);

La última partición (partDefault) tendrá todos los registros que no entren en las particiones anteriores. De esta manera nos aseguramos que la información nunca dejará de insertarse en la tabla.

· Por Listas: para construir nuestras particiones especificamos listas de valores concretos.

ALTER TABLE contratos

PARTITION BY LIST (YEAR (fechaInicio)) (

PARTITION partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988, 1989),

PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999),

PARTITION partDecada00 VALUES IN (2000, 2001, 2002, 2003, 2004, 2005, 2006,

2007, 2008, 2009),

PARTITION partDecada10 VALUES IN (2010, 2011, 2012, 2013, 2014, 2015, 2016,

2017, 2018, 2019)

);

· Por Hash: MySQL se encarga de distribuir las tuplas automáticamente usando una operación de módulo. Sólo hay que pasarle una columna o expresión que resulte en un entero (el hash) y el número de particiones que queramos crear.

ALTER TABLE contratos

PARTITION BY HASH (YEAR (fechaInicio))

PARTITIONS 7;

· Por Clave: similar a la partición por hash, pero en este caso no necesitamos pasarle un entero; MySQL utilizará su propia función de hash para generarlo. Si no se indica ninguna columna a partir de la que generar el hash, se utiliza la clave primaria por defecto.

ALTER TABLE contratos

PARTITION BY KEY ()

PARTITIONS 7;

· Compuesta: podemos combinar los distintos métodos de particionado y crear particiones de particiones

Borrar Particiones

Lo bueno de trabajar con particiones es que podemos borrar rápidamente registros sin tener que recorrer toda la tabla e inmediatamente recuperar el espacio en disco utilizado por la tabla.

Por ejemplo si queremos borrar la partición más antigua simplemente ejecutamos:

ALTER TABLE reports DROP PARTITION p201111;

Añadir particiones

En el ejemplo anterior las 2 últimas particiones creadas han sido:

PARTITION p201205 VALUES LESS THAN (TO_DAYS ("2012-06-01")),

PARTITION pDefault VALUES LESS THAN MAXVALUE

El problema es que todos los INSERT que se hagan después de mayo de 2012 se insertarán en pDefault. La solución sería añadir particiones nuevas para cubrir los próximos meses:

ALTER TABLE reports REORGANIZE PARTITION pDefault INTO (

PARTITION p201206 VALUES LESS THAN (TO_DAYS ("2012-07-01")),

PARTITION pDefault VALUES LESS THAN MAXVALUE);

En el caso que no tuviéramos una partición del tipo pDefault simplemente ejecutamos:

ALTER TABLE reports ADD PARTITION (PARTITION p201206 VALUES LESS THAN (TO_DAYS ("2012-07-01")));

Consultar Particiones

Para consultar información de particiones creadas en una tabla así como también los registros que contiene cada una ejecutamos:

SELECT PARTITION_NAME, TABLE_ROWS FROM information_schema.PARTITIONS WHERE TABLE_NAME='reports';

3.1.5.- Espacios Privados

Un “espacio privado” permite que los administradores y redactores gestionen el conjunto de datos del sitio. Algunas bases de datos tienen estos espacios privados llamados comúnmente paneles de control, que son formularios que aparecen al abrir la base de datos.

Los paneles de control sirven de "puerta principal" o "recibidor" de una base de datos en el sentido de que dirigen a las personas hacia determinadas tareas, como introducir o buscar datos. Sirven también para mantener alejados a los usuarios de las tablas que contienen los datos en tiempo real.

Cuando se recibe una base de datos, se averiguar cómo están estructurados los datos, revisar de manera general el panel de control. Puede ofrecer algún indicio sobre las tareas que el diseñador de la base de datos consideró que realizarían los usuarios habitualmente con los datos.

3.1.6.- Espacios para Objetos
Los DBMS se basan en archivos para almacenar datos, y estos archivos, o conjuntos de datos, residen en medios de almacenamiento, o dispositivos. Una buena parte del trabajo del DBA implicará la planificación para el almacenamiento real de la base de datos.

El rendimiento de la base de datos depende de la entrada y salida a disco. La cantidad de datos almacenados es mayor que nunca antes, y los datos son almacenados por más tiempo.

Algunos DBMS permiten al tamaño de los archivos temporales de expandirse y contraerse de forma automática. Dependiendo del tipo y la naturaleza de las operaciones de base de datos en proceso, esta fluctuación puede provocar picos de uso del disco.

Hay muchos problemas de almacenamiento que deben ser resueltos antes de que un DBA pueda crear una base de datos. Uno de los temas más importantes es la cantidad de espacio para permitir la base de datos.

El cálculo espacial debe tener en cuenta no sólo tablas, índices, sino también, y dependiendo del DBMS, el registro de transacciones. Cada una de estas entidades probablemente requerirá un archivo separado o conjunto de datos, para el almacenamiento persistente.

El DBA debe separar en diferentes discos a los archivos para:

· Mejorar el rendimiento

· Separar índices de datos

· Aislar los logros en otro disco

3.2 Segmentos

Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima unidad de espacio físico, y es un múltiplo del bloque del SO (2 Kb usualmente). El tamaño del bloque Oracle se fija por el parámetro DB_BLOCK_SIZE del fichero init.ora. Un tamaño grande de bloque mejora la eficiencia del cache de E/S, pero el tamaño de la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa un problema de memoria.

Una serie de bloques contiguos es una extensión, que es una unidad lógica de almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensión en su segmento. Cuando el objeto crezca, necesitará más espacio y se reservarán más extensiones.

Cada segmento tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:

initial: tamaño de la extensión inicial (10k).

next: tamaño de la siguiente extensión a asignar (10k).

minextents: número de extensiones asignadas en el momento de la creación del segmento (1).

maxextents: número máximo de extensiones (99).

pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada (50).

pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque asignado al segmento (10).

pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.

tablespace: nombre del espacio de tablas donde se creará el segmento.

Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el crecimiento de las tablas. A continuación se hacen algunas consideraciones sobre la gestión del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener más o menos constante, aunque es crítico que tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. Así, hay que tener cuidado de colocar las tablas de usuario, los índices, segmentos temporales y los segmentos de rollback en otros espacios de tablas.

Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el número de filas, ya que se puede suponer que la longitud de las filas es constante.

Segmentos de Índice

Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los datos en la tabla son modificados frecuentemente. La gestión del espacio es mejor si se mantienen los índices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificación de un bloque. La información en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el bloque de datos) y la recuperación.

Es importante comprender cuál es el contenido de un segmento de rollback. No almacenan el bloque de datos modificado entero, sólo la imagen previa de la fila o filas modificadas. La información del segmento de roolback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitará sólo el rowid de la fila insertada, ya que para volver atrás la insercion sólo hay que realizar un delete. En las operación de actualización, se almacenará el valor antiguo de las columnas modificadas. El segmento de rollback asegura que la información undo se guardan durante la vida de la transacción.

Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este último las extensiones se utilizan de manera circular. Así, habrá que tener cuidado a la hora de fijar el tamaño del segmento de rollback para que la cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

Create Index

Select con distinct, order by, union, intersect y minus.

uniones no indexadas.

Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal, pero si la tabla es grande se realiza en disco. El parámetro SORT_AREA_SIZE determina el lugar donde se hace la ordenación. Incrementándole se reduce la creación de segmentos temporales.

3.3 Definición de Memoria Compartida

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

Un servidor Oracle está constituido de una instancia y una base de datos.

Instancia de Oracle

Una instancia de Oracle permite acceder a la base de datos Oracle y permite abrir únicamente una sola base de datos.

La instancia de Oracle está compuesta de:

Procesos en segundo plano que administran y aplican las relaciones entre las estructuras físicas y las estructuras de memoria. Existen dos categorías:

· Procesos en Segundo Plano Obligatorios: DBWN, PMON, CKPT, LGWR, SMON

· Procesos en Segundo Plano Facultativos: ARCn, LMDn, RECO, CJQ0, LMON, Snnn, Dnnn, Pnnn, LCKn, QMNn

Estructuras de Memoria: compuestas básicamente de dos áreas de memoria: el área de memoria asignada a la SGA (System Global Area): asignada al inicio de la instancia y representa un componente fundamental de una instancia de Oracle.

Está compuesta de varias áreas de memoria:

Área de memoria compartida

Buffer caché de la base de datos

Log buffer

Así como otras estructuras para la gestión de bloqueos externos (lock), internos (match), datos estadísticos, etc.

Eventualmente también es posible configurar al nivel de la SGA

Área de memoria LARGE POOL

Área de memoria Java

Área de Memoria Asignada a la PGA (Program Global Area): Ésta es asignada al inicio del proceso de servidor. Es reservada a cada proceso de usuario que se conecte a la base de datos Oracle y liberada al final del proceso.

El Proceso de Usuario: Es el programa que solicita una interacción con la base de datos iniciando una conexión. Se comunica únicamente con el proceso de servidor correspondiente.

El Proceso de Servidor

Representa el programa que entra directamente en interacción con el servidor Oracle. Responde a todas las peticiones y envía los resultados. Puede estar dedicado a un servidor cliente o compartido por varios.

3.4 Definición de Múltiples Instancias de un DBMS


Cuando comenzamos a trabajar con Oracle una de las primeras cosas que aprendemos es a diferenciar entre estos conceptos: base de datos, instancia e instancia de base de datos.

Una instancia es el conjunto de procesos que se ejecutan en el servidor así como la memoria que comparten para ello.

Cuando se habla de base de datos, nos referimos a los archivos físicos que componen nuestra base de datos.

Si queremos referirnos a los procesos que se ejecutan en memoria como a los archivos de base de datos tendremos que utilizar el término instancia de base de datos.

La instancia en Oracle describe varios procesos residentes en la memoria del computador(es) y un área de memoria compartida por aquellos procesos. En arquitecturas de bases de datos tales como, Microsoft SQL Server e IBM BD2, la palabra instancia indica una colección de bases de datos que comparten recursos de memoria en común, o sea, la relación entre instancia y bases de datos es 1 a N. Pero la relación entre la instancia de Oracle y la base de datos es 1 a 1 o n a 1. Cuando hay una relación N a 1, la configuración es llamada RAC (Real Application CLuster), donde la base de datos reside en discos compartidos y las instancias en múltiples computadores anexados a la base de datos.

martes, 7 de marzo de 2017

Curso: Administrador de bases de datos

                           

                           

                           

                           

                           

                           

                                                 Nivel 1

                           

                           



Nivel 2



                          
Nivel 3















UNIDAD 2: Arquitectura e Instalación del SGBD

2.1 ESTRUCTURA DE MEMORIA Y PROCESOS DE LA INSTANCIA

Oracle utiliza la memoria para almacenar la siguiente información:

- Código del programa
- Información acerca de una sesión conectada, incluso si no se encuentra activa.
- Información necesaria durante la ejecución del programa(por ejemplo, el estado de las consultas)
- La información que comparten y con la cual se comunican los procesos Oracle (por ejemplo, la información de bloqueo)
- La Caché de Datos

La memoria se puede estructurar en las siguientes partes:

- Área Global del sistema (SGA), la cual se comparte entre todos los servidores y los procesos en segundo plano.
- Áreas globales de programas (PGA), que es privada para cada servidor y proceso en segundo planos; a cada proceso se asigna un PGA.
- Área de Ordenaciones (Sort Areas).
- Memoria Virtual
- Área de código de Software (SCA).



INSTANCIA DE UNA BASE DE DATOS

Cada instancia Oracle está asociada a una base de datos. Cuando se inicia una base de datos en un servidor (independientemente del tipo de ordenador), se le asigna un área de memoria (SGA) y lanza uno o más procesos. A la combinación del SGA y de los procesos es lo que se llama instancia. La memoria y los procesos de una instancia gestionan los datos de la base de datos asociada de forma eficiente y sirven a uno o varios usuarios.




La instancia y la base de datos

Cuando se inicia una instancia Oracle monta la base de datos, es decir, asocia dicha instancia a su base de datos correspondiente. En un mismo ordenador pueden ejecutarse varias instancias simultáneamente, accediendo cada una a su propia base de datos física.

Únicamente el administrador de la base de datos puede iniciar una instancia y abrir una base de datos. Si una base de datos está abierta, entonces el administrador puede cerrarla y, cuando esto ocurre, los usuarios no pueden acceder a la información que contiene.


2.2 ESTRUCTURA FÍSICA DE LA BASE DE DATOS


En una base de datos almacenamos información relevante para nuestro negocio u organización y desde el punto de vista físico, la base de datos está conformada por dos tipos de archivos:

Archivos de datos: 
Contiene los datos de la base de datos internamente, está compuesto por páginas enumeradas secuencial mente que representa la unidad mínima de almacenamiento. Cada página tiene un tamaño de 8kb de información. Existen diferentes tipos de páginas, a tener en cuenta:

Páginas de datos: es el tipo principal de páginas y son las que almacenan los registros de datos.
Páginas de espacio libre (PFS Page Free Space): almacenan información sobre la ubicación y el tamaño del espacio libre.
Paginas GAM and SGAM: utilizadas para ubicar extensiones.
Páginas de Mapa de Ubicaciones de índices (IAM – Index Allocation Map): contiene información sobre el almacenamiento de páginas de una tabla o índice en particular.
Páginas Índices: Utilizada para almacenar registros de índices.

Archivo de Registro de Transacciones:
El propósito principal del registro de transacciones es la recuperación de datos a un momento en el tiempo o complementar una restauración de copia de respaldo completa (full backup). El registro de transacciones no contiene páginas, sino entradas con todos los cambios realizados en la base de datos, como son las modificaciones de datos, modificaciones de la base de datos y eventos de copia de seguridad y restauración. El acceso a datos es secuencial, ya que el registro de transacciones se actualiza en el mismo orden cronológico en el que se hacen las modificaciones.

Este archivo no puede ser leído por herramientas de usuario de SQL auqnue existen herramientas de terceros que leen este archivo para recuperar los cambios efectuados. Dependiendo de la versión el registro de transacciones se utiliza para otros propósitos como por ejemplo bases de datos espejo (mirror) y transporte remoto de transacciones (log shipping).

Para muchos de los administradores de bases de datos, la imagen anterior representa la parte lógica y la parte física, donde:

Data File: 
Los datafiles son los archivos físicos en los que se almacenan los objetos que forman parte de un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de datos. Un tablespace puede estar formado por uno o varios datafiles. Cuando se crea un datafile, se debe indicar su nombre, su ubicación o directorio, el tamaño que va a tener y el tablespace al que va a pertenecer. Además, al crearlos, ocupan ya ese espacio aunque se encuentran totalmente vacíos, es decir, Oracle reserva el espacio para poder ir llenándolo poco a poco con posterioridad. Por supuesto, si no hay sitio suficiente para crear un archivo físico del tamaño indicado, se producirá un error y no se creará dicho archivo.

Cuando se van creando objetos en un tablespace, éstos físicamente se van almacenando en los datafiles asignados a dicho tablespace, es decir, cuando creamos una tabla y vamos insertando datos en ella, estos datos realmente se reparten por los archivos físicos o datafiles que forman parte del tablespace. No se puede controlar en qué archivo físico se almacenan los datos de un tablespace. Si un tablespace está formado por 2 datafiles y tenemos una tabla en ese tablespace, a medida que vamos insertando filas éstas se almacenarán en cualquiera de los dos datafiles indistintamente, es decir, unas pueden estar en un datafile y otras en otro.

El espacio total disponible en un tablespace es lógicamente la suma de los tamaños que ocupan los archivos físicos o datafiles que lo forman. Como hemos indicado estos datafiles, al crearlos, están totalmente vacíos, simplemente es un espacio reservado y formateado por Oracle para su uso. A medida que se van creando objetos en ellos como tablas, índices, etc. y se van insertando registros en estas tablas, los datafiles se van llenando o, lo que es lo mismo, el tablespace se va llenando.

Tienen las siguientes características:

Un archivo sólo puede estar asociado con una base de datos.
Los archivos de datos tienen atributos que permiten reservar automáticamente para ellos extensiones cuando se acaba el espacio.
Uno o más archivos de datos forman una unidad lógica de almacenamiento llamada tablespaceOs 

Block:
 Conocidos como Disk Block, estos mapean a los data blocks. A la hora de crear una nueva base de datos se debe indicar cuántos bloques de sistema operativo formarán un bloque de datos.


2.3 REQUERIMIENTOS PARA LA INSTALACIÓN

Antes de instalar cualquier SGBD es necesario conocer los requerimientos de hardware y software, el posible software a desinstalar previamente, verificar el registro de Windows y el entorno del sistema, así como otras características de configuración especializadas como pueden ser la reconfiguración de los servicios TCP/IP y la modificación de los tipos archivos HTML para los diversos navegadores.

Es necesario conocer los requerimientos de hardware y software,el posible software a desinstalar previamente, verificar el registro de Windows y el entorno delsistema, así como otras características de configuración especializadas como pueden ser lareconfiguración de los servicios TCP/IP y la modificación de los tipos archivos HTML para losdiversos navegadores.Se presenta a continuación una serie de requerimientos mínimos de hardware y software parainstalar oracle 11g Express y MySQL estándar versión 5.1. en Windows Seven y Ubuntu 10.La regla general para determinar el tamaño de la memoria virtual depende del tamaño dememoria RAM instalada. Si su sistema tiene menos de 4 GB de RAM por lo general el espacio deintercambio debe ser de al menos dos veces este tamaño. Si usted tiene más de 8 GB de memoriaRAM instalada puede considerar usar el mismo tamaño como espacio de intercambio. Cuanta másmemoria RAM tenga instalada, es menos probable usar el espacio de intercambio, a menos quetenga un proceso inadecuado.

La regla general para determinar el tamaño de la memoria virtual depende del tamaño de memoria RAM instalada. Si su sistema tiene menos de 4 GB de RAM por lo general el espacio de intercambio debe ser de al menos dos veces este tamaño. Si usted tiene más de 8 GB de memoria RAM instalada puede considerar usar el mismo tamaño como espacio de intercambio. Cuanta más memoria RAM tenga instalada, es menos probable usar el espacio de intercambio, a menos que tenga un proceso inadecuado..