通过Techopedia Staff，2017年4月19日
要点：主持人埃里克·卡瓦纳（Eric Kavanagh）与罗宾·布洛尔（Robin Bloor）博士，里克·谢尔曼（Rick Sherman）和IDERA的Bullett Manale讨论了预报。
您必须注册此事件才能观看视频。 注册以观看视频。
埃里克·卡瓦纳（Eric Kavanagh）：女士们，先生们，您好，再次欢迎您回到Hot Technologies网络广播系列！ 我叫Eric Kavanagh，我将主持您今天的网络研讨会，名为“通过最佳预测节省时间，金钱和麻烦”。“当然，我错过了标题的第一部分，即“最佳布置计划”。总是在这个节目上谈论这个。 因此，“热门技术”当然是我们的论坛，以了解当今世界上有哪些很棒的产品，企业技术领域，人们正在使用它们做什么，它们如何工作以及所有这些有趣的东西。
正如我所建议的，今天的主题涉及预测。 确实，您正在尝试了解组织中将要发生的事情。 无论用户在做什么，如何使他们满意？ 如果他们在进行分析，如果他们在进行实际工作，他们正在面对具有交易系统的真实客户，无论情况如何，您都想了解系统的运行方式和运行状况，这就是我们的目的。今天再说。 这有点好笑，因为预测不是我喜欢做的事，因为我迷信了，就像我认为如果我预测得太多，就会发生不好的事情，但这就是我。 不要跟着我走。
因此，今天是我们的演讲者，您的演讲者确实在左上角，瑞克·谢尔曼（Rick Sherman）从波士顿拨入电话，我们从IDERA结识的好友Bullett Manale和我们自己的罗宾·布洛尔博士（Robin Bloor）。 然后，我将其交给罗宾，并提醒其他人：提出问题，不要害羞，我们喜欢好问题，今天将它们分发给演示者和其他人。 然后，罗宾，把它拿走。
Robin Bloor：好的，好吧，正如我所说的那样，我认为我今天要讲一个SQL故事，因为这是进行讨论的背景，并且不可避免地不会与之发生冲突。因为里克（Rick）并不专注于此，也不会与里克（Rick）所说的相冲突。 因此，在SQL故事中，关于SQL有一些有趣的事情，因为它是如此占主导地位。 瞧，这是一个错字，SQL是一种声明性语言。 这个想法是，您可以创建一种语言来请求您想要的内容。 数据库将找出如何获取它。 实际上，它的工作效果相当好，但是有很多事情值得一说，这是整个IT行业基于声明性语言的后果。 用户不了解或不在乎数据的物理组织，这对声明性语言来说是件好事–它使您与所有语言分开，甚至为之烦恼–只需询问您想要的内容和数据库会去得到它。
但是用户不知道他们构造SQL查询的方式是否会影响查询的性能，这是一个缺点。 我已经看到了几百行的查询，这只是一个SQL请求，您知道，它以“选择”开头，然后继续进行子查询等等。 实际上，事实是，如果您希望从数据库中获取特定的数据集合，则可以使用SQL以多种不同的方式提出要求，并且如果您对数据有些熟悉的话，也会得到相同的答案。 因此，一个SQL查询不一定是查询数据的最佳方法，并且数据库根据您输入的SQL的响应会大不相同。
因此，SQL实际上会影响性能，因此使用SQL的人们确实如此，使用SQL的SQL程序员也是如此，他们甚至很少考虑他们将产生的影响，因为实际上，他们的大部分精力都放在数据的操作上，而不是数据的获取和放置上。 BI工具也是如此，如果您愿意的话，我已经看到SQL从各种数据库的BI工具中挤出来，不得不说，很多是，我不会。不能这样写SQL查询。 如果有人喜欢，有人创造了一个小小的马达，不管这些参数是什么，都会抛出一些SQL，并且再次说明，SQL不一定是有效的SQL。
然后我想我要提到阻抗失配，程序员使用的数据与排序时的数据不同。 因此，我们的DMS将数据存储在表中，组织的面向对象的代码主要是编码器，如今正在编程的是面向对象的形式，并且它们按对象结构对数据进行排序，因此不会相互映射。 因此，有必要将程序员认为数据是什么转化为数据库认为数据是什么。 看来我们一定是做错了一些事情。 SQL具有用于数据定义的DDL，它具有DML（数据处理语言）-选择，投影和联接以获取该数据。 现在，只有很少的数学运算和很少的基于时间的内容，所以这是不完善的语言，尽管必须说它已经被扩展并且还在继续扩展。
然后，您遇到了SQL障碍问题，该问题总是比图表更直截了当，因为很多人出于分析的原因提出问题，一旦他们获得了问题数据术语的答案，便想问另一个问题。 因此，它变成了对话框的东西，好吧，SQL不是为对话框而构建的，而是为询问所有您想要的内容而构建的。 值得一提的是，因为有一些产品实际上放弃了SQL，以使用户与数据之间的对话成为可能。
在数据库性能方面–并且这种扩展扩展到所有方面–是的，有CPU，有内存，有磁盘，有网络开销，而且存在锁定问题，一个以上的人希望在给定的数据中独占使用数据时间点。 但是，SQL调用也很差，如果在性能方面实际优化SQL，则可以完成很多工作。 因此，数据库性能因素：设计不良，程序设计不良，工作负载并发丢失，负载平衡，查询结构，容量规划。 那就是数据增长。 简而言之，SQL很方便，但是它不能自我优化。
话虽如此，我认为我们可以转嫁给里克。
埃里克·卡瓦纳（Eric Kavanagh）：好的，里克，让我给您介绍WebEx汽车的钥匙。 把它拿开。
里克·谢尔曼（Rick Sherman）：好的，太好了。 好了，Robin，在开始介绍时，我的图形仍然很无聊，但我们会继续使用。 因此，我同意Robin在SQL方面谈论的一切。 但是，我现在想集中讨论的是对数据的需求，我们将很快处理该需求，即该空间中使用的工具的供应或对该空间中工具的需求。
首先，您阅读的每篇文章都涉及到大数据，大量数据，来自云的非结构化数据以及您可以想象的无处不在的大数据。 但是数据库市场的增长一直伴随着SQL的发展，关系数据库大概到2015年仍占数据库市场的95％。 前三名关系厂商在该领域约占88％的市场份额。 因此，正如罗宾所说，我们仍在谈论SQL。 实际上，即使我们正在寻找Hadoop平台，Hive和Spark SQL（我的儿子是数据科学家）现在也一直在使用它，这无疑是人们获取数据的主要方式。
现在，在数据库方面，有两大类的数据库用法。 一种是用于运营数据库管理系统，因此，全球的企业关系计划，客户关系配置，Salesforce ERP，Oracle，EPIC，N4等。 而且，数据仓库和其他基于商业智能的系统中存在大量且不断扩展的数据。 导致一切，无论在何处以及如何捕获，存储或进行交易，都将最终进行分析，因此数据库的需求和使用量都有很大增加，尤其是市场上的关系数据库。
现在，我们有了需求，我们将收到大量数据。 我并不是在真正谈论大数据，而是在各种企业中使用数据。 但是从供应方来看，对于那些可以管理那些资源的人来说，我们首先要面对的是DBA短缺。 根据美国劳工统计局的数据，从2014年至2024年，DBA职位仅将增长11％-现在拥有DBA职位的人，但我们将在稍后讨论-40人加上年度数据增长空间的百分比。 而且我们有很多DBA； 平均而言，与其他IT职业相比，同一项研究谈到的平均年龄要高得多。 然后，我们有很多人离开该领域，不一定要退休，而是转向其他方面，进入管理领域等等。
现在，他们离开的部分原因是因为DBA的工作越来越难。 首先，我们让DBA管理许多不同的数据库本身，遍布各地的物理数据库以及不同类型的数据库。 现在这可能是关系型的，或者它们可能是其他数据库，也可能是数据库类型。 但是，即使是关系型的，他们实际上也可以尝试管理1、2、3、4个不同的供应商中的任何一个。 在设计数据库或应用程序之后，DBA通常会参与其中。 Robin谈到了如何设计数据库或应用程序，如何设计SQL。 好吧，当我们谈论数据建模，ER建模，扩展ER建模，维度建模，高级维度建模时，通常，应用程序程序员和应用程序开发人员在设计时都考虑了最终目标–他们并不是在为提高效率而设计的数据库结构本身。 所以我们有很多糟糕的设计。
现在，我不是在谈论商业企业应用程序供应商。 他们通常有ER模型或扩展ER模型。 我要说的是，每个公司中的应用程序开发人员都在构建更多的业务流程和应用程序-不一定是为了提高部署效率或有效性而设计的。 而且，DBA本身工作过度，有时还要承担24/7的责任，因此他们不断获得越来越多的数据库。 我认为这与人们不太了解自己的工作或做事的方式有关。 他们自己的小组成员和人们一直在思考：“好吧，所有这些工具都非常易于使用，我们可以继续在他们的工作量上投入越来越多的数据库，”事实并非如此。
这导致我们出现兼职和意外DBA。 我们的IT团队规模很小，他们不一定能负担得起专用的DBA。 现在，对于中小型企业来说确实如此，在过去的十年中，数据库和数据库应用程序的爆炸式增长一直持续。 但是大型公司也是如此，通常他们已经进行了很长时间的数据仓库，商业智能分析。 很久以前，我们曾经为那些项目获得专用的DBA。 我们再也没有专门的DBA。 如果有经验的人，我们负责设计数据库，这很好。 但是总的来说，DBA是应用程序开发人员，他们通常将其作为兼职工作的一部分，他们没有经过正式的培训，而且他们再次针对最终目标进行设计，没有为提高效率而设计。
设计与开发与部署与管理之间存在许多差异。 因此，我们拥有“一分钱明智的，愚蠢的”，那里有一些存钱罐，而没有获得项目所需的技能和资源。 认为每个人都来自“书呆子复仇”，这是我在那里的小照片。 现在，根据人们的需求，我们在SQL中扩展了数据库和数据的使用。 我们限制了DBA的数量–在这些调整和设计以及管理和部署情况下的熟练和专业人士。 而且，我们有越来越多的兼职或偶然的DBA，他们没有经过正式培训。
那么，这些数据库也没有被调优或管理的事实，还有哪些其他问题呢？ 首先，许多人认为数据库系统本身具有足够的工具来管理自己。 现在，工具变得越来越容易-设计和开发-但这与为部署进行良好的设计，良好的管理，容量规划，监视等不同。 因此，首先，人们认为他们拥有所需的所有工具。 其次，如果您是兼职或偶然的DBA，则不知道自己不知道的内容。
我想我忘了那里的一些用语，所以很多时候他们只是不了解他们甚至需要在设计中或者在管理或操作数据库时需要看什么。 如果那不是您的专业，那么您就不会了解自己需要做什么。 第三，SQL是入门工具，因此Robin谈到了SQL，以及有时构造SQL或经常构造SQL的程度很低。 而且，我在BI数据仓库，数据迁移，数据工程领域中最讨厌的事情之一是，人们使用工具而不是使用工具，而是倾向于编写SQL代码，存储过程，即使他们正在使用昂贵的数据集成工具或作为一种昂贵的BI工具，他们经常真正地将其仅用于运行存储过程。 因此，理解数据库设计和SQL构造的重要性变得越来越重要。
最后是这种筒仓方法，在这种方法中，我们让各个人查看各个数据库。 他们不关注应用程序如何工作以及如何相互交互。 而且，他们实际上确实经常在查看数据库及其使用的应用程序。 因此，在数据库上获得的工作负载在设计中至关重要，在对其进行调整中至关重要，在试图找出如何规划容量方面也至关重要，等等。因此，从树上看森林，人们在杂草丛中，查看单个表和数据库，而不查看工作负载中这些应用程序的整体交互。
最后，人们需要研究他们需要研究的关键领域。 当他们计划管理数据库时，他们需要首先考虑该问题，开发一些以应用程序为中心的性能指标，因此他们不仅需要查看此表的结构，如何对其进行特别建模，还需要研究如何使用它？ 因此，如果您有需要在供应链管理中使用的企业应用程序，如果要从网上下订单，如果您正在执行BI（无论您在做什么），则需要查看谁在使用它，如何使用它们使用它，什么时候会发生什么数据量。 您真正要寻找的是等待时间，因为无论如何，所有应用程序都是根据完成某件事需要花费的时间来判断的，无论是人还是只是应用程序或处理器之间的数据交换。 还有什么瓶颈？ 因此，通常，当您尝试调试问题时，您实际上是在尝试查看真正的瓶颈-不一定是如何调优所有内容，而是如何摆脱性能并在等待时间内提高性能和吞吐量–无论您需要查看什么。
您确实需要将数据库中的数据捕获，事务，转换方面以及分析分离出来。 每种都有不同的设计模式，每种都有不同的使用模式，并且每种都需要进行不同的调整。 因此，您需要考虑该数据的使用方式，使用时间，用途以及确定性能指标以及与该用途相关的要分析的关键事项。 现在，当您要监视性能时，您需要查看数据库操作本身。 您希望同时查看数据的结构，索引，分区和数据库的其他物理方面，甚至是数据库的结构（无论是ER模型还是维模型，无论结构如何），所有这些都会对性能产生影响，尤其是在数据捕获分析和发生的转换的不同上下文中。
正如Robin在SQL方面提到的那样，查看这些数据库中这些不同应用程序正在运行的SQL，并对其进行调整至关重要。 并查看总体应用程序工作负载以及这些数据库和应用程序在其上运行的基础架构环境。 因此，无论网络，服务器，云（无论它们运行于何处），也要查看这些应用程序和数据库在该上下文中所产生的影响，所有这些都具有能够调整数据库的相互作用。
最后，当您查看工具时，希望能够查看与此相关的三种不同类型的分析。 您想看一下描述性分析：正在发生的事情和发生的地方，与数据库和应用程序的性能有关。 您想进行诊断分析的能力不仅要弄清正在发生的事情，而且要弄清楚为什么会发生，瓶颈在哪里，问题在哪里，什么运行良好，什么运行不正常？ 但是能够分析和深入研究问题区域以解决这些问题，无论是设计还是您需要做的事情。
最后，最激进或最主动的分析类型是实际上进行一些预测分析，预测分析建模等工作。 我们知道，数据库和应用程序可以在这种情况下工作，如果我们增加容量，获得更多用户，获得更多吞吐量，无论我们在做什么，都能够预测出什么，如何以及在哪里影响数据库，应用程序，使我们能够进行计划和主动解决，瓶颈在哪里，等待时间可能在哪里受苦以及我们需要做些什么来解决问题。 因此，我们希望拥有能够执行性能指标，监视性能的工具，就像这三种类型的分析一样。 这就是我的概述。
埃里克·卡瓦纳（Eric Kavanagh）：好吧，顺便说一下，这是两个精彩的演讲，让我交给Bullett Manale，从那里拿出来。 乡亲们，别忘了问好问题。 我们已经有了一些很好的内容。 把它拿走，Bullett。
Bullett Manale：听起来不错。 谢谢，埃里克。 因此，里克和罗宾说了很多，显然我同意100％。 我想说我把这张幻灯片拉了起来，因为我认为这很合适，对于80年代的“ A队”粉丝来说，我不知道，约翰·汉尼拔·史密斯（John Hannibal Smith）曾说过说，“当计划制定时，我喜欢它。”我想当您特别在谈论SQL Server时，这就是我们要关注的重点，而这正是我们今天要讨论的产品， SQL Diagnostic Manager，这绝对是您必须拥有的那些东西之一； 您必须能够利用自己拥有的数据，并能够根据该数据做出决策，在某些情况下，您并不是在寻找决策。 您正在寻找一些东西来告诉您什么时候资源将耗尽，什么时候资源将耗尽，瓶颈将何时发生。
这不仅仅是监视特定的指标。 因此，使用Diagnostic Manager，它做得很好的一件事就是可以帮助您进行预测，并了解特定于工作负载的信息，而今天我们将谈论很多。 该工具适用于数据管理器，DBA或代理DBA，因此在Rick提到的许多事情中，代理DBA是如此。 在很多情况下，如果您不是DBA，则在管理SQL环境时会遇到很多问号，这是您所不知道的。 因此，您正在寻找可以帮助您的东西，引导您完成该过程，并在此过程中也对您进行教育。 因此，重要的是，您用于这些类型的决策的工具将使您对做出这些决策的原因有一些了解，而不仅仅是告诉您，“嘿，这样做。”
因为我是代理DBA，所以最终我可能是成熟的DBA，具有实际的专业知识和知识来支持该职位。 就是说，当我们谈论成为数据库管理员时，我总是总是先展示这张幻灯片，因为DBA的角色不同，根据您所在的组织，您将拥有该角色，这些内容会在一个地方到另一个地方有所不同-但是通常，您总是要以某种方式负责您的存储，该存储的计划以及对预期容量的了解，我应该说，需要，无论是用于备份还是数据库本身。 您将需要理解和评估。
另外，您将需要能够根据需要理解和优化事物，并且在进行环境监视时，根据需要进行更改很重要，这很重要。环境本身的变化。 因此，在进行预测时，应该考虑诸如用户数量，应用程序受欢迎程度，数据库的季节性等因素。 然后，显然在考虑其他方面，以便能够提供报告和与做出这些决策相关的必要信息。 在很多情况下，这意味着进行比较分析； 这意味着能够专门查看特定指标并了解该指标随着时间的推移所具有的价值，以便您可以预测指标的发展方向。
因此，Diagnostic Manager的许多工具都具有这些功能，并且人们每天都在使用它来进行诸如预测之类的事情，因此，我将容量规划的定义放在这里。 这是一个相当宽泛的定义，实际上只是一个模糊的定义，它只是确定组织满足其产品不断变化的需求所需的生产能力的过程，而实际上，这就是全部内容：关于能够获取您有某种方式的信息，并获取该信息并制定决策以帮助您在数据库的整个生命周期中不断前进。 因此，人们之所以需要这么做是因为，首先，最重要的是，在大多数情况下，这是为了省钱。 显然，企业的主要目标是赚钱和存钱。 但是在此过程中，这还意味着能够确保您的停机时间没有停机时间。 并且能够确保您减少停机时间的可能性，因此避免停机发生，换句话说，就是不要等待停机发生然后再做出反应。
除了能够整体提高用户的工作效率之外，提高他们的效率以使您可以完成更多的业务显然是这里的关键，因此，作为DBA或涉及预测或能力的人员，这些是这类事情规划将必须能够遍历这些信息才能做出那些决定。 然后，总的来说，这显然将帮助您消除浪费，不仅是金钱上的浪费，而且还包括时间上的浪费以及可能用于其他用途的一般资源上的浪费。 因此，能够消除浪费，这样您就不会有与浪费本身相关的机会成本。
那么，话虽如此，我们针对DBA人士所遇到的问题是什么？ 我什么时候会用完空间？ 这是一个很大的挑战，不仅要消耗我现在的空间，而且要根据趋势和过去的历史来确定我何时要用完？ 与SQL的实际实例，数据库相同，我可以整合哪些服务器？ 我要在VM上添加一些内容，就我要合并的数据库以及应该驻留在哪些SQL实例而言，什么才有意义？ 所有这些类型的问题都需要能够回答。 因为在大多数情况下，如果您是DBA或代理DBA，则需要在职业生涯中的某个时候进行整合。 在很多情况下，您将持续进行该操作。 因此，您需要能够快速做出这些决定，而不是在进行猜谜游戏。
我们讨论了瓶颈以及下一步将发生的瓶颈，因此能够再次预见到瓶颈，而不必等待瓶颈发生。 因此，显然，我们正在谈论的所有这些事情在某种意义上是有意义的，因为您在大多数情况下都依赖历史数据来生成这些建议，或者在某些情况下能够自己制定决策，才能提出这些答案。 但这让我想起，当您听到某人出售证券之类的广播广告时，总是“过去的表现并不代表未来的结果”之类的事情。 同样的事情在这里也适用。 您将遇到这样的情况，这些预测和分析可能不是100％正确的。 但是，如果您要处理过去发生的事情和已知的事情，并且能够处理很多这类问题并进行“假设”，那将是非常有价值的与玩猜谜游戏相比，它可以使您走得更远。
因此，显然会出现这些类型的问题，因此我们如何使用Diagnostic Manager处理很多这些问题，首先，我们具有预测功能，能够在数据库和表中执行此操作作为驱动器或音量。 不仅要说“嘿，我们有足够的空间”，而且要说从现在开始六个月，从现在开始两年，从现在开始五年之后，如果我为此预算，我要去多少驱动器空间需要预算吗？ 这些是我将要问的问题，我将需要能够使用某种方法来做到这一点，而不是猜测并把我的手指悬在空中，等着看风向，不幸的是，很多时候，很多决策都是通过这种方式做出的。
除此之外，能够-好像我的幻灯片在那儿被剪掉了-能够以建议的形式提供一些帮助。 因此，能够向您显示一个充满指标的仪表板并说“好，这是所有指标及其所在位置”，这是一回事，但是然后您可以对其中的一些指标有所了解要做的是，这是又一次飞跃。 在某些情况下，人们对DBA的角色受过足够的教育，能够做出这些决定。 因此，我们在工具中提供了一些机制来帮助您解决这些问题，我们稍后将向您展示。 但是，不仅可以显示建议是什么，还可以提供一些关于为何提出该建议的见解，并且除此之外，在某些情况下，还可以实际提出使脚本自动化的脚本。修复该问题也是理想的。
转到此处的下一个，我们将看到，通常来说，了解到度量标准级别是正常的。 如果我不知道什么是正常的，我不能告诉你什么不正常。 因此，有了某种方法来衡量这一点很关键，您就必须能够考虑多种类型的区域，例如-我应该说时间范围-不同的服务器组，能够动态地做到这一点，从警报的角度讲，换句话说，在深夜中，在维护窗口中，根据正在进行的所有维护，我希望我的CPU以80％的速度运行。 因此，在那些时间范围内，我可能希望将阈值提高一些，而在一天当中没有太多活动的时候，我可能希望将阈值提高一些。
这些显然是环境问题，但您可以将其应用于所管理的事物，以帮助您更有效地管理该环境，并使之变得更容易。 显然，另一个领域是能够整体提供报告和信息，从而能够回答那些类型的“假设”问题。 如果我刚刚对环境进行了更改，那么我想了解这种影响是什么，以便可以将相同的更改应用于环境中的其他实例或其他数据库。 我希望能够获得一些信息或弹药，使他们可以放心地进行更改，并知道这将是一个很好的更改。 因此，能够进行比较报告，能够对我的SQL实例进行排名，可以对彼此的数据库进行排名，例如，“哪个是我最大的CPU使用者？”或者哪个使用时间最长？等待的条件之类的？ 因此，该工具还将提供很多信息。
然后，最后但并非最不重要的一点是，您只需要一种总体能力，即您需要一个能够处理您遇到的任何情况的工具，所以我的意思是，如果您的环境很大，并且在很多情况下，您可能会遇到一些情况，您需要根据传统情况提取通常不是DBA在某些情况下甚至希望监视的指标的指标。 因此，拥有一个可以扩展的工具，能够添加其他指标，并能够以与使用即用型即用时相同的形式和方式使用这些指标指标。 因此，能够运行报告，能够向基线发出警报（我们正在谈论的所有内容），也是进行此预测并做出预测以使您获得所需答案的关键部分能够做出这些决定，向前迈进。
现在，使用Diagnostic Manager的方式，我们有了一个集中服务，即一组运行的服务，收集2000至2016年实例的数据。 然后，我们要做的就是获取这些数据，然后将其放入一个中央存储库，然后我们将对这些数据进行处理，显然，我们已经做了很多工作，能够提供更多的见解。 现在，除此之外（这里没有提到的一件事）是我们还有一个在深夜运行的服务，这是我们的预测分析服务，它进行一些数字运算，有助于理解并帮助您成为DBA或代理DBA，以便能够提出这些类型的建议，还可以提供一些有关基准的见解。
因此，我想做的只是一个简单的体系结构示例，这里最大的收获是，实际上没有任何代理或服务位于您要管理的实例上。 但是我想做的实际上只是将您带到这里的应用程序中，并给您一个快速演示。 让我也出去，实现这一目标。 所以，我想我想埃里克（Eric），你能看到那好吗？
埃里克·卡瓦纳（Eric Kavanagh）：是的，现在知道了。
Bullett Manale：好的，我将带您介绍我讲过的这些不同部分。 从本质上来说，让我们从更类似的事情开始，这是您需要做的事情，或者这是将来的时间点，我们将为您提供一些了解。 这能够真正预见-或者我应该说动态预见-事情正在发生。 现在，就报告而言，该工具中的其中一项功能是三个不同的预测报告。 以数据库预测为例，在能够预测一段时间内数据库大小的情况下，我可能会做些什么，我仅举几个例子进行说明。 。 因此，我将使用我的审核数据库，该数据库非常耗费I / O －它要处理大量数据。 我们有，让我们看看，我们将在这里进行此操作，让我们在这里选择医疗数据库。
但问题是，我不仅要看到空间上的变化，还可以说：“看，让我们获取去年的数据” –我将在这里稍作讨论，我真的没有一年的数据，我有大约两个月的数据，但是，因为我在这里选择了一个月的采样率，所以我将能够对此进行预测或预测。假设接下来的36个单位是因为我们的抽样率设置为月（即一个月的单位），然后我将能够运行报告，基本向我展示我们对未来增长的预期。三个数据库。 我们可以看到，在三个不同的数据库之间，我们有不同程度的差异或差异，尤其是它们过去使用的数据量。
我们可以看到这里的数据点代表历史数据，然后该行将为我们提供预测以及支持该预测的数字。 因此，我们可以在表级别执行此操作，甚至可以在驱动器级别执行此操作，在该驱动器级别，我可以预测驱动器的容量，包括安装点。 我们将能够预测出相同类型的信息，但是再次取决于采样率，这将使我能够确定要预测出多少个单位以及将要预测的内容。 还要注意，我们有不同类型的预测类型。 因此，在进行预测时，您会获得很多选择和灵活性。 现在，这是我们要做的一件事，实际上是给您指定日期，并能够说“嘿，在这个日期，这是我们可以预期您的数据增长的地方。”此外，我们还可以为您提供与我们在下班时间执行的某些分析以及服务运行时相关的其他见解。 它所做的某些事情是，它根据过去发生的时间来尝试预测可能发生的事情。
因此，我们可以在这里看到，实际上，一项预测为我们提供了一些洞察力，使我们能够根据过去再次发生的事情，对我们整个晚上可能出现问题的可能性提供一些见解。 因此，显然这很棒，特别是如果我不是DBA的时候，我可以看一下这些东西，但是如果我不是DBA，那么更好的是此分析选项卡。 因此，在此工具出现之前，我们将向人们展示产品，他们将是“那太好了，我看到了所有这些数字，我看到了所有东西，但是我不知道该怎么办”（笑） “因此。”因此，如果我要采取行动来提高绩效，甚至要采取行动，甚至是采取行动，那么我们在这里所拥有的就是一种更好的理解方式。帮助我的环境健康，能够有序地提供这些建议，以及有用的信息提示，以了解有关这些建议的更多信息，甚至实际上具有某些数据的外部链接，这将向我和带我了解提出这些建议的原因。
而且在许多情况下，能够提供可以自动修复这些问题的脚本（如我所说）。 现在，我们在此处进行此分析的部分工作-当我进入配置此实例的属性时，我将向您展示，然后进入“分析配置”部分-我们有许多不同的类别此处列出，部分，我们有索引优化和查询优化。 因此，我们不仅要评估指标本身以及诸如此类的指标，而且还要评估诸如工作负载和索引之类的指标。 在这种情况下，我们实际上将进行一些附加的假设索引分析。 因此，这是我不想要的情况之一，在许多情况下，如果不需要，我不想添加索引。 但是在某个时候，有一个转折点，在这里我说：“好了，表越来越大了，工作负载内正在运行的查询的类型现在变得有意义，可以添加索引。 因此，这样可以让您动态地了解那些可能会像我所说的那样根据环境中发生的事情以及工作负载中发生的事情来提高性能的事物。 ，并进行此类操作。
因此，您在这里可以获得很多很好的信息，并且能够自动优化这些内容。 因此，就预测分析而言，这是我们可以提供帮助的另一个领域。 现在，除了这一点，我应该说，我们还有其他一些领域，我认为这些领域通常可以帮助您做出决策。 而且，当我们谈论决策时，能够再次查看历史数据，可以提供一些见解，使我们了解需要改进的地方。
现在，我们可以做的一件事情就是拥有一个基线可视化工具，它使我们能够有选择地选择我们想要的任何指标-让我在这里找到一个不错的指标-我将要使用SQL CPU的情况，但是重点是您可以返回过去几周的时间来绘制这些图片，以供您查看离群值何时出现，以及从总体上看该值在我们收集数据的时间段内所处的位置。 然后，除此之外，您还将注意到，当我们转到实际实例本身时，我们可以配置基准。 基线是关于能够使事物自动化以及能够被事物通知的非常重要的部分。 正如大多数DBA会告诉您的那样，挑战是，在一天的整个过程中，与晚上和晚上一样，您的环境并不总是运行相同的。具有高水平的CPU或可能发生的任何事情。
因此，在这种情况下，使用这些实际基准，我们可以有多个基准，例如，我可能有一个基准，那就是在维护时间内。 但是我可以轻松地为生产时间创建基准。 这样做的重点是，当我们进入一个SQL实例并且实际上拥有多个基准时，我们便可以预期并能够执行某种类型的自动化，某种类型的补救或只是发出警报，特定于那些时间窗口的方式。 因此，您将在这里看到的一件事是，我们生成的这些基线正在使用历史数据来提供该分析，但更重要的是，我可以静态地更改这些阈值，但也可以动态地自动执行这些操作。 因此，当出现维护时段（或者应该说是维护基准时段）时，这些阈值将自动切换到该时段内我遇到的负载，而可能是在一天中的中间时间当工作负载的影响不那么大时，就不会那么多了。
因此，就基线而言，这是其他要记住的事情。 显然，这些内容对于您也将是非常有帮助的，既可以理解什么是正常现象，也可以理解，参与资源的耗尽。 现在，我们在工具中拥有的另一种功能，就是可以帮助您做出决定，此外，基线，能够围绕这些基准和动态创建的阈值设置警报，就像我之前说的，只是能够运行大量报告，从而帮助我回答有关正在发生的事情的问题。
因此，举例来说，如果我要管理150个实例-就我而言，我没有，那么我们就必须在这里玩假装游戏-但是如果我拥有所有生产实例，则需要了解在哪里我需要关注的领域，换句话说，如果我只有有限的时间来执行某种类型的管理以提高性能，那么我想专注于关键领域。 如此说来，我将可以说：“基于该环境，将我的实例彼此排名，并通过竞争管道给我排名。”因此，无论是磁盘使用率，内存使用率，是否等待，无论是响应时间，我都可以将这些实例相互关联（或者应该说排名）。 显然，该实例位于每个列表的顶部，如果是同一实例，那可能就是我真正要关注的事情，因为显然它再次位于列表的顶部。
因此，该工具中包含许多报告，可以帮助您在实例级别对环境进行排名。 您也可以在数据库级别执行此操作，在此我可以将数据库相互排名。 尤其是对于可以设置的阈值和区域，如果愿意，我甚至可以在此处设置通配符，以便只关注特定的数据库，但是要点是，我可以以相同的方式比较数据库。 此外，就其他类型的比较分析和该工具中的大功能而言，它是我们拥有的基准分析。 因此，如果您在此处向下滚动到服务视图，则会看到有基线统计报告。 现在，此报告显然将不仅帮助我们了解指标值，而且对于特定的实例，我可以了解这些指标，并且对于这些指标中的任何一个，都能够实际查看这些指标的基准。
因此，无论是什么百分比，或者我可以说：“让我们看看过去30天内突破的基准”，在这种情况下，它将向我显示实际值与基准以及显然，我将能够使用这些信息做出一些决定，因此，这是其中一种情况，它取决于您当时要问的是什么问题。 但这显然可以帮助您解决许多问题。 我希望我能说我们有一份报告可以完成所有工作，这有点像简单的报告，只需按一下按钮，它就可以回答您可能回答的每个“假设”问题。 但是现实是，您将拥有很多属性和很多选项，可以从这些下拉菜单中进行选择，从而提出您正在寻找的“假设”类型的问题。
因此，许多此类报告都旨在回答这些类型的问题。 因此，这些报告以及我们已经在工具中向您展示的所有内容（如我之前提到的）具有灵活性，可以合并新指标，进行管理，甚至能够创建，这也很重要计数器或包含在轮询间隔中的SQL查询，以便能够帮助我回答这些问题，您可以添加一些东西，而这些东西可能是我们本来没有希望监视的。 然后，您将能够执行我刚刚向您显示的所有相同操作：基线，运行报告并根据该指标创建报告，并能够回答和执行我向您展示的许多这些不同类型的事情这里。
现在，除此之外-我们显然已经碰到很多事情了-首先是，每个人都切换或切换到VM。 现在，我们有很多人正走向云。 这些类型的事情有很多问题。 我迁移到云端是否有意义？ 我要通过迁移到云来省钱吗？ 如果将这些东西放在VM上，或者在共享资源机器上，我可以节省多少钱？ 这些类型的问题显然也会提出来。 因此，要记住很多事情，借助Diagnostic Manager，我们可以在VMware和Hyper-V的虚拟化环境中添加和提取。 我们还可以添加云中的实例，因此您的环境（例如，Azure DB甚至是RDS）也可以从这些环境中获取指标。
因此，它具有很大的灵活性，并且能够回答这些问题，因为这与人们看到的其他类型的环境有关。 围绕这些问题仍然存在很多问题，而且正如我们看到人们在巩固那些环境一样，他们也将需要能够回答这些问题。 因此，我想对Diagnostic Manager进行一个很好的概述，因为它与此主题相关。 我知道商业智能这个话题已经出现，我们还有一个我们今天没有谈论的商业智能工具，但是它也将为您提供有关回答与您有关的这类问题的见解。立方体以及所有这些不同类型的事物。 但是希望这是一个很好的概述，至少在该产品如何能够帮助制定好的计划方面。
埃里克·卡瓦纳（Eric Kavanagh）：好吧，好东西。 是的，如果他还在那儿，我会把它扔给里克。 瑞克，您有任何疑问吗？
Rick Sherman：是的，所以首先，这很棒，我喜欢。 我特别喜欢扩展到VM和云。 我看到许多应用程序开发人员认为，如果它在云中，则无需对其进行调整。 所以-
Bullett Manale：对，我们仍然需要为此付费，对吗？ 您仍然需要为人们在云上放置的内容付费，因此，如果它运行不佳，或者导致大量的CPU周期，则您需要付出的钱更多，所以不是，仍然需要测量这些东西，绝对。
里克·谢尔曼（Rick Sherman）：是的，我已经在云中看到了很多糟糕的设计。 我确实想问一问，是否还会使用此产品-我知道您提到过BI产品，并且您还有其他许多相互交互的产品-但是您是否会开始研究SQL性能以及此工具中的各个查询？ 还是会使用其他工具？
Bullett Manale：不，绝对如此。 这是我没有涉及的内容，而我的意思是其中的查询部分。 我们有很多不同的方法来识别查询性能，无论是与查询性能相关，还是与等待（如我们在此视图中看到的那样）相关，还是与查询的整体资源消耗相关，我们可以通过多种方法来分析查询性能。 无论是持续时间，CPU，I / O，还是我们也可以查看工作负载本身以提供一些见解。 我们可以在分析部分中提供建议，并且我们还有一个基于Web的版本，可提供有关查询本身的信息。 因此，我可以获得有关缺少索引的建议以及查看执行计划和所有类似内容的能力； 这也是一种能力。 因此，绝对地，我们可以诊断到星期日的七个查询方法（笑），并能够根据执行次数（无论是资源消耗，等待时间，持续时间还是所有这些好东西）提供这种见解。
里克·谢尔曼（Rick Sherman）：好的，太好了。 那么，通过所有这些监视，实例本身的负担是多少？
Bullett Manale：这是一个很好的问题。 回答这个问题所面临的挑战是，这取决于其他事物。 我们的工具提供了很多功能，它提供了灵活性，而灵活性的一部分是您可以告诉它要收集什么而不要收集什么。 因此，例如，对于查询本身，我不必收集等待信息，或者可以。 我可以收集与超过执行时间的查询有关的信息。 举一个例子，如果我进入配置查询监视器，然后说：“让我们将该值更改为零”，事实是，基本上，该工具只是收集了所有运行的查询，而实际上并不是为何会有这种精神，但总的来说，如果我想为所有查询提供完整的数据样本，我可以这样做。
因此，通常来讲，这与您的设置非常相关。 它的开销大约为1-3％，但是还存在其他条件。 这还取决于您的环境中正在运行多少端口查询，对吗？ 它还取决于收集这些查询的方法以及它的SQL版本。 因此，例如，在SQL Server 2005中，我们将无法从扩展事件中提取信息，而我们将从跟踪中提取信息来做到这一点。 因此，就我们收集数据的方式而言，这会有所不同，但是正如我所说，自2004年以来，我们一直在使用该产品。 已经有很长时间了，我们已经有成千上万的客户，所以我们要做的最后一件事就是拥有一个性能监控工具，该工具会导致性能问题（笑）。 因此，我们尽力避免这种情况的发生，但总的来说，大约1-3％是一个很好的经验法则。
里克·谢尔曼（Rick Sherman）：好的，那很低，所以太棒了。
埃里克·卡瓦纳（Eric Kavanagh）：很好。 罗宾，您有任何问题吗？
罗宾·布卢尔（Robin Bloor）：对不起，我沉默了。 您具有多数据库功能，并且我对如何查看多个数据库感兴趣，因此您可以知道可能在各个虚拟机之间分配了更大的资源库，依此类推。 我对人们实际使用它的方式很感兴趣。 我对客户的处理方式很感兴趣。 因为在我看来，当我正与数据库打交道时，这对我来说似乎是从未有过的。 而且我只会在任何给定的时间点以任何有意义的方式考虑一个实例。 那么，人们如何使用呢？
Bullett Manale：一般来说，您所谈论的只是工具本身？ 他们如何使用它？ 我的意思是，通常来说，这是关于能够拥有一个环境的中心点。 放心，知道如果他们凝视着屏幕并且看到绿色，他们知道一切都很好。 从DBA的角度来看，这是发生问题的时间，并且显然是大多数情况，当问题出现在控制台的前面时，很多时候都会发生这些问题，因此能够在问题发生时立即得到通知。 但是除此之外，能够理解问题何时发生，能够深入了解为问题提供原因的信息的核心。 因此，我认为这是最大的部分：对此保持主动，而不是被动。
我与之交谈的大多数DBA（但我不知道，这是其中的很大一部分），不幸的是，它们仍然处于反应性环境中。 他们等待消费者接近他们，告诉他们有问题。 因此，我们看到很多人都试图摆脱这一点，我认为这是人们喜欢此工具的重要原因，因为它可以帮助他们变得更加主动，但也可以为他们提供正在发生的情况的洞察力，这是什么问题，但是在很多情况下，至少我们发现了什么-也许仅仅是DBA告诉我们-但DBA认为，这始终是他们的问题，即使是编写应用程序的是应用程序开发人员没有正确编写它的人，这是他们的责任，因为他们将应用程序带入系统或服务器，然后当性能下降时，每个人都指向DBA指出： “嘿，这是你的错。”
因此，很多时候将使用此工具来帮助DBA说“嘿，这是问题所在，而不是我。”（笑）我们需要无论是更改查询还是任何其他查询，都可以改善这一点。 在某些情况下，就他们的责任而言，这是他们的职责所在，但至少拥有能够帮助他们理解并了解这一点的工具，并且及时地做到这一点显然是理想的方法。
Robin Bloor：是的，我熟悉的大多数站点都已经有一段时间了，因为我去过那里已有一段时间了，可以看到各种多数据库站点，但是我以前发现的大部分地方是专注于少数数据库的DBA。 那就是数据库，如果它们一旦崩溃，对企业来说将是一个真正的大问题，依此类推等等。 而其他的，他们只是不时地收集统计数据，然后看到它们并没有用完空间并且根本不会查看它们。 当您进行演示时，我正在研究这个问题，并且以一种或另一种方式思考得很好，因此可以扩展您的工作，只是为数据库提供了类似的功能，而这些数据库通常没有人关心太多，因为它们具有数据增长的能力，它们的应用程序有时也会增长。 您正在以一种戏剧性的方式扩展DBA的覆盖范围。 因此，这才是真正的问题所在，就是使用这样的一组工具，您最终能够为公司网络中的每个数据库提供DBA服务吗？
Bullett Manale：当然，我的意思是，挑战是，就像您雄辩地说的那样，就像有些数据库管理员关心DBA，而有些数据库他们却不太关心。 而且，该特定产品的方式，获得许可的方式均基于每个实例。 因此，我想您会说，当人们决定“嘿，这不是我想使用此工具进行管理的足够关键的实例”时，会有一个阈值。也就是说，我们还有其他工具我猜有更多的功能可以满足那些不太重要的SQL实例的需要。 其中之一就像库存管理器，我们对实例进行轻度运行状况检查，但除此之外，我们还进行发现操作，因此我们确定已联机的新实例，然后从这一点开始，作为DBA，我可以说：“好，这是SQL的新实例，现在是Express吗？ “这是免费版还是企业版？”这可能是我想问自己的一个问题，但是第二，该实例对我有多重要？ 如果不是那么重要，我可能会使用通用的这种工具来做它，我称之为通用健康检查，因为它们是我作为DBA关心的基本类型：驱动器是否装满了？ ？ 服务器是否响应问题？ 主要的东西，对不对？
借助Diagnostic Manager（我刚刚向您展示的工具），它将下降到查询级别，并下降到对索引的建议，并查看执行计划和所有其他好东西，而这主要是针对关于谁拥有什么，我拥有什么，谁负责？ 我有哪些Service Pack和Hot Fix？ 我的服务器是否运行了我认为是健康的SQL实例的主要成分？ 因此，要回答您的问题，有一些混合。 当我们有人们在看这个工具时，他们通常是在看一组更关键的实例。 就是说，我们有些人购买他们拥有的每个实例并进行管理，因此这取决于。 但我告诉您，总的来说，对于那些认为自己的环境足够重要以拥有这样的工具来管理这些实例的人来说，肯定有一个门槛。
罗宾·布卢尔（Robin Bloor）：好的，在我提出Eric之前，还有一个问题。 仅仅从对行业的观察中就可以得出的印象是，数据库仍然可以生存，但是所有数据都涌入了所有这些数据湖，等等。 确实，这是炒作，而炒作永远无法反映现实，所以我对您在那感觉到的是哪种现实感兴趣？ 是组织中的重要数据库吗？它们是否正在经历传统的数据增长（我曾经以每年10％的速度增长）？ 还是他们的增长超过了？ 大数据使这些数据库膨胀吗？ 你看到的是什么图片？
Bullett Manale：我认为在很多情况下，当有其他可用的技术出现时，我们会将一些数据转移到更有意义的其他部分。 最近，一些更大的数据。 但是，我要说的是，在很多情况下很难归纳这些数据库，因为每个人都有些不同。 总的来说，我确实看到了一些分歧。 我看到，就像我说的那样，人们在很多情况下都转向弹性模型，因为他们想增加资源，而在其他领域则不需要那么多。 一些人正在转向大数据。 但是，很难感觉到这种感觉，因为通常来说，我与之交谈的人们都拥有传统的数据库，并且正在SQL Server环境中使用它。
也就是说，就SQL本身而言，我绝对仍然认为它正在获得市场份额。 而且我认为还有很多人仍在从Oracle等其他地方转向SQL，因为随着SQL版本变得更加高级，它更实惠，而且显然很明显，而且您会在最近的事情中看到这一点。就加密和使它成为环境或数据库平台的所有其他功能而言，SQL正在发展-我想这显然是非常关键的功能。 所以，我认为我们也看到了这一点。 在您看到变化的地方，它仍在发生。 我的意思是，这是十年前发生的事情，但我认为，就SQL Server而言，它还在发生，环境在不断增长，市场份额也在不断增长。
Robin Bloor：好的，Eric，我想观众有一个或两个问题？
埃里克·卡瓦纳（Eric Kavanagh）：是的，让我向您快速提出一个。 实际上，这是一个很好的问题。 一位与会者在问，这个工具能否告诉我表是否可能需要索引来加快查询速度？ 如果是这样，您可以举个例子吗？
Bullett Manale：是的，所以我不知道我是否有一个专门用于添加索引的索引，但是您可以在这里看到，这里有一些碎片建议。 我也只是相信我们刚刚拥有的，这是提供基于Web版本的Diagnostic Manager的一部分，它告诉我我缺少索引。 我们可以查看这些建议，并通过索引该信息告诉我们该建议的潜在收益。 我应该提到的另一件事是，当我们提出建议时，对于其中的许多建议，都将为它构建脚本。 那不是一个很好的例子，但是，您可以看到，索引（重复索引或添加索引）可以提高性能的情况，就像我之前说的，我们做了很多通过假设的指数分析。 因此，从理解工作量的角度来看，将其应用于建议确实很有帮助。
埃里克·卡瓦纳（Eric Kavanagh）：太好了，这将使我对此处的最终评论有所保留。 罗宾（Robin）和我以及瑞克（Rick）都已经听了很多年了，关于自整定数据库的话题。 这是一个自调整数据库！ 我只能告诉你的是：不要相信他们。
Bullett Manale：不要相信炒作。
埃里克·卡瓦纳（Eric Kavanagh）：可能有一些小事情是动态完成的，但是即使如此，您可能还是要检查一下并确保它没有做您不希望做的事情。 因此，在相当长的一段时间内，我们将需要像这样的工具来了解数据库级别的情况，就像罗宾所说的那样，数据湖是令人着迷的概念，但是它们接管的机会可能与之差不多。很快就会有尼斯湖怪兽。 因此，我再说一遍，现实世界中有很多数据库技术，我们需要人员DBA来研究和综合这些东西。 您可以说，您需要知道您在做什么才能使这些东西正常工作。 但是，您需要工具来为您提供信息，以使您知道自己在做什么。 因此，最重要的是DBA会做的很好。
非常感谢Bullett Manale和IDERA的朋友。 当然，还有瑞克·谢尔曼（Rick Sherman）和罗宾·布洛尔（Robin Bloor）。 我们确实存档了所有这些网络广播，因此，请在线上Insideanalysis.com或访问我们的合作伙伴网站www.techopedia.com，以获取有关所有这些内容的更多信息。
亲爱的，我们将以此告别您。 再次感谢您，下次我们会与您联系。 照顾自己。 再见。
