ヘッダーをスキップ

Oracle Database 概要
11gリリース1(11.1)

E05765-03
目次
目次
索引
索引

戻る 次へ

24 SQL

この章では、SQLの概要について説明します。

この章の内容は、次のとおりです。

SQLの概要

SQLは、データベース・アクセス用の非手続き型言語です。処理内容をSQLで記述すると、SQL言語コンパイラがデータベースをナビゲートし、指定されたタスクを実行するプロシージャを自動的に生成するという点で、SQLは非手続き型言語です。

Oracle SQLには、ANSI/ISO標準SQL言語に対応する多くの拡張機能が組み込まれています。また、Oracleのツール製品とアプリケーションを利用すると、文を追加できます。SQL*PlusおよびOracle Enterprise ManagerなどのOracleツールでは、Oracleデータベースに対してANSI/ISO標準のSQL文を実行できる他、これらのツール製品で利用可能な追加の文や機能を実行できます。

いくつかのOracleのツール製品およびアプリケーションでは、SQLの使用は簡略化またはマスクされていますが、すべてのデータベース操作はSQLを使用して実行されます。その他のデータ・アクセス方法を使用すると、Oracle Databaseに組み込まれているセキュリティが活用されず、データのセキュリティと整合性が損われる可能性があります。

関連項目

  • SQL文およびSQLのその他の部分(演算子、関数および書式モデルなど)の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

  • SQL文との相違点など、SQL*Plusの文の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

 

SQL文

Oracle Database内の情報に対するすべての操作は、SQLを使用して実行します。1つの文は、識別子、パラメータ、変数、名前、データ型およびSQL予約語から構成されます。SQL予約語は、SQLで特別な意味を持ち、他の目的には使用できません。たとえば、SELECTUPDATEは予約語のため、表名には使用できません。

SQL文は、コンピュータ・プログラムまたは命令です。文は、完全なSQL文と等価である必要があります。次に例を示します。

SELECT last_name, department_id FROM employees;

実行できるのは完全なSQL文のみです。次のような不完全文を実行しようとすると、テキストの不足によりSQL文を実行できないことを示すエラーが発生します。

SELECT last_name 

Oracle DatabaseのSQL文は、次のカテゴリに分類されます。

データ操作言語文

データ操作言語(DML)文は、既存のスキーマ・オブジェクト内のデータの問合せや操作を実行します。次のことを実行できます。

DML文は、最も頻繁に使用するSQL文です。次に、DML文の例をいくつか示します。

SELECT last_name, manager_id, commission_pct + salary FROM employees; 

INSERT INTO employees VALUES 
    (1234, 'DAVIS', 'SALESMAN', 7698, '14-FEB-1988', 1600, 500, 30); 

DELETE FROM employees WHERE last_name IN ('WARD','JONES'); 

DMLエラー・ロギング

DML文にエラーが発生した場合、エラー・コードおよび関連付けられたエラー・メッセージ・テキストがエラー・ロギング表に記録される間、DML文は処理を続行できます。これは特に、長時間実行のバルクDML文に役立ちます。DML操作の完了後、エラー・ロギング表をチェックして、エラーのある行を修正できます。

エラー・ロギング表の名前、文タグおよび拒否の制限を指定する新規構文がDML文に追加されています。拒否の制限は、文を強制終了する必要があるかどうかを決定します。パラレルDML操作の場合、拒否の制限はスレーブごとに適用されます。パラレル操作に対して正確に規定される拒否の制限の値は、0(ゼロ)および無制限のみです。

データ変換エラーが発生した場合、Oracle Databaseは、列についてログに記録するための意味のある値を提供します。たとえば、障害が発生した変換演算子に対する最初のオペランドの値をログに記録します。値を導出できない場合、その列についてNULLがログに記録されます。

関連項目

  • 「SQL文の処理の説明」

  • DMLエラー・ロギングの詳細は、『Oracle Database管理者ガイド』を参照してください。

  • DMLエラー・ロギングの使用例は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

  • DMLエラー・ロギングの構文は、『Oracle Database SQL言語リファレンス』を参照してください。

 

データ定義言語文

データ定義言語(DDL)文は、スキーマ・オブジェクトに対し、定義、構造の変更および削除を実行します。DDL文によって、次のことを実行できます。

DDL文は、先行するコマンドを暗黙的にコミットし、新しいトランザクションを開始します。次に、DDL文の例をいくつか示します。

