Questions tagged «sql-server-2008-r2»

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


2
查询性能调优
寻求帮助来改善此查询性能。 SQL Server 2008 R2 Enterprise,最大RAM 16 GB,CPU 40,最大并行度4。 SELECT DsJobStat.JobName AS JobName , AJF.ApplGroup AS GroupName , DsJobStat.JobStatus AS JobStatus , AVG(CAST(DsJobStat.ElapsedSec AS FLOAT)) AS ElapsedSecAVG , AVG(CAST(DsJobStat.CpuMSec AS FLOAT)) AS CpuMSecAVG FROM DsJobStat, AJF WHERE DsJobStat.NumericOrderNo=AJF.OrderNo AND DsJobStat.Odate=AJF.Odate AND DsJobStat.JobName NOT IN( SELECT [DsAvg].JobName FROM [DsAvg] ) GROUP …

4
有什么原因停止SQL Server?
我所读到的只是停止SQL Server可能造成的破坏,因为它会创建一个冷缓存并占用内存。那么为什么有人要停止SQL Server?如果您可以提供文章的任何链接,以便我可以阅读更多文章,我将不胜感激! 这个问题是我老师提出的。除非是一个棘手的问题,否则我绝对会感到困惑。他的确切问题是: 使用Internet进行研究,并了解为什么有人想要停止SQL Server。解释你的答案。 这是在我们探索如何使用SQL Server 2008 R2的上下文中。我不确定他是否在寻求明显的答案,或者我缺少什么。

1
为什么MSDB数据库值得信赖?
TRUSTWORTHY如果您不小心,该设置可能会非常危险,除特殊情况外,建议保持关闭状态。但是默认情况下,MSDB数据库TRUSTWORHTY设置ON默认。我很好奇为什么? 我已经在BOL中阅读了此条目 注意默认情况下,MSDB数据库的TRUSTWORTHY设置设置为ON。使用默认值更改此设置可能会导致使用MSDB数据库的SQL Server组件出现意外行为。 但是我对细节感到好奇。为什么MSDB需要专门TRUSTWORTHY打开电源?它使用什么功能?

4
SQL备份与IT常规夜间服务器备份有何不同?
我们的IT部门每晚都会备份整个服务器(此服务器上安装了一个SQL Server实例),如果出现问题,该服务器应该备份该服务器以及整个网络。 因此,经理问我的完整,差异和日志SQL备份与IT部门备份的备份相比有什么重要意义?为了节省我们服务器上的更多空间,而不是将这些文件保留几个星期并删除它们,她认为IT会提供它们! 我知道这是不对的,因为我可以使用日志备份恢复到最近30分钟,IT会在第二天恢复它,但这是唯一的区别吗? 由于我将数据库备份文件保存/发送到同一服务器上,因此IT部门将还原它们,但是如果我的维护计划中没有这些备份作业,则IT部门可以还原SQL实例而无需任何表,事务...等。我说对了吗? 任何建议将不胜感激。

