2012年12月20日木曜日

蘇るパラメータファイルその3

前回のつづきです。
前回は、SPFILEの記述のないinit[SID].oraファイルを
%ORACLE_HOME%\database\配下に配置しても、
勝手にSPFILEの記述を追記される。

それも、SQL*PlusのSTARTUPコマンドじゃなくて、
srvctlコマンドで起動してみた場合に起きている。
# line added by Agentというメッセージを残して。。
そう、Oracle Grid Infrastructure(以下Grid)がなんかやっそうだ。
さて、本題。
Gridでcrsに関係するagentと言えば、oraagentかorarootagentですよね
でもあってOracleなので、なんかやってるとすればoraagentが怪しい。
ということで、「init[SID名]」でログを検索します。
%GRID_HOME%\log\strike-1\agent\crsd\oraagent\配下の\oraagent.XXXを検索

やっぱりなんか出てる。

2012-12-19 20:05:13.130: [ora.strike01.db][4876] {1:28408:2364} [start] sModifyConfig for strike01
2012-12-19 20:05:13.145: [ora.strike01.db][4876] {1:28408:2364} [start] ConfigFile::update file D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora is updated

sModifyConfigっての実行した後に、initstrike011.oraを更新したと。
しれっとやっとる。。

sModifyconfigというキーワードと、
srvctlの実行によって出力されているということから
srvctl configやmodify辺りが怪しい!!(強引ですが)
と言うことで、configを確認します。


C:\>srvctl config database -d strike01 -a
====
一意のデータベース名: strike01
データベース名: strike01
Oracleホーム: D:\app\orauser\product\11.2.0\dbhome_1
Oracleユーザー: nt authority\system
spfile: +DATA/strike01/spfilestrike01.ora
ドメイン:
開始オプション: open
停止オプション: immediate
データベース・ロール: PRIMARY
管理ポリシー: AUTOMATIC
サーバー・プール: strike01
データベース・インスタンス: strike011,strike012
ディスク・グループ: DATA
マウント・ポイントのパス:
サービス:
タイプ: RAC
データベースは有効です
データベースは管理者によって管理されています
====

SPFILE、定義されてます。

そもそもSRVCTLって???

OracleR Real Application Clusters管理およびデプロイメント・ガイド11g リリース2 (11.2)より
====
SRVCTLを使用してクラスタの構成操作を実行すると、
SRVCTLは構成データをOracle Cluster Registry(OCR)に格納します。
SRVCTLは、Oracle Clusterwareリソース(Oracle Call Interface APIを使用して
データベースの起動および停止操作を実行するエージェントを定義)を構成および管理することによって、
インスタンスの起動および停止のようなその他の操作を実行します。
====

どうやら定義はOCRに入ってるようです。

いつ、定義したんだろう。。。
と、よくよくDB作成スクリプト([Database名].sql)を確認してみると

host D:\app\orauser\product\11.2.0\dbhome_1\bin\srvctl.bat add database -d strike01 -o D:\app\orauser\product\11.2.0\dbhome_1 -p +DATA/strike01/spfilestrike01.ora -n strike01 -a DATA

srvctlコマンドを使用したデータベースリソース追加時のオプションで、
-p +DATA/strike01/spfilestrike01.oraというのを指定して実行しています。

OracleR Real Application Clusters管理およびデプロイメント・ガイド11g リリース2 (11.2)より

-p spfile
データベース・サーバー・パラメータ・ファイルのパス名

なるほど。
だんだん見えてきました。
次回は、srvctlコマンドを実行してOCR内のSPFILE情報を書き換え、
推測が正しいかを確認します。

2012年12月19日水曜日

蘇るパラメータファイルその2

前回の続きです。

消したはずのinit[SID].oraが蘇りました。
誰かの手によって。。

とても気になるので、悪戯してみます。

PFILEを作っちゃいます。

SQL> create pfile='D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011
.ora' from spfile;

ファイルが作成されました。


5.4 Oracle RACでのパラメータ・ファイルの検索順序
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

このルールなので、init%ORACLE_SID%.oraを読むはず。

C:\>srvctl stop instance -d strike01 -i strike011

C:\>crsctl stat res ora.strike01.db -t
--------------------------------------------------------------------------------

NAME           TARGET  STATE        SERVER                   STATE_DETAILS

--------------------------------------------------------------------------------

Cluster Resources
--------------------------------------------------------------------------------

ora.strike01.db
      1        OFFLINE OFFLINE                               Instance Shutdown

      2        ONLINE  ONLINE       strike-2                 Open


C:\>srvctl start instance -d strike01 -i strike011


C:\>crsctl stat res ora.strike01.db -t
--------------------------------------------------------------------------------

NAME           TARGET  STATE        SERVER                   STATE_DETAILS

--------------------------------------------------------------------------------

Cluster Resources
--------------------------------------------------------------------------------

ora.strike01.db
      1        ONLINE  ONLINE       strike-1                 Open

      2        ONLINE  ONLINE       strike-2                 Open


C:\>sqlplus sys/oracle as sysdba
に接続されました。
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora

なんだと・・・


C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora
======
strike012.__db_cache_size=671088640
strike011.__db_cache_size=570425344
strike012.__java_pool_size=16777216
strike011.__java_pool_size=33554432
 ・
 ・
 ・
 ・
strike011.undo_tablespace='UNDOTBS1'
SPFILE='+DATA/strike01/spfilestrike01.ora'  # line added by Agent
======

!!!!!!
最後の最後になんて罠を・・


C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\init*

2012/12/19  20:05             1,923 initstrike011.ora
2012/12/19  20:01             1,856 initstrike011.ora.bak.strike-1


なんと!!!

C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora.ba
k.strike-1
======
strike012.__db_cache_size=671088640
strike011.__db_cache_size=570425344
strike012.__java_pool_size=16777216
strike011.__java_pool_size=33554432
 ・
 ・
 ・
 ・
strike011.undo_tablespace='UNDOTBS1'

むむむむ

勝手に作られたファイルをリネームして、
バックアップにされたファイルを
リネームしてinit[SID].oraファイルに戻します。

C:\>sqlplus sys/oracle as sysdba
アイドル・インスタンスに接続しました。

SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area 2137886720 bytes
Fixed Size                  2254896 bytes
Variable Size            1560283088 bytes
Database Buffers          570425344 bytes
Redo Buffers                4923392 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------------------
spfile                               string

うん。init[SID].oraファイルで起動している。
どうやらAgentとやらは、RAC(GRID)関係で、
RAC(GRID)のどっかにSPFILEの情報もってるな・・


つづきます

蘇るパラメータファイルその1

サーバー・パラメータ・ファイル(SPFILE)って、
SQL文で動的にパラメータを変えられて、便利です。
今だとデフォルトだとSPFILE使うようになってますよね。
RAC環境だとASM上に配置して、複数ノードで1つのファイルを
使用したりします。
(各ノードにあると、運用管理がちょっと煩雑だったりしますもんね)

今回はそんなSPFILE絡みで、ビックリしたことがあったので、
それを書きたいと思います。(僕だけですかね?びっくりするの)
いつも通り役には立ちません。

検証環境
[OS]
----
Microsoft Windows Server 2003 R2
Enterprise x64 Edition
Service Pack 2
----
[Oracle&GRID]
----
11.2.0.2.0 - 64bit
----

[その他]
----
2ノードRAC、管理者型管理
----

