Questions tagged «sql-server-2017»

SQL Server 2017(主要版本14.00.xxxx)。还请标记sql-server。

4
帮助安装SQL Server 2017-VS Shell安装失败,退出代码为1638
关于如何处理此错误的任何建议: TITLE: Microsoft SQL Server 2017 Setup ------------------------------ The following error has occurred: VS Shell installation has failed with exit code 1638. For help, click: https://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.1000.169&EvtType=0x5B39C8B9%25401434%25403 ------------------------------ BUTTONS: OK ------------------------------ 这是一台正在运行的新笔记本电脑 SQL Server 2016 Express Visual Studio 2017 SSMS 2017 我尝试卸载与SQL Server或Visual Studio相关的所有内容。 日志:[3500:3970] [2017-11-03T16:25:20] e000:错误0x80070666:在安装较新版本时无法安装产品。 Detailed results: Feature: Full-Text …

2
为什么更改声明的连接列顺序会引入排序?
我有两个表,它们具有相同的命名,类型和索引键列。其中一个具有唯一的聚集索引,另一个具有非唯一索引。 测试设置 设置脚本,包括一些实际的统计信息: DROP TABLE IF EXISTS #left; DROP TABLE IF EXISTS #right; CREATE TABLE #left ( a char(4) NOT NULL, b char(2) NOT NULL, c varchar(13) NOT NULL, d bit NOT NULL, e char(4) NOT NULL, f char(25) NULL, g char(25) NOT NULL, h char(25) NULL --- and a …

1
如何在SQL Server 2017中使用SNAPSHOT_MATERIALIZATION创建视图?
SQL Server 2017有几个新的存储过程: sp_refresh_single_snapshot_view – @view_name nvarchar(261),@ rgCode int的输入参数 sp_refresh_snapshot_views – @rgCode int的输入参数 以及sys.messages中的新条目: 10149 –无法在视图'%。* ls'上创建具有SNAPSHOT_MATERIALIZATION的索引,因为视图定义包含内存优化表。 10642 –无法为'%。* ls'上的索引'%。* ls'设置SNAPSHOT_MATERIALIZATION,因为它仅适用于视图上的索引。 10643 –不能在'%。* ls'上为'%。* ls'设置SNAPSHOT_MATERIALIZATION,因为它仅适用于视图上的聚集索引。 10648 –无法为'%。* ls'上的分区索引'%。* ls'设置SNAPSHOT_MATERIALIZATION。 10649 –无法在具有SNAPSHOT_MATERIALIZATION的聚集索引'%。* ls'的'%。* ls'上创建非聚集索引'%。* ls'。 10650 –刷新快照视图要求在数据库上启用快照隔离。 3760 –无法在具有SNAPSHOT_MATERIALIZATION的视图'%。* ls'上删除索引'%。* ls'。 4524 –无法更改视图'%。* ls',因为它具有快照实现。 4525 –刷新视图之前,无法在具有快照实现的视图'%。* ls'上使用提示'%ls'。 以及新的扩展事件: 那么我们如何创建快照实现的视图呢?(显然,Microsoft尚未对此进行记录。)这是我迄今为止尝试过但仍未奏效的要点。

6
在整个数据库中更改GETDATE()的使用
我需要将本地SQL Server 2017数据库迁移到Azure SQL数据库,并且由于要克服很多限制,因此我面临一些挑战。 特别是,由于Azure SQL数据库仅在UTC时间(无时区)工作,并且我们需要本地时间,因此我们必须更改数据库中GETDATE() 所有地方的使用方式,事实证明,这比我预期的要多。 我创建了一个用户定义的函数,以获取在我的时区正确工作的本地时间: CREATE FUNCTION [dbo].[getlocaldate]() RETURNS datetime AS BEGIN DECLARE @D datetimeoffset; SET @D = CONVERT(datetimeoffset, SYSDATETIMEOFFSET()) AT TIME ZONE 'Pacific SA Standard Time'; RETURN(CONVERT(datetime,@D)); END 我遇到的问题是实际上GETDATE()在每个视图,存储过程,计算列,默认值,其他约束等中都使用此函数进行了更改。 实施此更改的最佳方法是什么? 我们正在受管实例的公开预览中。与仍然存在相同的问题GETDATE(),因此对解决此问题没有帮助。迁移到Azure是必需的。始终在该时区使用(并将使用)此数据库。

