两阶段提交(2PC Two Phase Commit)

    两阶段提交把事务提交分成两个阶段：

• 第一阶段，事务处理器向数据库服务器发出"准备提交"请求，数据库收到请求后执行相同的数据修改和日志记录等处理，不同的是处理完成后只是把事务的状态改成"可以提交",然后把结果返回给事务处理器。
• 事务处理器收到回应后进入第二阶段，如果在第一阶段内的危险期中发生了故障，事务处理器收不到回应，则认为事务失败，回撤事务。数据库服务器收不到第二阶段的确认提交请求，把"可以提交"的事务回撤.
• 两阶段的第二阶段中事务处理器向数据库服务器发出"确认提交"请求，数据库服务器把事务的"可以提交"状态改为"提交完成"状态，然后返回应答。

   从严格意义上说，两阶段提交并没有完全解决网络通讯危险期的问题，但因为第二阶段的处理很简单，只是修改了事务的状态，与第一阶段相比其处理时间极短，所以危险期极短，发生事务提交故障的可能性几乎不存在。 

　　---雇员表(EMPLOYE)

以下是代码片段：     CREATE TABLE EMPLOYE ( 　　EMPLOYEID INTEGER NOT NULL,---员工号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) VALUES 　　(1,'张三',1000), 　　(2,'李四',2000), 　　(3,'王五',3000), 　　(4,'赵六',4000), 　　(5,'高七',5000);

　　--经理表(MANAGER)

以下是代码片段：     CREATE TABLE MANAGER ( 　　EMPLOYEID INTEGER NOT NULL,---经理号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO MANAGER (MANAGERID,NAME,SALARY) VALUES 　　(3,'王五',5000), 　　(4,'赵六',6000);

　　---雇员表(EMPLOYE)

以下是代码片段：     CREATE TABLE EMPLOYE ( 　　EMPLOYEID INTEGER NOT NULL,---员工号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) VALUES 　　(1,'张三',1000), 　　(2,'李四',2000), 　　(3,'王五',3000), 　　(4,'赵六',4000), 　　(5,'高七',5000);

　　--经理表(MANAGER)

以下是代码片段：     CREATE TABLE MANAGER ( 　　EMPLOYEID INTEGER NOT NULL,---经理号 　　NAME VARCHAR(20) NOT NULL,---姓名 　　SALARY DOUBLE---薪水 　　); 　　INSERT INTO MANAGER (MANAGERID,NAME,SALARY) VALUES 　　(3,'王五',5000), 　　(4,'赵六',6000);

　　--更新存在的

以下是代码片段：     UPDATE EMPLOYE AS EM SET SALARY=(SELECT SALARY FROM MANAGER WHERE MANAGERID=EM.EMPLOYEID) 　　WHERE EMPLOYEID IN ( 　　SELECT MANAGERID FROM MANAGER 　　);

　　---插入不存在的

以下是代码片段：     INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) 　　SELECT MANAGERID,NAME,SALARY FROM MANAGER WHERE MANAGERID NOT IN ( 　　SELECT EMPLOYEID FROM EMPLOYE 　　);

　　--更新存在的

以下是代码片段：     UPDATE EMPLOYE AS EM SET SALARY=(SELECT SALARY FROM MANAGER WHERE MANAGERID=EM.EMPLOYEID) 　　WHERE EMPLOYEID IN ( 　　SELECT MANAGERID FROM MANAGER 　　);

　　---插入不存在的

以下是代码片段：     INSERT INTO EMPLOYE (EMPLOYEID,NAME,SALARY) 　　SELECT MANAGERID,NAME,SALARY FROM MANAGER WHERE MANAGERID NOT IN ( 　　SELECT EMPLOYEID FROM EMPLOYE 　　);

　　上面的处理是可以的，但是我们还可以有更简单的方法，就是用Merge语句，如下所示：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED THEN UPDATE SET EM.SALARY=MA.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY); 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED THEN UPDATE SET EM.SALARY=MA.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY);

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY); 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY);

　　不仔细的朋友可能没有看出上面两条语句的区别，哈哈，请仔细对比一下这两条语句。上面的语句中多了ELSE IGNORE语句，它的意思正如它英文的意思，其它情况忽略不处理。如果你认为理论上应该不存在EM.SALARY>MA.SALARY的数据，如果有，说明有问题，你想抛个异常，怎么办？如下：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'EM.SALARY>MA.SALARY' 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE; 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'EM.SALARY>MA.SALARY' 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE;

　　对于EM.SALARY>MA.SALARY的情况，如果你不想抛异常，而是删除EMPLOYE中的数据，怎么办？如下：

以下是代码片段：     MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN DELETE 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE; 　　MERGE INTO EMPLOYE AS EM 　　USING MANAGER AS MA 　　ON EM.EMPLOYEID=MA.MANAGERID 　　WHEN MATCHED AND EM.SALARY 　　WHEN MATCHED AND EM.SALARY>MA.SALARY THEN DELETE 　　WHEN NOT MATCHED THEN INSERT VALUES (MA.MANAGERID,MA.NAME,MA.SALARY) 　　ELSE IGNORE;

　　以上简单介绍了Merge语句的使用，它的应用不只是上面介绍的情况，其实它可以应用在很多其他语句不好处理情况，这需要你去发现，记住熟能生巧

MySQL

PostgreSQL

MSSQL Server

SQLite

MS Access

或是更简单的XML，文本文件等。这些数据库有优秀的文档，背后有强大的社区支持，大部分流行的CMS都使用了其中之一或多个，它们都易于使用，大多数托管服务供应商都提供了相应的产品，因此它们的使用量很多，名气也很大。但除了这些主流的数据库外，还有很多其它非主流数据库存在，其中有一些也开始受到人们的高度重视，下面我们就一起来看看吧，注意本文只介绍开源数据库，说不定在下一个项目中，你就有尝试它们的冲动。

1、MongoDB

MongoDB是一款开源，高性能，可扩展，无模式，面向文档(与JSON类似的数据模式)的数据库，它为时下最流行的编程语言提供了驱动，如PHP，Python，Perl，Ruby，JavaScript，C++等，支持全文索引，自动分片，跨LAN或WAN扩展，采用Key/Value方式存储数据。MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用。世界上最大的单词收录网站Wordnik就从MySQL转向了MongoDB。

2、Hypertable

Hypertable是一款高性能分布式数据存储系统，旨在为应用程序提供最好的性能，可扩展性和可靠性，它建立在Google的BigTable之上，主要面向大规模数据集应用，其目标是要成为世界上最好的大规模并发高性能数据库平台。百度目前也使用了Hypertable，也是它的赞助商。

3、Apache CouchDB

Apache CouchDB是一款面向文档的数据库，可以使用JavaScript通过MapReduce方法进行查询和索引，它提供了一个RESTful JSON API，因此可以在任何环境中通过HTTP访问，CouchDB内置了Web管理控制台，支持通过浏览器管理数据库。CouchDB使用Erlang编写，Erlang是一种健壮的函数式编程语言，非常适合于构建并发的分布式系统，Erlang的设计非常灵活，其可伸缩性与可扩展性都非常棒。

4、Neo4j

Neo4j是一个嵌入式，基于磁盘的，支持完整事务的Java持久化引擎，它在图像中而不是表中存储数据。Neo4j提供了大规模可扩展性，在一台机器上可以处理数十亿节点/关系/属性的图像，可以扩展到多台机器并行运行。相对于关系数据库来说，图形数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询——在关系数据库中，这些查询会导致大量的表连接，因此会产生性能上的问题。Neo4j重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。通过围绕图形进行数据建模，Neo4j会以相同的速度遍历节点与边，其遍历速度与构成图形的数据量没有任何关系。此外，Neo4j还提供了非常快的图形算法、推荐系统和OLAP风格的分析，而这一切在目前的RDBMS系统中都是无法实现的。

5、Riak

Riak是一款非常适合于Web应用程序的数据库，它提供了去中心化的Key/Value存储，灵活的map/reduce引擎和友好的HTTP/JSON查询接口。它是一个真正的容错系统，不会出现单点故障，在Riak世界中，没有哪台机器是特殊的或属核心服务器，它们都是对等的。

6、Oracle Berkeley DB

Oracle Berkeley DB是一系列开源的嵌入式数据库，使开发人员能够将一个快速、可伸缩、具有工业级别的可靠性和可用性的事务处理数据库引擎结合进他们的应用程序中。Berkeley DB最先由伯克利加州大学为了移除受到AT&T限制的程式码，从BSD 4.3到4.4时所改写的软件。Berkeley DB运行在大多数的操作系统中，例如大多数的UNIX系统， 和windows系统，以及实时操作系统。

7、Apache Cassandra

Cassandra是一款高可扩展性第二代分布式数据库，属于混合型的非关系的数据库，类似于Google的BigTable，支持的数据结构非常松散，类似于JSON的BJSON格式，因此可以存储比较复杂的数据类型。Cassandra最初由Facebook开发，后转变成了开源项目。Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra 的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。Facebook，Digg，Twitter和Cisco等大型网站都使用了Cassandra。

8、Memcached

Memcached是开源的分布式cache系统，现在很多的大型web应用程序包括facebook，youtube，wikipedia，yahoo等等都在使用memcached来支持他们每天数亿级的页面访问。通过把cache层与他们的web架构集成，他们的应用程序在提高了性能的同时，还大大降低了数据库的负载。

Memcached处理的原子是每一个key/value对，key会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。

9、Firebird

Firebird是一个关系数据库，可以运行在Linux，Windows和各种Unix平台上，Firebird相对MySQL和PostgreSQL来说比较小，这也使其可以称得上是理想的嵌入式数据库，可用于与其它应用程序服务器和应用程序捆绑。Firebird具有大部分成熟数据库所具有的功能，比如支持存储过程、SQL兼容等。

10、Redis

Redis是一款快速的Key/Value数据库引擎，它在保持键值数据库简单快捷特点的同时，又吸收了部分关系数据库的优点，从而使它的位置处于关系数据库和键值数据库之间。Redis不仅能保存Strings类型的数据，还能保存Lists类型(有序)和Sets类型(无序)的数据，而且还能完成排序(SORT)等高级功能，在实现INCR，SETNX等功能的时候，保证了其操作的原子性，除此以外，还支持主从复制等功能。Redis使用C语言编写，可以想memcached那样使用，放在传统数据库的前端，它支持许多编程语言，受到许多流行的项目使用，如GitHub和Engine Yard，有一个用PHP编写的客户端叫做Rediska，专门来管理Redis数据库。

11、HBase

HBase是一个分布式，面向列存储的数据库引擎，也可以叫做Hadoop数据库，因为它是Hadoop的子项目，HBase的目标是托管数十亿行，数百万列的大表，它提供了一个REST风格的Web服务器网关，支持XML，Protobuf和二进制数据编码选项。

12、Keyspace

Keyspace 是一家叫做 Scalien 的创业公司开发的高可靠 key/value 存储系统，Keyspace 强调的技术点是高可靠性，有以下一些特点：

Key/Value存储：一个 key/value 数据存储系统，只支持一些基本操作，如：SET(key, value) 和 GET(key) 等;