パラメータファイルについて、
OracleR Real Application Clustersインストレーション・ガイド11g リリース2 (11.2) for Microsoft Windows x64 (64-Bit)に
以下の記載があります。


5.4 Oracle RACでのパラメータ・ファイルの検索順序
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

なるほど。
環境を見てみます。

SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora

上記のどれにも合致しません。
OS上を見てみます。

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\sp*

ファイルが見つかりません

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\init*

2012/12/18  14:04                90 initstrike011.ora

ありました。どうやら3番目のinitファイルは読み込みそうです。
中身を見てます。

C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

SPFILE='+DATA/strike01/spfilestrike01.ora'

この一行だけ書いてあります。
なるほど、旧来の初期化パラメータのファイルであるinit%ORACLE_SID%.oraファイルを読み込んで、
ASM上のSPFILEを読み込んでいると。


そもそも、このinitstrike011.oraとその中身はいつ作られているのでしょうか?
データベース作成スクリプトの1つである、
%ORACLE_BASE%\admin\[データベース名]\scripts\[データベース名].sqlを見てみると、

以下の部分で作っていることが分かります。
host "echo SPFILE='+DATA/strike01/spfilestrike01.ora' > D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora"


ところで、Oracle DB起動時のnomount状態では、パラメータファイルの内容を読み込み、
メモリ割り当てやプロセスの生成などを行います。

つまり、パラメータファイルがないと
「Oracle DBは起動出来ない。」
やってみます。

SQL> conn /as sysdba
接続されました。
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> exit
接続が切断されました。

C:\>del D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

ファイルが見つかりません

C:\>sqlplus sys/oracle as sysdba

アイドル・インスタンスに接続しました。

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: ?p?????[?^?E?t?@?C??'D:\APP\ORAUSER\PRODUCT\11.2.0\DBHOME_1\DATABASE\INITSTRIKE011.ORA'???I?[?v?????????????B
SQL> exit
切断しました。

うん。上がらない。
ファイルないし。

あ、そうそう、RACのリソース起動停止は
srvctlコマンドを使うのが一般的だよな。。

C:\>srvctl start instance -d strike01 -i strike011

C:\>


あれ?普通にプロンプト返ってきた。。

C:\>crsctl stat res ora.strike01.db -t
NAME           TARGET  STATE        SERVER                   STATE_DETAILS

---------------------------------------------------------------------------
Cluster Resources
---------------------------------------------------------------------------

ora.strike01.db
      1        ONLINE  ONLINE       strike-1                 Open

      2        ONLINE  ONLINE       strike-2                 Open

ん????Open?


C:\>sqlplus sys/oracle as sysdba
接続されました。
SQL> select instance_name,status from v$instance;

INSTANCE_NAME    STATUS
---------------- ------------
strike011        OPEN

SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora


SQL> exit
接続が切断されました。
OPENしてて、ASM上のSPFILEを読んでるだと・・・

でも、マニュアルには、、、、
=====
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

んーなんだろう。。

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

2012/12/19  18:27                67 initstrike011.ora
               

!!!!!


C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

SPFILE='+DATA/strike01/spfilestrike01.ora'  # line added by Agent


# line added by Agentだと・・・

つづきます。。

2012年12月11日火曜日

Oracle Database作業時のちょっとしたテクニック

最初に
今日は、JPOUG Advent Calendarの11日目のエントリです。
1nmくらい役に立つプレゼントになればと思ってエントリします。


データセンターでのトラブルシュートでは、幾つかの共通する懸念があります。

1.PCが持ち込めない or 通信カードが使えない or サーバからはネット出来ない
2.トラブルシュートなので大体が緊急である
3.同様の障害が再発生した際に対応できるようにしておきたい。

これらの状況下で必要とされるのが「自力」
そんなとき使っているちょっとしたテクニックを紹介したいと思います。

1.PCが持ち込めない or 通信カードが使えない or サーバからはネット出来ない
 DB内の何かを調査するには、データディクショナリ(DBA_)や動的パフォーマンス・ビュー(V$)を
 参照して色々な統計情報を参照します。ただ、あまり使用しないものはなかなか覚えていられません。
 Oracleのリファレンスマニュアルを確認できれば、どのビューのどの列を参照すればいいか分かりますが、
 自PCも使えないし・ネットにも繋がってない。

 みんなが@yoshikawさんの「CUIでOracle Databaseリファレンスマニュアルを参照する」を参考にして、
 マニュアルを見れるようにしておいてくれるととても有難いのですが、なかなかそうもいきません。

 さて、どうするか?

 ディクショナリ一覧表から、関係のありそうなビューを見つけ出します。

SQL> SELECT TABLE_NAME,COMMENTS FROM DICTIONARY
         WHERE TABLE_NAME LIKE '%LINK%';
TABLE_NAME                     COMMENTS
------------------------------ ------------------------------------------------------------
DBA_DB_LINKS                   All database links in the database
DBA_STREAMS_TP_COMPONENT_LINK  DBA Streams Component Link (Streams Topology Links)
USER_DB_LINKS                  Database links owned by the user
ALL_DB_LINKS                   Database links accessible to the user
V$DBLINK                       Synonym for V_$DBLINK
GV$DBLINK                      Synonym for GV_$DBLINK

次に、関係のありそうな表に、どんな列があるのかを調べます。
SQL> DESC[RIBE] DBA_DB_LINKS
名前                                      NULL?    型
----------------------------------------- -------- ----------------
OWNER                                     NOT NULL VARCHAR2(30)
DB_LINK                                   NOT NULL VARCHAR2(128)
USERNAME                                           VARCHAR2(30)
HOST                                               VARCHAR2(2000)
CREATED                                   NOT NULL DATE
※[]内は省略できます。

TABLE_NAME LIKE '%調べたいキーワード%'という形で使用し、
あとは、関係のありそうな列を参照して調査します。

SQL> SELECT OWNER,DB_LINK,USERNAME FROM DBA_DB_LINKS;

これで、DBA_XXやV$XXを覚えて無くても、ある程度必要な情報を調査出来ます。


2.トラブルシュートなので大体が緊急である
 すぐになんとかしなければいけないのに、値の異なる対処SQL文を大量に実行しないといけない。
 でも、ローカルにはいいエディターもないし、ましてやエクセルなんて・・・
 地道にコピペして一部を修正してなんてやってたら、時間がかかってしまう。。。

 さて、どうする?

 SQL文を使用してSQL文を生成します。

 例)APからのセッション数が増えすぎてメモリが枯渇。セッションを破棄したい。
   ※PGA_AGGREGATE_TARGETのない時代はある話でした。。

 SQL> SELECT USERNAME,SID,SERIAL# FROM V$SESSION WHERE USERNAME='SCOTT';

USERNAME     SID    SERIAL#
---------- ----- ----------
SCOTT          8         75
SCOTT          9         39
SCOTT         11         27
SCOTT         12        129
・
・
・

100行が選択されました。
(kill sessionのSQL)
SQL> ALTER SYSTEM KILL SESSION 'SID,SERIAL#';

SIDとSERIAL#を修正して何度も実行する?
SQL> ALTER SYSTEM KILL SESSION '8,75';
システムが変更されました。
SQL> c/8,75/9,39/
1* ALTER SYSTEM KILL SESSION '9,39'
SQL> /
システムが変更されました。

c/修正対象文字列/修正後文字列/で置換できますが、
100回繰り返すのはしんどいし、時間もかかる。
そこで、連結演算子「||」を活用して参照結果からSQL文を生成します。

SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
     WHERE USERNAME='SCOTT';
'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||''';'
--------------------------------------------------------------------------------
alter system kill session '8,75';
alter system kill session '9,39';
alter system kill session '11,27';
alter system kill session '12,129';
・
・
99行が選択されました。

コピペして実行してもいいですが、
spoolコマンドを使用してスクリプト化するのもありです。
SQL> set pages 2000
SQL> set head off
SQL> set feedback off
SQL> set trimspool on
SQL> spool kill_session.sql
SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
  2  WHERE USERNAME='SCOTT';
alter system kill session '8,75';
alter system kill session '9,39';
alter system kill session '11,27';
alter system kill session '12,129';
・
・
・
SQL> spool off
ローカルフォルダに kill_session.sqlというファイルが出来るので、
editコマンドを使用して編集します。
SQL> edit kill_session.sql
Windowsだとノートパッドでファイルが開くので不要な部分を修正します。
Linuxの場合は、
SQL> define _editor=vi でエディターを定義してeditコマンドを実行します。
修正したファイルを実行します。
SQL> @kill_session
システムが変更されました。
システムが変更されました。
・
・
・
手動で繰り返し実行するよりとてもスマートですね。
INDEXのリビルドとか不要オブジェクトのdropとか使い道は様々です。

1.と2.を合わせて使えば、調査に必要な統計情報特定し、CSV形式で出力することも可能です。
SQL> SELECT USERNAME||','||TERMINAL||','||PROGRAM||','||EVENT FROM V$SESSION
  2  WHERE USERNAME IS NOT NULL;

USERNAME||','||TERMINAL||','||PROGRAM||','||EVENT
--------------------------------------------------------------------------------
SCOTT,SHIOSHIO,sqlplus.exe,enq: TX - row lock contention
SCOTT,SHIOSHIO,sqlplus.exe,SQL*Net message from client
SYS,SHIOSHIO,sqlplus.exe,SQL*Net message to client


3.同様の障害が再発生した際に対応できるようにしておきたい。
  後日同様の障害が発生しても、SQL文を生成出来るようにしておきたいですよね。
 作ったSQL文はsaveコマンドを使用してスクリプトとして保存しましょう。

SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
  2  WHERE USERNAME='SCOTT';

作ったSQL文を保存します。

SQL> save create_kill_session.sql
file create_kill_session.sqlが作成されました。

SQL> edit create_kill_session.sql


編集例)
==============ここから


