Egdbhealthを使用してジオデータベースを評価する

DannyKrouk_ps

<\/HEAD>

• はじめに<\/a><\/li>調査結果の表示と理解<\/a><\/li>クリティカル<\/a><\/li>警告<\/a><\/li>情報<\/a><\/li>ヘルス改善のための対応<\/a><\/li>評価の理解<\/a><\/li>評価の検証<\/a><\/li>評価の解決を試みる<\/a><\/li>解決の検証<\/a><\/li>まとめ<\/a><\/li><\/ul>

  注：このブログ記事は、egdbhealthに関する3回予定されている投稿シリーズの2回目です。シリーズの最初の記事では、このツールが何であるか、インストール方法、および実行方法について説明しました。シリーズの3回目では、システム設計の文脈でegdbhealthを使用することについて取り上げます。
  
  
  

  はじめに<\H2>EgdbhealthはEnterprise Geodatabases（eGDBes）のさまざまな特性を報告するためのツールです。この文章では、egdbhealthの出力を使用してeGDBのヘルスを評価する方法について説明します。すべての例はSQL ServerバックエンドのeGDBを使用していますが、同様の原則はOracleおよびPostgreSQLバックエンドのeGDBesにも適用されます。
  ツールのインストールおよび実行（つまり出力作成）に関する情報については、このシリーズの最初のブログ記事「What is Egdbhealth?」をご参照ください。
  

  調査結果の表示と理解<\H2>Expert Excelファイルには「OVERVIEW_EXPERT」シートがあり、高レベルで評価を確認し、調査結果のレビュー優先順位を付けることができます。
  
  この記事ではすべての評価とその意味を説明しません。数が多すぎて実用的ではないためです。その代わりに、プロセスを説明し、得られる利益の種類を示す具体的な例を提供します。
  

  クリティカル<\H3>赤く塗りつぶされたセル「Criticals」列は最初に確認してください。これらの調査結果はそれぞれのカテゴリで最重要課題として強調されています。
  例えば、上記スクリーンショットでは「Backups」がクリティカルな懸念としてフラグ付けされています。ハイパーリンクされたセルをクリックすると詳細情報があるシートが表示されます。
  
  この場合、ワークシートにはデータベースが一度もバックアップされたことがないという単一レコードがあります。これはシステム障害時にデータが失われる可能性があるため重大な懸念事項です。また、「OVERVIEW_EXPERT」ワークシートへのハイパーリンクもあります。この「Back to OVERVIEW」リンクはすべての詳細ワークシートにあり、ナビゲーションを容易にします。
  次の例「Memory Pressure」では、詳細ワークシートにSQL Serverによって報告されたメモリプレッシャー警告が表示されます。RDBMSがメモリプレッシャーを報告するとき、それはパフォーマンスやスケーラビリティ問題が現在または近い将来発生する兆候です。
  コメント列（常に最右端）は問題点と推奨される対応策を高レベルで説明しています。「BackUp」の例よりも多くの情報（列数）があり、高度な専門知識が必要な技術的内容です。
  コメント列はドメイン知識が不完全な状態でも詳細を理解しやすくし、実行可能にするためegdbhealthが最善を尽くしたものです。一部の場合、コメント列にはより深い理解を支援するインターネットリソースへのリンクも含まれます。
  空間インデックスがないジオメトリカラムを持つテーブルを特定する別例はこちらです：
  
  ジオメトリカラムに空間インデックスがないと空間クエリ性能が低下します。この場合、「Comment」列は問題解決のため空間インデックス作成（または再構築）を推奨しています。
  次の例ではeGDBリリースがかなり古いためアップグレードすべきことを示しています。「Comments」列には詳細情報（オンライン）へのリンクがあります：
  
  

  警告<\H3>「Warnings」は「Criticals」と同様ですが、その名の通りレビュー優先度は低めです。同じ評価でクリティカルと警告両方がある場合もあります。
  以下例ではegdbhealthがeGDB内さまざまなオブジェクトで古いまたは欠落した統計情報を報告しています：
  
  特定統計情報によってコメント列（常に最右端）で「Warning」または「Critical」とフラグ付けされます。
  統計情報なしの場合、不確実性から「Warning」と扱われます。一方、最近更新されていないか多く変更された統計情報は「Critical」とフラグ付けされます。
  RDBMSコストベースオプティマイザはこれら統計情報を使い最適なクエリ実行計画を決定します。そのため統計情報が最新でないとオプティマイザ判断が悪くなりシステム性能低下につながります。
  以下例ではほとんどレコードが「Informationals」で単なる事実報告ですが、一部に「Warnings」があります：
  
  警告は短時間ですがSQL Server以外プロセスによるCPU使用率が10%以上あったことを示しています。これは性能やスケーラビリティ問題には直結しません。しかし多くRDBMSシステムは専用マシン上で動作する想定なので、不適切な他プロセス存在や管理上注意必要な可能性があります。
  

  情報<\H3>「Informationals」は他タイプ調査結果と同様ですが、評価的要素はなく基本的に記述的です。そのため... コンテキスト Excel ファイル。  それが Expert ファイルにある理由はいくつかあります：<\/P><\/P>調査結果は、遭遇した条件によっては常に Informational であるとは限りません。<\/LI>情報は比較的変動しやすい（つまり、時間とともに変化します）。コンテキスト Excel ファイルは比較的静的な性質の情報を提供するように設計されています。<\/LI><\/OL><\/P>以下の例はこの最初のケースを示しています：<\/P><\/P><\/P><\/P>この eGDB のライセンスは数ヶ月間は問題になりません。  しかし、約6ヶ月後にライセンスが更新されていなければ、このメッセージはもはや Informational ではなくなります。<\/P><\/P>同様に、以下の基盤となるデータベースファイルサイズに関する調査結果はいつでも変わる可能性があります：<\/P><\/P><\/P><\/P>したがって、これらの記述的な情報は現在否定的な評価結果を報告していなくても、Expert Excel に報告されます。<\/P><\/P>

  ヘルス改善のための行動を取る<\/H2>このドキュメント内のすべての個別評価を説明することが非現実的であるのと同様に、それぞれに対して行動指示を提供することも非現実的です。  代わりに、本記事では評価情報を理解し行動するプロセスと具体例について説明します。<\/P><\/P>プロセスには以下のステップが含まれます：<\/P><\/P>評価を理解する<\/LI>評価を検証する<\/LI>評価を解決しようとする<\/LI>解決を検証する<\/LI><\/OL><\/P>

  評価を理解する<\/H3>評価によっては理解しやすいものもあります。  「コメント」列が懸念事項を十分に伝えている幸運な場合、このステップは自動的に行われます。  他の場合には、多少の調査が適切かもしれません。<\/P><\/P>例えば、以下の調査結果は、この SQL Server インスタンス内のデータベースで Checkdb が一度も実行されていないことを報告しています（eGDB はクリティカルとしてフラグ付けされ、他のデータベースは警告です）：<\/P><\/P><\/P><\/P>もし Checkdb にまだ慣れていなければ、「SQL Server Checkdb」でインターネット検索すると理解を助ける結果が得られます。  多くの場合、このような控えめな調査努力だけで、あなたにとって馴染みのないトピックの評価を理解するのに十分です。<\/P><\/P>この場合、インターネット検索では次のリンクが表示される可能性が高く、より多くの情報と推奨されるアクションが提供されます：

  https:\/\/docs.microsoft.com\/en-us\/sql\/t-sql\/database-console-commands\/dbcc-checkdb-transact-sql?view=sql-server-2017, https:\/\/www.mssqltips.com\/sqlservertip\/4381\/sql-server-dbcc-checkdb-overview\/
  , および https:\/\/www.brentozar.com\/blitz\/dbcc-checkdb-not-run-recently\/
  .  要約すると、Checkdb はデータベース上でさまざまな内部チェックを実行し、破損やその他の問題を特定します。  したがって、そのような問題を避けるために時々実行することが望ましいです。<\/P>

  <\/P>

  評価を検証する<\/H3>さまざまな理由から返される情報には不完全さや判断が必要な場合があるため、行動を起こす前に評価を検証することは有用です。 <\/P><\/P>例えば、以下の「Instance」カテゴリでは2つの「Critical」メモリプレッシャー警告評価がありますが、メモリプレッシャー評価自体は「Informationals」のみで、「Warnings」や「Criticals」は報告していません。<\/P><\/P>この場合、多くの異なるメモリプレッシャー指標が存在するため状況が説明されます。  任意の時点および時間経過で、それらすべてが必ずしも同じ結論を示すわけではありません。  したがって、関連情報を総合的に考慮して行動が必要かどうか（およびどんな行動が必要か）判断しなければなりません。<\/P><\\/p>
  他の場合には、詳細シートで提供された詳細情報についてあなた自身の判断が評価に役立つことがあります。  例えば、「Long Elapsed Time Queries」に関するこの詳細では、一部のクエリが SQL Server 内で非常に長時間かかっていることが明らかになっています。<\\/p>
  
  
  
  
  最初の行には平均実行時間72秒（3列目）のクエリがあります。  ただし、この統計期間中に6回しか実行されていません。<\\/p>
  
  Egdbhealth は統計期間を知りません（おそらく直前にフラッシュされたばかりかもしれません）。  また、6回実行という回数が多いか少ないかも知りません。  ここでは他のクエリより多いですが絶対数としては多くありません。  最後に、この特定クエリにとって「遅い」とは何かも Egdbhealth は知りません。  おそらくこれは長時間かかることが予想される「バッチ」処理をサポートしている可能性があります。  この判断を下すには右側（この画面キャプチャにはありません）へスクロールして SQL 文を見ることでクエリ内容を確認します。  その後、ご自身のシステム利用状況やユーザーが期待するパフォーマンス基準に基づいて、「長時間経過クエリ」があなたにとって対応すべきものかどうか判断できます。<\\/p>
  評価解決への試み<\\/h3>
  
  あなたの評価理解は問題解決への努力を導きます。  以下の場合など、一部では egdbhealth がインターネットベースのリソースへのリンクを示し、アクション計画と実施支援します。
  
  
  
  この場合、egdbhealth は SQL Server インスタンスが仮想ハードウェア上で稼働していることを認識しました。  VMWare（および他プラットフォームの場合もある）では最小サーバーメモリと最大サーバーメモリを同じ値に設定することがベストプラクティスとして推奨されています。  理解できれば、この変更は比較的簡単であり、仮想マシンプラットフォームチームと短時間相談して彼らもベストプラクティスと認識していること確認すればよいでしょう。
  
  他の場合には egdbhealth のガイダンスはより曖昧であり、自組織内専門家や Esri テクニカルサポート、自身によるインターネット調査など頼ってアクションプラン策定する必要があります。
  
  時にはアクションには組織的またはシステム的変更が大幅に必要になることがあります。  以下例では egdbhealth がバージョニングシステム性能向上策としてバージョンツリー階層削減提案しています。  組織によるバージョニング使用方法変更は大規模作業であり計画と時間要します。この場合、変更計画立案・組織内周知・実施まで時間費やすことになります。
  
  
  解決検証<\\/h3>
  
  egdbhealth を再度実行すると初期解決努力成功検証になります。同じ eGDB に対して再度 egdbhealth 実行すると以前 Expert Excel ファイルは参照用に「archive」サブディレクトリへ移動されます。（Content Excel ファイルは再作成されません。その情報は変動性低いためです。）
  
  当然ながら対応した「Criticals」や「Warnings」が新しい Expert Excel 出力から消えていること期待します。そして問題正しく理解し効果的対応した場合それが期待できます。
  
  例えば以下調査結果（最新圧縮失敗）が問題解決すると「OVERVIEW_EXPERT」シートで解決済みとなります。この場合正常圧縮後 egdbhealth 再実行するとこの評価は解決されます。
  
  
  
  ただし一部の場合には 「Critical」または「Warning」の分類は、現在の状態がもはや同じでなくても完全には解決しません。例えば、「Compress During Business Hours」の評価は、直近の圧縮だけでなく、最近の圧縮履歴を報告します。「OVERVIEW_EXPERT」シートの評価はしばらく変わらないことが予想されます。<\/P><\/P><\/P><\/P>詳細シートやVersioningカテゴリの他のシートでは、最近の圧縮が営業時間中に行われなかった場合（もしそうであれば）を示します。したがって、評価は解決されています。そして時間が経つにつれて、egdbhealthはそれを認めるようになります。<\/P><\/P>最後に、一部の評価は不安定であることがわかります。egdbhealthを繰り返し実行すると、それらはあなたの特定の行動とは関係なく存在したり存在しなかったりするように見えます。例えば、以下の評価はベーステーブルのレコードがデルタテーブル（「A」と「D」テーブル）に占める割合を報告しています。その割合が高い場合、否定的な評価を提供します。<\/P><\/P><\/P><\/P>あなたが取ったかもしれない対応はeGDBを圧縮することです。しかし、その効果はシステム上で行われている調整と投稿に依存します。したがって、新しい調整と投稿活動がなければ、圧縮は評価を変えなかったでしょう。一方で、調整と投稿活動があった場合や非常に古いバージョンが削除された場合、圧縮によって多くの問題が解決された可能性があります。ただし、理想的な調整、投稿、および圧縮があっても、編集者が同時にデルタテーブルに更新を生成している可能性もあります。<\/P><\/P>この記事で前述した「Memory Metrics」の例も評価の不安定さが予想されるケースです。これはメモリプレッシャー指標がデータベース内の異なる条件によってトリガーされるためです。繰り返される評価がさらなる対応を必要とする問題を示しているかどうかを判断するには、あなたの十分な判断力が必要です。<\/P><\/P>重要なのは、行動を起こす目的は必ずしも否定的な評価がない「クリーンな成績表」を得ることではありません。目的はあなたのシステムに適切な評価だけを持つことです。その過程で、あなたはeGDBシステムへの理解を深め、そのeGDBユーザーに多くの具体的な改善を提供することになります。<\/P><\/P>まとめ<\/H2>egdbhealthの主な目的は管理者がeGDBesの健全性特性を理解し改善する手助けをすることです。Expert Excelファイル出力に注目し、「Critical」「Warning」「Informational」の分類スキームに基づいて分析の優先順位をつけることで、調査が最も必要なeGDBの側面に対処できます。egdbhealthによって提供される一部の評価は理解と対応策決定のために様々な調査を要する場合があります。同僚やEsri Technical Support、インターネットリソースを活用して知識を構築してください。eGDBの健全性改善のために行動した際には、進捗確認と記録のために必ずegdbhealthを再実行してください。<\/SPAN><\/P><\/P>この情報がお役に立てば幸いです。ご質問があれば遠慮なくこちらに投稿してください： https://community.esri.com/thread/231451-arcgis-architecture-series-tools-of-an-architect 注意:<\/EM> 上記内容は多くの場合パフォーマンス向上につながる推奨事項ですが、一部の場合にはこれら推奨事項でパフォーマンス向上が得られないこともあり、その際には追加のパフォーマンステストやシステム構成変更が必要になる場合があります。

JulianoSantosFinck

In case the images do not show up, the reader might still be able to see them via webarchive: https://web.archive.org/web/20230108215740/https://community.esri.com/t5/implementing-arcgis-blog/using-egdbhealth-to-evaluate-a-geodatabase/ba-p/886488

Here the full Krouk's Series:
(1) What is Egdbhealth?,
(2) Using Egdbhealth to Evaluate a Geodatabase,
(3) Using Egdbhealth in System Design

Thank you, @DannyKrouk!