私はここでつまづいた！ Oracle database 11g から 12cへのアップグレードと Oracle Database 12c の新機能@2015 10-17 jpoug

Copyright © 2015 NTT DATA INTELLILINK Corporation
2015年10月17日(土)
NTTデータ先端技術株式会社オラクル事業部
吉本貴幸
私はここでつまづいた！
Oracle Database 11g から 12c へのアップグレードと
Oracle Database 12c の新機能

2Copyright © 2015 NTT DATA INTELLILINK Corporation
目次
1. 案件概要
2. 作業概要
3. これで完璧！（？）12cアップグレード
4. ここで私はつまづいた！12c新機能・変更点
 CDB/PDB
 Flex ASM
 統合監査
5. 質疑応答
• アップグレード手順
• 作業中につまづいた点
• 12cでの変更点
新機能・変更点との付き合い方
• 注意すべき点
• 対処法

Copyright © 2015 NTT DATA INTELLILINK Corporation 3
1. 案件概要

1. 案件概要
【お客様】大手通信キャリア様
【概要】現行システムのBCPサイトを11gから12cへバージョンアップ！!
【目的】 12cの恩恵を受けれる構成へ（障害対策、効率化、サポートポリシーへの対応）
同期
BCP
11g
Exadata
X4-2
Half Rack
現行
Exadata
X3-2 + X4-2
Half Rack
11g
DB×31
（増殖中）
動作確認用DB
EMリポジトリDB
■案件について

1. 案件概要
• InfiniBand Switch 36 バージョン: 2.1.3-4 ⇒ 2.1.5-1
InfiniBand Switch
• Oracle Database: 11.2.0.3.23 ⇒ 12.1.0.2.7
• Grid Infrastructure: 11.2.0.3.23 ⇒ 12.1.0.2.7
• Storage Server Software: 11.2.3.3.0 ⇒12.1.2.1.1
Database Server
• Storage Server Software: 11.2.3.3.0 ⇒12.1.2.1.1
Storage Server
U19
U18
U24
U23
：
Database Server ×4
Storage Server ×7
U22 InfiniBand Switch
U21 Cisco Catalyst
U20 InfiniBand Switch
U42
スイッチ拡張領域U41
U40
拡張領域
（使用不可）
U39
U08
U07
U06
U05
U04
U17
U16
U15
U14
U11
U10
U09
U13
U12
U03
U02
U01 InfiniBand Switch (未使用)
■アップグレード対象となるExadataコンポーネント
当時最新の QFSDP (Apr 2015) を適用
Exadata X4-2 Half Rack
Oracle Linux
5.9 ⇒ 6.6

2. 作業概要

2. 作業概要
■一般的な RAC データベースのアップグレード
Grid Infrastructure
Oracle Database
Grid Infrastructure
Upgrade
Oracle Database
Install
Database Upgrade
下層レイヤーから
順番に上げていくバイナリ
データベース
アップグレード新規インストール

2. 作業概要
■今回採用した手順
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c アップグレード
12c
新機能実装
単体/結合
試験
12c 新機能
事前調査
システム
バックアップ
事前作業

2. 作業概要
■今回採用した手順～背景・所要時間～
事前
調査
システム
バックアップ
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c
新機能実装
単体/結合
試験
 【期間短】スケジュール上、3週間程度で作業完了の必要
 【該当手順あり】本環境は Note 1681467.1 に該当
 【リスク小】アップグレード対象 DB は動作確認用と EM リポジトリ用のみ
 【復旧方針決定済】失敗した際はシステムバックアップから復旧
12c アップグレード
12c 新機能
 DB Server 4台
 Storage Server 7台
 InfiniBand Switch 2台
⇒全停止OK
Storage Server Software の
アップグレードは GI/DB の後で OK
（機能面での制限のみ）
事前作業
3:205:404:00 0:40
⇒事前調査に時間をかけず Try & Error で作業を進める方針
DB 数により時間増減

