Solucionar problemas do erro do Analysis Services "Erro OLE DB: erro OLE DB ou ODBC: Operação cancelada; HY008"

Este artigo descreve informações de solução de problemas em segundo plano e etapas específicas para um erro que pode ocorrer quando você usa SQL Server Analysis Services ao processar modelos multidimensionais.

Observação

Este artigo é derivado de um blog publicado em 11 de junho de 2012 e pode conter material datado.

Erros durante o processamento

O processamento do Analysis Services pode falhar com este erro: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

Em SQL termos OLE DB, HY008 significa DB_E_CANCELED, o que sugere que a consulta foi cancelada propositalmente pelo chamador. Às vezes, você pode ver esse erro melhor de 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) ou um tempo limite expirou. O tempo limite expirou devido à configuração de SQL_QUERY_TIMEOUT. O tempo limite do comando ou o tempo limite da consulta foi iniciado para eliminar a consulta em execução e cancelar o trabalho.

Comando e erros equivalentes XMLA

Se você usar comandos XMLA para processar seus objetos do Analysis Services, a sintaxe poderá ser semelhante ao exemplo a seguir:

<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>

Quando ocorre um tempo limite, o sistema mostra uma lista de erros diferentes acrescentados em uma cadeia de caracteres longa. Uma ou várias conexões de banco de dados têm um tempo limite, mas talvez você não observe. Há um ruído significativo no erro que as várias conexões obtêm de uma notificação de cancelamento. O Analysis Services relata os erros em uma ordem aparentemente aleatória devido à natureza multi-threaded da implementação de processamento. O indicador de tempo limite é 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 entender essa saída, 08S01 significa DB_E_CANNOTCONNECT do provedor. Este HResult é um pouco errado. Pode ser que o sistema não possa se conectar ou que tenha sido desconectado ou cancelado pelo provedor ou pelo servidor se a consulta foi cancelada.

Verifique o OLAP\Log\Msmdsrv.log arquivo. Você pode receber a mensagem de erro caso seu aplicativo não a 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)

A saída de log anterior indica que o provedor OLE DB relatou um erro, código 0xC1210003hex .

Tentar simplificar o erro

Se você não conseguir determinar qual objeto e atributo específicos estão causando o problema, simplifique o paralelismo de processamento restringindo o número de conexões com o banco de dados relacional.

Em Gerenciador de Soluções, selecione suas propriedades da Fonte de Dados. Ajuste o número máximo de conexões de um valor de 10 para um valor de 1. Na próxima vez que você processar os objetos, qualquer falha poderá mostrar melhor os atributos de problema e uma descrição de erro mais exata.

Plano de fundo no processamento de cubo

Quando o Analysis Services processa um cubo ou um objeto de nível inferior, como uma dimensão ou um grupo de medidas, ele envia muitas consultas SQL grandes para o mecanismo de banco de dados relacional por meio de um provedor OLE DB. Por exemplo, SELECT * FROM DimTABLE1, SELECT * FROM FactTable1.

Essas consultas de processamento podem levar de minutos a horas para serem executadas. O período de tempo depende de quantas junções existem e quão grandes são as tabelas e partições. O número de junções depende inteiramente do design do cubo e das relações de dimensão e de grupo de medidas no design.

Para se conectar à fonte de dados relacional, há cadeias de conexão armazenadas no design do cubo para apontar para o data warehouse no servidor de banco de dados.

Essa é uma cadeia de conexão que é salva no design do banco de dados do Analysis Services. Ele pode apontar para SQL Server ou pode apontar para outros bancos de dados relacionais de terceiros, como Teradata e Oracle. Na captura de tela a seguir, a SQL Server provedor OLE DB de 2012 chamado SQLNCLI11.1 é mostrado.

Tempo limite de comando e conexão em segundo plano

Sempre que um comando como uma consulta T-SQL no caso de SQL Server for emitido para a fonte de dados, a propriedade de tempo limite de comando é definida pelo chamador do Analysis Services.

O exemplo a seguir mostra o pseudocódigo do ADO para mostrar como um tempo limite de comando é definido pelo código que executa o Analysis Services internamente:

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

No exemplo anterior, se 15 segundos passarem e a consulta ainda não tiver sido concluída, o provedor OLE DB cancelará a consulta em nome do chamador. O chamador não precisa manter nenhum temporizador porque o tempo limite está definido na camada do provedor. Mas se a consulta falhar, o chamador realmente não sabe quanto tempo levou e se foi um tempo limite ou não.

