SQLSERVERがHOT PAGE問題を解決する一つの考え方はテーブルパーティションを使用する
2675 ワード
SQLSERVERがHOT PAGE問題を解決する一つの考え方はテーブルパーティションを使用する
HOT PAGEって何?
アプリケーションから大量の同時文が同じテーブルに変更または挿入され、テーブルアーキテクチャ設計およびユーザービジネスロジックにより、これらの変更と挿入が同じデータページに集中します.
あるいは数の少ないいくつかのデータページにあります.これらのページはhot page熱力ページとも呼ばれることがある.このようなボトルネックは、通常、同時ユーザが比較的多い典型的なOLTPシステムでのみ発生する.
PAGELATCHについて紹介します.
簡単に言えば、SQLSERVERがメモリにデータを読み込んだ後、データは「ページ」単位で格納され、2人のユーザが同時に変更または挿入したデータが同じページにある場合、
SQLSERVERはページにPAGELATCH(軽量級)ロックを置きます.これらのロックは意向共有ロック、排他ロック、行ロック、キーロックとは異なり、メモリにしか存在しません.
SQLSERVERは、Aユーザがデータページ番号が100のページを変更しようとすると、100のページにPAGELATCHロックを付加し、他のユーザが同時にこのページを変更しないようにする
1つの修正を得る順番で、Aユーザーの修正が終わった後、PAGELATCHはBユーザーの修正のために解放されます.
一般的に次のSQL文のwait_を使用します.type列には、現在どのセッションがPAGELATCHロックの取得を待つ必要があるかが表示されます.
HOTPAGEの紹介が終わり、PAGELATCHの紹介が終わりました.では、このHOTPAGEがもたらすボトルネックと危害は皆さんは知っているでしょう.
知らない?では、皆さんにお話しします.
同時利用者が多数同時に同じデータページにアクセスする場合、SQLSERVERはこのデータページのPAGELATCHのリリースを申請し、
継続的な申請と解放は、SQLSERVERがユーザの挿入または修正要求を処理するのが遅い場合、「ブロック」を引き起こす.
一般的なHOTPAGEでは、次のような状況が発生します.
例えば、株式取引システムがあり、取引ごとにフロー番号が増加し、重複できない取引要求があります.
同じ取引表に保存しなければなりません.新しい取引ごとに、新しいレコードを挿入します.設計者がストリーム番号に集計インデックスを作成する場合(これも自然です)
HOT PAGEのPAGE LATCHリソースのボトルネックに遭遇しやすい.同じ時間に1人のユーザーしか取引を挿入できません
どのようにしてこのボトルネックを緩和することができますか?
(1)最も簡単な方法:IDENTITYフィールド(たとえば、上記のトランザクションフロー番号)に設定しないで、データ列を交換して集計インデックスを作成します.
このように表のデータは他の方法で並べ替えられ、同じ時間の挿入で異なるページに分散する機会があります.
(2)IDENTITYのフィールドに集約インデックスを作成する必要がある場合は、他のデータ列に基づいてテーブルに複数のパーティション(Partition)テーブルパーティションを作成することをお勧めします.
1つのテーブルをいくつかのパーティションに分割することで、新しいデータを受け入れるページの数を増やすことができます.
例:
上の株取引システムを例に挙げます.異なる株は異なる業界に属している.開発者は、株式の業界属性に基づいて、1枚の取引表をいくつかのパーティションに分けることができます.
SQLSERVERでは、パーティション化テーブルの各パーティションは独立したストレージ単位です.異なるパーティションに属するデータ行は、厳密に別々に格納されます.
そのため、同じ時間に発生した取引記録は、他の業界によって異なるパーティションに保存されます.これにより、同じ時点で、異なる業界の
取引記録各パーティションのHOT PAGE(新しいデータ挿入を受け入れるPAGE)はそれほどHOTではありません
だから、自増列に集約インデックスを作成するのは状況次第です.そうしないと、HOTPAGEに遭遇しやすいですよo(∩∩)o
2012-12-27補足
ここで言うと、パーティションは両刃の剣で、パーティション化するとスキャン回数の増加をもたらします.元のテーブルにパーティションがない場合は、スキャンすればいいのですが、今では2つのパーティションに分かれている場合は、2回スキャンしなければなりません.パーティションごとに2回のI/Oが必要です.データがパーティション2の中にあれば、4回のI/Oが必要です.
このような状況はlatch競合状況の一種にすぎない.
SQL ServerのLatch競合のトラブルシューティングと解決
HOT PAGEって何?
アプリケーションから大量の同時文が同じテーブルに変更または挿入され、テーブルアーキテクチャ設計およびユーザービジネスロジックにより、これらの変更と挿入が同じデータページに集中します.
あるいは数の少ないいくつかのデータページにあります.これらのページはhot page熱力ページとも呼ばれることがある.このようなボトルネックは、通常、同時ユーザが比較的多い典型的なOLTPシステムでのみ発生する.
PAGELATCHについて紹介します.
簡単に言えば、SQLSERVERがメモリにデータを読み込んだ後、データは「ページ」単位で格納され、2人のユーザが同時に変更または挿入したデータが同じページにある場合、
SQLSERVERはページにPAGELATCH(軽量級)ロックを置きます.これらのロックは意向共有ロック、排他ロック、行ロック、キーロックとは異なり、メモリにしか存在しません.
SQLSERVERは、Aユーザがデータページ番号が100のページを変更しようとすると、100のページにPAGELATCHロックを付加し、他のユーザが同時にこのページを変更しないようにする
1つの修正を得る順番で、Aユーザーの修正が終わった後、PAGELATCHはBユーザーの修正のために解放されます.
一般的に次のSQL文のwait_を使用します.type列には、現在どのセッションがPAGELATCHロックの取得を待つ必要があるかが表示されます.
1 SELECT * FROM sys.[dm_exec_requests]HOTPAGEの紹介が終わり、PAGELATCHの紹介が終わりました.では、このHOTPAGEがもたらすボトルネックと危害は皆さんは知っているでしょう.
知らない?では、皆さんにお話しします.
同時利用者が多数同時に同じデータページにアクセスする場合、SQLSERVERはこのデータページのPAGELATCHのリリースを申請し、
継続的な申請と解放は、SQLSERVERがユーザの挿入または修正要求を処理するのが遅い場合、「ブロック」を引き起こす.
一般的なHOTPAGEでは、次のような状況が発生します.
例えば、株式取引システムがあり、取引ごとにフロー番号が増加し、重複できない取引要求があります.
同じ取引表に保存しなければなりません.新しい取引ごとに、新しいレコードを挿入します.設計者がストリーム番号に集計インデックスを作成する場合(これも自然です)
HOT PAGEのPAGE LATCHリソースのボトルネックに遭遇しやすい.同じ時間に1人のユーザーしか取引を挿入できません
どのようにしてこのボトルネックを緩和することができますか?
(1)最も簡単な方法:IDENTITYフィールド(たとえば、上記のトランザクションフロー番号)に設定しないで、データ列を交換して集計インデックスを作成します.
このように表のデータは他の方法で並べ替えられ、同じ時間の挿入で異なるページに分散する機会があります.
(2)IDENTITYのフィールドに集約インデックスを作成する必要がある場合は、他のデータ列に基づいてテーブルに複数のパーティション(Partition)テーブルパーティションを作成することをお勧めします.
1つのテーブルをいくつかのパーティションに分割することで、新しいデータを受け入れるページの数を増やすことができます.
例:
上の株取引システムを例に挙げます.異なる株は異なる業界に属している.開発者は、株式の業界属性に基づいて、1枚の取引表をいくつかのパーティションに分けることができます.
SQLSERVERでは、パーティション化テーブルの各パーティションは独立したストレージ単位です.異なるパーティションに属するデータ行は、厳密に別々に格納されます.
そのため、同じ時間に発生した取引記録は、他の業界によって異なるパーティションに保存されます.これにより、同じ時点で、異なる業界の
取引記録各パーティションのHOT PAGE(新しいデータ挿入を受け入れるPAGE)はそれほどHOTではありません
だから、自増列に集約インデックスを作成するのは状況次第です.そうしないと、HOTPAGEに遭遇しやすいですよo(∩∩)o
2012-12-27補足
ここで言うと、パーティションは両刃の剣で、パーティション化するとスキャン回数の増加をもたらします.元のテーブルにパーティションがない場合は、スキャンすればいいのですが、今では2つのパーティションに分かれている場合は、2回スキャンしなければなりません.パーティションごとに2回のI/Oが必要です.データがパーティション2の中にあれば、4回のI/Oが必要です.
このような状況はlatch競合状況の一種にすぎない.
SQL ServerのLatch競合のトラブルシューティングと解決