Questions tagged «sql-server»

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

3
在SAN环境中对SQL索引进行碎片整理有什么好处？
我们的SQL服务器位于SAN上。它包含数十个OLTP数据库，其中一些数据库包含100万条以上的记录。 我们每周运行Ola Hallengren的索引维护脚本，并且每次运行几个小时。根据碎片阈值，脚本将重新组织索引或为索引重新编制索引。我们已经观察到，在重新索引期间，日志文件会变得很大，这会导致日志传送过程中带宽的过度消耗。 然后是Brent Ozar的一篇文章，他说不再停止担心SQL索引： 您的硬盘驱动器与其他同时共享驱动器请求的服务器共享，因此驱动器将始终在各处跳跃以获取数据。整理索引碎片只是毫无意义的繁忙工作。 谷歌搜索这个问题会导致意见分歧，其中大多数观点似乎太简短或太弱。我们的暂定计划是调整维护脚本中的碎片阈值，以使其重新组织的频率比重新编制索引的频率高得多。 最终裁决是什么？考虑到每周运行维护工作所带来的负担，是否值得对SAN上的SQL索引进行碎片整理？
3
SQL Server LocalDB实例；恢复备份时出错（MasterDBPath不可用）
我已经安装了SQL Server 2012本地数据库，并且正在通过（localdb）\ v11.0连接到它。 尝试还原备份文件时，我得到： 标题：Microsoft SQL Server Management Studio 属性MasterDBPath不可用于信息'Microsoft.SqlServer.Management.Smo.Information'。该属性对于该对象可能不存在，或者由于访问权限不足而无法检索。（Microsoft.SqlServer.Smo） 要获取帮助，请单击：http : //go.microsoft.com/fwlink？ .PropertyCannotBeRetrievedExceptionText＆EvtID = MasterDBPath＆LinkId = 20476 我尝试在以下位置设置MasterDBPath字符串值： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\CurrentVersion` 但这没有帮助。 有人有什么想法吗？
16 sql-server 
2
SQL Server-增长数据库文件的最佳实践
我已经通过SQL Server 2008 R2中的数据收集器监视文件增长了两个星期。该数据库以每天约35（MB）的速度持续增长。该数据库尚未达到2 GB的初始大小。 数据库文件的自动增长设置为5MB，我想尝试另一种方法，所以我正在寻找建议和/或评论。 每个星期天晚上1:30 AM都会运行一项调优任务。该任务将： 检查数据库完整性 缩小日志文件–（可以，因为日志记录模式很简单） 收缩数据库 重组索引 重建索引 更新统计 清理历史 我想在每周调整计划中增加两个步骤： 如果使用的空间达到某个阈值或总大小，则将数据库文件增加500 MB。 如果使用的空间达到总大小的特定阈值，则将日志文件增加250 MB（缩小后）。 通过将增长负担放在离线时间，我希望通过减少重负载下的自动增长事件的数量来提高性能。 我有两个有关自动增长文件的问题。 放置文件增长步骤的最佳位置是在当前步骤之前还是之后？ 如果我使用ALTER DATABASE|MODIFY FILE来增大文件，那么如何确定是否SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)呢？
2
SQL Server数据工具和分区功能
我正在创建一个滑动窗口加载方案，并且分区功能将随着时间改变其边界。 我已经在SQL Server数据工具（SSDT）数据库项目中创建了一些分区功能，并使用一些硬编码的初始边界。 但是，随着时间的流逝以及分区功能的边界发生变化，未来的SSDT数据库发布会将边界恢复为原始边界。 是否有某种方法可以通过禁用分区功能的发布来优雅地处理此情况？ 我尝试将SSDT中分区功能的Build Action属性从default更改Build为None，但是由于依赖对象中缺少引用，因此项目无法构建。
16 sql-server 
1
使用RECOMPILE查询提示时查询之间执行时间的巨大差异
我在同一SQL Server 2005实例上运行两个几乎相同的查询： 第一个是SELECTLINQ生成的原始查询（我知道，我知道...我不是应用程序开发人员，只是DBA :)。 第二个与第一个完全相同，最后添加一个OPTION (RECOMPILE)。 没有其他改变。 第一次运行需要55秒。 第二个需要2秒。 两个结果集是相同的。 为什么这个提示会带来如此惊人的性能提升？ 的在线丛书条目RECOMPILE未提供详细的解释： 指示SQL Server数据库引擎在执行后放弃为查询生成的计划，从而迫使查询优化器在下次执行同一查询时重新编译查询计划。在不指定RECOMPILE的情况下，数据库引擎缓存查询计划并重新使用它们。编译查询计划时，RECOMPILE查询提示将使用查询中任何局部变量的当前值；如果查询在存储过程中，则将当前值传递给任何参数。 当只需要重新编译存储过程中的一部分查询而不是整个存储过程时，RECOMPILE是创建使用WITH RECOMPILE子句的存储过程的有用替代方法。有关更多信息，请参见重新编译存储过程。创建计划指南时，RECOMPILE也很有用。有关更多信息，请参见使用计划指南优化已部署应用程序中的查询。 由于我的查询有很多局部变量，因此我猜测当我使用OPTION (RECOMPILE)查询提示时，SQL Server能够（严重）优化它。 我到处看的人都说OPTION (RECOMPILE)应该避免。对此的解释通常是，使用此提示，SQL Server无法重用此执行计划，因此必须浪费时间每次重新编译它。（但是）鉴于巨大的性能优势，我倾向于认为这次使用此查询提示将是一件好事。 我应该使用它吗？如果没有，是否有一种方法可以强制SQL Server在没有此提示且不更改应用程序的情况下使用更好的执行计划？
5
测试是否有任何列为NULL
我试图找出一个简单的查询，我可以测试一个大表是否具有在ANY列中至少具有一个空白（NULL /空）值的条目列表。 我需要类似的东西 SELECT * FROM table AS t WHERE ANY(t.* IS NULL) 我不想做 SELECT * FROM table AS t WHERE t.c1 = NULL OR t.c2 = NULL OR t.c3 = NULL 这将是一个巨大的查询。
2
使用动态SQL在指定的数据库中创建视图？
我正在写一个动态sql，以在不同的数据库中删除并创建视图。 所以我写道： set @CreateViewStatement = ' USE ['+ @DB +']; CREATE VIEW [dbo].[MyTable] AS SELECT ........something exec (@CreateViewStatement) 它给我错误： “ CREATE VIEW”必须是查询批处理中的第一条语句。 如果我删除USE DATABASE语句，它可以正常工作，但是不再指定数据库了。 我怎么解决这个问题？
2
检索日期范围的最有效方法
用这种表结构检索日期范围的最有效方法是什么？ create table SomeDateTable ( id int identity(1, 1) not null, StartDate datetime not null, EndDate datetime not null ) go 假设您要同时为StartDate和设置一个范围EndDate。因此，换句话说，如果StartDate介于@StartDateBegin和之间@StartDateEnd，并且EndDate介于@EndDateBegin和之间@EndDateEnd，则执行某些操作。 我知道有几种方法可以解决此问题，但是最建议的是什么？
7
这些表设计中哪一个对性能更好？
我被要求创建一些东西来跟踪每天在帐户上收取的费用，而我正在尝试找出一个支持此目的的数据库表模式。 这就是我所知道的 公司拥有超过250万个帐户 其中，他们目前平均每月工作200,000（随着人员配备水平的变化而变化，目前水平很低） 他们想跟踪13种不同的费用类型，并且警告说，将来可能会增加更多的费用 他们希望每天跟踪费用 成本不会在整个库存中分配。它们可以分为每月工作的帐户数量（200,000），或者用户可以输入帐户标识符以将成本应用于一组帐户，或者可以仅指定将成本应用于哪个帐户。 我首先想到的是规范化的数据库： 帐户ID 日期 CostTypeId 量 我的问题是数学。该表将迅速变得庞大。假设所有13种成本类型都应用到了当月的所有工作帐户，即每月200k * 13 * N days in month大约75-8000万条记录，或者每年接近10亿条记录。 我的第二个想法是将其标准化 帐户ID 日期 总计花费 CostType1 CostType2 CostType3 CostType4 CostType5 CostType6 CostType7 CostType8 CostType9 CostType10 CostType11 CostType12 CostType13 此方法更加不200k * N days in month规范，每月最多可以创建600万条记录（），或每年大约7200 万条。它比第一种方法少很多，但是，如果公司将来决定使用新的费用类型，则需要添加另一个数据库列。 在这两种方法中，您更喜欢哪一种？为什么？您是否可以想到另一种更好的选择？ 我最感兴趣的是报告性能，包括总结报告和详细报告。当没有人在附近时，将费用分摊到各个帐户的工作将每晚进行。第二个问题是数据库大小。现有的数据库已经接近300GB，我相信磁盘上的空间约为500GB。 该数据库是SQL Server 2005
1
有没有人推荐一本教授分片的书？
有没有人对这本讲授数据库分片的书有很好的推荐（最好从零开始） 我读过40多个有关分片的网站。 我并不是说在线站点/博客很糟糕，它们是不错的选择。但是，我需要的主要餐点不仅仅是这里和那里的有用信息。基本上，我对如何实现分片有一个想法（但是我想），但是由于这是一个非常复杂的概念，因此我相信还有很多很多可以研究。
16 mysql  sql-server 
5
什么时候应该将非聚集索引存储在单独的文件组中？
我听说将索引存储在不同的文件组和驱动器上可以提高数据库的性能，因为驱动器不必在索引和索引所引用的数据之间来回移动。我也听说这是一个神话。 何时建议将非聚集索引存储在单独的文件组和驱动器上？什么性能/分析器证据会导致我得出该结论？硬件在决策中是否起作用（是否在单个驱动器上使用RAID / SAN）？
16 sql-server  index 
2
SQL Server 2008-分区和聚集索引
因此，请允许我说我对数据库的设计没有完全控制权，因此，对于本场景而言，无法更改当前系统的许多方面。 关于我们应该如何重新考虑设计方面的评论可能是正确的，但无济于事:) 我有一个很大的表，大约150个字段宽，大约600m行，它驱动着大量的进程。这是在数据仓库的情况下，因此我们在计划的加载过程之外没有任何更新/插入，因此它的索引很高。 已做出尝试对该表进行分区的决定，并且我对索引已分区表有些担忧。我没有分区方面的经验，因此不胜感激任何输入或链接。我在BOL或msdn上找不到具体的位置。 目前我们群集上一个领域，我们称之为IncidentKey这是一个varchar(50)，而不是唯一的-我们可以1-100记录与同一之间有IK（没有意见，请）。我们经常会在旧IncidentKey记录上获取新数据，因此也不是连续的。 我了解我需要IncidentDate在群集索引键中包含分区字段，以使分区正常工作。我在想IncidentKey, IncidentDate。 问题是，如果“新”分区中的记录应该在聚簇索引中“旧”分区中的记录之前，则聚簇索引的机制将如何在分区表的2部分键上工作？ 例如，我有5条记录： IncidentKey Date ABC123 1/1/2010 ABC123 7/1/2010 ABC123 1/1/2011 XYZ999 1/1/2010 XYZ999 7/1/2010 如果我得到一条新记录，ABC123, 2/1/2011它将需要在聚集索引BEFORE中 XYZ999, 1/1/2010。这是如何运作的？ 我假设使用碎片和指针，但是找不到具有双部分键的分区表上非分区聚簇索引的物理存储和配置的任何信息。
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.