1
由于文件路径错误,备份时SQL Server 2017崩溃
我试图还原数据库,而SQL Server一直崩溃。我会在SSMS中收到一条消息,说存在网络传输错误(由于崩溃导致连接断开)。我检查了日志,发现没有什么比SQL Server意外关闭更重要。然后,我将不得不重新启动该服务。 我将问题缩小到GUI试图运行的脚本。问题是当进行尾日志备份时,备份文件的路径错误。它应该是D:\mapbenefits\... BACKUP LOG [mapbenefits] TO DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak' WITH NOFORMAT, NOINIT, NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24', NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY , STATS = 5 我有两个问题。 如何解决此问题?我尝试进入服务器设置,并且备份路径D:没有斜杠。如果我添加斜杠,则gui会将其删除。这是SSMS v17.9.1。我可以选择,D:\mapbenefits\并且可以,但是我想要D:\DATABASE\... 这是错误吗?SQL服务器是否应该仅由于路径输入错误而崩溃?修复文件路径后,它就没有问题了。我可以随时通过复制文件路径来重现。 如果我运行查询以检查版本,则会得到CU13,但是如果进入设置,则会看到版本14.0.1000.169。 看起来这是一个错误并且可以复制,所以我将其发布到了这里:https : //feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command-原因

1
添加选择时超出自引用标量函数嵌套级别
目的 尝试创建自引用功能的测试示例时,一个版本失败,而另一个版本成功。 唯一的区别是添加SELECT到功能主体上,导致两者的执行计划不同。 起作用的功能 CREATE FUNCTION dbo.test5(@i int) RETURNS INT AS BEGIN RETURN( SELECT TOP 1 CASE WHEN @i = 1 THEN 1 WHEN @i = 2 THEN 2 WHEN @i = 3 THEN dbo.test5(1) + dbo.test5(2) END ) END; 调用函数 SELECT dbo.test5(3); 退货 (No column name) 3 该功能不起作用 CREATE …

4
如果数据库只有一个插入,那么索引每个可能的列组合是否不好?
我正在一个需要大量选择查询的报表系统上工作,但是该报表系统基于仅填充一次的数据库。数据库管理系统是Microsoft SQL Server2017。可能有更好的方法来设计这样的系统,但让我们从理论上解决这个问题。 从理论上讲: 如果我们有一个非常大的数据库(几张表上有1.5亿行) 我们可以假设数据库只会被填充一次。 索引每个可能的列组合是否会对选择查询产生负面的性能影响?

3
服务器重新启动后,SQL Server分布式可用性组数据库未同步
我们已经准备好在SQL Server上执行大型升级,并注意到我正在尝试解决的Distributed Availability Groups的一些异常行为,然后再进行下一步。 上个月,我将远程辅助服务器从SQL Server 2016升级到SQL Server2017。该服务器是多个分布式可用性组(DAG)和单独的可用性组(AG)的一部分。升级该服务器时,我们没有意识到它会进入无法读取的状态,因此在过去的一个月中,我们仅依赖主服务器。 作为即将进行的升级的一部分,我将CU 4修补程序应用于服务器并重新启动了它。当服务器重新联机时,刚刚打补丁的辅助服务器显示所有DAG / AG都在同步,没有任何问题。 但是,小学的故事却截然不同。据报道 单独的AG正在同步,没有任何问题 但是DAG处于“ 不同步/不正常”状态 最初出现恐慌之后,我尝试了以下操作以使DAG中的内容再次同步: 从主服务器开始,我停止并恢复了数据移动。这没有开始同步数据。 在第二个(我刚刚打过补丁的)上,我运行了ALTER DATABASE [<database] SET HADR RESUME;-执行时没有错误,但是没有恢复任何同步 我最后一次再次同步数据的尝试是登录到辅助数据库,然后手动重新启动SQL Server服务。手动重新启动服务似乎有些极端,因为我希望重新启动服务器就足够了。 是否有人遇到过重启后DAG无法开始同步到辅助服务器的问题?如果是这样,如何解决? 我同时检查了SQL Server错误日志和辅助服务器上的事件查看器,没有发现异常。



