Motores bases de datos jd

Sistemas de Gestión de Bases
de Datos
7.2.1 Oracle
Oracle [8] ofrece un completo paquete de herramientas y
aplicaciones para desarrollar, desplegar, gestionar y poner a punto
aplicaciones que requieran una alta disponibilidad. Una discusión
completa de estas herramientas se extendería durante varios
capítulos, por este motivo, esta sección se centra únicamente en
explicar algunas de las características de alta disponibilidad
ofrecidas:

Clústeres reales de aplicaciones Oracle.
o Alta disponibilidad usando clústeres reales de
aplicaciones.
o Ventajas de los clústeres reales de aplicaciones.
o Desventajas de los clústeres reales de aplicaciones.
Recuperación transparente de fallos de aplicación.
o Alta disponibilidad usando la recuperación transparente
de fallos de aplicación.
o Ventajas de la recuperación transparente de fallos de
aplicación.
o Desventajas de la recuperación transparente de fallos de
aplicación.
Oracle Data Guard
o Alta disponibilidad usando Oracle Data Guard.
o Ventajas de Oracle Data Guard.
o Desventajas de Oracle Data Guard.
Replicación Avanzada.
o Alta disponibilidad usando replicación avanzada.
o Ventajas de la replicación avanzada.
o Desventajas de la replicación avanzada.
Combinación de múltiples soluciones.

7.2.1.1 Clústeres reales de aplicaciones Oracle

Oracle RAC (Oracle Real ApplicationClusters) [8] es una configuración
de base de datos que consiste en múltiples instancias de la base de
datos con acceso compartido al mismo conjunto de archivos de datos.
Como su predecesor, RAC está configurado en combinaciones de
hardware/SO específicas capaces de soportar un entorno de clúster.

El Oracle RAC es una combinación de un número de distintos
componentes hardware y software. La lista siguiente detalla los
componentes individuales y sus funciones:

Hardware del servidor clúster: El hardware físico en el que se
aloja la base de datos RAC. Esto comprende dos o más nodos
uniprocesador o multiprocesador conectados en una
configuración clúster con una interconexión de alta velocidad
para la comunicación entre nodos.
Discos compartidos del clúster: Los discos compartidos en los
que se almacenan los archivos de la base de datos. Los discos
compartidos deben permitir accesos directos al disco
simultáneos desde todos los nodos del clúster. Las
configuraciones de discos compartidos pueden ser SAN
(StoreArea Network), RAID compartidos o NAS (Network
Attached Storage), pudiendo conectarse tanto directamente a
los nodos del clúster como a una interconexión de alta
velocidad.
Gestor del clúster: Las funciones OSD
(OperatingSystemDependent) para el control de la
funcionalidad del clúster. Esto se compone de dos módulos
distintos. Primero, el demonio Global Services ejecuta tareas
en nombre del software RAC, como el cierre, inicio y otras
acciones de tipo administrativo en los nodos individuales del
clúster. Segundo, el Node Monitor es responsable de mantener
la comunicación entre los nodos del clúster y el software RAC.
Esto incluye supervisión del estado de los nodos del clúster y el
paso de esta información al software RAC.
Servicio global de cahé/colas: Controla el acceso a los recursos
de todos los nodos que forman parte del RAC. Durante las
operaciones de bases de datos en las que debe accederse al
mismo recurso desde múltiples sesiones, el servicio Global
Cache/Enqueue se encarga de coordinar las operaciones entre
los nodos del clúster. Operaciones como el acceso a bloques de
datos en caché o la ejecución de operaciones de bloqueo,
deben producirse de forma transparente independientemente
de la sesión a la que esté asociado el nodo. Se utiliza un
esquema conocido como dominio de recurso para permitir que
la propiedad de un recurso ``flote'' entre los nodos,
dependiendo de dónde sea óptimamente referenciado.
Fusión de caché: Una de las capacidades más poderosas de
RAC. Utilizando los servicios globales de caché y colas, la fusión
de cachés permite que las sesiones conectadas a un nodo del
clúster hagan referencia a bloques de bases de datos que están

en la memoria caché de un nodo distinto. Cuando se solicita la
lectura de un bloque de base de datos, si el bloque de datos
referenciado ya está en la caché de uno de los nodos del
clúster, Oracle usa la interconexión de alta velocidad para
copiar el bloque entre los nodos. Cuando se solicita la escritura
de un bloque en la base de datos, si el bloque ya está en la
caché de uno de los otros nodos del clúster, Oracle de nuevo
copia los datos entre los nodos pero ahora la propiedad se
asigna al nodo que está ejecutando la actualización del bloque
de datos. Las operaciones de lectura adicionales sobre el
bloque pueden continuar en otros nodos, pero cualquier
escritura del bloque en base de datos se verá forzada a esperar
hasta que la primera sesión que está actualizando efectúe una
confirmación (commit) o un rechazo (rollback).

Siempre que se produce un fallo en uno de los nodos del clúster, se
ponen en marcha las siguientes operaciones:

