Algoritmos de almacenamiento de datos y registro de SQL Server 7.0, SQL Server 2000 y SQL Server 2005 amplían la confiabilidad de los datos

Seleccione idioma Seleccione idioma
Id. de artículo: 230785 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

SQL Server 7.0, SQL Server 2000 y SQL Server 2005 reestructuración y rediseñar los algoritmos de registro y datos de versiones anteriores de Microsoft SQL Server para mejorar la confiabilidad de los datos y la integridad.

Para obtener información sobre los conceptos subyacentes de los motores de SQL Server 7.0 y SQL Server 2000, vea "ARIES (algoritmo de recuperación y aislamiento Exploiting semántica): un método de recuperación de transacciones granularidad fina de soporte técnico bloqueo y revertidas parciales con escritura anticipada registro", de transacciones de ACM en sistemas de base de datos. Este documento se escribió por Chunder Mohan.

Este documento trata las técnicas de SQL Server 7.0, SQL Server 2000 y SQL Server 2005 para ampliar la confiabilidad de los datos y la integridad como relacionados con errores.

Se recomienda que lea los artículos siguientes en Microsoft Knowledge Base para aclaración más almacenamiento en caché y alternan las discusiones de modo de error:
86903Descripción del almacenamiento en caché los controladores de disco en SQL Server
46091Utilizando la caché de controlador de disco duro con SQL Server
234656Using Disk Drive Caching with SQL Server ("Utilización del almacenamiento en caché en las unidades de disco con SQL Server", este artículo está en inglés)

Más información

Antes de comenzar la discusión exhaustiva, algunos de los términos como se utiliza en este artículo se definen en la sección siguiente.
Contraer esta tablaAmpliar esta tabla
TérminoDefinición
Batería de seguridad Batería independiente y localizadas copia de seguridad utilidad directamente disponible y están controlado por el mecanismo de almacenamiento en caché para evitar la pérdida de datos.
Nota No es un sistema de alimentación ininterrumpida sistema de alimentación ininterrumpida (SAI). Un SAI (UPS) no garantiza las actividades de escritura y se puede desconectar el dispositivo de almacenamiento en caché.
Caché Mecanismo de almacenamiento intermedio se utiliza para optimizar las operaciones de E/s físicas y mejorar el rendimiento.
Página desfasada Página que contiene las modificaciones de datos que aún no se vacían al almacenamiento estable. Para obtener más información relativa a los búferes de página desfasada, consulte la documentación de los libros en pantalla de SQL Server.
Error Cualquier cosa que podría causar una interrupción inesperada del proceso de SQL Server. Algunos ejemplos son: interrupción, restablecimiento del equipo, errores de memoria, otros problemas de hardware, los sectores defectuosos, interrupciones de la unidad, errores de sistema operativo etc. de energía.
Vaciado Forzar de un búfer de caché estable de almacenamiento.
Pestillos Objeto de sincronización que se utiliza para proteger la coherencia física de un recurso.
Almacenamiento no volátil Cualquier medio que permanece disponible a través de errores del sistema.
Página agregado Página permanece en datos de caché y no se vacían al almacenamiento estable, hasta que se protegen todos los registros asociados en una ubicación de almacenamiento estable.
Almacenamiento estable Igual que el almacenamiento no volátil.
Almacenamiento volátil Cualquier medio que no permanecen intactos a través de errores.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, las versiones anteriores de SQL Server y muchos productos de base de datos convencional en el mercado utilizan hoy mismo el protocolo de escritura anticipada registro (WAL).

Protocolo de escritura anticipada registro (WAL)

El protocolo de término es una excelente forma de describir WAL. Es un objeto específico y conjunto definido de pasos de implementación necesarios para garantizar los datos se almacenan y intercambian correctamente y se pueden recuperar a un estado conocido en el caso de un error. Tal como una red contiene un protocolo para intercambiar datos de una manera coherente y protegida, por lo tanto, definido demasiado ¿el WAL describe el protocolo para proteger los datos.

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

SQL Server y el WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 y versiones anteriores de SQL Server utilizan el protocolo WAL. Para asegurarse de committal correcta de una transacción, se deben proteger todos los registros asociados a la transacción en almacenamiento estable.

