标签: sql-server-2017

我没有想法，所以我请求你的帮助。我有一个奇怪的问题，无论我在互联网上搜索多少，都找不到原因。

问题是，我有两台笔记本电脑：

l1 : HDD 和 Kingston HyperX Fury SATA-III SSD (240G)

l2 : HDD 和三星 960 evo, nvme SSD (500G)

我有一个程序来测试数据库的性能，它从 3 个不同的表中插入、选择和删除，数量分别为 10,000 和 100,000。

l2 是在 l1 之后购买的，我尝试将 l1 上的所有内容迁移到 l2，包括数据库。运行性能程序后，我注意到一些奇怪的事情，l2 的占用量超过 l1 的占用量。例如，在表中插入 10,000 行，l1 将花费 1 秒，而 l2 将花费 28 秒。当然，我没有耐心在 l2 上尝试 100,000 次插入，而在 l1 上只需要 40 秒。

所以，我试图找到原因的根源。打开任务管理器（我使用的是 Windows 10），性能选项卡，发现当它即将插入时，SSD 的写入速度仅为 200kb/s，而 l1 的 SSD 写入速度为 4.4MB/s。

当然，我考虑到 SSD 可能被损坏的可能性，所以我使用了 3 个基准来查看。我使用的第一个是 Samsung Magician、CrystalDiskMark 和 AS SSD Benchmark。所有这 3 个基准测试都表明没有问题，我的 SSD 正在以其应有的速度工作。我必须注意，我所有的驱动程序都是最新的，而 ssd …

我从查询存储开始，它有问题:-( 没有生成 Top Resource Consuming Queries 的报告。它只是一直说“等待”几个小时和几个小时。后台查询（请参见下面的示例）不是能够完成并消耗大量 CPU。无论我如何更改配置选项，它一直在等待和等待（甚至最后一小时报告）。这是查询存储的现实吗？听起来是一个很棒的工具，但完全是实际无法使用？

我的查询存储大小约为 1.7 GB。我正在以 1 小时的间隔和自动捕获模式收集 7 天的数据 - 所以对我来说这似乎是合理的设置。

这是一个从未完成的后台查询示例：

SELECT TOP (@results_row_count)
    p.query_id query_id,
    q.object_id object_id,
    ISNULL(OBJECT_NAME(q.object_id),'') object_name,
    qt.query_sql_text query_sql_text,
    ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration,
    SUM(rs.count_executions) count_executions,
    COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
    JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
    JOIN sys.query_store_query q ON q.query_id = p.query_id
    JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time)
GROUP BY p.query_id, qt.query_sql_text, q.object_id
HAVING COUNT(distinct p.plan_id) >= 1 …

我有下表，其中有 750 万条记录：

