問題タブ [esent]

JetOpenDatabase APIを使用して、ESE データベースを正常に開くことができました。レコードを読み取るために、「MSysObjects」テーブルを開き、現在のインデックスを「RootObjects」に設定しました。

これが私のコードです（エラー処理なし）：

レコードを読み取るために、現在のレコードから複数の列の値を取得するためにJetRetrieveColumns関数を試しました。JetRetrievedColumn関数も試しましたが、実際の結果は得られませんでした。

cpp を使用して、既存のマウントされていない ESE データベース ファイルからレコードを読み取る方法を知っている人はいますか?

ソリューションは、Hyper-V 環境でホストされている Windows Server 2012 R2 Standard VM 上の IIS でホストされている E/F を使用する ASP.NET MVC アプリケーションです。同じ VM が SQL Server 2012 を実行しています。

ホスティング環境は 30 の他のソリューションをホストしており、十分な空きディスク容量があり、ホスティング環境または VM に既知のディスクの問題はありません (VM で chkdsk と sfc が実行され、問題は報告されていません)。

問題は、ソリューション/サーバーが 5 ～ 10 分間の短い時間停止し、ESENT からのイベント ID 508/533 と「C:\Windows\system32\LogFiles\Sum」への書き込みに関するメッセージが表示されるたびに停止することです。

同様のメッセージが sqlsvr で見られましたが、C:\Windows\system32\LogFiles\Sum に対するすべての権限を全員に与えることで解決されました。

問題が解決しない場合は、VM 全体に影響し、リモート デスクトップ経由で接続できなくなることもあります。

問題が発生したときに多数の開いている SQL Server 接続が確認されており、特定の Web API メソッドのキャッシュを導入する前に、実際に SQL Server 接続プールを空にすることができました。念のため、接続プールを 100 から 200 接続に変更しましたが、キャッシュを導入して以来、この特定の問題は発生していません。

すべての DbContext インスタンスは、「使用」、ApiController.Dispose オーバーライド、または Controller.Dispose オーバーライドによって破棄され、1 つの SqlConnection のみが (ログ システム用に) 使用されます。

問題は解決策の外にあり、SQL Server 接続の数が多いのは、SQL Server がディスクに書き込めないという事実に関連していると思われます。

以下は、最近の 3 つの「ブレーク ダウン」に関する Windows イベント ログの抜粋です。問題が発生する前と、サーバーが自動的に復旧した後の Web 要求の数に関する追加情報も含まれています。

助言がありますか？

問題が発生する直前の 10 分間の
Web リクエスト: 1399 サーバーが回復した後の最初の 10 分間の Web リクエスト: 1630

18-03-2015 20:07:20 833 MSSQLSERVER SQL Server で、ファイル [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\] で完了するのに 15 秒以上かかる I/O 要求が 1 回発生しました。データベース [Xxx] 内の MSSQL\DATA\Xxx.mdf] (5)。OS ファイル ハンドルは 0x0000000000000A7C です。最新の長い I/O のオフセット: 0x000003e104e000

18-03-2015 20:07:40 833 MSSQLSERVER SQL Server で、ファイル [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\] で完了するのに 15 秒以上かかる I/O 要求が 1 回発生しました。データベース [Xxx] 内の MSSQL\DATA\Xxx_log.ldf] (5)。OS ファイル ハンドルは 0x0000000000000A8C です。最新の長い I/O のオフセット: 0x0000007f203000

