在我的一个生产 SQL 服务器实例中,我遇到了一个问题。查询需要很长时间才能运行。在检查 SQL 查询计划时,我发现它给出了创建缺失索引的建议。我去了推荐表,发现推荐的索引已经存在于表中,但有些没有被使用。维护计划(重建索引、更新统计信息等)定期执行。我不确定为什么索引没有被使用?以及为什么查询计划在索引已经存在的情况下继续给出缺失索引的建议?任何帮助将非常感激。
performance sql-server-2008 execution-plan query-performance
我正在使用 C#,实体框架。用于开发 SQL Server。我有一个方法,它有两个参数 ( int ID, List<String> _listobj)。对于每个 ID,都有一个 obj 列表。所有这些 ID 和列表都将插入到数据库中的不同表中。所以问题是:最好的做法是什么?我有几个选择:
在 C# 中,拆分list<obj>为单个值,然后创建一个带有两个参数 ( ID, str)的存储过程,然后 C# 将根据列表的大小多次调用存储过程
将ID和list<obj>作为两个参数传递给存储过程,并让存储过程拆分list<obj>. 这样C#只会调用一次存储过程
第二种策略可行吗?如果是,哪个在性能方面更好?
sql-server-2008 sql-server stored-procedures entity-framework c#
我正在尝试运行以下查询以在链接服务器上的表上重建索引,但它不起作用。任何人都可以让我知道我做错了什么吗?
ALTER INDEX ALL ON [LinkedServerName].[dbname].[dbo].[tablename] REBUILD
WITH (FILLFACTOR = 90)
Run Code Online (Sandbox Code Playgroud)
这给了我以下错误:
找不到对象“[LinkedServerName].[dbname].[dbo].[tablename]”,因为它不存在或您没有权限。
我的目标是在生产中使用选择而不影响其他任何东西。
当我刚接触 SQL 时,我只是写了简单的选择,但后来我知道这会导致锁定。
如果我不关心脏读,我可以在每个选择上使用 nolocks 或设置事务隔离级别来读取未提交。
但我确实关心脏读,所以我选择了隔离级别快照。隔离级别快照写入 tempdb,我不知道这是否有问题(额外写入数据库意味着更慢的 DB 和更少的空间?)
那么在 DB 上编写选择的最少侵入性方法是什么,我不能减慢它的速度或创建共享锁?我应该回到隔离级别读取未提交的每个查询吗?
这是从开发人员的角度提出的问题。我不知道有关 DB 设置的详细信息,但希望以最少麻烦的方式使用选择。
我正在使用 SQL Server 2008 并且有一个问题,如果不使用许多临时表和不可靠的连接,我不知道如何解决。
表 1 包含 6 列数据,然后将其拆分为两个表。Col1 到 Col3 进入表 2,Col4 到 Col6 进入表 3。将数据放入表 2 和表 3 是容易的部分。然而,表 3 中的 T2ID 是表 2 中 ID 的外键。
性能是关键,所以我不想使用变量和/或逐行迭代数据,理想情况下,我只想要一个可以做很多事情的插入。
我曾尝试使用链接表,但表 2 和表 3 中的数据不是唯一的,这使得连接不可靠。
有什么建议?
Create Table T1 (
ID INT IDENTITY(1,1),
Col1 VARCHAR(10),
Col2 VARCHAR(10),
Col3 VARCHAR(10),
Col4 VARCHAR(10),
Col5 VARCHAR(10),
Col6 VARCHAR(10)
)
Create Table T2 (
ID INT IDENTITY(1,1),
Col1 VARCHAR(10),
Col2 VARCHAR(10),
Col3 VARCHAR(10)
)
Create Table T3 (
ID INT IDENTITY(1,1),
T2ID INT, …Run Code Online (Sandbox Code Playgroud) 我一直在四处挖掘,但没有任何运气。
SQL Server 2008:是否可以在不重建整个表的情况下调整特定聚集索引/表的填充因子?
例如,如果它有 4 亿条记录,我们是否可以调整填充因子并让 SQL Server 在所有尚未超过该限制的页面(以及新拆分)上使用新的填充因子,然后调整已超出该限制的页面?索引维护期间超限?
是否可以预先定义在下一次索引维护期间应该构建索引的填充因子?
sql-server-2008 sql-server clustered-index fill-factor index-maintenance
我们有一项工作没有计划运行,但我们怀疑是另一项工作启动了它。没有作业历史记录,但它确实出现在错误日志中。我们如何知道这是否正在被另一个工作调用?我知道我们可以使用 sp_start_job 在作业步骤中立即调用作业,但如果是这种情况,我们如何找到它?
而且,为什么运行的作业没有任何历史记录?
Error log entry:
2017-05-01 10:01:50.40 spid6s SPID: 131 ECID: 0 Statement Type: ALTER INDEX Line #: 1
2017-05-01 10:01:50.40 spid6s Input Buf: Language Event: EXECUTE [msdb]. dbo.IndexOptimize @Databases = 'Database1,Database2'
Run Code Online (Sandbox Code Playgroud) 我有一个表,用于注册设备的状态。状态有开始时间和结束时间。但现在我想知道每个小时的状态是什么。如果从 15:20 到 17:10 的状态是“Operating”,我想看到它在一天的第 16 个小时运行 40 分钟,第 17 个小时运行 60 分钟,第 18 个小时运行 10 分钟当天。
这就是我现在所拥有的:
Shift_date 状态 Start_timestamp End_Timestamp ---------- --------- --------------- --------------- 5/20/2017 运营 5/20/2017 8:21 5/20/2017 10:40 5/21/2017 延迟 5/20/2017 10:40 5/20/2017 11:10 5/22/2017 运营 5/20/2017 11:10 5/20/2017 13:50
这就是我要的:
Shift_date 小时状态持续时间(分钟) ---------- ---- --------- ---------- 5/20/2017 1 .. .. 2017 年 5 月 20 日 ..... .. 5/20/2017 9 运营 39 5/20/2017 10 运营 60 5/20/2017 11 运营 40 5/20/2017 11 延迟 20 5/20/2017 …
我需要在滚动总和计算上设置一个下限。例如,与
PKID NumValue GroupID
----------------------------
1 -1 1
2 -2 1
3 5 1
4 -7 1
5 1 2
Run Code Online (Sandbox Code Playgroud)
我想拥有:
PKID RollingSum GroupID
----------------------------- ## Explanation:
1 0 1 ## 0 - 1 < 0 => 0
2 0 1 ## 0 - 2 < 0 => 0
3 5 1 ## 0 + 5 > 0 => 5
4 0 1 ## 5 - 7 < 0 => 0
Run Code Online (Sandbox Code Playgroud)
当添加一个负数将导致总和为负时,将激活限制以将结果设置为零。后续的加法应该基于这个调整后的值,而不是原来的滚动总和。
应该使用加法来达到预期的结果。如果第四个数字从 -7 变为 -3,则第四个结果应该是 2 而不是 0
如果可以提供单个金额而不是几个滚动数字,那也是可以接受的。我可以使用存储过程来实现非负加法,但这太低级了。 …
我必须使用 SQL Server Management Studio 2012 管理 SQL Server 2008 数据库。数据库文件大约为 290Gb。我们遇到的问题是日志文件过去增长了很多。
做了一些互联网研究(我对数据库管理完全陌生),我得出了以下结论,并应用了所有这些结论:
这个配置似乎工作正常。我一直在监视日志大小的行为,它从不需要自动增长;当日志文件的保留空间即将满时,计划备份将再次释放它。11 小时后,日志大小仅增加到 260MB,我认为还可以(11 小时内自动增长 4x10Mb)。
所以我回家了,相信这种行为会持续到晚上。但是第二天,我看到已经进行了几次自动生长。日志大小从 220 Mb 增加到 2350 Mb(超过 200 次自动增长!)。
我决定不改变任何东西,并继续监控它;日志文件的已用空间从未增长超过 18%。我将自动增长大小从 10 Mb 增加到 50 Mb。
同样,我非常有信心这种配置将防止发生自动增长。再一次,我错了。今天早上我发现已经执行了一个新的自动生长过程。只有一次,但它仍然让我感到困惑。
我注意到最后一次自动增长操作发生在执行完整数据库备份之后。
如果这种行为是正常的,请任何人解释我吗?为什么日志大小整天保持稳定,数据库备份后突然变大?为什么它会增长,而日志文件的保留空间只有 20% 在高峰时间使用,就在日志备份之前?有什么推荐吗?
sql-server-2008 ×10
sql-server ×9
performance ×2
c# ×1
fill-factor ×1
index ×1
jobs ×1
logging ×1
t-sql ×1