我在生产服务器上有几个数百 GB 的数据库，每天都有成千上万的事务通过它们运行。

几乎所有这些数据库都使用 SQL Server 镜像进行镜像。

尽管我们已经仔细规划了物理日志文件大小以匹配预期的日志文件活动；偶尔会出现问题，日志需要增长到超出我们预测的最大值。我们已将所有日志文件设置为增长 8192MB，但是当数据库面临增长日志文件的压力时，它有时只会以非常小的块增长日志，从而在某些情况下创建数十万个虚拟日志文件 (VLF) .

当我们的一个生产数据库意外恢复超过 200,000 个 VLF 时，我开始理解保持低 VLF 数量的重要性。恢复需要 20 多个小时；在此期间，我们的部分业务无法运营。

我需要一个可以监控服务器上所有数据库的虚拟日志文件数量的解决方案，如果任何特定日志文件的 VLF 数量超过给定数量，则发送警报电子邮件。

我知道DBCC LOGINFO;返回 VLF 列表，但是，我不想手动运行它。

我创建了以下 SQL 语句，该语句创建了一个列出数据库以及 VLF 数量的漂亮表，但是，我不知道如何将其放入 SQL 代理作业中，以便在任何数据库的数量超过“x”时向我们的团队发送电子邮件的 VLF。

DECLARE @cmd_per_database_prefix nvarchar(max);
DECLARE @cmd_per_database nvarchar(max);
DECLARE @database_name nvarchar(255);
SET @cmd_per_database = '';
SET @cmd_per_database_prefix = 
'
    SET NOCOUNT ON;
    DECLARE @vlf_count_table TABLE (database_name nvarchar(255), vlf_count int);
    DECLARE @params nvarchar(max);
    DECLARE @db_name nvarchar(255);
    DECLARE @vlf_count int;
    SET @params = ''@db_name nvarchar(255) OUTPUT, @vlf_count …

我创建了一个 SSIS 包，它使用文件系统任务（副本）将文件从 1 个文件夹复制到另一个文件夹。当我从本地计算机运行该包时，该包运行良好，但是当我将该包导入到我们的 SQL Server 并创建一个作业来运行该包时，该包失败并且我在日志中看到以下错误：

Started:  3:20:01 PM  
Error: 2013-03-27 15:20:01.70     
Code: 0xC002F304     
Source: copy template File System Task     
Description:
An error occurred with the following error message: 
    "Could not find a part of the path 
    'P:\IT\PROVIDERS\PROVIDERS AUDIT\File
    Template\QnxtProviderAuditList_yyyymmdd.xlsx'."  
End Error  
DTExec:
The package execution returned DTSER_FAILURE (1).  
Started:  3:20:01 PM  
Finished: 3:20:01 PM  
Elapsed:  0.452 seconds.  
The package execution failed.  The step failed.

错误中的文件路径是需要复制的文件（sourceconnection）。

我可以直接从错误中复制文件路径并在物理 SQL Server 机器上转到它（通过 Windows 资源管理器），所以我不明白为什么包说它找不到路径。

有没有人知道为什么这个包可以在我的本地机器上运行良好，但从 SQL Server 运行时却因上述错误而失败？ …

在 Windows 2008 64 位上运行的 SQL Server 2008 R2 RTM。

使用以下命令备份单个数据库时出现问题

backup database [somedatabase] 
to disk = '\\somehost\d$\BACKUP\somedirectory\some_database.bak'
with compression, init, stats=1

数据库备份了一段时间就好了

93 percent processed.
94 percent processed.

然后我收到有关磁盘空间的错误

消息 3202，级别 16，状态 1，第 1 行
写入“\somehost\d$\BACKUP\somedirectory\some_database.bak”失败：1130（没有足够的服务器存储空间来处理此命令。）
消息 3013，级别 16，状态 1，第 1 行
BACKUP DATABASE 异常终止。

这没有任何意义，因为有超过 800GB 的可用磁盘空间，而备份使用的是 121GB。

在 SQL Server 的日志中，我收到此消息

Date        9/25/2013 1:04:56 PM
Log     SQL Server (Current - 9/25/2013 12:15:00 PM)

Source      Backup

