none
Microsoft Access Database Engine 2016 を使うと 2016 Server の IIS がクラッシュする RRS feed

  • 質問

  • 環境:

     OS: Windows 2016 Server Standard

     Access Database Engine 2016 (AccessDatabaseEngine_X64.exe)

    上記環境で、Access DBへアクセスする Web アプリ (クラッシック ASP アプリ)でアクセスすると IIS がクラッシュします。

    解決策があれば教えてください。

    Web アプリは Windows Server 2008 R2 + Access Database Engine 2010 で現在全く問題なく動いているアプリです。

    これを今、2016へ移行する作業をしていてこの問題に遭遇しました。

    現象としては、

      DBへのアクセスが遅い

      クラッシュすると方が断然多いが、たまに正常に動くときもある

      ログには、エラーも出ていない。またブラウザにもServiceが動いていないというエラーが出る

      Microsoft OLEDB 12.0 でも 16.0 に変更してで現象は同じ


    同じOS環境で Access Database Engine を 2010 に変えると問題なく動く(アクセスも早い)

    ということで、原因は Access Database Engine ではないかと思っています。

    この問題をフィックスする方法を誰か知りませんか?

    できれば、Access Database Engine も 2016を使いたいと思っています。
    Engineの32bit 版は試していません。

    2019年12月4日 6:28

