亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 拳打Informix 9.3，腳踢Informix 9.4，強(qiáng)烈BS [打印本頁]

作者: 大夫 時(shí)間: 2006-01-06 11:24
標(biāo)題: 拳打Informix 9.3，腳踢Informix 9.4，強(qiáng)烈BS
1,execute plan
Informix的execute plan,
1)單條SQL語句,可以通過以下方式得到
% dbaccess  database_name  -
Database selected.
> set explain on;
Explain set.
> 執(zhí)行SQL語句
然后Ctrl+c退出會(huì)話,在當(dāng)前目錄會(huì)有一個(gè)sqexplain.out,里面記錄了執(zhí)行計(jì)劃。
2)Procedure,可以通過
% dbaccess  database_name  -
Database selected.
> set explain on;
Explain set.
> update statistics for procedure procedure_name;
Routine Statistics updated.
然后Ctrl+c退出會(huì)話,在當(dāng)前目錄會(huì)有一個(gè)sqexplain.out,里面記錄了procedure里所有SQL語句的執(zhí)行計(jì)劃。

Oracle,隨便一舉,就要N多種方法查看,如
SQLPLUS里set autotrace,alter session set sql_trace,alter session set events等等方法，還提供了跟蹤文件分析工具，可分析出N多有用的信息。

Informix那破玩意兒，就一個(gè)簡單的描述說是否走索引，成本值是多少，過濾條件是什么，估計(jì)返回多少行就完了，，語句執(zhí)行的順序都沒有，不過還好的是，如果用了索引，把這個(gè)要用的索引的所有字段列表都列出來了，就不給索引名稱了，

2,extend
Informix的extend居然有數(shù)量限制，如果一個(gè)表默認(rèn)設(shè)置extend小了，表大到一定程度，居然不再能插入數(shù)據(jù)，必須把表導(dǎo)出來，創(chuàng)建一個(gè)大的extend大小再導(dǎo)進(jìn)去，你說變態(tài)不變態(tài)

3,sql性能數(shù)據(jù)歷史記錄
Informix這個(gè)死變態(tài)，提供的SQL性能視圖就那么幾個(gè)，還啥鳥都查不出來。默認(rèn)配置參數(shù)，居然還不啟動(dòng)STMT_CACHE設(shè)置，猜測(cè)是因?yàn)椴惶峁﹦?dòng)態(tài)SQL語句執(zhí)行而默認(rèn)不用的，不然程序員一般使用公共接口，不會(huì)去寫綁定變量，INFORMIX擔(dān)心STMT_CACHE_SIZE變太大太大，或管理開銷太大被口水淹死，所以干脆默認(rèn)就不配置。提供了個(gè)onstat -g ssc，有用的東西沒幾個(gè)，，SQL性能指標(biāo)都沒找到。如執(zhí)行時(shí)間，物理讀/寫，邏輯讀/寫都沒有。
打個(gè)電話問INFORMIX技術(shù)支持，那鳥人居然說不知道，去查，查回來告訴我說沒有，建議使用server studio JE5.1，這是什么鳥玩意？沒見過。

4,SMI表解釋
SMI表就提供了那么幾張表的解釋，，對(duì)性能監(jiān)控來說，用處不大。在網(wǎng)上找到了sysmaster表的說明，認(rèn)真觀察了一下，也沒發(fā)現(xiàn)幾張有用的系統(tǒng)表。

5,分區(qū)支持
這個(gè)死克郎皮，9.3/9.4只提供了范圍分區(qū)，其他分區(qū)不提供，祖宗我還認(rèn)真看了文檔，高興的用HASH，結(jié)果一試不行，賠償我興奮死掉的腦細(xì)胞！
不過INFORMIX提供的在線重初始化分區(qū)方案，和分區(qū)表和非分區(qū)表之間的在線合并分離，我還是非常喜歡的，不能不表揚(yáng)一下下。。。

6,9.3和9.4的區(qū)別
同一個(gè)公司，兩個(gè)小版本，居然系統(tǒng)表名，字段名都變了，你說它鬼不鬼，升級(jí)還非常麻煩，導(dǎo)致一直沒做成升級(jí)。

7,系統(tǒng)工具難使
其實(shí)那有什么系統(tǒng)工具？onstat?onmode?onperf?onmonitor?，那一個(gè)是好使的。INFORMIX就TM以會(huì)話為單位統(tǒng)計(jì)一些性能數(shù)據(jù)，結(jié)果，你知道是那個(gè)會(huì)話頂鳥用，大型應(yīng)用那么多會(huì)話，用完就關(guān)閉，你知道那個(gè)是那個(gè)？它還不提供歷史記錄。

8,內(nèi)存分配,參數(shù)初始化設(shè)置
內(nèi)存分配名義上提供了好多參數(shù)設(shè)置，每個(gè)感覺都滿靈活的，可TM一用起來的時(shí)候，你就知道不爽了！

9,動(dòng)態(tài)SQL
一個(gè)字：不支持。

10,在線交互工具
dbaccess？那有sqlplus那么豐富的功能，，用dbaccess db_name -  這種方法登陸，稍微象了一點(diǎn)，結(jié)果啥幫助都不提供，只能執(zhí)行SQL語句。退出還得Ctrl + c。

其他就不說了，越寫越累。。。

[ 本帖最后由大夫于 2006-1-18 00:19 編輯 ]

作者: snow888 時(shí)間: 2006-01-07 08:52
老大,你是在 informix 版發(fā)表這樣的言論,不怕被圍攻么?

不會(huì)使用可以學(xué),不會(huì)用還不謙虛,不愿意學(xué),一味的說 informix 系統(tǒng)的壞話,不是求學(xué)之道吧?

informix 被 IBM 收購,并不是它的數(shù)據(jù)庫系統(tǒng)不優(yōu)秀,實(shí)際上 informix 與 oracle 在數(shù)據(jù)庫應(yīng)用領(lǐng)域各有優(yōu)勢(shì),很難分清哪一個(gè)更好,informix 的失誤在于它選錯(cuò)了發(fā)展的方向和市場(chǎng)運(yùn)作出現(xiàn)了問題.

還是多看看 informix 方面的書吧,等你真正了解了 informix ,就不會(huì)發(fā)表這寫言論了.

作者: IFMXDBA 時(shí)間: 2006-01-07 09:08
標(biāo)題: 回復(fù) 2樓 snow888 的帖子
can't agree with you more. Yes, every product has is pros and cons. Informix has lots of excellent feature; no doubts, it has lots of awkward aspects.

作者: 大夫 時(shí)間: 2006-01-09 09:55

原帖由 snow888 于 2006-1-7 08:52 發(fā)表
老大,你是在 informix 版發(fā)表這樣的言論,不怕被圍攻么?

不會(huì)使用可以學(xué),不會(huì)用還不謙虛,不愿意學(xué),一味的說 informix 系統(tǒng)的壞話,不是求學(xué)之道吧?

informix 被 IBM 收購,并不是它的數(shù)據(jù)庫系統(tǒng)不優(yōu)秀,實(shí)際上 ...

怕什么圍攻？我對(duì)所有數(shù)據(jù)庫都沒有特別愛好，僅僅是工作需要而已，老板說用那個(gè)我就用那個(gè)了，我想大家沒有對(duì)那種數(shù)據(jù)庫有什么特別的感情吧？如果說有，被攻擊也是好的，被攻擊的同時(shí)，肯定也會(huì)引出一些重要的技術(shù)點(diǎn)出來，我也正好跟著學(xué)習(xí)。

唉，我已經(jīng)在學(xué)了，我上面提到的，都是希望能用到的特性了，不知道你大概瀏覽了一下沒有，接觸Informix差不多兩年了，我說INFORMIX不爽，都說了是和ORACLE做比較的了，INFORMIX能做成這樣，已經(jīng)非常非常厲害的了，我不是不承認(rèn)他厲害，只是我是以一個(gè)用戶的觀點(diǎn)，來表達(dá)我使用過程中的一些不滿了。ORACLE同樣讓我不滿，只是沒INFORMIX那么多而已。INFORMIX同樣也有我喜歡的東西，只是比較少而已了。表達(dá)完不滿后，我還是一樣得低著腦袋繼續(xù)啃它了。

以下是我當(dāng)前收藏的INFORMIX資料，遠(yuǎn)遠(yuǎn)小于我收藏的ORACLE資料，不是我不想找，是找不到：
│  informix training 20050920 - .doc
│  informix 培訓(xùn)專題：集成基礎(chǔ)I v1.00.doc
│  informix優(yōu)化總結(jié)20051228hxjiang.doc
│
├─IBM Informix Guide to SQL(cn)
│    DBACCESS用戶指南.pdf
│    DYNAMIC FOR UNIX LINUX 安裝指南.pdf
│    DYNAMIC FOR WINDOWS 安裝指南.pdf
│    ENTERPRISE REPLICATION 指南.pdf
│    GLS 用戶指南.pdf
│    HIGH-PERFORMANCE LOADER 用戶指南.pdf
│    INFORMIX DYNAMIC SERVER 入門指南.pdf
│    Simplified Chinese IBM Informix Guide to SQL- Reference.pdf
│    Simplified Chinese IBM Informix Guide to SQL- Syntax.pdf
│    Simplified Chinese IBM Informix Guide to SQL- Tutorial.pdf
│    SQL參考指南pdf.pdf
│    SQL參考指南語法.pdf
│    SQL教程指南pdf.pdf
│    備份與恢復(fù)指南.pdf
│    存儲(chǔ)過程.sql
│    性能指南.pdf
│    數(shù)據(jù)庫設(shè)計(jì)和實(shí)現(xiàn)指南.pdf
│    用戶定義的例程與數(shù)據(jù)類型開發(fā)者指南.pdf
│    管理員參考大全.pdf
│    管理員指南.pdf
│    管理員指南2.pdf
│    遷移指南.pdf
│
├─IBM Informix92文檔
│    Archive and Backup Guide.pdf
│    DB-access指南.pdf
│    備份和恢復(fù)指南.pdf
│    性能指南.pdf
│    數(shù)據(jù)庫設(shè)計(jì)和實(shí)現(xiàn)指南.pdf
│    管理指南.pdf
│    遷移指南.pdf
│
├─IBM Informix93文檔
│    備份和恢復(fù)指南.pdf
│    安裝指南.pdf
│    性能指南.pdf
│    管理指南.pdf
│    遷移指南.pdf
│
├─IBM Informix94文檔
│    DB-Access用戶指南.pdf
│    Enterprise Replication指南.pdf
│    GLS 用戶指南.pdf
│    High-Performance Loader.pdf
│    IDS入門指南.pdf
│    IDS安裝指南（UNIX）.pdf
│    IDS安裝指南（Windows）.pdf
│    IDS性能指南.pdf
│    IDS管理員參考指南.pdf
│    IDS管理員指南.pdf
│    Informix Storage Manager管理員指南.pdf
│    Informix 遷移指南.pdf
│    SQL 參考指南.pdf
│    SQL 指南：語法.pdf
│    SQL 教程指南.pdf
│    備份與恢復(fù)指南.pdf
│    數(shù)據(jù)庫設(shè)計(jì)和實(shí)現(xiàn)指南.pdf
│    用戶定義的例程與數(shù)據(jù)類型開發(fā)者指南.pdf
│
└─Informix 9.3 Document
      5343A.pdf
      5402A.pdf
      5403A.pdf
      5404A.pdf
      6363A.pdf
      6502A.pdf
      6636A.pdf
      6638A.pdf
      6684A.pdf
      8320.pdf
      8321.pdf
      8322.pdf
      8323.pdf
      8324.pdf
      8326.pdf
      8327.pdf
      8330.pdf
      8331.pdf
      8332.pdf
      8333.pdf
      8334.pdf
      8335.pdf
      8336.pdf
      8338.pdf
      8341.pdf
      8342.pdf
      8343.pdf
      8344.pdf
      8345.pdf
      8346.pdf
      8347.pdf
      8348.pdf
      8349.pdf
      8350.pdf
      8354.pdf
      8363.pdf
      index.htm

[ 本帖最后由大夫于 2006-1-9 10:06 編輯 ]

作者: 大夫 時(shí)間: 2006-01-09 09:59
蒼天，你可曾知道
可曾知道，收集這些資料過程中的困難
可曾知道，和INFORMIX技術(shù)支持打交道的困難（INFORMIX技術(shù)支持態(tài)度很好，能力只能說是比我強(qiáng)）
可曾知道，要想了解一個(gè)INFORMIX技術(shù)問題得通過多少途徑，查閱多少資料
可曾知道，當(dāng)一個(gè)個(gè)應(yīng)用需求提出來，INFORMIX一次次回答說不行的時(shí)的感受
可曾知道，
。。。。。。

作者: wolfop 時(shí)間: 2006-01-09 14:08
動(dòng)態(tài)SQL不支持？有點(diǎn)暈，呵呵。
SMI表IDS的確就沒有打算支持，他們的開發(fā)人員看不起ORACLE那種獲得所有信息都要靠SQL的方式，認(rèn)為增加服務(wù)器負(fù)擔(dān)，所以認(rèn)為onstat夠了。
不過INFORMIX的各種調(diào)優(yōu)，呵呵，現(xiàn)在都快成了非主流的東西，是那個(gè)德性了。不過IDS的確也認(rèn)為很多東西不用調(diào)整。

作者: philein 時(shí)間: 2006-01-09 16:52
建議LZ自己開發(fā)套數(shù)據(jù)庫就不會(huì)抱怨了。。

作者: 大夫 時(shí)間: 2006-01-10 00:00

原帖由 wolfop 于 2006-1-9 14:08 發(fā)表
動(dòng)態(tài)SQL不支持？有點(diǎn)暈，呵呵。
SMI表IDS的確就沒有打算支持，他們的開發(fā)人員看不起ORACLE那種獲得所有信息都要靠SQL的方式，認(rèn)為增加服務(wù)器負(fù)擔(dān)，所以認(rèn)為onstat夠了。
不過INFORMIX的各種調(diào)優(yōu)，呵呵，現(xiàn)在都快 ...

IDS只支持在比如C語言里使用變量綁定,而現(xiàn)在寫程序,一般都是提供一個(gè)公共接口模塊,所以程序員寫的程序里,是非綁定的,接口里沒有提供綁定.包括在SPL里也不提供綁定變量的接口(類似ORACLE的immediate execute的動(dòng)態(tài)綁定接口).

