小编Kin*_*hah的帖子

请让我解释一下我的问题和情况：

我有一个 Web 应用程序 - MVC3、MSSQL Server 2005、LinqToSQL。它一直运行良好，直到一个晴朗的早晨，我将很多行推送到一个经常使用的表中，从那时起我就遇到了查询超时。为了解决这个问题，我运行了 Database Tuning Advisor 并添加了一些索引和统计信息。我还创建了一个维护计划来每天重建索引。这些添加后，应用程序一直表现不稳定；它会快速工作几个小时，然后它会再次开始超时。接下来，生活迫使我清理表格，现在其中的行数比以前更少，但超时仍在发生。所以，我删除了我创建的所有索引，现在网站更加稳定，但有时我仍然会看到一些超时。

我一直在试图弄清楚如何修复这些查询，当我对其进行分析并将查询直接粘贴到 SQL Management Studio 时，它会在 1 秒内返回结果，但是当我从我的应用程序运行此查询时，大约需要 25 秒. 然后在它第一次运行后，下次它会像在服务器上一样快！

我开始做一些研究，看起来当我使用所有这些索引时，我的查询计划搞砸了，现在它们正在产生问题。

我的问题是：

1. 我是否应该刷新我的查询计划缓存（大约 22000 个查询 - 其中很多只使用过一次）并且
2. 如果我这样做，对 SQL 都在重建时会产生什么影响？

我需要重命名我的数据库中的一些表 - SQL Server 2005，如下：

EXEC sp_rename 'dbo.TableName', 'Tmp_TableName', 'OBJECT'

但我不能这样做 - 我得到了这个例外 -

无法重命名表，因为它是为复制而发布的

这个数据库没有复制 - 它在 5 年前被删除 - 我们刚刚尝试过并在一周后将其删除。所以我想它应该是某个地方的一面旗帜。

请帮我以某种方式删除此标志。

我有兴趣确定我所有 70 多台服务器的年龄。我想创建一个增长图，显示服务器和数据库何时/每月或每年添加到环境中。我使用 SSMS 多查询功能执行了以下查询，但仅部分成功。

SELECT [name], create_date FROM sys.databases

这是部分成功，因为当我知道我在过去几年中创建了其中一些服务器时，主数据库和模型数据库返回的日期为“2003 年 4 月 8 日”。

我每周多次将数据库从一台服务器刷新到另一台服务器，这似乎会导致数据库创建日期出现问题。

是否有一种简单的方法可以确定服务器和数据库的实际创建日期？

题

1. 为什么尽管这两个数据库的 log_send_queue_size 越来越大，但 log_send_rate 却一直在下降？
2. 此时网络上没有带宽问题，其他数据库也没有遇到此问题。如果再次发生这种情况，除了必须通过辅助数据库手动还原主数据库以重新同步该对之外，是否有推荐的修复方法？

环境 ：

SQL 2012，SP1 CU7（内部版本 3393）

Windows Server 2012 标准版（内部版本 9200）

10 个数据库的可用性组 (PRDDB1-AG1)

2 个 AG 副本，一个在伦敦，一个在纽约（LDSERVER1 和 NYSERVER1），主要在纽约，次要在伦敦。

AG1 中的 2 个数据库，E-DB1（50GB 日志文件）和T-DB2（250GB 日志文件）

在T-DB2从客户数据库导入文件，对其进行处理（大量日志活动），然后输出到/更新数据E-DB1的数据库。

此过程会针对两个数据库生成大量数据流失和日志活动。我们偶尔会在伦敦和纽约数据库副本之间出现延迟高峰，最多可能每周一两次，但这些总是在几个小时内清除。

问题 ：

上周我们看到 log_send_queue_size 增加，而 log_send_rate 减少。这从星期一开始，一直持续到星期五晚上，当时它是手动解决的（请参阅下面的修复部分）。最低时，E-DB1 数据库的 log_send_rate 刚刚超过 100KB/秒，log_send_queue 超过 40GB。T-DB2 数据库的 log_send_rate 为 2000KB/sec，缩小到 300KB/sec，log_send_queue 超过 300GB。

这导致可用性组内这两个数据库的主副本和辅助副本之间的延迟量增加。其特点是在每个受影响的数据库的事务日志中积累了日志活动，这是意料之中的。由于这种延迟，每个受影响的数据库的日志扩展到日志驱动器有空间不足的危险。

