効果的な分析の鍵：高速に返されるクエリ

2024

Techopediaスタッフ、2016年11月30日

持ち帰り：ホストのエリック・カバナとロビン・ブロア博士、デズ・ブランフィールド、IDERAのバレット・マナーレは、クエリとその効率がどのように広範囲に影響するかについて話し合います。

あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。

エリック・カバナ：ご列席の皆様 、こんにちは。おかえりなさい。それは水曜日の東部時間の4時であり、最近では、Hot Technologiesの時間です！はい、確かに。今日はクールなものについて話している。もちろん、私はあなたのホスト、エリック・カバナです。今日のショーのタイトルは、「効果的な分析の鍵：迅速に戻るクエリ」です。そうですね、皆さん、私たちは皆、早く望んでいます。誰が速く欲しくないのですか？本当にあなたについてのスライドがあり、私については十分です。 Twitterで@eric_kavanaghを見つけてください。私はそこであなたとつながり、ソーシャルメディアで会話できることを嬉しく思います。楽しいこともありますが、政治については話さないでください。

今年の暑い。今年はさまざまな分析の問題について話していましたが、今日のトピックの1つは、仕事を成し遂げるための中心的なものです。「データと会話をする」という表現を誰かが最初に耳にしたのはおそらく5〜6年前だったことを覚えています。少し安っぽく聞こえるかもしれませんが、重要なのは、データ、クエリをすばやく修正したり、新しいクエリを送信したり、回答をすばやく取得したりできない場合は、データとの会話がなく、分析プロセス全体が切り捨てられます。それは良いことではありません。

データと会話するとき、それはどういう意味なのかを行き来できるということです。私の意見では、それは洞察を見つけるときです。初めて完璧なクエリを作成することはめったにないからです。あなたが分析のモーツァルトでないなら-そして私はその人がそこにいると確信しています-あなたは、あなたが探しているものを微調整するために、修正、いくつかの次元の追加に時間を費やす必要があります。

繰り返しになりますが、これらは分析の世界で扱っている途方もないほど扱いにくい環境ではありません。非常に扱いにくい環境と非常に複雑で多次元の環境を扱っています。したがって、今日のウェブキャストの全体的なアイデアは、データとのこのような反復的な相互作用を可能にする方法について話すことです。

3人のプレゼンターがいます。もちろん、ブリーフィングルームとは対照的に、Hot Technologiesには2人のアナリストがいます。それぞれが最初にテイクを行い、次にゲストが来てプレゼンテーションを行います。そして、あなた、私たちの聴衆は、その中で大きな役割を果たすことができます。恥ずかしがらないでください。ご質問はいつでもお送りください。可能な場合はQ&Aパネルを使用してください。それ以外の場合はチャットパネルで問題ありません。私はショーの間に両方を監視しようとします。そして、これらを記録しているので、何かを見逃したり、同僚と共有したい場合は、後で戻ってきてください。 Techopedia.comおよびInsideAnalysis.comにも投稿しています。

そしてそれで、私は賢い人々を連れて行きます。ロビン・ブロア博士に引き渡します。彼に鍵を渡して、プレゼンターを変えてください。ロビン、取り去ってください。

Robin Bloor：なるほど。そのイントロをありがとう。約1か月半前、実際にDBAである開発者とチャットをしました。彼は実際にはDBAではありません。特定の会社のDBAであり、実際にクエリを実行できるのは彼だけです。しかし、彼は本当にうんざりしています。なぜなら、彼は実際、かなり賢い開発者だからです。それで彼は去った。

とにかく、彼らは毎月数日彼らのためにやらなければなりません。彼らは彼の代わりになる人を見つけることができず、データベースが何をするのか、それをどのように調整するのか手掛かりを持っていなかったからですそして、私はそれについてちょっと考えていました、そして、あなたが知っているように、彼らは本当にIT部門を持っていませんでしたが、この男は彼らのためにサポートをしていた。実際、彼がほとんどの時間をやっていたのはDBAの仕事でした。

洗練されたデータベース（Oracle、SQL Server、DB2、それらのすべての大きな高価なデータベース）の場合、データベースのチューニングは困難な仕事です。それは安全な仕事でもあります。そして、本当に、これを言う理由は、それが変化する風景だからです。これについて少し説明します。リレーショナルデータベース-通常、全体像は、リレーショナルデータベースが依然として人気が高いことです。彼らは今後長い間支配するでしょう。はい、現在、より多くの通信時間を取得する他のデータベースがありますが、実際にそこに何が起こっているのかを見ると、Oracleはそれのほとんどを行っており、Microsoft SQL Serverは2番目であり、クラウドではさまざまなことが起こっていますしかし、挑戦を引き起こす可能性があります。彼らはゲームの大きな巨人です。そして、これらはOLTPと実際のデータウェアハウスワークロードの両方に使用できるデータベースです。通常、代替手段は主に分析環境で使用され、通常は、リレーショナルではなくなぜそれを選択するのかについて、データによって決定されます。ほとんどの人はそうではありません。

企業は、単一のデータベースで標準化する傾向があります。最近、5, 000を超えるOracleのインスタンスを持つ会社に出会いました。そして、私はその会社から話をしていた人のように、DBAについて尋ねました。彼らは、約10人のDBAがおり、約30のデータベースが管理されていると言いました。そして残りは、Oracleは全体として最終的なシステムとして使用されていました。それらを使用したアプリケーションからのデータにはほとんどストレスがありませんでした。しかし、それは私を驚かせました-Oracleの5, 000インスタンス。

ところで、彼らにはOracleの不動産ライセンスがありました。もちろん、企業ライセンスです。しかし、アプリケーションには優先データベースが付属している場合があるため、他のデータベースもありました。 Oracleが唯一のものではなかった。そして、HadoopもSparkも実際にはデータベースではないことを言及する価値があり、データベースルールとして私が考えるものを獲得するまでには長い時間がかかるでしょう。もちろん、データリンクに適しています。

DBAの活動（おそらく、バレットは私よりもこのことについて恐ろしいことを言うことができます）が、私はそれらをただ実行します。これらは私が考える傾向があるものです、あなたは知っている、DBAは何をするのか。インストール、設定、アップグレード、ライセンス管理を行います。彼らは多くのETLを実行し、何らかの形で複製作業を行います。ストレージと容量の計画を行います。トラブルシューティングを行うか、トラブルシューティングチームの一員です。パフォーマンスの監視とチューニングは、ほとんどの活動のほとんどですが、この他のすべてのことは、決して小さくはありません。セキュリティ。バックアップとリカバリを担当します。ソフトウェアテストシステムに関与する必要があり、データライフサイクルに関与する可能性があります。

パフォーマンス。私がこれらの男の1人であったとき。私がデータベースを実行してチューニングしていたとき、これは私がそれをどのように理解したかでしたね CPUがあります。今日のある意味では、CPUはほとんどアイドル状態です。これは、他の2つまたは3つのうちの1つであるためです。他のボトルネックの1つが実際に問題を引き起こしています。ネットワークの複数のノードで実行していて、実際に何らかのロックが発生する可能性がある場合、メモリ、スラッシングとフラグメンテーション、またはディスク、ディスクI / Oの飽和、時にはネットワークオーバーヘッド。

しかし、それは私が見た世界でした。最近、OracleとOracleにあるチューニングパラメータの数を調べました。 300を超えました。実際に考えてみると、DBAが何をしているのかを本当に知っているDBAには、なぜこれらのいずれかを台無しにする理由についての考えが必要です。だから、あなたは知っている複雑な仕事であり、これによってより複雑です。

ご存知のように、今はCPUがありますが、CPUが既に存在している、CPUにGPUがある、またはCPUにFPGAがあります。そのため、CPUで実際に何が起こっているかについて、ある種の交配が行われています。 CPUはずっと前にマルチコアになりました。実際、それが起こったとき、私はもはやデータベースをチューニングしていませんでした。今考えてみると、実際にどのような違いがあるのかわかりません。

3D XpointとIBMのPCMが追加のメモリレイヤーとして登場し、SSDがありますが、それらは回転する錆に取って代わります。ただし、SSDの速度はさまざまです。非常に多くの場合、並列アクセスが可能になり、RAMの速度に近い非常に高速になります。そして、すべての並列ハードウェアアーキテクチャがあります。

そして、これがすべて、コストの低下です。これは本当に素晴らしいことですが、これがすべてを実現しています。データベースの次のリリースを取得し、それをマシンに実装し始めると、これは、レイテンシが非常に大きく異なるため、データの振る舞いに対して感じるかもしれない直感を実際に失っています。そして、ここでは、3層のストレージではなく、4層のストレージがあります。

