最高の計画：時間、お金、トラブルを最適な予測で節約

2024

Techopediaスタッフ、2017年4月19日

持ち帰り：ホストのエリック・カバナは、ロビン・ブロア博士、リック・シャーマン、IDERAのバレット・マナーレと予測について話し合います。

ビデオを見るには、このイベントに登録する必要があります。登録してビデオをご覧ください。

Eric Kavanagh：皆さん、こんにちは。HotTechnologiesのWebキャストシリーズへようこそ。私の名前はエリック・カバナです。今日のウェブセミナーの主催者であり、「時間を節約し、お金を節約し、最適な予測で問題を抱えます」と題します。このショーでは常にそれについて話します。ですから、もちろん、Hot Technologiesは、今日の世の中にあるクールな製品のいくつか、エンタープライズテクノロジーの世界、人々が何をしているのか、彼らがどのように働くのか、そのような楽しいものを理解するためのフォーラムです。

そして、今日のトピックは、私が提案するように、予測を扱っています。本当にあなたはあなたの組織で何が起こっているのかを理解しようとしています。ユーザーが何をしていても、ユーザーをどのように満足させ続けますか？分析を行っている場合、実際の仕事をしている場合、トランザクションシステムを使用している実際の顧客に直面しています。ケースが何であれ、システムの実行方法と進行状況を理解する必要があります。今日の話をしましょう。予測は私がやりたいことではないので、ちょっとおかしいです。なぜなら、予測が多すぎると悪いことが起こると思うように、私は迷信的だからです。しかし、それは私だけです。私のリードに従わないでください。

さて、今日のプレゼンターは、本当にあなたの左上隅にいます。リック・シャーマンはボストンから、私たちの仲間のブレット・マナーレはIDERAから、そして私たち自身のロビン・ブロア博士がダイアルインしています。それで、私はそれをロビンに引き渡し、人々に思い出させるだけです。質問をしてください。恥ずかしがらずに、良い質問が大好きです。今日、プレゼンターや他の人にそれを公開します。そしてそれで、ロビン、それを取り去ってください。

Robin Bloor： OK、彼らが言うようにポールポジションにいるので、今日のSQLの話をするだろうと思った。それは今後の議論の背景であり、必然的に衝突しないだろうからリックはこれに焦点を合わせておらず、リックが言わなければならないことと衝突しないからです。そのため、SQLの話では、SQLが非常に支配的であるため、SQLには興味深いことがいくつかあります。それはタイプミスです。SQLは宣言型言語です。アイデアは、あなたが望むものを要求する言語を作成できるということでした。そして、データベースはそれを取得する方法を解決します。そして、実際にはかなりうまく機能していますが、それについて言っておく価値のあるものがいくつかあります。それは、宣言型言語に基づいてIT業界全体を結んだ結果です。ユーザーはデータの物理的な構成を知らないか気にせず、それは宣言型言語の良いところです。それはあなたをそのすべてから切り離し、心配することさえします-あなたが望むものとデータベース行くし、それを取得します。

しかし、ユーザーは、SQLクエリを構造化する方法がクエリのパフォーマンスに影響を与えるかどうかはわかりませんが、それは少しマイナス面です。何百行もの長さのクエリを見たことがあります。これはたった1つのSQLリクエストであり、「select」で始まり、サブクエリなどで繰り返されます。また、データベースから特定のデータのコレクションが必要な場合は、SQLでさまざまな方法でそれを要求し、データにある程度精通していれば同じ答えを得ることができます。そのため、1つのSQLクエリが必ずしもデータを要求する最良の方法とは限りません。データベースは、入力したSQLに応じてまったく異なる応答をします。

そのため、SQLは実際にパフォーマンスに影響を与えるため、SQLを使用する人々、それは真実です。SQLを使用するSQLプログラマーも真実であり、彼らがもたらす影響について考えることはさらに少ないでしょう。彼らの焦点のほとんどは、実際にはデータの取得と書き込みではなく、データの操作にあります。そして、同じことがBIツールにも当てはまります。必要に応じて、さまざまなデータベースのBIツールから絞り出すSQLを見てきました。その多くは、まあ、そうではないと言わざるを得ません。 tそのようなSQLクエリを作成します。必要に応じて、パラメーターが何であれ、SQLを破棄するという小さなモーターを作成した人がいます。また、SQLが必ずしも効率的なSQLであるとは限りません。

それから、私はインピーダンスの不整合について言及したいと思いました。プログラマーが使用するデータは、ソートするデータとは異なります。したがって、DMSはデータをテーブルに格納し、オブジェクト指向コードはほとんどがコーダーであり、オブジェクト指向形式をプログラミングし、オブジェクト構造でデータを順序付けているため、一方を他方にマッピングしません。そのため、プログラマがデータをどう思うかから、データベースがデータをどう思うかに変換する必要があります。そのためには、何か間違ったことをしたに違いないようです。 SQLにはデータ定義用のDDLがあり、データを取得するためにDML（データ操作言語）を選択、投影、結合します。現在、数学はほとんどなく、時間ベースのものはほとんどないため、不完全な言語ですが、拡張されていると言わざるを得ませんが、拡張され続けています。

次に、SQLバリアの問題が発生します。これは常に図よりもまっすぐですが、多くの人が分析上の理由で質問をしていました。質問データの用語に対する答えが得られたら、別の質問をしたいです。だから、それはダイアログのものになります。まあ、SQLはダイアログのために構築されたのではなく、あなたが望むものを一度に尋ねるために構築されました。そして、ユーザーとデータ間の会話を可能にするために実際にSQLを放棄する製品がいくつかあるため、それを知る価値があります。

データベースのパフォーマンスの観点から-そしてこの種のすべてに広がる-はい、CPU、メモリ、ディスク、ネットワークオーバーヘッド、複数の人が特定の場所でデータを排他的に使用したいというロックの問題がありますある時点。しかし、貧弱なSQL呼び出しもあります。パフォーマンスの観点から、実際にSQLを最適化する場合に実行できることは非常に多くあります。そのため、データベースのパフォーマンス要因：設計の誤り、プログラムの設計の誤り、ワークロードの並行性の欠落、負荷分散、クエリ構造、容量計画。それがデータの増加です。そして一言で言えば、SQLは便利ですが、自己最適化されません。

そうは言っても、リックに引き継ぐことができると思います。

Eric Kavanagh：わかりました 、リック、WebEx車の鍵を教えてください。奪って

リック・シャーマン：わかりました 。ロビン、ありがとう。プレゼンテーションの最初から始めたので、私のグラフィックスはまだかなり退屈ですが、私たちはそれで行きます。ですから、ロビンがSQL側で語ったすべてに同意します。しかし、ここで少し集中したいのは、データの需要です。データの需要は、非常に迅速に進みます。その空間で使用されるツールのような供給、またはその空間でのツールの必要性です。

