常識は本当に常識なのだろうか?

様々な経験から?とか言うと何か重みを感じてしまう人もいるかも知れませんが、これまで常識だと思っていたことを疑ってみたことはあるでしょうか?

例えば、Dominoの世界ではDB Maintenanceと言えば、決まったようにFixup/Updall/Compactを順番に流していきます。

Webを探すと、昔からのようにこの順序に意味があるように書かれていたりする文献もあるようですが、皆さんご存知の通り、DBが壊れてしまった場合はFixup、View Indexの再構築がUpdall、DBの圧縮がCompactで、それぞれ意味があって実行しているのです。

しかし、世の中では、定期メンテナンスと称して、必ずと言って良いほど、Fixup/Updall/Compactの順序で行われているのではないでしょうか?

今の世の中、大規模Userの場合は、1 Serverに配置されたDBの容量が1TBを超えることなど珍しくはないでしょう。

このような環境でDB Maintenaceを従来通りのやり方でやっていたのでは、DB Maintenanceの為の夜間のBatch Windowがどんどん長くなり、運用に耐えられなくなる現象が出ているのではないでしょうか?

こんな状況でDB Maintenanceすると、Compactだけでも数時間を要するのではないかと思います。

破損文書を残すためにFixup -Nなんかを行うと、2500DB/300GB程度であっても4時間近くかかり、UpdallやCompactも同様に長時間かかってしまい、結局、Maintenanceに10時間とか20時間とかかかってしまっている場合を見かけます。

これがこれまでの常套手段であり常識だとして、そのまま運用を続けると、5年後、10年後にはこのシステムは破たんします。

では、どうすれば良いのか?

それは、常識と思っていることを一旦捨てて、ちゃんと考えてみることです。

通常の運用でFixupはDBが破損しない限り実行する必要はないでしょう。

最新のDominoでは、DBが破損していることが発見されると、Dominoが自動的にFixupを実行します。

唯一、出来ないのが、システム系のDBで、names.nsfや2次Addressbook、Log,nsf、Admin4.nsf、Reports.nsf、Events4.nsf、Busytime.nsf(Clubusy.nsf)、Cldbdir.nsf、Mail.boxなどです。

これらのDBは定期的にServerを停止して、Offlineでfixupを流してやる必要がありますが、これも個別に処理している事例が多いと思います。

Job SchedulerでDominoを停止し、順番に、System DBのMaintenanceを流すという処理を行っている場合が多いのではないでしょうか?

この運用を行っていると、DominoのMaintenanceが必要なDBが追加されてしまうと、Job SchedulerのBatch Jobを直さなければならなくなり、Dominoの運用担当者だけでは対処ができなくなってしまいます。

こんな時に便利なのが、Dominoが提供するIndirect Fileです。

Technoteなどでも紹介されており、ご存知の方も多いと思いますが、File_Name.indというファイルを作成し、その中にMaintenance対象DBを記述しておけば、そのDBを順次Maintenanceしてくれるというものです。

実際のCommandは以下のように行います(Windowsの場合は、最初に"n"を加えてください)。

　fixup <options> File_Name.ind

　compact <options> File_Name.ind

　updall <options> File_Name.ind

設計置換が必要な場合は、

　design -i File_Name.ind

というような形で行います。

Design Taskのみ、ファイル単位の指定をする場合は -f 、Indirect Fileを利用する場合は -iのOption指定が必要です。

これであれば、上記の内容をJob SchedulerのBatch Jobに登録しておけば、後は、Domino担当者がFile_Name.indの内容をMaintenanceするだけでMaintenance対象のSystem DBが変わったとしても対応が出来るのです。

さて、これでSystem DBの定期Maintenanceは出来ましたが、次はUser DBのMaintenanceとなります。

上記に書いたように、User DBはDominoが自動Fixupしますので、Fixupは基本的に必要がありません。

行うべきなのは、Updall -RとCompactでしょう。

従来の常識?からすると、Updall -R/Compactの順番で流すのではないでしょうか?

しかし、基本に戻って考えてみると、この順序で流す意味はどこにあるのでしょうか?

「UpdallでView Indexを再構築してから、CompactするとDBは完全に綺麗な状態にまでCompactが行われる!」

