小编Geo*_*ios的帖子

我很确定我知道这个问题的答案，但时间点恢复的局限性让我大吃一惊。

假设我有一个 2TB 的数据库设置为FULL恢复模式。我认真地每 30 分钟进行一次每周完整备份、每日差异备份和日志备份。

现在，我想将数据库回滚到 1 小时前。我真的必须在一小时前恢复整个完整备份、差异和日志吗？我是否正确地认为这将需要很长时间？

有没有办法ROLLBACK使用事务日志文件进行更改，以便这种类型的恢复需要几分钟？

在最后一天左右的时间里，我一直在为这个问题摸不着头脑——我只是不明白为什么一个过程在一种环境中有效，但由于转换错误（相同的数据，相同的代码）而在另一种环境中失败。

工作服务器的计划（大幅削减版本）位于： https: //www.brentozar.com/pastetheplan/ ?id=B1jZWTfOf

（这似乎不起作用，所以我已将计划 XML 上传到此处的 Pastebin： https: //pastebin.com/47Q6nniw）

导致问题的相关列的一些背景知识：

propertyInst 表包含一个名为 ValueStr 的列，它是 nvarchar 数据类型。GeneralLedgerCode 表具有数据类型 int 的列 id。我们的开发人员正在尝试连接两个表。ValueStr 列保存文本数据、XML 数据、整数数据、小数数据等。当然，我们决定添加一个函数来确保仅解析整数 (ISNUMERIC(ValueStr) = 1）。我们没有意识到的是，这也会尝试转换任何十进制值 - 这会导致自然生产中的转换错误：

将 nvarchar 值“0.1”转换为数据类型 int 时转换失败。

我的问题是，鉴于 propertyInst 表的表扫描将拾取包括小数在内的所有数值，为什么标量运算符中的隐式转换不会因相同的转换错误而失败？ISNUMERIC 查询的输出返回其中一些小数。我根本看不出所附计划是如何运作的。

隐式转换运算符是否永远不会彻底失败，转换错误是否来自哈希匹配运算符中的探测残差？话又说回来，当隐式转换失败时，该值如何能够到达运算符呢？

作为一个小帮助，计划图像在这里，我要询问的计算标量被圈起来。

此外，我可以看到没有针对标量运算符记录的实际行 - 这是否意味着引擎由于转换错误而决定在运行时不使用该特定运算符？

任何帮助，将不胜感激。

我有一个用户使用的软件有时会将 UNIT 的 ID 作为整数（例如 1000）发回，有时会附加一个小十进制值（例如 1000.001）。该软件会自动生成具有“真实”数据类型的 MSSQL (2016 SP1) 表，并且“最重要”使此 UNIT 列成为主键的一部分。这会导致数据输入端和报告端出现问题。

我意识到这确实是软件的一个“错误”，但我试图在数据库方面提供帮助。我已经在沙盒区域证明我可以将“真实”数据类型更改为“int”，这不会导致现有数据丢失数据，并且每个输入场景都显示任何输入的十进制值将在“int”列（未四舍五入）。

我的问题是，“当输入到“int”数据类型时，SQL Server 是否总是可靠地截断十进制值（我们没有办法深入到打包的应用程序中并强制将其转为 ROUND）？是否有任何情况会出错，或引起问题？” 我在任何地方都找不到此文档。

我们目前正在朝着 24/7/365 运营模式迈进——因此我正在调查我们的维护策略。

我无法弄清楚的一项是 DBCC CHECKDB。我已经看到许多资源报告说 DBCC 可以通过执行完整备份、在单独的 SQL 实例上恢复该备份并在该恢复的副本上运行我们的 CHECKDB 来卸载。我还发现一些资源报告说由于边缘情况，这不安全。

如果不在生产数据库本身上运行，运行 CHECKDB 是否安全？如果不是，在恢复的副本上运行哪些部分是安全的？

我是我公司的一名非常专业的 DBA，并运行了 sp_Blitz 脚本（在我们的一个测试数据库上，它是我们生产数据库的精确副本），我只收到消息“命令成功完成。”。

我没有得到更详细的输出有什么原因吗？还是输出文件写在其他地方？