まず、あなたが読むすべての記事には、ビッグデータ、大量のデータ、クラウドからの非構造化データ、想像できるあらゆる場所のビッグデータに関係するものがあります。しかし、データベース市場の成長はSQLによって継続的に行われており、おそらく2015年時点のリレーショナルデータベースは依然としてデータベース市場の95％を占めています。上位3つのリレーショナルベンダーは、その分野で約88％の市場シェアを持っています。ですから、Robinが言ったように、SQLについてはまだ話し続けています。実際、Hadoopプラットフォームを検討している場合でも、データ科学者である息子が常に使用しているHiveとSpark SQLは、確かに人々がデータにアクセスするための主要な方法です。

現在、データベース側では、データベースの使用には2つの広範なカテゴリがあります。 1つは運用データベース管理システム用であるため、エンタープライズリレーションシッププランニング、顧客リレーションシップマニング、世界中のSalesforce ERP、Oracle、EPIC、N4などです。そして、データウェアハウスやその他のビジネスインテリジェンスベースのシステムには、膨大な量のデータがあります。「キャプチャ、保存、またはトランザクションの場所と方法に関係なく、すべてが最終的に分析されるため、データベース、特に市場に出回っているリレーショナルデータベースの使用に大きな需要と増加があります。

現在、需要があり、膨大な量のデータが来ています。そして、私は本当にビッグデータについて話しているのではなく、あらゆる種類の企業でのデータの使用について話しているのです。しかし、それに付随して、供給側から、これらのリソースを管理できる人々のために、まずDBA不足のようなものがあります。労働統計局によれば、2014年から2024年にかけて、DBAの仕事は11％しか成長しません。今ではDBAの役職を持っている人々ですが、それについてはすぐに話します。プラスの年間データ成長スペース。そして、多くのDBAがいます。平均して、同じ研究が平均年齢について語ったことは、他のIT専門家と比較してかなり高いことです。そして、多くの人々が現場を去り、必ずしも引退する必要はありませんが、他の側面に移行したり、管理職になったりします。

今、彼らが去る理由の一部は、DBAの仕事がますます難しくなっているためです。まず、DBAが、さまざまな種類のデータベースだけでなく、さまざまなデータベース自体、物理データベースを管理しています。今ではそれはリレーショナルかもしれませんし、他のデータベース、データベースのタイプかもしれません。しかし、たとえそれがリレーショナルであっても、実際に管理しようとしている1つ、2つ、3つ、4つの異なるベンダーのいずれかを持つことができます。 DBAは通常、データベースまたはアプリケーションの設計後に関与します。ロビンは、データベースまたはアプリケーションの設計方法、SQLの設計方法について話しました。データモデリング、ERモデリング、拡張ERモデリング、ディメンションモデリング、高度なディメンションモデリングなど、通常、アプリケーションプログラマーとアプリケーション開発者は、最終目標を念頭に置いて設計します。データベース構造自体。そのため、私たちには多くの貧弱なデザインがあります。

さて、私は商用エンタープライズアプリケーションベンダーの話ではありません。通常、ERモデルまたは拡張ERモデルがあります。私が話しているのは、すべての企業のアプリケーション開発者によって構築されているビジネスプロセスとアプリケーションがはるかに多いということです。これらは、展開の効率や有効性のために必ずしも設計されたものではありません。また、DBA自体は酷使されており、年中無休で24時間責任を負っています。私は、人々が自分が何をするのか、どのようにそれを行うのかをよく理解していないということで、少しは役立ったと思います。彼ら自身の小さなグループと人々は、「これらのツールはどれもとても使いやすいので、ワークロードにますます多くのデータベースを投入し続けることができる」と考え続けますが、そうではありません。

これは、パートタイムで偶発的なDBAにつながります。 ITチームは小規模であり、必ずしも専任のDBAを雇う余裕はありません。これは、過去10年間でデータベースとデータベースアプリケーションの拡大が爆発的に拡大し続けている中小企業にも当てはまります。しかし、大企業の場合も同様です。通常、長い間、データウェアハウジング、ビジネスインテリジェンス分析を行ってきました。昔、私たちはそれらのプロジェクト専用のDBAを取得していました。専用のDBAを取得することはありません。データベースを設計する責任は私たちにあります。経験がある人であれば、それは問題ありません。しかし、一般的に、DBAはアプリケーション開発者であり、仕事のパートタイムとしてその役割を担うことが多く、正式なトレーニングを受けておらず、最終目標に合わせて設計しています。効率のために設計していません。

また、設計と開発、展開と管理には多くの違いがあります。そのため、プロジェクトに必要なスキルとリソースを取得することをスキップして、そこに小さな貯金箱を備えた「賢明な、愚かなポンド」があります。みんなが「オタクの復even」からだと思って、そこに私の小さな写真。現在、人々が必要とするものに関しては、SQLのデータベースとデータの使用が拡大しています。 DBAの数は限られています。これらの調整と設計、および管理と展開の状況に熟練した専門家です。そして、正式なトレーニングを受けていないパートタイムまたは偶発的なDBAがますます増えています。

それでは、これらのデータベースも調整されていない、または管理されていないという事実の問題になっている他のことは何ですか？まず、多くの人は、データベースシステム自体が自分自身を管理するのに十分なツールを持っていると考えています。現在、ツールの設計と開発はますます簡単になっていますが、これは、展開のための優れた設計、優れた管理、容量計画、監視などを行うこととは異なります。そのため、まず、人々は必要なツールがすべて揃っていると思い込みます。 2番目に、パートタイムまたは偶然のDBAである場合、あなたが知らないことを知りません。

フレーズの一部を忘れてしまったので、多くの場合、彼らはデザインで何を見る必要があるのか、あるいはデータベースを管理または操作しているときに何を見る必要があるのか理解できないだけです。それがあなたの職業ではないなら、あなたはあなたが何をする必要があるかを理解するつもりはありません。 3つ目は、SQLは重要なツールであるため、RobinがSQLについて、またSQLが構築される頻度、または構築される頻度について説明しました。また、BIデータウェアハウジング、データ移行、データエンジニアリングの分野での私のお気に入りの1つは、高価なデータ統合ツールを使用している場合でも、ツールを使用するよりも、SQLコードやストアドプロシージャを作成する傾向があることです高価なBIツールであるため、多くの場合、ストアドプロシージャを実行するためだけに使用します。そのため、データベース設計の理解、SQLの構築の重要性がますます重要になっています。

