博客园_SQL Server

MEMORYCLERK_SQLOPTIMIZER占用内存过高带来的性能问题

2012-04-24T03:08:00Z

记录一下之前遇到过两次服务器由于MEMORYCLERK_SQLOPTIMIZER占用内存过高带来的性能问题。

症状：
SQL Server突然变的特别慢，无论是读还是写。

检查：
如下图，可以看到当前正在进行的进程，等待类型是RESOURCE_SEMAPHORE，初步判断是内存不足造成；

接下来我们查看服务器内存配置：
可以看到SQL可用内存为29GB，实用29GB，没有问题，再继续，可以看到Single_page占到了27GB左右，这表明DataPage只占到了2GB，明显存在问题；

再接下，我们查看SinglePage内存占用情况，发现MEMORYCLERK_SQLOPTIMIZER占用了27GB左右；

可以基本确认是由于MEMORYCLERK_SQLOPTIMIZER占用内存太多造成。
临时解决：重启SQLService.
原因猜测应该是由于提交了大批量的SQL造成，重现做要时间，暂未找到具体SQL.

本文链接

DBMIRROR_DBM_EVENT

2012-03-21T07:23:00Z

原文：http://blogs.msdn.com/b/grahamk/archive/2011/01/10/sql-server-blocking-caused-by-database-mirroring-wait-type-dbmirror-dbm-event.aspx

I was looking at a problem this morning about long blocking chains caused by the wait type DBMIRROR_DBM_EVENT, and it makes an interesting case study about database mirroring, blocking, undocumented wait types and general troubleshooting techniques for database mirroring. The information following relates ONLY to SQL 2005, SQL 2008 and SQL 2008 R2. However since the undocumented wait type is not supported, it is not guaranteed to be relevant to future versions higher than SQL 2008 R2 and considering the enhancements coming in this area of functionality, it may well be completely different.

First off some thoughts about looking at root cause analysis of database mirroring problems. We see quite a few of these and often people do not have the appropriate data with which is make a full analysis. Typical examples being unexpected failovers, slow performance and sometimes blocking. Obviously the more data you have the easier, but some of key parts for looking at DBM problems historically are this:

The perfmon counters in the SQLServer:Database Mirroring and SQLServer:Service Broker objects.

Default profiler trace files (people often forget these but they have very useful DBM state change audit information in them)

SQL Server Error Logs

windows event logs

