博客园_stswordman

inactive subscription

2012-02-09T07:42:00Z

The subscription(s) have been marked inactive and must be reinitialized. NoSync subscriptions will need to be dropped and recreated. (Source: MSSQLServer, Error number: 21074)

Get help: http://help/21074

当sql server检测到订阅和发布数据库不同步（例如网络原因）达到maximum retention（默认为72小时）, SQL Server会将订阅标记为inactive状态。此后，即使网络恢复。订阅也无法恢复了。

这是由分发服务器的Distribution clean up: distribution完成的。这个cleanup job实际调用存储过程distribution.sp_MSdistribution_cleanup @min_distretention = 0, @max_distretention = 72

执行sp_MSdistribution_cleanup时，这个存储过程会在下面这个代码段运行对于订阅的检查，如果大于了retention,就标记为inactive.

-- Note: we need to use the same cut_off time for sp_MSsubscription_cleanup

-- and sp_MSdistribution_delete since sp_MSsubscription_cleanup need to disable

-- all the dist agents that are lag behind (their pending trans will be removed)

    select @cutoff_time = dateadd(hour, -@max_distretention, getdate())



    -- Deactive any subscriptions which have been inactive beyond the maximum retention

exec @retcode = dbo.sp_MSsubscription_cleanup @cutoff_time

在sp_MSsubscription_cleanup，执行以下语句。详细的请参见sp_MSsubscription_cleanup定义。

update MSsubscriptions set status = @INACTIVE

我们可以很容易地模拟这种情况：停止相应的订阅的distributor job，停止1分钟，然后执行在distribution数据库执行

   select @cutoff_time = dateadd(minute, -3, getdate())



    -- Deactive any subscriptions which have been inactive beyond the maximum retention

exec @retcode = dbo.sp_MSsubscription_cleanup @cutoff_time

之后开启那个job，运行，会得到如下错误

The subscription(s) have been marked inactive and must be reinitialized. NoSync subscriptions will need to be dropped and recreated. (Source: MSSQLServer, Error number: 21074)

Get help: http://help/21074

Action Plan

对于这种情况，我们推荐进行重新初始化。当然也可以手工的将update MSsubscriptions 的状态变更为2，不过这会导致数据的不一致性，用户需要自己来维护丢失的数据变更

本文链接

一个filegroup backup+log backup的bug

2011-10-06T01:29:00Z

USE master;
GO
drop database Sales
go
CREATE DATABASE Sales
ON PRIMARY
( NAME = SPri1_dat,
    FILENAME = 'D:\SalesData\SPri1dat.mdf',
    SIZE = 10,
    MAXSIZE = 50,
    FILEGROWTH = 15% ),
FILEGROUP SalesGroup1
( NAME = SGrp1Fi1_dat,
    FILENAME = 'D:\SalesData\SG1Fi1dt.ndf',
    SIZE = 10,
    MAXSIZE = 50,
    FILEGROWTH = 5 )
LOG ON
( NAME = Sales_log,
    FILENAME = 'D:\SalesLog\salelog.ldf',
    SIZE = 5MB,
    MAXSIZE = 25MB,
    FILEGROWTH = 5MB ) ;
GO
USE Sales
GO
CREATE TABLE TA(A INT ,B INT ,C INT) ON  SalesGroup1
go
use master
go
backup database sales
to disk='sales.bck' with init
go
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1'
   TO DISK = 'SalesGroup1.bck' with init
   go
go

insert sales..ta default values

go
BACKUP log Sales
TO DISK = 'Sales_log.bck' with init
go

restore database sales from disk='SalesGroup1.bck' with recovery
go
restore log sales from disk='Sales_log.bck' with recovery
go
select *From sales..TA

以上这段代码可以正常执行

如果将insert sales..ta default values这句话的注释掉，会返回这个错误

Msg 8653, Level 16, State 1, Line 1

The query processor is unable to produce a plan for the table or view 'TA' because the table resides in a filegroup which is not online.

如果我们单独执行restore database和restore log语句。会发现两条警告信息

The roll forward start point is now at log sequence number (LSN) 25000000019700001. Additional roll forward past LSN 25000000020400001 is required to complete the restore sequence.

RESTORE DATABASE ... FILE=<name> successfully processed 8 pages in 0.036 seconds (1.736 MB/sec).