我相信目前國內(nèi)不少公司開發(fā)的軟件,在上線以前是不會(huì)認(rèn)真嚴(yán)格分析每一個(gè)SQL語句的執(zhí)行效率的,如果僅僅一個(gè)onstat就夠了,舉例,我現(xiàn)在有一個(gè)系統(tǒng),每小時(shí)生成的SQL量(超過9G,onstat -g ssc查到),我怎么知道是那些SQL語句嚴(yán)重導(dǎo)致了系統(tǒng)性能低下?而我很多SQL是在SPL里執(zhí)行的,不能綁定,每執(zhí)行一次解析一次,系統(tǒng)消耗是不是大了一點(diǎn)?

如果IDS現(xiàn)在認(rèn)為自己可以自己動(dòng)態(tài)調(diào)整,不需要人工調(diào)整,那自己跑快點(diǎn)啊......可是它又跑不快。同樣的應(yīng)用,在ORACLE里,優(yōu)化后可以很快速就執(zhí)行完的,在INFORMIX里就不行,而且都不方便測(cè)試,觀察。

看樓主說話,感覺用INFORMIX很有經(jīng)驗(yàn)的樣子,先景仰一下,方便的時(shí)候請(qǐng)教一下

[ 本帖最后由大夫于 2006-1-10 00:13 編輯 ]

作者: 大夫 時(shí)間: 2006-01-10 00:10

原帖由 philein 于 2006-1-9 16:52 發(fā)表
建議LZ自己開發(fā)套數(shù)據(jù)庫就不會(huì)抱怨了。。

唉,其實(shí)我不是看不起INFORMIX了,已經(jīng)承認(rèn)他非常厲害了,只是希望他能好用點(diǎn).你要真讓我自己開發(fā)套數(shù)據(jù)庫,我差不多可以告訴樓主,再給我10輩子我也搞不出來。所有的一切,都源自應(yīng)用需要而已。
我們這里講的,是不管他數(shù)據(jù)庫廠商的開發(fā)結(jié)構(gòu)是什么.只是問:
公司領(lǐng)導(dǎo)在應(yīng)用慢的時(shí)候,讓你把數(shù)據(jù)庫搞快點(diǎn),你會(huì)如何做?(千萬不要回答在應(yīng)用上線前應(yīng)該把每條SQL測(cè)試一下,在國內(nèi)不少公司來說，那是不可能的;如果樓主用過ORACLE,是不是覺得STATSPACK很爽?呵呵)

我用過ORACLE,INFORMIX,SYBASE,完全沒接觸過DB2,從內(nèi)心來說,我還是喜歡ORACLE多些,因?yàn)楹枚鄸|西很方便.信息全。呵呵,搞數(shù)據(jù)庫優(yōu)化是一個(gè)比較郁悶的工作了,大家就當(dāng)是對(duì)社會(huì)主義不滿,在這發(fā)發(fā)牢騷吧.

[ 本帖最后由大夫于 2006-1-10 00:12 編輯 ]

作者: ifx 時(shí)間: 2006-01-10 09:57
標(biāo)題: 寸有所長，尺有所短
不喜歡就不喜歡了，不必爭(zhēng)論這些，其實(shí)樓住所說的很多東西/問題，可能并不是問題，就看你用的怎樣了
INFORMIX的小巧靈活，資源占用少，效率高，還有很多先進(jìn)的技術(shù)比如HDR等都是不錯(cuò)的東西，它并不是那種以空間換時(shí)間的，或者以資源換效率的東西，我認(rèn)為它比較好的平衡了資源/效率，空間/時(shí)間，費(fèi)用/成本等
如果說IBM收購INFORMIX，除了開放平臺(tái)上的市場(chǎng)以外，還有的就是要收購INFORMIX的技術(shù)，看看現(xiàn)在的DB2就知道了
INFORMIX不方便的地方，我倒覺得并不想樓主所說的，而是沒有reorg，online建索引等功能
偶爾上來，忍不住多說了幾句

作者: lianyong 時(shí)間: 2006-01-10 22:37
樓主的經(jīng)驗(yàn)之談，路過，參考一下。。。

作者: ibm_informix 時(shí)間: 2006-01-12 15:14
一個(gè)項(xiàng)目選什么數(shù)據(jù)庫,不是工程師說了算,集成商要看賣那個(gè)軟件能給他帶來最大的利潤,那可是另外的一個(gè)領(lǐng)域.好好學(xué)習(xí)吧，工程師，你的路還遠(yuǎn)呢。。。

作者: xxyyy 時(shí)間: 2006-01-12 15:40

原帖由 ibm_informix 于 2006-1-12 15:14 發(fā)表
一個(gè)項(xiàng)目選什么數(shù)據(jù)庫,不是工程師說了算,集成商要看賣那個(gè)軟件能給他帶來最大的利潤,那可是另外的一個(gè)領(lǐng)域.好好學(xué)習(xí)吧，工程師，你的路還遠(yuǎn)呢。。。

嚴(yán)重同意。

作者: zzjijun 時(shí)間: 2006-01-12 15:47
工作太忙，時(shí)間沒有，大多潛水。今天看了這貼，就說幾句吧

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順序沒注意，好像每次看了執(zhí)行路徑都大概知道了順序，需要的信息都用了。
不給索引名也沒注意過，作者實(shí)在覺著麻煩也不用罵娘，這類的缺陷隨便那個(gè)軟件都能找出一堆來。

2. Extend有限制有什么新鮮的，現(xiàn)代計(jì)算機(jī)最基本的CPU,memory,I/O都有限制，作者說個(gè)Oracle沒限制的東西給我看看？
Extend問題如果沒有經(jīng)驗(yàn)是會(huì)遇到，如果經(jīng)過培訓(xùn)，學(xué)習(xí)應(yīng)該可以掌握吧。

3. 系統(tǒng)監(jiān)控Informix本身提供的工具并不多，這和Oracle的策略不同。
Oracle本身養(yǎng)了很多研究人員來開發(fā)基于Oracle的工具。而IBM對(duì)DB2,Informix來說只開發(fā)數(shù)據(jù)庫本身的產(chǎn)品，其他工具軟件是交給了第三方的軟件開發(fā)商來做。
比如server studio JE5.1，我還見過一家臺(tái)灣公司做的Informix監(jiān)控管理軟件。都是基于Informix開放的API函數(shù)和系統(tǒng)表來做的。

4. 從來沒覺得Informix的系統(tǒng)表少些什么內(nèi)容，但有些系統(tǒng)表是undocument，就是不希望用戶訪問的。

5,分區(qū)支持
Informix的hash分區(qū)偶用過。

6,9.3和9.4的區(qū)別
版本的升級(jí)，憑什么要規(guī)定人家變化什么，不變化什么。9.3升級(jí)到9.4很容易呀。

7,系統(tǒng)工具難使用
這恰恰是我覺得Informix的一個(gè)優(yōu)點(diǎn), 一個(gè)onstat就搞定很多事，要查的東西差不多都有了。
有時(shí)是要寫些sql, shell來完成復(fù)雜的管理任務(wù)，不過那個(gè)資深的DBA沒寫過sql,shell呢？

8,內(nèi)存分配,參數(shù)初始化設(shè)置
我見過很多大型應(yīng)用用的都挺好的呀。會(huì)不會(huì)用不等于好不好用。

9,動(dòng)態(tài)SQL
支持！

10,在線交互工具
dbaccess也還可以呀，偶一開始用sqlplus的時(shí)候也不習(xí)慣呢。

呵呵，好像Q&A的說了那么多。說點(diǎn)題外話吧。

要比數(shù)據(jù)庫，可以從
系統(tǒng)架構(gòu)
性能
安全性
可擴(kuò)展性
可用性
易管理性
等等方面去比。作者有空給點(diǎn)建議。

還有估計(jì)作者也是受過高等教育的，先拋開做技術(shù)的層次，一個(gè)有素質(zhì)的人，說一堆kao,cao,TMD對(duì)討論問題有什么幫助嗎？
海納百川有容乃大。退一步說作者要做到研究關(guān)系型數(shù)據(jù)庫的全球頂尖人物，要說點(diǎn)什么大話，大伙也沒意見。
可提的這些個(gè)問題，呵呵。。。

[ 本帖最后由 zzjijun 于 2006-1-12 15:51 編輯 ]

作者: 大夫 時(shí)間: 2006-01-13 09:21

原帖由 zzjijun 于 2006-1-12 15:47 發(fā)表
工作太忙，時(shí)間沒有，大多潛水。今天看了這貼，就說幾句吧

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順 ...

先回答這一句:
"
還有估計(jì)作者也是受過高等教育的，先拋開做技術(shù)的層次，一個(gè)有素質(zhì)的人，說一堆kao,cao,TMD對(duì)討論問題有什么幫助嗎？
海納百川有容乃大。退一步說作者要做到研究關(guān)系型數(shù)據(jù)庫的全球頂尖人物，要說點(diǎn)什么大話，大伙也沒意見。
可提的這些個(gè)問題，呵呵。。。
"

我本科畢業(yè),但我從不因?yàn)槲沂潜究飘厴I(yè)就認(rèn)為我比其他人有素質(zhì)!高中時(shí)就曾聽哲學(xué)老師說過,英國人最紳士,但他們大多回家就打老婆,家庭暴力不斷!君子劍岳不群很君子,可惜是偽君子!我就是我,最BS表里不一的人.至于說COW,CAO,KAO,TMD,我說了，表示當(dāng)時(shí)我的情緒比較激動(dòng),只覺得通過說這個(gè)話才能表達(dá)我當(dāng)時(shí)的心情!樓主從沒說過這些話?或者說樓主大學(xué)畢業(yè)后從沒說過這些話?如果是,我非常非常認(rèn)真的給樓主道歉!!!如果不是,那請(qǐng)樓主下次閉上鳥嘴!本人生平最煩偽道學(xué)!!!我的觀點(diǎn),寧做真小人，絕不做偽君子!忘記那個(gè)電影說的了，說穿著西裝的人最危險(xiǎn)!!!呵呵,這話又讓我想起了部連續(xù)劇《不要和陌生人說話》，樓主以為里面的男主角怎樣？符合樓主的胃口嗎？還是樓主就是這樣的人？----一切都是猜測(cè)而已。

開篇我就說了，用什么數(shù)據(jù)庫不是我所決定的，是公司決定的，或不能說是公司決定的，是客戶決定的，我們公司只是給用戶一個(gè)建議，具體用戶選擇哪個(gè)廠家的數(shù)據(jù)庫，就要看數(shù)據(jù)庫廠商的銷售手段了，我使用的9.3版INFORMIX數(shù)據(jù)庫有2個(gè)，INFORMIX 9.4版數(shù)據(jù)庫超過10個(gè)，Oracle 8i 超過8個(gè)，Oracle 9i超過 8個(gè)，Sybase 12.5 超過3個(gè)。我沒有經(jīng)過系統(tǒng)的培訓(xùn)，一切全是靠網(wǎng)上看別人的帖子，搜索別人總結(jié)的資料，這點(diǎn)真的非常非常感謝那么些無私貢獻(xiàn)的人們，讓我少走了很多彎路，快速接觸數(shù)據(jù)，同時(shí)只能看看廠家隨光盤帶來的文檔，還有就是打技術(shù)支持電話。因?yàn)槲覀儾皇窃诰€運(yùn)營商，業(yè)務(wù)不是關(guān)鍵業(yè)務(wù)，所以對(duì)數(shù)據(jù)庫的應(yīng)用要求不是特別高，這才讓我有機(jī)會(huì)在這3種數(shù)據(jù)庫里學(xué)習(xí)，我感謝這個(gè)環(huán)境提供的機(jī)會(huì)。由于學(xué)習(xí)時(shí)日不長，不到4年，期間還干了其他內(nèi)容的工作，所以數(shù)據(jù)庫的很多地方是不清楚的，理解錯(cuò)誤的可能性不僅是存在的，而且錯(cuò)誤的地方可能還非常多。文章開使我就說了，希望通過我情緒化發(fā)泄的這個(gè)不滿，引導(dǎo)出更多的討論，讓我進(jìn)步學(xué)習(xí)。用INFORMIX導(dǎo)致我非常不爽，而用ORACLE相對(duì)沒有那么多讓我煩惱的問題。而且打INFORMIX技術(shù)支持電話（購買了廠家服務(wù)），很多問題，INFORMIX技術(shù)支持，并不能認(rèn)真的，肯定的回答，這點(diǎn)尤其讓我郁悶�。�！一般都是電話后，他去查，然后電話回來告訴我結(jié)果。而有的時(shí)候，比如HASH分區(qū)，IBM工程師也是說支持的，我看資料上也是說支持的，我問技術(shù)支持是否做過實(shí)驗(yàn)了，他說做過了，可我就是做不出來，我要求他把實(shí)驗(yàn)過程發(fā)給我，他不發(fā)，讓我再做做，我把實(shí)驗(yàn)過程發(fā)給他，過了兩天電話我，才告訴我INFORMIX 9.4不支持，說到這，我不能停止的再次說聲KAO �。。∮羞@么胡弄用戶的嗎，嗎？？？？？？？這部分內(nèi)容，也請(qǐng)樓主實(shí)驗(yàn)以后再回答我，好嗎，謝謝！��！

再次請(qǐng)求原諒我因?yàn)闃侵鞯囊粋€(gè)“素質(zhì)”讓我有機(jī)會(huì)嘮叨這么多廢話！

作者: 大夫 時(shí)間: 2006-01-13 10:34

原帖由 zzjijun 于 2006-1-12 15:47 發(fā)表
工作太忙，時(shí)間沒有，大多潛水。今天看了這貼，就說幾句吧

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順 ...

在此，我再次申明：我不是說ORACLE好，我只是拿ORACLE和INFORMIX做個(gè)比較。
下面列出的是我認(rèn)為ORACLE比INFORMIX要讓我爽的，而一些，比如分區(qū)表在線初始化，我認(rèn)為INFORMIX就比ORACLE做的好，方便我用，但我沒有一一列出來說明。

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順序沒注意，好像每次看了執(zhí)行路徑都大概知道了順序，需要的信息都用了。
不給索引名也沒注意過，作者實(shí)在覺著麻煩也不用罵娘，這類的缺陷隨便那個(gè)軟件都能找出一堆來。
答：
為了這個(gè)問題，今天我再次去認(rèn)真反復(fù)看了一下，承認(rèn)我的錯(cuò)誤，我看懂了他的執(zhí)行計(jì)劃了。顯示方法和表達(dá)方法和ORACLE有點(diǎn)區(qū)別，以前我狗眼混花，沒注意到，例：
INFORMIX：
Estimated Cost: 140 --估計(jì)成本值為140
Estimated # of Rows Returned: 93       ------估計(jì)返回93行
  1) informix.b: SEQUENTIAL SCAN             ----第一步全表掃描表b，通過b.territory_id = 1過濾得到row set。
      Filters: informix.b.territory_id = 1
  2) informix.p: INDEX PATH                   -------第二步通過索引掃描得到表p的row set，使用的索引是包含的有字段ne_id start_time stop_time 的索引（索引名稱未給出），索引過濾條件為p.start_time = 。。。