→ Oracle Universal Installer（OUI) を使用
工程中分類内容
作業
サーバ
所要
時間
要事前
停止
作業中
停止
Pre-upgrade
事前チェック • runcluvfy.sh で要件を満たしているか確認 DB #1 0:30 - -
root ログインを許可一時的に root ログイン拒否設定を解除 DB #1-4 0:15 - -
インストールディレクトリ作成
GI 12c インストール先ディレクトリを作成
• /u01/app/12.1.0.2/grid/
DB #1-4 - - -
Upgrade
アップグレード
OUI を使用して GI 12c へのアップグレードを実施
• MGMTDB も自動で作成される
DB #1 1:30 - -
PSU 適用
OUI の rootupgrade.sh 実施前に
GRID_HOME へ Opatch にて PSU 適用
DB #1-4 0:30 - -
rootupgrade.sh OUI の指示に従い rootupgrade.sh 実施 DB #1-4 1:00 -
GI
(rolling)
Post-upgrade 環境変数参照先変更
grid ユーザの環境変数変更
• ORACLE_HOME=/u01/app/12.1.0.2/grid
DB #1-4 0:15 - -
■Grid Infrastructure Upgrade 手順概要
事前
調査
システム
バックアップ
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c
新機能実装
単体/結合
試験
3:205:404:00 0:40
Exachk
OUI

→ Oracle Universal Installer（OUI) を使用
■Oracle Database Install 手順概要
事前
調査
システム
バックアップ
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c
新機能実装
単体/結合
試験
作業
サーバ
所要
時間
要事前
停止
作業中
停止
Pre-upgrade インストールディレクトリ作成
ORACLE_HOME用ディレクトリ作成
• /u01/app/oracle/product/12.1.0.2/dbhome_1
DB #1-4 - - -
Upgrade
インストール OUI を使用して Oracle 12c のインストールを実施 DB #1 0:30 - -
PSU 適用 ORACLE_HOME へ OPatch にて PSU 適用 DB #1-4 0:10 - -
OUI
 OPatch ・・・パッチ適用
 rootcrs ・・・ Clusterware の起動・停止
 datapatch ・・・パッチ適用後に必要な SQL 処理を全インスタンスで自動実行
OPatchauto ・・・全ノードの GRID_HOME と ORACLE_HOME の両方にパッチを自動適用 GRID_HOME から実行
catbundle.sql は
12.1.0.2 より非推奨
3:205:404:00 0:40

→ patchmgr, dbnodeupdate.sh を使用
■Exadata Storage Server Software Upgrade 手順概要
事前
調査
システム
バックアップ
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c
新機能実装
単体/結合
試験
作業
サーバ
所要
時間
要事前
停止
作業中
停止
Pre-upgrade
NFS アンマウント NFS アンマウント DB #1-4 - - -
事前チェック
• SNMP 設定確認
• OS ファイル確認
全機器 0:15 - -
停止 DB/GI 停止 DB #1 0:10 - -
Upgrade パッチ適用
patchmgr で Storage Server にパッチ適用 DB #1 2:45
DB/GI
/celld
Storage Server
(non-rolling)
dbnodeupdate.sh で DB Server にパッチ適用 DB #1-4 0:30 DB/GI
DB Server
(non-rolling)
patchmgr で InfiniBand Switch にパッチ適用 DB #1 1:30 -
IB Switch
(rolling)
Post-upgrade
事後確認
• SNMP 設定確認
• OS ファイル確認
全機器 0:15 - -
root ログイン拒否設定 root ログイン拒否を再設定 DB #1-4 0:15 - -
Exachk
Exachk
utility
3:205:404:00 0:40

→ Database Upgrade Assistant（DBUA）を使用
■Database Upgrade 手順概要
事前
調査
システム
バックアップ
Grid
Infrastructure
Upgrade
Oracle
Database
Install
Exadata
Software
Upgrade
Database
Upgrade
12c
新機能実装
単体/結合
試験
作業
サーバ
所要
時間
要事前
停止
作業中
停止
Pre-upgrade
DB バックアップ対象 DB を RMAN バックアップ DB #1 0:15 × 2 - -
アップグレード前ツール実行
preupgrd.sql を実行
• processes パラメータを 300 に変更
DB #1 0:10 - -
listener_networks 無効化
DBUA 実行前に一部パラメータ無効化
• listener_networks
DB #1 - - -
Upgrade アップグレード DBUA 実行 DB #1
1:30 (動作確認用DB)
1:10 (EMリポジトリDB)
- DB
Post-upgrade
環境変数の参照先変更環境変数の参照先を 12c 用へ変更 DB #1-4 - - -
listener_networks 有効化
無効化したパラメータを元の値に戻す
• listener_networks
DB #1 - - -
パッチ適用後の SQL 処理 datapatch 実行 DB #1 < 0:05 - -
DBUA
Exachk
3:205:404:00 0:40

