Preguntas y respuestas acerca de SQLErrores de E/S, creación de reflejos de la base de datos, etc.

Paul S. Randal

P He empezado a ejecutar comprobaciones de coherencia con regularidad en las bases de datos que administro e, incluso, he agregado algunas alertas del Agente SQL para localizar los errores de E/S que se indican en las consultas de los usuarios. No sé si la lógica que he implementado en las comprobaciones y las alertas funcionará, ya que mis bases de datos no tienen daños. ¿Cómo puedo crear daños en una base de datos de prueba para asegurarme de que todo lo que he configurado funciona correctamente? Además, ¿qué más puedo hacer para detectar los errores de E/S?

R En SQL Server® 2000, el truco para crear una base de datos dañada en la que realizar pruebas consistía en eliminar manualmente una fila de la tabla sysindexes de una base de datos de prueba. Pero con SQL Server 2005, dañar una tabla del sistema de esta manera es muy difícil. La mejor manera de dañar una base de datos de prueba es usar un editor hexadecimal para alterar un archivo de datos con la base de datos cerrada. Estos son los pasos que debe seguir:

• Cierre la base de datos para que los archivos de datos no estén bloqueados. (Tenga cuidado de no separar la base de datos porque, si daña la página incorrecta, tal vez no pueda unirla de nuevo).
• Elija una parte del archivo de más de 100 páginas aproximadamente (por lo menos de 819.200 bytes) con intervalos de 8.192 bytes (límite de página). De esta forma puede evitar las páginas de metadatos importantes y los mapas de bits de asignación, lo que le permite iniciar la base de datos y ejecutar DBCC CHECKDB en ella.
• Escriba algunos bytes de ceros en la parte elegida del archivo. Al usar esta técnica la introducción de algunos daños en el encabezado de la página está prácticamente garantizada.

Dicho esto, la forma más rápida de dañar una base de datos de prueba es usar una que ya esté creada. Puede encontrar ejemplos de bases datos dañadas de SQL Server 2000 y SQL Server 2005 (con explicaciones) en mi blog (en go.microsoft.com/fwlink/?LinkId=115151).

En cuanto a la segunda pregunta con respecto a lo que se debe hacer para detectar los errores de E/S: debe habilitar las sumas de comprobación de las páginas. Esta característica se introdujo en SQL Server 2005 para proteger una página entera de la base de datos de los errores introducidos por el subsistema de E/S.

Básicamente, al escribir una página en el disco, lo último que hace SQL Server es calcular una suma de comprobación de los 8 KB de la página y marcarla en la página. Al leer una página del disco, si tiene una suma de comprobación de página, se calculará de nuevo y se comparará con la que se almacena en la página. Si no coinciden, significa que algún elemento ajeno a SQL Server dañó la página y se produce un error 824. El error se muestra en la conexión que provocó la lectura de la página, además de registrarse en el registro de error de SQL Server y en el registro de eventos de aplicación de Windows®.

Las sumas de comprobación de página están activadas de forma predeterminada en todas bases de datos creadas en SQL Server 2005 y SQL Server 2008. Sin embargo, hay que habilitarlas manualmente en las bases de datos actualizadas a partir de versiones anteriores de SQL Server. Para habilitar las sumas de comprobación de página, use este código:

ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Sugerencia: cambie el puerto predeterminado de SQL Server

De forma predeterminada, el puerto configurado de las instancias de SQL Server es el 1433. Una vez que una instancia use este puerto, no podrá ocuparlo ninguna otra. Por lo tanto, si instala una segunda instancia (con nombre) de escucha en la red mediante tcp, necesitará otro puerto. En algunos casos, el administrador puede cambiar el puerto por razones de ofuscación (aunque esta forma de ofuscación es secundaria y se puede interrumpir fácilmente mediante un escáner de puerto). Por supuesto, deberá configurar el cliente para usar un puerto diferente. Existen tres enfoques típicos de hacerlo.

