Beheben des Fehlers "OLE DB-Fehler: OLE DB oder ODBC-Fehler: Abgebrochener Vorgang; HY008"

In diesem Artikel werden Hintergrundbehandlungsinformationen und bestimmte Schritte für einen Fehler beschrieben, der auftreten kann, wenn Sie SQL Server Analysis Services verwenden, wenn Sie mehrdimensionale Modelle verarbeiten.

Hinweis

Dieser Artikel wird von einem Blog abgeleitet, der am 11. Juni 2012 veröffentlicht wurde und möglicherweise Datumsmaterial enthält.

Fehler während der Verarbeitung

Die Verarbeitung von Analysis Services kann mit diesem Fehler fehlschlagen: OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

In SQL OLE DB-Ausdrücken bedeutet DB_E_CANCELEDdies, HY008 dass die Abfrage gezielt vom Aufrufer abgebrochen wurde. Manchmal können Sie diesen Fehler besser von SQL Server Management Studio sehen:

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 bedeutet DB_E_ABORTLIMITREACHED (0x80040E31) oder ein Timeout abgelaufen ist. Das Timeout ist aufgrund der SQL_QUERY_TIMEOUT Einstellung abgelaufen. Das Befehlstimeout oder Abfragetimeout wurde ausgelöst, um die ausgeführte Abfrage zu beenden und die Arbeit abzubrechen.

XMLA-äquivalenter Befehl und Fehler

Wenn Sie XMLA-Befehle zum Verarbeiten Ihrer Analysis Services-Objekte verwenden, ähnelt die Syntax möglicherweise dem folgenden Beispiel:

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

Wenn ein Timeout auftritt, zeigt das System eine Liste verschiedener Fehler an, die in einer langen Zeichenfolge angefügt sind. Eine oder mehrere Der Datenbankverbindungen verfügen über ein Timeout, aber möglicherweise nicht. Es gibt erhebliche Rauschen im Fehler, dass die mehrere Verbindungen von einer Abbruchbenachrichtigung abgerufen werden. Analysis Services meldet die Fehler in einer scheinbar zufälligen Reihenfolge aufgrund der Multithread-Art der Verarbeitungsimplementierung. Die Timeoutanzeige ist schwer zu sehen.

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.

Um diese Ausgabe zu verstehen, 08S01 bedeutet DB_E_CANNOTCONNECT das vom Anbieter. Dieses HResult ist ein bisschen falsch. Es könnte sein, dass das System keine Verbindung herstellen kann oder dass es vom Anbieter oder dem Server getrennt oder abgebrochen wurde, wenn die Abfrage abgebrochen wurde.

Überprüfen Sie die OLAP\Log\Msmdsrv.log Datei. Möglicherweise erhalten Sie die Fehlermeldung, wenn Ihre Anwendung sie nicht protokolliert hat.

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

Die vorherige Protokollausgabe gibt an, dass der OLE DB-Anbieter einen Fehler gemeldet hat, hex code 0xC1210003.

Versuchen Sie, den Fehler zu vereinfachen.

Wenn Sie nicht bestimmen können, welche spezifischen Objekte und Attribute das Problem verursachen, vereinfachen Sie die Verarbeitungs parallelismus, indem Sie die Anzahl der Verbindungen mit der relationalen Datenbank einschränken.

Wählen Sie in Projektmappen-Explorer Ihre Datenquelleneigenschaften aus. Passen Sie die maximale Anzahl von Verbindungen von einem Wert von 10 auf einen Wert von 1 an. Beim nächsten Verarbeiten der Objekte kann ein Fehler die Problemattribute besser und eine genauere Fehlerbeschreibung anzeigen.

Hintergrund zur Würfelverarbeitung

Wenn Analysis Services einen Cube oder ein Objekt auf niedrigerer Ebene wie eine Dimension oder Maßgruppe verarbeitet, sendet er viele große SQL Abfragen an das relationale Datenbankmodul über einen OLE DB-Anbieter. Beispiel: SELECT * FROM DimTABLE1, SELECT * FROM FactTable1.

Diese Verarbeitungsabfragen können zwischen Minuten und Stunden dauern, um ausgeführt zu werden. Die Dauer hängt davon ab, wie viele Verknüpfungen vorhanden sind und wie groß die Tabellen und Partitionen sind. Die Anzahl der Verknüpfungen hängt vollständig von Ihrem Cubedesign ab, und Ihre Dimension und Messen von Gruppenbeziehungen im Design.

Um eine Verbindung mit der relationalen Datenquelle herzustellen, gibt es Verbindungszeichenfolgen, die im Cubeentwurf gespeichert sind, um auf das Data Warehouse im Datenbankserver zu verweisen.

