Oracle DBA Mentorを読んで [書評]
コロナのワクチンは広まるものの都内の感染は収まる気配はなく、そんな中でオリンピック開幕を迎えた。プロジェクトの合間ということで少し長めの休みを頂いたので、ようやくため込んでいた本に手を伸ばす時間ができた。本日はブライアン・ピースランド(Brian Peasland)氏のOracle DBA Mentor（2019年に出版）という本について紹介したい。
著者はOracleデータベースで20年以上のキャリアを持ち、My Oracle Support Community(MOSC)やOracle developer communityで活躍されている方である。私自身、MOSCでたびたび彼の有益なコメントを見かけることがあり、どんな方なのか興味を持ち、彼のBlogからこの本の存在を知るに至った。
本書の構成は以下の通り。１、２章でDBAの役割と他人とのかかわり方といったソフトスキルについて述べている。３～８章は自分用の検証環境のセットアップについて、９～１２章はデータベースの使い方について、様々なツールを使ってテスト環境に接続し、テストしたりログを確認する方法について述べている。１３～１６章がこの本の核で、未知の問題に対する答えの見つけ方について、マニュアル、ディクショナリ、MOS、ソーシャルメディア（コミュニティ）の利用について述べている。１７～１９章はパッチ適用やアップグレード、キャパプラなど先にセットアップした環境のメンテナンス方法について、２０、２１章は、Oracleのアーキテクチャとオプションについての概要が述べられている。
一見、Oracleの検証環境の構築方法が画面のスナップショットとともに丁寧に解説されているため、よくある初心者向けの手引きと勘違いしてしまうかもしれない。確かに、Oracle VM上にOracle LinuxからOracle Databaseを構築する手順が一通り乗っているので、これだけで手元のシングルインスタンスのテスト環境を作ることができる。若干バージョンは古い（12.2）ものの、読み替えれば十分最新のバージョンでも使える内容だろう。しかし、本書は純粋なOracleの技術のhow to本ではない。この本がユニークなのは、より根底にあるDBAという職業（Profession）についての考え方、心構えと、DBAとして自ら成長していくための方法、アドバイスを、自らの経験からつづった点である。
本書では、ITの世界でDBAは尊敬されるべき職業（well-respected profession）であり、そして同時にDBAたるもの、その位置づけを保つだけの行動を求められると説いている。AP開発からDBAになる、インフラ管理者からDBAになる、いろいろなパスはあれど、DBAを職業とするなら、業務から要求される様々な（時には理不尽な）要求に対して、単にNGを突きつける失礼な(rude)DBAになってはならない、DBAたるものは真の実現したい要件を関係者から聞き出し、現実解を導くような存在でなければならないと述べている。また、その過程で必要となる様々な人とのコミュニケーションにおいては、説明する相手に対して理解し易い言葉選び（例えばバッファキャッシュについて述べるにしても、説明する相手によっては単にキャッシュと言ったり、データベースメモリと言ったりといった配慮）をすることの重要性を述べている。このようなDBAの職業についての考えには、私自身の現場での経験に照らしてみても深く共感するところがあるし、もっと早くこの本に出合えていればと率直に感じた。
本書の主要なテーマの１つである、未知の問題にどう対処していくか、の記述は興味深かった。よくあるhow toはユースケースに応じたやり方は書いてあるが、そのような本では未知の問題には対処できない。まず、Oracleでこれってできる？といった無邪気な問いは、人に聞く前に自ら実機での動作確認を行い、検証することの重要性を述べている。失敗を通して学ぶことは多いこと、成功の条件を明確に定義することの重要性など、言われれば当たり前のことではあるが、Oracleコミュニティでの苦い経験を通しこのように行動することを重要性を改めて述べているのだろう。
本書の核となる部分のはじめに記載されているのは、マニュアルを読むことの重要性である。RTFM(Read The Fine Manual)という言葉は初めて聞いたが、おそらくコミュニティにおいてマニュアルに記載されていることを問い合わせる質問が投稿されたときの返答に使う略語なのだろう。有識者に聞くなら、自分で調べてから聞くべきで、有識者にマニュアルのここに記載されていることを調べさせるというのは礼を欠いている、というのである。RTFM的な質問をするなら、ドキュメントを確認した上で、それでも困難であることを質問すべきであろうと。Oracleのマニュアルは確かにボリュームが多く、これを全て読むことは不可能だが、著者が説いているのは、どこに何が書いてあるかを理解することはOracle DBAとしての必須スキルということである。本書にはインストール、管理、2日ガイド、概念ガイド、管理者ガイド、パフォーマンスガイド、エラーメッセージ、バックアップ・リカバリ、SQL言語リファレンスなど、マニュアルの主要なカテゴリについての説明は全体像を理解するのに役に立つだろう。
MOSの使い方の次に述べられているのが、ソーシャルメディアの活用である。ここでまず述べられているのは、ブログを書くことのススメである。著者は、難しい問題を解決したとき、新しいことを学んだとき（tips）、心に浮かんだことで誰かに共有したいこと、といったことをDBAとしてブログに綴っているそうだ。これにより自分自身の理解を深めるだけでなく、解決策が他の人の助けになれば、さらに未来の自分自身の助けにもなると言っている。本書にはOracleについて素晴らしいブログのリストが記載されいるが、Jonathan Lewis氏やTim Hall氏など私も過去googleで検索してよく見るブログばかりである。ブログの他にも、ツイッターやAsk TOM、Oracleのディスカッションフォーラム、カンファレンスやユーザグループなど、有益な情報ソースや活用方法について記載されており、とてもすべて活用できる気はしないが、何かあったときに参考になるだろう。Oracleを取り巻く技術者の層の厚さを改めて感じる。
DBAという職業についてより理解を深め、プロフェッショナルとしてさらに成長したいと考えている方には、一読をお勧めしたい本である。
以上
著者はOracleデータベースで20年以上のキャリアを持ち、My Oracle Support Community(MOSC)やOracle developer communityで活躍されている方である。私自身、MOSCでたびたび彼の有益なコメントを見かけることがあり、どんな方なのか興味を持ち、彼のBlogからこの本の存在を知るに至った。
本書の構成は以下の通り。１、２章でDBAの役割と他人とのかかわり方といったソフトスキルについて述べている。３～８章は自分用の検証環境のセットアップについて、９～１２章はデータベースの使い方について、様々なツールを使ってテスト環境に接続し、テストしたりログを確認する方法について述べている。１３～１６章がこの本の核で、未知の問題に対する答えの見つけ方について、マニュアル、ディクショナリ、MOS、ソーシャルメディア（コミュニティ）の利用について述べている。１７～１９章はパッチ適用やアップグレード、キャパプラなど先にセットアップした環境のメンテナンス方法について、２０、２１章は、Oracleのアーキテクチャとオプションについての概要が述べられている。
一見、Oracleの検証環境の構築方法が画面のスナップショットとともに丁寧に解説されているため、よくある初心者向けの手引きと勘違いしてしまうかもしれない。確かに、Oracle VM上にOracle LinuxからOracle Databaseを構築する手順が一通り乗っているので、これだけで手元のシングルインスタンスのテスト環境を作ることができる。若干バージョンは古い（12.2）ものの、読み替えれば十分最新のバージョンでも使える内容だろう。しかし、本書は純粋なOracleの技術のhow to本ではない。この本がユニークなのは、より根底にあるDBAという職業（Profession）についての考え方、心構えと、DBAとして自ら成長していくための方法、アドバイスを、自らの経験からつづった点である。
本書では、ITの世界でDBAは尊敬されるべき職業（well-respected profession）であり、そして同時にDBAたるもの、その位置づけを保つだけの行動を求められると説いている。AP開発からDBAになる、インフラ管理者からDBAになる、いろいろなパスはあれど、DBAを職業とするなら、業務から要求される様々な（時には理不尽な）要求に対して、単にNGを突きつける失礼な(rude)DBAになってはならない、DBAたるものは真の実現したい要件を関係者から聞き出し、現実解を導くような存在でなければならないと述べている。また、その過程で必要となる様々な人とのコミュニケーションにおいては、説明する相手に対して理解し易い言葉選び（例えばバッファキャッシュについて述べるにしても、説明する相手によっては単にキャッシュと言ったり、データベースメモリと言ったりといった配慮）をすることの重要性を述べている。このようなDBAの職業についての考えには、私自身の現場での経験に照らしてみても深く共感するところがあるし、もっと早くこの本に出合えていればと率直に感じた。
本書の主要なテーマの１つである、未知の問題にどう対処していくか、の記述は興味深かった。よくあるhow toはユースケースに応じたやり方は書いてあるが、そのような本では未知の問題には対処できない。まず、Oracleでこれってできる？といった無邪気な問いは、人に聞く前に自ら実機での動作確認を行い、検証することの重要性を述べている。失敗を通して学ぶことは多いこと、成功の条件を明確に定義することの重要性など、言われれば当たり前のことではあるが、Oracleコミュニティでの苦い経験を通しこのように行動することを重要性を改めて述べているのだろう。
本書の核となる部分のはじめに記載されているのは、マニュアルを読むことの重要性である。RTFM(Read The Fine Manual)という言葉は初めて聞いたが、おそらくコミュニティにおいてマニュアルに記載されていることを問い合わせる質問が投稿されたときの返答に使う略語なのだろう。有識者に聞くなら、自分で調べてから聞くべきで、有識者にマニュアルのここに記載されていることを調べさせるというのは礼を欠いている、というのである。RTFM的な質問をするなら、ドキュメントを確認した上で、それでも困難であることを質問すべきであろうと。Oracleのマニュアルは確かにボリュームが多く、これを全て読むことは不可能だが、著者が説いているのは、どこに何が書いてあるかを理解することはOracle DBAとしての必須スキルということである。本書にはインストール、管理、2日ガイド、概念ガイド、管理者ガイド、パフォーマンスガイド、エラーメッセージ、バックアップ・リカバリ、SQL言語リファレンスなど、マニュアルの主要なカテゴリについての説明は全体像を理解するのに役に立つだろう。
MOSの使い方の次に述べられているのが、ソーシャルメディアの活用である。ここでまず述べられているのは、ブログを書くことのススメである。著者は、難しい問題を解決したとき、新しいことを学んだとき（tips）、心に浮かんだことで誰かに共有したいこと、といったことをDBAとしてブログに綴っているそうだ。これにより自分自身の理解を深めるだけでなく、解決策が他の人の助けになれば、さらに未来の自分自身の助けにもなると言っている。本書にはOracleについて素晴らしいブログのリストが記載されいるが、Jonathan Lewis氏やTim Hall氏など私も過去googleで検索してよく見るブログばかりである。ブログの他にも、ツイッターやAsk TOM、Oracleのディスカッションフォーラム、カンファレンスやユーザグループなど、有益な情報ソースや活用方法について記載されており、とてもすべて活用できる気はしないが、何かあったときに参考になるだろう。Oracleを取り巻く技術者の層の厚さを改めて感じる。
DBAという職業についてより理解を深め、プロフェッショナルとしてさらに成長したいと考えている方には、一読をお勧めしたい本である。
Oracle DBA Mentor: Succeeding as an Oracle Database Administrator
- 作者: Peasland, Brian
- 出版社/メーカー: Apress
- 発売日: 2019/03/30
- メディア: ペーパーバック
以上
2021-07-27 17:29
保留統計の索引統計0件問題について [アーキテクチャ]
今までかかわっていたプロジェクトが一段落して離れることとなり少し落ち着いた時間が取れたので、先日コミュニティに投稿した、保留統計でgather_table_statsで索引の統計情報を取得すると、索引の統計がnum_rows=0となってしまうことがある、という事象について、ここで紹介しておきたい。
gather_table_stats doesn't gather related index stats properly when pending stats are enabled
事象の詳細や再現方法については上記を見て頂きたいが、簡単に言えば、保留統計を使っている表に対してgather_table_statsで表と一緒に索引の統計情報を取得するとき（カスケードオプション有効）、ある条件を満たすと索引の統計が適切に取得できない、より具体的には表の件数が有件なのに、索引の統計（num_rows）が0になってしまうのである。これが発生するのは表の（パブリッシュされた）統計（num_rows）が0で、保留統計を使っており、gather_table_statsでカスケードオプション有効にした場合に発生する。上記投稿で示したテストケースは19.3である。
この事象は新規不具合のため修正されるまではしばらく時間がかかる（一般的には21cまたは22cに取り込まれ、旧バージョンへバックポートされる流れになる）と思われる。このため、この事象を回避するワークアラウンドの確立が課題である。上記投稿ではパブリッシュ前にそのような問題を含んでいる可能性のある索引を抽出する方法について記載したが、実運用上この問題の影響と対処方法について少し補足しておきたい。
まず統計情報取得するシーンとして大きく２つあると考えている。１つは自動統計情報収集、これはOracleの一般的な統計情報取得方法であり、メンテナンスウィンドウに設定された時間帯に統計情報が古くなった表を選定（デフォルトでは更新が10%以上）し、統計情報を取得するケースである。システムが運用されている状態では、この方法で統計情報を取得していることがほとんどであろう。この問題の特性から有件の表に対しては統計情報取得に問題がないことは明らかであろう。あるとすれば、有件→０件→有件を繰り返すケースであろうが、そもそもそのようなテンポラリ表のような使い方のテーブルであれば、統計情報の状態を自動統計に任せること自体問題となる可能性があるので、統計ロックすることを検討するだろう。
もう一つのシーンは手動での統計情報収集である。これは、運用開始前のデータ移行や、リリースに伴う新規表の作成の際に、統計情報を適切な状態にするためにDBAが手動で統計情報を取得するケースである。この統計情報をどのような状態にすべきかは状況によって異なるだろうが、概ね初期データ投入後の状態で取得するか、あるいは空の状態としておき、何等かの契機でデータが投入された後を狙って手動で取得するといったケースが考えられる。いずれのケースにおいても、保留統計を使う場合は注意が必要である。空の状態で統計情報取得・パブリッシュして0件統計の状態を作ってしまうと、有件になったときの統計情報取得でこの事象の影響で意図せず索引統計が0となり、実行計画が適切でなくなるリスクがある。回避するには、0件統計をとらない、つまり0件の場合はあえてNULL統計にしておく、そして有件になった適切なタイミングで統計情報を取得することが一番簡易な対処である。ただ、0件の状態で統計情報を取得するなら、その後の統計情報取得では、必ず索引の統計情報が適切に取得できているかをパブリッシュ前に確認し、必要であれば、索引統計を再取得する、という運用を徹底することである。
索引のnum_rowsが0となってしまう弊害は、主に実行計画が適切でないことに伴う性能遅延に尽きる。ある表に複数の索引がある場合に、索引のnum_rowsが0であった場合、問い合わせのプレディケートに合致する索引が複数あった場合にコストが適切に算出できず、適切な索引が選択されない可能性がある。実際に、このような事象に遭遇した経験から、統計情報を手動取得する場合は、上記投稿にあるチェックSQLを実行し、索引統計に問題ないことを確認する運用を、少なくとも製品不具合が解消されるまでは徹底することが必要だと考える。手間としてはわずかであるが、このひと手間で後続の性能遅延のリスクを低減できるなら、これは十分実施検討するに値すると考える。
なお、コミュニティのSureshさんからは古い19cでは不具合多いよね、とのコメントを頂いたが、21cでも再現することが確認できたと聞いているので、おそらくこの事象は最新の19cでも修正されていないはずである。私の手元のテスト環境をそろそろ最新にバージョンアップさせなければと思う今日この頃である。Jonathan Lewisさんからの「いいね」が心の支えになっていることは言うまでもない。
以上
gather_table_stats doesn't gather related index stats properly when pending stats are enabled
事象の詳細や再現方法については上記を見て頂きたいが、簡単に言えば、保留統計を使っている表に対してgather_table_statsで表と一緒に索引の統計情報を取得するとき（カスケードオプション有効）、ある条件を満たすと索引の統計が適切に取得できない、より具体的には表の件数が有件なのに、索引の統計（num_rows）が0になってしまうのである。これが発生するのは表の（パブリッシュされた）統計（num_rows）が0で、保留統計を使っており、gather_table_statsでカスケードオプション有効にした場合に発生する。上記投稿で示したテストケースは19.3である。
この事象は新規不具合のため修正されるまではしばらく時間がかかる（一般的には21cまたは22cに取り込まれ、旧バージョンへバックポートされる流れになる）と思われる。このため、この事象を回避するワークアラウンドの確立が課題である。上記投稿ではパブリッシュ前にそのような問題を含んでいる可能性のある索引を抽出する方法について記載したが、実運用上この問題の影響と対処方法について少し補足しておきたい。
まず統計情報取得するシーンとして大きく２つあると考えている。１つは自動統計情報収集、これはOracleの一般的な統計情報取得方法であり、メンテナンスウィンドウに設定された時間帯に統計情報が古くなった表を選定（デフォルトでは更新が10%以上）し、統計情報を取得するケースである。システムが運用されている状態では、この方法で統計情報を取得していることがほとんどであろう。この問題の特性から有件の表に対しては統計情報取得に問題がないことは明らかであろう。あるとすれば、有件→０件→有件を繰り返すケースであろうが、そもそもそのようなテンポラリ表のような使い方のテーブルであれば、統計情報の状態を自動統計に任せること自体問題となる可能性があるので、統計ロックすることを検討するだろう。
もう一つのシーンは手動での統計情報収集である。これは、運用開始前のデータ移行や、リリースに伴う新規表の作成の際に、統計情報を適切な状態にするためにDBAが手動で統計情報を取得するケースである。この統計情報をどのような状態にすべきかは状況によって異なるだろうが、概ね初期データ投入後の状態で取得するか、あるいは空の状態としておき、何等かの契機でデータが投入された後を狙って手動で取得するといったケースが考えられる。いずれのケースにおいても、保留統計を使う場合は注意が必要である。空の状態で統計情報取得・パブリッシュして0件統計の状態を作ってしまうと、有件になったときの統計情報取得でこの事象の影響で意図せず索引統計が0となり、実行計画が適切でなくなるリスクがある。回避するには、0件統計をとらない、つまり0件の場合はあえてNULL統計にしておく、そして有件になった適切なタイミングで統計情報を取得することが一番簡易な対処である。ただ、0件の状態で統計情報を取得するなら、その後の統計情報取得では、必ず索引の統計情報が適切に取得できているかをパブリッシュ前に確認し、必要であれば、索引統計を再取得する、という運用を徹底することである。
索引のnum_rowsが0となってしまう弊害は、主に実行計画が適切でないことに伴う性能遅延に尽きる。ある表に複数の索引がある場合に、索引のnum_rowsが0であった場合、問い合わせのプレディケートに合致する索引が複数あった場合にコストが適切に算出できず、適切な索引が選択されない可能性がある。実際に、このような事象に遭遇した経験から、統計情報を手動取得する場合は、上記投稿にあるチェックSQLを実行し、索引統計に問題ないことを確認する運用を、少なくとも製品不具合が解消されるまでは徹底することが必要だと考える。手間としてはわずかであるが、このひと手間で後続の性能遅延のリスクを低減できるなら、これは十分実施検討するに値すると考える。
なお、コミュニティのSureshさんからは古い19cでは不具合多いよね、とのコメントを頂いたが、21cでも再現することが確認できたと聞いているので、おそらくこの事象は最新の19cでも修正されていないはずである。私の手元のテスト環境をそろそろ最新にバージョンアップさせなければと思う今日この頃である。Jonathan Lewisさんからの「いいね」が心の支えになっていることは言うまでもない。
以上
2021-07-01 01:02
