表演：告别延迟

通过Techopedia Staff，2016年5月9日

总结：主持人埃里克·卡瓦纳（Eric Kavanagh）就延迟和性能采访了马克·马德森（Mark Madsen），德兹·布兰奇菲尔德（Dez Blanchfield）和Bullett Manale。

您目前尚未登录。请登录或注册以观看视频。

Techopedia内容合作伙伴

Techopedia员工隶属于Bloor Group，可以使用右侧的选项与他们联系。 有关我们如何与行业合作伙伴合作的信息，请单击此处。

• 轮廓
• 网站

埃里克·卡瓦纳（Eric Kavanagh）：女士们，先生们，您好，欢迎再次回到Hot Technologies！ 确实是的！ 我叫Eric Kavanagh，这是我们的热门技术展览，它是与Techopedia的好朋友建立的伙伴关系。 跳至Techopedia.com，以获取广泛的企业技术领域的所有最新信息； 当然，它们也涵盖了消费者的东西。 我们在这里将重点放在企业上的程序上，所以这就是我们今天要做的。

确实有一个关于你的地方，对我有足够的了解，在Twitter上打我@eric_kavanagh，我喜欢Twitter，我喜欢检查这些东西，这是与人保持联系并进行良好对话的好方法， -一次对话。

那么，我们在说什么呢？ 今年是炎热的一年，这是我们当今在信息管理领域中所看到的全部机遇，而我们今天所说的将是查询，它将加速查询。

我想我忘了提到标题“ Performance Play：说再见了。”那么谁想要延迟呢？ 没有人想要等待时间，等待时间就是您坐在那里，单击按钮并等待发生的事情，没有人想要。 孩子们不喜欢它，他们不觉得这很酷，成年人也不喜欢它。 Web的速度让我们所有人都被宠坏了，我们想要很快，现在想要，现在我们将在我们的节目中谈论所有这些。

今天，我们的常客之一“第三自然”的分析师马克•马德森（Mark Madsen）和我们在一起。 我们的新数据科学家Dez Blanchfield从澳大利亚悉尼打来电话。 然后是Bullett Manale，是的，确实是他的名字，实际上应该是两个T。 Bullett Manale是来自非常有趣的公司Idera的来宾，做了很多工作。 我已经知道了，其中之一就是他们不久前收购了一家名为Precise的公司。 我知道他们的首席执行官叫Zohar Gilad，这个名字怎么称呼？ 他真是个聪明人。

但是，人们在您提出的问题中扮演着重要的角色，所以请不要害羞，随时发送您的问题-您可以使用网络广播控制台中的“问答”组件来实现。在右下角。 您也可以与我聊天，我将与演讲者聊天。 我们已经有来自意大利的人打来电话，“ Ciao，ciao。 好吧，我要推动Mark的第一行，然后将甲板交给Mark。 马克，您现在有了WebEx。 把它拿走，地板是你的。

马克·马德森：谢谢，埃里克。 我不会从中间开始，而是从头开始。 因此，仅需提几点评论就可以与Dez和Idera进行讨论，这是一种带有开发，数据库和操作的状态。 而且您知道，如果您对此有所了解，那么在数据库和应用程序市场中，我们仍然会遇到这两种世界的问题，因为开发人员将DBA视为麻烦他们的人。 您必须构建数据模型，无法访问它，不能创建该对象，也不能在数据库中每个表的每一列上放置索引以使其更快。 当然，为什么我们需要这些模型？ 只是数据结构，如果我们更改它们，您难道不可以以序列化形式写出来吗？

问题在于，开发人员知道代码和应用程​​序，但是他们经常不知道的两件事是并发，并发编程以及它们下面的数据库和操作系统。 作为内核开发人员以及操作系统和数据库的开发者，我可以说并发和并行性确实很困难，因此，您学到的很多东西可以使代码获得良好的性能，但是当您使用数据库。 性能看起来不错，测试环境很好，Q&A环境很好，然后又击中了实际系统，然后突然变得不那么好了。 因为它是多方面的，所以代码如何与数据库一起使用，代码如何与环境一起使用以及非常简单的小实践可能会产生严重的影响，具体取决于您运行的规模。

而且，当您开始谈论外部应用程序时，面对外部的应用程序，Web应用程序当然会非常困难，因为事情变得很不错，直到突然之间变得平淡无奇。 您会遇到这些有趣的高原，需要很多细微差别才能理解。

事情的另一面是DBA视图。 DBA的观点是，有一些运营，他们将大部分时间花费在运维上，占80％到90％，也许有10％到20％的时间用于处理正在进行的开发工作。 从这个角度来看，您要么现在就付款，要么以后再付款，如果您将所有时间都花在了前期，那么以后将有一个更好的机会，而不是倾向于探索功能的开发空间，并尝试找出如何最好地做事。 因此，我们遇到了问题，现在我们有了不兼容的方法-持续部署，在应用准备就绪时汇总您的应用，定期执行代码推送，在一家从事开发运营的商店工作。 这种事情可以加快开发速度，但是数据库周围的所有实践以及DBA的工作以及系统管理员经过培训的工作，IT ops的实践都没有跟上发展的步伐。

如果考虑一下，大多数DBA都在变更控制环境下而不是在连续部署环境下运行。 关键在于稳定性和控制力，以及变化和可逆性的速度。 连续部署，如果您不能撤消变更，您将遇到麻烦，因此必须将所有内容构建为易于可逆和可代码转换的，这不是关系数据库，开发实践和管理实践的工作方式。

作为DBA，您还遇到了必须更加主动的问题，因为当您听说一个问题时，成千上万的人正在您的网站上填写投诉表格。 这就使您需要一些新的东西，而这些都是您无法摆脱旧环境的。 您知道，诸如更好的监视和警报之类的事情。 同时，数据库正在成倍增加，我们拥有比以往更多的应用程序来支持比以往更多的事物，它们位于内部，外部，无处不在。 随着越来越多的独立数据集进行分析，人们正在全面启动数据库，因为现在当然可以轻松地建立虚拟机了。 如果您有云提供商或内部云，则可以立即弹出对话框，这将改变您的整个采购路径。

以前的采购路径是：“我有时间来获取服务器，将其推入机架，分配空间，获取存储空间，安装数据库并进行操作”，而不是有人刷信用卡然后在五分钟内完成。 如果这样做，那么现代开发环境的运行速度将大不相同，因此创建数据库很容易，并且只会造成这种扩散问题，就像我们以前从未见过的那样。 这已经持续了十年，这对任何人来说都不是新闻，但这也意味着操作环境变得越来越复杂。

整个客户端服务器环境确实发生了变化，因为它不再是客户端服务器世界。 那时您有一台服务器，一个数据库，如果出了问题，您知道要转到哪个服务器，就知道如何管理该服务器上的资源，因为最佳实践是一个数据库，一个服务器。 虚拟化开始打破这种局面，云进一步打破了这种局面，因为您认为数据库服务器只是软件。 因此环境不是真实的。 它包含的是真实的环境，可能是刀片服务器机架或大型服务器拼凑成碎片，您真的不知道。

