shioyakitaroのブログ

主にオラクルDBやLinuxについて調べたことを書いてます。

備忘録:Oracle RACのリスナー周りの関係と値指定のメリット

さてさて、今回はOracle RACのリスナー周りの関係について理解したことを備忘録として書く。

環境
OS : Oracle Linux Server release 6.9
DB : Oracle RAC
リスナー:SCANリスナー、アプリケーション用にデフォルトリスナー同様net1に別にリスナーを立てているケース

事前知識

Oracle RACにおいては、
値を設定していなくてもリスナーの情報が下記パラメータに自動的に登録される。

パラメータ名:登録される情報
local_listener : net1のリスナーの情報(デフォルトリスナーなど)
remote_listener : SCANのホスト名:ポート番号
listener_networks : net2のリスナーの情報

DB起動時にはこれらのリスナーに動的にサービスが登録される。
良しなにやってくれるし、これらのパラメータには値を設定しない方が良いのだろうか。

値未指定で良い?

値は指定した方が良いというのが持論。今のところ理由は二つ。

理由1:自動登録の失敗の可能性

リスナー数が多くなっていった際にALTER SYSTEM SET文で指定可能な文字数(255文字)を超えるとOracle Clusterwareによる自動登録が失敗する。

理由2:リスナーで受け付けるサービスが汚くなる

複数DBを同一サーバー群で構成すると、それらすべてのリスナーの情報が登録されてしまう。

たとえばDB1とDB2を同一サーバー群で運用する場合、かつリスナーを分ける場合、
net1に属するリスナーがそれぞれ存在するとき、両方の値がlocal_listenerに登録され、
同様にnet2に属するリスナーがそれぞれ存在するとき、両方の値がlistener_networksに登録される。

結果として、それぞれのリスナーに、すべてのDBのサービスが登録されてしまう。これは気持ち悪い。

最後に

運用上、ネットワーク的にもアプリケーション用、管理用にNICを分ける場合が多いと思うので
リスナーもそれぞれ存在するケースが想定される。上記の持論が助けになれば幸いである。
なおこれらのパラメータ、何も設定しなければDB起動時のアラートログを見れば分かる通り
システム側でalter system XX SCOPE=MEMORY文を発行して値を登録しているのだが
上記パラメータのどれかがspfile等に値が設定されているとシステム側では自動で設定しなくなる。
僕はlocal_listener,listener_networksに値を指定し、DB再起動をした際にremote_listenerに値を指定しなかったために
SCAN経由でのDB接続ができないという事態になった。個人的にはこれを気をつけたい。

最後の最後に

いくつか知識不足で理解がおかしい場合はご指摘いただきたい。優しければなおよし。

ifup後に静的ルーティングの設定が反映されない原因調査

久しぶりの更新。今回はifup時の静的ルーティング設定について書く。

背景

/etc/sysconfig/static-routesファイルに静的ルーティングの記述があっても
ifdown / ifupをすると静的ルーティングの設定が反映されない

環境:Oracle Linux Server release 6.9

原因

static-routesファイルの設定を反映させるには
ifup後にnetwork restartを実施する or OS再起動が必要だった。
つまりifupの際にstatic-routesファイルは読み込まれない。


なお、Oracle Linuxのドキュメントではroutes-デバイス名ファイルに記載するよう書かれていた。
https://docs.oracle.com/cd/E37670_01/E41138/html/ch11s07.html


To permanently configure static routes, you can configure them by creating a route-interface file in/etc/sysconfig/network-scripts for the interface.



このroutes-デバイス名ファイルに記載するとifup後に設定が反映される。

なお、network restartでstatic-routesファイルが反映されるのはnetworkコマンドの中身を見れば一目瞭然。

root# cat network | grep static
	# Add non interface-specific static-routes.
	if [ -f /etc/sysconfig/static-routes ]; then
	   grep "^any" /etc/sysconfig/static-routes | while read ignore args ; do
	# Add non interface-specific static arp entries.
root#