初期化パラメータアップグレード前アップグレード後
parallel_max_servers 135 204
_backup_disk_bufsz 1048576 0
_backup_file_bufsz 1048576 0
_backup_disk_bufcnt 64 0
_backup_file_bufcnt 64 0
_gc_read_mostly_locking FALSE TRUE
_kgl_cluster_lock_read_mostly TRUE FALSE
_kill_diagnostics_timeout 140 60
_lm_rcvr_hang_allow_time 140 70
local_listener (HOST=<管理用VIP>) xxx.xxx.xx.x（HOST指定がIPに）
listener_networks -
(( NAME=net3)(LOCAL_LISTENER=(DESCRIPTI
ON=(ADDRESS=(PROTOCOL=TCP)(HOST=xx.x
xx.xx.xxx)(PORT=xxxx)))))
DBUAの仕様
■アップグレード作業の注意点
DB初期化パラメータが変更されてしまう
DB

VIPリソース名が変更された
■Clusterware 変更点～その1～
Network3
業務用
VIP名: <業務用VIP>
VIPリソース名: ora.<業務用VIP>.vip
eth1 eth2 eth4 eth5
Network1
管理用
VIP名: <管理用VIP>
VIPリソース名: ora.<管理用VIP>.vip
Network2
内部通信用（InfiniBand）
VIP名: <内部用VIP>
VIPリソース名: ora.<内部用VIP>.vip
ib0 ib1
RAC用のネットワークインタフェース構成
GI

ora.<ノード1>.vip
1 ONLINE ONLINE <ノード1>
ora.<ノード1>_3.vip
…
ora.<ノード4>_3.vip
ora.<業務用VIP1>.vip
…
ora.<業務用VIP4>.vip
GIアップグレード前 GIアップグレード後
リネームは？ Vip再作成は？
GI

ora.<ノード名>_<ネットワーク番号>.vip
[grid@<ノード1>~]$ crsctl stat res ora.<ノード1>_3.vip –p
NAME=ora.<ノード1>_3.vip
TYPE=ora.cluster_vip_net3.type
…
USR_ORA_ENV=
USR_ORA_VIP=<業務用VIP1>
…
VIPが存在します: ネットワーク番号3、ホスティング・ノード<ノード1>
VIP名: <業務用VIP1>
VIP IPv4アドレス: xx.xxx.xx.xxx
…
GI 12.1.0.1 から VIPリソース名の書式が変更
対処不要
・/etc/hosts
・tnsnames.ora
・listener_networks
などの初期化パラメータ
VIPリソース名での利用なし
GI

srvctl config scan
SCAN名: <SCAN名>、ネットワーク:
1/xxx.xxx.xx.x/xxx.xxx.xxx.xxx/bondeth0
SCAN VIP名: scan1、IP: /<SCAN名>/xxx.xxx.xx.xx
srvctl config scan
SCAN名: <SCAN名>、ネットワーク: 1
サブネットIPv4:
xxx.xxx.xx.x/xxx.xxx.xxx.xxx/bondeth0, static
サブネットIPv6:
SCAN 0 IPv4 VIP: xxx.xxx.xx.xx
SCAN VIPは有効です。
SCAN VIPはノード: で個別に有効になっています
SCAN VIPはノード: で個別に無効になっています
SCAN VIP 名の項番が０から始まるように変更
対処不要
GI

