Archive for marzo 2015
Declarative Referential Integrity (DRI)
Integridad referencial es una característica proporcionada por los sistemas de gestión de bases de datos relacionales que evita que los datos inconsistentes. Debido a las relaciones entre las tablas, los cambios en las claves primarias deben actualizarse en las claves externas. Esto puede conducir a actualizaciones o eliminaciones en cascada, si más de una fila contiene la clave externa afectada. La tabla con la clave externa no debe permitir la inserción de filas que no contienen un valor de la tabla relacionada.SQL Server exige integridad referencial con dos técnicas diferentes nombradas integridad referencial declarativa (DRI) y disparadores.
Se declara al crear o modificar una tabla con una propiedad de tabla. Esto se hace con la cláusula FOREIGN KEY ... REFERENCIAS, esta es una restricción que se asegura de que la columna o columnas que respeten la integridad referencial. Una restricción FOREIGN KEY sólo puede hacer referencia a una clave principal o clave UNIQUE en la tabla referenciada. Hay dos posibles acciones que activan la restricción: Eliminar fila (ON DELETE) o fila de actualización (ON UPDATE). La restricción puede tomar una de dos acciones: CASCADE significa que el DELETE o UPDATE también se producirá en todas las filas relacionadas, y ninguna acción que genera un error y revierte la acción.
Los disparadores proporcionan entre bases de datos de integridad referencial mientras DRI sólo funciona dentro de una base de datos. El código en un disparador puede hacer tanto como un SP, con excepciones menores, en particular con las declaraciones de bases de datos. Aparte de eso, el código es muy flexible y con acceso a las tablas conceptuales que dan acceso directo a las filas modificadas. Ahí es donde la fuerza de los factores desencadenantes se encuentra; no sólo pueden enviar mensajes de correo electrónico, control de cambios, incluso ejecutar aplicaciones cuando se le llama, sino también examinar los cambios en el nivel de fila y tomar decisiones o tomar acciones basadas en ella.
DRI es más rápido y más fácil de mantener porque se basa en una restricción sin código debajo mientras dispara la demanda código para manejar correctamente todas las relaciones. El uso de disparadores de integridad referencial puede ser difícil cuando hay muchas tablas relacionadas entre sí y los cambios en la estructura de datos hará que todo el código que desea cambiar y cuidadosamente revisado. La ventaja de utilizar disparadores es que el código se puede personalizar para hacer tareas que son más intrincados y permitirá referencias circulares en la estructura de datos, que DRI prohíbe estrictamente.
El RTO (Recovery Time Objective)
Es la cantidad de tiempo que el negocio puede ser sin el servicio,
sin incurrir en riesgos significativos o pérdidas significativas. Los acontecimientos que marcan el inicio y el final de la duración RTO
deben ser previamente acordados entre Continuidad del Negocio y personal
ITSC. Lo mejor es llegar a un acuerdo para iniciar el reloj RTO en el momento en que se decidió proceder a la recuperación.
A veces demasiado tiempo se toma sobre la decisión de invocar la
recuperación, a veces incidentes mayores no comienzan a veces fácilmente
pared reloj definibles de todos modos. El reloj RTO debe considerarse que parar una vez que el equipo responsable de probar el servicio (antes de que se libera con éxito a la comunidad de usuarios más amplia) comenzar a trabajar.
Al definir el RTO de esta manera se puede establecer en un periodo de
tiempo muy específico, que permite una mejor toma de decisiones en
absoluto niveles-aceptar que esto compromete un poco el principio de
establecer el RTO para ser "la cantidad de tiempo que el negocio puede
ser sin el servicio ".
El
Objetivo de Tiempo de Recuperación (RTO) es la duración de tiempo y un
nivel de servicio dentro de la cual un proceso de negocio debe ser
restaurado después de un desastre a fin de evitar consecuencias
inaceptables asociados con una solución de continuidad.
En otras palabras, el RTO es la respuesta a la pregunta: "¿Cuánto tiempo le llevará a la recuperación después de la notificación de la interrupción de procesos de negocio?"
Multiversion concurrency control
El control de concurrencia mediante versiones múltiples (Multiversion concurrency control o MVCC) es un método para control de acceso generalmente usado por SGBDs para proporcionar acceso concurrente a los datos, y en lenguajes de programación para implementar concurrencia.
Aplicado a una base de datos el procedimiento consistiría en
implementar las actualizaciones de datos no borrando los datos antiguos y
sobreescribiéndolos con los nuevos, sinó marcando los antiguos como
obsoletos y añadiendo los nuevos. De ese modo habrá en algún momento más
de una versión de los mismos datos almacenada, teniendo validez sólo la
versión más reciente. Se evita así al sistema gestor de la base de
datos dedicar tiempo a rellenar huecos en memoria o disco, al precio de
tener que recorrer periódicamente la memoria o el disco para eliminar
dichos objetos obsoletos. En el caso de una base de datos documental
esta estrategia permite optimizar los documentos escribiéndolos en
memoria contigua, evitando así tener un documento parcheado o con una
lista encadenada de sus piezas en una estructura no contigua.
MVCC también proporciona vistas consistentes en tiempo. La lectura de
transacciones en MVCC usan típicamente marca de tiempo o ID de
transacción para determinar qué estado de la base de datos leer. Las
lecturas se pueden así independizar de las escrituras a merced de la
conservación de las versiones con valores antiguos, y se evitan así los
procesos de bloqueo o de exclusión mutua. Las escrituas afectan a
futuras versiones, pero el ID de transacción en curso garantiza la
consistencia ya que las escrituras posteriores se contemplarán más
tarde.
Dicho de otro modo, MVCC proporciona a cada usuario conectado a la
base de datos una instantánea de la misma para él sólo. Cualquier cambio
que se haga no será visible a los demás usuarios hasta que la
transacción se haya completado.
DWH(Data Warehouse)
Es una colección de datos
orientada a un determinado ámbito (empresa, organización, etc.),
integrado, no volátil y variable en el tiempo, que ayuda a la toma de
decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de
un expediente completo de una organización, más allá de la información
transaccional y operacional, almacenado en una base de datos diseñada
para favorecer el análisis y la divulgación eficiente de datos
(especialmente OLAP, procesamiento analítico en línea).
El almacenamiento de los datos no debe usarse con datos de uso actual.
Los almacenes de datos contienen a menudo grandes cantidades de
información que se subdividen a veces en unidades lógicas más pequeñas
dependiendo del subsistema de la entidad del que procedan o para el que
sean necesario.
La alta disponibilidad se trata de garantizar que un sistema de base de datos u otras funciones de servidor crítico permanecen operativos tanto durante los cortes planificados o no planificados, como las operaciones de mantenimiento o fallas de hardware o de red. Base de datos reducido el tiempo de inactividad le permite cumplir con los acuerdos de nivel de servicio (SLA estrictos) sin pérdida de datos durante fallas de infraestructura.
DB2 proporciona la agrupación de bases de datos, así como capacidades de alta disponibilidad y recuperación ante desastres diseñados para maximizar la disponibilidad de datos durante los dos eventos planificados y no planificados. También le permite adaptarse rápida y fácilmente a los cambios en las cargas de trabajo con una mínima participación de los administradores de bases de datos, y libera a los desarrolladores de aplicaciones de las complejidades subyacentes de diseño de base de datos y la arquitectura.
Característica DB2 recuperación de desastres de alta disponibilidad (HADR) proporciona una solución de alta disponibilidad para los dos fallas en el sitio parciales y completas. HADR protege contra la pérdida de datos mediante la replicación de los cambios de datos de una fuente o en el servidor primario, a uno o más servidores de reserva. DB2 HADR admite hasta tres servidores remotos de reserva y está disponible en todas las ediciones de DB2 con exclusión de DB2 Express-C.
IBM DB2 pureScale® ayuda a cambiar la economía de la disponibilidad continua de datos. DB2 pureScale está diseñado para organizaciones que requieren alta disponibilidad, fiabilidad y escalabilidad para el procesamiento de transacciones en línea (OLTP) para cumplir los acuerdos de nivel de servicio estrictos. Opciones generales para la infraestructura subyacente y términos de licencia flexibles ayudan a conseguir altos niveles de servicio a un precio
Recovery point objective
Uno de los objetivos de punto de recuperación, o "RPO", se define por la planificación de continuidad del negocio . Es el período máximo objetivo en el que los datos se pueden perder desde un servicio de TI debido a un incidente grave. El RPO ofrece a los diseñadores de sistemas de un límite a trabajar para.
Por ejemplo, si el RPO se ajusta a cuatro horas, a continuación, en la
práctica, fuera del sitio reflejado copias de seguridad deben mantenerse
continuamente - una copia de seguridad fuera del sitio a diario en la
cinta no será suficiente. Se debe tener cuidado para evitar dos errores comunes en torno al uso y definición de RPO. En primer lugar, el uso personal de BC análisis del impacto empresarial para determinar RPO para cada servicio - RPO no está determinado por el régimen de copia de seguridad existente.
En segundo lugar, cuando se requiere ningún nivel de preparación de
datos fuera del sitio, en lugar de en el momento de las copias de
seguridad se offsited, el período durante el cual los datos se pierde
muy a menudo comienza cerca de la hora del inicio de la obra para
preparar las copias de seguridad que son finalmente offsited.