過去にifup/ifdownとifconfig up / ifconfig downコマンドの挙動の違いに驚いたことがあったが、またしてもifup/ifdownコマンドの挙動について知見を深めることができた。

RMAN小ネタ:nomount時のshow allの結果に注意

今回はRMANを使う際に見つけた小ネタを一つ。

ずばり

nomount状態でRMANコマンドのshow allの結果に注意

である。

背景
制御ファイルの自動バックアップをONにしていたはずなのに
RMANコマンドのshow allの結果でOFFと表示された。

原因
少し考えれば分かるが、DBがnomountの状態であった。
ゆえにshow allで表示されたものはただのデフォルト情報だったのである。


以下、実験結果。

環境:Oracle Multitenant
DB名:TESTDB
RMANリポジトリ:制御ファイル(デフォルト)

まずはDBをnomountで起動。

oracle$ sqlplus / as sysdba

SQL> startup nomount;
ORACLE instance started.

Total System Global Area 1644167168 bytes
Fixed Size		    2925024 bytes
Variable Size		  973082144 bytes
Database Buffers	  654311424 bytes
Redo Buffers		   13848576 bytes
SQL>


この状態でshow allしてみる。

oracle$ rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Tue Jan 30 17:57:03 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: TESTDB (not mounted)

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name TESTDB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default    <---------------これ
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

RMAN>

制御ファイルの自動バックアップがOFFになっている。てか全部defaultかい。

DBをマウントしてみる。

SQL> alter database mount;

Database altered.

再度確認してみる。

RMAN> show all;

RMAN configuration parameters for database with db_unique_name TESTDB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;          <---------------これ
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
...

制御ファイルの自動バックアップがONになっている。


最後に
nomount状態でRMANからリストア等々実施することはあると思うのでshow allには注意すべし。

素朴な調査:オラクルに接続した際のプロセスについて

今回はオラクルのセッションのプロセスについて見てみる。ずばり、ローカル接続とリスナー経由接続の違いについて。

環境:2 node RAC

1. ローカル接続の場合

DBに対しローカル接続をする。

[oracle@node1 ~]$ sqlplus scott/tiger

SQL*Plus: Release 12.1.0.2.0 Production on 火 11月 21 18:42:14 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

最終正常ログイン時間: 火 11月 21 2017 18:41:35 +09:00


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
に接続されました。

SQL>


OS上のプロセスは以下で検索できる。

ps -ef | grep oracle$ORACLE_SID

まずは該当のプロセスを探す。

[oracle@node1 ~]$ ps -ef | grep oracleorcl_1
oracle   10375     1  0 18:32 ?        00:00:01 oracleorcl_1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   10385     1  0 18:32 ?        00:00:00 oracleorcl_1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   14892 14891  0 18:43 ?        00:00:00 oracleorcl_1(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) <-- これ
oracle   15314 14473  0 18:47 pts/2    00:00:00 grep oracleorcl_1

続いてプロセスの親をたどっていく。

[oracle@node1 ~]$ ps -ef | grep 14891
oracle   14891 14240  0 18:43 pts/1    00:00:00 sqlplus
oracle   14892 14891  0 18:43 ?        00:00:00 oracleorcl_1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   15366 14473  0 18:48 pts/2    00:00:00 grep 14891

[oracle@node1 ~]$ ps -ef | grep 14240
oracle   14240 14226  0 18:39 pts/1    00:00:00 -bash
oracle   14891 14240  0 18:43 pts/1    00:00:00 sqlplus
oracle   14917 14473  0 18:43 pts/2    00:00:00 grep 14240

[oracle@node1 ~]$ ps -ef | grep 14226
oracle   14226 14174  0 18:39 ?        00:00:00 sshd: oracle@pts/1
oracle   14240 14226  0 18:39 pts/1    00:00:00 -bash
oracle   14934 14473  0 18:43 pts/2    00:00:00 grep 14226

