はじめに
※本内容は2020年3月17日時点のものです。
昨年の9月にOCI DBaaSに関する記事を書いてから、半年が経過しました。
その間に下記のような様々な機能が追加となりましたので、それらを確認していきたいと思います。
ちなみに前回記載の記事はこちらからご確認ください。
上記の他もリリースされておりますので、他のリリースも気になる方はこちらから是非ご確認ください
DB作成
基本的な画面構成は前回の記事と大差がないため、本記事では追加されている項目を記載します。
LVM
以前まではONE Nodeであっても「Storage Management Software]はOracle Grid Infrastructure(GI)のみでしたが、
[Fast provisioning option]がリリースされ、LVM構成での起動が可能となっています。
リリースノートのタイトル通り、インスタンス作成にかかる時間が大幅に短縮されています。
手元で確認した限りでは、GIでは起動まで70分程度かかりましたが、LVMでは25分程で起動しました。
なお、ONE Node限定の機能なため、RACでの選択はできません。
Time zone
[Advanced Options]を表示すると[Time zone]が選択出来るようになってます。
Version 20c(Preview)
そして[Database version]では20c(Preview)も選択出来るようになってますね。
本記事はPreviewは避け、19cで作成をしています。
なお20c(Preview)に関しては、「Storage Management Software]でLVMを選択している必要があります。
LVM構成の確認
インスタンス起動後、sshでログインし、内部を確認していきます。
lsblkコマンドとlvscanコマンドでLVM構成である事が確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 58G 0 disk |-sda1 8:1 0 486M 0 part /boot/efi |-sda2 8:2 0 1.4G 0 part /boot `-sda3 8:3 0 52.2G 0 part |-VolGroupSys0-LogVolRoot 249:0 0 35G 0 lvm / `-VolGroupSys0-LogVolSwap 249:1 0 16G 0 lvm [SWAP] sdb 8:16 0 128G 0 disk `-DATA_GRP-DATA 249:2 0 256G 0 lvm /u02 sdc 8:32 0 128G 0 disk `-DATA_GRP-DATA 249:2 0 256G 0 lvm /u02 sdd 8:48 0 128G 0 disk `-RECO_GRP-RECO 249:3 0 256G 0 lvm /u03 sde 8:64 0 128G 0 disk `-RECO_GRP-RECO 249:3 0 256G 0 lvm /u03 sdf 8:80 0 200G 0 disk # lvscan ACTIVE '/dev/BITS_GRP/BITS' [<200.00 GiB] inherit ACTIVE '/dev/VolGroupSys0/LogVolRoot' [35.00 GiB] inherit ACTIVE '/dev/VolGroupSys0/LogVolSwap' [16.00 GiB] inherit ACTIVE '/dev/DATA_GRP/DATA' [255.99 GiB] inherit ACTIVE '/dev/RECO_GRP/RECO' [255.99 GiB] inherit |
タイムゾーンの確認
OSの時刻に関してはJSTになっていましたが、DBTIMEZONEやCDBのタイムゾーンはUTC、PDBに関してはPDTとなっていました。
マニュアルには下記のような記載がありますが、、PDTとなるのはよく分からないです。
The time zone that you specify when you create the DB system applies to the host and to the Oracle Grid Infrastructure (if the system has Grid Infrastructure), and controls the time zone of the database log files.
なおタイムゾーンで[Asia/Tokyo]を選択しない場合はOSの時刻もUTCです。
LVMとGIの違いも知りたかったので、両方で確認してみました。
LVM構成で起動させた場合
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
# su - oracle $ date Tue Mar 17 14:31:59 JST 2020 $ sqlplus system/Pass_Word_1234; SQL> HOST date Tue Mar 17 14:32:23 JST 2020 SQL> SELECT DBTIMEZONE FROM DUAL; DBTIME ------ +00:00 SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 17-MAR-20 05.33.00.645960000 AM ETC/UTC SQL> alter session set container=DB0316_PDB1; Session altered. SQL> show con_name CON_NAME ------------------------------ DB0316_PDB1 SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 16-MAR-20 10.34.14.304349000 PM PST8PDT |
GIで起動させた場合は下記のようになっていました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
$ date Tue Mar 17 14:36:05 JST 2020 SQL> HOST date Tue Mar 17 14:36:27 JST 2020 SQL> SELECT DBTIMEZONE FROM DUAL; DBTIME ------ +00:00 SQL> show con_name; CON_NAME ------------------------------ CDB$ROOT SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 17-MAR-20 02.37.17.342432000 PM ASIA/TOKYO SQL> alter session set container=PDB01; Session altered. SQL> show con_name CON_NAME ------------------------------ PDB01 SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 17-MAR-20 05.41.45.875000000 AM ETC/UTC |
タイムゾーンに関しては起動後にしっかりとした確認が必要そうですね。
なお起動後のタイムゾーンの変更は上記マニュアルの「Changing Time Zones After Provisioning」を参照ください。
スケールアップ
スケールアップを実行します。
なお、DBインスタンスのスケールアップ機能リリースに先駆けて、Computeインスタンスの同機能は1月にリリースされていますので、DBサーバー以外でも利用可能です。
起動時:VM.Standard2.1(OCPU:1,Memory:15)からスケールアップしてみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
CPU # grep physical.id /proc/cpuinfo | sort -u | wc -l 1 # grep cpu.cores /proc/cpuinfo | sort -u cpu cores : 1 # grep processor /proc/cpuinfo | wc -l 2 Memory # free -m total used free shared buff/cache available Mem: 14778 9491 1988 5 3297 3893 Swap: 16383 7 16376 |
コンソールの[DB System Details]より[Change Shape]を選択します。
ここで変更するシェイプを選択します。
上記メッセージにあるようにインスタンス再起動が実行され、DBシステムのステータスが[Updating]となります。
その後、10分ほどでステータスが[Available]に戻りました。
ログインし、OCPUやMemoryがスペックアップしているか確認してみます。
変更後:VM.Standard2.2(OCPU:2,Memory:30)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
CPU # grep physical.id /proc/cpuinfo | sort -u | wc -l 1 # grep cpu.cores /proc/cpuinfo | sort -u cpu cores : 2 # grep processor /proc/cpuinfo | wc -l 4 Memory # free -m total used free shared buff/cache available Mem: 29898 17593 11465 8 839 11222 Swap: 16383 0 16383 |
スケールアップされてますね。
今回はスケールアップを実施しましたが、スケールダウンにも対応しておりますので、
再起動は必要となりますが、負荷状況に合わせて柔軟に変更可能となっています。
まとめ
クラウドサービスとして、新機能の追加が早いのは嬉しいことですね。
ただそれは常にアンテナを張っていないと、あっという間に情報が陳腐化してしまう可能性も含んでいます。
リリースノートを適宜確認し時間の取れるタイミングで確認は継続していきたいところですね。
