标签: sql-server-2012

我怀疑这是一个问题，因为我们达到了 SQL Server 的 50 个实例的最大限制。在极限情况下，它自然不会安装更多实例。但是，它似乎也不会卸载它们。那更糟。

在为实例选择 SQL 引擎后点击下一步时，它会挂在“选择功能”对话框中。

我没有找到很多关于这方面的信息。最有趣的是：http : //social.msdn.microsoft.com/Forums/sqlserver/en-US/24a1e5f3-25f3-48c8-973a-4c6a18578e42/trying-to-uninstall-1-of-50-sql -server-2008-r2-express-hangs-on-please-wait

它还建议使用setup.exe一些参数来卸载实例，但如果不启动 GUI 并进入失败的正常卸载，我就无法这样做。

海拔没有任何作用。重新启动没有帮助。日志只说“被用户取消”，因为我最终必须杀死它。在那之前没有什么明显的。验证都是绿色的。

安装程序说它是 SQL Server 2012 SP1 - 所有实例都在 11.0.2100。

我选择回答/关闭我自己的问题，因为 Microsoft 已关闭状态为“无法修复”的故障单。

希望他们已经为 SQL Server 2014 解决了这个问题，但我没有也不打算自己测试，他们也没有提供关于关闭票证的任何其他评论。

表T_PIN有 300,000 个引脚和T_POLYGON36,000 个多边形。T_PIN有这个索引：

CREATE SPATIAL INDEX [T_PIN_COORD] ON [dbo].[T_PIN]
(
[Coord]
)USING  GEOGRAPHY_GRID 
WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), 
CELLS_PER_OBJECT = 128, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY];

T_POLYGON 已：

CREATE SPATIAL INDEX [T_POLYGON_COORD] ON [dbo].[T_POLYGON]
(
[COORD]
)USING  GEOGRAPHY_GRID 
WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), …

我有一个在亚马逊 EC2 上运行的 SQL Server 2012 数据库。我创建了一个能够创建、编辑和删除数据库的用户。我为新用户提供了dbcreator服务器角色。

我的用户可以远程连接并成功运行create database foo;命令。但是当用户尝试再次使用drop database foo;该命令删除数据库时失败并出现以下错误：

Warning: Fatal error 615 occurred at Feb  1 2014  5:15PM.
   Note the error and time, and contact your system administrator.
ErrorCode: 21

即使选定的数据库是master（所以我认为不是因为它正在使用中）。当我以管理用户身份再次登录时，该命令会成功。

我检查了新创建的数据库，并且我的用户已db_owner按照我的预期在数据库中分配了角色，所以我的理解是，这应该是该用户能够删除他们刚刚创建的数据库的足够权限。

根据http://technet.microsoft.com/en-us/library/ms178613.aspx，db_owner角色应该有足够的权限。“需要对数据库的 CONTROL 权限，或 ALTER ANY DATABASE 权限，或 db_owner 固定数据库角色的成员身份。”

我查找了错误 615 并发现“找不到数据库表 ID %d，名称为 '%.*ls'。” 这对我来说毫无意义。http://technet.microsoft.com/en-us/library/aa937592(v=sql.80).aspx

Sql 服务器版本信息：Microsoft SQL Server 2012 (SP1) - 11.0.3368.0 (X64) /n May 22 2013 17:10:44 …

SQL Server的数据库镜像功能即将消失：

此功能将在 Microsoft SQL Server 的未来版本中删除。避免在新的开发工作中使用此功能，并计划修改当前使用此功能的应用程序。请改用AlwaysOn 可用性组。

有谁知道什么时候？高可用性（和快速恢复）数据库有哪些选择？

我注意到 2 台服务器 HA 集群上的奇怪行为，我希望有人能证实我的怀疑，或者提供一些其他解释......这是我的设置：

• 2 台服务器 SQL 2012 SP1 安装
• 已为一些数据库启用 SQL AlwaysOn HA
• CPU 为 2.4GHz，4 核
• RAM 为 34 GB（它是一个 AWS 实例，因此是奇数）
• 资源利用率比较低——每台服务器有14+GB的空闲内存，SQL没有限制使用多少内存
• 磁盘访问时间很好 - 很少超过 15 毫秒/读或写
• 数据库不大 - 1 GB、1.5 GB、7.5 GB
• SQL 服务器进程使用 16 GB 专用字节，15 GB 工作集

总体而言，没有注意到资源问题。现在是奇怪的部分。SQL 没有重新启动（进程已经运行了将近 6 个月），但似乎每大约 50 天，页面预期寿命计数器就会下降到（几乎）0。直到那时它稳步攀升，没有下降。这是一个性能图：

当我查看计数器数据时（我没有确切的数字，只是每小时汇总），似乎 PLE 计数器值每次都达到了大约 4,295,000 秒（大约 50 天）（至少每次我有数据时）。

我疯狂的理论是，PLE 数以毫秒为单位作为无符号长整型（其限制为 4,294,967,295）并在 49.71 天时重置，无论是设计还是错误。这将解释两台服务器的行为以及它们具有的相同模式。或者它可能是完全不同的东西，我只是没有任何意义。:)