El demonio de Global Services efectúa una reorganización del
clúster que implica determinar qué nodos ya no forman parte
del clúster. Esto se logra indicando a cada instancia de base de
datos que actualice su entrada en el mapa de miembros
contenido en el archivo de control. Al final del proceso, las
entradas sin actualizar del mapa de pertenencia se juzgan
como nodos con fallos.
La recuperación de la base de datos implica determinar qué
bloques de caché y bloqueos de objetos de la base de datos
pertenecen a la instancia que ha fallado. Asimismo, es
necesario reasignar la propiedad de los recursos.
La recuperación de transacción conlleva la lectura de los
archivos de registro para rehacer el nodo que ha fallado, para
determinar las transacciones que deben aplicarse y las
transacciones incompletas que deberían ser deshechas.
Dependiendo de la cantidad de recuperación que deba
efectuarse, este proceso puede tomar una cantidad de tiempo
excesivo. La característica fast-start-rollback le permite
ajustar la duración máxima del proceso de recuperación y
facilita que la recuperación se efectúe en paralelo.

Las dos configuraciones de alta disponibilidad más simples que se
pueden crear utilizando RAC usan un clúster de dos nodos con una
configuración primario/secundario. Este método usa una base de
datos primaria activa que da servicio a la mayoría de las solicitudes
de conexión de la aplicación. La base de datos secundaria

normalmente no responde a las solicitudes de la aplicación, aunque
con la configuración de red apropiada, la instancia secundaria puede
conectarse directamente para operaciones como el mantenimiento o
los informes por lotes. En caso de fallo de la instancia primaria, la
secundaria toma el control efectuando la devolución de transacción y
recuperación de instancia. Todos los intentos de conexión siguientes
son entonces dirigidos a la instancia secundaria. Los dos tipos de
configuración RAC primaria/secundaria son:

Oyente dedicado básico de clúster real de aplicación es una
configuración en la que cada base de datos tiene su propio
oyente. La aplicación se configura para conectar con el oyente
de la primera base de datos. Cuando una solicitud de conexión
no puede ser satisfecha por la primera base de datos, la
aplicación conecta con la segunda base de datos. En ese caso,
todas las transacciones que se encontraban en curso son
canceladas. La figura 7.1 muestra la configuración de oyentes
para la configuración de oyente dedicado básico RAC.

Figura 7.1: Oyente dedicado básico RAC

Oyente compartido básico de clúster real de aplicación. Una
configuración en la que las bases de datos comparten uno o
más oyentes. Cuando se inicia la base de datos primaria, se
registra con cada uno de los oyentes. La aplicación entonces se
configura para conectar con cualquiera de los oyentes y las
solicitudes son enviadas a la instancia primaria. Cuando la
instancia primaria falla, la instancia secundaria efectúa la
recuperación, se registra como instancia primaria y acepta
todas las conexiones siguientes. Cualquier transacción que
estuviese en proceso cuando falló la instancia primaria es
cancelada y la aplicación tiene que reconectar. La
figura 7.2 muestra la configuración de oyentes para la
configuración oyente compartido básico RAC.

Figura 7.2: Oyente compartido básico RAC

Ventajas de los clústeres reales de aplicaciones

Los RAC (Real ApplicationClusters) ofrecen las siguientes ventajas:

Son mínimos los cambios requeridos en la aplicación para
aprovechar las características ofrecidas por la arquitectura del
RAC.
Crear una solución de alta disponibilidad es extremadamente
fácil usando el RAC de dos nodos.
En una configuración primario/secundario, la recuperación de
instancias tras el fallo de un nodo es automática, mejorando así
el tiempo medio de recuperación o MTTR (mean time
torecover).
Combinando el RAC con otras características, como Oracle RAC
Guard, recuperación transparente de fallos de aplicación
y Oracle Data Guard se puede crear una arquitectura
extremadamente potente, altamente escalable así como
flexible.

Desventajas de los clústeres reales de aplicaciones

Los RAC Real ApplicationClusters) tienen las desventajas que se
exponen a continuación:

Al compartir el subsistema de disco todos los nodos
participantes, la configuración es todavía débil a los fallos de
disco a menos que se den pasos específicos para prevenirlos.
Estos pasos incluyen espejos por hardware.
Dado que la interconexión de alta velocidad es el punto central
de comunicación entre los nodos del clúster, a menos que se
use redundancia puede convertirse en un punto de posibles
fallos.
RAC puede proteger tan sólo contra fallos localizados en caídas
de los nodos del clúster. Por sí mismo, no ofrece ninguna
redundancia remota como la que es necesaria para prevenir
desastres como la pérdida completa de un centro de datos.

Pueden conseguirse mejoras adicionales de alta disponibilidad y
escalabilidad combinando RAC con otras posibilidades de Oracle.

7.2.1.2 Recuperación transparente de fallos de aplicación

Una de las consideraciones de diseño más importantes de cualquier
aplicación es la transparencia para el usuario final que nunca debería
conocer la arquitectura de la aplicación. Desde la perspectiva del
usuario, las interrupciones frecuentes del servicio pueden resultar
frustrantes. Incluso la más elegante solución de alta disponibilidad
puede parecer molesta a los usuarios si requiere que tengan que
reconectar y reiniciar su trabajo.

TAF (TransparentApplicationFailover) [8] es un componente
de Oracle Networking que puede utilizarse para minimizar la
interrupción causada por temas relacionados con conectividad.
Cuando se pierde la conexión entre la aplicación y la base de datos,
TAF ejecuta las siguientes funciones dependiendo de como haya sido
configurado:

Restauración de sesiones de base de datos: Se restaura la
conexión a la base de datos usando el mismo identificador de
usuario y clave utilizados previamente.
Continuación de operaciones SELECT: Las sentencias SELECT
emitidas previamente vuelven a ejecutarse, continuando a
partir del mismo punto en que se produjo la desconexión.

