INSTITUTO TECNOLOGICO DE CALKINI EN EL ESTADO DE CAMPECHE

INGENIERIA INFORMATICA

Integrantes:

Sandi Verenisa Ake Caamal

Cristian del Carmen Cab Chi

Tirson Guillermo Naal Chim

Bryan Haciel Uc Catzin

MATERIA: SISTEMAS OPERATIVOS II

DOCENTE: Erick Evar Ceron.
GRADO: 5to Semestre

F1: Investigar cómo se puede utilizar el registro de escritura adelantada en

transacciones distribuidas para que el sistema se recupere de fallas.
Introducción

Los registros distribuidos constituyen un nuevo paradigma o desarrollo en los

sistemas de consenso. Para muchos, se trata de una de las innovaciones tecnológicas
más importantes de los últimos veinte años, y probablemente al nivel de impacto
sistémico de internet. Si el primero se configuró como el primer sistema capaz de
transmitir información de forma instantánea, descentralizada, y a cualquier parte del
mundo, los registros distribuidos o DLTs por sus siglas en inglés (distributed ledger
technology) permiten (o permitirán) llevar a cabo la transmisión de valor (transacciones,
archivos o información) en las mismas condiciones que internet de forma
descentralizada.

Resumen
La evolución de los sistemas de consenso o registro centralizado a los distribuidos se
produce al prescindir del consenso proporcionado por un tercero externo al propio sistema.
A cambio, genera un consenso a través de un conjunto de reglas o protocolo que los
participantes del sistema se dan para, de forma interna, autónoma y trustless (en español
se traduce como sin necesidad de confiar en el resto de participantes), verificar el contenido
de la información o valor a registrar.

Estos sistemas van a permitir implementar formas de almacenamiento y autentificación del

valor nunca vistas, en un contexto en el que cada vez más, la información constituye la
gasolina o combustible que mueve el mundo. La llegada del Big Data a las sociedades y la
posibilidad de intercambiar, almacenar, distribuir y utilizar datos e información en tiempo
real proveniente de una multiplicidad de fuentes exige sistemas de verificación y
almacenamiento de datos, sin necesidad de confiar en terceros, que permitan garantizar el
llamado data integrity o integridad de los datos.
Abstract
The evolution of the systems of consensus or centralized registration to those
distributed occurs when the consensus provided by a third party outside the system itself
is dispensed with. In return, it generates a consensus through a set of rules or protocol that
the system participants give themselves to, internally, autonomously and trustless (in
Spanish it is translated as without needing to trust the rest of the participants), verify the
content of the information or value to register.

These systems will allow to implement forms of storage and authentication of the value
never seen, in a context in which more and more, the information constitutes the gasoline
or fuel that moves the world. The arrival of Big Data in societies and the possibility of
exchanging, storing, distributing and using data and information in real time from a
multiplicity of sources requires verification systems and data storage, without the need to
rely on third parties, to guarantee the so-called data integrity or data integrity.

Objetivos
Reduce la eficiencia del propio sistema, ya que el coste de la comprobación se
repercute entre todos los participantes del sistema.
Proporciona un control al verificador o autoridad central que hace a todos los
participantes del sistema dependientes de sus decisiones.

Materiales

Laptop
Internet
Desarrollo

¿Cómo se puede utilizar el registro de escritura adelantada en transacciones

distribuidas para que el sistema se recupere de fallas?

Transacciones distribuidas:

Una transacción distribuida es aquella que involucra algún proceso en distintos sitios de la
red. Llamaremos a estos procesos los agentes de la transacción, entonces una transacción
distribuida está compuesta por varios agentes. Para llevar a cabo una transacción
distribuida los agentes tienen que comunicarse a través de mensajes en la red y se debe
garantizar la atomicidad de la transacción.

Transacciones Distribuidas:
1. Existe un agente raíz que inicia toda la transacción, así que cuando el usuario
requiere la ejecución de una aplicación distribuida el agente raíz es iniciado; el sitio
del agente raíz es llamado el sitio origen de la transacción.

2. El agente raíz tiene la responsabilidad de asegurar BEGIN-TRANSACTION, COMMIT O

ROLLBACK de toda la transacción distribuida
Ejemplo:
¿Qué es el Registro de Transacciones SQL Server?
SQL Server registra información acerca de cada transacción hecha en el registro de
transacciones antes de que los cambios sean escritos a la base de datos. La cantidad de
información registrada depende del modelo de recuperación de su base de datos. SQL
Server ofrece 3 modelos de recuperación diferentes: Completo, Por medio de registros de
operaciones masivas y Simple.

Modelos de Recuperación
Modelo de recuperación COMPLETO:

Este modelo de recuperación registra cada cambio a cada fila así como una copia de
cada página añadida a los índices o tablas. Como tal el registro contiene suficiente
información para poder reconstruir completamente cada acción que ocurrió en la base de
datos, permitiéndole restaurar su base de datos a un punto de tiempo específico, dado que
usted tienen una cadena de registro completa.

Todas las entradas son mantenidas en el registro de transacciones en línea hasta que el
registro es respaldado, después de lo cual sólo las transacciones activas permanecerán en
el registro en línea. Esto significa que para obtener información acerca de las transacciones
completadas desde el registro, las copias de seguridad tendrán que ser tomadas en cuenta.

