标签: sql-server-2014

我目前正在使用 Ola Hallengren 先生提供的脚本来执行维护工作，最近我注意到有很多表（堆）碎片级别高得惊人，需要查看并采取行动。我在网站上查看了常见问题解答，似乎他的脚本不支持重建堆。我使用以下查询来查找碎片级别：

SELECT dbschemas.[name] as 'Schema', 
dbtables.[name] as 'Table', 
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID() and dbindexes.name is null
ORDER BY page_count desc, indexstats.avg_fragmentation_in_percent desc

我的应用程序得到供应商的支持，我一直在与他们沟通以将这些堆更改为表并创建聚集索引，但是它还没有产生任何有意义的结果，因为他们已将主键定义为唯一的非聚集索引并且它也是一部分外键，因此在进行任何更改之前需要在多个级别进行更改。首先，我花了很多天时间来解释聚集索引和具有唯一索引的主键之间的区别。

我还经历了Brent Ozar 先生建议的调整 …

我们有一个由供应商支持的应用程序，并且有一段代码在一个过程中执行非常繁重的逻辑读取和耗时，因此我建议他们稍微调整查询以减少 IO 和时间，它在在数据和性能方面进行测试，但是在生产中失败并返回不同的数据，我们不得不回滚更改。需要您的专家建议。

这是在测试环境中对数据进行了3个多月的测试，我们从未出现过任何数据问题。部署后立即开始在生产中很少失败，并产生不一致的数据。

现有查询：

SELECT @Ref= CAST(MAX(ISNULL(CAST(ref_clnt AS INT),0))+1 AS VARCHAR(10)) 
FROM table_name WITH(NOLOCK) 
WHERE s_mode='value'

建议查询：

SELECT @Ref = ref_clnt+1 FROM table_name WITH(NOLOCK) 
WHERE RefNo = (SELECT MAX(RefNo) FROM table_name WHERE s_mode = 'value')

表的DDL如下：

CREATE TABLE [dbo].[table_name](
    [RefNo] [dbo].[udt_RefNo] NOT NULL,
    [S_Mode] [varchar](10) NOT NULL,
    [ref_clnt] [varchar](50) NULL)
CONSTRAINT [PK_table_name] PRIMARY KEY CLUSTERED 
(
    [RefNo] ASC
)

仅提供查询中使用的定义中的那些列。

Udt_RefNo 是用户定义的数据类型：

CREATE TYPE [dbo].[udt_RefNo] FROM [char](16) NOT NULL
GO

SQL Server 版本：Microsoft SQL Server 2014 (SP3) 版权所有 …

我想知道是否可以使用一个共享文件夹（仅在源数据库中）而不是两个（一个在源数据库中，另一个在目标数据库中）。即 Server1 将其 t-log 备份存储在那里，Server2 将从同一文件夹中恢复这些备份。请看下面的图片来理解我的意思：

我在我的项目中使用 MS SQL Server 2014 标准版，最近我遇到了在用户正常使用系统期间索引碎片变高的问题。

目前索引在维护窗口期间每天重建一次，但在某些操作之后，一些索引会变得相当高（超过 30%）。另一个问题是，如果有大量数据要处理，碎片会发生在单个进程中，因此我们最终会发现进程启动得相当快，但一旦出现碎片，其性能就会急剧下降。

在这种情况下我能做什么？我不太可能获得额外的维护窗口。我正在考虑定期只重建一些索引，但我担心它最终会导致数据库锁定甚至死锁。

需要将 Service Pack 应用于以下 SQL Express 安装：

安装版本： 12.0.2000.8 (2014) Express Edition

不确定我是否可以应用最新的 SQL 2014 Service Pack SP4 或坚持使用我发现的最新 Express Service Pack SP3。

SQL 2014 的服务包与 SQL 2014 Express 的服务包不同吗？

昨天我在一个 3 节点 AlwaysOn 实例组 SQL 2014 SP3 上做一些工作，今天早上我发现有一个名BackupLocDb_1260a388-153d-4c86-a30b-0fd3feafb116为主数据库的数据库。我没有创建数据库，但我被列为所有者。

这个数据库是从哪里来的？

最初尝试使用 google，将我带到了一些 AlwaysOn 帖子，但没有明确提及数据库。我也没有在 DBA.SE 上找到它。

我有一个关于工作统计的问题。因此，我有一份具有以下时间表的工作：每天在上午 12:00:00 到晚上 11:59:59 之间每 5 分钟发生一次。时间表将于 2017 年 12 月 13 日开始使用。

在 2019-10-20 上午 11:27 我运行了两个脚本来获取 last_run_time 和 next_run_time，下面是脚本及其对应的结果：

USE msdb
GO
SELECT J.Name                     AS 'Job Name'
         ,'Job Enabled' =        
          CASE J.Enabled
                 WHEN 1 THEN 'Yes'
                 WHEN 0 THEN 'No'
          END
         ,STUFF(
          STUFF(CAST([active_start_date] AS VARCHAR(8)), 5, 0, '-')
          , 8, 0, '-')                   AS 'Job Schedule Start Date'
         ,STUFF(
          STUFF(CAST([active_end_date] AS VARCHAR(8)), 5, 0, '-')
          , 8, 0, '-')                   AS 'Job Schedule End Date'
         ,'Job Frequency' =
          CASE …

我相信在数据库镜像中改变主数据库的兼容模式会改变镜像数据库。

但事实证明这是错误的。我sys.databases在 Primary 上查询使用，我将兼容模式更改为 120 ，但是在其镜像数据库兼容级别仍然是 100。为什么？

我在 sys.databases 中使用了不正确的 fn 吗？

此外，如果它没有改变它的含义，我是否需要进行故障转移/故障回复来反映？

如果我有只读日志传送辅助数据库以及此更改需要反映的地方怎么办？那我需要重建日志传送吗？

谢谢

为什么在通过链接服务器更新时使用 ISNULL() 使用远程扫描来检索所有行并在本地进行过滤，而不是通过远程查询进行过滤？

UPDATE LINKEDSERVER1.database1.dbo.table1 WITH(ROWLOCK)
SET number = ISNULL(number,0)
WHERE accounts = '123'

UPDATE LINKEDSERVER1.database1.dbo.table1 WITH(ROWLOCK)
SET number = number
WHERE accounts = '123'

执行计划如下：

该表确实有一个针对帐户列的非聚集唯一索引，但 ISNULL() 未用于帐户列并且该索引应该仍然可用。我在这里错过了什么吗？

对于几个场景，我们很少看到在存储过程上执行 sp_recompile 以提高性能。

作为一名 DBA，我了解执行 sp_recompile 时涉及的一些注意事项以及为什么它可以提高性能。

我们的管理层一直在争论，当他们看到上述性能问题时，为应用程序/开发 DBA 提供执行 sp 重新编译的访问权限。只是为了减少 DBA 的参与，APP 开发人员可以在性能问题期间继续运行

我很犹豫，因为我认为它会带来一些不需要的行为，有时甚至会恶化其他 proc 的性能。

我正在寻求专家的一般指导和经验，为什么这在可能的不同情况下或在理想情况下可能是个坏主意。您的输入可能会帮助我设计，并可能以不同的方式解释该方法。

仅供参考 - 在看到参数嗅探等问题时，上述问题不仅被认为是一个应用程序，而且被认为是其他少数应用程序的自动化。