パフォーマンスプレイ：レイテンシーに別れを告げる

2024

Techopediaコンテンツパートナー

TechopediaスタッフはBloor Groupと提携しており、右側のオプションを使用して連絡できます。業界パートナーとの連携方法については、ここをクリックしてください。

プロフィール
ウェブサイト

エリック・カバナ：ご列席の皆様 、こんにちは。HotTechnologiesに再びようこそ！はい、確かに！私の名前はエリック・カバナです。これはTechopediaの良き友人たちとのパートナーシップである、私たちのHot Techショーです。 Techopedia.comにオンラインでアクセスして、幅広いエンタープライズテクノロジーの最新情報を入手してください。もちろん、それらも消費者のものをカバーしています。私たちはこのプログラムで企業に焦点を当てているので、それが今日私たちがやろうとしていることです。

あなたのことについて本当に本当に十分な場所があります。Twitter@eric_kavanaghで私を見つけてください。私はTwitterが大好きです。 -1つの会話。

それで、私たちは何について話しているのでしょうか？今年は非常に暑く、これは情報管理の世界で今日私たちが見ている機会の全体です。今日私たちが話しているのはクエリであり、クエリを高速化するでしょう。

「パフォーマンスプレイ：レイテンシーに別れを告げる」というタイトルを忘れていたと思います。遅延は誰も望んでいません。遅延とは、そこに座ってボタンをクリックし、何かが起こるのを待つことです。誰もそれを望みません。子供たちはそれを好まない、彼らはそれがクールだとは思わない、大人もそれを好まない。私たちは皆、ウェブの速度に甘やかされており、すぐに物事を望み、今すぐ物事を求めています。そして今日、ショーでそれについてすべて話します。

アナリストのマーク・マドセンは今日、私たちの常連の一人であるサード・ネイチャーから来ています。新しいデータサイエンティストのDez Blanchfieldがオーストラリアのシドニーから電話をかけます。そして、Bullet Manale、はい、それは彼の名前です。実際には2つのTであるはずです。 Bullett Manaleは、非常に興味深い会社であるIderaからのゲストとして多くのことをしています。私はすでに彼らについて知っています。そのうちの一つは、しばらく前にPreciseという会社を買収したことです。 Zohar GiladというCEOを知っていましたが、名前はどうですか？彼は賢い男の一体でした。

しかし、皆さん、このWebキャストでは、あなたが尋ねる質問で重要な役割を果たすので、恥ずかしがらずに、いつでも質問を送ってください。WebキャストコンソールのQ&Aコンポーネントを使用して行うことができます。右下隅にあります。私とチャットすることもできます。スピーカーとチャットします。すでにイタリアから電話がかかってきているので、「チャオ、チャオ。よし、マークの最初のラインをプッシュして、デッキをマークに引き渡そう。マーク、これでWebExができました。それを取り除いて、床はあなたのものです。

マークマドセン：ありがとう、エリック。私は途中から始めるつもりはありませんが、最初から始めます。 DezとIderaとの議論を設定するためのコメントをいくつかご紹介します。これは、開発とデータベースおよび運用に関する州の一種です。これを見てみると、開発者はDBAを面倒な人と見なしているため、データベースとアプリケーション市場にはまだこのような2つの世界の問題があります。データモデルを構築する必要があり、それにアクセスすることも、作成することも、データベースのすべてのテーブルのすべての列にインデックスを設定して高速化することもできません。そしてもちろん、なぜモデルが必要なのでしょうか？それは単なるデータ構造です。それらを変更した場合、シリアル化された形式で書き出すことはできませんか？

問題は、開発者がコードとアプリケーションを知っていることですが、彼らがしばしば知らない2つのことは、並行性、並行プログラミング、データベースとそれらの下にあるオペレーティングシステムです。カーネル開発者であり、オペレーティングシステムとデータベースであったため、同時実行性と並列性は非常に困難であるため、コードから優れたパフォーマンスを得るために学んだ多くのことは、実際に実行するとバラバラになり始めます。データベースでの作業。そして、パフォーマンスは素晴らしく見え、テスト環境は素晴らしく見え、Q&A環境は、実際のシステムに到達し、突然、それほど大きくありません。多面的であるため、コードがデータベースでどのように機能するか、環境でどのように機能するか、そして実際の単純な小さなプラクティスは、実行しているスケールに応じて劇的な効果をもたらします。

もちろん、外部アプリケーションについて話し始めると、外部に面したアプリケーション、Webアプリケーションは、物事が突然平坦化するまでは素晴らしいが、そうではないので、本当に難しい場合があります。理解するには多くのニュアンスが必要なこれらの興味深い台地にぶつかるでしょう。

物事の裏側はDBAビューです。 DBAの見解では、オペレーションがあり、80〜90％の時間を操作に費やし、10〜20％が前もって行われている開発関連のものを処理します。この観点から、今すぐ支払うか、後で支払うかのいずれかであり、すべての時間を前もって費やしている場合は、機能を探索する傾向がある開発とは対照的に、後でより良いチャンスを得ることができますスペース、そして物事を行うための最善の方法を見つけようとしています。そのため、問題があり、互換性のない方法論があります。継続的な展開、準備ができたらいつでもアプリをロールアップする、定期的にコードをプッシュする、開発運用を行っているショップで作業するなどです。この種のことは開発をスピードアップしますが、データベースに関するすべてのプラクティス、DBAが行うこと、およびシステム管理者が行うことを訓練されていることは、IT運用のプラクティスが追いついていません。

考えてみると、ほとんどのDBAは、継続的な展開環境ではなく、変更管理環境で動作しています。それは、変化の速度と可逆性に対する、安定性と制御に関するものです。継続的な展開、変更を取り消せない場合は問題が発生するため、すべてを簡単に可逆的かつコード切り替え可能に構築する必要がありますが、これはリレーショナルデータベース、開発プラクティス、および管理プラクティスが機能していない方法です。

また、問題について耳にするまでに10万人がWebサイトの苦情フォームに記入しているため、DBAとして可能な限り積極的に対処する必要があるという問題に直面しています。そのため、古い環境から抜け出せない新しいものが必要になります。監視と警告の改善などです。同時に、データベースは増加の一途をたどっており、これまで以上に多くのものをサポートするためのアプリケーションが増えました。それらは内部にあり、外部にあり、どこにでもあります。そして、分析のためのより独立したデータのセット、人々はデータベースを始めから始めています。もちろん、今では簡単に仮想マシンをセットアップできるからです。クラウドプロバイダーまたは内部クラウドを持っている場合、すぐに物事をポップアップできます。これにより、調達パス全体が変更されます。

古い調達方法は、「サーバーを取得し、ラックに押し込み、スペースを割り当て、ストレージを取得し、データベースをインストールして実行する時間がある」ということです。そうすれば、その最新の開発環境は非常に異なるペースで動作しているため、データベースを作成するのは簡単であり、これまで見たことのないような拡散の問題が発生します。そして、これは10年間続いています。これは誰にとってもニュースではありませんが、動作環境が複雑になったことを意味します。

クライアントサーバーの世界はもはや変化していないため、クライアントサーバー環境全体が本当に変化しました。当時はサーバーがあり、データベースがありました。何かがおかしいなら、どのサーバーに行くべきかを知っていました。ベストプラクティスは1つのデータベース、1つのサーバーだったので、そのリソースを管理する方法を知っていました。仮想化はそれを打ち破り始め、クラウドはさらにそれを打ち破りました。データベースサーバーと考えるものは単なるソフトウェアだからです。したがって、環境は現実的ではありません。それは現実の環境を含んでいるものであり、それはブレードのラックか、断片に切り分けられた大きなサーバーかもしれません、あなたは本当に知りません。