CREATE TABLE [dbo].[TestTable](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [TestCol] [nvarchar](50) NOT NULL,
    [TestCol2] [nvarchar](50) NOT NULL,
    [TestCol3] [nvarchar](50) NOT NULL,
    [Anonymised] [tinyint] NOT NULL,
    [Date] [datetime] NOT NULL,
CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

我注意到当日期字段上有非聚集索引时：

CREATE NONCLUSTERED INDEX IX_TestTable_Date ON [dbo].[TestTable] ([Date])

- 我运行以下查询：

UPDATE TestTable 
SET TestCol='*GDPR*', TestCol2='*GDPR*', TestCol3='*GDPR*', Anonymised=1
WHERE [Date] <= …

我有一个 1 TB 的数字串。给定一个 12 个字符的数字序列，我想获取该序列在原始字符串（charindex函数）中的起始位置。

我已经使用 SQL Server 使用 1GB 字符串和 9 位子字符串对此进行了测试，并将字符串存储为varchar(max). Charindex需要 10 秒。将 1GB 字符串分解为 900 字节重叠块并创建一个表（StartPositionOfChunk、Chunkofstring），其中包含二进制排序规则的 chunkofstring，索引时间不到 1 秒。10GB,10 位子字符串的后一种方法将 charindex 提高到 1.5 分钟。我想找到一种更快的存储方法。

例子

数字串：0123456789 - 要搜索的子字符串 345
charindex('345','0123456789') 给出 4

方法 1：我现在可以将其存储在包含一列的 SQL Server 表 strtable 中colstr并执行：

select charindex('345',colstr) from strtable

方法2：或者我可以通过拆分原始字符串来组成一个表strtable2（pos，colstr1）：1;012 | 2;123 | 3;234 aso然后我们可以进行查询

select pos from strtable2 where colstr1='345'

方法 3：我可以通过将原始字符串拆分成更大的块来组成一个表strtable2 (pos2,colstr2) …

我一直在建立一个具有 SQL Server 2017 后端的概念验证系统。
系统使用临时表来记录资产配置并跟踪随时间的变化。
我有一个链接到历史记录表的数据表，我们称之为 dbo.MSSQL_TemporaryHistoryFor_12345678900。

到现在为止还挺好。我有两个问题：

今天我关闭了表格上的版本控制，所以我可以添加一个计算列。这已完成并再次打开，没有错误。

现在我发现我无法查询更改之前的任何历史数据。新数据正在添加到历史记录中，但事先什么也没有。

查看 SSMS 内部，我现在可以看到有多个历史记录表，它们都具有相同的名称但带有十六进制后缀，例如 dbo.MSSQL_TemporaryHistoryFor_12345678900_A0B1C2D3。它们未链接到主数据表下方。它们只是在数据库中自行浮动。当我查询 sys.tables 时，这些没有显示为历史表，也没有链接到主数据表。

这些表确实包含缺失的历史数据。

因此，我的问题是：

• 这些额外的表代表什么？
• 它们是如何创建的？
• 有没有办法以某种方式将这些重新链接到主历史链中，以便我可以取回我的历史报告？

这非常令人沮丧，因此我们将不胜感激地收到您能提供的任何帮助。谢谢。

我有一个具有以下结构的测试表。

CREATE TABLE [dbo].[DW_test](
[ID] [bigint] IDENTITY(1,1) NOT NULL,
[CourtCaseID] [int] NOT NULL,
[ActionID] [int] NOT NULL,
PRIMARY KEY CLUSTERED([ID] ASC)

接下来，我使用以下脚本在我的表中填充了大约 4.7 亿条记录。

insert into DW_test
--select count(*)
--from (
select top 1000000 abs(checksum(newid())) % 100000 + 1 a, abs(checksum(newid())) % 10 + 1 b
from sys.all_objects
cross join sys.all_objects a
cross join sys.all_objects b
cross join sys.all_objects c
cross join sys.all_objects d
cross join sys.all_objects e
cross join sys.all_objects f
cross join sys.all_objects g
--) t
GO

该脚本执行了大约 …

我们有一些数据库有宽表COLUMNSTORE压缩（21 或 30 COLUMNS）和 2500 个分区（按日期）。该数据库中大约有 4000 个 stats 对象，其中大部分是分区表上的 INCREMENTAL 列统计信息。

sys.dm_db_stats_properties在这些数据库上运行时，这个表函数的性能极差。我们正在查看每行大约 1 秒 - 即此表函数的每次“运行”。

下面是一个简单查询生成的查询计划示例，其CROSS APPLY语法用于针对 1605 个 stats-table 组合执行此表函数。

这里没有什么非常有帮助的 - DMV 的表现显然很差。

我目前的理论是，由于数据库中统计对象的性质，对 OPENROWSET 内部表的查询优化不佳（可能是TOP 1，这就是导致速度变慢的原因。

CREATE FUNCTION sys.dm_db_stats_properties (@object_id int, @stats_id int)
RETURNS TABLE
AS
RETURN SELECT TOP 1 -- The first row in the TVF will be the root; avoid scanning entire TVF to find any additional rows.
    object_id, -- Columns now explicit since underlying tvf …

我有两个表，每个表包含 2 亿条记录。我必须根据列中的整数值从它们中删除大约 7000 万条记录。

我使用以下脚本以 4000 块为单位删除它们：

DECLARE @BATCHSIZE INT, @ITERATION INT, @TOTALROWS INT, @MSG VARCHAR(500)
DECLARE @STARTTIME DATETIME, @ENDTIME DATETIME

SET NOCOUNT ON;
SET DEADLOCK_PRIORITY LOW;
SET @BATCHSIZE = 4000
SET @ITERATION = 0 
SET @TOTALROWS = 0 

WHILE @BATCHSIZE>0
BEGIN   
    SET @STARTTIME = GETDATE();

    BEGIN TRANSACTION
    DELETE TOP(@BATCHSIZE)
    FROM [mydb].[dbo].tableA 
    WHERE [mydb].[dbo].tableA.Code not IN (
            SELECT Code
            FROM [mydb].[dbo].TableB)

    SET @BATCHSIZE=@@ROWCOUNT
    SET @ITERATION=@ITERATION+1
    SET @TOTALROWS=@TOTALROWS+@BATCHSIZE
    COMMIT TRANSACTION;

    SET @ENDTIME = GETDATE();

    SET @MSG = 'Iteration: ' + …

我有一个 SSIS 包的问题，​​当通过 VS2017 部署到集成服务目录时，实际上并未部署。这是一个单独的包部署，而不是一个项目部署。没有错误消息，部署似乎顺利进行。检查初始包和项目表表明虽然部署已经发生（项目时间戳被更新），但最新版本的包代码尚未真正部署，因为包表上的版本号与 Visual 中的最新版本不匹配工作室。

事实上，这个问题与另一位成员在之前的帖子中描述的完全一样，只是没有对该帖子的决议进行更新。我希望其他人可能遇到过这种情况。

为什么我的 SSIS 包没有更新？

一些可能有帮助的附加信息：

右键单击，项目部署 - 这有效（我们已经在另一个项目中尝试过这个，尽管对于我们真正感兴趣的项目，我们不能这样做，因为并非所有的包都准备好在项目级别进行部署）。

右键单击，包部署 - 这不起作用（部署报告为成功，但显然包尚未部署）。

从命令行为相关包调用 ISDeploymentWizard 也不起作用。同样，没有报告错误，但没有部署任何内容。

通过 Visual Studio 使用向导时，您可以在所有阶段保存部署后报告“成功”的 XML。

谢谢你。

我正在尝试在我的 SQL 服务器上激活高可用性并收到以下消息：

SQL 服务器版本：Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64) 2017 年 8 月 22 日 17:04:49 版权所有 (C) 2017 Microsoft Corporation Express Edition（64 位），Windows Server 2012 R2 Datacenter 6.3（Build 9600） :)（管理程序）

操作系统：windows server 2012。

感谢任何帮助。