コーソル DatabaseエンジニアのBlog へようこそ

コーソル DatabaseエンジニアのBlogでは、 コーソル所属のDatabaseエンジニアである 渡部がOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。

コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス(コンサルティング、設計、構築など)、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。


コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。

hiring.png

コーソルについて知るためには・・・

エンジニアのスキル向上を支援する各種施策については・・・

コーソルのエンジニアの多くが従事する、「Oracle Database サポートエンジニアの仕事」の利点について知るためには・・・。

コーソルで働くことに興味を持たれた方は・・・

2014年07月26日

Oracle VMでリピータHUB - 仮想環境で Oracle Audit Vault and Database Firewall 環境を構築

Oracle Audit Vault and Database Firewall の検証環境をつくることになり、 Oracle VM 環境における仮想スイッチをリピータHUBのように動作させたくなりました。

Database Firewall Serverは、実行されたSQLの記録や置換のため、データベースサーバとクライアントでやり取りされるSQLトラフィックをキャプチャします。Database Firewall Serverの配置方法にはインラインとアウトオブバンドの2種類がありますが、現時点で一般的に使用されるのはアウトオブバンド方式のようです。

アウトオブバンド方式では、通常、スイッチのミラーポート機能を使って、データベースサーバとクライアントでやり取りされるパケットをDatabase Firewall Serverが接続されたポートにミラーリングします。そして、ミラーリングされたパケットをDatabase Firewall Serverがキャプチャします。

しかし、確認した限り、Oracle VM 環境で使用される仮想スイッチには、ミラーリングの機能が無いようでした。しかし、実現したいことは、データベースサーバとクライアントでやり取りされるパケットが、Database Firewall Serverが接続されたポートからも出力されることですので、ミラーリングの機能が無くても、仮想スイッチをリピータHUBのように動作させらればOKです。

リピータHUBでは、HUBを経由するすべてのパケットがすべてのポートから出力されます。一方、仮想スイッチは、各ポートに接続されているホストのMACアドレスを学習することによって、パケットを出力するポートを(うまく)制限してくれます。 逆にいえば、この学習機能を無効にすればよいわけです。

ということで、Oracle VM Serverから、

brctl setageing [仮想スイッチ名] 0

を実行します。すると、学習した結果を保持する期間が0になり、実質的にMACアドレスの学習機能が働かなくなります。 すなわち、スイッチがスイッチたるところの機能が実質的に無効になり、リピータHUBのように振る舞う形になります。

なお、brctl showstp [仮想スイッチ名] を実行すれば、ageing time (= 学習した結果を保持する期間) が0になっていることが確認できます。

[root@csov32s2 AVDF_lc121f]# brctl showstp 1011982358
1011982358
 bridge id              8000.000000000000
 designated root        8000.000000000000
 root port                 0                    path cost                  0
 max age                  19.99                 bridge max age            19.99
 hello time                1.99                 bridge hello time          1.99
 forward delay             0.00                 bridge forward delay       0.00
 ageing time               0.00 <====
 hello timer               0.94                 tcn timer                  0.00
 topology change timer     0.00                 gc timer                   0.94
 flags

参考

2014年07月24日

資料「PostgreSQL Internals」のレビューに協力させていただきました!

コミュニティ活動などでご縁があり、日本HPの篠田さんが執筆された資料「PostgreSQL Internals」のレビューに参加させていただくことになりました。

資料「PostgreSQL Internals」は以下のWebページに「PostgreSQLエンジニア向け!ストレージ内部構造および内部動作検証報告」として公開されています。

日本HPの篠田さんはOracle ACEでもあり、また、非常に多くのOracle Database関連書籍を執筆なされている、非常に著名なエンジニアです。今回ご縁があってご協力させていただき、非常に光栄です!

ちなみに・・・と言っては失礼ですが、PostgreSQL Internalsという同名のWikiも存在します。

このWikiを作成なされたのは、著名なPostgreSQLエンジニア(という枠には収まりきらない これまた凄い方ですが)の永安さんです。奇遇なことに、永安さんも日本HPの篠田さんが執筆された資料「PostgreSQL Internals」のレビューに参加なされていらっしゃいました。