Puesto que TAF no restaura transacciones dudosas, las variables de
sesión de usuario perderán su estado tras la recuperación del fallo. Si
se requiere transparencia completa en la aplicación, sin embargo,
puede combinarse una composición de funciones de retorno para
recuperación de fallos con la escritura de valores en una tabla
temporal en la base de datos para restauración tras la recuperación
del fallo.

A pesar de no ser estrictamente una característica de TAF, un
componente adicional de Oracle Networking que puede utilizarse
para múltiples instancias de bases de datos, como con RAC, para
mejorar la transparencia de la aplicación, es el balanceo de cargas.
Esto permite que las conexiones a la aplicación se repartan entre
todas las instancias de bases de datos disponibles. El balanceo de
cargas puede usarse también con bases de datos replicadas y bases
de datos de reserva de Oracle Data Guard. Cuando se combina con la
reconexión automática de TAF, esto ofrece una mejora significativa
de alta disponibilidad minimizando la interrupción de sesiones.

Ventajas de la recuperación transparente de fallos de aplicación

TAF ofrece las siguientes ventajas:

Las aplicaciones pueden reconectarse transparentemente a la
base de datos sin intervención del usuario.
Las sentencias SELECT previamente ejecutadas continúan
donde se quedaron.
TAF puede combinarse con el balanceo de cargas para mejorar
la escalabilidad y disponibilidad de forma significativa.

Desventajas de la recuperación transparente de fallos de
aplicación

TAF tiene las siguientes desventajas:

No es posible la restauración de toda la información de sesión.
Las transacciones previas son deshechas.

7.2.1.3 Oracle Data Guard

ODG (Oracle Data Guard) [8] ofrece una solución integrada para la
configuración y gestión de bases de datos de reserva. Una
implementación de base de datos de reserva consiste en una o más
bases de datos que son copias separadas de una base de datos en
producción. A diferencia de las bases de datos RAC, las bases de
datos de reserva pueden situarse en la misma localización dentro del
mismo centro de datos que la base de datos en producción,
localizarse remotamente en una red de área ancha (WAN) o una
combinación de ambos. Algunos de los usos de las bases de datos de
reserva incluye el mantenimiento de bases de datos separadas para
informes, una base de datos fuera de sede para recuperación de
desastres o una copia de la base de datos de producción usada para
desarrollo o prueba de aseguramiento de la calidad.

La lista siguiente incluye algunos de los muchos componentes que son
parte de la arquitectura ODG.

Base de datos primaria: La base de datos en producción que es
la fuente de datos para la instancia de reserva. Una sola base
de datos primaria puede tener múltiples bases de datos de
reserva.
Base de datos de reserva: La base de datos que es copia de la
base de datos primaria en producción.
Servicios de registro: El método por el que los registros de
rehacer son transferidos desde la base de datos primaria a las
bases de datos de reserva. También controlan la frecuencia con
que los archivos de registro para rehacer se aplican a las bases
de datos de reserva.
Data GuardBroker: Es el componente software que se encarga
de la creación, control y gestión de la configuración de base de
datos primaria/secundaria.
Sede de Data Guard: La colección de una base de datos
primaria y hasta nueve bases de datos de reserva.

Una base de datos de reserva puede crearse utilizando tanto el
componente Data Guard Manager de Oracle Enterprise
Manager como herramientas desde la línea de comandos. Crear y
gestionar una sede ODB implica estos pasos:

Configurar la base de datos primaria: La base de datos
primaria debe estar funcionando en modo ARCHIVELOG y la misma
plataforma hardware, versión de SO y versión del software
RDBMS que el usado para la base de datos de reserva.
Determinación del modo de protección. Cuando cree una base
de datos de reserva, considerar qué modo de protección es el
apropiado, podría ser importante. ODG permite utilizar un
número de distintos modos de protección.
o Modo de protección garantizada: Asegura que todos los
cambios sean propagados a la sede de la base de datos de
reserva después de que hayan sido confirmados en la base
de datos primaria.
o Modo de protección instantánea: Asegura que todos los
cambios se propaguen a la base de datos de reserva tras
ser confirmados en la base de datos primaria a menos que
la conectividad de la red lo impida. Una vez que la
conectividad de red se haya restablecido, los registros
para rehacer se aplican para conseguir que la base de
datos de reserva esté actualizada.
o Modo de protección rápida: Procura que los cambios se
propaguen a la base de datos de reserva tan pronto como
sea posible, sin causar una degradación del rendimiento
en la base de datos primaria.
o Modo de protección demorada: Asegura la propagación
de todos los cambios a la base de datos de reserva una
vez ha transcurrido un pequeño periodo de tiempo. Con
la espera del modo de protección demorado, el retraso
en la propagación puede especificarse para permitir que
la base de datos quede detrás de la base de datos en
producción.
Determinar el modo de operación de reserva: Utilizado para
controlar la frecuencia con que los cambios se aplican a la base
de datos de reserva tras la propagación desde la base de datos
primaria. La base de datos puede estar funcionando en uno de
los dos modos siguientes:
o Modo de recuperación gestionada: Permite a la base de
datos de reserva aplicar todos los cambios tan pronto
como se propaguen a la sede de reserva. La base de datos

no está disponible para uso, sin embargo, hasta que ha
sido abierta.
o Modo de sólo lectura: Permite que la base de datos
permanezca abierta sólo para consultas de sólo lectura.
Sin embargo, no se aplican cambios a la base de datos
hasta que el modo se cambia a modo de recuperación
gestionada.

