miércoles, 6 de junio de 2018

ADMINISTRACIÓN DE LA SEGURIDAD

UNIVERSIDAD POLITÉCNICA AMAZÓNICA

TEMA: ADMINISTRACIÓN DE LA SEGURIDAD

ASIGNATURA: BASE DE DATOS II

DOCENTE: MARCO AURELIO PORRO CULLI

INTEGRANTES: PORTOCARRERO LABAJOS MAGALY

SOTO HORNA KARIN JUNETH

MEGO SAAVEDRA LUCY

Base de Datos II

I. Tema: Administración de la Seguridad de SQL Server

1. Contenido

 Definición

Las cuentas y roles de SQL SERVER tienen un papel fundamental en la seguridad de Windows Server usa estas entidades de SQL Server para controlar el acceso a almacenes y tablas que contienen datos de operaciones de seguimiento, así como datos de control de estado relacionados con la persistencia de flujo de trabajo.

Si desea crear cuentas y roles y ver, manipular y asignar los permisos adecuados a los objetos de base de datos, use las herramientas de ayuda que se incluyen con la instalación de la base de datos.

SQL Server usa los inicios de sesión y roles de SQL Server para administrar el acceso a activos como los almacenes de seguimiento y persistencia y los procedimientos almacenados. Se usan permisos para aplicar directivas de seguridad a tablas y procedimientos almacenados para determinar quién puede leer, escribir y realizar operaciones administrativas en los esquemas de seguimiento y persistencia. Cada esquema se protege mediante su propio grupo de directivas de seguridad.

 Autentificación

Es el proceso que debe seguir un usuario para tener acceso a los recursos de un sistema o de una red de computadores. Este proceso implica identificación (decirle al sistema quién es) y autenticación (demostrar que el usuario es quien dice ser)

SQL Server ofrece dos métodos para proteger la autenticación en sus servidores de bases de datos:

A. Autenticación de Windows. Modo de autenticación de Windows predeterminado. Es el más seguro para

SQL Server. Si se configura el modo de autenticación de Windows, SQL Server usa la seguridad de Windows para validar la cuenta y la contraseña de la cuenta de usuario solicitante con el sistema operativo Windows.

B. Autenticación de SQL Server. Modo de autenticación de SQL Server. Su finalidad es ofrecer compatibilidad con versiones anteriores a aplicaciones y usuarios que necesiten acceso a SQL Server con una cuenta de usuario y contraseña específicos. Es el modo menos seguro.

 Inicios de Sesión - Roles

Inicios de sesión de SQL Server

Es una entidad de seguridad o una entidad que puede ser autenticada por un sistema seguro. Los usuarios necesitan iniciar sesión para conectarse a SQL Server. Puede crear un inicio de sesión basado en una entidad de seguridad de Windows (como un usuario de dominio o un grupo de dominio de Windows) o puede crear un inicio de sesión que no lo esté (como un inicio de sesión de SQL Server).

Para realizar acciones de configuración o funcionamiento sobre los esquemas o datos de la base de datos, la cuenta de inicio de sesión debe estar asignada a un rol de SQL Server con los permisos adecuados. Un rol de SQL Server funciona como un grupo de Windows.

La asignación de una cuenta de inicio de sesión a un rol de SQL determina el control de dicha cuenta sobre las actividades administrativas y las operaciones en la base de datos. Una cuenta de inicio de sesión puede estar asignada a más de un rol de base de datos.

Los inicios de sesión de SQL Server por defecto encontramos:

(administrador)	Es un usuario especial que existe en todas las bases de datos, y como tal, no puede ser eliminado de la misma.
Guest (invitado)	Permite iniciar una sesión sin una cuenta de usuario que de acceso a la base de datos. Se pueden añadir y eliminar cuentas de usuario invitado en cualquier base de datos, excepto en las bases master y tempdb.

Roles SQL Server A. Rol de “SERVIDOR” de SQL

Server: Un rol de “servidor” de SQL Server se define a nivel de servidor fuera de cualquier almacén. Los roles de SQL Server están predefinidos y su número y su contenido no se pueden modificar. Un ejemplo de rol de servidor común es sysadmin.

