Oracle Database 11g Release 2データベースの管理性の概要 ·...

Oracleホワイト・ペーパー

2011年9月

Oracle Database 11g Release 2

データベース管理の概要

Oracleホワイト・ペーパー- Oracle Database 11g Release 2データベースの管理性の概要

概要 ..................................................................................................................................... 2

はじめに .............................................................................................................................. 2

管理性の課題 ...................................................................................................................... 3

パフォーマンス管理 ........................................................................................................... 3

パフォーマンス診断 ...................................................................................................... 3

アプリケーションのチューニング ................................................................................. 8

テストとテスト・データの管理 ....................................................................................... 13

Database Replayを使用したスループット・テスト ................................................... 14

SQL Performance Analyzerを使用した応答時間テスト .............................................. 16

テスト環境での機密データの保護 ............................................................................... 18

データのサブセット化によるストレージ・コストの削減 .......................................... 19

データベースのライフサイクル管理と継続的な管理 ....................................................... 19

データベースのライフサイクル管理 ........................................................................... 19

リソース管理 ............................................................................................................... 20

障害診断 ...................................................................................................................... 23

Exadataの管理とクラウドの統合 ..................................................................................... 26

統合システム監視 ........................................................................................................ 26

一元管理 ...................................................................................................................... 26

統合計画 ...................................................................................................................... 27

Database as a Service ................................................................................................. 27

計測とチャージバック ................................................................................................. 28

データベース管理者にとっての利点 ................................................................................ 28

結論 ................................................................................................................................... 28


2

概要

オラクルの統合エンタープライズIT管理製品ラインであるOracle Enterprise Managerは、業界初の完

全なクラウド・ライフサイクル管理ソリューションです。Oracle Enterprise Managerが提供するビ

ジネス主導型のIT管理機能を使用すると、アプリケーションからディスクに至るまで、エンタープラ

イズ・クラウドおよび従来のオラクルのIT環境を簡単に設定、管理、サポートできるようになります。

Enterprise Managerを利用することで、次の利点が得られます。

ビジネス上の観点から管理を実行することで、Oracle Fusion Applicationsを含む従来型のアプリ

ケーションとクラウド・アプリケーションで最高のサービス・レベルを達成できます。

Oracleスタックとエンジニアド・システムに対するインテリジェント管理を実現する最善のソ

リューションを通じて、IT管理への投資から最大の収益を得ることができます。

オラクルのナレッジベースと顧客環境がリアルタイムで統合されているため、他に例を見ない顧

客サポートが得られます。

はじめに

Oracleデータベースは、世界中の数多くの企業に加えて、アプリケーション開発者やデータベース

管理者から選ばれた、市場でもっとも広く普及しているデータベースです。企業は、年を追うごと

に、他に例のないパフォーマンスと信頼性を実現できるOracleデータベースへの依存度を高めてい

ます。オラクルは、画期的な管理性を備えた自己管理型のデータベースであるOracle Database 10g

で、ITの生産性を大幅に向上し、管理コストを劇的に削減しました。さらに、Oracle Enterprise

Manager Cloud Control 12cをリリースすることで、オラクルはもう一度、Oracle Databaseの管理水

準を上げる準備ができています。Oracle Database 11gおよびOracle Enterprise Manager Cloud

Control 12cは、急速な発展と変化を続けるデータセンター環境を対象として、ビジネスの要求に遅

れを取らないように設計されています。これらの製品を利用することで、組織はリスクを最小化し

ながら、新しいテクノロジーを素早く導入できます。また、業界を代表する自己管理機能を基盤と

して構築されたOracle Database 11gは、今日の企業が直面する最大の課題の多くに対応する管理性、

テストとテスト・データの管理、障害診断の分野で大きな進歩を遂げています。


3

管理性の課題

次の領域は、以前から、データベース管理者にとって管理上の最大の課題となっています。

パフォーマンスの診断とチューニング：確約したサービス・レベルを維持するために、本番デー

タベースで最高のパフォーマンスを発揮し続けるにはどうすれば良いか

テストとテスト・データの管理：Oracleデータベース環境でのテストとテスト・データの管理を

通じて、変更をロールアウトする際のリスク軽減を低コストで実現するにはどうすれば良いか

データベースのライフサイクル管理と継続的な管理：自動化によって日常的な繰り返し作業から

管理者を解放して、セキュリティやデータセンター統合、高可用性などのより戦略的な要求に重

点的に取り組めるようにするにはどうすれば良いか

クラウドの統合とExadataの管理：データセンター・コストを削減し、サーバー効率を上げるため

に、共通のインフラストラクチャ上にデータベースを統合するにはどうすれば良いか

これらの課題に対処するために、Oracle Database 11gは、パフォーマンス、変更保証機能、自己管理機

能の面で飛躍的な進歩を遂げており、Oracle Database 11gの管理はかつてないほど簡単になりました。

パフォーマンス管理

従来から、パフォーマンス管理は、データベース管理者にとって大きな課題の1つとなっています。

自己管理型データベースのOracle Database 11gを使用すると、データベースのパフォーマンスをこれ

までよりも簡単に管理できるようになります。Oracle Database 11gの自己管理機能はすべての領域で

拡大し続けており、これには、データベースのパフォーマンス管理における2つの主要機能であるパ

フォーマンス診断とアプリケーション・チューニングも含まれています。

パフォーマンス診断

優れたパフォーマンスの実現に必要な手順は、正しいデータを収集して適切な分析を行い、効果的

な行動計画を作成することです。

Oracleデータベースの自己管理フレームワークは、DBAの代わりにこれらの作業を実行することに

よって、パフォーマンス診断を簡素化して日常的に実施することを可能にします。Automatic

Workload Repository（AWR）は、必要なデータを収集し、Automatic Database Diagnostics Monitorは、

データを分析して、的確で具体的なすぐに実施できる推奨事項を提示します。それぞれの機能につ

いては、この後で詳しく説明します。

Automatic Workload Repository

Automatic Workload Repositoryは、Oracleデータベース内にある組込みリポジトリであり、特定のデー

タベースに関する運用統計情報やその他の同系統の情報が格納されています。Oracleデータベースは、

すべての重要な統計情報とワークロード情報のスナップショットを一定の間隔で作成し、AWRに格

納します。デフォルトでは、スナップショットは60分ごとに作成され、AWRに8日間格納された後で

自動的に消去されます。管理者は、これらのデフォルト設定の値を簡単に変更できます。AWRは、

軽量で完全に自己管理するように設計されているため、管理作業における管理者の負担が増えるこ

とはありません。


4

取得したデータを使用してシステム・レベルとユーザー・レベルの両方で分析を実施することが可

能になり、さらに問題を診断するために繰り返し行う必要がある作業の負担が減ります。AWRは、

オーバーヘッドを最小限に抑え、データの取得を効率的に実行できるように最適化されています。

AWRは、Oracle Databaseのすべての自己管理機能に関する基盤を形成します。また、Oracleデータベー

スの使用履歴に関する情報を提供する情報源です。これにより、データベースは、システムが稼働

している環境の個別の状況に合わせて正確な決定を下すことができます。

Automatic Database Diagnostics Monitor（ADDM）

取得したデータがAWRに格納されることを踏まえて、Oracle Databaseには、Automatic Database

Diagnostic Monitorと呼ばれる自己診断エンジンが搭載されています。ADDMによって、Oracleデータ

ベースでは、自身のパフォーマンスを診断して、検出された問題の解決方法を決定することが可能

になりました。取得した各統計情報がAWRに格納されると、ADDMは自動的に実行され、パフォー

マンスの診断データがすぐに利用できる状態になります。

ADDMは、AWRに格納されているデータを調べて分析を実行し、大きな問題を事前に見つけ出すこ

とで、推奨される解決方法を提示するとともに、問題解決によって期待される利益を定量的に示し

ます。ADDMでは、コンポーネント間における共通の基準として時間を使用し、システムのパフォー

マンスに対する全体的な働きかけを行います。ADDMの目標は、もっとも'データベース時間'を消費

するシステムの領域を特定することです。ADDMはドリルダウンによって問題の根本的な原因を特

定するため、単に症状を説明するのではなく、問題がシステム全体に与える影響をレポートに出力

します。推奨事項が提示される場合は、その中で、時間に関して期待できる利益が示されます。

データベースの全体時間などのメトリックを使用することで、複数の問題または推奨事項の影響を

比較できるようになりました。これまでは、多くの問題の特定が、影響の定量化ではなく、価値判

断と経験に基づいて行われていました。その良い例としては、ログオン率が高いという問題を抱え

ているシステムが挙げられます。経験則では、1秒間に10回を超えるログオン率は問題であり、修正

する必要があると言われてきました。しかし、多くのシステムは、それを大幅に超えるログオン率

でも、パフォーマンスに目立った影響を受けずに動作します。AWRにある時間分布データを使用す

ることで、ADDMでは、ログオンに使われる時間がデータベース処理時間の20%に達しているという

定量的なレポートを出力できます。この定量化された値によって、単に'ログオンの実行回数が多す

ぎると思われます'といった報告ではなく、問題の修正作業または修正の手配を行う担当者をより簡

