UNIDAD 2 ARQUITECTURA DEL GESTOR

2.1. Caractersticas del DBMS

Control de la redundancia de datos

Este consiste en lograr una mnima cantidad de espacio de almacenamiento para

almacenar los datos evitando la duplicacin de la informacin. De esta manera se
logran ahorros en el tiempo de procesamiento de la informacin, se tendrn menos
inconsistencias, menores costos operativos y har el mantenimiento ms fcil.

Compartimiento de datos

Una de las principales caractersticas de las bases de datos, es que los datos
pueden ser compartidos entre muchos usuarios simultneamente, proveyendo, de
esta manera, mxima eficiencia.

Mantenimiento de la integridad

La integridad de los datos es la que garantiza la precisin o exactitud de la

informacin contenida en una base de datos. Los datos interrelacionados deben
siempre representar informacin correcta a los usuarios.

Soporte para control de transacciones y recuperacin de fallas.

Se conoce como transaccin toda operacin 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 recuperacin de fallas tiene que ver con la
capacidad de un sistema DBMS de recuperar la informacin 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 aplicacin debe conocer

tanto la organizacin de los datos como las tcnicas que el permiten acceder a los
datos. En los sistemas DBMS los programas de aplicacin no necesitan conocer la
organizacin de los datos en el disco duro. Este totalmente independiente de ello.

Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Segn los
privilegios que posea cada usuario de la base de datos, podr acceder a mayor
informacin que otros.

Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.

Independencia del hardware

La mayora de los sistemas DBMS estn disponibles para ser instalados en
mltiples plataformas de hardware.

2.1.1 Estructura de memoria y procesos de la instancia

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 cdigo de software.

Cada instancia est asociada a una base de datos. Cuando se inicia una base de
datos en un servidor (independientemente del tipo de computadora), se le asigna
un rea de memoria (SGA) y lanza uno o ms procesos. A la combinacin 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.

Cuando se inicia una instancia El DBMS monta la base de datos, es decir, asocia
dicha instancia a su base de datos correspondiente. En una misma computadora
pueden ejecutarse varias instancias simultneamente, accediendo cada una a su
propia base de datos fsica.

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 informacin que contiene.
2.1.2 Estructuras fsicas de la base de datos
En una base de datos almacenamos informacin relevante para nuestro negocio u
organizacin y desde el punto de vista fsico, 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 pginas enumeradas secuencialmente que representa la unidad
mnima de almacenamiento. Cada pgina tiene un tamao de 8kb de
informacin. Existen diferentes tipos de pginas, a tener en cuenta:

Pginas de datos: es el tipo principal de pginas y son las que almacenan los
registros de datos.

Pginas de espacio libre (PFS Page Free Space): almacenan informacin sobre la
ubicacin y el tamao del espacio libre.

Paginas GAM and SGAM: utilizadas para ubicar extensiones.

Pginas de Mapa de Ubicaciones de ndices (IAM Index Allocation Map):

contiene informacin sobre el almacenamiento de pginas de una tabla o ndice en
particular.

Pginas ndices: Utilizada para almacenar registros de ndices.

Archivo de Registro de Transacciones: El propsito principal del registro de

transacciones es la recuperacin de datos a un momento en el tiempo o
complementar una restauracin de copia de respaldo completa (full backup). El
registro de transacciones no contiene pginas, 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
restauracin. El acceso a datos es secuencial, ya que el registro de
transacciones se actualiza en el mismo orden cronolgico en el que se hacen
las modificaciones.
Este archivo no puede ser ledo por herramientas de usuario de SQL auqnue
existen herramientas de terceros que leen este archivo para recuperar los cambios
efectuados. Dependiendo de la versin el registro de transacciones se utiliza para
otros propsitos 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 lgica y la parte fsica, donde:

Data File:

Los datafiles son los archivos fsicos 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
ubicacin o directorio, el tamao que va a tener y el tablespace al que va a
pertenecer. Adems, al crearlos, ocupan ya ese espacio aunque se encuentran
totalmente vacos, es decir, Oracle reserva el espacio para poder ir llenndolo
poco a poco con posterioridad. Por supuesto, si no hay sitio suficiente para crear
un archivo fsico del tamao indicado, se producir un error y no se crear dicho
archivo.

2.1.3 Requerimientos para instalacin de la base de datos.

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 caractersticas de
configuracin especializadas como pueden ser la reconfiguracin de los servicios
TCP/IP y la modificacin de los tipos archivos HTML para los diversos
navegadores.

Se presenta a continuacin una serie de requerimientos mnimos de hardware y

software para instalar oracle 11g Express y MySQL estndar versin 5.1. en
Windows Seven y Ubuntu 10.

2.1.4 Instalacin del software de BD en modo transaccional

Debido al constante crecimiento de datos que generan las empresas hoy
en da, se ha vuelto muy necesaria la bsqueda de nuevas plataformas
para almacenar y analizar la informacin, ambientes que consuman
menos recursos, que sean ms escalables y que provean una alta
disponibilidad. La solucin consiste en el procesamiento paralelo de los
datos de una base de datos.

Una base de datos en modo transaccional significa que la BD ser capaz

de que las operaciones de insercin y actualizacin se hagan dentro de
una transaccin, es un componente que procesa informacin
descomponindola de forma unitaria en operaciones indivisibles,
llamadas transacciones, esto quiere decir que todas las operaciones se
realizan o no, si sucede algn error en la operacin se omite todo el
proceso de modificacin de la base de datos, si no sucede ningn error
se hacen toda la operacin con xito.

Una transaccin es un conjunto de lneas de un programa que

llevan insert o update o delete. Todo aqul software que tiene un log de
transacciones (que es la "bitcora" que permite hacer operaciones
de commit o rollback), propiamente es un software de BD; aqul que no
lo tiene (v.g. D-Base), propiamente no lo es. Todo software de base de
datos es transaccional; si el software de la BD no es "transaccional", en
realidad NO es un "software" de BD; en todo caso, es un software que
emula el funcionamiento de un verdadero software de BD. Cada
transaccin debe finalizar de forma correcta o incorrecta como una
unidad completa. No puede acabar en un estado intermedio.

Se usan los siguientes mtodos:

Begin TRans para iniciar la transaccin

CommitTrans para efectuar los cambios con xito
RollbackTrans para deshacer los cambios
Y depende que base de datos uses para efectuar las operaciones pero,
es la misma teora para cualquier BD.

Una vez que se sabe la forma de ingresar comandos, es el momento de

acceder a una base de datos.

Suponga que en su hogar posee varias mascotas y desea registrar

distintos tipos de informacin sobre ellas. Puede hacerlo si crea tablas
para almacenar sus datos e introduce en ellas la informacin deseada.
Entonces, podr responder una variedad de preguntas acerca de sus
mascotas recuperando datos desde las tablas. Los pasos seran:

Crear una base de datos

Crear una tabla
Introducir datos en la tabla
Recuperar datos desde la tabla de varias maneras
Emplear mltiples tablas

2.1.5 Variables de Ambiente y archivos importantes

para instalacin.

Para instalar MySQL como primer instancia el archivo primordial es el que se

descarga de la Web de MySQL. El proceso para instalar MySQL desde un archivo
ZIP es el siguiente:
1. Extraer el contenido del archivo dentro del directorio de instalacin deseado.

2. Crear un archivo de opciones.

3. Elegir un tipo de servidor MySQL

4. Iniciar el servidor MySQL.

5. Establecer la seguridad de las cuentas de usuario por defecto.

2.1.6 Procedimiento general de instalacin de un DBMS

http://www.estructurayprogramacion.com/materias/administracion-de-
base-de-datos/procedimiento-general-de-instalaci%C3%B3n-de-un-
dbms/

2.1.7 Procedimiento para configuracin de un DBMS.

Para configurar nuestro DBMS podemos acceder a las siguientes
pantallas, para Oracle o MySQL.

El esquema de una base de datos (en ingls, Database Schema)

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 informacin sobre privilegios y procedimientos
del gestor y no deben ser elimandos.
http://administracionbd.weebly.com/unidad-2.html

UNIDAD 3 CONFIGURACIN Y ADMINISTRACIN

DEL ESPACIO EN DISCO.
3.1 - Estructuras lgicas de almacenamiento.
3.1.1 - Definicin de espacio de almacenamiento.
Para la gestin del almacenamiento de una base de datos existen 4
conceptos bien definidos que deben
ser conocidos para poder comprender la forma en la que se almacenan
los datos. Estos conceptos son:
bloque de datos, extensiones, segmentos y espacios de tablas.
Bloque de datos (Data blocks).- Se trata de la unidad ms pequea de
almacenamiento en una base de
datos. Generalmente debe ser mltiple del tamao de bloque del sistema
operativo, ya que es la unidad
mnima que va a pedir la BD al sistema operativo. Si no fuera mltiple del
bloque del sistema se aadira un
trabajo extra ya que el sistema debera obtener ms datos de los
estrictamente necesarios. Generalmente
se especifica mediante el parmetro DB_BLOCK_SIZE.
Extensiones (Extents).- Se forma con uno o ms bloques. Cuando se
aumenta tamao de un objeto en la
base de datos, se usa una extensin para incrementar el espacio.

