2012年2月16日木曜日

11gにおける一時表領域がSYSTEM表領域なユーザに関する考察#3


(今回はいつにも増して下らないネタ…)

11.2.0.3.0時代、あるところに、ユーザのデフォルト表領域がSYSTEM表領域で、
一時表領域もSYSTEM表領域のユーザがおったそうな。。

前回はDBを新規に作ってみました。
SYSTEM表領域をディクショナリ管理表領域で作成すると、
TEMP表領域を作成しないという選択が出来ることが分かりました。

また、SQLリファレンスにある通り、
ユーザの作成時に一時表領域の指定を省略した場合、かつ
データベースのデフォルトの一時表領域が指定しなかった場合は、
ユーザの一時セグメントはSYSTEM表領域に格納されました。

検証を通して分かったことを纏めます。
1)DBCAでDBを作成しようとするとSYSTEM表領域の
 エクステント管理はローカル管理
2)データベースがローカル管理となっている場合は、一時表領域が必要
3)データベース作成時に一時表領域が作成される場合は
 ユーザ作成時に一時表領域の指定を省略しても
 ユーザの一時表セグメントはデータベース作成時の一時表領域に格納される

つまり、何らかの理由でディクショナリ管理のSYSTEM表領域で
データベースを作成したが、
その際に一時表領域は作成しなかった。という状況が考えられる。


11gのSYSTEM表領域のエクステント管理のデフォルトはローカル管理であること、
管理者が意図的にユーザの一時表領域に、SYSTEM表領域を指定する可能性は
低いと考えられることから、
「過去環境のDBを作成したDB作成スクリプトを再利用して新環境のDBを作成した。」
というのが原因なのだろうか。
ただ、過去のバージョンにおいてもユーザの一時セグメントの格納先が
SYSTEM表領域だった可能性は少ないと思うので(のはず)、
ユーザの作成スクリプトかなんかを流す順序に問題があり、
追加でデータベースのデフォルト表領域を作成するスクリプトを流す前に、
ユーザ作成スクリプトを実行してしまっていた。
というところだろうか。。

なんとなく、ありそうな話だ。。。


で、何が言いたいかというと、

移行前の過去バージョンのDB作成スクリプトが、
SYSTEM表領域をディクショナリ管理で作っているようなことがなく、
一時表領域を作っていないようなもので、
それをそのまま使って新環境に11gのDBを作ろうとしない限りは、
ユーザの一時セグメントの格納先がSYSTEM表領域になっていて、
気が付いたら一般ユーザのソート処理をくらっていて、
気が付いたらSYSTEM表領域が肥大化しているということは、
まずありえない。



かなりまぐれとかなんやかんやが続かない限りは、きっとね。

11gにおける一時表領域がSYSTEM表領域なユーザに関する考察#2

(今回はいつにも増して下らないネタ…)

11.2.0.3.0時代、あるところに、ユーザのデフォルト表領域がSYSTEM表領域で、
一時表領域もSYSTEM表領域のユーザがおったそうな。。

前回は既存のDB環境で色々やってみましたが、
一時表領域がSYSTEM表領域なユーザは作れませんでした。
どうやらデータベースのデフォルトの一時表領域が関係してそうなのは
分かりましたが、その設定をSYSTEM表領域に変えられません。

うまくいかないので、DBそのものから作り直してみます。


■環境
Windows7 64Bit
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64Bit

データベースの作成⇒カスタムデータベースの作成⇒表領域作成画面
TEMP表領域をGUIから削除します。


むかっ。 じゃあいい、DB作成スクリプト生成して、 スクリプト編集してTEMP作成する部分を削除して実行してやるっ! CREATEDB.SQL抜粋 ========================================================================= ・・・ MAXDATAFILES 100 DATAFILE 'C:\app\oracle\oradata\orcl2\system01.dbf' SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SYSAUX DATAFILE 'C:\app\oracle\oradata\orcl2\sysaux01.dbf' SIZE 600M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE 'C:\app\oracle\oradata\orcl2\undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED CHARACTER SET JA16SJISTILDE ・・・ ========================================================================= 行1でエラーが発生しました。: ORA-12900: ?????????????????????????????????????? ========================================================================= ORA-12900: ローカル管理データベース用のデフォルトの       一時表領域を指定する必要があります。 原因: ローカル管理データベースには、SYSTEM表領域以外に一時表領域が必要です 処置: ローカル管理データベースの作成時に、 デフォルトの一時表領域を指定してください。 ========================================================================= むかむかっ。 SQLリファレンスのCREATE DB文を確認します。 ========================================================================= extent_management_clause この句を使用すると、ローカル管理SYSTEM表領域を作成できます。 この句を指定しない場合、SYSTEM表領域はディクショナリ管理となります。 注意: ローカル管理SYSTEM表領域を作成すると、 この表領域をディクショナリ管理に変更することはできません。 このデータベース内に別のディクショナリ管理表領域を作成することも できません。 この句を指定した場合、ローカル管理のSYSTEM表領域には 一時セグメントを格納できないため、データベースにデフォルトの 一時表領域が必要になります。 EXTENT MANAGEMENT LOCALを指定して、DATAFILE句を指定しない場合は、 default_temp_tablespace句を省略できます。 Oracle Databaseは、データファイル・サイズが10MBで、 自動拡張を使用禁止にした状態で、TEMPという一時表領域を作成します。 EXTENT MANAGEMENT LOCALおよびDATAFILEの両方の句を指定する場合は、 default_temp_tablespaceを指定し、その表領域のデータファイルを 明示的に指定する必要があります。 default_temp_tablespace この句を指定すると、データベースのデフォルトの一時表領域を作成できます。 Oracle Databaseは、この一時表領域に対して、別の一時表領域を指定していない ユーザーを割り当てます。 この句を指定しないと、 データベースがローカル管理のSYSTEM表領域の作成時に、 デフォルトの一時表領域を自動的に作成しない場合、 SYSTEM表領域がデフォルトの一時表領域になります。 ========================================================================== なんか最後の三行は矛盾している気もするけど、 とにかくSYSTEM表領域がローカルだと、ローカル管理データベースとなり、 SYSTEM表領域以外に一時表領域が必要というなら、 ディクショナリ管理でSYSTEM表領域作ってやろうじゃない。 CREATEDB.SQL抜粋 ・・・ MAXDATAFILES 100 DATAFILE 'C:\app\oracle\oradata\orcl2\system01.dbf' SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED  EXTENT MANAGEMENT LOCAL ←削除 SYSAUX DATAFILE 'C:\app\oracle\oradata\orcl2\sysaux01.dbf' SIZE 600M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE 'C:\app\oracle\oradata\orcl2\undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED CHARACTER SET JA16SJISTILDE ・・・ DBが作成されました。 データベースのデフォルトの表領域を確認します。 SQL> select property_value,property_name from database_properties 2 where property_name like '%TABLESPACE%'; PROPERTY_VALUE PROPERTY_NAME --------------- ----------------------------- SYSTEM DEFAULT_TEMP_TABLESPACE SYSTEM DEFAULT_PERMANENT_TABLESPACE いい感じ。
SQL> create user hoge2 identified by hoge2;

