Oracleコミュニティ活用法 [コミュニティ]

1.はじめに

近年、プロジェクトを経験を通して障害の再発防止(不具合や利用方法の理解不足)について有識者の勉強会などで地道に展開を図ってきた。しかし、そもそも身近なDB技術者が少なく、かつ、題材を提供する側の制約もあり、ノウハウ量が絶対的に少ないという課題を持ってきた。

2018年のOOWに参加した際、Oracleコミュニティ活動をしているACEディレクターの講演を聞く機会があり、「有償サポートがあるのにコミュニティを使う意味があるの?」と疑問に思っていた自分に、改めてその活動内容に興味を持つきっかけとなった。ここ数カ月間、コミュニティ活動を実際に行うことを通して、Oracleコミュニティの活用方法について考えてみた。

2.Oracleコミュニティとは
 Oracle製品に関するユーザ同士の情報を交換するコミュニティ。閲覧は自由だが、投稿にはOTNアカウントが必要である。以下からアクセスできる。あくまでユーザ同士の情報交換の場であり、サポートは受けられない。
https://community.oracle.com/welcome

特徴として、参加を促す仕組みとしてポイント制が導入されていること。ポイントに関する詳細は以下のリンクを参照。

https://community.oracle.com/docs/DOC-889071

3.Oracleコミュニティ紹介
 無数にあるコミュニティ(スレッド)の中から、Oracle Database関連をいくつかピックアップする。当然ではあるが、やりとりはすべて英語である。なお、MOSCとついているスレッドは、My Oracle Supportの検索に引っかかる記事となる。

(1)General Database DIscussions:著名な有識者がAWRの解析やSQLチューニングの助言をしている。私が個人的に尊敬しているJohnathan Lewisさんもこのスレッドに投稿しており、大変勉強になる。
(2)SQL Performance(MOSC):SQLチューニングに関するスレッド。大抵はSQL遅延に関する相談が多い
(3)Database Tuning(MOSC):インスタンスチューニングに関するスレッド
(4)Database Administration(MOSC):DDLのエラーの対処方法など、DB管理の幅広い問い合わせに関するスレッド

4.コミュニティ活用例
 以下が自分が実際にコミュニティを使ってみた事例である。
 
(1)SQL性能遅延の問い合わせ
 https://community.oracle.com/thread/4189736
 遅延SQLの実行計画(SQLトレース等)から原因を解析した例。実際にトレースを読んで、WHERE句のTO_NUMBERに原因があることをコメントした。結果、暗黙の方変換が発生していたことが判明した事例。
(2)時々遅延するSQLの原因解析
 https://community.oracle.com/thread/4193672
 実行計画が不安定になることにより性能が時々遅延しているように見えるとコメント。結果、一部の統計情報が最新ではなかったことが判明した事例。
(3)アイディア投稿
 https://community.oracle.com/ideas/23746
 direct path readのHINTを追加してはどうか、という意見に対して、Oracle ACEと隠しパラメータとの違いを議論
(4)製品(Oracle goldengate)の入門用ドキュメント
 https://community.oracle.com/thread/4194521
 GGの初歩的な入門資料でいいものがないか問い合わせを行った結果、1時間かからないうちにホワイトペーパーを紹介して貰えた
(5)ノウハウをワールドワイドに共有
 https://community.oracle.com/docs/DOC-1029199
 本ブログの記事「トランケートについて知っておくべきこと」を英語にして共有

5.ポイントについて
 アクティビティに応じてポイントが加算される仕組みがある。たとえば、返信は5、感謝は50、正解は100ポイントといった具合である。累積ポイントにより称号が与えられる。0ポイントのレベル0(newbie)から始まり、75万ポイントのレベル21(community wizard)まで果てしない。ポイントを稼ぐために、「ミッション」が用意されており、規定されるアクティビティをクリアすると、まとめてポイントを獲得できる。たとえば、感謝10回達成で75ポイントなど。

6.オラクルコミュニティ活用シーン
(1)スキルアップの手段として
 ・その分野の有識者がQAに答えているので、勉強になる題材が豊富
 ・SQL遅延トラブルなど「あるある」ネタのケーススタディとして勉強会のトピックとして活用ができそう
 ・質問に回答しようとすると、根拠を説明するために仕様を調べる必要があるので、自らの知識の再整理のきっかけともなる
(2)有識者からの第三者チェック手段として
 ・事象の解析や不具合のワークアラウンド等、ワールドワイドの有識者から第三者チェックとして活用ができそう。ただし、問題を明快に(英語で)説明する必要はある
(3)製品エンハンスリクエストのニーズ調査として
 ・アイディアを投稿すると、投票が活発に行われるかどうかで、一般的に興味のある内容かどうかが判断できそう

以上
nice!(0)  コメント(0) 

direct path readを強制するHINTについて [オプティマイザ]

最近特に寒い。相変わらずExadataの性能遅延と戦っている。

以前direct path readについて記事を書いたが、その続きを記載する。

現実逃避がてら、Oracle Communityでダイレクトパスリードを指定するHINTの導入をアイディアとして投稿してみた。

hint to enforce FULL SCAN with direct path read
https://community.oracle.com/ideas/23746

---
Parallel hint can be used for enforcing direct path read, but there's no hint for serial direct path read.
Serial direct path read is hard to control; it depends on several factors such as;
- FULL SCAN
- segment size and buffer cache size
- the num of blocks cached on buffer cache
Besides, the above logic is not written in manual and different from version to version.

So I would like to propose adding a hint like "FULL_DIRECT_PATH( emp )" to enforce FULL SCAN with direct path read.
This could be not only used to enforce optimizer serial direct path read but also ensuring smart scan on Exadata.
----

Oracle ACEの方からは早速このアイディアに対して_serial_direct_readパラメータがあるのにHINTいるの?というツッコミを貰った。確かに以下のようにセッションレベルで変更できる。

alter session set "_serial_direct_read"=always;

ただ、もしHINTがあったとすれば、以下のようなメリットがあるのでは?とコメントした。
・セッションレベルでなくSQLレベルで制御できること
・複数の表を結合する場合、特定の表だけを指定することができる
・きちんとマニュアルに記載される(隠しパラメータはMOSだけ)

なお、1点目に関してはopt_param('_serial_direct_read','always') が使えれば解決する。しかし、私の手元の環境(12.2)ではなぜかうまく動いてくれなかった。指定の仕方が良くないのかもしれないが原因不明のままである。

このアイディアに対しては、今のところこのOracle ACEの方からのみの投票。仕組みがよくわかってないのだが、投票は+10ポイント、否決票は-10ポイントという形で投票していくようである。トップアイディア見ると6,000ポイント以上集まっているが、これがたまっていくと、将来もしかすると機能拡張されたりするのか?と思うと少しモチベーションがあがる。

といっても、今20ポイントなので、見込み薄ではあるが。

以上
nice!(1)  コメント(0)