• Author / Uploaded
• nestor estrada

• Categories
• Servidor SQL de Microsoft
• Bases de datos
• Apoyo
• SQL
• Archivo de computadora

Citation preview

ACTIVIDAD AA9-EV3 SOCIALIZACIÓN Y EVALUACIÓN DEL MODELO TRANSACCIONAL EN UN MOTOR DE BASES DE DATOS ESPECÍFICO.

PREPARADO POR NESTOR ENRIQUE ESTRADA BARRIOS - FICHA: 1881763 PAULA DANIELA SANCHEZ DIAZ - FICHA: 1881763

ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS

BARRANQUILLA 14 DE NOVIEMBRE 2019

1

Contenido INTRODUCCIÓN ............................................................................................................. 3 OBJETIVOS..................................................................................................................... 4 JUSTIFICACION ............................................................................................................ 5 Socialización y evaluación del modelo transaccional en un motor de Bases de Datos específico ................................................................................................................................ 6 Modelo de recuperación del log de transacciones en una Base de datos ........................... 7 Modelo de recuperación Simple: ....................................................................................... 7 Modelo de recuperación Completa: ................................................................................... 8 Modelo de recuperación bulk-logged: ............................................................................... 8 CONCLUSIONES ........................................................................................................... 9

2

INTRODUCCIÓN La organización requiere contar con planes que le permita alcanzar los objetivos propuestos, por ellos luego de hacer un estudio detallado y aplicar herramientas que permiten detectar oportunidades de mejora en este caso referente a la seguridad de la información, tomando como base la norma ISO27002, se ha podido identificar temas que son prioridad para la organización teniendo en cuenta que uno de sus mayores activo de una empresa es su información, por lo cual se debe mantener la seguridad, integridad y confidencialidad en los datos, sin importar si estos son físicos o electrónicos ambos deben mantener estos principios.

3

OBJETIVOS

General Evaluar y socializar el modelo transaccional en un motor de Bases de Datos específico.. Específicos  Generar una evaluación del modelo transaccional  Definir la evaluación para el modelo transaccional  Documentar lo investigado  Debatir y apropiarse de los conocimientos investigados.

4

JUSTIFICACION

Es primordial para toda organización contar con herramientas que le permitan garantizar la seguridad de su información, por lo cual cada entidad genera planes mediante los cuales se pueda tener claridad sobre las acciones que se ejecuten y se pueda establecer los resultados que se esperan. En cualquier sistema es importante la continuidad del negocio, por lo cual las diferentes estrategias que se dispongan para mantener la disponibilidad ser prioritario para la organización. Los administradores de bases de datos, tienen todo tipo de responsabilidades con la organización, ya que de ellos depende uno de los mayores activos que contiene la empresa, esos activo permiten el desarrollo de la organización y el crecimiento de la misma.

5

Socialización y evaluación del modelo transaccional en un motor de Bases de Datos específico SQL Server almacena los datos físicamente en el archivo de datos (.mdf y .ndf). El archivo de transacciones (.ldf) almacena los detalles de todas las modificaciones que se realizan sobre la base de datos de SQL Server. La escritura en el Log de transacciones es secuencial, y esta optimizado para ello. Se podría decir que (por norma general) carece de sentido crear más de un fichero de log de transacciones. Aunque el algoritmo de escritura en los .ldf es algo más complejo: si tuviéramos más de un fichero, la escritura la haría formando un bucle circular pasando por cada uno de ellos, respetando la secuencialidad en las transacciones. A diferencia de los ficheros de datos, donde si es posible mejorar el rendimiento de una base de datos, aumentado su número. Una instrucción SQL ejecutable es una instrucción SQL que genera llamadas a una instancia de base de datos, incluidas las declaraciones DML y DDL y la SET TRANSACTION declaración. Fin de una Transacción: Una transacción puede terminar en diferentes circunstancias. Una transacción termina cuando ocurre alguna de las siguientes acciones: Un usuario emite una declaración COMMITo sin una cláusula.ROLLBACKSAVEPOINT En una confirmación , un usuario solicitó explícita o implícitamente que los cambios en la transacción se hicieran permanentes. Los cambios realizados por la transacción son permanentes y visibles para otros usuarios

solo después de que se confirme una transacción. La transacción que se muestra en " Transacción de muestra: débito y crédito de la cuenta " finaliza con un compromiso. Un usuario ejecuta un comando DDL tales como CREATE, DROP, RENAME, o ALTER. La base de datos emite una COMMIT declaración implícita antes y después de cada declaración DDL. Si la transacción actual contiene sentencias DML, la base de datos Oracle primero confirma la transacción y luego ejecuta y confirma la sentencia DDL como una nueva transacción de una sola declaración. Modelo de recuperación del log de transacciones en una Base de datos El objetivo de este punto, no es explicar los procesos de backup y restore, sino hacer un resumen de los distintos estados en que se pueden configurar el log de transacciones. El modelo de recuperación de una base de datos puede cambiarse en cualquier momento. No es frecuente cambiar de modelo de recuperación. Tenemos tres modos de configurar el log de transacciones: Simple, Full (completo) y, bulk-logged (recuperación optimizado para cargas masivas de registros). Modelo de recuperación Simple: Sin necesidad de hacer copias de seguridad del log de transacciones, se reduce automáticamente el espacio de registro, manteniendo al mínimo el espacio del fichero según termina las transacciones de las consultas. De este modo no es necesario administrar el espacio del log de transacciones.

Los cambios realizados después de la copia de seguridad más reciente no están protegidos. En caso de desastre, es necesario volver a realizar dichos cambios. Sólo se puede recuperar hasta el final de una copia de seguridad. Modelo de recuperación Completa: Requiere copias de seguridad del log de transacciones. No se pierde trabajo si un archivo de datos se pierde o resulta dañado. Se puede recuperar hasta cualquier momento, por ejemplo, antes del error de aplicación o usuario. Si la base de datos resulta dañada, se deben repetir los cambios realizados desde la última copia de seguridad del log de transacciones. Se puede recuperar hasta un determinado momento, siempre que las copias de seguridad se hayan completado hasta ese momento. Modelo de recuperación bulk-logged: Requiere copias de seguridad del log de transacciones, para ir liberando espacio en el .ldf. Puede considerarse complemento del modelo de recuperación completa, pero no sustito, ya que permite operaciones de copia masiva de alto rendimiento, (por ejemplo, operaciones realizadas con BCP.exe, Bulk Insert, etc…), reduciendo el uso del espacio de registro. Si la base de datos resulta dañada o se han realizado operaciones masivas desde la última copia de seguridad completa, se han de repetir los cambios desde esa última copia de seguridad. Se puede recuperar hasta el final de cualquier copia de seguridad completa. No admite recuperaciones a un momento dado.

CONCLUSIONES

Teniendo en cuenta el anterior plan se generan las siguientes conclusiones:  Se evalúa el modelo de transacciones de una base de datos, en este caso SQL Server.  Se permite socializar el modelo transaccional  Se documenta los datos investigados  Se genera la documentación correspondiente de lo investigado