SPMって使ってる？
この記事は、JPOUG Advent Calendar 2022 18日目の記事です。
昨日はmultilayerさんのAutonomous DatabaseのSLAを99.995%にしてみた！の記事でしたね！
タイトルからもう、強つよですよね…！！Autonomous Data Guardは現在営業さんからおすすめされているのですが。本当にボタンポチで使えちゃうんだ…スイッチオーバーいいな…なんて、DR/BCPを検討している私には、非常に胸アツな記事でした。
さて、仕事では主にRDS for Oracleを使っており、AWS界隈では割とマイナー道を突き進んでおります。
先日RDS for Oracleでは新しいSSDストレージ「gp3」というのが出まして。
これ面白いんですよ、IOPSとスループットが可変なんです！これはそれぞれの性能でsqlldrやったら楽しそう！と思い記事にしようと思ったんですが…
貴社は以下を行うことはできません。
・Oracle ソフトウェアまたは Oracle ソフトウェアにおける所有権の他の個人または法人への譲渡、付与、または権利移転。貴社が Oracle ソフトウェアにおける担保権を付与しようとした場合も、担保を得た当事者は Oracle ソフトウェアを使用または移転する権利を有しません。
・Oracle ソフトウェアを、レンタル、タイムシェア、サブスクリプション サービス、ホスティング、外注に使用すること。
・Oracle またはそのライセンサーの所有権通知を除去または変更すること。
・Oracle ソフトウェアを、何らかの形で第三者の事業運営のために第三者に利用可能にすること。
・Oracle ソフトウェアの複製、リバースエンジニアリング（相互運用性のために法に求められる場合を除く）、逆アセンブル、逆コンパイルを行うこと（Oracle ソフトウェアが生成したデータ構造や同様の資料を検討することを含む）。
・Oracle ソフトウェア上で実行したベンチマークテスト結果を公開すること。
だめでした。
ということで、別話題に変更！
SPMについて簡単に説明＆実はAWRから実行計画を引き抜けるんだよ！ということを軽くご紹介させていただこうと思います。
注：詳細な手順はMy Oracle Support（MOS）に記載されておりますので、ここではその一部だけ少し書くだけに留めさせていただこうと思います。正しい手順は必ずMOSの内容をご参照ください。また、このブログのSQLの動作確認はOracleDB19cが前提になります。
Agenda
- SPMってそもそも何だっけ？
- SPMを使う上での注意点
- SPMで実行計画を固定化する手順
- AWRから実行計画を抜き出してSPMで実行計画を固定化
SPMってそもそも何だっけ？
皆さんの中には、実行計画が意図せず変わってしまいパフォーマンス影響が出てしまい、処理が終わらない！性能劣化が！なんていうご経験ありませんか。
そんなときに助けてくれるOracleDBの便利機能、それがSPMです。
正式名は「SQL Plan Management」略して SPM になります。
端的に言うとSQL実行計画を管理する機能で、このSQL IDは絶対、この実行計画で動いてね！！ という機能になります。
仮に、SQL ID 1234567890abc が、今まで 1234567890 の実行計画（PLAN_HASH_VALUE）であったのに対し、統計情報更新等で急に 0987654321 になったシナリオを例とします。
それまでSQL ID 1234567890abc は実行計画 1234567890 で30秒で実行できていたのですが、実行計画 0987654321 で10分経っても過処理が終わらない！なんてことが、重要な処理で発生したら。バッチ処理なら後続処理が遅れて、場合によっては事業影響大。オンライン処理なら場合によってはシステムダウンと判定されるレベルかもしれないです。
そんな時、SPMが助けてくれます！
SPMに「SQL ID 1234567890abc は実行計画 1234567890 で絶対動いて！！」と設定すると、その瞬間からSQL ID 1234567890abc は実行計画 1234567890 を用いて実行し、元の30秒の性能で動き始めます。
な、なんて便利な機能…！恐ろしく便利な機能ですね、OracleDBさん！
詳細は 津島博士のパフォーマンス講座 第75回 SQL Plan Managementについて を是非読んでみてください！
OracleDB 19の新機能の説明も見どころですよ。
SPMを使う上での注意点
この機能は本当に便利なのですが、ご利用の際は以下の点を注意＆考えて使っていただきたいなと思っています。
1. SQL IDをKEYとして実行計画を固定化するため、SQL IDが変わった場合はこの設定は実質「無効化」されます
この話の前に、ちょっとSQL IDについておさらい。
そもそもSQL IDってどう算出されているかというと、実行されているSQL文をMD5で変換した末尾の8バイト、なんですよね。
ではSQL IDがどのタイミングで変わるかというと「実行されるSQL文が1バイトでも変わったら」になります。
例えば半角空白1つでも入ると、別SQLになったとOracleDBは受け取ります。条件(where)がリテラルの場合、その値が変わると別SQLと受け取ります。
逆にバインド変数の場合は、変数の値が何であれ同一のSQLともなされます。
ということで、実行計画を固定化したまま動かしたくない場合は、SQL IDが変わらないように実行する際一切変更しないこと。（該当SQLの開発を凍結するイメージがよいかと）
変更する場合は、必ず同時に変更後のSQL IDに対し実行計画を固定化する等を検討してください。
2. 実行計画を固定化をDBサーバー側で固定化するのがそもそも良いのか
そもそも何故実行計画が意図せず変わってしまうのかという話は、それだけで記事が書けてしまうほど深い議題です。
一般的にはテーブルの論理設計の問題（似たようなINDEXを使いすぎている等）と言われていますが、データのカーディナリティが起因するなど、原因は多岐に渡ります。
そのため、全ての場合において「この課題を解決したらいい」というものではないのは、皆さんご存知かと思います。
この点はオプティマイザの気持ちになって考える必要があるため、 門外不出のOracle現場ワザ 第4章 Oracleデータベースの頭脳 「オプティマイザ」徹底研究 にて、小田さんが詳しく書かれていますので、ぜひご一読ください。CBOが何故誤った選択をするのかと言うの例も、詳しく書かれています。
さて、SQLの実行計画を固定化するということについて。
OracleDBをあまり利用されていない方に、DBサーバ側で実行計画を固定化の話をすると驚かれます。
というのもこの機能、PostgreSQLでも追加パッケージ入れないと使えない機能（スミマセン使ったことはないです）ですし、MySQLには現時点でも存在しない機能だと思います。なので、この概念はOracleDB利用であることが前提に、現時点ではなるかと思います。
またアプリケーション開発という観点で見たとき、SQLの挙動をDB側で制御するのか良しとするのか。という考えもあります。私個人としてはこちらの考えですね。
実際、実行計画を固定化するということ事態、サービスレベルと内容によりケースバイケースだと思っています。
例えば銀行系の決済処理のSQL。性能命。このように非常に重要度の高い処理の場合は、実行計画を固定化する運用は必要だと思います。
ただし仮にそうだとしても、ヒント句等でSQL文側で実行計画を固定化するのが良いです。そのSQLを改修するたびに実行計画をDBで固定化するより、そもそもSQL側で宣言する（hash joinしか使わないよ、等）の方が、開発する側もSQLを改修する際に配慮ができますし、検証時に「このSQLは実行計画変動の課題を抱えているぞ」とコードをみて理解できるからです。
これについても、先に挙げた「何故実行計画が変動するのか」の理由、つまり根本原因を究明することの方が大事だと考えています。また同じように実行計画がコロコロ変わるSQLを生み出してしまう可能性がありますからね。
あくまで個人の意見ですが、この機能は止血策として使う機能であり、恒久的に使用する機能ではない。と考えています。
便利すぎるOracleDBが悪い。褒めてます。
SPMで実行計画を固定化する手順
さて本題のSPMで実行計画を固定化する方法ですが…MyOracleSupportの「SQL 計画管理 (SPM) の使用方法 - プラン・スタビリティ動作例 (ドキュメントID 2650514.1)」こちらをご参照になった上で、ぜひ使ってみてください。
この機能、なんとOracle Database 18cからはStanderd Editionでも使えるようになりました！ただしSEは1つのSQL IDに対してしか使えませんので、ご注意を。EEには制限はないです。
一例をあげますと、だいたいこんな感じのSQLを数回実行するだけで、即実行計画固定化が反映されます。実は簡単！
--- SQLベースラインの確認 select sql_handle, sql_text, plan_name, enabled,accepted, fixed from dba_sql_plan_baselines; --- カーソルキャッシュから実行計画を読み込む var res number exec :res :=dbms_spm.load_plans_from_cursor_cache(sql_id => '<SQL_ID>', plan_hash_value => '<PLAN_HASH_VALUE>'); --- 実行計画固定化の適用 var res number exec :res := DBMS_SPM.ALTER_SQL_PLAN_BASELINE ( - sql_handle => '<SQL_HANDLE>', - plan_name => '<PLAN_NAME>', - attribute_name => 'FIXED', - attribute_value => 'YES' );
AWRから実行計画を抜き出してSPMで実行計画を固定化
更に応用技！
過去、上記実行計画固定化をしようと思ったのですが「カーソルキャッシュに…適用したい実行計画が…な、い…」という絶望を味わったことがあります。週次や月次のバッチのSQLで、もうカーソルキャッシュに以前の安定稼働した実行計画が残っていなかったのです。
なんとなんと、OracleDBはAWRから実行計画をロードして、SQLチューニングセットを作って実行計画固定化出来るんです！
つまり、AWRの保存期間内の実行計画は復元出来るということです。え…シンプルにOracleDBすごくないですか…？！
こちらもMyOracleSupportの「自動ワークロードリポジトリ(AWR)からSQL計画管理(SPM)にSQL計画をロードする方法 (ドキュメントID 2677758.1)」に手順が記載されていますので、ぜひ使ってください。
尚、この機能はAWRが利用できる前提になります。つまりEnterPrise Edtionのみ利用可能、且つAWRはOracle Diagnostics Packのライセンスが必要になりますので、ご注意を。
こちらも一例を挙げますね。
--- AWRのスナップショットIDを確認する select s.snap_id snap_id,to_char(s.end_interval_time,'dd Mon YYYY HH24:mi') snapdate from dba_hist_snapshot s order by snapdate; --- SQLチューニングセットを作成 exec DBMS_SQLTUNE.CREATE_SQLSET('<SQL_TUN_NAME>'); --- 存在するSNAP IDから実行計画を取得しSQLチューニングセットに入れる declare baseline_ref_cursor DBMS_SQLTUNE.SQLSET_CURSOR; begin open baseline_ref_cursor for select VALUE(p) from table(DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(begin_snap=><SNAP_ID>,end_snap=><SNAP_ID>,basic_filter =>'sql_id='||CHR(39)||'<SQL_ID>'||CHR(39)||' and plan_hash_value=<PLAN_NUMBER>',attribute_list=>'ALL',dbid=><DB_ID>)) p; DBMS_SQLTUNE.LOAD_SQLSET('<SQL_TUN_NAME>, baseline_ref_cursor); end; /
まとめ
- SPMはSQL IDに対し実行計画固定化できちゃう機能です
- OracleDB 18c以上なら、SEでも使えちゃうよ
- 便利機能だけど止血策として使うのがオススメです
- 手順はとっても簡単
- AWRから過去の実行計画をロードして実行計画固定化もできちゃうよ！
明日はSekiguchiさんの記事ですね！わくわく楽しみだなぁ♪
DBAからDBREになろうと思ったきっかけ
今日も書くよ、エッセイみたいなもの
DBREに対する自己認識
まぁそれは本を読んでほしい。今日はここでこの本の内容をあれこれ言いたいわけではない。
システムの安全性や稼働率を定量的に測って目標値を決めて、その目標に向かって改善を積み重ねていく。
そうゆう手法を教えてくれるのがこの本で、自分の肩書がDBAなのかDBREなのかは、実はどうでもいいことなんだよね、とは思っています。
昔は、DBREとはDBAのその先の進化、みたいなイメージを持っていました。それは確かこの本の冒頭にも書いてあります。
けれど今の私が思うDBREは「疲れ切ったDBAが取った、最後の手段」と思っています。
何故DBREにシフトしようとしたのか
きっかけは、先日書いたこの本でした。
しかもこの本の内容ではなく、この本に挟まれていたこのメッセージから。
これすごく大事な内容なのだけれど、電子版にもあるのだろうか？
この本、実は精神科の先生（つまりお医者さん）が書かれた本なのですが。
先生がアウトプットの大切さを何故重要だと思ったのか？の経緯がここに書かれていました。
治療しても治療しても、また同じような症状の患者さんがやってくる。きりがない。
私が転職してからずっと、ひたすら忙しいのには訳がありました。
前提として、うちの会社は何故か「リリース前のSQLチューニングもSREのDBA」という謎ルールがあります。
ちなみにそのSQLの要件がなにかの説明はない…という闇はここで言うのは割愛。つまり開発者がSQLチューニングすることは非常に稀なので、DBAはSREとアプリ開発に片足入った状態。当然、日々のタスク量は多い方だと思います。（あと契約とか予実管理もしているので、実質死にそうです）
そんな状態なのに「急にこの処理が遅くなりました！DBAなんとかしてください！！」という問い合わせが、平均月一回以上あります。
多いときは、週に3回。大体が重要な処理で「今すぐ何とかしてもらわないと、XXXXX業務が回らないんです！！」と分単位でリカバリを求められる障害対応をしています。
同時に、高負荷なSQLをどうにかチューニングしてというプロジェクトも立ち上がり、毎週長文SQLをにらめつける日々。
原因は一目瞭然で、その理由を簡単にですがSlackで書いては皆さんに伝える、大分雑なアウトプットはしていました。けれどその内容は局所的で、正しく理解して頂ける内容だったかというと、とても足りる内容にはなっていませんでした。
とにかく、治らない。
チューニングしてもチューニングしても、また同じようなJOINがいっぱいのSQLが作成され、似たような実行計画を惑わすINDEXが作られ、DBA何とかして！がくる。
きりがない。もう辛い。
半年以上これを続け、モチベーションもですが絶望感も感じていました。
GW初日の祝日に呼び出されたときは、一緒に出かけようと言っていた娘に「ごめん行けない」と伝えたときの、娘の涙目を見て「もう辞めよう」と本気で思いました。
でも私が辞めても、改善はされない。ならせめて、何かしら食らいついて結果を出してから、辞めたい。
そんな中でこの本のレターを見て、アウトプットの重要性に気づきました。
「治療」より「予防」をしないと、この先ずっとこの状況が続くということ。
JOIN一杯の数百行SQLがなぜ作られるのか
INDEXを追加することで、なぜ実行計画の変動するのか
なんてことはDBAだったりSQLチューニングしている人であれば分かりますし、開発者の人でも分かっている人は分かっています。
けれどそれが開発に関わる人すべてがそうかというと、そうでもない。
であれば、「何故それがだめなのか」を正しく伝えることが必要なんだと思うんです。
それもDBREがすることの一つではないかなと、そう思っています。
同時に、コストベースのオプティマイザを利用しているRDBMSであれば、コストの指標を算出も改めてすることにしました。
なんとなく「コスト下げて！！」では、説得力がありません。
CPUの数がこれ、それに対して毎秒アクセス数はこれ、例えばOracleDBであればそれに対しDB TimeはXXXXでないと、CPUを食いつぶすよ。といった定量的な説得力を提示することです。
そうすれば開発者の方々も、作成したSQLのOK/NGがわかりやすい。同時に私たちも、その閾値を超えたものができた場合、どうしたらいいのかを相談する場を設けられ、アンチパターンのアウトプットを出すことが出来ます。
よし、こうすればWin-Winだな。そう思ったのが先日のことでした。
次にやらないといけないこと
さてDBREもどきに舵を切ることを選択した訳ですが、このとき同時にしないといけないことは「効果を定量的に出す」ということ。
日々の問い合わせ、実行計画変動の問い合わせ等、これまで行ってきた業務がどのように変化をしたのか、この効果を出さないといけません。
数はここでは言えないと思うのですが、どのくらい減った、という辺りはアウトプットできればいいなと思っています。
猫の手でも借りたい。でも猫がいたら、多分仕事しなくなると思います。
だって猫はかわいいもの。
「アウトプット大全」から学ぶ育児考察
お久しぶりの投稿です。本当にお久しぶり過ぎて、猛省。
相変わらず毎日バタバタ走っていたのですが。ふと、本屋さんで目に止まったこの本を手に取りました。
最近本は殆ど電子版ですが、何故かこの本はペーパーがいいなと思い手に取りました。
こうゆう「予感」みたいなものはだいたい、その時の自分にとって不足している栄養素を補う、本能みたいなもの。迷わずレジに持っていきました。
結論から言うと、やはり今の私にほしい栄養素が詰まった本でした。
半分は仕事に対して足りない栄養素だったのですが、それはまた後日。
今日はあえて、「アウトプット大全から学んだ育児考察」について、少しだけ書きたいなと思います。
「学びを結果に変えるアウトプット大全」から学んだ育児的考察
粒度がバラバラですが、こんな内容を学びました。
- コミュニケーション
- 「今日何したの？」という問いの重要性
- 子供と話すときの態度、特に目を見て話すことの重要性
- 「月に1回の家族旅行」より「毎日5分の家族の会話」の方が、遥かにコミュニケーションを深める
- 「相談」をすることで何故、心が軽くなるのか
- 勉強
- 「手で紙に書く」方が圧倒的に記憶が定着し、新しいアイディアを生み出しやすい
- 教科書には落書きをしたほうが記憶力を高める
- 「ぼーっとする」時間が必要
コミュニケーション系の学び
個人的な意見ですが、これが一番子育てで難しいことだと考えています。
コミュニケーション能力は社会性の需要な一つであり、コミュニケーションを通じて得た情報をどのように受け止めるかによって、人格形成にも影響があるのではと考えています。
そんなコミュニケーションで学んだ１つ目『「今日何したの？」という問いの重要性』について。
業務時間にみっちりミーティング三昧をしていると、退勤後の脳はもうすでにお疲れ。もう話すのも億劫だ…なんてこと、ありますよね。
でも保育園に迎えにいくと、元気一杯な子供とのコミュニケーションが始まるわけです。
今日保育園で何したの？へぇー楽しそうだね…で終わっている自分がいました。（場合によってはそれすら無いときもある。猛省。）
けれど仕事で同じ事をしているかと言うと、そんなことないですよね。
「そんなことしたんですね。で、それで何を学んだの？」って聞いてますよね？あれですあれ。同じことを聞けばいいんです。
「今日そんな遊びしたんだね。何が楽しかった？具体的にどんな事したの？」どんどん深堀り。なぜなぜ分析に近い。
こう聞くだけで、私も話をしていて子供の体験や考え方を知れるし、質問能力が上がります。
同時に子供も自然と「自分の意見、感想を話す」というアウトプットの経験をしています。
自分の体験を言語化し、相手に伝わるように要約し、感情を伝える経験。
これ、いい年しても未だに苦手ですが、その練習の場になっているんだなぁと学びました。
他の項目は割愛しますが、『「月に1回の家族旅行」より「毎日5分の家族の会話」の方が、遥かにコミュニケーションを深める』は割と刺さるものがあったので、これは家庭でも仕事でも、ぜひ。
1on1の時間を、半年に1時間と1週間に10分話すのと、どちらがよりよいコミュニケーションとモチベーションアップにつながるか。わかりますよね。
勉強系の学び
次に『「手で紙に書く」方が圧倒的に記憶が定着し、新しいアイディアを生み出しやすい』について。
システムエンジニアという職業の私ですが、議事録やToDoをTrello等のツールで書くことが、実は未だに苦手です。
リーンインという本で、FacebookのCOOであるシェリル・ザンドバーグさんが「未だに手帳にToDoを書いている」というのを拝見して、ホッとしたことが。
今はLIFE のノーブルブックをマウスパッド代わりにしつつ、気になったことや議事メモを書きなぐるようにしています。その方が忘れることが少ない経験があります。
最近の学校では、タブレットやPCで学ぶことが多いとか。
もちろんメリットもあるのでそれは積極的に取り込んでほしいのですが、やっぱり紙に書くことの方がいいよなぁと漠然的に思っていました。
私が社外プレゼンや重要な資料を作成するときは、必ずノートに書きなぐってから構成を考えた上で作成しますし、その方が新しい気付きやより精度のある資料ができる経験があるからです。
この本のなかで「手書きでノートをとる学生」と「ノートパソコンでノートをとる学生」に分けて比較した場合、手書きの学生の方が良い成績を上げ、新しいアイディアを思いつきやすい傾向がある研究結果を、知ることが出来ました。納得。
他にも面白かったのは、教科書に落書きしている方が記憶に定着しやすい、ですね。
偉人の顔に落書きしているほうが、その偉人のこと覚えるらしいですよ？落書きしたら褒めてあげましょう。よくやった。
蛇足：何故、育児をしながら仕事をしているのか
みなさん義務教育のカリキュラムの中で、「どうやって人を育成するか」という内容を学んだ記憶、ありますか？
残念ながら私の少ない脳内DISKには、その情報はゼロに近い状態です。正しく学術知識として得られるのは、おそらく大学なのかなと思います。教育系の専攻ですね。
そんな状態の私がある日、妊娠し出産し、一人の人間を育てなければならなくなります。なんの経営知識も経験もない人間が「今日から社長ね」と言われるのとほぼ同じ。
この悩みを妊娠前から漠然と抱えていた私は、ふと、日々の仕事を振り返りました。
あるじゃない、ネタが。
仕事では当然、教育は日々発生します。それは新人さんに対してであったり、未経験者であったり、色々なパターンがあります。
そして沢山ある、フレームワーク。PDCA、KPT、Fun Done Learn、なぜなぜ分析、3年後5年後の自分のありたい姿…プロジェクトのスケジュール作成やマイルストーンも、役に立ちます。それらを実践する場があります。
また、多くの人と関わることによる、様々な価値観や発想に触れることができます。これは特に、子供の発想を柔軟に受け止める練習の場にもなっています。
最後はまぁ、そんな「勉強」や「経験」をさせてもらえるのに、お金も貰える。何だ最高じゃない。
という実に安直な理由で、今も仕事をしながら子育てをしています。
ちょっとしんどいですけど。ぎぶみー体力。
よくあるオンプレOracleからRDSに移行したDBAの反省文
この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。
昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。
いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの？明日AWSサポートに早速連絡してみよう…
最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ！！笑
さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。
そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。
今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます。
結論
結論を最初に書くのが大事なので、これ一番最初に書きます。
私の反省は、以下の3つです。
本当はいっぱい書きたいけど、そうすると長すぎるのでやめましょう。
- 性能試験は必ずしましょう
- DB移行で一番大事なのはNWです
- 運用の見直しを忘れずに
かいたひと
これを書いた人は、10年ちょいSIerで開発PM→DBA→DBチームリーダーをしていた人でした。DB移行回数は…数えるのやめましょう。
ずっとオンプレOnly、パブリッククラウドはAWSですら未経験の人です。
もう数年SQLを打つことさえしなくなり（設計計画とマネジメントしかしない）、現場の仕事がしたいなぁと思って心機一転、全く別業種の社内DBAに転職してみました。
前提
転職後、とあるDBの移行プロジェクトにアサインされました。
移行元のDBはシステムの最も重要なDBでした。
ほとんどのシステム、業務処理がそのDBを利用しており、そのDB停止＝サービスほぼ全停止、という会社において最もミッションクリティカルなDBです。
私が参画段階では既にAWS RDSで移行することも、その移行先のRDSサイズや構成も決められていました。
AWSさんがしっかり入って検討してくださっていて、先方のエンジニアの方も凄腕のDBエンジニアさんでした。
転職直後ということもあり、事前検討はしっかりされているのだろうなと考え、私は計画や全体の流れではなく技術的に細かいことを検討することに集中しようと考えました。
これだけ見ると、とても順調に進んでいるように見えたのです。
ところが…まぁ、そうですよね。順調にいかないのがDB移行。もちろん、沢山の問題が発生しました。
反省その①：性能試験ができないDBの移行
最初に躓いたのはこちらでした。
試験計画（一応作った）を作っていたところ…突然、想定外のことを言われました。
性能試験は出来ません。
詳細は会社的にアレなので割愛させてください…
この時点で、「あ、SIer時代だったら丁重にお断りする案件だな」と思いました。 ←素直
AWSの担当さんから、性能試験無しのDB移行はやめてくれ、最大のアンチパターンだと念押しで言われました。
でも、出来ないことは出来ないのです。
ということで私は性能試験ができない、けれどミッションクリティカルなDBの移行をすることになったのです。
これはこのDB移行プロジェクトの、最大のリスクでした。
ここで投げ出したかったんですが、それじゃあ私の存在意義はないですよね？
このことから性能問題が必ず発生することを予測し、 Oracle Enterprise Manager（後述OEM）の利用を訴え、Diagnostics PackとTuning Packの購入を上申しました。
RDSのPerfomance Instight（後述PI）は非常に有用ですが、OEMで見れるような詳細な情報を追うことは出来ません。また、Tuning Packは非常に強力な性能改善機能です。
これはPIが悪いということではありません。様々なDB製品を扱う中、同様のIFであれだけ詳細な情報を見せれるPIは本当に素晴らしい機能です。が、OracleDBの深淵を覗くには浅すぎるのです。
幸い、上層は新参者のぎゃーぎゃーした言い分を聞いてくださり、この2つのライセンスを購入していただくことになりました。これは私にとって、最大の幸運でした。
さて、移行後の今…私が最も評価された事は「OEMの導入」になってしまいましたorz
案の定移行後のDBは安定せず、気を抜くとCPU使用率が100%近くになってしまうのですが…
CPUが上がってき始めた段階で各待機イベントの割合を占めているSQL IDをOEMで確認、Tuning PackでSQLチューニングをかけて対処方法を提示することで、今も順調に稼働しています。これを順調に稼働と呼んでいいのかはさておき。
結果、性能の担保をOracleDBの持つ製品機能とお金の力で解決しました。
DBのチューニングを華麗にやった！という素敵な内容でなくてごめんなさい。でもこれが、性能試験をせずにDB移行をした結果です。
まだお金の力でどうにかなっただけ、マシだとお考え下さい。本当に、性能試験無しは絶対だめです。移行後性能出なくても、文句言っちゃだめです。
余談ですが、製品の力を借りたSQLチューニングは個人スキルに依存しない為、安定したDB運用方法かなと考えています。一人の凄腕SQLチューニングエンジニアがいないと動くこともままならないDB、危険すぎますよね。
反省その②：DB移行の鍵はNW
プロジェクトを進めていく中で、現行と移行先の構成は決まっていたのに、移行方法がぽっかり空いていることに気づきました。
そのため私は、移行計画の作成に着手したわけです。
そうしてほうぼうにヒアリングをしていく中で気付くのです…
AWS向けのDirect Connectの回線の帯域は？
本当によーーーーく抜け漏れるのですが、DB移行作業の重要なポイントはNWなのです。
簡単な例は、引っ越しです。
一般家庭の引っ越し用のトラックが1tだったとして、何フロアも借りている企業のオフィス引越しも、1tトラックで済むと思いますか？
そりゃあなた、荷物の量が全然違うじゃないですか。1tトラックだったら何回往復しないといけないじゃない。そう、そうなんです。
通常MB、多くて1G程度のデータ転送しか発生しない回線であれば、Mbpsでいいのかもしれません。
ただ相手はDB、それもOracleDBなんて使ってるのですから、大抵データ量は多いのが相場です。
現状の回線帯域を聞いて青ざめた私は、すぐにNWエンジニアの方に移行計画内容を伝え、転送データ、秒間あたりの転送量を伝えて、10Gは最低でも用意してほしいという旨を伝えました。
その内容を聞いていただいたNWエンジニアの方は、同様に顔を青ざめて「それはまずい」と言ってくださり、すぐ10Gの回線の手配をしてくださいました。
ただ、気づくのが遅く、大分ギリギリに対応していただいたというのが、私の反省点です。
今思えばあれがなかったら、移行作業時間は何十倍も膨れ上がっていたと思います。本当にNWエンジニアの方には感謝しかありません。
これはRDSでなくとも、通常の移行時においても非常に重要なポイントだと思います。
反省その③：運用の見直しを忘れずに
※責任共有モデルのことは割愛させてください。
AWS RDS for Oracle。いやー本当にすごいですよね。
すぐDB作れるし、CPU/Memory/DISK増やせられるし、IOPSもこちらで指定できるし、MuritiAZで冗長化。Point Time in Recoveryですぐ戻せる。
それも全部ボタンぽちか、awsコマンド、Terraform applyでできちゃうんですよ。これオンプレでやってた時、どれだけ大変だったか。
パブリッククラウド最高！これは間違いないです。
こう見るとすべての課題、なんでも解決すると思いますよね？
それに、OracleからOracleに移行でしょ？やったー色々楽になるぞー！
私も同僚も、そう思っていたんです…いや、もちろん解決したことは沢山あったんですが…移行検証や運用をしていく中で気づくのです。
できなくなっていることが、割と苦痛。
典型的な例は以下です。あまりにも有名なので、何を今更と思われるかもしれませんが。
頭ではわかっていたんです。ただ、使い始めると特に、以下のようなことに悩まされます。
（ほとんどは責任共有モデルで解決できそうな予感/すみませんまだ未検証です…）
- OSレイヤにアクセスできないことによる変更
- DB Serverにクライアントインストールする系のツールが軒並み使えなくなる
- 大好きだったoratopはもう使えない
- インストール時にデフォルト存在するスクリプト系を準備しないといけない（@$ORACLE_HOME配置下のSQL達）
- Dumpファイル等の操作も全部SQLでしないといけない
- DataPumpのコマンドをクライアント経由で実行する内容に変更しないといけない
- 「ロングランのプロセスKILL」が出来ない →AWSさんに言ったらできるかもしれないですが、よほどのことない限りNGと思われる。また、やり取り大変。何せこちら、ps -efすら打てない。
- こちらコメントにて指摘いただいたので追記します。「ロングランのプロセス」と雑に書いて申し訳なかったです。ここの意味は「バグ引いてロングランになったり応答返さなくなったけどセッション保持したままのOracleDB Serverのプロセスをkill -9で強制停止させる」という荒業のタイプですので、通常時の運用ではrdsadminでセッションKILLしてくださいね
- OracleDB最大の秘奥義「個別パッチ」が当てられない。わかってたけど。そんな時に限ってすぐBugひく
- SYS権限が打てないことによる変更
- SYS≠マスターユーザであることを意外と皆さん知らない
- 特にうっかり間違えてalter system打ちがち。そして権限エラーが出ますよねすいませｎ
- rdsadminに慣れる期間が必要。同時に開発者にもそれを伝える必要がある。（開発環境のDBでDBA権限持つ人が、やっぱりalter system打つ）
- SYS系が持っているTABLEはSYS.をつけて実行しましょう
- DBAロールの権限差分
- 特にGRANTが打てなくなっているのが本当につらい。セキュリティ向上のためなのだと思いますが、開発環境でもマスターユーザーしかgrant打てないのつらい。だったらcreate userもDBAから外しておいてほしかった
- RACは使えない
人は、いままで自由だったことが制限されると、こんなにフラストレーションを感じるのだと、改めて知りました。
ちなみにこれ、RDSの悪口ではありません。マネージドサービスなので、当たり前なのです。ちゃんと、出来ないって書いてあります。
特権が持てない代わりに、運用をお任せできる。それがマネージドなんですよね。
頭で理解していたつもりが実際やるとこんなに変わるのだと、身をもって理解しました。
同時に、運用ルールや運用手順、運用に関わる様々なことを変更しなければなりませんでした。
私の盲点は、これを事前に行うことが出来ず、移行直前に慌てて運用設計の見直しをし始めたということです。
これがOracleDB→PostgreSQLであれば、さすがに事前検討や社内周知をしていました。ただ、OSにアクセスできない、SYS権限はない等が具体的に日々の開発や運用にどれほど影響を与えるのか、理解できていなかったのです。
これの対策は、やはり早期から移行検証や軽く運用をしてみて、そのシステムやサービスに応じて検討をしておく必要があったと痛感しました。
同時に、柔軟に対応できるようにする私たちエンジニアの動き。システムやプログラムに文句を言うのは筋違いですよね。
まとめ
他にもここでは書けないようなことが山ほどありましたが、無事移行できたことはほっとしつつ…反省点山盛りだったことは否めません。
そして現在も、私は運用ルールの整備とDB性能チューニングに、日々悩まされております。そろそろ平穏が欲しいよ、相棒のRDS for OracleDB！
明日は、おおのさんの記事です。わくわく、今から楽しみですね！
AWS RDS for OracleのS3連携を一般ユーザで実施する方法
久しぶりにブログ書いたと思ったら技術メモですが…はい、元気です生きてます！
RDS for Oracleとは随分仲良くなったのですが、S3連携するときに困ったことをメモ。
RDS for OracleがS3と連携するための設定、及び手順配下に記載があります。
aws.amazon.com
そこで、DB側のADMIN権限ではない一般ユーザでS3連携の以下コマンドを実行すると、エラーが出てできなかったのですが。
どうもこの権限が足りないみたいです。
GRANT EXECUTE ON RDSADMIN.RDSADMIN_S3_TASKS TO <UserName>; GRANT EXECUTE ON RDSADMIN.RDS_FILE_UTIL TO <UserName>;
ついでにディレクトリオブジェクトにも読み取り/書き込み権限付与も忘れずに。
GRANT READ ON DIRECTORY DATA_PUMP_DIR TO <UserName>; GRANT WRITE ON DIRECTORY DATA_PUMP_DIR TO <UserName>;
権限周り、ちゃんとRDS版勉強しないとなと反省の日々でございまする…とほほー。
DBREJPはじめてみました
この記事は JPOUG Advent Calendar 2020の12/11の記事となります。
昨日の記事はNakaieさんの「Oracle Databaseへの言語別アクセスドライバのまとめ - Qiita」でしたね。言語別のドライバがすごくわかりやすくまとまっていて、改めて学びになりました。
一日遅刻しちゃいました…遅くなりました！！
前に書いた記事から随分間が空いて、気がついたら年末になっていました…2020年、色々なことがありすぎてあっという間…でしたが！
さて気を取り直して、今日は最近はじめた活動について宣伝をさせていただこうと思いますっ( ˙꒳˙ᐢ )
はい！DBREJPはじめてみました(꜆꜄•ω•)꜆꜄꜆
まず、DBREってなんぞやというお話ですが…
SREという言葉をご存知でしょうか。
Site Reliability Engineering. サイト、システムの信頼性を向上していくエンジニアリングのことですね。
でもサイトやシステムの信頼性は、NWやOSレイヤ、サービスを提供ソフトウェアだけでは成り立ちません。
そうですよね。大抵そこには、RDBMSだろうがKey-ValueだろうがNoSQLだろうが…データを保存し、それを利用するDataBaseが存在します。
そんなDBの信頼性を上げるエンジニアリングが、 Database Reliability Engineers.
それが、DBREです。
でもここで紹介するDBREは、ちょっと違うかもしれません。
そもそも何故始めたいかと思ったかというと、以下のようなことを最近感じているからです。
- DBAの人口はエンジニア全体から見ても多くないので、どこでも人手不足
- 人手不足なのに、トラブルが発生するとシステム影響が多いシングルポイントであることが多く、メンテナンスやチューニング等でDBAの日々の仕事が多い
- こうしてDBAが今携わっているDB以外のやりたいことが何も出来ない！（別のDB製品触りたいとかも、これに含まれます）
- そんな悲しげなDBAをみて、よりDBA目指したい人が増えない！そして最初に戻る負のスパイラル！
※個人の見解です。
私自身、k8sとかコンテナとかにも興味は大いにありますし、RustやKotlinなどの開発言語にも非常に興味があります。あ、もちろんAnsible大好きです！
が、日々の業務の99.9%はDBのタスクです。
毎日まいにち、sqlplusを連打してます。ていていてい(꜆꜄•ω•)꜆꜄꜆
そりゃDBAだからそうでしょうと言われるとそうなのかもですが、ずっととあるDB製品ばかり触っていても、つまらない。DB以外のことだって学びたい。携わってみたい。
そのためにDBAがしないといけないことは、大きく2つあると考えました。
（細かいことを言い始めるとたくさんあると思うので、ここでは割愛）
- とにかくDBを安定稼働させる。トラブルやチューニング等の想定外運用タスクをなるべく防ぐ
- DBAを孤独にしない。DBを使う人達にもっとDBを理解いただき、本番サービス導入前に未然にリスクを防ぐように、一緒に考える
この2つの課題のために、DBREJPの活動をはじめたいと思いました。
とは言ったものの、いきなり「さぁ、DBをDBA以外の人に理解してもらうにはどうしたらどうしたらいいか、考えましょう！！」なんて言われても、DBAそれぞれの抱える課題は人それぞれ。
同じ製品であれどどの業種のシステムなのか、ミッションクリティカル度の違いや、セキュリティ要件、利用方法によって全く異なります。
その他にも、プロダクトそれぞれの特異な作業、開発から運用までの業務フローの違いなど…挙げ始めるときりがありません。
だから最初にすることは1つ目の「DBAが抱えている課題は何か？」を洗い出すことと考えました。
非常に広範囲な課題です。範囲も粒度もみんなバラバラです。
でもだからこそ、議論することは楽しいんじゃないかなと考えました。
例えば先日挙げられた課題は「みんなどうやってスロークエリを防止してるの？監視してても、見つけた時点でもう既に影響が出てしまっているよね？」という話がありました。
その課題に対し、色んな人が意見を出してくれます。
それはシステムもプロダクトもまたいで、「DBAと言う輪の中で」様々な角度や経験からの意見があり、それは見ているだけでも非常に興味をワクワクを与えてくれるものでした。（詳しくはDBREJPのSlackまで）
あぁみんな、こんなことに悩んだり課題に感じてるんだね。
プロダクトや技術で対応出来ることかな？技術でどうしようもできないことかな？
DBAが頑張ったら良いのかな？DBA以外の人にも協力してもらったら良いのかな？
じゃぁどうしたら良いか、一緒にアプローチを考えようよ！
そうして、みんなで課題を挙げて考え、課題が解決されてシステムが安定化して、DBAもっといろんな事ができる。
そうして溜まったナレッジは、誰もが見れるようにしたい。そうすれば、DBAでなくてもDBを安定稼働することになるのではないか。
まず直近は、そんな事ができるきっかけの場になれば、と考えています。
課題を解決していくことは、よりよいシステムを、より高速に、より安定したシステムを実現していく。
そしてそれはいつか、「システムの信頼性をあげていく」ことに繋がる。
そんな場となるよう、これから頑張っていきたいなと思っています。
この活動に、プロダクトの制限は一切ありません。
Oracleでも、Oracle以外でもなんでもいいのです。
様々なプロダクトに詳しい方が参加してくださっていますし、DBAじゃない方もいます。
プロダクト固有の話、例えば「MySQLのここが知りたい！」は、MySQLのコミュニティで会話したほうが良いです。
でも、「PostgreSQL使ってて暗号化に悩んでるんだけど、他のプロダクトだとみんなどうしてるの…？」を、話せる範囲で（守秘義務の範囲で）話をする。
そんな、DBAのみんなが抱えてる悩みや課題を、気軽に集まって話をする場になることが、直近の目標です。
お、そんな場所があるの？と思っていただいた方。
是非気軽に、Slackに参加してみてください♪
ログインはこちらまで♪
コチラ
無料アカウントなので、URLの有効期限が切れていれば、tomoのTwitterに気軽にお声がけくださいね₍ ᐢ. ̫ .ᐢ ₎
@tomomo1015 ←
それでは！明日は（というか今日なんですけどね…ぐすんぐすん）木村さんの「OCIといえばOracle Call Interface | キムラデービーブログ」ですね！
なになに気になる！という方は、ぜひ( ¯꒳¯ )ｂ✧
