2017年7月17日月曜日

バックアップファイルのチェックポイント時間

久しぶりのエントリとなってしまいました。
先日、業務でバックアップファイルからのリカバリをした際、全体バックアップのファイルの時間がどこになっているのかわからず、作業が止まってしまったことがありました。

少しおさらいしてみましょう。
バックアップは、データベースの破損をしたときにリカバリ(修復)するために取ります。
データベースのバックアップには、全体バックアップと増分バックアップ、差分バックアップがあります。

全体バックアップは、文字通りデータベースのデータファイルをバックアップしたものです。
増分バックアップは、全体バックアップとの増分のみをバックアップしたものです。
差分バックアップは、全体バックアップとの差分をバックアップしたものです。
こういった説明だとわかりづらくなってしまいますが、つまりは、増分バックアップと差分バックアップの違いは、
 増分:前回バックアップ以降のデータをバックアップ
 差分:全体バックアップ以降のデータをバックアップ
となります。

ここでは、全体バックアップと増分バックアップについて語ります。
なぜ増分を取るかといいますと、全体バックアップの取得には時間がかかってしまうため、以前取った全体バックアップとの差分を取って、
全体バックアップ+増分バックアップで、直近の状態のバックアップとします。
ここで一つ問題なのが、増分バックアップばかり取り続けてしまうと、全体バックアップと大量の増分バックアップを保存しなければならず、
管理が面倒になってしまいます。そのため、定期的に全体バックアップを取得する必要があります。
データベースの量がそれほど大きくないのであれば、一週間に一度バックアップというのでも良いのでしょうが、バックアップに取れる時間がそれほどないような場合、それも難しくなってしまいます。

oracleの場合、増分バックアップを全体バックアップに適用させることにより、増分バックアップの取得時点(もしくはそれまでの任意の地点)まで全体バックアップの時間を進めることができます。
何が嬉しいかといいますと、全体バックアップを定期的に取らずとも、増分バックアップ取得のみで、直近のバックアップ取得時点までの全体バックアップを保持することができるのです。
マニュアル:https://docs.oracle.com/cd/E16338_01/backup.112/b56269/rcmquick.htm#sthref136


こうなってきますと、現在の全体バックアップがいつ時点のポイントのバックアップであるかを確認する術が欲しくなります。
そこで、全体バックアップ取得、増分バックアップ取得、増分バックアップ適用後の状態を確認してみました。
まず、全体バックアップ取得時のバックアップリストです。

