2010-11-24 9 views
7

Le estamos diciendo a nuestro cliente que coloque un archivo de base de datos de SQL Server (mdf) en un disco físico diferente al archivo de registro de transacciones (ldf). La empresa de tecnología (contratada por nuestro cliente) quería poner el registro de transacciones en un disco más lento (por ejemplo, más económico) que la unidad de la base de datos, porque con los registros de transacciones, simplemente está escribiendo secuencialmente en el archivo de registro.¿La unidad de registro de transacciones debe ser tan rápida como la unidad de base de datos?

Les dije que pensaba que la unidad (en realidad una configuración RAID) también tenía que estar en un disco rápido, porque cada llamada de cambio de datos a la base de datos debe guardarse allí, así como también a la base de datos .

Después de decir eso, me di cuenta de que no estaba del todo seguro de eso. ¿La velocidad de la unidad de registro de transacciones hace una diferencia significativa en el rendimiento ... si la unidad con la base de datos es rápida?

Respuesta

4

La velocidad de la unidad de registro es el factor más crítico para una base de datos de escritura intensiva. No se pueden producir actualizaciones más rápido de lo que se puede escribir el registro, por lo que su unidad debe ser compatible con su tasa de actualización máxima experimentada en un pico. Y todas las actualizaciones generan registro. archivo de base de datos (MDF/NDF) actualizaciones pueden pagar tasas más lentas de escritura debido a dos factores

  • actualizaciones de datos se escriben con pereza y se vacía al puesto de control. Esto significa que un pico de actualización se amortizará en el rendimiento promedio de unidad
  • varias actualizaciones se pueden acumular en una sola página y por lo tanto se necesita una sola escritura

Así que tienes razón en que el rendimiento de registro es crítico.

Pero al mismo tiempo, las escrituras de registro tienen un patrón específico de escrituras secuenciales: el registro siempre se anexa al final.Todas las unidades mecánicas tienen un rendimiento mucho mayor, tanto para lecturas como escrituras, para operaciones secuenciales, ya que implican menos movimiento físico de las cabezas de disco. Por lo tanto, también es cierto lo que sus operadores dicen que un disco más lento puede ofrecer, de hecho, un rendimiento suficiente.

Pero todos estos vienen con algunos grandes advertencias:

  • la más lenta en coche (o una combinación de RAID) debe realmente ofrecer un alto rendimiento secuencial
  • la unidad debe ver ingrese escribe desde una y sólo una base de datos, y nada más. Cualquier otra operación que pudiera interferir con la posición actual del cabezal del disco va a dañar su rendimiento de escritura y dar como resultado un rendimiento más lento base de datos
  • el registro debe ser solamente escribir, y no lee. Tenga en cuenta que algunos componentes necesitan leer desde el registro, y por lo tanto van a mover la mecánica de disco a otras posiciones para que puedan leer de nuevo el registro escrito anteriormente:
    • replicación transaccional
    • reflejo de base de respaldo
    • registro
+0

+1: Un gran punto acerca de los componentes de SQL que "leen" el registro de transacciones ya que a menudo se pasan por alto. –

+0

Gracias, su información (junto con las otras respuestas) aclara las cosas. Tendremos más de un registro en este disco, aunque uno tendrá con mucho, el tráfico transaccional. También habrá copias de seguridad de registro de transacciones regulares. Creo que un impulso rápido es la apuesta más segura. – Clinemi

+0

Siempre puede usar SQLIOSIM.EXE para probar varias configuraciones antes de la implementación: http://support.microsoft.com/kb/231619 –

2

En términos simples, si está hablando de una base de datos OLTP, su rendimiento se determina por la velocidad de sus escrituras en el Registro de transacciones. Una vez que se alcanza este techo de rendimiento, todas las demás acciones dependientes deben esperar en el compromiso de iniciar sesión para completarse.

Esta es una interpretación MUY simplista de los aspectos internos del Registro de transacciones, al que están dedicados libros enteros, pero el punto rudimentario permanece.

Ahora, si el sistema de almacenamiento con el que está trabajando puede proporcionar los IOPS que necesita para admitir sus archivos de registro de transacciones y de datos de base de datos juntos, una unidad/LUN compartida satisfaría adecuadamente sus necesidades.

Para proporcionarle un curso de acción recomendado específico, necesitaría saber más sobre la carga de trabajo de su base de datos y el rendimiento que necesita que entregue su servidor de base de datos.

Obtenga el título SQL Server 2008 Internals para obtener una visión detallada de las operaciones internas del registro de transacciones de SQL Server, es uno de los mejores títulos de SQL Server y se amortizará en minutos a partir del valor que obtiene de leyendo.

+0

+1: libro (s) de Kalen Delaney es el * * fuente de ir a por todos los detalles. –

+0

¡Gracias por la información! – Clinemi

+0

@Clinemi: ¡De nada y buena suerte con su proyecto! –

0

Bueno, el registro de transacciones es la estructura principal que proporciona ACID, puede ser un gran cuello de botella para el rendimiento y si hace copias de seguridad regularmente su espacio requerido tiene un límite superior, así que lo pondría en un disco seguro y rápido con solo espacio suficiente + un poco de margen.

0

El registro de transacciones debe estar en las unidades más rápidas, si solo puede completar la escritura en el registro, puede hacer el resto de la transacción en la memoria y dejar que toque el disco más tarde.

Cuestiones relacionadas