データベース管理とパフォーマンス管理に関するすべて、および1つのサーバー、または少数のサーバーといくつかのデータベースを使用した厳密な制御に基づいて構築されたデータベースは、すべてを制御することはできません。マシン上に座っていますが、帯域幅は仮想マネージャーによって簡単に分割できないため、すべてがメモリとCPUで問題ない場合がありますが、処理できないリソースでボトルネックになっています。あなたがそれを修正しようとすると、古いモデルは大変な仕事をして、より大きなサーバーを取得してそのようなことをしていましたが、今では本当に簡単になり、仮想コースを追加し、VMにメモリを追加するだけで解決します。しかし、VMが過密なサーバー上にあり、移行する必要がある場合はどうなりますか？または、AWSシステムのサイズで最大サイズに達した場合、どうなりますか？

したがって、環境がデータベースの一部であるこれらの問題はすべてあり、環境、データベース、すべての特別なリソース、アプリケーションのすべてが構成の一部であり、構成はそこにプッシュされます。これはデータベース環境からのものであり、管理と制御がはるかに困難です。

データベースセンターが何をしていたかを見ると、彼らは自分たちの手に座っていましたよね？データベースやサーバーをペットのように扱うというこのアイデアから離れてきました。サーバーには名前があり、それらは個別に固有のものとして扱われ、牛のように扱われ、群れを管理します。そして、群れを管理する際の問題は、もしあなたがそれらを制御しなければ、最終的に彼らは踏みにじられる可能性があり、踏みつけは良いことではないということです。より良い監視ツールが必要であり、このようなものに対処するより良い方法が必要であり、何が影響を受けているかを知る必要があります。古いモデルでは、opsとすべての制御システムがあなたに言ったので簡単でしたが、サーバー名がUPCコードの場合、物事を理解するのはちょっと難しいです。

誤った警告を出す余裕はなく、「このマシンに問題があり、そのマシンは30個のデータベースをホストしている」ということを言う余裕はありません。監視コンソールは点灯すると優れていますが、赤色のライトが再び緑色に変わり、その理由がわからず、その原因が何であるかを確認するために戻る履歴がない場合は、コンテキストは、あなたが困っている。私たちは私たちのために監視するシステムを必要とし、そのデータ履歴を維持する筆記体の断続的な問題に対処するより良い監視が必要です。

優れたものと単純なメトリックしきい値により、主要なメトリックを取得できますが、正常なもの、異常なもの、およびこれらの問題が発生する頻度に直接導かないでください。私たちが本当に話しているのは、環境の監視とパフォーマンスの処理の組み合わせであり、ベンダーは自分たちの手で座っています。彼らは私たちに良いツールを与えていない。私たちはすべてをどうするかを知っているよりも多くのCPUとメモリを備えたシステムを持っていますが、それでも私たちは手動介入モデルに頼っています、私たちは問題のポイントに到達するために私たちを導くためにマシンを動作させていません、「ここに問題があり、修正するためにこれを行うことができます」、または「パフォーマンスの問題があり、実際にはこの特定のSQLステートメントにあります」という新しいスタイルには到達していません。ヒューリスティックを適用し、システムの使用パターンを調べることができる機械学習モデルを適用して、問題を発見し、誤ったアラートを回避します。マシンを使用して、マシンの最善の機能を実行したり、DBAを強化したり、パフォーマンスの問題に対処する必要のある人を強化したりします。

古いスタイルとは対照的に、それは新しい方法です。このデータベースには問題があり、物事は遅いので、新しいテクニックと新しい方法があり、それらを適用する必要があります。それが市場の方向です。大規模なベンダーではなく、サードパーティの企業で発生し始めています。これは、20年前にデータベースベンダーがシステムの管理を支援する単一のものを提供しなかったときに起こったことを反映しています。それが市場の方向性のようなものです。それで、私はそれをエリックに引き渡したいです。

エリック・カバナ：申し分なく、私はそれをデズに引き渡します。そして、デズ、それを取り去ってください、床はあなたのものです。

Dez Blanchfield：ありがとう、マーク。あなたはその技術的なコンポーネントをカバーする素晴らしい仕事をしました。私は、ビジネスとその周辺のデータベースへの影響に関して、世界の他の地域で何が起こっているかを強調するために、少し異なる角度から説明します。最初のスライドにジャンプしましょう。

物事の技術面と開発者面からあなたが今取り上げたものの裏に、私はビジネスが特にデータとデータベースの課題に立ち向かわなければならないと思っています、そして明らかに我々はこの重要なシフトに向かっていますこのビッグデータの概念ですが、データベースは事実上、組織がビジネス情報を保持する場所の中心であり、フロントドアからバックオフィスに至るまでです。組織のあらゆる部分が何らかのデータベースに触れられ、データベースを活用しているため、プロジェクトの議論や、データベースまたはデータベースシステムのトピックに関する組織での革新的な戦略的会話に参加することはほとんどありません出てこず、今聞いたばかりの種類、パフォーマンスとセキュリティ、開発がこの課題にどのように近づくのか、データベースがどこに適合するのか、そして環境とアプリケーションの認識に関する質問が常にあります環境が話す、デバイスとモビリティはどうですか？

それはまだ非常にホットなトピックであり、現代の技術に関する限り、物事の壮大な計画の中で長い間長い間1つでした。その点まで、私たちが日々の生活、つまり私たちの日常生活で行うほとんどすべてのことは、現在何らかの形のデータベースによってサポートされているという事実だと思います。私たちの周りのすべてのことを考えるとき、それが私たちが買っているいくつかのサービスのために毎日郵送される請求書であるかどうかにかかわらず、それは必然的にデータベースと話しているシステムによって印刷され、私たちはそこにいます。私たちの電話には、連絡先や通話ログなどのデータベースがあります。

どこに行っても、トークの背後には何らかの形のデータベースと使用しているシステムがあり、ほとんどの場合、それらはかなり透過的ですが、事実はそこにあります。それで、なぜこれが非常に短期間でちょっとした問題になったのかをすぐにカバーしたいと思いました。最初は、データベースの概念はこの素敵な紳士、エドガー・コッドから来ました。 IBMで働いている間、彼はデータ管理の世界を、今ではリレーショナルデータベースと呼ぶ概念を作成することで変えました。

当初、データベースはデータベースであり、寿命は長く、列、参照など、テーブルの両方でかなり簡単でした。ソフトウェアの開発は非常に簡単で、パフォーマンスはそれほど大きな問題ではありませんでした–それは新しいエキサイティングなテクノロジーでした。何らかの形式の端末を介してデータベースにアクセスしましたが、メインフレームの3270端末と、他の種類の端末では必ず、他のシステムが登場して、大混乱を引き起こすことができます。そして、ほとんどの場合、古いスタイルの端末は、現在のWeb環境と非常によく似ていました。つまり、端末自体の画面にフォームを入力し、Enterキーを押すだけで終了します。要求として1つのパケットとして撃ち落とされ、バックエンドシステムがそれを処理します。これは基本的に最近のWebブラウザーで発生することです。Webブラウザーでリンクを入力すると、そのフォームは通常リアルタイムでシステムに戻りませんが、最近のAJAXでは、場合。

しかし、その後、何かが起こり、未来が到来し、最近ではインターネット、そしてほとんど昨日、秒Web 2.0で、私たちはモノのインターネットを手に入れました。そして、将来の出来事の過程で、データベースの世界が爆発し、データベースとのやり取りがデフォルトで行われたものになりました。購入のような何かをするためにどこかに行くということではありませんでした飛行機のチケットで、地球の反対側に移動したい場合、誰かが端末にすべての詳細を入力し、データベースにアクセスしてチケットを印刷する必要がありました。