そして最後に、このサイロアプローチがあります。このアプローチでは、個々の人々に個々のデータベースを調べさせます。彼らは、アプリケーションがどのように動作し、相互にやり取りするのかを見ていません。また、実際にデータベースを使用しているアプリケーションと比較することもよくあります。したがって、データベースで取得するワークロードは、設計上、チューニング上、キャパシティの計画方法を把握する上で非常に重要です。したがって、木から森を見ると、人は雑草の中にいます。、個々のテーブルとデータベースを見て、ワークロード内のこれらのアプリケーションの全体的な相互作用を見ていない。

最後に、人々は彼らが見なければならない重要な領域を見る必要があります。データベースの管理を計画している場合、最初に考えて、アプリケーション中心のパフォーマンスメトリックを開発する必要があります。そのため、このテーブルの構造、特にモデル化の方法だけでなく、どのように使用されるのかを調べる必要がありますか？そのため、サプライチェーン管理の期限が切れるエンタープライズアプリケーションを使用している場合、Webから注文を受け取っている場合、BIを実行している場合-何をしている場合でも、誰がそれを使用しているか、どのようになっているかを調べる必要がありますそれを使用して、データボリュームが何であるか、いつ起こるか。あなたが本当に探しているのは待機時間です。何であれ、すべてのアプリケーションは、それが人であるか、アプリケーションやプロセッサ間のデータ交換だけであるかどうか、何かを達成するのにかかる時間によって判断されるためです。そして、ボトルネックは何ですか？もちろん、問題をデバッグしようとするときは、実際のボトルネックを確認しようとすることがよくあります。必ずしもすべてを調整する方法とは限りませんが、待ち時間をどのように取り除いてパフォーマンスを上げるかおよびスループット–必要なものは何でも。

そして、データベースのデータキャプチャ、トランザクション、変換の側面を分析とともに分離する必要があります。それぞれに異なる設計パターンがあり、それぞれに異なる使用パターンがあり、それぞれを別々に調整する必要があります。そのため、このデータの使用方法、使用時期、使用目的を検討し、パフォーマンスメトリックとその使用に関連して分析する重要な要素を把握する必要があります。ここで、パフォーマンスの監視を検討している場合、データベース操作自体を確認する必要があります。両方のデータ構造、つまりデータベースのインデックス、パーティショニング、その他の物理的側面、さらにはデータベースの構造（ERモデルであろうと次元モデルであろうと構造化されているものであろうと）を見たいと思います。、特にデータキャプチャ分析と発生する変換のさまざまなコンテキストで。

また、RobinがSQL側で述べたように、これらのデータベース全体でこれらのさまざまなアプリケーションによって実行されているSQLを見て、それを調整することが重要です。さらに、アプリケーション全体のワークロード、およびこれらのデータベースとアプリケーションが実行されるインフラストラクチャ環境を調べます。そのため、ネットワーク、サーバー、クラウド（それらが実行されているものは何でも）も、これらのアプリケーションとデータベースがそのコンテキスト内で持つ影響を調べ、これらすべてがデータベースを調整できるという相互作用を持っています。

そして最後に、ツールを見るとき、それに関連する3種類の分析を見ることができます。データベースとアプリケーションのパフォーマンスに関連する、何がどこで何が起こっているのかという記述的な分析を見てみたいと思います。診断分析を実行して、何が起こっているかだけでなく、なぜそれが起こっているのか、ボトルネックはどこにあるのか、問題はどこにあるのか、何がうまくいっているのか、何がうまくいっているのかを把握できるようにしたいですか？しかし、設計のために、またはあなたがする必要のあることのために、それらに対処するために問題領域を分析し、ドリルダウンできること。

そして最後に、最も積極的または積極的なタイプの分析は、実際に何らかの予測分析、予測分析モデリングなどを行うことです。データベースとアプリケーションがこのコンテキストで機能すること、容量を増やした場合、より多くのユーザーを獲得した場合、スループットを増やした場合、何をしていても、何を、どのように、どこに投影できるかがわかりますデータベース、アプリケーションに影響を与えることにより、ボトルネックがどこにあるのか、待機時間が苦しむ可能性のある場所、物事を修正するために何をする必要があるのかを事前に計画し、把握することができます。したがって、これら3つのタイプの分析と同様に、パフォーマンスメトリックを実装し、パフォーマンスを監視できるツールが必要です。それが私の概要です。

エリック・カバナ：了解しました。これは2つの素晴らしいプレゼンテーションです。ちなみに、これをブレット・マナーレに渡して、そこから引き継いでもらいましょう。そして皆さん、良い質問をすることを忘れないでください。すでにいくつかの優れたコンテンツがあります。それを取り去りなさい、バレット。

Bullett Manale：いいですね。ありがとう、エリック。それで、リックが言ったこととロビンが言ったことの多くは、明らかに私は100パーセントに同意します。私はこのスライドを引き上げたと思います、 'それはふさわしいと思うので、80年代に「A-チーム」ファンであるあなたのために、ジョン・ハンニバル・スミスはいつも彼が言っていた「計画がまとまったときにそれが大好きです」と言います。特にSQL Serverについて話しているとき、それは私たちが焦点を当てているところであり、これは今日話し合う製品です。 SQL Diagnostic Manager、それは間違いなくあなたが持っているものの一つです。所有しているデータを活用し、そのデータから意思決定を行える必要があります。場合によっては、意思決定を求めていません。何かがリソースを使い果たすとき、リソースを使い果たすとき、ボトルネックになるとき、そのようなことを伝えるために何かを探しています。

特定のメトリックを監視するだけではありません。そのため、Diagnostic Managerを使用すると、ワークロードに固有の予測と理解の面で非常に役立つことができます。今日はその多くについて説明します。このツールは、データマネージャー、DBA、または演技DBAを対象としているため、リックが言及したことの多くは、演技DBAが真実です。多くの場合、DBAでない場合、SQL環境を管理するときになると、多くの疑問符が付きます。そして、あなたはあなたを助ける何かを探していて、そのプロセスを通してあなたを連れて行きます、そして同様にプロセスであなたを教育します。したがって、これらの決定に使用するツールが、これらの決定が行われた理由についての洞察を提供することは重要であり、「ちょっと、これをやる」だけではありません。

私は演技DBAであるため、最終的には、そのタイトルをバックアップするための実際の専門知識と知識を持つ本格的なDBAになる可能性があります。データベース管理者であることについて話しているとき、DBAにはいくつかの異なる役割があり、所属する組織によっては、それらは場所によって異なりますが、通常は、ストレージ、そのストレージの計画、予測の理解について、常に何らかの形で責任を負うことになります。バックアップが必要なのか、データベース自体が必要なのかが必要です。それを理解し、評価する必要があります。

