Preguntas y respuestas sobre SQL&Tamaño de base de datos, creación de reflejos, transacciones marcadas y mucho más

Editado por Nancy Michell

Cómo mover un clúster

P Necesito mover un clúster de SQL Server 2000 a nuevas direcciones IP tanto para los servidores físicos internos, como para el clúster de Windows ® y el clúster de SQL Server™. ¿Tendré que volver a crear por completo la solución?

R No, todo lo que tiene que hacer es ejecutar la configuración de SQL Server y modificar las direcciones IP. En este vínculo puede leer un artículo sobre Microsoft Knowledge Base que explica cómo hacerlo.

Tamaño de la base de datos

P Tengo SQL Server 2000 SP4 en funcionamiento con una base de datos crítica de casi 10 GB, un modelo de recuperación SIMPLE, un archivo principal de 9.850 MB y un archivo de registro de transacciones de 88 MB. La copia de seguridad de la base de datos también tiene casi 10 GB. ¿Tengo que reducir el tamaño de la base de datos para mejorar el rendimiento? En caso necesario, ¿debo utilizar DBCC SHRINKDATABASE o DBCC SHRINKFILE? (Desgraciadamente, no dispongo de horas que no sean horas punta para realizar este mantenimiento.)

DBCC SHRINKDATABASE o DBCC SHRINKFILE sólo le servirán de ayuda si la base de datos experimenta muchas eliminaciones y actualizaciones que tienen como resultado un volumen de datos menor. Pero la verdadera pregunta es, ¿por qué le preocupa? Un espacio en disco de 10 GB puede valer hoy día unos 20 dólares. ¿No tendría más sentido agregar otros 100 GB o más de espacio en disco y continuar con la ejecución? El rendimiento empeorará a medida que el espacio se fragmenta, pero si no puede encargarse de ningún tipo de mantenimiento, no tiene muchas más opciones. A veces se utiliza una segunda copia de la base de datos en este tipo de casos. Se conserva una copia de seguridad actualizada con réplica, se realiza el mantenimiento de la copia de seguridad y, a continuación, se cambian las aplicaciones a la copia de seguridad. Obviamente, este proceso exige algunos cambios de código y el movimiento del modelo de recuperación SIMPLE (a FULL o BULK_LOGGED) pero puede ser una buena solución a largo plazo.

Actualización de versiones y rendimiento

P Necesito mover dos aplicaciones de SQL Server 2000 a SQL Server 2005. ¿Cómo puedo evitar posibles descensos en el rendimiento durante la actualización?

R Generalmente, las siguientes cuestiones pueden provocar una caída del rendimiento durante la actualización a otra versión, de modo que trate de evitarlas:

1. No ha creado de nuevo las estadísticas después de la actualización a SQL Server 2005.
2. Tiene las cláusulas JOINS y WHERE que comparan dos clases de datos diferentes, lo cual tiene como resultado un rendimiento incorrecto, especialmente si el servidor había estado ejecutando SQL Server 2000 SP3 o una versión anterior (consulte support.microsoft.com/kb/271566/).
3. La instancia de SQL Server 2005 no está correctamente configurada; la memoria, las extensiones de ventana de dirección (AWE), los controladores, etc., no se han configurado correctamente. Se ha ajustado el cuadro que ejecuta SQL Server 2000, pero la persona que lo hizo no lo documentó, de modo que fue nunca se realizó en la instancia de SQL Server 2005.
4. El hardware tiene un error. A menudo, se compra nuevo hardware porque parece bueno sobre el papel, pero no da la talla en el día a día.

Antes generar una instancia de SQL Server, debe establecerse una línea de referencia de rendimiento para confirmar que se alcanzará el rendimiento que espera. Esta acción descarta la infraestructura como un posible problema. Es necesario que observe contadores de rendimiento tales como el disco, la E/S y la memoria y que los compare entre las instancias.

Creación de reflejos de bases de datos

P Utilizo la creación de reflejos de bases de datos y quiero habilitar la opción de base de datos READ_COMMITTED_SNAPSHOT. Cuando trato de habilitarla una vez establecida la creación de reflejos, obtengo una excepción que indica que la base de datos se encuentra en una sesión de creación de reflejos y que no puede ejecutarse el comando.

