Oracle Database 11g: デフォルト動作の変更

機能

説明

• AL32UTF8およびAL16UTF16キャラクタ・セットのNLSデータファイルがバージョン5.0のUnicode標準キャラクタ・データベースに合せて更新されました。この機能強化の結果、Oracle Databaseは最新バージョンのUnicode標準に準拠しています。

• OracleJVMはSun社のJDK 1.5をサポートしています。この機能により、J2SEアプリケーション（スタンドアロンJDBCまたは中間層）のOracle Databaseへの移植、およびJ2SE 5.0の主な利点（Javaアノテーションにより可能になる宣言型プログラミング・スタイルなど）の活用が可能になります。

• JITはデフォルトで（特別な設定なしで）有効になるため、それ以上の構成作業は必要ありません。

• この機能を使用すると、LinuxとWindows間でデータベースを容易に移動できます。そのため、LinuxとWindows間で移動可能なデータベースが実現し、クロス・プラットフォーム型のフィジカル・スタンバイが可能になります。

• インスタンス・リカバリ中に破損ブロックが検出された場合、DBA_CORRUPTION_LISTにデータが自動的に移入されます。ブロックの検証は、バックアップ、メディア・リカバリ、インスタンス・リカバリのすべてのレベルで実行されます。

• Oracle Database 11gでは、併用するとOracle Databaseアプリケーションのパッチやアップグレードを作成および適用するときの停止時間をOracle Database 10gと比べて大幅に短縮できる機能がいくつか導入されています。

• WAITオプション付きのDDLが新たにデフォルトになりました。待機時間はインスタンス全体で（初期化パラメータ・ファイルで）指定し、セッション・レベルで変更可能です。WAITオプション付きでDDLコマンドを指定することで、すぐにエラーを生成するかわりに、コマンドが成功するまでの猶予期間を柔軟に定義できます。

• ADD COLUMN機能により、NOT NULL制約を指定したデフォルト値の列を新たに追加する場合は、すべての既存のレコードにデフォルト値を格納する必要がなくなりました。そのため、既存のデータ量にかかわらず1秒未満でスキーマの変更が行えるだけでなく、領域が消費されることもありません。

• これまでのリリースでは、オブジェクト間の相互依存性はオブジェクト全体の粒度でメタデータに記録されました。これは、論理的な必要性がないにもかかわらず、依存オブジェクトが無効化される場合があったことを意味します。Oracle Database 11gでは、依存性メタデータはより細かな粒度で記録されます。依存するオブジェクトの変更に伴って依存オブジェクトが無効化されるケースが減少するため、アプリケーションの可用性が向上します。

• 不可視の索引は、索引の使用不能化または削除の代わりとなる機能です。不可視の索引により、アプリケーション全体に影響を与えることなく、アプリケーションの特定の処理またはモジュールで一時的な索引構造を利用できます。不可視の索引を使用すると、索引をただちに削除せずに、索引の削除をテストすることができます。したがって、本番環境で猶予期間を設定してテストを行うことが可能になります。

• このリリースのOracle Databaseでは、マテリアライズド・ビュー・ログをセッションレベルで制御できるようになりました。他のセッションで加えられた変更のロギングを継続したまま、マテリアライズド・ビューの変更（マテリアライズド・ビュー・ログ）の取得を個々のセッションごとに無効にできます。この機能により、アプリケーション・アップグレード時の停止時間が短縮されます。

• これまでのリリースでは、表にログまたはマテリアライズド・ビューが定義されている場合、その表は再定義できませんでした。しかし、このリリースでは、マテリアライズド・ビュー・ログをトリガーや索引、その他の同様の依存オブジェクトのように一時的にクローニングすることができます。再定義が終わると、ROWIDログは無効化されます。最初に、すべての依存マテリアライズド・ビューで完全リフレッシュを実行する必要があります。

