誰かがこれらを実験しましたか。これはサポートされていますか?

テーブル値の UDT パラメータを入力として受け取る SQL ストアド プロシージャを Visual Studio 2008 から実行しようとしています。Visual Studio 2008 でこのパラメーターを追加しましたが、このプログラムを実行すると、"ArgumentException - 指定された型がターゲット サーバーに登録されていません" というメッセージが表示されます。だから私はこの問題をグーグルで検索し、Visual Studio 2008 で SQL Server 2008 のこのテーブル タイプのプロパティに一致する新しいクラスを作成する必要があると考えています。しかし、テーブルUDTを含むインターネット上の例は見つかりません。そして、すべてのスカラー UDT の例を試しましたが、これらを変更してテーブルベースにする方法がわかりませんでした。
また、アセンブリを作成する必要があるかもしれないことも読みましたが、これが型を SQL Server 2008 にインポートするためだけに必要なのか、型を Visual Studio にインポートするためにも使用できるのかはわかりません。ところで、データベースとその SP は表示されますが、VS 2008 のサーバー エクスプローラーにはタイプが表示されません。データベースを更新しようとしましたが、タイプはまだ表示されませんでした。私がしなければならないことは簡単です。次のようなテーブルUDTがあります。

そして、私の C# コードのコード スニペットは次のとおりです。

RowsAffected は、これを実行した後に影響を受けた行がゼロであることを示しています。私は何が欠けていますか？この簡単な例を示すウェブサイトを教えてください。それともヒントをくれますか？「param.UdtTypeName="parseInputFile";」も試しました 上記のスニペットの場合、これは同じエラーを返しました。ところで、「myStringArray」は基本的にテーブルです。ストリングスシリーズです。例: myStringArray[0] = "Hello|Bob|How|Do"、myStringArray[1] = "I|Am|Fine|And" など。

SQL Server 2008 BOLのこのページでは、CLR ストアド プロシージャについて説明し、「テーブル値パラメーター」というラベルの付いたセクションがあり、それらがどのように有利であるかについて説明しています。それは素晴らしいことです - CLR proc で TVP を使用したいのですが、残念ながら、これは宇宙でそのような可能性への唯一の参照のようであり、このセクションでは構文がどうなるかについて説明していません (また、詳細な情報もありません)。段落の最後にリンクされています）

確かに、T-SQL プロシージャから TVP を使用する方法や、一般的な CLR プロシージャを実行する方法の説明を簡単に見つけることができます。しかし、TVP を使用する CLR プロシージャを作成するのですか? 何もない。複数行のデータをストアド プロシージャに渡すことは一般的な問題であるため、これはすべて非常に珍しいことです。

これは、そのページのセクションの存在がエラーであるかどうか疑問に思います. 誰かがそうではないことを教えてください。詳細情報/例を教えてください。

[編集]

これに出くわしたとき、私もこれをMSフォーラムの1つに投稿しようとしていました.これは棺桶の最後の釘のようです. それはできないようです。

次のように定義された Dictionary を持つコードがあります。

ディクショナリの各 KeyValuePair の各値は、実際には現在次のように作成されている 3 つの個別の値です。

ご覧のとおり、3 つの値は「|」で区切られています。ディクショナリの「行」数は、600 ～ 1200 の範囲です。テーブル値パラメーターを使用して、SQL Server 2008 DB のすべてを 1 回の操作で取得したいと考えています。

テーブル値パラメーターは次のように定義されます。

ディクショナリからテーブル値のパラメーターに渡すことができるものに到達するための最良の方法は何ですか? 辞書以外のものを使用する必要がありますか? または、ディクショナリを別のより良いデータ構造に解析する必要がありますか?

ありがとう。

私は SQL Server 2008 でテーブル値パラメーターを調査しており、そのようなパラメーターをストアド プロシージャに渡すと、次のようなクエリがデータベース サーバーに送信されることを発見しました。

私の質問は、insert ステートメントがパラメーター化されていないことを考えると、これは SQL インジェクション攻撃に対してどの程度安全かということです。私はそれに対して最も些細な攻撃を試みましたが、引用符は適切にエスケープされましたが、誰かが徹底的なテストを実行しましたか、それとも私を保護する何かがここで起こっていますか?

TVPを右クリックしても、「ALTERTO」のようなオプションが表示されません

スキーマが変更されたため、 SQL Server のコマンドを使用してかなり古いコードを書き直さBULK INSERTなければならなくなりました。代わりに、TVP を使用するストアド プロシージャに切り替えることを検討する必要があるのではないかと思いましたが、どのような影響があるのか​​疑問に思っています。パフォーマンスが低下している可能性があります。

私がこの質問をする理由を説明するのに役立ついくつかの背景情報:

• データは実際には Web サービス経由で入ってきます。Web サービスは、テキスト ファイルをデータベース サーバー上の共有フォルダーに書き込みますBULK INSERT。INSERTこのプロセスはもともと SQL Server 2000 に実装されていましたが、当時はサーバーで数百のステートメントをチャッキングする以外に方法がありませんでした。

• データは、永続的なステージング テーブルに一括挿入されてから、より大きなテーブルにマージされます (その後、ステージング テーブルから削除されます)。

• 挿入するデータの量は「大量」ですが、「巨大」ではありません。通常は数百行で、まれに 5 ～ 10,000 行になることがあります。したがって、私の直感では、BULK INSERTログに記録されていない操作であってもそれほど大きな違いはありません (もちろん、よくわかりませんので、質問です)。

• 挿入は実際には、パイプライン化されたはるかに大規模なバッチ プロセスの一部であり、連続して何度も実行する必要があります。したがって、パフォーマンスは非常に重要です。

BULK INSERTを TVPに置き換えたい理由は次のとおりです。

• NetBIOS を介してテキスト ファイルを書き込むには、おそらくすでに時間がかかり、アーキテクチャの観点からはかなり厄介です。

• 私は、ステージング テーブルはなくすことができる (そしてそうすべき) と信じています。それが存在する主な理由は、挿入されたデータを挿入と同時に他のいくつかの更新に使用する必要があり、ほとんど空のステージングを使用するよりも大規模な本番テーブルから更新を試みる方がはるかにコストがかかるためです。テーブル。TVP では、パラメーターは基本的にステージング テーブルであり、メインの挿入の前後に、必要なことを何でも行うことができます。

• 重複チェック、コードのクリーンアップ、および一括挿入に関連するすべてのオーバーヘッドをほとんどなくすことができました。

• サーバーがこれらのトランザクションのいくつかを一度に取得する場合、ステージング テーブルまたは tempdb でのロックの競合について心配する必要はありません (回避しようとしますが、発生します)。

何かを本番環境に投入する前に、明らかにこれをプロファイリングするつもりですが、すべての時間を費やす前に、最初に周りに尋ねるのは良い考えかもしれないと思いました.この目的で TVP を使用することについて発行する厳しい警告があるかどうかを確認してください.

では、SQL Server 2008 に慣れていて、これを試したり、少なくとも調査したりした人は、どう判断するでしょうか? たとえば、かなり頻繁に発生する数百から数千行の挿入の場合、TVP はマスタードをカットしますか? 一括挿入と比べてパフォーマンスに大きな違いはありますか?

更新: クエスチョン マークが 92% 減少しました。

(別名: テスト結果)

最終結果は、36 段階の展開プロセスのように感じられるものを経て、現在運用中です。両方のソリューションが広範囲にテストされました。

• 共有フォルダーのコードを取り除き、SqlBulkCopyクラスを直接使用します。
• TVP を使用したスト​​アド プロシージャへの切り替え。

読者が正確に何がテストされたかを理解できるように、このデータの信頼性に関する疑問を和らげるために、このインポートプロセスが実際に何をするかについてのより詳細な説明を次に示します。

1. 通常は約 20 ～ 50 データ ポイントの一時的なデータ シーケンスから始めます (ただし、数百になることもあります)。

2. ほとんどデータベースから独立しているクレイジーな処理を大量に実行します。このプロセスは並列化されているため、(1) のシーケンスの約 8 ～ 10 が同時に処理されています。各並列プロセスは、3 つの追加シーケンスを生成します。

3. 3 つのシーケンスすべてと元のシーケンスを取得し、それらをバッチに結合します。

4. 完了した 8 ～ 10 個の処理タスクすべてのバッチを 1 つの大きなスーパーバッチに結合します。

5. BULK INSERT戦略 (次のステップを参照) または TVP 戦略 (ステップ 8 にスキップ)を使用してインポートします。

6. クラスを使用してSqlBulkCopy、スーパーバッチ全体を 4 つの永続的なステージング テーブルにダンプします。

7. (a)いくつかの条件を含む 2 つのテーブルで一連の集計手順を実行しJOIN、(b)MERGE集計データと非集計データの両方を使用して 6 つの運用テーブルで a を実行するストアド プロシージャを実行します。（終了した）

   また

8. DataTableマージするデータを含む 4 つのオブジェクトを生成します。それらの 3 つには、残念ながら ADO.NET TVP で適切にサポートされていない CLR 型が含まれているため、文字列表現として押し込む必要があり、パフォーマンスが少し低下します。

9. TVP をストアド プロシージャにフィードします。ストアド プロシージャは (7) と基本的に同じ処理を行いますが、受信したテーブルを直接使用します。（終了した）

結果はかなり近いものでしたが、データが 1000 行をわずかに超えた場合でも、TVP アプローチは最終的に平均してより良いパフォーマンスを示しました。