PostgreSQLの動作に興味がある方は、是非、資料「PostgreSQL Internals」とWiki「PostgreSQL Internals」を併せてご覧いただければと思います。私も多くのことを勉強させていただきました。オススメです!

2014年07月02日

db tech showcase 大阪 2014にてOSS-DB Silver 試験セミナーの講師を務めさせていただきました!

弊社コーソルは、「CO-Solutions=共に解決する」の理念のもと、Oracle技術に特化した事業を展開しておりますが、現在PostgreSQL、MySQLなどのOSS-DB領域へも事業範囲を広げています。

事業範囲をOSS-DB領域へ広げる取り組みの一環として、2014年6月18日(水)~6月20日(金)に大阪で開催された、インサイトテクノロジー様主催 「db tech showcase 大阪 2014」にて、OSS-DB Silver試験セミナーの講師を務めさせていただきました。

当日の様子がLPI-Japan様のOSS-DBウェブサイトにまとめられています。

できるだけ包括的な資料をお届けしたかったので、資料の総ページ数が217ページ(!) に達してしまいました。 セミナーではすべてのトピックについて説明できませんでしたが、今後の試験勉強の役立てていただければ幸いです。

アンケートにご回答いただいた全員の方に「参考になった」「大変参考になった」と、ありがたい評価をいただきました。 また同様の機会がありましたら、是非セミナーを担当させていただければと思っております。PostgreSQL、OSS-DB技術者認定試験にご興味がある方にお役に立てれば幸いです。

セミナーの資料は、以下よりダウンロードできますので、ご興味があるかたはぜひぜひ。

さらに今年も2名がOracle OpenWorld へ!

コーソルは、2012年からUSのOracle OpenWorldにエンジニアを送り出しています。 2013年に引き続き、2014年も中堅エンジニアと若手エンジニアの2名がOracle OpenWorldへ行くことになりました!

昨年初めてOOWに参加したメンバー曰く「今年も参加したい・・・」だそうですが、残念ながら、別の方に行っていただくことになりました。

そういや今年は OakTable Worldあるのかな・・・

2014年03月18日

Oracle Database 10.2 追加のExtended Support

先のエントリで、Oracle Database 11.2のPremier Support終了と1年間限定の無償Extended Supportの提供について ご紹介しました。これと併せて、Oracle Database 10.2 に対して、若干イレギュラーなサポート提供がされていたことに気付いたのでご紹介します。

For Oracle Database 10.2 a limited service providing Severity 1 fixes will be available after July 2013. For details please refer to the Technical Support Policies. For more-detailed information on bug fix and patch release policies, please refer to the "Error Correction Support Policy" on MyOracle Support.

Oracle Database 10.2 に対しては、9.2, 11.2と同様に1年間 無償でExtended Supportが提供されていました。その後、有償のExtended Supportが提供されていました。

通常であれば、2013年7月までで有償のExtended Supportの提供は終了し、以後、Sustaing Supportが適用され、パッチ提供はNGとなるはずでした。しかし、 2013年8月から2015年7月まで、重要度1限定の限定サポートが提供されており、パッチ提供が可能になっています。

2013年8月からのサービスであり、今更感がありますが、サポートに絡めてご紹介しました。 なお、サポート契約をお持ちの方は以下のKROWNもあわせてごらんください。

修正履歴

  • 2014-3-18 : 表現を一部修正

Oracle Database 11.2のPremier Support終了と1年間限定の無償Extended Support

以下のOracle Technology Network Japan Blog ( および Upgrade your Database - NOW! ブログ) のエントリの通り、2015年1月で Oracle Database 11.2の Premier Support が終了します。

しかし、Premier Support 終了後も1年間限定で無償のExtended Supportが提供されますので、 2016年1月までは 実質的に Premier Supportに準ずるサポートを受けられます。 が、パッチが提供されるのは、原則的に最新のPatchset (すなわち 11.2.0.4 ) に限定されることに注意が必要です。

