UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA EN CIENCIAS Y SISTEMAS

SOLUCIN DE ALTA DISPONIBILIDAD DE BASE DE DATOS

POR HARDWARE O POR SOFTWARE?

EDGAR FELIPE ALEJANDRO LPEZ LEMUS

Asesorado por: Ing. Moiss Fabriccio Daz Arvalo

Guatemala, julio de 2005

NDICE GENERAL

NDICE DE ILUSTRACIONES

VIII

GLOSARIO

RESUMEN

XIV

OBJETIVOS

XVI

INTRODUCCIN

XVII

1. ALTA DISPONIBILIDAD DE BASE DE DATOS 24 x 7

1.1. Alta disponibilidad de base de datos 24 x 7

1.2. Niveles de disponibilidad

1.3. Tiempo fuera de servicio

1.3.1. Tiempo fuera de servicio planeado

1.3.2. Tiempo fuera de servicio no planeado

2. ALTA DISPONIBILIDAD DE BASE DE DATOS POR HARDWARE

2.1. Qu es un cluster?

2.1.1. Nodo de cluster

2.1.1.1.

Nodo primario

2.1.1.2.

Nodo de reserva

10

2.1.1.3.

Nodo de duplicacin

10

2.2. Modelos bsicos de cluster

2.2.1. Cluster shared disk

10

2.2.2. Cluster shared nothing

11

2.3. Servidor cluster

11

2.4. Cluster por replicacin de datos

12

2.5. Conmutacin por anomala

12

2.6. Conmutacin por administracin

12

2.7. Gestin del proceso de grupos de recursos de cluster

de datos y de aplicacin

13
I

2.8. Ventajas de un cluster

13

2.8.1. Escalabilidad

13

2.8.1.1. Escalabilidad vertical

14

2.8.1.2. Escalabilidad horizontal

14

2.9. RAID (local)

2.9.1. Introduccin a los sistemas RAID

15

2.9.2. Funcionamiento del sistema RAID

15

2.9.2.1. Data stripping

16

2.9.2.2. Paridad

16

2.9.2.3. Hot spare

16

2.9.2.4. Hot swap

16

2.9.3. Ventajas

17

2.9.4. Tipos de implementaciones

17

2.9.4.1. Hardware RAID

18

2.9.4.2. Software RAID

18

2.9.5. Controladora RAID interna o externa?

18

2.9.6. Tipo de cache

2.9.6.1. Write back

19

2.9.6.2. Write through

19

2.9.7. Tipo de arreglos

2.9.7.1. Arreglos paralelos

19

2.9.7.2. Arreglos independientes

20

2.9.8. RAID 0
2.9.8.1. Definicin

20

2.9.8.2. Requerimientos mnimos

21

2.9.8.3. Confiabilidad

21

2.9.8.4. Rendimiento

21

2.9.8.5. Disponibilidad

22

2.9.8.6. Ventajas

22

2.9.8.7. Desventajas

22

II

2.9.9. RAID 1
2.9.9.1. Definicin

23

2.9.9.2. Requerimientos mnimos

23

2.9.9.3. Confiabilidad

23

2.9.9.4. Rendimiento

24

2.9.9.5. Disponibilidad

24

2.9.9.6. Ventajas

24

2.9.9.7. Desventajas

25

2.9.10. RAID 2
2.9.10.1. Definicin

25

2.9.10.2. Confiabilidad

26

2.9.10.3. Rendimiento

26

2.9.10.4. Disponibilidad

27

2.9.10.5. Ventajas

27

2.9.10.6. Desventajas

27

2.9.11. RAID 3
2.9.11.1. Definicin

27

2.9.11.2. Requerimientos mnimos

28

2.9.11.3. Confiabilidad

28

2.9.11.4. Rendimiento

29

2.9.11.5. Disponibilidad

29

2.9.11.6. Ventajas

29

2.9.11.7. Desventajas

29

2.9.12. RAID 4
2.9.12.1. Definicin

30

2.9.12.2. Requerimientos mnimos

30

2.9.12.3. Confiabilidad

30

2.9.12.4. Rendimiento

31

2.9.12.5. Disponibilidad

31

2.9.12.6. Ventajas

31

2.9.12.7. Desventajas

31
III

2.9.13. RAID 5
2.9.13.1. Definicin

32

2.9.13.2. Requerimientos mnimos

32

2.9.13.3. Confiabilidad

33

2.9.13.4. Rendimiento

33

2.9.13.5. Disponibilidad

33

2.9.13.6. Ventajas

33

2.9.13.7. Desventajas

34

2.9.14. RAID 0 + 1
2.9.14.1. Definicin

34

2.9.14.2. Requerimientos mnimos

35

2.9.14.3. Confiabilidad

35

2.9.14.4. Rendimiento

35

2.9.14.5. Disponibilidad

35

2.9.14.6. Ventajas

35

2.9.14.7. Desventajas

36

2.9.15. RAID 53
2.9.15.1. Definicin

36

2.9.15.2. Requerimientos mnimos

36

2.9.15.3. Confiabilidad

37

2.9.15.4. Rendimiento

37

2.9.15.5. Ventajas

37

2.9.15.6. Desventajas

37

2.10. Opciones de almacenamiento para arquitecturas de alta

disponibilidad
2.10.1. Storage Area Network (SAN)

38

2.10.1.1. Definicin

38

2.10.1.2. Rendimiento

39

2.10.1.3. Disponibilidad

40

2.10.1.4. Crecimiento

40

2.10.1.5. Ventajas

40
IV

2.10.1.6. Desventajas

41

2.10.2. Network Attached Storage (NAS)

2.10.2.1. Definicin

41

2.10.2.2. Rendimiento

42

2.10.2.3. Disponibilidad

42

2.10.2.4. Crecimiento

43

2.10.2.5. Ventajas

43

2.10.2.6. Desventajas

44

3. ALTA DISPONIBILIDAD DE BASE DE DATOS POR SOFTWARE

3.1. Replicacin
3.1.1. Definicin

45

3.1.2. Ventajas

46

3.1.3. Tipos de replicacin

46

3.1.3.1. Unidireccional

47

3.1.3.2. Bidireccional

47

3.1.3.3. Sncrona

48

3.1.3.4. Asncrona

48

3.1.4. El porqu de la replicacin

48

3.1.5. Replicacin basada en logs

49

3.1.6. Replicacin usando disparadores

49

3.1.7. Replicacin instantnea (Snapshot)

51

3.1.7.1. Instantneas simples e instantneas complejas

51

3.2. Solucin Oracle Data Guard

3.2.1. Definicin

52

3.2.2. Restricciones

53

3.2.3. Requerimientos mnimos

55

3.2.4. Funcionamiento

57

3.2.5. Confiabilidad

64

3.2.6. Rendimiento

65

3.2.7. Disponibilidad

66
V

3.2.8. Crecimiento

68

3.2.9. Ventajas

68

3.2.10. Desventajas

70

3.3. Solucin Oracle Real Application Clusters

3.3.1. Definicin

71

3.3.2. Restricciones

72

3.3.3. Requerimientos mnimos

74

3.3.4. Funcionamiento

76

3.3.5. Confiabilidad

85

3.3.6. Rendimiento

85

3.3.7. Disponibilidad

86

3.3.8. Crecimiento

87

3.3.9. Ventajas

88

3.3.10. Desventajas

89

3.4. Solucin Shareplex para Oracle

3.4.1. Definicin

90

3.4.2. Restricciones

90

3.4.3. Requerimientos mnimos

91

3.4.4. Funcionamiento

92

3.4.5. Confiabilidad

95

3.4.6. Rendimiento

96

3.4.7. Disponibilidad

97

3.4.8. Ventajas

98

3.4.9. Desventajas

100

3.5. Solucin SQL Server 2000 Cluster

3.5.1. Definicin

100

3.5.2. Restricciones

101

3.5.3. Requerimientos mnimos

101

3.5.4. Funcionamiento

103

3.5.5. Disponibilidad

105

3.5.6. Crecimiento

107
VI

3.5.7. Ventajas

107

3.5.8. Desventajas

107

4. COMPARACIN DE SOLUCIONES DE ALTA DISPONIBILIDAD

DE BASE DE DATOS POR HARDWARE O POR SOFTWARE
4.1. Comparacin de ventajas y desventajas de soluciones
de alta disponibilidad de base de datos por hardware y
por software

109

CONCLUSIONES

115

RECOMENDACIONES

119

BIBLIOGRAFA

121

VII

NDICE DE ILUSTRACIONES

FIGURAS
1

Causas del tiempo fuera de servicio

Grfica de las causas desconocidas no planeadas

Cluster shared disk y shared nothing

11

Escalabilidad vertical y escalabilidad horizontal

14

RAID de nivel 0

21

RAID de nivel 1

23

RAID de nivel 2

26

RAID de nivel 3

28

RAID de nivel 4

30

10

RAID de nivel 5

32

11

RAID de nivel 0 + 1

34

12

RAID de nivel 53

36

13

Topologa tpica de SAN

39

14

Topologa tpica de NAS

42

15

Replicacin unidireccional

47

16

Replicacin bidireccional

47

17
18
19
20
21

Configuracin tpica de la solucin Oracle Data Guard y los

servicios de transporte y aplicacin de los redo logs
Failover de una base de datos primaria hacia una base de datos
standby
Interconexin de los nodos en un cluster de base de datos para
Oracle RAC
Proceso de instancia especfica de la solucin Oracle RAC
Solicitud de cambio a un bloque para una operacin de
modificacin
VIII

60
67
77
79
81

22
23
24

Escritura de bloques a disco

83

Muestra el proceso bsico de replicacin usado por el producto

Shareplex para Oracle
Configuracin de SQL Server 2000 cluster

94
106

TABLAS

Tiempo sin servicio anual

II

Requerimientos mnimos de sistema operativo para la solucin

55

Oracle Data Guard

III

Requerimientos mnimos de hardware para la solucin Oracle

56

Data Guard sobre plataforma basada en Windows

IV

Requerimientos mnimos de hardware para la solucin Oracle

57

Data Guard sobre plataforma basada en Unix

V

Requerimientos mnimos de sistema operativo para solucin

74

Oracle Real Application Clusters

VI

Requerimientos mnimos de hardware para la solucin Oracle

76

Real Application Clusters

VII

Comparacin de las caractersticas mas relevantes de las

110

soluciones mencionadas
VIII

Precios de lista de las bases de datos relacionales utilizadas en

el presente trabajo

IX

111

GLOSARIO
Backup

Es una copia de la base de datos en un medio removible.

Cluster

Grupo de sistemas independientes que trabaja como un

nico sistema.

Commit

Comando de base de datos que significa realizado, hace

que los cambios en los datos sean permanentes.

Control

Contiene las entradas que especifican la estructura fsica

files

de la base de datos Oracle.

Datafiles

Contienen todos los datos de la base de datos Oracle.

DDL

Data definition language o lenguaje de definicin de datos.

DML

Data manipulation language o lenguaje de manipulacin de

datos.

Downtime

Tiempo fuera de servicio planeado o no planeado que

pueden experimentar los sistemas al no estar disponibles
en el caso de fallas en sus componentes.

Failback

Proceso de rehabilitar operaciones en el nodo primario

cuando ya ha sido reparado.

Failover

Recuperacin de una falla, regularmente se ejecuta hacia

un nodo activo.

Fault
resilient

Resistencia a fallas.
X

Fault

Tolerancia a fallos. Habilidad de un proceso para manejar

Tolerance

interrupciones sin tener que afectar los datos o la

integridad del proceso.

Hardware

Toda

pieza

fsica

palpable

que

conforma

una

computadora.
Host

Nombre genrico que se le da a una computadora a la cual

se conectan varios usuarios

Instancia

Es la combinacin de los procesos en segundo plano y los

buffers de memoria. Cada instancia tiene su propio SGA.

Interconexin

Enlaces de comunicacin entre los nodos del cluster.

LAN

Local Area Network o red de rea local.

Latencia

La diferencia entre tiempo cuando el dato origen es

cambiado y cuando el dato destino refleja ese cambio.

Logminer

Es un utilitario y bsicamente lo que hace es leer o recorrer

los redo logs, viendo su contenido para efectos de
bsqueda de transacciones, informacin, etc.

MAN

Metropolitan Area Network o red de rea metropolitana

Mirroring

Espejeado. Copia exacta de un disco a otro.

Nodo

Un nodo de un cluster es cualquier sistema que sea

miembro de ste.
XI

Nologging

Operacin que no deja registro o no inserta informacin en

los redo logs.

OLTP

Procesamiento de transacciones en lnea, generalmente en

un entorno de alta intensidad en procesamiento de datos.

RAID

Redundant

array

of

Independent

Disks

arreglo

redundante de discos independientes o de bajo costo.

Reconcile

Funcin de reconciliacin entre instancias.

Redo

Cada base de datos tiene 2 o ms redo log files. Su

Log files

principal funcin es almacenar los cambios hechos a la

base de datos Oracle.

Row

Conjunto de atributos o valores pertenecientes a una

entidad o registro en una tabla. Un row es una coleccin
de informacin correspondiente a la columna para un solo
registro.

Rowid

Es un identificador global nico para un row en la base de

datos. Es creado al mismo tiempo que el row es insertado
en la tabla y destruido cuando es removido de la tabla.

SCSI

Small Computer System Interface.

SGA

Es un grupo de estructuras de memoria compartida que

contienen los datos e informacin de control de una
instancia de base de datos Oracle.

XII

Sistema

Conjunto de programas de software que controlan el

operativo

funcionamiento general del computador y que administran

los recursos del mismo.

Software

Todos los programas que hacen funcionar a una

computadora.

TCP/IP

Protocolo de comunicacin utilizado para transmitir datos

en una red de computadoras.

WAN

Wide Area Network o red de rea amplia.

XIII

RESUMEN

Los sistemas de informacin de los negocios y empresas globales

poseen clientes en todo el mundo que requieren acceso a los datos las 24
horas del da, 7 das de la semana. Lo que quiere decir que no hay ninguna
interrupcin para los sistemas, eso significa alta disponibilidad; sin embargo,
los componentes de un computador pueden fallar y con ello se pierde el
acceso a la base de datos, lo que se traduce en prdida para las empresas.
Es por eso que las aplicaciones web, sistemas en lnea que generan gran
procesamiento de transacciones, necesitan altos niveles de disponibilidad
para los sistemas manejadores de bases de datos, los cuales no pueden
bajar de 99% del tiempo en servicio. Experimentar un porcentaje de tiempo
fuera de servicio del 1% al ao, significa que tendr un tiempo de 3.65 das
para reparar al componente fallido o darle mantenimiento. Claro est que si
se quiere aumentar ese porcentaje a casi el 100%, equivale a encontrar una
solucin de alta disponibilidad de base de datos ya sea por medio de
hardware o por medio de software, que aun que signifique una gran
inversin, si el negocio es de misin crtica, vale la pena.
En el mercado se encuentran varios manejadores de base de datos,
en el presente trabajo se encontrar los manejadores ms comunes como
Oracle 9i y SQL Server 2000; los cuales tienen soluciones de alta
disponibilidad de base de datos y stas combinadas con soluciones de alta
disponibilidad de base de datos por hardware, hacen posible disminuir ese
tiempo fuera de servicio.

XIV

Los clusters son grupos de sistemas independientes que funcionan

como un nico sistema, estos proporcionan un mejor rendimiento al distribuir
la carga entre los nodos que lo conforman.

Combinados con un

almacenamiento compartido que proporcione redundancia de los datos,

utilizando un arreglo redundante de discos independientes mas comnmente
conocido como RAID se solucionara el problema del tiempo fuera de
servicio.
La replicacin es una solucin de alta disponibilidad de base de datos
por software que implica tener una o ms copias de la base de datos en
produccin en ms de un lugar y que la misma se pueda utilizar en caso de
una destruccin total del sitio de produccin sin que los usuarios noten qu
es lo que ha sucedido.
Por lo tanto, es necesario comparar las caractersticas ms relevantes
resumidas en un cuadro que contengan las soluciones de alta disponibilidad
de base de datos por hardware o por software como si las mismas
proporcionan

recuperacin

desastres,

disponibilidad,

confiabilidad,

escalabilidad, costo, etc., para tomar una decisin que ayudara a tener un
considerable tiempo en servicio de sus sistemas de informacin.

XV

OBJETIVOS

General
Comparar las ventajas y desventajas de la alta disponibilidad de base de
datos por hardware o por software.

Especficos
1. Describir el porqu de la alta disponibilidad de las base de datos 24 x 7.
2. Definir qu es un cluster.
3. Describir el porqu de la replicacin.
4. Describir las ventajas y desventajas de alta disponibilidad de base de
datos por medio de hardware.
5. Describir las ventajas y desventajas de la alta disponibilidad de base de
datos por medio de software.

XVI

INTRODUCCIN

En el presente trabajo se expone la alta disponibilidad de las bases de

datos puesto que ya no se trata de una simple preferencia de las
organizaciones, ahora es un factor crtico para su xito, sobre todo, cuando
la informacin vital de las empresas se comparte electrnicamente entre los
empleados, socios y proveedores. La ms mnima falla de la red puede
resultar en la prdida de ganancias, prdida de productividad o algo peor.
Un cluster es una coleccin de computadores independientes que
ejecutan una serie de aplicaciones de forma conjunta y aparecen ante
clientes como un solo sistema. Los clusters son una solucin de hardware al
que se le puede agregar un almacenamiento redundante y ste ser una
buena solucin de alta disponibilidad de base de datos ya que el cluster
puede ocultar ante los usuarios del sistema los fallos de componentes y
proporcionar servicios de alta disponibilidad.
La replicacin es una solucin basada en software y es el proceso de
mantener copias de los datos del sistema principal que pueden ser usados
como datos alternativos sobre otros sistemas. Esas copias son usadas si el
sistema principal necesita estar fuera de lnea para efectuar copias de
seguridad o rutinas de mantenimiento (alta disponibilidad), en caso de
emergencia, cuando el sistema principal haya fallado (recuperacin de fallo)
o en una situacin de destruccin total como lo es un terremoto
(recuperacin de desastre). Una simple copia de seguridad restaurada en
un sistema alterno, puede ser considerada como una forma de replicacin.

XVII

Cuando se habla de alta disponibilidad en hardware, se hace

referencia a tener dos mquinas con igual hardware y sistema operativo con
un canal de alta velocidad y un ancho de banda grande (fibra ptica), la(s)
mquina(s) comparte(n) el acceso a una base de datos en un arreglo de
discos.
Cuando se habla de alta disponibilidad por software, se hace
referencia a tener una mquina 1 con un tipo de hardware, sistema operativo
y la base de datos del sistema situada en un punto geogrficamente distante
de otro local ya sea en unos cientos de kilmetros o bien en una parte del
mundo, sta utiliza un canal de comunicacin con un ancho de banda normal
o incluso por medio de Internet, con el cual se estar refrescando los
cambios a la base de datos del lugar origen al remoto en donde se
encuentra la mquina 2 con igual tipo de hardware, sistema operativo y una
rplica de la base de datos de la mquina 1.
Es importante mencionar que para que las soluciones de alta
disponibilidad de base de datos por hardware o software ms comunes le
ayuden a tener ideas, caractersticas y parmetros para la evaluacin de las
alternativas que mejor satisfagan las necesidades de la empresa que las
consulta, es necesario que posea informacin sobre las soluciones ms
comunes sobre esta tecnologa.

XVIII

1. ALTA DISPONIBILIDAD DE BASE DE DATOS 24 x 7

1.1. Alta disponibilidad de base de datos 24 x 7

Los sistemas de informacin de los negocios y empresas globales poseen
clientes en todo el mundo que requieren acceso a los datos todos los das las
24 horas. Varias aplicaciones necesitan altos niveles de disponibilidad para los
sistemas manejadores de bases de datos, incluyendo los sistemas de tiempo
real, aplicaciones web y otros tipos de sistemas en lnea.
La criticidad se determina en funcin de varios factores. Uno de ellos es la
naturaleza del servicio; si para la empresa es fundamental que est disponible
(independientemente del nmero de usuarios) este servicio es crtico. Si el
servicio ha de estar activo en un periodo de tiempo para un nmero elevado de
usuarios, tambin es crtico. En ambos casos la no disponibilidad puede
suponer elevadas prdidas para la empresa. Un caso tpico es un proveedor de
servicios Internet.
La alta disponibilidad significa acceder a los datos y aplicaciones donde
quiera que lo necesite y con un nivel de desempeo aceptable.