データベースの問題。データベースのエントロピーを取得します。インスタンスの増殖は非常に一般的です。食器棚として使用されているデータベース、これは実際に私が与えた例でした。自己調整型のデータベースはほとんどなく、自己調整型であると主張するデータベースは実際にはそれほど優れていません。しかし、もう1つは、適切に調整されたデータベースが非常に少ないことです。ワークロードのバランスを取ることができるのは難しい仕事です。つまり、データベースについて考えるとき、データベースが24時間にわたって何をしているのかを考えると、ワークロードは非常に大きく異なる可能性があります。データベースには、特に真のデータウェアハウスが必要です。

そのため、チューニングは些細なことではありません。特定の時点で全範囲のワークロードに対応する必要があるパラメーターをチューニングしているからです。基本的に大変な仕事です。また、SQLは特にSQL JOINに対して調整する必要があります。それらは非常にリソースを消費する可能性があります。また、データベースに具体化されたビューがある場合、正直に言うと、それらの使用を調査する必要があります。すべてのビューが非常に高速になるためです。それには、ワークロードを理解し、SQLトラフィックなどを理解している人が必要です。

そして、ほとんどの企業は非常に少数のDBAを雇用しています。非常に高価です。私は、3人の男のような、かなりの数のインスタンスを持つかなり大きな会社を知っています。本当に、彼らは多くの費用がかかります、それは複雑さの面で難しい仕事です。ツールが必要です。

そして、それが私が言いたいことのすべてだと思います。そうそう。デズに話を進めましょう。デズが言っていることを見てみましょう。

Dez Blanchfield：ありがとう、ロビン。これは大規模なトピックです。私は、私たちが直面している事実上の日々の課題であると思うことを続けます。それに直面しようとするので、このトピックについて書かれた本の完全なライブラリがあります。技術書店に行ったことがなく、データベースのパフォーマンスとデータベースのチューニング、および監視の一般的なトピックだけで書かれた本の壁を見つけた人。そして時々、それは時間をつぶすのに最適な方法です。

一般的なトピック：パフォーマンスクエリの取得。私の経験では、エンドユーザーのレベルでは、人々はパフォーマンスを経験しているだけで、物事が遅いということを、このトピックに汗を流している組織のさまざまな部分があります。スピニングホイールは、クエリが返されるまでに時間がかかります。スペクトルの反対側には、物事が期待どおりに実行されていないため、データベーススペシャリストにbeatられているインフラストラクチャとネットワークおよびストレージエンジニアリングの人がいます。私の経験では、そのスペクトルの中で私たちの生活に影響を与える可能性のあるものは非常に広いスペクトルです。

物理的に上から考えると、コンピューターのスペースだけです。必要に応じて、メモリ、RAM、およびディスクスペース、ネットワーク、およびその周辺のすべてのビットがあります。このスペースには、生ディスクまたはJBODを使用した方が良いという考えが保存されています。できるだけ早くディスクを立ち上げて、データベースはデータ保護層を整理します。他の人は、安価なディスクの冗長アレイであるRAIDの大ファンであり、ハードディスクに障害が発生した場合に、ディスク上のRAID 0、1、3、5および6の異なるタイプのストライピングまたはレプリケーションについて異なる宗教経験を持っています。ストレージレベルおよびエンジニアリングレベルでも、ストレージの種類に関してパフォーマンスに関して異なる見解と経験を持っている人々がいます。

直接接続されたディスクとサーバー自体、または何らかの形のストレージエリアネットワークにファイバーチャネル経由で接続されているかどうか、iSCSIを介してサーバーからマウントされたストレージか、イーサネットかなどです。そして、それはデータベース層に到達する前です。私たちが当然と思っている種類のことを知っています。エリックが概説したように、それを維持するだけです。。パターンと意味のあるパターンを特定できただけで、パフォーマンスの問題を掘り下げて調べることができると考えています。

そして、それは非常に広範なトピックなので、私の経験では、投資した時間とエネルギーと努力がいくつかの良い収益を得る2つの領域に飛び込むつもりです。それで、これらの最初のものにすぐにスキップさせてください。そして、私は半分冗談を言って、内側にスケルトンがあり、外側にスキンがあるものの写真を探しに行きましたが、レゴブロックはおそらく最も恐ろしいものではありませんでした。しかし、多くの点でこれは、分析プラットフォームとそれらをサポートするデータベースで時々直面する課題を想像し、精神的に描く方法です。そして、それは、消費者、エンドユーザー、または開発者として、本当にベニヤスキンレイヤーだけを見ることが多いということです。しかし、それは実際には下のスケルトンです。本当に焦点を当てる必要がある問題です。

この場合、特定の日のデータベースパフォーマンスと分析に影響を与える可能性のあるもの、パフォーマンスヒット、コアインフラストラクチャ、およびそのコアインフラストラクチャの監視について考えると、先ほど概説したように、ディスクとメモリ、CPU。そして、ロビン・ブロア博士が強調したように、現在仮想化の課題とチップ自体で起こっていること、コアレベルまでのパフォーマンス、各コアの各チップに現在投入されているメモリ量。これらは非常に技術的な課題であり、日常の人を対象としています。

クエリの監視を維持します。クエリとクエリキューの監視に関する課題の1つは、たとえば、言語としてのSQLと、分析ツールを中心とするデータベースツール、特に言語としてのSQLが非常に強力であることです。しかし、その力とシンプルさは、多くの場合に来ます、そしてそれは、それが何度も何度も同じことをしているアプリケーションではなく、良い開発者によって書かれ、良いDBAによって発見された場合、非構造化クエリを実行する人々である。

そして、それに関する問題は、少しのSQLを学び、クエリを開始することは非常に簡単ですが、その結果、必ずしもあなたがやっているかどうかを知るためのすべてのスキルと経験と知識を持っているわけではないということですデータベースを実行するための良いことまたは悪いこと。したがって、同じ大きな、広く、間違ったものを継続的に実行するだけで、建物を破壊することができます。クエリの監視を維持することは興味深い課題です。

プラットフォームが何をしているか、ユーザーが何を取得しているかに関する応答時間を監視するだけです。繰り返しますが、適切なツールがなければ、これはあなたが直感的に物事を見て、「ネットワークの動作が遅い」、「ユーザーのメモリのパフォーマンスが悪い」、「インデックスのパフォーマンスが悪い」と考えるものではありません。」または「膨満しています。」

そして、問題を見つけた後、どのようにしてそれを分解してバンドル解除し、不十分に構造化されたクエリの全体的な課題に対処するのでしょうか？そして、ご存知のように、それは誰かが手で実行しているアドホッククエリですか、それともダッシュボードフロントエンドを備えた分析ツールであり、質問を間違った方法で行っているためパフォーマンスが低下していますか、それとも本当に本当にひどく書かれたコードの一部？

そして、それを繰り返して、エリックはセットアップで最初に言った、あなたは知っている、ただ繰り返し何度も何度もそれらのワークフローを微調整し、微調整する。ご存知のとおり、私が実行しているワークフロー、実行方法、実行頻度、実行するコード、CPUとメモリ、ディスクとネットワークのどこで実行しているのですか？ええ、それは本当に、本当に技術的な挑戦です。

そして、この世界で人々が探しているn、歴史的な分析やパフォーマンスチューニングから環境へのアラートへと移行しながら、物事が遅くなった理由を知っていれば将来計画を立てられるかもしれないので、それは素晴らしいことです昨日の朝9時。しかし、それは今あなたを助けません、そして、それはあなたの計画を前進させるのを助けません。

キャパシティプランニングとサイジング、スケーリング、チューニング、つまり、大きなデータベースプラットフォームを持ち、広く普及しているデータベース環境を持つ非常に大規模な環境に変化が見られる傾向にあると思います。過去のアラートと計画から予測アラートと計画まで、現在何が起こっているかを知り、今後の計画を立てることができます。または、メモリが不足していて、次の1時間でメモリが不足しますか？リアルタイムでどのような容量計画ができますか？

すみません。これらのハードルを発見するという課題全体が、基本的に私たちが流動分析と呼んでいるものを邪魔し、それを組織の標準にするという点に到達します。ご覧のとおり、それは毎日の偉大な、洗われていない大衆にとって、取るに足らない挑戦です。そして、さらに技術的に精通している人にとっても、それは重要な挑戦です。

単なる人間にとって難しい場合、これをどのようにして可能にするのでしょうか？なぜなら、これらのほとんどは通常のユーザーが解決できないものであり、特別なデータベースエンジニア、データベース開発者、コード開発者、プログラマーがいる可能性があるからです。しかし、彼らは実際に環境をアンバンドルできる必要があります。彼らはコードを再利用する人々のような問題を解体しなければなりません。

