Fundamentos de SQL: Transacciones

Antes de nada una definición:

Una transacción es una unidad de trabajo compuesta por diversas tareas, cuyo resultado final debe ser quese ejecuten todas o ninguna de ellas.

SQL-Transacciones

Por regla general en un sistema de base de datos todas las operaciones relacionadas entre sí que se ejecuten dentro un mismo flujo lógico de trabajo, deben ejecutarse en bloque. De esta manera si todas funcionan la operación conjunta de bloque tiene éxito, pero si falla cualquiera de ellas, deberán retrocederse todas las anteriores que ya se hayan realizado. De esta forma evitamos que el sistema de datos quede en un estado incongruente.

BONUS: Consigue tu ebook recopilatorio GRATIS >> Héroe en SQL: manual de iniciación

Por ejemplo, si vamos al banco y ordenamos una transferencia para pagar una compra que hemos realizado por Internet, el proceso en sí está formado por una conjuto (o bloque) de operaciones que deben ser realizadas para que la operación global tenga éxito:

  1. Comprobar que nuestra cuenta existe es válida y está operativa.
  2. Comprobar si hay saldo en nuestra cuenta.
  3. Comprobar los datos de la cuenta del vendedor (que existe, que tiene posibilidad de recibir dinero, etc…).
  4. Retirar el dinero de nuestra cuenta
  5. Ingresar el dinero en la cuenta del vendedor.

Dentro de este proceso hay cinco operaciones, las cuales deben tener éxito o fallar conjuntamente.

En el caso de las operaciones 4 y 5 que modifican datos es algo obvio que no puede funcionar una y fallar la otra. Si se retira el dinero de nuestra cuenta en el paso 4 y hay algún problema que evita que pueda continuar el proceso, el dinero habrá salido de nuestra cuenta pero no se ha anotado en la cuenta de destino porque se ha producido un error. De repente hay un dinero que ha desaparecido y la base de datos se encuentra en un estado inconsistente. Es evidente que esto no puede ocurrir.

Precisamente para evitar este tipo de situaciones existen las transacciones: marcan bloques completos de operaciones y comprueban que, o se realizan todas, o que si hay algún problema se deshacen todas.

En nuestro ejemplo de transferencia fallida, al producirse un error en el paso 5 se habría deshecho automáticamente la operación de retirada de dinero del paso 4 y toda la información habría quedado como antes de comenzar el proceso.

Otro tema importante relacionado con las transacciones es la gestión de la concurrencia y los bloqueos. En el ejemplo del banco los 3 primeros pasos realmente no implican modificación alguna de datos, por lo que si fallan no dejan la base de datos en un estado inconsistente ¿o quizá sí?. ¿Qué pasaría si al mismo tiempo que se está realizando nuestra transferencia, entra en nuestra cuenta un cargo diferido que teníamos pendiente? Sería posible que de repente nos quedásemos sin saldo para realizar la operación actual o, peor aún, que se anotasen mal ambos cargos en cuenta de modo que se “pisasen” dejando un saldo inconsistente. O puede que entre los pasos 3 y 5 la cuenta del vendedor de repente se haya cancelado, justo en medio de la operación. El dinero iría a parar a una cuenta no válida.

Para controlar el comportamiento de las transacciones en estos casos se definen diferentes niveles de aislamiento de una transacción.

Otro ejemplo más común: la creación de un pedido. En este proceso se debe consultar antes la tabla de productos y ver si hay stock, se inserta un registro en la tabla de pedidos (quién hace el pedido, sus datos, fecha, importe total..), uno o varios registros en la tabla de detalles del pedido (qué productos se incluyen y su cantidad),  y se actualiza la tabla de stock de productos. Si además se genera al mismo tiempo la factura, el proceso continua involucrando a varias tablas más (cabeceras de factura, líneas de factura). En este caso también es muy importante que se lleve la operación a cabo por completo o que se deshaga por completo, ya que sino nos encontraríamos con datos incoherentes.

Existen infinidad de posibilidades de que algo salga mal  en cualquier proceso que involucre varias operaciones, y las posibilidades de fallo se multiplican a medida que aumenta la simultaneidad de acceso a la misma información. Por eso los sistemas de datos grandes son muy complejos.

Para todas estas situaciones nos ayudan las transacciones.

Propiedades ACID

Una transacción, para cumplir con su propósito y protegernos de todos los problemas que hemos visto, debe presentar las siguientes características:

  • Atomicidad: las operaciones que componen una transacción deben considerarse como una sola.
  • Consistencia: una operación nunca deberá dejar datos inconsistentes.
  • Aislamiento: los datos “sucios” deben estar aislados, y evitar que los usuarios utilicen información que aún no está confirmada o validada. (por ejemplo: ¿sigue siendo válido el saldo mientras realizo la operación?)
  • Durabilidad: una vez completada la transacción los datos actualizados ya serán permanentes y confirmados.

A estas propiedades se las suele conocer como propiedades ACID (de sus siglas en inglés: Atomicity, Consistency,Isolation y Durability).

