我们有一个SQL 2005服务器上的数据库设置为简单事务模式。 日志logging设置为1 MB，并在需要时设置为增长10％。 我们继续讨论事务日志填满的问题，我们需要缩小它。 什么可能导致事务日志填满时，其设置为简单和无限制的增长是允许的？
我通常在专用服务器上运行我的MSSQL服务器，但是我们已经采用了在VMWare ESXi 4主机中运行SQL Server的客户端，坦率地说，它运行得像垃圾一样。 我们已经确定，数据库本身不是问题所在。 我们将相同的数据库部署到比VMWare guest更低规格的专用服务器上，并且运行速度至less提高了5倍。 服务器是： Dual Quad Core Xeon 2Ghz (I don't know the exact model) 24Gb RAM 4x 300Gb SAS (RAID 10) ESXi 4 主持人是： 4x vCPUs 3Gb RAM 80Gb disk space Server 2008 Standard SQL Server 2008 Workgroup 主机上的其他虚拟机stream量非常低。 第二个DC（几乎没有使用），一个低stream量的Web服务器和一个低容量的terminal服务器（在任何给定时间约5个用户）以及其他几个其他客人。 我很久以前就读过一篇关于在Windows和SQL服务器中设置一大堆Paging设置来优化它的文章，但是我找不到它:( 是否有任何提示或窍门可以提供任何人来提高SQL性能？
我正在使用SQL Server 2008 Enterprise，我想安装SQL Server 2008故障转移群集。 我想知道， （1）我需要一个活动目录域吗？ （2）我需要什么最小数量的机器（假设我没有活动的目录域或域控制器呢）？ 在此先感谢乔治
我正在尝试在新SAN中规划SQL数据和日志文件位置。 我有几个很难使用的数据库。 它们主要是针对每天运行一次或两次的应用程序的元数据存储库，因此在任何给定时间基本上都没有任何负载。 性能不会是一个问题。 为了简单起见，我只想将数据和日志文件放在操作系统驱动器（C :)上，而不是在SAN上创build更多的LUN。 假设C：\驱动器具有足够的RAID容错，是否有任何理由不应该这样做？
我一直在阅读，为了性能和安全，最好将以下内容放在不同的磁盘上： tempdb中 数据库文件 日志文件 备份文件 当您考虑使用多个磁盘的RAID时，这将成为大量使用的物理磁盘。 我理解日志文件受益于自己的物理磁盘，因为它们的顺序写入模式，但其他文件可以分为“逻辑”磁盘而不是物理磁盘？
我们试图从VM内部诊断虚拟机显然运行缓慢。 情况： 我们在运行6核12GB虚拟机的Windows Server 2008 R2上安装了IIS托pipe的应用程序。 我们有一个运行在SQL Server 2008R2 SP3集群上的数据库（16+内核，> 16GB RAM） 应用程序正在处理这个数据库的消息队列。 处理主要包括查询/获取和更新，每个消息可能有十几个往返。 有限数量的线程（3）被分配给这个同步的工作负载，所以这些线程阻塞了数据库响应。 数据库显然轻载：只有最大CPU负载的百分之几。 据我们所知，数据库和VM主机都在同一个数据中心。 数据库报告等待asynchronousnetworkingIO的时间相当长， 等待应用程序使用数据。 应用程序虚拟机显然也是轻载：〜20％的CPU。 基础架构不属于我们，我们唯一的访问权限是通过RDP到虚拟机，SQL Management Studio到数据库集群。 我们没有足够的权限来运行探查器，尽pipe我们logging了数据库和虚拟机的性能计数器。 几个星期前，邮件处理速度突然下降了70-80％。 据我们所知，没有任何改变：应用程序没有被修改或重新configuration，并且性能计数器没有指示负载特性的任何改变。 基础设施的所有者已经表示，最终没有任何变化。 作为重新启动过程的一部分，应用程序已重新加载其消息队列。 这涉及到几十万行的一个简单SELECT，然后将其读入内存中的结构。 数据库在几秒内为SELECT提供服务，然后在读取结果集的应用程序上等待约10分钟。 这是一个涉及非常简单的反序列化的单线程操作，在这个硬件上不应该花费几分钟的时间。 我目前的理论是，networking延迟在某种程度上有所增加，但ping只报告“<1ms”，我们没有任何一个基准。 hrPing报告从应用程序服务器到数据库的时间在0.5到2ms之间。 另一种可能是虚拟机的实际CPU容量已经有所下降，但是我预计这会performance为“明显”负载的增加。 还有其他途径可以调查吗？
有谁知道一种模拟SQL Server集群解决scheme的方法吗？ 我们显然不想花大量的钱来构思这个想法，但是我们有很多可用的PC。 我只是想知道是否有任何方法可以欺骗SQL服务器认为它正在通过使用物理机甚至虚拟机安装到群集硬件？ 我当然不希望做任何性能testing，更重要的是testing故障切换场景和复制等。 有任何想法吗？
我试图将数据库从我们的生产服务器移动到我们的testing服务器。 我已经使用Microsoft的数据库发布向导来创build一个包含生产数据库的模式和数据的脚本。 然而**我无法弄清楚如何将这个脚本加载到我们的testing数据库中**由此产生的脚本是大约500MB，这不是由数据库标准“大”，但足够大，我不能复制和粘贴进入查询分析器。 或者，当我尝试直接用SQL Server Management Studio打开文件时，它会报错 操作无法完成。 没有足够的存储空间可用于此操作。 这个错误发生在我select数据库之前 ，所以我相信这是Management Studio抱怨没有足够的内存来加载一个500MB的文件。 有什么build议？
有没有简单的方法来找出什么许可证与正在运行的SQl Server副本或Windows Server 2008相关联？ 我有technet订阅，和MSDN订阅，但有时我也使用试用软件，如果我需要快速获得testing环境一段时间。 我有很多合法的软件（他们都只是为了testing/开发），但我不会不小心要我的一个“试用许可证”意外失效….我怎么知道我是否在运行试用版还是不行？
当前数据库服务器：SQL Server 2005 – Windows Server 2003新目标数据库服务器：SQL Server 2005 – Windows Server 2003 Enterprise – VM Ware映像 当前的数据库服务器上有20多个数据库，一些应用程序数据库…其他基础结构types数据库（Citrix）。 我们希望将所有这些数据库移动到一个新build的虚拟化框中。 所以在进一步的总结 – 是的，这是物理的虚拟。 – 20多个数据库转移到这个新的虚拟SQL 2005框。 – 这个盒子上的应用需要最less的停机时间。 我能想到的几种方法（全部都会被testing）：1.第三方物理到虚拟转换器 – 然后closures旧盒子。 – 关注= SID关联，Windows或SQL Server不喜欢这个。 将所有数据库同时移至新服务器 – closures旧服务器，将新虚拟框上的主机名更改为旧主机名。 一次移动全部，但是使用不同的主机名用于新的盒子 – 这允许在事件中断的情况下并行运行 – challenge =必须在每个应用程序内改变主机名称 – 可能有问题。 逐步移动每个数据库 – 这个woudl意味着一个新的主机名以及更长的项目。 其他人有类似的情况？