最近、以前使えていたようにデータベースを使えません。
データベースにアクセスするのに時間がかかったり、突然フリーズしたりすることが多々あります。
その場合の対処法を教えてください。
データベースのパフォーマンス低下の原因は、次の4つの観点から考えられます。
パフォーマンス低下が発生した場合は、まずは各観点から切り分けを行ってください。
それでも解決しない場合はお気軽にお問合せください。
1．ハードウェアや OS 関連
2．サードパーティアプリケーションの干渉
3．データベース設計
4．データベースの破損 (他の症状と併発することがあります)
※データベース破損の対応策は、3-11）で説明しています。
1．ハードウェアや OS 関連
この観点で考えられる原因は以下です。（参考情報より引用）
・ サーバーまたはクライアントで、利用可能なディスクスペースの量が制限されている。
・ ネットワークインターフェースカード (NIC)、サーバーハードウェア、
クライアントハードウェアが期限切れまたは廃止となっている。
・ クライアントのオペレーティングシステム (OS) が古い、または最新の OS や Service Pack がインストールされていない。
・ クライアントまたはサーバーの処理速度が遅い (RAM：ランダムアクセスメモリ など)。
・ クライアントマシンやサーバーマシン上でウイルスが検出されたか、未検出のウイルスがある。
・ ネットワークの問題、ネットワークトラフィック過多、ネットワークのボトルネック、データベースのトラフィック。
上記原因にお心当たりがある場合は、下記手順に沿ってトラブルシューティングを行ってください。
（一部、参考情報より引用）
１）クライアントとサーバーで、利用可能なディスクスペースや仮想メモリなどを検証します。
２）ハードウェア、ソフトウェア、Service Pack、ウイルス対策アプリケーションがすべて最新のものであるか検証します。
３）クライアントやサーバーで実行されている診断 (Win MSD、NSD など) をすべて把握します。
４）Microsoft Windows OS の場合は タスク マネージャー を確認します。
それ以外のクライアントオペレーティングシステムの場合は、データベースのオペレーション中に
マシンのメモリとCPUの使用状況を確認します。
５）システム/ Louts Notes ネットワーク環境でネットワークトレースを実行します。
６）疑わしいデータベースのローカルレプリカを作成し、事象が発生するか確認します
（ネットワークとサーバーから切り離しても依然事象が発生するかの確認です）。
※ 新規に作成したローカルレプリカを開くのに多少の時間がかかるのはビュー索引の構築を行っているためであり正常動作です。
７）問題がごく一部のユーザーだけに発生する場合は、そのユーザーの ID を別のマシンに移して再テストします。
次に、異なる OS で同じバージョンの Notes クライアントがインストールされているマシンを
ユーザーに使用してもらい、再テストします。
８）クライアント OS/ソフトウェアが、イメージからインストールされたものである場合、
可能であれば CD から OS を再インストールしてください。
その後、Notes クライアントのみを再インストールしてデータベースのパフォーマンスは改善されるかを確認してください。
９）可能であれば、クライアントマシンをいちから再構築します。事象が一部のユーザーだけに発生する場合は、
そのユーザーに別のマシンを使用してもらってください。
多くの場合で、新しいハードウェアやワークステーションの新規構築によって事象が解決できます。
2．サードパーティアプリケーションの干渉
以下のようなサードパーティアプリケーションがデータベースのパフォーマンスに影響を与えることがあります。
（一部、参考情報より引用）
・ バックグラウンドで実行されているウイルス対策ソフトウェアやウイルス対策ソフトウェアの一部のリリース。
・ Notes と連携するしないに関わらずマシンにインストールされている他のアプリケーションやソフトウェア (サードパーティ製)。
・ 古いバージョンのウイルススキャンソフトウェア。
・ 毎日や毎週行われる定期ウイルススキャン。これらのスキャンは、Notes クライアントだけでなく
ワークステーション全体の総合的なパフォーマンスを低下させます。
・ バックグラウンドで実行されているプログラム ([スタート] メニューから起動されたプログラムなど)
※スタート時に起動されるすべてのプログラムは、常にバックグラウンドで実行されています。
・ ポップアッププログラム（ワークステーションのパフォーマンスを低下させ、Notes データに干渉する可能性があります。）
上記原因にお心当たりがある場合は、下記手順に沿ってトラブルシューティングを行ってください。
（一部、参考情報より引用）
１）データベースのローカルレプリカを作成し、事象が発生するか確認します。
２）クライアントマシンをセーフモードで実行し、ローカルレプリカで事象の発生を確認します。
３）クライアントマシンで WinMSD を実行し、メモリ使用量などを確認します。
４）Windows のタスクマネージャーや OS のタスクバーを使用して、バックグラウンドで実行されている
他のすべてのアプリケーションを無効にしてください。
最初にサーバー上のコピーDBで事象を確認し、次にローカルレプリカでも事象の発生を確認します。
５）クライアント上のDataディレクトリ下にある下記ファイルの名前を変更し、Notesを再起動してください。
・ デスクトップファイル (Notes 8.5.x の場合は Desktop8.ndk、
Notes 6.x、7.x、8.0.x の場合は Desktop6.ndk、Notes R5.x の場合は Desktop5.dsk)
・ キャッシュファイル (Notes 6.x、7.x、8.x の場合は Cache.ndk、Notes R5.x の場合は Cache.dsk)、
・ bookmark.nsf ファイル
６）サードパーティアプリケーションの一部をアンインストールし、事象の発生を確認します。
７）可能であれば、クライアントから他のすべてのサードパーティアプリケーションをアンインストールして、
OS上にNotes クライアントだけが存在する状態にします。
（もしくは、OS と Notes クライアントだけを含む新しいクライアントワークステーションを構築します。
その場合、すべてのソフトウェアはイメージではなく CD からインストールしてください。）
８）Notes クライアントの複数のバージョンで事象を確認し、必要であれば Notes クライアントを再インストールします。
９）ポップアップ広告を除去するツールをインストールします。
3．データベース設計
データベースパフォーマンスを低下させる原因は、一般的に以下の式によって考えられます。
(ユーザー数) x (データベースのサイズ) x (ビューの数) x (各ビュー内の文書数) x (文書の更新頻度) x (プロセッサ) x (ネットワーク待ち時間)
※その他、データベース内に[すべての文書]ビューが複数あり、ユーザーに公開されていることも原因となり得ます。
一般に [すべての文書] ビューは 1 つだけ作成し、非表示に設定してユーザー用の UI で使用しないことが推奨されています。
この観点から考えられる原因は以下です。（参考情報より引用）
・ データベースに大量の文書がある。また、すべての文書を参照するビューがデータベースにある場合、
パフォーマンスが低下することがあります。
・ データベースに大量のビューがある。
・ 複雑なビューの選択式または列式。
・ 時間関数 (例: @Today、@Now など) を含むビューの選択式または列式。
・ ビュー索引の頻繁な更新や大きなデータベースの全文索引の作成。
・ 文書の [読者] フィールド。
・ @DbLookup 式や @DbColumn 式 (ネットワーク関連の問題ともオーバーラップします)。
・ データベースのプロパティには、パフォーマンスを低下させるものと、向上させるものがあります。
・ 「Fixup」、「Compact」、「Updall -r」は、データベースを開くときのパフォーマンスを低下させる可能性があります。
たとえば、ユーザーが開こうとしているデータベースや、ユーザーがデータの操作を試みているデータベースに
これらのユーティリティを実行すると、パフォーマンスが低下することがあります。
・ ワークステーション上の大きな cache.dsk または cache.ndk。
・ サーバーに保存されている個人ビューや共有 (最初は個人) ビュー。
・ マルチリンガルのデータベース。これらのデータベースは、単一言語のデータベースよりも開くのが遅くなります。
・ データベース内の大きな添付ファイル。
・ 大きな UNK テーブル (UNique Key Table：固有キーテーブル)。多数の固有フィールドがデータベース内にあることを意味します。
・ データベースの破損やビューの破損。
・ カスタムアプリケーションでの非効率的なコーディングまたはプログラミング。
Domino で利用できるプログラミング機能のリストはメジャーリリースごとに拡張され続けています。
このため、メジャーアップグレードの計画時にカスタムアプリケーションを見直し、
新しいプログラミング機能を確認することをお勧めします。
上記原因にお心当たりがある場合は、下記手順に沿ってトラブルシューティングを行ってください。
（一部、参考情報より引用）
１）上記で列挙した設計要素がデータベースで使用されていないか確認します。
２）データベースのコピーを作成し、事象の発生を確認します。
３）コピーしたデータベースで、データベース内の文書数を半分に減らしてみます。
４）コピーしたデータベースで、データベース内のすべての文書を削除し、新規文書を 1 つだけ作成します。
５）コピーしたデータベースで、データベース内のビューの数を減らします。
６）コピーしたデータベースで、たとえば複雑な列式やビューの選択式を削除して、ビューを簡素化します。
※ビューレベルで計算を実行するのではなく、ビューの列は文書内のフィールドを参照するつくりにする方が効率的です。
ビューレベルでそのような種類のコードをなくし、ビューをシンプルにして式を効率化することがベストです。
７）可能であれば、時間の要素に基づく @ 関数や式 (例: @Today) を削除します。
８）一部の少数の文書を参照するだけで、列式をまったく持たない非常にシンプルなビューを作成して事象を確認します。
９）データベースのプロパティには、パフォーマンスを低下させるものと、向上させるものがあります。
詳細については、Administrator ヘルプ「データベースのパフォーマンスを最適化するデータベースプロパティ」を参照してください。
10）すべてのフォームとビューで、@DbLookup 式と @DbColumn 式が使用されていないかチェックします。
この種類の @ 関数は、ネットワークを通じて他のビューやデータベースに関数呼び出しを実行するためパフォーマンスを低下させます。
11）該当のデータベースに「Fixup」、「Compact -c」、「Updall -r」を実行し、データベース破損がないかを確認します。
※ compact のオプション c は、コピー方式の圧縮を実行します。
トランザクションログが使われている場合はオプション c を使用せず、オプション b を使用するかデフォルトを使用します。
b やデフォルトは、トランザクションログとともに用いても安全なインプレース方式の圧縮を使用します。
12）ビューの索引のプロパティを変更し、更新の頻度を低くします。
13）データベースの全文索引 (FTI) がある場合は、それを削除して事象が改善するか確認します。
次に、全文索引を再作成してもう 1 度確認します。
14）データベースで索引が作成されたアイテムのリストを変更します。大きい添付ファイルに索引を作成すると
データベースのパフォーマンスが低下することがあるので注意してください。
15）このデータベースの新規レプリカを作成し、パフォーマンスの差があるか確認します。
16）このデータベースの新規コピーを作成し、サイズに大きな違いがあるか、パフォーマンスの差はあるか確認します。
※ 15）と 16）で作成したデータベースの新規レプリカと新規コピーを最初に開くときは、
ビュー索引が再構築されるため動作が遅くなります。
データベースにアクセスする前に「Updall -c」を実行するとまだ再構築されていないすべてのビューが
強制的に再構築されるので、必要であれば実行してください。
17）アプリケーションの [読者] フィールドの数を減らします。
18）サーバーに保存されている個人ビューと共有 (最初は個人) ビューの数を減らします。
19）データベースに大きな UNK テーブルがないか確認します。
◆参照元URL
上記の内容はHCL社公式文書にも情報がございます。詳しくはこちらをご参照ください。
問題判別ガイド：データベースのパフォーマンス低下のトラブルシューティング