これは古い質問ですが、実際に答えた人はいません。質問は次のとおりです。
- MDB での同時読み取りはどのように処理されますか?
- 同時更新/削除は MDB でどのように処理されますか?
- ロックの概念はありますか? .NET アプリでどのように活用できますか?
- MDB ファイルをネットワーク共有に配置することは良い考えですか、それとも恐ろしい考えですか?
最初の 2 つの質問は、基本的に 1 つの説明で答えることができます。ここで重要な注意点が 1 つあります。ここでの回答は Jet MDB (およびその亜種) に固有のものであり、A2007 以降に導入された新しいファイル形式、つまり ACCDB 形式には完全には適用されません。ACE からの Jet ULS の削除の影響を十分に調査したわけではありません。以下のコメントの一部は、ボンネットの下に Jet ULS があると想定している可能性があります。ただし、多くの場合、「LDB ファイル」を「LACCDB ファイル」に置き換えることができ、結果は同じになります。
1-2) 同時読み取り/更新/削除
Jet データベース エンジンは、サーバー上のデータ ファイルの I/O を管理するサーバー側のデーモンが存在しないという点で、"ファイル サーバー" データベースと呼ばれることがよくあります。これは、Jet MDB を使用するすべてのクライアントがファイルを直接読み取っていることを意味します。
もちろん、ファイルへの同時アクセスを処理するためのメカニズムが組み込まれていない場合、これは災害のレシピです。
Jet はレコード ロック ファイルを使用します。MDB が「MyFile.MDB」の場合、レコード ロック ファイルは同じフォルダにあり、「MyFile.LDB」と呼ばれます。LDB ファイルには、どの Jet ULS ユーザーが MDB ファイルを開いているか、そのユーザーが接続しているワークステーションは何か、および同時実行の問題のネゴシエーションに必要なすべての情報が記録されます。
クライアント/サーバー データベース エンジンに慣れている人にとっては、これは原始的で危険に思えるかもしれませんが、Jet データベース エンジンが開発された時点では、その目的は小規模なワークグループ用のデスクトップ データベース エンジンとして使用することでした。は、xBase や Paradox などの他のデスクトップ db エンジンと競合していました。どちらも類似のロック ファイルを使用して、複数のクライアントからのデータ ファイルの同時使用を管理していました。
Jet データベース ファイル内では、ロックはデータ ページ (Jet 4 では 4K に増えましたが、Jet 3.x 以前では 2K でした)、またはデータ テーブルが最初に作成された場合はレコード レベルで適用されます。レコード レベルのロックを使用します。Jet 4 の初期の頃、レコード レベルのロックは非常に遅く、特にペシミスティック ロックを使用すると多くの人が発見したため、多くの Access 開発者はページ レベルのロック以外は何も使用しませんでした (@David Fenton が挙手!)。
実際、楽観的ロックを使用すると、悲観的ロックに伴う並行性の問題のほとんどを回避できます。
いくつかの注意事項:
DAO からは、レコード レベルのロックは使用できず、ページ レベルのロックしか取得できません。
DAO から、楽観的/悲観的ロックを制御するためのオプションが多数あります。特に、OpenRecordset メソッドの LockEdits 引数ですが、これは OpenRecordset Options 引数で指定された特定の設定とも相互作用します (たとえば、Option dbReadOnly は、 LockEdits)。ロックに加えて、一貫性/非一貫性の更新のオプションもあり、これらすべてがトランザクションと対話できます (たとえば、コミットされていないトランザクション内の変更は他のユーザーには表示されないため、競合することはありませんが、関連するテーブルに読み取り専用ロックをかけることができます)。
ADO/OLEDB から、これらの Jet 同時実行制御構造は、ADO/OLEDB にある関連する関数と引数にマップされます。私は Access からのみ Jet を使用するため、DAO を介してのみ対話します。そのため、ADO/OLEDB を使用してこれらを制御する方法についてアドバイスすることはできませんが、Jet データベース エンジンは、アクセス時にレコードのロックを制御できるということです。 (Access UI を使用するのではなく) プログラムで作成する場合は、より複雑になります。
3) ロックと .NET
OLEDB をデータ インターフェイスとして使用する可能性が高いということ以外は、ここでアドバイスを提供することはできません。 OLEDB。ただし、OLEDB はクライアント/サーバー アーキテクチャを中心に設計されており、Jet のファイルベースのロックはエレガントな方法でそれに対応していない可能性があるため、きれいではないかもしれません。
4) ネットワーク共有上の MDB
Jet は、ネットワーク接続のわずかな問題に非常に敏感です。そのため、帯域幅の狭いネットワークでは、低速の接続で開いている Jet データベースの脆弱性が高まる可能性があります。
これは、データベース ファイルの主要なチャンクをローカル コンピューターの RAM に転送して処理する必要があるためです。現在、多くの人が、MDB ファイル全体がワイヤを介してプルされている、またはテーブル全体がワイヤを介してプルされていると誤って主張しています。本当じゃない。代わりに、Jet は最初にインデックスを要求し (そして、クエリを満たすために必要以上に要求しない)、その結果から必要なデータ ページを正確に判断し、それらのページのみをプルします。これは驚くほど効率的で高速です。
また、Jet は非常にインテリジェントなキャッシングを行います。つまり、最初のデータ リクエストには時間がかかる場合がありますが、同じデータに対する後続のリクエストはキャッシングによりほぼ瞬時に発生します。
ここで、テーブルのインデックスを適切に作成していない場合、テーブル全体をプルしてフル テーブル スキャンを実行することになる可能性があります。同様に、Jet の SQL ダイアレクトの一部ではないクライアント側関数に基づいて基準を設定すると、完全なテーブルを取得することになる可能性があります (たとえば、Replace(MyField, "A", "Z") で並べ替えると、全表スキャン)。しかし、そのようなことはクライアント/サーバー アーキテクチャでも非効率になるため、適切にインデックスを作成し、UDF や非 Jet 互換関数の使用に注意するのが常識的なスキーマ設計です。一般に、クライアント/サーバーで効率的な同じことは、Jet でも効率的になります (主な違いは、Jet では、LDB ファイルを再作成するオーバーヘッドを回避するために永続的な接続を使用したほうがよいということです。重要です）。
避けるべきもう 1 つのことは、WiFi 接続を介して Jet データを使用しようとすることです。WiFi の信頼性が低いことは誰もが知っています。それは、WiFi 接続を介して Jet データを操作しようとすると、問題が発生するだけです。
要点:
Web サーバーからデータを提供するためのデータ ストアとして MDB を使用している場合は、データを Web サーバーの RAM のできるだけ近くに配置する必要があります。つまり、可能であれば、物理 Web サーバーに接続されているディスク ボリューム上で。それが不可能な場合は、高速で信頼性の高い LAN 接続が必要です。最近では、データ センター内の GB LAN はかなり一般的であり、そのような接続を介して Jet データを操作するのは非常に快適です。
たとえば、単一の Jet MDB をデータ ストアとして共有する VB.NET デスクトップ アプリを実行する複数のクライアント ワークステーションなど、共有で使用する場合、データ ファイルを信頼できるファイル サーバーに置くことは非常に安全です。可能であれば、Jet MDB ファイルを複数の目的に使用されていないマシンに配置することをお勧めします (たとえば、Exchange、SQL Server を実行し、ファイル サーバーおよびプリント サーバーとして機能しているドメイン コントローラーは最適な場所ではない可能性があります)。 . Exchange のようなアプリは、ファイル サーバーの機能にひどく干渉する可能性があります。また、極端にボリュームが少ない場合を除き、Exchange サーバーとしてマルチタスクを実行しているサーバーに MDB ファイルを配置しないことをお勧めします。
その他の考慮事項:
すべてのユーザーが同じレプリカを使用していない限り、複製されたファイル システムに MDB を配布しようとしないでください。つまり、2 つのサーバー間でファイルをレプリケートしている場合、両方のサーバーから MDB ファイルを編集することは考えないでください。これにより、ファイルがすぐに破損します。
ネイティブの Microsoft SMB ネットワーク経由で提供されるネイティブの Windows ファイル システム以外には、MDB を保存しないことをお勧めします。つまり、Novell も Linux も SAMBA もありません。この主な理由は、他のファイル システムで 100% 複製されていない Windows ファイル システムのいくつかの低レベル ロック機能への Jet からの明らかに低レベル フックがあることです。さて、私はこれに関して非常に保守的であり、多くの有能な Access 開発者が、適切に構成された Novell ファイル サーバーで優れた結果を報告しています (最近では関連性が低くなる可能性がありますが、多くの場合、レコード ロックの調整が必要になります。 Novell がもう存在するかどうかさえ知りません!)、SAMBA を実行する Linux ベースのファイル サーバーで驚異的なパフォーマンスを発揮します。私はこれに慎重であり、それに対してクライアントをお勧めします (これにはさまざまな SAN デバイスが含まれます。
同じ理由で、仮想化されたファイル システムでそれらを実行することは決してありません。しかし、Mac Air で Parallels の下でシングルユーザー Access アプリを数年間実行しているクライアントがいますが、今のところ 1 つの問題も発生していません。ただし、これはシングル ユーザーであるため、ロックの問題は比較的軽微です。
それがあなたの質問に答えているかどうかはわかりません。これはすべて、Access 開発者としての 13 年間の定期的な Jet の使用と、Jet に関する唯一の出版物である Jet データベース エンジン プログラマーズ ガイド (Jet 3.5 のみ) の研究に基づいています。私は実際の引用を提供していませんが、誰かが私が言ったことについて詳細を必要とする場合は、できる限り調査を行います.