• オンライン表再定義後の依存PL/SQLの再コンパイル最小化機能は、オンライン表再定義の後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。この機能により、オンライン表再定義の後に依存PL/SQLを手動で再コンパイルする時間と労力が削減されます。論理的に再定義の影響を受けないビュー、シノニム、および表に依存するその他のオブジェクト（トリガーを除く）も対象となります。

• オンライン索引作成および再構築の強化により、オンライン索引を作成または再構築するときの排他ロックが不要になるため、これらの処理は完全に透過的に行われます。

• Oracle Database 11gでは、新しいALTER TABLE構文が導入されました。ファイルをその所有者に対しても読取り専用にするというオペレーティング・システムでの処理が先例となっています。これまで、表を読取り専用にできたのは、表の所有者以外のユーザーに対してでした。

• 仮想列は式の評価によって定義し、評価の結果は表の列のメタデータになります。仮想列は、表の作成時または変更時に定義できます。

• 仮想列を使用すると、アプリケーション開発者は領域を消費することなく計算や変換を表の列（メタデータ）定義として定義できます。これにより、アプリケーション開発におけるエラー発生率が低下するのに加えて、仮想列に関する追加の統計がオプティマイザに提供されるため、問合せ最適化の精度が高まります。

• バイナリXML（XMLドキュメントの構造を表現する方法の1つ）は、データベースでXMLを保持するための3番目の格納モデルとなります。バイナリXMLは、既存のオブジェクト格納モデルとテキスト格納モデルに取って代わるのではなく、既存のモデルを補完します。

• バイナリXMLを使用すると、XMLスキーマが使用可能かどうかに関係なくXML操作が大幅に最適化され、XMLがディスク内、メモリー内、ネットワーク上のいずれにあろうとXMLの内部表現を同一にすることができます。

• この機能を使用すると、索引付けされるXMLの形態やコンテンツがあらかじめ明確に分からなくても、XMLドキュメントに効率的に索引付けすることができます。索引付けされたXMLコンテンツに対する非常に効率的なXPathベースの検索が完全にサポートされます。

• 自動診断リポジトリ（ADR）は、トレース・ファイルおよびその他のエラー診断データの格納と編成を目的とした新しいシステム管理リポジトリです。ADRは、データベースで発生したすべての重大なエラーの包括的なビューを提供し、問題の診断および解決に必要なすべての関連データを保持します。

• ADRは、すべてのデータベース診断情報を格納、書式化、検索するための均一で一貫したメカニズムを提供します。重大なエラーのインシデントを自動的に生成し、インシデント管理機能を提供することで、顧客の問題解決に要する時間を大幅に短縮します。

• 自動状態監視とは、データベースの状態を先回りしてチェックし、データベースに影響を与えている問題を識別する機能です。自動状態監視により、DBAはデータベースの現在の状態を包括的に把握し、データベースに影響を与えている問題の修正方法についてのヒントを得ることができます。

• 自動状態監視では、コンポーネントや状況に応じて、影響を受けているコンポーネントやリソースが隔離されるか、問題の解決方法が提示されます。この機能は、停止時間を最小限に抑え、停止に備えた計画を前もって立てておくのに役立ちます。

• ローリング・アップグレード機能を使用すると、データベースの可用性に影響を与えることなく、ASMクラスタの個々のノードの移行またはパッチ適用を実行できます。ローリング・アップグレードにより、稼働時間が延長され、新規リリースへの正常な移行が可能になります。

• この機能は、新しいSYSASM権限を導入することで、データベース管理と記憶域管理の役割の分離を可能にします。SYSASM権限を使用すると、管理者は複数のデータベースで共有可能なディスク・グループを管理できます。SYSASM権限により、SYSDBA権限からの職務の明確な分離が実現します。

• この機能は、すべてのノードでASMを明示的に構成することで、非クラスタASMデータベースをクラスタASMデータベースに変換する作業をEnterprise Manager内で行えるようにします。また、単一インスタンスからOracle RACへの変換ユーティリティがスタンバイ・データベースをサポートするように拡張されています。

