标签: sql-server

我一直在通过 sql server 2008 r2 中的数据收集器监视文件增长两周。数据库以大约 35(MB)/天的速度持续增长。数据库尚未达到 2 GB 的初始大小。

DB 文件自动增长设置为 5MB，我想尝试不同的方法，所以我正在寻找建议和/或评论。

每周周日晚上 1:30 有一项调整任务运行。该任务将：

• 检查数据库完整性
• 缩小日志文件 - （这没关系，因为日志模式很简单）
• 收缩数据库
• 重组索引
• 重建索引
• 更新统计
• 清理历史

我想在每周调整计划中再添加两个步骤：

1. 如果已用空间达到某个阈值或总大小，则将数据库文件增大 500 MB。
2. 如果已用空间达到总大小的某个阈值，则将日志文件增加 250 MB（收缩后）。

通过将增长负担置于离线时间，我希望通过减少重负载期间自动增长事件的数量来提高性能。

我有两个关于自动增长文件的问题。

• 放置文件增长步骤的最佳位置是在当前步骤之前还是之后？
• 如果我使用ALTER DATABASE|MODIFY FILE来增长文件，那么我如何确定SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)？

我有敏感的价格列，我只想通过存储过程进行更新。如果不使用旨在更新它的存储过程，我希望所有代码或手动尝试更改这些价格列中的值都失败。

我正在考虑使用触发器和令牌表来实现这一点。我正在考虑的想法是有一个令牌表。存储过程必须首先在令牌表中插入值。然后更新价格列。更新触发器将检查更新行的令牌表中是否存在该令牌。如果找到，它将继续。如果未找到令牌，则会抛出异常并使更新事务失败。

有没有好的/更好的方法来实现这个限制？

我正在尝试自动执行对 SQL Server 2008 R2 数据库执行更改的过程。我实施的流程删除并重新创建了我的存储过程和函数，以及运行脚本来更改表/列/数据。不幸的是，其中一个脚本需要首先放置其中一个函数。但是我不能先运行所有存储的过程/函数更改，因为它首先依赖于从表/列/数据更改脚本中添加的列。

我想知道是否可以在没有 SQL Server 验证函数/SP 定义中使用的列的情况下运行存储过程和函数？我尝试查找但找不到启用此功能的条件或命令。

我们正在考虑用基于 VSS 的 mdf 和 ldf 文件备份替换传统的 SQL 服务器备份。作为一名 db 人员，我对此感到有些不安，但我找不到任何证据表明这行不通？

任何人都可以建议我可以设置的试验来证明我们可以在哪些地方丢失使用此策略的交易？[在长时间运行的事务期间拔掉电源线是可以的]。

我们正在查看的系统创建 mdf 和 ldf 文件的初始快照，然后跨更改复制。我无法想象这会让我们失望的场景。

希望您能帮助我说服我的老板我们需要保留传统备份！

我将拥有一个 SQL Server 2012 数据库和一个包含 300 万行和 50 列的表。无人值守后台 .net 进程（可能发出一些 SQL 或 Powershell 命令）将其导出到文本文件的最快方法是什么，每行数据一行？.net 进程应该知道导出何时完成或是否有任何错误。数据类型将为 allint或nvarchar。

我假设纯 C# 代码使用 ado.net 执行select *命令并循环遍历数据读取器并为每个记录写入文件会很慢，我无法并行化它。

理想情况下，将导出到远程共享网络文件夹，而不是 SQL Server 计算机上的本地文件夹。SQL Server 将是一个 HA 群集。SSIS 是否更适合于此，不需要数据转换？

.Net 进程将在机器 A 上运行，在机器 B 上运行 SQL Server，最终文件目的地是网络共享。一种选择是 SQL 服务器将文件直接写入网络共享。另一个选项是 SQL Server 写入机器 A，然后在写入文件时，.net 进程将其复制到网络共享。我没有正式的 SLA，但预计文件写入需要 30 分钟 - 1 小时。

我发现了一个僵局，似乎表明了我认为不可能的事情。死锁涉及两个进程：

1. process8cf948 SPID 63

• 对临时表 #PB_Cost_Excp_Process_Invoices_Work 执行 ALTER TABLE。

• 拥有表 #PB_Cost_Excp_Process_Invoices_Work 的 IX 锁，对象 ID 为 455743580

2. process4cb3708 SPID 72

• 在临时表 #PB_Cost_Excp_Process_Invoices_Work 上执行更新，它应该是它自己唯一的表副本。

• 在#PB_Cost_Excp_Process_Invoices_Work 上拥有 Sch-M 锁，对象 ID 为 455743580！

这应该是不可能的。我错过了什么吗？#Temporary 表真的在这两个 SPID 之间重用了吗？

这是在 SQL Server 2008 R2 Service Pack 2 和累积更新 1（版本 10.50.4260）上。