ユーザーが作成されました。

SQL> select username,default_tablespace,temporary_tablespace from dba_users
  2  where username='HOGE2';
  
  
USERNAME   DEFAULT_TABLESPACE        TEMPORARY_TABLESPACE
---------- ------------------------- -------------------------
HOGE2      SYSTEM                    SYSTEM

1行が選択されました。



そう。これ。これ待ってた。


冷静になって、DBCAの表領域作成箇所で、
SYSTEM表領域のエクステント管理をディクショナリ管理に変更して、
TEMP表領域の削除を実施したら。エラーなく削除できました。
(わざとDB作成スクリプトの例を出しているのですが。念のため)


次回、検証を通して一時表領域がSYSTEMなユーザがなぜできたかを考えます。

2012年2月15日水曜日

11gにおける一時表領域がSYSTEM表領域なユーザに関する考察#1

(今回はいつにも増して下らないネタ…)

11.2.0.3.0時代、あるところに、ユーザのデフォルト表領域がSYSTEM表領域で、
一時表領域もSYSTEM表領域のユーザがおったそうな。。

SYSTEM表領域が一時表領域なのはなんか怖い・・・?
どうしてこんなユーザがいるんだろう??
どう作ったらこんなことになるのだろう??


やってみます。

■環境
Windows7 64Bit
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64Bit

まずは、素直にユーザ作成時にSYSTEM表領域を指定してユーザを作ってみます。
SQL> create user hoge2 identified by hoge2 
  2 default tablespace system temporary tablespace system;

create user hoge2 identified by hoge2 
*
行1でエラーが発生しました。:
ORA-12911: 永続表領域は一時表領域に指定できません

む。。

SQLリファレンスより、CREATE USER文のTABLESPACEに関係する部分を確認します。

======================================================================
DEFAULT TABLESPACE句
ユーザーのスキーマ内に作成されるオブジェクトを格納する
デフォルトの表領域を指定します。
この句を省略した場合、ユーザーのオブジェクトはデータベースの
デフォルトの表領域に格納されます。
データベースのデフォルトの表領域が指定されていない場合、
ユーザーのオブジェクトはSYSTEM表領域に格納されます。

デフォルトの表領域の制限事項: 
ローカル管理の一時表領域(UNDO表領域を含む)またはディクショナリ管理の
一時表領域は、ユーザーのデフォルトの表領域として指定できません。

TEMPORARY TABLESPACE句
ユーザーの一時セグメントが確保される表領域または表領域グループを指定します
この句を省略した場合、ユーザーの一時セグメントはデータベースの
デフォルトの一時表領域に格納されます。
データベースのデフォルトの一時表領域が指定されていない場合は、
SYSTEM表領域に格納されます。
tablespaceに、ユーザーの一時セグメント表領域を指定します。
tablespace_group_nameを指定すると、ユーザーは、tablespace_group_nameで
指定された表領域グループ内の任意の表領域に一時セグメントを
保存できるようになります。

一時表領域の制限事項: 
この句には、次の制限事項があります。
表領域は一時表領域で、標準ブロック・サイズである必要があります。
表領域は、UNDO表領域または自動セグメント領域管理の表領域にできません。
======================================================================

表領域を指定しないでユーザを作ってみる。
※この時点で既に現実的でない気もしなくはない。。

SQL> create user hoge identified by hoge;
ユーザーが作成されました。

SQL>select username,default_tablespace,temporary_tablespace from dba_users
   2 where username='HOGE'

USERNAME   DEFAULT_TABLESPACE   TEMPORARY_TABLESPACE
---------- -------------------- --------------------
HOGE       USERS                TEMP

むむ。
どうやら、データベースのデフォルトの表領域と
デフォルトの一時表領域が指定されているようだ。

SQL> select property_value,property_name from database_properties
   2 where property_name like '%TABLESPACE%';

