Techopediaスタッフ、2016年5月26日
まとめ：ホストのエリック・カバナは、最新のHot Technologiesエピソードで、ロビン・ブロア、デズ・ブランフィールド、およびバレット・マナーレとデータベース管理とインスタンス発見について議論します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：よろしくお願いします 。 おかえりなさい。 私の名前はエリック・カバナです。 物事は暑いです。 ここで物事が熱くなっています。 何が起こっているのか分かりません。 ああ、そうです、Hot Technologiesの時間です。 はい、確かに、私の名前はもう一度、エリック・カバナです。 Twitter @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に引き渡します。
Dez Blanchfield：ありがとうございます。 今日のトピック全体がこれまで以上に重要である理由について、少し楽しく逸話的な旅に連れて行きます。 少し前に、ライセンス登録と車両登録に使用される州政府のプラットフォームと、そのトピックに関するさまざまなものを、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年を取り去り、ツールが今はなかったという事実を嘆きます。 そして、今日のゲストであるバレットから、それについてもっと多くのことを聞くのを楽しみにしています。 それで、Bullett、私はあなたに渡すつもりです、そして、私はあなたがこの問題をどのように解決したか聞くのを楽しみにしています。
バレット・マナーレ：わかりました 。 いいね。 エリック、私はここでスライドを引き継いで、製品自体に入る前に、会社のIderaについて少し早速話してみましょう。 参考までに、これは利用可能なさまざまな製品のポートフォリオのようなものです。
エリック・カバナ：あなたのオーディオはちょっと暑いので、ヘッドセットを使用している場合は少し上げてください。
Bullett Manale：問題ありません。 それは良いですか？
エリック・カバナ：それはずっと良いです。 奪って
バレット・マナーレ：わかりました 。 それで、今日は、私たちが議論しているこれらのトピックの多くに明らかに整合している在庫マネージャに焦点を当てるつもりです。 この製品がどこにあるのかを少し理解したいと思います。 私たちは、製品ラインを日常的に見ていくことから始めました。診断マネージャーと呼ばれるパフォーマンス監視ツールがあります。 コンプライアンスマネージャーツールがあります。 そのため、SQL Serverを取り巻くさまざまなツールがあり、必然的に、ライセンスの目的で、「組織内で現在管理しているインスタンスの数はいくつですか？」 興味深いのは、それについて確固たる答えを得ることができなかったことです。 誰と話をしても大した問題ではありませんでした。 それは常に「この数に近いと思います」と言っていました。 こうした種類のものは常に入ってくるので、私たちが管理しているインスタンスの観点からライセンスを取得したかったのは何なのかを正確に把握するこのプロセスを実行する必要があります。
私たちは明らかに、多くのDBAにこれに関連する痛みがあるように思われることを非常に迅速に理解しました。 明らかに、DBAとして、彼らが担当していることの1つはそれを知っていることです。なぜなら、彼らがしなければならないことの1つは、MicrosoftとSQL Serverとのライセンス契約について心配しているからです。 明らかに他の多くの異なる領域を担当していますが、それはDBAとしての一般的な責任の面で大きなチケット項目の1つです。 結論としては、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と私は、そのタイプの状況などに応じて、そのデータベースの責任者を置くことができます。そのデータベースの責任者が誰であれ、それを選択できるので、責任者であることがわかります在庫を掘り下げるだけで非常に簡単になります。
したがって、これらの情報は、特に大規模な環境がある場合に非常に貴重になります。なぜなら、それはその情報を理解し、自分が持っているものとその方法を知るのに役立つからです。
そこで、ここで次のスライドに切り替えましょう。 現在お見せしているのは、収集しているすべての情報、収集し適用しているメタデータのすべての情報とデータにより、より簡単かつ迅速に意思決定を行えるようになることです。エンタープライズボリュームライセンスまたはマイクロソフトとのソフトウェア保険でマイクロソフトとライセンスを交わします。
これにより、多くのデータを手動で収集し、手動で収集する必要がなく、実際にこれを行うことが非常に簡単になります。 それが、製品の使命の1つであり、DBAがライセンスに関する意思決定を容易にすることもあります。
DBAと話をして、すぐに発見して学んだもう1つのことは、以前に説明したものに戻ることです。SQLServerの環境には300個のインスタンスがありますが、実際にはサブセットしかありません。従来のパフォーマンス監視タイプのツールから実際に完全に監視および管理されているものの一部です。
したがって、実際にDBAと一緒に座って、「見れば、この20個のインスタンスまたは300個の10個のインスタンスがあり、それらを監視し、それに準拠するように設計されたこのツールで監視していることがわかります」 SOAとアラートの取得、およびこれらすべての種類の良いこと」を見つけたのは、「もしあなたが持っている他の280個のインスタンスについてはどうですか？」 彼らは気にしますが、彼らは本当にそれらのインスタンスに対して行うことができる深さのレベルでそれらを監視するための投資をしたくはありません。非常に重要な製品インスタンス。
したがって、このツールの方程式のもう1つの部分は、ベースレベルでインスタンスの正常性がカバーされていることを確認できるという点でも役立ちます。 デッドロックが発生しているのか、デッドロックの被害者が誰であるのかはわかりません。 セッション自体のレベルやクエリの詳細に到達することではありません。 しかし同時に、サーバーがダウンしたり、ボリュームがいっぱいになったり、データベースのバックアップを実行したりする必要があることも、DBAとしての重要な部分です。
これらの種類は間違いなく重要であるため、このツールを使用することで、多くの、非常に価値のある、非常に重要なインスタンスのすべてをキャッチできるようになりました。すぐに知る必要があります。 彼らはより高いレベルの監視を行うことができ、これらの種類のことを行うことができますが、これにより、環境に追加された新しいインスタンスを選択し、それらが説明され、また確認されることを確認できます基本レベルのヘルスチェックが形成されていることを確認してください。
つまり、Inventory SQL Import Managerのすべてについての簡単な説明です。 次に、そのデモを紹介します。 それを行う前に、ここでアーキテクチャのスライドを示します。管理しているSQLのインスタンスを示すために、SQL 2000から新しいものまですべてを発見できます。 SQLのバージョン。
そのため、インスタンス自体にエージェントをデプロイする必要なく、それを実行できます。 収集サービスを介してそれを行い、外に出てその情報を収集し、リポジトリに入れてから、Tomcat Webサービスのフロントエンドコンソールから、そのデータとやり取りして表示することができます。 したがって、非常に単純なアーキテクチャです。
私は先に進み、切り替えて実際に製品自体に取り込んで、それについて感じ、それがどのように機能するかを理解できるようにします。 そのための最善の方法は、ここで見ているダッシュボードのようなインターフェイス自体を最初に紹介することです。
現在管理しているインスタンスの数はそれほど多くありません。 しかし、バックポケットにはデータセンター全体もありません。 したがって、ここに表示されるインスタンスは約6つあります。 さて、それでは、私がやろうとしていることは、発見のプロセスを見て、それがどのように機能するかを示すことです。
ここで最初にすることは、管理セクションで、インスタンスの検出方法を指定できることです。 その情報をここに入れて、IPアドレスの範囲でもう一度できるようになります。 ドメインまたはサブドメインをポイントし、そのドメインのメンバーであるマシン上でのみ、これらのチェックを実行できるようになります。チェックするSQLの実行時のさまざまな種類の特性を選択できます。
それが完了したら、自動化して毎日実行し、そのデータを収集します。 必要に応じて、アドホックベースでそれを行うこともできます。 しかし、いったんそれを開始すると、その発見プロセスは、ここからインスタンスビューに移動したときに表示されます。 [検出]タブがあり、[検出]タブには最近検出されたインスタンスが表示されます。 そのため、ここでは番号があります。 先に進んで行うことは、先に進み、例として使用するものを追加することです。 この場合、これはシカゴのインスタンスですよね？ 先に進み、そのインスタンスをインベントリに追加します。
さて、ここでいくつかのことを説明します。 先に進むと、資格情報を設定できることがわかります。 私の資格はそこにあるべきです。 私は先に進むつもりです、そして、あなたが私が望むならば、これの所有権を割り当てることができることに気づくでしょう。 場所を指定することもできます。 これで、場所自体も追加できるようになり、次回は明らかにそのことを思い出すでしょう。
ここでも、メタデータと、SQLのインスタンス（特にこのインスタンス）をどのバケットに入れるかという観点から、タグをこれに関連付けることができます。ので、すでに含まれている可能性のあるさまざまなタグを見ることができます。 これらのいくつかをランダムに選択するだけで、それを適用できます。
だから今、私はこれをインベントリに追加します。 追加されたので、この管理ビューの下に表示されるので、ここに一覧表示できます。 それが最初のステップであり、私があなたに示したのは、日常的に通過するときに主にそれらのインスタンスを追加する方法でした。 場合によっては、SQL Serverのエンタープライズエディションである場合、インベントリに自動的に追加することを知っていると言うかもしれません。 手動で行って選択する必要はありません。
Jocelyn：すぐに中断します。 デモを見ていません。
バレット・マナーレ：そうじゃない？
ジョセリン：いいえ。
Bullett Manale：それは良くありません、見てみましょう。
エリック・カバナ：左上隅に行ったら、「開始」をクリックして、それをクリックします。
Bullett Manale：ああ、大丈夫。
エリック・カバナフ：そして今、画面を共有しましょう。
Bullett Manale：それについてすみません。 うん。
エリック・カバナ：大丈夫です。 プロデューサーのジョセリン。
バレット・マナーレ：よし、それでいいの？ 今見ていますか？
Robin Bloor：はい、そうです。
Bullett Manale：わかりました。それでは 、私たちが本物だったところをすぐに見てみましょう。 以前に発見されたインスタンスがあります。 シカゴのインスタンスを追加したばかりなので、現在表示されているのはここにリストされています。 既に多くの追加情報が取得されていることに注意してください。 インスタンス自体をクリックすると、そのインスタンスについて既に収集した情報の種類がすべて表示され始めます。 次に、そこにあるすべてのデータベースのリストを示します。 データベースのサイズ別およびアクティビティ別の内訳を見ると、どのデータベースが最もサイズとアクティビティが多いかがわかります。
繰り返しますが、インスタンスで実行されているワークロードに基づいて、そのインスタンスで実行されているアプリケーションをすぐに確認することもできます。 そのため、それを自動的に行うことができるのはいいことです。 アプリケーションを発生に結び付ける必要はありません。 私たちが見ているものに基づいて、それを埋めることができます。 手動でアプリケーションを追加したい場合は、絶対にそれを行うことができます。 しかし、インスタンスのデータベースへの関連付け、または申し訳ありませんが、アプリケーションへの関連付けを表示できるのは良い方法です。
また、画面の右側にインスタントサマリーがあり、その下にサーバーサマリーがあることがわかります。 インスタンスの重要な情報については、SQL Server 2012のバージョンだけでなく、実際のバージョン番号（どの修正プログラムがどの修正プログラムに関連付けられているか、どのサービスパックが含まれているかなど）を知っています。それに結びついているので、知ることは非常に重要です。 明らかにメモリ要件が重要です。 そのようなすべて、それがクラスター化されているかどうか、この情報のすべて、私はそれを入れる必要はありません-既に収集および収集されており、一度それが発見されたインスタンスであると識別したら、それはインベントリの一部になります。
ここに表示される他のこと-そしてそれはあなたを表示します-それはこのインスタンスビューの下にあります。 以前に説明したこれらの属性、つまり追加できるカスタム属性があります。 したがって、オープンな種類のテキストボックスフィールドを追加することができます。10種類の選択肢に関して、yes / noを実行できます。 ドロップダウンリストを作成することもできます。 これは、データベースのインスタンスまたはサーバーレベルで実行できます。
さらに少し下にスクロールすると、サーバー自体に関するすべての関連情報を確認できます。 したがって、この種のものはすべて収集されて収集され、在庫の一部にするという決定を下すとすぐにそこにあるので、明らかに本当に本当に役立ちます。 ここでは、CPU、論理的数と物理的数、メモリの量の違いをいくつか示します。 したがって、多くの作業を行うことなく、本当に優れた豊富な情報を得ることができます。
さて、これに対する他の部分は、私が言ったように、サーバーレベルのインスタンスでこのデータを収集していることです。 データベースにアクセスした場合でも、これらの多くが壊れていることがわかります。 したがって、コンプライアンスリポジトリにアクセスすると、この場合、これが対処していることがわかります。これは、コンプライアンスまたは規制の要件が関連付けられているコンプライアンスデータベースであり、たとえば、 SOXコンプライアンスまたはPCIコンプライアンス。 そのため、どのデータベースにどのコンプライアンスが関連付けられているかを選択して、満たす必要があるか、その規制要件に関して維持していることを確認できます。
したがって、この種のことはDBAにとって非常に役立つことがわかっています。なぜなら、これらの関連メタデータをすべて簡単に環境内に保持できる場所があり、私が言ったように、彼らがビジネスに適合するようにすることができるからです彼らがビジネスを行う方法として、やり直します。 したがって、これまでに見てきたすべてのものを見ると、インスタンスを掘り下げてみると、インスタンスのかなり良い概要が明らかになっています。
検索することもできるので、インベントリ全体でコンプライアンスリポジトリを探しましょうと言いました。 ここで表示されるのは、これらのものを検索して特定できることです。 私はそれを言う-私は何がわからない、私の行くボタンがそこで動作していません。 はい。 見てみましょう、もう一度試してみましょう。 いくよ そのため、コンプライアンスに準拠しているものをどこで見るか、内訳を見ることができるようになります。ドリルダウンして、その観点からも見ることができます。 このデータを掘り下げるための非常に迅速で簡単な方法を手に入れました。
前に述べたように、インスタンスサーバーとデータベースに対してメタデータを作成するためのさまざまな方法があります。 それに対する他の部分は、あなたがそれをグループ化した方法とあなたがそれに関連付けた方法でそれを利用できることです。 エクスプローラービューに移動します。それを行うことができます。 場所ごとにデータベースカウントを行いたいと言えます。 したがって、私がサポートする環境の各場所にあるデータベースの数。 または、多分インスタンス数の観点から、私がそこに持っているインスタンスを所有している所有者に基づいているかもしれません。 だから私たちはそれを見ることができるでしょう。 そのため、その時点で答えようとしている質問に基づいて、これらの写真を簡単にペイントすることができます。
次に、その情報を希望どおりに作成し、それをPDFまたはさまざまな形式にエクスポートして、それを活用して同僚に送信したり、必要な処理を実行したりできます。 だから、あなたはあなたがそのようなことをすることができるだろうことを知っています。 に戻りましょう–私はそれを失いましたか？ いくよ 申し分なく、これが私がこれまでに話したことに関して意味があることを願っています。 収集したデータが揃ったので、これは多くの理由（ライセンス供与など）にとって非常に重要です。
最後に言及するのは、ここでこの管理セクションに進むことです。 ここで、電子メールとアラートを設定し、本当に知りたいことについて、それらの設定もできるようにすることができます。 そのため、電子メールアラートを設定し、特定の機能をオンにして特定の機能をオフにする機能を設定してから、だれがそれらのメールを受信するかを判断し、必要なアラートをサブスクライブすることができます誰がそのようなことを知りたいと思うでしょう。
しかし、先ほど言ったように、これは本当に素晴らしい方法です。少なくともエンタープライズSQLインスタンス全体を知っているという全体的な安心感があります-それが何であるか、また、たとえそうでなくても最適に実行されることを確認してください」 t、そのインスタンスを管理するためのパフォーマンス監視ツールに大きな打撃を与えることを決定していない。 これは、非常に手頃な価格で外出する方法であり、多くの場合、これらのインベントリを実行し、非常に広範な種類の一般的なレベルの監視を行って、その心の安らぎを得て、何が起こっているかを知っています。
したがって、それを説明し、あなたに示した方法でそれが理にかなっていることを願っています。 その観点から、私は先に進んでそれを返すことができ、さらに話をすることができると思います。
Eric Kavanagh：それは素晴らしいですね。 ロビン？ デズ？ 質問は？
Robin Bloor：質問があります。 実際に非常に興味深いのは、DBAだけでなく、ネットワーク担当者、ストレージ担当者、仮想マシン管理担当者の間で、私がこれまで行ってきたほとんどすべてのことについてコメントしたかったということですスプレッドシートですべての作業をやり直してください。
エリック・カバナウ：そうです。
Dez Blanchfield：それがわかっている、数字が動き始めるまでは大丈夫だということを知っている。 数字が動き始めると、あなたはそれらがトラブルに巻き込まれることを知っています。 だから今私は質問に興味があり、答えるのは難しいだろうと知っていますが、スプレッドシートの作業のためにそこにこのようなものがない場所に行くとどうなるでしょうか？ DBAは非常に賢い人などです。このようなものを実装することで、どのようなROIが得られると思いますか？ そのことについての数字やガイドラインはありますか？
Bullett Manale：環境が少し異なるため、ROIが何であるかを言うのは難しいです。 明らかに、企業が大きくなればなるほど、環境も大きくなります。明らかに、手動の方法を使用している場合、ROIはおそらくより大きくなります。
数千、数千の従業員、そしておそらく数千のインスタンスで大規模な組織を言うとき、私は多くの人と話をしたことがあることを知っています。私の時間の2週間。 何度も言ったことがある。 そのため、実際の購入額から言うのは難しいですが、環境がある場合はかなり重要です。
私が言ったように、それはかなり一貫性があります、私、私が話すほとんどの人はスプレッドシートにこのようなものを保持しています。 だから、それは非常に非常に主観的なことです。なぜなら、すべての環境は、ライセンス供与の方法とマイクロソフトとのライセンス供与の方法の点で少し異なっているためです。 しかし、彼らが毎年または3年ごとに本当のアップをしなければならないなら、私は彼らがそうするMicrosoftのために最大で3年だと思う、彼らはあなたが少なくとも3年ごとに正してほしいと思う。
それから、あなたはそのかなりのことを知っています、そして、あなたはそれがはるかに簡単にする単なる何かであることを知っています。 それは常に変化している動的なものなので、あなたが詩を見ているという観点からももう少し有効性を与えます。まあ、私たちは6ヶ月または1年でスプレッドシートを実際に更新していません。 したがって、スプレッドシートを更新する頻度は、ROIへの回答であることを理解するための別の質問です。
Dez Blanchfield：ええ、SQLライセンスです。これのライセンスはただの悪夢ですが、ライセンスはMicrosoftとOracle、そしてデータベースのことをやっている他の人と同じではないので、特に悪夢です。 実際に発生する傾向があるスプレッドシートに実際に物事を保存している場合、実際にそれを実現する前にライセンス時間が発生し、実際にデータを持っているわけではないことを知っていますその情報。
とにかく、あなたが指摘するように、それは動的であり、私は実際にMicrosoftと交渉する必要がなかったので、個人的には分かりません。したがって、私は知らないが、おそらく人々がテストデータをテストし、あなたがライセンスを行っているなら、それらはあなたの側のとげだと思います。 あなたなの-？
Bullett Manale：はい、はい。 多くの場合、そのようなものが忘れられており、私たちはこれらの各インスタンスのコアの数を把握する必要があるコアライセンスを取得しようとしているので、理解しようとしています。あなたが賢明なハードウェアを購入しているものの基準に関しては、かなり良いハードウェアを購入し、そのハードウェアをそれが利用されるべき方法で利用していないなら、あなたはこれらのコアが活用されていない場合にコア価格の支払いが問題になる。
そのため、SQLの各バージョンにはライセンスの適用方法が異なるため、少し混乱することさえあります。 そのため、いくつかの課題があるため、この情報が非常に役立つ理由の大部分は、それがどのバージョンであるかを示すことができるためです。SQLの古いバージョンである場合は、明らかに、所有しているコアの数を示すことができますそれはソケットごとの価格設定でしたが、それも明らかにすることができます。 それだけで、それはあなたがそのようなものを実現する時間が来たときにあなたが経験しなければならないルーチンをはるかに単純にします。
Dez Blanchfield：頭に浮かぶことが1つあります。
ロビン・ブロア：大丈夫です、デズに行きます、私はおそらく無関係な質問をするつもりでした。
Dez Blanchfield：あなたが今話題になっている間、本当にすぐに何か-私たちはクラウド環境のより多くの採用を見ています、そして私たちが私たち自身のデータセンター内で、私たち自身の環境内でこれを実行しているなら、彼らはうろついて見つけ、物事を発見することは比較的簡単です。
3つのデータセット、2つのクラウドがあり、これらの環境全体の可視性がファイアウォールで保護され、多くの場合、パイプまたはVPNの終わりにデータセットがあるシナリオにどのように対処しますか。 このプラットフォームが実行されているクラウドとオフプレミスの間の特定の環境をスキャンできるように、ポートを開いてフロントエンドから検出する必要がありますか？
Bullett Manale：ええ、そうです、港に関してはいくらか考慮が必要です。 残念ながら、これらすべての環境を突破すると言えるといいのですが、これでできることはいくつかあります。 明らかに、Amazon EC2のようなことをしている場合、本当に必要なのは、ポートが開いていて、それに関連付けられたIPアドレスまたはドメインを指定でき、開始できる、接続を介したその環境へのアクセスだけです収集し、検出を開始します。
したがって、これらのタイプの環境では、実際には問題ではありません。 RDSなどのより具体的なタイプの環境であり、データベース自体を取得するだけで、そのタイプの情報を表示および検出するのが少し難しくなります。
Dez Blanchfield：そこから続いて、データベースとデータベースがあります。 たとえば、前例で共有した逸話のような非常に大きなデータベースエンジンを備えた古き良き時代は、ただ1つの巨大なプラットフォームであり、データベースを提供するだけです。 最近では、データベースがすべてに埋め込まれています。実際、アプリの背後で私の携帯電話で実行されているのは、そのうちの2つまたは3つだけです。
ロータスノーツからの環境、その背後にあるアプリ、さまざまなインターネット上のデータベースを使用したSharePointなどが存在するシナリオでは、どのような課題に直面していますか？ 基本的に、すべてはバックエンドのデータベースによって強化されています。 あなたはそこにどんな種類のものを見ていますか、そして人々はそれらの種類の世界をマップしようとしてちょうど直面しているどんな種類の挑戦とあなたのツールは彼らのために何をしますか？
Bullett Manale：それは、あなたが言ったことだということです。今はすべてがデータベースを必要としているので、多くの場合、多くの場合、DBA自身が環境に導入しているデータベースがたくさんあります。一般的に言って、環境にSQLサーバーをインストールするのはそれほど難しくないため、気づかれることさえありません。
このツールは、エクスプレスデータベースのようなものも識別するので、SQL Serverの無料バージョンも識別します。 おもしろいことに、DBAと話をすると、もう一度、無料のデータベースを気にしているという点で一貫した答えが得られません。 あなたが話すこれらのアプリケーションの多くは、データベースの無料版を使用します。 しかし、組織自体は、誰と話しているかに応じて、そのデータベースの責任者という点で異なる態度を持ちます。
私が話すDBAの中には、シアトルにあるSQL Server PASSに最後に行ったとき、「エクスプレスデータベースに関心がありますか？」という質問があり、それは約50でした。 一部の人々は、彼らがDBAとして知りたいと思ったのは、彼らがまだ重要な情報を含むことができる表明されたデータベースでさえ、彼らが責任の一部であると感じたからです。 彼らはまだバックアップされるプロセスを経る必要があり、それでもすべてのものが彼らの健康の観点から機能していることを確認する必要があります。 しかし、それらが存在することを知ることは、より重要ではないにしても、同様に重要です。
残りの半分の人々は、「ねえ、私たちはそれらのデータベースに対して責任を負わないわけではありません。彼らがデータベースに置くものはすべて、それらをインストールした人に注意します。」昨今、ほとんどすべてのものにアプリケーションが関連付けられており、その情報をインベントリする必要があるという複雑さと混乱の原因となっています。
Dez Blanchfield：ええ、政府のサイトはおそらく私のお気に入りですが、多くの場合、企業環境で見ていることは多いです。あなたが言ったように、人々はSharePointやセルフエクスチェンジのように、すぐにインストールし、ライセンスを購入する心配がないので、組み込みの無料バージョンが付属していることがわかります。
それから大きくなり、誰かがパフォーマンスについて文句を言うようになり、「古いサーバー、ストレージ、ネットワークなどなんでもない」などのようになり、DBAが呼び出されて「まあ、あなた」この無料バージョンのデータベースにすべてを詰め込んだだけです。これは、この大規模な実行に必要なものではありません。」
特に、プロジェクトマネージャーやOfficeなどのシナリオがあり、Officeが大企業または企業全体で何千ものプロジェクトを実行しており、Microsoft Project ServerでSharePointを使用していて、すべてのPMOをこのデータベースにダンプしている場合。 しかし、フロントエンドでは、それはWebインターフェイスにすぎません。 しかし、実際にはデータベースとデータベースがあります。
Bullett Manale：はい。
Dez Blanchfield：それで、彼らはどういうことなのでしょうか。ここにいる人々が最初に行う最初のステップの1つです。 最初の質問の1つは、人々がどこから始めるかです。 彼らが行くための最初の自然なステップは何ですか、「わかりました、アルコール依存症の匿名バージョンをやる必要がありますか？」
何をすべきかがわかっているよりも多くのデータベースがあります。 「これを手に入れて走り始める必要がありますか？」彼らが行くべき自然なステップはどのようなものですか？ ？
Bullett Manale：環境をマッピングする必要があると言っていたと思います。 現在、マイクロソフトはこれを行うための無料のツール、Microsoft Assessment Planning Toolを提供しています。これは無料のツールですが、静的です。 あなたは発見をし、それだけです。 そこにあるもののリストを取得します。 私たちはそれを取り上げて、さらに一歩踏み込んで発見してみましょう、そこにあるものを見つけてリポジトリに入れて、それが動的になり、追加して削除できるようにします。
しかし、全体的な最大の最初のステップは、ただ発見して発見することです。 試用版で製品をダウンロードすることを意味するかどうかにかかわらず、これをダウンロードして14日間試用することができ、環境を指摘して収集を行うことができます。
その情報が正しいスプレッドシートがある場合、その情報が正しいと確信している場合は、そのすべての情報を含むスプレッドシートをCSVにインポートして、その一部を作成することもできます既に持っている。 しかし、あなたが知らないことを理解するという点で、それを行う唯一の方法は、手動で外出するか、それを行うか、このようなタイプのものを探すツールを持つことです。 ある時点で、「その発見を自動化しようとするのか、少なくとも最初に何が起こっているのかを十分に把握してから、いくつかの例外を心配するのか」という判断を下す必要があります。ほとんどの場合、おそらくツールが必要です。
Dez Blanchfield：それですぐに。 人々はどこからこれを始めますか？ 彼らはあなたのウェブサイトにヒットしますか？ 彼らはどのように手を差し伸べ、これをすぐに始めますか？
Bullett Manale：IDERA.comのIderaに行けばわかるでしょう。実際にすばやく表示できます。 IderaのWebサイトで製品にアクセスし、在庫マネージャにアクセスします。 ここにダウンロードリンクがあります。 64ビットまたは32ビットにどのビルドをインストールするかを決定するだけで、それで作業が開始され、そこから発見を開始できます。
Robin Bloor：素晴らしい、素晴らしい、素晴らしいプレゼンテーション、ありがとうございました。
Bullett Manale：ありがとう。
エリック・カバナフ：聴衆からいくつか質問がありますが、今日私たちはハードストップする必要があるので、それらをメールで送りますが、バレットは、デモで素晴らしい仕事をしました。 t表示。
Bullett Manale：それについてすみません。
エリック・カバナ：いいえ、これは良いことです。ビジネスの中核を可視化していますか？ ビジネスがデータを実行し、コアまで可視性を提供しているためです。 したがって、これ以上手の波状のものはありません。 今、あなたは実際に物事を指し示し、それを解決することができます。 あなたにとても良い。
Bullett Manale：ありがとう。
Robin Bloor：しかし、それもライブで見ることができて良かったです。
エリック・カバナ：ええ、このウェブキャストを後で見るためにアーカイブします。それから約1、2時間以内に最初のアーカイブが立ち上がることを願っています。知っています。 それで、皆さんを手放します。 ブリーフィングルームにご参加いただきありがとうございます。私たちは実際にホットテクノロジーです。 次回またお会いしましょう。 さようなら
