使用實(shí)例化的查詢表加速 DB2 UDB EEE 中的查詢

?

未顯示需要 JavaScript 的文檔選項(xiàng)

?

級(jí)別: 初級(jí)

Alexander Kuznetsov , 芝加哥，伊利諾斯州

2002 年 8 月 01 日

有時(shí)候，物理數(shù)據(jù)庫結(jié)構(gòu)中的一次簡(jiǎn)單更改會(huì)引人注目地改進(jìn)查詢性能。除了索引外，DB2 UDB 還為您提供了總結(jié)表（實(shí)例化的查詢表），在許多情況下，這些表比索引更有效。本文將提供一些示例來演示使用總結(jié)表的優(yōu)點(diǎn)。

簡(jiǎn)介

有時(shí)候，物理數(shù)據(jù)庫結(jié)構(gòu)中的一次簡(jiǎn)單更改會(huì)顯著地改進(jìn)查詢性能。除了索引外，DB2? Universal Database? 還為您提供實(shí)例化的查詢表（在版本 7.2 和更早的發(fā)行版中，稱為“總結(jié)表”），在許多情況下，這些表比索引更有效。其實(shí)，實(shí)例化的查詢表（materialized query table，MQT）是根據(jù)查詢結(jié)果定義的表。本文將描述一些示例，在這些示例中，與單獨(dú)使用索引相比，MQT 提供更有效的性能改進(jìn)。

回頁首

優(yōu)點(diǎn)：避免重復(fù)計(jì)算

MQT 可以幫助您避免對(duì)于每次查詢重復(fù)計(jì)算（如 SUM）。讓我們假設(shè)有一個(gè)名為 CUSTOMER_ORDER 的表，它存儲(chǔ)了好幾年的客戶訂單。該表的記錄超過一百萬條，平均行寬為 400 個(gè)字節(jié)。現(xiàn)在，假設(shè)我們必須對(duì) 2001 年的訂單運(yùn)行多次查詢，并且我們只需要表中的三列，如下所示：

												
														  select SUM(AMOUNT), trans_dt
  from db2inst2.CUSTOMER_ORDER
  where trans_dt between '1/1/2001' and '12/31/2001'
  group by trans_dt

或

												
														  select SUM(AMOUNT), status
  from db2inst2.CUSTOMER_ORDER
  where trans_dt between '1/1/2001' and '12/31/2001'
  group by status

如果有適當(dāng)?shù)乃饕敲催@些查詢被作為索引掃描來執(zhí)行。清單 1是執(zhí)行計(jì)劃的摘錄，它表明使用索引掃描運(yùn)行查詢的預(yù)計(jì)成本是 152455。

清單 1. 對(duì) CUSTOMER_ORDER 表運(yùn)行查詢的成本

												
														-------------------- SECTION ---------------------------------------
Section = 1


SQL Statement:

  select SUM(AMOUNT), trans_dt
  from db2inst2.CUSTOMER_ORDER
  where trans_dt between '1/1/2001' and '12/31/2001'
  group by trans_dt



        Estimated Cost        = 152455
Estimated Cardinality = 378

（這里省略了一些行）

Subsection #2:
   Access Table Name = DB2INST2.CUSTOMER_ORDER ID = 2,591
   |  #Columns = 1
   |  Index Scan:  Name = DB2INST2.CUST_ORD_TRANS_DT  ID = 4
   |  |  Index Columns:
   |  |  |  1: TRANS_DT (Ascending)

（這里省略了一些行）

End of section

現(xiàn)在，讓我們創(chuàng)建一個(gè) MQT，它包含我們所需的列和行，包括總和計(jì)算。

												
														CREATE TABLE DB2INST2.SUMMARY_CUSTOMER_ORDER_2001 AS
(SELECT SUM(AMOUNT) AS TOTAL_SUM,
TRANS_DT,
STATUS
FROM DB2INST2.CUSTOMER_ORDER
WHERE TRANS_DT BETWEEN '1/1/2001' AND '12/31/2001'
GROUP BY TRANS_DT,
STATUS)
DATA INITIALLY DEFERRED REFRESH DEFERRED;

子句 DATA INITIALLY DEFERRED 表示：數(shù)據(jù)不作為 CREATE TABLE 語句的一部分插入到表中。而是您必須執(zhí)行 REFRESH TABLE 語句來填充表。子句 REFRESH DEFERRED 表示：表中的數(shù)據(jù)僅作為發(fā)出 REFRESH TABLE 語句時(shí)的快照反映查詢結(jié)果。有關(guān)創(chuàng)建 MQT 的更多信息，請(qǐng)參閱 SQL Reference。