围绕数据库管理和性能管理的所有内容，以及围绕一个服务器或几个服务器和几个数据库进行严格控制而构建的数据库，您将无法控制一切。 您正坐在一台机器上，但是虚拟管理器无法轻松地划分带宽，因此内存和CPU都可以正常工作，但是您遇到了一些无法处理的资源瓶颈，然后您尝试修复它时，旧模型本来就很辛苦，要拥有更大的服务器并执行类似的操作，现在它可能真的很简单，只需添加虚拟过程，仅向VM添加内存即可解决。 但是，如果您的VM在拥挤的服务器上并且需要迁移，会发生什么？ 或者，如果您只有AWS系统的大小，并且已经达到最大大小，那么现在您要去哪里呢？

因此，您遇到了所有这些问题，其中环境现在已成为数据库的一部分，您将环境与数据库，所有特殊资源以及应用程序中作为配置一部分的所有内容打包在一起，将配置推送到那里。 这是来自数据库环境的，它很难管理和控制。

如果您查看数据库中心在做什么，他们一直坐在他们的手上，对吧？ 我们一直在远离对待像宠物一样对待数据库和服务器的想法。 服务器有名称，您将它们视为单独的独特事物，将它们视为牛，将其视为畜群。 管理畜群的问题在于，如果您不控制它们，它们最终会踩踏，踩踏不是一件好事。 我们需要更好的监视工具，我们需要更好的方法来处理这些问题，并知道受到了什么影响。 在旧模型中，这很容易，因为您的操作和所有控制系统都会告诉您，但是如果您的服务器名称是UPC代码，则很难弄清楚。

您无法承受错误的警报，也无法承受诸如“这台机器有问题，并且该机器承载30个数据库”之类的事情。 监控控制台亮起时很棒，但是如果红色指示灯再次变为绿色，并且您不知道为什么，并且没有任何历史可追溯到导致它的原因以及导致问题的原因。当时的情况是，您遇到了麻烦。 我们需要可以为我们监控的系统，我们需要更好的监控，以处理维护该数据历史的草书间歇性问题。

更好的事情和简单的指标阈值可以为我们提供关键指标，但不能直接引导我们了解正常情况，异常情况以及这些问题的发生频率。 我们真正在谈论的是监视环境与性能的结合，而供应商一直坐在他们的手上。 他们没有给我们更好的工具。 我们拥有的系统拥有更多的CPU和内存，而不知道该怎么做，但是我们仍然依靠手动干预模型，我们没有使机器运转，无法指导我们，让我们直达问题所在。 ，我们还没有采用这种新样式，即“这里有问题，您可以执行此操作来解决它”或“存在性能问题，这实际上是与特定的SQL语句有关，您可以做到三点使用启发式方法，应用机器学习模型，这些模型可以查看系统的使用模式，以发现问题并避免错误警报。 使用机器执行机器最擅长的事情，扩大DBA或扩大必须处理性能问题的人员。

与旧样式相反，这是新方法。 该数据库存在问题，运行缓慢，因此我们拥有新技术，新方法来实现这一目标，因此我们应该应用这些技术，这就是市场的发展方向。 您会看到它开始兴起，而不是与大型供应商一起出现，而是与第三方公司一起出现，这反映了20年前发生的事情，当时数据库供应商没有提供任何东西来帮助管理系统。 因此，这就是市场发展的方向，因此，我想将其交还给Eric。

埃里克·卡瓦纳（Eric Kavanagh）：好，我要把它交给德兹。 Dez，把它拿走，地板在您的手中。

Dez Blanchfield：谢谢Mark。 您已经完成了涵盖其技术组件的出色工作。 我将以一个略有不同的角度来探讨它，以突出显示世界其他地区所发生的事情，以及对企业和周围数据库的影响。 让我跳到第一张幻灯片。

在您刚刚从技术方面和开发人员方面介绍的内容的背后，我看到企业必须特别面对数据和数据库的挑战，并且显然，我们已经朝着这种重大转变这种大数据的概念，但是数据库实际上仍然是组织保留其业务信息的核心和灵魂，它是从前门一直到后台的。 组织的每个部分都受到某种形式的数据库的影响，并受到数据库的支持，在涉及数据库或数据库系统主题的组织中，我很少参与项目讨论或某种形式的创新战略对话不会出现，围绕我们刚刚听说过的事情的类型，性能和安全性以及开发如何应对这一挑战，数据库适合何处以及我们对环境和应用程序的了解，总是存在疑问与环境对话，设备和移动性又如何？

这仍然是一个非常非常热门的话题，就现代技术而言，在宏伟的计划中已经有很长时间了。 到那时，我相信这是事实，几乎我们在日常生活中所做的一切，即我们的日常生活，现在都受到某种形式的数据库的支持。 当我们考虑周遭的所有事物时，无论是每天要为购买的某些服务在邮件中收到的帐单，都不可避免地要由正在与数据库进行通信的系统打印出来，并且我们就在那里。 我们的电话上具有数据库，其中包含联系人和通话记录以及其他内容。

无论我们走到哪里，演讲和我们正在使用的系统背后都有某种形式的数据库，而且它们通常对我们来说是相当透明的，但事实是它们在那里。 因此，我认为我很快就会讲解为什么这在很短的时间内就成为一个问题。 最初，数据库的概念来自这位可爱的绅士埃德加·科德（Edgar Codd）。 在IBM工作期间，他通过创建我们现在称为关系数据库的概念，改变了数据管理的世界。

最初，数据库是一个数据库，生活是美好的，它在列，引用等等以及表中都非常简单明了，开发软件也非常简单明了，而性能并不是真正的大问题–这是一项令人兴奋的新技术。 我们通过某种形式的终端访问数据库，您实际上只能在大型机上的3270终端的末尾造成如此大的破坏，而其他类型的终端总是会出现其他系统。 而且在大多数情况下，老式终端与现在的Web环境非常相似，也就是说，您需要在终端本身的屏幕上填写表格，然后按Enter键，然后关闭它，以一个数据包的形式发出请求，后端系统将对其进行处理。 这实际上是当今网络浏览器上发生的事情，当您在网络浏览器上键入链接时，这种形式通常不会实时返回系统，尽管如今使用AJAX并不完全是这样。案件。

但是随后发生了一些事情，未来到了，更近了互联网，几乎是昨天，在sec web 2.0中，并且即将到来的是物联网。 在未来的发展过程中，数据库世界才刚刚爆炸，与数据库的交互已成为我们所有人默认情况下要做的事情，这并不是您会去某处做某事（例如购买）的情况要买飞机票，想去星球的另一侧，必须有人在航站楼输入您的所有详细信息，然后进入数据库并打印出机票。

