本記事は JPOUG Advent Calendar 2024 の12日目の記事となります。
JPOUG Advent Calender、11日目の記事は wmo6hash さんの記事「私的Oracle Database Release and Support Timelines集」でした。
はじめに
Autonomous Database（以下ADB）はOCIで使用可能な自律型データベースです。
いままでDBAが行ってきた様々な管理・処理が自律的に行われます。
しかしながら実際にデータベースをアプリケーションで使用することを考えた時、今まで通りのSQLでデータ操作を行っていけます。
と、思っていましたが、ADBを使うためにexpdp/impdpでデータ移行をしてみたところ、細かいところ細かいところで躓きがありました。
そのように実際に使ってみて気づいたちょっとした違いを見ていきたいと思います。
特に自分でADBを作った人は作る途中で気づけることもありますが、他の人が作ったADBを渡されて、普通のOracleのように使えるよ！と言われた状態ですと、戸惑うところも多い気がします。
＜ 扱う話題 ＞
・クライアントのtnsnames.oraに記述する接続識別子に関する情報はどうやって入手する？
・SYSTEMユーザがいない？最初にどのユーザで接続すればいいのだろう？
・事前定義済みロール「DBA」が使えない？代わりはあるのか？
・表領域が作れない？どうするんだ？
・データインポートしたらUNDO不足。BaseDBでは正しくインポートできたのに？
1. Autonomousに接続する接続識別子は？
Autonomous Database(以降ADB)の作成ができたら、まずはSQL*Plusで接続したいですね。その時の手法をみていきましょう。
データベースアクション（ブラウザインタフェース）
ADBでSQLを実行するときに、まず簡単な方法としてブラウザインタフェースがあります。それを使えばすぐにでもSQLを実行できます。OCIコンソールからアクセス可能です。
1.「データベース・アクション」から「SQL」を選択
- こんな画面でSQLが実行できます。
SQL*Plusから接続
またSQL*Plusを使いたい人も多くいると思います。
その時は接続識別子が必要ですね。
オンプレであればホスト名、リスナーのポート番号、データベースのサービス名が必要でした。
ADBでは少し異なります。
方法が2種類あり「Wallet (mTLS)を使用したSQLPlusの接続」か、「Walletを使用しないSQLPlusの接続」です。後者であれば今までのように接続識別子を教えてもらってtnsnames.oraファイルに記述すればアクセス可能です。
Walletが必要な場合、walletの入手とsqlnet.oraへの記述が必要です。
https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/connect-tools.html
どちらを使用すべきかはADB側の設定によります。
ADB管理者に確認してみましょう。
2. SYSTEMユーザがいない？最初にどのユーザで接続すればいいのだろう？
Oracleをよく知るみなさんは、オンプレでデータベース作成後にまずはSYS
SYSやSYSTEMユーザで接続して、作業をすることと思います。
しかし、接続しようとしてもSYSTEMユーザはLOCKされています。
ADBでは「ADMIN」ユーザがデータベースの管理者になります。ADMINを使用しましょう。パスワードはADB作成時に指定しています。
3. 事前定義済みロール「DBA」がない？代わりはあるのか？
ADMINユーザで接続し、新しい管理用DBユーザを作成したいと思いました。
しかし、いつも使っているDBAロールが存在しないようで以下のSQLがエラーになります。
GRANT DBA TO dbuser1;
ADBではDBAロールが使用できません。存在はしますが、使用はできないイメージです。近しいロールとして「PDB_DBA」があります。
ただ含まれる権限が異なりますので、必要な権限があるかみてみてください。
主観ですが、ADBのADMINユーザはSYSやSYSTEMの代わりではなく、業務用DBユーザの管理ができるユーザという位置づけと思います。
次の話題にもつながりますが、表領域は作成できないし、存在はするはずDBAロールも使用できません。ADBということで、管理はADB任せで、業務用DBユーザおよびオブジェクトの管理をするユーザと考えています。
4. 表領域が作れない？どうするんだ？
データ格納用に表領域を作ろうとしましたが、以下のSQLがエラーになります。なぜでしょうか。
ADBでは表領域を作ることができません。
デフォルトで「DATA表領域」が作成されており、ユーザが作成するセグメントはDATA表領域に格納されていきます。
データ領域管理もすべてADBにお任せということですね。
いままで1ファイルの上限 32Gに達したらデータファイルを増やしたり、用途ごとに表領域を分けたりしていた方も多いと思いますが、そういったデータ管理も自律型のADBにお任せしちゃいましょう。
5. データインポートしたらUNDO不足。BaseDBでは正しくインポートできたのになぜ。
前述の通り、表領域はADBによる自動管理になります。
UNDO表領域も同様です。
ADBのUNDO表領域は、ADBストレージ全体の5%と決まっています。
ストレージが1TBの場合、50GBとなります。
※個人的にはここは改善してほしい
インポートや大量のUNDOが生成される処理を行うと、一時的に50GB使ってしまうことがあると思います。しかし、この割合は変更できないため、50GBをこえるとUNDO表領域が足りずにエラーとなります。
ストレージを増やすしかありません。
BaseDBや他のクラウドベンダーとは異なり、ADBはストレージを「縮小」できるため、一時的に増やして不要になったら減らすことはできますが、ここは自動で何とかして欲しいと思います。
おわりに
データ移行をはじめてやってみた、を観点にADBでの躓きをみてきました。
データ操作のSQLという意味では、今まで通り使用できますが、基盤としては多少管理が異なることがありますね。
他にも色々ありますので、またの機会に異なる観点で見ていけたらと思います。