🔬
公式が教えてくれない！ Oracle Database@GCPがWeb系エンジニアにもちょっと面白そう？

2025/12/01に公開
こちらの記事はOracle Cloud Infrastructure Advent Calendar 2025 シリーズ3 Day11 の記事として書かれています。

 はじめにデータベース、大事ですよね？
GCPならCloud SQLやAlloyDB、Cloud Spanner。AWSならAuroraやDynamoDB。最近はPlanetScaleやNeonも人気です。

適材適所でNoSQLやグラフDBやベクトルDBを組み合わせるのも当たり前になってきました。
でも、あえて。今回話をしたいのが Oracle Database です。
「えっ、Oracle？ SIer御用達の？」

「高そう、古そう、難しそう...」

「スーツを着た人たちのためのDBでしょ？」
そんなコメントが見える気がします＞＜ でもそれは、半分正解で半分間違いです。

正直、Oracleのマーケティングはエンタープライズ寄りすぎて、我々パーカーを纏うWebエンジニアには響きにくいんですよね。
でも、実は最近のOracle、特にAutonomous Database（ADB）Serverlessはかなり別物です。DBaaS的に使いやすい機能が揃ってきて、Web系やスタートアップの選択肢として普通に戦えるところまで進化しています。
私自身はオンプレミスなシステムでOracleを触る機会もあるんですけど、逆にそういった面白そうな機能は普段Oracleを採用するような現場では使えなかったりもして、気にだけなっていたりしました。
そんな中、ここ数年は Oracle Database@マルチクラウド が増えて、いつものGCPやAWSで使えるっぽい。

しかも、AuroraやAlloyDBと比較しても 「意外と安い」 という衝撃の事実。爆速/高可用のExadataが普通に勝負できる価格で使えるのはちょっとした驚きです。
だったら、ちょっと試してみるかな？ というわけで、公式があまり教えてくれない 「WebエンジニアのためのOracle Database@GCP」 の魅力を、普段はオンプレミスとかでOracleを触ってる目線で、Oracle Database@Google Cloud（以下ODB@GCP） を試しながら独断と偏見により紹介します！ ADBはお仕事では使えなかったので私もちょっと楽しみです＞＜

 TL;DR
Oracleは高い？: ADB Serverlessなら月額10万円から。本番ワークロードでもAuroraやAlloyDBと比較できるレンジ。

Web系に不向き？: DRCP（サーバサイドコネクションプール）で、FaaSなどのサーバーレス環境と相性抜群。

圧倒的な性能: ハードウェアレベルでチューニングされたExadataは、多くのOLTP/OLAP系ユースケースで極端なスループット・レイテンシを出しやすい。

運用が大変？: インデックス作成からパッチ当てまでAIが自律運用（Autonomous）。

レガシー？: JSON、Vector、Graphも1つのSQLで扱える「コンバージドDB」は、むしろ最先端のアーキテクチャ。

 まずはコスト感の話 - 「Oracle＝高い」はもう古い？ADB Serverless@GCPの技術的な面白さを語る前に、最大の心理的ハードルである 「お値段」 について片付けておきましょう。

「Oracle？ Exadata？ どうせ数千万円〜数億円の世界でしょ？」って思うと頭に何も入らないですものね＞＜
そのコスト感覚は、10年前なら正解 です。ミッションクリティカルな世界の「今」 もそう。でも、クラウド時代の普通の運用ではちょっと違います。
先に結論だけ言うと、インフラ的構成を同条件でマルチゾーンまで揃えるとADBはやや高めです。

ただし冗長構成の違いや性能によるコスパ、Autonomousの運用削減まで含めると比較の余地は十分ある、という感じです。

 フェラーリをタクシー料金で乗るOracle Cloud Infrastructure（OCI）の登場以来、Oracle DBは柔軟な構成が取れるようになり、結果として安く使えるようになりました。

特に ADB Serverless は、バックエンドのExadataをマルチテナントでシェアする仕組みです。
つまり、「フェラーリ（Exadata）をタクシー（Serverless）としてワンメーターから利用できる」 ということ。

初期費用ゼロで、開発用途や稼働時間を絞った使い方なら月額数万円台から、本番で24x7それなりに使っても 10〜数十万円クラスで Aurora や AlloyDB と十分に比較できるコスト感ですよね。
また、もちろんクラウドなので作ったり消したりも簡単です。今回ちょっと実験のために数日動かしましたが1日あたり16ドル程度でした。これは24時間動かした数字なので、もっと小さく出来ると思います。PoCくらいならやっても良いかな、ってお値段ですね。


 少しだけリアルに比較してみる(vs Aurora / AlloyDB)もう少しだけ実際的な比較をしてみます。ただ、コスト比較といっても、ECPU単位だったり、ACUだったりコストモデルが違うので一概に比較はできないのですが、いったん以下の様な構成で価格比較を検討してみます。AuroraはいろんなAuroraがありますが、なんとなく同じサーバレスで比較してみました。
シナリオA：中規模 本番環境 (HA構成)

要件: 4 vCPU / 32GB メモリ相当、高可用性（99.99% SLA）、ストレージ 500GB。

比較: Aurora (Multi-AZ), AlloyDB (HA), ADB (Autonomous Data Guard)。


項目
Amazon Aurora Serverless v2
Google AlloyDB
Oracle ADB Serverless


月額概算

約 $3,614 (約54万円)

約 $1,354 (約20万円)

約 $4,132 (約62万円)

※ いずれも 2025 年 11 月時点の東京リージョン公開価格をベースにしたざっくり概算です。目安なので、実際は各社の料金ページで再計算してください。
月額60万円なのでやはりOracleが少し高いです。とはいえ、これは他と合わせてマルチゾーン構成にしているからでもあります。
Autonomous Database は、最小構成の 2 ECPU からでも裏側は Exadata + RAC 構成で動いていて、単体で 99.95% SLA を提供しますし、複数台で構築されているので無停止パッチや冗長性の担保がされています。これにAutonomous Data Guard を有効にしてマルチゾーン構成にすると 99.995% SLA に引き上げる形です。ちょっと、冗長性の組み方が異なってます。
この表のADBは Aurora / AlloyDB と条件をそろえるためにマルチゾーン構成にしていますが、もしリージョン内冗長が不要であれば、単純にこの「半額くらい」が ADB シングル構成の目安になります。ここは判断ですね。

また、後述するExadataの高速化機能が効く場合はマシンスペック以上のコスパが得られる可能性もあるので、とりあえずは月額で何百万円もするような比べられないコストじゃない、ということが分かったのが収穫ですね。
というわけで、「Oracleは高嶺の花」ではもはや無く、「AuroraやAlloyDBと比較検討できる価格帯」 です。

 隠れたコスト - 人的リソースの削減効果もうひとつ、忘れてはならないのが 「人的コスト」 です。

