今天操作数据库进行批量DML操作的时候，报了一个以前没有见过的错误， java.sql.SQLException: No Transaction Isolation on non-logging db‘s，特此写一遍记录一下自己的解决过程。
首先，我从上述报错看出大体就是此库不记录日志，但是以前我们的事务操作是一定会有日志的。所以展开了如下搜索。
1，查看日志模式：
onmonitor --> Logical-logs -->Databases 看各个库的 Log Status
一看，状态果然是N。这样的话，就不支持事务。所以会报错。
2，修改模式：
ontape -s -B dbname
我执行该语句报错了，Error changing logging status - ‘bmt‘. iserrno 107. Program over. 原因好像是，执行该命令时，需要数据库服务器是脱机的，就是不能执行任何增删改查的操作才可以。
ontape –s –L 0 –N dbname 将数据库dbname从-U,-B,-A其中一种模式改变到-N模式，创建0级备份
ontape –s –L 0 –U cem2 将数据库”cem2”从-N改变到-U模式，创建0级备份
ontape –s –L 0 –B cem2 将数据库”cem2”从-N改变到-B模式，创建0级备份
ontape –s –L 0 –A cem2 将数据库”cem2”从-N改变到-A模式，创建0级备份
####ontape工具在-U,-B,-A三种模式中任何一种改变到另一种不需创建系统备份； 要完全从不带日志模式改成带日志模式，或者反过来，需要创建一个0级备份；
另外，
create database dbname with log
创建数据库状态是U
create database dbname with buffered log
创建数据库状态是B
这两种都带日志，支持事务。
下面大致列一下，各个模式的含义：
-N No Logging 没有日志
-U Unbuffered Logging 非缓冲日志
-B Buffered Logging 缓冲日志
-A Unbuffered Logging, Mode ANSI ANSI模式
No Loggin 没有日志模式：只向逻辑日志中记录很少的信息，只能执行DDL语句，不支持事务，也就是不能执行DML语句。一个不带日志的数据库环境可以具有很高的吞吐率，但在发生严重的实例失败时没有能力重建对数据库的修改。
Unbuffered Logging 非缓冲日志模式：只要事务提交，就会将包含该事务信息的物理日志和逻辑日志缓冲区刷新到磁盘上。这样的话，即使出现严重的实例错误，数据完整性和一致性也可以在事务级得到保证。但是因为每一次提交事务都会导致缓冲区被刷新到磁盘上，所以增加了磁盘I/O。另外，因为刷新是按照当前事务的进度将整个缓冲区内容都写到逻辑日志中，所以逻辑日志的页面中会有很多没有用的数据。日志填充得很快，但其中包含的“真正”数据却比缓冲日志数据库环境少得多。
Buffered Logging 缓冲日志模式：环境将在逻辑日志和物理日志缓冲区中保留这些事务信息，直到该缓冲区填满，或者发生检查点操作，或者是当事务还没有被写往日志之前关闭了产生该事务的用户连接。在“缓冲日志”数据库环境中，每个事务所造成的磁盘I/O大大降低，因此实例会运行得较快，但是因为事务信息存储在共享内存中，严重的实例错误就会很危险，当实例的共享内存被释放时，那些还没有写到磁盘上的事务信息就都丢失了。
#####非缓冲日志模式和缓冲日志模式的操作方式完全相同，其不同点在于何时将日志记录写到磁盘上。
Unbuffered Logging, Mode ANSI ANSI模式：ANSI模式的操作与非缓冲日志一样，但它还强制与ANSI事务处理方式一致。ANSI一致性包括这样一些特点和规则，如对引用表的唯一属主命名，表级权限的不同缺省值，游标读和更新能力的不同，以及character和decimal数据类型对数据类型越界或定义语句如何反应的不同。
####OnLine Dymanic Server在ANSI数据库环境中并不严格强制遵从所有的ANSI标准，如果你执行一条非ANSI的SQL语句，实例会产生一条警告信息，但仍然往下处理。除非操作环境要求使用ANSI标准，否则使用ANSI模式不会得到任何好处。
另附几个语句：
查找进程的命令：onstat -g sql | grep dbname
删除进程的命令：onmode -z 进程号
删掉全部进程的命令：onmode -u
本文出自 “bilingling” 博客，请务必保留此出处http://bilingling.blog.51cto.com/11578217/1795678
原文地址：http://bilingling.blog.51cto.com/11578217/1795678