確かにそうかも知れませんが、それにどれ程の意味があるのでしょうか?

Compactを行ってDBを綺麗な状態にしてから、Updallを流した方が処理効率は上がると思われます。

これも、従来から常識と思われている手順を踏むから起こることです。

少し試してみたことがありますが、通常長い時間が掛かっているUpdallがCompact後に流すと、すんなり終わってしまいました。

私の経験上では、Fixup -N/Compact/Updall -Rの順番に流した場合、5:3:1くらいの時間割合で処理が終わることが分かりました。

しかし、皆さん、面倒だからと、CompactやUpdallを単純に流して運用されているのではないでしょうか?

この場合、Updall/Compact TaskはRoot Directoryから順番にDBをMaintenanceしていくことになります。

今のH/W環境を考えると、Domino Serverは、利用しているCPUなど能力の高いCPUを使いこなせず、能力の高いDiskのI/O処理能力も使いこなせず、単に順次処理することにより、多大な時間が掛かってしまうことを経験されているのではないでしょうか?

昔の環境であれば、DominoでもCPUを70%とか使っていたと思いますが、今の環境ではCPUなど数%か20-30%程度の利用率なのではないかと思います。

そういう環境であれば、マルチ処理が非常に有効な手段となります。

Maintenance Taskを全体に対して複数流すことも出来ますが、この際は、同じDB Listから順番に処理するため、競合が起こり、Errorを出しながらMaintenane Taskが行われて行きます。

それでも、時間はかなり短縮されますが好ましいことではありません。

運用として、基本的にDominoのData RootにDBを配置しない設計にされており、Sub FolderにDBが格納されている環境であれば、Sub Folder毎にマルチで流すことにより、より効率的に処理が行えます。

例えば、2500DB/300GBのデータを持つDBがあり、これらが10個のSub Folderに分散配置されていたとしましょう。

これを普通にFixup -Nを順次処理すると、かなりH/W能力の高い環境でも3-4時間かかってしまいます。

では、Sub Folder毎に処理すると、一つのTaskは250DB/30GBの処理を行う訳ですが、結果は40-50分程度で終了するのです。

1/4程度の時間で処理されていることになり、かなりの時間削減になります。

勿論、Sub Folderに分けられていない環境でも先に述べたIndirect Fileを利用するとマルチ処理することは可能になりますが、DBが増えて行く環境ではINDファイルのメンテナンスが面倒になりますので、基本は、Sub Folderを適切に作成して運用するのが現実的だと思います。

上手な運用をするなら、Job Schedulerからは、server -c "load compact <options> File_Name.ind"を発行し、Indirect FileにFolderを記述して、適切な容量、DB数を均等化することでしょう。

常識を考え直してみると、意外と改善は沢山できるということがお分かり頂けたのではないでしょうか?

最後になりますが、Server移行の際は、FTPやOS Copyを使って、Fileを移行するのが当たり前です。

この際のCopyやFTP時間はどうしようもない範疇であり、実際のDominoの移行という観点からすると、無駄な時間かも知れません。

しかし、"過去の事例や実績、常識に基づき"、未だに、Offlineで全てのDB Maintenanceを行わなければならないと思っている方が今でもおられるようです。

こんなことをしたとしたら、土日を使っても1TBを超えるData移行は出来ないことは明らかです。

OfflineでMaintenanceしなければならないのは、一部のSyetem DBだけであり、User DBはOnline Maintenanceで十分なのです。

Onlineであれば容易にマルチ処理が行え、時間は大幅に短縮できるのです。

Offlineが必須なら、DominoはOnline Fixupを自動処理したりしないでしょう。

極稀に、Offlineでしか直せないようなDB破損もありますが、その場合はOfflineでも直らないCaseが殆どであり、今や、Offline MaintenanceはSystem DB以外意味がないと思います。

今の世に中では、停止時間を最小にしながら、適切なMaintenanceを行って移行することが極めて重要であり、更に停止なく移行することが求められてきている訳です。

運用や移行は常識だと思われていることを一旦捨てて、考え直す勇気が無い限り、現在のお客様の要件を満たすことはできないのではないかと思います。