システムのランニング費用は、インフラコストだけじゃなくて、運用コストも考慮する必要がありますよね？
Aurora や AlloyDB は「Managed」サービスなので、ハードウェアの管理、OSのパッチ適用、バックアップなどは自動化されています。でも、データベース内部の論理的な管理は依然としてユーザー（DBA）の責任です。
これに対して Oracle ADB は「Autonomous」を掲げていて、こうした領域のかなりの部分をAIが代行してくれます。いわゆるAIOpsってやつですね。


タスク
Amazon Aurora / AlloyDB (Managed)
Oracle Autonomous Database (Autonomous)
Human Costへの影響


インデックス設計

手動/支援型: スロークエリログを分析し、DBAがインデックスを作成。AlloyDB の Index Advisor は「推奨」のみで適用は人間が行う。

全自動: 機械学習がワークロードを常時監視し、インデックスの作成・削除・再構築を自動実行。性能向上を確認してから適用する。

大: 高度なスキルを持つ DBA のチューニング時間をほぼゼロにする。

パッチ適用

手動/スケジュール: メンテナンスウィンドウの設定が必要。ダウンタイムやフェイルオーバーが発生する場合がある。

全自動・無停止: RAC のローリング適用により、アプリ稼働中に透過的にパッチが適用される。ユーザーは意識すらしない。

中: 深夜メンテナンスや調整業務からの解放。

パフォーマンス・チューニング

手動: バキューム設定（Postgres）、メモリパラメータ、並列度の調整など、専門知識が必要。

全自動: メモリ配分、並列度、オプティマイザ統計を自己調整。

大: 性能トラブルシューティング工数の削減。

セキュリティ構成

必要: 暗号化設定、監査ログ設定などをユーザーが行う責任がある。

Always-On: デフォルトで常時暗号化。セキュリティパッチも自動適用。設定ミスによるリスクを排除。

中: セキュリティ監査対応コストの削減。

Aurora にも DevOps Guru for RDS や Performance Insights、AlloyDB にも Index Advisor や自動メモリ管理など、運用コストを下げるための機能はもちろん揃っています。

なので「Oracle だけが自動化している」という話では全くありません。
それでも、「人が最後に判断する前提」から「基本は AI に任せておく前提」へ振り切っているのが ADB です。好みはあれど先進的ですね。ドキドキする機能でもありますが＞＜
ちなみにIDC や Wikibon の調査によると、チームの効率が 66%向上、DBA 4.8人分の人件費を削減と紹介されています。アメリカなので、年収1000万円として4.8人分だから4,800万円のコスト削減とのこと。
Oracle Autonomous Database TCO Report
月額十数万円のインフラコストの差など、この「人件費削減効果」の前では誤差のようなものですね。本当に「DBのお守り」からエンジニアが解放されるのであれば、ADBの採用は非常に大きなコストメリットです。
とはいえ、このレポートは一応外部調査とはいえ、公式が全力で引用している時点で ほぼ大本営発表 みたいなものでもあります。

多少は眉に唾つけつつ、実際の削減効果は君のプロジェクトと財布の目で確かめてみてくれ！

 Oracle Database@Google Cloudとは？
 Oracleのマルチクラウド戦略さて、コストの話をざっくりとして「聞いても良いかな？」という気持ちになったところで、そもそもOracle Database@Google Cloudってなんだよって話を少しします。
GCPのOmniシリーズやAzure Arcなど王者AWS以外の各社はマルチクラウド戦略を持っています。そして、OCIは ExadataをAWSやGCP、Azureで動かす というマルチクラウド戦略をとっています。自分たちの武器が良く分かっていますね！
この「Oracle Database@マルチクラウド」はちょっと面白くて、Exadataを含むOCIインフラをGoogleなどのデータセンターに直接配置して動かす、というモデルです。
つまり、マルチクラウドなんだけど同じゾーンにあるGCEやGKEとネイティブな速度で動くってことです。これはExadataの特徴の一つであるマイクロ秒レベルのレイテンシーを維持するために必要なことなんですが、面白いアプローチですよね！
実際としてはRedis Enterprise等と同じく普通のマーケットプレイスです。裏側はOCIですが基本的な操作やモニタリングはGCPの管理コンソールから実施できます。
データプレーンがGCP上に置かれるマーケットプレイスはちょいちょいあると思いますが、それがベアメタルってのは流石にユニークですね＞＜
また、詳しい人は「AWSのAmazon RDS for Oracleと何が違うの？」って思うかもしれませんが、後述するRACが使えることが決定的に違いますし、Exadataによる性能や、サーバレスなどDBaaSとしての使いやすさも無視できないポイントです。
ようするに、この辺のOCIのインフラをそのまま、Google等のデータセンターに持ち込むソリューションですね。

 ADB Serverlessとは？ODB@GCPでは様々なサービスを利用できますが、今回はDBaaS的に使えて便利なADBサーバレスを中心に話します。


ref: Oracle Database@Google Cloud：サービス概要のご紹介
正式名称は Autonomous AI Database Serverless 。

一言で言えば、 「Exadataという最強のハードウェア上で動き、AIが運用を自律的に行う、フルマネージドなサーバーレスDB」 です。
「Oracle Database」と聞くと、サーバーにインストールして、パラメータをチューニングして... という重厚長大なイメージがあるかもしれません。専門のDBAを組織したり、Oracleやサードパーティのコンサルに依頼して構築や運用をするもの、そういうイメージですよね？ でも、ADBサーバレスは全く別物です。

DBaaS: クラウドネイティブで管理コンソールやTerraformから簡単に構築可能。

完全サーバーレス: インスタンスのプロビジョニングや管理は不要。

オートスケーリング: 負荷に応じてCPU（ECPU）が自動で増減。使った分だけ課金。
要するに、「中身はOracle/Exadataなんだけど、使い勝手はAurora ServerlessやCloud SQLと同じ（かそれ以上に楽）」 というサービスです。

Webエンジニアが普段使っている「クラウドネイティブなDB」の選択肢の一つとして、違和感なく使えるようになっていますし、AIによるパッチ当てやパフォーマンス最適化なども自動で行われる面白データベースです！

 Exadata - Oracle流、僕の考えた最強のでーたべーす！先ほどからちょいちょい出てくる謎の単語、Exadataに関して説明しましょう。簡単に言えばこれは 「データベース専用のスーパーコンピュータ」 です。
「クラウド時代にハードウェア？」と思うかもしれませんが、現代は極限の性能を出すにはかつてのHadoopの時代の様にコモディティなハードウェアでソフトで頑張るというよりも、GoogleがTPU Podを作るように最適なハードウェアを前提にソフトウェアで頑張る、というのが現実です。そう考えると時代を先取りと言えなくもないかも？
そして、Oracle Databaseには、他のデータベースとは違い シャーディングを行わずに書き込みがスケールする、RAC（Real Application Clusters） という構成があります。これは、複数のDBサーバーがネットワークを介してCache Fusion（キャッシュフュージョン） という仕組みでメモリを共有すること、そして同一のストレージを共有すること、で書き込みがスケール可能で、一貫性も保たれる分散DBを作る仕組みです。