當(dāng)我們準(zhǔn)備填充剛才創(chuàng)建的 MQT 時(shí)，發(fā)出下面的語句：

												
														REFRESH TABLE DB2INST2.SUMMARY_CUSTOMER_ORDER_2001;

現(xiàn)在，對(duì) MQT 的查詢速度快很多，因?yàn)?MQT 的大小相當(dāng)小，它的行很短（與基表的 400 個(gè)字節(jié)相比，它才 45 個(gè)字節(jié)）。清單 2 顯示了由 dynexpln 生成的執(zhí)行計(jì)劃的摘錄，它表明了一個(gè)顯著的性能改進(jìn)，與上一個(gè)計(jì)劃的預(yù)計(jì)成本 152455 相比，它只有 101。

清單 2. 對(duì) MQT 運(yùn)行查詢減少了成本

												
														-------------------- SECTION ---------------------------------------
Section = 1


SQL Statement:

  select sum(total_sum), trans_dt
  from db2inst2.summary_customer_order_2001
  where trans_dt between '1/1/2001' and '12/31/2001'
  group by trans_dt



														
																
																		Estimated Cost        = 101
Estimated Cardinality = 25
																

這里省略了一些行

Subsection #1:
   Access Summary Table Name = DB2INST2.SUMMARY_CUSTOMER_ORDER_2001  ID = 2,44
   |  #Columns = 2
   |  Relation Scan

（這里省略了一些行）

   |  |  Sortheap Allocation Parameters:
   |  |  |  #Rows     = 21
   |  |  |  Row Width = 45
   |  |  Piped

（這里省略了一些行）

注：如果 2001 年 CUSTOMER_ORDER 中的數(shù)據(jù)在刷新之后又進(jìn)行了更新，則需要再次刷新 MQT。

回頁首

優(yōu)點(diǎn)：避免資源集中式掃描

讓我們假設(shè)，我們經(jīng)常需要最新的 2002 年總計(jì)。過去在 2002 年 1 月 3 日運(yùn)行得非常快的報(bào)告，在 5 月就運(yùn)行得慢多了，因?yàn)?2002 年的數(shù)據(jù)量增加了。正如我們前面所描述的那樣，查詢?cè)?CUSTOMER_ORDER 表上作為索引掃描執(zhí)行。

現(xiàn)在，我們應(yīng)該考慮 MQT 能如何幫助我們改進(jìn)性能。然而，因?yàn)閿?shù)據(jù)始終在更新而且我們需要最新數(shù)據(jù)，所以不能使用 REFRESH DEFERRED，因?yàn)橄乱淮胃禄頃r(shí)，MQT 將不與基表同步。現(xiàn)在，讓我們用 REFRESH IMMEDIATE 和 ENABLE QUERY OPTIMIZATION 選項(xiàng)來創(chuàng)建 MQT。

												
														CREATE TABLE DB2INST2.SUMMARY_CUSTOMER_ORDER_2002 AS(
SELECT
TRANS_DT,
STATUS,
COUNT(*) AS COUNT_ALL,
SUM(AMOUNT) AS SUM_AMOUNT,
COUNT(AMOUNT) AS COUNT_AMOUNT
FROM DB2INST2.CUSTOMER_ORDER
GROUP BY TRANS_DT,
STATUS)
DATA INITIALLY DEFERRED
REFRESH IMMEDIATE
ENABLE QUERY OPTIMIZATION;

REFRESH IMMEDIATE 表示：在用 REFRESH TABLE 語句填充 MQT 后，MQT 的內(nèi)容始終是最新的。

重要事項(xiàng)：為了使優(yōu)化器能夠自動(dòng)選擇 MQT，ENABLE QUERY OPTIMIZATION 必須是有效的（這是缺省值）。

其它語法說明：所有聚合都出現(xiàn)在 SELECT 列表的末尾。另外，雖然我們的業(yè)務(wù)只關(guān)注 SUM(AMOUNT)，但我們?nèi)员仨殞?COUNT(*) 和 COUNT(AMOUNT) 包括在全查詢中。原因很容易記住。讓我們假設(shè)正在從基表中刪除一個(gè)給定日期的所有記錄：

												
														DELETE FROM DB2INST2.CUSTOMER_ORDER WHERE TRANS_DT = ?/1/2002?

現(xiàn)在，DB2 必須檢測(cè)到特定日期的所有記錄都已消失并刪除 MQT 中的所有相應(yīng)記錄。有了 COUNT 字段就可以使 DB2 快速執(zhí)行它，而不必掃描表或其索引。僅當(dāng) AMOUNT 列可空時(shí)，才需要 COUNT(AMOUNT)。

現(xiàn)在，該填充 MQT 并刷新其統(tǒng)計(jì)信息了：

												
														REFRESH TABLE DB2INST2.SUMMARY_CUSTOMER_ORDER_2002;
RUNSTATS ON TABLE DB2INST2.SUMMARY_CUSTOMER_ORDER_2002 WITH DISTRIBUTION;

現(xiàn)在，讓我們看一下查詢性能是如何改進(jìn)的（Estimated Cost = 392）。清單 3是查詢執(zhí)行計(jì)劃的摘錄：

清單 3. 優(yōu)化器選擇使用 MQT

												
														-------------------- SECTION ---------------------------------------
Section = 1

SQL Statement:

  select SUM(AMOUNT), trans_dt
  from db2inst2.customer_order
  where trans_dt >= '1/1/2002'
  group by trans_dt

Estimated Cost        = 392
Estimated Cardinality = 268

（這里省略了一些行）

Subsection #1:
   
        Access Summary Table Name = DB2INST2.SUMMARY_CUSTOMER_ORDER_2002  ID = 2,46
   |  #Columns = 2
   |  Relation Scan

注：表 CUSTOMER_ORDER（不是總結(jié)表）是在查詢中指定的。優(yōu)化器已經(jīng)自動(dòng)選擇使用 MQT。

無論何時(shí)修改 CUSTOMER_ORDER 表，互斥的表鎖就會(huì)在 SUMMARY_CUSTOMER_ORDER_2002 上保留，直到事務(wù)結(jié)束為止。只有同時(shí)具有聚合函數(shù)和 REFRESH IMMEDIATE 選項(xiàng)的 MQT 才會(huì)這樣。因此，修改 CUSTOMER_ORDER 中相關(guān)字段（包括所有插入和刪除）的事務(wù)必須很短，以減少鎖爭(zhēng)用。這個(gè)問題不適用于用 REFRESH DEFERRED 選項(xiàng)創(chuàng)建的 MQT，也不適用于復(fù)制的 MQT（在下一節(jié)中描述）。

回頁首

優(yōu)點(diǎn)：通過使用復(fù)制的 MQT 避免廣播

讓我們假設(shè)在分區(qū)環(huán)境中有一個(gè)名為 CUSTOMER_DATA 的大表。該表 CUSTOMER_DATA 與它的子表并置（Collocate）。分區(qū)鍵是系統(tǒng)生成的整數(shù) CUSTOMER_ID。表 CUSTOMER_DATA 有一個(gè)對(duì)另一個(gè)表 ZIP_CODE 的引用。表 CUSTOMER_DATA 和 ZIP_CODE 未被并置。然而，這兩個(gè)表常常連接在一起。讓我們研究一下清單 4中所示的訪問計(jì)劃。

清單 4. 與 ZIP_CODE 的連接會(huì)引起跨節(jié)點(diǎn)廣播

												
														-------------------- SECTION ---------------------------------------
Section = 1


SQL Statement:

  select c.*, z.zip, z.state_name, z.country_name
  from db2inst2.customer_address c join db2inst2.zip_code z on
		  c.zip_cd = z.zip_cd

Estimated Cost        = 100975
Estimated Cardinality = 255819

Coordinator Subsection:
   Distribute Subsection #2
   |  Broadcast to Node List
   |  |  Nodes = 0, 1
   Distribute Subsection #1
   |  Broadcast to Node List
   |  |  Nodes = 0, 1
   Access Table Queue  ID = q1  #Columns = 38
   Return Data to Application
   |  #Columns = 38