我们现在几乎所做的所有事情，无论是在Google应用程序上打车，还是在网上银行跳跃，我们日常工作，以及某种系统，都由数据库提供支持。 当互联网出现时，通过Web浏览器将它带给我们变得更容易一些，然后通过Web浏览器来实现我们的日常生活，然后Web 2.0出现了，事情变得移动了，事情的规模猛增。 实际上，我在本主题中最喜欢的一句话是：“互联网连接了一切，Web 2.0使其成为移动和社交平台，事情变得非常非常大，现在我们有了互联网，事物和物联网………！！”我们甚至还没有开始想象物联网对数据库系统的影响。

因此，以现代术语来说，我们过去通常认为的终端已经有效地变成了这些东西：手机，各种平板电脑，个人消费级或企业级大屏幕平板电脑，笔记本电脑以及传统台式机以某种形式。 在上一张图像中，您可以看到我们现在用来与数据库系统和应用程序交互的几乎所有形式的界面，从我们手中的小工具到我们似乎都被粘在了一起，逐步过渡到更大的版本，iPad，其他平板电脑和Microsoft Surfaces，再到日常笔记本电脑，如今在专业环境等场合总是如此。 人们倾向于获得一台笔记本电脑，而不是一台固定的台式机，但是在我看来，它们是现代的终端，这也是数据库在我们生活中的管理性能方面（而不仅仅是开发）面临各种挑战的部分原因。

因此，我认为这是企业日常仍面临的最大挑战之一。 每个人都认为数据库是我们唯一的问题，而事实并非如此。 那么，大惊小怪的是什么？ 好吧，从商业的角度出发，当我们从一端到另一端处理与数据库有关的所有事情时，Mark很好地涵盖了技术组件，但是从商业角度而言，作为一个组织，我们会考虑数据库。 我们从基础设计和开发前端一直处理所有事情。 当业务开始时，他们会考虑开发应用程序，开发功能或什至以某种形式实施现有应用程序。 必须进行某种形式的设计和开发，并且必须对如何实现，支持和管理这些数据库系统以及如何跟踪性能等进行大量思考。

数据库环境和应用程序的集成以及API的类型，现在提供的访问类型正变得越来越具有挑战性，更加复杂。 日常的管理，支持和备份，这些都是我们认为已经解决的事情，但是突然之间，规模变得更大了，事情发展得更快了，体积也变得更大了。 由于环境的大小，数据库系统必须支持事务移动的速度。

想想一个在非常高频率的交易环境中的数据库，人类是无法跟踪的，它只是一堆机器在与另一个机器集群作斗争以进行高频交易，买卖和交易量。这些交易发生了。 想想现代场景，例如Netflix电影的早期发行版，您谈论的不仅仅是成百上千甚至数十万，可能有数以百万计的人希望从发行的第二秒开始观看该电影。 所有这些信息都在数据库平台中被捕获，跟踪，记录和分析。

然后，我们生活在一个永远在线的世界，全天候24/7，不仅跟随太阳，而且总有人在午夜想做某事，而营业时间遍及全世界。 因此，默认情况下，正常运行时间和可用性是现在的气候，断电确实是不可接受的。 冗余，如果存在性能问题，或者如果我们需要维护窗口来进行升级，修补程序或安全性，那么实际上，我们需要能够从一个数据库环境切到另一个数据库环境，并自动无缝地进行。

安全性，标准和合规性，最近在世界上发生了很多重大事情，尤其是在GFC方面，因此我们在合规性，安全性和匹配标准方面面临着一系列新挑战，我们需要以便能够以理想的仪表板形式实时报告这些事件。 我们不想派遣猴子到数据中心去寻找事物，我们需要系统立即实时地告诉我们。

而且，几乎没有人谈论过的两个有趣的大事件，我们通常将他们推入高潮，并希望他们永远不要举起丑陋的头脑，但是灾难恢复和业务连续性–这些也是应该做的事情，如果需要，大部分会自动发生。

我们可能花几天时间讨论数据库环境中可能出错的问题的类型以及人类通常已经做出的响应，但是现在我们需要系统和工具才能为我们做到这一点。 一个例子是数据泄露，因此，当我们考虑数据库时，我以各种形式公开地问了这个问题：当我们视而不见，关键问题出了错时，数据库会发生什么？ 尤其是如果没有系统监视性能和安全性以及运行数据库的其他主要方面。

好吧，这可能会发生，这是过去两到三年中最近发生的一些违规事件的屏幕快照。 这些总是来自数据库系统，并且总是存在一些安全性或控制或访问方面的问题，在左上角，我们查看了1.52亿个Adobe帐户，其中每个细节这些客户中的一部分被违反了。 如果使用适当的工具来跟踪和捕获事件并控制安全性，我们可能会避免其中的一些，那么前几百条记录被盗可能会提醒我们，而我们会停止了下一亿五千万。

然后，我们到达了整个旅程的关键点，即：为什么我们需要更好的系统？ 为什么我们不能在这个问题上扔更多的尸体，在我看来我们已经很好地，真正地越过了临界点，并且我当然相信有一个事例已为时已晚，在此情况下扔了更多的DBA，管理员和更多的人这个东西不能解决问题。 我们需要一套更好的工具和一套更好的系统。

我认为这是我支持的五个主要理由，并且根据我在受治理环境的这些私营企业和州中看到的情况，它们在数据库环境中所面临的挑战，和管理它们。

安全性和合规性-第一。 您知道，控制谁可以访问，他们在哪里可以访问，什么时候他们可以访问，他们访问的频率，他们是从哪里访问的。 他们可能实际接触过的设备，所看过的事物的类型以及遵循的合规性。 30天后让人们运行报告来告诉我们一切是否还好不再合适，这必须实时进行。

性能和监视–似乎毫无脑子，但总是如此。 无论我们使用的是开放源代码工具还是某些第三方商业工具，我们始终在很多方面都没有错过任何机会，包括所需的性能监控类型，详细信息以及及时响应的能力。

事件检测和响应–它必须是即时的实时事物，并且我们总是需要一个系统来为我们做到这一点，或者至少需要迅速提醒我们以便我们可以对其进行处理，从而解决出现的少数问题快速，并且不要失控。

管理与行政–同样，我们认为这些问题已经解决，但没有解决。 数据库团队（尤其是DBA）所面临的问题的目标是系统应该为我们处理事情，但我们尚未解决该问题，这仍然是现实。

从设计和开发的前端开始，当我们开始构建这些工具时，我们就构建了数据库环境，能够将适当的工具投入到开发，测试以及集成平台中。 对于我们来说，这仍然不是一件容易的事，并且在整个旅程中，这一定会使我们了解相同的信息，在我看来，我们确实需要更好的系统和更好的工具来帮助我们从中获得所需的结果我们的数据库环境，使业务从客户那里获取价值。 我们不能仅仅丢下更多的尸体和更多的DBA，规模太大，速度太快，体积太高。 这样，埃里克，我可能会转嫁给您。

埃里克·卡瓦纳（Eric Kavanagh）：我喜欢它，我们在那里有很多人，有很多潜在的潜在客户，我们继续前进，将他们的钥匙在短短一秒钟内交给了Bullett。

Bullett Manale：好的。