単に納得させることが可能になります。

ADDMは、データベースがもっとも時間をかけている操作に焦点を置いて分析を開始し、高度な問

題分類ツリーへとドリルダウンします。ADDMで使用される問題分類ツリーは、オラクルのServer

Technologies Performance Groupやその他のパフォーマンスの専門家が持つ、何十年にも渡るパフォー

マンス・チューニングの経験をまとめたものです。

問題分類ツリーの開発における最大の目的は、単なる症状の説明ではなく、よくある問題を処理し

て問題の根本的な原因にまでドリルダウンすることでした。ADDMによって検出される一般的な問

題には、次のようなものがあります。


5

CPUのボトルネック

不十分な接続管理

過剰な解析

ロック競合

I/O容量

Oracle Databaseのメモリ構造のサイズ不足（例：PGA、バッファ・キャッシュ、ログ・バッファ）

高負荷のSQL文

実行に時間のかかるPL/SQLとJava

ログ・ファイルが小さいことなどで起きるチェックポイントでの高負荷

Oracle Real Application Clusters（Oracle RAC）固有の問題

ADDMは、潜在的なパフォーマンスの問題をレポートする以外に、システムで問題のない領域の情

報も記録します。I/Oやメモリなど、システムのパフォーマンスに重大な影響を及ぼすことがないサ

ブコンポーネントは、早い段階で問題分類ツリーから除外されてリストに表示されるため、DBAは、

対策を実施してもほとんどパフォーマンスが改善されないこれらの領域を素早く確認できます。さ

らに、この機能は、全体的なシステム・パフォーマンスに影響することがない領域の修正にかかる

無駄な時間と労力（人的な面とハードウェア的な面の両方）を節約します。

Oracle Database 11gでは、Oracle Real Application Clustersデータベース向けに、クラスタ単位のパ

フォーマンス分析機能を大幅に強化することで、ADDMが拡張されています。Oracle RAC環境では、

ADDMがOracle RACクラスタを分析し、個々のインスタンスだけでなくデータベース全体に影響を

与える問題をレポートに出力します。これにより、DBAはADDMを使用して、高負荷SQL、グロー

バル・キャッシュのインターコネクト通信量、ネットワークの遅延問題、即時応答時間の歪み、I/O

容量などの全リソースに対してデータベース全体の分析を実施できます。

Oracle Databaseは、このような革新的な自己診断機能を導入した最初のデータベース製品として、

データベース管理の環境を完全に変えました。これによって、管理者は、パフォーマンスの問題を

解決する答えを見つけるために、大量の診断データを収集し、膨大な時間をかけて分析する必要が

なくなりました。Oracle Database 11gでは、何がパフォーマンスの問題になっているかをデータベー

スに問い合わせるだけで済み、残りの作業はADDMが実行します。管理者はマウスを数回クリック

して、ADDMが提示する推奨事項に従うだけで良いのです。

リアルタイムADDMを使用した応答しないデータベースの診断

Oracle Enterprise Manager Cloud Control 12cに導入されているリアルタイムADDMは、従来であれば

データベースの再起動を必要とした、極めてパフォーマンスの低いデータベースやハングしたデー

タベースの問題を分析するための革新的な手段を提供します。リアルタイムADDMを利用すると、

データベースの再起動に頼ることなく、デッドロックやハング、共有プール競合やその他の例外状

況を解決できます。


6

図1：SQL Performance Analyzerのレポート

リアルタイムADDMは2種類の接続モードを使用して、ターゲット・インスタンスに接続します。通

常のJDBC接続は、利用可能な接続がある場合に広範囲のパフォーマンス分析を実行することを目的

としています。ラッチレス接続を行う診断モードは、通常の接続が使用できない極度のハング状況

に有効です。データベース管理者は診断モードを使用することで、リアルタイムADDMを使用した

分析を実行し、ハング状況の解決方法に関する推奨事項を得ることができます。

期間比較ADDMを使用したパフォーマンスの比較分析

Oracle Enterprise Manager Cloud Control 12cの新機能である期間比較ADDMを利用すると、管理者は、

なぜ今日のパフォーマンスは昨日より低いのか、といった長年の疑問に答えることができます。管

理者はAWRベースラインまたは古いAWRスナップショット期間、もしくは適切なカレンダー期間の

いずれかを選択し、特定の期間のパフォーマンスが別の期間よりも低い原因を特定できます。期間

比較ADDMはベース期間と比較期間の両方をチェックし、パフォーマンスが異なる根本原因を特定

する一連の調査結果を出力します。また、2つの期間に対してSQL Commonality索引を使用すること

で、2つの期間が同等であるかどうか、つまり、同じ期間に類似したSQLを実行しているかどうかも

示します。

AWRベースラインと適応しきい値

AWRの有効性と価値は、Oracle Databaseが新しくリリースされるたびに拡大し続けています。AWR

ベースラインを使用すると、DBAは、関心のあるワークロードまたは代表的なワークロードについ

て、一定期間に渡ってシステム・パフォーマンスのデータを記録して保存できます。

ベースラインは、システム・パフォーマンス・メトリックの警告しきい値を設定する際にも使用

されます。大半のメトリックは、Oracle Enterprise Manager内で、ベースライン期間に測定された、

そのメトリックの統計情報集計と対比して表示できます。これにより、ユーザーは、実データの

コンテキストとは無関係なしきい値を選択するのではなく、ベースラインに基づいたしきい値を

設定できます。また、特定のキー・パフォーマンス・メトリックには適応しきい値も設定できま

す。適応しきい値は自動的に設定されるパフォーマンス警告しきい値です。しきい値の決定の基

準として、システム移動ウィンドウ・ベースラインのデータを使用したシステムによって定期的

に調整されます。適応しきい値をすぐに使用する顧客は、新しい"クイック構成"オプションを用い

て、一般的なワークロード・プロファイルに基づき、しきい値の初期設定を数回のクリック操作

でセットアップできます。


7

AWRベースラインは、動的な将来のベースラインを定義するための強力な機能を実現し、比較用パ

フォーマンス・データの作成および管理のプロセスを大幅に簡素化します。

Active Session History

AWRのもう1つの主要コンポーネントは、Active Session History（ASH）です。

すべてのアクティブなデータベース・セッションは、毎秒、自動的にサンプリングされ、Active Session

Historyに保管されます。ASHデータは、現在データベース時間が費やされている個所を示すととも

に、パフォーマンス・ボトルネックがあれば、これを明らかにします。

Oracle Database 11g Release 2は、Oracle RACの追加情報を集めることでASHを拡張しています。この

情報は、ADDM for RACなどのアドバイザによって使用され、ASHレポートに含まれる新しいOracle

RAC固有のセクションに表示されます。このリリースのASHレポートでは、クラスタ待機クラスで

セッション・アクティビティのもっとも多くの割合を占めるイベントが、影響を受けるインスタン

スの数とともに表示されます。この情報によって、Oracle RAC固有の潜在的な問題が一層明らかに

なります。

また、ASHはスタンバイ・データベース上でも実行できるように拡張されているため、Active

Dataguardインスタンスで実行される問合せのパフォーマンスを分析する際に役立ちます。

ASH Analytics

Oracle Enterprise Manager Cloud Control 12cに含まれるASH Analyticsは、ASHデータを調査するための

新しいツールです。このツールを利用すると、管理者はさまざまなパフォーマンス・ディメンショ

ンにまたがるパフォーマンス・データのロールアップやドリルダウン、および各種分析を実行でき

ます。データベース管理者はASH Analyticsを使用することで、任意の時点のデータベース・セッショ

ンの各種パフォーマンス属性を調査できるようになります。

各種のディメンションにフィルタを作成できるため、DBAはパフォーマンスの問題を特定できるだ

けでなく、システムのリソース使用量やさまざまなパフォーマンス・パターンを十分に理解できま

す。また、ASH Analyticsビューをアクティブ・レポートとして使用できるため、パフォーマンス問

題のオフライン分析に後から使用できます。組込みのツリーマップ・ビューを使用すると、管理者

は事前定義されたパフォーマンスのディメンション階層を使用して、パフォーマンス・データを調

査できます。


8

図2：ASH Analytics

アプリケーションのチューニング

アプリケーション設計の問題は、パフォーマンス問題のもっとも大きな原因です。開発者、DBA、

システム管理者のチューニングに関するすべての英知をもってしても、アプリケーションの構造上

および設計上の不備が原因の速度低下を補うことはできません。したがって、データベース・シス

テムのパフォーマンス・チューニングの重要な部分の1つは、SQL文のチューニングです。

問合せオプティマイザは、索引を使用するかどうか、問合せに複数の表の結合が含まれる場合にど

の結合方法を使用するかなど、問合せのパフォーマンスに大きな影響を与える重大な決定を行いま

す。そのため、オラクルは多大な開発労力をつぎ込んで、業界最高の性能と完成度を持ち、十分に

テストされた問合せオプティマイザであるコストベース・オプティマイザを作り上げました。また、

コストベース・オプティマイザは、Oracle E-Business Suite、SAP、PeopleSoftなどの主要なパッケー

