Optimizar las consultas distribuidas
Para mejorar el rendimiento, SQL Server 2005 realiza los siguientes tipos de optimización específicos de las consultas distribuidas:
- Ejecución de consultas remotas utilizada con proveedores de comandos SQL de OLE DB.
Se considera que un proveedor OLE DB es un proveedor de comandos SQL si cumple los siguientes requisitos mínimos:- Admite el objeto Command y todas sus interfaces obligatorias.
- Admite la sintaxis DBPROPVAL SQL SUBMINIMUM o SQL-92 de nivel de entrada o superior, u ODBC de nivel de núcleo o superior. El proveedor debe proporcionar este nivel de lenguaje mediante la propiedad DBPROP_SQLSUPPORT de OLE DB.
- Acceso indizado utilizado con proveedores de índices de OLE DB.
Se considera que un proveedor OLE DB es un proveedor de índices si cumple los siguientes requisitos mínimos:- Admite la interfaz IDBSchemaRowset con los conjuntos de filas de esquema TABLES, COLUMNS e INDEXES.
- Admite la apertura de un conjunto de filas en un índice con IOpenRowset, especificando el nombre del índice y el nombre de la tabla base correspondiente.
- El objeto Index debe admitir todas sus interfaces obligatorias: IRowset, IRowsetIndex, IAccessor, IColumnsInfo, IRowsetInfo y IConvertTypes.
- Los conjuntos de filas abiertos con la tabla base indizada (mediante IOpenRowset) deben admitir la interfaz IRowsetLocate para colocarse en una fila basada fuera de un marcador recuperado a partir del índice.
Ejecución de consultas remotas
SQL Server intenta delegar la mayor parte posible de la evaluación de una consulta distribuida en el proveedor de comandos SQL. De la consulta distribuida original se extrae una consulta SQL que sólo tiene acceso a las tablas remotas almacenadas en el origen de datos del proveedor; esta consulta se ejecuta con el proveedor. Este comportamiento reduce el número de filas devueltas desde el proveedor y permite a éste utilizar sus índices para evaluar la consulta.
La parte de la consulta distribuida original que se delega en el proveedor de comandos SQL se ve afectada por:
- El nivel de lenguaje que admite el proveedor de comandos SQL
- La compatibilidad de intercalación
Nivel de lenguaje admitido por el proveedor de comandos SQL
SQL Server sólo delega las operaciones si el nivel de lenguaje específico las admite. Los niveles de lenguaje son, de mayor a menor, SQL Server, nivel de entrada de SQL-92, núcleo de ODBC y Jet. Cuanto mayor sea el nivel de lenguaje, más operaciones podrá delegar SQL Server en el proveedor.
[!NOTA] El nivel de lenguaje SQL Server se utiliza cuando el proveedor corresponde a un servidor vinculado de SQL Server.
Cada nivel de lenguaje es un superconjunto de los niveles inferiores. Por tanto, si se delega una operación en un nivel particular, también se delega en todos los niveles superiores.
Las consultas que utilizan los tipos de datos bit y uniqueidentifer nunca se delegan en un proveedor y, por tanto, siempre se evalúan de forma local:
Cuando la opción de SET CONCAT_NULL_YIELDS_NULL es OFF, la concatenación de cadenas siempre es local.
Las siguientes operaciones y elementos sintácticos se delegan en el nivel de lenguaje indicado (y en todos los niveles superiores):
- SQL Server: combinación externa, CUBE, ROLLUP, operador de módulo (%), operadores bit a bit, funciones de cadena y funciones aritméticas del sistema.
- Nivel de entrada de SQL-92: UNION y UNION ALL.
- Núcleo de ODBC: funciones de agregación con DISTINCT y constantes de cadena.
- Jet: funciones de agregado sin DISTINCT, ordenación (ORDER BY), combinaciones internas, predicados, operadores de subconsultas (EXISTS, ALL, SOME, IN), DISTINCT, operadores aritméticos no mencionados en niveles superiores, constantes no mencionadas en niveles superiores y todos los operadores lógicos.
Por ejemplo, todas las operaciones, excepto las que utilizan CUBE, ROLLUP, combinaciones externas, operadores de módulo (%), operadores bit a bit, funciones de cadena y funciones aritméticas del sistema, se delegan en un proveedor de nivel de entrada de SQL-92 que no sea también SQL Server.
Compatibilidad de intercalación
En el caso de una consulta distribuida, la semántica de comparación de todos los datos de caracteres se define mediante el juego de caracteres y el criterio de ordenación de la instancia local de SQL Server. SQL Server 2005 admite varias intercalaciones. Las intercalaciones pueden ser diferentes para cada columna, y cada valor de carácter tiene una propiedad de intercalación asociada. SQL Server interpreta la propiedad de intercalación de los datos de caracteres de un origen de datos remoto y la trata del modo correspondiente. Para obtener más información sobre la intercalación de columnas remotas, vea Intercalaciones en las consultas distribuidas.
SQL Server sólo puede delegar en un proveedor las comparaciones y operaciones ORDER BY en columnas de caracteres si puede determinar lo siguiente:
- El origen de datos subyacente utiliza la secuencia de intercalación y el juego de caracteres de la columna.
- La semántica de comparación de caracteres cumple el estándar de SQL-92 y SQL Server.
En el tema Intercalaciones en las consultas distribuidas se resume la forma en que SQL Server determina una intercalación para cada columna. Si el origen de datos remoto admite esa intercalación, se considerará que el proveedor es compatible con la intercalación.
Otras consideraciones sobre la compatibilidad con SQL
Los siguientes elementos de sintaxis de SQL no vienen condicionados por los niveles de lenguaje de SQL:
- Compatibilidad con consultas anidadas
Si el proveedor admite consultas anidadas (subconsultas), SQL Server puede delegar estas operaciones en el proveedor. Debido a que la compatibilidad con consultas anidadas no se puede determinar automáticamente a partir de propiedades de OLE DB, el administrador del sistema debe establecer la opción del proveedor NestedQueries para indicar a SQL Server que el proveedor admite consultas anidadas. - Compatibilidad con marcadores de parámetros
Si el proveedor admite la ejecución de consultas con parámetros mediante la utilización del marcador de parámetros ? en una consulta, SQL Server puede delegar la ejecución de consultas con parámetros en el proveedor. Debido a que la compatibilidad con marcadores de parámetros no se puede determinar automáticamente a partir de propiedades de OLE DB, el administrador del sistema debe establecer la opción del proveedor DynamicParameters para indicar a SQL Server que el proveedor admite marcadores de parámetros. - Compatibilidad con LIKE
Si el proveedor admite el operador LIKE tal y como se implementa en la sintaxis y semántica de SQL Server, se puede establecer la opción del proveedor SqlServerLike para indicar la compatibilidad.
Para obtener más información sobre cómo establecer estas opciones del proveedor, vea Configurar proveedores OLE DB para consultas distribuidas.
Acceso indizado
SQL Server puede utilizar estrategias de ejecución que incluyan el uso de índices del proveedor de índices para evaluar predicados y realizar operaciones de ordenación con tablas remotas. Para habilitar el acceso indizado en un proveedor, establezca la opción del proveedor IndexAsAccessPath.
Adicionalmente, cuando se utilicen índices con columnas de caracteres, establezca la opción de configuración del servidor vinculado collation compatible en true para el servidor vinculado correspondiente. Para obtener más información, vea sp_serveroption (Transact-SQL).
[!NOTA] Muestre gráficamente el plan de ejecución con el SQL Server Management Studio para determinar el plan de ejecución de una consulta distribuida determinada. Cuando se emplea la ejecución de consultas remotas en el plan de ejecución, se representa con el operador lógico y físico Remote Query. El argumento de este operador muestra la consulta ejecutada de forma remota.
Vea también
Conceptos
Consultas distribuidas
Aspectos básicos de las subconsultas