Autonomous Database を ECPU モデルに変更してみた

はじめに

Autonomous Database ServerlessでECPU課金モデルが利用できるようになりました
本記事では、既存のOCPU課金モデルのAutonomous DatabaseをECPU課金モデルへ変更する手順と、変更する際にクライアント接続が保たれているのか、処理性能等をレポートしたいと思います

ECPU課金モデルとは

Autonomous Database (以下 ADB) の新しい課金メトリックであり、Autonomous Data Warehouse (以下 ADW)、Autonomous Transaction Processing (以下 ATP) のみで利用可能
ECPU がデフォルトの価格メトリックとなり、推奨されています
- OCPUからECPUは変更可能ですが、逆（ECPUからOCPUへの変更）は不可です
OCPU と ECPU の違いによる性能差はなく、現時点では 1OCPU ≒ 4ECPU と考えて問題ありません
ECPU 利用の最小単位は 2 であり、スケールアップ・ダウンは 1 ECPU 単位で行うことが可能
ストレージ費用がADW、ATPで異なります
- ADW：￥3.416[GB/月]（￥3,497.984[TB/月]）、 ATP：￥16,576[TB/月]
自動バックアップのストレージ費用が必要となり、1～60日の間で保持期間を設定可能となります

などがございますが、Oracle Autonomous Database ECPUに関するよくある質問（PDF）もご参照いただければと思います

OCPUからECPUへの変更

ADBの詳細画面から、 ECPUモデルに更新 を選択し、請求モデルの更新画面で 変更の保存 をクリックするだけで、ECPU課金モデルへ変更できます

ECPU課金モデルへ変更する際にどのような動作となるのかを確認してみたいと思います

変更中、変更後にデータベースが再起動するのか
既存のクライアント接続は維持されるのか
トランザクションは維持されるのか
変更中に新規接続は行えるのか
変更中の処理性能はどうなるのか

※5の確認のみ他の確認の影響をなるべく排除したいため、別インスタンスを用意して実施しております
※確認を行うインスタンスは両方とも、1OCPU・1TBストレージのATPインスタンスを使用しております

1～4の確認用インスタンスをECPUモデルに変更

作業リクエストより、開始時刻が 11:00:25 であり、終了時刻は 11:01:12 であることがわかり、変更処理は約 50 秒程度で完了しているようです

1. 変更中、変更後にデータベースが再起動するのか

インスタンス起動時間の確認

SQL> SELECT
  2  TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME,
  3  TO_CHAR(OPEN_TIME, 'YYYY/MM/DD HH24:MI:SS') AS OPEN_TIME
  4  FROM v$containers
  5  ;

CHECK_TIME                                                OPEN_TIME
--------------------------------------------------------- ---------------------------------------------------------
2023/12/27 10:47:22                                       2023/12/27 00:58:37

SQL> SELECT

2 TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME,

3 TO_CHAR(OPEN_TIME, 'YYYY/MM/DD HH24:MI:SS') AS OPEN_TIME

4 FROM v$containers

5 ;

CHECK_TIME OPEN_TIME

--------------------------------------------------------- ---------------------------------------------------------

2023/12/27 10:47:22 2023/12/27 00:58:37

v$containersよりATPの起動時間を確認しています（OPEN_TIMEはUTCで出力されているため、実際は 09:58:37 となります）

ECPU モデルに変更を実施

変更処理を実施します

インスタンス起動時間の再確認

SQL> SELECT
  2  TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME,
  3  TO_CHAR(OPEN_TIME, 'YYYY/MM/DD HH24:MI:SS') AS OPEN_TIME
  4  FROM v$containers
  5  ;

CHECK_TIME                                                OPEN_TIME
--------------------------------------------------------- ---------------------------------------------------------
2023/12/27 11:04:17                                       2023/12/27 00:58:37

SQL> SELECT

2 TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME,

3 TO_CHAR(OPEN_TIME, 'YYYY/MM/DD HH24:MI:SS') AS OPEN_TIME

4 FROM v$containers

5 ;

CHECK_TIME OPEN_TIME

--------------------------------------------------------- ---------------------------------------------------------