(1) Index Keys: ne_id start_time stop_time (Serial, fragments: ALL)
      Lower Index Filter: (informix.p.ne_id = informix.b.ne_id AND informix.p.start_time = datetime(2006-01-1
1 14:00:00) year to second )
NESTED LOOP JOIN  ----表示第二步和第一步執(zhí)行nested loop連接，連接條件是p.ne_id =b.ne_id ，（那個(gè)是outer table,那個(gè)是inner table？）

  3) informix.t: AUTOINDEX PATH    -----自動(dòng)索引路徑訪問。
(1) Index Keys: territory_id
      Lower Index Filter: informix.b.territory_id = informix.t.territory_id ---索引過濾
NESTED LOOP JOIN ---------nested loop連接，應(yīng)該是說1）和2）的連接過后形成的row set再和3）進(jìn)行NL連接。
  4) informix.m: INDEX PATH       ------索引訪問。
(1) Index Keys: ne_id (Key-Only)  (Serial, fragments: ALL) ----索引字段說明。
      Lower Index Filter: informix.m.ne_id = informix.b.related_msc    過濾條件，連接條件
NESTED LOOP JOIN --------連接方式。

感謝樓主，沒有你的批評(píng)，我還不知道我到什么時(shí)候才會(huì)看到這個(gè)內(nèi)容。
個(gè)人覺得不好的地方：
1，索引名稱未給出，也無所謂。
2，只給出了總的COST和返回行估計(jì)，沒有給出具體每個(gè)步驟的COST和返回行估計(jì)。這關(guān)系到如果多表連接，我能否快速發(fā)現(xiàn)是SQL的那一步執(zhí)行的性能問題。ORACLE的分析方法此處略過。
3，執(zhí)行時(shí)間統(tǒng)計(jì)，樓主有什么好方法記錄每次SQL的執(zhí)行時(shí)間？如同sqlplus 的set timing on功能一樣。當(dāng)前我是寫了個(gè)執(zhí)行SHELL，在里面每次查詢數(shù)據(jù)庫當(dāng)前時(shí)間輸出，法子很笨，請(qǐng)給予指導(dǎo)。
4，沒有找到原始執(zhí)行過程的跟蹤文件，我們知道，一個(gè)SQL語句執(zhí)行慢，可能是因?yàn)楹芏嘣蛑瞥傻模绻鸌NFORMIX提供一份如ORACLE的udump的trace的原始文件，讓我們連接這個(gè)SQL從發(fā)布到執(zhí)行結(jié)束都做了些什么，在查找性能問題的時(shí)候，幫助更大一點(diǎn)。這方面，ORACLE提供的方法很多，分析內(nèi)容也很豐富。

2. Extend有限制有什么新鮮的，現(xiàn)代計(jì)算機(jī)最基本的CPU,memory,I/O都有限制，作者說個(gè)Oracle沒限制的東西給我看看？
Extend問題如果沒有經(jīng)驗(yàn)是會(huì)遇到，如果經(jīng)過培訓(xùn)，學(xué)習(xí)應(yīng)該可以掌握吧。
答：其他的先不說，就ORACLE的extend來說，目前可以認(rèn)為是沒有限制的，我們認(rèn)為的沒有限制，是一種相對(duì)概念，比如ORACLE的SCN，可以認(rèn)為幾百萬年都不會(huì)重復(fù)一樣（幾百萬年后，都不知道是否還有ORACLE這個(gè)名字，你也知道不會(huì)計(jì)較幾百萬年后他是否重復(fù)了吧），不是死專牛角尖。（在此，借這個(gè)機(jī)會(huì)，能否問一下，樓主使用ORACLE的經(jīng)驗(yàn)有多少？使用INFORMIX的經(jīng)驗(yàn)有多少？），不象INFORMIX一樣，對(duì)extend有限，固定數(shù)量。我曾經(jīng)遇到過好幾次因?yàn)镮NFORMIX的extend數(shù)滿了，無法插入數(shù)據(jù)，只能把表導(dǎo)出來，重新創(chuàng)建大的extend再導(dǎo)進(jìn)去，第一次遇到這個(gè)問題的時(shí)候，我也覺得很新鮮。你也知道，大表操作是很煩人的事，所以我才那么不滿了，只是不知道樓主是否曾經(jīng)管理過大數(shù)據(jù)庫的大表？？？

3. 系統(tǒng)監(jiān)控Informix本身提供的工具并不多，這和Oracle的策略不同。
Oracle本身養(yǎng)了很多研究人員來開發(fā)基于Oracle的工具。而IBM對(duì)DB2,Informix來說只開發(fā)數(shù)據(jù)庫本身的產(chǎn)品，其他工具軟件是交給了第三方的軟件開發(fā)商來做。
比如server studio JE5.1，我還見過一家臺(tái)灣公司做的Informix監(jiān)控管理軟件。都是基于Informix開放的API函數(shù)和系統(tǒng)表來做的。
答：恩，那天聽一位高人說了，說ORACLE和INFORMIX的策略不同，大概是說，ORACLE是以資源換性能，INFORMIX不是。這個(gè)話目前我還沒有認(rèn)真消化完，所以不好說。畢竟如果這是真的，那么多人的腦袋想出來的法子，我相信比我的強(qiáng)，我會(huì)去尋找差別。
至于說“Oracle本身養(yǎng)了很多研究人員來開發(fā)基于Oracle的工具”，我不知道是否真的，我最喜歡的ORACLE的性能工具STATSPACK，目前也還有很多我不滿意的功能，他們的工程師修正的好象也慢了一點(diǎn)。但類似的這種工具，INFORMIX都沒有。ORACLE的工具，不管是誰開發(fā)的，請(qǐng)樓主做個(gè)調(diào)查，是ORACLE的多，還是INFORMIX的多，我就不說了。再次說，DB2我不僅沒用過，見都沒見過。QUEST的性能工具我也見過，但只見過ORACLE的，沒見過INFORMIX的，至于說到server studio JE5.1，以前一直不知道有這個(gè)工具，后來電話INFORMIX技術(shù)支持，他被逼的沒招了，第三天吧，好象是，給我打了個(gè)電話，說他們工程師用這個(gè)工具，他本人沒有用過。我找了幾個(gè)網(wǎng)友，下載來研究了一下。目前還沒用熟，沒有感覺到多好，慢慢挖掘中，暫時(shí)還是不評(píng)論了。

4. 從來沒覺得Informix的系統(tǒng)表少些什么內(nèi)容，但有些系統(tǒng)表是undocument，就是不希望用戶訪問的。
答：
從沒覺得SMI少了點(diǎn)什么，那請(qǐng)樓主幫我查查一個(gè)用戶從連接開始，不說連接開始了，當(dāng)前會(huì)話執(zhí)行過的10個(gè)SQL語句出來？請(qǐng)教一下，如何查？如果SMI查不出來，那么請(qǐng)樓主用ONSTAT教我查也好，謝謝！如果查不出來，下次就不要這么說啦，我只是說我不滿，在尋求幫助，還沒如樓主一樣容易滿足了。
不知道樓主是否給系統(tǒng)做過綜合性能分析，在一個(gè)大型OLTP里，由于國內(nèi)的軟件開發(fā)上線，在上線前各模塊是沒有經(jīng)過認(rèn)真測(cè)試的，或者對(duì)SQL性能就是沒有測(cè)試的，每小時(shí)生成的SQL大概超過1G內(nèi)存大小，此時(shí)，請(qǐng)問如果不查詢這些，如何知道那些SQL是消耗資源最大的，或很大的呢？所以，我才喜歡ORACLE的STATSPACK，它提供趨勢(shì)分析！�。�

作者: 大夫 時(shí)間: 2006-01-13 10:35

原帖由 zzjijun 于 2006-1-12 15:47 發(fā)表
工作太忙，時(shí)間沒有，大多潛水。今天看了這貼，就說幾句吧

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順 ...

5,分區(qū)支持
Informix的hash分區(qū)偶用過。
答：請(qǐng)問樓主是在什么版本用的？我的IDS 9.4測(cè)試失敗，INFORMIX技術(shù)支持最后也被迫回答不支持，請(qǐng)樓主把9.4版的實(shí)驗(yàn)情況帖出來一下，讓我學(xué)習(xí)學(xué)習(xí)，十分感謝！

6,9.3和9.4的區(qū)別
版本的升級(jí)，憑什么要規(guī)定人家變化什么，不變化什么。9.3升級(jí)到9.4很容易呀。
答：確實(shí)，我無權(quán)規(guī)定他變化什么不變化什么，我只是表達(dá)他變化大了對(duì)我工作的影響，對(duì)我影響很大，如果變化不是那么徹底，影響就小了。
1，我曾經(jīng)寫過一個(gè)軟件dbmonitor，可自適應(yīng)監(jiān)控ORACLE，INFORMIX，SYBASE的一些如內(nèi)存，存儲(chǔ)，對(duì)象，會(huì)話，日志等內(nèi)容的一個(gè)工具。當(dāng)時(shí)做完了IDS 9.4版，做9.3版的時(shí)候，才發(fā)現(xiàn)很多系統(tǒng)表名都變了，到現(xiàn)在我也沒找到說明資料（或許有，是我沒翻到，但現(xiàn)在已失去了再升級(jí)DBMonitor的興趣）。
2，樓主說了，從9.3升級(jí)到9.4很容易，能否發(fā)個(gè)方案來看看？這個(gè)問題，后來提交給我們系統(tǒng)集成事業(yè)部討論，結(jié)論是目前不適合做升級(jí)，到現(xiàn)在我們也沒做成。環(huán)境：一個(gè)SUN，一個(gè)HP，表實(shí)際數(shù)據(jù)量大概300G左右，chunk使用裸設(shè)備。系統(tǒng)離線時(shí)間不能太長。謝謝。

7,系統(tǒng)工具難使用
這恰恰是我覺得Informix的一個(gè)優(yōu)點(diǎn), 一個(gè)onstat就搞定很多事，要查的東西差不多都有了。
有時(shí)是要寫些sql, shell來完成復(fù)雜的管理任務(wù)，不過那個(gè)資深的DBA沒寫過sql,shell呢？
答：
1，我不是資深DBA，我還是數(shù)據(jù)庫大海里游蕩的一個(gè)初級(jí)選手，所以不知道是否有資格和樓主討論這個(gè)話題，呵呵，樓主是“資深DBA”？景仰一下先。
2，就說寫SQL，SHELL來完成吧，就目前google搜索下來，還是ORACLE多，INFORMIX少，而且提供的INFORMIX腳本，轉(zhuǎn)來轉(zhuǎn)去，就是那么幾個(gè)。如果樓主有套全的，不妨貢獻(xiàn)給大家，人民感謝你？呵呵。
onstat ，只是計(jì)算輸出了當(dāng)前的值，請(qǐng)注意，是當(dāng)前，所以無法提供趨勢(shì)分析。既然樓主是“資深DBA”，那也應(yīng)該知道趨勢(shì)分析的重要了吧，要把問題扼殺在搖籃中啊。。。。那只能把當(dāng)前onstat的數(shù)據(jù)入庫？唉，我再說一次KAO，這樣是不是會(huì)增加很多資源消費(fèi)呢？曾經(jīng)見過，比如onperf，可以提供采集點(diǎn)，畫出圖形來表示資源的使用曲線，但這得一直開著這個(gè)窗口，這樣符合例行維護(hù)的工作需要嗎？我覺得好象不是很符合的吧。
還是說我的理解就是錯(cuò)誤的了，請(qǐng)樓主給于指導(dǎo)，我希望我在這方面對(duì)INFORMIX的認(rèn)識(shí)，能通過這次討論，有所突破，謝謝。

8,內(nèi)存分配,參數(shù)初始化設(shè)置
我見過很多大型應(yīng)用用的都挺好的呀。會(huì)不會(huì)用不等于好不好用。
答：
“會(huì)不會(huì)用不等于好不好用”，這句話我完全同意！“我見過很多大型應(yīng)用用的都挺好的呀”，呵呵，樓主可能見過真正的牛人做過的系統(tǒng)吧，我沒見識(shí)過，向往中啊。。。
我們?cè)谧鰞?nèi)存分配分析的時(shí)候，ORACLE在大體的幾個(gè)方面進(jìn)行初始設(shè)置后，一般都能取得不錯(cuò)的性能效果，剩下的我定義為微調(diào)整了。而INFORMIX，真的很難搞，你比如一個(gè)SQL緩沖區(qū)，就要配置好幾個(gè)參數(shù)，而同時(shí)還有統(tǒng)計(jì)數(shù)據(jù)緩沖區(qū)，數(shù)據(jù)字典緩沖區(qū)等等虛擬內(nèi)存部分。我的其中一個(gè)疑惑請(qǐng)參考本版《Informix 內(nèi)存討論之一: SQL語句高速緩存》 http://72891.cn/viewthr ... &extra=page%3D1
請(qǐng)樓主進(jìn)去對(duì)我的疑惑，指導(dǎo)一下，萬分感謝！

真的，我測(cè)試的時(shí)候就把我弄暈了，感覺一環(huán)扣一環(huán)的，因?yàn)闆]有幫定變量，現(xiàn)在我的hits設(shè)置為70，ssc都已經(jīng)超過900M了。感覺這樣，反過來，不如按原始配置，不起用SQL緩沖，但這樣又想著每次都要hard parse，效率差，唉，矛盾啊。綁定變量的問題，下面再說。

9,動(dòng)態(tài)SQL
支持！
答：我原來說的話有問題，當(dāng)時(shí)一沖動(dòng)，直接就說了“一個(gè)字：不支持�！�，我本意是這樣的，INFORMIX提供在接口程序里使用宿主變量的方式提供綁定，這是提供的。但比如在procedure里（我們絕大部分中間計(jì)算都是通過procedure來完成的，7*24小時(shí)每小時(shí)都有大批數(shù)據(jù)要計(jì)算），ORACLE就提供了如execute immediate的動(dòng)態(tài)接口，但I(xiàn)NFORMIX里，他沒有！�。�
這會(huì)導(dǎo)致什么問題呢？舉例給樓主：
1，我們做程序開發(fā)，都是提供一個(gè)接口程序給程序員，程序員把寫好的SQL直接發(fā)給接口程序輸出執(zhí)行，接口程序他們只需要編譯進(jìn)去就好了。這樣程序員寫的程序，就不好使用宿主變量的方式提供綁定了！
2，在procedure里，比如我有很多個(gè)地市，比如山西省，有10多個(gè)地市，我們就幾張表，是按地市進(jìn)行分表數(shù)據(jù)存儲(chǔ)的，但匯總上來的時(shí)候，計(jì)算方法是完全一樣的。這就有一個(gè)問題了：
僅僅是因?yàn)楸砻暮缶Y不一樣，我就不得不每個(gè)地市寫一個(gè)procedure。（我們很多這種procedure，這樣一來，procedure的數(shù)量就很大很大了，不知道樓主是否遇到過），而ORACLE指定動(dòng)態(tài)SQL，哈哈，很好，遇到這種情況，就用動(dòng)態(tài)SQL，把地市組合起來就好了，所以O(shè)RACLE一類就一個(gè)procedure，而INFORMIX就得很多過，即使我通過方法改進(jìn)，提前進(jìn)行數(shù)據(jù)預(yù)處理，那也需要3個(gè)procedure才能處理完！
3，procedure每小時(shí)，每網(wǎng)元重復(fù)計(jì)算，執(zhí)行的頻率很高，如果不提供SQL緩存，不使用綁定變量，每次都要hard parse，很浪費(fèi)資源。

