June 28, 2016

Notes/Dominoの64GBの限界値を超えてしまったDBの復活?

テーマ:Technique
一時期、IBMがNotes/Dominoの容量は論理的無制限(OSの限界値に依存する)と発表して、その後、上限値は64GBと訂正したのが今では懐かしく思えます。

しかし、世の中では、この上限値である64GBを超えるDBになってしまうこともあるかも知れません。

通常、Userが利用しているDBなら、文書保存時にErrorしたりするのですが、Mail Journalなどは普段は見ないDBですし、Mail Ruleに従い、勝手に容量が膨れ上がっている訳です。
通常のDBでも上限に近くなっていて、滅多に使わないViewを開いた途端に、View Indexが作成されて上限値を超え、View IndexのB-Treeが壊れてしまい開かなくなってしまうこともあるでしょう。

さて、こんな状態になってしまったDBを復活させて、文書を取り出すことは出来るのでしょうか?

それが、何とかなるようなのです。

詳細は解析できていませんが、64GBの上限値を超えたDBをRepliicaすると、何とReplicaが作成できてしまいます。
もしかしたら、Copyでも良いのかも知れませんが、試せていません。

作成したReplicaをNotes Clientで開いてしまうと、Default ViewのIndexが作成されてしまい、View作成中に上限値を超えてしまい、B-Tree Errorが再発すると思われますが、これも、試せてはいません。

とにかく、無事Replicaが作成されたことが確認できれば、そのDBは絶対にNotes Clientから開かないことが重要です。

Replicaの作成とかは通常Notes Clientから開いた場合のようにViewを使ったりしないことから(System側で持っているIndexを使ってCopyしていると思われます)、ViewのB-Tree Errorをすり抜けているように思います。

ここで、全く別の空のDBを作成し、Action Menuから実行できるLotusScriptのAgentを作成し対象文書は無しにして以下のようなCodeを書きます。

Dim ss As New NotesSession
Dim db As NotesDatbase
Dim dc As NotesDocumentCollection
Dim doc As NotesDocument

Set db = ss.GetDatabase("Server_Name","File_Path",False)
Set dc = db.AllDocuments

Print dc.Count

Set doc = dc.GetFirstDocument()

Print doc."Field_Name"(0)

作成後、LotusScript Debuggerを有効にして、このAgentをAction Menuから実行し、Step By Stepで実行して行くと、Document Collectionが正常に取得でき、CollectionのCount値も取れていることが分かりますし、Documentも正常に読めていることが確認できるのです。

ということは、この時点ではDBは壊れていないということです。

ここまで確認が出来たら、DBのDataは復帰可能ということです。

後は、Codeは省略しますが、上記のCodeの後に、While Not(doc Is Nothing)で文書を順番に取得して、別のDBに文書をCopyしてしまえば良いわけです。
勿論、1個のDBにCopyしたのでは、同じことの繰り返しですので、2つのDBに分けてCopyすれば問題はありません。

実際に実験した結果(こういうDBがある環境でしか試せない訳ですが)、問題なくNotes ClientからDBが開け、文書が参照可能な状態になりました。

皆さんも、DBが容量制限を超えてB-Tree Errorで開けなくなった場合、お試しください。

うまく復活できればラッキーというレベルですが、試してみる価値はあるのではないでしょうか?

 
いいね!した人  |  コメント(0)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
June 27, 2016

膨大な容量に膨れあがるMail DBへの対処方法? -9-

テーマ:Technique
<話題の履歴>

膨大な容量に膨れあがるMail DBへの対処方法? -1-
膨大な容量に膨れあがるMail DBへの対処方法? -2-
膨大な容量に膨れあがるMail DBへの対処方法? -3-
膨大な容量に膨れあがるMail DBへの対処方法? -4-
膨大な容量に膨れあがるMail DBへの対処方法? -5-
膨大な容量に膨れあがるMail DBへの対処方法? -6-
膨大な容量に膨れあがるMail DBへの対処方法? -7-
膨大な容量に膨れあがるMail DBへの対処方法? -8-


前回は、Archive Plicyの適用/除外を行い動作の検証を行いました。

今回は、もう少し、Archive PolicyのArchive条件の動きを検証してみます。


というのは、前回の評価では、Archive条件は以下のようになっていました。

Server_Side_Archive_41

ここで気になっていたのが、期間の指定とView/Folderの指定はAnd条件なのか、期間は無視されているのか、ということです。
設定Formの条件の書き方では判断がつきません。

では、この設定を変更して、1日以上経過したものという設定に変更します。

別のUserからArchive対象となっているUserにArchive条件に一致するMailを送信し、Server ConsoleからArchiveを実施します。