埃里克·卡瓦纳（Eric Kavanagh）：哦，让我们把它拿走，然后和布勒特（Bullett），现在我将它交给您，地板在您的手中。

Bullett Manale：好的，谢谢。 我认为已经提出了很多优点。 我想快速谈一谈Idera，我们是谁，然后我们就会介入。我将要讨论的工具，我认为我们正在谈论的很多东西，我们可以某种形式，并讨论使用该工具Diagnostic Manager产品与这些领域保持一致的某些领域。

现在，我首先要做的就是给您一些有关Idera是谁的背景知识； 自2003年以来我们就一直在使用，因此我们仅从SQL Server工具开始，这就是我们今天要关注的是Diagnostic Manager产品。 但是您可以看到这里拥有的所有内容，并且正如最近提到的，我们最近已经收购了Precise，通过收购，我们还拥有了Embarcadero，因此我们拥有了相当不错的产品组合。

就性能监控而言，就SQL Server而言，我要谈论的产品是Diagnostic Manager，它与我们正在讨论的主题保持一致，是我想要谈论的产品。 现在，这个产品自Idera诞生之初就已经存在了，从2005年左右开始，我很幸运地成为其中的一员。而且，我已经看到了很多变化SQL Server，从物理到虚拟的转变，发生的所有这类事情，以及随着环境的增长对DBA的需求，以及这些类型的事情。

首先，我们的产品的典型用户是DBA，因此，当我们第一次与潜在客户交谈时，我们主要是在与DBA交流。 我们不是在与IT经理或董事交谈，它可能在某个时候达到那个水平，但是最初的开始是DBA有问题，DBA试图解决该问题，很多时候我们您将获得数据管理器，DBA或代理DBA，这是很幸运的，在某些情况下，它是会议室中技术最先进的人。 现在，很明显，当您进入大型企业环境时，通常将获得成熟的DBA，它们将是使用该工具的DBA。 我继续，并在Wikipedia上添加了一些内容。 就像维基百科所说的那样，它超出了DBA的职责。

如果您浏览此处的清单，那么很多事情，我就不会读了，但是您会想到很多典型的事情，然后在其中之一上进行监视并优化数据库的性能，这是一个很大的成就。 有趣的是，当您与DBA交谈时，总是总是首先被指责的是他们，当涉及到问题时，并不一定是他们的错，而是在出现性能问题时，通常是应用程序与DBA数据库相关联，他们是应该受到指责的人，因此，他们一直在寻找原因不是他们的错。 在很多情况下，他们可以使用诊断管理器这个工具来帮助他们。

但是到了最后，如果数据库没有运行，那么其他很多事情也就不重要了，您的应用程序也无法正常工作，那么对于其中的许多事情来说就没有关系了的东西。 首先，我们希望能够确保用户体验我们所知的方式不会减少，这是DBA一直在努力的方向。 我认为，如果您看一下人们通常购买和使用SQL Diagnostic Manager产品的原因，则可能是第一个原因，也许不是最重要，最不重要或最不重要，但这在总体上是平等的，根据您与之交谈的原因，这些原因中，几乎总是一两个，总是存在某种需要。

但是第一个就是能够将实例作为他们管理的SQL的集中视图。 有趣的是，在很多情况下，如果您问DBA：“您管理多少个实例？”该数字变化频繁，以至于在某些情况下他们不确定。 因此，您不仅需要将所有内容都显示在屏幕上，还需要一些其他功能。 您想要掌握这些信息，想对其加以利用，因此Diagnostic Manager绝对可以帮助您做的事情之一就是能够为您提供对环境的这种看法。

而且，这不仅是对环境的看法，而且还表明数据库管理员DBA很满意，并且如果愿意，它是一个以DBA为中心的控制台。 它是为数据库管理员设计的。 那里有很多监视工具，那里有很多性能工具，但是就像我说的那样，最终，DBA想要一个专门为DBA设计的工具，因为有许多特定于它们的功能在他们的日常中。

话虽如此，您拥有SCOM，HPF，所有其他技术，但是他们想要的是与他们正在做的事情相对应的事情。 我认为我们可以通过该产品在这一领域提供帮助，您将在第二秒钟内看到它。 我们在DBA上看到的另一件事无疑也是我们前面提到的事情之一，那就是他们显然必须能够看到正在发生的事情，并且他们必须能够查看整个企业并且在知道发生了什么事时有一些内心的平静。 但与此同时，他们并没有坐在那里盯着控制台。

还记得您刚才在列表中看到的所有这些要点吗？ 他们也必须做其他事情，所以这不仅仅是等待火灾扑灭。 在很多情况下，会开会，或者与数据库管理员相关的许多维护窗口都在深夜睡觉的时候运行，因此他们必须能够回头看看发生了什么。 在很多情况下，如果您什么时候都没发现，或者问题消失了，或者至少在SQL Server中，问题就变成了一个问题，您正在处理不响应的情况不再有该问题的遗留物。 这些问题消失了，残留的问题也消失了，这意味着您需要解决的问题更少了，可以使用的信息也更少了。

话虽这么说，这绝对是Diagnostic Manager可以帮助您解决的问题之一，那就是让您了解过去，查询过去的信息，“我是否有阻塞警报，是否存在死锁问题，我们是否有资源方面正在发生的事情？”我可以返回查询该信息。 我可以深入了解具体的时间点。 我将能够直接在工具中执行所有这些操作。

所有这些事情，无论是内部应用程序还是外部应用程序，DBA都想知道，因为他们希望能够看到导致问题的原因。 编写代码的是组织内部的人员还是组织外部的人员并不重要。 他们仍然希望能够隔离它，以便他们知道问题正在发生，并且知道问题的根源。

因此，性能和责任感是我们产品功能的关键部分。 我们可以提供所有这些详细信息，这很不错，您有能力向下钻取。 如果存在瓶颈，则可以将其与应用程序，用户，数据库和查询相关联。 再说一遍，它就像一支抽烟的枪。 您在查询运行时与执行的操作之间有直接的关联？ 它不仅涉及查询本身，还涉及查询本身的执行，随着时间的推移，查询是否会变得更糟？ 使用产品，这些问题也可以得到解答，如果您要积极主动，那肯定是一件好事，可以说：“嘿，这是一个不好的查询，但是男孩看着它随着它运行的进一步，我们可以看到它的运行情况越来越糟，我对此可以采取一些措施。”

如果我们进入这里的下一个区域； 这可能是–我会说这是其中之一。 在展示我们的产品时，我要问的问题之一是，我总是会问数据库管理员：“您如何得知与SQL Server数据库相关的问题？” 这很有趣，因为现在（很自然）在大多数时候（大多数时候）他们都在关注我们的产品，因为在很多情况下，他们正试图解决特定的需求。 但是，有趣的是，最初听到的东西-至少对于SQL Server来说，是这样的-您知道，在SQL Server的早期，您拥有SQL Server，然后拥有Oracle。 每个人都有Oracle，SQL Server有点像，因为它缺少更好的表达方式，所以它刚开始时就是数据库的红发继子。