-- ローカルフォルダにSCOTTユーザセッションを破棄する ※編集により追記した行
-- kill_session.sqlを生成します。           ※編集により追記した行
-- @kill_session.sqlを実行することにより、           ※編集により追記した行
-- セッションを破棄します。              ※編集により追記した行

set pages 2000                                        ※編集により追記した行
set head off                                          ※編集により追記した行
set feedback off                                      ※編集により追記した行
set term off                                          ※編集により追記した行
set trimspool on                                      ※編集により追記した行
spool kill_session.sql                                ※編集により追記した行

SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
WHERE USERNAME='SCOTT'
/

spool off                                           ※編集により追記した行
==============ここまで




以上、つらつら書いてきましたが、
他にも有用なSQL*Plusコマンドはありますし、上記setコマンドの内容を知りたい方は
「SQL*Plus®ユーザーズ・ガイドおよびリファレンス」を参照ください。
SQL> help index や help setも有用ですね。
SQL*Plusコマンドを活用したCSVデータ出力方法については、
@s4r_agentさんが初日に「csvってどうやって出力してますか?」というエントリを書いてますので、
併せて見てみてください。

最後に
明日の扉は Masashi_Matsushita さんです。よろしくお願いします。



o<(o'∀')ノ☆*:;;;:*☆Merry Christmas☆*:;;;:*☆ヽ('∀'o)>o

2012年9月11日火曜日

INITIAL_EXTENTと遅延セグメント作成な話4


前回でスッキリ!したのですが、まだちょっと気になるので、dumpを取得してみます。
やってみてがモットーのブログですしね。


では、やってきます。

SQL> create tablespace test_ext2 datafile 'C:\app\oracle\oradata\orcl\test_ext2_01.dbf' size 81K;

表領域が作成されました。

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name= 'TEST_EXT2';

TABLESPACE_NAME       BLOCK_ID   BYTES     BLOCKS
--------------------- ---------- ---------- ----------
TEST_EXT2                             4      65536              8   -------(1)

SQL> alter user hoge quota unlimited on TEST_EXT2;

ユーザーが変更されました。

SQL> connect hoge/hoge
接続されました。


SQL> create table test_ext2(co1 number) tablespace TEST_EXT2;

表が作成されました。

SQL> connect /as sysdba
接続されました。


SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name= 'TEST_EXT2';

OWNER      TABLESPACE_NAME TABLE_NAME SEGMENT_CREATED
---------- ---------------     ----------    --------------------
HOGE          TEST_EXT2            TEST_EXT2        NO -------(2)

2話目で書きましたが、遅延セグメント作成な状態で、セグメントは作成されていません。



SQL> select tablespace_name,file_id from dba_data_files where tablespace_name='TEST_EXT2';
TABLESPACE_NAME    FILE_ID
--------------- ----------
TEST_EXT2                  14   -------(3)

(1)よりデータブロックの空きは4ブロック目(含む)から8ブロックなので、
11ブロック目が最期のブロックだと判断します。


ファイル番号14番のデータファイルの1ブロック目から11ブロックまでの
dumpを取得します。

SQL> alter system dump datafile 14 block min 1 block max 11;

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


diag\<DB_NAME>\<INSTANCE_NAME>\trace配下に出力された
dumpファイルを確認します。


先頭辺り
--------

*** 2012-09-11 11:02:09.047
*** SESSION ID:(9.37) 2012-09-11 11:02:09.047
*** CLIENT ID:() 2012-09-11 11:02:09.047
*** SERVICE NAME:(SYS$USERS) 2012-09-11 11:02:09.047
*** MODULE NAME:(sqlplus.exe) 2012-09-11 11:02:09.047
*** ACTION NAME:() 2012-09-11 11:02:09.047

Start dump data blocks tsn: 12 file#:14 minblk 1 maxblk 11
Block 1 (file header) not dumped:use dump file header command   -------(4)

早々に注意されています。1ブロック目はファイルヘッダーブロックだから、
ファイルヘッダーをダンプするコマンド使いなさいと。

まあ、1ブロック目がファイルヘッダーブロックってことは分かりました。


2ブロック目を確認
rdba(相対データ・ブロック・アドレス)という文字列を検索して2ブロック目を探します。
----------------------------
Block dump from disk:
buffer tsn: 12 rdba: 0x03800002 (14/2)    -------(5)
scn: 0x0000.00398ff6 seq: 0x03 flg: 0x04 tail: 0x8ff61d03
frmt: 0x02 chkval: 0x75b5 type: 0x1d=KTFB Bitmapped File Space Header   -------(6)


(5)がrdbaですね、(file_id/ブロック番号)なので、
14番のデータファイルの2ブロック目ということがわかります。

(6)を見てみると、「Bitmapped File Space Header」とあります。
このブロックが、 ビットマップ・ヘッダ・ブロックと考えてよさそうです。