さらに、必要に応じて物事を理解し、最適化できるようにする必要があります。環境の監視を行う際には、明らかに、物事に基づいて必要に応じて変更を加えることが重要です。環境自体の中で変化します。したがって、予測を行う際には、ユーザー数、アプリケーションの人気、データベースの季節性などをすべて考慮する必要があります。そして、明らかに、それらの決定に関連するために必要なレポートと情報を提供できるという点で、他のことを検討します。多くの場合、比較分析を行うことを意味します。つまり、特定のメトリックを具体的に見て、そのメトリックの値が時間の経過とともにどのようなものであったかを理解できるため、どこに進むかを予測できます。

そのため、Diagnostic Managerの多くのツールにはこれらの機能があり、人々は毎日予測などの機能を実行するためにそれを使用しており、キャパシティプランニングの定義をここに記載しました。そして、それはかなり広範で、実際にはかなり曖昧な定義です。これは、製品の変化する需要を満たすために組織が必要とする生産能力を決定するプロセスであり、結局のところ、それはまさにそれがすべてなのです：何らかの方法で情報を取得し、その情報を取得し、データベースのライフサイクルの進行に合わせて前進するための意思決定を行うことについて。したがって、人々がこれを行う必要がある理由である種類のことは、ほとんどの場合、お金を節約するために明らかに何よりも重要です。企業は、明らかに、それが彼らの主な目標はお金を稼ぎ、お金を節約することです。しかし、それに伴うプロセスでは、ダウンタイムがないことを確認できることも意味します。また、ダウンタイムが発生する可能性を確実に軽減できるため、最初から発生すること、つまり発生するのを待ってから反応しないようにすることができます。

ユーザーの生産性を全体的に高めることができるだけでなく、より多くのビジネスを成し遂げられるようにユーザーを効率化することが明らかに重要です。したがって、これらはDBAまたは予測や能力に関与する人たちのタイプです計画は、それらの決定を下せるように情報を歩き回らなければなりません。そして、全体的に見て、これは明らかにお金の面だけでなく、時間の面でも、他の事柄に使用できるリソースの面でも無駄をなくすのに役立ちます。そのため、その無駄を排除できるため、無駄そのものに関連する機会費用が発生しません。

それでは、DBAである人に固有の質問の種類は何ですか？いつスペースが不足しますか？これは大きな問題です。現在どのくらいのスペースを消費しているだけでなく、トレンドや過去の歴史に基づいて、いつ枯渇するのでしょうか？ SQLの実際のインスタンス、データベース、およびどのサーバーを統合できますか？ VMに一部を追加します。どのデータベースを統合し、どのSQLインスタンスを常駐させるのかという点で何が意味がありますか？これらのタイプの質問はすべて答えられる必要があります。ほとんどの場合、DBAまたは代理DBAであれば、あなたのキャリアの中でそれを統合するからです。多くの場合、継続的にそれを行うことになります。そのため、推測ゲームをプレイするのではなく、それらの決定を迅速に行える必要があります。

ボトルネックと次に発生する可能性のある場所について説明しました。ボトルネックが発生するのを待つのではなく、再び予測することができます。したがって、明らかに、これらのすべてのことは、履歴データに依存しているという意味で、ほとんどの場合、これらの推奨事項を生成できるか、場合によっては自分で決定を策定できるという意味で意味があります。これらの答えを思い付くことができます。しかし、証券などを売っている人のラジオ広告を聞いたとき、それは常に「過去の実績は将来の結果を示すものではない」ということを思い出させてくれます。ここでも同じことが当てはまります。これらの予測と分析が100％正しくない場合があります。しかし、過去に発生したことや既知のことを処理していて、これらの種類の質問の多くを使用して「what if」を実行できる場合は、非常に貴重です推測ゲームをプレイするよりもはるかに多くのことができます。

したがって、これらのタイプの質問は明らかに出てくるので、Diagnostic Managerでこれらの質問の多くを処理する方法、まず、予測機能があり、データベースでもテーブルでもこれを行うことができますドライブまたはボリュームとして。「ねえ、私たちはスペースがいっぱいだ」と言うだけでなく、今から6か月後、2年後、5年後、そのために予算を組むなら、どれくらいのドライブスペースを行くか予算が必要ですか？これらは私が尋ねなければならない質問であり、空中に指を当てて上げ、風が吹く方向を確認するのを待つのではなく、それを行う何らかの方法を使用できるようにする必要があります。多くの場合、残念ながら、これらの決定の多くが行われる方法です。

それに加えて、私のスライドが少し途切れたように見えますが、推奨事項の形で何らかの支援を提供できます。そのため、メトリックでいっぱいのダッシュボードを表示し、「OK、ここにすべてのメトリックとその場所がある」と言うことができるが、それをある程度理解できるそれに基づいて何をすべきか、別の飛躍です。また、場合によっては、人々はDBAの役割について十分な教育を受け、それらの決定を下すことができます。そのため、ツールには、それを支援するメカニズムがいくつかあります。これについては、すぐに説明します。しかし、推奨事項が何であるかを示すことができるだけでなく、その推奨事項が作成されている理由についての洞察を提供し、さらにその上に、場合によっては、実際に自動化するスクリプトを思い付くことができますその問題の修復も理想的です。

ここで次のトピックに進みます。これは、通常、メトリックレベルまでの理解を一般的に言っているだけです。正常なものがわからない場合、正常でないものを伝えることはできません。したがって、それを測定する何らかの方法があることが重要であり、複数のタイプの領域を考慮することができるようにしなければなりません。たとえば、サーバーのさまざまなグループ、動的に行うことができる、アラートの観点から、言い換えれば、深夜、メンテナンス時間帯に、CPUが実行中のすべてのメンテナンスに基づいて80％で実行されると予想しています。そのため、アクティビティがそれほど多くない日中に比べて、それらの時間枠の間にしきい値を高くしたい場合があります。

これらは明らかに環境に影響を与えるものですが、管理対象に適用できるものであり、その環境をより効率的に管理し、管理しやすくするためのものです。もう1つの領域は、明らかに、レポートと情報を全体的に提供して、これらのタイプの「もしも」の質問に答えることができることです。自分の環境に変更を加えたばかりの場合、その影響が何であるかを理解したいので、同じ変更を環境内の他のインスタンスまたは他のデータベースに適用できます。ある程度の情報や弾薬を持って、安心して変更を行えるようにしたいと思います。それが良い変更になることを知っています。そのため、比較レポートを作成したり、SQLのインスタンスをランク付けしたり、データベースを相互にランク付けしたりして、「CPUを最も消費しているのはどれですか」と答えます。待機の条件などは？そのため、この情報の多くはツールでも利用可能になります。