PROPERTY_VALUE  PROPERTY_NAME
--------------- ------------------------------
TEMP            DEFAULT_TEMP_TABLESPACE
USERS           DEFAULT_PERMANENT_TABLESPACE


強引に変えられないかなぁ

SQL> alter user hoge default tablespace system;
ユーザーが変更されました。

SQL> alter user hoge temporary tablespace system;
ORA-12911: 永続表領域は一時表領域に指定できません 

SQL>select username,default_tablespace,temporary_tablespace from dba_users
  2   where username='HOGE';

USERNAME   DEFAULT_TABLESPACE   TEMPORARY_TABLESPACE
---------- -------------------- --------------------
HOGE       SYSTEM               TEMP

むむむ。

じゃ、デフォルトの表領域を変えて、ユーザを新規に作ってみるか

SQL> alter database DEFAULT TABLESPACE system
データベースが変更されました。

SQL> alter database DEFAULT TEMPORARY TABLESPACE system
行1でエラーが発生しました。:
ORA-12901: デフォルトの一時表領域はTEMPORARY型である必要があります。

むむむむ。

じゃ、デフォルトの一時表領域をNULLにしてみるか

SQL>  alter database DEFAULT TEMPORARY TABLESPACE ;
 alter database DEFAULT TEMPORARY TABLESPACE
                                            *
行1でエラーが発生しました。:
ORA-02216: 表領域名が必要です。


SQL>  alter database DEFAULT TEMPORARY TABLESPACE '';
 alter database DEFAULT TEMPORARY TABLESPACE ""
                                             *
行1でエラーが発生しました。:
ORA-01741: 長さゼロの識別子は無効です。

SQL> select property_value,property_name from database_properties
  2  where property_name like '%TABLESPACE%';

PROPERTY_VALUE  PROPERTY_NAME
--------------- ------------------------------
TEMP            DEFAULT_TEMP_TABLESPACE
SYSTEM          DEFAULT_PERMANENT_TABLESPACE


むむむむむ。

NULLに出来ないなら、TEMP削除してやるっ

SQL> drop tablespace temp;
drop tablespace temp
*
行1でエラーが発生しました。:
ORA-12906: デフォルトの一時表領域は削除できません。


むむむむむむ。


こうなったら、USERSとTEMPがないDB作ってやる!!!!

2012年2月14日火曜日

HAIP(Highly Available virtual IP)その6

HAIP(Highly Available virtual IP)その5のつづき

忘れた頃にHAIPばなし。
知り合いが(゚∀゚ノツ HAIP HAIP☆
とかやっちゃっているので、ちょっとよもや話を。



KROWN#156243
================================================================
HAIP リソースが ONLINEにならず 2ノード目以降の Clusterwareが起動しない
対象リリース:11.2.0.2系
================================================================
ノード間のClusterwareの停止からの起動順序によって発生するようです。

まぁ、もう11.2.0.3.0が出てるし、大丈夫ですかね。

HAIPも11.2.0.3.0ならね。

・・・。

なんて安心するのは甘いのであった。。。


BUG:13555570
AFTER RECOVERING PRIVATE LAN FAILURE, GI ON NODE#2 DID NOT STARTED.


インターネクト障害時からの障害復旧時に、
Clusterから外されたノード2側のHAIPが自動起動起動せず 、
CRS(Grid Infrastructure)が起動しないため、Clusterに参加できない。
また、ノード2のサーバ再起動を行っても状況は変わらない。

ひどし。。。

HAIPが起動できないということは、すなわちインターコネクト通信が
出来ないってことなので、当然Clusterには参加できない。

どないすればええねん!!
というのがBUG:13555570。


一歩踏み込んで記載します。

■復旧手順
1)インターコネクト障害を発生
2)ノード1のインターコネクト復旧するが、ノード2のHAIPならびにCRS起動せず
----[事象発生]------

3)ノード1のインターコネクト用NIC停止(or抜線)。
4)ノード2のCRSを強制停止
 ⇒crsctl stop crs -f
  以前の記事で紹介したMOSのドキュメント手順にあるコマンドで、
  中途半端に上がっているGIを強制停止します。
  (通常コマンドだと、止めようとすると、いや上がってないし。
  上げようとすると上がってるしとか言われる状態になっているので。)

5)ノード1のNICインターコネクト用NIC開始(or結線)
6)ノード2でCRSを手動起動


前回の記事のように、とてもおまじないチックです(苦笑)

この問題も再現性が不安定なので、
同じマシンによる同じ構成でも出たり出なかったりしますので要注意。
カットオーバ前にしっかり障害テストをして確認しましょう。

・・・

個人的な感想として、
11.2.0.2.0以降、CRSやGIが起動しない場合の原因として、
HAIPの起動や通信に問題が発生しているケースが多い気がします。

CRSやGI、HAIPの挙動がおかしいようであれば、
ocssd.log、orarootagent_root.log、ohasd.logあたりのログを確認して、
エラーメッセージや特定メッセージがループしていないかなどのチェックがおすすめ。



また、HAIPの絡みで問題が出てるかな?と思ったら、

MOS[ID 1210883.1]
11gR2 Grid Infrastructure Redundant Interconnect and
ora.cluster_interconnect.haip

の内容がとても有効です。


では、楽しいHAIPライフを♪

ASMインスタンスが使用するメモリサイズについて#2

DB設計の過程でOracleマニュアルを貪っていたら、
面白い内容があったので書いておきます。

以前にこんな記事を書きました。
ASMインスタンスが使用するメモリサイズについて

