当ブログの別記事「統計収集操作レポートの作成」で紹介したものと同様の内容をEnterprise Manager Cloud Control（EMCC） で確認することができます。

この記事ではEMCCを使って統計収集操作の実行履歴を確認する方法をご紹介いたします。

EMCCで見る統計収集操作レポート

EMCCでは「オプティマイザ統計コンソール」を使うことで統計収集操作の実行履歴や統計収集ジョブのレポートにアクセスすることができます。

オプティマイザ統計コンソールの表示

統計収集の情報を確認したいデータベースのホームページに移動します。お好みの方法で移動してください。

【補足】
EMCCコンソール上部の メニューから「ターゲット（下図の①）」>「データベース」を選択してデータベース・ターゲットの一覧を表示し、目的のデータベースにアクセスできます。

また頻繁にアクセスするターゲットであれば「履歴（下図の②）」使って目的のデータベース名を選択するのも早いです。

データベースのホームページに移動した後は、メニューから「パフォーマンス」>「SQL」>「オプティマイザ統計」と選択します。

「オプティマイザ統計コンソール」が表示されます。

このページの下部には「統計採取ジョブ・リスト」としてオプティマイザ統計収集の実行履歴が一覧表示されています。「統計収集操作レポートの作成」で「統計操作タスクレポート」という名前で紹介したレポートとは表示内容が異なりますが、各ジョブの実行に要した時間（期間）が棒グラフであったり、より視覚的なものになっています。

オプティマイザ・ジョブ統計レポートの表示

「統計採取ジョブ・リスト」の「操作名」欄の内容はリンクになっています。このリンクをクリックすると、対応するジョブの詳細なレポートを表示することができます。

表示されたページは「オプティマイザ・ジョブ統計レポート」というタイトルになっています。この内容自体は「統計収集操作レポートの作成」で「統計操作タスクレポート」と同じ内容のものです。

おわりに

Oracle Database のオブティマイザ統計収集について、その実行履歴をEMCC上で確認する方法をご紹介しました。いかがでしたでしょうか。

皆さんの参考になれば幸いです。

統計収集操作レポート（EMCC）

こんにちは。
未来の敏腕営業つぼいです。

本日は、6/17に幕張メッセで行われたInteropに行ってきたのでレポしていきたいと思います。
Interopとは→コチラ

じゃじゃん！海浜幕張に着いたら早速こんなものが。


夢の国舞浜を通り過ぎても賑やかな電車で到着後、そのまま人の流れに無心で付いていったら無事たどり着けました。
これは大混雑なのでは？！という予想通り、私が到着した10時半頃にはすでに入場待ちの列ができていました。

事前登録の紙を印刷して持っていかねばならず、会社で印刷したものを持参しました。
入場時にケースをもらい、そこに名刺とその紙を入れて検温・消毒を済ませたらいざ入場！


わああああああああああああああああ！


この光景だけでテンションが上がり、すでに楽しかったです。(笑)

が、もちろんれっきとした、真面目なITイベントです。
ワクワクしながら知っている企業の名前を見つけ勇み足で向かったわけですが、専門用語や難しい図解の数々、、、私の気合とワクワク気分は一気にしぼんでいきました。
当たり前ですが、ブースの方々もこちらがある程度の知識がある前提で、特定の目的がある前提で話しかけてきます。
周りを見てみると専門的なやり取りがあったり、具体的なビジネスの話が始まっていたり、ここでやっと自分が場違いなことに気づきました。


でもせっかく来たんだし、このイベントを自分なりに楽しもう！
そう思って、以前の職場で使っていたシステムを作っている会社さんを見つけ、そのブースに向かいました。
自分が使ったことのあるシステムの仕組みを知りたいと伝えると、嫌な顔ひとつせずに丁寧にわかりやすく教えてくださったのです！
こちらに専門的な知識がないことも話の流れで悟ってくださったのか、ただただ勉強させていただいたような感じでした。
その流れでその会社さんが新しく始めたサービスについても興味があったので、詳しく説明していただきました。
こちらは専門分野というよりは管理部門サイドに近いお話だったので、意見交換もしつつたくさんお話を聞くことができました。