Googleのタクシーをアプリケーションで呼んでいるかどうか、インターネットバンキングに飛び乗っているかどうか、私たちが日常的に行っていること、なんらかのシステムを使用して、データベースを活用していることなど、今私たちがしていることのほとんどすべてです。そして、インターネットが登場したとき、それは私たちにもたらすのが少し簡単になり、ウェブブラウザを介して私たちの日常生活、そしてウェブ2.0が登場し、物事がモバイルになり、物事の規模が爆発的に拡大しました。実際、このトピックでの私のお気に入りの行は、「インターネットがすべてをつなぎ、web 2.0がモバイルとソーシャルを実現し、物事が非常に大きくなり、今ではインターネットと物事、そしてIoTができました… Yikes !!」モノのインターネットがデータベースシステムにもたらす世界への影響を想像することすらしていません。

だから現代の用語では、私たちが端末として考えていたものは事実上これらのものになりました、それは携帯電話、さまざまな種類のタブレット、個人消費者用またはエンタープライズグレードの大画面タブレット、ラップトップ、そして伝統的なデスクトップです何らかの形で。その1つの画像には、現在使用しているデータベースシステムやアプリと通信するために使用しているほぼすべてのインターフェイスが表示されています。やや大きめのバージョン、iPad、その他のタブレット、Microsoft Surface、日常のラップトップへと至るまでの道のりです。人々は固定デスクトップではなくラップトップを手に入れる傾向がありますが、彼らは私の見解では現代の端末であり、データベースが開発だけでなく私たちの生活の管理パフォーマンスのあらゆる種類の課題を経験している理由の一部です。

ですから、それは、企業が今なお日々直面している最大の課題の一つだと思います。誰もがデータベースは私たちの唯一の問題だと思っていましたが、そうではありません。それで、大騒ぎは何ですか？まあ、私たちが商業的な意味からデータベースに関連するすべてのものを一方から他方に行くとき、Mark'sは技術的なコンポーネントを非常に非常によくカバーしましたが、商業的な意味では、組織としてデータベースについて考えます。私たちは、基本的な設計と開発のフロントエンドからすべてのものを扱っています。ビジネスが始まると、アプリケーションの開発、機能の開発、または既存のアプリケーションの何らかの形での実装についても考えます。何らかの形の設計と開発を行う必要があり、これらのデータベースシステムの実装方法、サポートと管理方法、パフォーマンスの追跡方法などについて、多くの検討を行う必要があります。

データベース環境とアプリケーションの統合、および現在提供されているAPIの種類、アクセスの種類は、ますます難しく、複雑になっています。日々の管理、サポート、バックアップ、これらも解決されたと考えていましたが、突然規模が大きくなり、物事がより速く動き、ボリュームが非常に大きくなりました。環境のサイズ、データベースシステムはトランザクションが移動する速度をサポートする必要がありました。

非常に高頻度の取引環境のデータベースについて考えてください。人間がそれを追跡する方法はありません。それは、高頻度の取引、売買、および取引量を行うために別のマシンのクラスターと戦うマシンのクラスターにすぎません。それらのトランザクションが発生します。 Netflix映画の早期リリースのような現代のシナリオを考えてください。数百、数千、または数十万、場合によっては数百万の人々が、映画が公開された直後からその映画を見たいと思っているかもしれません。その情報はすべて、データベースプラットフォームでキャプチャ、追跡、ログ記録、分析されます。

そして、私たちが現在住んでいる常時稼働の世界は24時間年中無休で、太陽を追いかけるだけでなく、真夜中に何かをしたい人が常にいて、営業時間は世界中の太陽を追いかけます。したがって、稼働時間と可用性はデフォルトで、現在の気候であり、実際に停止することは受け入れられるものではありません。そして、冗長性、パフォーマンスの問題がある場合、またはアップグレードやパッチ、またはセキュリティを実行するためのメンテナンスウィンドウが必要な場合、実際には、データベース環境を別の環境にカットし、シームレスかつ自動的に実行できる必要があります。

セキュリティ、標準、コンプライアンス、最近では特にGFCでかなり大きなことが起こりました。そのため、コンプライアンス、セキュリティ、標準に適合するために、さまざまな新しい課題に対処する必要があります。それらをリアルタイムで、理想的にはダッシュボード形式でレポートできるようにします。サルのチームを物事を探そうとするデータセンターに送りたくはありません。すぐにリアルタイムでそれを伝えるシステムが必要です。

そして、ほとんど誰も話さない2つの大きな楽しいものは、一般的に彼らを敷物の下に押し込み、彼らがeverい頭を上げないことを願っていますが、災害復旧とビジネス継続性-これらもそうすべきですほとんどの場合、必要に応じて自動的に行われます。

データベース環境で問題が発生する可能性があり、一般に人間が応答するタイプのことについて話すのに何日も費やすことができましたが、今ではそれを行うためのシステムとツールが必要です。 1つの例はデータ侵害です。そのため、データベースについて考えると、さまざまな形でこの質問を非常に率直に尋ねます。ボールから目を離すと、重大な問題が発生するとデータベースはどうなりますか。特に、パフォーマンスとセキュリティ、およびデータベースを実行する他の主要な側面を監視するシステムがない場合。

さて、これが起こる可能性があります。これは、過去2〜3年の最近の侵害のスクリーンショットです。常に、これらはすべてデータベースシステムからのものであり、常にセキュリティや制御、またはアクセスに関する問題があり、左上には1億5200万のAdobeアカウントがあります。それらの顧客のうちの侵害された。そして、インシデントを追跡してキャプチャし、セキュリティを制御する適切なツールの場合、盗まれた最初の数百のレコードが私たちに警告している可能性があります。次の1億5, 000万を止めました。

次に、この全体の旅の要点にたどり着きました。つまり、なぜより良いシステムが必要なのでしょうか？私の見解では、この点でもっと多くの死体を投げることができないのはなぜですか？私たちの見解の転換点を本当に超えており、確かに、より多くのDBA、管理者、より多くの人々を投げているという証拠があると信じていますこの問題は問題を解決しません。より良いツールのセットとより良いシステムのセットが必要です。

これが私がこれをサポートすると考えている上位5つの理由です。これらは、管理されている環境であるこれらの民間企業や州で見ているもの、データベース環境で直面している課題、そしてそれらを管理します。

セキュリティとコンプライアンス-ナンバーワン。誰がアクセスできるか、どこでアクセスできるか、いつアクセスできるか、どのくらいの頻度でアクセスできるか、どこからアクセスしたかを制御します。潜在的に彼らが実際に触れたデバイスと彼らが見たものの種類、そしてそれを巡るコンプライアンス。 30日後に人間にレポートを実行させて、物事が大丈夫かどうかを伝えることはもはや適切ではありません。それはリアルタイムで発生する必要があります。

パフォーマンスとモニタリング–簡単なことのように思えますが、常にそうではありません。オープンソースのツールを使用する場合でも、サードパーティの商用ツールを使用する場合でも、必要とされるパフォーマンス監視の種類、詳細、および時間内に対応する能力など、さまざまな方法で常に見逃していません。

インシデントの検出と対応–それは即座にリアルタイムである必要があり、常にそれを行うシステムが必要です。または、少なくとも迅速にアラートを出して対処できるようにして、発生するいくつかの問題に対処します迅速に、そして制御不能にカスケードしないでください。

管理と管理-繰り返しますが、これらの問題は解決されたと思いますが、そうではありません。データベースチーム、特にシステムが私たちのために面倒を見るDBAが直面する問題の目標は、まだその問題を解決していない、それはまだ本物です。

そして、設計と開発のフロントエンドから、これらのツールの構築を開始すると、データベース環境を構築し、開発およびテスト、および統合プラットフォームに適切なツールを投入できます。これは今でも私たちにとって簡単なことではありません。この旅の全体を通して、私たちは同じメッセージに駆り立てられています。私の考えでは、より良いシステムとより良いツールが必要です。データベース環境、つまり顧客から価値を引き出すビジネス。より多くのボディとDBAを投入し続けることはできません。スケールが大きすぎ、速度が速すぎ、ボリュームが高すぎます。それで、エリック私はあなたに戻るかもしれません。

