Questions tagged «sql-server»

与Microsoft SQL Server有关的问题。如果您的问题是特定于版本的，请也为该版本专门标记。您的SQL Server问题属于这里还是其他站点？单击下面一行中的关于sql-server标记的链接。

9
如何将Microsoft SQL Server数据库转储到SQL脚本？
有什么方法可以将Microsoft SQL Server数据库导出到sql脚本？ 我正在寻找一种行为类似于mysqldump的东西，使用一个数据库名称，并生成一个脚本来重新创建所有表，存储过程，重新插入所有数据等。 我已经看过http://vyaskn.tripod.com/code.htm#inserts，但是理想情况下，我希望有一些东西可以重新创建所有内容（而不仅仅是数据），而这些步骤可以一步一步生成最终的脚本。
7
在虚拟机内部运行数据库有哪些弊端？我该如何克服它们？[关闭]
在虚拟机中运行任何内容都会对性能造成一定程度的影响，但是它实际上对数据库系统的性能有多大影响？ 我发现此学术参考论文带有一些有趣的基准，但这仅是使用Xen和PostgreSQL的有限测试。结论是使用VM不会“付出高昂的性能代价”（尽管您可能认为实际数据并非如此）。 在虚拟机中运行数据库有哪些技术，管理和其他缺点？ 请发布可以得到客观事实支持的答案，我对投机或任何其他半宗教论据不感兴趣（极客热情在许多方面都很好，但这在这里无济于事）。 话虽如此， 在虚拟机中运行数据库时出现什么问题？（请发表参考） 这些问题重要吗？ 它们仅在某些情况下有意义吗？ 有哪些解决方法？
22
电源外壳？你用吗？您能告诉我一些我可以使用的很棒的系统管理功能吗？[关闭]
我到处都读到PowerShell是未来的方式。当它第一次发布时，我做了很多虚拟实验室，但是从那时起，我仍然没有在生产环境中使用过它。我知道要处理已经安装的操作系统的日子已经来临，所以我想做好准备。 我想知道： 你用吗？ 您使用PowerShell的“引导”过程是什么？ 您编写了什么样的系统管理任务？ 我是SQL Server数据库管理员。与它有什么关系呢？ 似乎每个人都同意Microsoft会为此努力，但实际上还没有人使用它。我希望听到系统管理员正在使用它来执行日常任务并共享一些代码示例。
16
sysadmin错误的早期迹象
我们将要让我们的第一个sysadmin来照顾许多SQL Server，这些SQL Server以前曾被开发人员和IT支持混为一谈。早就该这样做了，我们多年来一直在努力说服高层人士同意一个人。 好吧，最后他们做到了，但是至少可以说我们提供的薪水并没有真正地鼓舞人心。尽管如此，我们还是以某种方式陷入困境。 我想知道的是，有什么迹象表明新的系统管理员并不真正知道他们在做什么，或者要寻找什么样的危险习惯，尤其是在SQL Server上，因此需要寻找哪些早期迹象。我有点紧张，因为我们的讨价还价搜寻工作可能做得不太好，其他角色也是如此。 有什么想法吗？
43 sql-server 
6
SQL Server（2005/2008）：完全备份会在完全恢复模式下截断日志吗
我刚刚阅读了许多MSDN文档，我想我了解不同的恢复模型和备份链的概念。我还有一个问题： 完整数据库备份是否会截断事务日志（使用完全恢复模式）？ 如果是：MSDN在何处提及？我所能找到的就是只有BACKUP LOG会截断日志。 如果没有：为什么？由于完整的数据库备份会启动新的备份链，因此在日志中保持完整备份之前完成的事务的意义何在？
18
内部数据库不良-替换它还是卡盘硬件？
所以-我们有一个内部公司数据库，这是通常的工作：管理客户，电话，销售交易和客户协议/方案。 它是Access 2000前端和SQL Server 2000 Standard后端。单服务器，双Xeon 3.2GHz，2GB RAM，Windows Server 2003，整天获得约40％的CPU负载，分布在OS（HT）可见的4个内核上。 后端数据库的设计欠佳，并且在不到10年的时间里有机地增长了，由经验不足的个人维护。它的规范化很差，一些明显的问题包括具有成千上万行的表而没有主键或索引，这些表在系统中使用最频繁的某些部分的多表联接中也大量使用（例如，呼叫管理器应用程序，每天在每个人的第二个监视器上放置8个小时，每隔几秒钟运行一次效率低下的大查询）。 前端并没有更好，它是典型的混乱，包括数百种形式的表格，嵌套的已保存查询，VBA代码中编写不佳的嵌入式SQL，数十个“怪癖”等，并且每当进行更改时，似乎无关的东西就会中断。我们已经选择了一个运作良好的MDB，并且由于我们内部没有Access的重量级人物（也没有计划雇用任何一个），因此现在对此没有更改政策。 该公司现在正在缓慢发展，增加了客户，呼叫等的数量，并发用户的数量也有适度的增加，并且性能最近一直在明显变差（等待在表单之间移动，等待列表填充等）。 ） Perfmon说： 每秒磁盘传输：0到30之间，平均4。 当前磁盘队列长度：徘徊在1 SQL Server的探查器每分钟看到数十万个查询。客户端上的CPU使用率几乎为零，表明它正在等待服务器端查询执行。我已经通过数据库引擎优化顾问（DB Engine Tuning Advisor）来处理此工作负载，并将其建议应用于测试备份，但这并没有太大的改变。 顺便说一下，我们在一个子网中混合了100MB和千兆以太网，两层楼有40个ish用户。 问题。 如我所见，我们有两种选择来解决/改善这种情况。 我们可以将其报废并将其替换为全新或定制的CRM系统 我们可以通过固定硬件来延长该系统的寿命。 我们可以构建具有疯狂性能数字的Intel i7系统，而成本却比更换软件少一个数量级。 最终开发出新系统时，可以将其托管在此设备上，因此不会浪费硬件。一个新的CRM系统不断推陈出新-我至少一年都不会看到这种情况。 对于这种情况的任何想法，特别是如果您自己来过这里的情况，将不胜感激。 谢谢
7
完全备份后如何减少事务日志备份的大小？
我设置了三个维护计划以在Sql Server 2005实例上运行： 每周进行数据库优化，然后进行完整备份 每日差异备份 每小时事务日志备份 每小时的日志备份通常在几百Kb到10Mb之间，具体取决于活动的级别，到星期结束时，每日差异通常会增长到250Mb左右，每周备份约为3.5Gb。 我的问题是完全备份之前的优化似乎导致下一个事务日志备份增长到完全备份大小的2倍以上，在这种情况下为8Gb，然后才恢复正常。 除了之外BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY，是否有任何方法可以减小该日志备份的大小，或者完全不将优化记录在事务日志中，因为可以肯定的是，这些优化将在之前的完整备份中得到考虑？
5
不要关注幕后的SAN
曾几何时，我建立了自己的SQL服务器，并控制了驱动器配置，RAID级别等。分离数据，日志，tempdb，备份（取决于预算！）的传统建议始终是非常重要的部分SQL Server设计过程。 现在有了企业级SAN，我只需要为新的SQL Server 请求特定数量的驱动器空间，该驱动器空间分为用于数据，备份和文件共享的逻辑驱动器。当然，这使我的工作更加轻松，但是我当中有一部分人感到不完全自在，因为我不能真正地“窥视”在幕后，看看那里到底发生了什么。 我的理解是，SAN团队不会以不同的方式配置不同的“类型”的驱动器（针对随机访问优化数据驱动器，针对流写入优化日志驱动器）。其中一些可能取决于SAN产品本身（我们有HP XP12000和HP XP24000），但是我确信HP软件可以进行各种动态性能配置（监视IO热点并即时重新配置以优化这些LUN），从而使应用团队和DBA无需担心任何这些问题。关于“将大量服务器上的所有服务器的负载分散到许多主轴上”之类的事情。 我的问题/讨论： 在不与SAN团队抗衡的情况下，如何使自己和应用程序开发人员确信我们的SQL Server不会遭受配置不当的存储的困扰？只是使用性能统计？其他基准，例如sqlio？ 如果我在这些SAN驱动器上进行负载测试，是否真的给我可靠，可重复的衡量标准，以衡量我们上线时会看到的内容？（假设SAN软件可能在不同的时间点以不同的方式“动态配置”。） SAN的一部分（例如Exchange服务器）中的大量IO是否会影响我的SQL服务器？（假设它们没有为每台服务器提供专用磁盘，据我所知它们没有） 请求为不同功能的逻辑驱动器（数据vs日志vs tempdb）分离逻辑驱动器在这里有帮助吗？SAN是否会在这些应用程序上看到不同的IO活动，并以不同的最佳方式配置它们？ 我们现在处于空间紧缩状态。要求应用程序团队削减数据存档等。由于空间问题，SAN团队是否会就如何配置内部存储（RAID级别等）做出不同的决定，从而影响服务器的性能？ 感谢您的想法（此SF问题中简要讨论了类似的话题）
3
如何从SQL Server查询缓存中删除特定的不良计划？
我们有一个特定的SQL Server 2008查询（不是存储的proc，而是相同的SQL字符串-每5分钟执行一次），该查询间歇地缓存一个非常糟糕的查询计划。 该查询通常在几毫秒内运行，但是对于这个错误的查询计划，它需要30秒钟以上的时间。 如何从SQL Server 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.