这篇文章将帮助你学习和准备SQL Server面试问题和答案。如果你正在寻找工作机会，或者想提高你的面试技巧，那么你必须通过这篇文章，以及这篇文章中给出的问题和答案。我试图以一种非常精确的方式回答每个问题，这也是现在大多数面试官希望听到的。
如果你想换工作，你也必须准备以下问题，同时提高你的技术能力。如今，拥有技术知识并不足以获得一份工作，相反，你应该向面试官展示你的奉献精神、积极的态度、灵活性，以及采用新变化的意愿。面试官会问很多其他非技术性的问题来评估你的素质，就像我上面提到的（奉献精神、积极的态度、灵活性和善于采用新的变化）。请确保在进入就业市场之前也准备好他们的答案。我举几个此类问题的例子。
- 告诉我一些关于你自己和你在SQL Server方面的经验？
- 给我介绍一下你的数据库环境，比如实例的数量、数据库、最大的数据库规模等等？
- 解释一下你的最大的关键OLTP数据库的备份和数据库维护策略？
- 你是如何处理重大事件的？
- 告诉我关于你所面临的最后一个问题，你是如何解决的？
- 假设有一个数据库问题，而你没有任何解决方案。你做了所有的事情来寻找解决方法来解决这个问题，但是你没有任何收获。你下一步将如何处理这种情况？
- 解释一下你的两个交付或解决方案中的任何一个，你已经得到了客户和领导的认可？
现在让我们在下面的章节中讨论一些技术问题和它们的答案。
在SQL Server中，Page和Extent之间的关系是什么？
页是SQL Server中的基本数据存储。分配给一个数据文件的磁盘空间在逻辑上被划分为一连串的页。在SQL Server中，一个页的大小固定为8KB。我们不能改变SQL Server中的页的大小。Extent是由8个连续的页组成的集合，用来管理这些页。一个extent的大小是64KB，也是八个连续页的大小。
假设你的数据库日志文件大小为10MB。你能计算出分配给该日志文件的页面有多少吗？
在SQL Server中，日志文件不包含任何页面，所以我们可以说日志文件没有任何页面。
SQL Server是如何知道所有更新的页面进行差异化备份的？
SQL Server有一个内部数据结构来跟踪自上一次完全备份以来所修改的外延。 这个内部数据结构是由差异变化图（DCM）页管理的。DCM跟踪extent，并捕获关于修改的extent的细节。如果一个extent的位值为1，意味着该extent自上次完整备份后被修改，如果其值为0，意味着该extent自完整备份后没有被修改。SQL Server在运行差异化备份时，会读取DCM页面以获得所有extent被修改和备份的情况。
我们怎样才能改变SQL Server数据库的逻辑文件名？
可以使用ALTER DATABASE语句来改变逻辑文件的名称。在运行此语句时，我们将传递旧名称和新名称。请看下面的例子，我将把数据库SQLSHACK的逻辑文件名 "SQLSHACK "改为 "SQLSHACK_data1"。
USE [master];
GO
ALTER DATABASE [SQLSHACK] MODIFY FILE ( NAME = SQLSHACK, NEWNAME = SQLSHACK_Data1 );
GO
逻辑文件名也可以通过访问数据库属性页面用GUI来修改。我们只需要为确定的数据库启动数据库属性页面，然后点击左侧窗格中的 "文件 "标签。按照你所需要的命名规则修改文件名，然后点击 "确定 "按钮，提交更改，应用到数据库。
如果我们在一个数据库中添加多个日志文件，对SQL Server的性能会有什么影响？
在数据库中添加多个日志文件将无助于优化数据库的性能，因为SQL Server会在日志文件中连续写入日志记录。
什么是SQL Server中的即时文件初始化？
即时文件初始化允许SQL Server数据文件跳过它们的归零过程，并迅速加快其空间分配过程。这在创建非常大的数据库或添加或扩展数据文件到更大的尺寸时非常有用。
我需要将数据文件大小增加到200GB，日志文件大小增加到50GB。数据文件的空间分配在几秒钟内非常快，但日志文件的空间分配却需要很长的时间，尽管为实例启用了即时文件初始化功能。你能告诉我日志文件增加这么久的原因吗？
即时文件初始化对日志文件不起作用，这就是花这么长时间的原因，数据文件已经迅速分配了所有的200GB。
如何保护你的SQL Server实例？
安全是这些天的主要关注点之一。我们必须采取以下步骤来保证SQL Server实例的安全。
- 确保运行SQL Server的操作系统是经过加固的，并遵循所有的最佳实践。
- 不要错过应用为SQL Server或操作系统发布的任何安全补丁
- 通过应用他们的修复程序或补丁及时修复漏洞
- 只安装那些需要的功能
- 改变SQL Server的默认端口号
- 禁用sa账户并从SQL Server中删除内置的管理员账户
- 始终使用windows认证模式
- 停用SQL浏览器服务
- 使用加密技术来保护数据
- 定期审计你的登录信息
还有一些其他的最佳做法，如给每个人分配适当的权限，不要给任何登录者不必要的授权，立即删除已经离开公司或团队的登录者，始终使用强大的密码来登录，等等。
在SQL Server中，有哪些可用于数据保护和业务连续性的选项？
SQL Server为业务连续性提供了各种选项。
- 备份恢复
- 始终在可用性组上
- 始终在故障转移群集实例上
- 日志运输
- 复制
在SQL Server中启用TDE（透明数据加密）的负面作用是什么？
TDE对数据进行加密，以确保其免受未经授权的访问。一方面，它保护了数据，另一方面，它对SQL Server实例有一些负面的影响。
- 对任何数据库启用TDE也会对tempdb数据库进行加密。
- 在服务器上有一些性能开销，甚至在同一实例上托管的非加密数据库也会因为tempdb的加密而有一些性能开销。
- 使用TDE，数据并不是完全加密的。运输中的数据和缓冲区缓存中的数据仍然是未加密的。
- 定期备份和保护证书/keys
你已经将SQL Server数据库升级到新的版本。你的应用程序用户已经开始抱怨性能缓慢。你如何解决这个问题？
如果用户在升级数据库到较新的版本后开始抱怨性能问题，我们需要调查以下方面。
- 将数据库的兼容性级别改为最新的
- 如果兼容性级别已经设置为最新，那么你应该审查查询计划，如果发现有任何查询退步，那么我们应该使用传统的cardinality估计器作为解决方法。同时，启用查询存储来识别查询回归，并通过选择一个好的计划来修复它们
- 参数嗅探可能是导致性能缓慢的原因之一。重新编译查询计划以解决这个问题
- 寻找缺失的索引并创建它们
- 在确定的对象上运行更新统计
什么是SQL Server中的Always on？
Always on是一个术语，用于SQL Server中的业务连续性功能。它包括可用性组和故障转移集群实例。如果你部署了可用性组，你可以称它为始终在线的可用性组或仅有可用性组，如果你说它仅有始终在线，那么它不是用于可用性组部署的正确术语。
我们可以在基于Windows的SQL Server和基于Linux的SQL Server实例之间配置可用性组吗？
是的，我们可以在Windows和Linux机器上托管的SQL Server实例之间配置可用性组。群集类型将从 WSFC 改为外部，因为 Windows 故障转移群集将不用于此类部署。我们必须使用 pacemaker 集群，集群类型设置为EXTERNAL，以配置基于 Windows 和 Linux 的 SQL Server 实例之间的始终可用组。
解释一下关于分布式可用性组的一些细节？
分布式可用性组是在SQL Server 2016中添加的。它跨越了多个可用组。分布式可用性组是在现有的2个或更多独立的可用性组之上创建的。 参与分布式可用性组的可用性组可以托管在多个地点，它可以在云端或内部，在同一域或不同域等。每个可用性组都有自己的WSFC，参与该可用性组的节点将只属于该Windows Server故障转移群集组。
我们能否在两个SQL Server故障转移集群实例之间配置可用性组？
是的，可以在 SQL Server 集群实例之间配置可用性组，但在 SQL Server 集群实例上运行的副本之间不能配置自动故障转移。
如何在最小的停机时间内修补Always on可用性组？
我们可以按照滚动升级的方法来修补可用性组实例。首先，我们将修补托管在另一个数据中心的 DR 复制。一旦DR副本打好补丁，接下来我们将把故障转移模式改为手动，如果它是自动的，那么就打好托管在主数据中心的辅助副本。 重新启动该服务器，一旦辅助副本上线，就启动主副本的故障转移到新打好补丁的辅助副本，使该副本成为主副本。现在你以前的主副本是次要的，继续修补这个副本。一旦修补完成，重新启动服务器，将SQL Server实例故障转移到这个实例上，使其成为初始设计的主要实例。
恢复可用性数据库（参与可用性组的数据库）需要遵循哪些步骤？
如果不把一个可用性数据库从AOAG中驱逐出去，我们就不能恢复它。我们需要将可用性数据库从可用性组中驱逐出去，然后恢复，再将其添加到可用性组中。
用户已经开始抱怨，他们的报告中没有得到最新的数据，而这些数据是从辅助副本中运行的。你能告诉我主副本和辅助副本之间出现这种延迟问题的三个原因吗？
有多种原因会使主副本和辅助副本之间的数据移动变慢。其中一些原因是。
- 长时间运行的事务会使用户无法看到二级副本的更新信息
- 次级副本的资源争夺会减慢数据移动速度
- 糟糕的网络吞吐量会导致日志在主副本上的堆积
我们知道，所有的事务都是先在二级副本上提交，然后在一级副本上以同步提交的方式提交，在可用性组的配置上总是如此，长期运行的事务怎么会成为看不到二级副本更新的一个原因呢？请解释一下这个问题。
我们需要了解如何在二级副本上进行读操作。所有只读操作都在辅助副本上使用快照隔离级别。只读事务在使用快照隔离级别时不会看到来自开放事务的任何更新。他们读取辅助副本上的日志中活动事务的起始点。长期运行的事务是开放的，还没有提交，所以只读事务将被阻止看到新的更新，直到这个开放的事务被提交。
你用什么工具来排查永远可用组的问题？
我们有很多工具可用于解决可用性组中的任何问题。其中一些是。
- SQL服务器错误日志
- 集群日志文件
- 可用性组扩展事件
- 始终在可用性组相关的等待类型
- 可用性组健康检测日志
- DMVs 和系统目录视图
假设你已经为你的数据库配置了带有Replication的Log Shipping。如果您将日志运输失败转移到辅助服务器上，对复制配置会产生什么影响？
复制将在日志运输故障转移后停止工作。交易将不会复制到用户，因为复制代理不会连接到辅助数据库。如果发生故障恢复，复制将恢复，所有悬而未决的事务将被复制到各自的用户。
你知道什么是RESOURCE SEMAPHORE等待类型吗？
RESOURCE SEMAPHORE是SQL Server中的一种内部算法，它根据SQL Server查询的编译执行计划，授予查询所需的内存，在实例上运行和执行。如果有内存压力或查询没有得到他们要求的内存来执行，那么该查询将以RESOURCE SEMAPHORE等待类型等待，直到内存被授予执行查询。RESOURCE SEMAPHORE在先来后到的基础上工作，因此所有新的查询都将在队列中，等待的查询将根据其在队列中的到来获得其请求的内存。
如何获得特定SQL Server查询的请求和授予的内存细节？
当我们处理性能问题时，获取像请求的内存和授予的内存这样的信息是非常关键的。在SQL Server中有一个名为sys.dm_exec_query_memory_grants 的DMV，它将显示这些内存细节的信息。