Cómo definir transacciones

Por regla general en los gestores de datos relacionales modernos disponemos de tres tipos de transacciones según la forma de iniciarlas:

  • 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 SQ. somos nosotros, los programadores, los que indicamos qué operacio0nes va a abarcar.

Una transacción explícita se define de manera general con una instrucción que marca su inicio, y dos posibles instrucciones que marcan su final en función de si debe tener éxito o debe fracasar en bloque.

Cada sistema gestor de bases de datos tiene sus pequeñas particularidades, pero podemos escribir con un pseudo-código, la sintaxis de una transacción genérica:

BEGIN TRAN
      Operación 1...
      Si fallo: ROLLBACK TRAN 
       Operación 2....
       Si fallo: ROLLBACK TRAN
...

      Operación N....
      Si fallo: ROLLBACK TRAN
COMMIT TRAN

Es decir, se define el comienzo de una transacción, se comprueban posibles errores en cada paso, echando atrás todo el proceso (se le suele llamar “hacer un Rollback”), o confirmando el conjunto de operaciones completas al final del todo si no ha habido problemas (en la jerga habitual se suele hablar de “hacer un Commit”).

De hecho no suele ser necesario comprobar los errores por el camino ya que por regla general el gestor de datos si detecta un error en cualquiera de los pasos dentro de una transacción, realizará un rollback automático de toda la operación.

Transacciones en SQL Server

En SQL Server las instrucciones equivalentes a las genéricas que acabamos de ver son:

  • BEGIN TRANSACTION o BEGIN TRAN: marca el inicio de una transacción. TRAN es un sinónimo de TRANSACTION y se suele usar más a menudo por abreviar.
  • ROLLBACK TRANSATION o ROLLBACK TRAN: fuerza que se deshaga la transacción en caso de haber un problema o querer abandonarla. Cierra la transacción.
  • COMMIT TRANSACTION O COMMIT TRAN: confirma el conjunto de operaciones convirtiendo los datos en definitivos. Marca el éxito de la operación de bloque y cierra la transacción.

Los niveles de aislamiento que nos ofrece SQL Server son:

  • SERIALIZABLE: No se permitirá a otras transacciones la inserción, actualización o borrado de datos utilizados por nuestra transacción. Los bloquea mientras dura la misma.
  • REPEATABLE READ: Garantiza que los datos leídos no podrán ser cambiados por otras transacciones, durante esa transacción.
  • READ COMMITED: Una transacción no podrá ver los cambios de otras conexiones hasta que no hayan sido confirmados o descartados.
  • READ UNCOMMITTED: No afectan los bloqueos producidos por otras conexiones a la lectura de datos.
  • SNAPSHOT: Los datos seleccionados en la transacción se verán tal y como estaban al comienzo de la transacción, y no se tendrán en cuenta las actualizaciones que hayan sufrido por la ejecución de otras transacciones simultáneas.

La instrucción SET TRANSACTION ISOLATION LEVEL nos permite cambiar el nivel de aislamiento.

Puedes leer la documentación oficial sobre transacciones de SQL Server.

Transacciones en MySQL

Hay que tener en cuenta que MySQL es un gestor de datos relacional que soporta diversos motores de almacenamiento por debajo (al menos 20 la última vez que los contamos). De todos esos solamente unos pocos soportan transacciones. Los dos más comunes son el tradicional MyISAM y el más moderno InnoDB. De estos dossolamente InnoDB soporta el uso de transacciones (con razón myISAM es tan rápido: da mucha velocidad a costa de no ofrecer consistencia en las operaciones, lo cual puede ser muy útil para ciertos tipos de aplicaciones).

En MySQL InnoDB las instrucciones equivalentes a las genéricas son las siguientes:

  • START TRANSACTION o BEGIN: marca el inicio de una transacción. Se suele usar más a menudo BEGIN porque es más corto.
  • ROLLBACK: fuerza que se deshaga la transacción en caso de haber un problema o querer abandonarla. Cierra la transacción.
  • COMMIT: confirma el conjunto de operaciones convirtiendo los datos en definitivos. Marca el éxito de la operación de bloque y cierra la transacción.

En cuanto a los niveles de aislamiento que nos ofrece MySQL son los siguientes:

  • SERIALIZABLE
  • REPEATABLE READ
  • READ COMMITED
  • READ UNCOMMITTED

La instrucción que nos permite cambiar el nivel de aislamiento es también SET TRANSACTION ISOLATION LEVEL .

Puedes leer la documentación oficial sobre transacciones de MySQL. Hay unas cuantas particularidades así que conviene leerlo detenidamente.

Transacciones en Oracle

En Oracle las instrucciones equivalentes a las genéricas son las siguientes:

  • START TRANSACTION o BEGIN: marca el inicio de una transacción. Se suele usar más a menudo BEGIN porque es más corto.
  • ROLLBACK: fuerza que se deshaga la transacción en caso de haber un problema o querer abandonarla. Cierra la transacción.
  • COMMIT: confirma el conjunto de operaciones convirtiendo los datos en definitivos. Marca el éxito de la operación de bloque y cierra la transacción.