CREATE TABLE plants  
    (COMMON_NAME VARCHAR2 (15), LATIN_NAME VARCHAR2 (40)); 

DROP TABLE plants; 

GRANT SELECT ON employees TO scott; 

REVOKE DELETE ON employees FROM scott; 

関連項目

 

トランザクション制御文

トランザクション制御文は、DML文による変更の内容を管理し、一連のDML文をトランザクションとしてグループ化します。次のことを実行できます。

セッション制御文

セッション制御文は、特定のユーザー・セッションのプロパティを管理します。たとえば、次の操作を実行できます。

システム制御文

システム制御文は、Oracleデータベース・インスタンスのプロパティを変更します。システム制御文は、ALTER SYSTEMのみです。この文は、設定値(共有サーバーの最小数など)の変更、セッションの終了およびその他の作業のために使用します。

埋込みSQL文

埋込みSQL文は、手続き型言語プログラム内にDDL、DMLおよびトランザクション制御文を取り込みます。これらの文は、Oracleプリコンパイラで使用されます。埋込みSQL文によって、次のことを実行できます。

カーソル

カーソルとは、解析済の文と、処理に使用するその他の情報が保持されるメモリー内の領域(プライベートSQL領域)のハンドルまたは名前のことです。

ほとんどのOracle DatabaseユーザーはOracle Databaseユーティリティの自動カーソル処理を使用しますが、プログラム・インタフェースを利用すると、アプリケーション設計者はカーソルを制御しやすくなります。アプリケーション開発の場合、カーソルはプログラムが使用できる名前付きのリソースです。特にアプリケーションに埋め込まれたSQL文の解析に使用できます。

ユーザー・セッションごとに、初期化パラメータOPEN_CURSORSで設定された値を上限として、複数のカーソルをオープンできます。ただし、システム・メモリーを節約するには、アプリケーション側で不必要なカーソルをクローズする必要があります。カーソル数の制限のためにカーソルをオープンできない場合、データベース管理者はOPEN_CURSORS初期化パラメータを変更できます。

Oracle Databaseは暗黙的に再帰的SQL文を発行する必要があり、再帰カーソルが必要になる場合があります(主としてDDL文の場合)。たとえば、CREATE TABLE文を使用すると、新しい表と列を記録するために、各種データ・ディクショナリ表に多数の更新が加えられます。これらの再帰カーソルに対して再帰コールが発行されます。1つのカーソルで複数の再帰コールが実行されることもあります。それらの再帰カーソルでは、共有SQL領域も使用します。

スクロール可能カーソル

カーソルを実行すると、問合せの結果が結果セットと呼ばれる行の集合に入れられます。この集合は、順次またはランダムにフェッチできます。スクロール可能カーソルは、フェッチおよびDML操作を順送りで行う必要がない場合のカーソルです。以前フェッチした行のフェッチ、結果セットのn番目の行のフェッチ、および結果セットの現在位置からn番目の行のフェッチのために、インタフェースが存在しています。

関連項目

Oracle Call Interface(OCI)内でのスクロール可能カーソルの使用方法の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 

共有SQL領域

複数のアプリケーションがデータベースに対して同じSQL文を送信すると、Oracle Databaseはそのことを自動的に認識します。その文が最初に出現したときの処理に使用されたSQL領域は共有されます。つまり、その後に同じ文が出現すると、それを処理するためにこの領域が使用されます。したがって、一意の文に対しては1つの共有SQL領域しか存在しません。共有SQL領域は共有メモリー領域であるため、どのOracle Databaseプロセスも共有SQL領域を使用できます。SQL領域を共有することで、データベース・サーバーのメモリー使用量が節約され、システムのスループットが向上します。

文が同一であるかどうかを評価するときに、Oracle Databaseは、ユーザーとアプリケーションが直接発行したSQL文と、DDL文によって内部的に発行された再帰的SQL文を評価します。

関連項目

共有SQLの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 

解析

解析は、SQL文を処理するときの1つの段階です。アプリケーションがSQL文を発行すると、アプリケーションはOracle Databaseに解析コールを出します。解析コールでは、Oracle Databaseは次のことを実行します。

また、Oracle Databaseは、ライブラリ・キャッシュにその文の解析済の表現を含んでいる既存の共有SQL領域が存在するかどうかも判別します。存在する場合、ユーザー・プロセスはこの解析済の表現を使用して、ただちにその文を実行します。存在しない場合、Oracle Databaseはその文の解析済の表現を生成し、ユーザー・プロセスは、ライブラリ・キャッシュの中にその文の共有SQL領域を割り当て、そこに解析済の表現を格納します。

