| Oracle® Enterprise Manager概要 11gリリース11.1.0.1 B61020-01 |
|
 戻る |
 次へ |
この章では、データベース管理の概要について説明します。内容は次のとおりです。
データベース管理では、エンタープライズ内のデータベースおよびデータベース・グループの監視、管理およびメンテナンスを行います。Enterprise Managerは、データベース環境の管理に使用する主要ツールです。
Enterprise Managerでは、次のものが提供されます。
Oracleデータベースを管理するために統合された機能の完全なセット
単一データベースまたは数千のインスタンスの管理を可能にするスケーラビリティ
デプロイメントが容易で使用しやすい管理製品
Enterprise Managerでは、データベースの監視に使用する2つのコンソール、Database ControlおよびGrid Controlが提供されます。
Database Controlは、Oracle Database 11gリリース1（11.1）以上を管理するEnterprise ManagerのWebベースのアプリケーションです。Database Controlは、Oracle Database 11gのすべてのインストールでインストールされ、使用できます。Database Controlを使用すると、単一のOracleデータベース・インスタンスまたはクラスタ化されたデータベースを監視および管理できます。
Grid Controlは、Oracle環境全体の集中管理に使用するEnterprise Managerコンソールです。Grid Controlでは、「ターゲット」タブを使用し、「データベース」をクリックして複数のデータベース・ターゲットにアクセスします。
Enterprise Managerのデータベースのホームページ（図6-1）には、単一ソースからのデータベース・インスタンスに関する重要なステータスおよびパフォーマンスの情報が表示されます。この情報には、次の内容が含まれます。
データベースのステータスおよびデータベースに関する基本情報の迅速な表示
Oracleホストの相対的CPU使用率
CPUとI/Oの使用によって消費したインスタンス時間およびボトルネックで消費したインスタンス時間
追跡されるSQLセットの現行レスポンスと参照収集レスポンス
Automatic Database Diagnostic Monitoring（ADDM）検出の件数、ポリシー違反の件数（Database Controlのみ）、およびアラート・ログのステータス
パフォーマンスの改善についての記憶域関連の問題と推奨事項、および領域違反とADDMに関する情報
最新のバックアップ時間およびバックアップ・ステータス
未処理のアラートおよび関連アラート
システム内のすべてのメンバー・ターゲットでのOracleポリシー違反のロールアップ数
データベース・セキュリティの迅速な表示
スケジュール済、稼働中、一時停止中、および問題のある実行を示すジョブの実行
データベースのホームページから、ユーザー・インタフェースをドリルダウンして、追加の管理機能にアクセスできます。また、データベースのホームページには、関連リンクのリストも表示されます。これらのリンクから、メトリックしきい値の編集、ジョブ・アクティビティおよびメトリック収集エラーの分析、様々なアドバイザへのアクセスなどのアクティビティを実行して、データベースのパフォーマンスを改善できます。
|
関連項目: Enterprise Managerのオンライン・ヘルプのOracle Databaseホームページに関するトピック |
包括的にデータベースを監視することによって、データベース環境でパフォーマンスを低下させている問題箇所を特定できます。修正する箇所を特定した後、Enterprise Managerの管理機能を使用してデータベースのパフォーマンスをチューニングできます。
Enterprise Managerは、自動ワークロード・リポジトリ（AWR）のデータを使用して、パフォーマンス情報を表示し、データベースのアラートを開始します。このユーザー・インタフェースには、管理するターゲット用のリアルタイム・パフォーマンス・グラフおよびドリルダウンがいくつか用意されています。グラフには、集計パフォーマンス統計とインスタンス固有のパフォーマンス統計がわかりやすいように色分けされて表示されます。問題の原因を特定し解決するには、グラフの横の凡例リンクをクリックして、包括的な情報を含む詳細ページを表示します。
パフォーマンス監視の基本ワークフローでは、まずデータベースの「パフォーマンス」ページに移動します。ここには、最上位レベルの重要なパフォーマンス・インジケータの一覧が示され、対話方式または自動のいずれかで問題を診断できます。
|
ヒント: この後の項で説明されていないデータベースの監視の詳細は、『Oracle Database2日でパフォーマンス・チューニング・ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
パフォーマンスを詳細に診断するためのすべての情報が単一の画面で入手できるので、データベースを簡単かつ効率的にチューニングできます。データベースの「パフォーマンス」ページ（図6-2）は、データベースのホームページからアクセスできます。データベースの「パフォーマンス」ページでは、インスタンスおよびインスタンスの基礎となるホストのパフォーマンス・データを迅速に表示できます。また、すべてのパフォーマンスのすべてのクリティカルなメトリックの傾向を分析し、他のデータベース・インスタンスのメトリックと比較できます。
このページからパフォーマンスの問題を最も直接的に調査および診断する方法は、自動データベース診断モニター（ADDM）にアクセスすることです。Oracleデータベースを起動すると、自動ワークロード・リポジトリ（AWR）がデータベース・アクティビティのスナップショットの作成を開始します。このスナップショットはデフォルトで1時間に1回作成されます。スナップショットが収集された時点でADDMが実行されます。ADDMは、これらのスナップショットを使用してデータベース・アクティビティ全体を分析し、チューニングの推奨事項を提供します。
パフォーマンスの問題を調査および診断するもう1つの方法は、まず「平均アクティブ・セッション」グラフの横に示された待機クラスのうちのどれが過剰に長い時間を消費しているかを確認し（最大CPUラインより上の山型部分で表示）、次に詳細をドリルダウンすることです。これにより、ADDMから推奨事項が提供されたデータの視覚化が可能になります。
いずれの方法も問題の診断および解決に役立ちます。最初の自動化方法では結果がテキストで表示されますが、2番目の対話方法では結果がグラフィカルに表示されます。
データベースの「パフォーマンス」ページのグラフでは、共通の時間軸上に現在および最近のメトリック情報が表示されます。この時間軸によって、メトリックを相関的に表示できます。これらのグラフには、問題を迅速に診断するために、追加の詳細を検出する状況依存ドリルダウンが含まれています。
表6-1 「パフォーマンス」ページのグラフ
| グラフ | 説明 |
|---|---|
|
このグラフには、全体的なCPU使用量の概要が表示されます。「非データベース・ホストのCPU」の値は、このインスタンスで実行されていないその他のすべてのCPUの処理量を表しています。「インスタンスのバックグラウンドCPU」の値は、ユーザーがチューニングできないOracleプロセスを表しています。「インスタンスのフォアグラウンドCPU」の値は、データベースの問合せなどチューニング可能なアクティブな処理を表しています。 このグラフの機能を拡張する関連チェック・ボックスの詳細は、このページのオンライン・ヘルプを参照してください。 |
|
|
このグラフはOracleパフォーマンス監視の主要グラフであり、データベース内部の考えられる問題を示します。このグラフには、セッションがデータベース・インスタンスで実行されている時間、または実行の待機時間のいずれかのプロファイルが表示されます。 待機クラスと呼ばれるカテゴリは、データベース内でCPUまたはディスクI/Oなどのリソースを待機している量を表します。グラフには、インスタンスの負荷が表示され、パフォーマンスのボトルネックを特定できます。 このグラフの詳細は、このページのオンライン・ヘルプを参照してください。 |
|
|
このグラフには、「平均アクティブ・セッション」グラフに表示された競合が示され、ユーザーに対して実行されているデータベースの処理量が表示されます。 |
|
|
これらのグラフには、次の情報が表示されます。
|
|
|
パラレル問合せに関連するシステム・メトリックが表示されます。このグラフには、サンプリングされたセッション・アクティビティの最も高い割合を占める特定の待機イベントを待機していたパラレル問合せが表示されます。 |
|
|
表示されている期間中、対応する待機イベントを待機している上位サービスが表示されます。アクティブなセッションのみ表示されます。 |
「その他の監視リンク」セクションでは、複数の関連ページにアクセスできます。これらのページのうち、次のページにリアルタイム診断機能が備わっています。
トップ・アクティビティ
上位コンシューマ
インスタンス・アクティビティ
履歴SQL(AWR)（「データの表示」が「履歴」に設定されている場合のみ表示）
|
関連項目: Enterprise Managerのオンライン・ヘルプの「パフォーマンス」ページに関するトピック |
対話方式で問題を手動で診断できます。これには、まず問題があると考えられる待機クラスを調査し、次にそこからSQLの詳細またはセッションの詳細にドリルダウンします。また、1箇所にあるすべての待機クラスを調査し、そこからドリルダウンすることも可能です。次の項では、これらの方法について説明します。
待機クラスのドリルダウンにより、長い間待機していると考えられる特定の待機クラスを調査できます。次に、問題の原因が、異常に長い間待機している1つ以上のSQL文であるかどうか、または1つ以上のセッションかどうかを判別できます。
待機クラスのドリルダウンを、「待機中アクティブ・セッション」ページと呼びます。これらのページのソースはアクティブ・セッション履歴（ASH）です。ここでは、秒単位でセッション・アクティビティがサンプリングされます。どのセッションがCPUを使用しているか、どのセッションがI/Oを待機しているかといった発生状況が継続的に記録されます。
「平均アクティブ・セッション」グラフの横に示された待機クラス・リンクを選択すると、該当する待機クラスの詳細が表示されます。たとえば、「ユーザーI/O」をクリックすると、「待機中アクティブ・セッション: ユーザーI/O」ページが表示されます（図6-3を参照）。
デフォルトでは、最大リソース・コンシューマが詳細の表の上部に表示されます。上位SQLまたは上位セッションについて偏りのあるアクティビティを検索します。アクティビティの過剰な累積の原因がSQLソースであると思われる場合は、関連するSQL IDをクリックして「SQLの詳細」ページに移動します。このページに、該当するSQL文とアクティビティが表示されます。過剰な累積の原因がセッション・ソースであると思われる場合は、関連するセッションIDをクリックして「セッションの詳細」ページに移動します。このページでは、必要に応じてセッションを中断できます。また、該当するセッションに関連付けられた待機イベントも表示できます。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「待機中アクティブ・セッション」ページに関するトピック |
「トップ・アクティビティ」ページ（図6-6）には、基本的にすべての待機クラスのドリルダウンの合計が表示されます。インタフェース・フォーマットは「待機中アクティブ・セッション」ページのものと同じですが、「トップ・アクティビティ」ページには、特定の待機クラスの平均アクティブ・セッションではなく、すべての待機クラスの平均アクティブ・セッションが表示されます。このページには、すべての待機クラスの上位SQLコンシューマおよび上位セッション・コンシューマも表示されます。「待機中アクティブ・セッション」ページの場合と同様に、上位SQLまたは上位セッションについて偏りのあるアクティビティを検索します。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「トップ・アクティビティ」ページに関するトピック |
OracleデータベースのリアルタイムSQL監視機能では、SQL文の実行中にそのパフォーマンスを監視できます。デフォルトでは、SQL文がパラレルで実行される場合、またはSQL文が1回の実行で5秒以上のCPUまたはI/O時間を消費している場合に、SQL監視は自動的に開始されます。
「監視されたSQL実行」ページ内の表の各行は（図6-7）、監視されたSQL文の1回の実行に対する一般的な情報および統計を表しています。この表には、最後に監視されたいくつかの実行のみが表示されます。これは、データベース・サーバーが、古い監視データによって占められた領域を要求し、そこに新しい実行の監視データを格納するためです（つまり、監視データは循環されます）。
SQL文の実行に関してこのページに表示されている情報以上の詳細情報を表示する場合、「ステータス」アイコンをクリックするか、表の列の任意の行を右クリックすると、「監視されたSQL実行の詳細」ページを選択できます（図6-8）。「レポートの表示」ボタンをクリックすると、SQLテキスト、詳細なグローバル情報およびグローバル統計を含む、アクティブなSQL監視レポートを生成できます。
|
ヒント: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のリアルタイムSQL監視に関する項を参照してください。 |
「データベース・パフォーマンスの評価」で説明したように、自動データベース診断モニター（ADDM）を使用して、データベースのホームページまたはデータベースの「パフォーマンス」ページからパフォーマンスの問題を自動的に調査および診断できます。ADDMは、定期的にスケジュールされたデータベース・アクティビティのスナップショットを使用して、最もリソースが集中するコンポーネントまたは操作を特定し、これらのコンポーネントまたは操作がパフォーマンスのボトルネックになっているかどうかを判別します。1つ以上の問題が発生した場合、ADDMは考えられる問題を診断し、アドバイスを提供します。このアドバイスでは、アドバイザの実行またはデータベース構成の変更が推奨される場合があります。
事前に定義された最近の期間のADDM結果を表示することも、現時点でのADDM結果を表示することも可能です。データベースのホームページの「診断サマリー」セクションにある「ADDM結果」リンクをクリックすると、最近の期間のADDM結果を表示できます。また、データベースの「パフォーマンス」ページの「平均アクティブ・セッション」グラフの下の小さい「ADDM」アイコンをクリックすると、該当する期間のADDM結果を表示できます。いずれのオプションを使用しても、「自動データベース診断モニター(ADDM)」ページが表示されます（図6-9）。現時点でのADDM結果を求めるには、データベースの「パフォーマンス」ページにある「ADDMの実行」ボタンをクリックします。
デフォルトでは、データベースは60分間隔でスナップショットを作成します。自動ワークロード・リポジトリを使用すると、スナップショットの間隔を10分から2時間までの範囲内で変更できます。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「パフォーマンス結果の詳細」ページに関するトピック |
前述のプライマリ診断ページの他に、パフォーマンスの問題の診断と修正に役立つ重要なセカンダリ診断ページもあります。次の項では、これらの診断ページについて説明します。
上位コンシューマ
インスタンス・アクティビティ
履歴SQL(AWR)
「上位コンシューマ」リンクには、システム・リソースの上位データベース・コンシューマに関するグローバル・サマリー情報があります。セッション、サービス、モジュール、クライアントなどの特定の上位コンシューマに関する詳細なメトリック・データへのアクセスが可能です。これにより、データベースをチューニングする必要のある問題箇所を特定できます。図6-10には、「上位コンシューマ」の「上位モジュール」ページが示されます。ここでは、コンシューマに対する集計およびSQLトレースの有効化および無効化などのタスクを実行できます。SQLトレースを使用して、CPU時間、経過時間、実行計画などのSQL文の統計をトレースできます。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「上位コンシューマ」ページに関するトピック |
「インスタンス・アクティビティ」リンクには、カーソル、セッション、トランザクションなどのメトリック・グループに関する特定のデータのデータベース・アクティビティが表示されます（図6-11）。たとえば、「カーソル」メトリック・グループには、オープン・カーソルとセッション・カーソルに関する情報の他に認証と解析数も表示されます。グラフ・ビューの下の凡例リンクまたは表ビュー内の名前リンクでは、「上位セッション」ページにアクセスして詳細を参照できます。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「インスタンス・アクティビティ」ページに関するトピック |
「履歴SQL(AWR)」リンクには、自動ワークロード・リポジトリ（AWR）に24時間保存されている文が表示されます。このリンクは、「履歴」データ・ビューを選択すると「その他の監視リンク」セクションで使用可能になります（図6-12）。
このページの下部にある表には、パフォーマンスおよびリソース使用に関するすべてのSQL文の分析が表示されます。文のリンクを選択して、該当する文に関するSQLの詳細（統計、アクティビティ、SQL計画、およびチューニング情報）を参照できます。SQLチューニング・アドバイザを実行して、1つ以上の文についての推奨事項を入手することも可能です。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「履歴SQL(AWR)」ページに関するトピック |
Enterprise Managerでは、システム・コンポーネント間の関係を表示したり、データベースのパフォーマンスが低下した場合にシステム統計を収集したりするその他の支援ツールが提供されます。次の項では、これらのツールについて説明します。
トポロジ・ビューア
AWRベースライン
メモリー・アクセス・モード
ハング分析
Enterprise Managerには、複数のアプリケーションを対象としたトポロジ・ビューアが用意されています。トポロジ・ビューアを使用すると、様々なOracleアプリケーション内のコンポーネント間、ノード間またはオブジェクト間の関連を表示できるようになります。選択詳細およびサマリー情報をズーム、パン、表示し、集計コンポーネントを評価できます。オブジェクト・タイプごとに異なるアイコンが使用され、すべてのアプリケーションに対して標準化されたビジュアル・インジケータが使用されます。
トポロジ・ビューアは次のデータベース・アプリケーションに使用可能です。
スケジューラ
SQLの詳細
SQL実行計画
Real Application Clusters
クラスタ・データベース
図6-13は、「SQLの詳細」の「プラン」ページのトポロジ・ビューアを示します。トポロジ・ビューアでは、Enterprise Managerでモデル化されたSQLステップがグラフィカルに表示されます。
ベースラインとは、ターゲットに関連付けられた名前付きの期間で、ターゲットのパフォーマンスを評価する際の参照として使用されます（図6-14）。ベースラインを使用すると、パフォーマンスの問題を効率よく診断できます。AWRでは、スナップショットのペアをベースラインとして指定し保持することで、ベースライン・データの取得をサポートします。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「AWRベースライン」ページに関するトピック |
データベース・サーバーがパフォーマンスの問題に直面すると、診断問合せによってシステムがさらに影響を受ける可能性があります。メモリー・アクセス・モードは、データベースの速度が低下した場合またはデータベースがハングしている場合でもシステム統計を収集するため、パフォーマンス関連の問題の診断に役立ちます。
通常のSQLエンジンに依存するのではなく、共有グローバル領域（SGA）から表に直接アクセスしてデータを取得します。データ収集は迅速に実行されるため、すでに速度が低下しているシステムにさらに影響を与えることはありません。場合によっては、システムにさらに負荷をかけることなくパフォーマンス・メトリックのサブセカンド・サンプリングを実行できます。
「関連リンク」セクションの「メモリー・アクセス・モードで監視」リンクをクリックし、標準SQLアクセス・モードを無効化してからメモリー・アクセス・モードに切り替えることが可能です。
|
関連項目: Enterprise Managerのオンライン・ヘルプのデータベースの「パフォーマンス」ページに関するトピック |
ハング分析を使用すると、システムの速度を低下させたりハングを引き起こす可能性のあるロックの問題を診断できます。通常、システムの速度が低下した場合またはシステムがハング状態になった場合は、診断問合せも極端に遅くなるか、または結果を戻さなくなります。このユーティリティは、通常の問合せエンジンを使用せずにOraclebug APIを使用するため、システムがハング状態にあると考えられる場合でも迅速に結果を戻します。
「ハング分析」ページには、ブロックしているセッションまたはブロックされているセッションのビジュアル・マップが表示されます。セッションがツリー表示され、他のセッションをブロックしている問題のセッションがツリーのルートに配置されます。各セッションは色分けされ、セッションがブロックされていた期間の長さを示します。セッション・ボックスをクリックすると、セッションの詳細を示す別のページが表示されます。このページの情報を使用することによって、問題のセッションを取り消し、システムを通常の状態に戻すことが可能になります。
「ハング分析」ページにアクセスするには、「その他の監視リンク」セクションの「ハング分析」リンクをクリックします。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「ハング分析」ページに関するトピック |
Oracle Enterprise Managerでは、Oracleデータベースの可用性と効率的な稼働状態を維持します。Enterprise Managerは、データベース管理者による日常業務の遂行を支援します。特に、Enterprise Managerには、データベース記憶域構造およびスキーマを管理するためのグラフィカル・ユーザー・インタフェースがあります。データベース監視の場合と同様に、Oracleデータベースの管理もOracleデータベースのホームページから開始します。このページでは、データベースのプロパティおよびパフォーマンスの概要を表示できます。また、このページの「管理」セクションを使用して、次に示す共通管理タスクを実行することも可能です。
システム記憶域の割当ておよびデータベース・システムの記憶域要件の計画
プライマリ・データベース記憶域構造（表領域）の作成および管理
プライマリ・オブジェクト（表、ビュー、索引）の作成および管理
ユーザーの登録と、データベースへのユーザー・アクセスの制御および監視によるシステムのセキュリティの維持
データベースのバックアップおよびリストア
Enterprise Managerで監視することによってデータベースおよびデータベース・グループの問題箇所が特定されるため、Enterprise Managerの管理ツールを使用してデータベースを管理できます。管理ツールを使用すると、データベース・オブジェクトを管理し、Oracleデータベース内でデータベース操作を開始できます。次の項では、Enterprise Managerで使用可能なデータベース管理機能の概要を示します。
管理者として、Oracle Enterprise Managerの管理ツールを使用してデータベースのパフォーマンスを最適化できます。これらのツールを使用すると、制御ファイル、表領域、データファイルおよびアーカイブ・ログなどの記憶域構造を管理できます。これらの構造の表示、編集および削除だけでなく、それ以外の機能も実行できます。つまり、表領域をローカルで管理できるようにしたり、データファイルの依存性を表示したり、トレース用に制御ファイルをバックアップできます。
Oracle Enterprise Managerには、ユーザーがデータベース構成を管理するために役立つ多くの機能が組み込まれています。たとえば、Enterprise Managerを使用して、システムのシステム・グローバル領域およびプログラム・グローバル領域のメモリー・サイズを管理できます。また、UNDO管理機能を使用して、保存するUNDO情報の量を明示的に指定する手段を提供し、UNDO情報が上書きされないようにすることもできます。
現行のデータベースの初期化パラメータを作成または編集できます。さらに、これらのパラメータを特定の値に設定し、多量のメモリーを初期化してOracleデータベース・インスタンスの設定を処理できます。また、データベース機能の一覧表示もできます。これにより、データベース操作でのこれらの機能の使用頻度が表示されます。サポート・グループとその他の組織は、使用量の情報を活用して、システムの使用方法に関する知識を習得し、必要に応じてリソースの割当てを支援します。
データベースでは、データファイル、制御ファイルおよびログ・ファイルの自動化およびレイアウトの簡略化に、自動ストレージ管理（ASM）を使用できます。Enterprise Managerを使用して、既存のデータベースをASMに移行できます。データベースですでにASMが使用されている場合、Enterprise Managerを使用して、ディスク・グループ上にデータファイルを作成できます。
自動ストレージ管理（ASM）は、ディスク・グループを使用する大量のデータベース・ファイルを個別に管理するかわりに、ディスク・グループを管理してデータベースの運用を簡略化します。データファイルは、使用可能なすべてのディスクに自動的に分散されます。また、記憶域の構成が変わるたびに、データベース記憶域のリバランスが実行されます。ASMでは、ディスク・グループのストレージ領域を使用して、必要に応じて内部的にファイルを作成、削除および管理します。また、ASMには、論理ボリューム・マネージャで一般的に使用されるミラー化やパリティ保護などのストレージの信頼性を保証する機能も含まれます。これらの機能は、OracleデータベースまたはReal Application Clusters（RAC）で使用できます。
ASMインスタンスは、ASMアクティビティを調整するための特殊なOracleインスタンスです。インスタンスにより、ノード内のOracleデータベースにサービスが提供されます。単一ノードでは、通常、そのノードに、すべてのディスク・グループを管理する1つのASMインスタンスがあります。RAC環境では、通常、各ノードに、そのノードのすべてのディスク・グループを調整しながら管理する1つのASMインスタンスがあります。
汎用ストレージ・コンテナまたはボリューム・デバイスとして使用するために、自動ストレージ管理ファイルを構成できます。Oracle File Systemは、顧客アプリケーションにおけるデータベースとデータベース以外のすべてのデータファイル（Oracleホームに関連付けられたものを含む）をサポートする汎用のファイル・システムです。このサポートは、単一ホストおよびクラスタ構成用です。
|
関連項目: 『Oracle Databaseストレージ管理者ガイド』のOracle Enterprise ManagerによるOracle ASMの管理に関する項 |
Oracle Real Application Clusters（RAC）には、複数のホスト全体での可用性の高いデータベース環境が用意されています。それぞれのクラスタは複数のクラスタ・データベースで構成され、各クラスタ・データベースは複数のクラスタ・データベース・インスタンスで構成されます。クラスタ・データベースは、そのインスタンスが1つでも使用可能であるかぎり使用できます。Enterprise Managerを使用すると、単一インスタンス・データベースをOracle RACデータベースに非同期に変換できます。
追加された機能を使用すると、ディクショナリ管理表領域をローカル管理表領域に変換できます。これにより、領域割当ての簡略化、パフォーマンスの改善、およびデータ・ディクショナリへの依存の軽減が実現されます。
データベース・リソース・マネージャは、データベース内の実行スケジュールを管理して、様々なセッション間でのリソースの分散を制御します。データベース・リソース・マネージャは、各セッションによるCPUのおおよその使用量を制御することで、リソース分散がプラン・ディレクティブおよびビジネス目的に確実に一致するようにします。データベース・リソース・マネージャを使用すると、セッション属性とコンシューマ・グループ間のマッピングを設定して、特定のコンシューマ・グループにセッションを自動的に割り当てることができます。また、指定したカテゴリ内のコンシューマ・グループをユーザー、クライアント・プログラム、モジュール、またはサービスにマッピングできます。
リソース・コンシューマ・グループによって、リソース要件別にユーザー・セッションを分類できます。リソース・コンシューマ・グループはユーザー・ロールとは異なります。つまり、1件のデータベース・ユーザーは、それぞれのリソース・コンシューマ・グループに割り当てられた様々なセッションを有することができます。これにより、リソース・プランで、様々なリソース・コンシューマ・グループにリソースを分散するように指定できます。
リソース・プランには、このプランに属するリソース・コンシューマ・グループを指定し、これらのグループ間でのリソースの割当てに関するディレクティブを含めます。プラン情報はデータ・ディクショナリ内の表に保存されます。プラン・データを表示するための複数のビューが使用可能です。プランには、リソース・コンシューマ・グループだけでなくサブプランを含めることもできます。Enterprise Managerを使用して、リソース・プランのすべての側面を管理します。
ワークロード・リポジトリには、特定の時間間隔でデータベース統計を収集するメカニズムがあります。Enterprise Managerのオプティマイザ統計機能を使用すると、統計の収集、リストア、削除、ロック、ロック解除などのオプティマイザ統計操作の管理を簡略化できます。これらの統計を使用して、SQL文のパフォーマンスを改善します。
Oracle Schedulerを使用すると、データベース管理者およびアプリケーション開発者はデータベース環境で様々なタスクを実行する時期と場所を管理できます。Enterprise ManagerでOracle Schedulerを使用することにより、このようなタスクの管理と計画の改善を図れます。Oracle Schedulerを使用すると、タスクが時間、場所、データベース・オブジェクトなどのコンポーネント部分に分けられるため、データベース環境の管理が容易になります。データベース管理者は、バックアップまたは夜間のデータ・ウェアハウスのロードおよび抽出などの再帰データベース・メンテナンス・ジョブをスケジュールおよび管理できるだけでなく、時間またはイベントに基づくジョブの実行もスケジュールできます。
Enterprise Managerでは、スケジューラ・ジョブの有効化と無効化、既存のジョブの設定変更、現行ジョブの起動または停止、およびスケジューラ情報の表示が可能です。
スキーマとは、データベース内のデータを直接参照する論理構造で構成されたデータベース・オブジェクトの集合です。スキーマ・オブジェクトには、表、ビュー、索引などの構造があります。Oracle Enterprise Managerで使用可能なツールを使用して、これらのスキーマ・オブジェクトを作成および管理できます。
Oracle Enterprise Managerに用意されている包括的なツールのセットを使用すると、表、索引、ビューなどのデータベース・ディレクトリ・オブジェクトをすべて管理できます。Enterprise Managerで使用可能なツールは、オブジェクト・プロパティの作成、編集、表示などの基本的な作業に使用できるだけでなく、セグメント・アドバイザの実行によるブロックと領域使用量についての表の評価、および非常に断片化されたセグメントを縮小することによる領域の節約ができるかどうかを判別するといった、より包括的なタスクにも使用できます。これらの推奨事項の実装によって得られた領域は表に戻されます。
索引は、表に関連付けられたオプション構造であり、データ取得のパフォーマンスを向上する目的で作成できます。Enterprise Managerで索引を管理する場合、セグメント縮小などの機能を実行してセグメントを圧縮し、リカバリされた領域を現在の表領域に解放できます。また、記憶域設定と索引の位置を変更する際に領域使用量を再編成することで、領域の問題を取り除くこともできます。
ビューは、1つ以上の表またはその他のビューに含まれるデータのカスタマイズされた表示です。ビューを作成、削除および管理するだけでなく、ビューに依存しているオブジェクトを表示することもできます。「依存状態」表には、現行ビューに依存している「オブジェクト名」および「オブジェクト・タイプ」が表示されます。また、Enterprise Managerを使用すると、反対に現行ビューが依存しているオブジェクトも表示できます。
通常、データベース・オブジェクトの「検索」ページまたは「プロパティ」ページにある「アクション」メニューは、該当するオブジェクトに対して実行できる機能を一覧表示する目的で使用します。
Enterprise Managerを使用すると、パッケージ、パッケージ本体、機能、トリガーなどのプログラム構造も同様に管理できます。これらの要素を作成および表示する他に、たとえばJavaソースをコンパイルしたり、パッケージなどの特定のオブジェクトのデータ定義言語（DDL）コードを生成することもできます。特定のオブジェクトに使用可能な各種機能の詳細は、オンライン・ヘルプを参照してください。
XML（eXtensible Markup Language）は、Web上でデータを特定および記述するための標準的な手段です。Oracle XML DBでは、XMLがデータベース内でネイティブ・データ型として処理されます。このため、SQLを使用してXMLデータにアクセスする際、XMLデータの格納、問合せ、更新および変換が容易になります。
Oracle XML DBには、リレーショナル表からXML文書を容易に作成できる様々な手段があります。SQL問合せの結果は自動的にXML文書に変換されます。また、Oracleには、XML文書の作成を簡略化するために、JavaとC++で使用可能なユーティリティのセットが用意されています。
Oracle Enterprise Managerは、Oracle XML DBに関連する次のタスクを実行する際に役立ちます。
Oracle XML DB構成ファイル、/xdbconfig.xmlのパラメータの表示または編集など、Oracle XML DBの構成。
Oracle XML DBリポジトリ・リソースおよびそれに関連するアクセス制御リスト（ACL）の検索、作成、編集および削除取消し。
XMLType表およびビューの検索、作成、編集および削除。
XMLスキーマの検索、作成、登録および削除。
XPath式に基づくファンクション索引の作成。
Oracleには、データベースへのアクセスおよびデータベースの使用を制御するセキュリティ機能が用意されています。権限およびロールによって、データおよび実行可能なSQL文タイプへのユーザー・アクセスが制御されます。権限には、システム権限とオブジェクト権限の2種類があります。システム権限は、CREATE、ALTERなど特定のデータベース操作を実行できるOracle定義の権限です。オブジェクト権限は、特定のオブジェクトへのアクセスを制御するOracle定義の権限です。
ユーザー（通常は管理者）は、権限およびその他のロールをグループ化する目的でロールを作成できます。これによって、ユーザーに複数の権限およびロールを付与する処理が容易になります。
他のユーザーに権限およびロールを付与できるのは、ADMIN/GRANTオプションによりこの処理を実行する権限を付与されたユーザーです。Oracle Enterprise Managerを使用すると、ユーザー、ロールおよびプロファイルを作成および管理できます。また、パスワードを期限切れにしたり、ユーザーをロックまたはロック解除したりするには、1件以上のユーザーに対してこれらの操作を適用します。ロールを管理する場合は、権限受領者の表示機能を使用して、指定のロールに割り当てられたすべてのユーザーおよびロールを表示できます。
監査とは、選択したユーザー・データベース・アクションを監視および記録することです。監査は、SQL文実行のタイプなどの個別のアクションに基づくことも、名前、アプリケーション、時間などの要素の組合せに基づくこともできます。Oracleデータベース内でコンテンツなどの特定の要素にアクセスした場合、または特定の要素を変更した場合には、セキュリティ・ポリシーによって監査が実行されることがあります。監査の設定および監査設定の調整は、Enterprise Managerインタフェース内で容易に実行できます。Enterprise Managerでは、データベース監査構成の表示と、監査オブジェクト、監査権限および監査文の管理ができます。監査証跡の内容も表示できます。即時利用可能なEnterprise Managerには、ログイン試行の成否およびSYSUSER操作の成否を監視する場合に役立つ監査レポートもあります。
マテリアライズド・ビューとは、データの要約、計算、レプリケートおよび分散に使用できるスキーマ・オブジェクトです。マテリアライズド・ビューは、データ・ウェアハウス、意思決定支援、分散コンピューティング、モバイル・コンピューティングなどの様々なコンピューティング環境に適しています。Enterprise Managerでは、マテリアライズド・ビューの作成および管理ができます。また、Enterprise Managerには、マテリアライズド・ビューに対して特定の操作を実行できる追加ツールのセットも用意されています。マテリアライズド・ビューの説明機能を使用すると、マテリアライズド・ビューが高速リフレッシュ可能かどうか、マテリアライズド・ビューを使用して実行できるクエリー・リライトのタイプ、およびPCTリフレッシュが可能かどうかが示されるため、マテリアライズド・ビューを使用して実行できる操作を判別できます。
Oracleでは、マスター表の変更後にマテリアライズド・ビューをリフレッシュすることで、マテリアライズド・ビュー内のデータを管理します。リフレッシュ方法には、増分（高速）リフレッシュまたは完全リフレッシュがあります。高速リフレッシュ方法を使用しているマテリアライズド・ビューでは、マスター表に加えられた変更の記録がマテリアライズド・ビュー・ログに保持されます。完全リフレッシュは、マテリアライズド・ビューが最初に定義されたときに発生します。ただし、マテリアライズド・ビューが、事前作成された表を参照している場合を除きます。また、完全リフレッシュは、マテリアライズド・ビューが有効な間いつでもリクエストできます。完全リフレッシュでは、マテリアライズド・ビューのための結果を計算するためにディテール表も読み取られるため、処理に時間がかかる場合があります。特に、大量のデータの読取りおよび処理が必要な場合時間がかかります。
クエリー・リライトを実行する場合、Enterprise Managerからアドバイスを受けることができます。これにより、クエリー・リライトを必要とする適切な操作を実行できます。クエリー・リライトを実行すると、表またはビューで表されているSQL文がディテール表で定義されている1つ以上のマテリアライズド・ビューにアクセスする文に変換されます。
マテリアライズド・ビューのリフレッシュは、リクエストごと、または一定の時間間隔で実行できます。手動でマテリアライズド・ビューをリフレッシュする場合は、Enterprise Managerの「アクション」メニューを使用します。
ディクショナリ・ベースラインは、特定の時間に取得された一連のデータベース定義を含むオブジェクトです。ベースラインは、その他の「変更の管理」アプリケーションが使用できる形式でEnterprise Managerリポジトリの内部に保存されます。Enterprise Managerを使用すると、特定の時点でデータベース・オブジェクト定義を取得し、再使用可能なベースラインの有効範囲を指定できます。ディクショナリ・ベースラインを取得すると、異なる時点で取得された各データベース・オブジェクトを比較し、データベース・オブジェクトに加えられた変更を追跡できます。
ディクショナリの比較により、2つのデータベース間、データベースとベースライン間、または1つのデータベース/ベースライン内の2つのスキーマ間のデータベース・オブジェクト定義の相違が識別されます。Enterprise Managerを使用すると、異なる時点で取得された2つのデータベース・オブジェクト定義間の相違を比較、表示、および追跡できます。比較結果には、同一のオブジェクト、異なるオブジェクト/属性、および左側または右側のソースにあるオブジェクトが表示されます。
ディクショナリの同期化では、2つのデータベース間またはデータベースとベースライン間のデータベース・オブジェクト定義の相違が同期化されます。
同期化は、同期化指定を使用して生成されます。同期化では、有効範囲の指定に個々のオブジェクトの名前は含まれません。指定できるのは、同期化のタイプと、包含または除外するスキーマのみです。追加で接頭辞を指定して、その接頭辞で始まる名前を持つオブジェクトのみを選択することも可能です。
ディクショナリの同期化では、任意のタイプのオブジェクト間で属性値の相違が同期化されます。同期化指定を使用して、複数の同期化バージョンを作成できます。各バージョンには、一意のバージョン番号と同期化日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース（スキーマ）の同期化を関連付けます。
これらの機能の詳細は、「データベースの変更管理」を参照してください。
アドバイザは、ユーザーが起動できる（つまり、Enterprise Managerが内部的に起動できる）プロシージャで、特定のオブジェクトを分析するように指定します。アドバイザはデータベースの様々な側面について報告し、ユーザーの操作を必要とする条件ごとに推奨操作を記述します。提供された自動化タスクで条件を修正できるという内容がアドバイザからレポートされる場合もあります。
アドバイザの中には、特定の状況に対してwhat-if分析を提供するものもあります。たとえば、UNDOアドバイザは、UNDOレコードの保存期間の変更がUNDO表領域のサイズに与える影響の分析を提供します。また、メモリー・アドバイザは、SGA構成要素のサイズの変更がパフォーマンスに与える影響をグラフィカルに表示します。
アドバイザの起動は、データベースのホームページの「関連リンク」ヘッダーの下にある、または別のページに一覧表示されている「アドバイザ・セントラル」リンクをクリックすると表示される「アドバイザ・セントラル」のホームページから実行できます。アラートからの推奨事項に応じてアドバイザを起動することもできます。アドバイザはデータベースをチューニングするための有益なツールです。通常、アラート生成はコストを低く抑えてパフォーマンスへの影響を最小限に抑えることを目的としているため、アドバイザはアラートよりも包括的な推奨事項を生成します。その一方で、アドバイザはユーザーによって頻繁に起動されるため、多大なリソースを消費し、詳細な分析を実行する場合があります。また、自動化された分析では、通常の操作の一環として与えられた時間に手動で生成する場合よりも多くの結果が提供されることもあります。この分析を一部のアドバイザのwhat-if機能と併用すると、他のソースからは入手できない重要なチューニング情報が提供されます。
次の項では、データベース・セキュリティの様々な側面について説明します。
|
ヒント: この後の項で説明されていないその他のトピックについては、『Oracle Database概要』のデータベース・セキュリティの概要に関する項を参照してください。 |
Oracleには、データベースへのアクセスおよびデータベースの使用を制御するセキュリティ機能が用意されています。権限およびロールによって、データおよび実行可能なSQL文タイプへのユーザー・アクセスが制御されます。権限には、システム権限とオブジェクト権限の2種類があります。システム権限は、CREATE、ALTERなど特定のデータベース操作を実行できるOracle定義の権限です。オブジェクト権限は、特定のオブジェクトへのアクセスを制御するOracle定義の権限です。
ユーザー（通常は管理者）は、権限およびその他のロールをグループ化する目的でロールを作成できます。これによって、ユーザーに複数の権限およびロールを付与する処理が容易になります。
他のユーザーに権限およびロールを付与できるのは、ADMIN/GRANTオプションによりこの処理を実行する権限を付与されたユーザーです。Oracle Enterprise Managerを使用すると、ユーザー、ロールおよびプロファイルを作成および管理できます。また、パスワードを期限切れにしたり、ユーザーをロックまたはロック解除したりするには、1件以上のユーザーに対してこれらの操作を適用します。ロールを管理する場合は、権限受領者の表示機能を使用して、指定のロールに割り当てられたすべてのユーザーおよびロールを表示できます。
監査とは、選択したユーザー・データベース・アクションを監視および記録することです。監査は、SQL文実行のタイプなどの個別のアクションに基づくことも、名前、アプリケーション、時間などの要素の組合せに基づくこともできます。Oracleデータベース内でコンテンツなどの特定の要素にアクセスした場合、または特定の要素を変更した場合には、セキュリティ・ポリシーによって監査が実行されることがあります。監査の設定および監査設定の調整は、Enterprise Managerインタフェース内で容易に実行できます。Enterprise Managerでは、データベース監査構成の表示と、監査オブジェクト、監査権限および監査文の管理ができます。監査証跡の内容も表示できます。即時利用可能なEnterprise Managerには、ログイン試行の成否およびSYSUSER操作の成否を監視する場合に役立つ監査レポートもあります。
Oracle Advanced Securityは、企業のコンプライアンスに対する取組みをサポートする透過的データ暗号化機能を提供します。アプリケーションを変更する必要はなく、既存のアプリケーションを以前と同じようにシームレスに使用できます。データは、ディスクに書き込まれる際に自動的に暗号化され、アプリケーションによってアクセスされる際に自動的に復号化されます。キー管理機能が組み込まれているため、暗号化キーの作成、管理および保護などの複雑なタスクを行う必要はありません。
Oracle Advanced Securityの透過的データ暗号化では、個々の表の列または表領域を暗号化できます。ユーザーが、データを暗号化された列に挿入すると、データベースによりデータは自動的に暗号化されます。ユーザーがその列を選択すると、データは複合化されます。この暗号化の手順は、透過的に実行されるため、高いパフォーマンスを提供し、実装も簡単です。
透過的データ暗号化は、組込み済のキー管理機能だけではなく、Advanced Encryption Standard（AES）などの業界標準の暗号化アルゴリズムを備えています。
Enterprise Managerインタフェースにより、透過的データ暗号化を容易に使用でき、ウォレットおよびマスター・キーの管理が可能になります。
Oracle Label Security（OLS）は、セキュリティ・ラベルを使用して、データの分類を割り当て、アクセスを制御することができるセキュリティ・オプションであり、プライバシおよび法規制のコンプライアンスに対する要件に対応するための機能です。OLSでは、複数レベルのセキュリティ、即時利用可能な行レベルのアクセス制御の他、Oracle Database Vault内で使用される要素が提供されています。
OLSでは次のことが可能です。
データの分類に基づいてアクセスを制御できます。アクセス制御の決定プロセスに強力なディメンションが追加されます。
政府および防衛機関向けアプリケーション用に従来の複数レベル・セキュリティ（MLS）ポリシーを強化できます。
Enterprise Managerインタフェースを使用すると、OLSポリシーの管理、表またはスキーマへのポリシーの割当て、およびユーザーへのラベルの割当てが可能です。ラベルは、データとユーザーの両方に割当て可能です。データに割り当てた場合、ラベルは既存の表に非表示の列として添付でき、既存のSQLに透過性を提供します。たとえば、機密性の高いデータを含む行にはHIGHLY SENSITIVEというラベルを付け、機密性が比較的低い行にはSENSITIVEというラベルを付けることができます。
ユーザーがデータへのアクセスを試みると、OLSによって、ユーザー・ラベルとデータ・ラベルが比較され、アクセスを許可するかどうかが決定されます。VPDとは異なり、OLSでは、即時利用可能なセキュリティ・ポリシー、およびラベルを定義し格納するためのメタデータ・リポジトリが提供されています。
仮想プライベート・データベース（VPD）では、行レベルおよび列レベルでのセキュリティを強化できます。セキュリティ・ポリシーにより、過失または悪意によるデータの破壊、またはデータベース・インフラストラクチャの被害からデータベースを保護する手段が確立されます。
VPDは、権限およびロールなどのセキュリティ保護の精度が十分ではない場合に役立ちます。たとえば、すべてのユーザーに従業員表へのアクセスを許可し、従業員へのアクセスはアクセスするユーザーと同じ部門の従業員のみに制限するセキュリティ・ポリシーを作成できます。Enterprise Managerインタフェースを使用すると、VPDポリシーおよびそれに関連する様々な操作を管理できます。
基本的に、データベースによって、Oracle VPDのセキュリティ・ポリシーが適用されている表、ビューまたはシノニムに対して発行されたSQL文に対して動的なWHERE句が追加されます。WHERE句により、資格証明がセキュリティ・ポリシーの条件を満たしているユーザーのみに、保護されたデータへのアクセスが許可されます。
アプリケーション・コンテキストを使用すると、ユーザーのセッション情報の特定の側面を利用するアプリケーションを作成できます。アプリケーション・コンテキストは、アプリケーションが使用できる属性を定義および設定し、それにアクセスする方法を提供します。
アプリケーション・コンテキストはネームスペースです。各アプリケーション・コンテキストのネームスペースには、複数の属性（名前/値のペア）を設定できますこれらは、ユーザー・セッションに関連付けられ、設定およびアクセスは複数回行えます。
「グローバルに初期化されたアプリケーション・コンテキスト」属性をOracle Internet Directory内に格納し、1人以上のエンタープライズ・ユーザーに割当てできます。エンタープライズ・ユーザーは、ログインすると自動的に属性を取得し、この属性を使用してアプリケーション・コンテキストを初期化できます。
Oracle Database Enterprise Editionの機能であるエンタープライズ・ユーザー・セキュリティをOracle Identity Managementと組み合せて使用することで、データベース・ユーザーおよび承認を1箇所で集中管理できます。このため、ユーザーのプロビジョニングおよびパスワードのリセットにかかるコストを大幅に削減できます。この機能では、新しいアプリケーション開発だけではなく既存のアプリケーションも考慮されています。
エンタープライズ・ユーザー・セキュリティの使用により、次に示すように様々な点においてセキュリティが向上します。
データベース・ユーザーのプロビジョニングおよびプロビジョニングの解除の集中化。
パスワードの集中管理およびセルフサービスによるパスワード・リセット機能。
グローバル・データベース・ロールを使用した認証の集中管理。
Payment Card Industry（PCI）、サーベンス・オクスリー（SOX）法、欧州連合プライバシ指令（EU Privacy Directive）および医療保険の相互運用性と説明責任に関する法令（Healthcare Insurance Portability and Accountability Act: HIPAA）のすべてにおいて、詐欺罪、なりすまし犯罪、金融上の不正や罰則につながる可能性のある、機密情報へのアクセス、公開または変更に対する厳密な内部統制が義務付けられています。
Oracle Database Vaultは、次に示すような手段により、一般的な法規制のコンプライアンス要件に対応し、内部脅威のリスクを削減します。
高い権限を付与されたユーザー（DBA）によるアプリケーション・データへのアクセスの防止。
責務の分離の強化。
アプリケーション、データおよびデータベースに対してアクセスが可能なユーザー、時期、場所および方法の制御。
使用しているデータベースでDatabase Vaultを有効にすると、Enterprise Managerにより、Database Vaultポリシーの監視に使用できるインタフェースが使用できるようになり、さらにポリシーが複数のデータベースに伝播されます。
データ・マスキング（データ・スクランブリングおよびデータ匿名化とも言う）は、本番データベースからテスト用データベースまたは本番以外のデータベースにコピーされる機密情報を、マスキング・ルールに基づいて外見は本物のようで内容は本物ではないデータに置き換えるプロセスです。データ・マスキングは、機密データまたは規制されたデータを他の非本番ユーザー（アプリケーション開発者のような内部ユーザー、オフショアのテスト会社のような外部ビジネス・パートナ、サプライヤ、カスタマなど）と共有する必要がある状況に対し、実質上あらゆる場合に理想的です。これらの非本番ユーザーは、オリジナル・データの一部にはアクセスする必要がありますが、すべての表のあらゆる列を見る必要はありません。政府の規制によって情報が保護されている場合は、特にそうです。
データ・マスキングを使用すると、組織ではオリジナル・データに類似した特性を持つ、外見は本物で完全に機能するデータを生成し、機密情報のかわりに使用することができます。これと対照的な暗号化や仮想プライベート・データベースの場合は、データが単に隠されるだけであり、適切なアクセス権やキーがあればオリジナル・データを取得できます。データ・マスキングの場合は、元の機密データを取得することも、元の機密データにアクセスすることもできません。
情報コンテンツを不適切な開示から保護すべきデータの例としては、名前、住所、電話番号、クレジット・カードの詳細情報などがあります。本物の本番稼働データベース環境には、貴重な機密データが含まれており、そのような情報へのアクセスは厳重に規制されます。ただし、各本稼働システムには通常、開発用のコピー・データがあり、そのようなテスト環境に対する規制はさほど厳しくありません。これにより、データが不適切に使用されるリスクが非常に高くなります。データ・マスキングでは、データベースの機密レコードを変更し、利用可能ではあるものの機密情報も個人情報も含まれないようなデータにすることができます。マスクされたテスト・データは、アプリケーションの整合性を確保するために、外見はオリジナル・データに類似しています。
テスト情報をマスキングするとデータが誤って漏れるのを防止できるため、データのマスキングはビジネス・セキュリティの観点から見て賢明な予防策です。多くの場合、データのマスキングは法律上の義務です。Enterprise Manager Data Masking Packを使用すると、組織では法律上の義務を満たし、サーベンス・オクスリー法、カリフォルニア州データベース機密保護違反通知法（CA上院法案1386）、欧州連合データ保護指令のようなグローバルな規制基準に応じることができます。
法的必要条件は国によって異なりますが、個人的な消費者情報の機密性および整合性を保護するためのなんらかの形態の規制が現在ではほとんどの国に存在しています。たとえば、米国の場合、財務プライバシ権法（1978年）により財務レコードに対する第4修正条項の法的保護が策定され、これを必要とする州法は多数あります。同様に、米国における医療保険の相互運用性と説明責任に関する法令（US Health Insurance Portability and Accountability Act: HIPAA）では、個人医療情報の保護が策定されています。
データのマスキングを対象として、Data Masking Packでは次の2つの主要な機能を提供しています。
すぐに利用可能な一連のマスキング・フォーマットが入ったフォーマット・ライブラリです。このライブラリは、マスキングに利用可能な一連のフォーマット・ルーチンから構成されています。マスキング・フォーマットには、ユーザーが作成したものか、Oracle付属のデフォルト・マスキング・フォーマットのリストから取得したものを使用できます。
組織では、規制の対象になる共通するすべての情報に対してマスキング・フォーマットを作成し、機密データが属するデータベースとは無関係に機密データに適用できるようにすることをお薦めします。そうしておけば、組織全体にわたり、全機密データに対するマスキングを首尾一貫して行うことができます。
マスキング定義では、1つのデータベース内の1つまたは複数の表に実装されるデータ・マスキング操作を定義します。マスキング定義では、データのマスキングに使用する表の列とフォーマットを関連付けます。また、データベース内で正式に宣言されない列間の関係も、関連列を使用して維持されます。
マスキング定義を作成するには、データがマスキングの対象となる表の列とマスク・データのフォーマットを指定します。マスク対象の列が一意な主キー制約または外部キー制約に関与している場合は、データ・マスキングにより、それらの制約に違反しないような値が生成されます。マスキング操作には、新しいマスキング定義を作成することもできますし、既存の定義を使用することもできます。通常は、マスキング定義をファイルにエクスポートした後、他のシステムにインポートします。テスト・サイトと本番サイトが、別々のOracle管理システムにある場合や、まったく別のサイトにある場合には、これが重要です。
データ・マスキングは、繰り返し使用され、クローニング先で更新されていくプロセスです。これはセキュリティ管理者が管理し、データベース管理者によってオーケストレートされます。データ・マスキングの構成を初めて実行する場合は、まずテスト・システムでマスキング定義をテストし、その後、より多い数の列をマスキング定義に追加してテストを実行し、正しく機能することと、アプリケーション制約に違反しないことを確認します。このプロセスでは、実データへの組込み参照をすべて削除する際に、参照の整合性が維持されるよう注意する必要があります。データ・マスキングの構成が終わったら、既存の定義を使用して、クローニング後に繰り返しマスキングを実行できます。ただし、新しいスキーマ変更によって新規データおよび列をマスキングする必要がある場合、マスキング定義もそれに応じて更新する必要があります。
|
関連項目: Enterprise Managerのオンライン・ヘルプおよび各「データのマスキング」ページのヘルプにある「データ・マスキング定義の作成」 |
図6-15は、本番データベースをステージング・リージョンにクローニングし、そこでマスキングする過程を示しています。マスキングのプロセスでは、ステージング領域およびテスト領域は本番サイトのように厳重に規制されます。
マスキング・プロセスが終わると、データベースは広く利用可能な状態にすることができます。データベースを別のサード・パーティ・サイトに移送する場合は、データ・ポンプ・エクスポート・ユーティリティを使用してリモート・サイトにダンプ・ファイルを移送する必要があります。ただし、マスキングされたデータを社内に保存する場合は、次の項を参照してください。
この項のタスク順序では、データ・マスキングのワークフローを具体的に示すと同時に、一部のタスク順序では、この章の別の場所にある追加情報を紹介します。この順序を確認する前に、このプロセスを完了するためのオプションが2つあることに注意してください。
本番データベースをステージング領域にクローニングし、マスキングします。その後、社内のテスト実行者または外部の顧客に配信する前に、そのデータベースを別のデータベースにエクスポート/インポートします。これは最もセキュアな方法です。
本番データベースをマスキングされたステージング領域にクローニングし、そのステージング領域を新しいテスト・リージョンにします。この場合は、SYSDBAアクセスや、データベース・ファイルへのアクセス権をテスト実行者に付与しないでください。付与するとセキュリティが低下します。マスキングされたデータベースでは、未使用ブロックと空きリストに元のデータが含まれます。この情報は、データを別のデータベースにエクスポート/インポートすることでのみパージできます。
次の手順では、データ・マスキング・プロセスを順番に示します。サポート情報として、他の項に対する参照も含まれます。
アプリケーション・データベースを見直し、機密情報のソースを特定します。
機密データのマスキング・フォーマットを定義します。マスキング・フォーマットがシンプルであるか複雑であるかは、組織の情報セキュリティに対するニーズによって異なります。
詳細は、「データ・マスキング・タスクの順序」を参照してください。
それらのマスキング・フォーマットに表の列を関連付けるマスキング定義を作成します。データ・マスキングにより、データベースの外部キー関係が決定され、外部キー列がマスクに追加されます。
詳細は、「マスキング定義の作成」を参照してください。
オプションで、データベースで定義されておらず、アプリケーションによって施行される依存列を宣言します。これらの追加の制約を受け入れるようなマスキングが実行されることが前提になります。
それには、アプリケーション・スキーマの知識が必要です。アプリケーションのドキュメントを参照して、機密データが含まれる表と列の関係を調べ、アプリケーション・データが完全にカバーされるようにしてください。
詳細は、「依存列の追加」を参照してください。
マスキング定義を保存してマスキング・スクリプトを生成します。
本番データベースをステージング領域にクローニングし、クローニング後に使用するマスキング定義を選択します。Enterprise Managerを使用してクローニングを実行すると、Enterprise Managerのクローニング・ワークフローにマスキングを追加できます。一方、Enterprise Managerを使用せずにクローニングを実行する場合、クローニングの完了後にEnterprise Managerからマスキングを開始する必要があります。クローニングされたデータベースは、本番環境用の機密データがまだ含まれているので、本稼働システムと同じ権限で制御する必要があります。
クローニングが終わったら、パスワードを変更するだけでなく、データベース・リンク、ストリーム、または外部データ・ソースへの参照の更新または無効化も必ず実行してください。クローニングされたデータベースのバックアップを採取します（マスキングされたデータが含まれる表のバックアップは最低限必要です）。そうしておけば、マスキング定義をさらに調整する必要がある場合に、オリジナル・データをリストアできます。
詳細は、「本番データベースのクローニング」を参照してください。
マスキングされたデータが情報セキュリティ要件を満たしているかどうかを確認します。満たしていない場合は、マスキング定義を調整し、変更した表をリストアした後、マスキング定義の最適なセットが得られるまでマスキング定義の適用を繰り返します。
マスキングが終わったら、アプリケーション、レポートおよびビジネス・プロセスをすべてテストし、それらが機能していることを確認します。すべて正常に機能している場合は、マスキング定義をエクスポートし、バックアップとして保存することができます。
ステージング・サイトのマスキング後、テスト・リージョンにクローニングする前に、MGMT_DM_TTという表をすべて削除します。これらの一時表は、元の機密列値とマスク値間のマッピングを含んでいるため、機密データとして扱う必要があります。
これらの一時表は、デフォルトの「マスキング中に作成した一時表の削除」オプションにより、マスキング中に自動的に削除されます。ただし、このオプションの選択を解除することで、これらの一時表を維持できます。この場合、テスト・リージョンにクローニングする前にユーザーの責任で一時表を削除します。
マスキングが完了したら、置換列の形式または表の列の形式で使用するためにロードされたすべての表を必ず削除します。これらの表には、表の列の形式または置換形式で使用されるマスク値が含まれます。セキュリティ上の理由から、この情報は消去することをお薦めします。
詳細は、「決定論的マスキング」を参照してください。
データベースをテスト・リージョンにクローニングするか、データベースを新しいテスト・リージョンとして使用します。データベースを外部サイトまたはセキュアでないサイトにクローニングする場合は、エクスポートまたはインポートを使用し、データベース・ファイル自体ではなくデータベース内のデータのみを操作の対象としてください。
マスキング定義をアプリケーション・データベース管理者に提供し、テスト用のクローニングされた本番環境の一部としてデータベースをマスキングできるようにします。
マスキング定義には、マスキング定義に含まれる任意の列に対して1つ以上のマスキング・フォーマットが必要です。マスキング定義に列を追加する場合、手動でマスキング・フォーマットを作成するか、それらをフォーマット・ライブラリからインポートできます。一般的には、フォーマット・ライブラリのマスキング・フォーマットを操作する方が効率的です。
フォーマット・ライブラリにマスキング・フォーマットを作成するには、次のようにします。
「データベース」ターゲットのロールアップ・ページに移動します。「データベース」ページが表示されます。
「データ・マスキングのフォーマット・ライブラリ」リンクをクリックします。Oracle Enterprise Managerに付属する事前定義済のフォーマットが含まれたフォーマット・ライブラリが表示されます。
「作成」をクリックします。マスキング・フォーマットを定義できる「フォーマットの作成」ページが表示されます。
|
ヒント: ページのユーザー・コントロールの詳細は、「フォーマット」ページのオンライン・ヘルプを参照してください。 |
新規フォーマットに必要な名前を指定し、「追加」ドロップダウン・リストからフォーマット・エントリ・タイプを選択して、「実行」をクリックします。
選択したフォーマット・エントリにデータを入力できるページが表示されます。たとえば、「配列リスト」を選択した場合、後続のページでは、New York、New Jersey、New Hampshireなどの値のリストを入力できます。
必要に応じて続けて別のフォーマット・エントリを追加します。
終了したら、オプションでユーザー定義関数または後処理関数を指定し（「ユーザー定義関数および後処理関数の指定」を参照）、「OK」をクリックしてマスキング・フォーマットを保存します。
「フォーマット・ライブラリ」ページが再表示され、新しく作成したフォーマットが「フォーマット・ライブラリ」表に表示されます。
|
ヒント: ページのユーザー・コントロールの詳細は、「フォーマット・ライブラリ」および「フォーマットの作成」ページのオンライン・ヘルプを参照してください。 |
ユーザー定義関数および後処理関数の指定
必要に応じて、「フォーマットの作成」ページでユーザー定義関数および後処理関数を指定できます。ユーザー定義の選択には、「追加」ドロップダウンを使用できます。また、後処理関数フィールドはページの一番下にあります。
ユーザー定義関数
ユーザー定義関数を指定するには、「追加」ドロップダウンから「ユーザー定義関数」を選択し、「実行」をクリックして、入力フィールドにアクセスします。
ユーザー定義関数は、元の値を入力として受け取り、マスク値を戻します。出力値のデータ型と一意性は、元の出力値と互換性がある必要があります。それ以外の場合、ジョブの実行に失敗します。また、ユーザー定義関数は、SELECT文で起動できるPL/SQLファンクションです。シグネチャは、次のように戻されます。
Function udf_func (rowid varchar2, column_name varchar2, original_value varchar2) returns varchar2;
rowidは、第3引数のoriginal_valueの値を含む行の最小値（ROWID）です。
column_nameは、マスキングする列の名前です。
original_valueは、マスキングする値です。
つまり、この関数は、元の値の入力文字列を受け取り、マスク値を戻します。
入力値と出力値は、両方ともVARCHAR2です。たとえば、数値をマスキングするユーザー定義関数は、入力として100を受け取り（数値100の文字列表現）、99を戻します（数値99の文字列表現）。値は、表への挿入時に適切にキャストされます。値をキャストできない場合、マスキングは失敗します。
後処理関数
後処理関数を指定するには、「後処理関数」フィールドに関数を入力します。
後処理関数は、ユーザー定義関数と同じシグネチャを持ちますが、マスキング・エンジンが生成したマスク値を受け取り、マスキングに使用できるマスク値を戻します。次の例を参照してください。
Function post_proc_udf_func (rowid varchar2, column_name varchar2, mask_value varchar2) returns varchar2;
rowidは、mask_valueの値を含む行の最小値（ROWID）です。
column_nameは、マスキングする列の名前です。
mask_valueは、マスキングする値です。
マスキング・フォーマット・テンプレートの使用
1つ以上のフォーマットを作成したら、「フォーマットの作成」ページでテンプレートとしてフォーマット定義を使用できます。このページでは、新規フォーマットを最初から作成することなく、ほとんどのフォーマットを異なる名前で実装し、必要に応じてそのエントリを変更できます。
既存のフォーマットに似た新規フォーマットを作成するには、「フォーマット・ライブラリ」ページでフォーマットを選択し、「類似作成」をクリックします。マスキング・フォーマットには、以前に自分で定義したフォーマットか、デフォルトのマスキング・フォーマットのリストから取得したフォーマットを選択できます。これらの汎用マスキング・フォーマット定義は、様々なアプリケーションに使用できます。
様々なOracle付属の事前定義済のマスキング・フォーマット定義と、要件に合せてそれらを変更する方法の詳細は、「Oracle付属の事前定義済のマスキング・フォーマットの使用」を参照してください。
次の項では、様々なOracle付属のフォーマット定義と、要件に合せてそれらを変更する方法について説明します。
すべてのフォーマット定義は、次の一般的なパターンに準拠します。
ランダム数値またはランダム桁数を生成します。
前述の生成値に後処理を実行し、最終結果が有効で実用的な値になるようにします。
たとえば、クレジット・カード番号が有効であるためには、Luhnチェックに合格する必要があります。つまり、クレジット・カード番号の最後の桁はチェックサム桁であり、この桁は常に計算されます。また、最初の数桁は、カード・タイプを示します（MasterCard、Amex、Visaなど）。したがって、クレジット・カードのフォーマット定義は、次のようになります。
ランダムで一意な10桁の数値を生成します。
後処理関数の使用により、既知のカード・タイプ接頭辞を追加して最後の桁を計算することで、前述の値を適切なクレジット・カード番号に変換します。
このフォーマットにより、100億個の異なるクレジット・カード番号を生成できます。
次の項では、これらの定義の異なるカテゴリについて説明します。デフォルトでは、これらのマスキング・フォーマットは、ハイフン（-）形式などの異なるフォーマット・スタイルでも使用できます。フォーマット・スタイルは、必要に応じて変更できます。
クレジット・カード番号
デフォルトで、フォーマット・ライブラリには、クレジット・カード用の異なるフォーマットが多数用意されています。これらのフォーマットにより生成されたクレジット・カード番号は、アプリケーションによる標準的なクレジット・カード検証テストに合格するため、有効なクレジット・カード番号を装うことができます。
次のようなクレジット・カード・フォーマットを使用できます。
MasterCard番号
Visaカード番号
American Expressカード番号
Discover Card番号
任意のクレジット・カード番号（すべてのタイプのカードに属するクレジット・カード番号）
クレジット・カード番号を格納するために、次のような異なるスタイルを使用できます。
番号のみ
4桁ごとに空白を挿入
4桁ごとにハイフン（-）を挿入、など
マスキングされた値を一定のフォーマット・スタイルで実装するには、DM_FMTLIBパッケージのDM_CC_FORMAT変数を設定します。DM_FMTLIBパッケージのインストール方法の詳細は、「DM_FMTLIBパッケージのインストール」を参照してください。
米国社会保障番号
デフォルトで、有効な米国社会保障番号（SSN）を生成できます。これらのSSNは、有効なSSNを検証する通常のアプリケーション・テストに合格します。
フォーマット・スタイルを調整するには、DM_FMTLIBパッケージのDM_SSN_FORMAT変数を設定します。たとえば、この変数を「-」に設定すると、一般的な社会保障番号は123-45-6789のように示されます。
ISBN番号
フォーマット・ライブラリを使用して、10桁または13桁のISBN番号を生成できます。これらの番号は、標準的なISBN番号検証テストに合格します。これらのISBN番号は、事実上すべてランダムです。他のフォーマット定義と同様に、DM_ISBN_FORMATに値を設定することでISBNフォーマットのスタイルを調整できます。
UPC番号
フォーマット・ライブラリを使用して、有効なUPC番号を生成できます。これらの番号は、有効なUPC番号を検証する標準的なテストに合格します。フォーマット・スタイルを調整するには、DM_FMTLIBパッケージのDM_UPC_FORMAT値を設定します。
カナダ社会保険番号
フォーマット・ライブラリを使用して、有効なカナダ社会保険番号（SIN）を生成できます。これらの番号は、カナダSIN番号を検証する標準的なテストに合格します。フォーマット・スタイルを調整するには、DM_FMTLIBパッケージのDM_CN_SIN_FORMAT値を設定します。
北米電話番号
デフォルトで、フォーマット・ライブラリには、米国およびカナダの様々な電話番号が用意されています。これらの番号は、見かけ上有効で現実的な番号であり、アプリケーションで採用されている標準的な電話番号検証テストに合格します。次のタイプの番号を生成できます。
任意の北米電話番号
任意のカナダ電話番号
任意の米国電話番号
事前定義済のマスキング・フォーマットでは、DM_FMTLIBパッケージで定義されているファンクションを使用します。このパッケージは、Enterprise Managerリポジトリ・データベースのDBSNMPスキーマに自動的にインストールされます。（リポジトリ・データベースではなく）ターゲット・データベースで事前定義済のマスキング・フォーマットを使用するには、手動でそのデータベースにDM_FMTLIBパッケージをインストールする必要があります。これを行うには、次の手順に従います。
Enterprise Managerのインストール環境で次のスクリプトを検索します。
$ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgdef.sql $ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgbody.plb
これらのスクリプトをターゲット・データベースのインストール環境にあるディレクトリにコピーし、DBSNMPスキーマにパッケージを作成できるユーザーとしてSQL*Plusに接続してから、これらのスクリプトを実行します。
終了したら、マスキング定義で事前定義済のマスキング・フォーマットを使用できます。
データ・マスキングは、Oracle Database 9i以降をサポートしています。Enterprise Manager 11.1 Grid Controlでは、11.1のエージェントが必要です。11.1より前のバージョンを保有している場合、次の回避策を実行することで、そのバージョンを使用できます。
次のファイルを置き換えます。
AGENT_HOME/sysman/admin/scripts/db/reorg/reorganize.pl
... 次のファイルと置き換えます。
OMS_HOME/sysman/admin/scripts/db/reorg/reorganize.pl
サポートされているデータ型のリストは、リリースによって異なります。
Grid Control 10gリリース5（10.2.0.5）およびDatabase 11gリリース2（11.2）
数値型
次の数値型では、「配列リスト」、「削除」、「固定数値」、「NULL値」、「後処理関数」、「元のデータの保持」、「ランダム小数」、「ランダム数値」、「シャッフル」、「SQL式」、「置換」、「表の列」、「切捨て」、「ユーザー定義関数」フォーマットを使用できます。
NUMBER
FLOAT
RAW
BINARY_FLOAT
BINARY_DOUBLE
文字列型
次の文字列型では、「配列リスト」、「削除」、「固定数値」、「固定文字列」、「NULL値」、「後処理関数」、「元のデータの保持」、「ランダム小数」、「ランダム桁数」、「ランダム数値」、「ランダム文字列」、「シャッフル」、「SQL式」、「置換」、「部分文字列」、「表の列」、「切捨て」、「ユーザー定義関数」フォーマットを使用できます。
CHAR
NCHAR
VARCHAR2
NVARCHAR2
日付型
次の日付型では、「配列リスト」、「削除」、「NULL値」、「後処理関数」、「元のデータの保持」、「ランダム日付」、「シャッフル」、「SQL式」、「置換」、「表の列」、「切捨て」、「ユーザー定義関数」フォーマットを使用できます。
DATE
TIMESTAMP
Grid Control 11gリリース1（11.1.0.1）
前述のGrid Control 10.2およびDatabase 11.2に対するサポートの他に、Grid Control 11.1では、固定文字列、固定数値およびNULLを使用できる次のLOB型もサポートされます。
CLOB
NCLOB
BLOB
マスキング定義を作成する前に、次のアドバイス情報を確認してください。
選択したフォーマットが、チェック制約に違反していないことと、そのデータを使用するアプリケーションを中断させないことを確認してください。
トリガーおよびPL/SQLパッケージでは、データ・マスキングによりオブジェクトが再コンパイルされます。
パーティション表（特にパーティション・キー）をマスキングする場合、注意が必要です。この場合、行が別のパーティションに移動する可能性があります。
データ・マスキングでは、クラスタ表、オブジェクト表のマスキング情報、XML表および仮想列はサポートされません。リレーショナル表はマスキングでサポートされます。
オブジェクトが表の上層に位置する場合（ビュー、マテリアライズド・ビュー、PL/SQLパッケージなど）、それらのオブジェクトは有効になるように再コンパイルされます。
マスキング定義を作成するには、次のようにします。
「データベース」ターゲットのロールアップ・ページに移動します。「データベース」ページが表示されます。
「関連リンク」セクションの「データ・マスキング定義」リンクをクリックします。「データ・マスキング定義」ページが表示されます。このページで、新規マスキング定義の作成とスケジュール、および既存のマスキング定義の管理を行うことができます。
「作成」をクリックして「マスキング定義の作成」ページに移動します。マスキング定義には、表の列と各列のフォーマットに関する情報が含まれます。マスキングする列とそのまま残す列を選択できます。
必要なデータベース名を指定します。「データベース」フィールドには、「データ・マスキング定義」ページにアクセスする前に選択したデータベース・ターゲットのデータベース名が表示されます。使用可能な任意のデータベースを指定できます。リストを検索するには、懐中電灯アイコンをクリックします。
「追加」をクリックして「列の追加」ページに移動します。このページで、マスキング用の1つ以上の列を追加できます（外部キー列が自動的に追加されます）。マスキング定義では少なくとも1つの列を追加する必要があります。
「検索」セクションで、少なくともスキーマ名を入力し、オプションで結果をフィルタするための他の検索フィールドに値を入力します。その後、「検索」をクリックします。
1つ以上の列を選択し、「マスキング定義の作成」ページで後でフォーマットするか、（選択した列のデータ型が同一の場合）その場でフォーマットします。
|
ヒント: データ型の詳細は、「サポートされているデータ型」を参照してください。 |
選択した列をグループとしてマスキングするかどうかを決定します。
複数の列を個別にではなくまとめてマスキングする場合、このチェック・ボックスを選択します。次に、2つ以上の列を選択し、後で「グループ・マスクの定義」ページでフォーマットを定義すると、それらの列がまとめて表示されます。フォーマット・タイプまたはマスキング表に選択した内容は、すべての列にまとめて適用されます。
グループとしてマスキングする列は、すべて同じ表の列である必要があります。
「追加」をクリックしてマスキング定義に列を追加し、「マスキング定義の作成」ページに戻って後で列のフォーマットを定義するか、「フォーマットの定義と追加」をクリックしてその場で列のフォーマットを定義します。
「フォーマットの定義と追加」機能では、かなりの時間を節約できます。同じデータ型の複数の列を選択して追加する場合、「追加」をクリックするときのように列ごとにフォーマットを定義する必要はありません。たとえば、社会保障番号（SSN）を検索して100個のSSN列を生成する場合、それらの列をすべて選択し、「フォーマットの定義と追加」をクリックすれば、すべての列のSSNフォーマットをインポートできます。
前の手順で「追加」をクリックした場合
操作を進めるには、「マスキング定義の作成」ページで列のフォーマットを定義する必要があります。準備ができていれば、フォーマットする列の「フォーマット」列ページでアイコンをクリックします。選択した列をグループとしてマスキングすることを「列の追加」ページで指定したかどうかに応じて、「列マスクの定義」または「グループ・マスクの定義」が表示されます。どちらの場合も、詳細はこの手順の後続の内容を参照してください。
前の手順で「フォーマットの定義と追加」をクリックし、「選択した列をグループとしてマスキング」を選択していない場合
「列マスクの定義」ページが表示されます。このページで、「マスキング定義の作成」ページに列を追加する前に、列のフォーマットを定義できます。
必須のデフォルト条件のフォーマット・エントリを指定するため、ドロップダウン・リストからフォーマット・エントリを選択して「追加」をクリックするか、「フォーマットのインポート」をクリックして「フォーマットのインポート」ページで事前定義済のフォーマットを選択し、「インポート」をクリックします。
Oracle付属の事前定義済のマスキング・フォーマット定義の詳細は、「Oracle付属の事前定義済のマスキング・フォーマットの使用」を参照してください。
別の条件を追加するには、「条件の追加」をクリックして新しい条件行を追加し、前の手順に従って1つ以上のフォーマット・エントリを指定します。図6-16に、ユーザー入力の例を示します。
列のフォーマット作業が終了したら、「OK」をクリックして「マスキング定義の作成」ページに戻ります。
前の手順で「フォーマットの定義と追加」をクリックし、「選択した列をグループとしてマスキング」を選択した場合
「グループ・マスクの定義」ページが表示されます。このページで、「マスキング定義の作成」ページに表示されるグループ列のフォーマット・エントリを追加できます。
使用可能ないずれかのフォーマット・タイプを選択します。フォーマット・タイプの詳細は、オンライン・ヘルプを参照してください。
オプションで、グループに列を追加します。
グループのフォーマット作業が終了したら、「OK」をクリックして「マスキング定義の作成」ページに戻ります。「列」表に構成が表示されます。
「OK」をクリックして定義を保存し、「データ・マスキング定義」ページに戻ります。
この時点で、スーパー管理者は互いのマスキング定義を確認できます。
定義を選択して「スクリプトの生成」をクリックし、前に選択した列をマスキングするためのデータベース・コマンドのリストにスクリプトを表示します。
表示される「スクリプト生成結果」ページで、データベースのクローニングとマスキング、またはデータ・マスキング・ジョブのスケジュールを行うことができます。
|
注意: マスキング定義または再編成に含まれている表に、データ型LONGの列がある場合、警告メッセージが表示される場合があります。詳細は、「LONG列を含むデータ・マスキングの使用方法」を参照してください。 |
次のいずれかの処理を選択します。
本番データベースで作業する場合、「クローニングとマスキング」をクリックします。
テスト・データベースですでに作業しており、そのデータベースのデータを直接マスキングする場合、「ジョブのスケジュール」をクリックします。
次の前提条件は、依存列として定義される列に適用されます。
マスキング用としてすでに含まれている列は、有効な依存列になりません。
外部キー列、または外部キー列に参照される列は、依存列に指定できません。
依存列のデータは、親列のデータに準拠している必要があります。
列がこれらの基準を満たしていない場合、依存列を追加しようとすると、「無効な依存列」というメッセージが表示されます。
依存列を追加するには、次のようにします。
「マスキング定義の作成」ページで、フォーマットする列に対応する「依存列」の「追加」列にある「追加（+）」アイコンをクリックします。「依存列の追加」ページが表示されます。
「検索」セクションで、少なくともスキーマ名を入力または（最初に懐中電灯アイコンをクリックすることで）選択し、「検索」をクリックします。
下に表示されるリストから1つ以上の列名を選択し、「追加」をクリックします。
「マスキング定義の作成」ページが再表示され、追加した依存列がページの一番下の「依存列」表に表示されます。依存列は、親列に指定されたものと同じフォーマットを使用してマスキングされます。
マスキング定義のターゲット・データベースをクローニングおよび（オプションで）マスキングするには、次のようにします。
作業を進める前に、Provisioning and Patch Automation Packのライセンスを保持していることを確認します。データベースのクローニング機能には、このライセンスが必要です。
「データ・マスキング定義」ページで、クローニングするマスキング定義を選択し、「アクション」ドロップダウンから「データベースのクローニング」を選択し、「実行」クリックします。テスト・システムを作成してマスキングを実行できる、データベースのクローニング・ウィザードが表示されます。
通常のデータベースのクローニングと同じように、ウィザードのステップを進めます。詳細は、各ステップのオンライン・ヘルプを参照してください。
ウィザードの「データベース構成」ステップで、マスキング定義を追加します。
クローン・ジョブをスケジュールして実行します。
オブジェクトの再編成スクリプトの生成が完了すると、影響レポートが表示されます。再編成に含まれている表に、データ型LONGの列がある場合、次の警告メッセージが影響レポートに表示される場合があります。
Reorganization includes a table with a LONG column. To support reorganization of tables with LONG columns that are greater than 32KB, the external procedure MGMT$REORG_MOVELONGCOMMAND must be configured properly. It has been determined this external procedure is not currently configured as expected.
このメッセージが影響レポートに表示される場合、LONG列のデータを調査してください。データが32KB未満の場合、このメッセージは無視できます。データが32KBを超える場合、オブジェクトの再編成ウィザードから戻り、次の手順を実行してデータベースの外部プロシージャの接続を構成してください。
ターゲット・データベースおよびそのリスナーを停止します。
$ORACLE_HOME/network/admin/tnsnames.oraを編集して、次のエントリを追加します。
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(PROTOCOL=IPC)(KEY=EXTPROC))
(CONNECT_DATA =
(SID=PLSExtProc)(PRESENTATION=RO)))
tnsnames.oraへの変更を保存し、エディタを終了します。
$ORACLE_HOME/network/admin/listener.oraを編集して、次の変更を行います。
listener.ora内のエントリは、次の例と類似しています。
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)(HOST = host1.us.oracle.com)(PORT = 1521)))))
このエントリに新しいADDRESS_LISTパラメータを追加します。
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)(HOST = host1.us.oracle.com) (PORT = 1521)))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)))))
listener.ora内の2番目のエントリは、次の例と類似しています。
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (SID_NAME = db1)(ORACLE_HOME = /scratch/oracle/db1)))
このエントリに新しいSID_DESCパラメータを追加します。
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (SID_NAME = db1)(ORACLE_HOME = /scratch/oracle/db1))
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /scratch/oracle/db1)
(PROGRAM = extproc)
(ENVS =
"EXTPROC_DLLS=ANY,
LD_LIBRARY_PATH=/usr/lib:/scratch/oracle/db1/lib")))
listener.oraへの変更を保存し、エディタを終了します。
次のファイルが、データベース・インストール内に存在することを確認します。
$ORACLE_HOME/lib/libnmuc.so
リスナーおよびデータベースを再起動します。
オブジェクトの再編成を起動し、スクリプトを生成します。今回は、影響レポートに警告メッセージは表示されません。
ジョブをスケジュールして発行します。次のメッセージが、ジョブ出力ログに表示されます。
Copy with PLSQL block failed due to size of long. Using Mgmt$Reorg_MoveLongCommand to perform the reorganization.
このメッセージは予期されたものです。LONG列を含む表は正常にマスキングまたは再編成されました。
データ・マスキングの方法は、LONG列を含む表と含まない表とで異なります。LONG列を含む表は、UPDATEのSQL文を使用して更新され、マスキングする必要のある列のみが変更されます。LONG列自体はそのまま維持されます。LONG列を含まない表は、マスキングされた値で表データを削除、再作成および再ロードすることでマスキングされます。この処理は、更新よりも高速で実行されるため、SQLによってサポートされないLONG列を除き、使用されます。
LONG列の表がマスキングされる際、UPDATE文は、フラッシュバック問合せを使用して古い値を取得する場合に使用できるUNDO情報を作成します。これを避けるには、データを別のデータベースにエクスポート/インポートする、UNDO情報をパージする、またはフラッシュバック問合せを無効化する必要があります。
状況によっては、複数の異なるデータベースを一貫してマスキングする必要があります。たとえば、3つの異なるデータベースで従業員IDの概念を持つHR、給与および手当てを管理する場合、従業員のIDを選択することで従業員のHR、給与または手当ての情報を取得できるという意味において、この概念はすべてのデータベースで一貫性を保持する可能性があります。この前提に基づくと、実際に社会保障番号を含むために従業員のIDをマスキングする必要がある場合、これら3つのデータベース全体で一貫してマスキングを行う必要があります。
決定論的マスキングにより、この問題を解決できます。置換フォーマットを使用して、3つのデータベースすべての従業員ID列をマスキングできます。置換フォーマットでは、値の表を使用して元の値をマスク値と置換します。この値の表が変更されないかぎり、3つのデータベース全体で決定論的なマスクまたは一貫したマスクを使用できます。
次のユースケースは、ユーザーが実行できるより重要なデータ・マスキング・タスクの一部を示しています。
ステージング環境で維持されるアプリケーションの本番環境データのマスキング
このユースケースは、ステップ6を除き、アプリケーション・データベース管理者に適用されます。
アプリケーション・データベース管理者としてシステムにログインし、データベースおよびそれに関連する権限にアクセスします。
列に機密情報または規制された情報が入っている表を、スキーマの中で検索します。検索基準に基づき、表および列が表示されます。
表の列と適切なマスキング・フォーマットを選択します。表の列とそれに関連するすべての外部キー列が、マスキング定義に追加されます。
明示的な参照整合性関係がデータベース内で定義されていないマスキング定義に、追加の表の列を割り当てます。該当する表の列が、依存列としてマスキング定義に追加されます。
マスキング定義を、情報セキュリティ管理者に通知します。
情報セキュリティ管理者が、マスキング定義をレビューし、その完全性を確認した後、アプリケーション・データベース管理者にマスキング・プロセスを進めるよう推奨します。
ステップ4で作成したマスキング定義を使用して、データ・マスキング・プロセスを開始します。システムにより、マスキング定義が検証され、領域の可用性が確認された後、テスト・ステージングのデータベース内にあるデータにマスキング・フォーマットが適用されます。
マスキング・プロセスの完了を検証した後、マスキングされたデータに機密データが置き換えられていることを確認します。
既存のマスキング定義による新しいデータベースのマスキング
このユースケースは、アプリケーション・データベース管理者に適用されます。
以前作成したマスキング定義に基づいて新しいマスキング定義を作成し、それを新しいデータベースに適用します。表の列およびマスキング・フォーマットを含め、マスキング定義がコピーされ、新しいデータベースと関連付けられます。
新しく作成したマスキング定義を使用し、新しいデータベースのマスキングを開始します。システムにより、マスキング定義が検証され、領域の可用性が確認された後、テスト・ステージングのデータベース内にあるデータにマスキング・フォーマットが適用されます。
マスキング定義のエクスポートとインポート
このユースケースは、アプリケーション開発者およびアプリケーション・データベース管理者に適用されます。
開発者が、システムにログインし、データベースおよびそれに関連する権限にアクセスします。
開発者が、有効なマスキング定義をトランスポータブルなファイル・フォーマットにエクスポートするよう要求します。マスキング定義およびマスキング・フォーマットが格納されたXMLファイルが生成されます。
データベース管理者が、マスキング・テンプレートをダウンロードするか、受信します。
データベース管理者が、マスキング・テンプレートをインポートします。マスキング・テンプレートが検証され、そのテンプレートに基づいてマスキング定義が作成されます。
新しく作成したマスキング定義を使用し、データベース管理者がデータベースのマスキングを開始します。システムにより、マスキング定義が検証され、領域の可用性が確認された後、テスト・ステージングのデータベース内にあるデータにマスキング・フォーマットが適用されます。
Oracle Enterprise Managerを使用すると、Oracleデータベース間またはOracleデータベース外のデータ・フローを制御できます。次の項では、Oracleデータベースのメンテナンスに役立つ機能の概要を示します。
Oracleデータベースのバックアップは通常、物理バックアップを指し、データベースを構成しているファイルを保護します。Oracle Enterprise Managerに組み込まれたバックアップ機能およびリカバリ機能で保護されるファイルには、データファイル、制御ファイル、およびアーカイブREDOログ・ファイルがあります。物理レベルで動作するバックアップ・メカニズムは、過失によるデータファイルの削除またはディスク・ドライブの故障などのファイル・レベルの破損を防止します。通常、Oracleのバックアップおよびリカバリはデータベース・ファイルの物理バックアップを対象としています。これにより、データベースの完全な再構築が可能になります。
Enterprise Managerの物理バックアップ機能およびリカバリ機能はOracleのRecovery Manager（RMAN）コマンドライン・クライアント上に構築されています。Enterprise Managerは、RMANコマンドを作成しRMANクライアントに送信することで、バックアップ・タスクを実行します。Enterprise Managerでは、多くのRMAN機能の他に、RMANベースのバックアップおよびリカバリの実装を簡略化および自動化するためのウィザードや自動計画も使用できます。
バックアップの管理には、ディスクまたはテープ上にあるバックアップ自体の管理、およびRMANリポジトリに保持されているバックアップのレコードの管理という2つの作業があります。
オペレーティング・システム・レベルでコピーされたデータファイルまたはアーカイブREDOログ・ファイルは、カタログに入れてRMANリポジトリに追加した後、RMANで作成された場合と同様にデータのリストア操作およびリカバリ操作に使用できます。Enterprise Managerに用意されているバックアップ・メンテナンスは次のとおりです。
RMANリポジトリに記録されているバックアップ（バックアップ・セットおよびイメージ・コピー）の一覧表示。
リポジトリの照合確認。リポジトリに入っているが照合確認の時点でアクセスできなかったバックアップは、すべて期限切れとしてマークされます。
期限切れになったバックアップのRMANリポジトリからの削除。
廃止されたバックアップのリポジトリおよびディスクからの削除。リカバリ領域をバックアップ記憶域として使用する場合、ディスク領域におけるフラッシュ・リカバリ領域の自動管理によって多数のメンテナンス・アクティビティが削減されるかまたは不要になることに注意してください。
Enterprise Managerを使用したメディア・リカバリには、完全リカバリまたはポイント・イン・タイム・リカバリがあります。完全リカバリでは、ログの変更がすべて適用され、データベースが障害発生時の状態に戻ります。これにより、データを失うことなくデータベースを再オープンできます。
ポイント・イン・タイム・リカバリでは、データファイルのバックアップ作成時からREDOログの最終変更までの間の任意のシステム変更番号（SCN）を選択し、このSCNまでの変更のみを適用できます。これにより、バックアップ作成時からREDOログの最新SCNまでの間の任意のSCN（つまり、任意の時点）にデータベースを戻せます。この手法は、データベースの論理的な破損の原因となるユーザー・エラーなどの状況からのリカバリに使用できます。ポイント・イン・タイム・リカバリは、すべての変更が適用されるわけではないことから、不完全リカバリと呼ばれることもあります。
メディア・リカバリには、制御ファイル、データファイル、およびデータファイルのバックアップが作成された時点からのすべてのオンラインREDOログとアーカイブREDOログが必要となります。通常、メディア・リカバリは、データベースに障害が発生した場合のみ使用されます。
クラッシュ・リカバリは、単一インスタンス・データベースがクラッシュした場合またはOracle RACデータベースのインスタンスがすべてクラッシュした場合の障害からのリカバリに使用されます。インスタンス・リカバリとは、Oracle RACデータベース内の障害インスタンスが残りの正常なインスタンスによってリカバリされるケースを指します。データファイル・メディア・リカバリは、現時点で消失または破損しているデータファイルや制御ファイルからのリカバリに使用されます。ブロック・メディア・リカバリは、すべてのデータベース・ファイルがオンラインで使用可能な状態にある間に個々のデータ・ブロックをリストアおよびリカバリする手法です。
Enterprise Managerのフラッシュバック機能には、物理および論理バックアップに対する効率的かつ使いやすい代替手段として一連の物理および論理データ・リカバリ・ツールが用意されています。フラッシュバック表を使用すると、表を最近の内容に戻すことができ、フラッシュバック削除を使用すると、削除したデータベース表を取り戻すことが可能になります。いずれのツールも、消失したデータを取得できるように論理レベルのエクスポートを作成するなどの準備作業は必要ありません。また、いずれのツールも、データベースが使用可能な状態にある間に使用できます。
フラッシュバック・データベースでは、Oracleデータベースを過去の時点に迅速にリカバリして、論理データ破損またはユーザー・エラーによって引き起こされた問題を修正できます。フラッシュ・リカバリ領域が構成されている場合は、データベースを過去の時点に戻せます。フラッシュバック表では、表を特定の時点にリカバリできます。表データだけでなく、それに関連付けられている索引やトリガーなどの属性もすべてリストアできます。フラッシュバック表を実行するには、データベースがオンライン状態にある間に、所定の表に加えられた変更のみをロールバックします。表とその内容を特定の時点またはユーザー指定のSCNに戻せます。フラッシュバック表をフラッシュバック問合せおよび行バージョンと併用すると、どの時点まで表をリストアする必要があるかがわかります。
フラッシュ・リカバリ領域は規模が大きいほど、その有用性も高くなります。理想として、フラッシュ・リカバリ領域には、データファイルの2つの完全なバックアップ・コピーに加えて、データベースをリカバリ・ウィンドウ実行中の任意の時点にリストアするために必要な増分バックアップおよびアーカイブ・ログを十分に収容できる大きさが必要です。
Enterprise Managerを使用すると、バックアップの保存方法、バックアップするデータ、バックアップの実行方法、およびリカバリ領域からパージされるまでバックアップを保存しておく期間を決定する複数の設定およびポリシーを構成できます。バックアップのパフォーマンスが向上するように設定を構成することもできます。ディスクの場合、パフォーマンスの向上を目的として、バックアップを保存するためのデフォルト・フォーマット、バックアップが保存されるディスク上の場所、およびバックアップ・タスクを並行して実行するかどうかを構成できます。ディスクへのOracleのバックアップはイメージ・コピーまたはバックアップ・セットとして保存できます。テープおよび同様のメディア管理デバイスへのバックアップはバックアップ・セットとして保存する必要があります。
Enterprise Managerを使用すると、データベースをリストアできる特定の時点としてリストア・ポイントを作成できます。リストア・ポイントは、データベースの過去の時点に関連付けられた名前になります。必要なフラッシュバック・ログおよびアーカイブ・ログが存在する場合、データベースをリストア・ポイントにフラッシュバックできます。保証付きリストア・ポイントとは、その時点にデータベースをフラッシュバックできるリストア・ポイントです。リストア・ポイントごとに、名前と作成時間が付与されます。リストア・ポイントは、作成時間の新しい順にソートされます。
Oracle Data Guardを使用すると、エンタープライズ・データの高可用性、データ保護および障害時リカバリが保証されます。Data Guardには、障害やデータ破損が発生しても本番Oracleデータベースが正常な動作を続けられるように、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットが用意されています。Data Guardは、これらのスタンバイ・データベースをトランザクション上に一貫性のある本番データベースのコピーとして維持します。計画済または未計画の停止が原因で本番データベースが使用できなくなった場合、Data Guardはスタンバイ・データベースを本番ロールに切り替えます。これにより、停止にかかわる時間が最小限に抑えられます。
Data Guardを従来のバックアップ、リストアおよびクラスタ手法と併用すると、高レベルのデータ保護およびデータ可用性を実現できます。Data Guardを使用した場合、必要に応じて管理者はリソースが集中するバックアップをオフロードし、スタンバイ・システムに操作をレポートすることで、本番データベースのパフォーマンスを改善できます。
Enterprise Managerには、次に示すような包括的なData Guardの設定、管理および監視機能が用意されています。
物理データベース、論理データベースおよびスナップショット・スタンバイ・データベースの自動作成
Data Guardのステータスおよびパフォーマンスの監視
Data Guardの主要機能（保護モード、スイッチオーバー、フェイルオーバー、ファスト・スタート・フェイルオーバーなど）の管理
Enterprise Managerでは、ファイルまたはデータベースから既存のデータベースにデータを容易に移動できます。Enterprise Managerに用意されているツールを使用すると、データのエクスポートおよびインポートとデータベースのクローニングを実行できます。次の項では、データベースのホームページの「メンテナンス」領域にある機能について説明します。
ファイルへのエクスポート機能を使用すると、Oracleデータベースとの間でOracleフォーマットの既存データを移動できます。たとえば、エクスポート・ファイルでは、データベース・データをアーカイブしたり、同一または異なるオペレーティング・システム上で稼働している複数のOracleデータベース間でデータを移動できます。「ファイルにエクスポート」を使用すると、データベースがオープンされ、使用可能な場合は、論理データベース・オブジェクトをバックアップできます。これにより、データベース・オブジェクトの読取り一貫性ビューがオペレーティング・システム・ファイルに書き込まれます。データベースの完全エクスポートでは、一部のスキーマが除外されるため、すべてのデータベース・オブジェクトは含まれません。次のシステム・スキーマは、そこに含まれるメタデータが、ダンプ・ファイル・セット内のその他のオブジェクトの一部としてエクスポートされるため、完全エクスポートの一部としてエクスポートされません（SYS、ORDSYS、EXFSYS、MDSYS、DMSYS、CTXSYS、ORDPLUGINS、LBACSYS、XDB、SI_INFORMTN_SCHEMA、DIP、DBSNMP、WMSYS）。
ファイルのエクスポートの詳細は、『Oracle Databaseアップグレード・ガイド 11gリリース2』の「データ・ポンプおよびエクスポート/インポートを使用したデータの移動」を参照してください。データ・ポンプの詳細は、『Oracle Databaseユーティリティ 11gリリース2』の「データ・ポンプ・エクスポート」を参照してください。
Enterprise Managerでは、反対にデータベース、オブジェクトおよび表の内容をインポートできます。データベースからのインポート機能を使用して、データベースの内容をインポートすることもできます。インポートできる内容は、データベース全体、データベース内のスキーマ、スキーマ内のオブジェクト、またはスキーマ内の1つ以上の表です。Oracle以外のデータベースからOracleデータベースにデータをロードするには、ファイルからのデータのロード機能を使用します。
エクスポート・ジョブとインポート・ジョブの監視機能を使用すると、データベース全体のエクスポートや表領域エクスポートなどのインポートおよびエクスポート操作のステータスが表示されます。ジョブの状態を変更するには、ジョブの一時停止、取消し、または再開（すでに一時停止されている場合）を実行します。また、そのジョブ専用のスレッドの数と付随するリソースの数を増やすこともできます。
Enterprise Managerの「データベースのクローニング」ツールを使用すると、Oracleデータベース・インスタンスを既存のOracleホームにクローニングできます。Oracleデータベース・インスタンスが既知の状態になった後で、そのデータベースを別の既存のOracleホームにクローニングすることもできます。
表領域のトランスポート機能を使用すると、異なるマシン・アーキテクチャ間および異なるオペレーティング・システム間で表領域をトランスポートできます。トランスポータブル表領域を使用した場合は、アンロード・ステップおよびリロード・ステップをほとんど実行せずに済みます。トランスポータブル表領域を使用すると、Oracleデータファイル（表データ、索引、およびその他のOracleデータベース・オブジェクトのほぼ全部を含む）を一方のデータベースからもう一方のデータベースに直接トランスポートできます。また、トランスポータブル表領域の機能を使用すると、Oracleデータベースのサブセットを移動し、別のOracleデータベースにプラグインできます。基本的に、表領域はデータベース間で移動します。
|
注意: TTSの統合ウィザードは、11.1 GC OMSとともに構成された10.2.0.5エージェントによって監視されている11.2.0.1.0データベース・ターゲットへの統合の実行中、ヘッダー情報を読み取る段階で失敗します。次の回避策を使用してください。 $OMS_HOME/sysman/admin/scripts/db/dataUtilities/tts.plを次にコピーします。 コピー先: $AGENT_HOME/sysman/admin/scripts/db/dataUtilities/tts.pl |
Oracle Streamsでは、データベース内またはデータベース間でのデータ・ストリームのデータ、トランザクションおよびイベントの伝播と管理ができます。このストリームにより、公開情報がサブスクライブされた宛先にルーティングされます。変更が必要な場合は、既存の機能を犠牲にすることなく、Oracle Streamsの新機能を容易に実装できます。
Oracle Streamsでは、グリッドのデータベース、ノード、またはブレード・ファーム間のデータをストリーミングし、更新が適用された場合に2つ以上のコピーの同期を保持できます。また、Oracle Streamsでは、情報共有、メッセージ・キューイングの組合せ、レプリケーション、イベント、データ・ウェアハウスのロード、通知、および公開/サブスクライブのためのフレームワークを1つのテクノロジに統合して提供します。
Oracle Streamsに用意されている一連の要素を使用すると、ストリームに入れる情報、ノード間のストリームの到達方法およびルーティング方法、ストリーム内のイベントが各ノードに到達した際に実行される操作、およびストリームの終了方法を制御できます。ストリームに基づいて動作する要素の構成を指定して、メッセージ・キューイングまたはデータ・レプリケーションなどの特定の要件に対応できます。
Oracle Streams環境の設定、管理、監視およびトラブルシューティングを行うには、Oracle Enterprise ManagerのStreams管理機能を使用します。
ホスト上のOracle管理エージェントは、ホストに関するホスト構成情報、ホスト上のOracleデータベースに関するデータベース構成情報、およびクライアント構成情報を収集し、HTTPSを介してOracle管理サービスに情報を伝達します。情報はOracle管理リポジトリに保存されます。Enterprise Managerでは、これらの構成を比較して、2つ以上のホスト、クライアントまたはデータベース間の相違を判別できます。一般的な比較機能を使用すると、様々なタイプの現行または保存された構成を1つ以上の現行または保存された構成と比較できます。
この機能では、選択したターゲット・タイプの現行の構成を同じタイプの他のターゲットの1つ以上の現行の構成と比較したり、保存された構成を同じまたは他のターゲットの1つ以上の保存された構成と比較できます。保存された構成を同じまたは他のターゲットの1つ以上の現行の構成と比較したり、特定の構成を別の構成と比較して相違を即時に表示することもできます。さらに、特定の構成を別の構成と比較し、この比較をジョブとしてスケジュールすることもできます。
Enterprise Managerを使用すると、Oracle管理エージェントが稼働しているホスト上のOracleソフトウェアのパッチを簡略化し、クリティカル・パッチ・アドバイザを提供できます。Enterprise Managerは、Oracleソフトウェアのパッチ適用を簡略化します。Oracleパッチ・アドバイザでは、Oracle製品のクリティカル・ソフトウェア・パッチについて説明します。安全で、信頼できる構成を実現するには、すべての関連クリティカルOracleパッチおよび現行クリティカルOracleパッチを適用する必要があります。クリティカル・パッチの適用を促進するために、Enterprise Managerは、エンタープライズに対して収集されたホスト構成を調査し、1つ以上のクリティカル・パッチをインストールする必要のあるOracleホームを判別して、脆弱性を評価します。すべてのクリティカル・パッチ・アドバイザとそれに対応した「影響」領域、各アドバイザの簡単な説明、影響を受けるホストの数、および各アドバイザのOracleホームが一覧表示されます。
Enterprise Managerを介してMy Oracle Supportに接続し、検索を実行して必要なパッチまたはパッチ・セットをダウンロードし、パッチを適用できます。すべてのパッチ・アクティビティはパッチ・キャッシュから実行できます。つまり、OMSがインターネットを介してMy Oracle Supportに接続されていない場合でも、パッチまたはパッチ・セットを検索、ダウンロードおよび適用できます。
Oracle Real Application Clusters（RAC）には、複数のホスト全体での可用性の高いデータベース環境が用意されています。それぞれのクラスタは複数のクラスタ・データベースで構成され、各クラスタ・データベースは複数のクラスタ・データベース・インスタンスで構成されます。クラスタ・データベースは、そのインスタンスが1つでも使用可能であるかぎり使用できます。Enterprise Managerの「パフォーマンス」ページで、クラスタ、クラスタ・データベースおよびクラスタ・データベース・インスタンスを含む、クラスタ環境のすべてのレベルを監視します。Oracle Real Application Clustersデータベースおよびインスタンスの管理方法は、単一インスタンス・データベースの管理方法とほぼ同じです。Enterprise Managerを使用すると、次のような様々なタスクを実行できます。
クラスタ、クラスタ・データベース、およびクラスタ・データベース・インスタンスの管理
キー・パフォーマンス統計の監視
管理タスクおよびメンテナンス・タスクの実行
クラスタ管理データベース・サービスなどのReal Application Clusters機能の管理
Oracle RACにより、クラスタのメンバーである各コンピュータ（つまりホスト）はデータベースへのアクセスを共有できます。クラスタの1台のホストが故障した場合やオフライン状態になった場合でも、クラスタの他のホストが処理を引き継ぐため、Oracle RACデータベース全体はアプリケーションで使用可能な状態を維持します。つまり、アプリケーションでは、標準的なパフォーマンスの2台以上のコンピュータをさらに有効性の高いものとみなします。2台のホストが備わっているOracle RACデータベースのパフォーマンス、可用性および信頼性を向上させるために、クラスタ・ホストを追加できます。ホスト間でデータがパーティション化されていないため、クラスタにホストを追加しても不安定になることはありません。むしろ、アプリケーションの実行速度がより速くなるか、より多くのユーザーをサポートできるようになります。Oracle RACデータベースに備わっているホストの数が多いほど、個々のノードの損失によってデータベースが受ける影響が少なくなります。
クラスタ内の共有データに対して、同時読取り/書込みアクティビティは頻繁に実行されます。サービス要件によって異なりますが、通常このアクティビティはパフォーマンスの問題を引き起こしません。ただし、グローバル・キャッシュ・リクエストによって「クラスタ・データベース」ページに示されるパフォーマンスの問題が発生した場合は、SQL計画とスキーマを最適化して、有効なローカル・キャッシュのヒット効率を実現し、I/Oを最小限に抑えることが正しいパフォーマンス・チューニング計画になります。この問題の解決を支援するために、「クラスタ・キャッシュ一貫性」ページでは、クラスタ・データベース全体のキャッシュ一貫性メトリックを表示して処理傾向を特定し、Oracle Real Application Clusters環境のパフォーマンスを最適化できます（図6-17）。
「クラスタ・キャッシュ一貫性」ページにアクセスするには、「その他の監視リンク」セクションの「クラスタ・キャッシュ一貫性」リンクをクリックします。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「クラスタ・キャッシュ一貫性」ページに関するトピック |
これらのグラフの用途は、次のとおりです。
「グローバル・キャッシュ・ブロックのアクセス待機時間」は、ブロック・リクエスト全体での経過時間または待機時間を表します。
「グローバル・キャッシュ・ブロック転送率」は、インターコネクトを介してクラスタ内のすべてのインスタンスが受け取るデータ・ブロックの総数を表します。
「グローバル・キャッシュ・ブロック転送と物理読取り(論理読取りとの比較)」は、ダイレクト・メモリー・アクセスでの他のインスタンスのバッファ・キャッシュからのデータおよびディスクからのデータが読み取られる論理読取りの割合を表します。
「アクティブ・セッション履歴」は、表示されているクラスタ待機クラスのアクティブ・セッションを表します。グラフ内のグレーの影付きボックスを目的の期間に移動することで、その期間の上位SQLおよび上位セッションを下の表に表示できます。
「クラスタ」の「インターコネクト」ページでは、ホスト上にあるインタフェースの現在の状態を表示できます（図6-18）。このページを使用すると、インターコネクト・インタフェースの監視、構成の問題の判別、および超過通信量などの転送速度に関連した問題の特定ができます。このページは、インターコネクト上の個々のインスタンスおよびデータベースによって加えられた負荷を判別するために役立ちます。場合によっては、Oracleデータベース外のアプリケーションによるインターコネクトの遅延も即時に特定できます。
|
関連項目: Enterprise Managerオンライン・ヘルプの「クラスタ」の「インターコネクト」ページに関するトピック |
サービスとは、アプリケーションのワークロードを増加させ、そのワークロードに対応するビジネス・コンポーネントで構成された、アプリケーションのグループまたは分類です。サービスの例としては、買掛管理、カスタマ・リレーションシップ・マネジメントなどがあります。Oracle RACのサービスにより、連続したデータベース操作で複数インスタンスの複数サービスをサポートできるようになります。
Oracle RACのサービスでは、クラスタ・データベース・リソースを1つのシステム・イメージに統合して、クラスタの管理性を最適化できます。これにより、システム・デプロイメント、テスト、障害時リカバリが簡略化され、管理オーバーヘッドが削減されます。サービスを使用すると、どのインスタンスでSQLアプリケーション・サービスが実行されるかに関係なく、ユーザーはデータベースに接続します。
実行するサービスを1つ以上のインスタンスに割り当てると、プライマリ・インスタンスで障害が発生した場合に代替インスタンスがバックアップ・インスタンスとして機能できるようになります。プライマリ・インスタンスで障害が発生した場合、Oracleは障害インスタンスから残りの正常な代替インスタンスにサービスを移行します。
サービスでは、あらゆる高可用性状況や障害時リカバリ状況に対して計画済および未計画の操作の両方をモデル化およびデプロイできます。停止中に、Oracle RACはキー・コンポーネントを自動的に再起動します。自動再起動に適格なコンポーネントには、インスタンス、Oracle Net Servicesリスナー、データベース、および複数のデータベース・サブコンポーネントがあります。
Enterprise Managerの「サービスの作成」ページでサービスを作成および編集できます。このページには、Enterprise Managerの「可用性」プロパティ・ページにある「クラスタ管理データベース・サービス」リンクからアクセスできます（図6-19）。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「サービスの作成」ページに関するトピック |
ポリシー管理型データベースであるOracle RACデータベースを作成する場合、データベースに必要なサーバーの数を指定すると、データベースにサーバー・プールが自動的に作成されます。Oracleクラスタウェアにより、使用可能なサーバーがサーバー・プールに移入されます。サーバー・プールを使用しない場合、管理者管理型データベースを作成できます。
ポリシー管理型と管理者管理型の両方のデータベースにサービスを定義できます。
ポリシー管理型データベース
ポリシー管理型データベースにサービスを定義する場合、データベースが実行されているサーバー・プールにサービスを割り当てます。サービスは、UNIFORM（サーバー・プール内のすべてのインスタンスで実行）またはSINGLETON（サーバー・プール内の1つのインスタンスのみで実行）のいずれかとして定義できます。
管理者ベースのデータベース
管理者管理型データベースにサービスを定義する場合、そのサービスを通常サポートするインスタンスを定義します。これは、PREFERREDインスタンスと呼ばれます。別のサポート・インスタンスを定義することもできます。
|
関連項目: 新規ノードでのインスタンスの作成を含む、ポリシー・ベースおよび管理者ベースのデータベースの詳細は、『Oracle Database2日でReal Application Clustersガイド』 を参照してください。 |
OracleクラスタウェアとOracle RACを併用すると、優れたスケーラビリティと高可用性を実現できます。高可用性を維持するために、Oracleクラスタウェアのコンポーネントは、「サービスの作成」ページで指定可能な高可用性ルールに従ってアプリケーションおよびプロセスを再起動するステータス変更に対応できます（図6-19）。Oracleクラスタウェアは、表6-2のコンポーネントを使用して高可用性を実現します。
表6-2 Oracleクラスタウェアの高可用性コンポーネント
| コンポーネント | 説明 |
|---|---|
|
投票ディスクは、ヘルス・チェックを使用してクラスタ・メンバーシップを管理し、ネットワークの障害が発生した場合にインスタンス間のクラスタ所有者を調整します。Oracle RACは投票ディスクを使用して、どのインスタンスがクラスタのメンバーであるかを判別します。 |
|
|
OCRは、データベースおよびクラスタ・データベースの構成情報とクラスタ内のクラスタ・データベースの構成情報を維持します。OCRは、Oracleクラスタウェアで制御されているプロセスの情報も管理します。 |
|
|
Application Program Interface（API） |
Oracleクラスタウェアには、単一インスタンスOracleデータベースまたはOracle RACデータベース上で稼働するアプリケーションまたはプロセスの管理に使用できる高可用性APIがあります。これにより、すべてのアプリケーションに高可用性を提供できます。 |
データベースの「高可用性コンソール」は、データベースの高可用性（HA）を監視するための集中的なダッシュボード・スタイルのページです。「高可用性コンソール」ページを使用すると、高可用性イベント、データベースのステータスを含む可用性のサマリー、最後のバックアップ・ステータス、フラッシュ・リカバリ領域の使用量、Data Guardのサマリー、および上位サービスを含むRACサービスのサマリーを参照できます。どの程度詳しく表示するかに応じて、詳細表示または基本表示でデータベースの「高可用性コンソール」ページを表示できます。
データベースの「高可用性コンソールのオプション」ページを使用すると、可用性イベントのイベント・オプションの設定、ヘッダー・バー、ターゲット名およびホスト名の書式設定オプションの構成、「高可用性コンソール」ページのリフレッシュ・オプションの定義、および履歴グラフの表示の可否と表示方法の指定を行うことができます。
データベースの「最大可用性アーキテクチャ(MAA)アドバイザ」ページを使用すると、各停止タイプ（コンピュータ障害、ストレージ障害、人的ミス、データ破損およびサイト障害）に応じたOracle推奨ソリューション、各ソリューションの構成ステータスとEnterprise Managerリンク、および推奨された各ソリューションの利点を参照できます。「MAAアドバイザ」ページには、「停止タイプ」、「Oracleソリューション」、「推奨レベル」、「構成ステータス」および「利点」をリストした表が含まれます。特定のソリューション領域を設定、管理および構成可能なページに移動できます。ソリューションを構成したら、アドバイザの「詳細」リンクをクリックして更新された値を確認できます。