La figura 7.3 muestra de forma global la arquitectura de ODG.

Figura 7.3: Arquitectura de Oracle Data Guard

Una vez se han creado y configurado las bases de datos de reserva,
el broker ODG gestiona y supervisa la propagación y aplicación de
registros para rehacer, dependiendo del modo de protección
seleccionado. Ya que ODG permite la creación de múltiples instancias
de reserva, la mejor configuración de protección podría ser tener un
número de bases de datos de reserva, cada una de ellas con un modo
de protección distinto.

Si la base de datos primaria queda innaccesible por problemas de
hardware en el nodo de la base de datos primaria, puede iniciarse
una recuperación del fallo con la base de datos de reserva. La
cantidad de datos perdidos durante la operación de recuperación del
fallo dependerá del modo de protección elegido. Una vez se haya
producido la recuperación del fallo, la base de datos de reserva
asume el papel de base de datos primaria.

Una vez resuelto el problema de hardware en el nodo de la base de
datos primaria, volver a la configuración original requiere volver a

crear una instancia de la base de datos copiando de nuevo la base de
datos y reconfigurando el nodo de reserva con su estado original.

ODG permite el inicio manual de un intercambio desde la base de
datos primaria a la base de datos de reserva sin necesidad de
reinstanciar cuando se produzca la vuelta a la situación original. Esto
puede ser útil para efectuar mantenimiento en los nodos de bases de
datos.

Ventajas de Oracle Data Guard

ODG ofrece las siguientes ventajas:

Puede ser utilizado conjuntamente con RAC y la recuperación
transparente de fallos de aplicación.
Dependiendo del modelo de protección elegido, el intercambio
y recuperación de errores puede ocurrir con poca o ninguna
pérdida de información.
La configuración y administración se simplifican con Data Guard
Manager.
Data Guard ofrece recuperación de desastres si la base de
datos de reserva se mantiene en una localización remota.
Data Guard es flexible puesto que la base de datos de reserva
puede mantenerse automáticamente o de forma manual
mediante entradas de usuario y/o guiones.
Las necesidades de ancho de banda son menos intensivas
comparadas con otras soluciones de alta disponibilidad ya que
sólo se propagan los archivos de registro guardados desde la
base primaria a la que está en reserva.

Desventajas de Oracle Data Guard

ODG tiene las siguientes desventajas:

Aunque ODG puede configurarse para funcionar en nodos
locales, no ofrece la misma escalabilidad que los Oracle RAC.
Dependiendo del modo de protección elegido, el intercambio y
recuperación ante fallos pueden necesitar una cantidad de
tiempo significativa.
La frecuencia de la propagación depende mucho del ancho de
banda disponible en la red. En un entorno con un significativo
volumen de cambios en la base de datos, la cantidad de
cambios propagados puede provocar un excesivo tráfico en la
red.

No existe un mecanismo fácil de vuelta atrás para volver a la
máquina primaria original una vez que se ha activado la de
reserva. La base de datos de reserva debe reconstruirse como si
fuera la primaria e iniciarse una recuperación de fallo en la
primaria original (ahora la de reserva).
Mientras la base de datos de reserva está abierta en modo sólo
de lectura, no puede mantenerse sincronizada con la base de
datos primaria (esto es, no pueden aplicarse los archivos de
reconstrucción guardados mientras está abierta).
Los datos no presentes en los registros de reconstrucción
guardados (como las tablas e índices creados mediante la
opción NOLOGGING/UNRECOVERABLE) no se propagan a la reserva. Por
ello, los comandos que desconectan la reconstrucción deben
evitarse o tienen que implementarse medidas explícitas para
registrar y propagar manualmente esos comandos. La
implementación de un procedimiento robusto de parcheo de
base de datos puede ayudar a través de los registros de
reconstrucción archivados si no se detecta y rectifica a tiempo.
La base de datos de reserva debe estar funcionando en el
mismo hardware, versión de SO y versión de DBMS que la base
de datos principal.

7.2.1.4 Replicación avanzada

AR (AdvancedReplication) [8] es un sofisticado mecanismo de
replicación disponible en Oracle. AR permite que una o más bases de
datos origen, con ciertos esquemas predeterminados, e incluso con
segmentos específicos dentro de cada base de datos sean replicadas
a una o más bases de datos destino en un esquema de replicación de
sentido único o múltiple. Así, tanto las base de datos de origen como
las de destino pueden gestionar de forma concurrente las lecturas y
escrituras. Desde una perspectiva lógica, AR ofrece una base de datos
de reserva ``en caliente''.

A diferencia de un escenario convencional de base de datos de
reserva, la base de datos destino está abierta y disponible para
recuperación inmediata ante un fallo de la base de datos origen (ver
figura 7.4). Idealmente, el destino es mantenido en una máquina
separada en una situación remota para propósito de recuperación de
desastres.

Figura 7.4: Arquitectura de replicación avanzada

Bajo AR, las copias múltiples de bases de datos o subconjuntos
específicos son escritas concurrentemente y se mantienen
sincronizadas casi en tiempo real. Una configuración así se denomina
configuración multi-maestro (porque existen múltiples copias
maestras). Si no se desea sincronización inmediata, puede tomarse
un modelo dirigido por eventos para propagar las transacciones de un
maestro a los otros. Por ejemplo, la propagación puede estar basada
en tiempo, produciéndose durante horas específicas de poco uso. Si
se está usando la replicación para propósitos de recuperación de
fallos, sin embargo, la sincronización debería ser inmediata. Por ello,
cada copia de la base de datos debería de mantenerse de
manera peer-to-peer. Todas las escrituras inicialmente se almacenan
de forma local, y luego se remiten a cada base de datos de destino
utilizando el mecanismo push, en oposición a la replicación simple de
instantáneas que se obtiene al tirar (pull) de los datos desde la base
de datos origen.

