リストビューのしきい値の周りの良い方法は何ですか？

sharepoint.stackexchange https://sharepoint.stackexchange.com/questions/16402

質問

SharePointリストのデータを使用しようとしています SSRS（レポートサービス）.
レポートはそれほど大きくありません - 数十行しかありませんが、各行に対して2番目のリストからデータを追加する必要があります。これには（現在）7000行が含まれています。 SharePoint 2007では、同様のことを成功させましたが、SharePoint 2010で動作させることはできません。
私はもう試した：

私は同じ壁にぶつかり続けます - リストが大きすぎるので、データを取得できません！同様のエラーが発生します。

管理者が実施するリストビューのしきい値を超えるため、操作の試みは禁止されています。

これは落胆しています。私はこのテーマについてかなり読んでいますが、アプリケーション全体のしきい値を増やす以外に、その周りの良い方法を見ることができません。

この新しい制限の周りの簡単な方法はありますか？難しい方法はありますか？
私は「ベストプラクティス」を探しています...これらの方法のいずれかを確実に使用し続けることができないようには見えません。 SSIを使用してすべての行をデータベースにコピーするために考えることができる唯一の「良い」ソリューションですが、それはやり過ぎのようです...

役に立ちましたか？

解決

中央管理では、リストのしきい値を完全に無効にするか、上限を設定することができます。また、制限が無効になっているときにタイムウィンドウを設定し、レポートサービスを実行することもできます。中央管理のWebアプリケーション管理ページに移動し、リボンの一般的な設定ボタンからリソーススロットリングオプションを選択します。

フィルターを使用してリストをクエリして、機能するはずのしきい値よりも少ないアイテムを返すようにクエリする場合。

他のヒント

ListViewのしきい値を回避するには、ライブラリの列をインデックス付けし、その列に対してクエリする必要があります。クエリで返される行の数がListViewしきい値を下回っている限り、例外は得られません。

例として、SharePointライブラリのすべてのフォルダーを取得しようとすると、この問題にぶつかりました。フォルダーの数は5000を大きく下回っていました（デフォルトのListViewしきい値）が、ライブラリに20,000を超えるアイテムがあるため、例外をトリガーしていました。

解決策は、コンテンツタイプ（SharePoint Libraryの設定からアクセス可能）をインデックス作成し、次のクエリを使用することでした。

<Where><BeginsWith><FieldRef Name='ContentTypeId' /><Value Type='ContentTypeId'>0x0120</Value></BeginsWith></Where>

クエリがListViewのしきい値よりも少ないことを確認する方法を把握する必要があります。

使用できます Contentiterator リストビューのしきい値をバイパスするクラスですが、データを取得するにはカスタムコードに頼る必要があります。

ドキュメント：「リスト項目、リスト、サイトを反復する方法を提供し、転送されるデータの量を調整します（つまり、SpqueryThrottleDecteptionを投げることを避けるため）。」

SSRS 2008 R2には、追加されたSharePointデータソースオプションがあります。 SharePointデータソースは、クエリ全体が完了するまで、2000の最大アイテムクエリのシリーズを実行します。これにより、リストビューのしきい値を克服することができ、パフォーマンスに大きく影響することはありません。 PowerPivotはこれをさらに良く実行します。一度に1000行のリストを照会し、結果をExcel Tied Workbookでキャッシュします。 PowerPivotは、ルックアップ列と関係を作成することもできます。 SSRSは、AnalyticsキューブのようにSharePoint内のPowerPivotデータソースを照会できます。

この質問者の選択は制限を上げることですが、それは正当な理由でそこにあります。パフォーマンスの低いサイトの作成を避けることです。サイトがコンテンツで成長するか、他のサイトのテンプレートになると、「この制限をリラックスする必要がある」ページをヒットするすべてのユーザーがサイトを遅くすることがわかります。発生します。

私はこれと一連のソリューションについてブログに書きました http://squarepoint.blogspot.com/2013/05/creating-performant-sharepoint-apps.html. 。そこには、問題を回避し、パフォーマンスペナルティなしでSharePointの動作を維持するのに役立ついくつかの提案があるかもしれません。

また、特定のリストのEnableThrottlingプロパティを無効にすることもできます。 マイケル・モリソンはここに書いた:

$web = Get-SPWeb http://url/to/web/with/list
$list = $web.Lists[“BIG_LIST_NAME”]
$list.EnableThrottling = $false

幸運を！

利用可能な場合は、おそらく検索APIとWebサービスを組み合わせることを検討してください。検索は、はるかに多くのフィールドをインデックスして返すことができます。データを取得するラウンドアバウトの方法ですが、サポート可能です。

「サービスアカウント」を定義し、そのアカウントサイト収集管理者の権利を与えることができます。そのアカウントを使用してデータを照会します。私は彼らが一度に20.000アイテム（またはそれは5000？！）をクエリすることができると信じています。

それがうまくいかない場合：

  • リスト列にインデクサーを置きます（UID？）
  • PowerShellを使用して、ListViewTresholdを増やします

5000アイテムの境界には目的があることに注意してください。 2200アイテムのクエリはパフォーマンスを低下させる可能性があり、5000+のクエリではデータベースのテーブルをロックすることさえあります！

ライセンス： CC-BY-SA と 帰属
所属していません sharepoint.stackexchange
scroll top