小编Col*_*art的帖子

我们一直在使用专用服务器（单四核，6 GB RAM）并且正在迁移到新的专用服务器（2x 六核，32 GB RAM）。两者都是Windows Server 2008、SQL Server 2008。新服务器上的性能比旧的、速度较慢的服务器稍差。

在测试中，我们的 ASP.NET 应用程序运行速度慢了 10 - 20%。使用 STATISTICS IO 和 STATISTICS TIME 运行单个昂贵的查询显示在新服务器上花费的时间增加了 10 - 20%。SQL 查询配置文件在昂贵的查询中显示更高的 CPU 使用率。

新服务器上的任务管理器显示 sqlserver.exe 正在消耗 22 GB 的 RAM，但 CPU 值始终保持很低。

我已经更新了所有统计信息、重建或重新组织的索引等。考虑到我已经完成的测试数量，此时执行计划应该存储在新服务器上。如果缺少任何索引（我认为没有），它们会同等影响旧服务器和新服务器。新的具有旧的相同数据的恢复备份。

我原以为新服务器上的性能会更好，但更令人担忧的是负载。如果旧服务器即使在负载下也能表现得更好，那么当这个新的、稍微差一点的服务器必须承担那个负载时会发生什么？

我还能在这里错过什么？

编辑：MAXDOP 设置为 6。

旧服务器在相同的物理驱动器 (RAID 10) 上具有操作系统、数据库和 tempdb。总共 4 个 15k 3 Gb/s 3.5 英寸 SAS。新服务器具有三个驱动器组：RAID 1 上的操作系统、RAID 10 上的数据库、RAID 5 上的 tempdb。总共 9 个 15K 6 Gb/s 2.5 英寸 SAS。

旧服务器有 1 x Intel Xeon E5620 2.40 GHz 四核 …

我正在从没有文档的旧系统中归档数据。幸运的我...

我想知道表的创建时间、上次访问时间等。我可以相信这个查询会给我正确的答案还是我首先需要检查一些参数？SQL Server 2008 R2：

 SELECT t.Name AS Tabelname, p.rows AS NoOfRows, MAX(us.last_user_lookup) AS LastUsed, t.create_date AS CreatedDate
FROM sys.tables t
INNER JOIN      
    sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN 
    sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
LEFT JOIN --A lot of the tables did not have any records in this table
    sys.dm_db_index_usage_stats as us ON t.OBJECT_ID = us.OBJECT_ID
GROUP BY t.Name, p.rows, create_date
ORDER BY MAX(us.last_user_lookup) DESC

我在 SQL Azure 上有一个数据库，想为此创建一个数据库图表，但不想安装 SQL 服务器并复制数据库等。有什么方法可以做到这一点，有人知道吗？

我的理解是，在 MS SQL Server Management Studio 窗口中，在执行“开始事务”然后进行一些更改（例如将数据添加到表）之后，您只能从同一窗口查询该表和这些更改，直到您执行“提交交易”。

在执行“提交事务”之前，有什么方法可以从其他来源进行查询？

具体到我当前的目标并添加一些上下文。我从 Excel Power Query 执行一些 SQL 查询。我真的很希望能够在“提交事务”之前执行这些查询，以便我可以进行一些分析并确定是否应该进行回滚而不是提交。

有没有人成功镜像分发数据库？我们有一个专用服务器作为分销商。它处理我们从生产到报告的所有推送复制。我们想在附近建立一个相同的服务器，以防分销商崩溃。有没有人成功构建过这样的东西？

我们刚刚开始设计一个新的数据仓库，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是 GMT、IST、PST 和 EST）。我们最初认为我们将有一个广泛的组合日期时间维度，大约 15 分钟的粒度，这样我们的事实表中有一个键，所有支持的时区的所有不同日期时间数据都在一个维度表中。（即日期键、GMT 日期、GMT 时间、IST 日期、IST 时间等...）

Kimball 建议从一天的时间维度中设置一个单独的日期维度，以防止表变得过大（数据仓库工具包第 240 页），这听起来不错，但这意味着我们在每个时区的事实表中有两个键我们需要支持（一个用于日期，一个用于一天中的时间）。

