标签: sql-server-2014

SQL Server 2014 速成版已发布，内存限制为 1 GB。

SQL 实例内存属性对此限制有何作用？例如，我可以将属性中的最小和最大内存限制设置为 4GB，并且根据任务管理器，该实例将“使用”4GB 的系统内存。

我最好将内存属性限制为 1 GB 还是在此处分配 > 1 GB 内存有优势。

为什么一个查询的多个计划不好

所以我跑去sp_Blitz处理一些系统。有一些代码可以像往常一样清理。一些应该是聚集索引的堆。等等。

这个特定的查询使用了文字，似乎产生了很多计划。在此查询中的表上整理了索引和内容，甚至为最新的代码/数据库将查询参数化以投入生产。

但是查询仍然显示为参数化问题。（DBA 帮助将计划缓存查询转换为 SSRS 报告，因此我可以从浏览器在 PROD 环境中快速运行它们）。

然后去哪儿？忽略它？（似乎很多计划都很重要）

使用强制参数化？（但显式参数化的那个出现了）。

呃 - 我看到开发人员没有接受我的建议，认为它LEFT JOIN正在变成INNER JOIN......我必须把它修好......

如果没有强制参数化，所有这些文字样式的查询将永远不会共享相同的计划吗？这个查询对于简单的参数化是否太复杂了？

我们正在向一个 60 亿行的表添加一个聚集索引。这是一个在线操作（15 小时后）。

如果我们在此过程中添加另一个日志文件，是否会alter database add log file阻止命令应用程序？

SQL Server 数据库页的大小定义为 8192 字节。有一些头信息据说大小为 96 字节。

如果您曾经尝试创建一个包含超过 8053 个字节的列定义的表，那么您将看到错误消息：

Creating or altering table 'Generated_Data_GUID' failed because the 
minimum row size would be 8061, including 7 bytes of internal overhead. 
This exceeds the maximum allowable table row size of 8060 bytes.

Run Code Online (Sandbox Code Playgroud)

以下是一个示例表 DDL：

CREATE TABLE [dbo].[Generated_Data_GUID](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [GUID] [uniqueidentifier] NOT NULL,
    [SEQGUID] [uniqueidentifier] NOT NULL,
    [Data1] [char](4000) NULL,
    [Data2] [char](4000) NULL,
    [Data3] [char](9) NULL,
    [EntryDate] [datetime2](7) NULL
) ON [PRIMARY]

通过以上的DDL如果我改变了列的列定义Data3是char(10)，那么我会打的错误消息。

每个列类型的字节大小如下： …

我正在努力理解执行计划中行估计的来源。

粘贴计划链接

declare
@BatchKey INT = 1, @ParentBatchKey INT = 1,
@QuoteRef varchar(50) = 'Q00018249',
@MpanRef varchar(50) = '1425431100004'


SELECT DISTINCT
        ISNULL(c.ContractReference,-1) AS [ContractReference] ,
        ISNULL(d_cd.ContractDetailsKey,-1) AS [ContractDetailsKey] ,
        -1 AccountManagerKey,
        -1 SegmentationKey,
        ISNULL(d_tpi.TpiKey,-1) AS [TpiKey] ,
        ISNULL(d_cu.CustomerKey,-1) AS [CustomerKey] ,
        ISNULL(d_p.ProductKey,-1) AS [ProductKey] ,
        -1 as PayPointKey,
        -1 AS [GspBandingKey], --Not used in Junifer ESOB
        ISNULL(d_pps.[ProductPricingStructureKey],-1) AS [ProductPricingStructureKey],
        ISNULL(d_tou.TouBandingKey,-1) AS [PricingStructureBandingKey],
        -1 AS [VolumePointCategoryKey],
        ISNULL(d_ppc.PowerPeriodCategoryKey,-1) AS [PowerPeriodCategoryKey],
        ISNULL(d_pcat.[PriceComponentAggregationTypeKey],-1) AS [PriceComponentAggregationTypeKey],
        -1 AS [MarginRateBandingKey], --Not used in Junifer ESOB
        -1 …

假设我们有一个生产系统，其中有几个使用 TDE 加密的数据库和一个自生成的证书。

我们经常需要使用这个数据库并更新我们的非生产系统。此过程涉及备份源数据库、将其恢复到预生产状态、混淆个人数据和许多其他项目。

这里的关键事实是预生产系统具有生产的加密证书副本

我正在寻找使此过程更安全的方法 - 我对预生产环境中的证书不满意。有没有另一种方法可以：

1. 永远不要在任何地方保存未加密的备份
2. 不允许将个人数据从生产传播到非生产系统？

我有一个启用了 RCSI 的数据库，并且从我记事起，我就一直在在线重建索引（SQL 2014 Enterprise）。我的理解是，如果我们要离线重建索引，我们将丢失额外的 14 个字节。但是，只要我们继续在线重建或重组，我们就会保留每行 14 个字节。那是对的吗？

我们有一个Truncate Table在 Snapshot 事务中运行的 proc 。这似乎导致了一个LOCK_M_S阻塞 sys 视图的锁sys.partitions。

有没有方便的解决方法？我喜欢不使用 truncate 发生的多余日志的效率，但不想锁定我的sys.partitions.

我很高兴应要求发布代码，但我很确定这是Truncate在 Snapshot 事务中的某种行为。我只是不知道。

我们一直遇到一个表上的页面拆分问题，这是一个特别麻烦的问题 - 它是数据库中活动的审计日志，并且已经增长到 1TB 以上。主要索引位于记录类型上，它是 an NVARCHAR(100)- 因为当有 5 种记录类型时您需要它 - 它比 aTINYINT和记录 id更有意义- 它是 anNVARCHAR(200)而不是记录的整数键。

它们还涵盖索引，包括键、旧值、新值等——非常广泛。

这是一个旧系统，不幸的是，这种审计的代码无处不在，而不是集中在一个程序中。它无法改变，我们正在经历漫长的微服务重写的痛苦过程。

因此，我将两个索引的填充因子从 100% 降低到 85%。

并且页面拆分变得更糟。我会说大约 3 倍的页面拆分。

这是一个普遍的结果吗？大多数建议说减少填充因子以提高页面拆分性能。我可以理解为什么它会这样做，因为键中数据的宽度。

建议是进一步降低填充因子，还是将其恢复原状？

我使用维护计划重建了我的数据库设置填充因子 95（5% 可用空间）中的所有索引。重新索引后，数据库的大小几乎翻了一番——报告的可用空间为 42%。

计算的填充因子如何与数据库的大小相关？

也许重新索引有问题；是什么导致了如此大的规模增长？

重新索引后的一些数据库信息：

Size (MB):            164 983.625
Data Space Used (KB):      82 907 896
Index Space Used (KB):     14 073 320
Space Available (KB):      71 879 024

为一张表生成维护计划的T-SQL：

Size (MB):            164 983.625
Data Space Used (KB):      82 907 896
Index Space Used (KB):     14 073 320
Space Available (KB):      71 879 024

附加信息：

的结果 sp_spaceused 'dbo.BigTable'

name        rows        reserved    data        index_size  unused
BigTable    58028080    72824296 KB 68393936 KB 4424000 KB  6360 KB