データベース性能の問題を自動で検知・分析　オラクルが目指すAutonomousの未来

リフレッシュ可能なPDBの活用

日本オラクル株式会社：まずはイメージのお話です。リフレッシュ可能なPDBスイッチオーバーです。今、2つのコンテナがありますね。上と下に、CDB1と2があります。1個プラガブルデータベースをつくりました。その下にもう1個（プラガブルデータベースを）つくるんですけど、ここでリフレッシュモードにします。

2分ずつリフレッシュをかけるような、本当にこんなコマンドだけでできちゃうんだという、伝搬するものにしました。

あと、他にいくつかDBをスポスポっと立てて。もう1個、逆側に下から上にリフレッシュをかける構成があったとします。この下のほうに対して、アプリケーションであったりユーザから更新が入っている状態を考えてください。

ある段階で切り替えたくなった時に、切り替えコマンドをバスンと打ちますと、ユーザは上に切り替わる。無停止です。かつ、更新の向きも伝搬の向きも逆になる。ということで、今度は上のデータベースを更新して下に伝搬をする。こんなことがコマンドでできるのが、スイッチオーバーです。

これは手動でちゃんとやった場合、計画スイッチオーバーと書いてありますけど、もう1個あります。あんまりうれしくない話かもしれませんが、計画外というのもできたりするんですね。

例えば、さっきと同じように上から下に流れてる時に、なにかあって、上のPDBにだけ障害が発生してしまったと。おそろしいですね。こういう時にも、こちら（スイッチオーバーが）使えるんですね。今度は生きている下のデータベースから手動でリフレッシュをかけさせることができます。つまり、処理を追いかけさせるんですね。

最新の状態にしてから改めて開くと、上で行っていた処理を下にしっかりと伝搬した後、処理を継続できる。スイッチオーバーはこんな使い方もできます。

「リフレッシュ可能なPDBの活用」と題しまして、今お話した2つの機能を、これからデモンストレーションを用いてご覧いただこうかなと思います。

デモンストレーションの中身がちょっとわかりにくいので、「どんなことやってますよ」というのをお見せしながら、画面もお見せするということで、交互にやろうかなと思います。

リフレッシュ処理のデモンストレーション

まず、環境のご紹介です。今回の登場人物は3人。アプリケーションサーバが1つ。処理をかける人のイメージです。あとは、コンテナとプラガブルがそれぞれ一対。2番、3番になってますけども、この2つが今回の登場人物です。

まずデモンストレーションでは、最初に「このDB空です」というのを、いったん確認します。

確認した後に、まずアプリケーションからトランザクションをかけます。この時に、トランザクションが3つ、それぞれ100行ずつ、3つの表に対して100行ずつ入れるというイメージです。トランザクションをかけ終わると、右上のこの人に対して3つの処理が入ることを確認します。

では、まず今の状況の確認です。「no rows」「no rows」と出てきました。まずこんな感じで、DB2つに対して確認処理を都度行っていこうと思います。最初は今「no rows」なので、「何も入ってないよ」という状態ですね。

ここから今度は、下はアプリケーションの欄です。ここ、負荷をかける人はこっちにいるって思ってくださいね。それで、runをかけると、トランザクションが走ります。1インサートあたり、1つのポートがポッと出てくるイメージです。

ちょっと伝搬の時間があるので、バッと出ちゃいましたけども。こんな感じで、「今、インサートが終わったよ」ってことを意味しております。

もう1回上に戻って確認をしてみますと。伝搬されてますかね。されてますね。「いるかな？」って見てみると……見えますか？　見えますね。

上に1人、DB02のほうですね。100、100、100という更新が入っていて、下はいない。まずこれが初期状態です。こんな感じで進めていきますね。

スライドに戻ります。まず一番最初は、処理の伝搬を行っていきます。DB02からリフレッシュ処理をかけて、DB03へ100のトランザクションを伝搬します。

ここでは、内部的にはリフレッシュ処理をかけます。本当にリフレッシュコマンドはめちゃくちゃ簡単でして、これはスクリプト化しちゃってますけど、「ALTER PLUGGABLE DATABASE REFRESH」というコマンドです。

もうリフレッシュが終わっちゃいました。「じゃあ、中はちゃんと入ってるのかな？」というのを確認してみます。すいません、地味ですよね。

出ましたね。見事、下のDB03に100が伝搬されました。これがリフレッシュです。

PBDスイッチオーバーのデモンストレーション

では本題です。今度はこの上のDBに対して、もう1回トランザクションをかけていきます。ポイントは、まず1つ目のトランザクション1を終えて、上に200が入った。（100行から）200行になったというのがコミットを終えた状態です。続けて2のトランザクションが走るんですけど、その途中で、鬼の気持ちでスイッチオーバーをかけるのがここの味噌です。

