我正在接管一个项目，该项目涉及删除和限制我们服务器场中所有数据库用户的权限。（娱乐时间）
当前受限的权限之一是 db_owner 权限。
正在逐案审查此权限，但常见的更改是将 db_owner 权限替换为以下内容：
我想定义两者之间的确切区别（以通知客户）。
但是，据我所知，两者之间的区别应该是：
所以实际上他们会失去：
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]
一旦 db_owner 被上面的四个角色替换，用户是否还会丢失任何其他内容？
这实际上在安全方面起到了很大的作用吗？
我一直在考虑在我们的一些开发机器上恢复一些磁盘空间。
这些机器没有备份，没有直接开发，也没有得到很好的维护。
任何恢复都是从 PRD 或 PRE-PRD 到 DEV 环境，在这个特定的 DEV 环境中没有什么是关键的。
这些数据库上的恢复模型必须保留，FULL因为它是这样规定的（尽管没有进行实际备份）。
由于这些数据库在某些情况下已经存在了很长一段时间而没有备份，我正在寻找一种适当的方法来缩小它们的日志。
我发现了两种可能达到目的的方法：
BACKUP LOG [databasename] TO DISK=’NUL:’
其次是收缩日志。
或者：
ALTER DATABASE [databasename] SET RECOVERY SIMPLE;
ALTER DATABASE [databasename] SET RECOVERY FULL;
其次是收缩日志。
我的实际问题：
这两种方法有什么区别？
有什么我想念/忽视的东西吗？
我最近不得不多次重新创建用户。
为了方便创建用户，我会右击用户并选择script login as, create to, New Query Editor Window。
但是，这样做之后，我收到一个语法错误：
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near 'ROLE'.
这里发生了什么？
我有一个使用 Windows 身份验证添加到 SQL Server 2008 R2 计算机的用户。
他几个月前离开了公司，此时他的 AD 用户被禁用并转移到另一个 OU。
用户数据库登录和用户不受影响。
然后他回到公司，他的 AD 用户被重新激活，并移动到正确的 OU。
但是，他所有的数据库登录当前都出现登录失败。
如果采取以下措施，问题就会得到解决：
这是一种不切实际的方法，因为它意味着跟踪每个登录并重新创建它。
我怎样才能以更实际的方式解决这个问题？
没有更实际的解决方案，这个问题的原因是什么？
我正在对高流量（16000 多个用户，峰值估计 1000 多个并发）Microsoft Dynamics 数据库进行性能测试。
服务器几个月前上线了，我正在做一些测试，看看它是如何处理当前流量的。
在工作时间检查一些性能计数器时，我在目标和总服务器内存中发现了一个奇怪的问题。
虽然我只会在目标内存明显高于总内存时将其标记为问题，但结合其他计数器（取决于差异量）可能会导致此处的结果有些奇怪。
使用：
SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters
where (object_name like '%Buffer Manager%' and counter_name like '%page life%')
or (object_name like '%Memory Manager%' and counter_name like '%memory grants pending%')
or (object_name like '%Memory Manager%' and counter_name like '%target server memory%')
or (object_name like '%Memory Manager%' and counter_name like '%total server memory%');
我得出以下结果：
counter_name | cntr_value
------------------------------------------------
Page life expectancy | 14887
Memory Grants Pending | 0
Target Server Memory (KB) | 44040192
Total Server Memory (KB) | 44040184
显然目前没有内存压力，并且页面预期寿命高于要求。但是，在某些时候，sql server 似乎正好缺少 8 KB 内存。
这些数字对我来说似乎有些奇怪，但我无法确定。
这是否表明 sql server 在某些时候处于内存问题的边缘？
我是否正确地认为因为这些数字非常相似，所以我现在可以忽略它，并在经过相当长的时间后再次测试？
我收到算术溢出错误，但似乎无法查明具体情况。
我最近不得不调整一些存储过程，以允许输入未来的日期。
随后的数据提取的以下部分现在因算术溢出错误而失败：
SELECT
CONVERT(varchar(8),DATEDIFF(week, CONVERT(date,convert(varchar(8),Column1)), GETDATE()))/[Column2]
FROM Table1;
我不完全确定为什么会发生此错误。
任何给定条目中的字符不超过 8 个，将其更改为varchar(max)不会执行任何操作（正如您所期望的那样）。
删除/[Column2]确实会删除错误，但我终生无法弄清楚原因。
编辑：
CAST([Column2] as numeric(8))做的伎俩。
然而，select max(len([Column2]))最长的字段是 2 个字符长。
[Column1]是小数 (32,0)
[Column2]是小数 (3,0)
发生什么了？为什么这会导致问题？
在审查我们的一些代码时，一位同事认为他对总是在TRUNCATE TABLE没有真正其他用途的情况下编写TRUNCATE.
谷歌搜索，我确实找不到TABLE需要该零件的具体原因。
我错过了什么？TABLEin有一些历史原因TRUNCATE TABLE吗？
你怎么称呼下面的表达？
(TableName == NULL) ? "0" : TableName
我知道它的作用，但想查找整个语法定义，但是由于表达式中没有真正的描述符，我似乎无法找出它的名称。
我最近遇到了很多数据库登录没有enforce_password_policy启用标志的环境。
即将进行的审核需要验证这些登录名的密码。
我使用以下查询来获取登录列表以及标志是打开还是关闭。
select
@@SERVERNAME as servername,
name,
IS_SRVROLEMEMBER('sysadmin', name) as SYSADMIN,
type_desc,
create_date,
is_policy_checked,
is_disabled,
password_hash,
PWDCOMPARE(name, password_hash) as UsernameAsPassword
FROM sys.sql_logins
但是，这并不能告诉我密码是否真的遵守密码策略，因为该标志仅在创建用户时才相关。
是否有已知的方法来测试现有用户的密码策略合规性？
我无法访问旧密码，我更喜欢不需要它们的方法。
我最近从 SQL Server 2005 升级到 2012。但是在验证过程中，发现了一个错误。
某个触发器的编码如下：
CREATE TRIGGER [dbo].[trigger] on [dbo].[foo]
FOR UPDATE, UPDATE
AS
UPDATE foobar
SET datetime = GetDate()
FROM bar
WHERE foobar.id = bar.id
GO
我可以在 SQL Server 2005 上安全地（奇怪地）执行此操作。
但是在 SQL Server 2012 上它抛出（我所期望的）语法错误。
语法错误：触发器声明中操作“UPDATE”的重复规范。
为什么这不会在 SQL Server 2005 上引发语法错误？我在这方面的 google-fu 让我失望了。
为什么这似乎适用于 SQL Server 2005？
我一直致力于提高大型报告数据库的性能。
该数据库的大小为 2TB，其中一个较大的表heap具有三个非聚集索引。
每个非聚集索引都处理 Case_ID 与相关数据的组合。
然而，案例 ID 根本不是唯一的，因为每个案例条目都与 Case_ID 存储在同一个堆中。
在业务方面的查询使我了解到 Case_ID、Line_Number 和 Document_ID 的组合是唯一的。
然而，几乎所有的查询都是由日期组成的（使用datetime名为 DATE 的列）。
通常由WHERE DATE = 'xxxx-xx-xx 00:00:00.000, 或WHERE DATE > 'xxxx-xx-xx 00:00:00.000'. 在大多数情况下，Line_Number 和 Document_ID 值甚至不包含在报告中。
因此，我在堆上（在 DEV 上）创建了一个聚簇索引，以列为键datetime。
报告的性能有了相当大的提高，我的大部分测试报告的查询时间从 5 分钟减少到 3 分钟，而且我还没有看到对未按日期声明的报告有任何负面影响。
然而，我担心我看得太远了，因为我知道非唯一聚集索引很少是解决方案。我正在做的是一种有效的方法吗？或者我应该简单地索引唯一的复合键，并在列上创建覆盖索引datetime？
我正在寻找更新READ_ONLY数据库上的几个用户。
由于数据库在全球范围内全天候 24/7 使用，并且维护窗口刚刚过去，我想在活动较少的时候执行此操作（以便能够遵守最后期限）。
我目前正在考虑使用：
USE MASTER
GO
ALTER DATABASE SQL SET READ_WRITE
GO
USE SQL
GO
EXEC sp_addrolemember N'db_datareader', N'USER'
GO
USE MASTER
GO
ALTER DATABASE SQL SET READ_ONLY
GO
但是我想：
由于我无法将这些命令放入事务中，并且我在 DEV 或 STG 环境中没有方便的应用程序服务器来预先测试更改，是否有任何关于更改read_only单个操作状态的文档？（我确实测试了 T-SQL 语句，它们有效）
此外，由于这需要对数据库进行独占锁定，我是否有可能通过我的声明？
我倾向于只是提出，这将不得不等到下一个维护窗口期。但我希望这里有人能证明我错了。
在专用于 Dynamics CRM 数据库的 sql 服务器上，我看到了一些奇怪的行为。
在使用以下查询作为基础监控增长时，我注意到 tempdb 在过去几个小时内增长非常频繁：
DECLARE @path NVARCHAR(1000)
SELECT @path = Substring(PATH, 1, Len(PATH) - Charindex('\', Reverse(PATH))) +
'\log.trc'
FROM sys.traces
WHERE id = 1
SELECT databasename,
e.name AS eventname,
cat.name AS [CategoryName],
starttime,
e.category_id,
loginname,
loginsid,
spid,
hostname,
applicationname,
servername,
textdata,
objectname,
eventclass,
eventsubclass
FROM ::fn_trace_gettable(@path, 0)
INNER JOIN sys.trace_events e
ON eventclass = trace_event_id
INNER JOIN sys.trace_categories AS cat
ON e.category_id = cat.category_id
WHERE e.name IN( 'Data File Auto Grow', 'Log File Auto Grow' )
ORDER BY starttime DESC
给出数据文件的几行增长：
tempdb Data File Auto Grow Database 2015-03-02 09:50:33.187 2
但是，当我查看 tempdb 占用的空间时，我没有看到空间紧缩的位置：
USE tempdb
GO
SELECT DB_NAME() AS DbName,
name AS FileName,
size/128.0 AS CurrentSizeMB,
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB
FROM sys.database_files;
给出以下输出：
DbName FileName CurrentSizeMB FreeSpaceMB
tempdb tempdev 7500.000000 7492.625000
tempdb templog 156.132812 93.820312
tempdb tempdev2 7250.000000 7245.625000
tempdb tempdev3 7250.000000 7245.312500
tempdb tempdev4 7366.500000 7360.875000
维护 CRM 的人要求我们缩小 tempdb。
我的同事过去曾有义务。但是我不愿意在没有解释的情况下这样做。尤其是考虑到收缩已经成为几乎每周都会发生的事情。
谁能告诉我为什么 tempdb 有这么多增长事件，以及如何正确处理？
我目前正在考虑要求更多存储空间，并将 tempdb 驱动器增加 50%。
然而，这感觉就像治疗症状，而不是原因。
我目前正在审查一个SSRS服务器频繁阻塞和死锁的案例。
这些报告不是关键业务，它们经常被杀死以缓解阻塞。
但是，同样的 SQL Server 上有一些关键数据库（它与大型共享点场共享一个 SQL 服务器），这些数据库的性能一直在下降。
我的前任的计划如下：
原因是我们将拥有更好的硬件 (B)，能够摆脱旧服务器 (A)，并从关键数据库服务器（现在是 B）中删除报告服务器（最终位于 C）。
但是，我并不完全相信这会对性能产生很大影响（除了较新的硬件）。
我在一周的大部分时间里一直在监视这些块，它始终是 WriteLockSession 阻塞 ReadChunkSegment。据我从文档（谷歌）中可以看出，这非常好。
我如何确定/如果一个阻塞的进程导致不同数据库的速度变慢？
如果我能证明性能问题与共享硬件无关（报告和其他数据库），我想设置共享数据集。由于大多数报告和所有长时间运行的报告都在查询相同的小数据子集。
我最近与一位同事讨论过，他正在推动从生产查询中删除 order by 子句，因为order by column 与 primary key 相同。
经过长时间的讨论，我试图解释他不能保证基于主键的排序，最后的结论是他不会推动改变 MSSQL 查询。
但他仍然打算更改 DB2 查询。
我无法立即找到一篇反驳 DB2 按主键排序查询的文章，目前我想知道它是否确实如此。
所以我的问题是，如果没有 order by 子句，DB2 如何对查询进行排序？它使用主键吗？
在并行系统中，如何保证数据在没有 order by 子句的情况下正确排序？
我正在寻找一个意见，我知道这通常是不受欢迎的，所以我提前道歉。
我目前处于每个实例都是 SQL Server 企业版的环境中。维护任务由自定义计划执行。默认情况下，此计划在夜间进行离线重建。
没有夜间维护窗口，并且由于环境是多国的，维护的“夜间”部分并不总是意味着最低活动点（但在 95% 的情况下确实如此）。由于积极的索引维护，目前有很多夜间作业运行缓慢。（一个报告查询在等待一个包含客户数据的 300GB 表的索引重建时卡住了，导致我走上了这条路线）
我可以假设以下内容将产生主要的积极影响：
我在这里主要要问的是，我是否正确假设当前的维护计划过于激进。并且上述 4 项变化将产生净积极影响。
我最担心的是每天晚上为所有事情重新组织一切......这似乎太过分了。
我正在查看第三方应用程序正在执行的查询。该应用程序被我们的一些最终用户标记为运行缓慢。
它似乎INSERT记录到一个 HEAP 中，然后在会话结束后再次记录它们（没有任何选择发生在它们上面？）但是在每个语句DELETE的末尾都有一个.INSERTSELECT 0
我是否从查询计划缓存中看到了某种工件？是否可能缺少某些参数？所有其他参数都清楚地标明，例如@P1。
每分钟有 350 个INSERT动作，DELETE每小时有一个表中的所有内容。使用 HEAP 似乎是一个好的情况，但是如果这个 SELECT 0 实际上是从这个堆中选择一些东西，我想知道我是否应该添加一个聚集索引。
更新：添加了一个屏幕截图来显示选择：
我最近遇到了一个数据库，它在大表上具有非常高的碎片。
页数 > 1'000'000，碎片为 99，...
我想知道这张表在没有重组/重建的情况下已经走了多长时间。这样我就可以查看在该日期所做的更改，以尝试找到原因。（在我的报告中看起来不错“这个数据库从那时起就没有得到适当的维护......）
由于我正在设置一项工作以快速重组受影响的表（可能是今晚），因此任何可以为我提供索引操作历史的解决方案将不胜感激。如果没有，只要知道我将来可以检查这些数据就会很有帮助。
我正在寻找一种方法来证明最近添加的一些索引正在对生产系统产生积极影响。
我收集了一些 dmv 统计数据以表明索引确实（经常）被使用，但需要一些方法来证明它们对选择查询有足够积极的影响，添加更新/删除时间的任何负面影响是输出。
我正在寻找有关如何证明这些指数具有积极影响的任何见解/建议。