[Oracle Cloud] DBaaS (VM) を使ってみる その3 - DBaaS使うときに確認しておいたほうがよいとこ


## はじめに
DBaaSを触ってみて、きづいたこと・確認しておいたほうがよいことをざっくばらんに書いてみる

## ゴミがある。。

2021年1月に作成したイメージを確認したところ、再発してました。。

<strike>
以下に記載のごみは、2020年7月確認時には消えていました。
</strike>

<strike>
データベース関係ないですが、2020.3時点のイメージには大きめのごみ(インストールイメージ)が含まれているようです。(おそらく次のアップデートで解消されると思いますが。。)
</strike>

```
# df -Ph /
Filesystem                           Size  Used Avail Use% Mounted on
/dev/mapper/VolGroupSys0-LogVolRoot   35G   29G  4.0G  88% /

# du -sm /opt/oracle/oak/pkgrepos/orapkgs/clones/
26058   /opt/oracle/oak/pkgrepos/orapkgs/clones/

# ls -ltr /opt/oracle/oak/pkgrepos/orapkgs/clones/
total 26683152
-rwxr-xr-x 1 root root 2842284040 Jan  9 02:00 db112.200114.tar.gz
-rwxrwxrwx 1 root root 4160621279 Jan  9 02:03 db122.200114.tar.gz
-rwxrwxrwx 1 root root 3854266382 Jan  9 17:38 db19.200114.tar.gz
-rwxrwxrwx 1 root root 5569248951 Jan  9 17:40 db18.200114.tar.gz
-rwxrwxrwx 1 root root 5216286166 Jan 29 18:41 grid19.tar.gz
-rwxrwxrwx 1 root root 5680802224 Jan 30 10:06 db121.200114.tar.gz

なので、消します。
```
## /tmpがマウントされる

以下に記載の/tmpマウントは、2020年9月確認時には消えていました。
<strike>
2020年7月時点でVMのDBCSを作成したら、tmpfsとして/tmpがマウントされてました。
</strike>

```
# df -Ph
…
/dev/asm/commonstore-129             5.0G  319M  4.7G   7% /opt/oracle/dcs/commonstore
tmpfs                                7.3G   36K  7.3G   1% /tmp ★
```

どうも、initdcsadmin起動時にマウントされるぽい。
このままだと、再起動すると/tmpにおいたファイルが消えてしまったり、/tmpに大きいファイルをおくと、物理メモリを消費してしまいそう。

以前もあったんだよね、これ。

正しい対処かどうかはおいておいて、tmp.mountをmask状態にしてあげると解消されました。

```
# systemctl mask tmp.mount
```

## デフォルトロケールが設定されない
2020年9月時点でVMのDBCSを作成したら、/etc/locale.confファイルが存在しない状態でした。

<strike>
vimなどでテキストに日本語書くと全部文字化けるので、/etc/locale.confを作成して以下のエントリ書いてあげることで以前のようになりました
</strike>
よく考えたら、OEL7なのでlocalectlで設定したほうがいいですね

```CONSOLE
$ localectl set-locale LANG=en_US.UTF-8
$ localectl
   System Locale: LANG=en_US.UTF-8
       VC Keymap: n/a
      X11 Layout: n/a
$ cat /etc/locale.conf
LANG=en_US.UTF-8
```

## yumレポジトリの設定が消えてる

2020年12月時点で確認しました。yumレポジトリ設定用のファイルがなくなり、versionlockも設定されています。#versionlockは以前からかどうかは未確認。

```CONSOLE
# ll /etc/yum.repos.d/
total 0
# yum repolist
Loaded plugins: versionlock
repolist: 0
# cat /etc/yum/pluginconf.d/versionlock.list
//省略//
0:dcs-agent-20.3.4.0.0_200917.1159-20.*
0:dcs-admin-20.3.4.0.0_200917.1159-1.*
```
<strike>
DBCSに追加パッケージを導入したいときに困るので、ComputeのOEL7と同じような設定を行ってみる # サポートされるかは未確認
</strike>