Cada transacción se propaga de forma consistente para prevenir
violaciones de la integridad de los datos. Si se producen violaciones o
conflictos de integridad, se llevan a cabo los esquemas específicos
para resolución de conflictos. Éstos pueden producirse por una
variedad de razones. Por ejemplo, si distintos usuarios efectúan
cambios en la misma fila en cada base de datos, existirá un conflicto.
Una violación de clave única es otro ejemplo de estos conflictos. Los
conflictos deben ser detectados y resueltos amigablemente. AR
ofrece potentes algoritmos para la detección de conflictos y su
resolución. La resolución de conflictos puede ser consistente o variar
al nivel de segmento (tabla) o incluso columna. Hay disponibles
múltiples técnicas de resolución de conflictos, como utilizar el último

de los cambios, usar el primero de los cambios, utilizar los cambios
específicos a una cierta sede/base de datos, etc.

A medida que las transacciones van remitiéndo, si una base de datos
destino específica no está disponible, las transacciones son retenidas
en el origen en la cola diferida. Cuando la base de datos de destino
está disponible otra vez, se aplican en ella las transacciones. La falta
de disponibilidad de una o más bases de datos destino no evitan que
las transacciones sean propagadas a las restantes copias de la base
de datos.

Tanto las sentencias DML como las DDL se propagan entre todas las
maestras. AR tradicionalmente ha usado desencadenadores
(triggers), colas asíncronas y varias tablas periódicas para
implementar distintos esquemas de replicación. La replicación
basada en desencadenadores es efectiva en ciertos escenarios.

Tradicionalmente, el enfoque basado en desencadenadores en AR es
disuasorio, evitando que las sedes con una fuerte actividad puedan
usarlo eficientemente sin una degradación significativa del
rendimiento. AR en Oracle usa desencadenadores y paquetes
internos. Los desencadenadores y paquetes internos son módulos de
código en C enlazados en el núcleo de Oracle. Esto hace el código
relativamente más a prueba de manipulación (con seguridad
elevada), así como ligero y eficiente, permitiendo que la
implementación sea rápida y escalable. No se configuran ni
mantienen componentes externos. Al no generarse paquetes ni
disparadores, pueden ser instanciados y ejecutados con mayor
rapidez. La propagación de datos es manejada mediante el protocolo
de flujo directo, en lugar de mediante el igualmente fiable, pero
menos eficaz, protocolo de confirmación en dos fases.

En el caso de AR, durante el fallo de una copia específica de la base
de datos, la causa del fallo debe determinarse y la base de datos
recuperarse/reonstruirse desde la última copia o desde salvaguardas.
Como se indicó previamente, existe la posibilidad de una pérdida de
datos (las escrituras más recientes) durante ese fallo. Siempre que
una copia específica de la base de datos falla, las otras copias
continúan funcionando a menos que se produzca un desastre mayor
en cuyo caso todas las copias existentes son descartadas. Las
posibilidades de que esto ocurra son remotas. Durante estas
situaciones, el intervalo de fuera de servicio es significativo porque
la base de datos tiene que reconstruirse usando la última salvaguarda
disponible. Todo el tráfico de clientes/usuarios tiene que redirigirse
a través de TAF o Net8 a copias supervivientes de la base de datos.

Ventajas de la replicación avanzada

AR ofrece las siguientes ventajas:

Todas las bases de datos mantenidas por AR pueden
mantenerse abiertas y en uso concurrente.
AR puede utilizarse para recuperación de desastres teniendo
una copia de la base de datos mantenida en una sede remota.
Existe independencia de hardware ya que las máquinas en que
se crean las bases de datos pueden ser de distintos fabricantes,
plataformas y versiones de SO.
Se han efectuado mejoras a Oracle Enterprise Manager para
simplificar la configuración y administración de bases de datos
replicadas.

Desventajas de la replicación avanzada

AR tiene las siguientes desventajas:

La propagación podría no ser siempre inmediata. Los cambios
de datos en una base de datos pueden no ser visibles
inmediatamente en las otras bases de datos.
Durante desastres, existe una posibilidad de alguna pérdida de
datos porque la base de datos de una sede puede destruirse
antes de que los últimos cambios se hayan propagado. Si la
base de datos de una sede falla, pero no es destruida, la
pérdida de datos pordría ser temporal y todas las copias de la
base de datos pueden sincronizarse una vez que la base de
datos se recupere del fallo.
Los mecanismos de resolución de conflictos deben ser bien
planificados y tener en cuenta escenarios en los que puede
escribirse directamente en las copias de la base de datos para
prevenir corrupción lógica de los datos.

7.2.1.5 Combinación de soluciones

Cada una de las opciones de alta disponibilidad ofrece protección
contra ciertos tipos de fallos. A veces, la mejor opción es combinar
dos o más de las soluciones y prevenir una amplia variedad de
situaciones causantes de paros. Por ejemplo, usando RAC nos
protegemos contra fallos de nodos locales solamente, pero usándolo
con ODG obtenemos una protección adicional contra escenarios de
desastres, como una pérdida completa del centro de datos.