然后，随着Microsoft向其添加更多功能，它逐渐成为一种企业工具。 显然，此后已经走了很长一段路。 但问题是，有一次您可能会争辩说，数据库在当今并不被认为是至关重要的。 而且随着时间的流逝而改变。 因此，在很多情况下，人们都在努力解决问题，并说：“您知道吗？ 我已经拥有了所有这些SQL Server数据库，我正在设法解决它。”而不是从服务台上听到问题，或者从特定的人那里听到问题，例如用户自己，他们正在寻找解决方法，他们正在寻找能够在情况发生之前就意识到这些情况的方法。

因此，对于Diagnostic Manager，这也是我们正在尝试做的事情，至少可以使DBA成为第一个了解这些情况或问题的人，以便他们可以做关于它的一些信息，或者在它们发生时就进行，或者更进一步，以分析它正在监视的这些系统。 并能够为您提供主动建议，以改善该实例的性能，并能够定期执行该建议。 例如，我们需要根据工作量添加索引； 这些类型的东西，以及能够胜任的工具。 因此，我们将在工具中看到很多内容。

清单上的另一件事和最后一件事，虽然有点笼统，但绝对值得一提。 特别是，当您进入大型企业级情况时，其中有很多实例，如果我是数据库管理员，那么我总是要监视一些晦涩的事情，例。 因此，我们试图做的是根据典型的DBA要监视的内容进行预期。

话虽如此，您还可以做到–总是会有一些新事物。 因此，我们为您提供了一种在添加安装点后添加需要监视和管理的指标的方法。 因此，任何PerfMon计数器，WMI计数器，SQL Server计数器对象； 所有这些都可以合并到工具中。 您可以添加可以合并到轮询间隔中的其他查询。

而且，最后值得一提的是，我们可以添加并实际与vCenter和Hyper-V进行通信，以便能够从那些环境中提取指标。 因为我们在DBA中发现的一件事是它们通常不是专门的操作的一部分。 您知道，它们不一定通常具有可供他们使用的vCenter环境或此类事物。

因此，问题在于，如果他们正在处理一个SQL Server实例，并且已经为他们分配了资源，但是该实例已虚拟化，那么当他们只是监视什么内容时，它们似乎就拥有了世界上所有的资源。在来宾操作系统上。 现实情况是，在主机上，他们可能正在尝试访问30或40、50或100个其他VM，并争用这些相同的资源。 真正看到这种情况的唯一方法是与其他环境以及这些接口进行通信，在这种情况下，我们就是这样做的。

您可以将其他类型的计数器添加到工具中。 现在，不仅要能够监视这些计数器，而且还可以使您向产品介绍的那些新计数器成为它们的一部分，使其成为工具的一部分，就好像它们是现成的度量标准一样。 。 您想要监视的开箱即用的东西； 因此这意味着能够将它们合并到其仪表板中。 这意味着能够将它们添加到您自己的自定义报告中，能够明显地设置阈值并对其进行警报，而且还可以将它们设置为基线并能够基于一些知识（根据您的情况将阈值设置在何处）来设置阈值基线和正常现象。 因此，您还可以在产品中找到很多类似的东西。

我为您提供的就是所谓的“诊断管理器的核心交付物”，接下来，我将继续介绍该产品，并向您介绍一下。共享我的屏幕，好吧，然后将其拖到屏幕上，所以您将看到，这是Diagnostic Manager的控制台。正如我之前提到的，转到第一个核心交付项，可以查看从企业级别的角度来看事情。工具中有许多不同的示例；我们有一种缩略图视图；我们有更多的网格状视图；就灵活性而言，我们还拥有也有一个基于Web的控制台。基于Web的控制台还提供了其他视图，例如按键图和类似的视图。但是，重点是，您具有那种查看和查看事物的能力从高层次上讲。但是，当出现问题时，您将进一步深入研究该工具，并实际看到特定的问题。 障碍，并有某种方式来了解和了解正在发生的事情。 显然，这非常重要。

现在，就能够真正看到过去发生的事情而言； 如果我正在查看昨天或一周前发生的问题，那么在这种情况下，您将需要能够使用特定的SQL实例。 好消息是，如果您知道该产品在什么时间发生问题，则可以直接转到历史记录浏览器。 我可以指出一天中的特定时间； 可能是几周前，也可能是昨天。 但是，无论我从日历中选择哪一天，都将看到不同的轮询间隔。 现在，在这种情况下，我有效地看到了如果我在4月20日下午1:37查看控制台，将会看到什么

因此，我可以回到过去，然后，一旦完成，我们在这里看到的所有不同选项卡都将反映该特定时间点，包括可能运行不佳的查询，包括我遇到了封锁问题。 所有这些内容都会显示在该工具中，这将使我显然可以利用历史信息来解决该问题。 现在，请注意，当我们谈论历史时，这里值得注意的另一件事是，不仅是使用历史来解决问题。 显然，由于其他原因，该历史非常有价值。 而且，其中一项重要任务是能够利用正确的信息有效地做出决策，并能够快速做出决策。 因此，所有这些历史记录，我们正在收集的所有信息都可以作为报告依据。

如果有人来找我说：“我有了这个非常出色的新应用程序。它将改变我们所知道的世界。哦，顺便说一句，它将需要一个数据库，哦，这将真正地钉住数据库。该数据库所在的计算机上的I / O。” 如果我知道要使用它，那么我可以利用这些信息来提供我所有生产服务器的排名，可能基于收集的最后7天。 我将能够很快得出结论，即哪种实例最适合使用该数据库。 因此，这种历史信息显然也非常有价值。

就查询本身而言； 在查看查询方面，我们在该工具中有许多不同的方法可以做到这一点。 我要看的是查询等待视图，因为查询等待视图在评估方面非常有帮助。 如果我遇到瓶颈，则能够从本质上确定影响该特定查询的所有不同区域； 不仅是查询本身以及该查询的影响是什么，而且，您知道它来自哪个应用程序，来自哪个会话，哪个用户调用了它以及所有这些东西，我可以很明显地看到信息实时，但我也能够查看过去的数据。 这就是这里的事情之一，我启动了一个脚本，但是我必须等待它弹出。

在我们等待时，我想–而且我知道我们的时间很短，所以我也想谈一点关于主动通知警报的话题。 正如我所说，当您谈论这类内容时，作为主动部分，有很多工具可以进行警报。 困难的部分是不发送电子邮件。 困难的部分是不写入事件日志或生成SNMP陷阱。 困难的部分是知道何时在适当的时间发送该警报。 因此，随之而来的是很多必须做一些计算的事情，必须理解“关于那个特定实例是什么以及与该实例有关的正常现象？”

