問題タブ [snapshot-isolation]

スナップショット分離機能は、大量のサイトでリーダーがライターをロックアウトする問題を解決するのに役立ちます。これは、SqlServer で tempdb を使用して行をバージョン管理することによって行われます。

私の質問は、このスナップショット分離機能を正しく実装することです.SqlServerで次を実行するだけの問題ですか.

次のように、TransactionScope を含むコードも作成する必要がありますか?

最後に、Brent は、この記事の同時実行の隠れたコストのセクションで懸念を指摘しました。この記事では、tempdb で行をバージョン管理する際に、tempdb はスペースが不足する可能性があり、バージョン管理された行を検索する必要があるため、パフォーマンスの問題が発生する可能性があると述べています。私の質問は、このサイトがスナップショット分離を使用していることは知っていますが、他の誰かが大規模なサイトでこの機能を使用していることを知っています。パフォーマンスについてどう思いますか?

ありがとう、レイ。

分離レベル「コミットされたスナップショットの読み取り」でSQLサーバーを使用して、データベースにデータを定期的に書き込み、同じトランザクションのコンテキストでさらに読み取ります。通常、データベースから読み取ると、自分自身のコミットされていない変更が表示されますが、他の人によって行われたコミットされた変更のみが表示されます。これが予想される動作であると想定しました。

比較的まれなケースでは、作成した値が表示されず、以前にコミットされた値のみが表示されることがわかりました。

矛盾を引き起こしている可能性のあるアイデアはありますか？

数日おきに使用できなくなるデータベース（データベースAと呼びましょう）があり、再起動する必要があります。私が使用できないと言うときは、それを使用するすべてのアプリケーションが、データベースが応答するのを待ってそこでブロックするだけですが、決して応答しません。

幸運なことに、SQL Server Management Studioを使用して特定のテーブルに対してSELECTステートメントを実行すると、いくつかのレコードが表示されるように見えますが、ある時点でブロックされます。

面白いのは、特定のデータベースにLOCKEDまたはLOCKINGプロセスがないことです。アプリケーションが次のトランザクション分離を使用していることがわかりました。

LockedまたはLockingプロセスが正しく表示されない理由を説明していますか？

実際には同じスキーマを持つ別のデータベース（データベースBと呼びましょう）があり、この問題は発生していません。これらのデータベースの唯一の違いは、前述の分離です。これはデフォルトのトランザクション分離を使用しており、データベースがブロックされるという奇妙なことは一度もありませんでした。しかし、データベースAには、1日あたりに開かれるトランザクションがはるかに多くあります。はるかに。したがって、私が考えることができるのは、この場合、多数の同時トランザクションではSNAPSHOTISOLATIONを回避する必要があるということです。

誰かが問題を引き起こしているのはSNAPSHOTISOLATIONである可能性が高いことを確認できますか？つまり、ロックはなく、データベースがブロックされているだけで、実際の例外や問題の根本原因を検出するのに役立つものはありません。

私の仮定は正しいですか？きっとそう願っています。

高同時実行環境での使用に問題はありますか? MSが宣伝しているように本当に機能しますか？私は SQL Server 2005 を使用していますが、運用環境で SQL Server 2005 を使用しているアプリケーションで使用している、または使用していた人の経験を聞きたいです。

Firebird/Interbase も開発/管理しているため、スナップショット分離自体は新しいものではありません。明示的なロックがなく、行のバージョン管理ですべてが機能します...

ソフトウェアを開発する際の現在の作業方法には、Windows XP で Visual Studio を実行している vmware 仮想マシン内での開発が含まれます。これは主に、当社のソフトウェアが多くのドライバーをインストールし、システム内のさまざまな領域をフックするためです。そのため、パッケージ全体を実行しているマシンでシステム全体をデバッグするのが最も便利です。特定の制限 (フックが設定されている場所など) により、リモート デバッグは問題外であり、機能しません。

