INFORMIX

在一家早期的S-100/CP/M公司Cromemco工作的Roger Sippl和Laura King開發了一個基於ISAM技術的小型的關係數據庫，作為一個報表記錄器軟件的一部分。

1980年，Sippl和King離開Cromemco去開發關係數據庫系統（RDS）。他們的第一個產品叫做馬拉松（Marathon），本質上是一個他們以前那個ISAM作品的16位版本，並且在Onyx操作系統上發佈，這種Onyx操作系統是一個為早期的ZiLOG微處理器開發的Unix操作系統。

在開發RDS的時候，他們把目光轉移到了新興的RDBMS市場，並且在1981年發佈了他們自己的一個產品：Informix（INFORMation on unIX）。它包含了他們自己的Informer語言。它具備了ACE報表記錄器的特性，用來把數據從數據庫裏釋放出來，並且呈現給用户以供讀取。它還具備了PERFORM屏幕格式工具的特性，可以讓用户實現交互式的查詢並且編輯數據庫裏的數據。這個產品的最終版本是1986年的3.30版。

在1985年，他們引進了一種新的基於SQL的查詢引擎，作為INFORMIX-SQL（或ISQL）1.10版（1.00版一直沒有發行）的一部分。這個產品同樣包括了SQL和PERFORM的SQL變量。ISQL和早期的Informix產品最顯著的區別就在於將數據庫存取碼分散至一個引擎進程中（sqlexec），而不是將其直接嵌入客户端，這樣來為和用户的電腦分離開的數據庫服務器上的客户端-服務端運算創造條件。而基礎的基於ISAM的文件存儲引擎就被稱作C-ISAM。

儘管在上世紀80年代Informix一直扮演一個小角色，但是隨着Unix和SQL在80年代走向流行，他們的命運隨之改變。在1986年，他們已經強大到自己獨立募股，而且將公司改名為Informix Software。他們的產品包括INFORMIX-SQL 2.00版和INFORMIX-4GL 1.00版，兩個產品都包含了數據庫引擎和開發工具（為程序員準備的I4GL，和為普通用户準備的ISQL）。

一系列的產品隨之發佈，包括最初被認為是INFORMIX-Turbo的新的查詢引擎。Turbo利用了新式的，比C-ISAM更對多用户性能有好處的RSAM。在1989年的4.00版出版後，Turbo被命名為INFORMIX-OnLine（一部分原因是因為它允許服務器運行在運行時，並且用户正在修改數據，而數據庫的備份照樣連貫進行），而且最初的基於C-ISAM的服務器被工具（ISQL和I4GL）所分割開來，並且被命名為INFORMIX-SE（標準版）。在1990年年末的時候，Informix OnLine 5.00版本問世，而且包括了完整的對擁有兩步式工作提交和存儲過程的分佈式交易的支持。在5.01版中增加了對觸發器的支持。

在1988年，Informix將Innovative Software公司收購，後者研發了著名的基於DOS和Unix的辦公系統軟件SmartWare，和具有革新意義基於Apple Macintosh平台的的電子製表軟件WingZ。

隨着Informix在辦公自動化領域的失敗，1994年他們重新把精力集中到發展當中的數據庫服務器市場。同年，在與Sequent Computer Systems的協作下，Informix發佈了具備動態可擴展結構（DSA）的6.00版的數據庫服務器。

DSA將產品的核心引擎做了很大改動，支持了橫向和縱向的並行功能。並且基於和很多先驅與軟件生產商（比如Sun Microsystems，Hewlett-Packard）都相繼追隨的對稱多處理系統完美搭配的多線程核心。這兩種並行模式讓產品在擴展性上處於市場領先地位，不論是OLTP還是data warehousing。

如今我們熟知的Informix Dynamic Server（當初考慮過命名為Obsidian，而後來命名為Informix OnLine Dynamic Server），它的第7版在1994年震撼了市場。當時正式對稱多處理技術（SMP）系統剛剛開始盛行，而且Unix已經開始變為服務器操作系統的主流。第7版基本上成為領先於其他競爭者的一代產品，而且不斷地在性能評測上勝出。這場勝利的結果使得Informix在1997年輕而易舉地將Sybase擠下去，登上了數據庫世界的亞軍寶座。