[oracle@node1 ~]$ ps -ef | grep 14174
root     14174  2558  0 18:39 ?        00:00:00 sshd: oracle [priv]
oracle   14226 14174  0 18:39 ?        00:00:00 sshd: oracle@pts/1
oracle   14992 14473  0 18:44 pts/2    00:00:00 grep 14174
[oracle@node1 ~]$ ps -ef | grep 2558
root      2558     1  0 18:22 ?        00:00:00 /usr/sbin/sshd
root     14174  2558  0 18:39 ?        00:00:00 sshd: oracle [priv]
root     14411  2558  0 18:39 ?        00:00:00 sshd: root@pts/2
oracle   15017 14473  0 18:44 pts/2    00:00:00 grep 2558


これを見る通り、ローカルの場合、sqlplusからプロセスがforkされていることが分かる。
プロセスがsqlplusだけだったのが意外。


ちなみにPROTOCOL=beqとはなんぞやと思い調べてみると

https://docs.oracle.com/cd/E49329_01/network.121/b71288/concepts.htm#sthref128

クライアントとデータベースが同じコンピュータ上に存在する場合、クライアント接続は、リスナーを経由せずに専用サーバー・プロセスに直接渡すことができます。これは、bequeathプロトコルとして知られています。セッションを開始するアプリケーションは、接続要求に対する専用サーバー・プロセスを生成します。データベースの起動に使用されるアプリケーションがデータベースと同じコンピュータ上にある場合、この処理は自動的に実行されます。

とのこと。ローカル接続を意味しているってことかな。

2. リスナー経由の接続の場合

[oracle@node1 ~]$ sqlplus scott/tiger@node1-vip.oracle12c.jp:1522/orcl

SQL*Plus: Release 12.1.0.2.0 Production on 火 11月 21 18:54:35 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

最終正常ログイン時間: 火 11月 21 2017 18:54:12 +09:00


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
に接続されました。
SQL>
[oracle@node1 ~]$ ps -ef | grep oracleorcl
oracle   10375     1  0 18:32 ?        00:00:01 oracleorcl_1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   10385     1  0 18:32 ?        00:00:00 oracleorcl_1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   15859     1  0 18:54 ?        00:00:00 oracleorcl_1 (LOCAL=NO) <-- これ
oracle   15904 15526  0 18:55 pts/1    00:00:00 grep oracleorcl

親プロセスが1なのでこれより先に親はいない。

ちなみにリスナーのプロセスも確認したが他に親子関係を持つプロセスもないことがわかる。

[oracle@node1 ~]$ ps -ef | grep tns
root        23     2  0 18:20 ?        00:00:00 [netns]
grid      4787     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr ASMNET1LSNR_ASM -no_crs_notify -inherit
grid      4789     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr ASMNET2LSNR_ASM -no_crs_notify -inherit
grid      4791     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr MGMTLSNR -no_crs_notify -inherit
grid      4846     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr LISTENER -no_crs_notify -inherit
grid      4870     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr LISTENER_SCAN2 -no_crs_notify -inherit
grid      4884     1  0 18:25 ?        00:00:00 /u01/app/12.1.0/grid/bin/tnslsnr LISTENER_SCAN3 -no_crs_notify -inherit
oracle   15825     1  0 18:54 ?        00:00:00 /u01/app/oracle/product/12.1.0/homeDB/bin/tnslsnr LISTENER_TEST -inherit
oracle   16291 15526  0 19:00 pts/1    00:00:00 grep tns
[oracle@node1 ~]$ ps -ef | grep 15825
oracle   15825     1  0 18:54 ?        00:00:00 /u01/app/oracle/product/12.1.0/homeDB/bin/tnslsnr LISTENER_TEST -inherit
oracle   16344 15526  0 19:00 pts/1    00:00:00 grep 15825
[oracle@node1 ~]$

まとめ

ローカル接続とリスナー経由接続でのプロセスの違いについて調査した。
ローカル接続、リスナー経由の接続ともに独立してプロセスが立てられる。って当たり前か。
ローカル接続の場合のprotocolはbeqになり、リスナー経由の場合はLOCAL=NOという情報のみになる。

