Cambios de comportamiento en las características del Motor de base de datos en SQL Server 2008

En SQL Server 2008, las mejoras del diseño de las tablas con particiones facilita un mayor paralelismo durante el procesamiento de las consultas sobre las tablas con particiones que en SQL Server 2005. Como consecuencia de este cambio del diseño, solo se pueden colocar combinaciones bidireccionales. Los planes de consulta de las combinaciones por colocación bidireccionales en SQL Server 2008 tienen la misma apariencia que en SQL Server 2005 y un rendimiento comparable a SQL Server 2005. Si en la combinación se incluyen tablas adicionales con particiones alineadas, se seleccionará un plan diferente, por ejemplo una combinación por colocación bidireccional seguida de una combinación hash con la tercera tabla. Las combinaciones por colocación entre más de dos tablas son inusuales. Las combinaciones por colocación no se benefician de las mejoras del paralelismo en SQL Server 2008. Sin embargo, si tiene una consulta para la que SQL Server 2005 realiza una combinación por colocación de tres o más formas, es posible que la consulta pueda ejecutarse más lentamente en SQL Server 2008 si la cantidad de memoria es pequeña con respecto al tamaño de las tablas. Para mejorar el rendimiento en esta situación se puede, por ejemplo, aumentar la cantidad de memoria que está disponible y reescribir la consulta de modo que las particiones individuales se unan de forma independiente antes de combinar los resultados. Para obtener más información sobre las combinaciones por colocación, vea Mejoras de procesamiento de consultas en las tablas e índices con particiones.

SQL Server dispone de una nueva optimización para procesar las consultas con combinaciones en estrella que utiliza combinaciones hash y filtros de mapas de bits. Cuando una consulta procesa cantidades grandes de datos de tablas de hechos que se combinan con tablas de dimensiones en un esquema en estrella, un plan de consulta que use la nueva optimización puede ejecutarse mucho más rápidamente. 

Así, puede ver un nuevo plan de consulta para las consultas existentes si se ajustan al patrón de la combinación en estrella. El optimizador de consultas elige este plan cuando sus estimaciones indican que el rendimiento de las consultas va a aumentar. Sin embargo, si las estadísticas utilizadas en la estimación del costo son inexactas, el optimizador de consultas podría elegir la optimización de la combinación en estrella cuando un plan diferente sería más rápido.

Si la opción de configuración Grado máximo de paralelismo o la opción de índice MAXDOP está establecida en 1, el optimizador de consultas no utilizará la optimización de la combinación en estrella y no experimentará los beneficios que ofrece esta nueva optimización. Si el sistema de ejecución de consultas envía una consulta optimizada con un plan paralelo con solo un subproceso, es posible que algunos filtros de mapas de bits se eliminen de un plan de combinación en estrella con varios filtros de mapas de bits. Este cambio puede ralentizar más de lo esperado la ejecución al bajar de dos subprocesos a uno, por ejemplo.

La optimización de la combinación en estrella solo está disponible en las ediciones Enterprise, Developer y Evaluation de SQL Server. Para obtener más información acerca de las opciones del filtro de mapas de bits, vea Optimizar el rendimiento de las consultas del almacén de datos a través del filtrado de mapas de bits. Para obtener más información sobre cómo interpretar planes de consulta que contienen filtros de mapas de bits, vea Interpretar planes de ejecución que contienen filtros de mapas de bits. Para obtener más información sobre la optimización de la combinación en estrella, vea el artículo de TechNet Magazine "Rendimiento de consultas de almacén de datos".

SQL Server 2008 facilita el paralelismo de las combinaciones de bucle anidado cuando el lado externo de la combinación tiene solamente algunas filas. En SQL Server 2005, si hay varios subprocesos disponibles, a cada uno se le asigna una página de filas del lado externo de la combinación. Si hay únicamente algunas filas, es probable que estén en la misma página. En casos como este, se emplea solo un subproceso y los posibles beneficios del paralelismo se pierden. SQL Server 2008 reconoce tales casos e introduce a un operador de intercambio que asigna una fila por cada subproceso para que se empleen todas las CPU disponibles. Un mayor paralelismo significa que el consumo de CPU aumentará temporalmente en comparación con SQL Server 2005, pero la ejecución de las consultas será más rápida. Este nuevo comportamiento solo se aprecia si el número de filas externas es pequeño y si se prevé que el costo de la consulta sea lo suficientemente grande como para beneficiarse del paralelismo adicional. Si se calcula que el costo de la consulta es pequeño o si la estimación de la cardinalidad del lado externo es mayor que 1000, SQL Server asignará una página por cada subproceso como en SQL Server 2005. Para obtener más información sobre los operadores de intercambio y el procesamiento de consultas en paralelo, vea Procesar una consulta en paralelo.

