＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語で Oracle！ #036 2007/02/05
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今までの目次です。
http://imoment.blogspot.com/2006/11/toctable-of-contents.htmlおはようございます。
嫁様に頑張ってもらって、光回線が開通しました。
夜中の速度計測で16mbps。。。ピーク時もこの速度なら変えた甲斐がありました。
引き続きRichard FooteさんのIndex Rebuildに関するプレゼン資料を
ご紹介します。（第３回）
前回までの発行はこちら
1.導入、B-tree Indexの基礎、Clustering Factor、Fast Full Scanの説明
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html2.Indexブロック分割、PCTFREE、PCTUSED、FREELISTの説明
http://imoment.blogspot.com/2007/01/oracle-b-tree-index_22.htmlそして今回は削除済領域の再利用に対する見解が主なテーマです。
遅延ブロッククリーンアウト機能の内部動作も説明していきます。
※今回含めて残りあと３回続きますが、もうしばらくお付き合い下さい。
※index用語に慣れていない方は、先にoracle解説のコーナー（前号までも含む）で
知らない用語について確認されるといいかもしれません。
■ askTomでのindex rebuildに関するdiscussion
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112※今回は引用PDFを紹介している適切なサイトが無いので、
その資料について触れているaskTomのdiscussionをリンクとして
ご紹介します。
■ 引用PDFファイル
http://www.actoug.org.au/Downloads/oracle_index_internals.pdf＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Deleted Index Deleted Index Space Is Reused
- The previous example clearly illustrates that any insert to
a leaf block removes all deleted entries
- In randomly inserted indexes, deleted space is not an issue as it will
eventually be reused
- But wait, there’s more …
◆ Deleted Deleted Entries: Delayed Block Cleanout
- Long running transactions may result in dirty blocks being flushed
from memory before a commit;
- When subsequently accessed, delayed block cleanout is performed
- Delayed block cleanout results in all corresponding deleted entries
being cleaned out
◆ Conclusion: Conclusion: Deleted Space
- Deleted space is cleaned out by subsequent writes
- Deleted space is cleaned out by delayed block cleanout
- Fully emptied blocks are placed on freelist and recycled
(although remain in the index structure)
- Suggestions that deleted space can never be reused are wrong and yet
another silly myth
◆ Index Fragmentation
Although deleted index space is generally reusable,
there can be wasted space:
. Bug with 90-10 split algorithm in 9i (previously discussed)
. Too high PCTFREE
. Permanent table shrinkage
. Monotonically increasing index values and deletions
. Deletes or Updates that dramatically reduce occurrence of specific
index values
. Large volume of identical index entries
◆ Large Volume Large Volume Of Identical Values
There are a number of issues with this behaviour:
1. The only leaf blocks that can be inserted into are:
. L3 for values of AAA
. L7 for values of BBB or CCC
i.e. the last leaf blocks containing a specific value
2. All other leaf blocks are “isolated” in that they cannot be considered
by subsequent inserts
(assuming only current values)
3. The isolated blocks are empty due to 50-50 block splits
◆ Index Rebuilds
. As discussed, most indexes are efficient at allocating and reusing space
. Randomly inserted indexes operate at average 25% free space
. Monotonically increasing indexes operate at close to 0% free space
. Deleted space is generally reusable
. Only in specific scenarios could unused space be expected to be higher
and remain unusable
. So when may index rebuilds be necessary ?
. An index rebuild should only be considered under the following
general guideline:
“The benefits of rebuilding the index are greater than the overall
costs of performing such a rebuild”
. Another way to look at this:
“If there are no measurable performance benefits of performing
an index rebuild, why bother ?”
. Another important point:
“If after a rebuild, the index soon reverts back to it’s previous
state, again why bother ?”
. The basic problem with index rebuilds improving performance is
that generally, the ratio of index blocks visited to table blocks
visited is relatively small.
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
なっているところがあります。 ()書きは後続修飾節の修飾対象です。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Deleted Index Space Is Reused
削除された領域は再利用される
- The previous example clearly illustrates that any insert to
a leaf block removes all deleted entries
前述の例では、どのようなリーフブロックへのinsertでも削除済エントリを
消去することを明確に証明しています。
(前述の例とは引用資料のP35-37の内容です)
- In randomly inserted indexes, deleted space is not an issue as it will
eventually be reused
不規則にinsertされたindexでは、削除済領域は最終的に再利用されるので
問題になりません。
- But wait, there’s more …
しかし待ってください。まだあります。
◆ Deleted Entries: Delayed Block Cleanout
削除済エントリと遅延ブロッククリーンアウト
- Long running transactions may result in dirty blocks being flushed
from memory before a commit;
長時間実行されるトランザクションはダーティブロック（更新済のブロック）が
コミット前にmemoryからフラッシュされてしまう可能性を持っています。
- When subsequently accessed, delayed block cleanout is performed
その後のアクセスがあったとき、遅延ブロッククリーンアウトが発生します。
- Delayed block cleanout results in all corresponding deleted entries
being cleaned out
遅延ブロッククリーンアウトは全ての対応する削除済エントリを一掃します。
◆ Conclusion: Deleted Space
削除済領域の結論
- Deleted space is cleaned out by subsequent writes
削除済領域は後続の書込みによって消去されます。
- Deleted space is cleaned out by delayed block cleanout
削除済領域は遅延ブロッククリーンアウトによって消去されます。
- Fully emptied blocks are placed on freelist and recycled
(although remain in the index structure)
完全な空ブロックはfree listに移動して、再利用されます。
（しかしindex構造内には残ります）
- Suggestions that deleted space can never be reused are wrong and yet
another silly myth
削除済領域が再利用されないという提案は間違っており、
もうひとつのバカな通説です。
◆ Index Fragmentation
indexのフラグメンテーション
Although deleted index space is generally reusable,
there can be wasted space:
削除されたindex領域は通常再利用されますが、
無駄な領域である可能性も残っています。
. Bug with 90-10 split algorithm in 9i (previously discussed)
(以前討論された)9iの90-10分割アルゴリズムのバグ
. Too high PCTFREE
あまりにも高いPCTFREE
. Permanent table shrinkage
永続テーブルの収縮
. Monotonically increasing index values and deletions
単調に増加するindex値および削除
. Deletes or Updates that dramatically reduce occurrence of specific
index values
特定のindex値を激減させるdeleteまたはupdateの発生
. Large volume of identical index entries
大規模な同一値のindexエントリ
◆ Large Volume Large Volume Of Identical Values
大規模な同一値のindexエントリ
※P51の図解ベースにしたP52の解説の引用です
There are a number of issues with this behaviour:
このふるまいには沢山の問題があります。
1. The only leaf blocks that can be inserted into are:
insertされうるのは以下のブロックのみです。
. L3 for values of AAA
AAA用のリーフ3
. L7 for values of BBB or CCC
BBBとCCC用のリーフ7
i.e. the last leaf blocks containing a specific value
すなわち特定の値の最後のブロックです。
2. All other leaf blocks are “isolated” in that they cannot be considered
by subsequent inserts
(assuming only current values)
この場合、他の全てのブロックが孤立します。後続のinsertでは考慮されません。
（現在の例示した値だけで仮定した場合）
3. The isolated blocks are empty due to 50-50 block splits
50-50ブロック分割のために孤立したブロックは半分が空です。
◆ Index Rebuilds
. As discussed, most indexes are efficient at allocating and reusing space
議論したように、ほとんどのindexは領域の割り当てや再利用において効率的です。
. Randomly inserted indexes operate at average 25% free space
不規則なinsertが起こるindexでは平均25%の空き領域で機能します。
. Monotonically increasing indexes operate at close to 0% free space
単調に値が増加するindexではほとんど0%の空き領域で機能します。
. Deleted space is generally reusable
削除された領域は通常再利用されます
. Only in specific scenarios could unused space be expected to be higher
and remain unusable
特定のケースに限って、未使用領域が多く残ることが考えられます
. So when may index rebuilds be necessary ?
というわけで、いつrebuildは必要になるのでしょうか？
. An index rebuild should only be considered under the following
general guideline:
index rebuildは以下のガイドラインによってのみ考慮されます
“The benefits of rebuilding the index are greater than the overall
costs of performing such a rebuild”
”index rebuildはrebuildを行う手間やコストを上回る場合において
意味があります”
. Another way to look at this:
こういった見方もあります。
“If there are no measurable performance benefits of performing
an index rebuild, why bother ?”
”もし計測可能なindex rebuildによるパフォーマンスの利益が無いなら、
何故わざわざ(rebuild)するのでしょうか”
. Another important point:
もうひとつ重要なポイントです
“If after a rebuild, the index soon reverts back to it’s previous
state, again why bother ?”
”もしindex rebuildをした後に、すぐに元の状態に戻るとしたら、
繰り返しますが、何故わざわざ(rebuild)するのでしょうか”
. The basic problem with index rebuilds improving performance is
that generally, the ratio of index blocks visited to table blocks
visited is relatively small.
index rebuildによるパフォーマンス向上に関する基本的な問題は、
通常tableブロックのアクセス数に対するindexブロックのアクセス数の
割合は比較的小さいことです。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
- The previous example clearly illustrates that any insert to
a leaf block removes all deleted entries
illustrate:(主に本や雑誌に)描く、
(より明確に図解や例示によって)意味や真実を示す
- In randomly inserted indexes, deleted space is not an issue as it will
eventually be reused
issue:（雑誌など）発行する、課題、問題
eventually:ついに、最終的に
◆ Deleted Entries: Delayed Block Cleanout
Delayed Block Cleanout:遅延ブロッククリーンアウトと呼ばれるOracleの仕様です。
(Oracle解説参照)
- Long running transactions may result in dirty blocks being flushed
from memory before a commit;
dirty blocks:メモリ上に存在する更新済み未COMMITデータ
(Oracle解説のDelayed Block Cleanout参照)
flush:（メモリの内容を）一掃してDISKに反映する。通常はトイレを流すという意味で使用する。
- When subsequently accessed, delayed block cleanout is performed
subsequently:後続して
◆ Index Fragmentation
indexのフラグメンテーション
Fragmentation:元々大きな１つの何かが細かくバラバラになってしまった状態。
fragmentは小さくなった破片、または、塊を砕く行為そのもの。
diskのfragmentationはデータの削除、追加の繰り返しにより、
連続した空き領域がなくなり、ファイルを細かい断片にして小さな空き領域に
格納すること、またはそれが発生した状態を指す。（断片化）
ここではindexのエントリの削除によって、細かい未使用領域が沢山存在した
状態を指している。
Although deleted index space is generally reusable, there can be wasted space:
generally:一般的に、総じて、通常
. Bug with 90-10 split algorithm in 9i (previously discussed)
Bug with 90-10: 9.2で90-10のsplitアルゴリズムにバグがあり、
50-50になってしまっていたというもの。
. Permanent table shrinkage
Permanent:永遠の、永続の
Oracleでは一時テーブルと区別する為に、
永続テーブルとしてPermanentを使用する。
. Deletes or Updates that dramatically reduce occurrence of specific
index values
dramatically:劇的に
occurrence:発生
specific:特定の
. Large volume of identical index entries
identical:同一の
There are a number of issues with this behaviour:
behaviour:振舞い
i.e. the last leaf blocks containing a specific value
i.e.:要約、すなわち、（ラテン語のid estの略）
2. All other leaf blocks are “isolated” in that they cannot be considered
by subsequent inserts
(assuming only current values)
isolated:孤立した、隔離された
assuming ～:～と仮定した場合
◆ Index Rebuilds
. As discussed, most indexes are efficient at allocating and reusing space
efficient:効率的
. Randomly inserted indexes operate at average 25% free space
randomly:不規則に
operate:動作する、機能する
“If there are no measurable performance benefits of performing
an index rebuild, why bother ?”
mesurable:計測可能な
bother:邪魔する、わざわざする
“If after a rebuild, the index soon reverts back to it’s previous
state, again why bother ?”
revert:元に戻る
. The basic problem with index rebuilds improving performance is
that generally, the ratio of index blocks visited to table blocks
visited is relatively small.
relatively:比較的
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★
※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
☆どちらが理想的でしょうか。
◆to study English.
┗
http://clickenquete.com/a/a.php?M0002066Q0019367A1a2bf◆to learn English.
┗
http://clickenquete.com/a/a.php?M0002066Q0019367A245c4○結果を見る
┗
http://clickenquete.com/a/r.php?Q0019367C983d締切：2007年02月10日23時00分
協力：クリックアンケート
http://clickenquete.com/こたえは次回に発表します。
■ 前回のこたえ
☆現在完了形は英語でどう言いますか
◆present perfect
◆current complete
◆present finish
◆current perfect
○結果を見る
┗
http://clickenquete.com/a/r.php?Q0019172Ccd12こたえはpresent perfectです。
その他の英語学習用語です。
時制:tense
現在進行形:continuous
現在:present
過去形:past tense
未来形:future tense
現在完了:present perfect
過去完了:past perfect
主語:subject
述語:predicate
動詞:verb
名詞:noun
前置詞:preposition
形容詞:adjective
副詞:adverb
代名詞:pronoun
不定詞:infinitive
受動態:passive
冠詞:article
発音:pronounce(動詞)/pronunciation(名詞)
母音:vowel
子音:consonant
音節:syllable
アクセント:accent/stress
語順:word order
単数:singular
複数:plural
多少でも英語がわかるのであれば、
英語で書かれた文法テキストでの勉強を強くお勧めします。
日本のそれよりもずっとわかりやすいと思います。
以下は私が使った文法テキストです。小学校低学年向けの内容なので文章も難しくありません。
◆ Amazon.co.jp：Basic Grammar in Use With Answers
http://tinyurl.com/38mpmxBasic版で物足りなければ、Intermediate版(高学年)、Advanced版(中学生程度)もあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今回の用語説明は"Delayed Block Cleanout"のみです。
既にご存知の方は後続の解説にお進みください。
－・ Delayed Block Cleanout ・－・－・－・－・－・－・－・－・－・－・－・
日本語では「遅延ブロッククリーンアウト」と呼ばれる動作について、
削除時の内部動作から理解しましょう。
01.delete発行
02.delete対象のブロックをDISKからバッファキャッシュに読み込む
03.redoログバッファにdelete情報を記録
04.undoエントリをundoセグメントヘッダのトランザクションエントリに作成
05.delete行のコピーを空いているundoブロックに書き込む
06.delete行をバッファキャッシュ上の該当ブロック内から消し去る
07.該当ブロックをdirtyブロックとしてマークし、delete前のデータが存在する
undoブロックの宛先を記録
(dirtyブロック:メモリ上に存在する更新済みの未COMMITデータ)
08.commit発行
09.SCN(System Change Number)の生成
10.undoセグメントヘッダのトランザクションエントリに該当するundoエントリが
commit済であることを記録(SCNを記録)
11.LGWRがlog bufferの該当トランザクションに関連するredoデータを
flush(redoログファイルに格納)する。
12.もし該当のデータブロックがバッファキャッシュにまだ残っていた場合、
そのブロックヘッダにSCNを記録する。これをfast commitを呼びます。
13.項番12.に該当せず、既にバッファキャッシュからDISKに追い出され、
dirtyブロックのままDISKに格納されてしまっていた場合、
commit時点ではそのdirtyブロックそのままでほっとかれます。
その後、dirtyブロックにアクセスした後続プロセスがdirtyブロック（未COMMIT）
という情報を信じてundoセグメントヘッダのトランザクションエントリを参照し、
「なんだ既にCOMMIT済みじゃん！」ってことになって、undoセグメントヘッダ
トランザクションエントリ上のSCNを取得し、dirtyブロックのブロックヘッダに
「やれやれ。。。何で俺がやんなきゃならんの？」という感じで記録してあげます。
この項番13.の動作が「遅延ブロッククリーンアウト」です！
これはcommitの性能を高めるために、dirtyブロックの存在するDISKへの
アクセスを後回した「日本の国債」のような問題先送りシステムです。
そのツケは後からアクセスしたプロセスが背負います。
最悪の場合、大量の行削除後に別の処理で同じテーブルにフルスキャンを
かけた場合、フルスキャン処理はとんでもないとばっちりを食う可能性が
あるということになります。
※ちなみにLGWRプロセスのlog buffer flush動作は上記項番11.を含めて以下のケースが
あります。
A.commit発行時
B.3秒に1回
C.log bufferの3分の1が使用された場合
D.DBWnプロセスが修正済みのバッファをDISKに書き込む時
A.の場合にflushするのはcommitレコードとそのトランザクションに属するredoデータです。
D.の場合にflushするのはDISKに書き出すバッファに関連するredoデータです。
B.C.のflush内容はわかりません。その時点の全てのredoデータでしょうか。
すみません勉強不足です。(どなたか教えてください)
（flushは主にトイレを流すという意味の動詞として日常では使用されます）
今回の引用文ではこのDelayed Block Cleanoutがindexの削除済み領域をクリアする
要因になることを説明しています。
－・ Delayed Block Cleanout ここまで・－・－・－・－・－・－・－・－・－・
Footeさんの結論としては、indexの削除済みエントリは後続のinsertやupdate時に
使用される予約領域なので、rebuildでクリアするのは馬鹿げていると考えています。
ただし、例外事項としてrebuildが必要なケースもちゃんと説明しています。
・9iの90-10分割アルゴリズムのバグ
・あまりにも高いPCTFREE
・永続テーブルの収縮
・単調に増加するindex値および削除
・特定のindex値を激減させるdeleteまたはupdateの発生
・大規模な同一値のindexエントリ
アンチrebuildのfooteさんが要rebuildのケースと言っているんだから、
考慮する価値がありそうですね。
・9iの90-10分割アルゴリズムのバグ
→これはパッチをあてるかPSRを上げるかしないとでしょうか。
・あまりにも高いPCTFREE
→これはあえてそうしているのだから考慮不要では？設定ミスの可能性？
これを掲載しているfooteさんの意図がわかりませんでした。
・永続テーブルの収縮
・特定のindex値を激減させるdeleteまたはupdateの発生
→大規模な支店の統廃合などでindexが激変した場合などでしょうか。
・単調に増加するindex値および削除
→年月で古いデータから消えていくテーブルなど
・大規模な同一値のindexエントリ
→複数のindexブロックを跨ってしまうほどの同一値エントリだと
連続する同一値ブロックは最後のブロック以外永遠に再利用されることが
原則としてありません。（同一値全て削除されれば再利用可）
上記のケースに当てはまりそうで、かつパフォーマンスクリティカルなindexが
あった場合、rebuildを考慮してみてはいかがでしょうか。
一番のrebuild緊急検討ケースはindexが使用されなくなってしまう程、
無駄な削除済領域が増えてしまったった場合でしょうか。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。
厳しい１月の仕事をなんとか乗り越えることができました。
次は２，３月と怒涛の休日出勤が始まります。
滞らないように頑張りたいと思います。
それではまた。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。
簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274
バックナンバー兼ブログはこちら
http://imoment.blogspot.com/
登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm
