我们偶尔会收到以下电子邮件提醒。
描述：用于打开连接的登录包在结构上无效；连接已关闭。请联系客户端库的供应商。
描述：网络数据包有效负载中指定的长度与读取的字节数不匹配；连接已关闭。请联系客户端库的供应商。
我试着在网上搜索。但是我没有任何好的方向来解决我应该如何对这些警报进行故障排除。在这种情况下，我应该联系应用程序团队检查错误代码还是联系安全团队检查任何恶意活动？感谢您的指导。
请您帮助我了解使用 Ola 的解决方案而不是维护计划的利弊？我准备了一个基于 SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) 的演示文稿，我将介绍它。
我还准备了一些 Ola 解决方案解决方案和维护计划解决方案没有解决的方案。大家能帮我从技术上解释一下吗？
顺便说一句，我们管理着近 150 多台服务器（2008/2012/2014/2016 年的混合），其中至少 75% 使用了 Ola 的解决方案。我喜欢 Brent Ozar 的这篇文章。但在其中一条评论中，布伦特建议对我们拥有的服务器数量使用基于脚本的解决方案。https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/
我们有 SQL Server 2008 SP2，如果我们需要他们的任何支持，Microsoft 告诉我们将其升级到 SP4。既然微软已经警告我们，我转向 SQL Server 2016 SP1 的道路就很明确了。回到我的问题，我在星期六将我们的生产服务器升级到 SQL Server 2008 SP4。但是执行速度很快的存储过程（这是一个相对术语）在星期一运行得太慢了。我没有看到任何阻塞。用户不是 内存压力似乎很正常。打开任务管理器时，我看到可用内存和可用内存。CPU有点高。但不固定在 100%。我的猜测是，计划缓存在升级后重新启动服务器后被刷新，今天查询受到影响。在升级之前，所有索引维护作业均已成功。我应该在升级后运行完整的索引维护吗？升级后我运行了DBCC CHECKDB，很清楚。复制是同步的。修改后的统计数据每天更新。如果您需要更多信息，请告诉我。任何见解都会有很大的帮助。谢谢你。
我只在一台准生产机器（SQL Server 2008 SP2 标准版）上看到一个令人困惑的问题。自 2017 年 2 月 4 日起，完整和差异备份工作突然开始耗时 48 小时。完整备份通常在一小时内完成，差异备份在几分钟内完成。有四台其他服务器备份到相同的共享和备份像往常一样成功。它们都是在 VMWARE 上运行的虚拟机，共享相同的底层 SAN。
系统管理员没有发现 SAN 和备份共享有任何问题。我没有看到任何阻塞。来自该机器的复制运行良好。事务日志备份作业运行良好，因为大多数数据库都具有简单的恢复模型。我可以从不超时的机器 ping 备份共享。
我用的是Ola的保养液。清理作业也成功运行。msdb 数据库大小不到 0.5 GB。如果我想念房间里的大象，请告诉我。
这是服务器上的等待。完整备份和差异备份作业（不同的数据库）仍在进行中。我在本地对一个小型数据库 (60MB) 进行了完整备份，很快就完成了。谢谢你。
我继承了这样的数据库系统。目前，我在带有 SQL Server 2008R2 SP2 机器的 Windows Server 2008 R2 上的 SQL Server 2005 兼容模式下拥有发布者数据库。分销商在同一台机器上。订阅者为 2008R2 SP2，数据库处于 SQL Server 2008 兼容模式。我们正在使用事务复制。隔离级别为已提交读。Distributor 位于 Publisher 上。即使当我右键单击发布时，即使订阅显示为拉订阅，我认为这并不重要，因为分发者驻留在发布者本身。如果我错了，请纠正我。存储系统是 IBM flex，由包括发布者和订阅者在内的五台服务器共享。
几天后，我看到几个小时的延迟，它在早上赶上，下午又开始上升。我跟着https://www.mssqltips.com/sqlservertip/3598/troubleshooting-transactional-replication-latency-issues-in-sql-server/看看到底发生了什么。我运行了以下查询。
USE distribution
go
EXEC Sp_browsereplcmds
@xact_seqno_start = '<seq#>' -- seq# is same for start and end
,@xact_seqno_end = '<seq#>'
,@publisher_database_id = <publisher database id --this is different than database_id
我看到在涉及复制的几个表上进行了大规模更新，而日志阅读器只是扫描事务日志，在事务完成之前无法复制任何内容。有趣的是，我看不到对发布者和/或订阅者的任何阻止。将隔离级别更改为已提交读快照隔离 (RCSI) 是否有帮助？将轮询间隔更改为 1 并将 readbatchsize 更改为 1000 或 5000 是否有帮助。更改该设置的命令是什么？
我更改了日志读取器代理默认配置文件，如下所示。轮询间隔从 5 到 1，ReadBatchSize 到 5000。这几乎立即将延迟从 13 小时降至零。但我看到它回到了 13 小时。
复制是同步的，我对导致延迟的实际根本原因没有任何线索，现在它消失了。
我刚开始担任 DBA 的新工作。突然之间，我们开始收到有关磁盘空间的警报。在查看时，我发现 tempdb 日志文件不断增长。有一个针对它运行的活动事务。我检查了查询，它正在使用临时表。从45分钟开始，它根本没有进展。我尝试了很多东西，包括这些作为最后的手段。
use tempdb
GO
DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
但这根本没有帮助。我还杀死了卡住的插入物。似乎它并没有超出规范过程。最后我不得不紧急中断几分钟并重新启动 SQL 服务。关于我可能错过的任何提示？