（トランザクションを）行っている最中にスイッチオーバーをかけると、トランザクションの向きが変わります。この時に見ていただきたいのは、「トランザクションどうなってるのか？」というところですね。「エラー返ってるか？」という。

実際デモの中身では、ちゃんとスイッチオーバーされて、DB03のほうにトランザクションが入っているところを確認いただいて、「これがPDBスイッチオーバーですよ」と言うところをこれからやっていきます。

まずは下のほうですね。これでトランザクションかけていきます。

今、1つ目のトランザクションがかかってます。それが終わったら、1回確認を入れますね。今の段階ではまだトランザクションが終わってないので、（DB02とDB03のTSN1は）100、100の状態のままです。

はい、トランザクション1つ目が終わりましたので、中身を見てみます。そうすると……地味ですね、上に200と入りましたね。これで上のDBに200の状態になりました。

まだまだ処理が続いています。今2本目のトランザクションが走っている最中に、スイッチオーバーを行いました。

今日のクライマックスはここです。（トランザクションが）止まりましたね。ここでトランザクションは、エラーが返ることなくいったん待たせます。今、裏側で一生懸命処理を切り替えています。

今、スイッチオーバーのコマンドを打った最中なので、……まだ途中ですね。スイッチオーバーというコマンドを打っています。ドキドキが止まらない。もうちょっとですかね。今、切り替え処理中です。

来た！　来ました。これで今スイッチオーバーが終わったので、見てください。トランザクションが来ましたね。これがクライマックスでした。

DBで自動的にエラー処理を完結できる

こんなことが自動でできるのがスイッチオーバーでした。トランザクションが最後まで終わったので確認してみると、ちゃんと下に200、200と入っているのがポイントです。トランザクションは、いったん続けちゃいましょうか。今、3番目のトランザクションが進んでる段階です。

どうですかね？　私はこれはけっこうすごいと思うんですよね。DBで全部完結しちゃうので、エラーが返らないのはすごくうれしいなと思うんです。何が起きているかは、この後もうちょっとご説明します。

3番目のトランザクションが、終わりましたので、一応確認してみましょう。下のDB03が全部200、200、200になりましたということで、下にちゃんと処理が引き継がれて、その後も行われたのが、確認いただけるかなと思います。

では、何が行われたのか？　簡単に「スイッチオーバーでひっくり返ったよ」と一言で言っちゃったんですけど、実は中でけっこういかついことが行われているので、そのご紹介です。

話は戻ります。またトランザクション1が終わって、2をかけている段階のお話に戻ります。スイッチオーバーのコマンドを打った段階で、今何が行われているかなんですけど、実は一番最初に、まずはPDBリフレッシュが裏側では行われています。

だから、上で（TXN1の）200の処理が終わって、下に伝搬されたのはこいつのおかげなんですね。まずリフレッシュをすることによって、200あったやつが下に伝搬されて、200、100、100の状態がつくられました。

ここからなんですけど、処理を切り替えました。この時に、もうトランザクションは1回やめて、DB03に再接続をしています。

そうなるとトランザクションの途中なので、DB的には「あ、これ、ダメだ。ダメトランザクションだ」となって、実はトランザクションをかけていたDB02はロールバックされています。だから、200、100、100の状態でコミットされた状態です。

「じゃあ、その後どうなったの？」という話なんですけど、2のトランザクションは下にかけてますよねと。ここで行われてるのが、先ほどお話したApplication Continuityなんですね。「途中、さっきの上のトランザクションが未コミットだから、下でもう1回リプレイしよう」。

これを全部自動にやってくれたからこそ、下に処理が伝搬されます。それで200、200が実現できた。これがスイッチオーバーの味噌でした。こんなことが18cだとできちゃうんです。

PDBスナップショット・カルーセルのデモンストレーション

先ほどのデモでは、この後、トランザクション3をかけて300に持っていきました。

最後、デモの中身では、リフレッシュをかけて200、200に合わせて、スイッチオーバーはおしまいになります。リフレッシュコマンドを打ったので、ここで確認をしてみましょう。

カウントしてみると、見事に200、200が引継がれていて、同じ状態が同期されました。無事にできてめでたしめでたしというのが、スイッチオーバーのお話でした。

ここから2つ目のPDBスナップショット・カルーセルのデモに移ろうと思います。

今度は、先ほどから裏側でトランザクションを進めちゃってますけども、300からスタートです。300、300で、上から下に伝搬している環境です。まずは300、300の状態で、スナップショット取ります。

ちょっと遷移が見えなかったですね。一番最初に、下のDB03から、この初期状態でスナップショットをカルーセルの中に取ります。ポイントは更新元じゃなく、スタンバイのほうから取れるので、更新元に影響なく取れちゃうというところですね。

