組織内で複数の人がAWSを操作する必要がある場合、統合課金によって支払いが簡単になるだけでなく、ある閾値に達すると、S3などの消費リソースを割引くことができます。また、AWSのティアによっては、使用量が多いほど価格が下がったり、事前にインスタンスを購入することで割引が適用されたりするものもあります（上記のRIやSaving Plansのようなもの）。さらに、未使用のリソースは、ある子アカウントから別の子アカウントに再配布することができます。ここで先に述べたコスト最適化ツールを適用し、多数のアカウントを運用する際の組織の混乱を防いでください。
AWSのネットワークは独自のものですが、物事をシンプルに保つために、あまり深入りせず、とにかくここでいくつかの重要なヒントに触れます。
１）オンプレミスサイトとAWSの間で大量のトラフィックがやり取りされる場合、Direct Connection機能を使えば、より安定したネットワーク体験、帯域スループットの向上、接続の安全性を確保することができます。
２）静的コンテンツ（画像、動画、音楽など）は、S3とCloudFrontの組み合わせでより良く、より安価に配信することができます。世界の様々な地域にある素晴らしいエッジサーバーのセットで、エンドユーザーはより近い場所にあるサービスキャッシュから来るデータを得ることができます。
3)異なるAWSサービス間のトラフィックフローを分析する。VPCからS3のような他のサービスへのトラフィックがエンドポイントを経由するようにVPCエンドポイントを構成することで、インターネットや公共ネットワークをバイパスし、より安全で安価な接続を実現します。
4)可用性ゾーン間のトラフィックについても、別の費用がかかるので、忘れないようにしましょう。フォールトトレランス・アーキテクチャを再考してください。すべてのサービスに必要でない場合もありますし、他の技術で実現できる場合もあります。
災害がどのような規模で発生し、どのようなシステムに影響が及ぶかを予測することは不可能です。そのため、バックアップソリューションでは、データを異なるシステムやクラウドにリストアできることを確認することが重要です。また、精度の高いリストアが可能であることも重要です。例えば、仮想マシンの場合、仮想マシン全体をリストアできる必要がありますが、仮想マシン内の1つのファイルも同様に簡単にリストアできる必要があります。
バックアップソリューションが複雑でなければないほど、必要なときに動作する可能性が高くなります。複雑すぎるバックアップソリューションは、ヒューマンエラー、誤った設定、パッチのリリースに伴う互換性の問題が発生しやすくなります。そのため、シンプルな管理インターフェイスを持つだけでなく、エージェントを必要とせず、実際のデータ保護プロセスを簡素化するソリューションを探すとよいでしょう。つまり、管理者が新しいワークロードごとに手動でエージェントを展開したり、自動化スクリプトを書いたりする必要がなく、あらゆる規模の環境に対して拡張できるソリューションを探すということです。
現在、多くの企業が複数のバックアップ製品を使用しています。オンプレミスのリソースを保護するために1つのバックアップツールを使用し、Azureにあるリソースを保護するために別のツールを使用している場合があります。可能であれば、バックアップ操作を1つのバックアップツールに統合するのがベストです。これにより、バックアップのサイロ化を解消し、クラウドと自社データセンター間でシームレスにデータを移動させることができます。同時に、単一のバックアップソリューションを使用することで、バックアップオペレーションを大幅に簡素化し、ライセンスコストを削減し、組織のデータ保護戦略におけるギャップの可能性を低減することができます。
クラウドバックアップの設置場所は重要です。ハイブリッド/マルチクラウドのサポートに関するビジネス要件は増加傾向にあり、特定のクラウドベンダーの選択と離脱の両方に関して、柔軟性が重視されています。
そのため、共通のコントロールペインとポータブルなバックアップフォーマットが可能なバックアップソリューションが必要とされています。これにより、異なるプラットフォーム間でデータを移動することが容易になります（オンプレミスからクラウドへ。クラウドからオンプレミスへ、クラウドから別のクラウドへ）、プラットフォームのロックインを回避することができます。
バックアップを保護するために組織ができる最も重要なことの1つは、バックアップをオンラインで維持しないことです。ランサムウェアの亜種は、特にバックアップサーバーをターゲットに設計されているため、被害者は身代金を支払う以外に選択肢がありません。以前は、テープは、空隙のあるバックアップを作成したい組織にとって、最適なメカニズムでした。バックアップが作成されると、テープはテープドライブから取り外されるだけでよかったのです。しかし、クラウドバックアップの場合、テープという選択肢はありません。Azureのアーカイブ層はオフラインに保たれ、レイテンシは2時間です。また、クラウドストレージへのアクセスは、多要素認証を使用したアカウントに限定することもできます。これにより、犯罪者が漏れたパスワードや総当たりパスワード攻撃でバックアップにアクセスすることを防ぐことができます。
Azureのバックアップストレージのオプションを評価するとき、必然的にストレージ階層を選択する必要があります。利用可能な階層は、コスト、可用性、およびパフォーマンスに関してかなり異なっています。パフォーマンスの高いストレージ層は、一般的にコストが高くなります。
バックアップの保存期間によっては、ギガバイトあたりのコストが最も低い階層が、必ずしも全体のコストを低く抑えられるとは限らないことに留意する必要があります。これは、Cool Tier の最低データ保存期間が 30 日間であるのに対し、Archive Tier の最低保存期間が 180 日間であるためです。つまり、これらの階層にデータを保存する場合、実際にはそれほど長期間バックアップを保持する必要がない場合でも、少なくとも最低期間データを保存するために費用を支払うことになります。
クラウドサービスプロバイダーは当初から、コストのかかるオンプレミスでのIT運用に代わる安価な選択肢として、パブリッククラウドを販売してきました。しかし、実際には、Azureやその他のクラウド環境での運用は、オンプレミスでのワークロードの維持と同じくらいコストがかかることがよくあります。
Azureのデータをバックアップする場合、IT担当者がコストを抑制するために留意すべき点がいくつかあります。まず、効果的なデータライフサイクル管理ポリシーを持つことが必要です。このようなポリシーは、バックアップされるデータの量やバックアップ自体のサイズを制限するのに役立ちます。第二に、構内や他のクラウド環境に存在するバックアップターゲットの使用には注意が必要です。マイクロソフトは、Azureクラウドからデータを取り出す際にデータ取り出し手数料を契約者に請求しており、この手数料は大きなデータセットではかなり高額になる可能性があります。
クラウドでのコスト管理の複雑さを考えると、バックアップベンダーはクラウドでのデータ移動のニュアンスを意識したバックアップコスト計算とデータ管理ツールを内蔵していることが重要です。
バックアップの自動化には、さまざまな形態があります。例えば、特定の時刻にバックアップを実行するようにスケジュールを組むといった簡単なものです。しかし、最新のバックアップソフトウェアでは、バックアップのスケジューリング以外の自動化も可能です。これまでITプロフェッショナルは、バックアップを作成するだけでなく、バックアップに関連する様々なタスクに対処しなければなりませんでした。しかし、今日ではこれらのタスクの多くを自動化することができます。例えば、バックアップのライフサイクル管理やバックアップのテストを自動化することができます。
Azure のデータを保護するためには、Azure を意識した最新のバックアップソリューションを使用することが重要です。主にオンプレミス用に設計されたレガシーバックアップツールは、Azureデータの一部を保護できるかもしれませんが、すべてのデータを保護することはできない可能性があります。例えば、サーバーレスデータベース内にデータがある場合、レガシーバックアップアプリケーションでは、おそらくそのデータをバックアップすることはできないでしょう。
レガシーバックアップツールでは、バックアップデータを保存するためのオプションが制限されている場合があります。例えば、特定のワークロードをクラウド上で実行することを意識的に決定した場合、そのワークロードのバックアップを構内に保存することは意味をなさないかもしれません。しかし、レガシーバックアップツールの中には、クラウドベースのバックアップターゲットを使用するオプションがないものもあります。
Azureのバックアップ戦略を策定する最初のステップは、実際にバックアップする必要があるのは何なのかを把握することです。つまり、データがAzureクラウド内のどこに存在し、そのデータを保護するために何が必要かを決定することです。Azureのデータは、仮想マシンやAzure SQLのようなマネージドサービスなど、さまざまな場所に存在する可能性があります。また、データが複数のリージョンに分散している可能性もあります。
パブリッククラウドの柔軟性、CAPEXからOPEXへの移行が言われていますが、請求書を減らすAWSの機能であるRI（Reserved Instances）や節約プランなどは、皮肉にもCAPEXに戻るように見えてしまうものです。しかし、実際に50%以上の割引が得られるのですから、誰もが「導入のベストプラクティス」リストに挙げるべきでしょう。
まずは、EC2インスタンスの時間単価の割引とオプションの容量予約を提供するRIを検討することから始めましょう。1年または3年のコミットメントと引き換えに、インスタンスコストの割引を受けることができます。オンデマンドインスタンスは、無制限の柔軟性を持ってワークロードをプロビジョニングすることを好む人にとって良い選択肢となる。しかし、負荷が予測可能なワークロード（Webサービスなど）を常時稼働させる場合は、RIの方がはるかに優れています。
節約のまとめ。
• 予約時間が長いほど、割引率がアップします。
• 前払い金額が多いほど割引率が高くなる（ただし、前払い金0円も可能）
• 標準クラスはコンバーチブルより安い（ただし、インスタンスタイプは作成後に変更できない）
コンバーチブルインスタンスは、サイズダウンやAWS Marketplaceでの販売ができないため、注意が必要です。最小のインスタンスから始め、必要に応じてアップグレードすることで、最大36ヶ月間の月々の支払いを約束させられることを避けることができます。
AWSのサービスの価格は、データセンターが置かれている物理的な場所に依存することに気づくのは簡単です。これは当たり前のように聞こえるかもしれませんが、理にかなっている場合は価格の安いリージョンにリソースを移行してください。
現在の価格を計算して、小さな例を紹介しましょう。ヨーロッパでt3.2xlargeインスタンスを10台、それぞれ150GB SSD gp2のディスク容量で稼働させる必要があるとします。ドイツ・フランクフルトのデータセンターを選択した場合、AWSのコンピュート利用料金は0.5312ドル/時間、一方スウェーデン・ストックホルムのデータセンターでは0.4928ドル/時間となる。さらに、ストレージコストとして1GB/月あたり$0.119 vs $0.1045を加え、1年間運用します。この差は、同じサービスであれば、24*365*10*$0.0384+$0.0145*1,500GB*12m = $3,364 + $261 = $3,625 の年間コストダウンに相当し、単に安い地域を選択したことになるのである。
これは、価格の高い地域をすべて、一度に捨てなければならないということなのでしょうか？そうとは限りません。先ほども言ったように、意味があるときにやればいいのです。アジアで事業を展開し、ユーザーに最も低いレイテンシーを提供しようとする場合、アプリケーションを米国に移動させる理由はないでしょう。ただし、負荷の低いサービスや静的なコンテンツについては、米国に移すことも可能です（詳しくは後述します）。もうひとつ注意しなければならないのは、個人情報の取り扱いです。GDPR（一般データ保護規則）やCCPAのような世界的な規制が障害となる可能性があります。
AWSのネットワークは独自の論文に値するものですが、物事をシンプルに保つために、あまり深入りせず、とにかくここでいくつかの重要なヒントに触れておくべきだと思います。
オンプレミスサイトとAWSの間で大量のトラフィックがやり取りされる場合、Direct Connection機能を使えば、より安定したネットワーク体験、帯域スループットの向上、接続の安全性を確保することができます。
静的コンテンツ（画像、動画、音楽など）は、S3とCloudFrontの組み合わせでより良く、より安価に配信することができます。世界の様々な地域にある素晴らしいエッジサーバーのセットで、エンドユーザーはより近い場所にあるサービスキャッシュから来るデータを得ることができます。
異なるAWSサービス間のトラフィックフローを分析する。VPCからS3のような他のサービスへのトラフィックがエンドポイントを経由するようにVPCエンドポイントを構成することで、インターネットや公共ネットワークをバイパスし、より安全で安価な接続を実現します。
可用性ゾーン間のトラフィックについても、別の費用がかかるので、忘れないようにしましょう。フォールトトレランス・アーキテクチャを再考してください。すべてのサービスに必要でない場合もありますし、他の技術で実現できる場合もあります。
スポットインスタンスのコンセプトは、パブリックマーケットと比較するとよく理解できます。価格は、利用可能な未使用のAWS EC2容量の供給と需要に基づいて変動します。AWSユーザーはそこに行き、希望する価格を入札することができす。もし需要がそれほどなければ、市場は一時的に低い価格で売ることに同意し、結果として通常価格の3倍から6倍の値下げをすることになります。
では、何が問題なのか？需要が高まる瞬間には、必要な資源を受け取れないかもしれない。価格がその希望する上限を超えると、プロビジョニングされたインスタンスは短期間で自動的に終了してしまいます。もちろん、重要なデータをこのような変動にさらしたいと思う人はいないでしょう。しかし、このモデルがうまく機能するケースも多くあります。ロードバランサーの背後にあるメディアレンダリング、ビッグデータ、分析、Webサービスなども、この機能の最初の候補の1つになるはずです。
例えば、ここにノースバージニア地域のスポットインスタンスの価格履歴があります。過去3ヶ月間のt2.largeインスタンスの需要と価格設定が示されています。
上の表からわかることは：
●実質的な価格はオンデマンドの3分の1程度になる可能性がある
●6つのAZはすべて、平等ではないものの、余裕のあるキャパシティを持っている
●価格が安定しないので、最低料金で入札しない
この技術をアクティブなCloudWatchとAuto Scalingで補完すれば、2分間の終了アラートを受信した時点で、システムは負荷をリバランスし、オンデマンドインスタンスに切り替わることができます。
通常、AWSユーザーはEC2インスタンスを新規にセットアップする際に、EBSストレージ（つまりディスク）に注目することになります。それらのディスクは、インスタンスにアタッチしたり、インスタンスからデタッチしたり、データ保護のケースでスナップショットしたりすることができます。インスタンスが停止しても、データはディスク上に残り、どこにも行きません。
もう1つ、検討する価値のあるオプションがある。EC2インスタンスストアを経由してローカルディスクを使用します。これらのディスクの大きな違いは、対応するインスタンスが停止されると、ディスクがクリーニングされることです。ユーザーはインスタンスの使用料のみを支払っているため、「無料」です。
貴重なデータにローカルディスクを使いたくないのは理解できるが、キャッシュやログなどの一時的なデータにはぴったりなケースもあります。また、下敷きのストレージは高速なSSD、あるいはNVMeなので、十分なパフォーマンスがありますので安心ください。EC2インスタンスストアを利用することで、EBSの消費量も少なくなり、月々の請求額も小さくなります。
技術は止まらず、CPUメーカーはほぼ毎年、より高性能で消費電力の少ないCPUを発表し、AWSもそれを実装しているので、必ず定期的にインスタンスタイプ表に戻ってくることです。例えば、10台のインスタンスをc4.xlargeからc5.xlargeに変更するだけで、年間約2,500ドルの節約になり、同時に各インスタンスに多くのRAM（16 -> 20GB）と約5％の性能向上を実現します。
このヒントは、AWS Compute Optimizerを確認することです。このツールは、このタイプの変更をアドバイスすることができます。
EC2サービスは、おそらくAWSでのクラウドの旅で最初に選ぶものの1つでしょう。60以上のインスタンスタイプがあり、最適なものを選ぶのは至難の業です。まずは、インスタンスの目的を考えてみてください。それを元に、以下の表を見て最適なタイプを絞り込むことができます。
ライトサイジングとは、性能要件を満たした上で、最も安価なオプションを選択することであることを忘れないでください。経験則では、長期間にわたってインスタンスのリソース使用率が80%になるようにすることです。
●Database Performance Analyzer (DPA) は、最も複雑なデータベース・パフォーマンスの問題を発見し解決するために設計されています。
●Database Performance Analyzer (DPA)データベースのパフォーマンスに問題がある箇所を一目で確認でき、さらに詳細な情報を得るために簡単に移動することができます。DPAは、単一のインストールで、すべての主要なデータベース・システムでこれを実現できます。
●Database Performance Analyzer (DPA) を使用して、最もリソースを消費し、最も問題を引き起こしているSQLに焦点を当てれば、SQL文のチューニングは容易になります。グラフの各色は、個別のSQLステートメントを表します。
●Database Performance Analyzer (DPA)は、SQL文のテキストをドリルダウンして詳細を確認することも可能です。
●Database Performance Analyzer (DPA)のダイナミックベースラインでは、詳細なメトリクスと数年にわたる履歴を表示し、長期にわたる完全なパフォーマンスストーリーを物語るトレンドとパターンを確認することができます。
SSDドライブを買うべきか、より大きなサーバーを買うべきか？
Database Performance Analyzer（DPA）は、アプリケーションがディスクの読み書き、ネットワークの待ち時間、CPUの待ち時間、サスペンド状態や処理の妨げとなるアクティビティの待ち時間を正確に把握できるため、推測する必要がありません。これにより、アプリケーションのパフォーマンスを向上させるために投資する必要がある箇所や、新しいハードウェアが必要ない場合、コードやデータベース/システム構成の修正または改善によってボトルネックを解消できる箇所を把握することができます。
1. 誤って削除してしまうこと: 1つ目の理由は、実はMicrosoft 365のデータ損失で最も多い懸念事項です。ユーザーを削除すると、その意図があったにせよなかったにせよ、その削除はネットワーク上に複製されます。バックアップを取れば、オンプレミスのExchangeでもOffice 365でも、そのユーザーを復元することができます。
2. 保持ポリシーのギャップと混乱：Microsoft 365 の保持ポリシーは、コンテンツの保持や削除を求める規制、法律、社内ポリシーに組織が準拠できるように設計されており、それらはバックアップではありません。しかし、バックアップの代わりに保持ポリシーに頼ったとしても、管理はおろか、維持することも困難です。バックアップは、より長く、よりアクセスしやすいリテンションを提供し、すべてを保護し、一箇所に保存して、簡単にリカバリできるようにします。
3. 内部セキュリティーの脅威：ビジネスに対する脅威を考えるとき、私たちは通常、外部の脅威から保護することを考えます。しかし、多くの企業は内部からの脅威を経験しており、それはあなたが考えている以上に頻繁に起こっています。ハイグレードなリカバリーソリューションがあれば、重要なデータが失われたり破壊されたりするリスクを軽減することができます。
4. 外部からのセキュリティ脅威： ランサムウェアはますます巧妙になり、犯罪者はユーザーの手を煩わせ、リンクをクリックさせ、身代金を要求するために組織全体のデータを暗号化する方法をより多く見つけてきています。バックアップを取れば、攻撃される前のインスタンスにデータを簡単に復元することができます。
5. 法的コンプライアンス要件：Microsoft 365 には eDiscovery 機能が組み込まれていますが、サードパーティのバックアップソリューションは、バックアップ内を簡単に検索し、あらゆる法規制のコンプライアンスニーズに対応したデータを迅速に復元できるように設計されています。
6. ハイブリッドメールの導入とMicrosoft 365への移行の管理：Microsoft 365 に移行する場合でも、オンプレミスの Exchange と Microsoft 365 のユーザーを混在させる場合でも、交換データは同じ方法で管理および保護する必要があり、移行元のロケーションは関係ありません。
7. Teams のデータ構造：Teams のバックエンドは、多くの人が思っているよりもはるかに複雑です。Teamsは自己完結型のアプリケーションではないため、Teamsで生成されたデータはExchange Online、SharePoint Online、OneDriveなど、他のアプリケーションに存在することになります。このように複雑なレイヤーが追加されているため、データを適切に保護することが最も重要です。
効率的で費用対効果の高いクラウドストレージの管理手法を確立するために、守るべき最高のヒントとコツを紹介します。
▸ ニーズを定義する。 プロバイダーやソリューションを選択する前に、正確なニーズを定義する必要があります。そうしないと、ベンダーをウィンドウショッピングするために多くの時間とお金を費やすことになります。
データを分類する。データをタイプ別に分類し、組織にとって重要なデータセットを定義することが推奨されます。
▸ プロバイダーを綿密周到に選択する。クラウド ストレージ市場は、現代のクラウドの世界で最も競争の激しい市場の一つです。つまり、少なくとも10社の素晴らしい有名ベンダーがあり、あなたに合うかもしれないということです。したがって、コスト削減のためだけに無名業者を選択する必要はありません。大手ベンダーよりも価格が高くなる可能性もあるし、サポートが悪かったり、スタートアップ企業にありがちなトラブルに見舞われる可能性もあります。
▸ クラウド上で安全性を確保する。多くのクラウドストレージベンダーが提供するIDアクセス管理ソリューションは、一見難しそうですが、洗練された便利なものです。データの漏洩や損失を避けるためには、時間をかけて堅牢なデータアクセスポリシーを作成することが最も重要です。主なアクセスパターンとして、最小権限ルールを採用してみてください。
▸ コストをコントロールする。 ベンダーを選択したら、そのソリューション・エンジニアリング・チームと連絡を取り、シナリオに応じた最適なアプローチを検討します。これにより、初期コストを削減し、継続的なコストを監視および管理するためのドキュメントを作成することができます。さらに、ベンダーによっては、すぐに必要でないデータを、より安価なデータストレージの階層に保存することを認めてくれるところもあります。
▸ 構造を作成する。 クラウドへのデータのアップロードや、完全なデジタル文書のワークフローの作成を始める前に、図面を引いて構成図を作りましょう。その構成により、クラウドデータストレージが1年後にゴミサイトとならないようにすることができます。
DPA の [Resources] タブでリソース メトリクスを表示しているとき、ベースラインを表示して、特定の期間の値を過去の基準値と比較することができます。ベースラインは、現在の値に対するコンテキストを提供します。ベースラインを大幅に上回ったり下回ったりするメトリック値は、チューニングや再設定が必要な領域を示している可能性があります。
ベースラインを計算する前に、少なくとも1日間モニタリングが有効でなければなりません。ベースラインは、モニタリングの日数が増えるほど、より代表的なものになります。
（注）ベースラインは、VMオプションで収集されたメトリクスでは利用できません。
ベースラインの表示/非表示
ベースラインは、選択した期間が1週間以下の場合に利用できます。デフォルトでは、ベースラインは表示されません。[Resource］タブの右上にある［Baselines］トグルスイッチをクリックすると、ベースラインの表示/非表示が切り替わります。
ベースラインを表示する場合（かつ期間が1週間以内の場合）、10%から90%の間の履歴値を網掛けで表示します。
ベースラインはどのように計算されるのですか？
ベースラインは、1時間ごとに計算されます。デフォルトでは、ベースラインは平日（月～金）のデータのみを使用して計算されます。各ベースラインは、平日すべての対応する時間のデータを使用して計算されるため、特定の時間の値はすべての日にわたって同じになります。(例えば、午後1時から2時までは月曜日から金曜日まで同じ値です）。
ベースラインは、チャートに表示されている最も古い時間以前の履歴データを使用して計算されます。例えば、5月10日から始まる1週間のチャートの場合、すべてのベースラインは5月9日以前のデータを使って計算されます。このため、1週間チャートは日毎にパターンが繰り返されます。
ベースライン計算に含まれる日数を変更する
ベースライン計算に含まれる日数を変更するには、詳細オプションの 「METRICS_BASELINE_TYPICAL_HOUR_CALCULATION」 を編集します。このオプションは、グローバルまたは特定の監視対象データベースインスタンスに対して設定することができます。
以下の値のいずれかを選択してください。
●Weekday Only (M-F)：平日（月～金）の対応する時間のデータを用いて、1時間ごとにベースラインを計算します。これはデフォルトです。
●All Days of the Week：ベースラインは、すべての日の対応する時間のデータを使用して、各1時間の期間について計算されます。
●Same Day of Week：各1時間の期間について、該当する日の該当する時間のデータを使用して計算されます。(例えば、月曜日の午後1-2時の値は、月曜日の対応する時間のデータを使用しており、したがって金曜日の午後1-2時の値とは異なります)。このオプションを選択すると、メトリックごとのベースラインの数が24から168に増えることに注意してください。
●Query advisors [クエリアドバイザ]は、待ち時間の原因となっている待ちの種類、ステートメントが他のセッションによってブロックされていないか、実行プランにフルテーブルスキャンなどのコストのかかるステップが含まれていないかなど、特定のクエリのパフォーマンスを改善するのに役立つ情報を提供します。
●Table tuning advisors [テーブルチューニングアドバイザー]は、あるテーブルに対して非効率的なクエリが大量に実行された場合に生成されます。これらのアドバイザーは、テーブル、実行された非効率的なクエリ、および既存のインデックスに関する集約された情報を提供します。
DPA ホームページの [チューニング] 列には、データベース インスタンスで警告またはクリティカル ステータスのアドバイザが利用可能な場合、警告またはクリティカル アイコンが表示されます。この列の緑のチェックマークは、アドバイザーが存在しないか、すべてのアドバイザーが情報提供であることを示します。
データベースインスタンスのすべてのアドバイザーを表示する
データベースインスタンスのすべてのアドバイザーを表示するには、次のいずれかの操作を行い、[Tuning Advisors] ページを開きます。
●DPA ホームページから、[Tuning] 列のアイコンをクリックします。
●データベース インスタンスの情報を表示するためにドリルインした場合は、インスタンスの詳細ページの右上隅にある［Tuning］タブをクリックします。
Tuningタブの赤または黄色のバーは、CriticalまたはWarningアドバイザーが利用可能であることを示します。
Tuning Advisors ページには、最新のクエリおよびテーブル・チューニング・アドバイザーが表示されます。ページの上部にあるドロップダウン・メニューを使用して、以前の日付に生成されたアドバイザーを表示します。