●ネットワーク起動
crsctl start res ora.net2.network ⇒×
srvctl start vip { -n <ノード名> | -i <VIP名> } ⇒○
※事前にネットワークリソースに対してVIPを作成しておく必要があります。
●リスナーのリソース属性変更
crsctl modify res ora. <リスナー名>.lsnr -attr
“USR_ORA_ENV=ORACLE_BASE=/u01/app/grid“ ⇒×
srvctl setenv listener -listener <リスナー名> -t “ORACLE_BASE=/u01/app/grid” ⇒○
GI 2.1.0.1 からの
仕様変更
GI 12.1.0.1 からの
仕様変更
crsctl コマンドではなく srvctl より実施
GI

Clusterware ログ出力先変更（12.1.0.2～）
• 多くのログが下記ディレクトリに出力されるように
$GRID_BASE/diag/crs/<ノード名>/crs/trace
• CHM（Cluster Health Monitor）のログ名が変更
$GRID_HOME/log/<ノード名>/crflogd/crflogd.log
$GRID_HOME/log/<ノード名>/crfmond/crfmond.log
↓
$GRID_BASE/diag/crs/<ノード名>/crs/trace/ologgerd.trc
$GRID_BASE/diag/crs/<ノード名>/crs/trace/osysmond.trc
変更
⇒詳細は Note 1770194.1 を参照
GI

MGMTDB およびリスナーが作成される
[grid@<ノード1> ~]$ crsctl status resource -t
-------------------------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
-------------------------------------------------------------------------------------------------
Local Resources
-------------------------------------------------------------------------------------------------
：
-------------------------------------------------------------------------------------------------
Cluster Resources
-------------------------------------------------------------------------------------------------
：
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE <ノード1> STABLE
ora.MGMTLSNR
1 ONLINE ONLINE <ノード1> xxx.xxx.xxx.xxx xxx.
xxx.xxx.xxx xxx.xxx.x.x
,STABLE
：
ora.mgmtdb
1 ONLINE ONLINE <ノード1> Open,STABLE
：
-------------------------------------------------------------------------------------------------
• Grid Infrastructure Management Repository
 CHM などのデータが格納される
• 所有者：grid
• PDB 1つを持つ CDB
• いずれか1ノードで稼働
• メンテナンス（バックアップ等）不要
• 12.1.0.2～必須
MGMTDB とは
GI

INTERNAL_STATE が表示される
• STARTING: 起動中
• STOPPING: 停止中
• CLEANING: クリーンアップ中
• STABLE: アクションなし
[grid@<ノード1> ~]$ crsctl status resource -t
-------------------------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
-------------------------------------------------------------------------------------------------
Local Resources
-------------------------------------------------------------------------------------------------
：
-------------------------------------------------------------------------------------------------
Cluster Resources
-------------------------------------------------------------------------------------------------
：
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE <ノード1> STABLE
ora.MGMTLSNR
1 ONLINE ONLINE <ノード1> xxx.xxx.xxx.xxx xxx.
xxx.xxx.xxx xxx.xxx.x.x
,STABLE
：
ora.mgmtdb
1 ONLINE ONLINE <ノード1> Open,STABLE
：
-------------------------------------------------------------------------------------------------
GI

■その他、変更点
ILOM アップグレード
• 画面レイアウト
• バックアップ時に指定するパスフレーズの最小文字数が16字に
変更点
Exadata SW

■その他、作業中につまづいた点
OS アップグレード後、GUI ツールが起動できない
必要な手順をきちんと行う
対処
これまで通りの手順では X が飛ばなくなった
問題
• DISPLAY 環境変数を設定する
export DISPLAY=<作業用PCのIPアドレス>:0.0
• XLaunch にて Xming 起動時に「No Access Control」にチェックを入れる
• Linux にログイン後、Switch User（su）しない
Exadata SW？

検討項目検討結果
DB 構成
マルチテナント（CDB/PDB）
マルチテナント化によるハードウェアや管理コストの削減といったメ
リットを享受できるため、マルチテナントを採用する
ASM 構成
Flex ASM を利用する
可用性を考慮し、Flex ASM を採用する
監査モード
統合監査を使用する
管理性、性能影響を考慮し、統合監査を採用する
クラスタ構成
自動データ最適化
拡張データ型
Global Data Service
Database In-Memory
Data Redaction
Oracle プロセスの
マルチスレッド化

 CDB/PDB
 Flex ASM
 統合監査

