計算機專業(yè)文獻翻譯優(yōu)調SQL過程

1、外文資料譯文及原文院（系）：計算機學院專 業(yè)：計算機科學與技術班 級：2401102學 號：20023011059姓 名： 指導教師： 2005年6月簡介有關如何調優(yōu)數(shù)據(jù)庫系統(tǒng)和應用程序的好的建議的來源有很多。比如oltp應用程序的db2調優(yōu)技巧(以前在 ibm® db2® 開發(fā)者園地上發(fā)表)之類的文章通過使用事務和數(shù)據(jù)并行性以及分析查詢方案，給出了從表空間和索引設計到緩沖池的內存分配等方面的建議。這些方面的內容是性能調優(yōu)的基礎知識。 但是，有關如何組織存儲過程自身中的邏輯并著眼于其性能的專門建議卻并不多見。本文就提供了這樣一種建議。盡管本文著重于介紹 sql 過程，但是這

2、里所提供的大多數(shù)信息同樣適用于用其它語言編寫的在應用程序中或存儲過程中嵌入的 sql 邏輯。背景知識和術語在深入研究詳細問題之前，讓我們先想想db2 中有關過程化 sql 的一些基本術語和概念。過程化 sql 構造（例如標量變量、if 語句和 while 循環(huán)）是在 db2 universal database (udb) v7 發(fā)行版中引入 db2 的。以前的 db2 發(fā)行版支持 c 和 java 作為存儲過程的語言。v7 引入了 sql 存儲過程，以及其它許多可以促進 oltp 應用程序開發(fā)的特性（例如臨時表、應用程序保存點和標識列）。當創(chuàng)建 sql 過程時，db2 將過程主體中的 sql

3、 查詢與過程邏輯區(qū)分開來。為了使性能最優(yōu)，sql 查詢被靜態(tài)地編譯成包中的節(jié)。（對于靜態(tài)編譯的查詢而言，節(jié)主要是由 db2 優(yōu)化器為該查詢選擇的存取方案構成的。包是節(jié)的集合。在過程的執(zhí)行期間，每當控制從過程邏輯流向 sql 語句時，在 dll 和 db2 引擎之間就存在“上下文切換”。（在 db2 v8 中，sql 過程是在“不受保護的方式”下運行的，即與 db2 引擎在相同的尋址空間中。因此我們這里談及的上下文切換并不是操作系統(tǒng)級別上的完全的上下文切換，而是指 db2 中層的更換。）減少頻繁調用的過程（例如 oltp 應用程序中的過程）或者處理大量行的過程（例如執(zhí)行數(shù)據(jù)清理的過程）中的上下文

4、切換次數(shù)，對它們的性能有顯著的影響。本文中的幾個技巧恰好旨在減少這些上下文切換。剛開始的時候（db2 通用數(shù)據(jù)庫 v7 ga），只允許在 sql 過程中使用 sql 過程語言（通常稱為 sql pl）。后來（在 db2 udb v7.2 中），在 sql 函數(shù)和觸發(fā)器主體中開始支持該語言的子集。sql pl 的這個子集即所謂的 內聯(lián)（inline）sql pl。“內聯(lián)”一詞突出顯示了它與完整語言的重要區(qū)別。sql pl 過程是通過將其單獨的 sql 查詢靜態(tài)地編譯成包中的節(jié)實現(xiàn)的，而內聯(lián) sql pl 函數(shù)就象其名稱所展示的，是通過將函數(shù)主體內聯(lián)到使用它的查詢中實現(xiàn)的。稍后我們將再看一下內聯(lián)

5、sql pl 及其用法的一些示例。 從多個 sql 語句到一個 sql 表達式跟其它編程語言一樣，sql 語言提供了兩類條件構造：過程型（if 和 case 語句）和函數(shù)型（case 表達式）。在大多數(shù)環(huán)境中，可使用任何一種構造來表達計算，到底使用哪一種只是喜好問題。但是，使用 case 表達式編寫的邏輯不但比使用 case 或 if 語句編寫的邏輯更緊湊，而且更有效。使用 sql 的一次處理一個集合語義,諸如循環(huán)、賦值和游標之類的過程化構造允許我們表達那些只使用 sql dml 語句是不可能表達的計算。但是，當我們擁有一些可以隨意使用的過程語句時，即使我們手頭的計算實際上僅使用 sql dm