ジ・アプリケーションで幅広く使用されています。これらのアプリケーションを使用している顧客

の大多数がプラットフォームとしてOracleデータベースを採用しているため、実際に稼働している膨

大な数のアプリケーションにおいてもオラクルのオプティマイザが活躍していることになります。

その結果として、Oracle Database 10gで導入されたルールベース・オプティマイザ（RBO）はすでに

利用できなくなっており、現在サポートされているオプティマイザ・モードはコストベース・オプ

ティマイザのみとなっています。

Oracle Databaseが提供する最高の問合せ最適化テクノロジーは、多くの場合において管理者の介入な

しでアプリケーションと問合せのパフォーマンスを最大化します。それでも、いくつかの場合には、

アプリケーションの性質またはデータ分散の特異性が原因で、特定のSQL文によるシステム・リソー

ス全体の消費率が通常ではあり得ないほど高くなってしまうことがあります。このような状況では、

SQLチューニング・プロセスで次の3つの基本手順が実行されます。

システムで利用できる過去のSQL実行履歴（例：V$SQL動的ビューに格納されているカーソル・

キャッシュの統計情報）を調べて、アプリケーション・ワークロードおよびシステム・リソース

の大部分が占有される原因となっている高負荷または負荷が最高のSQL文を特定します。

問合せオプティマイザによって作成された実行計画で、それらの文が適切に機能することを検証

します。

パフォーマンスの低いSQL文に対して、考えられる修正処理を実行し、より優れた実行計画を生

成します。

この3つの手順は、システム・パフォーマンスが十分なレベルに到達するまで、またはチューニング

できる文がなくなるまで繰り返されます。前述のSQLチューニング・プロセスでは、膨大な時間がか

かるだけでなく、高度な専門知識も必要です。アプリケーションとデータベース・システムに関す

る深い知識を持った人物だけが、この作業を実施できます。


9

SQLチューニング・アドバイザとSQLアクセス・アドバイザ

Oracle Database 10g以降では、SQLのチューニング・プロセスが完全に自動化されています。ADDM

は、異常に多くのシステム・リソースを消費してパフォーマンスの問題を引き起こしているSQL文を

特定します。さらに、CPUと共有メモリをもっとも多く消費しているSQL文は、自動的にAWRに記

録されます。したがって、新しいチューニング・フレームワークでは高負荷のSQL文が自動的に特定

されるため、管理者が介入する必要はありません。

リソース消費量のもっとも多いSQL文が特定されると、Oracle Databaseは、問合せオプティマイザに

新しく追加されたAutomatic Tuning Optimizerと呼ばれる自動チューニング機能を使用して、それらの

SQL文を自動的に分析して、推奨される解決方法を提示できます。自動チューニング・オプティマイ

ザは、SQLチューニング・アドバイザと呼ばれるアドバイザを介して公開されます。SQLチューニン

グ・アドバイザは、1つまたは複数のSQL文を取り込み、チューニング・アドバイスに従って適切に

チューニングされた計画を作成します。管理者がSQLチューニング・アドバイザを起動するだけで、

推奨される解決方法が提示され、他の操作は一切必要ありません。ここで重要なことは、解決方法

はオプティマイザによって提示されるものであり、何らかの事前に定義された経験則を使用する外

部ツールからのものではないということです。これには、次のような利点があります。

実行計画に最終的な責任を持つシステム・コンポーネントによって、チューニングが実行されます。

チューニング・プロセスが完全にコスト・ベースであるため、問合せオプティマイザに対する変

更や拡張が自然に反映されます。

チューニング・プロセスはSQL文の過去の実行統計をふまえて、この文に対するオプティマイザ

設定をカスタマイズします。

問合せオプティマイザにとって何が有益であるかに基づいて、通常の統計情報以外に補助的な情

報を収集します。

自動チューニング・オプティマイザの推奨事項は、以下の4つのカテゴリに分類されます。

統計分析：自動チューニング・オプティマイザは、統計情報が欠落または古くなっている各問合せ

オブジェクトを調べて、関連する統計情報を収集するための推奨事項を提示します。また、推奨事

項が実装されていない場合は、欠落している統計情報を提供するため、または古くなった統計情報

を修正するために、補足情報を収集します。

SQLプロファイリング：自動チューニング・オプティマイザは、予測を検証し、補足情報を収集す

ることで、予測誤差を排除します。また、SQL文の過去の実行履歴に基づいてオプティマイザの設定

をカスタマイズする方法で（例：最初の行とすべての行の比較）、補足情報を収集します。自動チュー

ニング・オプティマイザは、補足情報を使用してSQLプロファイルを構築し、それを作成するための

推奨事項を提示します。SQLプロファイルが作成されると、問合せオプティマイザは、（通常モード

で）適切にチューニングされた計画を生成することが可能になります。SQLプロファイルの最大の利

点は、構文を一切変更せずに問合せをチューニングできることです。したがって管理者は、パッケー

ジ・アプリケーションに埋め込まれているSQL文をチューニングするソリューションを得られること

になります。


10

アクセス・パス分析：自動チューニング・オプティマイザは、問合せの中にある各表へのアクセス

時間を大幅に改善するために新しい索引が使用できるかどうかを調べて、該当する場合は、このよ

うな索引を作成するための推奨事項を提示します。

SQL構造分析：自動チューニング・オプティマイザは、不適切な計画の原因となっているSQL文の特

定を試み、計画を再構築するための関連する推奨事項を提示します。再構築のための推奨事項では、

SQLコードに対する構文の変更およびセマンティックの変更が推奨される場合があります。

アクセス・パスとSQL構造の両方を分析することは、開発中のアプリケーションのパフォーマンス・

チューニング、および管理者と開発者がアプリケーション・コードにアクセスする独自の本番アプ

リケーションのパフォーマンス・チューニングに非常に役立つことがあります。

SQLアクセス・アドバイザは、Oracle Databaseの管理性に関係するもう1つの主要なコンポーネント

です。SQLアクセス・アドバイザは、特定のワークロードに対してスキーマ設計の分析を自動的に行

い、そのワークロードに関する索引、マテリアライズド・ビュー、マテリアライズド・ビュー・ロ

グの作成、保存、または削除を必要に応じて推奨します。推奨事項を生成する際に、SQLアクセス・

アドバイザでは、問合せのパフォーマンス向上に加えて、挿入、更新、削除などのデータ操作のア

クティビティに新しいアクセス構造を追加した場合の影響が検討されます。SQLアクセス・アドバイ

ザのインタフェースは非常に使いやすく、システムに関する多くの知識を必要としません。また、

データは、本番システムから収集されて、SQLアクセス・アドバイザを実行できる別のマシンに取り

込まれるので、SQLアクセス・アドバイザは、本番システムに影響を与えずに動作させることができ

ます。

Oracle Database 11gでは、SQLアクセス・アドバイザが改良され、SQLアクセス構造推奨事項の一部

として、パーティション・アドバイスが提示されるようになりました。

自動SQLチューニング

Oracle Database 11gでは、データベースを最高のパフォーマンスで稼働し続けるために、SQLチュー

ニング・プロセスのさらなる改善と自動化が実施されています。現在は、SQLチューニング・アドバ

イザが、システム・メンテナンスの時間枠で、メンテナンス・タスクとして自動的に実行されるよ

うになりました。SQLチューニング・アドバイザは、実行されるたびに、システム内で処理負荷の大

きいSQL問合せを自動的に検出し、それらのチューニング方法に関する推奨事項を生成します。

推奨事項を検証するため、Oracle DatabaseのSQLチューニング・アドバイザは、SQLプロファイルが

推奨される新しい実行計画でSQL文のテストを実行します。これにより、SQLプロファイル推奨事項

の正確性と信頼性が大幅に向上します。

SQLチューニング・アドバイザは、SQLプロファイル推奨事項を自動実装するように設定できます。

自動実装を有効にすると、アドバイザによって、少なくともパフォーマンスが3倍以上に向上するSQL

文に対してのみSQLプロファイルが作成されます。新しい索引の作成、オプティマイザ統計のリフ

レッシュ、SQLの再構築に関する推奨事項といった、その他のタイプの推奨事項については、手動で

実装する必要があります。自動SQLチューニング・アドバイザは、DML文をチューニングの対象と

はみなしません。デフォルトでは、自動SQLチューニング・アドバイザは夜間に実行され、推奨事項

レポートのみを出力するように構成されています。推奨事項の自動実装はデフォルトでは行われま

せん。

自動SQLチューニングの結果のサマリーは、過去7日間といったように期間を指定して表示できます。

処理されたすべてのSQL文について、作成された推奨事項の詳細なレポートも表示できます。これら

の推奨事項は、手動プロセスで選択的に実装できます。また、自動的に実装された推奨事項も表示

できます。自動SQLチューニング・アドバイザは任意のメンテナンス・ウィンドウで実行するように

構成できます。また、必要に応じて、完全に無効にすることもできます。


11

リアルタイムSQL監視

Oracle Database 11gのリアルタイムSQL監視機能では、実行中のSQL文のパフォーマンスを監視でき

ます。標準で追跡される新しい詳細なSQL統計の使用によって、長時間実行されるSQLの実際の実行

