Sistemas de Bases de Datos Distribuidas

Informe:

Confiabilidad y Recuperacin en Sistemas de Bases de Datos Distribuidas

ndice de Contenido
NDICE DE CONTENIDO ................................................................................................................................................. 2 1 CONFIABILIDAD EN SMBDD ......................................................................................................................................... 3 1.1 Sistema, Estado y Falla ...................................................................................................................................... 3 1.2 Confiabilidad, Disponibilidad y medidas ........................................................................................................... 5
1.2.1 Tiempo medio entre fallas y Tiempo medio de reparacin ...................................................................................... 6 Tcnica de prevencin de fallas ................................................................................................................................ 7 Tcnica de tolerancia a fallas .................................................................................................................................... 7

1.3 2

Tcnicas para el tratamiento de fallas .............................................................................................................. 7

1.3.1 1.3.2

CASO DE ESTUDIO ORACLE ............................................................................................................................................ 8 2.1 Oracle en Base de datos distribuidas homogneas ........................................................................................... 8
2.1.1 Confiabilidad en SBDD Homogneos (Oracle con Oracle) ...................................................................................... 9 Confiabilidad en SBDD Heterogneos (Oracle con no-Oracle) .............................................................................. 14

2.2

Oracle en Base de datos distribuidas heterogneas ....................................................................................... 12

2.2.1

CONCLUSIN .............................................................................................................................................................. 15 BIBLIOGRAFA ............................................................................................................................................................ 16

Pg. 2

1 Confiabilidad en SMBDD
En los Sistemas de Bases de Datos Distribuidas la confiabilidad es un aspecto muy importante que debe ser tomado muy en cuenta en todas las etapas desde su planeacin y diseo hasta su implantacin y evolucin, pero a su vez es muy difcil de mantener por diversas razones. Se puede decir que un Sistema Manejador de Bases de Datos confiable es aquel que puede continuar atendiendo correctamente los procesos requeridos por los usuarios incluso ante cualquier falla que se pueda presentar en alguno de sus componentes, es decir que el sistema puede continuar atendiendo dicho requerimiento del usuario despus de presentarse una falla sin comprometer la consistencia de la BD, por lo que la confiabilidad tiene mucho que ver con mantener las propiedades de atomicidad y durabilidad de las transacciones que realiza. 1.1 Sistema, Estado y Falla Un sistema se refiere a un mecanismo que consiste de una coleccin de componentes y sus interacciones con el medio ambiente que responden a estmulos que provienen del mismo con un patrn de comportamiento vlido reconocible, como lo podemos ver en la siguiente figura:

Figura 1 Estructura y conceptos bsicos de un sistema

Por lo general los sistemas complejos estn conformados por varios componentes que dada tambin su complejidad pueden ser vistos internamente como sub-sistemas. El sistema al igual que los subsistemas que lo componen tiene un determinado estado el cual cambia a medida que el sistema opera. El comportamiento del sistema el cual debe ser el de proveer respuesta a todos los requerimientos externos, es definido en su especificacin segn su propsito. La especificacin muestra el comportamiento vlido deseado de cada estado del sistema. Un estado externo de un sistema se puede definir como la respuesta que un sistema proporciona a un estmulo externo. Por lo tanto, es posible hablar de un sistema que se mueve dentro de estados externos de acuerdo a un estmulo proveniente del medio ambiente. Un estado interno es, por lo tanto, la respuesta del sistema a un estmulo interno. Desde el punto de vista de confiabilidad, es conveniente definir a un estado interno como la unin de todos los estados externos de las componentes que constituyen el sistema. As, el cambio de estado interno se da como respuesta a los estmulos del medio ambiente. El comportamiento del sistema al responder a cualquier estmulo del medio ambiente necesita establecerse por medio de una especificacin, la cual indica el comportamiento vlido de cada estado del sistema. Su especificacin es no slo necesaria para un buen diseo sino tambin es esencial para definir los siguientes conceptos de confiabilidad. En un sistema confiable los cambios van de estados vlidos a estados vlidos. Sin embargo, en un sistema no confiable, es posible que el sistema caiga en un estado interno el cual no obedece a su

Pg. 3

