我们能否在不停止 VM 本身的情况下扩展 Azure VM 中的磁盘。（在线的）
我们正在寻找一种在线方法来扩展我们无法破解的磁盘。我们有某些应用程序迁移到 IAAS，这些应用程序有时需要磁盘扩展。
我正在使用 SSMS 18.0 Preview 6 并想导入我们在本地存储并可访问的 .bacpac 文件。但是，GUI 似乎不支持该功能。欢迎任何更新/建议。
我们将使用 sqlpackage.exe，但是想知道 GUI 是否支持这个。
在我们的 POC 期间，我们看到系统数据库（model、msdb 和 tempdb）位于系统数据库组之外。
背后有什么具体原因吗？
我们遇到了开发团队无法查看他们的报告的问题。安装都是由他们完成的，我们不得不跳起来看看有什么问题。我们怀疑他们安装了评估版并且 180 天已经结束。错误说明这就是问题所在，但我们仍然要检查安装的版本。
我们能够从注册表中找到版本 1.4.6969.7395（内部版本 15.0.1102.235）
如何查找 Power BI 报表服务器的版本？
我们在 AlwaysOn 设置的单个节点上有多个实例，所有实例都配置为 AOAG。现在我们正在使用 Listener\InstanceName 进行连接。每个 AG 的侦听器都指定了一个专用端口。这就是为什么我们不能仅使用没有端口或 InstanceName 的 Listener 进行连接的原因。
我想以这样一种方式进行配置，即只需提供 AG_Listener 就足以进行连接，而无需显式使用端口。
示例：AG-SQL001 而不是 AG-SQL001，Port_Number
这可以做到吗？如果是那么如何？
这是我正在开发的报告中发生的一件非常烦人的事情。顶部的面包屑有时工作正常，但有时会分成多行。我的环境中只有 IE 11，是浏览器问题吗？如果没有，请帮我解决这个问题。
下面是屏幕截图。
我一直在尝试在我的 AG 环境中获取 RegisterAllProvidersIP 的参数值。但是，该命令并没有获取我所有的结果。结果集只有 4 个参数，我想知道如何获取所有参数。我想对此进行检查以调查正在进行的连接问题。这是一个多子网 AlwaysOn 配置。
我正在使用以下命令：
Get-Clusterresource -Name AG_Name | Get-ClusterParameter
AG_Name 是侦听器名称。
请帮助确定我做错了什么还是只是一些权限问题？
我正在阅读有关缺失索引和未使用索引的各种文章。想知道有多个未使用的索引如何导致性能问题。
它如何影响性能？（没有找到任何解释或概念证明）
也很困惑，因为一些文章说丢弃它们也会导致性能问题。它适用于所有情况还是任何特定情况？
在我们的生产服务器之一中，我们需要启用xp_cmdshell某些应用程序功能。
使用我们当前的安全措施，它在所有情况下都被禁用，只需要为一个特定的 SQL Server 启用。
- 启用有多糟糕
xp_cmdshell？ - 这真的是一件值得担心的大事吗？
- 可以采取什么具体措施来启用它并仍然限制它的使用？
我们的应用程序团队创建了一个触发器，可以启动另一个发票流程，他们需要这样做xp_cmdshell。
我们通常使用 Ola Hallengren 的解决方案来处理我们拥有的索引优化作业中的更新统计信息。作为标准做法，我们将它安排在所有服务器（1500+）的每个星期日午夜。
现在，有几台服务器在一周中出现很多性能问题，当因性能问题引发事件时，我们会为该特定数据库运行 sp_updatestats。我们有一个巨大的环境，所有版本都在使用，从 2000 到 2016。在 2012 和 2014 版本中，我们一直在周中手动运行特定数据库的更新统计信息。
最近，由于反复出现的问题，我们还不得不为一些非常活跃的数据库每天安排 sp_updatestats。
我的问题：
- 我们应该多久安排一次？
- 过于频繁地安排它有什么缺点？
- 有没有办法避免定期更新运行如此频繁的缺点，因为我听说编译需要更多时间并且可能会在一段时间内降低性能？
请帮助我了解您在这方面的经验。
我正在玩 SQL Azure 并且在我的学习曲线中。我已将数据库从本地实例迁移到 Azure 服务器。现在我的问题是，如何将数据库从 Azure 移动到本地实例。
来源：Azure，数据库名称：Azuretest
目的地：我笔记本电脑中的本地 Sql server 2016 实例。
是否可以将 Azure 迁移到 On Premise 数据库？
2017-07-06 05:53:02.69 spid17s Error: 17065, Severity: 16, State: 1.
2017-07-06 05:53:02.69 spid17s SQL Server Assertion: File: <latch.cpp>, line = 1538 Failed Assertion = '0' Attempted release of unacquired latch. This error may be timing-related. If the error persists after rerunning the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.
2017-07-06 05:53:02.69 spid17s Using 'dbghelp.dll' version '4.0.5'
2017-07-06 05:53:02.70 spid17s **Dump thread - spid = 17, PSS = 0x1589E7D8, EC = 0x1589E7E0
2017-07-06 05:53:02.70 spid17s ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump1824.txt
2017-07-06 05:53:02.70 spid17s * *******************************************************************************
2017-07-06 05:53:02.70 spid17s *
2017-07-06 05:53:02.70 spid17s * BEGIN STACK DUMP:
2017-07-06 05:53:02.70 spid17s * 07/06/17 05:53:02 spid 17
2017-07-06 05:53:02.70 spid17s *
2017-07-06 05:53:02.70 spid17s * Location: latch.cpp:1538
2017-07-06 05:53:02.70 spid17s * Expression: 0
2017-07-06 05:53:02.70 spid17s * SPID: 17
2017-07-06 05:53:02.70 spid17s * Process ID: 4572
2017-07-06 05:53:02.70 spid17s * Description: Attempted release of unacquired latch
以上是错误日志的详细信息。似乎 tempdb 损坏存在一些问题。实例重新启动修复了该问题，并且 sql 转储创建停止。
似乎已经解决的是 tempdb 在重新启动后重新创建。您对此有何看法？