ref: Oracle Database 入門 - Oracle Real Application Clusters【アーキテクチャ詳説編】
SpannerなどのNewSQLも同じように 「単一の論理DBを複数ノードで動かす」 分散DBですが、仕組みはかなり異なっています。RACはシャーディングではなく全DBで状態を同期(Shared Everything)なので、アプリ側でシャードキーなど分散データベース特有の設計を意識することが少ないのが大きなメリットですね。
ただ、メモリをサーバ間で共有するということで、高帯域/超低レイテンシのネットワーク が必要になります。そのため、まさしくスーパーコンピュータで使われる技術であるRDMA over Converged Ethernet（RoCE） という超高速な内部ネットワーク技術や、大容量キャッシュ、分散ストレージなどソフトウェアのボトルネックを解決するための最適なハードウェアとして構成されているのがExadataです。
コンピュートとストレージサーバを分離する事で、独立してスケールさせることが出来るようにしたり、処理をオフロードできるのですが、このあたりはAuroraやAlloyDB、あるいはBigQueryなどでも今となってはお馴染みの構成ですね。
さらに大容量フラッシュを賢くキャッシュに使う Smart Flash Cache や、X11M 世代で入った Exadata RDMA Memory (XRMEM) で DRAM をリモートメモリとして使うことで、マイクロ秒クラスの読み取りレイテンシを実現するなど、いろいろ変態的な最適化が入っています。どう考えても変態の所業です。
このあたりの話は少し古いですがこの辺の資料が参考になると思います。最新のすごさ自慢はこっちの資料を見てください。
まあ、小難しいことは置いておいて、最大 24,320 ECPU までスケールして、ワークロードがハマればライト性能も一緒に伸びていく、なんだかやたら速いRDB という公式チートアイテムみたいなDBだと思っておけば十分ですね。

 「チューニング疲れ」からの解放：勝手に速くなるDBさて、話は変わりますが、難しいこと考えずにSQLが速くなったら良いと思ったことはありませんか？ 私はわりと思います！
データベースを速くするというと、まず最初に思いつくのはインデックスを貼ることですよね？ でも、闇雲にインデックスを貼れば書き込み性能等に影響が出る懸念もあります。他にも統計情報が古くて実行計画が狂ったり、テスト環境の想定と本番環境の実際のデータの量や偏りが異なって上手く性能が出ない話もありますよね。
こうした悩みから解放してくれる、プログラマーを甘やかしてくれる魔法の箱、欲しいと思ったこと無いですか？ 完全ではありませんが、そんな魔法を提供してくれるのがExadata/ADBです。

 単純に速いレイテンシーExadataはハードウェア的にもソフトウェア的にも 「速い」設計になっています。前述の通り変態ハードウェアなのですが、それをプログラマは気にすることなく普通にSQLを書けば速いんです。
どのくらい速いかというと、低レイテンシー過ぎて 「N+1クエリ」 が多少紛れ込んでいても、いきなり即死みたいな事態にはなりにくい、というレベル感です。マイクロ秒レベルの性能は伊達ではありません。
もちろん、N+1クエリは言うまでもなく邪悪なビジネスロジックなので本来は直すべきです。ただ、技術的負債を抱えてでもまず走りたいフェーズでは、Exadata/ADBのおかげで 「致命傷になる前に直すための猶予」 を得られるのはアプリケーション目線では朗報ですよね。なお、DBAにはキレられます＞＜

 SmartScan、フルスキャンを速くする！ADBのバックエンドであるExadataのストレージは単なるSSDやHDDの集まりではなく、CPUを搭載したサーバです。そのため、インテリジェンスなストレージとして本来DBサーバでやる処理をオフロードする事ができ、その典型的な例が SmartScan です。最近はちょいちょい他のシステムでも見かける構成ですね。
これはストレージが問い合わせを解釈し、必要なデータだけをDBサーバーへ返すことで、サーバーとストレージ間のI/O量を最小限に留め、安定した性能を実現する技術です。DBのCPUリソースが浮くだけではなく、ネットワークI/Oも最小化されるため、効果は抜群です！
条件がハマると、数百万行〜数千万行クラスのレコードをリアルタイム処理でフルスキャンしても、正直「言われるまで気づかなかったな…」というくらいの体感になることもあります。「お前、行ストアのくせにアタマBigQuery かよ」 。なお、不用意に頼りすぎるとDBAにキレられるかもしれません＞＜
ただ、これは単なるサボり用途ではなく、インデックスを付けると書き込み性能に影響が出るような、ライトもそこそこ多いテーブルに対する集計やバッチ処理にとても効果的です。もちろん、CQRSなどを駆使してアプリケーション設計でそうしたワークロードに対処する方法もありますが、そういった工夫をテーブルに入れなくても済むなら、それに越したことはないですよね？ シンプルなのは良いことです。
もちろん、「すべてのインデックスが無くて良い」なんていう暴論ではありません。OLTPのポイントアクセスや小さいルックアップは、普通にインデックスが大事です。ただ、DWH的な集計クエリやバッチ、読み書きのバランスでインデックス設計に悩むテーブルなどでは、SmartScan前提の設計に振った方がシンプルで速くなるケースもあります。
「フルスキャン＝遅い」 という従来の常識を疑うケースもあるのは面白いですよね。まあ、これに関してはロックインの極みなので、ご利用は計画的に。
Exadataにはこのほかにも、こうしたストレージ側へのオフロード系やその他の高速化技術がいくつもあって、カタログ読んでると結構楽しいです！

 AIによる自律運転 - 24時間365日働くAI DBA流行りの生成AIを使ってるわけではありませんが、ADBの売りの一つがAIによる自律運転(Self Driving)です。Oracleはこのあたりの機能をAutonomousと呼んでますね。一般的な言葉としてはAIOpsかな。



