Estás trabajando sin conexión, espera a que vuelva la conexión a Internet

Descripción de los algoritmos de almacenamiento de datos y de registro que amplían la confiabilidad de los datos en SQL Server

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 230785
Resumen
Este artículo describe como algoritmos de registro y de datos de Microsoft SQL Server extienden la integridad y la confiabilidad de los datos.

Para obtener más información acerca de los conceptos subyacentes de los motores y ARIES (algoritmo para la recuperación y aprovechamiento de semántica de aislamiento), consulte las siguientes transacciones de ACM en el documento de sistemas de base de datos (en "volumen 17, número 1, de marzo de 1992):

El escritor de la entrega de este documento es C. Mohan. El documento trata las técnicas de SQL Server para ampliar la confiabilidad de los datos y la integridad en relación a errores.

Le recomendamos que lea los siguientes artículos en Microsoft Knowledge Base para obtener más información sobre el almacenamiento en caché y discusiones de modo alternativo de error:
86903 Descripción del almacenamiento en caché de los controladores de disco en SQL Server
234656 Información sobre el uso de las cachés de disco con SQL Server que deben conocer todos los administradores de base de datos
Más información
Antes de comenzar el debate en profundidad, algunos de los términos que se utilizan en este artículo se definen en la tabla siguiente.
TérminoDefinición
Con respaldo de bateríaBatería independiente y localizadas herramienta de respaldo directamente disponible y es controlada por el mecanismo de almacenamiento en caché para evitar la pérdida de datos.
Nota: No es una fuente de alimentación ininterrumpida (SAI). Un SAI no garantiza que las actividades de escritura y se puede desconectar el dispositivo de almacenamiento en caché.
Memoria cachéMecanismo de almacenamiento intermedio utilizado para optimizar las operaciones de E/S físicas y mejorar el rendimiento.
Página desfasadaPágina que contiene las modificaciones de datos que todavía no se han vaciado al almacenamiento estable. Para obtener más información acerca de los búferes de página desfasada, consulte el "Escribir páginas"el tema en los libros en pantalla de SQL Server.
Nota: El contenido también se aplica a Microsoft SQL Server 2012 y versiones posteriores.
ErrorTodo lo que puede provocar una interrupción inesperada del proceso de SQL Server. Algunos ejemplos son: alimentación interrupción, reinicio del equipo, errores de memoria, otros problemas de hardware, sectores defectuosos, las interrupciones de la unidad, errores del sistema y así sucesivamente.
VaciadoForzar de un búfer de caché al almacenamiento estable.
CierreObjeto de sincronización que se utiliza para proteger la coherencia física de un recurso.
Almacenamiento no volátilCualquier medio que sigue estando disponible a través de errores del sistema.
Página ancladoPágina que permanece en datos almacenar en caché y no se pueden vaciar almacenamiento hasta que se protegen todos los registros asociados en una ubicación de almacenamiento estable.
Almacenamiento estableIgual que el almacenamiento no volátil.
Almacenamiento volátilCualquier medio que no permanecen intacto a través de errores.

Protocolo de registro de escritura anticipada (WAL)

El término "protocolo" es una excelente manera de describir WAL. Es un específico y un conjunto definido de los pasos de implementación necesarios para asegurarse de que los datos se almacenan y se intercambian correctamente y se pueden recuperar a un estado conocido en caso de falla. Al igual que una red contiene un protocolo definido para intercambiar datos de forma coherente y protegida, por lo que también describen el WAL el protocolo para proteger los datos.

El documento ARIES define el WAL como sigue:
El protocolo WAL afirma que los registros que representan los cambios a algunos datos ya deben estar en almacenamiento estable antes de que los datos modificados se permiten reemplazar la versión anterior de los datos en el almacenamiento no volátil. Es decir, el sistema no puede escribir una página actualizada a la versión de almacenamiento no volátil de la página hasta que al menos las partes de deshacer de los registros que describen las actualizaciones de la página se han escrito al almacenamiento estable.
Para obtener más información acerca del registro de escritura anticipada, consulte la Registro de transacciones de escritura anticipada tema de libros en pantalla de SQL Server.

SQL Server y el WAL

SQL Server utiliza el protocolo WAL. Para asegurarse de que una transacción se confirma correctamente, todos los registros asociados a la transacción deben estar protegidos en un almacenamiento estable.

Para clarificar esta situación, considere el siguiente ejemplo específico.

Nota: En este ejemplo, se supone que no hay ningún índice y que la página afectada es página 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
A continuación, dividir la actividad en pasos de registro simple, tal como se describe en la tabla siguiente.
InstrucciónAcciones realizadas
COMENZAR LA TRANSACCIÓNEscribe en el área de la memoria caché de registro. Sin embargo, no es necesario vaciar al almacenamiento estable como el de SQL Server no ha realizado los cambios físicos.
INSERT INTO tblTest
  1. Datos página 150 se recuperan en la memoria caché de datos de SQL Server, si no está ya disponible.
  2. La página es bloqueado, anclado, y contiene errores, y se obtienen bloqueos adecuados.
  3. Un registro de insertar está construido y se agrega a la caché de registro.
  4. Se agrega una nueva fila a la página de datos.
  5. Se libera el pestillo.
  6. Las entradas del registro asociadas a la transacción o página no tiene que hay que vaciar en este momento porque todos los cambios quedan en almacenamiento volátil.
CONFIRMAR TRANSACCIÓN
  1. Se forma un registro de confirmación y se deben escribir las entradas del registro asociadas a la transacción al almacenamiento estable. La transacción no se considera confirmada hasta que los registros se han asignado correctamente al almacenamiento estable.
  2. Datos página 150 permanecen en la memoria caché de datos de SQL Server y no se descarga de forma inmediata al almacenamiento estable. Cuando los registros se ha protegido correctamente, recuperación puede rehacer la operación, si es necesario.
  3. Se liberan los bloqueos de transacciones.
No se debe confundir por los términos "bloqueos" y "registro". Aunque importantes, bloqueo y registro son temas independientes al tratar con el WAL. En el ejemplo anterior, SQL Server generalmente contiene el pestillo en página 150 durante el tiempo necesario para realizar los cambios físicos de insertar en la página, no todo el tiempo de la transacción. Se establece el tipo de bloqueo apropiado para proteger la fila, intervalo, página o tabla según sea necesario. Consulte las secciones de cierre de libros en pantalla de SQL Server para obtener más información acerca de los tipos de bloqueo.

Mira el ejemplo más detalladamente, podría preguntar lo que sucede cuando ejecutan los procesos de escritura diferida o punto de control. SQL Server 7 emite todos los vaciados adecuados para el almacenamiento de registros de registro de transacciones asociados a la página sucia y anclada estable. Esto garantiza que la página de datos de protocolo WAL nunca puede escribirse al almacenamiento estable hasta que los registros de transacciones asociados se han volcado.

Almacenamiento de información de SQL Server y estable

SQL Server mejora las operaciones de página de datos y de registro incluyendo el conocimiento de los tamaños de sector de disco (normalmente 4.096 o 512 bytes).

Para mantener las propiedades ACID de la transacción, el SQL Server debe tener en cuenta para los puntos de error. Durante un corte en muchas de las especificaciones de unidad de disco sólo garantizan una cantidad limitada de sector de operaciones de escritura. La mayoría de las especificaciones garantizan la realización de una escritura único sector cuando se produce un error.

SQL Server utiliza páginas de 8 KB de datos y el registro (si baja) en múltiplos del tamaño del sector. (La mayoría de las unidades de disco utilice 512 bytes como el tamaño de sector predeterminado). En el caso de una falla, SQL Server puede tener en cuenta las operaciones de escritura más de un sector mediante el empleo de paridad de registro y las técnicas de escritura rasgada.

Detección de página rasgada

Esta opción permite a SQL Server detectar operaciones de E/S incompletas causadas por cortes eléctricos u otros imprevistos del sistema. Cuando es true, hace que un poco va a voltear para cada sector de 512 bytes en una página de base de datos de 8 kilobytes (KB) cada vez que la página se escribe en el disco. Si algo es en un estado incorrecto cuando la página es posterior lectura por SQL Server, entonces la página se escribió correctamente; se detecta una página rasgada. Las páginas rasgadas suelen detectarse durante la recuperación porque es probable que se lean cualquier página en la que se ha escrito incorrectamente.

Aunque las páginas de base de datos de SQL Server son de 8 KB, discos realizan operaciones de E/S con un sector de 512 bytes. Por lo tanto, se escriben 16 sectores por cada página de la base de datos. Una página puede rasgarse si se produce un error en el sistema (por ejemplo, debido a un error de alimentación) entre el momento en que el sistema operativo escribe el primer sector de 512 bytes en disco y la finalización de la operación de E/S de 8 KB. Si el primer sector de una página de base de datos se escribe correctamente antes de la falla, la página de la base de datos en disco aparecerá como actualizada, aunque puede no haber tuvo éxito.

Mediante el uso de memorias caché de controlador de disco con respaldo de batería, puede asegurarse de que los datos se escriben correctamente en el disco o no escritos en absoluto. En esta situación, no establezca la detección de páginas rasgadas en "true" porque no es necesario.

Nota: Detección de página rasgada no está habilitada de forma predeterminada en SQL Server. Para obtener más información, consulte el siguiente sitio Web MSDN:

Paridad de registro

Comprobación de paridad de registro es muy similar a la detección de páginas rasgadas. Cada sector de 512 bytes contiene los bits de paridad. Estos bits de paridad siempre están escritos con la entrada del registro y evalúa cuando se recupera el registro. Forzando escrituras en un límite de 512 bytes, SQL Server puede asegurarse de que las operaciones de compromiso se escriben completamente en los sectores del disco físico.

Versiones de SQL Server anteriores a 7.0

Las versiones anteriores de SQL Server a la 7.0 no proporcionó registro paridad o instalaciones de detección de bits rasgada. De hecho, esas versiones pueden escribir la misma página de registro varias veces hasta que el relleno de los registros de la página de registro de 2 KB. Esto puede exponer las transacciones que se han comprometido con éxito. Si se va a reescribir la página de registro durante una falla, es posible que un sector con la transacción confirmada no obtener escribir correctamente.

Impactos en la performance

Todas las versiones de SQL Server abren los archivos de registro y de datos mediante la funciónCreateFile de Win32. El miembro dwFlagsAndAttributes incluye la opción de FILE_FLAG_WRITE_THROUGHcuando se abren por SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica al sistema que se va a escribir en una caché intermedia e ir directamente al disco. El sistema aún puede almacenar en caché las operaciones de escritura, pero no las puede vaciar de forma diferida.

La opción FILE_FLAG_WRITE_THROUGH se asegura de que, cuando una operación de escritura devuelve la finalización correcta, los datos se almacenan correctamente en un almacenamiento estable. Esto se alinea con el protocolo WAL que garantiza que los datos.
Muchas unidades de disco (SCSI e IDE) contienen memorias caché incorporadas de 512 KB, 1 MB o superior. Sin embargo, las cachés de unidad normalmente se basan en un condensador y no es una solución con respaldo de batería. Estos mecanismos de almacenamiento en caché no pueden garantizar el ciclo de escrituras a través de una potencia o punto de error similar. Sólo garantiza la realización de las operaciones de escritura del sector. En concreto, esto es ¿por qué la escritura rasgada y detección de paridad de registro fueron construidos en SQL Server 7.0 y versiones posteriores. Como las unidades continúan creciendo en tamaño, las memorias caché aumentan de tamaño y que pueden exponer grandes cantidades de datos durante una falla.

Muchos proveedores de hardware ofrecen soluciones de controlador de disco con respaldo de batería. Estas cachés de controlador pueden mantener los datos en la memoria caché durante varios días e incluso permitir el hardware de almacenamiento en caché para colocarse en un segundo equipo. Cuando la alimentación se restaura correctamente, los datos no se vacían completamente antes de permite el acceso a los datos adicional. Muchos de ellos permiten un porcentaje de lectura frente a la caché de escritura que se establezca para un rendimiento óptimo. Algunos contienen áreas de almacenamiento de grandes cantidades de memoria. De hecho, para un segmento muy específico del mercado, algunos fabricantes de hardware proporcionan discos high-end con respaldo de batería, el almacenamiento en caché de sistemas de controlador con 6 GB de memoria caché. Estos pueden mejorar significativamente el rendimiento de la base de datos.

Avanzada de las implementaciones de almacenamiento en caché mango solicitar la FILE_FLAG_WRITE_THROUGH si no deshabilita la caché del controlador ya que pueden proporcionar cierto sobreescribirá capacidades en caso de un reinicio del sistema, corte de suministro eléctrico u otro punto de error.

Transferencias de E/S sin el uso de una memoria caché pueden ser significativamente mayor debido a la hora mecánica que es necesario para mover los cabezales de la unidad, velocidades de giro y otros factores limitantes.

Ordenación del sector

Una técnica común utilizada para aumentar el rendimiento de E/S es sector pedidos. Para evitar el movimiento mecánico de la cabeza se ordenan las solicitudes de lectura y escritura, lo que permite un movimiento más coherente de la cabeza para recuperar o almacenar los datos.

La caché puede contener múltiples de registro y las solicitudes de escritura de datos al mismo tiempo. El protocolo WAL y la implementación de SQL Server del protocolo WAL requieren de baja del registro de escrituras al almacenamiento estable para poder emitir la escritura de la página. Sin embargo, el uso de la memoria caché podría devolver el éxito de una solicitud de escritura de registro sin los datos se escriben en la unidad real (que es, escribe al almacenamiento estable). Esto puede conducir a emitir la solicitud de escritura de página de datos de SQL Server.

Con la participación de caché de escritura, todavía se consideran que los datos en almacenamiento volátil. Sin embargo, la llamada de la API de Win32 WriteFile, exactamente cómo SQL Server ve la actividad, se obtuvo un código devuelto correctamente. SQL Server o cualquier proceso que utilice la llamadaWriteFileAPI puede determinar sólo los datos correctamente ha obtenido almacenamiento estable.

A efectos de discusión, se supone que todos los sectores de la página de datos se ordenan para escribir antes de los sectores de los registros coincidentes. Esto infringe inmediatamente el protocolo WAL. La caché está escribiendo una página de datos antes de los registros. A menos que la memoria caché es totalmente con respaldo de batería, un error puede causar resultados catastróficos.

Al evaluar los factores de rendimiento óptimo para un servidor de base de datos, hay muchos factores a considerar. Es el más importante, "permite mi sistema válidas capacidades FILE_FLAG_WRITE_THROUGH?"

Nota: Cualquier caché que está usingmust totalmente compatible con una solución de batería. Otros mecanismos de almacenamiento en caché son sospechosos de corrupción de datos y pérdida de datos. SQL Server hace todo lo posible para garantizar el WAL habilitando FILE_FLAG_WRITE_THROUGH.

Las pruebas han demostrado que muchas configuraciones de unidad de disco pueden contener la caché de escritura sin el respaldo de batería adecuada. Las unidades SCSI, IDE y EIDE aprovechar al máximo las memorias caché de escritura. Para obtener más información acerca del funcionan de SSDs junto con SQL Server, vea el siguiente artículo del Blog de ingenieros de CSS SQL Server:


En muchas configuraciones, la única manera de deshabilitar la caché de escritura de una unidad IDE o EIDE correctamente es mediante una utilidad de un fabricante específico o mediante puentes ubicados en la misma unidad. Para asegurarse de que la caché de escritura está deshabilitada para la propia unidad, póngase en contacto con el fabricante de la unidad.

Unidades de disco SCSI también tienen las memorias caché de escritura. Sin embargo, estas cachés pueden deshabilitarse normalmente por el sistema operativo. Si tiene alguna pregunta, póngase en contacto con el fabricante de la unidad para utilidades adecuadas.

Apilamiento de caché de escritura

Escribir que caché de apilamiento es similar a la ordenación del Sector. La definición siguiente está tomada directamente del sitio Web de un IDE unidad fabricante líder:
Normalmente, este modo está activo. Escribir el modo de caché acepta que el host escribe datos en el búfer hasta que el búfer está lleno o se ha completado la transferencia del host.

Una tarea de escritura de disco se comienza a almacenar los datos de host al disco. Continuarán con comandos de escritura del host para que se acepte y datos que se transfieren al búfer hasta que la pila del comando de escritura está llena o el búfer de datos está lleno. La unidad puede reordenar comandos de escritura para optimizar el rendimiento de la unidad.

Reasignación de escritura automática (AWR)

Otra técnica común que se utiliza para proteger los datos es detectar sectores defectuosos durante la manipulación de datos. La siguiente explicación proviene de un líder IDE unidad sitio Web del fabricante:
Esta característica es parte de la memoria caché de escritura y reduce el riesgo de pérdida de datos durante las operaciones de escritura diferida. Si se produce un error de disco durante el proceso de escritura de disco, el disco tarea se detiene y el sector sospechoso se reasigna a un grupo de sectores alternativos que se encuentran al final de la unidad. Después de la reasignación, la tarea de escritura de disco continúa hasta que se complete.
Esto puede ser una característica muy eficaz si se proporciona el respaldo de batería para la caché. Esto proporciona la modificación correspondiente al reiniciar. Es preferible para detectar los errores de disco, pero la seguridad de los datos del protocolo WAL nuevo requeriría Esto se realice en tiempo real y no de forma diferida. Dentro de los parámetros WAL, la técnica AWR no se cuenta una situación en la que se produce un error de escritura en el registro debido a un error de sector, pero el disco está lleno. El motor de base de datos debe conocer inmediatamente sobre el error por lo que la transacción se puede anular correctamente, el administrador puede recibir alertas y corregir las medidas adoptadas para proteger los datos y corregir la situación de error de los medios de comunicación.

Seguridad de los datos

Hay varias precauciones que debe tomar un administrador de base de datos para garantizar la seguridad de los datos.
  • Siempre es una buena idea asegurarse de que su estrategia de copia de seguridad es suficiente para recuperarse de un error muy grave. Almacenamiento fuera del sitio y otras precauciones son apropiados.
  • Probar la operación de restauración de base de datos en un secundario o la base de datos de prueba con frecuencia.
  • Asegúrese de que los dispositivos de almacenamiento en caché pueden controlar todas las situaciones de error (corte de suministro eléctrico, sectores defectuosos, malas unidades, interrupciones del sistema, bloqueos, pico de energía etc.).
  • Asegúrese de que el dispositivo de almacenamiento en caché:
    • Ha integrado el respaldo de batería
    • Puede reedición escribe al encender
    • Puede deshabilitar completamente si es necesario
    • Controla la reasignación del sector defectuoso en tiempo real
  • Habilitar rasgado la detección de páginas. (Tiene muy poco efecto en el rendimiento).
  • Configurar unidades RAID que permite un intercambio en caliente de una unidad de disco, si es posible.
  • Utilice los controladores de almacenamiento en caché más recientes que le permiten agregar más espacio en disco sin tener que reiniciar el sistema operativo. Esto puede ser una solución ideal.

Las pruebas de unidades

Para proteger los datos, debe asegurarse de que todos del almacenamiento en caché de datos se controla correctamente. En muchas situaciones, debe deshabilitar la caché de escritura de la unidad de disco.

Nota: Asegúrese de que una alternativa al mecanismo de almacenamiento en caché correctamente puede controlar varios tipos de error.

Microsoft ha realizado pruebas en varias unidades de disco SCSI e IDE mediante la utilidad SQLIOSim . Esta herramienta simula actividad pesada lectura y escritura asincrónica a un dispositivo de datos simulados y dispositivo de registro. Estadísticas de rendimiento de la prueba muestran que las operaciones de escritura promedio por segundo entre 50 y 70 para una unidad con el almacenamiento en caché de escritura deshabilitado y un rango de RPM entre 5.200 y 7.200.

Para obtener más información acerca de la utilidad SQLIOSim , consulte el artículo siguiente en Microsoft Knowledge Base:
231619 Cómo utilizar la utilidad SQLIOSim para simular la actividad de SQL Server en un subsistema de disco
Muchos fabricantes de equipos orden las unidades por tener la memoria caché de escritura desactivada. Sin embargo, las pruebas muestran que esto no sea siempre el caso. Por lo tanto, siempre Pruebe completamente.

Dispositivos de datos

En situaciones pero no registradas, SQL Server requiere los registros que se debe vaciar. Al realizar operaciones no registradas, también se deben vaciar las páginas de datos al almacenamiento de información estable; no existen registros para regenerar las acciones en el caso de un error de registro individuales.

Las páginas de datos pueden permanecer en la caché hasta que el proceso de escritura diferida o punto de control vacía al almacenamiento estable. Con el protocolo WAL para asegurarse de que los registros se almacenan correctamente se asegura de que la recuperación puede recuperar una página de datos a un estado conocido.

Esto no significa que es aconsejable colocar los archivos de datos en una unidad de caché. Cuando el SQL Server vacía las páginas de datos al almacenamiento estable, se pueden truncar los registros del registro de transacciones. Si las páginas de datos se almacenan en caché volátil, es posible truncar los registros que se utilizaría para recuperar una página en el caso de un error. Asegúrese de que los datos y el registro de dispositivos acomodar correctamente almacenamiento estable.

Aumentar el rendimiento

La primera pregunta que se produce es: "tengo una unidad IDE que fue el almacenamiento en caché. Pero cuando deshabilitado, mi rendimiento significativamente menor de lo esperado. ¿Por qué?"

Muchas de las unidades IDE probadas por Microsoft se ejecutan a una velocidad de RPM de 5.200 y unidades de la SCSI en de 7.200 RPM. Al deshabilitar la escritura el almacenamiento en caché de la unidad IDE el rendimiento mecánico puede convertirse en un factor.

Hay un área muy claro para enfrentar la diferencia de rendimiento: una dirección a la velocidad de la transacción."

Hay muchos sistemas (OLTP) que requieren una tasa de transacciones alta de procesamiento de transacciones en línea. Para estos sistemas, considere el uso de una controladora de caché que puede admitir una memoria caché de escritura y aumentan el rendimiento mientras se asegura la integridad de los datos correctamente.

Para encontrar considerablemente los cambios de rendimiento con SQL Server en una unidad de almacenamiento en caché, se incrementó la tasa de transacciones mediante el uso de transacciones pequeñas.

Prueba demuestra que escribe alta actividad de búferes que es menor que 512 KB o mayor que 2 MB puede provocar un rendimiento lento.
Considere el siguiente ejemplo:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Resultados de pruebas de ejemplo de SQL Server son los siguientes:
SCSI(7200 rpm) 84 segundos
SCSI(7200 rpm) 15 segundos (controlador de almacenamiento en caché)

14 de IDE(5200 rpm) segundos (caché de la unidad habilitada)
160 IDE(5200 rpm) segundos

Ajuste de toda la serie de operaciones de INSERCIÓN en una sola transacción se ejecuta en unos cuatro segundos en todas las configuraciones.

La razón es que el número de vaciados de registro necesaria. Sin la transacción, cada INSERCIÓN es una transacción de por sí, y cada vez que los registros del registro de la transacción deben vaciarse. Cada descarga es de 512 bytes de tamaño, lo que requiere la intervención de accionamiento mecánico significativo.

Cuando se utiliza una única transacción, pueden integrar los registros del registro de la transacción y una operación de escritura única, más grande que puede utilizarse para vaciar los registros recopilados. La intervención mecánica se reduce considerablemente.

Advertencia: Se recomienda que no aumentan el ámbito de la transacción. Transacciones de ejecución larga pueden producir un bloqueo excesivo y no deseados, así como mayor carga. Utilice los contadores de rendimiento de SQL Server : bases de datos de SQL Server para ver los contadores basado en el registro de transacciones. En concreto, Flushed Bytes de registro/seg. puede indicar muchas transacciones pequeñas, una disco mecánico de alta actividad.

Observe las instrucciones asociadas con el vaciado del registro y determinar si se puede reducir el número de vaciados de registro. En el ejemplo anterior, se implementó una única transacción. Sin embargo, en muchos casos, esto puede conducir a un comportamiento no deseado bloqueo. Examine el diseño de la transacción. Puede utilizar código similar al siguiente para realizar lotes para reducir la actividad de vaciado en pequeñas y frecuentes del registro:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server requiere que sea compatible con los sistemas "entrega garantizada en medios estables," como se describe en el Requisitos de revisión de programa de SQL Server entrada-salida confiabilidad Descargue el documento. Para obtener más información acerca de los requisitos de entrada y salidos para el motor de base de datos de SQL Server, haga clic en el número de artículo siguiente para ir al artículo en Microsoft Knowledge Base:
967576 Requisitos de entrada/salida de motor base de datos de Microsoft SQL Server

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 230785 - Última revisión: 05/15/2015 22:12:00 - Revisión: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtes
Comentarios
ody>.microsoft.com/ms.js"> ">El Salvador - Español
Panamá - Español
Uruguay - Español
대한민국 - 한국어
España - Español
Paraguay - Español
Venezuela - Español