なるほど、私は知らないことをどんどん聞くやり方で楽しもう！
なんとなく自分なりの楽しみ方がわかったので、その後はお昼休憩の時間もギリギリまで使ってたくさんのブースを回りました。
忙しい人気のブースはさすがに避けたけど、"勉強中なんです"と正直に話すとどの企業さんも優しく説明してくださって、感謝カンゲキでした。
その中で私はこれに興味があるのかも？と思った分野は同じようなブースやセッションをはしごしたりして、とても有意義な時間を過ごせたと思います。


資料やいただいたノベルティで荷物が重くなってきた頃、当社Re:Qの講演時間が迫ってきました。

まずは１コマ目、
"SRE定着に向けての取り組み～「形」から「運用」へ～"
クラウド基盤技術部の部長が登壇しました。



社内での新人研修や外部での講師経験も豊富なＮ部長、さすが慣れた様子でスムーズに話していました。
途中で一斉に来場者の皆さんがカメラを構えたりメモを取る音が聞こえたときはとても嬉しかったです！
アンケートの回収率も上々で、実際に話を聞きたいというコメントも多数いただきました。
ここからのフォローアップは我々企画本部の仕事です。
良いご縁につながるように、頑張るぞ～！


１コマ開けて、次はDB技術2部のY部長による、
"データの流れを止めない！データドリブン経営のためのデータ基盤構築"


DX summitでも人気だったこちらの講演、なんと開催前から事前登録をたくさんいただいており残席僅かの状態で開演でした。

開場前にも長蛇の列ができており、講演中もどんどん人だかりが、、！
満員御礼、立ち見続出で大人気でした。



今注目のテーマであること、内容は難しかったけど、色んな企業さんでの課題なんだなあと私自身も勉強になりました。


Re:Qはこれからも外部でのイベントに積極的に参加していく予定です。
講演やブース出展、また採用イベントにも定期的に出展しています。
ＩＴインフラに特化したすごい会社があるぞ！と多くの方に知ってもらって、色んなことに興味のある仲間をもっと増やして、会社やこの業界がもっと盛り上がったらいいなあと思った１日でした。


最後に、大活躍した両部長の記念撮影。
キマッてますね！
撮影の裏側はつぼいのTwitterでバラしているので、ぜひ(笑)

【1-9】Interop22に行ってきた思い出話

こんにちは。
未来の敏腕営業つぼいです。

ついに関東も梅雨入りしましたね。
おそらく大多数の方と同様に、雨より晴れが好きなので梅雨明けが待ち遠しいです。
私はジグソーパズルを1つ完成させようと思っているのですが、皆さんの梅雨の過ごし方もぜひ教えてください！

今回も日記らしいブログになりますので、片手間にお楽しみいただければと思います。


最近は、"朝の通勤ラッシュ"・"人が多くて電車に乗れない"（経験済）というワードを聞く頻度が増えてきて、在宅勤務を打ち切る会社と在宅システムを確立させた会社とで分かれてきたのかなーなどと感じているのですが、皆さんはどんな働き方をしていますか？

当社はフルリモートだといくつか前のブログでお伝えしておりましたが、それも変わりつつあり、私は最近週1～3くらいの頻度で出社しています。
というのも、お客さん先に出向いたり会食に行ったり、はたまた社内で打ち合わせを～という機会が増えてきたのです。
それでも丸一日社内にいる必要はなく、会食であれば午後から出社でＯＫだし、午前中に訪問の打ち合わせがあれば昼休みに帰宅もＯＫだし、ただとりあえず出社せよというコンセプトでは今のところないので、働きやすさはそこまで変わらないように思えます。
（もちろん丸一日今日は社内で仕事するぞ、もＯＫです。）
エンジニアの部署でも、月に1回出社日を決めて出れるメンバーで集まっているようです。
作業などの関係で毎回全員勢揃い！は難しいかもしれないけど、これなら負担感もなく出社日が楽しみになるんじゃないかなと思っています。
色んな会社が働き方について考える、新しいフェーズに入ってきたのかもしれませんね。