ref: Autonomous AI Database Serverless 技術詳細
最近、DB x AIみたいな話題は多いですが、そのほとんどはDBのクエリの中などでAIが活用できる、とかAIのバックエンドとしてのベクトルDB的な話です。Oracleでもこの辺の機能自体はありますが、今回話したいのはそうではなく、DBAがやる作業をAIが自動化してくれる系の話。
例えば、ADBがワークロードを常時監視し、「このクエリ、インデックスあった方が速いな」と判断したら、勝手にインデックスを作成してくれます(Auto Indexing)。同じくパーティション化なども対象です。実際にインデックスが貼られる前に、自動で実行計画の評価がされ結果が悪くなるならもちろん適用されません。賢い！
他にも、Exadataはマルチコアでコンピュートが複数あり、しかもストレージも分散ストレージということでパラレルクエリの効果が非常に高いのですが、アプリケーション側で特に指定しなくても効果が高そうであれば、パラレルクエリに変えるなどのチューニングも行ってくれるみたいです。
さらに、ソフトウェア的な部分だけではなく、ECPUのスケールアップやスケールダウンといったハードウェア的なチューニングも自律的に行ってくれます(AUTO DOP)。
こうした機能は、実は 「速くも遅くもなって欲しくない/同じ側で安定的に動いてほしい」 というエンタープライズでミッションクリティカルなOracleの主要顧客層のニーズと微妙にマッチしてなくて、使いたいけど実運用での人気は無いって機能です。でも、DBよりもアプリケーションに集中したいフェーズには願ったりかなったりの機能なので、使えるケースは結構あるんじゃないかと期待しています。まあ、ADBに関しては私もちゃんと本番運用したことがまだないので、真価を実感したいところですね。
というわけで、Exadata/ADBは、完全ではありませんが我々を 「DBチューニングという苦行（Toil）」 から解放してくれるデータベースなんです。

 クイックハンズオン：サクッとADB Serverless を立ち上げてみる
 ADBの構築とりあえず、ここまで御託を並べてきたので、そろそろ手を動かしたいですよね？ 超ざっくりですが、ODB@GCP で ADB Serverless を触ってみるには大きくは以下の流れです。
マーケットプレイスからパブリックオファーを送りOCIテナントを作成して紐づける
ODBネットワークをGCPのVPC内に作成する
ADBインスタンスを作成する
作るときには、以下のマーケットプレイスから選択します。Oracle側でも処理が走るので、少し待ちますが、さすがに24時間もかかりませんでした。



https://console.cloud.google.com/marketplace/product/oracle/oracle-database-at-google-cloud
そのあとはODBネットワークをGCPのVPC内に作成して、ADBインスタンスを作成すれば、自動でOCI側にもネットワークやデータベースが作成されます。



ADBサーバレスであればネットワークなどはそこまで設計できる部分が無いので、結果的に簡単です。IAMはこの辺を読んでください。
また、基本的な操作はGCP上からできるんですが、たとえば管理者パスワードのリセットとか、通常のインフラメトリクスを超えるSQLレベルのパフォーマンスモニタリングとかはOCI側からやる必要があります。以下のようにOCIコンソールからアクセスできます。



こんな感じでOCI側からも見えてちょっと面白いですね。普段からOCIのコンソールを使い慣れている人にとっては便利かもしれませんね。

ちなみに、セットアップに関しては、こちらの記事がとても分かりやすかったので参考にしてみてください。

https://qiita.com/yunagash/items/e44bde42f1bcebacceba

https://qiita.com/yunagash/items/c9443e866bbaa15d4ce8

 ADBへの接続DBを作成したら、以下の様に適当なGCEからsqlplusなどで接続してみます。まずは接続情報のウォレットをダウンロードします。

GCEインスタンスにsqlplusをインストールして先ほどダウンロードしたウォレットを配置します。
# sqlplusのインストール
apt-get install -y libaio1 wget unzip
sudo wget https://download.oracle.com/otn_software/linux/instantclient/2390000/instantclient-basic-linux.x64-23.9.0.25.07.zip
unzip instantclient-basic-linux.x64-23.9.0.25.07.zip
sudo wget https://download.oracle.com/otn_software/linux/instantclient/2390000/instantclient-sqlplus-linux.x64-23.9.0.25.07.zip
unzip instantclient-sqlplus-linux.x64-23.9.0.25.07.zip

export LD_LIBRARY_PATH=/opt/oracle/instantclient/instantclient_23_9
export PATH=$PATH:/opt/oracle/instantclient/instantclient_23_9
export TNS_ADMIN=/opt/oracle/instantclient/instantclient_23_9/network/admin
ln -s /opt/oracle/instantclient/instantclient_23_9/sqlplus /usr/local/bin/sqlplus

# Walletの配置
export WALLET_DEST_DIR="/opt/oracle/instantclient/instantclient_23_9/network/admin"
unzip -o Wallet_ODB-ADB-TEST001.zip -d "${WALLET_DEST_DIR}"
cat "${TNS_ADMIN}/tnsnames.ora"
接続は普通にSQLPlusで。もちろんJavaScriptやPythonなどのアプリケーションからも接続はできます。
# 接続
sqlplus ADMIN@odbadbtest001_high 
> SQL*Plus: Release 23.0.0.0.0 - Production on Fri Dec 5 02:50:12 2025
> Version 23.9.0.25.07
> Copyright (c) 1982, 2025, Oracle.  All rights reserved.
> Enter password: 

> Connected to:
> Oracle AI Database 26ai Enterprise Edition Release 23.26.0.1.0 - for Oracle Cloud and Engineered Systems
> Version 23.26.0.1.0
> SQL> SELECT TABLESPACE_NAME, STATUS, CONTENTS FROM DBA_TABLESPACES;

> TABLESPACE_NAME                STATUS    CONTENTS
> ------------------------------ --------- ---------------------
> SYSTEM                         ONLINE    PERMANENT
> SYSAUX                         ONLINE    PERMANENT
> UNDOTBS1                       ONLINE    UNDO
> DATA                           ONLINE    PERMANENT
> DBFS_DATA                      ONLINE    PERMANENT
> TEMP                           ONLINE    TEMPORARY
> SAMPLESCHEMA                   READ ONLY PERMANENT
> UNDO_8                         ONLINE    UNDO

> 8 rows selected.

> SQL> 

 Terraformちなみにデータベースの作成はTerraformモジュールを使う事でも出来そうです。
terraform {
  required_version = ">= 1.5.7"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
    oracle = {
      source  = "oracle-terraform-providers/oracle"
      version = "~> 1.0"
    }
  }
}

provider "google" {
  project = "your-project-id"
  region  = "us-central1"
}

provider "oracle" {
  project_id = "your-project-id"
}

resource "oracle_db" "adb" {
  name                = "your-db-name"
  cpu_core_count      = 2
  storage_size_in_gb  = 20
  db_version          = "21c"
  db_workload         = "OLTP"
  db_password         = "your-db-password"
  db_admin_password   = "your-db-admin-password"
  db_admin_username   = "your-db-admin-username"
  db_admin_email      = "your-db-admin-email"
  db_admin_phone      = "your-db-admin-phone"
  db_admin_first_name = "your-db-admin-first-name"
  db_admin_last_name  = "your-db-admin-last-name"
}
ref: Announcing Terraform providers for Oracle Database@Google Cloud
やっぱ手でポチポチやるのは面倒だし本格的な運用でIaCが使えるのは良いですよね！ テスト環境もサクサク作れます。

 ADBでつかってみたい機能たち
 グッバイ、SQL Proxyさて、ここまでExadataやAutonomous Databaseがどんなデータベースで、どういう風に触れるのかを話してきたので、ここからはどんな感じに身近に役立ちそうかを考えていきたいと思います。