Processed 0 pages for database 'sales', file 'SGrp1Fi1_dat' on file 1.

The roll forward start point is now at log sequence number (LSN) 25000000019900001. Additional roll forward past LSN 25000000020400001 is required to complete the restore sequence.

RESTORE LOG successfully processed 0 pages in 0.003 seconds (0.000 MB/sec).

restore database时显示仍然需要roll forward到25000000020400001 ，但是log备份中的日志并没有达到/超过预期的lsn，而是在25000000019900001就结束了。

我们通过restore head对比

restore headeronly from disk='SalesGroup1.bck'
go
restore headeronly from disk='Sales_log.bck'

Log包含的最大的lsn没有办法满足之前restore database所需要的lsn...

此问题可以在SQL SERVER 2008 R2 RTM中重现

本文链接

找出性能差的语句

2011-07-27T07:15:00Z

1 找出效率低的语句

SELECT TOP 10
   qs.total_worker_time ,qs.total_logical_reads,qs.last_logical_writes,   qs.plan_handle,
   qs.execution_count,
   (SELECT SUBSTRING(text, qs.statement_start_offset/2 + 1,
      (CASE WHEN qs.statement_end_offset = -1
         THEN LEN(CONVERT(nvarchar(max), text)) * 2
         ELSE qs.statement_end_offset
      END - qs.statement_start_offset)/2)
   FROM sys.dm_exec_sql_text(sql_handle)) AS query_text
FROM sys.dm_exec_query_stats qs
ORDER BY total_worker_time DESC

2 查看这些语句对应的client, hostname,loginname

select s.host_name,s.PROGRAM_NAME,s.login_name, t.text From sys.dm_exec_requests r
cross apply
sys.dm_exec_sql_text(r.sql_handle) t
inner join sys.dm_exec_sessions s on r.session_id=s.session_id
where t.text like '%sqlstatement%'----- place your sql statement here
and s.session_id<>@@SPID

3确定这些语句隶属的存储过程

通过第一步得到的plan_handle,代入dm_exec_query_plan，得到具体的存储过程的名称。如果返回空，则说明该语句是ad-hoc或者是prepared或者是在存储过程内部使用批结字符串弄出来的语句。如果是以上几种情况，我们是无法定位对象的，只能让程序员们逐个排查了

select OBJECT_NAME(objectid) from sys.dm_exec_query_plan ( plan_handle )

本文链接

一个单表死锁的示例

2011-07-19T04:48:00Z

准备数据，插入1w条数据

create table locktest(id int primary key identity(1,1))
go
begin tran
insert locktest default values
go 10000
commit

执行顺序如下，在第三部的时候会出现死锁

执行顺序	session1	session2
1	begin tran delete from locktest where id=2
2		set transaction isolation level repeatable read begin tran select * from locktest where id<3
3	delete from locktest where id=1

本文链接

DDL Trigger

2011-07-14T08:20:00Z

create TRIGGER indexTrigger
ON ALL SERVER
--FOR DROP_INDEX ,ALTER_INDEX,create_index
FOR DROP_INDEX
AS
declare @original_login sysname ,@login_name sysname,@user_name sysname,@eventtype nvarchar(100),@commandText nvarchar(max),@dbname sysname
select
@original_login=ORIGINAL_LOGIN(),
@login_name=SUSER_NAME(),
@user_name=CURRENT_USER,
@dbname=EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]', 'sysname') ,
@eventtype= EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)') ,
@commandText= EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)')

if not exists(select 1 from tempdb.sys.tables where name='indexTrigger')
begin
    create table tempdb.DBO.indexTrigger(
        original_login sysname ,
        login_name sysname,
        user_name sysname,
        eventtype nvarchar(100),
        commandText nvarchar(max),
        dbname sysname,
        createtime datetime default getdate()
    )
end
insert tempdb.dbo.indexTrigger([original_login],[login_name],[user_name],[eventtype],[commandText],dbname)
select @original_login,@login_name,@user_name,@eventtype,@commandText,@dbname

EVENTDATA (Transact-SQL)

本文链接

DistributionDB过大的原因

2011-07-07T09:05:00Z

1 同一个发布库的对象被多个发布包(n)所包含，导致产生了n倍的数据

在发布库执行下面的语句，会返回被多次发布的对象