3ブロック目を確認
----------------------------
Block dump from disk:
buffer tsn: 12 rdba: 0x03800003 (14/3)   -------(7)
scn: 0x0000.0039ecd1 seq: 0x01 flg: 0x04 tail: 0xecd11e01
frmt: 0x02 chkval: 0x43ae type: 0x1e=KTFB Bitmapped File Space Bitmap   -------(8)


(7)より14番のデータファイルの3ブロック目ということがわかります。

(8)を見てみると、「Bitmapped File Space Bitmap」とあります。
このブロックが、 ビットマップ・ブロックと考えてよさそうです。


4ブロック目を確認
----------------------------
Block dump from disk:
buffer tsn: 12 rdba: 0x00000004 (0/4)   -------(9)
scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001
frmt: 0x02 chkval: 0xa704 type: 0x00=unknown   -------(10)

14/4が見つかりません。ファイルの終わりまで見ると(9)の部分が、(0/11)まであります。
8ブロック。。(10)はunknownになっています。

遅延セグメント作成でセグメントが作成されていないので、
空き領域になっているんですかね。



一先ず、1~3ブロック目までは、技術文書通りだということが分かって、スッキリ!!


次回は、遅延セグメント作成のセグメントに行を追加して、どうなるかを見てみます。


INITIAL_EXTENTと遅延セグメント作成な話3


前回で終わったーと思って寝たのですが。
前々回の先頭3ブロックが気になる。。

そして、OS上で1ブロック分領域が多く獲得されているのも気になる。。。

ということで続きます。

何度も書いてますが、役に立つ内容ではないですね。

ローカル管理表領域

ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域が割り当てられるか、解放されると、Oracle Databaseでは、ビットマップの値がブロックの新しい状態を反映する値に変更されます。




でした。でした。ディクショナリ管理と違って、エクステント内の領域を使用または解放について、
領域を管理するためのデータ・ディクショナリ表の更新をしなくてよくなったんですよね。
ディクショナリ管理時は、ディクショナリの更新のための再帰SQLの発行や競合による待ち、
redoの生成とか色々な課題があったんですよね。


ローカル管理表領域だと、自分の表領域内で領域の使用状況をビットマップで管理することによって、
エクステントの管理にデータ・ディクショナリを使用する必要がなくったので、
上記のような課題を解消してパフォーマンスがアップしたのでした。


ということで、使えない先頭3ブロックにはビットマップ情報の情報がきっと入ってるんだろうなぁ。。。

・・・KROWNの文書番号:29765に中にちゃんと書いてありますね。。



1ブロック目:データファイルヘッダー。デーファイル毎の1ブロック目
        データファイルの管理情報を格納

2ブロック目: ビットマップ・ヘッダ・ブロック。ローカル管理表領域デーファイル毎の
        2ブロック目※。ローカル管理するための管理情報を格納
        ※最初からローカル管理としてデータファイルを作った場合のみ


3ブロック目: ビットマップ・ブロック。ローカル管理表領域デーファイル毎の
        3ブロック目移行に1個以上獲得される。
        実際の領域管理のためのビットマップ情報を格納。


とすると88KBは、(上記3ブロック+セグメント用8ブロック)×8で88KBか。


96KBとOS上で見えている、残り1ブロック分の領域。
これもKROWNの文書番号:29765に書いてありました。

OS側でのファイル管理用領域なんですね。
以下のSQL文で確認ができます。



SQL> select a.FILE_NAME,b.BLOCK1_OFFSET from dba_data_files a,v$datafile b where a.file_id=b.file# and a.tablespace_name='TEST_EXT';


FILE_NAME                                                   BLOCK1_OFFSET
---------------------------------------------      -------------
C:\APP\ORACLE\ORADATA\ORCL\TEST_EXT01.DBF              8192


BLOCK1_OFFSET:ファイルの最初からOracleの共通情報の開始点へのオフセット


確かにデータファイルの8KB以降からOracleの情報が開始されるみたいですね。


ということで、96KBの謎が解けた。

スッキリ!


でも、まだ、ちょっとだけ気になるのでしつこく続けます。


次回:INITIAL_EXTENTと遅延セグメント作成な話4

2012年9月10日月曜日

INITIAL_EXTENTと遅延セグメント作成な話2


前回に引き続き、どうでもいい内容を検証していきます。


表領域にオブジェクトを作っていきます。


SQL> create table test_ext(co1 number) tablespace TEST_EXT;

表が作成されました。


SQL>  select OWNER,SEGMENT_NAME,EXTENT_ID,BLOCKS,BYTES from dba_extents where TABLESPACE_NAME like 'TEST_EXT%';

OWNER  SEGMENT_NAME     EXTENT_ID     BLOCKS      BYTES
------- --------------- ---------- ---------- ----------
SYS        TEST_EXT                   0                  8              65536



SQL>  select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT';

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


うんうん。データベース記憶域の割当ての論理単位はエクステント単位だもんね。
MIN_EXTENTSの1エクステント(8ブロック)使っちゃったもんね。うんうん。


うん・・・

ん??


あえ、確か最近のバージョンからは、オブジェクト作成しただけじゃ、
セグメント作成(領域獲得)しなくて、行が挿入されたときに初めて、
セグメント作成されるんじゃなかったっけ、、、

えっとぉ、、、
そうそう、11.2.0.1.0からの新機能「遅延セグメント作成」
※パーティションは11.2.0.2.0からなので、要注意。

詳しくは、Oracle® Database概要 11gリリース2(11.2) 12章 論理記憶域構造 参照


確認してみます。


SQL> show parameter DEFERRED_SEGMENT_CREATION

NAME                                 TYPE        VALUE
----------------------- ----------- ------------------------------
deferred_segment_creation     boolean     TRUE



遅延セグメント圧縮機能は有効になっています。



SQL> select OWNER,TABLE_NAME,SEGMENT_CREATED from dba_tables where table_name='TEST_EXT';

OWNER       TABLE_NAME     SEGMENT_CREATED
--------- --------------- -------------------
SYS           TEST_EXT                      YES



でもセグメント作られてますな。。。


そもそもSYSで作ったのがいけないのかなぁ。。怪しそう。。。


試します。



SQL> create tablespace test_ext2 datafile 'C:\app\oracle\oradata\orcl\test_ext2_01.dbf' size 81K;

表領域が作成されました。



SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME       BLOCK_ID   BYTES     BLOCKS
--------------------- ---------- ---------- ----------
TEST_EXT2                             4      65536              8




SQL> alter user hoge quota unlimited on TEST_EXT2;

ユーザーが変更されました。


SQL> connect hoge/hoge
接続されました。


SQL> create table test_ext2(co1 number) tablespace TEST_EXT2;

表が作成されました。




SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name like 'TEST_EXT%';

OWNER      TABLESPACE_NAME TABLE_NAME SEGMENT_CREATED
---------- ---------------     ----------    --------------------
SYS            TEST_EXT              TEST_EXT         YES
HOGE          TEST_EXT2            TEST_EXT2        NO


お、HOGEのTEST_EXT2はセグメント作成されていない。



SQL>  select OWNER,SEGMENT_NAME,EXTENT_ID,BLOCKS,BYTES from dba_extents where TABLESPACE_NAME like 'TEST_EXT%';

OWNER  SEGMENT_NAME     EXTENT_ID     BLOCKS      BYTES
------- --------------- ---------- ---------- ----------
SYS          TEST_EXT                   0              8        65536


