我们有一个 ETL 过程，它将大量数据插入到表中。该数据库设置为简单恢复模型，并且事务日志增长很多。我在想将这个数据库设置为批量日志恢复模型会有帮助吗？我们每天都会进行完整备份。那么，与简单恢复模型相比，批量日志恢复模型中是否存在一些未记录的操作？
我有这个简单的脚本来备份 postgres 中的所有数据库
pg_dumpall -U pg_user > /tmp/tmp.txt
DUMP_STATUS=$?
echo "Dump status: $DUMP_STATUS" > /tmp/status.txt
从命令行执行脚本时，转储状态为 0，并且正确创建了 tmp.txt 文件。
但是，如果我在 crontab 中将该脚本作为 cronjob 执行，则我的 tmp.txt 为空（所有数据库的转储失败），并且我的 status.txt 文件包含转储状态 127。
我注意到的一个奇怪的行为是 pg_dumpall 会将信息通过管道传输到文件中，但也会将其打印在终端上。我认为这种行为可能是问题的原因。
知道如何解决这个问题吗？
我正在运行 FreeBSD：
> uname -mrs
FreeBSD 9.1-PRERELEASE amd64
> psql -V
psql (PostgreSQL) 9.1.7
contains support for command-line editing
背景：
我正在尝试创建一个仅包含数据库中的数据的转储文件。我希望它使用 INSERT 命令创建数据。在阅读手册时，（http://www.postgresql.org/docs/9.2/static/app-pgdump.html#PG-DUMP-EXAMPLES）我发现我可以使用
从手册中并不清楚有什么区别。所以我尝试了两者并对文件进行了比较。存在差异，我想知道为什么。有人能告诉我这两个命令有什么区别吗？
这是我正在运行的完整命令：
pg_dump -a --column-inserts -U postgres testdb > /tmp/test_data_as_inserts2.sql
和 ：
pg_dump -a --attribute-inserts -U postgres testdb > /tmp/test_data_as_inserts.sql
任何提示将不胜感激。与此同时，我将深入研究这两个文件之间的区别……为什么某些记录被包含而另一些则不被包含。
谢谢。
我有几个数据库想要转移到完整恢复模式，这样我们就可以拥有时间点恢复功能。我们不需要在所有数据库上使用它，只需要在事务量大且包含不断更新的数据的数据库上使用它。
我做了很多研究，并且完全理解当您切换到完全恢复时会发生什么，特别是它与日志文件的关系。
我正在寻找的是一些建议或“陷阱”，这些建议或“陷阱”可能是由于将某些恢复模式切换为完整恢复模式而出现的。
现在，我计划一次执行一个数据库，这样我就可以监视日志文件的增长并确定日志文件备份的最佳频率，以确保我们不会陷入日志文件失控的情况。我还知道，一旦我们切换到完整恢复，我就需要对该数据库运行完整备份。（我知道在我们这样做之前，完整模式不会真正启用）。
我的计划还包括每周运行一次完整备份，擦除上周的日志文件，本质上是“重新开始”。
还有其他有帮助的注意事项或建议吗？有什么我应该注意的吗？我们也每周运行一次完整索引重建、DBCC CHECKDB 和统计重建。这些操作是否存在任何潜在问题（也许在该时间段内切换到 BULK_LOGGED 以免破坏日志文件？）
感谢你的帮助！
我的理解是所有备份都包含到备份操作完成的时间/点的数据。
管理 SQL 数据库基础结构 - 考试参考书 70-764说：
完整：这包含数据库的全部内容以及在备份操作期间对数据库所做的任何更改。因此，完整备份表示备份操作完成时的数据库。
（强调我的）
然而，对于差异备份，本书暗示了一些不同的东西：
差异：这仅包含上次完整数据库备份与执行差异备份操作的时间点之间的差异。
这样对吗？或者这只是不精确的语言？这里的“执行”是指差异备份开始或完成的时间吗？
对于其他备份类型（日志、部分、文件备份），本书并没有完全说明这一点？
这里有一个问题，我需要一些帮助来解决。
托管一个数据库，大约 400Gigs。这让我们有点头疼让它与托管备份到 Azure 存储容器一起工作。
这是我们得到的错误
10/21/2018 12:45:18,spid149,Unknown,Write to backup block blob device https://NAME.blob.core.windows.net/CONTAINER/DB_NAME_20181021120709+02.bak failed. Device has reached its limit of allowed blocks.
设置完成
EXEC managed_backup.sp_backup_config_basic
@database_name = 'DB_NAME',
@enable_backup=1,
@container_url = 'https://NAME.blob.core.windows.net/CONTAINER',
@retention_days=30;
USE msdb;
GO
EXEC managed_backup.sp_backup_config_schedule
@database_name = 'DB_NAME'
,@scheduling_option = 'Custom'
,@full_backup_freq_type = 'Daily'
,@backup_begin_time = '00:30'
,@backup_duration = '02:00'
,@log_backup_freq = '00:05'
GO
并且日志备份运行良好，所以我们知道凭证没问题。但是它不会备份数据库，因为它太大了，所以需要拆分。但是怎么做呢？当我像这样运行手动备份时
Use MSDB
Go
EXEC managed_backup.sp_backup_on_demand
@database_name = 'DB_NAME'
,@type = 'Database'
它确实在 Azure 容器中将其分成两部分。那么我如何获得拆分 BAK 文件的自动作业。
我们在 SQL Server 2017 上运行。 …
我在我的 SQL 服务器上创建了 5 个维护计划（比如 50 个！），每天生成 5 次数据库备份。正如我在此 Q/A 中读到的那样，当我需要时间点恢复时，完全恢复是很好的。
我的确切问题：是否使用简单的恢复模型生成多个每日备份，类似于较长时间的完整恢复备份？
我想我已经知道答案了，但我还是会问。
情况是：
如果我尝试恢复这些并创建一个 AG - 它会失败。在我重新创建 AG 之前，我需要进行另一个完整的 Db 备份 = 另一个 6 小时。
所以 COPY ONLY 备份是没有用的。除非我错过了什么？这些有什么意义？
您能否对 SQL 服务器备份消息稍作说明
例如 ：
BACKUP DATABASE 在 1945.648 秒（79.088 MB/秒）内成功处理了 19696388 页。
例如，我们有一个带数据库的磁盘，我们有单独的磁盘用于备份，这是否意味着 79 MB/秒是一个磁盘以 40 mb/秒的速度读取数据进行备份，另一个磁盘以 40 mb 的速度写入数据，总和它给了我们 79 mb/sec 的速度，对吗？
我很确定我知道这个问题的答案，但时间点恢复的局限性让我大吃一惊。
假设我有一个 2TB 的数据库设置为FULL恢复模式。我认真地每 30 分钟进行一次每周完整备份、每日差异备份和日志备份。
现在，我想将数据库回滚到 1 小时前。我真的必须在一小时前恢复整个完整备份、差异和日志吗？我是否正确地认为这将需要很长时间？
有没有办法ROLLBACK使用事务日志文件进行更改，以便这种类型的恢复需要几分钟？