La alta

disponibilidad congenia con los aspectos de servicio del sistema como un no

rompimiento total y como es percibido por los usuarios finales.

En este

contexto, confiabilidad de componentes de hardware y software y rendimiento,

tiempo de respuesta, etc. son partes de un sistema disponible.

La alta

disponibilidad es la proporcin de tiempo en el que un sistema es productivo y

es usualmente expresado como un porcentaje.
1

Los sistemas de alta disponibilidad bajan entre 100% y 99.9% de

disponibilidad. En la tabla que se muestra a continuacin la primer columna
significa el porcentaje de tiempo en que un sistema corre sin ningn tipo de
falla, en la siguiente columna se muestra el resto del porcentaje en que un
sistema debe estar fuera de servicio y en la siguiente columna su equivalente
en tiempo al ao.
Tabla I. Tiempo sin servicio anual
Porcentaje

de Porcentaje

tiempo

en tiempo

servicio

de
Anual

fuera

de servicio

Normalizado
(segundos)

98%

2%

7.30 das

630,720

99%

1%

3.65 das

315,360

99.8%

0.2%

17 horas, 30 minutos

63,000

99.9%

0.1%

8 horas, 45 minutos

31,500

99.99%

0.01%

52 minutos, 30

3,150

segundos
99.999%

0.001%

5 minutos, 15 segundos

315

99.9999%

0.0001%

31.5 segundos

31.5

Fuente: www.enlace.cl/empresa/anexos/alta_disponibilidad.pdf

La disponibilidad es expresada de la siguiente manera:

MTTF
(MTTF + MTTR)
donde:

MTTF (Mean-Time-To-Failure) tiempo promedio que un sistema corre (sin

fallas) despus que ha sido inicializado o reparado.
MTTR (Mean-Time-To-Repair) es el tiempo promedio necesario para
reparar o restaurar una falla en el sistema.
En el entorno de negocios, hoy en da, pocas empresas pueden quedarse
sin acceso a las misiones crticas por ms de 8 horas, no pueden tolerar ms
que una falla por ao, alrededor de 8760 horas.

Adems, pocos usuarios

finales deberan considerar un sistema disponible si el desempeo est por

debajo de algn nivel o si el sistema es nicamente disponible para algn
porcentaje de la comunidad de usuarios. Considerando esos hechos por un
mnimo, nivel de entrada sistema de alta disponibilidad, el MTTF es 8760
horas y el MTTR es 8 horas, lo cual da una disponibilidad de 99.9%.
1.2. Niveles de disponibilidad

Convencional: las funciones de negocios pueden verse interrumpidas y la

integridad de los datos no es esencial.
Disponibilidad: 90%
Mecanismos: servidor de base de datos regular con respaldo tradicional
(tcnicas de recuperacin y copia de seguridad).

Media (High Reliable):

las funciones de negocios pueden verse

interrumpidas pero se debe mantener la integridad de datos.

Disponibilidad de servicio: 95%
Mecanismos: bitcoras de operaciones.

Alta Disponibilidad: las funciones de negocios aceptan pequeas

interrupciones y al retomar se reprocesan transacciones.
Disponibilidad: 99%
Mecanismos: bitcoras de operaciones, recuperacin automtica.

Resistencia

fallas

ininterrumpida en

(Fault

horario

requiere

Resilient):

laboral, se

retoma

en

de

operacin

caso

de falla

automticamente.
Disponibilidad: 99.9%
Mecanismos: clustering, mirroring.

Tolerancia a fallas (Fault Tolerance):

capacidad de procesamiento

continuo y cualquier falla debe ser transparente para el usuario.

Disponibilidad: 99.99%
Mecanismos: duplicidad del sitio y redundancia.

Tolerancia a Desastres: disponibilidad en todo momento, capacidad para

soportar desastres naturales y humanos.
Disponibilidad: 99.999%
Mecanismos:

Los

anteriores

ms

dos

sitios

mecanismos

de

recuperacin.
1.3. Tiempo fuera de Servicio
La meta de la alta disponibilidad es cuidar cualquier rompimiento en el
servicio.

Los sistemas

de alta disponibilidad tienen representaciones,

capacidades y empleo de estrategias especialmente diseadas para minimizar

el tiempo fuera de servicio. El Tiempo fuera de servicio puede ser planeado o
no planeado.
4

Figura 1. Causas del tiempo fuera de servicio

Tiempo fuera de servicio

Tiempo fuera de servicio no planeado

Tiempo fuera de servicio planeado

Fallas de computador

Fallas en los datos

Cambios en los datos

Error humano

Corrupcion en los datos

Falla del sitio

Cambios en el sistema

1.3.1. Tiempo fuera de servicio planeado

El tiempo fuera de servicio planeado es el cuando el sistema no est
disponible debido al programa de mantenimiento con actualizaciones de
software / hardware y cuando se hace copias de seguridad del sistema. El
mtodo usado para minimizar el tiempo fuera de servicio planeado debe ser:

Proveer copias de seguridad (backups), mantenimiento, actualizaciones

mientras el sistema est arriba y corriendo.

Reducir el tiempo para desempear esas tareas que pueden ser

nicamente cuando el sistema est bajo.

1.3.2. Tiempo fuera de servicio no planeado

El tiempo fuera de servicio no planeado es el tiempo que el sistema no
est disponible debido a fallas de componentes defectuosos del computador o
defectos del medio ambiente.

Errores humanos y desastres naturales son

ejemplos de defectos del medio ambiente. El mtodo usado para minimizar el

tiempo fuera de servicio no planeado es para:

Minimizar el nmero de defectos y el efecto / recuperacin en el tiempo de

los defectos en un sistema.

Evitar un punto singular de falla por la utilizacin redundante de partes

(failover).

Reducir el impacto de los defectos del medio ambiente usando UPS y

copia idntica de los datos fuera del sitio y/o replicacin en caliente de
componentes omitidos.
Para mencionar el porcentaje de las causas no planeadas que provocan un

paro se debe revisar la grfica que se presenta a continuacin.

Figura 2. Grfica de las causas desconocidas no planeadas

Software bsico 27%
Hardware 23%

8%

7%

Error humano 18%

27%

17%

Problemas en transmisin 17%

Desastre natural 8%

18%

23%

Desconocido 7%

Fuente: Gartner/Dataquest www.enlace.cl/alta_disponibilidad.pdf

La solucin lgica para incrementar la disponibilidad es mantener los

datos en ms de un lugar (recuperacin de desastre), evitar que el usuario
perciba las fallas en el servicio (recuperacin de fallas) y mejorar el tiempo de
respuesta (rendimiento).
El criterio para una la alta disponibilidad y alto desempeo incluye una
solucin:

Mnimo impacto sobre la disponibilidad y desempeo de un sistema

primario.

Una copia completa de la base de datos primaria para reportar y extraer,

que siempre es accesible donde no hay emergencia.

La copia de la base de datos deber ser una imagen de la actualizacin

de la base de datos primaria.

Capacidad para llegar a convertirse en la base de datos primaria (failover)

en caso de desastre.

El failover de la base de datos secundaria deber ser sin prdida de datos.

Despus del desastre, la solucin deber habilitar un cambio de vuelta al

sistema primario.

La copia no requiere administracin de la propia base de datos en adicin

a la administracin del sistema primario.

Redundancia en CPU, componentes de red, fuentes de poder,

almacenamiento de datos, etc.

Ubicacin remota del sistema secundario.

2. ALTA DISPONIBILIDAD DE BASE DE DATOS POR

HARDWARE

2.1. Qu es un Cluster?
Un cluster es un grupo de sistemas independientes que ejecutan una serie
de aplicaciones de forma conjunta y aparecen ante clientes y aplicaciones como
un solo sistema. Las configuraciones del cluster son usadas para disponibilidad
y escalabilidad.
2.1.1. Nodo de cluster
Un nodo de cluster es cualquier sistema que sea miembro de un cluster.
Los tres tipos de nodos de cluster que pueden encontrarse en un domino de
recuperacin son primarios, de reserva y de duplicacin.
2.1.1.1. Nodo primario
Es el nodo de cluster que sirve de punto de acceso y de copia principal de
un recurso. Si se produce una anomala en este nodo, todos los objetos del
grupo de recursos de cluster que tengan a este nodo como punto de acceso
primario conmutarn por anomala a un nodo de reserva.

2.1.1.2. Nodo de reserva

Es el nodo de cluster que asumir el cometido de servir de acceso
primario si el nodo primario actual sufre una anomala. Este nodo de clster
contiene una copia de un recurso de cluster.

En el caso de un grupo de

recursos de cluster de tipo datos, las copias de los datos se mantienen

actualizadas mediante duplicacin.
2.1.1.3. Nodo de duplicacin
Es un nodo de cluster que contiene copias de los recursos de ste, pero
que no puede asumir el cometido de nodo primario o de nodo de reserva.
2.2. Modelos bsicos de cluster
2.2.1. Cluster shared disk
En un cluster shared disk, todos los procesadores tienen acceso directo a
todos los discos y datos, pero ellos no comparten la memoria principal. Se
necesita un software extra, llamado cache distribuido, el cual es requerido para
manejar la concurrencia global de cache entre los procesadores.

10

Figura 3. Cluster shared disk y shared nothing

Fuente: http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/default.mspx

2.2.2. Cluster shared nothing

Cada nodo en un cluster shared nothing es una computadora totalmente
independiente con sus propios recursos y su propio sistema operativo. Cada
nodo tiene su propia memoria y almacenamiento en disco; la comunicacin
entre los nodos es a travs de mensajes entre una interconexin compartida.
2.3. Servidor cluster
Un servidor cluster (Cluster server) es un grupo de servidores
independientes manejados como un solo recurso unificado, esto permite
compartir cargas entre los computadores para obtener un excelente rendimiento
y un muy seguro sistema de alta disponibilidad, pues cuando algn servidor
salga de funcionamiento los otros toman el control y mantienen arriba todos los
servicios para los usuarios.

11

2.4. Cluster por replicacin de datos

Un cluster que utiliza la replicacin de datos es la mejor solucin para
alcanzar los requisitos de disponibilidad continua, proporcionando una
recuperacin rpida para la ms amplia gama de paradas posibles y mxima
flexibilidad de las aplicaciones.

La inversin depende del tamao de los

servidores (nmero de CPU, velocidad de CPU, cantidad de memoria, espacio

en disco, tipo de sistema operativo), va desde un nivel intermedio hasta un nivel
alto de inversin.
2.5. Conmutacin por anomala
Conmutacin

por

anomala

significa

que

el

sistema

conmuta

automticamente a uno o ms de los sistemas de reserva en caso se produzca

una anomala en el sistema.
2.6. Conmutacin por administracin
Una conmutacin por administracin se produce si se conmuta
manualmente el acceso de un sistema a otro sistema. En general, es posible
que se realice esta accin si se lleva a cabo el mantenimiento del sistema, por
ejemplo, en el caso de aplicar arreglos temporales de programa, instalar una
nueva versin o versin de mantenimiento (release) o actualizar el sistema.

12

2.7. Gestin del proceso de grupos de recursos de cluster de datos y de

aplicacin
Si se produce una conmutacin por anomala o una conmutacin por
administracin en un cluster, los grupos de recursos de cluster gestionan todos
los cambios en el dominio de recuperacin. Una conmutacin por anomala o
una conmutacin por administracin puede afectar a grupos de recursos de
cluster de tipo datos y de tipo aplicacin. Se procesan todos los grupos de
recursos de cluster de datos resistentes (tipo 1) antes de que se procese algn
grupo de recursos de cluster de aplicacin (tipo 2). Quiz se desea utilizar un
bloqueo para retener la aplicacin hasta que los datos estn disponibles para su
proceso.
2.8. Ventajas de un cluster
2.8.1. Escalabilidad
La escalabilidad es la capacidad de un equipo para hacer frente a
volmenes de trabajo cada vez mayores sin, por ello, dejar de prestar un nivel
de rendimiento aceptable.
Existen dos tipos de escalabilidad de hardware los cuales se muestran en
la siguiente figura:

Escalabilidad vertical

Escalabilidad horizontal

13

Figura 4. Escalabilidad vertical y escalabilidad horizontal

Fuente: http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/default.mspx

2.8.1.1. Escalabilidad vertical

La escalabilidad vertical se basa en la utilizacin de un gran equipo cuya
capacidad se aumenta a medida que lo exige la carga de trabajo existente, sta
se alcanza en cuanto a la adicin de hardware a un solo nodo, procesadores,
memoria RAM .
2.8.1.2. Escalabilidad horizontal
La escalabilidad horizontal se basa en cambio, en la utilizacin de un
cluster compuesto de varios equipos de mediana potencia que funcionan en
tandem de forma muy parecida a como lo hacen las unidades de un RAID
(Redundant array of independent disks o Arreglo redundante de discos
independientes).

Del mismo modo que se aaden discos a un RAID para

aumentar su capacidad, se pueden aadir nodos a un cluster para aumentar su

rendimiento.

14

2.9. RAID (local)

2.9.1. Introduccin a los sistemas RAID
RAID combina mltiples discos duros en un arreglo, junto con una
controladora, que gestiona la reparticin de datos entre el mencionado arreglo
de discos y almacena la informacin procurando evitar que se pierdan datos si
uno o ms discos llegan a fallar. Esto proporciona una mayor proteccin de los
datos, velocidades ms altas de transferencia y una mayor capacidad que la
que proporcionara un nico disco duro.

El servidor ve al sistema RAID como

si se tratase de cualquier otro disco duro externo. Existen distintos niveles de