> load compact -A mail\
[0AF8:0004-0F24] 2016/06/06 06:41:20 Archiving documents from mail\administ.nsf (Administrator)
[0AF8:0004-0F24] 2016/06/06 06:41:20 Archiving documents from mail\siwama.nsf (Shinya Iwama)
[0AF8:0004-0F24] 2016/06/06 06:41:20 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[0AF8:0004-0F24] 2016/06/06 06:41:20 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[0AF8:0004-0F24] 2016/06/06 06:41:20 Archived mail\siwama.nsf, 0 documents were archived and 0 were deleted
[0AF8:0002-1374] 2016/06/06 06:41:22 Database compactor process shutdown

上記のようにArchiveされている文書はありません。
MailのArchive対象のViewを参照すると、Mailは残ったままになっています。

Server_Side_Archive_42

これで期間設定と、View/Folder条件の設定はAnd条件で効いていることが分かりました。

何故、こんな試験をしてみたかと言うと、Server Sideで自動的にArchiveを行う設定を実装するにあたり、Userによっては、数日はMail DBに残しておいて欲しいという要望もあるのではないかと思ったからです。
特に、e-Mailなどが監査のために上司に送付されるような運用をされている会社の場合、基本は上司が部下が送付したe-Mailを確認する義務がある訳で、直ぐにArchiveしてしまっては、わざわざArchiveを開いて確認する行為はしないのではないかと思われるからです。
Archiveはあくまで後で確認する必要が出た場合のBackup的な意味合いです。
また、直ぐにArciveしてしまったのではUserが削除する時間が無くなってしまうというというのも理由の一つです。

あと、前回評価を忘れていましたが、UserがMail RuleでJunk Mailに分類した場合もArchive対象になるように設定していますので、これも試してみます。

まず、Mail Ruleを設定して、条件に当てはまるMailをJunk Folderに分類するように設定します。

Server_Side_Archive_43

この状態で、別のUserから幾つかのMail(Junk条件に合うもの、Archive条件に合うもの、それ以外のもの)を送信します。

これで以下のように、Archive対象のUserにMailが届きます。

Server_Side_Archive_44

Server_Side_Archive_45

これで、Archive条件設定を、猶予期間なしに設定してServer SideでArchiveを実行します。
結果は以下のようになります。

> load compact -A mail\
[06FC:0004-0EC0] 2016/06/06 21:48:58 Archiving documents from mail\administ.nsf (Administrator)
[06FC:0004-0EC0] 2016/06/06 21:48:58 Archiving documents from mail\siwama.nsf(Shinya Iwama)
[06FC:0004-0EC0] 2016/06/06 21:48:58 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[06FC:0004-0EC0] 2016/06/06 21:48:58 レプリケータは 4 文書を archive\a_siwama.nsf へ mail\siwama.nsf から追加しました
[06FC:0004-0EC0] 2016/06/06 21:48:58 Pushing mail\siwama.nsf to archive\a_siwama.nsf
[06FC:0004-0EC0] 2016/06/06 21:48:58 Archived mail\siwama.nsf, 4 documents were archived and 4 were deleted
[06FC:0002-0F14] 2016/06/06 21:49:00 Database compactor process shutdown

これで、Junkに分類されたMailとCopy Mailと判断されたViewに分類されたMailがArchiveされたことが確認できました。

実際にiNotesから確認しても以下のように期待通りのArchiveが行われています。

Server_Side_Archive_46

Server_Side_Archive_47

これで今回の設定が意図した通りに動くことが分かりました。

Mailが膨れ上がって大変な状態になるような場合には、Server SideのArchiveを活用するのも良いのではないかと思います。

Mailというのは今では無くてはならない存在になっていて、GMailを筆頭にIBM Smart Cloud Notesなど膨大なMail容量を提供するCloud Serviceは増えています。
しかし、CloudのSecurityが心配でIn Houseの運用を続けているUserも多いと思います。

そういうUserを管理するIT部門としては、DominoのServer SideのArchiveを活用するのも一つの解決策かも知れません。

皆さんも、もう一度、自社の環境を考えてみてください。

<終わり>
いいね!した人  |  コメント(0)  |  リブログ(0)
June 24, 2016

DAOS環境でのBackupからのMail復元時の注意点

テーマ:Technique
皆さんの環境でも、添付ファイルの容量削減効果があるからと、DAOS(Domino Attachment Object Store)を利用されている場合もあるのではないかと思います。

昔あったSCOS(Single Copy Object Storeでしたっけ?)も同じような仕組みです。

ファイル容量の削減に貢献し、Diskの節約が出来るのは良いことなのですが、これにより逆に運用が複雑になります。

DAOSに至っては、SCOS時代に比べTransaction Loggingを有効にしなければならないことは皆さんご存知の通りです。

DAOSやSCOSを使わない環境であれば、Backup ToolでBackupされたDBを単純にClientやTest ServerなどにRestoreして、内容を確認することができますが、DAOSやSCOSを使った環境ではそうはいきません。