select objid,count(*) from sysarticles group by objid having(count(*)>1) order by COUNT(*) desc

2 distribution cleanup job停止工作，导致MSrepl_commands和MSrepl_transactions数据无法被清除

3 发布库中的任意一个发布的匿名订阅属性/立即初始化属性为true，这会导致全部的数据在max retention到达之前无法被删除（具体的删除逻辑见sp_MSdelete_publisherdb_trans）

在distributiondb执行下面的语句，找出存在匿名订阅/立即初始化的发布:

select a.article,p.publication from MSsubscriptions s inner join MSpublications p
on s.publication_id=p.publication_id
inner join MSarticles a on s.article_id=a.article_id where subscriber_id < 0
go
sp_helpdistpublisher

找到后在发布库执行以下语句即可

exec sp_changepublication @publication = 'xx' ,@property = 'allow_anonymous' , @value = false

exec sp_changepublication @publication = 'publicationTest' , @property = 'immediate_sync' , @value = false

本文链接

事物复制的troubleshooting 1

2011-06-21T08:06:00Z

本文大量照抄了Transactional Replication Conversations

上图是一个事物复制的拓扑. 大致可以把这个流程分为3步

logReader Agent从publicationDB的日志文件中读取需要复制的日志信息
logReader Agent将读取的信息写入到distributor的distribution库中
distribution Agent将distribution库中的数据写入到subscriber

三个阶段都可能出现性能问题. 先使用tracertoken进行定位，找到是哪一部出现问题

如果是发布到分发的问题

在logreader agent的作业里添加output参数,输出具体的信息. 方法见参见’How to enable replication agents for logging to output files in SQL Server’

和 Using “Verbose history agent profile.” while troubleshooting Replication

一个示例:-Publisher [TESTDB1] -PublisherDB [pub] -Distributor [TESTDB2] -DistributorSecurityMode 1 -Continuous -Output C:\sqldata\logreader.txt -Outputverboselevel 2

下面是文本输出的部分信息.

******************** STATISTICS SINCE AGENT STARTED ***************************
06-01-2011 15:28:36

Execution time (ms): 633551
Work time (ms): 633348
Distribute Repl Cmds Time(ms): 620035
Fetch time(ms): 658458
Repldone time(ms): 60429
Write time(ms): 273870
Num Trans: 667500 Num Trans/Sec: 1053.922962
Num Cmds: 3076294 Num Cmds/Sec: 4857.193833
*******************************************************************************

在分析这段统计信息之前先介绍一下发布到分发传输数据的大致步骤:

1 发布库数据被更新/插入/删除,产生事务日志(这其中包含需要进行复制的日志记录和不需要进行日志记录的事物)

2 LogReader agent去读取日志信息:

i.    读取LogReader profile里的配置信息,按照这些信息的配置参数去工作.(代理重启时会执行这个操作,然后将信息存储起来,直到下次代理重启才会再次执行). 例如每次读取多少记录,多长时间读取一次.详细信息查看Agent的profile信息
ii.    sp_replcmds命令读取事务日志, 这是一个sp_replcmds调用的示例: exec sp_replcmds 1000,0,-1,0x,5023,0,500000 .其中第一个参数1000为ReadBatchSize. [在发布端执行]
iii.    sp_MSadd_repl_commands去处理sp_replcmds得到的日志信息,将这些信息转化后插入distribution库[在分发端执行]
iv.    sp_repldone对日志记录进行标记(之后这些日志记录就允许被截断了,并且避免被再次读取..), 也就是那些已经在distribution端处理的记录.[在发布端执行]

Execution time:从logreader agent开始运行之后的总时间

Work time:除去Ideal后的Execution time, 是刨去PollingInterval的时间。另外，如果代理程序处于Idle状态（例如没有事务需要发布，都不会算作Work Time）

. 如果复制出现延迟,并且Work time和Execution Time有明显差距,则可能需要调整pollinginterval和ReadBatchSize

Distribute Repl Cmds Time:从publisher上读取出需要复制的事务的信息、写入缓存并写入到distribution库中所持续的总时间

Fetch time: 读取事物日志的时间,对应前面的ii

Repldone time: sp_repldone花费的时间,对应iv

Write time:将读取到的信息写入distribution花费的时间.对应iii

分析

一般来说，消耗时间的步骤就是ii和iii