分布式：多台机器(nodes)同时存储数据和状态，彼此交换消息来保持数据一致，可视为一个完整的存储系统。为了更可靠，Keyspace 推荐使用奇数个 nodes，比如：3，5，7等;

数据一致：所有机器上的数据都是同步更新的、不用担心得到不一致的结果，Keyspace 使用著名的 Paxos 分布式算法;

冗余：所有机器(nodes)保存相同的数据，整个系统的存储能力取决于单台机器(node)的能力;

容错：如果有少数 nodes 出错，比如重启、当机、断网、网络丢包等各种 fault/fail 都不影响整个系统的运行;

高可靠性：容错、冗余等保证了 Keyspace 的可靠性。

13、4store

4store是一个容纳RDF数据的数据库存储和查询引擎，它使用ANSI C99编写，可在类Unix系统上运行，提供一个高性能，可扩展和稳定的平台。4store专门为无共享集群进行优化，最大可支持32节点集群，导入性能最大可以达到120kT/s，它的查询性能也相当出众。

14、MariaDB

MariaDB是一个向后兼容的，旨在替换MySQL数据库的MySQL分支，它包括所有主要的开源存储引擎，另外也开发了属于自己的Maria存储引擎。MariaDB是由原来 MySQL 的作者 Michael Widenius 创办的公司所开发的免费开源数据库服务器，与 MySQL 相比较，MariaDB 更强的地方在于：

Maria 存储引擎

PBXT 存储引擎

XtraDB 存储引擎

FederatedX 存储引擎

更快的复制查询处理

线程池

更少的警告和bug

运行速度更快

更多的 Extensions (More index parts, new startup options etc)

更好的功能测试

数据表消除

慢查询日志的扩展统计

支持对 Unicode 的排序

15、Drizzle

Drizzle是从MySQL衍生出来的一个数据库，但它的目的不是要取代MySQL，它的宗旨是构建一个“更精练、更轻量、更快速”的MySQL版本，它的扩展性和易用性与MySQL相当，但为了提高性能和扩展性，它从原来的核心系统里移除了部分功能。Drizzle是一种为云和网络程序进行了特别优化的数据库，它是为在现代多CPU/多核架构上实现大规模并发而设计的。

16、HyperSQL

HyperSQL是用Java编写的一款SQL关系数据库引擎，它的核心完全是多线程的，支持双向锁和MVCC(多版本并发控制)，几乎完整支持ANSI-92 SQL，支持常见数据类型，最新版本增加了对BLOB和CLOB数据的支持，最高支持达64T的数据量。同时，HyperSQL也是一个不错的嵌入式数据库。

17、MonetDB

MonetDB是一个高性能数据库引擎，主要用在数据挖掘，OLAP，GIS，XML Query，文本和多媒体检索等领域。MonetDB对DBMS的各个层都进行创新设计，如基于垂直分片的存储层，为现代CPU优化的查询执行架构，自动和自助调整索引，运行时查询优化，以及模块化的软件架构。MonetDB/SQL是MonetDB提供的关系数据库解决方案，MonetDB/XQuery是XML数据库解决方案，MonetDB Server是MonetDB的多模型数据库服务器。

18、Persevere

Persevere 是针对Javascript设计的基于REST的JSON数据库，分布式计算，持久对象映射的框架，提供独立的web服务器，主要用于设计富客户端应用，可以用在任何框架和客户端上。Persevere Server是一个基于Java/Rhino的对象存储引擎，在交互式的客户端JavaScript环境中提供持久性的JSON数据格式。

19、eXist-db

eXist-db是使用XML技术构建的数据库存储引擎，它根据XML数据模型存储XML数据，提供高效的，基于索引的XQuery查询。eXist-db支持许多Web技术标准，使得它非常适合Web应用程序开发：

XQuery 1.0 / XPath 2.0 / XSLT 1.0 (使用pache Xalan)或XSLT 2.0

HTTP接口：REST，WebDAV，SOAP，XMLRPC，Atom发布协议

XML数据库规范：XMLDB，Xupdate，XQuery更新扩展

最新的1.4版本还增加了基于Apache Lucene的全文索引，轻量级URL重写和MVC框架，以及对XProc的支持。eXist-db与XQuery标准高度兼容(目前XQTS的得分是99.4%)。

20、Gladius

Gladius是用纯PHP编写的平面文件数据库引擎，它的SQL语法与SQL92的一个子集兼容，它捆绑了一个轻量级的adoDB驱动。

21、CloudStore

CloudStore(以前叫做Kosmos文件系统)是一个开源的高性能分布式文件系统，它是用C++编写的，CloudStore可以和Hadoop以及Hypertable集成，这样就允许应用程序构建在那些系统上，而底层数据存储无缝地使用CloudStore。CloudStore支持Linux和Solaris，主要用来存储Web日志和Web爬行数据。

22、OpenQM

OpenQM是唯一一款同时有商业支持和免费的开源多值数据库，基于GPL协议发布，多值数据库对NoSQL运动起到了推动作用，它自身也因速度快，体积小，比关系数据库便宜而很快得到了认可。名称OpenQM中的Open表示开源版本，QM表示商业闭源QM数据库。商业版本支持Windows，Linux(RedHat，Fedora，Debian，Ubuntu)，FreeBSD，Mac OS X和Windows Mobile，其列表价格还不到其它多值产品的1/5，商业版本还包括一个GUI管理界面和终端模拟器，开源版本仅包括核心多值数据库引擎，主要是为开发人员准备的。

23、ScarletDME

ScarletDME也是一个开源多值数据库，它是OpenQM的社区分支版，最初由Ladybridge开发，这个项目创立于2008年11月28日，它既在独立开发自己的功能，也在为OpenQM贡献代码。这个项目最初的名字叫做Ladybridges GPL OpenQM，现在正式改为ScarletDME，其中的DME是Data Management Environment(数据管理环境)的首字母缩写。

24、SmallSQL

SmallSQL是一个100%纯Java编写的轻量级数据库，一般用于嵌入式领域，兼容SQL 99标准，支持JDBC 3.0 API，定位于高端Java桌面SQL数据库。支持所有能运行Java的平台，可直接嵌入到应用程序中。不过它也有一些不足，如没有网络接口，必须安装Java运行时，同一时间不能在多个应用程序之间共享数据库，没有用户管理。

25、LucidDB

LucidDB是唯一一款专注于数据仓库和商务智能的开源RDBMS，它使用了列存储架构，支持位图索引，哈希连接/聚合和页面级多版本，大部分数据库最初都注重事务处理能力，而分析功能都是后来才加上去的。相反，LucidDB中的所有组件从一开始就是为满足灵活的需求，高性能数据集成和大规模数据查询而设计的，此外，其架构设计彻底从用户出发，操作简单，完全无需DBA。

LucidDB对硬件要求也极低，即使不搭建集群环境，在单一的Linux或Windows服务器上也能获得极好的性能。最新版本还加入了对Mac OS X和Windows 64位的支持，官方网站上的文档和教程也非常丰富，非常值得你体验一下。

26、HyperGraphDB

HyperGraphDB是一种通用的，可扩展的，可移植的，分布式，嵌入式和开源数据存储机制，它是一个图形数据库，专门为人工智能和语义Web项目而设计，它也可用于任意规模的嵌入式面向对象的数据库。正如其名，HyperGraphDB是用来存储超图的，但它也属于一般图形数据库家族，作为一个图形数据库，它不施加任何限制，相比其他图形数据库它的功能更丰富。

HyperGraphDB非常稳定，已经应用在多个生产环境，包括一个搜索引擎和Seco scripting IDE。它支持*nix和Windows平台，需要Java 5+。

27、InfoGrid

InfoGrid是一个互联网图形数据库，它提供了许多额外的组件，使得在图像基础上开发RESTful Web应用程序变得更加容易。InfoGrid是开源的，包括一系列项目：

InfoGrid图形数据库项目 – InfoGrid的心脏GraphDatabase，可以独立使用，也可以附加到其它InfoGrid项目。

InfoGrid图形数据库网格项目 – 在GraphDatabase基础上增加了复制协议，因此多个分布式GraphDatabase就可以在一个非常大的图像管理环境中协作。

InfoGrid存储项目 –象SQL数据库和分布式NoSQL哈希表那样，为存储技术提供一个抽象的通用接口，这样InfoGrid GraphDatabase就可以使用任何存储技术持久化数据。

InfoGrid用户接口项目 – 将GraphDatabase中的内容以REST风格映射成浏览器可访问的URL。

InfoGrid轻量级身份识别项目 – 实现以用户为中心的身份识别技术，如LID和OpenID。

InfoGrid模型库项目 – 定义一个可复用对象模型库，作为InfoGrid应用程序的模式使用。

InfoGrid Probe项目 – 实现Probe框架，它允许开发人员将任何互联网上的数据源当作一个图像对象看待。

InfoGrid Utilities项目 – 收集InfoGrid使用的常见对象框架和实用代码。

28、Apache Derby

Apache Derby是Apache DB的子项目，它完全用Java编写，是一个开源关系数据库，它的体积非常小，基础引擎加上JDBC驱动只有2.6MB，它支持SQL标准，它提供了一个嵌入式JDBC驱动，因此可以嵌入到任何基于Java的应用程序中，Derby也支持常见的客户端/服务器模式，它也易于安装和使用。

29、hamsterdb

Hamsterdb是一个轻量级嵌入式NoSQL Key/Value存储引擎，它已经有5年历史，现在它的开发重点放在易用性，高性能，稳定性和可扩展性上。Hamsterdb支持事务(同一时间只能处理一个事务)，支持内存数据库，支持基于HTTP服务器的嵌入式远程数据库，支持日志/恢复，AES加密，基于zlib的压缩，支持C++，Python，.NET和Java编程语言。

30、H2 Database

H2 Database是一个开源的Java数据库，它的速度很快，包括JDBC API，支持嵌入式和服务器模式，内存数据库，提供了一个基于浏览器的控制台程序，它的体积也非常小，只有一个大小约1MB的jar文件，它还支持ODBC驱动和全文搜索。

31、EyeDB

EyeDB是一款基于ODMG 3规范的面向对象数据库管理系统，为C++和Java提供了编程接口，它功能非常强大，并且成熟，稳定和安全，实际上，它起源于1992年的Genome View项目，1994年又进行了重写，广泛用于生物信息项目。

32、txtSQL

txtSQL是一个面向对象的平面文件数据库管理系统，它使用PHP编写，支持对普通文本文件的操作，虽然是一个文本数据库，但同样支持SQL的一个子集，并且执行效率非常高，txtSQL使用文件系统的方法与MySQL的表和数据库原理类似，它有一个类似于phpMyAdmin管理界面。

33、db4o

db4o是一个面向对象的开源数据库，允许Java和.NET开发人员用一行代码存储和检索任何应用程序对象，无需预定义或维护一个独立的，僵化的数据模型，因为模型现在是由db4o根据需要自动创建和更新的。db4o成功的秘密是因为它的易用性，它原生为Java和.NET设计，存储数据对象的方法直接在应用程序中定义，因此db4o很容易集成到应用程序中，由于只需要一行代码，因此执行效率非常高。

