小编Phi*_*lip的帖子

这是一个有点尴尬的问题，我不敢相信我已经错过了这么多年。

我有一个包含 401 个堆表的供应商第三方数据库。我最近开始使用 Brent Ozar 的脚本并设置sp_BlitzFirst为每 15 分钟运行一次以收集等待统计信息等。

它发现的是每次运行 24 小时期间，它都告诉我修复转发记录。可能会让一些读者感到震惊的是，我在 DMV 上运行了一个查询，并取回了一些包含超过 150,000 个转发记录值的表。

我明白要解决这个问题是在整个表中有一个聚集索引，或者作为运行ALTER TABLE [tablename] REBUILD.

然而，我无法找到的是这是否会使表脱机，以及在运行此命令之前我是否应该注意其他任何问题。

我正在使用 2008 R2 的企业版，我想知道以这种方式运行它是否会消除中断的需要？

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

有人对这个有经验么？

我最近阅读了这篇关于与函数有关的性能问题的文章。

我目前正处于 Azure SQL 数据库平台上新数据库的开发阶段。它不会在新的几个月上线。我正在使用各种标量值函数，其中一个是将 UTC 转换为在配置表中指定的本地日期，例如澳大利亚东部标准时间

该函数被调用如下：

SELECT
    dbo.fnGetLocalDate(DateColumn) as DateColumn,
FROM
    table

有没有人对如何在这种情况下避免功能有任何建议？我发现它们对代码重用很有用，但我不确定如何在此处避免它。

我还想知道 vNext 是否可以解决 Azure 平台中函数的性能问题，我最好继续使用函数。

CREATE FUNCTION [dbo].[fnGetLocalDate]
(
    @DateToConvert datetimeoffset = NULL
)
RETURNS datetimeoffset
AS
BEGIN

    DECLARE @TimeZone varchar(50)

    RETURN 
    CASE 
        WHEN @DateToConvert is NULL then NULL
    ELSE 
        CONVERT(datetimeoffset, @DateToConvert AT TIME ZONE (SELECT Value FROM LookUp.Config WHERE Property = 'TimeZone'))
    END

END

我有一个包含超过 200 亿行的 SQL Server 表，最后一个分区中有 130 亿行。

该表目前按“时间”字段分为 6 种方式：

2011
2012
2013
2014
2015
2016/2017/2018

2016/2017/2018分区需要拆分成自己的分区所以有2016、2017、2018分区。

如何做到这一点并在此过程中避免大量日志文件增长？数据库处于简单恢复中，当前每个分区都位于其自己的一组磁盘上的单独文件组中。

CREATE TABLE [dbo].[Log](

      [RefNo] [nchar](7) NOT NULL,

      [DevID] [nvarchar](7) NOT NULL,

      [Time] [datetime] NOT NULL,

      [summary] [float] NULL,

      [staging] [float] NULL,

      [position] [float] NULL,

CONSTRAINT [PK_Log] PRIMARY KEY CLUSTERED

(

      [RefNo] ASC,

      [DevID] ASC,

      [Time] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 96)

)