サポート契約を持ちの方は、以下のKROWNを合わせて御確認いただいた方がよいかと思います。

ただ、(この文章、「逆接」が多いですね・・・複雑なんです)パッチ提供期間については猶予期間などの例外事項もあるので、以下のKROWNおよびMOS Docを合わせて御確認ください。

お約束ですが・・・ やっぱり、計画的なアップグレードをお勧めします!

2014年03月07日

12c新機能 1ステップでの表のオンライン再定義

オンライン再定義はオブジェクトの定義変更をオンラインで実行できる Oracle Database Enterprise Editionで利用可能な機能です。非常に強力な機能ですが、 使用手順が若干面倒なのがちょっとした難点でした。(慣れればそれほどでもないのですが)

従来のバージョンでのオンライン再定義の手順概略は以下の通りです。

  1. DBMS_REDEFINITION.CAN_REDEF_TABLEプロシージャを起動して、表をオンラインで再定義できることを確認
  2. 今回の再定義で変更したい内容を表(仮表)を作成する。
    たとえば、今回のオンライン再定義で表の格納先表領域を移動したい場合は、移動先の表領域に同じ定義の表を作成する。
  3. DBMS_REDEFINITION.START_REDEF_TABLE でオンライン再定義を開始する。
    このタイミングでの元表のデータが仮表にコピーされる。
  4. 索引や制約などの依存オブジェクトと統計を元の表から仮表へコピーする。
  5. DBMS_REDEFINITIONFINISH_REDEF_TABLE でオンライン再定義を終了する。
    DBMS_REDEFINITION.START_REDEF_TABLE 実行後に元表に対して加えられた変更が、仮表に反映される。

12cでは、このような若干面倒な手順が、DBMS_REDEFINITION.REDEF_TABLEを実行するだけに単純化されます。

例:従来のオンライン再定義の手順で格納先表領域を変更する

以下の手順は MOS Doc:1357742.1 を参考にしています。まず、格納先表領域を変更したい表ORIGINALを作成し、データを投入しておきます。

SQL> create table ORIGINAL (
  2    COL1 NUMBER PRIMARY KEY,
  3    COL2 VARCHAR2(1000))
  4    TABLESPACE SYSTEM;

表が作成されました。

SQL> insert into ORIGINAL values(1,'AAA');
1行が作成されました。

SQL> commit;

コミットが完了しました。

次に仮表を作成します。ここでは、(誤って)SYSTEM表領域に作成した表をUSERS表領域に移動ししたい状況を想定します。ですので、仮表はUSERS表領域に作成します。列定義は同様とします。

SQL> create table INTERIM (
  2    COL1 NUMBER,
  3    COL2 VARCHAR2(1000))
  4    TABLESPACE USERS;

表が作成されました。


SQL> col table_name format a16
SQL> set lines 80
SQL> SELECT TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES;

TABLE_NAME       TABLESPACE_NAME
---------------- ------------------------------
INTERIM          USERS
ORIGINAL         SYSTEM

DBMS_REDEFINITION.CAN_REDEF_TABLEでオンライン再定義が可能か確認し(エラーがなければOK)、DBMS_REDEFINITION.START_REDEF_TABLEでオンライン再定義を開始します。

SQL> SET SERVEROUTPUT ON

SQL> exec DBMS_REDEFINITION.CAN_REDEF_TABLE('RYWATABE','ORIGINAL', DBMS_REDEFINITION.CONS_USE_PK);
PL/SQLプロシージャが正常に完了しました。

SQL> BEGIN
  2     DBMS_REDEFINITION.START_REDEF_TABLE(
  3                    uname => 'RYWATABE',
  4                    orig_table => 'ORIGINAL',
  5                    int_table => 'INTERIM',
  6                    options_flag => DBMS_REDEFINITION.CONS_USE_PK);
  7  END;
  8  /

PL/SQLプロシージャが正常に完了しました。

仮表には、索引や制約が設定されていないので、DBMS_REDEFINITION.COPY_TABLE_DEPENDENTSで、元表からコピーします。


