我有一个包含很多模式的数据库，我想将每个表内容转储到 CSV。我知道 COPY 命令，但我不确定如何编写一些脚本来读取模式中的所有表并针对它们执行 COPY。

我客户的 SQL 服务器上有很多数据库。这些数据库正在开发中，因此开发人员可以进行设计、重构、数据修改等。有一些数据库很少更改。我的客户必须确保所有这些都安全（备份）并花一些时间管理环境。（公司没有DB管理员职位。）经过长时间的讨论，客户决定使用每日完整备份策略，因为恢复容易。

所以这里是情况的总结：

• 数据库的数量每天都在变化。
• 应备份已更改的数据库（意味着数据和/或结构已更改）。
• 未更改的数据库不得备份。
• 解决方案不应影响数据库结构（不受限制的要求）
• 这个“备份引擎”应自动工作。

主要问题：如何检测数据库已更改。问题的第一部分（DDL 更改）可以通过使用DDL 触发器来解决。但是数据更改（DML 更改）是一个问题。不可能将 DML 触发器应用于所有数据库的所有表以跟踪更改（性能、扩展对象的管理......）。备份引擎必须跟踪所有更改以将每个数据库标记为准备备份。

• Change Data Capture是一个解决方案，但它似乎太重了（它还需要 SQL Server 企业版）。

• 另一种方法是跟踪数据库文件更改（大小或上次更改时间），但它无法正常工作：当数据库超过所有保留的可用空间时，它可以更改其大小，而sp_spaceused不是解决方案。

• 跟踪是一种解决方案，但它会导致性能问题并需要额外的管理。

是否有任何解决方案可以在不影响其他数据库管理对象（如统计信息..）的情况下计算实际数据库使用大小？当然，对不改变表大小的表数据的更改不会触发（我认为），但总比没有好。我真的在寻找 SQL Server 2008 的直接或间接解决方案。

感谢您的任何评论、解决方案和想法。

添加：

这是解决方案（感谢玛丽安）：