計画が、Oracle Enterprise ManagerのSQL監視ページに自動的に表示されます。

デフォルトでは、SQL文がパラレルで実行された場合、またはSQL文が1度の実行でCPU時間やI/O時

間を5秒以上消費した場合に、リアルタイムSQL監視機能が自動的に開始されます。DBAは、SQL文

の実行に合わせて各ステップの統計情報を表示することで、実行計画の全体を通してSQL文のステッ

プを確認できます。実行計画の各ステップにおける行ソース情報が、キー・パフォーマンス・メト

リックによって追跡されます。使用されるメトリックには、経過時間、CPU時間、読取りと書込み

の回数、I/O待機時間、およびその他の待機時間などが含まれます。SQL監視機能は、長時間実行さ

れるSQLのどのステップが実行されているかを示す情報をDBAに提供します。これによって、DBA

は、追加のチューニング操作を実行する必要があるかどうかを判断できます。

Oracle Database 11g Release 2では、リアルタイムSQL監視機能が強化され、Oracle Exadata Database

Machineで部分的に実行されている実行計画にも対応しました。

図3：実行計画のリアルタイムSQL監視

SQL文をリアルタイムで監視できるようになったことに加えて、Oracle Database 11g Release 2では、

DBAはアクティブ・レポートにある実行の詳細情報のすべてを、オフライン分析に使用可能なイン

タラクティブ・レポートに保存できるようになりました。この機能では、さまざまなレベルの詳細

情報にドリルダウンすることによって、ライブ表示と同じレベルの双方向性が提供されます。


12

SQL計画の管理

SQL計画の管理では、SQL実行計画の取得、選択、改善のためのコンポーネントを提供することによっ

て、SQL文の実行計画の急な変更が原因で起こるパフォーマンスの低下を防ぎます。SQLパフォーマ

ンスは、オプティマイザの新バージョン、オプティマイザの統計および（または）パラメータの変

更、SQLプロファイルの作成など、さまざまな変更によって影響を受けます。SQL計画の管理は、時

間の経過とともに変化するSQL文の実行計画を記録して評価し、効率的であることが分かっている既

存の計画セットで構成されるSQL計画ベースラインを構築する予防的なメカニズムです。こうして作

成されたSQL計画ベースラインは、システムの変更にかかわらず、対応するSQL文のパフォーマンス

を維持するために使用されます。

SQL計画の管理を使用してSQLのパフォーマンスを改善、または維持する一般的なシナリオを以下に

示します。

新バージョンのオプティマイザのインストールを伴うデータベースのアップグレードを実施す

ると、ごく一部のSQL文の実行計画が変更される場合があります。大半のSQLパフォーマンスは、

これらの計画変更によって、向上するか変化しないかのどちらかですが、特定の計画変更がパ

フォーマンスの低下の原因になることもあります。SQL計画ベースラインを使用すると、データ

ベースのアップグレードに起因するパフォーマンスの低下の可能性を最小限に抑えられます。

継続的なシステムとデータの変更は、一部のSQL文の実行計画に影響を及ぼし、パフォーマンス

の低下を招く可能性があります。SQL計画ベースラインを使用すると、パフォーマンスの低下を

最小限に抑え、SQLパフォーマンスの安定化を図ることができます。

新規アプリケーション・モジュールを配置すると、新しいSQL文がシステムに導入されます。ア

プリケーション・ソフトウェアは、新しいSQL文のための標準のテスト構成のもとで作成された

適切なSQL実行計画を利用できます。

SQL計画ベースラインは、より高いパフォーマンスを実現するために、時間の経過とともに改善され

ていきます。SQL計画ベースラインの改善フェーズにおいて、Oracle Database 11gは、定期的に新し

い計画のパフォーマンスを評価し、より高いパフォーマンスを実現する計画をSQL計画ベースライン

に組み込みます。新しい計画とSQL計画ベースラインから選択された計画との間でパフォーマンスが

比較され、新しい計画のパフォーマンスの方が高いことが確認されると、その計画がベースライン

に組み込まれます。

ストアド・アウトラインのSQL計画ベースラインへの移行

SQL計画の管理の一部としてSQL計画ベースラインが導入される以前は、ストアド・アウトラインが

類似の機能を提供していました。しかし、ストアド・アウトラインには、柔軟性およびSQL計画の管

理との適合性が欠けていました。

ストアド・アウトラインでは、時間の経過とともに計画を自動的に改善することはできません。

つまり、ストアド・アウトラインはそれが作成されたときは有効であっても、データベースに変

更が加えられた後は不適切な計画となってしまい、パフォーマンス低下の原因となることがあり

ます。


13

ストアド・アウトラインのヒントは、無効になる可能性があります（例：削除された索引に対応

する索引ヒント）。このような場合、データベースは無効になったヒントを除外してアウトライ

ンを引き続き使用しますが、作成される計画は、元の計画、またはオプティマイザによって生成

された最新で最適なコスト計画よりも劣ることがほとんどです。

SQL文に関して、オプティマイザは、現在指定されているカテゴリ内のストアド・アウトライン

で定義された計画だけを選択できます。たとえパフォーマンスが向上するとしても、異なるカテ

ゴリ内にある他のストアド・アウトライン、または最新のコスト・ベースの計画を選択すること

はできません。

Oracle Database 11g Release 2では、ストアド・アウトラインをSQL計画ベースラインに移行する機能

が提供されています。SQL計画ベースラインへの移行には、以下のような利点があります。

SQL計画ベースラインによって、オプティマイザは同じ適切な計画を使用できるようになり、ま

たその計画を時間の経過とともに改善することが可能になります。特定のSQL文に対して、パ

フォーマンスの低下を起こさないことが確認された新しい計画を、SQL計画ベースラインとして

追加できます。

SQL計画ベースラインは、無効なヒントによって計画が不適切な状態になるのを防止します。計

画ベースラインに格納されているヒントが無効になると、オプティマイザによる計画の再作成が

できなくなることがあります。この場合、オプティマイザは、別の再作成可能な計画ベースライ

ン、またはオプティマイザによって生成された最新で最適なコスト計画を選択します。

特定のSQL文に対して、データベースは複数の計画ベースラインを保持することが可能です。ス

トアド・アウトラインで定められていたようなカテゴリごとに1つの計画という制限がなくなり、

オプティマイザは特定のSQL文に対して一連の適切な計画の中から1つを選択できるようになり

ました。

Oracle Database 11g Release 2の移行パスを利用することによって、ストアド・アウトラインを使用す

る古いアプリケーションから透過的に移行して、SQL計画の管理における強化された機能をただちに

活用できます。

テストとテスト・データの管理

Oracle Enterprise ManagerのApplication Quality Management（AQM）ソリューションを利用すると、ア

プリケーション・スタックを構成するすべての層で高品質なテストを実施できます。徹底的なテス

トを実施することで、ユーザーはアプリケーションの配置前にその品質とパフォーマンスの問題を

見つけ出すことができます。テストは、アプリケーションの配置を成功させる上でもっとも困難か

つ時間を要する作業ですが、プロジェクトの成功にとって、もっとも不可欠な要素でもあります。

Oracle Enterprise Managerのテスト機能およびセキュアなテスト・データ管理機能は、Oracleデータ

ベースのテスト機能を独自の組み合わせで提供します。この機能を利用することで、ユーザーは次

の利点が得られます。

インフラストラクチャ変更のテスト：Oracle Real Application Testingはデータベース層のインフラ

ストラクチャ変更テスト向けに設計および最適化されており、実際のアプリケーションの本番

ワークロードを使用して、テスト環境でデータベース・パフォーマンスを検証できます。


14

テスト・データの管理と本番クラスのセキュアなテストの実施：Oracle Data Maskingソリューショ

ンとOracle Test Data Managementソリューションを利用すると、企業はセキュリティとコンプライ

アンスの目標を達成できるようになります。本番データベース内の機密データをテスト・データ

ベースで不明瞭化し、本番データを適切なサイズのデータベースにスケールダウンすることで、

テスト環境や開発環境で、本番データをセキュアに使用できます。

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とシステム

管理者は、変更が本番環境のシナリオを使用して十分にテストおよび検証されていることを認識し

ているため、最高の自信を持って、データセンターのインフラストラクチャ・コンポ―ネントを迅

速にテストしてアップグレードできます。

迅速な配置

Database Replayのもう1つの利点は、DBAが、何ヶ月もかけてアプリケーションの機能に関する知識

を取得して、開発用のテスト・スクリプトを用意する必要がないという点です。数回マウスをクリッ

クするだけで、本番環境全体のワークロードを簡単に再現してシステム変更のテストとロールアウ

トを実施できます。これによって、従来は何ヶ月もかかっていたテスト・サイクルが数日または数

週間に短縮され、結果として大幅なコスト削減になります。

Database Replayの処理は、以下の4つの主要なステップで構成されています。

1. ワークロードの取得 - ワークロードの取得を有効にすると、Oracleデータベースに対するす

べての外部クライアントの要求が追跡され、ファイル・システム上のバイナリ・ファイル（取

得ファイル）に格納されます。ユーザーは、取得ファイルの保存場所、およびワークロード