SQL> DECLARE
  2     error_count pls_integer := 0;
  3  BEGIN
  4     DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS('RYWATABE', 'ORIGINAL', 'INTERIM',
  5        dbms_redefinition.cons_orig_params, TRUE,TRUE,TRUE,FALSE, error_count);
  6     DBMS_OUTPUT.PUT_LINE('errors := ' || TO_CHAR(error_count));
END;
  8  /
errors := 0

PL/SQLプロシージャが正常に完了しました。

現段階では、オンライン再定義は実行中の状態となりますが、この状態で、元表に対してDMLを実行できます。元表に加えた更新は、この時点では仮表に反映されません。

SQL> col col2 format a16
SQL>
SQL> SELECT * FROM ORIGINAL;

      COL1 COL2
---------- ----------------
         1 AAA

SQL> SELECT * FROM INTERIM;

      COL1 COL2
---------- ----------------
         1 AAA

SQL> insert into ORIGINAL values(2,'BBB');

1行が作成されました。

SQL> commit;

コミットが完了しました。

SQL> SELECT * FROM ORIGINAL;

      COL1 COL2
---------- ----------------
         1 AAA
         2 BBB

SQL> SELECT * FROM INTERIM;

      COL1 COL2
---------- ----------------
         1 AAA

DBMS_REDEFINITION.FINISH_REDEF_TABLEを実行して、オンライン再定義を終了します。この時点で、元表に加えられた変更が仮表に反映されます。

SQL> exec DBMS_REDEFINITION.FINISH_REDEF_TABLE('RYWATABE','ORIGINAL','INTERIM');

PL/SQLプロシージャが正常に完了しました。

SQL> SELECT * FROM ORIGINAL;

      COL1 COL2
---------- ----------------
         1 AAA
         2 BBB

SQL> SELECT * FROM INTERIM;

      COL1 COL2
---------- ----------------
         1 AAA
         2 BBB

例:1ステップでの表のオンライン再定義の手順で格納先表領域を変更する(DBMS_REDEFINITION.REDEF_TABLE)

次に、Oracle Database 12c (12.1.0.1)で導入された、1ステップでの表のオンライン再定義で同様のことをやってみます。まず、テーブルとデータを準備します。仮表を準備する必要はありません。

SQL> create table ORIGINAL (
  2    COL1 NUMBER PRIMARY KEY,
  3    COL2 VARCHAR2(1000))
  4  TABLESPACE SYSTEM;

表が作成されました。

SQL> insert into ORIGINAL values(1,'AAA');

1行が作成されました。

SQL> commit;

コミットが完了しました。

SQL> SELECT TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES;

TABLE_NAME       TABLESPACE_NAME
---------------- ------------------------------
ORIGINAL         SYSTEM

DBMS_REDEFINITION.REDEF_TABLEを実行します。ここで実行したい定義変更は表領域の移動なので、引数table_part_tablespaceに'USERS'を指定しています。指定する引数は実行したい定義変更により異なります。詳細はマニュアルをご確認ください。

SQL> BEGIN
  2    DBMS_REDEFINITION.REDEF_TABLE(
  3      uname                      => 'RYWATABE',
  4      tname                      => 'ORIGINAL',
  5      table_part_tablespace      => 'USERS'
  6      );
  7  END;
  8  /

PL/SQLプロシージャが正常に完了しました。

SQL> SELECT TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES;

TABLE_NAME       TABLESPACE_NAME
---------------- ------------------------------
ORIGINAL         USERS

注意点

このように便利な1ステップでの表のオンライン再定義ですが、 再定義におけるオブジェクト定義変更の内容にかなり制約があることに注意が必要です。

  • 表、パーティション、索引、LOB列などの表領域の変更
  • 表、パーティション、索引キー、LOB列などの圧縮タイプの変更
  • LOB列の場合、SECUREFILEまたはBASICFILE記憶域の変更

参考

上記以外の列の追加や削除などのオブジェクト定義変更をオンライン再定義で実行したい場合、残念ながら従来の手順で実行する必要があります。

2014年03月06日