6、l 語句就可表達，但轉換成過程語句還是有風險的。正如我們以前提到的，過程計算的性能與使用 dml 語句表達的同一個計算的性能相比會慢幾個數(shù)量級。在研究改進現(xiàn)有過程邏輯的性能時，為消除游標循環(huán)而花費的任何時間都可能是值得的。改進游標性能如果存儲過程中的邏輯確實需要游標，那么要使性能最優(yōu)，請牢記下面這些內容。首先，請確保不使用高于您所需的隔離級別。隔離級別決定了 db2 對過程讀取或更新的行應用的鎖定的數(shù)量。隔離級別越高，db2 將執(zhí)行的鎖定越多，因此為同一資源而競爭的應用程序之間的并發(fā)就越少。例如，使用可重復讀（repeatable read，rr）隔離級別的過程將形成對其讀取的任何行的共享鎖，

7、而使用游標穩(wěn)定性（cursor stability，cs）的過程只會鎖定任何可更新游標的當前行?？梢允褂?db2_sqlroutine_prepopts 注冊表變量來指定 sql 過程的隔離級別。db2 中缺省的隔離級別是游標穩(wěn)定性。但是，當然了，為了保持應用程序的正確性，有時需要使用可重復讀。還需記住一件重要的事情，一旦創(chuàng)建了需要可重復讀的過程，必須將 db2_sqlroutine_prepopts 重新設置回較低的隔離級別。在嘗試改進游標性能時需要牢記的一個相關問題是游標的可更新能力。如果游標涉及的行是可以使用 insert 或 delete 語句中的 where current of 子

8、句進行更新或刪除，那么它就是 可刪除的。當游標可刪除時，db2 必須獲取行上的 互斥鎖（與 共享鎖相對），并且不能執(zhí)行行分塊。行上的互斥鎖甚至可以防止其它應用程序讀取該行（在互斥鎖被釋放之前，這些應用程序必須等待，除非它們的隔離級別是 ur），而行分塊通過在一個操作中檢索行塊，從而減少了用于游標的數(shù)據(jù)庫管理器開銷。 只有不可刪除的游標才可以進行行分塊。這就是為什么讓 db2 了解將如何使用游標是很重要的原因。通過在 select 語句中指定 for read only 子句，可以將游標顯式地聲明為不可刪除，或者通過在 select 語句中使用 for update 子句將其聲明為可刪除。根據(jù)該

9、信息（并且還根據(jù)下面描述的 blocking 選項），db2 將確定是否將行分塊用于給定的游標。缺省情況下，對于那些使用 for read only 子句定義的游標，db2 將始終使用行分塊，除非指定了 blocking no 綁定選項。另一方面，如果使用了 blocking all 綁定選項，那么對于含混游標（既不是定義成 for read only 也不是定義成 for update 的游標），db2 將使用行分塊。簡而言之：如果可能，則在游標定義中使用 for read only 子句；如果您的過程包含含混游標，那么請使用 blocking all 綁定選項。要設置 blocking 綁

10、定選項的值，我們還可以使用 db2_sqlroutine_prepopts 注冊表變量。在無副作用的情況下，請使用 sql 函數(shù)。正如我們在簡介中提及的，sql 過程和 sql 函數(shù)是使用不同技術實現(xiàn)的。sql 過程中的查詢是單獨編譯的，每個查詢都成為包中的一個節(jié)。編譯是在過程創(chuàng)建時進行的，直到重新創(chuàng)建過程或者直到重新綁定其相關的包時才重新編譯這些查詢。另一方面，sql 函數(shù)中的查詢是一起編譯的，就好像函數(shù)體是一個查詢一樣。每當編譯一條使用 sql 函數(shù)的語句時，也會對 sql 函數(shù)進行編譯。與 sql 過程中所發(fā)生的情況不同，sql 函數(shù)中的過程語句與數(shù)據(jù)流語句是在同一個層中執(zhí)行的。因此，每

