ファイルメーカーがフリーズした時の対処法とは
ファイルメーカーがフリーズした時はファイルメーカーサーバーの状態をすぐに確認します
ファイルメーカーサーバーの状態をアドミンコンソールですぐに確認する
よく経験したのはユーザーが思いもよらない複雑な検索をしてしまい、処理しきれずサーバーもろとも機能しなくなってしまう状態になります。
速やかに対処しないとホストしているファイルの破損が広範囲にわたってしまうため、ファイル検証に時間がかかり正常稼働まで数時間を要してしまいますのでご注意ください。
ホストしているファイルメーカーのシステムが全体でフリーズした時の対処法
ファイルメーカーサーバーに入る
大概サーバーはリモート操作だと思うので、リモートデスクトップ接続などですぐにサーバーに入る
FileMaker Server Admin Consoleを起動しログインする
恐らく起動させたまままにしていると思いますが念のため。
管理コンソールからクライアントの接続状態を確認する
ここで同一ユーザーが複数表示されていればアウトです。
そういうユーザーは利用できなくなっているファイルメーカーに何度も再接続しログインしています。
まずは全ての接続ユーザーを速やかに切断してください。コメントを入れながら切断すると幾分ユーザーに状態を伝えることができます。
切断しきれないユーザーもいる
これは先ほど説明した通り何度も再接続してきているユーザーです。
これ以上被害を最小限に抑えるために、無理はせず切断していきます。
ファイアーウォールで接続をブロックする
これはかなり重要です。
アプリケーション別にポート許可をしている場合は拒否しましょう。
ファイアーウォール自体無効にしていれば、すぐに有効にしてしまいこれ以上ホストしているファイルを開けないようにします。
開いているデータベースを全て閉じる
データベースをクリックして、全てのデータベースを終了します。
この中にはユーザーが掴んだままのものが含まれていて、終了できないものがあります。
それが破損するファイルとなることが多いので、確認のためメモしておきます。
データベースを停止する
管理コンソールの上部にある赤バツがついたアイコンをクリックして、ファイルメーカーサーバーホスト機能を停止しておきます。
アドミンコンソールを閉じてファイルメーカーサーバーのサービスを落とす
Windows Serverの場合ですが、
- Windowsボタン+R(ファイル名を指定して実行)
- services.mscと入力してEnter
- サービス一覧の中から「FileMaker Server」を探して(一覧内のどれかを選択して「F」を叩くとすぐに飛びます)右クリックから「停止」する
- 落ち切らない場合もある
処理が続いてしまっている場合エラーでサービスが落ちない場合があります。
その際はこれでサービス停止の操作を終わりにする。
あとは開いたサービスのウィンドウを閉じます。
サーバーOSの再起動
OSを再起動するときに、リモートデスクトップ接続からだと「離れた場所にあります」や「シャットダウン理由」を選ばなければいけませんが、急いでいるので適当に選択してすぐにOSを再起動させます。
再起動後、リモートデスクトップ接続する
数分でサーバーOSが起動してくるので再度リモートデスクトップ接続します。
設定にもよりますが、「FileMaker Server」のサービスは「手動」で起動するようにしておく方が、このような障害対応時に便利です。
そして、先ほどの操作同様FileMaker Serverのサービスを起動します。
「Windowsボタン+R」「services.msc」「Enter」「FileMaker Serverを探して」「右クリック」「開始」
これでサービスが開始されます。
FileMaker Server Admin Consoleを開いてログイン
ここもできれば自動でデータベース開始をしないように念のため手動設定しておくことをオススメします。
で手動でデータベース開始をクリックしてファイルメーカーサーバーがホストしているファイルが利用できるようにします。
ファイル破損処理が自動で走る
複数ファイルをホストして公開している場合、それぞれのファイルを自動的に検証してくれます。
どれくらい破損しているかを確認するために、ログビューアーから適宜確認します。
後はサーバーの処理能力に依存した時間が解決してくれる
破損具合やデータベースの大きさ、システム規模にもよりますが、30分以上から数時間かかる場合があります。
その間、ユーザーにはおおよその復旧時間を通知してあげます。
やはりシステムが稼働していないと業務全体がストップしてしまうので必ず行ってください。
ちなみに、その復旧時間の推測は、ログビューアから解析します。
複数ファイルをホストしていると破損具合がそれぞれですので、破損ブロック数と復旧時刻の概算から、メインとなるファイルの時刻を単純に算出していきます。
全てのファイルが検証終了し開始になったら
すぐに公開してはいけません。
まだファイアーウォールを有効なままにしておいてユーザーからは接続できないようにしておきます。
ライセンスに余裕があればサーバーにもFileMaker Proをインストールしておくと、このようにサーバーローカルで破損ファイルの確認ができるので、こちらもオススメします。無理にAdvancedにしなくても大丈夫です。
でサーバーにインストールしてあるFileMaker Proからシステムのメインファイルを開いて、ひと通りユーザー操作をしてみます。
検索、入力、レコード作成等。
レスポンスにも問題が無いことを確認したら、FileMaker Proを閉じて、もう一度OS再起動の準備に入ります。
最終検証のOS再起動手順
- 管理コンソールからデータベースを開いて、開始されているデータベース全てを閉じる
- 画面上部にある赤バツでファイルメーカーサーバーを停止
- 管理コンソールを閉じる
- WindowsのサービスからFileMaker Serverのサービスを停止(操作は先ほど2回書いたので割愛)
- サーバーOSの再起動
OSが再起動されたらFileMakerサーバーを起動させる
こちらも先ほどの手順と同じなので割愛します。
問題なく公開するデータベースが開始されたことを確認して、Windowsファイアーウォールを無効化します。
ファイルメーカーが使えるようになったことをユーザーに通知
通知しないといっこうにログインしないでまだ使えないの？などと避難の嵐になってしまうので。
しばらく管理コンソールでユーザーがログインしてきて問題なく稼働しているか注視しておきます。
ログビューアでログ解析と問題のあった操作の切り分け
このまま終わらせてはいけません。
必ず原因があるので、フリーズしだした時間をユーザーに聞きながらその時間近辺のログをくまなくチェックします。
そうすると特定のユーザーログで異常を発見できるでしょう。
そうしたら、該当ユーザーにどのような操作をしたか聞いてみます。
あくまでも「あなたは悪くありません、システム上過負荷になる要素があったためそれを聞きたいだけです」というスタンスでいきましょう。
そうすると、
- リレーションが多重になっているフィールドの検索
- 計算フィールドと複数フィールドにまたがった条件の検索
- 範囲や不等号を用いた複数条件の検索
などが主な原因とわかってきます。
あとは、そのフィールドを特定しレイアウトモードから対象フィールドの検索無効化をして、障害対応と今後の対策が完了となります。
地道に問題を切り分け解決しながら最大限ファイルメーカーでシステムを運用する
私が運用していてこれらの障害が発生した頻度は年に数回でした。
やはり構築段階では利便性を優先したいていのフィールドは検索対象とするでしょう。
しかし運用していく中でデータ増量や複雑なリレーションなど想定外の状態に陥ってしまいます。
それもまたシステム運用する宿命であることなので、障害発生後どのように対応すれば解決できるかを知っていれば今後も問題無くファイルメーカーでシステム運用が可能になります。
是非とも同じ状態になって困った場合は参考にしてみてください。