especificacin; a este tipo de estados se les conoce como estados errneos. Transiciones a partir de este estado pueden causar una falla. La parte del estado interno que es incorrecta se le conoce como error del sistema. Cualquier error en los estados internos de las componentes del sistema se le conoce como una falta en el sistema. As, una falta causa un error lo que puede inducir una falla del sistema, tal como se muestra en la siguiente figura:

Figura 2 Cadena de eventos que conducen a una falla del sistema

Las faltas del sistema se pueden clasificar como severas (hard) y no severas (soft). Las faltas severas casi siempre son de tipo permanente y representan el 90% de las fallas. Las faltas no severas por lo general son transitorias o intermitentes. Una falta permanente es aquella que refleja un cambio irreversible en el comportamiento del sistema. Las faltas permanentes causan errores permanentes que resultan en fallas permanentes. Las caractersticas de estas fallas es que la recuperacin de las mismas requiere intervencin para reparar la falta. Entre las faltas no severas (soft) tenemos las faltas intermitentes y transitorias. Una falta intermitente se refiere a faltas que se presentan ocasionalmente debido a hardware inestable, a variacin del hardware o de los estados del software. Un ejemplo tpico es el de los faltas que los sistemas pueden tener cuando la carga llega a ser demasiado pesada. Por otro lado, una falta transitoria describe una falta que resulta de las condiciones ambientales temporales. Una falta podra ocurrir, por ejemplo, debido a un incremento repentino en la temperatura en la habitacin. La falta transitoria es por lo tanto el resultado de las condiciones ambientales que pueden ser imposibles de reparar. Una falta intermitente, por otro lado, puede ser reparada, ya que puede ser rastreada y asociado a un componente del sistema. Las fallas de sistema pueden ser atribuibles a faltas o defectos de diseo, a la inestabilidad del hardware causan errores intermitentes que resultan en fallas del sistema, aunque tambin los errores del operador son fuentes de un nmero significativo de errores La relacin entre los diferentes tipos de faltas y errores se representa en la siguiente figura:

Figura 3 Fuentes de la falla de un sistema

Pg. 4

1.2 Confiabilidad, Disponibilidad y medidas La confiabilidad se puede interpretar de varias formas. La confiabilidad se puede ver como una medida con la cual un sistema conforma su comportamiento a alguna especificacin. Tambin se puede interpretar como la probabilidad de que un sistema no haya experimentado ninguna falla dentro de un periodo de tiempo dado. La confiabilidad se utiliza tpicamente como un criterio para describir sistemas que no pueden ser reparados o donde la operacin continua del sistema es crtica. Una forma de medir esto es que podemos asumir que los fallos siguen una distribucin de Poisson (esto es usual en el caso del hardware), as tenemos:

= 0 0,
Para obtener que:

P k fallas en el intervalo de tiempo 0, =

( ) ()

k!

Donde:

=
0

Aqu es conocida como la funcin de riesgo (hazard function) que nos da la tasa de falla dependiente del tiempo del componente de hardware en consideracin. La distribucin de probabilidad para puede ser diferente para distintos componentes electrnicos. La esperanza (media) nmeros de fallos en el tiempo 0, puede ser calculada como:

E =
= 0

( ) ()

k!

y la varianza:

Var = E 2 [ ( )]2 = ()
Dados estos valores, puede ser escrito como:

= ( )
Note que la ecuacin de confiabilidad anterior es aplicada para un componente del sistema. Para un sistema que consta de n componentes no-redundantes (todos tienen que funcionar apropiadamente para que el sistema funcione) cuyas fallas son independientes, la confiabilidad total del sistema puede ser escrita como:

Pg. 5

=
= 1

()

La disponibilidad , se refiere a la probabilidad de que el sistema est operacional de acuerdo a su especificacin en un momento particular t. Varios fallos pueden haber ocurrido previos a el tiempo t, pero si los mismos han sido reparados, el sistema est disponible en el tiempo t. Obviamente, la disponibilidad se refiere a sistemas que pueden ser reparados y que tambin pueden estar fuera de servicio durante la reparacin. La Confiabilidad y la Disponibilidad de un sistema son consideradas a ser objetivos contradictorios. Por lo general se acepta que es ms fcil de desarrollar sistemas de alta disponibilidad que sistemas de alta confiabilidad. Podemos medir la disponibilidad si asumimos que las fallas siguen una distribucin tipo Poisson con una tasa de falla , y que el tiempo de reparacin es exponencial con un tiempo medio de reparacin de 1 , la disponibilidad de un sistema en estado estable se puede escribir como:

1.2.1 Tiempo medio entre fallas y Tiempo medio de reparacin

Hay dos simples parmetros de medida que se han hecho ms populares que las funciones de confiabilidad y disponibilidad vistas anteriormente, para modelar el comportamiento de los sistemas. Estas dos medidas son el tiempo medio entre fallas (TMEF mean time between failures MTBF en ingls) y el tiempo medio de reparacin (TMR mean time to repair MTTR en ingls). El TMEF es el tiempo esperado entre fallos consecutivos en un sistema con reparacin. El TMEF puede calcularse a partir de datos empricos o de la funcin de confiabilidad como:

=
0

Puesto que est relacionada con la tasa de falla del sistema, hay una estrecha relacin entre TMEF y la tasa de fallos del sistema. El TMR es el tiempo esperado para reparar un sistema con fallas. Al igual que el TMEF est relacionado con la tasa de falla, el TMR se relaciona con la tasa de reparacin. Usando estos dos parmetros, la disponibilidad en estado estable de un sistema con falla exponencial y tasas de reparacin se puede especificar como:

A veces es hecha una distincin entre TMEF y TMAF (tiempo medio al fallar) es definido como el tiempo esperado de la primera falla dado un inicio correcto en el tiempo 0. El TMEF se define entonces slo para sistemas que pueden ser reparados. Una aproximacin para TMEF se da como:

= +
Los fallos del sistema pueden ser latentes, en el sentido de que una falla es usualmente detectada algn tiempo despus de su ocurrencia. Este periodo se denomina latencia del error, y el tiempo promedio de latencia del error sobre un nmero de sistemas idnticos se denomina tiempo medio de deteccin (TMD). La relacin de varias de estas medidas de confiabilidad con la ocurrencia de fallas la podemos ver en la siguiente figura:

Pg. 6

Figura 4 Fuentes de fallas de un sistema

1.3 Tcnicas para el tratamiento de fallas Para el tratamiento de fallas en los sistemas se han ideado tipos de tcnicas para su deteccin y tratamiento entre ellas tenemos las tcnicas de prevencin de fallas y las tcnicas de prevencin de fallas. 1.3.1 Tcnica de prevencin de fallas Tiene como base que en el sistema implementado no ocurrir ninguna falla. Se concentra en hacer un diseo con componentes altamente confiables y en someterlos a diferentes pruebas para irlos refinando. Se buscan todas las fallas antes del desarrollo antes de ser implementado, y si alguna falla surge se hace el mantenimiento manualmente. Slo cuenta con mecanismos que alertan la ocurrencia de una falla. 1.3.2 Tcnica de tolerancia a fallas Esta tcnica reconoce que las fallas pueden ocurrir, por lo que implementa mecanismos dentro del sistema que detectan y corrigen la falla. Para ello se valen de la redundancia de componentes y de la modularizacin, donde cada componente es un mdulo con interfaces bien definidas, con lo cual se asegura el aislamiento de la falla dentro de un componente. Un componente puede ser fail-stop process-pair, Un componente fail-stop, se monitorea constantemente y cuando se detecta una falla, se termina automticamente la operacin. Un componente process-pairs es un mdulo que se encuentra duplicado teniendo una rplica primaria y otra de backup, manteniendo entre ellas una constante comunicacin por pase de mensaje o memoria compartida.

Pg. 7

2 Caso de estudio Oracle

Oracle soporta una comunicacin entre bases de datos usando SQL y/o PL/SQL distribuido, manteniendo una ubicacin transparente y una integridad de la base de datos. Para satisfacer la necesidad de las aplicaciones en cuanto al acceso a sistemas no-Oracle ofrece los mecanismos de Transparent Gateways y un Generic Connectivity. A continuacin describiremos cmo Oracle se integra, interacta gestiona y colabora en mantener la confiabilidad y alta disponibilidad en los sistema de bases de datos distribuido homogneo (todos los nodos con SMBD Oracle sin importar que algunos tengan versiones diferentes de Oracle) y en los heterogneo (uno o ms nodos con SMBD Oracle junto con uno ms nodos con SMBD no- Oracle).