• 変換の簡素化により、顧客はデータベースを容易に移行して、スケーラビリティや高可用性などのOracle RACの利点を活用することができます。

• データベース・リプレイでは、本番システムで実際のデータベース・ワークロードを取得し、それをテスト・システムで再現することにより、現実に即したテストを実行できます。また、潜在的な問題（発生したエラーやパフォーマンスの相違など）に注目して問題の解決方法を推奨する、分析およびレポートの機能も用意されています。

• SQLリプレイでは、変更の前後の応答時間を比較対照することにより、変更がSQL文のパフォーマンスに与える影響を容易に評価できます。本番データベースなどのソース・システムからSQLワークロードを取得し、変更が適用されたテスト・システムでそのワークロードを再現することが可能です。

• この機能により、ソースと宛先のステージ領域が不要になります。また、一般的なRMANバックアップ・セットからのクローニングがサポートされ、Enterprise Managerのデータベース・クローニング・ページにおけるジョブ・サマリー・ユーザー・インタフェースが強化されます。

• 適応メトリックしきい値機能により、データベース・パフォーマンス・メトリックのアラートしきい値の選択が簡素化および改善されます。この機能を使用すると、DBAはベースライン方式の高品質なパフォーマンス・アラートしきい値を最小限の労力で構成できます。

• メトリック統計のソースとなる、AWRベースラインとの完全な統合

• クイック構成オプションにより、OLTPシステム・プロファイルまたはデータ・ウェアハウス・システム・プロファイルに基づいた初期しきい値セットを1クリックで使用可能

• SYSTEM変動ウィンドウ・ベースラインに対する時間グループ選択の自動化

• 既知の問題への応答レベルに基づき、候補となるアラート・メトリックをガイドに従って検出

• メトリックのグラフ化および分析の改善

• Oracle Database 11gでは、自動タスクにより、数百から数千のジョブを管理性ウィンドウで実行できます。自動タスクは、この管理性ジョブの高負荷を自動的に管理するのに必要なスケジューラ・インフラストラクチャとなります。

• この機能を使用すると、自動オプティマイザ統計収集や自動セグメント・アドバイザなどの各種データベース・メンテナンス・タスク間でのリソース分散（CPUおよびI/O）を複雑な設定なしで管理できます。CPUは自動的に管理されます。I/Oは、I/Oリソース・マネージャが有効になっている場合にのみ管理されます。

• 自動ワークロード・リポジトリ（AWR）・ベースラインを使用すると、将来のある時点で比較を行う対象期間として特定の期間をマークできるため、正確なパフォーマンス比較が可能になります。

• この強力な機能により、動的ベースラインおよび将来のベースラインを定義でき、比較に使用されるパフォーマンス・データの作成および管理のプロセスが簡素化されます。

• DBMS_JOBユーザーは、ジョブをOracle Schedulerに移行できます。その場合、DBMS_JOBジョブはOracle Schedulerジョブとなり、Oracle Schedulerのすべての機能が利用可能になります。 DBMS_JOBユーザーはOracle Schedulerの機能を利用できます。

• このリリースでは、SPFILEのフォルト・トレランスの強化、SPFILEの損失からのリカバリの容易化、Enterprise Manager初期化パラメータ管理インタフェースの直感性の強化によるサーバー・パラメータ・ファイルおよび初期化パラメータ値の管理の容易化などの機能拡張が行われています。

• データベース・インストール・プロセスがORACLE_BASE環境変数をベースとするよう再設計されました。これまで、この変数の設定はオプションであり、必須の変数はORACLE_HOMEのみでした。この機能により、入力が必要なのはORACLE_BASEのみとなり、ORACLE_HOME設定はORACLE_BASEから導出されます。この変更の結果、Oracleソフトウェアのインストールの構成が合理化され、継続的な管理が容易になります。

• この機能は、Oracle Databaseのデフォルト・インストールをOptimal Flexible Architecture（OFA）の仕様により厳密に準拠させることで、管理性を高めています。

