[第17回] このユーザーは何をしたのか — QueryPieユーザータイムライン

「DBには接続できたが一つの操作ができない」。運用担当はログイン失敗、DB接続問題、特定SQLの遮断をまず切り分ける。

以前に注文参照が成功しUPDATEが止まったDemo AnalystをUser Timelineで探した。一人を軸に接続とSQLを見ると経緯を追いやすかった。

1. ユーザーと期間で活動を探す

Audit → General → User Timelineを開いた。この環境ではメニューに Beta の表示があった。

Demo Analyst、実習日の2026年11月8日、Newest firstを選んだ。Event Sourcesでは対象ログ種別を選べた。

2. ログインとDB利用が同じ一覧に出る

Searchで11件が表示された。ログイン・ログアウト、DB接続・終了、SELECT成功、UPDATE遮断が同じ一覧にあった。

時刻、出所、イベント、結果、ユーザー、IPがあり、複数ログで同じ検索を繰り返さず全体の流れを見られた。

ログイン詳細にはID、メール、17:53:01、IPがあり、正常ログイン後に作業したと確認できた。

3. 遮断された操作を開くと理由も分かる

17:55:27のUPDATEはBLOCKEDだった。Timeline Event DetailsにはRead-OnlyとOrders Control Labが表示された。

下部には実際のSQLとエラー文も残っていた。 No permission to execute UPDATE statementというメッセージから、変更権限不足による遮断だと分かった。

これは存在しない注文-1を条件にした以前のテストだ。QueryPieが遮断し、利用者のエラーと管理者記録が同じ操作を示していた。

4. 直前の正常参照と比較する

直前の17:55:06のSELECTはSuccessで、Web SQLエディターのRead-Only実行だった。

注文3件の参照は成功し、次のUPDATEだけが止まった。DB全体が使えない状況と許可範囲外の操作を区別しやすかった。

5. DB関連だけに絞ると分かりやすい

Event SourcesでDatabasesだけを選び、DB Access History、DB Query Audit、DB Access Control Logsで再検索した。

接続17:54:50、参照成功17:55:06、UPDATE遮断17:55:27、終了18:02:11の4件となり、DB利用の流れが明確になった。

6. ユーザー問い合わせの調査に役立ちそうだ

一人の活動を追うのに便利だった。人と時間を定め、流れを見て、必要なSQLや接続詳細を開き、必要なら種別を減らせばよい。

制御の動作とともに現場の問い合わせへ答えられるかも重要だ。今回は参照成功とRead-Onlyによる変更遮断を同じ流れで確認できた。

誰が何をしたかだけでなく、どこまで成功し、どの操作がなぜ止まったかを確認できる点がよかった。ポリシーを運用し、状況を利用者へ説明する担当者に役立つ画面だった。