12c新機能 同一列に対する複数索引

Oracle Database 12cより 同じ列に対して複数の索引を作成できるようになりました。 例えば、同じ列に対してBツリー索引とビットマップ索引を作成できます。従来は 同じ列に対してBツリー索引とビットマップ索引を作成しようとすると、 ORA-01408: such column list already indexed というエラーが発生していました。

ただし、この機能は、Oracle Database 11g R1 で導入された不可視索引と連携して 使用することを想定した機能です。私は、この機能を、不可視索引がOracle Database 11g において不十分であった点を補う位置づけであるととらえています。

さっそく動作を確認してみましょう。まず、テーブルとデータを準備します。

SQL> create table tab2 (n number, c varchar(80));
Table created.

SQL> insert into tab2 select 1, 'aaa' from dual
  2    connect by level <= 999;

999 rows created.

SQL> insert into tab2 values(999, 'aaa');

1 row created.

SQL> commit;

Commit complete.

テーブルtab2のn列に対して、Bツリー索引idx2tとビットマップ索引idx2bを作成しようとしますが・・・

SQL> create index idx2t on tab2(n);

Index created.

SQL> create bitmap index idx2b on tab2(n);
create bitmap index idx2b on tab2(n)
                                  *
ERROR at line 1:
ORA-01408: such column list already indexed

過去バージョンと同様にORA-01408が発生してビットマップ索引を作成できません。同じ列に複数の索引を作成するためには、索引の作成前に既存の索引をINVISIBLEにする必要があるのです。

さて、一応この状態で、索引が使用されることを確認しておきます。

 
SQL> exec dbms_stats.gather_table_stats(null, 'TAB2');

PL/SQL procedure successfully completed.

SQL> explain plan for SELECT count(*) FROM tab2 WHERE n = 1;

Explained.

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1847674165

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |     1 |     4 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |       |     1 |     4 |            |          |
|*  2 |   INDEX RANGE SCAN| IDX2T |   500 |  2000 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("N"=1)

14 rows selected.

Bツリー索引が使われていることがわかります。

このBツリー索引をINVISIBLEにして、同じ列にビットマップ索引を作成します。

SQL> alter index idx2t invisible;

Index altered.

SQL> create bitmap index idx2b on tab2(n);

Index created.

今度はビットマップ索引を正常に作成できます。

不可視索引にアクセスするかどうかを制御するoptimizer_use_invisible_indexesはデフォルトでFALSEです。この状態では、不可視(INVISIBLE)状態の索引は使われません。

SQL> show parameter optimizer_use_invisible_indexes

NAME                                 TYPE
------------------------------------ -----------
VALUE
----------------------------------------------------------------------------------------------------
optimizer_use_invisible_indexes      boolean
FALSE
SQL> explain plan for SELECT count(*) FROM tab2 WHERE n = 1;

Explained.

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 703723870

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |       |     1 |     4 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE               |       |     1 |     4 |            |          |
|   2 |   BITMAP CONVERSION COUNT     |       |   500 |  2000 |     1   (0)| 00:00:01 |
|*  3 |    BITMAP INDEX FAST FULL SCAN| IDX2B |       |       |            |          |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("N"=1)

15 rows selected.

不可視索引を使用しようと、明示的にヒントでその索引を指定しても、使用されません。

SQL> explain plan for SELECT /*+ INDEX(tab2 idx2t) */ count(*) FROM tab2 WHERE n = 999;

Explained.

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1400846200

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |     1 |     4 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE             |       |     1 |     4 |            |          |
|   2 |   BITMAP CONVERSION COUNT   |       |   500 |  2000 |     1   (0)| 00:00:01 |
|*  3 |    BITMAP INDEX SINGLE VALUE| IDX2B |       |       |            |          |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("N"=999)

15 rows selected.

不可視索引を使用するには、optimizer_use_invisible_indexes を TRUEに設定する必要があります。

SQL> ALTER SESSION SET optimizer_use_invisible_indexes = TRUE;

Session altered.

SQL> explain plan for SELECT /*+ INDEX(tab2 idx2t) */ count(*) FROM tab2 WHERE n = 999;