backup of msdb database (this contains useful meta data such as the size of every log backup and the DBM monitor meta data if you've enabled it)

memory dumps (if any were produced)

Obviously if you've also proactively collected MPSReports or SQLDIAG as well, then this will be no bad thing. Back to my specific scenario.....

In this example the symptom was that a huge blocking chain built on a high volume OLTP database where all the head blockers were waiting on DBMIRROR_DBM_EVENT. Here is the sequence of events I went through:

1. Review the blocking chain itself - ho help here as all we can see is that we're waiting on DBMIRROR_DBM_EVENT

2. Review the source for the undocumented wait type. Obviously you can't do this outside of MS, but I can say that at the time of writing this wait type represents the wait used when the principal is waiting for the mirror to harden an LSN, meaning that the transaction it's part of cannot commit. This immediately points quite specifically to the problem that the principal cannot commit transactions as it's waiting on the mirror. Now we need to investigate why the mirror is not committing transactions or why the principal doesn't know whether it is.

3. Review the msdb system tables

(a) Look at the [backupset] table to see if the size of the logs produced at the time of the problem are significantly higher then normal. If they were exceptionally large it may be that the mirror was flooded with transactions and could simply not keep up with the volume. This is why books online will tell you sometimes to disable mirroring if you need to do an exceptionally large logged operation such as an index rebuild. (reference for why this is at http://technet.microsoft.com/en-us/library/cc917681.aspx). Here i used the following TSQL

SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go

select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'

(b) secondly I looked at the data in the tables [dbm_monitor_data]. The key here is to locate the timeframe in which we had a problem and then see if we were significant experiencing changes in any of the following:

log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate

These are all indicators similar to part (a) in that they might show a component or piece of architecture that wasn't responding. For example if the send_queue suddenly starts to grow but the re_do queue doesn't grow, then it would imply that the the principal cannot send the log records to the mirror so you'd want to look at connectivity maybe, or the service broker queues dealing with the actual transmissions.

In this particular scenario we noted that all the counters appeared to have strange values, in that there were log backups going on of normal sizes, but there were no status changes, 0 send queue, 0 redo queue, a flat send rate and a flat redo rate. This is very strange as it implies that the DBM Monitor could not record any values from anywhere over the problem period.

4. Review the SQL Server error logs. In this case there were no errors or information messages whatsoever, but in other scenarios such as this, it’s very common for errors in the 1400 range to be reported, examples of which you can find in other places in my other mirroring blogs, such as this Error 1413 example

5. Review the default trace files – in this scenario I was not provided the default traces, however they are fantastic sources of DBM problem information, as they record state change events on all the partners.This is documented here:

Database Mirroring State Change Event Class

This often gives you a great picture of scenarios such as when network connectivity failed between one or all of the partners and then what the state of the partnership became afterwards.

CONCLUSIONS:

In this particular scenario I’m currently missing 2 key points of data, but that apart I can still make a reasonable hypothesis on the above information. We certainly can say that the blocking was caused by the fact that DBM was enabled to the due the blockers all waiting on the DBMIRROR_DBM_EVENT wait type. Since we know we didn’t flood the mirror with a large logged operation and that this deployment normally runs happily in this mode, we can exclude unusual large operations. This means that we have 2 potential candidates at this stage:

1. Hardware problems on the connectivity between some or all of the partners.

2. CPU exhaustion on the mirror server – simply unable to keep up with redos – the CPU exhaustion could itself be from a process outside of SQL Server or outside of the this mirror partnership.

3. A problem with the mirroring code itself (we’d really need some memory dumps to confirm this though).

Based upon experience I’d suspect 1 or 2, but I always keep an open mind about 3 as well, we’re trying to collect some more data now to look at this problem in more detail.

As a final note though I noted some similar scenarios on the forums, and one particular one of note where the poster said that everything worked fine until they enabled mirroring, at which point the system ground to a halt with this wait type. This is far more likely to be a non-optimal configuration where some section of the architecture can simply not keep up with the volume of requests required by the partnership, and is a perfect example of why one must benchmark mirror deployments very carefully. In that scenario you should review this KB first : http://support.microsoft.com/kb/2001270

本文链接

SQL Server 2008 Uninstall - Restart Computer Failure

2012-03-12T08:30:00Z

Today, I uninstalled the SQL Server 2008 on Windows Server 2003 and encountered an issue with "Restart computer", But restart computer many times, it was still this error.
Finally, I got it from "http://ntsblog.homedev.com.au/index.php/2010/05/05/sql-server-2008-uninstall-restart-computer-failure/"

To resolve that need to do below steps:
1.Leave the "Setup Support Rule" UI open if you are already in there

2.Delete "PendingFileRenameOperations”" from key”HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager”

3.Reclick "Re-run".

Now It does work well.

本文链接

SQL Server 2008 install SP3后，发布数据库log变得越来越大

2012-03-08T02:15:00Z

起因：
前一段时间在为一组sql server 2008 failover cluster安装sp3，之前是sq1.
windows server 2003 enterprise 64bit + sql server 2008 enterprise 64bit
failover cluster 是active/acitve 双实例

问题：
在两个节点都install sp3后，发现有一个sql server实例在切换时（其实也就是在restart sql server service)，用SSMS连接时会显示“服务器处于脚本升级模式。此时只有管理员可以进行连接”，大概几分钟，之后就正常了，当时就并未重视。过了段时间，在例行维护切换时，问题重现，此时意识到之前安装sp3的时候应该存在问题。最近发现该实例上一个发布的库，log文件增长到了近30GB，于是考虑收缩该Log文件。但在收缩时，发现尽管不停的备份log，仍然无法收缩Log文件。

检查：

通过查看该库的log_reuse_wait_desc，发现值为ACTIVE_TRANSACTION

于是查看虚拟日志文件使用情况，发现有2000多个虚拟日志文件都为活动状态

查看活动的事务信息，发现一个名为tran_sp_mscreate_peer_tables自从2012.02.02 晚10点43起一起到现在，而这个时间是上次切换该cluster时间;

近一步验证，transaction_type=1标明是写操作；

从sql server errorlog内发现Error executing sp_vupgrade_replication.

推断应该是在生升发布订阅相关对象时失败，导致事务尽管已被发布到分发，但无法标记为已分发，也就始终无法截断它们并重用。

解决：
目前google到的方法大概是：
1.disabled sql agent service
2.stop sql server service and sql agent service
3.only start sql server service
4.execute sp_vupgrade_replication
5.restart sql server service
6.enable and start sql agent service.

在操作过程中，sql server 处于脚本升级模式，不可以连接。

2012.03.09补充：经邮件咨询微软支持组，得到官方解决方法：
官方解决方案：
http://support.microsoft.com/kb/2509302

相关讨论：http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/b77799d2-a931-467a-928d-49426d83d5ce/

本文链接

SQL Server 2012 正式发布

2012-03-07T06:02:00Z

SQL Server 2012 正式发布 2012.3.7

pls refer:
https://www.microsoft.com/sqlserver/en/us/default.aspx
http://blogs.technet.com/b/dataplatforminsider/archive/2012/03/06/sql-server-2012-released-to-manufacturing.aspx
https://www.microsoft.com/sqlserver/en/us/get-sql-server/try-it.aspx

下载sql server 2012

本文链接

[分享]系统crash后SQL Server 在recovery时的rollback机制

2012-02-21T02:16:00Z

来自：msdn论坛贴子

创建一个测试表TESTTABLE,并且插入如下两行数据:

insertinto TESTTABLE values (1, 'aaaa')

insertinto TESTTABLE values (2, 'bbbb')

然后做如下的操作。

update TESTTABLEset myName = 'cccc' where myID = 2

为了更加直观化，我们可以用一些日志工具如ApexSQL Log (从http://www.apexsql.com/ ) 可以下载来观察一下日志的结构。

这时候，我们可以看到，update的语句包含了oldValue和newValue，所以，在做rollback的时候，因为有了oldValue，所以所谓的恢复就是把value改回为oldValue即可

同时，我们也可以看到相应的UNDO Script.

和 REDO script:

只是记录oldValue和newValue，而不是记录那个值对应的整个oldpage跟newpage。

本文链接

4.0 Query Parameterization

2012-02-17T06:11:00Z

原文：http://blogs.msdn.com/b/sqlprogrammability/archive/2007/01/11/4-0-query-parameterization.aspx

Using parameters or parameter markers in queries increases the ability of SQL Server to reuse compiled plans. There are two places where parameterization of queries can be done: on the client side application (or mid tier) or on the server side.

4.1 Client Side Parameterization

Client side parameterization (via ADO.NET, ODBC, or sp_executesql) is the recommended approach for query parameterization. Based on the degree of re-execution of queries (once versus multiple executions), client applications can decide to parameterize queries by specifying parameter holders, their data types and lengths in the queries. Therefore between query executions the only thing that changes is the actual value of parameters. This allows for re-use of one parameterized compiled plan. The server will not attempt to parameterize these queries further. It is important to parameterize queries completely and correctly in the client code in order to get the full benefits of parameterized queries. Consider the example below where the client submits a parameterized query using sp_executesql:

declare @param_value int, @sqlstring nvarchar(500),

@param_definition nvarchar(500), @col2 int;

set @sqlstring = N'select @col2_out = t1.col2 from t1 join t2 on t1.col1 = t2.col1 where t2.col2 = @param';

set @param_definition = N'@param int, @col2_out int output';

set @param_value = 5;

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

set @param_value = 10;

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

The adhoc query in this case is fully parameterized, and for different values of the parameter the same compiled plan is re-used which gives significant performance gains. The compiled plan is as below:

Text

Plan_handle

Cacheobjtype

Objtype

(@param int, @col2_out int output)select @col2_out = t1.col2 from t1 join t2 on t1.col1 = t2.col1 where t2.col2 = @param

0x06000100

6639AD2BB8

4181040000

0000000000

Compiled Plan

Prepared

The next section describes the best practices for query parameterization and highlights how several common omissions in client side parameterization can manifest as performance degradations.

4.2 Server Side Parameterization: Simple Parameterization

If the query submitted for execution has no parameters specified, then SQL server attempts to parameterize this query. This process is called simple or auto parameterization. The parameterization of queries is done on the server side and is on by default. As the name simple parameterization suggests, only a relatively small set of queries do get parameterized using simple parameterization. Consider the following example:

select col2 from t1 where col1 > 5

select col2 from t1 where col1 > 6

The 2 queries only differ in the literal values in the where clause. When the first query is submitted for execution, SQL Server parameterizes the first and the entries in the cache look like:

Text

Plan_handle

Cacheobjtype

Objtype

select col2 from t1 where col1 > 5

0x06000100

87711124B8

614C040000

0000000000

Compiled Plan

Adhoc

(@1 tinyint)SELECT [col2] FROM [t1] WHERE [col1]>@1

0x06000100

533AC103B8

81CF030000

0000000000

Compiled Plan

Prepared

The second row contains what we call a parameterized query and has objtype of prepared. The parameterized (or prepared) query is the actual compiled plan for the query with the literal values replaced with parameters. The first row contains what we call the shell query and has objtype adhoc. As the name suggests, this entry just saves the exact adhoc batch text in cache and points to the parameterized query plan (the prepared compiled plan). In other words the shell query has a dummy compiled plan which just points to the parameterized compiled plan. The shell query is relatively small in size compared to the parameterized (or prepared query).

There are benefits in caching the shell query: If the same query were to be re-executed, then we would compute the hash value of the sql text of the query and find an exact match in the cache i.e. the shell query. Since this shell query points to the compiled plan, the compiled plan is executed and we are done. If we had not cached this shell query and if the same query was re-executed then the steps followed would be slightly different: first we would compute the hash of the sql text of the query and not find an exact match in the cache. Next, the query is auto-parameterized. Now for this auto-parameterized query we will search the cache and find an exact match in the cache avoiding the need to go to the query optimizer. Finally we execute this compiled plan and are done. Clearly there are performance gains from caching the shell query, especially for applications that re-execute the same query with the same literal values as well. Note that we do not cache insert shell queries because the probability of re-using the exact same adhoc query is low.

SQL Server attempts to auto-parameterize queries and sends the auto-parameterized query to the query processor. Now the query processor decides if it can generate a potentially better plan given the constant values instead of the auto-parameterized query. If the query processor cannot find a better plan with the constant value plugged in, it means that the parameterized plan can be used across different parameter values. This parameterization is considered ‘safe’. In this case we cache both the parameterized and the shell query. However if the query processor can generate a better plan with the literal values, then this parameterization is considered ‘unsafe’. The query is parameterized and the shell query is cached. The parameterized query is not cached and is not visible through any of the plan cache DMV’s. The shell query points to the parameterized query and this is the only way to get to the parameterized query. In other words, unless the exact same query (and parameter value) is re-executed there is no chance of re-using this ‘unsafe’ parameterized query. Queries that already have explicitly defined parameters are not auto-parameterized.

It is important to note that SQL Server will not even attempt to auto-parameterize certain types of queries. A non-exhaustive list of such queries with certain constructs is as below:

1. BULK INSERT

2. IN Expressions (Ex. IN (1, 2, 3))

3. UPDATE with SET clause that has variables

4. SELECT with UNION

5. SELECT with INTO

6. SELECT/UPDATE with FOR BROWSE

7. SELECT/UPDATE/DELETE with OPTION <query hints>

8. SELECT with DISTINCT

9. SELECT/UPDATE/DELETE/INSERT with TOP

10. WAITFOR statements

11. SELECT with GROUP BY, HAVING, COMPUTE

12. DELETE/UPDATE with FROM CLAUSE

13. full text predicates

14. Sub queries

15. FROM Clause of a SELECT statement has table valued method or full text table or OPENROWSET or OPENXML or OPENQUERY or OPENDATASOURCE

16. Comparison predicate of the form EXPR <> a non null constant

17. Queries with JOINS

A general rule of thumb would be that the server auto-parameterizes a query when only one feasible plan for that query is possible. It follows that when auto-parameterization is done, no cost based query optimization is performed by the query optimizer.

4.3 Server Side Parameterization: Forced Parameterization

Clearly since simple parameterization encompasses a small subset of query types, a more powerful option called forced parameterization is available in SQL Server 2005. There are two levels of granularity with which forced parameterization can be enabled: for the entire database or at the query level.

Between the 2 options of database and query level granularity, query level parameterization is the recommended approach. With this alternative, the benefits of parameterization are retained for specific queries and any potential performance problems that may emerge from applying it at the database level are eliminated. Forced parameterization at the query level can be specified using plan guides. Consider the example below:

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 5

This query does not get parameterized when the database parameterized option is set to simple. Now let us create a plan guide for queries of this template that differ only in the where clause parameter value:

declare @stmt nvarchar(max), @params nvarchar(max);

exec sp_get_query_template N'select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 5', @stmt output, @params output

exec sp_create_plan_guide N'JoinGuide', @stmt, N'Template', NULL, @params, N'OPTION(PARAMETERIZATION FORCED)'

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 15

Now if we look at the cached plans we have the parameterized and the shell queries cached.

Text

Plan_handle

Cacheobjtype

Objtype

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 15

0x060001009

DE67C01B8C1

B0040000000

00000000000

000000

Compiled Plan

Adhoc

(@0 int)select t1 . col2 , t2 . col2 from t1 join t2 on t1 . col1 = t2 . col1 and t1 . col2 > @0

0x060001009

647E335B881

70040000000

00000000000

000000

Compiled Plan

Prepared

BOL has more information on plan guides.

Next let us consider the database level option. Forced parameterization at the database level can be enabled using the alter database DDL:

alter database <database_name> set parameterization forced

For some databases with a high volume of queries it may significantly reduce the frequency of query compilations. In general, a broad class of DML queries are parameterized and literal values are replaced with parameters during query compilation. BOL article ‘Forced Parameterization’ has a list of query clauses and in literals in query constructs that will not be forced parameterized.

There are some factors to consider before turning on forced parameterization for a database. Examine these factors carefully along with query level forced parameterization options before turning on forced parameterization at the database level. Turning on (or off) forced parameterization flushes the plan cache of all entries, except those that were then compiling or executing. Plans that were then compiling or executing are parameterized the next time the query is executed. The database parameterization setting is preserved when re-attaching or restoring a database. Distributed queries may also be parameterized as long these queries are executing in a database where forced parameterization is enabled. Since parameterization replaces the literal values in the query with parameters, the query optimizer may very well choose a sub optimal plan. Specifically, the query optimizer is less likely to match the query to an index, indexed view or a computed column. It is also less likely to choose optimal plans for partitioned tables and distributed partitioned views. Thus forced parameterization can have some serious performance ramifications and should be used with caution.

Note that it is possible to turn on forced parameterization at the database level and then use plan guides to specify simple parameterization for specific queries that suffer from poor performance due to forced parameterization. However the reverse approach i.e. specifying forced parameterization for specific queries, with the database parameterization option simple is what is recommended.

Using forced parameterization the performance problems associated with not re-using cached plans seems to have to been solved largely. However in some cases it can give rise to another set of problems emerging from parameter sniffing. Parameter sniffing can be explained as follows: If the parameter values are specified during the first execution of a query then the query optimizer attempts to pick the best plan based on the current parameter values provided. Parameter values are sniffed for stored procedure executions, queries submitted for sp_executesql, and prepared queries. While in most cases this works well, in some cases where the optimal plan for a query varies greatly with the range of parameter values, there can be some performance degradation. This is especially true if the first set of parameter values are atypical, because it causes a sub-optimal plan (for other parameter values) to be inserted into cache and re-used as well. Consider the following example: Sales table has three columns: transaction id, country id, and total_amount. We also know that majority of the sales occur in country with id = 1, and country with id = 2 has far fewer rows in the sales table. If we had a stored procedure that reported sales by country id as below:

create proc sales_report @country_id int

as begin

select * from sales where country_id = @country_id

end

If we now executed the stored proc with country id 2 first, then the query_plan can be obtained by:

select text, query_plan, cacheobjtype, objtype

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle)

outer apply sys.dm_exec_query_plan(plan_handle)

where cacheobjtype = 'Compiled Plan' and objtype = 'Proc'

and text not like '%select text%'

The query plan shows that the query optimizer does an index seek when we execute the procedure with country id 2 first, where as the query optimizer does a clustered index scan with country id 1 on first execution of the stored procedure. This difference in plan for the stored procedure execution comes from parameter sniffing and cause poor query execution time for more frequently executed parameter values if the first parameter was not a representative value. Or if the parameterized plan removed from cache due a cache flush and the next stored procedure execution was with atypical value. In such cases one way to bypass parameter sniffing would be to modify the stored procedure as follows using local variables:

create proc sales_report @country_id int, @country_id_default int = 1

as begin

set @country_id_default = @country_id;

select * from sales where country_id = @country_id_default;

end

Now irrespective of what order the parameters are supplied, the query optimizer does a clustered index scan. This is because the optimizer sniffs the @country_id_default variable which is always set to the more commonly used value (in this case 1), leading to the same plan irrespective of what parameter we pass to the procedure. Notice that the parameter we pass to the stored procedure is not part of the select statement where clause. Also note that the set statement cannot affect the compiled plan chosen by the query optimizer because it is evaluated only at execution time. There are other options like creating the procedure with the ‘with recompile’ option. More details are available in this white paper and in this blog post.

本文链接

日志文件如何影响我数据库的启动

2012-02-03T08:56:00Z

原文：http://blogs.msdn.com/b/apgcdsd/archive/2011/12/30/10251946.aspx

截取一段，备查
日志文件如何影响我数据库的启动？

无论你的SQL Server启动，或者你将某数据库重备份中恢复，或者其他的一些情况，总之在你的数据库能够被正常使用之前，你的数据库都会进入 Recovery的状态。http://msdn.microsoft.com/en-us/library/ms190442.aspx 如果这一个步失败，那么你的数据库就会进入Suspect状态而无法正常使用。在一些特殊情况下，这个Recovery所花费的时间会很长。在数据库进入Online状态之前，我们都不能认为SQL Server可以被正常使用了。

那么在Recovery中做了什么呢？

我们可以在你的SSMS中运行如下语句。在运行之前，你可以先按下Ctrl+T来把结果转化成Plain Text格式。

sp_readerrorlog会返回自从最近一次SQL Server服务启动，或者Error Log被回收开始的SQL Server的Error Log信息。这里有两个词汇可能会让你感到疑惑。首先，这里的Log和我们上文所说的日志文件（Transaction Log）中的Log不是一件事情。其次，所谓的Error Log，并不是说这里出现了Error。SQL Server使用这个Error Log记录了很多诊断信息。所以，你可以认为这只是一个普通的记录了很多SQL Server相关信息的日志文件。

在结果返回中，你可能会找到上面的这些信息。引号中为在你当前数据库实例下的各个数据库名。

以数据库‘CaseLync’为例。由于Error Log会记录当前SQL Server实例下的所有数据库的相关信息，所以你可能会看到和这个数据库相关的日志被顺序地分布在日志的不同地方。在上图中，第一和第二行提及两个词：rolled forward和rolled back。这两个词和我们本文中所提及的Transaction Log息息相关。

在前文中，我们提到过数据修改的过程：先同步的被写入Transaction Log，然后再Checkpoint发生的时候被同步到Data File里。那么，如果我的事物（Transaction）没有被提交（Commit）或者回滚（Rollback），那么这个数据修改是否也在日志文件（Transaction Log）还是在数据文件里（Data File）？

答案是：都在！

SQL Server在记录数据改变时，并不会区分该语句是否有显示的进行事物操作（Begin Transaction，Commit / Rollback Transaction）, 或者该事务是否有完成。SQL Server会忠实地记录所有的修改操作。而Begin Transaction和Commit / Rollback Transaction本身也是日志文件需要记录的操作之一。

由于对于事物日志的修改要先于对于数据文件的修改，所以当你的数据库处于Recovery的状态时，那么Transaction Log就会从最近的一个Checkpoint点开始做如下操作：

如果该操作已在在Transaction Log中，而不在Data File之中，并且如果它使用显式的Transaction操作符而且处于Commit状态，则会发生一次Rolled Forward操作，将该操作同步到Data File之中。
如果该操作已在在Transaction Log中，而不在Data File之中，并且如果它使用显式的Transaction操作符而且处于Rollback Transaction状态，则会发生一次Rolled back操作，将Data File之中的相关数据修改回滚到Transaction发生之前。
如果该操作已在在Transaction Log中，而不在Data File之中，并且如果它使用显式的Transaction在日志文件中即没有Commit操作，也没有Rollback操作，则会发生一次Rolled back操作，将Data File之中的相关数据修改回滚到Transaction发生之前。
如果该操作已在在Transaction Log中，而不在Data File之中，并且如果它没有使用显式的Transaction操作符（Begin Transaction）, 则被认为是一个Rolled Forward操作。
如上步骤都完成后，SQL Server会对该数据库做一个Checkpoint的标识，并写入Transaction Log，表示Data File和Transaction Log已经同步。这表明了数据库的Recovery完成。数据库将进入Online状态，并被正常使用。如果你的数据库在最近的一次Checkpoint到现今的修改操作足够多，在Error Log中也会看到SQL Server用百分比标识Recovery完成的进展。

本文链接

How can I create a dump of SQL Server?

2012-02-01T06:58:00Z

原文：http://blogs.msdn.com/b/askjay/archive/2010/02/05/how-can-i-create-a-dump-of-sql-server.aspx

You can create a memory dump of the SQL Server process space in several ways. There are many external tools that can help you accomplish this such as userdump.exe, debugdiag.exe, and ADPlus.exe. In this post, I’ll cover 3 common ways to accomplish this for SQL Server: The most common way (sqldumper), using the debugger, and three methods from within SQL Server itself.

First, two of these methods will require that you get the process id (PID) of SQL Server. Here are a few simple ways to do that:

1. From a command window, execute --> tasklist | find /i “sqlservr” or from the Debugging tools directory execute –> tlist | find /i “sqlservr”
2. Open task manager, and find sqlservr.exe and get the PID from the PID column. If you don’t see this column, then select View –> Select Columns to add it.
3. In a query window inside of SSMS on the instance you wish to dump, execute –> “SELECT SERVERPROPERTY(‘PROCESSID’)
4. Get the process ID from the SQL Server Errorlog.

Now that you have the PID, you can use one of the following ways to create the dump:

Method 1 (Using SqlDumper)

The most common way (and the way used internally by SQL Server) is to run SqlDumper.exe. You will find SqlDumper.exe in the following directory for a default installation of SQL Server:

C:\Program Files\Microsoft SQL Server\100\Shared

The syntax of SqlDumper is as follows:

SqlDumper <process id (PID)> <thread id (TID)> <Flags:Minidump Flags> <SQLInfoPtr> <Dump Directory>
more parameters can be seen with SqlDumper /?

The common flags are as follows:

0x0120 – Minidump (this is a dump of just the stacks and loaded modules – this is the smallest of the dump types – this is normally the type of dump created automatically by SQL Server during AVs and other exceptions)

0x01100 – Full Dump (this dumps the entire process space – this can be very large on a 64 bit system or any system with a large amount of memory assigned to SQL Server)

0x8100 – Filtered Dump (a filtered dump is a dump of all of Stolen Memory plus certain areas of the buffer pool)
NOTICE: SQLDumper can be used to dump ANY user mode process – not just SQL Server.

Some examples for SQLServer running under SPID 4024 to c:\temp:

Minidump: sqldumper 4024 0 0x0120 0 c:\temp
Full Dump: sqldumper 4024 0 0x01100 0 c:\temp
Filtered Dump: sqldumper 4024 0 0x8100 0 c:\temp

The dump file will have the naming convention of: SQLDmpr####.mdmp (i.e. SQLDmpr0001.mdmp)

Method 2 (Using a debugger)

To dump SQL Server from WINDBG or other debugger, attach the debugger to the process using the PID:

Once connected, just use the .dump command which has the following syntax:

Options are:
/a - Create dumps for all processes (requires -u)
/b[a] - Package dump in a CAB and delete dump
/c <comment> - Add a comment (not supported in all formats)
/j <addr> - Provide a JIT_DEBUG_INFO address
/f - Create a legacy style full dump
/m[acdfFhiprRtuw] - Create a minidump (default)
/o - Overwrite any existing file
/u - Append unique identifier to dump name

“.dump /ma” is the recommend method of creating a complete memory dump of a user mode process.

So, to create a complete memory dump of the SQL Server to c:\temp, execute the following:

.dump /ma c:\temp\sqldump.dmp

Method 3 (From within SQL Server)

From inside SQL Server, you can create a dump using two different methods. First, to create a manual dump immediately, use the following undocumented command:

DBCC STACKDUMP

This will create a memory dump in the LOG directory of your SQL Server instance installation. To enable this method to create a FULL DUMP, you must turn on trace flags 2544 and 2546:

dbcc traceon(2544, -1)
go
dbcc traceon(2546, -1)
go
dbcc stackdump

To create only a minidump, enable trace flag 2546. To create a full-filtered dump, use trace flag 2551.

You can use the undocumented DBCC DUMPTRIGGER command to enable SQL Server to create a dump on the occurrence of an error. You can use the following to enable a full dump on error 802 (There is insufficient memory available in the buffer pool):

-- turn on TFs for full dump
dbcc traceon(2544, -1)
go
dbcc traceon(2546, -1)
go
-- set DUMP TRIGGER for exception 802
dbcc dumptrigger('set', 802)
go

-- view exceptions set for DUMP TRIGGER
dbcc traceon(3604, -1)
go
dbcc dumptrigger('display')
go
dbcc traceoff(3604, -1)
go
-- Turn off dumptrigger for exception 802
dbcc dumptrigger('clear', 802)
go

Finally, you can also use the –y parameter on SQL Server startup to achieve the same functionality as SQL Server’s DBCC DUMPTRIGGER. For more information refer to:

http://blogs.msdn.com/psssql/archive/2008/01/10/how-it-works-sql-server-engine-error-messages.aspx

One method not covered in this post is to create the dump from within Task Manager as seen here:

I am not a big fan of this method since you have little control over it. It will create a full dump inside your user profile by default. It is also only available on Windows 2008 and Windows 2008 R2 (or Vista and Windows 7). However, it is yet another way to dump the SQL Server process.

- Jay

本文链接

在发布订阅中增加rowversion数据类型字段引发错误(or bug)

2011-12-01T05:19:00Z

考虑这样的场景，现在每天要同步更新的数据，为了记录哪些数据发生过变更，需要对表添加一个rowversion列来标识被更新过。恰好这个表比较大，而且有发布订阅。由于该字段对于订阅表来讲，无实际意义，而且添加一个有默认值的不可为空的8字节字段，会产生数据空间分配，或许带来大量的页拆分，对IO压力会加大，所以考虑将此表的发布项暂时改为不支持架构复制，等添加完该字段后，再将其改为支持架构复制。

下面来做这个测试：

1.下面是一个正常的事务发布，将DB_1中的T_1发布到DB_2的T_1表中。

2.修改发布项DBrepTEST关于架构复制的选项，设置为不支持

DECLARE @publication AS sysname
SET @publication = N'DBrepTEST'

USE DB_1
EXEC sp_changepublication
@publication = @publication,
@property = N'replicate_ddl',
@value = 0
GO

3.然后，添加一个字段，类型为rowversion

use DB_1
alter table t_1 add rv rowversion

4.经过观察，发布订阅一切正常，该字段并未被创建在订阅库DB_2上

5.我们在另外一个进程开始一个sql，向表DB_1.dbo.T_1 insert data.

while 1=1
begin
waitfor delay '00:00:01'
insert into DB_1.dbo.T_1(name)select 'a'
end

6.发现数据已同步到DB_2.dbo.T_1，但rv字段并未被同步，现在一切正常

7.现在将发布项DBrepTEST修改回支持架构复制

DECLARE @publication AS sysname
SET @publication = N'DBrepTEST'

USE DB_1
EXEC sp_changepublication
@publication = @publication,
@property = N'replicate_ddl',
@value = 1
GO

8.然后，此时向表DB_1.dbo.T_1新加一个int类型字段

use DB_1
go
alter table t_1 add age int

9.此时发布订阅出错

出错文字为：
Command attempted:
if @@trancount > 0 rollback tran
(Transaction sequence number: 0x000000580000013C000100000000, Command ID: 6)

Error messages:
A DDL change has been replicated. (Source: MSSQL_REPL, Error number: MSSQL_REPL27332)
Get help: http://help/MSSQL_REPL27332
列名 'rv' 无效。 (Source: MSSQLServer, Error number: 207)
Get help: http://help/207
10.由上面的信息，可以看出此时是由于在订阅库上找不到rv这个列造成的，为了确定这一点，我们看下这个事务执行的是什么

use distribution
go
EXEC sp_browsereplcmds '0x000000580000013C000100000000','0x000000580000013C000100000000'

11.由10的结果中的command列，得到如下需要应用到订阅库的t-sql

ALTER TABLE [dbo].[T_1] add age int
if object_id(N'[dbo].[sp_MSins_dboT_1]', 'P') > 0 drop proc [dbo].[sp_MSins_dboT_1]
--
if object_id(N'dbo.MSreplication_objects') is not null delete from dbo.MSreplication_objects where object_name = N'sp_MSins_dboT_1'
--
create procedure [dbo].[sp_MSins_dboT_1]
@c1 int,
@c2 varchar(20),
@c3 int
as
begin
insert into [dbo].[T_1](
[id],
[name],
[rv],
[age]
) values (
@c1,
@c2,
default,
@c3 )
end
--
if columnproperty(object_id(N'dbo.MSreplication_objects'), N'article', 'AllowsNull') is not null exec sp_executesql @statement = N'insert dbo.MSreplication_objects (object_name, publisher, publisher_db, publication, article, object_type) values (@object_name, @publisher, @publisher_db, @publication, @article, ''P'')', @parameters = N'@object_name sysname, @publisher sysname, @publisher_db sysname, @publication sysname, @article sysname', @object_n
ame = N'sp_MSins_dboT_1', @publisher = N'mySrv\SQL2008', @publisher_db = N'DB_1', @publication = N'DBrepTEST', @article = N'T_1'
--
--
if object_id(N'[dbo].[sp_MSdel_dboT_1]', 'P') > 0 drop proc [dbo].[sp_MSdel_dboT_1]
--
if object_id(N'dbo.MSreplication_objects') is not null delete from dbo.MSreplication_objects where object_name = N'sp_MSdel_dboT_1'
--
create procedure [dbo].[sp_MSdel_dboT_1]
@pkc1 int as begin
delete [dbo].[T_1] where [id] = @pkc1
if @@rowcount = 0 if @@microsoftversion>0x07320000 exec sp_MSreplraiserror 20598
end
--
if columnproperty(object_id(N'dbo.MSreplication_objects'), N'article', 'AllowsNull') is not null exec sp_executesql @statement = N'insert dbo.MSreplication_objects (object_name, publisher, publisher_db, publication, article, object_type) values (@object_name, @publisher, @publisher_db, @publication, @article, ''P'')', @parameters = N'@object_name sysname, @publisher sysname, @publisher_db sysname, @publication sysname, @article sysname', @object_n
ame = N'sp_MSdel_dboT_1', @publisher = N'mySrv\SQL2008', @publisher_db = N'DB_1', @publication = N'DBrepTEST', @article = N'T_1'
--
--
if object_id(N'[dbo].[sp_MSupd_dboT_1]', 'P') > 0 drop proc [dbo].[sp_MSupd_dboT_1]
--
if object_id(N'dbo.MSreplication_objects') is not null delete from dbo.MSreplication_objects where object_name = N'sp_MSupd_dboT_1'
--
create procedure [dbo].[sp_MSupd_dboT_1]
@c1 int = NULL,
@c2 varchar(20) = NULL,
@c3 int = NULL,
@pkc1 int = NULL,
@bitmap binary(1) as begin
update [dbo].[T_1] set
[name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [name] end,
[age] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [age] end where [id] = @pkc1
if @@rowcount = 0 if @@microsoftversion>0x07320000 exec sp_MSreplraiserror 20598
end
--
if columnproperty(object_id(N'dbo.MSreplication_objects'), N'article', 'AllowsNull') is not null exec sp_executesql @statement = N'insert dbo.MSreplication_objects (object_name, publisher, publisher_db, publication, article, object_type) values (@object_name, @publisher, @publisher_db, @publication, @article, ''P'')', @parameters = N'@object_name sysname, @publisher sysname, @publisher_db sysname, @publication sysname, @article sysname', @object_n
ame = N'sp_MSupd_dboT_1', @publisher = N'mySrv\SQL2008', @publisher_db = N'DB_1', @publication = N'DBrepTEST', @article = N'T_1'
--
--

可以看到对于添加字段，会重新创建对表操作的三个proc，本例中，insert这个proc会将rv加入进来，并且值为default,如下所示，但由于该列并不存在于订阅中，所以就会报错了，由此造成分发中断，后续事务无法应用到订阅端。

create procedure [dbo].[sp_MSins_dboT_1]
@c1 int,
@c2 varchar(20),
@c3 int
as
begin
insert into [dbo].[T_1](
[id],
[name],
[rv],
[age]
) values (
@c1,
@c2,
default,
@c3 )

12.虽然可以通过在订阅端手工端建一个rv列，将其设置为可为null的varbinary(8)类型，但这个列对于订阅并没有实际意义。

use DB_2
go
alter table t_1 add rv varbinary(8)

总结，经过测试，发现当添加其它类型字段，并设置为有默认值且not null时，不会有此错误出现，目前发现仅是rowversion类型列，不知是否为SQL Server bug.
测试环境：windows server 2003 enterprise 32bit sql server 2008 sp2 standard 32bit

本文链接