Segmentos (Segments).- Grupo de extensiones que forman un objeto de la base

de datos, como por
ejemplo una tabla o un ndice.
El segmento de datos es una coleccin de extensiones que mantiene todos los
datos para una tabla
o cluster.
El segmento de ndices mantiene todos los datos para un ndice.
El segmento de rollback mantiene datos para rollback, consistencia de lecturas
o recuperacin.
El segmento temporal es una coleccin de extensiones que mantiene datos
pertenecientes a
objetos temporales.
Espacio de tablas (Tablespaces).- Formado por uno o ms archivos de datos
(datafiles) del SO, donde
cada datafile solo puede pertenecer a un determinado tablespace y una base de
datos. Representan un
nivel medio entre la BD y los datafiles.
El SGBD tiene estructuras lgicas y fsicas que el administrador ha de gestionar.
Las estructuras fsicas son
aquellas se pueden ver en el sistema operativo como son los archivos; mientras
que las estructuras lgicas
slo se pueden ver desde el manejador de base de datos, como son por ejemplo
los tablespaces.

Los usuarios ms avanzados tendrn conocimiento de la estructura lgica de la

base de datos, y es
responsabilidad del DBA gestionar la correspondencia entre las estructuras lgicas
y fsicas para tener un
rendimiento ptimo.

3.1.2 - Definicin y creacin del espacio asignado

para cada base de datos.
Una base de datos se divide en unidades lgicas denominadas TABLESPACES.
Un tablespace no es un
archivo fsico en el disco, simplemente es el nombre que tiene un conjunto de
propiedades de
almacenamiento que se aplican a los objetos (tablas, secuencias) que se van a
crear en la base de datos
bajo el tablespace indicado (tablas, secuencias). Un espacio de tablas puede
pertenecer slo a una BD.
Un objeto en la base de datos debe estar almacenado obligatoriamente dentro de
un tablespace.
Cuando se crea una tabla se debe indicar el espacio de tablas (Tablespace) al que
se destina. Por defecto
se depositan en el espacio de tablas SYSTEM.
Cuando se crea un nuevo Tablespace, la capacidad total del tablespace coincidir
con la suma de los
tamaos de los archivos de datos (datafiles) asociados.
Por ejemplo:
create tablespace app_data
datafile /u03/oradata/ userdata01. dbf size 100m,
datafile /u03/oradata/ userdata02. dbf size 250m;
En este caso se crea un tablespace app_data asociado a dos archivos con una
capacidad total de 350M.
Si se quiere incrementar el tamao de la base, se puede hacer incrementando el
tamao de un archivo de
datos (data files) de un Tablespace en particular.
Por ejemplo:
alter database datafile /u03/oradata/ userdata02. dbf resize 200m;
Si no se tiene espacio libre en la particin del disco, entonces se puede agregar
otro archivo de datos (data
files) sobre otra particin de disco para un Tablespace en particular.
Por ejemplo:
alter tablespace app_data add datafile /u01/oradata/ userdata03. dbf size 200m;
3.1.3 - Bitcoras
Las bitcoras, son las estructuras de datos ms ampliamente usada para grabar
las modificaciones de la
base de datos.
Cada registro de la bitcora escribe una nica escritura de base de datos y tiene lo
siguiente:
1. Nombre de la transaccin: Nombre o nmero de la transaccin que realiz la
operacin de escritura.
2. Nombre del dato: El nombre nico del dato escrito.
3. Valor antiguo: El valor del dato antes de la escritura.
4. Valor nuevo: El valor que tendr el dato despus de la escritura.
Existen otros registros de bitcora especiales para grabar sucesos importantes
durante el proceso de
transaccin tal como:
< T1, inicio >
< T1, x, v1, v2 >
< T1, commit >
Es fundamental que siempre se cree un registro en la bitcora cuando se realice
una escritura antes de que
se modifique la base de datos, ya que esto nos da la posibilidad de deshacer una
modificacin que ya se
ha escrito en la base de datos, esto se realizar usando el campo del valor antiguo
de los registros de la
bitcora.
Los registros de la bitcora deben residir en memoria estable y como resultado, el
volumen de datos en la
bitcora puede ser exageradamente grande.
Bitcora (Redo log files) en Oracle
Los archivos de redo log son las bitcoras que registran los cambios a la base de
datos como resultado de
transacciones o acciones internas del servidor Oracle.
Los archivos de redo log protegen la base de datos de la prdida de integridad en
casos de fallas causadas
por suministro elctrico, errores en discos duros, y otras causas.
Es recomendable que los archivos de redo log sean multiplexados para asegurar
que la informacin
almacenada en ellos no se pierda en caso de un fallo en disco.
Consiste en grupos de archivos de redo log y cada grupo est integrado por un
archivo de redo log y sus
copias multiplexadas. Se dice que cada copia idntica es miembro de un grupo, y
cada grupo es
identificado por un nmero.
El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de
redo log a todos los
miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita
una operacin de cambio
de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los
archivos del siguiente
grupo.
Cuando Oracle se ejecuta en modo ARCHIVELOG el proceso en segundo plano
llamado ARCH hace una
copia de cada archivo de redo log online una vez que el proceso LGWR termina
de escribir en l, guarda
dicha copia en los archivos de reconstruccin fuera de lnea (redo log offline) en
disco

3.1.4 - Particiones
Una particin es una divisin de una base de datos lgica o sus elementos
constituyentes en partes
independientes.
La creacin de particiones en una base de datos mejora el rendimiento y simplifica
el mantenimiento. Al
dividir una tabla grande en tablas individuales ms pequeas, las consultas que
tengan acceso nicamente
a una parte de los datos pueden ejecutarse con mayor rapidez, ya que deben
recorrer menos datos. Las
tareas de mantenimiento (por ejemplo, volver a generar los ndices o hacer copias
de seguridad de una
tabla), pueden ejecutarse con mayor rapidez.
Una aplicacin popular y favorable es en un Sistema de Administracin de Base
de Datos Distribuida. Cada
particin puede ser extendida hasta mltiples nodos, y los usuarios en el nodo
pueden hacer transacciones
locales en la particin. Esto aumenta el rendimiento en sitios que tienen
transacciones regularmente
involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la
seguridad.
Esta particin puede hacerse creando bases de datos ms pequeas separadas
(cada una con sus propias
tablas, ndices, y registros de transacciones) o dividiendo elementos
seleccionados, por ejemplo, solo una
tabla.
Particiones horizontales
La creacin de particiones horizontales divide una tabla en varias tablas. As, cada
tabla contiene el mismo
nmero de columnas, pero menos filas. Por ejemplo, se podra crear una particin
horizontal de una tabla
que contenga mil millones de filas en 12 tablas; cada una de las tablas ms
pequeas representara un
mes de datos de un ao especfico. Las consultas que requieran datos de un mes
especfico slo hacen
referencia a la tabla apropiada.
La determinacin del modo de crear particiones horizontales de las tablas
depende de cmo se analicen los
datos. Debera crear particiones de tablas de forma que las consultas hagan
referencia al menor nmero
posible de tablas. De lo contrario, un nmero excesivo de consultas UNION,
utilizadas para mezclar las
tablas de forma lgica en el momento de la consulta, podra afectar al rendimiento.
Particiones verticales
La creacin de particiones verticales divide una tabla en varias tablas que
contienen menos columnas. Los
dos tipos de particiones verticales son la normalizacin y la divisin de filas:
La normalizacin es el proceso estndar de bases de datos que consiste en
quitar columnas
redundantes de una tabla y colocarlas en tablas secundarias vinculadas a la tabla
principal
mediante relaciones de clave principal y clave externa.
La divisin de filas divide verticalmente la tabla original en tablas con menos
columnas. Cada fila
lgica de una tabla dividida coincide con la misma fila lgica en las dems tablas,
segn se
identifica en la columna UNIQUE KEY que es idntica en todas las tablas con
particiones. Por
ejemplo, al combinar la fila con el Id. 712 de cada tabla dividida se vuelve a crear
la fila original.
Igual que las particiones horizontales, las particiones verticales permiten a las
consultas recorrer menos
datos. De ese modo se aumenta el rendimiento de las consultas. Por ejemplo, una
tabla que contenga siete
columnas de las cuales generalmente slo se hace referencia a las cuatro
primeras, puede beneficiarse de
la divisin de las tres ltimas columnas en una tabla independiente.
La creacin de particiones verticales se debe considerar detenidamente, ya que
analizar datos de varias
particiones requiere consultas que combinen las tablas. La particin vertical
tambin puede afectar al rendimiento si las particiones son muy grandes.

3.1.5 Espacios privados