Linux : CPUのコア数の確認方法

今回はCPUのコア数の確認方法について。


CPUの情報は/proc/cpuinfoに書かれている。

$ cat /proc/cpuinfo

で、これどう読むの?ってところで以下のサイトが参考になった。
http://d.hatena.ne.jp/kakurasan/20110117/p1#h-20110117p1-2
ただ、いつもコア数の話になると物理コアとか論理コアとかハイパースレッディングがどうだとか色々混乱するので
自分なりにまとめておく。


まとめ
physical id : 物理CPUの場所を指す
core id : 同一物理CPU内にある物理コアの番号
cpu cores : 同一物理CPU内の物理コアの合計
processor : 同一物理CPU内における論理プロセッサの番号


実際に自分のLinux環境で確認してみる。

物理CPUの数

$ cat /proc/cpuinfo | grep "physical id" | uniq
physical id	: 0

physical idが1つ(idが0のみ)なので物理CPUは1つ


論理プロセッサの数

$ cat /proc/cpuinfo | grep "processor"
processor	: 0
processor	: 1
processor	: 2
processor	: 3
processor	: 4
processor	: 5
processor	: 6
processor	: 7

論理プロセッサの数は8つ

物理コアの数

$ cat /proc/cpuinfo | grep "cpu cores" | uniq
cpu cores	: 4

コアの数は4つ


ここまでで、

  • 物理CPUが一つ
  • 論理プロセッサの数は8つ
  • コア数は4つ

であることがわかった。

ここでコア数と論理プロセッサの数に着目すると
プロセッサの数とコア数が等しくない。
このことから、ハイパースレッディング・テクノロジーが有効になっている。
その証拠に、以下、core idを確認すると各idごとに2個ある。

$ cat /proc/cpuinfo | grep "core id" | sort | uniq -c
   2 core id		: 0
   2 core id		: 1
   2 core id		: 2
   2 core id		: 3

ハイパースレッディング・テクノロジーの詳細についてはぐぐってもらうとして、
ざっくりと一つのコアで複数のプロセッサを実現する仕組みのようである(適当)。


で、ここまで書いてきてあれだが
普通に下記のドキュメントにコマンドも説明も詳しく書いてあった。。。
https://access.redhat.com/ja/node/2159401

お試し:RMANによるUNDO表領域の破壊からのリストア、リカバリ

今回はUNDO表領域のについて。
UNDO表領域はテーブルのレコードが更新される際に、更新前のレコードを保持する表領域である。
これは読み取り一貫性を保証するために存在する。

お試す際の情報は以下の通り。

環境:Oracle Database Multitenant Architecture
状態:OPEN
UNDO表領域のデータファイルの場所:/home/oracle/db/oracle/testdb/data/undotbs01.dbf

では順次実施していく。

0. 下準備

0.1. テーブルの作成
面倒なのでルートコンテナにてSYSTEMユーザーのテーブルを作成する。

SQL> create table system.test1 ( col number );

Table created.

0.2. UNDO表領域のバックアップ

まずはUNDO表領域のデータファイルの番号とファイルの場所を確認。

SQL> select file#, name from v$datafile
  2  where name like '%undotbs01.dbf';

     FILE#
----------
NAME
--------------------------------------------------------------------------------
	 4
/home/oracle/db/oracle/testdb/data/undotbs01.dbf

0.3. backupの取得

oracle$ rman target /
RMAN> backup as copy datafile 4;

Starting backup at 20170801_18:50:05
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/home/oracle/db/oracle/testdb/data/undotbs01.dbf
output file name=/home/oracle/flash/TESTDB/datafile/o1_mf_undotbs1_dr0mpgh2_.dbf tag=TAG20170801T185006 RECID=28 STAMP=950899835
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:35
Finished backup at 20170801_18:50:41

Starting Control File and SPFILE Autobackup at 20170801_18:50:41
piece handle=/home/oracle/flash/TESTDB/autobackup/2017_08_01/o1_mf_s_950899841_dr0mqldz_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 20170801_18:50:44

