我用来sys.fn_hadr_backup_is_preferred_replica查询每个可用性组副本上的数据库,以确定是否应该在该副本上备份数据库 - 然后,如果该函数返回 true,则检查msdb.dbo.backupset数据库最近是否已备份。
我遇到的问题是该函数需要很长时间才能运行(每个数据库大约 3 秒) - 谁能推荐一个更快的替代方案?
为了回应下面的评论,我目前使用的是 SQL 2012 SP1 (11.0.3000.0) - 但是,我正在创建的查询需要针对多个客户站点上 SQL Server 2012 的多个不同安装,因此,即使这个系统功能在后续的更新中得到了改进,遗憾的是我可能无法强迫人们更新。
如何向 ola.hallengren 备份脚本添加加密。
简而言之我想实现这个目标
BACKUP DATABASE [MyTestDB]
TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\MyTestDB.bak'
WITH
COMPRESSION,
ENCRYPTION
(
ALGORITHM = AES_256,
SERVER CERTIFICATE = MyTestDBBackupEncryptCert
),
STATS = 10
Go
Run Code Online (Sandbox Code Playgroud) 我通过 SAN 磁盘工具配置了数据库备份。在备份集表中,我可以看到 VSS 编写器服务正在进行快照类型的完整备份。
服务器上有85个数据库。
我了解数据库快照的概念,最初它的大小为 0。当源数据库更新时,它将更改推送到快照,从而增加快照大小。
我想问是否:
数据库快照和VSS数据库快照备份(通过VSS writer服务)是同一个概念吗?
对于数据库快照和 vss 数据库快照备份 - 假设有 85 个项目(快照/快照备份),那么这将导致 sql server 上的整体 IO 较差,因为它必须定期维护(随着源数据库发生更改而更新)快照85 个数据库?
假设我在凌晨 12 点进行完整备份。然后每小时记录一次备份。
然后假设在晚上 8.30 我进行手动日志备份(从而截断日志)并删除该文件。这样后续晚上9点的日志备份就会有不完整的日志。
因此,从晚上 8 点到凌晨 12 点的时间点恢复数据是不可能的。
现在中午 12 点将进行另一次完整备份。随后像往常一样每小时进行一次日志备份。现在假设下午 4.30 发生崩溃。
在此完整备份之前进行的手动日志备份是否会使完整备份后的正常日志备份变得无用?或者只有上次手动日志备份到上次完整备份的日志没有用?
我需要使用 Python 程序在 MySQL 服务器中创建数据库的副本。
经过一番研究,我发现 mysqldump 是更好的方法:
import subprocess
command_to_copy_db = f"mysqldump -h {SQL_DB_HOST} -P 3306 -u {SQL_DB_USER} -p{SQL_DB_PASSWORD} {src_database_name} | mysql -u root -p{SQL_DB_PASSWORD} {dest_database_name}"
backup_db_command_result = subprocess.run(command_to_copy_db, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
shell=True, text=True)
Run Code Online (Sandbox Code Playgroud)
我的查询:
这种方法有什么问题吗?或者有没有更好的方法来做到这一点?
我们有多个可用性组,每个可用性组都混合有大型数据库和小型数据库,所有这些都至关重要。它们都是异步提交,因为它们的辅助数据中心位于不同的数据中心,虽然我们希望快速恢复/故障转移,但一些数据丢失是可以接受的。
我们在两个节点+文件共享见证集群中的一些节点上遇到了问题,其中集群由于某种未知原因脱机,导致每个 AG 数据库都脱机。主节点本身没有问题,因此主节点上的其他非 AG 数据库仍然可用。一些最关键的数据库很小(<100GB),所以我想我们可能希望将它们从 AG 中取出并让它们成为普通数据库,这样集群问题不会影响它。我们会将其日志备份计划更改为 5 分钟之类的时间,以最大限度地减少恢复点目标 (rpo),并将任何恢复作为从备份进行的正常恢复来处理。
AG 在工作时表现出色,但在不工作时则需要排除故障并重新上线。对这个设计有什么想法吗?谢谢!
我们的一位同事告诉我,他们正在为 SQL Server 进行“冷”备份,以便他们关闭服务,然后以某种方式进行备份。我认为这一切都错了!我对吗?我认为他们应该在他们的数据库处于 FULL 模式时进行完整备份、差异备份和日志备份。
他们在备份后启动 SQL Server 服务时也遇到问题,他们找不到 .mdf 文件。你知道为什么这会发生在他们身上吗?
我们有一个带有 SP4、x86 的 SQL Server 2005。当我们尝试进行差异备份时,我们收到以下错误消息。
无法对数据库“ABCD”执行差异备份,因为当前的数据库备份不存在。通过重新发出 BACKUP DATABASE 执行完整的数据库备份,省略 WITH DIFFERENTIAL 选项。[SQLSTATE 42000](错误 3035)BACKUP DATABASE 异常终止。
对解决此问题的任何帮助表示赞赏
如果您想避免数据库中毒(即想快速恢复到某个时间点),您更喜欢哪种方法?
让我定义数据中毒。您在数据库中插入了一些东西,这完全弄乱了内部结构和相互依赖关系。我知道这意味着可能还需要重新审视数据库设计,但损害已经造成。
我想到的方法是
如果第一个选项是可能的,并且它还存储了所有的中继日志(即在 Master 上发生的事情在同一时刻传输到 Slave,但在几个小时内自动应用),那么这将是一个完美的解决方案。也许可以在一个设置中设置多个从站以从中断和数据中毒中恢复
有没有人从 Oracle 数据库的实时环境中获取备份(大约 30 个表),然后使用此备份加载测试环境并在测试环境和从实时环境中获取的备份之间进行比较?最好不要使用针对实时环境的查询。
请注意,在加载测试环境时,实时环境将有事务更改其数据,因此我无法在加载测试环境后使用实时环境的数据进行比较。
这个想法是选择备份丢失的任何丢失的记录、列甚至表。知道实际数据值是否相同也很棒。
我认为散列函数可能是最好的方法。有没有可用的工具?
backup ×10
sql-server ×5
restore ×3
mysql ×2
clustering ×1
mysqldump ×1
oracle ×1
python ×1
replication ×1
snapshot ×1
vss ×1