ご存知のように、データベースサーバーインフラストラクチャの非常に大規模な展開における分析プラットフォームのパフォーマンスヒットに関して、この分野で私が見た最悪のことの1つは、コード、SQLの塊、または盗まれた手順を取っている人々です書いて、彼らはそれが良いコードか悪いコードかを知らず、彼らが望む結果を与えるのでそれを再利用するだけです。しかし、レポートのように、1つまたは2つの結果を得るためにオンザフライで書かれたものであった可能性があります。誰かが急いでいました。

そのため、人々は書いていない複雑なコードを使用しており、実際にバックエンドを罰していることを知らずに、アプリケーション開発の一部にそれを平手打ちしています。そのパフォーマンスヒットを監視し、クエリの発信元を調べてドリルダウンするだけでも、それは日常の課題です。

可能な場合、パフォーマンスのための事前ステージングデータなどの基本的な動作。バルクインポートを行う場合はインデックスを削除し、テラバイトのデータを取得するときにインデックスが維持されないようにインデックスを再作成するなど、経験だけが教えてくれます。適切なツールなしでは、インデックスが破壊されていることがわからないため、ほとんど見ることができません。

インデックスを定期的に最適化することは101のようなものですが、一括インポートを行うとき、または誰かが本当に大きなクエリを実行する場合にクエリでテーブルを作成するときはどうでしょうか？これは大規模なパフォーマンスヒットになる可能性があります。また、監視していない場合は、それを確認するツールがありません。そのようなことはバックグラウンドで発生するだけで、対処方法もわかりません。。

クエリを必要な列の数だけに制限します。つまり、非常に基本的に聞こえますが、表示されない場合は、それが発生していることを知らず、バックグラウンドで発生するだけで痛いです。、あなたに。

一時テーブルを使用するタイミングと場所を把握し、大規模な削除と更新をまとめます。繰り返しますが、非常に単純なことですが、その可視性がなく、それを行うツールがなければ、彼らはただバックグラウンドに座ってあなたを傷つけ続けます。データベース環境でより多くのメモリまたはCPUを投げ続けるだけで、分析プラットフォームのパフォーマンスが向上します本当に何があなたを傷つけているかの詳細を掘り下げ、その特定の事柄に対処できるはずです。そして、あなたは知っています、外部キー制約のようなものとそれをどのように見つけますか、それが問題であることをどのように知っていますか？

ここで私の重要なポイントの結論に至ります。それは、日常的に、これらの問題が至る所に見られるということです。そして、データベース環境がますます大きくなり、ますます広くなり、ロビン・ブロア博士がここで強調したように、データベース時間とともにますます複雑な環境モデルが得られます。

そして、HadoopやSparkなどのビッグデータプラットフォームに統合する必要もあります。私の見解では、このリアルタイムのプラットフォームのパフォーマンスと分析と診断をインテリジェントに実行するためのより良い方法と特定のツールを見つける必要があります。なぜなら、これらのことを掘り下げるためのツールに着手しなければ、エンドユーザーにとってはリアルタイムとお金、そしてフラストレーションとコストがかかるからです。

それで、私たちはIDERAの友人たちに引き渡します。なぜなら、彼らがこのまさに問題にどのように対処できるかを伝える良い物語を持っているからです。

Bullett Manale：いいですね。どうもありがとうございました、私は先に進み、物事を開始します。ここにもいくつかのスライドがありますので、先に進んでそれを持ち出します。これらのいくつかは、私たちがかなり迅速にジャンプするつもりです。

ちょっとした洞察を与えるために、私はここIDERAのセールスエンジニアリングディレクターです。そのため、私たちが行うことは、多くの場合に特有の痛みや課題についてDBAに定期的に話すことです。、パフォーマンスモニタリング、およびこれらの種類のものは、明らかに。そして、そのオーディエンスから多くのことを聞いているので、彼らから受け取った情報の一部を定期的に共有することができ、それが理にかなっていると思います。私はこれらのいくつかを飛び回ります。なぜなら、彼らが会話に本当に関係があるとは思わないからです。

DBAの責任に関する私自身のリストがここにあります-それはロビンのリストによく似ており、かなり一貫していると思います。しかし、データベース管理者と話をするとき、それは常にだと思います-あなたは知っている、彼らは他の領域よりもこれらの領域の一部に集中しており、それに韻や理由はなく、それは単に環境に依存します。

人々ができることを望んでいる、かなり広く、幅広いことを聞きます。そして、多くの場合、これらのことを望んでいる人々はそうではありません。彼らは彼らに尋ねます。そして、場合によっては、彼らが本当に求めているものを掘り下げて、それから彼らがいることを見つけます。本当にもっと探しています。彼らは本当に彼らが最初に必要と考えるよりも多くの情報を望んでおり、あなたがツールを掘り下げ始めたとき、私は彼らがデータと会話していると言い始めることができると思う。

それは本当に面白いフレーズだと思います。そして、ええ、まあ、もしあなたが悪いクエリを持っているなら、本当に悪いクエリとは何でしょうか？多くの読み取りまたは書き込みまたはCPUを消費しているのはクエリですか？それはたくさん実行されるものであるかもしれません、それはあなたが知っているように、それはあなたが言ったように、不十分に書かれているかもしれません。

それをどのように識別するかという点では、製品であるDiagnostic Manager製品の観点から見ることができる多くの方法があります。そして、それは非常に柔軟であり、それは大きなことの1つだと思います。これらのパフォーマンスの問題を解決するツールを用意する必要があります。

そして、あなたは多くの、あなたが知っている必要があるでしょう、そしておそらく監視の面で要件を曖昧にすることさえあるので、あなたは柔軟性があり、動作し、環境に適合することができるものを持っている必要がありますあなたが管理しようとしています。これらの例はたくさんありますが、それぞれについては説明しませんが、あるデータと別のデータとの間で前後にピボットできるものが必要です。製品について少し話をして、それをお見せしたら、その方法についてお話しください。

しかし、優れた分析ツールに関して私が考える他のことは、あなたが本当に探しているいくつかの中核的なものがあるということです。当然のことながら、何よりもまず、パフォーマンスという名前で独自のパフォーマンスの問題を引き起こすツールは必要ありません。費用なしでデータを収集するという場合、費用については金銭的費用という意味ではなく、間接費という観点からの費用と、リソースの量という観点からの費用という意味です。「パフォーマンスの名前で使用するつもりです。あなたは間違いなくそこに役立つ何かを望んでいます。

日々の中で直面している問題に固有の、探しているデータを取得できるものが必要です。また、不要なものや不要なものがあるかもしれません。必要ではありません。データを報告したり、そのデータを管理しようとする必要がない場合、そのデータを収集しても意味がありません。たとえば、パフォーマンスに関連付けられたメタデータに関して。

良い例としては、SQLの分散トランザクションコーディネーターサービスがダウンしていても、最初に実行したくない場合に警告する必要はありません。だから私に警告しないでください、それに対してデータを収集しないでください-私はその情報を必要としません。そのため、これらの機能をオン/オフする機能を持つことが非常に重要です。

また、データを収集すると、すぐにデータにアクセスできるようになります（データを実行、マッサージ、データを操作する必要はありません）。データを迅速かつ効率的に実行できます。そして、データを取得したら、明らかにそれを理解できることが本当に重要です。

さて、ここで、たとえば、今日お見せするDiagnostic Manager製品を使用して、その製品について説明します。この製品は、その製品が置き換えて、ボックス内のDBAになります。現実には、環境が何であり、何を達成しようとしているのかについてある程度の知識が必要です。明らかに、DBA自体の役割を理解することが重要です。

今、私たちがやろうとしているのは、ヘルプや他の方法を通して教育することです。しかし、明らかに、これを何らかの種類の経験レベルや、データを受け取った後に何をすべきかをある程度知っている人と結び付けたいと思うでしょう。そして、製品に適切な質問をすることができる人を持つことができ、データとの会話を持つことは明らかに重要です。そして、明らかにデータの意味を理解することができます。

情報を入手したら、それを適切な人に伝えることができます。私の開発者、私の運用チーム–だれでも、他の製品と統合する必要があるかもしれません。これらはすべて本当に重要なものです。そして、明らかに、最後になりましたが、重要なことですが、もっと詳しく知る必要がある場合は、そうすることができます。収集するためにもう少しオンにすることを意味するのか、それともデータを少し深く掘り下げることを意味するのか。パフォーマンスを支援するツールがあれば、これらの質問に答えるために必要なすべてのものを手に入れられることを望んでいます。

