标签: sql-server-2012

我想tempdb分成两个大小相同的文件，以提高数据库的性能。

我想知道这两个数据文件是否可以在同一个磁盘上，与日志和用户数据文件分开？

在重新启动无响应的主机 WINTEL 服务器导致 SQL Server 2012 SP3 实例重新启动后，我有一个 SQL 代理日志传送复制作业（它使用代理帐户访问日志备份所在的 NAS 文件共享）因此错误而失败：

验证代理 MyDomain\MyProxyAccount 时出错，系统错误：用户名或密码不正确。

我试图将正确的密码重新应用到代理的凭据并重新创建一个新的凭据，但都因此错误而失败：

此操作所需的密钥似乎已损坏。（Microsoft SQL Server，错误：15507）

我读过一个 MSDN 页面，上面写着：

SQL Server 使用加密密钥来帮助保护存储在服务器数据库中的数据、凭据和连接信息。服务主密钥在 SQL Server 实例首次启动时自动生成，用于加密链接服务器密码、凭据和数据库主密钥。

我不确定如何继续。我的服务主密钥有问题吗？如果是这样，有人可以建议如何解决此问题或指导我在线进一步阅读吗？

更新：我发现 SQL Server 日志中的条目（在主机 WINTEL 服务器重新启动后重新启动实例时写入）进一步表明问题出在服务主密钥上：

无法使用其加密之一解密服务主密钥。服务主密钥初始化期间发生错误。

我仍然欢迎任何关于如何解决这个问题的建议......

我在一家经济咨询公司工作，我们所有的数据都保存在 SQL Server 11 (2012) 中。我们的数据基本上由一个日期列、一个原始数据列、几个计算列和一个具有用于区分每组数据和下一组数据的短代码的列组成。

我们有数千个这样的集合，它们都加载到同一个表中（总共约 250 万行），然后从查询中提取和排序。它们通常按日期排序，从第一个月开始，逐月移动到最后一个月。每个系列的开始和结束日期从一年到 100 多年不等。

最近，我们遇到了一些随机数据部分消失的问题。整行只是向上和离开，这使得找到这些丢失的行有点困难，而无需每个月都检查是否丢失了一个月，这对于 250 万行的表来说是一项有点不可能完成的任务。

我的老板让我编写一个查询/存储过程，它将查看这个巨大的表并查看哪些集合缺少行以及它们在哪里。

我一直在努力解决这个问题，这个问题有点超出我的 SQL 技能，我似乎无法在网络上的任何地方找到任何有类似问题的人。我将经历我已经拥有的东西，也许有人至少可以告诉我我是否朝着正确的方向前进，并可能提供一些关于我应该从哪里开始的见解。

我在网上找到的最佳解决方案是使用 CTE 创建一个临时日期表，然后将它们与原始表进行比较。如果我只是扫描一个特定数据集中的问题，这很有效，但我在同一个表中有许多数据集，所有数据集都有不同的开始和结束日期。所以我还是选择了它，希望我最终可以扩展它以搜索其中的很多。这是我的代码：

declare @startDate Date, @endDate Date 
set @startDate = '2000-01-01'
set @endDate = '2016-11-01'

;with GetDates As  
(  
select @startDate as TheDate
UNION ALL  
select DATEADD(MONTH,1, TheDate) from GetDates
where DATEADD(MONTH,1, TheDate) <= @endDate
)

SELECT TheDate,SHORTCODE,MonthYear 
From GetDates
LEFT OUTER JOIN VWTBL_INDICATOR
ON GetDates.TheDate=VWTBL_INDICATOR.MonthYear
AND VWTBL_INDICATOR.SHORTCODE='RMI WEST'
OPTION(MAXRECURSION 1000)

'RMI West' 将是标记此特定数据集的短代码，它缺少从 2004 年 11 月到 2005 年 3 …

考虑我有一个名为 sql_login 的登录名。登录尝试失败sql_login后，我可以锁定登录吗5？

当我们创建登录时，我们可以看到有一个名为密码策略检查图像的选项。但是没有提到锁定密码

在N尝试登录失败后，Sql Server 中是否有锁定登录的选项

我有一个 SQL Server 表（SQL Server 2012 SP3 标准版），它存储了不同组织的一堆配置信息（基本上是文本 blob）。架构是这样的：