運用上、良くあるのが、Mail文書を消してしまったので、Backupから元に戻して欲しいというUserの我儘です。
Soft Deletionが有効になっている環境であれば、Defaultで48時間以内であればUserでも元に戻すことが出来るのですが、そういうUserに限って何も考えずにゴミ箱を空にしてしまったりしています。
Mail DBがQuotaに達して、Mailが送信できなくなり、必死でMail DBの整理をしていたのだろうというのは良くわかりますが、作業は落ち着いてやって欲しいものです。
中には、昨日Mailの整理をしていたが、間違えてその日に来た新着Mailを消してしまったから戻して欲しいという要求もありますが、運用で取得しているBackupは夜間に1回なので、当日に当日のMailを削除したのを戻してくれと言われても無理な訳です。

少し話がそれましたが、こういうBackupからMailを戻して欲しいというUserの要望があった場合、通常の環境ならいとも簡単なのですが、DAOS/SCOS環境はそうではないのです。

SCOSは今は使われていないので、DAOS環境に絞ってお話ししましょう。

DAOS環境の場合、Mail DBとDAOSの添付ファイルのフォルダー(File System)は別で、別々にBackupされています。
Mail DBの文書内の添付ファイルは、DAOSに保管されたFileへのPointer情報を持っているだけですので、Mail DBだけをNotes Clientや別のServerにRestoreしても、Mail文書を開く際にDAOSに格納された添付ファイルが参照できないため、文書が開けない状態になるのです。
DAOSに格納されたAttachment Objectが削除されていない前提であれば、元DBのあったServerにRestoreすれば正常に文書が開けます。
DAOSからAttachment Object自体が無くなっていた場合は、もっと面倒なことになります。

では、ここではDAOSにAttachment Objectが残っていた場合(比較的簡単な場合)を考えてみましょう。

BackupからMail DBを元のDBに配置しないと、DAOSに格納されたObjectが参照できない訳ですから、本番のDBとBackupから戻したDBが同一Server上に同居することになります。

賢明な皆さんなら、直ぐに気が付くと思いますが、DominoはDBをReplica IDで同一の物と判断している関係上、同一Server上に同一Replica IDのDBが存在すると何が起こるか分からないのです。
他のServerとReplicaやCluster Replicaを行っている環境では、同じReplica IDのDBがServer上に存在すると、どちらのDBとReplicaするか分からない状態になります。
実際にやってみると分かりますが、OS CopyでServerに戻した後、DominoがそのDBを握り、Replicaを行ったことがReplication Historyから確認できるでしょう。

では、このような場合、どうすれば良いのでしょうか?

先ずは、BackupからDomino配下以外のWork領域にRestoreしたDBをNotes ClientのData領域にOS Copyして、Replication Settingを変更し、一時的にReplicaを禁止する設定を行うことです。
これで、Replicationは行えなくなります。
次に、Notes Clientも環境によってはReplicationをしている場合がありますので、この時点でDesktopのDB ICONやReplica Entryがあれば消してしまい、DB自体をNotes ClientのData Folder以外に退避することです。
そのあとで、このMail DBが元あったServerの本番のMail DBが入ったFolderとは別のFolderにOS Copyで配置します。
この時点で、load fixupでOS Copyで戻したMail DBをFixupしておくのが良いでしょう。
これでやっとServerに戻すことができ、Notes ClientからAccessして必要なMail文書をCopyして本番のMail DBにCopyした後にBackupから戻したMail DBを削除すれば作業が完了する訳です。

DAOSが有効になっていない場合と比べると、かなり煩雑な操作になることがお分かり頂けるでしょう。

更に、これはDAOSが有効な環境に限ったことではありませんが、Soft Deletionが有効になった環境で、Userさんから、数日前に文書を削除したのだが、今日ゴミ箱を空にしてしまったが、必要なMail文書があったので、戻したいという要望があった場合です。
Mail文書を削除した日が分かっていれば、Defaultではその日時から48時間はゴミ箱に残っているハズなので、Mail文書した日の夜間に取得されたBackup FileをRestoreすれば良いわけです。
ところが、文書を削除してからSoft Deletion有効期限(Defaultで48時間)以上経ったMail DBをServerに戻すと、確認するまでにゴミ箱の文書が削除されてしまう可能性が高いです。
これも困る訳ですが、もう1日前を戻せば良いという意見もあるかもしれませんが、削除したMailが削除した日に届いていた場合、ゴミ箱から復活させるしか方法はないのです。
この場合は、BackupをNotes ClientにOS Copyしてから、DB PropertyのSoft Deletionの有効期限を目いっぱい伸ばした後で処理する必要があります。
DAOSが有効な環境では、Backupを戻す先が元のServerに限られるため、DAOSが無効な環境よりも面倒なことになることは確かです。

こうやって考えていくと、Diskを節約しようとかという考えを捨てた方が賢明かも知れない訳です。
今時、Diskはかなり安価になっている訳で、運用を複雑にしてミスを招きかねない運用をすると、運用コストが上がり、人件費が一番高いという状態にもなりかねないのです。

単に目先のことだけを考えず、総合的に考えて機能を導入するかどうかを判断すべきだと思います。
 
いいね!した人  |  コメント(0)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。