Cambios de comportamiento en las características del Motor de base de datos en SQL Server 2008
En este tema se describen los cambios de comportamiento en el Database Engine (Motor de base de datos). Los cambios de comportamiento afectan a cómo trabajan o interactúan las características en SQL Server 2008 en comparación con versiones anteriores de SQL Server.
Agente SQL Server
Cambios de comportamiento en las operaciones de scripting de una tarea del Agente SQL Server.
En SQL Server 2008, si crea un nuevo trabajo copiando el script de un trabajo existente, el nuevo trabajo puede afectar inadvertidamente al trabajo existente. Para crear un nuevo trabajo utilizando el script de un trabajo existente, elimine manualmente el parámetro @schedule\_uid, que suele ser el último parámetro de la sección que crea la programación del trabajo en el trabajo existente. De este modo se creará una nueva programación independiente para el nuevo trabajo sin afectar a los trabajos existentes.
Opciones de Access Check Cache
En SQL Server 2005, la estructura interna de access check result cache no se puede configurar salvo que se utilicen marcadores de seguimiento. En SQL Server 2008, puede utilizar las opciones de access check cache para modificar esta estructura. Para obtener más información, vea Opciones de acceso a la caché de comprobación.
Búsqueda de texto completo
La búsqueda de texto completo de SQL Server 2008 presenta una nueva arquitectura de búsqueda de texto completo. Ahora, el motor de búsqueda de texto completo está integrado totalmente en SQL Server Database Engine (Motor de base de datos de SQL Server), en lugar de ser un servicio independiente. La integración proporciona mejor capacidad de administración, escalabilidad, seguridad y rendimiento de la búsqueda de texto completo que en las versiones anteriores de SQL Server. Para obtener más información sobre las diferencias principales entre la búsqueda de texto completo en SQL Server 2005 y en SQL Server 2008, así como las prácticas recomendadas asociadas a este nuevo motor de búsqueda de texto completo integrado, vea el artículo técnico relativo a las mejoras y fundamentos de la búsqueda de texto completo de SQL Server 2008 de MSDN.
Servidores vinculados
SQL Server 2008 cambia la semántica de transacción de las instrucciones INSERT...EXECUTE que se ejecutan en un servidor vinculado de bucle invertido. En SQL Server 2005, no se admite este escenario y se produce un error. En SQL Server 2008, una instrucción INSERT... EXECUTE se puede ejecutar en un servidor vinculado de bucle invertido cuando la conexión no tiene habilitados conjuntos de resultados activos múltiples (MARS, Multiple Active Result Sets). Cuando MARS está habilitado en la conexión, el comportamiento es igual que en SQL Server 2005.
Paralelismo
Procesamiento de las consultas de tablas con particiones y paralelismo
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.
Combinación en estrella y paralelismo
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".
Paralelismo de pocas filas externas
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.
Consultas de tabla con particiones que utilizan la sugerencia USE PLAN
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:
Quite la sugerencia USE PLAN de la consulta.
Pruebe la consulta.
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:
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.
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.
Guías de plan
En SQL Server 2008, si no se puede respetar una guía de plan, la consulta se compila utilizando un plan diferente y no se devuelve ningún error. En SQL Server 2005, se produce un error y la consulta no se puede ejecutar.
Las guías de plan creadas en SQL Server 2005 pueden no ser válidas después de actualizar a SQL Server 2008. Las guías de plan no válidas no harán que la aplicación genere un error, pero la guía de plan no se utilizará. Se recomienda volver a evaluar y probar las definiciones de guías de plan al actualizar la aplicación a una nueva versión de SQL Server. Los requisitos de optimización del rendimiento y el comportamiento de la coincidencia de las guías de plan pueden cambiar. Después de actualizar una base de datos a SQL Server 2008, debería realizar las siguientes tareas para validar las guías de plan existentes utilizando la función sys.fn_validate_plan_guide. Otra opción es encontrar las guías de plan no válidas buscando el evento Plan Guide Unsuccessful en SQL Server Profiler.
Arquitectura del procesador de consultas
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 para un plan generado por SQL Server 2005 podrían contener un plan no válido. Para obtener más información, vea Consideraciones para actualizar el Motor de base de datos. 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.
Función REPLACE
En SQL Server 2005, los espacios finales especificados en el primer parámetro de entrada a la función REPLACE se recortan cuando el parámetro es del tipo char. Por ejemplo, en la instrucción SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', el valor 'ABC ' se evalúa incorrectamente como 'ABC'.
En SQL Server 2008, los espacios finales siempre se conservan. En las aplicaciones que se basan en el comportamiento anterior de la función, utilice la función RTRIM al especificar el primer parámetro de entrada para la función. Por ejemplo, la sintaxis siguiente reproducirá el comportamiento de SQL Server 2005 SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.
Bases de datos del sistema
Base de datos Resource
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.
Base de datos tempdb
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.
Usar INSERT…SELECT para realizar una carga masiva de datos con registro mínimo
En versiones anteriores de SQL Server, la carga masiva de filas en una tabla de destino usando la instrucción INSERT INTO <tablaDeOrigen> SELECT <columnas> FROM <tablaDeDestino> siempre es una operación que se registra por completo. En SQL Server 2008, esta operación se puede realizar con registro mínimo cuando la tabla de destino es un montón, el modelo de recuperación de la base de datos está establecido en simple o registrado de forma masiva, y la sugerencia TABLOCK está especificada en la tabla de destino. El registro mínimo puede mejorar el rendimiento de la instrucción y reducir la posibilidad de que la operación rellene el espacio del registro de transacciones disponible durante la transacción. Para obtener más información, vea INSERT (Transact-SQL).
XML
Actualizar XML con tipo de SQL Server 2005 a SQL Server 2008
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.
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:
Se deshabilitan los índices XML de la columna.
Todos los valores de SQL Server 2005 continúan representándose en la zona horaria Z porque se han normalizado a dicha zona horaria.
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.
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.
La validación lax y los elementos xs:anyType
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.
Vea también
Referencia
Otros recursos
Historial de cambios
Contenido actualizado |
|---|
Se han agregado las secciones "Opciones de Access Check Cache", "Búsqueda de texto completo", "Paralelismo" y "XML". |
Se ha agregado la sección "Usar INSERT… SELECT para realizar una carga masiva de datos con registro mínimo". |
Se ha agregado la sección "Cambios de comportamiento en las operaciones de scripting de una tarea del Agente SQL Server". |