ここで取り上げなかったのは、おそらく注目に値すると思いますが、通常のものとそうでないものを区別するのに役立つツールが必要です。それは大きなものだと思います。なぜなら、たくさんのアラート製品やそこにあるものがあるからです。しかし、アラートを受け取っていて、アラートが誤ったアラートであるなら、それはあなたに何の役にも立ちません。 ; それは時間の無駄であり、彼らを助けようとするよりもあなたの効率を低下させるでしょう。だから、あなたが知っている、それらは私が心に留めておくいくつかのものです。

IDERA製品スイート内でこれらすべてを結びつけている製品について話すとき、それはおそらくデータベースの観点からここで話していることの主な種類の特徴を持っていると思うDiagnostic Manager製品ですチューニングとパフォーマンスと監視、およびこれらの種類のもの。

人々は企業レベルの監視を探しています。 1つの画面で、物事が本来の方法で機能していることを知ることができるようにしたいのです。または、明らかに問題がある場合は、問題の場所を確認してから、その問題にドリルダウンできるようにしたいと考えています。私は、人々があなたのパフォーマンスに本当に磨きをかけることができるこれらのタイプの方法で探しているものの本当の大きな部分だと思います。

それと明らかに一致するもう1つのことは、現在だけで操作することはできません。それは、実行が不十分なクエリを見ることを意味するのか、それとも、ホストVM自体がリソースの観点から動作している様子を見てください。あなたができるようにしなければならないこれらの種類のことのすべて、そしてあなたは毎日24時間、あなたのコンソールを見つめてそこに座っているつもりはありません。

休暇中または深夜、またはそれが何であろうと、インスタンスで何が起こっているのかを話すことができるように、時間内に戻ることができるものが必要です問題が発生した時間。そして、それをもう一度、効率的かつ迅速に行うことができ、それを掘り下げることができることは、この議論の観点から間違いなく重要な部分です。そして、それはおそらく人々が探しているものの観点からより重要なものの一つだと思います。彼らは常に過去へのその窓を探しています。なぜならそれは本当にimだからです。あなたはそこに座って何かが再び起こるのを待ちたくないのです。

リストの次のことは、クエリパフォーマンス自体を使用して、前に説明した内容に結び付けるだけです。そして、Diagnostic Manager製品内のいくつかの異なる例を紹介します。その方法を説明します。1日の終わりには、クエリ自体に関するさまざまなオプションを提供します。あなたが集まりたいです。

リソースの痛み、CPUの消費、またはI / Oの消費を引き起こしているクエリに興味があるかどうかという点で。完了するのに長い時間がかかるクエリや、一般的にはパフォーマンスの面では最悪の問題ではないかもしれませんが、実行頻度が非常に高いため、実行自体の頻度が問題になる可能性があります。そして明らかに、これらのクエリを使用して時間とともにトレンドを見つけることができることは、その重要な部分です。

この製品では、さまざまな方法でそれを行うことができます。ほとんどのDBAにとって、これは明らかに重要な要素だと思います。また、社内で開発した独自のアプリケーションがない場合でも、ソフトウェアベンダーにアクセスして、「ねえ、知ってる？ご存知のように、毎日午後2時にこの仕事が始まります」またはそれが何であれ、「あなたのアプリケーションがこれを引き起こしているので、修正する必要があります。」コード自体を制御しますが、問題がいつ発生するかを知ることはまだ便利です。

そして、あなたは知っています、他の部分は明らかにより積極的です。最初に知ることができること、問題が発生していることを理解できること。最初に知ることができるので修正できますが、多くの場合、多くの場合、応答を自動化できるものが必要になります。私が会議に参加している場合や、外出中に何をしていようと、「ねえ、これを直さないといけない」と言うメールを受け取るのではなく、あなたは知っています。「やっていることは、それが自動化された方法でそれに対処することができる場所に何かを持っていると言うことができることは明らかに非常に素晴らしいです。

そして、自動化された方法で対処されていない場合は、少なくとも最初に知ることができるので、是正措置を取るか、できる人に連絡することができます。したがって、これらは明らかに、マシンとインスタンスの監視および分析自体の点で遭遇する可能性があるこの種の問題にとって、非常に重要な要素です。

さて、これについては以前に話しました。これは物事の柔軟性です。私はこれを十分に強調することはできません、あなたが知っている、あなたが知っている、監視されていないものがあれば、それらを追加できる製品内の機能を持っていることができます監視されます。また、Diagnostic Managerの例では、WMIカウンター、カウンター、SQL Serverカウンターがあります。独自のクエリを作成できます。

必要に応じて、vCenter環境またはHyper-V環境からデータをプルすることもできます。これは、ポーリングが行われ、定期的に実行できるためです。そのデータを引き出して表示できるようにします。また、この情報を見ながら、ある場所から別の場所にピボットします。

チューニングとパフォーマンスの面で役立つツールについて話しているときに人々が尋ねるのを見ると、そういうものです。 2つ目はDiagnostic Managerで、2000年から2016年までのすべてをサポートします。SQLServerに固有であるため、これらのことを監視します。インスタンスを監視しているインスタンス自体にはエージェントはありません。

少しコストをかけて情報を収集することに戻ります。多くのリソースを使用するのではなく、明らかにこの情報をより多く収集しようとしました。私たちは、SQL Serverが既に提供しているものを活用し、動的管理ビュー、拡張イベント、またはコレクション自体に関するケースに関係なく、それを改善しようとしています。その情報を活用して改善できるようにすることが、私たちの使命の1つです。

さて、これを実際にすばやく見てみると、アーキテクチャをあまり詳しく説明しませんが、バックエンドリポジトリには、管理可能なすべての履歴データが含まれており、あなたが欲しい。保持する情報の種類と期間を選択することもできます。それはある種の話に戻り、適切なデータを収集し、不要なデータを除外します。コアパフォーマンスであるクエリを5日間保持し、その後2年間アラートを保持する場合、それはあなた次第であり、それを行うことができるのは完全に特権です。

この製品にはさまざまなコンソールがあります。 Webベースのバージョンがあり、シッククライアントバージョンもあります。そして、それはブラウザにジャンプして何が起こっているかを見る柔軟性を持っているか、専用クライアントがインストールされているラップトップを持っているなら、これらのアプローチのどちらかがあなたのために働くでしょう。

さて、私がやりたいことは、ちょっとしたデモをすることです。そして、私はここでこの他のスライドに戻る-私たちが持っていることを指摘します、私たちはちょうど製品に精通している人々のためのFYIとして、私たちが持っている、新しい製品がありますDiagnostic Manager Pro。ワークロード分析と呼ばれるものを含むプロフェッショナルなサービス。

そして実際には、非常に長い時間をインタラクティブに見て、30日間のビューから約3回のクリックで5分間のビューに移動できるようにすることです。また、パフォーマンスの急上昇やボトルネックの問題を確認できれば、非常に高いレベルで確認でき、非常に低いレベルまでドリルダウンできます。そして特に今日でも、それはこの製品の新機能です。

しかし、私がやろうとしているのは、最初のスタートのようなものです。そして、そのピボットと前後のことについて少し話したいです。そして、例を挙げて、ここで画面で共有します。そして、見てみましょう… 私の画面。そして、あなたがそれを見ることができることを、私に知らせてください。

エリック・カバナ：どうぞ。

Bullett Manale：あそこはすべて大丈夫ですか？わかった。それで、あなたが今見ているもの（これがDiagnostic Manager製品です）で、ここで何が起こっているのかを示す高レベルのデモを提供したかっただけです。この特定の例では、待機に関連付けられているクエリを表示しています。ですから、前後に移動したり、より深く掘り下げたり、ピボットしたりできることについて話しているとき、それがここにあります。このビューはその良い例です。ここに表示されているように、現在表示されるタイムラインビューから移動できます。この場合、待機自体と待機のカテゴリ自体を調べています。これらの待機に関連付けられているステートメントを見ることができ、アプリケーションを見ることができます。

ここのタイムラインビューにあることに注意してください。そのため、問題が発生した時期に基づいてその情報を線形に識別できますが、もう一度、ピボットしたい場合は、「わかりました、見てみましょう」と言います。これを別の視点から見てみましょう」と言い、「私が最も苦痛を引き起こしているクエリ、待機、またはアプリケーションを確認し、それらをランク付けしたい」という観点からこれを見ていきましょう。「クエリは期間ごとに待機します」で確認します。現在、アプリケーション自体が、最も多くの苦痛または待機を引き起こしています。