这种延迟只发生在这两个数据库上，尽管可用性组内所有数据库的事务活动出现了一些相当大的峰值，这是正常的。

在整个问题中，辅助节点上的重做队列中没有堆积，并且 redo_rate 保持高位。这意味着该问题是由于两个受影响数据库的发送速率都很低造成的。

尝试的步骤

1. 暂停 T-DB2 数据库的数据移动。我希望这可以为优先级数据库 E-DB1 释放网络带宽。没有效果。

2. 重新启动辅助节点 (LDPRDENTDB1)。没有效果。 …

我正在尝试将完整的数据库备份和事务日志还原到最新的事务日志。我已将交易日志设置为每 15 分钟发送一次。此设置是通过 SMSS GUI 执行的。完整数据库备份每天上午 12 点开始，通常在凌晨 2 点之前完成。

首先，我使用 NORECOVERY 恢复完整备份。：

USE [master]
RESTORE DATABASE [DBNAME] FROM  DISK = N'X:\path\to\DBNAME.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 5
GO

这将成功完成。

然后，我获取最旧的事务日志并运行以下命令：

RESTORE LOG DBNAME FROM DISK = 'X:\path\to\OldestTransactionLog.trn' WITH NORECOVERY;

但是，我收到以下错误：

Msg 4305, Level 16, State 1, Line 10
The log in this backup set begins at LSN 421814812000000025600001, which is too recent to apply to the database. An earlier log backup that includes LSN 421787067000000013800001 …

我有一个 SQL Server 2012 维护计划，它执行正常的操作（重建索引和更新统计信息、备份数据库、删除超过 X 天的 .bak 文件等）。除了一项维护清理任务外，一切正常：

这应该是删除所有意外留在每晚备份目录中的 .7z 档案（相当于 .zip 或 .rar）（尽管我们尽了最大努力，但最终还是有些人将这些文件留在服务器上......），但是E:\Backups\foo\bar.7z在维护计划运行后，子目录（例如）中仍然存在旧的 .7z 文件。

SQL Server 日志中没有错误。

我怀疑这是因为“删除以下类型的文件：备份文件”选项限制了可以删除的文件类型。我还尝试使用 7z 扩展名将其更改为“维护计划文本报告”，但没有任何更改。

是否可以让维护计划在维护清理任务期间删除任意（非 SQL Server）文件？如果是这样，知道我做错了什么吗？

假设我正在使用 跟踪查询sys.dm_exec_query_stats，如果查询顺利结束，那么我们可以在 中找到相关统计信息sys.dm_exec_query_stats。但是，如果取消查询，则该查询的统计信息（即在被用户取消之前执行了多长时间、其 I/O 使用情况等）在sys.dm_exec_query_stats.

还有其他地方可以获取此信息吗？

我想将本地 SQL 数据库传输到 Microsoft Azure。db中存储了文件，因此db大小约为300MB。

在 SQL Server Management Studio 中，我尝试了以下操作：

任务->生成脚本

我能够创建.sql脚本但无法加载它。

我也试过

任务->将数据库部署到 SQL Azure...

但大约 30 分钟后，它崩溃了。

有任何想法吗？

我正在负载测试环境中收集等待类型，第二大等待类型是QDS_SHUTDOWN_QUEUE. 统计数据来自 sys.dm_os_wait_stats，但我找不到任何解释该特定类型含义的文档。

我在物理 Windows 2008 R2 实例（不涉及 VM）上运行 SQL Server 2014 SP1。

我有一个问题，如何在 MS SQL 中实现自动增量。到目前为止我知道的一种方法是在表格中进行修正，例如

CREATE TABLE Customer (
    CUSId INT NOT NULL IDENTITY(1, 1) PRIMARY KEY
    ,CUSKey AS 'Cus' + RIGHT('000' + CONVERT(VARCHAR(5), CUSId), 6) PERSISTED
    ,CusName VARCHAR(50)
    ,mobileno INT
    ,Gender VARCHAR(10)
    )

我会得到类似的东西

Cus0001
Cus0002

Cus9999 之后呢？

一些如何实现这样的自动增量

CUSAB000001
CUSAB000002
CUSAB000003
CUSAB000004
CUSAB000005
CUSAB000006
CUSAB000007
CUSAB000008
CUSAB999999
CUSCD000001
CUSYZ999999.