[ConfigurationID]       INT IDENTITY (1,1) NOT NULL,
[OrganizationID]        INT NOT NULL,
[TimestampUtc]          DATETIME NOT NULL,
[ConfigurationData]     NVARCHAR (MAX) NOT NULL,
[ChangedBy]             NVARCHAR (256) NOT NULL,
[Comment]               NVARCHAR (MAX) NOT NULL,
[ChangeType]            INT NOT NULL

该TimestampUtc会一直增加（我将永远不会成为插入“回过时”的条目到表），行永远不会被更新（我只插入新行）。对于某些OrganizationIDs 会有很多行，对于一些非常少，并且OrganizationID任何时候都可能会插入一个新行。

如果需要，我可以保证的唯一性TimestampUtc（但如果有一个不需要的解决方案会很棒）。

INSERT 相对较少（每天最多几十次，但通常比这少得多），读取非常频繁（基本上是对我的应用程序的每个 Web 请求）。

我的目标是：

• 无论表的大小如何，获取给定ConfigurationData的最新信息都应该非常快TimestampUtcOrganizationID
• INSERT 性能并不重要，但我想尽可能避免可怕的索引碎片（所以我对唯一聚集索引的第一个想法OrganizationID ASC, TimestampUtc DESC可能不是一个好主意）。

问题

我知道我可以非规范化并只将最新ConfigurationData值存储在一个表中，并将先前值的历史日志存储在另一个表中，但是仅使用一个表是否可以实现我的目标？最好的方法是什么？（即最好的索引结构是什么？我需要更改有关表架构等的任何内容吗？）

我正在使用 SQL Server 2012，其中有一个表[abc]，其中有一个名为[Information][XML] 类型的列。

此列具有以下值 -

<Information>
  <Groups>
    <Group Name="Monitor">
      <Items>
        <Item>
          <Name>Cid</Name>
          <Value>2323232323</Value>
        </Item>
        <Item>
          <Name>Tid</Name>
          <Value>6656565656</Value>
        </Item>
      </Items>
    </Group>
  </Groups>
</Information>

如何编写可以查询此列并进一步提取值的 SQL 查询[Tid]？

我的数据库在具有 32 个核心处理器的 SQL Server 2012 上运行。根据sp_blitz（Brent Ozar），我们需要启用跟踪标志 8048。

我们应该在 2012 年启用这个标志，还是只推荐在 2014 年以后启用？

当我使用 SSMS GUI 在 varchar(1024) 列上创建索引时，它失败并显示以下消息：

"Warning! The maximum key length is 900 bytes. The index 'XXX' has maximum length of 1024 bytes. For some combination of large values, the insert/update operation will fail." 

但是，当我使用 SQL（不是 GUI）时，同样的操作成功了。我不确定为什么会发生这种情况，但这是否意味着索引会一直工作，直到超过 900 字节的数据真正插入到列中？

（该列当前没有超过 900 字节的值。）

环境： - SQL Sever 2012 - Windows Server 2008 R2 SP1

我需要确认我们的 SQL Server 中是否曾经存在过一个特定的表。是否存在可用于列出 SQL Server 实例中所有删除的数据库的现有脚本或方法？

我们为连接到其 SQLServer 数据库的客户编写了一个简单的“客户端”应用程序，对“属性”运行大约 360 次查询，并将该数据作为我们称为“cProp”的 .Net 对象返回。

查询的复杂性各不相同，但最长的可能需要 400 毫秒。当我们最近为 60 个属性运行它时，整个运行大约需要 3 分钟。客户决定将他们的数据库移动到我们之间 65 毫秒的远程服务器。结果，相同的查询需要 51 分钟。

现在我 99% 确定问题是行检索，但我需要证明这一点。DBA 对该过程进行了跟踪，但之前从未使用过它，我很沮丧地发现它包含的信息如此之少。我所看到的是，它花了不到 4 分钟的服务器时间。这加强了我的信念，即问题出在行检索上。

但我如何衡量呢？跟踪不返回关于行数或总数据大小的任何信息 - 我做错了吗？我也知道批处理发生在服务器之外，那么我们如何知道那里发生了什么？一般来说，可以这么说，如何调试“服务器外部”发生的问题。