英語でOracle!

以下のようなこと、Oracleですぐに書けますか？

・ｎ～ｍ件目のデータを検索
・大文字、小文字に関係なくデータを検索
・viewの定義内容を確認
・テーブル変更に影響する依存オブジェクトの確認
・一定間隔の処理件数でCommit発行
・partition毎の件数確認

他にも知っていて便利な情報が詰め込まれた一冊です。
「Oracleはこう動いている。―Oracle徹底検証」の著者である
榎本茂男氏が２冊目の著書になります。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　Oracleのテクニック、伝授します。
　そろそろ初心者を卒業したプログラマーの方、
　SQLを考えるのに苦労したことはありませんか？
　思わず“なるほど”と唸る、ちょっとしたSQLのテクニックお教えします。

　「Oracle技術研究所 知って得するSQL」
　楽天ブックス
　http://tinyurl.com/ygcrjd
　amazon
　http://tinyurl.com/ya2v2a

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語で Oracle！ #043 2007/01/16
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今までの目次です。
http://imoment.blogspot.com/2006/11/toctable-of-contents.html

おはようございます。お世話になっている翻訳の先生から
英語とはまったく関係ない面白いフラッシュを教えていただきました。
音声込みで息抜きに聞いてみてください。
注意：笑い転げる可能性があるので、仕事以外の時間に見てください。
「中村屋」
http://blog.livedoor.jp/kemui/nakamura.html

今回はindexのrebuildに関するRechard Footeさんの資料をご紹介します。
indexのrebuildに関する情報を発表したOracleの有識者を
名指しで批判するという刺激的な内容になっていますが、
注目はその裏づけの説明や証明です。rebuildの是非が主題ではありますが、
その説明の為にindexの内部構造を詳しく説明されています。
ついでにtree dumpやindexのblock dumpの取得方法や内容の解釈もわかります。

少し昔の資料なので、ご存知の方もいらっしゃるかもしれません。

（ここは噂です）
この資料で批判されていることを知ったDon Burlesonさんは
footeさんのオフィスに電話し、今すぐ、footeさんが黙るか、
そうでないと深刻な訴訟問題になると伝えたとか
（ここまで）

でもFooteさんの意見はTom Kyteさん、Jonathan LewisさんなどのDBA Guruを
はじめとして多くの人々に支持されました。

そもそも古い説を取り上げて名指しで批判というのは
Footeさんの若気の至りでしょうが、それを差し引いても一読の価値はあります。

その後のDon Burlesonさんの意見については別の機会に取り上げたいと思います。
亀田選手とランダエタ選手まではいきませんが、ちょっとしたバトルでした。

※今回はちょっと引用したい部分が長いので、いくつかの発行に分けて
お送りしたいと思います。

※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

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Objectives

- Dispel many myths associated with Oracle B-Tree Indexes
- Explain how to investigate index internals
- Explain and prove how Oracle B-Tree Indexes work
- Explain when index rebuilds might be appropriate

◆ Classic Oracle Index Myths

- Oracle B-tree indexes can become “unbalanced” over time
and need to be rebuilt
- Deleted space in an index is “deadwood” and over time
requires the index to be rebuilt
- If an index reaches “x” number of levels, it becomes
inefficient and requires the index to be rebuilt
- If an index has a poor clustering factor, the index needs to be rebuilt
- To improve performance, indexes need to be regularly rebuilt

◆ Index Fundamentals

- Oracle’s B-Tree index is always balanced. Always.
- Index entries must always be ordered.
- An update consists of a delete and an insert
- Each leaf block has pointers to next/previous blocks
- Each leaf block contains the index entry with corresponding rowid
- Index scans use ‘sequential’, single block reads
(with exception of Fast Full Index Scan)

◆ Clustering Factor

