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


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

お試し:RMANによるSYSTEM表領域のリストア、リカバリ

DBAにとって障害からの復旧は基本のロールである。


というわけでRMANの勉強を始めた。

題名の通り、今回はSYSTEM表領域に障害が起きた時の復旧作業である。


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

  1. バックアップの取得

リストアのためにSYSTEM表領域のバックアップを事前に取得する。

oracle$ rman target /

RMAN> backup datafile '/home/oracle/db/oracle/testdb/data/system01.dbf';

Starting backup at 20170725_20:57:10
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/home/oracle/db/oracle/testdb/data/system01.dbf
channel ORA_DISK_1: starting piece 1 at 20170725_20:57:11
channel ORA_DISK_1: finished piece 1 at 20170725_20:57:36
piece handle=/home/oracle/flash/TESTDB/backupset/2017_07_25/o1_mf_nnndf_TAG20170725T205710_dqgdjqcc_.bkp tag=TAG20170725T205710 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 20170725_20:57:36

Starting Control File and SPFILE Autobackup at 20170725_20:57:36
piece handle=/home/oracle/flash/TESTDB/autobackup/2017_07_25/o1_mf_s_950302656_dqgdkk9z_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 20170725_20:57:39

制御ファイルの自動バックアップもONにしているのでSYSTEM表領域のデータファイルだけでなく制御ファイルとSPFILEもバックアップが取得されていることが分かる。

  1. SYSTEM表領域のデータファイルの物理削除

データファイルを削除します。

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


ためしにsystemユーザーでログインしようとするもできず。

ERROR:
ORA-02002: error while writing to audit trail
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/home/oracle/db/oracle/testdb/data/system01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory

アラートログには以下のメッセージ

Checker run found 1 new persistent data failures


RMANでは以下のように確認できる

RMAN> list failure all;

Database Role: PRIMARY

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

Failure ID Priority Status    Time Detected     Summary
---------- -------- --------- ----------------- -------
1482       CRITICAL OPEN      20170725_20:23:41 System datafile 1: '/home/oracle/db/oracle/testdb/data/system01.dbf' is missing
  1. リストア作業

さて、まず、SYSTEM表領域に障害が起きた場合は以下の手順を実施してリストアできる準備をする。
1:shutdown abortでDBを強制停止
2:startup mountでマウント状態にする

上記のコマンドはRMANからでも実施できる。RMANを用いてリストア、リカバリを実施する場合にはRMANコマンドで上記の作業をするのがスムーズである。

というわけでリストアを実施。

RMAN> restore datafile 1;

Starting restore at 20170725_21:03:57
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/db/oracle/testdb/data/system01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/flash/TESTDB/backupset/2017_07_25/o1_mf_nnndf_TAG20170725T205710_dqgdjqcc_.bkp
channel ORA_DISK_1: piece handle=/home/oracle/flash/TESTDB/backupset/2017_07_25/o1_mf_nnndf_TAG20170725T205710_dqgdjqcc_.bkp tag=TAG20170725T205710
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 20170725_21:04:12

問題なくリストアされた模様。ちなみにリストアで使用されたbackup pieceは
/home/oracle/flash/TESTDB/backupset/2017_07_25/o1_mf_nnndf_TAG20170725T205710_dqgdjqcc_.bkp
だとメッセージで出ているが、これは

RMAN> list backup;

...
...
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
25      Full    758.40M    DISK        00:00:18     20170725_20:57:29
        BP Key: 25   Status: AVAILABLE  Compressed: NO  Tag: TAG20170725T205710
        Piece Name: /home/oracle/flash/TESTDB/backupset/2017_07_25/o1_mf_nnndf_TAG20170725T205710_dqgdjqcc_.bkp
  List of Datafiles in backup set 25
  File LV Type Ckp SCN    Ckp Time          Name
  ---- -- ---- ---------- ----------------- ----
  1       Full 6283638194 20170725_20:57:11 /home/oracle/db/oracle/testdb/data/system01.dbf


さきほどバックアップしたものであることが分かる。

  1. リカバリの実施とDBのオープン

ここまでくればあとはリカバリを実施しDBをオープンすれば良い。
オープン時にリカバリが必要な場合は以下のようにメッセージが出るのでメッセージに従ってリカバリを実施する。

RMAN> alter database open;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 07/25/2017 20:48:27
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/home/oracle/db/oracle/testdb/data/system01.dbf'

RMAN> recover datafile 1;
Starting recover at 20170725_20:48:51
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 8 is already on disk as file /arch/1_8_948652501.dbf
archived log for thread 1 with sequence 9 is already on disk as file /arch/1_9_948652501.dbf
archived log for thread 1 with sequence 10 is already on disk as file /arch/1_10_948652501.dbf
archived log for thread 1 with sequence 11 is already on disk as file /arch/1_11_948652501.dbf
archived log file name=/arch/1_8_948652501.dbf thread=1 sequence=8
archived log file name=/arch/1_9_948652501.dbf thread=1 sequence=9
media recovery complete, elapsed time: 00:00:01
Finished recover at 20170725_20:48:53

RMAN> alter database open;

Statement processed


以上

どのくらい禁煙できるか試してみる

題名の通り、禁煙を試してみる。

書生は週に1箱、多い時で2箱くらいの喫煙家である。

喫煙家の中ではあまり吸っていない方だと思う。

吸う理由は、なんとなく一服したいとき(休憩したいとき)とか、
ぶっちゃけ暇な時とか、まあそんなところ。

たとえば一服したいときに、すぐにあったかいお茶とか出てくるならそれでよくて、
特別たばこじゃなくてもいいような気がしていた。
でも、あったかいお茶は、すぐには出てこない。
お湯をわかす必要がある。
というわけで、今までそんなにヘビーなスモーカーではないが、
細く長くというか、なんとなくずっと吸ってきていた。

