小编Mag*_*ier的帖子

我想创建被授予访问权限的登录名

• 所有用户数据库

• 查看所有定义

• 选择所有表的所有记录

对我来说，将登录名分配给每个数据库并将其添加到自定义 db 角色或每个 db 中的默认 db 角色（如 db_datareader）似乎开销太大。

相反，我尝试使用用户定义的服务器角色。

• 但是如何将所需的权限分配给用户定义的服务器角色以允许查看所有数据库的任何定义和 db_datareader？

• 这甚至可能吗？

我知道AUTO_SHRINK在 SQL Server 数据库上配置的缺点。最近，在一个新环境中，我发现了几台启用了 Auto Shrink 选项的生产服务器。

现在，在更改此配置之前，我想知道：由于 auto_shrink 事件从 25% 的未使用空间开始，我想知道这是否和/或何时在 SQL Server 上实际发生。我试图找到相关的 SQL-Event-Logfile 条目。我开始手动缩小测试数据库，但没有显示事件日志条目。

有谁知道如何找出最近几天或几周内 SQL Server 发生收缩的时间？

我发现自己处于继承了数据库的情况，人们抱怨数据库性能。我确定了大约十几个没有聚集索引或没有精心规划的聚集索引的表，其中一些数据量大且经常使用。我实际上正在努力找出为堆实现 CI 的最佳候选者。经过大量阅读后，我仍然不知道该怎么做。我知道这取决于。所以我想给出一张表作为样本，希望得到一些建议。

该表有 122 列。是的，我知道...它包含大约 800 000 行。结构（摘录）：

