据我了解，当使用 RESTORE WITH STANDBY 对数据库应用还原时，SQL Server 会生成撤消文件。
从 MSDN 文档（重点是我的）：
备用文件用于为撤消过程中修改的页面保留“写时复制”预映像的恢复与待机。备用文件允许在事务日志恢复之间启动数据库以进行只读访问，并且可以与热备用服务器情况或特殊恢复情况一起使用，在这些情况下，在日志恢复之间检查数据库很有用。在 RESTORE WITH STANDBY 操作之后，撤消文件会被下一个 RESTORE 操作自动删除。如果在下一次 RESTORE 操作之前手动删除了此备用文件，则必须重新恢复整个数据库。当数据库处于 STANDBY 状态时，您应该像对待任何其他数据库文件一样小心对待这个备用文件。与其他数据库文件不同，此文件仅在活动还原操作期间由数据库引擎保持打开状态。
standby_file_name 指定一个备用文件，其位置存储在数据库的日志中。如果现有文件使用指定的名称，则覆盖该文件；否则，数据库引擎将创建该文件。
给定备用文件的大小要求取决于还原操作期间未提交事务导致的撤消操作量。
开头提到的undo pass是什么？
据我了解，这些是写入日志文件中尚未提交的操作。如果这是正确的，为什么这些操作在日志文件中没有被提交，为什么 RESTORE WITH STANDBY 操作需要将它们存储在某个地方才能使数据库处于只读状态访问（换句话说，为什么不能直接扔掉它们）？
所有操作，已提交或未提交，都写入日志。提交确保所有日志条目都是持久的（刷新到磁盘），但没有什么可以阻止未提交的条目在此之前被刷新（因为日志块已填充或因为另一个事务提交，从而强制每个事务的刷新）。回滚必须分析所有事务条目并生成补偿操作（每次插入执行删除，每次删除执行插入，每次更新执行将数据反转回的更新）。当然，这些补偿动作会被记录下来。
恢复数据库后，它必须回滚日志中未提交的任何事务。因此，它必须分析日志，找出未提交的事务，然后为属于未提交事务的所有动作生成补偿动作。在线恢复会将补偿操作写入日志本身。备用恢复会将补偿操作写入备用流，从而允许稍后从“主”源应用进一步的日志（这就是日志传送备用只读访问的工作原理）。
在提出任何澄清性问题之前，请阅读ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging。
undo pass 需要从检查点操作刷新到磁盘的进行中事务中恢复任何脏页。
检查点将缓冲区缓存中的所有脏页写入磁盘，无论生成它们的事务是否已提交。检查点和日志的活动部分涵盖了血淋淋的细节。
Restore WITH STANDBY 允许您在恢复之间将数据库置于只读状态（如您的报价所述）。为了使数据库处于事务一致的状态，必须运行撤消过程。为了继续进一步的恢复（这是备用的目的），被UNDO修改的页面需要重新应用，因此需要将它们存储在备用文件中。