小编Aar*_*and的帖子

我在 sqlskills.com 上使用此博客作为练习在事务日志备份中查找相关 LSN 以进行时间点恢复的指南。

备份事务日志后，我尝试使用以下命令读取它：

SELECT COUNT(*) FROM fn_dump_dblog (
NULL, NULL, 'DISK', 1, 'D:\TEMP\test_tlog2.bak',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, …

我需要对 AlwaysOn 进行一些基准测试，无论是否启用 TDE。我看到的所有说明都涉及将加密数据库添加到可用性组，但我没有提到为 AG 中已有的数据库启用加密。

我可以将服务器证书恢复到所有节点，然后从主节点启用 TDE 吗？我希望我不需要从 AG 中删除数据库，对其进行加密，然后重新初始化所有节点，因为数据库大约为 100 GB。如果需要，我们可以这样做，但这肯定会减慢我们的测试速度。

更新

我只是在一些实验室虚拟机上尝试过这个。我能够在主节点上创建一个证书，在所有辅助节点上恢复它，然后使用这个证书在主节点上创建一个数据库加密密钥。之后我所要做的就是ALTER DATABASE AdventureWorks SET ENCRYPTION ON在主服务器上，一两分钟后，sys.dm_database_encryption_keys 在所有节点上都显示了 encryption_state = 3。

那么，后续问题：是否有任何理由认为我不应该使用此程序？SQL Server 似乎对结果很满意，但我还没有看到任何地方讨论过这种方法。在处理加密和高可用性问题时，我不想让事情碰运气。

假设我有一个看起来像这样的表：

CREATE TABLE Activity (
    ActivityID int primary key identity(1,1) ,
    ActivityName nvarchar(10),
    InactiveFlag bit
)

具有如下所示的索引：

CREATE INDEX Activity_Index on Activity 
( 
    ActivityName
)

然后出于某种原因，有人创建了第二个索引：

CREATE INDEX Another_Activity_Index on Activity 
( 
    ActivityName, InactiveFlag
)

删除第一个索引绝对安全吗？它只是占用了不必要的磁盘空间吗？第二个索引会覆盖第一个索引的所有情况吗？列排序绝对是“ActivityName”第一。

我正在尝试在两个表之间进行单列合并。第一个表 ( VisitorSession) 有 40,000,000 行。第二个 ( ShoppingCart) 有 9,000,000 行。

在我的开发环境中，查询只需不到 8 分钟。但是在生产环境中，它应该占用更少（更强大的机器）。但是，我预计该查询至少需要 2 分钟才能在生产中运行。我知道这个查询会导致开发环境中的其他开发人员超时，这意味着它很容易导致客户超时。是否有更安全和/或更快的方法来执行此查询？

declare @dt datetime = cast(dateadd(month, -6, getdate()) as date);

merge ShoppingCart as TargetTable  -- 07:55 to complete in Dev
using 
(
  select * from -- 04:55 to run select, resulting in 12,727,927 rows in Dev
  (
    select
      visitorid  -- int, not null, foreign key
      ,useripaddress  -- varchar(55), null
      ,row_number() over 
      (partition by visitorid order by createdate desc) as [row]
    from VisitorSession (nolock) …

我是一位经验丰富的 SQL Server DBA，但不熟悉分区，我有几个问题。使用 SQL Server 2008 R2 企业版。

我继承了一个每天增长约 10 GB 的大型客户指标数据库。该数据库目前由一个文件组 (PRIMARY) 中的一个大数据文件组成。所有表都有一个名为 的日期时间列InsertedDate。我想对数据进行水平分区InsertedDate，每个日历周使用一个单独的数据文件。

在测试环境中，我将所需的附加文件组和数据文件添加到该数据库中，InsertedDate在每个表中放置了聚集索引，并设置了分区功能和分区方案。通过查询sys.partitions和其他系统表，我确认数据现在物理上驻留在正确的分区和数据文件中。

其中，目标是：

• 通过仅备份PRIMARY当前日期范围内的文件组和文件组来减少备份时间（我目前正在运行每晚完整备份）。一旦日期范围过去，该分区将永远不会被再次写入，因此我想将文件组设置为只读并最后一次备份它。

• 能够最终使分区“停止服务”。3 个月后，不再需要将旧数据保持在线，因此我想将这些数据离线（但如果需要，可以再次将这些数据重新在线）。

问题：

1) 如何在不备份整个数据库的情况下对这个分区数据库执行备份？我可以备份单个文件组，但要恢复它需要数据库的其余部分，这违背了使用多个较小数据文件的目的。

2) 如何使分区停止服务？我读过关于切换的内容，但似乎只有当您想在同一数据库内的分区之间移动数据时才有效。我希望能够简单而安全地将一系列数据脱机（并在必要时将其重新联机）。

我正在尝试搜索?字符串中的字符，但在服务器上的所有数据库中搜索。由于?标记是数据库名称的占位符，我如何格式化查询以便它知道我的意思是搜索?而不是用数据库名称替换它？

此时的 WHERE 子句是：

WHERE DirectoryPath LIKE ''%?%''

这导致：

WHERE DirectoryPath LIKE '%DATABASENAME%'

我需要它呈现为：

WHERE DirectoryPath LIKE '%?%'

如何更改 sql server 2008 R2 中的列顺序？

例如：我的餐桌顺序是开斋节------Ename-----Esalary

知道我想要这种格式，例如 Eid---Salary----Ename

谢谢。

我有一个使用以下 T-SQL 创建的表：

CREATE TABLE [dbo].[TableName](
    [id] [int] IDENTITY(1,1) NOT NULL
PRIMARY KEY CLUSTERED 
(
    [id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

我今天查看了这张表，注意到 id 列正在跳过值：

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26、27、1027、1028、1029、1030、1031、1032、1033、1034、1035、2034、2035、3034

我不担心这个或任何事情（我的应用程序不关心主键是什么），我只是想知道可能导致这种情况发生的原因。似乎确实有一种模式，每次“跳跃”发生时跳跃 1000。

我的应用程序使用实体框架插入这些行，如果这有什么不同的话。

所以我和几个人就一个给定的数据库应该拥有的事务日志文件的数量进行了争论。我看过几篇帖子说每个数据库应该只有 1 个事务日志文件，但在任何 Microsoft 白皮书中都没有。然而，在许多情况下，我已经看到增加给定数据库的事务日志文件的数量实际上会提高对数据库的写入性能。我应该注意到，所有这些数据库都处于完全恢复模式，并且为 I/O 子系统使用了大型 SAN 框架。如果很多帖子都说事务写入都是串行发生在一个文件中，直到到达文件末尾，那么写入会转移到后续的日志文件中，为什么增加日志文件的数量最终会对磁盘写入速度有非常明显的提高？在最近的案例中，通过将日志文件的数量从 1 增加到 8，我们看到 IO 从 700 Kb/s 跃升至超过 60 Mb/s。任何输入都将不胜感激。

请，如果这里不是发布此类问题的地方，请告诉我，我将删除它。

在 Glenn berry 的诊断查询中，有一个查询来显示数据库使用了多少 CPU。这是查询：

-- Get CPU utilization by database (Query 24) (CPU Usage by Database)
WITH DB_CPU_Stats
AS
(SELECT DatabaseID,
        DB_Name(DatabaseID) AS [Database Name],
        SUM(total_worker_time) AS [CPU_Time_Ms]
 FROM sys.dm_exec_query_stats AS qs
 CROSS APPLY (SELECT CONVERT(int, value) AS [DatabaseID] 
              FROM sys.dm_exec_plan_attributes(qs.plan_handle)
             WHERE attribute = N'dbid'
              ) AS F_DB
 GROUP BY DatabaseID)
SELECT ROW_NUMBER() OVER(ORDER BY [CPU_Time_Ms] DESC) AS [CPU Rank],
       [Database Name], [CPU_Time_Ms] AS [CPU Time (ms)], 
       CAST([CPU_Time_Ms] * 1.0 / SUM([CPU_Time_Ms]) OVER() * 100.0 AS …