Este rol ofrece a la cuenta de inicio de sesión un control total sobre todas las operaciones de la base de datos y la capacidad de realizar cualquier operación sobre los datos de SQL Server de cualquier almacén.

B. Rol de “APLICACIÓN” de SQL Server: Los roles de aplicación satisfacen las necesidades de seguridad más complejas y personalizadas de una aplicación particular. Varias aplicaciones pueden usar un almacén con la necesidad común de proteger la seguridad de sus datos durante el acceso de una de las aplicaciones.

C. Rol de “BASE DE DATOS” de SQL Server: Usa el rol de base de datos de forma generalizada. Existen tres tipos de roles de base de datos: públicos, definidos por el usuario y fijos. A fin de ofrecer una información exhaustiva, a continuación se describen detalladamente.

AppFabric usa el modelo de rol de base de datos definido por el usuario de forma exclusiva para gran parte de su seguridad en SQL Server.

Existen tres tipos de roles de base de datos de SQL Server:

 Público: El rol de base de datos público contiene un permiso de acceso predeterminado para todos los usuarios de base de datos. Por lo tanto, todas las cuentas de inicio de sesión que se crean a través de AppFabric son miembros de este rol.

 Fijo: Del mismo modo que los roles de “servidor” de SQL Server (por ejemplo, sysadmin), los roles de base de datos fijos no se pueden modificar. Al contrario de lo que sucede con los roles de servidor, que existen a nivel de servidor, los roles de base de datos existen a nivel de base de datos para cada almacén. Un ejemplo de rol de base de datos fijo es db_owner.

Se pueden agregar o quitar cuentas de usuario de inicio de sesión de SQL Server a roles de base de datos fijos.

 Definido por el Usuario: Crea roles de base de datos definidos por los usuarios específicos en blanco durante la instalación. El programa de instalación de AppFabric no inserta explícitamente ninguna cuenta de Windows o cuenta de inicio de sesión de SQL Server en los roles de base de datos definidos por el usuario. Para agregar cuentas, es necesario usar las herramientas de administración de SQL Server.

 Ejemplos

Ejemplo del esquema de una base de datos en Oracle

2. Resumen

Tema: Administración de la Seguridad de SQL Server

1. Contenido

 Definición

Si desea crear cuentas y roles y ver, manipular y asignar los permisos adecuados a los objetos de base de datos, use las herramientas de ayuda que se incluyen con la instalación de la base de datos.

 Autentificación

SQL Server ofrece dos métodos para proteger la autenticación en sus servidores de bases de datos:

Autenticación de Windows. Modo de autenticación de Windows predeterminado.

Autenticación de SQL Server. Modo de autenticación de SQL Server.

 Inicios de Sesión - Roles

Inicios de sesión de SQL Server

Roles SQL Server A. Rol de “SERVIDOR” de SQL

Rol de “APLICACIÓN” de SQL Server: Los roles de aplicación satisfacen las necesidades de seguridad más complejas y personalizadas de una aplicación particular.

Rol de “BASE DE DATOS” de SQL Server: Usa el rol de base de datos de forma generalizada. Existen tres tipos de roles de base de datos: públicos, definidos por el usuario y fijos.

2. Summary

       Topic: SQL Server Security Administration

1. Content

… Definition

The accounts and roles of SQL SERVER have a fundamental role in the security of Windows Server uses these entities of SQL Server to control access to stores and tables that contain data tracking operations, as well as status control data related to persistence of work flow.

If you want to create accounts and roles and view, manipulate and assign the appropriate permissions to the database objects, use the help tools that are included with the installation of the database.

… Authentication

It is the process that a user must follow to access the resources of a system or a network of computers. This process involves identification (telling the system who it is) and authentication (showing that the user is who they say they are)

SQL Server offers two methods to protect authentication on your database servers:

Windows authentication. Default Windows authentication mode.

SQL Server authentication. SQL Server authentication mode.

… Beginnings of Session - Roles

SQL Server session starts