■CDB/PDB ～概要～
• DB統合による集約率向上
 メモリ
 バックグラウンドプロセス
 データファイル
• 管理コスト削減
 CDB単位での管理
• アップグレード・パッチ適用
• バックアップ・リストア
• DataGuard
 移行、クローニング
メリット
DB
Pluggable
Database
Container Database

CDB1
pdb_srv
pdb
cdb_srv
動作確認用として CDB/PDB 単位の
サービス作成
RMAN
PDB
接続
■CDB/PDB ～サービスの注意点～
APからの接続が前提
- サービスを利用
DB

CDB1
pdb_srv
pdb
ノード1
cdb_srv
CDB2
pdb_srv
pdb
ノード2
cdb_srv
CDB3
pdb_srv
pdb
ノード3
cdb_srv
CDB4
pdb_srv
pdb
ノード4
cdb_srvサービス
CDB
PDB
DB

CDB1
pdb
ノード1
MOUNTED
試験内容
CDB の再起動時に PDB が
MOUNTED ステータスとなることを確認する
※PDBの起動ステータスは保存していない状態
DB

あれ !?
DB

試験結果
CDB1
pdb
ノード1
READWRITE
CDB1
pdb
ノード1
MOUNTED
CDB再起動
srvctl stop database
srvctl start database
DB

CDB1
pdb_srv
pdb
cdb_srv
優先インスタンス: CDB1（ノード上のCDBインスタンスを指定）
使用可能インスタンス: CDB2, CDB3, CDB4
管理ポリシー: AUTOMATIC
優先インスタンス: CDB1 （ノード上のCDBインスタンスを指定）
使用可能インスタンス: CDB2, CDB3, CDB4
管理ポリシー: AUTOMATIC
DB

PDBのサービスの依存関係により、PDBが READ WRITE に!?
原因
AUTOMATIC: DB起動時にサービスも自動起動
MANUAL : DB起動時にサービスは自動起動しない
管理ポリシー
DB
CDB
pdb_srv
pdb
現在の状態
CDB
pdb_srv
pdb
A) サービス起動時 B) PDBオープン時
CDB
pdb_srv
pdb
PDBも
オープン
PDBのみ
オープン

～運用面～
※デフォルトサービスは管理タスクでの使用を想定しているため、カスタマイズは不可
PDB のサービスは、管理ポリシーを AUTOMATIC から MANUAL に切り替える
対処
1. PDB のサービスは管理ポリシー MANUAL で作成
2. CDB 起動後、PDB を手動で起動 or PDB のステータスを事前に保存しておく
ことで自動起動
3. PDB 起動後、PDB のサービスを手動で起動
DB

■CDB/PDB関連問題
リスナー経由で連続接続・切断時にORA-12520/12516エラーで接続できなくなる
1. CDBにて、processes=300（デフォルト値）
2. リスナー経由で接続・切断を繰り返す
for ((i=0; i<1000000; i++))
do
sqlplus -S -L sys/<パスワード>@<ノード名>:<ポート番号>/<サービス名> as sysdba <<END
select instance_name from v$instance;
END
done
再現条件
以下の場合は再現せず
• アップグレード前（11.2.0.3）
• non-CDB
• processes=500 に増加
• ローカル接続
サービス経由接続の
ロードバランスの状況を
見たかっただけなのに…
ERROR:
ORA-12516: TNS:listener could not find available handler with matching protocol stack
SP2-0751: Unable to connect to Oracle. Exiting SQL*Plus
ERROR:
ORA-12520: TNS:listener could not find available handler for requested type of server
SP2-0751: Unable to connect to Oracle. Exiting SQL*Plus
NW関連のエラー
最大接続数
DB

事象発生の
メカニズム
LISTENER
接続：即時に認識
切断：service_update
まで認識しない
現在のプロセス数＋新規プロセス数 → processes と判定
（事象自体は Note 1733296.1 に該当）
PDB のプロセス数を考慮して、processes を設定する
対処
複数のDBをPDBとして集約
↓
PDB のプロセスもカウント
CDBでのみ
発生した理由
LREG
DB
PDB PDB
CDB

 CDB/PDB
 Flex ASM
 統合監査

