miércoles, 7 de junio de 2017
martes, 6 de junio de 2017
UNIDAD 2 Arquitectura e instalación del SGBD
2.1 Características del DBMS
Los sistemas de administración de bases de datos son usados para:
· Permitir a los usuarios acceder y manipular la base de datos proveyendo métodos para construir sistemas de procesamiento de datos para aplicaciones que requieran acceso a los datos.
· Proveer a los administradores las herramientas que les permitan ejecutar tareas de mantenimiento y administración de los datos.
Algunas de sus características son:
Control de la Redundancia de Datos
Este consiste en lograr una mínima cantidad de espacio de almacenamiento para almacenar los datos evitando la duplicación de la información. De esta manera se logran ahorros en el tiempo de procesamiento de la información, se tendrán menos inconsistencias, menores costos operativos y hará el mantenimiento más fácil.
Compartimiento de Datos
Una de las principales características de las bases de datos, es que los datos pueden ser compartidos entre muchos usuarios simultáneamente, proveyendo, de esta manera, máxima eficiencia.
Mantenimiento de la Integridad
La integridad de los datos es la que garantiza la precisión o exactitud de la información contenida en una base de datos. Los datos interrelacionados deben siempre representar información correcta a los usuarios.
Soporte para Control de Transacciones y Recuperación de Fallas
Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardware.
Independencia de los Datos
En las aplicaciones basadas en archivos, el programa de aplicación debe conocer tanto la organización de los datos como las técnicas que el permiten acceder a los datos. En los sistemas DBMS los programas de aplicación no necesitan conocer la organización de los datos en el disco duro. Este totalmente independiente de ello.
Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según los privilegios que posea cada usuario de la base de datos, podrá acceder a mayor información que otros.
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
Independencia del Hardware
La mayoría de los sistemas DBMS están disponibles para ser instalados en múltiples plataformas de hardware.
2.2 Estructura física de la base de datos
2.1.2 Estructuras físicas de la base de datos
Estructura física de la base de datos Oracle:
La Arquitectura de Oracle tiene tres componentes básicos:1.
La Estructura de memoria2.
Los Procesos3.
Los Archivos.1.
ESTRUCTURA DE LA MEMORIA:
Es la estructura de memoria compartida que contienen datos e información de control para unainstancia de una base de datos, cada instancia tiene sus propias estructuras de memoria y selocaliza en la memoria virtual
del computador.
Las estructuras de memoria se denominan SystemGlobal Area (SGA) la cual es un área compartida por todos los usuarios y se divide en tres partes:
1.1.
Fondo común compartido (Shared pool):
Se utiliza durante el procesamiento de comandos.Tiene dos zonas:
–
Library Cache: almacena información relacionada a la instrucción de SQL:
–
–
Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la información de usomás frecuente sobre el diccionario de datos. Esta información incluye definición decolumnas, usuarios, passwords y privilegios. Esta información es usada durante tiempo decompilación.
1.2.
Arear de Memoria rápida (Dtabase buffer cache):
mantiene los bloques de datos leídosdirectamente de los archivos de datos. Cuando se procesa una consulta, el servidor busca losbloques de datos requeridos en esta estructura. Si no se encuentra, el proceso servidor lee elbloque de la memoria secundaria y coloca una copia. Está organizada en dos listas:
–
Lista de sucios
: bloques que han sufrido modificaciones y no han sido escritos en disco.
–
Lista de menos recientemente usados:
mantiene los bloques libres, los bloques a los que seestá accediendo actualmente y los bloques sucios que aún no han sido remitidos a la listade sucios.
1.3.
Área de registro de rehacer (Redo log buffer):
es un buffer circular que mantiene todos loscambios que han sido
realizados sobre la base de datos por operaciones de insert, update,delete, create,
alter y drop. Las entradas de este buffer contienen toda la informaciónnecesaria
para reconstruir los cambios realizados a la base de datos por medio de cualquier
instrucción (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor).
El uso esestrictamente secuencial.
UNIDAD 2 Arquitectura e instalación del SGBD
2.1 Características del DBMS
Los sistemas de administración de bases de datos son usados para:
Permitir a los usuarios acceder y manipular la base de datos proveyendo métodos para construir sistemas de procesamiento de datos para aplicaciones que requieran acceso a los datos.
Proveer a los administradores las herramientas que les permitan ejecutar tareas de mantenimiento y administración de los datos.
Algunas de sus características son:
Control de la Redundancia de Datos
Este consiste en lograr una mínima cantidad de espacio de almacenamiento para almacenar los datos evitando la duplicación de la información. De esta manera se logran ahorros en el tiempo de procesamiento de la información, se tendrán menos inconsistencias, menores costos operativos y hará el mantenimiento más fácil.
Compartimiento de Datos
Una de las principales características de las bases de datos, es que los datos pueden ser compartidos entre muchos usuarios simultáneamente, proveyendo, de esta manera, máxima eficiencia.
Mantenimiento de la Integridad
La integridad de los datos es la que garantiza la precisión o exactitud de la información contenida en una base de datos. Los datos interrelacionados deben siempre representar información correcta a los usuarios.
Soporte para Control de Transacciones y Recuperación de Fallas
Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardware.
Independencia de los Datos
En las aplicaciones basadas en archivos, el programa de aplicación debe conocer tanto la organización de los datos como las técnicas que el permiten acceder a los datos. En los sistemas DBMS los programas de aplicación no necesitan conocer la organización de los datos en el disco duro. Este totalmente independiente de ello.
Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según los privilegios que posea cada usuario de la base de datos, podrá acceder a mayor información que otros.
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
Independencia del Hardware
La mayoría de los sistemas DBMS están disponibles para ser instalados en múltiples plataformas de hardware.
|
2.2 Estructura física de la base de datos
2.1.2 Estructuras físicas de la base de datos
Estructura física de la base de datos Oracle:
La Arquitectura de Oracle tiene tres componentes básicos:1.
La Estructura de memoria2.
Los Procesos3.
Los Archivos.1.
ESTRUCTURA DE LA MEMORIA:
Es la estructura de memoria compartida que contienen datos e información de control para unainstancia de una base de datos, cada instancia tiene sus propias estructuras de memoria y selocaliza en la memoria virtual
del computador.
Las estructuras de memoria se denominan SystemGlobal Area (SGA) la cual es un área compartida por todos los usuarios y se divide en tres partes:
1.1.
Fondo común compartido (Shared pool):
Se utiliza durante el procesamiento de comandos.Tiene dos zonas:
–
Library Cache: almacena información relacionada a la instrucción de SQL:
–
–
Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la información de usomás frecuente sobre el diccionario de datos. Esta información incluye definición decolumnas, usuarios, passwords y privilegios. Esta información es usada durante tiempo decompilación.
Descripción: https://html1-f.scribdassets.com/5aa1eb3ds03v0l09/images/1-1e6a2b77ef.jpg
1.2.
Arear de Memoria rápida (Dtabase buffer cache):
mantiene los bloques de datos leídosdirectamente de los archivos de datos. Cuando se procesa una consulta, el servidor busca losbloques de datos requeridos en esta estructura. Si no se encuentra, el proceso servidor lee elbloque de la memoria secundaria y coloca una copia. Está organizada en dos listas:
–
Lista de sucios
: bloques que han sufrido modificaciones y no han sido escritos en disco.
–
Lista de menos recientemente usados:
mantiene los bloques libres, los bloques a los que seestá accediendo actualmente y los bloques sucios que aún no han sido remitidos a la listade sucios.
1.3.
Área de registro de rehacer (Redo log buffer):
es un buffer circular que mantiene todos loscambios que han sido
realizados sobre la base de datos por operaciones de insert, update,delete, create,
alter y drop. Las entradas de este buffer contienen toda la informaciónnecesaria
para reconstruir los cambios realizados a la base de datos por medio de cualquier
instrucción (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor).
El uso esestrictamente secuencial.
2.
ARCHIVOS:
Los archivos que maneja Oracle, se clasifican en cuatro grupos:
2.3 Requerimientos para instalación
Los requerimientos de hardware x86_64 Hardware para instalaciones de base de datos incorporadas.
La tabla a continuación muestra las consideraciones de hardware que se requieren y recomiendan en la plataforma x86_64 para un servidor de Satélite mediante una base incorporada:
Tabla 2.3. Requerimientos de hardware en Satélite de base de datos incorporada
| Obligatorio | Recomendado |
|---|---|
| Procesador Intel Core, 2.4GHz, 512K cache o equivalente | Procesador Intel multi-core, procesador dual de 2.4GHz, 512K cache o equivalente |
| 2 GB de memoria | 8 GB de memoria |
| 5 GB de almacenaje para instalación base de Red Hat Enterprise Linux | Por lo menos 30 GB de almacenaje por canal de software (incluidos Base y canales hijos), en /var/satellite/, configurable en la instalación. |
| Un SAN externo para copias de seguridad más confiables | |
12 GB de almacenaje para repositorio de base de datos, en la partición /rhnsat (almacenaje local únicamente) | |
| Un controlador SCSI conectado a un nivel de RAID 5 (se recomienda) | |
| Una partición individual (o mejor, un conjunto de discos físicos) para guardar copias de seguridad, la cual puede ser un directorio definido en el momento de copiado. |
2.4 Instalación del SGBD en modo transaccional
2.5 Variables de Ambiente y archivos importantes para instalación.
2.6 Procedimiento general de instalación
Oracle Database XE es una gran base de datos para:
Ø Desarrolladores que trabajan en PHP, Java, .NET, XML, y Open Sourceapplications
Ø DBAs que necesitan desarollar libremente
Ø Vendedores de Software y hardware que necesitan distribuir sin cargos
Ø Instituciones educativas y estudiantes que cursan materias relacionados con base de datos
Oracle es líder en bases de datos. Con Oracle XE, es posible desarrollar y desplegar aplicaciones potentes, actualizar sin costo y generar complejas migraciones.
Oracle Express Edition se instala en una máquina con cualquier número de procesadores, solo puede contener una base de datos y direccionar un máximo de 4GB de datos y un máximo de 1GB RAM.
Oracle Database XE, usa una interface basada en browser (Navegador) para:
Ø Administrar la base de datos
Ø Crear tablas, vistas, y otros objetos de base de datos
Ø Importar, exportar, y ver tablas de datos
Ø Ejecutar consultas y scripts SQL
Ø Generar reportes
Oracle Database XE incluye Oracle Application Express release 2.1, un ambiente de desarrollo gráfico para crear aplicaciones Web con base de datos. Oracle Database XE es una versión reducida de Oracle con las misma características y potencialidad de Oracle Database. Es necesario destacar que no soporta todos los tipos de datos de Oracle Database XE.
2.7 Procedimiento para configuración de un SGBD.
Para configurar nuestro DBMS podemos acceder a las siguientes pantallas, para Oracle o MySQL.
El esquema de una base de datos (en inglés, DatabaseSchema) describe la estructura de una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada campo y cada tabla.
Oracle generalmente asocia un 'username' como esquemas en este caso SYSTEM y HR (Recursos humanos).
Por otro lado MySQL presenta dos esquemas information_schema y MySQL ambos guardan información sobre privilegios y procedimientos del gestor y no deben ser elimandos.
UNIDAD 3 Configuración y administración del espacio en disco
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
3.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:
3.3 Asignación de cuotas de espacio para usuarios
Anteriormente vimos como la creación de procesos recursivos podía implicar la congelación del sistema y como solucionarlo estableciendo una cantidad máxima de procesos en ejecución por usuario.
Esto mismo puede pasar si un usuario llena de información nuestro disco duro, y para remediarlo estableceremos ‘Cuotas’ de usuario para que tengan un límite de espacio en disco.Éstas cuotas son restricciones del número de bloques de espacio en disco y de i-nodos (ficheros, directorios…) que un usuario puede llegar a tener. Las cuotas, sólo se establecen para las particiones que queramos, no para la totalidad del sistema asique si quisiéramos activar las cuotas en nuestra partición principal, sólo tendríamos que añadir al /etc/fstab en el cuarto campo de la partición ‘usrquota’,pero antes instalamos el paquete quota:
sudo apt-get install quota
Luego modificamos el /etc/fstab:
/media/hdb1 ext3 defaults,usrquota 0 2
En este caso la partición /media/hdb1 que será el disco duro secundario tendría establecidas las cuotas.
Después tenemos que crear en la partición dos archivos en mi caso será en /media/hdb1:
Después tenemos que crear en la partición dos archivos en mi caso será en /media/hdb1:
ekhtor@ubuntu:/media/hdb1$ sudo touch quota.user
ekhtor@ubuntu:/media/hdb1$ sudo touch quota.group
Y ahora solo tenemos que darle permisos a los archivos:
ekhtor@ubuntu:/media/hdb1$ sudo chmod 600 quota.*
Para que los cambios surtan efecto tenemos que reiniciar el sistema, y una vez hecho editamos las cuotas con el comando ‘edquota -u’, que nos aparecerá algo parecido a ésto:
Disk quotas for user ekhtor (uid 1000):
Filesystem blocks soft hard inodes soft hard
/dev/hdb1 0 0 0 0 0 0
Aquí podemos ver que no hay límites, para establecerlos tenemos que modificar las variables soft y hard, que las dos primeras se referiran a los bloques y las dos últimas a los i-nodos.
Para saber de cuanto tamaño es un bloque usamos la instrucción df /media/hdb1 que nos devulve esto:
Para saber de cuanto tamaño es un bloque usamos la instrucción df /media/hdb1 que nos devulve esto:
S.ficheros Bloques de 1K Usado Dispon Uso% Montado en
/dev/hdb1 12563216 1392004 10533032 12% /media/hdb1
/dev/hdb1 12563216 1392004 10533032 12% /media/hdb1
Podemos observar que los bloques son de 1K asique si quisiéramos asignarle al usuario ekhtor 50000K’s que serían unos 50 Mb tendríamos que cambiar la primera variable hard por 50000, y a la variable soft le asignaremos 40000. La variable hard va a ser el tamaño que nunca sobrepasará el usuario y la soft mandará un aviso cuando se sorbrepase, luego cuando el usuario llegue a los 40 megas se le enviará un aviso de que el espacio se le está agotando y si llega a los 50 megas ya no podrá usar más.
Si queremos además limitar el número de archivos y directorios que tendrá el usuario lo haremos en el segundo bloque de soft y hard de igual forma.
Al igual que para los usuarios se hace con el grupo pero en vez de edquota -u ‘usuario’ se hace con el comando edquota -g ‘grupo’. Puede parecer una tontería limitar el número de ficheros en un sistema si ya hemos limitado el espacio físico pero realmente cuantos más inodos haya en un sistema, más se ralentiza asique en servidores grandes es una opción a tener en cuenta.
3.4. Espacios para objetos de la base de datos
- 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.
- 3. 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.
- 4. 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.
- 5. 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.
- 6. 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
- 7. . 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
UNIDAD 4 Operación y Mantenimiento
En caso de que sea multiusuario existen muchas ventajas adicionales, donde la BD es con todaprobabilidad mucho más grande y compleja. Ofrece control centralizado de su información. * Es compacto: no hacen falta archivos de papales que pudieran ocupar mucho espacio.
* Es rápido: la máquina puede obtener y modificar con mucha mayor velocidad que un ser humano.
* Es menos laborioso: se elimina gran parte del tedio de mantener archivos a mano.
* Es actual: se dispone en cualquier momento de información precisa y al día. Tiene aún más importancia, en un ambiente multiusuario, donde la BD es con toda probabilidad mucho más grande y compleja que un uno de un solo usuario. El sistema de BD ofrece a la empresa un control centralizado de su información.
* Es rápido: la máquina puede obtener y modificar con mucha mayor velocidad que un ser humano.
* Es menos laborioso: se elimina gran parte del tedio de mantener archivos a mano.
* Es actual: se dispone en cualquier momento de información precisa y al día. Tiene aún más importancia, en un ambiente multiusuario, donde la BD es con toda probabilidad mucho más grande y compleja que un uno de un solo usuario. El sistema de BD ofrece a la empresa un control centralizado de su información.
4.1 Archivos log del SGBD
Cuando trabajas frente al ordenador, navegas en tu tablet u operas una página web desde un servidor, tienen lugar numerosos procesos que pasan inadvertidos ante cualquier usuario. En caso de que se presenten problemas, se produzcan errores o quieras conocer exactamente qué acciones ejecutan los sistemas operativos o los diferentes programas o servicios, puedes acceder a los llamados archivos log, en español ficheros de registro. Estos “logs” son gestionados por prácticamente todas las aplicaciones, servidores, bases de datos y sistemas de manera automática y permiten controlar (de forma centralizada) todos los procesos relevantes.
En general, los ficheros log no suelen evaluarse frecuentemente, pues cumplen una función similar a la de un registrador de vuelo que es inspeccionado solo en caso de emergencia. Como consecuencia del registro detallado de datos de los logs, estos son una fuente primordial a la hora de analizar errores de programa o del sistema, así como para determinar el comportamiento de los usuarios. Esto no solo resulta interesante para los fabricantes de software, sino también para propietarios de páginas web, quienes pueden acceder a información interesante desde los archivos de registro del servidor web.
4.2 Definición de los modos de operación de un SGBD. (alta, baja, recovery) y comandos de activación
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
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.
De Protección de Datos
Como administrador de copia de seguridad, su trabajo principal es hacer copias de seguridad y vigilancia para la protección de datos. Una copia de seguridad es una copia de los datos de una base de datos que se puede utilizar para reconstruir los datos. Una copia de seguridad puede ser una copia de seguridad física o una copia de seguridad lógica.
Copias de seguridad físicas son copias de los archivos físicos utilizados en el almacenamiento y la recuperación de una base de datos. Estos archivos incluyen archivos de datos, archivos de control y los registros de rehacer archivados. En última instancia, cada copia de seguridad física es una copia de los archivos que almacenan información de base de datos a otra ubicación, ya sea en un disco o en medios de almacenamiento fuera de línea, tales como cinta.
Copias de seguridad lógicas contienen datos lógicos, como tablas y procedimientos almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lógicos binarios, que posteriormente puede importar a la base de datos. Clientes de línea de comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y DBMS_METADATA PL / SQL paquetes.
Copias de seguridad lógicas contienen datos lógicos, como tablas y procedimientos almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lógicos binarios, que posteriormente puede importar a la base de datos. Clientes de línea de comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y DBMS_METADATA PL / SQL paquetes.
Copias de seguridad físicas son la base de cualquier estrategia de recuperación de copia de seguridad sólida y. Copias de seguridad lógicas son un complemento útil de las copias de seguridad físicas en muchas circunstancias, pero no son suficiente protección contra la pérdida de datos y sin respaldos físicos.
A menos que se especifique lo contrario, la copia de seguridad término tal como se utiliza en la copia de seguridad y la documentación de recuperación se refiere a una copia de seguridad física. Copia de seguridad de una base de datos es el acto de hacer una copia de seguridad física. El enfoque en la copia de seguridad y recuperación de documentación está casi exclusivamente en copias de seguridad físicas.
A menos que se especifique lo contrario, la copia de seguridad término tal como se utiliza en la copia de seguridad y la documentación de recuperación se refiere a una copia de seguridad física. Copia de seguridad de una base de datos es el acto de hacer una copia de seguridad física. El enfoque en la copia de seguridad y recuperación de documentación está casi exclusivamente en copias de seguridad físicas.
4.3 Índices, reorganización y reconstrucción
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. Existen diferentes tipos de índices algunos de ellos son:
Ø Índices agrupados: definen el orden en que almacenan las filas de la tabla (nodos hoja/página de datos de la imagen anterior). La clave del índice agrupado es el elemento clave para esta ordenación; el índice agrupado se implementa como una estructura de árbol b que ayuda a que la recuperación de las filas a partir de los valores de las claves del índice agrupado sea más rápida. Debemos tener en cuenta:Columnas selectivas, columnas afectadas en consultas, Columnas accedidas "secuencialmente", Columnas implicadas en JOIN, GROUP BY y el Acceso muy rápido a filas: lookups
Ø Índices no agrupados: tienen la misma estructura de árbol b que los índices agrupados, con algunos matices; como hemos visto antes, en los índices agrupados, en el último nivel del índice (nivel de hoja) están los datos; en los índices no-agrupados, en el nivel de hoja del índice, hay un puntero a la localización física de la fila correspondiente en el índice agrupado.
Ø Índices compuestos: 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.
Ø índices descendientes: Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
4.4.2 Reorganizacion 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. Un paquete puede usar la tarea Reorganizar índice para reorganizar los índices de una base de datos individual o de varias bases de datos.
La tarea Reorganizar índice encapsula la instrucción ALTER INDEX de Transact-SQL. Si elige compactar datos de objetos grandes, la instrucción utiliza la cláusula REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece LOB_COMPACTION en OFF.
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.
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
Se debe 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.
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 siguientes:
ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING;
Comando ALTER INDEX
Como hemos comentado esta sentencia se utiliza para cambiar o reconstruir un Índice existente en la base de datos. Para reconstruir un Índice bastaría con lazar la siguiente sentencia: ALTER INDEX REBUILD;
Como hemos comentado esta sentencia se utiliza para cambiar o reconstruir un Índice existente en la base de datos. Para reconstruir un Índice bastaría con lazar la siguiente sentencia: ALTER INDEX REBUILD;
UNIDAD 5 Seguridad
Seguridad de los datos: es la protección de la base de datos de uso mal intencionado o no autorizado.
Esta se encarga de limitar o restringir a los usuarios a realizar solo las operaciones permitidas.
Esta se encarga de limitar o restringir a los usuarios a realizar solo las operaciones permitidas.
Respaldo y Recuperación.
Los SGBD deben proporcionan instrumentos para evitar o remediar fallos.
Sistema de recuperación: Consiste en restaurar la BD a un estado que se sepa correcto, tras cualquier fallo que la haya dejado en un estado incorrecto o al menos sospechoso.
El objetivo de este servicio es evaluar la situación particular de cada base de datos, y proponer el mejor esquema de respaldo que garantice la mayor disponibilidad y la menor pérdida de información ante un desastre.
Recuperación.
Un sistema de recuperación consiste en restaurar la BD a un estado que se sepa correcto, tras cualquier fallo que la haya dejado en un estado incorrecto.
Un sistema de recuperación consiste en restaurar la BD a un estado que se sepa correcto, tras cualquier fallo que la haya dejado en un estado incorrecto.
Recuperación de BD: “devolver la BD a un estado consistente” La recuperabilidad significa que, si se da algún error en los dato el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara.
___________________________________________HASTA AQUI LLEGUE HOY
Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA’s.
La recuperabilidad, frecuentemente denominada “recuperación de desastres”, tiene dos formas primarias.La primera son los respaldos y después las pruebas de recuperación. La recuperación de las bases de datos consiste en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos ó bugs que pudieran haber corrompido los respaldos.
Respaldo.
Es la obtención de una copia de los datos en otro medio magnético, de tal modo que a partir de dicha copia es posible restaurar el sistema al momento de haber realizado el respaldo. Por lo tanto, los respaldos deben hacerse con regularidad, con la frecuencia preestablecida y de la manera indicada, a efectos de hacerlos correctamente.
Es la obtención de una copia de los datos en otro medio magnético, de tal modo que a partir de dicha copia es posible restaurar el sistema al momento de haber realizado el respaldo. Por lo tanto, los respaldos deben hacerse con regularidad, con la frecuencia preestablecida y de la manera indicada, a efectos de hacerlos correctamente.
Es fundamental hacer bien los respaldos. De nada sirven respaldos mal hechos (por ejemplo incompletos). En realidad, es peor disponer de respaldos no confiables que carecer totalmente de ellos. Suele ocurrir que la realización de respaldos es relegada a un plano secundario.
Existen varias maneras de respaldar base de datos MySQL, en este post únicamente mostraré una manera de hacerlo utilizando mysqldump() y PHP. Básicamente lo que se realiza es un respaldo de todas las bases de datos, por lo que el script debe ejecutarse como un usuario que tenga permisos sobre todas las bases. Adicionalmente se mantiene en disco las últimas 3 copias de los respaldos.
5.1 Espejeo (mirroring).
Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de base 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 elservidor árbitro, es usado cuando es necesario determinar cuál de los 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). Para hacer el mirror, es necesario como mínimo 2 instancia y como máximo 3. Si utilizamos 2 instancias, una de ellas contiene la base de datos y la otra la espejo. La pega de esta configuración es que el failover no es automático y se necesita intervención humana. Si utilizamos 3 instancias, entonces utilizamos una de ellas como witness server y permite que el failover sea automático, osea que cuando una caiga, la otra se ponga en marcha. Para ello el witness server se encarga de “mirar” el estado de las 2 instancias y cuando una de ellas cae, pone la otra en marcha. Hacer el mirror son dos pasos principales: 1. Copiar y restaurar la base de datos de la que queremos hacer el mirror desde una instancia a la otra 2. Configurar el asistente de configuración del mirror. Vamos un ejemplo paso a paso.
5.2 Réplica (replication).
La replicación de base de datos es una herramienta muy potente en el mundo de las aplicaciones distribuidas. Sus aplicaciones en el mundo real son muy variadas. Sin embargo, para que se pueda utilizar de forma correcta y funcione como esperamos es importante conocer realmente cómo funciona y las diferentes opciones que nos ofrece. Los beneficios o los entornos donde es aplicable la replicación de bases de datos son los siguientes: Usuarios trabajando en ubicaciones geográficamente alejados trabajando con sus propias copias locales de la base de datos. Entornos en los que se replica la base de datos principal en una secundaria como copia de seguridad. En el caso que la primaria caiga, la secundaria toma el control. En entornos en los que la carga de usuarios sea muy grande para un sólo gestor, se pueden replicar las bases de datos en varios servidores asignando a cada usuario un servidor. Balanceando de esta manera la carga podremos aliviar a los gestores. Como observamos, los entornos son variados y comunes en muchos casos. El problema reside en la configuración y la elección correcta del tipo de replicación Modelo de Replicación Antes de empezar, vamos a clarificar los conceptos y términos que se utilizan cuando hablamos de la replicación. Los elementos que componen la replicación son los siguientes: Publicador: es la instancia que pone sus datos a disposición de otras localizaciones mediante la replicación. El Publicador puede tener varias publicaciones configuradas cada una relacionada con un conjuntos lógico de objetos y datos. Distribuidor: es la base de datos destinada a almacenar la información específica asociada a la replicación de uno o más publicadores. Cada publicador es asociado con una base de datos (conocida como la base de datos de distribución) en el Distribuidor. La base de datos de distribución guarda el estado de la replicación, metadatos y en algunos casos hace de cola de distribución entre el publicador y el suscriptor. En la mayoría de los casos, la misma base de datos actúa como Publicador y Distribuidor. Cuando el Publicador y el Distribuidor se encuentran en servidores separados, el Distribuidor es conocido como "Distribuidor Remoto". Artículo: un artículo identifica un objeto de base de datos que es incluido en la publicación. Una publicación puede tener varios tipos de artículos: procedimientos almacenados, vistas, tablas y otro tipo de objetos. Cuando las tablas son publicadas, se pueden establecer filtros para restringir los datos y/o columnas que se envían al suscriptor. Publicación: es una colección de no o más artículos de una base de datos. La agrupación de artículos en una publicación hace más fácil especificar el conjunto de datos asociados en la replicación como una sola unidad Suscripción: es una petición para que una copia de la publicación sea enviada al suscriptor. La suscripción define qu´r publicación será recibida, cuando y donde. Hay dos tipos de suscripción: de inserción y de extracción Agentes: son los encargados de gestionar la comunicación y el envío de los datos entre los suscriptores y los publicadores
5.3 Métodos de respaldo de un SGBD
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 este 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 mas un conjunto de datos que no denotan infomació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 mas de espacio que myISAM.
5.4 Métodos de recuperación de un SGBD
La recuperación consiste en tres pasos principales: Análisis: Identifica las páginas sucias y el conjunto de transacciones activas en el momento de la caída y el punto del log apropiado para empezar la operación REHACER Rehacer: se replican las operaciones del log. Deshacer: Se recorre el log hacia atrás y se deshacen las transacciones activas en el momento de la caída, o iniciadas después, de las que no se ha encontrado confirmación. Recuperación en Oracle Red Log Files: dos o más archivos donde se registra cualquier modificación transaccional de una memoria intermedia de la BD. Archivos de control: metadatos necesarios para operar en la base de datos, incluyendo información sobre copias de seguridad. Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción. En la Recuperación de un fallo: Recupera los datos con REHACER (Desde Redo Log File). Deshace las transacciones no comprometidas con Deshacer (Desde el segmento de rollback). 5.1.4 Comandos para recuperación Cada vez que se ejecuta una tarea de copia de seguridad, CA ARCserve Backup registra la información en la base de datos sobre los equipos, directorios y archivos de los que se ha realizado copia de seguridad y los medios utilizados. Esto permite localizar archivos para cuando sea necesario restaurarlos. El comando de recuperación de base de datos (ca_recoverdb) es una opción de protección propia que permite recuperar una base de datos de CA ARCserve Backup si se ha perdido y se ha realizado copia de seguridad mediante el dominio de CA ARCserve Backup que está utilizando la base de datos. La utilidad ca_recoverdb sólo se utiliza para recuperar una base de datos de ARCserve (ASDB) en el mismo equipo o dominio de ARCserve en el que se ha realizado la copia de seguridad de ASDB. Si desea realizar la copia de seguridad de ASDB en un equipo y recuperarla en otro (los dos equipos no se encuentran en el mismo dominio de ARCserve), no se puede utilizar este comando. Ante esta situación dispone de dos soluciones: Solución 1: Realizar una copia de seguridad de recuperación de desastres desde el equipo A y después recuperarla en el equipo B. Esta solución necesita que esté instalada la opción de recuperación de desastres (DR, Disaster Recovery) .
5.5 Migración de la Base de Datos
La migración de bases de datos es generalmente una tarea compleja que no sólo supone transferir datos entre tipos de almacenaje y formatos de un servidor de base de datos a otro; sino que también supone reescribir sentencias SQL o incluso procedimientos (SPL) de lógica de negocio. En comparación con los esquemas estándares de migración a mano, ofrecemos una potente gama de herramientas desarrolladas de probada eficacia en complejos módulos de bases de datos relacionales. Estas herramientas y nuestros especialistas pueden asegurar que las transiciones de las bases de datos se realicen perfectamente, independientemente de la naturaleza del sistema. Desde la experiencia, estamos familiarizados con la complejidad, el coste que supone una larga migración de bases de datos y los problemas que aparecen durante el proceso cuando se emplean métodos inapropiados; ya que siempre comprobamos con los clientes potenciales que el uso de nuestras herramientas y métodos pueda ofrecer una ventaja significativa. HERRAMIENTAS DE MIGRACIÓN En comparación con la consultoría estándar de migraciones, la cual puede ofrecer poco más que soporte a la base de datos, nosotros tenemos gran experiencia en escribir grandes aplicaciones para empresas en sintaxis de la base de datos nativa y cross. Además, enseñamos a los equipos de las empresas una metodología y les proporcionamos una potente gama de herramientas para reducir costes y optimizar el proceso de migración.
Suscribirse a:
Entradas (Atom)