[2021年1月追記]
[DBCSのOS Update マニュアル](https://docs.oracle.com/en-us/iaas/Content/Database/Tasks/updatingDB.htm#OS)に、yumリポジトリの定義ファイルの更新方法が記載されてました。こちらの方法のほうがよさそうです。

## 内部利用されるIP

謎のens4インタフェースに192.168.16.0/24ネットワークがくっついてます。

```
# ip -f inet -o addr
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
2: ens3    inet 10.0.2.51/24 brd 10.0.2.255 scope global dynamic ens3\       valid_lft 53518sec preferred_lft 53518sec
3: ens4    inet 192.168.16.18/24 brd 192.168.16.255 scope global ens4\       valid_lft forever preferred_lft forever
```

DB作成コンソールにも注意書きがでるので驚きはないのですが、
![q.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/456818/3d1f22b4-a30d-b895-6e2d-7a3419494868.png)

たとえば、192.168.16.0/24ネットワークのクライアントからDBに接続しようとするとルーティングの問題が発生するので注意が必要です。(ODAにも同じような制限がありますが、ビンゴしてしまうことがまれにあります。)

## ブロックボリューム
DATA用に4つ、RECO用に4つで合計8個のブロックボリュームがアタッチされるのですが、現時点で汎用のブロックボリュームを追加でアタッチできるようなインタフェースが用意されていません。

既定の状態で、以下のような構成になっているので、ローカルに大きいファイルを置くことができません。

```
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   64G  0 disk 
sdc                           8:32      0   64G  0 disk 
sdd                           8:48      0   64G  0 disk 
sde                           8:64      0   64G  0 disk 
sdf                           8:80      0   64G  0 disk 
sdg                           8:96      0   64G  0 disk 
sdh                           8:112     0   64G  0 disk 
sdi                           8:128     0   64G  0 disk 
sdj                           8:144     0  200G  0 disk /u01
asm!commonstore-250         248:128001  0    5G  0 disk /opt/oracle/dcs/commonstore
```

データベースローカルにファイルシステムが必要な場合は、ASMディスクグループにACFSを作ってあげる必要がありそうです。

## タイムゾーン
最近、DBaaSのVMインスタンス作成するときに[タイムゾーンを初期設定する機能](https://docs.cloud.oracle.com/en-us/iaas/releasenotes/changes/d7e2bf9d-22ca-4e06-b5ba-00976ed8c047/)がでました。

Asia/Tokyoの設定をためしてみました。現時点では、PDBのスケジューラ・タイムゾーンに注意が必要なようです。

```
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> select dbms_scheduler.stime from dual;

STIME
---------------------------------------------------------------------------
13-MAR-20 04.58.39.205957000 PM ASIA/TOKYO ★ CDBはAsia/Tokyo

SQL> alter session set container=pdb01;
Session altered.

SQL> select dbms_scheduler.stime from dual;
STIME
---------------------------------------------------------------------------
13-MAR-20 07.58.50.860462000 AM ETC/UTC ★ PDBはUTC

アラート・ログを見てると、やっぱり9時間遅れでPDB側のメンテナンスウィンドウが開いて自動タスクが実行されているようです。メンテンタンスウィンドウが日中帯に開いてしまうので、注意が必要。
…
2020-03-13T22:00:00.021522+09:00
Setting Resource Manager plan SCHEDULER[0x4D61]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager CDB plan DEFAULT_MAINTENANCE_PLAN via parameter
2020-03-13T22:00:03.067774+09:00
Begin automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
…
2020-03-14T07:00:00.017563+09:00
PDB01(3):Setting Resource Manager plan SCHEDULER[0x4D5E]:DEFAULT_MAINTENANCE_PLAN via scheduler window
PDB01(3):Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter

```

## 鍵の設定
PDBを新規に追加したあと、表領域を作成しようとすると以下のエラーになります

```
SQL> create pluggable database pdb02 admin user pdbadmin identified by xxxxx;

Pluggable database created.

SQL> alter  pluggable database pdb02 open;

Pluggable database altered.

SQL> alter session set container=pdb02;

Session altered.

SQL> create tablespace data datafile size 100m;
 create tablespace data datafile size 100m
*
ERROR at line 1:
ORA-28361: master key not yet set
```
PDBを追加したあとは、鍵情報を登録する必要があるようです

```
・DBのIDを確認します。
# dbcli list-databases
ID                                       DB Name    DB Type  DB Version           CDB        Class    Shape    Storage    Status        DbHomeID                                
---------------------------------------- ---------- -------- -------------------- ---------- -------- -------- ---------- ------------ ----------------------------------------
428eca54-c55a-475a-8394-35538e29cd75     DB19c      Si       19.6.0.0.200114      true       Oltp              ASM        Configured   74203a3f-d3bd-45c9-9cf4-ad7285d0fbc1    

・鍵を登録します
# PDB_NAME=pdb02
# dbcli update-tdekey -i 428eca54-c55a-475a-8394-35538e29cd75 -n ${PDB_NAME} -p
TDE Admin wallet password:
{
  "jobId" : "5d192cc2-3195-4463-aaaf-29f737180713",
  "status" : "Created",
  "message" : null,
  "reports" : [ ],
  "createTimestamp" : "March 14, 2020 09:37:15 AM JST",
  "resourceList" : [ ],
  "description" : "TDE update DB19c",
  "updatedTime" : "March 14, 2020 09:37:15 AM JST"
}

・ジョブの完了確認をします
# dbcli list-jobs
…
5d192cc2-3195-4463-aaaf-29f737180713     TDE update DB19c                                                            March 14, 2020 9:37:15 AM JST       Success   

・ジョブの中でなにやってるか確認します
# dbcli describe-job -i 5d192cc2-3195-4463-aaaf-29f737180713

Job details                                                      
----------------------------------------------------------------
                     ID:  5d192cc2-3195-4463-aaaf-29f737180713
            Description:  TDE update DB19c
                 Status:  Success
                Created:  March 14, 2020 9:37:15 AM JST
                Message:  

Task Name                                                                Start Time                          End Time                            Status    
------------------------------------------------------------------------ ----------------------------------- ----------------------------------- ----------
Closing auto login                                                       March 14, 2020 9:37:38 AM JST       March 14, 2020 9:37:42 AM JST       Success   
Opening wallet                                                           March 14, 2020 9:37:42 AM JST       March 14, 2020 9:37:49 AM JST       Success   
Rotate Master Key                                                        March 14, 2020 9:37:49 AM JST       March 14, 2020 9:37:53 AM JST       Success   
Closing wallet                                                           March 14, 2020 9:37:53 AM JST       March 14, 2020 9:37:56 AM JST       Success   

```

再度、表領域を作成するとできるようになります

```
SQL> alter session set container=pdb02;
SQL> create tablespace data datafile size 100m;

Tablespace created.
```

## プロファイル
DEFAULT PROFILEが厳しめです。

```
SQL> select resource_name,limit from dba_profiles where profile='DEFAULT' and resource_type='PASSWORD' order by 1;

RESOURCE_NAME                    LIMIT
-------------------------------- --------------------------------------------------
FAILED_LOGIN_ATTEMPTS            3
INACTIVE_ACCOUNT_TIME            UNLIMITED
PASSWORD_GRACE_TIME              7
PASSWORD_LIFE_TIME               60
PASSWORD_LOCK_TIME               1
PASSWORD_REUSE_MAX               5
PASSWORD_REUSE_TIME              365
PASSWORD_VERIFY_FUNCTION         ORA12C_STRONG_VERIFY_FUNCTION

8 rows selected.

```
アプリケーション接続用のユーザに関しては、独自のプロファイルを作って割り当てたほうがよさそうです

## 初期化パラメータ
既定でデフォルト以外に設定される初期化パラメータをアラートログから覗いてみます。

初期パラで確認しておいたほうが良いと思ったのは、

- コンソールから作成すると、db_unique_nameが別名でつけられる
- global_namesがtrueになってるので、任意名でデータベースリンクを作成した場合は変更する必要がある
- sql92_securityがTRUEになっているので、現行がFALSの場合は、権限を追加で与えなければいけないかもしれない
- db_domainにサブネット名が設定される。よってデフォルトのサービス名もドメイン名がついてる

(シェイプ・バージョン・エディションなどで変わると思いますが、この環境は19c(シングル)のEnterpriseです)

```
  processes                = 200
  cpu_count                = 2
  _enable_NUMA_support     = FALSE
  use_large_pages          = "only"
  pga_aggregate_limit      = 7680M
  nls_language             = "AMERICAN"
  nls_territory            = "AMERICA"
  filesystemio_options     = "setall"
  _file_size_increase_increment= 2044M
  _disable_interface_checking= TRUE
  sga_target               = 7680M
  control_files            = "+RECO/xxxx/CONTROLFILE/current.256.1034955591"
  db_block_checksum        = "FULL"
  db_block_size            = 8192
  encrypt_new_tablespaces  = "DDL"
  _db_writer_coalesce_area_size= 16M
  compatible               = "19.0.0.0"
  log_archive_format       = "%t_%s_%r.dbf"
  log_buffer               = 16M
  db_files                 = 1024
  db_create_file_dest      = "+DATA"
  db_create_online_log_dest_1= "+RECO"
  db_recovery_file_dest    = "+RECO"
  db_recovery_file_dest_size= 255G
  _gc_undo_affinity        = TRUE
  _gc_policy_time          = 20
  fast_start_mttr_target   = 300
  db_lost_write_protect    = "TYPICAL"
  _datafile_write_errors_crash_instance= FALSE
  undo_tablespace          = "UNDOTBS1"
  undo_retention           = 900
  db_block_checking        = "FULL"
  remote_login_passwordfile= "EXCLUSIVE"
  audit_sys_operations     = TRUE
  db_domain                = "xxxx.xxx.oraclevcn.com"
  global_names             = TRUE
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=XXXXXDB)"
  local_listener           = "LISTENER_XXXX"
  session_cached_cursors   = 100
  cursor_sharing           = "EXACT"
  parallel_execution_message_size= 16384
  _fix_control             = "18960760:on"
  audit_file_dest          = "/u01/app/oracle/admin/XXXX_xxxx/adump"
  audit_trail              = "DB"
  db_name                  = "XXXX"
  db_unique_name           = "XXXX_XXXX"
  open_cursors             = 1000
  os_authent_prefix        = "ops$"
  sql92_security           = TRUE
  parallel_threads_per_cpu = 2
  pga_aggregate_target     = 3840M
  enable_ddl_logging       = FALSE
  control_management_pack_access= "DIAGNOSTIC+TUNING"
  diagnostic_dest          = "/u01/app/oracle"
  enable_pluggable_database= TRUE
```

## 接続が微妙に遅い

BEQでもリスナー経由の接続でも、sqlplusで接続するとき、体感できるくらいに微妙に遅い。
なんでかと思ってたら、通信暗号化されてるためだった。

```
$ cd $ORACLE_HOME/network/admin
$ cat sqlnet.ora 
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))
SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA1)
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)
```

sqlnet.oraをmvしてみると早くなる。が、通信暗号化されなくなるので注意
※ENCRYPTION_WALLET_LOCATIONのエントリまで消してしまうと、表領域暗号化に利用されるマスターキーにもアクセスできなくなるので注意

```
■ 接続暗号化有効時
$ date '+%Y/%m/%d %H:%M:%S.%N'; sqlplus -s -L <接続文字列> <<EOF
select to_char(systimestamp,'yyyy/mm/dd hh24:mi:ss.ff3') from dual;
exit;
EOF
2020/08/27 10:52:14.278019155

TO_CHAR(SYSTIMESTAMP,'Y
-----------------------
2020/08/27 10:52:14.740

→ 0.5秒くらい

■ 接続暗号化無効時
$ date '+%Y/%m/%d %H:%M:%S.%N'; sqlplus -s -L <接続文字列> <<EOF
select to_char(systimestamp,'yyyy/mm/dd hh24:mi:ss.ff3') from dual;
exit;
EOF
2020/08/27 10:53:00.052921925

TO_CHAR(SYSTIMESTAMP,'Y
-----------------------
2020/08/27 10:53:00.122

→ 0.07秒くらい
```

[調べたところ](https://support.oracle.com/knowledge/Oracle%20Database%20Products/2000474_1.html)、通信暗号化すると新規接続時の認証が遅くなるのは仕様みたいですね。