标签: sql-server-2008

我最近在我们的 SQL 2008 R2 服务器中遇到了一些超时问题。这种情况从上周晚些时候开始出现，此后有所改善。

问题：使用 SSMS 并右键单击数据库时...菜单将延迟显示。可以是 2-3 秒到 10 秒之间的任何时间。

尝试访问 SSMS 中的报告时，沙漏。它要么出错，要么最终显示报告。

使用 Team Foundation Server 并签入更改时，它不会由于超时而签入。调试Web应用程序时，访问数据库时可能会超时

我看过分析器，但没有看到任何突出的东西。CPU 利用率低，内存很好，并且没有任何类型的锁定问题。

问题消失时： 登录到本地数据库服务器并通过 SharedMemory 连接？“[当地的]”。一切都很快，并按预期运行。当我将连接切换为使用 TCP/IP ["127.0.0.1"] 时，我看到了相同的延迟。

同样，这不会整天发生......早上通常很好，然后在中午之后指向我将开始看到超时。

没有看到任何奇怪的东西：“从 sys.dm_exec_requests order by status”中选择 *。大多数都表现出睡眠。

没有看到任何奇怪的内容：“从 sys.dm_exec_sessions order by login_time desc 中选择 *”。大约 48 个活动会话。

 sp_monitor

 cpu_busy           io_busy         idle
 31331(2593)-17%    573(41)-0%  4025036(224233)-1531%

 packets_received         packets_sent  packet_errors
 6131943(343656)          6305718(356043)   0(0)

 total_read           total_write       total_errors    connections
 1372503(103382)      1678338(140267)   0(0)            5324156(296335)

 select @@MAX_CONNECTIONS == 32767

我们处于 SSAS 类型的环境中，拥有 100 名客户。

目前，每个客户端都有一个数据库，我们在 SQL Server 2008R2 上每个实例有 200 个。这会限制 snapmanager 能够进行备份，因为建议的数量是每个实例 (netapp) 35 个数据库。

我们正在研究的解决方案之一是整合数据库——使用单独的模式将其中的 150 个收集到一个数据库中。

有没有人做过这样的事情？
每个数据库的模式数量是否有限制，或者我们应该注意的性能问题与使用单独数据库的比较？

谢谢您的回答。

我们需要 Snapmanager 的原因是因为这是我们目前用于 DR 复制的内容，他们的建议是每个实例 35 个数据库，否则备份/传输数据可能需要一个多小时，这打破了我们的 1 小时恢复要求。

但是根据他们的说法，如果我们每个实例有 1 个数据库（或 35 个以下），他们应该能够让它没有问题。

所以这就是为什么我们可能会研究模式，但这意味着每个数据库很可能至少有 100 个模式。

我们有一个客户表（谁没有？），其中包含许多从业务角度来看是重复的记录。我已经能够创建一个 SSIS 包来执行模糊分组，并报告潜在的重复项。

现在，假设我想在有人进入新客户时进行这种分析。这个想法是对客户名称（可能还有一些其他基本信息，如邮政编码）执行模糊查找，并在继续客户创建表单之前显示潜在的重复项。

这里明显的问题是模糊分组和查找组件是 SSIS 的一部分。如果我想按需运行那些，我必须做一些疯狂的事情，比如将搜索词放在临时表中，运行 SSIS 包，等待它完成，并从输出表中获取结果。这会很慢，很痛苦，并且有严重的并发问题。

因此，另一个想法是使用全文索引。在试用它时，它看起来不合适。它无法捕捉到客户名称的细微拼写错误，或“Company”与“Corporation”与“Co.”或“Anderson”与“Andersen”以及其他此类变体的名称不同的名称。

有没有什么东西可以让 T-SQL 灵活地进行模糊分组/匹配？我可以通过模糊查找来保存标记，但看起来我仍然需要重新实现大部分匹配算法才能使用它们。

这是 SQL Server 专家的一个建议：如果我将 SQL Server 2008 事务隔离级别设置为READ UNCOMMITTED，这是否也会影响索引页？

例如，使用ISOLATION LEVEL READ UNCOMMITTED，ALLOW_PAGE_LOCKS或ALLOW_ROW_LOCKS对索引有什么影响（如果有）？

ALTER INDEX IX_FirstName ON Employee
SET (ALLOW_PAGE_LOCKS=OFF, ALLOW_ROW_LOCKS=OFF)

我似乎无法在任何地方找到明确的答案——关于事务隔离级别的 MSDN 文档实际上只讨论了数据页......

我希望能够锁定一行，选择它，增加它的值，然后释放锁定。（不锁定其他行，以便其他连接可以与表的其余部分一起使用）

我找到了这个

BEGIN TRAN SELECT * FROM tablename WITH (HOLDLOCK, ROWLOCK)
WHERE ID = 1

我的问题是我做不到

UPDATE tablename
SET columnName = -1
WHERE ID = 2

在我提交上一个事务之前，为什么行锁会锁定整个表？

编辑：

此代码是否保证在此更新命令期间不会更新所选行的数据？

UPDATE [tablename] WITH (ROWLOCK)
SET columnName = columnName + 5
WHERE ID = 1

