裝備檔案,裝備檔案：Linux/UNIX.,效能器的裝備參數存儲在位于$INFORMIXDIR/etc目次的檔案中。,通過設定,ONCONFIG,環境變量可以指定檔案的稱号。不要指定完備的途徑，隻需
裝備檔案
裝備檔案：Linux/UNIX.
效能器的裝備參數存儲在位于 $INFORMIXDIR/etc 目次的檔案中。
通過設定
ONCONFIG
環境變量可以指定檔案的稱号。不要指定完備的途徑，隻需指定檔案名即可。
假若沒有定義
ONCONFIG
環境變量，将運用默許的檔案名 onconfig。
示例：
導出 ONCONFIG=onconfig.server1
裝備檔案包括很多不合的參數，準許您按照詳細需求裝備效能器。其中一些參數将在第一次啟動效能器時設定，第一次初始化效能器後，這些參數設定将不克不及改動。然則，大大大都參數可以在效能器初始化後禁止修改。
以下的裝備檔案參數必須在初始化效能器之前禁止裝備，這是由于根 dbspace 包括保管頁、效能器上全部資料庫的資訊和跟蹤效能器勾當的資料庫的資訊：
- 根 dbspace
- 舊事
- 效能器資訊
每個效能器必須具有一個根 dbspace。根 dbspace 在最後還包括實體和邏輯日記。然則，這些日記可以在稍後的工夫裡移至其他 dbspace。
清單 16. 裝備根 dbspaceROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/online_root # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (kilobytes)
ROOTSIZE 20000 # Size of root dbspace (kilobytes)
這些參數隻需在第一次初始化效能器之前才可以大要禁止修改。在初始化效能器時代，一旦為根 dbspace 分派了空間，就不克不及夠對這些參數禁止修改。
清單 17. 裝備舊事途徑
MSGPATH /usr/informix/online.log # System message log file path
CONSOLE /dev/console # System console message path
IDS Server 為效能器舊事供給了兩個不合的目的地：
-
MSGPATH
-
CONSOLE
清單 18. 裝備特定于效能器的資訊
SERVERNUM Unique id corresponding to an IDS server
DBSERVERNAME Name of default database server name
DBSERVERALIASES Names of additional database server names
必須設定這些參數，多麼手腕在托管較勁争論機上專一地辨別您的效能器。
日記資訊
清單 19. 裝備特定于日記的資訊
LOGBUFF Size in kilobytes for the three logical-log buffers in shared memory
LOGFILES Number of logical-log files
LOGSIZE Size of logical-log files
PHYSBUFF Amount of shared memory reserved for the buffers
PHYSFILE Size of the initial physical log
PHYSDBS Name of the dbspace in which the physical log resides
邏輯日記
邏輯日記檔案是磁盤上繼續的頁面聚集，用于存儲效能器的事情記錄。這些事情記錄運用日記設立建設，用于跟蹤對資料庫禁止的全部更動。全部的資料庫共享溝通的一組邏輯日記檔案。每個效能器必須具有至多三個邏輯日記檔案。
手工添加邏輯日記檔案由于以下緣由，您可以大要必要手工添加邏輯日記檔案：
- 添加分派給邏輯日記的磁盤空間
- 改動邏輯日記檔案的大大小
- 啟用開放的事情完善日記
- 将邏輯日記檔案挪動到不合的 dbspace
可以運用兩種方式添加邏輯日記檔案：
- 運用
onparams -a
-
onparams -a -i
下面的饬令在 logspace dbspace 中将邏輯日記檔案添加到了日記檔案清單的開頭，運用
LOGSIZE
裝備參數指定的日記檔案大大小：
onparams -a -d logspace 下面的饬令在 logspace dbspace 中将一個 1000KB 的邏輯日記檔案拔出到目前的日記檔案之後：
onparams -a -d logspace -s 1000 -i 要添加具有新大大小（本例為 250 KB）的邏輯日記檔案，執行以下饬令：
onparams -a -d logspace -s 250 可以運用下面的饬令删除邏輯日記檔案：
onparams -d -l lognum -y 通過下列應用挪動邏輯日記檔案：
- 從目前 dbspace 删除邏輯日記檔案
- 将邏輯日記檔案添加到新的 dbspace
偉大來講，管理幾多大大型日記檔案要比管理大大量較小的日記檔案苟且。較大大的日記空間不會影響功能。然則，缺乏足夠的日記檔案和日記空間将對功能爆發影響，由于資料庫效能器将因今生成頻繁的搜查點處理。blobspaces 中的智能大大對象不執行日記記錄，然則它們被包括在設立建設對象的日記備份中。這就是說，直到效能器對設立建設對象的日記禁止備份後，這些對象才被釋放。因而，假若 blobspace 中的智能大大對象被頻繁禁止更新，則可以大要必要更頻繁地禁止日記備份，以擷取 blobspace 内分外的閑暇空間。拼集生成小量日記資料的運用順序，起碼運用 10 個 10 MB 的日記檔案。拼集生成大大量日記資料的運用順序，起碼運用 10 個 100 MB 的日記檔案。
可以運用兩種方式維護恢停工夫目标（recovery time objective，RTO）戰略，該戰略可以确定在爆發劫難事情（比喻資料效能器丢丢失資料）時所能容忍的資料丢丢失量：
維護 RTO 戰略的一種方式是運用主動日記備份，該方式将在日記檔案寫滿後觸發日記備份應用。多麼可以在備份時代限制包括在日記檔案中的事情的資料丢丢失，以及備份時代爆發的其他事情的資料丢丢失。
維護 RTO 戰略的另一種方式是運用調節順序。您可以設立建設一個任務，該任務從上一次日記備份起每隔肯定工夫主動備份任何新的日記資料。這将限制每個時間隔斷内沒有備份的事情的資料丢丢失。本系列教程 的 第 2 部分 “零碎勾當看管” 引見了更多有關運用調節順序的資訊。
假若必要運用 RTO 戰略，則可以運用調節順序來拔出具有希冀的執行頻率的任務，進而維護戰略。這将在一般運轉周期中的特定工夫點主動備份日記檔案。在日記禁止備份和從新運用之前，應該先寫滿日記，您可以備份日記并添加新日記檔案使事情得以繼續處理，大要可以運用調節順序添加新的任務來檢察形态，并主動執行任何應用。
您可以随時添加日記檔案，而且在必要事情連接配接性的環境下，資料庫效能器将主動添加日記檔案（比喻，運用大大量日記空間而且繼續工夫較長的事情）。
添加邏輯日記的空間容量的最簡便的方式是再添加一個邏輯日記檔案。
下面的表達式供給了總的日記空間（total-log-space）的裝備示例，以千位元組為機關：
LOGSIZE = (((connections * maxrows) * rowsize) / 1024) / LOGFILES
實體日記
效能器具有一個用于主動恢複的非凡日記。該日記稱為實體日記。實體日記是磁盤上繼續頁面的聚集。
當頁面被讀取到共享記憶體緩沖區并由使用者修改後，該頁面在初始形态下的副本被寫入了實體日記。該副本被稱為前映象（before image），即修改前的頁面的副本。隻需在緩沖區中對頁面作出初度更動時才會将前映象寫入實體日記。任何後續更動并不會形成其他的前映象被寫入到實體日記。有一種主動恢複機制必要運用到這些前映象。
可以運用 onparams 移植實體日記的職位和大大小。
以下饬令将實體日記挪動到 dbspace dbspace1 并将其大大小從新設定為 3000KB：
onparams -p -d dbspace1 -s 3000 實體日記的大大小在
PHYSFILE
裝備參數中做了指定，它取決于兩個因素：
- 事情生成實體日記勾當的速度 —— 不論您能否設定了
RTO_SERVER_RESTART
- 能否運用
RTO_SERVER_RESTART
事情生成實體日記勾當的速度會影響搜查點功能。在搜查點處理時代，假若由于事情不時生成實體日記資料，實體日記開端變滿，資料效能器将壅閉事情，以完成搜查點處理并避免實體日記溢出。
要避免事情壅閉，資料庫效能器必須具有足夠的實體日記空間來包涵搜查點處理曆程中爆發的全部事情勾當。當實體日記抵達 75％ 的飽和時将觸發搜查點處理。必須在殘剩的 25％ 的實體日記被占用之前完成搜查點處理。隻需零碎檢測到可以大要爆發實體日記溢出時就會爆發事情壅閉，由于每個勾當事情都将生成實體日記勾當。
比喻說，假定您具有一個 1 GB 的實體日記和 1000 個勾當事情，這些事情可以大要會生成大約莫 80 MB 的實體日記勾當（假若全部事情同時處于臨界部分）。當運用了 750 MB 實體日記後，資料庫效能器将觸發搜查點處理。假若在搜查點完成之前，運用了 920 MB 實體日記，将爆發事情壅閉，而且要直到搜查點處理完成後才會破除壅閉。假若爆發了事情壅閉，效能器将主動觸發愈加頻繁的搜查點處理來避免事情壅閉。您可以禁用主動搜查點處理功用。
瞻望實體日記大大小的第二個因素在于能否運用
RTO_SERVER_RESTART
裝備參數指定了疾速恢複運用的目标工夫量。假若您不必要考慮疾速恢停工夫，就沒有必要運用
RTO_SERVER_RESTART
裝備參數。假若為
RTO_SERVER_RESTART
裝備參數指定了值，事情勾當将生成分外的實體日記勾當。
屢屢，分外的實體日記勾當對事情功能爆發的影響眇乎小哉，大要根蒂根基不會有影響。分外的日記行為用于在疾速恢複時代為緩沖池供給攙扶幫忙，多麼可以最優化執行日記重放。假若實體日記異常大大，超過了全部緩沖池的總的大大小，則在疾速恢複時代會爆發頁面重新整理（page flushing）和頁面妨礙。頁面重新整理和頁面妨礙告急降低了疾速恢複的功能，而且資料庫效能器不克不及維護
RTO_SERVER_RESTART
戰略。
拼集緩沖池容量小于 4 GB 的零碎來說，實體日記的大大小應該是全部緩沖池總大大小的 110％。拼集較大大的緩沖池，起碼要 4 GB 的實體日記空間，然後再看管搜查點的勾當。假若搜查點處理過火頻繁并将影響功能，則需添加實體日記的大大小。