Veritas InfoScale™ 8.0 DB2 データベース用ストレージと可用性管理 - AIX, Linux
- 第 I 部 DB2 データベース用 SFHA (Storage Foundation High Availability) 管理ソリューション
- Storage Foundation for Databases の概要
- 第 II 部 Veritas InfoScale 製品を使用した DB2 の配備
- 第 III 部 Storage Foundation for Databases (SFDB) ツールの設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- Storage Foundation for Databases (SFDB) リポジトリの設定
- Storage Foundation for Databases (SFDB) ツールの認証の設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- 第 IV 部 DB2 データベースのパフォーマンスの向上
- データベースアクセラレータについて
- Quick I/O によるデータベースパフォーマンスの向上
- Veritas Concurrent I/O による DB2 データベースパフォーマンスの向上
- 第 V 部 PITC (Point-In-Time Copy) の使用
- PITC 方法の理解
- DB2 PITC に関する注意事項
- サードミラーブレークオフスナップショットの管理
- Storage Checkpoint の管理
- リカバリのための Database Storage Checkpoint
- SFHA 環境での NetBackup によるバックアップとリストア
- 第 VI 部 DB2 に対するストレージコストの最適化
- 第 VII 部 Storage Foundation for Databases 管理リファレンス
- Storage Foundation for Databases コマンドリファレンス
- Storage Foundation for Databases のチューニング
- SFDB ツールのトラブルシューティング
Storage Checkpoint と 64 ビットの i ノード番号
ファイルの i ノード番号は、Storage Checkpoint 全体で同じです。 たとえば、ファイル file1
がファイルシステムにあり、Storage Checkpoint がそのファイルシステムを取る場合、元のファイルシステムと Storage Checkpoint の file1 で stat
コマンドを実行すると、st_ino で同じ値が返されます。 st_ino と st_dev の組み合わせは、システム内のすべてのファイルを一意に識別する必要があります。 これは、Storage Checkpoint は別々にマウントされ、st_dev が異なるため、通常は問題ありません。 Storage Checkpoint のファイルに Storage Checkpoint の可視性拡張子を介してアクセスする場合、st_dev は元のファイルシステムと同様に、すべての Storage Checkpoint で同一です。 つまり、st_ino と st_dev を使用してもファイルを一意に識別できなくなったことを意味します。
通常は、システムのすべてのファイルを一意に識別する必要はありません。 ただし、正しく機能するためには一意に識別する必要がなるアプリケーションもあります。 たとえば、あるバックアップアプリケーションは、ファイルが別のファイルにハードリンクされているかどうか確認するために、両方のファイルで stat を呼び出し、st_ino と st_dev が同一であるかどうか調べる場合があります。 Storage Checkpoint の可視性拡張子を介して 2 つのクローンを同時にバックアップするようにバックアップアプリケーションに指示があった場合、それらのファイルに含まれているデータが異なる場合でも、アプリケーションは誤って 2 つのファイルが同一であると推測します。
デフォルトでは、SF(Storage Foundation)は i ノード番号を一意にしません。 ただし、一意の 64 ビットの i ノード番号の使用を有効にするために uniqueino マウントオプションを指定できます。 このオプションは再マウント中には変更できません。