2.1 Oracle en Base de datos distribuidas homogneas Como dijimos en estos sistemas todos los nodos usan como SMBD Oracle sin importar si algunos o todos tienen versiones diferentes. Todos los nodos se conectan usando el software de conexin Oracle Net8, el cual permite a las bases de datos comunicarse a travs de redes para soportar transacciones distribuidas y remotas, como lo vemos en la siguiente figura:

Figura 5 Sistema de bases de datos distribuidas en Oracle

En dicho sistema Oracle puede incorporar nodos con diferentes versiones, esto no es problema ya que la instancia de cada nodo es capaz de adaptarse a las funcionalidades de las instancias de los dems nodos, el problema puede surgir a nivel de aplicaciones que accedan a estos nodos, las que deben conocer las extensiones SQL que puede admitir cada uno segn su versin. Igualmente, Oracle para manejar las conexiones usa el mecanismo de DB Links para as habilitar a los usuarios de una base de datos a poder acceder objetos contenidos en una base de datos remota. El DB Link es uni-direccional en el sentido de que un cliente conectado a una BD local A puede usar un link guardado en el diccionario de datos de la BD A para acceder a una BD remota B, pero los usuarios conectados a la BD B no pueden usar el mismo DB Link para acceder a la BD A; si as lo quiere debe definirse un DB Link en su diccionario para acceder a la BD A.

Pg. 8

Figura 7 DB Link en Oracle

2.1.1 Confiabilidad en SBDD Homogneos (Oracle con Oracle)

Oracle como SMBDD mantiene una alta confiabilidad y disponibilidad proporcionando mecanismos que garantizan la recuperacin automtica de transacciones distribuidas manteniendo la consistencia de la BD, agregando tambin opciones que permiten a los DBAs (Administradores de Bases de Datos) realizar esta tarea de forma manual para casos ms complejos. Igualmente cuenta con caractersticas avanzadas para recuperar la Data mediante Backups a nivel de cada nodo individual, as como a nivel global, tanto online como offline. Tambin brinda soporte para realizar y sincronizar replicas y continuidad de operacin en sustitucin de discos daados lo cual contribuye con una alta disponibilidad. En sistemas homogneo, Oracle asegura la atomicidad y con ello la consistencia en las transacciones distribuida que cada nodo pueda iniciar usando el protocolo de Commit de dos fases (Two-Phase Commi)t; este mecanismo es completamente transparente, no requiriendo programacin para lograr el mismo mecanismo alguna operacin especial para proveer control de transaccin distribuida. La sentencia COMMIT dispara el mecanismo de Commit de dos fases como vimos anteriormente. l proceso background RECO (recuperar) resuelve automticamente el resultado de estas transacciones distribuidas en las que se interrumpe el COMMIT, estas son las transacciones en duda (In-Doubt Transactions). El proceso RECO de cada Servidor Oracle local confirma o deshace automticamente cualquier transaccin distribuida en duda consistentemente en todos los nodos involucrados. Para fallos de larga duracin, Oracle permite a cada BD local confirmar o deshacer manualmente cualquier transaccin en duda y liberar los recursos. La consistencia global se puede mantener restaurando la BD en cada nodo retornando a un punto fijo predeterminado del pasado. En los sistemas heterogneos con Oracle, pueden usarse varias de sus tecnologas que ayudan a aumentar la confiabilidad y disponibilidad del mismo tales como: RAC (Real Application Clusters ): que permite a los nodos de un clster (conjuntos o conglomerados de servidores construidos mediante la utilizacin de hardwares comunes y que

Pg. 9

se comportan como si fuesen una nica computadora), acceder concurrentemente a la base de datos distribuida de forma ms efectiva y confiable por lo que se aumenta la disponibilidad y escalabilidad, adems se incluye que incluye TAF (Transparent Application Failover) la cual permite a los clientes de Oracle reconectarse a otra instancia en caso de que ocurriera una falla en la instancia (Nodo) a la cual se encontraba conectado. ASM (Automatic Storage Management) hace que la sustitucin o inclusin de discos en los nodos resulten transparentes para todo el sistema distribuido, ya que permite entre otras cosas aadir o quitar discos en caliente sin afectar el funcionamiento de la BD y hacer un rebalanceo automtico del almacenamiento en el grupo de discos. Adems hace remirroring automtico cuando un disco falla, en Oracle 11g puede reparar los datos corruptos desde el mirror de forma automtica, adems puede hacer una resincronizacin rpida de la rplica al recuperarse de un error (utiliza nicamente los bloques cambiados).