CREATE TABLE [dbo].[tO](
[ID] [uniqueidentifier] NOT NULL,
[MaID] [uniqueidentifier] NULL,
[OrID] [uniqueidentifier] NOT NULL,
[UsID] [uniqueidentifier] NOT NULL,
[CrUsID] [uniqueidentifier] NOT NULL,
[SuID] [uniqueidentifier] NULL,
[SOID] [uniqueidentifier] NULL,
[DeA1ID] [uniqueidentifier] NULL,
[DeA2ID] [uniqueidentifier] NULL,
[PayID] [uniqueidentifier] NULL,
[MAdID] [uniqueidentifier] NULL,
[ShID] [uniqueidentifier] NULL,
[SessID] [varchar](32) NULL,
[OrUID] [uniqueidentifier] NULL,
[PurOfUID] [uniqueidentifier] NULL,
[AddiUID] [uniqueidentifier] NULL,
[SupUID] [uniqueidentifier] NULL,
[PayTID] [uniqueidentifier] NULL,
[OPSID] [uniqueidentifier] NULL,
[StoRSID] [uniqueidentifier] NULL,
[PayMeID] [uniqueidentifier] NULL,
... …

SELECT *不幸的是，我们的应用程序开发人员对我们的数据库系统运行了大量查询。

sys.dm_db_missing_index的缺失索引建议包含很多案例，表明为这些案例创建 100% 覆盖非聚集索引。例如，实际上有一个包含 3 个索引列的索引和建议的额外 25 个包含的列。带有建议的键列的其他索引已经就位，但随后需要查找。

我对此感到有些惊讶。然而，由于基础查询运行非常高的成本往往和建议的指数自带的约50％这也许是一个有趣的选择产生影响。

我知道支持这些查询不是最佳实践和糟糕的设计，但我怀疑这是否可以在足够的时间内改变，所以我想知道这些索引是否会有所帮助或产生更多的成本而不是收益？

是否有规则或我只需要尝试/错误后果？

• 行数在 60,000 到 210 万之间。
• 缺失的索引 DMV 告诉我平均（在多台服务器上）可以为查询执行 2424 次搜索操作（这是一个持续约 3 个月的数字，平均 19 次的查询成本可能会受到约 50% 的积极影响） .
• 删除SELECT *是最好的，但我被要求按原样优化它，并且由于 SQL Server 本身建议这样做，我认为无论如何都值得考虑。
• 现有的查询并不是很慢，< 1 秒，但我认为这也很主观。执行计划告诉关键查找成本占整体的 80%，所以我想无论如何保存它可能是可取的。

• 我做了一些没有/使用 100% 覆盖索引的测试。结果：

  SELECT *：成本之前：0,026 之后：0,00329（使用新索引）= -88% 改进
  UPDATE：之前：0,043333 之后：0,0533（使用 ix）= +20%
  INSERT：之前：0,1133 之后：0,1233 (ix 未使用)=equal
  DELETE: before: 0,645 after: 0,655 (ix used) =equal.

  结论：它对选择的调整比减缓变化要多得多。为什么不申请？

我已经阅读了很多关于索引维护以及重组、重建、在线、离线、TEMPDB 和时间安排的所有优点/缺点的文章，现在我比以往任何时候都更加困惑......

目标是用更灵活和碎片化驱动的解决方案替换一些简单的重建维护计划，以遵循最佳实践并执行所需的操作而不是不需要的操作。因此，按照Kendra Little和许多其他聪明人的类似建议，我转向了Ola Hallengreen 的解决方案。

到目前为止，一切都设置正确，按照Brent Ozar 的建议创建两个不同的工作（一个侵入性较小的工作，例如每天运行的重组/在线重建工作和一个周末工作，做更多的工作，可能是离线处理）并准备好了。

但我不确定，也不太关心（副作用）的影响。

因为我们有几个非常大的表，所以我试图根据我在这个问题中找到的以下代码，找出索引重建对事务日志的影响，观察日志文件大小和 entris 增长数：

backup log myDB to disk = 'NUL'
-- check log space/usage:
dbcc sqlperf (logspace)
-- query index log records 
SELECT LogRecordsGenerated = COUNT(*)  FROM sys.fn_dblog(NULL, NULL)  WHERE AllocUnitName = 'dbo.TableName.indexName' 
-- COMMINT THE INDEX OPERATION (Online / Offline)
-- Check the above values again...

令人惊讶的是，索引重建离线任务需要日志空间并生成事务日志条目，而在线则不需要！我期望它反过来......？

我找不到答案的问题是：

• 重建联机或脱机作业将如何影响日志文件增长？我该如何衡量？有没有更好的办法？
• 我必须在我的数据文件中为重建过程保留多少空间？我发现了大约 110%-120% 的索引大小的提示（例如在这个 MS 文档中）。如果我的所有索引一起使用大约 10 …

有没有人有一个很好的方法来手动为索引创建特定的碎片，理想情况下不增加基础表中的行数？我需要这个来进行索引重建基准测试。为了测量相同表/索引的特定碎片率所需的时间，我必须重新创建我想尝试的特定碎片级别。

通过或多或少的随机表更新来创建这种碎片是非常耗时且困难的。有任何想法吗？

更新：这是我的测试表。它实际上有大约 540K 行，

USE [Test]
GO

/****** Object:  Table [dbo].[tFrag2]    Script Date: 12/22/2015 15:33:51 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[tFrag2](
    [a] [int] NULL,
    [b] [varchar](1000) COLLATE Latin1_General_CI_AS NULL,
    [c] [varchar](1000) COLLATE Latin1_General_CI_AS NULL,
    [d] [decimal](18, 0) NULL,
    [e] [int] NULL,
    [uid] [uniqueidentifier] NOT NULL,
    [dt1] [datetime] NULL,
    [dt2] [datetime] NULL,
    [dt3] [datetime] NULL,
    [dt4] [datetime] NULL,
    [dt5] [datetime] NULL,
    [dt6] [datetime] NULL,
    [dt7] [datetime] NULL,
    [dt8] [datetime] NULL, …

我需要一个解决方案来监视表权限更改：

• 如何监控 SQL Server 2008 R2 中特定表上特定或任何用户的授予权限的每项更改？

是否可以找出谁使用了 SQL-Server 登录？

让我们假设我们怀疑有人滥用 SQL 登录名，该登录名本应由应用程序仅用于登录 SQL-Server。使用SQL登录的域用户是否记录在任何地方，以便我们得出谁使用它的结论？

我有一个跟踪文件，包括由服务器端跟踪创建的 TEXTDATA 列。一些跟踪查询非常长。

如果我在 Profiler 上重新打开跟踪文件，则会完整显示相关的长查询 - 它有 340 行文本和 10951 个字符。

但是在我将跟踪文件导入 SQL-Server 表后，相关查询似乎被截断了。该表有一个由fn_trace_gettable方法创建的 ntext 列。

我使用不同的方法查询表：SSMS 中的文本输出（配置了最大数量的字符）在第 52 行中断输出。 SSMS (*.rpt) 的文件输出也被截断，这里查询在第 250 行被截断.

所以现在我想知道是否有可能将整个查询从跟踪文件中提取到 SQL-Server 表中，以及如何获取？

我们新安装和配置的 SQL Server Always On Availability Failover Cluster with SQL Server 2016 Enterprise Edition 以四个实例和六个节点运行。它包括每个集群节点资源中的数据库引擎服务和代理服务。一切正常。

但是现在我们发现填充文本过滤器守护程序启动器 (FTFDL) 服务存在于每个节点上并且随机运行，与 Sql-Instance 当前运行的事实无关。一些节点有四个 FTFDL 服务在运行，而只有一个实例位于那里。其他人有其中一两个在运行。

问题：我们是否应该将此服务添加为集群资源？为什么它在故障转移集群实例上随机启动和停止，导致多个服务处于活动状态而相关实例处于活动状态？这里的最佳实践是什么？