标签: sql-server

我在 SQL Server 中有这个查询：

SELECT Dated, AccountID, AccountName, Rate, 
  case (when (Credit-Debit) > 0 then Credit-Debit END) as Credit,
  case (when (Credit-Debit) < 0 then Credit-Debit END) as Debit,
  Balance
FROM TempTrallBalance

如何将其转换为 Access 语法？

作为夜间维护计划的一部分，我的 MS SQL Server 2012 数据库使用简单恢复和完整备份选项进行备份。事务日志未备份。此外，在晚上重新启动 MSSQLSERVER 服务或 SQL Server

检查操作系统（Windows Server 2008）中相应文件的属性，我观察到.mdf文件的“修改”时间与维护计划（制作备份）运行的时间相对应，但.log文件修改时间为一两周早些时候。

为什么会有这样的差异，为什么操作系统无法更新修改时间？

那么，.mdf文件修改时间的时间和原因是什么？
是重启SQL Server还是备份时间？

我如何估计数据库上次写入物理磁盘的时间，即相应数据库的 .mdf 文件的最近时间？
如何强制 SQL Server 将数据库刷新到硬盘，以便在看到 SQL Server 运行出现问题的情况下获得最实际的 .mdf 文件？

我正在整合一些 SQL Server 以简化管理。我正在考虑使用 SQL Server 2005/2008R2/2012 的新 VM，每个 VM 作为同一台机器上的单独命名实例。这台机器将仅用于“沙盒”环境，主要用于测试我们备份的恢复。没有应用程序会遇到这个问题。

我可能会遇到多个版本的问题吗？我记得几年前在同一台机器上使用 SQL 2000/2005 时遇到过问题。你们是否使用单独的机器进行恢复测试？

如果固态驱动器在两台机器上都是本地驱动器，它们是否可以用于 SQL Server 故障转移群集上的 TempDB？它在 2012 年受支持，但我们的集群是 SQL 2005。它运行的应用程序不能升级到 2012。

如果 SSD 驱动器在两台服务器上位于相同的本地路径上，它不会在故障转移时重建 TempDB 吗？集群不会识别操作系统识别的任何驱动器吗？或者还有其他需要考虑的问题。

我意识到微软不会支持它，但性能提升会很棒。我们在该集群上的 TempDB 是使用最多的数据库，我们无法更改它运行的应用程序中的任何代码。

我需要在 Windows 8 Home Edition x64 上安装 SQL Server 2005 Express。

但我收到兼容性错误！

我尝试过 SQL Server 2005 的 SP1、SP2、SP3。

Visual Studio 2008 工作正常。

有什么建议？

最近有一个域迁移，我们的 SQL Server 托管在其中。

我有两台服务器，每台服务器大约有 30 个数据库。每个用户都被更改为新域，但这样做时，当我们希望默认为 DBO 时，他们的默认架构更改为他们的域。

我目前正在通过单击 DB -> Security -> Users 然后在常规属性选项卡中手动更改它们，在默认模式框中手动键入 dbo。

有没有办法编写 SQL 代码来运行和调整所有数据库中所有用户的默认模式？

这些查询中哪些最有利于性能？有时我想知道 SHORT 脚本是否真的是最好的关注点。这些脚本执行相同的任务。通过左连接，我只需几行就可以实现我想要的。但后来我尝试使用更长的脚本，使用联合。哪种方法最好？在这之间：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        INNER join products P ON p.productID = q.productID
        LEFT JOIN colors C ON C.colorID = q.colorID
        LEFT JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID = @productID 

和这个：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        inner join products P ON p.productID = q.productID
        INNER JOIN colors C ON C.colorID = q.colorID
        INNER JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID …

我正在帮助解决 SQL Server 机器上的一些问题。曾经运行没有问题的应用程序现在因连接池错误而失败，并且没有对应用程序进行任何可能导致此新问题的更改。

在调查连接池错误的可能原因时，我遇到了这篇文章，其中将“最大工作线程”设置作为可能的原因。我检查了生产服务器，此设置为 54（开发中为 89，QA 中为 79）。

1. 有没有办法查看更改此设置时的日志/历史记录？
2. 是否有任何理由将设置设置得如此低（这篇 MSDN 文章建议 32 位处理器的最低设置为 256，64 位处理器的最低设置为 512）？
3. 低设置是否通常看起来很奇怪，因为有人必须有意识地设置它？

在发现我的 SQL Server 上几乎所有数据库的碎片都超过 40% 后，我决定使用 80 的填充因子对所有表进行索引重建。

重建所有索引后，某些查询似乎永远需要至少两个查询/表。

这是其中一个慢查询：

SELECT  a.FileID,
        a.EventID,
        MAX(b.cyNumber) AS cyNumber,
        MAX(b.skNumber) AS skNumber,
        MAX(b.cyFormat) AS cyFormat,
        MAX(b.Cost) AS Cost,
        MAX(b.PackageRef) AS PackageRef,
        MAX(CASE WHEN b.BMUpdatedON = '1900-01-01 00:00:00.000' THEN NULL ELSE b.BMUpdatedON END) AS BMUpdatedON,
        MAX(b.RunID) AS RunID   
FROM    DB.dbo.[File] a
        INNER JOIN DB.dbo.bicy b ON a.InnerFileID = b.InnerFileID
WHERE   a.FileID NOT IN (SELECT FileID FROM DB.dbo.Event_bicy)
GROUP BY a.FileID,
        a.EventID
OPTION (MAXDOP 1);

我总是OPTION (MAXDOP 1)在所有查询中使用，因为当我不使用它时，查询会运行得很慢。现在，在索引重建之后，似乎发生了相反的情况。如果我删除MAXDOP 1或删除where子句，查询运行得很快，我觉得很奇怪。 …

在我的工作中，我备份了数据库并收到了 .bak 文件。现在我想在我的机器上恢复这个数据库。但我收到以下错误：

无法打开备份设备“C:\Program Files...\MSSQL10_50.SQLEXPRESS...\file.bak”。
操作系统错误 5（无法检索此错误的文本。原因：15105）。
RESTORE HEADERONLY 异常终止。（Microsoft SQL Server，错误：3201）

当然我上网查了一下，例如：http : //social.msdn.microsoft.com/Forums/sqlserver/en-US/805661f1-cf23-4230-ae31-d9cc16505359/cant-restore-backup-from-2005- to-2008r2?forum=sqlexpress

但是所有用户都拥有所有文件夹的权限，所以我真的很困惑。问题是什么？