Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Los mejores documentos en venta realizados por estudiantes que han terminado sus estudios
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Descubre las mejores universidades de tu país según los usuarios de Docsity
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
En la presente investigación se realizará en detalle los modos de operación que se utilizan en un Sistemas de Gestión de Base de Datos, esto con la finalidad de entender el funcionamiento de los modos en las transacciones que siempre se realizan en una base de datos. De los cuales en los diferentes modos tenemos el Rollback que es una operación que devuelve a la base de datos a algún estado previo, un Commit que en SQL finaliza una transacción de base de datos dentro de un SGBD, etc...
Tipo: Guías, Proyectos, Investigaciones
1 / 22
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Docente: MIRIAN MAGALY CANCHE CAAMAL Investigación 1 Unidad 4: Investiga los modos de operación de un SGBD e importancia de los archivos log (SQL Server) Alumno: Luis Enrique Canche Balam
En la presente investigación se realizará en detalle los modos de operación que se utilizan en un Sistemas de Gestión de Base de Datos, esto con la finalidad de entender el funcionamiento de los modos en las transacciones que siempre se realizan en una base de datos. De los cuales en los diferentes modos tenemos el Rollback que es una operación que devuelve a la base de datos a algún estado previo, un Commit que en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional y pone visibles todos los cambios a otros usuarios, y el Recobery que es el proceso de restauración ( restore o recovery) de los que todo SGBD dispone, pueden reconstruir la BD y darle el estado consistente y correcto anterior al incidente.
Investigar los diferentes modos de un SGBD y la importancia de los archivos Log.
un SGBD
SE APLICA A: SQL Server Azure SQL Database Azure Synapse Analytics (SQL DW) Almacenamiento de datos paralelos. Revierte una transacción explícita o implícita al principio de la transacción o a un punto de guardado dentro de la transacción. Puede utilizar ROLLBACK TRANSACTION para borrar todas las modificaciones de datos realizadas desde el inicio de la transacción o hasta un punto de guardado. También libera los recursos mantenidos por la transacción. Sintaxis ROLLBACK { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable | savepoint_name | @savepoint_variable ] [ ; ] Argumentos transaction_name Es el nombre asignado a la transacción en BEGIN TRANSACTION. transaction_name deben cumplir las reglas para los identificadores, pero solo se utilizan los primeros 32 caracteres del nombre de transacción. Al anidar transacciones, transaction_name debe ser el nombre de la instrucción BEGIN TRANSACTION más externa. transaction_name siempre distingue mayúsculas de minúsculas, incluso cuando la instancia de SQL ServerSQL Server no distingue mayúsculas de minúsculas. @ tran_name_variable
Es el nombre de una variable definida por el usuario que contiene un nombre de transacción válido. La variable debe declararse con un tipo de datos char , varchar , nchar o. nvarchar savepoint_name se savepoint_name de una instrucción SAVE TRANSACTION. savepoint_name debe cumplir las reglas para los identificadores. Use savepoint_name cuando una reversión condicional solo debe afectar a una parte de la transacción. @ savepoint_variable Es el nombre de una variable definida por el usuario que contiene un nombre de punto de guardado válido. La variable debe declararse con un tipo de datos char , varchar, nchar o nvarchar. Manejo de errores Una instrucción ROLLBACK TRANSACTION no genera ningún mensaje para el usuario. Si se necesitan advertencias en procedimientos almacenados o desencadenadores, utilice las instrucciones RAISERROR o PRINT. RAISERROR es la instrucción preferida para indicar errores. Interoperabilidad En los procedimientos almacenados, las instrucciones ROLLBACK TRANSACTION sin una savepoint_name o transaction_name revertir todas las instrucciones al BEGIN TRANSACTION más externo. Una instrucción ROLLBACK TRANSACTION en un procedimiento almacenado que hace que @@TRANCOUNT tenga un valor diferente cuando el procedimiento almacenado se completa que el valor @@TRANCOUNT cuando se llamó al procedimiento almacenado genera un mensaje informativo. Este mensaje no afecta al procesamiento posterior. Si se emite una TRANSACCION ROLLBACK en un desencadenador:
de error. Todos los cursores se desasignan independientemente de su tipo o la configuración de CURSOR_CLOSE_ON_COMMIT. Esto incluye los cursores declarados en los procedimientos almacenados a los que llama el lote de errores. Los cursores declarados en un lote antes del lote de errores están sujetos a las reglas 1 y 2. Un error de interbloqueo es un ejemplo de este tipo de error. Una instrucción ROLLBACK emitida en un desencadenador también genera automáticamente este tipo de error. Comportamiento de bloqueo Una instrucción ROLLBACK TRANSACTION que especifica un savepoint_name libera los bloqueos que se adquieren más allá del punto de guardado, con la excepción de las escalaciones y conversiones. Estos bloqueos no se liberan y no se convierten de nuevo a su modo de bloqueo anterior.
SE APLICA A: SQL Server Azure SQL Database Azure Synapse Analytics (SQL DW) Almacenamiento de datos paralelos. Marca el final de una transacción implícita o explícita correcta. Si @@TRANCOUNT es 1, COMMIT TRANSACTION realiza todas las modificaciones de datos desde el inicio de la transacción una parte permanente de la base de datos, libera los recursos de la transacción y disminuye @@TRANCOUNT a 0. Cuando @@TRANCOUNT es mayor que 1, COMMIT TRANSACTION disminuye @@TRANCOUNT solo por 1 y la transacción permanece activa. Sintaxis -- Applies to SQL Server (starting with 2008) and Azure SQL Database COMMIT [ { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ] [ ; ] -- Applies to Azure SQL Data Warehouse and Parallel Data Warehouse
Database COMMIT [ TRAN | TRANSACTION ] [ ; ] Argumentos transaction_name SE APLICA A: SQL Server y Azure SQL Database Motor de base de datos de SQL ServerSQL Server Database Engine omite. transaction_name especifica un nombre de transacción asignado por una BEGIN TRANSACTION anterior. transaction_namedeben cumplir las reglas para los identificadores, pero no pueden superar los 32 caracteres. transaction_name indica a los programadores a los que se ha anidado BEGIN TRANSACTION está asociado COMMIT TRANSACTION. @tran_name_variable SE APLICA A: SQL Server y Azure SQL Database Es el nombre de una variable definida por el usuario que contiene un nombre de transacción válido. La variable debe declararse con un tipo de datos char, varchar, nchar o nvarchar. Si se pasan más de 32 caracteres a la variable, solo se utilizarán 32 caracteres; los caracteres restantes se truncan. DELAYED_DURABILITY SE APLICA A: SQL Server y Azure SQL Database Opción que solicita esta transacción debe confirmarse con durabilidad retardada. La solicitud se omite si la base de datos se ha modificado con o. Para obtener más información, consulte Controlar la durabilidad de las transacciones: DELAYED_DURABILITY = DISABLEDDELAYED_DURABILITY = FORCED Observaciones Es responsabilidad del programador de Transact-SQLTransact-SQL emitir COMMIT TRANSACTION solo en un momento en que todos los datos a los que hace referencia la transacción son lógicamente correctos.
COMMIT TRANSACTION;
SE APLICA A: SQL Server (todas las versiones compatibles) Para recuperar una base de datos de SQL Server de un error, un administrador de base de datos tiene que restaurar un conjunto de copias de seguridad de SQL Server en una secuencia de restauración lógicamente correcta y significativa. La restauración y recuperación de SQL ServerSQL Server admite la restauración de datos a partir de copias de seguridad de una base de datos completa, un archivo de datos o una página de datos, como se indica a continuación: La base de datos (una restauración completa de la base de datos) Toda la base de datos se restaura y recupera, y la base de datos está sin conexión durante las operaciones de restauración y recuperación. El archivo de datos (restauración de un archivo) Se restaura y recupera un archivo de datos o un conjunto de archivos. Durante una restauración de archivos, los grupos de archivos que contienen los archivos se desconectan automáticamente durante la restauración. Cualquier intento de acceder a un grupo de archivos sin conexión produce un error. La página de datos (restauración de una página) En el modelo de recuperación completa o en el modelo de recuperación de registrarse masivamente, puede restaurar bases de datos individuales. Las restauraciones de página se pueden realizar en cualquier base de datos, independientemente del número de grupos de archivos. La copia de seguridad y restauración de SQL ServerSQL Server funcionan en todos los sistemas operativos compatibles. Para obtener información acerca de los sistemas operativos compatibles, vea Requisitos de hardware y software para instalar SQL Server 2016. Para obtener información acerca de la compatibilidad con copias de seguridad de versiones anteriores de SQL Server, vea la sección "Compatibilidad" de RESTORE (Transact-SQL).
Descripción general de los escenarios de restauración Un escenario de restauración en SQL ServerSQL Server es el proceso de restaurar datos de una o varias copias de seguridad y, a continuación, recuperar la base de datos. Los escenarios de restauración admitidos dependen del modelo de recuperación de la base de datos y de la edición de SQL Server. En la tabla siguiente se presentan los posibles escenarios de restauración que se admiten para diferentes modelos de recuperación. Escenario de restauración Bajo un modelo de recuperación simple En modelos de recuperación completos o registrados a granel Restauración completa de la base de datos Esta es la estrategia básica de restauración. Una restauración completa de la base de datos podría implicar simplemente restaurar y recuperar una copia de seguridad completa de la base de datos. Como alternativa, una restauración completa de la base de datos puede implicar la restauración de una copia de seguridad completa de la base de datos seguida de la restauración y recuperación de una copia de seguridad diferencial. Para obtener más información, vea Restauraciones completas de bases de Esta es la estrategia básica de restauración. Una restauración completa de la base de datos implica restaurar una copia de seguridad completa de la base de datos y, opcionalmente, una copia de seguridad diferencial (si existe), seguida de la restauración de todas las copias de seguridad de registros posteriores (en secuencia). La restauración completa de la base de datos se ha terminado recuperando la última copia de seguridad del registro y también restableciéndola (RESTORE WITH RECOVERY). Para obtener más información, consulte Restauraciones completas de bases de datos
seguridad de registros, hasta el archivo de registro actual, y todas deben aplicarse para poner la página actualizada con el archivo de registro actual. Para obtener más información, vea Restaurar páginas (SQL Server). **Restauración por pieza *** Restaure y recupere la base de datos por etapas en el nivel de grupo de archivos, empezando por los grupos de archivos secundarios primarios y todos los grupos de archivos secundarios de lectura/escritura. Restaure y recupere la base de datos por etapas en el nivel de grupo de archivos, empezando por el grupo de archivos principal. Para obtener más información, vea Restauraciones por pieza (SQL Server) Pasos para restaurar una base de datos Para realizar una restauración de archivos, Motor de base de datosDatabase Engine ejecuta dos pasos: Crea los archivos de base de datos que faltan. Copia los datos de los dispositivos de copia de seguridad en los archivos de base de datos. Para realizar una restauración de la base de datos, Motor de base de datosDatabase Engine ejecuta tres pasos: Crea la base de datos y los archivos de registro de transacciones si aún no existen.
Copia todas las páginas de datos, registro e índice del medio de copia de seguridad de una base de datos en los archivos de base de datos. Aplica el registro de transacciones en lo que se conoce como el proceso de recuperación. Independientemente de cómo se restauren los datos, antes de que se pueda recuperar una base de datos, Motor de base de datos de SQL ServerSQL Server Database Engine garantiza que toda la base de datos es coherente lógicamente. Por ejemplo, si restaura un archivo, no puede recuperarlo y ponerlo en línea hasta que se haya rodado lo suficientemente lejos como para ser coherente con la base de datos. Ventajas de la restauración de un archivo o página Restaurar y recuperar archivos o páginas, en lugar de toda la base de datos, proporciona las siguientes ventajas: La restauración de menos datos reduce el tiempo necesario para copiarlos y recuperarlos. En SQL ServerSQL Server restaurar archivos o páginas puede permitir que otros datos de la base de datos permanezcan en línea durante la operación de restauración. Recuperación y el registro de transacciones Para la mayoría de los escenarios de restauración, es necesario aplicar una copia de seguridad del registro de transacciones y permitir que Motor de base de datos de SQL ServerSQL Server Database Engine ejecute el proceso de recuperación para que la base de datos se vuelva en línea. Recuperación es el proceso utilizado por SQL Serversql Server para que cada base de datos se inicie en un estado transaccionalmente coherente o limpio. En caso de una conmutación por error u otro cierre no limpio, las bases de datos pueden quedar en un estado en el que algunas modificaciones nunca se escribieron desde la memoria caché del búfer a los archivos de datos y puede
de blog Nuevos eventos extendidos para el progreso de la recuperación de bases de datos. Modelos de recuperación y operaciones de restauración compatibles Las operaciones de restauración que están disponibles para una base de datos dependen de su modelo de recuperación. En la tabla siguiente se resume si cada uno de los modelos de recuperación admite un escenario de restauración determinado y en qué medida. Operación de restauración Modelo de recuperación completa Modelo de recuperación de registrada masiva Modelo de recuperación simple Recuperación de datos Recuperación completa (si el registro está disponible). Exposición a pérdida de datos. Se pierden todos los datos desde la última copia de seguridad completa o diferencial. Restauración puntual Cualquier tiempo cubierto por las copias de seguridad de registros. No se permite si la copia de seguridad de registros contiene cambios de registro masivo. No es compatible. **Restauración de archivos *** Soporte completo. Algunas veces. ****** Disponible solo para archivos secundarios de solo lectura. **Restauración de páginas *** Soporte completo. Algunas veces. ****** Ninguno. Restauración por pieza Soporte Algunas veces. ****** Disponible solo para archivos
**(nivel de grupo de archivos) *** completo. secundarios de solo lectura.
SE APLICA A: SQL Server (todas las versiones compatibles) Cada base de datos de SQL ServerSQL Server tiene un registro de transacciones que registra todas las transacciones y las modificaciones de base de datos realizadas por cada transacción. El registro de transacciones es un componente crítico de la base de datos. Si se produce un error del sistema, necesitará ese registro para devolver la base de datos a un estado coherente. Para obtener información acerca de la arquitectura del registro de transacciones y los productos internos, consulte la Guía de administración y arquitectura del registro de transacciones de SQL Server.
El registro de transacciones admite las siguientes operaciones: Recuperación de transacciones individuales. Recuperación de todas las transacciones incompletas cuando se inicia SQL Server. El desplazamiento de una base de datos, un archivo, un grupo de archivos o una página restaurados se reenvíe hasta el punto de error. Compatibilidad con la replicación transaccional.
Compatibilidad con soluciones de alta disponibilidad y recuperación ante desastres: grupos de disponibilidad AlwaysOn, creación de reflejo de la base de datos y trasvase de registros. Recuperación de transacciones individuales Si una aplicación emite una instrucción, o si Motor de base de datosDatabase Engine detecta un error como la pérdida de comunicación con un cliente, los registros se usan para revertir las modificaciones realizadas por una transacción incompleta. ROLLBACK
Si se produce un error en un servidor, las bases de datos pueden quedar en un estado en el que algunas modificaciones nunca se escribieron desde la memoria caché del búfer a los archivos de datos y puede haber algunas modificaciones de transacciones incompletas en los archivos de datos. Cuando se inicia una instancia de SQL ServerSQL Server, se ejecuta una recuperación de cada base de datos. Cada modificación registrada en el registro que puede no haberse escrito en los archivos de datos se revierte. A continuación, se revierten todas las transacciones incompletas que se encuentran en el registro de transacciones para asegurarse de que se conserva la integridad de la base de datos. Para obtener más información, vea Información general sobre restauración y recuperación (SQL Server).
A continuación, vamos a ver un ejemplo de creación de una base de datos con un log de transacciones de 512 MB. Según las reglas definidas, este debería nacer con 8 VLFs: USE [master] GO IF DB_ID('VLFDB') > 0 DROP DATABASE [VLFDB]