このインポート プロセスは何千回も連続して実行されることに注意してください。そのため、すべてのマージを完了するのにかかった時間 (はい、時間) をカウントするだけで、平均時間を簡単に求めることができます。

もともと、平均的なマージは完了するのにほぼ正確に 8 秒かかりました (通常の負荷の下で)。NetBIOS のクラッジを削除してに切り替えるとSqlBulkCopy、時間がほぼ正確に 7 秒に短縮されました。TVP に切り替えると、バッチあたりの時間がさらに5.2 秒に短縮されました。これは、実行時間が時間単位で測定されるプロセスのスループットが35% 向上したことを意味し、まったく悪くありません。また、 よりも ~25% 向上していSqlBulkCopyます。

私は、実際の改善はこれよりもはるかに大きいと確信しています。テスト中に、最終マージがもはやクリティカル パスではないことが明らかになりました。代わりに、すべてのデータ処理を行っていた Web サービスが、受信する要求の数に屈し始めていました。CPU もデータベース I/O も実際には限界に達しておらず、重要なロック アクティビティもありませんでした。場合によっては、連続するマージの間に数秒のアイドル秒のギャップが見られました。わずかなギャップがありましたが、 を使用するとはるかに小さくなりました (0.5 秒程度) SqlBulkCopy。しかし、それは別の日の話になると思います。

結論:テーブル値パラメーターは、BULK INSERT中規模のデータ セットを操作する複雑なインポート + 変換プロセスの操作よりも優れたパフォーマンスを発揮します。

プロステージングテーブルである人々の不安を和らげるために、もう1つのポイントを追加したいと思います. ある意味では、このサービス全体が 1 つの巨大なステージング プロセスです。プロセスのすべてのステップは厳重に監査されるため、特定のマージが失敗した理由を判断するためにステージング テーブルは必要ありません(ただし、実際にはほとんど発生しません)。サービスにデバッグ フラグを設定するだけで、デバッガーが中断されるか、データがデータベースではなくファイルにダンプされます。

言い換えれば、私たちはすでにプロセスについて十分な洞察を持っており、ステージング テーブルの安全性は必要ありません。最初にステージング テーブルを用意した唯一の理由は、他の方法で使用しなければならなかったすべてのINSERTandステートメントでスラッシングを回避することでした。UPDATE元のプロセスでは、ステージング データがステージング テーブルに存在するのはほんの一瞬でした。

また、すべての操作を TVPに置き換えたわけではないことにも注意してください。BULK INSERT大量のデータを処理する操作や、DB にデータを投げる以外に特別なことをする必要がない操作のいくつかは、引き続きSqlBulkCopy. TVP がパフォーマンスの万能薬であることを示唆しているわけではなくSqlBulkCopy、最初のステージングと最終的なマージの間のいくつかの変換を含むこの特定のインスタンスで TVP が成功したことだけを示唆しています。

それで、あなたはそれを持っています。ポイントは、最も関連性の高いリンクを見つけるために TToni に行きますが、他の回答にも感謝します。再度、感謝します！

SQL Server 2008 に、「StoreIDs」というテーブル値パラメーターを持つ「GetPrices」というストアド プロシージャがあります。

これは、この TVP 用に作成したタイプです。

Entity Framework から SP を呼び出したいと思います。しかし、ストアド プロシージャを EDM に追加しようとすると、次のエラーが発生します。

関数 'GetPrices' には、パラメーター インデックス 2 に、サポートされていないデータ型 'table type' を持つパラメーター 'StoreIDs' があります。関数は除外されました。

これの回避策はありますか？何かご意見は？

ファビオ

Visual Studio / SQL Server Management Studio デバッガーを使用して、ストアド プロシージャに渡されたテーブル値パラメーターの内容を検査できるかどうかは誰にもわかりませんか?

簡単な例を挙げると：

exec ステートメントにブレーク ポイントを指定して上記を使用すると、問題なくストアド プロシージャにステップ インできます。デバッガーは、@controllerData ローカルの値が '(table)' であることを示していますが、そのテーブルを構成する行を実際に表示できるツールは見つかりませんでした。

TVPを使用してVB.NETアプリからSQL2008DBにデータを送信し、すべての書き込みをアトミックに保つようにコードを修正しています。

このページを一般的なガイドとして使用する： http ：//www.sqlteam.com/article/sql-server-2008-table-valued-parameters

SQLストアドプロシージャに送信されるすべてのコード内データテーブルを作成中です

ただし、複数のテーブルに対して、これらのデータテーブルとデータ列を繰り返し作成する（次に、テーブルに列を追加する）必要があります。私の場合、これらの各Datatablesは、SQL Serverテーブルと同じレイアウトになります（自動番号PKとGUIDを除く）。

このデータテーブル作成コードを自動生成する方法はありますか？それとも、一般的にもっと速い方法はありますか？

ありがとう