エリック・カバナフ：大好きです。そこにはたくさんのグラウンドがあり、見込み客もたくさんいます。そして、すぐに彼らをキーにバレットに引き渡します。

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

エリック・カバナ：ああ、それを取り去りましょう、そしてバレット、今私はそれをあなたに手渡しています、そして床はあなたのものです。

Bullett Manale：よろしくお願いします。多くの良い点が指摘されたと思います。私たちは誰なのか、すぐにIderaについて話をしたかったので、すぐに飛び込みます。私たちが話しているこの多くのことを考えているツールについて話します。このツールを使用して、Diagnostic Manager製品について、これらが一致するいくつかの領域について説明します。

さて、私が最初にやりたいことは、Ideraが誰であるかについて少し背景を説明することです。私たちは2003年頃から存在しているため、SQL Serverツールだけで始めました。今日私たちが焦点を当てるのは、診断マネージャー製品です。しかし、ここにあるもののすべてを見ることができます。先ほど述べたように、最近、Preciseを買収し、買収を通じてEmbarcaderoも所有しているため、非常に優れた製品ポートフォリオを持っています。

SQL Serverの観点から見たパフォーマンスモニタリングの観点から、私が説明しているこれらのトピックを調整する、話したい製品はDiagnostic Managerです。今、これはIderaの時代の始まりのかなり近くから出回っている製品であり、2005年頃からその一部になれたことは幸運でした。そして、 SQL Server、物理から仮想への移行、発生したすべての種類、および環境の成長に伴うDBAのニーズ、およびそれらの種類。

私が始めたのは、私たちの製品の典型的なユーザーはDBAでした。ですから、私たちが初めて見込み客と話をするとき、それは大部分が話しているDBAです。 ITマネージャーやディレクターと話をしているのではなく、ある時点でそのレベルに到達するかもしれませんが、DBAに問題があり、DBAが問題を修正しようとすることが多くあります。その一部として製品をダウンロードして試用します。場合によっては、データマネージャー、DBA、または演技DBAを取得できます。さて、大規模なエンタープライズ環境に到達すると、明らかに、本格的なDBAを取得することになります。通常は、ツールを使用するDBAになります。そして、私は先に進み、ウィキペディアからここにちょっとした宣伝文句を追加しました。 Wikipediaが言うように、それはDBAの責務の一種です。それが彼らの仕事です。

ここのリストを読んで、これらの多くのことを読み終えるつもりはありませんが、あなたが考える典型的なものの多くを取得し、そのうちの1つで、あなたは監視していますデータベースのパフォーマンスを最適化することは非常に大きなことです。そして興味深いのは、DBAと話をするとき、彼らは常に最初に非難される人であり、それが問題になると、実際には彼らのせいではないかもしれませんが、パフォーマンスの問題があるとき、通常はアプリケーションでDBAデータベースに関連付けられており、彼らが責任を負うので、彼らは常に彼らのせいではない理由を探しています。多くの場合、このツールであるDiagnostic Managerを使用して、支援することができます。

しかし、結局のところ、データベースが実行されていない場合、この他の多くのものは実際には重要ではなく、アプリケーションは機能しません。そして、これらの多くにとっては本当に重要ではありませんもの。何よりもまず、ユーザーが私たちが知っている方法を体験することを確実にできるようにしたいと考えています。それは、DBAが常に目指していることです。そして、人々が通常SQL Diagnostic Manager製品を購入して使用する理由を見てみると、最初の理由の1つは、おそらく最も重要ではなく、最後ではないが、全体的には同等であると思います誰と話すか、これらの理由に応じて、それらのうちのほぼ1つまたは2つは常に存在し、何らかの種類のニーズがあります。

しかし、最初の方法は、インスタンスを管理しているSQLとして集中的に表示できるようにすることです。そして面白いのは、多くの場合、DBAに「あなたは何個のインスタンスを管理しますか？」と尋ねた場合、数が頻繁に変わるため、場合によっては本当にわからないことです。したがって、画面上にすべてを表示できる以上の何かが必要です。その情報を把握し、それを理解したいので、Diagnostic Managerが間違いなく役立つことの1つは、環境に対するそのようなビューを提供できることです。

そして、それは環境に対する単なるビューではなく、データベース管理者であるDBAが満足できるビューであり、DBA中心のコンソールです。データベース管理者向けに作られています。監視ツールはたくさんありますが、パフォーマンスツールはたくさんありますが、私が言ったように、結局、DBAはDBA用に設計されたツールを求めています。彼らの日々に。

つまり、SCOM、HPF、その他のすべてのテクノロジーを持っていますが、彼らは自分たちがしていることに特別な何かを求めています。私たちはこの分野でこの製品を手伝うことができると思います。すぐにこの製品に取り掛かるでしょう。 DBAで見られるもう1つのことは、間違いなく以前に触れたことの1つであり、明らかに、何が起こっているかを見ることができる必要があり、企業全体を見ることができる必要があるということです。そして何が起こっているのかを知って安心してください。しかし、同時に、彼らはそこに座ってコンソールを見つめていません。

あなたがそのリストで見たすべての箇条書きを覚えていますか？彼らは他のこともしなければならないので、火が消えるのを待つだけではありません。多くの場合、会議があるか、データベース管理者に関連するメンテナンスウィンドウの多くが夜中に眠っているときに実行されるため、戻って何が起こったかを確認する必要があります。。多くの場合、問題が発生したときに何かをキャッチしなかった場合、問題が解決した後、または少なくともSQL Serverを使用すると、それができない状況に対処するという問題になります。その問題の残りをもう持っています。そして、これらの問題はなくなり、残りの問題も解消されます。つまり、トラブルシューティングの手間が少なくなり、対処する情報が少なくなります。

そうは言っても、それは間違いなくDiagnostic Managerが支援できることの1つであり、過去の情報を照会するために過去のビューを提供することです。「ブロッキングのアラートがありましたか。デッドロックの問題がありましたか。私たちは戻って、その情報を照会することができます。特定の時点にドリルダウンできます。これらのすべてをツール内から直接行うことができます。

これらのすべては、内部アプリケーションであるか外部アプリケーションであるかに関係なく、DBAは問題の原因を確認できるようにするため、知りたいと考えています。コードを書いたのが組織内の誰かであるか、組織外の誰かであるかは、実際には関係ありません。彼らはまだそれを隔離したいと思っているので、彼らは問題が起こっていることを知り、どこから来たのかを知っています。

したがって、パフォーマンスと説明責任は、当社の製品の重要な部分です。これらすべての詳細を提供できますが、ドリルダウンする機能があるのはすばらしいことです。ボトルネックがある場合は、それをアプリケーション、ユーザー、データベース、クエリに関連付けることができます。そして再び、それは一種の喫煙銃です。このクエリを実行するタイミングと、それが何をしているのかを直接相関していますか？そして、それ自体で実行されるという点で、クエリ自体だけでなく、時間の経過とともにクエリが悪化しますか？そして、これらのことも製品で答えることができます。これは間違いなく何かを積極的にしようとしている場合、「ねえ、ここに悪い実行したクエリがありますが、少年はそれを見てください」と言うことができるのは素晴らしいことですさらに実行されると、さらに悪化していることがわかります。私はそれについて何かすることができます。」

ここで次のエリアに入ると、これはおそらく-私はこれが大きなものの一つだと思います。製品を展示する際に私が尋ねる質問の1つは、データベース管理者に「SQL Serverデータベースに関連する問題についてどのように聞きますか」という質問です。それは非常に面白いです。なぜなら、多くの場合、彼らは特定のニーズを解決しようとしているからです。しかし、SQL Serverの初期の頃は、SQL Serverを使用してからOracleを使用していたことを知っています。そして、誰もがOracleを使用していました。SQLServerは、最初の起動時に、より良い表現がなく、データベースの赤毛の継子であるようなものでした。