うんうん。HOGEのTEST_EXT2がない。
※dba_extentsはセグメントを含むエクステントの情報だから



SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME   BLOCK_ID      BYTES     BLOCKS
---------------    ---------- ---------- ----------
TEST_EXT2                    4         65536          8




うん。うん。空いてますな。



ということで、SYSのオブジェクトは遅延セグメント作成しないってことだな。


という内容が、KROWNの文書番号:137280が遅延セグメント作成機能についてですが、
やっぱりSYSは対象外と書いてありますね。




SQL> connect hoge/hoge
接続されました。
SQL> insert into test_ext2 values(1);

1行が作成されました。

SQL> commit;

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

SQL> connect /as sysdba
接続されました。
SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name like 'TEST_EXT%';

OWNER      TABLESPACE_NAME TABLE_NAME  SEGMENT_CREATED
---------- ---------------   ----------   --------------------
SYS          TEST_EXT            TEST_EXT      YES
HOGE        TEST_EXT2          TEST_EXT2     YES




SQL>  select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

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




SQL>   CREATE TABLE TEST_EXT3(col1 number)
  2    STORAGE(INITIAL 100M) TABLESPACE TEST_EXT2;

とかやっても、領域は取得しないし、表領域は拡張しないし、
データファイルも大きくならないので、勘違いは禁物ってことで。


SQL> CREATE TABLE TEST_EXT3(col1 number) SEGMENT CREATION IMMEDIATE
  STORAGE(INITIAL 100M) TABLESPACE TEST_EXT2;



データ挿入時に領域獲得させたくないとかであれば、
「SEGMENT CREATION IMMEDIATE」付けましょう。



ということで、だから何?って感じですが、満足したのでした。


次回:INITIAL_EXTENTと遅延セグメント作成な話3


INITIAL_EXTENTと遅延セグメント作成な話1


ちょっと気になったのでやってみたのだけど、
個人的にはツボったのでメモしておく。
何の得もない内容です。

----
環境
----
Windows7 64bit
Oracle: 11.2.0.3.0 64bit



SQL> select TABLESPACE_NAME,INITIAL_EXTENT,MIN_EXTENTS from dba_tablespaces where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME                INITIAL_EXTENT MIN_EXTENTS
--------------------------- -------------- -----------
TEST_EXT                                    65536              1

INITIAL_EXTENT :初期エクステントのデフォルトのサイズ
MIN_EXTENTS:エクステントのデフォルトの最小数

それぞれよく見る数値です。

初期エクステントサイズは64KBで、1ブロック8KBとすると、
エクステントは1個で、初期エクステントは8ブロックですね。


じゃ、64KBで表領域作れるってこと?

SQL>create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 64K;


create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 64K
*
行1でエラーが発生しました。:
ORA-03214: 指定したファイル・サイズが必要最小値を下回っています。

うーん、エラー
まぁ、管理情報とかのオーバーヘッドもあるよね、
64KBから1KBずつ増やしていきます。


SQL> create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 81K;

表領域が作成されました。



81KBで作れました。


ちなみに、KROWNでエラー番号を検索すると、文書番号:35170に
表領域の最低値の目安が書いてあります。


使用可能エクステントを確認します。
SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';


TABLESPACE_NAME   BLOCK_ID   BYTES     BLOCKS
------------------- ---------- ---------- ----------
TEST_EXT                       4             65536          8


ブロックID4から8ブロック64KB使えるようです。
ブロックID4より前の3ブロックは管理用に使ってるんですかね。

あり??
8KB×12ブロック=96KB。。。

81KBで作ったのに???


SQL> select tablespace_name,bytes/1024 from dba_data_files where tablespace_name ='TEST_EXT';

TABLESPACE_NAME            BYTES/1024
------------------------ ----------
TEST_EXT                               88


ん?88KB=11ブロック??


C:\app\oracle\oradata\orcl>dir TEST_EXT01.DBF

98,304 TEST_EXT01.DBF

!!

96KB!? 12ブロックだ。。


ぐぬぬぬ。油断ならん。。


次回は、表領域が出来たのでオブジェクトを作っていきます。

次回:INITIAL_EXTENTと遅延セグメント作成な話2

2012年7月27日金曜日

JPOUGのイベントでOracle設計について話しました。



私は、Japan Oracle User Group (JPOUG)のメンバーであり、
Board Memberの一人でもあるのですが、

先日7/21(土)の「 JPOUG> SET EVENTS 20120721 」イベントのアンカンファレンス枠にて、
20分程度でOracle の設計関係(インフラ周り)の話をしました。

セッションの目的は以下2点です。
・Oracle設計の概要や注意点を知る
・Oracle設計への漠然とした不安の払拭

Oracle設計について話をしようと思った背景は、
仕事柄、設計を担当することが多いことと、
ちゃんと設計しておけばこんなことには、、、
というDBと出会ったりすることがあるため、
もっと多くの人が、設計を出来るように知識を共有したい、
うーん。。というDBが一つでも減ることを願ってでした。


セッションには50人前後の方が参加頂いたようですが、
何かしら得てもらえてたのなら幸いです。

色々伝えたいことが多過ぎて、20分では話し切れないこともあり、
飛ばしてしまった内容もあったので、
公開した資料をご確認頂ければと思います。






参加頂けなかったが、資料を確認される方へですが、
セッションでは以下の点を強くお話ししました。


・基本や機能は常々勉強しておこう
・システムをイメージし、よく考え、設計しよう
・当たり前のことををきっちりやろう
・要件はシステム全体で担保する。(Oracleだけで無理に担保しようとしない)
・サイジングでは悩み過ぎない。(悩む≠考える)
・分からなければ、実際に作ってみよう。やってみよう。


アーキテクチャや機能といった基本を身に付けていれば、
機能の詳細やパラメータなどについては、
オラクル社提供のマニュアルをきちんと確認しつつ進めればいいと思います。
(制限事項もちゃんと調べましょうね。)

それにより、新しい発見や再発見があるのも、
設計の楽しい部分の一つだと私は思います。




なお、資料について質問やご意見、うちの会社でちょっと話してよ。
みたいなのがあれば、コメントやメール等で気軽にご連絡下さい。



JPOUGに興味が湧いた人はこちらを確認ください。


イベントの報告や他の発表者の方の資料等については、
別途投稿しますね。

2012年5月18日金曜日

Oracle DB 移行作業おける事前検討1

先日、日本オラクル社の無償セミナーである
 「秘訣を直伝!最新オラクルデータベースへのアップ グレードテクニック」を受講してきた。

 アップグレードや移行に関するチップス・見ておくべき情報、
 手法についてのケーススタディが詰め込まれており、かなり有益だった。

 以下、自分のメモ用に何点かポイントを書いておく。(私の意見も入っています。)
 ※1.以下、文章が長くなるので、特定の理由がない限り
   アップグレードや移行を同義語として、移行とする。
 ※2.移行≒アップグレードを含む移行として記載している。

 前回:アップグレードや移行作業前のお作法

今回はテスト計画とネットワークへの考慮について