2023/12/27 11:04:17 2023/12/27 00:58:37

ECPU モデルに変更しても OPEN_TIMEに変化はありませんので、再起動は行われていないと思われます

2. 既存のクライアント接続は維持されるのか

SQL*Plusでインスタンスに接続します

SQL> SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual;

CHECK_TIME
---------------------------------------------------------
2023/12/27 10:48:33

SQL>

SQL> SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual;

CHECK_TIME

---------------------------------------------------------

2023/12/27 10:48:33

SQL>

ECPU モデルに変更を実施

変更処理を実施します

SQL*PlusでSQLを実行してみます

SQL> SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual;

CHECK_TIME
---------------------------------------------------------
2023/12/27 10:48:33

SQL> r
  1* SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual

CHECK_TIME
---------------------------------------------------------
2023/12/27 11:04:42

SQL>

SQL> SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual;

CHECK_TIME

---------------------------------------------------------

2023/12/27 10:48:33

SQL> r

1* SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') AS CHECK_TIME FROM dual

CHECK_TIME

---------------------------------------------------------

2023/12/27 11:04:42

SQL>

ORAエラーもなくSQLが実行できましたので、既存クライアントが切断されるということも無いようです

3. トランザクションは維持されるのか

SQL*Plusでインスタンスに接続し、トランザクションを開始します

SQL> SELECT * FROM t1;
        ID DATA
---------- ------------------------------
         1 FGHIJKLMNO
         2 EFGHIJKLMN
         3 DEFGHIJKLM
         4 CDEFGHIJKL
         5 LMNOPQRSTU

SQL> SET TRANSACTION NAME 'OCPU_TO_ECPU';

トランザクションが設定されました。

SQL> UPDATE t1 SET data=SUBSTR('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890', dbms_random.value * 50, 10) WHERE id=1;

1行が更新されました。

SQL> SELECT * FROM t1;

        ID DATA
---------- ------------------------------
         1 OPQRSTUVWX
         2 EFGHIJKLMN
         3 DEFGHIJKLM
         4 CDEFGHIJKL
         5 LMNOPQRSTU

SQL>

SQL> SELECT * FROM t1;

ID DATA

---------- ------------------------------

1 FGHIJKLMNO

2 EFGHIJKLMN

3 DEFGHIJKLM

4 CDEFGHIJKL

5 LMNOPQRSTU

SQL> SET TRANSACTION NAME 'OCPU_TO_ECPU';

トランザクションが設定されました。

SQL> UPDATE t1 SET data=SUBSTR('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890', dbms_random.value * 50, 10) WHERE id=1;

1行が更新されました。

SQL> SELECT * FROM t1;

ID DATA

---------- ------------------------------

1 OPQRSTUVWX

2 EFGHIJKLMN

3 DEFGHIJKLM

4 CDEFGHIJKL

5 LMNOPQRSTU

SQL>

ダミーデータを用意して明示的にトランザクションを開始、id=1 の値を更新した状態で待機します

ECPU モデルに変更を実施

変更処理を実施します

ロールバックして確認します

SQL> SELECT * FROM t1;

        ID DATA
---------- ------------------------------
         1 OPQRSTUVWX
         2 EFGHIJKLMN
         3 DEFGHIJKLM
         4 CDEFGHIJKL
         5 LMNOPQRSTU

SQL> ROLLBACK;

ロールバックが完了しました。

SQL> SELECT * FROM t1;

        ID DATA
---------- ------------------------------
         1 FGHIJKLMNO
         2 EFGHIJKLMN
         3 DEFGHIJKLM
         4 CDEFGHIJKL
         5 LMNOPQRSTU

SQL>

SQL> SELECT * FROM t1;

ID DATA

---------- ------------------------------

1 OPQRSTUVWX

2 EFGHIJKLMN

3 DEFGHIJKLM

4 CDEFGHIJKL

5 LMNOPQRSTU

SQL> ROLLBACK;

ロールバックが完了しました。

SQL> SELECT * FROM t1;

ID DATA

---------- ------------------------------

1 FGHIJKLMNO