完整的未更改死锁跟踪如下。请注意这两个进程如何在具有相同表名的相同对象 ID 上运行 #PB_Cost_Excp_Process_Invoices_Work_SNIP_0000000D8519：

12/14/2012 13:46:03,spid23s,Unknown,waiter id=process8cf948 mode=X requestType=wait
12/14/2012 13:46:03,spid23s,Unknown,waiter-list
12/14/2012 13:46:03,spid23s,Unknown,owner id=process4cb3708 mode=Sch-M
12/14/2012 13:46:03,spid23s,Unknown,owner-list
12/14/2012 13:46:03,spid23s,Unknown,objectlock lockPartition=0 objid=455743580 subresource=FULL dbid=2 objectname=tempdb.dbo.#PB_Cost_Excp_Process_Invoices_Work_________________________________________________________________________________0000000D8519 id=lock371705d00 mode=Sch-M associatedObjectId=455743580
12/14/2012 13:46:03,spid23s,Unknown,waiter id=process4cb3708 mode=Sch-M …

我有一个大表（约 5000 万行）我正在尝试批量插入 SQL Server，但出现错误：

无法为数据库“I 3 Stroke”中的对象“myDB”分配空间，因为“PRIMARY”文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

数据库中有另一个表，大约有 2500 万行。该数据库将仅在一台机器上使用，它旨在挖掘已经存在的数据，并且在任何情况下都不会超过其当前大小。

对于这种情况，解决此问题的最佳方法是什么，这样 SQL Server 就不会抱怨？这个数据库不会暴露给多个用户的解决方案是否重要？

我们正在使用带有唯一标识符的 SQL Server 2012，我们注意到在执行选择时在末尾添加了额外的字符（所以不是 36 个字符），它仍然返回与 UUID 的匹配项。

例如：

select * from some_table where uuid = '7DA26ECB-D599-4469-91D4-F9136EC0B4E8' 

返回带有 uuid 的行7DA26ECB-D599-4469-91D4-F9136EC0B4E8。

但是如果你运行：

select * from some_table where uuid = '7DA26ECB-D599-4469-91D4-F9136EC0B4E8EXTRACHARS'

它还返回带有 uuid 的行7DA26ECB-D599-4469-91D4-F9136EC0B4E8。

SQL Server 在进行选择时似乎忽略了 36 以外的所有字符。这是错误/功能还是可以配置的东西？

这不是一个大问题，因为我们在前端验证了长度，但对我来说这似乎不是正确的行为。

我对这个想法进行了一些确认，以修复性能不佳的数据库或更好的建议（如果有人有的话）。始终对更好的建议持开放态度。

我有一个非常大的数据库（20 多万条记录，每天增长约 1/2 百万），它使用 GUID 作为 PK。

我的疏忽，但 PK 聚集在 SQL 服务器上并导致性能问题。

guid 的原因 - 此数据库与 150 个其他数据库部分同步，因此 PK 需要是唯一的。同步不是由 SQL Server 管理的，而是构建了一个自定义过程，使数据保持同步以满足系统的要求——所有这些都基于该 GUID。

150 个远程数据库中的每一个都不存储中央 SQL 数据库中存储的完整数据。他们只存储他们实际需要的数据的一个子集，并且需要的数据对他们来说不是唯一的（150 个数据库中有 10 个可能有一些来自其他站点数据库的相同记录，例如 - 他们共享）。此外 - 数据实际上是在远程站点生成的 - 而不是在中心点 - 因此需要 GUID。

中央数据库不仅用于保持所有内容同步，而且将针对这个非常大的碎片数据库执行来自 3000 多个用户的查询。这在初始测试中已经是一个大问题。

幸运的是，我们还没有上线 - 所以我可以进行更改并在需要时将事情脱机，这至少是一些事情。

远程数据库的性能不是问题 - 数据子集非常小，数据库的总大小通常不会超过 1GB。记录会定期反馈到主系统，并在不再需要时从较小的 BD 中删除。

作为所有记录的管理员的中央数据库的性能是可悲的 - 由于聚集的 GUID 作为许多记录的主键。索引碎片不在图表之列。

所以 - 我解决性能问题的想法是创建一个新列 - Unsigned BIGINT IDENTITY(1,1) 然后更改表 BIGINT 列的 Clustered PK。

我会在作为主键的 GUID 字段上创建一个唯一的非聚集索引。

较小的远程 150 数据库不需要知道中央 SQL Server 数据库上的新 PK …

我正在处理 sql 脚本，如果不满足某些条件，我需要停止继续该脚本。

当我谷歌它时，我发现 20 严重级别的 RaisError 将终止它。但由于某些原因，我不能使用该选项。

请向我提供停止 SQL 脚本执行的可能替代方法。