博客园_兰斌专栏

数据库隔离等级

2012-01-06T07:36:00Z

数据库隔离等级决定并发时用户读和写的行为，非常重要。用户用SELECT读取数据时会默认使用共享锁（shared lock ），修改数据时会使用排他锁（exclusive lock）。我们不能控制写数据时请求的锁和锁数据持续的时间，但是幸运的是，我们可以控制读数据时的行为，从而来影响写数据的行为。

从SQL SERVER 2005开始，有6个隔离等级，分别是READ UNCOMMITTED, READ COMMITTED (default), REPEATABLE READ, SERIALIZABLE, SNAPSHOT和READ COMMITTED SNAPSHOT，其中，最后两个是2005新增的隔离等级。

设置隔离等级的语法大致如下：

SET TRANSACTION ISOLATION LEVEL <isolation name>。

SELECT ... FROM <table> WITH (<isolationname>);

第二种语法注意是不能有空格的，比如WITH (REPEATABLEREAD)，还有特定于这种语法使用的：NOLOCK=READUNCOMMITTED; HOLDLOCK=REPEATABLEREAD。

所有隔离等级从本质上来说是通过控制共享锁来达到各自的目的。

READ UNCOMMITTED

最低的一个隔离等级。在读取数据时不会请求共享锁。这样，就可以直接读取被排他锁锁住的数据，并发性最好。

这个等级会造成脏读，举例如下：

输入下面的脚本：

BEGIN TRAN;

UPDATE Production.Products
SET unitprice = unitprice + 1.00
WHERE productid = 2;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

如上所示，事物还未关闭，unitprice已经被更新为20，这时再打开一个连接，输入下面的脚本：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

首先把隔离等级设为READ UNCOMMITTED，然后查询数据，查出来的值为20。

这时，假如对第一个连接中的事务进行回滚：

ROLLBACK TRAN;

更新动作被取消，数据库中的实际值还是19，连接2里面读到的值就是脏读的结果。

READ COMMITTED

避免脏读的最低隔离等级，也是SQL SERVER数据库的默认隔离等级。

在这个等级中，只会读取事务已提交的数据，不会读取未提交的数据。在读取数据时会先请求在数据上加共享锁，如果有操作在更新这些数据，那么这些数据上已经有排它锁，读取必须等待排它锁释放后才能加共享锁，这样就达到了避免脏读的目的。

输入下面的脚本：

BEGIN TRAN;

UPDATE Production.Products
SET unitprice = unitprice + 1.00
WHERE productid = 2;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

在另一个连接中输入：

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

由于第一个连接的事物还未提交或回滚，所以第二个连接必须等待，直到排它锁释放。

SELECT语句在数据上加共享锁，查完数据后就会释放锁，即使在一个事务未提交或回滚的情况下，也是如此。

REPEATABLE READ

这个隔离等级可以解决不可重复读的问题。

可重复读可以考虑这样的场景，在一个事务中，从数据库读取了一个值，用于后续的判断，但是在判断之前，别的事务就把这个数据给更新成别的值，这样第一个事务中的值就不能在重复读取到了。

解决的本质是在一个事务中，当读取了数据后，并不立马释放共享锁，直到事务结束，这样可以阻止不是本事务的操作来影响数据。

输入脚本如下：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRAN;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

首先将隔离等级设为REPEATABLE READ，然后开启事务，读取了一个值。接着，在另一个连接中：

UPDATE Production.Products
SET unitprice = unitprice + 1.00
WHERE productid = 2;

会发现，第二个连接的UPDATE动作被阻塞，因为第一个连接在数据上加的共享锁还未解除。　　　　　　　　　　　　　　　　　　

另外能避免的一个问题是丢失更新。场景是当两个事务都需要读取同一个值，然后经过业务计算来更新值。在REPEATABLE READ之下的隔离等级，最后完成的事务会赢得这场胜利。在REPEATABLE READ下，这种场景将导致死锁，从而避免了丢失更新的问题，当然，死锁也是我们要设法避免的。

SERIALIZABLE

堪称堡垒级别的隔离。

REPEATABLE READ不能避免的是幻读（phantom）。因为只会在查询的数据上加锁，如果这是有别的事务INSERT了一条新的记录，这样，在事务中做第二次读取时就会读到这个新的行。

SERIALIZABLE在REPEATABLE READ保留共享锁到事务结束的基础上，还会锁定读取的结果集，从而达到避免幻读的目的。

举例：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

BEGIN TRAN

SELECT productid, productname, categoryid, unitprice
FROM Production.Products
WHERE categoryid = 1;

第二个连接：

INSERT INTO Production.Products
(productname, supplierid, categoryid,
unitprice, discontinued)
VALUES('Product ABCDE', 1, 1, 20.00, 0);

可以看到，第二个连接执行的INSERT被阻塞，直到第一个连接中的事务完成才能新增数据。

SNAPSHOT

SQL SERVER 2005引进了把事务提交前的数据版本保存到tempdb的能力。基于这个能力，新增了两个隔离等级。