第ii步是发布端执行,造成延迟的原因可能如下:

1. 执行了一些操作,这些操作产生的大量的不需要被复制的日志记录(例如rebuild index). logreader在读取时候需要进行筛选,大量的非复制性日志会延长时间.

在非高峰时间运行rebuild index, 或者将恢复模式切换成BULK_LOGGED

下面的语句返回发布库中需要复制的数据和非复制数据

Use <published database>
GO
-- Total records in the log
SELECT count(*) FROM ::fn_dblog(NULL, NULL)
GO
-- Records marked for REPLICATION
SELECT count(*) FROM ::fn_dblog(NULL, NULL) WHERE Description='REPLICATE'

2. 一个事务里的命令操作了很多行数据,产生了大量的日志

避免这种情况,将大事物拆分成小的事物分批执行.
考虑使用Publishing Stored Procedure Execution in Transactional Replication
调整MaxCmdsInTran。缺点：如果发布库事务回滚，会导致发布服务器和分发服务器数据不一致。参考Replication Log Reader Agent
可以使用下面的语句查看
在发布服务器执行
select [database],begin_lsn,commit_lsn,rows,cmds_in_tran from sys.dm_repl_traninfo
或者在分发库执行
select xact_seqno, count(*) as [count] into #MSrepl_commands from dbo.MSrepl_commands

group by xact_seqno

having count(*)>100

select t.xact_seqno,t.entry_time,c.[count] from MSrepl_Transactions t inner join

#MSrepl_commands c on t.xact_seqno=c.xact_seqno

order by c.count desc,t.entry_time

3. 小而多的VLF

过的的VLF会影响日志读取速度, 造成这种情况的原因多是日志的FILEGROWTH 过小(例如1mb)并且日志频繁的自动扩张. 解决方法:日志文件压缩,然后一次性扩张到预期的大小. 通过dbcc loginfo返回当前数据库的VLF信息. <1000是可以接受的

4. 日志磁盘存在IO压力. 如果发布数据库的压力,会影响读取速度. 解决方法:将文件存放在更高性能的磁盘上.通过performance monitor进行监控Avg. Disk Sec/Read和Avg. Disk Sec/Write,请参考Troubleshooting Performance Problems in SQL Server 2008

5. Logreader配置错误。例如ReadBatchSize设置过小或PollingInterval设置过大

6. 网络原因。发布服务器和分发服务器之间存在网络瓶颈。检查两个服务器的Performance monitor的Network Interface output queue length.理想情况应当低于2

第iii部是分发端执行,造成延迟的原因可能如下:

1 不良的复制结构：同一个对象被多个发布所（n个）包含，这样在msrepl_commands和MSrepl_transationcs会产生n倍的对象，导致插入时间增长。在发布库执行以下语句，返回被多次发布的对象:

select objid,count(*) from sysarticles group by objid having(count(*)>1) order by COUNT(*) desc

2 阻塞：插入作业和清除作业之间形成阻塞. 解决方法：在非高峰时间运行清除作业，不过这样会导致distribution agent运行效率降低
3 IO压力：distribution的日志盘存在io压力，导致写入缓慢。参见上文
2,3还可以通过 SQL SERVER 2005/8 Performance Dashboard Reports查看

SQLSERVER PROFILER收集logreader相关的命令

SELECT duration, starttime, endtime, textdata

FROM ::fn_trace_gettable('C:\DISTRIBUTOR_sp_trace.trc', DEFAULT)

WHERE TEXTDATA LIKE '%SP_MSadd_replcmds%' AND EVENTCLASS=10
Or

SELECT TOP 25

st.text, qp.query_plan,

(qs.total_logical_reads/qs.execution_count) as avg_logical_reads,

(qs.total_logical_writes/qs.execution_count) as avg_logical_writes,

(qs.total_physical_reads/qs.execution_count) as avg_phys_reads,

qs.*

FROM sys.dm_exec_query_stats as qs

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st

CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as qp

WHERE st.text like 'CREATE PROCEDURE sp_MSadd_replcmds%'

ORDER BY qs.total_worker_time DESC

如果是分发到订阅的问题…

本文链接

distribution cleanup job2

2011-06-16T06:56:00Z

第25行开始清除事务和命令

sp_MSdistribution_delete以发布库（@publisher_database_id)为单位清除：