It is a security entity or an entity that can be authenticated by a secure system. Users need to log in to connect to SQL Server. You can create a logon based on a Windows security principal (such as a domain user or a Windows domain group) or you can create a logon that is not (such as a SQL Server logon).

To perform configuration or operation actions on the schemas or data of the database, the login account must be assigned to a SQL Server role with the appropriate permissions. A SQL Server role works like a Windows group.

Roles SQL Server A. SQL "SERVER" role

Server: A SQL server "server" role is defined at the server level outside any warehouse. SQL Server roles are predefined and their number and content can not be modified. An example of a common server role is sysadmin.

"APPLICATION" role of SQL Server: Application roles meet the most complex and customized security needs of a particular application.

"DATABASE" role of SQL Server: Uses the database role in a generalized way. There are three types of database roles: public, user defined, and fixed.

3. Recomendaciones

Ø Optimiza los índices. Tener una buena relación de índices entre tablas es básico para las búsquedas relacionales funcionen correctamente. Agrega índices a las tablas y, sobre ellas, utiliza las sentencias de consulta (SELECT, WHERE…). También resulta recomendable acostumbrarse a verificar periódicamente el registro de consultas (o “queries”) lentas para identificar aquellas que deben ser optimizadas.

Ø No mantengas consultas abiertas en tu código y realiza las querys justas. Así, evitamos saturar la memoria de la máquina. Como sucede en cualquier sistema informático, un proceso abierto afecta al rendimiento del hardware. Eliminando esas consultas inútiles, liberarás recursos para que se empleen en las consultas útiles que necesitamos.

Ø En general, no almacenes imágenes en la base de datos. Sólo referencias a la ruta en la que se encuentran y metadatos para identificarlas. No nos engañemos, las bases de datos crecen y crecen y las imágenes siguen aumentando en tamaño a su propio ritmo. Si mantienes sólo las referencias al almacén de imágenes, la base de datos estará en forma para devolverte los procesos más rápidamente.

4. Conclusiones

v La seguridad del BD está formada por mecanismos que protegen al BD frente a amenazas intencionadas o accidentales.

v El control de seguridad incluye:

· Mecanismos de autorización, controles de acceso, esquemas externos, copias de seguridad y de recuperación, mecanismos de integridad, sistemas de cifrado y tecnología RAID.

v La carencia, la deficiencia o el mal diseño de medidas de seguridad en un BD puede no cumplir las leyes.

5. Apreciación del Equipo

v Podemos decir que un SBD está compuesto por: Software, Hardware, Datos Usuario e indicar las medidas de seguridad que se deben tomar para proteger cada uno de estos tipos de elementos.

6. Bibliografía o Linkografía

http://ict.udlap.mx/people/carlos/is346/admon03.html

https://es.wikipedia.org/wiki/Administrador_de_base_de_datos

LINK DE DIAPOSITIVAS

https://es.slideshare.net/MagalyPortocarreroLa/administracion-de-la-seguridad

TRANSACCIONES

UNIVERSIDAD POLITÉCNICA AMAZÓNICA

TEMA: TRANSACCIONES

ASIGNATURA: BASE DE DATOS II

DOCENTE: MARCO AURELIO PORRO CULLI

INTEGRANTES: PORTOCARRERO LABAJOS MAGALY

SOTO HORNA KARIN JUNETH

MEGO SAAVEDRA LUCY

Base de Datos II

I. Tema: Transacciones

1. Contenido

 Definición

Es una unidad única de trabajo. Si una transacción tiene éxito, todas las modificaciones de los datos realizadas durante la transacción se confirman y se convierten en una parte permanente de la base de datos.

Si una transacción encuentra errores y debe cancelarse o revertirse, se borran todas las modificaciones de los datos.

Es considerado como un grupo de una o varias instrucciones de base de datos totalmente confirmadas o totalmente revertidas. Cada transacción es atómica, coherente, aislada y durable (ACID).

El principio y el final de las transacciones dependen de la configuración de AUTOCOMMIT y de las instrucciones BEGIN TRANSACTION, COMMIT y ROLLBACK

 Propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad)

 Atomicidad: Las operaciones que componen una transacción deben considerarse como una sola.