そして最後になりますが、最後になりますが、あらゆる状況に対処できるツールが必要な全体的な能力です。つまり、私が意味するのは、多くの場合、おそらく特定の状況に応じて、DBAが場合によっては監視したいメトリックではないメトリックをプルする必要がある状況に陥るでしょう。したがって、追加のメトリックを追加し、そのまま使用する場合に使用するのと同じ形式と方法でそれらのメトリックを使用できるようにする、拡張可能なツールを持っているたとえば、メトリック。そのため、レポートを実行したり、アラートを出したり、ベースラインを作成したりすることは、私たちが話しているすべてのことを、この予測を行い、目的の答えを得ることができるようにすることの重要な部分でもありますこれらの決定を下すことができ、前進します。

Diagnostic Managerがこれを行う方法により、中央集中型サービス（実行されるサービスのグループ）があり、2000〜2016のインスタンスに対してデータを収集します。そして、私たちが行うことは、そのデータを取得して中央のリポジトリに格納し、そのデータで行うことは、明らかに、さらなる洞察を提供するために多くのことを行うことです。さて、それに加えて、ここにはないことの1つは、予測分析サービスである深夜に実行されるサービスもあります。 DBAまたは代理DBAとして、これらのタイプの推奨事項を作成し、ベースラインの観点から洞察を提供できるように支援します。

だから、私がやりたいこと、そしてこれはアーキテクチャの簡単な例です、ここでの大きなポイントは、あなたが管理しているインスタンスに実際に座っているエージェントやサービスがないということです。しかし、私がやりたいのは、実際にここのアプリケーションに連れて行って、簡単なデモを提供することです。そして、私も外に出て、それを実現させます。それで、私に知らせてください、エリック、大丈夫だとわかりますか？

エリック・カバナ：今わかった、ええ。

Bullett Manale：わかりました。それで、私が話したこれらの異なる部分のいくつかを紹介します。そして本質的には、ここの行に沿った種類のことから始めましょう、あなたがする必要があることです、またはここで将来のある時点であり、それについていくつかの洞察を与えます。そして、これは、起こっていることを本当に予測することができます-または、動的に予測することを言うべきです-。現在、レポートの場合、ツールにあるものの1つは3つの異なる予測レポートです。また、たとえばデータベースの予測の場合、ある期間にわたってデータベースのサイズを予測できる状況でおそらく何をするのか、その例をいくつか紹介します。そこで、監査データベースを使用します。これはかなりI / O集約型です。大量のデータが送られます。ここでこれを行い、ここでヘルスケアデータベースを選択します。

しかし、ポイントは、このスペースが何であるかだけを見ているのではなく、「見て、去年の価値のあるデータを取りましょう」と言えます。実際には1年分のデータはありません。約2か月分のデータがありますが、ここでは月のサンプルレートを選択しているので、これで予測または予測することができます。サンプルレートが月に設定されているため（次の36単位）、つまり単位は1か月です。その後、レポートを実行して、基本的に将来の成長を予測する場所を示します。 3つのデータベース。また、3つの異なるデータベース間で、特にそれらが歴史的に消費しているデータの量に応じて、さまざまな程度の差または差異があることがわかります。

ここでデータポイントが履歴データを表していることを確認できます。その後、ラインが予測を提供し、それを裏付ける数字も表示されます。そのため、テーブルレベルでそれを行うことができます。マウントレベルを含め、ドライブがどれだけ大きくなるかを予測できるドライブレベルでもできます。これと同じタイプの情報を予測することはできますが、サンプルレートに応じて、予測するデータの数と場所を決定できます。また、予測タイプにはさまざまなタイプがあります。そのため、予測を行うときに多くのオプションと柔軟性が得られます。さて、これは私たちがやることの1つです。実際に特定の日付を指定し、「おい、この日付に、データの増加が予想される場所です」と言うことができます。それに加えて、営業時間外に実行する分析の一部と、実行時のサービスに関連する他の洞察を提供します。それが行うことのいくつかは、過去に何かが起こったときの履歴に基づいて、起こりそうなことを予測しようとすることです。

実際、ここで見ることができるのは、過去に再び起こったことに基づいて、夜中に問題が発生する可能性についての予測を提供する予測です。したがって、これは明らかに素晴らしいことです。特に、私がDBAでない場合は、これらのことを確認できますが、DBAでない場合は、この分析タブがさらに優れています。ですから、これがツールに登場する前に、製品を人に見せて、「すごい、これらすべての数字を見て、すべてを見て、どうしたらいいのかわからない」と言いました（笑）「その結果として」です。そして、ここにあるものは、パフォーマンスを支援するために行動を起こすなら、さらには行動を起こすなら、あなたが理解できるより良い方法です私の環境の健全性を支援し、それらの推奨事項を提供するためのランク付けされた方法、およびそれらの推奨事項についてさらに学ぶための情報の有用なヒントを持つことができ、実際にそのデータの一部への外部リンクさえ持っていますこれらの推奨事項が作成された理由を教えてください。

そして、多くの場合、これらの問題の修正を自動化するスクリプトを提供できることは、私が言ったように。ここで、この分析でここで行っていることの一部です。このインスタンスのプロパティを構成するために、分析構成セクションに移動するときに表示します。ここにリストされ、その一部として、インデックスの最適化とクエリの最適化があります。そのため、メトリック自体とそのようなものだけでなく、ワークロードとインデックスのようなものも評価しています。ここでのケースでは、実際にいくつかの追加の仮想インデックス分析を行います。したがって、これは私が望んでいない状況の1つであり、多くの場合、必要のない場合はインデックスを追加しません。しかし、ある時点である種の転換点があります。私は次のように言います。「テーブルは、ワークロード内で実行されているクエリのサイズまたは種類に近づいています。 But it wouldn't have made sense maybe six weeks prior.” So this allowing you to dynamically get that insight as to things that will likely, like I said, improve performance based off of what's happening in the environment, what's happening within the workloads, and doing those kinds of things.

And so you get a lot of good information here, as well as the ability to optimize these things automatically. So, that's another area where we would be able to help out, in terms of what we call predictive analysis. Now, in addition to that, I should say, we also have other areas that I think just generally lend themselves to helping you make decisions. And when we talk about making decisions, once again, being able to look at historical data, provide some insight to get us to where we need to be to improve that performance.

Now, one of the things we can do is we have a baseline visualizer which allows us to selectively choose whichever metric we would want – and let me find a decent one here – I'm going to SQL CPU usage, but the point is you can go back over however many weeks to paint these pictures for you to see when your outliers are, to see generally speaking where that value falls within the periods of time that we've been collecting data. And then, in addition to that you'll also notice that when we go out to the actual instance itself, we have the ability to configure our baselines. And the baselines are a really important part about being able to automate things as well as being able to be notified of things. And the challenge, as most DBAs would tell you, is that your environment is not always running the same, throughout the course of the day, versus the evening and whatnot as we mentioned earlier in the example with the maintenance periods of time, when we have high levels of CPU or whatever that might be happening.