そして、実際に最も重要な部分は、これらのものを分離できることです。ここで、このNoSQLアプリケーションの開始を確認できます。この30分間の時間内で25秒間の待機時間に相当するかなりの待機時間が発生します。そして、そのアプリケーションを分離し、この場合、この特定のインスタンスに直接影響するステートメントを見ることができます。

したがって、これは、ボトルネックを特定し、情報をランク付けし、最初に対処する必要のある問題に優先順位を付けることができる方法の一例にすぎません。これらはすべて考慮しなければならないものです。 1日中問題を修正できますが、リストの一番下にある問題を修正する場合は、時間を無駄にします。それに関連する機会費用があります。

別の例を示しますが、これは少し異なる例です。問題を具体的に指摘したり、地域を指摘したりするのではなく、「おい、何か問題がありましたか？」または「ありますか？」と言えるように、広い意味で役立つツールが必要です。パフォーマンスを改善するためにできることはありますか？」この場合、これは構成に関連している可能性があります。インスタンス自体のヘルスが管理されている方法に関連している可能性があります。そして、明らかに、パフォーマンスも同様です。

ここでこの分析ボタンに移動すると、この製品では、本質的に洞察を提供するランク付けされた形式で実行できるものの積極的なリストが表示されますそのインスタンスでのパフォーマンスの向上、またはそのインスタンスの正常性の向上をもたらす可能性が高いものに。そして、特定された特定の種類の問題に固有のパフォーマンスを向上させる可能性が高いものを確認できるという意味で、ランク付けされた形式です。

そのため、これらのことを見て特定すると、問題があることだけでなく、多くの場合、その問題を解決するために自動的にビルドできるスクリプトもあります。しかし、これらの多くの場合、私たちが経験している問題のタイプを参照する外部リンクもあり、それからなぜこの推奨事項も提供しているので、あなたは物事の教育的側面を得ることができます。繰り返しますが、これは問題を解決することについて話しているときに非常に重要だと思います。

盲目的にこれらの推奨事項に従うだけではなく、これらの推奨事項が作成されている理由を理解したいと思います。そして、私は30年間これをやっているシニアDBAかもしれません、そして、あなたは知っているか、あなたが知っていることを確認する必要があります-この場合、私はドットをつけてtを越えます-または多分私はジュニアDBAであり、これらの問題が発生していることを理解し、なぜこれらの推奨事項が作成されているのかを理解するには、少し助けが必要です。

先ほど言ったように、製品のいくつかの異なる部分を紹介します。このツールは、2004年、2003年から使用されています。また、多くの開発、情報が含まれているため、ここですべてを説明するのは意味がありません。しかし、注目に値するものの1つは、私たちが入って、あなたが監視できるすべてのこと、そしてあなたが警告できるすべてのことについて話し始めるとき、もう一度、その柔軟性に戻ることだと思います、ここに私たちが監視しているすべてのアイテムのリストがあります。

さて、これらがしきい値の点で強打から抜け出した場合、これらの事柄がアラート状態にあると必ずしも考えたいというわけではないので、これらの事柄をオンまたはオフにできます。これは、「ねえ、特定の指標に対して特定のことをするだけでいいのです。特定の問題に注意を払うだけでいいのです。」そして、多くの誤検知で私たちが飽和状態にならないようにすることができます。これらの機能を有効または無効にするだけでなく、多くの場合、各メトリックに関連する通常の帯域も提供していることに気付くでしょう。この特定の場合、この場合はベースラインを見ていると、しきい値が現在より高い可能性が高いことに気付くでしょう。

コインの反対側にあるのは、SQLのインスタンスがあり、何らかの理由でメトリックを追跡し、何らかの理由で設定したしきい値が正しくない場合です。言い換えると、しきい値はベースラインが実際に座っている場所の真ん中に軽く塗られています。つまり、そのしきい値に関連付けられたアラートがある場合、通常のイベントであるアラートが発生する可能性があります。そのため、このような状況では、その洞察を全面的に提供できます。

この特定のインスタンスのすべてのメトリックについて、正常なものとそうでないものに関して、おそらくここで誤検知を示す可能性が高いしきい値を確認できます。これは、メモリ側でより通常の使用方法と見なされるものになるでしょう。そのしきい値を増やしたい場合は、できますが、それはベースラインに関する一種のアイデアです。

また、ベースライン自体に関してDiagnostic Manager製品の素晴らしい点は、複数のベースラインを設定できることです。そして、「なぜ私はそれをしたいのか？」と尋ねることができます。そして、答えは、あなたが本当にあなたのリソースに負担をかけている真夜中から午前4時までのメンテナンスウィンドウがある場合、「可能な限りリソースを実際に使用しているので、もう一度シフトできるようにしたいので、少しピボットして「見て、そのためのしきい値を変更する」と言いたいです。そして、実際には、時刻や曜日などに基づいて、たまたまベースラインに固有のしきい値を動的に調整できます。そのため、これらのしきい値を動的に調整します。

もう一度一歩を踏み出しましょう。これらのしきい値を特定し、それを通過した後、アラートと通知を設定し、発生する可能性のあるこれらの状況を認識できるという点で、柔軟性がここで最も重要です。特定の状況でアラートを発したい場合。他の状況では、電子メールを他の人に送信したり、PowerShellスクリプトを実行したり、リストが続くこともあります。

SNMPトラップを介して、またはSCOMなどと直接統合することもできます。重要なのは、それを行うための柔軟性があり、すべてのインスタンスにわたって、非常に広範囲にわたる状態（私のCPUとメモリ、または任意のリソース）であるかどうかを保証するあらゆるタイプの条件を設定できることです。、または私が監視したい非常に特定のタイプのものがあるかもしれません。なぜなら、私たちが違反していることに気付いたら、その問題に対して非常に具体的で指示されたスクリプトを実行したいからです。したがって、ここで、Diagnostic Manager製品内でそのようなことを実行できるのは、アラートと通知の観点から、そしてその観点から柔軟に対応できるということです。

今、私はすべての警告とすべてのそのような良いものを通過しません。レポートについて話したいと思いました。また、情報を取得してさまざまな方法でそのデータを活用できるようになりました。これは、データとのやり取りに戻ります。そして多くの人々は、最初にこの製品を見たとき、「ああ、まあ、問題が発生したときに私に警告するツールを手に入れるつもりです。そして、現実には、彼らはそのツールを必要としていますが、その反対側は、もし彼らが本当に–もし彼らが意思決定を支援するツールも必要であり、彼らがこの情報を活用できるならパフォーマンスの名前とアラートの名前の両方で収集することで、今後の判断を下せるようになります。

良い例は、データベース内での成長予測です。特定のデータベースが成長している場合、そのデータベースまたは複数のデータベースをポイントして、成長率を確認できます。今日の内容に基づいて表示しているわけではありません。私たちが経験した過去の成長に基づいて予測します。

ここにいくつかのデータベースを持っている場合-たまたま想像してみてください-「1年分のデータを最後に取り上げましょう。それを月ごとに、サンプルで関連付けましょう。数ヶ月の割合で、先に進んで、今後3年間、つまり36ユニットでどれだけの成長が見られるかを見てみましょう。」その場合、その質問に非常に迅速に答えることができます。さて、それを自分でやってみてくださいね？私があなた自身でやったのと同じくらいの時間でそれをするようにしてください。しばらく時間がかかります。

さて、さらに強調するために、別のレポートを見てみましょう。これは、私のトップサーバーレポートです。 100個の実稼働インスタンスがあると想像してください。この場合、実稼働インスタンスはありません。しかし、誰かが私のところに来て、「あなたが私に言う必要があります。このすばらしい新しいアプリケーションのためにこの新しいデータベースを公開するつもりです。私たちが知っているようにすべてを変えるでしょう。それは人生をとても素晴らしいものにするでしょう。ああ、ところで、データベース自体は本当にI / O集中型になります、またはCPU集中型、または本当にメモリ集中型になります…」私のすべての実稼働インスタンスの中で、そのデータベースを配置する意味がどこにあるかを見ることができますか？また、CPU、メモリ、ディスクなど、どのような場合でも、偶発的なタイプに関して、すべてのインスタンスを相互にランク付けできます。したがって、ここでのポイントは、その質問に迅速かつ効率的に答えることができ、あなたがそれを行うときに推測するのではなく、正しい決定を下すことです。これらはすべて明らかに重要であり、あなたはあなたを助ける何かが必要です

そして、分析について話すときは、キャパシティプランニングで話しているようなものから、CPUを処理する可能性のある日常的に実行されているアラートまで、さまざまです。明らかにクエリ自体、ブロックなどがあるかどうかなど。