4
SQL Server发生I / O请求的时间超过15秒
在生产SQL Server上,我们具有以下配置: 将3台Dell PowerEdge R630服务器组合到可用性组中,所有3台都连接到单个RAID SAN存储单元,该存储单元是一个RAID阵列 有时,在PRIMARY上,我们会看到类似以下的消息: SQL Server在数据库ID 8 的文件[F:\ Data \ MyDatabase.mdf]中遇到11次I / O请求,而这些请求花费的时间超过15秒。OS文件句柄为0x0000000000001FBC。 最新的长I / O的偏移量是:0x000004295d0000。 长I / O的持续时间为:37397毫秒。 我们是性能故障排除的新手 解决与存储相关的特定问题的最常用方法或最佳做法是什么?必须使用哪些性能计数器,工具,监视器,应用程序等来缩小此类消息的根本原因?可能会有可以提供帮助的扩展事件,或者某种审计/日志记录?

5
尝试回收未使用的空间会导致已用空间在SQL Server中显着增加
我在生产数据库中有一个表,该表的大小为525 GB,其中383 GB未使用: 我想回收一些空间,但是在弄乱生产数据库之前,我正在用较少数据的测试数据库中的同一表上测试一些策略。该表有一个类似的问题: 有关表的一些信息: 填充因子设置为0 大约有30列 列之一是图像类型的LOB,它存储的文件大小从几KB到几百MB不等 该表没有任何与之相关的假设索引 服务器正在运行SQL Server 2017(RTM-GDR)(KB4505224)-14.0.2027.2(X64)。数据库正在使用SIMPLE恢复模型。 我尝试过的一些事情: 重建索引: ALTER INDEX ALL ON dbo.MyTable REBUILD。这产生的影响可以忽略不计。 重组索引:ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON)。这产生的影响可以忽略不计。 将LOB列复制到另一个表,删除该列,重新创建该列,然后将数据复制回(如本文章中概述的:释放未使用的空间SQL Server表)。这减少了未使用的空间,但似乎只是将其转换为已用空间: 使用了bcp实用程序来导出表,截断表并重新加载表(如本文所述:如何为表释放未使用的空间)。这也减少了未使用的空间,并将使用的空间增加到与上述图像相似的程度。 即使不建议这样做,我也尝试了DBCC SHRINKFILE和DBCC SHRINKDATABASE命令,但是它们对未使用的空间没有任何影响。 跑步 DBCC CLEANTABLE('myDB', 'dbo.myTable')并没有改变 在保持图像和文本数据类型以及将数据类型更改为varbinary(max)和varchar(max)之后,我都尝试了上述所有方法。 我尝试将数据导入到新数据库中的新表中,这也仅将未使用的空间转换为已用空间。我在这篇文章中概述了这种尝试的细节。 如果我期望这些结果,我不想在生产数据库上进行这些尝试,因此: 为什么将其中一些尝试之后的未使用空间仅转换为已用空间?我觉得我不太了解幕后发生的事情。 我还能做些其他事情来减少未使用的空间而不增加已使用的空间吗? 编辑:这是表的磁盘使用情况报告和脚本: SET ANSI_NULLS ON GO SET …

