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

ビデオ: 【時間術大全①】スマホ中毒から解放されて時間を取り戻す（Make Time）

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

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

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

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

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

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

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

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

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

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

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

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

エリック・カバナ： わかりました、リック、WebEx車の鍵を教えてください。奪って

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

まず、あなたが読むすべての記事には、ビッグデータ、大量のデータ、クラウドからの非構造化データ、想像できるあらゆる場所のビッグデータに関係するものがあります。しかし、データベース市場の成長はSQLによって継続的に行われており、おそらく2015年時点のリレーショナルデータベースは依然としてデータベース市場の95％を占めています。上位3つのリレーショナルベンダーは、その分野で約88％の市場シェアを持っています。ですから、ロビンが言ったように、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は間違いなくその1つですあなたは〜を持つ必要があります;所有しているデータを活用し、そのデータから決定を下せる必要があります。場合によっては、決定を求めていないことがあります。何かがリソースを使い果たすとき、あなたがリソースを使い果たすとき、ボトルネックになるとき、そのようなことを伝える何かを探しています。

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

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

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

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

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

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

ボトルネックと、それらが次に発生する場所について話しました。ボトルネックが発生するのを待つのではなく、もう一度予測することができます。したがって、明らかにこれらのすべてのことは、ほとんどの場合、履歴データに依存しているという意味で意味があります。ほとんどの場合、これらの推奨事項を生成したり、場合によっては自分で決定を立てたり、これらの答えを考え出します。しかし、証券などを売っている人のラジオ広告を聞くと、常に「過去の実績は将来の結果を示すものではない」などのことを思い出します。ここでも同じことが当てはまります。これらの予測と分析が100％正しくない場合があります。しかし、あなたが過去に起こった事柄や既知の事柄に対処し、これらのタイプの質問の多くで「もしも」を受け入れて実行できるなら、あなたは出くわすことは非常に価値があり、推測ゲームをプレイするよりもはるかに多くを取得します。

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

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

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

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

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

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

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

エリック・カバナ： そうだね

バレット・マナーレ： わかりましたので、私は私が話したこれらのさまざまな部分のいくつかを紹介します。そして基本的には、ここにあるようなものから始めましょう。あなたがしなければならないこと、またはここにあるのは未来のある時点であり、それについての洞察を与えてくれるものです。そして、これは起こっていることを本当に予測することができます-または動的に予測することを言うべきです-。現在、レポートの場合、ツールにあるものの1つは3つの異なる予測レポートです。また、たとえばデータベースの予測の場合、ある期間にわたってデータベースのサイズを予測できる状況でおそらく何をするのか、その例をいくつか示します。それで、私は監査データベースを使用します。これはかなりI / O集中型です。大量のデータが送られてきました。ここでこれを取得し、見てみましょう。そしてここでヘルスケアデータベースを選択します。

しかし、ポイントは、私はこのスペースが何であるかを見るだけではなく、「見て、最後の数年分のデータを取りましょう」と言うことができます-そして、私はここで少しfiるつもりです、私は本当に何年も持っていません約2か月分のデータがありますが、サンプルレートをここで選択しているため、サンプルレートが月に設定されているため、この場合は次の36ユニットを予測または予測できるようになります。 –それは1か月、1か月です–そして、これら3つのデータベースについて、将来の成長を予測する場所を基本的に示すレポートを実行することができます。また、3つの異なるデータベース間で、特にそれらが過去に消費していたデータの量に応じて、さまざまな程度の差異または分散があることがわかります。

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

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

そして、多くの場合、これらの問題の修正を自動化するスクリプトを提供できることは、私が言ったように。さて、この分析でここで行っていたことの一部-そして、このインスタンスのプロパティを構成するために行って、分析構成セクションに行くときを示します-ここにリストされている多くの異なるカテゴリがあり、その一部として、インデックスの最適化とクエリの最適化があります。そのため、メトリック自体とそのようなものだけでなく、ワークロードとインデックスのようなものも評価していました。ここでのケースでは、実際にいくつかの追加の仮想インデックス分析を実行します。そのため、私はしたくない状況の1つであり、多くの場合、必要のない場合はインデックスを追加しません。しかし、ある時点で、ある種の転換点があります。「まあ、テーブルはワークロード内で実行されているクエリのサイズまたは種類に達しつつあるので、インデックスを追加する意味があります。だから、これは、先ほど言ったように、環境で起こっていること、ワークロードで起こっていることに基づいてパフォーマンスを向上させる可能性があるものについて、その洞察を動的に得ることを可能にします。そのようなことをする。

そのため、ここで多くの有益な情報を取得でき、これらの情報を自動的に最適化する機能も得られます。つまり、予測分析と呼ばれるものに関して、私たちが支援できる別の領域です。さて、それに加えて、私は他の分野も持っていると思いますが、一般的にあなたが決断を下すのに役立つと思います。そして、意思決定について話すとき、もう一度、履歴データを見ることができるので、パフォーマンスを改善するために必要な場所に到達するための洞察を提供します。

さて、できることの1つは、必要なメトリックを選択して選択できるベースラインビジュアライザーです。ここで適切なメトリックを見つけます。SQLCPUの使用率についてですが、要点はただし、何週間も前にこれらの画像をペイントして、外れ値がいつ表示されるかを確認し、データが収集されている期間内でその値がどこにあるかを確認します。そして、それに加えて、実際のインスタンス自体に移動すると、ベースラインを構成できることにも気付くでしょう。そして、ベースラインは、物事を自動化できることと物事を通知できることに関して、本当に重要な部分です。そして、ほとんどのDBAが言うように、課題は、メンテナンス期間での例で前に述べたように、夕方やその他ではなく、1日を通して常に同じ環境を実行しているわけではないということです。高レベルのCPUまたは発生する可能性のあるものがあります。

したがって、ここでのケースでは、これらの実際のベースラインを使用して、複数のベースラインを作成できます。たとえば、メンテナンス時間中にベースラインを作成する場合があります。しかし、実稼働時間のベースラインを簡単に作成できました。そして、それを行うポイントは、SQLのインスタンスに入り、実際にこれらの複数のベースラインを持っているとき、ある種の自動化、ある種の修復、または一般的なアラートを予測して実行できるようになることです。これらの時間枠に固有の方法が異なります。したがって、ここで表示されるものの1つは、生成するこれらのベースラインが履歴データを使用してその分析を提供することですが、さらに重要なことは、これらのしきい値を静的に変更できますが、動的にこれらを自動化することもできますしたがって、メンテナンスウィンドウ、またはメンテナンスベースラインウィンドウが表示されると、これらのしきい値は、その時間の間に発生した負荷に応じて自動的に切り替わります。多くの場合、ワークロードがそれほど影響を与えません。

したがって、ベースラインに関しては、他に留意する必要があります。明らかに、これらはあなたにとって本当に役に立ちます。また、普通のことを理解し、また理解することができるという点でも、あなたがリソースを使い果たしようとしているときに関与します。さて、ツールにあるもう1つの種類は、意思決定に役立つことです。さらに、ベースラインと動的に作成するしきい値に基づいてベースラインとアラートを設定できることは、前述のとおりです。何が起こっているのかという質問に答えるのに役立つ、無数のレポートを実行することができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ロビン・ブロア： わかりました、エリック、聴衆に質問があると思いますか？

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

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

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

バレット・マナーレ： 誇大広告を信じないでください。

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

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

それで、皆さん、お別れを申し上げます。次回もよろしくお願いします。気を付けて。バイバイ。