その時に
=================================================================
経験的にはDiskGroup(DG)の数が大量に存在するorサイズが大きいとかがない限り、
標準のMEMORY_TARGETで良いと思います。
DGの数が大量orサイズが大き目の場合、
LARGE_POOLやMEMORY_TARGETの引き上げを検討するのも悪くないと思います。
=================================================================
と書いています。

この時は、リストア&リカバリ試験の際に、
asmcmdからのDGリストア、DGのマウント時にORA-4031が発生し
ASMが起動しないという事象が発生したので、
LARGE_POOLへのメモリ割り当てを増加しました。
なお、その時のデータ量は1.5TB程度でした。

・・・


さて、ではなぜORA-4031が出て、LARGE_POOLへのメモリ割り当てで回避できたのか。
今日マニュアルを読んでいると、、

=================================================================
ラージ・プール

データベース管理者は、次の目的で大量のメモリーを割り当てるために、
ラージ・プールと呼ばれるオプションのメモリー領域を構成できます。

・共有サーバーおよびOracle XAインタフェース用のセッション・メモリー
 (トランザクションが複数のデータベースと対話する環境で使用)
・I/Oサーバー・プロセス
・Oracleのバックアップおよびリストア操作
=================================================================
出典:Oracle Database 概要 10gリリース2(10.2)


リストア操作!
なるほど。リストア時に、ここで使用されるメモリ領域を獲得できなかったからか。。


そしてリファレンスマニュアルを読むと

=================================================================
LARGE_POOL_SIZE

デフォルト値
SGA_TARGETが設定されているが、値が指定されていない場合のデフォルト値は0
(Oracle Databaseによって内部で決定される)。
LARGE_POOL_SIZEが指定されている場合は、プールの最小値を示す。
SGA_TARGETが設定されておらず、次の両方に該当する場合は0。

パラレル実行によって、プールが要求されない。
DBWR_IO_SLAVESが設定されていない。

それ以外の場合は、PARALLEL_MAX_SERVERS、PARALLEL_THREADS_PER_CPU、
CLUSTER_DATABASE_INSTANCES、DISPATCHERSおよびDBWR_IO_SLAVESの値から導出される。

この方法で導出される値には、自動ストレージ管理ファイルに使用される要件が
考慮されない。
一般的なガイドラインとして、ASMを使用するデータベース・インスタンスの
SGAのサイズに600KBを追加する

=================================================================
出典:Oracle Databaseリファレンス 11g リリース2(11.2)

ASMの場合は、600KB追加しておけと書いてある。
まぁ、600KB程度では足りなかっただろうけど、
ちゃんと指標が書いてある。。。


また、同マニュアルのSHARED_POOL_SIZEの項を見てみると、一番下の方に、、、

=================================================================
SHARED_POOL_SIZEと自動ストレージ管理

ASMを使用するデータベース・インスタンスでは、
エクステント・マップを格納するために追加メモリーが必要です。
一般的なガイドラインとして、次の問合せの値を集計して、
すでにASM上にあるか、これからASMに格納される、
現行のデータベース記憶域サイズを取得できます。
次に、使用されている(またはこれから使用される)冗長タイプを判断し、
集計した値を入力として使用して、SHARED_POOL_SIZEの値を計算します。

SELECT SUM(BYTES)/(1024*1024*1024) FROM V$DATAFILE;
SELECT SUM(BYTES)/(1024*1024*1024) FROM V$LOGFILE a, V$LOG b
WHERE a.group#=b.group#;
SELECT SUM(BYTES)/(1024*1024*1024) FROM V$TEMPFILE WHERE
status='ONLINE';
また、次のガイドラインに注意してください。

外部冗長性を使用するディスク・グループの場合:
(100GBの領域ごとに1MBの追加共有プールが必要)+ 2MB

通常の冗長性を使用するディスク・グループの場合:
(50GBの領域ごとに1MBの追加共有プールが必要)+ 4MB

高冗長性を使用するディスク・グループの場合:
(33GBの領域ごとに1MBの追加共有プールが必要)+ 6MB
=================================================================
出典:Oracle Databaseリファレンス 11g リリース2(11.2)


あの時は、1.5TBで外部冗長性だから、、、
1.5*1024/100=16↑ +2 = 18MBか。まぁ、問題ないな。
通常の冗長性だとこの2倍。
高冗長性だと約3倍。
むー


「Oracle ASM初期化パラメータの設定」節
「Oracle ASMの自動メモリー管理」項を読んでみると
注意というところに、


=================================================================
Oracle ASMのMEMORY_TARGETの最小値は256MBです
MEMORY_TARGETを100MBに設定すると、MEMORY_TARGETの値は自動的に256MBに増加します。
=================================================================
出典:Oracle Automatic Storage Management管理者ガイド 11gリリース2(11.2)


なるほど
読み進めると、ほとんどのパラメータは自動メモリ管理でおk。
となっているのですが、気になる記述も。。


=================================================================
PROCESSES
PROCESSES初期化パラメータはOracle ASMに影響しますが、
ほとんどの場合、デフォルト値が適しています。
ただし、複数のデータベース・インスタンスが1つのOracle ASMインスタンスに
接続している場合、次の式を使用できます


PROCESSES = 50 + 50*n

ここで、nはOracle ASMインスタンスに接続しているデータベース・インスタンスの数です。
=================================================================
出典:Oracle Automatic Storage Management管理者ガイド 11gリリース2(11.2)


