2026.06.25
長期稼働している保守システムで発生した性能低下トラブルと解決策について
製造業の現場システムは長期間運用されることが多く、安定稼働しているように見えても、データの蓄積によって、ある日突然性能低下が顕在化することがあります。
本記事では、10年以上稼働している製造現場向けシステムで実際に発生した性能低下トラブルを題材に、原因調査から解決までの過程をご紹介します。
【対象読者】
・長期間運用しているシステムの保守を担当している方
・製造業の情報システム担当者の方
・システムのレスポンス低下や長期運用に伴う保守課題を抱えている方
【この記事で分かること】
・長期稼働システムで発生した性能低下トラブルの実例
・原因特定のために実施した調査内容
・OracleのHWM（ハイウォータマーク）が性能へ与える影響
・再発防止のために実施した運用改善策
【この記事を読むメリット】
・長期間運用しているシステムで発生する性能問題の原因調査の進め方が分かる
・Oracle環境における見落としやすい性能低下要因を把握できる
・保守運用における再発防止策の検討材料として活用できる
はじめに：システムと事例の概略
長期稼働していた製造現場システム
当社は福岡でシステム開発・保守を行っています。
今回登場する保守システムは、弊社が上流工程から下流工程まで担当してフルスクラッチで開発したシステムです。
ASP.NET（.NET Framework）とOracleを組み合わせて構築したWebシステムです。
当システムは、製造現場で稼働するシステムで、主な機能は次の通りです。
・製造時の検査結果の保存
・検査の結果について承認を行うワークフロー（メール送信付き）
・関連するマスタデータのメンテナンス
検査結果を保存するため長期稼働を前提としているシステムですが、いつの間にか10年を越えて稼働するシステムとなっていました。
システムの性能低下トラブル発生
現場から寄せられた性能低下の問い合わせ
ここ数年は大きな改善もトラブルもなく、平穏が続いていた保守メンバーのもとに現場から問合せが入ります。
「一括承認ボタンをクリックすると長時間アイコンが砂時計のままになり、エラーとなってしまい再度作業をやり直す必要がある。エラーにならなかったとしても、ここ最近は待ち時間が長くなっている」
長期稼働しているシステムあるあるトラブル上位に入ると思われる"性能低下トラブル"です。
安定稼働して油断しているときほど、突然舞い込んでくるような気がします。
初期調査で得られた手がかり
当システムの開発当初に関わっていたため、私も原因究明のメンバーとして招集されました。他にも百戦錬磨の先輩方の姿がありました。
保守メンバーから提示された情報は次の通りです。
・複数レコードの項目を更新する処理でタイムアウトが発生する。
・一定件数までは、なんとかエラーにならずに処理が出来る。
・ロジックを変更するような改善や手動でデータを投入するような保守作業は行っていない。
長期稼働しているのでデータ件数がトリガーとなったDBの性能低下トラブルのように見受けられました。
検査結果データは、検査の証左ですから簡単には削除が出来ず、さらに長期稼働で大量データを貯め込んでいると私は予想しました。
SQL調査と臨時対応検討
SQL実行計画の確認
開発当初のテストデータは件数も少なく、実運用とは大きく異なっていました。そのため、実際のデータ量ではSQLの負荷が高くなっているのではないかと考え、実行しているSQLを抽出して実行計画を確認しました。
結果、特に高負荷なSQLは見つからず、私の調査は振り出しに戻りました。
データ退避による性能改善検証
次にデータ件数を減らせば、一時的に性能低下が改善するのではないか？ ということで、5年以上経過している過去の検査結果データを別テーブルに退避してみることになりました。
これで性能低下が改善すれば、一定期間経過したデータは別テーブルに移動し、処理で参照する際は～という流れでしたが、改善しませんでした。
性能低下の原因はHWM（ハイウォータマーク：Oracle）
HWMとは何か
検索サイトで"ハイウォータマーク HWM oracle"とでも入力して検索していただければ、情報がふんだんに出てきますので詳細は省きますが、データベース領域をどこまで使用しているかを管理する機能です。
データベース領域が100GBあり、実際にデータが格納されている領域が50GBでも、HWMが98GBまで伸びている場合は、Oracleは98GBまでを使用済み領域として扱います。そのため、フルテーブルスキャン時には空ブロックも読み込むことになり、不要なディスクI/Oが発生します。
HWMを適切にメンテナンスすれば、不要な領域を読み込む必要がなくなり、レスポンスの改善が期待できます。こうしたディスクI/Oの積み重ねが、処理時間に大きく影響する場合があります。
HWMが性能低下を引き起こした仕組み
"TRUNCATE TABLE"やダンプファイルでデータ移行した時には、ハイウォータマークは再構成されます。
そのため、一定周期で発生するサーバー移行イベントでハイウォータマークが初期化されてレスポンスが改善し、その後じわじわとレスポンスが悪化していく、を繰り返していたようです。
リリース当初よりDBもサイズを増やしていることも要因でしょう。
HWMのメンテナンス
HWM解消のために実施した対策
対応方法は至ってシンプルです。
・テーブルの移動による再作成（ALTER TABLE テーブル名 MOVE [ONLINE]）
・断片化の解消（SHRINK SPACE）
それぞれ実行するための条件などはありますが、SQLを実行することで改善できます。
検証の結果、断片化の解消（SHRINK SPACE）を選択し、実行すると、システムは元のレスポンスを取り戻しました。
1件当たり十数秒必要としていた処理が1件当たり5秒以下というレスポンスになり、性能低下を大幅に改善しました。
再発防止のための運用改善
保守チームは、定期的にハイウォータマークをメンテする仕組みを導入し、今後はハイウォータマークを起因としたトラブルを防ぐように対策を施しました。
振り返ってみると、私が保守しているシステムはSQL Serverで定期的に断片化したインデックスの再構成などを行って、レスポンス低下を防ぐようにメンテナンスを行っていました。
インデックスの断片化＝HWMのように、すぐ紐づけが出来ていればと振り返りがあります。
まとめ・次のアクション
今回の事例から得られた教訓
Oracleに精通している技術者の方であれば、「ハイウォータマーク」は思いつかれる原因かもしれません。弊社は幅広くシステムの保守を行うため、
社員全員が全ての技術に精通しているわけではありません。
しかし、知識や経験豊富な社員が一丸となって問題解決にあたり、お客様へ質の高いサービスを提供することをモットーにしております。
パッケージソフトの導入だけでなく、現場の課題を解決するためのシステムをお求めの製造業の皆さまへ、
エクシーズでは無料で個別相談を承っています。