Autonomous Database (ADB)はどこまで使えるか [アーキテクチャ]
１．はじめに
私の周りでは更改前のオンプレの運用中のトラブルの話がまだ多く、クラウドを実感することはさほど多くない。しかし、レビュー等でAWS RDSを使う案件の増加を実感するところでもある。私も遅ればせながら、今年春から実際にADBやOCIを触り始めている。今のところ私がやったのは、以下のリンクから、Autonomouse databaseとOCI architectの動画を一通り見て、実際にOCIを使ってみて学習した。３～４か月程度の学習の結果、Autonomous databaseやOCI architect associateまでは取得できた。残念ながらarchitect professionalは不合格だったが、これは２年の実務経験と謳っているだけに妥当なところかもしれない。
Oracle Ramps Up Free Online Learning and Certifications for Oracle Cloud Infrastructure and Oracle Autonomous Database
実際ADBやOCIを触ってみて、その使い方を学ぶことはたいして難しくないことはよくわかる。例えば、DBの構築はDBのタイプ、CPU数や領域サイズ等を指定すれば、数クリックでインスタンスが上がってしまう。バックアップは自動で取得されており、リストアはリカバリポイントを選択してクリックするのみ。時代は確実に現場のDBAの定型作業をコモディティ化する方向に進んでいると感じる。逆に定型作業に落ちない部分、例えばクラウドへの移行や、サービスの制約とオンプレのギャップを埋める作業、性能チューニング、障害の切り分けなどは、難しくなるかもしれないと感じている。その意味でも、やはりクラウドサービスの理解とその制約を正しく理解することは、避けることができないと感じている。
２．ADBで運用上気になること
Autonomous Database (ADB)で気になったのは、オンプレ運用に慣れた感覚からすると制約があることである。特にOSへのアクセスが制限されていることは思いのほか不便で、例えばディレクトリオブジェクト経由で入出力するファイルをOSから直接アクセスできない。DBMS_CLOUDパッケージでデータロードしたときのエラーログファイルも、OSから直接アクセスする方法がないため、DBMS_CLOUDパッケージを使って、都度オブジェクトストレージを介してファイルをやりとりする必要がある。実際運用で使った経験がないのであくまで想像でしかないが、DBAとしては結構面倒なのではないかと思う。AWSのRDSも同様のコンセプトであるので、これに関していえばOracleが、というよりクラウドPaaSの共通の課題かもしれない。
また、DBの障害解析でalert.logや各種トレースファイルを見たい場合にどうすればよいのかという点も気になる。フルマネージドなクラウドサービスとはいえ、単純なハード障害でなければ、オンプレと同じように問題の切り分けを行うためにログを見なければならない状況になり得るだろう。検知はOEMでできるとして、いままでのようにユーザ側で生ログ見てMOSで調べて切り分けることは難しくなるかもしれない。ユーザはよりアプリケーションに近い問題（AWRやASHを使ったSQL性能改善やORA-1555など）に注力し、ORA-600などのトラシューは隠蔽され、定期パッチ適用でいつのまにか自然に修正されているという世界が一般的になっていくのかもしれない。いずれにしても、ログ一式をまとめてSRへ送付する必要がなくなるのは本当にありがたい。
３．もし今のシステムでADBを使うことになったら
今回勉強を通して分かったことをベースに、実際どこまでこのサービスが使えるのか、今現在自分の関わっているシステムで考察してみよう。本システムはExadata上に3つの異なるDBを構成（OLTP用、バッチ用、DWH用）し、規模はそれぞれ数TB程度、バックアップはRMANでZFSへ、監視はOEMを用いている。これをADBに移行するとした場合の構成、課題を考えてみたい。
◇ATPかADWか
初めの選択は、それぞれのDBをATP、ADWどちらへ移行するか、という点である。ATPはOLTP用、ADWはDWH用なので、オンライン、バッチメインのDBはATPで問題ないだろう。しかしDWHは単純にADWを選択すればよい、ということではない。ADWはカラムストア、デフォルトでEHCC（圧縮）が有効、デフォルトでHINTは効かない、といった違いがあることから、移行する上ではどのような動きになるのか予想が難しい。APになるべく手を入れず現行の動きを踏襲したいなら、ATPを選択すべきだろう。ADWを選択するなら、SQLのチューニングやアーキテクチャ（利用しているミドルの設定）を見直す覚悟が必要だろう。
◇sharedかdedicatedか
続いての選択は、sharedがdedicatedかである。言うまでもなくsharedは複数のユーザ（テナント）でDBサーバを共有するため、必然的に運用に制約が生じる。例えば、四半期に一度のパッチ適用のタイミングは今のところsharedではカスタマイズできない。実際、私のADWの環境では、Next Maintenance: Sat, Sep 5, 2020, 09:00:00 UTC -13:00:00 UTC（日本時間なら18時～24時）というように、次回のメンテナンスのタイミングが示されている（通常この4時間全部がメンテナンスにかかる訳ではなく、実際は2時間以下らしい）。実際のシステム運用では、データベース毎に停止調整可能な日や時間帯が決まっているので、そのタイミングを狙って計画する。オンラインでメンテナンスされるとはいえ、sharedの選択はなく、やはりdedicated一択であろう。
◇CPUのサイジング
CPUサイジングは、オンプレExadataのコア数をベースに必要なOCPUを算出するが、メモリがOCPUベースで決まってしまうので、両方満たすようなシェイプにする必要がある。現在ADBのハードとして選択可能なExadataX8-2 halfのスペックを見ると、CPUは200コア、メモリは2,880GBメモリ/4ノード（50コア、720GBメモリ/ノード）であり、現在オンプレで動いているOracleではなかなか使い切れない程の高スペックである。なお、フラッシュキャッシュがRAWで179.2TBということは、3冗長（WriteBack)でおおむね論理50TB以上使えることになるので、数TBレベルのDBはすべてフラッシュキャッシュに乗ってしまう。現在、バッチ処理等でシングルブロックリードの待機でI/Oネックとなっていた処理は、I/Oレイテンシの向上により性能向上の恩恵を受けられるはずである。
A Characteristics of Infrastructure Shapes
◇接続性
本システムはオンラインはAPサーバからはJDBC接続、バッチサーバやBIツールからはOracle*Netの接続がある。移行に際し、ADBの接続に必要な資格証明ファイルをクライアントに配置し適切な設定をする必要がある。実際に資格証明をダウンロードするとWallet_（DB名）.zipというファイルが得られるが、この中には以下のファイルが含まれる。Oracleクライアントからの接続は、?/network/admin配下にcwallet.ssoを配置し、既存のtnsnames.oraの接続情報を下記tnsnames.oraの内容に書き換え、sqlnet.oraにWALLET_LOCATIONを追加すればADBに接続できるようになる。JDBCでは"jdbc:oracle:thin:@接続識別子?TNS_ADMIN=XXX"のように、TNS_ADMINでウォレットの格納場所をデフォルトから変更すれば良いようだ。
tnsnames.oraには以下のようにhigh、low、mediumの３種類のサービスに接続できるよう、接続識別子が用意されている（以下はADWの例。ATPではこれに加え、tpurgentとtpが追加される）。既存の接続識別子を踏襲し、接続内容だけ下記に書き換えれば、既存クライアント資材への影響を少なくDB接続先をADBに変更できる。
移行の際には接続毎にどれを使うかを考えなければならない。上記それぞれのサービスの違いは以下マニュアルに記載されている。OLTP系の接続は同時実行性が求められるため、一律tpurgentで良いだろう。バッチ系APはtpでも良さそうだが、paralellismが使えないので、やはりtpurgentしかない。そもそもリソースマネージャに依存せずに設計されたシステムでは、一律tpurgentでの接続と割り切っても良いのではないか。なお、もしADWを使う場合は少し注意が必要である。ADWのhighはparallelismはCPU_COUNTまでであるが、Concurrent Statements（同時実行できるSQL数）が3に限定されている。DWH系アプリケーションの夜間バッチは多重実行されるため、ここはmediumを選択し、parallelismは4に制限されるが、Concurrent Statementsがparallelismが1.25 × CPU_COUNTとなるのが良いだろう。
Predefined Database Service Names for Autonomous Transaction Processing
Predefined Database Service Names for Autonomous Data Warehouse Dedicated Databases
◇バックアップ
ADBのバックアップは、保持期間60日、PITRでいつでも任意のタイミングにリカバリできる。しかし、sharedではバックアップのタイミングや保持期間がカスタマイズできない。例えば私のADWの環境ではUTCで12時頃（JSTで21時頃）にインクリメンタルバックアップが取得されているが、今のシステムでは、この時間は月次の重要バッチと重なってしまう。この点、dedicatedならバックアップタイミングがカスタマイズが可能、かつ、保持期間も7、15、30、60日から選択できるようになる。また、マニュアルバックアップを取得できるので、特定のリリースのタイミング等でのバックアップに利用できる。実運用上は主要なバッチと重ならないように制御することを考えると、オブジェクトストレージへのバックアップ性能を見極め、現在のバックアップウィンドウに収まるかを見切る必要がある。このあたりは実際に性能を検証して確認する必要があるだろう。
一点気になるのは、開発期間中のバックアップ・リカバリである。例えば性能試験では、特定のDBのデータ断面バックアップしておき、試験後にその断面をリストアする。試験を同じデータの条件で実行するために、何度も同じ断面にリストア（フラッシュバックDB）する。夜間にシナリオを流せるよう、リストアもジョブに組み込み自動化する。このような使い方をするには、マニュアルバックアップとフラッシュバックDBを組み合わせればできそうな気はするが、フラッシュバックの保持期間が24時間では土日かけて流すシナリオに耐えられないとか、自動化のために外部インタフェースからフラッシュバックDBを起動する仕組みづくりを考えないといけないといった解決すべき課題はいくつか出てきそうである。複数断面を任意のタイミングにリカバリすることの難しさを経験した方なら、これがクラウドで簡単に実現できる日を待っているに違いない。
◇監視
現時点ではATP dedicatedのみだが、OCIマーケットプレイスのOEMが使えるので、これで一通りの監視が可能と思われる。alert.logでORA-エラーが発生したことの検知や、メモリや領域等のリソース（閾値）監視は基本的に用意されたテンプレートを利用して作りこめばよいだろう。拡張メトリックで作りこんだ部分のカスタマイズがどの程度許されるのか、あたりが若干懸念としてある。また、OEMで検知したメッセージをJP1/IMの統合監視に連携する必要があるので、この実現方式は要検討である。
Administrator's Guide for Oracle Autonomous Databases
◇その他懸念点
まず気になった点はDBのキャラクタセットである。本システムのDBのキャラクタセットはSJIS（外字あり）なので、ADBへの移行に際しても同じキャラクタセットが好ましい。sharedはAL32UTF8となってしまうのでこの意味も採用は難しい。sharedの場合、CDBを共有しPDBをテナントとして提供しているはずで、この場合、CDBとPDBの文字コードは合わせておきたいのは理解できる。その意味でdedicatedだとカスタマイズできるのではないかと期待したが、現時点では難しいようだ。これはかなり厳しい制約で、文字コード変換を伴う移行は難易度が格段に上がることを考えると、今後の対応に期待したい。
Developer’s Guide to Oracle Autonomous Transaction Processing on Dedicated Exadata Infrastructure
次に気になった点はDBLINKである。本システムでは、異なるDB間でDBLINKを使って表への参照・更新を行っている。ADB間のDBLINKの作成は可能なので、この点は問題なさそうである（tnsnames.oraが使えないので、create database linkで指定するのは接続識別子ではなく、Easy Connectの書式で指定する）。ただ、現状PL/SQLプロシージャでDBLINKの使用はできないという制約がある。本システムではPro*CやMVIEWのほか、PL/SQLでもDBLINKを使用しているため、この制約はかなり厳しい。今後の対応に期待したい。
４．まとめ
ADBについて最近学んだことをベースに、現在私の関わっているシステムへADBはどの程度使えるのかを考察してみたが、やはり今の運用を変えずに移行するのは難しいと感じた。クラウドサービスをベースに運用を見直す前提で考え直す必要があるので、まずそこのハードルをクリアできるかがポイントと感じる。私の感覚として、変わらないことを是とする企業風土の中では、このハードルは決して低いものではない。この他、文字コードやDBLINKに関しては、現時点では厳しい制約がある点もあることがわかった。このような技術的な問題については、クラウドサービスの拡充に伴い解消していくのではという期待もあるので、今後も継続して注視していきたいと思う。なお、本記事内容は現時点で私が知ったことをベースに記載しているため、正確でない部分があるかもしれない旨、ご容赦頂きたい。
以上
私の周りでは更改前のオンプレの運用中のトラブルの話がまだ多く、クラウドを実感することはさほど多くない。しかし、レビュー等でAWS RDSを使う案件の増加を実感するところでもある。私も遅ればせながら、今年春から実際にADBやOCIを触り始めている。今のところ私がやったのは、以下のリンクから、Autonomouse databaseとOCI architectの動画を一通り見て、実際にOCIを使ってみて学習した。３～４か月程度の学習の結果、Autonomous databaseやOCI architect associateまでは取得できた。残念ながらarchitect professionalは不合格だったが、これは２年の実務経験と謳っているだけに妥当なところかもしれない。
Oracle Ramps Up Free Online Learning and Certifications for Oracle Cloud Infrastructure and Oracle Autonomous Database
実際ADBやOCIを触ってみて、その使い方を学ぶことはたいして難しくないことはよくわかる。例えば、DBの構築はDBのタイプ、CPU数や領域サイズ等を指定すれば、数クリックでインスタンスが上がってしまう。バックアップは自動で取得されており、リストアはリカバリポイントを選択してクリックするのみ。時代は確実に現場のDBAの定型作業をコモディティ化する方向に進んでいると感じる。逆に定型作業に落ちない部分、例えばクラウドへの移行や、サービスの制約とオンプレのギャップを埋める作業、性能チューニング、障害の切り分けなどは、難しくなるかもしれないと感じている。その意味でも、やはりクラウドサービスの理解とその制約を正しく理解することは、避けることができないと感じている。
２．ADBで運用上気になること
Autonomous Database (ADB)で気になったのは、オンプレ運用に慣れた感覚からすると制約があることである。特にOSへのアクセスが制限されていることは思いのほか不便で、例えばディレクトリオブジェクト経由で入出力するファイルをOSから直接アクセスできない。DBMS_CLOUDパッケージでデータロードしたときのエラーログファイルも、OSから直接アクセスする方法がないため、DBMS_CLOUDパッケージを使って、都度オブジェクトストレージを介してファイルをやりとりする必要がある。実際運用で使った経験がないのであくまで想像でしかないが、DBAとしては結構面倒なのではないかと思う。AWSのRDSも同様のコンセプトであるので、これに関していえばOracleが、というよりクラウドPaaSの共通の課題かもしれない。
また、DBの障害解析でalert.logや各種トレースファイルを見たい場合にどうすればよいのかという点も気になる。フルマネージドなクラウドサービスとはいえ、単純なハード障害でなければ、オンプレと同じように問題の切り分けを行うためにログを見なければならない状況になり得るだろう。検知はOEMでできるとして、いままでのようにユーザ側で生ログ見てMOSで調べて切り分けることは難しくなるかもしれない。ユーザはよりアプリケーションに近い問題（AWRやASHを使ったSQL性能改善やORA-1555など）に注力し、ORA-600などのトラシューは隠蔽され、定期パッチ適用でいつのまにか自然に修正されているという世界が一般的になっていくのかもしれない。いずれにしても、ログ一式をまとめてSRへ送付する必要がなくなるのは本当にありがたい。
３．もし今のシステムでADBを使うことになったら
今回勉強を通して分かったことをベースに、実際どこまでこのサービスが使えるのか、今現在自分の関わっているシステムで考察してみよう。本システムはExadata上に3つの異なるDBを構成（OLTP用、バッチ用、DWH用）し、規模はそれぞれ数TB程度、バックアップはRMANでZFSへ、監視はOEMを用いている。これをADBに移行するとした場合の構成、課題を考えてみたい。
◇ATPかADWか
初めの選択は、それぞれのDBをATP、ADWどちらへ移行するか、という点である。ATPはOLTP用、ADWはDWH用なので、オンライン、バッチメインのDBはATPで問題ないだろう。しかしDWHは単純にADWを選択すればよい、ということではない。ADWはカラムストア、デフォルトでEHCC（圧縮）が有効、デフォルトでHINTは効かない、といった違いがあることから、移行する上ではどのような動きになるのか予想が難しい。APになるべく手を入れず現行の動きを踏襲したいなら、ATPを選択すべきだろう。ADWを選択するなら、SQLのチューニングやアーキテクチャ（利用しているミドルの設定）を見直す覚悟が必要だろう。
◇sharedかdedicatedか
続いての選択は、sharedがdedicatedかである。言うまでもなくsharedは複数のユーザ（テナント）でDBサーバを共有するため、必然的に運用に制約が生じる。例えば、四半期に一度のパッチ適用のタイミングは今のところsharedではカスタマイズできない。実際、私のADWの環境では、Next Maintenance: Sat, Sep 5, 2020, 09:00:00 UTC -13:00:00 UTC（日本時間なら18時～24時）というように、次回のメンテナンスのタイミングが示されている（通常この4時間全部がメンテナンスにかかる訳ではなく、実際は2時間以下らしい）。実際のシステム運用では、データベース毎に停止調整可能な日や時間帯が決まっているので、そのタイミングを狙って計画する。オンラインでメンテナンスされるとはいえ、sharedの選択はなく、やはりdedicated一択であろう。
◇CPUのサイジング
CPUサイジングは、オンプレExadataのコア数をベースに必要なOCPUを算出するが、メモリがOCPUベースで決まってしまうので、両方満たすようなシェイプにする必要がある。現在ADBのハードとして選択可能なExadataX8-2 halfのスペックを見ると、CPUは200コア、メモリは2,880GBメモリ/4ノード（50コア、720GBメモリ/ノード）であり、現在オンプレで動いているOracleではなかなか使い切れない程の高スペックである。なお、フラッシュキャッシュがRAWで179.2TBということは、3冗長（WriteBack)でおおむね論理50TB以上使えることになるので、数TBレベルのDBはすべてフラッシュキャッシュに乗ってしまう。現在、バッチ処理等でシングルブロックリードの待機でI/Oネックとなっていた処理は、I/Oレイテンシの向上により性能向上の恩恵を受けられるはずである。
A Characteristics of Infrastructure Shapes
Specification:Exadata X8-2 Half Rack
Shape Name:Exadata.Half3.200
Number of Compute Nodes:4
・Total Maximum Number of Enabled CPU Cores:200
・Total RAM Capacity:2880 GB
◇接続性
本システムはオンラインはAPサーバからはJDBC接続、バッチサーバやBIツールからはOracle*Netの接続がある。移行に際し、ADBの接続に必要な資格証明ファイルをクライアントに配置し適切な設定をする必要がある。実際に資格証明をダウンロードするとWallet_（DB名）.zipというファイルが得られるが、この中には以下のファイルが含まれる。Oracleクライアントからの接続は、?/network/admin配下にcwallet.ssoを配置し、既存のtnsnames.oraの接続情報を下記tnsnames.oraの内容に書き換え、sqlnet.oraにWALLET_LOCATIONを追加すればADBに接続できるようになる。JDBCでは"jdbc:oracle:thin:@接続識別子?TNS_ADMIN=XXX"のように、TNS_ADMINでウォレットの格納場所をデフォルトから変更すれば良いようだ。
- README ・・・この資格証明のダウンロード日時と有効期限（5年）が記載されいている
- cwallet.sso ・・・パスワード不要で自動ログイン可能とするためのウォレット
- ewallet.p12 ・・・パスワードが必要なPKCS#12ウォレット
- tnsnames.ora ・・・接続先ADBの接続識別子情報。サービス（high, medium, low等）に応じてエントリがそれぞれ用意されている
- sqlnet.ora ・・・WALLET_LOCATIONのDIRECTORYに資格証明の格納場所ディレクトリを指定する
- ojdbc.properties ・・・wallet_locationDIRECTORYに資格証明の格納場所ディレクトリを指定する
- keystore.jks、truststore.jks ・・・JKSを使う場合に必要なファイル
tnsnames.oraには以下のようにhigh、low、mediumの３種類のサービスに接続できるよう、接続識別子が用意されている（以下はADWの例。ATPではこれに加え、tpurgentとtpが追加される）。既存の接続識別子を踏襲し、接続内容だけ下記に書き換えれば、既存クライアント資材への影響を少なくDB接続先をADBに変更できる。
orcl_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=xxx.ap-tokyo-1.oraclecloud.com))(connect_data=(service_name=xxxxxxxxxxxxxxx_orcl_high.adwc.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-tokyo-1.oraclecloud.com,OU=Oracle ADB TOKYO,O=Oracle Corporation,L=Redwood City,ST=California,C=US"))) orcl_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=xxx.ap-tokyo-1.oraclecloud.com))(connect_data=(service_name=xxxxxxxxxxxxxxx_orcl_low.adwc.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-tokyo-1.oraclecloud.com,OU=Oracle ADB TOKYO,O=Oracle Corporation,L=Redwood City,ST=California,C=US"))) orcl_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=xxx.ap-tokyo-1.oraclecloud.com))(connect_data=(service_name=xxxxxxxxxxxxxxx_orcl_medium.adwc.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-tokyo-1.oraclecloud.com,OU=Oracle ADB TOKYO,O=Oracle Corporation,L=Redwood City,ST=California,C=US")))
移行の際には接続毎にどれを使うかを考えなければならない。上記それぞれのサービスの違いは以下マニュアルに記載されている。OLTP系の接続は同時実行性が求められるため、一律tpurgentで良いだろう。バッチ系APはtpでも良さそうだが、paralellismが使えないので、やはりtpurgentしかない。そもそもリソースマネージャに依存せずに設計されたシステムでは、一律tpurgentでの接続と割り切っても良いのではないか。なお、もしADWを使う場合は少し注意が必要である。ADWのhighはparallelismはCPU_COUNTまでであるが、Concurrent Statements（同時実行できるSQL数）が3に限定されている。DWH系アプリケーションの夜間バッチは多重実行されるため、ここはmediumを選択し、parallelismは4に制限されるが、Concurrent Statementsがparallelismが1.25 × CPU_COUNTとなるのが良いだろう。
Predefined Database Service Names for Autonomous Transaction Processing
Predefined Database Service Names for Autonomous Data Warehouse Dedicated Databases
◇バックアップ
ADBのバックアップは、保持期間60日、PITRでいつでも任意のタイミングにリカバリできる。しかし、sharedではバックアップのタイミングや保持期間がカスタマイズできない。例えば私のADWの環境ではUTCで12時頃（JSTで21時頃）にインクリメンタルバックアップが取得されているが、今のシステムでは、この時間は月次の重要バッチと重なってしまう。この点、dedicatedならバックアップタイミングがカスタマイズが可能、かつ、保持期間も7、15、30、60日から選択できるようになる。また、マニュアルバックアップを取得できるので、特定のリリースのタイミング等でのバックアップに利用できる。実運用上は主要なバッチと重ならないように制御することを考えると、オブジェクトストレージへのバックアップ性能を見極め、現在のバックアップウィンドウに収まるかを見切る必要がある。このあたりは実際に性能を検証して確認する必要があるだろう。
一点気になるのは、開発期間中のバックアップ・リカバリである。例えば性能試験では、特定のDBのデータ断面バックアップしておき、試験後にその断面をリストアする。試験を同じデータの条件で実行するために、何度も同じ断面にリストア（フラッシュバックDB）する。夜間にシナリオを流せるよう、リストアもジョブに組み込み自動化する。このような使い方をするには、マニュアルバックアップとフラッシュバックDBを組み合わせればできそうな気はするが、フラッシュバックの保持期間が24時間では土日かけて流すシナリオに耐えられないとか、自動化のために外部インタフェースからフラッシュバックDBを起動する仕組みづくりを考えないといけないといった解決すべき課題はいくつか出てきそうである。複数断面を任意のタイミングにリカバリすることの難しさを経験した方なら、これがクラウドで簡単に実現できる日を待っているに違いない。
◇監視
現時点ではATP dedicatedのみだが、OCIマーケットプレイスのOEMが使えるので、これで一通りの監視が可能と思われる。alert.logでORA-エラーが発生したことの検知や、メモリや領域等のリソース（閾値）監視は基本的に用意されたテンプレートを利用して作りこめばよいだろう。拡張メトリックで作りこんだ部分のカスタマイズがどの程度許されるのか、あたりが若干懸念としてある。また、OEMで検知したメッセージをJP1/IMの統合監視に連携する必要があるので、この実現方式は要検討である。
Administrator's Guide for Oracle Autonomous Databases
◇その他懸念点
まず気になった点はDBのキャラクタセットである。本システムのDBのキャラクタセットはSJIS（外字あり）なので、ADBへの移行に際しても同じキャラクタセットが好ましい。sharedはAL32UTF8となってしまうのでこの意味も採用は難しい。sharedの場合、CDBを共有しPDBをテナントとして提供しているはずで、この場合、CDBとPDBの文字コードは合わせておきたいのは理解できる。その意味でdedicatedだとカスタマイズできるのではないかと期待したが、現時点では難しいようだ。これはかなり厳しい制約で、文字コード変換を伴う移行は難易度が格段に上がることを考えると、今後の対応に期待したい。
Developer’s Guide to Oracle Autonomous Transaction Processing on Dedicated Exadata Infrastructure
Characteristics of an Autonomous Transaction Processing dedicated database include:- The default data and temporary tablespaces for the database are configured automatically.
- The name of the default data tablespace is DATA.
- The database character set is Unicode AL32UTF8.
...
次に気になった点はDBLINKである。本システムでは、異なるDB間でDBLINKを使って表への参照・更新を行っている。ADB間のDBLINKの作成は可能なので、この点は問題なさそうである（tnsnames.oraが使えないので、create database linkで指定するのは接続識別子ではなく、Easy Connectの書式で指定する）。ただ、現状PL/SQLプロシージャでDBLINKの使用はできないという制約がある。本システムではPro*CやMVIEWのほか、PL/SQLでもDBLINKを使用しているため、この制約はかなり厳しい。今後の対応に期待したい。
４．まとめ
ADBについて最近学んだことをベースに、現在私の関わっているシステムへADBはどの程度使えるのかを考察してみたが、やはり今の運用を変えずに移行するのは難しいと感じた。クラウドサービスをベースに運用を見直す前提で考え直す必要があるので、まずそこのハードルをクリアできるかがポイントと感じる。私の感覚として、変わらないことを是とする企業風土の中では、このハードルは決して低いものではない。この他、文字コードやDBLINKに関しては、現時点では厳しい制約がある点もあることがわかった。このような技術的な問題については、クラウドサービスの拡充に伴い解消していくのではという期待もあるので、今後も継続して注視していきたいと思う。なお、本記事内容は現時点で私が知ったことをベースに記載しているため、正確でない部分があるかもしれない旨、ご容赦頂きたい。
以上
2020-09-07 01:21
