事务管理

使用TransactionScope类 正如名称所暗示，TransactionScope类用于限定事务代码块，其具有一些明显优点，例如范围与应用程序对象模型无关，同时提供了一个简单直观的编程模型等等。在该类的构造函数内部，TransactionScope对象创建了一个事务（.NET 2.0中默认时轻量级事务管理器），同时将该事务设置给Transaction类的Current属性。由于TransactionScope是可释放对象，所以事务将调用Dispose()方法释放该对象： using(TransactionScope scope = new TransactionScope()) { /*在这里实现事务性工作 */ // 没有错误——提交事务 scope.Complete(); } 示例2列举了一种在.NET 2.0中创建事务的方法。在TransactionScope对象定义的代码块中创建和释放该对象。使用TransactionScope对象的构造函数和TransactionScopeOption枚举，开发人员能够定义是否需要新事务，或者是否应该使用已经在外部块中存在的事务。TransactionScope.Complete()方法指示事务范围内的所有操作都已成功完成。在using语句结尾处（调用Dispose()方法的位置），定义了事务块的输出

转自： http://www.oschina.net/question/12_32573 二级索引与索引Join是Online业务系统要求存储引擎提供的基本特性。RDBMS支持得比较好，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来探讨如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook和官方Coprocessor方案的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果想实现了高性能地范围检索，必然需要依赖冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果对范围检索的性能要求不高，那么可以不考虑冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row

二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果你实现了高性能地范围检索，必然需要靠冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果你不要求高效地范围检索，那么可以不考虑产生冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row key存储索引

二级索引与索引Join是Online业务系统要求存储引擎提供的基本特性。RDBMS支持得比较好，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来探讨如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index,?ITHbase, Facebook和官方Coprocessor方案的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果想实现了高性能地范围检索，必然需要依赖冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果对范围检索的性能要求不高，那么可以不考虑冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row

二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性，RDBMS早已支持，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。 这篇文章会以HBase做为对象来讨论如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index, ITHbase, Facebook方案和官方Coprocessor的介绍。 理论目标 在HBase中实现二级索引与索引Join需要考虑三个目标： 1，高性能的范围检索。 2，数据的低冗余（存储所占的数据量）。 3，数据的一致性。 性能与数据冗余，一致性是相互制约的关系。 如果你实现了高性能地范围检索，必然需要靠冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。 如果你不要求高效地范围检索，那么可以不考虑产生冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。 理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。 这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正： 1，按索引建表 每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row key存储索引

作者：翟飞 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的 CRUD 等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。分布式事务在现在遍地都是分布式部署的系统中几乎是必要的。 我们先聊一下啥是事务？ 分布式事务、事务隔离级别、ACID我相信大家这些东西都耳熟能详了，那什么是事务呢？ 概念： 一般是指要做的或所做的事情。 指作为单个逻辑工作单元执行的一系列操作，要么全部执行，要么全部不执行。 简单的说，事务就是并发控制的单位，是用户定义的一个操作序列。 特性： 事务是恢复和并发控制的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。 原子性（atomicity）：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。 一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交

SQL SERVER锁的机制 SQL server的所有活动都会产生锁。锁定的单元越小，就越能越能提高并发处理能力，但是管理锁的开销越大。如何找到平衡点，使并发性和性能都可接受是SQL Server的难点。 SQL Server有如下几种琐： 1、 共享锁 用于只读操作(SELECT)，锁定共享的资源。共享锁不会阻止其他用户读，但是阻止其他的用户写和修改。 2、 更新锁 更新锁是一种意图锁，当一个事务已经请求共享琐后并试图请求一个独占锁的时候发生更新琐。例如当两个事务在几行数据行上都使用了共享锁，并同时试图获取独占锁以执行更新操作时，就发生了死锁：都在等待对方释放共享锁而实现独占锁。更新锁的目的是只让一个事务获得更新锁，防止这种情况的发生。 3、 独占锁 一次只能有一个独占锁用在一个资源上，并且阻止其他所有的锁包括共享缩。写是独占锁，可以有效的防止’脏读’。 4、 意图缩 在使用共享锁和独占锁之前，使用意图锁。从表的层次上查看意图锁，以判断事务能否获得共享锁和独占锁，提高了系统的性能，不需从页或者行上检查。 5、 计划锁 Sch-M,Sch-S。对数据库结构改变时用Sch-M，对查询进行编译时用Sch-S。这两种锁不会阻塞任何事务锁，包括独占锁。 读是共享锁，写是排他锁，先读后更新的操作是更新锁，更新锁成功并且改变了数据时更新锁升级到排他锁。锁的类型有： DB-----数据库，由于

T- SQL性能优化详解 http://www.cnblogs.com/weixing/p/3357519.html 故事开篇：你和你的团队经过不懈努力，终于使网站成功上线，刚开始时，注册用户较少，网站性能表现不错，但随着注册用户的增多，访问速度开始变慢，一些用户开始发来邮件表示抗议，事情变得越来越糟，为了留住用户，你开始着手调查访问变慢的原因。 　　经过紧张的调查，你发现问题出在数据库上，当应用程序尝试访问/更新数据时，数据库执行得相当慢，再次深入调查数据库后，你发现数据库表增长得很大，有些表甚至有上千万行数据，测试团队开始在生产数据库上测试，发现订单提交过程需要花5分钟时间，但在网站上线前的测试中，提交一次订单只需要2/3秒。 　　类似这种故事在世界各个角落每天都会上演，几乎每个开发人员在其开发生涯中都会遇到这种事情，我也曾多次遇到这种情况，因此我希望将我解决这种问题的经验和大家分享。 　　如果你正身处这种项目，逃避不是办法，只有勇敢地去面对现实。首先，我认为你的应用程序中一定没有写数据访问程序，我将在这个系列的文章中介绍如何编写最佳的数据访问程序，以及如何优化现有的数据访问程序。 　　 范围 　　在正式开始之前，有必要澄清一下本系列文章的写作边界，我想谈的是“事务性(OLTP)SQL Server数据库中的数据访问性能优化”，但文中介绍的这些技巧也可以用于其它数据库平台。 　

细说SYBASE数据库日志 　　SYBASE公司是世界著名的数据库厂家，其关系数据库产品SYBASE SQL Server在中国大中型企事业单位中拥有大量的用户。笔者在多年的使用过程中，总结出SYBASE数据库管理和维护的一些经验，现拿出来与大家分享。 　　我们知道，SYBASE　SQL Server用事务（Transaction）来跟踪所有数据库的变化。事务是SQL　Server的工作单元。一个事务包含一条或多条作为整体执行的T-SQL语句。每个数据库都有自己的事务日志（Transaction　Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。 　　 一、SYBASE　SQL Server 如何记录和读取日志信息 　　SYBASE SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL　Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL　Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。 　　 二、日志设备 　

并发控制 锁粒度： 表级锁 行级锁 锁： 读锁：共享锁，只读不可写（包括 自己当前用户 和当前事务） ，多个读互不阻塞 写锁：独占锁，排它锁，写锁会阻塞其它事务（不包括当前事务）的读和它锁 实现 存储引擎：自行实现其锁策略和锁粒度 服务器级：实现了锁，表级锁，用户可显式请求 分类： 隐式锁：由存储引擎自动施加锁 显式锁：用户手动请求 锁策略：在锁粒度及数据安全性寻求的平衡机制 显式使用锁 LOCK TABLES 加锁 lock tables tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: READ ,WRITE UNLOCK TABLES 解锁 FLUSH TABLES [tb_name[,...]] [WITH READ LOCK] 关闭所有正在打开的表，同时清除掉查询缓存以及准备好的语句缓存， 如果加上with read lock 选项的话，它代表关闭所有正在打开的表并加上全局锁（不清除缓存了）， 通常在备份前加全局读锁 SELECT clause [FOR UPDATE | LOCK IN SHARE MODE] 查询时加写或读锁 注意点1（加锁）： 注意，读锁加到表上之后，此表将只能读，不能进行其他任何操作。