不知道樓主遇到這種問題的時(shí)候，是怎么解決的，也請(qǐng)指導(dǎo)一下，這部分內(nèi)容對(duì)我來說很重要。

10,在線交互工具
dbaccess也還可以呀，偶一開始用sqlplus的時(shí)候也不習(xí)慣呢。
答：恩，剛開始用工具的時(shí)候，都不習(xí)慣，但兩種工具都要經(jīng)常用的時(shí)候，你發(fā)覺一個(gè)可以提供好多方便，靈活，豐富的功能，而另外一個(gè)死活沒有的時(shí)候，你就知道不爽了�？磥順侵魅鄙偈褂胹qlplus的豐富經(jīng)驗(yàn)。

在此，推薦研究一下，呵呵。

啊，總算又請(qǐng)樓主賜教的內(nèi)容寫了一遍，誠懇的請(qǐng)樓主指導(dǎo)。

作者: 大夫 時(shí)間: 2006-01-13 10:39

原帖由 zzjijun 于 2006-1-12 15:47 發(fā)表
工作太忙，時(shí)間沒有，大多潛水。今天看了這貼，就說幾句吧

1, 現(xiàn)在商業(yè)的關(guān)系型數(shù)據(jù)庫查詢優(yōu)化器大多是基于成本的，需要的是執(zhí)行路徑，cost，預(yù)計(jì)返回的行數(shù)。
我一直用Informix都覺著蠻好用的。
說到執(zhí)行順 ...

剛看到這一段：
“
要比數(shù)據(jù)庫，可以從
系統(tǒng)架構(gòu)
性能
安全性
可擴(kuò)展性
可用性
易管理性
等等方面去比。作者有空給點(diǎn)建議。
”

回復(fù)：
恩，很認(rèn)同你的觀點(diǎn)，全方便比較數(shù)據(jù)庫，但我不是要做數(shù)據(jù)庫比較，測(cè)評(píng)，專門有組織這樣做的。我只是在工作中應(yīng)用的時(shí)候，在我用的到的部分進(jìn)行比較，僅僅比較的是因?yàn)閿?shù)據(jù)庫的差異，給我的工作帶來的麻煩和便利。如果你非要說，那我再回答一次，如果給我選擇，我希望公司，客戶選擇國產(chǎn)數(shù)據(jù)庫，比如夢(mèng)龍的，我想我雖然會(huì)罵，但絕對(duì)會(huì)認(rèn)真的對(duì)他進(jìn)行測(cè)試，總結(jié)提出自己的建議。

作者: 大夫 時(shí)間: 2006-01-13 10:43
批判一下自己，剛給樓主發(fā)站內(nèi)信請(qǐng)求過來指導(dǎo)的時(shí)候，發(fā)現(xiàn)樓主是女孩，確實(shí)聽到KAO，TMD等可能很不習(xí)慣，或許是我錯(cuò)了。因我確實(shí)見過一次TMD等Z話都沒說過的女孩（至少在我面前）。下面，只請(qǐng)樓主指導(dǎo)吧。

作者: 大夫 時(shí)間: 2006-01-13 10:48

原帖由 ibm_informix 于 2006-1-12 15:14 發(fā)表
一個(gè)項(xiàng)目選什么數(shù)據(jù)庫,不是工程師說了算,集成商要看賣那個(gè)軟件能給他帶來最大的利潤,那可是另外的一個(gè)領(lǐng)域.好好學(xué)習(xí)吧，工程師，你的路還遠(yuǎn)呢。。。

我也嚴(yán)重同意，我們就是系統(tǒng)集成商，但我們以軟件生產(chǎn)為主。所以一些第三方軟件，我們都是建議用戶買，由用戶決定買那個(gè)廠家的。一般都是用戶在做項(xiàng)目的時(shí)候，做預(yù)算，就根據(jù)不同的預(yù)算我們做選擇，報(bào)價(jià)了。所以買什么，用什么，我控制不了，我發(fā)這個(gè)帖子的意圖，1是發(fā)發(fā)牢騷，2是這些牢騷都是嚴(yán)重影響我工作了的，希望同時(shí)得到其他牛的人幫助。如果INFORMIX真的不支持，那就當(dāng)笑話看了。

作者: wzg2006sh 時(shí)間: 2006-01-13 15:08
各位朋友幫幫忙，我的環(huán)境是win2000+informix9.3
我的查詢結(jié)果中文顯示問亂碼，我環(huán)境變量也設(shè)置過了，
幫幫忙吧

作者: zzjijun 時(shí)間: 2006-01-13 15:11
呵呵，沒想到討論會(huì)這么火暴。
還是先說說粗口的事吧。生活里怎么說無所謂，那是你身邊家人朋友的事。
在一個(gè)社會(huì)環(huán)境里是有禮儀，道德要遵循的吧。
敢問作者你在公司和上級(jí)會(huì)這么說話嗎？和客戶會(huì)這么說話嗎？和廠商的人會(huì)這么說話嗎？
這和偽君子無關(guān)，關(guān)系到在職業(yè)生涯里面，你是否professional。
我覺得在這個(gè)論壇大家都應(yīng)該相互尊重，友好討論，你連最起碼的人際關(guān)系都建立不起來怎么和別人探討呢。
這個(gè)尊重不僅僅對(duì)個(gè)人而言，對(duì)一家公司，對(duì)一個(gè)軟件產(chǎn)品同樣需要。
開發(fā)一個(gè)成熟的軟件產(chǎn)品需要多少人的心血和努力呀，存在的東西一定會(huì)有他存在的理由。
這個(gè)世界人比人傻多少，你發(fā)現(xiàn)的問題，難道別人就沒發(fā)現(xiàn)嗎？為什么不平心靜氣去搜尋一下答案呢。

一個(gè)軟件產(chǎn)品的發(fā)展策略，系統(tǒng)架構(gòu)，功能模塊不是一兩個(gè)人能決定的。非要死恰有什么意思的。
要死恰誰不會(huì)呀，Oracle的TPC-C怎么不是第一呀，SAP測(cè)試怎么不是第一呀，好容易弄個(gè)TPC-H第一，怎么還比別人多用8個(gè)CPU呀。
要死恰Oracle RAC的share disk架構(gòu)可以說出一堆毛病。
(呵呵，作者不用一一答復(fù)我，僅僅是舉個(gè)死恰例子－－就是有些事是有道理的我也說沒道理)
你可以說你不care數(shù)據(jù)庫的性能，架構(gòu)，可用性等等，你就是說用著這個(gè)功能那個(gè)功能怎么怎么不爽，這樣的挑沒有哪個(gè)東西在所有人的眼里是完美的。
呵呵，就象我說sqlplus我用了一下就是不爽。然后你跟我說你沒用多久吧，我用的挺好的。我說我就是用的不爽，它為什么不和我以前用的dbaccess一樣呢，我為什么要適應(yīng)它呢。這樣有盡頭嗎？

對(duì)于Informix IBM現(xiàn)在的策略本來就不是重點(diǎn)。(呵呵，偶們還是對(duì)Informix挺有感情的。)
你在這罵娘，人家廠商都不care有什么意思呢。
Oracle除了數(shù)據(jù)庫的開發(fā)人員外，還有上千人的團(tuán)隊(duì)開發(fā)輔助工具。而IBM的DB2, Informix都沒有，所以在<DB2雜志>里可以看到有很多第三方軟件的廣告。
這部分產(chǎn)品是有市場(chǎng)的，只是IBM自己不做罷了。
好比甲買床給你，但不買床單。乙兩者都買。你非要拿乙的床單去和甲去比有意思嗎？甲就是執(zhí)行不做，也不買的策略。

問的技術(shù)問題有些可以在以前的帖子里搜一下，找不到的可以就事論事的提出來大家討論。
這里是個(gè)開放的環(huán)境，大家都可以發(fā)言，大家也都可以不發(fā)言。
也許有的情況別人也沒遇到過，也許別人知道卻沒有時(shí)間，或者沒有精力，或者沒有興趣去回復(fù)你。
你可以要求別人來證明什么什么，回答什么什么�？墒侨绻氵B最起碼的誠懇態(tài)度都沒有，別人憑什么care你呀。
畢竟這里不是一個(gè)簽了合同付了費(fèi)用就要執(zhí)行合約的商業(yè)機(jī)構(gòu)。

如果你的公司買了廠商的產(chǎn)品，覺得不爽可以罵廠商的人呀。你們是甲方呀。
你們不是買服務(wù)了嗎？廠商的解決方法就是權(quán)威呀。
換一個(gè)場(chǎng)景，作者可以把原文對(duì)800的工程師說一遍，您覺著合適嗎，您覺著他們會(huì)怎樣答復(fù)您。
其實(shí)廠商的工程師也只是做產(chǎn)品技術(shù)支持的呀，他們也是普通打工一族呀，走在街上他們和你我一樣都是社會(huì)公民呀。
您的客戶這樣的態(tài)度，就和您這樣的死恰你感覺會(huì)怎么樣呢。

作者: zzjijun 時(shí)間: 2006-01-13 15:22
BTW:
IBM Tivoli Monitoring (ITM) 6.1也是可以監(jiān)控database的，不過具體功能不是很了解。
也許IBM也作監(jiān)控工具，只是不叫Informix罷了。

唉，這個(gè)世界是變化的，多樣的，發(fā)生什么都不奇怪。

作者: 大夫 時(shí)間: 2006-01-13 17:10

原帖由 zzjijun 于 2006-1-13 15:11 發(fā)表
呵呵，沒想到討論會(huì)這么火暴。
還是先說說粗口的事吧。生活里怎么說無所謂，那是你身邊家人朋友的事。
在一個(gè)社會(huì)環(huán)境里是有禮儀，道德要遵循的吧。
敢問作者你在公司和上級(jí)會(huì)這么說話嗎？和客戶會(huì)這么說話嗎？ ...

呵呵，沒想到討論會(huì)這么火暴。
還是先說說粗口的事吧。生活里怎么說無所謂，那是你身邊家人朋友的事。
在一個(gè)社會(huì)環(huán)境里是有禮儀，道德要遵循的吧。
敢問作者你在公司和上級(jí)會(huì)這么說話嗎？和客戶會(huì)這么說話嗎？和廠商的人會(huì)這么說話嗎？
這和偽君子無關(guān)，關(guān)系到在職業(yè)生涯里面，你是否professional。
我覺得在這個(gè)論壇大家都應(yīng)該相互尊重，友好討論，你連最起碼的人際關(guān)系都建立不起來怎么和別人探討呢。
這個(gè)尊重不僅僅對(duì)個(gè)人而言，對(duì)一家公司，對(duì)一個(gè)軟件產(chǎn)品同樣需要。
開發(fā)一個(gè)成熟的軟件產(chǎn)品需要多少人的心血和努力呀，存在的東西一定會(huì)有他存在的理由。
這個(gè)世界人比人傻多少，你發(fā)現(xiàn)的問題，難道別人就沒發(fā)現(xiàn)嗎？為什么不平心靜氣去搜尋一下答案呢。

-------------------------------
-------------------------------
-------------------------------
1，在公司和上級(jí)我會(huì)說CAO，TMD，KAO，和熟悉的客戶我也會(huì)這么說，不熟悉的客戶就防備著，完全無感情的工作語言。和廠商是憋著不說，激動(dòng)的時(shí)候依然會(huì)說。在我接觸的客戶中，所KAO的客戶比不說KAO的客戶更好相處一點(diǎn)，更容易溝通一點(diǎn)�？赡苁俏覀兌歼€沒到你的修養(yǎng)吧。
2，professional，你說的對(duì)，粗口不夠professional，但我依然會(huì)繼續(xù)。因?yàn)槲乙呀?jīng)在前面說過了，我沒有素質(zhì)（我曾經(jīng)問過我的同學(xué)和認(rèn)識(shí)的朋友，他們有素質(zhì)嗎，他們回答說，看場(chǎng)景，看對(duì)象）。
3，在壇子里“相互尊重，友好討論”，我嚴(yán)重同意。我寫1樓文的時(shí)候，是激動(dòng)下一口氣寫完的，當(dāng)時(shí)是一種發(fā)泄，沒有注意措辭，承認(rèn)是個(gè)錯(cuò)誤。不應(yīng)該出現(xiàn)TMD，CAO，KAO等詞語。
4，我發(fā)現(xiàn)的問題，就我列出的幾點(diǎn)，都是對(duì)我工作影響特別大的，所以才特別不滿，他們折磨了我無數(shù)個(gè)日夜。我已經(jīng)搜索過很多了，找一些人討論過了，以及尋求INFORMIX技術(shù)支持，得不到答案，才在此發(fā)泄，并尋求能幫助我的人幫助。

一個(gè)軟件產(chǎn)品的發(fā)展策略，系統(tǒng)架構(gòu)，功能模塊不是一兩個(gè)人能決定的。非要死恰有什么意思的。
要死恰誰不會(huì)呀，Oracle的TPC-C怎么不是第一呀，SAP測(cè)試怎么不是第一呀，好容易弄個(gè)TPC-H第一，怎么還比別人多用8個(gè)CPU呀。
要死恰Oracle RAC的share disk架構(gòu)可以說出一堆毛病。
(呵呵，作者不用一一答復(fù)我，僅僅是舉個(gè)死恰例子－－就是有些事是有道理的我也說沒道理)
你可以說你不care數(shù)據(jù)庫的性能，架構(gòu)，可用性等等，你就是說用著這個(gè)功能那個(gè)功能怎么怎么不爽，這樣的挑沒有哪個(gè)東西在所有人的眼里是完美的。
呵呵，就象我說sqlplus我用了一下就是不爽。然后你跟我說你沒用多久吧，我用的挺好的。我說我就是用的不爽，它為什么不和我以前用的dbaccess一樣呢，我為什么要適應(yīng)它呢。這樣有盡頭嗎？