アプリケーションがSQL文の解析コールを出すことと、Oracle Databaseが実際にその文を解析することには、次のような違いがあります。

解析コールと解析は、実行に比べて負荷が高いため、できるだけ回数を少なくしてください。

関連項目

「PL/SQLの概要」 

SQL文を解析するとその文の妥当性がチェックされますが、解析で識別されるのは文を実行する前に検出が可能なエラーのみです。したがって、解析で捕捉できないエラーもあります。たとえば、データ変換エラーまたはデータ・エラー(主キーに重複値を入力しようとした場合など)およびデッドロックは、実行段階に入ってからでなければ検出もレポートもされません。

問合せの処理

問合せは、正常に実行された場合に結果としてデータを戻すという点で、他のタイプのSQL文とは異なります。他の文は単に成功か失敗かを戻すのみですが、問合せは1行または数千行を戻します。問合せの結果は、常に表形式です。結果の行は、1行ごとにまたはグループ単位でフェッチされ(取り出され)ます。

問合せ処理のみに関連する問題がいくつかあります。明示的なSELECT文のみでなく、他のSQL文に含まれる暗黙的問合せ(副問合せ)もあります。たとえば、次のそれぞれの文では、実行の一部として問合せが必要になります。たとえば、次のそれぞれの文では、実行の一部として問合せが必要になります。

INSERT INTO table SELECT... 

UPDATE table SET x = y WHERE... 

DELETE FROM table WHERE... 

CREATE table AS SELECT... 

問合せには、次のような特長があります。

SQLの処理

この項では、SQL処理の基本について説明します。最初に、ほとんどのタイプのSQL文を網羅する、一般的なSQL文の実行のフローチャートを示します。次に、SQL文の処理の段階について概説します。最後に、異なるタイプのSQL文では、フローチャートおよび説明が異なる場合があることを説明します。

この項の内容は次のとおりです。

SQL文の実行のフローチャート

図24-1に、SQL文を処理して実行するための一般的な段階を示します。場合によっては、Oracle Databaseでこれらの段階の実行順序が少し異なることもあります。たとえば、DEFINEの段階は、コーディングの仕方によってはFETCHの直前にくることがあります。

多くのOracleのツール製品では、これらの段階のいくつかが自動的に実行されます。ほとんどのユーザーには、ここまでの詳細は必要ありません。ただし、この情報はOracleアプリケーションの作成に役立ちます。

図24-1    SQL文の処理の段階


画像の説明

SQL文の処理の説明

この項では、1つの例をあげて、SQL文の実行中に何がどのように処理されているのか、処理の段階ごとに説明します。この例では、特定のDML文を処理しますが、その内容は他のタイプのSQL文にも一般化できます。それに続く項では、他のタイプのSQL文を実行した場合、この説明とどのように異なるかについての情報を提供します。「他のタイプのSQL文の処理」を参照してください。

Pro*Cプログラムを使用して、ある部門の従業員全員の給与を増額する処理を実行するとします。現在使用しているプログラムは、Oracle Databaseへの接続が確立され、employees表を更新するための適切なスキーマに接続されているとします。この場合、プログラムに次のSQL文を埋め込むことができます。

EXEC SQL UPDATE employees SET salary = 1.10 * salary 
    WHERE department_id = :department_id; 

Department_idは、部門番号の値を含むプログラム変数です。SQL文の実行時には、アプリケーション・プログラムから提供されるdepartment_id値が使用されます。

次に、各タイプの文を処理するために必要な段階を示します。段階7はオプションで、段階4、5、および9は図24-1で説明する問合せのみに適用されることに注意してください。

段階1: カーソルのオープンまたは作成

プログラム・インタフェース・コールにより、カーソルがオープン(作成)されます。カーソルは、SQL文からの要求で独立して作成されます。ほとんどのアプリケーションでは、カーソルは自動的に作成されます。ただし、プリコンパイラ・プログラムでは、暗黙的にカーソルが作成されたり、カーソル作成が明示的に宣言されることもあります。

段階2: 文の解析

解析段階では、SQL文がユーザー・プロセスからOracle Databaseに渡され、SQL文の解析済の表現が共有SQL領域にロードされます。文処理のこの段階では、多くのエラーを捕捉できます。

