jueves, 5 de noviembre de 2009

Tecnología Oracle Flashback

Cuando la gente autorizada comete errores, usted necesita las herramientas para corregir esos errores. Oracle Database 11g brinda una tecnología para la corrección de errores humanos denominada Flashback. Flashback que revoluciona la recuperación de datos. En el pasado, dañar una base de datos podría tardar minutos, pero varias horas en recuperarla. Con Flashback, el tiempo para corregir los errores es igual al tiempo que llevó cometer el error. También es extremadamente fácil de utilizar, y se puede utilizar un solo comando breve para recuperar toda la base de datos en lugar de seguir algún procedimiento complejo. Flashback ofrece una interface SQL para analizar y reparar rápidamente los errores humanos. Flashback brinda reparación y análisis de grano fino para el daño localizado – como cuando se elimina el pedido erróneo de un cliente. Flashback también permite la corrección de daños más generalizados, y lo hace con rapidez para evitar un largo tiempo de baja – como cuando se eliminan todas las órdenes del mes de un cliente. Flashback es exclusivo para Oracle Database y soporta la recuperación en todos los niveles, incluso las filas, transacciones, tablas, espacios de tabla y base de datos.

Flashback Query

Mediante el uso de Oracle Flashback Query, los administradores pueden consultar cualquier dato del pasado. Esta poderosa característica puede utilizarse para ver y reconstruir los datos corruptos que pueden haberse eliminando o cambiado involuntariamente.


Flashback Versions Query

Flashback Versions Query, similar a Flashback Query, es una característica que permite que los administradores consulten cualquier dato del pasado. La diferencia y el poder detrás de Flashback Versions Query es su capacidad de recuperar diferentes versiones de una fila a través de un intervalo de tiempo especificado.


Flashback Transaction
A menudo, es probable que haya una corrupción lógica en una transacción que puede cambiar los datos en múltiples filas o tablas. Flashback Transaction Query permite que un administrador vea todos los cambios realizados por una transacción específica.


Flashback Data Archive
Nuevo en Oracle Database 11g, constituye un mecanismo para almacenar versiones históricas de datos durante largos períodos.


Automáticamente administrado por Oracle, cada vez que se cambian los datos, se pone a disposición una copia de solo lectura de la versión original de los datos en Flashback Data Archive.


Flashback Database
Para restablecer toda una base de datos a un momento pasado, el método tradicional es restablecer la base de datos desde un backup RMAN y recuperar hasta el momento anterior al error. Como el tamaño de bases de datos está creciendo, puede tardar horas o incluso días restaurar toda una base de datos.


Flashback Table
Con frecuencia, la corrupción lógica es puesta en cuarentena en una o más tablas, no requiriendo así un restablecimiento de toda la base de datos. Flashback Table es la característica que permite al administrador recuperar una tabla, o un grupo de tablas, hasta un momento específico, con rapidez y facilidad.


Flashback Restore Points
En las descripciones y ejemplos anteriores de Flashback Database y Flashback Table, hemos utilizado el tiempo como criterio para nuestras operaciones de restablecimiento o flashback. En Oracle Database 10g versión 2, se ofrecían Flashback Restore Points (Puntos de Restauración Flashback) como medio para simplificar y acelerar la resolución de fallas en los datos. Un punto de restablecimiento es una etiqueta definida por el usuario que marca un momento específico en el que el administrador considera que la base de datos está en buen estado. Flashback Restore Points permite a los administradores remediar, más fácil y eficientemente, sus bases de datos en caso de actividades perjudiciales o inapropiadas.

Fuentes:

http://translate.google.com.pe/translate?hl=es&sl=en&u=http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm&ei=DhPzSs-1EI-n8AaFjq3qAQ&sa=X&oi=translate&ct=result&resnum=2&ved=0CA0Q7gEwAQ&prev=/search%3Fq%3DTecnolog%25C3%25ADa%2BOracle%2BFlashback%26hl%3Des%26lr%3D%26sa%3DG




Data guard

Oracle Data Guard es una facilidad de Alta Disponibilidad que se encuentra disponible en la versión Oracle Database Enterprise Edition y que pemite configurar uno o más ambientes de replicación que sirvan como contingencia en caso que el servidor de producción (servidor primario) de la configuración pierda su capacidad de servicio. La configuración de Oracle Dataguard se puede hacer de acuerdo a los objetivos que se tengan: MAXIMA DISPONIBILIDAD, MAXIMA PROTECCION, MAXIMO DESEMPEÑO. Cada una de estas opciones tiene ventajas y desventajas que deben ser pesadas a la hora de seleccionar la configuración más adecuada para un negocio específico. Oracle dataguard se puede administrar desde la consola Grid Control de Oracle o también desde las consolas de sqlplus o el Oracle Dataguard Broker.

