标签: backup

以下问题与 Microsoft SQL Server 事务日志传送 (TLS) 有关。

我们使用的是 SQL Server 2008 R2 SP1，尽管这个问题可能与所有最新版本有关。

背景

我有一个主数据中心 (A) 和一个辅助的灾难恢复数据中心 (B)。假设我有 64 个数据库需要进行不同大小的日志传送，但没有一个数据库超过 50GB。

我目前正在使用 SQL Server 自动创建的默认 SQL 代理作业，因此我有 64 个 SQL 代理作业。

我想每 15 分钟记录一次每个数据库。假设如果我只是背对背传输所有文件，那是可能的。

问题

假设从 A 到 B 的路径通过公共 Internet 传输，因此我要为传输这些日志的带宽付费。我在第95 个百分位计量。我想平滑或优化带宽，以尽量减少支付超额的机会。我正在使用备份压缩。

可能的解决方案

我目前的想法是编写一个脚本，该脚本将自动自定义每个备份作业的开始时间。该脚本可以根据需要频繁运行以保持最佳传输。让它定期运行将使新添加的数据库的新日志传送备份作业能够在无需人工干预的情况下进行优化。

当前的 SQL 代理作业都以字符串“LSBackup”开头，因此我可以使用以下方法列出它们：

SELECT * FROM msdb..sysschedules WHERE name LIKE 'LSBackup%'

我可以获取所有 SQL 代理作业的列表并将它们存储在表变量中，然后在WHILE循环调用中迭代以适当EXEC msdb.dbo.sp_update_schedule地更新@active_start_time作业的空间。

我应该为每个作业的开始时间使用什么值？

为了回答这个问题，我需要知道日志备份文件可能有多大，以便最佳地分配作业。在运行备份之前，您能预测事务日志备份的大小吗？或者，我可以查看本地文件系统上过去几天的日志备份，以确定每个数据库的相对权重。然而，对于几乎没有事务日志备份历史的全新数据库来说，这并不真正有效。

假设可以确定每个备份的相对大小，那么在第 95 个百分位计量时将它们隔开以实现最小带宽影响的最佳算法是什么？

我正在对 SQL Server 数据库进行每日备份。现在该.bak文件大约为 2GB，并且每天都在增长。有一个计划的作业正在运行，它移动了这个.bak文件从一个位置到另一个位置。

有没有办法以.bak块的形式保存文件 - 比如part1.bak，part2.bak等等。

所以移动小数据并在目的地合并会容易得多？

我在我的 postgresql 配置上打开了 archive_mode 以测试备份服务器。由于 wal 文件占用了大量磁盘空间，因此在测试后我将其关闭并删除了 wal 文件。当我尝试重新启动 postgresql 时，出现以下错误。

 root@hooshang:/etc/postgresql/9.1/main# /etc/init.d/postgresql restart
 * Restarting PostgreSQL 9.1 database server
 * The PostgreSQL server failed to start. Please check the log output:
 2014-10-16 13:15:28 IRST LOG:  database system was shut down at 2014-10-15 15:51:53 IRST
 2014-10-16 13:15:28 IRST LOG:  could not open file "pg_xlog/00000001000007DC00000037" (log file 2012, segment 55): No such file or directory
 2014-10-16 13:15:28 IRST LOG:  invalid primary checkpoint record
 2014-10-16 13:15:28 IRST LOG:  could not open file …

有人告诉我，可以使用 rsync 即时备份数据库。我认为这是可能的，但不安全，因为一些日志、缓冲区......没有被刷新。正在从备份中恢复的数据库会不一致。

实际上我不确定为什么使用 rsync 备份不安全。任何人都可以向我解释 mysql 的原因吗？

我在 Amazon RDS 实例上有一个 PostgreSQL 数据库。

我想要这个实例的本地转储。

到目前为止，我已经尝试过：

PGPASSWORD="Password" pg_dump -h mydb.xxxxxx.us-east-1.rds.amazonaws.com -p 5432

但它不断抛出错误，说服务器拒绝连接，并检查服务器是否实际上在 port 上运行5432，这实际上是在做。

我所有的凭据和数据库路径/代码都是正确的。

我正在运行 MS SQL Server，它分别保存了 110 GB 和 245 GB 的 mdf 和 ldf 文件。

我的问题是，如果我对所述数据库进行 .bak 备份，它会产生 355 GB (110+245) 大小的备份文件，还是只包含 mdf 备份？

我需要知道这一点，因为我的硬盘上没有这么多空间。

我使用的是 SQL 2008 R2 标准版

我试图在服务器版本中备份 common_schema: 5.5.44 MySQL Community Server (GPL)。

mysqldump -u root -p common_schema > common_schema_bkup.sql

我收到以下错误：

“mysqldump：得到错误：1356：视图'common_schema._bare_grantee_grants'引用无效的表或列或函数或视图的定义者/调用者在使用锁定表时缺乏使用它们的权利”

我该如何纠正？

我正在使用 SQL Server 2012 SP2 使用BACKUP TO URL语句将我的事务日志直接备份到 Azure Blob 存储中。

然后我尝试验证我的交易日志，如下所示：

RESTORE VERIFYONLY FROM  URL = 'https://mystore.blob.core.windows.net/logfile.trn'
WITH CREDENTIAL = 'azurecreds'

该RESTORE VERIFYONLY操作对 Azure 中的文件进行了租借，我可以使用 Azure Management Studio 的 blob 浏览器查看该文件（我创建的最后 2 个文件没有运行 RESTORE VERIFYONLY）。

我可以使用 Azure Management Studio 手动中断租约，但我是否做错了RESTORE VERIFYONLY在文件上留下活动租约的问题？

我被聘来填补一个我还没有准备好填补的 DBA 职位，虽然培训让我到达那里，但我正在接近一个潜在的问题。

我的 oracle 11g 数据库的闪回恢复区 (FRA) 快要满了（还剩 2.5%）。它处于 ARCHIVELOG 模式，因为我们进行实时备份（至少这是我被告知的原因）。我们已经通过企业管理器清除了所有不需要的备份，但存档日志仍然占用超过 50% 的已分配 FRA 空间。是否可以删除一些较旧的存档日志以释放空间？服务器仍然保存几个月前的日志，我们真的不需要那么远的备份。

如果我可以删除它们，最好的方法是什么？

我有一个 SQL SERVER DB，我想通过自动计划（使用 GUI 维护计划）进行备份。配置时间表时，我有 2 个选择：

1) 不用担心日志备份、完整备份和差异 bakcup 事件时间，就好像所有 3 个备份同时发生一样，没有区别。

2) 仔细配置每次备份的时间，确保日志备份、全量备份和差异备份不会同时发生。

下面是描述 2 个选择的图像（选择 1 的 Schedule1 和选择 2 的 chedule2）

你知道哪一个是最好的吗？

编辑：当备份重叠时，Sechdule1 可能会遇到一些错误。这里备份的类型是日志和差异 hapening，同时在 5:30 作为备份，无论类型是什么，都将附加到现有备份文件中。所以该文件正被日志备份使用，而差异失败。即使没有数据丢失。