今回はイメージコピーとしてバックアップを取得した。
メッセージから以下の場所に取得されていることがわかる。

/home/oracle/flash/TESTDB/datafile/o1_mf_undotbs1_dr0mpgh2_.dbf

なお、制御ファイルの自動バックアップをONにしているので制御ファイル、SPFILEも取得されていることがわかる。

RMAN> list backkup;
・・・
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
31      Full    17.23M     DISK        00:00:01     20170801_18:50:42
        BP Key: 31   Status: AVAILABLE  Compressed: NO  Tag: TAG20170801T185041
        Piece Name: /home/oracle/flash/TESTDB/autobackup/2017_08_01/o1_mf_s_950899841_dr0mqldz_.bkp
  SPFILE Included: Modification time: 20170801_18:43:49
  SPFILE db_unique_name: TESTDB
  Control File Included: Ckp SCN: 6284037315   Ckp time: 20170801_18:50:41


1. UNDOの削除

下記、OSコマンドにて削除する。

oracle$ rm /home/oracle/db/oracle/testdb/data/undotbs01.dbf


アラートログに以下のメッセージが出力された。

Tue Aug 01 18:53:42 2017
Checker run found 1 new persistent data failures

# ORAエラーも発生

Tue Aug 01 18:54:42 2017
Errors in file /home/oracle/db/u01/oracle/diag/rdbms/testdb/testdb/trace/testdb_j000_3943.trc:
ORA-12012: error on auto execute of job "SYS"."CLEANUP_ONLINE_PMO"
ORA-01116: error in opening database file
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/home/oracle/db/oracle/testdb/data/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

RMANでも検知された。

RMAN> list failure all;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1062       HIGH     OPEN      20170801_18:53:42 One or more non-system datafiles are missing

DB自体は使えるようなのでどこまでいけるか試してみる。

2. レコード操作

2.1. レコードの挿入

SQL> insert into system.test1 values ( 1 );

1 row created.

SQL> commit;

Commit complete.

insert完了。INSERT作業ではUNDOが利用されないことが分かる。

2.2. レコードの更新

更新しようとすると下記のエラーが発生。
UNDO表領域のデータファイルがないので当然の結果。

18:57:11 SQL> update system.test1 set col=2;
update system.test1 set col=2
              *
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/home/oracle/db/oracle/testdb/data/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


3. 復旧作業

今回はRMANの便利な機能で復旧を試みる。
基本、以下の手順で復旧が可能である。

  1. list failure
  2. advise failure
  3. repair failure

2のadvise failureをすると復旧に必要なコマンドをまとめたファイルをRMANが作成してくれる。
それをrepair failureで実施すれば復旧が完了というもの。


では順次実施していく。

3.1. 障害内容を確認

RMAN> list failure;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1062       HIGH     OPEN      20170801_18:53:42 One or more non-system datafiles are missing

3.2. アドバイスを確認

RMAN> advise failure;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1062       HIGH     OPEN      20170801_18:53:42 One or more non-system datafiles are missing

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
1. If file /home/oracle/db/oracle/testdb/data/undotbs01.dbf was unintentionally renamed or moved, restore it
2. Automatic repairs may be available if you shutdown the database and restart it in mount mode
3. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
no automatic repair options available

あれ、なんかマニュアルアクションが必要みたい。
アドバイスに沿って実施する。

3.3. バックアップからファイルをコピー

oracle$ cp flash/TESTDB/datafile/o1_mf_undotbs1_dr0nx67b_.dbf db/oracle/testdb/data/undotbs01.dbf


再度確認する。

RMAN> list failure;

Database Role: PRIMARY

no failures found that match specification

復旧した模様。アラートログからORAエラーも出なくなった。
実際に運用していると可能であればDBを停止したくないと思うので上記のように復旧する。

3.3. DBを停止しての復旧
停止しても問題ない場合は当初の予定通り、以下の手順でUNDO表領域のリカバリを実施する。