So, in the case here, with these actual baselines, we can have multiple baselines, so I might have a baseline for example, that's during my maintenance hours. But I could just as easy create a baseline for my production hours. And the point of doing that is when we go into an instance of SQL and we actually have these multiple baselines, then we would be able to anticipate and be able to perform some type of automation, some type of remediation or just alerting in general, differently specific to those windows of time. So, one of the things you'll see here, is these baselines that we generate are using the historical data to provide that analysis, but more importantly, I can change these thresholds statically, but I can also automate these dynamically as well. So, as the maintenance window, or I should say the maintenance baseline window comes up, these thresholds would automatically switch specific to the loads that I'm encountering during that window of time, versus maybe in the middle of the day when my loads are not as much, when the workloads are not as impactful.

So, that's something else to keep in mind, in terms of the baseline. Obviously these are going to be really helpful for you, in terms of also understanding what is normal and being able to also understand, engage when you're going to be also running out of resources. Now, the other kind of thing that we have in the tool, that's going to help you make decisions, in addition the baselining and being able to set up alerts around those baselines and the thresholds that you create dynamically, is like I said earlier, just being able to run a whole myriad of reports that help me answer questions about what's going on.

ですから、例として、管理しているインスタンスが150個ある場合-私の場合はそうではないので、ここでふりをする必要があります-しかし、すべての実稼働インスタンスがあり、どこにあるかを理解する必要がある場合注意が必要な領域、つまり、パフォーマンスを向上させるために何らかのタイプの管理を実行する時間が限られている場合は、重要な領域に焦点を当てたいと思います。ですから、そうは言っても、「その環境に基づいて、インスタンスを相互にランク付けし、競合パイプでランク付けしてください」と言うことができます。したがって、ディスク使用量、メモリ使用量、待機時間、応答時間であるかどうかに関係なく、それらのインスタンスを相互に相関させることができます（または、ランクを言う必要があります）。明らかに、各リストの一番上にあるインスタンスは、同じインスタンスである場合、おそらくリストの一番上にあるので、おそらく私が本当に集中したいものです。

そのため、インスタンスレベルでの環境のランク付けに関して役立つツールには、多くのレポートがあります。データベースレベルでもこれを行うことができます。ここでは、データベースを相互にランク付けできます。設定可能なしきい値と領域に特に、必要に応じてここでワイルドカードを設定して特定のデータベースのみに焦点を当てることもできますが、ポイントは同じ方法でデータベースを比較できることです。また、他のタイプの比較分析とこのツールの大きな分析に関しては、ベースライン分析があります。そのため、ここでサービスビューまでスクロールすると、ベースライン統計レポートがあることがわかります。このレポートは、メトリック値が何であるかを理解するのに役立つことは明らかです。特定のインスタンスについては、これらのメトリックのいずれかについて、実際にこれらのメトリックのベースラインを見ることができます。

だから、それが何であれ、パーセントとして、または私が外に出て、「この30日間でブレークアウトのベースラインを見てみましょう」と言っても、その場合、ベースラインに対する実際の値を表示し、明らかに、その情報を使用していくつかの決定を下すことができるので、これはそのような状況の1つであり、どの質問であるか、あなたがその時に尋ねていることに依存します。しかし、これは明らかにこれらの質問の多くに役立つでしょう。すべてを実行するレポートが1つあり、それを押すとボタンを押すだけの簡単なレポートのように、すべての「what if」質問に答えることができます。しかし、現実には、これらのプルダウンから選択できる多くの属性とオプションがあり、あなたが探している「what if」タイプの質問を定式化することができます。

そのため、これらのレポートの多くは、これらのタイプの質問に答えることができるようになっています。したがって、これらのレポートに加えて、前述したように、ツールで既に示したすべてのものに、新しいメトリックを組み込み、管理し、作成することもできる柔軟性があることも非常に重要ですカウンタ、またはポーリング間隔に組み込まれたSQLクエリは、これらの質問に答えるのに役立ちます。おそらく、監視することを予期していなかったので、それらを追加できます。そして、あなたは私があなたに示したのと同じことをすべて行うことができます：ベースライン、レポートを実行し、そのメトリックからレポートを作成し、私があなたに示しているこれらの異なるタイプの多くに答えて実行することができますここに。

さて、それに加えて、明らかに最近かなり明らかになったことの1つは、まず、全員がVMを反転または切り替えることでした。そして今、クラウドに向かう多くの人々がいます。そして、これらのタイプの事柄についてはたくさんの質問が出てきています。クラウドに移行することは理にかなっていますか？クラウドに移行することで費用を節約できますか？これらのことを共有リソースマシンのVMに置くとしたら、どれくらいのお金を節約できますか？これらのタイプの質問は、明らかに同様に出てくるでしょう。そのため、Diagnostic Managerを使用すると、VMwareとHyper-Vの両方の仮想化環境を追加および取得できます。クラウド上にあるインスタンスを追加することもできます。たとえば、Azure DBなどの環境やRDSでも、それらの環境からメトリックを取得できます。

そのため、多くの柔軟性があり、人々が向かおうとしている他のタイプの環境に関連しているため、これらの質問に答えることができます。そして、この問題についてはまだ多くの質問があります。これらの環境を統合する人々を見ると、それらの質問にも答えられる必要があります。したがって、このトピックに関連する診断マネージャーの概要はかなり良いと思います。ビジネスインテリジェンスの主題が浮上し、今日は説明していなかったビジネスインテリジェンスのツールもありますが、これらの質問に答えるという観点からも、あなたに関連する洞察を提供してくれます。キューブおよびそれらのさまざまなタイプのすべても同様に。しかし、うまくいけば、少なくともこの製品が良い計画を立てることができるという点で、これが良い概要であったことを願っています。

エリック・カバナフ：よし、いいもの。ええ、リックがまだそこにいるなら、私はそれをリックに投げます。リック、あなたから何か質問はありますか？

リック・シャーマン：はい、最初に、これは素晴らしいです、私はそれが好きです。 VMとクラウドに拡張することが特に気に入っています。多くのアプリ開発者は、クラウドにある場合は調整する必要がないと考えています。そう-

バレット・マナーレ：そうですね 、まだ支払わなければなりませんよね？人々がクラウドに投入しているものは何でも支払わなければならないので、実行が不十分な場合、または多くのCPUサイクルを引き起こしている場合は、支払わなければならないより多くのお金があるので、そうではありません絶対にこのようなものを測定する必要があります。

