株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
＼_〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜_／
^^＼_ 2003.07.31 _／^^
^^^^＼_ 海の見える開発室 −解き放てmind！− _／^^^^
^^^^^^＼_ Vol.003 _／^^^^^^
^^^^^^^^＼_〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜_／^^^^^^^^
≪目次≫
■ディベロッパーX 〜開発者たちの挑戦〜
◆プロアクティブな監視
■どっぷり開発生活
■開発フリートーク
■お知らせ・・・
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■ディベロッパーX 〜開発者たちの挑戦〜
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
◆プロアクティブな監視
前号では「無意味なシステム・リソースの追加投資を避ける」ことについて調
べてみました。そこで「ディスクキャッシュのメリットとOracleチューニング
の重要性」を知り、開発現場でもOracleコンサルティング心得を念頭に開発に
取り組んでいることを知りました。
今回は、そーは言ってもパフォーマンスを向上させなくちゃいけないんだよ！
とおっしゃる方のために、パフォーマンスに影響を与えているものはなんなの
か？について探りを入れてみようと思います。
だいたい、システムって、どーしてパフォーマンスが悪くなってくるの？
お金を掛けてきちんと作ったんだから、ずっと作った時のパフォーマンスでい
てよっ！ってな感じなんですけどねぇ。
データベース設計・開発・管理、Oracleコンサルタントの方に役立つ情報を集
めてきまーす！！！
⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃
〔KA〕「監視」の目的は・・・と言うと、トラブルを未然に防ぐためだと思う
んですけど、トラブルを未然に防ぐための「プロアクティブな監視」と
言うと？
〔DV〕まず「領域的な問題」がナンバーワンに挙げられるね。
〔KA〕「領域的な問題」と言うと・・・？
〔DV〕例えば、
何百ものオブジェクトが何百ものエクステントを発生させていて、
そのエクステントを見るためのビューも膨大に膨れ上がっていて、
監視のためのSQL文も負荷が掛かる状況！
〔KA〕そんな状況になっちゃったらどうするんですか？
〔DV〕そりゃ〜領域再構築をナビゲートするのが最も重要なアクションプラン
だよ！
〔KA〕領域再構築ですかぁ？？？
そもそも、データが増えてくると、最初に確保したエリアに入りきれな
くなって自動的にエクステントが発生するんですよね？
〔DV〕そうだね。
〔KA〕そしたらハードディスクをバーンと増設しちゃうっていうのは？？？
〔DV〕おいおい！エクステントというのはディスクの物理容量が足りないから
発生するのわけじゃないんだよ。テーブルとかインデックスと呼ばれる
オブジェクトは予めテーブルスペースという論理的な単位で獲得されて
いる領域内に作るんだけど、そこで各オブジェクトごとに割り当てたエ
クステント、すなわち初期の領域が足りなくなると自動的にエクステン
トは獲得されるんだ。この自動的に拡張されたエクステント数が膨大に
膨れ上がり、予め用意したファイルに収まらなくなると、今度はデータ
ファイル自身も自動拡張したりするんだけどね。その時は、確かにハー
ドディスクの増設が必要になるかもしれないよ。だけど、エクステント
の中身をきちんと吟味してみると、スカスカであったり（空き領域のフ
ラグメンテーション)、小さなオブジェクトにもかかわらず見積もり時に
大量の初期エクステントを割り当てていたり、と検討の余地が沢山ある
場合が少なくないんだよ。
〔KA〕なるほどね！ところで、エクステントが発生すると何か都合が悪いんで
すか？例えば、Oracleのパフォーマンスが悪くなる...とか。
〔DV〕パフォーマンスに影響する場合としない場合があるので、少し整理して
みようか！
1.オブジェクトのエクステントを管理する空き領域管理方式は２つある
(1).ディクショナリ管理
(2).ローカル管理
2.上記の管理方式はテーブルスペースの作成時に決まる。したがって、
テーブルスペース単位に管理方式が違う場合もあり
(1).ディクショナリマネージメント・テーブルスペース(DMT)
(2).ローカルマネージメント・テーブルスペース(LMT)
と区別して呼ぶ。
3.大量なエクステント発生がパフォーマンスに影響するのはDMTだけ。
〔KA〕じゃ、ディクショナリマネージメント・テーブルスペース(DMT)を使わ
なければいいんじゃないです？
〔DV〕そもそもLMTはOracle8iからサポートされた機能だから、バージョンアッ
プしたユーザであればDMTを使い続けているというのがほとんどだと思
うよ。その他にも次の理由でDMTを使っているお客さんも少なくないしね。
・アプリケーション・パッケージでの指示で
・Compatibleパラメータで8i以前を指定する必要がある
・領域（エクステント）を細かく管理したい
〔KA〕なるほどね、LMTは新しい機能だから使っていないお客さんも沢山いる
んですね！それに、エクステントを発生させないように、領域見積もり
をきっちり行っておけばどちらでやろうが関係ないですもんね。
〔DV〕その通り！
PIではエクステントの監視だけではなく、オブジェクトの増加傾向や
テーブルスペースの満杯予測までもサポートしてるんだ。例えば、
『Orderテーブルのレコード数が毎月nn%の割合で増えています』とかね。
〔KA〕エクステントを見るだけならOEMでもできますもんね！
〔DV〕いつも鋭いネ。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■どっぷり開発生活
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ということで、今回の話題は以下の2点です。
(1).DMTを使っているにもかかわらず、大量にエクステントを発生させている
お客さまに警告する
(2).領域管理方式に関わらず監視報告すべき項目を整理する
┏─────────────────────────────────┓
┃総合評価欄 ┃
┗─────────────────────────────────┛
------------->> (1)領域管理の見直しが必要です <<----------------------
ディクショナリ・マネージメント・テーブルスペース(DMT)を使用しています
・エクステントが発生しました。
・100個以上のエクステントが発生したオブジェクトがあります。
・テーブルスペースのフラグメンテーションが多く発生しています。
・エクステントが大量に発生しているテーブルスペースが存在します。
------------->> (2)領域管理の見直しが必要です <<----------------------
データファイルが自動拡張しました。
テーブルスペースの空き容量が足りず、次のエクステントは確保出来ません
現在のエクステント数がMAXEXTENTSの70%に達してます
----------------------------------------------------------------------
┏─────────────────────────────────┓
┃DMT監視の課題 ┃
┗─────────────────────────────────┛
DMTのディクショナリテーブルは、以下の4つがある。
FET$...空き領域管理
UET$...エクステント管理
SEG$...セグメント管理
TSQ$...セグメント管理
領域の状態をモニタリングするのはとっても大切なことだが、安易に上記の
ディクショナリを見ると大変な負荷がかかってしまう。お客様の環境で負荷を
かけないように、更新されたオブジェクトをモニタリングし、それがエクステ
ントしたかを監視していた(PI5.1) 。しかしタイミングによっては、モニタリ
ングでは引っかからなかったオブジェクトのエクステントを見逃してしまう
ケースがあった。見落とされたエクステントは、評価レポートの中で1日単位
でフォローされるが、UET$やFET$が膨大に膨らんだサイトでは、レポート作成
でRUN TIMEOVERになってしまう！なんていう（重症な）事さえあった。
#独り言：他社監視ツールは平気でエクステント監視を走らせてる！？
#問題があったときには「エクステント監視はdisableにしてください」とか
#「マシンを上げてください」なんて本末転倒なことを言うのかな？？？
┏─────────────────────────────────┓
┃PI5.2詳細メッセージ1（DMT対応) ┃
┗─────────────────────────────────┛
●DMTエクステントを総評として取り上げるもの●
1.50個以上のエクステントオブジェクトを持っている
2.今日発生したエクステントがある
3.UET$やFET$が膨大になっている！という警告
●Oracleコンサルティングの総評コメント指標●
┏━┓
┃１┃「エクステントが発生しました」
┗━┛
このメッセージはエクステント100個あるものがありますよ！というメッセー
ジより上に来ると思う。でも、ここで注意しなければならないのは：
・オブジェクトの種類がRBSであれば無視すること
・毎日Truncateされているようなワーク・オブジェクトが混じる場合もあるの
で、昨日の報告なんかも参考にして、ワーク・オブジェクトの場合は無視する。
・オブジェクトの存在するTBSのFreeを見て、次のエクステントで：
・自動拡張しますよ！
・Freeがなくなりますよ！
と言ってあげる。ここでは、Local Extent管理も対象にする。
┏━┓
┃２┃「大量にエクステントが発生したオブジェクトが存在します」
┗━┛
ここではRBSも同様に扱うべきなんだけど、後に続く文言が変わってくるので
RBSは別のところで扱う。ということは、Table, Index（共にPartitionedも含
む）、Clusterといったところがターゲット。しかし「大量のエクステント」
の「大量」っていくつから判断できるのか？例えば、IndexでRange検索として
も使われていれば、10個のエクステントも大量と言っていいかもしれない。
議論しても根拠が見えてこないので、50個を超えたものが有れば「大量」とし
てしまう。この辺は大雑把だが、この後がむしろ大事！！！
≪Used Extentの調査≫
select SEGFILE# count(*) EXTENTS from uet$ where ts#>0
group by SEGFILE# having count(*) > 50
そもそも、この処理が相当遅いサイトが存在します。（UET$のカウントが150
万件もあったなどということもある)そこで、次のことを調べる必要がある。
┏━┓
┃３┃「エクステントが大量に発生していて」かつ
┗━┛「テーブルスペースのフラグメンテーションも大量に発生しているか？」
≪Free Extentの調査≫
select ts#, count(*) from fet$ group by ts# having count(*) > 100
これが大量に発生しているのは、TRUNCATEなどで領域の解放を繰り返すうちに
空き領域が断片的に残ってしまっている状態。50万件を超える空きエクステン
トが存在しているケースもあった。そんな時に、テーブルスペースの空き状況
を見るDBA_FREE_SPACEを検索したら戻ってこなくなる。これを解消できる可能
性があるのがALTER TABLESPACE xxx COALESCEだ。
≪PI52詳細メッセージ≫
◆_FET_COUNT＞10万件の場合
MSG:「ディクショナリ・エクステント管理」方式のテーブルスペースのフラグ
メンテーションが大量に発生している可能性があります。
コアレスを実行することを強く勧めます。
SQL> alter tablespace TABLESPACE_NAME coalesce;
keyword=COALESCE
TABLESPACE_NAME FREE_EXTENTS
--------------- ------------
users 10000 10000 alter tablespace TABLESPACE_NAME coalesce;
keyword=COALESCE
TABLESPACE_NAME PERCENT_BLOCKS_COALESCED
--------------- ------------------------
users
このビューは、FET$の隣り合った数をカウントアップするので、隣り合っ
た数が膨大であれば時間がかかってしまう。従って上記のようなケースで
あれば絶対に見てはならない。
select tablespace_name, percent_blocks_coalesced
from dba_free_space_coaleced
where percent_blocks_coalesced > 25;
◆_UET_COUNT＞10万件の場合
MSG:「ディクショナリ・エクステント管理」方式のテーブルスペースにエクス
テントが大量に発生しているオブジェクトがあります。
発生しているエクステントの数が多すぎるためオブジェクトを特定する監
視が実行できません。
DB Scopeを使用してオブジェクトを特定してください。
keyword=DMT
TABLESPACE_NAME EXTENTS
--------------- ------------
users 10000 10000>extentsを対象
ここではUET$のカウントを見る。合計が10万を超えているような場合であ
れば、DBA_EXTENTSやSEG$を見るような監視ははじめからスキップ。
また、UET$のカウントは毎日見ることもないので_UET_COUNT_INTERVALを
作成し、デフォルトで1週間単位で見るようにする。
◆_UET_COUNT<10万件の場合
MSG:エクステントが大量に発生した「ディクショナリ・エクステント管理」方
式のオブジェクトがあります。
select u.name||'.'||o.name||'('||so.object_type||')' OBJECT_NAME,
s.extents, s.maxexts
from sys.user$ u, sys.obj$ o, sys.ts$ ts,
sys.sys_objects so, sys.seg$ s, sys.file$ f
where ts.ts# in (select ts#
from sys.ts$ t
where t.bitmapped = 0
and t.contents$ = 0)
and s.file# = so.header_file
and s.block# = so.header_block
and s.ts# = so.ts_number
and s.ts# = ts.ts#
and o.obj# = so.object_id
and o.owner# = u.user#
and s.type# = so.segment_type_id
and o.type# = so.object_type_id
and s.ts# = f.ts#
and s.file# = f.relfile#
and s.extents > 50
order by s.extents desc, u.name
OBJECT_NAME EXTENTS MAX_EXTENTS
------------------------------ ---------- -----------
SCOTT.FLAGMENT(TABLE) 35021 2147483645
SCOTT.TB_DICT2(TABLE) 25163 2147483645
SCOTT.TB_LOCAL1(TABLE) 17457 2147483645
SCOTT.TEST(INDEX) 107 2147483645
Action Toolとリンクした場合、INDEXに関してはalter index rebuild
あるいはcompressをナビゲートする。
ここで勘違いしやすいのは、大量のエクステントが問題になるのはディク
ショナリ・エクステント管理方式の時だけだということである。上記では
UET$と無理矢理Joinすることにより、ディクショナリ・エクステント管理
方式のものだけを抜き出している。
┏━┓
┃４┃「STエンキューで待ちが発生してるか？」
┗━┛
DMTの場合、TRUNCATEでSTエンキューが発生する。原因は、大量に発生したエ
クステントをTRUNCATEしているからである。
検索の条件は：
(1).STエンキュー待ちが1分以上ある。
(2).50個以上エクステントしたオブジェクトがある。
MSG:STエンキューで待ちが発生しています。TRUNCATEを行うオブジェクトが大
量にエクステントしている可能性があります。
ローカルマネージメント・テーブルスペース(LMT)ではSTエンキューは発生
しません。
TRUNCATE TABLE ... REUSE STORAGEで回避はできますが、空エクステント
がテーブルスペースに残ります。
keyword=LMT
┏─────────────────────────────────┓
┃PI5.2詳細メッセージ2 ┃
┗─────────────────────────────────┛
●エクステント管理方式の種別に関係なく出されるメッセージ●
エクステント関連：
MSG:本日のエクステント一覧（意味合いが異なるためローカル、ディクショナ
リでグルーピング）
MSG:現在のエクステント数がMAXEXTENTSに達してます
MSG:現在のエクステント数がMAXEXTENTSの70%に達してます
MSG:テーブルスペースの空き容量が足りず、次のエクステントは確保出来ません。
データファイルのAUTOEXTENDはOFFになっています。
MSG:テーブルスペースの空き容量が足りず、次のエクステントは確保出来ません。
データファイルのAUTOEXTENDはONになっていますがMAXSIZEを超えてしま
います。
MSG:テーブルスペースの空き容量が足りず、次のエクステント時が確保出来な
い可能性があります。
MSG:テーブルスペースの空き容量が足りず、次のエクステント時にはAUTEXTEND
が発生する可能性があります。
MAXEXTENTS≠UNLIMITEDのオブジェクトがMAXエクステントに近づいていないか？
SQL> select ds.owner , ds.segment_name , ds.segment_type ,
ds.bytes/1024 kbytes , ds.extents, ds.max_extents
from sys.dba_segments ds
where ds.max_extents < 2147483645 and ds.extents > 1
order by ds.extents desc , ds.owner
OWNER SEGMENT_NAME SEGMENT_TYPE KBYTES EXTENTS MAX_EXTENTS
-------- -------------------- ------------------ ---------- ---------- -----------
SYS C_FILE#_BLOCK# CLUSTER 32410 19 121
SYS HIST_HEAD$ TABLE 9610 16 121
SYS C_COBJ# CLUSTER 9650 16 121
SYS C_TS# CLUSTER 9610 16 121
ELLEAIR TEST1 TABLE 6410 15 121
SYS EXT_TO_OBJ TABLE 6410 15 121
SYS SYS_IOT_TOP_93019 INDEX 6410 15 121
ELLEAIR TEST00 TABLE 4280 14 121
SYS I_HH_OBJ#_COL# INDEX 4280 14 121
SYS I_HH_OBJ#_INTCOL# INDEX 4280 14 121
SYS TEST_ZPRT_SQA TABLE 2860 13 121
表領域関連：
MSG:表領域がOFFLINEになりました。
MSG:表領域の空きが減少しています。
Autoextensible datafile:
MSG:データファイルが自動拡張しました
データファイル名、回数、サイズ
（全てのデータファイルの拡張回数の合計が10回以上の場合、上記に合わせて
以下のメッセージを出力）
MSG:AUTOEXTENDが多数発生しています、AUTOEXTENDは負荷の掛かる処理ですので、
あらかじめ必要なサイズを見積もって、データファイルを拡張して下さい。
またはAUTOEXTENDのNEXTサイズを調整してください。
ALTER DATABASE DATAFILE 'data_file_name' RESIZE integr M(K)
ALTER DATABASE DATAFILE 'data_file_name' AUTOEXTEND ON NEXT integterM(K)
MSG:これ以上自動拡張できません AVAILABLE_INC<1 のとき
MSG:データファイルのサイズが2GBを超えています
MSG:自動拡張したブロック数がMAXBLOCKSのnn%になりました。後nn回拡張できます。
自動拡張したデータファイル
select dd.file_name,dd.tablespace_name,dd.bytes,
dd.increment_by*ts.block_size as INC_BYTES,
(dd.bytes - vd.create_bytes)/(dd.increment_by * ts.block_size) as AUTOEXTEND_CNT,
(dd.bytes - vd.create_bytes) as AUTOEXTEND_BYTES
from dba_data_files dd, v$datafile vd, dba_tablespaces ts
where dd.file_id = vd.file#
and dd.tablespace_name=ts.tablespace_name
and dd.increment_by > 0
and dd.autoextensible = 'YES';
FILE_NAME TABLESPACE_NAME BYTES INC_BYTES AUTOEXTEND_CNT AUTOEXTEND_BYTES
-------------------------------------------------- --------------- ---------- ---------- -------------- ----------------
/mnt2/home/ora901/oradata/ora901/system01.dbf SYSTEM 508559360 10485760 48.5 508559360
/mnt2/home/ora901/oradata/ora901/undotbs01.dbf UNDOTBS 4430233600 5242880 845 4430233600
/mnt2/home/ora901/oradata/ora901/drsys01.dbf DRSYS 20971520 655360 32 20971520
/mnt2/home/ora901/oradata/ora901/example01.dbf EXAMPLE 10485760 655360 16 10485760
/mnt2/home/ora901/oradata/ora901/indx01.dbf INDX 26214400 1310720 20 26214400
/mnt2/home/ora901/oradata/ora901/tools01.dbf TOOLS 122552320 327680 374 122552320
/mnt2/home/ora901/oradata/ora901/users01.dbf USERS 798228480 1310720 609 798228480
/mnt2/home/ora901/oradata/ora901/ext_tst_local.dbf ext_tst_local 20971520 655360 32 20971520
/mnt2/home/ora901/oradata/ora901/ext_tst_dic.dbf ext_tst_dic 20971520 655360 32 20971520
/mnt2/home/ora901/oradata/ora901/insight01.dbf INSIGHT 125829120 10485760 12 125829120
/mnt2/home/ora901/oradata/ora901/DF_DICT2 TB_DICT2 51546112 2048 24657 50497536
/mnt2/home/ora901/oradata/ora901/mo_test2.dbf MO_TEST2 6291456 2048 2048 4194304
/mnt2/home/ora901/oradata/ora901/oba.dbf TS_OBA 525336576 2048 512 1048576
/mnt1/oba_test/oem.dbf OEM 104857600 2048 0 0
┏─────────────────────────────────┓
┃PI Knowledge Center ─ コンテンツ ─ ┃
┗─────────────────────────────────┛
●ディクショナリ・マネージメント・テーブルスペース●
＜KnowledgeCenter:keyword=DMT,EXTENT, EXTENTS, UET$, FET$, COALESCE＞
UET$やFET$で空き領域を管理する方式を「ディクショナリ・エクステント管理」
方式といいます。エクステントだらけのオブジェクトを持つサイトや、テーブ
ルスペースの断片化が進行しているサイトでは、これらの空き領域を管理する
ディクショナリ・テーブルへのメンテナンスに負荷がかかる！というかなり深
刻な問題を抱えることになります。このような問題を起こさないのが「ローカ
ル・エクステント管理」方式です。Oracle8 以降を新規に導入したサイトであ
ればデフォルトのローカル・エクステント管理が使われる場合が多いのですが、
旧バージョンからの移行やアプリケーション・パッケージでの指示によりディ
クショナリ・エクステント管理方式を使っているユーザも少なくありません。
ディクショナリ・マネージメント・テーブルスペース(DMT)を使っている場合
の問題点はエクステント時に：
・リカーシブコールが発行される
・UNDOエントリが作成される
・フラグメンテーションが起きやすい coalesce tablespaceが必要
・drop/truncateに時間がかかる STエンキューが発行される
ローカルマネージメント・テーブルスペース(LMT)では上記の心配がありません。
DMTを使う場合の注意：
・オブジェクト作成時に綿密な領域見積もりを行う
・エクステントやTBSのフラグメントが多発する前に再作成を行う
・TBSのフラグメントが問題の場合はALTER TABLESPACE xxx COALESCEを実行する
●コアレス●
＜KnowledgeCenter:keyword=COALESCE＞
一度COALESCEをしたからといって、全ての連続領域が結合するわけではなく、
何度かCOALESCEを繰り返すうちに全ての連続領域は結合されます。
空き領域のフラグメンテーションが多数発生しているサイトでは、COALESCEは
時間と負荷のかかる処理です。COALESCE処理の実行はタイミングを考慮してく
ださい。
COALESCEはディクショナリ・マネージメント・テーブルスペース(DMT)で必要
な処理です。ローカルマネージメント・テーブルスペース(LMT)では必要があり
ません。
●ローカル・マネージメント・テーブルスペース●
＜KnowledgeCenter:keyword=LMT＞
Oracle8iよりエクステント管理方式は「ディクショナリ管理」と「ローカル管
理」があります。さらに「ローカル管理」には「SYSTEM管理」と「UNIFORM管理」
が存在します。
「SYSTEM管理」はOracleが自動でエクステントサイズを決定します、これに対
して「UNIFORM管理」は表領域作成時に指定した均一サイズのエクステントだ
けになります。これらはDBA_TABLESPACESのALLOCATION_TYPEで「USER」(ディク
ショナリ)、「SYSTEM」「UNIFORM」で確認できます。
・Oracle9iのデフォルトの管理方法は、「ローカル管理」です。
・ローカル管理は、表領域内のエクステント情報をビットマップで管理します。
ビットマップ内のビットは、1ブロックに対応します。
・ディクショナリ管理と比較して、ローカル管理表領域の方がパフォーマンス
と管理性に優れていますが、記憶領域を細かく設定することはできません。
・エクステントのサイズは、デフォルトでは、可変エクステント・サイズです
が、UNIFORM句を指定すると、均一なエクステントによる管理が可能です。
・データ・ディクショナリにより管理されるディクショナリ管理と比較して、
ローカルに管理されるローカル管理は、競合を少なくすることができる。
・ローカル管理のエクステントの場合、記憶域パラメータNEXT、PCTINCREASE、
MINEXTENTS、MAXEXTENTS およびDEFAULT STORAGEは無効です。
SQL> select TABLESPACE_NAME, EXTENT_MANAGEMENT, ALLOCATION_TYPE from dba_tablespaces;
TABLESPACE_NAME EXTENT_MANAGEMENT ALLOCATION_TYPE
------------------------------------ ---------------
SYSTEM LOCAL SYSTEM
UNDO1 LOCAL SYSTEM
TEMP LOCAL UNIFORM
UNDO2 LOCAL SYSTEM
USERS LOCAL SYSTEM
自動セグメント領域管理
SEGMENT SPACE MANAGEMENT AUTO
LMTのビットマップ管理が前提
PCTUSED, FREELIST, FREELIST GROUPを設定しない
CREATE TABLESPACE userdata DATAFILE 'filename'
SIZE 100M AUTOEXTEND ON NEXT 5M MAXSIZE 200M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO
●オートエクステンド●
＜KnowledgeCenter:keyword=AUTOEXTEND, NEXT＞
AUTOEXTND ONでNEXTを指定しないとデフォルトで1-Oraclブロックになる。
例えば、新しいエクステントのサイズが1Mでブロックサイズが8Kだと128回も
拡張処理をしてしまいます。このような場合はNEXTサイズを増やします：
SQL> ALTER DATABASE DATAFILE 'data_file_name' AUTOEXTEND ON NEXT integter M(K);
また、データファイルのサイズを見直します：
SQL> ALTER DATABASE DATAFILE 'data_file_name' RESIZE integr M(K);
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■開発フリートーク 〔by 四谷 兼三〕
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
みなさん、SQeeL というプログラミング言語をご存知ですか？
SQeeL は弊社が開発し、GPL に基づくフリーソフトウェアとして公開している
プログラミング言語です。現在、PI(Performance Insight) を構成しているプ
ログラムの多くが SQeeL で開発されています。
SQeeL は PI の開発効率向上を目的に発展してきましたので、データベースア
プリケーションや Web アプリケーションの開発に便利な機能を多数備えてい
ます。また、仮想マシンアーキテクチャとデマンドコンパイルの採用により、
スクリプト言語の手軽さはそのままに、高速な動作も実現しています。詳しく
は http://www.sqeel.org/ にてチュートリアルやリファレンスを公開してい
ますのでご覧ください。ソースコードのダウンロードも可能です。
SQeeL 自体はプログラミング言語として、ある程度の完成度に達してしまった
ため、開発を一時中断していましたが、現在、さらにパワフルな言語にすべく、
次期バージョンの開発プランを構想中です。また、開発方式もよりオープンソ
ースソフトウェア的に、多数の開発者が自由に参加できる方式に移行しようと
考えています。ただ、そのためには環境等を整備する必要がありますので、現
在、どのような形態にすべきか検討中です。
（詳細が決まりましたら本メルマガにてご報告させていただきます。）
将来的には SQeeL を Perl や Ruby、PHP、Python のような言語に育てていき
たいと考えています。もし、お手軽に開発するためのプログラミング言語をお
探しでしたら、ぜひ SQeeL をお試しください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■お知らせ・・・
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
＜ご意見・ご感想をお寄せください＞
メルマガに関するご意見・ご感想をお送りください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
昨年の今頃、近所に捨てられていた子猫を拾って飼う事になりました。仕事で
疲れていても、玄関を開けるときちんと座って「ミャ〜オ！」と可愛い声で出
迎えてくれていたんです。ところが、先週、いつものように玄関を開けると、
「ガァ〜オ！」と・・・ん？？？
それ以来ずっとドスの効いた声で出迎えてくれるんですが。。。。
猫も変声期ってあるんですかぁ？？？ by KA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
登録・解除は以下のURLで行うことができます。
http://www.insight-tec.com/html/mailmagazine/d_mail.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜海の見える開発室 −解き放てmind！−＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright(c) 2003, Insight Technology, Inc., All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Insight Technology, Inc
Japanese | English
製品・サービスに関するお問い合わせは