34、Tokyo Cabinet

Tokyo Cabinet是一个Kay/Value型数据库，每个Key和Value的长度都可以不同，Kay和Value既可以是二进制数据，也可以是字符串，无数据表和数据类型的概念，记录是以哈希表、B+树和固定长度数组形式组织的。Tokyo Cabinet具有以下优点：

空间利用率高 – 数据文件尺寸更小;

执行效率高 – 更快的处理速度;

并发性能好 – 在多线程环境性能更好;

改善的可用性 – 简化的API;

改善的可靠性 – 即使在发生灾难的情况下，数据文件也不会损坏;

支持64位架构 – 支持海量的存储空间和巨型数据库文件。

Tokyo Cabinet是用C语言编写的，为C，Perl，Ruby，Java和Lua提供了API。

35、Voldemort项目

Voldemort是一个分布式Key/Value存储系统，它具有以下特点：

数据自动在多个服务器之间复制;

数据自动分区，因此每个服务器只包括整体数据的一个子集;

服务器故障处理是透明的;

支持插入式序列化，允许丰富的Key和Value类型，包括列表和元组，也可以集成常见的序列化框架，如Protocol Buffers，Thrift，Avro和Java Serialization

数据项支持版本化，即使在故障情况下，数据完整性也可以得到保障;

每个节点都是独立的，无需其他节点协调，因此也没有中央节点;

单节点性能优秀：根据机器配置、网络、磁盘系统和数据复制因素的不同，每秒可以执行10-20k操作;

支持地理分散式部署。

LinkedIn目前就使用Voldemort解决了高可伸缩性存储问题。

不知道你是否一口气看完本文，我想你也一定会惊讶于这么多开源数据库吧，事实上，本文也尚未完全罗列，欢迎你的补充。

DECLARE CURSOR WITH HOLD 语句

当用包括 WITH HOLD 子句的 DECLARE CURSOR 语句声明游标时，在落实该事务时任何打开的游标仍然打开；并且释放所有锁定，除保护打开的 WITH HOLD 游标的当前游标位置的锁定外。

如果回滚事务，则关闭所有打开的游标且释放所有锁定以及释放 LOB 定位器。

用银行的例子来说明事务的重要性是很经典的。假定某个客户从他的储蓄账户向支票账户转账500美元。这个操作包括连续执行的两个独立步骤。

(1) 储蓄账户减500美元。

(2) 支票账户增500美元。

图14-1显示了这个事务的两条SQL语句。设想，如果DBMS在执行了第一条语句，但没有执行第二条时突然发生故障——断电、系统崩溃、硬件出问题，账户在神不知鬼不觉的情况下出现了不平衡。渎职控告和牢狱之灾就会接踵而至。

图14-1　当银行客户从储蓄账户向支票账户转账时，必须有两条SQL语句

为了避免违法记录，应该使用事务来保证两条SQL语句都被执行，以维持账户平衡。如果事务中的一条语句无法执行时，DBMS将撤销（回滚）事务中其他语句。如果一切顺利，变化将被持久化（提交）。

执行事务

要了解事务如何工作，就要了解一些术语。

提交。提交（committing）事务是使自事务开始后修改的所有数据持久化在数据库中。在事务提交后，即使发生崩溃或其他故障，事务带来的所有变化仍然对其他用户可见并能够保证持久化。

回滚。回滚（rolling back）事务是撤销事务中SQL语句带来的所有变化。事务回滚后，此前影响到的数据回到原状，就好像SQL语句从未执行一样。

事务日志。事务日志文件（transaction logfile）或日志（log）是有关事务对数据库进行修改的一系列记录。事务日志记录了每个事务开始、数据的变化以及撤销或重新执行事务（如果将来需要）的足够信息。日志随着数据库事务的执行不断增长。

尽管保证每个事务本身的完整性是DBMS的职责，但依据组织或公司规章来开始和结束事务以保证数据逻辑的一致性则是数据库开发人员的责任。事务应该仅包含能做出一致修改的必要的SQL语句——不多不少。所有引用表中的数据在事务开始前和事务结束后必须保持一致。

在设计和执行事务时，要重点考虑以下方面。

l 事务相关的SQL语句会修改数据，所以执行事务要得到数据库管理员的授权。

l 事务过程应用于那些改变数据和数据库对象的语句（INSERT、UPDATE、DELETE、CREATE、ALTER、DROP——因不同DBMS而异）。对于工作中用到的数据库，每一条这样的语句都应该作为事务的一部分执行。

l 提交了的事务被称作持久化，意味着永久性改变，即便系统发生故障仍能保持。

l DBMS的数据恢复机制依赖于事务。当DBMS在故障之后被在线复原，DBMS检查事务日志确认是否所有事务都提交给了数据库。如发现没有提交（部分执行）的事务，依据日志将它们回滚。必须重新提交回滚的事务（尽管一些DBMS能够自动完成没有结束的事务）。

l DBMS的备份/恢复设备依赖于事务。备份设备获得例行的数据库快照并将它们和随后的事务日志存储在备份盘上。假定使用的硬盘发生故障使得数据和事务日志不可读。可以借助于恢复设备，它将采用最近的数据库备份并执行，或前滚所有从快照到故障前最后执行并在日志中提交的事务。这个恢复操作使数据库恢复到故障发生前的正确状态（注意，要再次提交没有提交的事务）。

l 显然，应该将数据库和它的事务日志存储于不同的物理硬盘。

因为事务按照要么全部，要么全不方式被执行，事务的边界（开始点和结束点）必须清晰。边界使DBMS作为一个原子单元来执行这些语句。事务隐式开始于第一个可执行的SQL语句或显式使用 START TRANSACTION语句。事务显式结束于COMMIT或ROLLBACK语句（无法隐式结束），且无法在提交之后回滚事务。

q

Oracle和DB2的事务总是隐式开始，这些DBMS没有用来开始事务的语句。在Microsoft Access、Microsoft SQL Server、MySQL和PostgreSQL中，可以使用BEGIN语句显式开始事务。SQL:1999引入START TRANSACTION语句——由于这发生在DBMS使用BEGIN开始事务很久以后，因此不同DBMS扩展BEGIN的语法也各不相同。MySQL和PostgreSQL支持START TRANSACTION（作为BEGIN同义词）。

在Microsoft Access或Microsoft SQL Server中，输入：

BEGIN TRANSACTION;

或

在MySQL or PostgreSQL，输入：

START TRANSACTION;

输入：

COMMIT;

输入：

ROLLBACK;

代码14-1中的SELECT语句显示UPDATE操作被DBMS执行后又被ROLLBACK语句取消。结果见图14-2。

                                    图14-2　运行代码14-1的结果。SELECT语
句的结果显示DBMS取消了操作

代码14-1　在一个事务内，更新操作（像插入和删除操作那样）永远不是在最后出现。结果见图14-2

SELECT SUM(pages), AVG(price) FROM titles;

BEGIN TRANSACTION;

  UPDATE titles SET pages = 0;

  UPDATE titles SET price = price * 2;

  SELECT SUM(pages), AVG(price) FROM titles;

ROLLBACK;

SELECT SUM(pages), AVG(price) FROM titles;

代码14-2显示更实用的事务例子。要从表publi- shers删除出版社P04而不产生引用完整性错误。因为表titles的有些外键值指向表publishers的出版社P04，所以要先删除表titles、titles_authors、和royalties中相关的行。应该使用事务保证所有DELETE语句都被执行。如果只有一些语句执行成功，数据将无法保持一致（要了解更多有关引用完整性检查的信息，参见11.7节）。

代码14-2　使用事务从表publishers中删除出版社P04，及删除其他表中与P04相关的行

BEGIN TRANSACTION;

  DELETE FROM title_authors

    WHERE title_id IN

      (SELECT title_id

         FROM titles

         WHERE pub_id = 'P04');

  DELETE FROM royalties

    WHERE title_id IN

      (SELECT title_id

         FROM titles

         WHERE pub_id = 'P04');

  DELETE FROM titles

    WHERE pub_id = 'P04';

  DELETE FROM publishers

    WHERE pub_id = 'P04';

COMMIT;

_ü提示

l 不要忘记使用COMMIT或ROLLBACK显式结束事务。没有结束点将导致回滚的最后未提交事务巨大，可能带来意外的数据变化或程序异常中止。因为事务在生存期锁定行、整个表、索引和其他资源，所以要让事务尽可能小。COMMIT或ROLLBACK为其他事务释放资源。

l 可以嵌套事务。最大嵌套数因DBMS而异。

使用一条SET语句的UPDATE更新多个列比使用多个UPDATE快。例如，查询：

UPDATE mytable

  SET col1 = 1

      col2 = 2

      col3 = 3

  WHERE col1 <> 1

     OR col2 <> 2

     OR col3 <> 3;

比3个UPDATE语句好，因为它减少了日志记录（尽管带来锁定）。

l 默认情况下，DBMS运行在自动提交模式（autocommit mode），除非被其他显式或隐式事务重写（或被系统设置关闭）。在这种模式下，每一条语句作为一个事务执行。如果语句执行成功，DBMS就将它提交；如果DBMS遇到错误，就回滚这条语句。

l 对于长的事务，可以设置称为存储点（savepoints）的中间标志，将事务分割为小段。存储点允许回滚从事务当前点到事务靠前的时间点之间的变化（假定事务还没有提交）。如果在一系列复杂的插入、更新、删除操作未提交时，意识到最后的变化是不正确的或不必要的，使用存储点就可以避免重新提交所有语句。Microsoft Access不支持存储点。在Oracle、DB2、MySQL和PostgreSQL中，使用语句：

SAVEPOINT savepoint_name

对于Microsoft SQL Server，使用：

SAVE TRANSACTION savepoint_name;

查阅DBMS文档来了解有关存储点锁定的细节知识及如何COMMIT或ROLLBACK到特定的存储点。

q

Microsoft Access中，通过SQL视图窗口或DAO无法执行事务，必须使用Microsoft Jet OLE DB Provider和ADO。

Oracle和DB2是隐式开始事务的。为了在Oracle 和 DB2中运行代码14-1和代码14-2，要删除语句：BEGIN TRANSACTION；

为了在MySQL中运行代码14-1和代码14-2，将语句BEGIN TRANSACTION;变为START TRANSACTION;（或BEGIN）。

MySQL通过InnoDB和BDB表支持事务，请查阅MySQL文档了解事务。Microsoft SQL Server、 Oracle、MySQL和PostgreSQL支持SET TRANSACTION语句设置事务特征。DB2通过服务器层和连接初始化设置控制事务特征。

　　OLTP：On_line Transaction Processing  联机事务处理

　　OLAP：On_line Analytical Processing   联机分析处理

　　OLTP顾名思义，以业务处理为主。OLAP则是专门为支持复杂的分析操作而设计的，侧重于对决策人员和高层管理人员的决策支持，可以应分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并以一直直观的形式把查询结果提供。