Una transacción es una unidad de trabajo en la que se produce una serie de operaciones entre las instrucciones BEGIN TRANSACTION y END TRANSACTION de una aplicación. Una transacción se ejecuta exactamente una vez y tiene carácter "atómico" (de subdivisión), es decir, el trabajo se realiza en su totalidad o no se realiza en ningún caso.

Las operaciones asociadas a una transacción comparten normalmente un objetivo común y son interdependientes. Si el sistema ejecutase únicamente una parte de las operaciones, podría poner en peligro el objetivo final de la transacción. La atomicidad elimina la posibilidad de procesar un subconjunto de operaciones.

 Consistencia: Una operación nunca deberá dejar datos inconsistentes.

Una transacción es una unidad de integridad porque mantiene la coherencia de los datos, transformando un estado coherente de datos en otro estado de datos igualmente coherente.

Se requiere que los datos enlazados mediante una transacción se mantengan en términos de semántica. Una parte de la responsabilidad para mantener la coherencia recae en el programador de la aplicación que debe asegurarse de que ésta exija todas las restricciones de integridad conocidas.

 Aislamiento: Los datos "sucios" deben estar aislados, y evitar que los usuarios utilicen información que aún no está confirmada o validada.

El aislamiento requiere que parezca que cada transacción sea la única que manipula el almacén de datos, aunque se puedan estar ejecutando otras transacciones al mismo tiempo. Una transacción nunca debe ver las fases intermedias de otra transacción.

Las transacciones alcanzan el nivel máximo de aislamiento cuando se pueden serializar. En este nivel, los resultados obtenidos de un conjunto de transacciones concurrentes son idénticos a los obtenidos mediante la ejecución en serie de las transacciones.

Como un alto grado de aislamiento puede limitar el número de transacciones concurrentes, algunas aplicaciones reducen el nivel de aislamiento en el intercambio para mejorar el rendimiento.

 Durabilidad: Una vez completada la transacción los datos actualizados ya serán permanentes y confirmados.

Si una transacción se realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen, aunque el equipo falle inmediatamente después de la confirmación. El registro especializado permite que el procedimiento de reinicio del sistema complete las operaciones no finalizadas, garantizando la permanencia de la transacción.

 Tipos de Transacciones (Implícitas, Explícitas, ámbito de lote, etc.)

A. De Confirmación Automática: El Gestor de Datos inicia una transacción automáticamente por cada operación que actualice datos. De este modo mantiene siempre la consistencia de la base de datos, aunque puede generar bloqueos.

B. Implícitas: Cuando el Gestor de Datos comienza una transacción automáticamente cada vez que se produce una actualización de datos, pero el que dicha transacción se confirme o se deshaga, lo debe indicar el programador.

Se inicia implícitamente una nueva transacción cuando se ha completado la anterior, pero cada transacción se completa explícitamente con una instrucción COMMIT o ROLLBACK.

C. Explícitas: Son las que iniciamos nosotros "a mano" mediante instrucciones SQL, los programadores son los que indican qué operaciones va a abarcar.

Cada transacción se inicia explícitamente con la instrucción BEGIN TRANSACTION y se termina explícitamente con una instrucción COMMIT o ROLLBACK.

D. Transacciones de Ámbito de Lote: Una transacción implícita o explícita de Transact-SQL que se inicia en una sesión de MARS (conjuntos de resultados activos múltiples), que solo es aplicable a MARS, se convierte en una transacción de ámbito de lote. Si no se confirma o revierte una transacción de ámbito de lote cuando se completa el lote, SQL Server la revierte automáticamente.

 Comandos BEGIN TRANSACTION, ROLLBACK TRANSACTION y COMMIT TRANSACTION

A. BEGIN TRANSACTION

Marca el punto de inicio de una transacción explícita.

Representa un punto en el que los datos a los que hace referencia una conexión son lógica y físicamente coherentes. Si se producen errores, se pueden revertir todas las modificaciones realizadas en los datos después de BEGIN TRANSACTION para devolver los datos al estado conocido de coherencia.