ふーむ。インスタンス統合(インスタンスを複数起動する)によるDB統合環境や
プライベートクラウド環境では、注意が必要だなぁ。

更に読み進めると、、

=================================================================
Oracle ASMで使用するデータベース初期化パラメータの設定
・・・
自動メモリー管理を使用する場合、この項で説明するサイズ指定データは、
情報としてのみ、またはSGAに使用する適切な値を判断するための補足情報として扱うことができます。

・・・・

データベース・インスタンス上のSGAサイズ指定に関するガイドラインを次に示します。

PROCESSES初期化パラメータ: 現在の値に16を追加します。
LARGE_POOL_SIZE初期化パラメータ: 現在の値に600Kを追加します。
SHARED_POOL_SIZE初期化パラメータ: 次の問合せの値を集計して・・・
=================================================================
出典:Oracle Automatic Storage Management管理者ガイド 11gリリース2(11.2)


なんてこったい!!
ほとんどのパラメータは自動メモリ管理でおk。とか言っときながら、
同じことが書いてあるじゃないか。。



ということで何が言いたかったというと、
調子こいて、MEMORY_TARGETいんじゃん?
とか言っちゃってすみません。。

正しくは、マニュアルちゃんと読もうぜ。(おまえも俺も)

でしたとさ。

2012年2月11日土曜日

Oracle Database 11g の標準セキュリティ設定について#4

前回はこちら

11gで大きく変わったセキュリティ関連の設定は3つ
 1)Auditの監査設定が標準設定されている
 2)プロファイルのDEFALUTの設定が強固に
 3)パスワードの大文字小文字を区別するようになった

今回はそれぞれの対処方法について記載します。

1)Auditの監査設定が標準設定されている
以下のSQLを実行します。
=========================================================================
SQL> @?\rdbms\admin\undoaud.sql

監査取消しが成功しました。


監査取消しが成功しました。


監査取消しが成功しました。


SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE
   2 from DBA_STMT_AUDIT_OPTS;

レコードが選択されませんでした。

SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS;

レコードが選択されませんでした。

SQL> show parameter audit_trail

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------------------
audit_trail                          string      DB

↑audit_trailはDBから変更されません。必要に応じてユーザにて変更。
=========================================================================


2)プロファイルのDEFALUTの設定が強固に
以下のSQLを実行します。
=========================================================================
SQL> @?\rdbms\admin\undopwd

プロファイルが変更されました。

SQL>  select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES
  2   where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME;

PROFILE  RESOURCE_NAME             RESOURCE LIMIT
-------  ------------------------- -------- -------------
DEFAULT  FAILED_LOGIN_ATTEMPTS     PASSWORD 10
DEFAULT  PASSWORD_GRACE_TIME       PASSWORD UNLIMITED
DEFAULT  PASSWORD_LIFE_TIME        PASSWORD UNLIMITED
DEFAULT  PASSWORD_LOCK_TIME        PASSWORD UNLIMITED
DEFAULT  PASSWORD_REUSE_MAX        PASSWORD UNLIMITED
DEFAULT  PASSWORD_REUSE_TIME       PASSWORD UNLIMITED
DEFAULT  PASSWORD_VERIFY_FUNCTION  PASSWORD NULL

7行が選択されました。
=========================================================================


3)パスワードの大文字小文字を区別するようになった
以下のSQLを実行します。
=========================================================================
SQL> alter system set sec_case_sensitive_logon=FALSE scope=both;
システムが変更されました。

SQL> show parameter sec_case_sensitive_logon

NAME                     TYPE        VALUE
------------------------ ----------- -------------------------
sec_case_sensitive_logon boolean     FALSE
=========================================================================


■まとめ
 11gではデフォルトのセキュリティレベルが高くなった。
 でも知ってりゃ騒ぐほどのことはない。


なお、やっぱり元の11gのセキュリティレベルに戻したい場合は以下を実行します
1)と2)両方の設定を元に戻します。

SQL> @?\rdbms\admin\secconf.sql


■参考資料
 Oracle Databaseセキュリティ・ガイド11g リリース2(11.2) 認証部分
 Oracle Databaseセキュリティ・ガイド11g リリース2(11.2) 監査部分
 Oracle Databaseアップグレード・ガイド11g リリース2(11.2)

Oracle Database 11g の標準セキュリティ設定について#3

前回はこちら

11gで大きく変わったセキュリティ関連の設定は3つ
 1)Auditの監査設定が標準設定されている
 2)プロファイルのDEFALUTの設定が強固に
 3)パスワードの大文字小文字を区別するようになった

今回は3)パスワードの大文字小文字を区別するようになった
11gからパスワードの大文字小文字を区別するようになりました。
それにより何が起きるかというと、、

=======================================================
DBのアップグレードは完了したし、
アプリケーションから接続してみるか。
まぁ、アプリケーションは現行のままだから
問題ないだろうけどなっと♪

ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。

って、、ありりりり?
=======================================================

の原因がパスワードの大文字小文字の仕様変更。

・・・

11g以前のリリースでは、パスワードは「原則」大文字小文字の区別はされませんでした。
"で囲ってユーザを作ってしまい、小文字として認識されている環境もありましたが、
Oracleはやっちゃ駄目だと言ってきました。(基本は駄目。)

でも、このご時世、パスワードは大文字小文字を組み合わせた、
複雑なものがいいよねってことで、
11gからパスワードの大文字小文字が区別されるようになりました。

そんなこんなで、既存のプログラムのコネクション時のパスワードが小文字、
ユーザ作成時はパスワードに大文字をしていたとか、またその逆とかだと、
上記のような問題が発生したります。