因此，对于所有有意义的指标，我们将这些指标作为基准。 实际上，我们向您显示基准，我们将向您显示当前设置的阈值。 然后，另一个有趣的事情是，对于本示例，我将阈值设置为6和10。 从现在起的六个星期后，如果我回到这个实例，该基准可以完全改变，因为默认情况下，计算基准时我们要做的一项工作是滚动7天的计算。 因此，它始终为我提供最新的基准版本。 如果该基线上升到我的阈值，会发生什么？ 在这种情况下，我可以看到并发出以下警告提示：“嘿，您设置的阈值可能设置不正确，具体取决于我们看到的阈值所在的位置，以及基线的明显位置，您可能会收到正常情况的警报。”

因此，除了处理正常现象的症状外，我还可以识别出实际阈值设置不正确的情况。 显然，我可以做的是根据要获得警报的位置设置阈值。 我知道这更多是号召性用语而不是调查以查看是否确实存在问题。 而且我认为该工具的一部分对于基线本身以及能够进行计算真的很有帮助。

现在，使用此产品，您可以实际拥有多个基准。 您可以将它们设置为不同的时间段，并且可以根据基准动态调整阈值，这也是适应SQL Server实例每天发生的更改的一种非常重要的部分。 现在，在这种情况下，我们介绍了许多阈值设置，并向您显示了基线。 但是就实际警报而言，通知本身（关于Diagnostic Manager的最酷的事情）是它确实为您提供了多个警报配置文件。 因此，例如，如果您有一个从凌晨2:00到凌晨5:00的通话中个人资料，那么我可以拥有一个特定于该时间范围的个人资料，并且可以在此处设置所有条件和适当的设置对于我的回应。

现在，关于响应的事情是，在某些情况下，可以，我可以发送电子邮件，也可以启动并生成SNMP陷阱，或写入事件日志。 我们还有很多其他事情可以做，但是当我和DBA交谈时，他们真正喜欢的是，在大多数情况下，很多工作是重复的事实。 他们完全了解问题发生的时间，解决问题的方法。 他们只需要去干预即可。 因此，随着环境的增长，拥有更多实例，这将变得更加困难。 因此，我认为值得一提的是，您可以在工具中执行的操作之一是，您确实可以设置条件，但是可以基于该条件设置响应以运行脚本，运行脚本。工作，以运行可执行文件。 而且，要点是，如果您决定运行脚本，则可以在运行时在脚本内部使用参数填充实际信息。

因此，如果特定数据库存在问题，则将脚本设计为仅针对发生问题的数据库运行。 因此，您可以以自动化的方式动态地解决问题，然后我仍然会收到一封电子邮件，告诉我，“嘿，有问题，但是，问题已得到解决。” 该脚本已运行，您已经知道是DBA，但是实际上并不需要介入。 现在，关于积极主动的注意事项，显然，这里我们还有另一个功能是“分析”功能。 并且，这将针对SQL实例进行常规检查。 而且，在某些情况下，它将根据所需内容进行更深入的研究。 将执行诸如假设索引分析之类的操作。 是否添加索引？ 我要删除索引吗？ 而且，所有这些事情显然都会对我的表现有所帮助，但是再一次，这一切都是关于积极主动。 这是关于能够在工作中断之前做出决定并使其运行得更好的方法。 而且，因此，在很多情况下，这实际上是我们要在这里进行的工作。

回到我们之前讨论的查询等待； 如您所见，这里有一个很大的峰值。 我之前运行了一个脚本，该脚本导致了一些等待活动，正如我之前提到的，我们有一种非常独特的方式来深入研究此信息。 如果我想看看它是什么应用程序； 我可以看到它来自NoSQL应用程序。 我们将能够看到它所绑定的数据库，会话，用户，然后，如果我愿意，我还可以根据等待时间对其进行排名。 因此，我可以说，在那个时间段内发生的所有等待中，哪些等待最频繁？ 而且，如果我看到最常发生的事情，那么真正的好处就是我可以深入研究该等待类型，并且可以看到所有命令。 如果您在这里看，他们正在等待。 而且我还可以主要看到，是哪个应用程序导致了等待。

因此它像拇指酸痛一样伸出来。 我可以立即说：“这是造成我瓶颈的应用程序。现在运行的查询是什么？运行了哪个用户？运行了哪个数据库？”，依此类推。希望如此，它也有助于确保您的环境中没有与数据库相关的延迟。希望这会有所帮助。我现在将继续并将其传递回去，我想我们可以从那里继续。

埃里克·卡瓦纳（Eric Kavanagh）：好的。 所以，我想我会把它扔给我们今天的专家。 马克，也许首先您想发表评论并提出几个问题。 然后Dez，您可以鸣叫。

马克·马德森（Mark Madsen）：是的，谢谢，我真的很喜欢看其中的一些。 这比我以前看到的要智能得多。 我对此背后的数据管理感到好奇； 管理您可以跟踪的指标，并且您知道，这些指标尤其需要通过设置仪表板来寻找诸如转移基准（这是我的宠物痛点之一）之类的事情。 您知道如何处理这些数据，而第二部分是如何处理基准指标，就像某种偏移一样？您是否也能够自动偏移阈值，所以我不必当基线发生变化时，请返回并手动重置阈值？

Bullett Manale：您愿意，所以它的好处是您可以决定。 您都可以做。 我可以设置一个阈值并将其设置为静态设置，也可以选中此框以说：“将其设置为动态阈值，该阈值会随着基线的变化而变化。”并且我有能力并且可以设置默认窗口时间作为基准时间，但是如果需要，我可能会有一个单独的基准时间窗口，例如，从维护时间窗口开始，从凌晨2:00到5:00，因为我要加CPU，驱动器以及其他所有东西，因为那是我们进行所有维护的时候，然后，如果我选择这样做，它将自动将我的阈值调整为超出那些指标正常的范围我选择这样做，这将允许我这样做。基本上，您可以在该工具中设置时间窗口（即基准窗口），并且就时间而言，每个窗口都可以视为一个单独的实体。可以进行动态基准调整。您可以添加基线的任意数量的窗口 您需要，如果有道理。 您可能有一个周末窗口，一个工作时间的工作日，一个在深夜发生的维护窗口等等。

马克·马德森：谢谢。

Bullett Manale：我想回到问题的第一部分，我们确实有，并收集了所有这些信息。 我并没有真正讨论过该体系结构，但是我们有一个后端存储库，您可以完全控制该数据的保留，但是我们还有一个可以在深夜运行的服务所有我们的基准计算，它都会获取数据，收集数据并使其有意义。 显然，除此之外，您还拥有许多报告，我们可以使用这些报告针对特定指标针对您的基准进行报告。 而且，您甚至可以比较同一服务器在不同时间段内针对同一指标的基准。 您可以查看是否存在差异，或差异是多少。 这些选项也很多。

Eric Kavanagh： Dez。

Dez Blanchfield：我想向您提出一个快速问题-该工具可以做什么。 您现在是否在开发的早期阶段就开始使用它，或者它仍主要是生产环境工具？ 换句话说，开发人员是否可以在其早期开发中访问并使用它，然后测试集成阶段？ 还是仍然主要在生产环境中使用？

