こんな経験に心当たりはありませんか？
「自分のデスクで仕事に集中し、開発者と一緒に最新のアプリケーション機能拡張リクエスト向けの素晴らしいSQLを書こうと猛烈に作業しているところです。まさに決定打となるような、非常に優れた機能です。すると突然、電話が振動し始めます……何度も、何度も、何度も……。
最悪の事態、つまり本番環境の問題を恐れながら、あなたは一気に集中状態から引き戻されます。
そして実際、そのとおりです。エンドユーザーからパフォーマンス低下の報告が上がり、KPIは未達となり、皆が頭を抱え、顧客は不満を募らせていますが、何が起きているのか誰にも分かりません。原因はアプリケーションでしょうか、ネットワークでしょうか、データベースでしょうか。それとも太陽の引力でしょうか。すると誰かが親切にもあなたを指し示し、どこかの無作為なブログで読んだ、大量のI/Oを発生させるバックグラウンド・プロセスが原因だと言い出します。もしかして、それではないかと。きっとそれに違いない、と。
いいえ、それが原因ではありませんでした……。」
少し大げさに書きましたが、私たちは皆、一度や二度は似たような経験をしたことがあるのではないでしょうか。パフォーマンスが低下しており、問題を切り分けて解決する必要があります。あるいは、問題が環境内の別の場所に存在することを証明できる根拠が必要な場合もあります。要するに、お客様から私や他のプロダクト・マネージャーに対して、問題の切り分けや解決に役立つどのようなツールがあるのか、頻繁に質問されるということです。
ご質問ありがとうございます。Oracle DatabaseとExadataは、膨大な量のパフォーマンス待機イベントやメトリックを出力します。また、これらの情報を収集・分析するために、Automatic Workload Repository（AWR）レポート、Enterprise Manager、ExaWatcher、Exadata Management Server（MS）のアラート通知など、多くのツールを提供しています。Exadataのドキュメントには、利用可能な各ツールや情報源について説明されていますので、ここでは詳しく取り上げません。一般的に、これらのツールは事後に問題を特定し、解決するうえで非常に有効です。たとえば、「なぜSQLの実行が遅かったのか」「リバランスが実行されていたのか」といったことを確認できます。
では、リアルタイムで問題を特定するには、どのツールを使えばよいのでしょうか？まさにこの瞬間、データベース・サーバーやストレージ・サーバーで何が起きているのかを、どのように確認できるのでしょうか？
実は、先ほどの一覧で触れていなかったツールが1つあります。Exadata Real-Time Insightです。
その名のとおり、Exadata Real-Time InsightはExadata管理者にシステムのリアルタイム監視機能を提供します。Real-Time Insightは、2022年にExadata System Software 22.1リリースで導入されました。ブログ記事を全文読む価値がありますが、ここでは主なポイントを簡単に要約します。
Exadataは、通常dbmcliまたはcellcliのlist metrichistoryコマンドを使用して表示するメトリックを出力します。Exadata Real-Time Insightは、Exadata Database ServerおよびStorage Serverから200種類を超える固有のメトリックを、中央の時系列データベースへ直接ストリーミングします。通常は、その上にダッシュボードを重ねることで、簡単に可視化できます。
たとえば、最近のExadata Disk Scrubbingに関する投稿では、実際のデータベース・ワークロードが増加すると、Scrubプロセスが自動的に処理を抑えることを示すために、ダッシュボードの以下の一部を使用しました。
どれも素晴らしく聞こえますが、Real-Time Insightのメリットを活用し始めるには、何をする必要があるのでしょうか。
ご質問ありがとうございます。Exadata Real-Time Insightは、あらゆる組織で役立つように設計されています。実際には、PrometheusやInfluxなどの一般的な時系列データベース、およびGrafanaなどのダッシュボード・アプリケーションをサポートしています。また、データ・ストアとダッシュボード・アプリケーションの両方として機能するSplunkもサポートしています。
アーキテクチャ
ここまでで背景を整理し、Real-Time Insightを実装することを決めたので、これから構築する内容をまとめておきましょう。
時系列データベースにはPrometheus、グラフ作成アプリケーションにはGrafanaを使用することにしました。今回は両方をコンテナ内に配置しますが、もちろん、これらのプロジェクトがサポートする任意のサーバーにインストールすることもできます。
Prometheusでは、Database ServerおよびStorage Serverからデータをプッシュ、つまりストリーミングするのではなく、Prometheus側からデータを取得する方式が推奨されています。結果として得られるものは同じで、監視して対応に活用できるリアルタイムのメトリック・データです。
Grafanaはシンプルです。Prometheusデータベースに問い合わせを行い、読みやすいチャートやグラフを生成するグラフ作成エンジンです。
最後に、Exadata Database ServerおよびStorage Serverで、メトリック・ストリーミングを有効にするための設定が必要です。
これを簡単な図にすると、左側にExadataサーバーがあり、Prometheusがそこからメトリックを取得し、Grafanaがグラフィカルなフロントエンドを提供する構成になります。
さて、前置きはこのくらいにして、PrometheusとGrafanaをインストールして構成しましょう。ここでは、Podmanを使用してPrometheusとGrafanaの両方をインストールおよび構成します。Containerfile、構成ファイル、ダッシュボードなどは、Oracle GitHubリポジトリのReal-Time Insightディレクトリにすべて用意されています。
注意事項
- PrometheusおよびGrafana環境のホストとしてExadata Database Serverを使用しないでください。確かにPodmanは利用できますが、Database Serverに高い負荷がかかっている状況で、そのサーバーが何をしているのかを調査しようとしている場合、コンテナによって余計な負荷やノイズが加わることは避けるべきです。さらに悪いことに、収集してきたメトリックにアクセスできなくなる可能性もあります。
- Exadata Real-Time Insightは、Exadata Cloud Service（ExaDB-D）およびExadata Cloud@Customer（ExaCC）でも利用できます。ただし、これらの環境ではVM Guestのみを監視できます。
Exadata Database ServerおよびStorage Server
Real-Time Insightに必要な構成の多くは、あらかじめ用意されています。Exadata System Softwareには、すでに「きめ細かな」収集用に構成された一連のメトリックが含まれています。Database Serverで定義されている82個のメトリックのうち、48個はすでにきめ細かな(fine-grained)メトリックとして定義されています。Storage Serverでは、902個のメトリックのうち192個が、最初からきめ細かなメトリックとして定義されています。きめ細かな収集とは、特定のメトリックを1秒単位で収集することを指し、これによってReal-Time Insightのリアルタイム性が実現されています。
では、デフォルトで有効になっているメトリックを、どのように確認し、その内容を理解すればよいのでしょうか。まず、cellcliでdescribe metricdefinitionを実行し、メトリックの定義を確認してみましょう。
CellCLI> describe metricdefinition
name Unique name of the metric definition
description Description of the metric
fineGrained modifiable Specifies if the metric is enabled for fine-grained collection
metricType Indicates how the statistic was created or defined, either 'cumulative', 'instantaneous', 'rate', or 'transition'
objectType Type of object being measured, such as 'CELL', 'GRIDDISK', 'FLASHCACHE', and so on
retentionPolicy modifiable Amount of time metric values are stored
streaming modifiable Specifies if the metric is enabled for streaming to a collection endpoint
unit Unit for the metric explicitly, and is related to the metric collected各メトリックには、名前、説明、タイプ、関連するオブジェクト、測定単位、および保存ポリシーがあります。また、Real-Time Insightに関連する2つのフィールド、「fineGrained」と「streaming」もあります。
上流のデータベースに関係なく、FineGrainedはメトリックを1秒単位で収集するかどうかを制御します。Streamingは、Splunkや、データを取得するのではなくプッシュされる方式を好むツールを使用する場合に役立ちます。本稿ではストリーミングまたはプッシュ方式のユースケースについては説明しませんが、ドキュメントにはその構成方法が記載されています。
メトリックがどのように定義されるかを理解できたので、いくつか確認してみましょう。
この例では、dbmcliを使用して、データベース・サーバーの1秒ごとのCPU使用率を確認します。
DBMCLI> list metrichistory DS_CPUT
DS_CPUT exapm01dbadm01 3.7 % 2024-03-12T23:00:10-07:00
DS_CPUT exapm01dbadm01 3.4 % 2024-03-12T23:01:10-07:00
DS_CPUT exapm01dbadm01 3.3 % 2024-03-12T23:02:10-07:00
DS_CPUT exapm01dbadm01 3.4 % 2024-03-12T23:03:10-07:00
DS_CPUT exapm01dbadm01 3.4 % 2024-03-12T23:04:10-07:00
DS_CPUT exapm01dbadm01 3.3 % 2024-03-12T23:05:10-07:00
DS_CPUT exapm01dbadm01 3.5 % 2024-03-12T23:06:10-07:00
DS_CPUT exapm01dbadm01 3.3 % 2024-03-12T23:07:10-07:00
DS_CPUT exapm01dbadm01 3.3 % 2024-03-12T23:08:10-07:00
DS_CPUT exapm01dbadm01 3.4 % 2024-03-12T23:09:10-07:00
DS_CPUT exapm01dbadm01 3.3 % 2024-03-12T23:10:10-07:00
DS_CPUT exapm01dbadm01 3.5 % 2024-03-12T23:11:10-07:00
DS_CPUT exapm01dbadm01 3.4 % 2024-03-12T23:12:10-07:00この例では、データベース・サーバーのCPU使用率を1秒単位で収集します。
CellCLI> list metricdefinition DS_CPUT detail
name: DS_CPUT
description: "Percentage of time over the previous minute that the system CPUs were not idle."
fineGrained: Enabled
metricType: Instantaneous
objectType: CELL
retentionPolicy: Default
streaming: Enabled
unit: %もう1つ、今度はストレージ・サーバーの例を見てみましょう。
list metricdefinition FC_IO_BY_R_DW_SEC detail
name: FC_IO_BY_R_DW_SEC
description: "Number of megabytes of large reads (DW) per second from flash cache"
fineGrained: Enabled
metricType: Rate
objectType: FLASHCACHE
retentionPolicy: Default
streaming: Enabled
unit: MB/secこのメトリックのmetrichistoryを確認すると、次のような内容が表示されることがあります。このメトリックが何に関連しているか、分かりますか？
CellCLI> list metrichistory FC_IO_BY_R_DW_SEC
FC_IO_BY_R_DW_SEC FLASHCACHE 0.008 MB/sec 2024-03-12T22:59:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.013 MB/sec 2024-03-12T23:00:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0 MB/sec 2024-03-12T23:01:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.013 MB/sec 2024-03-12T23:02:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.017 MB/sec 2024-03-12T23:03:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.025 MB/sec 2024-03-12T23:04:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0 MB/sec 2024-03-12T23:05:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0 MB/sec 2024-03-12T23:06:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.004 MB/sec 2024-03-12T23:07:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.004 MB/sec 2024-03-12T23:08:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.008 MB/sec 2024-03-12T23:09:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0 MB/sec 2024-03-12T23:10:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.008 MB/sec 2024-03-12T23:11:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.004 MB/sec 2024-03-12T23:12:37-07:00
FC_IO_BY_R_DW_SEC FLASHCACHE 0.004 MB/sec 2024-03-12T23:13:37-07:00各メトリックのmetricTypeに注目してください。ここでは例として2つの「instantaneous」メトリックを使用しましたが、ほかにも興味深い種類のメトリックがあります。収集・表示しているメトリックの種類を理解することで、最適なチャートを作成しやすくなります。
Database ServerまたはStorage Serverでメトリックを有効にするには、それぞれdbmcliまたはcellcliを使用し、alter metricdefinition <metric name> finegrained=enabledを実行するだけです。メトリックを無効にするのも同様に簡単です。ただし、ここで改めて強調したいのは、有用なメトリックの一部はあらかじめ有効化されているため、ユーザー側で設定する必要はないということです。必要なのは、それらの収集を開始し、見やすいグラフで可視化して内容を読み取ることだけです。
Database ServerおよびStorage Serverでの最後の手順は、Prometheusが接続するためのユーザーを各サーバー上に作成することです。
Database Server（VMを含む）ではDBMCLI、Storage ServerではCELLCLIで以下のスクリプトを実行し、メトリックを取得するために必要な権限を持つユーザーを作成します。
CREATE ROLE realtime_collector
GRANT PRIVILEGE LIST ON METRICSTREAM ALL ATTRIBUTES WITH ALL OPTIONS TO ROLE realtime_collector
CREATE USER realtime_collector PASSWORD="Sup3rS3cr3tP@ssword" ### Don't forget to change this password
GRANT ROLE realtime_collector to user realtime_collectordcliユーティリティを使用すると、複数のサーバーにわたるこれらのユーザーの作成を自動化できます。GitHubリポジトリには、その例も含めています。
最後に、次の手順へ進む前に、RESTインターフェースを使用して、メトリックが収集可能な状態で表示されることを確認しましょう。
次のURLパターンを使用します。
https://exadata_server_hostname/metricstream/list?stream=true前の手順で定義したユーザー名とパスワードを使用すると、ブラウザに以下のような出力が表示されるはずです。
CD_IO_BY_R_LG{objectName="FD_00_exapm01celdm01",unit="MB",server="exapm01celdm01.domain.com",fleet="prod",pod="exapm01",rackName="exapm01",rackID="f0d36120-4a4e-390c-8e1f-c894ed331afb",siteName="RWS",siteID="5e72d887-835e-3628-aefe-6749580ec4bb",nodeType="STORAGE"} 3173.8125 1643385465000
...
CD_IO_BY_R_LG{objectName="FD_01_exapm01celdm01",unit="MB",server="exapm01celdm01.domain.com",fleet="prod",pod="exapm01",rackName="exapm01",rackID="f0d36120-4a4e-390c-8e1f-c894ed331afb",siteName="RWS",siteID="5e72d887-835e-3628-aefe-6749580ec4bb",nodeType="STORAGE"} 3060.4375 1643385465000これで、Prometheusを使用したメトリック収集の手順に進みます。
Prometheus
まず、Exadataのメトリックを送信するためのシンプルな時系列データベースが必要です。insight/container/prometheusディレクトリに移動し、Containerfileを確認してください。次のような非常にシンプルなコンテナ・ビルド・ファイルが表示されます。
FROM prom/prometheus
VOLUME ["/prometheusdata"]
ADD prometheus.yml /etc/prometheus/
ADD all_exadata_nodes.json /etc/prometheus/これらの各項目を順に確認していきましょう。
FROM prom/prometheusこれは、使用するイメージの名前です。ここではPrometheusの最新バージョンを使用することを前提としていますが、特定のバージョンを指定してもよいでしょう。
VOLUME ["/prometheusdata"]Prometheusはデータベースなので、再起動後もデータを利用できるよう、どこかに永続化する必要があります。
ADD prometheus.yml /etc/prometheus/この行では、prometheus.ymlファイルをイメージ内の/etc/prometheusディレクトリにコピーします。ファイル全体はGitHubリポジトリで確認できますが、scrape_configsセクションは次のとおりです。
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'exadata'
metrics_path: metricstream/list
scheme: https
params:
stream: [true]
basic_auth:
username: realtime_collector
password: Sup3rS3cr3tP@ssword ## Change this to your secure password
file_sd_configs:
- files:
- 'all_exadata_nodes.json'
tls_config:
insecure_skip_verify: true
# Drop cumulative metrics from the stream
metric_relabel_configs:
- source_labels: [__name__]
regex: '(CD_IO_BY_R_LG|CD_IO_BY_R_SM|CD_IO_BY_W_LG|CD_IO_BY_W_SM|CD_IO_RQ_R_LG|CD_IO_RQ_R_SM|CD_IO_RQ_W_LG|CD_IO_RQ_W_SM|CD_IO_TM_R_SM|CD_IO_TM_R_LG|CD_IO_TM_W_SM|CD_IO_TM_W_LG)'
action: drop
- source_labels: [__name__]
regex: '(FC_COL_IO_BY_R|FC_COL_IO_BY_R_ELIGIBLE|FC_COL_IO_BY_SAVED|FC_COL_IO_RQ_W_POPULATE|FC_COL_IO_BY_W_POPULATE)'
action: drop
- source_labels: [__name__]
regex: '(SIO_IO_EL_OF|SIO_IO_OF_RE|SIO_IO_PA_TH|SIO_IO_RV_OF|SIO_IO_RD_FC|SIO_IO_RD_HD|SIO_IO_RD_FC_HD|SIO_SIO_SI_SV)'
action: drop
- source_labels: [__name__]
regex: '(FC_IO_BY_R|FC_IO_BY_R_DISK_WRITER|FC_IO_BY_R_DW|FC_IO_BY_R_MISS|FC_IO_BY_R_SKIP|FC_IO_RQ_R|FC_IO_RQ_R_DISK_WRITER|FC_IO_RQ_R_DW|FC_IO_RQ_R_MISS|FC_IO_RQ_R_MISS_DW|FC_IO_RQ_R_SKIP)'
action: drop
- source_labels: [__name__]
regex: '(FC_IO_RQ_W_DISK_WRITER|FC_IO_RQ_W_METADATA|FC_IO_RQ_W_POPULATE|FC_IO_RQ_W_SKIP|FC_IO_BY_W|FC_IO_BY_W_DISK_WRITER|FC_IO_BY_W_METADATA|FC_IO_BY_W_POPULATE|FC_IO_BY_W_SKIP)'
action: drop
# Change disk and flash device metric names for readability
- source_labels: [objectName]
regex: '(^nvme.*)'
replacement: 'flash:$1'
target_label: objectName
action: replace
- source_labels: [objectName]
regex: '(^sd.*)'
replacement: 'disk:$1'
target_label: objectName
action: replace最後に、prometheus.yml構成ファイルには、all_exadata_nodes.jsonへの参照があります。このファイルには、Prometheusがメトリックを取得するすべてのDatabase ServerおよびStorage Serverを登録します。
ファイル形式の例はGitHubリポジトリに含まれており、次のようになっています。Storage Server（Cell）はデフォルトでポート443を使用し、Database Serverはポート7879を使用する点に注意してください。
[
{
"labels": {
"job": "exadata"
},
"targets": [
"exadbadm01.domain.com:7879",
"exadbadm02.domain.com:7879",
"exadbceladm01.domain.com",
"exadbceladm02.domain.com",
"exadbceladm03.domain.com",
"exadbadm01vm01.domain.com:7879",
"exadbadm02vm01.domain.com:7879",
"exadbadm01vm02.domain.com:7879",
"exadbadm02vm02.domain.com:7879"
]
}
]ご覧のとおり、各データベース・サーバー（およびVM）とストレージ・サーバーが、Real-Time Metricsで構成されているポート番号とともに一覧表示されています。
これでコンテナの定義が完了したので、コンテナをビルドして起動できます。
$ podman build -t realtime_prometheus .私の場合、Prometheusイメージはすでにダウンロード済みなので、表示される出力は私のものとは異なる場合があります。
STEP 1/4: FROM prom/prometheus
STEP 2/4: VOLUME ["/prometheusdata"]
--> Using cache 5331179832b36a2b945e8a411956b37f3dbb35401883e7e1addbd90049a2e3c9
--> 5331179832b3
STEP 3/4: ADD prometheus.yml /etc/prometheus/
--> Using cache 61200cba233a3c70da35400abf6edd084d775adf596615b3181ce7616bf7d48e
--> 61200cba233a
STEP 4/4: ADD all_exadata_nodes.json /etc/prometheus/
--> Using cache fad1303c6f25c93a5fd84cfd50f9bc621b13b4ef6edce5107e7da0724782ce1d
COMMIT realtime_prometheus2
--> fad1303c6f25
Successfully tagged localhost/realtime_prometheus:latest
fad1303c6f25c93a5fd84cfd50f9bc621b13b4ef6edce5107e7da0724782ce1dこれで、コンテナを起動し、適切なポートをマッピングできます。
$ podman run --name=realtime_prometheus -v prometheusdata:/prometheus -d -p 9090:9090 realtime_prometheusすべてが想定どおりに動作していることを確認するには、ブラウザでhttp://podman_server_hostname:9090というURLを使用してコンテナに接続します。すると、以下の画像のような画面が表示されます。
CD_IO_BY_R_LG_SECを検索すると、メトリックが収集されていることを確認できます！
ここまで問題なく進んでいれば、Exadataのメトリックがコンソールに表示され始めるはずです。自由に確認していただいて構いませんが、ここでは先に進み、見やすいチャートを表示できるようGrafanaをセットアップしましょう。
Grafana
Prometheusと同様に、Grafanaもコンテナで起動します。まず、insight/container/grafanaディレクトリにあるContainerfileを確認しましょう。
今回もGrafanaの最新コンテナ・イメージを取得します。この例では、Enterprise版ではなくOSS版を使用しています。
FROM grafana/grafana-ossそして、コンテナにいくつかの設定を組み込みます。具体的には、GrafanaをPrometheusに接続するためのデータ・ソースを追加します。
ADD ./datasources/*.yaml /etc/grafana/provisioning/datasourcesコンテナをビルドする前に、exa-real-time-insight-ds.yamlファイル内のURLを更新し、Prometheusコンテナを参照するようにしてください。また、正しいポートが指定されていることも確認してください。
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
# Make sure you update the hostname below to that of the hostname your container is running on (and don't forget to remove the {{}}).
url: http://podman_server_hostname:9090/
jsonData:
httpMethod: POST
manageAlerts: true
prometheusType: Prometheus
prometheusVersion: 2.50.0
cacheLevel: "High"
disableRecordingRules: false
incrementalQueryOverlapWindow: 10m最後に、Real-Time InsightリポジトリにあるOracle提供のダッシュボードをコンテナ内に配置し、自動的に読み込まれるようにします。
ADD ./dashboards/*.yaml /etc/grafana/provisioning/dashboards
ADD ./dashboards/*.json /etc/grafana/provisioning/dashboardsこれでイメージをビルドできます。
$ podman build -t realtime_grafana .起動するには、以下を実行します。ローカル・マシンのポート3000をコンテナ内のポート3000にバインドしている点に注意してください。
$ podman run -d --name=realtime_grafana -p 3000:3000 realtime_grafanaこの時点で、Grafanaが起動していること、データ・ソースが定義されていること、および提供済みのダッシュボードを追加できることを確認する準備が整っているはずです。
任意のブラウザでhttp://podman_server_hostname:3000にアクセスし、Grafanaのデフォルトのユーザー名とパスワードであるadmin/adminを使用してログインすると、Grafanaのホームページが表示されます。
左側のメニューから「Data sources」に移動し、データ・ソースが正しく作成されていることを再確認してください。
すると、このページが表示されます。ホスト名は伏せています。
次に、ビルド時にインポートしたダッシュボードを確認しましょう。左側のメニューから「Dashboards」に移動します。
「Exadata」フォルダを展開すると、GitHubリポジトリで公開されている7つのサンプル・ダッシュボードが表示されます。
「Exadata Cluster」ダッシュボードを開くと、次のような画面が表示されます。ご覧のとおり、このダッシュボードはPrometheusからデータを取得し、CPU使用率、クライアントおよびRDMAネットワーク・トラフィック、さらにStorage ServerのCPU使用率の一部を表示しています。各ダッシュボードを開くと、トピックごとにさらに詳しいグラフを確認できます。
これらはあくまで出発点として用意されたものです。クラスタ、ワークロード、環境ごとに異なるデータを表示する独自のダッシュボードを作成することもできます。可能性はほぼ無限です！
ひと息つきましょう！
さて、ついに完了です。ここまでたどり着き、すべてが想定どおりに進んでいれば、Exadata Database ServerおよびStorage Serverから、多数の有用なリアルタイム・メトリックが生成されているはずです。これらのメトリックはPrometheusによって収集され、そのデータをもとにGrafanaで有用なダッシュボードが表示されています。
記事の冒頭で述べたとおり、Enterprise Manager、Exawatcher、AWRなどのツールは非常に有用であり、発生した問題の診断や解決に日常的に使用することになります。Real-Time Insightは、これらのツールを補完し、「今」に関する情報、つまりこの瞬間にシステム上で何が起きているのかを可視化することで、診断およびトリアージのワークフローを迅速化します。
最後に、このクイック・スタートはGitHubリポジトリで公開されています。ぜひお試しください。Exadata Real-Time Insightをすばやく立ち上げ、その機能を体験し、メリットを得られるようにすることを目的としています。コードに問題を見つけた場合、提案がある場合、またはぜひ共有したい優れたダッシュボードがある場合は、フィードバックをお寄せください。
推奨資料