Cada transacción dura hasta que se completa sin errores y se emite COMMIT

TRANSACTION para hacer que las modificaciones sean una parte permanente de la base de datos, o hasta que se produzcan errores y se borren todas las modificaciones con la instrucción ROLLBACK TRANSACTION.

B. COMMIT

Marca el final de una transacción explícita o de confirmación automática. Esta instrucción hace que los cambios en la transacción se confirmen permanentemente en la base de datos. La instrucción COMMIT es idéntica a COMMIT WORK, COMMIT TRAN y COMMIT TRANSACTION.

Si la transacción que se ha confirmado era una transacción Transact-SQL distribuida, COMMIT TRANSACTION hace que MS DTC utilice el protocolo de confirmación en dos fases para confirmar los servidores involucrados en la transacción.

Si una transacción local afecta a dos o más bases de datos de la misma instancia del Motor de base de datos, la instancia utiliza una confirmación interna en dos fases para confirmar todas las bases de datos involucradas en la transacción.

C. ROLLBACK

Revierte una transacción al principio de la misma. No se confirman cambios para la transacción en la base de datos. La instrucción ROLLBACK es idéntica a ROLLBACK WORK, ROLLBACK TRAN y ROLLBACK TRANSACTION.

Una transacción no se puede revertir después de ejecutar una instrucción COMMIT TRANSACTION, excepto cuando COMMIT TRANSACTION está asociada a una transacción anidada incluida en la transacción que se revierte. En esta instancia, la transacción anidada se revierte, incluso si ha emitido una instrucción COMMIT TRANSACTION para ella.

 Ejemplos

Un ejemplo

Trabajaremos con la base de datos Northwind en nuestros ejemplos. Vamos a realizar una transacción que modifica el precio de dos productos de la base de datos.

USE NorthWind

DECLARE @Error int

--Declaramos una variable que utilizaremos para almacenar un posible código de error

BEGIN TRAN

--Iniciamos la transacción

UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'

--Ejecutamos la primera sentencia

SET @Error=@@ERROR

--Si ocurre un error almacenamos su código en @Error

--y saltamos al trozo de código que deshara la transacción. Si, eso de ahí es un

--GOTO, el demonio de los programadores, pero no pasa nada por usarlo

--cuando es necesario

IF (@Error<>0) GOTO TratarError

--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda

UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'

SET @Error=@@ERROR

--Y si hay un error hacemos como antes

IF (@Error<>0) GOTO TratarError

--Si llegamos hasta aquí es que los dos UPDATE se han completado con

--éxito y podemos "guardar" la transacción en la base de datos

COMMIT TRAN

TratarError:

--Si ha ocurrido algún error llegamos hasta aquí

If @@Error<>0 THEN

BEGIN

PRINT 'Ha ecorrido un error. Abortamos la transacción'

--Se lo comunicamos al usuario y deshacemos la transacción

--todo volverá a estar como si nada hubiera ocurrido

ROLLBACK TRAN

END

2. Resumen

Definición

Es una unidad única de trabajo. Si una transacción tiene éxito, todas las modificaciones de los datos realizadas durante la transacción se confirman y se convierten en una parte permanente de la base de datos.

Si una transacción encuentra errores y debe cancelarse o revertirse, se borran todas las modificaciones de los datos.

Propiedades

 Atomicidad: Las operaciones que componen una transacción deben considerarse como una sola.

Una transacción es una unidad de trabajo en la que se produce una serie de operaciones entre las instrucciones BEGIN TRANSACTION y END TRANSACTION de una aplicación.

 Consistencia: Una operación nunca deberá dejar datos inconsistentes.

Una transacción es una unidad de integridad porque mantiene la coherencia de los datos, transformando un estado coherente de datos en otro estado de datos igualmente coherente.