クラウドのコンピューティングといえばCloud RunのようなCaaSやFunctions、あるいはAWSのLambdaのようなFaaSはデプロイするだけで動くし、スケールアウトも手軽にできる最有力候補ですよね？
でも、クラウドネイティブなデータベースはともかく、トラディショナルなRDBとは相性が悪いことが多いです。その理由の1つがコネクションであり、サーバレスで自由にスケールアウトさせると簡単に「コネクションが枯渇する」というのは悩みの種の1つです。

 なぜコネクションプールが必要なのか？MySQLやPostgreSQL、あるいはOracle Databaseのような伝統的なデータベースはクライアントとDBでコネクションを貼り、その中でリクエストをやり取りするのが一般的です。
これはHTTPなどと異なり接続しっぱなしなので、低レイテンシ―で動く半面１つ１つのコネクション確立や維持はCPU的にもメモリ的にも比較的負担の大きな仕組みとなります。そのため、JSにしろJavaにしろRubyにしろ、多くのフレームワークは 「コネクションプール」 を使って、一度作った接続を使い回すことで高速化をはかります。
SpannerなどのクラウドネイティブなDBは、HTTP/2(gRPC)による多重化やAPIベースのアクセスを前提としており、大量の同時接続を前提に設計していますが、多少レイテンシーが犠牲になってもスケールアウトさせやすいのですが、高価なJDBCなどのコネクションを並列で回すにはコネクションプールは非常に良い仕組みでした。

 FaaSでプールが効かない理由しかし、Cloud RunやCloud Functionsのようなステートレスな環境では、この常識が通用しません。

FaaSはリクエストのたびに新しいコンテナが立ち上がり、処理が終われば消えます。つまり、「使い回すべき接続」を保持する場所がないのです。
さらに悪いことに、FaaSは負荷に応じて数千コンテナまで一気にスケールアウトします。

各コンテナが「とりあえず1本」接続を作っただけで、DB側には数千の接続リクエストが殺到します。

従来のPostgreSQLやMySQLはプロセスモデルのオーバーヘッドが大きく、数千の同時接続をさばくようには設計されていません。結果、「アプリは元気だし、なんならDBも余力があるのにコネクションが先にパンクして死ぬ」 という悲劇が起きます。
そこで、Cloud SQL Auth ProxyやRDS Proxyを使ってFaaS/CaaSからのリクエストはProxyを経由することで、コネクションプールをコンピュートから切り離し上記のコネクション不足の問題を解決するのが一般的です。

 Oracleの回答：DRCP (データベース常駐接続プーリング)この問題に関して、ADBというかOracleは実は以前より回答を作っていました。それがDRCP (Database Resident Connection Pooling)です。これは 「コネクションプールをDB側に移す機能」 です。
Proxy方式も悪くはないのですが、若干のレイテンシーの問題が出たりしますし、余計なサイドカーを立てる必要もあります。OracleのDRCPは、外部Proxyではなく、DB自体の機能です。そのため、DBのメモリ空間内で直接セッションを管理するため、オーバーヘッドが少ないのが特徴です。


ref: Amazon RDS for Oracle を使用して Oracle データベース常駐接続プールを実装する
非常に多くの同時接続をさばけるようになるので、CloudRunやFunctionsから大量のコンテナを起動しても難なくさばけるはずです。これを圧倒的にシンプルな構成で組み立てられるのは、クラウドネイティブ時代にとてもマッチしそうですよね？

 Multilingual Engine (MLE)による強力なDB内エッジコンピューティングもうひとつ、面白そうと思っている機能が、Multilingual Engine (MLE) です。
これはいわゆる「ストアドプロシージャ」。でも、伝統的なPL/SQLを思い浮かべる人もいるでしょうし、貴重なDBのリソースを使う禁じ手、あるいはコード管理の悪夢を思い出すかもしれません。私は思い出します。
でも、ADBサーバレス + MLEなら少し違った見方が出来るかも？ とも考えています。MLEはGraalVMをベースにした実行基盤で、MLEでもJSを実行することが出来ます。つまり、謎のPL/SQLではなく、現代のJSを実行することが可能になります。


ref:PL/SQL vs. JavaScript in the Oracle Database 23c 
例えば以下はカラムのJSONを解析して複雑な不正検知のビジネスロジックでフィルタする例です。まあ、普通に読めますよね？
CREATE OR REPLACE FUNCTION calc_risk_score(p_details IN JSON) 
RETURN NUMBER
AS MLE LANGUAGE JAVASCRIPT
{
    const data = JSON.parse(p_details); 
    let score = 0;

    // ルール1: 未知のデバイスなら +30点
    if (data.device === 'unknown') score += 30;
    if (data.device === 'vpn')     score += 50;

    // ルール2: 国外IPなら +40点
    if (data.ip_country !== 'JP')  score += 40;

    // ルール3: 過去の行動履歴による加点
    if (data.history) {
        if (data.history.includes('login_fail'))      score += 20;
        if (data.history.includes('password_change')) score += 30;
    }

    return score;
}
/
使うときはこんな感じ。
SELECT 
    tx_id, 
    user_id, 
    amount
FROM 
    transactions
WHERE 
    -- 【重要】ここでJSが実行され、該当しないデータはネットワークに出ない
    calc_risk_score(details) >= 80;
とはいえ、Oracleが脱PL/SQLなストアドを作るのは今に始まった事ではなく、古くはOracle 8iのJavaストアドプロシージャ。JSも一時期、RhinoというJSエンジンで動かしていました。GraalVMのTruffleJSはモダンで確かに魅力的ですが、それだけだとあえて使う理由にはなりません。
でも、ここでクラウド/サーバレスという特徴が組み合わさると少し話は変わります。