Subsection #1:
   Access Table Queue  ID = q2  #Columns = 4
   |  Output Sorted
   |  |  #Key Columns = 1
   |  |  |  Key 1: (Ascending)
   Nested Loop Join
   |  Access Table Name = DB2INST2.CUSTOMER_ADDRESS  ID = 2,591
   |  |  #Columns = 35
   |  |  Index Scan:  Name = DB2INST2.CU_ZIP_CD  ID = 2
   |  |  |  Index Columns:
   |  |  |  |  1: ZIP_CD (Ascending)
   |  |  |  #Key Columns = 1
   |  |  |  |  Start Key: Inclusive Value
   |  |  |  |  |  1: ?
   |  |  |  |  Stop Key: Inclusive Value
   |  |  |  |  |  1: ?
   |  |  |  Data Prefetch: Eligible 162
   |  |  |  Index Prefetch: Eligible 162
   |  |  Lock Intents
   |  |  |  Table: Intent Share
   |  |  |  Row  : Next Key Share
   |  |  Insert Into Asynchronous Table Queue  ID = q1
   |  |  |  Broadcast to Coordinator Node
   |  |  |  Rows Can Overflow to Temporary Table
   Insert Into Asynchronous Table Queue Completion  ID = q1

Subsection #2:
   Access Table Name = DB2INST2.ZIP_CODE  ID = 2,590
   |  #Columns = 4
   |  Relation Scan
   |  |  Prefetch: Eligible
   |  Lock Intents
   |  |  Table: Intent Share
   |  |  Row  : Next Key Share
   |  Insert Into Sorted Temp Table  ID = t1
   |  |  #Columns = 4
   |  |  #Sort Key Columns = 1
   |  |  |  Key 1: ZIP_CD (Ascending)
   |  |  Sortheap Allocation Parameters:
   |  |  |  #Rows     = 4479
   |  |  |  Row Width = 36
   |  |  Piped
   Sorted Temp Table Completion  ID = t1
   Access Temp Table  ID = t1
   |  #Columns = 4
   |  Relation Scan
   |  |  Prefetch: Eligible
   |  Insert Into Asynchronous Table Queue  ID = q2
   |  |  
        Broadcast to All Nodes of Subsection 1
   |  |  Rows Can Overflow to Temporary Table
   Insert Into Asynchronous Table Queue Completion  ID = q2

End of section

ZIP_CODE 表不會(huì)經(jīng)常更新（因?yàn)椴怀Ｓ行碌泥]政編碼），但會(huì)經(jīng)常成為連接目標(biāo)。每次發(fā)出導(dǎo)致連接的查詢時(shí)，必須將 ZIP_CODE 表廣播到每個(gè)節(jié)點(diǎn)。

這對(duì)于要使用 復(fù)制的 MQT 來說，可能是個(gè)好情況，它基于可能已經(jīng)在單個(gè)分區(qū)節(jié)點(diǎn)組中創(chuàng)建的表，但您需要在節(jié)點(diǎn)組中的所有數(shù)據(jù)庫分區(qū)中進(jìn)行復(fù)制，以便啟用頻繁訪問的數(shù)據(jù)的并置。要?jiǎng)?chuàng)建復(fù)制的 MQT，調(diào)用帶 REPLICATED 關(guān)鍵字的 CREATE TABLE 語句。

												
														CREATE TABLE DB2INST2.SUMMARY_ZIP_CODE AS (SELECT * FROM DB2INST2.ZIP_CODE)
DATA INITIALLY DEFERRED REFRESH IMMEDIATE ENABLE QUERY OPTIMIZATION REPLICATED;

定義中不允許有聚合。ZIP_CODE 表在 ZIP_CD 上有唯一的索引。讓我們填充該表，在其上創(chuàng)建索引并更新統(tǒng)計(jì)信息：

												
														REFRESH TABLE DB2INST2.SUMMARY_ZIP_CODE;
CREATE INDEX AAA_TTT ON DB2INST2.SUMMARY_ZIP_CODE(ZIP_CD);
RUNSTATS ON TABLE DB2INST2.SUMMARY_ZIP_CODE WITH DISTRIBUTION AND DETAILED INDEXES ALL;

現(xiàn)在，優(yōu)化器自動(dòng)選擇使用復(fù)制的表，這樣，每次運(yùn)行查詢時(shí)，不必將 ZIP_CODE 表廣播到每個(gè)節(jié)點(diǎn)。

清單 5. 通過使用復(fù)制的 ZIP_CODE 表，避免某些跨節(jié)點(diǎn)廣播

												
														-------------------- SECTION ---------------------------------------
Section = 1


SQL Statement:

  select c.*, z.zip, z.state_name, z.country_name
  from db2inst2.customer_address c join db2inst2.zip_code z on
		  c.zip_cd = z.zip_cd


Estimated Cost        = 101171
Estimated Cardinality = 255819

Coordinator Subsection:
   Distribute Subsection #1
   |  Broadcast to Node List
   |  |  Nodes = 0, 1
   Access Table Queue  ID = q1  #Columns = 38
   Return Data to Application
   |  #Columns = 38