別の例として、ここの管理セクションに行った場合、実際には、ここのアラートセクションに戻って、過去に起こったことを過去の情報の預託機関に照会します。実稼働環境で発生したブロッキングがありましたか？わかりません、調べてみましょう。

Productionタグに戻ることができます。また、特定のメトリックについて、任意の期間を指定して、すべての実稼働インスタンスについて言うことができます。私たちのケースでは、アラート状態になった場合、ブロッキングの秒単位ではなく、カウント単位でブロッキングします。必要に応じて、この場合は数か月前に戻ることができます。ケース、1か月–そして、私はそのブロッキングを見ることができます。開始時刻、終了時刻、必要に応じてこれらのプル間隔のいずれかにドリルダウンして、ブロッキングインシデントの詳細を確認できます。たくさんのサイクルを回して実行するのではなく、必要なものを見つけて探すことができる、非常に迅速なものを手に入れる必要があります。そして、それも重要だと思います。

最後に紹介したいのは、この製品であるDiagnostic Manager製品を紹介することです。前述したように、SQL Diagnostic Managerに別のコンポーネントを追加しました。プロ提供。そして、それがワークロード分析コンポーネントです。そして、これはこれのウェブベースのバージョンであり、この場合はここに示しています。しかし、ここでのポイントは、これにより、非常に広い期間または非常に特定の時間枠を見ることができ、数回のクリックで、発生した可能性のある問題に直接関連するコードを表示できることです。

その一例として、4週間のビューを見ると、ここで、データベースとそれらのデータベースのパフォーマンスに関するすべてのスパイク、およびそれらのデータベースでの待機アクティビティを見た場所を見ることができます。ここで、ここで急上昇している場合、このツール自体の利点は、その小さなバーを強調表示できることです。そして、それを行うと、ここにあるものはすべて変わります。データベースを見ることができ、すべてのコマンドがそのバーの背後にあるものに結び付けられているのを見ることができます。

過去4週間ではなく、「過去4時間を見てみましょう」と言った場合も同じです。まだできます。私はまだその期間を強調することができます、そして、そこから-ここに、もう一度、ここに私の要点があります-ここにリンクできるこれらすべての事柄です。上位のSQLステートメント、この場合、CPU消費に関連する待機を引き起こしているクエリを確認できます。ドリルインするだけで、ここに関連するクエリ（whoops）を確認できます。また、これに関連するプログラムやその他の情報も確認できます。

ここで多くの洞察を得ることができますが、それだけでなく、コマンドレベルに到達すると、それはあなたに物事を伝えることになるでしょう。重い演算子が表示されるかどうかを確認し、実行計画を表示できます。これをロードするにはかなり時間がかかるため、これには少し時間がかかります。しかし、ここでのポイントは、データを表示し、探しているものを見るためのさまざまな方法があり、必要に応じてそこからアクションをとることができるということです。通常よりも長いので、そのままにしておきます。

それで、それを言って、私はそれを引き渡すつもりです。そして、うまくいけば、これが私たちが話していたようなことの良いデモンストレーションであったことを願っています。そして、私が言ったように、私たちがこれらの例を与えるために使用していた製品自体はかなり長い間存在していたので、私たちが話してあなたに見せることができる他の多くのものがありますが、これが興味深いものである場合あなたはいつでも私たちのウェブサイトに出かけ、それをダウンロードして、それをいじることができます。

エリック・カバナフ：そして、あなたがこのすべての詳細を示すことが大好きです。 2つ前の画面に戻ると、この画面でもかなり良いです。なぜなら実際に何が起こっているのかを視覚化する方法は非常にたくさんあるからです。そして、これは最近のコンピューティングの過小評価されている側面の一つだと思います。それは確かにデータベース環境であり、多くの点で「私はまだシリコンを話すことを学んでいます」と言っているこの半ば冗談を持っています。非常によくできていたので、何が起こっているのか、なぜ物事がゆっくり進んでいるのかをよりよく理解するには、データとの会話が必要です。そしてもちろん、IDERAにはいくつかの異なる製品がありますが、その1つが、これを補完できると思う古いPrecise製品です。

しかし、ロビン、私はあなたにいくつかの質問を投げかけます。そして、デズ、あなたからのいくつかの質問、そしておそらく聴衆からだれでも、恥ずかしがらないでください。今すぐ送ってください。

バレット・マナーレ：ロビン、あなたは黙っていますか？

Robin Bloor：はい。それは大丈夫です、私は自分自身をミュートから外しています。特に信じられないことです。実際、このツールで最も劇的な印象を与えたのは、特に一連のディメンション全体が入っていないことが非常に明らかであるためです。これについて最も印象的だったのは、DBAを訓練するための本当に、本当に良い方法であるに違いないと思います。ご存知のとおりです。つまり、最初にデータベースの作業を始めて、実際にデータベースで何が起こっているのかをよく知らない場合、実際に理解するのは非常に困難です。それで、これは特にトレーニングによく使われますか？私はそれを使用します。

バレット・マナーレ：ええ。トレーニングと言うとき、DBAのようなものとして進行中のトレーニングのようなものを意味しますよね？の面では…

Robin Bloor：はい、はい、はい、はい。学習ツール。あなたが知っている、。

Bullett Manale：確かにそうだと思います。さらに、これを追加したので、先ほどお見せしたAnalyzeコンポーネントには、すべての推奨事項が関連付けられています。しかし、ヘルプや製品内のさまざまな分野で、きっと多くの洞察が得られると思います。多くの情報。

そして、私が言ったように、現実はあなたがDBAでないならこれを使うことができます。おそらく、ほとんどのDBAが持っているものの一般的な知識に基づいて、Google検索などを行うことになるでしょうが、これを相関させることができ、「ねえ、知ってる、ちょっとこれは断片化と呼ばれますか？」または「なぜこのクエリが6, 000回実行されるのですか？」という意味です。これらのものはあなたに持ち込まれ、バブルアップして表示されるからです。あなたは、あなたが、あなたが知っている、何が正常で、何がそうでないかを見るでしょう。スパイクのあるものとそうでないものが表示されます。

原則として、ベストプラクティスの観点から、このことを設定します。そのため、インスタンスをポイントすると、ベストプラクティスの範囲外として特定されたものが表示されます。もちろん、ベストプラクティスはベストプラクティスであり、必ずしも実際のプラクティスとは限らないというのが現実です。しかし、ご存知のように、インストールしてインスタンスをポイントする最初の時点からでも、外れ値が表示されます。

そして、そこから問題を解決し、それが本当に問題なのか、通常は日常的に発生しているものなのかを特定する必要がある場合、そこから先に進むことができます。そして、役立つ情報や推奨事項がたくさんあるので、もちろんそうです。

Robin Bloor：わかった。そして別の質問-これに対する答えは非常に迅速であると確信しています-それは、個々のクエリと個々の時点に直行し、その次元から見る粒度を持っているということです。

Bullett Manale：もちろんです。やりたいことに応じて、1分間の時間帯、3日間の時間帯、または3週間の時間帯を見ることができます。そして、あなたが知っていることは、私が言ったように、それはあなたがどのようにデータを見たいか、そしてまたあなたが何を集めたいかによって異なります。場合によっては、特定したしきい値に達したクエリのみを収集します。他のケースでは、待機の原因となるすべてのクエリを収集する場合があります。

しかし、「見た、私が特定したこれらのしきい値、おそらく書き込み専用、または読み取り専用、またはCPU専用」と言う能力もあります。したがって、そのしきい値を超えていると仮定すると、それは収集したいものを見ると、どのような時間枠で見たい場合でも、問題のあると思われるものに基づいて、問題のあるクエリを見ることができます。

データを見るにはさまざまな方法があります。統合ビューでそれを見て、知っている、クエリを開始する-舞台裏のクエリが何回開始されたのか、そのクエリのすべてのインシデントが開始されて、パターンを見る悪化し続けているかどうかを確認します。

しかし、あなたの質問に答えるために、あなたは間違いなくあなたが望むいつでも指すことができます。履歴ブラウザと呼ばれるこのものがあります-私は少しそれを使用していましたが、基本的には、選択した任意の時点、選択したカレンダーのどの日でも、その時点に直接移動できます。

現在、11月15日午後7時5分に検索しています。その時間に固有のクエリを見ることができます。その時間枠を与えられて実行が不十分なものがあった場合、その時間枠に固有のセッションの詳細を調べて、実行されているセッションを確認できます。つまり、ここにはたくさんのデータがあります。私が言ったように、本当に難しいのは、実際にコンソールで遊んで、この方法を理解するのに30分かかることです。