Microsoft SQL Server
Disponibilidad es un término que describe los períodos que está
operativo un determinado sistema informático. Así se pueden
determinar las horas en las que se espera que los usuarios puedan
tener acceso al sistema, teniendo en cuenta los períodos
programados de no disponibilidad debidos al mantenimiento o
actualización del sistema.

Una de las tareas clave en la administración de un sistema o
aplicación consiste en tomar todas las precauciones para reducir al
mínimo el tiempo de parada no programado. Los cortes de servicio no
programados provocan la frustración de los usuarios, pueden reducir
su productividad y, en algunos casos, pueden tener un efecto
significativo en la marcha de la empresa. Por ejemplo, en el caso de
una solución de comercio electrónico, la falta de disponibilidad
producirá, casi con certeza, la pérdida de ingresos y, si se produce
con frecuencia, puede hacer que los clientes dejen de acudir al sitio.

Los aspectos de disponibilidad se suelen tratar, a menudo, junto con
las posibilidades de escalabilidad de una solución. Mientras que la
disponibilidad trata de resolver el problema que supone proporcionar
acceso a la aplicación dutante un período aceptable, la escalabilidad
está relacionada con el problema asociado a proporcionar acceso
simultáneo a un número aceptable de usuarios.

Hay dos métodos principales para aumentar la escalabilidad: el uso
de procesadores más rápidos o el uso de un mayor número de
procesadores.

7.2.2.1 Escalabilidad

Los métodos de crecimiento tratan de aumentar el número de
usuarios simultáneos a los que puede dar servicio un servidor
individual. Normalmente, para conseguir esto se agregan nuevos
recursos hardware al servidor.

El aumento de la memoria RAM instalada en un servidor puede
mejorar mucho su capacidad para procesar con mayor rapidez las
solicitudes que recibe. A menudo, este sistema sencillo y
relativamente económico puede mejorar el rendimiento y la
escalabilidad del sistema.

El multiproceso permite ejecutar en paralelo varios subprocesos. La
capacidad de Microsoft Windows 2000 para usar multiproceso
simétrico (SMP) permite instalar varios procesadores en el equipo.

Un método alternativo para aumentar la escalabilidad consiste en
distribuir la carga de proceso entre varios servidores. Puede usar un
sistema denominado balanceo de carga para asegurarse de que las
tareas de proceso se distribuyen por igual entre todos ellos.

Hay varios sistemas para aumentar la escalabilidad de las soluciones
de SQL Server por medio de la instalación de servidores adicionales.
Los sistemas de replicación y los servidores de reserva mejoran la
escalabilidad y la disponibilidad, mientras que las federaciones de
servidores suponen una mejora en cuanto a escalabilidad, aunque
disminuyen la disponibilidad.

La replicación puede usarse para distribuir los datos entre varios
equipos de la empresa donde se ejecuta SQL Server. Esto permite
que los usuarios muy alejados geográficamente puedan tener acceso
a una aplicación de base de datos sin que necesiten una conexión
permanente con la instalación central. Este sistema permite mejorar
la escalabilidad global de una solución ya que distribuye la carga de
proceso.

También puede mejorar la disponibilidad ya que permite que los
usuarios trabajen con sus copias locales de datos, aun en el caso de
que la base de datos central no esté disponible.

Los servidores de reserva de solo lectura son copias exactas de los
servidores de producción de la base de datos. Se puede usar un
servidor de reserva como origen de datos de sólo lectura para la
generación de informes y otras operaciones de sólo lectura, con lo
que se descarga de parte del trabajo del servidor de producción y se
mejora la escalabilidad. También mejora la disponibilidad, ya que,
en el caso de que el servidor de producción quede fuera de servicio,
el servidor de reserva puede tomar su lugar.

Las federaciones de servidores están formadas por varios equipos
con SQL Server donde cada uno contiene un subconjunto de una tabla
de datos. Se pueden consultar y actualizar las tablas por separado
por medio de una vista dividida y actualizable que muestra al usuario
una única tabla virtual. Este sistema mejora la escalabilidad aunque
tiene un efecto desfavorable en la disponibilidad ya que introduce
varios puntos donde se pueden producir errores.

7.2.2.2 Aumentar la disponibilidad mediante Microsoft .NET
Enterprise Server

Microsoft .NET Enterprise Server [16] es una familia completa de
aplicaciones de servidor que permite crear, distribuir y administrar
soluciones Web integradas y escalables. Una aplicación se divide en
tres capas o más, y se reparte entre varios equipos. Cada capa se
puede mantener y configurar de forma independiente, lo que permite
un alto grado de flexibilidad en cuanto al diseño y administración de
la aplicación. Hay varias formas de optimizar la disponibilidad en
cada una de las capas de la aplicación.

Figura 7.5: Modelo de 3 capas

Capa de presentación

La capa de presentación proporciona los servicios de software que
permiten a los usuarios usar la aplicación. Puede tratarse de una
aplicación Windows instalada en el equipo del usuario o una
aplicación Web a la que tienen acceso los usuarios por medio de un
explorador.

Una aplicación Windows instalada de forma local estará disponible
siempre mientras la instalación no sufra ningún daño. En una red
Windows 2000, puede usar Windows Installer para lograr que las
instalaciones dañadas se reparen automáticamente y sea posible
instalar a petición componentes adicionales.

