ここでは、このマニュアルに記載されているPL/SQLの新機能について簡単に説明し、詳細情報へのリンクを示します。
ここでのトピック
セッションが存続する間パッケージの状態が一定である場合、パッケージはステートレスとして処理されます。
リリース11.2.0.2より前は、あるセッションによってステートフルなパッケージの本体が再コンパイルされ、そのパッケージをインスタンス化した別のセッションによってそのパッケージが参照されると、後者のセッションでは重大なエラーORA-04068(パッケージの既存状態は廃棄されました。)が発生しました。そのため、パッケージにホット・パッチを適用することによって、ユーザーは中断される可能性が高くなりました。
リリース2(11.2.0.2)の時点では、セッションが存続する間(またはそれより長い間)パッケージの状態が一定である場合、パッケージはOracle Databaseにステートレスとして処理されます。これは、パッケージの項目がすべてコンパイル時定数になっているパッケージの場合です。そのため、パッケージへの「ホット・パッチの適用」によって、それらを使用しているセッションが中断される可能性は低くなります。
詳細は、「パッケージの状態」を参照してください。
Oracle Database 11gリリース2でのPL/SQLの機能は、次のとおりです。
DBMS_PARALLEL_EXECUTEパッケージ
DBMS_PARALLEL_EXECUTE
パッケージを使用すると、次の2つの手順で、大規模な表のデータをパラレルで増分更新できます。
表内の一連の行を、より小さいチャンクにグループ化します。
必要なUPDATE
文をパラレルでチャンクに適用し、1つのチャンクの処理が終わるたびにコミットします。
大量のデータを更新する場合は、常にこの方法を使用することをお薦めします。これによって、パフォーマンスが向上し、ロールバックによる領域消費が削減され、保持される行ロック数が削減されます。
詳細は、「大規模な表のパラレルでの更新」を参照してください。
CREATE TYPE文のFORCEオプション
Oracle Database 11gリリース2より前は、型依存性または表依存性のある既存のタイプをCREATE
OR
REPLACE
TYPE
文で指定すると、ORA-02303エラーが発生して文の実行は失敗していました。
Oracle Database 11gリリース2以降は、このような場合にFORCE
を指定すると、表依存性がある場合にのみ文は失敗し、型依存性がある場合には失敗しなくなっています。詳細は、「CREATE TYPE文」を参照してください。
crosseditionトリガー
crosseditionトリガーは、表を使用するオンライン・アプリケーションに対して、エディション・ベースの再定義によってパッチ適用またはアップグレードが実行されているときに、データベース操作言語(DML)がデータベース表を変更すると起動されます。crosseditionトリガーの本体は、このような変更を処理するように設計されているため、アプリケーション・コードに対する変更が完了した後で変更を適切に適用できます。
詳細は、「CREATE TRIGGER文」を参照してください。
関連項目: エディション・ベースの再定義に関する一般的な情報およびcrosseditionトリガーとエディションとの関係などのcrosseditionトリガーの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
エディションされたADTについてのALTER TYPE文の制限
エディション・ベースの再定義を使用して、アプリケーションにパッチを適用するかまたはアプリケーションをアップグレードする場合は、エディションされたオブジェクトを使用します。いずれかのエディションされたオブジェクトが抽象データ型(ADT)の場合、「型の制限」を参照してください。
関連項目: エディション・ベースの再定義に関する一般的な情報およびエディションされたオブジェクトの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
ALTER TYPE文のRESETオプション
ALTER
TYPE
文のRESET
オプションは、型のバージョンを1に再設定し、進化の対象とみなされないようにします。RESET
は、所有者に対してエディションが有効にならないようにする進化したADT向けです。詳細は、「ALTER TYPE文」を参照してください。
関連項目: エディションの有効化の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
結果がキャッシュされるファンクションのデータソースの自動検出
Oracle Database 11gリリース2より前は、結果がキャッシュされるファンクションが依存するデータソースを指定する必要がありました。
Oracle Database 11gリリース2以降は、結果がキャッシュされるファンクションの実行中に問い合せられるすべてのデータ・ソースをOracle Databaseが自動的に検出します。詳細は、「PL/SQLファンクション結果キャッシュ」を参照してください。
プライベートではなくなったOracle RAC環境での結果キャッシュ
Oracle Database 11gリリース2より前は、Oracle RAC環境では、各データベース・インスタンスに、そのインスタンス上のセッションでのみ使用できるプライベートなファンクション結果キャッシュがありました。必要な結果がローカル・インスタンスのプライベート・キャッシュから欠落している場合、ファンクションの本体が実行されて、結果が計算され、その後、この結果がローカル・キャッシュに追加されました。この結果が別のインスタンスのプライベート・キャッシュから取り出されることはありませんでした。
Oracle Database 11gリリース2以降は、各データベース・インスタンスで独自のローカル結果キャッシュを管理しますが、そのローカル結果キャッシュはプライベートではなくなりました(リモート・データベース・インスタンスにアタッチされたセッションからその内容にアクセスできます)。必要な結果がローカル・インスタンスの結果キャッシュから欠落している場合、ローカルで計算するのではなく、他のインスタンスのローカル・キャッシュから結果が取り出される場合があります。詳細は、「Oracle RAC環境での結果キャッシュ」を参照してください。
Oracle Database 11gリリース1でのPL/SQLの機能は、次のとおりです。
正規表現SQLファンクションへの拡張機能
正規表現SQLファンクションREGEXP_INSTR
およびREGEXP_SUBSTR
では、機能が強化されています。新しい正規表現SQLファンクションREGEXP_COUNT
では、文字列にパターンが出現する回数が戻されます。このファンクションはSQLおよびPL/SQLでの場合と同じ働きをします。
関連項目:
|
SIMPLE_INTEGER、SIMPLE_FLOATおよびSIMPLE_DOUBLEデータ型
SIMPLE_INTEGER
、SIMPLE_FLOAT
およびSIMPLE_DOUBLE
データ型は、それぞれPLS_INTEGER
、BINARY_FLOAT
およびBINARY_DOUBLE
の事前定義のサブタイプです。各サブタイプはそのベース型と同じ範囲を取り、NOT
NULL
制約を含んでいます。
SIMPLE_INTEGER
とPLS_INTEGER
との大きな違いは、オーバーフローの方法です。ただし、SIMPLE_FLOAT
とSIMPLE_DOUBLE
は、NOT
NULL
制約を除いて、そのベース型と同じです。
SIMPLE_INTEGER
は、値がNULL
になることがなく、オーバーフロー・チェックが不要な場合に使用できます。SIMPLE_FLOAT
およびSIMPLE_DOUBLE
は、値がNULL
になることがない場合に使用できます。SIMPLE_INTEGER
値に対する算術演算はハードウェアで直接実行されるため、これらのサブタイプを使用すると、NULLかどうかのチェックおよびオーバーフロー・チェックのためのオーバーヘッドが発生せず、PLSQL_CODE_TYPE='NATIVE'
の場合、そのベース型を使用するよりパフォーマンスが大幅に向上します。PLSQL_CODE_TYPE='INTERPRETED'
の場合、パフォーマンスの向上は少なくなります。
詳細は、次の項を参照してください。
CONTINUE文
CONTINUE
文は現行のループの反復を終了して、次の反復に制御を移します(ループを終了して、そのループの最後に制御を移すEXIT
文とは対照的です)。CONTINUE
文には、無条件CONTINUE
と条件付きCONTINUE
WHEN
という2つの形式があります。
詳細は、次の項を参照してください。
PL/SQL式の順序
擬似列CURRVAL
およびNEXTVAL
を使用すると、PL/SQLのソース・テキストの記述が簡単になり、実行時のパフォーマンスとスケーラビリティが向上します。sequence_name
.CURRVAL
およびsequence_name
.NEXTVAL
は、NUMBER
式を使用できるすべての場所で使用できます。
詳細は、「PL/SQLのCURRVALおよびNEXTVAL」を参照してください。
動的SQLの拡張
システム固有の動的SQLとDBMS_SQL
パッケージの両方が拡張されています。
システム固有の動的SQLでは、CLOB
型にできるようにすることで32KBを超える動的SQL文がサポートされています。「EXECUTE IMMEDIATE文」および「OPEN FOR文」を参照してください。
DBMS_SQL
パッケージは、次のように拡張されています。
システム固有の動的SQLでサポートされているすべてのデータ型がサポートされています。
DBMS_SQL.PARSE
ファンクションは、CLOB
引数を受け入れることによって、32KBを超える動的SQL文を実行できます。
新しい「DBMS_SQL.TO_REFCURSORファンクション」を使用することによって、DBMS_SQL
パッケージからシステム固有の動的SQLに切り替えることができます。
新しい「DBMS_SQL.TO_CURSOR_NUMBERファンクション」を使用することによって、システム固有の動的SQLからDBMS_SQL
パッケージに切り替えることができます。
PL/SQLサブプログラムの起動での名前表記法および混合表記法
Oracle Database 11gリリース1より前は、PL/SQLサブプログラムを起動するSQL文には、実パラメータを位置表記法で指定する必要がありました。Oracle Database 11gリリース1以降は、名前表記法および混合表記法も使用できるようになっています。これによって、SQL文がデフォルトのパラメータを多数持つPL/SQLサブプログラムを起動する際の操作性が向上し、デフォルト値とは異なる値にする必要がある実パラメータがほとんどなくなっています。
一例として、例8-24
のSELECT文を参照してください。
PL/SQLファンクション結果キャッシュ
ファンクション結果キャッシュを使用すると、領域と時間を大幅に節約できます。結果がキャッシュされるファンクションが異なるパラメータ値で起動されるたびに、それらのパラメータおよびそれぞれの結果がキャッシュに格納されます。それ以降、同じファンクションが同じパラメータ値で起動されると、結果は再計算されるのではなく、キャッシュから取り出されます。
Oracle Database 11gリリース1より前は、PL/SQLアプリケーションでファンクションの結果をキャッシュする場合、キャッシュとキャッシュ管理サブプログラムを設計およびコーディングする必要がありました。複数セッションでアプリケーションを実行する場合、各セッションではそのキャッシュおよびキャッシュ管理のサブプログラム・コピーが必要でした。各セッションで同じ高価な演算を実行する必要がある場合もありました。
Oracle Database 11gリリース1以降は、PL/SQLによってファンクション結果キャッシュが提供されます。これを使用するには、結果がキャッシュされるようにする各PL/SQLファンクションでRESULT_CACHE
句を使用します。ファンクション結果キャッシュは、共有グローバル領域(SGA)に配置されるため、アプリケーションを実行するすべてのセッションで使用できます。
アプリケーションをPL/SQLファンクション結果キャッシュに変換すると、アプリケーションによって使用されるSGAは増加しますが、システム・メモリーの合計使用量は大幅に減少します。
詳細は、次の項を参照してください。
複合DMLトリガー
表またはエディショニング・ビューに対して作成された複合DMLトリガーは、複数のタイミングで起動できます。各タイミング部には、独自の実行部とオプションの例外処理部がありますが、それらのすべての部分から共通のPL/SQL状態にアクセスできます。共通の状態は、トリガーを起動する文でエラーが発生した場合でも、トリガーを起動する文の開始時に発生し、トリガーを起動する文の完了時に消滅します。
Oracle Database 11gリリース1より前は、アプリケーション開発者が補助パッケージを使用して、共通の状態をモデル化していました。このアプローチは、プログラムしにくく、また、トリガーを起動する文でエラーが発生し、AFTER文トリガーが起動されなかった場合にメモリー・リークが発生する可能性がありました。複合トリガーを使用すると、様々なタイミングで実装したアクションで共通データを共有するアプローチを簡単にプログラムできます。
詳細は、「複合DMLトリガー」を参照してください。
トリガーに対するより詳細な制御
SQL文CREATE
TRIGGER
では、トリガーをより詳細に制御できるENABLE
句、DISABLE
句およびFOLLOWS
句がサポートされています。DISABLE
句を使用すると、トリガーを無効な状態で作成できるため、トリガーを有効にする前に、コードが正常にコンパイルされることを確認できます。ENABLE
句は、デフォルトの状態を明示的に指定します。FOLLOWS
句を使用すると、同じ表に対して定義され、タイミングも同じであるトリガーの起動順序を制御できます。
詳細は、次の項を参照してください。
サブプログラムの自動インライン化
サブプログラムのインライン化によって、(同じPL/SQLユニット内のサブプログラムに対する)サブプログラムの起動は、起動するサブプログラムのコピーに置き換えられます。ほとんどの場合はこれによって、プログラムのパフォーマンスが向上します。
PRAGMA INLINE
を使用して、個々のサブプログラムの起動がインライン化されるかどうかを指定できます。コンパイル・パラメータPLSQL_OPTIMIZE_LEVEL
を3(デフォルトは2)に設定することによって、自動インライン化を有効にする(コンパイラにインライン化の機会を探るように要求する)こともできます。
まれに、自動インライン化を行ってもプログラムのパフォーマンスが向上しないことがありますが、この場合は、PL/SQL階層型プロファイラを使用して、インライン化を無効にするサブプログラムを識別できます。
詳細は、次の項を参照してください。
関連項目: コンパイル・パラメータPLSQL_OPTIMIZE_LEVELの詳細は、『Oracle Databaseリファレンス』 を参照してください。 |
PL/Scope
PL/Scopeは、PL/SQLのソース・テキストからユーザー定義の識別子に関するデータを収集して整理するコンパイラ・ドリブンのツールです。PL/Scopeはコンパイラ・ドリブンのツールであるため、直接使用するのではなく、対話型開発環境(SQL DeveloperやJDeveloperなど)を介して使用します。
PL/Scopeを使用すると、ソース・テキストを参照したり理解するために費やす時間を最小限に抑えることによって、PL/SQL開発者の生産性を向上させる、強力で効果的なPL/Scopeのソース・テキスト・ブラウザの開発が可能になります。
詳細は、「ユーザー定義の識別子に関するデータの収集」を参照してください。
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
PL/SQL階層プロファイラ
PL/SQL階層プロファイラは、サブプログラムの起動別に編成されたPL/SQLプログラムの動的実行プロファイルをレポートします。SQL実行時間およびPL/SQL実行時間が個別に説明されます。動的実行プロファイルにおけるサブプログラム・レベルの各サマリーには、サブプログラムの起動数、サブプログラム自体に要した時間、サブプログラムのサブツリー(つまり依存サブプログラム)に要した時間、詳細な親子情報などが表示されます。
生成されたHTMLレポートは任意のブラウザで参照できます。ブラウザのナビゲーション機能と厳選したリンクを組み合せた効率的な手段により、大規模なアプリケーションのパフォーマンスを分析し、アプリケーションのパフォーマンスを向上させ、開発コストを削減できます。
詳細は、「PL/SQLプログラムのプロファイルおよびトレース」を参照してください。
関連項目: 『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』 |
PL/SQLネイティブ・コンパイラによるシステム固有のコードの直接生成
PL/SQLネイティブ・コンパイラは、PL/SQLコードをC言語のコードに変換してからCコンパイラにシステム固有のコードを生成させるのではなく、システム固有のコードを直接生成します。個々の開発者は、DBAとして設定を行わずに、システム固有の実行用にPL/SQLユニットをコンパイルできます。ネイティブ・コンパイルされたPL/SQLプログラムの実行速度が大幅に向上する場合もあります。
詳細は、「システム固有の実行のためのPL/SQLユニットのコンパイル」を参照してください。