在第7版的成功的基礎上，Informix將他們核心數據庫研發的投資分為兩個焦點。第一個是一開始所謂的XMP（for eXtended Multi-Processing），後來演變成了第8版的生產線，也被稱作 XPS（for eXtended Parallel Server）。這個焦點致力於data warehousing和高端平台的並行處理，包括像IBM的RS-6000/SP這樣的shared-nothing平台。

在1995年收購了IIIustra後，第二個焦點集中在object-relational數據庫（O-R）技術。Informix在7.x版本的OnLine產品中集成了IIIustra的O-R映射和DataBlades，結果變成了Informix Universal Server（IUS），或者簡單地説，就是第9版。

第8版（XPS）和第9版（IUS）都出現在1996年的市場上，令Informix成為第一個內建O-R支持的“big three”數據庫公司（另外兩個是Oracle和Sybase）。評論家們花了很多心思在DataBlades上，DataBlades後來非常流行，繼與IIIustra的合夥後，又有了新架構。這讓其他的軟件生產商很着急，Oracle在1997年發佈了支持時間序列的“嫁接”包，而Sybase讓一家第三方公司為其製作了一個沒有競爭力的附加產品包。

在市場上的失敗和公司的管理不當，掩蓋了Informix技術上的成功。在1997年愚人節那天，Informix宣佈他們第一個季度的收入比預期少了10億美元。公司CEO Phillip White把這些差額怪罪在未能投入足夠的精力在核心數據庫業務上，而在object-relational技術上投入了太多資源。緊接着，大量的營業損失和裁員相繼而來。Informix重審了1994年到1996年的利潤，1990年代中期包括給合夥公司的軟件許可證其實很大一部分都沒有真正售出到終極用户手中，這樣不規範的操作致使公司財政產生了超過20億美元的泡沫。即使在White 1997年7月離開後，公司在1998年又來了一次財務重審。

從2000年開始，Informix歷史上的大事件再也不是集中在技術革新上了。從那一年開始，三月份，Informix購買了Ardent Software，一家自己本來就是收購和合並而來的公司。這次收購為他們那個時候已經很多了的數據庫引擎又增加了兩個多維引擎UniVerse和UniData（被簡稱為U2），不僅包括Informix傳統的產品，還有Red Brick的面向datawarehouse的SQL引擎、100% Java版本的SQL，Cloudscape（後來被綁定在J2EE的參考安裝包內）。

2000年7月，Ardent公司的前任CEO，Peter Gyenes，成為Informix的CEO，並且迅速重整了Informix以讓其成為一個更誘人的期待別被別人收購的“獵物”。這樣重要的一個決定是要把所有的數據庫引擎技術，和應用程序與工具分離開來。

在2001年4月，IBM趁着這次重整，提出了一項來自於沃爾瑪（Informix最大的客户）的建議，從Informix購買了數據庫技術、品牌、未來開發計劃（代碼名為“Arrowhead”的內部工程）以及和這些相關的超過10萬餘計的用户基礎。剩下的生產應用程序和工具的公司重新命名為Ascential Software。在2005年5月，IBM買下了Ascential，在IBM的Information Management Software的投資組合下重新聚合了Informix的資產。

經過優化的新版IDS 11.5代號“Cheetah 2”，可支持客户運用IBM大型機系統提供的多種信息管理技巧，增強集羣服務器環境的業務表現。因此IDS可謂是業界第一款非大型機級數據服務器，無論地理位置遠近或與備份數據中心站點間距離長短，它都能為集羣數據中心提供低成本持續數據可用性和災難恢復能力。

IBM負責數據管理市場推廣的副總裁Inhi Cho表示：“目前全球各行各業、各種規模的企業都希望能夠與本地及全球企業開展不間斷業務交易，獲得競爭性優勢。而新版IDS卓越的速度、靈活性和高效可幫助我們的客户企業在自我發展的過程中，不斷增強整體業務表現並降低相關成本。”