要开启这个，需要执行下面的语句：

ALTER DATABASE XXX SET ALLOW_SNAPSHOT_ISOLATION ON;

第一个连接：

BEGIN TRAN;

UPDATE Production.Products
SET unitprice = unitprice + 1.00
WHERE productid = 2;
SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

第二个连接：

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

BEGIN TRAN;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

第二个连接都到的值就是已提交的最后一个版本，也就是19。即使第一个连接中的事务提交，只要第二个连接中还是这个事务中去做查询，读到的值始终是19，而不会是20。如果在第二个连接中开启一个新的事务，那么读到的值才是20。原来tempdb中的19也就不再需要了，会有一个一分钟启动一次的清理线程从tempdb中清理掉这个过时版本。

SNAPSHOT能避免更新冲突，比如在第一个连接中取unitprice的值，是19，然后更新unitprice为20，如果没有别的事务来搀和，这个是成功的。现在假设在第一个连接读取了unitprice值后，由另外一个连接对unitprice做了更新，然后第一个连接去更新unitprice值，报：

Msg 3960, Level 16, State 2, Line 1
Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot
isolation to access table 'Production.Products' directly or indirectly in database
'TSQLFundamentals2008' to update, delete, or insert the row that has been modified or
deleted by another transaction. Retry the transaction or change the isolation level for the
update/delete statement.

　　READ COMMITTED SNAPSHOT

也是基于数据版本。和上面一种的区别是，它会取到最后提交的版本。

ALTER DATABASE XXX SET READ_COMMITTED_SNAPSHOT ON;

这个标志开启后，数据库默认的隔离等级就是READ_COMMITTED_SNAPSHOT。

第一个连接：

BEGIN TRAN;

UPDATE Production.Products
SET unitprice = unitprice + 1.00
WHERE productid = 2;

SELECT productid, unitprice
FROM Production.Products
WHERE productid = 2;

在这个连接中，值为20，但是如果开启第二个连接，查询unitprice的值，还是19。

这时我们把第一个连接的事务做COMMIT，接着在第二个连接中再次查询unitprice的值，这就是和SNAPSHOT的区别了，是20。

最后是一张总图：


Isolation Level	Uncommitted Reads?	Non Repeatable Reads?	Lost Updates?	Phantom Reads?	Detects Update Conflicts?	Uses Row Versioning?
READ UNCOMMITTED	Yes	Yes	Yes	Yes	No	No
READ COMMITTED	No	Yes	Yes	Yes	No	No
READ COMMITTED SNAPSHOT	No	Yes	Yes	Yes	No	Yes
REPEATABLE READ	No	No	No	Yes	No	No
SERIALIZABLE	No	No	No	No	No	No
SNAPSHOT	No	No	No	No	Yes	Yes

本文链接

数据库连接池

2011-01-10T14:29:00Z

数据库连接池能使应用程序重用池中的连接。如果没有连接池，每次请求连接就需要耗费额外的性能开销来打开一个新的连接。

连接池是和连接字符串精确匹配的，对名称和值之间的空格也十分敏感。如果一个连接字符串没有匹配到现有的池，那么就会创建一个新的池。

每次请求一个连接时，都会到池中查找是否有可用的连接，如果没有，就创建一个新的连接，使用后通过Dispose或Close将连接池化。如果池中的连接达到了最大值，那么请求就必须排队等待。

如果连接生存期已过，或者连接池管理程序检测到和数据库的连接已经断了，连接池管理程序将从池中移除连接。

本文链接

转载：数据库sharding（scale up to scale out）

2010-07-22T05:54:00Z

sharding是将一个大数据库按照一定规则拆分成多个小数据库的一门技术.

当我们的应用数据量越来越多，访问量越来越大的时候，我们会作何选择？继续提升数据库服务器的性能还是采用一项技术让数据库平滑扩展？虽然伴随着服务器的更新换代，性能越来越好，更换更加豪华的服务器能暂时解决这个问题，但是无论是从花费和可控都无法让人满意。这时数据库sharding是一个更加可行的方案。

常用的sharding方案有以下几种，

1。按功能划分（垂直切分）

将不同功能相关的表放到不同的数据库中，譬如将用户管理相关表放到shard 1上，将blog相关表放到shard 2上。。。这样做的好处是非常直观，当需要用户列表时，我就到shard 1上获取。。。。这样也有一个问题，当某一部分的功能其数据量或性能要求超出了可控的范围，我们就需要继续对其进行深入的sharding。

2。按表中某一字段值的范围划分（水平切分）

当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对她进行进一步的切分。一种选择是根据key的范围来做切分，譬如userID为1-10000的放到shard 10上，userID为10000到20000的放到shanrd 11上。。。这样的扩展就是可预见的。另一种是根据某一字段值得来划分，譬如根据用户名的首字母，如果是a-d，就属于shard 20，e-h就属于shard 21。。。这样做也存在不均衡性，当某个范围超出了shard所能承受的范围就需要继续切分。还有按日期切分等等，