- A vital statistic used by the CBO
- Determines the relative order of the table in relation to the index
- CF value corresponds to likely physical I/0s or blocks visited
during a full index scan (note same block could be visited many times)
- If the same block is read consecutively then Oracle
assumes only the 1 physical I/0 is necessary
- The better the CF, the more efficient the access via the
corresponding index as less physical I/Os are likely
- “Good” CF generally has value closer to blocks in table
- “Bad” CF generally has a value closer to rows in table

◆ How To Improve The CF

- As some of the “expert” quotes suggest, rebuild index if
CP is poor is common advice
- Unfortunately, as neither table nor index order changes,
the net effect is “disappointing”
- To improve the CF, it’s the table that must be rebuilt (and reordered)
- If table has multiple indexes, careful consideration
needs to be given by which index to order table
- Pre-fetch index reads improves poor CF performance
- Rebuilding an index simply because it has a CF over a
certain threshold is futile and a silly myth

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
なっているところがあります。 ()書きは後続修飾節の修飾対象です。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Objectives
目的

- Dispel many myths associated with Oracle B-Tree Indexes
OracleのB-Tree indexに関する多くの間違った教えを払拭します。

- Explain how to investigate index internals
どのようにindexの内部構造を調べるかを説明します。

- Explain and prove how Oracle B-Tree Indexes work
OracleのB-Tree indexがどのように働くかを説明し、証明します。

- Explain when index rebuilds might be appropriate
index rebuildがどのような場合に適切であるかを説明します。


◆ Classic Oracle Index Myths
よく知られた誤った教え

- Oracle B-tree indexes can become “unbalanced” over time
and need to be rebuilt
OracleのB-tree indexは時間が経つとアンバランスになり、
rebuildが必要になる

- Deleted space in an index is “deadwood” and over time
requires the index to be rebuilt
Deleteが繰り返されると無駄な領域が増えるのでやがてrebuildが必要になる。

- If an index reaches “x” number of levels, it becomes
inefficient and requires the index to be rebuilt
indexのレベルがあるレベルに達すると、非効率になるのでrebuildが必要

- If an index has a poor clustering factor, the index needs to be rebuilt
CFが悪くなるとrebuildが必要になる

- To improve performance, indexes need to be regularly rebuilt
パフォーマンス向上の為にindexのrebuildが定期的に必要

◆ Index Fundamentals
indexの基礎

- Oracle’s B-Tree index is always balanced. Always.
b-tree indexは常にバランスが取れている

- Index entries must always be ordered.
indexエントリは常に順序が整っている必要がある

- An update consists of a delete and an insert
更新は削除と挿入で構成される

- Each leaf block has pointers to next/previous blocks
各リーフブロックは前後のリーフへのポインタを持っている

- Each leaf block contains the index entry with corresponding rowid
各リーフブロックはインデックスエントリと対応するrowidが格納されている

- Index scans use ‘sequential’, single block reads
indexスキャンはシーケンシャルシングルブロックリードを利用する

(with exception of Fast Full Index Scan)
（FFSを除く）


◆ Clustering Factor
クラスタリングファクタ

- A vital statistic used by the CBO
CBOに利用される重要な統計

- Determines the relative order of the table in relation to the index
indexの並び順と対応するデータの並び順を決定づけている

- CF value corresponds to likely physical I/0s or blocks visited
during a full index scan
CFはindex full scan中に行われた物理I/Oまたはアクセスブロックブロックの数

(note same block could be visited many times)
（同じブロックに何度もアクセスする可能性がある）

- If the same block is read consecutively then Oracle
assumes only the 1 physical I/0 is necessary
もし、連続で同じブロックにアクセスする場合、
Oracleは１回の物理I/Oしか発生しないと想定する。

- The better the CF, the more efficient the access via the
corresponding index as less physical I/Os are likely
物理I/Oが少くなくなるので、CFの値が良くなればなるほど、
対応したindex経由のアクセスは効率が良くなる

