Comments
Description
Transcript
Oracle Database 12cの管理性
Oracleホワイト・ペーパー 2013年6月 Oracle Database 12cの管理性 Oracle Database 12cの管理性 免責事項 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を 唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルやコード、 機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材料になさらな いで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期について は、弊社の裁量により決定されます。 Oracle Database 12cの管理性 はじめに ....................................................................................................................................................3 管理性の課題 ..........................................................................................................................................3 パフォーマンス管理 ...........................................................................................................................4 パフォーマンス診断 ....................................................................................................................4 アプリケーションのチューニング .....................................................................................8 テストとテスト・データの管理............................................................................................... 12 SQL Performance Analyzerを使用した応答時間テスト ...................................... 13 Database Replayを使用したスループット・テスト ............................................. 14 統合型のDatabase Replayを使用した統合テスト .................................................. 15 Database Replayのワークロードのスケールアップ ............................................. 15 継続的な管理 .......................................................................................................................................17 リソース管理 ................................................................................................................................ 17 Exadataの管理とクラウドの統合 ............................................................................................ 19 統合システム監視 ...................................................................................................................... 19 障害診断 .................................................................................................................................................20 Oracle Database 12cの管理性 はじめに Oracleデータベースは、世界中の数多くの企業に加えて、アプリケーション開発者やデータベース管理者か ら選ばれた、市場でもっとも広く普及しているデータベースです。企業は、年を追うごとに、他に例のない パフォーマンスと信頼性を実現できるOracleデータベースへの依存度を高めています。オラクルは、画期的 な管理性を備えた自己管理型のデータベースであるOracle Database 10gで、ITの生産性を大幅に向上し、管 理コストを劇的に削減しました。Oracle Database 11gでは、本番ワークロードを使用してデータベース・テ ストを実行する機能、ならびにデータベースの問合せを自動的に監視する機能が追加されました。Oracle Database 12cでは、この管理性がさらに強化されています。Oracle Database 12cの組込みの機能は、継続的 な統合とクラウド・コンピューティングの需要に対応するために急速に進化し、常時変化し続けるデータセ ンター環境に対応します。また、業界を代表する自己管理機能を基盤として構築されたOracle Database 12c は、今日の企業が直面する最大の課題の多くに対応する管理性、テストとセキュアなテスト・データの管理、 障害診断の分野で大きな進歩を遂げています。 オラクルの統合エンタープライズIT管理製品ラインであるOracle Enterprise Manager（Oracle EM）は、業界 初の完全なクラウド・ライフ・サイクル管理ソリューションです。Oracle Database 12cとOracle Enterprise Manager Cloud Control 12cをともに使用すると、組織は新しいテクノロジーを素早く活用しながら、リスク を最小限に抑えることができます。Oracle Enterprise Managerが提供するビジネス主導型のIT管理機能を使 用すると、アプリケーションからディスクに至るまで、エンタープライズ・クラウドおよび従来のIT環境を 簡単に設定、管理、サポートできるようになります。 管理性の課題 大量のデータベースを企業で管理する際に、データベース管理者が直面する管理に関する最大の課題は次の とおりです。 • パフォーマンスの診断とチューニング：確約したサービス・レベルを維持するために、本番データベース で最高のパフォーマンスを発揮し続けるにはどうすれば良いか • テストとテスト・データの管理：Oracleデータベース環境でのテストとテスト・データの管理を通じて、 変更をロールアウトする際のリスク軽減を低コストで実現するにはどうすれば良いか • 継続的な管理：自動化によって日常的な繰り返し作業から管理者を解放して、セキュリティやデータセ ンター統合、ビジネス継続性などのより戦略的な要件に重点的に取り組めるようにするにはどうすれば 良いか • クラウドの統合とOracle Exadataの管理：データセンター・コストを削減し、サーバー効率を上げるため に、共通のインフラストラクチャ上にデータベースを統合するにはどうすれば良いか これらの課題に対処するために、Oracle Database 12cは、パフォーマンス、変更保証機能、自己管理機能の 面で飛躍的な進歩を遂げており、Oracle Database 12cの管理はかつてないほど簡単になりました。 3 Oracle Database 12cの管理性 パフォーマンス管理 従来から、パフォーマンス管理は、データベース管理者にとって大きな課題の1つとなっています。Oracle Database 12cの自己管理機能は継続してすべての領域で拡充していきます。この領域には、データベースの パフォーマンス管理における2つの重要な側面であるパフォーマンス診断とアプリケーション・チューニン グも含まれています。 パフォーマンス診断 データベースで報告されているパフォーマンスの課題は、大きく次の4つのカテゴリに分類できます。 i. i永続的なパフォーマンス問題 ii. 一時的なパフォーマンス問題 iii. 比較によるパフォーマンス問題 iv. リアルタイムのパフォーマンス問題 以降のセクションでは、Oracle Databaseを使用したこれらの課題の対処方法について説明していきます。 優れたパフォーマンスの実現に必要な手順は、正しいデータを収集して適切な分析を行い、効果的なアク ション・プランを作成することです。Oracle Databaseの自己管理型フレームワークは、DBAの代わりにこの ようなタスクを実行することによって、パフォーマンス診断を簡素化して日常的に実施することを可能にし ます。自動ワークロードリポジトリは必要なデータを収集し、自動データベース診断モニターはデータを分 析 し て 、 的 確 で 具 体 的 な す ぐ に 実 施 で き る 推 奨 事 項 を 提 示 し ま す 。 デ ー タ ベ ー ス 管 理 者 は 、 Oracle Enterprise Manager Cloud Controlを使用して多数のデータベースを単一のコンソールから管理するか、また は特定の対象を管理するためにOracleデータベースと統合されたOracle Enterprise Manager Database Expressを使用するかを選択できます。 Oracle Enterprise Manager Database Express Oracle Database 12cには、パフォーマンス管理用に最適化された、すぐに使えるWebベースのデータベース 管理ツール、Oracle Enterprise Manager Database Expressが搭載されています。このツールは、データベー ス内に組み込まれており、インストール時に自動構成されます。ディスク・フットプリントの占有はわずか 20MBで、起動または使用されないときにはリソースをまったく消費しません。Oracle Enterprise Manager Database Expressは、単一インスタンスとOracle Real Application Clusters（Oracle RAC）データベースの両 方を管理できます。このツールには、コンテナ・データベース（CDB）へのサポートも組み込まれています。 Oracle Enterprise Manager Database Expressは、徹底的なパフォーマンス管理機能のサポートとともに、構 成管理、ストレージ管理、セキュリティ管理に利用できます。重要な追加機能の1つはパフォーマンス・ハ ブです。パフォーマンス・ハブについて以下に説明します。 4 Oracle Database 12cの管理性 自動ワークロードリポジトリ 自動ワークロードリポジトリ（AWR）は、すべてのOracle Database内に組み込まれてあり、特定のデータ ベースに関する運用統計情報やその他の構成および使用状況の情報が格納されています。Oracle Databaseは、 すべてのパフォーマンス統計情報とワークロード情報のスナップショットを一定の間隔で取得し、AWRに格 納します。デフォルトでは、スナップショットは60分ごとに作成され、AWRに8日間格納された後で自動的 に消去されます。 AWRは、Oracle Databaseの自己管理機能の大半の基盤を形成します。また、Oracle Databaseの使用履歴に 関する情報を提供する情報源です。これにより、データベースは、システムが稼働する環境の個別の状況に 合わせて正確な決定を下すことができます。Oracle Databaseの自己管理機能のほとんどは、AWRで取得し た情報に大きく依存しています。AWRのデータは、永続的なパフォーマンスや比較によるパフォーマンスの 診断まで、あらゆる種類のパフォーマンス問題の診断に役立ちます。 Oracle Database 12cでは、リアルタイムSQL監視、リアルタイムADDM、およびデータベース操作監視から のレポートが含まれるようにAWRが強化されています。 自動データベース診断モニター（ADDM）による永続的なパフォーマンス問題の診断 永続的なパフォーマンス問題は一般に、数時間から数日間続きます。適切に記述されていないコード、アプ リケーション設計の問題、またはシステム・リソースの過剰な使用（I/O帯域幅がフルに使用されているな ど）といったことが一般に、永続的なパフォーマンスの問題を引き起こします。Oracle Databaseの自己管理 型フレームワークの一部として構築された自動データベース診断モニター（ADDM）は、このような問題の 診断に最適です。 ADDMは、AWRで取得されたデータを基にしています。ADDMによって、Oracle Databaseでは、Oracle Database自体のパフォーマンスを診断して、特定された問題の解決方法を決定することが可能になりました。 取得した各統計情報がAWRに格納されると、ADDMは自動的に実行され、パフォーマンスの診断データがす ぐに利用できる状態になります。 ADDMは、AWRに格納されているデータを調べて分析を実行し、大きな問題を事前に見つけ出すことで、推 奨される解決方法を提示するとともに、問題解決によって期待される利益を定量的に示します。ADDMに よって検出される一般的な問題には、次のようなものがあります。CPUのボトルネック、不完全な接続の管 理、過剰な解析、ロック競合、I/O容量、サイズ不足のOracleメモリ構造（PGA、バッファ・キャッシュ、ロ グ・バッファ、高負荷のSQL文など）、実行に時間のかかるPL/SQLとJava、チェックポイントでの高負荷、 およびOracle RAC固有の問題。 5 Oracle Database 12cの管理性 ADDMは、潜在的なパフォーマンスの問題をレポートする以外に、システムで問題のない領域の情報も記録 します。I/Oやメモリなど、システムのパフォーマンスに重大な影響を及ぼすことがないサブコンポーネン トは、早い段階で問題分類ツリーから除外されてリストに表示されるため、DBAは、対策を実施してもほと んどパフォーマンスが改善されないこれらの領域を素早く確認できます。Oracle RAC環境では、ADDMがク ラスタ全体のパフォーマンス分析を実行し、個々のインスタンスだけでなくデータベース全体に影響を与え る問題をレポートに出力します。これにより、DBAはADDMを使用して、高負荷SQL、グローバル・キャッ シュのインターコネクト通信量、ネットワークの遅延問題、即時応答時間の歪み、I/O容量などの全リソー スに対してデータベース全体の分析を実施できます。Oracle Database 12cおよびCDBと連携するADDMの推 奨事項には、影響を受けたデータベースをピンポイントで特定するために、問題が検出された関連するプラ ガブル・データベース（PDB）が含まれます。 リアルタイムADDMによる一時的なパフォーマンス問題の診断 一時的なパフォーマンス問題はほとんどの場合、数秒から数分続き、アプリケーション・パフォーマンスが 不安定になります。ほとんどの場合、極めて低速または無応答の状態によって計画外停止が起こり、最終的 に収益の損失が生じます。これらの問題の根本原因を捉えて分析するための適切なツール・セットを持つこ とが非常に重要です。 リアルタイムADDMは、従来だとデータベースの再起動が必要になるような、非常に低速または無応答の データベースの問題を革新的な方法で分析します。リアルタイムADDMを利用すると、データベースの再起 動に頼ることなく、デッドロック、ハング、および共有プール競合やその他の例外状況を解決できます。 Oracle Database 12cのリアルタイムADDMは、パフォーマンス・スパイクを事前予防的に検出し、診断する ように強化されています。データベース・エンジン内部に組み込まれたリアルタイムADDMは、"新しい"パ フォーマンス問題がサーバーで検出されると、自動的にトリガーされます。そのフレームワークは、データ ベース・バックグラウンド・プロセス（MMON）がロックまたはラッチされることなく、3秒ごとにパ フォーマンス統計情報を取得する、プーリング・メカニズムを使用して構築されます。次に、これらの統計 情報は過去の動作と比較してチェックされ、必要に応じてレポートがトリガーされます。このレポートも AWRに保存されます。 期間比較ADDMによる期間中のパフォーマンスの比較 比較によるパフォーマンス問題では、データベース管理者は、ある期間のパフォーマンスが同様の期間より 低下する原因を調査するように求められることが頻繁にあります。この調査は多くの場合、非常に時間がか かり、通常は決定的な結論に達しません。 期間比較ADDMは、このような調査を非常にシンプルにします。管理者はAWRベースラインまたは古いAWR スナップショット期間、もしくは適切なカレンダー期間を選択し、特定の期間のパフォーマンスが別の期間 よりも低い原因を特定できます。期間比較ADDMはベース期間と比較期間の両方をチェックし、パフォーマ ンスが異なる根本原因を特定する一連の調査結果を出力します。最初のステップでは、パフォーマンスの相 違の原因が検出され、次に、これらの相違の影響を定量化するための測定が行われます。 最後のステップでは、原因と影響が相互に関連付けられて、パフォーマンス問題が特定されます。また、2 つの期間に対してSQL Commonality索引を使用することで、2つの期間が同等であるかどうか、つまり、同 じ期間に類似したSQLを実行しているかどうかも示します。 6 Oracle Database 12cの管理性 AWRベースラインと適応しきい値 AWRベースラインを使用すると、DBAは、関心のあるワークロードまたは代表的なワークロードについて、 一定期間に渡ってシステム・パフォーマンスのデータを記録して保存できます。複数の期間にまたがる比較 分析、または構成やパラメータの変更が行われた後に比較分析を実行する上でこのデータが役に立ちます。 また、DBAはベースラインを使用して、システム・パフォーマンス・メトリックの警告しきい値を設定でき ます。大半のメトリックは、Oracle Enterprise Manager内で、ベースライン期間に測定された、そのメト リックの統計情報集計と対比して表示できます。これにより、ユーザーは、実データのコンテキストとは無 関係なしきい値を選択するのではなく、ベースラインに基づいたしきい値を設定できます。また、特定の キー・パフォーマンス・メトリックには適応しきい値も設定できます。適応しきい値は自動的に設定される パフォーマンス警告しきい値です。しきい値の決定の基準として、システム変動ウィンドウ・ベースライン のデータを使用したシステムによって定期的に調整されます。AWRベースラインは、動的な将来のベースラ インを定義するための強力な機能を実現し、比較用パフォーマンス・データの作成および管理のプロセスを 大幅に簡素化します。 ASH Analyticsによるリアルタイムのパフォーマンス分析 AWRの主要コンポーネントは、Active Session History（ASH）です。 すべてのアクティブなデータベース・セッションは、毎秒、自動的にサンプリングされ、ASHに保管されま す。データはデータベース・メモリのローリング・バッファで取得され、バッファが一杯になるか60分経過 すると（いずれかが最初に起こったとき）、データがディスクに書き込まれます。ただし、ディスクに書き 込まれるデータは、10のサンプルごとに1つのみです。ASHデータは、現在データベース時間が費やされて いる個所を示すとともに、パフォーマンス・ボトルネックがあれば、これを明らかにします。 ASHはセッション・ステートおよび多数のパフォーマンス属性を取得するため、インメモリASHデータを非 常に効果的に使用することで、データベース・ワークロード・プロファイルを把握でき、極めて短期間に発 生するCPUスパイクやI/Oストームなどの一時的なパフォーマンス問題を事前予防的に診断できます。Oracle Enterprise Manager Cloud Control 12cに含まれるASH Analyticsは、ASHデータを調査するための新しいツー ルです。このツールを利用すると、管理者はさまざまなパフォーマンス・ディメンションにまたがるパ フォーマンス・データのロールアップやドリルダウン、および各種分析を実行できます。データベース管理 者はASH Analyticsを使用することで、任意の時点のデータベース・セッションの各種パフォーマンス属性を 調査できるようになります。 また、ASH Analyticsビューをアクティブ・レポートとして使用できるため、後からパフォーマンス問題のオ フライン分析に使用できます。 図1：ASH Analytics 7 Oracle Database 12cの管理性 Oracle Database 12ターゲットの場合、ASH AnalyticsはPDBもディメンションとして取得するので、CDB管 理者は特定のPDBのパフォーマンス・アクティビティをドリルダウンできます。また、PDB管理者がASH Analyticsにアクセスした場合は、PDBのワークロード・プロファイルを表示できます。 アプリケーションのチューニング アプリケーション設計の問題は、パフォーマンス問題のもっとも大きな原因です。問合せオプティマイザは、 索引を使用するかどうか、問合せに複数の表の結合が含まれる場合にどの結合方法を使用するかなど、問合 せのパフォーマンスに大きな影響を与える重大な決定を行います。Oracle Databaseが提供しようとしている 最高の問合せ最適化テクノロジーは、多くの場合において管理者の介入なしでアプリケーションと問合せの パフォーマンスを最大化します。それでも、場合によっては、アプリケーションの設計またはデータ分散の 偏りが原因で、特定のSQL文によるシステム・リソース全体の消費率が通常ではあり得ないほど高くなって しまうことがあります。 SQLチューニング・アドバイザ ADDMは、異常に多くのシステム・リソースを消費してパフォーマンスの問題を引き起こしているSQL文を 特定します。さらに、CPUと共有メモリをもっとも多く消費しているSQL文は、自動的にAWRに記録されま す。したがって、チューニング・フレームワークでは高負荷のSQL文が自動的に特定されるため、管理者が 介入する必要はありません。 リソース消費量のもっとも多いSQL文が特定されると、Oracle Databaseは、問合せオプティマイザに追加さ れた自動チューニング・オプティマイザと呼ばれる自動チューニング機能を使用して、それらのSQL文を自 動的に分析して、推奨される解決方法を提示できます。自動チューニング・オプティマイザは、SQLチュー ニング・アドバイザと呼ばれるアドバイザを介してデータベース管理者に公開されます。SQLチューニン グ・アドバイザは、1つまたは複数のSQL文を取り込み、チューニング・アドバイスに従って適切にチューニ ングされた計画を作成します。管理者がSQLチューニング・アドバイザを起動するだけで、最適なチューニ ングの解決方法が推奨されるため、他の操作は一切必要ありません。解決方法はオプティマイザによって提 示されるものであり、事前定義された経験則を使用する外部ツールからのものではない点に留意することが 重要です。 自動チューニング・オプティマイザの推奨事項は、以下の4つのカテゴリに分類されます。 8 Oracle Database 12cの管理性 カテゴリ 詳細 統計分析 各問合せオブジェクトの統計情報をチェックし、統計情報が存在しないか古い 場合は統計情報を収集することを推奨します。 SQLプロファイリング 自動チューニング・オプティマイザは、カスタマイズされたオプティマイザ設 定や過去の実行履歴などの補足情報を使用してSQLプロファイルを構築し、 SQLプロファイルを作成するための推奨事項を生成します。SQLプロファイル の最大の利点は、アプリケーションを変更せずに、問合せを透過的にチューニ ングすることで、Oracle管理者はSQLをパッケージ・アプリケーションで チューニングできます。 アクセス・パス分析 自動チューニング・オプティマイザは、問合せの中にある各表へのアクセス時 間を大幅に改善するために新しい索引が使用できるかどうかを調べて、該当す る場合は、このような索引を作成するための推奨事項を提示します。 SQL構造分析 不適切な計画の原因となっている不出来なSQL文を特定し、計画の再構築に関 連する推奨事項を提示します。 また、SQLチューニング・アドバイザは、システム・メンテナンスの時間枠で、メンテナンス・タスクとし て自動的に実行されます。SQLチューニング・アドバイザは、実行されるたびに、システム内で処理負荷の 大きいSQL問合せを自動的に検出し、それらのチューニングに関する推奨事項を生成します。 推奨事項を検証するため、Oracle DatabaseのSQLチューニング・アドバイザは、SQLプロファイルが推奨さ れる新しい実行計画でSQL文のテストを実行します。これにより、SQLプロファイル推奨事項の正確性と信 頼性が大幅に向上します。SQLチューニング・アドバイザは、パフォーマンスの改善が3倍以上になるSQL文 に対し、SQLプロファイル推奨事項を自動的に実装するように構成できます。 Oracle Database 12cのSQLチューニング・アドバイザは、CDBレベルとPDBレベルの両方でチューニングを シームレスにサポートするように強化されています。Oracle Database 12cより、SQLチューニング・アドバ イザはCDBにも対応しています。ルート・コンテナでSQLチューニング・アドバイザを使用して、複数の PDBの問合せをチューニングできますが、PDB管理者がSQLチューニング・アドバイザを使用して、管理者 のPDBの問合せをチューニングすることもできます。 SQLアクセス・アドバイザ SQLアクセス・アドバイザは、Oracle Databaseの管理性に関係するもう1つの主要なコンポーネントです。 SQLアクセス・アドバイザは、データベース・ワークロードを入力として取得して、各種アクセス構造の追 加を推奨します。推奨事項を生成する際に、SQLアクセス・アドバイザでは、問合せのパフォーマンス向上 に加えて、挿入、更新、削除などのデータ操作のアクティビティに新しい索引、マテリアライズド・ビュー、 またはマテリアライズド・ビュー・ログなどを追加した場合の影響が考慮されます。 Oracle Database 11gよりSQLアクセス・アドバイザに組み込まれているパーティション・アドバイザは、 Oracle Database 12cで強化されています。パーティション・アドバイザでは、レンジ、インターバル、およ びハッシュに基づくパーティションの推奨に加えて、リスト・ベースのパーティション・スキーマも推奨し ます。 9 Oracle Database 12cの管理性 リアルタイムSQL監視 リアルタイム・パフォーマンス分析の一部には、問合せに長時間かかっている理由を判別するために、実行 中の問合せの実行詳細を調べる処理が含まれます。従来、この分析はSQLトレースなどの事後対処的な手法 を使って行われてきましたが、リアルタイムSQL監視の追加により、SQL文を実行中に監視することが可能 になります。標準で追跡される新しい詳細なSQL統計の使用によって、長時間実行されるSQLの実際の実行 計画が、Oracle Enterprise ManagerのSQL監視ページに自動的に表示されます。 デフォルトでは、SQL文がパラレルで実行された場合、またはSQL文が1度の実行でCPU時間やI/O時間を5秒 以上消費した場合に、リアルタイムSQL監視機能が自動的に開始されます。DBAは、SQL文の実行に合わせ て各ステップの統計情報を表示することで、実行計画の全体を通してSQL文のステップを確認できます。 SQL監視機能は、長時間実行されるSQLのどのステップが実行されているかを示す情報をDBAに提供します。 これによって、DBAは、追加のチューニングが必要かどうかを判断できます。 図2：リアルタイムSQL監視の実行計画 SQL文とPL/SQL文をリアルタイムで監視できるようになったことに加えて、Oracle Database 11g Release 2 では、DBAは、実行の詳細情報のすべてをアクティブ・レポート（オフライン分析に使用可能なインタラク ティブ・レポート）に保存できるようになりました。この機能では、さまざまなレベルの詳細情報にドリル ダウンすることによって、ライブ表示と同じレベルの双方向性が提供されます。 データベース操作監視 リアルタイムSQL監視により、個別のSQL文とPL/SQL文を監視できますが、ビジネス・オペレーションにあ わせて両方を組み合わせる方法はありませんでした。Oracle Database 12cの新機能であるリアルタイム・ データベース操作監視では、SQLとPL/SQLの両方を監視する機能を組み合わせており、バッチ・ジョブや ETLなどの実行時間が長いデータベース・タスクを複合的なビジネス・オペレーションとして監視できます。 10 Oracle Database 12cの管理性 視覚的なライブ表示機能では、監視対象のビジネス・オペレーションに関連付けられているSQL問合せと PL/SQL問合せの進捗状況を追跡できます。開発者やDBAは、操作の開始と終了を明示的に指定するか、操作 を識別するタグを暗黙的に使用して、監視するビジネス・オペレーションを定義できます。SQLトレースに 比べてオーバーヘッドがごくわずかなデータベース操作監視を使用すると、DBAが介入することなく、重要 なビジネス・トランザクションを事前予防的に自動監視できます。 図3：リアルタイム・データベース操作監視レポート Oracle DatabaseのリアルタイムSQL監視は、CDBレベルとPDBレベルで動作します。 パフォーマンス・ハブ Oracle Enterprise Manager Database Expressには、パフォーマンス監視用のまったく新しい統合インタ フェースであるパフォーマンス・ハブを搭載しています。データベース・パフォーマンスを一元的に表示し、 ADDM、SQLチューニング、リアルタイムSQL監視、およびASH Analytics（この機能については後で説明） に一ヶ所からアクセスできます。柔軟な時間選択により、管理者はデータベース・パフォーマンスのリアル タイム・ビューと履歴ビューをシームレスに切り替えることができます。Oracle RACデータベースには、 RACタブがもう1つ付いていて、データベース管理者はクラスタ関連のパフォーマンス問題を監視できます。 11 Oracle Database 12cの管理性 図4：パフォーマンス・ハブ SQL計画の管理 SQL計画の管理では、SQL実行計画の取得、選択、改善のためのコンポーネントを提供することによって、 SQL文の実行計画の急な変更が原因で起こるパフォーマンスの低下を防ぎます。SQLパフォーマンスは、オ プティマイザの新バージョン、オプティマイザの統計および（または）パラメータの変更、SQLプロファイ ルの作成など、さまざまな変更によって影響を受けます。SQL計画の管理は、時間の経過とともに変化する SQL文の実行計画を記録して評価し、効率的であることが分かっている既存の計画セットで構成されるSQL 計画ベースラインを構築する予防的なメカニズムです。こうして作成されたSQL計画ベースラインは、シス テムの変更にかかわらず、対応するSQL文のパフォーマンスを維持するために使用されます。 SQL計画ベースラインは、より高いパフォーマンスを実現するために、時間の経過とともに改善されていき ます。SQL計画ベースラインの改善フェーズにおいて、Oracle Databaseは、定期的に新しい計画のパフォー マンスを評価し、より高いパフォーマンスを実現する計画をSQL計画ベースラインに組み込みます。新しい 計画とSQL計画ベースラインから選択された計画との間でパフォーマンスが比較され、新しい計画のパ フォーマンスの方が高いことが確認されると、その計画がベースラインに組み込まれます。 テストとテスト・データの管理 Oracle Enterprise ManagerのApplication Quality Management（AQM）ソリューションを利用すると、アプ リケーション・スタックを構成するすべての層で高品質なテストを実施できます。徹底的なテストを実施す ることで、ユーザーはアプリケーションのデプロイメント前にその品質とパフォーマンスの問題を見つけ出 すことができます。テストは、アプリケーションのデプロイメントを成功させる上でもっとも困難かつ時間 を 要 す る 作 業 で す が 、 プ ロ ジ ェ ク ト の 成 功 に と っ て 、 も っ と も 不 可 欠 な 要 素 で も あ り ま す 。 Oracle Enterprise Managerのテスト機能およびセキュアなテスト・データ管理機能は、Oracle Databaseのテスト機 能を独自に組み合わせます。この機能を利用することで、ユーザーは次の利点が得られます。 12 Oracle Database 12cの管理性 • インフラストラクチャ変更のテスト：Oracle Real Application Testing（Oracle RAT）はデータベース層の インフラストラクチャ変更テスト向けに設計および最適化されており、実際のアプリケーションの本番 ワークロードを使用して、テスト環境でデータベース・パフォーマンスを検証できます。 • テスト・データの管理と本番クラスのセキュアなテストの実施：Oracle Data Maskingソリューションと Oracle Test Data Managementソリューションを利用すると、企業はセキュリティとコンプライアンスの 目標を達成できるようになります。テスト・データベース内の機密データを不明瞭化し、本番データを適 切なサイズのデータベースにスケールダウンすることで、テスト環境や開発環境で、本番データをセキュ アに使用できます。 SQL Performance Analyzerを使用した応答時間テスト SQL実行計画を変更すると、アプリケーションのパフォーマンスと可用性に重大な影響を与える可能性があ ります。結果として、DBAは、システムの変更によってリグレッションが発生したSQL文の特定と修正に膨 大な時間を費やすことになります。SQL Performance Analyzer（SPA）を使用すると、システム環境の変更 によって引き起こされるSQL文の実行パフォーマンスの低下を予測し、未然に防ぐことができます。 SPAでは、環境の変更前と変更後にSQL文を続けて実行することで、環境の変更がSQLの実行計画と統計情報 に及ぼす影響をより細かく表示します。また、リグレッションの発生したSQL文だけでなく、システムの変更 によってもたらされた、ワークロードに対する純益を説明するレポートも生成します。リグレッションが発 生したSQL文については、適切な実行計画の詳細とそれらをチューニングするときの推奨事項が提示されます。 SPAは、既存のSQL Tuning Set（STS）、SQLチューニング・アドバイザ、SQL計画の管理における各機能と、 密接に連携して動作します。非常に大きな（数千にのぼるSQL文の）SQLワークロードにシステム変更が及 ぼす影響を査定する作業は、これまで手動で行っていたため大変時間のかかる作業でした。SPAを使用すれ ば、こうした作業を完全に自動化し、簡素化できます。DBAは、SQLチューニング・アドバイザを使用する ことで、リグレッションが発生したSQL文をテスト環境で修正して新しい計画を生成できます。こうして生 成した計画をSQL計画管理にベースラインとして供給し、本番システムにエクスポートして戻します。この ように、SPAを使用することで、企業は、これまでより低いコストで、本番環境に対するシステム変更が実 際にプラスの効果をもたらすことを極めて高い信頼度で確認できます。 SPAを使用して分析できる、共通のシステム変更の例を以下に示します。 • データベース・アップグレード、パッチ、および初期化パラメータの変更 • オペレーティング・システム、ハードウェア、またはデータベースに対する構成変更 • 新しい索引の追加、パーティション化、マテリアライズド・ビューなどのスキーマの変更 • オプティマイザ統計情報の収集 • SQLプロファイルの作成などのSQLチューニング操作 13 Oracle Database 12cの管理性 図5：SQL Performance Analyzerレポート このSPAの比較レポートでは、提示されたシステム変更の後、SQLワークロード全体のパフォーマンスが大 幅に向上しますが、リグレッションが発生した実行計画もいくつかあります。劣化が起きた場合、SPAは、 ユーザーがSQLチューニング・アドバイザまたはSQL計画ベースラインを使用して、それらを修正できるよ うにします。 Database Replayを使用したスループット・テスト Database Replayを使用すると、DBAとシステム管理者は、オンライン・ユーザーやバッチ処理によるワーク ロードなど、実際の本番環境で発生するワークロードをテスト環境において忠実で正確かつ現実的に再現で きます。Database Replayでは、同時実行性、依存性、タイミングなどを含む完全なデータベース・ワーク ロードを本番システムから取得して、本番システムのワークロードをテスト・システム上で再現することで、 システムの変更を現実的にテストできます。これは、スクリプトのセットなどでは決して実現できません。 Database Replayを使用すると、DBAとシステム管理者は次のテストを実行できます。 • データベースのアップグレード、パッチ、初期化パラメータの変更、スキーマの変更など • 単一インスタンスからOracle RACやOracle Automatic Storage Management（Oracle ASM）への変換と いった構成の変更 • ストレージ・プールやネットワーク、インターコネクトの変更 • オペレーティング・システムとハードウェアの移行、パッチ適用、アップグレード、パラメータの変更 テスト・インフラストラクチャ構築コストの低減 Database Replayを導入することで、DBAは、システムの変更をテストするためのテスト・インフラストラク チャを自由に構築できるようになりました。これまでのように、アプリケーション・インフラストラクチャ 全体を重複して保持する必要はありません。Database Replayでは、中間層、すなわちWebサーバー層を重 複させることに伴う設定上のオーバーヘッドは発生しません。DBAとシステム管理者は、変更が本番環境の シナリオを使用して十分にテストおよび検証されていることを認識しているため、最高の自信を持って、 データセンターのインフラストラクチャ・コンポ―ネントを迅速にテストしてアップグレードできます。 14 Oracle Database 12cの管理性 迅速な展開 Database Replayのもう1つの利点は、DBAが、何ヶ月もかけてアプリケーションの機能に関する知識を取得 して、開発用のテスト・スクリプトを用意する必要がないという点です。数回マウスをクリックするだけで、 本番環境全体のワークロードを簡単に再現してシステム変更のテストとロールアウトを実施できます。これ によって、従来は何ヶ月もかかっていたテスト・サイクルが数日または数週間に短縮され、結果として大幅 なコスト削減になります。 統合型のDatabase Replayを使用した統合テスト Oracle Database 12cの新しい機能であるDatabase Replayでは、単一の統合データベース上での複数のデー タベース取得の同時実行をサポートします。統合データベースは、CDBとOracle Pluggable Database、ある いはスキーマ統合手法を使用して統合された従来のデータベースなどがあります。複数のワークロードを統 合データベースに対して再現することで、ターゲット・プラットフォームでワークロードをサポートできる ことを保証できます。Database Replayでは、Oracle Database 9.2.0.8以上からの取得をサポートします。 Database Replayは 、 Oracle Database 11.1以上で実行可能です。統合型のDatabase Replayは、Oracle Database 11.2.0.2以上で実行可能です。Database Replayでの取得はプラットフォームに依存せず、サポート されているどのオペレーティング・システムでも再現できます。 また、統合型のDatabase Replayでは、個別の再現のスケジューリングをサポートして、各種ワークロード・ シナリオの調査を可能にします。 Database Replayのワークロードのスケールアップ Database Replayは、既存の取得ワークロードに基づいた新しいワークロードの作成もサポートします。新し いワークロードは、容量計画やさまざまなワークロードのwhat-ifシナリオで使用できます。Database Replayと併用可能な3つの手法には、ワークロード・フォールディング、タイム・シフト、およびスキーマ 再マッピングがあります。これらの手法の筆頭にワークロード・フォールディングがあります。ワークロー ド・サブセットを使用すると、新しいワークロードを作成できます。取得対象の期間内のある時点を指定し、 既存の取得済みワークロードをサブセットにスライスすることで、既存の取得を2つのより小さいワーク ロードに分割できます。その後、この指定した時点でワークロードをフォールディングし、ワークロードを 2倍にできます。それには、ターゲット・データベース上のサブセット・ワークロードの同時再現を発行し ます。これにより、スクリプトを使用したり、バインドを指定したりせずに、ワークロードを効果的に2倍 にできます。この手法は、個々のトランザクションがほぼ独立しているアプリケーションに最適です。 もう1つのスケールアップ手法はタイム・シフトです。複数のDatabase Replayをスケジュールすることで、 ピーク時のデータベース使用を調整できます。これにより、ターゲット統合システムが現在の本番システム からの最大本番ワークロードを処理できるかどうかを確認できます。 15 Oracle Database 12cの管理性 Database Replayは、スキーマ複製によるテストもサポートします。ターゲット・スキーマを複製して、同じ ワークロードの複数の再現を実行できます。これらの複数の再現を実行する前に、ユーザーを再マッピング して、各再現がその個々のスキーマに対して実行されるようにして、ワークロードの衝突を回避します。ス キーマ複製により、現在のワークロードの複数のスケールをテストでき、正確なワークロードのプロファイ ルと同時実行性が維持されます。これは、SaaS（Schema as a Service）の場合や、各事業部門に独自のス キーマがある場合のシナリオに役立ちます。 管理者は、Oracle Enterprise Managerのプロビジョニング機能を利用して、事前にテストされた、Oracle Databaseの標準化されたゴールデン・イメージをロールアウトできます。これによって、管理者がプロビ ジョニング・プロセスの各ステップを手動で実行する必要がなくなるため、非常に大きな労力が節約できま す。これらのゴールデン・イメージを使用すると、バックアップ・データベースまたは稼働中の本番データ ベースからテスト・システムをプロビジョニングすることができます。 企業がアプリケーションの開発またはテストを目的として本番データをテスト環境にコピーする場合、法令 で定められた規則から逸脱するか、またはデータのプライバシ法違反として罰金や罰則を課されるリスクが あります。管理者が使用できるデータ・マスキング機能は、開発環境、テスト環境、ステージング環境で機 密情報をマスキングすることで、組織がプライバシおよび機密保護法を遵守できるように支援します。逆行 できないプロセスを使用し、マスキング・ルールに基づいて機密データをスクラブし、本物に見えるデータ に置き換えることによって、セキュリティ管理者は、元データの検索、リカバリ、またはリストアが不可能 であることを保証できます。 Real Application TestingとData Maskingを統合すると、セキュアなテストを実行できます。多くの場合、テ ストは本番以外の環境で実行されるか、または別のグループや組織によって実行されます。本番データや、 本番から取得された機密情報を含むワークロードを共有すると、データ・プライバシ規制の違反につながり、 多大なビジネス・リスクの原因となります。Real Application TestingとData Maskingを統合すると、デー タ・プライバシ規制を遵守しながら、取得したワークロードとデータをデータベースで共有できます。 情報源のマスキング 従来、規制対象の機密情報は、本番環境外で本番以外の用途で使用する場合、不明瞭化されます。この手法 の場合、システム管理者は、すべての機密データがスクラブされ共有されるまで、クローン環境を分離して アクセス禁止にする必要がありました。その結果、この環境を設定するために、限られた重要なリソースが 生産的な用途から奪われ、ぜい弱性も増します。Oracle Enterprise Managerの最新リリースでは、専用の環 境を必要とせずに、情報源でのマスキングを利用できるようになっています。本番データを抽出してからマ スキングし、マスクされエクスポートされた状態に維持できます。これらのファイルは、本番データに影響 を及ぼすことなく、本番以外の環境と直接共有できます。したがって、機密性の高い本番データが本番環境 を離れることはありません。 16 Oracle Database 12cの管理性 データのサブセット化によるストレージ・コストの削減 データベース・アプリケーションが増加する中で、企業はアプリケーションの開発やテストに使用される本番 以外の環境のプロビジョニングという課題に直面しています。企業には、本番と同じデータをプロビジョニン グするだけのストレージ経費を非本番データベースに対して負担する余裕も、本番データを適切なサイズの開 発環境に縮小するためのツールやアプリケーション知識もありません。オラクルのテスト・データ管理機能を 使用すると、アプリケーションの開発およびテスト向けに、データセットの参照整合性を維持しながらサイズ を縮小した本番データのコピーを作成できるため、ストレージ・コストが削減されます。データ検出とアプリ ケーション・モデリングを通じて、オラクルのテスト・データ管理機能はエンタープライズ・アプリケーショ ンの複雑なビジネス・ルールを自動的に適用し、正確な本番データのサブセットを生成します。 データ・マスキングとデータ・サブセット化の統合 データ量が急増し、QA、テスト、開発などの本番以外の環境の更新頻度が高まる中、効率的でパフォーマ ンスの高いデータ・セキュリティ・ソリューションを実装することは、大きな課題となっています。 Data Masking Packは、データ・サブセット化とデータ・マスキングの機能を統合することで、この課題に対 処します。この統合により、企業は本番データベース全体をコピーすることなく、縮小化したセキュアなテ スト・システムを本番データベースから直接プロビジョニングできます。企業は、マスキング操作またはサ ブセット化操作（または両方）の実行を選択して、本番データに影響を及ぼすことなく、単一のワークフ ローで非本番データベースを本番データベースからプロビジョニングできます。 これらの機能により、ストレージ・コストを大幅に増大させる本番データベースのフル・コピーを取得する 必要がなく、また機密データが本番環境を離れることはありません。 継続的な管理 これまで管理者があまりにも多くの時間をかけて行ってきた日常的な繰り返し作業を自動化したことは、自 己管理型Oracle Databaseの主要な成果の1つです。データベースのプロビジョニングやパッチ適用、メモリ の割当ての管理やディスク・リソースの管理などの単調で手間のかかる管理作業から解放されることで、管 理者は、セキュリティや高可用性などのより戦略的な要求に重点的に取り組むことができるようになります。 リソース管理 メモリ割当てやディスク・リソースの管理などのリソース管理タスクを自動化することは、自己管理型デー タベースにとって、もう1つの重要な成果でした。これらのタスクについて、詳しく確認してみましょう。 自動メモリ管理 Oracle Database 11gにおける自己管理機能の重要な強化点の1つが、自動メモリ管理機能でした。この機能 はOracle Databaseインスタンスによって使用される共有メモリの管理を自動化するので、管理者は、手動で 共有メモリを構成する作業から解放されます。自動メモリ管理機能は、Oracle Databaseの内部動作に関する 高度な経験則に基づいて、メモリの配分を監視し、ワークロードの要求に応じて配分を変更します。 17 Oracle Database 12cの管理性 PGAとSGAを含むすべてのメモリが、自動メモリ管理機能によって集中管理されるようになりました。DBA が1つのパラメータMEMORY_TARGETを指定するだけで、Oracle Databaseが、ワークロードに基づいてPGA とSGAのサイズを自動的に算出します。また、間接メモリ転送により、ワークロードに応じてSGAとPGA間 でメモリが相互に転送されます。 領域管理 領域管理は、データベース管理者がもっとも時間を使う可能性がある作業の1つです。しかし、Oracle Databaseでは使用領域は自動的に管理され、潜在的な領域問題が発生した場合には、管理者への警告ととも に推奨される解決方法が提示されます。 事前予防的な領域管理 Oracle Databaseではバージョン11g以降、非介入型のタイムリーな監視を実行して、データベース・サー バーの領域使用率を確認します。Oracle Databaseの領域監視機能は、標準で設定されているためパフォーマ ンスに影響を与えることはほとんどなく、すべてのタイプの表領域に対して使用できます。領域がデータ ベース・サーバーで割り当てられて解放されると同時に監視が実行されるため、領域の使用状況情報は、 ユーザーが必要とするときにいつでも確実に入手できます。 透過的な領域再生 Oracle Databaseでは、セグメントの縮小によって領域利用率を最適化するために、データのインプレース再 編成を実行できます。セグメントの縮小によって、未使用領域を表領域内にある他のセグメントで使用でき るようになるため、問合せとDML操作のパフォーマンスが向上する可能性があります。 セグメント縮小機能は、セグメントで使用される領域を圧縮する能力と、セグメントから領域の割当てを解 除する能力の両方を提供します。割当てを解除された領域は表領域に戻されるため、その表領域内にある他 のオブジェクトで使用できるようになります。セグメントの縮小はオンライン操作です。つまり、セグメン トの縮小処理が実行されている間でも、縮小される表は問合せおよびDMLに使用できます。さらに、セグメ ント縮小はインプレースで実行されます。Oracle Databaseには、縮小の候補となるセグメントを簡単に特定 できるように、自動セグメント・アドバイザも組み込まれています。このアドバイザは、事前に指定された メンテナンス時間枠で毎晩実行され、縮小が必要なセグメントを事前予防的に特定します。 オンデマンドのセグメント作成 パッケージ・アプリケーションのインストールでは、何千ものデータベース表と索引が作成されることがよ くあります。これらの表と索引の作成には時間がかかり、さらに大量のディスク領域を使用する可能性があ ります。パッケージ・アプリケーションのすべてのモジュールに対応するライセンスを取得していない場合 は、これらの表と索引の多くが使用されないままになることもあります。Oracle Databaseでパーティション 化されていない表と索引を作成する場合、デフォルトでは、データベースは遅延セグメント作成を使用して データベース・メタデータだけを更新し、ユーザー・セグメントの初期作成を回避します。これによって、 ディスク領域が節約され、インストール時間が大幅に短縮されます。ユーザーが表に最初の行を追加すると、 データベースは、表のためのセグメント、表のLOB列、表の索引を作成します。 オンデマンドのセグメント作成は、時間、領域、コンピューティング・リソースを節約します。 18 Oracle Database 12cの管理性 Compression Advisor Oracle Database 11gの表圧縮は、アプリケーションに対して完全に透過的です。Oracle Databaseに組み込 まれたCompression Advisorにより、データに合った的確な圧縮レベルを簡単に選択できます。Oracle Database 11gにおける既存のアドバイザ・フレームワークの一部として、Compression Advisorはデータ ベース内のオブジェクトを分析して達成可能な圧縮率を検出し、最適な圧縮設定を行うための推奨事項を提 示します。 Exadataの管理とクラウドの統合 Oracle Exadataインフラストラクチャ上に異種データベースを統合しよ うとする企業が増える中で、Oracle Enterprise Manager Cloud Control 12cは総体的な管理手法を使用することで、Exadata Database Machine の管理者を支援します。また、エンジニアド・システム全体の監視から 管理、継続的な保守までの包括的なライフ・サイクル管理機能を提供し ます。 統合システム監視 Oracle Enterprise Managerが提供する包括的な監視および通知機能を利 用すると、管理者はOracle Exadata Database Machineとそのソフトウェ アおよびハードウェア・コンポーネントに付随する問題を事前に検出し、 対応できるようになります。管理者は、それぞれのデータセンター環境 の要件に合わせて、容易にこれらの監視設定を調整できます。アラート が 通 知 さ れ る と 、 管 理 者 は 、 InfiniBand ポ ー ト の ネ ッ ト ワ ー ク ・ パ フォーマンスやExadataストレージ・セルのディスク・アクティビティ などの、問題のコンポーネントに関連するパフォーマンス・メトリック とアラートの履歴を簡単に表示し、問題の根本原因を特定できます。 Oracle Enterprise Manager Cloud Control 12cでは、Exadata Storage 図6：Exadataの略図 Server、InfiniBandスイッチ、Ciscoスイッチ、KVM、PDU、およびILOM を完全に管理し、監視することができます。 Oracle Enterprise ManagerはExadataのハードウェア・コンポーネントに直接接続されているため、ハード ウェア関連の障害を管理者に警告した上で、Oracle Automatic Service Requests（Oracle ASR）との統合を介 して自動的にサービス・リクエストを登録し、Oracle Supportによる素早いレビューが可能となります。 従来のシステムでは、データベース管理者、システム管理者、ストレージ管理者が協力して検出する必要の あった問題が、Exadata Database Machine全体に対応した統合システム監視機能によって、数分で診断され るようになりました。 19 Oracle Database 12cの管理性 障害診断 Oracle Database 11gには、問題の防止、検出、診断、解決を行うための高度な障害診断インフラストラク チャが含まれています。特に診断の対象となるのは、データベースの正常稼働に支障をきたす可能性のある 重大なエラーです。重大なエラーが発生すると、インシデント番号が割り当てられ、エラーの診断データ （トレース、ダンプなど）が即座に取得されます。取得された診断データは、インシデント番号でタグ付け されます。この診断データは自動診断リポジトリ（データベース外のファイル・ベースのリポジトリ）に格 納されます。リポジトリ内のデータは、後でインシデント番号により検索し、分析できます。Oracle Database 11gで大幅に改善された障害診断インフラストラクチャの目的は、次の利点を実現することです。 • ヘルス・チェックを使用してDBAに警告し、問題に事前に対処することで、壊滅的なシステム障害を防止 します。 • データ・リカバリおよびSQL Repair Advisorを使用して、問題発生後の破壊、修復、中断を抑制します。 • ADRおよびテスト・ケース・ビルダーを使用して、問題の診断に必要な時間を削減します。 • インシデント・パッケージング・サービス（IPS）およびOracle Configuration Support Managerを使用し て、ユーザーとOracle Supportとのやり取りを簡素化します。 障害診断インフラストラクチャの主要なコンポーネントとしては、以下のものがあります。 自動ヘルス・チェック Oracle Database 11gには、システムの事前予防的なチェックを実行する目的で、ヘルス・チェッカ・フレー ムワークが搭載されています。 SQLテスト・ケース・ビルダー 多くのアプリケーション・エラーでは、エラーが再現されるテスト・ケースを取得することが、問題の早期 解決への重要な要素となります。SQLテスト・ケース・ビルダーを使用すると、SQLテキスト、PL/SQL、 DDL、実行環境情報など、エラーを再現するために必要なすべての情報を自動的に収集できます。こうして 収集された情報をOracle Supportに送信することで、エラーを再現できます。 自動診断リポジトリ 自動診断リポジトリ（ADR）は、トレース、ダンプ、警告ログ、ヘルス・モニター・レポートといったデー タベース診断データ用のファイル・ベースのリポジトリです。ADR内の診断データは自己管理型であり、事 前定義のデータ保持設定に基づいて自動的に削除されます。また、ADRはデータベースで発生したすべての 重大なエラーのメタデータも管理しているため、管理者は、ADRに対して問合せを発行し、過去数日、数ヶ 月、あるいは数年の間にシステムで発生した重大なエラーの種類と数を確認できます。 V$DIAG_CRITICAL_ERRORビューには、現在のOracle Databaseリリースで重大なエラーとして指定される非 内部エラーがすべて表示されます。Oracle Database 12cには、これらの警告を記録するファイルであるデ バッグ・ログが個別にあります。デバッグ・ログはアラート・ログと同じ形式と基本動作を備えていますが、 修復が必要となる可能性のある潜在的な問題に関する情報のみが記載されています。デバッグ・ログは、ア ラート・ログとトレース・ファイルの情報量を軽減します。 20 Oracle Database 12cの管理性 また、デバッグ情報の可視性も改善します。デバッグ・ログはIPSインシデント・パッケージに含まれており、 Oracle Support用の内容になっています。アラート・ログとトレース・ファイルは簡素化されています。デ バッグ・ログで記録されているタイプの警告の量が少なくなっています。Oracle Database 12cでは、 ENABLE_DDL_LOGGING初期化パラメータがTRUEに設定されている場合、RDBMSコンポーネント用のみに個 別のDDLログが作成されます。DDLログには、データベースによって実行されたDDL文ごとに1つのログ・レ コードが含まれます。DDLログはIPSインシデント・パッケージに含まれています。 インシデント・パッケージング・サービス インシデント・パッケージング・サービスは、1つ以上のエラーに関連するすべての必要な診断データを収 集するプロセスを自動化します。 サポート・ワークベンチ サポート・ワークベンチは、Oracle Databaseの障害診断インフラストラクチャを操作するためのOracle Enterprise Managerの機能の1つです。サポート・ワークベンチでは、問題の調査、レポート、修復（必要な 場合）を使いやすいグラフィカル・インタフェースで実行できます。サポート・ワークベンチは、IPSを使用 した診断データのパッケージ化、サポート要求番号の取得、IPSパッケージのOracle Supportへのアップロー ドを、最小限の操作で、極めて短時間に実行可能にするセルフサービス型のツールです。これにより、エ ラー解決の所要時間が短縮されます。 図7：サポート・ワークベンチのワークフロー 21 Oracle Database 12cの管理性 データベース管理者にとっての利点 今日の急速に進化するIT環境では、変化と統合が絶え間なく続いていますが、データセンターのマネー ジャーや管理者がそれを困難だと考える必要はありません。Oracle Enterprise Manager Cloud Control 12cを 使用して管理されるOracle Database 12cの管理性機能のおかげで、データベース管理者は、システムの適切 なパフォーマンスと可用性を維持しながら、テストと統合を通じて、ユーザーにより品質の高いサービスを 提供できます。 まとめ 現代の企業は、競争力と収益性を強化するために、新しいテクノロジー・ソリューションを積極的に導入し ており、その結果、管理に関する課題は増加し続けています。Oracle Database 12cでは、これらの重要な課 題に対処するために、日常的な管理タスクが自動化されました。これによって、データベース管理者がデー タベースのパフォーマンスを最大レベルで維持すること、新しいテクノロジーをリスクなしですばやく導入 す る こ と 、 お よ び DBA の 生 産 性 と シ ス テ ム の 可 用 性 を 向 上 さ せ る こ と が 可 能 に な り ま し た 。 Oracle Enterprise Manager Cloud Control 12cを使用して管理されるOracle Database 12cは、次世代のDBAのために、 次世代のデータベース管理を提供します。 22 Oracle Database 12cの管理性 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 2013年6月 著者： Deba Chatterjee、Kurt Engeleiter 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りが Ashish Agarwal、Waleed Ahmed ないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保 共著者：Jagan Athreya、Mughees Minhas Prabhaker Gongloor Oracle Corporation World Headquarters 証および条件などのいかなる保証および条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本 文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、い かなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 500 Oracle Parkway IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Redwood Shores, CA 94065 Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。 U.S.A. UNIXはThe Open Groupの登録商標です。 海外からのお問い合わせ窓口： 0113 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 oracle.com