の開始時間と終了時間を指定します。ワークロードの取得処理中は、外部データベースの呼

出しに関するすべての情報が取得ファイルに書き出されます。


15

2. ワークロードの処理 - ワークロードを取得した後は、取得ファイル内の情報を処理する必要

があります。この処理では、取得データを再生ファイルに変換し、ワークロードの再生に必

要なすべてのメタデータを作成します。取得ファイルは、通常、別のシステムにコピーして

処理します。取得したすべてのワークロードの処理が完了して初めて、ワークロードを再生

できるようになります。処理された取得ワークロードは、再生システム上で何度でも再生で

きます。ワークロードの処理には時間がかかり、リソースの消費量も多いため、一般的には、

ワークロードを再生するためのテスト・システム上で実行することが推奨されています。

3. ワークロードの再生 - 取得したワークロードの処理が完了すれば、再生準備が整います。ク

ライアント・プログラム（再生クライアント）は、再生ファイルを処理し、取得元のシステ

ムとまったく同じタイミングおよび同時実行性を再現して、データベースに対する呼出しを

発行します。ワークロードを正しく再生するために、取得したワークロードによって、1つま

たはそれ以上の再生クライアントが必要になることもあります。ワークロードに必要な再生

クライアントの数を決定するためのキャリブレーション・ツールも用意されています。DML

およびSQL問合せを含むワークロード全体が再生されるため、再生システム内のデータが

ワークロード取得元の本番システム内のデータと完全に一致していることが重要です。これ

によって、レポートの生成に使用できる信頼性の高い分析が可能となります。

4. 分析とレポーティング - 取得と再生の詳細な分析を実行できるように、広範なレポートが用

意されています。再生中に発生したエラーはレポートに出力されます。DMLや問合せによっ

て返される行の相違も表示されます。取得時と再生時の基本的なパフォーマンスの比較デー

タも提供されます。詳細な分析が必要な場合は、Database Replayの期間比較レポートおよび他

のAWRレポートによって、取得時と再生時のさまざまな統計情報の詳細な比較も可能です。

ワークロードの取得プロセスと再生プロセスの両方で、フィルタリング機能がサポートされていま

す。この機能は、たとえばサービス、アクション、モジュールなどで、対象になるワークロードを

絞り込むのに役立ちます。Oracle Enterprise Managerでは、Database Replay機能が提供するエンド・

ツー・エンドの自動化に対応することによって、Real Application Testingの価値が大幅に向上してい

ます。これによって、ワークロードの取得データとパフォーマンス・データの保存およびテスト・

システムへの転送、テスト・システムと再生クライアントの正しい設定、Oracle Enterprise Manager

インタフェースを介しての再生全体の調整といった一連のプロセスが簡素化されました。


16

図4：データベース再生ワークフロー

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を使用することで、企業は、これまでより低いコストで、本

番環境に対するシステム変更が実際にプラスの効果をもたらすことを極めて高い信頼度で確認できま

す。


17

SPAを使用して分析できる、共通のシステム変更の例を以下に示します。

データベース・アップグレード、パッチ、初期化パラメータの変更など

オペレーティング・システム、ハードウェア、またはデータベースに対する構成変更

新しい索引の追加、パーティション化、マテリアライズド・ビューといったスキーマの変更

オプティマイザ統計の収集

SQLプロファイルの作成などのSQLチューニング操作

SPAを使用するには、次の5つの手順を実行する必要があります。

1. SPAで分析するSQLワークロードを取得します。Oracleデータベースには、カーソル・キャッ

シュやAutomatic Workload Repositoryなどの複数のソースからSQLワークロードを取得して、

SQL Tuning Setに格納する方法が提供されます。この処理は、通常本番システム上で実行され

ます。その後、STSがテスト・システムに転送され、そこでSPA分析が実行されます。

2. 2. SQL Tuning Setに対してSPAを実行することで、変更前のワークロードのパフォーマンスを

計測します。非常に短時間の問合せを複数回実行してそれらの統計情報の平均値を求めるこ

とによって、バッファ・キャッシュの状態および他のノイズ要因が原因となっている値の変

動が除去されます。

3. データベースのアップグレードやデータベース・オプティマイザ統計のリフレッシュなどの

変更を行います。

4. ステップ2と同じようにSQL Tuning Setに対してSPAを実行することで、変更後のワークロー

ドのパフォーマンスを計測します。

5. SQL Tuning Setの2回の実行結果を比較して、効率が向上したSQL文、リグレッションが発生

したSQL文、変化のなかったSQL文を特定します。

図5：SQL Performance Analyzerレポート


18

このSPAの比較レポートでは、提示されたシステム変更の後、SQLワークロード全体のパフォーマン

スが大幅に向上しますが、リグレッションが発生した実行計画もいくつかあります。SPAでは、パ

フォーマンスへの影響を計測する際に、SQL文の実行回数も考慮されます。数秒で終わるが実行回数

の多いSQL文の方が、実行時間が長くても1回しか実行されないSQL文よりも、システムのパフォー

マンスに及ぼす影響が大きくなることがあるからです。SPAは、こうした要因を考慮に入れて、全体

的なパフォーマンスの向上と低下を予測します。SPAによってリグレッションが検出されると、ユー

ザーは、SQLチューニング・アドバイザまたはSQL計画ベースライン（Oracle Database 11gで新たに

導入されたプラン・スタビリティ機能）を使用してそのSQLを修正できます。

SPAでは、以下で簡単に説明されているような、システム変更の評価に役立つ他の多数の機能をサ

ポートしています。

1. SPAは、Exadataサーバーへの移行によって達成できるI/O負荷の軽減を予測するのに役立ちま

す。実際にハードウェアをプロビジョニングする必要はありません。この機能は、Exadataに

移行する必要がある潜在的なワークロードまたはシステムの特定に使用できます。

2. SPAは、2つのSTSの比較をサポートしています。この機能は、変更のテストに使用できる負

荷テスト・スクリプトまたはOracle Application Testing Suiteなどのメカニズムがある場合に役

立ちます。取得したワークロードを2つの異なるSTS（1つは変更前の状態を維持、もう1つに

は変更を適用）に格納することによって、一方のSTSでSPAを使用してシステム変更の影響を

評価できます。

3. Oracle Enterprise Managerでは、"ワンクリック"で転送できるSTSのメカニズムを使用して、本

番データベースとテスト・データベースの間を移動するSTSワークロードのプロセスを簡素化

できます。

正しいソリューションを選択することで、DBAは、システム変更を効率的に取り込み、管理できま

す。Database Replayは、システム・パフォーマンスをテストして改善することを目的に設計されてい

ます。SPAは、DBAがSQL応答時間を短縮するために使用します。Oracle Database 11g Real Application

Testingによって、データベース管理者は、ビジネスに必要不可欠なあらゆる変更をより少ないリス

クで簡単に管理および実行できるようになります。

テスト環境での機密データの保護

管理者は、Oracle Enterprise Managerのプロビジョニング機能を利用して、事前にテストされた、Oracle

データベースの標準化されたゴールデン・イメージをロールアウトできます。これによって、管理

者がプロビジョニング・プロセスの各ステップを手動で実行する必要がなくなるため、非常に大き

な労力が節約できます。これらのゴールデン・イメージを使用すると、バックアップ・データベー

スまたは稼働中の本番データベースからテスト・システムをプロビジョニングすることができます。

企業がアプリケーションの開発またはテストを目的として本番データをテスト環境にコピーする場

合、法令で定められた規則から逸脱するか、またはデータのプライバシ法違反として罰金や罰則を

課されるリスクがあります。管理者が使用できるデータ・マスキング機能は、開発環境、テスト環

境、ステージング環境で機密情報をマスキングすることで、組織がプライバシおよび機密保護法を

遵守できるように支援します。逆行できないプロセスを使用し、マスキング・ルールに基づいて機

密データをスクラブし、本物に見えるデータに置き換えることによって、セキュリティ管理者は、

元データの検索、リカバリ、またはリストアが不可能であることを保証できます。


19

データのサブセット化によるストレージ・コストの削減

データベース・アプリケーションが増加する中で、企業はアプリケーションの開発やテストに使用

される非本番環境のプロビジョニングという課題に直面しています。企業には、本番と同じデータ

をプロビジョニングするだけのストレージ経費を非本番データベースに対して負担する余裕も、本

番データを適切なサイズの開発環境に縮小するためのツールやアプリケーション知識もありません。

オラクルのテスト・データ管理機能を使用すると、アプリケーションの開発およびテスト向けに、

データセットの参照整合性を維持しながらサイズを縮小した本番データのコピーを作成できるため、

ストレージ・コストが削減されます。データ検出とアプリケーション・モデリングを通じて、オラ

クルのテスト・データ管理機能はエンタープライズ・アプリケーションの複雑なビジネス・ルール

を自動的に適用し、正確な本番データのサブセットを生成します。

Real Application TestingとData Maskingを統合すると、セキュアなテストを実行できます。多くの場合、

テストは非本番環境で実行されるか、または別のグループや組織によって実行されます。本番デー

タや、本番から取得された機密情報を含むワークロードを共有すると、データ・プライバシ規制の