　　OLTP与OLAP 的主要区别有以下几点：

  （1）、所面向的用户和系统：OLTP是面向客户的，由职员或客户进行事务处理或者查询处理。OLAp是向向市场的，由经理、主管和分析人员进行数据分析和决策的。

  （2）、数据内容：OLTP系统管理当前数据，这些数据通常很琐碎，难以用于决策。OLAP系统管理大量历史数据，提供汇总和聚集机制，并在不同的粒度级别上存储和管理信息，这些特点使得数据适合于决策分析。

  （3）、数据库设计：通常，OLTP采用ER模型和面向应用的数据库设计，而OLAP系统通常采用星型模式或雪花模式和面向主题的数据库设计。

  （4）、视图：OLTP系统主要关注一个企业或部门的当前数据，而不涉及历史数据或不同组织的数据。与之相反，OLAP系统常常跨越一个企业的数据库模式的多个版本，OLAP系统也处理来自不同组织的信息，由多个数据源集成的信息。

  （5）、访问模式：OLTP系统的访问主要由短的原子事务组成，这种系统需要并发控制和恢复机制。而OLAP系统的访问大部份是只读操作，其中大部份是复杂查询。

  （6）、度量：OLTP专注于日常时实操作，所以以事务吞吐量为度量，OLAP以查询吞吐量和响应时间来度量。

以上初步辨识了这二个概念，以后对于满嘴跑概念的人可以略有防范。

这里我们创建了一个视图，并使用了with check option来限制了视图。 然后我们来看一下视图包含的结果：
select * from testview得到：
EMPNO ENAME
———- ———–
7654 MARTIN
7934 MILLER
这两条记录

然后我们在试图将其中一条更新：
update testview
set ename = ‘Mike’
where empno = 7654;
OK,这条更新语句可以执行，并没有什么问题，但是当我们执行另一条更新时：
update testview
set ename = ‘Robin’
where empno = ‘7654′;
就会出现ORA-01402: 视图 WITH CHECK OPTIDN 违反 where 子句的错误，这是因为什么呢？

这是因为前面我们在创建视图时指定了witch check option关键字，这也就是说，更新后的每一条数据仍然要满足创建视图时指定的where条件，所以我们这里发生了错误ORA-01402。

但是需要说明的时 ，虽然指定了with check option，我们还是可以删除视图中的数据。例如上例中，我们可以使用
delete from test where where empno =   7654

--------------------------------------------------------------------------------

我创建一个视图：  
  create   view   IS_student  
  as  
  select   sno,sname,sage  
  from   student  
  where   sdept='IS'  
  with   check   option;  
  加上了with   check   option;后，不能执行插入操作：  
   
  insert   into   is_student  
  values('95100','李娜',12)  
   
  什么原因？不加上with   check   option则可以！  
 
with   check   option可以这么解释：通过视图进行的修改，必须也能通过该视图看到修改后的结果。比如你insert，那么加的这条记录在刷新视图后必须可以看到；如果修改，修改完的结果也必须能通过该视图看到；如果删除，当然只能删除视图里有显示的记录。  
   
  --->而你只是查询出sdept='is'的纪录，你插入的根本不符合sdept='is'呀，所以就不行
 
默认情况下，由于行通过视图进行添加或更新，当其不再符合定义视图的查询的条件时，它们即从视图范围中消失。例如，可创建一个查询，从而定义一个视图以在表中检索所有员工薪水低于   $30,000   的行。如果该员工的薪水涨到了   $32,000，则查询视图时该特定员工将不再出现，因其薪水不符合视图所设的标准。但是，WITH   CHECK   OPTION   子句强制所有数据修改语句均根据视图执行，以符合定义视图的   SELECT   语句中所设的条件。如果使用该子句，修改行时需考虑到不让它在修改完后从视图中消失。任何可能导致行消失的修改都会被取消，并显示错误信息。  

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hippoppower/archive/2009/09/03/4516733.aspx

　　oracle 游标有4个属性：%ISOPEN，%FOUND，%NOTFOUND，%ROWCOUNT。

　　%ISOPEN判断游标是否被打开，如果打开%ISOPEN等于true,否则等于false；

　　%FOUND %NOTFOUND判断游标所在的行是否有效，如果有效，则%FOUNDD等于true，否则等于false；

　　%ROWCOUNT返回当前位置为止游标读取的记录行数。

　　隐式游标和显式游标

　　隐式游标
 
　　显式游标
 

PL/SQL维护，当执行查询时自动打开和关闭
 
在程序中显式定义、打开、关闭，游标有一个名字。
 

游标属性前缀是SQL
 
游标属性的前缀是游标名
 

属性%ISOPEN总是为FALSE
 
%ISOPEN根据游标的状态确定值
 

SELECT语句带有INTO子串，只有一行数据被处理
 
可以处理多行数据，在程序中设置循环，取出每一行数据。
 

 　　记录变量

　　定义一个记录变量使用TYPE命令和%ROWTYPE，

DECLARER_emp EMP%ROWTYPE;CURSOR c_emp IS SELECT * FROM emp;

　　或：

DECLARECURSOR c_emp IS SELECT ename,salary FROM emp;R_emp c_emp%ROWTYPE;

　　带参数的游标

　　与存储过程和函数相似，可以将参数传递给游标并在查询中使用。这对于处理在某种条件下打开游标的情况非常有用。它的语法如下：

　　CURSOR cursor_name[(parameter[,parameter],...)] IS select_statement;

　　定义参数的语法如下：

　　Parameter_name [IN] data_type[{:=|DEFAULT} value]

　　与存储过程不同的是，游标只能接受传递的值，而不能返回值。参数只定义数据类型，没有大小。　　
　　
　　另外可以给参数设定一个缺省值，当没有参数值传递给游标时，就使用缺省值。游标中定义的参数只是一个占位符，在别处引用该参数不一定可靠。
　　
　　在打开游标时给参数赋值，语法如下：

　　OPEN cursor_name[value[,value]....];

　　游标FOR循环

　　FOR循环的游标按照正常的声明方式声明，它的优点在于不需要显式的打开、关闭、取数据，测试数据的存在、定义存放数据的变量等等。游标FOR 循环的语法如下：