Dies ist eine Verbindungszeichenfolge, die im Analysis Services-Datenbankdesign gespeichert wird. Es kann auf SQL Server verweisen oder auf andere relationale Datenbanken von Drittanbietern verweisen, z. B. Teradata und Oracle. Im folgenden Screenshot wird der SQL Server 2012 OLE DB-Anbieter mit dem Namen SQLNCLI11.1 angezeigt.

Hintergrund für Befehls- und Verbindungstimeouts

Wenn ein Befehl wie eine T-SQL-Abfrage im Fall von SQL Server an die Datenquelle ausgestellt wird, wird die Befehlstimeouteigenschaft vom Analysis Services-Aufrufer festgelegt.

Das folgende Beispiel zeigt ADO-Pseudocode, um anzuzeigen, wie ein Befehlstimeout vom Code festgelegt wird, der Analysis Services intern ausführt:

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

Wenn im vorherigen Beispiel 15 Sekunden übergeben und die Abfrage noch nicht abgeschlossen ist, wird der OLE DB-Anbieter die Abfrage im Auftrag des Anrufers abgebrochen. Der Anrufer muss keinen Zeitgeber beibehalten, da das Timeout auf der Anbieterebene festgelegt ist. Wenn die Abfrage fehlschlägt, weiß der Anrufer jedoch nicht wirklich, wie lange es dauerte und ob es sich um ein Timeout handelte oder nicht.

In OLE DB-Ausdrücken wird diese Eigenschaft DBPROP_COMMANDTIMEOUT auf dem DBPROPSET_ROWSET-Objekt aufgerufen. Mit dieser Eigenschaft können Sie Abfragen für eine bestimmte Zeit ausführen. Wenn der Befehl nicht abgeschlossen ist, wird es abgebrochen. In SQL Server können Sie solche Timeouts mit einem Aufmerksamkeitsereignis in der Profilerablaufverfolgung sehen. In dieser Profiler-Ablaufverfolgung entspricht die Ereignisdauer genau der Dauer des Befehlstimeouts.

Die Befehlstimeouteinstellung ist nicht für die Verbindung oder die Verbindungszeichenfolge selbst festgelegt. Es muss festgelegt werden, nachdem eine Verbindung eingerichtet wurde, da jedes Befehlsobjekt verwendet wird. Auf dem DBPROPSET_DBINIT Objekt gibt es einen ähnlichen VerbindungstimeoutDBPROP_INIT_TIMEOUT. In Analysis Services ist das Verbindungstimeout die separate Eigenschaft ExternalConnectionTimeout. Diese Einstellung gilt für den anfänglichen Kontakt mit dem Server und die Überprüfung der Authentifizierung und Autorisierung von Konten. Diese Einstellung wirkt sich in der Regel nicht auf lange ausgeführte Abfragen aus, da die anfängliche Verbindung ohne Fehler erfolgreich war.

Sie können das OLE DB-Befehlstimeout in Analysis Services steuern. Es gibt eine ExterneCommandTimeout-Einstellung in den erweiterten Optionen in der Analysis Services-Instanz. Der Standardwert beträgt 60 Min. (eine Stunde).  Dieser Timeoutwert ist möglicherweise nicht lang genug. Diese Standardkonfiguration ermöglicht eine beliebige T-SQL-Abfrage der relationalen Datenbank, um eine Stunde oder mehr zu dauern. Nach diesem Punkt wird der Befehl vom OLE DB-Anbieter abgebrochen, der zum Herstellen einer Verbindung mit diesem System verwendet wird, und der Befehl "Analysis Services-Verarbeitung" schlägt fehl.

Die Integer-Eigenschaft "ExternalCommandTimeout " definiert das Timeout in Sekunden für Befehle, die an externe Server ausgestellt wurden, einschließlich relationaler Datenquellen und externer Analysis Services-Server. Der Standardwert für diese Eigenschaft beträgt 3.600 Sekunden.

Wenn Sie erwarten, dass die Verarbeitungsabfragen mehr als eine Stunde dauern, erhöhen Sie den Timeout höher als eine Stunde. In einem Beispiel dauerte die Verarbeitung von Verknüpfungsabfragen etwa neun Stunden, um eine 2-TB-Datenbank mit einigen großen komplexen Verknüpfungen abzuschließen.

Klicken Sie mit der rechten> Maustaste auf den Servernamen in Management Studio Properties. Aktivieren Sie das Kontrollkästchen "Erweiterte Eigenschaften anzeigen" (Alle) Passen Sie dann die Einstellung "ExternalCommandTimeout " an, wie in den folgenden Bildern dargestellt:

Wenn der Server externe Abfragen ausführt, um mit der relationalen Datenbank zu sprechen, legt er das Befehlstimeout auf den angegebenen Wert fest, sodass er eine lange Zeit ohne Fehler ausführen kann.

Lange Verarbeitungsdauer kann zu Timeouts führen

Wenn die Verarbeitung von Abfragen mehr als eine Stunde dauert, gibt es möglicherweise Möglichkeiten, das System schneller auszuführen:

• Optimieren Sie die Verknüpfungen, die Analysis Services ausführt, wenn alle diese Verarbeitungsabfragen im Hintergrund im Namen ausgeführt werden.
• Partitionieren Sie Ihre Messgruppen so, dass die Arbeitseinheit, die durch die Verarbeitung durchgeführt wird, ein kleineres Datenteil ist, anstatt alle Daten gleichzeitig. Die Partitionierung erfordert sorgfältige Überlegungen und Würfeldesignarbeiten. Wenn Ihre Daten über mehr als 20 Millionen Zeilen in einer Tabelle verfügen und Probleme bei der Verarbeitung von Leistungsproblemen sehen, sollten Sie die Partitionierung berücksichtigen.

Optimieren des relationalen Datenbanksystems

Nachdem Sie die Cubeverarbeitung einmal oder zweimal ausgeführt haben, suchen Sie nach fehlenden Indizes in der relationalen Datenbank oder dem Datenlagersystem. Nehmen Sie einige Minuten zeit, um die Datenbank zu optimieren. Fügen Sie den relationalen Datenlagertabellen einige Indizes hinzu, um die Verknüpfungskriterien zum Verarbeiten des Cubes zu optimieren.

Der folgende T-SQL-Code wird vom Supporttool PSSDiag ausgeliehen. Es identifiziert die hilfreichsten fehlenden Indizes und funktioniert auf SQL Server 2005 und höher. Suchen Sie die Indizes für die Fakten- und Dimensionstabellen, die die Leistung am meisten verbessern. Denken Sie daran, dass beim Hinzufügen eines Indexes möglicherweise die Leistung wie die Cubeverarbeitung gelesen werden kann, kann es einige Einfügen- und Aktualisierungsleistung, z. B. Extrahieren, Transformieren, Laden (ETL)-Aktivitäten, verlangsamen.

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

Auswirkungen des Speicherwettbewerbs auf Timeouts

Es gibt mehrere Gründe, aus denen Timeouts auftreten können, und viele umfassen Nicht-Timeout-Szenarien. Die zweite häufigste Ursache für eine Verarbeitung von T-SQL Abfrageabbruch ist Nichtspeicherfehler.

Der Speicher kann zwischen SQL Server Datenbank-Engine (SQLServr.exe), Analysis Services (MsMdsrv.exe), Integration Services-Paketen (DTExec.exe oder ISServerExec.exe) und Reporting Services auf demselben Computer ausgeführt werden. Möglicherweise müssen Sie die anderen Dienste zurückdrosseln oder Speicherzuweisungen ausgleichen. Die am häufigsten verwendete Anpassung besteht darin, die SQL Server maximalen Serverspeichereinstellung zu beschränken.

Die Cubeverarbeitung ist wie die intensivste Verarbeitungszeit für ein SQL Server, das als Data Warehouse verwendet wird, da Analysis Services mehrere große Abfragen mit komplexen Verknüpfungen zur SQL relationalen Datenbankmodul gleichzeitig verschiebt.

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

Die ETL-Prozesse, die in der Regel selten von der normalen Pufferung des SQL Server Datenbankmodulspufferpool profitieren. Betrachten Sie SQL Server Integration Services (SSIS) Pakete, die große Datensätze aus einem Transaktionssystem in ein Datenlagersystem importieren. ETL-Vorgänge verwenden häufig MASSEN-INSERT-Befehle, die nicht viel warme Daten im Arbeitsspeicher erfordern.

Andere ETL-Vorgänge während der ETL-Phase des Erstellens eines Data Warehouse profitieren von SQL großen Pufferpool. Die Lese- und AKTUALISIERUNGs- und JOIN-Teile der ETL-Verarbeitung, z. B. Nachschlagevorgänge und langsam ändernde Dimensionupdates, verwenden zwischengespeicherte warme Daten im Arbeitsspeicher, sofern verfügbar. Das Verringern des Speichers des SQL Server Datenbank-Engine kann eine Nebenwirkungen auf diese Teile der ETL-Importe haben, die normalerweise direkt vor der Cubeverarbeitung ausgeführt werden.

