我有一个应用程序使用db_owner权限连接到的数据库。
如何有效地确定该用户（应用程序）在不导致服务中断的情况下实际运行所需的最低要求集？（即没有反复试验）
除了数据库引擎，SQL Server 还有一些额外的服务，即：
他们每个人都应该拥有单独的 Windows 帐户吗？
如果是这样，使用这种更细粒度的帐户设置有什么好处？实用吗？
如果没有，为 SQL Server 及其附加服务设置什么是好的、推荐的帐户设置？
我在生产中的两个 SQL Server 2005 实例上设置了警报。只要Free Pages性能计数器低于 5000 页标记，就会发送这些警报之一。
两台服务器通常都有超过 300000 个空闲页面，但有时其中一台服务器会暂时远远低于 2000 甚至 1000 个空闲页面，然后再次上升。同样，这只发生在其中一台服务器上。
据我所知，这种行为不会降低该服务器的性能，因为在我看来，每当服务器在空闲页面上耗尽时，它都会从缓冲区中释放旧数据页面并填充空闲缓冲区列表. 至少从理论上讲。
我不明白的是，为什么惰性写入器没有维护更大的空闲缓冲区列表，而是“等待”SQL Server 在释放更多缓冲区之前在空闲页面上变得如此短缺。
所以我的问题实际上是双重的：
1. 我如何确定是什么/谁导致 SQL Server 空闲页面不足？
2.如何检查什么是真正回事？
据我了解，SQL Server在使用 RESTORE WITH STANDBY 将还原应用于数据库时会生成撤消文件。
从 MSDN 文档（强调我的）：
备用文件用于为在撤消过程中修改的页面保留“写时复制”预映像的 RESTORE WITH STANDBY。备用文件允许在事务日志还原之间启动数据库以进行只读访问，并且可以用于热备用服务器情况或特殊恢复情况，在这种情况下检查日志还原之间的数据库很有用。在 RESTORE WITH STANDBY 操作之后，撤消文件会被下一个 RESTORE 操作自动删除。如果在下一次 RESTORE 操作之前手动删除了此备用文件，则必须重新恢复整个数据库。当数据库处于 STANDBY 状态时，您应该像对待任何其他数据库文件一样谨慎对待此备用文件。与其他数据库文件不同，此文件仅在活动还原操作期间由数据库引擎保持打开状态。
Standby_file_name 指定一个备用文件，其位置存储在数据库的日志中。如果现有文件使用指定名称，则覆盖该文件；否则，数据库引擎会创建该文件。
给定备用文件的大小要求取决于还原操作期间未提交的事务导致的撤消操作量。
开头提到的undo pass是什么？
据我了解，这些是写在日志文件中的未提交的操作。如果这是正确的，为什么如果这些操作一开始没有提交，为什么要在日志文件上执行这些操作，为什么 RESTORE WITH STANDBY 操作需要将它们存储在某个地方以便能够将数据库设置为只读访问（换句话说，为什么不能直接扔掉它们）？
我有两个几乎相同的（结构上）数据库：
原来的数据库在表分区可用之前就已经存在，所以他们找到的解决方案是创建第二个数据库，并在每年之后将所有旧数据迁移到其中。现在他们想再次合并两个数据库。
我做了一些研究，我发现两个数据库在表之间只有很小的结构差异，并且没有 IDENTITY 列。
因此，除了微小的结构差异之外，我认为最有可能将旧数据库中的值插入到第一个数据库中。
数据库其实有点大，有100多张表。
我想知道的是，使用 SSIS 来做这件事有意义吗，或者 SSIS 适合这种工作吗？还是我应该只编写 T-SQL 代码来完成这项工作？
作为一个附加问题，是否有比上述前两个选项更适合此类工作的工具？
我想在 SQL Server 上使用 Service Broker 为我们的生产数据库设置一堆事件通知。
我在我的测试机器上设置了一个新数据库，一切正常。问题是我宁愿不必为此通知目的部署整个数据库，而且我不能使用一个已经到位的用户数据库（无论如何，这将是一团糟）。
如果可能，我最好将通知对象部署在 上master，但首先我想确定这实际上是一个好主意（如果确实如此）。
从网上书籍：
不要在 master 中创建用户对象。如果这样做，必须更频繁地备份 master。
Books Online建议我不要在master. 此外，我们已经master经常备份我们的数据库。
master在这种情况下，我应该使用数据库还是其他东西？
master在设置之前，我应该了解数据库、服务代理或事件通知吗？
sql-server-2005 sql-server sql-server-2008-r2 service-broker event-notification