2 EFGHIJKLMN

3 DEFGHIJKLM

4 CDEFGHIJKL

5 LMNOPQRSTU

SQL>

ロールバックも問題なくできますので、トランザクションも維持されたままであることが確認できます

4. 変更中に新規接続は行えるのか

データベースに毎秒間隔で接続を行います

$ while (true); do echo "SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') FROM dual;" | sqlplus -s admin/＜＜password＞＞@abcdefghijklmnop_medium 2>&1 ; sleep 1; done

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 10:59:37

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 10:59:38

$ while (true); do echo "SELECT TO_CHAR(sysdate,'YYYY/MM/DD HH24:MI:SS') FROM dual;" | sqlplus -s admin/＜＜password＞＞@abcdefghijklmnop_medium 2>&1 ; sleep 1; done

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 10:59:37

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 10:59:38

毎秒間隔で現在時刻を問い合わせするように実行します

ECPU モデルに変更を実施

変更処理を実施します

ECPU モデル変更中の接続を確認します

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:23

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:24

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:25

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:27

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:28

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:29

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')
---------------------------------------------------------
2023/12/27 11:00:30

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:23

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:24

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:25

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:27

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:28

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:29

TO_CHAR(SYSDATE,'YYYY/MM/DDHH24:MI:SS')

---------------------------------------------------------

2023/12/27 11:00:30

一部抜粋ではありますが、問題なく接続できていることが確認できます

5の確認用インスタンスをECPUモデルに変更

作業リクエストより、開始時刻が 11:15:05 で終了時刻は 11:15:39 であることがわかり、変更処理は約 35 秒程度で完了しているようです

5. 変更中の処理性能はどうなるのか

データベースに負荷をかけてみます

本検証では、jdbcRunnerを用いて Tiny TPC-Cを実行してみます
※ATPの処理性能を検証することが目的ではないため、各種パラメータは jdbcrunner-1.3.1.zip に同梱されている tpcc.js をそのまま使用し、測定時間のみ5分に変更して実行しています

$ java JR tpcc.js
11:08:40 [INFO ] > JdbcRunner 1.3.1
11:08:40 [INFO ] [Config]
Program start time   : 20231227-110840
Script filename      : tpcc.js
JDBC driver          : oracle.jdbc.driver.OracleDriver
JDBC URL             : jdbc:oracle:thin:@abcdefghijklmnop_high?TNS_ADMIN=/home/opc/bin/instantclient/network/admin
JDBC user            : tpcc
Warmup time          : 300 sec
Measurement time     : 300 sec
Number of tx types   : 5
Number of agents     : 16
Connection pool size : 16
Statement cache size : 40
Auto commit          : false
Sleep time           : 0,0,0,0,0 msec
Throttle             : - tps (total)
Debug mode           : false
Trace mode           : false
Log directory        : logs
Parameter 0          : 0
Parameter 1          : 0
Parameter 2          : 0
Parameter 3          : 0
Parameter 4          : 0
Parameter 5          : 0
Parameter 6          : 0
Parameter 7          : 0
Parameter 8          : 0
Parameter 9          : 0
11:08:45 [INFO ] Tiny TPC-C
11:08:46 [INFO ] Scale factor : 16
11:08:46 [INFO ] tx0 : New-Order transaction
11:08:46 [INFO ] tx1 : Payment transaction
11:08:46 [INFO ] tx2 : Order-Status transaction
11:08:46 [INFO ] tx3 : Delivery transaction
11:08:46 [INFO ] tx4 : Stock-Level transaction
11:08:47 [INFO ] [Warmup] -299 sec, 28,28,4,2,7 tps, (28,28,4,2,7 tx)
11:08:48 [INFO ] [Warmup] -298 sec, 64,56,5,9,5 tps, (92,84,9,11,12 tx)
11:08:49 [INFO ] [Warmup] -297 sec, 94,105,7,6,4 tps, (186,189,16,17,16 tx)
・・・
・・・
・・・
11:13:44 [INFO ] [Warmup] -2 sec, 249,257,25,26,27 tps, (71449,71456,7143,7145,7149 tx)
11:13:45 [INFO ] [Warmup] -1 sec, 252,255,26,25,21 tps, (71701,71711,7169,7170,7170 tx)
11:13:46 [INFO ] [Warmup] 0 sec, 238,234,24,23,22 tps, (71939,71945,7193,7193,7192 tx)
11:13:47 [INFO ] [Progress] 1 sec, 262,246,26,24,30 tps, 262,246,26,24,30 tx
11:13:48 [INFO ] [Progress] 2 sec, 250,261,26,30,23 tps, 512,507,52,54,53 tx
11:13:49 [INFO ] [Progress] 3 sec, 246,257,26,26,25 tps, 758,764,78,80,78 tx
11:13:50 [INFO ] [Progress] 4 sec, 244,243,25,20,26 tps, 1002,1007,103,100,104 tx
11:13:51 [INFO ] [Progress] 5 sec, 259,234,24,26,23 tps, 1261,1241,127,126,127 tx
11:13:52 [INFO ] [Progress] 6 sec, 248,250,24,23,23 tps, 1509,1491,151,149,150 tx
11:13:53 [INFO ] [Progress] 7 sec, 238,252,26,28,29 tps, 1747,1743,177,177,179 tx
11:13:54 [INFO ] [Progress] 8 sec, 251,248,24,22,22 tps, 1998,1991,201,199,201 tx
11:13:55 [INFO ] [Progress] 9 sec, 247,241,24,24,22 tps, 2245,2232,225,223,223 tx
11:13:56 [INFO ] [Progress] 10 sec, 254,265,27,29,27 tps, 2499,2497,252,252,250 tx
・・・
・・・
・・・

