Risolvere l'Analysis Services di errore "OLE DB errore: errore OLE DB o ODBC: Operazione annullata; HY008"

Questo articolo descrive le informazioni generali sulla risoluzione dei problemi e i passaggi specifici per un errore che possono verificarsi quando si usa SQL Server Analysis Services quando si elaborano modelli multidimensionali.

Nota

Questo articolo è derivato da un blog pubblicato l'11 giugno 2012 e potrebbe contenere materiale datato.

Errori durante l'elaborazione

Analysis Services'elaborazione potrebbe non riuscire con questo errore: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

In SQL OLE DB termini, significa , che suggerisce che la query è stata annullata intenzionalmente HY008 DB_E_CANCELED dal chiamante. A volte, questo errore può essere visualizzato meglio da 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.

SQL Server Management Studio stato del processo che mostra un errore

HYT00 indica DB_E_ABORTLIMITREACHED (0x80040E31) che o un timeout è scaduto. Il timeout è scaduto a causa dell SQL_QUERY_TIMEOUT predefinita. Timeout del comando o timeout della query per interrompere la query in esecuzione e annullare il lavoro.

Comando ed errori equivalenti XMLA

Se si usano comandi XMLA per elaborare gli Analysis Services, la sintassi potrebbe essere simile all'esempio seguente:

<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 si verifica un timeout, il sistema visualizza un elenco di errori diversi accodati in una stringa lunga. Una o più connessioni di database hanno un timeout, ma è possibile che non si noti. L'errore generato da più connessioni da una notifica di annullamento è significativo. Analysis Services segnala gli errori in un ordine apparentemente casuale a causa della natura multi-thread dell'implementazione dell'elaborazione. L'indicatore di timeout è difficile da visualizzare.

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.

Per comprendere questo output, 08S01 significa DB_E_CANNOTCONNECT dal provider. Questo HResult è un po' erta. È possibile che il sistema non sia in grado di connettersi o che sia stato disconnesso o annullato dal provider o dal server se la query è stata annullata.

Controllare il OLAP\Log\Msmdsrv.log file. È possibile che venga visualizzato il messaggio di errore nel caso in cui l'applicazione non lo registra.

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

L'output del log precedente indica che il provider OLE DB ha segnalato un errore, codice esadecimale 0xC1210003 .

Tentativo di semplificare l'errore

Se non è possibile determinare l'oggetto e l'attributo specifici che causano il problema, semplificare il parallelismo di elaborazione limitando il numero di connessioni al database relazionale.

In Esplora soluzioni selezionare le proprietà dell'origine dati. Regolare il numero massimo di connessioni da un valore di 10 a un valore pari a 1. Alla successiva elaborazione degli oggetti, qualsiasi errore potrebbe mostrare meglio gli attributi del problema e una descrizione più esatta dell'errore.

Background sull'elaborazione dei cubi

Quando Analysis Services elabora un cubo o un oggetto di livello inferiore, ad esempio una dimensione o un gruppo di misure, invia molte query SQL di grandi dimensioni al motore di database relazionale tramite un provider OLE DB. Ad esempio: SELECT * FROM DimTABLE1, SELECT * FROM FactTable1.

L'esecuzione di queste query di elaborazione può richiedere da minuti a ore. Il periodo di tempo dipende dal numero di join presenti e dalle dimensioni delle tabelle e delle partizioni. Il numero di join dipende interamente dalla progettazione del cubo e dalle relazioni tra dimensioni e gruppi di misure nella progettazione.

Per connettersi all'origine dati relazionale, nella progettazione del cubo sono archiviate stringhe di connessione che puntano data warehouse nel server di database.

Origini dati di Analysis Services

Si tratta di una stringa di connessione che viene salvata nella progettazione Analysis Services database. Può puntare a SQL Server o ad altri database relazionali di terze parti, ad esempio Teradata e Oracle. Nello screenshot seguente viene visualizzato il provider SQL Server 2012 OLE DB denominato SQLNCLI11.1.

Analysis Services proprietà dell'origine dati

Informazioni di base sui timeout di comando e connessione

Ogni volta che all'origine dati viene eseguito un comando, ad esempio una query T-SQL nel caso di SQL Server, la proprietà di timeout del comando viene impostata dal Analysis Services chiamante.

Nell'esempio seguente viene illustrato lo pseudocodice ADO per mostrare come un timeout del comando viene impostato dal codice che viene Analysis Services internamente:

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

Nell'esempio precedente, se sono trascorsi 15 secondi e la query non è ancora stata completata, il provider OLE DB annulla la query per conto del chiamante. Il chiamante non deve mantenere alcun timer perché il timeout è impostato nel livello del provider. Tuttavia, se la query ha esito negativo, il chiamante non sa quanto tempo ha impiegato e se si è verificato o meno un timeout.