- “Good” CF generally has value closer to blocks in table
良いCFは通常テーブルデータのブロック数に近い値である。

- “Bad” CF generally has a value closer to rows in table
悪いCFは通常テーブルデータの行数に近い値である。

◆ How To Improve The CF
CFの値を向上させるには。。。

- As some of the “expert” quotes suggest, rebuild index if
CP is poor is common advice
experts達の中には、CFが悪い時はrebuildが必要だと言う人がいます。

- Unfortunately, as neither table nor index order changes,
the net effect is “disappointing”
しかし残念ながら、テーブルの並び順もindexの並び順も変わる訳ではないので、
がっかりした結果が待っています。

- To improve the CF, it’s the table that must be rebuilt (and reordered)
CF値を向上させるにはtableの並び順を変える必要があります。

- If table has multiple indexes, careful consideration
needs to be given by which index to order table
もし、複数のindexを持つテーブルなら、この決断は慎重になるべきです。

- Pre-fetch index reads improves poor CF performance
pre-fetch indexは悪いCF値を改善します。

- Rebuilding an index simply because it has a CF over a
certain threshold is futile and a silly myth
固定のCF値を閾値としてrebuildを行うというアドバイスは役立たずの腐った教えです。


知っていて損はないSQLです。
http://tinyurl.com/ya2v2a


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

- Dispel many myths associated with Oracle B-Tree Indexes

dispel:（恐れ、疑い、誤った考え）を一掃する。
通常、ある情報が間違っていたり不必要なことを証明する際に利用します。
myth:神話、作り話、俗説、（広く信じられている）誤った考え
(発音：mith)
associated with:関係する
B-Tree:balanced treeの略（oracle解説参照）


- Explain when index rebuilds might be appropriate

rebuild:再作成、再構築（oracle解説参照）

◆ Classic Classic Oracle Index Myths

classic:標準的な、古典的な、有名な


- Deleted space in an index is “deadwood” and over time
requires the index to be rebuilt

deadwood:枯れ枝、役に立たないもの、足手まとい、蛇足
over time:時間の経過
deleted space:index内における実際のテーブルデータは
削除されている未使用領域

- If an index reaches “x” number of levels, it becomes
inefficient and requires the index to be rebuilt

reach:達する、到着する。
inefficient:効率が悪い、スキルの無い、充分に効果を発揮することができない
level:b-tree用語（oracle解説のb-tree参照）


- If an index has a poor clustering factor, the index needs to be rebuilt

clustering factor:(oracle解説参照)


- Each leaf block has pointers to next/previous blocks

leaf block:b-tree用語(oracle解説のb-tree参照)


(with exception of Fast Full Index Scan)

fast full index scan:(oracle解説参照)


- A vital statistic used by the CBO

vital:（生命など）何かを存在を維持する為の、非常に重要な要素


- Determines the relative order of the table in relation to the index

relative:関連のある
in relation to:～に関連した


- CF value corresponds to likely physical I/0s or blocks visited
during a full index scan

likey:起こりそうな、予期される


- If the same block is read consecutively then Oracle
assumes only the 1 physical I/0 is necessary

consecutively:連続して
assume:仮定する


- The better the CF, the more efficient the access via the
corresponding index as less physical I/Os are likely

the 比較級1,the 比較級2:比較級1であればあるほど、比較級2になる
via:経由して
correspond:対応する、一致する


- “Good” CF generally has value closer to blocks in table

generally:通常、たいてい、ほとんど


- As some of the “expert” quotes suggest, rebuild index if
CP is poor is common advice

quote:引用する、もしくは引用そのもの


- Unfortunately, as neither table nor index order changes,
the net effect is “disappointing”

unfortunattely:残念ながら
disappoint:がっかりさせる（がっかりした場合はi'm disappointed with）


- Rebuilding an index simply because it has a CF over a
certain threshold is futile and a silly myth