じゃ、いちからプログラムを見直せってのかよ?!
ってこともあるわけもなくて、
以前のように大文字小文字区別しないようにするには、
以下のパラメータの設定を変更します。

初期化パラメータ:sec_case_sensitive_logon

このパラメータは11gからの初期化パラメータになります。
デフォルトだと以下のようにTRUEになっているので、
FALSEに変更すれば、大文字小文字区別しないようになります。
動的変更が可能なパラメータなので楽ちんです。

==============================================================

SQL> show parameter sec_case_sensitive_logon

NAME                     TYPE        VALUE
------------------------ ----------- -------------------------
sec_case_sensitive_logon boolean     TRUE

SQL> conn scott/TIGER
ERROR:
ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。
警告: Oracleにはもう接続されていません。

SQL> conn system/XXXX
接続されました。

SQL> alter system set sec_case_sensitive_logon=FALSE scope=both;
システムが変更されました。

SQL> show parameter sec_case_sensitive_logon

NAME                     TYPE        VALUE
------------------------ ----------- -------------------------
sec_case_sensitive_logon boolean     FALSE

SQL> conn scott/TIGER
接続されました。

==============================================================

まとめです、
11gではデフォルト設定のままだと、パスワードの大文字小文字が区別されます。
簡単に戻せるし、特に言うことないですね。

大切なのは、このようなアップグレード時の仕様変更を把握して、
自分のシステムではどのように対処するかということ。
折角、パスワードの大文字小文字を指定出来るようになったのだから、
アップグレードを機にパスワードを強化してみるのもいいですよね。


つづきはこちら

Oracle Database 11g の標準セキュリティ設定について#2

前回はこちら

11gで大きく変わったセキュリティ関連の設定は3つ
 1)Auditの監査設定が標準設定されている
 2)プロファイルのDEFALUTの設定が強固に
 3)パスワードの大文字小文字を区別するようになった

今回は 2)DEFALUTプロファイルのパスワード関連の設定が強固に
11gからDEFALUTプロファイルのパスワード関連のセキュリティ設定が
強固になりました。
それにより何が起きるかというと、、

=======================================================
本番環境のDBを作成してテストを半年間近くやってきたが、
明日はとうとうリリースだ!

・・・あれっ!?
アプリケーションにエラーが!!
DBに接続できてない?!
ORA-28000: アカウントがロックされています。
って、、
=======================================================
という話が、実際にあったとかなかったとか。
(場合によってはもっと悲惨。)

の原因がDEFALUTプロファイルの仕様変更。

・・・

プロファイルとはデータベース・リソースの制限の集合。
DEFAULTプロファイルは最初から用意されているプロファイルで、
明示的にプロファイルを設定しなければ、
Oracleアカウントはこのプロファイルの制限を受けます。
で、その中にパスワードに関する制限というか設定があります。
制限には、何日間でパスワード変えなさいとか、
失効したら何日使えないというような、一般的なパスワードの制限があります。


では、プロファイルについて見ていきます。

■10gのDEFALUTプロファイルのパスワード関連の制限


SQL> select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES
   where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME;


PROFILE  RESOURCE_NAME             RESOURCE LIMIT
-------  ------------------------- -------- ---------
DEFAULT  FAILED_LOGIN_ATTEMPTS     PASSWORD 10
DEFAULT  PASSWORD_GRACE_TIME       PASSWORD UNLIMITED
DEFAULT  PASSWORD_LIFE_TIME        PASSWORD UNLIMITED
DEFAULT  PASSWORD_LOCK_TIME        PASSWORD UNLIMITED
DEFAULT  PASSWORD_REUSE_MAX        PASSWORD UNLIMITED
DEFAULT  PASSWORD_REUSE_TIME       PASSWORD UNLIMITED
DEFAULT  PASSWORD_VERIFY_FUNCTION  PASSWORD NULL

7行が選択されました。

----------------------------------------------------------------------
FAILED_LOGIN_ATTEMPTS   :アカウントロックまでのログイン失敗回数 
PASSWORD_GRACE_TIME    :警告が出され、ログインが許可される猶予期間の日数 
PASSWORD_LIFE_TIME     :警告が出され、ログインが許可される猶予期間の日数
PASSWORD_LOCK_TIME     :ログインが指定された回数連続して失敗した場合、
               アカウントがロックされる日数 
PASSWORD_REUSE_MAX      :現行のパスワードを再利用する前に必要な
             パスワードの変更回数
PASSWORD_REUSE_TIME     :パスワードを再利用できない日数
PASSWORD_VERIFY_FUNCTION:PL/SQLの複雑なパスワード検証スクリプトの
             CREATE PROFILE文の引数
----------------------------------------------------------------------

パスワードミスの猶予回数10回以外はフリーダムです。
失効してしまうとユーザがアカウントのアンロックをしないと、
使用できないくらいです。


では、11gは?

■11gのDEFALUTプロファイルのパスワード関連の制限

SQL> select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES
   where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME;

PROFILE  RESOURCE_NAME              RESOURCE LIMIT
-------- -------------------------- -------- ---------------------------
DEFAULT  FAILED_LOGIN_ATTEMPTS      PASSWORD 10
DEFAULT  PASSWORD_GRACE_TIME        PASSWORD 7
DEFAULT  PASSWORD_LIFE_TIME         PASSWORD 180
DEFAULT  PASSWORD_LOCK_TIME         PASSWORD 1
DEFAULT  PASSWORD_REUSE_MAX         PASSWORD UNLIMITED
DEFAULT  PASSWORD_REUSE_TIME        PASSWORD UNLIMITED
DEFAULT  PASSWORD_VERIFY_FUNCTION   PASSWORD NULL

