Preguntas y respuestas sobre SQLBest Practices Analyzer, procesadores multinúcleo y otros

Editado por Nancy Michell

P Tengo varias preguntas acerca de la regla de Best Practices Analyzer (BPA) sobre el uso de tablas/vistas de esquema calificado. Según la documentación de BPA, esta regla no comprueba la calificación del esquema en las tablas temporales. El informe de BPA apunta referencias a tablas temporales creadas en procedimientos almacenados. ¿Deben calificarse? Si es así, ¿con qué esquema? Diría que las tablas temporales deben calificarse para sus propietarios igual que las otras tablas.

R En realidad, la recomendación de BPA para referencias de vista y tabla de esquema calificado no se aplica a SQL Server™ 2005, ya que la separación de usuario y esquema corrigió el problema que requería esta práctica en versiones anteriores de SQL Server. La calificación de esquemas era necesaria para habilitar el reuso del plan de consulta por diferentes usuarios que tenían diferentes esquemas predeterminados en SQL Server 2000. Estos usuarios podían usar objetos dbo sin calificación, pero SQL Server tenía que comprobar primero los esquemas predeterminados para los objetos, lo que impedía el reuso del plan de consulta. La separación de usuario y esquema permite que diferentes usuarios compartan un esquema predeterminado y, en el caso típico, que todos los usuarios de la base de datos obtengan acceso a objetos de los esquemas predeterminados; por lo general, los planes ad hoc con nombres de tabla y vista incompletos se compartirán y se volverán a usar. En primer lugar, los nombres de tabla y vista incompletos de los procedimientos almacenados nunca tuvieron este problema, lo que reduce todavía más la necesidad de esta práctica. BPA en SQL Server 2005 no incluirá reglas de este tipo, puesto que no tiene un analizador de T-SQL. En vez de eso, buscará configuraciones y valores de seguridad no adecuados.

P SQL Server 2005 SP1 tiene un comportamiento extraño. Si elimino registros de una tabla y realizo inserciones en dicha tabla al mismo tiempo, las inserciones se bloquean hasta que se confirma la transacción de eliminación. ¿Hay alguna manera de saber por qué se bloquean?

R Sí. Puede ejecutar la secuencia de comandos de vistas de administración dinámicas (DMV) de la figura 1 para buscar los bloqueos y los bloqueadores.

Figure 1 Buscar bloqueos y bloqueadores

-- script to show blocking and locks
SELECT 
  t1.request_session_id AS spid, 
  t1.resource_type AS type, 
  t1.resource_database_id AS dbid, 
  (case resource_type 
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id) 
   WHEN ‘DATABASE’ THEN ‘ ‘ 
   ELSE (SELECT object_name(object_id) 
      FROM sys.partitions 
      WHERE hobt_id=resource_associated_entity_id) 
  END) AS objname, 
  t1.resource_description AS description, 
  t1.request_mode AS mode, 
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address 
GO

P Además de la tecnología HyperThreading y de doble núcleo, los proveedores de chips empiezan a comercializar procesadores con núcleos adicionales (cuatro, ocho o más). Estoy pensando en comprar un servidor nuevo con procesadores de varios núcleos que sea compatible con una implementación de SQL Server 2005 Standard Edition y me pregunto si, al usar un procesador de cuatro núcleos, sólo podré usar una única CPU física (pues la Standard Edition está limitada a cuatro CPU)?

R Tanto para la compatibilidad de ediciones de licencia como de CPU, SQL Server sólo tiene en cuenta el número de sockets/CPU físicos, independientemente del número de núcleos que tenga el procesador. Así, por ejemplo, el hecho de que SQL Server 2005 Standard Edition admita 4 CPU significa que admitirá 4 sockets de la CPU física, independientemente del número de núcleos que contenga cada una (si tiene 4 CPU físicas con 4 núcleos cada una, la implementación de Standard Edition tendrá 16 CPU lógicas para usar). Además, aunque tenga 16 núcleos/CPU lógicas, la licencia sólo requiere que pague las 4 CPU físicas, no los 16 núcleos. Para obtener más información sobre SQL Server y la tecnología de varios núcleos, consulte el sitio microsoft.com/sql/howtobuy/multicore.mspx.

P Voy a comprar varios servidores de base de datos nuevos. ¿Es mejor adquirir una versión de 64 bits o seguir con las versiones de 32 bits probadas y comprobadas?