threshold:敷居、閾値
futile:何の効果も無い
silly:ばかげた、知性の欠けた

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★

※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
珍しく普通の問題です。in,at,onのイメージを整理しましょう。
穴埋め問題です。

1)There's a coffee shop ( ) the end of the block.

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019067A182e1
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019067A2f23a
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019067A36098
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019067Cf7b2


2)Where are you? ( ) a taxi.

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019068A19d8c
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019068A2e1e0
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019068A3f476
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019068Cc7c5

3)There was a big chair ( ) the middle of the room.

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019069A1ba6a
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019069A2ea31
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019069A33ff1
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019069Ce5fb

4)Who is she ( ) this photograph?

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019070A10398
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019070A23b9d
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019070A329c4
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019070C5f93

5)Ross is ( ) the hostpital.

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019071A14897
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019071A2b27f
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019071A3e222
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019071C130d

6)I came school ( ) the bus.

◆in
┗ http://clickenquete.com/a/a.php?M0002066Q0019072A11c49
◆at
┗ http://clickenquete.com/a/a.php?M0002066Q0019072A20475
◆on
┗ http://clickenquete.com/a/a.php?M0002066Q0019072A38ab3
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019072Ca29c


締切：2007年01月23日18時00分
協力：クリックアンケート http://clickenquete.com/


こたえは次回に発表します。


■ 前回のこたえ

☆２週間に一度って英語で伝えたいときは？

◆biweekly
◆bimonthly
◆every two weeks
◆every next next week
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0018917Cf54a

厳密にはbiweekly,every two weeksどちらも
２週間に一度という意味を持っています。
ただし、biweeklyは不可思議なことに１週間に２回という
意味も併せ持つので誤解されないようにご注意下さい。

この１週間に２回という意味はbritish系の意味で、
日本で言う「自分」が関東と関西で逆の意味を持つのに
少しパターンが似ている気がしました。

この誤解はnativeどうしでも起こりがちなので、
１週間に２回：semi-weekly
２週間に１回：every two weeks
というように違う言い方をするのがお勧めです。

ちなみにevery other weekも２週間に１回の意味を
持っているのですが、個人的にはevery two weeksの方が
すんなり伝わると思っています。

bimonthlyは月に２度か、２ヶ月に１度という意味があります。

every next next weekは誰もクリックしていない通り、
恐らく伝わらないでしょう。

もちろん２日（２ヶ月、２年）に１回にも応用できます。


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
用語を順々に説明いたしますので分かっている用語については
どんどん飛ばしてください

－・ b-tree ・－・－・－・－・－・－・－・－・－・－・－・－・－・

balanced tree の略で、逆から見た木のように
最上にroot（根）があり、rootからbranch（枝）が派生し、
最終的にleafにたどり着く構造
rootからleafまでの距離がどのleafに対しても同一である特徴がある
このことからbalanced treeと呼ばれる。
この特徴を満たす為に、b-treeは以下のように成長します。

１つのleafに入りきれない値が追加された場合leafが２分割され、
そのleafの親となるbranchにもその情報が追加される。
branchにも情報が入りきらなくなった場合、branchも２分割するが、
最終的にrootに情報が収まりきらなくなった場合、rootの場合だけ
特別に３分割され、新しいルートとその子となるbranchが２つ
生成される。これが発生した際にrootからleafまでの距離が
１つ伸びることになる。
この距離をlevel(blevel)と呼んだり、heightと呼んだりします。

これらのb-treeに関するOracleの動きは次回以降で詳しく説明されます。
（先にご覧になりたい方は引用資料のP26～P34をご覧ください）

root
│
├branch1┬leaf11
│ └leaf12
└branch2┬leaf21
├leaf22
└leaf23

上記の例なら、levelは3となり、heighは2となります。

－・ b-tree ここまで・－・－・－・－・－・－・－・－・－・－・－・


－・ rebuild ・－・－・－・－・－・－・－・－・－・－・－・－・－・

