データベースのパフォーマンスと保守
どもども、ジャナイホーです。
忘れないで下さい。
目をそらさないで下さい。
きちんと最初から、巻き込んで下さい。
データベースのメンテナンスのお話です。
最近急に。。。
どうも最近、、、、
- コントロールルームとかスタジオ画面のレスポンスが悪くなった。
- プロセスが時間どおりに終わらなくなった。
- スケジュールの起動が失敗していることがある。
- ランタイムリソースやリソースプールが不調で未接続に時々なる。
、、、、なんてことはありませんか。
既にカスタマーサポートに問い合わせてるよー、という方もおられるかもしれません。
実際、そんな話を、ほんとうにここ最近、聞く機会が多くなりました。
、、、で、ネットワークやOS環境が変わったなどといった要因も考えられますが、注意して頂きたいのが、データベース＝SQL Serverです。
データベーステーブルの大きさを確認する
長く動かしていると、セッションログが膨れ上がってきます。
ましてや、ログ出力のベストプラクティスを知らずに実装されたプロセスやオブジェクトを実行していると、書き込まれたセッションログが尋常じゃないほどになっていたりすることがあります。
先ずは、現状を確認してみましょう。体重を測ります。
SQL Serverが稼働しているデータベースサーバには、多分、SQL Server Management Studio（SSMS）という、管理画面があると思います。
それを開き、該当のデータベースを開きます。データベース名、ユーザ名、パスワードは、Blue Prismを最初にインストールしてデータベースを構築した際に入力していると思いますので、思い出して下さい（正確には、データベース管理者に聞いて下さい。焼き肉を奢るなどして、教えてもらって下さい。教えてくれないと思いますけど。）
そこで、該当のデータベースを選択し、ポップアップメニューから、
レポート ＞ 標準レポート ＞ 上位のテーブルによるディスク使用量
というレポートを実行します。
そうすると、特にレコード件数や使用率が高い（つまり、サイズが肥大化している）テーブルをリストアップしてくれます。
下記では、BPASessionLog_NonUnicodeというテーブルが大きくなっているのが分かると思います。
これが、数百GBくらいまで膨れ上がっているようだと、それは、ヤバいです。
早いところ手当てしないと、成人病の予備軍です、どころか、病気が出ているはずです。
先に示したようなパフォーマンス劣化、スケジュール失敗、プロセス落ちる、スタジオがもっさりする、ランタイムリソースが繋がらない（というメッセージが出る）、などが発生していると思います。
数十GB程度まで小さくなっている状態まで、先ずはダイエットしましょう。
やることは、簡単です。
トレーニングジムに通うことでも、炭水化物を遮断することでもありません。
アーカイブです。
アーカイブの実施
「アーカイブ」とは、セッションログの情報をローカルPCのファイルに出力して取っておいて、でも、データベーステーブルからは削除する、というものです。
これで、データベーステーブル、先の「BPASessionLog_NonUnicode」とか「BPASessionLog_Unicode」といったテーブルたちが、ダイエットされます。
取り出された脂肪（＝セッションログの内容）は、ちゃんとローカルにファイルとして残っているので、監査目的で、見せてよ、と言われた時も、取り戻すことが出来ます。
「削除」ってやってしまいますと、本当に消えます。気を付けて下さい。
アーカイブは、システム管理者画面で実施します。
緊急を要するような状態の場合は、手っ取り早く、手作業でアーカイブします。
纏めてごそっといきたいところですが、たまりにたまっている、あるいはプロセスの作りや運用がイケてないと、大量のセッションログが対象に含まれ、時間がかかるどころか正常にアーカイブ処理が終了しなかったりします。
地道に、ひとつずつ、あるいは、小さい範囲で、ひたすら地道に、アーカイブしてってください。
こんな、のっぴきならない状態になる前に、ちゃんと、自動モードで定期的にアーカイブする運用をやっとくべきだった、と後悔することしきり、です。
パンクしてからでは遅いです。パフォーマンスが悪いときに大量のものをアーカイブしようッてったんで、ドダイ無理な話ってもんですよ。
手遅れになる前に、目をそらさずに、メンテナンスすること。これ大事です。
あるいは最初からDBに詳しい人を巻き込んでおくこと。これ大事です。
あと、イケてる作りのプロセス・オブジェクト開発を行うこと。これ、非常に大事です。別記事で解説しようと思います。
1週間で尋常じゃないくらい増える、なんてことがあるときは、ログのベストプラクティスを無視した作りになっていること請け合い。プロセス、オブジェクトを修正して、ログ出力を絞りましょう。
食べ過ぎ、飲み過ぎってやつですな。
アーカイブが出来たら、もう一回、データベースでレポートを出して、サイズが小さくなったか確認しましょう。
自動モードでのアーカイブ
毎回、手作業でアーカイブするのも億劫ですよね。
そんなときは、定期的に自動的にアーカイブさせちゃいましょう。
先の画面で「自動モードに変更」というボタンを押します。
デフォルトで、「6」か月過ぎた古いセッションログをアーカイブしてくれます。
この期間は、増え方や監査ポリシーなどに従って決めます。
手作業でアーカイブを少しずつしてみて、どれだけ減るか、なんてのも測定しながら決めるのも良いでしょう。
アーカイブは、実は、AutomateC.exeというコマンドラインプログラムからも実行できたりします。
DB管理者からは重宝がられるかもしれません。
あ、アーカイブした（エクスポートした）先のファイル、これには、センシティブな情報も含まれていることもあると思います。取り扱いには注意して、暗号化するあるいはセキュリティがしっかりと担保されたエリアで保管するようにしましょう。
Blue Prism v6.5以降では、Data Gatewaysという機能もあります。
これを使って、セッションログを外に出してやり、SQL Serverデータベースは細マッチョでキープする、ということも出来ます。
注意しなくてはいけないテーブルは他にも。。。
知らず知らずのうちに、件数やサイズが肥大化する恐れがあるテーブルは、実はセッションログだけではありません。
以下のデータについても、注意が必要です。
- プロセスの履歴
- ワークキュー
- スケジュール履歴
これらを削除するツールも用意されてたりします。これはカスタマーサポートへチケットを起票して問い合わせて下さい。「Housekeeping scripts」というものを出してくれると思います。
注意しなくてはいけないメンテナンス作業は他にも。。。
こういう話をしていると、DB管理者が登場してくると、他にやらなきゃいけないことは？という質問が出てきます。
- フラグメンテーション（断片化）の管理とインデックスの再構築
- 自動統計更新オプションの設定
- データベース整合性チェックの実施
- TempDBの監視
- 自動拡張とディスク容量の監視
などです。
「何をやらなくてはいけないのか」は、以下に纏まってます。
「Maintaining a Blue Prism Database Server」で漁ってみて下さい。
https://portal.blueprism.com/documents/v6-data-sheet-maintaining-blue-prism-database-server-japanese
まとめ
先ず「アーカイブ」しましょう。計画的に行いましょう。
ワークキューやスケジュール履歴など、まめにお手入れしましょう。
データベースを健康に保ち、パフォーマンスをきちんと出す為には、保守作業でやらなくてはならないことが結構あり、どれも重要です。
「スモールスタートで始めたけど、だいぶ範囲も展開も広がってきた。」
「長く使ってきました。」
こういった場合、データベースのメンテナンスを怠っていると、絶対トラブルが出てきます。
先ず間違いなく、ひずみが出てきます。
「ディスクがパンクしました」「プロセスが全部止まって、誰も何も保存できません」というような、分かり易い形で問題は顕在化しません。
大体のケースでは、「スケジュールが動かない」「いくつか上手く動かないものが出てきた」「レスポンスが悪いときがある」「ランタイムリソースが接続できない」など、再現性の難しいエラーが、少しずつ、あるいはあるとき突然、頻発するようになります。
RPAから次の段階へ、デジタルワークフォースへステップアップする際には、データベースの保守運用は適切に行う必要があります。
もちろん、最初の導入段階で、例えスモールスタートであっても、データベースの運用をきちんと設計して導入する、ということがベストプラクティスです。
ロボットを作って稼働させて結果を出したい、だけに目先が行っていると、あとあとで苦労する、典型的な例になります。知らなかったでは済まされません。
きちんとしたデータベースの保守は、トラブルの未然防止に役立ちます。
今からでも遅くはありません。
データベース保守に目を向けて下さい。
きちんと最初から、巻き込んで下さい。
目をそらさないで下さい。
忘れないで下さい。