ただ、吸った後はいつもうがいをするし、いまいちたばこにコミットしてる感じがしない。
よく一服すると集中力が上がるとか言う人もいるが、書生はあんまり感じない。むしろ吸った後は何か疲れる。


ここまで書いてお分かりだと思うが、おそらくそんなにたばこ必要な人ではないと思われる。

禁煙にこだわっているわけでもないのだけれど、
今回、このように禁煙を試す事でどのようなことを思うのかを記してみようと思いたち、書いてみた。

ひとまず禁煙一日目の今日。

たばこを吸いたいと思うことはあった。
ただ、この試みをしているという意識から割とすぐに我慢できた。
時間はかかるがお湯をわかしお茶を飲む事でたばこ欲はおさまった。

はたして何日禁煙できるのだろうか。

むしろこのように記事に書いていくことでたばこを積極的に意識していくことになると思うのであるが
そのように意識するとどういう心持ちになるのかも書いていければ良いなと思う。

まあ、そんなかんじで本日一日が終わりました。

ではまた。

期待 - 天丼弁当

天丼が食べたい

自由が丘の天丼

北口か何口かを出て左へ進んだ先にある

これまでもチャンスはあった

食べるチャンス

存在は知っていた

弁当が1300円

天丼としては当然の値段である

たまに食べるラーメン
全部盛りが1000円

それを考えると
どうしても一度は食べてみたい

きっと美味しいんだろうな

衣のさくさく感に感動し

具の味に感動し

つゆに感動し

そうしてこの天丼が弁当であることに感動するだろう

でもそんだけ?

ほとんど感動でまとめてない?

いや、きっとこうだ

意外と具が多い

米は丁度良い、0.3合といったとこか

エビが二つ入っている

これは驚きである

養殖されたエビ

そうして自由が丘まで運ばれてきた

えびちゃん

さぁ 食べよう 僕は 食べよう

この自由が丘というばしょで

それをお持ち帰りし

開けよう 割る箸の音

僕を前に進める

さぁ どうでしょう?

サンドイッチで得られる効果について

コンビニでご飯を済ませる時、
書生の場合はだいたい以下の3パターン

  • カップ焼きそば+コロッケ
  • なにか弁当など
  • サンドイッチ

コンビニで済ませる時に一食500円を超えたくないという思いから
上記の3パターンにしぼられるのである。

選ぶ際の書生の思考回路はこう。

  • カップ焼きそば+コロッケ

見るからに健康に悪そうではあるが、
カロリーを摂取したいとき、ジャンキーなものを食べたいときに選択される。
カップ焼きそばは麺類なので一瞬で食べ終わってしまう恐れがあるので、保険としてのコロッケがいるのである。
懸念点といえば野菜がとれないこと。まあ、カップ焼きそばには雀の涙程度の野菜はあるのであるが。

  • なにか弁当など

これはだいたい500円で済ますのが難しい。
ちょっとした弁当でも400円程度するので、そもそも選択肢が限られてくるのであるが
カップ焼きそばよりは身体に良さそうなものを摂取したい時に選択される。
うどんやソバにするとタンパク質が不足しているような、一瞬で食べ終えてしまい満腹中枢を刺激できないので、それらは避けている。よほど暑い日以外は。

  • サンドイッチ

こちらはそもそもお腹があまり空いていない時に選択される。
飲み会明けで、夜までお腹が持たないかもしれないような土曜、日曜の昼に
選択される傾向にある。

はてさて、これらの中で、最近は飲み会が多くなり
翌日の昼、もしくは夕方あたりに昼ご飯としてサンドイッチを食べることが多くなったが、
買う時にいつも思う事があった。

サンドイッチの値段はなぜ高いのか
おにぎりの値段と比べるとカロリー的にみても異常に高いのである。

ただ、なんとなく格好がつくというのと、
おにぎりより

「私炭水化物でお腹満たしてます」感が若干薄まる

のがサンドイッチだと思うのだがそれにしても高い。
値段にしてみれば二倍以上はする。

その理由を知るために、Gケンサクに聞いてみると
やはり出てくる、出てくる、同じような疑問をもった人たち。

ざっくりいうと次のようである。

  • 作るのに時間と手間がかかる ( 具材をはさんだりするのが手作業らしい )
  • 原材料が生のものが多いため賞味期限が短い

上記の理由により利益確保のための上乗せがされる。
まあGケンサクがいうことなので真実は不明であるのであるが、
手間の事に関して言えば、おにぎりは全部機械が作っているということだろうか。
まー形も奇麗だし海苔の包み方とか包装とか考えるとたしかに機械がやってそうである。

というのでサンドイッチの値段についての疑問は晴れた。
てっきり、何か他に理由があるからだと思っていた(健康に良いなど)が
そうでもないようである。

ただ、書生はいつもサンドイッチを食べる時、サンドイッチにはある効果があると思っている。

それは

村上春樹

である。

村上春樹の小説に出てくる主人公がサンドイッチを食べるのは良く知られているところであるが
サンドイッチを食べる事で、その主人公感を得られる。
少なくとも、書生の場合は。

書生的観点でいうと、村上春樹小説は

の宣伝に一役買っている。

なんか、こう、主人公のまねをしたくなる、
そんな魔力が村上春樹氏の小説にはあって
書生は見事に影響される。あるいは。みたいな。

少々話は脱線したが、
村上春樹感を得るために書生はサンドイッチを食べる。
もちろん、ビールも飲む。

以上、サンドイッチで得られる効果についてであった。