違反につながり、多大なビジネス・リスクの原因となります。Real Application TestingとData Masking

を統合すると、データ・プライバシ規制を遵守しながら、取得したワークロードとデータをデータ

ベースで共有できます。

Oracle Enterprise Manager Cloud Control 12cのデータ・マスキング機能は拡張されているため、表内の

機密データだけでなく、SQL Tuning SetやDatabase Replayのワークロード取得ファイルなど、すべて

のReal Application Testingアーチファクトに渡って含まれる機密データが一貫してマスキングされま

す。このため、テスト・データがマスキングされた後でも、正しいテストを実行できます。Real

Application TestingとData Maskingを統合すると、企業はデータ・プライバシ規制に準拠した方法で、

セキュアなテストを実行できるようになります。

データベースのライフサイクル管理と継続的な管理

これまで管理者があまりにも多くの時間をかけて行ってきた日常的な繰り返し作業を自動化したこ

とは、自己管理データベースであるOracle Database 11gの主要な成果の1つです。データベースのプロ

ビジョニングやパッチ適用、メモリの割当てやディスク・リソースの管理などの単調で手間のかか

る管理作業から開放されることで、管理者は、セキュリティや高可用性などのより戦略的な要求に

重点的に取り組むことができるようになります。

データベースのライフサイクル管理

データベース・ライフサイクル管理の対象は、データベースのライフサイクル全体におよびます。

次に、その例を挙げます。

インベントリの検出と追跡：資産を検出し、追跡します。

初期プロビジョニング：データベースを数分でロールアウトします。

継続的な変更管理：パッチ、アップグレード、スキーマ、データ変更をエンド・ツー・エンドで

管理します。

構成管理：構成のずれ、詳細な構成検索、インベントリの追跡を実行します。


20

コンプライアンス管理：業界と規制コンプライアンスの標準をレポーティングし、管理します。

データベースのライフサイクル管理機能を利用すると、データベースを含むIT資産を手動で追跡す

る必要がなくなります。すぐに使える透過的なエージェントレス機能により、物理サーバーが検出

されます。いったん検出されたサーバーは簡単に管理状態に格上げされ、すべてのデータベースや

その他のアプリケーションを自動的に検出します。この自動検出機能によって、すべてのサーバー

とソフトウェアを確実に管理下に置くというプロセスが簡素化されるとともに、ITインフラストラ

クチャの統合と最適化の取組みが支援されます。

この機能には、基盤インフラストラクチャを含むOracle Database（単一インスタンス・データベース

とOracle RACデータベースの両方）のプロビジョニングとパッチを行うためのデプロイメント・プ

ロシージャが標準で含まれています。Enterprise Managerでは職務分掌がサポートされているため、設

計者がプロビジョニング・ワークフローとパッチ適用ワークフローを作成し、オペレータはこれら

のワークフローを使用してデータベースを配置するということが可能です。また、参照システムや

ゴールデン・イメージから新しいデータベースをプロビジョニングすることもできます。ゴールデ

ン・イメージは、構成の詳細とともにプロビジョニング・プロファイルで取得できます。プロビジョ

ニング・プロファイルは、参照システムから入手するか、またはオラクルからダウンロードできま

す。

データベース・ライフサイクル管理は、パッチ・アドバイザ、配置前分析、ロールアウト、レポー

ティングなどのパッチ管理のライフサイクル全体をサポートします。また、My Oracle Supportと統合

されているため、利用できるパッチや推奨パッチの同期ビューが提供されます。また、データベー

ス・ライフサイクル管理は、スキーマ変更の配置プロセスを完全に自動化します。管理者は構成の

絶対基準およびベースラインを定義することで、これらの定義に照らして環境を標準化できます。

リソース管理

メモリ割当てやディスク・リソースの管理などのリソース管理タスクを自動化することは、自己管

理型データベースであるOracle Database 11gにとって、もう1つの重要な成果でした。これらのタスク

について、詳しく確認してみましょう。

自動メモリ管理

メモリは重要なシステム・リソースであり、従来から、管理者はメモリ使用の最適化に多くの時間

をかけてきました。Oracle Database 11gにおける自己管理機能の重要な強化点の1つが、自動メモリ管

理機能です。この機能はOracle Databaseインスタンスによって使用される共有メモリの管理を自動化

するので、管理者は、手動で共有メモリを構成する作業から解放されます。自動メモリ管理機能は、

データベースの内部動作に関する高度な経験則に基づいて、メモリの配分を監視し、ワークロード

の要求に応じて配分を変更します。

Oracleのメモリ構造は、基本的に、共有メモリまたはシステム・グローバル領域（SGA）、およびプ

ライベート・メモリまたはプログラム・グローバル領域（PGA）で構成されています。Oracle9i Database

で、PGAの管理を自動化する自動SQL実行メモリ管理機能が導入されました。Oracle Database 10gで

は、自動共有メモリ管理機能によって、SGAに対しても同様のメモリ管理機能が導入されました。

これにより、PGA内の個々のSQL領域は、すべてシステムのワークロードに合わせて最高のパフォー

マンスが達成されるように自動的にサイズが決定され、共有メモリ内のすべてのメモリ・プールも

同様に、最適なパフォーマンスが達成されるように自動的にサイズが調整されるようになりました。


21

ユーザーはPGAとSGAのターゲット・サイズを指定するだけで済みます。その後は、指定されたター

ゲットの範囲内で最高のパフォーマンスが達成されるように、Oracleデータベースによって適切なメ

モリの割当てが自動的に行われます。Oracle Database 10gでは、SGAとPGAのターゲットを適切に設

定できるように、PGAアドバイザとSGAアドバイザも提供されています。

図6：自動メモリ管理

Oracle Database 11gでは、メモリ管理の自動化がさらに強化されています。PGAとSGAを含むすべて

のメモリが、自動メモリ管理機能によって集中管理されるようになりました。DBAが1つのパラメー

タMEMORY_TARGETを指定するだけで、ワークロードに基づいてPGAとSGAのサイズが自動的に

算出されます。また、間接メモリ転送により、ワークロードに応じてSGAとPGA間でメモリが相互

に転送されます。動的なメモリ割当ては、ワークロードの要件に応じてメモリの使用を最適化する

ために、頻繁に調整されます。これにより、メモリの使用率を最大化し、メモリ不足エラーを防ぐ

ことができます。ユーザーは、自動メモリ管理機能を使用する際に、SGAおよびPGAのターゲット

値をオプションとして設定できます。これにより、自動チューニング・モードにおいて、SGAとPGA

のサイズが、それぞれ指定されたパラメータ・ターゲット値を下回ることがなくなります。この機

能は、現在、Linux、Solaris、HP-UX、AIX、およびWindowsの各プラットフォームで利用できます。

Oracle Database 10gで初めて導入されたメモリ・アドバイザを使用すると、総メモリ領域のターゲッ

ト設定、SGAとPGAのターゲット設定、またはSGAコンポーネント・サイズの設定をグラフィカル

に分析できます。DBAは、これらの分析結果を用いて、データベースのパフォーマンスをチューニ

ングし、さまざまなケースに応じた計画シナリオを実行できます。データベースで使用されている

メモリ管理モードに応じて、各種のメモリ・アドバイザが利用できます。たとえば、自動メモリ管

理を有効にすると、インスタンス全体に割り当てるメモリ量のターゲット値の設定に関するアドバ

イスを受け取ることができます。自動共有メモリ管理を有効にすると、SGAとPGAのターゲット・

サイズの構成についてアドバイスを受けることができます。手動共有メモリ管理を有効にすると、

共有プール、バッファ・キャッシュ、およびPGAのサイジングについてアドバイスを受けることが

できます。


22

領域管理

領域管理は、データベース管理者がもっとも時間を使う可能性がある作業の1つです。しかし、Oracle

Database 11gでは使用領域は自動的に管理され、潜在的な領域問題が発生した場合には、管理者への

警告とともに推奨される解決方法が提示されます。

事前予防的な領域管理

Oracle Database 11gでは、非介入型のタイムリーな監視を実行して、データベース・サーバーの領域

使用率を確認します。Oracle Database 11gは、通常の領域割当ておよび割当て解除の処理中に領域使

用率を自動的に監視し、使用可能な空き領域が事前に定義されたしきい値を下回った場合は管理者

に警告します。Oracle Database 11gの領域監視機能は、標準で設定されているためパフォーマンスに

影響を与えることはほとんどなく、すべてのタイプの表領域に対して使用できます。データベース・

サーバーでの領域の割当ておよび割当て解除と同時に監視が実行されるため、管理者が必要なとき

に領域使用量の情報をすぐに利用できることが保証されます。

通知は、サーバーのアラート生成メカニズムを使用して実行されます。アラートは、データベース

で領域に関係する特定のイベントが発生した場合にトリガーされます。たとえば、表領域の領域使

用量がしきい値に達すると、アラートが生成されます。アラートのもう1つの例としては、再開可能

セッションで領域不足の状況が発生した場合です。修正措置を取れるように、アラートはただちに

DBAに送信されます。DBAは、アラート情報を含む呼出しを受け取ることにより、表領域に領域を