Para mejorar la disponibilidad de una aplicación Web, puede
distribuir el sitio Web en varios servidores. Puede usar balanceo de
carga en la red Windows 2000 para crear un grupo de servidores que
responda dinámicamente a una petición de cliente en función de la
dirección IP de origen. En este caso se asigna a cada servidor del
grupo un conjunto de direcciones IP a las que debe responder. Si se

produce un error en el servidor, los restantes servidores se reparten
las direcciones IP que quedan desatendidas, con lo que el sitio sigue
estando disponible.

Capa de lógica empresarial

La capa de lógica empresarial contiene el software que implementa
las reglas peculiares de una empresa en una aplicación.
Normalmente, esta capa está compuesta por componentes del
modelo de objetos componentes (COM, Componente ObjectModel)
que contienen las reglas de la empresa.

Se puede lograr la máxima disponibilidad de la capa de lógica
empresarial con grupos de servidores divididos en clústeres y
administrados mediante Application Center 2000.
Además,Application Center 2000 proporciona balanceo de de la carga
de componentes (CLB, Component Load Balancing), una de las
características de Servicios de componentes, lo que permite
distribuir los componentes en varios servidores y equilibrar de forma
dinámica su carga en función de la disponibilidad y trabajo de cada
uno.

En el caso de procesos asincrónicos de empresa que no precisen de
una respuesta inmediata, se pueden usar los componentes de colas
de los servicios de componentes para que sea posible el acceso a la
lógica empresarial aunque el servidor de base de datos no esté
disponible.

Capa de datos

En una aplicación de tres capas, las bases de datos SQL Server forman
parte de la capa de datos. La disponibilidad de esta capa se puede
mejorar de varias formas.

En el caso de una instalación de servidor único, se pueden emplear
soluciones con tolerancia a fallos mediante tecnología RAID. Windows
2000 es compatible con RAID nivel 1 (discos espejo) y RAID nivel 5
(creación de bandas de disco con paridad). Ambos sistemas se pueden
usar para garantizar la disponibilidad de la base de datos completa
incluso en el caso de un error de disco.

Si hay más de un servidor instalado, se puede usar la replicación de
datos para hacer que la base de datos esté disponible en varios
puntos alejados o, incluso, al alcance de usuarios sin conexión. Así se

permite que los usuarios usen la aplicación de base de datos cuando
no se puede establecer una conexión con el servidor de publicación.

Para alcanzar un altísimo grado de disponibilidad se puede usar la
organización por clústeres con conmutación por error. Este sistema
se basa en las capacidades del uso de clústeres de Windows 2000 y
permite crear un servidor virtual formado por varios equipos físicos.
En el caso de que se produzca un error en un servidor, los restantes
servidores del clúster hacen que la base de datos siga estando
disponible.

Finalmente, se puede usar un servidor de reserva que contenga una
copia completa del servidor de producción de la base de datos, que
se podrá comenzar a utilizar en el caso de que se produzca un error
en el servidor. Este servidor de reserva se mantiene sincronizado con
el servidor de producción mediante un sistema denominado trasvase
de registros en el que los registros de transacciones del servidor de
producción se aplican al servidor de reserva.

7.2.2.3 Clústeres con conmutación por error

Un clúster está formado por dos o más equipos independientes que
trabajan conjuntamente como si fueran un único equipo. La
organización por clústeres [16] constituye una eficaz forma de
aumentar la disponibilidad ya que permite la conmutación en caso de
error. Si un miembro del clúster tiene un error, los restantes
miembros garantizan que las operaciones no se vean afectadas.

Figura 7.6: Organización por clústeres de Windows

Componentes de un clúster

Tenga en cuenta los siguientes hechos acerca de la organización por
clústeres de Windows:

Los servidores miembros de un clúster se conocen como nodos.
Los nodos de un clúster deben estar vinculados entre sí por
medio de un vínculo de comunicación de red independiente.
Cada nodo debe disponer de una conexión a uno o varios discos
compartidos (RAID), donde se almacenan los datos del clúster.
Los recursos, como aplicaciones o unidades lógicas, se
combinan en grupos de recursos a los que se asigna un nodo
principal. Este nodo es el predeterminado para el acceso a esos
recursos

Conmutación por error

Los nodos de un clúster usan software de organización por clústeres
para mantener la disponibilidad y realizar la conmutación en caso de
error. El Monitor de recursos realiza la comunicación entre el Servicio
de clúster y los recursos de las aplicaciones en el clúster. El Servicio
de clúster controla la comunicación entre los nodos y realiza la
conmutación en caso de error.

En el caso de que haya un error en una aplicación debido a un error
del equipo, el Servicio de clúster tratará de reiniciar la aplicación. Si
no lo consigue, reiniciará la aplicación en otro nodo del clúster, al
que moverá todos los recursos de esa aplicación.

Si se produce un error en un nodo, el Servicio de clúster reparte
automáticamente el trabajo que realizaba ese nodo entre los
restantes miembros del clúster.

Clústeres con conmutación por error

La organización por clústeres con conmutación por error de SQL
Server está diseñada para que trabaje conjuntamente con la
organización por clústeres de Windows. Cuando se instala la
organización por clústeres con conmutación por error en un clúster,
permite que varios equipos SQL Server aparezcan como un
único servidor virtual.

Un clúster con conmutación por error de SQL Server 2000 puede
incluir uno o varios servidores virtuales. Cada servidor virtual consta
de uno o varios nodos. Puede crear servidores virtuales durante la