La figura muestra la arquitectura de la solución Oracle Dataguard. En ella se observan dos servidores de base de datos: un servidor primario o de producción y un servidor standby o de contingencia. Basicamente Oracle Dataguard posee una serie de procesos que se encargan de trasladar cada uno de las transacciones que ocurre en el servidor primario para que se replique (redo apply) en el servidor standby. Como las transacciones se van registrando en los archivos de redolog, las entradas de estos archivos de bitácora de transacciones se van transportando y reaplicando en los archivos de redolog standby y estos a su vez se aplican a la base de datos standby por medio de un proceso especial para este fin.

Lo interesante que Oracle Dataguard permite invertir los roles de las base de datos, (switchover) esto es, la base de datos standby puede quedar como productiva y la productiva como standby, y luego repetir nuevamente el cambio de roles para llegar a la configuración original y todo esto con un mínimo tiempo de pérdida de servicio. Esto es muy útil cuando se requiere hacer mantenciones preventivas de la infraestructura de servidores, parchado de software, o cualquier otra mantención al sitio. Oracle dataguard permite administrar los roles anteriormente descritos. Existens dos tipos de roles de transición: SWITCHOVER y FAILOVER. El rol de SWITCHOVER que fue mencionado permite la inversión de roles primary --> standby y viceversa. La gracia es que a diferencia de una base de datos standby que tambien permite hacer en forma manual un switchover esto se hace sin la necesidad de recrear las bases de datos, por lo tanto es mucho más rápida la operación. El otro rol de transición es el rol de FAILOVER que se puede ejecutar en forma manual o automática. En un FAILOVER la base de datos standby queda como primaria cuando se ha perdido la base de datos primaria (imaginemos una pérdida de disco que no permite seguir operando la base de datos). Una vez que se ha corregido el problema la base de datos primaria que falló rapidamente se puede dejar como una base de datos standby de la nueva base de datos primaria, usando la capacidad de FLASHBACK DATABASE que tiene oracle. Esto último reduce dramaticamente el esfuerzo de recrear la configuración de protección de Oracle Dataguard.

Oracle Data Guard debería ser la base de toda implementación para la recuperación de desastres en la infraestructura de IT. Data Guard ofrece la tecnología para implementar y administrar una o más copias standby de la base de datos de producción, ya sea en el centro de datos local o en un centro de datos remoto, que podría ubicarse en cualquier lugar del mundo. Una variedad de opciones configurables se encuentran disponibles en Data Guard, las cuales permiten que los administradores definan el nivel de protección que requieren para su empresa. Data Guard también funciona de manera transparente en los clusters de Grid ya que los servidores pueden agregarse dinámicamente en la base de datos standby en caso de que se requiera un failover. Data Guard respalda dos tipos de bases de datos standby– bases de datos standby físicas que utilizan la tecnología Redo Apply y las bases de datos standby lógicas que utilizan la tecnología SQL Apply.

Data Guard Redo Apply (Standby Físicas)
Una base de datos standby física es mantenida y sincronizada con la base de datos de producción mediante la tecnología Redo Apply. Los datos redo de la base de datos de producción son enviados a la standby física que, utilizando la recuperación de medios, aplica los cambios de datos redo a la base de datos standby. Al utilizar Redo Apply, la base de datos standby permanece físicamente idéntica a la base de datos de producción. Las bases de datos standby físicas son buenas para brindar protección ante desastres y errores de datos.

Data Guard SQL Apply (standby lógica)
Una base de datos standby lógica es mantenida y sincronizada con la base de datos de producción mediante la tecnología SQL Apply. En vez de usar la recuperación de medios para aplicar cambios de la base de datos de producción, SQL Apply transforma los datos redo en transacciones SQL y los aplica en una base de datos que está abierta para operaciones de lectura/escritura.

Agente Data Guard
Las bases de datos primaria y standby, así como sus variadas interacciones, pueden administrarse utilizando SQL*Plus™. Para una capacidad de administración más fácil, Data Guard también ofrece un marco distribuido para la administración, denominado Agente Data Guard, que automatiza y centraliza la creación, el mantenimiento y el monitoreo de una configuración Data Guard.

Principales beneficios

a)Recuperación ante desastres y alta disponibilidad

Mediante un failover automático y fácil de administrar que en segundos cambia el rol de las bases de standby a producción

b)La base standby database también provee una salvaguarda efectiva contra la corrupción de los datos y los erroresde los usuarios

Ya que daños físicos en la base de datos primaria no se propagan a la standby

c)La base standby puede ser utilizada para backups y reportes de sólo lectura

Reduciendo la carga de trabajo de las bases productivas ahorrando ciclosde CPU y de E/S.

d)Flexibilidad en la protección de los datos

Balancea la disponibilidad con los requerimientos de performance

e)Protección ante fallas de comunicación

Si la conectividad de la red se pierde, por lo que no se pueden transmitir los datos entre las bases productivas y las standby, luego cuando se reestablece la misma, los datos perdidos son automáticamente detectados porData Guard y los logs de los archivos son transmitidos a las bases standby, lasque se resincronizan con las bases primarias, sin intervención manual del administrador.

f)Administración simple y centralizada

La funcionalidad Data Guard Broker automatiza la administración y el monitoreo detodas las bases de datos

g)Economía