Explained.

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1847674165

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |     1 |     4 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |       |     1 |     4 |            |          |
|*  2 |   INDEX RANGE SCAN| IDX2T |   500 |  2000 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("N"=999)

14 rows selected.

SQL> explain plan for SELECT count(*) FROM tab2 WHERE n = 1;

Explained.

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 703723870

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |       |     1 |     4 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE               |       |     1 |     4 |            |          |
|   2 |   BITMAP CONVERSION COUNT     |       |   500 |  2000 |     1   (0)| 00:00:01 |
|*  3 |    BITMAP INDEX FAST FULL SCAN| IDX2B |       |       |            |          |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("N"=1)

15 rows selected.

12c新機能 不可視列 - Invisible column

Oracle Database 12cより 不可視(INVISIBLE)という列の属性が追加され、実体としては存在するけれども、明示的に指定しない限り見えない列を作ることができるようになりました。

動作を確認してみましょう。なお、以下のブログエントリを大いに参考にしています。

SQL> CREATE TABLE t1
  2  (
  3    c1 NUMBER,
  4    c2 NUMBER,
  5    c3 NUMBER INVISIBLE,
  6    c4 NUMBER
  7  );

Table created.

SQL> set lines 80
SQL> desc t1
           Name                            Null?    Type
           ------------------------------- -------- ----------------------------
    1      C1                                       NUMBER
    2      C2                                       NUMBER
    3      C4                                       NUMBER

SQL> col column_name format a16
SQL> SELECT column_name, hidden_column FROM ALL_TAB_COLS WHERE table_name = 'T1';

COLUMN_NAME      HID
---------------- ---
C4               NO
C3               YES
C2               NO
C1               NO

列c3にINVISIBLE属性を指定し、不可視列にしています。SQL*Plusのdescでは列c3は表示されません。 また、ALL_TAB_COLSを確認する列c3はhidden_column='YES'となっていることがわかります。

SQL> INSERT INTO t1 (c1,c2,c3,c4) VALUES (11,12,13,14);

1 row created.

SQL> commit;

Commit complete.

SQL> SELECT c1,c2,c3,c4 FROM t1;

        C1         C2         C3         C4
---------- ---------- ---------- ----------
        11         12         13         14

SQL> UPDATE t1 SET c3=23;

1 row updated.

SQL> commit;

Commit complete.

SQL> SELECT c1,c2,c3,c4 FROM t1;

        C1         C2         C3         C4
---------- ---------- ---------- ----------
        11         12         23         14

しかし、c3列を明示的に指定すれば、更新などは可能です。

なお、SQL*PlusのCOLINVISIBLEをONにすると、 不可視列がdescコマンドで表示されるようになります。

SQL> SET COLINVISIBLE ON
SQL> desc t1
           Name                            Null?    Type
           ------------------------------- -------- ----------------------------
    1      C1                                       NUMBER
    2      C2                                       NUMBER
    3      C4                                       NUMBER
    4      C3 (INVISIBLE)                           NUMBER

SQL> SET COLINVISIBLE OFF

c3列を明示的に指定しない場合は、あたかも列c3がいないかのように振る舞います。

SQL> INSERT INTO t1 VALUES (11,12,13,14);
INSERT INTO t1 VALUES (11,12,13,14)
            *
ERROR at line 1:
ORA-00913: too many values


SQL> SELECT * FROM t1;

        C1         C2         C4
---------- ---------- ----------
        11         12         14

注意点

マニュアルでも触れられていますが、不可視(INVISIBLE)の列を可視(VISIBLE)にすると、 列の順序が変わる点に注意が必要です。
SQL> ALTER TABLE t1 MODIFY c3 VISIBLE;

Table altered.

SQL> desc t1
           Name                            Null?    Type
           ------------------------------- -------- ----------------------------
    1      C1                                       NUMBER
    2      C2                                       NUMBER
    3      C4                                       NUMBER
    4      C3                                       NUMBER