======
[oracle@tama01 ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Jul 11 20:09:24 2017

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

connected to target database: BALLOON (DBID=2896125069)

RMAN> list copy;

using target database control file instead of recovery catalog
specification does not match any archived log in the repository
List of Datafile Copies
=======================

Key     File S Completion Time     Ckp SCN    Ckp Time        
------- ---- - ------------------- ---------- -------------------
36      1    A 2017/07/11 20:04:13 1155397    2017/07/11 20:01:44
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_49_11
        Tag: TAG20170711T200144

37      2    A 2017/07/11 20:06:15 1155468    2017/07/11 20:04:22
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_50_11
        Tag: TAG20170711T200144

38      3    A 2017/07/11 20:06:40 1155512    2017/07/11 20:06:21
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_51_11
        Tag: TAG20170711T200144

41      4    A 2017/07/11 20:07:09 1155531    2017/07/11 20:07:07
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_54_11
        Tag: TAG20170711T200144

39      5    A 2017/07/11 20:06:56 1155523    2017/07/11 20:06:47
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_52_11
        Tag: TAG20170711T200144

List of Control File Copies
===========================

Key     S Completion Time     Ckp SCN    Ckp Time        
------- - ------------------- ---------- -------------------
40      A 2017/07/11 20:07:04 1155529    2017/07/11 20:07:02
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_53_11
        Tag: TAG20170711T200144


RMAN> exit
======

このうち、「Ckp Time」がバックアップファイルの時間、「Completion Time」はバックアップを取得した時間です。

■参考マニュアル
https://docs.oracle.com/cd/E16338_01/backup.112/b56270/rcmsynta027.htm#CHDGGGHG

データを更新して、増分バックアップを取ってみましょう。
=======
[oracle@tama01 ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Tue Jul 11 20:10:06 2017

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

SQL> conn XXXXX/XXXXXX;
Connected.
SQL> select count(*) from oak;

  COUNT(*)
----------
      1001

SQL> insert into oak values('OAKTABLE');

1 row created.

SQL> commit;

Commit complete.

SQL> select count(*) from oak;

  COUNT(*)
----------
      1002
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP and Real Application Testing options

[oracle@tama01 ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Jul 11 20:09:24 2017

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

connected to target database: BALLOON (DBID=2896125069)

RMAN> backup incremetal level 1 database;

Starting backup at 2017/07/11 20:13:55
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=44 device type=DISK
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/balloon/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/balloon/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/balloon/undotbs01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/balloon/rman01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/balloon/users01.dbf
channel ORA_DISK_1: starting piece 1 at 2017/07/11 20:13:58
channel ORA_DISK_1: finished piece 1 at 2017/07/11 20:14:05
piece handle=/u01/app/oracle/flash_recovery_area/BALLOON/backupset/2017_07_11/o1_mf_nnnd1_TAG20170711T201357_dp9dqqx3_.bkp tag=TAG20170711T201357 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 2017/07/11 20:14:07
channel ORA_DISK_1: finished piece 1 at 2017/07/11 20:14:10
piece handle=/u01/app/oracle/flash_recovery_area/BALLOON/backupset/2017_07_11/o1_mf_ncsn1_TAG20170711T201357_dp9dqz4w_.bkp tag=TAG20170711T201357 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 2017/07/11 20:14:10

======
この状態で、Lv0の時間はどうでしょうか。

======
RMAN> list copy;

specification does not match any archived log in the repository
List of Datafile Copies
=======================

Key     File S Completion Time     Ckp SCN    Ckp Time        
------- ---- - ------------------- ---------- -------------------
36      1    A 2017/07/11 20:04:13 1155397    2017/07/11 20:01:44
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_49_11
        Tag: TAG20170711T200144

37      2    A 2017/07/11 20:06:15 1155468    2017/07/11 20:04:22
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_50_11
        Tag: TAG20170711T200144

38      3    A 2017/07/11 20:06:40 1155512    2017/07/11 20:06:21
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_51_11
        Tag: TAG20170711T200144

41      4    A 2017/07/11 20:07:09 1155531    2017/07/11 20:07:07
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_54_11
        Tag: TAG20170711T200144

39      5    A 2017/07/11 20:06:56 1155523    2017/07/11 20:06:47
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_52_11
        Tag: TAG20170711T200144

List of Control File Copies
===========================

Key     S Completion Time     Ckp SCN    Ckp Time        
------- - ------------------- ---------- -------------------
40      A 2017/07/11 20:07:04 1155529    2017/07/11 20:07:02
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_53_11
        Tag: TAG20170711T200144
======
特に変わってはいません。

では、増分更新をしてみましょう。
======
RMAN> recover copy of database;

Starting recover at 2017/07/11 20:17:02
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy file number=00001 name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_49_11
recovering datafile copy file number=00002 name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_50_11
recovering datafile copy file number=00003 name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_51_11
recovering datafile copy file number=00004 name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_54_11
recovering datafile copy file number=00005 name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_52_11
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/BALLOON/backupset/2017_07_11/o1_mf_nnnd1_TAG20170711T201357_dp9dqqx3_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/flash_recovery_area/BALLOON/backupset/2017_07_11/o1_mf_nnnd1_TAG20170711T201357_dp9dqqx3_.bkp tag=TAG20170711T201357
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished recover at 2017/07/11 20:17:04

RMAN> list copy;

specification does not match any archived log in the repository
List of Datafile Copies
=======================

Key     File S Completion Time     Ckp SCN    Ckp Time        
------- ---- - ------------------- ---------- -------------------
45      1    A 2017/07/11 20:17:03 1155895    2017/07/11 20:13:58
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_49_11
        Tag: TAG20170711T200144

46      2    A 2017/07/11 20:17:03 1155895    2017/07/11 20:13:58
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_50_11
        Tag: TAG20170711T200144

44      3    A 2017/07/11 20:17:03 1155895    2017/07/11 20:13:58
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_51_11
        Tag: TAG20170711T200144

43      4    A 2017/07/11 20:17:03 1155895    2017/07/11 20:13:58
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_54_11
        Tag: TAG20170711T200144

42      5    A 2017/07/11 20:17:03 1155895    2017/07/11 20:13:58
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_52_11
        Tag: TAG20170711T200144

List of Control File Copies
===========================

Key     S Completion Time     Ckp SCN    Ckp Time        
------- - ------------------- ---------- -------------------
40      A 2017/07/11 20:07:04 1155529    2017/07/11 20:07:02
        Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lv0_53_11
        Tag: TAG20170711T200144

======
時間が動きましたね。
バックアップファイルもデータファイルも、一度更新を適用してしまうと元に戻すことはできません。
バックアップ運用を進めていくうえでも、今の状態で想定しているポイントにバックアップできるのかをチェックする必要がありますので、
rmanのリスト機能も読めるようになっておきたいですね。

2017年5月6日土曜日

Testing Log Miner(English)

Oracle LogMiner can check substance of Oracle database redo log file using SQL.
Checking Oracle database redo log file is good for seeing history of transactions.

If you want to use LogMiner, you have to additional row in redo log to record in advance.
Recording in additional row called Supplimental Logging.

In default, supplimental logging is not valid. so I need supplimental logging valid to use LogMiner.

For now, I checked configureation of supplimental logging.

===
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;

SUPPLEME
--------
NO
===

NO means supplimental logging is invalid in this database.
So, I enable supplimental logging.
===
SQL> alter database add supplemental log data;

Database altered.

SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;

SUPPLEME
--------
YES
===
Supplimental logging is now valid.

Next, let's get history of transactions.

1. Specify directory of LogMiner
I can specify directory. But this time, I specified when starting LogMiner, so I didn't anything.

2. Specify redo log file
I can specify redo log file that I want to get LogMiner data.
I specified online redo log file which was used right now.
===
SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/balloon/redo03.log
/u01/app/oracle/oradata/balloon/redo02.log
/u01/app/oracle/oradata/balloon/redo01.log

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE  MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1    1       1   52428800   512 1 YES
INACTIVE       1127233 13-NOV-16      1147535 09-APR-17

2    1       2   52428800   512 1 NO
CURRENT       1147535 09-APR-17   2.8147E+14

3    1       0   52428800   512 1 YES
UNUSED     0    0

===
The redo02.log is used right now. So, I specified redo02.log's data.

===
SQL> execute dbms_logmnr.add_logfile(logfilename => '/u01/app/oracle/oradata/balloon/redo02.log', options=> dbms_logmnr.new);

PL/SQL procedure successfully completed.
===
It's finished to specify.

3. Starting LogMiner
I started LogMiner. This time, I used online catalog for specifing directory.
We can use online catalog to analyzing online redo log file and arhived redo log file.
===
SQL> execute dbms_logmnr.start_logmnr( options => dbms_logmnr.dict_from_online_catalog);

PL/SQL procedure successfully completed.
===

*I executed some sql to recording redo log file.
I added new row and commit and I deleted row. After that, I checked difference transaction rollback or commit.
===
SQL> select * from qb.keiyaku;

NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

SQL>  insert into qb.keiyaku values('oriko',to_date('2011/03/20','yyyy/mm/dd'));

1 row created.

SQL> commit;

Commit complete.

SQL> select * from qb.keiyaku;

NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 *

6 rows selected.

SQL> delete from qb.keiyaku where name = 'oriko';

1 row deleted.

SQL> rollback;

Rollback complete.

SQL> select * from qb.keiyaku;

NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 *

6 rows selected.

SQL>
SQL> delete from qb.keiyaku where name = 'oriko';

1 row deleted.

SQL> commit;

Commit complete.

SQL> select * from qb.keiyaku;

NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

===

4.Checking recorded redo log.
For checking recorded redo log, We can use the view v$logmnr_contents.
===
set line 6000
select SCN,TIMESTAMP,TABLE_NAME,OPERATION,SQL_REDO from v$logmnr_contents where operation!='INTERNAL';


       SCN TIMESTAMP TABLE_NAME      OPERATION       SQL_REDO
...
   1152964 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
...
   1153175 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153180 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
   1153181 15-APR-17      ROLLBACK       rollback;
...
   1153193 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153194 15-APR-17      COMMIT       commit;

===


5.Stopping LogMiner
In the end,stopping LogMiner.
===
SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR;

PL/SQL procedure successfully completed.
===
Log miner can be used in the above procedure.
I think that it can be used for confirmation when it is operation mistake.

However, You may warry about load of the system.
According to manual, when you use "minimal supplemental logging" ( I tried this time), the load does not become much heavier. Of course, you should verificate before introducing.
The other hand, when you use "recognition key / logging"(it can record up to the contents of the line) the load is heavier than minimal supplemental logging.

2017年4月25日火曜日

ログマイナーを試してみる

Oracle LogMinerは、Oracle DatabaseのREDOログファイル(オンライン・アーカイブともに)の内容ををSQLで問い合わせることができるものです。
REDOログファイルの内容を見ることができるようになることで、データベースの履歴情報が確認できます。

LogMinerを使用するためには、REDOログファイルに対して追加の列を用意し、記録をする必要があります。追加の列に記録することを「サプリメンタル・ロギング」といいます。
デフォルトでは、Oracle Databaseはサプリメンタル・ロギングは有効になっていません。そのため、LogMinerを使用したい場合はサプリメンタルロギングを有効にする必要があります。

まずは、現在のデータベースの設定を確認し、サプリメンタル・ロギングが有効か確認します。

SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
NO


NOはサプリメンタル・ロギングが設定されていないことを示しています。

さて、それではサプリメンタル・ロギングを有効にしましょう。

SQL> alter database add supplemental log data;
Database altered.
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
YES


有効になりました。

さて、LogMinerによるデータの取得をしてみましょう。

1.LogMinerディクショナリの指定
ディクショナリの指定を行うことができますが、今回はLogMiner起動時に指定したので、
特になにもしませんでした。

2.REDOログファイルの指定
LogMinerのデータを取得したいREDOログファイルを指定します。
まずは、今使われているのオンラインREDOログファイルを確認します。


SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/balloon/redo03.log
/u01/app/oracle/oradata/balloon/redo02.log
/u01/app/oracle/oradata/balloon/redo01.log
SQL> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE  MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1    1       1   52428800   512 1 YES
INACTIVE       1127233 13-NOV-16      1147535 09-APR-17
2    1       2   52428800   512 1 NO
CURRENT       1147535 09-APR-17   2.8147E+14
3    1       0   52428800   512 1 YES
UNUSED     0    0

現在はredo02.logを使用されているため、今回はredo02.logを確認したいと思います。

SQL> execute dbms_logmnr.add_logfile(logfilename => '/u01/app/oracle/oradata/balloon/redo02.log', options=> dbms_logmnr.new);
PL/SQL procedure successfully completed.

指定が完了しました。

3.LogMinerを起動
LogMinerを起動します。ここではディクショナリの指定にオンラインカタログを使用します。
オンラインカタログはオンラインREDOログ、アーカイブREDOログの分析に使用できます。

SQL> execute dbms_logmnr.start_logmnr( options => dbms_logmnr.dict_from_online_catalog);
PL/SQL procedure successfully completed.

★ここで、REDOログに記録するSQLを発行します。
今回は、qb.keiyakuテーブルに新たに行を追加したのち、削除後ロールバックした場合と削除後コミットした場合のログを見てみます。

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

SQL>  insert into qb.keiyaku values('oriko',to_date('2011/03/20','yyyy/mm/dd'));
1 row created.
SQL> commit;
Commit complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 ★
6 rows selected.

SQL> delete from qb.keiyaku where name = 'oriko';
1 row deleted.
SQL> rollback;
Rollback complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 ★
6 rows selected.

SQL> delete from qb.keiyaku where name = 'oriko';
1 row deleted.
SQL> commit;
Commit complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

4.REDOログの内容を確認
REDOログの内容を確認します。
確認するには、SQLにてv$logmnr_contentsビューを確認することで可能となります。

set line 6000
select SCN,TIMESTAMP,TABLE_NAME,OPERATION,SQL_REDO from v$logmnr_contents where operation!='INTERNAL';
       SCN TIMESTAMP TABLE_NAME      OPERATION       SQL_REDO
(略)
   1152964 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
(略)
   1153175 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153180 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
   1153181 15-APR-17      ROLLBACK       rollback;
(略)
   1153193 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153194 15-APR-17      COMMIT       commit;

略としてある場所には、裏で発行SQL文をv$sqlに格納するなど、システム側の動きがありました。

5.LogMinerを停止
最後にLogMinerを停止します。

SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR;
PL/SQL procedure successfully completed.

以上のような手順でログマイナーを使用できます。
オペミスなどのときにも確認に使えそうですね。

ただ、気になるのはシステムへの負荷。
今回試してみたのは「最小サプリメンタル・ロギング」でしたが、最小サプリメンタル・ロギングでは、マニュアルで読む限り、さほど負荷は大きくならないとなっています。もちろん、導入の際にはしっかり事前検証が必要でしょう。
行の内容までを記録できる「認識キー・ロギング」もありますが、こちらは最小サプリメンタル・ロギングと比べると負荷が大きくなるようです。

2017年2月26日日曜日

海外カンファレンスに行く(8):渡航を終えて

これまで6回に分けてブログに書いてきました、5泊7日の海外カンファレンス参加を終えました。
本場アメリカでのカンファレンス参加は刺激的なもので、遠く日本からの参加者への物珍しさもあり、親切にもしてもらえましたし、楽しませてもらいました。

特に、Welcome Receptionで技術の話を1対1で話すイベントは、英語力の無さがあって聞けなかったものがあったものの、アメリカのExpert達が語るデータベースへの思いだとか悩みだとかが聞けました。
日ごろ携わっている仕事でぶち当たる課題が、地球の裏側でも起きていて、同じように(もしくはもっと画期的な方法で)取り組まれているのだと思うと、不思議な思いがしました。
OracleOpenWorldなど、もっと大きな規模のカンファレンスもありますが、手作り感があり話し手と近いRMOUG Training Daysに参加できたことはとてもよかったです。

またお金をためて、私はデンバーに訪れることでしょう。
長々とした連載となりましたが、最後まで見てくださりありがとうございました。

2017年2月24日金曜日

海外カンファレンスに行く(7):RMOUG Training Days 2017参加3日目その2

前回のエントリの続きです。

[Session9: From 10046 to Real-Time Monitoring/ASH/Modern Techniques for Diagnostics]
10046トレース、ASHからリアルタイム監視をするセッションです。
スライドの文字が小さく、話す言葉も速くてついていけませんでした…。

[Session10: Bulletproof Your Data Guard Environment]
DataGuard環境を守れ! ということで、DataGuardのセッションです。
・Oracle7.3のホットスタンバイから始まったDataGuardは、11gでActive Data Guard、12cでFar Syncが採用された。
・Far Syncインスタンスは、プライマリDBとそれほど離れていない場所に作成する必要がある。
・DataGuardは12.2からブロック比較(Block Comparison)ツールがDGMGRLにできる。
・Active DataGuardでインメモリが使用できる。
・Active DataGuardでAWRが使用できる(今まではstatspackしか使えなかった)。
・DataGuardのよくある失敗として、スタンバイ適用前にデータファイルを削除したり、ASMディスク領域がExhaustion(疲労)したりといったことがある。
・リスナーの設定にSEND_BUF_SIZEとRECV_BUF_SIZEの設定をしてあげよう。
・ブロックチェンジトラッキングファイルをEnableにしてあげよう。
等など、書ききれないほどの注意点を教えてもらいました。

セッション後に質問して、通常、DataGuard環境を最大保護モードとすると、スタンバイDBがダウンするとプライマリDBもダウンすることになるが、Far Syncを最大保護モードに設定した場合、Far Syncインスタンスがダウンすると同様にプライマリもダウンするのか聞きましたが、この場合はダウンすることは無いようです。

[Session11: Virtualization 101 and Q&A]
・仮想化の適用は年々増加している。移行のプランにも物理より仮想化が増えてきている。
・新しいスキルへの適用をしていきましょう。DBAにとってはパーティショニングの考え方に似ているかもしれない。
スナップショット、コピーデータ管理、テストデータ管理などを図で説明頂きました。

これですべてのセッションが終わりました。この日はコンビニで夕飯を買って、最後の夜を過ごしました。

2017年2月23日木曜日

海外カンファレンスに行く(6):RMOUG Training Days 2017参加3日目その1

だいぶ長くなってしまいましたが、開催3日目の報告です。

<DAY5>
この日も朝からカンファレンスです。朝食会で声をかけてくれる人もちらほらいらっしゃり、心細さも無くなっていきました。
[Session6: Stabilizing Performance After Oracle 12c Upgrade]
・プラン・スタビリティのお話
・12cへのアップグレードの方法として、
 アップグレードするか、マイグレーションか
 マルチテナントを使用するか
 DBUAを使うか、コマンドラインでアップグレードするか
といった項目がある。
・テストを行う方法として、RAT(Real Application Testing)の活用、SQLパフォーマンスアナライザの使用のほか、テストしたSQLで性能悪化したものをASHやAWRで解析するなど考えられる。
・SPMを使用する方法も考えられます。SPMの実行に当たっては、ドキュメントやバグ、パッチの情報を見ておく必要がある。
・11gCBOはバグがあっていくつかは12cで直っているが、12cで全部実行計画が良くなるわけではない。

[Session7: Holistic Approach to Database Security]
・攻撃により、怪しいデータになったり、データロストしたり、パスワードが盗まれたりというリスクが考えられる。
・パスワードのフレーズもグーグルで検索できてしまうため、暗号化したから大丈夫とも言えなくなっている。
・DBを信頼できる状態にするために、Real Application SecurityやPL/SQLによる方法がある。
・SQLインジェンクション対策として、デリケートなデータとそうでないものを分けて、デリケートなものは権限をつけてDBへ見に行かせるようにする工夫が必要。
・どんなデータを扱っているかわかってしまうので、PL/SQLのコードに必要以上にコメントをつけない。
・参考としてSQLインジェクションのホワイトペーパーを見てみるとよい。

[Session8: Big Data Solution Architecture: Kafka, Spark, Cassandra, and Oracle Technology Integration]
Kafka、Spark、Cassandraをどう使うべきかというセッションでした。
・Kafkaはメッセージングシステムで、ソースのデータからクエリを使ってデータを引っ張っていく処理を行う。増分で引っ張るか、すべて引っ張るかを選択可能。
・Sparkは、Scala、JavaまたはPythonで書かれている。SparkのストリーミングをKafkaがひっぱって、Casandraのテーブルに入れるという動きになる。
・ETLとは、SparkSQLであり、SQLのデータを変形、フレームを変形させたりするときに使用する。
・Cassandraとは、NOSQLのデータベースである。CQLSH(Casandraのクエリ言語)というジョインがないSQLを使用する。
・Kafka、Cassandra、Sparkをなぜ使うか?
 - ライセンス費がかからない
 - 可用性・拡張性がある
 - マシンラーニングを使用できる
 - リアルタイムに分析、検索できる
 - 利用可能でない情報をひっぱることができる(この特性については、良い点と悪い点がある)

[Expert Lunch]
初日にRACのサービスについてのセッションをしてくださった、Bjoern Rost氏と食事をしました。某秋葉原のカンファレンスのTシャツを着ていたので、その話を少ししました。しかしながら昨日同様に話は長く続けられませんでした…。


長くなったので、次のエントリに分けます。

2017年2月22日水曜日

海外カンファレンスに行く(5):RMOUG Training Days 2017参加2日目その2

前回のエントリの続きです。

[Session4: Putting HCC Compression to Good Use]
ExadataのHCC圧縮に関するセッション。
・5000万件の行のログを保存する。インデックスを貼っている。書き込むが長く、コンテンション(ロックなど)が多いというシチュエーションでの話
・インデックスが原因だろうか。インデックスはなぜ必要か。ただデータを保存するだけであればインデックスは保存したいデータそのものではないから不要ではないか。
・Exadataから別マシンに移動する、データベースリンクで移動する、移動に3時間以上かかってしまうという状態。
・Exadataであれば、HCCでフルスキャンは速くなるため、インデックスを削減するという選択肢がありうる。
・今あるテーブルに対してHCC圧縮を行いたい場合は、パーティション交換をする必要がある。圧縮用テーブルを作成し、データを移動することで行う。パーティション交換はメタデータの変更のみである。

[Session5: Index and Redo Internals]
Oracle 12c R2 Solaris 11での検証結果によるもの。ドキュメントにないものもある。
・インデックスは木構造となっている。ルートブロックとブランチ(枝)、リーフ(葉)の3種類あるが、Tracedumpではブランチとリーフを確認できる。
・ルートブロックはブロックダンプにより確認ができる。
詳細は行の変更、ビットマップインデックス、インデックスのスプリットが発生した場合のパターンなどをスライドで図示してくださいましたが、ここで書いてよいものか判断に迷うものもあるため、詳細は渇愛とさせてください。

[Welcome Reception]
セッションの後はWelcome Receptionとして、軽食とお酒が用意しての歓談が行われました。
とはいえ、英語がそれほど話せない私としては、どうしよかなと思っていたのですが、このなかでNetwork Eventとして、技術的テーマにそって1対1で話すというイベントがありまして、拙いながらも話したり、相手のストーリーを聞くことができました。
DBAになりたいと語る大学生、Oracle ACEでありながらそのなかでトップ技術者に憧れ近づきたいと語るエキスパートの方など、その熱に圧倒されました。

[ODTUG Meetup]
このイベントの後、近くのカフェCraveでODTUGのMeetupがありました。参加していいのか聞いておどおどしていると、隣に座りなよと声をかけてくれる人がいて、スピーカーなのかとかこのカンファレンスの為だけに日本から来たのか等聞かれました。
あまり話についてはいけませんでしたが、ビールを飲みながらUser Groupの話ができ、楽しいひと時でした。
そのあともう1件店に連れて行ってもらいましたが、アメリカのエンジニアと触れあえる貴重なひと時でした。

21時30分ごろ解散。タクシーでホテルに帰りました。