Bullett Manale：我要说的是，在大多数情况下，我们在生产环境中看到它。 这取决于情况，但是在大多数情况下，我主要会说生产，而我们会这样做。而且，公平地说，我们对开发和测试环境的定价不同，因此更具吸引力。 我们确实看到人们在那些环境中使用它，但是我想说，如果我不得不以一种或另一种方式给您答案，我会说这主要是在生产环境中，我们看到人们对此产品进行投资。 。

Dez Blanchfield：当然，是的，很高兴听到您有不同的定价点，因为显然存在不同的工作量，并且工作量会增加，所有实际工作都在进行。 但是我看到很多组织，特别是在政府部门，当然还有在国防部门，在这些组织中，开发人员正在进行与生产环境相同水平的工具和系统投资，因为他们在进行更多的前期测试。 例如，在国防领域，有一些团队对应用程序，系统和工具进行数十亿次测试，数千亿次测试，并在进行集成测试之前对其进行监视，因为他们希望确保已建立代码和数据库它坐在它下面。 它达到一亿一百万次迭代之类的速度，而当您在野外向某人射击时，它并不会“爆炸”。

Bullett Manale：好的。

Dez Blanchfield：根据我的经验，在老式的数据库世界中，认为数据库环境只存在于数据中，而您中的某些人却很少被看到，也很少被提及，因此，当我们明白了这一点时，工具和正在开发应用程序，尤其是使用分析平台开发的应用程序，现在已在我们的手机和设备中使用。 您是否看到客户在日常讨论中带来了与数据库性能和数据库管理有关的对话，而不仅仅是纯粹的技术专家？ 而且我知道您之前曾提到过，主要是您在与DBA交谈，但是现在在一般词汇中是否有这种趋势，您是否看到人们在讨论这些主题，而不是极客？

Bullett Manale：很难说。 我的意思是，就像我在大多数情况下所说的，无论如何，我们在销售过程中与之打交道的人都是从业者，即DBA。 因此，就您的问题而言，您只是在说：“就IT组织内部的人员而言，他们是否变得对数据库的了解更多？”我想这是问题，我可能会说答案是“是”。 根据我现在的位置，我可能不会每天都这么看，但是我想，如果我了解您的问题，那将是我的答案。

Dez Blanchfield：是的，没关系。 抱歉，这可能是一个充满挑战的问题，因为显然您在世界上的主要利益是事物的技术方面。 我很好奇，在我的日常活动中，我看到组织很早就开始将其带入对话。 因此，当他们谈论新的计划，新的项目，新的工作计划时，立即出现的事情之一是：“我们如何对其进行监控，如何对其进行跟踪，如何处理出现的问题，而不是发射而上线？”

Bullett Manale：我要说的是-

Dez Blanchfield：对不起，继续。

Bullett Manale：我要说的是我确实看到了一种趋势，我想我应该说–您知道，在过去的很多次里，您都会说：“我们遇到了问题，所以现在我们需要一种工具。 ” 而且我认为，如果有道理，那么在问题发生之前就可以使用该工具会带来更多的认可。 因此，我想这肯定会变得越来越普遍，“嘿，我们需要一个监控工具，我们需要一些东西。”人们肯定会看到该产品的价值，因为就像您前面说的那样，只需添加DBA和添加新实例时，您需要能够对其进行管理的东西。您需要对它进行管理的东西，这就是为什么我们对这种产品也抱有很大的接受的原因。

Dez Blanchfield：快速提问。 这需要住在哪里？ 它是否必须坐在数据中心内LAN的背面，尽可能靠近数据库环境，还是放在舒适的某个位置（可能在云中），或某种形式的第三方云中？ VPN隧道还是对各种环境的远程访问？ 就环境和监控而言，这需要放在哪里？

Bullett Manale：就体系结构而言，有一个后端存储库，也就是一个SQL Server数据库。 我们拥有可以是胖客户端或瘦客户端的控制台； 我们为您提供两者的选择。 而且，我们还有一个瘦客户机，它确实专门针对移动设备。 但是就实际位置而言； 它可以放在一个环境中，真正棘手的部分是，从我们需要收集的许多信息中，在某些情况下甚至在很多情况下确实需要管理权限。 现在，我们不让您这样做； 如果您愿意，您可以收集数据，并且仅收集我们无法收集的内容，因为我们没有管理员权限，如果您选择这样做，我们只会让您看不到该信息。

根据口味的不同（例如您在谈论AWS），某些环境会比其他环境更好，但是就实际环境本身而言，通常需要使用SA身份验证来针对实例收集数据。 或者，如果这是一个不受信任的域，通常是您想要这样做的时候，但是有多个域； 只要他们之间有信任，我们就可以反对它们。 无论是在LAN上还是在WAN上，这都没有关系，就我们收集的数据量而言，实际的收集本身可以忽略不计。 如果我们有足够大小的WAN连接，那不是问题。 我已经看到了在其分支机构遍布美国的环境。 而且这是在每个不同位置上的一台服务器，并且他们正在对其进行集中监视。 棘手的部分只是确保您具有相当数量的连接来执行此操作。 希望这能回答您的问题，整个地图上都有。

Dez Blanchfield：的确如此。 谢谢。 因此，今天早上，与会者很快提出了两个问题。 一个是：有什么影响–我们经常看到系统监视工具仅通过监视事物来生成负载，因此问题是，很抱歉现在它滚出了我的屏幕，但只是解释一下； 通过监视我们是否自己产生负载？ 只是观察环境，该工具是否会产生可衡量的影响，还是可以忽略不计？

Bullett Manale：总是会有一点影响，因为它必须查询SQL Server实例以拉回数据。 就像您说的那样，问题是：它可以忽略不计还是有意义？ 开箱即用，您指向的是实例，可以忽略不计。 就像我说的那样，我们已经这样做了一段时间了。 我们有20, 000多个客户，我可以向您保证，如果它对性能产生重大影响，我们将无法开展业务。 话虽如此，我们还允许用户决定他们想要监视的内容。 因此，我认为要提到的重要一点是，每个环境都有点不同。

一个例子是，使用查询监视组件，我们可以做的事情之一就是，我们可以设置您认为是正常界限的阈值。 因此，它可以基于查询的执行时间。 它可能基于CPU，I / O，但作为示例，我们只需要将执行时间设置为零毫秒即可。 实际上，我要告诉该工具要做的是收集自上次提取间隔以来运行的所有查询，并将其纳入我的历史收集中。

现在，当我们这样做时，我们将收集自上次轮询以来在盒子上运行的任何数量的查询。 现在这是可选的，用户可以执行此操作。 我们是说“那是您应该做的”吗？否。但是，如果您想要一个样本数据来收集这些信息，我们也可以选择这样做。因此，总的来说，您可以工具，可以根据自己的喜好对其进行设置和精确调整，但是如果您愿意的话，您确实可以将其打开，并且可以收集很多不一定必要的其他信息收集，如果有道理。