新版IDS 11.5在原版基礎上進行了多處改良，其領先的穩定性和交易性能得到了進一步的提升，可更好地支持用户減少所需的服務器的數量和成本。它允許客户以更少的硬件服務器管理相同數量的數據，因此大大降低了客户對軟件許可、管理成本、能源和空間的需求。

依此類推，當企業內部擁有數百或數千台應用或系統時，IDS 11.5可為分佈廣泛的數據管理節約大量資源、空間和成本。那些依賴不間斷信息訪問、且缺乏管理眾多數據庫專業IT員工的小型企業和機構也能從多功能IDS 11.5中受益。

英國Trafficmaster（一家領先的智能駕駛服務提供商）的一名項目經理Jon Tasker表示：“我們選擇使用Informix將大型數據倉庫整合在一起，為我們的客户提供更智能的衞星導航服務和更短的驅車路程。我們需要全天候管理350萬條路段上多達10萬輛汽車的行駛速度相關數據，這是一項巨大的數據管理挑戰，而且這些數據還在持續不斷的增加。在我們的基準測試流程中，Informix憑藉其優異的性能、可擴展性和穩定性從眾多領先解決方案中脱穎而出。”

Jenzabar公司負責軟件與服務的副總裁Ben Bassett表示：“Jenzabar對IBM IDS 11.5中的幾項新功能印象深刻。改進的高可用性支持我們這些高等教育市場的客户更輕鬆地為委託人提供全天候不間斷的服務。此外，我們對IBM在IDS產品線中所展示的承諾感到尤為欣喜。這一系列版本的推出不僅增加了IDS的實際價值，反過來還提升了我們對該產品線，以及我們與IBM之間合作關係的滿意度。”

作為IBM信息管理軟件組合中的一項戰略要素，IDS 11.5數據服務器可提供出色的快速在線交易處理（OLTP）性能，高可靠性和低成本管理能力。因此，IDS也一舉成為了眾多細分市場上領先的集成數據服務器，這些市場包括零售、電信、政府/公共領域、旅遊和娛樂等。IIDS持續受到眾多客户的垂青和歡迎，越來越多的企業在本企業中選擇使用IDS。例如，僅北美地區前十大美國零售商中就有八家將其用於重要業務應用；全球有95%的電信公司均採用IDS支持本企業的數據管理。

1. Page Size

頁面大小，由系統決定，用户無權更改。

2. Mirror { MIRROR }

是否作鏡像處理。

3. Tape Dev. { TAPEDEV}

數據備份所用的磁帶設備，需要選擇好或提前準備好，如使用硬盤文件的話，創建方法同準備硬盤空間。

主要參數有磁帶設備路徑(可以是硬盤的某個文件，或/dev/null )、磁帶塊大小(Block Size)及總容量(Total Tape Size)。

4. Log Tape Dev. {LTAPEDEV}

數據庫邏輯日誌備份使用的磁帶設備。

5. Stage Blob {STAGEBLOB}

INFORMIX-OnLine/Optical為存儲目的地是光盤的blobs所用的blobspace名稱。僅當你使用光盤 和INFOMRIX-OnLine/Optical時，才有可能使用此參數。

6.Root Name {ROOTNAME}

存儲OnLine配置的根數據庫空間（dbspace），在所有數據庫空間中名字唯一。默認是rootdbs,建議沿用此名稱。

Primary Path： { ROOTPATH }

rootdbs的路徑，須預先準備好。

Root Size： { ROOTSIZE }

規定rootdbs的大小。建議不要小於50MB。

Root Offset ： {ROOTOFFSET }

Root Name 設備的偏移量。對於Primary Path指定的設備是操作系統文件時，必須是0；如果Primary Path是原始設備（硬盤、或可擦寫光盤等）可以指定起始位置。

8. Mirror Path { MIRRORPATH }

如果Mirror處選擇了Y，此處要求輸入鏡像設備或文件的絕對路徑。

Mirror Offset：{ MIRROROFFSET }

鏡像設備的偏移量。對於Mirror Path指定的設備是操作系統文件時，必須是0；如果Mirror Path是原始設備（硬盤、或可擦寫光盤等）可以指定起始位置。

9. Phy. Log Size { PHYSFILE }

規定物理日誌大小（大於等於200K）。初始化後仍可以調整。

