He visto que nuestra base de datos tiene el modelo de recuperación completo y tiene un registro de transacciones de 3GB.¿Cómo afecta un registro de transacciones grande al rendimiento?
A medida que el registro aumenta, ¿cómo afectará esto el rendimiento de la base de datos y el rendimiento de las aplicaciones que acceden a la base de datos?
JD
La mejor práctica recomendada es asignar un archivo de registro de transacciones de SQL Server a su propio disco o LUN.
Esto es para evitar la fragmentación del archivo de registro de transacciones en el disco, como han mencionado otros carteles, y también para evitar/minimizar la contención del disco.
El escenario ideal es que su DBA asigne con tiempo suficiente espacio de registro para su entorno de base de datos, es decir, asigne, por ejemplo, x GB de datos de una vez. En un disco dedicado, esto creará una asignación contigua, evitando así la fragmentación.
Si necesita hacer crecer su registro de transacciones, nuevamente debe esforzarse para hacerlo en trozos considerables a fin de tratar de asignar contiguamente.
También debe considerar NO reducir el tamaño del archivo de registro de transacciones, ya que las contracciones repetidas y el crecimiento automático pueden provocar la fragmentación del archivo de datos en el disco.
Creo que es mejor pensar en la propiedad de base de datos de crecimiento automático como failsafe, es decir, su DBA debe supervisar proactivamente el espacio de registro de transacciones (quizás configurando alertas) para que puedan aumentar el tamaño del archivo de registro de transacciones. requisitos, pero la propiedad de crecimiento automático puede implementarse para garantizar que su base de datos pueda continuar funcionando normalmente en caso de que ocurra un crecimiento inesperado.Un archivo de registro de transacciones más grande en sí mismo si no es perjudicial para el rendimiento ya que el servidor SQL escribe secuencialmente en el registro, por lo que siempre que administre su tamaño de registro general y la asignación de espacio adicional no debería preocuparse.
Si el registro se fragmenta o necesita para crecer que se ralentizará la aplicación.
Si no borra el registro de transacciones periódicamente realizando copias de seguridad, el registro se llenará y consumirá todo el espacio disponible en el disco.
De varias maneras.
Si su sistema está configurado para hacer crecer automáticamente el registro de transacciones, a medida que el archivo se agranda, su servidor SQL necesitará hacer más trabajo y posiblemente se ralentizará. Cuando finalmente se quede sin espacio, no tendrá suerte y su base de datos dejará de tomar nuevas transacciones.
Necesita obtener con su DBA (¿o quizás usted es el DBA?) Y realizar copias de seguridad periódicas y periódicas. Guárdelos de su servidor en otro sistema de respaldo dedicado. A medida que haga una copia de seguridad del registro, se recuperará el espacio en su archivo de registro existente, lo que impedirá que el registro sea mucho más grande. Copia de seguridad del registro de transacciones también le permitirá restaurar su base de datos a un punto específico en el tiempo después de su última copia de seguridad completa o diferencial, lo que reduce significativamente sus pérdidas de datos en el caso de una falla del servidor.
Si el archivo de registro aumenta de tamaño en pequeños pasos, terminará con una gran cantidad de archivos de registro virtuales estos archivos de registro virtuales ralentizarán las operaciones de inicio, restauración y respaldo de la base de datos.
aquí es un artículo que muestra cómo solucionar este problema: http://www.sqlserveroptimizer.com/2013/02/how-to-speed-up-sql-server-log-file-by-reducing-number-of-virtual-log-file/
Eso es un título engañoso. Estoy seguro de que es solo un error tipográfico, pero "transacción grande" y "gran registro de transacciones" son cosas muy diferentes, ¡estoy seguro de que lo sabes! –