第15行，得到改发布库的需要清除的最大序列号（@max_cleanup_xact_seqno)
地20行，调用sp_MSdelete_publisherdb_trans来删除这些数据，所以早于@max_cleanup_xact_seqno的数据都会被删除

sp_MSdelete_publisherdb_trans是真正执行删除操作的存储过程。该存储过程删除msrepl_commands，并通过调用sp_MSdelete_dodelete来删除msrepl_transactions

本文链接

在分发服务器上查看信息

2011-06-15T02:46:00Z

1 发布信息

use [distribution]

select publication,publication_id,publisher_db, case publication_type
                                                     when 0 then 'transactional'
                                                     when 1 then 'snapshot'
                                                     when 2 then 'merge'
                                                end as publication_type ,
allow_anonymous,                               case sync_method
                                                     when 0 then 'native'
                                                     when 1 then 'character'
                                                     when 3 then 'concurrent'
                                                     when 4 then 'concurrent_c'
                                                end as publication_type ,
allow_initialize_from_backup
From MSpublications

2 查看Agent的profile信息, 每个agent都有相应的系统表可以供查看:

select *From MSsnapshot_agents

select *From MSdistribution_agents
select *From MSlogreader_agents

上面的查询会返回正在应用的profileid,将返回的profileid赋值sp_help_agent_parameter.

我们以logReader agent为例

select *From MSlogreader_agents

exec sp_help_agent_parameter @profile_id=17

3 查看是否存在匿名订阅(allow_anonymous)或立即初始化(immediate_sync)选项

select * from MSsubscriptions where subscriber_id < 0

这两个选项会导致msrepl_transactions和msrepl_commands表的内容在到达max retention之前无法被分发清除作业清除.

本文链接

Top子句对查询计划的影响

2011-06-14T03:02:00Z

1子查询的影响

Nest loop适用于被连接的数据

如果两个表做join操作,会有三种join方式: Nested join, Merge Join, Hash Join

Nested Join适用于结果集较小表

Hash Join适用于结果集很大的表

示例如下

create table moderatetable1(id int identity(1,1) primary key, c1 int ,c2 int,c3 int,c4 int)
create table moderatetable2(id int identity(1,1) primary key, c1 int ,c2 int,c3 int,c4 int)
declare @n int=0
while @n<100000
begin
    insert moderatetable1(c1,c2,c3,c4) values(@n,@n,@n,@n)
    insert moderatetable2(c1,c2,c3,c4) values(@n,@n,@n,@n)
    set @n+=1
end

create index index1 on moderatetable1(C1)
create index index1 on moderatetable2(C2)
go
set statistics io on
select t1.c1 from moderatetable1 t1 inner join moderatetable2 t2
on t1.c1=t2.c1
go

下图是上面查询的执行计划和io统计信息

IO情况

(100000 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable2'。扫描计数 1，逻辑读取 361 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable1'。扫描计数 1，逻辑读取 176 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

如果只想取前50行,可以指定top 50:

select top 50 t1.c1 from moderatetable1 t1 inner join moderatetable2 t2
on t1.c1=t2.c1

(50 行受影响)
表 'moderatetable1'。扫描计数 50，逻辑读取 124 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable2'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

我们看到,当指定了top 50之后,查询计划成了nested join. 当使用TOP时,SQLSEVER会认为这是一个较小的数据集,所以会使用nested join.对于这个查询,IO的开销比较李小. 但SQLSERVER经常会估计错误(即使统计信息是正确的).

我们看一下下面的查询:

select top 500 t1.c1 from moderatetable1 t1 inner join moderatetable2 t2
on t1.c1=t2.c1

(500 行受影响)
表 'moderatetable1'。扫描计数 500，逻辑读取 1080 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable2'。扫描计数 1，逻辑读取 4 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

返回行数增加到了500,SQLSERVER仍然使用nested join,得到了较差的IO

随着TOP的行数的增多,IO开销会越来越大. 但也不是总是这样,当top值达到一个临界点后,执行计划会变更成hash join.

select top 20000 t1.c1 from moderatetable1 t1 inner join moderatetable2 t2
on t1.c1=t2.c1

(20000 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable2'。扫描计数 1，逻辑读取 74 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'moderatetable1'。扫描计数 1，逻辑读取 176 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

慎用TOP ...

本文链接