ただし、ここのデータのほとんどがこのリボンにあり、これらのタブで分割されていることを認識すると、各タブには、クリックするたびに表示される動的に変化するボタンの独自のセットがあります。時間的なものや先週起こったもの、それは同じプロセスです。基本的には、11月15日に探していますが、そのボタンをクリックするだけでリアルタイムを簡単に見ることができます。そして、同じ方法でデータを操作します。

しかし、あなたの質問に答えるために、ええ、履歴情報を表示する多くの異なる方法があり、それはクエリ自体にも関係します。

ロビン・ブロア：なるほど。とても印象的です。また、最近のリアルタイムデータを扱うものでは、ウィンドウが同期する必要性が非常に高くなっていますが、ウィンドウが同期するという事実が大好きです。

バレット・マナーレ：ええ。承知しました。

Robin Bloor：ここにあるのは、私が実際に答えを知らない情報のポイントです。 SQL Serverとクラウドのオファーとして、Ratioの下でクラウドをポイントできますか？

Bullett Manale：できます。これをクラウドの下に向けることができます。実際にインスタンスを追加すると、RDSかAzureかが尋ねられます。今、クラウドから私たちに公開されているものに基づいていくつかの制限があるので、あるかもしれません-単にインストルメンテーションが場合によってはそうではないので、監視できるものに関して少しの違いがありますマイクロソフトが公開しているものに基づいて、私たちが集まる場所はありません。

さて、プラットフォームとしてのインフラストラクチャ、つまり、ご存知のように、EC2またはそのようなものであれば、それはまったく問題ではありません。すべて入手できます。そして、マイクロソフトと連携し、Amazonと連携しています。その情報をさらに詳細に公開するよう取り組んでいます。しかし、絶対にそうです、これらの環境をサポートしています。

Robin Bloor：わかりました、面白いですね。さて、私はDezに引き渡します。Dezは別の方向から質問を投げかけると確信しています。

バレット・マナーレ：わかりました 。

Dez Blanchfield：ありがとう。私はあなたのために2つの非常に迅速なものを持っています。私は、最初の1つはスケールだと思います、私が印象的なことの1つは、パフォーマンスの一般的なテーマは、非常に大きく、非常に大きくなったときに考えるものになる傾向があることだと思います、非常に大規模で広範なテラバイトのデータ。デモを見ると、これは実際には非常に小さな環境にも当てはまるものであり、パフォーマンスが低下するようなものです。

これを理解する上でどのような広がりが見られますか？それは良いと思うと思いますか？それは良いツールだと思いますか？私の考えでは、そうだと思います。しかし、私はあなたが見ているものを見たいだけです。小規模な組織は同じ会話をしており、これを行うためのツールを探していますか、それとも本当に町の大きな端にあるのでしょうか？

Bullett Manale：おもしろいです。それはいい質問です。少々混ざっていますが、私たちには小さな顧客がたくさんいると思います。そして、私が小さな顧客と言うとき、つまり、管理するためのライセンスを取得するために1つから5つのインスタンスを購入するということです。さて、場合によっては、SQLのインスタンスが30個ある場合があり、それらの5つのインスタンスについて、このようなツールに投資するのに十分な、本当に重要な5つのインスタンスのみを本当に気にします。

しかし、現実には、小規模なショップでも、ほんの一握りのSQL Serverしかありません。ほとんどの場合、または多くの場合、その小さな店はデータベースの機能に非常に依存しています。そして、彼らはそうしません、彼らはそれを落とすことはできません。彼らは、ツールを持っている必要はありません。

そのコインの反対側は、それらの小さな店のいくつかでは、専用のDBAを持たないため、部屋で最も頭が良い男または部屋のより技術的な男は、割り当てられたDBAになります。したがって、そのような状況では、彼らは間違いなく何らかの助けを求めています。このツールは、明らかにその点でも役立ちます。

あなたの大規模な環境については、私が言ったのはDezだったと思います-またはロビン、私にはわかりませんが-大規模な環境では、DBAの数に驚くでしょう。膨大な数のSQLのインスタンスについて話しますが、文字通り、それらに責任を持つことを任されているDBAのほんの一握りがいます。ですから、その観点から、彼らは本当に助けになるリソースを十分に持っていないので、彼らはいくつかの助けを探しています、そしてツールはそのいくつかを相殺するのに役立ちます。

そのため、かなり多くのことを確認できます。200個のインスタンスを管理する3人の男がいます。そのため、このようなツールがない場合、問題がある場合でも把握するためのロジスティクスを想像できます。それは積極的な方法ではありません、私はあなたを保証することができます。うまくいけば、それがあなたの質問に答えるでしょう。うん。

Dez Blanchfield：そうですね 。ロビンはそれをほのめかしたと思いますが、デモを行ったときに説明している約束は、非常に大規模な環境に限定されるものではありません。ある目的のために設計された一般的な既製のプラットフォームを購入し、それを他の目的のためにデータベース共有環境に入れると、環境全体を罰するだけです。

私を驚かせた他のこと-それはそれほど質問ではなく、単なる観察ですが、私はそれを質問に導きます-それは、あなたが知っている、組織がすでにインフラストラクチャとプラットフォームとそのデータベース、サーバー、およびその周辺のインフラストラクチャ、そして、HR、ERP、BIツールなど、何であれ製品を購入しようとしています。彼らはすでにかなり大きな投資をしています。

人々と会話をし、パフォーマンスの問題があることに気付いたとき、どのような反応が見られますか？しかし、彼らは今、それを達成するためにさらに別の投資をしなければならないと感じていますか？デモを行った後、このことは非常に簡単だと気づく点がありますか。それはそれほど売り込みではありませんが、もっとひらめきです。ただ、「すぐにこの恩恵が見られるでしょう」というだけです。製品を販売するだけでなく、それはそれ自体を売っており、ROIはページから飛び出しているように思えます。

Bullett Manale：ええ、それはおもしろいことです。なぜなら、多くの場合、DBAや営業担当者などの誰かが来て、「ねえ、これらの人はそして、これについてのROIシートを参照してください。デモは常に10倍優れています。特に、DBA自身で行うことができます。

Dez Blanchfield：ええ。

Bullett Manale：あなたが言ったように、製品はそれ自体を売ります。紙にROIを付けて、「さて、DBAは通常1時間でクリック数を数えますか？」と言うのは本当に難しいです。、ええと？そして、それを紙に書き込もうとすると、それをするのは本当に難しいです。しかし、誰かを取得し、彼らに製品を見せ、彼らがそれを見るとき、それはまさにあなたが言ったことです。

人々はその価値を認識しています。なぜなら彼らが彼らが理解し、より良い意思決定をするのを助けるだけでなく、彼らが悪い男にならないようにするのも助けだからです。彼らは最初に知ることができます。問題があると特定される前に問題を修正できます。

それのもう1つの部分は、DBAとして、それが本物であろうと認識であろうと、そしてあなたが実際にパフォーマンスの問題を所有していると思うことです。あなたは、パフォーマンスが低下したときにあなたに指を向ける人です、そして実際は、実際に問題を引き起こしているのは開発者である可能性があるということです。

「ねえ、これは私の問題ではありません。これを開発者に持ち帰り、修正する必要があります」と言うことができるツールを持っているか、それらの線に沿って知っています。武器庫に何かを入れて、「これが本当の問題の場所です」と言うことができるのは良い方法です。

Dez Blanchfield：ええ。あなたにとって最後の1つであり、私が経験したときにこれを見て、私を襲ったのは、パフォーマンスの問題について考えるとき、特別なスキルを取り入れることが多いということでした。彼らは20年の経験があり、それを見て、エンジニアリングショップに足を踏み入れ、小さなハンマーを持ってマシンを正しい場所に当ててから言う男の古典的な冗談のようなものです、「これは15, 000ドルの修正です」と人々は言います、「私たちはそのためにお金を払っていません」と、あなたは知っています、それは仕事の5分だからです。そして、「まあ、5分間の作業で修正するには15年の経験が必要で、何百万人も節約できました」と彼は言います。

私には、中間のプロセスがあるように思えます。人々はこのことを経験し、「さて、特別なスキルを持ち込み、問題を修正し、消えます」と言っています。しかし、彼らがしたことはバンドエイドを貼っただけですよね？私がここで見ることができるものから、これがいつ入るのかというシナリオとは対照的に、はい、彼らは彼らが経験していると思ったいくつかのパフォーマンスの問題に対処したかもしれませんが、私にはちょうどそれが24 /環境をリアルタイムで監視している7種類の目。

