标签: backup

有没有办法制作一个 mysqldump 来保存指定数据库中的所有触发器和过程？

前段时间我读到这mysqldump也将保存我的触发器，但它看起来不像。我的第二个相关问题是如果触发器存在，我如何检入 sql 文件？

我正在尝试备份我的整个数据库以及视图。我将使用mysqldump命令。我想知道这是否会复制所有视图，或者我将不得不使用单独的命令。

请给我一个答案。任何帮助是极大的赞赏。

我有点像一个新的 DBA，我正在管理一个具有大量活动的 SQL Server 2012 实例。我在完全恢复模式下运行，因为我们需要时间点恢复。

现在，我每天凌晨 5 点对数据库和日志进行完整备份。一些日志文件已经膨胀到 300gb，即使在进行备份后，它们的大小也不会减小。我可以通过运行类似于以下内容的内容来减小它们的大小：

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

当我检查备份文件的 LSN 时，我看到如下内容：

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

我不相信我通过缩小日志文件来破坏我的日志链。读到这里，我确实相信我正在损害我的性能，因为那些缩小的日志文件必须重新增长自己。

问题：

1. 为什么备份后日志文件没有缩小？是因为有未提交的事务吗？
2. 起初我想我应该在每 5:00 AM 备份后缩小日志文件。在阅读了这对性能的影响之后，我现在相信我需要在白天每隔几个小时进行一次定期的日志备份。那是对的吗？ …

今天，我试图在现有数据库上恢复数据库，我只需在 SSMS --> 任务 --> 脱机中右键单击该数据库，以便我可以恢复数据库。

一个小的弹出窗口出现并显示Query Executing.....了一段时间，然后抛出一个错误说Database is in use cannot take it offline。我从中收集了一些与该数据库的活动连接，因此我尝试执行以下查询

USE master
GO
ALTER DATABASE My_DatabaseName
SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

再次在这一点上 SSMS 显示Query Executing.....了一段时间，然后抛出以下错误：

Msg 5061, Level 16, State 1, Line 1
ALTER DATABASE failed because a lock could not be placed on database 'My_DatabaseName'. Try again later.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.

在此之后，我无法通过 SSMS 连接到数据库。当我尝试使用 SSMS 将其离线时，它抛出了一个错误：

Database is …

我已经开始对 2012 SQL Server 上的各种活动进行一些长期跟踪，我注意到在增量备份期间批量请求有所增加。

举个例子，正常的日常我们大约每秒 10-20 个批处理请求，但在我们的差异备份运行期间，它跃升至每秒 100-130 个。

我知道这不是很多，但它让我好奇它增加了 10 倍是怎么回事。

不确定您可能需要哪些信息来帮助解决此问题。

我使用的是 SQL Server 2014，情况是这样的：

• 我有服务器 A 和服务器 B。
• 在服务器 A 上处理隔夜 ETL。
• 加载过程完成后，数据库 X 得到备份（使用CHECKSUM和RESTORE VERIFYONLY以确保可靠性），然后发送到服务器 B。
• 服务器 B 接收bak文件，然后在那里恢复数据库。

我想使用差异备份策略，以便：

1. 完整备份仅在星期六进行，
   即星期六在服务器 A 上进行完整备份 -> 运送到服务器 B -> 在服务器 B 上恢复完整备份

2. 剩下的日子将是差异备份，
   即服务器 A 上的差异备份 -> 运送到服务器 B -> 在服务器 B 上恢复差异备份

我试过了，但出现错误，说：

无法恢复日志或差异备份，因为没有文件准备好前滚。

不知道为什么。我检查sys.database_files了服务器 A 和服务器 B，我可以看到differential_Base_LSN和differential_base_GUID是相同的。任何地方/还有什么要检查的吗？

顺便说一下，在上面的第 2 步中，当我在服务器 B 上恢复差异备份时，是否每次都需要同时恢复完整备份 + 差异备份？

我只恢复了差异备份WITH RECOVERY（并收到了错误消息），因为前一天已经恢复了完整备份。

澄清一下：是的，我希望服务器 B 上的数据库在差异之间可读。我怎样才能解决这个问题？是我每晚RESTORE FULL (WITH NORECOVERY)+ …

我正在尝试将 mongodb 数据库备份/恢复到 .gz 文件作为示例脚本here

#01 create .gz backup - ok for r3.2.9 and r3.4.10 
mongodump --db ${DB_NAME} --gzip --archive=${BACKUP_FILE_GZ}

#02 restore from .gz file - NOT ok for r3.2.9
mongorestore --gzip --archive=${BACKUP_FILE_GZ} --nsFrom "${DB_NAME}.*" --nsTo "${DB_NAME_RESTORE}.*"

步骤 01 即备份对 mongodb 版本r3.2.9和r3.4.10; 虽然步骤 02 不适用于r3.2.9

如何从 .gz 文件中获取mongorestore版本r3.2.9并能够重命名数据库？

ps

我们在这里有解决方案，但这需要备份是一个文件夹；我的备份文件很大，即 1Gb-2Gb，所以提取太耗时了。

如果我从 SQL Server 2016 实例备份数据库，然后将其还原到 2017 实例以对其进行一些工作。

然后我可以从 2017 年实例中转身并备份该数据库，并使用它来覆盖 2016 年实例上的原始版本吗？

Oracle® 数据库备份和恢复基础知识 10g 第 2 版 (10.2) 说

归档重做日志是成功恢复媒体的关键。定期备份它们。

但是，我想知道为什么存档日志的备份如此重要。是否可以仅使用常规 RMAN 完整和增量数据文件备份进行时间点恢复。

我有一个托管在 SQL Azure 实例上的 OLTP 数据库。我想从云中提取数据库的副本，以便我可以对其运行一些大量提取和 OLAP 样式的查询，而不会影响源数据库。

如何将数据库的副本下拉到本地 SQL Server 实例？