18-03-2015 20:08:16 533 ESENT svchost (1740) 4096 (0x00001000) のオフセット 1806336 (0x00000000001b9000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求バイトが 36 秒間完了していません。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

18-03-2015 20:17:14 508 ESENT svchost (1740) 4096 (0x00001000) のオフセット 1806336 (0x00000000001b9000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求bytes は成功しましたが、OS による処理に異常に長い時間 (36 秒) かかりました。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

問題が発生する直前の 10 分間の
Web リクエスト: 696 サーバーが回復した後の最初の 10 分間の Web リクエスト: 614

19-03-2015 01:17:19 533 ESENT svchost (1740) 4096 (0x00001000) のオフセット 3067904 (0x00000000002ed000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求バイトが 36 秒間完了していません。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

19-03-2015 01:33:02 508 ESENT svchost (1740) 4096 (0x00001000) のオフセット 3067904 (0x00000000002ed000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求bytes は成功しましたが、OS によって処理されるまでに異常に長い時間 (983 秒) かかりました。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

19-03-2015 01:33:03 833 MSSQLSERVER SQL Server で、ファイル [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\] で完了するのに 15 秒以上かかる I/O 要求が 5 回発生しました。データベース [Xxx] 内の MSSQL\DATA\Xxx_log.ldf] (5)。OS ファイル ハンドルは 0x0000000000000A8C です。最新の長い I/O のオフセット: 0x000000a389d000

問題が発生する直前の 10 分間の
Web リクエスト: 555 サーバーが回復した後の最初の 10 分間の Web リクエスト: 784

19-03-2015 03:33:51 833 MSSQLSERVER SQL Server で、ファイル [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\] で完了するのに 15 秒以上かかる I/O 要求が 1 回発生しました。データベース [Xxx] 内の MSSQL\DATA\Xxx_log.ldf] (5)。OS ファイル ハンドルは 0x0000000000000A8C です。最新の長い I/O のオフセット: 0x000000aa95f000

19-03-2015 03:40:48 533 ESENT svchost (1740) 4096 (0x00001000) のオフセット 3846144 (0x00000000003ab000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求バイトが 36 秒間完了していません。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

19-03-2015 03:40:48 833 MSSQLSERVER SQL Server で、ファイル [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\] で完了するのに 15 秒以上かかる I/O 要求が 1 回発生しました。 MSSQL\DATA\MSDBLog.ldf] データベース [msdb] (4)。OS ファイル ハンドルは 0x0000000000000A90 です。最新の長い I/O のオフセット: 0x00000000108000

19-03-2015 03:40:49 508 ESENT svchost (1740) 4096 (0x00001000) のオフセット 3846144 (0x00000000003ab000) にあるファイル「C:\Windows\system32\LogFiles\Sum\Svc.log」への書き込み要求bytes は成功しましたが、OS による処理に異常に長い時間 (36 秒) かかりました。この問題は、ハードウェアの障害が原因である可能性があります。問題を診断するためのサポートが必要な場合は、ハードウェア ベンダーにお問い合わせください。

19-03-2015 03:40:49 17894 MSSQLSERVER ディスパッチャー (0x1a88) ディスパッチャー プール 'XE エンジン メイン ディスパッチャー プール' ワーカー 0x00000000F03B8160 は、ノード 0 で解放されていないようです。概算 CPU 使用: カーネル 0 ミリ秒、ユーザー 0 ミリ秒、間隔: 336140。

マウントされていない EDB ファイルを esent.dll で読み込もうとしています。4k ページのデータベースではすべてが機能しますが、8k ページのデータベースを読み込もうとすると、エラー 1414 が返されます -> セカンダリ インデックスが壊れているため、データベースを最適化する必要があります。しかし、eseutil で最適化しても問題は解決しません。(eseutil は、.edb を作成した同じ Exchange サーバーの bin フォルダーからのものです)

そして、それはデータベースを接続しません..あなたの意見では、何が問題だと思われますか?

ManagedEsent ライブラリを使用して ESE データベース (.edb) を読み込もうとしています。ただし、データベースのセットアップ時にエラーが発生します。エラーは、データベースの接続時 (JetAttachDatabase() の呼び出し時) に発生しているようです。

表示されるエラー メッセージは、「ソフト リカバリはバックアップ データベースを対象としています。代わりに復元を使用する必要があります」です。

以下は私のコードです：

私が得ている例外は次のとおりです。

これを引き起こしている可能性のあるアイデアはありますか？添付している .edb ファイルは無効である可能性がありますか?

のドキュメントでは、セッションはトランザクションを定義する粒度の単位であり、現在開いているテーブル内のカーソルの位置を定義し、現在アクティブなインデックスを定義するJetBeginSessionことに注意してください。1 つのセッションでは、他に何もできません。しかし、彼らは次のことに注意しています。

データベースへの同時実行性と並列アクセスを向上させるために、複数のセッションを開始できます。

それが私が望むものです。データベースへの 2 番目のセッションを開きたいと思います。

バックグラウンド

ESE は、それを実現する方法がやや複雑です。

そして、それはすべてうまくいきます。

しかし、別のセッションを開くにはどうすればよいでしょうか。

ESE のドキュメントは、まばらですが、同じデータベースに対して複数のセッションを実行できることを示唆しています。

• データベースへの同時実行性と並列アクセスを向上させるために、複数のセッションを開始できます。
• JET_bitTableDenyRead- テーブルを別のデータベース セッションで読み取りアクセス用に開くことはできません。(別のセッションによって読み取りアクセスのために開かれる場合があることを意味します)
• JET_bitTableDenyWrite- 別のデータベース セッションによる書き込みアクセス用にテーブルを開くことはできません。(別のセッションによって書き込みアクセス用に開かれる場合があることを意味します)
• JetOpenDatabase- この関数は、同じデータベースに対して複数回呼び出すことができます。
• JET_bitDbExclusive- 1 つのセッションのみがデータベースに接続できるようにします。通常、複数のセッションでデータベースを開くことができます。 (私のものを強調)

単純なアプローチは、別のセッションを開始することです。

JetDetachDatabase2 番目のセッションで への呼び出しがハングすることを除きます。

• のドキュメントを確認してJetDetachDatabaseも何の助けにもなりません。
• を確認すると、JetAttachDatabase気になることがあります。

別のセッションによって既にアタッチされているデータベースをアタッチしようとするとエラーになることを示すエラー コードがあります。

JET_errDatabaseSharingViolation: データベース ファイルは、別のセッションによって既にアタッチされています。

複数のセッションを開く方法は?

だから今はあまりにも無作為に動揺するのではなく、正しい方法を尋ねます.

Extensible Storage Engine で複数のセッションを開始する方法

ボーナス

私はやや無作為に動き回りました。への呼び出しJetDetachDatabaseがハングしている場合は、呼び出さないようにしましょう。文書化された規則に完全に違反しています。

• JetOpenDatabaseJetAttachDatabase最初に電話しなければならないと言う
• JetAttachDatabase私は電話しなければならないと言いますJetDetachDatabase

しかし、それを試してみてください：

そして、実際にそれがうまくいくようです。

...わーい？

RavenDB のストレージの初期サイズを ESENT に設定するオプションがあるかどうかは誰でも知っていますか?
VORON の場合、このサイトによると、Raven/Voron/InitialSize である必要があります。

ありがとう

私はMS ESENT ドキュメントからサンプルを実行しようとしており、別のドキュメントを見つけました。MS サンプルは VC++ 2010 Express でうまくコンパイルされます。ただし、いずれかのプログラムを試すと、次のように文書化されたエラーコード 0f -1216 が表示されます

リカバリの開始時または終了時に未処理のデータベース アタッチメントが検出されましたが、データベースが見つからないか、アタッチメント情報と一致しません。

これは新しい開発であるため、何をする必要があるのか​​ 途方に暮れています。このエラーを見た人はいますか？