小编Jos*_*ell的帖子

出于安全考虑，我们希望每天更改启动 SQL Server 服务的密码。是否可以在不重新启动服务的情况下执行此操作？

如果有可能，更改会立即应用，还是我最终需要重新启动服务以获取新密码？

我们正在考虑在 Windows 操作系统的服务选项中而不是在 SQL Server 配置管理器中进行此更改。

不重复：

• 交易日志很大！但是选择了简单的恢复模式！

• 当数据库处于简单模式并且没有等待事务时，为什么我的事务文件会增长

原因：我的日志不大，但是是空的。它很大，但正在使用中。

问题

我有一个小型数据库 (100 MB)，它全天都会受到大量小型事务性工作负载的影响。尽管我似乎了解如何限制它，但我已经看到事务日志继续增长。显然我错过了一些东西。

• 数据库处于简单恢复模式（我不能保证它在第一次创建时没有处于完全状态，但它从未处于完全负载状态）。

• DBCC SQLPERF(Logspace) 说：

| Log Size (MB) | Log Space Used (%) | Status
--------------------------------------------
| 927.2422      | 94.72562           | 0

• DBCC LOGINFO 说：

有39行（VLF）进行，所有这些都具有Status的2。

• DBCC opentran 说：

最旧的活动事务：
SPID：51
名称：user_transaction
开始时间：2019 年 3 月 11 日晚上 7:27

注意：鉴于我的服务器时间，此事务大约有五分钟的历史。

我不明白为什么当我的应用程序只创建 - 最多 - 大约六个短期交易时，每个 VLF 都在使用中，尽管非常频繁。

我尝试终止连接到该数据库的唯一应用程序进程，但它没有释放事务日志。

解决方法

我做了一个完整备份只是为了解决这个问题，它释放了整个日志空间......所以......我不知道。我得看看它是否会再次过度生长。

我遇到了一张这样的表：

CREATE TABLE TABLE1
(
 CD1    int
,CD2    varchar(16)
,CD3    varchar(21)
,CD4    decimal(14,0)
,CD5    varchar(4)
,CD6    decimal(18,2)
,CD7    AS (left([CD3],(4)))
)

该表有超过 40 亿行（完全没有必要，但这是另一个主题）。

正如您在最后一列中看到的，它们使用AS (left([CD3],(4))). 我认为这是非常无用的，因为我们几乎从来没有在这个表上有一个 SELECT，这里只是使用空间。

在需要时在选择期间选择该字段不是更好吗？

我们有一个独特的情况，我们希望允许用户使用 SSMS 查询数据库的可读辅助副本以进行临时报告，但不允许他们从主副本中读取数据。我们设置了只读路由来完成此任务。这也是 SQL 2016 上的全部。

我最初的想法是在主副本和辅助副本上创建登录名，并授予对相关数据库的读取访问权限。然后我们将拒绝连接或禁用当前主副本上的登录。在 SSMS 中，用户可以使用 ApplicationIntent=ReadOnly 连接到侦听器，并路由到辅助副本，而无需接触主副本。

我们将使用基本逻辑在主副本服务器和辅助副本服务器上设置一个简单的作业：如果当前服务器=主服务器，则禁用登录；如果当前服务器 = 辅助服务器，则启用登录。

问题是，当在主服务器上禁用登录时，以只读意图连接到侦听器时，我会遇到登录失败。当我在主副本上重新启用登录时，它工作得很好，并且连接已正确路由到可读的辅助副本。

我在主服务器上设置了跟踪，果然，我可以看到登录连接并在主副本上的 master 和 msdb 中运行一些系统类型查询 - 即使我在 SSMS 中使用 ApplicationIntent=ReadOnly 进行连接。我不确定这是否是 SSMS 在幕后执行的操作，或者是否是登录通过只读路由过程的默认行为。

以下是我在主数据库上使用快速分析器跟踪捕获的查询：

--msdb query

    select 
        case 
            when object_id('dbo.sysdac_instances') is not null then 1             
        else
            0 
        end

--master query

SELECT
dtb.name AS [Name],
dtb.database_id AS [ID],
CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible]
FROM
master.sys.databases AS dtb
ORDER BY
[Name] ASC

以前有人处理过这种情况吗？看来我们基本上需要允许主副本上的登录连接权限，同时拒绝其对主副本上 AG 中的数据库的读取访问权限，但授予该登录权限以读取可读辅助副本上的数据库。

另一种选择是创建一个直接指向辅助副本的 DNS 条目，但我们不能保证该副本始终是辅助副本，因为可能会发生故障转移。

我已经计算出所有隐式转换，但我仍然在计划中看到它的提及。我已附上该计划，任何建议都会有所帮助。