7行が選択されました。


パスワードミスの猶予回数10回は同じですが、
180日間後にパスワードが自動的に失効するようになっています。
(7日間の猶予を設けてくれていますが。)
187日間を越えて、アカウントがロックされてしまうと、
パスワードが変更されるまでそのアカウントへのログインは許可されません。。。


まとめです、
11gではデフォルト設定のままだと、半年毎にアカウントのパスワード変更が必要
DB設計時には、システム全体のパスワードポリシーやアプリケーションの作りに
合わせて対処を考えておく必要があります。

現実的には、11gの初期DEFAULTプロファイル設定に合わせて、
アプリケーションを作ったり、ポリシーを考えることはほぼありないので、
設定変更やどのようにセキュリティを高めるかを考えることになると思います。


大切なのは、このようなアップグレード時の仕様変更を把握して、
自分のシステムではどのように対処するかということ。
気が付いたらシステムが止まってたは避けたいですよね。


対処はこちら
つづきはこちら

Oracle Database 11g の標準セキュリティ設定について#1

最近、DBバージョンアップ&移行案件のDB設計をやっているので、
ただでさえ多いベーシックネタが更に多くなります。
自分へのメモだけど、誰かの一助になれば。。
(バージョンアップの時にこういうところも気にしているんだとかね。)

さて、今回はOracle Database 11g での標準セキュリティ設定について。
ここ数年の世相を受けてデフォルトがいくつか変わっています。
バージョンアップしてから、「え?そうなの?」というのはお粗末な話。
(割とよく聞くけど。。)

11gで大きく変わったセキュリティ関連の設定は3つ
 1)Auditの監査設定が標準設定されている
 2)DEFALUTプロファイルのパスワード関連の設定が強固に
 3)パスワードの大文字小文字を区別するようになった

では、見ていきます。

■環境
Windows7 64Bit
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64Bit

1)Auditの監査設定がデフォルトで設定されている
 気付かない内に監査ログ取られているなんて領域が心配です。
 設計時に方針を決めておかないと、SYSTEM表領域が・・・


まずは、Audit関係の初期化パラメータ

SQL> show parameter audit

NAME                  TYPE      VALUE
--------------------- --------- ------------------------------
audit_file_dest       string    C:\APP\ORACLE\ADMIN\ORCL\ADUMP
audit_sys_operations  boolean   FALSE
audit_trail           string    DB


10gのaudit_trailのデフォルトはnoneだったのが、11gではDB※1になっています。
※1.Database Configuration Assistantを使用してデータベースを作成した場合の
  デフォルト。それ以外の方法だとnone。

none:標準監査機能は使用禁止
DB:標準監査機能使用可能状態。監査レコードをSYS.AUD$表に書き込みます。

audit_sys_operationsとaudit_file_destは変更無いようです。


まぁ、audit_trailの値がDBになっていたって、監査設定がされていなければ、
なんてことはありません。

監査設定を見ていきます。


■権限監査設定

SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS;

SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS
   order by PRIVILEGE;

USER_NAME PRIVILEGE                     SUCCESS    FAILURE
--------- ----------------------------- ---------- ---------
          ALTER ANY PROCEDURE           BY ACCESS  BY ACCESS
          ALTER ANY TABLE               BY ACCESS  BY ACCESS
          ALTER DATABASE                BY ACCESS  BY ACCESS
          ALTER PROFILE                 BY ACCESS  BY ACCESS
          ALTER SYSTEM                  BY ACCESS  BY ACCESS
          ALTER USER                    BY ACCESS  BY ACCESS
          AUDIT SYSTEM                  BY ACCESS  BY ACCESS
          CREATE ANY JOB                BY ACCESS  BY ACCESS
          CREATE ANY LIBRARY            BY ACCESS  BY ACCESS
          CREATE ANY PROCEDURE          BY ACCESS  BY ACCESS
          CREATE ANY TABLE              BY ACCESS  BY ACCESS
          CREATE EXTERNAL JOB           BY ACCESS  BY ACCESS
          CREATE PUBLIC DATABASE LINK   BY ACCESS  BY ACCESS
          CREATE SESSION                BY ACCESS  BY ACCESS
          CREATE USER                   BY ACCESS  BY ACCESS
          DROP ANY PROCEDURE            BY ACCESS  BY ACCESS
          DROP ANY TABLE                BY ACCESS  BY ACCESS
          DROP PROFILE                  BY ACCESS  BY ACCESS
          DROP USER                     BY ACCESS  BY ACCESS
          EXEMPT ACCESS POLICY          BY ACCESS  BY ACCESS
          GRANT ANY OBJECT PRIVILEGE    BY ACCESS  BY ACCESS
          GRANT ANY PRIVILEGE           BY ACCESS  BY ACCESS
          GRANT ANY ROLE                BY ACCESS  BY ACCESS
23行が選択されました。

がっつり設定されています。
「CREATE SESSION」で成功も失敗もって、、、
環境によってはログが大量に出そうです。。。


■文監査

SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE from DBA_STMT_AUDIT_OPTS
   order by AUDIT_OPTION;

