| Oracle® Database新機能ガイド 12cリリース1 (12.1) B71327-06 |
|
 前 |
 次 |
この章では、Oracle Database 12cリリース1 (12.1.0.2)で使用可能な機能について説明します。この章には次の項が含まれます:
高度な索引圧縮は、既存の接頭辞圧縮機能の候補としてふさわしくない索引も含み、サポートされているすべての索引に対して効果的に機能します。これには、索引の先頭列に重複値がない(またはほとんどない)索引も含まれます。
高度な索引圧縮により、索引に対する効率的なアクセスを提供しながら、圧縮率が大幅に高くなります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
最適化された新しいSQL関数APPROX_COUNT_DISTINCT()により、重複していない値の近似カウントが集約されます。大量のデータの処理速度が完全集約よりも大幅に上がりますが、これは特に、重複していない値が多数含まれるデータ・セットの場合に顕著であり、完全集約結果との偏差は無視できる程度です。
現在のデータ分析では、一般的な操作で重複していない値をカウントすることが求められます。処理時間およびリソース消費を桁違いに最適化すると同時にほとんど完全な結果を提供することにより、既存の処理速度を上げ、分析の洞察力を数段高めることができます。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
属性クラスタリングは、特定の列の内容に基づいて物理的に近い場所にあるデータをクラスタリングする表レベルのディレクティブです。このディレクティブは、一括挿入または移動操作などの任意の種類の直接パス操作に適用されます。
論理的な帰属先が同じであるデータを物理的に近い場所に格納することにより、処理対象のデータ量が大幅に削減され、圧縮率を上げることができます。
|
関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
以前のリリースでは、キャッシュ・メモリーをめぐって複数のスキャンの間で競合が発生している場合に、インメモリー・パラレル問合せが正しく機能しませんでした。この機能によって、大きな表のキャッシュと呼ばれる、表スキャン・ワークロードのための新しいキャッシュが実装されます。
この大きな表のキャッシュにより、バッファ・キャッシュに全体が収まらない表に対する全表スキャンのパフォーマンスが大幅に向上します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
このリリースでは、フラッシュバック・データ・アーカイブ(FDA)はマルチテナント・コンテナ・データベース(CDB)でサポートされます。
顧客は、Oracle Multitenantを使用して連結しているデータベースでフラッシュバック・データ・アーカイブを使用できるため、マルチテナント・コンテナ・データベースでプラガブル・データベース(PDB)を使用してアプリケーションに対する履歴追跡を簡単に行うことができます。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
全データベースのキャッシュを使用して、データベース全体をメモリーにキャッシュできます。これは、データベース・インスタンスのバッファ・キャッシュ・サイズがデータベース全体のサイズより大きい場合に使用する必要があります。Oracle RACシステムでは、適切にパーティション化されたアプリケーションにおいて、すべてのインスタンスのバッファ・キャッシュを結合したサイズに、インスタンス間の重複キャッシュ・ブロックを処理するための追加スペースを足した値が、データベースのサイズより大きい場合、この機能を使用できます。
データベース全体をキャッシュすると、パフォーマンスが大幅に向上しますが、これは特に、以前はI/Oスループットやレスポンス時間によって制限されていたワークロードに効果的です。より具体的に言うと、この機能により、すべての表のキャッシュが強制されるため、全表スキャンのパフォーマンスが向上します。デフォルトの動作では、全表スキャンのバッファ・キャッシュに大規模な表が保持されませんが、この点が変更されています。
|
関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
インメモリー集約により、ディメンション表をファクト表に結合し、CPUおよびメモリー効率のよいKEY VECTORおよびVECTOR GROUP BY集約操作を使用してデータを集約する問合せ(スター問合せなど)を最適化します。これらの操作は、SQLオプティマイザによってコスト見積りに基づいて自動的に選択される場合があります。
インメモリー集約により、スター問合せのパフォーマンスが向上し、CPU使用率が下がるため、より高速で一貫した問合せパフォーマンスが実現され、より多くの同時ユーザーがサポートされます。代替SQL実行計画と比較すると、パフォーマンスは著しく向上します。より多くのディメンションが含まれ、ファクト表からより多くの行が集約される問合せの方が、向上率が高くなります。インメモリー集約ではほとんどの場合、要約表が必要なくなるため、スター・スキーマのメンテナンスが簡略化され、リアルタイム・データへのアクセスが可能になります。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
インメモリー列ストアを使用すると、オブジェクト(表またはパーティション)を列フォーマットでメモリーに格納できます。列フォーマットを使用すると、分析スタイルの問合せ用の従来のディスク上フォーマットより、スキャン、結合および集約の実行速度を上げることができます。インメモリー列フォーマットは、ディスク上フォーマットまたはバッファ・キャッシュ・フォーマットを置き換えるわけではなく、トランザクションとの整合性がとれたオブジェクトの追加コピーです。列格納はデータベースにシームレスに統合されているため、アプリケーションの変更を行わずにこの機能を透過的に使用できます。DBAが実行する必要があるのは、インメモリー列ストアへのメモリーの割当てのみです。オプティマイザはインメモリー列ストアに対応しているため、列格納に存在するオブジェクトに問合せがアクセスした場合に、その列フォーマットが有益になるときには、オブジェクトが直接送信されます。また、パフォーマンスが向上することにより、既存のワークロードに影響を与えずに、リアルタイムのトランザクション・データに対してより多くのアド・ホック問合せを直接実行できるようになります。
過去数年において、問合せのレスポンス時間を短縮する手段としてインメモリー・データベース・オブジェクトの概念に対する需要が急増しています。インメモリー列ストアを使用すると、アプリケーション・コードを変更しなくてもインメモリー・オブジェクトを既存の環境にシームレスに統合できるようになります。インメモリー列ストアにメモリーを割り当てることにより、既存の分析ワークロードのパフォーマンスを即座に向上できるとともに、インタラクティブなアド・ホック・データの外挿が可能になります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
この機能により、Oracle Databaseに対するJavaScript Object Notation (JSON)データの格納、問合せおよび索引付けに関するサポートが追加され、Oracle Databaseに格納されているJSONをJSON規則に準拠するよう強制できます。また、この機能を使用すると、PATHに基づく表記法を使用してJSONデータを問い合せることが可能になり、JSON PATHに基づく問合せをSQL操作に統合するための新しい演算子が追加されます。
企業は、構造化されていないデータや半構造化されたデータを格納する方法としてJSONを採用しています。JSONデータのボリュームが増加するにつれ、リレーショナル・データの場合と同じレベルのセキュリティ、信頼性および可用性を実現できる方法で、このデータの格納および問合せを実行できることが必要になります。この機能を使用すると、JSONデータとして表される情報をOracleデータベース内で処理できます。
|
関連項目: 詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
新しいデータベース・パラメータDBFIPS_140は、Oracleデータベースで連邦情報処理規格(FIPS) 140暗号処理モードのオンとオフを切り替える機能を提供します。
世界中の政府機関および他の業界では、FIPS 140によって検証された暗号モジュールを使用する必要性がますます高まっています。FIPS 140要件がある場合には、DBFIPS_140パラメータをオンにできます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
CONTAINERS句は、マルチテナント・コンテナ・データベース(CDB)を参照するための新しい方法です。この句を使用すると、ルート・コンテナ内の多くのプラガブル・データベース(PDB)にわたる単一の同一表またはビューからデータを集約できます。CONTAINERS句では、そのコンテナ内のすべてのPDBに存在すると想定される入力パラメータとして、表またはビューの名前が認識されます。単一のPDBまたは一連のPDBのデータは、WHERE句にCON_IDを指定すると組み込むことができます。次に例を示します。
SELECT ename FROM CONTAINERS(scott.emp) WHERE CON_ID IN (45, 49);
この機能を使用すると、ユーザーが作成したデータをマルチテナント・コンテナ・データベース内に集約するという革新的な方法が可能になります。多くのリージョンまたは他の属性にわたってデータを集約する必要があるレポートでは、CONTAINERS句を活用し、単一の場所からデータを取得できます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
新しいパラメータCREATE_FILE_DESTを使用すると、管理者は、Oracle Managed Files (OMF)データ・ファイルのデフォルトの場所をプラガブル・データベース(PDB)内に設定できます。設定しない場合、PDBはこの値をルート・コンテナから継承します。
ファイル・システム・ディレクトリをデフォルトの位置として指定する場合は、そのディレクトリがすでに存在する必要があります。Oracleによって作成されることはありません。ディレクトリには、Oracleがそのディレクトリでファイルを作成できる適切な権限が必要です。これらのファイルには一意の名前が生成されます。この方法で作成されたファイルはOracle Managed Filesです。
CREATE_FILE_DESTパラメータを使用すると、管理者は、マルチテナント・コンテナ・データベース(CDB)ファイルの宛先とは関係なくPDBファイルを構築できます。管理者は、この機能を使用することにより、共有記憶域環境内のコンテナ間でデータベースを接続または切断できます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
PDBのLOGGINGまたはNOLOGGING句をCREATEまたはALTER PLUGGABLE DATABASE文で指定することにより、プラガブル・データベース(PDB)のロギング属性を設定または変更できます。LOGGING句がCREATE TABLESPACE文で指定されていない場合、この属性を使用して、PDB内で作成された表領域のロギング属性を確立します。
PDBのLOGGING句がCREATE PLUGGABLE DATABASE文に指定されていない場合、PDBのロギング属性はLOGGINGにデフォルト設定されます。
この新しい句により、マルチテナント・コンテナ・データベース(CDB)でのPDBの管理性が向上します。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
管理者は、データ・モデル定義のみを使用してプラガブル・データベースのクローンを作成できます。ソース内のディクショナリ・データはそのままコピーされますが、ユーザーがソースから作成した表および索引データはすべて破棄されます。
この機能により、クローニング機能が拡張され、開発環境の迅速なプロビジョニングが容易になります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Multitenantの新しいリリースは、データベース・リンクを介したリモートの完全クローンおよびスナップショット・クローンを全面的にサポートしています。非マルチテナント・コンテナ・データベース(CDB)は、データベース・リンクを介してクローニングするだけで、プラガブル・データベース(PDB)として採用できます。また、同じ記憶域を共有する2つのCDBにわたるリモートのスナップショット・クローニングもサポートされています。
この機能により、プラガブル・データベースの迅速なプロビジョニングがさらに向上します。管理者がプロビジョニングに費やす時間が短縮され、その他の革新的な作業に集中することができます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
初期化パラメータCLONEDBがtrueに設定されている場合、Oracle Direct NFS (dNFS)が有効である任意のローカルのネットワーク・ファイル記憶域(NFS)またはクラスタ化ファイル・システムでプラガブル・データベースのスナップショット・クローンがサポートされます。クローンのソースは読取り専用である必要があり、ターゲットは疎密性をサポートするファイル・システム上に存在する必要があります。
スナップショットのクローニングのサポートは、他のサード・パーティ・ベンダーのシステムに拡張されています。
この機能を使用すると、プラガブル・データベースのスナップショット・クローンに関する特定のファイル・システムの要件が緩和されます。ファイル・システムの寛容なスナップショット・クローンを使用すると、プラガブル・データベースを以前より迅速にプロビジョニングできます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
STANDBYS句を使用すると、プラガブル・データベース(PDB)を既存のスタンバイ・データベースの一部にする必要があるかどうかを指定できます。STANDBYS句には、ALLとNONEの2つの値を使用できます。デフォルト値はALLですが、STANDBYS=NONEとしてPDBを作成する場合、PDBのデータ・ファイルはオフラインになり、すべてのスタンバイ・データベースでUNNAMEDとしてマークされます。PDBが作成された後にインスタンス化された新しいスタンバイ・データベースでは、PDBをスタンバイ・データベースから除外するために回復を目的としてPDBを明示的に無効にする必要があります。ただし、PDBがスタンバイ・データベースで除外された後に同じスタンバイ・データベースでそのPDBを有効にする必要がある場合、PDBデータ・ファイルをプライマリ・データベースからスタンバイ・データベースにコピーし、これらのパスが反映されるよう制御ファイルを更新してから、ユーザーがそのスタンバイ・データベース上のPDBに接続し、ALTER PLUGGABLE DATABASE ENABLE RECOVERYを発行する必要があり、こうすることで、そのPDBに属するすべてのデータ・ファイルが自動的にオンラインになります。
この機能により、同じマルチテナント・コンテナ・データベース(CDB)内の異なるサービス・レベル合意(SLA)がサポートされるため、統合の密度が高くなります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
SAVE STATE句およびDISCARD STATE句をALTER PLUGGABLE DATABASE SQL文とともに使用することにより、マルチテナント・コンテナ・データベース(CDB)の再起動ごとにプラガブル・データベース(PDB)のオープン・モードを保持できます。
SAVE STATEを指定すると、INSTANCES句に指定されているインスタンスでCDBが再起動されるたびに、指定したPDBのオープン・モードが保持されます。同様に、DISCARD STATE句を使用すると、指定したPDBのオープン・モードが保持されなくなります。
これらの新しいSQL句には、CDBが再起動されるたびにアプリケーションのPDBの自動起動を選択できる柔軟性があります。この機能を使用すると、より詳細な制御が可能になり、計画停止および計画外停止時にアプリケーションの停止時間を効率的に短縮できます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
USER_TABLESPACES句を使用すると、新しいプラガブル・データベース(PDB)で使用可能にする必要がある表領域をユーザーが指定できるようになります。複数のテナントに属するデータを区別するためにスキーマベースの統合を行っていた非マルチテナント・コンテナ・データベース(CDB)から、各テナントに属するデータが個別のPDBに保持されているCDBに移行する事例が、この句の使用例です。USER_TABLESPACES句を使用すると、非CDB内のスキーマごとにPDBを1つ作成できます。
この強力な句は、煩雑なスキーマベースの統合を、より機動的かつ効率的なプラガブル・データベースに変換する上で役立ちます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
高速ホーム・プロビジョニングを使用すると、事前に作成されたホームのカタログに格納されているゴールド・イメージに基づいてOracle Homesをデプロイできます。
集中管理により、Oracle Databaseのプロビジョニング時間が大幅に短縮され、ホームの更新もリンクから簡単に実行できます。クラスタ間でのホームの共有を改善し、記憶領域を減らすために、内部でOracleスナップショット・テクノロジが使用されます。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
全表アクセスの場合、ゾーン・マップを使用すると、ディスク上のデータの物理的な位置に基づいてデータのI/Oプルーニングが可能になり、アンチ索引のように機能します。
関連するデータにのみアクセスすることで、問合せへの対応に必要なI/Oが最適化されるため、パフォーマンスが大幅に向上し、リソースの消費量が減ります。
|
関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