そもそもストアドプロシージャのメリットの1つはデータローカリティです。通常はビジネスロジックはアプリケーションで持っているので、どうしてもNW通信のコストが乗ってしまいます。しかし、ストアドプロシージャであればデータのある場所で処理がされるため、大幅に性能を上げることが理論上可能になります。
こうした、考え方は普遍的なもので、Hadoop/HDFSのようなビッグデータ処理基盤、GoogleのBigQueryのようなMPPは、それを意識したアーキテクチャですし、AI関連ではより効率的な処理を目指してニアメモリコンピューティングが注目されてきましたよね？
MLEなら一部のnpmも使えますし、DBアクセスをして以下のように大きなカーソルを走査して、大量のデータを処理するようなロジックもふつうのJSとして書くことが可能です。
CREATE OR REPLACE PROCEDURE process_simple_loop
AS MLE LANGUAGE JAVASCRIPT
{
    const oracledb = require("mle-js-oracledb");
    const conn = oracledb.defaultConnection();
    const result = conn.execute(
        `SELECT id, amount FROM huge_sales_table`, 
        [], 
        { resultSet: true }
    );
    
    const rs = result.resultSet;

    try {
        for (const row of rs) {
            if (row.AMOUNT < 10000) continue;

            conn.execute(`INSERT INTO high_value_sales VALUES (:1, :2)`, 
                         [row.ID, row.AMOUNT]);
        }
    } finally {
        rs.close();
    }
}
/
そして、ADBサーバレスはコンピュートが並列化された分散DBですし、クラウドやサーバレスのオンデマンド、という特徴を考えれば 「高価なデータベースサーバ」のリソースを消費すると考えずに、「データの一番近くにあるアプリケーションランタイム」 とみなすことも可能です。このあたり、とてもわくわくしますね！
CI/CDを適切に組めばバージョン管理やデプロイの課題も解決することは可能な気がします。そうすればビジネスロジックを書いてしまう問題も闇ではなくなるかもです。
このあたりの、ADBサーバレスを 「データの一番近くにあるアプリケーションランタイム」 というのはありな気はするものの、結構考え方の転換で課題も多そうなので、別の機会に試してみたいと思います。
データローカリティのハマるアプリならシンプルで効率よく動くかも？ ちょっと試したいですね。

 最適化疲れの救世主？ コンバージドデータベースWeb開発の現場では、長らく「適材適所（Polyglot Persistence）」が良しとされてきました。

「リレーションはRDB、ドキュメントはMongoDB、検索はElasticsearch、キャッシュはRedis、ベクトルはPinecone...」

しかし、これらを全て繋ぎ合わせ、データの整合性を保ち、運用し続けることに 「疲れ」 を感じていませんか？ 個人的な経験でも「このユースケースでわざわざDBを分離して、ストリームで連携して整合性を気にする必要あるのかな？」という構成に出会う事もしばしばです。
Oracleの 「コンバージドデータベース (Converged Database)」 戦略は、この複雑さに対するアンチテーゼです。Oracle Databaseは、単なるRDBではありません。

JSON、グラフ、空間情報、そして最新のベクトルデータ（Vector）まで、あらゆるデータモデルを一つのエンジンで扱えます。


ref: https://japan.zdnet.com/article/35166494/
いわゆるOLTPとOLAPを統合した**HTAP（Hybrid Transactional/Analytical Processing）**をさらに拡張した考え方ということもできるかもしれませんね。
これはADBというより、Oracle Database自体の思想に近い話です。

ただ、運用が軽くてバックエンドがExadataというADBサーバレスだと、この全部入りの価値がより活きる気がしています。
特に、半構造/非構造データを扱いやすいJSONを扱えるドキュメントDB、SNSなどでも良く利用されるグラフDB、AIでも注目されているベクトルDBなどを１つのデータベースで扱えるのは運用のシンプルさとしてとても良いですね。
こうしたマルチモデルのDB連携は各社とも対応を進めています。AWSなどは「Zero-ETL」として複数種類のデータベースを透過的なETLで繋ぐことで統合を目指していますし、GoogleはSpannerをネイティブでグラフDBやベクトルDBに対応させたり、AlloyDBでRDBとベクトルDBを統合したりと、OracleのコンバージドDBと近い思想で進化しています。

Zero-ETLも良いですが、やはり単一のDBでデータ移動がないのはモニタリングや権限管理もシンプルになるはずですし、以下のように単一のSQLでRDB、JSON、ベクトルを扱えるのは面白いですよね。Spannerも似たような変態クエリ書けるようになりましたよね。
SELECT * FROM products p WHERE p.json_data.category = 'book' AND vector_distance(p.vec, :query_vec) < 0.5
このあたりも好みや、メリット/デメリットがあるので、一概にコンバージドDB的なアプローチが目的毎に最適化するアプローチより優れている、という話では全くないのですが、シンプルに始めるという点では意外にOracleがあってるケースもあるかもしれません。

 FAQ: リージョナルで動かない？ それは誤解です
 異なるアクティブ/アクティブの考え方「OracleはExadataでもシングルゾーン（データセンター内）でしかRACを組めない。対してAuroraはマルチAZでActive-Activeだ」
マイグレーション案件でよく聞く話ですが、これは典型的な誤解です。
たしかに、RACは超低遅延ネットワーク（RoCE）を前提としているため、DCを跨いでクラスタを組むことは（技術的には可能でも）推奨されません。おそらくクラウド環境では組めないと思います。しかし、ここで重要なのは 「なにがActive-Activeなのか」 という点です。
Aurora / AlloyDBは一般的にリージョナルで冗長性が組める、と言われますが実際に書き込みが出来るDBは1つだけです。シングルゾーン、シングルノードでWriterとなるDBを構築し、マルチゾーンでリードレプリカを展開。障害時には別のゾーンのリードレプリカがWriterに昇格します。



ref: Amazon Aurora as an Alternative to Oracle RAC
一方で、ADBのバックエンドである Oracle RAC(Realtime Application Clusters)は、1つのゾーンで複数のノードを構築し、ノードを追加することで読み込みだけでは無く書き込みの性能と冗長性を向上させることが可能です。ノードが死んでも接続中のセッションが死ぬだけでシステム全体としての読み書きは無停止で継続されます。ゾーンレベルの障害に対策するためには、Autonomous Data Guardという機能を使ってレプリケーションをします。自動でスイッチオーバ―も可能で数秒から数分で切り替わります。


ref: Amazon Aurora as an Alternative to Oracle RAC
書き込みの地理的な分散という意味では、Aurora/AlloyDBもADBも基本は1ゾーンにWriterが寄ります。そのためアプリケーションをマルチゾーンに分散配置して書き込みはゾーン越えのレイテンシー影響がありますし、ゾーン障害に無停止対応は出来ずフェールオーバーが必要です。
しかし、RACは同一ゾーン内でMulti-Writerを成立させ、ノード障害に強く、書き込みも伸ばせるのが本質的な違いです。ただし、ゾーン冗長まで考えるとコストとのトレードオフが発生します。
このあたりは、そもそもケースバイケースで最適な冗長構成を提供する前提に設計されたExadataと、ノード障害もゾーン障害も同じ方法で担保する前提に設計されたAuroraやAlloyDBとの決定的に異なる点ですね。
また、Exadata自体はActive Data Guardといってまさにリードレプリカを作る機能があるのですが、これはADBサーバレスでは使えません。ただ、結局のところ読み込み性能を足したいだけならRACにノードを追加すれば十分なので、他ゾーンにレプリケーションしたDBをリードレプリカとして使えなくても、ゾーンレベルの低レイテンシ―読み込みを要求するシステム以外ではあまり気にしなくて良いでしょう。それもExadata自体の性能の良さでトントンになる可能性もあるので計測が大事ですね。
ここまでの話はOracle/OCIの設計思想と一般論として押さえた上で、現状の ODB@GCP の提供形態には制約があります。2025年12月現在ではOracle Database@Google Cloudはシングルゾーン構成しか作れません。
別に、ここまで書いたことは嘘では無いのですが、単純にマルチゾーンで展開されていません。リージョンに関しては大阪が一応ロードマップに載ってるので良いのですがゾーン(OCI用語でAvailability Domains)となると、現時点ではOCI本体も日本ではリージョン毎に1個なのでちと怪しいです。この点は注意が必要ですね。

 無停止パッチ当ての威力ADB、ひいてはOracle RACの魅力の１つが 「無停止でのパッチ適用」 です。