DBを停止、マウントモードで起動する。

  1. shutdown abortで停止
  2. startup mount;


RMANで3.の冒頭で述べた手順を実施する。

RMAN> list failure;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1062       HIGH     OPEN      20170801_18:53:42 One or more non-system datafiles are missing

RMAN> advise failure;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1062       HIGH     OPEN      20170801_18:53:42 One or more non-system datafiles are missing

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /home/oracle/db/oracle/testdb/data/undotbs01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Restore and recover datafile 4
  Strategy: The repair includes complete media recovery with no data loss
  Repair script: /home/oracle/db/u01/oracle/diag/rdbms/testdb/testdb/hm/reco_249714199.hm


RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /home/oracle/db/u01/oracle/diag/rdbms/testdb/testdb/hm/reco_249714199.hm

contents of repair script:
   # restore and recover datafile
   restore ( datafile 4 );
   recover datafile 4;
   sql 'alter database datafile 4 online';

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 20170801_19:04:17
using channel ORA_DISK_1

channel ORA_DISK_1: restoring datafile 00004
input datafile copy RECID=28 STAMP=950899835 file name=/home/oracle/flash/TESTDB/datafile/o1_mf_undotbs1_dr0mpgh2_.dbf
destination for restore of datafile 00004: /home/oracle/db/oracle/testdb/data/undotbs01.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00004
output file name=/home/oracle/db/oracle/testdb/data/undotbs01.dbf RECID=0 STAMP=0
Finished restore at 20170801_19:04:52

Starting recover at 20170801_19:04:52
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 20170801_19:04:53

sql statement: alter database datafile 4 online
repair failure complete

Do you want to open the database (enter YES or NO)? YES
database opened

なお、実行したファイルの中身はこれ

oracle$ cat /home/oracle/db/u01/oracle/diag/rdbms/testdb/testdb/hm/reco_249714199.hm
   # restore and recover datafile
   restore ( datafile 4 );
   recover datafile 4;
   sql 'alter database datafile 4 online';


以上

お試し:RMANによる制御ファイル全損からのリストア、リカバリ

さて、今回は制御ファイル全損からのリストア、リカバリをやってみる。



0. 制御ファイルのバックアップの取得


制御ファイルの自動バックアップをONにしていることを確認

RMAN> show all;
...
...

CONFIGURE CONTROLFILE AUTOBACKUP ON;  ← これ


バックアップを取得する。
念のために手動でバックアップを取得した。

RMAN> BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl';

Starting backup at 20170727_18:37:12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/tmp/control01.ctl tag=TAG20170727T183712 RECID=27 STAMP=950467033
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:02
Finished backup at 20170727_18:37:14

Starting Control File and SPFILE Autobackup at 20170727_18:37:14
piece handle=/home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950467034_dqmf2bhm_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 20170727_18:37:15

取得された。


バックアップの取得状況を確認する。

RMAN> list backup;

...
...

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
28      Full    17.23M     DISK        00:00:00     20170727_18:25:41
        BP Key: 28   Status: AVAILABLE  Compressed: NO  Tag: TAG20170727T182541
        Piece Name: /home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950466341_dqmddox2_.bkp
  SPFILE Included: Modification time: 20170727_18:14:01
  SPFILE db_unique_name: TESTDB
  Control File Included: Ckp SCN: 6283971770   Ckp time: 20170727_18:25:41

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
29      Full    17.23M     DISK        00:00:00     20170727_18:37:14
        BP Key: 29   Status: AVAILABLE  Compressed: NO  Tag: TAG20170727T183714
        Piece Name: /home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950467034_dqmf2bhm_.bkp
  SPFILE Included: Modification time: 20170727_18:29:32
  SPFILE db_unique_name: TESTDB
  Control File Included: Ckp SCN: 6283972474   Ckp time: 20170727_18:37:14


手動バックアップの際も、自動バックアップが取得されるようだ。安心。


1. 制御ファイルの削除
OSコマンドで制御ファイルを削除する。