11、當控制從過程語句流向數(shù)據(jù)流語句或相反時，并不發(fā)生上下文切換。因為存在這些區(qū)別，所以當給定的過程代碼段作為函數(shù)實現(xiàn)時的執(zhí)行速度通常比作為過程實現(xiàn)時要快。但是，當然了，有一個小問題。函數(shù)只能包含那些不會改變數(shù)據(jù)庫狀態(tài)的語句（例如 insert、update 或 delete 語句是不允許的）。并且只允許完整 sql pl 語言的子集出現(xiàn)在 sql 函數(shù)中（不能是 call 語句、游標和條件處理）。盡管有這些限制，但大多數(shù) sql 過程都可以在無副作用的情況下轉換成 sql 函數(shù)。因此，正如本節(jié)標題所展示的，當您只是從數(shù)據(jù)庫抽取數(shù)據(jù)而不執(zhí)行任何更改時，請考慮使用 sql 函數(shù)而不是使用 sql 過程

12、。使用用于臨時數(shù)據(jù)的臨時表在 v7 中，db2 引入了臨時表。對臨時表的操作通常比對常規(guī)表的操作快。讓我們看一些原因：· 首先，臨時表的創(chuàng)建不會涉及向目錄中插入項，并且臨時表的使用也不會涉及對目錄的訪問；因此，不會有目錄爭用問題。 · 因為臨時表只能由創(chuàng)建它們的應用程序訪問，因此在其操作中不會涉及鎖定問題。 · 如果指定了 not logged 選項，則不對臨時表上的操作記錄日志（當然，這樣就不可能回滾更改）。因此，如果您的存儲過程生成了大量臨時數(shù)據(jù)，并只打算在數(shù)據(jù)庫的一個會話中使用它們，那么請將這些數(shù)據(jù)存儲進臨時表，這樣可以顯著地改進性能。 在對 sql 過程中

13、的臨時表進行任何應用之前，表定義在編譯環(huán)境中必須是可用的。在執(zhí)行了 connect reset 命令后，臨時表將不復存在。在運行時，應用程序必須確保在執(zhí)行使用臨時表的首個查詢之前該表是存在的。最后的這個觀察引出了一個我們從未提及的要點：引用臨時表的任何查詢都將被動態(tài)地編譯，即使該查詢被寫成靜態(tài)的 sql。跟其它任何動態(tài)查詢一樣，在編譯該查詢之后，它將以已編譯的形式保留在包高速緩存中。在下一次執(zhí)行相同的查詢時，僅當無法在高速緩存發(fā)現(xiàn)它時，db2 才重新編譯它。如果您打算創(chuàng)建相對較大的臨時表，并對這些表運行幾個查詢，請考慮定義索引并對它們運行 runstats（顯然后者是填充了表后進行的）。有關在

14、 sql 過程中使用臨時表的最后一個說明是：如果需要根據(jù)在同一個過程中創(chuàng)建的臨時表返回結果集，那么必須在嵌套的復合語句中定義結果集。必須在嵌套的復合語句中定義結果集的理由是，declare global temporary table 是一個可執(zhí)行語句，而可執(zhí)行語句只能在聲明語句（例如 declare cursor）之后編寫。如果我們在游標定義之后在外部作用域中聲明表，那么當編譯 declare cursor 語句時，該表在編譯環(huán)境中將不可用，因此編譯會失敗。關于作者gustavo arocena是 db2 sql 編譯器方面的技術經(jīng)理。他于 1998 年加入 ibm 多倫多實驗室，目前負責

15、sql 過程和 sql 解析器的開發(fā)。gustavo 擁有多倫多大學計算機科學碩士學位，研究方向是數(shù)據(jù)庫查詢語言。 優(yōu)調sql過程資深軟件開發(fā)人員, ibm canada ltd. 2005 年 2 月普通 sql 過程如果您有 microsoft sql server 或 sybase 方面的背景知識，那么您就會很好地了解這些過程。除了一條 call 語句，這個范例的應用程序中將不存在任何 sql。通過這個范例所認識到的好處有兩個：首先是封裝。例如，如果查詢十分復雜，就不應重復查詢多次，而是應該將它存儲在某一個地方。 其次是緩存。存儲過程中的代碼是預先編譯的。而應用程序中的代碼通常是動態(tài)代碼

16、。 為了解決第一個問題，db2 支持內聯(lián) sql pl 的概念。db2 允許將簡單邏輯或查詢封裝在 sql 函數(shù)中。當從調用者執(zhí)行該 sql 函數(shù)時，其主體就是擴展到調用者中的宏。為了解決第二個問題，db2 使用了包緩存。該緩存不僅記住最近執(zhí)行的過程，還記住了以前執(zhí)行的語句。因此，在第一次編譯 sql 語句之后，后來的調用只要繼續(xù)執(zhí)行相同的執(zhí)行計劃即可。真是令人印象深刻！僅僅通過使用內聯(lián) sql pl 就使所監(jiān)控代碼的運行速度提高了三倍。甚至連不返回結果集的簡單 sql 過程也可以用 sql 函數(shù)取代。對于返回不止一個參數(shù)的過程，可以使用 sql 表函數(shù)，它返回一個包含一行的表 每個輸出參數(shù)為

