Questions tagged «sql-server»

所有版本的Microsoft SQL Server(非MySQL)。还请添加特定于版本的标记,例如sql-server-2016,因为它通常与问题相关。

7
在SQL Server 2005上获取最少的多列的最有效方法是什么?
我要从6列中获取最小值。 到目前为止,我已经找到了三种方法来实现此目的,但是我对这些方法的性能感到担忧,并且想知道哪种方法对性能更好。 第一种方法是使用大写语句。这是一个包含3列的示例,基于上面链接中的示例。我的案例陈述将更长,因为我将查看6列。 Select Id, Case When Col1 <= Col2 And Col1 <= Col3 Then Col1 When Col2 <= Col3 Then Col2 Else Col3 End As TheMin From MyTable 第二种选择是将UNION运算符与多个select语句一起使用。我将其放在接受Id参数的UDF中。 select Id, dbo.GetMinimumFromMyTable(Id) from MyTable 和 select min(col) from ( select col1 [col] from MyTable where Id = @id union …

2
有没有一种方法可以防止计算列中的标量UDF抑制并行性?
关于SQL Server 中标量UDF的危害,已经写了很多文章。随意搜索将返回大量结果。 但是,在某些地方,标量UDF是唯一的选择。 例如:在处理XML时:XQuery不能用作计算列定义。Microsoft记录的一个选项是使用Scalar UDF将XQuery封装在Scalar UDF中,然后在计算列中使用它。 这会产生各种影响,并有一些解决方法。 查询表时逐行执行 强制对表的所有查询顺序运行 您可以通过模式绑定该函数并持久保存计算的列或对其进行索引来解决逐行执行的问题。即使没有引用标量UDF,这两种方法都无法防止查询的强制序列化。 有已知的方法吗?

1
有哪些客观原因会首选SQL Server 2016而不是早期版本?
自从SQL Server 2005或2008年以来,由于Microsoft更加频繁地进行SQL Server版本升级,因此许多公司发现很难确定何时必须进行升级!而升级是“不错的选择” 本着一些以前的问题的精神,他们问为什么比以前的版本更喜欢各种SQL Server的较新版本,公司可能会考虑一些客观的技术或业务原因,以便公司将SQL Server 2016升级到较早的版本,甚至更高的版本。发布,例如SQL Server 2014? (关于SQL Server 2012与SQL Server 2008相比的这个问题,或者关于SQL Server 2012与SQL Server 2005相比的一个问题,就是这个问题的精神的示例。它们的答案还扩展了此处的一些原因。 SQL Server 2008或SQL Server 2005开始的公司)


5
将备份还原到旧版本的SQL Server
尝试将备份还原到SQL Server Express 2008数据库时,出现以下错误: Restore failed for Server '...\SQLEXPRESS'. (Microsoft.SqlServer.SmoExtended) System.Data.SqlClient.SqlError: The database was backed up on a server running version 10.50.1600. That version is incompatible with this server, which is running version 10.00.2531. Either restore the database on a server that supports the backup, or use a backup that …

2
将SQL Server实例根目录放在单独的驱动器上是否有用?
我知道在安装SQL Server时可以更改许多默认路径,通常在安装时,我将数据和日志文件夹更改为单独的驱动器(通常为D和E),但是最近我得到了一个预安装的计算机正在运行实例名称(而不是默认名称),并且他们已将实例根目录与mdf文件一起配置在D驱动器上。这意味着在通常只有一个文件夹和数据库文件的相对干净的驱动器上,我现在也已经完全安装了SQL Server二进制文件。 即我现在有以下内容: C:\Program Files\Microsoft SQL Server\ --Base Install D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files 通常我会在类似的地方运行: C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries D:\MSSQL\DATA --Data Files E:\MSSQL\LOGS --Log Files 我可以理解为什么有必要使用单独的实例二进制文件夹,但是我看不到为什么将所有这些二进制文件放在单独的驱动器上会很有用。 谁能告诉我为什么这样做是合理的?也许这根本没有什么不同?对我来说,这似乎很不整洁。

2
为什么GROUP BY语句中的通配符不起作用?
我正在尝试使以下SQL语句正常工作,但出现语法错误: SELECT A.*, COUNT(B.foo) FROM TABLE1 A LEFT JOIN TABLE2 B ON A.PKey = B.FKey GROUP BY A.* 在这里,A是一个有40列的宽表,如果可能的话,我想避免在GROUP BY子句中列出每个列的名称。我有很多这样的表,必须在这些表上运行类似的查询,因此我必须编写一个存储过程。解决此问题的最佳方法是什么? 我正在使用MS SQL Server 2008。


3
我应该使用哪种PowerShell技术与SQL Server通讯?
我最终希望使用PowerShell替换用于SQL实例监视器的旧KornShell脚本。但是,我很难过,无法理解PowerShell可以与SQL Server实际进行通信的所有不同方式。不确定是否全部都是这些,但是这里有5种完全不同的方式可以查询SQL Server的版本: 1. SQLConnection .NET类 $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionString = "Server=MyServer;Database=Master;Integrated Security=True" $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlCmd.CommandText = "Select @@version as SQLServerVersion" $SqlCmd.Connection = $SqlConnection $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $SqlAdapter.SelectCommand = $SqlCmd $DataSet = New-Object System.Data.DataSet $SqlAdapter.Fill($DataSet) $SqlConnection.Close() $DataSet.Tables[0] 2. WMI提供者 $sqlProperties = Get-WmiObject -computerName "MyServer" -namespace root\Microsoft\SqlServer\ComputerManagement10 …

5
删除/插入时,对同一排他锁定的集群键(使用NHibernate)上的SQL死锁
我已经在这个僵局问题上研究了好几天了,无论我做什么,它都会以一种或多种方式持续存在。 首先,一般的前提是:我们具有与VisitItems具有一对多关系的Visits。 VisitItems相关信息: CREATE TABLE [BAR].[VisitItems] ( [Id] INT IDENTITY (1, 1) NOT NULL, [VisitType] INT NOT NULL, [FeeRateType] INT NOT NULL, [Amount] DECIMAL (18, 2) NOT NULL, [GST] DECIMAL (18, 2) NOT NULL, [Quantity] INT NOT NULL, [Total] DECIMAL (18, 2) NOT NULL, [ServiceFeeType] INT NOT NULL, [ServiceText] NVARCHAR …

4
我怎样才能知道为什么在某个表上插入会很慢?
我知道,出于多种原因,在SQL表上执行INSERT操作可能会很慢: 桌子上是否存在INSERT TRIGGER 许多必须检查的强制约束(通常是外键) 当在表的中间插入一行时,页面在聚集索引中拆分 更新所有相关的非聚集索引 阻止桌面上的其他活动 IO写响应时间差 ...我错过了什么? 如何确定我的具体情况中哪个责任人?如何衡量分页与非聚集索引更新与其他所有内容的影响? 我有一个存储的过程,一次插入大约10,000行(从临时表中),每10k行大约需要90秒。这太慢了,因为它会导致其他sps超时。 我已经查看了执行计划,并且看到了INSERT CLUSTERED INDEX任务和FK查找中的所有INDEX SEEKS,但仍不能确定为什么要花这么长时间。没有触发器,但是表中确实有少数FKey(似乎已正确索引)。 这是一个SQL 2000数据库。

10
如何获得夏令时之前或之后的某个日期的UTC与当地时间之间的正确偏移量?
我目前使用以下方法从UTC日期时间获取本地日期时间: SET @offset = DateDiff(minute, GetUTCDate(), GetDate()) SET @localDateTime = DateAdd(minute, @offset, @utcDateTime) 我的问题是,如果夏令时发生在GetUTCDate()和之间@utcDateTime,那么@localDateTime最终会减少一个小时。 是否有简单的方法可以将utc转换为非当前日期的本地时间? 我正在使用SQL Server 2005

4
使用SQL CLR标量函数模拟HASHBYTES的可伸缩方法是什么?
作为ETL流程的一部分,我们将暂存中的行与报表数据库进行比较,以找出自从上次加载数据以来是否实际更改了任何列。 比较是基于表的唯一键和所有其他列的某种哈希值。我们目前使用HASHBYTES该SHA2_256算法,并且发现如果许多并发工作线程都在调用,则该算法无法在大型服务器上扩展HASHBYTES。 在96台核心服务器上进行测试时,以每秒哈希数衡量的吞吐量不会增加超过16个并发线程。我通过将并发MAXDOP 8查询数从1 更改为12进行测试。测试MAXDOP 1显示了相同的可伸缩性瓶颈。 作为一种解决方法,我想尝试一个SQL CLR解决方案。这是我尝试陈述要求的尝试: 该功能必须能够参与并行查询 函数必须是确定性的 该函数必须接受NVARCHAR或VARBINARY字符串的输入(所有相关列都串联在一起) 字符串的典型输入大小为100-20000个字符。20000不是最大值 哈希冲突的机会应大致等于或优于MD5算法。CHECKSUM对我们不起作用,因为有太多的碰撞。 该功能必须在大型服务器上很好地扩展(随着线程数量的增加,每个线程的吞吐量不应显着降低) 对于Application Reasons™,假定我无法保存报表的哈希值。这是一个不支持触发器或计算列的CCI(还有其他我不想讨论的问题)。 HASHBYTES使用SQL CLR函数进行仿真的可扩展方式是什么?我的目标可以表示为在大型服务器上每秒获得尽可能多的哈希,因此性能也很重要。我对CLR感到很糟糕,所以我不知道该如何完成。如果它激励任何人回答,我计划在可能的情况下尽快为这个问题添加赏金。下面是一个示例查询,它非常粗略地说明了用例: DROP TABLE IF EXISTS #CHANGED_IDS; SELECT stg.ID INTO #CHANGED_IDS FROM ( SELECT ID, CAST( HASHBYTES ('SHA2_256', CAST(FK1 AS NVARCHAR(19)) + CAST(FK2 AS NVARCHAR(19)) + CAST(FK3 AS NVARCHAR(19)) + CAST(FK4 AS NVARCHAR(19)) + …

4
如何找出谁删除了一些SQL Server数据
我的老板昨天从一个客户那里询问,询问他们如何找到谁删除了他们在SQL Server数据库中的某些数据(如果重要的话,这是速成版)。 我以为可以从事务日志中找到它(假设它没有被截断)-这正确吗?如果是这样,您实际上将如何找到这些信息?

1
全文索引维护准则
维护全文索引应考虑哪些准则? 我应该重新构建或重新组织全文目录(请参阅BOL)吗?什么是合理的维护节奏?可以使用什么启发式方法(类似于10%和30%的碎片阈值)来确定何时需要维护? (下面的所有内容只是有关此问题的详尽信息,并显示了我到目前为止的想法。) 额外信息:我的初步研究 有关b树索引维护的资源很多(例如,该问题,Ola Hallengren的脚本以及其他站点上有关该主题的大量博客文章)。但是,我发现这些资源都没有提供用于维护全文索引的建议或脚本。 有微软的文档是提到整理基表的B树索引,然后对全文目录执行REORGANIZE可以提高性能,但它并没有任何更具体的建议碰。 我也发现了这个问题,但它主要集中在变更跟踪(如何将对基础表的数据更新传播到全文索引中),而不是可以最大程度地提高索引效率的定期维护类型。 额外信息:基本性能测试 此SQL Fiddle包含可用于创建具有AUTO更改跟踪的全文本索引的代码,并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本(而不是小提琴中的人造数据)上运行脚本的逻辑时,以下是在每个数据修改步骤之后看到的结果的摘要: 即使此脚本中的update语句设计得相当不错,但这些数据似乎表明定期维护有很多好处。 额外信息:初步构想 我正在考虑创建每晚或每周的任务。看来此任务可以执行REBUILD或REORGANIZE。 因为全文索引可能非常大(数以千万计的行),所以我希望能够检测目录中的索引何时足够零散,以确保需要进行REBUILD / REORGANIZE。对于哪种启发式方法可能有意义,我还不清楚。

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.