Em termos OLE DB, essa propriedade é chamada DBPROP_COMMANDTIMEOUT no objeto DBPROPSET_ROWSET . Essa propriedade permite que você execute consultas por um determinado período de tempo. Se o comando não for concluído, ele será cancelado. Em SQL Server, você pode ver esses tempos limite com um evento Attention no rastreamento do criador de perfil. Nesse rastreamento do criador de perfil, a duração do evento corresponde exatamente à duração do tempo limite do comando.

A configuração de tempo limite do comando não está definida na conexão ou na própria cadeia de conexão. Ele deve ser definido depois que uma conexão é estabelecida, pois cada objeto de comando é usado. Há um tempo limite de conexão semelhante no DBPROP_INIT_TIMEOUTDBPROPSET_DBINIT objeto. No Analysis Services, o tempo limite da conexão é a propriedade separada ExternalConnectionTimeout. Essa configuração é aplicável para fazer contato inicial com o servidor e verificar a autenticação e a autorização das contas. Essa configuração não afeta consultas de execução longa normalmente, pois a conexão inicial foi bem-sucedida sem falha.

Você pode controlar o tempo limite do comando OLE DB no Analysis Services. Há uma configuração ExternalCommandTimeout nas opções avançadas na instância do Analysis Services. O valor padrão é de 60 minutos (uma hora).  Esse valor de tempo limite pode não ser longo o suficiente. Essa configuração padrão permite que qualquer consulta T-SQL ao banco de dados relacional dure uma hora ou mais. Após esse ponto, o comando é cancelado pelo provedor OLE DB usado para se conectar a esse sistema, e o comando de processamento do Analysis Services falha.

A propriedade inteiro ExternalCommandTimeout define o tempo limite, em segundos, para comandos emitidos para servidores externos, que inclui fontes de dados relacionais e servidores externos do Analysis Services. O valor padrão dessa propriedade é de 3.600 segundos.

Se você espera que as consultas de processamento levem mais de uma hora, aumente o tempo limite em mais de uma hora. Em um exemplo, as consultas de junção de processamento levaram cerca de nove horas para serem concluídas em um banco de dados de 2 TB com algumas junções complexas grandes.

Clique com o botão direito do mouse no nome do servidor em Management Studio>Properties. Selecione a caixa de seleção Mostrar Propriedades Avançadas (Todas ). Em seguida, ajuste a configuração ExternalCommandTimeout , conforme mostrado nas seguintes imagens:

Agora, quando o servidor executa consultas externas para falar com o banco de dados relacional, ele define o tempo limite de comando para o valor especificado para que ele possa ser executado por muito tempo sem falha.

Duração de processamento longa pode levar a tempos limite

Se o processamento de consultas levar mais de uma hora, talvez haja maneiras de ajustar o sistema para executar mais rapidamente:

• Ajuste as junções que o Analysis Services faz quando executa todas essas consultas de processamento em segundo plano em seu nome.
• Particione seus grupos de medidas para que a unidade de trabalho feita pelo processamento seja uma parte menor dos dados em vez de todos os dados de uma só vez. O particionamento requer um pensamento cuidadoso e um trabalho de design de cubo. Se seus dados tiverem mais de 20 milhões de linhas em uma tabela e você vir problemas de desempenho de processamento, considere o particionamento.

Ajustar o sistema de banco de dados relacional

Depois de executar o processamento de cubo uma ou duas vezes, procure índices ausentes no banco de dados relacional ou no sistema de data warehouse. Leve alguns minutos para ajustar o banco de dados. Adicione alguns índices às tabelas relacionais do data warehouse para ajudar a ajustar os critérios de junção para processar o cubo.

O código T-SQL a seguir é emprestado da ferramenta de suporte PSSDiag. Ele identifica os índices ausentes mais úteis e funciona em SQL Server 2005 e posteriores. Localize os índices nas tabelas de fatos e dimensões que ajudam a melhorar mais o desempenho. Lembre-se de que, embora a adição de um índice possa ajudar a ler o desempenho, como o processamento de cubos, ele pode retardar alguma inserção e atualizar o desempenho, como atividades de ETL (extrair, transformar, carregar).

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 da competição de memória nos tempos limite

