Domino Document Deletion Logging: How to Solve for Missing Documents の翻訳版です。
HCL Domino の文書削除ログ: 見つからない文書を解決する方法
2020年8月19日
著者: Jessie Jeffrey Matias / HCL
Domino の管理者として、あなたはユーザーから「この特定のメールはどこにあるのか!」と聞かれたことがあるかもしれません。Domino の古いバージョンでは、複数のユーザーが使用しているアプリケーションで重要な文書が消えてしまい、誰が、何を、いつ、どのようにして特定の文書が削除されたのかを特定する方法がない場合、長年の問題となっていました。もう心配ありません。Domino 文書の削除ロギングは、Domino V10から利用可能になった機能です。 彼らが探している文書に何が起こったのかを説明することができるようになりました。
では、どのように実装すればいいのでしょうか?それは、文字通りデータベース上でコンパクトタスクを実行するのと同じくらい簡単です。新しいコンパクトタスクのオプションで、指定したデータベースに削除された文書に関するデータをロギングできるようになります。このような機能を実現するために必要な主な要件は以下の通りです。
Domino V10以上を使用していること。
トランザクションのロギングが有効になっていること。
監視するデータベースに対して compact タスクを実行する。
load compact <データベースパス> -dl on "<項目のカンマ区切りリスト>"
ここで、<データベースパス>は、特定のデータベースまたはデータベースのディレクトリで、データディレクトリからの相対的なもの、例えば mail や discussion.nsf などです。
<カンマで区切られた項目のリスト> は、削除された文書を識別するのに役立つログに表示するフィールドのリストです。フィールドは、以下のタイプのいずれかでなければなりません。Text、Text_List、RFC822_Text、または Time のいずれかでなければなりません。メール文書に推奨されるフィールドは、Subject、SendTo、From、および DeliveredDate です。文書にカスタムフィールドがある場合は、それらも使用できます。
データは delete.log という削除ログファイルに記録され、サーバーの Data ディレクトリ、IBM_TECHNICAL_SUPPORT フォルダの下にあります。データベースから文書が削除されると、そのファイルにエントリが追加されます。
サーバーが再起動されると、新しい削除ログ ファイルが作成されます。古い削除ログ・ファイルは delete_<サーバ名>_yyyy_mm_dd@hh_mm_ss.log に名前が変更されます。例: delete_Server1\Renovations_2020_01_10@06_28_45.log
データベースから文書を削除すると、現在の削除ログファイルに次のデータのエントリが追加されます。このデータは、CSV 互換の形式で提供されます。
削除ログエントリのデータ一覧
文書を削除した日時
文書が削除されたデータベース: データ ディレクトリの相対値
データベースのレプリカ ID: データベース名がすべてのサーバーで同じではない場合に、データベースの複数のレプリカをログから見つけるのに役立ちます。
削除を行ったプロセス: 例:
文書を削除したサーバー名またはユーザー名
文書削除の種類
削除された文書のクラス: 以下のいずれかの 16 進数で指定します。
UNID: レプリカ間での一意の文書識別子
アイテム: 削除された文書のフィールド値を最大4つまで指定して、識別に役立てることができます。削除ログを有効にしたときに指定します。4 つ以上のフィールド値を指定できますが、最初に見つかった 4 つのフィールド値のみがログ エントリに表示されます。各項目には、項目名、項目値の長さ、項目値の最初の 400 文字の 3 つの部分があります。
データベース上での文書削除を監視する必要がなくなった場合は、次のコマンドを実行します。
この機能を使用する際の注意点は以下の通りです。
コンパクトコマンドを入力する際に、カンマで区切られた項目のリスト内にスペースを入れないこと。
正: load compact mail/admin.nsf -dl on "SendTo,From,DeliveredDate"
誤: load compact mail/admin.nsf -dl on "SendTo, From, DeliveredDate"
コマンド入力時にカンマ区切りで 4 件以上の項目を入力することができますが、削除ログファイルにはカンマ区切りの4件のみが記録されます。ただし、削除ログファイルに記録されるのはカンマ区切りの4項目のリストのみです。
詳細についてはこちらをご覧ください。
HCL Notes/Domino のライセンスに関してはガイドを公開していますが、HCL Complete Collaboration (Bundle) (CCB) のゲストライセンスについての、英語版ブログの解説記事 Licensing Update: HCL Complete Collaboration (CCB) Guest Licensing の翻訳版を掲載します。
ライセンス最新情報:HCL Complete Collaboration (Bundle) (CCB) のゲストライセンス
2020年7月29日
著者: Uffe Sorensen / Global Director of DS Strategy, HCL Software
翻訳注記: 正式な名称は HCL Domino Complete Collaboration です。各種製品・機能の利用権が含まれているため Bundle を末尾に付けて、通称として CCB としています。
2019年7月以降、HCL ではモダンなライセンスを導入し、すべての製品のライセンス管理を容易にし、お客様やビジネスパートナーをご支援することが HCL Digital Solutions の使命となっています。
今、私たちは Domino のすべてのライセンスを「ユーザー単位」のライセンスモデルに統一化するための次の一歩を踏み出しました。"HCL Domino Complete Collaboration" (Bundle)、通称 "CCB" です。
そして、これは直ちに有効な内容ですが、CCB ユーザー権限の下でデプロイされた HCL Domino サーバーは、その「CCB ユーザー」と「ゲストユーザー」の双方がアクセスを許諾されます。
「ゲスト・ユーザー」とは、匿名のウェブ・ユーザー (認証なし)、または Domino アプリケーション・アクセス・レベル (ACL) で「投稿者」を上限として事前定義されたアプリケーションにアクセスする認証済み Web ユーザーとなります。
さらに、CCB の下にある HCL Domino サーバーでは、メールルーティング (SMTP)、HCL Domino 以外のプログラムのために使用される LDAP ディレクトリ (参照および認証) が使用できます。また、CCB ユーザーのカレンダーの空き時間情報へのアクセスが許可されます。
HCLは、お客様のご要望に基づき、CCBライセンスに以下の変更を加えました。
8月に、HCLはここに掲載されている正式なライセンス情報を更新する予定です。それまでの間は、このブログを参照していただくか、コンプライアンスのための正式な製品通知を要求することができます。
この発表についてご質問がある場合、またはライセンスに関するご質問がある場合は、HCLの製品スペシャリストまたはビジネスパートナーにお問い合わせください。
Uffe Sorensen & the Domino Product Team
免責事項 - HCLの計画、方向性、意図に関する記述は、HCLの独自の判断により、予告なく変更または中止されることがあります。将来の可能性のある製品に関する情報は、当社の一般的な製品の方向性を示すものであり、ご購入の際には、これらの情報に依拠して判断されるべきではありません。将来の可能性のある製品に関する情報は、いかなる材料、コード、機能を提供することを約束、約束、法的義務を負うものではありません。将来の可能性のある製品に関する情報は、いかなる契約にも組み込まれない可能性があります。当社製品に記載されている将来の機能や機能の開発、リリース、タイミングは、当社の単独の裁量に委ねられています。性能は、制御された環境での標準的な HCL ベンチマークを使用した測定および予測に基づいています。ユーザーが体験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリーム内のマルチ・プログラミングの量、I/O構成、ストレージ構成、処理されるワークロードなどの考慮事項を含む多くの要因によって変化します。したがって、個々のユーザーがここに記載されている結果と同様の結果を達成することを保証するものではありません。
HCL Notes/Domino には MarvelClient Essentials (無償版) が付属しており、Notes クライアントの構成管理やバージョンアップの実行管理が可能です。HCL Nomad にも MarvelClient Essentials (無償版) が備わっており構成管理が可能です。
MarvelClient Essentials (無償版) を使った HCL Nomad の設定管理の方法を解説した資料を公開しました。
原題は Going Inline with Domino Views という記事です。「Domino ビューにはインラインだよ」というニュアンスだと思います。別のニュアンスも感じ取れますが、自分はネイティブではないので確信はありません。内容的にはビューのインライン更新機能についてです。
Domino ビューのインライン更新機能
2020年7月23日
著者: John Curtis / Domino Core Application Team Lead
私は長年にわたって Notes Indexing Facility (NIF) の奥深くで作業をしてきました。初期の Domino 開発者が最初の日からしっかりとバンドルされた豊富な機能からは、まだまだやるべきことがあり、収穫するべきことがあるからです。非常に多くの多様なデータがコードを通ってガラスの上に流れてくるので、これは挑戦的な領域である可能性があります。注意を怠ると、あるユーザーのストーリーを喜ばせる一方で、別のユーザーのストーリーはそれほどでもないものになってしまいます。
NIF で最も問題となる操作の1つは、更新の処理です。誰かが「じゃあ、何が問題なの?他のデータベース製品はインデックスの更新に問題はありませんが、Dominoはなぜ違うのでしょうか?Dominoはなぜ違うのでしょうか?その答えは、Designer でのビューやフォルダの作成の容易さにあります。ビューは常に数と複雑さを増していくというのはよくある話です。
そこで、私はよくこのように違いの質問に答えます。「あなたがMySQLやOracle、DB2やMongoDBの管理者のところに行って、データベースに 200~1000 個のインデックスを要求したら、彼らは何と言うでしょうか?」もちろん、彼らはあなたを笑い者にするでしょう。しかし、Domino データベースではインデックスの数はごく普通のもので、それが怠惰に更新されたり、スケジュール通りに更新されたり、トリガーや強制的に更新されたりする理由です。更新/更新のルールには様々なものがありますので、ここでは触れません。
NIF で最もコストのかかる問題のいくつかは、更新のための過度のキューイングに起因しています。APIや文書のほとんどは、ユーザーがビューを開いて最新の更新を見たいときに「リフレッシュ」と呼んでいますが、これは完全に理にかなっています。問題は、多数のユーザー(まあ、スレッド)が一度にそれを行うとき、彼らはそれぞれが 「公正な読み書き (fair read/write)」キューでビューを更新する権利を競います。つまり、読みたいだけの人は書き手よりも優先されません(私たちは更新を飢えさせることはありません)。その結果、サービスレベルアグリーメント(SLA)のタイミングに違反し、ビューを開くのに時間がかかりすぎてしまうことがあります。
以下は、SPR JCUS8MXLA2 用にまとめた図です。この中には、スケジュールされた専用のビュー更新を表す「更新タスク」が含まれています。
ご存知ないかもしれませんが、v9.0.1 Feature Pack で、Domino の開発者はこの問題を攻撃するための機能をひっそりと開発していました。これは「インラインビュー更新」あるいはシンプルに「インライン」と呼ばれています。この機能は以下のコマンドで有効/無効にできます。
load updall <データベース名> [-T <ビュー名>] -inline on/off
これが何をするかというと、文書更新時にビューの更新を適用することです。そのため、ビューオープン時のすべてのリフレッシュ要求は、そのまま「nops」として扱うことができます。文書の更新はより重い作業単位になりますが、ビューのオープンと読み込みのパフォーマンスのトレードオフはそれだけの価値があります。
Domino V10では、使用率の高いビューを検出して自動的に専用の更新スレッドを作成するという2つ目の取り組みが開始されました。これは notes.ini の NIF_VIEW_USAGE_ENABLED=1 で有効になっています。
私は最初の取り組みである-inlineの効果を測定したかったので、この夏、HCL Chelmsford で(まあ、COVID-19のために自宅で)、Dominoコアのインターンである Joseph Calles と一緒に仕事をするという特権を得ました。私は Joseph に、-inline のオンとオフを使って実際のタイミングを提供することの探求をお願いしました。彼は、3つのビューを持つ 200K の文書のデータベースに対して、読み込みと更新の負荷を変化させるスクリプトを書き、Domino コンソールで "show trans" を使って統計を収集しました。Joseph 氏は、文書の更新とビュー操作の上限を10/秒に設定しましたが、もちろん、あなたの数値は、ボリューム、データ量、使用するハードウェアに応じて変化します。
誰もこれらの数字が現実のものであると主張していません、データと処理は自動化されています。しかし、彼らは収集されたセットとの相対的な一貫性があります。また、インラインの使用を検討する際に知っておくべき傾向を示しています。テスト負荷の分散は単純なものでした。
OPEN_COLLECTION トランザクションは、インラインがオフのときにビューを更新しようとするときの負荷を下げるものです。その利点は最初のグラフを見れば一目瞭然で、インラインがないとビューを開く時間が直線的に増加するよりもはるかに速くなることに注目すべきです。これが、私が言及したログジャムです。
2つ目のグラフでは、ビューを開いている時間とビューを読んでいる時間を組み合わせて、1つの時間を提供しています。これは、ユーザーがビューを開いて最初のウィンドウのエントリがレンダリングされるまでの時間に近いものです。ここでも、-inline を使用しないトランザクションの数が多くなるとスパイクが発生することは明らかです。
今では、800 ミリ秒のレスポンスで SLA に違反することはほとんどありません。繰り返しになりますが、ポイントは曲線です。ビューを開くための最大時間を表示すると、実際にはほとんどのSLAに違反するであろう、不規則で最悪のケースのユーザー体験を示しています(このグラフでは、時間は秒単位で表示されていますのでご注意ください)。
ウソのない宣伝 (Truth in advertising): 文書の更新時間は -inline をオンにすると増加しますが、それを期待するでしょう。そして、指数関数的に増加するのではなく、直線的に増加します。しかし、これをスループットの低下と混同しないでください。
この最後のグラフは、更新、検索、ビューのオープン、ビューエントリの読み込みなど、すべての操作を等しく扱い、それらの合計時間を平均化しています。つまり、インライン処理の全体的な持続時間の影響を表しています。
しかし、元々のユースケースを覚えておくことは重要です。複数のユーザーがビューを開いて読もうとしていますが、最初に「リフレッシュ」(更新)を行います。複数のユーザがビューを開いて読もうとしますが、最初に「リフレッシュ」(つまり更新)を行います。 -inline をオンにすると、読まれているビューは NSFNoteUpdate 操作中に更新されるので、リフレッシュ操作は不要です。そのため、これらのビューのオープン操作ははるかに軽量化されます。
繰り返しになりますが、この動作はトランザクション中心のデータベースシステム、特にデータがきちんとした四角形の中に存在するリレーショナルシステムでは「普通」です(少し進歩しています)。しかし、Domino では、文書の格納と処理を行う NoSQL エンジンである Domino では、非常に多くの異なるインデックスをサポートしており、インデックスデータを非常に多くの異なる方法で構築しているため、多くの場合、遅延更新モデルが適切なものとなります。そして -inline 機能は、それが適切でない場合に対処します。
ですから、もしあなたが競合するビューを持っているのであれば (すべてのビューが熱く競合しているわけではありませんが)、以下のコマンドを使用して、インラインビュー更新を有効にする検討を強くお勧めします。
load updall <DB名> -inline on -T <競合するビュー名>
すると、良い結果を得ることができることでしょう。
文書の更新コストが急増する可能性があるため、データベース内のすべてのビューに対してオンにすることには注意が必要です。みなさんは、ご自身の環境で、最も競合の多いビューを知っているでしょうからうまくやってみてください。
これまでも HCL サポートでは、サポート終了済みからのバージョンアップに関するお問い合わせについて、できるかぎりの対応をしてまいりました。しかしながら、バージョンアップ手順の観点からは「一旦、サポートされているバージョンに上げてから、最新に上げる」ことを案内してきました。今回、直接のアップグレードについて、サポートはされていないものの、ベストエフォート対応とすることが明示されました。
事前の検証をするなどのリスク回避はお客様側で行っていただくことや、HCLのサポートがベストエフォートであることはこれまでと変わりませんが、「一旦、サポートされているバージョンに上げてから、最新に上げる」ことについては必須ではなくなりました。
HCL Notes/Domino、およびメール・テンプレート 11.0 のサポートされている混在バージョンと相互運用性
旧: Notes/Domino 11.0 をインストールしてアップグレードする前に、少なくとも Notes 9.0.1 および Domino 9.0 にアップグレードする必要があります。それより前のバージョンからのアップグレードも可能な場合もありますが、テストされておらず、正式にサポートされていません。
新: Domino 9.0 以降の Domino バージョンから Domino 11 へのアップグレードはテストされ、認証されています。明示的には認証されていませんが、HCL は Domino 9.0 より前のサーバーから Domino 11 への直接アップグレードをサポートするためにベストエフォートで対応します。
この度、「Notes/Domino ファミリーフォーラム」を開設しました。このフォーラムは、Notes/Domino やその他関連製品についての情報共有、質問、知見を深めていただくための場所です。どうごご利用ください。
いくつか注意事項があります。
お客様間での相互扶助の場としてもご活用ください。このフォーラムでのご質問について、HCL は回答、問題解決の義務を負いません。そのような対応が必要な問題については、技術サポートにお問い合わせください。
HCL として専任の管理者による常時モニターを行っていません。HCL より回答をさせていただく場合もございますが、主たる業務の範囲外でありベストエフォートの内容となります。ご了承ください。
フォーラム内の情報は、HCLからの発言を除き、HCLが保証をするものではございません。
HCL Software サポートトップ画面からの行き方
2020年も後半に入りました。ちょっと先のことを書きたいと思います。
2020年6月に OpenNTF のイベントにおいて、HCL からプレゼンテーションが行われました。そこで使われたスライドの 1 枚がこれです。
スライド下に時間軸がかかれていますが、今は「2020/21」のあたりになります。
2020年後半からは、このロードマップにしたがって、製品がリリースされていく予定です。ご期待くださいませ。
Cloud サービス終了に関連して、サポート技術情報「Notes クライアントでバックグラウンドレプリケーションのスレッドを増やす方法」を作成しました。ピン留されている「Cloud サービス終了のお知らせ」にもリンクを設定してあります。