instalación de SQL Server y puede instalar un servidor virtual para
cada grupo de recursos del clúster subyacente de Windows.

En un clúster con conmutación por error de SQL Server, cada servidor
virtual debe tener asignado un nombre de red de forma que los
clientes puedan tener acceso a él a través de la red. Un servidor
virtual puede tener asignadas varias direcciones IP. Puede asignar
distintas direcciones IP para todas las subredes disponibles, con lo
que se garantiza la conexión a la red aún en el caso de que ocurra un
error en un adaptador de red o enrutador.

Organización por clústeres activo-pasivo

Puede configurar SQL Server en un clúster de forma que sólo esté
activa una copia de SQL Server en cualquier momento. El otro
servidor SQL Server está pasivo y sólo se activa cuando se produce un
error en el nodo principal. En el caso de una conmutación por error,
el nodo secundario se hace cargo de los recursos y carga de trabajo
del nodo principal. Esta configuración ofrece protección frente a
errores de sistema, al tiempo que proporciona un rendimiento
óptimo.

Figura 7.7: Organización por clústeres activo-pasivo

La configuración por clústeres con conmutación por error activo-
pasivo se puede realizar siempre que se disponga de los siguientes
componentes y se cumplan las condiciones mencionadas:

El disco de cada nodo contiene una copia de Windows 2000
Advanced Server o Windows 2000 DataCenter Server. El disco
también debe tener instalado Organización por clústeres de
Windows.
Una copia de SQL Server debe estar instalada en el disco SCSI o
en la matriz de discos que comparten ambos nodos.
Hay una conexión de red que vincula los dos servidores físicos.
Se ha creado un servidor virtual que representa el conjunto
formado por los dos servidores físicos. Puede crear un servidor
virtual mediante el Asistente para clústeres con conmutación
por error.

Los clientes que se conectan a este servidor virtual no saben a qué
servidor físico activo están conectados.

Organización por clústeres activo-activo

En entornos en los que hay varias aplicaciones de bases de datos, se
puede usar la organización por clústeres activo-activo para mejorar
la disponibilidad de las aplicaciones al tiempo que se ejecutan en un
host distinto par aumentar el rendimiento. En una configuración por
clústeres con conmutación por error activo-activo, cada nodo ejecuta
una o varias copias de SQL Server. De esta forma, es posible que cada
nodo actúe como servidor principal de uno o varios servidores
virtuales, y como servidor secundario del resto de los servidores.

Figura 7.8: Organización por clústeres activo-activo

Esta configuración utiliza al máximo ambos nodos, aunque mantiene
la posibilidad de conmutación por error. Sin embargo, si se produce
la conmutación por error, el rendimiento general se verá afectado ya
que un nodo debe hacer frente a la carga de trabajo de ambos nodos.

La configuración por clústeres con conmutación por error activo-
activo se puede realizar siempre que se disponga de los siguientes
componentes y se cumplan las condiciones mencionadas:

El disco de cada nodo mantiene una copia de Windows 2000
Advanced Server o Windows 2000 Datacenter Server. El disco
también debe tener instalada la organización por clústeres con
conmutación por error.
Debe haber dos discos físicos SCSI o matrices RAID de hardware
compartidos en un bus SCSI compartido.

Debe haber instalada una copia de SQL Server en cada uno de
los discos compartidos.
Debe haber al menos dos conexiones de red que vinculen los
dos servidores físicos.
Se deben haber instalado dos servidores virtuales, cada uno de
los cuales debe representar al conjunto formado por los dos
servidores físicos. Los clientes se pueden conectar a cualquiera
de los servidores virtuales.

7.2.2.4 Servidores de reserva y trasvase de registros

Un servidor de reserva [16] es un servidor físico independiente que
contiene una copia exacta del servidor de producción. Si se produce
un error en el servidor de producción, se puede realizar
inmediatamente la conmutación al servidor de reserva, con lo que se
reduce al mínimo el tiempo de inactividad y se alcanza un alto grado
de disponibilidad.

Un servidor de reserva es un segundo servidor que refleja el
contenido del servidor principal. Se puede usar el servidor de reserva
para sustituir al servidor principal cuando se produce un error en
éste. También se puede usar como una copia de sólo lectura de la
base de datos, con lo que se descarga parte del trabajo del servidor
principal.

Para mantener sincronizado el servidor de reserva con el servidor
principal puede copiar y cargar los registros de transacciones del
servidor principal al servidor de reserva. Debe comprobar que SQL
Server utiliza el modelo de recuperación completa para que se
realicen las copias de seguridad del registro de transacciones.

El transvase de registros automatiza el proceso de sincronización
mediante el uso de trabajos de SQL Server Agent. La secuencia de
sucesos que componen el transvase de registros incluye la realización
de copias de seguridad de los registros de transacciones de la base de
datos principal, la copia de éstos a una ubicación secundaria y su
restauración en la base de datos secundaria. En concreto:

SQL Server Agent realiza una copia de seguridad del registro de
transacciones del servidor principal y le asigna un nombre
basado en la fecha y hora actuales.
El SQL Server Agent del servidor de reserva copia a una carpeta
del del servidor secundario la copia de seguridad del registro de
transacciones.

El SQL Server Agent del servidor secundario ejecuta un trabajo
de carga para restaurar el registro de transacciones en la base
de datos del servidor de reserva.

Motores bases de datos jd

Más contenido relacionado

La actualidad más candente (20)

Similar a Motores bases de datos jd (20)

Último (20)

Motores bases de datos jd