それでは最近の出社日の様子です。



私が所属する企画本部（営業部は企画本部の中にあります）では、現在コーポレートサイトの改修に取り組んでいます。
この営業日記もそうですが、他の記事を読もうと思ったらトップページに戻って技術ブログのコーナーに行って、、、となかなか遠い道のりですよね。
他にもスマホ対応だったりカテゴリの見直しなど、より見てもらいやすいホームページを目指しています！
これは見え方を相談している様子。
新バージョン公開は近々の予定です。楽しみ～！！


そしてそして、これは夜にお世話になっている会社さんと会食に行った時のお肉です。
びっくりするくらい美味しいワインをペアリングしながらいただきました。



サイズ感が上手く伝えられなくて悔しいのですが、、私が使っている会社のノートＰＣを横に2つ並べて更にもう少し大きいサイズなんです！
これは夢がありますよね！

以前の会食デビューのブログでもお伝えした通り、Re:Q社長の紙屋さんのお店選びは秀逸で、ご一緒した会社の皆様もいつも楽しみにしてくださっているとのこと。
美味しいものをいただきながら、これから更に盛り上がっていくプロジェクトの話や、プライベートでもひょんな共通点が見つかったり、とても楽しい時間を過ごさせていただきました。
社内での立場はとても偉い方々なのに、ご一緒していると学校の先輩のような、親戚のような、とても親しみやすく素敵な皆さんでした。
人となりがわかると余計に、どうしたら力になれるんだろう、もっと良い提案がしたいな、という気持ちが強くなりました。


まだまだ初心者マーク付きの営業ではありますが、大切なお客さん一人一人のお顔を思い浮かべながら、これからもめげずに頑張っていこうなどと思っています。

【1-8】最近の出社のお話

Data Guard（フィジカル・スタンバイ・データベース）では、管理リカバリ・プロセスのステータス確認が重要です。V$MANAGED_STANDBYビューを使って、どこまでの情報が同期されたかアーカイブログのスレッドと順序番号を確認することができます。

しかしながら Oracle Database 12cリリース2 (12.2.0.1) 以降、V$MANAGED_STANDBYビュー は非推奨になりました。代わりに V$DATAGUARD_PROCESSビューを使うようアナウンスされています。

【補足】
本記事時点の長期リリースである19cにも V$MANAGED_STANDBYビューは存在しています。また最新のイノベーション・リリースである21c でも存在を確認しています。今しばらくは V$MANAGED_STANDBYビューを使うことはできます。

V$MANAGED_STANDBYビューでの確認

管理リカバリ・プロセス（MRP0）の確認をする際に、以下のような問合せを実行しているケースがあると思います。

※記事中のSQL文は SQL*Plusで "SET MARKUP CSV ON" を設定して実行しています。

SQL> SELECT PROCESS,PID,STATUS,THREAD#,SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS='MRP0'; "PROCESS","PID","STATUS","THREAD#","SEQUENCE#" "MRP0","209078","APPLYING_LOG",2,224

スレッド2の順序番号224のアーカイブログを適用中（STATUS=APPLYING_LOG）であると判別できます。

V$DATAGUARD_PROCESSビューでの確認

従来 V$MANAGED_STANDBYビューで行なっていた内容を V$DATAGUARD_PROCESSビューに置き換える場合は次の問合せ文が使えます。

SQL> SELECT NAME,PID,ACTION,THREAD#,SEQUENCE# FROM V$DATAGUARD_PROCESS WHERE NAME='PR00'; "NAME","PID","ACTION","THREAD#","SEQUENCE#" "PR00","209083","APPLYING_LOG",2,224

変更は次の二つです。

