我一直想知道为事务日志记录生成日志序列号的算法,我担心如果工作量足够大,可能会用完日志序列号。
在那种情况下会发生什么?
我一直想知道为事务日志记录生成日志序列号的算法,我担心如果工作量足够大,可能会用完日志序列号。
在那种情况下会发生什么?
SQL Server 2016 CU2(企业版)在这里,我的一位用户要求我们安装 R-Services。
我按照此页面上看似非常简单的说明进行操作
当我谈到使用简单测试的部分时
exec sp_execute_external_script @language =N'R',
@script=N'OutputDataSet<-InputDataSet',
@input_data_1 =N'select 1 as hello'
with result sets (([hello] int not null));
go
它失败了
消息 39021,级别 16,状态 1,第 6 行无法启动“R”脚本的运行时。请检查“R”运行时的配置。消息 39019,级别 16,状态 1,第 6 行发生外部脚本错误:无法启动运行时。ErrorCode 0x80070057: 87(参数不正确)。消息 11536,级别 16,状态 1,第 6 行 EXECUTE 语句失败,因为其 WITH RESULT SETS 子句指定了 1 个结果集,但该语句在运行时仅发送了 0 个结果集。
因此,我开始在 Internet 上搜索有关 R-Services 的已知问题,并找到了这篇文章 - SQL Server R Services 的已知问题
每次配置更改后,我都重新启动了 SQL Server 和 SQL Server Launchpad。
但是,每次我尝试为 R-Services 运行示例 T-SQL 测试时,它都会失败,并且我在rlauncher.log
文件中看到此条目
[错误] 会话创建失败:失败 2 以获取 C:\TEMP\R_SERV~1\MSSQLSERVER01 的安全性
我正在寻求其他可能知道问题所在或任何其他故障排除链接的人的帮助。
我今天早上醒来发现我的一个数据库损坏了。我有一份工作,每天为服务器上的所有数据库运行 DBCC CHECKDB。输出表明只有一张表损坏(幸运的是)。
Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:216001) on page (5:216002) does not match the previous page (5:2603841) that the parent (5:3902159), slot 23 expects for this page.
Msg 8936, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). B-tree chain linkage mismatch. (5:628894)->next = (5:628895), but (5:628895)->Prev = (5:2602254).
Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:1165706) on page (5:1165707) does not match the previous page (5:2602253) that the parent (5:1529), slot 33 expects for this page.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:2239068), slot 33 refers to child page (5:2602254) and previous child (5:628894), but they were not encountered.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:3902159), slot 22 refers to child page (5:2603841) and previous child (5:216001), but they were not encountered.
Msg 8981, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 10, partition ID 72057601280507904, alloc unit ID 72057601393229824 (type In-row data). The next pointer of (5:1212172) refers to page (5:3489726). Neither (5:3489726) nor its parent were encountered. Possible bad chain linkage.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:1529), slot 32 refers to child page (5:2602253) and previous child (5:1165706), but they were not encountered.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 10, partition ID 72057601280507904, alloc unit ID 72057601393229824 (type In-row data). Page (5:3489727) is missing a reference from previous page (5:1212172). Possible chain linkage problem.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602253) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602254) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602255) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603840) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603841) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603842) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:2602255) on page (5:15918) does not match the previous page (5:15917) that the parent (5:3904979), slot 8 expects for this page.
Msg 8936, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). B-tree chain linkage mismatch. (5:15917)->next = (5:15918), but (5:15918)->Prev = (5:2602255).
CHECKDB found 0 allocation errors and 16 consistency errors in table 'AperioCompare.PolicyAmendmentCompare' (object ID 1946163866).
CHECKDB found 0 allocation errors and 16 consistency errors in database 'Aperio'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Aperio).
我一直在寻找最后一行,这样我就可以弄清楚所涉及的最低恢复水平。在这种情况下,它表示“repair_allow_data_loss 是 DBCC CHECKDB 发现的错误的最低修复级别”。
我查看了对象 ID 并验证了 OBJECT_NAME(1946163866) 确实指向了我的 ONE 表。错误报告显示索引 ID 10 和 11 存在问题。然后我从 sys.indexes 中选择 object_id=1946163866 并找到索引 10 和 11 的索引行——这两个索引都是非聚集的。我删除并重新创建了两个非聚集索引并重新运行我的 DBCC CHECKDB - 没有报告任何错误。
我对 DBCC CHECKDB 报告的最低恢复级别 repair_allow_data_loss 感到困惑。这不应该重建吗?
我在这里遗漏了一些明显的东西吗?
我已经使用Get-MSSQLLinkPasswords
Powershell 脚本很长时间了,它帮了我大忙。该脚本解密特定 Windows 服务器上所有链接服务器的密码,并以纯文本形式显示给您。此功能甚至已合并到dbatools Copy-SqlLinkedServer
脚本中。
运行脚本有安全警告,如下所示
该脚本必须在 MSSQL 服务器上本地运行(因为 DPAPI 需要访问本地计算机密钥)。执行脚本的用户还必须拥有对所有数据库实例的系统管理员访问权限(用于 DAC 连接)和 Windows 服务器上的本地管理员权限(用于访问注册表中的熵字节)。此外,如果启用了 UAC,则必须以管理员身份运行脚本。
在最近升级到 SQL Server 2016 之前,此脚本一直运行良好。我想知道是否有其他人在 SQL Server 2016 下遇到过此脚本的任何问题。也许 SQL Server 2016 中的某些安全模型已更改并且此脚本无法解密密码现在。
如果时间允许,我会尝试看看这个dbatools Copy-SqlLinkedServer
脚本在 2016 年是否仍然有效。