In the continuation of our SQL FILESTREAM article series, we’ll be covering transaction log backups
在我们SQL FILESTREAM系列文章的续篇中，我们将介绍事务日志备份
In SQL Server, we take transaction log backups regularly to have a point-in-time recovery of a database. It is essential to define the backup policy with the combination of full, differential and transaction log backups. A standard configuration of backups for large databases in the production database environment is as follows.
在SQL Server中，我们定期进行事务日志备份，以对数据库进行时间点恢复。 必须结合完整，差异和事务日志备份来定义备份策略。 生产数据库环境中大型数据库备份的标准配置如下。
- Weekly Full backup 每周完整备份
- Daily differential backup 每日差异备份
- Transaction log backup every 30 minutes 每30分钟备份一次事务日志
We need to consider the transaction log backup size while designing a backup and recovery solution. In SQL FILESTREAM database, we store the objects into FILESTREAM container in the file system. SQL Server requires both metadata stored in relational tables and corresponding objects into the file system to recover a database. A Transaction log backup in FILESTREAM databases copies the relevant file from the FILESTREAM container as well into a backup file. It copies the files from the FILESTREAM container in the transaction log backup that is created, modified after the last transaction log backup. It is important to understand the behaviour of the log backup for FILESTREAM database. In this article, we will explore the transaction log backup for the FILESTREAM database backup.
在设计备份和恢复解决方案时，我们需要考虑事务日志备份的大小。 在SQL FILESTREAM数据库中，我们将对象存储到文件系统中的FILESTREAM容器中。 SQL Server要求将存储在关系表中的元数据和相应的对象都放入文件系统中，以恢复数据库。 FILESTREAM数据库中的事务日志备份也将相关文件从FILESTREAM容器复制到备份文件中。 它将文件从FILESTREAM容器复制到创建的事务日志备份中，该文件在上一次事务日志备份之后进行了修改。 了解FILESTREAM数据库的日志备份的行为很重要。 在本文中，我们将探讨FILESTREAM数据库备份的事务日志备份。
先决条件 ( Prerequisites)
- SQL Server instance with FILESTREAM feature 具有FILESTREAM功能SQL Server实例
- FILESTREAM database FILESTREAM数据库
- FILESTREAM table FILESTREAM表
In this article, we are using the [DemoSQL] FILESTREAM database with FILESTREAM table [DemoSQL].[dbo].[SQLShack]
在本文中，我们将[DemoSQL] FILESTREAM数据库与FILESTREAM表[DemoSQL]。[dbo]结合使用。[SQLShack]
We do not have any database backups for this database as of now. You can verify it by right click on the database and Properties.
截至目前，该数据库没有任何数据库备份。 您可以通过右键单击数据库和“ 属性”来验证它。
Before we proceed further, take a full backup and log backup for this SQ Server FILESTREAM database.
在继续进行之前，请对此SQ Server FILESTREAM数据库进行完整备份并记录备份。
Execute Full backup using the following script
使用以下脚本执行完全备份
BACKUP DATABASE [DemoSQL] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\DemoSQL.bak' WITH NOFORMAT, NOINIT, NAME = N'DemoSQL-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
Execute Log backup using the following script
使用以下脚本执行日志备份
BACKUP LOG [DemoSQL] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\DemoSQL_log.trn' WITH NOFORMAT, INIT, NAME = N'DemoSQL-Log Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
In SQL Server 2017 and onwards, we can use DMV sys.dm_db_log_stats to get information about the transaction log. Execute the following query in the FILESTREAM database.
在SQL Server 2017及更高版本中，我们可以使用DMV sys.dm_db_log_stats获取有关事务日志的信息。 在FILESTREAM数据库中执行以下查询。
SELECT
database_id,
recovery_model,
total_log_size_mb,
active_log_size_mb,
total_vlf_count,
active_vlf_count,
log_truncation_holdup_reason,
log_backup_time,
log_since_last_log_backup_mb
FROM sys.Dm_db_log_stats(db_id(db_name()))
At this point, we are having 0.085937 MB active transaction log size.
此时，我们的活动事务日志大小为0.085937 MB。
Let us insert one record in FILESTREAM table.
让我们在FILESTREAM表中插入一条记录。
DECLARE @File varbinary(MAX);
SELECT
@File = CAST(
bulkcolumn as varbinary(max)
)
FROM
OPENROWSET(BULK 'C:\Users\rajen_000\Pictures\BBQ\DSC_0245.JPG', SINGLE_BLOB) as MyData;
INSERT INTO [DemoSQL].[dbo].[SQLShack]
VALUES
(
2,
'Rajendra',
NEWID(),
@File
)
In the following screenshot, we can see a minimal change in the active log size from 0.085937 MB to 0.117187 MB
在以下屏幕截图中，我们可以看到活动日志大小的最小变化，从0.085937 MB变为0.117187 MB
Execute the transaction log backup again. Log backup size is 9.332 KB now. We inserted only 1 record in the FILESTREAM table.
再次执行事务日志备份。 日志备份大小现在为9.332 KB。 我们在FILESTREAM表中仅插入了1条记录。
Insert one more record and monitor the transaction log size.
再插入一条记录并监视事务日志大小。
Update the object in FILESTREAM table as well using the following query.
以及使用以下查询更新FILESTREAM表中的对象。
UPDATE [DemoSQL].[dbo].[SQLShack]
SET BLOBData = (SELECT *
FROM OPENROWSET(
BULK 'C:\Users\rajen_000\Pictures\BBQ\DSC_0246.JPG',
SINGLE_BLOB) AS Document)
WHERE FSUnique = '5E18B530-8A27-48A9-A36C-DF9DBA012319'
GO
After the update also, we have a small active log of 0.296875 MB
更新之后，我们还有一个小的活动日志，为0.296875 MB
Execute the log backup again and view the transaction log size. In the following image, you can see log backup size increased to 135,452 KB.
再次执行日志备份，并查看事务日志大小。 在下图中，您可以看到日志备份大小增加到135,452 KB。
I performed a few more DML command on SQL FILESTREAM table and took the log backup. It was surprising to see the log backup size grown to 23.2 GB.
我在SQL FILESTREAM表上执行了一些DML命令，并进行了日志备份。 令人惊讶的是，日志备份大小增长到23.2 GB。
In the above examples, we observed, using the active log size, that we did not have much transaction log growth but still we have a huge size of log backups. SQL Server does not store the objects for the FILESTREAM database into its relational table. Therefore, it does not require more log size to perform the transactions. SQL Server copies the FILESTREAM files as well in the transaction log backup. It is the reason you might see a huge transaction log backup size. We need to consider below points in transaction log backup for SQL FILESTREAM databases.
在以上示例中，我们使用活动日志大小观察到，虽然事务日志增长不多，但是日志备份仍然很大。 SQL Server不会将FILESTREAM数据库的对象存储到其关系表中。 因此，它不需要更多的日志大小来执行事务。 SQL Server也会在事务日志备份中复制FILESTREAM文件。 这就是您可能会看到巨大的事务日志备份大小的原因。 我们需要在SQL FILESTREAM数据库的事务日志备份中考虑以下几点。
- Insert statement: Suppose we are only inserting the objects into the FILESTREAM table, log backup contains the copy of the inserted object Insert语句：假设我们只是将对象插入FILESTREAM表，日志备份包含插入对象的副本
- Update Statement: In case of update objects into FILESTREAM table, log backup contains the copy of the old object and new object as well. If we perform multiple update queries on FILESTREAM table, log backup size might increase significantly 更新语句：如果将对象更新到FILESTREAM表中，则日志备份也包含旧对象和新对象的副本。 如果我们对FILESTREAM表执行多个更新查询，则日志备份大小可能会大大增加
- Delete Statement: In case of delete activity, log backup contains the copy of the deleted object as well Delete语句 ：在进行删除活动的情况下，日志备份也包含已删除对象的副本
SQL Server removes the files from the FILESTREAM container once the transaction log backup does not require these files. Once we take the log backup, it takes backups of all required files from the FILESTREAM container, and then garbage collector process removes these files from the container.
一旦事务日志备份不需要这些文件，SQL Server就会从FILESTREAM容器中删除这些文件。 一旦我们进行了日志备份，它将从FILESTREAM容器中备份所有必需的文件，然后垃圾收集器进程将这些文件从容器中删除。
You can notice a considerable time in the log backup progress even after 100 percent processed status. It indicates that SQL Server is copying the files from the FILESTREAM container to log backup file.
即使在100％处理状态之后，您也可以注意到日志备份进度中有相当长的时间。 它表明SQL Server正在将文件从FILESTREAM容器复制到日志备份文件。
Let us examine the log backup file. We can use the RESTORE FILELISTONLY command to get a list of database files included in the backup file.
让我们检查日志备份文件。 我们可以使用RESTORE FILELISTONLY命令来获取备份文件中包含的数据库文件的列表。
In this example, I am using the below 1.81 GB log backup file.
在此示例中，我使用下面的1.81 GB日志备份文件。
Execute the following query and observe the output.
执行以下查询并观察输出。
RESTORE FILELISTONLY
FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\DemoSQL_Tran6.trn' ;
GO
We can observe the following things from the output.
我们可以从输出中观察到以下内容。
Log backup file contains all DB files
日志备份文件包含所有数据库文件
- Primary database file ( Type D) 主数据库文件（类型D）
- Transaction log file ( Type L) 事务日志文件（类型L）
- FILESTREAM container ( Type S) FILESTREAM容器（类型S）
Look on highlighted column BackupSizeinBytes in the output. We have following files size in this 1.81 GB log backup.
查看输出中突出显示的列BackupSizeinBytes 。 在此1.81 GB的日志备份中，我们具有以下文件大小。
- DemoSQL.mdf backup size 0 bytesDemoSQL.mdf备份大小0字节
- DemoSQL_log.ldf backup size 0 bytesDemoSQL_log.ldf备份大小0字节
- DemoSQL FILESTREAM files backup size 1943732224 bytes i.e. 1.81 GB. DemoSQL FILESTREAM文件的备份大小为1943732224字节，即1.81 GB。
In this case, we have the log backup size(1.81 GB) equivalent to FILESTREAM container size( 1.81 GB) . It proves our point stated earlier that log backup copies the objects from FILESTREAM container into log backup.
在这种情况下，我们的日志备份大小（1.81 GB）等于FILESTREAM容器大小（1.81 GB）。 证明了我们前面提到的观点，日志备份将对象从FILESTREAM容器复制到日志备份中。
We need to note here that SQL Server does not copy the entire files from the FILESTREAM container. You could see a difference in overall FILESTREAM container size and log backup size because it copies only those files that are required for the transaction log backup. In our case, we had FILESTREAM container size 1.93 GB however log backup size 1.81 GB.
我们需要在这里注意，SQL Server不会从FILESTREAM容器复制整个文件。 您可能会发现FILESTREAM容器的总大小和日志备份大小有所不同，因为它仅复制事务日志备份所需的那些文件。 在我们的案例中，我们的FILESTREAM容器大小为1.93 GB，但是日志备份大小为1.81 GB。
Let us explore more on log backups for SQL FILESTREAM database using extended events in SQL Server.
让我们探索更多有关使用SQL Server中扩展事件SQL FILESTREAM数据库的日志备份的信息。
Create an extended event using the following query. In this extended event session, we need to capture the SQL Server backup and restore progress trace sqlserver.backup_restore_progress_trace.
使用以下查询创建扩展事件。 在此扩展事件会话中，我们需要捕获SQL Server备份并还原进度跟踪sqlserver.backup_restore_progress_trace。
CREATE EVENT SESSION [Backup Monitor] ON SERVER
ADD EVENT sqlserver.backup_restore_progress_trace(
ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_nt_username,sqlserver.sql_text))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
Once we have created the extended event session, right click on it under the Management and Extended Events. Click on Watch Live Data.
创建扩展事件会话后，请在“ 管理和扩展事件”下右键单击它。 单击观看实时数据。
Execute the transaction log backup for FILESTREAM database now and view data in Live Data session window. In the following section, we will explore the output of the extended event session output.
立即执行FILESTREAM数据库的事务日志备份，并在“实时数据”会话窗口中查看数据。 在以下部分中，我们将探讨扩展事件会话输出的输出。
Once we start the log backup process, in the extended event session, we can see a message Backup Log started.
一旦开始日志备份过程，在扩展事件会话中，我们会看到一条消息“ 备份日志已开始”。
It acquires the required locks on the databases and opens the backup media set to write.
它获取数据库上所需的锁，并打开要写入的备份媒体集。
SQL Server performs the estimation of the backup size. If you do not have sufficient free space in the backup drive, you get an error based on this estimated size. You can note the estimated total size is 2416640 bytes, i.e. 2.30 MB. It scans SQL FILESTREAM data after the work estimation. The work estimation size does not include the FILESTREAM container files size required to be backed up.
SQL Server执行备份大小的估计。 如果备份驱动器中没有足够的可用空间，则会基于此估计的大小出现错误。 您可以注意到估计的总大小为2416640字节，即2.30 MB。 工作估计后，它将扫描SQL FILESTREAM数据。 工作估算大小不包括需要备份的FILESTREAM容器文件大小。
SQL Server starts copying the FILESTREAM data into the log backup. We need to note here that at 100 percent stage, we still have backup size 2416640 bytes, i.e. 2.30 MB.
SQL Server开始将FILESTREAM数据复制到日志备份中。 在这里我们需要注意的是，在100％的阶段，我们仍有备份大小2416640字节，即2.30 MB。
In the following screenshot, we can look at the timings for the FILESTREAM data copy.
在下面的屏幕截图中，我们可以查看FILESTREAM数据副本的时序。
- Copying FILESTREAM data: 2019-03-02 10:12:01.5490612 复制FILESTREAM数据：2019-03-02 10：12：01.5490612
- Finish copying FILESTREAM data: 2019-03-02 10:13:30.9988646 完成复制FILESTREAM数据：2019-03-02 10：13：30.9988646
It is the reason you can notice that transaction log backup takes time even after we receive 100 percent processed message. If SQL Server needs to copy large size of FILESTREAM container into log backup, it might take longer to finish the backup.
这就是您即使在收到100％已处理消息后仍会注意到事务日志备份需要时间的原因。 如果SQL Server需要将大型FILESTREAM容器复制到日志备份中，则可能需要更长的时间才能完成备份。
Once it finishes copying FILESTREAM data, it copies the required transaction log and completes the log backup.
完成复制FILESTREAM数据后，它将复制所需的事务日志并完成日志备份。
SQL FILESTREAM数据库中的日志备份注意事项 (Considerations for log backups in SQL FILESTREAM databases)
- Monitor the FILESTREAM database activity in your environment to plan transaction log backups 监视环境中的FILESTREAM数据库活动以计划事务日志备份
- You should have sufficient free disk space to accommodate FILESTREAM database log backup 您应该有足够的可用磁盘空间来容纳FILESTREAM数据库日志备份
- Keep a watch on the log backup size for FILESTREAM database and take actions accordingly 注意FILESTREAM数据库的日志备份大小，并采取相应的措施
- Schedule the log backup frequency to a minimum duration to keep log backups size to a minimum size 将日志备份频率安排为最小持续时间，以将日志备份大小保持为最小大小
目录 (Table of contents)
翻译自: https://www.sqlshack.com/transaction-log-backups-in-a-sql-filestream-database/
815
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
