拳打Informix 9.3，腳踢Informix 9.4，強(qiáng)烈BS

zhan_yl

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



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

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

zhan_yl

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


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

zhan_yl

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

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

zhan_yl

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

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

zhan_yl

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

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

zhan_yl

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

zhan_yl

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

zhan_yl

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

zhan_yl

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

zhan_yl

原帖由 大夫 于 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)測工具的可以去看看http://www.serverstudio.com/products/ssje/