① sqlserver锁表机制
这个问题要具体分析：
第一，事务隔离级别基本两种模式，一种是阻塞式（read committed，repeatable read，serializable）
，一种是非阻塞式(read uncommitted,snapshot)。
默认是read committed，这种情况一般在更新表的时候，如果不使用hint 提示，基本是先对表添加IX锁，级别不算高，基本和其他锁兼容，但是repeatable read，serializable 事务隔离级别就会先对表添加IX锁，然后向X锁转化，而X锁和大多数锁都不兼容，容易发生表阻塞。
第二种隔离级别不会有以上问题，但是又引入了其它的问题。
以上是一种情况。
另外一种就是 锁升级，一个锁是96B内存，如果太多，sqlserver就会升级为表锁，一般是5000以上行级锁就升级为一个表X锁。
所以适当的文件分组和表分区 是有必要的。
其次就是资源互相引用导致事务长时间不能释放，导致真正的死锁，不过SQL2005以后，这种情况发生的概率很低。
留个问题你自己去想。
两个SQL，两个连接，同时执行。
update A set A.NAME=xxx where A.id=55
update A set A.NAME=xxx where A.id=56, 如果 56 不存在你说会发生什么情况呢？
② 揭秘SQL Server 2014有哪些新特性
1、内存数据库
在传统的数据库表中，由于磁盘的物理结构限制，表和索引的结构为B-Tree，这就使得该类索引在大并发的OLTP环境中显得非常乏力，虽然有很多办法来解决这类问题，比如说乐观并发控制，应用程序缓存，分布式等。但成本依然会略高。而随着这些年硬件的发展，现在服务器拥有几百G内存并不罕见，此外由于NUMA架构的成熟，也消除了多CPU访问内存的瓶颈问题，因此内存数据库得以出现。
内存的学名叫做RandomAccess Memory（RAM），因此如其特性一样，是随机访问的，因此对于内存，对应的数据结构也会是Hash-Index，而并发的隔离方式也对应的变成了MVCC，因此内存数据库可以在同样的硬件资源下，Handle更多的并发和请求，并且不会被锁阻塞，而SQLServer 2014集成了这个强大的功能，并不像Oracle的TimesTen需要额外付费，因此结合SSDAS Buffer Pool特性，所产生的效果将会非常值得期待。
SQLServer内存数据库的表现形式
在SQL Server的Hekaton引擎由两部分组成：内存优化表和本地编译存储过程。虽然Hekaton集成进了关系数据库引擎，但访问他们的方法对于客户端是透明的，这也意味着从客户端应用程序的角度来看，并不会知道Hekaton引擎的存在。如图1所示。
图8.内存优化表+本地编译存储过程
因此不难看出，内存优化表+本地编译存储过程有接近几十倍的性能提升。
③ Oracle数据库和Sql server数据库各有什么优缺点
1.Oracle跨平台，SQL
Server只能运行在Windows上，而Windows能够安装的硬件是有限的，如Sun的Sparc服务器不能安装Windows，一些大型机、小型机也只能装UNIX，在这些高端机器上就只能跑Oracle了，这注定了Oracle就是高端数据库，而SQL
Server呢，中低端。
2.Oracle真正实现了行级锁，SQL
Server也宣称实现了行级锁，但你实际去试，如果不加索引，其实是不行的。
3.Oracle因为有多版本数据的技术，读写操作不会相互等待，虽然SQL
Server
2005学习Oracle增加了snapshot机制，从而也引进了多版本数据（MySQL也有多版本数据机制，不能说一定是学习Oracle），但是实际效果感觉就是2个版本的数据，隔离级别为read
committed时候，读写不再相互等待，但是把隔离设置为Serializable还是会产生读写相互等待。
4.Oracle的事务日志归档相当方便，而SQL
Server要用事务日志备份来实现，而且还要配置自动作业，启动agent服务。
5.Oracle的数据字典丰富，使得DBA容易判断数据库的各种情况，虽然SQL
Server
2005学习了Oracle的数据字典的特点，但从数量及方便程度上还是相差太多。个人感觉这是Oracle最人性化的地方。
6.Oracle的PL/SQL比SQL
Server的T-SQL功能强大很多。
7.Oracle的触发器比SQL
Server的种类多几种。
8.oracle的备份恢复原理相当简单明了，备份就在操作系统上拷贝数据文件好了，恢复呢，再拷贝回来，数据是旧的，不怕，应用重做日志好了。SQLServer呢，虽然原理在本质上还是这些，但操作起来麻烦多了，麻烦到让你体会不到其本质。
9.Oracle数据库启动可以有多个阶段，使得DBA可以在不同的情况下，通过启动到特定的阶段解决一些特殊问题，而SQLServer只要服务一启动，所有数据库就都打开了。
10．SQLServer给人的感觉是简单易用，但是我要说，如果你继续向前走，就会发现SQLServer的体系结构相当复杂（注意我这里是说的复杂），大体还是沿袭的Sybase的体系结构，这种复杂结构，估计很难有根本性的改变，而Oracle呢，时间越长你越会觉得其体系结构严谨，虽然开始会感觉很难。我的一个比喻，SQLServer是傻瓜相机（就是那些一两千的小数码），Oracle是单反相机（40D，5D，D300），如果你是入门者，那用傻瓜相机好了，在各种环境下拍摄，基本都过得去，用单反，光圈、快门都要自己设定，反倒不如傻瓜相机的效果，如果你是高手了，那傻瓜相机就很难得心应手了。
11．Oracle的书籍一般都比较深，随便一说就是一大批，EpertOracle、PracticalOracle8i、Cost－basedOracle，SQLServer呢，恐怕只有那套InsideSQLServer了，虽然SQLServer的书籍数量比Oracle的多的多（特别是在国内），但多数都是stepbystep的入门书。
12.对比SQL＊Plus与sqlcmd（或2000的osql，6.5的isql），sqlcmd的功能是太简陋，差得太多了。
13.SQLServer的最大优点就是和Windows结合紧密，易用，但是要注意事情都是两面的，这些优点可能导致其致命的缺点，例如易用，使得搞SQLServer的人可以不求甚解，有时候不求甚解是没问题的，但是有时候不求甚解可能会造成灾难，特别是对搞数据库的人来说。不好意思，本来要说SQLServer的优点呢，最后也成了缺点了。
④ sqlserver snapshot快照怎么用jdbc获取
数据库快照为你现有的数据库创建了一个数据库的壳，然后无论何时当数据页被修改的时候，改变也同时被写入稀疏文件(sparse file)当中
⑤ sqlserver 复制新增需要同步的对象一定要重新发布么
把属性 allow_anonymous 和 immediate_sync 改为false ,然后重新做snapshot,这样snapshot只会对新增加(异动)article升效...建议你先在test环境测试后再去proction.
⑥ sqlserver 并发问题
从来没有真正的同时写入
使用事务一个一个写入吧，不报错就成了，
还有，写操作速度很快的，完全不用纠结等待的时间
⑦ 如何查看sqlserver的启动/停止日志
您好，很高兴为您解答。
缺省情况下，在Program FilesMicrosoft SQL ServerMSSQLLog目录下。最近的错误日志名称是ERRORLOG,如果停止并重启SQL Server，旧的日志将被压缩和新建一个文件。此外，也可以通过DBCC ERRORLOG 命令或者sp_cycle_errorlog 系统存储过程回收错误日志。
[@more@]
以下是一些没有写在文档中但是众所周知的系统存储过程，这些存储过程可以从SQL Server自身读取错误日志。
exec xp_enumerrorlogs 1 will list SQL Engine errorlog file numbers
exec xp_readerrorlog <errorlognumber>, 1 will return the content of the requested Engine errorlog file.
exec xp_enumerrorlogs 2 will list the Agent error log file numbers
exec xp_readerrorlog <errorlognumber>, 2 will return the content of the requested Agent error log file.
举例：
exec xp_enumerrorlogs 2
存档# 日期 日志文件大小(字节)
1 08/06/2012 10:52 11399188
2 07/13/2012 00:58 1048
3 07/13/2012 00:55 1048
4 07/13/2012 00:55 12682508
5 06/16/2012 09:53 12869230
6 05/20/2012 05:38 10492
7 05/20/2012 05:25 11766
8 05/20/2012 05:08 10012278
9 04/29/2012 00:41 15371150
0 08/08/2012 11:30 939606
exec xp_readerrorlog 1, 2
时间 错误级别 内容
2012-07-13 01:07:03.0 3 [393] 正在等待 SQL Server 恢复数据库...
2012-07-13 01:18:29.0 3 [100] Microsoft SQLServerAgent 版本 9.00.1399.06 (内部版本号 x86 unicode 零售): 进程 ID 1996
2012-07-13 01:18:29.0 3 [101] SQL Server SVCTAG-4GCYY2X 版本 9.00.1399 (连接限制: 0)
2012-07-13 01:18:29.0 3 [102] SQL Server ODBC 驱动程序版本 9.00.1399
2012-07-13 01:18:29.0 3 [103] 驱动程序使用的 NetLib 是 DBNETLIB.DLL；本地主机服务器是
2012-07-13 01:18:29.0 3 [310] 检测到 8 个处理器和 4096 MB RAM
2012-07-13 01:18:29.0 3 [339] 本地计算机是 SVCTAG-4GCYY2X，运行的是 Windows NT 5.2 (3790) Service Pack 2
2012-07-13 01:18:29.0 3 [431] 正在填充子系统缓存...
2012-07-13 01:18:36.0 3 [432] 子系统缓存中有 11 个子系统
2012-07-13 01:18:36.0 3 [124] 已成功加载子系统“TSQL”(最大并发数: 160)
2012-07-13 01:18:37.0 3 [124] 已成功加载子系统“ActiveScripting”(最大并发数: 80)
2012-07-13 01:18:37.0 3 [124] 已成功加载子系统“CmdExec”(最大并发数: 80)
2012-07-13 01:18:38.0 3 [124] 已成功加载子系统“Snapshot”(最大并发数: 800)
2012-07-13 01:18:38.0 3 [124] 已成功加载子系统“LogReader”(最大并发数: 200)
~ O(∩_∩)O~
⑧ SQLServer快照功能以及其查询如何操作
SQLServer数据库的快照只能通过SQL语句创建，以msdb数据库为例进行说明：
1、执行以下代码，看看MSDB数据库有多少数据文件
EXEC SP_HELPDB msdb
查询结果是完全一样的。
（如有帮助，请采纳，谢谢）
⑨ sqlserver with snapshot 有什么作用
数据库快照为你现有的数据库创建了一个数据库的壳，然后无论何时当数据页被修改的时候，改变也同时被写入稀疏文件(sparse file)当中。当人们获取数据的时候，数据中没有变化的部分是从原始数据库中得到的，而改变的部分则是从稀疏文件中获得。
稀疏文件和数据库快照
当数据库快照被创建的时候，第一次的创建是十分迅速的。因为实际上只是创建了一个用来记录被修改文件的壳。随着时间的推移，文件不断的被修改，这些修改页都将被写进稀疏文件。你的主数据库中修改的文件越多，就有越多的文件被写入稀疏文件。因此，有越来越多的磁盘空间被用来保存你的主数据库和快照的数据库，也增加了你服务器的磁盘输入输出的次数。
稀疏文件被写入大小为64KB的分组块当中。每一个分组块增量能包含8个大小为8KB的数据页。所以，每次在你的主数据库中有任何的数据改变，都会先把数据页拷贝到稀疏文件当中，然后再将主数据库中文件的变化写入稀疏文件。一旦数据页被写入稀疏文件，他们就不再需要被写出来。因为页面的全部内容被保护起来，让其处于当快照建立时的状态。
为了实现优化磁盘并消除磁盘冲突，在主数据库以外的独立的驱动器和阵列中创建稀疏文件是一个明知之举。原因有二：
其一，当快照被建立的时候，没有数据被写入稀疏文件。从快照进行的所有的数据访问实际上都是在主数据库文件当中的。随着时间的推移，你会通过在不同的阵列和磁盘上从主文件数据库读取未被修改过的文件和从稀疏文件读取修改过的数据的方法来减少输入输出的负担。
其二，根据你数据库数据的易变动性和数据变化的数量，你可以通过将在主数据库的读取工作和稀疏文件的写入工作分离来减少输入输出的瓶颈大小。
使用数据库快照
在这里你一定要记住的事情就是，你的查询请求访问的依然是你的主数据库。当初始的快照被建立的时候，其实仅建立了一个空的壳子。所有的数据请求都是在主数据库文件中被完成的。随着时间的流逝和文件不断地被修改，就有一些数据请求从初始的数据库文件中分离出来指向了稀疏文件。所以，尽管看上去它是一个独立的数据库，那些根本的数据仍然是源于主数据库。
鉴于此，你需要确定不要试图去进行你日常活动范围以外的查询。这样说吧，你创建了一个快照，接着你进行了读写的操作，并对每个人做了记录。当那些记录被执行查询操作时，他们仍然继续影响着主数据库。所以你要保证任何新的活动都不会影响主数据的活动。
另外，你需要记住到底有哪些数据是被写入稀疏文件里的，而不是认为所有可能的数据都被写进了稀疏文件。基本上，当快照被创立时，主数据库的大小就是快照稀疏文件的潜在大小。如果稀疏文件中的数据量已经达到甚至超过数据库的一半时，也许再创造一个数据库的完整拷贝来取代现有的快照是一个更好的主意。
综上所述，我认为，数据库快照是一个非常新的功能。我也希望在SQL Server2005的所有版本，而不仅仅在企业版和开发版中可以应用这个功能。有一个没有讨论的地方就是我们没有讨论有关对数据库镜像使用快照。其实，无论是镜像还是原数据库，快照都给了你最好的方法。因为镜像是离线的，你并不能访问那些数据，所以说无论是镜像还是原数据库，它都给了你最好的方法。花一些时间去理解快照是如何应用于你的环境中的，并且确认你监视着维护快照的影响以及通过快照进行的数据存储。