将日志文件和数据文件分开以将磁盘从操作系统中分离出来的标准做法（tempdb，备份和交换文件也一样）当您的驱动器都是基于SAN的，并且您的LUN不是刻有特定的磁盘或RAID组时 – 它们只是SAN上x个驱动器的一部分，而LUN只是空间分配
每个SQL Server数据库pipe理员应该知道什么？ 书籍，博客，工具，你的名字。
就在最近，我有一个开发人员不小心尝试将数据库恢复到生产阶段，而他应该将其恢复到临时副本。 考虑到数据库名称是相似的，即CustomerName_Staging和CustomerName_Production很容易做到。 理想情况下，我会把这些放在完全独立的盒子上，但是这样做成本过高，严格来说，如果用户连接到错误的盒子，就不会阻止同样的事情发生。 这本身并不是一个安全问题 – 它是使用临时数据库的正确用户，如果在生产数据库上有工作要做，那也是他自己的工作。 我希望有一名部署人员将这些担忧分离出来，但是这个团队还不够大。 我很想听听一些关于如何防止这种情况的练习，configuration和控制方面的build议。
曾几何时，我build立了自己的SQL服务器，并控制了驱动器configuration，RAID级别等等。数据，日志，tempdb，备份（取决于预算！）的传统分离通常是非常重要的部分的SQL服务器devise过程。 现在，对于企业级SAN，我只需要为新的SQL Server请求特定的驱动器空间，将其划分为用于数据，备份和文件共享的逻辑驱动器。 当然，我的工作更容易，但是有一部分人不能完全放松，我不能真正地偷看“幕后”，看看那里真正发生了什么。 我的理解是，SAN团队不会以不同的方式configuration不同types的驱动器（针对随机访问优化数据驱动器与针对stream式写入的日志驱动器）。 其中一些可能取决于SAN产品本身（我们有一个HP XP12000和一个HP XP24000），但是我确信惠普软件可以进行各种dynamic性能configuration（监视IO热点并在运行中重新configuration为优化这些LUN），以便应用程序团队和DBA不必担心这些问题。 关于“将所有服务器的负载分散到大量的主轴上”或类似的东西。 我的问题/讨论： 在SAN团队中没有敌人的情况下，我如何向自己和应用程序开发人员保证我们的SQL服务器不会遭受configuration不当的存储？ 只要使用perfmon统计信息？ 其他基准像sqlio？ 如果我在这些SAN驱动器上加载testing，这是否真的给我一个可靠的，可重复的测量，当我们上线时我将会看到什么？ （假设SAN软件可能会在不同的时间点“dynamicconfiguration”）。 SAN的一部分（比如说Exchange服务器）中的重IO会影响我的SQL服务器吗？ （假设他们没有给每个服务器提供专用的磁盘，我已经告诉他们没有） 请求为不同的逻辑驱动器（数据vs日志与tempdb）分离逻辑驱动器在这里有帮助吗？ SAN会看到这些不同的IO活动，并以不同的方式优化configuration它们吗？ 我们现在处于空间不足的状态。 应用程序团队被告知修剪数据存档等。空间问题会导致SAN团队对如何configuration可能影响服务器性能的内部存储（RAID级别等）做出不同的决定？ 感谢您的想法（ 在这个SF问题中简单讨论过类似的话题）
我有三个维护计划设置在Sql Server 2005实例上运行： 每周数据库优化，然后进行完整备份 每日差异备份 每小时事务日志备份 每小时日志备份通常在几百Kb和10Mb之间，具体取决于活动级别，每周差异通常在本周末之前增长到250Mb左右，每周备份约为3.5Gb。 我遇到的问题是，完全备份之前的优化似乎导致下一个事务日志备份增长到超过完整备份的大小的两倍，在这种情况下是8Gb，然后恢复正常。 除了BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY ，有没有什么办法可以减less日志备份的大小，或者根本不会将优化logging在事务日志中，因为它们肯定会在它们之前的完全备份中被考虑？
所以 – 我们有一个内部的公司数据库，通常是这样的：pipe理客户，电话，销售交易和客户协议/计划。 这是一个Access 2000前端和一个SQL Server 2000 Standard后端。 单服务器，双至强3.2GHz，2GB内存，Windows Server 2003，整天占用40％的CPU负载，分布在OS（HT）可见的4个内核中。 后台数据库devise不佳，已经有超过10年的有机增长，由不太熟练的人维护。 这是严重的规范化，一些显而易见的问题包括成千上万的行没有主键或索引的表，这些也在系统中使用最多的一些部分的多表连接中大量使用（例如，呼叫pipe理器应用程序，每天在每个人的第二台显示器上工作8个小时，每隔几秒钟运行一次大量低效的查询）。 前端并不好，这是几百个表单的典型混乱，嵌套保存的查询，VBA代码中embedded式SQL写得不好，几十个“怪癖”等等，每当一个变化被做出时，不相关的东西似乎就破坏了。 我们已经解决了一个“足够好”的多边开发银行，现在有一个不变的政策，因为我们在内部没有访问权重（也没有计划雇用）。 现在公司正在慢慢成长，客户数量不断增加，电话用户数量不断增加，并发用户数量也有所增加，而且最近的performance也变得越来越糟糕（等待表单之间的移动，等待列表填充等）。 ） Perfmon说： 每秒磁盘传输：0到30之间，平均4次。 当前磁盘队列长度：徘徊在1左右 SQL Server的分析器每分钟都会看到成千上万的查询。 客户端的CPU使用率几乎为零，表示正在等待服务器端查询执行。 我已经通过数据库引擎优化顾问把这个工作量，将其build议应用于testing备份，但这并没有太大的差别。 顺便说一句，我们有一个100MB和千兆以太网的组合，全部在一个子网上，两个楼层有40个用户。 对于这个问题。 正如我所看到的，我们有两个select来解决/改善这种情况。 我们可以取消它，并用一个全新的客户关系pipe理系统取而代之，可以定制或部分定制 我们可以通过硬件来延长这个系统的寿命。 我们可以构build一个性能数字惊人的英特尔i7系统，其成本比replace软件的成本低一个数量级。 当一个新的系统最终被开发出来，它可以被托pipe在这个盒子里，所以没有浪费的硬件。 一个新的客户关系pipe理系统不断推迟，closures和closures – 我至less有一年没有看到这种情况发生。 任何关于这种情况的想法，特别是如果你一直在这里，将不胜感激。 谢谢
我刚刚阅读了很多MSDN文档，我想我理解不同的恢复模式和备份链的概念。 我还有一个问题： 完整的数据库备份是否会截断事务日志（使用完全恢复模式）？ 如果是的话：MSDN中提到了哪里？ 所有我能find的是只有BACKUP LOG截断日志。 如果不是：为什么？ 由于完整的数据库备份启动了一个新的备份链，因此在完整备份激活之前保持事务处于活动状态的关键是什么？
有很多可以为数据库启用的SQL Server选项，而最容易被误解的是自动缩减。 安全吗？ 如果没有，为什么不呢？
在虚拟机内运行任何东西都会有一定程度的性能影响，但它对数据库系统的性能有什么影响？ 我发现这个学术参考文件有一些有趣的基准，但这只是一个有限的testing，只使用Xen和PostgreSQL。 结论是，使用虚拟机“不会在性能上花费太高”（尽pipe您可能会认为实际的数据是这样说的）。 与在虚拟机中运行数据库相关的技术，pipe理和其他缺点是什么？ 请张贴可以客观事实支持的答案，我对炒作或其他任何半宗教性的争论都不感兴趣（极客的激情在许多方面都很好，但这对我们来说无能为力。 话虽如此， 在虚拟机中运行数据库时会出现什么问题？ （请张贴参考） 这些问题是重要的吗？ 他们只在某些情况下显着吗？ 什么是解决方法？
有没有办法将Microsoft SQL Server数据库导出到SQL脚本？ 我正在寻找一些与mysqldump类似的东西，取一个数据库的名字，然后生成一个脚本来重新创build所有的表，存储过程，重新插入所有的数据等。 我已经看到http://vyaskn.tripod.com/code.htm#inserts ，但我理想的是想要重新创build一切（不仅仅是数据），在一个单一的步骤来产生最终的脚本。