R Esto sucede porque el establecimiento de la opción READ_COMMITTED_SNAPSHOT requiere un reinicio de la base de datos para tener efecto. Por lo tanto, es necesario interrumpir la sesión de creación de reflejos, establecer la opción y reiniciar la base de datos. Una vez realizados esos pasos, puede restablecer la creación de reflejos. La base de datos reflejada interpretará la opción después de que la sesión esté establecida y la utilizará en caso de que se produzca un error.

P Estoy tratando de establecer la creación de reflejos asincrónicos y estoy obteniendo un error 1418. La ejecución de Netstat -ano muestra que SQL Server escucha en el puerto correcto en todos servidores. El error aparece cuando trato de iniciar la creación de reflejos. ¿Qué sucede?

R Una posibilidad es que el firewall esté bloqueando la comunicación; este es un problema relativamente común que debe investigar. Consulte los siguientes artículos para obtener más ayuda: Troubleshooting Database Mirroring Setup (en inglés) y MSSQLSERVER_1418 (en inglés).

Debe tener en cuenta que este problema no es específico de la creación de reflejos asincrónicos. De hecho, puede suceder también con la creación de reflejos sincrónicos.

El error que obtiene ("La dirección de red del servidor "%.*ls” no puede alcanzarse o no existe. Compruebe el nombre de la dirección de red y vuelva a emitir el comando") es correcto. A menudo no se trata de que el socio remoto no exista, lo que sucede simplemente es que no es posible tener acceso a él.

Esto podría suceder si el socio remoto no está disponible, no escucha el puerto, o incluso si el extremo no está disponible (puede suceder si los socios no pueden negociar el mismo mecanismo de cifrado o tienen otros problemas de autenticación). También puede suceder si el socio está bloqueado, lo cual puede ser el resultado de que el firewall del socio esté iniciando el comando.

Otros problemas que quizás desee descartar para incluyen el nombre del origen de datos (DSN) y problemas de resolución de nombres. La recomendación genérica es utilizar nombres de dominio completos. De modo que si bien el firewall puede que sea con frecuencia el problema, recuerde que hay muchas causas posibles.

P Deseo utilizar la creación de reflejos de SQL Server 2005; sin embargo, he oído que no se recomienda la creación de reflejos cuando varias aplicaciones se conectan a varias bases de datos en la misma instancia de SQL Server. ¿Estoy en lo cierto?

R La respuesta depende realmente de si cada aplicación tiene su propia base de datos o de si las aplicaciones utilizan transacciones entre bases de datos transacciones o del Coordinador de transacciones distribuidas (DTC). Si se utilizan transacciones entre bases de datos, entonces la creación de reflejos puede incluir incoherencias lógicas en las que las transacciones no se realizan como se espera. Una buena explicación de lo que sucede en estas circunstancias puede encontrarse aquí.

Si varias aplicaciones utilizan varias bases de datos y cada aplicación tiene su propia base de datos, entonces la creación de reflejos no causará estos problemas.

Transacciones marcadas

P ¿Qué son exactamente las transacciones marcadas y son algo que puede utilizarse si una base de datos es SQL Server y otra es Oracle?

R Marcar una transacción es algo que el administrador de bases de datos hace periódicamente para poner una marca en el mismo lugar en todos los registros. Esta acción, combinada con la capacidad de restaurar una tabla en una marca de transacción, le permite restaurar todas las bases de datos al mismo punto. Hacer esto puede resultar muy laborioso, porque tendrá que restaurar todas las bases de datos implicadas y se perderán datos en todas las bases de datos, de modo que debe evitarlo cerciorándose de que no pierde los archivos de registro. Las transacciones marcadas son específicas de SQL Server, de modo que si sus transacciones distribuidas incluyen bases de datos que no son SQL Server, no podrán participar en el marcado de transacciones. En general, muy pocos sistemas de bases de datos distribuidos utilizan marcas de transacciones. Simplemente tratan la pérdida de uno de los registros de transacciones como un evento catastrófico que requerirá mucho trabajo manual de recuperación.

Herramienta de conversión Access-To-T-SQL

P ¿Hay alguna herramienta de conversión Access™-SQL a T-SQL disponible para procedimientos almacenados?

R Pruebe SQL Server Migration Assistant (SSMA) for Access, que es posible descargar. Allí encontrará también SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase y Migrating Informix Databases to Microsoft ® SQL Server 2000.

Para convertir de Access a SQL Server, podría utilizar el Asistente de conversión de Office, pero SSMA for Access, que se muestra en la Figura 1, tiene más características, incluidos los informes de evaluación de la conversión y exploración de red. SSMA for Access corrige también muchos problemas que actualmente no trata correctamente el Asistente de conversión de Office.

Figura 1** SQL Server Migration Assistant for Access **(Hacer clic en la imagen para ampliarla)

Índices no agrupados

P Tengo una tabla en la que la clave principal está formada por GUID (digamos, GUID1 y GUID2). Ya tuve mi índice único agrupado en GUID1 y GUID2. Ahora, por razones de rendimiento, quiero crear el segundo índice no agrupado en GUID2 y GUID1. ¿Habrá algún efecto indirecto en el rendimiento si declaro el índice como único?

R No hay ninguna penalización en el rendimiento al declarar el índice no agrupado como único. De hecho, el hacerlo puede tener como resultado menos niveles en el árbol de índice.

Cuándo un índice no agrupado se declara como que no es único, el localizador de filas se adjunta a la parte clave de las entradas del índice en las páginas raíz y que no son hojas. Esto se realiza para la eliminación y actualización de entradas de índice, que evita la exploración de cadenas sinónimas cuando hay duplicados para una clave; la entrada específica que se va a cambiar puede localizarse mediante una operación de búsqueda de sistema en el localizador positivo clave. El resultado es que esas entradas son más largas (considerablemente de acuerdo con la clave de clúster que ha elegido). Como resultado, las páginas raíz y que no son hojas se llenarán más rápido de forma natural. Si el índice es único, debe declararlo como tal.

La cuestión es, independientemente de si la tabla tiene un índice agrupado, cualquier índice no agrupado de la tabla que no sea declarado único tendrá el localizador adjunto a las entradas de las páginas raíz y otras páginas que no son hojas.

Además, si utiliza una columna de identificador int como clave suplente y después agrega dos índices únicos (GUID1, GUID2) y (GUID2, GUID1), esto hará que probablemente mejore el rendimiento, ya que los índices tendrán una clave de clúster de 4 bytes en lugar de una clave de clúster de 32 bytes.

Bloqueos de actualizaciones

P Tengo un procedimiento almacenado con la estructura siguiente:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances 
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId ) 
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION

Este procedimiento almacenado admite que sólo una persona que llama tome el bloqueo y hará que cualquier otra persona que llama quede en espera. ¿Puedo lograr el mismo comportamiento reduciendo el nivel de aislamiento?

Parece que READ COMMITTED es el nivel correcto de aislamiento, ya que esta transacción tiene sólo una consulta, y si alguna otra transacción está en proceso de actualizar el mismo registro, esta transacción esperará en la otra transacción. ¿Estoy en lo cierto?

R No es la configuración en serie de su ejemplo lo que hace que las demás personas que llaman permanezcan en espera; es la propia actualización en sí. Sí, puede establecer el aislamiento en READ COMMITTED y la actualización tomará de forma natural cualquier bloqueo de actualización en cualquier índice que utilice. Esto causará problemas a otros procesos que ejecuten la misma instrucción, de modo que se bloquearán hasta que la actualización se realice. (Además, tampoco necesita la transacción explícita aquí si la actualización es la única instrucción; cada instrucción está implícitamente en su propia transacción si no está en una explícita).

Sin embargo, si no hay las filas que coincidan con la cláusula WHERE en la instrucción UPDATE, entonces el uso del nivel de aislamiento serializable evitaría que dichas filas se insertaran o modificaran en otras transacciones. Si fuese a ejecutar UPDATE en el aislamiento READ COMMITTED, esto no sucedería y otras transacciones podrían insertar filas candidatas a la actualización. Si el código del procedimiento almacenado es como el código que ha mostrado, puede que no tenga sentido realizar ninguna de estas acciones (en serie o transacción); simplemente llevar a cabo la actualización.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip y Frankie Yuen.

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