Há vários motivos para que os tempos limite possam ocorrer e muitos incluem cenários sem tempo limite. A segunda causa mais comum de um processamento de T-SQL cancelamento de consulta são falhas de memória insuficiente.

Pode haver competição pela memória entre SQL Server Mecanismo de Banco de Dados (SQLServr.exe), Analysis Services (MsMdsrv.exe), pacotes do Integration Services (DTExec.exe ou ISServerExec.exe) e Reporting Services em execução no mesmo computador. Talvez seja necessário restringir os outros serviços ou balancear as alocações de memória. O ajuste mais comum é limitar a configuração de memória máxima do servidor SQL Server.

O processamento de cubos é como o tempo de processamento mais intensivo para um SQL Server usado como data warehouse, pois o Analysis Services envia por push várias consultas grandes com junções complexas ao mecanismo de banco de dados relacional SQL ao mesmo tempo.

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

Os processos ETL que normalmente são executados raramente se beneficiam do buffer normal do pool de buffers do mecanismo de banco de dados SQL Server. Considere SQL Server pacotes do SSIS (Integration Services) que importam grandes conjuntos de dados de um sistema transacional para um sistema de data warehouse. As operações DE ETL geralmente usam comandos BULK INSERT que não exigem muitos dados quentes na memória.

Outras operações de ETL durante a fase ETL de criação de um data warehouse se beneficiam do grande pool de buffers do SQL. As partes de leitura (SELECT) e UPDATE e JOIN do processamento de ETL, como pesquisas e atualizações de dimensão de alteração lenta, usam dados quentes armazenados em cache na memória, se disponíveis. A redução da memória do SQL Server Mecanismo de Banco de Dados pode ter um efeito colateral sobre as partes das importações de ETL que geralmente acontecem pouco antes do processamento do cubo.

A leitura de dados da RAM é 1000-1 milhão de vezes mais rápida do que a leitura da unidade de disco giratório média, portanto, reduzir o pool de buffers SQL significa mais leituras de disco. A menos que você tenha SSDs (discos de estado sólido) de alto nível ou uma SAN de alto nível, você pode esperar um pouco mais.

Medir o consumo de memória no sistema

Se a memória for a culpada, colete um rastreamento do criador de perfil e esses contadores de desempenho para investigar melhor a causa:

1. Configure o Windows Monitor de Desempenho para produzir um rastreamento do consumo de recursos. Selecione StartRunPerfmon>>.

2. Clique com o botão direito do mouse no ícone Logs de Contador na árvore em Logs de Desempenho e inicie um novo log de contadores. Nomeie o log.

3. Adicione o contador para os seguintes objetos: todos os contadores para cada objeto e todas as instâncias para cada objeto.

   • Memória
   • MSAS* --- todos os objetos (para uma instância padrão do Analysis Services)
   • MSOLAP$InstanceName* --- todos os objetos (para uma instância nomeada do Analysis Services)
   • MSSQL* --- todos os objetos (para o SQL Server Mecanismo de Banco de Dados)
   • Arquivo de paginação
   • Processar
   • Processador
   • Sistema
   • Thread

4. Exemplo a cada 15 segundos.

5. Na guia Log , especifique a estratégia de diretório e nome de arquivo como um arquivo binário.

6. Para obter o Monitor de Desempenho para rolar para um novo arquivo uma vez por dia, na guia Agendar, selecione:

   • Interromper log após:1 dia
   • Quando o arquivo de log é fechado:Iniciar um novo arquivo de log

Examinar os resultados do Monitor de Desempenho

1. Examine o contador do mecanismo de SQL Server para ver se SQL Memória do Servidor MemoryTotal> estava aumentando fora de controle.

2. Examine o> contador MBytes disponível para ver a quantidade de memória gratuita disponível para os processos em execução no Windows.

3. Examine os Bytes doProcessPrivate> para obter os vários processos executáveis para ver quanto cada um leva em comparação.

4. Examine os contadores MSAS e MSOLAP . Se a quantidade de uso for acima da quantidade de KB Alta , o Analysis Services precisará cortar alguns dos buffers na memória.

   • KB de uso de memória
   • KB de Limite de Memória Alto
   • KB de Limite de Memória Baixo
   • KB de limite de memória física

   Se a quantidade de KB de Uso de Memória exceder o limite do Hard KB , o Analysis Services poderá cancelar todo o trabalho atual e entrar em modo de pânico para eliminar os consumidores de memória. O modo de pânico pode se manifestar em erros semelhantes, mas geralmente o erro é mais descritivo, como The Operation Has been Cancelled ou 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 do processamento paralelo nos tempos limite