17、一列。對于包含一個輸出的過程，可以只使用一個標量 sql 函數(shù)。注意，db2 v8.2 還支持在 sql 表函數(shù)中包含 update、delete、insert 和 merge。這意味著您甚至可以使用內聯(lián) sql pl 封裝數(shù)據(jù)庫更改。使用臨時表sql 術語來說，declare 表示所定義對象的目錄中將不包含條目。因此，它在定義上是私有的。與之相比，db2 udb for zos® 所支持的已創(chuàng)建的全局臨時表（created global temporary table）是在目錄中定義的。當然，雖然它們的內容是私有的，但其定義卻不是私有的。具有聲明對象的靈活性（只要用戶臨時表空間是立

18、即可用的，dba 就不會再關心該應用程序在做什么）也帶來了一個不足：對于要進行編譯的語句來說，這個對象必須存在。如果連接失敗，或者該表已刪除，那么每次重新聲明這個表時，都需要重新編譯引用 dgtt 的任何語句。declare 和 drop 之間的 insert 語句每次都要重新進行編譯，因為 db2 無法知道該 dgtt 下次是否將具有相同的屬性。實際上，declare 和 drop 之間有許多語句，都可用于處理該臨時表結果集的格式，直到它最終滿足要求為止。為了避免這種瘋狂編譯，將該臨時表的聲明移至一個單獨過程中會更合適一些，該過程只在啟動工作負載時執(zhí)行一次。正如您可以在上面看到的，其結果是令

19、人震驚的。但這里將有更多要了解的東西。請觀察取代 drop 語句的 delete 語句。它將總是因用戶引起的錯誤而失敗，然后，將由一個 continue 處理程序解決這個錯誤。這里發(fā)生了什么事？為了提高速度，需要優(yōu)化臨時表，因此，當插入行時，db2 不用費心在臨時表中尋找空閑空間，而是將表行為替換為 append only。雖然常規(guī)的 delete 將刪除這些行，但是它不會真正讓 db2 回收這些空間。應用程序將繼續(xù)消費越來越多的用戶臨時表空間。實際上，另外一個因素在這里提供了幫助。那就是，所有 dgtt 都被聲明為 not logged。畢竟，您可以相當容易地重新構建臨時表的內容。如果 no

20、t logged 表在執(zhí)行數(shù)據(jù)修改語句期間碰到了執(zhí)行錯誤，那么對于 db2 來說，就只有一個選擇：清空（truncate）該表。而這就是 delete 語句所進行的工作。條件處理程序計算機語言有兩種處理錯誤的常用方法。第一種方法要求程序在在進行每一個重大操作之后，檢查錯誤。在 db2 中編寫 c-udf 或 c 存儲過程的開發(fā)人員已經(jīng)學會在其代碼的每條 exec sql 語句之后檢查 sqlca。第二種方法就是具有專用的處理程序，“捕捉”各條語句所“拋出”的任何或特定錯誤條件。java 和 c+ 編程人員都熟悉這一概念。sql/psm 標準為 sql 過程語言定義了使用處理程序的第二種方法。然

21、而，通常當從 sybase 或 microsoft sql 服務器移植 tsql 過程時，或當僅僅對 sql pl 應用 c 技巧時，都可以避免更現(xiàn)代的處理程序方法，而支持更為傳統(tǒng)的錯誤檢查方法。這些情況下要做的事情就是定義一個通用的“萬能（catch-all）”處理程序，用于在局部變量中保存所有錯誤信息。然后，使用過程體中的顯式錯誤處理代碼進行錯誤處理。具有諷刺意味的是，在許多情況下，程序甚至可能不在乎檢查 select into 的結果是什么，因此，條件處理程序的工作是徒勞的。本例中，將完成以下幾件事。首先，可以顯式地檢查 not found 警告（如果想這樣做的話），而不必在局部變量中保

