取り除く： ホストのエリック・カバナは、ホット・テクノロジーズの最新エピソードで、ロビン・ブロア、デズ・ブランフィールド、およびバレット・マナーレとデータベース管理とインスタンス発見について議論しています。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ： よろしくお願いします。おかえりなさい。私の名前はエリック・カバナです。物事は暑いです。ここで物事が熱くなっています。何が起こっているのか分かりません。ああ、そうです、Hot Technologiesの時間です。はい、確かに、私の名前はもう一度、エリック・カバナです。 @eric_kavanaghで私を見つけることができます。これは、市場で注目を集めている番組について説明するための番組です。今日のタイトルは、「王国への鍵：Dynamic DiscoveryによるSQL Serverの管理」です。本当にあなたのものがあります。さて、その写真は数年前のものです。私はうそをつくつもりはありません、私はもう少し年上に見えますが、それは大丈夫です。
ですから、テクノロジとSQL Serverがどのように本当に、本当に、本当に、本当に暑いかについて話しています。今日はたくさんのコンテンツがあるので、すぐに引き渡します。待って、行きましょう。スピーカーがいます。そして、Robin Bloorが最初になります。
ロビン・ブロア： はい、そうです。プレゼンテーションはデータベース管理に深く入るので、人々をその精神に引き込むために、データベース管理、またはデータベースの迷路を実行すると思いました。私はDBAでしたが、約20年前にデータベースコンサルタントであったと言うことができると思いますが、実際にデータベースについて驚かされるのは、あまり変わっていないことです。データの量などの点で、速度の点で多くのことが変化しましたが、実際にはその多くは以前とほぼ同じままです。
データベースは、私の意見では、特定のワークロード向けに最適化され、データ管理機能を提供できる、組織化された拡張可能なデータのコレクションです。ファイル内のデータを管理したい場合、それは非常に困難な仕事だったため、主に存在しました。そして、1970年代にIBMメインフレームへのランダムアクセスができるとすぐに、必要なことはほとんど何でもできるソフトウェアをまとめるというアイデアがほぼ瞬時に始まりました。
リレーショナルデータベースは70年代に発明され、80年代のプロトタイプの観点から存在し、90年代の初めから市場で牽引力を獲得しました。そして、リレーショナルデータベースの人気は今なお完全に支配的です。新聞を読むと、SQLデータベースに関する非常に多くのことを聞くことができます。最近は、グラフデータベースに関する非常に多くのノイズがあります。必要に応じてこれらは興味深いものですが、実際にはまだ最新の販売数のままで、リレーショナルデータベースは市場の95％を占めています。また、今日詳しく説明するMicrosoft SQL Serverは、Oracleにとって2番目に人気があります。
リレーショナルデータベースに関して、それらが存在するエンジンの観点から珍しいのは、OLTPとクエリワークロードの両方で動作できることです。それを行う場合は、それらを別々に調整する必要がありますが、実際には両方のタイプのワークロードに対応しています。 1つは短いランダムトランザクションで、もう1つは大量のデータにまたがる長いクエリです。代替のNoSQLデータベースとグラフデータベースは、主に分析用であり、かなり最近になって登場しました。 NoSQLが最初に登場し、最近ではグラフが注目を集め始めています。 NoSQLはトランザクションアクティビティに使用できますが、グラフはトランザクションアクティビティにはほとんど使用されません。その理由は、ソフトウェアの在庫を見ると、ほとんどの企業が少なくとも3つ、実際には3.5の異なるブランドのデータベースを持っていると言う、実際には少なくとも10歳だと思う統計に出くわしました。
しかし現実には、ほとんどの企業は特定のデータベースを標準化しています。また、ほとんどの企業は、SQL ServerとOracleのいずれかを、必要に応じて標準データベースで最も人気のある2つとして標準化しています。また、たとえば、異なるデータベースを必要とするソフトウェアパッケージを取得している場合や、存在するビッグデータ分析ターゲットのいくつかを追跡している場合など、例外的な状況でのみ代替を使用します。
必要に応じて、Hadoopの干渉もあります。何らかの形でHadoopはファイルシステム以上のものになりましたが、まだデータベースではありません。ただし、その上にあるSQLがあります。しかし、そこにある証拠は、それが実際に取って代わるものではなく、世界の心をつかんだリレーショナルデータベースに取って代わるものではないということです。そして、その理由は、それらのリレーショナルデータベースが20年以上かかっており、実際には20年以上かかっていたからです。そして、非常に短い時間で本当にパフォーマンスの高いクエリエンジンまたはSQLエンジンを構築するだけではありません。それは起こりません。
したがって、このスライドの結論は、データベースは戦略的であり、進化し、改善されるということです。そして、OracleとMicrosoft SQL Serverでも確かにそうです。おそらく、データベースが最初に登場した当時のことを覚えている人はほとんどいませんが、私はそうしましたが、私は当時少年でした。元のアイデアは、単一のデータベースが存在することであり、それは絶対に根付かない概念的なアイデアでした。 IBMがAS / 400で実際にデータベースベースのファイルシステムを使用しようとしましたが、どちらも支配していませんでした。データベースは自然に断片化するという事実が残っています。実際には複数のインスタンスがあります。スケーラビリティの問題があります。データベースは特定のサイズにのみスケーリングされ、そのサイズは長年にわたって増加していますが、制限がありました。
また、ワークロードの問題がありました。ワークロードの主要な問題は、OLTPワークロードと大規模なクエリワークロードが相互に互換性がないことです。そして、それを行うエンジンを構築することは不可能でした。私たちが遭遇したことは、ちょっと面白いですが、最近、Oracleの1000を超えるインスタンスを持つサイトに出会いました。 DBAの数を正確に思い出すことはできませんが、DBAが実際に監視しているデータベースの数について実際に話した場合、10人のようでした。彼らは基本的にデータベースを食器棚として使用しており、少なくともあなたがスキームを持ち、ファイルシステムよりも組織化されていたので、データを投げ入れていましたが、デフォルトの設定を与えて設定する以外は何もしていませんでした緩い。
それが良いアイデアであったかどうかはわかりません。私の意見では、データベースを操作するときはいつでもデータベースに参加する必要があり、あなたは何らかの形で何が起こっているかを正確に知る必要があるため、正直に言って奇妙に聞こえます。また、システムの相互依存性が非常に大きいため、特定の種類のサービスレベルを必ず満たす必要があります。そうしないと、問題が発生します。
最近話がありましたが、私は自己調整であると主張するさまざまなデータベースに出会いました。クエリトラフィック用にセットアップされた列ストアであるものは、インデックスに関して非常に2つの選択が必要なため、主に自己調整されます。ただし、その特定の領域を除いて、データベースを調整する必要があります。また、主に非常に多くのトランザクションが結合を伴うため、特定のリレーショナルデータベースを調整する必要があります。結合は高価なアクティビティです。適切なインデックスを適切な場所に配置しないと、結合は必要のないときに非常に長い時間がかかります。
現在、自己調整データベースは、ワークロードがよく知られているこれらの領域にのみ存在します。私の経験では、ほとんどの企業はDBAをほとんど採用しておらず、それは高価だからです。したがって、DBAが行うことを代替できるのであれば、より良い方法です。私が理解しているように、これはDBAの活動です。データベースのインストール、構成、およびアップグレードを行います。ところで、アップグレードは必ずしも些細な作業ではありません。データベースをアップグレードする理由は、私がいつも取り組んでいたルールは、それが機能している場合は触れないことです。データベースを特定の新しいバージョンにアップグレードする場合は、テストモードで行います最初に、その後すべてをアップグレードします。常に同じバージョンを扱っています。しかし、実際に私が出くわした多くのサイトは、それが起こることではありません。たとえば、かなりの程度のエントロピーがあります。ライセンス管理は問題であり、所有しているライセンスによって異なります。 ETLおよびデータ複製。
データベースのコツの1つは、分割する必要があるクエリワークロードがある場合、2つのインスタンスを作成して複製することができ、必要に応じてレプリカをホットバックアップとして使用している場所でよく行われます。その後、ストレージと容量の計画は、もちろんデータが増大するためDBAの活動の一部であり、それを追跡する必要があります。そして、さまざまなハードウェアのアップグレードまたはハードウェアの増強を計画する必要があります。トラブルシューティングは、ほとんどのDBAにとって苦痛な作業です。何かがうまくいかず、バックアップが完全に機能しない場合は、袖をまくり上げて、ログファイルから物事を回復しようとします。それは私が思っているよりも頻繁に起こります。まあ、私はその出来事を覚えていますが、私は少なくとも10年間ゲームから除外されていますが、あなたが予想するよりも頻繁にその出来事を覚えています。パフォーマンスの監視とチューニングは、DBAの仕事の心臓部です。ただし、アクセス管理、バックアップ、リカバリの面でもセキュリティがあり、稼働中のシステムとほぼ同等のソフトウェアテストシステムを作成できます。そして、データのライフサイクル全体。だから、私の意見では、DBAの仕事のリストは、他に依頼されるかもしれないものとは別になっています。オペレーショナルダイナミック。最終的に、データの整合性とサービスレベルの管理は、DBAの主要な責任です。通常、それらは重要です。そして、それだけです。 Dezに引き渡します。
デズ・ブランフィールド： どうもありがとうございました。今日のトピックがこれまで以上に重要である理由について、少しおもしろい逸話的な旅に連れて行きます。少し前に、ライセンス登録と車両登録に使用される州政府のプラットフォームと、そのトピックに関するさまざまなものを、A + Additionと呼ばれるものを実行する富士通のメインフレームプラットフォームから移行するプロジェクトに参加しました。 Oracleを実行し、非常に良い仕事をしているSolarisオペレーティングシステム、つまりUnix。そして、このことは古くなっていて、それを別のものに移す時が来たという見方でした。メインフレーム上でUnixを実行することは非常に楽しかったです。それは非常に安定していて非常に安全で、奇妙なことにSDLプラットフォームとしては十分でした。しかし、知恵は、メインフレームから降りて動く時でした。
すべてのシステムとビジネスロジック、およびその下のデータベースのSQL環境をマッピングし、新しいホームをどのように設計および設計するかを検討するというこの大きな課題。そして、私たちはそれらを現在数年前のものの1つに持って行きましたが、SunラックシステムStarfireサーバーのトップエンドの1つです。そして、これらはおそらく、1つの大きな箱と対称型マルチプロセッシングサーバーにすべてが収まる地球上で購入できる最大の缶です。それは私たちの世界の中規模システムでした。 Unixを実行し、Oracleをネイティブに実行し、「何が問題になる可能性がありますか？」という見解でした。
たとえば、当時、私たちはずっと前に話をしていませんでしたが、メインフレームプラットフォームにあるものを発見し、広めるために非常に手動のプロセスを経る必要がありました。特に、実際のデータベース環境とSQLロジック。したがって、ビューは、OracleからOracleへのかなり単純な移動、データベースからデータベースへの移動になりそうでした。すべてのビジネスロジックに出くわし、ほとんどのビジネスロジックは埋め込みクエリとトリガーで記述されていました。しかし、何ヶ月もかかるはずだったものが、1年もかからずに終わった。メインフレーム環境でUnixのすべての部分を物理的および手動で確認するには、すべてのデータベースがどこにあり、実行されているインスタンスの数とそれらのインスタンスで何が実行されているかを確認します。これは簡単な作業ではありませんでした。すべてをキャプチャしたことを確認するためだけに3回。必要なだけ深く掘ったと思うたびに、表面の下にもっとあることがわかったからです。
もう1つの課題は、どのインスタンスがどの状態で実行されているかということでした。これは開発環境ですか？テスト環境ですか？それは統合プロセスの一部ですか？システム統合ですか？ UAT、ユーザー受け入れテストですか？本番ですか？ DR環境ですか？メインフレームの素晴らしいところは、今では当たり前だと思っているこれらの小さな仮想環境を構築し、動き回ることができるからです。そして、あなたはこの人が本番グレードの開発とテストをしているのか、それとも本番の本番をしているのかを考えなければなりません。このことは、運転免許証や車の登録のリアルタイム発行や、人々の生活に本当に重要なことを行っていることを思い出してください。
そして、この事柄のバックアップを実行するのに長い時間がかかったので、事をオフラインにして何が起こったのかを確認するためのメンテナンスの時間枠が実際にはありませんでした。再ルーティングするようなものはありませんでした。また、どのインスタンスがどこで誰が実行されているかを見つけるだけでなく、どのインスタンスのどのバージョンが実行されているかを把握する必要がありました。そして、これは私がほとんど私のプロットを失ったところです。さまざまなレベルのテストを実行している本番環境の2つまたは3つのバージョンがあり、ツールやこれに対する体系的なアプローチがほとんどないことに気付き始めました。文字通りコードと実行中のインスタンスを掘り下げなければならず、場合によってはしばらくの間何かをオフラインにするリスクがあります。私たちはこの全体の底に到達し、それをマッピングしました、そしてそれは私が言ったように非常に手作業のプロセスでした。そして、最終的にETLシフト全体を行い、ある場所からダンプし、別の場所に移動し、全体として機能しました。そして、機能的であり、非常に満足しています。
しかし、その後、非常に深刻な頑丈なレンガの壁に出会いました。特に、パフォーマンスの問題が見つかりました。その日の賢明な考えは、より大きく、より良く、より速く、よりハードなハードウェアになったことです。データベースレベルのアプリケーションでパフォーマンスが悪くなる理由はないので、他の場所から見てみましょう。そのため、ネットワークを2回完全に再設計しました。すべてのルーター、すべてのスイッチ、すべてのケーブル、場合によってはイーサネットからファイバーに移行し、ソフトウェアをアップグレードし、パッチを適用しました。私たちは基本的に、パフォーマンスの問題があると考えてネットワークを再構築しました。そして、それはそのように見え、感じました。異なるセキュリティシステム、異なるファイアウォールを通過しました。オペレーティングシステムにパッチを適用しました。ある計算ブレードから別の計算ブレードにデータを移動しました。そして、インフラストラクチャの一部を見てかなりの時間を費やしました。
そして、サーバーを切断し、その上で他のアプリケーションを実行すると、ネットワークが正常に実行されることに気付きました。そのため、オペレーティングシステムをバラバラにし始めました。同じ問題。しかし、興味深いのは、ネットワークレベルとオペレーティングシステムレベル、ツールが存在することです。ベンチマークとテストを行い、それらの各要素が機能することを証明することは、実際には比較的簡単でした。しかし、それでも、SPARCハードウェアプラットフォームのミッドレンジのSolarisでは、データベース環境の診断を開始するためのツールがそこにありませんでした。すべてのインスタンスを持ち込んだかどうかをマッピングします。そのため、実際に独自のツールを構築し、いくつかを記述して座って、それがネイティブスクリプト言語のデータベースツール内にあるのか、それとも一連のシェルスクリプトであるのか、場合によってはCプログラムの束であるのかを判断する必要がありました
最終的に、SQLレイヤーの下のロジック、実際のデータベースエンジン自体、いくつかの非常に興味深い問題を掘り下げて、メインフレームバージョンのOracleで実行されていた何かの特定の方法がSPARC上のSolarisに移行されたことが判明しましたOracleのバージョンでは、すぐに同じパフォーマンスを置き換えませんでした。そもそもこれは私たちにとって非常に苦痛な旅でした。ただそれを実行してすべてを見つけましたが、今では新しい生産システムで診断する必要があり、1か月分の移行から1年近くになりました。そして、それは単に私たちが周りにツールを持っていなかったという事実に帰着しました。メタデータをマップするなどのことを実行します。
ある時点で、ウィジャボードが必要であると判断しました。これは、ランダムにポイントアンドポークする方が簡単だからです。誰が古いシステムにアクセスしたのか、なぜそのシステムにアクセスできたのかを見つけるなどの簡単なこと。そして、誰が新しいものへのアクセスと確認を必要とし、誰かをサインオフさせてそれを確認させ、それをマッピングしました。データベースのサイズのような単純なものでさえ、2つのプラットフォーム間で一貫していませんでした。それを行うためのツールを構築し、システムAとシステムBのトン数、生メガバイトまたはテラバイトのデータベースの大きさを比較する必要がありました。そして、パフォーマンスとパフォーマンス環境に関する詳細に飛び込みました。繰り返しますが、新しいツールを構築する必要がありました。すぐに使えるものはありませんでした。
そして、あなたはこれから全体を引き出します。ものを実行させて安定させたとき、そのすべてが非常に手動のプロセスでした。何かを自動化できる唯一の方法は、新しいものを構築することでしたツールまたは新しいスクリプト。そして、今日利用可能なツールがあれば、人生はずっと楽になり、ずっと良くなっただろう。そして、このプロジェクトで何百万も節約できたでしょう。しかし、私たちが今日お話ししようとしているのは、ツールが現在利用可能であり、生活をとても楽にするという事実だと思います。落とし穴の多くはまだ残っています。そこにあるデータベースと、どのインスタンスが何を実行しているかの発見。彼らがいる状態。何人が走っていますか？彼らが走っている理由。順調かどうか。バックアップされていますか？
これらはすべて、適切なツールを使用することで、多くの点で当たり前のことと言えるでしょう。しかし、私が言ったように、この特定の逸話には期間がありました、それは私たちの多くが多くの髪を失ったことであり、おそらく私たちは人生から15年を取り去り、ツールが今はなかったという事実を嘆きます。そして、今日のゲストであるバレットからより多くのことを聞くのを楽しみにしています。それでは、バレット、お渡しします。この問題をどのように解決したかを楽しみにしています。
バレット・マナーレ： わかった。いいね。エリック、私はここでスライドを引き継いで、製品自体に入る前に、会社のIderaについて少し早速話してみましょう。参考までに、これは利用可能なさまざまな製品のポートフォリオのようなものです。
エリック・カバナ： オーディオは少し暑いので、ヘッドセットを使用している場合は、少し上げてください。
バレット・マナーレ： 問題ない。それは良いですか？
エリック・カバナ： それははるかに良いです。奪って
バレット・マナーレ： わかった。それで、今日は、私たちが議論しているこれらのトピックの多くに明らかに整合している在庫マネージャに焦点を当てるつもりです。この製品がどこにあるのかを少し理解したいと思います。私たちは、製品ラインを日常的に見ていくことから始めました。診断マネージャーと呼ばれるパフォーマンス監視ツールがあります。コンプライアンスマネージャーツールがあります。そのため、SQL Serverを取り巻くさまざまなツールがあり、必然的に、ライセンスの目的で、「組織内で現在管理しているインスタンスの数はいくつですか？」興味深いのは、それについて確固たる答えを得ることができなかったことです。誰と話をしても大した問題ではありませんでした。それは常に「この数字の周りだと思います」と言っていました。これらの種類のものは常に入ってくるので、私たちが管理しているインスタンスの観点からライセンスを取得したいのは何であるかを正確に把握するこのプロセスを実行する必要があります。
私たちは明らかに、多くのDBAにこれに関連する痛みがあるように思われることを非常に迅速に理解しました。明らかに、DBAとして、彼らが担当していることの1つはそれを知っていることです。なぜなら、彼らがしなければならないことの1つは、MicrosoftとSQL Serverの場合のライセンス契約に対する心配です。明らかに、彼らは彼らが担当している他の多くの異なる領域を持っていますが、それはあなたの一般的な責任が何であるかというDBAとしての大きなチケットアイテムの一種です。結論としては、DBAがその数字を簡単に理解できるようにするツールが必要です。というのも、それを呼び出したい場合、SQLスプロールがあり、それはいくつかの異なる理由で起こるからです。誰がソフトウェアをインストールしているか、そのようなことを制御することはできません。
最悪の事態は、誰かがSQL Serverのコピーを手に入れ、それをインストールし、社内の他の組織や部門の何も知らないうちに作業を開始することです。データがバックアップされていないこと、および発生する可能性のあるもの。ここで別の問題があります。インスタンスがそもそも存在していることさえ知らないために、実際に重要なデータを失うことになる状況があります。
私たちがしなければならないことの1つは、その発見の部分を理解しようと言うことでした。そして、その上で、ビジネスが何をしているかに基づいて理にかなっている論理的な方法で収集している情報を整理および管理することができます。そして明らかに、その情報に基づいて意思決定を行い、そのようなことを行えるようになります。それがツールの始まりであり、どこから来たのかです。定期的にDBAと話しているとき、私たちが本当に抱えているのは、DBAが持っているインスタンスの数を知らないという問題です。
面白いのは、測定できないものを管理できないということです。常に、SQL Diagnostic Managerのようなパフォーマンスツールを考え出しましたが、それを知らなければ何も管理できません。そもそも「それ」です。それはこのツールの大きな部分でもあり、それがそこにあることを知ることができるということです。
そのメモで、SQL Serverを使用していくつかの大規模な組織やエンタープライズショップと話をしたところ、多くの人と知り合った興味深い点は、彼らが実際に1年の間に時間を設定したことです。彼らは実際にある場所から別の場所に物理的に歩いて、その数がどのように見えるかを判断しようとしました。 DBAとして、場合によっては、あるマシンから別のマシンに物理的に歩いていくためにかなりの金額を支払われていることを想像できます。これは、驚くほど大きな名前の会社から聞いたことでしょう。ただし、ライセンスカウントが正しいかどうかを確認するためだけに、このような種類の演習を1年のうちの2週間で行うという興味深い点があります。
これはすべてこのツールとその方法に関連していますが、私たちが取り組んだ方法は、SQL Serverの多くの特性に基づいて検出を行う機能を使用することでした。それで、最初の質問は、何を指しているのか、何を最初に見ようとしているのですか？その方法は、IP範囲ごとに行うか、ドメインのメンバーであるコンピューターの観点からドメイン自体のメンバーシップによって行うことができます。これは、この部分にどのように対処したかということです。ただ、これが発見の観点から注目したい分野だと言えるだけです。
そして、それ以外の部分は、それらの特性、ポートなど、WMIレジストリキーなどに基づいており、SQLが実行され、そのインスタンスまたは特定の環境でインストールされている可能性が高いことを確認できます。明らかに、スニーカー法やスニーカーエクスプレス法よりもはるかに優れた方法です。すばらしいのは、インスタンスに関して収集しているすべての情報がリポジトリに保持されており、環境の変化に応じて変化する可能性があることです。 「ねえ、インスタンスがあります、ここにリストがあります」というだけではありませんが、DBA、またはインスタンスを管理している人が、インベントリのその部分を作成するかどうかを判断できます。そのインスタンスを使用停止できるようにするために、インベントリの一部ではありません。したがって、ツール内でSQL Serverインスタンスのプロセス全体のライフサイクルを本当に簡単に理解できます。
インスタンスを発見したら、その後何をしますか？もう1つは、インスタンスに関する多くの情報です。手動で取得してスプレッドシートなどに入力する必要はありません。それは、インベントリプロセスとライセンスについてDBAと話をする際に興味深いものでした。また、「インベントリをどのように維持しますか？」本当に皮肉な部分であるDBAと話しているのです。DBAはそれを維持し、すべての静的なスプレッドシートで追跡しています。私が言ったように、あなたがそれについて少し考えると、それは非常に皮肉です。しかし、それは多くの場合に当てはまり、多くの組織がそれを管理する方法にも当てはまります。彼らはどうやってそれを維持しますか。これは、Excelスプレッドシートのマスターコピーであり、定期的に更新され、定期的に更新される必要があります。
これらが課題だったので、そのインスタンスを登録してインベントリの一部にすることで、それを実行して情報を取得できます。インベントリ、バージョン、エディションの一部になるかどうかを自動化することができます。それでできることは、リストまたはExcelスプレッドシートを手動で追加できることです。これをSQL Inventory Managerと呼ばれるこのツールにインポートできます。かなり自信があると感じるインスタンスの開始点が既にある場合は、それらのインスタンスをインポートして、製品内の管理対象インベントリのその部分を作成できます。インスタンスを取得し、そのインスタンスが存在することがわかったら、そのインスタンスが存在することを知り、外に出て情報を収集することで活用できる多くの情報を取得できます。
そして、多くの情報が、単なるライセンス供与の目的以上のものに必要になるでしょう。その多くは、明らかに物事がどこにあるかを知るために使用でき、取得された後にこの情報を検索できます。しかし、重要なのはサーバー、ハードウェアそのものです。モデルまたはメーカー、メモリ、メモリ量、物理マシンか仮想マシンか、特に物理ソケットまたはコアとCPUの数、およびそれらのタイプなど、どのマシンなのかを理解できます。
コア数に関しては、特にSQL Serverの場合、新しいバージョンのSQLでライセンスを取得する方法がコアごとの計算であることがわかっており、これは非常に重要な部分になります。外に出て実際に掘りに行きます。インスタンスが特定されると、その情報を提供して取得し、表示して理解できるようにし、明らかにそれを利用することができます。
次の層はインスタンスであり、明らかに標準またはエンタープライズ、さらにはSQL Serverの無料バージョンであっても、SQL Serverインスタンスには多くの違いがあります。また、どのアプリケーションがそのインスタンスに関連付けられているかを理解することができ、これは自動的に実行できます。 SQL Server自体のインスタンスに関連する他の情報と同様に、構成設定とそのようなことを理解できること。
次に、実際のデータベースに移動し、構成設定、そのデータに関連付けられたスペースの量、データの場所を確認します。これらすべてが自動的に読み込まれるため、時間を大幅に節約できます。繰り返しになりますが、これは動的に外に出ており、毎日新しいインスタンスを識別しているため、在庫の観点から見ると生き物です。それは、製品のその種の目標であり、動的に変化するものにすることです。
この情報がすべて利用可能になり、このすべてのデータを取得できるようになったら、場合によっては、これらのインスタンスに関連付けられた独自のメタデータの作成を開始し、そのような方法でメタデータを作成することができますビジネスを行う方法に合わせて調整します。
したがって、インスタンスを地理的な場所、またはアプリケーション所有者、DBA所有者などによってグループ化する場合は、それらのインスタンスをグループ化する方法、それらのインスタンスを論理的に理解する方法、ツール内の2つの領域のうち、その機能を提供します。
1つ目は、インスタンスのタグまたはタグを作成する機能です。これは基本的にサーバー、インスタンス、またはデータベースへの関連付けを作成することで、日常的に発生する可能性のあるビューを作成し、質問に答えることができます。管理しているものと、その情報をどのように前進させたいか。
私たちが持っている他のことは、インベントリフィールドまたはカスタムインベントリフィールドと呼ばれるものであり、これらはドリルダウンできる情報の種類に特定のものです。たとえば、ドロップダウンリストを追加するデータベースレイヤーなどすべてのDBAと私は、その状況の種類などに応じてそのデータベースの責任者を置くことができます。データベースの責任者が誰であれ、それを選択することができます。在庫を掘り下げるだけで簡単に。
したがって、これらの情報は、特に大規模な環境がある場合に非常に貴重になります。なぜなら、それはその情報を理解し、自分が持っているものとその方法を知るのに役立つからです。
そこで、ここで次のスライドに切り替えましょう。私が今あなたに示しているのは、これらすべての情報が収集されており、これらすべての情報とメタデータを収集および適用するデータがすべて、Microsoftでライセンスを有効にする際に、より簡単かつ迅速に意思決定を行えるようになることですエンタープライズボリュームライセンスまたはマイクロソフトとのソフトウェア保険。
これにより、多くのデータを手動で収集し、手動で収集する必要がなく、実際にこれを行うことが非常に簡単になります。それが、製品の使命の1つであり、DBAがライセンスに関する決定をより簡単に行えるようにすることです。
さて、DBAと話し合ってすぐに発見し、学んだもう1つのことは、SQL Serverの環境に300個のインスタンスがありますが、実際にはサブセットしか存在しないということです。従来のパフォーマンス監視タイプのツールから実際に完全に監視および管理されているものの一部です。
したがって、実際にDBAに座って言うと、「見て、SOAに準拠し、SOAに準拠するように設計されたこのツールで監視されている300の20個のインスタンスまたは10個のインスタンスがあります。アラートやこれらすべての種類の良いものを取得します」と私たちが見つけたのは、「もしあなたが持っているこれらの他の280個のインスタンスについてはどうですか？そして、彼らは彼らを気にしますが、彼らは本当にそれらのインスタンスで実行できる深さのレベルでそれらを監視するための投資をしたくはありません。製品インスタンス。
したがって、このツールの方程式のもう1つの部分は、ベースレベルでインスタンスの健全性に関してカバーされていることを確認できるという点でも役立ちます。デッドロックが発生しているのか、デッドロックの被害者が誰なのかはわかりません。そのレベルのセッション自体とクエリの詳細に到達することはできません。しかし同時に、サーバーがダウンしたり、ボリュームがいっぱいになったり、データベースのバックアップを行う必要があることを、DBAとしての重要な部分であるということを知らせます。
これらの種類は間違いなく重要であるため、このツールを使用することで、多くの、非常に価値のある、非常に重要なインスタンスのすべてをキャッチできるようになりました。すぐに知る必要があります。彼らはより高いレベルの監視とそのようなことを行うことができますが、これにより環境に追加された新しいインスタンスをピックアップし、それらが説明されていることを確認することができます基本レベルのヘルスチェックが形成されています。
つまり、Inventory SQL Import Managerのすべてについての簡単な説明です。今、私はあなたにそれのデモンストレーションを見せようとしています。それを行う前に、すぐにこれがアーキテクチャのスライドであることを示します。管理しているSQLのインスタンスを表示するために、SQL 2000から新しいバージョンまでのすべてを発見できます。 SQL。
そのため、インスタンス自体にエージェントをデプロイする必要なく、それを実行できます。収集サービスを介してそれを行い、外に出てその情報を収集し、リポジトリに入れてから、Tomcat Webサービスのフロントエンドコンソールから、そのデータとやり取りして表示することができます。そのため、非常に単純なアーキテクチャです。
私は先に進み、切り替えて、実際に製品自体に取り込んで、それについて感じ、それがどのように機能するかを理解できるようにします。したがって、これを行うための最良の方法は、最初に、ここで見ていた一種のダッシュボードであるインターフェイス自体を紹介することです。
現在管理しているインスタンスの数はそれほど多くありません。しかし、私はバックポケットにデータセンター全体を持っていません。したがって、ここに表示されるインスタンスは約6つあります。さて、それで、私は、私がやろうとしていることは、発見のプロセスを通り抜け、それがどのように機能するかを示すことです。
ここで最初にすることは、管理セクションで、インスタンスの検出方法を指定できることです。その情報をここに入れて、IPアドレスの範囲でもう一度できるようになります。ドメインまたはサブドメインをポイントし、そのドメインのメンバーであるマシン上でのみ、これらのチェックを実行できるようになります。チェックするSQLの実行時のさまざまな種類の特性を選択できます。
その後、一度それを実行すると、毎日実行してそのデータを収集するために自動化することができます。また、必要に応じてアドホックベースでそれを行うことができます。しかし、いったんそれを開始すると、その発見プロセスは、ここからインスタンスビューに移動したときに表示されます。 [検出]タブがあり、[検出]タブには最近検出されたインスタンスが表示されます。この場合、ここに番号があります。私が先に進んでやることは、先に進んで、例として使用するものを追加することです。この場合、これはシカゴのインスタンスですよね？先に進み、そのインスタンスをインベントリに追加します。
さて、ここでいくつかのことを説明します。私は先に進むだけで、資格情報を設定できることがわかります。私の資格はそこにあるべきです。私は先に行くつもりであり、あなたは私が望むならこれの所有権を割り当てることができることに気づくでしょう。場所を指定することもできます。これで、場所自体も追加できるようになりました。次回はもちろん、そのことを覚えています。
ここでも、メタデータと、SQLのインスタンス（特にこのインスタンス）をどのバケットに入れるかという観点から、タグをこれに関連付けることができます。ので、すでに含まれている可能性のあるさまざまなタグを見ることができます。これらのいくつかをランダムに選択するだけで、それを適用できます。
だから今、私はこれをインベントリに追加します。追加されたので、この管理ビューの下に表示されるので、ここにリストを表示できます。つまり、それが最初のステップであり、私があなたに示したのは、日常的に通過するときに主にそれらのインスタンスを追加する方法であるということです。場合によっては、SQL Serverのエンタープライズエディションをインベントリに自動的に追加したい場合は知っていると言うかもしれません。手動で行って選択する必要はありません。
ジョセリン： すぐに中断します。デモを見ていません。
バレット・マナーレ： あなたではない？
ジョセリン： 番号。
バレット・マナーレ： よくありません、見てみましょう。
エリック・カバナ： 左上隅に移動する場合は、[開始]をクリックして、それをクリックします。
バレット・マナーレ： あ、そう。
エリック・カバナ： そして今、画面を共有します。
バレット・マナーレ： ごめんなさいうん。
エリック・カバナ： それは大丈夫だ。プロデューサーのジョセリン。
バレット・マナーレ： いいでしょう今見ていますか？
ロビン・ブロア： はい、そうです。
バレット・マナーレ： さてさて、私たちが本物だったところをすぐに見てみましょう。以前に発見したインスタンスを取得しました。シカゴのインスタンスを追加したばかりなので、現在表示されているのはここにリストされています。既に多くの追加情報が取得されていることに注意してください。インスタンス自体をクリックすると、そのインスタンスについて既に収集した情報の種類がすべて表示され始めます。次に、そこにあるすべてのデータベースのリストを示します。データベースのサイズ別およびアクティビティ別の内訳を見ると、どのデータベースが最もサイズとアクティビティが多いかがわかります。
繰り返しますが、インスタンスで実行されているワークロードに基づいて、そのインスタンスで実行されているアプリケーションをすぐに確認することもできます。そのため、それを自動的に行うことができるのは素晴らしいことです。私は入って、アプリケーションを発生率に結び付ける必要はありません。見ていたことに基づいて、それを埋めることができます。手動でアプリケーションを追加したい場合は、絶対にそれを行うことができます。しかし、データベースへのインスタンスの関連付け、または申し訳ありませんが、アプリケーションへの関連付けを示すことができるのはちょうど良い方法です。
また、画面の右側にインスタントサマリーがあり、その下にサーバーサマリーがあることがわかります。インスタンスで重要な情報について話していました。バージョンと、あなたが知っているSQL Server 2012だけでなく、実際のバージョン番号を知り、それにどの修正プログラムが関連付けられているか、どのサービスパックが関連付けられているかを教えてくれましたそれに、知ることは非常に重要です。明らかにメモリ要件が重要です。そのようなすべて、その情報がクラスター化されているかどうか、すべての情報を入力する必要はありません。既に収集および収集されており、検出されたインスタンスであることが特定されると、それがインベントリの一部になります。
ここに表示されるもう1つは、このインスタンスビューの下に表示されます。以前に説明したこれらの属性、つまり追加できるカスタム属性があります。したがって、オープンな種類のボックスフィールドを追加できます。10億種類の選択肢に関しては、yes / noを実行できます。ドロップダウンリストも作成できます。これは、データベースのインスタンスまたはサーバーレベルで実行できます。
さらに少し下にスクロールすると、サーバー自体に関するすべての関連情報を確認できます。そのため、この種のものはすべて収集されて収集され、在庫の一部にするという決定を下すとすぐに私たちのためにそこにあるので、明らかに本当に本当に役立ちます。ここでは、CPU、論理的数と物理的数、メモリの量の違いをいくつか示します。そのため、多くの作業を行うことなく、本当に優れた豊富な情報を得ることができます。
さて、これに対する他の部分は、私が言ったように、サーバーレベルのインスタンスでこのデータを収集することです。データベースにアクセスした場合でも、これらの多くが壊れていることがわかります。したがって、コンプライアンスリポジトリに移動すると、この場合、これが対処していることがわかります。これは、コンプライアンスまたは規制の要件が関連付けられているコンプライアンスデータベースであり、たとえばSOXコンプライアンスまたはPCIコンプライアンス。そのため、どのデータベースにどのコンプライアンスが関連付けられているかを選択して、満たす必要があるか、その規制要件の点で維持していることを確認できます。
したがって、この種のものは、DBAにとって非常に役立つことがわかっています。なぜなら、この関連するメタデータをすべて環境内に簡単に保持できる場所があるからです。 、彼らがビジネスを行う方法として。したがって、これまでに見てきたすべてのものを見てみると、インスタンスを掘り下げると、明らかにインスタンスのかなり良い概要がわかりました。
検索もできるので、インベントリ全体でコンプライアンスリポジトリを検索できると言いました。次に、ここで表示されるのは、これらのものを検索して特定できることです。私はそれを言う-私はわからない、私の行くボタンがそこで動作していません。はい。見てみましょう、もう一度試してみましょう。いくよそのため、コンプライアンスが順守されていたものの内訳を確認でき、ドリルダウンしてその観点から確認することもできます。このデータを掘り下げるための非常に迅速で簡単な方法を手に入れました。
さきほど述べたように、インスタンスサーバーとデータベースに対してメタデータを作成する方法はたくさんあります。それに対する他の部分は、あなたがそれをグループ化した方法とあなたがそれに関連付けた方法でそれを利用できることです。エクスプローラービューに移動します。それを行うことができます。場所ごとにデータベースカウントを行いたいと言えます。したがって、私がサポートする環境の各場所にあるデータベースの数。または、インスタンス数の観点から、私がそこに持っているインスタンスを所有している所有者に基づいているかもしれません。だから私たちはそれを見ることができるでしょう。そのため、あなたがその時点で答えようとしている質問に基づいて、これらの写真を簡単にペイントすることができます。
次に、そのような情報を希望どおりに作成し、それをPDFまたはさまざまな形式にエクスポートして、それを活用して同僚や必要なことを行うことができます。あなたはあなたがそのようなことをすることができると知っています。に戻りましょう-失くしましたか？いくよ申し分なく、これが私がこれまでに話したことに関して意味があることを願っています。収集したデータが揃ったので、これはすべて、多くの理由（ライセンス供与など）にとって非常に重要です。
最後に言及するのは、ここでこの管理セクションに進むことです。これは、あなたとあなたのアラートを設定し、あなたが本当に知りたいことについて、あなたがそれらのものを設定できることを確認することができる場所でもあります。したがって、アラートを設定し、特定の機能をオンにして特定の機能をオフにする機能を設定してから、だれがそれらを受信するかを判断し、それらのアラートをサブスクライブして、誰を関連付けるかを設定できますそのようなことを誰が知りたいのでしょうか。
しかし、先ほど言ったように、これは本当に素晴らしい方法です。少なくとも、エンタープライズSQLインスタンス全体を知っているという全体的な安心感があります。 haventは、そのインスタンスを管理するために、打撃の大きいパフォーマンス監視ツールに投資することを決定しました。これは、非常に手頃な価格で外出する方法であり、多くの場合、これらのインベントリを実行し、非常に広範な種類の一般的なレベルの監視を行って、その心の安らぎを得て、何が起こっているかを知っています。
願わくば、それが私たちがそれを説明し、あなたに示した方法で理にかなっていることを願っています。その観点から、私は先に進んでそれを返すことができ、さらに話をすることができると思います。
エリック・カバナ： それはいいです。ロビン？デズ？質問は？
ロビン・ブロア： よく質問があります。これを実際に見るのは非常に興味深いです。つまり、DBAだけでなく、ネットワーク担当者、ストレージ担当者、仮想マシン管理担当者の間で、私がこれまでにいたあらゆる場所でコメントをしたかっただけです。スプレッドシートで作業します。
エリック・カバナ： そのとおり。
デズ・ブランフィールド： 数字が動き始めるまで、それが大丈夫だということを知っています。数字が動き始めると、問題が発生することがわかります。だから今の質問はちょっと興味があり、答えるのが難しいことを知っていますが、スプレッドシートの作業のために彼らがこのようなものがない場所に行くとどうなりますか？とても頭がいい人など、このようなものを実装することでどのようなROIが得られると思いますか？そのことについての数字やガイドラインはありますか？
バレット・マナーレ： 環境が少し異なるため、ROIが何であるかを言うのは難しいです。明らかに、企業が大きくなればなるほど、環境も大きくなります。明らかに、手動の方法を使用している場合、ROIはおそらくより大きくなります。
数千、数千の従業員、そしておそらく数千のインスタンスの大規模な組織と言えば、私がこれを見せてくれる人がいて、彼らはこれに2週間かかると言っていることを知っています。私の時間のバック。私はそれを何度も言われました。したがって、実際の購入額から言うのは難しいですが、環境が整っている場合は相当なものになります。
私が言ったように、非常に一貫性があり、私、私が話すほとんどの人はスプレッドシートにこのようなものを保管しています。すべての環境は、ライセンス供与方法とマイクロソフトとのライセンス供与方法の点で少し異なるため、それは非常に主観的なことです。しかし、彼らが毎年または3年ごとに本当のアップをしなければならないなら、彼らは少なくとも3年ごとにMicrosoftにとって最大で3年、彼らはあなたに真のアップを望んでいると思います。
それから、あなたはそのかなりのことを知っています、そしてあなたはそれをはるかに簡単にする単なる何かを知っています。常に変化する動的なものであるため、詩を見るという観点からも少し有効性が高くなります。6か月または1年でスプレッドシートを実際に更新する必要はありません。したがって、スプレッドシートを更新する頻度は、ROIへの回答であることを理解するための別の質問です。
デズ・ブランフィールド： ええ、つまり、SQLライセンス、これのライセンスはひどい悪夢ですが、特にライセンスはMicrosoftとOracleとデータベースのことをやっている他の人と同じではないので悪夢です。実際に発生する傾向があるスプレッドシートに実際に物事を保管している場合、実際にそれを実現する前にライセンス時間が発生し、実際にデータを取得していないことを知っています。
とにかく、あなたが指摘するように、私は実際にMicrosoftと交渉する必要がなかったので動的であり、私は個人的にはわかりません。したがって、私は知らなかったが、おそらく人々がテストデータ、テスト環境をかなり頻繁に削除するデータベースがあると思いますライセンスを取得する場合、それらはあなたの側のとげだと思います。あなたなの-？
バレット・マナーレ： はい、はい。多くの場合、そのようなものが忘れられており、その後、私たちはこれらのインスタンスのコアの数を把握する必要があるコアライセンスを取得したので、把握しようとしています。ハードウェアを賢明に購入する基準に関しては、かなり良いハードウェアを購入することもできます。そのハードウェアを利用すべき方法で利用しない場合は、コアが利用されていないときにコア価格を支払うため、過剰に支払います問題になります。
そのため、SQLの各バージョンにはライセンスの適用方法が異なるため、少し混乱することさえあります。そのため、いくつかの課題があります。そのため、この情報が非常に役立つ理由の大部分は、それがどのバージョンであるかを示すことができるためです。それはソケットごとの価格設定でしたが、それも明らかにすることができます。それだけで、それはあなたがそのようなものを実現する時間が来たときにあなたが経験しなければならないルーチンをはるかに単純にします。
デズ・ブランフィールド： 私の頭に浮かぶことの1つは、すみません。
ロビン・ブロア： 大丈夫、あなたはデズに行く、私はおそらく無関係な質問をするつもりだった。
デズ・ブランフィールド： あなたのトピックについてあなたが今すぐに本当に何か-クラウド環境のより多くの採用を見ていました、そしてそれを私たちのデータセンター内で、私たちの環境内でこれを実行しているなら、彼らは歩き回って、物事を見つけることは比較的簡単です。
3つのデータセット、2つのクラウドがあり、これらの環境全体の可視性がファイアウォールで保護されており、多くの場合、パイプまたはVPNの終わりにデータセットがあるシナリオにどのように対処しますか。このプラットフォームが実行されているクラウドとオフプレミスの間の特定の環境をスキャンできるように、ポートを開いてフロントエンドから検出する必要がありますか？
バレット・マナーレ： ええ、そうです、港の面でいくつかの考慮事項があるでしょう。そのため、残念ながら、これらすべての環境を突破すると言いたいのですが、これを使ってできるいくつかの異なるオプションがあります。明らかに、Amazon EC2のような操作を行う場合、ポートが開いていて、それに関連付けられているIPアドレスまたはドメインを指定でき、収集を開始できる場合、本当に必要なのは接続を介したその環境へのアクセスだけですディスカバリーを開始します。
そのようなタイプの環境では、それは実際には問題ではありません。 RDSなどのより具体的なタイプの環境と、データベース自体を取得するだけで、そのタイプの情報を表示して発見するのが少し難しくなる場所です。
デズ・ブランフィールド： そこでそこから、そこにデータベースとデータベースがあります。したがって、たとえば、ちょうど1つの巨大なプラットフォームとそれが行うすべてがデータベースを提供するという前例で共有した逸話のような、非常に大きなデータベースエンジンを持つような古き良き時代。最近では、データベースはすべてに埋め込まれています。実際、アプリの背後で私の携帯電話で実行されているのは、そのうちの2つまたは3つだけです。
ロータスノーツからの環境、その背後にあるアプリ、さまざまなインターネット上のデータベースを使用するSharePointなどを使用するシナリオでは、どのような課題に直面していますか？基本的に、すべてはバックエンドのデータベースによって強化されています。あなたはそこにどんな種類のものを見ていますか、そして人々はそれらの種類の世界をマップしようとしてちょうど直面しているどんな種類の挑戦とあなたのツールは彼らのために何をしますか？
バレット・マナーレ： それは、あなたが言ったことです-すべてが今データベースを必要としているので、多くの場合、おそらく多くの場合、多くのデータベースがDBA自身が作成した環境に導入されています一般に、環境にSQLサーバーをインストールするのはそれほど難しくないためです。
このツールは、エクスプレスデータベースのようなものも識別するので、SQL Serverの無料バージョンも識別します。おもしろいことに、DBAと話をすると、もう一度、無料のデータベースを気にしているという点で一貫した答えが得られません。あなたが話すこれらのアプリケーションの多くは、データベースの無料版を使用します。しかし、組織自体は、あなたが誰と話しているかに応じて、そのデータベースの責任者に関して異なる態度を取ります。
私が話すDBAの中には、シアトルにあるSQL Server PASSに最後に行ったとき、「エクスプレスデータベースに関心がありますか？」という質問があり、それは約50でした。一部の人々は、彼らがDBAとして知りたいと思ったのは、彼らがまだ重要な情報を含むことができる表明されたデータベースでさえ彼らが責任の一部であると感じたからです。彼らはまだバックアップされるプロセスを経る必要があり、それでもすべてのものが彼らの健康の観点から機能していることを確認する必要があります。しかし、それらが存在することを知ることは、より重要ではないにしても、同様に重要です。
一方、残りの半分の人々は、「ねえ、それらのデータベースに責任を負わなかったし、彼らがデータベースにつけたものはすべて、それらをインストールした人に注意している」と言いました。今日では、アプリケーションが関連付けられており、その情報をインベントリする必要があるという複雑さと混乱にさらに貢献しています。
デズ・ブランフィールド： 政府のサイトはおそらく私のお気に入りですが、多くの場合、企業環境で見ていることはよくあります。あなたが言ったように、SharePointやセルフエクスチェンジのようなものをインストールすると、私も忘れてしまいますすぐにインストールしたいので、ライセンスを購入する必要がないので、組み込みの無料バージョンが付属していることを知っています。
それから大きくなり、誰かがパフォーマンスについて文句を言うようになり、「古いサーバー、ストレージ、ネットワークなどなんでも」というようになり、DBAが呼び出されて、「まあ、あなたはただデータベースのこの無料バージョンにすべてを詰め込みました。これは、この大規模な実行に必要なものではありません。」
特に、Project ManagerやOfficeなどのシナリオを取得した場合、Officeは大企業または企業全体で数千とは言わないまでも数百ものプロジェクトを実行しており、Microsoft Project ServerでSharePointを使用し、すべてのPMOをこのデータベースにダンプしています。しかし、フロントエンドでは、Webインターフェイスにすぎません。しかし、実際にはデータベースとデータベースがあります。
バレット・マナーレ： はい。
デズ・ブランフィールド： だから、彼らは何ですか、ここの人々が最初のステップの一種の1つです。聴衆から持ち込みたいと思うかもしれないいくつかの質問があると思います。最初の質問の1つは、人々がどこから始めるかです。彼らが行くための最初の自然なステップは何ですか、「わかりました、アルコール依存症の匿名バージョンをやる必要がありますか？」
何をすべきかがわかっているよりも多くのデータベースがあります。 「これを手に入れて走り始める必要がありますか？」彼らが行くべき自然なステップはどのようなものですか？ ？
バレット・マナーレ： まあ、彼らは環境をマッピングしなければならないと言ったと思う。現在、マイクロソフトはそれを行う無料のツール、Microsoft Assessment Planning Toolを提供しています。これは無料のツールですが、静的です。あなたは発見をし、それで終わりです。そこにあるもののリストを取得します。私たちはそれを取り上げて、さらに一歩踏み込んで発見を行い、そこにあるものを見つけてリポジトリに入れ、それを動的にして追加、削除できるようにしました。
しかし、全体的な最大の最初のステップは、ただ発見して発見することです。試用版で製品をダウンロードすることを意味するかどうかにかかわらず、これをダウンロードして14日間試用することができ、環境を指摘して収集を行うことができます。
その情報が正しいスプレッドシートがある場合、その情報が正しいと確信している場合は、そのすべての情報を含むスプレッドシートをCSVにインポートし、その一部を作成することもできます既に持っている。しかし、あなたが知らないことを理解するという点で、それを行う唯一の方法は、手動で外出するか、それを行うか、このようなタイプの物を探すツールを持つことです。ある時点であなたがしなければならない決定は、「その発見を自動化しようとするか、少なくとも最初にそこにあるものの良い基礎を得て、次にいくつかの例外を心配するか」ということです。おそらくツールが必要です。
デズ・ブランフィールド： だからすぐに。人々はどこからこれを始めますか？彼らはあなたのウェブサイトにヒットしますか？彼らはどのように手を差し伸べ、これをすぐに始めますか？
バレット・マナーレ： I-D-E-R-A.comのIderaにアクセスすると表示されます。実際にすばやく表示できます。 Ideraのウェブサイトでyoullは製品に行き、在庫マネージャに行きます。ここにダウンロードリンクがあります。 64ビットまたは32ビットにインストールするビルドを決定するだけで、それで作業を開始でき、そこから検出を開始できます。
ロビン・ブロア： 素晴らしい、素晴らしい、素晴らしいプレゼンテーション、ありがとうございました。
バレット・マナーレ： ありがとうございました。
エリック・カバナ： 視聴者からの質問がいくつかあります。今日、私たちは一生懸命やらなければならないので、しかし、バレットは、デモで素晴らしい仕事をしました。
バレット・マナーレ： ごめんなさい
エリック・カバナ： いいえ、これは良いことです。ビジネスのコアを可視化できますよね？ビジネスがデータを実行し、コアが可視性を提供するためです。したがって、これ以上手の波状のものはありません。今、あなたは実際に物事を指し示し、それを解決することができます。あなたにとても良い。
バレット・マナーレ： ありがとうございました。
ロビン・ブロア： しかし、それをライブで見るのは素晴らしいことでした。
エリック・カバナ： ええ、後で見るためにこのWebキャストをアーカイブします。その後、1〜2時間以内に最初のアーカイブがそれより少し長くなることがありますが、必ず知らせてください。それで、あなたを手放すつもりでした、人々。ブリーフィングルームにご参加いただきありがとうございます。実際にホットテクノロジーでした。次回もお会いしましょう。さようなら、気をつけて。