・PROCESS列とSTATUS列をそれぞれNAME列とACTION列に置き換えています。
・WHERE句でPROCESS列に指定していたプロセス名を"MRP0"でなく"PR00"にしています。

"PR00"はメディア・リカバリをパラレル実行するためのプロセスです。この例では簡略化のためWHERE句のプロセス名"PR00"と決め打ちしています。実際には数字部分の異なる複数プロセスが存在しますのでご注意ください。"PRnn" と表されるもので製品ドキュメントでは次のように説明されています。

PRnnは、パラレル・メディア・リカバリを実行しているコーディネータ・プロセスのスレーブ・プロセスとして機能し、コーディネータにより割り当てられたタスクを実行する。このプロセスのデフォルトの数は、CPUの数に基づいている。

Oracle Databaseデータベース・リファレンス, 19c  / F バックグラウンド・プロセス より引用

ちなみに、この例のデータベース・インスタンスには3つ存在していました。

"PR00"のほかに"PR01"と"PR02"が表示されています。問い合わせにROLE列を加えてみたところ、"PR00"と"PR01","PR02"では役割が異なるようです。

SQL> SELECT NAME,PID,ACTION,THREAD#,SEQUENCE#,ROLE FROM V$DATAGUARD_PROCESS WHERE NAME LIKE 'PR%'; "NAME","PID","ACTION","THREAD#","SEQUENCE#","ROLE" "PR00","209083","APPLYING_LOG",2,224,"recovery logmerger" "PR02","209087","IDLE",0,0,"recovery apply slave" "PR01","209085","IDLE",0,0,"recovery apply slave"

ついでに確認

MRP0 を問い合わせた場合

V$DATAGUARD_PROCESSビューへの問合せで、V$MANAGED_STANDBYビューと同じようにプロセス名を"MRP"にした場合を確認してみます。

SQL> SELECT NAME,PID,ACTION,THREAD#,SEQUENCE# FROM V$DATAGUARD_PROCESS WHERE NAME='MRP0'; "NAME","PID","ACTION","THREAD#","SEQUENCE#" "MRP0","209078","IDLE",0,0

プロセスのステータスは"IDLE"、アーカイブログのスレッドと順序番号はどちらも "0" と示されてしまいました。V$MANAGED_STANDBYビューと同じつもりで "MRP0" を指定しないようにご注意ください。

V$MANAGED_STANDBY と V$DATAGUARD_PROCESS の比較

少々しつこいかもしれませんが、もう一つ問合せの例を取り上げます。二つのビュー、V$MANAGED_STANDBYとV$DATAGUARD_PROCESSへの問合せを比較してみます。

それぞれのSELECT文を UNION ALL で結合します。また問合せ対象のビューが分かるようにREF_VIEW列としてビュー名を表示しています。

SQL> SELECT 'V$MANAGED_STANDBY' REF_VIEW,PROCESS,PID,STATUS,THREAD#,SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS='MRP0' UNION ALL SELECT 'V$DATAGUARD_PROCESS' REF_VIEW,NAME,PID,ACTION,THREAD#,SEQUENCE# FROM V$DATAGUARD_PROCESS WHERE NAME='PR00'; "REF_VIEW","PROCESS","PID","STATUS","THREAD#","SEQUENCE#" "V$MANAGED_STANDBY","MRP0","209078","APPLYING_LOG",2,224 "V$DATAGUARD_PROCESS","PR00","209083","APPLYING_LOG",2,224

上段が V$MANAGED_STANDBYビューの内容、下段が V$DATAGUARD_PROCESSビューの内容です。プロセス名とOSのプロセスID（PID）が違うことを除くと、プロセスのステータスとアーカイブログのスレッド、順序番号は同じ値を確認できます。

おわりに

Oracle Database 12cリリース2 以降のV$DATAGUARD_PROCESSビューをつかった管理リカバリの実行状態の確認方法をご紹介いたしました。

本記事の内容がひとつの例として、皆さんの参考になれば幸いです。

Data Guard 管理リカバリの実行状態確認