Das Lesen von Daten aus RAM ist 1000-1 Millionen Mal schneller als das Lesen von Einem durchschnittlichen Spinnlaufwerk, sodass das Verkleinern des SQL Pufferpools mehr Datenträgerlesungen bedeutet. Es sei denn, Sie verfügen über High-End-Solid-State-Datenträger (SSDs) oder ein High-End-SAN, können Sie etwas mehr warten.

Messen des Speicherverbrauchs im System

Wenn der Speicher der Täter ist, sammeln Sie eine Profilerverfolgung und diese Leistungsindikatoren, um die Ursache besser zu untersuchen:

1. Richten Sie die Windows Leistungsmonitor ein, um eine Ablaufverfolgung des Ressourcenverbrauchs zu erzeugen. Wählen Sie "StartRunPerfmon>>" aus.

2. Klicken Sie mit der rechten Maustaste auf das Symbol " Zählerprotokolle " in der Struktur unter "Leistungsprotokolle", und beginnen Sie ein neues Zählerprotokoll. Benennen Sie das Protokoll.

3. Fügen Sie den Zähler für die folgenden Objekte hinzu: alle Zähler für jedes Objekt und alle Instanzen für jedes Objekt.

   • Arbeitsspeicher
   • MSAS* --- alle Objekte (für eine Standardinstanz von Analysis Services)
   • MSOLAP$InstanceName* --- alle Objekte (für eine benannte Instanz von Analysis Services)
   • MSSQL* --- alle Objekte (für die SQL Server Datenbank-Engine)
   • Auslagerungsdatei
   • Prozess
   • Prozessor
   • System
   • Thread

4. Beispiel für alle 15 Sekunden.

5. Geben Sie auf der Registerkarte "Protokoll " die Verzeichnis- und Dateinamenstrategie als Binäre Datei an.

6. Wenn Sie die Leistungsmonitor abrufen möchten, um einmal an eine neue Datei zu wechseln, wählen Sie auf der Registerkarte "Zeitplan" folgendes aus:

   • Beenden des Protokolls nach:1 Tag
   • Wenn die Protokolldatei geschlossen wird:Starten einer neuen Protokolldatei

Überprüfen der Leistungsmonitor Ergebnisse

1. Sehen Sie sich den Zähler des SQL Server Moduls an, um zu sehen, ob SQL MemoryTotal>Server-Speicher nicht kontrolliert wurde.

2. Sehen Sie sich den SpeicherVerfügbarkeits-MBytes-Zähler> an, um zu sehen, wie viel freier Arbeitsspeicher für die prozesse verfügbar war, die in Windows ausgeführt werden.

3. Schauen Sie sich ProcessPrivate>Bytes für die verschiedenen ausführbaren Prozesse an, um zu sehen, wie viel jeder vergleicht.

4. Schauen Sie sich die MSAS - und MSOLAP-Zähler an. Wenn der Nutzungsbetrag über den hohen KB-Betrag geht, muss Analysis Services einige der Puffer im Arbeitsspeicher kürzen.

   • Speicherauslastung in KB
   • Obere Arbeitsspeichergrenze in KB
   • Untere Arbeitsspeichergrenze in KB
   • Grenzwert für den festen Speicher (KB)

   Wenn der KB-Wert für die Speichernutzung den Grenzwert für harte KB überschreitet, kann Analysis Services alle aktuellen Arbeiten abbrechen und in den Panikmodus wechseln, um die Speicherverbraucher zu beenden. Der Panikmodus kann sich in ähnlichen Fehlern manifestieren, aber normalerweise ist der Fehler beschreibender, z The Operation Has been Cancelled . B. oder The session was canceled because it exceeded a timeout setting (session orphaned timeout or session idle timeout) or it exceeded the session memory limit.

Parallele Verarbeitungsauswirkungen auf Timeouts

Analysis Services-Verarbeitungsbefehle können parallel oder sequenziell ausgeführt werden. Überprüfen Sie in der Syntax der Verarbeitungsbefehle, ob Sie angeben, dass sie in sequenzieller Reihenfolge ausgeführt oder parallel ausgeführt werden sollen. Überprüfen Sie das SSIS-Paket oder den XMLA-Auftrag, der die Verarbeitung ausführt.

Dieses Bild zeigt die Einstellungen für eine SSIS Analysis Services-Verarbeitungsaufgabe:

In diesem Beispiel wird ein XMLA-Befehl gezeigt, der bis zu acht Aufgaben parallel ausführt:

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

