下载文档原格式
华为产品维护资料汇编 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注册才能执行本命令，本命令不但能初始化共享内存，还能初始化磁盘空间。
关于Mysql的binlog_cache_size变量的修改一、参考知识点：Mysql 5.6官档：5.1.5 Server System VariablesThe MySQL server maintains many system variables that indicate how it is configured. Each system variable has a default value. System variables can be set at server startup using options on the command line or in an option file. Most of them can be changed dynamically at runtime using the SET statement, which enables you to modify operation of the server without having to stop and restart it. Setting the global value of a system variable requires the SUPER privilege. For some system variables, setting the session value also requires the SUPER privilege; if so, it is indicated in the variable description. You can also use system variable values in expressions.Mysql服务器维护着很多的表明系统怎样配置的系统变量，每个系统变量都有一个默认值。
这些变量可以在服务器启动的时候在命令行或者一个可选文件进行设置。
MySQL调优参数配置MySQL服务器硬件优化硬盘：mysql 对磁盘的要求⽐较⾼，包括随机读写的带宽和IOPS和顺序读写的带宽和IOPS，可以通过使⽤⾼转速磁盘、商业FC存储、固态硬盘等⽅式提⾼IOPS及读写带宽；内存：mysql 服务器内存越⾼，可加载的热点索引数据越多，可提供给操作线程的内存越多。
Mysql 读写操作越快；CPU： mysql正常的查询对CPU要求⽐较低，如果磁盘和内存不⾜CPU配置过⾼更容易引起磁盘吞吐量下降严重导致性能过低，所以硬件优化⾸先优化硬盘和内存，只有硬盘和内存⽆瓶颈后增加CPU才会使mysql性能更⾼如果有⼤量的慢查询则很容易将CPU跑满，所以CPU如果过⾼应⾸先检查慢查询优化慢查询，如慢查询优化完成应⾸先检查是否由于磁盘IO过⾼引起的CPU过⾼。
内存优化-数据索引页共享内存innodb_buffer_pool_size1. 作⽤：pool-size可以缓存索引和⾏数据，值越⼤，IO读写就越少，如果单纯的做数据库服务，该参数可以设置到电脑物理内存的75-80%2. 调优参考计算⽅法：val = Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%val > 95% 则考虑增⼤ innodb_buffer_pool_size，建议使⽤物理内存的75%val < 95% 则考虑减⼩ innodb_buffer_pool_size，建议设置为：Innodb_buffer_pool_pages_data * Innodb_page_size *1.05 / (102410241024)innodb_buffer_pool_instances1. 作⽤：innodb_buffer_pool_instances的值主要⽤于将innodb buffer pool进⾏划分，通过划分innodbbuffer pool为多个实例，可以提⾼并发能⼒，并且减少了不同线程读写造成的缓冲页。
数据库transaction用法1. 介绍在数据库管理系统中，transaction（事务）是指一系列数据库操作，要么全部执行，要么全部不执行。
在现代的数据库系统中，transaction是一个非常重要的概念，它确保了数据库操作的一致性、可靠性和持久性。
本文将介绍数据库transaction的基本概念、用法和注意事项。
2. 事务的特性在数据库中，事务具有以下四个特性，通常被缩写为ACID：1）原子性（Atomicity）：事务是一个不可分割的工作单位，要么全部执行，要么全部不执行。
2）一致性（Consistency）：事务执行前后，数据库的完整性约束没有被破坏。
3）隔离性（Isolation）：在并发情况下，事务的执行不会受到其他事务的影响。
4）持久性（Durability）：一旦事务提交，其结果就会被永久保存在数据库中，即使系统发生故障也不会丢失。
3. 事务的基本操作在数据库系统中，事务具有四个基本操作，通常被缩写为ACID：1）开始事务（BEGIN TRANSACTION）：标志着事务的开始。
2）提交事务（COMMIT TRANSACTION）：将事务的操作永久保存到数据库中。
3）回滚事务（ROLLBACK TRANSACTION）：撤销事务中的所有操作，回复到事务开始之前的状态。
4）保存点（SAVEPOINT）：在事务中设置一个保存点，可以在事务回滚时回滚到该保存点。
4. 事务的使用在实际开发中，事务的使用非常普遍，特别是在对数据库进行复杂操作时。
下面是一些常见的事务使用场景：1）转账操作：假设有一个转账操作，需要从一个账户扣除一定金额然后添加到另一个账户。
这个操作必须是原子性的，否则就会出现数据不一致的情况。
2）订单处理：在订单处理中，通常涉及到减库存、生成订单、扣款等操作，这些操作必须是一致的，否则就会出现订单和库存不匹配的情况。
3）数据导入导出：在数据导入导出时，需要保证数据的完整性和一致性，这就需要使用事务来保证操作的一致性。
Informix监控和管理命令电脑资料监控ONLINE系统后动情况的工具主要有以下三类：系统监控接口（ I）、tbstat和tbcheck，不能对 I中的表加锁或使用隔离级别。
不允许使用insert，delete，update等语句（只读）不能使用dbsche ，dbexport等命令使用select rowid语句将会产生不可预料的结果主要的 I表有：sysdatabases：online中的数据库信息systabnames：某数据库中所有表的信息syslogs：逻辑日志信息sysdbspaces：数据库信息syschunks，syslocks等例1：显示处于脱机（offline）状态的chunk的序号和所在数据库空间Select chknum，dbsnum from syschunks where isoffline=1 or misline=!例二：显示满chunk的信息Select chknum，dbsnum from syschunks where nfree=0 二、TBSTAT ? 列出当前时刻的信息（实际也是读取 I表）不需要磁盘I/O不需要锁等系统资源，因此不会影响系统性能用法：tbstat [-abcdklmpstuzBDFPRX] [-r seconds] [-o file] [infile] -a print all info (options: bcdklmpstu)-b print buffers（缓冲区）-c print configuration file（配置文件）-d print dbspaces and chunks（dbspace和chunk）-k print locks（锁）-l print logging（日志）-m print message log（日志）-p print profile（profile文件）-s print latches（门闸）-t print tblspaces（表空间）-u print users（用户）-z zero profile counts-B print all buffers-D print dbspaces and detailed chunk stats-F print page flushers（页刷新进程）-P print profile, including BIGreads-R print LRU queues（LRU队列）-X print entire list of sharers and waiters for buffers-r repeat options every n seconds (default: 5)-o put shared memory into specified file (default: tbstat.out) infile use infile to obtain shared memory infor tion三、几个常用的tbstat选项 tbstat -m ：显示消息日志的最后20行. 消息日志的内容包括：1）、检查点信息2）、读写错误信息3）、ONLINE模式转换信息4）、长事务5）、日志文件满(LOG FILE FULL )假设想显示完整信息,可直接编译消息日志文件.Tbstat -d：磁盘空间的使用情况，包括DBSPACE和CHUNK的信息例：RSAM Version 5.03.UC1 -- On-Line -- Up 09:45:41 -- 816 Kbytes Dbspaces address number flagsfchunk nchunksflags ownername 8040a244 1111 N informix rootdbs 1 active, 8 total Chunks address chk/dbs offset size free bpages flags pathname 80409d84 1 1 0 300000 231871PO-/dev/rdata 1 active, 8 total其中的FREE项，显示了该CHUNK的空闲空间大小(Kbytes).Tbstat -l ：日志文件情况Physical Logging Buffer bufused bufsize numpages numwrits pages/io P-2 016 000.00 phybegin physize phypos phyused %used 101782 15000960 00.00 Logical Logging Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io L-2 016 1111.01.0 address number flagsuniqid beginsize used%used 8042de94 1U---C-L 110521a 7500 630 8.408042deb0 2F------ 0106f66 75000 0.00 8042de 3F------0108cb2 75000 0.00 8042dee8 4F------ 010a9fe 75000 0.00 8042df04 5F------ 010c74a 75000 0.00 8042df20 6F------010e496 75000 0.00其中：%USED：使用百分比FLAGS字段的含义:F: 空闲B:已备份C: 正在接收事物记录U: 正在使用A: 新增日志L: 包含最后一个检查点Tbstat - u：ONLINE的用户情况Users address flags pid user tty waittout locks nreads nwrites 804019f4 ------D 329 root console 0 00 179 2 80401a64 ------D 0 root console 0 00 00 80401ad4 ------F 330 root 0 00 00 3 active, 20 total Transactions address flags user locks log begin isolation retrys coordinator 804022b4 A---- 804019f4 0 0 NOTRANS 0 804028d8 A----80401a64 0 0 NOTRANS 0 2 active, 20 total其中：flages字段的含义:第一列：（S：等待mutex；Y：等待条件；L：等待锁；B：等待缓冲区；C：等待检查点；X：长事务清理；G：等待长缓冲写；T：等待事务）第二列：（*：事务执行时，发生I/O错误）第三列：（A：正在备份；B：操作已被记录在日志中；P：分布处理已准备好；C：正在提交；R：正在回滚）第四列：（P：会话的主线索）第五列：（R：在read rsam 调用中；X：进程在关键分区）第七列：（M：特殊监控；D：特殊线索；C：清理线索；F：特殊清页进程；B：特殊B+树清页线索） Tbstat -k ：用户持有锁的情况锁按照粒度分为6种: 库锁、表锁、页锁、行锁、字节锁、键锁字节锁：更新包含有VARCHAR类型的行时，加在该行上的锁，键锁：用于索引树上的锁。
事务（Transaction）的特性和状态事务管理事务（Transaction）：1、构成单⼀逻辑⼯作单元的操作集合DBMS中的⽤户程序DBMS外的可执⾏程序对数据库的读/写操作序列2、读从数据库中读取数据，⾸先从磁盘中读到内存（Buffer Pool），然后赋给变量。
3、写先完成内存中的数据复制，然后写⼊磁盘。
事务的特性－ACID：原⼦性(Atomicity)⼀致性(Consistency)隔离性(Isolation)持久性(Durability)事务的特性－原⼦性：事务中的操作，要么全做成，要么都不做事务是不可拆分的事务必须以 Commit/Rollback 结束事务的特性－⼀致性：单独运⾏的事务，必须保证保持数据库的⼀致状态从⼀个⼀致状态迁移到另⼀个⼀致状态与原⼦性相关事务的特性－隔离性：多个并发事务之间不能相互⼲扰并发不影响事务的执⾏事务的特性－持久性：⼀旦事务成功完成（Commit），它对数据库的更新应该是持久的即使在写⼊磁盘之前，系统发⽣故障在下次启动之后，也应保障数据更新的有效事务及事务管理器：恢复和并发控制是事务管理的重要组成部分恢复管理部件负责保证事务的原⼦性与持久性并发控制部件负责事务的并发控制机制，实现事务的隔离性与⼀致性事务管理器实现事务的ACID事务的提交与回滚：提交( Commit通知事务管理器⼀个逻辑⼯作单元已完成，所做的更新操作可以被提交或永久保留表明事务成功地结束执⾏有效性检验回滚( RollBack)通知事务管理器事务未能正常完成，数据库可能处于不⼀致状态，当前事务所做的所有更新操作必须撤消表明事务不成功地结束事务的状态：活动状态(Active)，初始状态，事务正在执⾏时处于此状态部分提交状态，事务的最后⼀条语句被执⾏后失败状态，发现正常的操作不能继续后中⽌状态，事务回滚且数据库已恢复到事务开始时的状态重启事务——不是由于内部逻辑错误导致的故障杀死事务提交状态，事务成功完成事务的并发：多个事务可能同时（交叉地）在系统中运⾏提⾼处理器、磁盘的利⽤率减少等待时间多个事务并发运⾏，由事务管理器进⾏调度可串⾏化调度并发运⾏的结果，与事务按某⼀顺序串⾏运⾏的结果等同PROPAGATION_REQUIREDSpring默认的传播机制，能满⾜绝⼤部分业务需求，如果外层有事务，则当前事务加⼊到外层事务，⼀块提交，⼀块回滚。
transaction 、的用法摘要：一、引言二、transaction的定义三、transaction的用法1.事务处理2.交易3.转换四、transaction在不同场景中的应用1.数据库2.金融领域3.计算机科学五、总结正文：一、引言本文将详细介绍transaction的用法。
Transaction是一个非常常见的词汇，涉及到多个领域，包括数据库、金融和计算机科学等。
本文将重点讨论transaction的定义、用法以及在不同场景中的应用。
二、transaction的定义Transaction（事务）是一个在计算机科学和金融领域中广泛使用的概念，它表示一个原子性、一致性、隔离性和持久性（ACID）的操作序列。
简单来说，事务就是一组逻辑上相关的操作，这些操作要么全部执行，要么全部不执行。
三、transaction的用法1.事务处理在计算机科学领域，事务处理是指对数据库的一组操作，这组操作需要满足ACID特性。
事务处理可以确保数据的一致性和完整性，避免因为部分操作失败导致整个操作失败。
2.交易在金融领域，交易是指涉及到货币或其他资产转移的行为。
交易所遵循的规则和原则也符合ACID特性，例如，在股票交易中，买入和卖出的操作需要同时进行，以确保市场的公平和公正。
3.转换在某些情况下，transaction还可以表示转换。
例如，将一种货币转换为另一种货币，或者将一种数据格式转换为另一种数据格式。
这种转换操作同样需要满足ACID特性，以确保转换过程的准确性和一致性。
四、transaction在不同场景中的应用1.数据库在数据库系统中，事务处理是确保数据一致性和完整性的关键技术。
通过将多个操作组合成一个事务，可以确保这些操作同时成功或失败，避免因部分操作失败导致的数据不一致问题。
2.金融领域在金融领域，交易是金融市场的基础。
通过遵循ACID特性的交易规则，可以确保金融市场的公平、公正和透明。
此外，金融领域的事务处理还包括风险管理、资金清算等关键环节。
长事务( Long Transaction ) 是数据库用户经常会碰到和非常头疼的问题。
长事务处理不当常常会引起数据库的崩溃，给企业运营带来不必要的损失。
本文旨在帮助用户理解什么是长事务，为什么会出现长事务，怎样避免长事务以及如何解决长事务可能带来的系统挂起甚至崩溃问题。
什么是“长事务”?要理解什么是“长事务”，还要从“事务”本身及数据库的逻辑日志工作原理谈起。
所谓“事务”(transaction)，是一个完整的不可分割的数据处理单元。
该单元中所有的数据处理操作要么全部处理成功，要么因其中任意一个操作的失败而完全回滚至整个事务处理前状态。
为了保证事务的完整性，Informix 数据库通过逻辑日志(logical log) 来记录所有的事务操作及其处理的数据。
逻辑日志的作用之一在于对数据所发生的变化进行记录以满足可能的回滚需要。
Informix 数据库服务器把逻辑日志分成多个相互分离的磁盘空间，每个磁盘空间称为一个逻辑日志文件。
由于逻辑日志文件的大小和个数由参数指定，整个逻辑日志的空间是相对固定的，并不能无限制的增长。
所以对于逻辑日志文件的使用是循环进行的。
Informix 数据库服务器按数字顺序依次填充空闲的（即状态为free 或available）的逻辑日志文件。
当第一个逻辑日志文件变满时，接着开始填充下一个逻辑日志文件，直到填充完最后一个逻辑日志文件。
这时，数据库服务器回到第一个逻辑日志文件，试图将其内容释放，以循环使用( 如图1)。
图 1. 循环使用的逻辑日志释放已经使用过的逻辑日志，需要具备很多条件。
其中之一就是该日志不能包含仍然活动的( 即还没有提交) 的事务。
因为活动的事务随时存在需要回滚的可能性，如果在事务还没有提交时，包含该事务记录的日志由于被释放重用，原来的事务操作记录被覆盖，当事务由于各种原因需要回滚时，回滚所需的记录就会缺失，从而导致无法保证事务的原子性和完整性。
那么，当数据库服务器需要循环使用某个逻辑日志文件，而该文件又包含有还没有提交的事务时，数据库系统就将被挂起(hang), 处于一种停滞状态，任何对数据库的更新操作都无法继续，从而影响系统的正常处理工作( 如图2)。
长事务( Long Transaction ) 是数据库用户经常会碰到和非常头疼的问题。
长事务处理不当常常会引起数据库的崩溃，给企业运营带来不必要的损失。
本文旨在帮助用户理解什么是长事务，为什么会出现长事务，怎样避免长事务以及如何解决长事务可能带来的系统挂起甚至崩溃问题。
什么是“长事务”?要理解什么是“长事务”，还要从“事务”本身及数据库的逻辑日志工作原理谈起。
所谓“事务”(transaction)，是一个完整的不可分割的数据处理单元。
该单元中所有的数据处理操作要么全部处理成功，要么因其中任意一个操作的失败而完全回滚至整个事务处理前状态。
为了保证事务的完整性，Informix 数据库通过逻辑日志(logical log) 来记录所有的事务操作及其处理的数据。
逻辑日志的作用之一在于对数据所发生的变化进行记录以满足可能的回滚需要。
Informix 数据库服务器把逻辑日志分成多个相互分离的磁盘空间，每个磁盘空间称为一个逻辑日志文件。
由于逻辑日志文件的大小和个数由参数指定，整个逻辑日志的空间是相对固定的，并不能无限制的增长。
所以对于逻辑日志文件的使用是循环进行的。
Informix 数据库服务器按数字顺序依次填充空闲的（即状态为free 或available）的逻辑日志文件。
当第一个逻辑日志文件变满时，接着开始填充下一个逻辑日志文件，直到填充完最后一个逻辑日志文件。
这时，数据库服务器回到第一个逻辑日志文件，试图将其内容释放，以循环使用( 如图1)。
图 1. 循环使用的逻辑日志释放已经使用过的逻辑日志，需要具备很多条件。
其中之一就是该日志不能包含仍然活动的( 即还没有提交) 的事务。
因为活动的事务随时存在需要回滚的可能性，如果在事务还没有提交时，包含该事务记录的日志由于被释放重用，原来的事务操作记录被覆盖，当事务由于各种原因需要回滚时，回滚所需的记录就会缺失，从而导致无法保证事务的原子性和完整性。
那么，当数据库服务器需要循环使用某个逻辑日志文件，而该文件又包含有还没有提交的事务时，数据库系统就将被挂起(hang), 处于一种停滞状态，任何对数据库的更新操作都无法继续，从而影响系统的正常处理工作( 如图2)。
长事务( Long Transaction ) 是数据库用户经常会碰到和非常头疼的问题。
长事务处理不当常常会引起数据库的崩溃，给企业运营带来不必要的损失。
本文旨在帮助用户理解什么是长事务，为什么会出现长事务，怎样避免长事务以及如何解决长事务可能带来的系统挂起甚至崩溃问题。
什么是“长事务”?要理解什么是“长事务”，还要从“事务”本身及数据库的逻辑日志工作原理谈起。
所谓“事务” (transaction)，是一个完整的不可分割的数据处理单元。
该单元中所有的数据处理操作要么全部处理成功，要么因其中任意一个操作的失败而完全回 滚至整个事务处理前状态。
为了保证事务的完整性，Informix 数据库通过逻辑日志 (logical log) 来记录所有的事务操作及其处理的数据。
逻辑日志的作用之一在于对数据所发生的变化进行记录以满足可能的回滚需要。
Informix 数据库服务器把 逻辑日志分成多个相互分离的磁盘空间，每个磁盘空间称为一个逻辑日志文件。
由于逻辑日志文件的大小和个数由参数指定，整个逻辑日志的空间是相对固定的，并 不能无限制的增长。
所以对于逻辑日志文件的使用是循环进行的。
Informix 数据库服务器按数字顺序依次填充空闲的（即状态为 free 或 available）的逻辑日志文件。
当第一个逻辑日志文件变满时，接着开始填充下一个逻辑日志文件，直到填充完最后一个逻辑日志文件。
这时，数据库服务 器回到第一个逻辑日志文件，试图将其内容释放，以循环使用 ( 如图 1)。
图 1. 循环使用的逻辑日志释放已经使用过的逻辑日志，需要具备很多条件。
其中之一就是该日志不能包含仍然活 动的 ( 即还没有提交 ) 的事务。
因为活动的事务随时存在需要回滚的可能性，如果在事务还没有提交时，包含该事务记录的日志由于被释放重用，原来的事务操作记录被覆盖，当事务由于 各种原因需要回滚时，回滚所需的记录就会缺失，从而导致无法保证事务的原子性和完整性。
那么，当数据库服务器需要循环使用某个逻辑日志 文件，而该文件又包含有还没有提交的事务时，数据库系统就将被挂起 (hang), 处于一种停滞状态，任何对数据库的更新操作都无法继续，从而影响系统的正常处理工作 ( 如图 2)。
图 2. 长事务导致系统挂起为了防止这种现象的发生，我们把占用整个逻辑日志空间在一定比例以上的事务，就叫 做“长事务”。
“长事务”意味着可能由于跨越过多的日志文件，导致需要循环使用的日志文件不能及时释放。
从而造成数据库系统挂起无法正常工作的可能性。
与长事务相关的数据库参数那么究竟多长的事务就是“长事务”呢？事实上，“长事务”由一系列数据库参数决定。
LOGFILES该参数指定系统初始化或重启动时创建的逻辑日志文件的个数。
之后系统管理员还可以继续追加逻辑日志文件数。
Informix 数据库要求逻辑日志文件最少有 3 个，最多可以追加到 32,767 个或直至逻辑日志所在空间 (dbspace) 被占满。
LOGSIZE该参数指定创建的逻辑日志文件的缺省大小。
当系统管理员手工追加日志文件时，可以重新指定日志文件大小。
所以逻辑日志文件的个数和其大小决定了系统可用逻辑日志空间的总和。
Long-Transaction High-Watermark (LTXHWM)长事务深水线比例是指整个逻辑日志空间的一个百分比值。
当一个事务占用整个逻辑日志空 间的百分比超过这个值时，该事务就成为长事务。
数据库系统系统就会强制对该事务进行回滚（rollback ）， 以防止该事务继续填充日志，最终导致日志需要循环重用时无法释放而造成系统挂起。
例如，数据库服务器有 10 个逻辑日志文件，如果 LTXHWM 设置为 80 。
一个事务（transaction ）从日志文件 1 （log1 ）开始填充，随着该事务的更新(update) ，当其操作填充到第 8 个日志文件满时，该事务就到达了长事务深水线比例（LTXHWM ），为了防止系统挂起，数据库服务器将回滚该事务。
Exclusive Access, Long-Transaction High-Watermark (LTXEHWM)当一个 事务到达长事务深水线比例（LTXHWM ）后，数据库服务器会回滚该事务。
事务回滚本身也会产生日志，仍然要继续填充日志空间。
同时，由于并发事务的存在，其他事务也在不断填充日志空间。
所以如 果在该事务完全回滚之前，日志空间被填满，仍然会造成系统的挂起。
为了尽量避免这种情况的发生，我们用独享的长事务深水线来限制长事物回滚时其他事务对日 志空间的使用。
独享的长事务深水线也是整个逻辑日志空间的一个百分比值。
当正在回滚的长事务占用日志空间的百分比到达这个值时，系统会 急剧降低对日志文件的填充速度。
此时，数据库系统几乎给予正在回滚的长事务以独占使用剩余日志空间的权利，以最大限度地保障长事务回滚能够在日志空间添满 前能够顺利完成，从而使日志释放重用得以实现。
例如，数据库服务器有 10 个逻辑日志文件，如果 LTXHWM 设置为 80, LTXEHWM 设置为 90 。
一个事务（transaction ）从日志文件 1 （log1 ）开始填充，随着该事务的更新 (update) ，当其操作填充到第 8 个日志文件满时，该事务就到达了长事务深水线比例（LTXHWM ），为了防止系统挂起，数据库服务器开始回滚该事务，此时日志内容由于该事务回滚和其他事务继续增长，当其操作填充到第 9 个日志文件满时，如果该事务还未回滚完成，则到达独享的长事务深水线比例（LTXEHWM ），这时候数据库系统会暂停其他事务的操作（除 commit 操作外），留下剩余的日志空间，让该事务回滚，以防止日志空间在回滚结束前被占满。
( 如图 3)图 3. 长事务深水线比例（LTXHWM）与独享的长事务深水线比例（LTXEHWM）示意DYNAMIC_LOGS从 Informix Dynamic Server （IDS）版本 9.30 开始，用户可以通过对数据库参数中的 DYNAMIC_LOGS 参数进行设置以实现系统逻辑日志的自动分配。
该参数允许用户在服务器工作状态动态添加新的日志并且立即生效，从而动态增加整个逻辑日志空间的大小，消除或 减小长事务处理引起挂机的可能性。
DYNAMIC_LOGS 参数有三个值分别为 0,1,2：缺省为 2( 系统自动分配日志 )。
假如当前使用的日志为 n，系统自动为 Transation 检查 log n+1 的状态，如果返回的结果为真 ( 即 Log n+1 无法被释放而重用 )，系统将在 n 和 n+1 之间加入新的日志并一直增加到满足当前 Transation 完成且立即生效。
新增加的日志缺省建立到逻辑日志最后被添加的 dbspace 中，或根据系统规则建立到指定的 dbspace 中。
新增日志的大小将取已有最大日志和最小日志的均值。
或根据请求空间的大小进行相应的调整，日志最小为 200K。
图 4. 逻辑日志的动态分配示意当 DYNAMIC_LOGS 参数设置为 1 时，系统也自动为 Transation 检查 logn+1 的状态，如果返回的结果为真 ( 即 Log n+1 无法被释放而重用 )，系统将等待系统管理员手工在当前日志后添加日志，系统管理员可以在任何时间使用 ISA 或 onparams 多种方式为系统添加日志。
如果 DYNAMIC_LOGS 参数为 0，系统将不会自动添加日志也不会出现等待状况。
什么情况下会出现长事务从以上数据库参数可以看出，长事务与整个日志空间大小有关，与长事务深水线比例有关。
直接来看，在整个逻辑日志空间相对固定的前提下，当一个事务越大 （包含的操作越多），其需要填充的逻辑日志空间就会越大。
如果该事务需要记录的日志占用整个逻辑日志的百分比超过长事务深水线比例（LTHWM），该事务 就成为长事务。
那么，如果我们能够预计最复杂的事务需要填充日志空间的大小，如果我们分配给系统足够大的日志空间（系统整个日志空间 *LTHWM/100 > 最复杂的事务需要填充的日志空间），是不是就完全能够杜绝长事务的发生呢？另外，一个非常小的事务（其实际填充的日志空间远远小于系统整个日志空间）是不 是就一定不会成为长事务呢？答案并非如此。
事实上，事务之所以成为长事务，其所占日志空间定义为该事务从第一条日志 记录到最终 commit 或者 rollback 记录之间的所有日志空间。
当这个空间占用整个逻辑日志空间的百分比超过长事务深水线比例时，该事务就成为长事务了。
首先，事务包含的操 作的多少只是决定该事务是否将成为长事务的因素之一。
还有其它一些因素会影响事务占用逻辑日志空间的大小。
例如，一条 Alter table 虽然仅仅是一个操作，但语句将会为每一次往新修改了的表中的插入操作生成一条逻辑日志记录。
数据行的数量与表的大小都将会影响生成的逻辑日志记录的数目与 大小。
操作的数据行数越多，生成的逻辑日志记录越多，所占用的逻辑日志空间既然越大。
其次，在另外一些情况下，虽然事物的操作和数据行 大小并不大，但由于系统并发的存在，事务的持续时间也是一个不能为用户所控制的主要的变化量。
在事务持续时间中，该事务所占日志空间中可能包含了许多其他 并发事务的日志记录。
因此，系统的并发性越大，事务的操作时间越长，事务占用 ( 跨越 ) 的逻辑日志空间就越大。
一个应用，也许并不需要过多的逻辑日志记录空间，但如果用户允许事务在很长时间内保持打开，这时就可能造成长事务事件。
发生长事务事件的结果及影响当一个事务所跨逻辑日志空间的百分比超过长事务深水线比例 (LTXHWM) 时，系统会将该事务标记为长事务，并开始回滚 (rollback) 该事务。
如果此时还没有达到独享的长事务深水线比例 (LTXEHWM) ，则系统在回滚该事务的同时允许其他并发事务的继续操作。
当该事务日志占用超过独享的长事务深水线比例 (LTXEHWM) 时，系统会暂停其他并发事务的进行，优先进行该事务的回滚操作，直到事务回滚完成。
如果在该事务回滚完成之前，系统逻辑日志空间已被全部占满，则数据库系 统会挂起，无法为客户端继续提供正常服务。
所以，只要配置足够的逻辑日志空间和较低的长事务深水线比例 (LTXHWM)、独享的长事务深水线比例 (LTXEHWM)，就有可能保证长事务的顺利回滚。
但是，长事务的出现，会影响业务的正常操作，导致该事务无法执行成功。
而且，长事务独享日志回滚期 间，也会影响整个系统的并发效率。
然而，最糟糕的情况莫过于出现长事务回滚完成之前，系统逻辑日志空间已被全部占满，从而带来致命的系 统挂起，给系统运营带来损失。
