私はここでつまづいた！ oracle database 11g から 12cへのアップグレードと...

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

ExadataX4-2

Half Rack

現行

ExadataX3-2 + X4-2Half Rack

11g

DB×31（増殖中）

動作確認用 DBEM リポジトリ 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

U19U18

U24U23

：

Database Server ×4

Storage Server ×7

U22 InfiniBand SwitchU21 Cisco CatalystU20 InfiniBand Switch

U42 スイッチ拡張領域U41U40

拡張領域（使用不可）

U39

U08U07U06U05U04

U17U16U15U14

U11U10U09

U13U12

U03U02U01 InfiniBand Switch ( )未使用

■ アップグレード対象となる Exadata コンポーネント

当時最新の QFSDP (Apr 2015) を適用Exadata X4-2 Half Rack

Oracle Linux5.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. 作業概要

■ 今回採用した手順　～背景・所要時間～

事前　調査

システムバックアップ


Oracle Database Install


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 手順概要

事前　調査





Database Upgrade

12c 新機能実装

単体/結合試験

3:205:404:00 0:40

Exachk

OUI



→ Oracle Universal Installer （ OUI) を使用

■Oracle Database Install 手順概要

事前　調査





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 手順概要

事前　調査





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 手順概要

事前　調査





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 #11: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 70local_listener (HOST=<管理用 VIP>) xxx.xxx.xx.x （ HOST 指定が IP に）

listener_networks -(( NAME=net3)

(LOCAL_LISTENER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xx.xxx.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 1 ONLINE ONLINE <ノード 1>

…

ora.<ノード 4>.vip

1 ONLINE ONLINE <ノード 4>ora.<ノード 4>_3.vip 1 ONLINE ONLINE <ノード 4>

ora.<ノード 1>.vip 1 ONLINE ONLINE <ノード 1>ora.< 業務用 VIP1>.vip

1 ONLINE ONLINE <ノード 1>

…

ora.<ノード 4>.vip 1 ONLINE ONLINE <ノード 4>ora.< 業務用 VIP4>.vip

1 ONLINE ONLINE <ノード 4>

GI アップグレード前

GI アップグレード後

リネームは？

Vip再作成は？

GI



ora.<ノード名 >_< ネットワーク番号 >.vip

[grid@<ノード 1>~]$ crsctl stat res ora.<ノード 1>_3.vip –pNAME=ora.<ノード 1>_3.vipTYPE=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 SCAN VIP名 : scan2 、 IP: /<SCAN名 >/xxx.xxx.xx.xx SCAN VIP名 : scan3 、 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.xxSCAN VIP は有効です。 SCAN VIP はノード : で個別に有効になっています SCAN VIP はノード : で個別に無効になっています SCAN 1 IPv4 VIP: xxx.xxx.xx.xx SCAN VIP は有効です。 SCAN VIP はノード : で個別に有効になっています SCAN VIP はノード : で個別に無効になっています SCAN 2 IPv4 VIP: xxx.xxx.xx.xxSCAN VIP は有効です。 SCAN VIP はノード : で個別に有効になっています SCAN VIP はノード : で個別に無効になっています

SCAN VIP 名の項番が０から始まるように変更

■Clusterware 変更点　～その 2 ～対処不要

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> STABLEora.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



■Clusterware 変更点　～その 6 ～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> STABLEora.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 ？


4. ここで私はつまづいた！ 12c 新機能・変更点



検討項目検討結果

DB 構成マルチテナント（ CDB/PDB ）マルチテナント化によるハードウェアや管理コストの削減といったメリットを享受できるため、マルチテナントを採用する

ASM 構成 Flex ASM を利用する可用性を考慮し、 Flex ASM を採用する

監査モード統合監査を使用する管理性、性能影響を考慮し、統合監査を採用する

クラスタ構成

自動データ最適化

拡張データ型

Global Data ServiceDatabase In-Memory

Data RedactionOracle プロセスのマルチスレッド化



CDB/PDBFlex ASM統合監査



■CDB/PDB 　～概要～

• DB 統合による集約率向上メモリバックグラウンドプロセスデータファイル

• 管理コスト削減 CDB 単位での管理

• アップグレード・パッチ適用

• バックアップ・リストア• DataGuard

移行、クローニング

メリット

DB

PluggableDatabase

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 databasesrvctl 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 stackSP2-0751: Unable to connect to Oracle. Exiting SQL*Plus

ERROR:ORA-12520: TNS:listener could not find available handler for requested type of serverSP2-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



■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 showclustermodeASM cluster : Flex mode enabled

$ /u01/app/12.1.0.2/grid/bin/srvctl config asmASMホーム : <CRS home>パスワード・ファイル : +DATA/ASM/orapwasmASM リスナー : LISTENERASM インスタンス数 : 3クラスタ ASM リスナー : ASMNET1LSNR_ASM

確認方法

GI



--------------------------------------------------------------------------------Name Target State Server State details --------------------------------------------------------------------------------Local Resources--------------------------------------------------------------------------------ora.ASMNET1LSNR_ASM.lsnr ONLINE ONLINE <ノード 1> STABLE ONLINE ONLINE <ノード 2> STABLE ONLINE ONLINE <ノード 3> STABLE ONLINE ONLINE <ノード 4> STABLEora.DATA.dg ONLINE ONLINE <ノード 1> STABLE ONLINE ONLINE <ノード 2> STABLE ONLINE OFFLINE <ノード 3> STABLE ONLINE ONLINE <ノード 4> STABLE

…ora.asm 1 ONLINE ONLINE <ノード 2> Started,STABLE 2 ONLINE ONLINE <ノード 1> Started,STABLE 4 ONLINE ONLINE <ノード 4> Started,STABLE

GI



■Flex ASM 　～表示問題～

ora.DATA.dg ONLINE ONLINE <ノード 1> STABLE ONLINE ONLINE <ノード 2> STABLE ONLINE OFFLINE <ノード 3> STABLE ONLINE ONLINE <ノード 4> STABLE

●ディスクグループの属性値による影響

AUTO_START=alwaysSTART_DEPENDENCIES=pullup:always(ora.asm) hard(ora.asm)

⇒仕様上の動作のため、問題なし

GI

ASM との依存性高

Target: ONLINE

ASM インスタンス稼働数 3

State: OFFLINE



Flex ASM のため ASM インスタンスは

3ノード上で稼働中のため

ターゲットのステータスはオールグリーンにならない

GI■Flex ASM 　～ EM からの監視～



■ 統合監査　～概要と導入の背景～

監査ログが 1 つのビューに集約される↓

管理が簡素化

これまで OSファイルへの

大量出力に悩まされていた

キュー書き込みモード↓

監査全体のパフォーマンス向上

従来• DBA_AUDIT_TRAIL• DBA_FGA_AUDIT_TRAIL• OSファイル• OSファイル（ XML形

式）

UNIFIED_AUDIT_TRAIL

メリット1

メリット2

DB

SGASGA キュー

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へのアップグレードと...

Business