| Oracle® Database開発ガイド 12c リリース1 (12.1) B71295-06 |
|
 前 |
 次 |
内容は次のとおりです。
『Oracle Database開発ガイド』では、Oracle Database 12cリリース1 (12.1.0.2)の1つの新機能について説明します。
リリース12.1.0.1で、フラッシュバック・データベース・アーカイブはマルチテナント・コンテナ・データベース(CDB)でサポートされていませんでした。
リリース12.1.0.2から、この制限は解除されます(16.12項「マルチテナント・コンテナ・データベースでのOracle Flashback Technologyの制限」を参照)。
Oracle Database 12cリリース1 (12.1.0.1)の『Oracle Database開発ガイド』における変更点は次のとおりです。
このリリースの新機能は次のとおりです。
アプリケーション・コンティニュイティは、計画済および計画外のリカバリ可能な停止後にリクエストをリカバリすることで、エンドユーザーとアプリケーションから停止をマスクしようとします。アプリケーション・コンティニュイティはこのリカバリをアプリケーション外で実行するため、停止がアプリケーションでは遅れた実行のように表れます。
アプリケーション・コンティニュイティはリカバリ可能な停止をマスキングします(その中でリクエストが再発行されるとそれらのリクエストは成功します)。たとえば、システム障害、ネットワークの切断、フォアグラウンド障害、ストレージ障害などがあります。
Javaのアプリケーション・コンティニュイティは、Oracle Database、JDBC Thinドライバ、およびOracle Database接続プール(UCP (Universal Connection Pool)およびWebLogic Server Active GridLink)で使用可能です。
アプリケーション・コンティニュイティは、Oracle JDBCを使用し、Oracle Database接続プール(UCPまたはWLS Active GridLink)を使用するが、外部アクションを持たないJava EEおよびJava SEアプリケーションにとって透過的です。外部アクション(自律型トランザクション、またはUTL_HTTPを使用したSOAコールを発行するトランザクションの使用など)の場合、障害後にこれらの外部アクションがリプレイされるときにアプリケーションの正確性が保持されている場合、アプリケーション・コンティニュイティは透過的なままです。
詳細は、第26章「アプリケーション・コンティニュイティの有効化」を参照してください。
リリース12.1.0.1より前には、Oracle Database (サーバー)がアプリケーション(クライアント)に返すコミット・メッセージが永続的でなかったため、停止後にデータベース・アプリケーションをリカバリすることは困難でした。Oracle Databaseとアプリケーションの間で接続が切断された場合や、データベース・セッションが使用不可になった場合、アプリケーションは切断のエラー・メッセージを受信しましたが、そのメッセージでアプリケーションが次のような質問に応答することはできませんでした。
進行中のトランザクション(接続が中断されたときに実行中だったトランザクション)はコミットされたか。
進行中のトランザクションに、ストアド・サブプログラムの呼出しが含まれていた場合:
サブプログラムは正常終了し、予定されていたコミットとセッション状態変更をすべて実行したか。
サブプログラムは中断されたか。
サブプログラムはOracle Databaseで引き続き実行されているか、アプリケーションから切断されたか。
例外コードを使用してコミット・ポイントごとに結果を問い合せることにより、アプリケーションは進行中のトランザクションがコミットされたかどうかの判定の試行が可能でした。各問合せは、結果を求めるトランザクション固有である必要がありました。次の理由から、このアプローチは現実性に乏しく(特にアプリケーションが本番稼働した後では)、エラーも発生しがちでした。
問合せの直後にトランザクションがコミットされた可能性があります。
トランザクションに、ストアド・サブプログラムの呼出しが含まれていた場合:
Oracle Databaseはまだサブプログラムを実行している可能性があるため、問合せ結果がアプリケーションに返された後でデータベースの変更がコミットされた可能性があります。
サブプログラムがPL/SQLまたはJavaで記述されていた場合は、サブプログラムが正常終了したか中断されたかをアプリケーションで判定できない可能性があります。
中断されたサブプログラムは、後続のセッション状態変更を行わずにデータベース変更をコミットした可能性もあります。
停止後に、コミットされた進行中のトランザクションをアプリケーション・ユーザーが再発行すると、トランザクションが重複して返されます。
リリース12.1.0.1では、Oracle Databaseにトランザクション・ガードが導入され、各トランザクションは必ず最大1回のみ実行されるようになります。PL/SQLインタフェースでDBMS_APP_CONT.GET_LTXID_OUTCOMEプロシージャを使用すると、アプリケーションは停止後に進行中トランザクションの結果判定が可能になり、続いて停止のために失われた作業をリカバリできます。詳細は、第25章「トランザクション・ガードの使用」を参照してください。
Oracle Databaseでは時間的な有効性がサポートされているため、有効時間ディメンションを表に関連付け、時間ベースの妥当性に基づいてデータを表示できます。時間は、特定のレコードが有効とみなされる期間の開始日と終了日またはタイムスタンプによって決定されます。
時間的な有効性のサポートは、次のようなシナリオで役立ちます。
情報ライフサイクル管理(ILM)など、特定のデータがいつ有効になったか(アプリケーションの観点から)、いつ無効になったか(無効になった場合)を把握することが重要なアプリケーション
有効とみなされていた期間をマークしたうえで不正確なデータを保持しておき、正しいデータを現在有効であると表示する必要がある、データ修正
詳細は、1.9.4項「時間的な有効性のサポート」を参照してください。
リリース12.1.0.1より前では、定義者権限(DR)のユニットは常に定義者の権限で実行され、実行者権限(IR)のユニットは常に実行者の権限で実行されていました。すべてのユーザーが呼び出せるPL/SQLユニットを作成する場合には、その権限が自身の権限より低い場合でも、DRユニットとして作成する必要がありました。DRユニットは、呼び出したユーザーにかかわらず常に自身のすべての権限で実行されました。
リリース12.1.0.1から、個々のPL/SQLパッケージとスタンドアロン・サブプログラムにロールを付与できます。DRユニットのかわりにIRユニットを作成し、それにロールを付与できます。IRユニットは、実行者とそのロールの両方の権限で実行されますが、それ以外の権限は追加されません。
詳細は、11.8項「ストアドPL/SQLサブプログラムの起動」を参照してください。
12.1.0.1より前のリリースでエディションベースの再定義(EBR)を使用するとき、アプリケーション・データをアップグレード前の(旧エディションの)形式からアップグレード後の(新エディションの)形式に変換するには、行ごとにUPDATE操作が必要であり、膨大なコストと時間が必要でした。
リリース12.1.0.1では、DBMS_EDITIONS_UTILITIES.SET_NULL_COLUMN_VALUES_TO_EXPRを呼び出し、メタデータ操作を使用してアプリケーション・データを変換することもあります。詳細は、24.3.5項「アップグレード前の表現をアップグレード後の表現に変換」を参照してください。
|
参照: DBMS_EDITIONS_UTILITIES.SET_NULL_COLUMN_VALUES_TO_EXPRプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください |
リリース12.1.0.1より前では、スキーマ・オブジェクトが対応可能になるのは、そのタイプがデータベースでエディション対応であり、その所有者がエディション対応である場合でした。エディション対応のユーザーは、エディション対応タイプの非エディション・オブジェクトを所有できませんでした。
非エディション・オブジェクト(表など)がエディション・オブジェクト(エディション対応スキーマにおけるユーザー定義タイプなど)を参照すると、エラーが発生していました。これを回避するには、エディション対応ではないスキーマで参照されるオブジェクトを作成する必要がありました。
リリース12.1.0.1では、次のように変更されます。
スキーマ・オブジェクトは、そのオブジェクトを所有するスキーマでそのタイプがエディション対応であり、そのオブジェクトがEDITIONABLEプロパティを持つ場合にエディション対応になります。エディション対応のユーザーは、スキーマにおいてタイプが非エディションであるか、オブジェクトにNONEDITIONABLEプロパティがある場合に、データベースでエディション対応であるタイプの非エディション・オブジェクトを所有できます。
通常、非エディション・オブジェクトがエディション・オブジェクトを参照する場合には、名前解決時にエディション・オブジェクトが非表示になり、「該当するオブジェクトなし」のエラーが発生します。
名前解決時にエディション・オブジェクトの検索のためにエディションを指定できる非エディション・オブジェクト(評価エディション)は、エディション・オブジェクトに依存できます。
詳細は、24.1.1項「エディション・オブジェクトと非エディション・オブジェクト」を参照してください。
リリース12.1.0.1より前には、PL/SQLストアド・サブプログラムはSQL問合せからOUT REF CURSORパラメータを通じて明示的に結果セットを返しました。そのため、そのサブプログラムを呼び出すクライアント・プログラムは、それらのパラメータに明示的にバインドして結果セットを受け取る必要がありました。
リリース12.1.0.1では、OUT REF CURSORパラメータのかわりにPL/SQLパッケージDBMS_SQLを使用すると、PL/SQLストアド・サブプログラムで問合せ結果を暗黙的にそのクライアントに返すことができます。この方法により、サード・パーティ製データベースのストアド・サブプログラムから問合せ結果を暗黙的に返すことに依存するアプリケーションから、Oracle Databaseに移行することが容易になります。詳細は、11.4.5.3項「問合せ結果の暗黙的戻し」を参照してください。
データベース・アプリケーションを複数のPL/SQLパッケージとして実装できます。このうち、1つのパッケージがアプリケーション・プログラミング・インタフェース(API)を提供し、ヘルパー・パッケージが処理を実行します。理想的には、このAPIのみにクライアントからアクセスします。
また、同じスキーマ内の他のPL/SQLユニットのみにサービスを提供するユーティリティ・パッケージを作成できます。理想的には、ユーティリティ・パッケージは目的のPL/SQLユニットのみがアクセスできます。
リリース12.1.0.1より前のPL/SQLでは、ヘルパー・パッケージで公開されたアイテムをクライアントが使用することを禁止できませんでした。このようなアイテムを分離するには、リレーショナル・データベース管理システム(RDBMS)のセキュリティ機能を使用する必要がありました。アプリケーションのデプロイ方法によっては、RDBMSのセキュリティ機能を使用することが困難でした。
リリース12.1.0.1では、それぞれの文にオプションでACCESSIBLE BY句を使用し、作成または変更しているPL/SQLユニットにアクセスできるPL/SQLユニットの「ホワイト・リスト」を指定できます。
CREATE FUNCTION (詳細は、『Oracle Database PL/SQL言語リファレンス』を参照)
CREATE PACKAGE (詳細は、『Oracle Database PL/SQL言語リファレンス』を参照)
CREATE PROCEDURE (詳細は、『Oracle Database PL/SQL言語リファレンス』を参照)
CREATE TYPE (詳細は、『Oracle Database PL/SQL言語リファレンス』を参照)
ALTER TYPE (詳細は、『Oracle Database PL/SQL言語リファレンス』を参照)
ACCESSIBLE BY句は、Oracle Databaseの標準セキュリティ・メカニズムを補完します。これ以外の不正な参照を認可することはできません。
ACCESSIBLE BY句を変更すると、緩やかな無効化の原因になります(表23-2を参照)。
リリース12.1.0.1より前には、SQLデータ型ではない仮パラメータや戻り型をとるPL/SQLファンクションをSQL式から呼び出すことはできませんでした。ただし、このルールの例外として、対応する実パラメータが暗黙的に仮パラメータのデータ型に変換される場合には、その仮パラメータはPL/SQLデータ型を持つことができました。
リリース12.1.0.1では、この制限がなくなります。残りの制限については、11.9.3項「SQL式の中でPL/SQLファンクションを使用できる条件」を参照してください。
リリース12.1.0.1では、SQLより高速で実行される2種類のPL/SQLファンクションがあります。
SQL SELECT文のWITH句で宣言および定義されるPL/SQLファンクション(詳細は、『Oracle Database SQL言語リファレンス』を参照してください)
UDFプラグマで定義されるPL/SQLファンクション。(詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください)
クライアントの自動チューニングは、中間層アプリケーションのOCIクライアント・セッション機能の構成パラメータを透過的に最適化し、OCIアプリケーションを再プログラミングすることなく、アプリケーションのパフォーマンス向上を図る機能です。
oraaccess.xmlファイル(クライアント側構成ファイル)が提供されており、選択するOCIパラメータをデプロイメント時設定として構成するために使用できます(これらの一部は、文キャッシュや文プリフェッチなど、各種OCI APIコールでプログラム的に受け入れられます)。これにより、OCIをコールするソース・コードを変更せずに、デプロイメント中にOCIの動作を変更できるようになります。
これらの設定は、OCI機能のユーザー構成の手動設定をオーバーライドするクライアントのoraaccess.xmlファイル内の接続文字列ベースのデプロイメント設定として提供されています。
クライアント自動チューニングの詳細は、2.9項「OCIクライアント文キャッシュの自動チューニング」を参照してください。
このガイドで以前に記述されていた機能の一部は、リリース12.1.0.1でサポートされない可能性があります。サポート対象外機能のリストは、『Oracle Databaseアップグレード・ガイド』を参照してください。
このマニュアルのタイトルは、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』から『Oracle Database開発ガイド』に変更されました。このタイトル変更は、このマニュアルの拡張と調整を反映した結果です。たとえば、新しい第I部「データベース開発の基礎」では、データベース開発者(DBAとデータベース・アプリケーション開発者の両方)にとって重要な内容と手法が導入され、詳細情報については、他の章やマニュアルを参照しています。
第21章「Oracle ODBC Driverの使用方法」は、Oracle ODBC Driverヘルプ・ファイルと同じ内容ですが、この章には用語集がありません。
第25章「トランザクション・ガードの使用」では、主要な新機能であるトランザクション・ガードについて説明します。トランザクション・ガードでは、トランザクションの冪等性(トランザクションの最大1回実行)が保証され、トランザクションの論理トランザクション識別子を使用して、オープンになっている最終トランザクションの結果が判断されます。
第26章「アプリケーション・コンティニュイティの有効化」では、主要な新機能であるアプリケーション・コンティニュイティについて説明します。アプリケーション・コンティニュイティでは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、透過的で迅速な方法で、データベースに対してトランザクションのリプレイが有効化されます。
第25章および第26章では、トランザクション・ガードとアプリケーション・コンティニュイティの関係について説明し、実装の詳細について関連マニュアルを示しています。