Ya que Data Guard está disponible como una característica integrada de la versión Enterprise Edition sin costo adicional.


FUENTE:
http://www.oracle.com/global/lad/database/active-data-guard.html
http://www.kit.com.ar/boletines-a.php?id=0000035

Real Application Clusters

Oracle RAC es una opción que en Oracle Standard Edition viene incluida en el licenciamiento básico y que le permite a varios servidores trabajar en forma concurrente sobre una misma base de datos (que se encuentra en un Storage), incrementando escabilidad, rendimiento y tolerancia a las fallas (alta disponibilidad).

Esto permite bajar los costos de operación : RAC le permite utilizar un cluster de servidores de bajo costo (por ejemplo equipos con procesadores INTEL y sistema operativo Linux) en vez de un equipo con procesadores de Multi Procesamiento Simétrico (SMP) y sistema operativo propietario que son de mucho mayor costo. Incluso se puede armar un RAC con 3 máquinas de bajo costos donde dos máquinas juegan el rol de nodos del RAC y la tercera juega el rol de Storage accesado con protocolo iSCSI. NEURONET mostró en el último Oracle Day en forma exitosa la operación de esta última configuración, derribando el mito de que RAC es una arquitectura cara y para empresas muy grandes. RAC es una opción real que tiene cualquier empresa que maneje información de misión crítica para su negocio.

Oracle Real Application Clusters (RAC) es la principal tecnología para clustering de base de datos que permite a dos o más computadoras (también referidos como “nodos”) de un cluster acceder concurrentemente a una sola base de datos compartida. Esto crea efectivamente un sistema de base de datos única que abarca múltiples sistemas de hardware y aparece frente a la aplicación como una sola base de datos unificada. Esto trae aparejado enormes beneficios de disponibilidad y escalabilidad para todas sus aplicaciones, como por ejemplo:
Tolerancia a fallas dentro del cluster, en especial, a fallas de la computadora. Flexibilidad y eficiencia de costos en la planificación de capacidad, de manera que un sistema pueda escalar a cualquier capacidad deseada a pedido y a medida que las necesidades de negocio cambian.

Real Application Clusters permite Grids para empresas. Los Grids para Empresas están creados con grandes configuraciones de componentes estandarizados, con precios de commodity: procesadores, servidores, redes y almacenamiento. RAC es única tecnología que puede aprovechar estos componentes para obtener sistemas de procesamiento útiles para la empresa. Real Application Clusters y Grid reducen drásticamente los costos operacionales y brindan nuevos niveles de flexibilidad, de manera que los sistemas se vuelven más adaptables, preactivos y ágiles. El suministro dinámico de nodos, almacenamiento, CPUs y memoria permite que los niveles de servicio sean mantenidos fácil y eficientemente mientras se reducen los costos mediante un mejor uso. Asimismo, Real Application Clusters es completamente transparente para la aplicación que accede a la base de datos RAC, permitiendo así que las aplicaciones existentes sean implementadas en RAC sin la necesidad de ninguna modificación.

Una ventaja clave de la arquitectura RAC es la tolerancia inherente a fallas suministrada por múltiples nodos. Dado que los nodos físicos se ejecutan independientemente, la falla de uno o más nodos no afectará otros nodos del clust El failover ocurre en cualquier nodo del Grid. En un caso extremo, un sistema Real Application Clusters aún suministraría el servicio de base de datos incluso cuando todos los nodos excepto uno hayan dejado de funcionar. Esta arquitectura permite que un grupo de nodos sea puesto online u offline en forma transparente, para el mantenimiento, mientras el resto del cluster sigue brindando el servicio de base de datos. RAC brinda integración incorporada con Oracle Fusion Middleware para hacer el failover de los grupos de conexión. Con esta capacidad, se notifica inmediatamente a la aplicación acerca de la falla, en vez de tener que esperar varios minutos para que ocurra una interrupción TCP. La aplicación puede inmediatamente tomar las medidas adecuadas de recuperación. Y Grid load balancing redistribuirá la carga a lo largo del tiempo.

Real Application Clusters también ofrece a los usuarios la flexibilidad de agregar nodos al cluster a medida que la demanda de capacidad aumenta, ampliando cada vez más el sistema para ahorrar costos y eliminar la necesidad de reemplazar sistemas más pequeños de nodo único por unos más grandes. Facilita el proceso de la actualización de capacidad, y hace que sea más rápido, ya que uno o más nodos pueden agregarse al cluster, en vez de reemplazar los sistemas existentes con nuevos nodos más grandes para actualizar los sistemas. La tecnología Cache Fusion implementada en Real Application Clusters y el soporte de InfiniBand networking permite el aumento casi linear de la capacidad sin realizar cambios en sus aplicaciones.

Oracle Database 11g optimiza aún más el desempeño, la escalabilidad y los mecanismos de failover de Real Application Clusters para mejorar sus beneficios de escalabilidad y alta disponibilidad.


FUENTES:
http://www.oracle.com/lang/es/database/rac_home.html
http://es.wikipedia.org/wiki/Oracle_RAC