そして、Microsoftがより多くの機能を追加すると、それはもう少しエンタープライズツールになりました。そして明らかに、それはそれ以来長い道のりを歩んできました。しかし、ポイントは、かつてデータベースが重要であると考えられていなかったと主張することができるということです。そして、それは時間とともに変化します。そのため、多くの場合、人々はそれを回避しようとして、「あなたは何を知っていますか？これらすべてのSQL Serverデータベースを持っているので、それを処理しようとしています。」そして、ヘルプデスクから問題を聞いたり、ユーザー自身のような特定の人々から問題を聞いたりするのではなく、それを回避するいくつかの方法を探しています。彼らは、それらの状況が発生する前にそれを認識できるようにする方法を探しています。

ですから、Diagnostic Managerを使用すると、私たちもやろうとしていることの1つは、少なくとも、DBAがそれらの状況や問題について最初に知ることができるようにすることです。何かが起こったとき、またはそれをさらに一歩進めて、監視しているシステムを分析します。そして、そのインスタンスのパフォーマンスを改善する積極的なアドバイスを提供し、それを定期的に実行できるようにします。たとえば、ワークロードに基づいてインデックスを追加する必要があります。これらのタイプの物、同様にできるツール。そのため、ツールにはその多くが表示されます。

このリストにある他のことと最後のことは、より一般的な説明のようなものですが、間違いなく注目に値するものです。特に、多くのインスタンスが存在する大規模なエンタープライズレベルの状況に陥ると、データベース管理者である場合、私が監視したい不明瞭なことが常にあります。例。そして、私たちがやろうとしていることは、典型的なDBAが監視したいものの観点から予想しています。

それが言われていると、あなたはまたの面でできるようになるだろう-常に何か新しいものになるだろう。そのため、インストールポイントの追加後に監視および管理する必要があるメトリックを追加する方法を提供しました。したがって、PerfMonカウンター、WMIカウンター、SQL Serverカウンターオブジェクト。これらはすべてツールに組み込むことができます。ポーリング間隔に組み込むことができる追加のクエリを追加することができます。

また、注目に値する最後のことは、vCenterとHyper-Vの両方を追加し、実際に通信してそれらの環境からメトリックを取得できることです。 DBAで特定したことの1つは、それらが通常、特に操作の一部ではないということです。また、通常、vCenter環境、利用可能なvCenter環境、または利用可能なこれらの種類のものを必ずしも持っているわけではありません。

したがって、問題は、SQL Serverインスタンスを処理していて、リソースが割り当てられているが、そのインスタンスが仮想化されている場合、何を監視しているだけで、世界中にすべてのリソースがあるように見えることですゲストオペレーティングシステム上。現実には、ホスト上で、アクセスしようとしている他のVMが30、40、50、または100個あり、それらの同じリソースの競合が存在する場合があります。そして、実際にそれを確認する唯一の方法は、他の環境や、この場合はインターフェースと通信することです。

これらの他のタイプのカウンターをツールに追加することができます。今では、それらのカウンターを監視できるようになるだけでなく、製品に導入する新しいカウンターを作成できるようになり、すぐに使用できるメトリックのようにツールの一部にすることができます。すぐに監視したいもの。そのため、それらをダッシュボードに組み込むことができます。独自のカスタムレポートにそれらを追加できること、明確にしきい値を設定してアラートを出すことができることを意味しますが、ベースラインを作成し、ある程度の知識を持ってしきい値を設定できること、つまり、ベースラインと正常なもの。だから、あなたも製品にあるようなものがたくさんあります。

私があなたに提供したのは、私が「診断マネージャーのコア成果物」と呼んでいるものであり、先に進んで、製品に入ることでそれを少し味わうことができます。画面を共有して、これをドラッグします。これで、これがDiagnostic Managerのコンソールになります。前述したように、最初のコア成果物に移動して、エンタープライズレベルのビューのようなものです。ツールにはさまざまな例があります。サムネイルビューのようなものがあります。グリッドのようなビューがあります。 Webベースのコンソールもあります。Webベースのコンソールには、キーマップなどのような他のビューもありますが、ポイントは、物事を見て、見ることができるということです。しかし、問題が発生すると、ツールをさらに掘り下げて、特定の問題を実際に確認します。レム、そして何が起こっているのかを理解して知る何らかの方法があります。そして明らかにそれは非常に重要です。

今、過去に何が起こったのかを実際に見ることができるという点で。昨日、または1週間前に発生した問題を調べている場合、その状況では、特定のSQLインスタンスにアクセスできるようにする必要があります。また、製品内でその問題がいつ発生したかがわかっている場合は、履歴ブラウザに直接アクセスできます。そして、特定の時刻を指すことができます。それは数週間前から、昨日からかもしれません。しかし、カレンダーで選択した日が何であれ、異なるポーリング間隔が表示されます。この場合、4月20日の午後1時37分にコンソールを表示していた場合、実際に表示されていたものが効果的に表示されます。

そのため、時間をさかのぼることができます。その後、ここに表示されるさまざまなタブはすべて、特定の時点を反映します。ブロッキングのセッションがありました。そのようなものはすべてツールに表示され、その履歴情報を明らかに活用して問題を解決できるようになります。さて、そのメモについて、歴史について話しているとき、ここで注目に値する他のことは、問題を修正するために歴史を使用するだけではないということです。他の理由から、その歴史は明らかに非常に貴重です。そして、大きなものの1つは、適切な情報を使用して効率的に意思決定を行い、迅速に意思決定を行えるようにすることです。そのため、そのすべての履歴、収集しているすべての情報に対して、報告することができます。

誰かが私のところに来て、「この素晴らしい新しいアプリケーションを手に入れた。それは、私たちが知っているように世界を変えるだろう。ああ、それはデータベースを必要とする方法で、そしてまあそれは本当にペグする方法でそのデータベースがあるマシンのI / O。」入ってくることがわかっている場合は、その情報を活用して、おそらく収集の最後の7日間に基づいて、すべての運用サーバーのランキングを提供できます。そして、どのインスタンスがそのデータベースを使用するのが最も理にかなっているのか、すぐに結論に達することができます。したがって、明らかに非常に貴重なのは、その種の履歴情報です。

クエリ自体の観点から。クエリを見るという観点では、ツールでそれを行うためのさまざまな方法があります。クエリ待機ビューは評価できるという点で非常に役立つため、私が見たいのはクエリ待機ビューです。ボトルネックが発生している場合、その特定の特定のクエリに影響を与えているさまざまな領域のすべてを本質的に特定できるようにするため。クエリ自体とそのクエリの影響だけでなく、どのアプリケーションから、どのセッションから、どのユーザーからそれを呼び出したのか、そしてそのすべてを知っているので、明らかに、情報を見ることができます。リアルタイムで、しかし過去からそのデータを見ることもできます。それがここにあることの1つであり、スクリプトを開始しましたが、それがポップアップするのを待つ必要があります。

私たちがそれを待っている間、私はしたいです-そして私たちは時間が不足していることを知っているので、私は通知が事前であることを警告することについても少し話したいと思いました。先ほど言ったように、そのようなことについて話しているときは、先を見越して、警告を発するツールがたくさんあります。難しいのは、メールを送信しないことです。難しいのは、イベントログへの書き込みやSNMPトラップの生成ではありません。難しいのは、適切なタイミングでそのアラートをいつ送信するかを知ることです。そのため、「特定のインスタンスについてはどういうことで、そのインスタンスに関連する通常のことは何ですか？」