USER_NAME AUDIT_OPTION                  SUCCESS    FAILURE
--------- ----------------------------- ---------- ----------
          DATABASE LINK                 BY ACCESS  BY ACCESS
          PROFILE                       BY ACCESS  BY ACCESS
          PUBLIC SYNONYM                BY ACCESS  BY ACCESS
          ROLE                          BY ACCESS  BY ACCESS
          SYSTEM AUDIT                  BY ACCESS  BY ACCESS
          SYSTEM GRANT                  BY ACCESS  BY ACCESS

※権限監査と重複しているものは記載していません。

文監査も設定されています。


■オブジェクト監査

SQL> select OWNER,OBJECT_NAME,SEL,INS,DEL from  DBA_OBJ_AUDIT_OPTS;

レコードが選択されませんでした。

SQL> select * from ALL_DEF_AUDIT_OPTS;

ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ----
-/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-


流石にオブジェクト監査は設定されていませんね。
ALL_DEF_AUDIT_OPTSは、オブジェクトが作成されるときに適用される
デフォルトのオブジェクト監査オプションですが、こちらも何もありません。
オブジェクト監査はユーザ次第という感じです。

実際に取得されている監査ログを見てみると、、、

SQL> select USERNAME,ACTION_NAME from DBA_AUDIT_TRAIL

USERNAME  ACTION_NAME
--------- ------------------------
DBSNMP    SET ROLE
SYSTEM    LOGON
SYSTEM    LOGON
DBSNMP    LOGON
SYSMAN    LOGON
SYSMAN    LOGON
DBSNMP    LOGON
DBSNMP    LOGON
DBSNMP    LOGON
DBSNMP    LOGOFF
DBSNMP    LOGOFF
SYSMAN    LOGOFF
SYSMAN    LOGOFF

・・・

SYSTEM    SYSTEM GRANT
SYSTEM    CREATE PUBLIC SYNONYM
SYSTEM    CREATE PUBLIC SYNONYM
SYSTEM    DROP PUBLIC SYNONYM
SYSTEM    DROP PUBLIC SYNONYM
SYSTEM    GRANT ROLE

うーん。。
1件のデータ量はそんなに多くないんでしょうが、
レコード数は結構なペースで増えていきそう。。

あとあと、気が付いたらSYSTEM表領域がアレレレ???
という感じでボディーブローのように効きそうな気も?

まとめですが、DBCAでDBを作成するとデフォルトでログが取られます。
自動的に消してはくれないので、領域を消費し続けます。
ログの生成量は環境によると思いますが、
個人的には気にしなてくもいいかもとは思います。
(コネクションプーリングとかしてれば。)

大切なのは、このようなアップグレード時の仕様変更を把握して、
自分のシステムではどのように対処するかということ。
セキュリティ事故が発生した際に、監査ログが自動で取得されていて良かった。
ということもあるでしょうし、
SYSTEM表領域を自動拡張にしてなかったので、気が付いたら。。。
ということもあるかもしれません。

対処はこちら
つづきはこちら

2012年2月6日月曜日

Oracleのバージョンとconnectロール

基本的なことだけど、一応メモ。
(いまさらか。。)

Connectロールに含まれる権限は10.2.0.1.0以降、縮小されている。

■10.1.0.X.Xより以前のバージョンのConnectロールと含まれる権限

SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'

GRANTEE  PRIVILEGE
----------------  ---------------
CONNECT  CREATE VIEW
CONNECT  CREATE TABLE
CONNECT  ALTER SESSION
CONNECT  CREATE CLUSTER
CONNECT  CREATE SESSION
CONNECT  CREATE SYNONYM
CONNECT  CREATE SEQUENCE
CONNECT  CREATE DATABASE LINK

■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限

SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'

GRANTEE  PRIVILEGE
----------------  --------------
CONNECT  CREATE SESSION


以前は色々作れる権限が入ってたのに、接続できるだけになっちゃったんですね~
昔の感覚で適当にConnectロール振っておけばいんじゃね?
とかでやっちゃうとビックリします。

ちなみに、同じ感覚で付与してたRESOURCEはというと・・・

■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限

SQL> select GRANTEE,PRIVILEGE from dba_sys_privs where GRANTEE='RESOURCE' order by PRIVILEGE;

GRANTEE   PRIVILEGE
-----------------  -------------------
RESOURCE  CREATE CLUSTER
RESOURCE  CREATE INDEXTYPE
RESOURCE  CREATE OPERATOR
RESOURCE  CREATE PROCEDURE
RESOURCE  CREATE SEQUENCE
RESOURCE  CREATE TABLE
RESOURCE  CREATE TRIGGER
RESOURCE  CREATE TYPE

10.2.0.1.0以前と変更はなし。
RESOURCEロールだけじゃ、VIEWは作れません。。

ちゃんとユーザロール作るか、必要な権限のみを適切に付与しろ。
というOracle社のメッセージが見えますね。
(実際にマニュアル内で、「CONNECTおよびRESOURCEのロールはともにOracleの
将来のバージョンで非推奨になります」と言っています。)

さて、もうひとつの有名なロールといえば、DBA。
なんでもできちゃうロール。
説明するまでもないですし、健在です。


時たま、アプリケーションユーザや、
全部のユーザにこのロールが付与されている環境があってびっくりしたり。。。

バージョンアップや移行のタイミングで合わせて見直したいですね。


「Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)から
新しいOracle Database 11gリリースにアップグレードすると、
CONNECTロールに含まれる権限はCREATE SESSION権限のみになります。
以前のリリースでCONNECTロールに付与された他の権限は、
アップグレード時に取り消されます。」
出典:Oracle® Databaseアップグレード・ガイド 11g リリース2(11.2)

気を付けなくちゃですね。