對11.70和11.50簡單測試一下，發(fā)現(xiàn)問題

D2002

1. 背景資料：

有一個Table：

create table cust_book (
        seq_no   CHAR(10) NOT NULL,
        cust_no  CHAR(12) NOT NULL,
        currency CHAR(3) NOT NULL,
        amount   DECIAML(12,2) NOT NULL,
        ......
        tr_date   DATE NOT NULL,
        tr_status CHAR(1)
);
create custbook_idx01 on cust_book(tr_date, seq_no);
此表中有150萬條記錄。在A和B機中，同樣建此表。


A機配置，RedHat Linux Server虛擬機，安裝64位Linux系統(tǒng)(核心2.6.18-194.e15), Linux系統(tǒng)顯示單個CPU。
安裝的IDS版本：IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line -- Up 1 days 00:10:41 -- 329552 Kbytes

B機配置(雙CPU，每個CPU有6核12線程，8GB內存)，RedHat Linux Server，安裝32位Linux系統(tǒng)(核心2.6.18-308.e15), Linux系統(tǒng)顯示24個CPU。
安裝的IDS版本：IBM Informix Dynamic Server Version 11.70.UC3 -- On-Line -- Up 4 days 15:18:11 -- 1824392 Kbytes

在配置IDS 11.70時，將CPU的配置是這樣的：
VPCLASS cpu,num=16,noage
......
VPCLASS aio,num=2
......
VPCLASS jvp,num=2
......
無論cpu還是內存，配置上B機要高很多。

2. Unload 評估

運行shell文件：

date>cust.log
echo "unload to 'cust.unl' select * from cust_book;" >>cust.log
dbaccess - - <<!
DATABASE  testdb;
unload to 'cust.unl' select * from cust_book;
!
date>>cust.log

A機：用時105秒
   Tue Mar  5 08:44:52 CST 2013
    unload to 'cust01.unl' select * from cust_book;
    Tue Mar  5 08:46:37 CST 2013
B機：用時92秒
   Tue Mar  5 09:18:40 CST 2013
    unload to 'cust01.unl' select * from cust_book;
    Tue Mar  5 09:20:12 CST 2013

在A機器上運行比B機器慢，符合預期。

3. 查詢評估

用dbaccess運行：

select * from cust_book order by tr_date, seq_no;

在A機(11.50.FC9)上運行, 不用等待，馬上出現(xiàn)第一條記錄。
在B機(11.70.UC3)上運行, 等待2分鐘，還沒有出現(xiàn)第一條記錄，就強行中斷查詢。


不明白這問題所在？難道是11.70.UC3的bug？

yunzhongyue

先做個高優(yōu)然后再試下！

liaosnet

1,統(tǒng)計更新。。
2,數(shù)據(jù)緩存～

D2002

回復 2# yunzhongyue

同等條件下，簡單測試，都沒設置優(yōu)先級
   

D2002

liaosnet 發(fā)表于 2013-03-06 16:50
1,統(tǒng)計更新。。
2,數(shù)據(jù)緩存～

做了UPDATE STATISTICS后，再進行同樣的測試，現(xiàn)在正在測試。

同樣的查詢語句，等了7分鐘還多，查詢的第一條結果還沒出來。

D2002

在B機器上，重新安裝了Redhat Enterprise 6.4(x86_64), 又安裝了IDS 11.70.FC3(64位版本):
IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line -- Up 02:03:23 -- 1511728 Kbytes

Unload 測試結果： 用時51秒 （64位操作系統(tǒng)+64位IDS 11.70， 確實要快過32位操作系統(tǒng)+32位IDS 11.70）
   Tue Mar  7 11:14:57 CST 2013
    unload to 'cust01.unl' select * from cust_book;
    Tue Mar  7 11:15:49 CST 2013
接下來先做：
UPDATE STATISTICS

然后做：

select * from cust_book order by tr_date, seq_no;

等待大約10分鐘后，才出現(xiàn)第一條記錄。
同意問題出現(xiàn)在64位版本的11.70.FC3上。

通過這些簡單測試，本人覺得11.70.xC3在Index上存在問題或BUG。

希望 liaosnet 能提供11.70.xC5 或 xC6 版本測試一下。

D2002

為了測試11.70最新版本，特意下載了11.70.xC6  開發(fā)版。

在B機器(RH ES 6.4 x86_64)上，又安裝一個開發(fā)版11.70.FC6DB，開發(fā)版只支持一個CPU。
IBM Informix Dynamic Server Version 11.70.FC6DB -- On-Line -- Up 00:44:23 -- 815764 Kbytes

1. Unload 性能： 用時44秒(此次測試最快的)
   Tue Mar  7 14:10:59 CST 2013
    unload to 'cust01.unl' select * from cust_book;
    Tue Mar  7 14:11:43 CST 2013
2. select ... order by ...性能：

select * from cust_book order by tr_date, seq_no;

與11.70.FC3完全不同的，感覺不到等待時間，第一條查詢記錄馬上出來了！

看來11.70.FC3在Index上確實存在問題！

yunzhongyue

回復 4# D2002

高優(yōu)的意思是高級別的統(tǒng)計更新！
   

D2002

yunzhongyue 發(fā)表于 2013-03-07 15:44
回復 4# D2002

高優(yōu)的意思是高級別的統(tǒng)計更新！

最新的11.70.FC6D開發(fā)版測試結果，不用做任何其他處理就沒有11.70.xC3上出現(xiàn)的問題了。
可見11.70.xC3在Index上存在BUG。

3sane

回復 9# D2002


好久沒玩INFORMIX了，如果你用11.10或11.20估計你的工作就是打電話了。
看你這么說，我也躲開11.70xC3 了。個人猜想，這個版本是不是等輸出緩存滿了才輸出結果。
我的建議是：
1、用update statistics high
2、比較下2臺機器上表空間所在硬盤的性能

默認的參數(shù)都比較保守，包括系統(tǒng)和數(shù)據(jù)庫。