Questions tagged «sql-server-2008-r2»

SQL Server 2008 R2（主要版本10.50.xxxx）。请同时用sql-server标记。

3
在Microsoft SQL Server 2008中，语法生成错误“未启用并行数据仓库（PDW）功能”。
我有以下虚拟列是通过排序分区上的聚合生成的， MIN(picture_id) OVER ( PARTITION BY [360_set] ORDER BY picture_id ASC ) 但是，当我执行该操作时，会得到以下结果。 Msg 11305, Level 15, State 10, Line 12 The Parallel Data Warehouse (PDW) features are not enabled. 尽管这是有趣的地方，但在分区上没有排序顺序，但它的工作原理是： MIN(picture_id) OVER ( PARTITION BY [360_set] ) 而且，ROW_NUMBER()窗口函数（不是聚合函数）在分区上以显式顺序工作。 ROW_NUMBER() OVER ( PARTITION BY [360_set] ORDER BY picture_id ASC ) …
1
XML列的IN和NOT IN
我有一个带有xml列的表。Xml类似于 <Root> <Row> <user>abc</user> <Rowid>1</Rowid> </Row> <Row> <user>vf</user> <Rowid>2</Rowid> </Row> <Row> <user>ert</user> <Rowid>3</Rowid> </Row> <Maxrowid>3</Maxrowid> </Root> 现在下面的查询返回sl_no列和myxmlcolumn行包含节点``user''（）中具有值``abc''或``xyz''的xml列。查询以下我正在使用类似于sql的IN选项。 SELECT [mytable].[Sl_no], [mytable].[myxmlcolumn] FROM [mydb].dbo.[mytable] WHERE [myxmlcolumn].exist('for $x in /Root/Row where (($x/user[fn:upper-case(.)=(''ABC'',''XYZ'')])) return $x') > 0 我想要类似的查询，其功能与sql'NOT IN'相同。在我的情况下，我希望在xml列的节点“ user”（）中不具有值“ abc”或“ xyz”的行。所以请帮我。
1
SQL Server不使用可用内存
Windows 2008R2 Enterprise上的SQL Server 2008 R2标准版（64位） 服务器具有超过300 GB的内存，但控制面板中的总内存使用量永远不会超过86 GB 将SQL配置为使用最大内存量 即使在大量使用的情况下-超过80％的CPU持续数分钟 专用SQL Server 几个大型数据库 一个频繁使用的表的索引大小仅超过10 GB 设置服务帐户以保留内存中的锁 那正常吗？ 我可以测试什么？ 我可以让SQL Server使用更多的内存吗？
2
寻求谓词不使用所有可用列
我有一个奇怪的查询编译问题，很难重现。它仅在高负载下发生，不能轻易重复。 有一个带有列A，B，C，D的表T。 T（A，B，C，D）上存在一个非唯一的聚集索引。 有一个查询SELECT * FROM T WHERE A = @ P1 AND B = @ P2 AND（C = @ P3或C = @ P4）AND D = @ P5。查找条件位于聚集索引的所有列上，第3列具有OR。 问题在于此查询的查询计划仅在A和B上具有Seek谓词！C和D上的谓词是普通谓词，因此这意味着不使用C和D列上的搜索树。 所有参数的数据类型都与列数据类型匹配。 谁能提供暗示为什么会发生这种情况？SQL版本是2008 R2（SP1）-10.50.2789.0（X64）
1
分离/附加或脱机/在线是否清除特定数据库的缓冲区高速缓存？
今天，我的一个伙伴告诉我，除了启动SQL Server之外，我还可以简单地分离并重新附加数据库，此操作将从缓存中清除给定数据库的页面和计划。我不同意并在下面提供证据。如果您不同意我的意见或有更好的反驳，则绝对不要提供。 我在此版本的SQL Server上使用AdventureWorks2012： 选择@@ VERSION; Microsoft SQL Server 2012-11.0.2100.60（X64） Windows NT 6.1（内部版本7601：Service Pack 1）上的Developer Edition（64位） 加载数据库后，我运行以下查询： 首先，运行在此处找到的乔纳森·K的AW育肥脚本： AW发胖 --------------------------- -步骤1：Bpool Stuff？ --------------------------- USE [AdventureWorks2012]； 走 选择 OBJECT_NAME（p.object_id）AS [ObjectName] ，p.object_id ，p.index_id ，COUNT（*）/ 128 AS [缓冲区大小（MB）] ，COUNT（*）AS [buffer_count] 从 sys.allocation_units AS a 内联接sys.dm_os_buffer_descriptors AS b 开启a.allocation_unit_id = b.allocation_unit_id 内部联接系统分区AS p 开启a.container_id …
1
-E启动选项和SSD
有没有人看到-E使用SSD时会产生影响的证据？ 对于“旋转生锈”驱动器的影响毋庸置疑-但是SSD并没有真正受到随机I / O的困扰。我不知道该-E选项是否可能会损害性能。 在具有混合驱动器（SSD SAN，PCI SSD和传统SAN）的服务器上，SQL Server必须决定是否使用启动-E。我有一些经验证据表明该选项可能会损害性能，但是在考虑将其取消之前，我希望获得其他人的反馈。 我的设置使用标准的64K RAID条带，并且NTFS群集大小也为64K。
1
多次创建和删除#SomeTable是“合法的”吗？
我已经将代码分类为“连贯的块”，可以一遍又一遍地插入较长的“配置脚本”中，而我使用的模式之一是： CREATE TABLE #WidgetSetting ( WidgetID bigint not null, Name nvarchar(100) not null, Value nvarchar(max) not null, CreateDate datetime not null ) INSERT VALUES MERGE TABLES DROP TABLE #WidgetSetting 但是现在SSMS抱怨到下次CREATE TABLE火灾时该对象已经存在。是什么赋予了？ 我认为很明显，我将不得不在脚本开始时声明一次表，然后截断而不是删除，但是自然地，令人沮丧的是，无法仅删除表并再次使用相同的名称。
2
生成脚本以自动重命名默认约束
背景：某些默认的列约束是在没有显式名称的情况下生成的，因此我们得到的有趣的名称因服务器而异，例如： DF__User__TimeZoneIn__5C4D869D 我希望使用一致的命名方式来管理它们，DF_Users_TimeZoneInfo以便我们可以确保将来的目标表上存在适当的约束（例如在RedGate比较中，甚至只是在视觉上） 我有一个脚本，该脚本通常可以满足我的需求： select 'sp_rename N''[' + s.name + '].[' + d.name + ']'', N''[DF_' + t.name + '_' + c.name + ']'', ''OBJECT'';' from sys.tables t join sys.default_constraints d on d.parent_object_id = t.object_id join sys.columns c on c.object_id = t.object_id and c.column_id = d.parent_column_id join sys.schemas s on …
2
将TempDB拆分为多个文件，这些文件等于CPU的数量
《SQL Server tempdb最佳实践提高性能》一文建议，我应该将tempdb文件分割成与内核数相等的数量。因此，对于4个内核，您将获得4个文件。 通过拥有更多的文件，可以增加SQL Server一次可以推送到磁盘的物理I / O操作的数量。SQL Server可以将其下推到磁盘级别的I / O越多，数据库将运行得越快。使用标准数据库，SQL Server可以将所需的大量数据缓存到内存中。由于tempdb具有高写入特性，因此需要先将数据写入磁盘，然后才能将其缓存回内存。 尽管从理论上讲听起来不错，但总体上来说它真的那么好吗？它仅适用于IO非常高的特定系统吗？
2
如何为BI配置在SQL Server上配置这些磁盘？
假设恒定内存（32gb）和CPU（4），2个磁盘阵列，我有以下磁盘 2 x 150（10k） 6 x 150（15k） 它们都是本地磁盘。 我的要求 我的数据库是350gb，并设置为默认10％增长 我的OS和SQL Server是Server 2k8R2（C：驱动器OS +页面+应用程序= 55Gb） 日志要求约为70gb，默认设置为10％的增长，并且通常会被截断 我的TempDb当前约为12gb，默认设置为10％的增长 我的问题是我试图了解将TempDB和OS以及Log放在哪里的最佳方式。我的经验仅限于这两个的最佳配置 这不是一个在线交易系统。它具有大量的数据写入（新数据+索引重建/重组），然后具有大量的数据读取（我估计约为50/50），处理大约13个小时，然后安静下来。 我的理解是，与日志相比，TEMPDB在正常处理期间被大量使用。 我的想法是以下 适用于OS + TempDB的2 x 150g（15k）突袭1 = 150g 2 x 150g（10k）RAID 1 = 150g for LOG（请注意此处的磁盘较慢） 4 x 150g（15k）突袭5 = 150g用于数据 听起来像个好主意吗？然后，如果需要，我可以交换Log + TempDB。 我是否违反基本原则，例如由于分页问题而从不将TempDB放在OS磁盘上，或者也许从不将日志放在比数据慢的磁盘上？ 编辑： 我们的系统上也有一个SSAS，最终用户只能访问多维数据集。上面的50％是根据处理SSAS数据库所需的时间得出的。
3
SQL更新状态需要很长时间/大量磁盘使用
是的，这听起来像是一个非常笼统的问题，但是我还不能将其范围缩小很多。 所以我在sql批处理文件中有一个UPDATE语句： UPDATE A SET A.X = B.X FROM A JOIN B ON A.B_ID = B.ID B有40k条记录，A有4M条记录，它们通过A.B_ID一对一相关，尽管两者之间没有FK。 因此，基本上，我正在为数据挖掘目的预先计算一个字段。尽管我为这个问题更改了表的名称，但是我没有更改该语句，实际上就这么简单。 这需要几个小时才能运行，因此我决定取消所有操作。数据库已损坏，因此我删除了它，恢复了我在运行该语句之前所做的备份，并决定使用游标进一步介绍细节： DECLARE CursorB CURSOR FOR SELECT ID FROM B ORDER BY ID DESC -- Descending order OPEN CursorB DECLARE @Id INT FETCH NEXT FROM CursorB INTO @Id WHILE @@FETCH_STATUS = 0 BEGIN …
2
随着时间的流逝，SQL Server变得越来越慢，直到我们不得不重新启动它为止
我们有一个混合OLAP / OLTP工作负载的数据库。这些查询是非常特殊的，并且是在中间层应用程序服务器中动态创建的。当我们启动服务器时，性能是可以接受的，但是在所有可用内存（30GB）用完之前，内存消耗越来越多。在那之后，系统变得越来越慢。 像这样的命令Dbcc freeproccache无效。 交易select * from sys.dm_tran_session_transactions不多（不超过系统正常时），有时此列表为空。 的第一个结果dbcc memorystatus是 VM Reserved 42136628 VM Committed 1487176 Locked Pages Allocated 24994048 Reserved Memory 1024 Reserved Memory In Use 0 重新启动SQL Server可以解决该问题一段时间。 是什么原因导致这种现象？如何避免呢？ 如果真正的解决方法太困难了，是否有一条命令可以强制SQL Server在不重新启动DBMS的情况下实际释放所有内存？ 服务器在专用硬件（不是VM）上运行。我们有一些预定的工作，但是暂时禁用了它们，没有任何变化。同一台服务器上还运行着其他中层应用程序，但是它们使用的内存不超过2GB，CPU可以忽略不计，几乎没有I / O。我们没有更改就重新启动了所有此类应用程序。
1
保存视图时，如何防止SSMS重写代码？
我正在创建一个视图，该视图使用带有与WHERE此类似的子句的语句： WHERE ( col1 IS NOT NULL OR col2 IS NOT NULL ) AND NOT EXISTS (SELECT ...) 平均需要10秒钟才能运行。但是，当我尝试将此查询另存为View时，SQL Server（或MS SQL Server Management Studio客户端）“优化”查询以使用此结构，而是： WHERE (col1 IS NOT NULL AND NOT EXISTS (SELECT ...)) OR (col2 IS NOT NULL AND NOT EXISTS (SELECT ...)) 将查询速度减慢到6分钟以上。有什么方法可以禁用此行为，以便视图完全使用我提供的SQL查询吗？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.