$ java JR tpcc.js

11:08:40 [INFO ] > JdbcRunner 1.3.1

11:08:40 [INFO ] [Config]

Program start time : 20231227-110840

Script filename : tpcc.js

JDBC driver : oracle.jdbc.driver.OracleDriver

JDBC URL : jdbc:oracle:thin:@abcdefghijklmnop_high?TNS_ADMIN=/home/opc/bin/instantclient/network/admin

JDBC user : tpcc

Warmup time : 300 sec

Measurement time : 300 sec

Number of tx types : 5

Number of agents : 16

Connection pool size : 16

Statement cache size : 40

Auto commit : false

Sleep time : 0,0,0,0,0 msec

Throttle : - tps (total)

Debug mode : false

Trace mode : false

Log directory : logs

Parameter 0 : 0

Parameter 1 : 0

Parameter 2 : 0

Parameter 3 : 0

Parameter 4 : 0

Parameter 5 : 0

Parameter 6 : 0

Parameter 7 : 0

Parameter 8 : 0

Parameter 9 : 0

11:08:45 [INFO ] Tiny TPC-C

11:08:46 [INFO ] Scale factor : 16

11:08:46 [INFO ] tx0 : New-Order transaction

11:08:46 [INFO ] tx1 : Payment transaction

11:08:46 [INFO ] tx2 : Order-Status transaction

11:08:46 [INFO ] tx3 : Delivery transaction

11:08:46 [INFO ] tx4 : Stock-Level transaction

11:08:47 [INFO ] [Warmup] -299 sec, 28,28,4,2,7 tps, (28,28,4,2,7 tx)

11:08:48 [INFO ] [Warmup] -298 sec, 64,56,5,9,5 tps, (92,84,9,11,12 tx)

11:08:49 [INFO ] [Warmup] -297 sec, 94,105,7,6,4 tps, (186,189,16,17,16 tx)

・・・

11:13:44 [INFO ] [Warmup] -2 sec, 249,257,25,26,27 tps, (71449,71456,7143,7145,7149 tx)

11:13:45 [INFO ] [Warmup] -1 sec, 252,255,26,25,21 tps, (71701,71711,7169,7170,7170 tx)

11:13:46 [INFO ] [Warmup] 0 sec, 238,234,24,23,22 tps, (71939,71945,7193,7193,7192 tx)

11:13:47 [INFO ] [Progress] 1 sec, 262,246,26,24,30 tps, 262,246,26,24,30 tx