redundancia en los arreglos RAID (generalmente se reconocen desde RAID-0
hasta

RAID-5

aunque

existen

proveedores

que

han

especificado

unilateralmente otros niveles, los que definen distintas especificaciones de

almacenamiento.
La mayora de los sistemas operativos de red modernos (Windows Server,
Unix, etc.), tienen capacidad de manejar algunos o todos los niveles antes
mencionados de RAID (sistemas RAID basados en software), pero cuando se
buscan altos niveles de seguridad en la redundancia de la informacin
almacenada, se recurre a sistemas RAID basados en hardware. Adems de ser
ms seguros, las soluciones RAID basadas en hardware son tambin ms
rpidas que las soluciones basadas en software.
2.9.2. Funcionamiento del sistema RAID
El funcionamiento del sistema RAID se sustenta en dos elementos: DATA
STRIPPING y PARIDAD.

15

2.9.2.1. Data stripping

En el data stripping (creacin de bandas), los datos que llegan al RAID
procedentes del servidor, son divididos por la controladoras RAID en segmentos
cuyo tamao depende del bloque que se defina. Posteriormente, esos
segmentos son enviados a los diferentes discos que componen el sistema
RAID.
2.9.2.2. Paridad
Por otro lado, en el concepto de paridad, la controladora RAID genera bits
de paridad y los almacena en los discos del RAID, obteniendo as la
redundancia de datos. De este modo, si un disco falla los datos pueden ser
regenerados.
Los discos optimizados para RAID poseen circuitos integrados que detecta
si el disco est fallando, de ser as este circuito se encargar por encima del
tiempo real de sacar la informacin y almacenarla en los otros discos.
2.9.2.3. Hot spare
Un hot spare es un disco que permanece siempre en el sistema
esperando a que otro se estropee y l entre directamente en funcionamiento.
2.9.2.4. Hot swap
Una de las ventajas del sistema RAID es la posibilidad de conectar y
desconectar los discos en caliente, es decir, que si un disco falla no har falta
apagar el sistema para reemplazarlo.
16

2.9.3. Ventajas
El rendimiento general del sistema aumenta ya que pueden funcionar de
forma paralela con los diferentes discos del conjunto. Dependiendo del nivel de
RAID que se elija, si uno de los discos del conjunto falla, la unidad continua
funcionando, sin prdida del tiempo ni de datos. La reconstruccin de los datos
del disco que ha fallado se hace de forma automtica sin intervencin humana.
En el caso de algunos sistemas operativos la regeneracin de datos se hace
desde el software, aunque en estos sistemas se pueden usar controladoras
RAID que s regeneraran los datos automticamente. La capacidad global del
disco aumentar, ya que se suman las capacidades de los diferentes discos
que componen el conjunto.
Para conseguir mejoras en las prestaciones del RAID, se utiliza memoria
cache de lectura, que contiene datos de forma temporal, minimizando as el
nmero de accesos necesarios. En la memoria cach de escritura se almacena
un determinado nmero de bloques de datos, adyacentes a ser escritos,
disminuyendo de ese modo los accesos a disco. Un sistema de discos RAID es
plenamente multiusuario, ya que todas las solicitudes de los usuarios pueden
ser atendidas simultnemante.
2.9.4. Tipos de implementaciones
Existen dos tipos de implementaciones, segn la controladora, para los
sistemas RAID.

17

2.9.4.1. Hardware RAID

Las controladoras de hardware RAID ofrecen mayores prestaciones y son
independientes del sistema operativo, lo cual evita que se genere cualquier tipo
de conflicto.
2.9.4.2. Software RAID
Por el contrario, si se emplea un software RAID para que realice las
funciones propias del RAID, se consumirn recursos del servidor.

Esto

disminuir su rendimiento. Adems, al trabajar con un software especfico se

depende del sistema operativo, lo cual puede generar conflictos que deriven
incluso en la corrupcin de los datos.
2.9.5. Controladora RAID interna o externa?
Sin duda es mejor utilizar un sistema RAID externo al servidor. Si el RAID
es interno y se produce un fallo, en el propio RAID o en otro componente, se
pierden los datos. En cambio, si el RAID es externo, aunque falle el servidor los
datos seguirn intactos. Luego se conecta el RAID a otro servidor y el trabajo
puede continuar sin perder tiempo.

Adems, solo el RAID externo permite

configuraciones cluster, y al no ser un sistema propietario, se puede conectar a

cualquier servidor, con independencia de su marca, sin que d ningn problema
ni limite a las posibilidades de configuracin.

18

2.9.6. Tipo de cache

2.9.6.1. Write back
Envan al servidor un mensaje de terminacin tan pronto como han escrito
los datos en la cach.

La controladora escribir los datos en disco a su

conveniencia. De esta forma se mejoran, en definitiva, las prestaciones de

escritura.
2.9.6.2. Write through
En este segundo caso, la controladora escribe los datos a disco y
posteriormente manda el mensaje de finalizacin al servidor. Este proceso de
cach resulta ms lento que el anterior.
2.9.7. Tipo de arreglos
2.9.7.1. Arreglos paralelos
Son aquellos en que cada disco participa en todas las operaciones de
entrada o salida. Este tipo de arreglo ofrece tasas altsimas de transferencia
debido a que las operaciones son distribuidas a travs de todos los discos del
arreglo y ocurren en forma prcticamente simultnea. La tasa de transferencia
ser muy cercana, 95%, a la suma de las tasa de los discos miembros, mientras
que los ndices de operaciones de entrada o salida sern similares a las
alcanzadas por un disco individual.

Un arreglo paralelo accesar slo un

archivo a la vez pero lo har a muy alta velocidad. Algunas implementaciones

requieren de actividades adicionales como la sincronizacin de discos. Los
RAID de niveles 2 y 3 se implementan con arreglos paralelos.
19

2.9.7.2. Arreglos independientes

Son denominados as aquellos arreglos en los cuales cada disco
integrante opera en forma independiente, an en el caso de que le sea
solicitado atender varios requerimientos en forma concurrente. Este modelo
ofrece operaciones de entrada o salida sumamente rpidas debido a que cada
disco est en posicin de atender un requerimiento por separado. De esta
forma las operaciones de entrada o salida sern atendidas a una velocidad
cercana, 95%, a la suma de las capacidades de los discos presentes, mientras
que la tasa de transferencia ser similar a la de un disco individual debido a que
cada archivo est almacenado en slo un disco. Los niveles 4 y 5 de RAID se
implementan con arreglos independientes, mientras que los niveles 0 y 1
pueden ser implementados por cualquiera de las categoras de arreglos
independientes. Stripping y mirroring RAID a niveles 0, 1 y 0 & 1 puede ser
implementado, tanto en forma de arreglos independientes o paralelos.
2.9.8. RAID 0
2.9.8.1. Definicin
El RAID de nivel 0 distribuye la informacin en bloques a travs de varios
discos duros, esta tcnica es llamada striping. Maneja varios discos duros como
si fueran uno solo, lo que proporciona una mayor velocidad de lectura y
escritura. ste es el nico nivel que no duplica la informacin, es decir, no
proporciona

redundancia,

por

lo

tanto

almacenamiento.

20

no

desperdicia

capacidad

de

Figura 5. RAID de nivel 0

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.8.2. Requerimientos mnimos

El RAID 0 requiere al menos 2 discos para su implementacin y sus
respectivas tarjetas controladoras.
2.9.8.3. Confiabilidad
Es una buena alternativa en sistemas donde sea ms importante el
rendimiento que la seguridad de los datos, ya que no proporciona tolerancia a
fallos, si un disco falla el sistema se cae, por lo cual es bueno implementarlo en
ambientes que puedan soportar una prdida de tiempo de operacin para
reemplazar el disco que falle y reponer toda la informacin.
2.9.8.4. Rendimiento
El RAID de nivel 0 ofrece muy buen rendimiento permitiendo tener acceso
a ms de un disco a la vez, logrando una tasa de transferencia ms elevada y
un rpido tiempo de acceso.

21

2.9.8.5. Disponibilidad
Este RAID de nivel 0 no proporciona redundancia ya que los datos se
distribuyen a travs de los discos y si un disco falla el sistema se cae, por lo
tanto, este nivel no proporciona alta disponibilidad.
2.9.8.6. Ventajas

Rpida velocidad de lectura y escritura.

Se logra un rendimiento mejorado cuando se distribuyen los datos a travs

de varias controladoras y cada una de ellas con un solo disco.

Se emplea toda la capacidad del disco.

Permite acceder a ms de un disco a la vez, logrando una tasa de

transferencia ms elevada y un rpido tiempo de acceso.
2.9.8.7. Desventajas

Si un disco falla, el sistema cae.

No existe proteccin de datos.

No existe informacin de paridad.

No es verdaderamente un disco RAID ya que no tiene integridad de datos.

22

2.9.9. RAID 1
2.9.9.1. Definicin
El RAID de nivel 1 usa un tipo de configuracin conocido como
espejeado, ya que la informacin de un disco es completamente duplicada en
otro disco (redundancia); proporciona tolerancia a fallas ya que los discos
guardan exactamente la misma informacin por parejas, de tal manera que si
uno falla, el segundo toma su lugar.
Figura 6. RAID de nivel 1

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.9.2. Requerimientos mnimos

El RAID de nivel 1 requiere al menos dos discos para su implementacin,
cada disco con su tarjeta controladora.
2.9.9.3. Confiabilidad
Se protege la informacin en caso de falla tanto del disco como del
controlador.

23

En caso de duplexing que es el agregar un segundo controlador al arreglo

de discos; la ventaja es que con duplexing se elimina que el adaptador sea el
punto de falla; la nica desventaja de duplexing es el costo del segundo
adaptador; ya que si un disco suspende su operacin el otro continua
disponible.

De este modo se evita la prdida de informacin y las

interrupciones del sistema debido a fallas de discos.

2.9.9.4. Rendimiento
El rendimiento de la lectura se mejora ya que cualquiera de los dos discos
puede leerse al mismo tiempo. El rendimiento de escritura es el mismo que el
del almacenamiento en un solo disco. El RAID de nivel 1 proporciona el mejor
rendimiento y la mejor tolerancia a fallos en un sistema multiusuario.

El

rendimiento no se ve afectado cuando un disco falla; el almacenamiento

funciona normalmente hacia los usuarios externos.
2.9.9.5. Disponibilidad
El RAID de nivel 1 proporciona alto nivel de proteccin ya que el
espejeado proporciona el 100% de duplicacin de los datos, est diseado para
sistemas donde la disponibilidad de la informacin es esencial (datos de misin
crtica) y su reemplazo resultara difcil y costoso, ms costoso que reponer el
disco en s.
2.9.9.6. Ventajas

Puede perder un disco y recuperarse (tolerante a fallas).

Es el ms confiable con respecto a guardar la informacin (redundancia).

24

Alto nivel de proteccin ya que el espejeado proporciona el 100% de

duplicacin de los datos.

Entrega el mejor rendimiento de cualquier arreglo redundante durante una

reconstruccin.

No es necesario la reconstruccin de los datos. Si un disco falla, todo lo

requerido es copiar bloque por bloque a un nuevo disco.
2.9.9.7. Desventajas

Debido a que escribe la informacin dos veces, hay un menor rendimiento

comparado con la escritura hacia un solo disco.

Requiere dos discos para un 100% de redundancia, duplicando el costo.

Es lento en la escritura de datos, porque debe escribir en dos

localizaciones si se hace por medio de software.

Cuando se escriben datos deteriorados en un disco, estos son duplicados

con los mismos defectos en el disco espejo.

Se desperdicia el 50% de la capacidad.

2.9.10. RAID 2
2.9.10.1. Definicin
El RAID de nivel 2 adapta la tcnica comnmente usada para detectar y

corregir errores en memorias de estado slido. En un RAID de nivel 2, el cdigo

ECC (Error correction code) se intercala a travs de varios discos a nivel de bit.
El mtodo empleado es el Hamming. Est diseado para ser utilizado con
discos que carecen de deteccin de error interna (discos antiguos). Todos los
discos SCSI soportan deteccin de error interna, por lo que este nivel de RAID
tiene muy poca utilidad prctica para esos modelos de discos.
25

Figura 7. RAID de nivel 2

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.10.2. Confiabilidad
Debido a que el cdigo Hamming se usa tanto para deteccin como para
correccin de errores (Error detection and correction), RAID 2 no hace uso
completo de las amplias capacidades de deteccin de errores contenidas en los
discos. Las propiedades del cdigo Hamming tambin restringen las
configuraciones posibles de matrices para RAID 2, particularmente el clculo de
paridad de los discos. Por lo tanto, RAID 2 no ha sido implementado en
productos comerciales, lo que tambin es debido a que requiere caractersticas
especiales en los discos y no usa discos estndares.
2.9.10.3. Rendimiento
Debido a que es esencialmente una tecnologa de acceso paralelo, RAID
2 est ms indicado para aplicaciones que requieran una alta tasa de
transferencia y menos conveniente para aquellas otras que requieran una alta
tasa de demanda de entrada y salida.

26

2.9.10.4. Disponibilidad
RAID 2 usa mltiples discos dedicados para almacenar informacin de
paridad y por lo tanto requiere que un arreglo contenga un nmero relativo de
discos individuales. Por ejemplo, un RAID 2 con 4 discos de datos requiere tres
discos dedicados a paridad. Consecuentemente, RAID 2 tiene alta redundancia
de cualquier esquema RAID orientado a la paridad.
2.9.10.5. Ventajas

Utiliza cdigos de correccin de Hamming.

Permite altas tasas de transferencia.

2.9.10.6. Desventajas

No puede ser usado con discos SCSI.

RAID 2 no hace uso completo de las amplias capacidades de deteccin de

errores contenidas en los discos.
2.9.11. RAID 3
2.9.11.1. Definicin
El RAID de nivel 3 introduce el chequeo de paridad o la correccin de

errores. Divide el bloque de datos y los distribuye a travs de mltiples discos,

aadiendo redundancia mediante la utilizacin de un disco de paridad dedicado,
que detecta errores en los datos almacenados producidos por una falla de
cualquier disco y los reconstruye mediante algoritmos especiales.

27

Si la falla se produce en el disco de paridad se pierde la redundancia pero

se mantiene intacta la informacin original.
Figura 8. RAID de nivel 3

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.11.2. Requerimientos mnimos

El RAID de nivel 3 requiere mnimo tres discos y se utiliza la capacidad de
un disco para la informacin de control.
2.9.11.3. Confiabilidad
Debido a que RAID de nivel 3 escribe los datos en grandes bloques de
informacin es una alternativa apropiada para aplicaciones tales como video,
que envan y reciben grandes archivos. Este arreglo de discos RAID de nivel 3
son frecuentemente usados en aplicaciones que requieren alto ancho de banda
pero no altas tasas de entrada y salida.

28

2.9.11.4. Rendimiento
El RAID de nivel 3 proporciona alto rendimiento debido a la distribucin de
los datos para transferencias de datos secuenciales; pero en cuanto a
transferencias de datos pequeos su rendimiento es pobre. Las lecturas son
rpidas.

Si embargo, cada escritura requiere que el disco de paridad sea

accesado y escrito conforme los datos son escritos en los dems discos.
2.9.11.5. Disponibilidad
El RAID de nivel 3 proporciona disponibilidad ya que gracias al disco de
paridad se puede reconstruir el disco daado pero si ste falla se pierde la
redundancia.
2.9.11.6. Ventajas

Disco de paridad para correccin de errores.

Se puede perder un disco y recuperarse.

Datos a nivel de bytes.

2.9.11.7. Desventajas

El disco de paridad puede convertirse en un cuello de botella ya que cada

cambio en el grupo RAID requiere un cambio en la informacin de paridad.

No plantea una solucin de fallo simultneo en dos discos.

Es especialmente recomendado para aplicaciones como video, imgenes,

etc., que envan y reciben grandes archivos.

Si se pierde el disco de paridad se pierde la redundancia.

Una falla en un disco reduce el arreglo a RAID 0.

29

2.9.12. RAID 4
2.9.12.1. Definicin
El RAID de nivel 4 distribuye los datos a nivel de bloque (la principal
diferencia con el nivel 3), a travs de varios discos con la paridad almacenada
en un disco. La informacin de paridad permite la recuperacin de cualquier
disco en caso de falla.
Figura 9. RAID de nivel 4

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.12.2. Requerimientos mnimos

Se requiere un mnimo de tres unidades para implementar una solucin
RAID 4.
2.9.12.3. Confiabilidad
Debido a su organizacin interna, este RAID es especialmente indicado
para el almacenamiento de ficheros de gran tamao, esto lo hace ideal para
aplicaciones grficas donde se requiera, adems, fiabilidad de los datos. La
ventaja con el RAID de nivel 4 est en que se puede acceder a los discos de
forma individual.
30

2.9.12.4. Rendimiento
El rendimiento de RAID de nivel 4 es muy bueno para lecturas (similar al
nivel 0). Sin embargo, la escritura requiere que los datos de paridad sean
actualizados cada vez. Esto retarda particularmente las escrituras aleatorias
pequeas, aunque las escrituras grandes o secuenciales son razonablemente
rpidas. Debido a que solamente un disco del arreglo es utilizado para datos
redundantes, el costo por megabyte de un arreglo RAID de nivel 4 es
relativamente bajo.
2.9.12.5. Disponibilidad
Este arreglo RAID de nivel 4 proporciona tolerancia al fallo basndose en
la utilizacin de un disco dedicado a guardar la informacin de paridad
calculada a partir de los datos guardados en los otros discos. En caso de avera
de cualquiera de las unidades de disco, la informacin se puede reconstruir en
tiempo real mediante la realizacin de una operacin lgica de O exclusivo.
2.9.12.6. Ventajas

Rpido en lectura.

Datos a nivel de bloques.

Un disco de paridad.
2.9.12.7. Desventajas

Escritura lenta en pequeos accesos y regular en grandes escrituras.

31

2.9.13. RAID 5
2.9.13.1. Definicin
El RAID de nivel 5 crea datos de paridad, distribuyndolos a travs de los
discos (excepto en aquel disco en que se almacena la informacin original),
obviando la necesidad de un disco de paridad dedicado. El nivel 5 es el ms
completo de todos los niveles de redundancia por distribucin, porque si un
disco falla, la informacin de paridad en los otros permite la reconstruccin de
toda su informacin. An ms, el nivel 5 escribe datos en los discos al nivel de
bloques (en lugar de trabajar al nivel de bytes), volvindolo mas apropiado para
mltiples transacciones pequeas como correo electrnico, procesadores de
palabras, hojas electrnicas y aplicaciones de bases de datos.
Figura 10. RAID de nivel 5

Fuente: http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome.html

2.9.13.2. Requerimientos mnimos

Los requerimientos mnimos para implementar el RAID de nivel 5 son de
al menos 3 discos.

32

2.9.13.3. Confiabilidad
RAID de nivel 5 reduce (pero no elimina) los cuellos de botella que se
formaban en las soluciones RAID de niveles 2 al 4, ya que distribuye la paridad
de los datos en todos los discos fsicos del arreglo, de tal modo que permite
escrituras y lecturas paralelas.

El RAID de nivel 5, es confiable para

aplicaciones intensas de entrada y salida y de lectura y escritura, tal como

procesamiento de transacciones. Es mejor para los sistemas multiusuario en
los cuales el rendimiento no es crtico o que realizan pocas operaciones de
escritura.
2.9.13.4. Rendimiento
El RAID de nivel 5 asegura un mejor rendimiento de operaciones de
entrada o salida para aplicaciones en la que el sistema realiza bsquedas
aleatorias de muchos archivos pequeos como sucede en las aplicaciones
transaccionales. Por otra parte, el rendimiento es muy bajo cuando se hacen
lecturas o escrituras secuenciales de grandes volmenes de informacin.
2.9.13.5. Disponibilidad
El nivel 5 proporciona disponibilidad debido a la redundancia por
distribucin, porque si un disco falla, la informacin de paridad en los otros
permite la reconstruccin de toda su informacin.
2.9.13.6. Ventajas

Distribuye la paridad en todos los discos.

Apropiado para aplicaciones transaccionales.

33

Es tolerante a fallos.
2.9.13.7. Desventajas

No plantea una solucin al fallo simultneo en dos discos.

No aumenta el rendimiento en las aplicaciones, aunque la velocidad de

transferencias de datos es alta.
2.9.14. RAID 0 + 1
2.9.14.1. Definicin
Es un nivel de arreglo de discos, donde la informacin se distribuye en

bloques como en RAID de nivel 0, adicionalmente cada disco se duplica como

RAID de nivel 1, creando un segundo nivel de arreglo.

Se conoce como

"striping de arreglos duplicados". Se requieren, dos canales, dos discos para

cada canal y se utiliza el 50% de la capacidad para informacin de control.
Figura 11. RAID de nivel 0 + 1

Fuente: http://linux.cudeso.be/raid.php

34

2.9.14.2. Requerimientos mnimos

Los requerimientos mnimos para implementar el RAID 0 + 1 son de un
mnimo de 4 discos para su implementacin y slo dos de ellos se utilizan para
el almacenamiento de datos.
2.9.14.3. Confiabilidad
El RAID de nivel 0 + 1 aplica para sistemas de misin crtica donde se
requiera mayor confiabilidad de la informacin, ya que pueden fallar dos discos
inclusive (uno por cada canal) y los datos todava se mantienen en lnea. Es
apropiado tambin en escrituras aleatorias pequeas.
2.9.14.4. Rendimiento
El RAID de nivel 0 + 1 provee las mismas caractersticas de rendimiento
del nivel 0 mientras proporciona la redundancia de un arreglo mirrored; sin
embargo, porque cada miembro es duplicado el costo por megabyte de un
RAID de nivel 0 + 1 es extremadamente alto.
2.9.14.5. Disponibilidad
Este nivel ofrece un 100% de redundancia de la informacin y un soporte
para grandes volmenes de datos.
2.9.14.6. Ventajas

100% de redundancia de la informacin.

Soporta grandes volmenes de datos.

35

2.9.14.7. Desventajas

Costo elevado.

Menor capacidad de transferencia que otros.

2.9.15. RAID 53
2.9.15.1. Definicin
Es el nivel de arreglo de discos ms reciente, es implementado como un

arreglo striped de nivel 0, en el cual cada segmento es un arreglo RAID de nivel

3. ste tiene la misma redundancia y tolerancia a fallos que RAID 3. Podra ser
usado para sistemas que necesitan una configuracin RAID 3 con alta tasa de
transferencia de datos, pero es caro e ineficiente.
Figura 12. RAID 53

Fuente: http://linux.cudeso.be/raid.php

2.9.15.2. Requerimientos mnimos

Los requerimientos mnimos para implementar el RAID 53 son de 5
discos.

36

2.9.15.3. Confiabilidad
La confiabilidad es bastante alta debido a que puede sobrevivir a una sola
falla en cada arreglo RAID 3.
2.9.15.4. Rendimiento
Su rendimiento es bastante alto en cuanto a lecturas y escrituras se
refiere.
2.9.15.5. Ventajas

Posee la misma tolerancia a fallos que el RAID 3.

Alta tasa de transferencia de datos gracias a los segmentos del arreglo de

RAID 3.
2.9.15.6. Desventajas

Demasiado caro para implementar.

No est disponible en el mercado. Su costo es bajo respecto a RAID 0 + 1,

pero sigue siendo caro respecto a RAID 3 5.

37

2.10.Opciones

de

almacenamiento

para

arquitecturas

de

alta

disponibilidad
2.10.1. Storage Area Network (SAN)
2.10.1.1. Definicin
SAN es una infraestructura de red diseada para proveer un entorno de
flexibilidad, alto rendimiento y alta escalabilidad. SAN logra esto habilitando
varias

conexiones

almacenamiento

directas

tales

como

entre

el

libreras

servidor
y

sistemas

los

dispositivos

RAID,

de

de

manera

independiente de la LAN pero coexistiendo con ella. Este arreglo hace posible
que el almacenamiento sea accesible a todos los servidores en la red
permitiendo que la informacin se consolide y sea compartida entre diversos y
diferentes servidores de red sin ningn impacto en la LAN (red de rea local).
Ya que la informacin no reside directamente en ninguno de los servidores, los
recursos de estos pueden ser utilizados para otros propsitos incrementado la
capacidad y el rendimiento de la red. Adems la escalabilidad de toda la SAN
puede ser mantenida dentro de cualquiera de los recursos individuales: a
medida que se agregan dispositivos adicionales a la SAN, estos son accesibles
desde cualquier servidor en la red.
Una SAN, adems, hace que la informacin est disponible para los
usuarios, proporcionando un ambiente seguro para toda aquella informacin
sensitiva, simplificando la administracin y reduciendo costos generales de
operacin y mantenimiento.

38

SAN emplea interconexiones de alto rendimiento como la tecnologa del

canal de fibra (FC), permitiendo de una manera innovadora proteger y distribuir
datos importantes.

FC proporciona enlaces de hasta 120 Km de distancia

permitiendo que las conexiones parezcan locales a la aplicacin.

La

redundancia de conexin en SAN protege contra desastres locales.

Es confiable en las aplicaciones de bases de datos de misin crtica, en
las cuales el tiempo de respuesta, la disponibilidad y escalabilidad del
almacenamiento son esenciales.
Figura 13. Topologa tpica SAN

Fuente: www.infrastor.com/downloads/papaers/sanvsnas.pdf

2.10.1.2. Rendimiento
SAN mejora el rendimiento ayudando a las redes de rea local
congestionadas por el alto trfico de volumen de datos que son generados por
copias de seguridad, grandes migraciones de datos, aplicaciones de audio y
video.
39

El tiempo de respuesta del almacenamiento es rpido por los enlaces del

canal de fibra ya que estos pueden transferir los datos a 100 MBps. En el
futuro, el ancho de banda del canal de fibra se duplicar a 200 MBps,
mantenindose delante de los avances de SCSI.
2.10.1.3. Disponibilidad
Los recursos de un servidor y del almacenamiento pueden ser agregados
en lnea sin interrumpir el acceso a los datos. En adicin, SAN reduce los
costos de hardware de la alta disponibilidad, hacindolo aceptable para ms
aplicaciones.

En una arquitectura SAN, todos los servidores pueden tener

acceso directo al almacenamiento.

Esto significa que un servidor puede

proveer proteccin contra fallos para docenas de otros servidores ms de lo que

es posible en un cluster tradicional de discos compartidos. Para recuperacin
de desastre y backup, los sitios con copias idnticas pueden ser localizados a
una distancia segura uno de cada otro, hasta 10 kilmetros usando cableado de
fibra ptica.
2.10.1.4. Crecimiento
SAN ofrece excelente escalabilidad, agregando almacenamiento sin tener
tiempo fuera de servicio (downtime) y ruptura asociada con las actualizaciones
del servidor.
2.10.1.5. Ventajas

Alta disponibilidad.

Confiabilidad en la transferencia de datos.

Reduce el trafico en la red primaria.

40

Flexibilidad de configuracin.

Alto rendimiento.

Alta escalabilidad.

Administracin centralizada.
2.10.1.6. Desventajas

Costo.
2.10.2. Network Attached Storage (NAS)
2.10.2.1. Definicin
NAS es un sistema de almacenamiento orientado al servicio de archivos a

travs de una red de rea local. Se basa en file servers con tecnologa y
sistemas operativos especficamente desarrollados para este propsito. Son
equipos de bajo costo relativo, capaces de operar sobre redes de distinta
naturaleza, multiplataformas y altamente eficientes. Los dispositivos NAS
proporcionan servicios puros y dedicados al almacenamiento y file sharing
adems de proporcionar caractersticas avanzadas de seguridad tales como
polticas de acceso, RAID y alimentacin redundante para aumentar su
confiabilidad y prestaciones.

41

Figura 14. Topologa tpica NAS

Fuente: www.infrastor.com/downloads/papaers/sanvsnas.pdf

2.10.2.2. Rendimiento
NAS es ms lento que SAN, pero ms rpido que el almacenamiento
adjunto al servidor.

NAS mejora el rendimiento descargando el servicio de

archivo proporcionado por el host, liberando de esta manera los ciclos de CPU
para otras tareas. Actualizar NAS a Ethernet Gigabit hace que sea incluso una
solucin atractiva, aunque enormes cantidades de datos pueden estar sobre la
red.
2.10.2.3. Disponibilidad
NAS habilita copias de seguridad rpidas, minimizando la interrupcin
para acceder a los datos.

Algunos aparatos NAS presentan funciones de

replicacin de datos para una rpida recuperacin.

La simplicidad de los

aparatos los hacen ms confiables que los tradicionales servidores de archivos

LAN.

Y el acercamiento del aparato elimina muchas fallas inducidas por

sistemas operativos y hardware complejo. En adicin los aparatos NAS pueden

ser configurados para failover.
42

Carecen del rango de supervivencia y prestaciones que a menudo se

requiere en una red corporativa. La capacidad RAID incorporada proporciona un
cierto grado de proteccin.
2.10.2.4. Crecimiento
Agregar ms capacidad de almacenamiento a una red simplemente se
traduce en agregar y conectar ms unidades NAS a ella. NAS es una eficiente
forma para las redes corporativas de agregar capacidad de almacenamiento y
liberar efectivamente a los servidores de las tareas que implican el compartir
archivos.
Con NAS, la capacidad de almacenamiento no est amarrada a la
capacidad del servidor.

Las empresas agregan almacenamiento segn sea

necesario para la misma. Los productos NAS pueden escalar hasta mltiples
terabytes y al descargar el servicio de archivos hacia esos dispositivos,
entonces los servidores pueden soportar ms usuarios.
2.10.2.5. Ventajas

Pocas limitaciones en cuanto a distancia.

Sistema especfico orientado al servicio de archivos por lo tanto ms

eficiente, ms confiable y disminuye los puntos de falla.

Acceso a archivos sobre ambiente de red, no depende de un servidor.

Acceso a archivos desde clientes multiplataformas.

Fcil administracin e instalacin.

No requiere licencias (multiusuario).

Optimizacin del almacenamiento y el compartir archivos heterogneos.

43

2.10.2.6. Desventajas

Genera mucho trfico de red en entornos que tienen mucha demanda de

archivos.

44

3. ALTA DISPONIBILIDAD DE BASE DE DATOS POR

SOFTWARE

3.1. Replicacin
3.1.1. Definicin
La replicacin es el proceso de mantener copias de datos en produccin
que pueden ser usadas como sitios alternativos de datos en produccin sobre
otros sistemas. Esas copias son usadas si el sistema de produccin necesita
estar fuera de lnea para backups o rutinas de mantenimiento (alta
disponibilidad), o en casos de una emergencia cuando el sistema de produccin
haya fallado (recuperacin de desastres). La replicacin hace posible disminuir
el trfico de red y permite la tolerancia a fallos.
Esos sitios de datos alternativos pueden ser usados cada da en modo
nicamente de lectura sin comprometer la viabilidad de los datos como una
representacin exacta de la produccin de estos. Consecuentemente, ellos
pueden servir para un propsito de consultar informacin y procesar reportes
sin cargar el sistema principal de produccin, lo cual ayuda en gran parte a
mejorar el desempeo del proceso de transacciones en lnea (OLTP) sobre el
sistema de produccin.

Este concepto se ha venido desarrollando por los

proveedores de sistemas administradores de bases de datos relacionales y por

otras organizaciones.

45

Un simple backup restaurado sobre un sistema alternativo puede ser

considerado una forma de replicacin; sin embargo, este tipo de backup tiene
las mismas limitaciones como las asociadas con las instantneas (snapshots) o
exportar / importar, ya que ellos son copias estticas de los datos de produccin
en un punto especfico en el tiempo, dndole antigedad conforme envejece.
Otras tecnologas de replicacin pueden actualizar una copia de los datos
replicados, pero nicamente sin ser accesada.
3.1.2. Ventajas
La replicacin introduce una serie de ventajas que son:

Distribuir la carga de trabajo en mltiples servidores.

Mejorar la disponibilidad de datos.

Mover subconjuntos de datos de la base de datos central a otras bases de

datos.

Optimizar las transacciones al separar los sistemas transaccionales de los

sistemas de decisin.

Reducir el trfico de red y dar soporte optimizado para cambios de los

modelos organizacionales.
3.1.3. Tipos de Replicacin
Hay diversas formas de clasificar los tipos de replicacin, aqu se

mencionan dos de ellas, una basada en el sentido de viaje de los datos y otra
por la oportunidad de la replicacin.
Los tipos de replicacin segn el sentido del viaje de los datos son:

46

3.1.3.1. Unidireccional
Se tiene un nodo actualizable y otro que contiene una copia del principal
pero es solo de lectura, tal como se muestra en la figura.
Figura 15. Replicacin unidireccional

Fuente: http://www.pucp.edu.pe

3.1.3.2. Bidireccional
Se tienen nodos actualizando los datos, de tal forma que la replicacin se
produce en ambas direcciones, tal como se muestra en la figura.
Figura 16. Replicacin bidireccional

Fuente: http://www.pucp.edu.pe

Los tipos de replicacin segn la oportunidad de replicacin son:

47

3.1.3.3. Sncrona
Inmediatamente despus que una aplicacin actualiza una tabla local o
rplica, la misma transaccin actualiza las otras tablas en los otros nodos.
3.1.3.4. Asncrona
Cuando se produce una actualizacin se guarda la informacin en una
cola y luego se enva la informacin modificada a otro nodo del sistema de
replicacin despus de cierto tiempo.
Los fabricantes de motores de bases de datos que implementan
replicacin introducen conceptos de acuerdo a sus beneficios, pero en general
las clasificaciones que ellos proponen estn dentro de la clasificacin antes
mencionada.
3.1.4. El porqu de la replicacin
Con la replicacin, se est maximizando el retorno sobre la inversin
haciendo trabajar el sistema secundario, pues es continuamente actualizado, es
una copia actualizada de la base de datos de produccin que permite ser usada
para reportes, consultas, extracciones y backups. Removiendo estos procesos,
que normalmente compiten por recursos sobre el sistema origen o en
produccin, mejorando el desempeo de la instancia de produccin mientras
permite optimizarse la instancia secundaria para propsito de consultas.

48

3.1.5. Replicacin basada en logs

La principal funcin de los redo log files en una base de datos Oracle es
almacenar los cambios hechos a los datos. Oracle se protege contra fallas en
los mismos redo log manteniendo dos o ms copias de los redo log en discos
separados. Por ello es que la informacin en un redo log file es usada para
recuperar la base de datos en el caso de una falla.
La replicacin basada en logs captura toda modificacin a los objetos
seleccionados inmediatamente en la base de datos origen y tan pronto como
ellos son escritos al redo log file de Oracle, estos son replicados hacia la base
de datos destino para aplicarlos.
3.1.6. Replicacin usando disparadores
Los

disparadores

de

bases

de

datos

son

procedimientos

que

implcitamente se ejecutan o disparan cuando se realiza una insercin, una

actualizacin o una eliminacin en una tabla a la cual est asociado. Es decir,
el procedimiento se ejecuta automticamente cuando se realiza una operacin
en la tabla.
Un disparador est compuesto de tres partes bsicas:

El evento que dispara el procedimiento: el cual es una instruccin de la

base de datos que hace que se ejecute el cdigo del disparador.

El

evento puede ser insertar datos a la tabla, actualizarlos o eliminarlos.

La restriccin del disparador: es una condicin lgica que debe ser

verdadera para que el disparador se ejecute. En la restriccin se puede
hacer referencia a cualquier valor de fila que se est modificando en la
accin del disparador.
49

El cuerpo del disparador: consiste en el cdigo que se debe ejecutar

cuando el evento se realiza. Este cdigo incluye cualquier instruccin del
lenguaje de manipulacin de datos.
Cuando el evento ocurre el primer paso es evaluar la restriccin del

disparador, si el resultado es verdadero entonces se ejecuta el cdigo como

cualquier procedimiento normal.
Los disparadores pueden ser utilizados para implementar replicacin
sncrona de dos o ms tablas en diferentes localidades. La implementacin de
replicacin utilizando disparadores debe tener las siguientes caractersticas:

Cada copia puede ser consultada y actualizada y todas las actualizaciones

son propagadas inmediatamente a todas las localidades donde se tengan
copias.

Si esto es un requerimiento necesario se debe realizar la

replicacin utilizando disparadores.

Actualizaciones remotas realizadas por los disparadores son parte de la

transaccin que ejecut el disparador por lo que la instruccin commit
(es una instruccin de sistemas de bases de datos transaccionales que
significa cometido o realizado) es realizada como parte de la transaccin
local utilizando el proceso normal de commit de dos fases.

Si los disparadores estn deshabilitados, la operaciones de replicacin no

son realizadas lo que provoca que una o ms tablas no estn
sincronizadas.

Si existen fallas en la red las localidades que contienen rplicas no sern

actualizadas.

50

3.1.7. Replicacin instantnea (Snapshot)

Una instantnea es una copia completa o subconjunto de los datos de una
tabla que refleja el estado actual de esa tabla. Una instantnea es definida en
funcin de una consulta distribuida que recupera los datos y actualiza la
instantnea.
A la tabla de la cual se hace la copia se le llama tabla maestra y a la
localidad que contiene la tabla se le llama localidad maestra.
La instantnea es actualizada en forma peridica y el periodo de tiempo
en que se debe actualizar es definido al crear la instantnea.
3.1.7.1. Instantneas simples e instantneas complejas
Una instantnea simple consiste en una copia exactamente igual a la tabla
maestra, es decir que cada fila de la instantnea es igual a cada fila en la tabla
maestra. Para cumplir con esta definicin al crear la instantnea simple la
consulta no puede tener agrupaciones, uniones de varias tablas, operadores de
conjuntos o subconsultas. Si la consulta de la instancia tiene cualquiera de
estas instrucciones entonces se le llama una instantnea compleja.

51

3.2. Solucin Oracle Data Guard

3.2.1. Definicin
Oracle Data Guard es el software para la administracin y monitoreo que
trabaja con una base de datos de produccin y una o ms bases de datos
standby para proteger los datos contra fallas, errores y corrupcin que pueda
destruir la base de datos.
Una base de datos standby es una rplica de la base de datos creada de
un backup de una base de datos primaria. Aplicando archived redo logs de la
base de datos primaria hacia la o las bases de datos standby, se logra
mantener dos bases de datos sincronizadas.
Una base de datos standby tiene los siguientes propsitos:

Proteccin contra desastre.

Proteccin contra corrupcin en los datos.

Abrir la base de datos en modo de solo lectura. Reportes suplementarios.

Si la base de datos es destruida completamente o si los datos comienzan

a corromperse, entonces se puede implementar un failover hacia la base de

datos standby, en este caso la base de datos standby comienza a ser la nueva
base de datos primaria. Esta base de datos tambin puede abrirse con la
opcin de solo lectura, por lo consiguiente funciona como una base
independiente para propsitos de reportes.
En la versin de Oracle 8i esta solucin se conoca como Oracle Standby
pero en Oracle 9i fue renombrada como Data Guard.
52

3.2.2. Restricciones
Dentro de una base de datos standby se puede encontrar ciertas
restricciones en cuanto a su configuracin se refiere:

Una configuracin Data Guard debe usar la misma edicin de la base de

datos de Oracle Enterprise Edition y sta debe instalarse sobre todos los
sistemas.

La base de datos primaria debe correr en modo ARCHIVELOG.

La misma versin del software Oracle debe ser usada sobre ambas, la
base primaria y las bases standby. El sistema operativo que corre sobre
la base primaria y

standby debe ser el mismo, pero en el sistema

operativo no se necesita que sea la misma versin. En adicin, la base de

datos standby puede usar una estructura de directorio diferente al de la
base de datos primaria.

La arquitectura de hardware y sistema operativo sobre la localidad

primaria y standby debe ser la misma. Por ejemplo, esto significa que una
configuracin Data Guard con una base

de datos primaria sobre un

sistema Sun de 32 bit debe tener una base de datos standby con un
sistema Sun de 32 bit.

Cada base de datos primaria y standby deben tener su propio control file.

Si actualmente corre Oracle Data Guard sobre el software de base de

datos Oracle 8i, se debe actualizar a Oracle 9i Data Guard.
53

Las cuentas de usuario para administrar las instancias de bases de datos

tanto primaria como standby debern tener privilegios de sistema
SYSDBA.

Se debe usar la misma versin, release, y parche (patch) de ORACLE

RDBMS para las bases de datos primaria y standby para que las
operaciones de failover no estn comprometidas.

En Oracle Data Guard se puede tener hasta nueve bases de datos

standby.

En versiones de Oracle para Windows NT previas a Oracle8 release 8.0.4

soportan nicamente un Oracle home. Se puede instalar productos
Oracle7 release 7.x y Oracle8 release 8.x en el mismo Oracle home. Sin
embargo, no se puede instalar mltiples releases con un tercer dgito del
mismo producto. Por ejemplo, no se puede instalar productos Oracle7
release 7.3.2 y Oracle7 release 7.3.3 en la misma computadora, ya que
una instalacin escribe sobre la previa.

En versiones Oracle8 releases 8.0.4 a 8.0.6, se puede instalar una o ms

releases de Oracle en mltiples Oracle homes. Se puede instalar Oracle8
release 8.0.x y Oracle8i release 8.1.3 o bien Oracle7 release 7.x y Oracle8
release 8.0.x en diferentes Oracle homes en la misma computadora.
Tambin se puede instalar diferentes releases de Oracle en el mismo
Oracle home que tengan diferente el primer o segundo dgito del nmero
de release. Por ejemplo, instalar Oracle7 release 7.2 y Oracle8 release
8.0.x en el mismo Oracle home.

54

Para instalar Oracle8i release 8.1.3 a Oracle9i release 2 (9.2) tienen la

misma funcionalidad que el inciso anterior pero contienen las siguientes
restricciones:
o No se puede instalar cualquier release de Oracle8i release 8.1.3 a
Oracle9i release 2 (9.2) en un Oracle home que fue creado con el
instalador antiguo llamado Oracle Installer y fue usado para
instalaciones previas a Oracle8i release 8.1.3; el nuevo instalador
es llamado Oracle Universal Installer y est basado en Java.
o Los releases Oracle 8i release 8.1.3 a Oracle9i release 2 (9.2)
deben ser instalados en Oracle homes separados. No se puede
tener mas de un release instalado en cada Oracle home.
3.2.3. Requerimientos mnimos
El software que se necesita para instalar Oracle Data Guard sobre cada

servidor (primario y standby) es el siguiente:

Tabla II. Requerimientos mnimos de sistema operativo para la solucin
Oracle Data Guard
Plataforma
Basada en
Windows

Sistema Operativo
Windows NT 4.0

Service pack 5

Basada en

Windows 2000 (Server, Advanced

Windows

Server, DataCenter)

Parche requerido

Service pack 1

Licencia de Windows 2000 (Server, Advanced Server, Datacenter) con

service pack 1 o mayor.

55

TCP/IP o TCP/IP con SSL

Licencia por procesador o nmero de usuarios de Oracle 8/8i/9i Enterprise

Edition sobre cada servidor de base de datos.

Hay que tener en cuenta que siempre se debe tener los ltimos parches.

Idealmente, ambos servidores deben ser idnticos en hardware, drivers o

controladores, software, y configuracin. La igualdad fsica de un servidor
a otro, evitar que se tenga mayores problemas.

Netscape Navigator 4.76 o mayor.

Microsoft Internet Explorer 5.0 o mayor.

Para instalar la base de datos Oracle 9i bajo plataformas intel o

compatible, se necesita el hardware que se muestra en la siguiente tabla.

Tabla III. Requerimientos mnimos de hardware para la solucin Oracle
Data Guard sobre plataforma basada en Windows
Hardware

Requerimientos

Procesador

Pentium 266 o mayor (para Oracle 9i Enterprise Edition)

Memoria

RAM: 128 MB (recomendado 256 MB)

Memoria virtual: el doble de la memoria fsica

Espacio
duro

en

disco Drive del sistema 140 MB,

Oracle home drive (NTFS) 2.85 GB para Enterprise
Edition

56

Para instalar la base de datos Oracle 9i bajo sistemas Unix, se necesita

hardware que se muestra en la siguiente tabla.
Tabla IV. Requerimientos mnimos de hardware para la solucin Oracle
Data Guard sobre plataforma basada en Unix
Hardware

Requerimientos

Memoria

Un mnimo de 512 MB de RAM

Swap Space

Un mnimo del doble de RAM, o 400 MB, cualquiera de

los dos

Espacio en disco duro

4.5 GB

Una consideracin muy importante es cuando se selecciona el hardware

del servidor puesto que ste debe ser certificado en la lista de
compatibilidad de Oracle.
3.2.4. Funcionamiento
En Oracle Data Guard se introducen nuevos conceptos como son los

siguientes:
Base de datos primaria es una base de datos en produccin. sta es
usada para crear una base de datos standby. Cada base de datos standby es
asociada solamente con una base de datos primaria.
Base de datos Standby, puede ser una base de datos fsica o lgica, es
creada de una rplica de un backup de una base de datos primaria.
Una base de datos standby fsica es fsicamente idntica a la base de
datos primaria bloque por bloque.
57

Esto es actualizado mediante la realizacin de recuperacin de los redo

logs que son generados en la base de datos primaria.
Data Guard mantiene una base de datos standby fsica realizando
operaciones de recuperacin administrada. Cuando no se est realizando una
operacin de recuperacin, una base de datos standby fsica puede ser abierta
para operaciones de solo lectura.
La recuperacin administrada de una base de datos standby es mantenida
aplicando los archived redo logs sobre el sistema standby usando el mecanismo
de recuperacin de Oracle. La operacin de recuperacin aplica los cambios
bloque por bloque usando el row ID fsico. La base de datos no puede ser
abierta para operaciones de lectura o escritura mientras los redo data estn
siendo aplicados.
La base de datos standby fsica puede ser abierta para operaciones de
solo lectura en que se puedan ejecutar consultas sobre la base de datos.
Mientras est abierta para operaciones de solo lectura,

la base de datos

standby puede continuar recibiendo los redo logs pero la aplicacin de los datos
de los logs es en diferido mientras la base de datos cambia a operaciones de
recuperacin administrada.

58

Aunque la base de datos standby no puede realizar ambas operaciones al

mismo tiempo, se puede cambiar entre ellas. Por ejemplo, se puede usar una
base de datos standby fsica para realizar operaciones de recuperacin
administrada, entonces sta puede ser abierta para que las aplicaciones
puedan realizar operaciones de solo lectura para correr reportes y luego
cambiarla nuevamente a operaciones de recuperacin administrada para aplicar
los archived redo logs. Se puede repetir este ciclo alternando entre ellos segn
sea necesario.
En otro caso, si la base de datos standby fsica est disponible para
realizar operaciones de backup. Puede continuar recibiendo los redo logs
incluso si ellos no estn siendo aplicados en ese momento.
Una base de datos standby lgica contiene la misma informacin lgica
que la base de datos de produccin, aunque la organizacin fsica y la
estructura de los datos puede ser diferente. Esto se mantiene sincronizado con
la base de datos primaria transformando los datos recibidos en los redo logs de
esta base dentro de declaraciones SQL, las cuales son ejecutadas en la base
de datos standby. Esta base de datos standby lgica puede ser usada para
propsitos de negocios en adicin a requerimientos de recuperacin de
desastres.

Esto permite a los usuarios accesar a la base de datos standby

lgica para propsitos de consultas y reportes en cualquier momento. As, una

base de datos standby lgica puede ser usada concurrentemente para
proteccin de datos y reportes.
A continuacin se muestra la figura de una configuracin Data Guard que
contiene una instancia de la base de datos primaria que transmite los redo data
hacia las bases de datos standby fsica y lgica y ambas se encuentran en
localidades remotas de la instancia de la base de datos primaria.
59

En esta configuracin, una base de datos standby fsica es configurada

para operaciones de recuperacin de desastres y operaciones de backup, y una
base de datos standby lgica es configurada primariamente para propsitos de
reportes, pero sta tambin puede ser usada para recuperacin de desastres.
Figura 17. Configuracin tpica de la solucin Oracle Data Guard y los
servicios de transporte y aplicacin de los redo logs

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96524.pdf

Data Guard utiliza servicios para administrar la transmisin de los redo

data, la aplicacin de los redo logs y los cambios de role de la base de datos
Log transport services
Este servicio controla la trasferencia automtica de los redo data dentro de
una configuracin Data Guard, y realiza las siguientes tareas:

60

Transmitir los redo data del sistema primario a los sistemas standby en la
configuracin.

Hacer cumplir los modos de proteccin de la base de datos.

Log apply services

Los redo data transmitidos de la base de datos primaria son archivados
sobre el sistema standby en la forma de archived redo logs. Este servicio
automticamente aplica los archived redo logs sobre la base de datos standby
para mantener sincronizacin transaccional con la base de datos primaria y
permitir acceso a los datos nicamente de lectura consistentemente
transaccionales.
La principal diferencia entre las bases de datos standby fsica y lgica es
la manera cmo el servicio Log Apply aplica los archived redo logs:

Para una base de datos standby fsica, Data Guard usa tecnologa redo
apply, la cual aplica los redo data sobre la base de datos standby usando
tcnicas de recuperacin estndar del servidor de base de datos Oracle.

Para una base de datos standby lgica, Data Guard usa tecnologa SQL
apply, la cual primero transforma los redo data recibidos dentro de
declaraciones SQL y entonces se ejecutan las declaraciones SQL
generadas sobre la base de datos standby lgica.
El servicio Log apply realiza las siguientes tareas:

Aplicacin automtica de los archived redo logs sobre la base de datos

standby.

61

Deteccin automtica del extravo de los redo logs sobre un sistema

standby y automticamente recupera de los redo logs extraviados de la
base de datos primaria u otra base de datos standby.

Servicios de administracin de roles

Una base de datos Oracle opera en uno de dos roles: primario o standby.
Usando Data Guard, se puede cambiar el rol de una base de datos usando una
operacin de switchover o failover. Los servicios que controlan esos aspectos
son llamados servicios de administracin de roles.
Un Switchover es un rol cambiante entre la base de datos primaria y una
de sus bases de datos standby.

Una operacin de switchover garantiza

ninguna prdida de datos. Esto es usado para propsitos de mantenimiento

planeado sobre el sistema primario. Durante un switchover, la transicin de la
base de datos primaria a el rol de standby y la transicin de la base de datos
standby para el rol primario ocurren sin tener que recrear la base de datos.
Un failover es una transicin irreversible de una base de datos standby
hacia el rol primario. Esto es nicamente aplicado en el evento de una falla
catastrfica de la base de datos primaria. El administrador de la base de datos
puede configurar Data Guard para asegurar ninguna prdida de datos.
El Data Guard broker es un marco de trabajo distribuido que automatiza y
centraliza la creacin, mantenimiento y monitoreo de las configuraciones de
Data Guard. La siguiente lista describe algunas de las operaciones que el Data
Guard broker automatiza o simplifica:

62

Crea y habilita una o ms configuraciones Data Guard, incluyendo

configuracin de los servicios de transporte de log y de aplicacin de log.

Crea una base de datos standby fsica o lgica de una copia de seguridad
de la base de datos primaria.

Agrega nuevas bases de datos standby o existentes a una configuracin

Data Guard.

Administra una configuracin Data Guard completa de cualquier sistema

en la configuracin.

Monitorea las tasas de aplicacin de logs, capturando informacin de

diagnstico y detectando rpidamente problemas con el monitoreo
centralizado.

Modos de proteccin de Data Guard

En algunas situaciones, los negocios no pueden afrontar la prdida de
datos a ningn costo. En otras situaciones, la disponibilidad de la base de
datos quiz sea ms importante que la prdida de datos. Algunas aplicaciones
requieren mximo rendimiento de la base de datos y poder tolerar una potencial
prdida de datos. Data Guard proporciona tres modos distintos de proteccin:
El modo de mxima proteccin ofrece el ms alto nivel de proteccin de
los datos. Estos son transmitidos de una forma sincronizada de la base de
datos primaria a la base de datos standby, y las transacciones no son
comprometidas sobre la base de datos primaria a no ser que los redo data
estn disponibles en al menos una base de datos standby configurada en este
modo. Si la ultima configuracin de la base de datos standby no est disponible,
el proceso se detiene en la base de datos primaria.
ninguna prdida de datos.

63

Este modo garantiza

El modo de mxima disponibilidad es similar al modo de mxima

proteccin, incluyendo la garanta de ninguna prdida de datos. Sin embargo, si
una base de datos standby llega a ser no disponible (por ejemplo, debido a
problemas de conexin de la red), el proceso continua sobre la base de datos
primaria. Cuando la falla es corregida, la base de datos standby es
resincronizada con la base de datos primaria. Si hay necesidad de un failover
antes de la resincronizacin con la base de datos standby, algunos datos se
pueden perder.
El modo de mximo rendimiento ofrece ligeramente menos proteccin a
los datos en la base de datos primaria, pero alto rendimiento respecto del modo
de mxima disponibilidad. En este modo, las transacciones procesadas en la
base de datos primaria, los redo data son enviados asincrnicamente hacia la
base de datos standby. La operacin de commit en la base de datos primaria
no espera para que la base de datos standby reciba reconocimiento de que han
sido recibidos los redo data antes de completar las operaciones de escritura
sobre la base de datos primaria.

Si cualquier destino standby llega a ser no

disponible, el proceso continua en la base de datos primaria y hay un pequeo

efecto sobre su rendimiento.
3.2.5. Confiabilidad
Una base de datos standby es confiable debido a que es una rplica de la
base de datos creada de un backup o base de datos primaria. Esta confiabilidad
se logra aplicando archived redo logs de la base de datos primaria hacia la base
de datos standby, con ello se puede mantener las dos bases de datos
sincronizadas.

64

Si una base de datos primaria es destruida o bien los datos se corrompen,

se puede hacer un failover hacia la base de datos standby, en este caso la base
de datos standby llega a ser la nueva base de datos primaria. De igual manera,
se puede abrir una base de datos standby con la opcin de solo lectura, lo cual
permite que sta funcione como una base de datos independiente para
propsitos de reportes.
3.2.6. Rendimiento
El rendimiento se ve beneficiado al usar la tecnologa de redo apply la cual
es usada por la base de datos standby fsica que aplica los cambios usando
mecanismos de recuperacin de bajo nivel, lo cual es una va de paso para todo
a nivel de cdigo SQL y de tal modo el mecanismo es ms eficiente de aplicar
los cambios. Esto hace la tecnologa de redo Apply un mecanismo altamente
eficiente de propagar los cambios entre las bases de datos.
Una base de datos standby lgica puede permanecer abierta al mismo
tiempo que las tablas son actualizadas desde la base de datos primaria, y esas
tablas son simultneamente disponibles para accesos a lecturas. Esto hace
que una base de datos standby lgica sea una buena eleccin para hacer
consultas, actividades de reportes, adems se puede descargar la base de
datos primaria aumentando con ello el rendimiento con lo cual se puede ahorrar
valiosos ciclos de CPU y de entradas y salidas a disco.
Esta solucin de Oracle Standby puede mejorar el rendimiento del servidor
de base de datos primario si ste se encuentra demasiado sobrecargado.

65

Por ejemplo, si un departamento necesita hacer reportes de un cierre del

mes, entonces en lugar de hacerlos en la mquina primaria, la cual no solo est
procesando transacciones y atendiendo a varios usuarios, al aplicarle el reporte
a

la

misma

bajara

el

rendimiento

suponiendo

que

ste

se

lleva

aproximadamente 3 horas, con ello se sobrecarga al procesador del sitio

primario y obviamente provocara un bajo rendimiento del sitio primario;
mientras que si este reporte se efecta en la base de datos standby
posiblemente le tome aproximadamente 30 minutos, con lo cual se puede
colocar en modo de solo lectura y con ello se estara utilizando ese procesador
que bsicamente no est efectuando nada ms que aplicando los archived redo
logs. Con este ejemplo se hace un mejor uso del sistema primario como del
sitio secundario, sin afectar su rendimiento, al contrario, se mejora el
rendimiento del sitio primario.
3.2.7. Disponibilidad
Data Guard proporciona una eficiente y comprensiva solucin de
recuperacin a desastres, proteccin de datos y alta disponibilidad.

Fcil

administracin de switchover y failover permitiendo cambiar entre bases de

datos primaria y standby, minimizando el tiempo fuera de servicio planeados y
no planeados (downtime) de la base de datos primaria.
En cuanto a disponibilidad se refiere la base de datos standby llega a
activarse slo si una falla es detectada por el DBA y ste mismo decide si la
activa o se soluciona el problema en el sitio primario. Regularmente lo que ms
falla en un servidor son los discos y se puede solventar el problema cambiando
el mismo y aplicando un backup.

66

Por el contrario, si dentro de ese disco la parte que se da corresponde

al diccionario de datos de la base de datos el administrador de la base de datos
deber de activar la base standby para convertirla en la base de datos primaria.
Esta accin no es transparente al usuario y toma cierto tiempo que la base de
datos standby se convierta en la primaria.
La figura describe una operacin de failover de una base de datos primaria
en San Francisco hacia una base de datos standby en modo de recuperacin
administrada en Boston.
Figura 18. Failover de una base de datos primaria hacia una base de datos
standby

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96524.pdf

67

3.2.8.

Crecimiento

La base de datos standby no proporciona el beneficio de escalabilidad

horizontal ya que esta solucin no est basada en clusters.
3.2.9. Ventajas

Data Guard ofrece recuperacin a desastre, proteccin de datos y alta

disponibilidad.

Completa proteccin de datos, con sus bases de datos standby, Data

Guard garantiza ninguna prdida de datos, incluso en un desastre
imprevisto.

Una base de datos proporciona un salvavidas contra la

corrupcin de los datos y errores de usuario. Las corrupciones a nivel de

almacenamiento fsico en la base de datos primaria no son propagadas
hacia la base de datos standby. Similarmente, las corrupciones lgicas o
errores de usuario que causan que la base de datos primaria sea daada
permanentemente puedan ser resueltos.

Finalmente, los redo data son

validados cuando se aplican en la base de datos standby.

Eficiente uso de los recursos del sistema, las tablas de la base de datos
standby que son actualizadas con los redo logs recibidos de la base de
datos primaria pueden ser usados para otras tareas tales como
operaciones de backup, reportes y consultas, de tal modo reduce la carga
de trabajo necesaria para realizar esas tareas, ahorrando ciclos de CPU y
entrada o salida en la base de datos primaria. Con una base de datos
standby lgica, los usuarios pueden realizar operaciones de manipulacin
de los datos normalmente sobre las tablas en esquemas que son
actualizados de la base de datos primaria.
68

Una base de datos standby puede quedar abierta mientras las tablas son
actualizadas desde la base de datos primaria, y las tablas son
simultneamente disponibles para accesos de solo lectura.

Flexibilidad

en

la

proteccin

de

los

datos

para

balancear

los

requerimientos de disponibilidad contra rendimiento, Oracle Data Guard

ofrece mxima proteccin, mxima disponibilidad y mximo rendimiento
para ayudar a las empresas a balancear los requerimientos de
disponibilidad de los datos contra el rendimiento del sistema.

Administracin simple y centralizada, el Data Guard broker proporciona la

interface grfica de usuario Data Guard Manager y la interface de lnea de
comando Data Guard command line para automatizar la administracin y
la operacin de las tareas a travs de mltiples bases de datos en una
configuracin Data Guard.

El broker tambin monitorea todo de los

sistemas dentro de una sola configuracin Data Guard.

Deteccin y resolucin automtica de aberturas, si la conectividad se

pierde entre la base primaria y una o ms bases de datos standby por
ejemplo, debido a problemas de red, redo data generados en la base de
datos primaria no pueden ser enviados a las bases de datos standby. Una
vez es establecida la conexin nuevamente,

la secuencia de log

extraviados (o abertura) son automticamente detectados por Data Guard,

y los redo logs necesarios son automticamente transmitidos hacia las
bases de datos standby.

Las bases de datos standby son

resincronizadas con la base de datos primaria, con ninguna intervencin

manual por parte del administrador de la base de datos.

69

Mantener una base de datos standby en una localidad que est ubicada
geogrficamente remota de la base de datos primaria o mantener varias
bases de datos standby en diversas localidades geogrficas.

Hacer una base de datos standby la nueva base de datos primaria con
mnima prdida de tiempo y de datos si la base de datos primaria est
completamente destruida.

Provee posible proteccin contra lotes de trabajos errneos, errores de

usuario o aplicacin que corrompa la base de datos primaria por no aplicar
logs archivados que contienen datos corruptos a la base de datos standby.
Se puede entonces activar la base de datos standby no corrupta,
hacindola base de datos primaria.

Una base de datos standby puede ser un gran beneficio para las
estrategias de backup y recuperacin.
3.2.10. Desventajas

Falta de escalabilidad.

Costo, Oracle cobra las licencias que sern usadas en la base de datos
standby.

La activacin de una base de datos standby la debe efectuar el

administrador de la base de datos, aunque la misma se encuentre en
modo de recuperacin administrada.

Operaciones UNRECOVERABLE o NOLOGGING no son propagadas.

70

Prdida de los datos debido a la prdida de los redo logs en lnea, esto
ocurre cuando es manual y no administrada.

3.3. Solucin Oracle Real Application Clusters

3.3.1. Definicin
El software Real Application Clusters (RAC) y una coleccin de hardware
llamada cluster utilizan el potencial de cada componente para crear un potente
entorno de computacin. RAC provee escalabilidad y alta disponibilidad debido
a que se puede agregar nodos al cluster con ello se proporciona la recuperacin
de falla si los componentes del nodo fallaran. En un entorno de RAC todas las
instancias activas pueden concurrentemente ejecutar transacciones contra una
base de datos compartida. RAC coordina cada acceso de las instancias para
compartir los datos con lo cual proporciona consistencia e integridad de los
datos.
RAC proporciona disponibilidad escondiendo las fallas al usuario final sin
interrumpir el acceso a los datos. Transparent Application Failover (TAF) es
una aplicacin que transparentemente redirecciona las consultas de los clientes
de la base de datos, hacia un nodo disponible en el cluster cuando ste falla.
Con esta aplicacin el cliente no ve el mensaje de error que describe la prdida
del servicio.

71

3.3.2. Restricciones

En versiones de Oracle para Windows NT previas a Oracle8 release 8.0.4

soportan nicamente un Oracle home. Se puede instalar productos
Oracle7 release 7.x y Oracle8 release 8.x en el mismo Oracle home. Sin
embargo, no se puede instalar mltiples releases con un tercer dgito del
mismo producto. Por ejemplo, no se puede instalar productos Oracle7
release 7.3.2 y Oracle7 release 7.3.3 en la misma computadora, ya que
una instalacin escribe sobre la previa.

En versiones Oracle8 releases 8.0.4 a 8.0.6, se puede instalar una o mas

releases de Oracle en mltiples Oracle homes. Se puede instalar Oracle8
release 8.0.x y Oracle8i release 8.1.3 o bien Orale7 release 7.x y Oracle8
release 8.0.x en diferentes Oracle homes en la misma computadora.
Tambin se puede instalar diferentes releases de Oracle en el mismo
Oracle home que tengan diferente el primer o segundo dgito del nmero
de release. Por ejemplo, instalar Oracle7 release 7.2 y Oracle8 release
8.0.x en el mismo Oracle home.

Para instalar Oracle8i release 8.1.3 a Oracle9i release 2 (9.2) que tienen la
misma funcionalidad que el inciso anterior pero contienen las siguientes
restricciones:

No se puede instalar cualquier release de Oracle8i release 8.1.3 a

Oracle9i release 2 (9.2) en un Oracle home que fue creado con el
instalador antiguo llamado Oracle Installer y fue usado para instalaciones
previas a Oracle8i release 8.1.3; el nuevo instalador es llamado Oracle
Universal Installer y est basado en Java.

72

Los releases Oracle 8i release 8.1.3 a Oracle9i release 2 (9.2) deben ser
instalados en Oracle home separados. No se puede tener ms de un
release instalado en cada Oracle home.

RAC puede correr con cualquier base de datos Oracle creada en modo
exclusivo (x).

Oracle en modo exclusivo puede acceder una base de

datos creada o modificada por el software RAC. En adicin a ello, cada

instancia debe tener su propio juego de redo logs.

La base de datos en modo de cluster, no soporta las siguientes

operaciones:
o Crear una base de datos (create database)
o Crear un control file (create control file)
o Cambiar el modo de archiving de la base de datos (las opciones
ARCHIVELOG y NOARCHIVELOG de alter database)
o Para desarrollar esas opciones se debe apagar (shutdown) todas
las instancias e iniciar (startup) una instancia en modo exclusivo.

El nmero de datafiles soportados por Oracle es especfico en el sistema

operativo. Dentro de este lmite, el nmero mximo permitido depende de
los valores usados en el comando create database. Esto es limitado por el
tamao fsico del control file.

Se pueden agregar nodos dinmicamente al cluster pero esto depende de

las capacidades del sistema operativo. Si se esta usando Oracle
clusterware, entonces dinmicamente se pueden agregar nodos e
instancias sobre diferentes plataformas.

73

Dentro de las limitaciones de TAF se pueden encontrar que el efecto de

cualquier declaracin Alter Session se perder, lo cual incluye prdida de las
tablas temporales globales: cualquier paquete PL/SQL se perder y las
transacciones que involucren declaraciones de insertar, actualizar o borrar, se
perdern ya que no pueden ser manejadas automticamente por TAF.

Por default, cuando un TAF ha iniciado y ocurre un failover, Net8 tomar

solamente una conexin hacia una instancia de backup, pero usando los
parmetros retries y delay, se puede cambiar el comportamiento de Net8
haciendo mltiples intentos para conectar a un backup de la base de
datos.
3.3.3. Requerimientos mnimos
Los requerimientos mnimos de software en cada nodo de un cluster se

muestran en la siguiente tabla.

Tabla V. Requerimientos mnimos de sistema operativo para la solucin

Oracle Real Application Clusters
Plataforma

Sistema operativo

Parche requerido

Basada en Windows Windows NT 4.0

Service pack 5

Basada en Windows Windows 2000 (Server,

Service pack 1

Advanced Server, DataCenter)

Compaq Tru64 Unix Tru64 5.1

5.1 patchkit 4

Compaq Tru64 Unix Tru64 5.1A

5.1A patchkit 1

74

TCP/IP o TCP/IP con SSL

Netscape Navigator 4.76 o mayor / Microsoft Internet Explorer 5.0 o mayor

Se instala Oracle 8/8i Enterprise Edition para OPS u Oracle 9i para RAC
sobre ambos nodos.

Licencia por procesador o nmero de usuarios de Oracle 8/8i/9i Enterprise

Edition sobre cada nodo del cluster.

Hay que tener en cuenta que siempre se debe tener los ltimos parches.

Idealmente, ambos servidores deben ser idnticos en hardware, drivers o

controladores, software, y configuracin. La igualdad fsica de un servidor
a otro evitar que se tenga mayores problemas.
Requerimientos de hardware
Cada nodo requiere:

Discos externos compartidos.

Configuraciones de hardware certificado.

Configuraciones de hardware y red
Para instalar la base de datos Oracle 9i bajo plataformas intel o compatible

se necesita el siguiente hardware, que se muestra en la siguiente tabla.

75

Tabla VI. Requerimientos mnimos de hardware para la solucin Oracle

Real Application Clusters
Hardware

Requerimientos

Procesador(es)

Pentium 266 o mayor (para Oracle 9i Enterprise Edition)

Memoria

RAM: 256 MB en cada instancia

Memoria virtual: el doble de la memoria fsica

Espacio en disco Drive del sistema 140 MB,

Oracle home drive (NTFS) 2.85 GB para Enterprise Edition

duro

Nombres de red publica (conocidos como host o nombres TCP/IP) de

cada nodo.

Si se tiene una interconexin de alta velocidad, en la cual cada nodo tenga

su propio nombre de red privada.

Se usa hardware Virtual Interface Architecture (VIA) y si hay disponibilidad

de NIC (Network Interface Card).
3.3.4. Funcionamiento
Una base de datos en cluster debe tener al menos dos nodos que son

enlazados por una interconexin que comunica cada nodo en el cluster de la

base de datos.

Cada instancia de Oracle usa la interconexin para los

mensajes que sincronizan cada uso de instancia de los recursos compartidos.

Oracle tambin usa la interconexin para transmitir bloques sobre mltiples
instancias compartidas. El tipo primario de recurso compartido son los datafiles
que son accesados por todos los nodos.

La figura de abajo es una vista de

cmo los nodos se interconectan en un cluster de base de datos y cmo ste

accesa los datafiles compartidos sobre los dispositivos de almacenamiento.

76

Figura 19. Interconexin de los nodos en un cluster de base de datos

para Oracle RAC

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/rac.920/a96597.pdf

El

cluster

su

interconexin

son

enlazadas

al

dispositivo

de

almacenamiento o subsistema de discos compartidos, por medio de storage

area network.
RAC usa alta velocidad para el componente de interproceso de
comunicacin (IPC) para la comunicacin entre nodos. Usualmente esta
interconexin usa un ancho de banda grande, facilitando la comunicacin entre
los nodos enlazados y proporcionando baja latencia. Se puede usar Ethernet,
un Fiber Distributed Data Interface (FDDI), u otro hardware para su
interconexin. El IPC define protocolos e interfaces requeridas en un entorno
RAC para transferir mensajes entre las instancias. Los mensajes son la unidad
fundamental de comunicacin entre las interfaces. El IPC es funcionalmente
construido sobre modelo de mensajes en colas asincrnico.

77

Generalmente, cada nodo en un cluster de base de datos tiene uno o ms

CPU.

Los nodos con mltiples CPU son configurados tpicamente para

compartir la memoria principal.

RAC requiere que todos los nodos tengan acceso simultneo a los discos
compartidos para dar a las instancias acceso concurrente a la base de datos.
La implementacin del subsistema de discos compartidos est basado en su
sistema operativo o solucin de hardware.
Las configuraciones para RAC son tpicamente uniformes. Esto significa
que la sobrecarga para cada nodo en el cluster al accesar la memoria es la
misma.
Una base de datos RAC tiene los mismos procesos que una sola instancia
de base de datos Oracle tales como monitor de proceso (PMON), escritor de
base de datos (DBWRn), escritor de log (LGWR), etc.
adicionales para RAC como se muestra en la figura.

Pero hay procesos

Los nombre son

exactamente los mismos que pueden ser creados sobre plataformas

dependientes.
Global Cache Service Process (LMSn), donde n es el rango que puede ir
de 0 a 9 dependiendo de la cantidad de trfico en mensajes, controla el flujo de
mensajes a instancias remotas y maneja el acceso al bloque de datos global.
ste tambin transmite imgenes del bloque entre los buffer de cache de las
diferentes instancias. Esta parte de procesamiento es conocido como CACHE
FUSIN.

78

Global Enqueue Service Monitor (LMON) monitorea las colas globales y

los recursos a travs del cluster y realiza operaciones de recuperacin de colas
globales.

Las colas son estructuras de memoria compartida que serializan

actualizaciones de lnea.
Global Enqueue Service Daemos (LMD) administra las colas globales y
el acceso al recurso global. El proceso LMD administra solicitudes de recursos
remotos.
Lock process (LCK) maneja las solicitud de recursos no basados en
cache fusion tales como libreras y solicitudes de row cache.
Diagnosability Daemon (DIAG) captura los diagnsticos de datos a cerca
de las fallas de procesos entre instancias.
Figura 20 . Proceso de instancia especfica de la solucin Oracle RAC

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/rac.920/a96597.pdf

79

Servicio Global cache y Global enqueue

El Global Cache Service (GCS) y Global Enqueue Service (GES) son
componentes integrados de RAC que coordinan simultneamente el acceso a la
base de datos compartida y comparten los recursos entre la base de datos.
Esos servicios mantienen consistencia e integridad de los datos.

Estos

servicios en cada instancia usan el IPC para comunicarse entre las instancias y
dentro del cluster.
Estos servicios mantienen un Global Resource Directory para registrar la
informacin acerca de los recursos.

El GRD reside en memoria

y est

disponible para todas las instancias. En esta arquitectura distribuida, cada nodo
participa en la administracin de informacin en el directorio. Este esquema
distribuido proporciona tolerancia a fallos y mejora el rendimiento en tiempo de
corrida.
El GCS y GES aseguran la integridad del GRD incluso si mltiples nodos
fallaran. El almacenamiento de la base de datos estara accesible si al menos
una instancia est activa despus de que una recuperacin sea completada.
El proceso cache fusion
Debido a cache fusion y la eliminacin de escrituras a disco que ocurren
cuando otras instancias solicitan modificacin para los bloques, el rendimiento
es grandemente disminuido debido a la sobrecarga para administrar los datos
compartidos entre las instancias.
Las lecturas concurrentes sobre mltiples nodos ocurren cuando dos
instancias necesitan leer el mismo bloque de datos.
80

RAC resuelve esta situacin sin sincronizacin porque mltiples instancias

pueden compartir los bloques de datos para accesos de lectura sin conflictos de
coherencia de cache.
Una solicitud de lectura de una instancia para un bloque que fue
modificado por otra instancia y an no ha sido escrita a disco puede ser una
solicitud para una versin actual de el bloque o para una versin de lectura
consistente. En ese caso, el (LMSn) transfiere el bloque de la instancia que lo
tiene en cache hacia la instancia que lo solicita sobre la interconexin. La figura
muestra que un bloque de datos ha sufrido modificacin, por una instancia y
est en modo exclusivo (X).

Adems, en este escenario se asume que el

bloque ha sido accesado solo por la instancia que los cambi. sta es, la nica
copia existente a lo largo del cluster. En otras palabras, el bloque tiene un rol
local (L).
Figura 21. Solicitud de cambio a un bloque para una operacin de
modificacin

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/rac.920/a96597.pdf

1.

La instancia modifica el bloque, la instancia 1 enva una solicitud al GCS.

2.

El GCS transmite la solicitud para mantenerla en la instancia 2.

81

3.

La instancia 2 recibe el mensaje y el proceso LMS enva el bloque a la

instancia 1. Antes de enviar el bloque, el recurso es bajado en la instancia
2 de modo exclusivo a nulo (N) y la instancia 2 retiene el buffer cambiado
como una PI.

El rol cambia a global (G) porque quiz el bloque

permanezca diferente en ms de una instancia. A lo largo del bloque, la

instancia 2 comunica hacia las instancias solicitantes que la instancia 2
retiene en una PI (past image o imagen pasada) en modo nulo (N). En el
mismo mensaje, la instancia 2 especifica que el solicitante debe retener el
bloque en modo exclusivo (X) y con un rol global (G).
4.

Al recibir el bloque, la instancia 1 informa a el GCS que lo mantiene en

modo exclusivo y con un rol global. Hay que notar que el bloque no ha
sido escrito a disco antes que el recurso no le sea permitido a la instancia
1.
Las escrituras concurrentes sobre diferentes nodos ocurren cuando el

mismo bloque de datos es modificado frecuentemente por diferentes instancias.

En tal caso, la instancia que tiene el bloque completa su trabajo sobre ste
despus de recibir su solicitud. El GCS entonces convierte los recursos sobre
el bloque para su administracin global y el proceso LMSn transfiere una copia
del bloque a la cache de la instancia que lo solicit. En detalle seria de la
siguiente manera:

El GCS rastrea cada versin del bloque de datos y cada versin es

referida como una past image (PI). En el evento de una falla, Oracle
puede reconstruir la versin actual de un bloque, usando la informacin en
un PI.

82

La transferencia de datos cache a cache es efectuada por medio de

interconexin de alta velocidad IPC, as elimina entradas o salidas a disco.
En la figura se ilustra cmo una instancia puede realizar un checkpoint en

cualquier momento o reemplazar los buffer en el cache debido a solicitudes de

liberacin del buffer. Porque pueden existir mltiples versiones del bloque de
datos con cambios en las instancias sobre el cluster, el GCS se asegura que
nicamente la versin actual de los datos sea escrito a disco por medio de un
protocolo que administra la escritura. Y tambin debe asegurarse que todas las
versiones previas sean borradas en todas las otras caches.
Figura 22. Escritura de bloques a disco

Fuente: http://download-east.oracle.com/docs/cd/B10501_01/rac.920/a96597.pdf

1. La instancia 2 enva una solicitud de escritura a GCS.

2. El GCS enva la solicitud a la instancia 1, mantener el bloque actual.
83

3. La instancia 1 recibe la solicitud de escritura y escribe el bloque a disco.

4. La instancia 1 registra completamente la operacin de escritura con el GCS
y le informa que el rol del recurso se convirti en local porque la instancia 1
realiz la operacin de escritura del bloque actual.
5. Despus de recibir la notificacin, el GCS ordena que todas las PI
mantenidas en las instancias sean descartadas. El buffer es liberado y el
recurso previamente en modo nulo es cerrado.
En lo referente a TAF, ste proporciona los siguientes tipos de failover

Select failover. Cuando es usado el Select failover, Net8 mantiene la pista

de cualquier declaracin Select emitida en la transaccin actual. Si la
conexin de la instancia se pierde, Net8 establece una conexin a la
instancia de backup, ejecuta de nuevo la declaracin Select y posiciona el
cursor en donde sucedi la interrupcin, entonces el cliente puede seguir
leyendo lneas como si nada hubiese sucedido.

Session failover.

Cuando se pierde la conexin de una instancia,

SESSION failover es el resultado de establecer una nueva conexin hacia

una instancia de backup. Cualquier trabajo en progreso se pierde.
Dentro de este tipo de failover, Oracle ofrece dos submtodos:

Basic failover: En este failover Oracle conecta hacia una instancia de

backup nicamente despus que una conexin primaria falla.

84

Preconnect failover:

En este failover Oracle conecta hacia un backup

base de datos y una base de datos primaria.

3.3.5. Confiabilidad
Oracle provee continuidad ocultando las fallas al usuario final.

Esto

provee acceso a los datos continuamente e ininterrumpidamente, gracias a

TAF en la base de datos ya que transparentemente la aplicacin redirecciona la
consulta (query) del cliente hacia un nodo disponible en el cluster cuando el
nodo al que est conectado el cliente falla. Los clientes no ven el mensaje de
error en la cual se pierde el servicio (Oracle 9i).
ocultadas

Las fallas tambin son

debido a la redundancia de conexiones con otra base de datos

evitando retardos si miles de usuarios deben migrar sus servicios durante una
falla en el nodo con el cual estaban conectados. Esas capacidades proveen
grandes beneficios para las aplicaciones que no pueden enfrentar un tiempo
fuera de servicio (downtime).
3.3.6. Rendimiento
La tecnologa de Cache Fusion implementada en Oracle RAC provee
varios puntos clave que la hacen tener un mejor rendimiento.

Utilizacin de caches de las bases de datos de todos los nodos en el

sistema para satisfacer las solicitudes de la aplicacin hacia cualquiera de
los nodos.

Remueve las operaciones de disco de un camino crtico en la

sincronizacin entre nodos.

85

Reduce grandemente el nmero requerido de mensajes de sincronizacin

entre los nodos.

Baja latencia entre los protocolos de interconexin del cluster para los
mensajes y el envo de datos con un alto ancho de banda.
Otra caracterstica importante que ayuda al rendimiento es la ejecucin

paralela de consultas sobre RAC en esta solucin debido a que puede distribuir
porciones de una gran declaracin SQL a travs de mltiples instancias. Con
ello la transaccin es completada ms rpidamente puesto que la misma se
ejecuta sobre mltiples CPU. En Oracle RAC, el software determina en tiempo
de corrida si se aplicar un proceso de ejecucin en paralelo en el servidor o
nicamente en una instancia, o si esos procesos corrern sobre mltiples
instancias.

En general, Oracle intenta usar slo una instancia cuando hay

suficientes recursos disponibles. Esto reduce el trfico de mensajes entre las

instancias cruzadas.
3.3.7. Disponibilidad
RAC proporciona disponibilidad ya que su arquitectura est basada en
clusters, los cuales proporcionan redundancia. La falla de un nodo no afecta la
forma de procesar transacciones, mientras haya un nodo sobreviviente a lo
largo del cluster, todos los clientes de la base de datos pueden procesar
transacciones, aunque ellos posiblemente necesiten incrementar los tiempos de
respuesta pero esto es debido a la capacidad de las reglas de validacin sobre
el nodo sobreviviente. Esta arquitectura tambin permite agrupar nodos para
que estos se coloquen fuera de lnea para propsitos de mantenimiento
mientras el resto del cluster contina proporcionando servicios en lnea.

86

RAC

puede

agregar

mayor

disponibilidad

si

el

sistema

de

almacenamiento compartido proporciona una solucin basada en hardware que

se conoce como mirroring, con la cual se dispone de redundancia en caso de
que ocurra una falla en los discos.
En lo que se refiere a recuperacin de desastres, estos sistemas de
cluster no pueden ser usados contra ellos, ya que los desastres tales como
terremotos, incendios, atentados, etc. Pueden destruir el sitio fsicamente, y
con ello se perdera por completo la base de datos.
Por lo anteriormente expuesto, RAC sobresale en reas primarias con
respecto a la alta disponibilidad:

Oculta las fallas al usuario final.

Entrega disponibilidad con N-1 nodos en un cluster con N nodos.

3.3.8. Crecimiento
Oracle RAC provee un entorno en el cual mejora el rendimiento y

adiciona capacidad al agregar nodos.

En algunas plataformas se puede

agregar nodos dinmicamente mientras el cluster est corriendo.

El nmero de nodos que RAC puede soportar es significativamente
mayor que cualquier otra aplicacin.

Los sistemas pequeos que estn

configurados para alta disponibilidad deben tener nicamente dos nodos. Sin
embargo, mayores configuraciones permiten tener 32 y hasta 64 nodos.

87

3.3.9. Ventajas
Esas ventajas incluyen rendimiento de procesamiento y escalabilidad
sobre sistemas con instancias nicas y tiempo de respuesta mejorado. Una
solucin RAC tambin provee una solucin ideal de alta disponibilidad
resolviendo la falla de un nodo en un ambiente de clusters.

Escalabilidad sobre sistemas de una sola instancia, al agregar nodos al

cluster para un mejor desempeo.

Tiempo de respuesta.

Transparencia.

Debido a sus componentes redundantes, los cuales proveen servicio

ininterrumpido, siempre en el evento de fallas de hardware o software,
RAC provee alta disponibilidad si un nodo falla en el cluster, entonces el
sistema no se ve afectado. En otras palabras, todos los usuarios tienen
acceso a todo dato en donde haya un nodo disponible en un cluster. Esto
significa que los datos estn consistentemente disponibles.

Debido a cache fusin de RAC se evita la entrada o salida hacia los

discos, ya que si un bloque de datos fue actualizado por otro nodo, lo
traslada del nodo remoto hacia el nodo que est procesando la consulta,
de esa manera se ahorra la entrada o salida del disco.

88

3.3.10. Desventajas

Tambin es importante notar que hay serias limitaciones para la

herramienta Oracle TAF. La limitacin ms seria es que Oracle TAF no
soporta el reinicio de cualquier declaracin de DML incluyendo insert,
update y delete.

Dentro de TAF se encuentran ciertas limitaciones que implican prdida de

tablas

globales

temporales,

prdida

de

paquetes

PL/SQL.

Las

transacciones que involucren declaraciones insert, update o delete no

pueden ser manejadas automticamente por TAF, el efecto de cualquier
declaracin alter session se perder.

Esta solucin RAC requiere tiempo fuera de servicio para actualizar el

software de Oracle. Por lo tanto, los sistemas se deben detener para
aplicar las actualizaciones de Oracle.

RAC no proporciona recuperacin de desastre, si el cluster en el que

reside RAC se encuentra dentro de la misma habitacin o dentro del
mismo edificio y ste se destruye completamente.

Oracle RAC requiere licencias adicionales, stas pueden ser de acuerdo al

nmero de procesadores con que cuente el nodo, es decir, que si cada
nodo puede contener dentro de l dos procesadores y el cluster se
compone de dos nodos ello significara pagar cuatro licencias por
procesador con lo cual esta solucin en lo referente al costo de licencias
es alta.

89

3.4. Solucin Shareplex para Oracle

3.4.1. Definicin
Shareplex para Oracle proporciona alta velocidad de replicacin basada
en log entre instancias Oracle sobre las siguientes plataformas Windows
NT/2000, Unix y otras.
Shareplex replica nicamente los cambios realizados en el sistema de
produccin hacia el sistema alterno que puede ser remoto, esto es
continuamente sin interrumpir el proceso de produccin, con lo cual los datos
son continuamente accesibles.

Con Shareplex se pueden correr reportes

contra estos datos y obtener los mismos resultados como si se estuviera

corriendo un reporte sobre el sistema de produccin, sin afectar la productividad
de los usuarios en lnea.
3.4.2. Restricciones

Las bases de datos origen y destino deberan usar la misma versin de

SharePlex. Para ejemplo se supondr que est replicando la instancia
ora7 usando SharePlex 3.0, y est replicando la instancia ora8 usando
SharePlex 3.2.

la versin SharePlex para la instancia destino ora7

debera ser SharePlex 3.0, y la versin SharePlex para la instancia destino

ora8 debera ser SharePlex 3.2.

Shareplex no puede replicar instancias corriendo sobre OPS, porque OPS

usa mltiples redo logs.

90

Shareplex no puede replicar ciertos componentes que son usados por

Oracle, dentro de ellos se pueden mencionar los siguientes: Alter Table
para borrar una columna, agregar una columna de objetos largos (LOB,
LARGE OBJETCS), agregar una columna con una clave primaria o un
constraint nico, mover lneas, redefinir una columna LOB, ALTER TABLE
comando que cambia el tamao de una columna cuando hay dato en la
misma. Si no hay dato en la tabla, si lo soporta, DDL sobre tablas
particionadas, DDL para agregar una columna LOB, actividades que no
estn en los redo o archive logs, Tablas de SYSTEM tales como
diccionarios de datos. La replicacin del mismo objeto hacia otra base de
datos podra causar corrupcin .

Shareplex regresar un mensaje de

error, si se intenta activar una configuracin que incluya una tabla del
sistema, ndices, Index organized tables (IOT).

Esos pueden ser

convertidos en tablas regulares si se desea replicar vistas, vistas de

objetos, Snapshot y vistas materializadas, sinnimos, mtodos, stored
procedures, funciones, y paquetes, triggers, tipos de datos NCLOB Y
BFILE, VARRAY y otro tipo de datos, tablas clustered.
3.4.3. Requerimientos mnimos
En sistemas con Windows:

Mnimo de 300 MB de RAM.

Tamao del archivo de pgina adicional de 200 MB si el tamao usado es

80% o ms.

Cliente Oracle 8.1.6.

Servidor de Terminal MS o PC para proveer soporte tcnico por medio de

login remoto.

91

3.4.4. Funcionamiento
Cuando se activa una configuracin SharePlex comienza la replicacin,
los datos son transportados a lo largo de una serie de colas por medio de una
serie de cinco procesos, comnmente llamados servicios, mientras llega a su
destino en el sistema designado. Esos procesos se ejecutan automticamente
conforme sean necesitados, pero tambin pueden ser detenidos y reiniciados
mediante comandos emitidos por un usuario de SharePlex.

El proceso de captura

lee uno o varios redo log para obtener los

cambios a los objetos seleccionados para replicacin, como se dijo en la

configuracin activa.

El proceso de captura escribe los datos para los

cambios a la cola de captura, donde se acumula mientras el siguiente

paso del proceso SharePlex (lectura) est listo para ello. Hay un proceso
de captura separado para que cada instancia a ser replicada, funcione de
manera concurrente e independientemente.

El proceso de lectura es el siguiente paso en la replicacin, agrega

informacin de direccionamiento a la transaccin (basada en el archivo de
configuracin) y construye una cola de exportacin.

Hay un proceso

separado de lectura para cada origen de datos, cada uno funcionando

concurrentemente e independientemente. En general, todos los procesos
de lectura comparten la misma cola de exportacin.

92

El proceso de exportacin opera sobre el sistema origen para leer los

datos de la cola de exportacin y lo enva a travs de la red hacia un
proceso de importacin sobre el sistema destino. No importa cuntas
configuraciones activas se hallan directamente replicando al sistema
especfico destino.

El replicador crea un proceso de exportacin para el

sistema destino, compartido por todos los datos. Si hay dos sistemas
destino, habr dos procesos de exportacin y as sucesivamente.

El

proceso de exportacin es la primera parte de la exportacin-importacin

par de servicio, los cuales actan como un transporte para mover los
datos entre los dos sistemas sobre una red TCP / IP.

El proceso de importacin es el segundo medio del par de servicios

exportacin-importacin, para cada proceso de exportacin hacia un
sistema destino hay un correspondiente proceso de importacin sobre ese
sistema.

La funcin del proceso de importacin recibe los datos del

sistema origen y construye una cola post sobre el sistema destino una cola
para cada fuente de datos comienza a ser replicada a ese sistema.

El proceso post en cada sistema destino lee los datos que esperan en la
cola post,

construyendo declaraciones SQL para las operaciones de

replicacin y aplicando lo mismo a las tablas destino sobre el sistema

destino. Mltiples procesos post, cada uno asignado a una combinacin
de instancias diferentes origen-destino, pueden operar simultneamente
sobre el sistema destino.

93

Figura 23. Muestra el proceso bsico de replicacin usado por el producto

Shareplex para Oracle

Fuente: http://www.dlt.com/quest/solutions-availability.asp?sol=shareplx

Entendiendo la sincronizacin
Es importante configurar los sistemas y bases de datos para asegurarse
que los datos origen y destino queden sincronizados. Resolviendo condiciones
fuera de sincrona que pueden ser consumidas en tiempo y disociador para la
actividad del usuario.
94

Para establecer y mantener un entorno de replicacin sincronizada, se

necesita un entendimiento bsico de cmo replica SharePlex y cmo determina
una condicin de fuera de sincrona.
La definicin bsica de sincronizacin es que todas las tablas
correspondientes en el origen y destino en la configuracin de la replicacin
sean idnticas. Esto significa:

Tengan la misma estructura, los mismos nombres de columna y el mismo

tipo de dato (incluyendo atributos idnticos)

dentro de las columnas

correspondientes.

Todas las lneas emparejadas, si existe una lnea en una base de datos,
existe en todas las otras.

Los valores en las lneas correspondientes son idnticos.

Eso es, despus de todo, el punto de replicacin, tener una rplica en una

base de datos de algn objeto o todos los objetos en otra base de datos.
3.4.5. Confiabilidad
Construye declaraciones estndar SQL y cambios post replicados a la
base de datos destino.

Replica nicamente los cambios hechos en los datos

de origen, proveyendo una rpida y fiable solucin de replicacin. Por defecto,

si los cambios estn en un insert, se usa todo de las columnas en la lnea a
construir en una declaracin insert. Si los cambios estn en un delete, se usa
nicamente el valor llave para construir una clusula where que localiza la lnea
correcta.
95

Si los cambios son un update, se usa una llave nica y nicamente los
valores de las columnas cambiadas en la clusula where. Antes de mandar
esos cambios, el proceso post compara una imagen previa de los valores de
las columnas de origen para los valores existentes en la columna destino. Si
ellos concuerdan, confirman un estado de sincronizacin,

post aplica los

cambios; si no, los cambios son llevados hacia un archivo de error y SharePlex
regresa un error de fuera de sincronizacin. SharePlex valida constantemente
el dato destino.
3.4.6. Rendimiento
Toda comunicacin y movimiento de datos es manejado por sistemas de
transporte y mensajes internos de Shareplex, usando protocolos asincrnicos
con conexiones TCP/IP que son muy eficientes para grandes transferencias de
datos. Este sistema entrega alto rendimiento, confiabilidad, mientras se usa
menos ancho de banda para la comunicacin. Shareplex puede replicar sobre
cualquier red TCP/IP, incluyendo entornos WAN.
Los cambios son replicados conforme ocurren, ms bien sobre un commit;
Shareplex reduce el impacto que tiene la replicacin sobre la red. Esto no
causa picos en el rendimiento de la red.

Haciendo esto mantiene mnima

latencia entre los sistemas origen y destino.

Shareplex es diseado para recuperarse de fallas en la red. Cuando la
red no est disponible, los registros son almacenados en una cola del sistema
origen.

Shareplex automticamente detecta cundo la red se encuentra

disponible nuevamente y transmite los datos.

96

Tambin puede controlar cuando SharePlex usa la red. Ordinariamente,

los datos son transferidos del origen al destino continuamente. Sin embargo, s
quiere un lmite cuando esto ocurra para enviar datos cuando el costo de
conexin de red sea menor;

por ejemplo, puede detener el proceso de

exportacin en el sistema origen. Los datos quedarn seguramente en la cola

de exportacin mientras inicia la exportacin nuevamente.
3.4.7. Disponibilidad
Se puede configurar SharePlex para replicar sobre conexiones LAN y
WAN que guarden una segunda instancia constantemente actualizada y lista
para tomar la produccin de la instancia cuando el sistema origen est
programado para mantenimiento o un desastre.
La instancia alternativa es una imagen espejo del entorno de produccin.
Para optimizar la efectividad de esta alternativa, todos los objetos replicados
deberan tener el mismo propietario y nombres sobre el sistema primario y
secundario. El periodo fsico se refresca usando para actualizar cambios a la
estructura de la base de datos, mientras SharePlex replica los cambios a los
datos.
Puede configurar replicacin bidireccional usando una configuracin
reversa, mientras el sistema primario est fuera de lnea los usuarios estn
trabajando sobre el sistema secundario, las colas SharePlex cambian sobre el
sistema secundario.

Entonces, cuando el sistema primario es restaurado,

SharePlex puede actualizarse con esos cambios.

97

3.4.8. Ventajas

Mantiene completamente accesible a la instancia destino, no est forzado

a elegir entre replicacin y acceso, puede acceder a la instancia mientras
SharePlex est actualizndola.

Diseado para entornos OLTP de alta intensidad est diseado para los
negocios con volmenes de datos.

Es capaz de replicar millones de

transacciones por da para miles de tablas.

Conserva los recursos del sistema SharePlex logra esta replicacin sin
impactos significativos a la instancia origen, el sistema origen o la red.
Este diseo basado en log permite replicar con muy baja sobrecarga u
overhead.

Velocidad y exactitud con ambas replicacin continua, SharePlex es

rpido, minimiza la latencia entre las instancias origen y el destino
capturando las modificaciones a las tablas seleccionadas y secuencias de
redo logs Oracle continuamente, dndole prioridad a la replicacin de la
transaccin que les ha dado commit.

Si la transaccin es cancelada,

SharePlex replica el rollback tanto que la instancia destino es una

representacin exacta de la base de datos origen.

Shareplex es rpido, sin embargo, la velocidad no sacrifica la exactitud del

dato. Shareplex estrictamente adhiere al modelo consistencia de lectura,
manteniendo ambas operaciones en orden y el contexto de la sesin toda
la manera al de la instancia designada, donde usa el estndar SQL para
aplicar la transaccin.

98

SharePlex mantiene tolerancia a fallos, puede colocar en una cola si la

instancia destino est abajo, permitindole a las transacciones acumularse
en el sistema destino mientras la comunicacin puede ser restablecida con
la instancia destino. Si el sistema destino en la red est abajo, SharePlex
almacena las transacciones en el sistema origen mientras las operaciones
son restauradas.

Provee alto nivel de control de usuario con este diseo, se puede tener
opciones adicionales; si se prefiere controlar cuando SharePlex enve los
datos sobre el enlace de la red, se puede hacer.

Instalacin fcil y rpida SharePlex, por todo lo sofisticado y poderoso que

es, es relativamente simple de instalar. El promedio de instalacin toma
alrededor de una hora sobre dos sistemas.

Replica en un entorno de alta disponibilidad

provee una ventaja

significativa en este entorno y otras operaciones de misiones crticas,

donde el acceso a los datos es crtico, y el downtime significa prdida de
oportunidad en los negocios. Shareplex permite hacer la sincronizacin
inicial de replicacin, como la resincronizacin despus de una falla o
cambios en la aplicacin-base de datos, para lograr con una mnima
interrupcin la actividad del usuario.

En adicin, usando replicacin

Shareplex con otras tecnologas de alta disponibilidad permite a la base de

datos secundaria ser usada para consultas y reportes.

99

Shareplex entrega esos beneficios por medio de la funcin reconcile, la

cual coordina los resultados de una sincronizacin o resincronizacin
fsica, como proveer con un backup o disco mirroring y soluciones
refrescadas, con replicacin basada en transacciones. Despus que la
base de datos destino ha sido recuperada, la funcin reconcile compara la
copia esttica proveda por el backup con las transacciones replicadas en
las colas de replicacin para traer las dos bases de datos dentro de
sincronizacin.

SharePlex, que es una solucin liviana en uso de recursos (CPU, ancho

de banda de comunicacin, memoria, sobre carga moderada a la base de
datos, etc.), sin un solo punto de falla y facilidad de manejar ambientes
heterogneos en versiones de base de datos Oracle y sistemas operativos
distintos y diferentes versiones del mismo.
3.4.9. Desventajas

Posiblemente precio; sin embargo, cuando es misin crtica no importa

pagar un poco de dinero con tal de tener disponibilidad, rendimiento, etc.

3.5. Solucin SQL Server 2000 Cluster

3.5.1. Definicin
Esta solucin de la base de datos SQL Server 2000 cluster con acceso
compartido a una sola base de datos, utiliza las ventajas proporcionadas por los
cluster ya que si un nodo en el cluster falla, los nodos restantes continan
dando servicio a los usuarios conectados a los mismos.

100

3.5.2. Restricciones

SQL Server 2000 Cluster solo corre bajo el sistema operativo Microsoft
Windows Server.
3.5.3. Requerimientos mnimos
El software que se necesita para SQL Server cluster depende de cuntos

nodos tenga el cluster, si tiene dos o ms que dos.

Para el cluster de dos nodos, se necesita lo siguiente:

Dos licencias para Microsoft Windows 2000 Advanced Server

Una licencia para SQL Server 7.0 Enterprise o SQL Server 2000
Enterprise para activo-pasivo, o dos licencias para activo-activo.

Los ltimos Service Packs para Windows 2000 y SQL Server.

Hay que tener en cuenta que siempre se debe tener los ltimos Service

packs, debido al problema de los bugs o errores relacionados al cluster y que

estos hayan sido resueltos por ellos mismos.
Hardware necesario para cluster
Se asumir un cluster de dos SQL Servers, para ello se necesitara como
mnimo lo siguiente:

Dos servidores con un mnimo de 256 MB de RAM y un solo CPU Pentium

III.

101

Un arreglo de discos compartido que soporten RAID 5, cualquiera de los

dos SCSI o canal de fibra.

Cada servidor debe tener al menos un disco duro local SCSI y su propia
controladora SCSI.

Cada servidor debe tener un adaptador SCSI o canal de fibra para

comunicarse hacia el arreglo de discos compartidos. El arreglo de discos
compartidos no puede ser usado por la controladora SCSI usada para el
disco duro local o el CD-ROM.

Cada servidor debe tener 2 tarjetas de red PCI (una para conexin privada
y la otra para la conexin pblica).

Idealmente, ambos servidores deben ser idnticos en hardware, drivers o

controladores, software, y configuracin. La igualdad fsica de un servidor
a otro, evitar que se tenga mayores problemas.

Otra consideracin muy importante es cuando se seleccione el hardware

del cluster y es que ste debe ser aprobado por la lista de compatibilidad
de hardware de Microsoft como un sistema soportado. Esto significa que
antes que Microsoft soporte el cluster,

todo el hardware del cluster

seleccionado (servidores, tarjetas, arreglo de discos, etc.) debe haber sido

probado

como un sistema completo y aprobado por Microsoft.

Si el

sistema que se comprara no ha sido probado, entonces Microsoft no

podr ayudar incluso si se les llamara o se les pagara por soporte.

102

3.5.4. Funcionamiento
En un cluster de dos nodos, uno de SQL Server es referido como el nodo
primario y el segundo como el nodo secundario. En un diseo de cluster activopasivo, SQL Server correr sobre el nodo primario, y cuando el nodo primario
falle, entonces el secundario entrar en funcionamiento.
Cuando se construye un cluster de dos nodos usando Windows 2000
Advanced Server y el servicio Microsoft Clustering, cada nodo debe estar
conectado a un arreglo de discos compartidos usando cables SCSI o un canal
de fibra.
Usualmente, este arreglo de discos compartido usa arreglos de discos con
nivel RAID 5.

Todos los datos compartidos en el cluster deben ser

almacenados en este arreglo de discos, de tal manera que cuando ocurre una
falla, el nodo secundario en el cluster no puede accesarlo.
Como se ha dicho, el cluster no ayuda para la proteccin de los datos o el
arreglo de discos en los que est almacenada la informacin. Por ello, es muy
importante que se seleccione un arreglo de discos compartido que sea confiable
e incluya tolerancia a fallos.
Ambos servidores deben estar conectados a un arreglo de discos
compartido y deben estar conectados por medio de una red privada, que es
usada para cada nodo para mantener el estado del otro nodo. Por ejemplo, si
el nodo primario experimenta fallas de hardware, el nodo secundario detectara
esta falla y automticamente iniciar un failover.

103

Cmo se dan cuenta los clientes que estn usando SQL Server que ha
ocurrido una falla en el cluster? Esto es parte del Microsoft Cluster Service.
Esencialmente SQL Server tiene asignada su propio nombre y direccin virtual
TCP/IP. Este nombre y direccin son compartidas por ambos servidores en el
cluster.
Usualmente, un cliente se conectara a SQL Server cluster usando el
nombre virtual usado por el cluster. Y esto va mas all de lo que al cliente le
concierne, ya que hay un nico SQL Server fsicamente, no dos. Asumiendo
que el nodo primario de SQL Server cluster es el nodo que est corriendo SQL
Server sobre un diseo de cluster activo-pasivo, entonces el nodo primario
responder a las solicitudes de los clientes.

Si el primario falla, entonces

ocurrir un failover hacia el nodo secundario, el cluster conservar el mismo

nombre virtual de SQL Server y la misma direccin TCP/IP, aunque ahora un
nuevo servidor fsico responder a las solicitudes de los clientes.
Durante el periodo de failover, el cual puede ser varios minutos porque la
cantidad de tiempo depende del nmero y tamao de la base de datos SQL
Server, y de cmo fueron activados, los clientes no podrn acceder a SQL
Server, entonces hay una pequea cantidad de tiempo fuera de servicio cuando
ocurre un failover.
Cmo reacciona el cliente ante el proceso de failover. Algn software
solo esperar a que ser recupere del failover, cuando ste se complete,
continuar como si nada hubiera sucedido. Algn software presentar una
ventana con un mensaje en pantalla, describiendo prdida de conexin. Otro
software cliente no sabr qu hacer, por lo que los usuarios tendrn que salir y
recargar a los clientes antes que puedan acceder nuevamente a SQL Server.

104

Como parte de este proceso de prueba, cuando se implementa un SQL

Server cluster, es importante encontrar las reacciones de los clientes del
software que se conectan a SQL Server cuando ocurre un failover. De esta
manera, se puede informar a los usuarios que tienen que esperar, con lo cual
habr una mejor comunicacin cuando esto ocurra.
Una vez que ocurre un failover, se querr encontrar que lo caus para
tomar la accin necesaria y corregir el problema. Una vez que el problema ha
sido resuelto, el siguiente paso es failover SQL Server back hacia el nodo
primario del nodo secundario. Esto se puede programar en cualquier tiempo,
de preferencia cuando la actividad de usuarios sobre el sistema es baja.
3.5.5. Disponibilidad
SQL Server Enterprise Edition ofrece tolerancia a fallas y alta
disponibilidad proporcionando failover de un servidor a otro cuando el primero
falla o se toma fuera de servicio para darle mantenimiento. El mecanismo de
failover funciona sobre dos servidores configurados como un cluster y esos dos
servidores pueden soportar dos instancias de SQL Server. Cada servidor
administra una particin de la base de datos. La base de datos SQL Server es
colocada sobre discos SCSI compartidos los cuales son accesibles para ambos
servidores. Si uno falla, el otro toma los discos y reinicia el servidor fallado
como el nodo sobreviviente. El servidor reiniciado recupera la base de datos y
comienza aceptando las conexiones de los clientes. Los clientes se reconectan
al servidor virtual cuando el servidor primario falla. Una funcin de Windows
2000 Server, Microsoft cluster Service, permite que el nombre del servidor
virtual y la direccin IP migren entre los nodos, entonces los clientes no sabrn
que el servidor ha sido movido.

Este servicio de Microsoft cluster est

disponible en Windows 2000 Server.

105

SQL Server Enterprise Edition proporciona soporte para servidores

virtuales. Una vez configurado, el servidor virtual se mira como otro servidor en
la red, excepto que puede tolerar fallas en el hardware.

Figura 24. Configuracin de SQL Server 2000 cluster

Fuente: http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/default.mspx

SQL Server failover es completamente automtico.

La deteccin y

recuperacin de la falla tomar nicamente pocos minutos. Cuando el nodo

fallido es reparado, es reiniciado y comienza como un nuevo servidor de
backup. Si se desea, el nodo fallido puede regresar a ser el servidor original
cuando sea reparado.

106

3.5.6. Crecimiento
SQL Server proporciona crecimiento, debido a que se basa en la
arquitectura de clusters y como bien se conoce con esta arquitectura se pueden
agregar nodos, ya sea para propsitos de reemplazo en el caso de falla de
algn nodo como tambin se pueden agregar procesadores al nodo lo cual
implicara una escalabilidad vertical en el nodo.
3.5.7. Ventajas

Permite una respuesta automtica a una falla en el servidor o software. No

se requiere de intervencin humana.

Permite realizar actualizaciones sin forzar a los usuarios a salirse del

sistema por periodos extendidos de tiempo.

Permite reducir el tiempo fuera de servicio debido a rutinas de servidor,

red o mantenimiento de base de datos.

El cluster no requiere que cualquier servidor sea renombrado. Entonces

cuando ocurre un failover, esto es relativamente transparente al usuario
final.

Failing back es rpido, y puede ser realizado considerando que el servidor

primario est completamente reparado y colocado nuevamente en lnea.
3.5.8. Desventajas

Ms caro que otras alternativas, tales como servidores standby.

107

Requiere ms tiempo que otras alternativas.

Requiere ms mantenimiento que otras alternativas.

Requiere ms hardware especializado que sea compatible con clusters.

No puede tolerar una falla en el almacenamiento compartido.

Requiere ms experiencia por parte de administradores de base de datos

y administradores de red.

Requiere dos nodos que estn fsicamente conectados, por ello los nodos
no pueden estar en ubicaciones fsicas diferentes. Eso es, en caso de un
desastre, se pierden ambos nodos.

Cluster es una solucin de alta disponibilidad, pero no es efectivo contra

recuperacin de desastres, a menos que est combinado con otros
acercamientos como backup/restore, discos mirroring, etc.

108

4. COMPARACIN DE SOLUCIONES DE ALTA

DISPONIBILIDAD DE BASE DE DATOS POR HARDWARE O
POR SOFTWARE

4.1. Comparacin de ventajas y desventajas de soluciones de alta

disponibilidad de base de datos por hardware y por software
Al llegar a este captulo, en el cual se mostrar un cuadro comparativo
sobre lo ms relevante de cada una de las soluciones descritas anteriormente,
siempre en el entorno de alta disponibilidad de bases de datos por hardware y
alta disponibilidad de bases de datos por software, se podr apreciar que no
todas las soluciones son exactamente adecuadas para un negocio en particular.
Esto depende de los requerimientos de cada negocio y por ello no se puede
decir que tal solucin es ptima para una organizacin; por otro, lado las
organizaciones debern tener presupuestada la cantidad de dinero para invertir
en una solucin en particular o una combinacin de unas con otras, todo con el
nico propsito de reducir ese tiempo fuera de servicio que a ninguna entidad le
gustara experimentar en la actualidad, en la que la mayora de negocios gira
en torno a la tecnologa de informacin. Los clientes no estn dispuestos a
perder acceso a la informacin tan vital de los negocios ni mucho menos a la
prdida total de los datos en el caso de un desastre, ello conlleva que se tendr
que hacer una mayor inversin al hacer cualquier tipo de combinacin de
soluciones, cuyo nico fin, es el de alcanzar ese porcentaje de cinco nueves,
con el respaldo de que su informacin y que sus clientes no experimenten
ningn tipo de fallo o destruccin total de la localidad en cuanto al
almacenamiento y manejo de la informacin se refiera.
109

Por lo tanto, no se puede concluir cul es la mejor solucin y es por ello

que a continuacin se har un anlisis de sus caractersticas ms relevantes.

Tabla VII. Comparacin de las caractersticas mas relevantes de las

soluciones mencionadas
Oracle Data
Guard

Oracle Real
Application
Clusters
Transparent
Application
Failover

Shareplex
para Oracle

SQL Server
2000 Cluster

RAID 0

RAID 1

RAID 5

RAID 0 + 1

Failover
Manual o
Automtico1

Failover
Automtico

Automtico

Automtico

Automtico

Automtico

Mecanismo
de Failover

Switchover y
Failover

Recuperacin
a Desastre

Si

Si

Si

No

No

No

No

No

Escalabilidad

No

Si

Si2

Si

Si3

Si

Si

Si

Disponibilidad

Si

Si

Si

Si

No

Si

Si

Si

Confiabilidad

Si

Si

Si

Si

Si

Si

Si

Si

Versin de la
base de datos

Igual

Igual

Igual o
Diferente

Igual

No
Aplica

No
aplica

No
aplica

No aplica

Ubicacin de
la base de
datos
fsicamente
distinta entre
el origen y
destino

Local o
Remota

Local

Local o
Remota

Local

Local

Local

Local

Local

Costo4

Bajo a
Regular

Regular a
Alto

Regular a
Alto

Regular

Bajo

Bajo

Bajo

Bajo

SharePlex conjuntamente con hardware y software de terceros, puede tener Failover

Automtico, balance de carga completa.

2

SharePlex si ofrece Escalabilidad ya que puede replicarse a mas de un servidor,

aumentando la capacidad de procesamiento.

3

Si, pero es limitado al chsis del arreglo de discos. Igual a los dems niveles de RAID.

La fila de costo (aproximado solo la base de datos), esta se estara clasificando entre

los siguientes rangos, equivalentes a Bajo <= $40,000, Regular = $80,000, Alto = > $120,000.

110

Por la parte de soluciones basadas en hardware se debe tomar en cuenta

que para stas es mejor utilizar controladoras redundantes, las cuales pueden
costar entre $1,000 y $2,500 por controladora, a esto hay que sumarle los
discos pero estos permanecen adjuntos al servidor. Por otro lado, si se obtiene
un arreglo pequeo externo al servidor ste puede ir alrededor de los $8,000 y
aun mayor a esa cantidad, sin incluir los discos.
El rendimiento de las soluciones de alta disponibilidad de base de datos
no fue incluido en la tabla anterior ya que depende de una serie de factores que
estn ms all del alcance de la base de datos y los cuales dependen no solo
de la base de datos, sino a eso hay que agregarle el rendimiento del sistema
operativo, del servidor y cada uno de sus componentes internos, el
almacenamiento ya sea compartido o no, las conexiones de red, etc.
La tabla que se muestra a continuacin presenta los precios de las bases
de datos relacionales Oracle 9i Enterprise Edition y SQL Server 2000 por
procesador.
Tabla VIII. Precios de lista de las bases de datos relacionales utilizadas en
el presente trabajo
Nmero de CPU

Oracle 9i Enterprise Edition

SQL Server 2000 Enterprise Edition

$40,000

$19,999

$80,000

$39,998

$160,000

$79,996

$320,000

$159,992

16

$640,000

$319,984

32

$1,280,000

$639,968

sta no es una comparacin total de precios entre SQL Server 2000 y

Oracle 9i. Es slo una comparacin corta de sus precios.
111

Se pueden tener descuentos y los precios pueden ser incrementados o

decrementados en el futuro. Para obtener ms informacin es necesario ver en
los sitios respectivos de las casas proveedoras.
Para ver el costo de esas soluciones, en este trabajo solo se tomar en
cuenta el valor de la licencia de la base de datos, la cual puede ser por medio
de procesador o por el nmero de usuarios que usarn la base de datos; por lo
tanto, planteare unos escenarios en los cuales se podr determinar el costo
aproximado sobre la base de datos, mas no exacto ya que a esto se debe
sumar todos esos componentes redundantes, sistema operativo y el
almacenamiento que son de vital importancia.
Por ejemplo, el primer escenario al querer implementar una solucin
basada en clusters con dos servidores (nodos) y cada nodo con dos
procesadores y acceso a una base de datos compartida, al implementarla por
medio de la base de datos SQL Server 2000, si se toma la licencia por
procesador est casi en los $19,999 pero como son cuatro procesadores eso
quiere decir que se multiplica esa cantidad por 4 con lo cual esta solucin
costara $79,996 por ao en un ambiente basado en Windows. Cabe resaltar
que stas cantidades son solo para la base de datos relacional y a esto hay que
agregarle

el

costo

de

los

servidores,

ms

UPS

redundantes,

ms

almacenamiento, etc., esto no lo tomo en consideracin en el presente trabajo.

Por otro lado, si en el mismo escenario se implementa la misma solucin
solo que utilizando la base de datos Oracle 9i, el valor por procesador es de
$40,000.00 por ao y debido a que son cuatro procesadores, eso equivale a la
suma de $160,000.00; slo el valor de la licencia por procesador con el cual no
hay lmite a el nmero de usuarios que accedan a esa base de datos
compartida.
112

Otro escenario sera implementar una solucin de bases de datos basada

en software que estn fsicamente separadas y se hara bajo la base de datos
Oracle 9i, ya que Oracle cobra por cada base de datos no importando si est
activa o en espera.

Con una base de datos primaria y una base de datos

standby el precio sera de $80,000 si se tomara la licencia por procesador

durante el primer ao para esas dos bases de datos; para proporcionar
recuperacin a desastre las mismas deberan estar fsicamente localizadas en
lugares distantes.
Es importante aclarar que los costos de los escenarios anteriormente
descritos corresponden solo al primer ao y al culminar ese ao se debe pagar
el 20% de la cantidad, lo cual disminuye considerablemente pero esto puede
ser variable y aplica en la base de datos Oracle.
Con esta informacin se puede tener una idea de costo aproximado y las
caractersticas ms importantes para cada una de las soluciones expuestas en
el presente trabajo; siempre recordando que la alta disponibilidad implica
redundancia respecto a todos los componentes que puedan hacer que sta falle
o sea destruida en casos extremos, pero reales.

113

114

CONCLUSIONES

1. La clave de la alta disponibilidad de base de datos es la redundancia que

permite mantener los datos en ms de un lugar, con lo cual se logra en
un momento dado la recuperacin a un desastre.
2. El tiempo fuera de servicio o downtime es categorizado como planeado y
no planeado; indistintamente cual de los dos ocurra, debe ser minimizado
para evitar cualquier rompimiento en el servicio, lo que implicara
prdidas.
3. Los clusters son usados para ocultar las fallas en los nodos del sistema,
sin dejar de prestar el servicio a los usuarios de las bases de datos y
permiten distribuir la carga de trabajo, proporcionando un buen
rendimiento en cualquier momento; adems, permiten agregar nodos, lo
cual los hace sobresalir en sus principales ventajas que son la
disponibilidad y la escalabilidad.
4. La replicacin es una solucin de software que permite tener copias de la
base de datos en produccin en ms de un lugar, ya sea una ubicacin
local o remota; estas copias actualizadas de las bases de datos de
produccin pueden ser usadas para reportes, consultas, backups y en
casos de emergencia cuando el sistema de produccin haya fallado o
est sea totalmente destruido.

115

5. Las soluciones de alta disponibilidad de bases de datos por hardware o

por software, al combinarlas proporcionan un mejor resultado.
6. La solucin de alta disponibilidad de base de datos por software Oracle
Data Guard proporciona recuperacin a desastres, si la base de datos
est en una localidad remota; proporciona disponibilidad si se produce
una falla en la base de datos primaria, o bien cuando se necesite
operaciones de mantenimiento, permitiendo cambiar entre bases de
datos primaria y standby.
7. La solucin de alta disponibilidad de base de datos por software Oracle
Real Application Clusters proporciona disponibilidad y escalabilidad
debido a que est basad en clusters; proporciona recuperacin a
desastres si los nodos de la misma se encuentran a gran distancia entre
ellos.
8. La solucin de alta disponibilidad de base de datos por software
Shareplex

para

Oracle

proporciona

recuperacin

desastres,

manteniendo una base de datos en un lugar remoto constantemente

actualizado por medio de la replicacin, proporciona escalabilidad y
disponibilidad ya que puede replicarse a ms de un servidor.
9. La solucin de alta disponibilidad de base de datos por software SQL
Server 2000 cluster proporciona disponibilidad y escalabilidad, debido a
que usa tecnologa de clusters y proporciona un buen rendimiento. No
proporciona recuperacin a desastres, ya que los nodos residen en el
mismo lugar.

116

10. La solucin de alta disponibilidad de base de datos por hardware llamada

RAID local, proporciona disponibilidad a travs de distintos niveles de
redundancia en los arreglos de discos, con lo cual se evita la prdida de
los datos si uno o ms discos llegan a fallar; proporciona escalabilidad, la
cual est limitada al chsis del arreglo de discos pero no proporciona
recuperacin a un desastre local.
11. La opcin de almacenamiento SAN proporciona recuperacin a desastre,
si los sitios estn copiados idnticamente y localizados a una distancia
segura, debido a su tecnologa de canal de fibra para proteger y distribuir
datos; ofrece escalabilidad agregando almacenamiento, sin tener tiempo
fuera de servicio; reduce el trfico en la red primaria.
12. La opcin de almacenamiento NAS comparte archivos a travs de una
red de rea local; mejora el rendimiento, descargando el servicio de
archivo proporcionado por el servidor.

117

118

RECOMENDACIONES

1. Antes de implementar una solucin se necesita determinar si satisface las

necesidades de un negocio tales como la continuidad del servicio, costo,
requerimientos, etc.
2. Se recomienda ver el modo de las configuraciones disponibles para cada
una de las diversas soluciones mencionadas.
3. Es importante resaltar que la redundancia es un punto clave en la
implementacin de las soluciones de alta disponibilidad de base de datos,
por lo cual se debe tener en cuenta que la base de datos son solo un
componente para alcanzar esa disponibilidad de los sistemas; por lo tanto,
es necesario consultar otras fuentes sobre los dems componentes como
las fuentes de energa redundantes, sistemas de ventilacin de los
ambientes, etc., para lograr la alta disponibilidad.

119

120

BIBLIOGRAFA
1.

Adding Instances and Nodes.

http://technet.oracle.com/doc/windows/server.804/a55925/chap8.htm
Estados Unidos: 06/08/2002

2.

Administering mltiple Instances.

http://technet.oracle.com/doc/windows/server.804/a55925/chap7.htm
Estados Unidos: 06/08/2002

3.

Alta disponibilidad.
http://www.logica.cl /soluciones_de_integracin_TI.htm
Chile: 16/02/2002

4.

Alta disponibilidad.
http://www.enlace.cl/empresa/anexos/alta_disponibilidad.pdf
Chile: 16/02/2002

5.

Backing Up and Recovering an Oracle Parallel Server Database.

http://technet.oracle.com/doc/windows/server.804/a55925/chap9.htm
Estados Unidos: 06/08/2002

6.

Backup de recuperacin.
http://otn.oracle.com/deploy/availability/pdf/backup_recovery_twp
Estados Unidos: 06/08/2002

7.

Basic RAID Organizations.

http://www.ecs.umass.edu/ece/koren/architecture/Raid/raidhome
Estados Unidos: 02/06/2005

8.

Before you begin.

http://technet.oracle.com/doc/windows/server.804/a55925/preface
Estados Unidos: 06/08/2002

121

9.

Configuring Oracle Parallel Server.

http://technet.oracle.com/doc/windows/server.804/a55925/chap5.htm
Estados Unidos: 06/08/2002

10. Costs and Benefits for High Availability Oracle9i.

http://www.dba-oracle.com/art_dbazine_high_avail.htm
Estados Unidos: 16/08/2004
11. Glossary.
http://technet.oracle.com/doc/windows/server.804/a55925/glos.htm
Estados Unidos: 06/08/2002
12. High Availability Oracle 8i listing.
http://otn.oracle.com/deploy/availability/htdocs/ha8i_listing.html
Estados Unidos: 02/08/2002
13. High Availability Solutions.
http://www.pafumi.net/replication/High_Availability_Solutions.html
Estados Unidos: 29/05/2005
14. High Availability.
http://www.tpc.org/information/other/articles/ha.asp
Estados unidos: 16/02/2002
15. High Available databases.
http://www.firstsql.com/highavailability.html
Estados Unidos: 11/05/2005
16. Installing and configuring Oracle Parallel Server Manager.
http://technet.oracle.com/doc/windows/server.804/a55925/chap6.htm
Estados Unidos: 06/08/2002
17. Installing Oracle Parallel Server.
http://technet.oracle.com/doc/windows/server.804/a55925/chap4.htm
Estados Unidos: 06/08/2002
122

18. Introduccin a Oracle 8i.

http://technet.oracle.com/doc/oracle8i_816/paraserv.816/a76968/psin
tro.htm Estados Unidos: 02/08/2002
19. Introduction to OPS.
http://technet.oracle.com/doc/windows/server.804/a55925/chap1.htm
Estados Unidos: 06/08/2002
20. Introduction to storage area network.
http://is.pennnet.com/articles/introsan.cfm
Estados Unidos: 20/05/2005
21. NAS and SAN cost considerations.
http://is.pennnet.com/articles/nassancost.cfm
Estados Unidos: 20/05/2005
22. NAS y SAN similarities and differences.
http://is.pennnet.com/articles/nassan.cfm
Estados Unidos: 20/05/2005
23. No data loss standby.
http://otn.oracle.com/deploy/availability/pdf/no_data_loss_sb.pdf
Estados Unidos: 02/08/2002
24. Oracle 8i High Availability.
http://www.jeffreyhazelwood.com/Oracle8iHA.pdf
Estados Unidos: 11/05/2005
25. Oracle 9i deployment and performance.
http://downloadeast.oracle.com/docs/cd/B10501_01/rac.920/a96598.pdf
Estados unidos: 26/10/2004

123

26. Oracle 9i Instalation.

http://download-east.oracle.com/docs/pdf/A95493_01.pdf
Estados Unidos: 26/10/2004
27. Oracle Parallel Server Architecture.
http://technet.oracle.com/doc/windows/server.804/a55925/chap3.htm
Estados Unidos: 06/08/2002
28. Oracle Prices.
http://www.oracle.com/corporate/pricing/pricelists.html
Estados Unidos: 02/06/2005
29. Oracle9i Database Concepts.
http://downloadeast.oracle.com/docs/cd/B10501_01/server.920/a96524.pdf
Estados Unidos: 26/10/2004
30. Parallel Fail Safe.
http://otn.oracle.com/deploy/availability/pdf/PFS_TWP_53.pdf
Estados Unidos: 02/08/2002
31. Parallel Hardware Architecture.
http://technet.oracle.com/doc/windows/server.804/a55925/chap2.htm
Estados Unidos: 06/08/2002
32. Performing Oracle and SQL Server database recovery.
http://is.pennnet.com/articles/databaseperf.cfm
Estados Unidos: 20/05/2005
33. Pre-Installation Tasks for Installing RAC on hp Tru64 UNIX-Based
Systems.
http://downloadeast.oracle.com/docs/html/B10766_05/pretru64.htm#sthref1641
Estados Unidos: 30/09/2004

124

34. Qu es Raid?
http://www.raidweb.com/whatis.html
Estados Unidos: 30/05/2005
35. Raid Definitions.
http://linux.cudeso.be/raid.php
Estados Unidos: 29/05/2005
36. RAID White Paper.
http://www.attotech.com/diamond/pdf/RAIDWhitePaper.pdf
Estados Unidos: 02/06/2005
37. RAID.
http://rk.8m.com/cgi-bin/i/PIC/raid.htm
Estados Unidos:02/06/2005
38. Read only standby database.
http://www.dbatoolbox.com/WP2001/hastandby/Readonly_standby_database.pdf
Estados Unidos: 19/08/2002
39. Real Application Clusters Concepts.
http://downloadeast.oracle.com/docs/cd/B10501_01/rac.920/a96597.pdf
Estados Unidos: 26/10/2004
40. Replicado de datos en tiempo real bajo Linux.
http://www.linuxfocus.orgt/castellano/march2001/article199.htm
Estados Unidos: 16/02/2002
41. SAN vs. NAS.
http://www.infrastor.com/downloads/papers/sanvsnas.pdf
Estados Unidos: 19/08/2002

125

42. SAN y NAS.

http://www.nas-san.com/differ.html
Estados Unidos: 19/08/2002
43. Shareplex for Oracle.
http://www.quest.com/SharePlex
Estados Unidos: 16/02/2002
44. Sistemas de alta disponibilidad bajo linux.
http://www.linuxfocus.orgt/castellano/november2000/article179.htm
Estados Unidos: 16/02/2002
45. Sistemas de alta disponibilidad.
http://www.optimat.com/soluciones/altadisponibilidad.html
Espaa: 16/02/2002
46. SQL Server 2000 clustering Intro 2.
http://www.sql-server-performance.com/clustering_intro2.asp
Estados Unidos: 29/05/2005
47. SQL Server 2000 clustering Intro.
http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/ssmsa
m.mspx Estados Unidos: 29/05/2005
48. SQL Server product overview.
http://databases.about.com/od/sqlserver/a/sqlserver2k.htm
Estados Unidos: 30/05/2005
49. SQL Server versus Oracle 9i.
http://www.mssqlcity.com/Articles/Compare/sql_server_vs_oracle.ht
m Estados Unidos: 10/06/2005
50. SQL Server.
http://www.microsoft.com/sql/evaluation/overview/default.mspx
Estados Unidos: 30/05/2005
126

51. Standby Concepts.

http://downloadeast.oracle.com/docs/cd/A87860_01/doc/server.817/a76995.pdf
Estados Unidos: 26/10/2004
52. Standby Database Concepts
http://fncduh1.fnal.gov/oracledoc/v8.1.7/DOC/server.817/a76995/stan
dbyc.htm#25080 Estados Unidos: 19/08/2002
53. Understanding the Real Application Clusters Installed Configuration
http://download-east.oracle.com/docs/html/B10766_05/undrstnd.htm
Estados Unidos: 30/09/2004
54. White paper Building 24 x 7 database.
http://www.quest.com/building_wp.pdf
Estados unidos: 16/02/2002

127