Aurora / AlloyDB: パッチ当ての際、Writerノードの再起動が必要です。フェイルオーバーでダウンタイムは最小化されますが、セッションは切断されます。

Oracle RAC: ノードを1台ずつ切り離してパッチを適用（ローリング適用）できます。全DBが落ちる瞬間は存在せず、リードもライトも常に稼働し続けます。
さらに、FAN (Fast Application Notification) や TAC (Transparent Application Continuity) といった機能を使えば、アプリ側でリトライ処理を書かなくても、DBドライバが勝手に再接続・再実行してくれます。ユーザーは「瞬断」にすら気づきません。
とはいえ、TACもあらゆる処理に適用できるわけではないので、注意は要りますが適切に運用すれば完全に無停止で運用できるのは大きな魅力ですね。AuroraもBlue/Greenなどの手法はありますが、構成的にこの無停止のやり方は出来ないはずなので。ここはアーキテクチャ的な堅牢さと言えるでしょう。
こうしたRAC構成がボタンぽちで特に意識する事なく作られるのが、ADBサーバレスの魅力的なところです。

 で、Spannerより速いの？ - RACのスケールアウト限界ここまでExadata速い！ とアピールしてきたので誰もが気になるであろう話題を１つ。つまり、Google最強のデータベースであるSpannerと比べて、Exadataの方が速いの？ ということです。
答えは、ワークロードによる、面白いくらいに性能特性が違うので、用途に合わせた選択をする必要があります。
ADBのバックエンドで使われているExadata、ひいてはRACはシェアードエブリシングという構成の限界として、シャーディングをベースとするSpannerのようなNewSQLに比べてスケールアウトの限界があります。最大 24,320 ECPU というとんでもない数まではスケールしますが、それ以上は厳しいです。一方でSpannerはドキュメントに明確な上限の記載がありませんが、Pokémon GOの数千ノード規模の運用などとんでもない数で動いている事例もあります。
また、コア数的には拡張できても、実際はNW帯域やストレージのIOPSの関係で十分な性能を引き出しきれないことも多いでしょう。特に、書き込みヘビーなアプリケーションでノードを増やし過ぎるとキャッシュフュージョンが多発して性能が思ったように伸びないのはRACの典型的なスケールのボトルネックです。
そのため、最大スループットという点で事実上の青天井と思われるSpannerに比べてADB/Exadataは及びません。またプラネットスケールに展開するとかも（一応機能はあるけど）あまり得意ではありません。
逆にレイテンシーであれば、Spannerは数msから十数msと十分に速いですが、Exadataのようにマイクロ秒の世界でクエリを返すわけではありません。この点は明確にExadataが優位です。
すなわち、傾向としては最大スループットならSpanner、レイテンシーならExadataと良い感じに棲み分けされるわけですね。
一方で、多くのサービスでプラネットスケールが必要かと言われると疑問がありますし、キャッシュフュージョンの問題がボトルネックになるほど書き込みを増やしかつ台数も増やしているケースに到達するのは簡単ではないでしょう。そうした問題が出るまでは、シャーディングではなくShared Everythingなので同じ分散DBであっても特別アプリケーションで考慮することが少ないのも魅力の1つです。改修コストが不要ですからね。フリーランチ食べれるなら食べたいですよね？
損益分岐点はあると思いますが、ADBやExascaleでコスパが悪くなってはじめて、NewSQLのようなより高度な分散DBにアプリケーションの改修を含めてチャレンジするのも選択肢かとは思います。
このあたりのExadataが得意なところは、Spanner/DSQLというよりも、Aurora/AlloyDBの強化で戦っていくことになるんでしょうね。

 FAQ: 構築や運用はDBAやコンサル契約が必要？ いいえ、あなたがボタンを押すだけですOracle Databaseを運用するならば高度な資格を持った社員を雇ったり、コンサルと契約する必要があると思っていませんか？ それが必要な現場もあるかもしれませんが、少なくともMySQLやPostgreSQLの専門家を雇う想定が無いレベルの運用なら同様に不要でしょう。
Oracle Databaseといえども、管理コンソールやダッシュボードが整備されるので普通にDBを構築するだけならゴリゴリsqlplusで設定する、みたいなことは不要です。基本的には画面をポチポチしたりTerraformを実行すれば作れます。

ADBサーバレスはDBaaSとして、管理コンソールからポチポチするだけで簡単に構築できるため、そこまで特殊なスキルは不要です。前述した通り、多くのチューニングやパッチ当てのようなメンテナンスも自動で行われます。
細かく管理することが出来るだけで、細かく管理しないと破綻するシステムではないので、そこは怖がらなくて大丈夫なところなんです。

 Oracleエンジニアは採用困難？ PostgreSQLなら簡単？ という幻想他にもよく聞くのが
「Oracleは専門家が少ないから採用が大変」
という話もありますね。本当にそうでしょうか？
たしかに、面接で 「PostgreSQL使えます（アプリ開発で触ったことあります）」 という人を見つけるのは簡単です。でも、「内部構造や実行計画まで追って、データ破損や謎の性能劣化トラブルにちゃんと向き合える人」 となると、PostgreSQLだろうがMySQLだろうが一気にレアキャラ化します。ここはOSSかどうかに関係なく、どのDBでも同じです。
OracleとPostgreSQLで、NULLの扱いなどプログラマが気にすべき方言の違いはたしかにありますが、これはググれば済むレベルの話。それよりも、きちんと設計できて、いざという時に腰を据えて調査できる人がいるかどうかの方がよほど重要です。
この点でOracleには、「Oracle Master」などの認定資格でスキルの目安を持ちやすい というメリットがあります。もちろんペーパー合格もゼロではないですが、Gold / Platinum クラスなら一定以上の知識は期待しやすいですし、SIerやベンダーにそういう人材がそれなりにいます。最悪、「お金でプロを呼ぶ」という選択肢が現実的に取れるのはビジネス的には大きいです。