由于我在这方面非常缺乏经验，我希望有人知道这两种方法之间的权衡，即性能与所有不同时区键的管理。也许还有其他方法，我看到有些人谈论在每个时区的事实表中有一个单独的行，但这似乎是一个问题，如果你的事实表有数百万行，那么你需要将它翻两番来添加时区.

如果我们使用 15 分钟的粒度，我们的日期时间维度表中每年将有 131,400 (24 * 15 * 365) 行，这对性能来说听起来并不太可怕，但在我们测试之前我们不会确定原型查询。在事实表中使用单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到不同的列，也许这是 SSAS 为您处理的事情，我不确定.

感谢您的任何想法，-马特

鉴于被苹果以 2 亿美元收购的自然语言用户界面Siri的流行，我想知道是否有人知道微软为什么在 SQL Server 上杀死了“English Query”。

由于在这种模式下 pgbouncer 为每个入站连接创建出站连接，因此在我看来 pgbouncer 不能作为池化器工作。这只是1对1的映射。

我哪里错了？

我想在同一个 SqlServer 中制作数据库的副本。所以，当我使用复制数据库向导时，它会抛出错误：（我用测试数据库做了这个步骤，它工作正常！！！）

配置：

用户

方法：“使用 SQL 管理对象方法”

为目标数据库选择新名称。

错误：

标题：复制数据库向导

作业失败。有关详细信息，请检查目标服务器上的事件日志。

- - - - - - - - - - - - - - - 纽扣：

好的

在事件日志中：

• 系统

  • 提供者

  [名称] SQLSERVERAGENT

  • 事件 ID 208

  [限定词] 16384 Level 3 Task 3 关键词 0x80000000000000

  • 时间创建

  [ SystemTime] 2014-05-07T06:23:11.000000000Z EventRecordID 123672 Channel Application Computer Server1 Security

• 事件数据

  CDW_Server1_Server1_3 0x666DE807F406D7438C65B09171211D7B
  失败 2014-05-07 10:52:50 作业失败。作业由用户 sa 调用。运行的最后一步是步骤 1 (CDW_Server1_Server1_3_Step)。

日志文件的最后几行：

OnProgress,Server1,NT Service\SQLSERVERAGENT,Server1_Server1_Transfer Objects 任务,{066BD090-26F3-45D8-AD60-B207D56D44CE},{1CF7B713-F747-45FB-8936-5522651,E0C76A,580C70A /7/2014 10:08:46 AM,0,0x，1 个数据库的数据库传输失败。OnProgress,Server1,NT Service\SQLSERVERAGENT,Server1_Server1_Transfer Objects 任务,{066BD090-26F3-45D8-AD60-B207D56D44CE},{1CF7B713-F747-45FB-8936-5522651,E0C76A,580C70A /7/2014 …

在解决将断开连接的设备与中央数据库服务器同步的问题时，我们在服务器上升级到 SQL Server 2012 后遇到了问题。看起来 CHANGE_TRACKING_MIN_VALID_VERSION 返回的值比它应有的值高 1（或至少比升级前的值高）。

我一直在研究如何设置简单示例的Arshad Ali 的精彩示例。

我已经运行了从 #1 到 #5 的脚本，以在 SQL Server 2008 和 2012 环境中的 Employee 表中插入、删除和更新一行。

在 2008 年，以下语句返回 0：

SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('Employee'))

在 2012 年，它返回 1。

在测试中通过更多脚本 (6-8) 工作时，我将保留期设置为 1 分钟，以期强制执行清理操作。我离开了一天，显然它运行了一夜。

在 2008 年的实例中，CHANGE_TRACKING_CURRENT_VERSION 和 CHANGE_TRACKING_MIN_VALID_VERSION 是相等的 (11)。在 2012 年的实例中，CHANGE_TRACKING_MIN_VALID_VERSION 比 CHANGE_TRACKING_CURRENT_VERSION (11) 高一 (12)。当数据库长时间空闲时，这可能会对同步过程产生影响。我们发现进程可能会陷入循环，尤其是在执行以下测试以确定是否需要重新初始化而不是同步时：

IF CHANGE_TRACKING_MIN_VALID_VERSION(object_id(N'dbo.Employee')) > @sync_last_received_anchor 
       RAISERROR (N'SQL Server Change Tracking has cleaned up tracking information for table ''%s''...

有没有其他人经历过这种行为变化？有人有解释吗？