R Depende. Se trata de una pregunta muy común actualmente, pues los proveedores están transformando el hardware de x86 a x64. La primera pregunta que debe plantearse es la demanda de memoria que tendrá el servidor de base de datos. Si prevé que la sesión de SQL Server consuma menos de 3 GB de RAM durante la vida del hardware (por lo general, tres años), le bastará con 32 bits x86 si esa es la dirección para otros servidores (controladores de dominio, servidores DNS, servidores de aplicaciones, servidores web, servidores de correo). Si prevé que la sesión de SQL Server consuma más de 16 GB o que haya varias sesiones por servidor (o clúster), considere seriamente la posibilidad de pasar a tecnologías de 64 bits. Si va a contar con más de ocho procesadores, la recomendación estándar es IA64. Sin embargo, cuando las CPU x64 de cuatro y ocho núcleos empiecen a llegar a las calles, es posible que el costo sea un aspecto importante a la hora de decantarse por una x64 antes que por una IA64.

Al pasar a x64 (o IA64), es posible que no haya incluido en las estimaciones iniciales de costos la implementación de la misma arquitectura en los entornos de desarrollo, prueba y rendimiento. También debe preguntarse si desea estancarse con tecnología antigua a medio camino del ciclo de vida del hardware. En 18 meses, será muy difícil obtener hardware puramente x86. Si ahora se decide por esa clase de solución, la actualización en los próximos dos años será costosa, pues será necesario desechar y cambiar. Si se decide por un hardware de 64 bits ahora, tendrá más opciones en los años venideros.

Así que es un buen momento para hacer el salto a la tecnología de 64 bits si va a comprar hardware nuevo, al comienzo de un ciclo de lanzamiento de la aplicación principal o si va a actualizar SQL Server 2000 a SQL Server 2005.

P Tengo el envío de registros habilitado entre dos servidores. Durante el fin de semana, un problema de hardware en el servidor principal provocó la detención del envío de registros. Cuando volví para supervisar el envío de registros, vi que LS_backup_dbname se estaba ejecutando bien a pesar de las horas de inactividad.

Sin embargo, en el servidor secundario, el trabajo de copia funciona correctamente, pero parece que el trabajo de restauración omite archivos y, eventualmente, falla constantemente. Se ejecuta, pero omite todos los archivos y, después, falla. De modo que el tiempo desde la última restauración es ahora de 849 minutos. En el pasado, en situaciones similares, tan sólo reinicié la configuración de envío; es decir, lo desactivé y lo volví a activar para obtener una copia de seguridad nueva y poder restaurarlo en el servidor secundario del registro de servidor. El envío de registros volvió a empezar. ¿Hay una manera mejor de administrar este escenario?

R Seguramente el escenario que tiene delante es el resultado de que falten archivos de copia de seguridad. Como ya sabe, los trabajos de copia de seguridad, copia y restauración del envío de registros se ejecutan de manera independiente. Los archivos de copia de seguridad antiguos que se encuentran en la ubicación de copia también se eliminan de acuerdo con el programa que especifique. Si durante un espacio de tiempo el trabajo de restauración no se ejecutó, es posible que haya superado el intervalo, lo que tendría como resultado la pérdida de archivos de copia de seguridad. El trabajo de restauración del envío de registros tiene una lógica que intenta recuperarse de diferentes tipos de errores provocados por condiciones operativas diferentes. Básicamente, revisa los archivos cuando se detectan errores e intenta encontrar los archivos de copia de seguridad correctos. Si no encuentra un archivo de copia de seguridad correcto, sospecho que algo ha eliminado los archivos necesarios o que, posiblemente, haya vuelto a configurar la parte de copia de seguridad del envío de registros.

Una solución sería restaurar manualmente los archivos de copia de seguridad de registro de transacciones que creó de forma inadvertida el otro trabajo de copia de seguridad. El problema de copiarlos en la ubicación de copia del envío de registros son las convenciones de nombres que reconoce el envío de registros. Una vez que haya realizado la restauración manual hasta ese punto, la restauración normal debería retomarse y continuar.

P Necesito saber cómo usar T-SQL para averiguar el tamaño de la memoria física libre y total. ¿Existe alguna manera fácil de obtener esta información?

R Ejecute la consulta de la figura 2 y obtendrá los datos que busca.

Figure 2 Obtener memoria

With VASummary(Size,Reserved,Free) AS 
(SELECT 
  Size = VaDump.Size, 
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0) 
  WHEN 0 THEN 0 ELSE 1 END), 
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0) 
  WHEN 0 THEN 1 ELSE 0 END) 
FROM 
( 
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes)) 
    AS Size, 
    region_allocation_base_address AS Base 
  FROM sys.dm_os_virtual_address_dump 
  WHERE region_allocation_base_address <> 0x0 
  GROUP BY region_allocation_base_address 
  UNION 
  SELECT CONVERT(VARBINARY, region_size_in_bytes), 
    region_allocation_base_address 
  FROM sys.dm_os_virtual_address_dump 
  WHERE region_allocation_base_address = 0x0 
) 
AS VaDump 
GROUP BY Size)
 
SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024 
    AS [Max free size, KB] 
FROM VASummary 
WHERE Free <> 0 

P Quiero almacenar la contraseña de sa (administrador del sistema) en un archivo cifrado con una clave simétrica para facilitar la creación de bases de datos desde una aplicación. ¿Puedo hacerlo?

R En primer lugar, nunca debería usar sa desde una aplicación. Además, debe usar la autenticación de Windows en vez de la autenticación de SQL Server.

Si necesita realizar actividades con muchos privilegios, haga lo siguiente: Defina los permisos mínimos necesarios para realizar la acción. Defina una función de base de datos que contenga dichos permisos. Asigne un usuario a esa función. Cree un procedimiento almacenado con la cláusula EXECUTE AS para realizar esas funciones. Si desea ver una explicación de la cláusula Execute As, visite el sitio msdn2.microsoft.com/ms188354.aspx.

Por supuesto, si pasamos por alto el hecho de que la cuenta en cuestión sea la cuenta de sa o no, y teniendo en cuenta que la autenticación de Windows no siempre es una opción, la pregunta más básica es: ¿cómo se almacena de forma segura una contraseña para una cuenta de inicio de sesión de SQL Server de manera que la aplicación que debe usar esa contraseña pueda obtener acceso a ella, pero los usuarios o aplicaciones no autorizados no puedan?

El cifrado de la contraseña es un paso en la dirección correcta, pero traslada el problema de proteger la contraseña a proteger la clave de cifrado.

Suponiendo que se trata de una aplicación basada en Microsoft® NET Framework, consulte la biblioteca de información empresarial en msdn2.microsoft.com/aa480453.aspx y las recomendaciones de la sección patterns & practices de MSDN® en msdn.microsoft.com/practices. La biblioteca de información empresarial contiene varios bloques de aplicación que le serán de utilidad, incluido un bloque de configuración, un bloque de criptografía y un bloque de acceso a datos; estos bloques pueden ayudarle a (por lo menos) almacenar de forma segura las contraseñas y, lo que es más, a administrar el acceso a datos en general.

Si la biblioteca de información empresarial no es una opción (quizás no use .NET Framework), debe familiarizarse con la CryptoAPI: msdn2.microsoft.com/aa380255.aspx. Aquí encontrará la funcionalidad criptográfica principal distribuida con el sistema operativo que le puede permitir asociar claves criptográficas a una entidad principal de usuario o a un equipo, lo que puede simplificar la administración de claves (que supone un problema cuando se ha cifrado la contraseña).

P Quiero mover mi servidor de clústeres de dos nodos de SQL Server 2000 (Activo/Activo, en hardware de 64 bits) del Dominio A al Dominio B dentro del mismo bosque. La base de datos de SQL Server se encuentra en la SAN. La arquitectura de Active Directory® llama a un dominio raíz vacío con dos dominios secundarios (el Dominio A y el Dominio B). El Dominio B será el dominio donde se colocarán todos los componentes de infraestructura. Es un entorno de Windows Server ® 2003 Enterprise, con controladores de dominio adicionales que ejecutan Windows 2000.

¿Se puede cambiar la pertenencia al dominio del servidor de clústeres de SQL Server del Dominio A al Dominio B?

R Para empezar, consulte "Cómo cambiar dominios de un clúster de conmutación por error de SQL Server 2000" y "Cómo mover un Windows Cluster Server de un dominio a otro". El mismo proceso se aplica a los clústeres de varias sesiones. La única diferencia es que tendrá que repetir los pasos para todas las sesiones que sea necesario. Nunca es "recomendable" cambiar el dominio de un clúster, dada la complejidad de la tarea, aunque se ha hecho muchas veces. La otra manera de hacerlo es como indica en su consulta, volver a generar una sesión nueva en paralelo y migrar los datos.

Cada proyecto es diferente y se usan una gran variedad de herramientas para realizar el verdadero cambio de nivel de dominio (incluidas consideraciones de seguridad, migraciones de cuenta, asignaciones SID, etc.). A menudo, esa es la parte más difícil del proceso, no el cambio en sí.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Sunil Agarwal, Laurent Banon, Steve Bloom, Chad Boyd, Matt Burr, Shaun Cox, Cindy Gross, Bobby Gulati, Matt Hollingsworth, Arnost Kobylka, Mikhail Shir, Fernando Pessoa Sousa, Stephen Strong y Ramu Veeraraghavan.

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