标签: sql-server-2005

关于在单个存储过程中返回多个聚合的最有效方法？

我有一个电子邮件类型的应用程序，想为用户选择所有消息（收件箱）。问题是我将电子邮件的标题部分规范化到数据库中，这样平面数据就会进入消息表，而从、到、抄送、密件抄送则存储到另一个表中。

根据 PK/ FK 关系。

我非常重视的一件事是 SQL 解决方案的效率，因为这将是多次执行的代码，并且可能是整个数据库中运行次数最多的 sql

这里的上下文是我的数据库模式的视图。

我们公司目前为每个 SQL Server 2005 实例托管大约 400 个数据库。500-600 个数据库，我们看到性能开始下降。数据库大小在极端情况下从 50mb 到 40-60gb 不等，平均可能只有几 GB。

有哪些好的指标需要收集，我们如何获取这些指标来确定我们的瓶颈？

SQL Server 数据库太多是不是性能限制？是数百个数据库的数百个存储过程的所有缓存过程计划吗？查询效率低吗？还是组合？

什么最有可能帮助我们增加每台服务器的数据库数量？所有模式都是相同的，并且数据库将每个客户的数据分开。也许重构一切以便我们可以将多个客户合并到一个数据库中并按客户过滤，或者将我们的查询优化到极致？或者它可能只是 SQL Server 的限制？

我们最近设置了一个运行 Windows Server 2008 的新虚拟机，并在其上安装了 SQL Server 2005 的副本。该服务器已经运行并顺利使用了大约两周。我们对它所做的唯一真正维护是移动数据库文件所在的分区（近一周前完成），我们运行了数据库引擎优化顾问，以查看昨天中午 12 点左右对新索引的一些建议。

下午 5 点刚过，软件像往常一样使用时，有人通知我该程序似乎不再正常工作。我检查了数据库，不仅特定于他使用该程序的数据消失了，而且每张大约五十张表的表格似乎都被抹去了所有记录。

在与应用程序开发人员进行了长时间的交谈之后，很明显这不是他们软件的远程可能的功能。

在争先恐后地恢复原状的过程中，我们通过重新启动之间的运行副本克隆了 VM 的备份，从那以后它已经运行了大约一天的时间。因此，我们没有导致问题本身的事件日志。

你以前见过这样的事情吗？（数据库的所有表中的所有记录都......消失了。）有没有人有一个合理的理论来说明这种情况是如何发生的，如果有什么是合理的预防措施呢？

我在一家小公司（3 个用户）有一台 Linux 服务器，它充当域服务器并在 VMware 下运行两台虚拟机：一台装有 SQL Server 2000，另一台装有 SQL Server 2005，每种情况都在 Win2k 上运行。每个 SQL Server 都有几个小而重要的数据库。

据我所知，Linux 服务器的一生都非常无聊。它有 2GB 的内存，但即使使用虚拟机，它的内存使用量也不会超过 512MB，其余的都分配给缓存。

但是虚拟机性能很糟糕！数据库比我从专用（但古老的）机器上移动它们之前要慢。如果有一段时间没有使用数据库，您可以在它再次开始响应之前喝杯咖啡。

我可以做些什么来提高性能？

假设我有一张foo类似于：

ident int, primaryKey, auto_increment
someNumber int
statusId int
...

someNumber除少数特殊情况外，其中该列等于ident。（在那些特殊情况下，someNumber总是等于前一个ident）。

我看到了一些问题，这些问题看起来像这样的查询SELECT TOP 10 ident, someNumber FROM foo WHERE statusId=@desiredStatusId ORDER BY someNumber会返回错误的 10 条记录。记录都有正确的 statusId，但随机有一个不正确someNumber。例如：

ident        someNumber
-------      ----------
1234567      1234567
1234700      1234700
1234568      1234568
1234569      1234569
1234570      1234570
...          ...

什么可能导致此查询间歇性地返回错误结果？

多年前我在 Oracle 8 上工作时，我曾经在每次批量插入后手动执行 COMMIT 命令。在 SQL Server 中，默认情况下自动提交是 ON 的，这有好处也有危险。

我想知道新版本的 Oracle 是否仍然默认关闭自动提交？我还想知道如何在 SQL Server 2005 中关闭自动提交。

