Soporte analisis multidimensional y procesamiento analitico en linea (OLAP): Los datos son clasificados en diferentes dimensiones y pueden ser

vistas unas con otras en diferentes combinaciones para obtener diferentes combinaciones para obtener diferentes analisis de los datos que contienen. Usuarios formulan consultas complejas, arreglar datos en un reporte, cambiar de datos resumidos a datos detallados. (Olap)procesamiento analitico online integrado

Los tres tipos diferentes de recuperacion

La reconstrucion de la base de datos se conoce como recovery. Los tres tipos diferente de recuperacion son: Version recovery, que es la restauracion de la base de datos a la version anterior con una imagen de la base de datos que fue creado durante la operacion de respaldo. Rollforward recovery, que es la reaplicacion de transacciones registradas en los archivos de log despues que una base de datos o una tabla esta restaurada. Crash recovery, que es la recuperacion automatica de la base de datos si una falla ocurre antes de todas las transacciones estan completas.

II - 1.

Version Recovery

Version recovery es la restauracion de la base de datos de la version anterior con una imagen de la base de datos que fue creado durante la operacion de respaldo. Se usa version recovery con una base de datos no recuperable. En este momento, solo quedan los archivos de log activos para crash recovery. Una operacion de restauracion reconstruira una base de datos entera al estado identico a la base de datos en el momento que se realizo la operacion de respaldo. Sin embargo, se perderan todas las transacciones que se realizaron despues de la operacion de resplado. Con la base de datos distribuido, es necesario hace el respaldo y restuarar la base de datos de cada nodo separado y en el mismo momento.

II - 2.

Rollforward Recovery

Rollforward recovery es la reaplicacion de transacciones registradas en los archivos de log despues que una base de datos o una tabla esta restaurada. Para aplicar el metodo de rollforward recovery, es necesario a hacer un respaldo de la base de datos y los archivos de log. Hay dos tipos de rollforward recovery: Database rollforward recovery. En este tipo de rollforward recovery, las transacciones registradas en archivos de log seran aplicadas despues de la operacion de la restauracion de la base de datos. Los archivos de log registran todos los cambios a la base de datos. Este metodo recupera la base de datos a su estado del ultimo momento antes de la falla (que es hasta el fin de los archivos de log). Con la base de datos distribuida, si hace una rollforward recovery para regresar la base de datos a un momento especifico, es necesario a aplicar la recuperacion a todos los nodos para asegurarse que todos los nodos estan en el mismo nivel de estado. Si solamente para restaurar un solo nodo, se reaplican todas las transacciones que estan registradas en archivos de log. Tablespace rollforward recovery. Para comenzar la operacion de table space rollforward recovery, se neceesita la imagen de la base de datos entera (que es, todas los table spaces), o uno o mas table spaces, y tambien los archivos de log que afectan a los table spaces que se restauraran. Se puede restaurar las tablas con los archivos de log a dos puntos: 1. Fin de los archivos de log. 2. Un momento particular, que se conoce como point-in-time recovery.

II - 3.

Crash Recovery

Crash recovery es la recuperacion automatica de la base de datos si una falla ocurre antes de todas las transacciones estan completas. Una falla de transaccion se provoca por un error grave o una comdicion que termina la base de datos anormalmente. Si las transacciones estan interrumpidas, la base de datos estaria en un estado inconsistente y inservible. Las condiciones que resultan falla de transaccion incluyen: Una falla de fuente de poder en la maquina, que cae la base de datos. Una serie de error del sistema operativo, que cae DB2.

 Crash recovery es el proceso que regresa la base de datos al estado consistente con desechar las transacciones incompletas y completar las transacciones con commit que todavia estan en la memoria.

III. Recovery Logs y Recovery History File

Los archivos de log y los archivos de la historia de recuperacion son creados automaticamente cuando se crea una base de datos. No se pueden modificar directamente a los archivos de log o los archivos de la historia de recuperacion. Sin embargo, son importantes para recuperar los datos perdidos. Recovery logs, que se usa para recuperar de los errores de aplicacion o sistema. En combinacion con el respaldo de base de datos, los archivos de log son usados para recuperar el estado consistenet de un momento antes de una falla pasa a la base de datos. Recovery history file, que contiene un resumen de informaciones del respaldo, que se puede usar para recuperar parte o toda de la base de datos a un momento especificado. Se usa para rastrear eventos relacionados a la recuperacion, tales como las operaciones de respaldo y restauracion.