次にトランザクションをかけます。先ほどと同じように、上に400のトランザクションをかけて、400になって、リフレッシュをして、下にも400を伝搬させるという一連の流れをします。

その後、もう一度、下からスナップショットを取るということで、2つのスナップショットを取ります。

今、スナップショットを1発取った状態にしています。「スナップショットが今1人取られたよ」というのを確認しているのが、こちらです。自動で取ってるので、名前は自動生成になってます。

ここからDB02に対してトランザクションをかけて、400のカウントに回していきます。これは一瞬でできると思います。

トランザクションがかかったので、また上に戻って今の状況を確認してみると、まず上が400と、（DB02が）400、（DB03が）300の状態になってますね。（上を指して）400、（下を指して）300です。ここで1回リフレッシュをかけて、下に400のトランザクションを伝搬させます。

「ALTER PLUGGABLE DATABASE REFRESH」だけですから、本当に便利だと思います。これでリフレッシュはおしまいです。また確認してみると、トランザクションがいると思います。

スナップショットで過去のデータを再現できる

（DB02が）400、（DB03が）400と、トランザクションが引き継がれたと。なので、ここで今度下のDB03のほうからスナップショットを1発取ります。「ALTER PLUGGABLE DATABASE SNAPSHOT」のコマンドだけでスナップショットが取れます。スナップショット名は「SOE S02」です。

取れましたので、中身を見てみます。「今、2つのスナップショットが取られたよ」というのが確認できます。

ここからもう1回、上にトランザクションをかけます。下に伝搬する、今度500の状態にするということですね。

もう一気にババーッとトランザクションをかけちゃいます。確認をしてみると、（DB02が）500、（DB03が）400になっているというかたちですね。

リフレッシュをかけてしまって確認をします。（DB02が）500、（DB03が）500になりました。

ここからなんですけど、今度は取ったスナップショットを使って（データ）を戻していこうと思います。今は最初に取ったスナップショットを戻しているので、中身は300が入ってるはずなんですね。それを見てみると、見事300が入っています。

つまり、過去に取ってあったスナップショットを戻したので、昔のデータを再現できたというのが確認できます。こういうことをすべてのスナップショットにおいて行えるのが、このPDBスナップショット・カルーセルのポイントでした。

簡単ではありましたけれども、こんなことができました。「Autonomousなので」というところと絡む意味で言うと、好きな段階に戻れる。あとはスイッチオーバーを使えば、今後は無停止でどこでも動くようになるのかなという気がします。

最後、データベース管理のお話なんですけども、やっぱりデータベースはAutonomousが非常に重要です。18cにも、そういった機能がたくさん出てきています。ポイントは、無停止でパッチ適用できるようになったことです。

Grid Infrastructureというクラスタウェアですね。このソフトウェアは、今まで停止が必要だったんですけど、無停止で当てられるようになったので、より自動で（パッチを）当てるということに近づいたのかな、というのが1つです。

進化し続ける自律型データベース

あともう1つ、12から入ってきた機能でAutonomous Health Frameworkというものが、初めてAutonomousの名前が入った機能です。

問題が起きた時に何が起きていて、何をすべきか、そんなことを自分で解析する機能です。

その中で、Cluster Healty Advisorという機能がありました。これは18cで拡張されてまして、自分の中で性能に問題があったら、検知して、分析して、何をすべきか、ここまで全部自分で考えて、つくり出すことができます。

今流行りの機械学習がまさに使われておりまして。これは、これまで弊社に寄せられた障害報告を分析した結果による傾向などを取り入れ、モデルの開発を行いつつ、また使いながら自分で自己学習を進めていきます。内部的にはベイジアン・ネットワークベースで診断モデルをつくって、より適切なアドバイスを出していく。

つまり、何が平常値で、何が異常値なのかを学習から導いていくことができるようになっています。

実際にEnterprise Managerの画面と統合をして、「なにか起きたから、こういうことをしたほうがいいですよ」という具体アクションまで出してくれるようになっています。

今はまだ解決策の提示までですけど、これが自動で適用できるようになったら、今後はよりAutonomousっぽくなるのかなといったところです。

お時間になりましたので、まとめに入ります。ちなみにAutonomousのデモはYasinさんとまったく同じだったので、今日は割愛させてください。

18cという話をしました。年次リリースモデルとして、より品質が向上し新機能を使っていただけるようになるかなと思います。

マルチテナントという、2つの話をしました。スナップショット・カルーセルとスイッチオーバーはこんな機能で、より新しいことができるようになってきますよ。

データベース管理も進化しています。Autonomousという観点で言うと、さまざまな自動化テクノロジーの積み重ねで、このAutonomousが実現されています。これから、Autonomousというものがより継続的に進化をしていくので、ぜひご期待くださいというお話で、私のセッションは以上になります。ご清聴いただきありがとうございました。

（会場拍手）