そのため、意味のあるすべてのメトリックについて、それらのメトリックをベースライン化します。実際にベースラインを表示し、現在設定されているしきい値を表示します。それから、もう1つの良い点は、この例ではしきい値をこの例では6と10に設定したことです。 6週間後、このインスタンスに戻ると、このベースラインは完全に変更される可能性があります。ベースラインを計算するときに行うことの1つは、デフォルトでは、ローリング7日間の計算です。そのため、常にベースラインの最新バージョンを提供しています。そして、そのベースラインがしきい値にシフトするとどうなりますか？この場合、基本的に「推奨されているしきい値は、おそらく正しく設定されていない、しきい値が表示されている場所、そして明らかにベースラインがどこにあるのかを確認している」という推奨事項を確認して警告することができます正常に発生していることについてアラートを受け取ることができます。」

したがって、正常な何かの症状を処理するのではなく、実際のしきい値が正しく設定されていない状況を特定することができます。そして、それによって明らかにできることは、アラートを受け取る場所に応じてしきい値を設定することです。それが本当に問題であるかどうかを調べるための調査ではなく、行動を促すことの方が多いことは知っています。そして、ツールの一部は、ベースライン自体と計算できるという点で非常に役立つと思います。

さて、この製品では、実際に複数のベースラインを持つことができます。さまざまな期間にそれらを設定できます。また、ベースラインに基づいてしきい値を動的に調整できます。これは、日常的に発生するSQL Serverインスタンスへの変更に適応するための非常に重要な部分でもあります。ここで、この場合、しきい値の設定の多くをカバーし、ベースラインを示します。しかし、実際のアラートに関する限り、Diagnostic Managerの優れた点である通知自体は、複数のアラートプロファイルを提供します。たとえば、午前2時から午前5時までのオンコールプロファイルがある場合、その時間範囲に固有のプロファイルを作成し、すべての条件と適切な設定をここで設定できます私の応答のために。

現在、応答に関することは、場合によっては、はい、私は電子メールを送信することができます、または私は発射してSNMPトラップを生成するか、イベントログに書き込むことができます。私たちにできることは他にもたくさんありますが、DBAと話をするとき、彼らが本当に気に入っているのは、ほとんどの場合、実行される作業の多くが反復的なものであるという事実です。問題がいつ発生するか、それを修正するために何をすべきかを彼らが正確に知っているものです。彼らはただ行って介入しなければなりません。したがって、環境が成長するにつれて、インスタンスが増えるにつれて、それを行うのがはるかに難しくなります。注目に値するツールでできることの1つは、条件を設定できることですが、その条件に基づいて、スクリプトを実行するための応答を設定したり、ジョブ、実行可能ファイルを実行します。そして、ポイントは、スクリプトを実行することに決めた場合、実際の情報が入力された、実行時のスクリプト内のパラメーターを使用できることです。

そのため、特定のデータベースに問題がある場合、スクリプトは、問題が発生しているデータベースに対してのみ実行されるように設計されます。そのため、自動化された方法で動的に問題に対処することができます。それでも、「問題がありましたが、修正された」という返信をメールで受け取ることができます。スクリプトが実行され、DBAとしては知っていますが、実際に介入して介入する必要はありませんでした。さて、プロアクティブであることについての同じメモで、明らかに「分析」機能という別の機能もここにあります。そして、これが行うことは、SQLのインスタンスに対して定期的なチェックを行うことです。また、場合によっては、探しているものに関してより深く掘り下げます。仮想インデックス分析などが実行されます。インデックスを追加しますか？インデックスを削除しますか？そして、これらすべてのことは明らかに私のパフォーマンスに役立つでしょうが、繰り返しますが、それはすべて先を見越して行うことです。ものが壊れる前に決定を下し、それをより良く実行できるようにすることです。そして、多くの場合、それがここでやろうとしていることです。

先ほど話していたQuery Waitsに戻ります。ご覧のとおり、ここには大きなスパイクがあります。先ほどスクリプトを実行して待機アクティビティを発生させましたが、前述したように、この情報を掘り下げることができる非常にユニークな方法があります。どのアプリケーションであったかを見たい場合; NoSQLアプリケーションからのものであることがわかります。関連付けられているデータベース、セッション、ユーザーを確認でき、必要に応じて、待機時間の観点からこれをランク付けできます。それで、私は、その時間枠で起こっていたすべての待機の中で、どれが最も起こっていたと言うことができますか？そして、それが最も多く発生したときに、本当に素晴らしいことは、その待機タイプにドリルダウンし、すべてのコマンドを表示できることです。ここを見ると、彼らはその待ち時間を発生させていました。また、主に、それがどのアプリケーションであったかが、その待機を発生させていたことを確認できます。

それで、それは痛い親指のように突き出ます。「これがボトルネックの原因となっているアプリケーションです。実行されたクエリは何でしたか？どのユーザーが実行しましたか？どのデータベースに対して実行されましたか？」などとすぐに言うことができます。また、データベースに関連しているため、環境内に遅延がないことを確認するという点でも役立ちます。これが役立つことを願っています。この時点で先に進み、それを返送します。そこから続行できます。

エリック・カバナ：もちろん。だから、私はちょうどその日の専門家にそれを投げるだろうと思います。マーク、最初にコメントをして、いくつか質問をしたいかもしれません。その後、Dez、チャイムできます。

マーク・マドセン：はい、ありがとう、私はこれのいくつかを本当に楽しみました。私が見慣れているよりもはるかにインテリジェントな監視です。この背後にあるデータの管理に興味があります。追跡できるメトリックの管理、そしてあなたが知っているように、ダッシュボードで、特にベースラインのシフトなど、私のペットの問題点の1つであるものを探します。そのデータをどのように処理しますか。その2番目の部分は、シフトのようなベースラインメトリックスです。しきい値を自動的にシフトする機能があるので、その必要はありません。ベースラインが変化したときに、手動でしきい値をリセットしますか？

Bullett Manale：あなたはそうしているので、それについての良いところはあなたがそれを決めることができるということです。どちらでもできます。しきい値を設定して静的な設定にすることも、「これを動的なしきい値にして、ベースラインが変更されると変化する」というボックスをオンにすることもできます。また、デフォルトウィンドウを設定する機能とツールがありますしかし、必要に応じて、たとえば午前2時から午前5時までのメンテナンスウィンドウなど、別のベースラインウィンドウがある場合があります。 CPU、ドライブ、その他すべてがメンテナンスのすべてを行っているためです。そうすることを選択した場合は、自動的にしきい値を調整して、これらのメトリックの通常の範囲外になります。基本的には、ツール内でベースラインウィンドウである時間ウィンドウを設定する機能があり、各ウィンドウは個別のエンティティとして扱うことができます。動的なベースライン調整を行うことができます。また、ベースラインのウィンドウをいくつでも追加できますそれが理にかなっている場合、あなたがする必要があります。週末の時間帯、勤務時間中の平日時間帯、深夜に行われるメンテナンス時間帯などを設定できます。

マーク・マドセン：ありがとう。

Bullett Manale：質問の最初の部分に戻って、この情報をすべて収集し、収集していると思います。アーキテクチャについてはあまり説明しませんでしたが、バックエンドリポジトリがあり、そのデータの保持を完全に制御できますが、深夜に実行されるサービスもあります。すべてのベースライン計算を行い、そのデータを取得し、収集し、それを理解します。そして明らかに、それに加えて、特定のメトリックについて、ベースラインに対してレポートするために使用できる多数のレポートもあります。さらに、異なる期間の同じメトリックについて、同じサーバーのベースラインを比較することもできます。差異が発生したかどうか、またはデルタとは何かを確認できます。これらのタイプのオプションもたくさんあります。

エリック・カバナ：デズ。