Subsection #1:
   Access Summary Table Name = DB2INST2.SUMMARY_ZIP_CODE  ID = 2,47
   |  #Columns = 4
   |  Relation Scan
   |  |  Prefetch: Eligible
   |  Lock Intents
   |  |  Table: Intent Share
   |  |  Row  : Next Key Share
   |  Insert Into Sorted Temp Table  ID = t1
   |  |  #Columns = 4
   |  |  #Sort Key Columns = 1
   |  |  |  Key 1: ZIP_CD (Ascending)
   |  |  Sortheap Allocation Parameters:
   |  |  |  #Rows     = 8958
   |  |  |  Row Width = 36
   |  |  Piped
   Sorted Temp Table Completion  ID = t1
   Access Temp Table  ID = t1
   |  #Columns = 4
   |  Relation Scan
   |  |  Prefetch: Eligible
   Nested Loop Join
   |  Access Table Name = DB2INST2.CUSTOMER_ADDRESS  ID = 2,591
   |  |  #Columns = 35
   |  |  Index Scan:  Name = DB2INST2.CU_ZIP_CD  ID = 2
   |  |  |  Index Columns:
   |  |  |  |  1: ZIP_CD (Ascending)
   |  |  |  #Key Columns = 1
   |  |  |  |  Start Key: Inclusive Value
   |  |  |  |  |  1: ?
   |  |  |  |  Stop Key: Inclusive Value
   |  |  |  |  |  1: ?
   |  |  |  Data Prefetch: Eligible 162
   |  |  |  Index Prefetch: Eligible 162
   |  |  Lock Intents
   |  |  |  Table: Intent Share
   |  |  |  Row  : Next Key Share
   |  |  Insert Into Asynchronous Table Queue  ID = q1
   |  |  |  Broadcast to Coordinator Node
   |  |  |  Rows Can Overflow to Temporary Table
   Insert Into Asynchronous Table Queue Completion  ID = q1

End of section

雖然在我們的示例中，使用復(fù)制的 MQT 的預(yù)計(jì)成本稍微高了點(diǎn)（101171 vs. 100975）（因?yàn)槲覀冋诹硗庖环N空閑系統(tǒng)上運(yùn)行，這種系統(tǒng)將兩個(gè)分區(qū)放同一臺(tái)計(jì)算機(jī)上。）然而，當(dāng)節(jié)點(diǎn)駐留在不同計(jì)算機(jī)上并且它們之間的網(wǎng)絡(luò)很忙時(shí)，在這種情況下使用復(fù)制的 MQT 的性能優(yōu)點(diǎn)會(huì)變得明顯。

所以，當(dāng)您從以下這樣的表中復(fù)制數(shù)據(jù)時(shí)，使用復(fù)制的 MQT 會(huì)有性能方面的優(yōu)勢(shì)：

是經(jīng)常連接的。
很少更新（即使曾經(jīng)更新過）。
不太大（雖然如果并置的性能優(yōu)勢(shì)可以抵消復(fù)制的一次性成本，您可能會(huì)考慮復(fù)制不太更新的大表。）

另外，對(duì)于復(fù)制的 MQT，不會(huì)發(fā)生針對(duì) REFRESH IMMEDIATE 表所描述的鎖定問題。

回頁首

REFRESH IMMEDIATE vs. REFRESH DEFERRED

REFRESH IMMEDIATE MQT 會(huì)象索引那樣影響查詢的性能。這些影響包括：

加速相關(guān)選擇（select）語句的性能。
只要有意義，就由優(yōu)化器自動(dòng)選擇它們。
會(huì)降低插入（insert）、更新（update）和刪除（delete）語句的性能。
不能直接更新。
可能會(huì)占用相當(dāng)大的磁盤空間。
在更新其基表期間，可能會(huì)保留互斥鎖。

要查看對(duì)更新性能的影響，請(qǐng)參閱清單 6（仍沒有 MQT）中所示的 INSERT 語句的 EXPLAIN 輸出。

清單 6. 對(duì)基本 ZIP_CODE 表執(zhí)行的 INSERT 操作

												
														-------------------- SECTION ---------------------------------------
Section = 1

SQL Statement:

  insert into db2inst2.zip_code(zip_cd, zip, state_cd, state_name,
		  country_name) values (60606, '60606', 'IL', 'Illinois',
		  'United States')


        Estimated Cost        = 25
Estimated Cardinality = 1