これにより、開発環境全体を仮想マシン内にインストールし、VM で開発およびデバッグすることが強制されます。ご想像のとおり、パフォーマンスは悪く、これは一般的に地獄です (パフォーマンスに関して)。

私が望んでいるのは、vmware のスナップショット メカニズムと同様の機能です。システムがインストールされていなくても、すべての開発ツールを使用して、クリーンなスナップショットを作成できます。ソフトウェアの特定のバージョンをインストールし、そのバージョンのバグ修正/機能に取り組み、コンパイルし、すべてライブ システムで作業します。別のバージョンをインストールする必要がある場合は、保存したスナップショットに戻って、最初からやり直します。

さまざまなポイントでゴースト イメージを作成することでこれを行うことができ、すでにこのアプローチを試しました。しかし、私が探しているのは、それに代わる方法です。スナップショットブードゥーを自動的に実行してくれるもの、使いやすいものですが、vmware ではありません..私のライブマシンをスナップショット可能なものに変えるもの.

これが理にかなっていることを願っています。前もって感謝します。

通常、大規模な SQL Server 2008 テーブルは、SNAPSHOT ISOLATION トランザクションを使用して (比較的) 小さなチャンクで更新されます。チャンクがオーバーラップしないため、スナップショットはこれらの更新に非常に適しています。これらの更新は、長時間実行される単一の操作ではなく、トランザクションによってグループ化された多くの小さな 1 行の挿入/更新です。

優先度の低いトランザクションで、現在ロックされていないすべての行を更新したいと考えています。この動作を取得する方法を知っている人はいますか? 別の SNAPSHOT ISOLATION トランザクションは、行が衝突するとすぐに失敗しますか? それとも、失敗する前に可能な限りすべてを更新しますか?

try SET DEADLOCK_PRIORITY LOW-catch は役に立ちますか? おそらく、WHERE更新されていない行のみを対象とする a を使用した再試行ループでしょうか?

なぜこれが起こるのか、何か考えはありますか？おそらくディレクトリが壊れていますか？私はこれらのファイルを何度もコピーしました。

新しい NoSQL データベース サーバー製品を開発しています。スナップショット分離を使用するクラスター化された B+ ツリーに範囲クエリを実装する方法に関する論文はありますか?

データベースに 2 つのテーブルがあります。それらはアイテムとフィールドです。Item は、ツリーを実装するための自己参照テーブルです。つまり、Item テーブルには、ID 列と ParentId 列があります。このようにして、Item テーブルにツリーを格納できます。フィールドは、アイテムの他の拡張プロパティを格納するテーブルです。フィールド テーブルには、アイテム テーブルを参照するための「Item_ID」という名前の列があります。

OK、今はデータベース操作にトランザクションを追加したいだけです。タイトルの通り、おかしな動作を発見しました。

Microsoft が要求したように、次の SQL を実行して、データベースのスナップショット分離を有効にします。

そして、次のテストを行います：</p>

1. 2 つのテスト プログラムを開く

2. 最初のプログラムは項目 1 を更新し、トランザクションがコミットされる前にブロックされます。

3. 2 番目のプログラムを使用して、アイテム 2 を削除しようとします。アイテム 1 はアイテム 2 と関係がありません。つまり、アイテム 1 はアイテム 2 の親/子ではありません。

4. その後、2 番目のプログラムが最初のプログラムによってブロックされていることがわかりました。最初のプログラムを続行すると、タイムアウトでなければ 2 番目のプログラムが終了します。

この結果に違和感を覚えます。商品1が取引中でも商品2を削除できると思うので。なぜこれが起こるのか誰が知っていますか？

私は現在、さまざまな分離レベルに関して MySQL のパフォーマンスを特徴付ける必要がある学校のプロジェクトに取り組んでいます。READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、および SERIALIZABLE についてテストしました。ここで、スナップショット分離を使用してテストしたいと思います。

InnoDB で REPEATABLE READ のデフォルトを使用する場合、スナップショット分離が併用されることは理解していますが、分離レベルをスナップショット分離のみに設定することは可能ですか? どうすればいいですか？