Figura 8 Inclusin de un nuevo disco online

Figura 9 Sustitucin de un disco daado online

Flashback el cual permite realizar recuperacin a todos los niveles, de forma automtica y ms efectiva y rpida que con los backups, sobretodo en errores causados por los operadores o usuarios sobre la data como por ejemplo borrar la orden errnea, bacht job elimin las rdenes del mes. Puede realizar una recuperacin a nivel de: o o A nivel de la BD completa (usando los Flashback Logs). A nivel de tabla para restaurar filas a un conjunto de tablas trabaja conjuntamente con el UNDO en la BD. Con Flashback Drop recupera una tabla o ndice borrados.

Pg. 10

A nivel de fila, usa Flashback Query para restaurando registros individuales.

Igualmente cuenta con Flashback Data Archive que gestiona automticamente la retencin de la BD a largo plazo-aos, muy til para mantener historiales de cambios a largo plazo en la data y auditorias. Oracle tambin permite a los DBAs resolver transacciones en duda de forma manual en casos como: La transaccin en duda tiene bloqueada data crtica o un segmento a deshacer (UNDO). L a causa del fallo de la mquina, la red o el software no se pueden resolver rpidamente. Si una de las bases de datos participantes se pierde por completo.

Para ello el DBA debe: Conocer los datos y situacin actual en cada BD participante. Utiliza Vistas del Diccionario: o o DBA_2PC_PENDING based on pending_trans$ DBA_2PC_NEIGHBORS based on ps1$ & pss1$

Puede requerir extraccin manual del Diccionario de datos.

Figura 8 Transaccin en duda, note el ID del error

Figura 9 Usando el ID del error se consulta la vista DBA_2PC_PENDING En el caso de recuperacin por backups Oracle ofrece distintas formas de backup y recuperacin, dependiendo que la BD trabaje en modo archivelog o noarchivelog, permitiendo hacer recuperacin local y/o a nivel distribuido. Dependiendo del tipo de operacin de recuperacin seleccionada para una BD daada, se puede tener que coordinar la operacin de recuperacin globalmente entre todas las BD de un sistema distribuido. En caso de noarchivelog la nica estrategia valida es bajar la BD y realizar un backup offline, y en caso de recuperacin se pierden los cambios entre el backup y el momento de la falla. La ventaja de este mtodo es que es fcil de usar. En caso de estar trabajando con bases de datos distribuidas, los backups deben estar coordinados, as mismo como la recuperacin. Si no podemos darnos el lujo de bajar la base para realizar backups, o no podemos permitir perder informacin ante una falla, entonces tenemos que trabajar en modo archivelog. Este modo de la base nos permite realizar backups online y recuperar la base hasta el momento de la falla En la siguiente tabla se resumen diferentes tipos de recuperacin y si es necesaria o no la coordinacin entre los distintos nodos de un ambiente distribuido:

Pg. 11

Si se est...... Recuperando un backup completo (full offline backup) de una base que nunca fue accedida desde un nodo remoto Recuperando un backup completo (full offline backup) de una base que fue accedida desde un nodo remoto Realizando recuperacin completa de una o mas bases en un sistema distribuido Realizando recuperacin incompleta de una base de datos que nunca fue accedida desde un nodo remoto Realizando recuperacin incompleta de un nodo que fue accedido por un nodo remoto

Entonces..... Usar recuperacin no coordinada

Bajar todas las bases y recuperarlas utilizando el mismo backup completo coordinado Usar recuperacin no coordinada Usar recuperacin no coordinada

Usar recuperacin incompleta coordinada de bases de datos distribuidas, al mismo punto global de tiempo para todos los nodos del ambiente distribuido

Los datos de un SBDD Oracle se pueden replicar utilizando instantneas (snapshots) o tablas principales replicadas. La replicacin se proporciona en los siguientes niveles: Replicacin bsica: las replicas de tablas se gestionan para accesos de solo lectura. para modificaciones, se debera acceder a los datos del sitio primario. Replicacin avanzada (simtrica): es una extensin sobre la replicacin bsica, que permite a las aplicaciones que modifiquen replicas de tablas por todo un SBDD replicado. Los datos se pueden leer y modificar en cualquier sitio. Esto requiere un software adicional llamado opcin de replicacin avanzada de Oracle. Una instantnea genera una copia de parte de la tabla por medio de una consulta llamada consulta de definicin de la instantnea Una definicin simple de una instantnea sera la siguiente:

Figura 10 Creacin de la replicacin

2.2 Oracle en Base de datos distribuidas heterogneas En SBDD heterogneas, Oracle ofrece dos soluciones para la conectividad en una Base de Datos distribuida heterognea que son: Generic Connecivity y Oracle Transparent Gateways. Ambas soluciones proveen la habilidad de un acceso transparente a la informacin en sistemas no-Oracle, desde un ambiente Oracle. Los usuarios podrn entonces crear sinnimos Oracle para objetos de un ambiente no-Oracle y hacer referencia a los mismos sin tener que especificar la ubicacin fsica de cada objeto. En vez de requerir que las aplicaciones interoperen con sistemas no-Oracle usando sus interfaces nativas, las aplicaciones pueden ser construidas a travs de una interfaz Oracle para sistemas Oracle y no-Oracle. Pero, para lograr estar interoperabilidad entre sistemas distintos (Oracle y no-Oracle), que implica transacciones SQL, traducciones de diccionario de datos y traslaciones de tipos de datos sern requeridas dichas soluciones, an si los sistemas no-Oracle son basados en estndares SQL. Para

Pg. 12

alcanzar este objetivo es que Generic Connectivity y los Transparent Gateways de Oracle tienen la habilidad para traducir el dialecto de un sistema en el del otro. Esta tecnologa est compuesta de dos partes: una componente genrica que conecta a un sistema noOracle, que es comn a todos los sistemas no-Oracle, llamada Servicios Heterogeneos y una componente que es especfica a cada Manejador de Base de Datos, llamado Agente. Un Agente es un proceso a travs del cual un servidor Oracle se conecta a uno no-Oracle y tiene dos componentes: Cdigo Genrico y un Driver especfico a cada sistema no-Oracle. La razn de existencia del Agente es primeramente debida a la necesidad de una separacin del servidor de la BD Oracle del cdigo de terceras partes. De manera de que si queremos que un proceso acceda a un sistema noOracle, las libreras del cliente del sistema no-Oracle tienen que ser asociadas dentro del Agente. Sin la existencia de este Agente, las bibliotecas deberan tener directamente que ser asociadas al servidor de la Base de Datos y problemas de cdigos podran causar que el Servidor de Oracle cayera. De esta manera, la propuesta de la existencia del Agente provocara en el caso de la aparicin de un problema de cdigo, que caiga solo el Agente.

Figura 11 Arquitectura para la conectividad Oracle con no-Oracle

Entonces, los Servicios Heterogneos junto al Agente hacen posible el acceso transparente al sistemas no-Oracle desde un ambiente Oracle. Generic Connectivity soporta solo los protocolos ODBC o OLE DB para acceder a un sistema noOracle, o sea que el agente usa el driver ODBC o OLE DB. Mientras que Oracle Transparent Gateways usa un agente especfico a cada sistema no-Oracle. Por ejemplo, si se incluye una Base de Datos Sybase en un ambiente distribuido, luego se tiene que obtener un Oracle Transparent Gateway especfico a Sybase, de manera de que las Bases de Datos Oracle en el sistema pueda comunicarse con sta. Entonces con el driver indicado podra acceder tambin a sistemas DB2, Informix, Microsoft SQL Server, Ingres, Teradata, etc. Esto le brinda al usuario de los Transparent Gateways un poder mayor de integracin que el que se logra con Generic Connectivity mediante el uso de un driver ODBC u OLE DB. Otra limitacin que tiene Generic Connectivity es que no se pueden conectar varios Servidores de Bases de Datos a un mismo agente.

Pg. 13

Figura 11 Conectividad heterognea (Oracle con no-Oracle) 2.2.1 Confiabilidad en SBDD Heterogneos (Oracle con no-Oracle)