Para aclararlo esto, considere el ejemplo específico siguiente (para este ejemplo suponga que no hay ningún índice y la página afectada es página 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
ahora desglosar la actividad en los pasos de registro simple:
Contraer esta tablaAmpliar esta tabla
InstrucciónAcciones realizadas
INICIO DE TRANSACCIÓN Escribe en el área de caché de registro pero no es necesario vaciar al almacenamiento estable como SQL Server no ha realizado cambios físicos.
INSERT INTO tblTestLos datos de 1. página 150 se recuperan en caché de datos de SQL Server, si no está ya disponible.

2. La página está activada , Fijar y marcado con errores y se obtienen bloqueos apropiados.

3. Un registro de registro de insertar está integrado y agrega a la caché de registro.

4. Una nueva fila se agrega a la página de datos.

5. El bloqueo se libera.

6. El registro asociado con la transacción o no es necesario páginas se vacían en este momento ya que todos los cambios permanecerán en almacenamiento volátil.
CONFIRMAR TRANSACCIÓN1. Un registro de registro de confirmación está formado y los registros de registro asociados con la transacción deben escribirse a estable de almacenamiento. La transacción no se considera confirmada hasta que los registros se asignan correctamente a almacenamiento estable.

2. Página 150 de datos permanecen en caché de datos de SQL Server y no se vacían inmediatamente al almacenamiento estable. Cuando los registros están correctamente recuperación segura puede rehacer la operación si es necesario.

3. Transaccionales bloqueos se liberan.
No se debe confundir con bloqueo y el registro. Aunque importante, bloqueo y el registro se son a problemas independientes de cuando se trabaja con la WAL. En el ejemplo anterior, SQL Server 7.0, SQL Server 2000 y SQL Server 2005 generalmente contienen el pestillo en página 150 para el tiempo necesario para realizar los cambios de inserción física en la página, no la hora completa 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 bloqueo de los libros en pantalla de SQL Server para obtener más información sobre tipos de bloqueo.

Observamos el ejemplo en más detalle, podría preguntar qué ocurre al ejecutan los procesos de escritura diferida o CheckPoint. SQL Server 7.0, SQL Server 2000 y SQL Server 2005 emiten todos los vaciados apropiados para estable el almacenamiento de registros de registro transaccional asociados con la página desfasada y agregada. Esto garantiza que el protocolo WAL que una página de datos nunca se puede escribir estable almacenamiento hasta que se hayan vaciado los registros de transacciones asociadas.

Almacenamiento de SQL Server y estable

SQL Server 7.0, SQL Server 2000 y SQL Server 2005 para mejorar las operaciones de página de registro y datos incluyendo el conocimiento de tamaños de sector de disco (normalmente 512 bytes).

Para mantener las propiedades ACID de una transacción, SQL Server debe tener en cuenta los puntos de error. Durante un error numerosas 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 finalización de escritura de un único sector cuando se produce un error.

SQL Server 7.0, SQL Server 2000 y SQL Server 2005 utilizan páginas de datos de 8 KB y el registro (si se vacían) en múltiplos del tamaño del sector. (La mayoría de los discos utilice 512 bytes como el tamaño de sector predeterminado.) En el caso de un error, SQL Server puede cuenta para las operaciones de escritura más de un sector empleando la paridad de registro y técnicas de escritura rasgada.

Detección de página rasgada

La siguiente sección proviene de en la pantalla de SQL Server 7.0 libros que describe la detección de páginas rasgadas:
Esta opción permite a SQL Server detectar operaciones de E/s incompletas a causa de otros sistema cortes eléctricos u. Cuando el valor es true, provoca un bit se volteará para cada sector de 512 bytes de una página de base de datos de 8 kilobytes (KB) siempre que la página se escribe en disco. Si un bit es en un estado incorrecto cuando la página es posterior lectura por SQL Server, a continuación, la página se escribió incorrectamente; detecta una página rasgada. Páginas rasgadas normalmente se detectan durante la recuperación, ya que cualquier página que se escribió incorrectamente es probable que ser leído por recuperación.

Aunque las páginas de base de datos de SQL Server son de 8 KB, discos realizan operaciones de E/s mediante un sector de 512 bytes. Por lo tanto, se escriben 16 sectores por página de base de datos. Una página rasgada puede producirse si el sistema falla (por ejemplo, debido a eléctrico) entre el momento 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 producirse el error, la página de base de datos en disco aparecerá como actualizada, aunque es posible que no han correcta.

Utilizar cachés de controlador de disco de la batería puede asegurarse de que datos está escritas correctamente en el disco o no escritos en absoluto. En este caso, puede hacer no conjunto torn page detection en true, para no es necesario.
Nota Detección de página rasgada no está habilitada de forma predeterminada en SQL Server 7.0. Consulte sp_dboption para activar la detección en el sistema.

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 bits de paridad. Estos bits de paridad siempre son escritos con el registro y se evalúa cuando se recupera el registro. Al forzar el registro se escribe en un límite de 512 bytes, SQL Server 7.0, SQL Server 2000 y SQL Server 2005 pueden asegurarse de que committal operaciones son completamente escritas para los sectores de disco físico.

Los cambios proporcionan coherencia de datos mayor, incluso a través de las versiones anteriores de SQL Server.

Versiones de SQL Server anteriores a 7.0

Las versiones de SQL Server anteriores a 7.0 no proporcionó registro paridad o bits rasgada detección instalaciones. De hecho, dichas versiones pueden escribir la misma página de registro varias veces hasta que los registros del registro llenen la página Registro de 2 KB. Esto puede exponer las transacciones que han confirmado correctamente. Si la página de registro que se reescribe durante un error, es posible que un sector con la transacción confirmada no obtener reescrito correctamente.

Impacto de rendimiento

Todas las versiones de SQL Server abrir los archivos de registro y de datos mediante la función CreateFile de Win32. El miembro dwFlagsAndAttributes incluye la opción de FILE_FLAG_WRITE_THROUGH cuando abre por SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica al sistema para escribir a través de cualquier caché intermedio y vaya directamente al disco. El sistema puede seguir almacenar en caché las operaciones de escritura, pero forma diferida no pueda vaciar.

La opción FILE_FLAG_WRITE_THROUGH garantiza que cuando una escritura operación devuelve éxito que los datos se almacenan correctamente en almacenamiento estable. Se alinea con el protocolo WAL asegurar los datos.
Muchas unidades de disco (SCSI e IDE) contienen integradas cachés de 512 KB, 1 MB o superior. Sin embargo, las cachés de unidad normalmente dependen de un condensador y no una solución de seguridad de la 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 finalización de las operaciones de escritura del sector. Se trata específicamente por qué la escritura rasgada y la detección de paridad de registro se crearon en SQL Server 7.0, SQL Server 2000 y SQL Server 2005. Como las unidades continúan creciendo de tamaño, las cachés de aumentar de tamaño y exponen grandes cantidades de datos durante un error.

Muchos proveedores de hardware proporcionan soluciones de controlador de disco de la batería. Estas cachés de controlador pueden mantener los datos en la caché durante varios días y incluso permitir que el hardware de almacenamiento en caché para colocarse en un segundo equipo. Si alimentación se restaura correctamente, los datos implícitas se vaciarán completamente antes de que el acceso a datos adicional que se permita. Muchas de ellas permiten un porcentaje de lectura frente a la caché de escritura para establecerse 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 proveedores de hardware proporcionan almacenamiento en caché los sistemas de controlador con 6 GB de caché de disco batería superiores. Estos mejorará significativamente el rendimiento de la base de datos.

Avanzada implementaciones de almacenamiento en caché se capacidades en el caso de un reinicio del sistema, corte de alimentación o otro punto de error reescriba identificador el FILE_FLAG_WRITE_THROUGH solicitar no deshabilitar la caché de controlador porque proporcionan true.

Transferencias de E/s sin utilizar una caché pueden ser mucho mayor debido a la hora mecánica necesaria para mover los cabezales de unidad, tasas de número y otros factores limitadores.

Orden del sector

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

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

Con la participación de caché de escritura, se sigue consideran los datos en almacenamiento volátil. Sin embargo, la llamada a API Win32 WriteFile , exactamente cómo SQL Server se ve la actividad, un código de retorno correcto se obtuvo. SQL Server o cualquier proceso utilizando sólo el puede de llamada de API WriteFile deducir de los datos ha obtenido correctamente almacenamiento estable.

Para fines de discusión, suponga 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 caché de batería de seguridad completo, un error puede producir resultados catastróficos.

Al evaluar los factores de rendimiento óptimo para un servidor de base de datos, son muchos los factores que deben tenerse en cuenta. Es más importante de estas consideraciones "permitir mi sistema válidas FILE_FLAG_WRITE_THROUGH capacidades?"

Nota Cualquier caché que utiliza debe totalmente compatible con una solución de seguridad de la batería. Otros mecanismos de almacenamiento en caché son sospechosas a daños en los datos y pérdida de datos. SQL Server realiza cada esfuerzo para garantizar la WAL habilitando FILE_FLAG_WRITE_THROUGH.

Las pruebas han demostrado que muchas configuraciones de disco pueden contener la caché de escritura sin reserva de batería correcta. Las unidades SCSI, IDE y EIDE aprovechar al máximo las memorias caché de escritura.

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

Unidades SCSI también tienen cachés de escritura, pero estas cachés normalmente pueden deshabilitarse mediante el sistema operativo. Si hay alguna pregunta, póngase en contacto con el fabricante de la unidad para utilidades apropiadas.

Escribir caché pila

Escribir que caché pila es similar al orden del sector. La siguiente definición tomó directamente desde un sitio inicial IDE unidad fabricante Web:
Normalmente, este modo está activo. Escribir el modo de caché acepta que el host escribir datos en el búfer hasta que el búfer está lleno o se completa la transferencia de host.

Comienza una tarea de escritura de disco almacenar los datos de host en el disco. Comandos de escritura de host hasta ser aceptado y datos transfieren al búfer hasta que la pila de comando de escritura está llena o el búfer de datos está lleno. La unidad puede reordenar los comandos de escritura para optimizar el rendimiento de unidad.

Reasignación automática de escritura (AWR)

Otra técnica común utilizada para proteger los datos es detectar los sectores defectuosos durante la manipulación de datos. La explicación siguiente procede del mismo inicial IDE unidad fabricante sitio Web:
Esta característica es parte de la 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, la tarea de disco se detiene y el sector sospechoso se reasigna a un grupo de sectores alternativos encuentra al final de la unidad. Siguiendo la reasignación, la tarea de escritura de disco continúa hasta que se complete.
Esto puede ser una característica muy eficaz si copia de seguridad de la batería se proporciona para la caché, que permite la modificación correcta al reiniciar. Es preferible para detectar los errores de disco, pero la seguridad de datos del protocolo WAL nuevo requeriría esto realizarse en tiempo real y no de forma diferida. Dentro de los parámetros WAL, la técnica AWR no cuenta para una situación donde una escritura de registro falla debido a un error de sector pero el disco está lleno. El motor de base de datos inmediatamente debe conocer acerca del error anula la transacción puede ser correctamente, puede avisar al administrador y pasos adecuados para proteger los datos y corregir la situación de error de medios.

Seguridad de los datos

Hay varias precauciones que debe seguir un administrador de bases de datos para garantizar la seguridad de los datos.
  • Siempre es conveniente asegurarse de que su estrategia de copia de seguridad es suficiente para recuperarse de un error catastrófico. Almacenamiento fuera del sitio y otras precauciones son adecuados.
  • Probar la operación de restauración de base de datos en un secundario o base de datos prueba en una frecuencia.
  • Asegúrese de que los dispositivos de almacenamiento en caché pueden controlar todas situaciones de error (corte de energía, sectores, unidades incorrectas, interrupción de sistema, bloqueos, pico de energía etc.).
  • Asegúrese de que el dispositivo de almacenamiento en caché:
    • Ha integrado la batería de reserva.
    • Puede nueva emisión energía escribe.
    • Puede deshabilitarse completamente si es necesario.
    • Controla el sector defectuoso reasignar en tiempo real.
  • Habilitar detección de páginas rasgadas; tiene poco impacto de rendimiento.
  • Configurar unidades RAID que permite un intercambio activo de una unidad de disco incorrecto, si es posible.
  • Utilice controladores de almacenamiento en caché más recientes que permiten la adición de más espacio en disco sin reiniciar el sistema operativo. Esto puede ser una solución ideal.

Pruebas de unidades

Para proteger totalmente los datos, debe asegurarse de que todo el almacenamiento en caché datos correctamente trata. En muchas situaciones, esto significa que debe deshabilitar la caché de escritura de la unidad de disco.

Nota Asegúrese de que un mecanismo de almacenamiento en caché alternativo correctamente puede controlar varios tipos de error.

Microsoft ha realizado pruebas en varias unidades SCSI e IDE, mediante la utilidad SQLIOStress . Esta utilidad simula actividad de lectura y escritura asincrónicas mucho a un dispositivo de datos simulados y dispositivo de registro. Estadísticas de rendimiento de prueba muestran las operaciones de escritura promedio por segundo entre 50 y 70 para una unidad con la caché de escritura deshabilitado y un intervalo RPM entre 5,200 7.200.

Para obtener más información y detalles acerca de la utilidad SQLIOStress , vea el artículo siguiente en Microsoft Knowledge Base:
231619Cómo utilizar la utilidad SQLIOStress para resaltar un subsistema de disco, como SQL Server
Muchos fabricantes de PC (por ejemplo, Compaq, Dell, puerta de enlace, HP etc.) orden de las unidades con la caché de escritura deshabilitada. Sin embargo, muestra pruebas que esto no siempre sea el caso así siempre probar completamente.

Dispositivos de datos

En situaciones de todo, pero no registrada, SQL Server requerirá sólo los registros a se vacíen. Al realizar operaciones no registradas, también se deben vaciar las páginas de datos al almacenamiento estable; no hay registros individuales para regenerar las acciones en el caso de un error.

Las páginas de datos pueden permanecer en memoria caché hasta que el proceso de escritura diferida o CheckPoint los vaciados al almacenamiento estable. Uso el protocolo WAL para asegurarse de que los registros se almacenan correctamente garantiza que la recuperación puede recuperar una página de datos a un estado conocido.

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

Aumentar el rendimiento

La pregunta inicial que surge es: "Tengo una unidad IDE que se almacenamiento en caché, pero cuando deshabilita, mi rendimiento quedó considerablemente menor esperado--¿por qué?"

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

Hay un área muy claro para tratar la diferencia de rendimiento: "La tasa de transacción de direcciones".

Hay muchas transacciones en línea (OLTP) sistemas que requieren una tasa alta de transacción de procesamiento. Para estos sistemas, considere el uso un controlador de almacenamiento en caché que correctamente puede admitir una caché de escritura y proporcionar el aumento del rendimiento al garantizar la integridad de datos.

Encontrar considerablemente los cambios de rendimiento con SQL Server en una unidad de almacenamiento en caché, la tasa de transacción se aumentó mediante transacciones pequeñas.

Las pruebas muestran que la actividad de escritura alta de búferes más pequeños que 512 KB o por encima de 2 MB puede provocar un rendimiento lento.
Considere el siguiente ejemplo:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
siguiente es resultados de prueba de ejemplo para SQL Server:
Segundos de SCSI(7200 RPM) 84
SCSI(7200 RPM) 15 segundos (controlador de caché)

IDE(5200 RPM) 14 segundos (unidad caché habilitada)
IDE(5200 RPM) 160 segundos
Ajuste toda la serie de operaciones INSERT en una sola transacción se ejecuta en aproximadamente 4 segundos en todas las configuraciones.

El motivo es el número de vaciados de registro necesarios. Sin la transacción, cada INSERT es una transacción de por sí, y cada vez que se vacíen los registros de la transacción deben. Cada vaciado es 512 bytes de tamaño, que requiere la intervención unidad mecánico significativo.

Cuando se utiliza una única transacción, los registros de la transacción pueden ser agrupados y una escritura única, más grande puede utilizarse para vaciar los registros recopilados. Se reduce significativamente la intervención mecánica.

Advertencia No se recomienda que aumente el ámbito de transacción. Transacciones de larga duración pueden conducir a bloqueo excesivo y no deseado, así como mayor sobrecarga. Utilice la SQL Server 7.0, SQL Server 2000 y contadores de rendimiento de SQL Server 2005 Bases de datos de SQL Server: para ver los contadores de basado en un registro de transacciones. Específicamente, Flushed de bytes de registro por segundo puede indicar muchas transacciones pequeñas conducen a la actividad del disco mecánico alta.

Examine las instrucciones asociadas con el registro de vaciado y determinar si puede reducirse el número de vaciados de registro. En el ejemplo anterior, se implementó una única transacción. Sin embargo, en muchos casos esto puede provocar al comportamiento de bloqueo no deseado. Examine el diseño de la transacción. Quizás algo como siguiente para realizar lotes para reducir el registro frecuente y pequeño vaciar actividad:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6. x no puede ver el mismo impacto de rendimiento de frecuentes y registro de transacciones pequeñas escribe. SQL Server 6. x vuelve a escribir de la misma página de registro de 2 KB las transacciones se confirman. Esto puede reducir el tamaño del registro considerablemente en comparación con los vaciados de límite del sector de 512 bytes en SQL Server 7.0, SQL Server 2000 y SQL Server 2005. Reducir el tamaño del Registro directamente está relacionado con la cantidad de actividad de mecánica de la unidad. Sin embargo, como se explica anteriormente, SQL Server 6. x algoritmo puede exponer las transacciones confirmadas.
SQL Server requiere los sistemas admiten ? garantiza la entrega a medios estables ? como se describe en el programa de revisión de solución de almacenamiento de Microsoft SQL Server Always-On. FOPara obtener más información sobre 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 verlo en Microsoft Knowledge Base:
967576Microsoft SQL Server Database Engine E/s requisitos

Propiedades

Id. de artículo: 230785 - Última revisión: jueves, 09 de febrero de 2006 - Versión: 5.3
La información de este artículo se refiere a:
  • 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
Palabras clave: 
kbmt kbhowto kbinfo KB230785 KbMtes
Traducción automática
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

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com