informix 长事务详解
[IT计算机]informix
![[IT计算机]informix](https://img.taocdn.com/s3/m/d21bbe39dc36a32d7375a417866fb84ae45cc3ed.png)
轻松接触Informix数据库的基本概念（一）informix 数据库基本概念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：{ ROOTPA TH } rootdbs的路径，须预先准备好。
Root Size：{ ROOTSIZE } 规定rootdbs的大小。
建议不要小于50MB。
Root Offset ：{ROOTOFFSET } Root Name 设备的偏移量。
对于Primary Path指定的设备是操作系统文件时，必须是0；如果Primary Path是原始设备（硬盘、或可擦写光盘等）可以指定起始位置。
8. Mirror Path { MIRRORPA TH }如果Mirror处选择了Y，此处要求输入镜像设备或文件的绝对路径。
Mirror Offset：{ MIRROROFFSET }镜像设备的偏移量。
对于Mirror Path指定的设备是操作系统文件时，必须是0；如果Mirror Path是原始设备（硬盘、或可擦写光盘等）可以指定起始位置。
Informix监控和管理命令 电脑资料
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类型的行时，加在该行上的锁，键锁：用于索引树上的锁。
InformixSQL语句详解
Informix SQL 语句详解（1）1. CREATE DATABASE database_name [WITH LOG IN “pathname”]创建数据库。
database_name：数据库名称。
“pathname”：事务处理日志文件。
创建一database_name.dbs目录，存取权限由GRANT设定，无日志文件就不能使用BEGIN WORK等事务语句（可用START DATABASE语句来改变）。
可选定当前数据库的日志文件。
如：select dirpath form systables where tabtype = “L”;例：create databse customerdb with log in “/usr/john/log/customer.log”;DA TABASE databse-name [EXCLUSIVE]选择数据库。
database_name：数据库名称。
EXCLUSIVE：独占状态。
存取当前目录和DBPATH中指定的目录下的数据库，事务中处理过程中不要使用此语句。
例：dtabase customerdb;3. CLOSE DA TABASE关闭当前数据库。
database_name：数据库名称。
此语句之后，只有下列语句合法：CREATE DATABASE；DATABASE；DROP DA TABSE；ROLLFORWARD DA TABASE；删除数据库前必须使用此语句。
例：close database;4. DROP DA TABASE database_name删除指定数据库。
database_name：数据库名称。
用户是DBA或所有表的拥有者；删除所有文件，但不包括数据库目录；不允许删除当前数据库（须先关闭当前数据库）；事务中处理过程中不能使用此语句，通过ROLLBACK WORK 也不可将数据库恢复。
例：drop databse customerdb;5. CREATE [TEMP] TABLE table-name (column_name datatype [NOT NULL], …)[IN “pathname”]创建表或临时表。
数据库长事务处理方法
IBM Informix Dynamic Server Version 11.50.FC7 -- On-Line (LONGTX) -- Up 165 days 08:32:44 -- 30340096 Kbytes
Blocked:LONGTX
session effective #RSAM total used dynamic
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
30440026 UPDATE (all) niosdb DR Wait 20 0 0 9.28 Off
Current SQL statement :
update tap_so_NetStructHealthEnt set sum_level =1;
log 0 16536 temprec 0 21664
blob 0 360 keys 0 1800
onmode -z 30440026
ons
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
Last parsed SQL statement :
update tap_so_NetStructHealthEnt set sum_level =1;
2048 byte(s) of memory is allocated from the sscpool
wydb% onstat -g ses 30440026
Informix的事务、并发控制、锁机制、隔离级别
Informix的事务、并发控制、锁机制、隔离级别1、事务事务是指作为单个逻辑工作单元执行的一系列操作。
事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。
通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。
数据库服务器保证在事务范围内执行的操作完整且正确地提交至磁盘，否则数据库会复原至事务启动之前的状态。
一个逻辑工作单元要成为事务，必须满足所谓的ACID属性。
ACID的具体含义如下：1）A（Atomicity）：操作序列要么完整的执行，否则什么都不做；2）C（Consistency）：一致性，事务执行后，保证数据库从一个一致性状态到另外一个一致性状态； 3）I（Isolation）：隔离，一个事务的中间状态对其他事务不可见，即每个用户都感觉他们在单独使用数据库。
隔离级别用来定义多大程度的隔离多个不同的事务；4）D（Durability）：持久性，事务的有效性，不会应用硬件或软件的失败而丢失。
2、并发控制1）相关概念i）隔离（+一致性） => 并发控制；ii）多个事务可以访问或修改相同的资源；iii）只要多个进程共享资源，就需要对访问进程进行排队控制；iv）在进行并发控制时，数据库内部将生成多个并发事务访问资源的操作序列表，并且每一个事务内部的各个操作都需要序列化。
2）串行调度存在的问题在串行调度中，采用操作序列，一个事务完成了再完成另外一个，即使两个事务T1、T2更新的是数据库中不同的对象。
此种方式从并发和性能角度考虑，都不能很好的利用计算机资源。
为了改善性能，需要采用非串行调度，即允许事务并发执行，即一个事务内的操作可以在其他事务提交前开始执行。
3）并发调度的常见问题i）脏读：事务T2读取到了事务T1没有提交的结果例如如下的操作序列会导致脏读：事务T1读取记录，然后更新记录；事务T2读取了更新后的记录；若T1后续操作失败，会导致更新的记录回滚，而同时事务T2已经使用了这个没有提交的值。
Informix运维手册
检查方法 onstat esqlБайду номын сангаас-V
onstat -
onstat onstat -l onstat -m onstat -m onstat -m onstat -m onstat -l onstat -m onstat -m onstat -d onstat -c 巡检脚本 onstat -d 巡检脚本 巡检脚本 巡检脚本 巡检脚本 onstat -p onstat -p onstat -p onstat -p onstat -p onstat -p onstat -g seg onstat -g seg onstat -g ath onstat -c onstat -c onstat -F onstat -F 巡检脚本 onstat -c 巡检脚本 onstat -c onstat -m onstat -g sql
该动作对性能有一定影响，特别是大表
参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni 参看advanced performance tuning and moni
informix详解
data-type：字段数据类型。
path-name：指定表的存放位置
TEMP用于指定建立临时表；表名要唯一，字段要唯一；有CONNECT权限的用户可建立临时表；创建的表缺省允许CONNECT用户存取，但不可以ALTER。
例：create table user
( c0 serial not null, c1 char (10),
三种权限居且仅居其一，事务处理过程中不要执行GRANT语句。
例：revoke resource from john;
REVOKE tab-privilege ON table-name FROM {PUBLIC|user-list}
收表级权限。
tab-pE table-name
取消记录级加锁和表级加锁或文件加锁。
table-name：表名称。
例：unlock user;
SET LOCK MODE TO [NOT] WAIT
改变锁定状态。
TO [NOT]：等待解锁，有可能被死锁或不等待并提示错误信息，表示此记录被锁，缺省值。
例：rename user to bbb;
8. DROP TABLE table-name 删除表。
table-name：表名称。
删除表意味着删除其中所有数据、各字段上的索引及对表的赋权、视图等；用户不能删除任何系统目录表；语句使用者是表拥有者或拥有DBA权限，事务中处理过程中不要使用此语句。
table_name：表名称。
column_name：字段名称。
UNIQUE/DISTINCT：唯一索引。
CLUSTER：使表的物理存放顺序按索引排列。
ASC/DESC：升序或降序，缺省升序。
Informix常见错误处理思路
数据库 chunk 出现异常，I/O 失败
• 故障现象： 数据库日志中出现 chunk IO 错误，使用 onstat –d 观察 chunk flag 的状态是 down 的状态，数据库操作中不能操作包含在这些 chunk 中的数据，如果使 用到这些数据可能会返回错误，严重情况下会导致数据库宕机。
Informix 常见错误处理思路及应用
深圳IT-叶万华
2019年1月10日
informix常见错误处理思路
逻辑日志满
频繁的锁冲突 长事务 I/O 失败
逻辑日志满
• 故障现象： 数据库不再进行任何操作，使用 onstat –l 命令观察逻辑日志状态，所有 的逻辑日志都处于已使用未备份状态，即 flags 为 U------ 标志。
• /informix-dba/194-informix.html 中国Informix数据库用户协会
所有的管理都存在一定风险，所有的监控都是为了更好的管理。希望同事们不 断总结经验，共享经验，从各方面提升自我。我们可以抱着怀疑的态度去肯定 自己，证实自己。任何操作都是有风险的，请大家多留意细节！
类似的锁表现象中，我们在日常的监控过程中会经常观察得到。
频繁的锁冲突
• 故障分析：
数据库在进行修改操作的时候为了防止其他用户的同时修改，都会在修改所涉及的数据上设 置对应的锁，如果其他用户再访问到这些已经被放置上锁的数据，就会出现锁失败。例如如 果需要知道在指定的表上是有哪些用户具体占用了锁，可以通过以下的方式查看： 执行 onstat –u来获得实际的 session 信息，从中就可以找到锁的拥有者。
长事务
• 故障处理： 根据数据库日志里面所提供的信息可以很方便的发现具体是哪一个事务造 成了长事务。系统在将某个事务判定为长事务以后就会自动对其进行回滚 操作。事后可以有针对性的调整应用将大的事务划分为小事务进行提交； 避免一个活动事务长时间没有后续的操作；提供充足的逻辑日志空间，这 里所指出的不仅是空间的总量需要增加，逻辑日志的个数也是应该增加的 ，因为判断的标准是以逻辑日志的使用个数所占比例来确定的。在 INFORMIX 9.3X 以后的版本中可以通过动态增加逻辑日志的手段避免由于 长事务带来的一些不良影响，在长事务回滚过程中如果逻辑日志空间被消 耗完毕，如果 DYNAMIC_LOGS 设置为 2，数据库服务器会自动在最后创 建的逻辑日志所存在的 dbspace 上查找空余空间，按照最后创建的逻辑日 志的大小自动在当前逻辑日志之后新增逻辑日志，如果不能满足需要则会 创建失败，需要管理员手工添加。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
长事务( 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)，就有可能保证长事务的顺利回滚。
但是，长事务的出现，会影响业务的正常操作，导致该事务无法执行成功。
而且，长事务独享日志回滚期间，也会影响整个系统的并发效率。
然而，最糟糕的情况莫过于出现长事务回滚完成之前，系统逻辑日志空间已被全部占满，从而带来致命的系统挂起，给系统运营带来损失。
回页首如何监控长事务当数据库系统发生长事务事件时，可以在所有onstat 命令的输出头上看到。
“onstat –”命令（不带有任何选项）只输出头部信息，对于观察系统的状态非常onstat 输出下方还会有如下显当数据库系统由于各种原因被阻止时，在以上其中，“reason”可能的跟长事务相关的值见表1：)另外，“onstat -x”命令还可以看到回滚的事务( 如图 5 所示)。