SQL Q & A: Restauración y configuración
SQL Server es una plataforma poderosa, pero requiere astucia al considerar su configuración de registro de transacciones y otras preguntas de configuración.
Paul S. Randal
Registros de transacciones de XXXL
P: Nuestro producto, utiliza SQL Server para almacenar datos. Cada tan a menudo, publicamos una nueva versión de nuestro producto que incluye una secuencia de comandos de actualización para que se ejecute en la base de datos. Tal como nos estábamos probar nuestro script de actualización más reciente de una base de datos de prueba representativo, el archivo de registro de transacciones se incrementó a más de 40 GB. Nos gustaría evitar que el archivo de registro tan grande. ¿Cuáles son nuestros opciones? Se debe cumplir con el modelo de recuperación completa para la recuperación ante desastres.
A: Para empezar con es fantástico que está probando en los datos de cliente representativo. Muchas veces, veo los proveedores de la aplicación en capas probar estos tipos de secuencias de comandos en pequeños conjuntos de datos y, a continuación, libera a los clientes que se ejecución en todos los tipos de problemas de producción. Podrá responder su pregunta como si es usted el usuario. A continuación, se puede traducir en el contexto de sus clientes.
Se dice que necesitas para estar con el modelo de recuperación completa. Esto implica la transacción ya que está realizando copias de seguridad del registro y no tiene problemas generales con el registro de transacciones crece fuera del control. Esto es bueno, teniendo copias de seguridad del registro de transacciones es la única operación que permite el registro de transacciones borre una vez que se han confirmado las transacciones. (Para esto, consulte de technet.microsoft.com/magazine/2009.02.logging , donde se explica cómo funciona el registro de transacciones y cómo los diferentes modelos de recuperación afectan a su comportamiento.)
Dicho esto, la frecuencia con la que realiza copias de seguridad de registro de transacciones es una cosa que se dicta la rapidez con borrar y no incrementan el registro de transacciones. Por ejemplo, si el trabajo de copia de seguridad regular realiza una copia de seguridad del registro de transacciones cada 30 minutos, el archivo de registro de transacciones debe ser suficiente para contener la mayor cantidad de datos de registro de transacciones que se pueden generar en un plazo de 30 minutos. De lo contrario, aumentará.
Si la secuencia de comandos de actualización se ejecuta en 60 minutos, que se puede trabajar a 20 GB de registro de transacciones que se genera cada 30 minutos, por lo que tendrá el archivo de registro de transacciones a 20 GB. Que es probablemente aún demasiado grande, por lo que tendrá que realizar copias de seguridad del registro de transacciones más frecuentemente, mientras se está ejecutando la secuencia de comandos de actualización. Borrar con más frecuencia y evitar que aumente de tamaño por lo tanto, esto permite el registro de transacciones. Se tenía una situación similar a una ubicación del cliente y ha terminado realizar una copia de seguridad del registro de transacciones una vez por minuto durante varias horas, mientras que una secuencia de comandos similar se ejecutaba en una base de datos.
Una cosa a tener en cuenta es que estas transacciones “ adicional ” forman parte de las copias de seguridad de la cadena de copia de seguridad del registro de la sesión y que son necesarios para la recuperación de desastres. Asegúrese de que todos tienen un nombre descriptivo y no se eliminan.
Hay otro factor a tener en cuenta: ¿Cuál es la única transacción más grande que forme parte del proceso de actualización que ha aplicado ingeniería? Puede borrar el registro de transacciones sólo si las entradas del registro de transacciones confirmadas (que puede ser oversimplifying un poco, consulte el artículo mencionado para obtener más detalles). Esto significa que una transacción de larga ejecución no permite el registro de borrar, incluso aunque el registro de transacciones hace copia de seguridad del registro de transacciones generados de copia de seguridad.
Si la secuencia de comandos de actualización contiene una transacción que requiere de 15 GB de espacio de registro, el archivo de registro de transacciones debe ser al menos de 15 GB para contener toda la transacción hasta que lo confirme. Si es así, independientemente de la frecuencia con realiza una copia de seguridad del registro de transacciones, no desactive el registro de transacciones. En este caso es el único recurso dividir las transacciones de gran tamaño en otras más pequeñas, si es posible.
Téngalo en cuenta: el tamaño del registro de transacciones necesario para ejecutar la secuencia de comandos de actualización determina la frecuencia de las copias de seguridad del registro de transacciones y el tamaño de la transacción más grande que se crea.
Configuración acertijo
P: Nos estamos aprovisionamiento algunos nuevo almacenamiento de información de conexión directa de uno de nuestros servidores de base de datos, y desea asegurarse de que conoce todas nuestras opciones y obtener la configuración correcta. ¿Puede explicar las diversas opciones de configuración que debe tener en cuenta lo que se refiere a SQL Server?
A: Existen diversas opciones de configuración cuando el aprovisionamiento de almacenamiento, por lo que yo prefiero implicar a un administrador de almacenamiento dedicada. Hay definitivamente algunas opciones con el que un administrador de SQL Server se debe que se trate y asegúrese de establecerla de forma adecuada.
La primera es el nivel RAID subyacente. Los distintos niveles RAID tienen diferentes pros y contras lo que se refiere a rendimiento y redundancia. Por ejemplo, la configuración de RAID más barata que sigue ofreciendo algunos redundancia es RAID-5, pero sólo es adecuada para esta configuración con un error de disco único (a menos que se utiliza RAID-6, o configurar las unidades de la espera activa) y a veces puede deteriorar el rendimiento para cargas de trabajo con gran cantidad de escritura, dependiendo de cuántas unidades se encuentran en la matriz.
RAID 10 proporciona el mejor redundancia, pero es más caro. La capacidad total de la matriz como máximo es la mitad de la capacidad total de las unidades de componentes. Se presenta una excelente explicación de los distintos niveles RAID en el apéndice A de las notas de TechNet “ del diseño físico de almacenamiento de base de datos. ”
Los principales factores a tener en cuenta son el tamaño de bandas RAID, el tamaño de unidad de asignación de NTFS (el tamaño de clúster) y la alineación de la partición de disco. Todos estos factores pueden reducir considerablemente el rendimiento si establecen incorrectamente. Lo más importante es la alineación de la partición de disco para volúmenes de disco creadas con Windows Server 2003. Se utiliza una alineación de 31,5 KB de forma predeterminada, que no coincide con los tamaños de bandas RAID comunes de 64 KB (o un múltiplo del mismo). Por lo tanto, cada E/s, esencialmente, debe leer o escribir dos bandas RAID para satisfacer la E/S. Obviamente, esto hace que gran degradación del rendimiento.
Windows Server 2008, se utiliza una alineación de 1 MB de forma predeterminada. Todos los volúmenes creados en Windows Server 2003 y actualizado para que se aloja en Windows Server 2008 no es necesario su alineación cambia, por lo que aún pueden verse afectados. Corregir este problema implica volver a formatear los volúmenes, pero el aumento del rendimiento que sea a menudo, un paso que merece la pena.
Una discusión detallada de estos es en realidad más allá del alcance de esta columna, pero hay más detalles (y vínculos para obtener más información) en la entrada de blog, “ tamaños de bandas se desplaza de la partición del disco, RAID y unidades de asignación de NTFS configurado correctamente? ”
Cuando el aprovisionamiento de cualquier nuevo almacenamiento, es una buena idea para la prueba de carga y pruebas de rendimiento antes de iniciar una carga de trabajo de producción. Prueba de carga le permite vaciar los problemas de configuración que podrían resultar en pérdida de datos o el tiempo de inactividad. Se requiere la ayuda a comprobar que el nuevo almacenamiento proporciona la capacidad de E/s de la carga de trabajo de pruebas de rendimiento. Microsoft cuenta con herramientas gratuitas para ayudar con esto, que puede obtener más información acerca de las notas del producto “ de prácticas recomendadas de E/s de Pre-Deployment. ”
Espejo, duplicación
P: Soy un poco confundido sobre la naturaleza del servidor testigo al configurar la creación de reflejos de base de datos. ¿Cómo eficaz el servidor testigo deben ser? ¿Depende el número de bases de datos para que lo hace de conmutación por error? ¿Es importante en los centros de datos se realiza el servidor testigo? Quisiera estar seguro de obtener la máxima disponibilidad de las bases de datos reflejadas.
A: La función de servidor testigo es uno de los aspectos de peor comprendidos de cualquier sistema de creación de reflejos de base de datos. El servidor testigo en una configuración de creación de reflejos de base de datos sincrónica existe únicamente para ayudar a facilitar una conmutación por error automática en caso de que el servidor principal deja de estar disponible.
El servidor principal envía continuamente entradas del registro de transacciones para el servidor reflejado, nunca en el servidor testigo. Los servidores principal, espejo y testigo hacer ping entre sí por segundo como parte del mecanismo de detección automática de errores. Si el servidor reflejado, se determina que no se puede comunicar con el servidor principal por cualquier razón, no puede iniciar una conmutación por error automática, a menos que el servidor testigo está de acuerdo que no se puede comunicar con el servidor principal. Si está de acuerdo de los dos servidores, constituye un quórum y el servidor reflejado inicia una conmutación por error automática. Si un servidor testigo no está presente, no puede haber un quórum y una conmutación por error automática no es posible.
Por lo tanto, el servidor testigo existe únicamente para formar un quórum de la Ayuda. No iniciar migraciones tras error ni reproducir cualquier parte en la que se aloja la base de datos reflejada. Normalmente, el quórum existe entre los servidores principal y reflejada.
Como el servidor testigo sin procesar como tal, no es necesario ser un servidor eficaz. Pueden alojar todas las ediciones de SQL Server, incluido el gratuita SQL Server Express Edition. También hay ningún límite en el número de sesiones para que una instancia concreta de SQL Server puede actuar como testigo de la creación de reflejos de base de datos.
El servidor testigo mejor se coloca en un centro de datos independiente de los servidores de entidad de seguridad o de espejo. Sin embargo, la mayoría de las empresas no tienen tres centros de datos, por lo que la pregunta es si se debe colocar el servidor testigo con el servidor reflejado o con el servidor principal.
Cuando hay sólo dos centros de datos, siempre se debe colocar el servidor testigo con el servidor principal. La razón por la que se tiene que ver con la que forman un quórum. Si los servidores de testigo y reflejo son comparten ubicación y el vínculo de red de baja al servidor principal, un quórum formará entre el testigo y el espejo y el servidor reflejado iniciará una conmutación por error.
El servidor principal, que no tengan ningún problema en absoluto, pondrá fuera de conexión la base de datos principal cuando pierde el quórum. Se supone que la duplicación realiza una conmutación por error en este caso. Para evitar esto, unión de los servidores principal y testigo permite la entidad de seguridad del quórum de mantener con el testigo en el caso de un error de la red. La base de datos principal sigue estando disponible.
El servidor testigo es totalmente opcional, pero no hay ninguna posibilidad de una conmutación por error automática, y por lo que se va a reflejar la máxima disponibilidad de la base de datos, sin él. Creación de reflejos de base de datos funciona igual en todos los demás aspectos. Si un servidor testigo está configurado, pero no está disponible por alguna razón, no hay sin pérdida en funcionalidad excepto la posibilidad de realizar una conmutación por error automática de la creación de reflejos.
También puede tener dos testigos para una sesión de creación de reflejos de base de datos. La única forma para agregar redundancia con aún más a la función de servidor testigo es que la instancia SQL Server auxiliar alojada en un clúster de conmutación por error. Puede obtener más información sobre las configuraciones en el TechNet white paper “ el reflejo de base de datos en SQL Server 2005 . ” de creación de reflejos de base de datos
.jpg)
Paul S. Randal es el director de administración de SQLskills.com, un director regional de Microsoft y un MVP de SQL Server. Trabajó en el equipo de motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Escribió DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Randal es experto en recuperación ante desastres, alta disponibilidad y mantenimiento de bases de datos, y es moderador habitual en conferencias en todo el mundo. Le que blogs en SQLskills.com/blogs/paul y puede encontrar en Twitter en Twitter.com/PaulRandal.