Lotus Dominoサーバーのデータベースを強制的に圧縮しますか？
最近、使用頻度の高いLotus Notesデータベースが64GBの制限を超えたという厄介な経験がいくつかあります。
データベースには、データベースの圧縮を実行して問題を解決するための余裕がありましたが、データベースを圧縮してデータベースを排他的に使用するのに十分な時間データベースをオフラインにすることは、本当に悪夢でした。
私たちは試しました：
- データベースの圧縮中に、ユーザーにデータベースへの読み取り専用アクセスを許可します。
（データベースが変更されたと言うと、しばらくすると圧縮は失敗します） - データベースのすべての非管理者へのアクセスを削除する
- データベースの複製を無効にする
- drop database.nsf-全員をそのデータベースから追い出す
- dbcacheフラッシュ-データベースキャッシュで開いていたすべてのデータベースを閉じる
それでも、ユーザーはデータベースへのアクセスとして表示され、排他モードの圧縮は許可されません。
結局、私たちは次のことに頼りました：
- データベースのすべての非管理者へのアクセスを削除する
- サーバーを再起動する
- サーバーコンソールにすばやく入力する：誰かがデータベースにアクセスする前に "compact -c databasename.nsf"
全員をデータベースから追い出して、排他的なデータベース圧縮を強制する簡単な方法はありますか？ Lotus Domino Server 8.5.3を実行しています
compact -Bは「ファイルサイズを縮小したインプレース」です。まだの方はお試しください。
私の理解ではdrop db.nsfは機能しません。 Drop Allを試してみてください。それが機能する場合は、そのdbにアクセスするユーザーのみをドロップするコードを記述できます。
（フェイルオーバー用に構成された）クラスターを実装しないのであれば、ユーザーを他のユーザーに切り替えることができます。次に、DBを修正してコンパクトを実行する時間があります。次に、DBを削除して、2番目のサーバーから再作成することもできます（再作成されたDBはすでに圧縮されています）。
ところで。 （まだ有効になっていない場合は）Document＆Design CompressionとLZ1を有効にすると、DBを少し縮小するのに役立ちます（コンテンツによって異なります）。
プライマリサーバーのレプリカをクラスターの新しいレプリカに置き換える前に、ドキュメントの数が同じか、かなり近いこと、およびクラスターサーバーのレプリカに構造上の問題がないことを確認することをお勧めします。これを確認するには、クラスターのデータベースでコンパクトを実行し、クラスターサーバーのコンソールログでエラーを解析します。
Compact -C -DAOS ONでも同じ問題が発生します。圧縮中に別のユーザーが変更したため、圧縮が途中で停止したと言って失敗しました。ルーター、smtp、レプリケータータスクを停止すると問題が解決します。現時点ではどのタスクが責任があるのかわかりませんが、機能しています
ノーツクライアントからncompactユーティリティを使用してオフラインコンパクトを試すことができます。 Dominoコンソールからのコンパクトコマンドと同じオプションがありますが、Notesを開いたりDominoを実行したりせずにnfsで直接動作します。
この巨大なNFSを移動したくない場合は、ネットワーク共有を使用して、ncompactを実行できます。修正プログラムを実行し、古いODSバージョンを使用している場合はODS 5.1に変換することを強くお勧めします。
また、nsfをチェックし、そのサイズに達しないようにして、ドキュメントをアーカイブして新しいnsfコピーに移動することをお勧めします。それらを数ギガバイト程度に維持するようにしてください。そうすれば、フィックスアップとコンパクト化を頻繁に実行して、それらの整合性を確認できます。