11:13:48 [INFO ] [Progress] 2 sec, 250,261,26,30,23 tps, 512,507,52,54,53 tx

11:13:49 [INFO ] [Progress] 3 sec, 246,257,26,26,25 tps, 758,764,78,80,78 tx

11:13:50 [INFO ] [Progress] 4 sec, 244,243,25,20,26 tps, 1002,1007,103,100,104 tx

11:13:51 [INFO ] [Progress] 5 sec, 259,234,24,26,23 tps, 1261,1241,127,126,127 tx

11:13:52 [INFO ] [Progress] 6 sec, 248,250,24,23,23 tps, 1509,1491,151,149,150 tx

11:13:53 [INFO ] [Progress] 7 sec, 238,252,26,28,29 tps, 1747,1743,177,177,179 tx

11:13:54 [INFO ] [Progress] 8 sec, 251,248,24,22,22 tps, 1998,1991,201,199,201 tx

11:13:55 [INFO ] [Progress] 9 sec, 247,241,24,24,22 tps, 2245,2232,225,223,223 tx

11:13:56 [INFO ] [Progress] 10 sec, 254,265,27,29,27 tps, 2499,2497,252,252,250 tx

・・・

ECPU モデルに変更を実施

Warmupが完了しProgressになったら、変更処理を実施します

結果確認

tx1はほぼ250tpsから270tpsほどを記録しており、変更処理中でも11:15:30から5秒間ほど性能が落ち込んだ以外は問題ないことが確認できます
tx0,tx2,tx3,tx4に関しては、tx0が何故か途中で増加しておりますが、基本的には横ばいで推移していることからも、性能劣化などは見受けられなかと思われます

まとめ

上記の結果よりOCPUからECPUへ変換する際には、既存の接続に関しては気にする必要がないことがわかります
性能に関しては、ワークロードによっては性能の問題が出てしまう可能性はございますが、本検証結果を見る限りではそれほど気にする必要はないことがわかります
※ただし、すべての環境で同一の結果が得られるわけではございませんので、なるべくメンテナンス時間を設けていただくことが望ましいです

追加確認

4OCPUのATPを16ECPUに変更してみましたが、変更処理は約 29 秒で完了いたしました
全く負荷をかけていない作成直後のインスタンスであるため、あくまで参考となりますが、OCPU数は変更処理時間にそれほどの影響は与えないものと思われます

データベース＆クラウド技術情報

MySQLでミッションクリティカルシステムのダウンタイム”ゼロ...

【HeatWavejp】祝１周年はじめてでもわかる！MySQL HeatWav...

HeatWavejp Meetup #06 イベントレポート

【HeatWavejp】MySQL HeatWave へのデータ同期はどうするの...

HeatWavejp Meetup #05 イベントレポート

【共催セミナー】「Oracle Cloud」の実力とは？～低価格・高品質・移行...

HeatWavejp Meetup #03 イベントレポート

HeatWavejp Meetup #02 イベントレポート

HeatWavejp Meetup #01 イベントレポート

Autonomous Database を ECPU モデルに変更してみた

はじめに

ECPU課金モデルとは

OCPUからECPUへの変更

1～4の確認用インスタンスをECPUモデルに変更

1. 変更中、変更後にデータベースが再起動するのか

インスタンス起動時間の確認

ECPU モデルに変更を実施

インスタンス起動時間の再確認

2. 既存のクライアント接続は維持されるのか

SQL*Plusでインスタンスに接続します

ECPU モデルに変更を実施

SQL*PlusでSQLを実行してみます

3. トランザクションは維持されるのか

SQL*Plusでインスタンスに接続し、トランザクションを開始します

ECPU モデルに変更を実施

ロールバックして確認します

4. 変更中に新規接続は行えるのか

データベースに毎秒間隔で接続を行います

ECPU モデルに変更を実施

ECPU モデル変更中の接続を確認します

5の確認用インスタンスをECPUモデルに変更

5. 変更中の処理性能はどうなるのか

データベースに負荷をかけてみます

ECPU モデルに変更を実施

結果確認

まとめ

追加確認