Modelo De Recuperación Por Medio De Registros De Operaciones Masivas:

Cuando usted está usando la opción De recuperación BULK_LOGGED, Todas las operaciones
mínimamente registradas no son escritas en el registro. Las operaciones mínimamente
registradas son operaciones como SELECT INTO, BULK INSERT y operaciones de Índice.

El registro es manejado en la misma manera que en el modelo de recuperación COMPLETO,

y las transacciones inactivas son movidas a la copia de seguridad del registro cuando una
copia de seguridad es tomada. Por supuesto, la información acerca de las transacciones
masivas no está disponible.

Modelo De Recuperación Simple:

El modelo de recuperación SIMPLE sólo registra suficiente información para permitirle

recuperar su base de datos. Todas las entradas inactivas del registro son automáticamente
truncadas cuando se pasa un punto de control. Todas las operaciones todavía son
registradas, pero tan pronto como se alcanza el punto de control el registro es
automáticamente truncado,

Clasificación de fallas.
Tipo de Fallas: El sistema debe estar preparado para recuperarse no sólo de fallas
puramente locales, como la aparición de una condición de desborde dentro de una
transacción, sino también de fallas globales, como podría ser la interrupción del suministro
eléctrico al CPU.

Las fallas locales son las que afectan sólo a la transacción en donde ocurrió. Por el contrario
las fallas globales, afectan a varias -y casi siempre a todas- las transacciones que se estaban
efectuando en el momento de la falla, por lo cual tienen implicaciones importantes en el
sistema. Estas fallas pueden ser:

Falla del sistema:

Por ejemplo interrupción del servicio eléctrico, estas afectan a todas Las transacciones que
se estaban ejecutando pero no afectan a la base de datos.

 Las fallas de sistema se conocen también como caídas (crash) suaves.

 El problema aquí es que se pierda el contenido de memoria principal, en particular,
las áreas de almacenamiento temporal o buffers.
 Si esto ocurre, no se conocerá el estado preciso de la transacción que se estaba
ejecutando en el momento de la falla, esta transacción jamás se podrá completar
con éxito por lo que será preciso anularla cuando se reinicie el sistema.
 Además, puede ocurrir que sea necesario volver a ejecutar algunas transacciones
que sí se realizaron con éxito antes de la falla pero cuyas modificaciones no lograron
Efectuarse sobre la base de datos porque no lograron ser transferidas de los buffers
de la base de datos a la base de Datos física (en disco).
¿Qué se registra en el registro de transacciones?

Se registra cada evento en una base de datos en mayor o menor grado.

Cuando una transacción comienza o termina

Cada update, insert o delete
Eliminación y creación de tablas e índices
Grado y página de asignaciones y des asignaciones
Truncado de tablas

El registro de transacciones SQL Server es un archivo que usualmente tiene la extensión

.LDF. Aunque es posible tener múltiples archivos de registro para una base de datos, el
registro de transacciones es siempre escrito secuencialmente y múltiples archivos físicos de
registros son tratados como un archivo continuo circular
El siguiente comando puede ser ejecutado para ver cuánto archivos de registro virtuales
hay, cuántos han sido usados y cuáles son sus tamaños. Esto será usado para determinar
cuál tamaño y cuál incremento son los correctos
Leyendo el Registro de Transacciones SQL Server
Aun cuando Microsoft no provee una herramienta, hay muchas funciones no documentadas
que pueden ser usadas para ver el registro. Dado que estos procedimientos son no
documentados, ellos tampoco son soportados por Microsoft y por tanto vienen con el aviso
de “Use a su propio riesgo”. Han habido algunos reportes de que fn_db_dumplog crea un
itinerario oculto del OS y algunos hilos que aparentemente permanecen en el servidor hasta
que es reiniciado

fn_dblog()

Esta función con valores de tabla (la cual fue DBCC LOG previamente a SQL Server 2005) le
permite ver las entradas en registros de transacciones en línea. Este procedimiento acepta
2 parámetros, el LSN de inicio y de final. Para ver todas las entradas disponibles, NULL puede
ser pasado por ambos parámetros, y todas las entradas en la porción activa del registro en
línea serán mostradas.

fn_dump_dblog()

Esta función lee el registro en línea y las copias de seguridad del registro y acepta 68
parámetros. Todos los parámetros necesitan ser especificados para ejecutar la sentencia
Conclusión
Para concluir con el presente trabajo se llegó al análisis sobre leer el registro de
transacciones ofrece la habilidad de auditar e investigar la actividad de la base de datos
después del hecho. El formato en el cual el registro de transacciones SQL Server es escrito
requiere un decodificado cuidadoso de cada artículo para entender qué valores han sido
afectados. Microsoft no provee herramientas de lectura de registros aparte de 2 funciones
que leen y muestran pero no decodifican los datos del registro.

Referencias
http://www.carlosproal.com/bda/files/bda_redise%F1ado/documents/bases_datos_distribuidas/
TransDist.pdf

https://www.sqlshack.com/es/leyendo-el-registro-de-transacciones-sql-server/

https://codeday.me/es/qa/20190312/299986.html