小编JHF*_*HFB的帖子

我们的数据库中有一些表的数据类型为 varchar(8000)，其中该列中最长的实际值为 75。当我们在该列上放置索引时，我们会收到预期的警告，即最大允许的索引长度为 900 字节.

实际数据类型是否会影响该索引的有效性？也就是说，既然实际数据远低于900字节，那么索引还能用吗？

就其价值而言，我正在尝试修改数据类型，因为这对于列的目的来说是一个荒谬的限制，但我不确定争论的激烈程度。

我希望提高 SQL Server 2008 中视图的性能。这个视图存在于一个报告数据库中，非技术人员广泛使用该数据库来基本上对一个人的所有这些属性进行非规范化。

这是一个非常复杂的长期运行视图。我们有超过 1900 万人，每一列都有很多逻辑。例如，有一个关于一个人是否已故的指标，它依赖于三个 CTE（公共表表达式）和一个 case 语句。

基本上，这是一场噩梦。

我需要想办法提高性能。无法将其更改为表格 - 数据必须准确无误。将其更改为索引视图是正确的 - 它使用来自多个数据库的数据。我无法真正修改列结构，因为它会破坏许多现有报告。

工具箱中是否有可能有帮助的工具？我想知道存储过程或函数是否有帮助。也许是一个带有计算列的表？我将能够每晚提取此人的识别信息并将其存储到表格中，但绝大多数列依赖于实时数据。

我有一个应用程序数据库的复制副本。我正在探索如何更改约束和索引以更好地满足我们的报告要求。因为这是应用程序数据库的副本，所以我知道参照完整性正在检查中。

此副本中的主键和外键关系有何影响？如果我仔细设置我需要的索引，外键有什么好处吗？有什么害处吗？

我使用的是 sql express 2008 r2 express 版。

是否可以独立于导致触发器触发的语句的事务在触发器内部进行写入？

我有触发器用于对我的数据库中的某些表进行简单审计。我有一张用于保存审计数据的表（查看此处了解详细信息）它工作正常，除非我不希望在事务回滚时审计数据消失。所以我想将审计数据写入审计表，独立于导致我的审计触发器触发的语句的事务。

我为 SSRS 2008 创建了一份报告，其结果如下。

我希望实现的是粉红色，AD 中的那些结果在 AM 和 PM 下，文本居中，即合并的单元格。

工作日和上午/下午是基于我表中字段的矩阵中的组标题。为了显示数据，我使用了矩阵数据区域内的表格。

我已经阅读了其他关于在表中创建一个附加行的其他帖子，该行将 2 个单元格合并在一起，使用表达式在不使用时隐藏该行，尽管我没有设法让它正常工作。

2012 年 3 月 28 日更新：
我设法让 AD 出现在 AM 和 PM 下。我所做的是删除 AM/PM 列组并在 Weekdays 组下创建 2 个单元格，并在这些单元格中输入文本 AM 和 PM。然后我在矩阵的数据部分创建了 2 行，底行有 2 列。在这些单元格中的每一个中，都有一个带有表达式的表格

=IIF(Fields!SessionIdentifier.Value="AD","AD",Nothing)

每个表中的行可见性是使用表达式设置的：

=IIF(Fields!SessionIdentifier.Value="AD", False, True)

我现在想做的是在矩阵为空时隐藏矩阵数据区域中的顶行，但我还没有想出执行此操作的表达式。

我正在尝试将 AdventureWorks 示例数据库添加到 SQL Server 2012，但收到一条错误消息：

消息 5133，级别 16，状态 1，行 1 文件“C:\Users\A\Documents\SQL Server Management Studio\Data\AdventureWorks2012_Data.mdf”的目录查找失败，操作系统错误 5（访问被拒绝。） .

（这是索引消耗内存的延续吗？）

一位数据库开发人员认为我们遇到了内存问题。他发现一些标准查询的运行时间有所增加——从不到 10 秒增加到大约两分半钟。他查看了服务器上的任务管理器，发现内存使用率很高，现在想要获取一些当前分配给操作系统的内存并将其释放给 SQL Server。

我们使用的是 SQL Server 2008，64 位机器，未启用 AWE，最小 4096 MB，最大 10240 MB。

我发现 Brent Ozar 的A Sysadmin's Guide to Microsoft SQL Server Memory表明任务管理器不可靠。我还发现我们的页面预期寿命并不表示内存压力。（通过Pinal Dave 的查询检查。）

我还应该看哪里？我还应该检查什么？我想向数据库开发人员报告以确认他的怀疑或证明他们不正确。

编辑：修改了我的实际问题。我欣赏并同意，由于内存问题以外的原因，这些查询很可能会变慢。然而，我处于一种情况，我需要证明内存不是全面的罪魁祸首。也就是说，证明少数查询由于其他原因而变慢并不能完成我的任务。我想了解我可以从哪里获得此类信息以及我应该检查哪些指标。

我想知道是否可以为 SSRS 创建一个“内部”组，而不必将该组添加到 ReportServer 框本身。

我无权使用该框创建组和/或将用户添加到现有组。我知道这是一种（唯一的方法？）可以在 SSRS 界面中为组分配权限的方法。

我确实拥有 SSRS 界面中所需的所有权限。我在 ReportServer 实例上拥有系统管理员系统角色，以及对 ReportServer 数据库的完整系统管理员权限。

我正在尝试简化我们的安全结构，如果我可以创建一个组，将用户分配到该组，然后授予该组的权限，那就太好了。但我似乎只能为盒子上设置的组分配权限。

有任何想法吗？

编辑：Active Directory 组不是我的选择。:(

我们在服务器 A 上有一个应用程序数据库，它使用推送事务复制复制到服务器 B。报告是在服务器 B 上的复制副本上完成的。

我们在复制过程中遇到问题，它获得了一个共享的意向排他(SIX) 锁，死锁的SELECT语句，获得了一个意向共享(IS) 锁。该SELECT语句被选为死锁牺牲品，查询终止，报表开发人员不高兴。

我应该在哪里解决这个问题？我们应该NOLOCK在SELECT语句中添加提示吗？更改一些复制设置？这里是否存在更大的问题，例如糟糕的数据库设计？

我们一直收到来自特定 SSRS 用户的投诉，称她的报告运行缓慢。我在ExecutionLog表中调查ReportServer数据库发现了一些奇怪的东西。

相当一致，TimeDataRetrieval比其他用户长得多。双方TimeProcessing并TimeRendering其他用户的平均值附近。

我很困惑。这些报告都使用作为服务帐户运行的相同共享数据源。我想如果这是一个糟糕的用户计算机问题，我会看到渲染时间的差异。如果有网络问题也一样。

我不知道还能去哪里找 - 有什么想法吗？