FOR record_name IN(corsor_name[(parameter[,parameter]...)]| (query_difinition)LOOPstatementsEND LOOP;

 
　　2 游标的更新和删除

　　在PL/SQL中依然可以使用UPDATE和DELETE语句更新或删除数据行。显式游标只有在需要获得多行数据的情况下使用。PL/SQL提供了仅仅使用游标就可以执行删除或更新记录的方法。

　　UPDATE或DELETE语句中的WHERE CURRENT OF子串专门处理要执行UPDATE或DELETE操作的表中取出的最近的数据。要使用这个方法，在声明游标时必须使用FOR UPDATE子串，当对话使用FOR UPDATE子串打开一个游标时，所有返回集中的数据行都将处于行级（ROW-LEVEL）独占式锁定，其他对象只能查询这些数据行，不能进行UPDATE、DELETE或SELECT...FOR UPDATE操作。

　　语法：

　　FOR UPDATE [OF [schema.]table.column[,[schema.]table.column]..
[nowait]

　　在多表查询中，使用OF子句来锁定特定的表,如果忽略了OF子句，那么所有表中选择的数据行都将被锁定。如果这些数据行已经被其他会话锁定，那么正常情况下ORACLE将等待，直到数据行解锁。

　　在UPDATE和DELETE中使用WHERE CURRENT OF子串的语法如下：

　　WHERE{CURRENT OF cursor_name|search_condition}

　　例：
DELCARECURSOR c1 IS SELECT empno,salaryFROM empWHERE comm IS NULLFOR UPDATE OF comm;v_comm NUMBER(10,2);BEGINFOR r1 IN c1 LOOPIF r1.salary<500 THENv_comm:=r1.salary*0.25;ELSEIF r1.salary<1000 THENv_comm:=r1.salary*0.20;ELSEIF r1.salary<3000 THENv_comm:=r1.salary*0.15;ELSEv_comm:=r1.salary*0.12;END IF;UPDATE emp;SET comm=v_commWHERE CURRENT OF c1l;END

本篇文章来源于 IT中国 转载请以链接形式注明出处 网址：http://www.it86.cc/oracle/2008/0410/30076.shtml

session: 一个由ORACLE用户产生的连接，一个用户可以产生多个SESSION ，但相互之间是独立的。

transaction:所有的改变都可以划分到transaction里，一个 transaction包含一个或多个SQL。当一个SESSION建立的时候就是一个TRANSACTION开始的时刻，此后transaction的 开始和结束由DCL控制，也就是每个COMMIT/ROLLBACK都标示着一个transaction的结束。

consistency：是对于statement级别而不是transaction级别来说的。sql statement 得到的数据都是以sql statement开始的IMAGE。

LOCK的基本情况：

update, insert ,delete, select ... for update会LOCK相应的ROW 。

只有一个TRANSACTION可以LOCK相应的行，也就是说如果一个ROW已经LOCKED了，那就不能被其他TRANSACTION所LOCK了。

LOCK由statement产生但却由TRANSACTION结尾（commit，rollback），也就是说一个SQL完成后LOCK还会存在，只有在COMMIT/ROLLBACK后才会RELEASE。

SELECT.... FOR UPDATE [OF cols] [NOWAIT];
OF cols
SELECT cols FROM tables [WHERE...] FOR UPDATE [OF cols] [NOWAIT];

前面的FOR UPDATE省略，下面我们来讲一下OF。

transaction A运行
select a.object_name,a.object_id from wwm2 a,wwm3 b
2 where b.status='VALID' and a.object_id=b.object_id
3* for update of a.status

则transaction B可以对b表wwm3的相应行进行DML操作,但不能对a表wwm2相应行进行DML操作.

反一下看看。

transaction A运行
select a.object_name,a.object_id from wwm2 a,wwm3 b
2 where b.status='VALID' and a.object_id=b.object_id
3* for update of b.status

则transaction B可以对a表wwm2的相应行进行DML操作,但不能对b表wwm3相应行进行DML操作.

也就是说LOCK的还是行,只是如果不加OF的话会对所有涉及的表LOCK的,加了OF后只会LOCK OF 字句所在的TABLE.

NOWAIT（如果一定要用FOR UPDATE，我更建议加上NOWAIT）

当有LOCK冲突时会提示错误并结束STATEMENT而不是在那里等待.返回错误是"ORA-00054: resource busy and acquire with NOWAIT specified"

另外如下用法也值得推荐，应该酌情考虑使用。

FOR UPDATE WAIT 5

5秒后会出现提示：

ORA-30006: resource busy; acquire with WAIT timeout expired
FOR UPDATE NOWAIT SKIP LOCKED;

出现提示：

no rows selected
TABLE LOCKS
LOCK TABLE table(s) IN EXCLUSIVE MODE [NOWAIT];

同样也是在transaction结束时才会释放lock。

DEADLOCK:

transaction a lock rowA , then transaction b lock rowB
then transaction a tries to lock rowB, 
and transaction b tries to lock rowA

也就是说两个transaction都相互试图去lock对方已经lock的ROW，都在等待对方释放自己的lock，这样就使死锁。另外，deadlock也会有600提示。

使用说明

Select…For Update语句的语法与select语句相同，只是在select语句的后面加FOR UPDATE [NOWAIT]子句。

该语句用来锁定特定的行（如果有where子句，就是满足where条件的那些行）。当这些行被锁定后，其他会话可以选择这些行，但不能更改或删除这些行，直到该语句的事务被commit语句或rollback语句结束为止。

本章主要讲解如下内容：

●       隔离级别和锁

●       加锁总结

●       乐观锁

●       内部锁

●       设置锁相关的注册变量

6.1  隔离级别和锁

要维护数据库的一致性和数据完整性，同时又允许多个应用程序同时访问一个数据库，将这样的特性称为并发性。DB2数据库尝试强制实施并发性的方法之一是使用隔离级别，它决定在第一个事务访问数据时，如何对其他事务锁定或隔离该事务所使用的数据。DB2使用下列隔离级别来强制实施并发性：

●       可重复读(Reapeatable Read，RR)

●       读稳定性(Read Stability，RS)

●       游标稳定性(Cursor Stability，CS)

●       未提交的读(Uncommitted Read，UR)

隔离级别是根据称为现象(Phenomena)的三个禁止操作序列来声明的：

●       脏读(Dirty Read)：在事务A提交修改结果之前，其他事务即可看到事务Ａ的修改结果。

●       不可重复读(Non-Repeatable Read)：在事务Ａ提交之前，允许其他事务修改和删除事务Ａ涉及的数据，导致事务Ａ中执行同样操作的结果集变小。

●       幻像读(Phantom Read)：事务Ａ在提交查询结果之前，其他事务可以插入或者更改事务A涉及的数据，导致事务A中执行同样操作的结果集增大。

数据库并发性(可以同时访问同一资源的事务数量)因隔离级别不同而有所差异，可重复读隔离级别可以防止所有现象，但是会大大降低并发性。未提交读隔离级别提供了最大的并发性，但可能会造成“脏读”、“幻像读”或“不可重复读”现象。DB2默认的隔离级别是CS。

6.1.1  可重复读

可重复读隔离级别是最严格的隔离级别。在使用它时，一个事务的操作结果完全与其他并发事务隔离，脏读、不可重复读、幻像读都不会发生。当使用可重复读隔离级别时，在事务执行期间会共享(S)锁定该事务以任何方式引用的所有行，在该事务中多次执行同一条SELECT语句，得到的结果数据集总是相同的。因此，使用可重复读隔离级别的事务可以多次检索同一行集，并可以对它们执行任意操作，直到提交或回滚操作终止事务。但是，在事务提交前，不允许其他事务执行会影响该事务正在访问的任何行的插入、更新或删除操作。为了确保这种行为，需要锁定该事务所引用的每一行—— 而不是仅锁定被实际检索或修改的那些行。因此，如果一个表中有1000行，但只检索两行，则整个表(1000行，而不仅是被检索的两行)都会被锁定。输出结果如下：

C:\>db2 +c select empno,firstnme,salary from employee where empno between '000010' and '000020' with  rr

EMPNO  FIRSTNME     SALARY

------ ------------ -----------

000010 CHRISTINE      152750.00

000020 MICHAEL         94250.00

  2 条记录已选择。

我们通过“get snapshot for locks on sample”命令来监控表加锁情况，输出结果如下：

C:\>db2 update monitor switches using lock on

DB20000I  UPDATE MONITOR SWITCHES命令成功完成。

C:\>db2 get snapshot for locks on sample | more

--------------略------------------

锁定列表

锁定名称                       = 0x020006000E0040010000000052

锁定属性                       = 0x00000010

发行版标志                     = 0x00000004

锁定计数                       = 1

挂起计数                       = 0

锁定对象名                     = 20971534

对象类型                       = 表

表空间名                       = USERSPACE1

表模式                        = DB2ADMIN

表名                         = EMPLOYEE

方式                           = S    --注：虽然读取了两行，但是整个表加S锁

如果使用这种隔离级别，不管你从表中读多少数据，整个表上都加S锁，直到该事务被提交或回滚，表上的锁才会被释放。这样可以保证在一个事务中即使多次读取同一行，都会得到相同结果集。另外，在同一事务中如果以同样的搜索标准重新打开已被处理过的游标，那么得到的结果集不会改变。可重复读相对于读稳定性而言，加锁的范围更大：对于读稳定性，应用程序只对符合要求的所有行加锁；而对于重复读，应用程序将对整个表都加S锁。

可重复读会锁定应用程序在工作单元中引用的整个表。利用可重复读，一个应用程序在打开游标的相同工作单元内发出一个SELECT语句两次，每次都返回相同的结果。利用可重复读隔离级别，不可能出现丢失更新、脏读和幻像读的情况。

在该工作单元完成之前，“可重复读”应用程序可以多次检索和操作这些行。但是，在该工作单元完成之前其他应用程序均不能更新、删除或插入可能会影响结果表的行。“可重复读”应用程序不能查看其他应用程序未提交的更改。

6.1.2  读稳定性

读稳定性隔离级别没有可重复读隔离级别那么严格；因此，它没有将事务与其他并发事务的效果完全隔离。读稳定性隔离级别可以防止脏读和不可重复读，但是可能出现幻像读。在使用这个隔离级别时，只锁定事务实际检索和修改的行。因此，如果一个表中有1000行，但只检索两行(通过索引扫描)，则只锁定被检索的两行(而不是所扫描的 1000 行)。因此，如果在同一个事务中发出同一个SELECT语句两次或更多次，那么每次产生的结果数据集可能不同。

与可重复读隔离级别一样，在读稳定性隔离级别下运行的事务可以检索一个行集(ROWS SET)，并可以对它们执行任意操作，直到事务终止。在这个事务存在期间，其他事务不能执行那些会影响这个事务检索到的行集的更新或删除操作，但是可以执行插入操作。如果插入的行与第一个事务的查询的选择条件匹配，那么这些行可能作为幻像出现在后续产生的结果数据集中。其他事务对其他行所作的更改，在提交之前是不可见的。下面我们还用上面的那个例子锁定读稳定性，输出结果如下：

C:\>db2 +c select empno,firstnme,salary from employee where empno between '000010' and '000020' with  rs

EMPNO  FIRSTNME     SALARY

------ ------------ -----------

000010 CHRISTINE      152750.00

000020 MICHAEL         94250.00

  2 条记录已选择。

我们通过“get snapshot for locks on sample”命令来监控表加锁情况，输出结果如下：

C:\>db2 update monitor switches using lock on

DB20000I  UPDATE MONITOR SWITCHES命令成功完成。

C:\>db2 get snapshot for locks on sample | more

--------------略------------------

锁定列表

锁定名称                       = 0x02000600050040010000000052

锁定属性                       = 0x00000010

发行版标志                     = 0x00000001

锁定计数                       = 1

挂起计数                       = 0

锁定对象名                     = 20971525

对象类型                       = 行

表名                 　　　　　= EMPLOYEE

方式                           = S　--注：只在读取的行上加S锁

锁定名称                       = 0x02000600040040010000000052

锁定属性                       = 0x00000010

发行版标志                     = 0x00000001

锁定计数                       = 1

挂起计数                       = 0

锁定对象名                     = 20971524

对象类型                       = 行

表名                 　　　　 = EMPLOYEE

方式                           = S　--注：只在读取的行上加S锁

锁定名称                       = 0x02000600000000000000000053

锁定属性                       = 0x00000010

发行版标志                     = 0x00000001

锁定计数                       = 1

挂起计数                       = 0

锁定对象名                     = 6

对象类型                       = 表

表名                 　　　　　= EMPLOYEE

方式                           = IS　--注：表上加IS锁

如果使用这种隔离级，那么在一个事务中将有N+1个锁，其中N是所有被读取(通过索引扫描)过的行的数目，这些行上都会被加上NS锁，在表上加上1个IS锁。这些锁直到该事务被提交或回滚才会被释放。这样可以保证在一个事务中即使多次读取同一行，得到的值也不会改变。但是使用这种隔离级别，在一个事务中，如果使用同样的搜索标准重新打开已被处理过的游标，则结果集可能改变(可能会增加某些行，这些行被称为幻影行(Phantom))。这是因为RS隔离级别不能阻止通过插入或更新操作在结果集中加入新行。

注意：

NS是下一键共享锁，此时锁拥有者和所有并发的事务都可以读(但不能更改)被锁定行中的数据。这种锁用来在使用读稳定性或游标稳定性事务隔离级别读取的数据上代替共享锁。

读稳定性(RS)只锁定应用程序在工作单元中检索的那些行。它确保在某个工作单元完成之前，在该工作单元运行期间的任何限定行读取不被其他应用程序进程更改，且确保不会读取由另一个应用程序进程所更改的任何行，直至该进程提交了这些更改。也就是说，不可能出现“不可重复读”情形。

“读稳定性”隔离级别的其中一个目标是提供较高并行性以及数据的稳定视图，为了有助于达到此目标，优化器确保在发生锁定升级前不获取表级锁定。

“读稳定性”隔离级别最适用于包括下列所有特征的应用程序：

●       在并发环境下运行。

●       需要限定某些行在工作单元运行期间保持稳定。

●       在工作单元中不会多次发出相同的查询，或者在同一工作单元中发出多次查询时并不要求该查询获得相同的回答。

6.1.3  游标稳定性

游标稳定性隔离级别在隔离事务效果方面非常宽松。它可以防止脏读；但有可能出现不可重复读和幻像读。这是因为在大多数情况下，游标稳定性隔离级别只锁定事务声明并打开的游标当前引用的行。

当使用游标稳定性隔离级别的事务通过游标从表中检索行时，其他事务不能更新或删除游标所引用的行。但是，如果被锁定的行本身不是用索引访问的，那么其他事务可以将新的行添加到表中，以及对被游标锁定行前后的行进行更新或删除操作。所获取的锁一直有效，直到游标重定位或事务终止为止(如果游标重定位，原来行上的锁就被释放，并获得游标现在引用的行上的锁)。此外，如果事务修改了它检索到的任何行，那么在事务终止之前，其他事务不能更新或删除该行，即使在游标不再位于被修改的行时。与可重复读和读稳定性隔离级别一样，其他事务在其他行上进行的更改，在这些更改提交之前对于使用游标稳定性隔离级别的事务(这是默认的隔离级别)是不可见的。我们还用上面那个例子，一个表中有1000行数据，我们只检索其中两行数据。那么对于可重复读隔离级别会锁住整个表，对于读稳定性隔离级别会对读到的数据(两行)加锁，而对于游标稳定性隔离级别只对游标当前所在那一行加锁，游标所在行的前一行和下一行都不加锁。下面我们举一个游标稳定性的例子，输出结果如下：

C:\>db2 +c declare c1 cursor for  select empno,firstnme,salary from employee where empno between '000010' and '000020' with cs

C:\>db2 +c open c1

C:\>db2 +c fetch c1

EMPNO   FIRSTNME      SALARY

------ ------------ -----------

000010 CHRISTINE      152750.00   --注：游标当前所在行，DB2只对这一行加锁。游标的

上一行和下一行都不加锁。当游标移动到下一行时，锁自动释放。

  1 条记录已选择。

我们通过“get snapshot for locks on sample”命令来监控表加锁情况，输出结果如下：

C:\>db2 update monitor switches using lock on

DB20000I  UPDATE MONITOR SWITCHES命令成功完成。

C:\>db2 get snapshot for locks on sample | more

--------------略------------------

锁定名称                         = 0x02000600040040010000000052

锁定属性                         = 0x00000010

发行版标志                       = 0x00000001

锁定计数                         = 1

挂起计数                         = 0

锁定对象名                       = 20971524

对象类型                       = 行

表名                          = EMPLOYEE

方式                             = S　--注：只在游标所在行上加S锁

锁定名称                         = 0x02000600000000000000000053

锁定属性                         = 0x00000010

发行版标志                       = 0x00000001

锁定计数                         = 1

挂起计数                         = 0

锁定对象名                       = 6

对象类型                       = 表

表名                            = EMPLOYEE

方式                            = IS　--注：表上加IS锁

如果使用这种隔离级，那么在一个事务中只有两个锁：结果集中只有正在被读取的那一行(游标指向的行)被加上NS锁，在表上加IS锁。其他未被处理的行上不加锁。这种隔离级别只能保证正在处理的行的值不会被其他并发的程序所改变。该隔离级别是DB2默认的隔离级别。

游标稳定性(CS)当在行上定位游标时会锁定任何由应用程序的事务所访问的行。此锁定在读取下一行或终止事务之前有效。但是，如果更改了某一行上的任何数据，那么在对数据库提交更改之前必须挂起该锁定。

对于具有“游标稳定性”的应用程序已检索的行，当该行上有任何可更新的游标时，任何其他应用程序都不能更新或删除该行。“游标稳定性”应用程序不能查看其他应用程序的未提交操作。

使用“游标稳定性”，可能会出现不可重复读和幻像读现象。“游标稳定性”是默认隔离级别，应在需要最大并行性，但只看到其他应用程序中的已提交行的情况下才使用。

6.1.4  未提交读

未提交读隔离级别是最不严格的隔离级别。实际上，在使用这个隔离级别时，仅当另一个事务试图删除或更改被检索的行所在的表时，才会锁定一个事务检索的行。因为在使用这种隔离级别时，行通常保持未锁定状态，所以脏读、不可重复读和幻像读都可能会发生。因此，未提交读隔离级别通常用于那些访问只读表和视图的事务，以及某些执行SELECT语句的事务(只要其他事务的未提交数据对这些语句没有负面效果)。

顾名思义，其他事务对行所做的更改在提交之前对于使用未提交读隔离级别的事务是可见的。但是，此类事务不能看见或访问其他事务DDL(CREATE、ALTER和DROP)语句所创建的表、视图或索引，直到那些事务被提交为止。类似地，如果其他事务删除了现有的表、视图或索引，那么仅当进行删除操作的事务终止时，使用未提交读隔离级别的事务才能知道这些对象不再存在了。

一定要注意一点：当运行在未提交读隔离级别下的事务使用可更新游标时，该事务的行为和在游标稳定性隔离级别下运行一样，并应用游标稳定性隔离级别的约束。下面我们举一个例子。

我们编写一个SQL存储过程，在存储过程中我们显式地在SELECT语句中使用UR隔离级别。

创建一个存储过程，保存为LOCKS.SQL，输出结果如下：

CREATE PROCEDURE locks()

LANGUAGE SQL

BEGIN

declare c1 cursor for select * from staff with UR;

open c1;

while 1=1 do　——注：死循环

end while;

END @

为了方便抓住锁信息，我们在这个存储过程的结尾处使用了一个死循环。利用一个命令窗口运行存储过程，输出结果如下：

C:\ >db2 –td@ -vf locks.sql

C:\ >db2 "call locks()"

再打开一个新的窗口，得到在STAFF表上的当前锁信息，输出结果如下：

C:\>db2pd -db sample -locks show detail

Locks:

Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg

0x408E0290 2 00020003000000000000000054 Table .IS G 2 1 0 0x0000 0x00000001

TbspaceID 2 TableID 3

但是会发现此时在STAFF表上出现的是IS锁，而不是IN锁。是什么原因呢？这是因为UR隔离级别允许应用程序存取其他事务的未落实的更改，但是对于只读和可更新这两种不同的游标类型，UR的工作方式有所不同。对于可更新的游标，当它使用隔离级别 UR 运行程序时，应用程序会自动使用隔离级别 CS。

在上面的例子当中，虽然显式地指定了SQL语句的隔离级别是UR，但是，由于在存储过程中使用的游标是模糊游标(也就是没有显式地声明游标是只读的还是可更新的)，因而系统会默认地将这个模糊游标当成可更新游标处理，存储过程的隔离级别自动从UR升级为CS。要防止此升级，可以采用以下办法：

●       修改应用程序中的游标，以使这些游标是非模糊游标。将SELECT语句更改为包括FOR READ ONLY子句。

●       将模糊游标保留在应用程序中，但是预编译程序或使用BLOCKING ALL和STATIC READONLY YES选项绑定它以允许在运行该程序时将任何模糊游标视为只读游标。

我们还是使用上面的例子，显式地将该游标声明成只读游标，输出结果如下：

declare c1 cursor for select * from staff for read only with UR;

此时我们再运行这个存储过程，并利用DB2PD获取锁的情况，输出结果如下：

c:\> db2pd -db sample -locks show locks

Locks:

Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg

0x408E07E0 2 00020003000000000000000054 Table .IN G 2 1 0 0x0000 0x00000001

TbspaceID 2 TableID 3

-注：可以看到STAFF表上出现的锁是IN锁。

从上面的例子中我们可以看到：“未提交读(UR)”隔离级别允许应用程序访问其他事务的未提交的更改。除非其他应用程序尝试删除或改变该表，否则该应用程序也不会锁定正读取的行而使其他应用程序不能访问该行。对于只读和可更新的游标，“未提交的读”的工作方式有所不同。

如果使用这种隔离级别，那么对于只读操作不加行锁。典型的只读操作包括：               SELECT语句的结果集只读(比如语句中包括ORDER BY子句)；定义游标时指明起为FOR FETCH ONLY或FOR READ ONLY。

该隔离级别可以改善应用程序的性能，同时可以达到最大程度的并发性。但是，应用程序的数据完整性将受到威胁。如果需要读取未提交的数据，该隔离级是唯一选择。

使用“未提交的读”，可能出现不可重复读行为和幻像读现象。“未提交读”隔离级别最常用于只读表上的查询，或者在仅执行选择语句且不关心是否可从其他应用程序中看到未提交的数据时也最常用。

以上我们所讲的隔离级别的加锁范围和持续时间都是针对读操作而言的。对于更改操作，被修改的行上会被加上X锁，无论使用何种隔离级别，X锁都直到提交或回滚之后才会被释放。

6.1.5  隔离级别加锁示例讲解

假设有一张表EMP1，表中有42条记录，我们使用FOR READ ONLY分别在UR、CS、RS和RR隔离级别下加锁。

EMP1表在本章后续的内容中也会使用到，其创建过程如下：

C:\> db2 "create table emp1 like employee"

C:\> db2 "insert into emp1 select * from employee"

我们使用EMP1表中JOB字段内容为'CLERK'的数据，输出结果如下：

C:\>db2 +c select empno,job,salary from emp1 where job='CLERK'  for read only

EMPNO  JOB      SALARY

------ -------- -----------

000120 CLERK       49250.00

000230 CLERK       42180.00

000240 CLERK       48760.00

000250 CLERK       49180.00

000260 CLERK       47250.00

000270 CLERK       37380.00

200120 CLERK       39250.00

200240 CLERK       37760.00

  8 条记录已选择。

在上面的SQL语句中，我们从表的42条记录中返回8条记录。下面我们分别看看这条语句在不同的隔离级别下加锁的情况：

●       UR隔离级别，输出结果如下：

C:\>db2 +c select empno,job,salary from emp1 where job='CLERK'  for read only with ur

EMPNO  JOB        SALARY

------ -------- -----------

000120 CLERK       49250.00

000230 CLERK       42180.00

000240 CLERK       48760.00

000250 CLERK       49180.00

000260 CLERK       47250.00

000270 CLERK       37380.00

200120 CLERK       39250.00

200240 CLERK       37760.00

  8 条记录已选择。

在另外一个窗口中使用“db2 get snapshot for locks on sample”命令监控，发现在UR隔离级别下，在表上有一个IN锁，没有加任何行锁。

●       CS隔离级别，输出结果如下：

C:\>db2 +c declare c1 cursor for select empno,job,salary from emp1  where job='CLERK'  for read only with CS

C: \>db2 +c open c1

C: \>db2 +c fetch c1

EMPNO  JOB        SALARY

------ -------- -----------

000120 CLERK       49250.00

  1 条记录已选择。

在另外一个窗口中使用“db2 get snapshot for locks on sample”命令监控，发现在CS隔离级别下，共有两个锁：在表上有一个IS锁，在行上有一个NS锁。

●       RS隔离级别，输出结果如下：

C:\>db2 +c select empno,job,salary from emp1 where job='CLERK'  for read only with RS

EMPNO  JOB      SALARY

------ -------- -----------

000120 CLERK       49250.00

000230 CLERK       42180.00

000240 CLERK       48760.00

000250 CLERK       49180.00

000260 CLERK       47250.00

000270 CLERK       37380.00

200120 CLERK       39250.00

200240 CLERK       37760.00

  8 条记录已选择。

在另外一个窗口中使用“db2 get snapshot for locks on sample”命令监控，发现在RS隔离级别下，共有9个锁：在表上有一个IS锁，在读取的8行上分别有1个NS锁。

●       RR隔离级别，输出结果如下：

C:\>db2 +c select empno,job,salary from emp1 where job='CLERK'  for read only with RR

EMPNO  JOB       SALARY

------ -------- -----------

000120 CLERK     49250.00

000230 CLERK     42180.00

000240 CLERK     48760.00

000250 CLERK     49180.00

000260 CLERK     47250.00

000270 CLERK     37380.00

200120 CLERK     39250.00

200240 CLERK     37760.00

  8 条记录已选择。

在另外一个窗口中使用“db2 get snapshot for locks on sample”命令监控，发现在RR隔离级别下，分为两种情况：

如果该SQL语句使用全表扫描，那么即使只读取了8行，也会在整个表上加一个S锁，输出结果如下：

C:\>dynexpln -d sample -q  "select empno,job,salary from emp1 where job='CLERK'

 for read only with rr" –t

Access Table Name = DB2ADMIN.EMP1  ID = 3,12

|  #Columns = 2

|  Relation Scan　--注：全表扫描

|  |  Prefetch: Eligible

|  Isolation Level: Repeatable Read　--注：RR隔离级别

|  Lock Intents

|  |  Table: Share　--注：整个表上加S锁

|  |  Row  : None

|  Sargable Predicate(s)

|  |  #Predicates = 1

|  |  Return Data to Application

|  |  |  #Columns = 3

Return Data Completion

End of section

如果创建索引，并进行索引扫描，那么表上加IS锁，读取的每行上加S锁。所以对于RR隔离级别来说，为了保证并发，尽可能创建合理的索引以减少加锁的范围，输出结果如下：

C:\>db2 create index job on DB2ADMIN.emp1(job)

DB20000I  SQL命令成功完成。

C:\>db2 runstats on table DB2ADMIN.emp1 and indexes all

DB20000I  RUNSTATS命令成功完成。

C:\>dynexpln -d sample -q  "select empno,job,salary from emp1 where job='CLERK'

 for read only with rr" -t

Access Table Name = DB2ADMIN.EMP1  ID = 3,12

|  Index Scan:  Name = DB2ADMIN.JOB  ID = 1　--注：索引扫描

|  |  Regular Index (Not Clustered)

|  |  Index Columns:

|  |  |  1: JOB (Ascending)

|  #Columns = 2

|  #Key Columns = 1

|  |  Start Key: Inclusive Value

|  |  |  |  1: 'CLERK   '

|  |  Stop Key: Inclusive Value

|  |  |  |  1: 'CLERK   '

|  Data Prefetch: Eligible 0

|  Index Prefetch: None

|  Isolation Level: Repeatable Read　--注：RR隔离级别

|  Lock Intents

|  |  Table: Intent Share　--注：表上加IS锁

|  |  Row  : Share　--注：行上加S锁

|  Sargable Predicate(s)

|  |  Return Data to Application

|  |  |  #Columns = 3

Return Data Completion

End of section

6.1.6  隔离级别摘要

表6-1按不期望的结果概述了几个不同的隔离级别。

表6-2提供了简单的试探方法，以帮助您为应用程序选择初始隔离级别。首先考虑表中列示的方法，并参阅先前对影响各隔离级别因素的讨论，可能会找到另一个更适合的隔离级别。

为避免应用程序出现用户无法容忍的现象，必须为其选择适当的隔离级别。在不同隔离级别下，应用程序锁定或释放资源需要不同的CPU和内存资源，所以隔离级别不但影响应用程序之间的隔离程度，还可能影响应用程序的个别性能特征。潜在的锁等待情况也会随隔离级别的不同而不同。

因为隔离级别确定访问数据时如何锁定数据并使数据不受其他进程影响，所以您在选择隔离级别时应该平衡并行性和数据完整性需求。您指定的隔离级别在工作单元运行期间生效。

选择正确的隔离级别

使用的隔离级别不仅影响数据库的并发性，而且影响并发应用程序的性能。通常，使用的隔离级别越严格，并发性就越小，某些应用程序的性能可能会随之越低，因为它们要等待资源上的锁被释放。那么，如何决定要使用哪种隔离级别呢？最好的方法是先确定哪些现象是不可接受的，然后选择能够防止这些现象发生的隔离级别。以下列举了各种隔离级别的适用情况：

●       如果正在执行大型查询，而且不希望并发事务所做的修改导致查询的多次运行返回不同的结果，则使用可重复读隔离级别。

●       如果希望在应用程序之间获得一定的并发性，还希望限定的行在事务执行期间保持稳定，则使用读稳定性隔离级别。

●       如果希望获得最大的并发性，同时不希望查询看到未提交的数据，则使用游标稳定性隔离级别。

●       如果正在只读的表/视图/数据库上执行查询，或者并不介意查询是否返回未提交的数据，则使用未提交读隔离级别。

设置隔离级别

尽管隔离级别控制事务级上的行为，但实际上它们是在应用程序级被指定的：

●       对于嵌入式SQL应用程序，在预编译时或在将应用程序绑定到数据库(如果使用延迟绑定)时指定隔离级别。在这种情况下，使用PRECOMPILE或BIND命令的ISOLATION选项来设置隔离级别。

●       对于开放数据库连接(ODBC)和调用级接口(Call Level Interface，CLI)应用程序，隔离级别是在应用程序运行时通过调用指定了SQL_ATTR_TXN_ISOLATION连接属性的SQLSetConnectAttr()函数进行设置的。另外，也可以通过指定DB2CLI.INI配置文件中的TXNISOLATION关键字的值来设置ODBC/CLI应用程序的隔离级别；但是，这种方法不够灵活，不能像第一种方法那样为一个应用程序中的不同事务修改隔离级别。

●       对于Java数据库连接(JDBC)和SQLJ应用程序，隔离级别是在应用程序运行时通过调用DB2的JAVA.SQL连接接口中的“setTransactionIsolation()”方法设置的。

当没有使用这些方法显式指定应用程序的隔离级别时，默认使用游标稳定性(CS)隔离级别。这个默认设置被应用于从命令行处理程序(CLP)执行的DB2 命令、SQL语句和脚本，以及嵌入式SQL、ODBC/CLI、JDBC和SQLJ应用程序。因此，也可以为从CLP执行的操作(以及传递给DB2 CLP进行处理的脚本)指定隔离级别。在这种情况下，隔离级别是通过在建立数据库连接之前在CLP中执行CHANGE ISOLATION命令设置的，输出结果如下：

C:\pp>db2 change isolation to ur

DB21027E  当连接至数据库时未能更改隔离级别。

C:\pp>db2 connect reset

DB20000I  SQL命令成功完成。

C:\pp>db2 change isolation to ur

DB21053W  当连接至不支持 UR 的数据库时，会发生自动升级。

DB20000I  CHANGE ISOLATION命令成功完成。

在DB2 V7.1及更高版本中，能够指定特定查询所用的隔离级别，方法是在SELECT SQL语句中加上WITH [RR | RS | CS | UR]子句。大家可以看到，本章前面的示例均使用这种方法举例。

e.g.事务A和事务B同时修改某行的值，

 1.事务A将数值改为1并提交

       2.事务B将数值改为2并提交。

这时数据的值为2，事务A所做的更新将会丢失。

解决办法：对行加锁，只允许并发一个更新事务。

二.未确认的相关性（脏读）
　　当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。

      e.g.

        1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务)         2.Mary读取自己的工资 ,发现自己的工资变为了8000，欢天喜地！

     3.而财务发现操作有误，回滚了事务,Mary的工资又变为了1000

      像这样,Mary记取的工资数8000是一个脏数据。

 解决办法：如果在第一个事务提交前，任何其他事务不可读取其修改过的值，则可  以避免该问题。

三.不一致的分析（非重复读）
　　当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。

      在一个事务中前后两次读取的结果并不致，导致了不可重复读。

e.g.

1.在事务1中，Mary 读取了自己的工资为1000,操作并没有完成

2.在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.

3.在事务1中，Mary 再次读取自己的工资时，工资变为了2000

解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。

 四.幻像读 　　 　

 　当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。

 　　e.g. 目前工资为1000的员工有10人。

1.事务1,读取所有工资为1000的员工。

2.这时事务2向employee表插入了一条员工记录，工资也为1000

3.事务1再次读取所有工资为1000的员工 共读取到了11条记录，

解决办法：如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/d8111/archive/2008/06/29/2595635.aspx

注意要加括号，在更改多个列的时候

ALTER      proc usp_clearActiveScoreCalcCommentScore
as
begin
update tbForum set UltimoScore=
   (case
    when AllScore-RemainScore<0 then 0
    else AllScore-RemainScore
   end),AllScore=
   (case
    when ActivityDegree>=0 and ActivityDegree<=300 then 250
    when ActivityDegree>=301 and ActivityDegree<=800 then 500
    when ActivityDegree>=801 and ActivityDegree<=2000 then 1000
    when ActivityDegree>=2001 and ActivityDegree<=4000 then 2000
    when ActivityDegree>=4001 and ActivityDegree<=8000 then 4500
    when ActivityDegree>8000 then 9000  
   end),UltimoDegree=ActivityDegree,ActivityDegree = 0
update tbForum set RemainScore=AllScore
end

   嵌入式SQL须解决下列几个问题：

  (1)如何将嵌有SQL的宿主语言程序编译成可执行码（这是首要问题）。
  (2)宿主语言和DBMS之间如何传递数据和信息。
  (3)如何将查询结果赋值给宿主语言程序中的变量（通过游标语句）。
  (4)宿主语言与SQL之间数据类型的转换问题（按系统约定转换）。

  以SQL嵌入C为例，说明实现的一般方法。

   如何在C中嵌入SQL？通常是以“EXEC SQL”开始，以“；”结尾。
   SQL与C之间数据的传送通过宿主变量。（即SQL中可引用的C语言变量）
   在SQL语句中引用宿主变量时，为了区别数据库中变量，宿主变量前须加“：”，它可与数据库中变量同名。在宿主语言语句中，宿主变量可与其它变量一样使用，不须加冒号。当宿主变量的数据类型与数据库中不一致时，由系统按约定转换。

   在宿主变量中，有一个系统定义的特殊变量，叫SQLCA（SQL通信区）。它是全局变量。供应用程序与DBMS之间通信用。

   EXEC  SQL  INCLUDE  SQLCA

   SQLCA中有一个分量叫SQLCODE，可表示为：SQLCA.SQLCODE. 它是一个整数，供DBMS向应用程序报告SQL语句执行情况用。

   SQLCODE > 0 ，SQL已执行，但有异常；
   SQLCODE < 0 ，SQL没执行，有错误；
   SQLCODE = 0 ，执行成功， 无异常。
  注：SQLCODE的值与具体含义，不同系统有所区别。 

  允许在嵌入的SQL语句中引用宿主语言的程序变量，但有两条规定：
（1）引用时，这些变量前必须加“：”作为前缀，
以示与数据库中变量区别。
（2）这些“共享变量”有宿主语言的持续定义，并用SQL的DECLARE语句说明。

  例如，在C语言中说明共享变量：
   EXEC  SQL  BEGIN  DECLARE  SECTION;/说明语句开头
         CHAR   SNO [7];
         CHAR   GIVENSNO[7];
         CHAR   CNO[6];
         CHAR   GIVENCNO[6];
         FLOAT  GRADE;
         SHORT  GRADEI;/*GRADEI是GRADE的指示变量，两者必须连用
   EXEC  SQL  END DECLARE  SECTION;/*说明语句结束

   SQL的集合处理方式与宿主语言单记录处理方式的协调
   由于SQL语句可以处理一组记录，而宿主语言语句一次只能处理一个记录，因此需要游标机制，把集合操作转换成单记录方式。

  嵌入式SQL的可执行语句内容包括：嵌入式DDL、QL、DML、及DCL语句，进入数据库的CONNECT语句以及控制事务结束的语句。
   对于SQL DDL语句，只要加上前缀标识“EXEC SQL”和结束标识“；”（对C语言），就能嵌入在宿主语言程序中使用。而SQL DML语句在嵌入使用时，要注意是否使用了游标机制。
   可执行语句格式：
   EXEC SQL CONNECT :uid IDENTIFIED BY :pwd；
   这里uid、pwd为两个宿主变量；uid为用户标识符，pwd为用户的口令。执行CONNECT前由宿主语言程序赋值。只有当CONNECT语句执行成功后才能执行事务处理中的其它可执行语句。

   例：
   EXEC SQL INSERT INTO SC (SNO, CNO, GRADE )
                   VALUES (:SNO, :CNO, :GRADE);
   功能：将一个元组插入到表SC中。
   插入的元组由三个宿主变量构成，由宿主语言程序赋值。  

   例：
   EXEC SQL SELECT GRADE
           INTO :GRADE,:GRADEI
           FROM SC
           WHERE SNO=:GIVENSNO AND CNO=:GIVENCNO;

   功能：查询学生成绩。
   如查询结果只有一个元组，可将结果直接用INTO子句对有关的宿主变量直接赋值。
   如查询结果超过一个元组，需在程序中开辟一个区域，存放查询的结果。该区域及其相应的数据结构称为游标。然后逐个地取出每个元组给宿主变量赋值。   

嵌入式SQL的实现，有两种处理方式：

   (1)扩充宿主语言的编译程序，使之能处理SQL语句；
   (2)采用预处理方式。
    
   目前多数系统采用后一种方式。预处理方式是先用预处理程序对源程序进行扫描，识别出SQL语句，并处理成宿主语言的过程调用语句；然后再用宿主语言的编译程序把源程序编译成目标程序。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/prayforever/archive/2008/08/06/2778495.aspx

@@12W03501.GIF;图2 ODBC体系结构@@
下面我们详细介绍各层的功能。
1. 应用程序层(Application)
使用ODBC接口的应用程序可执行以下任务：
①请求与数据源的连接和会话(SQLConnect)；
②向数据源发送SQL请求(SQLExecDirct或SQLExecute)；
③对SQL请求的结果定义存储区和数据格式；
④请求结果；
⑤处理错误；
⑥如果需要，把结果返回给用户；
⑦对事务进行控制，请求执行或回退操作(SQLTransact)；
⑧终止对数据源的连接(SQLDisconnect)。
2. 驱动程序管理器(Driver Manager)
由微软提供的驱动程序管理器是带有输入库的动态连接库ODBC.DLL，其主要目的是装入驱动程序，此外还执行以下工作:
①处理几个ODBC初始化调用；
②为每一个驱动程序提供ODBC函数入口点；
③为ODBC调用提供参数和次序验证。
3. 驱动程序(Driver)
驱动程序是实现ODBC函数和数据源交互的DLL，当应用程序调用SQL Connect或者SQLDriver Connect函数时，驱动程序管理器装入相应的驱动程序，它对来自应用程序的ODBC函数调用进行应答，按照其要求执行以下任务:
①建立与数据源的连接；
②向数据源提交请求；
③在应用程序需求时，转换数据格式；
④返回结果给应用程序；
⑤将运行错误格式化为标准代码返回；
⑥在需要时说明和处理光标。
以上这些功能都是对应用程序层功能的具体实现。驱动程序的配置方式可以划分为以下两种。
(1)单层次(single-tier) 这种方式下，驱动程序要处理ODBC调用SQL语句，并直接操纵数据库，因此具有数据存取功能。这种配置最常见的是同一台微机之上异种数据库通过ODBC存取，如在Powerbuilder中存取XBase、Excel、Paradox等数据文件,如图3所示。@@12W03502.GIF;图3 一层配置示意图@@
(2)多层次(multiple-tier) 这种配置中驱动程序仅仅处理ODBC调用，而将SQL语句交给服务器执行，然后返回结果。这种情况往往是应用程序、驱动程序管理器、驱动程序驻留在客户机端，而数据源和数据存取功能放在服务器端。譬如用Foxpro或Excel存取SQL Server或Oracle上的数据,如图4所示。
@@12W03503.GIF;图4 二层配置示意图@@
有时在以上两者之间加上网关以解决[本文由网站www.gwdq.com公文大全www.gwdq.cn收集整理]通信协议的转换等问题，这时驱动程序要将请求先传送给网关，如访问DEC RDB和IBM AS/400时的配置,如图5所示。
@@12W03504.GIF;图5 三层配置示意图@@
4. 数据源
数据源由用户想要存取的数据和它相关的操作系统、DBMS及网络环境组成。
四、一致性级别
从应用程序观点来看，最理想的情况是每个数据源和驱动程序都支持同一套ODBC函数调用和SQL语句。但是由于形形色色的DBMS在实现上有很大的差异，它们所依赖的系统和环境也各不相同，在对ODBC支持的程度上就不一致。一致性级别(Conformance Levels)建立了对众多功能的标准划分，为应用程序和驱动程序提供帮助和选择的依据。它划定了驱动程序所支持的ODBC函数和SQL语句的范围，我们可以用SQLGetInfo、SQLGetFunctions、SQLTypeInfo三个函数获知驱动程序所支持的功能集。ODBC从API和SQL语法两方面划分级别。
1. API的一致性
ODBC将函数调用划分为三级。
(1)核心API 它包括了与SAG的CLI相匹配的基本功能，包括：分配与释放环境、连接及语句句柄；连接到数据源；准备并执行SQL语句或立即执行SQL语句；为SQL语句和结果列中的参数分配存储器；从结果中检索数据，检索结果的信息；提交和撤消事务处理；检索错误信息。
(2)一级API 它包括了核心API的全部功能，比如用特定驱动程序的对话框连接到数据源；设置和查询语句值和连接选项；送部分或全部参数值；检索部分和全部结果；检索目录信息；检索关于驱动程序和数据源的信息。
(3)二级API 其功能包括核心和一级API的全部功能；浏览可获得的连接和可获得的数据源列表；发送参数值数组，检索结果数组；检索参数个数及参数描述；应用可卷动的光标；检索SQL语句和本机表格；检索各种目录信息；调用转换DLL。
2. SQL语法的一致性级别
从SQL方面可划分为最小的SQL语法、核心SQL语法和扩展SQL语法三个等级。
五、ODBC的应用与前景
ODBC的出现给用户描绘了一个诱人的前景，即网络中的Windows用户可以方便地访问各种数据库。现在，在微软推出的许多产品中都提供了ODBC支持，如Visal Basic 3.0、Visal C1.5、Excel 5.0、Word 6.0、FoxPro、Access等。同时其他一些应用软件和开发工具也提供了对ODBC的支持。因此用户只要安装不同的ODBC驱动程序，就可存取相应的数据库产品，而不管用户使用何种前台应用软件，也不管后台是何种数据库，这个存取的
本文来自: 公文大全(www.gwdq.com) 详细出处参考：http://www.gwdq.com/lwzx/jsj/jsjll/146960_2.html
过程是一致的。
但是由于ODBC产生的时间还不长，其应用也同时存在着一些问题。首先，它的层次比较多，表现在性能上比专有的API要慢，这是其标准化和开发性所带来的必要的代价；其次，由于ODBC规定了三个层次的一致性级别，应用程序与驱动程序之间的匹配就会出现一些问题和矛盾，比如某些驱动程序支持的级别比较低，而应用程序要求的比较高；再者，由于不同的驱动程序为不同的开发商所开发，测试工作不能统一，而现有的开发和测试工具并不很完善；同时，在非SQL的数据库系统上的应用也存在一些问题。
微软公司将ODBC作为一项很重要的技术，它已承诺进一步改进ODBC技术，为驱动程序开发者提供更先进的开发和测试工具，还将交付系统管理和监控工具，它还将与DBMS厂商和第三方厂商建立更密切的合作，以期使驱动程序支持更高级别的一致性，并在规范化方面有所完善。目前，ODBC已为数据库供应商组织内部所认可，同时为众多应用软件厂商和第三方开发商所使用，相信随着SQL的推广和规范，用户和开发商会更加依赖于这一技术
本文来自: 公文大全(www.gwdq.com) 详细出处参考：http://www.gwdq.com/lwzx/jsj/jsjll/146960_3.html

问题 在一台机器上运行DB2 CLI或者ODBC应用程序，必须要安装DB2运行客户端，DB2是否提供了单独的ODBC驱动程序？

解答 DB2在版本9.1以前，没有提供单独的ODBC/CLI驱动程序，如果要运行ODBC/CLI程序，您必须安装DB2的运行客户端，在DB2版本8.1补丁9以后，DB2还提供了一个轻量级的DB2运行客户端。但是没有提供单独的ODBC/CLI驱动程序。

从版本9.1开始，DB2提供了一个单独的ODBC/CLI驱动程序，现在，您只需安装ODBC/CLI驱动程序，就可以方便地运行您的ODBC/CLI应用程序了。通过使用单独的ODBC/CLI驱动程序，您可以将驱动程序包含在您的应用程序安装包中，使用该驱动程序，应用程序的大小，安装大小和内存需求都有所减少。

你可以单独安装ODBC/CLI驱动程序，驱动程序可以安装在已经包含DB2客户端的机器上，也可以在一台机器上安装多个ODBC/CLI驱动程序。

DB2 ODBC/CLI驱动程序需要通过ODBC驱动程序管理器加载，目前它符合ODBC 3.51标准。DB2 ODBC/CLI驱动程序提供如下功能：

* DB2 CLI API 运行环境
* ODBC API 运行环境
* XA API 运行环境
* 数据库连接功能
* 支持 LDAP 数据库目录
* 支持跟踪、日志和诊断功能
本文来自: IXPUB技术社区(www.ixpub.net) 详细出处参考：http://www.ixpub.net/thread-855959-1-1.html

创建序列需要CREATE SEQUENCE系统权限。序列的创建语法如下：

CREATE SEQUENCE 序列名

[INCREMENT BY n]

[START WITH n]

[{MAXVALUE/ MINVALUE n|NOMAXVALUE}]

[{CYCLE|NOCYCLE}]

[{CACHE n|NOCACHE}];

INCREMENT BY 用于定义序列的步长，如果省略，则默认为1，如果出现负值，则代表序列的值是按照此步长递减的。

START WITH 定义序列的初始值(即产生的第一个值)，默认为1。

MAXVALUE 定义序列生成器能产生的最大值。选项NOMAXVALUE是默认选项，代表没有最大值定义，这时对于递增序列，系统能够产生的最大值是10的27次方;对于递减序列，最大值是-1。

MINVALUE定义序列生成器能产生的最小值。选项NOMAXVALUE是默认选项，代表没有最小值定义，这时对于递减序列，系统能够产生的最小值是?10的26次方;对于递增序列，最小值是1。

CYCLE和NOCYCLE 表示当序列生成器的值达到限制值后是否循环。CYCLE代表循环，NOCYCLE代表不循环。如果循环，则当递增序列达到最大值时，循环到最小值;对于递减序列达到最小值时，循环到最大值。如果不循环，达到限制值后，继续产生新值就会发生错误。

CACHE(缓冲)定义存放序列的内存块的大小，默认为20。NOCACHE表示不对序列进行内存缓冲。对序列进行内存缓冲，可以改善序列的性能。

删除序列的语法是：

DROP SEQUENCE 序列名;

其中：

删除序列的人应该是序列的创建者或拥有DROP ANY SEQUENCE系统权限的用户。序列一旦删除就不能被引用了。

序列的某些部分也可以在使用中进行修改，但不能修改SATRT WITH选项。对序列的修改只影响随后产生的序号，已经产生的序号不变。修改序列的语法如下：

创建和删除序列

例1：创建序列：

CREATE SEQUENCE ABC INCREMENT BY 1 START WITH 10 MAXVALUE 9999999 NOCYCLE NOCACHE;

执行结果

序列已创建。