Os comandos de processamento do Analysis Services podem ser executados em paralelo ou sequencialmente. Na sintaxe do comando de processamento, verifique se você está especificando para executar em ordem sequencial ou executar em paralelo. Verifique o pacote do SSIS ou o trabalho XMLA que executa o processamento.

Esta imagem mostra as configurações de uma tarefa de processamento do SSIS Analysis Services:

Este exemplo mostra um comando XMLA que executa até oito tarefas em 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>

Se o sistema estiver atingindo o tempo limite, talvez seja necessário reduzir o número de tarefas paralelas, especialmente quando você substituir manualmente a configuração padrão, deixe o servidor decidir.

Você pode ser capaz de limitar melhor o sistema reduzindo a configuração maxthreads em 50% e reprocessando os objetos para que menos threads sejam executados de uma só vez.

Na pior das hipóteses, execute o processamento no modo sequencial para ver se os erros desaparecem. O sistema usa menos memória para executar uma sequência de uma tarefa por vez, em vez de muitas tarefas ao mesmo tempo. A compensação pode ser que ele seja executado por mais tempo porque você não pode enviar o hardware do sistema para os mesmos limites de taxa de transferência.

Para saber mais sobre o processamento de práticas recomendadas, consulte SQL Server práticas recomendadas.

Para obter mais informações sobre a arquitetura do processamento de cubo, consulte a arquitetura de processamento do Analysis Services 2005.

Impacto na memória de agregação nos tempos limite

Há uma configuração avançada de AggregationMemoryLimitMax. Para obter mais informações, consulte esta postagem no blog

SQL Server Analysis Services usa a cota de memória para controlar o número de trabalhos simultâneos. Cada trabalho calcula a quantidade de memória necessária para concluir o trabalho e solicita a cota de memória com base em sua estimativa. O trabalho prossegue somente quando a cota de memória for concedida. Estimamos a cota para um trabalho de agregação. As configurações que controlam as estimativas de uso de memória são AggregationMemoryLimitMin e AggregationMemoryLimitMax.

Para obter mais paralelismo para processamento, ajuste as configurações.

Configurações de tempo limite adicionais

Tempo limite de consulta é outra configuração na fonte de dados. Essa configuração parece não se aplicar prontamente ao processamento. Essa configuração se aplica ao pool de conexões e ajuda a expirar conexões ociosas que não são mais necessárias. Essa configuração não se aplica aos comandos executados durante o processamento ou comandos ROLAP.

Há muitos outros tempos limite no Analysis Services, como:

• ForceCommitTimeout para processamento para matar consultas de usuário se as consultas MDX mantiverem bloqueios que bloqueiam o processamento de confirmações.
• CommitTimeout para processamento para desistir se ele for bloqueado na fase de confirmação.
• ServerTimeout para que as consultas cheguem ao tempo limite após algum tempo.
• Configurações do pool de conexões, como IdleConnectionTimeout, IdleOrphanSessionTimeout, MaxIdleSessionTimeout, MinIdleSessionTimeout e DatabaseConnectionPoolConnectTimeout e as que discutimos anteriormente, ExternalConnectionTimeout e ExternalCommandTimeout.

Caracteres especiais

Em algumas situações, o erro de tempo limite de processamento ocorreu devido a alguns caracteres especiais presentes nas colunas de uma das tabelas de dimensão. Mesmo valores nulos em uma coluna de dimensão podem causar falhas de processamento.

Você pode isolar melhor o problema processando cada objeto um de cada vez até encontrar o problema.

Por exemplo, ao processar a tabela de dimensões, ela gera o erro OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

Depois que o usuário removeu os caracteres especiais, o processamento funcionou conforme o esperado.

Isolar em uma partição

Você pode ser capaz de isolar ainda mais o erro em uma partição específica. Se você particionou seu cubo, pode haver uma consulta de baixo desempenho em uma das partições.

Experimente a consulta de partição. Altere de uma tabela de consulta nomeada direta na exibição da Fonte de Dados para uma consulta de SQL subjacente.