前回のおさらい

前回はすぐに使える！DBデータの論理削除(2/4) 論理削除のしくみ(前編)ということで、In-Database Archivingが、ユーザから見たテーブル定義を変更せず、どのように削除フラグを管理するのかについて紹介しました。

今回は、ユーザが入力するSQLを変更せずに、削除フラグが設定されている行をselect文の結果からどのように除外するかを紹介します。

前提として、今回も引き続きOracle Databaseの知識がある人向け(マニア向け)の内容になっているかと思いますが、どうぞよろしくお願いいたします。

どのように削除フラグの設定された行を除外しているのか？

削除フラグは非表示のora_archive_state列に格納されていました。
ですが、ユーザが入力するSQLには、「ora_archive_stateが0ではない」といった条件は付いていません。
それでは、ora_archive_stateが0ではない行をどのように除外しているのでしょうか。

今回も実際にコマンドとその結果を見ながら進めていきたいと思います。
もし実際に検証用にDBを使用できるのであれば、是非実際に試してみてください！

まずは今回検証で使用するDB環境についてご紹介します。

DBバージョン	12.2.0.1.0
Oracle DB所有者ユーザ	oracle
ORACLE_BASE	/u01/app/oracle
ORACLE_HOME	/u01/app/oracle/product/12.2.0/dbhome_1
リスナー名	LISTENER
DBインスタンス名	orcl
Oracle SID	orcl
PDB名（※1）	orclpdb
PDB接続用接続記述子(※1)	orclpdb

※1
12c以降、Oracle DatabaseではCDBアーキテクチャを使用した構成が推奨となっています。
そのため、今回はPDBを一つだけ作成したシングルテナント構成としています。
シングルテナント構成であれば、CDBアーキテクチャの使用に特別なライセンスは必要ありません。
(PDBを複数作成するとOracle Multitenantオプションが必要となります。)
CDBアーキテクチャについては、後日、本ブログでも取り上げる予定です！

DBの構成によっては、実行結果が異なる場合があります。
また、第2回のコマンドを実行している前提のコマンド及び実行結果となっています。

それでは、実際にコマンドを見ていきましょう！

今回は少し複雑な作業をするため、手順簡略化のためscottユーザにDBA権限を付与します。

# scottユーザにDBA権限を付与します。
[oracle$] sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on 金 3月 23 20:02:39 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。

SQL> alter session set container = orclpdb;

セッションが変更されました。

SQL> grant dba to scott;

権限付与が成功しました。

SQL> quit
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Productionとの接続が切断されました。

今回は、DatabaseがSQLを実行する際、どのように処理を行うかを決定するCost Base Optimizerのトレースを取得し、select時の動作を確認します。
はじめに、削除フラグが設定された行も表示する状態でトレースを取得します。

# PDBにログインします
[oracle$] sqlplus scott/tiger@orclpdb

SQL*Plus: Release 12.2.0.1.0 Production on 金 3月 23 20:06:16 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.

最終正常ログイン時間: 金 3月  23 2018 20:06:06 +09:00


Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。

# 共有プールをフラッシュします。
SQL> alter system flush shared_pool;

システムが変更されました。

# 論理削除行も表示する設定にします。
SQL> alter session set row archival visibility = all;

セッションが変更されました。

# トレースの取得を設定します。
SQL> alter session set events '10053 trace name context forever, level 1';

セッションが変更されました。

SQL> select * from scott.emp where empno in (7369, 7499, 7521, 7566, 7654);

     EMPNO ENAME      JOB	       MGR HIREDATE	   SAL	     COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7369 SMITH      CLERK	      7902 80-12-17	   800
	20

      7499 ALLEN      SALESMAN	      7698 81-02-20	  1600	      300
	30

      7521 WARD       SALESMAN	      7698 81-02-22	  1250	      500
	30


     EMPNO ENAME      JOB	       MGR HIREDATE	   SAL	     COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7566 JONES      MANAGER	      7839 81-04-02	  2975
	20

      7654 MARTIN     SALESMAN	      7698 81-09-28	  1250	     1400
	30


# トレースの取得を終了します。
SQL> alter session set events '10053 trace name context off';

セッションが変更されました。

SQL> quit
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Productionとの接続が切断されました。

# トレースファイルを確認します。
[oracle$] ls -ltr $ORACLE_BASE/diag/rdbms/orcl/orcl/trace
[略]
-rw-r-----. 1 oracle oinstall 107715  3月 27 01:21 orcl_ora_24420.trc
[略]
# トレース取得時間帯に更新されている、「orcl_ora」から始まるtrcファイルのファイル名を確認します。

上記で確認したトレースファイルの内容を確認します。
ファイル内に、「Final query after transformations:******* UNPARSED QUERY IS *******」と出力されている個所の直後のSQLを確認します。