レポートが実行されているため、DBAが午前4時に目覚めるというシナリオから実際に逃れることになります。それは事実であり、おそらく修辞的かもしれませんが、特定の問題を解決するために製品に投資することから人々がすぐに移行するのは事実ですが、それが一般的には単なるDNAの一部になりますか？

Bullett Manale：ええ、それは場所によって異なりますが、つまり、2006年に元々製品を購入した人がいます。彼らはさまざまな企業で3つの異なる仕事に就きました。彼らは入ってきて、その次の会社に行くとき、彼らはワークフローを持っているので、これを手に入れるものとして宣伝します。そして、それを呼び出すと、私はそれを呼び出すことを嫌いますが、あなたは知っています、そのワークフローはこの製品に関係し、彼らは日常的にそれに慣れており、それが彼らを助けるので、彼らは望んでいません新しい何かを学びます。

しかし、絶対に。つまり、ほとんどの場合、人々にこの製品をダウンロードさせるのは、予算があり、外出しているからではなく、「ねえ、まあ、このパフォーマンスの予算があります。通常、何が起こるかというと、彼らはSQLのインスタンスに問題を抱えており、彼らはいくつかの助けを探しています。その問題を修正します。彼らはツールをダウンロードし、問題を修正します。そして、これは、ツール自体が当時の問題を修正するだけでなく、実際に全体的なパフォーマンスを改善することに役立つことを認識しています。他の問題の発生を防ぎ、前進します。そして、それは確かです。このツールを使用して環境を継続的に調整し続けることができます。これは、現在何が起こっているかだけでなく、先週、先月、昨年何が起こったのかを常に確認し、起こっていることと比較できるためです明日。ええと？そのようなこと。

Dez Blanchfield：ええ。

Bullett Manale：それで、確かに。

Dez Blanchfield：完璧です。それで、あなたが言及した、あなたは何かについて言及した-私は私が閉じるためにエリックに手渡す前に、私はちょうどラップアップするつもりです。私がいつも興味を持っていることの1つは、あなたが知っているように、人々はどのようにそれを手に入れるのですか？あなたはそれをダウンロードすると述べました。インスタンスを取得するために、どのように手に入れ、コピーを取得し、それをスピンアップし、プレイし、インフラストラクチャーに必要なものかについての30秒の概要は何ですか？

Bullett Manale：そうなると 、IDERA（idera）.comにアクセスします。 IDERA.comは会社です。そのWebサイトにアクセスすると（実際にここに表示できます）、まだ画面を共有しているかどうかわかりませんが、[製品]ページに移動してから[診断]マネージャーのリンクには、小さな[ダウンロード]ボタンがあります。情報を入力したら、ビルドをダウンロードできます。彼らはあなたに32または64ビットのビルドを要求し、彼らが言うようにあなたはレースに出かけます。

Dez Blanchfield：それは誰かがそれで遊ぶためにラップトップ上で実行されますか、それともどこかにあるサーバーにロードする必要がありますか？

バレット・マナーレ：いいえ、いいえ。実際、今日お見せしたことは、すべて私のラップトップから実行することでした。現在、私のラップトップには32のギグと8コアプロセッサがありますが、それでもラップトップです。しかし、あなたの質問に答えるために、必ずしもそれほど多くのリソースを持っている必要はありません。評価自体は14日間有効ですが、長期間の試用を歓迎します。お電話をいただければ、ご希望に応じて延長できます。

Dez Blanchfield：それは奪うべきものだと思います。物の見た目から、私はそれをダウンロードして遊ぶのは簡単だと思います。おそらくあなたの環境の1つに行って、あなたが見ることができるものを見てください、なぜなら私はそれを疑います-私が老化する過去20年以上のデータベースの背景で見たすべてのもののように-フード、それはあなたがあなたがすぐに修正し、パフォーマンスの少しの利益を得ることができることを実現することを驚くべきことです。

素晴らしい、デモをありがとう。本当に素晴らしかった。質問について話し合ってくれてありがとう。

Bullett Manale：どういたしまして。についてありがとうございました-

Dez Blanchfied：エリック、お返しします。

Eric Kavanagh：ええ、観客から本当に良い質問があります。あなたはプレゼンテーションでこれについて話したことがありますが、私は実際にこのことについてツイートしました。あなたは、パフォーマンスに悪影響を与えるパフォーマンスを監視するツールを使用したくないと言いました。

バレット・マナーレ：そうです 。そのとおり。それはパフォーマンス監視ツールの一種の重要な部分であり、パフォーマンスの問題を引き起こさないということです。その通りです。

エリック・カバナ：そのとおりです。まあ、それはあざけりのようなものです-それはちょうどシステムに大混乱をもたらすことができる抗ウイルスプログラムのようなものです。つまり、放送にさまざまなテクノロジーを使用して、アンチウイルスプログラムが起動し、ストリームを切り詰めます。したがって、予期しないことが起こることがありますが、質問は、あなたが行った特定のコメントに関連しています。また、どのようなパフォーマンスヒットが見られますか？ 2％ですか、5％ですか、1％ですか？投げられる数字はありますか？

Bullett Manale：そうですね、この質問の難しさは、ご存知のとおり、以前話し合った議論の一部です。私はあなたに与えることができます-あなたの質問に答えるために、それは通常およそ1〜3パーセントです。しかし、私はあなたが監視したいものをツールに伝えることができる多くの方法を提供しています、私が必要だと思うより多くの説明がありますか？そして、それはそれに戻ります。実行中のすべてのクエリのサンプルを取得したい場合があります。そのため、それを有効にするのに十分な柔軟性を備えたツールを手に入れたいので、それを見ることができます。

そのため、柔軟性の一部にはコストがかかります。最後に実行されているすべてのクエリのサンプルが必要なため、さらにデータを収集する必要がある場合は、20分でそれを有効にできます。ですから、一般的に言えば、オーバーヘッドに関しては、1〜3パーセントが見られます。しかし、それは変化し、そのほとんどは、しきい値、収集するデータの量、ポーリング間隔、それらすべてに関係するものに関して、オンとオフを切り替えるものに依存しますそれ。

実際、管理しているインスタンス自体にアクセスすると、表示されるものの1つに、指定可能なポーリング間隔が複数あります。それは単に、すべてをチェックする必要がないからです。インスタンスでハートビートチェックを実行する場合、CPUとその他すべてをポーリングする必要はありません。 20秒ごとに実行します。したがって、指定できるポーリング間隔は複数あります。

また、私が言ったように、指定できるクエリモニタリングもあります。 And this can be done for each instance independently, so you can really cater to that specific instance in terms of what you want to monitor. For my wait statistics and wait monitoring, I can turn that on or off. And I can tell it to capture everything, I can tell it, you know, what I want to capture and when I want to capture it. So a lot of that will also– You have to take into consideration what you're doing, in terms of what you're telling the tool to monitor.

But generally speaking, what I would say, is, like I said, around one to three percent is what we see. We've been selling this tool a long time – since, like I said, about 2003 or 2004 – and we've got thousands of customers, so I can assure you that, you know, we don't have– we try our best not to cause performance problems in the name of performance.

Eric Kavanagh: Yeah, that's really good information. I just thought that was a brilliant quote because, you know, again, you don't want to defeat the purpose of what you're trying to accomplish, right?

Bullett Manale: Exactly.

Eric Kavanagh: And I appreciate Robin's question, too; this really is an excellent platform for helping DBAs understand the many different aspects and dimensions and layers of what we're talking about. And I think the concept of conversation with your data is highly appropriate here, because, to your point earlier, you're not gonna figure it out on the first try, usually. You need to spend some time looking at the data, looking at historical data, doing that synthesis in your mind. And that's the job of the human, right? The job of the profession that sits back there and takes heat from the business on a fairly regular basis, to get that job done and to keep the trains running on time, right?

Bullett Manale: Absolutely.

Eric Kavanagh: Well, folks, this has been another fantastic event. If any question you asked was not answered, by all means, let me know. Send an email to . We do archive all these events, so you can always go to InsideAnalysis.com to find the archive, or go to our partner, Techopedia.com. If you look on the right-hand side of their page, you will see Events, and the webcasts listed there. If you click on More Events, you can see all of the webcasts that we do listed there, past, present and future.

And with that, we're going to bid you farewell. We've got five more webcasts for the rest of this year, folks. We may schedule one more. But otherwise, it's going to be on to 2017. The ed cal is out. Let us know, and if you have someone that wants to showcase their technology, send an email to .

With that, we're gonna bid you farewell, folks. Thanks again for your time and attention, we'll talk to you next time. 気を付けて。 Bye-bye.