1)テスト
 ・移行テスト(リハーサル)
  -手順通り問題なく実施できるか
  -所要時間

  大事ですよね。
  手順に漏れがないか、所要時間を計測して計画停止時間の見積もりや
  移行手順の再検討を行う。
  あと、手順と計画停止時間に関連して、
  切り戻し判定ポイントや切り戻し条件や
  切り戻し手順を移行計画手順書に忘れずに含めることが必要。

 ・移行後の環境でのパフォーマンステスト
   -移行前環境とのパフォーマンス比較
   -レスポンス要件やスループット要件を満たせているか、
    バッチがタイムスケジュール内に終了するか

   新しいOS、マシン、バージョンに移行して遅くなるケースはほとんどないと思うが、
   DB統合などで、複数のDBが1DBサーバ上or RAC上に相乗りするという場合は、
   パフォーマンステストの分析により、
   OSやOracleのパラメータの調整やSQLの実行計画の固定化、
   リソース制御などのチューニング、
   今後ボトルネックとなる箇所の想定などが必要。
   ファイルのレイアウト調整やRAID調整をその時点でやるとしたら、
   設計そのもののミスかしら。。
   ハードリソースの追加は避けたいところ。

   言うまでもないが、移行前の環境でパフォーマンス・データを取得しておかないと
   比較できない。また、移行の計画段階から移行先でどのようなパフォーマンステストを
   どのような手段で実施するのかなどを検討しておく必要がある。
   例)どの時点で?どのようなデータで?どのようなツールで?どのような処理を?

   ※パフォーマンス・データの取得方法はSTATSPACKやAWR、
       サードベンダツールやOSSツールでの取得なんでもいい。


 2)ネットワーク環境の考慮
  物理的な限界は超えられない。


ネットワークインターフェースデータボリューム最大転送速度
100Mbit Ethernet11MB/sec40GB/hour(best case approach)
1Gbit Ethernet110MB/sec400GB/hour(best case approach)
10Gbit Ethernet1.1GB/sec4TB/hour(best case approach)
InfiniBand 4X QDR4GB/sec(theoretical)
3GB/sec(realistic)
10.8TB/hour

・プロトコル転送
 -ftp,scp,NFSのパラレルコピーを検討
・ネットワーク機器やセキュリティ設定による制限
・外部ネットワークプロバイダによる制限と距離的な制限

2012年5月14日月曜日

Oracle DB アップグレードや移行作業前のお作法

先日、日本オラクル社の無償セミナーである
 「秘訣を直伝!最新オラクルデータベースへのアップ グレードテクニック」を受講してきた。

 アップグレードや移行に関するチップス・見ておくべき情報、
 手法についてのケーススタディが詰め込まれており、かなり有益だった。

 以下、自分のメモ用に何点かポイントを書いておく。
 ※1.以下、文章が長くなるので、特定の理由がない限り
   アップグレードや移行を同義語として、移行とする。
 ※2.移行≒アップグレードを含む移行として記載している。
 ※3.以下、SQL文は環境によっては少なくない負荷を掛ける可能性があるので、
   実行タイミングは考えましょう。



  前回:OralceDB移行・アップグレード前に見ておきたい資料


■サニティ・オペレーション
  ここで言うサニティ・オペレーションとは、
  簡単に言うと、移行作業前に移行元の環境を整理・綺麗にしておこうね。
  この作業は、すべてのアップグレードや移行作業にも有効。


1)INVALIDオブジェクトへの対応
  1-1)INVALIDオブジェクトのチェック
     SQL> select unique OBJECT_NAME,OBJECT_TYPE,
         OWNER from DBA_OBJECTS where STATUS='INVALID';

 1-2)移行作業前にすべてのINVALIDオブジェクトを修正
    と資料にはあるが、1-1)の結果を精査して不要なものは削除、
    必要なものは、原因を調査してVALIDにいう感じが妥当かな。
    そもそも、運用中にINVALIDになっているなら削除していんじゃない?
    という考え方はありだと思う。

 1-3)SYSやSYSTEMスキーマのINVALIDオブジェクトをなくす。
    移行作業前にutlrp.sqlでINVALIDオブジェクトを再コンパイルする。
    うーん、1-2)の対応としてもutlrp.sqlは有益かも。

    ※utlrp.sqlは$ORACLE_HOME/rdbms/admin/utlrp.sql SYSで実行。


2)SYS/SYSTEMの重複オブジェクトの対応
  普通はこんなことはないだろうけど、
  パッチ適用後の流し忘れや、特定コンポーネント使用時の流し忘れ、
  実行ユーザ間違いとかで発生する。

 2-1)SYS/SYSTEMの重複オブジェクトをチェック
    SQL> select  OBJECT_NAME,OBJECT_TYPE from
        DBA_OBJECTS where OBJECT_NAME||OBJECT_TYPE
        in (select OBJECT_NAME||OBJECT_TYPE from DBA_OBJECTS
        where OWNER='SYS') and OWNER='SYSTEM' and
        OBJECT_NAME not in ('AQ$_SCHEDULES_PRIMARY',
        'AQ$_SCHEDULES','DBMS_REPCAT_AUTH');

 2-2)SYS/SYSTEMの重複オブジェクトの修正
    基本は、2-1)で出力されたオブジェクトのSYSTEM側のものを
    削除(drop)するようですが、HELP~というオブジェクトのみはSYSTEM側を残す模様。

    ・How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema [ID 1030426.6]
     も合わせて参照とのこと。※大体同じことしか書いてない。


3)INVALIDなコンポーネントの対応
 3-1)INVALIDオブジェクトのチェック
    SQL> select substr(COMP_ID, 1, 10) compid,
        substr(COMP_NAME,,24) compname, STATUS,VERSION
        from DBA_REGISTRY where STATUS != 'INVALID';

 3-2)移行作業前に全てのVALIDではないオブジェクトを修正
    と資料にはあるが、3-1)の結果を精査して不要なものは削除、
    必要なものは、原因を調査してVALIDにいう感じが妥当かな。
    そもそも、運用中にINVALIDになっているなら削除していんじゃない?
    という考え方はありだと思う。

 3-3)utlrp.sqlで再コンパイルしても、ステータスが修正されない場合
    以下の内容により追加の診断が必要

   ・Information On Installed Database Components and Schemas [ID 472937.1]
     -各コンポーネントの説明や参考noteが示されており、とても便利。
   ・How To Diagnose Components With NON VALID Status In DBA_REGISTRY 
    After an Upgrade [ID 753041.1]


4)ゴミ箱を空っぽに
  10g以降のバージョンからの移行である場合は移行元にてrecyclebinをパージする。
  SQL> purge DBA_RECYCLEBIN;


5)古いパラメータや隠しパラメータ、イベントパラメータの設定解除
  アップグレード時間が49分⇒7分になった事例もあるとのこと。


  -----

  以上だけど、基本は不要なものやゴミを綺麗にしておきましょうってことですね。
  アップグレード時や移行時のコンパイル対象や移行対象が減るだけでも、
  処理時間は短くなるだろうし。
  そもそも、INVALIDなオブジェクトを事前にチェックしておかないと、
  アップグレードや移行後に作業によりオブジェクトがINVALIDになったか
  判断できなくて混乱するよね。


  一手間の事前準備で作業時間の短縮や作業失敗のリスクを低減出来るなら、
  是非実施しておきたい作業ですね。



2012年5月13日日曜日

Oracle DB 移行・アップグレード前に見ておきたい資料

昨日、日本オラクル社の無償セミナーである
 「秘訣を直伝!最新オラクルデータベースへのアップ グレードテクニック」を受講してきた。

個人的にはセミナーによって、当たり外れの落差が激しいと感じているのだけど、
昨日は当たりだった。ありがとうございました。

 アップグレードや移行に関するチップス・見ておくべき情報、
 手法についてのケーススタディが詰め込まれており、かなり有益だった。