Message
BackupIoRequest::ReportIoError: write failure on backup device 
'\\somehost\d$\BACKUP\somedirectory\some_database.bak'. Operating 
system error 1130(Not …

问题 - 架构更改后完成数据库锁定

建筑学

我使用带有PostGIS的 PostgreSQL 9.3来存储位置更新。更新写入两个表 -location_updates和location_updates_history.

每个人都有：

• 一个自动递增的数字 id
• 一个文字 car_id
• geom 柱子

每次更新都会写入location_updates表，然后触发器函数会将相同的更新写入location_updates_history. 更新后，除最新的 10 个更新外，所有更新都car_id将被删除。因此，该location_update表以移动窗口的方式包含了每辆车的最新 10 次更新，并且该location_updates_history表包含了它的完整历史记录。

改变

我发现我只需要每辆车的最新更新，而不是最新的 10，所以我运行以下命令：

DROP TRIGGER location_update_insertion_trigger ON location_update;
DELETE FROM location_update WHERE id NOT IN 
            (SELECT max(id) FROM location_update GROUP BY cat_id);
ALTER TABLE location_update DROP COLUMN id CASCADE;
ALTER TABLE location_update ADD PRIMARY KEY (car_id);

锁

经过几个小时的工作，数据库处于完全锁定状态 - 非常糟糕，甚至其架构上的 pg_dump 也被阻止了。

在 …

我在 Windows Server 2016 Core 上安装了 SQL Server 2016。在本地，它似乎有效。我可以连接使用SQLCMD.exe并做一些基本的选择，什么不是。

从远程，我无法连接。使用SQLCMD.exe远程计算机上：

sqlcmd -S boldiq_db3
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Named Pipes 
    Provider: Could not open a connection to SQL Server [53]. .
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout 
    expired.
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related
    or instance-specific error has occurred while establishing a connection 
    to SQL Server. Server is not found or not …

每隔几天我的 SQL Server 实例就会意外终止并重新启动。在日志中，请参阅：

.NET Framework 公共语言运行时发生致命错误。SQL Server 正在关闭。（事件 ID 6536）。

在终止之前，我看到几条消息说：

由于内存压力，AppDomain XXX 被标记为卸载。

我有 60 个 CLR 存储过程，它们是从我的前任那里继承而来的。所有这些都应该是使用少量数据的短存储过程。如何找到导致内存压力的 CLR 存储过程？

我在跑：

Microsoft SQL Server 2016 (SP1-CU4) (KB4024305) - 13.0.4446.0 (X64) 2017 年 7 月 16 日 18:08:49   
Windows Server 2016 Standard 6.3（内部版本 14393：）（管理程序）上的标准版（64 位） 

我希望我的应用程序面向未来。最好使用的标识符类型是什么？

我正在考虑：

1. 64 位整数
2. 用户名
3. 64 个字符的 SHA256

我不是在开发分布式系统，所以需要使用 UUID 吗？

另外，INTEGER连接与VARCHAR连接有多好？

最后，将用户名（唯一）和消息数据存储在同一个 MySQL 表中是否比存储用户 ID 更好？

我在我们的一个生产数据库中有大约 40 个表，由于各种原因，这些表不是使用聚集索引创建的。

转换这些堆的最佳自动化方法是什么？

由于我天生是一名开发人员，我真的不想手动执行此操作。

我开始为此创建一个过程，如为什么此游标以不正确的顺序产生结果中所述？，然而我对那篇文章的回应让我怀疑我在做什么。

我已经使用 AlwaysON AG 很长时间了，目前在 120 个数据库和 3 个 AG 组中拥有大约 10TB 的数据，用于 SQL 2012 上的任何应用程序并取得了巨大成功。每个 AG 组在补丁级别 11.0.5058.0 上运行，主数据中心有 2 个同步副本（在不同的 SAN 上），DR 中有 1 个异步副本。迁移一直不是问题，因为没有一个数据库足够大，以至于我无法适应 SAT 早上 12 点到 4 点的维护窗口。

我的问题是，我最后一个迁移到 2012 年的应用程序包含一个 4TB TDE 加密数据库数据库，它比我之前迁移的任何应用程序大 10 倍左右。数据库在大量调优后需要 4 小时才能备份（我讨厌 TDE ！！）

由于种子增量，恢复到主副本是即时的，但问题来自必须在添加到可用性组之前备份数据库。4 小时是我的确切停电窗口，我不能再得到更多了。

我迁移应用程序的计划是 -

第一个中断窗口

1. 从 2008 年到 2012 年的主副本还原数据库

2. 将应用程序 ARECORD（或 cname 不确定是哪个）更改为主副本

3. 在单个节点上运行数据库直到下一个中​​断窗口

一周后：

1. 将数据库添加到可用性组
2. 将 ARCORD/CNAME 更改为侦听器

我不喜欢这个的地方是我整个星期都用 1 个节点而不是 3 个节点，这很令人担忧。如果其他人对如何实现这一点有任何更好的想法，我很乐意听取您的意见，或在可用性组中使用 VLDB 的人员的任何类型的评论，以及您喜欢/讨厌/喜欢这样做的地方。我正在尝试全力以赴地使用这个软件，到目前为止我一直很喜欢它，但在涉及到 VLDB 迁移时却很担心。

我是一名 DBA，对从 UNIX/Informix 转过来的 SQL Server 相当陌生。

我有一个关于 tempdb 增长的问题：

从我在常规数据库上看到的情况来看，如果我从一个 10 GB 的数据库开始，然后将一堆数据放入其中以使其成为 100 GB，然后从中删除 50 GB 我必须执行收缩才能回收硬盘上的空间。直到我将空间分配给数据库

tempdb 是如何工作的？

如果初始大小为 10 GB，然后某个查询将 tempdb 增长到 100 GB，然后终止，该空间是否可用于未来的 tempdb 查询/临时表等......？

或者它是否将空间释放给操作系统？