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 }

最大緩衝區個數。

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

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 命令

語法： 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

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

利用onspaces命令刪除數據空間

增加或刪除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命令強制寫檢查點記錄直至最後一個檢查點記錄被寫入所要求的日誌為止。