标签: sql-server-2012

正如标题行所暗示的那样：在具有索引的 VIEW 上使用 ALTER VIEW 语句将在没有警告的情况下从 VIEW 中删除此（所有？）索引。我希望 ALTER VIEW 语句失败，通知我先删除索引。

SQL SERVER 中是否有更改此行为的设置？还是在 SQL 2012 (SP3) 之后的版本中发生了变化？

在传统的 SQL Server 群集中，当发生故障转移时，所有连接到 SQL Server 失败实例的客户端都会失去连接，每个客户端都必须重新建立到故障转移群集实例的新连接。

AlwaysON 可用性组是否可以缓解此问题？SQL Server 2012 AlwaysON 可用性组的故障转移对于连接到 SQL Server 的客户端是否透明？

跟踪谁进行了 CDC 确定的更改。

沿着我的 datetime hack的路线，我尝试了相同的方法，将 suser_sname 添加为 cdc 更改跟踪表上具有默认值的新字段。但是，这似乎返回了 cdc 进程的所有者，而不是在基表上启动更改的用户。我也试过 original_login 但它返回了 sql 服务帐户登录。同样，可能与 cdc 进程相关，而不是与发起更改的用户相关。

我在堆栈溢出上发现了一个类似的问题，但除了从前端或通过触发器跟踪更改之外没有其他答案，这似乎违背了使用 cdc 的目的。我不会重新发布，但由于原版是在 stackoverflow 上，我想我会在这里尝试一下，特别是如果 R2 或 2012 引入了更好的方法。

因此，简而言之：我如何知道谁对变更数据捕获进行了更改？

我们正在使用日志传送并RESTORE WITH STANDBY在 SQL Server 2012 上以只读模式恢复数据库以用于报告目的。但是，在完成一两个日志备份的还原后，日志传送设置不断中断。日志传送仅在运行时中断RESTORE WITH STANDBY；RESTORE WITH NORECOVERY不会造成任何问题。

我对此的唯一直觉是主数据库不是那么动态。因此，当没有交易时，这可能会导致RESTORE流程出现问题？

任何想法，已知的修复？

通过运行在两个表上进行大量更新的常规作业，我让它工作了几天。当作业停止运行时，日志传送设置很快失败，无法处理 .trn 文件。我重置了日志传送，并试图通过只做一个小的更新来查看它是否会继续运行，更改表中一个记录的一列的值，无论它仍然失败。

感谢您的所有回复。

PS：摘自我们的日志

02/25/2013 13:00:00,LSRestore_DBDB01-A_BulldogDB,进行中,1,DBREPORTS,LSRestore_DBDB01-A_BulldogDB,日志传送恢复日志作业步骤.,2013-02-25 13:00:12:31无法将日志备份文件“\\dbsan01\DBBackups\LSBackup_BulldogDB\BulldogDB_20130225180000.trn”应用到辅助数据库“BulldogDB”。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.31 *** 错误：处理数据库“BulldogDB”的日志时出错。如果可能，从备份中恢复。如果备份不可用，则可能需要重建日志。
恢复期间发生错误，导致数据库“BulldogDB”(8:0) 无法重新启动。诊断恢复错误并修复它们或从已知良好的备份恢复。如果未纠正或预期错误，请联系技术支持。
RESTORE LOG 异常终止。
为文件 1 上的数据库“BulldogDB”文件“BulldogDB”处理了 0 页。
为文件 1.(.Net SqlClient 数据提供程序) 上的数据库 'BulldogDB' 文件 'BulldogDB_log' 处理了 1 页 ***
2013-02-25 13:00:12.32 *** 错误：无法记录历史记录/错误消息。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.32 *** 错误：ExecuteNonQuery 需要打开且可用的连接。连接的当前状态是关闭的。(System.Data) ***
2013-02-25 13:00:12.32 跳过辅助数据库“BulldogDB”的日志备份文件“\\dbsan01\DBBackups\LSBackup_BulldogDB\BulldogDB_20130225180000.trn”，因为无法验证该文件。
2013-02-25 13:00:12.32 *** 错误：无法记录历史记录/错误消息。（Microsoft.SqlServer.Management.LogShipping）***
2013-02-25 13:00:12.32 *** 错误：ExecuteNonQuery 需要打开且可用的连接。连接的当前状态是关闭的。(System.Data) ***
2013-02-25 13:00:12.33 …

我读过的一些关于 SQL Server 数据压缩的文献指出，写入成本增加到通常所需的四倍左右。这似乎也暗示这是数据压缩的主要缺点，强烈暗示对于只读存档数据库，性能将（除了少数例外）通过使用 100% 填充页面的数据压缩来提高。

1. 以上说法是否属实？

2. 数据压缩和其他方式之间的主要“变化”是什么（用于阅读）

   • “CPU + x%”？
   • “IO -y%”？
   • 页面拆分发生？
   • tempdb 用法？
   • 内存使用情况？
3. 和写作？

出于此问题的目的，您可以将上下文限制为大型(> 1TB)数据库的PAGE 级压缩，但始终欢迎其他评论。

参考：

SQL Server 存储引擎博客（DW 场景显示压缩非常有利）
数据压缩：策略、容量规划和最佳实践

