キューブ処理中にOPENQUERY MDXクエリが非常に遅い

Question

SSASサーバー上に複数のキューブがあり、10GB以上のキューブがほとんどありません。 .NETアプリケーションの1つは、OPENQUERY経由で比較的小さなキューブ< 1GBキューブにアクセスしています。

デフォルトのタイムアウト（30秒）が設定されているため、大きいキューブの1つが処理中（36GB +）の.NETアプリケーションのタイムアウトになると、タイムアウトが増加する可能性がありますが、ユーザーはクエリを1〜完了する。同じMDXクエリを直接実行すると（SSMSまたはADOMD）、同じ状況で結果が<になります。

MSOLAP ProviderにはInProcess = trueが許可されています。 ADOMDを使用するようにアプリを変更することは、あまりにも多くのリソースを必要とするため、実行可能なオプションではありません。

リソースガバナを使用して、アプリケーションのクエリやその他の要求から処理を分離しようとしました。これは部分的に問題を軽減しましたが、すべてのクエリのタイムアウトではありません。

SQL ServerとSSASが連携するために他に何かできることはありますか？

PS。サーバー上で何が起こっているかを見て、私はSQL Server上で多くのODBC（および関連する）待機を確認しました。私には、キューブが処理してSQL Serverからデータにアクセスしている間、OLEDB/ODBCプロバイダ経由でOPENQUERY要求をキューブに「ブロック」しているように見えます。私はこの結論に達しましたが、.NET Appリクエストを処理するのに十分な空きCPUとメモリがあると確信しても、サーバーはあまりビジーではありません（CPU /メモリ使用量の減少）

edit ：

各.NETアプリケーション呼び出しでは、SSASに向かって実行されるMDXクエリはほとんど実行されません。すべてのクエリは100行を超えません。これはすべて一時テーブルで最終結果に組み合わされます。コードを開始して最適化するのが理にかなっていることは分かっていますが、コードは私たちが変更したい最後のものです。それはうまくテストされ、うまく動作します。

私は設定とインフラストラクチャのアイデアを探しています。

Answer 1

私たちのストアドプロシージャでは、OPENQUERYをmdxに使用すると、非常によく似たブロッキングとタイムアウトの問題が発生しました。

約2年前に私たちはオープンソースCLRソリューションに切り替えました。今では、これらのストアドプロシージャをOPENQUERYと同様の方法で使用しますが、問題はありません。

は現在、それがここにあります：（。作成されたリンクサーバー上）

https://olapextensions.codeplex.com/