oracle$ rm /home/oracle/db/oracle/testdb/ctl/control01.ctl
oracle$ rm /home/oracle/db/oracle/testdb/ctl/control02.ctl

全削除したとたん、さっそくアラートログには以下のメッセージ

Thu Jul 27 18:45:42 2017
Errors in file /home/oracle/db/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_m000_9417.trc:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/home/oracle/db/oracle/testdb/ctl/control01.ctl'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

なお、DB自体にはログインができた。
制御ファイルへの変更が入るように、表領域を作成してみる。

oracle$ sqlplus / as sysdba

SQL>
CREATE TABLESPACE testtbs
DATAFILE '/home/oracle/db/oracle/testdb/data/testtbs01.dbf'
SIZE 20M AUTOEXTEND ON;SQL>   2    3
CREATE TABLESPACE testtbs
*
ERROR at line 1:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/home/oracle/db/oracle/testdb/ctl/control01.ctl'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

上記のエラーが出た。よしよし。では復旧しよう。


2. DBの強制停止、nomountで起動

制御ファイルやSYSTEM表領域といった、クリティカルなファイルに障害が起きる場合は
shutdown abortでDBを強制停止する必要がある。
また、今回、制御ファイルが全損しているのでマウントができない(制御ファイルが読み込めないので)ため
nomountで起動する。

shutdown abort;
startup nomount;

ちなみにこの段階でRMANでlist failureしても何も結果は出なかった。

RMAN> list failure;

using target database control file instead of recovery catalog
no failures found that match specification

3. 制御ファイルのリストア、リカバリ

まずは制御ファイルをリストアする。

RMAN> restore controlfile from autobackup;

Starting restore at 20170727_19:00:39
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=7 device type=DISK

recovery area destination: /home/oracle/flash
database name (or database unique name) used for search: TESTDB
channel ORA_DISK_1: AUTOBACKUP /home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950467034_dqmf2bhm_.bkp found in the recovery area
AUTOBACKUP search with format "%F" not attempted because DBID was not set
channel ORA_DISK_1: restoring control file from AUTOBACKUP /home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950467034_dqmf2bhm_.bkp
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=/home/oracle/db/oracle/testdb/ctl/control01.ctl
output file name=/home/oracle/db/oracle/testdb/ctl/control02.ctl
Finished restore at 20170727_19:00:41

自動バックアップからリストアが完了。

アラートログには以下の出力。

No controlfile conversion


制御ファイルがリストアできたのでマウントしリカバリを実施実施する。

RMAN> alter database mount;
Statement processed
released channel: ORA_DISK_1

RMAN> recover database;

Starting recover at 20170727_19:03:03
Starting implicit crosscheck backup at 20170727_19:03:03
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=7 device type=DISK
Crosschecked 15 objects
Finished implicit crosscheck backup at 20170727_19:03:03

Starting implicit crosscheck copy at 20170727_19:03:03
using channel ORA_DISK_1
Crosschecked 4 objects
Finished implicit crosscheck copy at 20170727_19:03:04

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /home/oracle/flash/TESTDB/autobackup/2017_07_27/o1_mf_s_950467034_dqmf2bhm_.bkp

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 35 is already on disk as file /home/oracle/db/oracle/testdb/redo/redo02.log
archived log file name=/home/oracle/db/oracle/testdb/redo/redo02.log thread=1 sequence=35
media recovery complete, elapsed time: 00:00:00
Finished recover at 20170727_19:03:05

4. DBの起動

DBをオープンする。RESETLOGSオプション付きでないと起動しないので注意。

RMAN> alter database open resetlogs;

Statement processed


ログ順序番号がリセットされていることを確認。

oracle$ sqlplus / as sysdba
SQL> select group#, thread#, sequence#, status from v$log;
    GROUP#    THREAD#  SEQUENCE# STATUS
---------- ---------- ---------- ----------------------------------------------------------------
	 1	    1	       1 CURRENT
	 2	    1	       0 UNUSED
	 3	    1	       0 UNUSED


以上、制御ファイル全損からのリストア、リカバリを試した。