-------------------------------
-------------------------------
-------------------------------
你說的對(duì)，不用對(duì)所有的問題死恰，但我工作中的應(yīng)用，屬于影響我工作的，因?yàn)樗恢С�，他們折磨了我無數(shù)個(gè)日夜。不知道你認(rèn)真看我開篇說的沒有，我無心對(duì)他所有的功能進(jìn)行比較，我所說的，都只是我急切需要用到的。我想用著不舒服了，總可以嘮叨幾句吧，只是我不小心嘮叨到CU來了。至于你說的，ORACLE和INFORMIX等數(shù)據(jù)庫的TPC-C等的比較，那不關(guān)我的事，我只因我所要用到的內(nèi)容，這方面ORACLE讓我省了很多很多事，所以我滿意他，同樣，我也說過，INFORMIX也有我感覺比ORACLE好用的東西一樣。我所說的基礎(chǔ)，是對(duì)我工作急用的，常用的，影響比較大的內(nèi)容。請(qǐng)注意討論的范圍。

對(duì)于Informix IBM現(xiàn)在的策略本來就不是重點(diǎn)。(呵呵，偶們還是對(duì)Informix挺有感情的。)
你在這罵娘，人家廠商都不care有什么意思呢。
Oracle除了數(shù)據(jù)庫的開發(fā)人員外，還有上千人的團(tuán)隊(duì)開發(fā)輔助工具。而IBM的DB2, Informix都沒有，所以在<DB2雜志>里可以看到有很多第三方軟件的廣告。
這部分產(chǎn)品是有市場(chǎng)的，只是IBM自己不做罷了。
好比甲買床給你，但不買床單。乙兩者都買。你非要拿乙的床單去和甲去比有意思嗎？甲就是執(zhí)行不做，也不買的策略。

-------------------------------
-------------------------------
-------------------------------
1，我不是故意要罵，已經(jīng)說過了，是一種宣泄，已經(jīng)承認(rèn)說粗口是一種錯(cuò)誤，但我依然不會(huì)否認(rèn)我會(huì)說，我說過，我說的內(nèi)容，沒有說要廠商關(guān)心。
2，我對(duì)INFORMIX，ORACLE，SYBASE等，完全沒有感情。雖然被他們折磨過無數(shù)日日夜夜，但我依然不會(huì)對(duì)他們有感情，有的只是一想到被折磨的日子就不會(huì)想再來一次！
3，你說的雜志什么的，實(shí)話是我確實(shí)不知道這個(gè)雜志，接受的信息也不夠，你說的內(nèi)容我不知道真假，沒辦法和你討論。
4，誰開發(fā)我不需要關(guān)心，我只關(guān)心通常被使用的，在google上能被很好查出來的（為什么要很容易查？那只是因?yàn)槲也粔驅(qū)I(yè)，我相信用的多的，肯定有他存在的價(jià)值）。這方面，確實(shí)ORACLE的相關(guān)產(chǎn)品比較多，和INFORMIX比起來，確實(shí)多很多，這個(gè)我不再和你爭(zhēng)論，因我不知道你對(duì)ORACLE的熟練程度。

問的技術(shù)問題有些可以在以前的帖子里搜一下，找不到的可以就事論事的提出來大家討論。
這里是個(gè)開放的環(huán)境，大家都可以發(fā)言，大家也都可以不發(fā)言。
也許有的情況別人也沒遇到過，也許別人知道卻沒有時(shí)間，或者沒有精力，或者沒有興趣去回復(fù)你。
你可以要求別人來證明什么什么，回答什么什么。可是如果你連最起碼的誠懇態(tài)度都沒有，別人憑什么care你呀。
畢竟這里不是一個(gè)簽了合同付了費(fèi)用就要執(zhí)行合約的商業(yè)機(jī)構(gòu)。

-------------------------------
-------------------------------
-------------------------------
1，我搜了，找不到，我就事論事的提出來了，只是家了我個(gè)人感情在里面，在此，再次對(duì)污染了環(huán)境，影響了你純凈的環(huán)境道歉，我粗人一個(gè)，望不要計(jì)較，如果你看不慣，請(qǐng)忍一下，以后我會(huì)盡量避免在CU用到那些粗口的詞匯，如果還能忍，請(qǐng)你饒道，當(dāng)我在放P好了，謝謝。
2，大家是可以發(fā)言，也可以不發(fā)言，所以，你看不慣的時(shí)候，你可以不發(fā)言，忍不住的時(shí)候，以你的文明，以你的素質(zhì)，應(yīng)該只簡單和我說一下，比如“樓主，你說粗口，臟話，懶的理里”或“拒絕與不文明人溝通”什么的，我想我就知道我錯(cuò)在什么地方了。
3，沒有要證明什么，再說一次，發(fā)帖1是發(fā)泄，2是就針對(duì)我遇到的麻煩，看是否運(yùn)氣好，能遇到幫助我解決的朋友，就目前來說，我提的技術(shù)問題，你好象沒有正面回答，不過算啦，目前我的INFORMIX方面的工作做的差不多了。
4，不是商業(yè)機(jī)構(gòu)，你可以不甩我的嘛，沒有求你來和我爭(zhēng)啊，對(duì)不對(duì)嘛。

如果你的公司買了廠商的產(chǎn)品，覺得不爽可以罵廠商的人呀。你們是甲方呀。
你們不是買服務(wù)了嗎？廠商的解決方法就是權(quán)威呀。

-------------------------------
-------------------------------
-------------------------------
對(duì)啊，已經(jīng)罵過了，表示過不滿了。他們的解決就是權(quán)威啊，是啊，他們說不行啊，我已經(jīng)說過了，再請(qǐng)你認(rèn)真看一次我發(fā)過的文字，他們胡弄把我觸怒了。

換一個(gè)場(chǎng)景，作者可以把原文對(duì)800的工程師說一遍，您覺著合適嗎，您覺著他們會(huì)怎樣答復(fù)您。
其實(shí)廠商的工程師也只是做產(chǎn)品技術(shù)支持的呀，他們也是普通打工一族呀，走在街上他們和你我一樣都是社會(huì)公民呀。

-------------------------------
-------------------------------
-------------------------------
我也被我的用戶罵過，而且不止一次，但是我的錯(cuò)，或是我公司的錯(cuò)，所以我閉著嘴等他罵完，等他心情好點(diǎn)，繼續(xù)和他溝通。因?yàn)槲夷昧斯窘o我發(fā)的工資，我有義務(wù)為公司工作，為公司承擔(dān)一部分責(zé)任。
和IBM工程師他們溝通的時(shí)候，接觸過好幾個(gè)工程師，他打工，我也打工，他們態(tài)度好，回答問題認(rèn)真的時(shí)候，不管是產(chǎn)品的問題或是他不清楚，或測(cè)試錯(cuò)誤，我從沒有對(duì)他們說過重的話，更不用說對(duì)他們說粗口了。但有一些工程師，就是不認(rèn)真對(duì)你，總想胡弄你，早點(diǎn)結(jié)束這個(gè)case，不罵他那就是我犯賤了�。�！ORACLE的態(tài)度就很好，一個(gè)問題，他會(huì)認(rèn)真的幫你分析，還會(huì)電話尋訪問題解決進(jìn)度，現(xiàn)在轉(zhuǎn)到臺(tái)灣去做支持，態(tài)度更好，工作更認(rèn)真，雖然有些口音聽不大懂，雖然問題總是要你在metalink上提case。

您的客戶這樣的態(tài)度，就和您這樣的死恰你感覺會(huì)怎么樣呢。
-------------------------------
-------------------------------
-------------------------------
我的客戶，他是上帝！我在公司工作一天，他就是一天我的上帝！所有的不滿，我都會(huì)閉嘴。我感覺很委屈，很冤枉的時(shí)候，實(shí)在忍不住的時(shí)候，我不會(huì)對(duì)客戶發(fā)火，我只對(duì)我的頭發(fā)火，事情就完了！這就是我的方式。

最后，說一下
樓主，我不會(huì)再回來繼續(xù)和你爭(zhēng)論處理事情的方法啦，粗口問題啦什么的，除非你討論的是技術(shù)問題，因你的技術(shù)回答，沒解決問題。
因我已經(jīng)說過了，我不是一個(gè)如你一樣有素質(zhì)的人，大家性格不合，我不會(huì)要求你接受我的態(tài)度的，我的態(tài)度對(duì)別人產(chǎn)生了影響，我也會(huì)認(rèn)真的接受批評(píng)，承認(rèn)錯(cuò)誤。所以，這里，我對(duì)我的粗口認(rèn)真的和你道歉啦。
但我一直疑惑的是，怎么你那么有素質(zhì)的人，怎么也那么容易沖動(dòng)呢，呵呵。。。我閃啦，除非是技術(shù)溝通，不然你把我打下18層地獄，俺也不回來了。。。

BTW
我不會(huì)娶你，你肯定打死也不會(huì)嫁我這種流氓。所以啦，不要太在意我的性格：）只要抓住我們本來要討論的根本問題“技術(shù)”就好了，我唐僧慣了，你可別學(xué)我唐僧啊，影響淑女形象的說。。。我撤了。

作者: pbj968 時(shí)間: 2006-01-15 10:47
其實(shí)個(gè)人認(rèn)為Informix是很優(yōu)秀的，但還有一個(gè)事實(shí)是IBM已并不重視它了

作者: 大夢(mèng) 時(shí)間: 2006-01-15 13:09

原帖由 ibm_informix 于 2006-1-12 15:14 發(fā)表
一個(gè)項(xiàng)目選什么數(shù)據(jù)庫,不是工程師說了算,集成商要看賣那個(gè)軟件能給他帶來最大的利潤,那可是另外的一個(gè)領(lǐng)域.好好學(xué)習(xí)吧，工程師，你的路還遠(yuǎn)呢。。。

就是標(biāo)題火藥味太濃，討論可以繼續(xù)，先頂上去幾天。

[ 本帖最后由大夢(mèng) 于 2006-1-15 13:11 編輯 ]

作者: imkdk 時(shí)間: 2006-01-16 14:30
標(biāo)題: 不支持動(dòng)態(tài)SQL???
很佩服LZ的鉆研精神，但是INFORMIX的SQL引擎的確是支持動(dòng)態(tài)SQL的。動(dòng)態(tài)SQL的語句不僅在ESQL/C中使用EXECUTE IMMEDIATE得到體現(xiàn)，也在4GL或者SPL中使用PREPARE ... FROM ... EXECUTE ...USING等SQL語句中得到體現(xiàn)，LZ可以再研究一下。
BTW: INFORMIX IDS 早在5版(早于1998年)開始支持原始磁盤數(shù)據(jù)文件管理（RAW DISK），而最近研究ORACLE9I，發(fā)現(xiàn)居然不支持（只支持操作系統(tǒng)數(shù)據(jù)文件，這在INFORMIX中被稱為COOKIED FILE），現(xiàn)在的ORACLE 10G，終于支持了原始磁盤空間管理，但是居然是打著ORACLE 10G的一項(xiàng)重要技術(shù)革新的旗號(hào)高調(diào)推出的，也作為其一大賣點(diǎn)，這有些讓人哭笑不得。

作者: xxyyy 時(shí)間: 2006-01-16 14:46

原帖由 imkdk 于 2006-1-16 14:30 發(fā)表
很佩服LZ的鉆研精神，但是INFORMIX的SQL引擎的確是支持動(dòng)態(tài)SQL的。動(dòng)態(tài)SQL的語句不僅在ESQL/C中使用EXECUTE IMMEDIATE得到體現(xiàn)，也在4GL或者SPL中使用PREPARE ... FROM ... EXECUTE ...USING等SQL語句中得到體現(xiàn)， ...

非常非常同意。

作者: yunzhongyue 時(shí)間: 2006-01-16 18:34
沒感覺多么好，但也不是很差，只是學(xué)起來困難點(diǎn)！

作者: ern 時(shí)間: 2006-01-17 14:28

原帖由 imkdk 于 2006-1-16 14:30 發(fā)表
很佩服LZ的鉆研精神，但是INFORMIX的SQL引擎的確是支持動(dòng)態(tài)SQL的。動(dòng)態(tài)SQL的語句不僅在ESQL/C中使用EXECUTE IMMEDIATE得到體現(xiàn)，也在4GL或者SPL中使用PREPARE ... FROM ... EXECUTE ...USING等SQL語句中得到體現(xiàn)， ...

呵呵，這個(gè)就不對(duì)了，您可能沒有仔細(xì)研究過。Raw Device早就被oracle支持了，至少我們的9i就是用在裸設(shè)備上的。10g在磁盤管理方面主要是多了些自動(dòng)化功能。

作者: imkdk 時(shí)間: 2006-01-17 18:54

原帖由 ern 于 2006-1-17 14:28 發(fā)表

呵呵，這個(gè)就不對(duì)了，您可能沒有仔細(xì)研究過。Raw Device早就被oracle支持了，至少我們的9i就是用在裸設(shè)備上的。10g在磁盤管理方面主要是多了些自動(dòng)化功能。

這個(gè)問題倒是困擾我很久的了，就是關(guān)于9I不支持RAW DEVICE的問題，接觸ORACLE不久，所有的資料都沒說9I能支持裸設(shè)備，同時(shí)，10G推出時(shí)也專門提出了原始磁盤管理的概念，因此我就武斷的認(rèn)為9I不支持，現(xiàn)在看來是我研究不夠。能告訴我9I如何實(shí)現(xiàn)原始磁盤管理嗎？

作者: 大夫 時(shí)間: 2006-01-17 20:41

原帖由 imkdk 于 2006-1-17 18:54 發(fā)表

這個(gè)問題倒是困擾我很久的了，就是關(guān)于9I不支持RAW DEVICE的問題，接觸ORACLE不久，所有的資料都沒說9I能支持裸設(shè)備，同時(shí)，10G推出時(shí)也專門提出了原始磁盤管理的概念，因此我就武斷的認(rèn)為9I不支持，現(xiàn)在看 ...

裸設(shè)備創(chuàng)建好后,做好文件連接符,直接在上面創(chuàng)建表空間或把它添加到表空間。把裸設(shè)備當(dāng)成創(chuàng)建前已存在即可,一樣的用。