Dez Blanchfield：簡単な質問が1つあります。このツールで何ができるかについては、幅広いスペクトルがあります。現在、開発の初期段階でそれを使用することに関心がありますか、それともまだ主に本番環境ツールですか？言い換えれば、開発者は開発の初期段階からアクセスして使用し、統合フェーズをテストしていますか？それとも、実稼働環境でまだ主に使用されていますか？

Bullett Manale：私は、ほとんどの場合、実稼働環境でそれを見ています。それは状況に依存しますが、ほとんどの場合、主に実稼働環境と言えますが、開発環境とテスト環境では価格が異なるため、もう少し魅力的です。それらの環境でそれを使用している人々を見ていますが、何らかの方法で答えを提供しなければならなかった場合、私は私たちが人々がこの製品に投資するのを見ているのは主にまだ本番環境であると言います。

Dez Blanchfield：確かに、そうです。明らかに異なるワークロードがあり、実際の作業がすべて行われるのは仕事が重いため、異なる価格設定ポイントがあることを聞くのは興味深いことでした。しかし、私は多くの組織、特に政府、そして確かに防衛の組織を見ています。そこでは、開発は現在、実稼働環境と同じレベルのツールとシステムへの投資を得ています。たとえば、防御には、数十億のテスト、アプリケーションおよびシステムとツールで数千億のテストを実行し、統合テストに進む前にそれらを監視するチームがあります。構築されたコードとデータベースがあることを確認したいからですそれの下に座っています。百万回のイテレーションか何かに到達しますが、フィールドで誰かに射撃している間、それは「強打」されません。

Bullett Manale：もちろん。

Dez Blanchfield：私の経験では、データベース環境はデータに残っているだけで、一部の人は知っていると思いますが、昔のデータベースの世界では、ほとんど見られず、ほとんど語られていません。アプリは、特に分析プラットフォームを使用して開発されており、現在は携帯電話とデバイスに搭載されています。単なる純粋な技術者とは対照的に、クライアントがデータベースのパフォーマンスとデータベース管理についての会話をより日常的な議論に取り入れているのを見ていますか？そして、主にあなたがDBAと話していることをあなたが以前に言及したことを知っていますが、今では一般的な語彙にある傾向があります、あなたは彼らがこれらのトピックを議論している人々を見ていますか？

Bullett Manale：それは言うのが難しいものです。つまり、私がほとんどの部分で言ったように、とにかく販売プロセスに関して私たちが扱う人々は、DBAである開業医と一緒です。あなたの質問に関しては、「一般的に、IT組織内の人々は、データベースをもっと意識するようになっていますか？」と言っているのでしょうか。質問だと思います。おそらく答えは「はい」でしょう。私は、現在の場所に基づいて、日々それをあまり見ないでしょうが、あなたの質問を理解しているなら、それが私の答えだと思います。

Dez Blanchfield：はい、大丈夫です。おそらくあなたの世界でのあなたの主な関心は物事の技術的な側面であるため、それはおそらくロードされた質問です、申し訳ありません。私は日々の活動で、組織がこれを非常に早い段階で会話に取り入れ始めていることに興味があります。したがって、彼らが新しいイニシアチブ、新しいプロジェクト、新しい作業プログラムについて話しているとき、すぐに来ることの1つは、「どのようにそれを監視し、どのように追跡し、発生した問題にどのように対処しているのか、立ち上げとは対照的に、ライブになりますか？」

バレット・マナーレ：私はそう言うでしょう–

Dez Blanchfield：すみません、 どうぞ 。

Bullett Manale：言うべき傾向があると言っていました。過去に何度も「問題があったので、今はツールが必要です。」そして、それが理にかなっている場合、問題が発生する前にツールを配置することについて、もう少し受け入れられていると思います。「監視ツールが必要です。何かが必要です。」そして、先ほど言ったように、DBAと新しいインスタンスを追加するには、それを管理するものが必要です。それを管理するのに役立つものが必要であり、そのため、この製品についても多くの支持を得ているのです。

Dez Blanchfield：簡単な質問です。これはどこに住む必要がありますか？ LANのバックバーン、データセンター内、データベース環境に可能な限り近い場所に配置する必要がありますか、それとも、クラウド内のどこかに、ある種のサードパーティクラウドを快適に配置しますか？ VPNトンネルか、さまざまな環境へのリモートアクセスか。環境と監視に関する限り、どこに座る必要がありますか？

Bullett Manale：アーキテクチャに関しては、バックエンドリポジトリがあり、それはSQL Serverデータベースです。ファットクライアントまたはシンクライアントのいずれかになるコンソールがあります。両方のオプションを提供します。また、モバイルデバイス専用のシンクライアントもあります。しかし、これが実際にどこにあるかという点では。それは環境に収まることができますが、実際にそれが難しいのは、収集する必要のある多くの情報から、場合によっては、または多くの場合、管理者権限が必要です。今、私たちはあなたにそれをさせません。必要に応じて、データを収集できます。収集できないものについては、管理者権限がないため、選択した場合はその情報が表示されないようにします。

フレーバーにもよりますが、AWS、一部の環境について話している場合など、他の環境よりもうまく機能しますが、実際の環境自体に関しては、通常、SA認証を使用してインスタンスに対するデータを収集することが必要です。または、それが信頼されていないドメインである場合、通常はそれを行いたいのですが、複数のドメインがあります。それらの間に信頼がある限り、それらに対して収集することができます。 LAN上にあるかWAN上にあるかは問題ではありません。実際の収集自体は、収集するデータの量に関してはごくわずかです。十分なサイズのWAN接続があれば、それは問題ではありません。私は、米国中にSQL Serverがあるブランチがある環境を見てきました。そして、それらはそれぞれ異なる場所にある1台のサーバーであり、彼らはそれを一元的に監視しています。トリッキーな部分は、それを行うための適切な接続性を確保することです。うまくいけば、それがあなたの質問の答えになると思います。

Dez Blanchfield：絶対にそうです。ありがとうございました。それで、今朝参加者から出てきた2つの簡単な質問。 1つは、影響です。システム監視ツールは、物事を監視するだけで負荷を生成することがよくあります。そのため、残念ながら、今では画面からスクロールしてしまいましたが、言い換えれば、監視することで、負荷が発生しますか？環境を監視するだけで、ツールの測定可能な影響はありますか、それとも無視できる影響ですか？

Bullett Manale：データをプルバックするにはSQL Serverインスタンスにクエリを実行する必要があるため、常に少しの影響があります。あなたが言ったような質問は、「それは無視できるか、重要ですか？」です。インスタンスを指している箱から出して、それはごくわずかです。私が言ったように、私たちはこれをかなり長い間行ってきました。 20, 000を超える顧客があり、パフォーマンスに重大な影響を与える場合はビジネスにならないことを保証できます。そうは言っても、ユーザーが監視したいものを決定することもできます。言及するべき重要なことは、すべての環境が少し異なるということです。

例として、クエリ監視コンポーネントを使用すると、実行できる機能の1つとして、正常性の境界と見なすもののしきい値を設定できます。そのため、クエリの実行時間に基づいている可能性があります。 CPU、I / Oに基づくこともできますが、例として、実行時間をゼロミリ秒に設定したとしましょう。事実上、ツールに実行するよう指示しているのは、最後のプル間隔以降に実行されたすべてのクエリを収集し、同様に履歴コレクションの一部にすることです。

これを行うと、最後のポーリング以降にボックスで実行していたクエリの量を収集します。これは選択的であり、ユーザーはそれを行うことができます。「それはあなたがすべきこと」と言うのですか？いいえ、しかし、その情報を収集できるデータのサンプルが必要な場合に、それを行うオプションも提供します。使いやすいものに基づいて設定し、希望どおりに調整するためのツールですが、必要に応じて実際に開くことができ、必ずしも定期的ではない多くの追加情報を収集することができます理にかなっている場合は収集します。