In OLE DB termini, questa proprietà viene chiamata DBPROP_COMMANDTIMEOUT'oggetto DBPROPSET_ROWSET. Questa proprietà consente di eseguire query per un determinato periodo di tempo. Se il comando non viene completato, viene annullato. In SQL Server possibile visualizzare tali timeout con un evento Attention nella traccia del profiler. Nella traccia del profiler, la durata dell'evento corrisponde esattamente alla durata del timeout del comando.

L'impostazione del timeout del comando non è impostata sulla connessione o sulla stringa di connessione stessa. Deve essere impostato dopo che è stata stabilita una connessione, in quanto viene usato ogni oggetto comando. È presente un timeout di connessione simile per DBPROP_INIT_TIMEOUT DBPROPSET_DBINIT l'oggetto . In Analysis Services timeout della connessione è la proprietà separata ExternalConnectionTimeout. Questa impostazione è applicabile per effettuare un contatto iniziale con il server e controllare l'autenticazione e l'autorizzazione degli account. Questa impostazione in genere non influisce sulle query a esecuzione lunga, perché la connessione iniziale ha avuto esito positivo senza errori.

È possibile controllare il timeout OLE DB comando in Analysis Services. È presente un'impostazione ExternalCommandTimeout nelle opzioni avanzate nell'Analysis Services predefinita. Il valore predefinito è 60 minuti (un'ora). Il valore di timeout potrebbe non essere sufficientemente lungo. Questa configurazione predefinita consente a qualsiasi T-SQL query nel database relazionale di durare almeno un'ora. Dopo tale punto, il comando viene annullato dal provider OLE DB usato per connettersi al sistema e il comando di elaborazione Analysis Services non riesce.

La proprietà Integer ExternalCommandTimeout definisce il timeout, in secondi, per i comandi emessi a server esterni, che include origini dati relazionali e server Analysis Services esterni. Il valore predefinito per questa proprietà è 3.600 secondi.

Se si prevede che l'elaborazione delle query sia superiore a un'ora, aumentare il timeout di oltre un'ora. In un esempio, il completamento delle query join di elaborazione ha richiesto circa nove ore in un database da 2 TB con join complessi di grandi dimensioni.

Fare clic con il pulsante destro del mouse sul nome del server Management Studio > proprietà. Selezionare la casella di controllo Mostra proprietà avanzate (tutte). Modificare quindi l'impostazione ExternalCommandTimeout, come illustrato nelle immagini seguenti:

Analysis Services proprietà del server

Casella di controllo Mostra proprietà avanzate (tutte)

A questo punto, quando il server esegue query esterne per la conversazione con il database relazionale, imposta il timeout del comando sul valore specificato in modo che possa essere eseguito a lungo senza errori.

Una lunga durata dell'elaborazione può causare timeout

Se l'elaborazione delle query richiede più di un'ora, è possibile ottimizzare il sistema per ottenere prestazioni più veloci:

  • Ottimizzare i join che Analysis Services quando vengono eseguite tutte le query di elaborazione in background per conto dell'utente.
  • Partizionare i gruppi di misure in modo che l'unità di lavoro eseguita dall'elaborazione sia un blocco di dati più piccolo anziché tutti i dati contemporaneamente. Il partizionamento richiede un'attenta attenzione e un'attenta progettazione dei cubi. Se i dati hanno più di 20 milioni di righe in una tabella e si verificano problemi di prestazioni di elaborazione, prendere in considerazione il partizionamento.

Ottimizzare il sistema di database relazionali

Dopo aver eseguito l'elaborazione del cubo una o due volte, cercare gli indici mancanti nel database relazionale o nel data warehouse sistema. L'ottimizzazione del database può richiedere alcuni minuti. Aggiungere alcuni indici alle tabelle relazionali data warehouse per ottimizzare i criteri di join per elaborare il cubo.

Il codice T-SQL seguente è preso in prestito dallo strumento di supporto PSSDiag. Identifica gli indici mancanti più utili e funziona in SQL Server 2005 e versioni successive. Trovare gli indici nelle tabelle dei fatti e delle dimensioni che consentono di migliorare al massimo le prestazioni. Tenere presente che, anche se l'aggiunta di un indice può contribuire a migliorare le prestazioni di lettura come l'elaborazione dei cubi, potrebbe rallentare alcune prestazioni di inserimento e aggiornamento, ad esempio le attività di estrazione, trasformazione, caricamento (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

Impatto della concorrenza sulla memoria sui timeout

Esistono diversi motivi per cui possono verificarsi timeout e molti includono scenari non di timeout. La seconda causa più comune di un annullamento di query T-SQL T-SQL è la memoria insufficiente.

Possono esserci competizioni per la memoria tra SQL Server motore di database (SQLServr.exe), Analysis Services (MsMdsrv.exe), pacchetti Integration Services (DTExec.exe o ISServerExec.exe) e Reporting Services in esecuzione nello stesso computer. Potrebbe essere necessario limitazione degli altri servizi o bilanciare le allocazioni di memoria. La regolazione più comune è limitare l'SQL Server di memoria massima del server.

L'elaborazione dei cubi è simile al tempo di elaborazione più intensivo per un SQL Server usato come data warehouse, perché Analysis Services esegue il push di diverse query di grandi dimensioni con join complessi al motore di database relazionale di SQL contemporaneamente.

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

I processi ETL che in genere vengono eseguiti raramente traggono vantaggio dal normale buffering SQL Server pool di buffer del motore di database. Prendere SQL Server Integration Services pacchetti (SSIS) che importano set di dati di grandi dimensioni da un sistema transazionale in un data warehouse sistema. Le operazioni ETL usano spesso BULK INSERT comandi che non richiedono molti dati ad accesso frequente in memoria.

Altre operazioni ETL durante la fase ETL della creazione di un data warehouse possono trarre vantaggio SQL pool di buffer di grandi dimensioni. Le parti di lettura (SELECT) e UPDATE e JOIN dell'elaborazione ETL, ad esempio ricerche e aggiornamenti delle dimensioni a modifica lenta, utilizzano i dati ad accesso più caldo memorizzati nella cache, se disponibili. L'abbassamento SQL Server motore di database memoria del cubo potrebbe avere un effetto collaterale sulle parti delle importazioni ETL che in genere vengono applicate subito prima dell'elaborazione del cubo.

La lettura dei dati dalla RAM è 1000-1 milione di volte più veloce rispetto alla lettura dall'unità disco rotante media, quindi la compattazione del pool di buffer SQL comporta più letture del disco. A meno che non si dispone di dischi SSD (Solid-State Disk) di fascia alta o san di fascia alta, è possibile attendere un po' di più.

Misurare il consumo di memoria nel sistema

Se la memoria è il responsabile, raccogliere una traccia del profiler e questi contatori delle prestazioni per analizzare meglio la causa:

  1. Configurare l'Windows Monitor prestazioni per produrre una traccia dell'utilizzo delle risorse. Selezionare Start > Run > Perfmon (Avvia esecuzione perfmon).

  2. Fare clic con il pulsante destro del mouse sull'icona Registri contatori nell'albero in Registri prestazioni e avviare un nuovo registro contatori. Assegnare un nome al log.

  3. Aggiungere il contatore per gli oggetti seguenti: tutti i contatori per ogni oggetto e tutte le istanze per ogni oggetto.

    • Memoria
    • MSAS* --- tutti gli oggetti (per un'istanza predefinita di Analysis Services)
    • MSOLAP$InstanceName* --- tutti gli oggetti (per un'istanza denominata di Analysis Services)
    • MSSQL* --- tutti gli oggetti (per il SQL Server motore di database)
    • File di paging
    • Processo
    • Processore
    • Sistema
    • Thread
  4. Campionare ogni 15 secondi.

  5. Nella scheda Log specificare la strategia di directory e nome file come file binario.

  6. Per ottenere il Monitor prestazioni eseguire il roll over in un nuovo file una volta al giorno, nella scheda Pianificazione selezionare:

    • Arresta log dopo: 1 giorno
    • Alla chiusura del file di log: avvia un nuovo file di log

Esaminare i Monitor prestazioni seguenti

  1. Esaminare il contatore SQL Server del motore di distribuzione per verificare se la memoria SQL memoria totale del > server aumentava fuori controllo.

  2. Esaminare il contatore > Memory Available MBytes (MByte disponibili per la memoria) per verificare la quantità di memoria disponibile per i processi in esecuzione in Windows.

  3. Esaminare Process > Private Bytes (Elabora byte privati) per i vari processi eseguibili per vedere quanto ognuno prende in confronto.

  4. Esaminare i contatori MSAS e MSOLAP. Se la quantità di utilizzo è superiore alla quantità di KB elevata, Analysis Services necessario tagliare alcuni buffer in memoria.

    • KB memoria utilizzata
    • KB limite superiore memoria
    • KB limite inferiore memoria
    • KB limite superiore memoria

    Se la quantità di KB di utilizzo della memoria supera il limite di KB rigidi, Analysis Services potrebbe annullare tutto il lavoro corrente e passare alla modalità panic per determinare l'annullamento dei consumer di memoria. La modalità panic potrebbe manifestarsi in errori simili, ma in genere l'errore è più descrittivo, ad esempio 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.

Impatto dell'elaborazione parallela sui timeout

Analysis Services comandi di elaborazione possono essere eseguiti in parallelo o in sequenza. Nella sintassi del comando di elaborazione verificare se si sta specificando l'esecuzione in ordine sequenziale o in parallelo. Controllare il pacchetto SSIS o il processo XMLA che esegue l'elaborazione.

Questa immagine mostra le impostazioni per un'attività di elaborazione Analysis Services SSIS:

Impostazioni dell'attività Analysis Services SSIS

Questo esempio illustra un comando XMLA che esegue fino a otto attività in parallelo:

<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 si verifica il timeout del sistema, potrebbe essere necessario ridimensionare il numero di attività parallele, soprattutto quando si esegue manualmente l'override dell'impostazione predefinita, Consenti al server di decidere.

È possibile ridurre meglio la limitazione del sistema riducendo la configurazione di MaxThreads del 50% e rielaborando gli oggetti in modo che un numero inferiore di thread venga eseguito contemporaneamente.

Nel peggiore dei casi, eseguire l'elaborazione in modalità sequenziale per verificare se gli errori vanno persi. Il sistema richiede meno memoria per eseguire una sequenza di un'attività alla volta anziché molte attività contemporaneamente. Il compromesso potrebbe essere che l'esecuzione è più lunga perché non è possibile eseguire il push dell'hardware di sistema agli stessi limiti di velocità effettiva.

Per altre informazioni sulle procedure consigliate per l'elaborazione, SQL Server procedure consigliate.

Per altre informazioni sull'architettura dell'elaborazione dei cubi, Analysis Services 2005.

Impatto della memoria di aggregazione sui timeout

È presente un'impostazione avanzata aggregationMemoryLimitMax. Per altre informazioni, vedere questo post di blog

SQL Server Analysis Services usa la quota di memoria per controllare il numero di processi simultanei. Ogni processo calcola la quantità di memoria necessario per completare il processo e richiede la quota di memoria in base alla stima. Il processo procede solo quando viene concessa la quota di memoria. Viene stimata la quota per un processo di aggregazione. Le impostazioni di configurazione che controllano le stime di utilizzo della memoria sono AggregationMemoryLimitMin e AggregationMemoryLimitMax.

Per ottenere un maggiore parallelismo per l'elaborazione, ottimizzare le impostazioni.

Impostazioni di timeout aggiuntive

Timeout query è un'altra impostazione nell'origine dati. Questa impostazione sembra non essere immediatamente applicabile all'elaborazione. Questa impostazione si applica al pool di connessioni e consente di impostare la scadenza delle connessioni inattive che non sono più necessarie. Questa impostazione non si applica ai comandi eseguiti durante l'elaborazione o ai comandi ROLAP.

Analysis Services errore di elaborazione

Esistono molti altri timeout in Analysis Services, ad esempio:

  • ForceCommitTimeout per l'elaborazione per determinare la fine delle query utente se le query MDX contengono blocchi che bloccano l'elaborazione dei commit.
  • CommitTimeout per l'elaborazione da rinunciare se viene bloccato nella fase di commit.
  • Timeout del server per le query che si verificano dopo un certo periodo di tempo.
  • Impostazioni del pool di connessioni, ad esempio IdleConnectionTimeout, IdleOrphanSessionTimeout, MaxIdleSessionTimeout, MinIdleSessionTimeout e DatabaseConnectionPoolConnectTimeout e quelle descritte in precedenza, ExternalConnectionTimeout ed ExternalCommandTimeout.

Caratteri speciali

In alcune situazioni, l'errore di timeout di elaborazione è dovuto ad alcuni caratteri speciali presenti nelle colonne di una delle tabelle delle dimensioni. Anche i valori Null in una colonna della dimensione possono causare errori di elaborazione.

È possibile isolare meglio il problema elaborando ogni oggetto uno alla volta fino a individuare il problema.

Ad esempio, durante l'elaborazione della tabella delle dimensioni, viene generato l'errore OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

Dopo che l'utente ha rimosso i caratteri speciali, l'elaborazione ha funzionato come previsto.

Isolare in una partizione

Potrebbe essere possibile isolare ulteriormente l'errore in una partizione specifica. Se il cubo è stato partizionato, potrebbe essere presente una query con prestazioni scarse in una delle partizioni.

Provare a eseguire la query di partizione. Passare da una tabella query denominata diretta nella vista origine dati a una query SQL sottostante.