以下、自分のメモ用に何点かポイントを書いておく。

1.パッチセットのロードマップ
Release Schedule of Current Database Releases [ID 742060.1]
-Release 10.1 to 11.2までのPatch Set Release(PSR)のリリース日やら
   サポート予定が書いてある。
予定だと11.2.0.4.0は来年かぁ。。


2.アップグレード手引書
11.1.0.X(11gR1)
Oracle 11gR1 Upgrade Companion [ID 601807.1]
Oracle Database 11gR1 Upgrade Companion - 目次[KROWN#134166]

11.2.0.X(11gR2)
Oracle 11gR2 Upgrade Companion [ID 785351.1]
Oracle Database 11gR2 Upgrade Companion - 目次[KROWN#141177]

-KROWNめちゃめちゃ分かりやすい。
移行方法別のメリットとデメリットも載ってる。
3.のマニュアルと共に移行の話が上がった際に事前に目を通して
おくべき資料だ。


3.アップグレードマニュアル
Oracle Databaseアップグレード・ガイド11g リリース2(11.2)

   -やっぱりチェックしとかないとね。


4.その他の重要なノート
Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]
Complete checklist for manual upgrades of Oracle databases
  from any version to any version on any platform (documents only from 
  7.3.x>>8.0.x>>8.1.x>>9.0.x>>9.2.x>>10.1.x>>10.2.x>>11.1.x>>11.2.x) [ID 421191.1]

-2.よりも、もっと実際的な手順や内容が多い。
移行にくらべ、同一筐体内でのアップグレード案件はあまりないような気がするが、
事前・事後の内容はお作法としても知っておきたい。


5.OTNのOracle Database Upgrade
-中段には今回のセミナー資料の元資料のダウンロードページに行けます。
560ページのPDF資料って、、、


バージョンアップや移行(バージョンアップを含む)のどちらも、
バージョンが変わることによる仕様や動作の変更点や、
バージョンアップ後のリリースのバグ等を押えておくべきなのは変わらない。
移行の場合には、さらに移行方法の検討というタスクが重要。


上の資料だけど、
時間がない場合は、上記資料2のKROWNと4の内容の事前事後の作業部分を
さらさら読むのがいいだろう。

時間があって本腰を入れて取り組む人は、5から入るのが良いと思う。


言うまでもないけど、1,2,4の資料は保守契約がないと読めないのでご注意を。


次回以降もこのセミナーネタをメモメモしていく予定。
※いずれ、セミナー資料自体が公開されると思いますが。

2012年4月10日火曜日

Oracle OpenWorld 2012 Unconference presented by JPOUG

久しぶりの記事になります。
なぜ久しぶりかというと、タイトルにもありますが、
「Oracle OpenWorld 2012 Unconference presented by JPOUG」の準備や、
私もセッションを持っていたことから、そちらに集中していたことがあります。


今回のイベントは、JPOUGにとって初めての公の大きな舞台での活動だったのですが、
Unconferenceの運営を任せて頂いた関係者の皆様、ありがとうございました。


また、お越し頂いた皆さんもありがとうございました。
楽しめたでしょうか?


私の担当セッションは、トップバッターということもあり、
最初は緩いネタがいいだろうということで、Oracleのマニュアルについて話しました。
しかも40分間も(笑)


伝えたかったのは、
 「マニュアルの面白さや有益さ」
 「ググってるだけでは見えてこないこと」
 「英語サイトの有効活用のすゝめ」
 「スマートなマニュアル活用術」
になります。


誰得?とも思ったのですが、
一応、デモ部分も含めて分かるように、加筆した資料を公開しました。
誰かの役に立てば幸いです。



また、セッション後のフィードバックとして、
JPOUGサポートメンバーである日本オラクルの小田さんからアドバイスを頂き、
資料で紹介した以外のマニュアルの検索情報も載っているサイトがありましたので、
記載しておきます。(小田さん、ありがとうございます。)

Oracleエンジニア通信-Oracle マニュアル


最後になりますが、JPOUGの活動としては、次回は初夏に大きなセミナーを検討しています。
是非、そちらも楽しみにしててくださいね。

JPOUG公式サイト
JPOUG Facebookページ
※「Oracle OpenWorld 2012 Unconference presented by JPOUG」僕以外の人の
 セッション資料も見れますよ。

2012年3月9日金曜日

Japan Oracle User Group(JPOUG)について#3

前回に引き続き、Japan Oracle User Group(JPOUG)について書きたいと思います。

ブログを更新した旨をRTして下さった皆さん、ありがとうございます。<(_ _)>
沢山の方にJPOUGを紹介出来てとても嬉しいです。
今回が最終回なので、、、ね!ね!(笑)

RTやらブログ見て「いいね」してくれた人、
はじめましてです。これから一緒に楽しくやっていきましょう。
もちろん、RTしてくれて良くってよщ(゚▽゚щ)



ということで、今回は最後に、僕からのお願いと楽しみ方の続きについて書きます。

1.みんなの声を聞かせてくださいщ(゚▽゚щ)
 既に何度か紹介していますが、
 「Oracle OpenWorld Unconference presented by JPOUG」と題して、
 JPOUGはOracle OpenWorldをハイジャック!?することにしました。


 そのUnconferenceで僕はセッションを担当するのですが、
 みんなと一緒に楽しめるUnconferenceをやりたいと考えています。
 そのネタの一つとして、現在FBのJPOUGページでアンケート2つ行っています。

 -Japan Oracle User Group (JPOUG)の質問-
 自由にいくつでも投票してほしいし、なければドンドン追加してくださいщ(゚▽゚щ)

 
 知らないものがあったら調べてみるのもいいかもです゚+.(・∀・)゚+.゚


 あと、FBをやってない方はGoogleDocsからも投票が可能です。
 -Oracler意識調査のお願い♪-

 こちらは名前とかは記入不要ですので、FBやってるけどちょっとね。。。
 という方はこちらに投票下さい。


 Unconferenceでは結果を考察するとともに、
 なぜそれが好きなのか?を熱く語る時間も用意しようと思っています。
 是非是非、アンケートもUnconferenceもよろしくです。


 鼓動枠もまだ何枠か残っている様なので、興味のある人は是非応募してみて下さい。
 鼓動枠”オーガナイザーの募集
 OracleOpenWorldTokyo
 wmo6hash::blog Oracle OpenWorld Unconference presented by JPOUG
 ※三年前の様子も分かります。

2.書いてみる、聞いてみる、やってみる、集まってみる
 JPOUGはユーザ会であり、みなさんそのものです。
 たまたま僕はBoard Memberをやっていますが、
 僕も一人のユーザ会のメンバーにすぎません。

 FBのウォールに、自分のブログをリンクするのも、
 共有したいこと書くのも、企画を提案してみるのも、
 僕がユーザ会のメンバーとしてやりたいからやっているだけです。


 みんなも先ずはやりたいように使ってみてください。
 (問題がありそうなものであれば、運営の方でサックリ行くので 笑)


 ただ、もし、やりたいことがFBの管理者じゃないと出来ないとか、
 FBとかではなく、もっと大きなこんなことしたんいんだ、
 こんなことはできないのか?というものがあれば是非連絡を下さいね。

 例)FBでクエスチョンしたいけど、管理者じゃないから出来ないとか


 あと、FB以外のコミュニケーション方法も用意しているので、
 こちらも是非見てくださいね。
 コミュニケーション