Oracleはそこまでマイナーなデータベースではありません。個人的にはTiDBとかYugabyteとかのMySQL/PostgreSQL互換のDBのエンジニア探すよりは簡単な気がしています。
なので、「周りにOracle経験者が少ない＝採用的に詰む」 と過度に心配する必要はあまりありません。

結局のところ、本当に優秀なDBエンジニアの採用は、どのDBを選んでもだいたい等しく修羅の道 なんですよね＞＜

 まとめ用途次第では大きく変わりますが、AuroraやAlloyDBと比較してもExadataの性能やRACの堅牢性、そしてAutonomousによる運用負荷の低減がこの値段で使えるなら十分比較の土俵に上がるので、万人向けではありませんが、ちょっと気にはなりますよね？ 意外にWeb系にもイケちゃう部分があるんです。
適切なアプリケーションであれば、性能も信頼性もハードで殴る必要は無いのですが、現実的なお値段だしトレードオフを分かって使うならそれもありかなー、と。アプリがシンプルになるのは良いことですし。
個人的にはこの辺でADBの利用例が増えて世の中の知見が増えるのも楽しみだし、刺激されたクラウドベンダー達が自分たちがOSSのDBをさらに魔改造してもっともっとマネージドDBを強化してくるのも楽しみなので、是非ともWeb系エンジニアこそADBサーバレスやODB@マルチクラウドを気軽に試してみてほしいです。
なお、OracleはエンタープライズにNotForYouな機能を宣伝し続けるより、自分たちの機能を欲しい人にちゃんとアピールしようよ、と心の底から思いますｗ
ちなみに、この記事は Oracle様から一銭ももらっていないどころか、本業ではしばしば Oracle のライセンス見積もりに震えている人間が書いています。Oracle 関係者の皆さま、もし「パンフ全盛りでよろしい！」と思ったら、次の見積もりを少し優しくするか、Zenn の投げ銭で手を打ちましょうｗ それだけが私の願いです。。。
それではHappy Hacking！
公式が教えてくれない！ Oracle Database@GCPがWeb系エンジニアにもちょっと面白そう？

はじめに

TL;DR

まずはコスト感の話 - 「Oracle＝高い」はもう古い？

フェラーリをタクシー料金で乗る

少しだけリアルに比較してみる(vs Aurora / AlloyDB)

隠れたコスト - 人的リソースの削減効果

Oracle Database@Google Cloudとは？

Oracleのマルチクラウド戦略

ADB Serverlessとは？

Exadata - Oracle流、僕の考えた最強のでーたべーす！

「チューニング疲れ」からの解放：勝手に速くなるDB

単純に速いレイテンシー

SmartScan、フルスキャンを速くする！

AIによる自律運転 - 24時間365日働くAI DBA

クイックハンズオン：サクッとADB Serverless を立ち上げてみる

ADBの構築

ADBへの接続

Terraform

ADBでつかってみたい機能たち

グッバイ、SQL Proxy

なぜコネクションプールが必要なのか？

FaaSでプールが効かない理由

Oracleの回答：DRCP (データベース常駐接続プーリング)

Multilingual Engine (MLE)による強力なDB内エッジコンピューティング

最適化疲れの救世主？コンバージドデータベース

FAQ: リージョナルで動かない？それは誤解です

異なるアクティブ/アクティブの考え方

無停止パッチ当ての威力

で、Spannerより速いの？ - RACのスケールアウト限界

FAQ: 構築や運用はDBAやコンサル契約が必要？いいえ、あなたがボタンを押すだけです

Oracleエンジニアは採用困難？ PostgreSQLなら簡単？という幻想

まとめ

Discussion

タスク	Amazon Aurora / AlloyDB (Managed)	Oracle Autonomous Database (Autonomous)	Human Costへの影響
インデックス設計	手動/支援型: スロークエリログを分析し、DBAがインデックスを作成。AlloyDB の Index Advisor は「推奨」のみで適用は人間が行う。	全自動: 機械学習がワークロードを常時監視し、インデックスの作成・削除・再構築を自動実行。性能向上を確認してから適用する。	大: 高度なスキルを持つ DBA のチューニング時間をほぼゼロにする。
パッチ適用	手動/スケジュール: メンテナンスウィンドウの設定が必要。ダウンタイムやフェイルオーバーが発生する場合がある。	全自動・無停止: RAC のローリング適用により、アプリ稼働中に透過的にパッチが適用される。ユーザーは意識すらしない。	中: 深夜メンテナンスや調整業務からの解放。
パフォーマンス・チューニング	手動: バキューム設定（Postgres）、メモリパラメータ、並列度の調整など、専門知識が必要。	全自動: メモリ配分、並列度、オプティマイザ統計を自己調整。	大: 性能トラブルシューティング工数の削減。
セキュリティ構成	必要: 暗号化設定、監査ログ設定などをユーザーが行う責任がある。	Always-On: デフォルトで常時暗号化。セキュリティパッチも自動適用。設定ミスによるリスクを排除。	中: セキュリティ監査対応コストの削減。
はじめに

TL;DR

まずはコスト感の話 - 「Oracle＝高い」はもう古い？

フェラーリをタクシー料金で乗る

少しだけリアルに比較してみる(vs Aurora / AlloyDB)

隠れたコスト - 人的リソースの削減効果

Oracle Database@Google Cloudとは？

Oracleのマルチクラウド戦略

ADB Serverlessとは？

Exadata - Oracle流、僕の考えた最強のでーたべーす！

「チューニング疲れ」からの解放：勝手に速くなるDB

単純に速いレイテンシー

SmartScan、フルスキャンを速くする！

AIによる自律運転 - 24時間365日働くAI DBA

クイックハンズオン：サクッとADB Serverless を立ち上げてみる

ADBの構築

ADBへの接続

Terraform

ADBでつかってみたい機能たち

グッバイ、SQL Proxy

なぜコネクションプールが必要なのか？

FaaSでプールが効かない理由

Oracleの回答：DRCP (データベース常駐接続プーリング)

Multilingual Engine (MLE)による強力なDB内エッジコンピューティング

最適化疲れの救世主？ コンバージドデータベース

FAQ: リージョナルで動かない？ それは誤解です

異なるアクティブ/アクティブの考え方

無停止パッチ当ての威力

で、Spannerより速いの？ - RACのスケールアウト限界

FAQ: 構築や運用はDBAやコンサル契約が必要？ いいえ、あなたがボタンを押すだけです

Oracleエンジニアは採用困難？ PostgreSQLなら簡単？ という幻想

まとめ

Discussion

最適化疲れの救世主？コンバージドデータベース

FAQ: リージョナルで動かない？それは誤解です

FAQ: 構築や運用はDBAやコンサル契約が必要？いいえ、あなたがボタンを押すだけです

Oracleエンジニアは採用困難？ PostgreSQLなら簡単？という幻想
