web-dev-qa-db-ja.com

DECLARE GLOBAL TEMPORARYTABLEとCREATEGLOBAL TEMPORARY TABLE in DB2

dB2でGLOBAL TEMPORARY TABLEを作成しています。サーフィンをしたとき、2つの方法で作成できました。1。宣言2.作成。

1. DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP
      (EMPNO  CHAR(6) NOT NULL,
       SALARY DECIMAL(9, 2),
       BONUS  DECIMAL(9, 2),
       COMM   DECIMAL(9, 2)) WITH REPLACE ON COMMIT PRESERVE ROWS ;

2. CREATE GLOBAL TEMPORARY TABLE TMPDEPT
      (TMPDEPTNO   CHAR(3)      NOT NULL,
       TMPDEPTNAME VARCHAR(36)  NOT NULL,
       TMPMGRNO    CHAR(6),
       TMPLOCATION CHAR(16) ) ON COMMIT PRESERVE ROWS ;

そしてIBMサイトから、作成が永続的であるため最良であるという情報を入手しました。これにより、すべてのユーザーセッションが、起動時に宣言することなく同じテーブル定義にアクセスできるようになり、さらに多くの利点が得られます。

リンク: http://www.ibm.com/developerworks/data/library/techarticle/dm-0912globaltemptable/

そして、create overdeclareを使用する際のクエリはほとんどありませんでした。

  1. CREATE GLOBAL TEMPORARY TABLEを使用しているときに、Replaceキーワードが見つかりませんでした。

  2. 1つのシナリオを考えてみましょう。接続を開き、ストアドプロシージャを実行しています。
    そのストアドプロシージャ内でグローバル一時テーブルを作成し、そのストアドプロシージャ内で別のストアドプロシージャを呼び出しています。このストアドプロシージャには、same CreateTempテーブルステートメントがあります。この場合はどうなりますか。両方のテーブルが同じであり、単一の接続内にあるため、エラーをスローしますか?

  3. セッションがあると宣言し、作成しませんか?これは永続性に関連していますか?

  4. パフォーマンスに関してはどちらが良いですか? tempを宣言しますか、それともtempを作成しますか?

  5. 宣言/作成の最適な使用法のためのいくつかのシナリオを提案してください!!

8
A Programmer

Craig S. Mullinsからの良い記事 があり、2つの主な違いをカバーしています。ほとんどの目的で、それらは同じように機能します。

作成された一時テーブルは、作業ファイルデータベース(作業用ストレージを必要とするSQLステートメント中に使用されるのと同じストレージ領域)であるDSNDB07に作成されます。宣言された一時テーブルは、作成する必要のある一時テーブルスペースに格納されます。

CTTにはいくつかの短所があります。

  • それらは永続的ではないため、ロック、ロギング、リカバリなどの一部の一般的なデータベース操作は、作成された一時テーブルには適用されません。

  • 作成された一時テーブルにインデックスを作成することはできないため、すべてのアクセスは完全なテーブルスキャンによって行われます。

  • 作成された一時テーブルに制約を作成することはできません。

  • Nullは、作成された一時テーブルの列に許可される唯一のデフォルト値です。

  • 作成された一時表は、DB2ユーティリティーでは参照できません。

  • 作成された一時テーブルは、UPDATEステートメントのオブジェクトとして指定できません。

  • 作成した一時テーブルから削除する場合は、すべての行を削除する必要があります。

  • 作成された一時テーブルにビューを作成することはできますが、WITH CHECKOPTIONを指定することはできません。

DTTは通常、はるかに柔軟性があります。

  • 宣言された一時テーブルには、インデックスとCHECK制約を定義できます。

  • 宣言された一時テーブルに対してUPDATEステートメントと配置されたDELETEステートメントを発行できます。

  • 宣言された一時テーブルの列を暗黙的に定義し、SELECTの結果テーブルを使用できます。

今あなたの番号付きの質問のために:

1.&2。ありません。 CTTは(DBAによって)一度宣言されれば、アプリケーションプログラマーはどのセッションでも使用できると私は信じています(これが正確かどうかは100%わかりません。当店ではほとんどすべての場合にDTTを使用しています)。各接続には独自のコピーがあり、アプリケーションが切断されると、そのセッションでそのCTTに保存されているデータは失われます。

3. SESSIONは、DTTの単なるスキーマ識別子です。これは、永続化されない一時テーブルであることを示しています。

4.どちらもほぼ同じパフォーマンスになると思います。ロック、ロギング、リカバリなどが適用されないため、通常のテーブルよりも高速になります。

5.一般的に、DTTが進むべき道だと思いますが、CTTは便利です(Craigが彼の記事で述べているように)。

(CTT)は、主に一時データの更新が不要で、一時データへのアクセスが純粋に順次である場合に検討する必要があります。

9
bhamby
  1. 作成された一時テーブルは、この場合、DTTよりもはるかに優れたパフォーマンスを発揮することがわかりました。例外かもしれませんが(状況によって異なります)、変更のきっかけは、DTTで実行されていたインクリメンタルバインドの数を確認することでした。各トランザクションには23の一時テーブルが必要でした。並列テストを実行したところ、CTTによってCPUとIn_DB2の両方の時間が大幅に低下することがわかりました。また、ロック/ラッチ待機の低下が見られ、CTTを使用すると、ZIIPCPUがGPCPUを超え始め、すべての人が満足していることがわかりました。

DTTインデックスや更新アクセスは必要なく、RIも使用できませんでした。

0
Bob Cothroll