有没有人见过这样的事情，或者可以解释这种行为？

PS我看到了这篇文章，但我的情况似乎略有不同。

PPS 这是一个转贴 - 我最初把它贴在这里，但被告知这里的观众更合适。

谢谢！

考虑以下两个语句：

PRINT CONVERT(NUMERIC(38, 0), 0x0100000001, 0);
PRINT CONVERT(NUMERIC(38, 0), 0x0100010001, 0);

两个语句都返回-1；这不是不正确，因为第二个二进制值比第一个值高 65,536 十进制，不是吗？

这肯定不是由于无声截断？

如果我运行以下语句：

PRINT CONVERT(NUMERIC(38, 0),   0x00000001, 0);
PRINT CONVERT(NUMERIC(38, 0),   0x00010001, 0);

我遇到了以下错误：

Msg 8114, Level 16, State 5, Line 1
Error converting data type varbinary to numeric.

我如何诊断这里发生了什么？

我在 SQL Server 2012 v11.0.5058 上运行它。结果在 SQL Server 2008 R2 SP2、SQL Server 2005 和 SQL Server 2000 上相同。

我从一篇博客文章中得到了这个查询：

SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Buffer Manager%'
AND [counter_name] = 'Buffer cache hit ratio'

帖子说它会给我一定比例的缓存命中率。它似乎表明它将是一个 0-100 的值（它显示的结果为 87）。

但是当我运行它时，我得到了非常高的数字。下面是一个例子：

object_name               counter_name             cntr_value  
SQLServer:Buffer Manager  Buffer cache hit ratio   9990

这是否意味着 99.90%？

如果不是，那是什么意思？我怎样才能得到真正的价值？

注意：我得到的值低至257，高至352363

如果它是相关的，这里有一些其他服务器统计信息：

• 页面预期寿命：145
• 页面读取/秒：1,380,009,009

我将创建一个包含两个字段的表 - IDasBIGINT和IPAddressasvarchar(45)或者varbinary(16)。这个想法是存储所有唯一的 IP 地址并使用引用ID而不是IP address其他表中的实际地址。

通常，我将创建一个存储过程，该过程返回ID给定的IP address或（如果未找到地址）插入地址并返回生成的ID.

我期望有很多记录（我无法确切说出有多少），但我需要尽快执行上面的存储过程。所以，我想知道如何以文本或字节格式存储实际的 IP 地址。哪个会更好？

我已经编写了SQL CLR用于将 IP 地址字节转换为字符串和反向转换的函数，因此转换不是问题（同时使用IPv4和IPv6）。

我想我需要创建一个索引来优化搜索，但我不确定我应该将该IP address字段包含在聚集索引中，还是创建一个单独的索引以及使用哪种类型的搜索会更快？

我目前正在使用更改数据捕获 (CDC)来跟踪数据更改，并且我希望跟踪提交进行更改的查询的客户端的主机名和 IP 地址。如果有 5 个不同的客户端通过相同的用户名登录，一个人面临着跟踪这 5 个中哪一个触发了查询的难题。我发现的其他似是而非的解决方案包括使用以下命令更改 CDC 表：

ALTER TABLE cdc.schema_table_CT 
ADD HostName nvarchar(50) NULL DEFAULT(HOST_NAME())

但是，这将返回触发查询的服务器的主机名，而不是触发查询的客户端的主机名。

有没有办法解决这个问题？有助于记录客户端的主机名或 IP 地址（或某种其他类型的唯一身份）的东西。我不想使用触发器，因为它会减慢系统速度，而且 CDC 还会生成系统表，因此显然不可能使用触发器。

我一直在 sql 错误日志上发现奇怪的错误消息：

Bocss：每小时都会发生同样的僵局——需要调查

根据以下示例，其他 SPID 的错误日志中还列出了许多重新编译：

2015年9月4日14：30：10，spid64，未知，用于SQLHANDLE 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000检测到可能无限的重新编译起始偏移1038结束偏移2600的最后一个重新编译原因是2. 2015年9月4日14时三十分十秒，spid150，未知，是为SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000起始偏移量998检测到的一个可能的无穷的重新编译结束偏移2520。最后重新编译原因是2. 2015年9月4日14：30：09，spid67，未知检测到可能无限的重新编译为SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000起始偏移1064结束偏移2652是2. 2015年9月4日14最后重新编译原因：30：09，spid163，未知，是为SQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle探测到一个可能无限的重新编译0x06000400E7C7BF0EF0EB68A52C00000001000000000000000000000000000000000000000000000000000000开始偏移量1028结束偏移2580的最后一个重新编译的原因是2。

是什么导致了这种情况？

看起来我没有缓存中的计划了。

按照这篇文章的建议 http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx

然后作为安全措施禁用全文目录，这没有区别，所以我完全回滚了更改（删除了新对象等）。这也没什么区别，最后似乎唯一阻止它的是重新启动 SQL 实例，这立即解决了问题。

这也解决了我的问题，但是，我仍然要找出造成这种混乱的原因是什么？