Wenn das System zeitlos ist, müssen Sie möglicherweise die Anzahl paralleler Vorgänge zurückstufen, insbesondere wenn Sie die Standardeinstellung manuell außer Kraft setzen, lassen Sie den Server entscheiden.

Möglicherweise können Sie das System besser drosseln, indem Sie die MaxThreads-Konfiguration um 50 % reduzieren und die Objekte erneut verarbeiten, sodass weniger Threads gleichzeitig ausgeführt werden.

Führen Sie im schlimmsten Fall die Verarbeitung im Sequenziellen Modus aus, um zu sehen, ob die Fehler weggehen. Das System benötigt weniger Arbeitsspeicher, um eine Sequenz einer Aufgabe gleichzeitig auszuführen, anstatt viele Vorgänge gleichzeitig auszuführen. Der Tradeoff kann sein, dass es länger ausgeführt wird, da Sie die Systemhardware nicht auf die gleichen Durchsatzgrenzen verschieben können.

Weitere Informationen zur Verarbeitung bewährter Methoden finden Sie unter SQL Server bewährte Methoden.

Weitere Informationen zur Architektur der Cubeverarbeitung finden Sie unter Analysis Services 2005-Verarbeitungsarchitektur.

Auswirkungen des Aggregationsspeichers auf Timeouts

Es gibt eine erweiterte Einstellung von AggregationMemoryLimitMax. Weitere Informationen finden Sie in diesem Blogbeitrag

SQL Server Analysis Services verwendet Speicherkontingent, um die Anzahl gleichzeitiger Aufträge zu steuern. Jeder Auftrag berechnet, wie viel Arbeitsspeicher es benötigt, um den Auftrag abzuschließen und das Speicherkontingent basierend auf seiner Schätzung anfordert. Der Auftrag wird nur ausgeführt, wenn das Speicherkontingent gewährt wird. Wir schätzen das Kontingent für einen Aggregationsauftrag. Die Konfigurationseinstellungen, die die Speichernutzungsschätzungen steuern, sind AggregationMemoryLimitMin und AggregationMemoryLimitMax.

Um mehr Parallelität für die Verarbeitung zu erreichen, optimieren Sie die Einstellungen.

Zusätzliche Timeouteinstellungen

Abfragetimeout ist eine andere Einstellung in der Datenquelle. Diese Einstellung scheint nicht leicht auf die Verarbeitung anzuwenden. Diese Einstellung gilt für den Verbindungspool und hilft beim Ablauf von Leerlaufverbindungen, die nicht mehr benötigt werden. Diese Einstellung gilt nicht für die Befehle, die während der Verarbeitung oder rolap ausgeführt werden.

Es gibt viele andere Timeouts in Analysis Services, z. B. folgendes:

• ForceCommitTimeout zum Töten von Benutzerabfragen, wenn MDX-Abfragen Sperren enthalten, die die Verarbeitung von Commits blockieren.
• CommitTimeout für die Verarbeitung, um aufzugeben, wenn sie in der Commitphase blockiert wird.
• ServerTimeout für Abfragen, die nach einiger Zeit ausgezeitigt werden sollen.
• Verbindungspooleinstellungen, z. B. IdleConnectionTimeout, IdleOrphanSessionTimeout, MaxIdleSessionTimeout, MinIdleSessionTimeout und DatabaseConnectionPoolConnectTimeout und die zuvor beschriebenen, ExternalConnectionTimeout und ExternalCommandTimeout.

Sonderzeichen

In einigen Situationen war der Verarbeitungs-Timeoutfehler auf einige Sonderzeichen zurückzuführen, die in den Spalten einer der Dimensiontabellen vorhanden sind. Selbst Nullwerte in einer Dimensionsspalte können zu Verarbeitungsfehlern führen.

Sie können das Problem besser isolieren, indem Sie jedes Objekt gleichzeitig verarbeiten, bis Sie das Problem finden.

Beim Verarbeiten der Dimensiontabelle wird beispielsweise der Fehler ausgelöst. OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

Nachdem der Benutzer die Sonderzeichen entfernt hat, funktionierte die Verarbeitung wie erwartet.

Isolieren mit einer Partition

Möglicherweise können Sie den Fehler weiter auf eine bestimmte Partition isolieren. Wenn Sie Ihren Cube partitioniert haben, gibt es möglicherweise eine schlecht ausgeführte Abfrage unter einer der Partitionen.

Experimentieren Sie mit der Partitionsabfrage. Ändern Sie stattdessen eine direkte benannte Abfragetabelle in der Datenquellenansicht in eine zugrunde liegende SQL Abfrage.