PRIVATE_SGA Define la cantidad de espacio privado que una sesin puede
reservar en la zona de SQL
compartido de la SGA.
3.1.6 Espacios para objetos
3.2 - Segmentos
Un segmento (segment) es aquel espacio reservado por la base de datos, dentro
de un archivo de datos
(datafile), para ser utilizado por un solo objeto. As una tabla (o cualquier otro
objeto) est dentro de su
segmento, y nunca podr salir de l, ya que si la tabla crece, el segmento tambin
crece con ella.
Fsicamente, todo objeto en base de datos no es ms que un segmento
(segmento, trozo, seccin) dentro
de un archivo de datos (datafile). Se puede decir que, un segmento es a un objeto
de base de datos, lo que
un datafile a un tablespace: el segmento es la representacin fsica del objeto en
base de datos (el objeto
no es ms que una definicin lgica).

Existen cuatro tipos de segmentos (principalmente):

Segmentos de TABLE: aquellos que contienen tablas.
 Segmentos de INDEX: aquellos que contienen ndices.
Segmentos de ROLLBACK: aquellos se usan para almacenar informacin de la
transaccin activa.
Segmentos TEMPORALES: aquellos que se usan para realizar operaciones
temporales que no
pueden realizarse en memoria, tales como ordenaciones o agrupaciones de
conjuntos grandes de
datos.
Calcular el tamao de un segmento en Oracle
select segment_name , sum(bytes)/(1024*1024) SegmentSize
from user_extents
where segment_'TABLE' and segment_name = 'MYTABLE'
TABLE = Tipo de segmento: "table," "index" o "cluster
MYTABLE = nombre de la tabla

3.3 - Memoria Compartida.

Cuando de habla de la estructura de memoria, se tienen dos tipos: Una de ellas es
compartida por todos
los usuarios conectados y la otra es dedicada al trabajo de cada uno de ellos.
SGA (Area Global del Sistema):
Esta es la estructura de memoria que es compartida por todos los usuarios y se
dividen en:
Shared pool (Fondo Comn Compartido): almacena parte del diccionario de
datos y las sentencias
SQL que han sido analizadas.
DataBase Buffer Cache (rea de memoria Rpida): almacena los bloques de
datos ledos resultado
de las rdenes SQL ejecutadas por los usuarios conectados.
RedoLogs (rea de registro rehacer): se registran los cambios hechos a la base
de datos.

PGA (Program global rea):

Es un rea de memoria utilizada por los procesos del DBMS. Esta zona de
memoria no se puede compartir
y se divide en:
Procesos de usuarios.- Cuando un usuario se conecta a la base de datos se
crea un proceso de
usuario, Los procesos de usuarios no interactan directamente con la base de
datos, lo hace a
travs de los procesos del servidor.
Procesos del servidor.- Ejecutan las peticiones de los usuarios y devuelven los
resultados. Un
proceso del servidor ejecuta las peticiones de un solo proceso de usuario.
Procesos de fondo (background).- Son creados por cada instancia de la BD y se
encarga de las
entradas/ salidas del SGA, existen los procesos que son obligatorios, los cuales
son:
o Obligatorios (DBWR, LGWR, SMON, PMON, CKPT)
o Opcionales (ARCH, LMON, LCKn, etc)
Para visualizar todos los procesos en segundo plano, puede consultarse la vista
v$bgprocess

3.4 - Instancias mltiples

Cada servidor de bases de datos est compuesto por:
Una Base de Datos: donde se almacenan los datos fsicos (archivos de datos y
otros componentes).
Una instancia: constituye el mecanismo que permite su manipulacin.
Una instancia de Base de datos es el conjunto formado por los procesos y las
estructuras de memoria
que se encuentran en un servidor.
Puede haber mltiples instancias para una nica base de datos o mltiples bases
de datos en una misma
instancia.

Instancias en SQL Server

Una instancia de Motor de base de datos es una copia del ejecutable de
sqlservr.exe que se ejecuta como
un servicio de sistema operativo. Cada instancia administra varias bases de datos
del sistema y una o
varias bases de datos de usuario. Cada equipo puede ejecutar varias instancias
de Motor de base de
datos. Las aplicaciones se conectan a la instancia para realizar el trabajo en una
base de datos
administrada por la instancia.
Cada Base de Datos mantiene sus propios archivos de datos (dnde se
almacenan las tablas, ndices,
vistas, procedimientos almacenados, y resto de objetos de base de datos),
archivos de LOG (dnde se
almacenan las transacciones de dicha base de datos), configuracin (Modo de
Recuperacin o Modo de
Registro, intercalacin, nivel de compatibilidad, etc.). Por el contrario, todas las
bases de datos de una
instancia en particular, comparten la base de datos TEMPDB (dnde se
almacenan los objetos temporales,
resultados intermedios de consultas, etc.) y otros recursos de la Instancia, como la
memoria, la afinidad de
CPU, y la afinidad de entrada/salida (E/S).
Instancia de una Base de Datos en Oracle
Cada instancia Oracle est asociada a una base de datos. Cuando se inicia una
base de datos en un
servidor, se le asigna un rea de memoria (SGA) y lanza uno o ms procesos. A la
combinacin del SGA y
de los procesos es lo que se llama instancia. La memoria y los procesos de una
instancia gestionan las
datos de la base de datos asociada de forma eficiente y sirven a uno o varios
usuarios.

UNIDAD 4.- OPERACIN Y MANTENIBILIDAD

4.1 BITCORAS DE TRABAJO DEL DBMS.

En muchos DBMS la bitcora incluye todo tipo de consulta incluyendo aquellas

que no modifican los datos.

La operacin ROLLBACK est basada en el uso de una bitcora. El DBMS

(Sistema Manejador de Bases de Datos) mantiene una bitcora o diario en cinta o
en disco, comnmente, en el cual se registran los detalles de todas las
operaciones de actualizacin, en particular, los valores iniciales y final del objeto
modificado. Por tanto, si resulta necesario anular alguna modificacin especfica,
el sistema puede utilizar la entrada correspondiente de la bitcora para restaurar el
valor original del objeto restaurado.

4.1.1. FUNCIONES ESPECFICA DE LAS BITCORAS. La estructura ms

ampliamente usada para grabar las modificaciones de la base de datos es la
Bitcora. Cada registro de la bitcora escribe una nica escritura de base de datos
y tiene lo siguiente:

Nombre de la Transaccin

Valor antiguo
Valor Nuevo
Es fundamental que siempre se cree un registro en la bitcora cuando se realice
una escritura antes de que se modifique la base de datos.

Tambin tenemos la posibilidad de deshacer una modificacin que ya se ha

escrito en la base de datos, esto se realizar usando el campo del valor antiguo de
los registros de la bitcora.

Los registros de la bitcora deben residir en memoria estable como resultado el

volumen de datos en la bitcora puede ser exageradamente grande.

Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como

punto de sincronizacin lo cual representa el lmite entre dos transacciones
consecutivas, o el final de una unidad lgica de trabajo, y por tanto al punto en el
cual la base de datos esta (o debera estar) en un estado de consistencia. Las
nicas operaciones que establecen un punto de sincronizacin son COMMIT,
ROLLBACK y el inicio de un programa. Cuando se establece un punto de
sincronizacin:

Se comprometen o anulan todas las modificaciones realizadas por el programa

desde el punto de sincronizacin 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 transaccin, no el programa.

4.1.2 RECUPERACIN ROLLBACK

En tecnologas de base de datos, un rollback es una operacin que devuelve a la

base de datos a algn 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 despus de que se han realizado
operaciones errneas. Son cruciales para la recuperacin de crashes de un
servidor de base de datos; realizando rollback(devuelto) cualquier transaccin 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 gestin 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 tambin publicar cualquier savepoint existente que

puediera estar en uso.

En muchos dialectos de SQL, ROLLBACKs son especficos de la conexin. Esto

significa que si se hicieron dos conexiones a la misma base de datos, un
ROLLBACK hecho sobre una conexin 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 tambin estar implementada mediante control de
concurrencia multiversin.

En el proceso de Rollback, SQL Server comienza a hacer un rollback de todas

las transacciones que no fueron confirmadas adems de las que fueron
rechazadas, dejando de esta manera la base de datos en un estado consistente.

Este proceso de recuperacin en algunos casos puede tardar mucho tiempo

debido a la gran cantidad de informacin que tienen que replicar desde el log de
transacciones. Es por eso que la frecuencia con la que se hacen los checkpoints
dentro de la base de datos es crucial para el tiempo que tardara el servidor en
ejecutar el proceso de recuperacin.

Adicionalmente cabe mencionar que en algunas pocas ocasiones el terminar el

servicio de SQL Server de manera inesperada puede causar corrupciones de
datos, y esto s es grave debido a que en algunos casos puede ser recuperable la
informacin, pero siempre con un riesgo de perder algo de data, y en otros no es
posible arreglar la base de datos, entonces lo nico que queda en estas
situaciones es la restauracin de backups y es ah donde si se tiene una buena
estrategia de backups se puede llegar a recuperar absolutamente toda la
informacin hasta el momento del desastre.

4.1.3 PERMANENCIA COMMIT En cualquier momento, el programa podra