作者: zzjijun 時(shí)間: 2006-01-17 21:06
呵呵，偽君子，性別，工作內(nèi)容，工作性質(zhì)這些都扯進(jìn)來了，然后再來給個(gè)類似王朔的"我是流氓我怕誰"，這些賤招比美國總統(tǒng)競(jìng)選強(qiáng)，快趕上臺(tái)灣選舉了。
偶還第一次注意到這個(gè)論壇上的性別，不過沒想到是以這種方式，哈哈，有意思。
一個(gè)論壇上互不認(rèn)識(shí)的人，宿無仇怨，為名為利為口氣，來這些，何必呢。CU上來這些，還是少見的哦。
前不久還看到一篇論述大陸和香港論壇異同的文章，說香港論壇上說話比較客觀，喜歡提問喜歡探討，不過都是就事論事。而大陸呢，文革遺風(fēng)。
當(dāng)時(shí)還覺著有些偏頗，沒想到今日來了個(gè)佐證。

<拳打Informix9.3, 腳踢Informix9.4，強(qiáng)烈BS>好吸引眼球的題目呀!木子美，芙蓉姐姐噱頭的風(fēng)格也不過如此吧。
可能覺著妙筆生花，立意高遠(yuǎn)，論據(jù)充足，推理嚴(yán)謹(jǐn)，邏輯清晰吧，抑或意猶未盡，一口惡氣宣泄不盡，特意巴巴的從Oracle網(wǎng)站的論壇轉(zhuǎn)到CU上。
咋一看俺們還高興呢，中國也有人出了個(gè)比Informix牛的商業(yè)數(shù)據(jù)庫軟件了，鼓舞人心呀。
進(jìn)來瞅瞅，呵呵，好像這話Larry Ellison說還合適吧。
Oracle, SQL Server說他要在市場(chǎng)上強(qiáng)占多少多少份額，要win back原來Informix的多少多少用戶，咱們還可以聽聽。
再或者Oracle的架構(gòu)師，設(shè)計(jì)人員，開發(fā)人員出于對(duì)自己孩子的熱愛，說說這話咱也能理解�？�。。。
開始還在拳打腳踢，跟著改口說只是涉及影響自己工作的部分，盛氣凌人變成了楚楚可憐，悠著點(diǎn)，這彎拐的也忒大了。
回過神來，俺們總算弄明白了不論拳打腳踢，還是宣泄情緒，都是英雄本色呀，這么對(duì)自我的肯定難得呀，如此大作以后可以附在簡歷或者標(biāo)書后面了。
說不定能遇到幾個(gè)一起豪言壯語，出口成章，惺惺相惜的公司老總或是客戶呢。

Informix目前在國內(nèi)金融，移動(dòng)，電信，保險(xiǎn)都還有很多地方在使用。很多都是大型應(yīng)用。
現(xiàn)在一些外資企業(yè)拓展到中國來，他們的系統(tǒng)也帶到中國，很多還是IDS V7+4GL，一樣用的好好的。
沒準(zhǔn)大家的生活中都會(huì)有Informix的影子。
可沒想到原來使用Informix的用戶，DBA都是生活在水深火熱中呀。
對(duì)客戶是上帝，對(duì)其他人呢。
在一個(gè)軟件產(chǎn)品上從開發(fā)人員到使用者，都花了很多的時(shí)間和精力，噢，我有個(gè)性我說的話就可以不care別人，不尊重別人的勞動(dòng)成果。
到IISU上去看看，人家的論壇為什么辦的那么好，幾乎成為一種文化。技術(shù)領(lǐng)域同樣需要人文關(guān)懷。

Informix被IBM收購后什么情況大家可以看看。市場(chǎng)上No. 1競(jìng)爭(zhēng)是什么樣的，大伙也都知道。
非要跳出來拿Informix和Oracle比有什么意思。
很多時(shí)候一個(gè)軟件產(chǎn)品并不是技術(shù)先進(jìn)性決定它的生命周期。Informix在V7就是多線程了，從學(xué)院派的角度看，這比其他競(jìng)爭(zhēng)對(duì)手都先進(jìn)吧。
我們看到的是Informix分2次10億，11億買給了IBM，公司的資本運(yùn)作真是令人嘆為觀止呀。呵呵，人家care的和你我不是一個(gè)層次的東西。
BTW，按照作者的邏輯可以拿Ascential的ETL工具把Oracle罵個(gè)狗血噴頭，誰讓你連數(shù)據(jù)庫的ETL工具不如人家呀。
前面還重拳與惡語齊飛，后面卻文謅謅的來個(gè)要定討論范圍。真是見過不要臉的，沒見過這么不要臉的。
那好了，誰都也可以規(guī)定個(gè)討論范圍，就是要Oralce要做到多線程，RAC,ETL一定要做的怎樣怎樣，不然就是沒解決客戶問題。
然后咱到論壇上challenge，沒給滿意答復(fù)的都沒資格和我說話。呵呵，不過這樣子雞同鴨講就是很沒勁罷了。

Oralce的用戶，覺著Oracle的產(chǎn)品好，遇到Oracle的服務(wù)也很好，對(duì)Oracle贊不絕口，一直夸到CU的Informix版來了，這個(gè)咱理解,誰都有個(gè)好惡之欲。
Oracle的sales, pre-sales可都是很aggressive的哦。
前段時(shí)間有篇關(guān)于Oracle中國黑幕的文章，如果文章屬實(shí)Oracle的銷售渠道也是臟的夠嚇人的。
林子大了啥鳥都有，服務(wù)不能做到讓所有客戶滿意也屬正常，不滿意的咱還可以找廠商投訴呀。
真要比，去IDC, Gartner上查各家公司的客戶滿意度呀，擺出第三方的數(shù)據(jù)那公平吧。
交流下各自遇到的case還行，如果憑個(gè)人的經(jīng)驗(yàn)就一棍子打死，有失公允吧。
那天真的長了采購大權(quán)了，用誰的不用誰的都是我說了算，那也OK。再或者象IBM一樣買下來呀，怎么玩都隨你。

Oracle的介質(zhì)和很多技術(shù)書籍是在Oralce網(wǎng)站上可以公開下載的，這點(diǎn)有點(diǎn)象微軟，暗中鼓勵(lì)盜版，市場(chǎng)大了我在找你收錢。
所以O(shè)racle在國內(nèi)很多用戶都熟悉Oracle，先入為主嘛。
可這些策略，就和Oracle要客戶為尚未開發(fā)出來的功能就預(yù)先支付費(fèi)用一樣，怎么都覺著有些損呀。

再說幾個(gè)技術(shù)問題吧。

Informix的Extent是有限制，但是通過對(duì)一張表數(shù)據(jù)量的估計(jì)，合理設(shè)計(jì)extent size是可以避免的。
數(shù)據(jù)量的問題應(yīng)該在設(shè)計(jì)階段就考慮。
既然使用了某個(gè)數(shù)據(jù)庫產(chǎn)品，是否應(yīng)該對(duì)產(chǎn)品的功能包括限制有些了解呢。了解extent size的含義再加上數(shù)據(jù)量的考慮應(yīng)該不會(huì)出現(xiàn)類型問題。
從項(xiàng)目管理的一個(gè)角度看，說怎么怎么影響時(shí)間、質(zhì)量了。是否捫心自問一下，是不是當(dāng)時(shí)應(yīng)用設(shè)計(jì)沒考慮周全，或者項(xiàng)目組軟件技能準(zhǔn)備不夠。
再從性能的角度看，Extent多，很多時(shí)候意味著數(shù)據(jù)碎片多，會(huì)導(dǎo)致訪問性能下降。Extent的限制難道沒有一點(diǎn)道理在里面嗎。
類似的問題您非要覺著還不爽，那沒折了，廠商都解決不了，論壇里估計(jì)也沒好方法。您就自個(gè)拳打腳踢Informix吧，全當(dāng)自娛自樂了吧。表現(xiàn)欲強(qiáng)的就跳到臺(tái)前來吧，不過既然是公眾的場(chǎng)合，那就不一定全是掌聲和喝彩了。

Informix的存儲(chǔ)過程是不支持動(dòng)態(tài)SQL，在這個(gè)版里就有好幾篇討論這個(gè)問題的。
我理解存儲(chǔ)過程設(shè)計(jì)的初衷是要減少網(wǎng)絡(luò)流量，提高性能，減小復(fù)雜性，易于使用等。動(dòng)態(tài)SQL的使用是否和這些原則有不一致的地方，我們可以考慮考慮。
在原來的兩層架構(gòu)里存儲(chǔ)過程是比較好的解決方法，應(yīng)用更新不需要進(jìn)行前端換版。
但如果所有的業(yè)務(wù)邏輯(簡單的也好，復(fù)雜的也好)都用存儲(chǔ)過程來實(shí)現(xiàn)也會(huì)帶來很多弊端：開發(fā)，調(diào)整，維護(hù)都不方便。
國內(nèi)很多用存儲(chǔ)過程的設(shè)計(jì)都是受原來Sybase+PB的影響。
在三層架構(gòu)下面所有的業(yè)務(wù)邏輯都跑在數(shù)據(jù)庫服務(wù)器上反而不是好事，那應(yīng)用服務(wù)器要來干嘛的。
人和人的想法是有區(qū)別的，跳出來站在另外一個(gè)層次，另外一個(gè)角度看看問題是不是會(huì)有些新的啟發(fā)呢。
大肚能容噢。好比非要Java支持指針有意思嗎？
說到開發(fā)4GL其實(shí)是個(gè)好東西的，現(xiàn)在法國一家公司和IBM都基于4GL推出了新的升級(jí)語言。

你要說Informix手冊(cè)寫了支持什么什么功能，而你沒做出來。
那簡單了，你把你做的平臺(tái)，數(shù)據(jù)庫版本，使用方法列出來找廠商支持呀。
一個(gè)知名廠商應(yīng)該不會(huì)說一個(gè)根本實(shí)現(xiàn)不了的功能就敢在手冊(cè)里寫，這樣的問題一般會(huì)是軟件的BUG。
如果購買服務(wù)的話，甚至可以要求實(shí)驗(yàn)室專門修改，重新發(fā)布一個(gè)版本給用戶。
但是我們做技術(shù)的，說話做事是不是該嚴(yán)謹(jǐn)一些呢。
你就說這個(gè)功能不work，是否是你在所有平臺(tái):AIX也好，HP-UX也好，Linux，Windows。。。32位,64位，數(shù)據(jù)庫的若干個(gè)大版本，子版本都測(cè)試過它不work呢？
就跟你打支持電話一樣，你說不work，人家會(huì)不會(huì)問你什么平臺(tái)，什么版本，怎么使用的。這些都是必要的前提條件。
這么絕對(duì)的結(jié)論，這個(gè)舉證的責(zé)任是不是該在說話人一方。
用激將法來論壇上challenge的，作者也不是第一個(gè)，想想呀，有些內(nèi)容較真了都是屬于技術(shù)支持，顧問咨詢的，都是賣錢的，就這態(tài)度沒事別人憑什么告訴你呀。
一個(gè)論壇的建設(shè)還是需要積極的聲音和態(tài)度多一些的。

說到看手冊(cè)，Informix手冊(cè)上寫了 "使用HASH分段(XPS)"
您覺著這個(gè)XPS是指什么呢？

還發(fā)個(gè)站內(nèi)短信求教，您拿個(gè)發(fā)大鏡慢慢看吧。

唉，這個(gè)社會(huì)也不是什么完美的社會(huì)，有時(shí)間有精力，做好本職工作，關(guān)心愛護(hù)家人。
每個(gè)技術(shù)論壇都有無數(shù)沒有結(jié)的貼子，很多技術(shù)問題都沒有定論。
這個(gè)帖子說那么多，真的是很care那幾個(gè)技術(shù)問題嗎，真的是非要爭(zhēng)個(gè)水落石出，高低上下嗎？
說了不少Oralce的不足，真的是很不爽Oracle嗎？非也，非也，只不過是按作者的思考邏輯模擬了一下：如果用一個(gè)自我的，主觀的視角，普天之下無一物可入我眼呀。
牢騷呀，憤青呀，調(diào)侃呀，輕佻呀，可以去罵罵日本右翼，罵罵臺(tái)獨(dú)。要不更具現(xiàn)實(shí)意義的，關(guān)注下社會(huì)的房子問題呀，醫(yī)療問題呀，教育問題呀。

BTW: 我國的宗教和少數(shù)民族政策的核心：尊重! 宗教還好你不尊重他，他還是要來寬容你，感化你。
而很多的少數(shù)民族是他用酒和美味準(zhǔn)備著敬你，可你不尊重他，他就不會(huì)和顏悅色。
想想都有道理。

[ 本帖最后由 zzjijun 于 2006-1-17 21:14 編輯 ]

作者: 大夫 時(shí)間: 2006-01-18 00:10
路過路過,zzjijun強(qiáng)人啊,參觀一下,繼續(xù)啊,辛苦了,送上杯茶水,請(qǐng)慢慢喝

如果zzjijun同意,斑竹,能否麻煩,把帖子刪了吧,因我不知道該說什么了,感覺現(xiàn)在我是在罵街了，罵街我會(huì),但我怕影響大家,侮辱別人的眼睛了,謝謝。

[ 本帖最后由大夫于 2006-1-18 00:25 編輯 ]

作者: 大夫 時(shí)間: 2006-01-18 00:14
zzjijun,你是不是特氣憤?寫了那么多東西不是白寫的吧,讓我怎樣你才消氣,你說，我做.氣壞了身體可不好,我賠不起,在我身上已經(jīng)驗(yàn)證沖動(dòng)是魔鬼了.

作者: 大夫 時(shí)間: 2006-01-18 00:21
已經(jīng)把CAO,KAO,TMD等內(nèi)容刪除了,真被樓主說對(duì)了,有木子美傾向,等我進(jìn)衛(wèi)生間看看性傾向先，謝謝。

作者: 大夢(mèng) 時(shí)間: 2006-01-18 13:23
好貼！
我們要言論自由！
沒必要去刪！

作者: wordlotus 時(shí)間: 2006-01-19 16:50
罵了這么長呀，嚇人

作者: alexander_lu 時(shí)間: 2006-01-24 10:48
好帖！我喜歡用onstat.

[ 本帖最后由 alexander_lu 于 2006-1-24 11:36 編輯 ]

作者: zhan_yl 時(shí)間: 2006-01-27 18:28

原帖由大夫于 2006-1-13 17:10 發(fā)表

呵呵，沒想到討論會(huì)這么火暴。
還是先說說粗口的事吧。生活里怎么說無所謂，那是你身邊家人朋友的事。
在一個(gè)社會(huì)環(huán)境里是有禮儀，道德要遵循的吧。
敢問作者你在公司和上級(jí)會(huì)這么說話嗎？和客戶會(huì)這么說 ...

這是一個(gè)講技術(shù)的論壇，在發(fā)表帖子的時(shí)候不用帶這么多的感情色彩，實(shí)事求是地講情況就可以了