Se requiere que los datos enlazados mediante una transacción se mantengan en términos de semántica. Una parte de la responsabilidad para mantener la coherencia recae en el programador de la aplicación que debe asegurarse de que ésta exija todas las restricciones de integridad conocidas.

 Aislamiento: Los datos "sucios" deben estar aislados, y evitar que los usuarios utilicen información que aún no está confirmada o validada.

El aislamiento requiere que parezca que cada transacción sea la única que manipula el almacén de datos, aunque se puedan estar ejecutando otras transacciones al mismo tiempo. Una transacción nunca debe ver las fases intermedias de otra transacción.

 Durabilidad: Una vez completada la transacción los datos actualizados ya serán permanentes y confirmados.

Si una transacción se realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen, aunque el equipo falle inmediatamente después de la confirmación.

Tipos

De Confirmación Automática: El Gestor de Datos inicia una transacción automáticamente por cada operación que actualice datos. De este modo mantiene siempre la consistencia de la base de datos, aunque puede generar bloqueos.

Implícitas: Cuando el Gestor de Datos comienza una transacción automáticamente cada vez que se produce una actualización de datos, pero el que dicha transacción se confirme o se deshaga, lo debe indicar el programador.

Explícitas: Son las que iniciamos nosotros "a mano" mediante instrucciones SQL, los programadores son los que indican qué operaciones va a abarcar.

Transacciones de Ámbito de Lote: Una transacción implícita o explícita de Transact-SQL que se inicia en una sesión de MARS (conjuntos de resultados activos múltiples), que solo es aplicable a MARS, se convierte en una transacción de ámbito de lote.

Transacciones SQL Server

A. BEGIN TRANSACTION.

Cada transacción dura hasta que se completa sin errores y se emite COMMIT TRANSACTION para hacer que las modificaciones sean una parte permanente de la base de datos, o hasta que se produzcan errores y se borren todas las modificaciones con la instrucción ROLLBACK TRANSACTION.

B. COMMIT

C. ROLLBACK

3. Summary

Definition

It is a unique unit of work. If a transaction is successful, all changes to the data made during the transaction are confirmed and become a permanent part of the database.

If a transaction encounters errors and must be canceled or reversed, all changes to the data are deleted.

Properties

… Atomicity: The operations that make up a transaction should be considered as one.

A transaction is a unit of work in which a series of operations occurs between the instructions BEGIN TRANSACTION and END TRANSACTION of an application.

… Consistency: An operation should never leave inconsistent data.

A transaction is an integrity unit because it maintains the coherence of the data, transforming a coherent state of data into another equally coherent data state.

It is required that the data linked through a transaction be maintained in terms of semantics. Part of the responsibility for maintaining consistency rests with the application programmer who must ensure that it requires all known integrity restrictions.

… Isolation: "Dirty" data should be isolated, and avoid users using information that is not yet confirmed or validated.

Isolation requires that each transaction appear to be the only one that manipulates the data store, even though other transactions may be running at the same time. A transaction should never see the intermediate phases of another transaction.

… Durability: Once the transaction is completed, the updated data will be permanent and confirmed.

If a transaction is successful, the system guarantees that its updates are maintained, even if the device fails immediately after confirmation.

Types

Automatic Confirmation: The Data Manager initiates a transaction automatically for each operation that updates data. In this way it always maintains the consistency of the database, although it can generate blockages.

Implicit: When the Data Manager starts a transaction automatically every time a data update occurs, but the fact that the transaction is confirmed or undoes, the programmer must indicate it.

Explicit: They are the ones that we initiate "by hand" by means of SQL instructions, the programmers are the ones that indicate which operations they will cover.

Batch Scope Transactions: An implicit or explicit Transact-SQL transaction that is initiated in a MARS session (multiple active result sets), which is only applicable to MARS, becomes a batch domain transaction.

SQL Server Transactions

A. BEGIN TRANSACTION.

Each transaction lasts until it is completed without errors and COMMIT TRANSACTION is issued to make the modifications a permanent part of the database, or until errors occur and all modifications are deleted with the ROLLBACK TRANSACTION statement.

B. COMMIT