追加して、一時停止中の処理を停止したところから再開させることができます。

データベースには、アラート用の一連のしきい値がデフォルトで設定されています。DBAは、特定

の表領域のデフォルト値をオーバーライドするか、またはOracle Enterprise Managerを介してデータ

ベース全体に適用される新しいデフォルト値を設定できます。

透過的な領域再生

Oracle Database 11gでは、セグメントの縮小によって領域利用率を最適化するために、データのイン

プレース再編成を実行する機能が提供されています。セグメントの縮小によって、未使用領域を表

領域内にある他のセグメントで使用できるようになるため、問合せとDML操作のパフォーマンスが

向上する可能性があります。

セグメント縮小機能は、セグメントで使用される領域を圧縮する能力と、セグメントから領域の割

当てを解除する能力の両方を提供します。割当てを解除された領域は表領域に戻されるため、その

表領域内にある他のオブジェクトで使用できるようになります。データがまばらに移入されている

表では、全表スキャンに関係したパフォーマンスの問題が発生することがあります。セグメント縮

小機能を実行すると、表の中にあるデータは圧縮され、セグメントの最高水位標が引き下げられま

す。これによって、全表スキャンで読み取るブロックの数が少なくなり、処理が早くなります。

セグメントの縮小はオンライン操作です。つまり、セグメントの縮小処理が実行されている間でも、

縮小される表は問合せおよびDMLに使用できます。さらに、セグメント縮小はインプレースで実行

されます。これが、オンライン表再定義の実行による領域の圧縮および再生と比較した場合のおも

な利点です。DBAは、データベース内にある1つまたはすべてのオブジェクトに対して、セグメント

圧縮のスケジュールを夜間ジョブとして設定できます。その際に、領域をデータベース用に追加す

る必要はありません。


23

Oracle Database 11gには、縮小の候補となるセグメントを簡単に特定できるように、自動セグメント・

アドバイザも組み込まれています。自動セグメント・アドバイザは、事前に指定されたメンテナン

ス・ウィンドウで毎晩実行され、縮小が必要なセグメントを事前予防的に特定します。手動または

自動で起動された自動セグメント・アドバイザは、個々のオブジェクトに対して増加傾向分析を実

行し、7日間放置されている付加的な領域がオブジェクト内にあるかどうかを確認します。その後、

再生領域ターゲットを使用して、縮小するオブジェクトの候補を選択します。

オンデマンドのセグメント作成

パッケージ・アプリケーションのインストールでは、何千ものデータベース表と索引が作成される

ことがよくあります。これらの表と索引の作成には時間がかかり、さらに大量のディスク領域を使

用する可能性があります。パッケージ・アプリケーションのすべてのモジュールに対応するライセ

ンスを取得していない場合は、これらの表と索引の多くが使用されないままになることもあります。

Oracle Database 11g Release 2でパーティション化されていない表と索引を作成する場合、デフォルト

では、データベースは遅延セグメント作成を使用してデータベース・メタデータだけを更新し、ユー

ザー・セグメントの初期作成を回避します。これによって、ディスク領域が節約され、インストー

ル時間が大幅に短縮されます。ユーザーが表に最初の行を追加すると、データベースは、表のため

のセグメント、表のLOB列、表の索引を作成します。

オンデマンドのセグメント作成は、時間、領域、コンピューティング・リソースを節約します。

Compression Advisor

Oracle Database 11gでは、データの圧縮によって、ディスク領域の節約、データベース・バッファ・

キャッシュのメモリ使用量の削減、および問合せの実行速度の大幅な向上を実現しています。圧縮

の代償として、データ・ロードとDMLにおけるCPUのオーバーヘッドが増加します。しかし、I/O要

件が大幅に引き下げられるため、オーバーヘッドの増加分は相殺されます。

Oracle Database 11gの表圧縮は、アプリケーションに対して完全に透過的です。これは特に、意志決

定支援システムで役立ちます。このようなシステムは、長時間の読取り専用操作を実行し、大量の

データを保持していますが、オンライン・トランザクション処理システムで使用することも可能で

す。管理者は、表領域、表、またはパーティションの圧縮を指定できます。

Oracle Database 11g Release 2で追加されたCompression Advisorを使用すると、データに合った的確な

圧縮レベルを簡単に選択できます。Oracle Database 11gにおける既存のアドバイザ・フレームワーク

の一部として、Compression Advisorはデータベース内のオブジェクトを分析して達成可能な圧縮率を

検出し、最適な圧縮設定を行うための推奨事項を提示します。

障害診断

Oracle Database 11gには、問題の防止、検出、診断、解決を行うための高度な障害診断インフラスト

ラクチャが含まれています。特に診断の対象となるのは、データベースの正常稼働に支障をきたす

可能性のある重大なエラーです。重大なエラーが発生すると、インシデント番号が割り当てられ、

エラーの診断データ（トレース、ダンプなど）が即座に取得されます。取得された診断データは、

インシデント番号でタグ付けされます。この診断データはAutomatic Diagnostic Repository（ADR）

（データベース外のファイル・ベースのリポジトリ）に格納されます。リポジトリ内のデータは、後

でインシデント番号により検索し、分析できます。Oracle Database 11gで大幅に改善された障害診断

インフラストラクチャの目的は、次の利点を実現することです。


24

ヘルス・チェックを使用してDBAに警告し、小さな問題に事前に対処することで、壊滅的なシス

テム障害を防止します。

データ・リカバリおよびSQL Repair Advisorを使用して、問題発生後の破壊、修復、中断を抑制し

ます。

ADRおよびテスト・ケース・ビルダーを使用して、問題の診断に必要な時間を削減します。

Incident Packaging Service（IPS）およびOracle Configuration Support Managerを使用して、ユーザー

とOracleサポートとのやり取りを簡素化します。

障害診断インフラストラクチャの主要なコンポーネントとしては、以下のものがあります。

自動ヘルス・チェック

Oracle Database 11gでは、システムの予測的なチェックを実行する目的で、ヘルス・チェッカ・フレー

ムワークが追加されました。重大なエラーが検出されると、障害診断インフラストラクチャはヘル

ス・チェックを1回以上実行して、エラーの詳細な分析を実行します。ヘルス・チェックの結果はレ

ポートに格納されます。このレポートは、テキスト・ファイルまたは書式設定されたHTMLとしてブ

ラウザで表示できます。レポートは、対象となっているエラーのために収集された他の診断データ

に追加できます。個々のヘルス・チェックでは、データの破損、取消しと再実行による破損、デー

タ・ディクショナリの破損などが検索されます。

SQLテスト・ケース・ビルダー

多くのアプリケーション・エラーでは、エラーが再現されるテスト・ケースを取得することが、問

題の早期解決への重要な要素となります。SQLテスト・ケース・ビルダーを使用すると、SQLテキス

ト、PL/SQL、DDL、実行環境情報など、エラーを再現するために必要なすべての情報を自動的に収

集できます。こうして収集された情報をOracle Supportに送信することで、エラーを再現できます。

自動診断リポジトリ

ADRは、トレース、ダンプ、警告ログ、ヘルス・モニター・レポートといったデータベース診断デー

タ用のファイル・ベースのリポジトリです。このリポジトリは、Oracleデータベースの複数のインス

タンスとコンポーネントにまたがる統一されたディレクトリ構造を持ち、旧リリースで使用されて

いたUSER_DUMP_DEST、BACKGROUND_DUMP_DEST、CORE_DUMP_DESTを置き換えるもので

す。ADR内の診断データは自己管理型であり、事前定義のデータ保持設定に基づいて自動的に削除

されます。また、ADRはデータベースで発生したすべての重大なエラーのメタデータも管理してい

るため、管理者は、ADRに対して問合せを発行し、過去数日、数ヶ月、あるいは数年の間にシステ

ムで発生した重大なエラーの種類と数を確認できます。

Incident Packaging Service

Incident Packaging Serviceは、1つ以上のエラーに関連するすべての必要な診断データを収集するプロ

セスを自動化します。IPSを使用すれば、従来のように、Oracle Supportによるエラー診断に必要なす

べての関連トレース・ファイルとダンプ・ファイルを収集するために、ディレクトリ内のさまざま

な場所を検索する必要がなくなります。IPSを起動すると、特定の重大なエラーに関するすべての診

断データ（トレース、ダンプ、ヘルス・チェック・レポート、SQLテスト・ケースなど）が自動的に

zipファイルにパッケージ化されます。このzipファイルをOracleサポートに送信して診断を受けるこ

とができます。


25

サポート・ワークベンチ

サポート・ワークベンチは、Oracle Database 11gの新しい障害診断インフラストラクチャを操作する

ためのOracle Enterprise Managerの機能の1つです。サポート・ワークベンチでは、問題の調査、レポー

ト、修復（必要な場合）を使いやすいグラフィカル・インタフェースで実行できます。サポート・

ワークベンチは、IPSを使用した診断データのパッケージ化、サポート要求番号の取得、IPSパッケー

ジのOracle Supportへのアップロードを、最小限の操作で、極めて短時間に実行可能にするセルフサー

ビス型のツールです。これにより、エラー解決の所要時間が短縮されます。

