1 | 2 | 3 | 4 | 5 |最初 次ページ >>
July 02, 2016

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

テーマ:Technique
前回紹介した、DBの制限値である64GBを超えてしまったDBの回復方法ですが、必ずしもDBのReplicaやCopyの処理は必要ではないことが分かりました。

冷静に考えてみると当然のことなのですが、DBのReplicaやCopyが可能と言うことは、DBの内部的に持っているIndexを使って設計要素(設計要素もNotes/Dominoにとっては文書です)や文書が読めるということです。

前回も書きましたが、DBを開く際にB-Tree Invalid Errorが発生するのは、あくまでUserが利用するViewが壊れてしまっているために利用出来ない状態に見えるに過ぎないということでしょう。

回復を試みる場合、前回書いたLotusScriptでDebugしながら、db.AllDocumentsのCollectionが取得でき、Collection.CountとCollection内の文書が読めることが確認して、読めているようなら、分割処理を行っても問題はありません。

恐らく、db.AllDocumentsはDB内部で利用するIndexの中から設計要素の文書を除いた物だけを
返しているためだと思われます。

64GBのDBをReplicaしたりCopyしたりするにはかなりの時間がかかることもありますので、先ずは、db.AllDocumentsが取得できるかを試してみてください。

ただ、ここで注意点ですが、DBは壊れている可能性がある訳で、全ての文書が正常な状態で復活できることが保証されている訳ではありません。
あくまで、救える文書は救ってあげるという考え方で使ってください。
 
いいね!した人  |  コメント(0)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
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)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

ブログをはじめる

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

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

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

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

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