小编u23*_*534的帖子

是CPU (ms/sec)在前面的第二毫秒的CPU时间？如果达到1000，是否意味着它使用了100%的CPU？

但是，在我的 8 核服务器上，% Processor Time当“最近昂贵的查询”中最昂贵的查询达到 1000 时，通常会非常低，例如几个百分点。

我已经使用待机模式设置了日志传送？未选中“还原备份时断开数据库中的用户”）。

我测试了在辅助服务器/数据库上运行以下代码。

declare @a int
while 1=1
begin
  select @a = count(*) from ....
end

但是，当日志传送还原作业开始运行时，代码会因以下错误而停止。

无法打开数据库。它正处于恢复过程中。

如何避免这个问题？

sp_configure 在服务器上返回以下值。

名称最小最大 config_value run_value
最大并行度 0 32767 8 8

但是，sp_who1并sp_WhoIsActive表明某些spid有超过 8 行（例如 18 行左右）。在这种情况下，最多不应该是 8 行吗？

这个查询不时返回很多行：

SELECT * 
FROM sys.sysprocesses sp
where exists 
(
    select spid 
    from sys.sysprocesses 
    where spid =sp.spid 
    and sp.waitresource = ''
    group by spid 
    having count(*)>9
)

我有以下分区表

create table T (Month char(6), ID int, .... primary key (ID, Month)) on psMonth(Month)

分区函数是

CREATE PARTITION FUNCTION [pfMonth](char(6)) AS 
RANGE RIGHT FOR VALUES (N'200001', .... N'200705', N'200706', N'200707', ....)

但是，以下查询显示的实际分区数是 260 而不是 1？

select count(*)
from T (nolock)
where Month = '200706'

执行计划是

  |--计算标量(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[globalagg1006],0)))
       |--Stream Aggregate(DEFINE:([globalagg1006]=SUM([partialagg1005])))
            |--Parallelism(Gather Streams)
                 |--Stream Aggregate(DEFINE:([partialagg1005]=Count(*)))
                      |--聚簇索引扫描(OBJECT:([DB].[dbo].[T].[PK_T]), WHERE:([DB].[dbo].[T].[Month]=[@1] ))

更新：如果我运行以下查询
，查询运行速度很快，实际分区计数为 1。

select count(*), $partition.pfMonth(Month)
from T with (nolock)
where Month = '200706'
group by $partition.pfMonth(Month)

更新 2：
以下查询也只扫描一个分区。 …

假设我在只有一个驱动器的服务器上有一张大桌子。该表可能增长到半 TB（数亿行）。我认为分区的目的主要是为了维护目的，因为只有一个驱动器。

表应该以什么大小进行分区？

我有以下查询，它连接几个非常大的表的透视数据，并且运行速度非常慢。我尝试为每次旋转创建临时表，它运行得更快。这是一种在不创建临时表的情况下强制索引/表假脱机的方法吗？

select ...
from T1 ....
left join (select ... from (select ... from T2....) pivot (sum(C1) on C2 in (...))) p1 
    on ...
left join (select ... from (select ... from T3....) pivot (sum(...) on ... in (...))) p2
    on ...
left join (select ... from (select ... from T4....) pivot (sum(...) on ... in (...))) p3
    on ...