Primero, suponiendo que el administrador cambió el puerto de una instancia a 5555, puede especificar simplemente el número de puerto de la instancia dentro del nombre del equipo al que desea conectar mediante la sintaxis MiNombreDeServidor,5555. Si se vuelve a cambiar el puerto, los clientes deberán cambiar sus connectionStrings de nuevo.

Otra opción es usar alias de SQL Server, que se configuran en el cliente. Además de especificar un nombre de alias, debe indicar el nombre de servidor, el nombre de puerto y el protocolo. Una vez configurado, el alias se puede usar como nombre de servidor para conectarse a la instancia de la base de datos. La ventaja que aporta esta opción es que un administrador de dominio puede implementar los cambios de configuración del servidor, ya que la configuración se almacena en el registro.

La tercera opción de las instancias con nombre en las que el usuario sólo conoce el nombre de la instancia y especifica el nombre con la estructura NombreDeEquipo\NombreDeInstancia dentro de connectionString es usar el servicio Explorador de SQL Server. Esto ya se ha implementado en SQL Server 2000 como parte de un servicio en ejecución. No obstante, en SQL Server 2005, se creó el servicio Explorador de SQL Server como servicio independiente. Además del descubrimiento de instancias del equipo, responde a las solicitudes entrantes del protocolo de datagramas de usuario (UDP) en el puerto 1434 con el número de puerto adecuado para la instancia solicitada, lo que permite la redirección del cliente y la compatibilidad de una conexión transparente.

—Jens K. Suessmeyer, consultor de bases de datos en Microsoft

P Para eliminar la fragmentación de la base de datos, he configurado un plan de mantenimiento nocturno que regenera todos los índices de la base de datos de producción que se ejecuta en SQL Server 2005 Enterprise Edition con SP2. He observado que, de esta forma, la base de datos crece demasiado, por eso, agregué un paso para reducir el espacio extra, ya que no hay mucho espacio en el disco. Ahora parece que la regeneración no funciona. ¿Qué pasa?

R Se ha encontrado con un problema al que suelen enfrentarse muchos usuarios cuando intentan configurar un plan de mantenimiento. Ha entrado en un ciclo de reducción y crecimiento.

Al regenerar un índice, se crea una nueva copia del índice antes de eliminar el índice existente. Este procedimiento necesita espacio extra en los archivos de la base de datos (generalmente el mismo espacio que use el índice actual). En SQL Server 2000, también se necesita el espacio extra para ordenar las filas del índice (aproximadamente un 20 por ciento del tamaño del índice), pero ese requisito se ha eliminado en la regeneración de un índice sencillo en SQL Server 2005.

A veces, los administradores desean quitar el espacio extra creado durante la regeneración del índice, por lo que realizan una operación de reducción al plan de mantenimiento después de la regeneración. Sin embargo, poca gente sabe que esta reducción provocará la fragmentación del índice debido a la naturaleza de su algoritmo. Esto significa que el índice regenerado y desfragmentado recientemente se fragmentará de inmediato, lo que anulará el efecto de regeneración en primer lugar.

