ここでは、このマニュアルで扱うOracle Databaseの新機能を簡単に説明し、詳細情報へのリンクを示します。
内容は次のとおりです。
フラッシュバック・データ・アーカイブの履歴表の最適化
リリース11.2.0.4までは、フラッシュバック・データ・アーカイブを作成または変更する際に、対応する履歴表の最適化を無効化できませんでした。
リリース11.2.0.4では、フラッシュバック・データ・アーカイブを作成または変更する際、CREATE
FLASHBACK
ARCHIVE
文またはALTER
FLASHBACK
ARCHIVE
文のOPTIMIZE
DATA
句を使用して対応する履歴表の最適化を有効化または無効化できます。詳細は、「フラッシュバック・データ・アーカイブの作成」および「Oracle Flashback Technologyの一般ガイドライン」を参照してください。
データベース・サービスのエディション属性
リリース11.2.0.2までは、データベース・サービスを使用してOracle Databaseに接続するときに、初期セッション・エディションを指定できませんでした。ホット・ロールオーバーのためにエディションベースの再定義を使用する場合、アップグレード前のエディションを使用するデータベース・クライアントと、アップグレード後のエディションを使用するデータベース・クライアントがあれば、クライアント・コードを変更する必要がありました。
リリース11.2.0.2では、データベース・サービスの属性として初期セッション・エディションを指定できます。これにより、さらに容易に、各セッションがホット・ロールオーバー中に目的のエディションを確実に使用することができるようになります。詳細は、「初期セッション・エディション」を参照してください。
リリース11.2.0.2では、各*_SERVICES
静的データ・ディクショナリ・ビューに、デフォルトの初期セッション・エディションを表示するEDITION
列が含まれます。詳細は、「エディション、エディショニング・ビューおよびCrosseditionトリガーの情報の表示」を参照してください。
Oracle Database 11gリリース2でのOracle Databaseの機能は、次のとおりです。
トランザクションのフラッシュバック外部キー依存性のトラッキング
CASCADE
オプションを使ったトランザクションのフラッシュバック(DBMS_FLASHBACK
.TRANSACTION_BACKOUT
プロシージャ)では、データベースがオンラインである間にトランザクションおよびその依存トランザクションがロールバックされます。
Oracle Database 11gリリース2以前、トランザクションのフラッシュバックでは、外部キーの依存性は追跡されませんでした。したがって、CASCADE
オプションを付けてトランザクションのフラッシュバックを使用し、外部キーに依存しているトランザクションをロールバックしようとすると、外部キー違反エラーが発生しました。これを回避するには、ロールバックするトランザクションのリストに外部キー依存トランザクションを含める必要がありました。
Oracle Database 11gリリース2以降、CASCADE
オプションを付けてトランザクションのフラッシュバックを使用する場合、ロールバックされるトランザクションのリストに依存トランザクションを入れる必要はありません。
トランザクションのフラッシュバックにおける外部キー依存性を追跡するには、外部キーのサプリメンタル・ロギングを有効化する必要があります。手順は、「フラッシュバック・トランザクションに関するデータベースの構成」を参照してください。トランザクションのフラッシュバックの詳細は、「フラッシュバック・トランザクションの使用」を参照してください。
トリガーの高度な無効化
Oracle Database 11gリリース1の機能である「高度な無効化」がトリガーにも拡張されています。
エディションベースの再定義
エディションベースの再定義を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。
使用中にアプリケーションをアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを分離した状態で再定義します。変更内容はアプリケーションのユーザーには影響しません。ユーザーは変更されていないアプリケーションの実行を継続します。変更内容が正しいことを確認したら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。
エディションベースの再定義では、1つ以上のコンポーネント機能を使用します。使用する機能と停止時間は次の要素によって異なります。
再定義するデータベース・オブジェクトの種類
データベース・オブジェクトの再定義中に、ユーザーがそのデータベース・オブジェクトをどの程度使用できるか
以前のアプリケーションを使用しているユーザーがいるときに、アップグレードしたアプリケーションを他のユーザーが使用できるようにするかどうか
エディション機能は常に使用します。これにより、データベース・オブジェクトをコピーして、コピーしたオブジェクトを分離して再定義することができます。
1つ以上の表の構造を変更する場合は、エディショニング・ビュー機能も使用します。
表の構造を変更している間、他のユーザーがその表のデータを変更する必要がある場合は、forward crosseditionトリガーも使用します。アップグレード前のアプリケーションとアップグレード後のアプリケーションが同時に通常使用(ホット・ロールオーバー)されている場合、reverse crosseditionトリガーも使用します。crosseditionトリガーはアプリケーションの永続的な要素ではありません。全ユーザーがアップグレード後のアプリケーションを使用するようになったら削除します。
詳細は、第19章「エディションベースの再定義」を参照してください。
APPLYING_CROSSEDITION_TRIGGERファンクション
forward crosseditionトリガーの本体はデータ変換の衝突を処理する必要があります。衝突処理方法がトリガーの実行理由に応じて変わる場合、その理由は、パッケージDBMS_STANDARD
で定義されているファンクションAPPLYING_CROSSEDITION_TRIGGER
により判断できます。
詳細は、「データ変換における衝突の処理」を参照してください。
IGNORE_ROW_ON_DUPKEY_INDEXヒント
INSERT
INTO
target
subquery
形式の文を実行すると、挿入される一部の行に対する一意キーが既存の行と衝突する可能性があります。アプリケーションはこのような衝突を無視する必要があると仮定し、既存の行と衝突しない行を挿入します。
Oracle Database 11gリリース2以前、DUP_VAL_ON_INDEX
例外用のNULL
ハンドラを持つブロックに、ソース行を選択し、これらを一度に1つずつターゲットに挿入するPL/SQLプログラムを書く必要がありました。
Oracle Database 11gリリース2では、PL/SQLプログラムを書く必要はありません。INSERT
文で、より記述しやすく、実行も早いIGNORE_ROW_ON_DUPKEY_INDEX
ヒントを使用できます。このヒントはcrosseditionトリガーを実装するときに特に便利です。
詳細は、「データ変換における衝突の処理」を参照してください。
CHANGE_DUPKEY_ERROR_INDEXヒント
INSERT
またはUPDATE
文を実行した時に、一意キーが既存の行と衝突する可能性があります。
Oracle Database 11gリリース2以前、この衝突はエラーORA-00001の原因でした。衝突が発生したことはわかりましたが、どこで発生したかはわかりませんでした。
Oracle Database 11gリリース2以降、INSERT
またはUPDATE
文でCHANGE_DUPKEY_ERROR_INDEX
ヒントを使用し、指定された索引または列セットで一意キー違反が発生したときに、ORA-00001のかわりにORA-38911が表示されるようにすることができます。このヒントはcrosseditionトリガーを実装するときに特に便利です。
詳細は、「データ変換における衝突の処理」を参照してください。
DBMS_PARALLEL_EXECUTEパッケージ
DBMS_PARALLEL_EXECUTE
パッケージを使用すると、大容量の表のデータを並列で増分的に更新することができます。これは次の2つの手順で行われます。
表の行をグループ化して小さなチャンクに分けます。
必要なUPDATE
文を並列でチャンクに適用し、1チャンクの処理が終了するたびにコミットします。
この方法では、パフォーマンスが向上し、ロールバックによる領域消費が削減され、保持される行ロック数が削減されます。たとえばforward crosseditionトリガーの適用など、大量のデータを更新するときは常にDBMS_PARALLEL_EXECUTE
パッケージを使用してください。
詳細は、「アップグレード前の表現をアップグレード後の表現に変換」を参照してください。
IPv6(Internet Protocol version 6)のサポート
IPv6(Internet Protocol version 6)では、IPv4に比べてかなり大きなアドレス空間がサポートされます。IPv6アドレスは128ビットですが、IPv4アドレスは32ビットです。
ネットワーク・アドレスを使用するアプリケーションでは、IPv6アドレスを処理するために、わずかな変更と再コンパイルが必要になる場合があります。詳細は、「PL/SQLサブプログラムでのネットワーク操作の実行」を参照してください。
マルチスレッドextproc
エージェントを起動するエージェント制御ユーティリティagtctl
は、IPv6アドレスを受け入れるようになりました。詳細は、「マルチスレッドextprocエージェント制御用の構成パラメータ」を参照してください。
参照: Oracle DatabaseでのIPv6サポートの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
Oracle Database 11gリリース1でのアプリケーション開発機能は、次のとおりです。
データ定義言語(DDL)文のWAITオプション
DDL文では内部構造に対する排他ロックを必要とします。DDL文の発行時にこれらのロックが使用できない場合、そのDDL文は失敗します。ただし、発行がサブセカンド後であれば成功していた可能性があります。SQL文LOCK
TABLE
のWAIT
オプションによって、DDL文は指定された期間ロックを待機して、失敗を避けることができます。
詳細は、「ロック方法の選択」を参照してください。
Oracle XML DatabaseのバイナリXMLのサポート
バイナリXMLは、XML文書を表す第3の方法です。バイナリXMLは、既存のオブジェクト・リレーショナル記憶域およびCLOB
記憶域表現を置換するのではなく補足します。バイナリXMLには2つの重要なメリットがあります。
XMLスキーマが使用できるかどうかに関係なく、XML操作が大幅に最適化されます。
XMLの内部表現が、ディスク上、メモリー内、およびワイヤ上で同一です。
他の記憶域メカニズムと同様、バイナリXML記憶域の詳細は透過的です。継続してXMLType
およびその関連メソッドおよび演算子を使用します。
詳細は、「XMLデータの表現」を参照してください。
参照: 『Oracle XML DB開発者ガイド』 |
SQL演算子と関数のメタデータ
SQL演算子および関数のメタデータは、動的パフォーマンス(V$
)ビューを介してアクセス可能です。サード・パーティのツールは、アプリケーション・レイヤーのメタデータをメンテナンスすることなくSQL関数を活用できます。
詳細は、「SQL演算子および関数のメタデータ」を参照してください。
正規表現SQL関数への拡張機能
正規表現SQL関数REGEXP_INSTR
およびREGEXP_SUBSTR
では、機能が強化されています。新しい正規表現SQL関数REGEXP_COUNT
では、文字列にパターンが出現する回数が戻されます。このファンクションはSQLおよびPL/SQLでの場合と同じ働きをします。
詳細は、「Oracle SQLの正規表現のサポート」を参照してください。
参照: 『Oracle Database SQL言語リファレンス』 |
非表示の索引
非表示の索引は、すべてのデータ操作言語(DML)文でOracle Databaseによってメンテナンスされますが、セッションまたはシステム・レベルで明示的にパラメータOPTIMIZER_USE_INVISIBLE_INDEXES
をTRUE
に設定しないかぎりは、オプティマイザによって無視されます。
索引を非表示にするのは、使用禁止または削除の代替手段です。非表示の索引を使用すると、次のことができます。
索引を実際に削除する前にそのテストをします。
既存のアプリケーションの動作に影響を及ぼすことなく、オンライン・アプリケーションのアップグレードなど、特殊な標準外操作用に一時的に非表示の索引を作成します。
詳細は、『Oracle Database管理者ガイド』を参照してください。
PL/SQLファンクション結果キャッシュ
Oracle Database 11gリリース1より前は、PL/SQLアプリケーションにファンクションの結果をキャッシュさせた場合、キャッシュおよびキャッシュ管理のサブプログラムを設計およびコーディングする必要がありました。複数セッションでアプリケーションを実行する場合、各セッションではそのキャッシュおよびキャッシュ管理のサブプログラム・コピーが必要でした。各セッションで同じ高価な演算を実行する必要がある場合もありました。
Oracle Database 11gリリース1では、PL/SQLはファンクション結果キャッシュを提供します。ファンクション結果キャッシュは共有グローバル領域(SGA)に格納されるため、アプリケーションが実行されるすべてのセッションで使用可能です。
詳細は、「PL/SQLファンクション結果キャッシュ」を参照してください。
参照: 『Oracle Database PL/SQL言語リファレンス』 |
PL/SQL式の順序
疑似列CURRVAL
およびNEXTVAL
によって、PL/SQLソース・コードの記述が容易になり、実行時のパフォーマンスおよびスケーラビリティが向上します。NUMBER式が使用できる場所であればどこにでも、
sequence_name.
CURRVALおよび
sequence_name.
NEXTVAL
を使用できます。
例6-6を参照してください。
参照: 『Oracle Database PL/SQL言語リファレンス』 |
PL/Scope
PL/Scopeはコンパイラ駆動方式のツールであり、PL/SQLソース・コードからユーザー定義の識別子に関するデータを収集して構成します。PL/Scopeはコンパイラ駆動方式のツールであるため、直接使用するのではなく、対話型の開発環境(SQL DeveloperやJDeveloperなど)を介して使用します。
PL/Scopeによって、強力で効率的なPL/Scopeソース・コード・ブラウザの開発が可能になります。このブラウザは、ソース・コードの参照および理解に費やされる時間を最小限にすることによって、PL/SQL開発者の生産性を向上させます。
PL/Scopeの詳細は、第7章「PL/Scopeの使用」を参照してください。
PL/SQL階層プロファイラ
非階層(フラット)プロファイラにより、プログラムによって各サブプログラム内で費やされた時間(サブプログラムの関数時間または自己時間)が記録されます。関数時間は役に立ちますが、たいていこれでは十分ではありません。たとえば、サブプログラムINSERT_ORDER
でプログラム全体の40%が費やされたことがわかれば参考になりますが、INSERT_ORDER
を頻繁にコールするプログラムや、INSERT_ORDER
の下(子サブプログラムを含む)で費やされた合計時間がわかればさらに便利です。階層プロファイラは、このような情報を提供します。
PL/SQL階層プロファイラには、次の機能があります。
サブプログラム・コール別に編成されたPL/SQLプログラムの動的実行プロファイルのレポート
SQL実行時間およびPL/SQL実行時間の個別の説明
特殊なソースやコンパイル時間の準備が不要
カスタム・レポートを生成するために統合開発環境(IDE)ツール(SQL Developerやサード・パーティ・ツールなど)によって処理された結果のデータベース表(階層プロファイラ表)への格納
RAWプロファイラ出力から単純なHTMLレポートを生成するには、plshprof
コマンドライン・ユーティリティを使用できます。
動的実行プロファイルのサブプログラムレベルの各サマリーには、次のような情報が含まれます。
サブプログラムに対するコールの数
サブプログラム自体で費やされた時間(関数時間または自己時間)
サブプログラム自体およびその子サブプログラムで費やされた時間(サブツリー時間)
次のような、詳細な親子情報
特定のサブプログラムのすべてのコール元(親)
特定のサブプログラムによってコールされたすべてのサブプログラム(子)
サブプログラムxがyからコールされたときに費やされた時間
サブプログラムxがyからコールされた回数
生成されたHTMLレポートは任意のブラウザで参照できます。ブラウザのナビゲーション機能と厳選したリンクを組み合せた効率的な手段により、大規模なアプリケーションのパフォーマンスを分析し、アプリケーションのパフォーマンスを向上させ、開発コストを削減できます。
PL/SQL階層プロファイラの詳細は、第8章「PL/SQL階層プロファイラの使用」を参照してください。
問合せ結果変更通知
Oracle Database 11gリリース1より前は、連続問合せ通知(CQN)によってオブジェクト変更通知のみが発行されていました。これは、登録済の問合せに関連付けられたオブジェクトのDML変更またはDDL変更の結果でした。
Oracle Database 11gリリース1では、CQNは問合せ結果変更通知も発行できます。これは、登録済の問合せに関連付けられた結果セットのDML変更またはDDL変更の結果です。新しい静的データ・ディクショナリ・ビューでは、結果セット変更通知に対してどの問合せが登録されているかを確認できます(「CQN登録の問合せ」を参照)。
詳細は、第11章「連続問合せ通知(CQN)の使用」を参照してください。
フラッシュバック・トランザクション
DBMS_FLASHBACK
.TRANSACTION_BACKOUT
プロシージャでは、データベースがオンラインである間にトランザクションおよびその依存トランザクションをロールバックします。このリカバリ操作では、UNDOデータを使用して補正トランザクションを作成および実行します。このトランザクションによって影響のあったデータが元の状態に戻ります。
詳細は、「フラッシュバック・トランザクションの使用」を参照してください。
フラッシュバック・データ・アーカイブ(Oracle Total Recall)
フラッシュバック・データ・アーカイブにより、その存続期間中、記録に対するトランザクションによる変更を格納および追跡できます。今後、アプリケーションにこのインテリジェンスを組み込む必要はありません。フラッシュバック・データ・アーカイブは、レコード・ステージ・ポリシーと監査レポートのコンプライアンスに役立ちます。
詳細は、「フラッシュバック・データ・アーカイブの使用(Oracle Total Recall)」を参照してください。
PL/SQL内で使用可能なXA API
XAインタフェース機能は、データベースやキューなど複数のリソース管理に関するトランザクションをサポートし、現在はPL/SQL内で使用できます。PL/SQLを使用して、SQL*Plusセッション間およびプロセス間のトランザクションを切替えおよび共有できます。
詳細は、「DBMS_XAパッケージの使用」を参照してください。
Oracle Real Application Clusters(Oracle RAC)でのXA/JTAのサポート
現在、XAトランザクションはデフォルトで複数のOracle RACインスタンスにまたがっており、XAを使用するすべてのアプリケーションはOracle RAC環境を最大限に活用でき、アプリケーションの可用性およびスケーラビリティを拡張します。
詳細は、「Oracle Real Application Clusters(Oracle RAC)でのOracle XAの使用」を参照してください。
識別コード・パッケージ
識別コード・パッケージは、Oracle Databaseの電子製品コード(EPC)など各種製品コードや識別コード間の格納、取得、エンコード、デコード、および変換を行うツールを提供します。また、新しいデータ型、メタデータ表およびビュー、およびEPC標準RFIDタグまたは新型RFIDタグをユーザー表に格納するためのPL/SQLパッケージも提供します。
識別コード・パッケージによって、Oracle Databaseは、EPCコード体系の認識、効率的な記憶域およびコンポーネント・レベルのEPCデータの取得、EPCglobal Tag Data Translation 1.0(TDT)標準に準拠することが可能になります。TDT標準は、各種EPC RFIDタグ表現間のデコード、エンコード、および変換の方法について定義したものです。
識別コード・パッケージでは、拡張可能なフレームワークも提供しており、EPC標準に含まれないアプリケーションで既存のコード体系を使用でき、Oracle Databaseを古いシステムと将来のEPC標準の一部になる可能性のある進化する識別コードの両方に対応させることができます。
また、識別コード・パッケージでは、最初に新しいエンコード・カテゴリを登録して新しいエンコード・タイプを登録し、次に新しいエンコード・タイプに関連付けられた新しいコンポーネントを登録して、独自の識別コードを作成できます。
詳細は、第17章「識別コード・パッケージの使用」を参照してください。
オンライン索引作成および再構築の機能拡張
オンライン索引作成および再構築では、今後DMLブロッキング・ロックを必要としません。
Oracle Database 11gリリース1より前は、オンライン索引作成および再構築では、再構築の終了時に非常に短期のDMLブロッキング・ロックが必要でした。DMLブロッキング・ロックは、待機中のDML操作の数の急上昇の原因となる可能性があったため、システム使用の一時的な遮断と急激な増加が発生しました。システムの使用状況の異常性によって、オペレーティング・システムのアラーム・レベルがトリガーされる可能性がありました。
埋込みPL/SQLゲートウェイ
PL/SQLゲートウェイを使用すると、HTTPリクエストから導出されたパラメータのあるURLに応答して、ユーザーが作成したPL/SQLサブプログラムを起動できます。mod_plsql
は、Oracle HTTP Serverへのプラグインとして存在するゲートウェイの形式です。現在はPL/SQLゲートウェイも、データベース自体に埋め込まれています。埋込みPL/SQLゲートウェイは内部のOracle XML Database Listenerを使用し、Oracle HTTP Serverに依存していません。DBMS_EPG
パッケージを使用して、ゲートウェイの埋込みバージョンを構成します。
詳細は、「埋込みPL/SQLゲートウェイの使用」を参照してください。
デフォルトでマルチスレッド・エージェントextprocを直接起動するOracle Database
アプリケーションが外部Cプロシージャをコールすると、Oracle DatabaseまたはOracle Listenerが外部プロシージャ・エージェントextproc
を起動します。
Oracle Database 11gリリース1より前は、Oracle Listenerによってマルチスレッド・エージェントextproc
が起動され、ユーザーがlistener
.ora
ファイルにextproc
の環境変数を定義していました。
Oracle Database 11gリリース1では、Oracle Databaseによってデフォルトでextproc
が直接起動され、Oracle Listenerが誤ってextproc
を起動する危険性が解消されています。セキュリティを最大限にするため、このデフォルト構成をお薦めします。使用する場合は、extproc
.ora
ファイルにextproc
の環境変数を定義します。
デフォルト構成を使用できない状況も含め、詳細は、「外部プロシージャのロード」を参照してください。
高度な無効化
Oracle Database 11gリリース1より前は、参照オブジェクトを変更するDDL文によって、そのすべての依存が無効になっていました。
Oracle Database 11gリリース1では、参照オブジェクトを変更するDDL文で依存が無効になるのは、次のいずれかに該当する場合のみです。
依存オブジェクトが、DDL文によって変更された参照オブジェクトの属性に依存している場合。
依存オブジェクトのコンパイル済メタデータが、変更された参照オブジェクトに対して正しいものでなくなった場合。
たとえば、ビューv
が表t
の列c1
およびc2
を選択している場合、t
の列c3
のみを変更するDDL文では、v
は無効になりません。
詳細は、「依存オブジェクトの無効化」を参照してください。