Solucione el error de Analysis Services "ERROR OLE DB: OLE DB o ODBC error: Operación cancelada; HY008"

En este artículo se describe la información de solución de problemas en segundo plano y los pasos específicos para un error que puede producirse al usar SQL Server Analysis Services al procesar modelos multidimensionales.

Nota

Este artículo se deriva de un blog publicado el 11 de junio de 2012 y podría contener material de fecha.

Errores durante el procesamiento

Es posible que se produzca un error en el procesamiento de Analysis Services: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

En SQL términos OLE DB, HY008 significa DB_E_CANCELED, lo que sugiere que el autor de la llamada canceló la consulta intencionadamente. En ocasiones, puede ver este error mejor en SQL Server Management Studio:

Internal error: The operation terminated unsuccessfully.
OLE DB error: OLE DB or ODBC error: Query timeout expired;HYT00.
Errors in the OLAP storage engine: An error occurred while the dimension, with the ID of '<Some ID>', Name of '<Dimension Name>' was being processed.

HYT00 significa DB_E_ABORTLIMITREACHED (0x80040E31) o ha expirado un tiempo de espera. El tiempo de espera expiró debido a la configuración de SQL_QUERY_TIMEOUT. Se inició el tiempo de espera del comando o el tiempo de espera de consulta para terminar la consulta en ejecución y cancelar el trabajo.

Comandos y errores equivalentes de XMLA

Si usa comandos XMLA para procesar los objetos de Analysis Services, la sintaxis podría ser similar al ejemplo siguiente:

<Batch xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
    <Parallel>
        <Process xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300">
            <Object>
                <DatabaseID>AdventureWorksDW2012Multidimensional-EE</DatabaseID>
            </Object>
            <Type>ProcessFull</Type>
            <WriteBackTableCreation>UseExisting</WriteBackTableCreation>
        </Process>
    </Parallel>
</Batch>

Cuando se produce un tiempo de espera, el sistema muestra una lista de errores diferentes anexados en una cadena larga. Una o varias de las conexiones de base de datos tienen un tiempo de espera, pero es posible que no observe. Hay un ruido significativo en el error que las varias conexiones obtienen de una notificación de cancelación. Analysis Services notifica los errores en un orden aparentemente aleatorio debido a la naturaleza multiproceso de la implementación de procesamiento. El indicador de tiempo de espera es difícil de ver.

Internal error: The operation terminated unsuccessfully. Internal error: The operation terminated unsuccessfully. Server: The current operation was cancelled because another operation in the transaction failed. Internal error: The operation terminated unsuccessfully. OLE DB error: OLE DB or ODBC error: **Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.
; 08S01.** Errors in the OLAP storage engine: An error occurred while the dimension, with the ID of 'Dim Time', Name of 'Date' was being processed. Errors in the OLAP storage engine: An error occurred while the 'Fiscal Year' attribute of the 'Date' dimension from the 'AdventureWorksDW2012Multidimensional-EE' database was being processed. OLE DB error: OLE DB or ODBC error: Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.

Para comprender esta salida, 08S01 significa DB_E_CANNOTCONNECT del proveedor. Este HResult es un poco de mal nombre. Podría ser que el sistema no se puede conectar o que el proveedor o el servidor la han desconectado o cancelado si se canceló la consulta.

Compruebe el OLAP\Log\Msmdsrv.log archivo. Es posible que reciba el mensaje de error en caso de que la aplicación no la registre.