Rick Sherman：ええ、クラウドで多くの貧弱なデザインを見てきました。この製品も使用しますか？BI製品について言及し、相互にやり取りする他の製品がたくさんあることは知っていますが、このツールでSQLパフォーマンス、個々のクエリを調べ始めますか？それとも、そのために使用される他のツールでしょうか？

Bullett Manale：いいえ、これは絶対にそうです。それは私がカバーしなかったものの1つであり、私が意図したことは、そのクエリ部分です。クエリのパフォーマンスを識別するためのさまざまな方法があります。具体的には、このビューで見られるような待機に関係するのか、クエリ全体のリソース消費に関係するのか、クエリを分析する方法は多数ありますパフォーマンス。それは期間、CPU、I / Oであるかどうかであり、もう一度、ワークロード自体を調べて洞察を提供することもできます。分析セクションで推奨事項を提供できます。また、クエリ自体に関する情報を提供するWebベースのバージョンもあります。そのため、不足しているインデックスに関する推奨事項と、実行計画とそのようなすべてのものを表示する機能を得ることができます。また、機能でもあります。したがって、絶対に、クエリを日曜日まで7つの方法で診断し（笑）、リソース消費、待機、継続時間など、実行回数に関する洞察を提供することができます。

リック・シャーマン：わかりました。そして、このすべての監視でインスタンス自体の負荷はどうなりますか？

Bullett Manale：いい質問ですね。その質問に答える際の課題は、それが依存するかどうかであり、それは他のものとまったく同じです。私たちのツールが提供するものの多くは、柔軟性を提供し、その柔軟性の一部は、収集するものと収集しないものをあなたに伝えることです。したがって、たとえば、クエリ自体では、待機情報を収集する必要はありません。実行時間を超えるクエリに関連する情報を収集できます。その例として、構成クエリモニターに移動し、「この値をゼロに変更しましょう」と言った場合、実際には、実行するすべてのクエリをツールが収集するだけで、実際にはそうではありませんそこにある理由の精神ですが、一般的に言えば、すべてのクエリのデータの完全なサンプルを提供したい場合、私はそれを行うことができます。

したがって、設定は、一般的に言ってすぐに使用できるものと非常に相対的です。オーバーヘッドは約1〜3パーセントですが、他にも適用される条件があります。また、環境で実行されているポートクエリの量にも依存します。また、これらのクエリの収集方法と、SQLのバージョンにも依存します。そのため、たとえばSQL Server 2005では、拡張イベントからプルすることはできませんが、トレースからプルすることはできます。そのため、そのデータを収集する方法に関しては少し異なりますが、それは、私が言ったように、2004年頃からこの製品を使用していたと思います。久しぶりで、何千人もの顧客がいるので、最後にしたいことは、パフォーマンスの問題を引き起こすパフォーマンス監視ツールを用意することです（笑）。そのため、可能な限りそれを避けようとしますが、一般的に言えば、1〜3％程度が目安です。

リック・シャーマン： OK、それはかなり低いので、それはすごいことです。

エリック・カバナ：いいですね。ロビン、あなたからの質問は？

Robin Bloor：申し訳ありませんが、ミュート状態でした。複数のデータベース機能があり、複数のデータベースを見ることができるため、より大きなリソースベースがさまざまな仮想マシンなどに分割される可能性があることを知ることができます。私は人々が実際にそれをどのように使用するかに興味があります。顧客がそれで何をしているかに興味があります。確かに、それは私には見えるので、確かに、データベースをいじっていたとき、手元にはなかったものです。そして、特定の時点で意味のある方法で1つのインスタンスのみを検討します。それで、人々はこれをどのように使用しますか？

Bullett Manale：一般的に言って、あなたは一般的にツールそのものについて話しているのですか？彼らはそれをどのように使用していますか？つまり、一般的に、環境の存在の中心点を持つことができるということです。安心して、画面を見つめて緑色を見ると、すべてが良いことを知っています。それは問題が発生したときであり、明らかにDBAの観点から見た場合のほとんどのケースです。多くの場合、それらの問題はコンソールの前で発生するため、問題が発生するとすぐに通知できます。しかし、それに加えて、問題がいつ発生するかを理解でき、それが発生した理由に関して何らかのコンテキストを提供している情報の中心に到達することができます。そして、それが最大の部分だと思います：事後対応するのではなく、積極的に対応することです。

私が話すDBAのほとんどは-そして、それらのかなりの割合だとは知りません-残念ながら、まだ反応型の環境にいます。彼らは問題があることを伝えるために消費者が彼らに近づくのを待ちます。そのため、多くの人々がそこから脱出しようとしているのを見て、それがこのツールが好きな理由の大部分は、彼らが積極的になるのに役立つだけでなく、何が起こっているのかについての洞察を提供するからだと思います、何が問題なのか、しかし多くの場合、少なくとも私たちが見つけたこと-そしておそらくそれは私たちにそれを告げるDBAだけかもしれません-しかしDBAは、アプリケーションを書いたアプリケーション開発者であっても、それは常に彼らの問題であるという認識ですそれは適切に記述していませんでした。彼らは責任を負おうとしているのです。「そのアプリケーションをシステムやサーバーに持ち込んでいるので、パフォーマンスが悪いときは誰もがDBAを指しています」「ねえ、それはあなたのせいです。」

したがって、このツールは、多くの場合、DBAが「ねえ、これは問題のある場所であり、私ではない」と主張するという点で役立つために使用される予定です（笑）クエリを変更するかどうかにかかわらず、これを改善します。場合によっては責任の面でバケツに入りますが、少なくともそれを理解し、それを理解できるツールがあれば、それをタイムリーに行うことが明らかに理想的なアプローチです。

Robin Bloor：ええ、私がよく知っているサイトのほとんどですが、私がそこに行ってからしばらく経ちましたが、さまざまなマルチデータベースサイトを見ていますが、ほとんどの場合、私が見つけたのは少数のデータベースに焦点を当てたDBA。そして、それらはデータベースであり、もしダウンした場合、それはビジネスにとって本当に大きな問題などになるでしょう。そして他のものは、彼らは時々統計を収集しているだけであり、スペースを使い果たしていないことを確認するために、彼らは決してそれらを見ません。そして、あなたがデモをしている間、私はこれを見ていましたが、データの成長があるため、あまり気にしていないデータベースにこのようなものを提供するだけで、何らかの形でうまく考えました、アプリケーションの成長も時々あります。あなたは非常に劇的な方法でDBAカバレッジを拡大しています。それが問題なのです。このようなツールを使用すると、企業ネットワーク内のすべてのデータベースにDBAサービスをほとんど提供できるようになるのでしょうか。