作者: zhan_yl 時(shí)間: 2006-01-27 18:59
標(biāo)題: 回復(fù) 24樓大夫的帖子
你說的對(duì)，不用對(duì)所有的問題死恰，但我工作中的應(yīng)用，屬于影響我工作的，因?yàn)樗恢С郑麄冋勰チ宋覠o數(shù)個(gè)日夜。不知道你認(rèn)真看我開篇說的沒有，我無心對(duì)他所有的功能進(jìn)行比較，我所說的，都只是我急切需要用到的。我想用著不舒服了，總可以嘮叨幾句吧，只是我不小心嘮叨到CU來了。至于你說的，ORACLE和INFORMIX等數(shù)據(jù)庫的TPC-C等的比較，那不關(guān)我的事，我只因我所要用到的內(nèi)容，這方面ORACLE讓我省了很多很多事，所以我滿意他，同樣，我也說過，INFORMIX也有我感覺比ORACLE好用的東西一樣。我所說的基礎(chǔ)，是對(duì)我工作急用的，常用的，影響比較大的內(nèi)容。請(qǐng)注意討論的范圍。

你說因?yàn)樗恢С�，影響你的工作，難道你寫應(yīng)用作設(shè)計(jì)，就只能從這一條路走，此路不通就完了？你不會(huì)尋找其他類似的方法或技術(shù)嗎？難道每種產(chǎn)品都必須提供一樣的功能才是你能接受的？

作者: zhan_yl 時(shí)間: 2006-01-27 19:05
標(biāo)題: 回復(fù) 24樓大夫的帖子
1，我不是故意要罵，已經(jīng)說過了，是一種宣泄，已經(jīng)承認(rèn)說粗口是一種錯(cuò)誤，但我依然不會(huì)否認(rèn)我會(huì)說，我說過，我說的內(nèi)容，沒有說要廠商關(guān)心。
2，我對(duì)INFORMIX，ORACLE，SYBASE等，完全沒有感情。雖然被他們折磨過無數(shù)日日夜夜，但我依然不會(huì)對(duì)他們有感情，有的只是一想到被折磨的日子就不會(huì)想再來一次！
3，你說的雜志什么的，實(shí)話是我確實(shí)不知道這個(gè)雜志，接受的信息也不夠，你說的內(nèi)容我不知道真假，沒辦法和你討論。
4，誰開發(fā)我不需要關(guān)心，我只關(guān)心通常被使用的，在google上能被很好查出來的（為什么要很容易查？那只是因?yàn)槲也粔驅(qū)I(yè)，我相信用的多的，肯定有他存在的價(jià)值）。這方面，確實(shí)ORACLE的相關(guān)產(chǎn)品比較多，和INFORMIX比起來，確實(shí)多很多，這個(gè)我不再和你爭(zhēng)論，因我不知道你對(duì)ORACLE的熟練程度。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
要宣泄可以去灌水樂園什么的地方
在INFORMIX被收購以前同樣也是有很多網(wǎng)站提供對(duì)INFORMIX的專業(yè)支持的，只是這些網(wǎng)站后來都被關(guān)閉或成為IBM的內(nèi)部網(wǎng)站了，這個(gè)跟一個(gè)產(chǎn)品的好壞是沒有聯(lián)系的

作者: zhan_yl 時(shí)間: 2006-01-27 19:20
標(biāo)題: 回復(fù) 16樓大夫的帖子
2. Extend有限制有什么新鮮的，現(xiàn)代計(jì)算機(jī)最基本的CPU,memory,I/O都有限制，作者說個(gè)Oracle沒限制的東西給我看看？
Extend問題如果沒有經(jīng)驗(yàn)是會(huì)遇到，如果經(jīng)過培訓(xùn)，學(xué)習(xí)應(yīng)該可以掌握吧。
答：其他的先不說，就ORACLE的extend來說，目前可以認(rèn)為是沒有限制的，我們認(rèn)為的沒有限制，是一種相對(duì)概念，比如ORACLE的SCN，可以認(rèn)為幾百萬年都不會(huì)重復(fù)一樣（幾百萬年后，都不知道是否還有ORACLE這個(gè)名字，你也知道不會(huì)計(jì)較幾百萬年后他是否重復(fù)了吧），不是死專牛角尖。（在此，借這個(gè)機(jī)會(huì)，能否問一下，樓主使用ORACLE的經(jīng)驗(yàn)有多少？使用INFORMIX的經(jīng)驗(yàn)有多少？），不象INFORMIX一樣，對(duì)extend有限，固定數(shù)量。我曾經(jīng)遇到過好幾次因?yàn)镮NFORMIX的extend數(shù)滿了，無法插入數(shù)據(jù)，只能把表導(dǎo)出來，重新創(chuàng)建大的extend再導(dǎo)進(jìn)去，第一次遇到這個(gè)問題的時(shí)候，我也覺得很新鮮。你也知道，大表操作是很煩人的事，所以我才那么不滿了，只是不知道樓主是否曾經(jīng)管理過大數(shù)據(jù)庫的大表？？？

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
extend就好比是數(shù)據(jù)碎片，理論上說沒有限制也不是不可能做到，只不過是效率低下罷了，從效率上考慮作了限制，要求用戶在設(shè)計(jì)階段就考慮這方面的問題，有什么不好？

作者: zhan_yl 時(shí)間: 2006-01-27 19:26
標(biāo)題: 回復(fù) 16樓大夫的帖子
答：恩，那天聽一位高人說了，說ORACLE和INFORMIX的策略不同，大概是說，ORACLE是以資源換性能，INFORMIX不是。這個(gè)話目前我還沒有認(rèn)真消化完，所以不好說。畢竟如果這是真的，那么多人的腦袋想出來的法子，我相信比我的強(qiáng)，我會(huì)去尋找差別。
至于說“Oracle本身養(yǎng)了很多研究人員來開發(fā)基于Oracle的工具”，我不知道是否真的，我最喜歡的ORACLE的性能工具STATSPACK，目前也還有很多我不滿意的功能，他們的工程師修正的好象也慢了一點(diǎn)。但類似的這種工具，INFORMIX都沒有。ORACLE的工具，不管是誰開發(fā)的，請(qǐng)樓主做個(gè)調(diào)查，是ORACLE的多，還是INFORMIX的多，我就不說了。再次說，DB2我不僅沒用過，見都沒見過。QUEST的性能工具我也見過，但只見過ORACLE的，沒見過INFORMIX的，至于說到server studio JE5.1，以前一直不知道有這個(gè)工具，后來電話INFORMIX技術(shù)支持，他被逼的沒招了，第三天吧，好象是，給我打了個(gè)電話，說他們工程師用這個(gè)工具，他本人沒有用過。我找了幾個(gè)網(wǎng)友，下載來研究了一下。目前還沒用熟，沒有感覺到多好，慢慢挖掘中，暫時(shí)還是不評(píng)論了

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
一個(gè)產(chǎn)品如果有很多各式各樣的工具來支持，你認(rèn)為就是一個(gè)產(chǎn)品好壞的判斷標(biāo)準(zhǔn)嗎？你學(xué)習(xí)使用這些工具是否要花費(fèi)精力呢？如果使用這些工具你得出矛盾的結(jié)果，你該如何應(yīng)對(duì)？

作者: zhan_yl 時(shí)間: 2006-01-27 19:53
標(biāo)題: 回復(fù) 17樓大夫的帖子
不知道樓主是否給系統(tǒng)做過綜合性能分析，在一個(gè)大型OLTP里，由于國內(nèi)的軟件開發(fā)上線，在上線前各模塊是沒有經(jīng)過認(rèn)真測(cè)試的，或者對(duì)SQL性能就是沒有測(cè)試的，每小時(shí)生成的SQL大概超過1G內(nèi)存大小，此時(shí)，請(qǐng)問如果不查詢這些，如何知道那些SQL是消耗資源最大的，或很大的呢？所以，我才喜歡ORACLE的STATSPACK，它提供趨勢(shì)分析�。�！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
如果你不是應(yīng)用開發(fā)商，你在得到一些設(shè)計(jì)很差的應(yīng)用程序，你監(jiān)控出結(jié)果，那你又能做些什么呢？你能去改他的應(yīng)用？那為什么不在應(yīng)用開發(fā)階段由開發(fā)人員去考慮這些問題呢？一個(gè)設(shè)計(jì)很差的應(yīng)用程序，我想在最好的系統(tǒng)里面也不會(huì)得到很高的運(yùn)行效率的。

作者: zhan_yl 時(shí)間: 2006-01-27 19:59
標(biāo)題: 回復(fù) 17樓大夫的帖子
1，我曾經(jīng)寫過一個(gè)軟件dbmonitor，可自適應(yīng)監(jiān)控ORACLE，INFORMIX，SYBASE的一些如內(nèi)存，存儲(chǔ)，對(duì)象，會(huì)話，日志等內(nèi)容的一個(gè)工具。當(dāng)時(shí)做完了IDS 9.4版，做9.3版的時(shí)候，才發(fā)現(xiàn)很多系統(tǒng)表名都變了，到現(xiàn)在我也沒找到說明資料（或許有，是我沒翻到，但現(xiàn)在已失去了再升級(jí)DBMonitor的興趣）。
2，樓主說了，從9.3升級(jí)到9.4很容易，能否發(fā)個(gè)方案來看看？這個(gè)問題，后來提交給我們系統(tǒng)集成事業(yè)部討論，結(jié)論是目前不適合做升級(jí)，到現(xiàn)在我們也沒做成。環(huán)境：一個(gè)SUN，一個(gè)HP，表實(shí)際數(shù)據(jù)量大概300G左右，chunk使用裸設(shè)備。系統(tǒng)離線時(shí)間不能太長。謝謝。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
INFORMIX公布出來的系統(tǒng)表及結(jié)構(gòu)一般是不會(huì)變化的，那些沒有公布出來的才是會(huì)發(fā)生改變的，這也是為了性能改進(jìn)的需要
你說的升級(jí)問題其實(shí)在你提供的參考書目里面就已經(jīng)提供了詳細(xì)的方案。你收集了這么多的參考書，但是卻束之高閣，對(duì)你的工作又有何益呢？

作者: zhan_yl 時(shí)間: 2006-01-27 20:07
標(biāo)題: 回復(fù) 17樓大夫的帖子
onstat ，只是計(jì)算輸出了當(dāng)前的值，請(qǐng)注意，是當(dāng)前，所以無法提供趨勢(shì)分析。既然樓主是“資深DBA”，那也應(yīng)該知道趨勢(shì)分析的重要了吧，要把問題扼殺在搖籃中啊。。。。那只能把當(dāng)前onstat的數(shù)據(jù)入庫？唉，我再說一次KAO，這樣是不是會(huì)增加很多資源消費(fèi)呢？曾經(jīng)見過，比如onperf，可以提供采集點(diǎn)，畫出圖形來表示資源的使用曲線，但這得一直開著這個(gè)窗口，這樣符合例行維護(hù)的工作需要嗎？我覺得好象不是很符合的吧。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
你認(rèn)為那些趨勢(shì)分析是在什么基礎(chǔ)上產(chǎn)生的？是絕對(duì)準(zhǔn)確的嗎？這可能需要一些統(tǒng)計(jì)概率學(xué)的知識(shí)吧？如果你知道了這些，你獲取合理的數(shù)據(jù)抽樣，我想你是不難得出趨勢(shì)分析的。但這只能代表預(yù)測(cè)，不能代表事實(shí)。

作者: zhan_yl 時(shí)間: 2006-01-27 20:17
標(biāo)題: 回復(fù) 17樓大夫的帖子
我們?cè)谧鰞?nèi)存分配分析的時(shí)候，ORACLE在大體的幾個(gè)方面進(jìn)行初始設(shè)置后，一般都能取得不錯(cuò)的性能效果，剩下的我定義為微調(diào)整了。而INFORMIX，真的很難搞，你比如一個(gè)SQL緩沖區(qū)，就要配置好幾個(gè)參數(shù)，而同時(shí)還有統(tǒng)計(jì)數(shù)據(jù)緩沖區(qū)，數(shù)據(jù)字典緩沖區(qū)等等虛擬內(nèi)存部分。我的其中一個(gè)疑惑請(qǐng)參考本版《Informix 內(nèi)存討論之一: SQL語句高速緩存》 http://72891.cn/viewthr ... &extra=page%3D1
請(qǐng)樓主進(jìn)去對(duì)我的疑惑，指導(dǎo)一下，萬分感謝
--------------------------------------------------------------------------------------------------------
sql statement cache并不是對(duì)數(shù)據(jù)庫效率影響最大的部分，我想你應(yīng)該抓住對(duì)性能影響最大的東西，把精力放在那上面，才會(huì)對(duì)整體性能有所提升，建議你去看看IBM Informix
Dynamic Server
Performance Guide

作者: zhan_yl 時(shí)間: 2006-01-28 08:54

原帖由大夫于 2006-1-6 11:24 發(fā)表
1,execute plan
Informix的execute plan,
1)單條SQL語句,可以通過以下方式得到
% dbaccess database_name -
Database selected.
> set explain on;
Explain set.
> 執(zhí)行SQL語句
然后Ctrl+c退出 ...

需要INFORMIX性能監(jiān)測(cè)工具的可以去看看http://www.serverstudio.com/products/ssje/

作者: 大夫 時(shí)間: 2006-02-06 17:22
這是一個(gè)講技術(shù)的論壇，在發(fā)表帖子的時(shí)候不用帶這么多的感情色彩，實(shí)事求是地講情況就可以了
你說因?yàn)樗恢С�，影響你的工作，難道你寫應(yīng)用作設(shè)計(jì)，就只能從這一條路走，此路不通就完了？你不會(huì)尋找其他類似的方法或技術(shù)嗎？難道每種產(chǎn)品都必須提供一樣的功能才是你能接受的？
要宣泄可以去灌水樂園什么的地方
在INFORMIX被收購以前同樣也是有很多網(wǎng)站提供對(duì)INFORMIX的專業(yè)支持的，只是這些網(wǎng)站后來都被關(guān)閉或成為IBM的內(nèi)部網(wǎng)站了，這個(gè)跟一個(gè)產(chǎn)品的好壞是沒有聯(lián)系的
extend就好比是數(shù)據(jù)碎片，理論上說沒有限制也不是不可能做到，只不過是效率低下罷了，從效率上考慮作了限制，要求用戶在設(shè)計(jì)階段就考慮這方面的問題，有什么不好？
一個(gè)產(chǎn)品如果有很多各式各樣的工具來支持，你認(rèn)為就是一個(gè)產(chǎn)品好壞的判斷標(biāo)準(zhǔn)嗎？你學(xué)習(xí)使用這些工具是否要花費(fèi)精力呢？如果使用這些工具你得出矛盾的結(jié)果，你該如何應(yīng)對(duì)？