すべての返信

  • その組み合わせはサポート外では無いでしょうか。2010 であれ 2016 であれ、Access Database Engine を非対話型のサービスとして実行することは想定されていないと認識しています。

    対処療法が無いか探してみたのですが、2016 + IIS で不具合の報告はあったぐらいで、解決策は見当たりませんでした。

    IIS 側でクラッシュするとのことですがユーザーダンプは取得できますか? もしかしたら、そこから調査できるかもしれません。(内容を解析できるだけの知識は求められますし、調査工数をかけて動くようになったとしても、自己責任となりそうですが…)

    2019年12月4日 7:09
  • > その組み合わせはサポート外では無いでしょうか。2010 であれ 2016 であれ、Access Database Engine を非対話型のサービスとして実行することは想定されていないと認識しています。

    前者の記事(ASP.NET に Access を使うのは間違い)はその通りのようですが、後者の記事(Microsoft 2007 Office System Driver と 2010 Access Database Engine をサーバーサイドで使うのは非推奨&サポート外)に ACE プロバイダまで含むかどうかは、以下の記事を見ると、少なくとも技術的にはそうでもなさそうな感じです。

    Microsoft Access 2010 を使用したデータ プログラミング
    https://docs.microsoft.com/ja-jp/previous-versions/office/ff965871(v=office.14)?redirectedfrom=MSDN

    ライセンス的な制約はあるかもしれませんが。


    • 編集済み SurferOnWww 2019年12月4日 8:32 訂正
    2019年12月4日 8:30
  • Microsoft Access 2010 を使用したデータ プログラミング
    https://docs.microsoft.com/ja-jp/previous-versions/office/ff965871(v=office.14)?redirectedfrom=MSDN

    ここで書かれている「Web サービス」というのは、ACE のデータソースとして Web サービスが利用できるという話ではないでしょうか。

    「Web サービス データ接続を作成する」
    https://support.office.com/ja-jp/article/web-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9-%E3%83%87%E3%83%BC%E3%82%BF%E6%8E%A5%E7%B6%9A%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B-5ce2738f-bf36-4490-a015-d1745d102bb8

    「Microsoft Access データベース エンジン 2010 再頒布可能コンポーネント」
    https://www.microsoft.com/ja-jp/download/details.aspx?id=13255

    の「詳細」には

    Access データベース エンジン 2010 再頒布可能コンポーネントは、以下の目的には使用できません。

    4.システム サービスまたはサーバー側プログラム (コードがシステム アカウントの下で実行されるもの、複数のユーザー ID を同時に処理するもの、高度に再入可能で動作が不安定になるもの) による使用。これには、ユーザーがログインしていないときにタスク スケジューラーから実行されるプログラムや、ASP.NET などのサーバー側 Web アプリケーションから呼びだされるプログラム、COM+ サービスの元で実行される分散コンポーネントなどがあります。

    と書いてあります。

    2019年12月4日 13:11
  • > ここで書かれている「Web サービス」というのは、ACE のデータソースとして Web サービスが利用できるという話ではないでしょうか。

    Web サービスはサーバーサイドのアプリです。また、SharePoint は ASP.NET + IIS + SQL Server + SharePoint 独自の拡張です。
    2019年12月4日 14:36
  • それでは、記事のどの部分を見て「少なくとも技術的にはそうでもなさそうな感じ」と思われたのか教えていただけますか?

    私にはそれを見つけられませんでした。

    2019年12月4日 15:16
  • 逆に、あなたが ACE をサーバーサイドでは使えないと思われたのであれば、その理由をお聞きしたいですね。

    あなたが「見つけられませんでした」ということは、少なくとも、あなた自身も良く分からないということでは?

    私は、ライセンス的な制約は置いといて、JET は止めて ACE を使えという Microsoft の文書があると言っています。なので、少なくとも技術的にはそうでもなさそうな感じ」と言ったのですが、あなたは何が引っかかるのですか?

    2019年12月4日 15:32
  • 私がサーバーサイドで使えないと思ったのは、上であげた

    「Microsoft Access データベース エンジン 2010 再頒布可能コンポーネント」
    に書いてある4.の項目です。

    JETはやめて ACE を使えというのは理解できますが、それがサーバーサイドで使ってもOKということに、どう結びつくのでしょうか?


    2019年12月4日 15:50
  • > JETはやめて ACE を使えというのは理解できますが、それがサーバーサイドで使ってもOKということに、どう結びつくのでしょうか?

    OK と断定はしてませんよ。JET は止めて ACE を使えという Microsoft の文書があると言っています。

    なので「少なくとも技術的にはそうでもなさそうな感じ」と言ったのです。私のレスをよく読んでください。因縁を付けられているようで気分が良くないです。
    2019年12月4日 15:58
  • 色々と回答ありがとうございます。

    話が、Engine を使えるかどうかという話に発展しているようですが、最新の Engine を使っていいかは別にして
    私としては、Jet の頃から調査して使い ACE に至るので、使えると思っています。

    それというのも、MSのサポートのドキュメントに Engine/ASP/IIS の話は出てくるからです。
    例えば
    https://docs.microsoft.com/en-us/iis/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/using-classic-asp-with-microsoft-access-databases-on-iis

    https://support.microsoft.com/de-lu/help/300382/how-to-create-a-database-connection-from-an-asp-page-in-iis

    話を戻して、クラッシュの件ですが。
    あれから少し調べてみました。調べたといっても、どこでクラッシュするかコメントアウトしながら試してみました

    どうやら、SQLの Select 文の集合関数, SUMや Count などを使って合計を計算したりしているところでIISがクラッシュしているようです。
    単純にレコードデータを取得するところでは問題ないようです。
    何度も繰り返し試して訳ではないので単純なデータ取得部分は確実に動くという自信はありませんが、
    集合関数でクラッシュするところはまず間違いないと思います。
    たまにこの部分も動くのですが、動いても反応が遅い。

    SQL Server Express を使えばもしかしたら、回避できるのかもしれませんが、改良する時間がありません。

    接続時間やセッション時間などのIISの設定を変えたりしたのですが、まったくダメでした。


    2019年12月5日 6:58
  • 高度に再入可能な処理には使えない、というのはマルチスレッドに対応していないということです。

    「リエントラント」
    https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%A8%E3%83%B3%E3%83%88%E3%83%A9%E3%83%B3%E3%83%88

    とはいえ、対応していないのは、一部の機能でしょう。

    よくやり玉に挙げられるのが winsock の gethostbyname ですが、この関数があるからといって、winsock がマルチスレッドで使われないといったことはありません。

    getaddrinfo を使ったり、呼び出しをシリアル化すれば対応できます。

    どの部分がそうなってるか明確になっていれば対応できますが、私は ACE や JET のどの部分がそうなってるか明確にした資料を見たことがありません。

    明確になっていれば安心して使えるのですけどね。

    2019年12月6日 1:27
  • SQL Server Express を使えばもしかしたら、回避できるのかもしれませんが、改良する時間がありません。

    SQL Server 系などへの移植も検討しておいた方がよいとは思いますが、それは将来の話。今回の移植分についてまでそれを求めるのは工数的にも酷ですよね。

    こちらでも調べてみてはいるのですが、IIS + ACE の組み合わせに関する関連資料はまだ見つけられていません。対 Classic ASP についてとなると、なおさら少ない…。

    先に紹介したクラッシュダンプの件についても、自分は解析できるだけの知識を持ち合わせていないので、具体的な支援はできそうにないのですが、何か追加の情報を見つけたら共有します。

    どうやら、SQLの Select 文の集合関数, SUMや Count などを使って合計を計算したりしているところでIISがクラッシュしているようです。

    On Error Resume Next で捉えられず、アプリケーションプールが停止してしまうような状況なのでしょうか。

    データ件数が多いなど、負荷の高い集計処理だったりしますか?

    また、Windows Update は行われていますか?  IIS 6.0 当時において、Web サーバーで Jet がデッドロックする問題がありました (KB838306)が、その後の Service Pack で修正されたことがありました。

    CursorType は何を設定しておられるでしょうか?

    同じ SQL を実行する *.vbs ファイルを作成して、それをデスクトップで実行してみた場合は動作するけれども、タスク スケジューラーから無人実行した場合はエラーになる…といった「実行アカウントによる違い」は生じますか?

    私としては、Jet の頃から調査して使い ACE に至るので、使えると思っています。

    極端な話、同時接続性能など幾つかの点に目をつぶれば、技術的には CSV を読み書きするような Web アプリを作ることも可能なわけですし、それと同程度以上の意味で mdb や accdb を利用した Web アプリの作成は可能でしょう(用途的にはスタンドアロン環境やイントラネット向け)。高負荷に耐えうる設計ではないので、インターネット公開するような場合は、いろいろと考慮する面はありそうですが。(たとえばサービスのシャットダウン時には、アプリケーションプールの停止前に、接続中の Connection をできるだけ安全に切断するための機能を作りこむ必要があるなど)

    MSのサポートのドキュメントに Engine/ASP/IIS の話は出てくるからです。

    紹介頂いた KB300382 の記事には、2004 年当時に人力翻訳された日本語版が存在しています。

    非推奨・不向きな組み合わせであるとしても、そういうニーズがあることは Microsoft 側でも把握しているはずです。KB278604 (旧番号: Q278604 & JP278604 ) では ASP + JET 3.51 & JET 4.0 に言及されていましたし、サンプルレベルであれば ASP どころか ASP.NET であっても C# + ADODB + mdb な組み合わせが掲載されていますから。

    とはいえ、本来は避けるべき組み合わせであることは間違いないと思います。Jet Database Engine の資料ではありますが、KB299973 や KB299974 には下記の記載があったので紹介しておきます。これを更新した ACE 向けのものがあるかは分かりませんが…。(これらの資料は既に公開されていないようですが、2008年12月版のMSDN Library にて読むことが出来ます)

    • 無制限のユーザー数、24 時間サポート、および ACID トランザクションが必要な場合、マイクロソフトは Internet Information Server (IIS) と共に Microsoft SQL Server を使用することを(強く)お勧めします。
    • ASP では、有効なデータ ソースとして Microsoft Jet データベース エンジンの使用もサポートされます
    • Access ODBC ドライバおよび Microsoft OLE DB Provider for Microsoft Jet は、Web サーバー、コマース サーバー、トランザクション サーバー、メッセージ サーバーなど、高負荷で多くの同時実行を伴う 24 時間稼動のサーバー アプリケーションで使用することは意図されていません
    • IIS 環境で Microsoft Jet を実行する場合、Microsoft Access ODBC ドライバではなく、ネイティブの Jet OLE DB プロバイダを使用することをお勧めします。
    • Microsoft Access ODBC ドライバ (Jet ODBC ドライバ) を使用すると、スレッド セーフではないバージョンの Visual Basic for Applications が呼び出された場合に、安定性の問題が発生する可能性があります。
    • ネイティブの Jet OLE DB プロバイダには、安定性、パフォーマンス、およびスレッド プーリング (スレッド セーフ バージョンの Visual Basic for Applications の呼び出しを含む) に対する修正および機能強化が含まれています
    • ODBC ドライバおよび OLE DB プロバイダは共に、Microsoft Jet データベース エンジンに対するラッパーを提供します。
    • しかし、Microsoft Jet は、24 時間稼動の事例、ACID トランザクション、無制限のユーザー数など、完全なデータ整合性や高度な同時実行が要求される事例で必要になる、高負荷のパフォーマンスを念頭に置いて設計されていません
    • (可能であれば、Web サーバーでの Access データベースの使用は避けてください。)

    2019年12月6日 7:25
  • 色々と考え方はあると思いますが、技術的に(特定の条件下で)利用可能ということと、その製品のベンダーから(その使用方法に対する)サポートが得られるという話は別なので、そこは整理して考えられた方が良いと思います。

    Access Database Engine を(IIS を含む)サービスから呼び出すこと自体は技術的可能ですし、一定の制限(高度な再入が発生しないなど)下で現実的に動作させることも可能でしょう。ただその「制限」についてベンダーからの公式な情報が得られないこと、問題が起きた場合にその原因が「制限」によるものかそうでないかの切り分けを行う必要があること、原因が「制限」であれば実装を変えて(試行錯誤で)制限を回避する必要があること、などは受容する必要があります。

    ここのようなコミュニティで質問をされる場合についても、原因が上記の「制限」である可能性が高そうであれば、まずその点の指摘がされるだけでそれ以上の有益な情報を得るのは難しいことが多いでしょう。

    そういう意味で、Access Database Engine を利用していくのは「茨の道」であることだけは認識された方が良いと思います。

    ※使うなということではなく、使う以上はそれなりの覚悟(手間とお金と時間と根気とやる気)が必要になる場合があるということです。


    Hebikuzure aka Murachi Akira

    2019年12月8日 4:37
  • いろいろとありがとうございます。

    2020/01/14 に現 IIS サーバの 2008 Server を使用できなくなるので焦っています。
    もっと早くと言われそうですが、計画は1年前、インフラ・チームがベースOSを入れたのがついこの間、
    それまで2回催促しましたが何の回答もなし、出来たと連絡があったのがついこの間
    それから私が、日本語化、IIS、Database Engine, Strawberry Perl をあたふたと入れアプリのテストしている次第です。 

    ASPですが、IISがクラッシュする部分では全く使っていません。
    On Error Resume はエラーがあったら暴走しろと言っているようで、気持ち悪いので極力使いたくないし、その場で死んでもらった方がいいから。

    パッチに関してはインフラ・チームが毎月適用しています。
    昔々の導入からこのサーバーは小規模のグループのサーバなので、サポートが楽な共有ベースのAccess を選びました。
    当時は、HW も含めすべて私のサポートでしたが、月日は流れ、HW/OS は私の手を離れました。

    IISの動的コンテンツは動かなくなってユーザからクレームが来た場合は、別の手段 (SQL や ASP.NETなど)でサービスを再開するかを考えます。今は時間がない!

    2008 の移行の時も asp は動かないのでは思い、ASP.NET に移行しようかなとは思いました。
    このときは IISも変わっていて移行に少し苦労しました。
    分かっていたことですが、2016は Index server は動かないし、何か別のIndex Serviceを探すしかないかも。
    MS さん梯子外さないで

    IISの方は、2016 Server + Database Engine 2010 で何とかテストは動いているのでこれで置き換え、
    とりあえず追及することはやめます。

    Perl もエラーをはいているので、こちらも見なくてはいけないので時間ありません。

    このサービスをリリースした当時から、サポートは自力でやるしかないとは思ってサポートしてきました。
    そのため、検索エンジンやフォーラムの方々には大変感謝しています。

    愚痴っぽくなりましたが、Perl が動かないのがちょっとショックだったので。


    2019年12月9日 10:12
  • ダメもとで、IIS クラッシュ時のプロセス ダンプを採取して、それを確認してみては?
    なにかヒントが得られるかも。

    2019年12月10日 1:19
  • 5台のサーバの機能を 2008 から 2016 に移して、去年の暮れに何とかリリースしました。
    ドキュメントは残っていますが。。。

    リリース後もユーザから突然クラッシュするという報告が頻繁にあるので、少し落ち着いたのでクラッシュの原因を簡単に再調査した結果を報告します。

    去年は時間もなく焦っていたので、落ち着いて調査できなかったので、SQL の集合関数の部分でクラッシュしているようだと報告していました。
    今回、少し落ち着いてテストしたところ、どうやら ADOX を使用しているところが原因でクラッシュするようです。
    この部分を ADOX を使わないようにしたところうまく動いています。

    他にも原因はあるかもしれないし、頻度が頻繁ではなくなっただけで、やはりクラッシュするかもしれません。

    引き続き監視モードなので、何かわかったらまた報告します。

    2020年1月16日 9:49