decidir que es necesario hacer fallar la transaccin, con lo que el sistema deber
revertir todos los cambios hechos por las operaciones ya hechas. En el lenguaje
SQL se denomina COMMIT a aplicar_cambios y ROLLBACK a cancelar_cambios.

Las transacciones suelen verse implementadas en sistemas de bases de datos y,

ms recientemente, se han visto incorporadas a como gestiona un sistema
operativo la interaccin con un sistema de archivos (como varias caractersticas de
las bases de datos, debido a que son muy similares arquitectnicamente).

Una sentencia COMMIT en SQL finaliza una transaccin 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 ms 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 recuperacin) existentes que
puedan estar en uso.

En trminos de transacciones, lo opuesto de commit para descartar los cambios

"en tentativa" de una transaccin, es un rollback.
4.2 DEFINICIN DE LOS MODOS DE OPERACIN DE UN DBMS. (ALTA, BAJA,
RECOVERY) El sistema de gestin de bases de datos es esencial para el
adecuado funcionamiento y manipulacin de los datos contenidos en la base. Se
puede definir como: "El Conjunto de programas, procedimientos, lenguajes, etc.
que suministra, tanto a los usuarios no informticos como a los analistas,
programadores o al administrador, los medios necesarios para describir, recuperar
y manipular los datos almacenados en la base, manteniendo su integridad,
confidencialidad y seguridad".

Las funciones esenciales de un SGDB son la descripcin, manipulacin y

utilizacin de los datos.

Descripcin: Incluye la descripcin de: Los elementos de datos, su estructura, sus

interrelaciones, sus validaciones. Tanto a nivel externo como lgico global e
interno esta descripcin es realizada mediante un LDD o Lenguaje de Descripcin
de Datos.

Manipulacin: Permite: Buscar, Aadir, Suprimir y Modificar los datos contenidos

en la Base de Datos.

La manipulacin misma supone: Definir un criterio de seleccin, Definir la

estructura lgica a recuperar, Acceder a la estructura fsica. Esta manipulacin es
realizada mediante un LMD o Lenguaje de Manipulacin de Datos.

Utilizacin: La utilizacin permite acceder a la base de datos, no a nivel de datos

sino a la base como tal, para lo cual: Rene las interfaces de los usuarios y
suministra procedimientos para el administrador.

En trminos ideales, un DBMS debe contar con estas funciones, sin embargo, no
todos las poseen, as existen algunos manejadores que no cumplen la funcin de
respaldo o de seguridad, dejndola al usuario o administrador; sin embargo un
DBMS que sea completo y que deba manejar una base de datos multiusuario
grande, es conveniente que cuente con todas estas operaciones

4.4. MANEJO DE NDICES

Los ndices son "estructuras" alternativa a la organizacin de los datos en una

tabla. El propsito de los ndices es acelerar el acceso a los datos mediante
operaciones fsicas ms rpidas y efectivas. Para entender mejor la importancia
de un ndice pongamos un ejemplo; imagnate que tienes delante las pginas
amarillas, y deseas buscar el telfono de Manuel Salazar que vive en Alicante. Lo
que hars ser buscar en ese pesado libro la poblacin Alicante, y guindote por
la cabecera de las pginas buscars los apellidos que empiezan por S de Salazar.
De esa forma localizars ms rpido el apellido Salazar. Pues bien, enhorabuena,
has estado usando un ndice.

4.4.1 TIPOS DE NDICES

En MySQL se tienen dos tipos de ndices, los cuales son:

NDICES AGRUPADOS

Los ndices agrupados, definen el orden en que almacenan las filas de la tabla
(nodos hoja/pgina de datos de la imagen anterior). La clave del ndice agrupado
es el elemento clave para esta ordenacin; el ndice agrupado se implementa
como una estructura de rbol b que ayuda a que la recuperacin de las filas a
partir de los valores de las claves del ndice agrupado sea ms rpida. Las
pginas de cada nivel del ndice, incluidas las pginas de datos del nivel hoja, se
vinculan en una lista con vnculos dobles. Adems, el desplazamiento de un nivel
a otro se produce recorriendo los valores de claves.

CONSIDERACIONES PARA USAR NDICES AGRUPADOS

Columnas selectivas

columnas afectadas en consultas

Columnas accedidas "secuencialmente"

Columnas implicadas en JOIN, GROUP BY

Acceso muy rpido a filas: lookups

Los 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) estn los datos; en los
ndices no-agrupados, en el nivel de hoja del ndice, hay un puntero a la
localizacin fsica de la fila correspondiente en el ndice agrupado. Adems, la
ordenacin de las filas del ndice est construida en base a la(s) columna(s)
indexadas, lo cual no quiere decir (a diferencia de los ndices agrupados), que la
organizacin fsica de las pginas de datos corresponda con el ndice.

4.4.2 REORGANIZACIN DE 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. Si la tarea solo reorganiza los ndices de una base de
datos individual, puede elegir las vistas o las tablas cuyos ndices reorganiza la
tarea. La tarea Reorganizar ndice tambin incluye la opcin de compactar datos
de objetos grandes. Los datos de objetos grandes son datos de tipo image, text,
ntext, varchar(max), nvarchar(max), varbinary(max) o xml.

La tarea Reorganizar ndice encapsula la instruccin ALTER INDEX de Transact-

SQL. Si elige compactar datos de objetos grandes, la instruccin utiliza la clusula
REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece
LOB_COMPACTION en OFF

Dentro de las tareas habituales de Mantenimiento de las Bases de Datos se

encuentran aquellas destinadas al control y respaldo de las mismas como ser:
Control de Integridad, Chequeo de Consistencia, Copias de Seguridad o
Compactacin de las bases.

Pero tambin es necesario ejecutar trabajos de mantenimiento cuyos objetivos

sean el de mantener la performance de las bases de datos y evitar su
degradacin.

Esos trabajos son la Reorganizacin de ndices y la Actualizacin de Estadsticas.

Estos trabajos son independientes del estado de la base de datos. Puede ocurrir
que a la base le falten estudios de optimizacin pero, al menos, mantendremos la
performance actual.

Si la base se encuentra optimizada, entonces ms an, son necesarios para evitar

la degradacin producto del uso continuo.

Cualquiera de estos trabajos deben realizarse fuera de lnea por motivos de: alto
consumo de recurso y bloqueo de las tablas en el momento de ejecucin.

Las tablas que contienen ndices al ser actualizadas o por insercin de nuevos
datos, generan fragmentacin de estos ndices. Estas fragmentaciones conllevan
a la prdida de performance al acceder a ellas.

La instruccin DBCC DBREINDEX reorganiza el ndice de una tabla o todos los

ndices definidos para una tabla. La reorganizacin de realiza dinmicamente sin
necesidad de conocer la estructura de la misma o las restricciones que ella tenga.
Por lo tanto no es necesario conocer si una tabla tiene clave primaria o si esta
clave es nica y adems pertenece a algn ndice, ya que la reorganizacin no
necesita eliminar y recrear stas restricciones para realizar su trabajo.

La sintaxis de esta instruccin es:

DBCC DBREINDEX
( basededatos.dueo.nombre_de_tabla

[ , ndice

[ , fillfactor ]

) [ WITH NO_INFOMSGS ]

Fillfactor es el porcentaje de espacio de pgina destinado a ser ocupado. El valor

definido reemplaza al que fue generado en el momento de la creacin del ndice.
Si se quiere mantener el valor original, entonces se utiliza el valor 0.

WITH NO_INFOMSGS se suprimen los mensajes generados en la ejecucin.

No es necesario conocer los nombres de todos los ndices de todas las tablas, ya
que si utilizamos la instruccin de la siguiente forma:

DBCC RBINDEX (Movimientos, , 0)

Se reorganizarn todos los ndices que contengan la tabla Movimientos,

conservndose el fillfactor original de cada ndice en particular.

Una de las formas de utilizarlo es, escribir un script con una sentencia DBCC
RBINDEX por cada tabla que necesitemos reorganizar y agendarlas en forma
peridica mediante un trabajo de mantenimiento dentro de algn horario
disponible.

Por lo tanto, la recomendacin ser: elegir las tablas ms accedidas y/o

actualizadas, y reorganizarlas una vez entre semana. Para reorganizar todas las
tablas que contengan ndices se utiliza el mismo concepto, pero dentro de un
procedimiento que recorra todas la tablas de la base y las reorganice, sin
necesidad que escribamos todas la tablas que contiene la base de datos. Estos
procedimientos se pueden encontrar en el Forum bajo el nombre de Tips, y la idea
es generar un trabajo de mantenimiento que se ejecute, por ejemplo, en el fin de
semana.

4.4.2 RECONSTRUCCIN DE NDICES

Es importante peridicamente 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 contencin de disco o
cuellos de botella en el sistema. Normalmente reconstruimos un ndice con el
comando ALTER INDEX.

Es importante tener actualizadas las estadsticas de la base de datos. Para saber

si las estadsticas se estn 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 estadsticas.

SELECT index_name, last_analyzed

FROM dba_indexed

WHERE table_owner=nb_usuario

Nota: Siendo nb_usuario el nombre del esquema del usuario para el que
queramos validar las estadsticas. (Lanzar con usuario SYS)

Para actualizar las estadsticas utilizamos el paquete DBM_STATS. Podemos

actualizar las estadsticas de todos los objetos de un esquema de la siguiente
forma:

Execute DBMS_STATS.gather_schema_stats(Esquema);

Nota: Sustituimos esquema por el nombre de nuestro esquema a actualizar (lanzar

con usuario SYS)

Una vez actualizadas las estadsticas de los ndices de la base de datos lanzamos
la siguiente consulta:

SELECT index_name, blevel,

DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2,

'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OK

FROM dba_indexes where table_owner='Propietario';

Nota: Sustituimos Propietario por el esquema o propietario que queramos verificar

(lanzar con usuario SYS)

Con esta sentencia obtendremos el nombre del ndice, el blevel y si es correcto.

INDEX_NAME

BLEVEL

OK
INX_CUENTA

OK BLEVEL

INX_TRABAJO

OK BLEVEL

INX_DINERO

BLEVEL HIGH

Los ndices que deberamos de reconstruir son los que en la columna ok aparecen
como BLEVEL HIGH.

Blevel (branch level) es parte del formato del B-tree del ndice e indica el nmero
de veces que ORACLE ha tenido que reducir la bsqueda en ese ndice. Si este
valor est por encima de 4 el ndice deber de ser reconstruido.

Comando ALTER INDEX

Como hemos comentado esta sentencia se utiliza para cambiar o reconstruir un

ndice existente en la base de datos.

Para poder ejecutar este comando el ndice debe de estar en el propio esquema
donde intentes ejecutarlo o deberas de tener el privilegio alter any index. Tambin
tenemos que tener en cuenta que para realizar la reconstruccin de un ndice
deberamos de tener cuota suficiente sobre el tablespace que lo lanzamos.

Para reconstruir un ndice bastara con lazar la siguiente sentencia:

ALTER INDEX <index_name> REBUILD;

Para reconstruir una particin de un ndice podramos hacer lo siguiente

ALTER INDEX <index_name> REBUILD PARTITION <nb_partition>

NOLOGGING;
5.1 REPALDO Y RECUPERACION
RECUPERACION
Concepto
Un sistema de recuperacin consiste en restaurar la BD a un estado que se sepa correcto,
tras cualquier fallo que la haya dejado en un estado incorrecto.
Recuperacin de BD:
devolver la BD a un estado consistente
La recuperabilidad significa que, si se da algn error en los datos, hay un bug de programa
o de hardware, 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 dao
se causara. Las actividades de recuperacin incluyen el hacer respaldos de la base de
datos y almacenar esos respaldos de manera que se minimice el riesgo de dao prdida
de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles
y almacenarlos fuera del rea en antelacin a un desastre anticipado. La recuperacin es
una de las tareas ms importantes de los DBAs.
La recuperabilidad, frecuentemente denominada recuperacin de desastres, tiene dos
formas primarias. La primera son los respaldos y despus las pruebas de recuperacin.
La recuperacin de las bases de datos consiste en informacin y estampas de tiempo junto
con bitcoras 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 bitcoras, la diferencia reside en que el DBA debe sacar de lnea
la base de datos en caso de llevar a cabo una recuperacin.
Las pruebas de recuperacin consisten en la restauracin de los datos, despus se aplican
las bitcoras 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 lnea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperacin de bases de
datos sin pruebas de recuperacin, no existe la certeza de que los respaldos sean del todo
vlidos. En la prctica, los respaldos de la mayora de los RDBMSs son raramente vlidos
si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos o
bugs que pudieran haber corrompido los respaldos.
RESPALDO
Es la obtencin de una copia de los datos en otro medio magnetico, 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 realizacin 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.
Bsicamente 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 ultimas 3 copias de los respaldos.

1. $backupFile;
8.
9. exec($command, $salida);
10.
11. // Mantiene los ultimos 3 backups
12. $days=3;
13. $archivos = scandir(./);
14. foreach ($archivos as $key => $val)
15. {
16. if(substr($val,-2) != gz)
17. unset($archivos[$key]);
18. }
19.
20. $i=count($archivos);
21. foreach ($archivos as $key => $val)
22. {
23. if($i
Para sacar un respaldo a tu base de datos usas el mysqldump:
Cdigo PHP:
//
shell> mysqldump -u usuario [-p] nombreBase > respaldoBase.sql
//
shell> mysqldump -u usuario [-p] nombreBase >
/directorio/donde/guardas/respaldoBase.sql

Respaldar la Base de datos MySQL

Hay ocasiones donde es necesario tener el cdigo de nuestra base de datos, ya sea para
hacer un respaldo , para migrar la BD a otro servidor o simplemente porque se nos da la
gana.
Para esto MySQL cuenta con un comando muy bueno, el cual nos entrega un archivo con
todas las tablas, relaciones y registros que se encuentran en la BD.
mysqldump -u usuario -p nombreDB > Archivo_de_salida.sql
Donde usuario hay que reemplazarlo con nuestro nombre de usuario.
Lo nico que hay que considerar es que en el script no se encuentra la creacin de la BD,
as que antes de ingresar este archivo pa crear la BD es necesario agregar las siguientes
lineas al inicio del archivo:
CREATE nombre_base_de_datos;
USE nombre_base_de_datos;

5.1.1 ESPEJEO MIRRORING

Base de Datos Espejo (Database Mirroring) es una configuracin donde dos o tres
servidores de dase de datos, ejecutndose 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 cul 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
configuracin 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 Compaeros (Partners).
La gran ventaja de este mtodo es que permite el failover automtico sin intervencin
humana (siempre que se instale un tercer servidor witness). De hecho, en la cadena de
conexin de las aplicaciones de .NET, podemos especificar cundo conectamos con la
aplicacin el servidor de sql al que nos conectamos y un failover partner, osea un servidor
mirror para que en caso de failover, la aplicacin pueda reconectar automticamente al otro
servidor. La desventaja del mirror, respecto el log shipping y la replicacin, es que slo
podemos tener una mquina secundaria o mirror y que esta no es accesible y no podemos
tenerla en modo lectura.
5.1.1.1 BENEFICIOS DEL ESPEJEO DE DATOS EN UN
DBMS.
La creacin 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 conmutacin automtica por error, la conmutacin
por error pone en lnea rpidamente la copia en espera de la base de datos, sin
prdida de datos. En los dems modos operativos, el administrador de bases de
datos tiene la alternativa del servicio forzado (con una posible prdida de datos) para
la copia en espera de la base de datos. Para obtener ms informacin, vea
Conmutacin de roles, ms adelante en este tema.
Aumenta la proteccin de los datos. La creacin de reflejo de la base de datos
proporciona una redundancia completa o casi completa de los datos, en funcin de
si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para
obtener ms informacin, vea Modos de funcionamiento, ms adelante en este
tema.

Un asociado de creacin de reflejo de la base de datos que se ejecute en SQL Server 2008
Enterprise o en versiones posteriores intentar resolver automticamente cierto tipo de
errores que impiden la lectura de una pgina de datos. El socio que no puede leer una
pgina, solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la
copia sustituir a la pgina que no se puede leer, de forma que se resuelve el error en la
mayora de los casos. Para obtener ms informacin, vea Reparacin de pgina automtica
(grupos de disponibilidad/creacin de reflejo de base de datos).
 Mejora la disponibilidad de la base de datos de produccin 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 creacin de reflejo de la base de datos. Esto incurrir
en el tiempo de inactividad de solo una conmutacin por error nica. Esta forma de
actualizacin se denomina actualizacin gradual. Para obtener ms informacin,
vea Instalar un Service Pack en un sistema con un tiempo de inactividad mnimo
para bases de datos reflejadas.

5.1.1.2 ACTIVACIN DE ESPEJEO EN UN DBMS. MySQL Lo primero que debemos

hacer es checar si ambos servidores se encuentran en red

Caso Windows

Caso Linux Cambie el comando ipconfig por ifconfig

Software Verifique que el MySQL instalado en el maestro y en el esclavo son iguales. En

este caso MySQL Server 5.6

Configuracin del Maestro 1. Localizar el archivo My.ini -Windows- (My.cnf -Linux)

2. Buscar y comentar las siguientes lneas si es que se encuentran:

#skip-networking
#bind-address = 127.0.0.1
3. Agregar despus de la lnea [mysqld] lo siguiente:

log-bin =mysql-bin.log
binlog-do-db=dolar
server-id=1
Nota: El server-id en el servidor siempre ser 1, y los esclavos sern 2, 3 n segn sea
el caso en binlog-do-db se pone el nombre de la base de datos que replicara despus de
signo =

4. Desde el panel de control entramos en Herramientas administrativas, Servicios y

reanudamos MySQL. Este paso se omite en Linux

5. Ahora en el shell de mysql genere una cuenta para el esclavo con el

privilegio REPLICATION SLAVE:

GRANT REPLICATION SLAVE ON *.* TO 'esclavo1'@'%'

IDENTIFIED BY 'bingo';
FLUSH PRIVILEGES;
Nota: esclavo1 es el usuario identificado por el passwword bingo.Los posteriores
replicadores debern ser esclavo2,..., esclavo-n.

6. Seleccione la base de datos a replicar y realice lo siguiente:

USE dolar;
FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS;

El resultado ser algo similar a la figura
5.1.1.3 CREACIN DE ESPACIOS DE DISCO CON ESPEJO.

Discos espejo

Espejeado de disco significa que se conectan dos unidades de disco al mismo controlador
de disco. Las dos unidades se mantienen idnticas cuando el servidor escribe en una
unidad (la primaria), posteriormente se escribe en (la secundaria). Si durante la operacin
falla, la unidad primaria, en su lugar se utiliza la secundaria. Si la secundaria falla, no
importa. En ambos casos los usuarios experimentan una breve pausa mientras el servidor
se asegura que la unidad est muerta, y luego se regresa al servicio normal.

Como sucede con todas las cosas buenas, hay una desventaja. Para contar con este nivel
de confiabilidad, se necesita un segundo disco duro, lo que duplica el costo del
almacenamiento de datos. Pero en lo que concierne a su organizacin, tal vez valga la pena
el costo relativamente pequeo de una unidad de disco, para evitar lo que de otra manera
seria un desastre. Una de las desventajas de los discos espejos es la perdida de
rendimiento. Dado que un controlador maneja dos unidades primarias para escribir los
datos en la unidad secundaria. Esto provoca que las escrituras en disco se tarden el doble.
En un servidor con carga ligera esto quizs no sea tan malo desde el punto de vista del
usuario, ya que el cach de disco del servidor hace que el acceso a disco perezca
extremadamente rpido. Sin embargo, la sobrecarga puede llegar a ser significativa en un
sistema con carga pesada.

Otra de las desventajas del espejeado es que el controlador de disco duro o los cables de
conexin llegan a fallar. Los datos se pueden leer desde la unidad o matriz duplicada sin
que se produzcan interrupciones. Es una alternativa costosa para los grandes sistemas, ya
que las unidades se deben aadir en pares para aumentar la capacidad de
almacenamiento, para los disco espejos. Los discos espejos tambin llamado "duplicacin"
(creacin de discos en espejo). Se basa en la utilizacin de discos adicionales sobre los
que se realiza una copia en todo momento de los datos que se estn modificando. El cual
ofrece una excelente disponibilidad de los datos mediante la redundancia total de los
mismos.
Administracin del espacio libre en un disco.

Es necesario saber qu bloques estn libres. Las opciones son parecidas a las que se
pueden usar para administrar espacio en memoria. Mapa de bits. Un bit por bloque. Es
eficiente si se puede mantener el mapa entero en memoria. Disco de 1 GB, con bloques de
512 KB requiere un mapa de 256 KB. Usado en los MACS. Lista ligada. En un bloque
reservado (fijo) del disco se registran las direcciones de los bloques desocupados. La ltima
direccin apunta no a un bloque libre, sino a otro bloque con ms direcciones de bloques
libres... En MS-DOS se usa la misma FAT para administrar el espacio libre.

Cachs de disco

Ya que el disco es tan lento comparado con la memoria (unas 10000 veces) resulta rentable
usar un cach para mantener en memoria fsica parte de la informacin que hay en el disco,
de manera que, si en el futuro se requiere un bloque que ya est en memoria, se ahorra el
acceso al disco.
Igual que en el caso de memoria virtual, hay que tratar de adivinar qu bloques se van a
acceder en el futuro cercano, para mantener esos bloques en el cach. Pero al contrario de
lo que ocurre con memoria virtual, no se requiere ningn apoyo especial del hardware para
implementar LRU.Ya que todos los accesos a disco pasan por las manos del sistema
operativo. Paradjicamente, LRU no es necesariamente la mejor alternativa tratndose de
bloques de disco. Qu pasa, por ejemplo, en el caso del acceso secuencial a un archivo?
Por otra parte, algunos de los bloques contienen informacin crtica respecto del sistema
de archivos (por ejemplo, un bloque que contiene informacin del directorio raz o de un i-
node o de los bloques libres). Si este bloque es modificado y puesto al final de la cola LRU,
puede pasar un buen tiempo antes de que llegue a ser el menos recientemente usado, y
sea escrito en el disco para ser reemplazado. Si el sistema se cae antes que eso, esa
informacin crtica se perder, y el sistema de archivos quedar en un estado inconsistente.
Se puede modificar un poco LRU, considerando dos factores:

A. Qu tan probable es que el bloque se necesite de nuevo. Bloques de directorios se

suelen usar bastante. El ltimo bloque de un archivo que se est escribiendo, tambin es
probable que se vuelva a necesitar.

B. Qu tan esencial es el bloque para la consistencia del sistema de archivos. Bsicamente

todos los bloques, excepto los de datos, que han sido modificados. Estos deben grabarse
en disco lo ms rpidamente posible.

Planificacin de disco

Un disco, mirado desde ms bajo nivel, no es simplemente una secuencia de bloques. Estn
compuestos de platos, cada uno de los cuales contiene una serie de pistas o tracks
concntricos. A su vez, las pistas se dividen en sectores. Las pistas exteriores, que son
ms grandes, pueden contener ms sectores que las interiores. (En un CD, en realidad hay
una espiral de sectores.) Existe un brazo mecnico con un cabezal lector/escritor para cada
plato. El brazo mueve todos los cabezales juntos. Un cilindro se conforma por las pistas
que los cabezales pueden leer cuando el brazo est en una posicin determinada. Los
bloques lgicos (secuenciales) que ve el sistema de archivos deben traducirse a un tro
(cilindro, plato, sector). El tiempo requerido para leer un sector depende de:

1. El tiempo de bsqueda (seek time), es decir, el tiempo requerido para mover el brazo al
cilindro apropiado.

2. El retardo rotacional, o sea, el tiempo que hay que esperar hasta que el sector requerido
pase por debajo del cabezal.

3. El tiempo de transferencia de los datos.

El primero es el que predomina, de manera que conviene reducirlo para aumentar la

eficiencia del sistema. El sistema de archivo puede ayudar (por ejemplo, con asignacin
contigua). Obviamente, bloques en el mismo cilindro deben considerarse contiguos. Pero
hay otra cosa que se puede hacer, considerando que en un sistema con muchos procesos
la cola de solicitudes pendientes de un dispositivo suele no estar vaca: atenderlas en un
orden que reduzca los movimientos del brazo.
5.1.2 REPLICACIN La replicacin es un conjunto de tecnologas para copiar y distribuir
datos y objetos de bases de datos de una base de datos a otra y, a continuacin, sincronizar
las diferentes bases de datos para mantener la coherencia. Mediante la replicacin, podr
distribuir los datos a diferentes ubicaciones y usuarios remotos o mviles a travs de redes
de rea local y extensa, conexiones de acceso telefnico, conexiones inalmbricas e
Internet.

Por lo general, la replicacin de transacciones se usa en escenarios de servidor a

servidor, que requieren un rendimiento alto, donde se incluye: la mejora de la escalabilidad
y disponibilidad; el almacenamiento datos y generacin de informes; la integracin de datos
desde mltiples sitios; la integracin de datos heterogneos y la descarga de procesamiento
por lotes.

La replicacin de mezcla se ha diseado principalmente para aplicaciones mviles que

presentan posibles conflictos de datos. Los escenarios comunes incluyen: intercambio de
datos con usuarios mviles; aplicaciones de puntos de venta (POS) para el consumidor e
integracin de datos desde varias ubicaciones.

La replicacin de instantneas se usa para proporcionar el conjunto de datos inicial para

la rplica transaccional o de mezcla. Tambin se puede usar cuando es necesario una
actualizacin completa de los datos. Con estos tres tipos de replicacin, SQL Server ofrece
un sistema eficaz y flexible para la sincronizacin de datos en toda la empresa.

5.1.2.1 Beneficios de la replicacin de Datos en un

DBMS
Disponibilidad.-El modo en que la replicacin incrementa la disponibilidad de los datos
para los usuarios y aplicaciones.

Fiabilidad.- Al haber mltiples copias de los datos disponibles en el sistema, se

dispone de un mecanismo excelente de recuperacin cuando existan fallos en nodos.

Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la

replicacin en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.

Reduccin de la carga.- Modo en que se utiliza la replicacin para distribuir datos en

ubicaciones remotas

Copia de seguridad: En condiciones normales, una base de datos replicada de forma

correcta es vlida como copia de seguridad. Adems se puede realizar copias de seguridad
usando un servidor esclavo para as no interferir al servidor maestro.

Mejorar la escalabilidad: Podramos configurar nuestras aplicaciones para balancear

las consultas de lectura (SELECT) entre los servidores replicados.

Alta disponibilidad: En aplicaciones y entornos en donde slo se requieren lecturas,

podramos configurar nuestras aplicaciones para balancear las consultas de lectura
(SELECT) entre los servidores replicados de manera que si uno se cae se contine
prestando servicio.
 Las rplicas locales constituyen una ayuda especialmente til cuando se desea
trabajar en una computadora que en ocasiones no estar conectada a la red donde se
encuentra el servidor en el que reside el curso.

5.1.3 MTODOS DE RESPALDO DE UN DBMS.

En mySQL existen varios mtodos para la realizacin 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 prctica se
utiliz el tipo de tabla InnoDB y el mtodo de backup utilizado es el que funciona con este
tipo de tablas.

InnoDB es una de las tec6-nologas de almacenamiento que utiliza mySQL, es de codigo

abierto. Entre sus caractersticas principales estan que soporta transacciones con
caractersticas 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 caractersticas ms importantes pues una base de datos sin integridad
referencial, es nada mas un conjunto de datos que no denotan infomacin.

Este tipo de almacenamiento tambin 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 compresin de datos, por lo que ocupa un poco mas de espacio
que myISAM.

5.1.3.1 ELEMENTOS Y FRECUENCIA DE RESPALDO

CUANDO RESPALDAR LA INFORMACION

Normalmente cuando uno plantea que va a respaldar los datos de su PC a una persona en
una compaauno tiene que definir muy bien cual es la informacin crtica para la empresa,
por ejemplo la msica que guarde un empleado en su PC no es crtica para las actividades
de la empresa ni lo son las fotos de su ltima fiesta. En cambio su correo electrnico,
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 la data o informacin 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 electrnico
Directorios telefnicos 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.
Imgenes y Fotografas de proyectos
Configuraciones de servicios

Clasificacin de respaldos

Copias de Informacin (Backups).

 Estos respaldos son slo 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 comn. Existen varios tipos de
Software que automatizan la ejecucin de estos respaldos, pero el funcionamiento bsico
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 Informacin" (tpicamente
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 acabo
los tres tipos de respaldos comnmente 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 acabo un Respaldo de
Incremento, slo aquellos archivos que tengan el archive bit sern respaldados; estos
archivos (o bloques) son los que han sido modificados despus de un Respaldo Completo.
Adems cada Respaldo de Incremento que se lleve acabo tambin 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 archive bit permanece intacto.

Frecuencia de Actualizacin de la Informacin

Hay dos puntos importantes en cuanto a la actualizacin de la informacin

1. Que tan frecuentemente se actualiza la informacin

2. Si queremos guardar un histrico de la informacin o no

No toda la informacin se actualiza con la misma frecuencia, hay informacin que puede
durar aos sin ser modificada y otra que se actualice constantemente todos los das, es
importante definir qu informacin se actualiza y en qu momento para hacer una poltica
de respaldo ms eficiente.
La mayora de las aplicaciones de respaldos hacen esto automticamente fijndose en la
fecha de modificacin del archivo y comparndola con la que tiene en el respaldo.

5.1.32. COMANDOS PARA RESPALDO DE DATOS

Para hacer un respaldo de una base de datos MySQL desde nuestro consola o mediante
comandos shell podemos usar el comando mysqldump como lo ejemplificamos en la
siguiente liga.

Comando: mysqldump -u "usuario" -p"contrasea" nombre-de-la-base-de-datos > nombre-

del-respaldo.sql

NOTA: Las comillas deben omitirse tanto en el usuario como en la contrasea.

Para restaurar un respaldo de una base de datos MySQL usamos el siguiente comando
Comando: mysql -u "usuario" -p"contrasea" nombre-de-la-base-de-datos < nombre-del-
respaldo.sql

NOTA: Al igual que en el ejemplo anterior las comillas deben omitirse tanto en el usuario
como en la contrasea.

Respaldo y Restauracin MySQL de Manera Remota.

Para Respaldar o Restaurar una Base de datos remota usamos los mismos comandos que
de manera local, con la nica diferencia de agregar la opcin "-h" con la cual
especificaremos el nombre o direccin del host en donde se encuentra nuestra base.

Para Respaldar usamos:

Comando: mysqldump -u "usuario" -p"contrasea" -h"nombre-o-direccin-del-host"

nombre-de-la-base-de-datos > nombre-del-respaldo.sql

Para restaurar usamos:

Comando: mysql -u "usuario" -p"contrasea" -h"nombre-o-direccin-del-host" nombre-de-

la-base-de-datos < nombre-del-respaldo.sql

5.1.33.MTODOS DE RECUPERACIN DE UN DBMS

Una base de datos corrupta a un estado previo libre de daos. El tipo de tcnica de
recuperacin usado en cada situacin determinada depende de varios factores, incluyendo
los siguientes:

La extensin del dao sufrido por la base de datos. Por ejemplo, si se encuentra que ha
sido un nico registro el que ha sufrido daos, la tcnica de recuperacin es trivial, en
comparacin con el procedimiento de restauracin necesario despus de un choque de una
cabeza.

El nivel de actividad de la base de datos. Las tcnicas de recuperacin son fciles de

implementar en bases de datos que se modifican con escasa frecuencia. Por el contrario,
resulta mucho ms difcil y caro el diseo de tcnicas de recuperacin para bases de datos
que se estn actualizando continuamente. En este ltimo caso, suele tratarse tambin de
bases de datos de gran importancia para sus usuarios, por lo que es de vital importancia
que la recuperacin sea rpida.

La naturaleza de la informacin de la base de datos. Para algunos tipos de datos, la prdida

de una pequea cantidad de informacin puede no resultar particularmente crtica. En otras
situaciones, tales como bases de datos financieras, no es aceptable ninguna prdida de
datos, independientemente de su cuanta. Los dos tipos de circunstancias requieren muy
diferentes aproximaciones en lo que se refiere a fiabilidad y recuperacin.

Estos son:

Copias de seguridad de la base de datos

Para poder efectuar cualquier tipo de restauracin de una base de datos, es necesaria la
realizacin de copias de seguridad (Backus) de la base de datos de forma peridica. Este
proceso consiste en la escritura de una copia exacta de la base de datos en un dispositivo
magntico separado del que contiene a la propia base de datos. En los sistemas ms
grandes, este dispositivo suele ser una cinta magntica. En los sistemas basados en
microordenadores, puede tratarse de un cartucho de cinta de casete, o de uno o ms discos
flexibles. Habitualmente, mientras se est generando una copia de seguridad es preciso
detener todas las dems actividades de la base de datos.

Diarios de transacciones y restauracin/reejecucin

Una extensin de la tcnica anterior consiste en el mantenimiento automtico de un fichero

de ordenador, que contenga una lista de los cambios hechos en la base de datos entre dos
copias de seguridad consecutivas. Esta lista se conoce como diario de transacciones, y se
mantiene siempre en un dispositivo fsico diferente del que almacena a la propia base de
datos. Habitualmente se utiliza para este propsito una unidad de cinta magntica, o una
unidad de disco diferente. La razn para usar un dispositivo separado es simplemente que
si la base de datos resulta daada, la causa de dicho dao no tiene por qu afectar a los
datos almacenados en un dispositivo fsico diferente.

Recuperacin por retroceso

La recuperacin por retroceso resulta til en situaciones en las que el procesamiento de la

base de datos se ve interrumpido, pero la base de datos en s no resulta daada de forma
alguna. Un ejemplo de esto podra ser algn tipo de fallo que produzca una terminacin
anormal de la ejecucin del SGBD. Las transacciones en marcha podran ser abortadas
antes de su finalizacin, y los registros asociados a las mismas quedaran en estados
desconocidos, aunque el resto de la base de datos no se vera afectada.

La tcnica de recuperacin por retroceso requiere que el diario de transacciones conteng

aimgenes iniciales de cada registro de la base de datos que haya sufrido modificaciones
desde la ltima copia de seguridad. Una imagen inicial es una copia de un registro tal como
se encontraba inmediatamente antes de ser modificado como parte de una transaccin, es
decir, justo antes del inicio de dicha transaccin.

5.1.42. APLICACIN DE CADA MTODO

Recuperacin Fsica

La utilizacin de una copia de backup de ficheros de datos siempre necesita de una

recuperacin fsica. Tambin es as cuando un fichero de datos se pone offline sin
un checkpoint.

Oracle detecta que se necesita una recuperacin fsica cuando el contador

de checkpoints de la cabecera del fichero de datos no coincide con el correspondiente
contador de checkpoints del fichero de control. Entonces se hace necesario el comando
recover. La recuperacin comienza en el SCN menor de los ficheros de datos en
recuperacin, aplicando los registros de redo log a partir de l, y parando en el SCN de final
mayor de todos los ficheros de datos.

Existen tres opciones para realizar una recuperacion fsica. La primera es una recuperacin
de BD donde se restaura la BD entera. La segunda es una recuperacin
de tablespace donde, mientras una parte de la BD est abierta, se puede recuperar
un tablespace determinado. Esto significa que sern recuperados todos los ficheros de
datos asociados al tablespace. El tercer tipo es la recuperacin de un fichero de datos
especfico mientras el resto de la BD est abierta.

Requisitos para Utilizar Recuperacin Fsica

La primera condicin que se ha de poner para poder recuperar fsicamente una BD es que
sta se est utilizando en modo ARCHIVELOG. De otro modo, una recuperacin completa
puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace
una copia semanal de los ficheros de la BD, se debera estar preparado para perder, en el
peor de los casos, el trabajo de la ltima semana si sucede un fallo. Ya que los ficheros
de redo log.

Recuperacin de la BD

La BD debe estar montada pero no abierta. El comando de recuperacin es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]

[UNTIL CANCEL]

[UNTIL TIME fecha]

[UNTIL CHANGE entero]

[USING BACKUP CONTROLFILE]

Las opciones entre corchetes son opcionales:

AUTOMATIC hace que la recuperacin se haga automticamente sin preguntar al

DBA por el nombre de los ficheros redo log. Tambin se puede utilizar para este
cometido el comando set autorecovery on/off. Los ficheros redo log deben estar en
la localizacin fijada en LOG_ARCHIVE_DEST y el formato del nombre de los
ficheros debe ser el fijado en LOG_ARCHIVE_FORMAT.
FROM se utiliza para determinar el lugar donde estn los ficheros redo log, si es
distinto del fijado en LOG_ARCHIVE_DEST.

UNTIL sirve para indicar que se desea realizar una recuperacin incompleta, lo que implica
perder datos. Solo se dar cuando se han perdido redo log archivados o el fichero de
control. Cuando se ha realizado una recuperacin incompleta la BD debe ser abierta con el
comando alter database open resetlogs.

Recuperacin de un tablespace
La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de
recuperacin es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion']

TABLESPACE nombre_tablespace [, nombre_tablespace]

Recuperacin de un Fichero de Datos

La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a

recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el fichero a
recuperar offline. Si el fichero es del tablespace SYSTEM la BD debe estar cerrada, ya que
no puede estar abierta con los ficheros del SYSTEM offline. El comando de recuperacin
es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion']

DATAFILE nombre_fichero [, nombre_fichero]

5.2. MIGRACIN DE LA BASE DE DATOS

Migracin de datos cuando nos referimos al traspaso de informacin entre bases de datos.
Si tenemos una aplicacin sobre una base de datos como por ejemplo Access y
posteriormente "crecemos" de manera que nos hace falta un sistema gestor de bases de
datos potente, lo ms seguro es que nos decantemos por Oracle, DB2, Informix, SQLServer
o similares.

En este caso, los datos, que estarn en formato "access" debern pasar a formato
"sqlserver" o formato para "oracle". La migracin de los datos consiste en convertir los datos
desde un sistema de base de datos a otro. Esta migracin conlleva la creacin de tablas o
modificacin de las existentes, cambios en algunos tipos de datos que existen en una base
de datos pero no en otras, etc.

Especialmente delicados son los campos fecha, los numricos (enteros, reales, etc), los de
tipo "memo" o campos de extensin superior a 256 caracteres, campos para imgenes, etc,
ya que cada SGBD los trata o los "espera" de manera diferente.

Actualmente la mayora de SGBD incluyen herramientas de ayuda a la migracin ms o

menos "fiables". No obstante, ni que decir tiene que el proceso de migracin de datos es lo
suficientemente delicado como para realizarlo en un entorno de pruebas, contemplando
toda la casustica posible en cuanto a tipos de datos a manejar, tablas involucradas y
sus relaciones, etc.

5.3. MONITOREO Y AUDITORA DE LA BASE DE DATOS

Qu es la Auditora de BD

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

Quin accede a los datos.

Cundo se accedi a los datos.

Desde qu tipo de dispositivo/aplicacin.

Desde que ubicacin en la Red.

Cul fue la sentencia SQL ejecutada.

Cul fue el efecto del acceso a la base de datos.

Es uno de los procesos fundamentales para apoyar la responsabilidad delegada a IT por la

organizacin frente a las regulaciones y su entorno de negocios o actividad.

Objetivos Generales de la Auditora de BD

Disponer de mecanismos que permitan tener trazas de auditora completas y automticas

relacionadas con el acceso a las bases de datos incluyendo la capacidad de generar alertas
con el objetivo de:

Mitigar los riesgos asociados con el manejo inadecuado de los datos.

Apoyar el cumplimiento regulatorio.

Satisfacer los requerimientos de los auditores.

Evitar acciones criminales.

Evitar multas por incumplimiento.

La importancia de la auditora del entorno de bases de datos radica en que es el punto de

partida para poder realizar la auditora de las aplicaciones que utiliza esta tecnologa.

La Auditora de BD es importante porque:

Toda la informacin financiera de la organizacin reside en bases de datos y deben existir

controles relacionados con el acceso a las mismas.

Se debe poder demostrar la integridad de la informacin almacenada en las bases de

datos.

Las organizaciones deben mitigar los riesgos asociados a la prdida de datos y a la fuga
de informacin.

La informacin confidencial de los clientes, son responsabilidad de las organizaciones.

Los datos convertidos en informacin a travs de bases de datos y procesos de negocios

representan el negocio.
 Las organizaciones deben tomar medidas mucho ms all de asegurar sus
datos.
5.3.12 MONITOREO DE ESPACIO EN DISCO.
Como DBA una de las responsabilidades es supervisar el espacio en disco. Siempre hay
que asegurarse de que se tiene suficiente para sus bases de datos, copias de seguridad de
bases de datos y cualquier otro tipo de archivos que va a almacenar en el servidor. Si no
controla su espacio en disco y se asegura de que tienes espacio suficiente, con el tiempo
uno de sus procesos crticos de bases de datos o componentes va a fracasar porque no se
puede asignar el espacio en disco que necesita.
Dentro de SQL Server hay un procedimiento no documentado que nos puede ayudar a
cumplir este cometido. El procedimiento es XP_FIXEDDRIVES, no lleva parmetros ni nada
y nos regresa todos los discos a los que tiene acceso SQL Server y su espacio disponible
en Megabytes.
Es muy sencillo utilizarlo, solo basta con ejecutar el comando xp_fixeddrives de vez en
cuando desde el Analizador de consultas para revisar la cantidad de espacio libre, aunque
este mtodo consume demasiado tiempo para los administradores de bases de datos. Un
mtodo mejor sera automatizar la ejecucin de este comando peridicamente para revisar
la cantidad de espacio libre.
Algunas tareas de DBA donde la informacin de espacio libre puede ser til:
- La primera que se alerte al DBA cuando el espacio libre cae por debajo de un umbral
especfico en cualquier unidad de SQL Server.
- La segunda sera la de realizar un seguimiento de la historia el espacio libre para la gestin
de la capacidad de espacio en disco.
La forma de construir un proceso para alertar a la DEA, cuando cualquiera de las unidades
de disco de SQL Server cae por debajo de un umbral predeterminado. Para obtener la
informacin xp_fixeddrives en una tabla temporal que se utiliza el siguiente T-SQL.
create table #FreeSpace(
Drive char(1),
MB_Free int)
insert into #FreeSpace exec xp_fixeddrives
A continuacin, por cada unidad se recupera la informacin de espacio libre a partir de esta
tabla temporal y se compara con un umbral que se ha fijado para cada unidad. Si la cantidad
de espacio libre cae por debajo del valor umbral determinado para la unidad, enviar alerta
al DBA mediante xp_sendmail. Aqu est una muestra de un cdigo que hace precisamente
eso.
declare @MB_Free int
create table #FreeSpace(
Drive char(1),
MB_Free int)
insert into #FreeSpace exec xp_fixeddrives
select @MB_Free = MB_Free from #FreeSpace where Drive = 'C'
-- Free Space on C drive Less than Threshold
if @MB_Free < 1024
exec master.dbo.xp_sendmail
@recipients ='[email protected]',
@subject ='SERVER X - Fresh Space Issue on C Drive',
@message = 'Free space on C Drive has dropped below 1 gig'
Esta alerta de espacio libre bajo permite tiempo al DBA para resolver el problema de
espacio libre antes de que sea crtico, y provoque procesos fallidos. Tenga en cuenta que
el cdigo anterior tiene un umbral diferente de espacio libre

5.3.13. MONITOREO DE LOGS.

Monitorear el log regularmente puede ayudarnos a resolver varios problemas dentro de
nuestros sistemas, ya que este puede indicarnos si existen demasiadas transacciones
realizadas por una sola aplicacin, que podra resultar en un mal diseo o simplemente la
necesidad de planear mejor los recursos de log en nuestro servidor de base de datos.

Es muy importante tener en cuenta que si el log de transacciones llegara a saturarse, SQL
Server no podr realizar ms cambios dentro de nuestra base de datos.

La manera de monitorear un log de transacciones, puede llevarse a cabo de 2 maneras,

una de ellas es mediante un comando desde el analizador de consultas y la otra utilizando
los contadores de SQL Server desde el sistema operativo.

Desde el analizador de consultas ejecutar el comando DBCC

SQLPERF(LOGSPACE).
Utilizando los contadores de SQL Server que se describen a continuacin.

http://administracionbd.weebly.com/