禁用资源调控器后是否应该重新启动 SQL Server？最佳做法是什么？
为什么我问这个，因为我担心 SQL Server 中现有的打开会话。如果我们只禁用资源调控器而不重新启动 SQL 服务，它们的行为（在 CPU、内存和 IO 方面）是否会更改为默认值？
例如，如果某个特定会话由于资源调控器而被限制为使用系统总内存的 30%。所以如果我们现在单独禁用资源调控器，它会立即开始使用超过 30% 吗？
我创建了一个示例表，如下所示
CREATE TABLE [dbo].[StatisticsDemo](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](50) NULL
) ON [PRIMARY]
然后我插入以下数据如下：
SELECT NAME,COUNT(*) AS COUNT
FROM StatisticsDemo
GROUP BY NAME
NAME COUNT
-------------
AABBCC 59999
XXYYZZ 1
然后我在下面创建了非聚集索引：
CREATE NONCLUSTERED INDEX [NCI_STATISTICSDEMO_NAME] ON [dbo].[StatisticsDemo]
(
[Name] ASC
)
现在我运行了以下查询：
SELECT NAME FROM [dbo].[StatisticsDemo]
WHERE NAME = 'AABBCC'
正如预期的那样，它返回 59999 行，但它正在对非聚集索引进行索引查找。但据我所知，它应该进行索引扫描，因为 99.99% 的数据满足选择查询中提到的过滤条件。
有人能告诉我为什么它在做索引搜索而不是索引扫描吗？
整个活动的目的是证明（正如我将要介绍的统计数据）SQL Server 在准备执行计划之前查看统计数据以识别符合查询过滤条件的记录数，并基于百分比记录匹配表中的总记录，它将决定执行扫描或搜索。如果匹配记录的百分比大约等于表中的记录总数，则应执行 SCAN。但这并没有发生。当我使用 AdventureWorks2016 数据库并运行以下查询时也是如此：
select * from [Sales].[SalesOrderHeader] WHERE SalesOrderID >= 43659 AND
SalesOrderID <= 73659
上面的查询返回 31465 条记录中的 30001 …
在SQL Server中，我们如何在查询执行后查看其实际执行计划？
据我所知，只有估计的执行计划（而不是实际的执行计划）存储在计划缓存中。那是对的吗？
注意：我们没有任何第三方监控工具。
Azure VM (IaaS) 上托管的 SQL Server 中是否存在数据库邮件？
如果不支持 DB 邮件，那么可以使用哪些功能？
我是 PostgreSQL 的新手，所以如果我的问题听起来很愚蠢，请忽略。
想象一下，我们在 PostgreSQL 中有三个数据库，TRUNCATE一个小时前有人错误地在其中一个数据库上运行了一个命令。现在我们想单独为那个数据库做一个 PITR，因为只有一个数据库有问题。
在 PostgreSQL 中是否可以为一个特定的数据库执行 PITR 或者它只能在实例级别发生？
我阅读了持续存档和时间点恢复 (PITR)的文档。看起来它只能在实例级别完成（我猜我们在 PostgreSQL 世界中将实例称为“数据库集群”，我来自 SQL Server 世界）。
与普通文件系统备份技术一样，这种方法只能支持整个数据库集群的恢复，而不是一个子集。
如果 PITR 在 DB 级别是不可能的，那么 Prod DBA 如何处理这种情况？
还有最后一件事，我有一个带有多个数据库的测试服务器，如果 PITR 在数据库级别是可能的，那么请分享我的步骤，以便我可以自己测试它。
我主要对支持的 Postgres 版本感兴趣。我的测试服务器是 PostgreSQL 9.6.16。