3。基于hash的切分

类似于memcached的key hash算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台shard。这种方法能够平均的来分配数据，但是伴随着数据量的增大，需要进行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash算法重新运算，数据需要重新割接。

4。基于路由表的切分

前面的几种方式都是跟据应用的数据来决定操作的shard，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。譬如我们在系统中维护一张表-（用户所属省-〉shard），这样每个用户我们知道是哪个省的，去路由表查找，就知道它所在的shard。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用程序的架构设计相关，你的设计必须适用这种增加。

虽然应用sharding会带来显而易见的好处，但是它也有一些固有的问题需要我们了解，这些问题大致分成以下几类，

1。shard的扩容

当当前的shard已经不能适用当前的应用需求时，就需要对shard数据库进行扩容，增加shard意味着需要对原有的shard数据进行迁移，这个过程是非常复杂，而且可能会导致数据的不一致（一边写、一边迁移）或者其他应用问题，因此扩容一般选择在凌晨等时间进行。

2。联合多个shard的表数据查询

这个是shard固有的问题，当遇到这样的问题时，你需要获取各个shard的数据，然后对这些数据进行汇总，很多时候因为现在的网络速度比较发达这个问题可以几乎被忽略掉。但是如果要进行数据的分析或挖掘，shard就会存在问题，通常面对这种对于数据要求不是那么实时的情况下，可以采用将shard数据同步到汇总数据库的方案，olap可以在这台汇总数据库上进行，这就需要在每台shard上进行数据的定时同步，这增加了程序的复杂性；如果要求实时的情况下，采用sharding方案会是一个毁灭性打击。

3。其他

我们现在做的系统就是采用的按照路由表切分的sharding方案，而且我们需要要求不是那么实时的汇总数据以提供数据的分析和挖掘，同时我们的基础数据都是在汇总数据库中进行管理，通过oracle的高级复制到shard节点上。在shard数据库向汇总数据库同步数据的时候，我们是通过oracle数据库的存储过程实现的，这种架构方式导致了数据库非常的复杂，同时还存在了一些其他问题，譬如同步会无缘无故的断掉。。。这就需要采用一些其他手段来维持数据的延迟一致性。

我们的sharding还在改进，我们的shard还在增加，我们还需要不断努力使我们的应用更加高效。

有时候觉得我们的社会就像一个巨大的多层sharding方案，中央、省（自治区）、市。。。

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

还有一种数据库方案是master-slave，一台master主要负责数据的更新，然后通过高级复制等手段将数据复制到各个slave节点，slave节点负责查询。这种结构是不管master和slave都拥有全部的数据，master到slave的数据存在一定的延迟。可以跟sharding方案结合使用。

本文链接

关于VS2005内置web服务器和IIS的区别问题(讨论,收集)

2007-02-13T09:51:00Z

关于使用VS2005内置服务器和IIS的问题

用SQLDMO掌握你的数据库信息

2006-10-17T02:10:00Z

SQLDMO,一个随SQL SERVER一起发布的COM对象，你能用它执行丰富的数据库功能！

在Linux中使用C#

2006-07-26T04:20:00Z

让.NET在Linux上起舞

方便你的测试（TestDriven.NET）

2006-07-20T06:54:00Z

TestDriven.NET和NCover，NCover，NCoverExplorer的介绍和应用

你期待已久的ASP.NET Atlas(一)[翻]

2006-07-14T05:39:00Z

原文地址：http://msdn.microsoft.com/msdnmag/issues/06/07/AtlasAtLast/ 近来开始看Atlas，体验了一下感觉挺不错的，先翻篇文章奉上，有翻的不好甚至有误的地方请大家指正，共同提高！这篇文章讨论以下几个方面：1.ASP.NET "Atlas"的介绍2.Atlas的体系结构3.客户端和服务器端的控件4.Atlas和Web服务在2005年9月的...

单元测试－－爱你不容易

2006-06-23T03:57:00Z

学习敏捷开发的时候接触到了单元测试。当时感觉这种方法真是太好了，测试功能代码是否如你想象的那样工作，可以减少以后的调试，也能给重构带来很多的方便。但现在我发现，在复杂的系统中，要做单元测试并不是那么容易的。这里我要声明一点，目前我为之写测试代码的系统基本已经开发了很久了，现在是想为方便以后的修改或重构而引入单元测试的。我这里主要要说的是系统的耦合度一旦比较高，写测试代码让我感觉相当困难。比如我们...

Ajax底层代码简析（可直接用的框架）

2006-05-25T03:42:00Z

近来忙毕业设计，又很长时间没写blog了。学ajax也有段时间了，理论是看了不少，也对MagicAjax框架做了下了解，当然要吃透它还是有很长的路要走。一直觉得对Ajax底层的代码应该总结一下。其实很底层的代码是比较简洁明了的，但功能却比较简单。一般我们都用Send(null).以前我一直在想我怎么来控制当异步传送Http请求时要调用的后台的指定的（我想用的）代码，现在终于明白了（唉，对自己...