III - 1. Recovery log

Todas bases de datos tienen los archivos de log asociados. Los logs registran cambios de base de datos. Si una base de dato necesita ser recuperada a un punto despues el ultimo respaldo, los logs son requeridos para realizar la recuperacion. Los logs de DB2 tienen dos tipos de comportamiento: Circular logging, es el comportamiento default cuando se crea una nueva base de datos. Como su nombre, circular logging usa un anillo de logs activos* en linea para registrar los cambios de base de datos para realizar una crash recovery, pero no se permite una rollforward recovery. Con este tipo de logs, la recuperacion de base de datos que puede realizar un usuario es version recovery. Todas las transacciones que se han realizaos entre el ultimo respaldo y el punto de falla de sistema, se perderan. Archived logs, son logs cerrados y guardados, y son usados especificamente para rollforward recovery. Pueden ser uno de los dos siguiente tipos: Online archived logs, que son guardados en el directorio de la base de datos. Offline archived logs, que no se encuentran en el directorio de la base de

datos.

III - 2. Recovery history file

Un RHF (Recovery History File) es creado con cada base de datos, y se actualiza automaticamente cuando hay: Respaldo de una base de datos o un tablespace Recuperacion de una base de datos o un tablespace Roll forward de una base de datos o un tablespace Alter un tablespace Renombrar un tablespace Cargar una tabla Actualizar una tabla Un RHF contiene un resumen de informaciones del respaldo. Usuario puede consultar las informaciones de un momento especificado. Las informaciones en RHF incluye: La parte de la base de datos que se hizo respaldo, y como se hizo. El tiempo que realizo el respaldo. La localizacion de la copia. El tiempo que realizo la ultima recuperacion. El tiempo que se renombro un tablespace, con el nombre previo y el nombre actual. El estado del respaldo: activo, inactivo, vencido, o borrado. El ultimo numero de sequencia de log guardado por el respaldo de la base de datos, o procesado por una Rollforward Recovery.

. Soporte OLAP:

Para realizar analisis multidimensional y procesamiento analitico en linea, con funciones de ROLLUP, CUBE y GROUPING SETS. Sopota STARS JOINS.

CONCURRENCUIA

A. Estrategia de bloqueo DB2

por Coboler@ el Vie Feb 25, 2011 10:38 am

GENERALIDADES. DB2 permite que varios procesos de aplicacin accedan a los mismos datos a la vez. Es decir, permite concurrencia, pero no gratis, al facilitar concurrencia hay que pagar el precio de posibles contenciones indeseadas, timeout, etc. A la larga es menos costoso que la concurrencia la gestione el DB2 que la gestionen los propios programas. Como beneficio tenemos: No existen prdidas de actualizaciones No existe la posibilidad de acceso a datos inconsistentes Los programas no necesitan controlarlo Para realizar todo esto el DB2 bloquea el recurso en un momento dado y para un programa dado, de tal forma que si otro programa quiere acceder a ese recurso y, por incompatibilidad de operaciones con el que lo tiene, el DB2 hace que espere durante un tiempo, si al cabo de ese tiempo se libera el recurso, contina la ejecucin del segundo programa, en caso contrario le devuelve el control dicindole que no ha podido realizar su peticin. Pero en ningn caso se producen los efectos negativos de dos procesos accediendo a los mismos datos. La forma de bloquear un recurso puede ser: Implcita del DB2, con los parmetros de creacin de los recursos y unas normas de acceso, l decide en cada momento qu debe hacer. Explcita, el proceso de aplicacin enva una peticin de bloqueo, (en sta instalacin no se recomienda esta forma de bloqueo). La estrategia bsica de bloqueo DB2 son: Bloqueo de Espacio para Tablas con bloqueo de pginas Bloqueo de Espacio para Tablas sin bloqueo de pginas Bloqueo de Tablas con bloqueo de pginas Bloqueo de Tablas sin bloqueo de pginas La estrategia a seguir depende de las necesidades de performance, frente a las necesidades de concurrencia. Cuando se utiliza bloqueo de pginas: Mejora concurrencia, lo que significa, buenos tiempos de respuesta Aumenta el consumo de CPU y memoria. Esto es muy importante en datos que slo se procesan batch y que requieren actualizaciones de muchas pginas. Cuando no se utiliza bloqueo de pginas: Disminuye el consumo de CPU y de memoria Se reduce la concurrencia, lo que significa mayor tiempo de respuesta

