⑴ 建议不要将sql安装在域控制器上是怎么会事
因为SQL工作室要消耗大量CPU资源，而域控制器主要也是消耗CPU资源，在一起的话容易导致服务器卡住的！
⑵ sql server 2012 资源调控器 启用和禁用的区别
if (con.State!=ConnectionState.Closed)
{
con.Close();
}
//释放数据库资源
con.Dispose();
}
if (dt.Rows.Count>0)
{
⑶ sql server 2016 rco是什么版本
SQL Server有很多配置选项只能在SQL Server实例级别进行全局配置。例如MAXDOP选项（当你不使用资源调控器时）。
另外微软提供我们大量不同的跟踪标记（Trace Flags）可以修改SQL Server的内部行为。微软现在最终宣布这些领域，SQL Server 2016会为我们提供现存的配置选项，在数据库级别就可以配置，而不使用特定的跟踪标记（Trace Flags）。
⑷ sql 对象资源管理器
sql2000 用企业管理器。
右击“LOCAL(Windows NT)”--------〉“新建sql server注册”---------〉进入“注册SQL Server向导”-----〉点击“下一步”--------〉在“可用的服务器（本机就是local）”列表中选择一个需要注册的服务器，点击右侧的“添加”按钮，就会出现在“添加的服务器”列表中----〉点击“下一步”---〉点击“完成”。
然后选中数据库，右键-》所有任务-》备份、还原
⑸ 揭秘SQL Server 2014有哪些新特性
有以下新特性：
数据库引擎功能增强
内存优化表
Windows Azure 中的 SQL Server 数据文件
将 SQL Server 数据库托管在 Windows Azure 虚拟机中
备份和还原增强功能
针对基数估计的新设计
延迟持续性
AlwaysOn 增强功能
分区切换和索引生成
管理联机操作的锁优先级
列存储索引
缓冲池扩展
增量统计信息
物理 IO 控制的资源调控器增强功能
Online Index Operation 事件类
数据库兼容性级别
Transact-SQL 增强功能
系统视图增强功能
⑹ 如何在SQL资源管理器中添加约束表达式
1、首先我们打开电脑里的SQL资源管理器，如图是一个Student表其中我们主要针对于这个表中的Phone这一列来进行演示。
⑺ sql2008 资源调控器一般设多少
在今天的文章里，我想谈下SQL Server 2014里非常酷的提升：现在你终于可以根据需要的IOPS来压制查询！资源调控器（Resource Governor）自SQL Server 2008起引入，但提供的功能还是有所限制：你只能限制CPU时间（这个已经很棒了），还有你能限制查询（从每个独立的查询）内存量。 但作为DBA的你，你经常会进行一些数据库维护操作，例如索引重建，DBCC CHECKDB操作等。我们都知道，这些操作会在你的存储里带来大量的IOPS直至峰值。如果在7 * 24在线的数据库来说，这个会影响你的生产力，给业务和销售额带来很大影响。 自SQL Server 2014开始，这个情况就变了，因为你可以通过资源调控器来部署指定的资源池来限制IOPS使用率。当你隔离你的DBA操作到指定的资源池时，你能指定资源池可以使用的最大IOPS（包括最小IOPS）。因此你可以压制下DBA操作需要的IOPS。你的生产工作量就可以更好的使用你的存储。更多信息可以查看微软在线帮助。 我想用一个非常简单的例子来展示下这个行为。假设你是DBA，正要进行常规索引重建操作，这个需要通过资源调控器对它们的最大IOPS使用率进行控制。第1步我们为DBA操作创建专用的资源池和工作负荷组。 -- Create a new Resource Pool for the DBAs. -- We use a very high value for MAX_IOPS_PER_VOLUME so that we are -- currently running unlimited. CREATE RESOURCE POOL DbaPool WITH ( MAX_IOPS_PER_VOLUME = 100000 ) GO -- Create a new Workload Group for the DBAs CREATE WORKLOAD GROUP DbaGroup USING DbaPool GO 从刚才的代码可以看到，CREATE RESOURCE POOL语句现在为你提供MAX_IOPS_PER_VOLUME属性（包括MIN_IOPS_PER_VOLUME）。这里我设置了一个很高的值，因此在第一次执行时IOPS不会受限，这里我们根据需要的IOPS建立了初始基线。下一步我会创建资源调控器需要的分类函数。 -- Create a new Classifier Function for Resource Governor CREATE FUNCTION dbo.MyClassifierFunction() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE @GroupName SYSNAME IF SUSER_NAME() = 'DbaUser' BEGIN SET @GroupName = 'DbaGroup' END ELSE BEGIN SET @GroupName = 'Default' END RETURN @GroupName; END GO 在分类函数里我们根据登录进行评估。如果登录是DbaUser，进入的会话会在DbaGroup工作负荷组里。否则就进入默认的工作负荷组。最后我们在资源调控器注册并配置它，这样我们的设置就生效了。 -- Register the Classifier Function within Resource Governor ALTER RESOURCE GOVERNOR WITH ( CLASSIFIER_FUNCTION = dbo.MyClassifierFunction ) GO -- Reconfigure Resource Governor ALTER RESOURCE GOVERNOR RECONFIGURE GO 现在当你创建名为DbaUser的登录时，你可以用它连接到你的SQL Server。你可以在DMV sys.dm_exec_sessions 看下 group_id列验证下到来的会话是否在正确的工作负荷组里。下一步我在ContoRetailDW数据库的FactOnlineSales表里的DataKey里创建一个非聚集索引。 -- Create a simple Non-Clustered Index CREATE NONCLUSTERED INDEX idx_DateKey ON FactOnlineSales(DateKey) GO 我们从开始就创建了资源池，现在在我们在我们的资源池里并没有限制。因此当我们现在进行刚才创建的非聚集索引的索引重建时，SQL Server会占用大量的IOPS。我们可以通过性能监控里的“SQL Server:Resource Pool Stats:Disk Write IO/Sec”性能计数器来验证刚才创建的资源池。 ALTER INDEX idx_DateKey ON FactOnlineSales REBUILD GO 可以看到索引重建花费近100的IOPS。接下来我要做的是限制DbaPool资源池为仅50的IOPS： -- Let's change the Resource Pool by lowering the maximum IOPS. ALTER RESOURCE POOL DbaPool WITH ( MAX_IOPS_PER_VOLUME = 50 ) GO 现在当你执行索引重建时，在性能监视器里可以清楚看到，在特定的资源池里只有平均50 IOPS。 另外Disk Write IO Throttled/sec性能计数器也会告诉为你资源调控器的IOPS的限制数。 使用以前的资源调控器，查询本身毫无办法，它是否被压制了。这对性能调优也是个非常重要的因素。当启用资源调控器时，没有特定的等待类型出现在SQL Server里。我的测试显示一旦资源调控器启用时，有更多的PAGEIOLATCH_SH/PAGEIOLATCH_EX等待类型，这就对了。下面2个图片显示了对于发生索引重建的会话里具体的等待类型信息——第1个没有资源调控器，第2个有资源调控器压制了IOPS。 从2个图中可以看到，2个运行的测试有巨大的区别，尤其是在PAGEIOLATCH_EX 和 SOS_SCHEDULER_YIELD等待类型。 从我站在IOPS压制来看，对于已有的功能来说，资源调控器是个很好的附加，这让资源调控器更加成熟。 大家可以尝试用这个新功能解决IOPS方面的问题。 以上所述就是本文的全部内容，希望对大家的学习有所帮助。
⑻ 数据库中用sql资源管理器修改列宽
“sql
server
对象资源管理器”或从“服务器资源管理器”中的“数据连接”
节点连接到
sql
server
数据库。
“sql
server
对象资源管理器”
提供了类似于
sql
server
management
studio
的视图。若要从菜单栏打开该资源管理器，请依次选择“视图”、“sql
server
对象资源管理器”
。有关更多信息，请参见
连接的数据库开发。
⑼ 做开发的朋友们，SqlServer大家都用什么版本
各版本功能对比
从我最开始接触的SQL SERVER 2000 开始，已经经历了如此多的版本。下面简单阐述下各个版本新增的功能：
SQL SERVER 2000
日志传送
索引视图
SQL SERVER 2005
分区
数据库镜像
（只有 SQL Server 2005 Enterprise Edition SP1 和更高版本支持异步数据库镜像。）
联机索引
数据库快照
复制
故障转移群集
SQL SERVER 2008
数据压缩
资源调控器
备份压缩
SQL SERVER 2008 R2
R2标志表示这是SQL Server的一个中间版本，而不是一个主版本 .此版本目前我的客户中，使用还是非常多，性能稳定，虽然新增功能比较少：
新增数据中心版，最大支持256核.
Unicode压缩
(为Unicode存储提供一个简单的压缩方案，通过Unicode压缩，可以减少Unicode字符对空间的占用)
SQL SERVER 2012
AlwaysOn
Columnstore 索引
增强的审计功能
大数据支持
SQL SERVER 2014
这个版本的新特效特别多，和非常有用，可以多了解下.
内存优化表
备份加密
针对基数估计的新设计
AlwaysOn 增强功能
延迟持续性 （将部分或所有事务指定为延迟持久事务，从而能够缩短延迟）
分区切换和索引生成
(官网写得Partition Switching and Indexing，感觉是有问题的，其实就是分区表的单个分区可以重建)
列存储索引
缓冲池扩展 就是使用SSD 扩展缓冲池
增量统计信息
资源调控器增强功能
（--之前只能控制CPU和内存，2014 开始可以控制IO）
DBCC CHECK 支持maxdop 提示
SQL SERVER 2016
全程加密技术(Always Encrypted)
JSON支持
多TempDB数据库文件
（以前也是支持的，在2014 开始就在error log提示,2016中，在安装时就可以设置。）
Query Store
（前几天去参加微软的培训还讲到的，挺不错的功能。可以帮助解决参数嗅探的问题，数据库升级的时候也可以用到它）
支持R语言
Live Quer y St at ist ics
（可以更清晰的看到执行计划的开销（水流式））
SQL SERVER 2017
可恢复的在线索引重建
允许您在发生故障（例如故障切换到副本或磁盘空间不足）之后恢复在线索引重建操作。
IDENTITY_CACHE option
当此选项设置为OFF时，它可以避免在服务器意外重新启动或故障切换到辅助服务器的情况下，标识列值的间隙
CLR在.NET Framework中使用代码访问安全性（CAS），该框架不再支持安全边界。
使用PERMISSION_SET = SAFE创建的CLR程序集可能能够访问外部系统资源，调用非托管代码并获取sysadmin权限
图表数据库功能
用于多对多关系建模
Read-scale availability groups without cluster
可以在不依赖集群的情况下，搭建读的可用性组，分担读压力。不过此时不能实现高可用。
R/PYTHON 机器学习方面的功能
总结
总的来说,SQL SERVER 正在变得越来越好，希望越来越多的人更多的了解他.如果有什么其他疑问欢迎讨论。