2
具有500个数据库的SQL Server 2017-自CU9起频繁的AG断开连接
大家好,在此先感谢您的帮助。SQL Server 2017可用性组面临挑战。 背景 公司是零售B2B后端软件。大约500个单租户数据库,以及所有租户使用的5个共享数据库。工作负载特征读取最多,大多数数据库的活动很少。 托管在同一地点的物理生产服务器最近从Windows Server 2012上的SQL Server 2014 Enterprise在共享SAN / FCI配置中升级到Windows Server 2016上的SQL Server 2017 Enterprise(2插槽/ 32核/ 768 GB RAM和本地)使用AlwaysOn AG的SSD驱动器。AG业务使用带交叉电缆连接的专用10G NIC端口。 他们的要求是所有数据库都一起进行故障转移,因此他们不得不将它们全部放在一个AG中。它是同一服务器上的单个不可读取的同步副本。 新服务器已于2018年6月投入生产。安装了最新的CU(当时为CU7)和Windows更新,并且系统运行良好。大约一个月后,在将服务器从CU7更新到CU9之后,他们开始注意到以下挑战,按优先顺序列出。 我们一直在使用SQL Sentry监视服务器,没有发现物理瓶颈。所有关键指标似乎都不错。CPU平均为20%,IO时间通常小于1ms,RAM未被充分利用,并且网络<1%。 挑战性 故障转移后,症状似乎会好转,但几天后又回来了,不管哪个服务器是主要服务器-两个服务器上的症状都相同。 零星的客户端超时和连接故障,例如 建立连接时发生错误 要么 执行超时已过期 有时这些会持续40秒钟,然后消失。 事务日志备份作业完成的时间比以前长10倍。以前备份所有500个数据库的日志需要2到3分钟,现在备份需要15到25分钟。我们已经验证了备份本身可以很好地运行并具有良好的吞吐量。但是,在完成一个日志的备份之后和启动下一个日志之前会有一个小的延迟。它开始时非常低,但是在一两天内会达到2-3秒。乘以500个数据库,便有区别。 有时,一些看似随机的数据库在手动故障转移后会陷入“未同步”状态。解决此问题的唯一方法是在辅助副本上重新启动SQL Server服务,或者将这些数据库删除并重新加入AG。 CU10引入的另一个问题(在CU11中未解决):在master.sys.databases上阻塞时,辅助超时的连接,甚至无法将SSMS对象资源管理器用于辅助副本。根本原因似乎是由Microsoft SQL Server VSS编写器发出以下查询阻止的: select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from …

1
直方图以外的基数估计
设定 我在了解基数估算值时遇到了一些麻烦。这是我的测试设置: 2010版本的Stack Overflow数据库 SQL Server 2017 CU15 + GDR(KB4505225)-14.0.3192.2 新CE(兼容级别140) 我有这个过程: USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO dbo.Posts表上没有非聚集索引或统计信息(上有聚集索引Id)。 当要求为此的估计计划时,出来的“估计行” dbo.Posts为1,934.99: EXEC #sp_PostsByCommentCount @CommentCount = 51; 当我要求估算的计划时,会自动创建以下统计信息对象: DBCC SHOW_STATISTICS('dbo.Posts', [_WA_Sys_00000006_0519C6AF]); 其中的重点是: …

2
为什么临时表比急切的线轴更有效地解决万圣节问题?
考虑以下查询,该查询仅在源表中的行尚未插入目标表中时才插入它们: INSERT INTO dbo.HALLOWEEN_IS_COMING_EARLY_THIS_YEAR WITH (TABLOCK) SELECT maybe_new_rows.ID FROM dbo.A_HEAP_OF_MOSTLY_NEW_ROWS maybe_new_rows WHERE NOT EXISTS ( SELECT 1 FROM dbo.HALLOWEEN_IS_COMING_EARLY_THIS_YEAR halloween WHERE maybe_new_rows.ID = halloween.ID ) OPTION (MAXDOP 1, QUERYTRACEON 7470); 一种可能的计划形状包括合并联接和渴望的线轴。热心的线轴操作员出席以解决万圣节问题: 在我的计算机上,以上代码在大约6900毫秒内执行。问题的底部包括创建表的Repro代码。如果我对性能不满意,则可以尝试加载要插入到临时表中的行,而不是依赖急切的假脱机。这是一种可能的实现: DROP TABLE IF EXISTS #CONSULTANT_RECOMMENDED_TEMP_TABLE; CREATE TABLE #CONSULTANT_RECOMMENDED_TEMP_TABLE ( ID BIGINT, PRIMARY KEY (ID) ); INSERT INTO #CONSULTANT_RECOMMENDED_TEMP_TABLE …

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.