标签: sql-server-2008-r2

SQL Server 占用了我服务器 RAM 的 87.5%。这最近造成了很多性能瓶颈，例如缓慢。我研究了这个问题。我可以在 Internet 上找到的一种常见解决方案是设置 SQL Server 的最大限制。这已经完成并且获得了很大的改进。我想知道为什么如果没有设置最大内存值为什么 SQL Server 不断消耗资源

我想了解为什么在 UAT（3 秒内运行）与 PROD（23 秒内运行）上执行相同查询时会有如此巨大的差异。

UAT 和 PROD 都拥有准确的数据和索引。

询问：

set statistics io on;
set statistics time on;

SELECT CONF_NO,
       'DE',
       'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
       CONF_TARGET_NO
FROM   CONF_TARGET ct
WHERE  CONF_NO = 161
       AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
       AND ( ( REGISTRATION_TYPE = 'I'
               AND (SELECT COUNT(1)
                    FROM   PORTFOLIO
                    WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                           AND DEACTIVATED_YN = 'N') > 1 )
              OR ( REGISTRATION_TYPE = 'K'
                   AND (SELECT COUNT(1)
                        FROM   CAPITAL_MARKET
                        WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS …

我有一个相当简单的查询

SELECT TOP 1 dc.DOCUMENT_ID,
        dc.COPIES,
        dc.REQUESTOR,
        dc.D_ID,
        cj.FILE_NUMBER
FROM DOCUMENT_QUEUE dc
JOIN CORRESPONDENCE_JOURNAL cj
    ON dc.DOCUMENT_ID = cj.DOCUMENT_ID
WHERE dc.QUEUE_DATE <= GETDATE()
  AND dc.PRINT_LOCATION = 2
ORDER BY cj.FILE_NUMBER

这给了我可怕的表现（就像从不费心等待它完成一样）。查询计划如下所示：

但是，如果我删除它，TOP 1我会得到一个看起来像这样的计划，它会在 1-2 秒内运行：

下面更正 PK 和索引。

TOP 1更改查询计划这一事实并不让我感到惊讶，我只是有点惊讶它使情况变得更糟。

注意：我已经阅读了这篇文章的结果并理解了 aRow Goal等的概念。我很好奇的是如何更改查询以使其使用更好的计划。目前我正在将数据转储到临时表中，然后从中取出第一行。我想知道是否有更好的方法。

编辑对于事后阅读本文的人，这里有一些额外的信息。

• Document_Queue - PK/CI 是 D_ID，它有大约 5k 行。
• Correspondence_Journal - PK/CI 是 FILE_NUMBER，CORRESPONDENCE_ID，它有大约 140 万行。

当我开始时，没有其他索引。我在 Correspondence_Journal (Document_Id, File_Number) 上找到了一个

我有一个类似如下的查询：

DELETE FROM tblFEStatsBrowsers WHERE BrowserID NOT IN (
    SELECT DISTINCT BrowserID FROM tblFEStatsPaperHits WITH (NOLOCK) WHERE BrowserID IS NOT NULL
)

tblFEStatsBrowsers 有 553 行。
tblFEStatsPaperHits 有 47.974.301 行。

tblFEStatsBrowsers:

CREATE TABLE [dbo].[tblFEStatsBrowsers](
    [BrowserID] [smallint] IDENTITY(1,1) NOT NULL,
    [Browser] [varchar](50) NOT NULL,
    [Name] [varchar](40) NOT NULL,
    [Version] [varchar](10) NOT NULL,
    CONSTRAINT [PK_tblFEStatsBrowsers] PRIMARY KEY CLUSTERED ([BrowserID] ASC)
)

tblFEStatsPaperHits：

CREATE TABLE [dbo].[tblFEStatsPaperHits](
    [PaperID] [int] NOT NULL,
    [Created] [smalldatetime] NOT NULL,
    [IP] [binary](4) NULL,
    [PlatformID] [tinyint] NULL,
    [BrowserID] [smallint] NULL, …

什么时候应该使用完整恢复模型，什么时候应该对数据库使用简单恢复模型？

我总是使用完整恢复模式，因为它是默认模式，但今天我遇到了这个错误：

Microsoft OLE DB Provider for SQL Server (0x80040E14) 数据库“DATABASE NAME”的事务日志已满。要找出无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列

特定的数据库实际上是我服务器上最小和最不活动的数据库之一，所以我不知道这个数据库上的日志如何被填满，而不是其他数据库。

为了缩小日志并使数据库再次可访问，我将恢复模式从 FULL 更改为 SIMPLE 并缩小了逻辑文件日志，使用以下命令

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

它帮助，但现在我需要了解为什么它的帮助下，如何这种情况开始，如何防止这种情况在未来？

编辑：

每天晚上 1 点，我们都会对服务器上的每个数据库进行脚本备份。这是由 31 行脚本完成的，其中最重要的部分是

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK …

我以前没有见过SLEEP_TASK等待类型，今天我似乎得到了很多。

我不是正式的 DBA，只是一名了解 DBA 知识的 SQL Server 开发人员。我们上周末将服务器升级到10.52.2500.0- 我认为是 R2SP1。

我在网上能找到的所有信息都表明SLEEP_TASK服务器正在等待某种内部进程完成。我没有任何阻塞或任何后台进程，如检查点或幽灵清理运行，所以我有点难住。

有没有人以前见过这种等待类型，如果有，你能告诉我是什么原因造成的吗？

我有几个具有相同基本结构的非常大的桌子。每个都有一个RowNumber (bigint)和DataDate (date)列。每晚都使用 SQLBulkImport 加载数据，并且永远不会加载“新”数据 - 它是历史记录（SQL Standard，不是 Enterprise，因此没有分区）。

因为每一位数据都需要绑定回其他系统，并且每个RowNumber/DataDate组合都是唯一的，那就是我的主键。

我注意到，由于我在 SSMS 表设计器中定义 PK 的方式，RowNumber列在第一和DataDate第二位。

我还注意到我的碎片总是非常高~99%。

现在，因为每个DataDate只出现一次，我希望索引器每天只添加到页面，但我想知道它是否实际上是基于RowNumber第一个索引，因此必须改变其他所有内容？

Rownumber不是标识列，它是由外部系统生成的 int（遗憾的是）。它在每个 开始时重置DataDate。

示例数据

RowNumber | DataDate | a | b | c..... 
   1      |2013-08-01| x | y | z 
   2      |2013-08-01| x | y | z 
...
   1      |2013-08-02| x | y | z 
   2      |2013-08-02| x | y | z 
...

数据按RowNumber顺序加载， …

我的许多数据库都有定义为 varchars 的字段。自从我在美国生活和工作以来，这并不是什么大问题（那里唯一存在的语言是“美国”。咳咳）

在使用数据库大约 5 年后，我发现我最终遇到了 varchar 字段的有限性质的问题，我必须修改我的字段以将数据存储为 nvarchars。在不得不对表进行另一次更新，将 varchar 字段转换为 nvarchar 之后，我有了一个想法——为什么我们仍然这样做？我早就决定将所有新的文本字段定义为 nvarchar，而不是 varchar，这是我 10 年前在学校时从教科书中学到的。

现在是 2011 年，去年发布了新版本的 SQL Server。当我们可以/应该使用 nvarchar 时，为什么我们继续支持 varchar 数据类型？

我知道经常有人争论 nvarchars 是 varchars 的“两倍大”，因此存储空间的使用可能是维护 varcars 的一个争论点。

但是，今天的用户如果想节省存储空间，可以定义他们的 nvarchars 以将数据存储为 UTF-8 而不是默认的 UTF-16。如果主要需要，这将允许 8 位编码，同时保证插入到他们的数据库中的稀有 2-8 字节字符不会破坏任何东西。

我错过了什么吗？在过去的 15 到 20 年里，这是否有充分的理由没有改变？

我们在虚拟 Windows 2008 R2 服务器上运行 SQL Server 2008 R2 (10.50.1600)。在将 CPU 从 1 核升级到 4 核并将 RAM 从 4 GB 升级到 10 GB 后，我们注意到性能更差。

我看到的一些观察：

1. 运行时间 <5 秒的查询现在需要 >200 秒。
2. CPU 被锁定在 100，而 sqlservr.exe 是罪魁祸首。
3. 一个有 460 万行的表上的 select count(*) 花费了 90 多秒。
4. 服务器上运行的进程没有改变。唯一的变化是增加了 cpu 和 ram。
5. 其他 sql 服务器有一个静态分页文件，该服务器设置为自行管理它。

有没有人遇到过这个问题？

根据 sp_BlitzErik，我跑了

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

给我这些结果。

我的一位同事在我们的 SQL Server 2008 R2 数据库中命名了一个存储过程sp_something。看到这里，我立刻想：“那是错的！” 并开始在我的书签中搜索这篇解释错误原因的在线文章，以便我可以向我的同事提供解释。

在文章（由Brian Moran撰写）中解释说，给存储过程一个sp_前缀会使 SQL Server 查看主数据库以获取编译计划。因为sp_sproc不驻留在那里，SQL Server 将重新编译该过程（并且需要一个排它编译锁，导致性能问题）。

文章中给出了以下示例以显示两个程序之间的区别：

USE tempdb;
GO

CREATE PROCEDURE dbo.Select1 AS SELECT 1;
GO

CREATE PROCEDURE dbo.sp_Select1 AS SELECT 1;
GO

EXEC dbo.sp_Select1;
GO

EXEC dbo.Select1;
GO

您运行它，然后打开 Profiler（添加存储过程 ->SP:CacheMiss事件）并再次运行存储过程。您应该会看到两个存储过程之间的区别：sp_Select1存储过程生成的SP:CacheMiss事件比Select1存储过程多一个（文章引用了SQL Server 7.0和SQL Server 2000。）

当我在我的 SQL Server 2008 R2 环境中运行该示例时，我SP:CacheMiss为两个过程（在 tempdb 和另一个测试数据库中）获得了相同数量的事件。

所以我想知道： …