ATRIBUTOS DEL BLOQUEO DB2. Objeto del Bloqueo El objeto de un lock es el recurso que va a ser bloqueado. El DB2 puede bloquear los siguientes recursos: Espacios para Tablas Tablas Pginas El DB2 bloquea adems otros recursos pero slo en el mbito de proceso interno, y, en cualquier caso, son objetos propios del DB2, y no de usuario. El tamao de un Bloqueo Dice el tamao del recurso que bloquea. Para Espacios para tablas segmentados, un lock puede afectar a: Al espacio para tabla entero, lo que significa, que cualquier tabla contenida en l queda bloqueada. Una tabla dentro del espacio para tablas. Una pgina de una tabla. Para Espacios para tablas NO segmentados, un lock puede afectar a: El espacio para tablas completo Una pgina dentro del espacio para tablas Existen dos tpicos casos de necesidades de concurrencia: Muchos usuarios, slo lectura Un usuario cada vez con posibilidad de lectura y/o escritura Dependiendo de los datos, unos necesitarn una concurrencia y otros otra. La necesidad de concurrencia depende tambin del tipo de proceso. De las necesidades mencionadas anteriormente, se puede decidir s la estrategia de bloqueo es slo en el mbito de espacio para tabla, , en el mbito de pginas dentro de un espacio para tabla. Para el caso 1, es mejor bloquear a nivel de espacio para tabla. Para el caso 2, es mejor pensar en el bloqueo de pginas dentro de un espacio para tablas. El tamao del bloqueo se decide cuando se define el Espacio para tablas, normalmente en esta instalacin se opta por decir que puede ser cualquiera, de manera que el DB2, dependiendo del proceso, decide cual es el ms ptimo. Duracin del Bloqueo Es el espacio de tiempo que el DB2 mantiene un bloqueo sobre un recurso. El espacio puede variar dependiendo de en qu momento se adquiere y en qu

momento se libera. Cmo se adquieren y liberan los recursos? En tiempo de BIND se define cuando se quiere que se adquieran y liberen los recursos. Los parmetros son: ADQUIRE: Cuando se adquieren los bloqueos sobre los recursos RELEASE: Cuando se liberan los bloqueos sobre los recursos ISOLATION LEVEL: Duracin del bloqueo sobre pginas. Las posibilidades para adquirir un lock son: En tiempo de carga del plan (ALLOCATE): Antes de ejecutar ninguna sentencia del plan se asegura que tiene disponibles todos los recursos que va a necesitar, si alguno estuviese bloqueado por otro proceso, ste esperara a que lo liberasen. En el momento que se usa (USE): Comienza a ejecutar el plan, cuando va a utilizar un recurso adquiere el lock necesario para esa sentencia, s otro proceso tuviese bloqueado el recurso, ste plan esperara. Las posibilidades para liberar un lock son: En tiempo de descarga del plan (DEALLOCATE): No libera ningn recurso hasta que el plan finalice, existan o no sentencias COMMIT. En tiempo de COMMIT, libera los recursos adquiridos hasta ese momento cuando se ejecuta un COMMIT, bien implcito, bien explcito. Con estos parmetros se pueden realizar cuatro combinaciones posibles, slo son vlidas las siguientes: Adquiere ALLOCATE libera DEALLOCATE. Adquiere USE libera DEALLOCATE. Adquiere USE libera COMMIT. El uso de Adquiere ALLOCATE: Disminuye posibilidades de DEADLOCK. Reduce posibilidad de Concurrencia. Por el contrario, el uso de Adquiere USE: Aumenta la posibilidad de DEADLOCK. Aumenta la posibilidad de Concurrencia. DEADLOCK: Un deadlock se produce cuando el proceso A tiene adquirido el recurso R1 y necesita el recurso R2, pero a su vez el proceso B tiene el recurso R2 y est esperando por el recurso R1.