Mark the end of an explicit transaction or automatic confirmation. This instruction causes the changes in the transaction to be permanently committed in the database. The COMMIT statement is identical to COMMIT WORK, COMMIT TRAN, and COMMIT TRANSACTION.

C. ROLLBACK

Reverts a transaction to the beginning of it. No changes are confirmed for the transaction in the database. The ROLLBACK statement is identical to ROLLBACK WORK, ROLLBACK TRAN and ROLLBACK TRANSACTION.

A transaction can not be rolled back after executing a COMMIT TRANSACTION statement, except when COMMIT TRANSACTION is associated with a nested transaction included in the transaction that is rolled back.

4. Recomendaciones

Si el registro de transacciones resulta dañado, perderá el trabajo realizado desde la última copia de seguridad válida. Por tanto, le recomendamos encarecidamente que sitúe los archivos de registro en un almacenamiento con tolerancia a errores.

Si una base de datos se daña o se va a restaurar, se recomienda crear una copia del final del registro para que pueda restaurar la base de datos hasta el momento actual.

De forma predeterminada, cada operación de copia de seguridad correcta agrega una entrada en el registro de errores de SQL Server y en el registro de eventos del sistema. Si hace una copia de seguridad del registro de transacciones con frecuencia, estos mensajes que indican la corrección de la operación pueden acumularse rápidamente, con lo que se crean registros de errores muy grandes que pueden dificultar la búsqueda de otros mensajes. En esos casos, puede suprimir estas entradas de registro utilizando la marca de seguimiento 3226 si ninguno de los scripts depende de esas entradas. Para obtener más información, vea Marcas de seguimiento (Transact-SQL).

Realice copias de seguridad de registros suficientemente regulares para ajustarse a los requisitos de la empresa, específicamente a la tolerancia a la pérdida de trabajo que un almacenamiento de registro dañado podría provocar.

La frecuencia adecuada para realizar copias de seguridad de registros varía en función de la tolerancia al riesgo de pérdida de trabajo y, por otra parte, de la cantidad de copias de seguridad de registros que puede almacenar, administrar y, potencialmente, restaurar. Tenga en cuenta los RTO y RPO necesarios al implementar la estrategia de recuperación, específicamente el ritmo de realización de copias de seguridad de registros.

Una copia de seguridad de registros cada 15 ó 30 minutos puede ser suficiente. Si su empresa necesita minimizar el riesgo de pérdida de trabajo, piense en la posibilidad de realizar copias de seguridad de registros más frecuentemente. La existencia de copias de seguridad más frecuentes de los registros tiene la ventaja añadida de aumentar la frecuencia de truncamiento del registro, lo que genera archivos de registro menores.

5. Conclusiones

ü Es difícil imaginar hoy en día la concentración de información sin base de datos, las pequeñas o grandes industrias tienen como base de su sistema informático la construcción de base de datos con la que podemos tener gran versatilidad con cualquier tipo de equipos.

ü La seguridad en las bases de datos es muy importante debido a que garantiza la integridad física y lógica de los datos.

6. Apreciación del Equipo

ü Para crear una base se deben realizar dos ejercicios de diseño: un diseño lógico y uno físico. El diseño lógico de una base de datos es un modelo abstracto de la base de datos desde una perspectiva de negocios, mientras que el diseño físico muestra como la base de datos se ordena en realidad en los dispositivos de almacenamiento de acceso directo. El diseño físico de la base de datos es llevado a cabo por los especialistas en bases de datos, mientras que el diseño lógico requiere de una descripción detallada de las necesidades de información del negocio de los negocios actuales usuarios finales de la base. Idealmente, el diseño de la base será una parte del esfuerzo global de la planeación de datos a nivel institucional.

7. Bibliografía o Linkografía

www.monografias.com LA TRANSACCION www.microsoft.com / sqlserver TRANSACCIONES FUNDAMENTOS DE BASES DE DATOS Abraham Silberschatz Mc Graw

https://es.wikipedia.org

https://msdn.microsoft.com

https://mariadb.com/kb

https://msdn.microsoft.com

Link de diapositivas

https://es.slideshare.net/MagalyPortocarreroLa/transacciones-101060074