Bullett Manale：確かに、挑戦は、あなたがかなり雄弁に言ったように、DBAが気にしているデータベースがあり、それからあまり気にしないデータベースもあるということです。そして、この特定の製品の方法、ライセンスの方法はインスタンスごとです。だから、あなたが言うように、人々が「ねえ、これはこのツールで管理したいほど重要なインスタンスではない」と判断するときの閾値があると思います。 SQLの重要度の低いインスタンスに対応していると思います。それらの1つはインベントリマネージャーのようなもので、インスタンスに対して軽いヘルスチェックを行いますが、それに加えてディスカバリを行うため、オンラインになった新しいインスタンスを特定し、その時点から、 DBAとして、「OK、ここにSQLの新しいインスタンスがあります。今はExpressですか？それはおそらく私が自問したい質問ですが、第二に、そのインスタンスは私にとってどれほど重要ですか？それがそれほど重要ではない場合、このツールを外に出して実行するかもしれません、ジェネリック、私がDBAとして気にしているものの要素タイプであるという意味でジェネリックヘルスチェックと呼ぶもの：ドライブがいっぱいですか？？サーバーは問題に対応していますか？主なものですよね？

診断マネージャーでは、先ほど紹介したツールでしたが、クエリレベルに到達し、インデックスの推奨事項に到達し、実行計画やその他の優れた機能を確認します。誰が何を所有しているのか、私が何を所有しているのか、誰がそれを担当しているのか？どのサービスパックとホットフィックスがありますか？そして、私のサーバーは、SQLの健全なインスタンスであると考えるものの主な要素で実行されていますか？それで、あなたの質問に答えるために、少しミックスがあります。このツールを見ている人がいるとき、彼らは通常、より重要なインスタンスのセットを見ています。とはいえ、所有しているすべてのインスタンスを購入して管理する人々がいるので、それは依存します。しかし、全体として、これらのインスタンスを管理するためのこのようなツールを使用するには、環境が十分に重要であると考えている人々のしきい値があることは間違いありません。

Robin Bloor：わかりました、エリックに渡す前にもう1つ質問があります。業界を見るだけで得られる印象は、データベースにはまだ寿命があるが、すべてのデータがこれらすべてのデータレイクなどに注がれているということです。それは本当に誇大広告であり、誇大広告は現実を決して反映しないので、あなたがそこにどのような現実を感じているのか興味がありますか？組織内の重要なデータベースは、従来のデータの増加を経験していますか？私はかつて年に10パーセントと考えていましたか？それともそれ以上に成長していますか？ビッグデータがこれらのデータベースを膨らませていますか？あなたが見る写真は何ですか？

Bullett Manale：他のテクノロジーが利用可能になったときに、いくつかのデータがより理にかなっている他のセグメントに移動しているのを目にすることが多いと思います。最近では、いくつかの大きなデータがあります。しかし、これらのデータベースは、多くの場合一般化するのは難しいと思います。なぜなら、誰もが少し違うからです。ただし、一般的に言えば、ある程度の相違が見られます。私が言ったように、多くの場合、人々は弾性モデルに移行しています。なぜなら、彼らは他の分野ではあまりリソースを増やしたくないからです。一部の人々はビッグデータに移行しています。しかし、一般的に言えば、私が話しているすべての人々が伝統的なデータベースを持ち、SQL Server環境でこれを使用しているため、知覚を感じるのは難しいです。

そうは言っても、SQL自体に関して言えば、市場シェアを獲得しつつあると私は確信しています。そして、SQLバージョンがより高度になるにつれて、より手頃な価格であり、明らかにそうであるように、Oracleのような他の場所からまだSQLに向かっている人々がたくさんいると思います。暗号化やSQLを環境またはデータベースプラットフォームにする他のすべての機能に関して、SQLを使用しています。これは明らかにミッションクリティカルであると思います。それで、私たちもそれを見ていると思います。あなたがシフトを見ているところで、それはまだ起こっています。つまり、それは10年前に起こっていましたが、それはまだ、環境が成長し、市場シェアが成長しているSQL Serverの観点から起こっていると思います。

Robin Bloor：わかりました、エリック、聴衆に質問があると思いますか？

エリック・カバナ：ええ、簡単なものを1つ投げます。実際、それはかなり良い質問です。出席者の一人が尋ねています。このツールは、クエリを高速化するためにテーブルにインデックスが必要かどうかを教えてくれますか？もしそうなら、例を示すことができますか？

Bullett Manale：ええ、だから、具体的にインデックスを追加するためのものがあるかどうかはわかりませんが、ここでわかるように、断片化の推奨事項があります。また、私はちょうど私たちが持っていたと信じており、これはWebベースのバージョンを提供する診断マネージャーの一部であり、インデックスが不足していることを教えてくれます。そして、それらの推奨事項を表示できます。その情報にインデックスを付けることにより、その潜在的な利点がわかります。言及すべきもう1つのことは、推奨事項を実行すると、これらの多くについて、スクリプトが作成されることです。これは良い例ではありませんが、インデックス（重複インデックスまたはインデックスの追加）がパフォーマンスを改善する状況を確認できます。前述のように、多くのことを行います。仮説的なインデックス分析を通じて。したがって、ワークロードを理解し、それを推奨事項に適用できるという点で、本当に役立ちます。

エリック・カバナ：それは素晴らしいことです、そしてこれはここでの最後のコメントに良いセグエを与えてくれます。ロビンと私、そしてリックも、長年にわたって聞いてきました。セルフチューニングデータベースについての話があります。それは自己調整データベースです！私に言えることは、彼らを信じないことです。

Bullett Manale：誇大広告を信じないでください。

エリック・カバナ：動的に行われる小さなことがいくつかあるかもしれませんが、それでも、それをチェックして、望まないことをしていないことを確認したいかもしれません。したがって、かなり長い間、データベースレベルで何が起こっているのかを理解するためにこのようなツールが必要になります。ロビンが言ったように、データレイクは魅力的な概念ですが、ネス湖の怪物はいつでもそこにいます。ですから、現実の世界には多くのデータベーステクノロジがあります。このようなものを見て、それを合成するには、DBAが必要です。このことを機能させるには、何をしているかを知る必要があります。しかし、自分が何をしているかを知るための情報を提供するツールが必要です。つまり、最終的には、DBAがうまくやっていくということです。

Bullett ManaleとIDERAの友人に感謝します。そしてもちろん、リック・シャーマンとロビン・ブロア。これらのWebキャストはすべてアーカイブされていますので、insideanalysis.comまたはパートナーサイトwww.techopedia.comにオンラインでアクセスして、詳細を確認してください。

それで、皆さん、お別れを申し上げます。もう一度ありがとう、次回もお話しします。気を付けて。バイバイ。