En SBDD heterogneas, Oracle soporta los estndares ms usados en la industria para trabajar en coordinacin con sistemas no-Oracle que estn presentes en los diferentes nodos, para ayudar a garantizar la confiabilidad y disponibilidad en todo el sistema distribuido. Es por ello que para garantizar la atomicidad de las transacciones soporta adems del protocolo Commit en dos fases, tambin cuenta con libreras como Oracle XA que implementa una interfaz que permite a las transacciones globales ser coordinadas por un Manejador de Transacciones (TM), en vez de ser coordinadas por el propio servidor de Oracle. Dicha librera soporta el protocolo Commit en una fase, esto con la idea de que pueda participar con sistemas que solo manejen dicho protocolo. En el caso de recuperacin por por backups si en nodos involucrados trabajan en modo ARCHIVELOG, entonces los backups en cada nodo pueden realizarse en forma autnoma, es decir, individualmente y sin coordinacin de hora. Por el contrario si trabajan en modo NOARCHIVELOG, entonces se debe realizar un backup consistente de las bases de datos en su totalidad, a la misma hora global, para planificar una recuperacin global de las bases de datos. Por ejemplo, si una BD en un nodo A ubicado en Los ngeles es recuperada por backup a la medianoche, la BD de un nodo B ubicado en Washington debe ser recuperada por backup al mismo tiempo, teniendo en cuenta las diferencias horarias, si las hubiera.

Pg. 14

Conclusin
Como hemos podido ver en este estudio, la confiabilidad unida a la disponibilidad, resultan ser aspectos muy importantes a tomar en los SMBDD, pero de especial forma su planteamiento terico desde el punto de vista general del sistema aplicables en la prctica tanto en sus conceptos y medidas ya que permite implementarlos de una manera ms inteligente y provechosa en la planeacin, diseo, implantacin y administracin de los mismos. Igualmente vimos los principales tipos de fallas que pueden afectar al sistema en sus distintos niveles, tales como: Fallas de transaccin, Falla del sistema, Falla en los medios y Fallas de comunicacin; junto a varios mecanismos para evitarlas y/o tratarlas siempre con la intencin de mantener la consistencia de los datos y la confiabilidad del sistema. Entre los principales mecanismos estn los protocolos Compromiso de Una Fase (C1F), Compromiso de Dos Fases (C2F) y Compromiso de Tres Fases (C3F) los cuales tratan de garantizar la atomicidad y durabilidad de las transacciones distribuidas aunque se produzcan fallos, esto con diferentes niveles de efectividad y complejidad. El protocolo C3F es el ms avanzado ya que tiene la ventaja de que se puede ejecutar sin bloqueo, es decir que los nodos pueden continuar trabajando sin esperar la recuperacin de algn nodo que haya fallado, lo cual favorece en gran medida la disponibilidad del sistema en general. Por otra parte hemos podido ver como muchos de estos conceptos se aplican en el SMBDD comercial Oracle, el cual es uno de los ms importantes de la industria, claro con sus particularidades y variantes, pero siempre con el propsito de garantizar la confiabilidad y la durabilidad en el sistema. Muchas de estas especificaciones y caractersticas se aprovechan al mximo en sistemas heterogneos (Oracle con Oracle), aunque en sistemas heterogneos (Oracle con no-Oracle) tambin se implementan en gran medida ya que en estos sistemas se debe conservar el principio de independencia con respecto al SMBD que se use en los distintos nodos, para ello en Qracle se implementan varios mecanismos como los Transparent Gateways y los Generic Connectivity que permiten la comunicacin y el uso de mecanismos y protocolos entre Oracle y otros SMBD para garantizar la confiablidad y disponibilidad de estos sistemas en buena forma.

Pg. 15

Bibliografa
zsu Tamar and Valduriez, P, Principles of Distributed Database Systems: Third Edition, DOI 10.1007/978-1-4419-8834-8_12, Springer Science+Business Media, LLC ao 2011 http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns003.htm http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns004.htm http://www.fing.edu.uy/inco/cursos/tagsi/Trabajos/2003/TAGSI03-TareaTecnSI-grupo11.pdf http://dbatrain.files.wordpress.com/2009/01/database-links-masterclass_2.pdf http://docs.oracle.com/cd/B28359_01/server.111/b31107.pdf http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm http://www.oracle.com/technetwork/products/clustering/overview/distributed-transactions-and-xa163941.pdf http://www.oracle.com/technetwork/products/clustering/overview/index.html

Pg. 16