■Flex ASM ～概要と導入の背景～
●クラスタ内の3ノード上でのみASMインスタンスが稼働！（デフォルト設定）
⇒従来: クラスタを構成する全ノードでASMインスタンスを構成する必要あり
[2ノードRAC構成]
ASMインスタンス
2つ起動
●クラスタ内、いずれかのASMインスタンスにリスナー経由で接続！
⇒従来: ローカルのASMインスタンスにのみ接続
リソースの
節約に！
GI
DBA DBA DBB
ASM
DBB
ASM
DBB
ASM
ASM
クラスタ
ASMインスタンスを
DBが共有

●単一のASMインスタンス障害時、DBインスタンスは停止しない！
⇒従来: 当該ノード上のDBインスタンス停止
可用性の
向上！
※FlexASM 構成後、通常の ASM へ変更は不可です
GI
ASM
クラスタ
DBA DBA DBB DBB
ASM
DBB
ASMASM ×
フェイルオーバー

■Flex ASM ～導入・確認方法～
・DB停止
・OCR/SPFILE/パスワードファイル格納先のディスクグループを COMPATIBLE.ASM=12.1 以上へ
・パスワードファイルを ASM 上に配置
------------------------------------------------------------------------------------------
【DB】 orapwd INPUT_FILE=‘$ORACLE_HOME/dbs/orapw<EMリポジトリDB>1‘
FILE='+DATA/<EMリポジトリDB>/orapw<EMリポジトリDB>' DBUNIQUENAME='<EMリポジトリDB>‘
【ASM】 orapwd INPUT_FILE=‘$GRID_HOME/dbs/orapw+ASM'
FILE='+DATA/ASM/orapwasm' ASM=y
------------------------------------------------------------------------------------------
・OCR/SPFILE が ASM 上に配置されていることを確認
・ASMCA 「Convert to Oracle Flex ASM」より
FlexASM へ変換
導入方法
ASMリスナーが作成される →
GI

$ /u01/app/12.1.0.2/grid/bin/asmcmd showclustermode
ASM cluster : Flex mode enabled
$ /u01/app/12.1.0.2/grid/bin/srvctl config asm
ASMホーム: <CRS home>
パスワード・ファイル: +DATA/ASM/orapwasm
ASMリスナー: LISTENER
ASMインスタンス数: 3
クラスタASMリスナー: ASMNET1LSNR_ASM
確認方法
GI

--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr
ONLINE ONLINE <ノード1> STABLE
ora.DATA.dg
ONLINE OFFLINE <ノード3> STABLE
…
ora.asm
1 ONLINE ONLINE <ノード2> Started,STABLE
GI

■Flex ASM ～表示問題～
ora.DATA.dg
ONLINE OFFLINE <ノード3> STABLE
●ディスクグループの属性値による影響
AUTO_START=always
START_DEPENDENCIES=pullup:always(ora.asm) hard(ora.asm)
⇒仕様上の動作のため、問題なし
GI
ASMとの依存性高
Target: ONLINE
ASMインスタンス稼働数 3
State: OFFLINE

Flex ASM のため ASMインスタンスは
3ノード上で稼働中のため
ターゲットのステータスはオールグリーンにならない
GI
■Flex ASM ～EM からの監視～

 CDB/PDB
 Flex ASM
 統合監査

■統合監査～概要と導入の背景～
監査ログが1つのビューに集約される
↓
管理が簡素化
これまでOSファイルへの
大量出力に悩まされていた
キュー書き込みモード
↓
監査全体のパフォーマンス向上
従来
• DBA_AUDIT_TRAIL
• DBA_FGA_AUDIT_TRAIL
• OSファイル
• OSファイル（XML形式）
UNIFIED_AUDIT_TRAIL
メリット1 メリット2
DB
SGA
SGAキュー
SYSAUX
表領域
監査ログ
自動Flush

■統合監査～導入・確認方法～
SQL> select value from v$option where parameter = 'Unified Auditing';
VALUE
------------------------------
TRUE
確認方法
・DB停止
・make コマンド
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME
・DB起動
導入方法
※RACの場合、各ノードで
実施する必要あり
DB