决定压缩内容的更详细方法涉及分析每个表和索引的工作负载特征。它基于以下两个指标：

U：特定表、索引或分区上的更新操作相对于该对象上的总操作的百分比。U 的值越低（即表、索引或分区不经常更新），它就越适合进行页面压缩。
S：表、索引或分区上的扫描操作相对于该对象上的总操作的百分比。S 的值越高（即表、索引或分区被扫描的次数越多），它就越适合进行页面压缩。

以上两者显然都偏向于推荐 DW 样式数据库（读取密集型/独占性、大数据操作）的页面压缩。

今天我在 The Heap 上，正在查看我认为可以改进的查询计划。然而，它创造了一些东西，动摇了我对 SQL Server 查询优化器的信念。如果sql-server甚至不能计数到 100%，我还可以信任它吗？

表的特点：

• 聚集在非标识列上
• 12 个索引，其中之一是相关date_entered列
• 60,000 条记录
• 26列不同类型和长度
• PAGE 压缩表

有没有人以前见过这个，是什么导致计划看起来如此扭曲？

我们有一个生成库存报告的流程。在客户端，进程拆分可配置数量的工作线程，为报告构建一个数据块，该数据块对应于许多商店中的一个（可能是数千个，通常是数十个）。每个工作线程调用一个执行存储过程的 Web 服务。

处理每个块的数据库进程将一堆数据收集到一个#Temporary 表中。在每个处理块结束时，数据将写入 tempdb 中的永久表。最后，在进程结束时，客户端的一个线程从永久 tempdb 表中请求所有数据。

运行此报告的用户越多，它的速度就越慢。我分析了数据库中的活动。有一次，我看到 35 个单独的请求在过程中的某一点都被阻止了。所有这些 SPIDLATCH_EX对资源类型的等待时间大约为 50 毫秒METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)。一个 SPID 拥有此资源，而所有其他 SPID 都处于阻塞状态。我在网络搜索中没有找到有关此等待资源的任何信息。

我们正在使用的 tempdb 中的表确实有一IDENTITY(1,1)列。这些 SPID 是否在等待 IDENTITY 列？我们可以使用哪些方法来减少或消除阻塞？

服务器是集群的一部分。服务器在 64 位 Windows 2008 R2 Enterprise 上运行 64 位 SQL Server 2012 Standard Edition SP1。服务器有 64 GB RAM 和 48 个处理器，但数据库只能使用 16 个，因为它是标准版。

（请注意，我对在 tempdb 中使用永久表来保存所有这些数据的设计并不感到兴奋。改变这将是一个有趣的技术和政治挑战，但我愿意接受建议。）

更新 4/23/2013

我们已经与 Microsoft 建立了一个支持案例。随着我们了解更多，我会更新这个问题。

更新 5/10/2013

SQL Server 支持工程师同意等待是由 IDENTITY 列引起的。删除 IDENTITY 消除了等待。我们无法在 SQL 2008 R2 上复制该问题；它仅发生在 SQL 2012 …

虽然我在做我自己的调查，没有人知道为什么在数据库SIMPLE恢复模型LOG_BACKUP的log_reuse_wait_desc？

SQL Server 2012 SP1。几周前创建的数据库。没有复制，没有镜像，没有日志传送，而且从来没有过这些。

我们确实备份了数据库并恢复到另一个实例，它显示SIMPLE并NOTHING在log_reuse_wait另一个实例中。但我不认为还原到另一个实例是重现问题的好方法，因为还原操作会前滚/回滚事务。

我最近设置了 SSDT 供我们的开发人员使用。我们通过 SSDT 通过限制每个开发人员在连接到服务器（db_datareader、db_datawriter）时拥有的权限来强制更改我们的开发数据库。在 SSDT 中，我们使用部署脚本将更改发布到数据库，该脚本使用具有提升权限的登录进行连接。

我的问题。鉴于我们已经走到了这个长度来锁定数据库（以阻止模式漂移）；有没有什么方法可以让开发人员在没有 db_owner 权限的情况下查看这个数据库上的图表？我知道每个开发人员都可以创建和查看他或她自己的图表，但我希望他们能够查看由许多不同开发人员创建的所有图表。

我不认为这会有所帮助，但我们正在运行 sql server 2012

任何帮助都会得到很大的帮助。

我在 SQL Server 2012 Express 中有一个表，有很多未使用的空间。

我需要释放数据库中的空间。

| 姓名 | 行 | 保留 | 数据 | INDEX_SIZE | 未使用 |
|-------------|--------|--------------|----------- ---|------------|--------------|
| 我的表名 | 158890 | 8928296 KB | 5760944 KB | 2248 KB | 3165104 KB |

如何让 SQL 释放 3165104KB？

我已经试过了：

Alter table MyTableName Rebuild
DBCC CLEANTABLE (MyDbName,"MyTableName ", 0)
ALTER INDEX ALL ON MyTableName REORGANIZE ; 
ALTER INDEX PK_Image ON MyTableName REBUILD WITH (ONLINE = OFF) 

这是表：

CREATE TABLE [dbo].[MyTableName](
    [ImageID] [int] IDENTITY(1,1) NOT NULL,
    [DateScan] …