• 自動ストレージ管理の新機能により、ストレージ管理の自動化が拡張され、スケーラビリティが向上し、Oracleデータベース・ファイルの管理が簡素化されます。

• これまでのリリースでは、アドバンスト・レプリケーションはトリガーベースのレプリケーション方法でした。Oracle Database 11gのこの機能では、既存の機能がWebベースのEnterprise Manager Database Controlに切り替わっています。この機能は、11gのEnterprise Manager Database Controlからアドバンスト・レプリケーションを管理することで、既存のアドバンスト・レプリケーション・ユーザーをサポートします。

• ADDMが強化され、クラスタ全体のパフォーマンスに関する包括的な診断およびチューニング・アドバイスが提供されるようになりました。ADDMの特殊なモードではOracle RACデータベースが分析され、クラスタ全体に影響を与える問題と個々のインスタンスに影響を与える問題がレポートされます。

  この機能により、I/Oやインターコネクト・トラフィックなどのグローバル・リソースを診断できます。また、Oracle RACデータベースのチューニングが容易かつ正確に行えるようになります。

• Oracle Databaseは、高負荷のSQL文を自動的に検出し、適切なSQLプロファイルを作成することで、メンテナンス期間中にSQL文のチューニングを自動的に行うようになりました。さらに、索引などのアクセス構造を新たに作成するよう求める予防的なアドバイスを発行して、高負荷のSQL文のパフォーマンスを大幅に改善します。

• Streamsプロセスが無効になると、アラートが自動的に生成されます。主要なStreamsメトリックのユーザー定義しきい値に基づいてアラートが生成されることもあります。これらのアラートは、重要なStreamsコンポーネントに関する情報をStreams管理者に提供します。

• 自動メモリー管理インスタンスは、メモリー・サイズ（SGAおよびPGA）に合せて、システム・グローバル領域（SGA）と総プログラム・グローバル領域（PGA総計）の間で必要に応じてメモリーを再分散します。「メモリー・サイズ(SGAおよびPGA)」初期化パラメータは動的であるため、データベースを再起動せずにいつでも変更可能です。「自動メモリー管理」オプションを選択すると、データベース・インスタンスがSGAとPGAのサイズを自動的に管理します。

• これまで、PL/SQLによってキャッシュされるSQLカーソルの数はOPEN_CURSORSで決められていました。 11gでは、キャッシュされるカーソルの数はSESSION_CACHED_CURSORSによって決まります。詳細は、Oracle Database 10gリファレンスを参照してください。

• SHARED_POOL_SIZEを増やして共有プールのオーバーヘッドに必要な領域を含める必要があります。

• DB_BLOCK_SIZEのデフォルト値はオペレーティング・システム固有ですが、通常は8KB（以前のリリースでは通常は2KB）です。

• 自動UNDO管理（AUM) のデフォルト設定はデフォルトで有効になっています。UNDO表領域を個々の環境に適したサイズに設定するためのPL/SQLプロシージャが用意されています。新しいリリースにアップグレードするデータベースは、AUMにシームレスに移行できます。

• パーティション化されたオブジェクトの統計収集は強化された統計収集プロセスであり、パーティション化されたオブジェクトの統計収集のスピードと精度を大幅に高めます。

• 一時領域管理が簡素化されたことで、DBAは使用されている一時領域のサイズや使用しているユーザー、一時領域が不足しているかどうかなどを容易に特定できるようになり、一時領域管理から曖昧さが排除されました。この機能は、不適切な一時領域構成が原因で発生するエラーを削減し、ランナウェイ問合せなどのアプリケーション設計上の問題を識別するのに役立ちます。

• DBCAのインタビュー・フェーズでORACLE_BASEに指定したディレクトリは、Oracleホーム・インベントリにDIAGNOSTIC_DESTパラメータとして格納され、その後のディレクトリ作成で使用されます。（デフォルトは$ORACLE_BASEディレクトリです。）また、ADD INSTANCE操作では、ORACLE_BASEの値がすべてのノードで同一であると想定され、ORACLE_BASEの値がすべてのノードで検証されます。