■監査関連の問題
:
Jun 1 04:20:45 <ノード1> Oracle Audit[71246]: LENGTH : '205' ACTION :[55] 'begin
dbms_application_info.set_module(:1 , :2 ); end; ' DATABASE USER:[7] 'ASMSNMP' PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[7] 'unknown' STATUS:[1] '0' DBID:[0] ''
Jun 1 04:20:45 <ノード1> Oracle Audit[71246]: LENGTH : '155' ACTION :[6] 'COMMIT' DATABASE USER:[7]
'ASMSNMP' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[7] 'unknown' STATUS:[1] '0'
DBID:[0] ''
Jun 1 04:20:45 <ノード1> Oracle Audit[71246]: LENGTH : '322' ACTION :[171] ' SELECT g.name, d.name,
d.mode_status FROM v$asm_disk_stat d, v$asm_diskgroup_stat g WHERE d.group_number != 0 AND
g.group_number != 0 AND d.group_number = g.group_number ' DATABASE USER:[7] 'ASMSNMP'
PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[7] 'unknown' STATUS:[1] '0' DBID:[0] ''
:
ASM インスタンスの
監査ログっぽい！
OSファイルに監査ログ！
統合監査を有効化したのに！
GRID_HOME で統合監査を
有効化していない
気付き1
/var/log/asmaudit.log に
これまで出力されていた
気付き2
GRID_HOME でも
統合監査を有効化してみよう
プラン1
syslog 周りの設定を
見直してみよう
プラン2
OS アップグレード後、/var/log/messages への出力が増加
Exadata SW

GRID_HOME でも統合監査を有効化してみよう
プラン1
調査の結果
ポジティブな情報ネガティブな情報
GRID_HOME でも
統合監査は有効化可能！
ASM インスタンスには
UNIFIED_AUDIT_TRAIL ビューが
ありません！
GRID_HOME
ロック解除・再ロックが必要。
Clusterware 再起動を伴う。
元ビューからexportして
他DBにimportして結合する
必要あり。
GI

統合監査は
ORACLE_HOME で
使いましょう
GI
・・・そもそもGRID_HOMEで使用しても
統合監査のメリットないし

syslog 周りの設定を見直してみよう
プラン2
OS アップグレードで何か変わっていないか
OL 6.0 より syslog ではなく rsyslog が標準採用された
変更点
設定ファイルが変更されたが、設定内容は引き継がれていなかった
# cat /etc/rsyslog.conf
：
*.info;mail.none;authpriv.none;cron.none;local0.none /var/log/messages
：
local0.info /var/log/asmaudit.log
rsyslog でも syslog 同様の
リダイレクト設定を実施
対処
Exadata SW

新機能
変更点
問題点対処法区分
CDB/PDB
優先インスタンスを指定した PDB サービスが存在する
場合、CDB 再起動時に PDB が自動起動してしまう
PDB のサービスは、管理ポリシーを
AUTOMATIC ではなく MANUAL として運用する
DB
リスナー経由で連続切断・接続するとエラー発生
CDB だけでなく PDB のプロセス数も考慮して
processes を設定する
DB
Flex ASM DiskGroup の Target が正常に表示されない DiskGroupの属性値による仕様のため対処不要 GI
監査 ASM インスタンスの監査ログが OS に出力される
rsyslog の設定を行う
（統合監査は ORACLE_HOME でのみ使用）
Exadata SW
（DB/GI）
■新機能・変更点とその問題点、対処法

私はここでつまづいた！ Oracle database 11g から 12cへのアップグレードと Oracle Database 12c の新機能@2015 10-17 jpoug

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to 私はここでつまづいた！ Oracle database 11g から 12cへのアップグレードと Oracle Database 12c の新機能@2015 10-17 jpoug

Similar to 私はここでつまづいた！ Oracle database 11g から 12cへのアップグレードと Oracle Database 12c の新機能@2015 10-17 jpoug (20)

Recently uploaded

Recently uploaded (12)

私はここでつまづいた！ Oracle database 11g から 12cへのアップグレードと Oracle Database 12c の新機能@2015 10-17 jpoug