| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
ここでは、このマニュアルに記載されているOracle Database 11g リリース2の新機能について説明し、追加情報の参照先を示します。
この項の内容は次のとおりです。
CloneDBを使用したデータベースのcopy-on-writeクローニング
CloneDBを使用してデータベースをクローニングする場合、Oracle Databaseはcopy-on-writeテクノロジに基づいてCloneDBデータベースにファイルを作成できるため、ディスク上に追加の記憶域が必要となるのは、CloneDBデータベースで変更されたブロックに対してのみとなります。
「CloneDBを使用したデータベースのクローニング」を参照してください。
ハイブリッド列圧縮
ハイブリッド列圧縮により、ダイレクト・パス・ロードが行われるデータに高度な圧縮レベルが提供されます。この新しい圧縮機能は、更新頻度の低いデータに推奨されます。ハイブリッド列圧縮は、パーティション、表および表領域のレベルで指定できます。また、希望の圧縮レベルを指定して、ディスク使用量とCPUオーバーヘッドの間のトレードオフ関係を適切に調整することもできます。アプリケーションに対する適切な圧縮レベルを決定するために圧縮アドバイザを使用できます。
「表圧縮の使用」を参照してください。
パーティション・オブジェクトのセグメント作成の遅延
セグメント作成の遅延が、パーティション・オブジェクトだけでなく、非パーティション・オブジェクトにも適用されるようになりました。
「セグメント作成の遅延の理解」を参照してください。
DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTSプロシージャを使用して、以前のリリースから移行した空の表からセグメントを削除できます。
「未使用オブジェクト記憶域の削除」を参照してください。
TRUNCATE文のDROP ALL STORAGE句を使用して、表のセグメントの割当てを解除できます。
「TRUNCATEの使用」を参照してください。
DBMS_SPACE_ADMIN.MATERIALIZE_DEFERRED_SEGMENTSプロシージャを使用して、セグメント作成が遅延された表、パーティション、および依存オブジェクトのセグメントをマテリアライズできます。
「セグメントのマテリアライズ」を参照してください。
パーティション表の第1エクステント・サイズに新たに導入されたデフォルトにより、パフォーマンスが向上します。
パーティション表のすべての新規セグメントについて、第1エクステントのデフォルトのサイズが64KBではなく8MBになりました。このことは、パーティション表に対する挿入と問合せのパフォーマンス向上に役立ちます。パーティション表の初期サイズが大きくても、十分なデータが挿入されると、領域消費は以前のリリースと同じになります。このデフォルトは、表の記憶域句にINITIALサイズを設定して上書きできます。この新しいデフォルトは、表パーティションおよびLOBパーティションにのみ適用されます。
NOLOGGINGダイレクト・パス・インサートのパフォーマンスを向上させるために新たに導入された初期化パラメータ
制御ファイルの定期更新を無効にして、リカバリ不能なダイレクト・パス・インサートのパフォーマンスを大幅に向上させることができるようになりました。このことを行うには、新たに導入されたDB_UNRECOVERABLE_SCN_TRACKING初期化パラメータをFALSEに設定します。ただし、これらの制御ファイルの更新を無効化してリカバリ不能なダイレクト・パス・インサートを実行すると、データファイルが現在リカバリ不能かどうかをデータベースに問い合せて正確に判断できなくなります。
「ロギングなしダイレクト・パスINSERT」を参照してください。
Oracle Schedulerで改善された電子メール通知機能
Oracle Scheduler電子メール通知のプリファレンスに、指定のSMTPサーバーに対する認証およびSSLプロトコルまたはTLSプロトコルを指定するオプションが追加されました。
「スケジューラのプリファレンスの設定」を参照してください。
データベース・サービスのエディション属性
データベース・サービスの作成時にそのエディション属性を設定したり、既存のデータベース・サービスのエディション属性を変更できます。
「データベース・サービスのエディション属性の設定」を参照してください。
Oracle Database Resource Managerの拡張
コンシューマ・グループごとにパラレル・ステートメント・アクティビティを制限し、パラレル・ステートメント・キュー内のパラレル・ステートメントの優先度を設定し、パラレル・ステートメント・キューでのパラレル・ステートメントの待機時間を制限して、パラレル・ステートメントのパフォーマンスを最適化できます。
パラレル・ステートメント・キューイングを使用すると、指定した並列度で文を実行するのに十分なリソースがデータベースにないときも、パラレル・ステートメントを効率的に管理できます。パラレル・ステートメントを発行したとき、そのパラレル・ステートメントの実行に必要なリソースがパラレル・ステートメントの割当て先のデータベースまたはコンシューマ・グループに指定されたパラレル・ステートメント・アクティビティの制限を超えている場合、パラレル・ステートメントはパラレル・ステートメント・キューに追加されます。パラレル・ステートメント・キューイングでは、リソース・プランで指定された優先度およびリソース割当てに従って、複数のパラレル・ステートメント・ワークロードも管理できます。
各リソース・プランに対する毎分ごとのメトリックを使用してCPU使用を追跡できます。また、リソース・マネージャが使用可能になっていない場合でも、コンシューマ・グループのリソース使用率を監視できるため、リソース・マネージャの潜在的影響を確認できます。
「V$RSRCMGRMETRIC」を参照してください。
Oracle Restartは、障害発生後にデータベースを自動的に再起動することで、データベースの可用性を向上させます。
Oracle Restartを構成すると、ハードウェアまたはソフトウェア障害の後、またはデータベース・ホスト・コンピュータの再起動後に、データベース、リスナー、Oracle Automatic Storage Managementインスタンスおよびその他のOracleコンポーネントが自動的に再起動されるようにできます。
第4章「Oracle Databaseの自動再起動の構成」を参照してください。
エディションに基づく再定義により、アプリケーション開発者およびDBAは、アプリケーションの停止時間をごくわずかまたはゼロに抑えてアプリケーションをアップグレードできます。
エディションと呼ばれる新しいデータベース構造は、新しいコードのインストールやデータの変更が実行中の本番アプリケーションから認識されないようにするためのプライバシ・メカニズムを提供します。必要なすべての変更をプライベートで実行した後、変更内容をユーザーに対して使用可能にすることができます。エディションに基づく再定義をサポートするために、エディショニング・ビューと呼ばれる新しいタイプのビューと、crosseditionトリガーと呼ばれる新しいタイプのトリガーが導入されています。
「エディションの管理」を参照してください。
データベース・スマート・フラッシュ・キャッシュ
データベース・スマート・フラッシュ・キャッシュはオプションのメモリー・コンポーネントで、データベースがSolarisまたはOracle Linux上で稼働している場合に追加できます。これはSGA常駐バッファ・キャッシュで、データベース・ブロックに対するレベル2のキャッシュを提供します。これにより、応答時間と全体的なスループットを向上できます。
「メモリー・アーキテクチャの概要」を参照してください。
自動セグメント・アドバイザによって、OLTP圧縮を表に使用することを指示する推奨事項が戻されるようになりました。
「使用できない領域の再生」を参照してください。
セグメント作成の遅延
ローカルで管理されている表領域に非パーティションのヒープ構成表を作成する場合、表セグメントの作成が最初の行の挿入時まで遅延されます。
「セグメント作成の遅延の理解」を参照してください。
Oracle Databaseファイル・システム
Oracle Databaseファイル・システムでは、データベース表に格納されているファイルおよびディレクトリの最上部に、標準のファイル・システム・インタフェースを作成します。
詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
Oracle Schedulerの拡張機能
リモート・データベース・ジョブ: 同じホスト上またはリモート・ホスト上の別のデータベース・インスタンスで、ストアド・プロシージャやPL/SQL無名ブロックを実行するジョブを作成できるようになりました。ターゲット・データベースとして、任意のOracle Databaseリリースを使用できます。
「データベース・ジョブ」を参照してください。
複数の宛先のジョブ: ジョブを複数の場所で実行し、そのジョブのすべてのインスタンスを単一の中核データベースから制御および監視できるようになりました。これは、ジョブの作成時に複数の宛先を指定することによって実行できます。宛先には、ローカル・ホスト、ローカル・データベース、リモート・ホスト(リモート外部ジョブの場合)またはリモート・データベース(リモート・データベース・ジョブの場合)を指定できます。
「複数の宛先のジョブ」を参照してください。
File Watcher: File Watcherと呼ばれる新しいスケジューラ・オブジェクトを使用すると、ローカル・システムまたはリモート・システムにファイルが到着したときにジョブが開始されるようにする場合に、スケジューラを簡単に構成できます。
「ファイルがシステムに到着したことによるジョブの開始」を参照してください。
電子メール通知: ジョブの特定の状態イベント発生時に1人以上の受信者に自動的に電子メールを送信するようにスケジューラを構成できます。これにより、ジョブが完了したときに、失敗または無効であるかどうか、割り当てられた実行時間を超過しているかどうかなどが電子メールで受信できるようになります。
「電子メール通知によるジョブ状態の監視」を参照してください。
データベース・リソース・マネージャの拡張機能
インスタンス・ケージング
Oracle Databaseでは、複数のデータベース・インスタンスを実行するマルチCPUサーバー上でCPU割当てを管理する方法が提供されるようになりました。インスタンス・ケージングによって、1つのデータベース・インスタンスが使用できる最大CPU数が制限されます。1つのインスタンスがCPUにバインドされると、リソース・マネージャは、現在のリソース・プランに基づいてCPU割当てを開始します。このように、インスタンス・ケージングとリソース・マネージャは連携して機能し、複数のインスタンスで目的とするサービス・レベルを実現できるようにサポートします。
「単一サーバーにおける複数のデータベース・インスタンスの管理」を参照してください。
リソース・プラン・ディレクティブの新しいMAX_UTILIZATION_LIMIT属性を使用すると、CPU使用の絶対上限をリソース・コンシューマ・グループに設定できます。この絶対上限は、プランでのあらゆるCPU自動再配分に優先します。
新しいORACLE_FUNCTIONコンシューマ・グループ・マッピング・ルール・タイプ、およびデータ・ポンプとRMAN用の事前定義された新しいマッピング・ルール。
データ・ポンプによってデータのロードを実行するセッション、またはRMANによってバックアップ操作やコピー操作を実行するセッションは、事前定義されたコンシューマ・グループに自動的にマッピングされるようになりました。
「事前定義のコンシューマ・グループ・マッピング・ルール」を参照してください。
Oracle Exadataによるデータ・ウェアハウス操作をサポートするための、新しいサンプル・リソース・プランおよびリソース・コンシューマ・グループ
「事前定義のリソース・プランおよびコンシューマ・グループ」を参照してください。
ダイレクト・ロード操作用のみ、またはすべての(OLTP)操作用の表圧縮を指定するための新規SQLコマンド構文。
「表圧縮の使用」を参照してください。
ユーザー指定のプリプロセッサ・プログラムで外部表を前処理できます。
前処理プログラムを使用すると、アクセス・ドライバでサポートされていない形式のファイルに格納されているデータを利用できます。たとえば、圧縮形式で格納されているデータにアクセスできます。ORACLE_LOADERアクセス・ドライバに対して解凍プログラムを指定すると、アクセス・ドライバでデータが処理される際にデータを解凍できます。
「外部表の前処理」を参照してください。
アーカイブ・ログで最大30個のスタンバイ・データベースがサポートされます。
IPバージョン6がサポートされています。
Oracle Databaseのコンポーネントおよびユーティリティで、長さ128ビットのインターネット・プロトコル・バージョン6(IPv6)のアドレスがサポートされています。SQL*Plusで簡易接続方法を使用してIPv6アドレスを指定できます。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
パフォーマンスを低下させることなく、セクター・サイズが4KBのディスク・ドライブにREDOログを格納できます。
REDOログ・ファイルで新しい4KBのブロック・サイズを使用すると、オンラインREDOログをセクター・サイズが4KBの新しい大容量ディスクに格納でき、パフォーマンス低下も発生しません。新しいブロック・サイズにより、ログ・ファイルの書込みがセクターの位置に確実に揃えられます。
「REDOログ・ファイルのブロック・サイズの計画」を参照してください。
障害診断インフラストラクチャのコンポーネントであるEnterprise Managerサポート・ワークベンチで、Oracle Automatic Storage Managementインスタンスでのクリティカル・エラーの調査、レポートおよび解決がサポートされます。
第9章「診断データの管理」を参照してください。