10. Log. Log Size { LOGSIZE }

規定邏輯日誌大小。初始化後不可改變。

最小值=200

最大值=（rootsize-physfile-512-(63*((pagesize)/1024))/logfiles）

Number of Logical Logs { LOGFILES }

規定邏輯日誌的個數。初始化後可以增加。

11. Logical Log：

記錄數據庫每個操作的日誌，主要是為了在數據庫崩潰後最大限度的恢復毀壞的數 據。Informix OnLine最少有六個邏輯日誌，記錄依次循環存放。要定期對其進行備份，備份後的日誌仍可使用。在當全部日誌寫滿而仍未進行備份時，OnLine將停止運轉，直到有可用的邏輯日誌。將數據庫設為No Log 模式、或邏輯日誌備份設備是/dev/null時除外。

12.Server Number { SERVERNUM }

數據庫服務器編號（0～255）。規定了共享內存存儲中的相對位置，選擇的數值並不重要。只是要求本地主機上的每個OnLine數據庫服務器選擇的值都要唯一。該值在網絡上不一定是唯一的，因為0值是默認設置。建議你選擇一個非0值以避免重複。

13. Server Name { DBSERVERNAME }

規定與這個OnLine的特定出現相聯繫的唯一名字。與環境變量INFORMIXSERVER的值相同。與sqlhosts文件中的一個通訊協議相聯繫。

14. Server Aliases { DBSERVERALIASES }

數據庫別名。

15. Max # of Logical Logs { LOGSMAX }

邏輯日誌的最大個數。主要是為在共享內存中為邏輯日誌預留空間。

16. Max # of Locks { LOCKS }

最大的鎖數。數據庫操作中同時使用的各類鎖的總數的上限。

17. Max # of Buffers { BUFFERS }

最大緩衝區個數 ^[1]  。

oninit命令 語法 oninit [-s] [-i] [-p] [-y] ^[2] 

oninit　將系統從off-line模式變為on-line模式

oninit -s 　 將系統從off-line模式變為quiescent模式

oninit -i 　 初始化系統

oninit -p 　 在共享內存初始化時，不搜索，刪除臨時表

oninit -y 　 對提示自動回答yes

oninit -v 加入這個選項顯示oninit處理過程

oninit-- 鍵入此命令可以獲得使用幫助

oninit命令用來改變系統的運行模式。其中-i選項用於初始化系統的root dbspace。注意，root-dbspace一旦被初始化，則等於整個數據庫系統被初始化。

如果用户希望在計算機啓動時自動自動啓動動態服務器系統，請在系統初啓文件（在許多UNIX系統中為/etc/rc）中加入oninit命令（不加任何選項）。

語法： onmode [-k] [-m] [-s] [-u] [-y]

onmode -k 　執行立即shutdown，將系統變為off-line模式

onmode -m 　將系統從quiescent模式變為on-line模式

onmode -s 　執行graceful shutdown

onmode -u 　 執行immediate shutdwon

onmode -y 　 對提示自動回答yes

onmode 命令同樣用於改變動態服務器的運行模式。除了上述選項外,onmode還有很多與改變系統運行模式無關的選項。

利用onspaces命令創建數據空間

語法： onspaces -c [-b] [-d] [-z] [-m] [-o] [-p] [-s] [-t]

-c 創建blobspace或dbspace

-b blobspace blobspace名

-d dbspace 　dbspace名

-g page size　 blobpages大小

-m mirror 　 鏡像設備設的全路徑名和偏移量（KB）

-o offset 　 偏移量（KB）

-p pathname 　 chunk設備的全路徑名

-s size　dbspace大小（KB）

-t　 創建臨時dbspace

onspaces命令用於創建數據空間、臨時空間和存儲blob數據的空間（blobspace）。鍵入onspaces--可以獲得該命令的聯機幫助。利用onstat -D或onstat -d可以看到系統中的關於數據空間的重要信息。包括：chunk的狀態、空閒、每一chunk讀寫的次數。系統中可能包括的多個系統空間，特別當進行數據分片後，我們建議用户最好能利用命令行來創建數據空間。

可以利用如下命令創建數據空間：