Dez Blanchfield：はい、 もちろんです 。少し時間がかかっていることは承知していますが、締めくくる前にあなたに投げたい本当に素晴らしい質問が2つあります。どちらも私に直接来ますが、それらに答えれば最高だと思います。通常、質問は「既存のシステムの知識に関するツールの範囲はどのくらいですか？」でした。これを接続するだけで、そこにあるプラットフォームを自動的に検出し、そのプラットフォームの正常な状態をすぐに知ることができます。マークが以前話していたように、プラットフォームの基本的な知識の一部は、Microsoft Dynamicsである可能性があることを知って、私は知りませんが、プラットフォームの知識の範囲は何ですか？ビジネスの周りで使用されている現在の市販のツールのいくつかで？

Bullett Manale：一般的に言って、SQLインスタンスに関するデータの収集を開始するとき、しきい値とそれらが設定される場所に関して、最初からベストプラクティスに従って作業していると思います。とはいえ、話をしている人は誰でも、ベストプラクティスに関しては、すべての環境が異なることも認識しています。最初に行うことはデータを収集するだけであり、ユーザーが行うことをお勧めすることです。必要に応じて、14日間製品を試すことができます。しかし、約2日後、ベースラインデータが表示されるようになります。動作するのに十分なサンプル情報が得られると、ベースライン、範囲の場所、およびそのようなすべてのものに関するコンテキストの提供を開始します。その後、必要に応じて、収集されたその情報からしきい値を自動的に設定できます。しきい値のシフトを開始できるように、正常なものを判別し始めるには、最初の収集とポーリングが少し必要です。

しかし、私が注目すべきことは、これらのしきい値を変更すると、インスタンスのグループごとに実行できることです。 1つのインスタンスに固有の場合もあれば、すべてのインスタンスに対して実行したり、テンプレートなどを作成したりすることもできるため、「これは実稼働インスタンスですが、これが欲しいテンプレートですそれに割り当てます。」そして、新しい本番インスタンスがオンラインになると、同じタイプのハードウェアを持ち、通常は同じワークロードを持つため、それらのしきい値を自動的に適用します。そのようにすることもできます。質問の面で役立つことを願っています。

Dez Blanchfield：絶対にそうです。実際、あなたは実際に私に届いた別の質問に答えました。それは「試用版のダウンロードはありますか？」でした。それに答えることができます、私は知っています。無料でダウンロードできることを確認していただけると思います。ウェブサイトから14日が経過したとおっしゃっていたと思います。あなたはそれをダウンロードして、それで遊ぶことができます。「試用版を実行するにはどのような環境が必要ですか。ラップトップで実行して試用できますか、それとも本当にサーバーが必要ですか？」

Bullett Manale：必要な主なものは、2005年以降のSQL Serverデータベースであるリポジトリです。それ以外にも、最小限のリソース要件、.NET要件があり、それだけです。したがって、製品をインストールしてデータベースを作成するだけです。

Dez Blanchfield：完璧です。私はもう時間がないので、私はあなたに投げかける最後の質問ですが、すぐに約2〜3人が私に尋ねました、「私は実際に立ち上げて実行できるようにDBAになる必要がありますかこれ、そしてそれで遊びますか？」

Bullett Manale：いいえ。DBAであれば、このツールのさまざまな用途があるでしょう。つまり、経験豊富なDBAであれば、おそらくもう少し価値があるでしょう。このツールをさらに深く掘り下げて、活用できるようになるでしょう。しかし、新しいDBAとして、またはDBAではない人としても、多くの推奨事項があります。私は今、そのページにいます。これらの推奨事項は定期的に出されますが、推奨事項について本当に素晴らしいことは、推奨事項が作成される理由を提供することです。しかし、それに加えて、外部コンテンツへのリンクもあり、これらの推奨事項が作成されている理由についてより詳細に説明しています。したがって、外部のMicrosoft Webサイト、ブログ、およびそのようなあらゆる種類のものにリンクされます。

しかし、あなたの質問に答えるのは、あなたが上級DBAであるなら、おそらくここに何かがあるでしょう、あなたはおそらく初心者DBAとしてではないということを利用するでしょう。しかし同時に、それは一種の学習ツールでもあります。これらの推奨事項を検討する際に、推奨事項を使用することでこれらのいくつかを独自に取り上げ始めるからです。

Dez Blanchfield：素晴らしい。ありがとうございました。デモ部分は本当に楽しかったです。プレゼンテーションは素晴らしかった。デモは素晴らしかった。すぐに記憶から、あなたのウェブサイトにリソースセンターがあり、人々にも見てもらうことをお勧めします。昨夜、詳細を知るためにその夜を過ごしたことを覚えています。ブログやデータ、会話から、メモリから製品ドキュメントの大部分をオンラインで取得できるようになりました。

Bullett Manale：はい、それは正しいです。あなたが参照していると思うフォームは、community.idera.comのWebサイトです。そして、私が言及したいことの1つは、以前に「環境を認識しますか？」新しいインスタンスまたはインスタンスの追加に関しては、インスタンスの検出を行う別のツールがあります。そして、それは在庫と在庫の管理に関するすべてです。実際にインスタンスを発見するという観点から、そのような方向にあなたを指し示すだけです。しかし、実際にパフォーマンスと監視に関する限り、私たちが話し合ったすべての種類のものは、診断マネージャーが出番する場所です。

Dez Blanchfield：素晴らしい。見て、すばらしい報道。プレゼンテーションは本当に楽しかったです。ライブデモが大好きで、これが今朝の私からのすべてです。エリック、お返しします。

エリック・カバナ：わかった。デモがとても気に入りました。デモをしてくれてうれしいです。私たちがQ&Aを行ったときに、それをよく一生懸命見てみることができて嬉しいです。

Bullett Manale：すばらしい。

エリック・カバナ：これは人々にあなたが見ているもののアイデアを与えてくれるので、あなたがそれを理解するとき、これらのコンピューターと話す方法についてまだ学んでいると思うのは本当に驚かされます。つまり、このレベルの診断はかなり洗練されており、日々改善されています。実際に何が起こっているかについて、より多くの洞察を得ています。しかし、あなたは本当にこのことを見落とし、それを読んで、その認識能力をあなたがしていることの後ろに置く人を本当に必要としますか？

Bullett Manale：はい、私は多くの場合を意味します-これは箱の中のDBAであると伝えたいと思いますが、あまりにも多くのことが起こっています。つまり、私たちはガイダンスを提供し、支援しますが、最終的には、提示するデータについて人々が意思決定を行う必要があります。私はそれがすぐに変わるとは思わない。

エリック・カバナフ：それは実在の人々、人々にとって朗報です。

バレット・マナーレ：そうです。

Eric Kavanagh: You're going to want to have someone watching this, a team watching this, and you'll learn, as you've heard from Bullett here, looking at these recommendations you're going to pick up what's going on. And I'm guessing from that history, and I think you've touched on this, Bullett, but very quickly, that history allows you to recognize significant patterns and then therefore be able to identify them when they happen in the future, right?

Bullett Manale: That is correct. One of the things we can do is track a query's performance over time. We can also obviously look at other things, like baselines and see them shifting, and obviously get alerts and things like that when that happens, so you definitely have that ability.

エリック・カバナ：いいですね、皆さん。 We wouldn't have been long here, but I wanted to get to those questions. ご清聴ありがとうございました。 We do archive all these webcasts. Hop online to Techopedia.com or to InsideAnalysis.com, you'll see links from both places.

And with that, we bid you farewell. Thanks again, folks, we'll catch up to you next week, three more webcasts next week, Tuesday, Wednesday, Thursday. So we'll talk to you next week, folks. 気を付けて。バイバイ。

Techopedia Content Partner

Techopedia Staff is affiliated with Bloor Group and can be contacted using the options on the right. For info on how we work with industry partners click here.