以下问题与 Microsoft SQL Server 事务日志传送 (TLS) 有关。

我们使用的是 SQL Server 2008 R2 SP1，尽管这个问题可能与所有最新版本有关。

背景

我有一个主数据中心 (A) 和一个辅助的灾难恢复数据中心 (B)。假设我有 64 个数据库需要进行不同大小的日志传送，但没有一个数据库超过 50GB。

我目前正在使用 SQL Server 自动创建的默认 SQL 代理作业，因此我有 64 个 SQL 代理作业。

我想每 15 分钟记录一次每个数据库。假设如果我只是背对背传输所有文件，那是可能的。

问题

假设从 A 到 B 的路径通过公共 Internet 传输，因此我要为传输这些日志的带宽付费。我在第95 个百分位计量。我想平滑或优化带宽，以尽量减少支付超额的机会。我正在使用备份压缩。

可能的解决方案

我目前的想法是编写一个脚本，该脚本将自动自定义每个备份作业的开始时间。该脚本可以根据需要频繁运行以保持最佳传输。让它定期运行将使新添加的数据库的新日志传送备份作业能够在无需人工干预的情况下进行优化。

当前的 SQL 代理作业都以字符串“LSBackup”开头，因此我可以使用以下方法列出它们：

SELECT * FROM msdb..sysschedules WHERE name LIKE 'LSBackup%'

我可以获取所有 SQL 代理作业的列表并将它们存储在表变量中，然后在WHILE循环调用中迭代以适当EXEC msdb.dbo.sp_update_schedule地更新@active_start_time作业的空间。

我应该为每个作业的开始时间使用什么值？

为了回答这个问题，我需要知道日志备份文件可能有多大，以便最佳地分配作业。在运行备份之前，您能预测事务日志备份的大小吗？或者，我可以查看本地文件系统上过去几天的日志备份，以确定每个数据库的相对权重。然而，对于几乎没有事务日志备份历史的全新数据库来说，这并不真正有效。

假设可以确定每个备份的相对大小，那么在第 95 个百分位计量时将它们隔开以实现最小带宽影响的最佳算法是什么？

我正在制作一项需要保存按年月组合分组和计算的数据的服务。我知道如何计算数据并将其放在新表上。但是我很困惑应该使用哪种数据类型来存储月 - 年值。这是我所考虑的。

1. 两个整数列，一个为一年，另一个为一个月（清晰易懂且易于操作（使用此表的任何人都可以轻松使用范围和顺序），但我认为这比其他解决方案占用更多空间。
2. 使用日期字段，并始终为整个月存储一个日期。（很难向用户解释它是如何工作的以及如何创建 WHERE 子句）
3. 一个 varchar(7) 列并将其放在那里，例如 2012-02,2013-01。对我来说，这很容易理解，但很难操作。

我应该选哪个？或者有其他解决方案。有人可以根据性能建议哪种方式将是一个好的解决方案，因为大多数查询将在 where 解决方案中使用数据范围，而我的新表将有大约 2-5 百万条记录。

使用时间数据类型（我使用的是 Microsoft SQL Server 2008），有没有办法只取出它的分钟部分？我试图将时间传递给 datepart 和 datediff 函数，但都拒绝工作。

示例：我想从 04:15 得到 15

现有数据库在 PRIMARY 文件组中存储了大量表。我想根据表名的“前缀”自动将这些表及其索引移动到不同的文件组上。

例如，有 5 个表命名如下：

ABC_XXXX
ABC_YYYY
DEF_ZZZZ
DEF_TTTT
GHI_UUUU

ABC应将开头的所有表移到文件组FG1、DEF文件组FG2和其他表到文件组DEFAULT。

这可以使用以下命令完成CREATE INDEX：

CREATE (UNIQUE|CLUSTERED|) INDEX <Index Name> ON <Table Name>(<Index Columns>)
       WITH (DROP_EXISTING = ON) ON <New Filegroup>

这个命令最大的问题是按正确的顺序检索每个索引的列。

不确定这是否或多或少适合提出这个问题，最初是在Stack Overflow 上提出的。

在SQL Server 2008中我有一个观点V在表A和B看起来大致是

create view V as
    select * from A
    union all
    select * from B

读取V导致查询在基表上获取意图共享锁，但也会在视图对象本身上获取意图共享锁。

很明显为什么我们需要表上的 IS 锁，并且我们可以看到视图上的 IS 锁阻止了对视图底层表的并发修改。没关系。

查询计划没有提及视图。它是完全编译出来的，在这种情况下生成的计划是来自两个基表的行的简单串联。实际上，查询计划 XML 中唯一提到的视图是在语句文本中。

如果您U在表上添加第二个视图，则读取V不会导致任何锁定U。这排除了引擎只对A和上的所有视图进行 IS 锁定B。

数据库引擎如何知道锁定视图？

• 语句文本是否再次解析？
• 查询规划器和底层执行之间是否有其他一些信息通道来传递这些信息？如果是这样，是什么？

如果是后者，存储引擎知道锁定视图的机制的细节可以被认为是内部的。然而，它这样做的事实是用户可见的，我希望它在某处被记录下来。