Select
    NextLSN = MAX(fn.[Current LSN])
    ,Databasename = DB_NAME()
 from fn_dblog(NULL,    NULL) fn
     LEFT JOIN sys.allocation_units au
         ON fn.AllocUnitId = au.allocation_unit_id
     LEFT  JOIN sys.partitions p
         ON p.partition_id = au.container_id
     LEFT  JOIN sys.objects so
         ON so.object_id = p.object_id  
    WHERE 
    (
        (Operation …

我需要将数据库（作为一个整体）传输到另一台服务器，以制作一个重复的数据库来设置另一个测试环境。

我有两个选择：

1. 在源服务器上进行完整备份/在目标服务器上进行还原；
2. 在源服务器上分离/在目标服务器上附加。

根据我的要求，这两种解决方案的优缺点是什么？

我正在使用 SQL Server 2008 企业版。

我需要备份 10-20 个大小在 10-50 GB 之间的 SQL Server 2008 R2 数据库，同时它们在线并由单个企业应用程序同时使用。我还需要将它们恢复到在所有数据库之间基本同步的状态（我可以承受数据库之间长达几秒钟的不同步）。目的是为 QA​​/DEV 环境捕获生产数据。

我强烈希望不要求数据库在完全恢复中运行，并提出一种备份方法，该方法专用于为 QA 环境捕获数据，并保持独立于不受我控制的主备份过程。

对于我的客户，捕获 20 个完整备份（每个约 30 GB）需要 1-2 小时。这使得按顺序进行完整备份是不可接受的，因为在简单恢复中运行时数据库会过于不同步。

我正在寻找比这些更好的想法：

想法 1：虚拟机磁盘的 SAN 级快照。从快照 xcopy MDF/LDF。

一旦复制的文件附加到不同的服务器实例，其恢复过程应该生成几乎同时快照的一致数据库。
谷歌搜索使我确信这是一个坏主意，至少因为我可能会与 master/msdb/etc 不同步。

IDEA 2：在所有数据库中编排复杂的备份和同步还原

这要求我要求以完全恢复运行的数据库，这是我不想要的。在截止日期 (T0) 之前为所有数据库启动并行备份。到达 T0 后，备份所有日志（最多需要几分钟）。获取由此产生的无数备份并尝试恢复它们并向前/向后滚动日志，以获得相对于 T0 的跨数据库某种程度的一致状态。
这需要大量的计划和脚本才能可靠地使用它，所以我会竭尽全力避免它。

我是否缺少其他解决方案？

PS1：我希望能够使用db snapshots。这个想法是在每个数据库上启动一个快照（应该在几秒钟内结束），然后在接下来的几分钟/几小时内按顺序完全备份每个。然后在不同的服务器上恢复所有这些并将每个恢复到快照。AFAIK 这种情况是不可能的，因为快照不能与数据库一起备份。它们只能在创建它们的服务器上就地回滚。此外，他们需要企业版，我没有为所有客户提供。

PS2：如果您知道能够生成跨数据库同步备份的 3rd 方解决方案，请提及它。

我们碰巧使用的是 SQL Server 2012 标准版。我还碰巧使用了 Ola Hallengren 的脚本来提供一个简单、更灵活的框架来进行备份和维护。

这个问题不是关于 Ola 的脚本，而是关于最佳实践。我意识到最终的答案是“这取决于贵公司的要求”。但我正在尝试就如何最好地满足我对公司要求的理解寻求社区的建议。

我希望每 15 分钟设置一次事务日志备份。这样我们希望丢失不超过 15 分钟的数据。我应该设置一项使用 ALL_DATABASES 的作业吗？还是为每个数据库设置一项工作并并行启动它们更好？我问，因为根据我如何看待 Ola 的脚本功能，我有一种感觉，即备份是串行启动的。串行的缺点是每个连续的备份都等待另一个完成。这可能会增加备份之间的时间量（即大于 15 分钟）。另外，我担心一个备份的失败会阻止其他备份的发生，我不希望出现这种情况。我希望其他人继续备份。

那么，Ola 的脚本是串行执行的，而且故障也会停止连续备份吗？

每个数据库都有一份工作是不是更好？还是做所有事情的单一工作？我倾向于单独的工作，但我希望了解 SQL Server DBA 通常倾向于做什么。

我希望在我的生产环境中部署日志传送。这意味着我将不得不管理备份链，这些备份链可能会被人们进行备份以刷新开发环境而中断。如果我遇到故障并想使用日志备份恢复到某个时间点，我还需要开发人员进行备份。

如果开发人员仅使用 COPY ONLY 备份，则不会发生这种情况。所以我的问题是：有没有办法限制用户只能执行 COPY ONLY 备份？

为什么我的还原操作不起作用？

我使用以下方法为数据库创建了一个转储文件：

mysqldump -u root -p databasename > /home/databasename_bkup.sql  

然后我打开了 dumfile 并确认它包含CREATE TABLE数据库中每个表的语句。因此，在运行以下恢复命令之前，我删除了数据库并重新创建了一个同名的空数据库：

mysqldump -u root -p databasename < /home/databasename_bkup.sql  

此恢复命令导致在终端中打印以下内容：

-- MySQL dump 10.13  Distrib 5.6.23, for Linux (x86_64)
--
-- Host: localhost    Database: databasename
-- ------------------------------------------------------
-- Server version   5.6.23

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 …

对于 MySQL，我知道数据库是在 SQL 语句中逐表备份的，这会导致锁定，如果在备份时更新列，则最终可能会出现完整性问题。

据我了解，这不适用于 Microsoft SQL Server，但 SQL Server 是如何处理的？是否有一些内部冻结来保持数据库一致？

我还听说备份是单线程的，这意味着它只使用一个核心，假设您备份到单个文件。还假设您有一台多核机器，例如 16 核，或者至少比 1 多得多。

根据我的个人经验，我在备份时从未遇到过问题，既没有锁定也没有开销问题，但我的经验有限。这就是为什么我总是建议在服务器属性中打开备份压缩。

那么当备份作业正在运行时会发生什么？不同版本是否也有显着差异？例如 2008、2012 和 2014（不是许可证）。

假设我正在运行日志备份，并且该日志备份需要 10 分钟才能完成。在这 10 分钟的窗口中，将运行进一步的事务。鉴于以下示例，日志备份实际上包含哪些事务？

1. 事务 A 提交
2. 事务 B 打开
3. 日志备份开始
4. 交易 C 开启
5. 事务 B 提交
6. 日志备份完成
7. 事务 C 提交

我尝试将数据库从本地计算机 v15 (2019) 上的 Sql Server 克隆到服务器计算机 v14(2017)。我做了一个 .bak 文件，当我尝试在服务器端导入时，它显示：

System.Data.SqlClient.SqlError：数据库已在运行版本 15.00.4083 的服务器上备份。该版本与运行版本 14.00.2037 的服务器不兼容。在支持备份的服务器上还原数据库，或使用与该服务器兼容的备份。(Microsoft.SqlServer.SmoExtended)

14-15 Sql Server 版本是否有“兼容”备份模式？

本地（在 docker、Linux 上）：

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) 2020 年 11 月 2 日 18:35:09 版权所有 (C) 2019 Microsoft Corporation Developer Edition（64 位）Linux (Ubuntu 18.04.5)长期支持）

远程（在 Windows Server 上）

Microsoft SQL Server 2017 (RTM-GDR) (KB4583456) - 14.0.2037.2 (X64)
2020 年 11 月 2 日 19:19:59 版权所有 (C) 2017 Microsoft Corporation 标准版（64 位），位于 Windows Server 2019 Standard 10.0（内部版本 …