小编Tho*_*ser的帖子

在 SQL Server（在本例中为 2008）中，如何快速缩小实例上所有数据库的所有文件，包括日志和数据？我可以通过 SSMS 并右键单击每个并选择任务 -> 收缩，但我正在寻找更快的东西。

我编写了一些“创建数据库”脚本，但忘记了它们的默认值已经膨胀，并且不需要为该项目中的这些文件保留太多空间。

我们每天通过 WAN 运送我们的 SQL Server 备份。我们需要最小化这些备份的大小，这样它就不会花很长时间。

我们不介意我们的备份过程是否需要更长的时间；目前，我们需要在 WAN 上移动 30gigs 的压缩备份，这需要 10 多个小时。

我们有两种选择来获得较小的每日备份。

1. 日志传送，这意味着我们必须重构 DR 流程。
2. 从数据库中剥离信息并在另一侧重建（删除非聚集索引，100% 打包聚集索引 - 在另一侧重建）

两者都涉及我们的大量工作。我们使用的是 SQL Server 2008 pro，所有备份都是压缩的。

是否有任何商业产品可以为我们提供与选项 (2) 类似的备份大小？

是否有一个全面的脚本可以让我们完成（2）？（处理索引视图、过滤索引、外键等）

我的许多数据库都有定义为 varchars 的字段。自从我在美国生活和工作以来，这并不是什么大问题（那里唯一存在的语言是“美国”。咳咳）

在使用数据库大约 5 年后，我发现我最终遇到了 varchar 字段的有限性质的问题，我必须修改我的字段以将数据存储为 nvarchars。在不得不对表进行另一次更新，将 varchar 字段转换为 nvarchar 之后，我有了一个想法——为什么我们仍然这样做？我早就决定将所有新的文本字段定义为 nvarchar，而不是 varchar，这是我 10 年前在学校时从教科书中学到的。

现在是 2011 年，去年发布了新版本的 SQL Server。当我们可以/应该使用 nvarchar 时，为什么我们继续支持 varchar 数据类型？

我知道经常有人争论 nvarchars 是 varchars 的“两倍大”，因此存储空间的使用可能是维护 varcars 的一个争论点。

但是，今天的用户如果想节省存储空间，可以定义他们的 nvarchars 以将数据存储为 UTF-8 而不是默认的 UTF-16。如果主要需要，这将允许 8 位编码，同时保证插入到他们的数据库中的稀有 2-8 字节字符不会破坏任何东西。

我错过了什么吗？在过去的 15 到 20 年里，这是否有充分的理由没有改变？

我在 Windows 服务器上的 SQL Server 2008 上有一个数据库，我想将所有数据移动到 Ubuntu 服务器上的 MySQL 数据库。我尝试将 SQL Server 导入和导出向导与 MySQL ODBC 驱动程序一起使用，它可以正确访问两个数据库，但包含类型转换规范的 xml 文件不存在，而且规范太有限，我无法正确创建它们。有谁知道如何创建类型转换文件或从哪里获得更好的工具来传输这些数据？

当我们即将更改 5TB 数据库中的一些大表时，我发现自己需要一份可以在线执行的操作列表，这些操作需要在运行时保持全锁。理想情况下，该列表还包含有关哪些语句需要 SCH-M 锁在最后提交的信息。

虽然我在 Microsoft 的时候就认识了其中的大部分，但我很惊讶我找不到公开可用的在线操作列表，因为它们从 SQL Server 2005 一直发展到 2014 CTP。

有人有这样的清单吗？如果没有，我可能会决定创建它。

我们有一个周期性事件，其中许多连接挂在 TM REQUEST（来自sys.dm_os_waiting_tasks）上并且没有任何进展。KILL对受影响的session_id人什么都不做

服务器运行数据库镜像 (2008R2)。暂停和恢复镜像可在问题发生时修复该问题。

陷入这种状态的会话是不可杀死的。镜子上的负载是平常的，而不是突发的。一旦大量连接卡在这种状态，系统就会冻结并且镜像停止复制（所有查询都被阻止）。

有没有人见过这个并知道是什么原因造成的？错误日志中没有任何内容。