（這里省略了一些行）

現(xiàn)在，讓我們添加用 REFRESH IMMEDIATE 選項(xiàng)創(chuàng)建的 MQT，并查看清單 7 中所示的 EXPLAIN 輸出。

清單 7. 用 REFRESH IMMEDIATE 創(chuàng)建的 MQT 上的 INSERT 會(huì)增加性能成本

												
														-------------------- SECTION ---------------------------------------
Section = 1


SQL Statement:

  insert into db2inst2.zip_code(zip_cd, zip, state_cd, state_name,
		  country_name) values (60606, '60606', 'IL', 'Illinois',
		  'United States')



        Estimated Cost        = 50
Estimated Cardinality = 1

（這里省略了一些行）

在這個(gè)特殊示例中，當(dāng)存在 REFRESH IMMEDIATE MQT 時(shí)，插入記錄的預(yù)計(jì)成本是雙倍的。另一方面，REFRESH DEFERRED MQT 沒有降低插入、更新和刪除語句的性能。

適度使用 REFRESH IMMEDIATE MQT，以僅僅優(yōu)化頻繁運(yùn)行且當(dāng)前數(shù)據(jù)很重要的查詢。一些 MQT 不適于立即刷新條件。可以在 SQL Reference中找到準(zhǔn)確的規(guī)則。

回頁首

讓優(yōu)化器決定

優(yōu)化器可以根據(jù)以下條件選用用 REFRESH IMMEDIATE 選項(xiàng)創(chuàng)建的 MQT 來代替其基表：

基表、MQT 及其索引的當(dāng)前統(tǒng)計(jì)信息。
CURRENT QUERY OPTIMIZATION 設(shè)置的值。

如果 CURRENT REFRESH AGE 設(shè)置選項(xiàng)設(shè)置為 ANY，則優(yōu)化器可以使用用 REFRESH DEFERRED 選項(xiàng)創(chuàng)建的 MQT。在 SQL Reference中詳細(xì)描述了 CURRENT QUERY OPTIMIZATION 和 CURRENT REFRESH AGE 設(shè)置選項(xiàng)。

為優(yōu)化器提供 MQT、創(chuàng)建適當(dāng)?shù)乃饕⑹菇y(tǒng)計(jì)信息保持最新。并讓優(yōu)化器選擇是使用基表還是使用總結(jié)表。在某些情況下，優(yōu)化器將選擇不使用 MQT。

不管 CURRENT REFRESH AGE 和 CURRENT QUERY OPTIMIZATION 設(shè)置選項(xiàng)的值是什么，您都可以直接在 SELECT 語句的 WHERE 子句中用 REFRESH DEFERRED 和 REFRESH IMMEDIATE 來指定 MQT。

回頁首

結(jié)束語

正如我們所看到的那樣，如果正確應(yīng)用了 MQT，那么它們?cè)诟鞣N情況下會(huì)非常有用。上面的示例演示了如何應(yīng)用 MQT 來改進(jìn)查詢性能。雖然 MQT 使用起來十分方便，但需要額外的磁盤空間。用 REFRESH DEFERRED 選項(xiàng)創(chuàng)建的 MQT 不會(huì)影響對(duì)基表執(zhí)行插入、更新和刪除的性能，而用 REFRESH IMMEDIATE 選項(xiàng)創(chuàng)建的 MQT 會(huì)影響。

回頁首

關(guān)于作者


		Alexander Kuznetsov 在軟件設(shè)計(jì)、開發(fā)和數(shù)據(jù)庫管理方面已經(jīng)有十四年的經(jīng)驗(yàn)。目前，他正在設(shè)計(jì) DB2 UDB EEE 中多 TB 級(jí)群集數(shù)據(jù)庫。Alexander 是 IBM 認(rèn)證的高級(jí)技術(shù)專家（DB2 群集）和 IBM 認(rèn)證的解決方案專家（數(shù)據(jù)庫管理和應(yīng)用程序開發(fā)）。可以通過 comp.databases.ibm-db2 新聞組與他聯(lián)系。

posted on 2006-12-19 15:01 hardson 閱讀(368) 評(píng)論(0) 編輯收藏所屬分類: 數(shù)據(jù)庫

新用戶注冊(cè) 刷新評(píng)論列表


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問管理

<

2025年7月

>

日

一

二

三

四

五

六

29

30

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

導(dǎo)航

統(tǒng)計(jì)

隨筆 - 5
文章 - 13
評(píng)論 - 10
引用 - 0