・・・・



 また今日も長くなってしまいました。。

 でも今回でJPOUGの紹介記事はお終いにします。



 最後に一言だけ。

 僕らBoard Memberはみんなと出会い、一緒に何かをしたい。
 その思い一つを胸に、去年の夏から準備をしてきました。



 「はじめまして、こんにちは。これからよろしくね。」

2012年3月8日木曜日

KROWN、有効活用したいよね。

FBのJPOUGページに書いた
KROWN#136531ネタに「いいね」してくれた人がいたので、
父ちゃん浮かれて、張り切ってブログなんか書いちゃいますよ(*゚∀゚)=3


何かあるといきなりGoogleやKROWNを検索しがちですが、
情報が断片的だし時間がかかるのでやめた方がいいです。


と、
そんな思いからやるのが、
「Oracle OpenWorld Unconference presented by JPOUG」の僕のセッションです。

宣伝しつこい?(笑)

と、まぁそれは置いといて、

まとめKROWNですが、[マスターノート]って言うんですね、
マスターノートって、まぁ索引みたいなものじゃないですか、
有効活用しない手はないと思います。


KROWN検索画面のキーワード部分にマスターノートを指定して
文書タイプの「マニュアル・パッチについての文書」にチェックを入れて検索すると、
純粋なマスターノートだけを検索できます。

闇雲にKROWNを検索して時間を潰しちゃうくらいなら、
有効活用したいですよね。



まぁ、エキスパートの方々はMOS(My Oracle Support)一択とか言っちゃうんですけど。。。



こんなネタが豊富にあるよ。そう、JPOUGならね。

2012年3月7日水曜日

Japan Oracle User Group(JPOUG)について#2

前回に引き続き、Japan Oracle User Group(JPOUG)について書きたいと思います。

ブログを更新した旨をRTして下さった皆さん、ありがとうございます。<(_ _)>
今回も宜しくお願いします(笑)

RTやらブログ見て「いいね」してくれた人、
はじめまして。これから楽しくやっていきましょう。
もちろん、RTしてくれて良くってよщ(゚▽゚щ)



ということで、今回は、例えばどんなことしている?できるの?
について書きたいと思います。


1.JPOUGはみんなの出会いや語らう場を創出します。
http://www.facebook.com/jpougfan?sk=wall

使い方は、、、まぁ、自由に書き込んでください(笑)
感動したことや、共有したい技術情報、
飲み会の企画やOracle技術者同士の合コン企画なんかも面白いかもしれません。
是非、結婚式で出会いは「JPOUGでした」とお披露目してください(笑)

気軽に書き込みやコメントしてくださいね。



例えばですが、僕は今日こんなことを書き込みました。
「KROWN#136531っていいよね。STATSPACKに読み替えても理解が深まるし。
他にも、まとめKROWN増えたよねー」

・・・。

まだ、誰もコメントくれていません(´Д`)
そんな知ってて当たり前!とかもっといいの知ってるぜ!とか。"φ(・ェ・o)~メモメモ
とか反応がないと寂しいなぁ・・・('・_・`)

・・・。気軽に書き込みやコメントしてくださいね。
Board Memberも楽しみにしています。





2.知識や発見、感動などをみんなへ発信する場を創出します。
JPOUGは初夏に大規模なセミナーを企画していますが、
まずは、デビュー戦(みんなへの挨拶の場と)して、
Oracle OpenWorld Unconference presented by JPOUG」と題して、
Oracle OpenWorldをハイジャック!?することにしました。

Unconferenceとは誰もが参加できるカンファレンスで、
オーガナイザーの話を一方的に聴くのではなく、参加者の意見や質問によってインタラクティブに
進行する技術セミナーです。


僕は、2セッションを持つ予定です。


です。。。。


でした。。。。。。


が、


やはりそこは、JPOUG!
「場」や「機会」を創出するのが意義!!

小生のつまらない(嘘ですよ嘘。きっと。。)セッションを1つ解放して
“鼓動枠”と題して、発表者を募集します!!!
誰かと何かを共有したい!」と思う人は是非手を挙げてみて下さい。
5分でも10分でも20分でも、発表を楽しみにしています。

詳細についてはこちらを確認してくださいね。
“鼓動枠”オーガナイザーの募集
OracleOpenWorldTokyo



・・・・



また今日も長くなってしまいました。。


僕からのお願いやら、まだまだJPOUGの楽しみ方があるのですが、
それはまた次回の記事で。

2012年3月6日火曜日

Japan Oracle User Group(JPOUG)について#1

僕はJPOUGのBoard Memberの一人なんですが、
本投稿はいつもの技術ネタじゃなくて、Japan Oracle User Group(JPOUG)について
ちょっと書きたいと思います。

Japan Oracle User Group(JPOUG)は去年の10月に発足した、
IOUC(International Oracle Users Group Community)にも参加している
日本のOracleユーザグループです。


設立趣旨はJPOUGサイトを見てもらえればと思います。
Board Memberによっても少しずつ思いが違うところもあるかもしれないのだけど、
簡単に言うと、OracleユーザやOracle好きな人同士で繋がったり、楽しんだり、
一緒に何かしたりする、「機会」「場」創出する活動を行っています。

大切にしているのは、「面白いこと」や「ためになること」ではなく「機会」や「場」を
「与える」のではなく「創出」することです。

JPOUGとはなんなのか?どう楽しめばいいのかは、うまく説明できません。
Board Member自身、オラクルという単語を中心とした出会いや化学反応を
楽しみにしているユーザ会の一員なのです。



例えばとして、個人的なエピソードを1つお話しすると

Board Memberで打ち合わせしたり、飲んだりしている時に、
僕は、ふと不思議な気持ちになることがあります。

Oracleのユーザ会だから、Oracleの話ばかりしていると思いきや、会話は多岐に亘ります。
家族のことや趣味のこと、働き方や技術動向。
もちろん異性の話もしたりしなかったり。


年上のメンバーから、色々な人生経験やアドバイスをもらったり
年下のメンバーの初々しさに若さや懐かしい思いをもらったり(笑)

JPOUGをやっていなかったら、Oracleの技術力アップはさることながら、
こんな風に色々な経験もなかったんだろうなぁ、、、と

年齢や仕事もバラバラな僕らは、
Oracleというものを共通に知り合い、集っているんだなぁと。

とても不思議な気持ちなります。


もっと沢山の人に同じように不思議な気持ちになってほしいなと思います。


・・・

ちょっと長くなってしまったので、具体的に例えばどんなことしているの?
という説明はまた次回に。



一緒にOracleで楽しんだり、新しい何かに出会ってみたい人は、
JPOUGファンページ でイイねを押してください。

押さなくてもウォールは見れるけど、色々言葉を交わしませんか?


facebookやってない人は、グーグルで繋がってみませんか?
JPOUGのGoogle グループ



あ、最後になっちゃいましたが、
僕らBoard Memberは、それぞれちゃんと生業があり(当たり前ですが)、
JPOUGのファンページが「イイね」されたからといって、何の得もありません(笑)

Oracleのユーザ会のメンバーだからといって、Oracleを褒め称えているでもありません。
特に僕は?f(^^);


なんか質問があったら、気軽にコメントでもTiwtterでもメールでも連絡下さいね。

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いんじゃん?
とか言っちゃってすみません。。

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

でしたとさ。