Ya que el archivo de la base de datos volverá a aumentar la próxima vez que se regenere el índice, es preferible que la base de datos tenga espacio extra y evitar que se ejecute la reducción. (Además, el continuo crecimiento y reducción de los archivos de la base de datos causará la fragmentación de los archivos a nivel de sistema operativo, lo que puede provocar un rendimiento insuficiente al igual que la fragmentación del índice.

Por último, debería plantearse la posibilidad de reducir la frecuencia con que regenera los índices. Incluso puede tratar de usar un método alternativo, como el antiguo DBCC INDEXDEFRAG que escribí para SQL Server 2000 o la nueva sintaxis ALTER INDEX REORGANIZE en SQL Server 2005 y SQL Server 2008.

Hay unas notas técnicas de gran utilidad en las que se trata la fragmentación de índices y ofrece orientación acerca de cuándo eliminar la fragmentación (en go.microsoft.com/fwlink/?LinkId=115154). Aunque este texto se escribió para SQL Server 2000, los conceptos son los mismos.

P Hemos estado evaluando la estrategia de recuperación de desastres en mi organización y creo que la creación de reflejos de bases de datos es el procedimiento correcto en nuestra situación. El servidor que intento proteger tiene muchas bases de datos no relacionadas (resultado de un proyecto previo de consolidación de servidores) y quiero usar la creación de reflejos de bases de datos para todas. Mi pregunta es la siguiente: ¿cuántas bases de datos se pueden reflejar antes de que se reduzca el rendimiento?

R La respuesta a esta pregunta es muy típica: depende. Las directrices publicadas aconsejan no reflejar más de 10 bases de datos por instancia, pero depende de cada usuario. Hay que tener en cuenta los siguientes factores para la instalación del hardware:

• ¿De cuánta memoria disponen las instancias principal y reflejada? (Lo idea sería que dispongan de la misma.)
• ¿Cuánta capacidad de procesamiento tienen las instancias principal y reflejada? (También debería ser la misma.)
• ¿Cuánto ancho de banda tiene el subsistema de E/S de la instancia reflejada? (Debería tener tanto como el de la principal.)
• ¿Cuántos registros de transacciones genera la carga de trabajo en cada base de datos?
• ¿Cuánto ancho de banda de red está disponible entre las instancias principal y la reflejada?

Los últimos dos factores son los más importantes. Si el ancho de banda de red disponible entre las dos instancias no es suficiente para encargarse la velocidad de generación de registros de transacciones combinados por segundo de todas las bases de datos reflejadas, el rendimiento disminuirá en las bases de datos principales. SQL Server 2008 ayuda a mejorar una parte de esta carga mediante la compresión de secuencias de registro.

El siguiente aspecto más importante a tener en cuenta en la creación de reflejos es la memoria y los requisitos de los subprocesos. Todas las bases de datos reflejadas ocupan un subproceso además de memoria. Si un servidor de baja potencia tiene una muchas bases de datos reflejadas, esto puede suponer una carga excesiva para el servidor al combinarlas con la carga de trabajo habitual.

Además, debe tener en cuenta cómo llevará a cabo la creación de reflejos de bases de datos. En el modo sincrónico, las transacciones de la base de datos principal no se pueden confirmar hasta que todos los registros de transacciones se hayan copiado en el registro de transacciones de la base de datos reflejada. Por lo tanto, cualquier retraso causado por una red sobrecargada podría provocar un problema de rendimiento de la carga de trabajo de la principal.

En el modo asincrónico, las transacciones se pueden confirmar en la principal sin tener que esperar, aunque un retraso de la red podría aumentar el número de registros de transacciones en espera de envío. Esto puede causar problemas relacionados con el tamaño del registro de transacciones. O, lo que es peor, los registros de transacciones que no se hayan enviado se perderán en caso de error. Por lo tanto, cuantos más registros de transacciones queden sin enviar, mayor será la probabilidad de perder datos en una situación de recuperación.

Las situaciones pueden ser muy diferentes y he detectado algunos ejemplos interesantes en entornos de producción reales. Por ejemplo, advertí un entorno con 150 bases de datos con una actividad muy pequeña y sin sincronización. Las 150 bases de datos se reflejaron sin problemas.

Por el contrario, también pude ver una configuración que solamente tenía tres bases de datos muy cargadas sin una conexión de red buena. En esa situación, apenas se pudo reflejar una base de datos antes de que la falta de ancho de banda de la red degradara la carga de trabajo.

La clave del éxito es, en primer lugar, realizar el cálculo de generación de registros. Si parece que el ancho de banda de red disponible puede ser compatible con el número de las bases de datos que desea reflejar, no debería haber ningún problema. Pruebe su configuración antes de ponerlo en ejecución y asegúrese de incluir todas operaciones que podrían generar un registro de transacciones (especialmente todo el mantenimiento de bases de datos que pueda realizar).

Paul S. Randal es el director general de SQLskills.com y uno de los profesionales más valorados (MVP) de SQL Server. Trabajó en el equipo del motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Paul escribió las directrices de reparación de DBCC CHECKDB para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Es experto en recuperación de desastres, en alta disponibilidad y en el mantenimiento de bases de datos, además de moderador habitual en congresos. Además, es autor de un blog: SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.