タグ付けされた質問 「service-broker」

1
サービスブローカーはバックアップされ、現在受信中ですが、処理していないようです
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 4年前に移行され ました。 イベント通知に問題がある。メッセージが送信されるマシン/ドライブ/データベース（受信者）では、誰も見ていないときにドライブがいっぱいになったため、1日中バックアップされています。 ドライブのスペースを解放したので、キューへのメッセージを受け入れていますが、メッセージを処理しているようには見えません-キューには現在2,200万のメッセージがあり、成長していますが（！）。キューが有効になっています： is_activation_enabled = 1 is_receive_enabled = 1 is_enqueue_enabled = 1 アクティブ化されたSPはactivation_procedureに表示されますが、SP_WHOISACTIVE、アクティブなリーダーはていません。 ドライブを再び吹き消す前に、何が間違っていますか？メッセージを処理またはフラッシュするにはどうすればよいですか？前もって感謝します。 更新 1つの考え-私が持っているのでis_enqueue_enabled、すべてのメッセージを処理できるまですべてのメッセージを保存しているのでしょうか？もしそうなら、それを安全にオフにできますか？ CREATE PROCEDURE [dbo].[Parse_EN_Messages] AS --mdb 2012/09/05 version 1.2 -- With apologies and thanks to Remus Rusanu, Jonathon Kehayias, Mladen Prajdic, and Jasper Smith for writing -- about EN, answering questions, …
2
無期限のWAITFORを起動すると、ログファイルのサイズが増加しますか？
アプリの前回のリリースでは、Service Brokerキューに何かが到着したときに待機するように指示するコマンドを追加しました。 WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM MyQueue) DBAは、追加以来、ログサイズが屋根を通過したことを教えてくれました。これは正しいですか？それとも私は他の場所を探すべきですか？
1
Sch-M WAITはSQL Server 2014でSch-Sをブロックしますが、SQL Server 2008 R2ではブロックしませんか？
最近、実稼働インスタンスをSQL 2008 R2から新しいSQL 2014サーバーに移行しました。Service Brokerの使用法で明らかになった興味深いシナリオを次に示します。でデータベースを考えてみましょうBroker Enabled = trueとMyServiceしてMyQueue。このキューでは、有害メッセージの処理が無効になっています。キューにメッセージがあるアクティブな会話が2つ以上あります。 1つのプロセス（SPID 100）で実行します。 BEGIN TRANSACTION; DECLARE @conversation_group_id UNIQUEIDENTIFIER; RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue; トランザクションは開いたままにしていることに注意してください。これは、外部リソースで長時間待機している.NETプログラムであると想像してください。経てsys.dm_tran_locks、私たちは、このSPIDがキューにIXロックが付与されていることがわかります。 | type | resource_id | mode | status | spid | | OBJECT | 277576027 | IX | GRANT | 100 | 別のプロセス（SPID 101）で5回実行します。 BEGIN TRANSACTION; …
1
SQL ServerのキャッシュフラッシュとディスクI / O
.NET 4.0で開発したOLTPシステムの負荷テストに忙しく、SQL Server 2008 R2を背後で実行しています。システムはSQL Server Service Brokerキューを使用します。これは非常にパフォーマンスが高いキューですが、処理中に独特の傾向が発生しています。 SQL Serverは、1分の猛烈な速度で要求を処理し、その後、約20秒のディスク書き込みアクティビティが増加します。次のグラフは問題を示しています。 Yellow = Transactions per second Blue = Total CPU usage Red = Sqlsrv Disk Write Bytes/s Green = Sqlsrv Disk Read Bytes/s トラブルシューティング中に、パターンに大きな変更を加えることなく次のことを試みました。 SQL Serverエージェントを停止しました。 実行中の他のほぼすべてのプロセスを強制終了（A / V、SSMS、VS、Windowsエクスプローラーなど） 他のすべてのデータベースを削除しました。 すべての会話タイマーを無効にしました（トリガーは使用しません）。 メッセージキュー主導のアプローチから、シンプル/粗いテーブルモニタリングデザインに移行しました。 軽いものから重いものまで、さまざまな負荷を使用しました。 すべてのデッドロックを修正しました。 SQL Serverがキャッシュを構築し、特定の時間ベースの間隔でディスクに書き込んでいるように見えますが、この理論をサポートするオンラインのものが見つかりません。 次に、ソリューションを専用のテスト環境に移動して、問題を再現できるかどうかを確認します。暫定的な支援をいただければ幸いです。 Update 1 要求に応じて、チェックポイントページ/秒、ページの平均寿命、およびいくつかのディスク遅延カウンターを含むグラフがここにあります。 チェックポイント（水色の線）が、パフォーマンスの低下（黄色の線）の原因であるように見えます。^ …
3
挿入トリガーからPythonスクリプトを起動する
いくつかの電子メールを送信し、クラウドシステムとやり取りするPythonの素晴らしい部分があります。正常に動作します。しかし、dbをポーリングするには、数分ごとに実行する必要があります。ビジネス目的では、Pythonスクリプトをリアルタイムで実行する必要があるため、ポーリングの遅延はありません。（これは、顧客と電話で連絡している営業担当者に提供されます。） 実際には1分のポーリングループは必要ありません。または30秒。レコードをdbに表示して、すぐに何かが起こるようにしたいと思っています。 このフライをすばやく作成するには、特定のレコードタイプがテーブルに挿入されたときにこれを起動します。 トリガーからPythonスクリプトを起動できますか？ 以下のAaronのメモによれば、これはVery Bad Thing™であることがわかりますが、このテーブルはほとんど使用されません（1日に0〜12挿入）。テーブルをポーリングしても、ビジネスニーズを満たすことができません（.pyをすぐに実行する必要があります-電子メールを送信するだけではありません）。 私たちのビジネスニーズを満たす方法は、SQL Serverに.netバージョンのpythonをセットアップし、T-SQLがC＃のものを呼び出す方法でpythonスクリプトを呼び出すようにすることです... しかし、私たちは方法がわかりません実際にこれを行う！（この質問に答えてください）。 ドキュメント/詳細？ Stack Overflowでフォローアップの質問をしました：SQL ServerでPython CLRプロシージャを作成するにはどうすればよいですか？ 質問の下の質問：あなたはPythonの断片を持っています。SQLトリガーから起動したいのですが、それは非常に悪いことです。では、SQL操作の途中でPythonコードを使用せずに同じ効果を実際に達成するにはどうすればよいでしょうか。 このニーズを解決するための非トリガー、非ポーリングのアプローチは何ですか？ （同じ効果=「テーブルで挿入/更新/削除が行われ、テーブルをポーリングせずに、dbイベントの2秒以内にPythonスクリプトがトリガーされます」）
1
Service Broker-会話の有効期間？
ビジネスケースを解決するために、Service Brokerを環境で動作させようとしています。メッセージのタイトルが適切かどうかはわかりませんが、私の質問は以下のとおりです。しかし、それは良い質問ではないかもしれません。そのため、私たちがやっていることと、それが正しい質問だと思う理由がここにあります。 会話を終了する前に、会話でいくつのメッセージを送信する必要がありますか？ 結果テーブルを非同期で更新するために、Service Brokerを使用します。結果テーブルは平坦化され、高速です。ベーステーブルに、テーブルと主キーを含むメッセージを送信するトリガーがあります。3つのキューがあります。 低レイテンシ-目標は処理に15秒です。特定のアイテムに関連して変更されるアイテムを処理します。 一括キュー-目標は5分で処理されます。これは、何百（または何千）ものアイテムに影響を与える何かの変更を処理します。影響を受けたアイテムのリストを分割し、それらを遅延低遅延キューにフィードします 遅延低遅延-目標は30分で処理されます。これはアイテムを処理しますが、バルクキューからのみです。 基本的に、クライアントの情報が更新された場合。これは多くの製品に影響を与えるため、処理を遅くするために一括キューに送信されます。ただし、製品が更新されると、それは低遅延キューに送信されます。 Remus Rusanuのブログhttp://rusanu.com/2007/04/25/reusing-conversations/と同様の会話を再利用しますが、主キーの係数に基づいて行う点が異なります。これには、主キーの重複排除を支援するという副次的な利点があります。 そのため、会話を再利用しており、ガイドラインの範囲内です。2つのスレッドで、125メッセージ/秒（数千のメッセージの人為的な低下）を焼き切ることができました。これは、生産（最大15メッセージ/秒）に追いつくのに十分です。 しかし、私たちが経験している問題は、一定の時間が経過すると、4時間または120Kメッセージの後に、sysdesendとキューテーブルでブロックと高い競合が発生し始めることです。ロックはLCK_M_Uであり、KEYロックです。hobtは、sysdesendに解決される場合もあれば、特定のキューテーブル（queue_）に解決される場合もあります。 24時間または30分の非アクティブ状態の後に会話を終了するプロセスが用意されているため、会話が循環するまでの時間を増やすことができます。 SQL 2016 Enterprise（13.0.4001.0）を使用しています トリガーの発火（低遅延または一括送信） 会話ハンドルを検索または作成します。 メッセージを送る キューがアクティブ化された手順 結果テーブルを更新する クリーンアッププロセスは10分ごとに実行され、アイドル状態の会話がないかどうかを確認します。連続して3回以上見つかった場合は、非アクティブとしてマークし、会話を終了します。 有益かもしれない追加の詳細があるかどうか私に知らせてください。Service Brokerの経験があまりないので、メッセージ/秒が低いか、高いか、無関心かはわかりません。 更新 そのため、本日もう一度試しましたが、同じ問題が発生しました。会話の有効期間を2時間に変更しましたが、影響はありませんでした。そこで、150トリックを実装しました。同じ問題がありました。 SEND CONVERSATIONでの大量の待機、sysdesendでの待機。誰か他のアイデアはありますか？ アップデート2 今日はさらに長い時間テストを実行し、17分のサンプル期間の1つで、4つの会話ハンドルで41Kのメッセージを処理しました。sysdesendとキューテーブルのロックが大きくなりすぎて停止する前にドリフトし始めたときを除いて、最後まで追いつくことができました。メッセージの処理には問題がないようですが、キューに入らない限り、メッセージを取り出して、少なくともその5倍の速度で処理できます。メッセージの追加に基づいて速度が制限されているようです。 後のテストで、メッセージの80％を占めるトリガーの1つを削除しました。このように負荷が大幅に軽減された場合でも、同じ待機が発生し始めました。 アップデート3 Remusからアドバイスをいただきありがとうございます（この件に関して優れたブログ記事を投稿していただき、ありがとうございました。この点に到達するために役立ちました）。 私たちは今日それをもう一度実行し、より良い結果を出しました（待機を見る前にさらに長くなり、それが私たちを不自由にする前にさらに長くなりました）。だから、詳細。 変更：*スレッドごとに維持される会話の数を1：1から2：1に増やしました。基本的に、4つのスレッドに対して8つの会話ハンドルがありました。 バルクキューを統合し（1つの受信メッセージが数百の送信メッセージを意味する可能性があるため）、少数の大きなメッセージに統合しました。 この試みに関するメモ： ターゲットキューのアクティブ化手順を無効にします。ブロッキングに変更はなく（5分間待機）、メッセージはsys.transmission_queuesに送信されました。 sys.conversation_endpointsのモニタリング。この数は0から13,000まで急速に増加し、その後、1日を通してゆっくりと増加し、約5時間後には約25Kに達しました。ブロックは、16K +/-に達するまで発生しませんでした 私はDACに入り、キューに対してDBREINDEXコマンドを実行しましたが、クエリから、ゴーストレコードが200を超えることはなく、クリーンアップが行われてカウントが0になりました。 テストを終了したとき、sysdesendとsysdercvのカウントは24,932でした。 5時間で〜310Kのメッセージを処理しました。 物事がバラバラになるずっと前に行ったので、今度はそれを作ると本当に思った。明日は、メッセージを強制的に送信してみます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.