var*_*ble 3 sql-server backup snapshot vss
我通过 SAN 磁盘工具配置了数据库备份。在备份集表中,我可以看到 VSS 编写器服务正在进行快照类型的完整备份。
服务器上有85个数据库。
我了解数据库快照的概念,最初它的大小为 0。当源数据库更新时,它将更改推送到快照,从而增加快照大小。
我想问是否:
数据库快照和VSS数据库快照备份(通过VSS writer服务)是同一个概念吗?
对于数据库快照和 vss 数据库快照备份 - 假设有 85 个项目(快照/快照备份),那么这将导致 sql server 上的整体 IO 较差,因为它必须定期维护(随着源数据库发生更改而更新)快照85 个数据库?
数据库快照和VSS数据库快照备份(通过VSS writer服务)是同一个概念吗?
不,它们是不同的概念。
数据库快照 (SQL Server) (Microsoft | SQL 文档) 使您能够在同一实例上创建现有数据库的只读副本。
这不是备份,您可以在参考文章的数据库快照限制部分中阅读:
...
您无法备份或恢复数据库快照。
...
您是正确的,I/O 可能会成为源数据库的问题,如同一篇文章的源数据库的限制部分中所述:
...
性能会降低,因为每次更新页面时都会对快照执行写时复制操作,从而导致源数据库上的 I/O 增加。
...
SQL Server 备份应用程序 - 卷影复制服务 (VSS) 和 SQL Writer是确保您可以创建给定数据库的快照备份的程序。这被认为是有效的数据库备份,但有限制。
当通过第三方工具创建数据库快照时,通常会触发 Windows 主机系统的 VSS 编写器。SQL 编写器将处理SQL Server 端的VSS 交互。
使用快照功能创建的数据库备份将在msdb.dbo.backupset.is_snapshot列的msdb备份历史记录中进行相应标记。
根据文档“不支持什么”,不支持 TLOG 备份。
...
SQL 编写器不支持日志备份。
...
对于数据库快照和 vss 数据库快照备份 - 假设有 85 个项目(快照/快照备份),那么这将导致 sql server 上的整体 IO 较差,因为它必须定期维护(随着源数据库发生更改而更新)快照85 个数据库?
根据提供的文档,只有数据库快照才会导致长期 I/O 问题。
数据库快照备份仅在创建快照期间导致短期 I/O问题。
...除非您谈论的是 VMware 快照,这是一个完全不同的问题。如果是这种情况,那么这个后续问题更适合在 severfault.com 上进行
快照备份怎么能这么快完成呢?
使用VSS 服务和SQL 编写器服务的 VSS数据库快照由外部源触发。为什么它们很快,取决于执行快照的环境如何实现快照功能,还取决于所涉及的底层技术。
我只能根据我从 VMware 和 Commvault 环境中获得的信息来提供有关 NetApp 如何执行此类操作的二手信息。Commvault 是我们环境中的领导者,因为它执行我们的备份。
Commvault 触发服务器快照。
VMware 收到快照请求并将其传递给虚拟服务器。
(虚拟)Windows 服务器接收请求并触发 VSS 服务来执行快照。
SQL 编写器服务收到通知并冻结数据库上的读/写操作。
当一切都准备好进行快照并同步时,NetApp 层将在一切都冻结的精确时刻执行服务器磁盘的块级快照。
由于 NetApp 在磁盘级别提供基于块级指针的快照功能(您必须向他们询问详细信息),因此自上次快照以来所有已修改的块都会被考虑在内,并且指针知道在哪里可以找到服务器的状态。快照时间。
一旦执行快照(主要以毫秒为单位),SQL Server 实例上冻结的 I/O 将被释放,数据库将再次可用。
我认为 vss 快照备份很快,因为它的工作方式就像普通快照一样。当原始数据库发生更改时,备份必须持续保持最新。因此,当源数据库发生更改时,整体磁盘 IO 会很慢,因为更改也必须传递到快照备份
是的,我同意数据库快照会由于必须记录到数据库快照中的更改而导致连续的 I/O 延迟。