informix常用故障处理操作
Informix错误代码中文解释转3
-101 ISAM错误：文件未打开。
ISAM处理器被要求使用一个未打开的文件(表)。
对C-ISAM程序，程序试图在调用isopen打开文件前使用该文件，或是试图写一个只读方式打开的文件。
如果错误再次出现，请参考INFORMIX-Online的“管理员指南”附录B，“陷井错误”以得到进一步诊断。
有关诊断信息请与Informix技术支持部联系。
-102 ISAM错误: 不合法的ISAM函数参数。
一个传递给C-ISAM函数的参数值超出了可接受的范围。
对C-ISAM程序，检查这个函数调用中使用的参数，并与该函数的文档比较。
如果错误再次出现，请参考INFORMIX- Online的“管理员指南”附录B，“陷井错误”以得到进一步诊断。
有关诊断信息请与Informix技术支持部联系。
-103 ISAM错误: 不合法的键描述符(部分过多或是太长)。
ISAM处理器被给予了一个无效的键描述符。
对C-ISAM程序，检查键描述符。
每个键描述符最多可以有8个部分和120个字符。
如果错误再次出现，请参考INFORMIX-Online 的“管理员指南”附录B，“陷井错误”以得到进一步诊断。
有关诊断信息请与Informix技术支持部联系。
-104 ISAM错误: 打开文件过多。
ISAM处理器已经到达了打开文件数的极限。
对C-ISAM程序，检查并改变程序逻辑使得它同时打开较少的文件。
使用isclose来关闭不需要的文件。
对SQL产品，这个查询过于复杂；它同时使用了过多的表。
分步执行查询并使用临时表。
-105 ISAM错误: 坏的ISAM文件格式。
一个ISAM文件(表或索引)的内容已被损坏。
对C-ISAM，如果已使用了事务日志，你可以用isrecover程序来恢复该文件。
否则，重新建立或是从备份上恢复该文件。
对SQL 产品，使用bcheck或secheck实用工具来获取有关此问题的进一步信息，可能的话改正错误(在INFORMIX-OnLine数据库服务器中使用tbcheck或是在INFORMIX-OnLine动态服务器中使用oncheck)。
Informix数据库常用命令介绍
华为产品维护资料汇编 TELLIN智能网维护资料数据库基础知识目录目录第1章 Informix数据库常用命令介绍 (1)1.1 概述 (1)1.1.1 oninit (1)1.1.2 dbexport (2)1.1.3 dbimport (4)1.1.4 dbload (5)1.1.5 dbschema (7)1.1.6 oncheck (8)1.1.7 onload (9)1.1.8 onlog (10)1.1.9 onmode (11)1.1.10 onparams (13)1.1.11 onspaces (13)1.1.12 onstat (14)1.1.13 ontape (19)1.1.14 onunload (21)第1章 Informix数据库常用命令介绍1.1 概述Informix数据库服务器提供了在shell提示符下直接执行管理任务功能的应用程序。
列出这些应用程序：表1-1提示符下直接执行管理任务功能的应用程序以下对这些应用程序逐一简要说明。
1.1.2 oninit1. 功能说明oninit 应用程序用于改变系统的运行模式。
数据库有六种工作模式，它们是：离线（off-line）不运行状态●静模式（quiescent）在此模式下，用户不能连接到数据库，但可用onstat等命令查看数据库信息●在线（on-line）数据库运行状态●只读（read-only）只能读数据库但不能写●恢复（recovery）是一种临时状态，存在于从离线模式到静模式之间●关闭（shutdown）是一种临时状态，存在于从在线模式到静模式或离线模式oninit命令将在离线（off-line）状态的数据库启动为在线（on-line）模式，并初始化共享内存（shared memory），在作初始化之前，应先设置环境变量INFORMIXSERVER，否则数据库不建立sysmaster表，必须以root或informix注册才能执行本命令，本命令不但能初始化共享内存，还能初始化磁盘空间。
常用告警说明诺西
常用告警说明诺西诺西是一款广泛使用的告警系统，帮助企业实时监控和管理各种运行时异常和故障。
本文将介绍一些常见的告警类型以及相应的解决方案，以帮助用户更好地理解和处理诺西告警。
一、服务器宕机告警当服务器宕机时，会触发服务器宕机告警。
这可能是由于硬件故障、网络故障或者服务器过载等原因导致的。
处理服务器宕机告警的解决方案如下：1. 检查服务器硬件：首先需要确认服务器是否存在硬件故障。
可以检查服务器的电源、硬盘、内存等组件是否正常。
2. 检查网络连接：如果服务器宕机是由于网络故障导致的，需要检查网络连接是否正常。
可以尝试重新连接网络或者检查网络设备是否工作正常。
3. 调整服务器负载：如果服务器宕机是由于过载导致的，可以尝试通过减少服务器负载来解决。
例如，优化代码、增加服务器资源等。
二、磁盘空间告警磁盘空间告警是指服务器磁盘空间不足导致的告警。
这可能是由于长时间未清理无用文件、磁盘写入速度过快等原因导致的。
处理磁盘空间告警的解决方案如下：1. 清理无用文件：可以通过删除无用的日志文件、临时文件等来释放磁盘空间。
2. 增加磁盘容量：如果磁盘空间经常不足，可以考虑增加服务器的磁盘容量。
3. 优化磁盘写入速度：如果磁盘空间告警是由于磁盘写入速度过快导致的，可以尝试优化代码，减少磁盘写入次数。
三、CPU负载告警CPU负载告警是指服务器CPU负载过高导致的告警。
这可能是由于程序运行过多、代码不优化等原因导致的。
处理CPU负载告警的解决方案如下：1. 优化代码：可以通过优化代码、减少CPU消耗来降低CPU负载。
例如，减少循环次数、合并重复代码等。
2. 增加服务器资源：如果CPU负载经常超过服务器承受范围，可以考虑增加服务器资源。
例如，增加CPU核心数、内存容量等。
3. 分离任务：如果程序运行过多导致CPU负载过高，可以尝试将任务分离到多台服务器上进行处理，从而分担负载。
四、网络连接异常告警网络连接异常告警是指服务器与外部网络连接不稳定或者中断导致的告警。
Informix数据库维护及应急手册
北京国际会议中心东配楼二层邮政编码：100101电话：800-810-1818转5266Informix数据库维护及应急手册前言本手册适用于Informix数据库系统，用于数据库管理及使用人员对数据库的日常维护、数据库异常情况初步诊断及应急处理。
如何拨打800免费支持热线IBM Informix 数据库技术支持中心开通有免费支持热线8008101818转5266，周一至周五早8：30到晚5：00为普通热线支持时间，其他的为24*7服务支持时间（包括节假日和公休日，具体安排依据IBM公司人力资源部的公布为准）。
当发现数据库有任何异常现象时，请根据本手册中“数据库异常情况初步诊断方法”中的内容进行初步判断，如果判定为与数据库相关的问题，请保留好现场（保留现场的方法请根据本手册的“如何保留现场”执行），并请提前准备好如下的信息，以支持IBM Informix 支持中心的工程师能更快更有效分析解决问题：1、数据库的版本序列号IBM Informix 的版本序列号S/N形如AAD#J123456，在产品包上可以找到，如果无法确认，也可在命令行状态下（$）敲入命令onstat –V来获得。
例如：Informix Dynamic Server Version 9.21.HC7 Software Serial Number AAD#J1234562、数据库的版本信息操作步骤与1同，其中9.21HC7为版本信息。
3、操作系统平台和版本信息该信息可通过敲入命令uname –a来获得。
4、数据库信息日志的内容如果已知信息日志的位置（通常称为online.log文件），则可忽略下面的步骤（1）至（5）。
(1) 以informix用户登陆进入IBM Informix数据库；(2) 在命令行状态下（$）敲入env|grep INFORMIXDIR，找出INFORMIXDIR所对应的值，例如：INFORMIXDIR=/informix；(3) 在命令行状态下（$）敲入env|grep ONCONFIG，找出ONCONFIG所对应的值，例如：ONCONFIG=onconfig.bill;北京国际会议中心东配楼二层邮政编码：100101电话：800-810-1818转5266 此例中，onconfig,bill为数据库配置文件。
INFORMIX-OnLine故障诊断与排除
INFORMIX-OnLine故障诊断与排除（1）－系统不能进入静态方式---摘自互联网开放系统以其无与伦比的能力连接不同的计算机软件，硬件。
在这种环境下，诊断问题时就需要关注问题的全局与细节。
本文就如果诊断INFORMIX-Online的问题给出了良好的建议。
诊断问题的症状系统管理员诊断问题时首先要定义问题的症状。
•系统是否难于进入静态（quiescent)状态？•是否有非正常结束的INFORMIX系统进程？•系统进程是否定期挂起？下面的讨论指出如何定位系统问题，讨论可能的起因，并对这些问题的解决提出建议。
系统不能进入静态方式该症状常常伴有一条错误信息。
一般错误是：tbinit:fatal error in shared memory creation (共享内存生成时有严重错误）检查系统初始化时定义的系统日志文件来发现错误的出处。
该日志的缺省名为$INFORMIXDIR/online.log。
在此文件中会看到与下面相近的信息：16:00:56 Cannot Open Primary Chunk '/dev/turbo_root',errno = 1316:00:56 Cannot Open Primary Chunk '/dev/turbo_root',errno = 1316:00:56 I/O error,Primary Chunk 'dev/turbo_root' -- Offline16:00:56 I/O lseek() chunk 1,pagenum 0, pagecnt 1 -->errno =916:00:56 INFORMIX-Online Stopped这些错误是由UNIX权限问题造成的。
OnLine产品需要由root来安装。
系统的部分可执行程序应属于root 或者root有权限。
所有INFORMIX系统文件的属主及权限都应该记录在$INFORMIXDIR/etc/onlinefiles中。
Informix常见错误处理方法思路
长事务
• 故障处理： 根据数据库日志里面所提供的信息可以很方便的发现具体是哪一个事务造 成了长事务。系统在将某个事务判定为长事务以后就会自动对其进行回滚 操作。事后可以有针对性的调整应用将大的事务划分为小事务进行提交； 避免一个活动事务长时间没有后续的操作；提供充足的逻辑日志空间，这 里所指出的不仅是空间的总量需要增加，逻辑日志的个数也是应该增加的 ，因为判断的标准是以逻辑日志的使用个数所占比例来确定的。在 INFORMIX 9.3X 以后的版本中可以通过动态增加逻辑日志的手段避免由于 长事务带来的一些不良影响，在长事务回滚过程中如果逻辑日志空间被消 耗完毕，如果 DYNAMIC_LOGS 设置为 2，数据库服务器会自动在最后创 建的逻辑日志所存在的 dbspace 上查找空余空间，按照最后创建的逻辑日 志的大小自动在当前逻辑日志之后新增逻辑日志，如果不能满足需要则会 创建失败，需要管理员手工添加。
Update Statistics的作用
为了提高数据库的效率，INFORMIX提供了一个基于成本的查 询优化器， 执行update statistics语句的作用就是将您创建的数据库 表的有关统计信息更新到系统sysmaster的相关表中，以便查询优化 器选择最佳的执行路径。当sysmaster库中没有相应的统计信息，或 者统计信息不十分准确时，优化器便无法制定一个行之有效的查 询策略，其结果必然是进行大量极其可怕的顺序扫描，产生严重 的性能问题。
address
number flags uniqid begin
size used %used
(注：红色部分为异常状态，如绿色部分也被使用完，数据库将出现异常。版 面上只显示出该店出现异常时用onstat –l监控到的部分信息。)
逻辑日志满
Informix数据库性能常见问题典型情况浅析
Informix数据库性能常见问题典型情况浅析张生成(酒泉职业技术学院，甘肃酒泉735000)摘要：数据库配置安装完成投入运行后。
数据库运行的性能就成为数据库管理人员(DBA)的一个重要任务。
根据教学过程中对Informix数据库的使用，总结出了一些常见性问题的处理经验，希望能和大家共同交流。
关键词：日常信息；处理思路；代价信息TP311.13：A：1672-7800(2010)04-0169-021平时的信息收集和维护工作为了更好地处理可能出现的性能问题，需要在乎时就注意积累操作系统、数据库的日常运行信息，这样可以了解系统的运行特点和基本负荷变化情况，当数据库出现性能问题的时候，这些都是非常有用的信息。
收集Infonxix数据库的日常信息，最简单的可以仅观察onstat-p的输出结果，和数据库性能相关的主要是读缓存率（第一个%cached）、写缓存率(第二个%cached)、顺序扫描数(seqscans)。
读缓存率不应该低于90%，否则就应该关注顺序扫描数，找出经常被顺序扫描的大表，创建相应索引或修改应用SQL，必要时还需要增加数据库BUFFERS。
写缓存率通常不应该低于85%，不过由于受到应用写库的方式和LRU设置的影响，稍微低一些也可以接受。
数据库日志中记录的检查点持续时间(checkpoint durationtime)也需要关注，性能良好的实例中，该值不超过3秒。
在日常维护时，注意定期收集数据库的统计信息(update statistics)，如果担心库太大，在业务空闲期间无法完成，至少应该对变化比较频繁的大表针对索引中的第一个字段收集统计信息，语法：update statistics for table mytab(coll);当性能问题出现后，可以按如下步骤来定位问题：首先应该利用操作系统命令查看一下当时操作系统状态：CPU/IO/SWAP，是否和平时差别很大；查看操作系统日志是否最近有异常报错；检查数据库日志，看看是否有断言错误(Assert Failed)，是否有数据库内部错误发生，数据库的检查点持续时间相比平常是否有显著增加。
informix基本操作详
oninit应用程序用于改变系统的运营模式。
informix数据库有六种模式:1：off_line：不运行状态2：Quiescent：静模式。
在此模式下用户不能连接到数据库，但是可用onstat 等命令查询数据库信息。
主要用于对系统进行底层维护操作。
3：on_line：运行状态4：read-only：只读模式5：recovery：恢复模式。
是一种临时状态，存在于从离线模式到静模式之间。
6：shutdown：关闭模式。
是一种临时状态，存在于从在线模式到静模式或者离线模式之间。
oninit -ipsvy-i ：初始化数据库，包括磁盘空间，该参数只在安装完成之后做一次。
只会保留onconfig文件配置的初始化信息，其它全部消失。
-p：当数据库不正常宕机后，数据库中会保留临时表，这些表会占据一定的磁盘空间，一般在重启数据库的时候，数据库会自动删除临时表数据的，如果加上这个参数，则会继续保留这些数据。
-s：数据库启动至静模式，做维护工作，不受其它用户的干扰-v：正常启动数据库，并显示启动的过程信息-y：关闭交互式提示，自动选择yes。
-j：启动informix进入单用户状态。
（informix 11 之后版本）onmod e 应用程序提供以下功能：1：改变online的工作模式2：强制生成检查点3：立即改变该会话过程中online共享内存的驻留空间4：转换逻辑日志文件5：撤销online的数据库服务进程6：撤销online的事物只有注册为root或informix的用户才能执行onmode参数：-a ：increase shared memory segment size。
增加共享内存大小-BC [1|2] ：change server large chunk mode。
支持大chunk模式-c [block|unblock] ：do checkpoint Block or Unblock。
设置检测点-b <version> ：Revert Dynamic Server disk structures。
Informix查看死锁和解锁
1：$ onstat -k | grep HDR+X
获得sessid，其中HDR+X 为排他锁，HDR 头，X 互斥 ，sessid 是会话标识符编号。
) 查看锁级别
#oncheck –pt database_name:table_name
)设置锁级别（行方式）
#alter table table_name lock mode(row)
)设置隔离级别
#set isolation to dirty read
)设置等待解锁时间（不宜过大）
中间件全局事务锁问题中间件与informix连接时会出现onstat -k 中 owner 内容为0的现象。这是应该查看全局事务onstat -x 和onstat -GDATABASE sysmaster;select hex(tx_addr) trans_addr,hex(tx_lklist) lock_addr from systrans
onstat -k 的owner 列中的地址与onstat -x 中的userthread 对应。
2：$ onstat -g ses sessid
根据sessid得到进程pid，其中pid 是与此会话的前端关联的进程标识。
（可通过$ onstat -g sql sessid 命令查看执行的sql语句）
3：$ ps -ef |grep pid
由此，我们可得到锁表的进程，可根据实际锁表进程的重要程பைடு நூலகம்的具体情况采取相映处理方法：
Could not do a physical-order read to fetch next row.
具体错误解释：
#finderr -244
原因：
Informix常用操作方法命令
Informix常用操作方法北京先进数通信息技术有限公司编写说明标题：Informix常用操作方法类别：〔文档类别〕（文档/管理/纪要/制度/资料）存放位置：请键入完整文档路径\请键入完整文档名称编辑软件：Microsoft Word XP 中文版版本历史：目录编写说明 (1)目录 (I)1. 相关文件 (1)2. 常用环境变量 (1)3. 数据库状态操作 (2)3.1.查看数据库状态 (2)3.2.启动O N L INE (2)3.3.关闭O N L INE (3)4. DBACCESS使用 (3)4.1.数据库操作 (3)4.2.编辑执行SQL语句 (3)5. 装数/卸数 (4)6. 策略优化 (4)7. 脏读 (4)8. 增加事务 (4)9. ONSTAT用法 (5)1.相关文件●informix配置文件：informix配置文件定义数据库的各种参数设置，通过环境变量$ONCONFIG指定，存放在informix用户的etc目录下，如$ONCONFIG=onconfig.cmq，则配置文件为$INFORMIXDIR/etc/onconfig.cmq；●informix日志文件：记录对数据库的操作，以及操作过程中的错误日志等信息，存放在$INFORMIXDIR目录下，文件名为online.log，如对数据库操作出现异常，可查看该文件定位错误原因；●数据库连接文件：连接文件sqlhosts所含的信息使用户可以连接到数据库服务器上，存放在$INFORMIXDIR/etc目录下，一行为一条配置信息，每条包含四个域：【数据库服务器名】：定义数据库服务器名称，如on_compaq_tcp；【连接类型】：如ontlitcp；【主机名】：在/etc/hosts中定义，或直接写主机的IP；【服务名称】：在/etc/services中定义，或直接写端口号；2.常用环境变量●INFORMIXDIR：informix用户安装路径，如INFORMIXDIR=/usr/informix；●INFORMIXSERVER：informix数据库服务器名，如INFORMIXSERVER=on_compaq，数据库服务器名在数据库连接文件sqlhosts中指定；●ONCONFIG：informix配置文件，如ONCONFIG=onconfig.cmq，该文件存放在$INFORMIXDIR/etc目录下。
Informix培训教材整理之系统维护技巧谈
Informix培训教材整理之系统维护技巧谈Informix是一种大型的数据库管理系统，具有先进的技术、性能与可靠性，在全球范围的各种应用中使用十分广泛，包括政府、金融保险、邮政电信、制造及零售等重要行业或领域。
本文根据笔者在SCOUnix／Xenix上使用Informix－4GL与Informix－SQL的经验，简要介绍Informix系统维护中的几个较为特殊的问题及其处理方法。
表文件的修复：Informix的数据库是指由若干张表所构成的集合，其中每一张表对应着两个文件，即数据文件(后缀为.dat)与索引文件(后缀为.idx)。
当系统出现异常、死机、掉电或非正常关闭时，有时会使一些使用中的表文件未能正常关闭而出现毁损，当系统再次对这些表进行相关操作时，就会报告“不能检索下一条记录”、“不能删除记录”等错误信息。
通常，数据文件是很少发生问题的。
要判别数据文件是否正常，只需执行select ＊ from 〈table—name〉语句或类似的语句即可，但不能使用where、order by等子句，以免利用到索引文件，目的就是纯粹从数据文件中依次读取数据。
如果数据读取顺利且记录个数正确，表明该文件完好无损；反之，则有问题，通常只能用其数据备份来恢复。
如果数据文件正确无误，那么就该检查相应的索引文件。
Informix提供有一个实用程序bcheck，专门用来检查与修复索引文件，即依次比较数据文件与索引文件，倘若不一致，就询问是否删除和重建有问题的索引。
bcheck有许多选项可供选用，其中－n和－y用于对所有的提问都回答“no”或“yes”，让系统自动进行一系列的操作。
其语法如下：bcheck[选项] 〈表文件名〉要检查表的索引文件，应先运行bcheck－n命令。
如果一切正常，说明索引没有问题。
一旦发现有错误报告（如有多少个错误数据记录指针、丢失了多少个数据记录指针或索引结点指针等），则再执行bcheck－y 命令即可将其修复。
INFORMIX-OnLine故障诊断与排除
INFORMIX-OnLine故障诊断与排除（1）－系统不能进入静态方式---摘自互联网开放系统以其无与伦比的能力连接不同的计算机软件，硬件。
在这种环境下，诊断问题时就需要关注问题的全局与细节。
本文就如果诊断INFORMIX-Online的问题给出了良好的建议。
诊断问题的症状系统管理员诊断问题时首先要定义问题的症状。
•系统是否难于进入静态（quiescent)状态？•是否有非正常结束的INFORMIX系统进程？•系统进程是否定期挂起？下面的讨论指出如何定位系统问题，讨论可能的起因，并对这些问题的解决提出建议。
系统不能进入静态方式该症状常常伴有一条错误信息。
一般错误是：tbinit:fatal error in shared memory creation (共享内存生成时有严重错误）检查系统初始化时定义的系统日志文件来发现错误的出处。
该日志的缺省名为$INFORMIXDIR/online.log。
在此文件中会看到与下面相近的信息：16:00:56 Cannot Open Primary Chunk '/dev/turbo_root',errno = 1316:00:56 Cannot Open Primary Chunk '/dev/turbo_root',errno = 1316:00:56 I/O error,Primary Chunk 'dev/turbo_root' -- Offline16:00:56 I/O lseek() chunk 1,pagenum 0, pagecnt 1 -->errno =916:00:56 INFORMIX-Online Stopped这些错误是由UNIX权限问题造成的。
OnLine产品需要由root来安装。
系统的部分可执行程序应属于root 或者root有权限。
所有INFORMIX系统文件的属主及权限都应该记录在$INFORMIXDIR/etc/onlinefiles中。
informix的使用技巧
安装数据库管理实用程序IDS联网内核配置参数备份策略从sysmaster或者sysutils实例中监控备份小技巧影响CPU使用率的配置参数常用指令用法说明数据复制技术如何监控IDSIDS数据库维护技巧informix的用户权限管理基本概念安装数据库：1．配置informix安装空间：1G左右，用来存放数据库的安装文件，一般是/Informix2．创建informix用户和用户组3．对informix软件进行解包，有以下几种方法：cpio –icvdumB < /mnt/cdrom/*.cpirpm –iv –prefix $INFORMIXDIR /mnt/cdrom/*.rpmtar –xvfb 20 /mnt/cdrom/*.tar4．配置informix安装环境变量：INFORMIXDIR=/informixPATH=$INFORMIXDIR/bin:$PATHINFORMIXSERVER=szxaONCONFIG=onconfig.SZXATERMCAP=$INFORMIXDIR/etc/termcapTERM=vt1005．安装informix软件（用informix用户）/Informix/installserver安装完成后，会提示用root用户运行/Informix/RUN_AS_ROOT.server至今，informix软件安装完毕6．阅读版本说明：/$INFORMIXDIR/release/en_us/03337．配置/etc/services文件：Service_name port/protocol alias例如：sqlexecA 1526/tcp # SZXA informix database usesqlexecB 1527/tcp # SZXB informix database use8．配置sqlhosts文件：dbservername nettype hostname service_name例如：szxa onsoctcp S1_C_SZX_SHUJUKU 1526dbserver_name 网络接口协议主机服务别名注意，系统使用的网络接口类型，可以从版本说明文件获得9．生成磁盘存储：一般使用裸设备，并生成磁盘设备的链接，这样，如果磁盘设备失败，也可以把链接改变成指向可操作的磁盘ln -s /dev/rrootdbs /Informix/data/rootdbs10．配置onconfig文件：（第一次初始化只是针对于rootdbs，参数配置可以相对简单）ROOTOFFSET –指定KB数，确定在原始设备中移动多长距离之后再生成根dbspace PHYSFILE –第一次初始化，设置临时值2048，LOGFILES –第一次初始化，设置临时值3LOGSIZE –第一次初始化，设置临时值500TAPEDEV（存档），LTAPEDEV（日志存档）-- /dev/null，这样就可以运行档案程序ontape而不实际把数据写入磁带中SERVERNUM –运行多个服务器时确定服务器的共享内存地址，唯一值DBSERVERNAME –应该与sqlhosts文件中的项目相符DBSPACE TEMP –可以有多个dbspace组成，这样，每个排序操作就会平均分配在每个tempdbspace中进行DEADLOCK_TIMEOUT –等待多长时间确认某操作遭遇死锁NETTYPE –可选参数，配置如下协议类型轮询线程数每个轮询希望的并发连结数处理器类例如：soctcp,2,150,NETRESIDENT –驻留系统物理内存与否NUMCPUVPS –指定对实例启动的CPU类虚拟处理器个数，按照处理器的个数而定可以用onstat –g glo进行调整SINGLE_CPU_VP –指定服务器不运行多个CPU虚拟处理器，设置为true(1)使服务器跳过管理锁存资源的大部分代码，从而提高性能LOCKS –服务器对服务器线程分配的最大锁数，用onstat –p监控状态，如果ovlocks一直大于0，需要增加实例所用的锁数BUFFERS –定义实例分配的缓冲区数，检查onstat –p输出的缓冲读和缓冲写，调整该参数使这些值最大化CLEANERS –指定所需的页面清理线程数，用于把数据从共享内存写入磁盘。
informix常用故障处理操作
Informix 计算长事务回滚时间及解决办法如何估算长事务回滚的时间环境:IDS9.40及其以上版本问题描述:用户往往由于一次操作的数据量过大，导致长事务，使整个数据库服务器暂时挂起而不可用。
用户需要估算长事务回滚完成的时间，以便做出安排。
解答:可以使用onstat -x -r 10监控该事务的回滚状态.并通过日志回滚的速率来估算回滚的时间。
“-r 10”表示每10秒显示一次。
下面是两次的间隔10秒输出：address flags userthread locks beginlg curlog logposit isol retrys coordd745b58 A-R-- d715e7c 4904 51 53 0x8f61c8 COMMIT 0address flags userthread locks beginlg curlog logposit isol retrys coordd745b58 A-R-- d715e7c 4904 51 53 0x5a1acc COMMIT 0从输出可以看到，该事务起始的逻辑日志号是51，当前回滚到53，还需要继续回滚2个逻辑日志。
在这10秒中回滚的逻辑日志大小可以通过两次的logposit相减得出，方法为：去掉每个logposit的后三位，剩下的数字相减就是日志回滚的page数目，再乘以page size 就可得到这10秒回滚的日志大小。
例如：（0x8f6 - 0x5a1）*4 = 3412 K (4表示当前系统的page size是4K),那么一分钟逻辑日志能够回滚 3412/10*60=20472 K假设每个逻辑日志的大小为50M，则该长事务还需要回滚的时间大约是5.28分钟(（1024*50) * 2 + 0x5a1*4)/20472 =5.28一、查看数据库状态正常情况下是onstat -IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line -- Up 35 days 16:51:16 -- 3920896 Kbytes长事务情况下是onstat -IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:40 -- 3920896 KbytesBlocked:LONGTX二、显示事务（transaction）信息其中flag字段中第三个标志位为R说明事务在rollback，说明这个事务是长事务onstat -xIBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:56 -- 3920896 KbytesBlocked:LONGTXTransactions1cf0a6748 A-R-- 1cd55c618 642073 119403 119405 0x1aa91e4 DIRTY 0三、通过长事务的userthread值找出session idonstat -u |grep 1cd55c6181cd55c618 --RPX-- 1880841 informix - 0 0 642073 256446 323049四、显示会话连接信息，找出造成长事务的SQL语句，并优化onstat -g ses 1880841informix锁表处理步骤：锁表处理步骤：1、onstat -ks|grep HDR+X //查询是那个表被锁address wtlist owner lklist type tblsnum rowid key#/bsizc1809510 0 d656e774 c181cb3c HDR+X 6002e1 2c602 0需要关注lklist和type项，从上面来看tblsnum为6002e1（十六进制转换成十进制）的表被锁了。
informix-4gl常见错误
Informix-4gl编程过程中常见错误Informix -244 错误:Could not do a physical-order read to fetch next row.具体错误解释：#finderr -244原因：a.锁表b.记录太多c.页损坏d.某个进程死了以后资源未释放导致在数据库端用 onstat –g ses/onstat –g sql /Onstat –k 等找出锁表进程，用onmode –z结束该进程，不行，重启数据库释放。
锁方式：行方式（row），页方式（默认page），表方式(table)。
解决：1．降低锁级别2．减少加锁事务的时间跨度3．设置等待解琐时间相关命令：）检查索引及页损坏情况#oncheck –cID database_name:table_name) 查看锁级别#oncheck –pt database_name:table_name)设置锁级别（行方式）#alter table table_name lock mode(row))设置隔离级别#set isolation to dirty read)设置等待解锁时间（不宜过大）#set lock mode to wait second(秒)不等待#set lock mode to not wait1：$ onstat -k | grep HDR+XHDR+X 为排他锁HDR 头X 互斥owner是正持有锁的线程的共享内存地址2：$ onstat -u |grep c60a363cc60a363c 为1中查到的owner内容。
sessid是会话标识符编号3：$ onstat -g ses sessid根据sessid得到进程pidpid与此会话的前端关联的进程标识$ onstat -g sql sessid通过上面命令查看执行的sql语句4：$ ps -ef |grep pid由此，我们可得到锁表的进程，可根据实际锁表进程的重要程度的具体情况采取相映处理方法：对于重要且该进程可以自动重联数据库的进程，可以用onmode -z sesid 的方法杀掉锁表session，$ onmode –z sessid否则也可直接杀掉锁表的进程kill pid。
informix数据库的操作和维护
informix数据库的操作和维护INFORMIX数据库的常用管理命令约定命令行中，<>括起来的内容不是实际要键入的内容，而是要键入的内容的说明。
命令行中，[]括起来的内容表示是可选项。
命令行中，a | b表示a或b选其中之一，为消除二义性，有时也用{a | b }表示。
命令行尾的\表示由于排版的限制一行写不下换到下一行，实际输入时可以不换行。
/* */括起来的斜体字表示注释。
1.简介INFORMIX-OnLine Dynamic Server（以下简称OnLine）提供了一个字符窗口界面的集成管理工具onmonitor，通过它可以完成除了数据备份外的大部分常用管理任务。
同时，OnLine还提供了一整套命令行管理工具，常用的有以下这些：命令功能oninit 启动OnLineonmode 改变模式和共享内存onstat 通过共享内存结构监视OnLine的操作状态oncheck 检查、修复、显示OnLine的磁盘结构ondblog 改变database的log方式onparams 修改逻辑和物理日志的配置参数onspaces 修改blobspace和dbspace的配置ontape 数据库备份和恢复工具onarchive 比ontape功能更强的备份和恢复工具dbexport 将整个database备份成文本文件格式dbimport 用文本文件格式的database备份重建databasedbschema 显示数据库、表的结构dbaccess 字符窗口界面的交互式SQL命令执行环境严格来说，最后四个命令不属于管理工具，但是因为在进行数据库管理时经常用到，所以也在此列出。
2.权限在Informix中，用户root和informix拥有最高的权限，可以执行所有的管理命令，可以查看所有database中的数据。
其次是属于informix组的用户，它们可以执行数据库server的启动和关闭等重要的管理命令。
Informix数据库系统维护及双机HDR疑难问题详解
Informix数据库疑难问题解答目录1、数据库日志模式 (3)No Logging 没有日志 (3)Unbuffered Logging 非缓冲日志 (3)Buffered Logging 缓冲日志 (4)Unbuffered Logging, Mode ANSI ANSI模式 (4)如何改变日志模式 (4)用onmonitor改变日志模式 (4)用ontpae改变日志模式 (4)2、如何在HDR系统中修改参数配子文件（onconfig）？ (5)3、在select的时候，where条件是不是有限制？ (6)4、关于INFORMIX的运行负荷进行度量的问题 (6)5、informix数据库主备切换的解决方法 (7)问题描述 (7)问题分析 (7)解决方案1（首推方案） (8)解决方案2 (8)故障解决 (9)6、数据库（OnLine）的启动和关闭 (9)7、数据库（OnLine）的状态查询 (10)8、数据库（OnLine）的空间管理 (11)9、数据库（OnLine）的日志管理 (12)数据库日志方式 (12)可使用ontape命令修改数据库日志方式 (12)物理日志的管理 (12)逻辑日志的管理 (13)10、如何查看informix的错误号 (13)11、数据库系统日常监测 (14)1查看锁的信息 (14)2查看物理和逻辑日志状态 (14)3查看一些统计信息 (14)4查看数据库系统占用共享内存的情况 (14)5 查看各chunk文件的读写量和读写率 (14)6 数据库目录结构检查 (14)7 数据库索引结构检查 (14)8 数据库数据结构检查 (15)9 查看数据库锁方法 (15)10查找造成长事务的SQL (15)11检查大表和对大表的维护 (16)1、数据库日志模式问：一般informix做了双机，那么scp的数据库log用什么方式比较好啊？一种是直接用log，一种用buffer log。
informix错误代码及解决方案
更正的方法：删除非法字符（通常为不可打印的控制字符）或重写语句。
-203 错误的描述：在语句中发现非法整数
系统的操作：包含的错误语句不被处理。
更正的方法：整数必须在-2,147，483，647到2,147，483，647之间。检查是否带有小数部分或超出值域，以及数字中是否含有字母（例如：12593代替了125b3）。
-222 错误的描述：不能新表table-name的临时文件中写信息。
系统的操作：含有错误的语句不被处理。
更正的方法：盘空间可能溢出。检查C—ISAM错误信息以找出问题的原因。
-223 错误的描述：在FROM子句中出现重复的表名table-name。
系统的操作：含有错误的语句不被处理。
-106 错误的描述：C—ISAM错误；非互斥访问。
系统的操作：该语句不被处理。
更正的方法：当要增加或删除一个索引时，必须以互斥访问打开文件。
-107 错误的描述：C—ISAM错误：记录被锁住。
系统的操作：该语句不被处理。
更正的方法：由该调用请求的文件或记录不能被访问，这是因为该文件被其它用户锁住。请稍等一会儿，再提出请求。
-118 错误的描述：不能读事务日志记录。
系统的操作：包含的错误语句不被处理。
更正的方法：运行dblog程序确定哪个记录有问题
-119 错误的描述：不能打开日志文件。
系统的操作：包含的错误语句不被处理。
更正的方法：确定文件是否存在，所使用的路径名是否正确，以及是否具有使用文件适当权限。
系统的操作：包含的错误语句不被处理。
更正的方法：检查数据库管理转换内存空间
-124 错误的描述：没有找到BEGIN WORK。
处理Informix故障偶得
ｄｒ ｐ ｉ ｄ ｘ ｕｐ ｔ ｓ ｄｌ ｏ ｎ ｅ ｉｍａ ｊｎ ；
ｄｅｌ ｅ ｆ ｏｍ ｅｔ ｒ ｕｐｉｍ ａ ｈｅｒ ａ ｕｓ＝ ”１ ： ｔ ｓｗ ｅ ｓｔ ｔ ”
由此 可 知 ，此 程 序 首 先卸 下 数 据 库 表 ｕ ｉ ｓ ｐｔ ｍａ
中 ｓａｕ ｔｔｓ为 １的 记 录 ， 后 删 除 一 些 记 录 ， 删 除 记 然 在
（ ）给 ｕ ｉ ｓ建 索 引 ； ７ ｐｔ ｍａ （ ８）执 行 ｓ ｈ命 令 ：ｎａ ｅ —Ｓ —Ｕ ｐ ｂ ｄ ｏ ｔｐ ｃｃｂ
设 定 ｐ ｂ ｄ 的 日 志 模 式 （ｏ ｇｎ ｄ ）为 Ｄ － ｃｃｂ １ｇ ｉｇｍｏ ｅ Ｒ
ｂｕ ｅｒ ｆ ｅｄ ｏｇｇｉ ｌ ｎｇ；
录 之 前 ， 先 删 除 了 此 表 的 索 引 。 我 们 认 为 这 一 点 首
（ ６）从 ｕ ｉ ｓｂ 中 取 记 录 插 入 ｕ ｉ ｓ ｐｔ ＿ ｍａ ＿ ｐｔ ： ｍａ
ｕ ｏｄｔ ｌ ｎ ａ ｏ￥ ｛ ａ ｈ｝ ｕ ｉ ｓ Ｐ Ｐ ｔ ｐ ｔ ￥ ＹＹ ｅｅ ｔ ， ｒ ｍ ｍａ ｓ ｌｃ Ｉ ｏ ｃ ｆ
ｕｐｉｍ ａｓ ｗ ｈｅｒ ｓ ａ ｕｓ＝ ”１ ： ｔ ｅ ｔｔ ”
０ｍ 。
右 ，为 此 ，我 们 采 取 一 些 措 施 来 减 少 处 理 上述 处 理之 后 ， 有 库表 恢 复正 常 。 所 经 计算 ： 述 处 理 过程 共 用 了 ２ 上 ３分 钟 ， 显 比 明 直 接做 快 很多 。
从 以 上 处 理 我 们 有 这 样 一 个 启 示 ： 对 ｉｆｒ ｘ ｎｏ ｍｉ
多 万条 记 录 ，故 用正 常 方 法 删 除将 需 要 １ 小 时左 ０
（ ９）在 ｏ ｍｏ ｉ ｒ管 理 菜 单 里 把 ｉｆｒ ｘ备 份 ｎ ｎｔ ｏ ｎｏｍｉ
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Informix 计算长事务回滚时间及解决办法如何估算长事务回滚的时间环境:IDS9.40及其以上版本问题描述:用户往往由于一次操作的数据量过大，导致长事务，使整个数据库服务器暂时挂起而不可用。
用户需要估算长事务回滚完成的时间，以便做出安排。
解答:可以使用onstat -x -r 10监控该事务的回滚状态.并通过日志回滚的速率来估算回滚的时间。
“-r 10”表示每10秒显示一次。
下面是两次的间隔10秒输出：address flags userthread locks beginlg curlog logposit isol retrys coordd745b58 A-R-- d715e7c 4904 51 53 0x8f61c8 COMMIT 0address flags userthread locks beginlg curlog logposit isol retrys coordd745b58 A-R-- d715e7c 4904 51 53 0x5a1acc COMMIT 0从输出可以看到，该事务起始的逻辑日志号是51，当前回滚到53，还需要继续回滚2个逻辑日志。
在这10秒中回滚的逻辑日志大小可以通过两次的logposit相减得出，方法为：去掉每个logposit的后三位，剩下的数字相减就是日志回滚的page数目，再乘以page size 就可得到这10秒回滚的日志大小。
例如：（0x8f6 - 0x5a1）*4 = 3412 K (4表示当前系统的page size是4K),那么一分钟逻辑日志能够回滚 3412/10*60=20472 K假设每个逻辑日志的大小为50M，则该长事务还需要回滚的时间大约是5.28分钟(（1024*50) * 2 + 0x5a1*4)/20472 =5.28一、查看数据库状态正常情况下是onstat -IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line -- Up 35 days 16:51:16 -- 3920896 Kbytes长事务情况下是onstat -IBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:40 -- 3920896 KbytesBlocked:LONGTX二、显示事务（transaction）信息其中flag字段中第三个标志位为R说明事务在rollback，说明这个事务是长事务onstat -xIBM Informix Dynamic Server Version 9.40.FC7 -- On-Line (LONGTX) -- Up 35 days 16:41:56 -- 3920896 KbytesBlocked:LONGTXTransactions1cf0a6748 A-R-- 1cd55c618 642073 119403 119405 0x1aa91e4 DIRTY 0三、通过长事务的userthread值找出session idonstat -u |grep 1cd55c6181cd55c618 --RPX-- 1880841 informix- 0 0 642073 256446 323049四、显示会话连接信息，找出造成长事务的SQL语句，并优化onstat -g ses 1880841informix锁表处理步骤：锁表处理步骤：1、onstat -ks|grep HDR+X //查询是那个表被锁address wtlist owner lklist type tblsnum rowid key#/bsizc1809510 0 d656e774 c181cb3c HDR+X 6002e1 2c602 0需要关注lklist和type项，从上面来看tblsnum为6002e1（十六进制转换成十进制）的表被锁了。
可以重查询是那个表被锁：dbaccess ：select * from systables where partnum='6292193'得到tabname basetab_mvpnowner smpmmlpartnum 6292193tabid 12813rowsize 464ncols 61nindexes 1nrows 2984created 12/10/2002version 839843846tabtype Tlocklevel Rnpused 746fextsize 16nextsize 16flags 02、onstat -u，将owner(address)为d656e774的线程找出来address flags sessid user tty wait tout locks nreads nwritesd656e774 Y--P--- 4261 smp20 - d6ad2330 0 180 99620 163、onstat -g sql d656e774可以将这个线程执行过的sql语句打印出来。
4、只要用informix用户执行onmode-z sessid干掉线程onmode-z 4261重点说明：onstat -g ses sessid找个进程PID来,然后ps -ef|grep Pid; kill -9 pid在处理这些问题时还会遇到表被锁是因为该线程还没有执行完毕，此时就不能简单的 onmode -z 杀线程Informix常见问题处理概述在实际的生产运行环境中，笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关 Informix 常见的问题，进而被多次问起如何处理这些常见的 Informix 问题，笔者根据自己在工作中对 Informix 数据库的使用经验积累写下这篇文章。
Informix 常见的问题有以下几种：•逻辑日志满•频繁的锁冲突•长事务问题•数据库 chunk 出现异常，I/O 失败•不能插入数据下面我们分别针对以上问题来一一讲解如何处理。
逻辑日志满故障现象：数据库不再进行任何操作，使用 onstat –l 命令观察逻辑日志状态，所有的逻辑日志都处于已使用未备份状态，即 flags 为 U------ 标志。
故障分析：由于数据库的大部分操作都需要记录逻辑日志，所以如果逻辑日志由于各种各样的原因被充满都会导致数据库停止正常的操作，等待逻辑日志空间的释放、重新再利用。
这一般会由于数据库逻辑日志没有及时备份、数据库逻辑日志空间分配过小、逻辑日志里面包含活动事务、包含检查点信息等原因。
故障处理：检查是否是由于逻辑日志备份出现问题，如果是不能备份请查找不能备份的原因，可能是由于磁带满或磁带机出现故障，或者是磁带设备繁忙；个别情况下即使逻辑日志标志为已备份但是仍然是不可使用的，包括：故障分析：数据库在进行修改操作的时候为了防止其他用户的同时修改，都会在修改所涉及的数据上设置对应的锁，如果其他用户再访问到这些已经被放置上锁的数据，就会出现锁失败。
例如如果需要知道在指定的表上是有哪些用户具体占用了锁，可以通过以下的步骤：1. 首先确定表的 partnum，可以通过查询 systables 里面的 partnum，也可以通过执行 oncheck–pt database:tabname 查看 Partition partnum 来获得，该数据为十进制数，需要转换为十六进制；2. 执行 onstat –k | grep partnum 来查找相应的信息，partnum 为上一个步骤获得的结果，需要使用具体的十六进制值来替换，观察其 owner 字段的地址信息；故障处理：调整数据库隔离级别，例如使用 dirty read；将数据库表的缺省页级锁修改为行级锁；设置锁等待时间；调整应用 SQL，提高执行效率，尽量快的完成事务处理，释放资源；如果需要快速处理锁冲突的情况，在确定锁的实际拥有者以后可以确定是否应该终止其操作，执行 onmode –z <sid> Kill specified session id，以达到释放锁资源的目的。
长事务故障现象：在数据库日志里面出现发现长事务的提示，受影响的事务处于回滚状态，个别情况下会导致整个数据库实例的其他数据库会话都停止执行。
故障分析：当一个活动事务它所占用的逻辑日志个数的比例达到或超过 LTXHWM 所设定的值，数据库就会判定该事务为一个长事务，对该事务进行回滚操作，如果这个时候逻辑日志的使用个数仍然持续上涨达到或超过 LTXEHWM 所设定的值，则数据库会停止其他会话的正常运转，全力保证该长事务的回滚操作。
故障处理：根据数据库日志里面所提供的信息可以很方便的发现具体是那一个事务造成了长事务。
系统在将某个事务判定为长事务以后就会自动对其进行回滚操作。
事后可以有针对性的调整应用将大的事务划分为小事务进行提交；避免一个活动事务长时间没有后续的操作；提供充足的逻辑日志空间，这里所指出的不仅是空间的总量需要增加，逻辑日志的个数也是应该增加的，因为判断的标准是以逻辑日志的使用个数所占比例来确定的。
在 INFORMIX 9.3X 以后的版本中可以通过动态增加故障分析：由于表所存在的 dbspaces 上没有足够的连续空间来创建新的 extent；达到每个单片表的extents 个数上限；达到每个单片表记录数的上限，以上 3 种可能都会导致不能插入数据情况的发生。
故障处理：在出现这种问题以后，首先应该查看应用日志、应用程序，也可以通过查看当前正在执行并返回错误的 SQL 以确定到底是哪张表不能插入数据。
在定位受到影响的表以后应该确定表所存在的dbspace 是否有足够的连续空闲空间，如果没有请相应的增加 chunk 空间以扩充其数据库存储空间。
在确认存在足够的连续空闲空间以后再检查是否达到后续的 2 个上限，可以使用一些脚本工具或数据库命令来实现这一点。
在确认问题的原因以后，理想的解决方法是为数据库表提供更多的使用空间，例如增加 chunk、将表进行重建、将表进行合理的分片等；应急的处理原则是：小批量、小批量地删除部分数据，尽量将需要处理的数据限制在较小的范围内，通过多次的操作来达到删除数据的目的，避免出现大事务、长时间不能完成的情况出现。