onspaces -c -d datadbs1 -o 0 -p /dev/rrvol3 -s 60000

可以用如下的方式創建臨時數據空間：

onspaces -c -d tempdbs1 -t -o 0 -p /dev/rrvol5 -s 80000

在系統中，臨時數據空間非常重要，通常情況下，應將多個臨時數據空間分佈在獨立的物理設備上。

增加或刪除chunks

語法： onspaces -a -d [-m] [-o] [-p]

-a spacename 　為dbspace新增chunk

-m pathname　鏡像設備的全路徑名和偏移量（KB）

-o offset 　 主設備的偏移量（KB）

-p pathname 　 chunk設備的全路徑名

-s size　chunk大小

-d spacename 　刪除chunk

-o offset 　 chunk設備的偏移量（KB）

onspaces不僅能創建數據空間還能刪除數據空間、臨時數據空間或存儲blob數據的空間。在刪除數據空間時，必須首先保證它是無用的，即該數據空間上無數據庫或表。

如需刪除數據空間，請鍵入如下命令：onspaces -d dbspace_name /blobspace_name

數據空間最初由一個chunk（first chunk）構成，一旦其空間用盡，用户必須追加chunk為了提高系統性能，用户在為數據空間分配chunk時需要計算以保證它的大小能適應未來的需要，否則在追加chunk的時候，它與先前的chunk在物理上不一定相鄰，導致增加讀取數據的時間。關於如何計算空間需求將在以後章節中闡述。利用onspaces命令可以對數據空間增加或者刪除chunk,除此之外，利用該命令還可以完成如下任務：啓動鏡像、中止鏡像或改變chunk的狀態。

例如可以用如下命令為數據空間增加chunk：

onspaces -a -d datadbs1 -0 60002 -p /dev/rrvol3 -s 60000

再如可以用如下方式從數據空間中刪除chunk：

onspaces -d datadbs1 -o 60002 -p /dev/rrvol3 -s 60000

onparams 命令語法：onparams -a -d -p [-d] [-s] [-l]

-a 　新增邏輯日誌

-d dbspace 指定日誌存放的dbspace

-s size 　 新增邏輯日誌的大小（KB）

-d 　刪除邏輯日誌

-l logid　 指定刪除一個邏輯日誌

-p 　改變物理日誌

-d dbspace 新物理日誌存放的dbspace名

-s size　物理日誌大小（KB）

系統在初始化時自動地在root dbspace中創建邏輯日誌和物理日誌。在DBMS系統中，尤其在OLTP環境下，數據庫的操作非常頻繁，日誌中必須記錄大量的信息，所以用户最好能將多個日誌文件分佈在不同的設備上。有一種非常簡單的方法： 即按所需大小創建邏輯日誌，同時創建一個較小的物理日誌，系統初始化完畢後，再將物理日誌移至其它設備。關於如何確定所需的物理日誌的大小，將在以後的章節詳述。 利用onstat -l命令可以看出系統中所有新增的邏輯日誌被標識為A。這些邏輯日誌只有在系統進行歸檔後才會真正被使用。為了激活這些邏輯日誌有一種簡單的方法：執行一次“偽”歸檔。具體步驟如下：將參數TAPEDEV設置為/dev/null然後運行一次ontape -s。也可以執行onbar -F命令。由於偽歸檔並不真正歸檔系統信息，所以千萬要適時地對系統進行真正的歸檔操作。

只有在邏輯日誌真正無用時才能將其刪除。利用onstat -l 可以看出所有的空閒日誌被標記為F。如果邏輯日誌中包含事務回滾或快速恢復所需的信息，該邏輯日誌是不能被刪除的。利用onstat -l命令可以看出接受當前事務的日誌被標記為C。如果邏輯日誌包括最後一個檢查點記錄，它也是不能被刪除的，只有當檢查點記錄被寫入下一個日誌忠並且上一個日誌被備份後，該日誌才能被刪除。利用onstat -l命令可以看出包含最後一個檢查點記錄的日誌被標記為L。用户可以利用onmode -c命令強制寫檢查點記錄直至最後一個檢查點記錄被寫入所要求的日誌為止。