• 診断のバックアップ先には、すべてのADRディレクトリ（アラート・ログなどの診断ファイル）が含まれます。診断をバックアップするディレクトリは、11gより前のOracleデータベースから11g以上のデータベースにアップグレードするときに必要となります。Oracleベース・ディレクトリがすでに存在する場合、Upgrade Assistantは自動的にこの情報を取得し、事前にパスを設定します。

• Oracle Database 11g以降では、バックグラウンド・ダンプ、ユーザー・ダンプ、コア・ダンプのバックアップ先の初期化パラメータ設定は、診断のバックアップ先に置き換えられます。

• 単一インスタンス・データベースの場合、Database Configuration Upgrade Assistant（DBUA）の構成ユーティリティを使用して、Oracle Database Express Edition（Oracle Database XE）からOracle Database 11gにアップグレードできます。DBUAは、データベースがXEデータベースであるかどうかを識別します

• XEデータベース・ファイルは、ORACLE_BASE/oradata/XEというパスにあります。ユーザーがアップグレード後にXEホームを削除する可能性があるため、XEデータベース・ファイルは新しい場所にコピーしてください。

• アップグレードの一環として、ASM、OFS、またはStorage Area Networks（SAN）やNetwork Area Storage（NAS）などのその他のストレージ・デバイスにデータファイルを移動できます。アップグレード中にデータベース・ファイルを移動する場合、ディスクをリバランスしてSAN、NAS、ASMなどの適切なストレージ・デバイスにファイルを移動することで、通常はこの表領域を停止できるという利点があります。

• メジャー・リリースとパッチ・セット・リリースのどちらも、データベースをアップグレードする前の元のバージョンに基づいてダウングレードできます。メジャー・リリースのダウングレードは、10.2と10.1に対してサポートされています。パッチ・セットのダウングレードについては、11.1より前のすべてのパッチ・リリースに対してサポートされています。
  Oracle Database Express Editionからアップグレードしたデータベースはダウングレードできませんので注意してください。
  ダウングレードできるのは、アップグレードする前のリリースに対してのみです。たとえば、10.1から11.1にアップグレードした場合、10.2へのダウングレードはできません。10.1へのダウングレードのみ可能です。

• Oracle10gリリース1（10.1）データベースのリリース番号が10.1.0.5より小さい場合は、ダウングレード前にリリース10.1の最新パッチをインストールする必要があります。同様に、Oracle 10gリリース2（10.2）データベースのリリース番号が10.2.0.3より小さい場合は、ダウングレード前に10.2の最新パッチ・リリースをインストールする必要があります。10.1または10.2のどのパッチ・リリースからもアップグレードできますが、ダウングレード後に使用するORACLE_HOMEに最新のパッチ・リリースをインストールする必要がありますので注意してください。

• データベースのメッセージ・ゲートウェイとWorkspace Managerは、リリース10.1.0.6およびリリース10.2.0.4より前のOracle Databaseパッチ・セットには含まれていません。したがって、ダウングレード前に、10.2.0.3または10.1.0.5のORACLE_HOMEにすべての関連パッチを個別に適用する必要があります。

• 最小およびデフォルトのログ・ファイル・サイズはより大きくなります。現在、最小は4MB、デフォルトは50MBです。ただし、Oracle Managed Files（OMF）を使用しているときは100MBです。

システム・ファイルを自動的に拡張するコマンドライン・オプション

• コマンドライン・オプションAUTOEXTENDを使用すると、アップグレードの一環としてデータファイルを自動的に拡張できます。このオプションは、アップグレード中にデータファイルの自動拡張を行い、アップグレード後に自動拡張を元の設定に戻します。このオプションは、ディスクに十分な領域があり、新しいデータファイルを追加したり、ファイルのサイズを手動で増やしたりする必要がない場合に便利です。