ND V9 FP8で実装されたNIFNSFを試してみよう! -5- | Lotus Notes/Domino (R) をこよなく愛して。。。。
February 07, 2019

ND V9 FP8で実装されたNIFNSFを試してみよう! -5-

テーマ:Notes/Domino 10.x

<話題の履歴>

ND V9 FP8で実装されたNIFNSFを試してみよう! -4-

ND V9 FP8で実装されたNIFNSFを試してみよう! -3-

ND V9 FP8で実装されたNIFNSFを試してみよう! -2-

ND V9 FP8で実装されたNIFNSFを試してみよう! -1-

 

前回は、NIFNSFのOn/Offに関して、運用面で考えてみました。

今回も、運用の観点で考慮点を考えてみたいと思います。

 

運用していて偶にあることですが、担当者がNDXファイルを削除してしまうということもあるかも知れません。

では、NDXファイルは削除できるのでしょうか?


まず、Domino AdministratorでAll File Typesを選んで表示してみても、NDXファイルはリストされることはありません。

詰まり、Administratorから運用管理している限り、UIから削除することは出来なくなっています。

 

 

しかし、Explorerから削除してしまうこともあるかも知れませんが、Explorerからでも、常にDomino Serverがファイルを開いている状態になっているため、簡単には消すことはできません(これは通常のDBでも同じです)。

消す方法は、Server Consoleからdbc flushを発行して、DB Cacheを無効にしてからExplorerで削除することですが、そこまでする人はいないでしょう。

 

 

当然のことながら、元のDBを削除すると、NDXファイルも同時に削除されます。

 

では、NDXファイルのみ削除されてしまったDBは一体どうなるのでしょうか?

何と、DB自体が無いと言うErrorになり、DBが開けなくなってしまいました。

 

 

NDXファイルのみが削除されると、NIFNSFが有効化されたNSFファイル自体も正常に認識されなくなるということです。

しかし、このまま暫く放置しておくと、Recovery Mangerが自動的に修復してくれますが、修復までには時間が掛かってしまいます(今回の場合は7分近く掛かっています)ので、間違えて削除してしまうようなことが無いように気を付けた方が良さそうです。

 

2019/01/23 21:43:11   Remote console command issued by Administrator/Lotus: dbc f
> dbc f
2019/01/23 21:49:50   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\nifnsf_test\No_Design_nsf.ndx (need new backup for media recovery).

 

つまり、このRecovery機能により、NSFファイルのみBackupしておけば、NSFファイルをServerにOS CopyでRestoreするだけで、NDXファイルも生成されてRecoveryが完了するため、Backup容量が従来より少なくて済むということです。

 

私が試す限りは、OS CopyでRestoreすると、Recovery Managerが瞬時に動き、NSFファイルの修復とNDXファイルの生成を即時に行っているようですが、注意しなければいけないのは、複雑なViewで文書数の多いDBの場合はView IndexのRebuildに時間が掛かり、NDXファイルのRecoveryに時間が掛かると言うことです。

この点を考慮すると、Backupは静止点を確保した上でNSFファイルとNDXファイルの両方をBackupする方が安全ということになり、従来のNSFだけのBackupに比べ容量が肥大化することも考えられます。

また、File単位のBackup/Restoreソフトの性質上、Backupするファイルの数が増えると余計に時間が掛かり、Restoreの手間も増えてしまうと言うことも考慮点となります。

更に、Backup/Restoreソフトで拡張子でBackup対象を決めているような場合は、.ndxの拡張子を追加することも必要になってきます。

また、NIFNSFが有効化されたDBをNotes ClientにLocal Replicaして利用するUserが居るとしたら、本体のNSFが64GBに近い状態になっている場合、Local Replicaが取れなくなることも考慮点になるでしょう。

 

今回の環境では、names.nsfもNIFNSFを有効化しています。

では、Serverを停止して、NDXファイルを削除して立ち上げてみます。

 

Server Start時にRecovery Managerが動作し、NDXファイルを生成していることが分かります。

 

2019/01/23 22:25:40   Recovery Manager: Restart Recovery complete. (0/0 databases needed full/partial recovery)
2019/01/23 22:25:41   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\names_nsf.ndx (need new backup for media recovery).
2019/01/23 22:25:41   Informational, rebuild view needed - collection object cannot be read (reading C:\IBM\Domino\Data\names.nsf view note Title:'($Servers)')

・・・・

2019/01/23 22:26:29   Informational, rebuilding view - no container or index (reading C:\IBM\Domino\Data\names.nsf view note Title:'($Policies)')

 

通常、私の評価環境では正常にStartするまでに30秒弱なのですが、50秒近くかかっています。

実際の環境であればUser文書もGroup文書も数多くありますので、正常に使えるようになるまでに更に時間が掛かると思われます。

NIFNSFという新機能でView Indexを外出ししてViewの更新Performanceの向上などのメリットもありますが、運用を考えると、Backup/Restoreや障害時のRecoveryも十分に考慮した上で実装を検討した方が良いと思います。

 

今回は、Backup/RestoreやRecoveryについて考慮点を考えてみました。

次回は、NIFNSFにより、View Index構築のPerformanceは良くなるのか?を見てみたいと思います。

 

<続く>

 

コメント

[コメントする]

Ameba人気のブログ