我有一些使用 Entity Framework Code First 创建的数据库；应用程序正在运行，总的来说，我对 Code First 让我做的事情感到非常满意。我首先是一名程序员，其次是 DBA，这是必要的。我正在阅读 DataAttributes 以在 C# 中进一步描述我希望数据库执行的操作；我的问题是：将这些nvarchar(max)字符串放在我的桌子上会吃什么惩罚（见下面的例子）？
在这个特定的表中有几列；在 C# 中，它们是这样定义的：
[Key]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int ID { get; set; }
public string Name { get; set; }
public string Message { get; set; }
public string Source { get; set; }
public DateTime Generated { get; set; }
public DateTime Written { get; set; }
我希望根据名称、来源、生成和书面内容进行查询和/或排序。我希望 Name 和 Source 的长度为 0-50 个字符，有时可达 150 个。我希望这个表开始时很小（<100k 行），但随着时间的推移显着增长（>1m 行）。显然消息可以是小或大的，并且可能不会被查询。
我想知道的是，我的 Name 和 Source …
sql-server entity-framework sql-server-2008-r2 azure-sql-database
我将数据库的备份从 SQL Server 2008 R2 恢复到 SQL Server 2012。
当我尝试访问应用程序的特定页面时，出现此错误：
无法作为数据库主体执行，因为主体“dbo”不存在
它与我的 2008 R2 项目完美配合。我该如何解决这个问题？
通常我们每周的完整备份在大约 35 分钟内完成，每日差异备份在大约 5 分钟内完成。从星期二开始，每天的日常工作需要将近 4 个小时才能完成，远远超出了应有的要求。巧合的是，这在我们获得新的 SAN/磁盘配置后立即开始发生。
请注意，服务器正在生产中运行，我们没有整体问题，它运行平稳 - 除了主要表现在备份性能中的 IO 问题。
在备份期间查看 dm_exec_requests，备份一直在等待 ASYNC_IO_COMPLETION。啊哈，所以我们有磁盘争用！
但是，MDF（日志存储在本地磁盘上）和备份驱动器都没有任何活动（IOPS ~= 0 - 我们有足够的内存）。磁盘队列长度 ~= 0 也是如此。CPU 徘徊在 2-3% 左右，也没有问题。
SAN 是 Dell MD3220i，LUN 由 6x10k SAS 驱动器组成。服务器通过两条物理路径连接到 SAN，每条路径都通过一个单独的交换机与 SAN 的冗余连接 - 总共有四个路径，其中两个随时处于活动状态。我可以通过任务管理器验证两个连接是否都处于活动状态 - 完美均匀地分配负载。两个连接都运行 1G 全双工。
我们曾经使用巨型帧，但我已禁用它们以排除此处的任何问题 - 没有变化。我们有另一台服务器（相同的操作系统 + 配置，2008 R2）连接到其他 LUN，它没有显示任何问题。然而，它没有运行 SQL Server，而只是在它们之上共享 CIFS。但是，它的 LUN 首选路径之一与麻烦的 LUN 位于同一 SAN 控制器上 - 所以我也排除了这一点。
尽管存在以下问题，但运行几个 SQLIO 测试（10G 测试文件）似乎表明 IO 是不错的：
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20 …将列添加到 SQL Server 2008 R2 上的大型生产表的最佳方法是什么？根据微软的在线书籍：
ALTER TABLE 中指定的更改会立即实施。如果更改需要修改表中的行，则 ALTER TABLE 更新行。ALTER TABLE 获取表上的模式修改锁，以确保在更改期间没有其他连接引用甚至表的元数据，除了在最后需要非常短的 SCH-M 锁的在线索引操作。
(http://msdn.microsoft.com/en-us/library/ms190273.aspx)
在包含数百万行的大表上，这可能需要一段时间。停电是唯一的选择吗？处理这种情况的最佳方法是什么？
当前在 SQL Server 2008 R2 上运行
我正在尝试提高 UPDATE 语句的性能。我注意到弹出显示计划中的 Eager Spool 操作。我对假脱机操作的理解非常基本 - 它们在更新期间为表创建临时存储。
我也知道，虽然它们可以防止更糟糕的执行时间，但急切的假脱机通常表明表结构和/或查询语句存在潜在问题。
我的问题很简单：当您在查询计划中看到 Eager Spool 时，您首先要解决哪些问题？
我将分析我们系统的每个部分以提高性能 - 我只是在寻找关于我应该从哪里开始的指导。
我有一个 MS SQL Server 2008 R2 DB 服务器，目前正在与生产应用程序一起使用。
该应用程序的新增强功能现在需要varchar(100)增加表格中的列长度。
能否在不影响当前数据的情况下增加 prod DB 中此现有列的长度？
是否必须在非工作时间完成此更改以避免服务中断？
我知道在安装 SQL Server 时可以更改许多默认路径，通常在我进行安装时，我会将数据和日志文件夹更改为位于单独的驱动器（通常是 D 和 E）上，但是我最近得到了一个预安装的机器运行的实例名称不是默认的，并且他们已将实例根目录与 mdf 文件一起配置在 D 驱动器上。这意味着在通常只有文件夹和数据库文件的相对干净的驱动器上，我现在也完全安装了 SQL Server 二进制文件。
即我现在有以下内容：
C:\Program Files\Microsoft SQL Server\ --Base Install
D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries
D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files
E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files
通常我会用类似的东西运行：
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries
D:\MSSQL\DATA --Data Files
E:\MSSQL\LOGS --Log Files
我可以理解为什么需要一个单独的实例二进制文件夹，但我不明白为什么将所有这些二进制文件放在一个单独的驱动器上会有用。
谁能告诉我为什么这样做可能是合理的？或者也许它根本没有区别？对我来说，它似乎非常不整洁......
我已经四处搜索了，但没有找到这个问题的最终答案。
我需要一个可以为关联角色授予所有权限的脚本。
有什么想法，或者甚至可能吗？
这让我关闭 - 但我似乎无法翻转它并提供角色而不是用户的摘要。
WITH perms_cte as
(
select USER_NAME(p.grantee_principal_id) AS principal_name,
dp.principal_id,
dp.type_desc AS principal_type_desc,
p.class_desc,
OBJECT_NAME(p.major_id) AS object_name,
p.permission_name,
p.state_desc AS permission_state_desc
from sys.database_permissions p
inner JOIN sys.database_principals dp
on p.grantee_principal_id = dp.principal_id
)
--role members
SELECT rm.member_principal_name, rm.principal_type_desc, p.class_desc,
p.object_name, p.permission_name, p.permission_state_desc,rm.role_name
FROM perms_cte p
right outer JOIN (
select role_principal_id, dp.type_desc as principal_type_desc,
member_principal_id,user_name(member_principal_id) as member_principal_name,
user_name(role_principal_id) as role_name--,*
from sys.database_role_members rm
INNER JOIN sys.database_principals dp
ON rm.member_principal_id = dp.principal_id
) rm
ON …在立即标记为重复之前，我已阅读 Mike Walsh 的《为什么事务日志不断增长或空间不足？，但我认为它没有回答我的情况。我浏览了十几个类似的问题，但相关的问题大多只是说“重复”并指向迈克的问题。
详细信息：我在 SQL Server 2008 R2 上有一堆约 500MB 的数据库，都处于简单恢复模式（不是我的选择），每晚完整备份，包含约 200MB 的数据文件和约 300MB 的日志文件。日志不会立即增长到 300MB，而是在几个月的过程中缓慢增长。至少根据 sp_who2 和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它会告诉我有大约 50MB 可用空间。特别是在备份之后，整个日志不应该是免费的吗？在 SIMPLE 模式下，只要没有打开的事务，日志就不应该是免费的吗？
log_reuse_wait_descfromsys.databases说“NOTHING”，根据上面引用的问题和答案说它不应该等待任何东西来重用空间。
如果我做'DBCC SHRINKFILE'，日志文件缩小到1MB，所以它愿意回收空间。我可以设置一些每周缩小日志并防止事情失控的东西，但我很困惑为什么 SQL Server 会让我这样做。
我可以理解是否有一些疯狂的事务需要 300MB 来记录它，但我们没有做任何极端的事情，只是基本的 OLTP。来自迈克的问题/答案：
简单恢复模型 - 有了上面的介绍，最容易先讨论简单恢复模型。在此模型中，您是在告诉 SQL Server - 我对您使用您的事务日志文件进行崩溃和重新启动恢复感到满意（您在那里确实别无选择。查找 ACID 属性，这应该很快就有意义），但是一旦您没有不再需要它用于崩溃/重启恢复目的，继续并重用日志文件。
SQL Server 在 Simple Recovery 中侦听此请求，并且仅保留执行崩溃/重新启动恢复所需的信息。一旦 SQL Server 确定它可以恢复，因为数据已加固到数据文件（或多或少），已加固的数据在日志中不再需要并被标记为截断 - 这意味着它会被重新使用。
它一直说日志空间应该被重用，但是随着几个月的缓慢增长，它似乎不是。
我错过了什么？是否有什么原因使 SQL Server 无法将数据识别为“硬化”并释放日志？
(编辑) 行动后报告 - AKA 一点点知识是危险的
在发现这是一个“热门问题”后，我觉得我欠了一个解释 7 个月前发生的事情以及我学到的东西，希望能挽救一些其他人的悲伤。
首先，当您查看数据库的属性时，您在 SSMS 中看到的可用空间是数据文件中的可用空间。您可以通过在数据库上运行以下命令来查看这一点，您会发现 SSMS 报告的可用空间是 FileSizeMB 和 UsedSpaceMB …
我试图想出一种理智的方法来了解max server memory (mb)设置是否合适（应该更低，或更高，或保持原状）。我知道max server memory (mb)应该总是足够低，以便为操作系统本身等留出空间。
我正在查看的环境有数百台服务器；我需要一个可靠的公式来确定缓冲池的当前大小是否合适，因为 RAM 是按分配给每个服务器的 GB 计算的。整个环境都是虚拟化的，分配给 VM 的“物理”RAM 可以轻松地向上或向下更改。
我有一个特定的 SQL Server 实例，我现在查看的 PLE 为 1,100,052 秒，相当于 12.7 天（服务器启动的时间）。服务器的最大服务器内存设置为 2560MB (2.5GB)，其中实际仅提交 1380MB (1.3GB)。
我已经阅读了几篇文章，包括 Jonathan Keheyias（帖子）和 Paul Randal（帖子）的另一篇文章，以及其他几篇文章。Jonathan 主张监控每 4GB缓冲池低于 300 的 PLE太低了。对于上面的 SQL Server 实例，300 * (2.5 / 4) = 187导致目标 PLE 非常低，低于 300。此实例具有 290GB 的 SQL Server 数据（不包括日志文件），仅用于集成测试。假设在过去的12天代表该服务器的典型用法的，我想说的max server memory (mb)设置可能会降低。
在规模的另一端，我有另一个 PLE 为 …