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

Artículo
05/08/2013

En este tema se describen los cambios de comportamiento en Motor de base de datos. Los cambios de comportamiento afectan al modo en que las características de SQL Server 2012 funcionan o interactúan en comparación con las versiones anteriores de SQL Server.

Detección de metadatos

Las mejoras de Motor de base de datos a partir de SQL Server 2012 permiten a SQLDescribeCol obtener descripciones más precisas de los resultados esperados que los devueltos por SQLDescribeCol en las versiones anteriores de SQL Server. Para obtener más información, vea Detección de metadatos.

La opción SET FMTONLY para determinar el formato de una respuesta sin ejecutar realmente la consulta se reemplaza con sp_describe_first_result_set (Transact-SQL), sp_describe_undeclared_parameters (Transact-SQL), sys.dm_exec_describe_first_result_set (Transact-SQL) y sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Cambios de comportamiento de scripting en una tarea del Agente SQL Server

En SQL Server 2012, si crea un nuevo trabajo copiando el script desde un trabajo existente, el nuevo trabajo puede afectar inadvertidamente al trabajo existente. Para crear un nuevo trabajo con el script a partir 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 esta forma se crea una nueva programación independiente del nuevo trabajo sin que se vean afectados los trabajos existentes.

Doblado constante para las funciones y métodos CLR definidos por el usuario

En SQL Server 2012, los objetos definidos por el usuario para CLR pueden doblarse ahora:

Funciones CLR definidas por el usuario con valores escalares deterministas.
Métodos deterministas de tipos CLR definidos por el usuario.

Esta mejora trata de aumentar el rendimiento cuando estas funciones o métodos se llaman más de una vez con los mismos argumentos. Sin embargo, este cambio puede producir resultados inesperados cuando las funciones o métodos no deterministas se han marcado como deterministas por error. El determinismo de una función o método CLR viene indicado por el valor de la propiedad IsDeterministic de SqlFunctionAttribute o SqlMethodAttribute.

El comportamiento del método STEnvelope() ha cambiado con tipos espaciales vacíos

El comportamiento del método STEnvelope con objetos vacíos es ahora coherente con el comportamiento de otros métodos espaciales de SQL Server .

En SQL Server 2008, el método STEnvelope devuelve los siguientes resultados cuando se llama con objetos vacíos:

select geometry::Parse('POINT EMPTY').STEnvelope().ToString()
-- returns POINT EMPTY
select geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()
-- returns LINESTRING EMPTY
select geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()
-- returns POLYGON EMPTY

En SQL Server 2012, el método STEnvelope devuelve ahora los siguientes resultados cuando se llama con objetos vacíos:

select geometry::Parse('POINT EMPTY').STEnvelope().ToString()
-- returns GEOMETRYCOLLECTION EMPTY
select geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()
-- returns GEOMETRYCOLLECTION EMPTY
select geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()
-- returns GEOMETRYCOLLECTION EMPTY

Para determinar si un objeto espacial está vacío, llame al método STIsEmpty (tipo de datos geometry).

La función LOG tiene un nuevo parámetro opcional

La función LOG tiene ahora un parámetro base opcional. Para obtener más información, vea LOG (Transact-SQL).

El cálculo de estadísticas durante las operaciones de índice con particiones ha cambiado

En SQL Server 2012, las estadísticas no se crean mediante el examen de todas las filas de la tabla cuando se crea o se vuelve a compilar un índice con particiones. En su lugar, el optimizador de consultas usa el algoritmo de muestreo predeterminado para generar estadísticas. Después de actualizar una base de datos con índices con particiones, puede observar una diferencia en los datos del histograma para estos índices. Este cambio de comportamiento puede no afectar al rendimiento de las consultas. Para obtener estadísticas sobre índices con particiones mediante el examen de todas las filas de la tabla, use CREATE STATISTICS o UPDATE STATISTICS con la cláusula FULLSCAN.

La conversión de tipo de datos del método value de XML ha cambiado

El comportamiento interno del método value del tipo de datos xml ha cambiado. Este método realiza una consulta XQuery en XML y devuelve un valor escalar del tipo de datos especificado de SQL Server . El tipo xs se tiene que convertir al tipo de datos de SQL Server. Anteriormente, el método value convertía internamente el valor de origen una xs:string y, a continuación, convertía la xs:string al tipo de datos de SQL Server. En SQL Server 2012, la conversión a xs:string se omite en los casos siguientes:

Tipo de datos XS de origen	Tipo de datos de SQL Server de destino
byte short int integer long unsignedByte unsignedShort unsignedInt unsignedLong positiveInteger nonPositiveInteger negativeInteger nonNegativeInteger	tinyint smallint int bigint decimal numeric
decimal	decimal numeric
float	real
double	float

El nuevo comportamiento mejora el rendimiento cuando la conversión intermedia puede omitirse. Sin embargo, cuando se producen errores en las conversiones de tipo de datos, aparecerán mensajes de error distintos de los que se generaban al convertir del valor xs:string intermedio. Por ejemplo, si el método value no podía convertir el valor int 100000 a smallint, el mensaje de error anterior era:

The conversion of the nvarchar value '100000' overflowed an INT2 column. Use a larger integer column.

En SQL Server 2012, sin la conversión intermedia a xs:string, el mensaje de error es:

Arithmetic overflow error converting expression to data type smallint.

Cambio de comportamiento de sqlcmd.exe en modo XML

Hay cambios de comportamiento si usa sqlcmd.exe con el modo XML (comando :XML ON) al ejecutar SELECT * desde T FOR XML… Para obtener más información, vea Mejoras de la capacidad de administración (motor de base de datos).

Mensaje revisado de CHECKIDENT DBCC

En SQL Server 2012, el mensaje devuelto por el comando DBCC CHECKIDENT cambia solo cuando se usa con RESEED new_reseed_value para cambiar el valor de identidad actual. El nuevo mensaje es "Comprobación de información de identidad: valor de identidad actual '<valor de identidad actual>'. Ejecución de DBCC completada. Si DBCC imprime algún mensaje de error, póngase en contacto con su administrador del sistema."

En versiones anteriores, el mensaje es "Comprobación de información de identidad: valor de identidad actual '<valor de identidad actual>', valor de columna actual '<valor de columna actual>'. Ejecución de DBCC completada. Si DBCC imprime algún mensaje de error, póngase en contacto con su administrador del sistema." El mensaje no se modifica cuando DBCC CHECKIDENT se especifica con NORESEED, sin un segundo parámetro o sin un valor de reinicialización. Para obtener más información, vea DBCC CHECKIDENT (Transact-SQL).

El comportamiento de la función exist() del tipo de datos XML ha cambiado

El comportamiento de la función exist() ha cambiado al comparar un tipo de datos XML con un valor NULL en 0 (cero). Considere el ejemplo siguiente:

DECLARE @test XML;
SET @test = null;
SELECT COUNT(1) WHERE @test.exist('/dogs') = 0;

En versiones anteriores, esta comparación devolvía 1 (true); ahora, esta comparación devuelve 0 (cero, false).

Las comparaciones siguientes no han cambiado:

DECLARE @test XML;
SET @test = null;
SELECT COUNT(1) WHERE @test.exist('/dogs') = 1; -- 0 expected, 0 returned
SELECT COUNT(1) WHERE @test.exist('/dogs') IS NULL; -- 1 expected, 1 returned