4

SSRS 2012 で非常に基本的なレポートを実行しています。テーブルからデータを取得しているだけで、クエリの Where 句でパラメーターを使用しています。SSRS クエリでパラメーターをハードコーディングすると、クエリは高速に (5 秒未満で) 実行されますが、動的に選択されたパラメーターのままにしておくと、クエリのレンダリングに 5 分以上かかります。私が使用しているものに似た抽象的なクエリを次に示します。

Select Col1, Count(*)
From Tbl1
Where Col2 = @Para1
Group By Col1
OPTION (RECOMPILE);

パラメータ スニッフィングの問題に対処するために、クエリで OPTION (RECOMPILE) を使用しようとしました。データ型も確認しました。Col2 は CHAR(2) で、Para1 は TEXT なので、実行時に変換は必要ありません。

これを引き起こしている可能性のある考えはありますか？

4

4 に答える 4

1

同じ問題が発生しました。SQL Server プロファイラー スニッフィング クエリを SQL Server に実行して、レポートが遅い場所を特定したところ、クエリが 20 秒実行されていることがわかりました。クエリはexec sp_executesqlでラップされます。クエリを SSMS にコピーしたところ、20 秒実行されました。クエリをストレート SQL に変換すると、1 秒実行されました。あはは！

exec sp_executesql sql に戻ると 、予想どおり IN 句がありました。

operid IN  (N''XICL002'',N''XICL005'',N''XICL026'',N''XICL028'...

operid は varchar(32) として宣言されますが、Nプレフィックスはパラメーターを強制的に NVARCHAR にします。Nを削除すると、exec sp_executesql sql が 1 秒で実行されました。

私の場合、レポートを変更できました。IN 句は、複数選択パラメーター (p_operators) によって入力されました。p_operators リストを生成したパラメーターを使用して、ビューから operid リストを取得するようにレポート クエリを変更しました。

operid IN (SELECT oper_id  FROM foo WHERE (foo1 IN (@p_foo1)) AND (foo2 IN (@p_foo2)) AND ...

基本的に、パラメータを NVARCHAR から VARCHAR に変換すると、パフォーマンスが低下します。SSRS は、「テキスト」だけでなく、パラメーターのデータ型を示すオプションを提供する必要があるようです。また、開発モードでのクエリのロギングも同様に優れています。

（役立つ情報を提供できれば幸いです。会社のポリシーにより、あまり多くの情報を書くことはできません）

于 2015-11-11T17:54:24.743 に答える
1

クエリを使用してデータをロードするレポートでも同様の問題がありました。私の場合、アーキテクチャ チームによって確立された開発パターンをサポートする必要がありました (SSRS DataSet で直接クエリを使用します)。フィルタリングされていないデータの量とセキュリティ要件 (DB から要求されたデータのみを抽出する) のため、フィルターを使用できませんでした。

したがって、私の解決策はコンバージョンを攻撃することでした。テーブル変数を宣言し、これらの変数に SSRS パラメーターから変換された選択値を入力し、これらのテーブル変数をWHERE … IN (…)式で使用しました。これにより、すべての要件クエリのみ、制限されたデータ量、安全なデータ アクセスがカバーされ、 NVARCHAR から VARCHAR への変換の速度低下が解決されました。

クエリのソリューションは次のようになります (@pSelectedValuesレポートの選択パラメーターにマップされた変数であり、変更前に既に存在していました):

DECLARE @tMySelectedParameterValues TABLE( SelectedValue varchar(255) NULL );

INSERT INTO @tMySelectedParameterValues

SELECT DISTINCT EntityStatusStatusName
FROM      dbo.t_MyReferenceData
WHERE     ValueForParameters IN (@pSelectedValues);

... main selection and from parts ....

WHERE keyValues IN (SELECT SelectedValue FROM   @tMySelectedParameterValues )
于 2016-05-24T16:18:41.713 に答える
0

三つのこと：

  1. なぜ再コンパイルを使用する必要があるのですか? あなたの計画が、それを必要としないたびに実行することを特に再考したい場合を除きます。特に、クエリが単純であると述べている場合。SSRS は SQL を超えて独自の解釈を行うため、それを行うためにさらに多くのことを追加すると、問題が発生するだけです。再コンパイルを行う必要がある場合は、それを proc に入れて、SQL エンジンが理解できるようにすべてのロジックをカプセル化することをお勧めします。

  2. SSMS のパラメーターを使用したクエリも遅いですか? あなたはそれが高速にハードコーディングされていると述べましたが、パラメーターを使用してSSMSでテストしていません。SSMS でパラメーターが遅い場合がありました。

  3. 少しのノウハウで、SSRS のパラメーター部分を「ごまかす」ことができます。パラメータが特に悪い極端な場合に、実行時に実行される式を作成できます。データセット オプションで式の「fx」をクリックしてから、次の操作を行います。

    ="Select Col1, Count(*)
From Tbl1
Where Col2 = " & Parameters!Para1.Value

タイプがテキストである限り、実行時に評価される正当な文字列が生成されます。1 つの注意点は、フィールドが最初に自動入力されない可能性があることです。そのため、実際のクエリを実行し、自動入力してから戻って関数を挿入することをお勧めします。それ以外の場合は、フィールドの左側のペインでフィールドを手動で設定する必要があります。私見の痛みである「フィールド」を示すデータセット。

于 2013-04-03T15:46:36.057 に答える