図7. サポート・ワークベンチのワークフロー

サポート・ワークベンチのワークフローは、以下の手順で構成されています。

1. 最初の障害の発生に基づいて、データベース内に自動的にインシデントを作成します。

2. DBAにエラーを通知し、障害が報告された領域でヘルス・チェックを実行します。

3. 発生したエラーが既知の問題であれば、問題の解決に必要なパッチを推奨および適用します。

4. そうでない場合は、インシデントと関連構成情報をパッケージ化し、Oracle Supportにアップ

ロードします。また、修復アドバイザを実行して障害からのリカバリを試みます。

Oracleデータベースではさまざまな問題が発生する可能性があり、問題によって正しい対処方法も異

なります。サポート・ワークベンチは、発生した問題に対して管理者が適切なアクションを実行で

きるように導く拡張ワークフローを提供します。


26

Exadataの管理とクラウドの統合

Oracle Exadataインフラストラクチャ上に異種データベースを統合しようとする企業が増える中で、

Oracle Enterprise Manager Cloud Control 12cは総体的な管理手法を使用することで、Exadata Database

Machineの管理者を支援します。また、エンジニアド・システム全体の監視から管理、継続的な保守

までの包括的なライフサイクル管理機能を提供します。

統合システム監視

Oracle Enterprise Managerが提供する包括的な監視および通知機能を利用すると、管理者はOracle

Exadata Database Machineとそのソフトウェアおよびハードウェア・コンポーネントに付随する問題を

事前に検出し、対応できるようになります。管理者は、それぞれのデータセンター環境の要件に合

わせて、容易にこれらの監視設定を調整できます。アラートが通知されると、管理者は、InfiniBand

ポートのネットワーク・パフォーマンスやExadataストレージ・セルのディスク・アクティビティな

どの、問題のコンポーネントに関連するパフォーマンス・メトリックとアラートの履歴を簡単に表

示し、問題の根本原因を特定できます。Oracle Enterprise ManagerはExadataのハードウェア・コンポー

ネントに直接接続されているため、ハードウェア関連の障害を管理者に警告した上で、Oracle

Automatic Service Requests（ASR）との統合を介して自動的にサービス・リクエストを登録し、Oracle

Supportによるすみやかなレビューを求めることができます。

従来のシステムでは、データベース管理者、システム管理者、ストレージ管理者が協力して検出す

る必要のあった問題が、Exadata Database Machine全体に対応した統合システム監視機能によって、数

分で診断されるようになりました。

一元管理

Oracle Enterprise ManagerはOracle Exadataのハードウェアとソフトウェアに対する統合ビューを提供

します。このビューを利用すると、コンピュート・ノード、InfiniBandスイッチ、Exadataストレージ・

セル、Oracleデータベース、Oracle ASMをはじめとする、あらゆるコンポーネントの状態とパフォー

マンスを確認できます。

図8：Oracle Enterprise Manager Cloud Control 12cを使用したExadataの監視


27

Oracleデータベースは、何の変更を加えなくてもOracle Exadata Database Machine上で透過的に実行で

きます。しかし、パフォーマンス・ボトルネックやハードウェア障害を特定および診断するために、

DBAがデータベースからストレージ・システムにドリルダウンする必要がある場合もあります。

Enterprise Managerが提供するExadataのハードウェアおよびソフトウェアの統合ビューを利用すると、

問題の原因がハードウェア・コンポーネントにあっても、同じストレージ・サブシステム上で稼働

している別のデータベースにあっても、DBAはデータベース・パフォーマンスのページから関連す

るExadataストレージ・サーバーにシームレスにナビゲートし、問題を分離できます。SQL実行のパ

フォーマンスをリアルタイムで分析するSQL監視機能はExadata認識型であるため、Exadataストレー

ジ・サーバーにオフロードされている実行計画の計画操作を特定できます。その結果として、DBA

はSQL文の効率を把握できます。

Enterprise ManagerのExadata管理機能は、管理されている特定のコンポーネントの状態およびパ

フォーマンス特性に準じて提供されます。たとえば、Enterprise Managerでポートのパフォーマンス低

下が検出された場合、管理者はInfiniBandネットワークのパフォーマンスを監視できるだけでなく、

ポート設定を変更することもできます。特定のデータベースが過剰なI/Oリソースを消費することで、

同じストレージ・セルのセット上にあるその他のデータベースのパフォーマンスに影響が出ている

場合、管理者はEnterprise Manager内で、Exadataストレージ・セルのI/Oリソース・マネージャの計画

を設定し、有効化できます。

統合計画

Oracle Exadataインフラストラクチャ上に異種データベースを統合しようとする企業が増えている中

で、Oracle Enterprise ManagerのConsolidation Plannerを使用すると、さまざまなExadata構成に対する

最適な統合戦略を決定できます。実際のハードウェア構成とEnterprise Managerに保管されているサー

バーのワークロード履歴を使用することで、Consolidation Plannerはソース・システムのワークロー

ドを分析し、ターゲットExadataシステムでの統合計画に対して期待される使用率を算出します。豊

富なハードウェア構成ライブラリを備えたConsolidation Plannerは、各種バージョンのX2-2からX2-8

までにおよぶ仮のExadataサーバーに対して、管理者が統合シナリオを定義できるようにガイドしま

す。Consolidation Plannerを使用すると、企業のデータベース統合要件に適したExadataの厳密な構成

を、より賢明かつ最適に決定できます。

Database as a Service

Oracle Cloud Management for Oracle Databaseは、データベース・クラウドのライフサイクル全体に渡

る機能を提供します。この機能を利用すると、クラウド管理者はプールされたリソースを特定し、

ロールベースのアクセスを構成し、サービス・カタログや関連するチャージバック計画を定義でき

ます。また、クラウド・ユーザーはデータベース・サービスをリクエストしてオンデマンドで消費

できます。さらに、ユーザーはプラットフォームをスケールアップまたはスケールダウンして、ア

プリケーション・トラフィックの変化に対応できます。最後に、提供されるサービスのコストを両

者が理解し、リソース消費に対するアカウンタビリティが確立されるようになります。

Oracle Enterprise Managerにはすぐに使えるセルフサービス型ポータルが含まれており、開発者、テス

ト担当者、DBA、およびその他のセルフサービス・ユーザーはこのポータルにログオンして、新し

い単一のインスタンスやOracle RACデータベースをリクエストしたり、開始または停止、ステータ

スと状態の監視などのライフサイクル操作を実行したりすることができます。また、データベース

を含む仮想アセンブリをOracle VMの仮想化サーバー・インフラストラクチャに配置できます。


28

ポータルからアクセスできるサービス・カタログには、標準化されたデータベース構成とバージョ

ンに対するさまざまな公開サービス・テンプレートの一覧があります。ユーザーは過去および未処

理のリクエストや、リソース割当て、現在の使用率だけでなく、所有するデータベースのチャージ

バック情報も確認できます。

計測とチャージバック

クラウド提供の重要な側面に、クラウド・リソースの消費に対して使用コストを確立し、チャージ

バック・レポートを提供するために実際の使用量を計測する機能があります。Enterprise Managerは、

リソース・タイプごとに収集された各種メトリックにおよぶ詳細なチャージバック計画を定義した

り、複数の開発者間でコストをグループ化するコスト・センターを定義したりするためのツールを

提供します。チャージバック計画では、使用量に基づくコストだけでなく、構成（プラットフォー

ムのバージョンなど）に基づくコストや固定コスト（定額管理費）を使用できます。

図9. データベースのチャージバック

データベース管理者にとっての利点

今日の急速に進化するIT環境では、変化と統合が絶え間なく続いていますが、データセンターのマ

ネージャーや管理者がそれを困難だと考える必要はありません。Oracle Enterprise Manager Cloud

Control 12cを使用して管理されるOracle Database 11gの管理性機能のおかげで、データベース管理者

は、システムのパフォーマンスと可用性を維持しながら、テストと統合を通じて、ユーザーにより

品質の高いサービスを提供できます。

結論

現代の企業は、競争力と収益性を強化するために、新しいテクノロジー・ソリューションを積極的

に導入しており、その結果、管理に関する課題は増加し続けています。Oracle Database 11gでは、こ

れらの重要な課題に対処するために、日常的な管理タスクが自動化されました。これによって、デー

タベース管理者がデータベースのパフォーマンスを最大レベルで維持すること、新しいテクノロ

ジーをリスクなしですばやく導入すること、およびDBAの生産性とシステムの可用性を向上させる

ことが可能になりました。Oracle Enterprise Manager Cloud Control 12cを使用して管理されるOracle

Database 11gは、次世代のDBAのために、次世代のデータベース管理を提供します。

Oracle Database 11g Release 2

データベースの管理性の概要

2011年9月

著者：Kurt Engeleiter

共著者：Jagan Athreya、

Mughees Minhas、

Debaditya Chatterjee

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載

される内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による

明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保

証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的

または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかな

る目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel Xeon

はIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,

Inc.の商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010

Oracle Database 11g Release 2データベースの管理性の概要 ·...

Documents

Transcript of Oracle Database 11g Release 2データベースの管理性の概要 ·...