如果你不是應(yīng)用開發(fā)商，你在得到一些設(shè)計(jì)很差的應(yīng)用程序，你監(jiān)控出結(jié)果，那你又能做些什么呢？你能去改他的應(yīng)用？那為什么不在應(yīng)用開發(fā)階段由開發(fā)人員去考慮這些問題呢？一個(gè)設(shè)計(jì)很差的應(yīng)用程序，我想在最好的系統(tǒng)里面也不會(huì)得到很高的運(yùn)行效率的。
INFORMIX公布出來的系統(tǒng)表及結(jié)構(gòu)一般是不會(huì)變化的，那些沒有公布出來的才是會(huì)發(fā)生改變的，這也是為了性能改進(jìn)的需要
你說的升級(jí)問題其實(shí)在你提供的參考書目里面就已經(jīng)提供了詳細(xì)的方案。你收集了這么多的參考書，但是卻束之高閣，對(duì)你的工作又有何益呢？
你認(rèn)為那些趨勢(shì)分析是在什么基礎(chǔ)上產(chǎn)生的？是絕對(duì)準(zhǔn)確的嗎？這可能需要一些統(tǒng)計(jì)概率學(xué)的知識(shí)吧？如果你知道了這些，你獲取合理的數(shù)據(jù)抽樣，我想你是不難得出趨勢(shì)分析的。但這只能代表預(yù)測(cè)，不能代表事實(shí)。
sql statement cache并不是對(duì)數(shù)據(jù)庫效率影響最大的部分，我想你應(yīng)該抓住對(duì)性能影響最大的東西，把精力放在那上面，才會(huì)對(duì)整體性能有所提升，建議你去看看IBM Informix
Dynamic Server
Performance Guide
需要INFORMIX性能監(jiān)測(cè)工具的可以去看看http://www.serverstudio.com/products/ssje/

============================================================

這些話我就懶的回了,無聊中

如果樓主有空，請(qǐng)看看
16樓,17樓的內(nèi)容,談?wù)勀切﹩栴}怎么解決,怎么處理吧.我無聊,不用你跟著我一起無聊,謝謝!

作者: zycwt 時(shí)間: 2006-02-13 16:04
informix確實(shí)很爛，程序管理多臺(tái)服務(wù)器都很大的問題

作者: snow888 時(shí)間: 2006-02-16 10:28
別爭(zhēng)這個(gè)問題了,我也是樓主的標(biāo)題引進(jìn)來的,還第一個(gè)回了帖子.

建議樓主把自己收集的書、資料用心看一遍吧。發(fā)發(fā)牢騷于事無補(bǔ)，樓主的某些問題就在樓主收集的資料里面。

作者: syitssa 時(shí)間: 2006-02-20 17:22
hah
說實(shí)話，拳打Informix 9.3，腳踢Informix 9.4
這個(gè)標(biāo)題還是比較有吸引力的，看的出來，樓主還是比較有鉆研精神的，這些佩服
另外說粗口，嘿嘿，雖然說最好不要，不過嘿嘿，覺得沒無傷大雅吧，又不是說的很惡心，都kao這樣代替而已，真漢子大部分都這樣的，說實(shí)話，個(gè)人認(rèn)為，中國人能有一大部分是真性情的漢子，那技術(shù)將不再是問題，中國的軟件也不至于如此的不堪了，唉。環(huán)境所致，大家不能真正的團(tuán)結(jié)罷了，呵呵，說起來，都成了題外話了

作者: hukeqin 時(shí)間: 2006-03-01 11:37
青菜蘿卜各人所愛,但我還是很喜歡INFORMIX

作者: yilingongzhu 時(shí)間: 2006-03-26 21:34
標(biāo)題: zzjijun強(qiáng)
zzjijun,請(qǐng)問您是哪方高人?
您寫的反擊文章好精彩!
是不是找槍手替的?
做技術(shù)的人怎么那么有文采??!!

作者: laizx 時(shí)間: 2006-03-27 22:21
^_^，我也來湊湊熱鬧！

我對(duì)oracle和informix的認(rèn)識(shí)是這樣的一個(gè)動(dòng)態(tài)過程：
1. 最先，那是在1996年左右，在Xinex下用Oracle，感覺那個(gè)sqlplus不好用，而且安裝太復(fù)雜了，寫了幾大張紙，一點(diǎn)都不能錯(cuò)了。其他嘛，馬馬虎虎。

2. 后來，從97年吧，開始用informix，比較老的版本，安裝很簡單，而且dbaccess，onmonitor，isql很好用啊，感覺比Oracle強(qiáng)多了，特別是isql，比那個(gè)什么sqlplus好用很多的。

3. 再后來，oracle越來越壯大了，特別是有了windows端的工具后，感覺oracle的易用性超過informix了，informix在windows平臺(tái)上的工具遠(yuǎn)遠(yuǎn)比不上oracle了。
不過，如果還是做主機(jī)/終端模式的系統(tǒng)，而數(shù)據(jù)庫能夠由我來選擇的話，我一定會(huì)選擇informix的！

p.s.我現(xiàn)在給銀行做的系統(tǒng)就是informix+AIX的！^_^

作者: 狡兔 時(shí)間: 2006-04-02 11:14
我目前僅會(huì)用informix，管理幾百G上T的數(shù)據(jù)，覺得也還行.　不過看樓主說的一些orcale的性能管理工具，是比informix的更好，如果informix上有，肯定比現(xiàn)在沒有要強(qiáng).

此外我很想了解informix的前景，是否要在下一代業(yè)務(wù)系統(tǒng)中換用oracle了.

作者: zfaika 時(shí)間: 2006-04-02 18:16

原帖由大夫于 2006-1-6 11:24 發(fā)表
1,execute plan
Informix的execute plan,
1)單條SQL語句,可以通過以下方式得到
% dbaccess database_name -
Database selected.
> set explain on;
Explain set.
> 執(zhí)行SQL語句
然后Ctrl+c退出 ...

誰說INFORMIX不支持動(dòng)態(tài)SQL？？？？？
LZ用過嗎？

作者: BigCadre 時(shí)間: 2006-04-07 09:37
標(biāo)題: 看來各位都是高手，請(qǐng)教一個(gè)問題先
informix是9.3版本，出現(xiàn)如下錯(cuò)
2006-04-06 05:47:35.491 讀取接口表待處理記錄錯(cuò)誤，錯(cuò)誤信息ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:-1 Line:1 State:0 Severity:0 SP: Server: ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:-1 Line:1 State:0 Severity:0 SP: Server: ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:-1 Line:1 State:0 Severity:0 SP: Server: ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:-1 Line:1 State:0 Severity:0 SP: Server: ；（SQL語句：SELECT b.i_accept, b.i_workno, b.i_zt, b.i_lath_id, b.i_phone, b.i_oldphone, b.i_devices, b.i_olddevices FROM dt_phsjkyw_zx a,dt_phsjkdd_zx b WHERE (b.i_zt = '000004' AND a.i_accept = b.i_accept AND a.i_bm = '092' AND a.i_xxm = '2' AND b.i_workno IN('00','02','06','15','16')) UNION SELECT b.i_accept, b.i_workno, b.i_zt, b.i_lath_id, b.i_phone, b.i_oldphone, b.i_devices, b.i_olddevices FROM dt_phsjkyw_zx a,dt_phsjkdd_zx b WHERE (b.i_zt = '000000' AND a.i_accept = b.i_accept AND a.i_bm = '092' AND a.i_xxm = '1' AND b.i_workno IN('00','02','06','04','05','15','16','01','18','07')) UNION SELECT i_accept, i_workno, i_zt, i_lath_id, i_phone, i_oldphone, i_devices, i_olddevices FROM dt_phsjkdd_zx WHERE (i_zt = '000004' AND i_workno = '17') UNION SELECT i_accept, i_workno, i_zt, i_lath_id, i_phone, i_oldphone, i_devices, i_olddevices FROM dt_phsjkdd_zx WHERE (i_zt = '000000' AND i_workno IN ('03','08','19','20','21'))）�。�
2006-04-06 05:47:47.382 數(shù)據(jù)庫異常（m_ODBCDatabase.Close()）：ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:0 Line:0 State:0 Severity:0 SP: Server:
2006-04-06 05:47:47.538 連接97系統(tǒng)接口表數(shù)據(jù)庫失�。ㄟB接參數(shù)DSN=136.5.8.30;UID=zxyf

WD=zximp724，錯(cuò)誤原因：ODBC Error Code:HY000 Local Error Code:-1803 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Connection does not exist.
Rownumber:0 Line:0 State:0 Severity:0 SP: Server: ）！
2006-04-06 05:48:21.069 數(shù)據(jù)庫異常（m_ODBCDatabase.DriverConnect）：ODBC Error Code:HYC00 Local Error Code:0 Error Info: [INTERSOLV][ODBC Informix driver]Optional feature not implemented. Rownumber:0 Line:56468 State:0 Severity:0 SP: Server: ODBC Error Code:HY000 Local Error Code:-25572 Error Info: [INTERSOLV][ODBC Informix driver][Informix]Network driver cannot bind a name to the port.
Rownumber:0 Line:56468 State:0 Severity:0 SP: Server: ODBC Error Code:HY000 Local Error Code:55 Error Info: [INTERSOLV][ODBC Informix driver][Informix]No buffer space available
Rownumber:0 Line:56468 State:0 Severity:0 SP: Server: ODBC Error Code:IM006 Local Error Code:0 Error Info: [INTERSOLV][ODBC Informix driver]Driver's SQLSetConnectAttr failed. Rownumber:0 Line:56468 State:0 Severity:0 SP: Server:

作者: lyx96 時(shí)間: 2006-04-17 16:27
標(biāo)題: 明白
上嗎的幾位大哥，你們忙活什么呢？如果是在民國的時(shí)候有人會(huì)以為是漢奸在吵架！不管是 informix、oracle、SYBASE或者是 Sql_server��；也不管是那個(gè)好用，那個(gè)不好用或者是ｂｕｇ多多。但是有一個(gè)問題，這中間的數(shù)據(jù)庫有幾個(gè)是中國的軟件？上嗎的幾個(gè)兄弟要是真的有能耐就自己研發(fā)一個(gè)中國的數(shù)據(jù)庫讓兄弟門也看看，ｂｕｇ多，不好用，那怎么還在用�。坎蝗缁丶曳N地，用自己的鋤頭心里面踏實(shí)！

作者: ikb 時(shí)間: 2006-04-20 11:24
把情緒化的東西過濾掉，看著還是很不錯(cuò)的。

作者: 大夫 時(shí)間: 2006-04-20 13:37
我現(xiàn)在已離開以前的公司,到一個(gè)新公司做全職Oracle DBA了.informix,只還有點(diǎn)殘留的記憶,再談informix,已是力不從心.

一個(gè)人的精力有限,對(duì)也罷,錯(cuò)也罷,往事已成歷史,活著就不容易.
已經(jīng)過去的我就不會(huì)后悔,只是有點(diǎn)BS自己拿著低薪,隨他的,自己高興就成。

今天我又把帖子看了一遍,發(fā)現(xiàn)自己和一部分人存在一些個(gè)問題,僅供參考:
1)情緒化確實(shí)太重了.
現(xiàn)在做DBA,情緒化是很恐怖的,沖動(dòng)是魔鬼一點(diǎn)也不假.冷靜下來,問題就已經(jīng)解決大半了。
再次就我上面發(fā)表的過激言辭道歉.但過去的，誰也改變不了,是我在這個(gè)世界活著的歷史,不會(huì)有再來一次的機(jī)會(huì),更不可能會(huì)有很多個(gè)機(jī)會(huì),我依然很高興我過去說的那些話,那是我的.
2)斷章取意.
沒有就上下文理解別人的意思,可能僅就看到的某一點(diǎn)而談自己的理解,以至發(fā)生不少誤解,誤會(huì).
我想,參與本帖討論的網(wǎng)友們,都不是這個(gè)領(lǐng)域的權(quán)威,或已深刻理解數(shù)據(jù)庫技術(shù)乃至引導(dǎo)數(shù)據(jù)庫技術(shù)的發(fā)展,平時(shí)別人冠與的專家,牛人等稱號(hào),也僅僅是某一特定圈子的比較結(jié)果而已,或許我們還要浪費(fèi)時(shí)間來捍衛(wèi)這種榮耀,悶心自問,我們會(huì)什么,懂什么,牛什么,自己理解的就是對(duì)的么,不能肯定自己,或許可以學(xué)會(huì)原諒,幫助,啟發(fā)別人,謀求共同進(jìn)步,共同學(xué)習(xí)。
好象說的過多了，請(qǐng)?jiān)徫胰滩蛔≌f的,緣于我看了一篇《成就DBA職業(yè)生涯》（http://www.itpub.net/519295.html），感于自己所會(huì)的，所不會(huì)的，平日的態(tài)度而已，還得繼續(xù)在初級(jí)DBA的世界里暢游啊，革命尚未成功，同志仍需努力。
3)設(shè)身處地
內(nèi)心捍衛(wèi)自己，排斥別人，立論前未謙虛的接受、理解別人的意圖，自己的就是對(duì)的，別人的就是錯(cuò)的，意見不再是意見，如果說我們不是真正清楚這個(gè)技術(shù)，那不妨把我們的理解說出來，以供學(xué)習(xí)參考吧。

不多說啦，說的越多，可被評(píng)擊的點(diǎn)越多，鴕鳥戰(zhàn)術(shù)是個(gè)不錯(cuò)的選擇。人與人的矛盾，可能就在于這個(gè)世界不是只有一個(gè)人吧。

作者: nick850827 時(shí)間: 2010-12-14 11:41
第一次回帖，支持樓主精彩的個(gè)人見解。

作者: meditatorx 時(shí)間: 2010-12-23 11:41

第一次回帖，支持樓主精彩的個(gè)人見解。
nick850827 發(fā)表于 2010-12-14 11:41

06年的帖子都能被你翻出來，這里我只能說佩服

informix的技術(shù)參考資料確實(shí)少得可憐，出了問題很難找到支持！

作者: nick850827 時(shí)間: 2011-01-04 10:05
回復(fù) 65# meditatorx

哈哈。。。我回完之后才發(fā)現(xiàn)了是n久以前了。我自己也汗一個(gè)。

作者: D2002 時(shí)間: 2012-08-23 09:44
看看老貼，還是很精彩的

Informix確實(shí)存在諸多不足，尤其在售后技術(shù)支持、測(cè)試監(jiān)控工具等方面

歡迎光臨 Chinaunix (http://72891.cn/)