22、存 sqlcode 和 sqlstate。事實的確如此，因為該警告可用于 sql 過程中的下一條語句。其次，所有錯誤或意想不到的警告實際上應該由異常處理程序來處理。除了按照發(fā)明者所計劃的方式來使用該語言之外，這樣做可避免復制和重新設置局部變量。- 10 -introductionthere are many sources of advice available on how to tune database systems and applications. articles like db2 tuning tips for oltp applications, previously pub

23、lished on the ibm® db2® developer domain, provide advice on topics ranging from tablespace and index design to memory allocation for buffer pools, exploiting transaction and data parallelism and analyzing query plans. these topics are the abcs of performance tuning.however, specific advice

24、 on how to organize the logic in the stored procedures themselves with an eye on performance is not that common. that is the kind of advice i provide in this article. even though the article focuses on sql procedures, most of the information provided here is applicable to sql logic embedded in appli

25、cations or in stored procedures written in other languagesbackground and terminologybefore going into the details, let's first review some basic terminology and concepts related to procedural sql in db2. procedural sql constructs (such as scalar variables, if statements and while loops) were int

26、roduced in db2 with the release of db2 universal databasetm (udb) version 7. prior releases of db2 supported c and javatm as languages for stored procedures. version 7 introduced sql stored procedures. when an sql procedure is created, db2 separates the sql queries in the procedure body from the pro

27、cedural logic. to maximize performance, the sql queries are statically compiled into sections in a package. (for a statically compiled query, a section consists mainly of the access plan selected by the db2 optimizer for that query. a package is a collection of sections. for more information on pack

28、ages and sections, please refer to the db2 sql reference,volume1.) on the other hand, the procedural logic is compiled into a dll (dynamically linked library).during the execution of a procedure, every time control flows from the procedural logic to an sql statement, there is a "context switch&

29、quot; between the dll and the db2 engine. (in db2 v8, sql procedures run in "unfenced mode", i.e., in the same addressing space as the db2 engine. therefore the context switch we refer to here is not a full context switch at the operating system level, but rather a change of layer within d

30、b2.) reducing the number of context switches in procedures that are invoked very often (such as procedures in an oltp application) or that process large numbers of rows (for example, procedures that perform data cleansing) can have a noticeable impact on their performance. several of the tips in thi

31、s article aim precisely at reducing these context switches.the sql procedural language (commonly referred to as sql pl) was first allowed only in sql procedures (db2 universal database v7 ga). later on (db2 udb v7.2), a subset of the language started to be supported in sql functions and trigger bodi

32、es. this subset of sql pl is known as inline sql pl. the word "inline" highlights an important difference with the full language. whereas an sql pl procedure is implemented by statically compiling its individual sql queries into sections in a package, an inline sql pl function is implement

33、ed, as the name suggests, by inlining the body of the function into the query that uses it. we'll revisit inline sql pl later on, along with examples of its use.from multiple sql statements to a single sql expressionlike other programming languages, the sql language provides two types of conditi

34、onal constructs: procedural (if and case statements) and functional (case expressions). in most circumstances where either type can be used to express a computation, using one or the other is a matter of taste. however, logic written using case expressions is not only more compact, but also more eff

35、icient than logic written using case or if statementsexploit the set-at-a-time semantics of sql,procedural constructs such as loops, assignment and cursors allow us to express computations that would not be possible to express using just sql dml statements. but when we have procedural statements at

36、our disposal, there is a risk that we could turn to them even when the computation at hand can, in fact, be expressed using just sql dml statements. as we've mentioned earlier, the performance of a procedural computation can be orders of magnitude slower than the performance of an equivalent com

37、putation expressed using dml statements. when looking at improving the performance of existing procedural logic, any time spent in eliminating cursor loops will likely pay off.improve cursor performance.if the logic in your stored procedures does require cursors, here are a few things to keep in min

38、d to maximize their performance.first of all, make sure you don't use an isolation level higher than what you need. the isolation level determines the amount of locking that db2 applies on the rows that the procedure reads or updates. the higher the isolation level, the more locking db2 will per

39、form, and therefore, the less concurrency between applications competing for the same resources. for instance, a procedure using repeatable read (rr) isolation level will cause share locks on any row it reads, whereas a procedure using cursor stability (cs) will only lock the current row of any upda

40、table cursor. the isolation level for sql procedures can be specified with the db2_sqlroutine_prepopts registry variable.the default isolation level in db2 is cursor stability. but of course, to preserve the correctness of an application, it is sometimes necessary to use repeatable read. what is imp

