タグ付けされた質問 「waits」



2
ロックを待機しているPostgreSQLのALTER TABLEクエリをキャンセルしても安全ですか?
ALTER TABLE数時間前にクエリを開始しましたpg_stat_activityが、ロックを待機していることが(を介して)最近認識されました。変更したいテーブルをロックしていて、それを手放さない他のクエリを発見しました。 このクエリは(列のデータ型を変更する)「単純な」クエリですが、大規模なテーブルで実行されています。 ロックを保持しているプロセスを強制終了するのではなく、を強制終了することにしましたALTER TABLE。 トランザクションでラップしませんでしたALTER TABLE。 私の理解する限り、クエリがロックを待機しているという事実は、常にロックを待機していて、何も変更していないことを意味します。 これは本当ですか?ALTER TABLEクエリを完全にキャンセルしても安全ですか?または、クエリがすでに何かを変更していて、それをキャンセルすると、データベースが何らかの中間状態になる可能性がありますか? PS:を使用してキャンセルする予定ですSELECT pg_cancel_backend(pid);。これが悪い考えであるなら、私に知らせてください。

2
より良いストレージにアップグレードした後のチェックポイント中の待機の増加
古いオールフラッシュアレイから新しいオールフラッシュアレイ(異なるが、確立されたベンダー)に移行すると、チェックポイント中にSQL Sentryで待機が増えることがわかりました。 バージョン:SQL Server 2012 Sp4 私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2,500で約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。歩哨は私たちをPAGEIOLATCHワティスにもっと向けます。独自の分析を行うと、PAGEIOLATCH and PAGELATCH待機の組み合わせのようです。Perfmonを使用すると、一般に、チェックポイントを行うページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです(主に挿入/更新)。 ストレージベンダーは、ファイバーチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、HBAキューの問題であるとは考えていません。また、ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1 TBに変更せずに増やしました。チェックポイントプロセス中に、2〜4個のコア(16個のうち)が100%に急上昇しますが、全体的なCPUは約20%です。BIOSも高パフォーマンスに設定されています。興味深いことに、CPUがC2スリープ状態になっているのは無効にしたにもかかわらず、通常はC2スリープ状態であるため、スリープ状態がC1を超えた理由を調査しています。 ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部のSPIDが同じページで待機していることもわかります。データベースの設計には、いくつかの挿入ホットスポットがありますが、同じ設計が古いストレージに配置されていました。 このクエリのループを100回実行すると、ディスクとメモリで待機しているSPIDの数を把握できました。 SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100 「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。SIOSデータキーパーを無効にする(これが古いストレージで行われている場合でも)。異なるHBAブランド。 exec sp_Blitz @outputtype = 'markdown' 優先度5:信頼性:-危険なサードパーティモジュール-Sophos Limited-ソフォスのバッファーオーバーラン保護-SOPHOS〜2.DLL-危険と思われるサードパーティモジュールがインストールされています。 優先度200:情報:-クラスターノード-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117がグローバルに有効になります。-トレースフラグ1118がグローバルに有効になります。-トレースフラグ3226がグローバルに有効になります。 優先度200:ライセンス:-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 …

1
UserDB選択の特定のTempDB挿入により、SOS_SCHEDULER_YIELDからENCRYPTION_SCANが返されます。
実稼働システムの1つで、ユーザーデータベースから一時テーブルへの1つの挿入ステートメントに問題が発生しています。挿入/選択をコメントアウトすると、問題のストアドプロシージャがタイムリーに実行されるため、問題の切り分けに自信があります。 問題の挿入/選択のコメントを解除すると、呼び出された一連のストアドプロシージャが基本的に停止して停止します。tempdbやユーザーデータベースで、年齢別の上位トランザクションに何も表示されません。データベースが「静止」しているときに、アクティビティモニターの情報から逸脱するアクティビティモニターに何も表示されません。ただし、CPUは約20%で平坦化されます。 動作は次のとおりです。再生ケースをセットアップして実行すると、問題の挿入/選択に到達すると、SOS_SCHEDULER_YIELDが表示され、ENCRYPTION_SCANが表示されます。約5時間後、ストアドプロシージャの処理が再開され、アクティビティが完了します(すべての個別の操作の周りに、迅速でダーティなログステートメントを配置します)。 また、挿入の選択部分の変数を実行時の値に置き換え、選択クエリ自体を実行したところ、5秒で戻りました。 問題のユーザーデータベースは、tempdbと同様に、暗号化が有効な値としてFALSEを持っています。問題の操作は約6万5千行のデータで発生し、1千行のみで試したところ、動作は持続しましたが、所要時間ははるかに短かったです。 シングルユーザーデータベースは、この動作の唯一のインスタンスです。そのユーザーデータベースのバックアップを介してローカルで再現しました。この問題を示さないソフトウェアのユーザーが約70人います。 上記の情報を踏まえて、私の質問は、ストアドプロシージャの処理が停止するのはなぜですか?正確な答えを期待することはおそらく楽観的であるため、これをデバッグするための正しい手順は何ですか?おそらく、dm_tran_locks、dm_exec_requests、dm_tran_database_transactions、dm_os_schedulers、dm_exec_sessionsなどのDMVの1つに何かがあり、それらは私にいくつかの情報を提供しましたが、解決策を指すような方法で出力を解釈または理解していません。 以下は問題の挿入/選択です: INSERT INTO #TS_EVENT_DATA ( EVENT_FK, EVENT_TYPE_CR_FK, EVENT_ENTITY_CLASS_CR_FK, userDatabase_ID, DATA_NAME_FK, IMPORT_JOB_FK, PRODUCT_STRUCTURE_FK, ORG_ENTITY_STRUCTURE_FK, ENTITY_CLASS_CR_FK, ENTITY_DATA_NAME_FK, ENTITY_STRUCTURE_FK, DATA_SET_FK, DATA_TYPE_CR_FK, ORG_IND, TABLE_NAME, NET_VALUE1_NEW, NET_VALUE2_NEW, NET_VALUE3_NEW, NET_VALUE4_NEW, NET_VALUE5_NEW, NET_VALUE6_NEW, NET_VALUE1_CUR, NET_VALUE2_CUR, NET_VALUE3_CUR, NET_VALUE4_CUR, NET_VALUE5_CUR, NET_VALUE6_CUR, PERCENT_CHANGE1, PERCENT_CHANGE2, PERCENT_CHANGE3, PERCENT_CHANGE4, PERCENT_CHANGE5, PERCENT_CHANGE6, VALUE_UOM_CODE_FK, ASSOC_UOM_CODE_FK, VALUES_SHEET_NAME, UOM_CONVERSION_FACTOR, END_DATE_CUR, …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.