En cuanto a los niveles de aislamiento que nos ofrece Oracle son idénticos a los anteriores:

  • SERIALIZABLE
  • REPEATABLE READ
  • READ COMMITED
  • READ UNCOMMITTED

La instrucción que nos permite cambiar el nivel de aislamiento es también SET TRANSACTION ISOLATION LEVEL. Es interesante leer al respecto este artículo de su documentación oficial sobre concurrencia de datos y consistencia.

Puedes leer la documentación oficial sobre transacciones de Oracle.

Con este artículo terminamos con la serie dedicada a los fundamentos del lenguaje SQL y el manejo de información en sistemas gestores de datos relacionales.

via: http://www.campusmvp.es/recursos/post/fundamentos-de-sql-transacciones.aspx

[Solved] High Memory Usage by Metafile on Windows 2008 R2

Dear All,

Have you seen such type of task manager parameters in any of your server? if please read the below scenario

You can see the memory utilized is 98% and when I went to processes tab I saw as below

But when I tried to sum all processes memory it was not going beyond 50 % so where the memory is getting utilized?

Installed RAMMap.exe of sysinternals and checked

After reading lot on various blogs I came to know metafile is

” Metafile is part of the system cache and consists of NTFS metadata. NTFS metadata includes the MFT as well as the other various NTFS metadata files… In the MFT each file attribute record takes 1KB and each file has at least one attribute record. Add to this the other NTFS metadata files and you can see why the Metafile category can grow quite large on servers with lots of files ”

checked for file type wise disk space utilization and 98 % of E: contains around 228 GB of JPG files

So searched further for ” how to clean / reduce METAfIle size ” and most of blogs where suggesting to install Dynamic Cache Service so tried that also but the service doesn’t work with windows 2008 r2 Web edition.

Now what to do ?

After lots of efforts ….. got the solution

As I have clicked on “Empty System Working Set” the memory utilization started reducing from 98% to………. 48 % J

Thanks

Prashant Deshpande

via: https://prashantd.wordpress.com/2013/11/14/solved-high-memory-usage-by-metafile-on-windows-2008-r2/

Auditing SELECT statements in SQL Server 2008

Prior to SQL Server 2008, the only way to audit the SELECT statements is to use SQL Server Profiler or server side trace. Now using SQL Server 2008 Enterprise, auditing feature is used to audit on SELECT statements. We cannot use triggers as triggers are not fired on SELECT statements.

Audit object is used to monitor various sever and database level events without the need of full trace.

We need to create an Audit object and the Database Level Audit Specification in order to monitor when a SELECT statement is issued against a particular table.

Creating an Audit

  1. Open SQL Server Management Studio (SSMS) and connect to SQL Server.
  2. Expand Security Node and select Audits.
  3. Right click Audit and click ‘New Audit’ to launch the new Audit dialog.
  4. We need to enter Audit name and the audit destination.

Audit destination can be of Application Log event, Security Log Event, File (or folder). In case of file, a path needs to be entered and the directory should exist. Also need to configure Maximum rollover and maximum file size properties.

  1. Click Ok to create the audit.

 

T-SQL:
[sql]
CREATE SERVER AUDIT [Audit_Select_Production_Product]
TO FILE ( FILEPATH = N’c:\temp\selectAudit’
,MAXSIZE = 0 MB
,MAX_ROLLOVER_FILES = 2147483647
,RESERVE_DISK_SPACE = OFF)
WITH
(QUEUE_DELAY = 1000,ON_FAILURE = CONTINUE)
[/sql]

Creating Database Level Audit Specification:

  1. Select the database where the db level audit specification needs to be created.
  2. Expand Security under the particular database node and select ‘Database Audit Specifications’
  3. Right Click the Database Audit Specifications and select ‘Create new Database Audit Specification’.
  1. We need to enter audit name and need to select the server level audit which we created above.Also need to select Audit Action type, object and principal. The audits are logged only when the particular principal name executes a SELECT statement. In case if the audit needs to be logged for every one issuing a SELECT statement, then the principal name should be ‘public’.
  2. Click ok to create a database level audit specification.

 

T-SQL
[sql]
CREATE DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification-20090105-115555]
FOR SERVER AUDIT [Audit_Select_Production_Product]
ADD (SELECT ON OBJECT::[Production].[Product] BY [Peter])
[/sql]

Viewing Audit Logs:

After executing SELECT statements, in order to view the audit logs, follow the below steps

  1. Expand Security->Audits-> and select the audit created above.
  2. Right click and click ‘View Audit Logs’ from the context menu to launch the audit log viewer dialog.
  3. It contains the information about the SELECT statements issued on the particular object.

via: http://blogs.msdn.com/b/sreekarm/archive/2009/01/05/auditing-select-statements-in-sql-server-2008.aspx