| Oracle® Database新機能ガイド 12cリリース1 (12.1) B71327-06 |
|
 前 |
 次 |
この章では、Oracle Database 12cリリース1 (12.1.0.1)のすべての新機能を説明します。この章には次の項が含まれます:
次の項では、Oracle Database 12cリリース1 (12.1)のアプリケーション開発の新機能について説明します。
次の項では、Oracle Application Expressの機能について説明します。
既存のテーマおよびHTMLテンプレートにおけるアクセシビリティの機能が改善されています。
Oracle Application Expressで開発されたアプリケーションのアクセシビリティを改善することで、障害のあるお客様のアクセスに関する法的コンプライアンスを実現しやすくなります。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
現在、Oracle Application Expressの機能により、ワークスペースのアクティビティやワークスペースでのアプリケーションが時間を追って監視されています。使用されていないワークスペースの管理者には、ワークスペースとアプリケーションが使用されていないためにパージの対象になるということが電子メールで通知されます。休止状態が一定期間続くと、DBAおよびインスタンス管理者は、クリーンアップするワークスペースのリストを承認できます。この結果、ワークスペースとアプリケーション(およびオプションとしてスキーマと表領域)がOracle Application Expressインスタンスから除去されます。
大規模なOracle Application Expressインストールがある組織では、この機能により未使用のデータベース・リソースが解放されます。
|
関連項目: 詳細は、『Oracle Application Express管理ガイド』を参照してください。 |
このリリースの新機能として、JavaScriptとAJAXをアプリケーションに組み込むための宣言機能が提供され、Oracle Application Expressアプリケーションにリッチ・クライアント側の相互作用力を提供します。手動作成のJavaScriptとAJAXを宣言定義で置き換えることにより、リッチ・クライアント側の相互作用力の品質、一貫性および管理性が大幅に向上します。
この機能を利用すると、開発者はクライアント側の動作を宣言によって定義することができ、JavaScriptやAJAXの知識は必要ありません。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
この新機能により、エンド・ユーザーが(アプリケーション内の)既存の表にデータをアップロードできます。開発者は、レコードを挿入するかまたは更新するかを決める一意のキーを含め、どの表にデータをアップロードできるかを定義できます。また、エンド・ユーザーがDEPTNOまたはSTATUS_IDなどと入力するかわりに、Department NameまたはStatus Codeと入力できるように、開発者は列のルックアップを指定できます。
この機能を使用すれば、開発者はエンド･ユーザーの自立度を高めることができます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
エラーの処理とユーザー定義例外の処理が改善され、開発者が、データベース・メッセージのかわりにユーザーフレンドリなメッセージをユーザーに提供できるようになりました。
この改善により、開発者はエンド・ユーザーに表示されるエラー・メッセージを制御できるようになり、エンド・ユーザーに「ORA-00001: 一意制約(<owner>.<name>)に反しています。PKに反しています」というようなエラーが表示されなくなります。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
エンド・ユーザーが、対話型レポートのレポート、アイコンまたは詳細表示を選択できるようになりました。複合フィルタ、グループ化、電子メール通知、および共有レポートの保存機能や検索可能なスタンドアロンHTMLファイルへのダウンロード機能もサポートされるようになりました。
このような機能拡張により、対話型レポートが改善され、エンド・ユーザーが保存したレポートを共有する機能が強化されています。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
改善されたFlashグラフ作成とHTML5グラフの導入に対応するAnyChart 6グラフ作成エンジンを統合することで、見栄えのよいグラフが生成され、ロード時間も短かくなります。マップとガント・チャートも、Oracle Application Expressのウィザードによるグラフ作成に導入されました。HTML5グラフは、Flashをサポートしないモバイル・デバイスのために必要です。
新しいレポート作成エンジンは高速になり、グラフィック機能が向上し、宣言機能が増加しています。これにより、グラフ作成機能が強化されると同時に、開発は容易になっています。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
モバイル・アプリケーションやモバイル・アプリケーション・コンポーネント(HTML5グラフ、HTML5アイテム・タイプおよびモバイル・カレンダを含む)を宣言によって定義できるようになりました。また、この機能により、アプリケーションにデスクトップとモバイルの両方のユーザー・インタフェースを自動検出で実装させやすくなります。モバイル・アプリケーションは、jQuery Mobileを使用して構築されます。
この拡張により、モバイル・アプリケーションの開発期間が短縮され、宣言を使用して開発できるようになります。様々なモバイル・オペレーティング・システム(たとえば、iOS、Android、Blackberry、Windowsなど)用に別のアプリケーションを構築するかわりに、jQuery Mobileを組み込むことで、同じアプリケーションをすべてのモバイル・デバイスで実行できます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Oracle Application Expressの使用性に関して多くの改善が行われています。アプリケーション全体で統合された検索機能、ユーザー・アプリケーションの一般的なエラーやセキュリティの問題点を検査するアドバイザ、製品全体のダッシュボード、改善された管理画面などです。
アプリケーション・ビルダーが改善され、ツールの直観性が高くなり、覚えやすくなっています。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
一群の生産性アプリケーションにより、ユーザーはすぐにデータベースへの投資の活用を開始できます。
多数の生産性およびサンプル・アプリケーションが備わっているため、開発者は、Oracle Application Expressの使用をインストールと同時に開始して、業務のプロセスを改善できます。また、これらのアプリケーションのロックを解除して、そのようなアプリケーションを開発するためのOracle Application Express開発ベスト・プラクティスについて学ぶこともできます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
この機能により、カスタム・リージョン・タイプ、アイテム・タイプ、動的アクション、認証および認可を共有する機能を開発することができます。これによって、Oracle Application Expressアプリケーションの範囲が大きく広がり、Oracle Application Expressの機能ライブラリが提供されます。開発者が必要とする機能がネイティブ・コンポーネントに含まれない場合、このアーキテクチャでは、開発者がサポートとメンテナンスの対象となるようにアプリケーションを拡張することができます。
この機能によって、サポートされている手段が提供されます。それを利用して組込みOracle Application Express機能を拡張できます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
拡張された表形式フォーム機能を使用して、開発者は、列値を使用する評価やプロセスを宣言によって定義できます。この拡張により、新たな表示タイプ(チェックボックス、ポップアップ・キーLOV、ラジオ・グループなど)での表形式フォームもサポートされるようになりました。
表フォームで検証を実行できるようにするために、カスタム・コードをコーディングし、カスタム項目タイプを使用することなく、開発者は検証およびプロセス内で列を参照できるようになりました。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
一連のツールがOracle Application Expressにネイティブに統合されています。これらのツールは、開発者がOracle Application Expressアプリケーションのアプリケーション開発を計画および管理するために使用できます。これには、Oracle Application Expressアプリケーションでフィードバックを収集し、そのフィードバックをTo-Doアイテム、バグまたは機能リクエストとして処理する機能も含まれます。
この機能を利用して、開発チームは開発プロセスを単純化することができます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Oracle Application Expressの新しいテーマはそれぞれ、修正され、現代風になりました。これにより、アプリケーションの外観が新しくなり、グラデーションが利用され、提供されるXHTML準拠テンプレートが増え、アクセシビリティが向上します。テーマ25は、Responsive Designを利用するための新しいテーマです。ウィンドウのサイズに応じてリージョンとアイテムが自動的に調整されます。テーマ26は、Oracle Application Express 4.2に導入された新しいパッケージ・アプリケーションのために使用されるテーマです。モバイル・スマートフォン用のまったく新しいテーマも組み込まれており、開発者はあらゆるモバイル・デバイスで実行するように設計したアプリケーションをすぐに開発できます。
改訂されたテーマでは、アプリケーションの表示が最新デザインになります。これらのテーマは、HTML表ベースではなくDIVベースのためにカスタマイズが容易です。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Oracle Application ExpressでTIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEデータ型がサポートされるようになりました。エンド・ユーザーのタイム・ゾーンを自動的に導出して、Oracle Application Expressセッションに設定する宣言機能も追加されています。これによって、タイム・ゾーン対応アプリケーションを簡単に作成できるようになります。
アプリケーション全体を通してタイム・スタンプおよびタイム・ゾーンを利用できることは、日時を記録するアプリケーションにとっては重要です。これは、グローバルにアクセスされるアプリケーションでは特に重要です。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
ROWIDを自動DML処理に使用できるようになりました(主キー列を指定するかわりに)。
限定数の主キー列のかわりにROWIDを使用すると、開発者は、複数の主キー列を含む表に基づくフォームやレポートを定義するときに標準のウィザードを使用することができます。これは、PeopleSoftなどの市販製品(COTS)のアプリケーションでは、特に重要です。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Webサービスのサポートが、Oracle Application Express内で最新化されています。次のための機能が含まれています。
Webサービスと対話するPL/SQL APIの作成。
レポート・リージョン、DMLプロセスのRepresentational State Transfer (REST) Webサービスとしての公開。
Webサービス・サポートでのバイナリ・データ型のサポート。
カスタムのSimple Object Access Protocol (SOAP)ヘッダーをWebサービスに基づくWeb Services Description Language (WSDL)により含めることが可能。
WSDL解析エンジンの改善。
ウィザードベースのWebサービス・サポートでのSOAP 1.2のサポート。
これらの拡張機能により、Oracle Application ExpressをRepresentational State Transfer (REST) Webサービスと統合し、それらのアプリケーションをSimple Object Access Protocol (SOAP)環境に統合することができます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Webシートは、Oracle Application Expressでの新種のアプリケーション開発で、WebブラウザからOracleデータベース内のデータをさらに管理しやすくなります。Webブラウザのみを使用すると、エンド・ユーザーはページ、データ・グリッドおよびレポートを定義できます。データ・グリッドを使用して、インライン編集の実行、値リストの追加、評価の追加を行うことができ、さらにデータを表示および編集できるコミュニティを選択できます。
この機能により、ビジネス・ユーザーは、テキスト・コンテンツ(ウィキに類似)をデータ(データ・グリッドや、Oracleスキーマ内の表に対する問合せなど)と組み合せることができます。
|
関連項目: 詳細は、『Oracle Application Expressアプリケーション・ビルダー・ユーザーズ・ガイド』を参照してください。 |
Oracleでは、完全にグローバル化されたエンタープライズ・アプリケーションの作成のサポートを強化し、これには最新のUnicode規格準拠、Unicodeキャラクタ・セットへのデータベースの移行、言語照合のサポートおよびアプリケーション・データの多言語サポート用のインフラストラクチャが含まれます。次の項では、拡張グローバリゼーション・サポート機能について説明します。
現在、一連の新しいロケール(およそ10の言語と30の国と地域)が現在Oracle Database 12cリリース1 (12.1)でサポートされます。ロケール全体の対象範囲が広がり、ユーザーの要件に対処できるようになりました。
この機能によって、データベースのロケール範囲が拡張され、ローカル・ユーザーの文化的な慣習に応じた動作を提供できます。
|
関連項目: 詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
Database Migration Assistant for Unicode (DMU)は、従来のキャラクタ・セットからUnicodeキャラクタ・セットにデータベースを移行するための簡素化されたエンドツーエンド・ソリューションを提供します。これはOracle Database 12cリリース1(12.1)に同梱されており、Unicodeキャラクタ・セットへの移行用に公式にサポートされる方法となります。従来のDatabase Character Set Scanner (CSSCAN)およびCSALTERユーティリティは、データベース・インストールから削除され、サポート対象外となりました。また、DMUでは、以前のデータベース・リリース10.2、11.1および11.2を選択して移行することができます。詳細は、次のOTN DMUページを参照してください。
http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/overview/index.html
|
関連項目: 詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
AL32UTF8およびAL16UTF16キャラクタ・セット用の各国語サポート(NLS)データ･ファイルは、Unicode規格キャラクタ・データベースのバージョン6.1に適合するように更新されました。
この機能強化の結果、2012年8月現在で、Oracle DatabaseはUnicode規格の最新バージョンに準拠しています。
|
関連項目: 詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
データベース言語のソートと検索のサポートが拡張され、国際的な照合の標準であるUnicode Collation Algorithm (UCA)およびISO 14651に準拠するようになりました。
UCA準拠の実装により、すべての言語に対する多言語ソートの動作が改善され、業界互換性が向上します。
|
関連項目: 詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
次の項では、一般的な新機能について説明します。
Workspace Managerスキーマ(バージョン対応表、参照整合性制約のバージョン対応表の親表、すべての内部Workspace Managerメタデータを含むスキーマすべて)のインポートとエクスポートが可能になりました。さらに、Workspace Manager対応表を含むデータベースの完全インポートおよびエクスポートも、Oracle Databaseの様々なバージョン間でサポートされるようになりました。
これによって、Workspace Manager対応表を含むデータベースのアップグレードや管理が大幅に単純化されます。
|
関連項目: 詳細は、『Oracle Database Workspace Manager開発者ガイド』を参照してください。 |
DIFFビューおよびCONFビューが再編成され、Workspace対応表に対してOracle Databaseオプティマイザで生成されるSQL計画の効率が向上しています。また、Workspace Managerビューでのユーザー定義のヒントを含めることができるようになりました。
MergeWorkspaceおよびDML挿入にも変更が加えられ、実行時間が短縮されています。
これらの変更により、Workspace Manager対応表の拡大や縮小の効率が上がり、特に大きな表(最大で2億行)をサポートできるようになります。また、問合せのレスポンス時間が短縮されます。
次の項では、改善されたOracle SQLおよびPL/SQLの機能について説明します。
Oracle Database 11gリリース2 (11.2)までは、結果をキャッシュすることができたのは定義者権限のPL/SQLファンクションだけでした。現在は、起動者権限のPL/SQLファンクションも結果をキャッシュできます。(起動ユーザーのIDは結果のキーに暗黙に追加されます。)
時には、起動者権限のPL/SQLファンクションを使用して、1つ以上のSELECT文を発行することをお薦めします。この機能によりパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
以前のリリースでは、LIBRARYタイプのオブジェクトは明示的なパスを使用しないと定義できませんでした。ただし、現在はDIRECTORYタイプを使用して、ファイル・システム・パスを一箇所で管理することができます。さらに、DIRECTORYタイプを使用するとセキュリティのメリットが得られます。ディレクトリ・オブジェクトは、DIRECTORYタイプを使用して定義できます。
また、LIBRARYタイプのオブジェクトの定義に、資格証明を含めることができるようになり、指定した外部プログラムをOracleインストールの所有者ではなく別のオペレーティング・システム・ユーザーとして実行できます。
このような拡張により、外部プロシージャを使用するアプリケーションのセキュリティと移植性が向上します。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
以前のリリースのOracle Databaseでは、2組以上の表の外部結合を実行する問合せで、単一表は他の1つの表のみに対してNULL生成された表にすることができました。Oracle Database 12c以降では、単一表は複数の表に対してNULL生成された表にすることができます。
Oracle Database 12cより前では、外部結合の左側に複数の表を入れることは違反で、その結果ORA-01417エラーが発生しました。そのような問合せを実行するには、ANSI構文に変換するしかありませんでした。Oracle Database 12cでは、LEFT OUTER JOINのネイティブの構文が拡張されて、左側に複数の表を指定できるようになりました。この拡張には次の利点があります。
外部結合の左側に指定した複数の表ビューをマージします。このようなビューはユーザー問合せに基づくことができます。または、LEFT OUTER JOIN構文からの変換において生成されます。
このようなビューのマージにより、結合の並替えを多く行えるようになり、それによって最適な実行計画が生成されます。これらのビューは経験則的にマージされるため、コストに基づく問合せ変換を行う必要はありません。
これにより、アプリケーション開発者は、ビューまたはLEFT OUTER JOIN構文に関して問合せを作成する負担から解放されます。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
このリリースでは、JavaおよびJDBCアプリケーションがPL/SQLパッケージの型とブール型をパラメータとしてバインドできます。
この機能によって、PL/SQL型とJava型のマッピングおよび交換がシームレスかつ容易に行えるようになり、Java開発者の生産性が向上します。
現在、許可されたコール元のホワイト・リストで、スキーマレベルのファンクション、プロシージャ、パッケージまたは型指定をマークすることができます。許可されたコール元は、PL/SQLサブプログラムを呼び出すことができるトリガー・オブジェクト・タイプです。ただし、これは、ホワイト・リストがあるユニットと同じスキーマに存在する必要があります。ホワイト・リストはオプションですが、使用するときは、リストされたオブジェクトのみが該当のユニットを参照できます。参照オブジェクトのスキーマは明示的に指定できるので、異なるスキーマ間の呼出しが可能です。
この機能は、メイン・ユニットとヘルパー・ユニットからなるモジュールの堅牢な実装をサポートします(ヘルパー・ユニットにはヘルプ対象のユニット以外からはアクセスすることができません)。
|
関連項目: 詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
この機能によって、データベース・クライアントAPI (たとえば、OCIおよびJDBC)が、PL/SQLのパッケージ型およびブール型をネイティブに記述してバインドできるようになります。現在、JavaおよびCベース・アプリケーションは、パラメータとしてPL/SQLパッケージ型およびブール型を含むPL/SQLファンクションまたはプロシージャを簡単にバインドして実行できます。
この機能により、クライアント側アプリケーションからPL/SQLファンクションまたはプロシージャを実行する複雑さが解消されます。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
DBMS_UTILITY.EXPAND_SQL_TEXTプロシージャは、ビューを参照する副問合せを受け入れ、表のみを参照する同一の意味を持つ副問合せを返します。
この機能が役立つのは、アプリケーションのロジックを修正したりパフォーマンスの問題を解決したりするためにビューを使用するSQLを分析するときです。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
UTL_CALL_STACKパッケージは、PL/SQLプログラムの現在のコール・スタックを返すサブプログラムを提供します。
これは機能的に、人間が読み取れる文として情報を返す既存のDBMS_UTILITY.FORMAT_CALL_STACKプロシージャに似ています。この新しいパッケージは、プログラムによる分析に対応する構造化表現としてこの情報を提供します。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
現在、$$PLSQL_UNIT_OWNERおよび$$PLSQL_UNIT_TYPE事前定義のPL/SQL問合せディレクティブがこのリリースでサポートされます。
Oracle Database 11gリリース2 (11.2)までは、事前定義の問合せディレクティブ$$PLSQL_LINEおよび$$PLSQL_UNITで、診断コードによる現在のPL/SQL文の特定が可能でしたが、不正確な部分がありました。この不正確な部分は修正されました。
|
関連項目: 詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
DBMS_SQL.PARSE()プロシージャには、新しいSCHEMAパラメータがあります。これは、未修飾のオブジェクト名を解決するスキーマを指定します。
これにより、定義者権限ユニットが、自ら発行する動的SQLの名前解決を制御できるようになります。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
このリリースから、PL/SQLファンクションを副問合せのWITH句に定義して、通常のファンクションとして使用することができます。
SQL文をサポートするために必要な手順のロジックが、SQL文にカプセル化されています。これは読取り専用データベースで特に役立ちます。
このコンストラクトを使用すると、スキーマレベル・ファンクションに比べてパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
Oracle Database 11gリリース2 (11.2)までは、PL/SQLがSQLを起動するときに、SQLでサポートされるデータ型の値しかバインドできませんでした。この制限は、呼び出されたSQLがPL/SQL無名ブロックの場合にも適用されました。この制限は、Oracle Database 12cリリース1 (12.1)では削除されています。たとえば、データ型がBOOLEANの仮パラメータを含むPL/SQLサブプログラムを、無名ブロックを使用して動的に起動できるようになりました。
その他の制限も削除されています。データ型がPL/SQLで宣言されたコレクションに対するPL/SQLプログラムで表演算子を使用できるようになりました。このとき、データ型としてPL/SQL結合配列を使用することもできます。(以前のリリースでは、コレクションのデータ型をスキーマ・レベルで宣言する必要がありました。)
これらの制限の削除により、式の効果とPL/SQLの有効性が向上しています。特に、表演算子の柔軟性が向上したことにより、他のベンダーのストアド・プロシージャ言語を実行するために記述したコードを、簡単にPL/SQLに移行できるようになりました。
|
関連項目: 詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
計画ベースラインのSQL文の生成のための新しいコマンドライン・オプションがあり、生成されたSQLファイルおよびログ・ファイルの名前と形式を制御します。
このサポートにより、SQL文実行のパフォーマンスの低下を回避でき、プリコンパイラ・アプリケーションを簡単にアップグレードできるようになります。
|
関連項目: 詳細は、『Pro*C/C++プログラマーズ・ガイド』を参照してください。 |
次に示すのは、SQL計画管理(SPM)のためのSQLJのサポートに関するこのリリースの新機能です。
計画ベースラインSQL文の生成のためのコマンドラインとプロパティ・ファイルのオプション。
SPM計画を作成するための文を含むSQLファイルの生成。
生成されたログ・ファイルおよびJavaファイルのネーミングの制御
この新しいサポートは、SQLJアプリケーションのアップグレードを容易にし、SQL文の実行のパフォーマンスの低下を防ぐのに役立ちます。
|
関連項目: 詳細は、『Oracle Database SQLJ開発者ガイド』を参照してください。 |
時制有効性により、既存の列を使用するか、データベースによって自動的に作成された列を使用して、表に1つ以上の有効な時間ディメンションを追加することができます。
多くの場合、アプリケーションは、データベースに記録された事実の有効性を、日付やタイム・スタンプによって示します。このような日付やタイム・スタンプは、基礎となるビジネス(アプリケーションで管理しているビジネス)に関連するものです。そのような日付の例としては、人事管理アプリケーションにおける従業員の雇用日と退職日、保険契約の保証の有効日の範囲、または株価の持続期間などがあります。時制有効性では、簡単な宣言インタフェースを提供して、アプリケーションで行の有効性を管理できるようにすることで、アプリケーション・コードの複雑さを軽減します。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
フラッシュバック問合せは、時制有効性ディメンションで問合せをサポートするように拡張されました。ユーザーは、基礎となる表で、1つ以上の有効期間に基づいたAS OFおよびVERSIONS BETWEEN句により、問合せを実行できるようになりました。時制有効性とトランザクション時間テンポラル(フラッシュバック・データ・アーカイブを使用して追跡)を組み合せるフラッシュバック問合せは、バイテンポラル問合せと呼ばれます。
2つの時間ディメンションに基づくデータの考えられるすべてのビューに対する宣言型のアクセス権を付与することで、ユーザーは、現在値(すなわち、有効時間およびトランザクション時間でのCURRENT)、現在わかっていること(すなわち、有効時間でのAS OF、トランザクション時間でのCURRENT)、または以前わかっていたこと(すなわち、有効時間およびトランザクション時間でのAS OF)に基づいたデータを問い合せることができるようになりました。Oracle Database 12cリリース1 (12.1)のバイテンポラル問合せによって提供される機能は、以前は、大規模で複雑なアプリケーション・コードを使用しないかぎり実現できませんでした。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
次の各項では、データ・アクセス機能と、Webベースのインタフェースを持つアプリケーションを介して実行されるSQL問合せのサポートについて説明します。
Oracle Database 12cリリース1(12.1)では、新しいクライアント側自動チューニング機能が導入されました。
この機能は、透過的な自動パフォーマンス管理を提供します。
|
関連項目: 詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
この機能は、配列DML文の反復ごとに影響を受ける行数を、ユーザーが提供する配列バッファに個別に取得するために、CおよびC++インタフェースをサポートします。
この機能により、データ・アクセス(信頼性、品質管理、デバッグの容易さなど)と、Webベース・インタフェースを持つアプリケーションを介して実行されるSQL問合せのサポートが改善されます。
|
関連項目: 詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
次の項では、Oracleに移行する際のコストと複雑さに影響する機能について説明します。
列のデフォルト値がOracleの順序を直接参照できます。有効なエントリはsequence.CURVALおよびsequence.NEXTVALです。
デフォルト値式として順序を直接参照できる機能によって、コードの開発が単純になります。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
列のDEFAULT定義は、DEFAULTが明示的なNULL挿入に適用されるように拡張できます。
DEFAULT句に新しいON NULL句を指定できるようになりました。これは、INSERT文が割り当てようとしている値がNULLと評価される場合に、指定のデフォルト列値を割り当てるようにデータベースに指示します。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
表の列は、米国規格協会(ANSI)のSQLキーワードIDENTITYをサポートするように拡張されました。
これにより、自動的に増分する列の宣言に標準ベースのアプローチが提供され、アプリケーションの開発が単純になり、DDLのOracleへの移行が簡単になります。
|
関連項目: 詳細は、Oracle Database SQL翻訳および移行ガイドを参照してください |
VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが、4,000バイトから32,767バイトに拡大されました。
これらのデータ型に割り当てられるサイズが拡大されたことで、ラージ・オブジェクト(LOB)に切り替える前に、文字データ型に格納できる情報の量が増加しました。これは、簡潔なテキスト・データ型、およびこれらの型の列に索引を作成する機能において特に有効です。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
Sybaseアプリケーション移行のためのJDBCのサポートには次の新しいAPIが含まれます。
oracle.jdbc.sqlTranslationProfile
oracle.jdbc.sqlErrorTranslationFile
oracle.jdbc.OracleTranslatingConnection
また、構成ファイルSQLErrorTranslation.xmlも含まれます。
これらの新しいAPIにより、Sybase JavaアプリケーションをOracleに移行する際のコストと複雑さが低減されます。
|
関連項目: 詳細は、Oracle Database SQL翻訳および移行ガイドを参照してください |
Oracle Database 12cリリース1 (12.1)よりも前では、静的SQLとしてPL/SQLプログラムに埋め込まれ、データベースで実行するSELECT文は、INTO句、BULK COLLECT INTOまたはBULK FETCH INTO句、またはCURSOR FOR LOOP句を使用して、結果をそのプログラム内のPL/SQL変数に返す必要がありました。その後、適切に定義されたスカラーまたはコンポジット・バインド引数を使用して、クライアントがこれらの結果にアクセスしました。あるいは、SELECT文を使用して、REFCURSORをクライアントに返し、結果のフェッチを管理できるようにしていました。
現在、PL/SQLには、他のベンダーの環境で提供されていたのと同じ機能が追加されています。最小限のSELECT文を使用して結果をクライアントに渡すことができます。コードが他のベンダーの環境からOracle Databaseに移行されるときは、この機能によって、結果セットとの暗黙の通信を利用するコードを作成しなおす必要がなくなります。
|
関連項目: 詳細は、Oracle Database SQL翻訳および移行ガイドを参照してください |
FETCH FIRST句およびOFFSET句は、返される行数を制限し、戻りセットの開始行を指定するために、ネイティブSQL言語をサポートします。
多くの問合せで、返される行数を制限したり、結果の開始行をオフセットしたりする必要があります。たとえば、上位N個の問合せでは、結果セットをソートし、最初のn行のみを返します。FETCH FIRSTおよびOFFSETによって構文が単純化されます。これらはANSI SQL標準に準拠しています。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
MySQLアプリケーションのOracle Databaseドライバは、MySQL 5.5のクライアント・ライブラリを一時的に置き換えるものです。これによって、MySQL C APIを使用して構築されたアプリケーションやツールが、MySQL C APIを実装する新しいライブラリを使用してOracle Databaseで実行できるようになります。
主要なメリットは、MySQLとOracleの両方でMySQLアプリケーションを再利用できることと、MySQLアプリケーションをOracleに移行するためのコストと複雑さが低減されることです。
|
関連項目: 詳細は、Oracle Database SQL翻訳および移行ガイドを参照してください |
新しいコマンドライン・オプションにより、Pro*CおよびPro*COBOLで、行のプリフェッチに使用されるメモリーの量を制限できます。
この機能によって、リソース制御が行われ、DB2アプリケーションをOracleに移行する際のコストと複雑さが低減します。
|
関連項目: 詳細は、『Pro*COBOLプログラマーズ・ガイド』を参照してください。 |
APPLY SQL構文を使用して、問合せの外部表式から返される行ごとに、表値ファンクションを呼び出すことができます。表値ファンクションは右側の入力として、外部表式は左側の入力として使用されます。右側の入力は、左側の入力の各行に対して評価され、生成された行が最終出力のために結合されます。したがって、左相関を表値ファンクションに渡すことができます。
APPLY - CROSS APPLYとOUTER APPLYという2つの形式があります。CROSS APPLYは、表値ファンクションから結果セットを生成する外部表の行のみを返します。OUTER APPLYは、結果セットを生成する行と、生成しない行(表値ファンクションによって生成される列にNULLを含む)の両方を返します。
LATERAL (ANSI標準に含まれる)はインライン・ビュー構文を拡張したものです。インライン・ビューの範囲にある左相関を提供します。これらの新しいキーワードによって、SQL問合せ結果を評価して返すための容易で柔軟性の高い方法が提供されます。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
新しいメカニズムが提供され、ODBCやJDBCなどのオープン・アプリケーション・プログラミング・インタフェース(API)を使用してクライアント・プログラムから発行されたSQL文のテキストを、Oracle Database SQLコンパイラに送信する前に、ユーザー指定のコードによって変換できるようになりました。変換コードは、PL/SQL APIを使用してデータベースに指定およびインストールされます。これは、プログラムやルックアップを使用して、または両方を適切に組み合せて実装できます。トランスレータの名前は接続時に指定します。このメカニズムでは、Oracleのエラー・コードとAmerican National Standards Institute (ANSI)のSQLSTATESもユーザー指定コードによって変換できます。
わかりやすいユース・ケースとしては、異なるベンダーのデータベース(およびOracle以外のSQL言語)に対して作成された実在のクライアント側アプリケーション・コードを、変更せずにOracleデータベースに対して実行できます。他のSQL言語の構文とセマンティクスがエミュレートされるためです。このように、移行のコストが大幅に削減されます。他にこの機能が役立つのは、クライアントが発行するSQL文と実際に実行される処理の間に介入する必要があるユース・ケースです。
|
関連項目: 詳細は、Oracle Database SQL翻訳および移行ガイドを参照してください |
次の項では、.NETおよびMicrosoft開発コミュニティの新しい機能について説明します。
Oracle Developer Tools for Visual Studio (ODT)の新機能の詳細は、ODTオンライン・ヘルプのOracle Developer Tools for Visual Studioの新機能に関する項を参照してください。このオンライン・ヘルプは製品と一緒にインストールされます。
Oracle Data Provider for .NETでは、.NET Framework 4および4.5 (Client Profileを含む)がサポートされます。
Oracle Data Provider for .NETでは、Oracle TimesTen In-memoryデータベースに対する.NETアプリケーションの高速データ・アクセスが可能です。ODP.NETによるTimesTenのサポートには、Oracle.DataAccess.ClientおよびOracle.DataAccess.Typesネームスペースのクラス、列挙、インタフェース、デリゲートおよび構造が含まれています。
ODP.NETは、Microsoft Windows 32ビットおよび64ビット・プラットフォームにおけるTimesTenリリース11.2.1.6.1以上をサポートします。TimesTenは、Microsoft Visual Studio 2005以上とともに、.NET Framework 2.0、3.0、3.5および4で使用できます。
ODP.NET XCopyは、Microsoft Windows x64システムで使用できるようになり、通常のODP.NETクライアントよりも小さいクライアント・インストール・サイズを実現し、さらに構成が簡単になりました。
ODP.NET XCopyは、カスタマイズされたデプロイメント・パッケージへのODP.NETの埋込みを簡素化します。
Entity Frameworkは、データ・モデルでのオブジェクトリレーショナル・マッピングおよびサービスを提供するフレームワークです。これは、データベース形式(リレーショナル)とクライアント優先形式(オブジェクト)とのインピーダンス・ミスマッチを解決しようとします。
統合言語クエリ(LINQ)は、配列データ、可算クラス、XML、リレーショナル・データベースおよびその他のデータ・ソースのクエリ、計画およびフィルタ処理に使用される一連の演算子を定義します。LINQの1つの形式であるLINQ to Entitiesを使用すると、Entity Frameworkデータ・ソースをクエリできます。
Oracle Data Provider for .NET (ODP.NET)では、オブジェクトリレーショナル・モデリングおよびLINQ to EntitiesクエリーでOracle Databaseを使用できるようEntity Frameworkがサポートされています。
Entity FrameworkおよびLINQを使用すると、多くの点で.NET開発者の生産性が向上します。ここでは、アプリケーションのデータ・モデルからデータベースのデータ・モデルが抽出されます。Entity Frameworkのツールを使用すると、オブジェクト・リレーショナル・データの処理が容易になります。Oracle .NET開発者は、Entity FrameworkおよびLINQにOracleを統合することで、生産性に関するこれらのすべての利点を活用できます。
|
関連項目: 詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
Oracle Data Provider for .NET (ODP.NET)では、REF CURSORパラメータを、明示的にバインドすることなくストアド・プロシージャにバインドできます。これを行うには、アプリケーションでREF CURSORメタデータを.NET構成ファイルの一部として指定する必要があります。
この機能によって、Entity Frameworkの関数インポートでOracleストアド・プロシージャをコールして、REF CURSORの結果セットを戻すことができます。また、ODP.NETは、REF CURSORを介して取得したデータ・セットまたはデータ表でデータベースのデータを更新することもできます。
Entity Frameworkでは、通常、結果セットのパラメータは宣言されません。ODP.NETは、暗黙的なREF CURSORパラメータをサポートすることで、Entity Frameworkの標準的な使用シナリオとより緊密に統合されます。
|
関連項目: 詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
Language Integrated Query (LINQ)は、.NETの問合せ言語です。LINQは実行時にネイティブ・データベースのSQLに変換されてから、データベースを問い合せます。状況によっては、LINQはラテラル・ビューを取得するために非標準のAPPLYキーワードをSQL翻訳で使用することがあります。Oracle DatabaseおよびODP.NETは、Oracle Database 12cリリース1 (12.1)ではAPPLYキーワードをサポートし、LINQのサポートを強化しています。
この機能により、SQL APPLYが使用される偶発的なLINQ問合せが、ラテラル・ビューについてODP.NETおよびOracle Databaseでシームレスに作動できます。
|
関連項目: 詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
現在、複数のDML文を実行するために配列バインディングを使用すると、Oracle Data Provider for .NET (ODP.NET)によって、影響を受けた行数の合計ではなく、バインドされた配列の入力値ごとに影響を受けた行数をリストする配列が提供されます。この情報によって、より詳しいフィードバックがアプリケーション開発者に提供されます。行数を取得するには、ODP.NETはOracleCommand.ArrayBindRowCountプロパティを呼び出します。
配列がバインドされたDML実行についてさらに詳しいフィードバックが得られるため、開発者は問合せの有効性やデータ変更が正しく適用されたかどうかを評価しやすくなります。
|
関連項目: 詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
開発者は、WCF Data Servicesによって、ODataを使用するサービスを作成し、Representational State Transfer (REST)のセマンティクスを使用してインターネット上のデータを公開および使用できます。ODataで公開されるデータはURI (universal resource identifier)によってアドレス指定できるリソースです。リソースは、ODataでEntity Data Modelの規則を使用して、アソシエーションによって関連付けられたエンティティのセットとして公開されます。ODP.NETではEntity Frameworkのサポートを介して、ODataおよびWCF Data Servicesを使用してデータが公開されます。
WCF Data ServicesおよびODataを使用すると、任意のデータ・ソースからフレキシブルなデータ・サービスを作成して、作成したデータ・サービスを無理なくWebに統合できます。すべてのタイプのデータ・ソース(Oracle Databaseを含む)が同じデータ共有標準で使用されるため、データ交換による相互運用がより可能になります。
|
関連項目: 詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
次の項では、Java開発コミュニティの新しい機能について説明します。
Java Database Connectivity (JDBC)でサポートされるその他の機能については、次の各トピックを参照してください。
Oracle Database 12cリリース1(12.1)では、アプリケーションにデータベースへの明示的アクセス権がない場合に、アプリケーション内のスレッドと関連付けることができるDBOPタグが導入されました。DBOPタグは、setClientInfo()メソッドまたはOracle Dynamic Monitoring Services (DMS) APIのいずれかの起動によりスレッドと関連付けられ、アクティブ・データベース接続またはクライアント/サーバーのラウンドトリップは必要ありません。
|
関連項目: 詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。 |
このリリースでの新しいサポートにより、ユーザーは埋込みJava VMランタイムをJava Development Kit (JDK)のより新しいリリースにアップグレードできます(たとえば、JDK 1.6からJDK 1.7へのアップグレード、またその逆であるJDK 1.7からJDK 1.6へのダウングレード)。また、データベースのインストール時にユーザーがターゲットJDKを選択することもできます。
最新のJava標準を使用するとコストを削減できます。生産性が向上し、Javaのクラスやライブラリを再利用できるためです。この機能により、最新Java標準との互換性が得られます。
|
関連項目: 詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
Oracle Databaseでは、JDK 1.6、JDK 1.7、Java Naming and Directory Interface (JNDI)、Java LoggingおよびJava SE Integration Libraries(RMI-IIOPやスクリプティング)をサポートします。
JDKのサポートにより、Javaクラスまたはライブラリを再利用することで、コストが軽減され、生産性が向上します。最新Java標準との互換性が得られるため、クライアント側のJavaクラスおよびライブラリを移植したり、データベースで直接使用したりすることが可能になります。
|
関連項目: 詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
Oracle Databaseには、Javaランタイムのための拡張された権限とポリシーの管理が含まれます。Javaポリシーがシステム管理者によってリロードできるようになるのは、サードパーティの暗号化スイートを追加した後です。また、データベース管理者はアルゴリズム検索順序を変更できます。
このような拡張により、権限とポリシーの管理が厳しくなると同時に、サードパーティ暗号化ライブラリのサポートが柔軟かつ高度になります。
|
関連項目: 詳細は、『Oracle Database Java開発者ガイド』を参照してください。 |
Java Database Connectivity (JDBC)では、Kerberos認証およびWindows認証(NTS)を含む、Oracle Databaseでのセキュリティ強化がサポートされます。
この機能によって、Javaアプリケーションに高度なセキュリティが提供されます。
|
関連項目: 詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。 |
データベース常駐接続プール(DRCP)は、専用サーバーのプールで、データベース・サーバーで有効化され、クライアント・アプリケーション、プログラミング言語および中間層間で共有されます。データベース上でいったん有効化されると、新しい接続プロパティoracle.jdbc.DRCP.nameおよびoracle.jdbc.DRCP.purityによって、JavaおよびJDBCアプリケーションはクライアント側の接続プール(たとえば、ユニバーサル接続プール)を使用してこのプールを透過的に使用できるようになります。oracle.jdbc.pool.OraclePooledConnectionの下に新しいpublicメソッドが導入され、この機能がクライアント・プールの開発者に公開されます。
この機能により、Javaアプリケーションの大規模なデプロイが可能になります(通常、同じデータベースに接続している数百または数千の中間層)。データベース・サーバーのプロセスとメモリーの大幅な削減が、この新しい機能に伴って確認されます。
|
関連項目: 詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。 |
配列DML、JDBC 4.1仕様、ParameterMetaData、getClientInfoおよびsetClientInfo APIの繰返しごとに行カウントがサポートされるようになりました。
Java標準に完全に準拠することで、OracleまたはOracle JDBCで構築されたアプリケーションへの外部Javaアプリケーションの移植が保証されます。
|
関連項目: 詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)のビジネス・インテリジェンスおよびデータ・ウェアハウスの新機能について説明します。
次の各項では、Oracle Advanced Analyticsの新機能について説明します。
ディシジョン・ツリー・アルゴリズムで、ネストされたデータがサポートされるようになりました。ディシジョン・ツリー・アルゴリズムをテキスト・マイニングに使用できます。
ディシジョン・ツリーは、透過性と普及率の高さからよく使用されています。このため、構造化されていないデータをこのアルゴリズムで扱えるようにすることが重要です。
|
関連項目: 詳細は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。 |
リリース11gでは、Oracle Data Miningによって2つのクラスタリング・アルゴリズムが提供されました。ただし、これらのアルゴリズムでは、様々なドメインからのデータ(構造化されたデータと非構造化データなど)の統合が容易ではありませんでした。期待値最大化(EM)は、データの密度モデルを作成する確率的クラスタリング・アルゴリズムです。密度モデルを使用すると、様々なドメインからのデータを結合する方法が改善されます。各ドメインは、ドメインにとって適切な分布でモデル化できます。分布パラメータは、最も可能性の高いデータの接合分布を提供するように最適化されます。EMの確率的特性のため、クラスタ割当ての見込みは、現在のOracle Data Miningアルゴリズムで生成される値よりも信頼性が高くなります。また、EMアルゴリズムは、データのモデル化に必要なクラスタの最適数も自動的に決定します。
Oracle Data Miningによって、アプリケーションに分析論が導入され、様々なタイプのクラスタリング機能が提供されています。これらは、現在複数のアプリケーションで使用されています。現在の機能で多様な問題が解決されますが、様々なドメインからのデータ(販売取引と顧客統計または構造化データと未構造化データ(たとえばテキスト)など)を効率よく結合するため、さらに範囲や等式の述語を含む問合せに答えるために新たな方法が求められています。期待値最大化はこれらすべての要件に対処できます。
|
関連項目: 詳細は、『Oracle Data Mining概要』を参照してください。 |
特異値分解(SVD)および主成分分析(PCA)は、データに内在する分散を、直交線形投影を使用して求める強力な特徴抽出法です。この特性は、高次元データのディメンション性を減少させ、有益なデータの視覚化をサポートする場合に非常に役立つ。テキスト・マイニングは、SVD投影を適用できる様々な分野の1つです。
PCAは、SVDアルゴリズムに含まれる特別なスコア計算方法とみなすことができます。これは、データの分散に応じてスケールされる投影を生成します。場合によっては、このタイプの投影が、標準の非スケールSVD投影よりも特徴抽出に適しています。
Oracle Data Miningによって、アプリケーションに分析論が導入され、強力な特徴抽出機能が提供されており、これらは、多くのコンテキストで使用でき、非構造化データや、センサー(無線自動識別(RFID)など)のデータのような大規模な数値データ・セット、および時系列を特別に処理できます。
Oracle Data Miningによって基本的な特徴抽出機能はすでに提供されていますが、多くのアプリケーションをサポートするためには、大規模なデータ・サイズ(行と属性の両方)への拡大に対応でき、データをさらに圧縮できる特徴抽出機能が必要です。
|
関連項目: 詳細は、『Oracle Data Mining概要』を参照してください。 |
特徴選択は、モデルによって使用される予測子の数を減らすために使用されます。これにより、スコアリングが小規模で高速に行えるようになり、一般化線形モデル(GLM)がさらに有意義になります。
特徴生成では、非線形項(3次項まで)を使用するGLMモデルを作成できます。これにより、より強力で透明性の高いモデルが生成されます。
Oracle Data Miningは、アプリケーションに分析論を導入してから、高い精度と透明性(予測を説明できること)という競合する目標の実現を追求し続けています。
アプリケーションでよく使用されるいくつかの手法(たとえばGLM)は、透明性が高くても、透明性の低い方法に比べて精度が低いことがあります。数千の属性を効率よく処理できる、透明性が高く、精度が高いスケーラブルな方法が必要です。これは、特徴選択と特徴生成をGLMに追加することで実現できます。
|
関連項目: 詳細は、『Oracle Data Mining概要』を参照してください。 |
Oracle Data Mining関数のネイティブのdouble型(BINARY_DOUBLEおよびBINARY_FLOAT)がサポートされるようになりました。
マイニング・モデル・デプロイメント(スコアリング)は、バッチとリアル・タイムの両方で本番データの大多数に対して実行されるため、パフォーマンスがクリティカルです。OracleはCパフォーマンス分析を介して、スコアリングのコストの大半は、モデル化そのものではなくOracleのnumberとdoubleの間の型強制が占めることを認識しました。このオーバーヘッドを取り除くことで、スコアリングの動作がさらに高速になります。
|
関連項目: 詳細は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。 |
ネイティブSQL問合せでMATCH_RECOGNIZE句を使用すると、指定されたパターンを行順序で一致させることができます。
ネイティブSQLの行パターン一致により、アプリケーションと開発の生産性が向上し、行順序分析での問合せの効率が上がります。この構文は、正規表現と完全な条件付きロジックを含み、正確で柔軟性の高いパターン定義を行うことができます。どのような分野でも(たとえば、金融市場の価格、インターネット上のクリック数、またはセキュリティ・センサーの出力)、行順序を分析するアプリケーションではMATCH_RECOGNIZEが役立ちます。
|
関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
このリリースではOracle Data Miningのテキスト・マイニングのネイティブ・サポートが追加されています。
この変更により、テキストの処理がOracle Data Miningに埋め込まれ、デプロイメントが単純になり、パフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。 |
オンザフライ・モデル(Oracle Data Miner GUIワークフローSQLDEV拡張機能では予測問合せと呼ばれる)は、分析句の一部として構成されるデータ・マイニング・モデルです。これは、SQL言語およびエンジンと密接に統合された、単純な形式のマイニングを表します。また、これによって導入されるパーティション・モデルの概念では、多くのモデルの永続性を維持するオーバーヘッドが不要です。
アプリケーションは、パーティション・セグメントごとにモデルを構築する必要がありが、この方法では一時モデルを使用することで対応します。
|
関連項目: 詳細は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。 |
このリリースでは、予測の詳細でディシジョン・ツリー・アルゴリズムがサポートされるようになりました。また、クラスタの距離と詳細の関数も追加されています。
アプリケーションは、予測の裏付けとなる理由を説明する詳細を提供する必要があります。また、特定のアプリケーションは、クラスタの中心に最も近いレコードを見つける必要がありますが、CLUSTER_PROBABILITY関数ではこの情報を提供することができません。
|
関連項目: 詳細は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。 |
次の各項では、Oracle OLAPの新機能について説明します。
このリリースでの拡張により、OLAPキューブに対する問合せのパフォーマンスが向上しています。このような拡張は、キューブに対する問合せのCPUとメモリーの消費を最小限に抑えて、I/Oを低減するように設計されています。
Oracleキューブでは、SQLユーザーは高度な分析計算に透過的にアクセスできます。近年のハードウェア(特にOracle Exadataマシン)の進化により、キューブ問合せのパフォーマンスを向上させる多くの機会がもたらされています。この機能では、このようなハードウェアの改善点を活用し、入手できるハードウェアを十分に利用しています。
|
関連項目: 詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。 |
これにより、自動ワークロード・リポジトリ(AWR)、アクティブ・セッション履歴(ASH)および自動データベース診断モニター(ADDM)など、Oracleの統計とワークロードの機能にOracleキューブの統計が公開されます。
この機能により、OracleキューブおよびOLAPディメンションを含むOracleインスタンスの管理が単純になります。
|
関連項目: 詳細は、『Oracle Databaseリファレンス』を参照してください。 |
次の項では、パーティション化の機能について説明します。
グローバル索引メンテナンスが、DROPおよびTRUNCATEパーティション・メンテナンス操作から切り離されました。このため、グローバル索引は使用不可になりません。索引メンテナンスは非同期で実行され、後の時点まで延期することもできます。
索引の可用性に影響せずに、グローバル索引メンテナンスをオフピーク時間まで延期すると、パーティション・メンテナンス操作の時点で、パーティションとサブパーティションのメンテナンス操作であるDROPおよびTRUNCATEの時間が短縮されてリソース消費が減少します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
パーティションのTRUNCATEおよびEXCHANGE操作には、参照パーティション表のカスケード機能があり、親表から子表にパーティション・メンテナンス操作を継承することができます。
パーティションのTRUNCATEおよびEXCHANGEのデータ・メンテナンス操作のカスケードにより、アプリケーション開発が大幅に単純化され、論理データ一貫性が細部にまで適用されます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
参照パーティション表は、最上位のパーティション化方法として時間隔パーティション化を活用しています。
時間隔参照パーティション化によってOracleのパーティション化機能が拡張され、実際のビジネス・ニーズに基づいてデータベース・スキームをモデル化できるようになりました。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
ALTER TABLE ... MOVE PARTITIONが非ブロック・オンラインDDLになり、その間、移動中のパーティションにおいて、DML操作が中断せずに実行し続けます。グローバル索引はパーティションの移動中にメンテナンスされるため、手動で索引を再構築する必要はなくなりました。
オンラインでのパーティション移動により、実際のMOVE PARTITIONコマンドの読取り専用状態が除去されています。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
ローカル索引とグローバル索引を、表のパーティションのサブセットに作成できます。
部分索引により、パーティション表の索引作成の柔軟性が向上します。たとえば、最新パーティションについて索引セグメントを省略すると、データ・モデル全体およびパーティション・オブジェクトのアクセスに影響せずに、最高データ収集速度を保証することができます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
パーティション・メンテナンス操作を、1回のパーティション・メンテナンス操作の中で複数のパーティションに対して実行できます。
同時に複数のパーティションに対して1回だけパーティション・メンテナンス操作を実行することで、アプリケーションの開発が単純化され、パーティション・メンテナンスの効率が上がり、使用されるシステム・リソースも減少します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
次の項では、労力なしで得られるパフォーマンスの機能について説明します。
オプティマイザが最初の計画生成で推定を間違う可能性があります。適合問合せ最適化により、次の2つの方法のいずれかで、これらの誤りは修正できます。
適合計画では、実行中に計画を停止し、実行の最初の部分で収集された情報に基づいて再最適化できます。たとえば、最初の計画の選択が、見積りカーディナリティ1でのNESTED LOOPの実行だった場合、1,000レコードが結合に送信された時点でその計画が停止され、その後、最初のカーディナリティ見積りが間違っていたため、かわりにHASH JOINを使用して再び開始されます。
自動再最適化は、文の最初の実行には影響しません。かわりに、問合せの最初の実行は監視され、実際の実行見積りが元の計画見積りと大幅に異なる場合は、実行統計が記録されて、新しい計画が後続の実行のために選択されるかどうかを確認するために、次に文が実行されるときに使用されます。
適応問合せ最適化は、オプティマイザが、実行計画に対する実行時の調整を行い、より優れた統計を導くための追加情報を検出できるようにするための一連の機能です。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
適応SQL計画管理を使用すると、DBAは承認されなかった計画について手動で確認を実行したり、プロセスを展開したりする必要がありません。自動SQLチューニングがCOMPREHENSIVEモードの場合、夜間のメンテナンス・ウィンドウに、未承認の計画を含むすべてのSQL文について確認が返されるかプロセスが展開されます。承認されていない計画が、SQL計画ベースラインの既存の承認済計画よりも実行に適している場合は、オプティマイザによってその計画が自動的に承認されて、使用できるようになります。確認が完了すると、承認済計画のパフォーマンスに比べて未承認の計画がどのように実行されたかを詳しく示す永続レポートが生成されます。展開プロセスはAUTOTASKになっているため、DBAは自らの展開ジョブを最後にスケジュールすることもできます。
SQL計画ベースライン内の未承認の計画は、夜間のメンテナンス・ウィンドウに自動的に展開され、永続確認レポートが生成されて、DBAが手動で計画を展開する必要はなくなり、数日後または数週間後でも、毎晩のメンテナンス・ウィンドウにどの計画が展開されたかをさかのぼって確認できます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
統計が拡張され、表内の列グループをひとまとまりとして統計を収集できるようになりました。これによって、列間に相関が存在する場合に多くの情報がオプティマイザに提供されます。自動列グループ検出の導入により、DBAは、各表のどの列がワークロードとして一緒に使用されるかを認識する必要がなくなりました。
所定のワークロードに基づいてどの列グループが表で必要になるかが自動的に判別されます。ワークロードを監視することで、必要な列グループが記録され、DBMS_STATS.CREATE_EXTENDED_STATSプロシージャを実行すると列グループを作成できます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
UNION文およびUNION ALL文は、複数のブランチを1つずつ処理するかわりに、同時に実行できます。
UNION文とUNION ALL文の複数のブランチを並列して実行することで、処理時間が短縮され、リソース使用率が向上します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
同時統計収集により、1つのスキーマ(またはデータベース)の複数の表と、1つの表内の複数のパーティション(またはサブパーティション)の統計を同時に収集できます。Oracleは、Oracleジョブ・スケジューラおよびアドバンスト・キューイングを利用して、複数の統計収集ジョブを同時に作成および管理します。
パーティション表に対してDBMS_STATS.GATHER_TABLE_STATSプロシージャを呼び出した場合に、CONCURRENTがtrueに設定されていると、Oracleによって表のパーティション(またはサブパーティション)ごとに別の統計収集ジョブが作成されます。Oracleジョブ・スケジューラは、使用可能なシステム・リソースに基づいて、同時に実行するこれらのジョブの数と、キューに入れる数を決定します。現在実行しているジョブが完了すると、すべてのパーティション(またはサブパーティション)の統計が収集されるまで、さらに多くのジョブがデキューされて実行されます。
複数の表とパーティション(またはサブパーティション)で同時に統計を収集することで、Oracleがマルチプロセッサ環境を十分に利用し、統計の収集にかかる合計時間が短縮されます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
この機能により、データベース・インスタンスが、複数のフラッシュ・デバイスにアクセスしてそれらを組み合せ、データベース・スマート・フラッシュ・キャッシュとして使用できます。ボリューム・マネージャは必要ありません。
データベース・スマート・フラッシュ・キャッシュとして複数のフラッシュ・デバイスを使用するために、Logical Volume Managerのコストや管理オーバーヘッドを負担する必要はありません。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
SQL文のコンパイル中に、オプティマイザが、適切な実行計画を生成するために既存の統計で十分かどうかを検討して、動的統計を使用するかどうかを決定します。既存の統計が十分でない場合は、動的統計が使用されます。動的統計は永続的であり、他の問合せで使用できます。1つのタイプの動的統計は、動的サンプリングによって収集された情報です。従来、問合せの1つ以上の表について統計がない場合にのみ、動的サンプリングが自動的に発生していました。動的サンプリングによってそれらの表の基本統計が収集されてから、文が最適化されました。現在は、動的統計がすべてのSQL文に対して役立つかどうか、また動的サンプリングが正しい方法かどうかは、オプティマイザによって自動的に決定されます。そうである場合、使用する動的サンプリング・レベルもオプティマイザにより決定されます。動的サンプリングで収集される統計の範囲には、JOIN句とGROUP BY句も含まれるようになりました。
オプティマイザで必要と認められると、動的統計は自動的に使用され、生成される統計は統計リポジトリに保持され、他の問合せでも使用することができます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
クリティカルな文は、パラレル・ステートメント・キューをバイパスすることができます。ビジネスの重要性が反映され、柔軟性が向上します。パラレル・ステートメント・キューにより、履歴情報を含めた情報の包括的な監視が実現します。
パラレル・ステートメント・キューの拡張により、柔軟性が向上し、ミッションクリティカル環境のビジネス要件に対処することができます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
パーティション表での統計収集には、表レベルとパーティション・レベル両方での統計の収集があります。増分統計では、パーティション・レベルのみで統計を収集して、パーティション・レベル統計に基づいてグローバル・レベル統計を正確に計算できます。増分統計が拡張され、パーティション交換ロードがサポートされるようになりました。パーティション化されていない表にロードされたデータを、表のパーティションと交換でき、また、パーティション表のグローバル統計は、パーティション化されていない表の統計と既存のパーティション・レベル統計を使用して、自動的かつ正確に計算されます。
以前は、パーティションに対してDMLが発生した場合、増分統計ではパーティション・レベル統計が古いとみなされました。現在は、DMLが発生した場合でも増分統計がパーティション統計を使用できる、増分の失効しきい値を設定できます。
パーティション表で収集を行う増分統計により、正確な統計を収集するために必要な時間とシステム・リソースを大幅に節約できます。増分統計でパーティション交換操作がサポートされることで、ユーザーは、1秒未満のパーティション交換操作を使用してデータをパーティション表にロードできるだけでなく、正確な統計をすぐに得ることができます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
システム統計により、オプティマイザは、データベース・システムが実行しているハードウェアの状態を把握することができます。Exadata Storageのようなスマート・ストレージの導入に伴い、オプティマイザは、スマート・ストレージ機能すべてを把握するために新たなシステム統計を必要としています。
新しいシステム統計収集方法が導入され、オプティマイザは、Exadata Storageなどスマート・ストレージのパフォーマンス特徴を正確に把握できるようになりました。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
自動並列度(Auto DOP)が拡張され、個々の文の並列度(DOP)を決定するときに、さらに多くのデータベースや文の特徴を考慮できるようになりました。
拡張されたAuto DOPにより、全体的なシステム使用率が向上し、あらゆる種類の主要アプリケーションへのAuto DOPの適用範囲が広がります。
|
関連項目: 詳細は、『Oracle Databaseリファレンス』を参照してください。 |
カーディナリティ見積りを改善するため、Oracleは、データ・スキューがある列にヒストグラムを作成します。個別値の数が254を上回る列のために新たに2種類のヒストグラムが導入され、その結果、ヒストグラムによって収集されるカーディナリティ見積りが改善されました。高頻度ヒストグラムが作成されるのは、少数の個別値がデータのほとんど(データの99%超)を占める場合です。このヒストグラムは、特に頻度が高い少数の個別値を使用して作成されます。統計的に重要ではない、頻度の低い値を無視することにより、頻度の高い値に対応した高品質のヒストグラムが作成されます。あるいは、高さ調整ヒストグラムと頻度ヒストグラムを組み合せたハイブリッド・ヒストグラムを作成することもできます。高さ調整ヒストグラムでは、頻度の高い値が常に終了点の値になり、1つの値が複数のバケットにまたがることはありません。各終了値の頻度を記録することにより、よく出現する値の頻度を記録します。
高頻度ヒストグラムの方が正確なカーディナリティ見積りを提供できるのは、列の個別値が254個を超えるが、非常に頻度が高い少数の個別値も含まれる場合です(データの99%超にそれらの値の1つが含まれる)。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
オンライン統計収集では、空の表に対するCREATE TABLE AS SELECT操作またはINSERT INTO ... SELECT操作のようなバルク・ロード操作の中で、統計が自動的に作成されますオンライン統計収集により、バルク・ロードが発生した後で手動で統計を収集する必要はなくなります。CREATE INDEXまたはREBUILD INDEXコマンドの際に収集される統計と同じように動作します。
オンライン統計収集により、バルク・ロード操作のパフォーマンスと管理性の両方が向上します。ロードの後で統計を収集するためにユーザーが介入することがなくなり、個別の統計収集操作で必要な追加の全表スキャンがなくなるためです。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
マテリアライズド・ビュー(MV)のリフレッシュは、論理的に同一の外部表(および索引)を使用して、MVリフレッシュ操作を実行し、リフレッシュ・プロセスの最後で、古いMVと最新の外部表を交換します。ホーム外のリフレッシュでは、非アトミック・リフレッシュ・モードでのCOMPLETE、FASTおよびPCTリフレッシュを含む、既存のすべてのリフレッシュ方法がサポートされます。
ホーム外のリフレッシュにより、最短のリフレッシュ時間と、マテリアライズド・ビューの高可用性が実現します。
|
関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
従来、グローバル一時表の統計は1セットのみで、様々なセッションの異なるデータが表に含まれる場合でも、その統計がすべてのセッションで共有されていました。Oracle Database 12cリリース1 (12.1)では、グローバル一時表にはセッションプライベート統計があります。これは、セッションごとに異なる統計セットです。グローバル一時表に対して発行される問合せは、専用セッションの統計を使用します。
グローバル一時表のセッションプライベート統計により、一時表のパフォーマンスと管理性が向上します。ユーザーが、セッションごとにグローバル一時表の統計を手動で設定したり、動的サンプリングを利用したりする必要はありません。これにより、グローバル一時表のカーディナリティ見積りでのエラーの可能性が減少し、オプティマイザが最適な実行計画を特定するためのデータを得ることができます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
PL/SQL DBMS_STATSパッケージを使用して収集される統計の他に、オプティマイザは、コンパイル時には動的サンプリングを使用して、実行時には適応実行計画を使用して統計を収集できます。以前のリリースでは、コンパイルと実行の統計はカーソル・キャッシュのみに格納され、永続的ではありませんでした。SQL計画ディレクティブの導入により、コンパイルと実行の統計がディスク上のSYSAUX表領域で永続化されます。SQL計画ディレクティブを使用すると、オプティマイザが実行計画を生成するときに、アクセス対象のオブジェクトに関してより多くの情報にアクセスできます。情報には、表t1とt2がSQL文で結合される場合、または列の間に相関の可能性がある場合に、動的サンプリングを使用すべきかどうかというものも含まれます。
SQL計画ディレクティブにより、コンパイル統計(動的サンプリングの結果)と実行統計(適応実行計画の結果)の両方がSYSAUX表領域に永続化され、複数のSQL文で使用できるようになるため、実行計画の正確さが向上します。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
パーティション化や、表と対応するマテリアライズド・ビューの間の論理的な依存関係を利用して、実表と同期してマテリアライズド・ビューをリフレッシュすることができます。
マテリアライズド・ビューが古くなっている(データが最新ではない)期間が最小限に抑えられ、可用性が向上します。
|
関連項目: 詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)の圧縮とアーカイブの新機能について説明します。
次の項では、アーカイブ機能について説明します。
この機能により、フラッシュバック・データ・アーカイブ(FDA)機能が拡張され、アプリケーションのセキュリティが重要な表の完全な履歴が提供されます。この機能で提供される1つのコマンドを使用して、1アプリケーションのすべての指定表でFDAを有効にし、それらの表の厳しい監査のニーズに対処します。また、この機能により、管理者は1つのコマンドを使用して、1アプリケーション内のすべてのセキュリティ表を読取り専用にすることができます。
データベース強化により、アプリケーションのすべてのセキュリティ関連表の履歴を追跡しやすくなり、また、必要に応じてそれらの表を読取り専用にすることができ、すべての表をループ処理するスクリプトを作成したり、他の手動操作を実行したりする必要はありません。アプリケーションによってグループ化された表に対するフラッシュバック・データ・アーカイブのサポートが拡張されたため、それらの表に対して行われたすべての変更を追跡しやすくなり、Oracle Flashback Queryを使用して履歴にアクセスしやすくなります。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
フラッシュバック・データ・アーカイブ(FDA)にいくつかの改善が加えられました。これらを次に示します。
ユーザーコンテキストの追跡
ユーザー・コンテキストなどのトランザクションを追跡するためのメタデータ情報が追跡され、どのユーザーがどの変更を表に加えたかの確認が容易になります。
ハイブリッド列圧縮(HCC)
Exadataや他のOracleストレージ・プラットフォーム上のHCC圧縮表でFDAを十分に活用できるようになりました。
履歴のインポートとエクスポート
ユーザー生成履歴のFDA表へのインポートがサポートされるようになりました。トリガーなど他の方法を使用して履歴を管理していたユーザーは、履歴をFDAにインポートできるようになりました。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
次の項では、新しいフラッシュバック・データ・アーカイブ機能について説明します。
表での変更を追跡するためにフラッシュバック・データ・アーカイブを使用すると、フラッシュバック・データ・アーカイブの作成時にOPTIMIZE DATA句を使用して、対応する履歴表の最適化を有効にすることが可能になりました。
フラッシュバック・データ・アーカイブの履歴表の最適化により、ストレージの効率がよくなり、変更履歴に対するフラッシュバック問合せのパフォーマンスが向上し、DBAによるさらなる介入は必要ありません。
次の項では、情報ライフサイクル管理(ILM)機能について説明します。
この機能では、情報ライフサイクル管理(ILM)ポリシーを行、セグメントおよび表レベルで指定するための宣言構文が提供されます。
データベース管理者はこの機能を使用して、ストレージの異なる層の間や、異なる圧縮レベルの間でのデータの移動を自動化できます。この機能は、行レベル(ブロックレベル統計に集計)とセグメント・レベルでアクセスを追跡するヒート・マップ機能を利用します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
この機能で提供されるPL/SQLプロシージャを使用すると、すぐに、または少し時間を置いてADOポリシーを実施できます。
場合によっては、1つの層から別の層に、またはある圧縮レベルから別の圧縮レベルに、できるだけ迅速にデータを移動する必要があります。EXECUTE_ILMプロシージャによって、前もってスケジュールされていたADOポリシーに関係なく、これを実行する機能が提供されます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
ヒート・マップにより、個々の行の変更(ブロック・レベルに集計)と、パーティションまたは表レベルでの変更および問合せが追跡されます。
ユーザーは、新しいADO機能または独自のツールやスクリプトを使用して、自動化されたポリシードリブンのデータ移動と、ヒート・マップで追跡された情報に基づくデータ圧縮を実装できます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
この機能では、ADOポリシーを管理するためのPL/SQLインタフェースが提供され、これにはスケジューリング、優先度およびリソース管理などの機能が含まれます。
ユーザーによっては、ADOポリシーで実際にいつデータを移動するか、データ移動操作で消費されるシステム・リソースの量などを制御して、複雑な情報ライフサイクル管理(ILM)シナリオを実装する必要があります。この機能では、重要な本番ワークロードに悪影響を及ぼさないようにILMアクティビティを管理することができます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
この機能では、ADOポリシーを指定して、データベース内の各表の行レベルに圧縮を実装できます。圧縮が実装されるのは、データベース・ブロック内のすべての行が、評価されるポリシーに基づいて条件を満たす場合です。
この機能を自動セグメント・レベル圧縮層と組み合せることで、データベース管理者は、データベース内のデータの格納と管理の方法を細かく制御することができます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
この機能では、ADOポリシーを指定して、データベース内の各表のセグメント・レベルに圧縮を実装できます。
この機能を自動行レベル圧縮層と組み合せることで、データベース管理者は、データベース内のデータの格納と管理の方法を細かく制御することができます。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
インデータベース・アーカイブを使用すれば、ユーザーとアプリケーションは、個々の行のアーカイブ状態を設定できます。アーカイブ済としてマークされている行は、そのセッションでアーカイブ済データが表示されるようにしないかいぎり見えません。
インデータベース・アーカイブを使用すれば、アプリケーションのパフォーマンスを損なわずに、本番データベースにより多くのデータをより長い期間格納できます。さらに、アーカイブ済データは、問合せやバックアップのパフォーマンスを向上させるために、積極的に圧縮できます。アーカイブ済データに対する更新は、アプリケーションのアップグレード中は保留でき、アップグレードのパフォーマンスを大幅に改善します。
|
関連項目: 詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
次の項では、SecureFileの拡張について説明します。
このリリースでは、SecureFile LOBのパラレルDML (PDML)サポートに関する制約が取り除かれました。
この機能により、SecureFileはOracle DatabaseのPDML機能のパフォーマンスとスケーラビリティの利点を活用できるようになります。
|
関連項目: 詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
impdpコマンドラインの新しいパラメータ(およびPL/SQL DBMS_DATAPUMPパッケージの新しいオプション)によって、Oracle Data PumpがすべてのLOBをSecureFile LOBとして作成するように指示します。Oracle Database 12cリリース1 (12.1)から、デフォルトですべてのLOB列がSecureFile LOBとして作成されます。ただし、Oracle Data Pumpは、エクスポートされたデータベースとまったく同じように表を再作成します。したがって、エクスポートされたデータベースでLOB列がBasicFile LOBである場合、Oracle Data Pumpはインポートしたデータベース内でBasicFile LOBとして再作成しようとします。
この機能により、ユーザーは、SecureFile LOBとしてのLOBを強制的に作成でき、優れたパフォーマンスの最新機能に移行できます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
このリリースでは、互換性初期化パラメータが12.1以上に設定されてる場合、SecureFileがLOB記憶域のデフォルトになりました。
SecureFile機能は、データベースに構造化されていないデータを格納する際に最適なパフォーマンスを提供します。SecureFileを構造化されていないデータのデフォルトにすることで、構造化されていないデータを管理する際にデータベースの最高のパフォーマンスが実現されます。
|
関連項目: 詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)のデータベースの新機能について説明します。
次の項では、データベースの統合の機能について説明します。
この機能により、DBAはパラメータPROCESSOR_GROUP_NAMEを指定して、サーバー上のCPUの指定サブセットにデータベース・インスタンスをバインドできるようになります。Linuxでは、CPUの指定サブセットは、制御グループ(cgroups)と呼ばれるLinuxの機能を使用して作成できます。Solarisでは、CPUの指定サブセットは、リソース・プールと呼ばれるSolarisの機能を使用して作成できます。
この機能は主に統合のために役立ちます。大規模サーバーで統合を行う場合、CPUとメモリーの特定のサブセットにデータベースを制限することをお薦めします。この機能により、Oracle DatabaseインスタンスのCPUとメモリーの制約を簡単に有効にすることができます。
|
関連項目: 詳細は、『Oracle Databaseリファレンス』を参照してください。 |
全体トランスポータブル操作には次のものがあります。
マルチテナント・コンテナ・データベース(CDBs)の全体トランスポータブル・サポート:
Oracle Data Pumpの新しい全体トランスポータブル機能により、データベース全体を1つのOracle Databaseから別のOracle Databaseに移動できます。この機能を使用すれば、非CDB (Oracle Database 11gリリース2 (11.2.0.3)以上)をプラガブル・データベース(PDB)に移動できます。
この全体トランスポータブル機能を使用すれば、PDB (Oracle Database 12cリリース1 (12.1)以上)を別のPDBに移動できます。バージョン間、別のオペレーティング・システムやハードウェア・プラットフォームへの移動を行う場合に、これが必要になります。
非CDBの全体トランスポータブルのサポート
Oracle Data Pumpの新しい全体トランスポータブル機能により、データベース全体を1つのOracle Databaseインスタンスから別のインスタンスに移動できます。
この機能を使用すれば、非CDB (Oracle Database 11gリリース2 (11.2.0.3)以上)を別の非CDBに移動できます。後日、非CDBをCDBにトランスポートできます。PDBを非CDBへの移動にも全体トランスポータブル機能を使用できます。
全体トランスポータブル操作を使用すると、表データをアンロードおよび再ロードする必要と、ユーザー表領域の索引構造を再作成する必要がなくなるため、エクスポート時間と(特に)インポート時間を短縮できます。全体トランスポータブルでは、以前は複数の操作で移動する必要のあった非トランスポータブル表領域にあるメタデータやユーザー・データを移動するため、トランスポータブル表領域よりも自動化率が高まります。これにより、全体トランスポータブル機能は、データベースの新しいコンピュータ・システムへの移動や、Oracle Databaseの新リリースへのアップグレードを効率的に行うために役立ちます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
マルチテナント・アーキテクチャは、Oracle Database 12c リリース1 (12.1)の新機能です。1つのOracle Databaseオカレンス内に多数のPDBを含めることができます。PDBは、12.1よりも前の通常のデータベースとの完全な下位互換性を備えています。
PDBの利点は次のとおりです。
新しいデータベース、または既存データベースのコピーを高速でプロビジョニングします。
既存のデータベースを新しいプラットフォームに高速で再デプロイします(切断してから接続します)。
多数のデータベースに対して1回分のコストでOracle Databaseバージョンの迅速なパッチまたはアップグレードを行います。
PDBを切断してから、新しいバージョンの別のCDBに接続することで、パッチまたはアップグレードを行います。
1台のマシンで、個別のモノリシック・データベースとしてより多くのデータベース・インスタンスをPDBの形で実行できます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
CDBは、0個以上のPDBで構成されます。Recovery Manager (RMAN)は、CDB全体か1つまたは複数のPDBを一貫性のあるPoint-in-Timeにバックアップすることができます。さらに、個々の表領域またはデータ・ファイルを特定のPDBからバックアップすることができます。
新しい構文PLUGGABLE DATABASEが導入され、個々のプラガブル・データベースのバックアップとリカバリがサポートされるようになりました。
CDBユーザーは、新しいプラガブル・データベース・モデルのためにバックアップとリカバリ機能が必要です。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
現在、PDBを特定のPoint-in-Timeにリカバリすることができます。
これは統合のための高可用性拡張です。これによって、Point-in-Timeリカバリ機能がPDBに拡張されます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracle Resource ManagerはCDBレベルとPDBレベルでリソースを管理できます。CDB全体および個々のPDBにリソースを割り当てるCDBリソース・プランを作成できます。一部のPDBにより多くのリソースを割り当て、他のPDBにより少なく割り当てたり、すべてのPDBでリソースを等しく共有するように指定できます。
複数のデータベースを1つのデータベースに統合することが可能なマルチテナント・アーキテクチャの導入により、コンテナ・データベース内の各データベースが消費するリソースをCDB管理者が制御できるリソース・プラン機能が必要になります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
次の項では、データベース・スケジューラとOracle Enterprise Managerの統合および新しいエンタープライズ・クラスのグリッド・スケジューラの作成について説明します。
この機能では、Oracle Recovery Manager (RMAN)スクリプト、シェル・スクリプトおよびSQLスクリプトが最初からサポートされています。現在、これらのタイプのジョブのために多くのセットアップが必要であるため、エラーが発生する可能性があります。この機能により、ユーザーはジョブ定義で必要なジョブ・タイプを指定するだけですみます。
この機能によって使いやすさが向上し、ジョブ作成の複雑さが緩和されます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
次の項では、データベースのクローニングについて説明します。
CLONEDBでは、Oracle Databaseに統合されているシン・プロビジョニング・アプローチを使用して、ネットワーク接続ストレージ(NAS)上でデータベースのコピーを簡単に短時間で作成することができます。
本番データベースのクローニングは、アプリケーションやその周囲に対する変更を開発およびテストするために役立つ一般的な方法です。新しいオペレーティング・システム・リリース、ストレージ・ソフトウェアまたはアプリケーション・バージョンが本番環境にインストールされる前には、本番データを使用した徹底的なテストが必要です。通常は、本番データベースをテスト環境にコピーすることでこれを行います。テスト環境だけでなく、アプリケーション開発者がアプリケーションの作成、変更またはテストを行う開発環境にも本番データベースがコピーされます。このようなコピーのすべてでは、大容量の記憶域を割り当てて管理する必要があります。シン・プロビジョニングを使用すると、CLONEDBが本番データベースのクローンで必要とする記憶域容量が大幅に低減されます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
次の項では、Oracle Databaseユーティリティの新機能について説明します。
Oracle Data Pumpのエクスポートおよびインポートで使用できる新しいLOGTIMEコマンドライン・パラメータでは、エクスポートおよびインポート操作中に表示されるメッセージにタイムスタンプを付けるように指定できます。有効な値は、次のとおりです。
NONE: ステータス・メッセージまたはログ・ファイル・メッセージにタイムスタンプを付けません(デフォルトと同じ)。
STATUS: ステータス・メッセージにのみタイムスタンプを付けます。
LOGFILE: ログ・ファイル・メッセージにのみタイムスタンプを付けます。
ALL: ステータス・メッセージとログ・ファイル・メッセージの両方にタイムスタンプを付けます。
DBMS_DATAPUMP.SET_PARAMETERプロシージャにもLOGTIMEと呼ばれる新しいオプションがあり、有効な値は同じです。
タイムスタンプを使用すると、Oracle Data Pump操作の異なる処理間の経過時間を確認できるため、パフォーマンス問題を診断する場合や、将来の同じような操作の時間を見積もる場合に役立ちます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
Oracle Data Pumpコマンドは監査できるようになりました。これによって、データベースに対して実行される操作の詳しい監査が提供されます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
Data Pumpインポートのimpdpの新しいコマンドライン・オプション(およびPL/SQL DBMS_DATAPUMPパッケージの新しいオプション)を使用して、ユーザーが表の圧縮オプションを変更できます。
これはExadataマシンに移行する際に役立ちます。Exadataマシンでは、表の圧縮オプションが多くサポートされており、データベース・パフォーマンスが優れています。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
Oracle Data Pumpエクスポートのexpdpの新しいコマンドライン・オプションを使用して、Oracle Data Pumpダンプ・ファイルに使用される圧縮度を制御できます。また、同じオプションがPL/SQL DBMS_DATAPUMPパッケージにも追加されます。これによって、DBAが、データ圧縮にかける時間と、Oracle Data Pumpダンプ・ファイルのサイズのトレードオフを行うことが可能になります。
この機能により、DBAはエクスポート操作で使用されるリソースを制御できるようになります。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
Oracle Data Pumpエクスポートのexpdpの新しいコマンドライン・オプションを使用して、ビューを表としてエクスポートするようにユーザーが指定できます。つまり、ビュー定義をエクスポートするかわりに、Oracle Data Pumpが表定義をエクスポートしてから、ビューのすべてのデータをアンロードします。インポート時には、Oracle Data Pumpがダンプ・ファイルの表定義を使用して表を作成し、ビューからアンロードされたデータを表に挿入します。PL/SQL DBMS_DATAPUMPパッケージにも同様のオプションがあります。
この機能により、DBAがエクスポートできるものについて柔軟性が高くなります。現在のWHEREパラメータに比べて、ビューの場合はアンロードするデータベースのサブセットをDBAが自由に指定することができます。ネットワーク・モードのインポートでは、ビューのコンテンツのエクスポートを使用すれば、impdp QUERYオプションを使用するよりはるかにパフォーマンスがよくなります。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
impdpコマンドラインの新しいTRANSFORMオプションDISABLE_ARCHIVE_LOGGINGを使用して、Oracle Data Pumpは、データを表にロードするときと索引を作成するときのREDOロギングを無効にすることができます。また、PL/SQL DBMS_DATAPUMPパッケージの一部としても同じオプションが追加されます。REDOロギングが無効の場合は、Oracle Data Pumpインポート時のREDOログに必要なディスク領域が小さくなります。ただし、メディア障害からのリカバリを保証するために、DBAはインポートが完了してからRMANバックアップを実行する必要があります。
このパラメータが指定されていても、Oracle Data Pumpの他の操作ではREDOロギングが行われます。これには、CREATE INDEXを除くすべてのCREATE文とALTER文、およびインポート時にOracle Data Pumpによって使用されるマスター表に対するすべての操作が含まれます。
この機能によって、DBAが行う必要があるREDOログのメンテナンスが縮小されます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
この新しいオプションにより、パラメータENCRYPTION_PWD_PROMPT = [Y | N]がexpdpおよびimpdpコマンドラインに追加され、ユーザーはこれを使用して、Oracle Data Pumpクライアントがパスワードをプロンプトすべきかどうか、コマンドラインから値を取得すべきかどうかを指定できます。
これにより、パスワードがオペレーティング・システム・コマンドにさらされる可能性を減らし、オペレーティング・システムのスクリプトにデータベース・パスワードを含める必要をなくすことで、セキュリティが向上します。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
外部表とSQL*Loaderの両方を使用して、ネットワーク・ファイル記憶域(NFS)サーバーに格納されているファイルをロードできます。Oracle Direct NFS (dNFS)は、大きなNFSファイルに従来のNFSクライアントよりも高速でアクセスできる内部I/Oレイヤーです。SQL*Loaderと外部表は、大きな表のために自動的にこの新しいパッケージを使用します。ただし、SQL*Loaderのコマンドライン・パラメータと外部表のアクセス・パラメータを使用して、dNFSの使用を無効にすることもできます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
この新機能により、ダイレクト・パス・ロードの監査機能がデータベースに追加されます。この新機能により、ダイレクト・パス・ロード操作の監査を完全に制御することができます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
SQL*Loaderの新しいオプションでは、ユーザーがSQL*Loader制御ファイルを作成する必要がありません。かわりに、データ・ファイルのロード方法の指定にはコマンドライン・パラメータが使用され、SQL*Loaderでは、データをロードする最良のメソッドを自動的に選択します。現在、SQL*Loaderと外部表の両方に対するカンマ区切り値(CSV)形式のデータ・ファイルがサポートされています。
また、SQL*Loaderと外部表の新しいデフォルト・オプションを使用すると、SQL*Loaderの制御ファイルと外部表のアクセス・パラメータでのオプション指定の重複を最小限に抑えることができます。すべてのフィールドに同じオプションを指定するかわりに、オプションを1回指定してすべてのフィールドに適用させることができます。
SQL*Loaderの制御ファイルの作成は複雑になることもあります。SQL*Loaderでは、制御ファイルが自動的に生成され、生成された制御ファイルは、参照や将来の再利用のためにコピーが出力されます。CSVファイルなど一般的なデータ・ファイル形式についてSQL*Loader制御ファイルの必要性をなくすことで、ユーザーが容易に短時間でデータをロードできるようになります。
SQL*Loaderと外部ファイルの新しいデフォルト・オプションにより、SQL*Loader制御ファイルまたはORACLE_LOADERアクセス・パラメータ・リストを作成する必要があるユーザーにとって、そのための時間が短縮され、複雑さが緩和されます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
次の各項では、Oracle Database 12cリリース1 (12.1)の新しい高可用性機能について説明します。
次の項では、アプリケーション・コンティニュイティおよびトランザクション・ガードの機能について説明します。
エンド・ユーザーから停止をマスクする場合、アプリケーション開発者は基礎となるソフトウェア、ハードウェアおよび通信レイヤーの停止を明示的に処理する必要がありました。
Oracle Database 10gから、高速アプリケーション通知(FAN)によって、例外条件がアプリケーションに迅速に配信されました。ただし、FANおよび以前のOracleテクノロジでは、最後のトランザクションの結果がアプリケーションに報告されず、アプリケーションの観点から進行中の要求がリカバリされませんでした。結果として、停止がマスクされず、ユーザーに不便を強い、収益が失われました。ユーザーが意図せずに重複して品物を購入したり、1つの請求書に何回も支払う可能性もあります。複雑なケースでは、引き起こされた問題に対処するために、管理者が中間層をリブートする必要がありました。
アプリケーション・コンティニュイティは、アプリケーションに依存しない機能であり、アプリケーションの観点から不完全な要求のリカバリを試行し、システム、通信、ハードウェアの多くの障害および記憶域の停止をエンド・ユーザーからマスクします。
このプロトコルにより、エンド・ユーザー・トランザクションが1回しか実行されないことが保証されます。正常な場合にエンド・ユーザーがサービスの中断を体験するのは、続行しても意味がないときだけです。リプレイした場合、アプリケーションとクライアントからは、リクエストが少し遅れているかのようにリプレイの実行が見えます。負荷の高いシステムでも似た影響があります。データベースによるリクエストの実行が少し遅くなり、クライアントへのレスポンスが遅れます。
ほとんどの障害は隠されます。したがって、アプリケーションのエラー処理ロジックの呼出し回数が減少します。たとえば、頻繁ではありませんが、アプリケーションでエラーが発生したときに、ユーザーには何が起きたかわからないことや、ユーザーがデータを再入力しなければならないことがあります。あるいは、解決が困難な場合には、管理者が中間層を再起動して障害に対処する必要があります。
他の利点は次のとおりです。
エンド・ユーザー・エクスペリエンスの向上。
アプリケーション可用性の向上。
アプリケーション開発者の生産性向上。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
トランザクション・ガードは、計画済および計画外の停止と送信の繰返しの場合に、実行を1回以下にするためにアプリケーションで使用される汎用ツールを提供します。アプリケーションでは論理トランザクションID (LTXID)という新しい概念を使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。
停止後にアプリケーションをリカバリする際の根本的問題の1つは、クライアントに返送されたコミット・メッセージに継続性がないことです。クライアントとサーバー間に間隔がある場合、クライアントには通信の失敗というエラー・メッセージが示されます。このエラーでは次のことがアプリケーションに知らされません。すなわち、送信によってコミット操作が実行されたかどうか、もしくは、プロシージャ・コールが予定されたすべてのコミットおよびセッション状態変更を行って完了まで実行されたか、一部の動作は失敗したか、またはクライアントから切断したまま現在も実行中というさらに悪い状態になっているかということです。
最後の発行がコミットしたのか、まもなくコミットするのか、完了まで実行していないのかがわかならないと、アプリケーションがリプレイを試行し、重複してトランザクションを発行することにつながります。ソフトウェアが、すでに確定された変更を再発行しようとする可能性があるためです。
トランザクション・ガードがない場合、トランザクションが開始されており、コミットが発行されている場合、クライアントに返送されたコミット・メッセージに永続性がありません。トランザクションがコミットされたかどうかはクライアントにはわかりません。非トランザクション状態が不正確な場合、またはそのトランザクションがすでにコミットされている場合、トランザクションを再送信することはできません。コミットまたは完了情報の認識がないときに再発行を行うと、トランザクションが複数回適用されて、不正確な状態になることがあります。
トランザクション・ガードの利点は次のとおりです。
コミット結果を保持する最初のRDBMS。
すべてのトランザクションの結果の認識。
トランザクションを最大1回実行するツール。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
次の各項では、Oracle GoldenGateおよびSQL Applyに基づくレプリケーション・ソリューションの作成について説明します。
XStreamでは、拡張VARCHAR2データ型のネイティブ・サポートを提供します。XStreamでは、拡張VARCHAR2データ型を含む表に対する変更の取得または適用が可能です。
|
関連項目: 詳細は、Oracle Database XStreamのガイドを参照してください。 |
このリリースでは、適用プロセスの動作を制御するXStreamインバウンド・サーバーで使用できるパラメータが追加されています。新しいパラメータには、COMPUTE_LCR_ON_ARRIVALやOPTIMIZE_PROGRESS_TABLEが含まれます。COMPUTE_LCR_ON_ARRIVALパラメータは、XStream適用プロセスのためにSchedulingの依存性をいつ計算するかを制御します。OPTIMIZE_PROGRESS_TABLEパラメータは、適用進捗表を作成するためにローカルREDOログを使用して、適用進捗表のメンテナンスを最小限に抑えます。
これらの新しいパラメータを使用すると、データベース管理者がXStreamインバウンド・サービスのパフォーマンス・チューニングをさらに制御できるようになります。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
このリリースでは、取得プロセスの動作を制御する追加のパラメータをXStreamで使用できます。EXCLUDETAGパラメータは、GETAPPLOPSおよびGETREPLICATES取得パラメータとの組合せで使用され、特定のREDOタグ値を持つREDOログ・ファイルからの変更の取得を制御します。
XStreamには、REDOログ・ファイルから取得できる変更に対する追加のフィルタリング制御があります。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
パフォーマンスの最適化として、XStreamインバウンド・サーバーはトランザクションのCOMMITをソースから受信する前に、大規模なトランザクションを処理することができます。EAGER_SIZE適用パラメータは、この最適化を開始する最小サイズを制御します。大規模なトランザクションは、変更を適用するために追加のサーバーが必要になることがあります。
MAX_PARALLELISM適用パラメータは、適用プロセスで使用できる適用サーバーの最大数を制御します。
現在、大規模なトランザクションは、ソースの変更をターゲット・データベースで受信するとすぐに適用を開始できます。これによって、大規模なトランザクションのレプリケーションの待機時間が短縮される場合があります。
|
関連項目: 詳細は、Oracle Database XStreamのガイドを参照してください。 |
XStreamでは、重複除外を使用して、格納されたSecureFiles LOBの列への変更をサポートします。ロジカル・レプリケーションを使用するデータベースでは、拡張LOB重複除外を利用できるようになり、パフォーマンスの向上と記憶領域の節約の可能性があります。
|
関連項目: 詳細は、Oracle Database XStreamのガイドを参照してください。 |
XStreamのデータ型サポートが拡張され、XMLTypeデータ(リレーショナルまたはバイナリとして格納されたオブジェクト)も含むようになりました。XStreamアウトバウンド・サーバーとインバウンド・サーバーの両方でサポートされます。表に対するDML変更をXStreamで取得または適用することは、すべてのXMLTypeデータ記憶域タイプでサポートされます。
|
関連項目: 詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』および『Oracle Database XStreamガイド』を参照してください。 |
次の項では、ロード・バランシングを提供する機能について説明します。これは、Oracle RACと単一インスタンス・データベースの分散環境(Oracle Active Data GuardとOracle GoldenGateを使用して相互接続)のための、Oracleのロード・バランシングとフェイルオーバーに似ています。
グローバル・データ・サービス(GDS)は、Oracle Databaseの新機能で、Oracle RACでのみ使用可能なサービスの概念を、Oracle RAC、Active Data GuardおよびOracle GoldenGateの組合せを含むグローバルにレプリケートされた構成にまで拡張します。これにより、このグローバルにレプリケートされた構成内のどこにでもサービスをデプロイでき、ロード・バランシング、高可用性、データベースの親和性などをサポートします。
Oracle RACのサービス概念をこれまで利用していたユーザーは、同じ自動ワークロード管理という利点を自らのActive Data GuardまたはOracle GoldenGate構成に拡張することができます。同様に、単一インスタンスのActive Data Guardまたは Oracle GoldenGateユーザーは、サービスや自動ワークロード管理の利点をレプリケート構成のために十分に活用できるようになりました。
|
関連項目: 詳細は、『Global Data Services概要および管理ガイド』を参照してください。 |
Oracle Call Interface (OCI)高可用性インフラストラクチャの拡張は次のとおりです。
フォアグラウンド・プロセス障害のTransparent Application Failover (TAF)のサポート。
インテリジェント再接続のサポート。接続オブジェクト(たとえば、モジュール、アクション、実行コンテキスト識別子(ECID)、論理トランザクション識別子(LTXID)およびクライアントID)の、前のセッションからリカバリ済セッションへの復元も含みます。
ドキュメントのグローバル・データベース・サービス(GDS)のサポート。
これらの機能により、Oracle 12c Databaseに接続するCおよびC++アプリケーションに高可用性サービスが提供されます。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
次の項では、Oracle ASMのレジリエンスの改善点について説明します。
Oracle ASMのディスク修正は、標準または高の冗長性のディスク・グループにおいて、論理データの破損をチェックして自動的に修復する新機能です。この機能は、本番システムの通常のI/Oにまったく影響を与えないように設計されています。修正プロセスは、ミラー・ディスクを使用して論理破損を修復します。ディスク修正は、I/Oオーバーヘッドを最小限に抑えるためにOracle ASMのリバランスを利用します。
Oracle ASMディスク修正は、データを事前に読み込むことで可用性と信頼性を向上します(別の方法ではデータを読み込めない場合があります)。潜在的なエラーや破損もOracle ASMのディスク修正で検出および修正され、同時にデータの冗長性も保たれます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
次の項では、オンライン操作の新機能について説明します。
Oracle Database 11gリリース2 (11.2)、非エディション・オブジェクトはエディション・オブジェクトに依存することができませんでした。このルールのために問題が発生するのは、エディション化する必要があるオブジェクトの所有者が、エディション化できないタイプのオブジェクトを所有しており、そのオブジェクトがエディション化可能なタイプのオブジェクトに依存していた場合です。ALTER USER ENABLE EDITIONSコマンドは失敗します。または、FORCEキーワードが使用された場合は、違反している依存側が無効になります。対処方法は、違反している依存の親を新しいスキーマで再確立して、所有者をエディション対応にしないことだけでした。
Oracle Database 12cリリース1 (12.1)では、タイプがエディション化可能であるオブジェクトのエディション状態は、個々のオブジェクトという細かいレベルで制御されます。
また、マテリアライズド・ビュー、索引および表列(以前はエディション・ビューまたはエディションPL/SQLファンクションへの参照によって違反が発生した)では、依存の事実によって、エディション・オブジェクトが検出されるエディションを指定できます。現在は、エディションに基づく再定義を使用するアプリケーションの準備が容易になりました。
|
関連項目: 詳細は、『Oracle Database開発ガイド』を参照してください。 |
いくつかのスキーマ・メンテナンスDDL操作でブロッキング・ロックが必要なくなったため、操作が非侵入型になり、透過的にオンラインで使用できるようになりました。改善されたスキーマ・メンテナンスDDL操作は次のとおりです。
DROP INDEX ONLINE
DROP CONSTRAINT ONLINE
SET UNUSED COLUMN ONLINE
ALTER INDEX UNUSABLE ONLINE
ALTER INDEX [VISIBLE | INVISIBLE]
内部ブロッキング・ロックの削除により、アプリケーション開発(特にアプリケーションの移行)が単純になり、堅牢性が高くなります。これによって、多くの一般的なスキーマ・メンテナンス操作においてアプリケーションの中断を回避できます。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
列の表示プロパティをユーザーが制御できます。非表示列は、SELECTリストで明示的に指定されないかぎり表示されません。表の汎用アクセス(SELECT * FROM 表またはDESCRIBEなど)では、非表示列は見えません。
非表示の列という概念により、Oracleのエディションベースの再定義によって提供されるオンライン・アプリケーション移行がさらに容易になります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ロック・タイムアウトを秒数で指定できるようになり、この間にFINISH_REDEF_TABLEで、ソースと暫定表のスワップのための排他的ロックの取得が試みられ、タイムアウトが期限切れになれば動作が終了します。
この機能によって、FINISH_REDEF_TABLEの柔軟性が向上し、ユーザー指定の秒数の間待機してから終了します。したがって、ユーザーがいつまでも待つこともなく、オンライン再定義セッションを強制的に終了する必要もなくなります。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
列のデフォルト値は、NULLとして指定された列のデータ・ディクショナリで管理されます。
DEFAULT値を含む新しい列を追加すると、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。そのため、既存のデータ量にかかわらず1秒未満でスキーマの変更が行えるだけでなく、領域が消費されることもありません。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
このリリースでは、データ・ファイルが開いてアクセスされているときに、オンラインで移動することができます。
データ・ファイルをオンラインで移動できるということは、ユーザーがシステムにアクセスしているときに、多くのメンテナンス操作(別のストレージ・デバイスへのデータの移動、Oracle Automatic Storage Management (Oracle ASM)へのデータベースの移動など)を実行できることを意味します。これによってサービスの継続性が保証され、稼働時間に関するサービス・レベル合意(SLA)を満たすことができます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
索引の特徴が異なる場合は、同一の列セットに対して複数の索引を作成できます。次の特徴によって区別されます。
Bツリーまたはビットマップ
パーティション化計画の違い
一意または非一意
同一の列セットに複数の索引を作成できる機能を提供することで、透過的かつシームレスなアプリケーション移行が可能になります。既存の索引を削除してから別の属性で索引を再作成する必要はありません。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
オンライン再定義では、1回の再定義セッションで複数のパーティションの再定義がサポートされます。この機能によって、複数のパーティションを再定義するまでの完了時間が短縮されます。また、この間に基礎となる表にアクセスすることもできます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
REDEF_TABLEは、DBMS_REDEFINITIONパッケージ内の新しいプロシージャで、これを使用すれば、次の特定の条件のもと、1つの操作で簡単に表またはパーティションの再定義ができます。
表またはパーティション、索引およびLOBの列の表領域の変更。
表領域またはパーティション、索引キーおよびLOBの列の圧縮タイプの変更。
LOBの列のSTORE AS SECUREFILEまたはBASICFILE。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
オンライン再定義では、仮想プライベート・データベース(VPD)ポリシーが定義されている表を再定義できます。この機能により、このような表の再定義のための停止時間がなくなります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
次の項では、Oracle Data Guardの拡張について説明します。
Data Guard構成の管理が拡張され、ヘルス・チェック管理、エラー・レポートおよび問題の診断と解決が追加されています。
この機能により、Data Guard構成の管理が簡素化され、生産性および信頼度が向上し、その結果管理コストが低減され、高可用性がいっそう向上します。
|
関連項目: 詳細は、『Oracle Data Guard Broker』を参照してください。 |
Oracle Data Guardブローカを使用して、カスケード・スタンバイ・データベースを含む構成を管理できるようになりました。この機能によって、カスケード・スタンバイ・データベースを含むData Guard構成での管理の生産性が向上します。
|
関連項目: 詳細は、『Oracle Data Guard Broker』を参照してください。 |
Data Guardの最大可用性では、NOAFFIRM REDO転送属性がサポートされます。REDOがメモリーで受信されるとすぐに、スタンバイ・データベースは受領通知をプライマリ・データベースに返します。スタンバイ・データベースでは、リモート・ファイル・サーバー(RFS)によるスタンバイREDOログ・ファイルへの書込みを待っていません。
この機能により、最大可用性とSYNC REDO転送を使用するData Guard構成でのプライマリ・データベースのパフォーマンスが向上します。高速同期により、最大可用性構成内のプライマリ・データベースが、スタンバイ・データベースでの遅いI/Oによるパフォーマンスの影響から隔離されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
この機能では、1つのDDLコマンドを実装して、Data Guardロール・トランジション(スイッチオーバーとフェイルオーバー)を実行します。これにより、前のリリースで必要だった複数のコマンドが置き換えられます。これにより、高可用性のための単純かつ高速のロール・トランジションが実現します。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
以前のリリースでは、SQLコマンドラインを使用してData Guard構成を作成する際、デフォルト構成は、スタンバイ・データベース上のアーカイブ済ログ・ファイルのREDOを適用することになっていました。Oracle Database 12cリリース1 (12.1)では、デフォルト構成はリアルタイム適用を使用することになり、REDOはスタンバイREDOログ・ファイルから直接適用されます。
フェイルオーバーが必要な場合に、スタンバイ・データベースへの適用を待機するREDOのバックログがないと、フェイルオーバーの際のリカバリ時間が短縮されます。また、アクティブなData Guardユーザーは最新のデータを見ることができます。この拡張により、以前のリリースで必要だった追加の手動構成(および管理者がデフォルト設定を認識するという要件)はなくなりました。また、このために、デフォルトのSQL*Plus構成が、Data Guardブローカによって使用されるデフォルト構成と同じになります。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
以前のリリースのOracle Data Guardブローカでは、スイッチオーバー操作中に問題が発生した場合、問題を解決し、中断した時点からスイッチオーバー操作を再開する適切な方法はありませんでした。Oracle Data Guardブローカは、再開可能なスイッチオーバーの機能を導入しています。予期したように動作しないときにスイッチオーバー操作を進められる柔軟性も向上しました。
計画メンテナンス中にも高可用性が維持されます。スイッチオーバー操作中に問題が発生した場合でも、問題を解決して、中断した時点からスイッチオーバーを再開することができます。このため、計画メンテナンス操作中の停止時間が最小限に抑えられます。
|
関連項目: 詳細は、『Oracle Data Guard Broker』を参照してください。 |
ログイン試行失敗のインメモリー表で動的なユーザー情報を追跡するために、新しいビューRO_USER_ACCOUNTが追加されました。この情報は、ユーザーのアクセスをロックするために使用されます。また、必要であれば、DBAはこの情報に基づいて、スタンバイ・データべスでアカウントを再有効化することができます。この機能により、Active Data Guardスタンバイ・データベースのセキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Databaseリファレンス』を参照してください。 |
この機能によって、本番データベースからActive Data Guardスタンバイ・データベースに移すことができる読取り専用アプリケーションの数が増加します。Active Data Guardスタンバイ・データベースが読取り専用モードで開いている場合でも、変更を行わずに、レポート・アプリケーションがスタンバイ・データベースのグローバル一時表に書き込みができるようになりました。
Active Data Guardスタンバイへのレポートのオフロードにより、プライマリ・データベースのパフォーマンスが向上し、プライマリおよびスタンバイの両システムを常に利用することで、生産能力が増加します。これにより、障害時リカバリ・システムの投資収益率が上がります。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
この機能により、Active Data Guard環境での順序のサポートが強化され、読取り専用のレポート作成をActive Data Guardスタンバイ・データベースにオフロードしやすくなりました。プライマリ・データベースで作成されたグローバル順序に、スタンバイ・データベースからアクセスできるようになりました。割り当てられた順序番号は、Data Guard構成全体で一意です。
さらに、セッション順序と呼ばれる新しいタイプの特殊な順序が、セッションで認識できるグローバル一時表で使用するために提供されています。1つのセッション順序が、セッション全体ではなく、1セッション内でのみ一意の順序番号の範囲を返します。
この新機能により、プライマリ・データベースからActive Data Guardスタンバイに簡単にオフロードできるレポート作成アプリケーションの範囲が拡張され、一意の順序番号が必要なレポートを含めることができるようになりました。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
REDOを他のスタンバイ・データベースにカスケードするスタンバイ・データベースは、プライマリ・データベースからREDOを受信するとすぐに、スタンバイREDOログ・ファイルから直接REDOを送信できます。カスケードされたスタンバイ・データベースは、リアルタイムでREDOを受信します。REDOの送信前にスタンバイREDOログ・ファイルがアーカイブされるのを待つ必要がなくなりました。
この機能により、カスケード・スタンバイ・データベースが、プライマリ本番データベースと同じ最新状態であることが保証されます。カスケード・スタンバイ・データベースが障害時リカバリで使用される場合、他のスタンバイ・データベースとほとんど同じリカバリ・ポイントの目標を達成できます。読取り専用問合せおよびレポートにより、最新の結果が返されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
遠隔同期は、データ損失0の保護をリモート・スタンバイ・データベースにまで拡張し、プライマリ・データベースのWANネットワーク待機時間のパフォーマンスに対する影響を回避するために使用されます。プライマリ・データベースでは、遠隔同期インスタンスと呼ばれる軽量インスタンス(1制御ファイルと複数のログ・ファイル、データ・ファイルなし、メディア・リカバリなし)に同時に送信します。遠隔同期インスタンスでは、次にREDOを非同期的に、フェイルオーバー・ターゲットであるリモート・スタンバイ・データベースに転送します。その他の遠隔同期機能には、最大29のリモート宛先を直接処理する機能、WAN全体での効率的な送信のためにOracle Advanced Compressionを利用してREDOを圧縮する機能があります。遠隔同期は、Data Guardロール・トランジションに関しては、管理者に対して透過的です。Data Guard構成に使用された同じスイッチオーバーまたはフェイルオーバー・コマンドは、遠隔同期インスタンスで処理されるリモート・スタンバイ・データベースをプライマリ本番ロールに遷移します。
遠距離間でのデータ損失0を達成できます。遠隔同期インスタンスは、プライマリ・データベースに対して、同期転送がアプリケーションのパフォーマンスに影響を与えない距離内に配置されます。遠隔同期では、すべての通信をリモート・スタンバイ・データベースにより処理し、データ損失0のフェイルオーバー実行時には透過的です。また、遠隔同期により、本番データベースで、複数のリモート宛先およびREDO転送圧縮処理のオーバーヘッドが軽減されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
次の項では、Oracle Databaseのローリング・アップグレードについて説明します。
このリリースでは、Data Guard SQL ApplyのネイティブREDOベース・レプリケーションが追加され、データベース(一時ロジカル・スタンバイ)のローリング・アップグレードがサポートされます。データ型には、バイナリXMLとして格納されるXMLType、オブジェクトリレーショナル形式で格納されるXMLType、オブジェクトおよびコレクション、Database File System (DBFS)、XDB、Oracle Spatial and Graph、Oracle Text、Oracle Multimedia、Label SecurityおよびOracle SecureFiles (重複除外およびフラグメント操作)が含まれます。
Data Guardデータベース・ローリング・アップグレードにより、ローリング方式で新しいデータベース・リリースまたはパッチ・セットへのアップグレードを行うことができ計画停止時間が短縮されます。このようなアップグレードでのデータベースの合計停止時間は、Data Guardスイッチオーバーを実行するために必要な短い時間に制限されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
XML DBリポジトリでは、Data Guardローリング・アップグレードがサポートされます。
XML DBリポジトリは、Data Guardローリング・アップグレードの制限事項ではなくなりました。Oracle Databaseは、新しいパッチ・セットまたはデータベース・リリースにローリング方式でアップグレードできるようになり、様々なユーザーのOracle Databaseデプロイメントで計画停止時間が最小限に抑えられます。
|
関連項目: 詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
Oracle Data Guardデータベース・ローリング・アップグレード・プロセスでは、アップグレードのターゲットであるスタンバイ・データベースが、プライマリ・データベースのREDOを引続き受け取ることができ、データ保護が維持されます。この間、スタンバイ・データベースはアップグレード・モードで開いています。
これにより、同じレベルのデータ保護を提供するために、別のアーカイブ・ログ・リポジトリを作成および保守する必要がなくなり、管理の複雑さが緩和されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Oracleアドバンスト・キューイング(AQ)を使用するデータベースは、Data Guardデータベース・ローリング・アップグレードを使用してローリング方式で新しいOracle Databaseリリースおよびパッチ・セットにアップグレードできます(一時ロジカル・スタンバイ・データベースのみ)。ローリング・アップグレードは、Oracle Database 12cリリース1 (12.1)からサポートされるようになりました。
Data Guardデータベース・ローリング・アップグレードにより、ローリング方式で新しいデータベース・リリースまたはパッチ・セットへのアップグレードを行うことができ計画停止時間が短縮されます。このようなアップグレードでのデータベースの合計停止時間は、Data Guardスイッチオーバーを実行するために必要な短い時間に制限されます。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
現在、Oracle Data Guardブローカではデータベース・ローリング・アップグレードがサポートされます。この機能により、Data Guardブローカ構成を保存することができ、アップグレードの完了後にブローカ構成を再構築する必要がなくなります。
|
関連項目: 詳細は、『Oracle Data Guard Broker』を参照してください。 |
プライマリ・データベースで作成されるOracle Schedulerジョブは、一時ロジカル・スタンバイ・データベースにレプリケートされます。これにより、Data Guardの使用方法が単純化され、新しいOracle Databaseリリースおよびパッチ・セットにローリング方式でアップグレードできます(一時ロジカル・スタンバイ・データベースのみ)。
Data Guardデータベース・ローリング・アップグレードにより、ローリング方式で新しいデータベース・リリースまたはパッチ・セットへのアップグレードを行うことができ計画停止時間が短縮されます。このようなアップグレードでのデータベースの合計停止時間は、Data Guardスイッチオーバーを実行するために必要な短い時間に制限されます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Active Data Guardには、いくつかの新しいPL/SQLパッケージとDDLコマンドが備わり、新しいOracleパッチ・セット、データベース・リリースへのデータベース・ローリング・アップグレードを実行する以前の手動ステップが自動化され、または他の計画メンテナンスが実行されます。このプロセスは、前バージョンのプライマリおよびフィジカル・スタンバイ・データベースから始まり、新バージョンのプライマリおよびフィジカル・スタンバイ・データベースの両方で終わります。自動化には、本番の新バージョンへのスイッチオーバーの処理が含まれます。また、プロセスのすべてのステップでも拡張検証が実行されます。問題が発生した場合、ユーザーは、エラーを修正してアップグレードを再開するか、構成の元の状態にロールバックするかのいずれかを選択できます。
Active Data Guardを使用するローリング・アップグレードにより、管理の労力は軽減され、データベース・ローリング・アップグレード実行の信頼性が向上します。ユーザーは、計画メンテナンスの停止時間の短縮化により、管理コストの低減および可用性の向上の恩恵を受けます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
SQL Applyの拡張データ型サポート(EDS)によって、SQL Applyで選択されたデータ型のレプリケーションが可能になります。ネイティブのREDOベース・レプリケーションは必要ありません。EDSでは、SDO_GEOMETRY、XMLType (オブジェクトリレーショナル形式で格納)、XMLType (バイナリXMLとして格納)、オブジェクト、およびVARRAY列を含むオブジェクトがサポートされます。
EDSにより、データベースに含まれるデータ型についてSQL ApplyがREDOベースのレプリケーションをまだサポートしていないケースでも、ユーザーはローリング・アップグレードを使用して、計画停止時間を短縮し、可用性を向上させることができます。SQL Applyがそれらのデータ型のサポートを今後のOracle Databaseリリースで追加した際には、REDOベース・レプリケーションに円滑に移行することができます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
SQL Applyでは、Oracleオブジェクトおよびコレクション、バイナリXMLとして格納されたXMLType、およびオブジェクトリレーショナル形式で格納されたXMLTypeをサポートします。この機能により、SQL Applyで非スカラー・データ型を持つデータベースに対するローリング・アップグレードをサポートする柔軟性が高まります。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
このリリースでは、SQL Applyを使用したすべてのXMLTypeストレージ・モデル用のXMLType表および列のレプリケーションが有効です。
この機能では、安全かつセキュアな方法で、XMLコンテンツをデータベース・インスタンス間でレプリケートできます。従来のリレーショナル・データのレプリケートにすでに使用されている、実績あるテクノロジが使用されます。XMLコンテンツとリレーショナル・コンテンツを同時にレプリケートすることができます。複雑でコストのかかるXMLコンポーネントの変換を実行する必要はありません。この機能により、ユーザーがOracle Databaseに求める極めて高いレベルの可用性が必要な場面で、XMLコンテンツを管理するためにXMLTypeを使用できるようになります。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
この機能により、SQL ApplyでSecureFiles LOB列の重複除外がサポートされます。SQL Applyは、利用制限なしでSecureFiles LOBを使用するOracle Databaseのローリング・アップグレードに使用できます。
|
関連項目: 詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
次の項では、Oracle Databaseアドバンスト・キューイング(AQ)の改善点について説明します。
Oracle Streamsアドバンスト・キューイング(AQ) JMSでは、Oracle Database 12cリリース1 (12.1)からパーティション表が使用されます。Oracle Java Message Service (JMS)メッセージは、1行ずつの削除ではなくパーティションの切り捨てによってパージされます。この機能により、パフォーマンスが向上し、オーバーヘッドが減少します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
AQ Java Message Service (AQ JMS)リスナーでは、新しいJMSメッセージをリスニングする専用のオープン接続が必要でなくなりました。複数のキューの間のポーリングは必要ありません。この機能により、AQ JMSのパフォーマンスとスケーラビリティが向上し、オーバーヘッドが減少します。
AQ JMSでは、以前のリリースと異なる優先度、例外キュー、およびメッセージ有効期限をサポートします。この機能により、AQ JMSのパフォーマンスが向上し、オーバーヘッドが減少し、標準に適切に準拠できるようになります。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
このリリースでは、トランザクションの非永続キューが、永続キューによりエミュレートされるかわりに、AQ JMSでサポートされます。
この機能により、AQ JMSのパフォーマンス、スケーラビリティ、オーバーヘッドの縮小および標準準拠が向上します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
Oracle RACでのアドバンスト・キューイング(AQ)は、インスタンス間での不必要なブロック交換を避けるために、共有されるようになりました。チューニングできるメッセージの転送もOracle RACでサポートされます。この機能によりAQのパフォーマンスとスケーラビリティが向上します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
AQルール・エンジンが拡張され、BITAND、CEIL、FLOOR、LENGTH、POWER, CONCAT、LOWER、UPPER、INSTR、SYS_CONTEXTおよびUIDなどの式の評価が速くなりました。この機能によりAQのパフォーマンスとスケーラビリティが向上します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
ルール・エンジンによって結果キャッシュが導入され、一般的に使用される多くのルールのパフォーマンスが向上しています。同じ属性の式がすでに評価されている場合、結果キャッシュによって評価フェーズが省略されます。この機能により、ルール評価の結果をキャッシュすることで、パフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
現在、Oracle Streamsアドバンスト・キューイング(AQ)のキュー表はパーティション化されています。パーティション表は、AQ(特にOracle RACまたはExadataの)を拡張して、パフォーマンスを向上させる土台を形成します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
AQの表は少なくなり、共有キューをサポートするためのオブジェクトをサポートするようになりました。この機能により、パフォーマンス、スケーラビリティおよび管理性が向上します。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。 |
次の項では、Recovery Manager (RMAN)の改善点について説明します。
アクティブDUPLICATEでは、補助データベースで実行されるネットワーク対応のリストア方法を使用して、ソース・データベースをクローニングします。これは、以前のリリースでソース・データベースで実行されていたイメージ・コピーベースの方法とは対照的です。アクティブDUPLICATEでは、SECTION SIZEオプションがサポートされ、補助データベース上の複数のチャネルにわたってパラレルにリストアされるサブセクションにデータ・ファイルを分割します。アクティブDUPLICATEは、リストア・フェーズ中の圧縮をサポートします。
この新機能の利点は次のとおりです。
補助データベースの複数のチャネルにリストア・ワークロードを均等に分散することで、大きなデータ・ファイルが含まれるデータベースでアクティブな複製にかかる時間を短縮します。
データ転送操作で圧縮を使用してネットワーク帯域幅をさらに有効に利用することで、アクティブな複製にかかる時間を短縮します。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
BACKUPおよびRESTOREコマンドには、クロス・プラットフォームの互換性のあるバックアップを作成して、別のプラットフォームでリストアするための新しいオプションが追加されました。
この機能では、クロス・プラットフォーム・トランスポータブル表領域とクロス・プラットフォーム・トランスポータブル・データベースを使用する方法で、プラットフォーム間でデータを移行して、操作の複雑さが緩和されます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
この機能により、リカバリされたクローン・データベースを自動的に開くことができないようになります。このため、NOOPENオプションを使用する前にデータベースの設定変更を実行できます。たとえば、場合によっては、クローン・データベースを開く前に、ブロック変更トラッキングやフラッシュバック・データベース設定を変更する必要があります。この機能は、アップグレード・スクリプトの実行前にデータベースをRESETLOGSによってオープンできないアップグレードの場合でも役に立ちます。
このような機能拡張により、DUPLICATEの際の柔軟性が高くなり、アップグレード・シナリオでの使用方法が広がります。たとえば、NOOPENオプションを使用すると、アップグレード手順においてDUPLICATEで新しいデータベースを作成することができます。データベースは、アップグレード・モードで開いて、その後アップグレード・スクリプトを実行できる状態になっています。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
イメージ・コピーは、SECTION SIZEオプションを使用して取得できます。このオプションでは、複数のチャネルで並行してバックアップできるサブセクションにデータ・ファイルが分割されます。この機能により、大きなデータ・ファイルのイメージ・コピー作成時間が短縮され、特にExadata環境で便利です。
また、バックアップ以外のユース・ケースでも完了時間が短縮されます。たとえば、トランスポータブル表領域の手順におけるファイルのコピーや、アクティブな複製によるクローンの作成などです。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
増分バックアップは、データ・ファイルを複数チャネルにわたってパラレルにバックアップできるサブセクションに分割するSECTION SIZEオプションを使用して取ることができます。これにより、大きなデータ・ファイルの増分バックアップ時間が短縮され、特にExadataおよびクラウド環境のバックアップで便利です。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
RESTORE操作では、ネットワーク上でデータベースからデータベース(たとえば、物理スタンバイ・データベースからプライマリ・データベース)にデータ・ファイルをコピーできます。ネットワーク対応のリストアでは、圧縮とマルチセクションのオプションもサポートされます。
RESTORE操作により、データ転送サイズを縮小し、大きなデータ・ファイルのリストア・ワークロードを複数チャネルで適切に並列化することで、データベースからデータベースへのデータ・ファイルのコピー時間が短縮されます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery Manager (RMAN)コマンドライン・インタフェースが次のように拡張されています。
コマンドラインでSQLをそのまま実行できます。SQLコマンドは必要ありません。
SELECT文がサポートされます。
表とビューに対するDESCRIBEコマンドがサポートされます。
このような機能拡張により、SQLをRMANセッションで実行する際の使いやすさが向上します。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
バックアップ・モードでは、大規模データベース環境での手順がより複雑になることに加えて、REDOにブロック全体のイメージを書き込むために、追加のシステムおよびI/Oオーバーヘッドが必要になる可能性があります。次の条件を満たすサードパーティのストレージ・スナップショットは、取得するときにデータベースをバックアップ・モードにする必要がありません。
データベースのクラッシュと、スナップショットのポイントが一致している場合。
スナップショット内で各ファイルの書込み順序が保存されている場合。
スナップショットが完了した時刻がスナップショットに格納されている場合。
新しいRECOVERコマンド・キーワードのSNAPSHOT TIMEが、一貫性維持点までスナップショットをリカバリするために導入され、Point-in-Timeリカバリの追加の手動手順が必要なくなりました。
このオーバーヘッドには、追加のREDOのロギングと完全なデータベース・チェックポイントの実行が含まれます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery Manager (RMAN)では、新しいRECOVER TABLEオプションを使用すると、ディスクまたはテープ上の既存のバックアップから1つの表または一連の表をリストアおよびリカバリできます。
必要な表領域をディスクの別の場所に手動でリストアおよびリカバリし、必要な表をエクスポートしてから元のデータベースにインポートする方法に対して、このオプションを使用すると、1つの表または一連の表を既存のバックアップからリカバリすることができ、時間が短縮され、ディスク領域も縮小されます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)の新しい管理機能について説明します。
次の項では、自動パフォーマンス管理機能について説明します。
Enterprise Manager Database Express 12cは、Oracleデータベースを管理するためのWebベース・ツールです。これはすぐに利用できるように構成され、すべてのデータベースに同梱されています。また、非常に軽量であり、JVMまたはアプリケーション・サーバーなど特別なインストールは必要ありません。Enterprise Manager Database Expressでは、基本のデータベース管理タスク(データベースの構成と管理、領域管理、ユーザーとロールの管理、パフォーマンス管理など)を実行するための直観的な対話型ユーザー・インタフェースが提供されます。
Enterprise Manager Database Expressでは、関連するデータベース・パフォーマンス画面がデータベース・パフォーマンス・ハブと呼ばれるビューに統合されるため、データベースのパフォーマンス診断が大幅に単純化されます。DBAは、複数のディメンションでのデータベース・パフォーマンスの現在のリアルタイム・ビューと履歴ビュー(データベース・ロード、監視対象のSQLおよびPL/SQL、アクティブ・セッション履歴(ASH)など)を、選択した期間について1ページの1つの統合ビューで確認することができます。
|
関連項目: 詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
この機能により、インスタンスがPGA_AGGREGATE_LIMITパラメータを使用して割り当てることができるプログラム・グローバル領域(PGA)の合計容量が制限されます。インスタンスが、PGA_AGGREGATE_LIMITの容量のPGAを割り当てた場合、割り当てられたPGAの最大容量を含むセッションは制限が順守されるまで停止します。
強い制限がない場合、過剰なページングでインスタンスが不安定になることがあるため、この機能は統合において重要です。過剰なページングは、Oracle RACデータベースでのインスタンス削除の主な原因の1つであり、パフォーマンスと安定性の多数の問題を引き起こすことがあります。
|
関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
リアルタイム・データベース操作の監視により、データベース管理者は長時間実行ジョブのパフォーマンスの問題の監視とトラブルシューティングを簡単に実行できます。この機能によって、バッチ・ジョブ、ETL (抽出、ロードおよび変換)操作またはスケジューラ・ジョブなど長時間実行するデータベース操作を把握することができ、管理者は操作によっていつ何が行われるかを正確に認識できます。これは、データベース操作を構成するSQLおよびPL/SQLコマンドを時間経過とともに追跡して実現されます。
この結果、DBAはデータベース操作の問題点を原因のSQLまたはPL/SQLまで簡単にたどることができ、さらに詳しく分析できます。
|
関連項目: 詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 |
ランナウェイ問合せはデータベースによくある問題です。適切に管理しないと全体的なパフォーマンスに悪影響を及ぼすことがあります。現在、Resource Managerによって情報が提供され、問題を含む問合せが予防的に管理されます。各コンシューマ・グループでヒット制限に到達した最新のSQLコマンドをDBAが確認するための新しいビューがあります。このようなビューは自動ワークロード・リポジトリ(AWR)に保存され、事後分析を行うことができます。また、DBAが問題のあるSQL実行計画に対して先制措置を取ることができる新機能もあります。
この結果、リソースを使用しすぎた問合せに対して後で処理するのではなく、被害が発生する前にDBAがランナウェイ問合せを未然に防ぐことができます。
|
関連項目: 詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseには、Automatic Database Monitor (ADDM)、リアルタイムADDM、期間比較ADDMなど、多くの自動パフォーマンス診断アドバイザがあり、DBAはこれらを使用してパフォーマンスの問題を診断および解決することができます。ADDMでは1時間以内(デフォルト)に検出された問題がレポートされますが、クリティカルな問題が発生した場合には、すぐにDBAに通知する必要があります。Spot ADDMは新しいアドバイザです。データベースでパフォーマンスの問題が検出され始めると自動的にトリガーされ、問題の根本原因を特定しようとします。Spot ADDMをトリガーする問題の中には、CPUの高負荷またはI/Oバウンドのシナリオが含まれます。Spot ADDMの結果は、自動ワークロード・リポジトリ(AWR)にレポートとして保存されます。
このような問題を認識することで、DBAは問題の連鎖にすぐに対処し、最終的に壊滅的な障害を招く可能性がある問題を防ぐことができます。
|
関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
次の項では、データベースのテスト機能について説明します。
企業が本番以外で使用する機密データをマスクするには、本番データベースのコピーを作成してデータをマスクしてから、テスト担当者や開発者などの非本番ユーザーと共有する必要がありました。ソースでのマスクや、ソース・データベースのサブセットに対するマスクを利用すると、企業は安全でサイズの小さいテスト・システムを本番データベースから直接プロビジョニングすることができます。本番データベースの完全コピーは必要ありません。マスク操作またはサブセット操作、または両方の実行を選択して、1つのワークフローでテスト・データベースをプロビジョニングできます。
ソースでのマスクや、ソースのサブセットに対するマスクにより、テスト・システムをプロビジョニングするときに重要な本番データがソース・データベースから流出せず、データ・プライバシ・ポリシーも順守されます。
|
関連項目: 詳細は、『Oracle Databaseテスト・ガイド』を参照してください。 |
企業は、Oracleアプリケーション(FusionアプリケーションやE-Business Suiteなど)のマスキング・テンプレートを使用して機密データをマスクできます。FusionアプリケーションまたはE-Business Suiteなどエンタープライズ・アプリケーションは複雑なため、データ・マスキング・テンプレートを手動でインポートするプロセスも複雑になることがあります。
Oracleアプリケーションのマスキング・テンプレートとサブセット化テンプレートの自己更新を使用すると、これらのテンプレートをOracleから直接ダウンロードして、手動操作を行わずにOracle Enterprise Manager Cloud Control 12c環境にインポートすることができます。
Oracleアプリケーションのマスキング・テンプレートとサブセット化テンプレートの自己更新オプションを使用すると、Oracleアプリケーションの非本番環境で機密データを保護して、小さなサイズのデータベースをプロビジョニングするベスト・プラクティスを、企業が容易かつシームレスに実装できます。
|
関連項目: 詳細は、『Oracle Databaseテスト・ガイド』を参照してください。 |
データベース・リプレイでは、1つの統合データベース上での複数データベース取得の同時実行をサポートするようになりました。統合データベースは、複数のPDBを持つCDBでも、スキーマ統合メソッドを使用して統合された従来のデータベースでもかまいません。統合データベース・リプレイでは、個々のリプレイのスケジューリングがサポートされ、様々なシナリオ(もし個々のワークロードがすべて同時に使用率のピークに達したらどうなるかなど)を検査できます。
統合リプレイにより、1つのOracleデータベース・マシン上で統合しようが、他の統合インフラストラクチャに統合しようが、データベース統合プロジェクトに必要なデータベース・パフォーマンスを保証できます。
|
関連項目: 詳細は、『Oracle Databaseテスト・ガイド』を参照してください。 |
Database Replayでは、既存の取得ワークロードに基づく新しいワークロードの作成をサポートします。新しいワークロードは、容量計画や様々なwhat-ifシナリオの評価に使用できます。
新しいワークロードを作成するために、様々なディメンション(時間、サービス、モジュールなど)でのワークロードのフィルタリングやスケジューリングなど、ワークロード操作テクニックが使用されます。さらに、ワークロード操作テクニック(フィルタリング、時間によるサブセット化など)を組み合せて使用して、それらを同時に実行するようにスケジュールすることで、カスタム・ワークロード・シナリオまたは元のワークロードのスケールアップ・バージョンも簡単に作成できます。
Database Replayを使用して取得されるデータベース・ワークロードは、様々な属性(リクエスト・タイプ、アクティビティ、アクセスまたはトランザクション・パターン、アプリケーション定義属性など)によって特性を評価できます。こうして、取得したワークロードを、小さくて管理しやすい自律型単位に分割することができ、これは取得したワークロードをよく理解するためにも使用できます。
データベース・ワークロードのスケールアップと特性評価の機能を利用して、ビジネスにおいて様々なwhat-ifシナリオの容量計画やシステム・テストを実行できます。
|
関連項目: 詳細は、『Oracle Databaseテスト・ガイド』を参照してください。 |
Database Replayのレポートが拡張され、リプレイ速度の遅さや速さの理由の手がかりを提供するようになります。アクティブ・セッション履歴(ASH)分析フレームワークを利用して、Database Replayでは追加のリプレイ・レポートを提供することで、データベース・リプレイのすべてのパフォーマンス特性を迅速に分析し理解できるようにします。さらに、ASH分析を使用すれば、カスタム・レポートを作成できます。
Database Replayのレポートの拡張により、ユーザーがリプレイ・パフォーマンスの分析にかける時間が短縮されます。
|
関連項目: 詳細は、『Oracle Databaseテスト・ガイド』を参照してください。 |
次の項では、一般的な新機能について説明します。
Oracle Database 12cでは、DBMS_QOPATCHを使用して、インストールされているデータベース・パッチを表示するためのPL/SQLまたはSQLインタフェースを提供します。このインタフェースでは、OPatch lsinventory -xmlコマンドの一部として、入手可能なすべてのパッチ情報が提供されます。パッケージは、Oracle Universal Installer (OUI)のパッチ・インベントリにリアルタイムでアクセスし、パッチおよびパッチ・メタ情報を提供します。
この機能を使用すれば、ユーザーは次のことができます。
SQL*Plusのどのパッチがインストールされているかの問合せ。
レポートを作成し、複数の環境にわたり検証チェックを実行するラッパー・プログラムの作成。
Oracle RACノードにインストールされているパッチを、各ノードに順々にログオンすることなく、1つの場所からチェック。
|
関連項目: 詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
次の各項では、Oracle Database 12cリリース1 (12.1)でのOracle RACおよびOracle Grid Infrastructureの新機能について説明します。
次の項では、Oracle Automatic Storage Management (Oracle ASM)の改善点について説明します。
Oracle Flex ASMは、Oracle ASMインスタンスをデータベース・サーバーから切り離します。Oracle Flex ASMインスタンスは、Oracle Database 12cインスタンスとは別の物理サーバーで実行することができます。任意の数のOracle Flex ASMサーバーをクラスタ化して、データベースの大規模なセットに対応することができます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
この機能により、Oracle ASMディスク・グループでのOracle ASM共有パスワード・ファイルのブートストラップの問題に対処するために必要なインフラストラクチャが実装されます。このアプローチによって、メンテナンスする必要があるコピーが1つのみであることが保証され、パスワード・ファイルの管理が簡易化されます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ASMリバランスの拡張により、リバランス操作のスケーラビリティ、パフォーマンスおよび信頼性が向上します。この機能によってリバランスが拡張され、1つのインスタンス内の複数のディスク・グループを処理できるようになります。また、シン・プロビジョニング、ユーザー・データ検証およびエラー処理のサポートが向上しています。
この新機能により、リバランス・ロードを分散してパフォーマンスを向上させ、適切なユーザー検証を取得し、エラー処理を制御し、シン・プロビジョニングをサポートすることができます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ASMディスク再同期化により、複数のディスクを同時にオンライン化したり、再同期化操作の速度を制御したりすることができます。現在、Oracle ASMディスク再同期化には、再同期化の並列度を制御してパフォーマンスを向上させる、再同期化指数制限があります。ディスク再同期化チェックポイントにより、インスタンス障害時に最初から始めるかわりに中断または停止した時点から再同期化を再開することができ、短時間でリカバリできます。
この拡張により、インスタンス障害時のリカバリ時間が短縮され、全体的な再同期化パフォーマンスが高速になります。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
この機能により、影響を受けるファイルが開いている場合でも、ASMCMDのchown、chgrpおよびchmodコマンドが実行できるようになります。Oracle Database 11gリリース2 (11.2)では、これは許可されていませんでした。これらのASMCMDコマンドをサポートしているALTER DISKGROUP MODIFY OWNERSHIP SQLコマンドも同様に変更されています。
この機能により、Oracle ASMのユーザーおよびユーザーが所有するファイルの管理性が向上します。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
この機能では、新しいSQL文ALTER DISKGROUP REPLACE USERが導入されます。これを使用すると、Oracle ASMユーザーのIDを、あるオペレーティング・システム・ユーザーから別のオペレーティング・システム・ユーザーに変更することができます。この機能により、エンド・ユーザーがOracle ASMユーザーのIDを変更でき、ユーザーを削除して再作成する必要はありません(この場合、ユーザーが所有するすべてのファイルを削除する必要があります)。
この機能により、Oracle ASMのユーザーおよびユーザーが所有するファイルの管理性が向上します。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Enterprise ManagerではOracle ASMの次の機能がサポートされます。
Oracle Flex ASMサーバー
ディスク再同期化の改善点
Oracle ASMリバランスの改善点
WindowsでのOracle ASMファイルのアクセス制御の有効化
Oracle ASMでの破損メディアのリカバリ(修正)
ユーザーは使いやすいインタフェースを利用して、ジョブのスケジューリングやメトリックの収集など、これらの新機能の監視と管理を行うことができます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ASMファイル・アクセス制御は、ファイルへのアクセスをSYSDBAとして接続する特定のOracle ASMクライアントに制限します。通常、Oracle ASMクライアントはデータベースで、データベース・インスタンス・ホームを所有するユーザーとして識別されます。
Oracle Database 12cリリース1 (12.1)以降、Oracleでは、Oracle Databaseサービスを実行するために、ローカル・システム・アカウントのかわりにWindowsの権限が低いユーザーの使用をサポートし、その結果、様々なOracleデータベースごとにユーザーを分けることができます。このリリースでは、Oracle ASMディスク・グループのファイルレベル・アクセス制御と権限分離もサポートされます。
Oracle ASMのファイル・アクセス制御機能により、現在のユーザーを新しいユーザーで置き換えることができ、ファイルが1つ以上のOracle ASMクライアントによって開かれているときに、ユーザーがファイルの所有権、グループ・メンバーシップおよび権限を変更できます。このリリースでは、特定のOracleホームの権限の低いユーザーは、Oracle ASMストレージ・デバイスへの直接アクセスを制約され、アクセスするには、サービスを実行する十分な権限があるOracle Databaseサービスを使用します。
現在、Oracle ASMディスク・グループ・ユーザーは、新しいASMCMDコマンドとSQL文を使用してASMディスク・グループ・ユーザーの置換を管理します。
|
関連項目: 詳細は、『Oracle Databaseプラットフォーム・ガイド』を参照してください。 |
ローリング移行フレームワークは拡張され、Oracle ASMにリリースされる個別パッチの適用をローリング形式で処理するようになりました。また、別のOracle ASMインスタンスにデータベース(Oracle Database 12cリリース1 (12.1)以上)を移行することもでき、ローリング移行の際の停止時間も最短になります。
この機能により、データベースを停止してアップグレードする前に別のOracle ASMインスタンスに移行することで、データベースの可用性が向上します。
|
関連項目: 詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
次の項では、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)の改善点について説明します。
Oracle ACFSでは、すべてのデータベース・ファイルがサポートされます。この機能は、データベース・ファイルのためのOracle ACFSデータ・サービスを利用しています。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Gridホームでは、Oracle ACFSエクスポート(NFS使用)には、Oracle ACFSスナップショットに適用されるゴールド・イメージとパッチ更新が含まれます。
ネットワーク・ファイル記憶域(NFS)はGridホーム・サーバーにデプロイされ、Gridホーム・クライアント・システムをサポートします。アプリケーションVIP (仮想インターネット・プロトコル・アドレス)およびNFSエクスポート・リソースは、Oracle ACFSおよび高可用性NFSのために利用されます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ACFSの読取り/書込みスナップショットが拡張され、同じOracle ACFSファイル・システムの既存のスナップショットから作成されたスナップショット(スナップのスナップ)や、スナップショットの変換(読取専用から読取り/書込み)をサポートするようになりました。これらによって、Oracle ACFSスナップショット管理に対する、追加のスパース・パッチ・セット拡張(スナップショット使用)の作成がサポートされます。
カスケード・スナップショット、読取り/書込みと読取専用スナップショットの双方向変換により、スナップショット機能が拡張されました。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
この機能により、Oracle ACFSレプリケーションとOracle ACFSのセキュリティおよび暗号化との統合が可能になります。ユーザーは、Oracle ACFSセキュリティおよび暗号化とOracle ACFSレプリケーションを組み合せて使用できます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
この機能により、Oracle Audit VaultおよびDatabase FirewallでのOracle ACFSのセキュリティと暗号化のサポートが有効になります。この新しいサポートは、Oracle Audit Vault、Database FirewallおよびOracle ACFSのセキュリティと暗号化を組み合せて使用するユーザーに対応します。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ACFSのセキュリティ機能により、ユーザーまたはグループがファイル・システム・オブジェクトにアクセスするためのセキュリティ・ポリシーを指定するレルムを作成できます。Oracle ACFSセキュリティ機能は、オペレーティング・システムが提供するアクセス制御の上の、より密なアクセス制御を提供します。
Oracle ACFS暗号化機能により、Oracle ACFSファイル・システムのデータを暗号化したフォーマットで保存でき、データの損失または盗難が発生した場合に、データの不正使用を防ぎます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ACFSファイル・タグ操作は、オペレーティング・システムに依存しない共通ファイル・タグAPI (Cライブラリ)でサポートされています。パッチ・ソフトウェア・ツールはOracle ACFSファイル・タグを使用して、指定のOracle ACFSスナップショット・イメージに適用される特定のパッチ・ファイルを識別し、Gridホーム・パッチ・セットが転送するスパース・ファイルをサポートします。タグ・ファイルは、使用状況メトリックの表示でも使用できます。
この機能により、プログラム・インタフェースがOracle ACFSのファイル・タグ機能を管理できるようになります。Gridホーム・ツールはそのようなユース・ケースの例です。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ACFSプラグイン機能により、ユーザー・スペース・アプリケーションが、Oracle ACFSファイルとASM動的ボリューム・マネージャ(ADVM)のジャストインタイム・ボリューム・メトリックをオペレーティング・システム環境から収集できます。Oracleとユーザー・アプリケーションは、Oracle ACFSプラグイン・インフラストラクチャを活用して、Oracle ACFSのファイル・システムとボリュームの詳しいデータを含むように、一般的なアプリケーション・ファイル・メトリック・インタフェースを拡張するカスタマイズ・ソリューションを作成できます。
この機能により、統計データを収集するプログラム・インタフェースが提供されます。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ACFS機能のEnterprise Managerでのサポートの内容は次のとおりです。
GridホームのためのOracle ACFSの拡張
Oracle ACFSタグ付け
Oracle ACFSスナップショットの拡張
このサポートにより、使いやすいGUI管理インタフェースを使用して、すべてのOracle ACFSファイル・システムの機能を管理できるようになります。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracleでは、Oracle ACFSのレプリケーションとタグ付けをAIXに移植できるようになり、オペレーティング・システム・プラットフォームのサポートが広がりました。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracleでは、Oracle ACFSのレプリケーションとタグ付けをSolarisに移植できるようになり、オペレーティング・システム・プラットフォームのサポートが広がりました。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
次の各項では、Oracle Clusterwareの新機能について説明します。
Oracle Flex Clusterは、2種類のクラスタ・ノード(ハブ・ノードとリーフ・ノード)を使用するトポロジに基づく新しいOracle Clusterwareです。ハブ・ノードは従来のノードで、ネットワークとストレージを使用する密結合です。リーフ・ノードは新しい種類のノードで、軽量のスタックを実行し、直接共有ストレージ接続の必要がありません。
密結合のハブ・ノードと軽量のリーフ・ノードを1つのクラスタに組み合せると、様々なワークロードやアプリケーションを数百のノードで実行することができ、追加のオーバーヘッドが発生しない一方、ノード間の依存関係を作成する機能は維持されます。クラスタ全体の集中管理と標準化されたリソース割当てポリシーにより、Oracle Flex Clusterでのワークロードの統合がさらに促進されます。
Oracle Grid Infrastructureでは、1つのクラスタで複数のアプリケーションを実行することができます。ポリシーベースのアプローチを使用すると、ポリシー・セットを使用してこれらのアプリケーションに伴うワークロードをクラスタ全体に割り当てることができます。またポリシー設定によって、時間の経過とともに必要に応じて異なるポリシーをクラスタに適用することができます。ポリシー設定は、Webベースのインタフェースまたはコマンドライン・インタフェースを使用して定義することができます。
同じクラスタ内で様々なワークロードを受け入れることで、共有インフラストラクチャにワークロードを集約することができ、高可用性とスケーラビリティが実現されます。集中管理されたポリシーベースの方法を使用することで、要求の変化に応じてリソースを動的に再配分し、優先度付けが可能になります。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
現在、Oracle Clusterwareで提供される一連の評価コマンドによって、それぞれの操作が実際に実行される前に、特定の操作の影響を判別することができます。
クラスタウェア管理者は、クラスタの変化に対処することを常に求められています。クラスタウェア管理者は、what-ifコマンドの評価を使用すると、特定の操作の影響を実行の前に確認でき、これにより最適な決定を下すことで、円滑なクラスタ操作が保証されます。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Cluster Registry (OCR)バックアップ・メカニズムによりOracle ASMディスク・グループでOCRのバックアップを格納することができます。
Oracle ASMディスク・グループにOCRのバックアップを格納すると、OCRのリカバリが必要になった場合にクラスタの任意のノードからOCRバックアップへのアクセスを許可することによって、OCR管理が簡素化されます。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
以前のリリースでは、グリッド・ネーミング・サービス(GNS)はOracle Grid Infrastructureベースの1クラスタ専用であり、名前解決が提供されるのもそのクラスタに含まれるノードのみでした。この制約は取り除かれ、現在は1つのGNSで1つのクラスタのみを管理することも、データ・センターのすべてのクラスタのすべてのノードの名前解決を実行することもできます。
データ・センターのOracle Grid Infrastructureベース・クラスタに含まれるすべてのノードに対して1つのGNSのみを使用すると、ネーミング規則が単純になるだけではなく、データ・センター・クラウドの日常的な管理作業を最小限に抑えることもできます。
Oracle Flex Clusterは新しい概念であり、少数のノード数を持つ従来の密結合クラスタを、多数の疎結合ノードと結合します。
この新しい概念を使用して作成された様々な構成をサポートするため、SRVCTLでは、インストールと構成を容易にする、新しいコマンドおよびコマンド・オプションが提供されています。
|
関連項目: 詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Clusterwareでは、リソース・モデルを使用して、高可用性のためにハードウェアおよびソフトウェアを管理します。たとえば、Oracle RACデータベースで使用されるリスナーまたはVIPは、それぞれのリスナーおよびVIPリソースを使用して管理されます。リソース属性は、Oracle Clusterwareでリソースを管理する方法の定義に使用されます。たとえば、VIPリソースのサブネットまたはリスナーの名前を定義するために、リソース属性が使用されます。オンラインでのリソース属性の変更を使用すれば、リソースの特定の属性を変更でき、変更を有効にするためにリソースを再起動する必要がありません。オンラインでのリソース属性の変更は、特定のSRVCTLおよびCRSCTLコマンドを使用すれば可能です。
特定のリソース属性を、変更を有効にするためにリソースを再起動しなくても変更できることで、リソースの可用性が高まり、障害の可能性は減少し、全体として高可用性環境でのリソース管理が簡単になります。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
次の各項では、Oracle Grid Infrastructureの新しい一般的機能について説明します。
インストールとアップグレードのスクリプト自動化を使用すると、Oracle Grid Infrastructureのインストールまたはアップグレードの最終ステップで、各ノードでスクリプトを手動で実行する必要がなくなります。この機能により、エラーが発生する可能性が最小限に抑えられ、インストール・プロセスが単純化されます。
|
関連項目: 詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
以前のOracleリリースでは、特定の構成シナリオに対応するためにはインストール後のステップが必要でした。新しいOracle Universal Installer (OUI)では、よく使用される構成が最初のインストール・フローでインストールされます。
よく使用される構成シナリオをOUIのデフォルト・インストール・フローに統合することで、Oracle Grid Infrastructureでのインストールが容易になり、エラーが発生しにくくなり、全体の効率が向上します。
|
関連項目: 詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
次の項では、Oracle RACの新機能について説明します。
クラスタ・ノードは、パブリック・ネットワーク上の仮想IP (VIP)でIPv4またはIPv6ベースのIPアドレスを使用するように構成できます。また、クラスタに対して複数のパブリック・ネットワークを定義できます。データベース・クライアントおよびアプリケーションはIPv4アドレスとIPv6 VIPアドレスのどちらにも接続できます。単一クライアント・アクセス名(SCAN)リスナーが、クライアントによってリクエストされたIPプロトコルを検討して、指定のサブネット内の適切なデータベース・リスナーにクライアントの接続を自動的にリダイレクトします。SCANリスナーはクラスタ内の各サブネットに定義できます。
IPv6ベースのIPアドレスは、現在のデータ・センターにおける情報テクノロジ・インフラストラクチャの最新標準になっています。このリリースでは、Oracle RACおよびOracle Grid Infrastructureはクライアント接続に関してこの標準をサポートしています。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)の新しいパフォーマンス機能について説明します。
次の項では、データベース・パフォーマンスの改善点について説明します。
新しいパラメータ、SQLNET_COMPRESSIONおよびSQLNET.COMPRESSION_SCHEME_LISTによって、Oracle Net Servicesでクライアントからサーバーに送信されるときにデータを圧縮できるようになりました。次の圧縮が有効です。
接続レベル(接続文字列、URL)
サービス・レベル(tnsnames.ora、ldap.ora)
データベース・レベル(sqlnet.ora)
ネットワーク・アクセラレーションにより、ローカル・エリア・ネットワーク(LAN)およびワイド・エリア・ネットワーク(WAN)環境でのネットワーク待機時間が短縮され、パフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。 |
Oracle Netレイヤーでの大きなパケット(セッション・データ・ユニット(SDU)サイズ)のサポートがこのリリースに追加されています。SDUによって内部バッファのサイズが定義されます。以前のリリースでは、デフォルトは8KB、最大値は64KBでした。このリリースでは現在の値よりも制限が高くなります。
非常に大きなネットワーク・バッファのメリットは、使用可能なネットワーク帯域幅の最適化と適切な利用による、アプリケーション・スループットの向上です。
|
関連項目: 詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
次の項では、一般的な新機能について説明します。
DNFS_BATCH_SIZEパラメータは、Direct NFSクライアントが有効な場合に、Oracleプロセスでキューに入れることができる非同期I/Oリクエストの数を制御します。ネットワーク・ファイル記憶域(NFS)サーバーが未処理の非同期I/Oリクエストを多数処理できない場合、このパラメータを使用して、Oracleフォアグラウンド・プロセスで発行されるI/Oリクエストの数を制限できます。このパラメータの推奨設定は128KBです。NFSサーバーのパフォーマンスに応じて増減します。
NFSサーバーによっては、短期間に送信される非同期I/Oリクエストが多すぎると正常に機能しないことがあります。この動作のデフォルトのDirect NFSクライアント設定は、一部のNFSサーバーでの処理数を上回っています。DNFS_BATCH_SIZEパラメータを使用すると、ユーザーが特定のNFSサーバー要件に合せてDirect NFSクライアントの動作をチューニングでき、最大限のパフォーマンスとシステムの安定が実現します。
|
関連項目: 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
Oracle Databaseで管理されるV$IO_OUTLIERビューは、完了までに長い時間がかかるI/O操作を取得します。I/Oの完了が大幅に遅延すると、深刻なパフォーマンスの低下を引き起こすことがあります。DBAはV$IO_OUTLIERビューを監視して、I/Oサブシステムの状態を確認します。V$IO_OUTLIERビューでは、全体的なI/O待機時間に関するヒントが得られますが、多くの場合DBAはさらにドリルダウンして、オペレーティング・システムのどこで長い待機時間が発生しているかを調べる必要があります。現在、Oracle DatabaseはSolarisの動的トレース機能を使用して、I/Oが物理デバイスに送られる途中にオペレーティング・システムの主要なサブシステムそれぞれでかかった時間の情報を収集します。各コンポーネントの時間情報は新しいV$KERNEL_IO_OUTLIERビューに記録されます。これは、完了までに長い時間がかかったI/Oについてオペレーティング・システムベースの待機時間の明細を示します。
これは、I/O関連の問題を迅速に特定して識別することができる、チューニングとデバッグのために不可欠なツールです。
|
関連項目: 詳細は、『Oracle Databaseリファレンス』を参照してください。 |
次の項では、ハードウェアの構成とテクノロジの機能について説明します。
複数プロセスかつマルチスレッドのOracleは、複数のプロセスと、各プロセスで複数のスレッドを使用し、Oracle Databaseの新しい実行モデルを実現します。複数プロセスかつマルチスレッドのOracleをサポートすることで、システムおよびプロセッサ・リソースの共有を効率よくできるようになり、パフォーマンスと管理性が向上します。
|
関連項目: 詳細は、『Oracle Database概要』を参照してください。 |
次の項では、すぐに使用できるパフォーマンスの改善点について説明します。
NFS_VERSIONパラメータを使用して、Direct NFSクライアントで使用されるNFSプロトコルをユーザーが指定できます。指定できる値は、nfsv3、nfsv4およびnfsv4.1です。バージョンを指定しないと、デフォルトではnfsv3が使用されます。
NFSバージョン4はNFSバージョン3に比べてパフォーマンスが向上しています。NFS_VERSIONパラメータにより、ユーザーは使用可能な場合にバージョン4の機能を利用できます。
|
関連項目: 詳細は、『Oracle Databaseインストレーション・ガイド for Linux』を参照してください。 |
次の各項では、Oracle Database 12cリリース1 (12.1)の新しいデータベース・セキュリティ機能について説明します。
次の項では、暗号化、ハッシングおよびリダクションの機能について説明します。
この新しいデータベース・セキュリティ機能は、Oracle Advanced Securityの一部で、これによりデータの列(クレジット・カード番号、米国の社会保障番号、その他の機密データや規制データなど)の表示を防ぐことができます。これは、データベース・セッション・ファクタやアプリケーションによって渡される情報に対応できる宣言ポリシーによって駆動されます。機密表示データは、実行中のアプリケーションの中断を最小限に抑えながら、実際の格納済データを変更することなく、稼働中の本番システムで実行時にリダクションできます。完全、部分、ランダムおよび正規表現リダクションなど、様々なタイプのリダクションがサポートされます。データ値全体を隠したり、データの一部のみをリダクションすることができます。この機能はデータベース内部に実装されるため、別にインストールする必要はありません。
|
関連項目: 詳細は、『Oracle Database Advanced Securityガイド』を参照してください。 |
Oracle Database 12cでのSHA-2アルゴリズムのサポートは、Oracle Database 11.2.0.3での既存のSHA-2サポートに基づいて構築されています。SHA-2アルゴリズムのサポートには、PL/SQL DBMS_CRYPTOパッケージが含まれています。
SHA-2アルゴリズムのサポートにより、Oracle Databaseのセキュリティが確実になります。また、現在または将来において、機密データのハッシングのためにSHA-2アルゴリズムの使用が必要な規制のコンプライアンスが得られます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
次の各項では、セキュリティの拡張について説明します。
新しい統合監査アーキテクチャは、データベースの初期化パラメータを変更せずにOracle Databaseで使用できます。この機能では、本番データベースを停止せずに、監査ポリシーをデータベースで作成および有効化できるようになります。これによりデータベース監査の柔軟性が向上し、管理しやすくなります。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
コードベース・セキュリティを使用して、PL/SQLパッケージ、ファンクションおよびプロシージャとロールを関連付けることができます。パッケージ、ファンクションおよびプロシージャとロールとの関連付けによって、権限付与の粒度が細かくなり、ランタイム・ユーザーにロールを直接付与する必要がなくなります。
コードベース・セキュリティは、PL/SQLプログラム・ユニットの実行範囲のロールのみを有効にすることで、アプリケーションのセキュリティを強化します。ユーザーにロールを直接付与することはありません。ロール付与の範囲指定により、ユーザーへのデータベース権限付与が減り、最少の権限でセキュリティ概念を実施することができます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
この機能により、SYSDBA権限を必要とせずに、Data Guard構成を管理できるようになります。SYSDBA権限が付与されないクラスのユーザーに、Data Guard構成の管理を委任することができます。
|
関連項目: 詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
新しい統合監査ポリシーベースのデータベース監査アーキテクチャでは、監査レコードが読取り専用表に格納されます。この新しい監査表はOracleデータベース・インフラストラクチャの一部として作成されます。監査証跡レコードのメンテナンスは監査証跡クリーンアップ・パッケージを使用して実装され、このパッケージは、新しいAUDIT_ADMIN管理者ロールを持つユーザーしか使用できません。
セキュリティとコンプライアンスの規制により、Oracleデータベース・アクティビティの正確な監視とレポートが求められます。新しい読取り専用表によって、監査レコードが監査証跡に書き込まれた後に変更も削除もされていないことが確実に保証されます。新しい監査証跡のメンテナンスは、新しいAUDIT_ADMINロールが付与されたユーザーのみに制限されます。新しいAUDIT_ADMINロールを持つユーザーのみが、監査データの保存ポリシーを管理できます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
SELECT ANY DICTIONARY権限では、セキュリティについて機密性が高いデータ・ディクショナリ表DEFAULT_PWD$、ENC$、LINK$、USER$、USER_HISTORY$およびXS$VERIFIERSへのアクセスが許可されなくなりました。
この変更により、SELECT ANY DICTIONARY権限によるデータ・ディクショナリ表のサブセットへのアクセスが禁止され、データベースのデフォルト・セキュリティが強化されます。
データベース・ユーザーの最終ログイン時間はUSER$表に記録され、Oracle SQL*Plusを使用してデータベースに接続すると表示されます。
データベース・ユーザーの最終ログイン時間を記録して、アカウントがデータベースで最後にいつ使用されかをセキュリティ管理者が確認できるようにすると、データベース・セキュリティが強化されます。Oracle SQL*Plus接続バナーに最終ログイン時間が表示され、SQL*Plusユーザーに直前のアカウント使用の情報が提供されます。
|
関連項目: 詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。 |
Oracle Database Vaultの必須レルムによって、オブジェクト所有者を含め、DBA権限と直接オブジェクト権限両方の付与がブロックされます。従来のOracle Database Vaultレルムは、一般的なDBA ANYシステム権限から保護し、権限を持つユーザーがSELECT ANY権限を使用して、レルムで保護されたオブジェクトにアクセスしないようにします。必須レルムにより、直接オブジェクト権限を持つユーザー(オブジェクト所有者を含む)も、レルムで保護されたオブジェクトへのアクセスがブロックされます。従来のレルムと同じく、アクセスが必要なユーザーは、Oracle Database Vaultのレルム認可機能を使用して認可されます。
Oracle Database Vaultの必須レルムにより、大規模アプリケーション内に存在する重要なアプリケーション表保護が強化されます。この機能を使用して、重要な機密情報を含むアプリケーション表を必須レルムに配置することができ、オブジェクト権限が直接付与されたユーザーが、それらの表に含まれるデータにアクセスできなくなります。必須レルムは、データベース管理者、サポート・アナリストまたは開発者がアプリケーション・スキーマに一時的にアクセスする必要があるが、特定のアプリケーション表へのアクセスをブロックする必要がある場合にも使用できます。
|
関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。 |
完全なデータベース・エクスポートおよびインポート操作を実行するときに、LBACSYSスキーマにあるOracle Label Securityのメタデータを含めることができます。ソース・データベースは、Oracle Database 11gリリース2 (11.2.0.3)以上に対応します。ターゲット・データベースは、Oracle Database 12cリリース1 (12.1)以上であることが必要です。
Oracle Label Securityのメタデータのエクスポートとインポートにより、Oracle Label Securityのポリシーと保護されている表をデータベース間で移動できるようになります。
|
関連項目: 詳細は、『Oracle Label Security管理者ガイド』を参照してください。 |
Oracle Database Configuration Assistant (DBCA)を使用して作成された新しいデータベースでは、デフォルトのパスワード複雑度チェックをオプションで有効にできます。パスワード複雑度チェックにより、強力なパスワード・チェックが有効化されずに新しいデータベースが作成される可能性が少なくなり、Oracleデータベースと企業全体のセキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
権限分析を行うと、データベース・ユーザーのプロファイルを作成し、そのユーザーによって使用されているシステムおよびオブジェクト権限のリストを取得できます。次に、ユーザーの使用権限リストを付与権限リストと比較し、使用権限に応じて付与権限リストを減らすことができます。
権限分析により、使用されない権限すなわち過剰な権限を特定することができ、アプリケーションと操作のセキュリティの強化につながります。データベース管理者が必要とする権限は、一般的な管理アクティビティを実行するときに使用される権限を分析するとすぐに特定できます。アプリケーションが必要とする権限は、アプリケーションがデータベースに接続しているときに権限分析を実行するとすぐに特定できます。
|
関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。 |
Oracle Database 12c以降では、UNLIMITED TABLESPACE権限がデフォルトのRESOURCEロールではなくなりました。この変更により、RESOURCEロールを付与されたデータベース・ユーザーおよびアプリケーションが表領域の意図されたリソース割当て制限を超過する可能性がなくなり、データベースのデフォルト・セキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
新しい統合コンテキストベース・データベース監査構成には、データベース監査を管理するために2つのロールがあります。新しいAUDIT_ADMINロールでは、新しい監査ポリシーを作成および有効化し、監査レコード保存ポリシーを指定することができます。新しいAUDIT_VIEWERロールでは、監査者およびセキュリティ管理者が新しい統合監査証跡の監査データを表示できます。
新しい統合コンテキストベース・データベース監査アーキテクチャでの義務の分離によって、監査ポリシーの作成、有効化および削除を行えるユーザーを選択して割り当てられるようになりました。ただし、セキュリティ・チーム・メンバーおよびマネージャは、生成された監査データをこれまでどおり確認できます。データベース管理者を監査の管理から切り離すことができ、日常的な操作のセキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
Oracle Databaseには、バックアップおよびリカバリ、高可用性およびキー管理などのデータベース管理アクティビティ用の新しいロールが用意されています。一般的なデータベース管理タスクのために新しいロールを提供することにより、一般的な日常操作のために高度な権限のSYSDBAロールを付与する必要がなくなり、Oracleデータベースのセキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
新しい管理権限SYSBACKUPを使用すると、Recovery Manager (RMAN)ユーザーがターゲット・データベースに接続して、RMANコマンドを実行できるようになります。SYSDBAは必要なくなりました。
この機能では、義務の分離セキュリティ・モデルが実施され、バックアップ・オペレータはRMANコマンドを実行するためにSYSBACKUP権限のみを必要とし、本来のSYSDBA権限を必要とするデータベース管理者とは別の職責を果たします。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次の項では、暗号化キー管理の拡張について説明します。
Oracle Advanced Security透過的データベース暗号化(TDE)のキー管理機能が、次の一連の新機能が含まれるように更新されます。
キーストア管理の共通レイヤーは、TDEのOracleキーストア(以前のリリースのウォレット)とサードパーティのハードウェア・セキュリティ・モジュール(HSM)を一貫して管理できます。
キー管理のための新しいSQL文(ADMINISTER KEY MANAGEMENT)は、以前は個別のOracleユーティリティで提供されていた機能を統合します。
マスター暗号化キーの重要な属性を追跡するための新しいメタデータ。
新しい組込みデータベース・ビュー。キーとその属性を調べることができます。
SYSKMデータベース管理権限は、キーストアと暗号化キーを管理します。
キーストアでの個々のキーのエクスポートまたはインポートのサポート。Oracleデータベース間でキーを移動できます。
TDEキーストアのOracle ASM管理対象ディスク・グループでの直接格納のサポートは、他のファイル・システムが必要ありません。
キー管理フレームワークの更新により、キー管理インタフェースの柔軟性とセキュリティが向上し、さらにユーザーフレンドリになります。
|
関連項目: 詳細は、『Oracle Database Advanced Securityガイド』を参照してください。 |
次の項では、セキュリティの管理と統合の機能の改善点について説明します。
Oracle Database Vaultによって提供されるセキュリティ制御が、Oracle実行可能ファイルに依存しなくなりました。Oracle Database Vaultが有効になっているデータベースでも有効になっていないデータベースでも、同じOracleソフトウェア・ホームを使用できます。
Oracle Database Vaultが短時間で有効化でき、企業内で使用しやすくなります。データベースが新しいOracleホームまたは新しいサーバーに移されても、Oracle Database Vaultによる制御は引き続き適用され、管理が単純になり、セキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Database Vault管理者ガイド』を参照してください。 |
Oracle Database VaultおよびOracle Label Securityのインストールが簡易化されています。以前のリリースでは、これらのソリューションのソフトウェアはデフォルトではインストールされませんでした。このリリースでは、ソフトウェアはデフォルトでインストールされていますが、有効ではありません。Oracle Database VaultまたはOracle Label Securityは、コマンドラインでの簡単な構成ステップのみで有効化できるようになりました。
Oracle Database VaultおよびOracle Label Securityがデフォルトでインストールされ、追加のセキュリティ制御を本番システムで短時間に容易に構成でき、これらの高機能セキュリティ・ソリューションの使用が単純になります。また、セキュリティの脅威からの保護に役立ちます。
|
関連項目: 詳細は、『Oracle Databaseインストレーション・ガイド for Linux』を参照してください。 |
透過的機密データ保護では、分類タイプ(たとえば、列で特定のデータ型が使用されるクレジット・カード番号)に基づいてデータベースで機密データを一貫して保護することができます。この機能により、データベースによる機密データの保護を管理しやすくなり、追加の保護も適用しやすくなります。また、透過的機密データ保護ポリシーは他のデータベースに簡単にエクスポートできます。透過的機密データ保護をOracle Data Redactionポリシーと一緒に使用できます。
透過的機密データ保護では、Oracleデータベース内のデータ分類に対して保護ポリシーを適用することができ、機密データを保護するためのコストが低下して複雑さが緩和されます。分類タイプにポリシーを適用することで、列ごとにポリシーを適用する必要がなくなります。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
ファイングレイン・コンテキスト依存ポリシーにより、1つ以上のペア(context,attribute)を仮想プライベート・データベース(VPD)ポリシーに関連付けることができます。VPDポリシー関数が評価されるのは、ペア(context,attribute)の1つで値が変更された場合のみです。
ファイングレイン・コンテキスト依存ポリシーにより、仮想プライベート・データベースを使用するアプリケーションのパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
次の項では、外部からデータベース・サーバーを保護する方法について説明します。
Oracle Grid Infrastructureで管理されるリスナーを構成して、そのリスナーに登録されているデータベースへのクライアントのアクセスを、クライアントの接続元サブネットなど、様々な条件を使用して制限することができます。データベースへのクライアントのアクセスを制御することで、Oracle RACのセキュリティが強化され、セキュリティの脅威や攻撃に対する脆弱性が低下します。
|
関連項目: 詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
データベースでアプリケーション・セキュリティのために必要なセキュリティ・インフラストラクチャは、アプリケーション・ユーザーとロールおよびアクセス権限とACLをよく理解し、それらをセキュアかつ効率よくデータベースに適用するものです。宣言による拡張可能なセキュリティ・ポリシーを使用して、ユーザーはセキュアなアプリケーションを迅速に構築することができます。
次の項では、Real Application Securityの改善点について説明します。
Real Application Securityは、アプリケーションの全体的なセキュリティのためにOracleデータベース認可ソリューションを提供します。これによって、データベース・レイヤーでアプリケーションレベルのセキュリティ・ポリシーが指定、プロビジョニングおよび適用されます。このため、アプリケーション・ユーザー、ユーザーの認可、およびデータに関するセキュリティ・ポリシーを処理するためにカスタム・アプリケーション・ロジックを構築するタスクが不要になります。広範囲のデータ中心セキュリティ・ポリシーやアプリケーション・ユーザーの認可に関する制約を、Oracleデータベース内に定義することができ、アプリケーション間で一貫性のある統一認可モデルが提供されます。
Real Application Securityは、セキュリティ制御をアプリケーション・レイヤーからデータが存在するデータベースに移すことにより、アプリケーションとデータのセキュリティ全体を強化し、最終的にはアプリケーションの開発時間を短縮します。アプリケーション・ユーザー、権限、ロール、権限付与およびセキュリティ・ポリシーを、データベース・レイヤーで定義、プロビジョニングおよび適用することができ、データとアプリケーションのセキュリティが強化されます。セキュリティ機能(権限の委任、ロールベースの制約、時間ベースのアクセス制御、コードベースのセキュリティ、複数レベルの認可、ネガティブ権限付与、ユーザー・インタフェース・アーティファクトでの認可、リレーショナル・データのアクセス制約、アプリケーション・ユーザー監査など)が提供され、アプリケーション・セキュリティのカスタム開発が縮小されます。データベース・レイヤーでのアプリケーション・セキュリティの適用により、データベースへのアクセス・パスにかかわらずアプリケーション・セキュリティ・ロジックを適用することができ、データのセキュリティが強化されます。
|
関連項目: 詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。 |
次の項では、セキュリティの最適化機能について説明します。
現在、Oracleデータベースでは、1つの統合監査証跡と、指定した監査ポリシーがOracleデータベース内で作成される新しいポリシー構文がサポートされます。この新しい強力な監査の実装は、コンテキストベースの条件に対応し、監査レコードがいつ作成されるかを制限します。また、特定のデータベース・ロールに対して監査を指定でき、監査を免除するように一連のユーザーを指定することもできます。
監査がセキュリティで果たす役割はますます重要になっています。新しい統合監査証跡とポリシー構文により、データベース監査の管理が単純化されます。また、監査の実行時期に関するきめ細かい制御、最適化されたパフォーマンス、およびセキュリティとコンプライアンスの柔軟性が得られます。
|
関連項目: 詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
この項では、Oracle Database 12cで提供されるSpatial and Graphの新機能について説明します。
Oracle Spatialは名前がOracle Spatial and Graphに変更されました。Oracle Spatial 10gのリリース以降、Oracle Databaseでは1つの機能としてネイティブ・グラフがサポートされていますが、Oracle Spatialの既存のグラフ機能を強調するため、またグラフ・データベース機能に対する市場の需要の高まりを意識して、この変更を行いました。
Oracle Spatial and Graphには、大手の輸送、通信、電力および公益企業において従来のネットワーク・アプリケーションで使用されるネットワーク・データ・モデル(NDM)グラフが含まれます。また、マスコミ、金融、研究、生命科学、製薬、諜報機関などでの必要性に対処して、社会的ネットワークや社会的相互作用で使用されるResource Description Framework (RDF)セマンティク・グラフもサポートされます。これらは実績が証明されている堅牢なグラフ・データベース・テクノロジです。
次の各項では、Oracle Spatial and Graphのこのような機能の拡張について説明します。
Oracle Spatial and Graphの新しいベクター・パフォーマンス・アクセラレーション機能を起動すると、ベクター操作を大幅に向上することができます。これにより、索引パフォーマンスの向上、ジオメトリ・エンジン・パフォーマンスの拡張、Spatialオペレータのセカンダリ・フィルタの最適化、多くの高度なベクター機能でのCPUおよびメモリー使用率の向上が実現します。ベクター・パフォーマンス・アクセラレーションが特に役立つのは、Oracle Exadataデータベース・マシンや他の大規模システムを使用している場合です。
Oracle Spatial and Graphベクター・パフォーマンス・アクセラレーションは、次の分野でのすべてのSDO_GEOMETRY操作で実現された全般的な改善に基づいています。
索引メタデータの取得
同時更新メカニズム
最適化された空間述語選択およびコスト機能
このような最適化により、CPU、メモリーおよびパーティション化をさらに有効に使用できるようになり、問合せパフォーマンスの大幅な向上につながります。たとえば、内部テストの結果では、測地点以外のデータやポリゴン問合せウィンドウについて、問合せパフォーマンスが以前のリリースに比べて最大で100倍になっています。
|
関連項目: 詳細は、『Oracle Spatial and Graph開発者ガイド』を参照してください。 |
Oracle Spatial and Graphルーティング・エンジンでは、トラック固有の経路指定と論理的な右左折制限がサポートされます。これは、乗用車の速度制限とは異なることが多いトラックの速度制限に基づいて運転時間を計算します。また、ルート沿いの計量所やトラック・ストップなどトラック用サービスに関する情報も提供します。さらに、ルート・ジオメトリ内で、複数の接線を含む論理的な右左折制限を処理できます。
このような拡張により、ロジスティックスおよびトラックの経路指定アプリケーションでより正確な結果を得ることができます。
|
関連項目: 詳細は、『Oracle Spatial and Graph開発者ガイド』を参照してください。 |
Oracle Spatial and Graph GeoRasterには、ローカル代数ファンクション・タイプと関連するラスター演算を提供する新しいラスター代数言語が含まれます。PL/SQLと組み合せることで、複雑なピクセル問合せの表現、値ベースのラスター編集、数学演算、分類、および多数のラスターとサイズ無制限のイメージに対する地図製作モデリングが可能になります。これらの操作は並列処理することができ、パフォーマンスが大幅に向上します。
サーバーベースのラスター分析機能、一連の効率的なI/Oおよびセル操作ユーティリティ、およびプログラミング・インタフェースを使用して、地図製作モデリング・アプリケーションを開発できます。ラスター・データの可用性が高くなっているため、分析をクライアント・ツールで実行しようとするかわりに、分析処理をデータベースに移すことで、パフォーマンスとスケーラビリティの向上を実現できます。
|
関連項目: 詳細は、『Oracle Spatial and Graph GeoRaster開発者ガイド』を参照してください。 |
Oracle Spatial and Graph GeoRasterでは、新しいイメージ処理機能が提供されます。これには、イメージの補正、オルソ補正、イメージの伸縮、イメージの分割、イメージの更新と追加、高度なモザイク操作、大規模な仮想モザイク、およびオンザフライ空間問合せが含まれます。
クライアントではなくサーバーで処理できるイメージ処理が増加しており、その一部は並列処理されます。これにより、ラスター・データの可用性が高くなるにつれて政府および民間のアプリケーションで使用されることが増えている、大きな規模や大きなデータ・セットに関してイメージ処理のパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Spatial and Graph GeoRaster開発者ガイド』を参照してください。 |
Oracle Spatial and Graph GeoRaster Java APIが拡張され、地上基準点(GCP)の格納と操作、GCP地形参照、再投影、グリッド補完およびgetCellValueなどの機能をサポートするようになりました。これらの機能は以前はPL/SQL APIのみでサポートされていました。
このような拡張により、Java開発者はOracle Spatial and Graph GeoRasterデータ管理機能をさらに利用できます。
|
関連項目: 詳細は、『Oracle Spatial and Graph Java APIリファレンス』を参照してください。 |
Oracle Spatial and Graph GeoRasterが拡張され、リレーショナル・ラスター・データ表(RDT)をサポートするようになり、ユーザーがデフォルトのアルファ・チャネルやピラミッド・レベルをメタデータに指定できるようになりました。また、GeoRasterによって新しいリサンプリング・アルゴリズムが追加され、解像度単位の指定と多くの操作での並列処理がサポートされ、ロードとエクスポートの新しい機能が追加されます。
これらの新機能により、GeoRasterデータの管理性、使用性、セキュリティおよびパフォーマンスが向上しています。
|
関連項目: 詳細は、『Oracle Spatial and Graph GeoRaster開発者ガイド』を参照してください。 |
次の高では、Oracle Spatial and Graphのグラフ機能の拡張について説明します。
機能モデリングによって、抽象的なネットワーク要素と、現実世界のアプリケーションにおける重要な具体的オブジェクトが結び付けられます。現在、Oracle Spatial and Graphネットワーク・データ・モデルには、機能モデリングと分析が含まれます。以前のリリースには、編集と分析のためのネットワーク要素レベルのインタフェースしか含まれていませんでした。機能モデリングにより、アプリケーションは機能分析関数を1回呼び出すだけで、結果の機能表現を取得できます。
機能モデリングにより、アプリケーション・オブジェクトとネットワーク要素のマッピングを管理するアプリケーション開発者の負担が軽くなります。たとえば、変電所で停電が発生して、電力会社のネットワーク・アプリケーションが影響をうける世帯を検出する必要があるとします。その場合、アプリケーションはアプリケーション機能(変電所、電線、変圧器)とネットワーク要素(リンクとノード)のマッピングを実行する必要があります。機能モデリングでは、この関係は機能メタデータによって管理されるため、アプリケーション・コードの開発と管理は必要ありません。
|
関連項目: 詳細は、『Oracle Spatial and Graphトポロジ・データ・モデルおよびネットワーク・データ・モデル・グラフ開発者ガイド』を参照してください。 |
現在、Oracle Spatial and Graphネットワーク・データ・モデルでは、時間ディメンションによるネットワークのモデリングがサポートされます。ユーザーは、時間属性をノードおよびリンクに関連付けることができ、ネットワーク分析問合せに一時入力を指定できます。
ほとんどの現実世界のネットワークは時間に依存しています。道路区分の移動時間は、時間帯によって異なります。電力会社のネットワークは、季節や時間帯に応じて需要量が増減します。分析や計画のアプリケーションは、現実世界の条件を正確に表すことによってメリットを得ます。Oracle Spatial and Graphネットワーク・データ・モデルは、指定された時間帯の最速ルートの検索、多様な輸送ネットワークのモデリングと分析、多様な輸送ネットワークでの最速経路の計算といった問合せをサポートします。
|
関連項目: 詳細は、『Oracle Spatial and Graphトポロジ・データ・モデルおよびネットワーク・データ・モデル・グラフ開発者ガイド』を参照してください。 |
リソース記述フレームワーク(RDF)ビューは、一連のリレーショナル表またはビューで作成できます。RDFビューに対するセマンティク・グラフ問合せによって、Oracle Databaseに格納されているリレーショナル・データとRDFセマンティク・グラフ・トリプル・データを統合できます。Oracleでは、これらのビューに対してSPARQL 1.1問合せ言語で記述されたセマンティク問合せがサポートされます。これは、OracleのJena/Joseki SPARQLエンドポイントを使用して行われます。また、埋込みSPARQL 1.1グラフ・パターンによるOracle SQL SEM_MATCH表関数の使用もサポートされます。
セマンティク・グラフ問合せは、RDFグラフ・データでのパターン一致を介してリレーションシップを検出する高度な性能を備えています。RDFビューによってセマンティク検出がリレーショナル表に拡張され、リレーショナル表のRDFトリプルへの変換は必要ありません。これにより、データを複製する必要がなくなります。また、リレーショナル・データ・セットにRDFグラフ問合せを実行するために関連する記憶域が以前は必要でしたが、これも必要なくなります。
RDFビューに対するセマンティク・グラフ問合せを使用すると、Oracle Databaseのリレーショナル・スキーマやRDFグラフ内外でのデータの統合と検出も可能になります。これにより、セマンティク検出ワークフローが単純になります。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
Oracle Spatial and Graphでは、World Wide Web Consortium (W3C)で定義されているように、Resource Description Framework (RDF)の名前付きグラフがサポートされます。RDFトリプルは、SQL INSERTおよびバルク・ロードを使用して1つ以上の名前付きグラフにロードできます。さらに、Oracle DatabaseのSesame AdapterおよびJena Adapterは、名前付きグラフによって拡張されたインタフェース、問合せおよびロードAPIをサポートします。また、一連の名前付きグラフに対するグローバル推論も、1つの名前付きグラフに対するローカル推論とともに、共通オントロジの有無にかかわらずサポートされます。
これにより、グラフ内の関連するトリプルの意味がある細分化を行うことが可能なスケーラブル・メカニズムが提供され、アプリケーション開発が単純になります。名前付きグラフ・レベルで、ロード、問合せおよび推論を実行できるようになりました。このために、コストが低くなり、これらの操作のパフォーマンスがセマンティク・ネットワーク全体に対する同様の操作に比べて向上します。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
Oracle Spatial and Graph RDFセマンティク・グラフでは、単純なパスと複雑なパスのSPARQL 1.1パス表現がサポートされるようになりました。RDFセマンティク・グラフは、ネットワーク・データ・モデルJava APIと組み合せて使用することもでき、高速のインメモリー・グラフ分析を提供します。これには、RDFグラフの最短パス、アクセス可能性、コスト内、最近傍の分析が含まれます。
Oracle Advanced Analyticsで使用するために、グラフ問合せの結果をビューとしてマテリアライズでき、これによって、Oracle Data Miningのクラスタ化、分類、回帰、異常検出、ディシジョン・ツリー・アルゴリズム、およびOracle R Enterpriseアルゴリズムを使用できるようになります。
また、ユーザー提供の推論拡張機能が、集計、算術および高度な分析の関数を実装できます。
このような拡張により、RDFグラフおよびトリプル・ストアで表現されるデータを、高度な分析ツールに送ることができ、アナリストが多くの情報を短時間で導出できるようになります。
組込みグラフ分析関数およびユーザー提供の推論拡張機能のサポートにより、アプリケーション開発が単純になります。また、クライアント・システムではなくサーバーに分析が統合され、セマンティク・グラフ・アプリケーションに共通する非常に大きなデータ・セットを処理します。さらに、ユーザー提供の推論拡張機能では、推論プロセスの関数や最適化、および生成される結果をユーザーが制御することもできます。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
現在、Oracle Spatial and Graph RDFセマンティク・グラフでは、Oracle Database XMLスキーマ、テキストおよび空間データ型がサポートされます。これには、データ型索引を追加、削除および変更するためのAPIも含まれます。
現在、XMLスキーマ、テキストおよび空間属性を使用して、SPARQLまたはSQLで記述されたセマンティク問合せをフィルタ処理することができます。これによって、キーワード、地理と距離、およびドキュメント構造に基づく問合せのパフォーマンスと選択性が向上します。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
ドキュメントのセマンティク索引APIは、サードパーティ・エンティティ抽出サービスの出力をRDFグラフにロードします。このグラフによって、ドキュメント・コレクションのエンティティの索引が提供されます。
機能拡張の内容は次のとおりです。
ドキュメントのバッチ索引付け。
エンティティ抽出エンジンと関連ルールを管理する柔軟性の高いフレームワーク。
ローカル・パーティションの索引付け。
また、検出されたドキュメントの関連性を計算する新しい演算子も提供されます。さらに、ドキュメントの推論を個別に行うか、ドメイン固有オントロジを備えたグループとして行うことができます。
Oracle Spatial and GraphでのRDFセマンティック・グラフ機能に対するこれらの拡張には、次の利点があります。
バッチ索引付けのサポートにより、大きなドキュメント・ワークロードを効率よく処理できるようになります。
同一ドキュメントに対する複数のエンティティ抽出ツールの構成と使用が単純化されます。
ドキュメントを処理する際に関連するパーティションにアクセスすることで、索引付け操作のパフォーマンスが向上します。
並列処理を有効化して、エンティティ抽出エンジンからのトリプルのロードを高速化します。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
Oracle Spatial and GraphのRDFセマンティク・グラフでは、新しい標準、標準の新バージョン、一般的なオープン・ソースやサードパーティのセマンティク・ツールがサポートされます。
現在、W3C SPARQL 1.1およびOpen Geospatial Consortium (OGC) GeoSPARQL 1.1言語標準に準拠しています。ネイティブの推論エンジンは最新のW3C OWL 2 ELプロファイルをサポートし、拡張性フレームワークはオープン・ソースの特殊推論機能(TrOWLやPelletなど)をサポートします。Oracle Spatial and Graph Jena Adapter機能の拡張には、SPARQLエンドポイントとSPARQL Gateway分散問合せが含まれます。これにより、一般的な分析ツールがXMLデータ・ソースにアクセスして、SPARQL問合せ結果を処理できるようになります。また、Jena Adapterには、問合せのタイムアウトと中止、SPARQL構文での問合せオプティマイザ・ヒント、プロパティ・パス、結果とメタデータのキャッシュ、ユーザー定義関数など、問合せの実行を制御および管理するために独特な拡張機能があります。
Oracle RDFセマンティク・グラフは、最新のW3C標準、OGC標準、およびオープン・ソース・フレームワークに準拠しています。このため、ユーザーは、Oracle Business Intelligence Enterprise Edition (OBIEE)やOracle Advanced Analytics (Oracle Data MiningおよびOracle R Enterprise)など、実績のあるリレーショナルおよびXMLベースのツールを利用でき、セマンティク問合せの結果を分析および視覚化できます。現在、Jena Adapterでは、中間層キャッシュや分散SPARQLエンドポイントのスケーラブル問合せを使用して、問合せパフォーマンスが最大で45%向上しています。
|
関連項目: 詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』を参照してください。 |
次の各項では、Oracle Database 12cリリース1 (12.1)の非構造化データ機能について説明します。
次の各項では、Oracle Multimediaの拡張について説明します。
Oracle Multimediaでは、Oracle Database 11g以来、Digital Imaging and Communications in Medicine (DICOM)形式のデータ型の管理をサポートしてきました。現在、Oracle MultimediaではDICOMプロトコルがサポートされており、これは、コンピュータ・ネットワークでDICOMイメージの通信を行うための世界標準です。これにより、ユーザーがDICOMプロトコルを使用してOracle DatabaseでのDICOMコンテンツの格納やアクセスを行うことができます。
DICOMアプリケーションおよびデバイスがOracle DatabaseのDICOMデータに容易にアクセスできるようになり、Oracle Databaseがクリニカル・ワークフローの中でDICOMコンテンツを格納および管理できます。Oracle Databaseツールを使用してDICOMコンテンツの大きなリポジトリを管理および保護することができ、管理コストが低減されます。電子医療レコード管理システムや他のアプリケーションへのイメージの組込みが単純化されます。
|
関連項目: 詳細は、『Oracle Multimedia DICOM開発者ガイド』を参照してください。 |
現在、Oracle Multimediaでは、Oracle WebCenter Contentが、Oracle DatabaseでDICOM (Digital Imaging and Communications in Medicine)コンテンツの格納およびアクセスを行うことができます。Oracle WebCenter Content DICOMデータ・ソースへのアクセスをサポートするDICOMプロトコル・アダプタと、DICOMビューアが含まれます。また、Oracle WebCenter Contentコンポーネントも含まれ、これによってDICOMメタデータがOracle WebCenter Contentストアに抽出され、サムネイル生成やWeb用のイメージ形式へのイメージ形式変換が実行されます。本来のリポジトリでのDICOMコンテンツへのアクセスと、Oracle WebCenter ContentへのDICOMコンテンツの転送の両方がサポートされます。
Oracle WebCenter ContentでのDICOMコンテンツのサポートにより、イメージ対応の患者向けポータル、委託医師用ポータル、電子医療記録(EMR)および生命科学研究アプリケーションの開発および管理が単純になります。
|
関連項目: 詳細は、『Oracle Multimedia DICOM開発者ガイド』を参照してください。 |
現在、Oracle Multimediaでは、Oracle Data Pumpを使用した完全モードのデータベース・エクスポートおよびインポートがサポートされます。これにより、Oracle Data PumpによるOracle Multimediaを使用したデータベースのエクスポートとインポート操作が単純化されます。Oracle Multimedia DICOMデータ・モデルの特殊な処理が必要なくなるためです。
|
関連項目: 詳細は、『Oracle Multimedia DICOM開発者ガイド』を参照してください。 |
次の項では、Oracle Textの拡張について説明します。
ニア・リアルタイム索引付けにより、最近変更された索引情報を、メモリーにとどまるように設計されている新しいステージング索引で管理することで、大量のDMLと索引を頻繁に同期させることができます。データは、索引最適化のための新しいMERGEモードを使用して、ステージング索引からメインの索引に定期的に移動できます。この新しいオプションはSTAGE_ITAB記憶域オプションを使用してオンにすることができます。
新しいステージング索引表は比較的小さく、メモリーに容易にキャッシュできます。メモリーに存在するとき、断片化されている索引のこの部分に対するコストは実質的にはありません。断片化された索引を、断片化されていないメイン索引から切り離すことで、パフォーマンスが向上し、ユーザーは、問合せのパフォーマンスを低下させずに索引を頻繁に同期させることができます。索引をTRANSACTIONALおよびSYNC(ON COMMIT)索引パラメータと一緒に使用すると、効率よく同期されます。
|
関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
ニア・リアルタイム索引と自動管理を組み合せると、バックグラウンド・タスクによって、データを小さな(通常はメモリー内の)$G表から大きな(通常はディスク上の)$I表に移動できるようになり、マージの最適化を実行する必要がなくなります。システムの負荷が高くない場合、自動管理プロセスはバックグラウンドで実行します。索引を自動的に最適化するには、管理システムに登録する必要があります。
この機能により管理が単純化され、ニア・リアルタイム索引のパフォーマンスが向上し、システムの速度を低下する手動でのマージ最適化のリスクを避けることができます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
新しい記憶域プリファレンスBIG_IOでは、TOKEN_INFOを格納するときに、可能であれば1つの大きなSecureFileデータベース・フィールドを使用し、4,000バイトに制限されるインラインBLOBSは使用しないように指定されます。これにより、大容量のTOKEN_INFOデータ・アイテムをディスクからロードするときに、多数のシークを実行する必要がなくなります。一般に順次I/OはランダムI/Oよりもかなり高速であり、パフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
DOCIDは索引化された用語を含むドキュメントを指定し、OFFSETは各ドキュメント内のそれらの用語の場所を指定します。
新しい記憶域プリファレンスSEPARATE_OFFSETSをBIG_IOと一緒に使用すると、DOCIDとOFFSETが索引内の別の場所に格納されます。
DOCIDリストは、前に結合されたTOKEN_INFOデータよりもかなり短くなります。このため、オフセット(つまり語の位置)情報が不要な1つの用語の問合せ、AND問合せおよび他の問合せを実行するために必要なI/Oを削減できます。このような問合せのパフォーマンスが向上します。オフセット情報が必要な問合せ(たとえば、語句検索または近接検索)はわずかに遅くなることがあります。
|
関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
SDATAセクションは、新しいPL/SQLパッケージCTX_DDL.UPDATE_SDATAを使用して更新できます。このパッケージでSDATAアイテムの値を更新すると、その行のすべてのデータの再索引付けを行う必要がありません。さらに、SDATAセクションの最大数は、32から99に増えました。
この機能によって、すぐに変更されるメタデータに関するパフォーマンスが向上します。たとえば、テキスト問合せに在庫水準を含める場合は、これをSDATAセクションにします。関連付けられる行には、在庫水準が変わるたびに再索引付けを行いたくない多くの情報を含めることをお薦めします。この新機能を使用すると、索引のSDATA部分だけを更新することができます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
SDATAセクションは、既存の索引に追加することができます。索引を最初から再構築する必要はありません。新しいSDATAセクションは、これ以降に追加または更新されるすべてのドキュメントで索引付けされます。前に索引付けしたドキュメントは影響を受けません。アプリケーションの柔軟性が向上し、稼動時間が長くなります。新しいビジネス要件を反映するように索引を変更でき、索引を最初から構築し直す必要もないためです。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
現在、問合せテンプレートでは、1つ以上のSDATAセクションによる順序付けがサポートされます。これにより、アプリケーション開発の柔軟性が向上し、標準のデータベース・ソートに比べて問合せが高速になります。
|
関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
以前は、フィールド・セクションは64個しか使用できませんでした。現在は、実質的に無制限のフィールド・セクション(10,000以上)を作成できます。フィールド・セクションのゾーン・セクションよりも効率的です。以前は、十分な数のフィールド・セクションを使用できないために、アプリケーションによってはゾーン・セクションを使用する必要がありました。この機能により、そのようなアプリケーションのパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
ドキュメントレベルのレクサーを使用すると、ユーザーは、様々なドキュメントに対する様々なレクサーとストップリスト・プリファレンスを索引に定義できます。これは、MULTI_LEXERおよびMULTI_STOPLIST機能を拡張したものですが、現在、レクサーの選択は言語に依存しません。この機能によりアプリケーションの柔軟性が向上します。様々なソースの様々なタイプのドキュメントでは、レクサーまたはストップワードの要件が異なる可能性があります。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
現在、使用可能なMDATAセクションの数が事実上無制限になりました。以前の最大数は100でした。この機能により、アプリケーションの柔軟性が向上します。複数のMDATAフィールドを結合して1つにする必要はなくなりました。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
新しいプロシージャPOLICY_LANGUAGESがCTX_DOCパッケージに追加されています。このプロシージャを使用して、テキスト・セクションの言語を識別できます。アプリケーションは、適切な方法でドキュメントを処理(たとえば、LANGUAGEメタデータ列の設定)するためにドキュメントの言語を識別できます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
現在、日本語VGRAMレクサーでは、コストがかかるワイルドカードの拡張が特定の日本語問合せで必要です。現在、Oracleによって日本語VGRAMレクサーのスイッチが提供され、BIGRAMモードのみを生成できるようになったため、ワイルドカード問合せの必要がなくなりました。この機能の利点は、日本語VGRAMレクサーで索引付けされたテキストに対する問合せパフォーマンスが向上することです。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
マイルド否定(MNOT)は、語句に含まれない語を検索するための新しい演算子です。たとえば、York市について言及する箇所を検索する場合、New Yorkという語句に含まれる語の検索を回避しようとします。ドキュメントによってはYorkとNew Yorkを参照している場合があるため、New Yorkを含むすべてのドキュメントを除外してもこの問題は解決されません。新しいMNOT演算子を使用するとこのようなセマンティクが可能になります。MNOT演算子によって、語を検索するときに、その語を含む不要な語句を除外することができ、、検索の精度とリコールが改善されます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
フォワード索引機能では、トークン化されて圧縮されたドキュメントがOracle Text索引に格納されます。つまり、強調表示やスニペット生成などの機能で、元のドキュメントのアクセス、フィルタ処理およびトークン化を行う必要がなくなります(これらは多くの場合コストが高いプロセスです)。
|
関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
NEAR演算子が改善され、NEAR演算子をネストできるようなり、NEAR演算子内でORコンストラクトを指定できるようになりました。このような拡張により、アプリケーションの作成の柔軟性が向上しています。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
パターン・ストップクラスを使用して、ユーザーが正規表現を指定でき、その正規表現と一致するトークンがストップワードとみなされます。言い換えれば、これは索引付けされず、問合せのときに有意とみなされません。
領域を節約して、パフォーマンスを向上させるために、不要な文字列(たとえば16進数や識別コードなど)を索引から取り除くことができます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
ストアド・クエリー式(SQE)は、よく使用される問合せ式を保存する方法です。セッション中SQEは、永続的に保存されるのではなく、現在のセッション中だけ存在します。これはセッション・メモリーに格納されるため、永続SQEよりもパフォーマンスが向上し、短期使用のSQEがアプリケーションで頻繁に作成されるときに生じる可能性がある混乱を回避できます。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
テキスト検索の一般的なシナリオでは、一連の特定の条件が多くの問合せで使用されます。たとえば、特定のユーザーのみに適した結果に限定するセキュリティ・フィルタを適用するとします。問合せフィルタ・キャッシュ機能では、特定の問合せ(または問合せの一部)の結果をキャッシュし、将来の検索をフィルタ処理するためにそれらの結果を使用できます。これは概念としてはストアド・クエリー式(SQE)の使用に似ていますが、パフォーマンスは上回ります。
この機能により、他の問合せとコンポーネントを共有する問合せののパフォーマンスが向上します。
|
関連項目: 詳細は、『Oracle Textリファレンス』を参照してください。 |
Oracle Database 11gの結果セット・インタフェースは、検索結果のページに必要な様々な種類のデータを同時に作成でき、オーバーヘッドを共有することでパフォーマンスを向上させました。結果セット・インタフェースは、カテゴリ問合せの上位n個の検索など、SQLで表すことが困難なデータ・ビューも戻すことができました。
スニペット情報と検索結果を一緒にエンド・ユーザーに示すには、Oracle Database 11gでは複数の反復処理が必要でした。Oracle Database 11gのアプローチでは、検索問合せを実行してから、その結果を反復処理して各行のスニペット情報を取得する必要がありました。
Oracle Database 12cリリース(12.1)では、結果セット・インタフェースのスニペット情報がネイティブでサポートされており、Oracle Database 11gの問題が解決されます。必要な場合に結果セット記述子にSNIPPETを定義するだけです。定義した場合、ユーザーが結果セットのスニペットを他の結果セットと一緒に取得します。
このサポートにより、結果セット・インタフェースに基づくアプリケーションが高速になり柔軟性が向上します。
|
関連項目: 詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。 |
次の項では、Oracle XMLの拡張について説明します。
ANYDATAの実装から、データ型がLOBまたはXMLTypeの属性を含む抽象データ型(ADT)と一緒に使用できないという制限が取り除かれました。この拡張により、Oracle ANYDATA実装の柔軟性が向上します。現在、データベース・エディションと一緒に使用できます。
|
関連項目: 詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
この機能により、OracleとBEA XQueryエンジンが統合されて、1つのJavaベースXQueryエンジンが作成され、これはXQuery 1.0勧告をサポートしており、Oracle Databaseの外部でXQuery言語を活用するために使用できます。また、XQuery API for Java (XQJ)もAPIとしてサポートされます。これは、JavaプログラムのXQuery文を実行するためのJava Specification Request (JSR)です。
この機能により、ユーザーはWorld Wide Web Consortium (W3C) XQuery言語の恩恵を受けることができます。既存のOracleエンジンとWebLogic XQueryエンジンが1つのエンジンに統合され、非常にスケーラブルで高性能のXQuery処理と開発者の生産性が組み合されます。
新しいXQueryエンジンでは、最新XQuery標準モジュールやXQuery Updateがサポートされます。これによって、Oracle Databaseで使用されるXQueryエンジンとの一貫性、XQueryデバッグのサポートおよびXQJのサポートが提供され、開発者の生産性が向上します。
新しいエンジンは、Oracle XMLテクノロジ(スケーラブルなDocument Object Model (DOM)処理や、Oracle DatabaseとOracle XML Developer's Kitで使用される新しいライブラリのXML形式を含む)を活用できます。このXQueryエンジンは、非常に大きなドキュメントや非常に多数の同時実行操作を処理することができます。
|
関連項目: 詳細は、『Oracle XML Developer's Kitプログラマーズ・ガイド』を参照してください。 |
W3C DOM Level 3 Core APIのサポートが追加され、XMLスキーマの使用に伴うメモリー・フットプリントが削減されます。
これらの改善点により、W3Cで定義されたとおりに、DOM Level 3.0 Core仕様の中で定義されたものも含めて、XML処理に使用される最新APIの恩恵を開発者が受けられるようになります。これによって、DOMのメモリー・フットプリントが減り、OracleによるスケーラブルなDOM (SDOM)のサポートが改善され、Oracle XDK/J DOM実装のパフォーマンスとスケーラビリティが向上します。
|
関連項目: 詳細は、『Oracle XML Developer's Kitプログラマーズ・ガイド』を参照してください。 |
現在、ドメイン索引を使用するアプリケーションは、ハッシュ・パーティション化方法を使用できます。Oracle XML DBはハッシュ・パーティションをサポートするようになりました。(レンジ・パーティション化とリスト・パーティション化の他に)ハッシュ・パーティション化を使用してパーティション化されたXMLType表および列に対して、パーティション化されたローカルのXMLIndex索引を作成できます。ハッシュ・パーティション化は、一連のパーティションにI/Oを均等に分散させるために効果的な方法です。
|
関連項目: 詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』および『Oracle XML DB開発者ガイド』を参照してください。 |
この機能により、非XDKベースのデータ・モデルをOracle XDK/J、XSLTまたはXPathエンジンで使用できるようになり、これらのOracleエンジンとサードパーティのXMLプロセッサの相互運用がサポートされます。
Oracle XDK/J、XSLTおよびXPathエンジンとサードパーティXMLプロセッサの相互運用が可能になります。
以前のリリースでは、スケーラブルなDocument Object Model (DOM)を作成できるのはOracleのXMLパーサーのみでした。つまり、スケーラブルなDOMは既存のXMLドキュメントからしか作成できませんでした。この機能により、開発者が、スケーラブルなDOMの技術に基づき、標準のDOM APIを使用して、新しいXMLドキュメントをプログラムによって作成および操作できるようになることで、この制約が取り除かれます。
この機能により、開発者が、従来のインメモリーDOMのかわりにOracleのスケーラブルなDOMのインスタンスを作成することで、非常に大きなXMLドキュメントをプログラムで作成および操作できます。その後、Oracle XDK/J DOM実装で提供される標準のDOM APIを使用してスケーラブルなDOMを操作できます。
Oracle XQuery仮想マシンのすべての機能にスタンドアロン・アプリケーションを使用してアクセスできます。これにより、Oracle Databaseを操作せずに、XQuery式をコマンドラインから直接実行できます。
また、Oracle XQuery仮想マシンが拡張され、XQuery Update標準と新しいXQueryスクリプト言語のサポートが追加されています。Oracle XQuery仮想マシンおよびデータベースは、同じネイティブXML形式を共有することもでき、Oracle XQuery仮想マシンがデータベースのXMLを処理できます。このとき、該当するXMLをシリアライズして解析するオーバーヘッドは発生しません。
Oracle XQuery仮想マシンは、現在Oracle Databaseのみに含まれている高性能のXQueryプロセッサです。スタンドアロン・コマンドライン・モードを有効にすると、データベース内でのXQueryの実行が適切でない状況でも、Oracle XQuery仮想マシンを使用してXQuery操作を実行できます。
この機能により、XQueryフルテキスト拡張機能のサポートが追加され、W3C XQuery仕様に対するOracleのサポートが拡張されます。これにより、ユーザーが、データベースに格納されているXMLコンテンツに対してXML対応のフルテキスト検索を実行できます。
|
関連項目: 詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
この機能では、Fast InfosetのサポートがXDK/Jモデルに追加され、開発者がJavaのXMLコンテンツを扱うときにFast Infoset技術を使用できるようになります。
Fast Infosetには、他の形式と比較して、次の利点があります。
大きさが小さく、速く解析でき、XMLドキュメントよりもよくシリアライズできます。
Xercesパーサーの5倍の速さで解析でき、シリアライズは3倍の速さで行えます。通常、Fast Infosetドキュメントは、対応するXMLドキュメントの20～60 %の大きさになります。
パフォーマンスと圧縮率に関して他のバイナリXML形式よりも優れ、小さなドキュメントから大きなドキュメントまでバランスよく処理できます。
|
関連項目: 詳細は、『Oracle XML Developer's Kitプログラマーズ・ガイド』を参照してください。 |
これにより、Oracle Database 11gリリース1 (11.1)で導入された既存のCおよびPL/SQL XmlDiff機能と互換性がある形式の、JavaベースのXmlDiffのサポートが追加されます。
この機能により、Pure Javaで記述された中間層プログラムが、Cで記述されたプログラムまたはOracle Databaseを使用してXmlDiff操作を実行するプログラムと、XmlDiff出力を交換できます。
|
関連項目: 詳細は、『Oracle XML Developer's Kitプログラマーズ・ガイド』を参照してください。 |
XQuery Update勧告のサポートが追加され、ユーザーがW3C標準問合せ言語を使用してフラグメントおよびノードレベルの更新を実行できるようになりました。
このサポートにより、Oracle XML DBによって管理されるXMLコンテンツに対するフラグメントレベルの更新を、標準に基づいたパフォーマンスの高い方法でユーザーが実行できます。また、このサポートにより、XQuery Update構文を使用して記述されたXMLベースのアプリケーションをOracle Databaseに移植できます。
この機能により、OracleのXPath 1.0ベースのDML演算子が、XQueryの恩恵を十分に受ける単純な標準ベースのアプローチで置き換えられ、開発者の生産性が向上します。
|
関連項目: 詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
次の項では、Oracle XMLリポジトリの拡張について説明します。
ダイジェスト認証は、クライアントとサーバーがパスワードをプレーン・テキストで送信せずに認証トークンを交換できる業界標準メカニズムです。このメカニズムにより、パスワードが送信中に漏えいする可能性が低減されます。
Oracle XML DBのダイジェスト認証のサポートによって、Oracle XML DB HTTPサーバーとMicrosoft Web Folders WebDAVクライアントの互換性が保証されます。
この機能はダイジェスト認証のサポートを追加することで、データベース・セキュリティを強化します。ダイジェスト認証は、HTTPプロトコルで一般に使用される業界標準のプロトコルで、ほとんどのHTTPクライアントでサポートされています。ダイジェスト認証により、暗号化(HTTPS)接続が使用されない場合でも、パスワードが常にセキュアな方法で送信されます。ダイジェスト認証のサポートにより、企業はパスワードの漏えいを懸念せずに、Oracle XML DB HTTPを活用するアプリケーションをデプロイできます。
|
関連項目: 詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
この機能では、Oracle XML DBのサポートをDBFSに拡張することで、WebDAV、HTTPおよびFTPでDatabase File System (DBFS)にアクセスできるようになります。現在、DBFSファイル・システムに格納されるファイルは、World Wide Web上で共同して編集や管理を行うことができます。従来のファイル・システムと同様のアクセス方法が、Linux以外のプラットフォーム上のDBFSファイル・システムにまで拡張されました。
|
関連項目: 詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
次の各項では、Oracle Database 12cリリース1 (12.1)のアップグレードの拡張について説明します。
次の各項では、一般的なアップグレードの機能と拡張について説明します。
データベースのアップグレードは、アップグレード・プロセスの自動化を進めることで、より使用しやすくなるように拡張されました。コマンドラインのアップグレード前スクリプトとDatabase Upgrade Assistant (DBUA)の両方で、アップグレード前のフェーズに、新たな検証ステップが追加されました。さらに、アップグレード前の検証ステップが、アップグレード前に特定される可能性のある大部分の問題を解決する修正スクリプトを生成する機能により拡張されました。
アップグレード後のステップも拡張され、データベースのアップグレードに必要な手動作業の量が減りました。アップグレード後のステータス・スクリプトでは、コンポーネントごとにアップグレードの成功について説明的に案内します。アップグレード後の修正スクリプトも生成され、アップグレード後に実行する必要のある作業を自動化します。
|
関連項目: 詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。 |
データベース・アップグレード・スクリプトは、パラレル処理を使用することで、複数のCPUコアを利用できるようになり、アップグレード・プロセスが迅速化されました。その結果、データベースのアップグレードによる停止時間は短縮され、データベースの可能性が向上しました。
|
関連項目: 詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。 |
次の項では、Oracle Database 12cリリース1 (12.1)のWindowsに関する新機能について説明します。
次の各項では、Windows上のOracle DatabaseでのWindowsセキュリティの統合について説明します。
Oracle Database 12cリリース1 (12.1)以降、Oracle Databaseでは、インストール時に指定されるOracleホーム・ユーザーの使用がサポートされます。Oracleホーム・ユーザーは、Oracleホームから実行されるOracleサービスの所有者で、インストール後は変更できません。1つのシステム上の異なるOracleホームが、同じOracleホーム・ユーザーを共有するか、様々なOracleホーム・ユーザー名を使用することができます。
Oracleホーム・ユーザーには、Windowsの組込みアカウントまたは標準のWindowsユーザー・アカウント(管理者アカウント以外)を指定できます。このアカウントはOracleホームのWindowsサービスの実行に使用されます。データベース・サーバーのインストールでは、セキュリティ強化のため、Oracleホーム・ユーザーとして(Windows組込みアカウントではなく)標準のWindowsユーザー・アカウントを使用することをお薦めします。
Oracle RAC Databaseの場合、Oracleホーム・ユーザーは、Windowsドメイン・ユーザー・アカウントで、既存のWindowsアカウントであることが必要です。
|
関連項目: 詳細は、『Oracle Databaseプラットフォーム・ガイド』を参照してください。 |
Oracle Database 12cでは、Oracle Net Services (Oracle Net Listener、Oracle Connection Manager Administration (CMADMIN)、Oracle Connection Manager (CMAN)プロキシ・リスナーなど)を、Oracle Databaseのインストール時に指定されたOracleホーム・ユーザー・アカウントとして実行できます。以前のリリースでは、Oracle Net Servicesは、高い権限の組込みローカル・システム・アカウント(LSA)として実行していました。この機能により、セキュリティをさらにきめ細かく制御できるようになります。
|
関連項目: 詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
Windowsサービスは、組込みアカウントまたは名前付きユーザーを使用して、Windowsオペレーティング・システムで実行できます。Oracle RACでは様々なOracle RACサービスを様々なユーザーとして実行できます。ただし、同じOracle Grid Infrastructure環境が共有されます。
サービスでの指定ユーザーの使用により、Oracle RAC環境を作成する際の柔軟性が向上します。また、必要に応じてOracle RACベースの統合を有効にし、義務の分離を保証します。
|
関連項目: 詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