3
零或一到零或一
如何以最自然的方式在Sql Server中对零或一到零或一的关系建模? 有一个“危险”表,列出了站点上的危险。有一个“任务”表,用于需要在站点上完成的工作。有些任务是修复危险,没有任务可以应对多种危险。有些危害有修复它们的任务。没有任何危险可以使两个任务相关联。 以下是我能想到的最好的方法: CREATE TABLE [dbo].[Hazard]( [HazardId] [int] IDENTITY(1,1) NOT NULL, [TaskId] [int] NULL, [Details] [varchar](max) NULL, CONSTRAINT [PK_Hazard] PRIMARY KEY CLUSTERED ( [HazardId] ASC )) GO ALTER TABLE [dbo].[Hazard] WITH CHECK ADD CONSTRAINT [FK_Hazard_Task] FOREIGN KEY([TaskId]) REFERENCES [dbo].[Task] ([TaskId]) GO CREATE TABLE [dbo].[Task]( [TaskId] [int] IDENTITY(1,1) NOT NULL, …

2
SQL Server DB在一夜之间变得无法使用
昨天,我的SQL Server数据库很好。如今,它几乎无法使用-减慢了5到20倍,具体取决于我何时按下它。 在通宵的加载过程中,一些数据已添加到服务器,但没有什么比对数据库有很大影响的卷更是如此。大约50,000条纯文本记录(没有XML或其他轻率的记录)。 该服务器已在今天早晨修补后重新启动。但是,我们所有其他也已打补丁的数据库服务器的行为都不相同。 资源监视器似乎暗示其磁盘IO有故障。即使在数据库中没有实际发生任何事情时,它始终在.mdf文件上以接近100%的容量运行。对Templog.ldf的访问也非常高。 这里没有人是专家DBA(我们都是拥有不同SQL技能的开发人员),我们都对发生的事情感到困惑。我们尝试运行sp_updatestats并将一些大索引移到不同的光盘上,但无济于事。 我认为这一定与补丁有关-似乎太多的巧合。一位同事确信,由于数据负载导致mdf的大小增加到导致执行计划变得效率低下的程度。 到底是什么原因造成的?我们如何找出答案,我们该如何解决? 编辑: 使用sp_WhoIsActive不会显示任何异常。它记录了我自己对sproc的使用以及来自当前正在尝试移动另一个索引的同事的一些命令。那可能现在正在支撑数据库,但是它之前运行得很差。 它是SQL Server 2008 R2的标准版本。SELECT @@VERSION给出: Microsoft SQL Server 2008 R2(SP2)-10.50.4033.0(X64) 2014年7月9日 版权所有(c)Windows NT 6.1(Build 7601:Service Pack 1)上的Microsoft Corporation标准版(64位)(Hypervisor ) 该服务器具有72GB的RAM和三个四核2GHz处理器。 该修补程序仅适用于Windows。除补丁外,没有其他更改。 所选设置: _id name value minimum maximum value_in_use description is_dynamic is_advanced 1540 min memory per query (KB) 1024 512 2147483647 …

1
无法还原(错误3456)
我的情况不容易弄清楚,以为我会在这个论坛上问其他人是否有建议。 我正在Windows Server 2008R2 Enterprise上运行SQL Server 2008 R2 Standard SP3。 数据库需要一些维护,事实上,我需要在另一台服务器上进行还原。我使用COPY_ONLY进行了完整的数据库备份,再加上一组4个日志备份。 在开始之前,创建tlogbackup1 从转换FULL为BULK_LOGGED恢复模式 添加新文件组 将文件添加到newfilegroup 将newfilegroup设置为默认 选择进入表(在newfilegroup上) 放下原始表 删除原始文件 删除原始文件组 更改新表的名称以匹配原始表 更改newfilegroup的文件名以匹配原始文件组 更改目录中的文件名以匹配原始文件名 在操作系统级别更改文件名以匹配原始文件名 将默认文件组设置为原始文件组 使数据库联机 从转换BULK_LOGGED为FULL恢复模式 完成所有步骤后,创建tlogbackup2 由于还原服务器上驱动器号的更改,所有备份的还原必须使用WITH MOVE。 恢复步骤: RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak' WITH MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf' ,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf' ,MOVE 'SystemData_log' TO …

2
Page Life Expectancy对实例有何看法?
我已经在环境中的一些SQL Server实例上安装了监视软件。我正在尝试查找瓶颈并解决一些性能问题。我想找出某些服务器是否需要更多内存。 我对一个计数器感兴趣:页面预期寿命。在每台机器上看起来都不同。为什么在某些情况下经常更改,这意味着什么? 请查看上周在不同计算机上收集的数据。您能对每个实例说些什么? 大量使用的生产实例(1): 适度使用的生产方式(2) 很少使用的测试实例(3) 大量使用的生产实例(4) 中度使用的测试实例(5) 大量使用的数据仓库(6) 编辑:我为所有这些服务器添加SELECT @@ VERSION的输出: Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 2: Microsoft SQL …

1
基于客户端TCP端口的SQL Server跟踪
我有一个Windows终端服务器,其中许多用户通过RDP登录以运行应用程序。该应用程序为每个用户与SQL Server 2008 R2实例建立一个或多个连接。所有用户都使用相同的SQL登录名访问相同的数据库。我希望能够跟踪特定用户的SQL会话,但是我还没有找到一种方法来确定哪个SQL会话属于哪个用户。但是,我能够确定应用程序的每个实例使用的源TCP端口。 有没有一种方法可以基于客户端的TCP端口来跟踪SQL会话?

1
mdf和ldf的可用空间与数据库的可用空间不匹配
在SSMS中,我看到了文件大小相关的属性,并在下面找到了一个数据库的详细信息。此处的值与其他属性不匹配。此处mdf,ldf的大小和总大小与每个窗口下的其他值匹配。但是,如果添加了mdf和ldf的可用空间,则它不等于收缩数据库窗口中显示的可用空间和数据库属性中显示的可用空间。对于任何数据库都是如此。为什么会这样呢?请任何人解释这背后的逻辑? 在数据库属性下: 大小:91.31 MB 可用空间:13.40 MB 在数据库文件属性下: mdf大小:17 MB ldf大小:75 MB 在收缩数据库下: 当前分配的大小:91.31 MB 可用空间:13.40 MB 在收缩文件下,用于数据文件: 当前分配的大小:16.38 MB 可用空间:12.63 MB 在收缩文件下-用于日志文件: 当前分配的大小:74.94 MB 可用空间:55.62 MB

2
我应该在SQL Server中嵌套依赖的外部联接吗?
我听说过与此相关的信息不一,并希望能提出规范或专家意见。 如果我有多个LEFT OUTER JOIN,每个都依赖于最后一个,嵌套它们会更好吗? 对于一个人为的示例,JOINto MyParent取决于JOINto MyChild:http : //sqlfiddle.com/#!3/31022/5 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN MyChild AS c ON c.[Id] = gc.[ParentId] LEFT OUTER JOIN MyParent AS p ON p.[id] = c.[ParentId] 与http://sqlfiddle.com/#!3/31022/7相比 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN ( MyChild AS c LEFT …


1
建议使用STATISTICS_NORECOMPUTE
我最近参与了维护一组具有一些有趣的索引问题的数据库。使我最恼火的因素之一是开发,测试,模型和生产机器之间的指标差异。由于差异使调整查询变得相当困难,因此将它们同步起来是我的第一个项目。 在比较测试和模型环境时,我注意到模型环境中的大多数索引都STATISTICS_NORECOMPUTE设置为,ON而测试中的索引没有设置。在所有环境中,每天都有一项工作来更新所有数据库的统计信息。 我从来没有处理过STATISTICS_NORECOMPUTE,所以这是我的问题。处理此设置时是否有最佳做法?如果我要在一天结束时进行统计信息更新,最好打开STATISTICS_NORECOMPUTE所有环境中的所有索引吗?还是有充分的理由不这样做? 编辑:我发现了金佰利特里普的关于这一主题的博客之一在这里,似乎表明STATISTICS_NORECOMPUTE应谨慎充其量只能使用。但是我仍然担心在全球范围内将其关闭。有没有人尝试过,他们经历了什么?

1
提高SQL Server上索引重建的速度
我正在将大量数据导入到一个空数据库中,在开始之前,我禁用了所有非唯一的非聚集索引,以查看是否可以改善导入性能。 现在我想重新启用索引,我想知道是否有什么我可以做的来优化它。 有超过100个表和将近2,000个索引要重建。该数据库的大小为200GB。 我正在运行的脚本的关键部分是: declare c_toggle_index cursor FORWARD_ONLY READ_ONLY for select 'alter index ' + QUOTENAME(i.name) + ' on ' + o.name + ' rebuild' from sys.indexes as i Inner Join sys.objects o On o.object_id = i.object_id Where o.is_ms_shipped = 0 And i.index_id >= 1 and i.type > 1 and …

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.