41、ortant to remember is to revert db2_sqlroutine_prepopts back to a lower isolation level once procedures requiring repeatable read are created.the query above will execute with isolation level ur regardless the isolation level specified in db2_sqlroutine_prepopts.a related issue to keep in mind when

42、trying to improve cursor performance is cursor updatability. a cursor is deletable if the rows it ranges over can be updated or deleted using the where current of clause in update or delete statements. when a cursor is deletable, db2 has to obtain exclusive locks (as opposed to share locks) on rows,

43、 and cannot perform row blocking. an exclusive lock on a row prevents other applications from even reading the row (they have to wait until the lock is released, unless their isolation level is ur), whereas row blocking reduces database manager overhead for cursors by retrieving a block of rows in a

44、 single operation.row blocking can only happen for non-deletable cursors. that is why it is important to let db2 know how a cursor is going to be used. cursors can be explicitly declared as non-deletable by specifying the for read only clause in the select statement, or as deletable by using the for

45、 update clause in the select statement. based on this information (and also on the blocking option described below), db2 will decide whether to use row blocking for a given cursor or not.by default, db2 will always use row blocking for cursors defined using the for read only clause, unless the block

46、ing no bind option has been specified. on the other hand, db2 will use row blocking for ambiguous cursors (cursors that are not defined as either for read only or for update) if the blocking all bind option is used.to make a long story short: when possible, use the for read only clause in your curso

47、r definitions; if your procedures contain ambiguous cursors, use the blocking all bind option. to set the value of the blocking bind option, we also use the db2_sqlroutine_prepopts registry variable.in the absence of side-effects, use sql functions.as we mentioned in the introduction, sql procedures

48、 and sql functions are implemented using different technologies. queries in an sql procedure are compiled individually, each of them becoming a section in a package. the compilation occurs when the procedure is created, and the queries are not recompiled until the procedure is recreated or until its

49、 associated package is rebound.on the other hand, queries in sql functions are compiled together, as if the function body were a single query. the compilation occurs every time a statement that uses the function is compiled.unlike what happens in sql procedures, procedural statements in sql function

50、s are not executed in a different layer than dataflow statements. therefore, there is no context switch every time control flows from a procedural to a dataflow statement or vice versa.as a result of these differences, a given piece of procedural code will usually execute much faster when implemente

51、d as a function than when implemented as a procedure. but of course, there is a catch. functions can only contain statements that do not alter the state of the database (for example, insert, update or delete statements are not allowed). and also only a subset of the full sql pl language is allowed i

52、n sql functions (no call statements, no cursors, no condition handling).despite these restrictions, most sql procedures with no side-effects can be converted into sql functions.so, as the title of this section indicates, consider using sql functions instead of sql procedures when you're just ext

53、racting data from the database without performing any changes.use temporary tables for temporary datain version 7, db2 introduced temporary tables. operations on temporary tables are usually much faster than operations on regular tables. let's look at some of the reasons:to begin with, the creat

54、ion of a temporary table does not involve the insertion of entries in the catalogs, and use of the temporary table does not involve access to the catalogs either; therefore, there is no catalog contention. because temporary tables are only accessible to the application that created them, there is no

55、 locking involved in their manipulation. if the not logged option is specified, operations on temporary tables are not logged (at the expense, of course, of the possibility of rolling back changes). therefore, if your stored procedures generate large amounts of temporary data that are only meant to

56、be used within a session with the database, storing those data in temporary tables can result in significant performance gains.before any use of a temporary table in an sql procedure, the table definition must be available in the compilation environment.after the connect reset command, the temporary

57、 table will no longer exist. at runtime, the application will have to ensure that the table exists before the first query that uses it is executed. this last observation brings up an important point we haven't mentioned yet: any query that references a temporary table will be compiled dynamicall

58、y, even if the query is written as static sql. like any other dynamic query, after the query is compiled, it will stay in compiled form in the package cache. the next time the same query is executed, db2 will recompile it only if it is not found in the cache.if you plan to create relatively big temp

59、orary tables and run several queries on them, consider defining indexes and running runstats on them (the latter obviously after the table has been populated).one last comment on using temporary tables in sql procedures: if you need to return a result set based on a temporary table that is created in the same procedure, the result set must be defined in a nested compound statement.the reason the result se