En SQL Server 2008 se cambia la manera en que se procesan las consultas en tablas e índices con particiones. Las consultas en objetos con particiones que usan la sugerencia USE PLAN podrían contener un plan no válido. Recomendamos que siga estos procedimientos después de actualizar a SQL Server 2008.

Cuando la sugerencia USE PLAN se especifica en una consulta directamente:

1. Quite la sugerencia USE PLAN de la consulta.

2. Pruebe la consulta.

3. Si el optimizador no selecciona un plan adecuado, ajuste la consulta y, a continuación, especifique la sugerencia USE PLAN con el plan de consulta deseado.

Cuando la sugerencia USE PLAN se especifica en una guía de plan:

1. Utilice la función sys.fn_validate_plan_guide para comprobar la validez de la guía de plan. También puede comprobar si hay planes no válidos mediante el evento Plan Guide Unsuccessful de SQL Server Profiler.

2. Si la guía de plan no es válida, quítela. Si el optimizador no selecciona un plan adecuado, ajuste la consulta y, a continuación, especifique la sugerencia USE PLAN con el plan de consulta deseado.

Para obtener más información sobre el procesamiento de consultas en objetos con particiones, vea Mejoras de procesamiento de consultas en las tablas e índices con particiones.

En SQL Server 2005, los archivos de datos y de registro para la base de datos Resource dependen de la ubicación del archivo de datos de la base de datos master. Por consiguiente, mover la base de datos master también requiere mover la base de datos Resource a la misma ubicación. Esta dependencia no existe en SQL Server 2008. Los archivos de la base de datos master se pueden mover sin mover la base de datos Resource.

En SQL Server 2008, la ubicación predeterminada de la base de datos Resource es <unidad>:\Archivos de programa\Microsoft SQL Server\MSSQL10.<nombreDeInstancia>\Binn\. La base de datos Resource no se puede mover.

En versiones anteriores de SQL Server, la opción de base de datos PAGE_VERIFY está establecida en NONE para la base de datos tempdb y no se puede modificar. En SQL Server 2008, el valor predeterminado para la base de datos tempdb es CHECKSUM para las nuevas instalaciones de SQL Server. Al actualizar una instalación de SQL Server, el valor predeterminado sigue siendo NONE. La opción se puede modificar. Se recomienda usar CHECKSUM para la base de datos tempdb.

SQL Server 2008 contiene varias extensiones de la compatibilidad con los esquemas XML, como son la compatibilidad con la validación lax, el tratamiento mejorado de los datos de instancia xs:date, xs:time y xs:dateTime, y una mayor compatibilidad con los tipos list y union. En la mayoría de los casos, los cambios no afectan a la experiencia de actualización. Sin embargo, si usa una colección de esquemas XML en SQL Server 2005 que permita valores del tipo xs:date, xs:time o xs:dateTime (o cualquier subtipo), los pasos de actualización siguientes se producen al actualizar la base de datos de SQL Server 2005 a SQL Server 2008.

1. Para cada columna xml, con el tipo de colección de esquemas XML que contiene elementos o atributos escritos como xs:anyType, xs:anySimpleType, xs:date o cualquiera de sus subtipos, xs:time o cualquiera de sus subtipos, o xs:dateTime y cualquiera de sus subtipos, o son tipos union o list que contienen cualquiera de estos tipos, se produce lo siguiente:

   1. Se deshabilitan los índices XML de la columna.

   2. Todos los valores de SQL Server 2005 continúan representándose en la zona horaria Z porque se han normalizado a dicha zona horaria.

   3. Cualquier valor xs:date o xs:dateTime que sea menor que el 1 de enero del año 1 provocará un error en tiempo de ejecución cuando el índice se regenere o se ejecute una XQuery o instrucciones XML-DML frente al tipo de datos xml que contiene dicho valor.

2. Cualquier año negativo en las facetas xs:date o xs:dateTime o los valores predeterminados en una colección de esquemas XML se actualizan automáticamente al valor más pequeño permitido por el tipo base xs:dateTime o xs:date. Por ejemplo, 0001-01-01T00:00:00.0000000Z para xs:dateTime.

Observe que todavía puede usar una instrucción SELECT de SQL para recuperar todo el tipo de datos xml, aun cuando contenga años negativos. Se recomienda reemplazar los años negativos por un año dentro del intervalo recientemente admitido o cambiar el tipo del elemento o atributo a xs:string. Para obtener más información, vea Comparación de XML con tipo y XML sin tipo.

En SQL Server 2005, la validación lax no se admite y se aplica la validación estricta para los elementos del tipo anyType. En SQL Server 2008, el contenido de los elementos de tipo anyType se valida utilizando la validación lax. Para obtener más información, vea Componentes comodín y validación del contenido.