select cardholder_index, sum(value) as [RxCost] 
into #rxCosts 
from RiskPredictionStatistics with (nolock) where model_name = 'prescription_cost_12_months'
 and model_set_name = 'rx_updated' and run_id in (select value from #runIds) 
 and exists (select 1 from StringContainsHelper with (nolock) where IntValue = cardholder_index and ReferenceId = @stringContainsHelperRefId)
group by cardholder_index

https://www.brentozar.com/pastetheplan/?id=SyHl9xFeS

因此，在基本编码和测试过程中，我们看到多个表的 Identity 值出现了巨大的无模式跳跃。我们不知道任何服务器故障或尝试进行批量操作，但 DBA 正在查看日志。

差距不是典型的 1,000 或 10,000 与服务器重启等情况。

对于Application_NO具有 2,320 行的表，其间隔为10,410,345

Transaction_Payment_NO 对于包含 685 条记录的表，跳出惊人的 1,712,149,313 条记录。

关于什么可能导致如此大且看似随意的跳跃的任何想法？

我想就我们目前在我工作的公司进行的索引维护获得一些意见。我们的生产 SQL 2012 集群之一由 4 个节点组成，每个节点上有两个实例，有多个 AG，为一些非常繁重的工作负载提供服务。这些 AG 中的一些数据库是 2TB+。

我们有一个标准的日常索引维护例程，它根据碎片级别进行通常的重建与重组，但我们也只对超过特定大小的索引进行重组，因为如果这些较大的索引要被删除，我们已经看到 SYNC 延迟问题重建。一旦执行了索引维护，我们就会更新统计信息等。

这项工作有时会运行长达 12 小时以上，因此它会影响我们看到流量高峰的关键工作时间，因此我们确实需要采取一些措施来缓解这种情况。

我最近看到了很多评论，有人建议根本不需要维护索引，我怀疑这可能是我们正在对只有 5% 的大型索引进行重组的情况支离破碎。

我想我想要一些关于如何识别索引的想法，这些索引不一定需要我们每天进行的维护级别，除了禁用它并观察影响（如果有的话）。

当我sys.sysprocesses在 SQL 2008R2 中签入时，存在许多阻塞会话。其中大部分是插入、更新和删除语句，具有与锁相关的等待类型。

这会导致超时问题吗？谁能确认这是否会导致超时/性能问题？

我们正在使用查询存储。现在我们通过每晚清理查询存储解决了一个问题。当您清理查询存储时，查询存储表正在被RESEED编辑 :-(

您知道如何在不RESEED使用表的情况下清理查询存储吗？

我有一个包含 3 个表的 SQL Server 数据库。我需要恢复包含4 个表的备份，同时仍保留原始 3 个表中的旧数据。这可能吗？

我试图了解由执行某些表扫描的 SQL 语句引起的缓存流失。

假设 LRU 缓存，如果某事正在执行 400K 逻辑 IO，则流过多少内存（IO 块大小 * 逻辑 IO）。

此外，我试图了解如何获取关于顶级逻辑 IO SQL 语句的报告并获取这些产生的物理 IO。

鉴于此，我的问题是：

1. SQL Server 逻辑 IO 操作所指的 IO 块大小是多少。
2. 如何获取特定 SQL 执行实例的物理 IO？

出于多种原因，但主要是数据量庞大，我们有 5 个 MS-SQL (2017) 分片服务器来分解任何单个服务器上的整体负载。其次，我们有一个按资产 ID 分区的实时表，以存储实时数据。每个资产的数据包大约每 2 秒到达一次。每个数据包可以有 300 到 12000 个数据点。

表分区和分片服务器运行良好。但是每隔一段时间，似乎其中一台服务器似乎停止使用分区，这会导致在删除旧数据和批量加载新数据时新数据到达时出现死锁和超时。

我的问题是为什么会发生这种情况，有没有办法检查何时或为什么会发生这种情况。我知道这是个问题，因为我可以将数据移动到临时表，删除原始表，使用相同的分区函数和方案重新创建原始表，最后将数据从临时表复制回新的“原始”表问题解决了。

根据要求的分区方案。资产 ID 是函数使用的内容，如上所述

CREATE PARTITION SCHEME [RMAPartitionScheme] AS PARTITION [RMAPartitionFunction] 
TO ([HULL269_484_LymanMartin], [HULL275_541_ClarenceTriche], 
    [HULL277_546_RussellAdams], [HULL278_550_CharlieComeaux], 
    [HULL281_561_CInstaller], [HULL284_587_GrandIsle], 
    [HULL290_621_ShipIsland], [HULL291_638_HornIsland], 
    [HULL296_653_StimStarIV], [HULL293_654_CatIsland], 
    [HULL292_655_SanibelIsland], [HULL297_678_DauphinIsland], 
    [HULL137_679_StimStarBrasil], [HULL809_680_Robin], 
    [HULL1304_690_FastTrack], [HULL174_691_CRuler], 
    [HULL1328_692_FastTiger], [HULL240_695_CFighter], 
    [HULL778_730_Kudu], [HULL064_738_FastCheetah], 
    [HULL063_739_FastServer], [HULLT100_746_ITS100BSM], 
    [HULLBT10_749_ITSBuckeye], [HULL315_779_Elrington], 
    [HULL302_780_MarshIsland], [HULL321_781_Courageous], 
    [HULL316_782_LaTouche], [HULL317_784_BainBridge], 
    [HULL324_787_Contender], [HULL325_788_Champion], 
    [HULL318_790_Ingot], [HULL326_792_Challenger], 
    [HULLN01_797_SeawayMoxie], [HULLAS1_799_IslandCommander], 
    [HULL301_800_DeerIsland], [HULL810_804_Lucy], 
    [DEFAULT_FILE_GROUP])

和功能

CREATE PARTITION FUNCTION [RMAPartitionFunction](int) 
AS RANGE LEFT 
FOR VALUES 
     (484, 541, 546, 550, 561, …