列の順序が変わるということは、列名を明示しないSQL、SELECT * FROM .. や INSERT INTO 表名 VALUES(...)の振る舞いが 期待した動作にならないことを示します。要注意ですね。

Oracle Databaseオプションの構成を各バージョンで比較した

タイトルの通りですが、Oracle Databaseの各バージョンで、オプションの構成を比較しました。

12.1ではかなりオプションが削減されているように見えます。

                                                   12.1    11.2    11.1  10.2 
Oracle Active Data Guard                           ○      ○      ○    -     
Oracle Advanced Analytics(*2)                      ○      -      -    -
Oracle Advanced Compression                        ○      ○      ○    -     
Oracle Advanced Security                           ○      ○      ○    ○     
Oracle Content Database Suite                      -      -      -    ○     
Oracle Data Mining                                 -      ○      ○    ○     
Oracle Data Profiling and Qualityオプション        -      ○      ○    ○     
Oracle Data Watch and Repair Connector             -      ○      ○    ○     
Oracle Database Vault                              ○      ○      ○    ○     
Oracle In-Memory Database Cache                    ○      ○      ○    ○     
Oracle Label Security                              ○      ○      ○    ○     
Oracle Multitenant                                 ○      -      -    -     
Oracle On-Line Analytical Processing(OLAP)       ○      ○      ○    ○     
Oracle Partitioning                                ○      ○      ○    ○     
Oracle RAC One Node                                ○      ○      -    -     
Oracle Real Application Clusters(Oracle RAC)     ○      ○      ○    ○     
Oracle Real Application Testing                    ○      ○      ○    ○     
Oracle Records DB                                  -      -      -    ○     
Oracle Spatial                                     ○(*1)  ○(*1)  ○    ○     
Oracle Total Recall                                -      △(*3)  ○    -     
  (*1) Oracle Spatial and Graphと名称変更    
  (*2) おそらくOracle Data Mining に機能追加して名称変更した
  (*3) Oracle Advanced Compressionに統合? (11.2リリース当初は存在しような記憶がありますが・・)

Oracle Total Recall オプション(=フラッシュバックデータアーカイブ; FDA)のライセンスが、ちょっと複雑なので追記しておきます。

            FDA                         FDA+履歴の最適化
            --------------------------- -----------------------------
12.1        EE                          EE + Advanced Compression
11.2.0.4    EE                          EE + Advanced Compression
11.2(*a)    EE + Advanced Compression   ‐ (*b)
11.1        EE + Total Recall           ‐ (*b)

  (*a) 11.2.0.1-11.2.0.3
  (*b) 履歴の最適化は11.2.0.4より導入

修正履歴

  • 2014/3/7: フラッシュバックデータアーカイブについて追記+11.2のオプション情報が古かったので修正

プロフィール

Ryota WATABE / 渡部 亮太

100x100.jpg

投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。

  • Oracle Database 12c Administrator Certified Professional (ORACLE MASTER Gold Oracle Database 12c)
  • Oracle Database 11g Certified Master (ORACLE MASTER Platinum Oracle Database 11g)
  • Oracle Database 11g Data Warehousing Certified Implementation Specialist
  • Oracle Database 11g Security Certified Implementation Specialist
  • Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator
  • Oracle Certified Expert, Oracle Exadata X3 Administrator
  • Oracle Exadata 11g Certified Implementation Specialist
  • Oracle Database 10g Certified Master (ORACLE MASTER Platinum Oracle Database 10g)
  • Oracle Database 10g Managing Oracle on Linux Certified Expert
  • Oracle Database 10g: Real Application Clusters Administrator Certified Expert
  • Oracle PL/SQL Developer Certified Associate
  • Oracle Certified Professional, MySQL 5 Database Administrator
  • Cisco Certified Network Associate (CCNA)
  • Cisco Certified Network Associate Security (CCNA Security)
  • OSS-DB Gold (PostgreSQL 9)
  • OSS-DB Silver (PostgreSQL 9)
  • LPIC 301 Core (Linux)
  • Oracle Certified Java Programmer, Silver SE 7

カテゴリー

Powered by
Movable Type 3.34