Questions tagged «sql-server-2005»

SQL Server 2005（主要版本9.00.xxxx）。还请标记sql-server。

2
SQL编译对SQL Server的性能有多严重的影响？
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 我正在分析一个SQL Server 2005实例，通过PerfMon的SQLServer:SQL Statistics - SQL Compilations/sec指标，我发现平均值约为170左右。 我剔除了SQL事件探查器，并寻找SP：Compile或SQL：Compile事件。显然它们不存在。我没有找到Stored Procedure/SP:Recompile和TSQL/SQL:StmtRecompile事件。我在探查器中看到的数据量表明这些是看错的事件，尽管我不确定。 所以我的问题。任何一个答案都是不错的。 如何查看SQL Server中正在编译的内容？ 我选择了错误的指标来查看吗？在Perfmon还是SQL Profiler中？ 关于Stored Procedure/SP:Recompile和TSQL/SQL:StmtRecompileSQL事件探查器中的事件...它们不包括“持续时间”度量标准。如果无法提供查看事件对系统的影响的方法，那么如何评估这些事件对系统的影响。
2
重建事务日志
我们有一个非常大的数据库（〜6TB），该数据库的事务日志文件已删除（在SQL Server关闭的同时，我们已经尝试过： 分离并重新附加数据库；和 删除事务日志文件 ...但是到目前为止没有任何效果。 我们目前正在运行： ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>') ...但是鉴于数据库的大小，这可能需要几天才能完成。 问题 上面的命令与下面的命令有区别吗？ DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) 我们应该REPAIR_ALLOW_DATA_LOSS代替执行吗？ 值得注意的是，数据是从其他来源派生的，因此可以重建数据库，但是我们怀疑，与重新插入所有数据相比，修复数据库要快得多。 更新资料 对于那些得分较高的用户：该ALTER DATABASE/REBUILD LOG命令在36小时后完成并报告： 警告：数据库“ dbname”的日志已重建。事务一致性已丢失。RESTORE链已损坏，并且服务器不再在先前的日志文件上具有上下文，因此您将需要知道它们是什么。 您应该运行DBCC CHECKDB来验证物理一致性。数据库已置于仅dbo模式。当准备好使数据库可用时，您将需要重置数据库选项并删除所有额外的日志文件。 然后，我们运行了一个DBCC CHECKDB（花了大约13个小时），这是成功的。可以说，我们都已经了解了数据库备份的重要性（并授予项目经理对服务器的访问权限...）。
5
在T-SQL中使用IF会削弱还是破坏执行计划的缓存？
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 有人向我建议，在t-SQL批处理中使用IF语句会降低性能。我试图找到一些确认或验证此断言。我正在使用SQL Server 2005和2008。 断言是以下批处理： IF @parameter = 0 BEGIN SELECT ... something END ELSE BEGIN SELECT ... something else END SQL Server无法重新使用生成的执行计划，因为下一次执行可能需要其他分支。这意味着SQL Server将基于执行当前可以确定需要哪个分支的基础，从执行计划中完全消除一个分支。这是真的吗？ 另外在这种情况下会发生什么： IF EXISTS (SELECT ....) BEGIN SELECT ... something END ELSE BEGIN SELECT ... something else END 无法提前确定执行哪个分支的地方？
5
为什么链接服务器在CASE表达式中限制为10个分支？
为什么这样CASE表达： SELECT CASE column WHEN 'a' THEN '1' WHEN 'b' THEN '2' ... c -> i WHEN 'j' THEN '10' WHEN 'k' THEN '11' END [col] FROM LinkedServer.database.dbo.table 产生这个结果？ 错误消息：消息8180，级别16，状态1，行1的语句无法准备。消息125，级别15，状态4，第1行Case表达式只能嵌套到级别10。 显然，这里没有嵌套CASE表达式，尽管有十多个“分支”。 另一个奇怪的地方。此内联表值函数产生相同的错误： ALTER FUNCTION [dbo].[fn_MyFunction] ( @var varchar(20) ) RETURNS TABLE AS RETURN ( SELECT CASE column WHEN 'a' THEN …
4
是否可以在sql-server中备份和还原数据库的一部分？
我们有一个sql-server 2005数据库，我们定期将其从客户端站点转移到我们的客户端站点。这需要很长时间，因为我们没有直接连接，必须通过其基于Web的文件传输应用程序传输文件。该数据库当前大约为10GB，但是我们不需要所有数据-大多数数据位于审计表和可重新生成计算值的表中。 我已经考虑过创建一个文件组来保存审核表，并希望我可以备份和还原主文件组。我可以很好地备份，但是在还原时出现错误，提示我没有将其还原到同一数据库。是否可以使用文件组将数据库的一部分还原到其他服务器？有一个更好的方法吗？
3
收缩SQL Server日志文件如何影响性能？
我有一个SQL Server 2008数据库，该数据库的数据文件大小约为2GB，但日志文件超过8GB。在2008年之前的数据库中，我可以使用“备份日志”和该TRUNCATE_ONLY选项，但是在2008年及以后的数据库中不再可用。 我确实有一个脚本会截断日志文件： USE [MyDatabase] GO ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT DBCC shrinkfile('MyDatabase_log', 1) ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT GO 这会完全截断日志文件，但是我的问题是：这会影响性能吗？ 我每天执行两次完整备份，因此就数据前滚而言，确实不需要日志。
2
外键会导致死锁并阻碍“读取已提交的快照”吗？
这是来自以下方面的后续问题：https : //stackoverflow.com/questions/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically 尽管同时运行大型报表时，我仍然在ASP.NET应用程序中遇到死锁/超时的情况READ_COMMITTED_SNAPSHOT ON。 所以我有两个问题： 如何检查“ 事务隔离级别快照”是否按预期运行/完全正常？ 我假设外键（在Web应用程序表中的报表表中）引起死锁。我发现这篇有趣的文章： 注意 SQL Server在验证外键时会获取共享锁，即使该事务使用的是读取提交的快照（使用行版本控制读取的提交）或快照隔离级别。当使用这些事务隔离级别检查来自事务的死锁图时，请注意这一点。如果看到共享锁，请检查是否对由外键引用的对象进行了锁定。 如何检查FK是否真正引起了死锁/超时情况，这是否意味着我可以删除那些外键以防止死锁（这是可以接受的工作）？ 注意：我只是从导致死锁的表中读取。 对此主题的任何想法都将不胜感激。 编辑 这是一个死锁图。也许有人可以帮助我了解造成僵局的原因。似乎是在没有任何报告仅由Web应用程序运行的情况下发生的，当两个事务要写入同一个表时（一个更新和一个插入，该插入与存储过程相同）。为什么要获取页锁？如何仅启用行锁？Insert-SP已使用TRANSACTION ISOLATION LEVEL REPEATABLE READ。 我非常怀疑两个触发器（一个更新和一个插入）是造成死锁的原因。这是插入触发器： CREATE TRIGGER [dbo].[CreateRMAFiDates] ON [dbo].[RMA] AFTER INSERT AS BEGIN SET NOCOUNT ON; UPDATE RMA SET [fiCreationDate]=(SELECT idDate FROM tdefDate WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text), [fiPopDate]=(SELECT idDate FROM …
2
从SQL 2005 [SQL_Latin1_General_CP1_CI_AS]迁移到2008-我将通过使用“向后兼容性”来丢失任何功能
我们正在从SQL 2005 [实例和数据库的归类为SQL_Latin1_General_CP1_CI_AS]到SQL 2008 [默认为Latin1_General_CI_AS]。 我完成了SQL 2008 R2的安装，并使用了默认Latin1_General_CI_AS排序规则，并且数据库还原仍在进行中SQL_Latin1_General_CP1_CI_AS。发生了例外的问题- Latin1_General_CI_AS数据库在 其中的#temp表所在的位置 SQL_Latin1_General_CP1_CI_AS，这就是我现在所在的位置-我现在需要有关陷阱的建议。 在安装SQL 2008 R2中，我对安装使用的选项'SQL Collation, used for backwards compatibility'，我必须选择相同的排序规则为2005数据库的选项：SQL_Latin1_General_CP1_CI_AS。 这将使我在#temp表上没有问题，但是有陷阱吗？ 如果不使用SQL 2008的“当前”排序规则，是否会丢失任何类型的功能或特性？ 当我们从2008年迁移到SQL 2012时（例如，在2年内）怎么办？那我有问题吗？ 我会在某个时候被迫去Latin1_General_CI_AS吗？ 我读到一些DBA的脚本完成了完整数据库的行，然后使用新的排序规则将插入脚本运行到数据库中-我对此感到非常害怕和警惕-您会建议这样做吗？
4
如何在不影响性能的情况下备份大型SQL Server数据库？
我们已经收到有关查询运行缓慢或凌晨超时的报告，而我认为运行可能会影响到此的唯一工作就是数据库备份工作。 数据库本身约为300GB，备份作业从凌晨4:30开始，直到凌晨7:00才完成。我们备份作业的当前语法为： BACKUP DATABASE [DatabaseName] TO DISK = N'E:\Database Backups\DatabaseName.Bak' WITH INIT, NOUNLOAD, NAME = N'DatabaseName.Bak', NOSKIP, STATS = 10, NOFORMAT E:\ 是服务器上的一个分区，既包含数据库又包含数据库备份。 还应该注意，这是虚拟服务器，而不是专用的独立服务器。切换到虚拟服务器后，我们立即开始抱怨备份过程中的速度降低，因此我认为这可能与之相关。 有没有一种方法可以运行此备份作业，使其在运行时不影响查询性能？ 我们正在使用SQL Server 2005
2
SQL Server如何在将列更新为int时解决事务日志填满的问题
我有一个称为SQL Server 2005的表BRITTNEY_SPEARS_MARRIAGES，它具有以下列： MarrigeId tinyint, HusbandName varchar(500), MarrigeLength int 现在我有另一张桌子 BRITTNEY_SPEARS_MARRIAGE_STORIES StoryId int, MarriageId tinyint, StoryText nvarchar(max) 问题是我们想将MarrigeId列从中更新int为tinyint。我们只是觉得在说完一切之前，布兰妮将会有很多婚姻。 现在BRITTNEY_SPEARS_MARRIAGE_STORIES表中有1800万行（嘿，女孩遇到了一些问题），因此当我们进行更新时，事务日志已填满，SQL Server框消失了。 我们如何解决这个问题？ 无论如何都说“嘿，SQL Server，我将更新此列并将其扩大。在此SQL Server上相信我。请在尝试验证所有内容时不要填写事务日志？”
3
是否可以通过更新分区键在分区之间移动行？
我认为这将是一个相当简单的问题，但实际上，我很难找到答案。 问题：您是否可以通过简单地更新分区列使其越过分区边界，将分区表中的数据行从一个分区移至另一个分区？ 例如，如果我有一个带有分区键的表： CREATE TABLE SampleTable ( SampleID INT PRIMARY KEY, SampleResults VARCHAR(100) NOT NULL, ) 使用映射到主键的分区功能： CREATE PARTITION FUNCTION MyPartitionFunc (INT) AS RANGE LEFT FOR VALUES (10000, 20000); 是否可以通过将SampleID从1更改为（例如）500,000，将行从第一分区移动到第三分区？ 注意：我将其标记为sql server 2005和2008，因为它们都支持分区。他们有不同的处理方式吗？
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.