上記実行例では、以下のような出力が確認できます。
「SELECT “EMP”.”EMPNO” “EMPNO”,”EMP”.”ENAME” “ENAME”,”EMP”.”JOB” “JOB”,”EMP”.”MGR” “MGR”,”EMP”.”HIREDATE” “HIREDATE”,”EMP”.”SAL” “SAL”,”EMP”.”COMM” “COMM”,”EMP”.”DEPTNO” “DEPTNO” FROM “SCOTT”.”EMP” “EMP” WHERE “EMP”.”EMPNO”=7369 OR “EMP”.”EMPNO”=7499 OR “EMP”.”EMPNO”=7521 OR “EMP”.”EMPNO”=7566 OR “EMP”.”EMPNO”=7654」

次に、削除フラグが設定された行は表示しない設定で同様にトレースを取得します。

# PDBにログインします
[oracle$] sqlplus scott/tiger@orclpdb

SQL*Plus: Release 12.2.0.1.0 Production on 金 3月 23 20:06:16 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.

最終正常ログイン時間: 金 3月  23 2018 20:06:06 +09:00


Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。

# 共有プールをフラッシュします。
SQL> alter system flush shared_pool;

システムが変更されました。

# 論理削除行も表示しない設定にします。
SQL> alter session set row archival visibility = active;

セッションが変更されました。

# トレースの取得を設定します。
SQL> alter session set events '10053 trace name context forever, level 1';

セッションが変更されました。

SQL> select * from scott.emp where empno in (7369, 7499, 7521, 7566, 7654);

     EMPNO ENAME      JOB	       MGR HIREDATE	   SAL	     COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7499 ALLEN      SALESMAN	      7698 81-02-20	  1600	      300
	30

      7566 JONES      MANAGER	      7839 81-04-02	  2975
	20

      7654 MARTIN     SALESMAN	      7698 81-09-28	  1250	     1400
	30

# トレースの取得を終了します。
SQL> alter session set events '10053 trace name context off';

セッションが変更されました。

SQL> quit
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Productionとの接続が切断されました。

# トレースファイルを確認します。
[oracle$] ls -ltr $ORACLE_BASE/diag/rdbms/orcl/orcl/trace
[略]
-rw-r-----. 1 oracle oinstall 107715  3月 27 01:21 orcl_ora_24328.trc
[略]
# トレース取得時間帯に更新されている、「orcl_ora」から始まるtrcファイルのファイル名を確認します。

 

上記で確認したトレースファイルの内容を確認します。
ファイル内に、「Final query after transformations:******* UNPARSED QUERY IS *******」と出力されている個所の直後のSQLを確認します。

上記実行例では、以下のような出力が確認できます。
「SELECT “EMP”.”EMPNO” “EMPNO”,”EMP”.”ENAME” “ENAME”,”EMP”.”JOB” “JOB”,”EMP”.”MGR” “MGR”,”EMP”.”HIREDATE” “HIREDATE”,”EMP”.”SAL” “SAL”,”EMP”.”COMM” “COMM”,”EMP”.”DEPTNO” “DEPTNO” FROM “SCOTT”.”EMP” “EMP” WHERE “EMP“.”ORA_ARCHIVE_STATE”=’0′ AND (“EMP”.”EMPNO”=7369 OR “EMP”.”EMPNO”=7499 OR “EMP”.”EMPNO”=7521 OR “EMP”.”EMPNO”=7566 OR “EMP”.”EMPNO”=7654)」

削除フラグ付きの行を非表示にした場合、入力したSQL文には存在しない、「“EMP”.”ORA_ARCHIVE_STATE”=’0′」という条件が追加されていることが解ります。

Oracle DatabaseのCBOは、論理的に同じ意味を持たせたままSQLを変換する機能があり、上記はCBOによってSQLが書き換えられた場合の、変換後のSQLを確認しています。今回は論理的に同じ意味を保っていないため、この機能による変換とは異なると思われますが、ユーザが入力したSQLはDB内部で変換され、where句に論理フラグが設定されていない、という条件が追加されていることが解ります。

以上のことから、In-Database Archivingでは、テーブルに非表示列ora_archive_stateを追加して削除フラグを管理し、テーブルアクセス時は、DB内部でwhere句にora_archive_state = 0を追加することで、ユーザにSQLやテーブルの構成変更を意識させることなく、論理削除を実現していることが解ります。

本来であれば、ユーザがテーブルに列を追加し、SQLも作り替えなければいけない論理削除の導入を、DBが自動的に行ってくれる、便利な機能ですね。

Oracle Databaseで論理削除を実装するのであれば、テーブルやSQLの構造について特別な考慮が不要な本機能は効果的なのではないでしょうか。

次回は、削除フラグ管理用の列が増えたことに対し、索引を追加するとどのような動作になるか、確認します。

投稿者プロフィール

DBひとりでできるもん運営チーム

「DBひとりでできるもん」運営チームです。
「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
70名弱の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります！
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。

• Dbvisit Standby2024年11月18日【再掲載】【Dbvisit Standby】DRテスト機能のご紹介
• Dbvisit Standby2024年11月15日【再掲載】【Dbvisit Standby】メール通知機能のご紹介
• Dbvisit Standby2024年11月14日【再掲載】【Dbvisit Standby】製品の保守(サポート)について
• Dbvisit Standby2024年11月13日【再掲載】【Dbvisit Standby】製品アーキテクチャ（Auto Failover）