indexの再作成をrebuildと呼びます。

例：alter index i_xxx rebuild online;
例：alter index i_xxx rebuild partition i_xxx_p1 online;

Richard FooteさんはOracleのB-tree indexは次回以降に述べる
一部の例外を除いてrebuildの必要は無いと主張しています。
（先にご覧になりたい方は引用資料のP79以降をご覧ください）

あくまでも目安としての再作成の指標は、
levelが5以上だったり、削除エリアの割合が30,40%を越えた場合
などが考えられますが、無条件にこの条件に当てはめて
rebuildしようとするとFooteさんやTom Kyteさん、もちろん
Don Burlesonさんにも怒られてしまいます。
対象となるテーブルの特性をよ～～～く考えてそのテーブルに
あったrebuildを検討しましょう。

－・ rebuild ここまで・－・－・－・－・－・－・－・－・－・－・－・

－・ clustering factor －・－・－・－・－・－・－・－・－・－・－・

単語が長いので以降CFで説明します。
これは絵で見ると理解が早いです。
引用資料のP22に悪いCF、P23に良いCFが図解されています。
これをテキストで示してみると少しシンプルすぎて苦しいですが、
＜良いCF＞
root
│
├branch1┬leaf11-datablock1
│　　　　└leaf12-datablock1
└branch2┬leaf21-datablock2
　　　　　├leaf22-datablock2
　　　　　└leaf23-datablock2
＜悪いCF＞
root
│
├branch1┬leaf11-datablock2
│　　　　└leaf12-datablock1
└branch2┬leaf21-datablock2
　　　　　├leaf22-datablock1
　　　　　└leaf23-datablock2
という感じです。

datablockは実際のテーブルデータが存在するブロック位置です。
＜良い＞例だと、full scan時に実際のテーブルデータのブロックにアクセスする
数は２ですが、＜悪い＞例だと、indexの順番と異なってアベコベになっている
ので、実際のテーブルデータのブロックにアクセスする数は５となります。
この数値はCBOのオプティマイザがindexを使ったrange scanが有効かどうかを
判断する重要な要素になり、この数値が悪いためにindexが使用されずに
tableのfull scanが発生してしまうケースがあります。

CFの数値がテーブルデータのブロック数の総計に近い程、
index full scanの効率が上がり、
行数に近くなる程index full scanの効率が最悪になります。

－・ clustering factor ここまで－・－・－・－・－・－・－・－・－・

－・ fast full index scan ・－・－・－・－・－・－・－・－・－・－・

特定の条件を満たした場合、本来テーブルのfull scanが行われるべきところを
indexをfull scanするだけで済ませてしまうことができます。

条件は以下の通り

１．索引となっている項目の最低１つにnot null制約がある
２．問合せに必要な全ての列が索引に含まれている
３．CBOで動作しているか、select /*+ index_ffs */のヒントを
使用していること

ちゃんと対象のテーブルのanalyze(or dbms_stats)がされていて、
プライマリキーを定義しているのであれば、
select count(*) from xxx_table;
などしてもテーブルのfull scanがされずに
indexのfull scanで事足りてしまいます。
使用された場合は実行計画にfast full scanが表示され、
v$sysstatやv$sesstatの「index fast full scans (xxx) 」の値が増加します。
(xxxはfull,direct read,rowid rangesのいずれか)

－・ fast full index scan ここまで・－・－・－・－・－・－・－・－・


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。

冒頭でご紹介した中村屋是非聞いてみてください。
ちなみは私はサイゼリヤでお腹が破裂しそうでした。

もしこのindexのメンテナンスに関する件で皆さんのご意見・疑問があれば、
ご連絡いただければと思います。

それではまた。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。

簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274

バックナンバー兼ブログはこちら
http://imoment.blogspot.com/

登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm

Posted by yaksa on 20070115 at 11:55 午後 | Permalink