Dez Blanchfield：是的，绝对如此。 我知道我们要花很长时间，但是在结束之前，我想向您提出两个非常好的问题。 他们俩都直接来找我，但是我认为最好是回答他们。 通常的问题是：“就现有系统的知识而言，该工具的适用范围是什么？”因此，我们可以将其插入，并让它自动检测存在的平台，并立即知道该平台的正常情况吗？就像Mark早先所说的那样：平台的一些基础知识，可能不包括Microsoft Dynamics。您知道该平台的知识范围是什么？在当前围绕业务使用的一些现成工具中？

Bullett Manale：我想说的是，通常来说，当我们开始在SQL实例上收集数据时，我们会从阈值和设置的最佳位置着手最佳实践。 也就是说，我们还认识到，无论您是与谁聊天，就最佳实践而言，每种环境都是不同的。 我们最初要做的只是收集数据，我们建议人们做的是，如果需要，您可以将产品试用14天以上。 但是大约两天后，您将开始看到基线数据填充。 一旦有足够的示例信息可以使用，它将开始为您提供有关基线，范围所在以及所有此类内容的上下文。 然后，如果需要，您可以从那里根据收集到的信息自动设置阈值。 确实需要一些初始收集和轮询才能开始确定什么是正常的，以便您可以开始改变阈值。

但我认为还值得注意的是，当您更改这些阈值时，可以在实例的基础上逐组完成。 它可以特定于一个实例，也可以针对所有实例执行此操作，还可以创建诸如模板之类的功能，这样您就可以说：“这是一个生产实例，但这是我想要的模板。分配给它。” 因此，当一个新的生产实例上线时，我们会自动对其应用这些阈值，因为它具有相同类型的硬件，并且通常具有相同的工作负载，因此我们也可以这样做。 希望这对问题有所帮助。

Dez Blanchfield：的确如此。 实际上，您实际上回答了我刚遇到的另一个问题，那就是“是否有试用版下载？” 我知道，我可以回答。 我确定您会确认免费下载，并且我认为您说距网站14天。 您可以下载并使用它。 我很快就猜到了，“我需要什么样的环境才能运行试用版？我可以在笔记本电脑上运行它并玩这个游戏，还是真的需要一台服务器？”

Bullett Manale：它需要的主要是存储库，即2005年或更高版本的SQL Server数据库。 除此之外，还有一些最小的资源要求，.NET要求，仅此而已。 因此，只需安装产品并创建数据库即可。

Dez Blanchfield：完美。 我要向您提出的最后一个问题是，因为我们现在时间不多了，但是很快，大约两三个人问我：“我需要成为一名DBA才能真正开始并运行这个，并且玩吗？”

Bullett Manale：不。我要说的是，如果您是DBA，则将对该工具有不同的用途。 我的意思是，如果您是经验丰富的DBA，那么可能会有更多的价值。 您将对可以利用的工具有更多的了解。 但是作为一个新的DBA，甚至是不是DBA的人，我们确实都有很多建议，我现在就在该页面上。 这些建议将定期提出，关于建议的真正好处是，它们为您提供了提出建议的原因。 但是除此之外，它们还将具有指向外部内容的链接，这些链接还详细描述了为什么提出这些建议。 这样就可以链接到外部Microsoft网站，博客以及诸如此类的所有东西，这些都是外部的。

但是要回答您的问题，这有点像，如果您是高级DBA，那么这里会有很多东西，您可能会利用，您可能不会成为新手DBA。 但是同时，它也是一种学习工具，因为当您阅读这些建议时，您将开始通过使用建议自行挑选其中的一些内容。

Dez Blanchfield：太棒了。 谢谢。 我真的很喜欢演示部分。 演讲很棒。 该演示太棒了。 记忆中很快，您的网站上就有一个完整的资源中心，我建议人们也去看看。 我记得昨晚经历了一些细节。 从博客，数据和对话到内存，您已经拥有了各种各样的东西，您的大多数产品文档也都在线上了，是吗？

Bullett Manale：是的，这是正确的，我认为您引用的表格是community.idera.com网站。 然后，我还要提到一件事，您之前曾问过它：“它能识别环境吗？” 在新实例或添加实例方面，我们还有另一个工具可以发现实例。 一切都与库存和管理库存有关。 就实际发现实例而言，我只是将您指向该方向。 但是实际上，就性能和监控而言，我们谈论的所有这些内容都将在诊断管理器中发挥作用。

Dez Blanchfield：太棒了。 看，覆盖率很高。 非常喜欢您的演讲。 我喜欢现场演示，这是我今天早上所有的事情，因为我知道我们可能已经过去了10分钟了。 埃里克，我会再回头给你。

埃里克·卡瓦纳（Eric Kavanagh）：好。 我只是喜欢演示。 我很高兴您做了演示。 我很高兴在进行问答时认真思考一下。

Bullett Manale：太好了。

埃里克·卡瓦纳（Eric Kavanagh）：因为这使人们对您正在查看的内容有所了解，并且让我感到惊奇的是，我认为我们仍然在学习如何与这些计算机对话，直到您掌握了它。 我的意思是，这种诊断水平非常复杂，并且每天都在变得越来越好。 我们对实际发生的事情有了更多的了解。 但是，您确实需要一个可以忽略，阅读，将认知能力置于您正在做的事情后面的人，对吗？

Bullett Manale：是的，在很多情况下，我的意思是–我希望我可以告诉您这是一个DBA，但是正在发生的事情太多了。 我的意思是，我们确实提供了指导，我们也提供了帮助，但是最终，这需要人们对我们提供的数据做出决策。 我认为这不会很快改变。

埃里克·卡瓦纳（Eric Kavanagh）：嗯，这对那里的真实人们是个好消息。

Bullett Manale：是的。

埃里克·卡瓦纳（Eric Kavanagh）：您将希望有人在看这个，一个团队在看这个，并且您会学到的，就像您从Bullett那里听到的那样，通过研究这些建议，您将了解正在发生的事情。 我从那段历史中猜测，我想您已经触及了这一点，Bullett，但很快，那段历史使您能够识别出重要的模式，因此能够在将来发生时识别它们，对吗？

Bullett Manale：是的。 我们可以做的一件事是随着时间的推移跟踪查询的性能。 我们还可以明显地查看其他事物，例如基线，并观察它们的变化，并且显然会在发生这种情况时得到警报和类似的信息，因此您绝对具有这种能力。

埃里克·卡瓦纳（Eric Kavanagh）：听起来不错，伙计们。 我们在这里待的时间不会很长，但是我想回答这些问题。 非常感谢您的时间和关注。 我们会存档所有这些网络广播。 在线跳至Techopedia.com或InsideAnalysis.com，您将看到两个地方的链接。

因此，我们向您告别。 再次感谢您，下周我们将与您联系，下周，周二，周三，周四还会再进行三场网络广播。 伙计们，下周我们再和您谈谈。 照顾自己。 再见。

Techopedia内容合作伙伴

Techopedia员工隶属于Bloor Group，可以使用右侧的选项与他们联系。 有关我们如何与行业合作伙伴合作的信息，请单击此处。

• 轮廓
• 网站