関連項目

 

段階3: 問合せの有無の判断

この段階では、SQL文が問合せで開始するかどうかを判断します。

関連項目

「解析」 

段階4: 問合せの結果の記述(問合せのみ)

記述段階が必要なのは、問合せがユーザーにより対話式で入力された場合など、問合せ結果の特性が不明な場合のみです。この場合は、記述段階で問合せ結果の特性(データ型、長さおよび名前)がわかります。

段階5: 問合せの出力の定義(問合せのみ)

問合せの定義段階では、フェッチされた各値を受け取るために定義された変数の位置、サイズおよびデータ型を指定します。これらの変数は定義変数と呼ばれます。Oracle Databaseは、必要に応じてデータ型を変換します。(図24-1「SQL文の処理の段階」の「DEFINE」を参照。)

段階6: 変数のバインド

この時点で、Oracle DatabaseはSQL文の意味を認識していますが、文を実行するための情報がまだ不足しています。Oracle Databaseは、文に含まれている変数の値を必要とします。例では、department_idの値が必要です。これらの値を取得する処理のことを、変数のバインドと呼びます。

プログラムでは、値を検出できる位置(メモリー・アドレス)を指定する必要があります。Oracle Databaseユーティリティはアプリケーションのエンド・ユーザーに新しい値の入力を要求するプロンプトを表示するのみであるため、エンド・ユーザーはバインド変数を指定していることを認識していない可能性があります。

位置を指定(参照によるバインド)すると、再実行の前に変数を再バインドする必要はありません。変数の値は変更可能です。Oracle Databaseは、実行のたびに、メモリー・アドレスを使用して変数の値を調べます。

Oracle Databaseでデータ型変換を実行する必要がある場合は、暗黙的にまたはデフォルトで指定されていないかぎり、それぞれの値のデータ型と長さも指定する必要があります。

関連項目

  • 『Oracle Call Interfaceプログラマーズ・ガイド』

  • 『Pro*C/C++プログラマーズ・ガイド』(動的SQL方法4に関する項を参照)

値のデータ型および長さを指定する方法の詳細は、これらを参照してください。 

段階7: 文のパラレル化(オプション)

Oracle Databaseでは、問合せ(SELECTINSERTUPDATEMERGEDELETE)および一部のDDL処理(索引の作成、副問合せを含む表の作成、パーティションの操作など)をパラレル化できます。パラレル化すると、複数のサーバー・プロセスがSQL文の処理を実行するため、処理を高速に完了できます。

関連項目

第16章「ビジネス・インテリジェンス」 

段階8: 文の実行

この時点で、Oracle Databaseに必要なすべての情報およびリソースが用意され、文を実行できます。問合せまたはINSERT文の場合は、データが変更されないため、行をロックする必要はありません。ただし、UPDATE文またはDELETE文の場合は、トランザクションのCOMMITROLLBACKまたはSAVEPOINTが次に実行されるまで、文の影響を受けるすべての行がロックされます。この処理により、データ整合性を確実に維持できます。

文によっては、実行回数を指定できる場合があります。このような処理を配列処理と呼びます。n回の実行回数が指定された場合、バインドと定義の位置はサイズnの配列の開始点とみなされます。

段階9: 問合せの行のフェッチ(問合せのみ)

フェッチ段階では、行が選択され、順序付け(問合せで要求された場合)されます。最後の行がフェッチされるまで、毎回のフェッチで結果の行が連続して取り出されます。

段階10: カーソルのクローズ

SQL文の処理の最後の段階は、カーソルのクローズです。

他のタイプのSQL文の処理

次の項では、DDL文、トランザクション制御文およびその他のSQL文の処理と、「SQL文の処理の説明」で説明した処理との相違について説明します。

この項の内容は、次のとおりです。

DDL文の処理

DDL文を正常実行するにはデータ・ディクショナリへの書込みアクセスが必要であるため、DDL文の実行はDML文や問合せの実行とは異なります。これらの文の解析(段階2)には、実際には解析、データ・ディクショナリの参照および実行が含まれます。

トランザクション制御処理

通常、1つのトランザクションを構成するアクションのタイプを考慮する必要があるのは、Oracle Databaseのプログラム・インタフェースを使用するアプリケーション設計者のみです。作業を論理単位として完了し、データの一貫性が保たれるようにトランザクションを定義する必要があります。トランザクションには、1つの論理作業単位に必要な部分を過不足なくすべて含める必要があります。