El Deadlock debe evitarse, pero no es desastroso que se produzca ya que el DB2 lo detecta y decide que un proceso termine, con lo que libera el recurso que espera el otro, y el otro acabe normalmente puesto que puede adquirir el recurso que necesita. En esta instalacin se ha definido que los recursos se adquieran en el momento que se utilicen y se liberen en tiempo de COMMIT, puesto que se hace mucho hincapi en la mxima concurrencia, asumiendo y controlando la posibilidad de Deadlock que, como se ha explicado en captulos anteriores, existen tcnicas de diseo que pueden reducirlos. Duracin de un lock sobre un Espacio para Tablas: Queda determinado por los parmetros ADQUIRE y RELEASE. Duracin de un lock sobre una Pgina: Una Pgina se bloquea cuando se accede a ella por primera vez. Una pgina se libera dependiendo de: el valor del parmetro ISOLATION LEVEL y del tratamiento realizado. El parmetro ISOLATION puede tomar los siguientes valores: CURSOR STABILITY (CS): Significa que: o En procesos slo de lectura, el bloqueo sobre la pgina se mantiene slo mientras el cursor est posicionado en ella, cuando el cursor accede a otra pgina , el bloqueo sobre la anterior se libera. o En procesos de actualizacin, el bloqueo sobre la pgina de datos se mantiene hasta el siguiente punto de commit ( hasta la liberacin del plan), rollback. Y, s no se ha modificado campos del ndice, la pgina de direcciones del ndice se libera cuando se cierre el cursor. REPEATABLE READ: Significa que los bloqueos se mantienen hasta el siguiente punto de commit. De esta manera, si un mismo proceso accede en dos momentos diferentes a los mismos datos, stos no pueden haber cambiado. Es preferible la opcin CS, puesto que permite mayor concurrencia. Modo de un Bloqueo Se denomina modo de un bloqueo a los diferentes tipos de acceso permitidos por procesos de aplicacin concurrentes. Bloqueos sobre Pginas Cuando una pgina se bloquea con un determinado tipo de bloqueo, el espacio para tablas al que pertenece se bloquea con un tipo de bloqueo que se denomina Intento de. Los tipos de bloqueos sobre pgina son: S (SHARE): El propietario del lock y cualquier otro proceso concurrente pueden leer los datos pero no pueden cambiarlos. Otro proceso de aplicacin puede adquirir

un S-lock o un U-lock sobre esa pgina. El espacio para tabla al que pertenece la pgina tendr un IS-lock o IX-lock. U (UPDATE): El propietario del lock puede leer los datos e intentar cambiarlos, ningn otro proceso de aplicacin puede adquirir sobre esa pgina un S-lock pero no un U-lock. Operaciones de Update y Delete mediante cursor requieren un U-lock en lectura; cuando se realiza la operacin de actualizacin el U-lock se promociona a X-lock s ningn otro proceso tiene adquirido un S-lock en caso contrario el proceso tiene que esperar. El espacio para tabla adquiere un IX-lock. X (EXCLUSIVE): El propietario puede leer datos o cambiar los datos, ningn otro proceso puede acceder a leer ni a modificar datos de esa misma pgina. El espacio para tabla adquiere un IX-lock o un SIX-lock. Los tipos de bloqueos sobre espacios para tablas son: IS (INTENT SHARE): El propietario puede leer datos del espacio para tabla pero no puede cambiarlos. Cualquier otro proceso puede leer o cambiar datos. S (SHARE): El propietario y cualquier otro proceso puede leer los datos del espacio bloqueado pero no pueden cambiarlos. IX (INTENT EXCLUSIVE): El propietario del lock y cualquier otro proceso concurrente pueden leer y modificar los datos. Para modificar los datos es necesario adquirir sobre la pgina en cuestin el lock necesario siguiendo las reglas de bloqueo sobre pginas. SIX (SHARE con INTENT EXCLUSIVE): El propietario del lock puede leer y cambiar los datos. Cualquier otro proceso concurrente puede leer datos en el espacio bloqueado pero no puede cambiarlos. U (UPDATE): El propietario puede leer e intentar cambiar los datos del espacio bloqueado. Cualquier otro proceso puede adquirir S-lock sobre el espacio para tabla pero no pueden adquirir U-lock. X (EXCLUSIVE): El propietario del lock puede leer y cambiar los datos, ningn otro proceso puede leer ni cambiar. Compatibilidad de tipos de bloqueo Se dice que dos tipos de bloqueo son compatibles cuando un proceso A tiene un recurso de un determinado tipo adquirido y un proceso B quiere adquirir ese recurso y puede hacerlo.