はじめに
DBaaSを触ってみて、きづいたこと・確認しておいたほうがよいことをざっくばらんに書いてみる
ゴミがある。。
2021年1月に作成したイメージを確認したところ、再発してました。。
# 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月確認時には消えていました。
2020年7月時点でVMのDBCSを作成したら、tmpfsとして/tmpがマウントされてました。
# 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ファイルが存在しない状態でした。
$ 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は以前からかどうかは未確認。
# 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.*
[2021年1月追記]
DBCSのOS Update マニュアルに、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作成コンソールにも注意書きがでるので驚きはないのですが、
たとえば、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インスタンス作成するときにタイムゾーンを初期設定する機能がでました。
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秒くらい
調べたところ、通信暗号化すると新規接続時の認証が遅くなるのは仕様みたいですね。