たとえば、口座間の振替操作(トランザクションまたは論理作業単位)の場合は、片方の口座からの引出し(1つのSQL文)と、もう一方の口座への預入れ(1つのSQL文)を含める必要があります。どちらのアクションも、1つの論理作業単位として一緒に失敗または成功する必要があります。出金がコミットされずに、入金がコミットされることはありません。また、ある口座に新しく預金するなど、関連のないその他のアクションを、振替トランザクションに含めることはできません。

その他の処理タイプ

トランザクション管理、セッション管理およびシステム管理のSQL文は、解析および実行段階を使用して処理されます。それらを再実行するには、実行段階をもう一度実行します。

オプティマイザの概要

すべてのSQL文でオプティマイザが使用されます。オプティマイザは、指定されたデータへの最も効率的なアクセス手段を決定するOracle Databaseの機能です。Oracleには、オプティマイザにジョブを適切に実行させるためのテクニックも用意されています。

たとえば、表または索引へのアクセス順序を変えることにより、SQL DML(SELECTINSERTUPDATEMERGEまたはDELETE)文の処理は様々になります。Oracle Databaseで文を実行するときに使用する手順は、文の実行速度に大きく影響します。オプティマイザは、代替アクセス・パスの多数の要因を考慮します。


注意

オプティマイザは、Oracle Databaseのバージョンが変わると、同じ決定をしない可能性があります。最近のバージョンでは、オプティマイザは入手可能な情報から適切なものに基づいて決定を行うことがあります。 


オプティマイザが選択する内容は、そのアプローチ方法および目標に従って決まります。陳腐化したオブジェクトや統計のないオブジェクトは、自動的に分析されます。PL/SQLパッケージDBMS_STATSを使用して、オプティマイザの統計も収集できます。

Oracle Database 11gでは、次のものを含む、新しい拡張統計が導入されています。

さらに、統計を公開することなく収集できるようになりました。新しく収集された統計(保留中の統計)を公開する前にテストできます。

特定のアプリケーションのデータについて、オプティマイザよりもさらに詳細な知識を持つアプリケーション設計者の方が、SQL文をより効率的に実行する方法を選択できることもあります。アプリケーション設計者は、SQL文内にヒントを使用して文の実行方法を指定できます。

関連項目

  • DBMS_STATSの使用方法は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  • オプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

 

この項の内容は、次のとおりです。

SQL計画の管理(SPM)

Oracle Database 11gでは、オプティマイザが自動的に計画を管理し、検証された計画のみが使用されます。SQL計画の管理(SPM)では、現在の計画よりも新しい計画のほうがより適切に実行されることが検証された場合にかぎり、その新しい計画を使用することによって、計画の更新を制御できます。

実行計画

DML文を実行するために、Oracle Databaseで数多くの処理を必要とする場合があります。各処理では、データベースからデータ行を物理的に検索するか、文を発行したユーザーのためになんらかの方法でデータ行を準備します。Oracle Databaseが文の実行に使用する処理の組合せを、実行計画と呼びます。実行計画には、文がアクセスする表ごとのアクセス方法と表の順序付け(結合順序)が含まれています。実行計画の各処理は、示されている番号の順序で実行されるわけではありません。

この項の内容は、次のとおりです。

ストアド・アウトライン

ストアド・アウトラインとは、実行計画の作成終了時にオプティマイザが生成する実行計画を抽象化したもので、主にヒントの集合として機能します。次にアウトラインを使用するとき、これらのヒントがコンパイルの様々な段階で適用されます。アウトライン・データは、OUTLNスキーマに格納されています。実行計画は、ストアド・アウトラインを編集することでチューニングできます。

ストアド・アウトラインの編集

アウトライン編集セッションの開始時には、ユーザーのスキーマにアウトラインのクローンが作成されます。その後の編集操作は、ユーザーが編集を完了し、それらを公開するまでそのクローンに対して行われます。このため、このユーザーによるいずれの編集内容も、それが明示的に保存されるまで、アウトラインのパブリック・バージョンを使用する残りのユーザー・グループに影響を与えることはありません。


注意

ストアド・アウトラインは、Oracle Database 11gでは非推奨です。ストアド・アウトラインではなく、SQL計画ベースラインを使用することをお薦めします。

実行計画およびSQL計画ベースラインの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 



戻る 次へ
Oracle
Copyright © 1993, 2008 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引