(6/12/2012 4:52:21 PM) Message:  (Source: [\\?\C:\OLAP\Log\msmdsrv.log](file://\\?\C:\OLAP\Log\msmdsrv.log), Type: 3, Category: 289, Event ID: 0xC1210003)
(6/12/2012 4:52:21 PM) Message: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008. (Source: [\\?\C:\OLAP\Log\msmdsrv.log](file://\\?\C:\OLAP\Log\msmdsrv.log), Type: 3, Category: 289, Event ID: 0xC1210003)
(6/12/2012 4:52:22 PM) Message: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008. (Source: [\\?\C:\OLAP\Log\msmdsrv.log](file://\\?\C:\OLAP\Log\msmdsrv.log), Type: 3, Category: 289, Event ID: 0xC1210003)
(6/12/2012 4:52:24 PM) Message: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008. (Source: [\\?\C:\OLAP\Log\msmdsrv.log](file://\\?\C:\OLAP\Log\msmdsrv.log), Type: 3, Category: 289, Event ID: 0xC1210003)
(6/12/2012 4:45:33 AM) Message: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008. (Source: [\\?\C:\OLAP\Log\msmdsrv.log](file://\\?\C:\OLAP\Log\msmdsrv.log), Type: 3, Category: 289, Event ID: 0xC1210003)

La salida del registro anterior indica que el proveedor OLE DB notificó un error, código hexadecimal 0xC1210003.

Intento de simplificar el error

Si no puede determinar qué objeto y atributo específicos están causando el problema, simplifique el paralelismo de procesamiento mediante la restricción del número de conexiones a la base de datos relacional.

En Explorador de soluciones, seleccione las propiedades del origen de datos. Ajuste el número máximo de conexiones de un valor de 10 a un valor de 1. La próxima vez que procese los objetos, cualquier error podría mostrar mejor los atributos del problema y una descripción de error más exacta.

Fondo en el procesamiento de cubos

Cuando Analysis Services procesa un cubo o un objeto de nivel inferior, como una dimensión o un grupo de medida, envía muchas consultas grandes SQL al motor de base de datos relacional a través de un proveedor OLE DB. Por ejemplo, SELECT * FROM DimTABLE1, SELECT * FROM FactTable1.

Estas consultas de procesamiento pueden tardar de minutos a horas en ejecutarse. El período de tiempo depende del número de combinaciones que hay y del tamaño de las tablas y particiones. El número de combinaciones depende completamente del diseño del cubo y de las relaciones de dimensión y grupo de medida en el diseño.

Para conectarse al origen de datos relacional, hay cadenas de conexión almacenadas en el diseño del cubo para que apunten al almacenamiento de datos en el servidor de bases de datos.

Se trata de una cadena de conexión que se guarda en el diseño de la base de datos de Analysis Services. Puede apuntar a SQL Server, o puede apuntar a otras bases de datos relacionales de terceros, como Teradata y Oracle. En la captura de pantalla siguiente, se muestra el proveedor OLE DB de SQL Server 2012 denominado SQLNCLI11.1.

Segundo plano en tiempos de espera de conexión y comandos

Cada vez que se emite un comando como una consulta de T-SQL en el caso de SQL Server al origen de datos, el llamador de Analysis Services establece la propiedad de tiempo de espera del comando.

En el ejemplo siguiente se muestra el pseudocódigo de ADO para mostrar cómo se establece un tiempo de espera de comando mediante el código que ejecuta Analysis Services internamente:

conn1.Open();
command = conn1.CreateCommand();
command.CommandText = "Select * from DimTable";
command.CommandTimeout = 15;

En el ejemplo anterior, si se pasan 15 segundos y la consulta aún no ha finalizado, el proveedor OLE DB cancela la consulta en nombre del autor de la llamada. El autor de la llamada no tiene que mantener ningún temporizador porque el tiempo de espera se establece en la capa del proveedor. Pero si se produce un error en la consulta, el autor de la llamada no sabe cuánto tiempo tardó y si se ha agotado el tiempo de espera o no.

En términos OLE DB, esta propiedad se denomina DBPROP_COMMANDTIMEOUT en el objeto DBPROPSET_ROWSET . Esta propiedad permite ejecutar consultas durante un período de tiempo determinado. Si el comando no finaliza, se cancela. En SQL Server, puede ver estos tiempos de espera con un evento Attention en el seguimiento del generador de perfiles. En ese seguimiento del generador de perfiles, la duración del evento coincide exactamente con la duración del tiempo de espera del comando.

El valor de tiempo de espera del comando no se establece en la conexión ni en la propia cadena de conexión. Debe establecerse después de establecer una conexión, ya que se usa cada objeto de comando. Hay un tiempo de espera de conexión similar en DBPROP_INIT_TIMEOUT el DBPROPSET_DBINIT objeto . En Analysis Services, el tiempo de espera de conexión es la propiedad independiente ExternalConnectionTimeout. Esta configuración es aplicable para establecer contacto inicial con el servidor y comprobar la autenticación y autorización de las cuentas. Esta configuración no afecta normalmente a las consultas de larga duración, ya que la conexión inicial se realizó correctamente sin errores.

Puede controlar el tiempo de espera del comando OLE DB en Analysis Services. Hay una configuración ExternalCommandTimeout en las opciones avanzadas de la instancia de Analysis Services. El valor predeterminado es 60 minutos (una hora).  Es posible que ese valor de tiempo de espera no sea lo suficientemente largo. Esta configuración predeterminada permite que cualquier consulta de T-SQL a la base de datos relacional dure una o varias horas. Después de ese punto, el proveedor OLE DB cancela el comando usado para conectarse a ese sistema y se produce un error en el comando de procesamiento de Analysis Services.

La propiedad integer ExternalCommandTimeout define el tiempo de espera, en segundos, para los comandos emitidos en servidores externos, que incluye orígenes de datos relacionales y servidores externos de Analysis Services. El valor predeterminado de esta propiedad es de 3600 segundos.

Si espera que las consultas de procesamiento tarden más de una hora, aumente el tiempo de espera superior a una hora. En un ejemplo, las consultas de combinación de procesamiento tardaron aproximadamente nueve horas en completarse en una base de datos de 2 TB con algunas combinaciones complejas de gran tamaño.

Haga clic con el botón derecho en el nombre del servidor en Management Studio>Propiedades. Active la casilla Mostrar propiedades avanzadas (todos). A continuación, ajuste la configuración ExternalCommandTimeout , como se muestra en las imágenes siguientes:

Ahora, cuando el servidor ejecuta consultas externas para comunicarse con la base de datos relacional, establece el tiempo de espera del comando en el valor especificado para que pueda ejecutarse mucho tiempo sin errores.

La duración larga del procesamiento puede dar lugar a tiempos de espera

Si el procesamiento de consultas tarda más de una hora, puede haber maneras de ajustar el sistema para que funcione más rápido:

• Ajuste las combinaciones que Realiza Analysis Services cuando ejecuta todas las consultas de procesamiento en segundo plano en su nombre.
• Particione los grupos de medida para que la unidad de trabajo realizada mediante el procesamiento sea un fragmento más pequeño de datos en lugar de todos los datos a la vez. La creación de particiones requiere un pensamiento cuidadoso y un trabajo de diseño de cubo. Si los datos tienen más de 20 millones de filas en una tabla y ve problemas de rendimiento de procesamiento, considere la posibilidad de crear particiones.

Ajuste del sistema de bases de datos relacionales

Después de ejecutar el procesamiento de cubos una o dos veces, busque los índices que faltan en la base de datos relacional o en el sistema de almacenamiento de datos. Dedique unos minutos a optimizar la base de datos. Agregue algunos índices a las tablas de almacenamiento de datos relacionales para ayudar a ajustar los criterios de combinación para procesar el cubo.

El siguiente código de T-SQL se toma prestado de la herramienta de soporte técnico PSSDiag. Identifica los índices que faltan más útiles y funciona en SQL Server 2005 y versiones posteriores. Busque los índices en las tablas de hechos y dimensiones que ayudan a mejorar el rendimiento más. Recuerde que, al agregar un índice, puede ayudar a leer el rendimiento, como el procesamiento de cubos, puede ralentizar algún rendimiento de inserción y actualización, como las actividades de extracción, transformación y carga (ETL).

PRINT 'Missing Indexes: ' PRINT 'The "improvement_measure" column is an indicator of the (estimated) improvement that might ' PRINT 'be seen if the index was created. This is a unitless number, and has meaning only relative ' PRINT 'the same number for other indexes. The measure is a combination of the avg_total_user_cost, ' PRINT 'avg_user_impact, user_seeks, and user_scans columns in sys.dm_db_missing_index_group_stats.' PRINT '' PRINT '-- Missing Indexes --' SELECT CONVERT (varchar, getdate(), 126) AS runtime, mig.index_group_handle, mid.index_handle, CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) AS improvement_measure, 'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' (' + ISNULL (mid.equality_columns,'') + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '') + ')' + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, migs.*, mid.database_id, mid.[object_id] FROM sys.dm_db_missing_index_groups mig INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle WHERE CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) > 10 ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC PRINT '' GO

Impacto de la competencia de memoria en los tiempos de espera

Hay varias razones por las que pueden producirse tiempos de espera y muchos incluyen escenarios de no tiempo de espera. La segunda causa más común de una cancelación de consultas de T-SQL de procesamiento es errores de memoria insuficiente.

Puede haber competencia por la memoria entre SQL Server Motor de base de datos (SQLServr.exe), Analysis Services (MsMdsrv.exe), paquetes de Integration Services (DTExec.exe o ISServerExec.exe) y Reporting Services que se ejecutan en el mismo equipo. Es posible que tenga que limitar los demás servicios o equilibrar las asignaciones de memoria. El ajuste más común es limitar la configuración de memoria del servidor SQL Server máxima.

El procesamiento de cubos es como el tiempo de procesamiento más intensivo para un SQL Server que se usa como almacenamiento de datos, ya que Analysis Services inserta varias consultas grandes con combinaciones complejas al motor de base de datos relacional SQL al mismo tiempo.

exec sp_configure 'show advanced',1;
reconfigure;
exec sp_configure 'min server memory';
exec sp_configure 'max server memory';
-- look at config_value in the results for the current MB setting configured

Los procesos ETL que normalmente se ejecutan rara vez se benefician del almacenamiento en búfer normal del grupo de búferes del motor de base de datos de SQL Server. Considere SQL Server paquetes de Integration Services (SSIS) que importan grandes conjuntos de datos de un sistema transaccional en un sistema de almacenamiento de datos. Las operaciones de ETL suelen usar comandos BULK INSERT que no requieren mucho datos intermedios en la memoria.

Otras operaciones de ETL durante la fase ETL de la creación de un almacenamiento de datos se benefician del grupo de búferes grande de SQL. Las partes read (SELECT) y UPDATE y JOIN del procesamiento de ETL, como búsquedas y actualizaciones de dimensiones que cambian lentamente, usan datos intermedios almacenados en caché en la memoria, si están disponibles. Reducir la memoria del SQL Server Motor de base de datos podría tener un efecto secundario en esas partes de las importaciones de ETL que normalmente pasan justo antes del procesamiento del cubo.

Leer datos de RAM es de 1000 a 1 millones de veces más rápido que leer desde la unidad de disco giratoria promedio, por lo que reducir el grupo de búferes de SQL significa más lecturas de disco. A menos que tenga discos de estado sólido (SSD) de gama alta o una SAN de gama alta, es posible que espere un poco más.

Medición del consumo de memoria en el sistema

Si la memoria es la culpable, recopile un seguimiento del generador de perfiles y estos contadores de rendimiento para investigar mejor la causa:

1. Configure el Windows Monitor de rendimiento para generar un seguimiento del consumo de recursos. Seleccione StartRunPerfmon>>.

2. Haga clic con el botón derecho en el icono Registros de contadores del árbol en Registros de rendimiento y comience un nuevo registro de contadores. Asigne un nombre al registro.

3. Agregue el contador para los objetos siguientes: todos los contadores de cada objeto y todas las instancias de cada objeto.

   • Memoria
   • MSAS* --- todos los objetos (para una instancia predeterminada de Analysis Services)
   • MSOLAP$InstanceName* --- todos los objetos (para una instancia con nombre de Analysis Services)
   • MSSQL* --- todos los objetos (para el SQL Server Motor de base de datos)
   • Archivo de paginación
   • Proceso
   • Procesador
   • Sistema
   • Thread

4. Muestra cada 15 segundos.

5. En la pestaña Registro , especifique la estrategia de directorio y nombre de archivo como un archivo binario.

6. Para obtener el Monitor de rendimiento para pasar a un nuevo archivo una vez al día, en la pestaña Programación, seleccione:

   • Detener registro después de:1 día
   • Cuando se cierra el archivo de registro:Iniciar un nuevo archivo de registro

Revisión de los resultados de la Monitor de rendimiento

1. Examine el contador del motor de SQL Server para ver si SQL memoria del servidor MemoryTotal> estaba aumentando fuera del control.

2. Examine el contador MBytes MemoryAvailable> para ver cuánta memoria libre estaba disponible para los procesos que se ejecutan en Windows.

3. Examine ProcessPrivate> Bytes para los distintos procesos ejecutables para ver cuánto toma cada uno en comparación.

4. Examine los contadores MSAS y MSOLAP . Si la cantidad de uso supera la cantidad de KB elevada , Analysis Services tiene que recortar algunos de los búferes en memoria.

   • KB de uso de memoria
   • KB de límite alto de memoria
   • KB de límite bajo de memoria
   • KB de límite físico de memoria

   Si la cantidad de KB de uso de memoria supera el límite de KB duro , Analysis Services podría cancelar todo el trabajo actual y entrar en modo de pánico para eliminar los consumidores de memoria. El modo de pánico puede manifestarse en errores similares, pero normalmente el error es más descriptivo, como The Operation Has been Cancelled o The session was canceled because it exceeded a timeout setting (session orphaned timeout or session idle timeout) or it exceeded the session memory limit.

Impacto en el procesamiento paralelo en los tiempos de espera

Los comandos de procesamiento de Analysis Services se pueden ejecutar en paralelo o secuencialmente. En la sintaxis del comando de procesamiento, compruebe si especifica que se ejecute en orden secuencial o se ejecute en paralelo. Compruebe el paquete SSIS o el trabajo XMLA que ejecuta el procesamiento.

Esta imagen muestra la configuración de una tarea de procesamiento de SSIS Analysis Services:

En este ejemplo se muestra un comando XMLA que ejecuta hasta ocho tareas en paralelo:

<Batch xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Parallel MaxParallel="8">
    <Process xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300">
      <Object>
        <DatabaseID>AdventureWorksDW2012Multidimensional-EE</DatabaseID>
      </Object>
      <Type>ProcessFull</Type>
      <WriteBackTableCreation>UseExisting</WriteBackTableCreation>
    </Process>
  </Parallel>
</Batch>

Si el sistema está agotando el tiempo de espera, es posible que tenga que reducir horizontalmente el número de tareas paralelas, especialmente cuando invalide manualmente la configuración predeterminada, Deje que el servidor decida.

Es posible que pueda limitar mejor el sistema al reducir la configuración de MaxThreads en un 50 % y volver a procesar los objetos para que se ejecuten menos subprocesos a la vez.

En el peor de los casos, ejecute el procesamiento en modo secuencial para ver si los errores desaparece. El sistema tarda menos memoria en ejecutar una secuencia de una tarea a la vez en lugar de muchas tareas a la vez. El equilibrio puede ser que se ejecute más tiempo porque no se puede insertar el hardware del sistema en los mismos límites de rendimiento.

Para más información sobre los procedimientos recomendados de procesamiento, consulte SQL Server procedimientos recomendados.

Para obtener más información sobre la arquitectura del procesamiento de cubos, vea Arquitectura de procesamiento de Analysis Services 2005.

Impacto en la memoria de agregación en los tiempos de espera

Hay una configuración avanzada de AggregationMemoryLimitMax. Para más información, consulte esta entrada de blog.

SQL Server Analysis Services usa la cuota de memoria para controlar el número de trabajos simultáneos. Cada trabajo calcula la cantidad de memoria que necesita para finalizar el trabajo y solicita la cuota de memoria en función de su estimación. El trabajo continúa solo cuando se concede la cuota de memoria. Calculamos la cuota de un trabajo de agregación. Las opciones de configuración que controlan las estimaciones de uso de memoria son AggregationMemoryLimitMin y AggregationMemoryLimitMax.

Para lograr más paralelismo para el procesamiento, ajuste la configuración.

Configuración de tiempo de espera adicional

Tiempo de espera de consulta es otra opción en el origen de datos. Esta configuración parece no aplicarse fácilmente al procesamiento. Esta configuración se aplica al grupo de conexiones y ayuda a expirar las conexiones inactivas que ya no son necesarias. Esta configuración no se aplica a los comandos que se ejecutan durante el procesamiento o los comandos ROLAP.

Hay muchos otros tiempos de espera en Analysis Services, como:

• ForceCommitTimeout para procesar consultas de usuario si las consultas MDX contienen bloqueos que bloquean el procesamiento de confirmaciones.
• CommitTimeout para que el procesamiento se elimine si se bloquea en la fase de confirmación.
• ServerTimeout para que las consultas agoten el tiempo de espera después de algún tiempo.
• Configuración del grupo de conexiones, como IdleConnectionTimeout, IdleOrphanSessionTimeout, MaxIdleSessionTimeout, MinIdleSessionTimeout y DatabaseConnectionPoolConnectTimeout, y las que hemos analizado anteriormente, ExternalConnectionTimeout y ExternalCommandTimeout.

Caracteres especiales

En algunas situaciones, el error de tiempo de espera de procesamiento se debe a algunos caracteres especiales presentes en las columnas de una de las tablas de dimensiones. Incluso los valores NULL de una columna de dimensión pueden provocar errores de procesamiento.

Es posible que aísle mejor el problema procesando cada objeto de uno en uno hasta que encuentre el problema.

Por ejemplo, al procesar la tabla de dimensiones, produce el error. OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

Una vez que el usuario quitó los caracteres especiales, el procesamiento funcionó según lo previsto.

Aislar en una partición

Es posible que pueda aislar aún más el error en una partición específica. Si particionó el cubo, es posible que haya una consulta con un rendimiento deficiente en una de las particiones.

Experimente con la consulta de partición. Cambie de una tabla de consulta con nombre directa en la vista Origen de datos a una consulta de SQL subyacente en su lugar.