我正在寻找有关如何处理环境报告的建议。我们目前拥有 16 台服务器，其中包含 20 个 SQL Server 2005 实例。我们拥有 6,600 多个数据库，并且在这些实例中不断增长（每个客户 1 个数据库）。我们的大多数数据库运行的大小从 200 mb 到 7gb，其中大约 60 个数据库运行的最大大小从 11GB 到 110gb。

我们正在使用 SAN 进行存储，但在运行影响 IO 的报告时遇到了问题。

我们的一个想法是拉取 60 个更大的数据库，然后使用事务复制来复制这些数据库并在副本上运行报告。

这将使所有较小的数据库在没有较大数据库压力的情况下运行。在未来，我们相信不会再有基于我们公司目标的更大的数据库。

有什么想法吗？

我使用查询来找出数据库文件的大小。我正在使用系统视图和 DMV，因为我确实想找出实际文件大小和理论（在稀疏文件的情况下）文件大小。

Select 
    DB_NAME(mf.database_id) AS [Database Name], 
    mf.Name,  
    mf.physical_name PhysicalName,
    cast(mf.size as bigint) * 8192 mfSize_bytes, 
    fs.size_on_disk_bytes fsSize_bytes
From sys.master_files mf
    Left Join sys.dm_io_virtual_file_stats(DEFAULT, DEFAULT) fs 
        On mf.database_id = fs.database_id and mf.file_id = fs.file_id
Order By DB_NAME(mf.database_id)

我很困惑 - 将两个值都转换为“字节”，然后比较它们。但是在我检查的所有实例中，temdb 文件大小（来自 sys.master_files）都小于磁盘上的文件大小（来自 sys.dm_io_virtual_file_stats）。

在所有其他情况下，如果存在差异，那么这是正确的（磁盘上的大小实际上小于文件大小 - 因为它们是稀疏文件）。

这种差异的原因是什么？

更新：当我查询时

Select is_sparse, * From sys.database_files 

在 SQL Server 2005 数据库快照上，则列 is_sparse = 0（因为它显示的是原始数据库中的文件的属性，而不是快照文件。所以-文档中有错误吗？）。

在我们的一个生产服务器日志文件中，每天都会观察到以下消息。这是什么意思？这是一个严重的问题吗？

由于某些数据库维护或重新配置操作，SQL Server 遇到了 1 次“SQL 计划”缓存存储（计划缓存的一部分）的缓存存储刷新。

我有一个 SQL Server 实例，每晚运行 5 个计划任务，每个任务都运行 SSIS 包。

这些包已运行多年，相关步骤通过代理帐户 (PackageExecutor) 运行。PackageExecuter 与以前是域管理员帐户的 SQL 凭据相关联。

很快，与此管理员帐户关联的域将被关闭。我必须在新域上使用一个新帐户作为与我的 roxy PackageExecutor 关联的管理员帐户。当我为新的管理员帐户创建一个新的凭据并将其与 PackageExecutor 关联时，当我尝试运行我的 SQL 作业之一作为测试时，我开始收到以下错误：

Unable to start execution of step 1 (reason: Error authenticating
proxy *Domain\Admin_Account*@*fully.qualified.domain.com*, system
error: Logon failure: unknown user name or bad password.).  The step
failed.

如果我理解这个相当明确的错误，它告诉我的是与我的代理关联的凭据帐户是正确的。我如何验证这一点？

我知道这个帐户是合法的——我已经将它与每个关联的服务器组相关联，我已经将它设置为服务器上的 sysadmin 用户。

什么可能导致这个问题？

需要明确的是，我没有错误输入与代理凭据关联的帐户名或密码。但是，当我输入帐户名Domain\Admin_Account并单击“检查名称”按钮时，SQL Server 会自动将用户 ID 转换为完全限定版本。我不确定这是否与此问题有关。

我有点不知所措。我已授予我的凭证帐户对我能想到的所有内容的完全访问权限。我可能需要做什么才能让它发挥作用？

更新

抱歉，再提一提。我找到了这篇 MSDN kb 文章。解决方法#1 是我多年来一直在做的。其他人似乎不适用，或者我遗漏了一些东西。任何提示或澄清将是有益的。