株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
＼_〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜_／
^^＼_ 2003.07.15 _／^^
^^^^＼_ 海の見える開発室 −解き放てmind！− _／^^^^
^^^^^^＼_ Vol.002 _／^^^^^^
^^^^^^^^＼_〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜_／^^^^^^^^
┏━━━━━━━◆ ！めるまが読者だけへの特典！ ◆━━━━━━━┓
┃ ┃
●─*─*─*─*─ 現場で使えるOracle診断テクニック ─*─*─*─*─●
┃ ┃
┃ 読者の方に２０％割引！ ┃
┃ この機会をお見逃しなく！！ ┃
┃ http://www.insight-tec.com/html/seminar/oratech.html ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
≪目次≫
■ディベロッパーX 〜開発者たちの挑戦〜
◆無意味なシステム・リソースの追加投資を避ける
■実録 −開発日記− oＯ○
■お知らせ・・・ ∂
■編集者より ＿＿＿ΠΠ＿
〜Ω〜〜〜Ω〜〜〜〜〜〜〜〜〜〜〜〜〜＼≡◎≡≡／〜〜
〜〜~ ~ ~ ~ ~ ~〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■ディベロッパーX 〜開発者たちの挑戦〜
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
◆無意味なシステム・リソースの追加投資を避ける
前号では「システムを正確に評価する」ことについて調べてみました。そこで
は「次にやるべき行動計画を明確にする」ということの重要性を知り、開発現
場での論議とPI(Performance Insight)に組み込んでいく過程を知りました。
今回は、ユーザーが泣き寝入りしなくてもいいツールとしてのもう1つの目的、
無意味なシステム・リソースの追加投資を避けるためにはどうしたらいいのか？
について探りを入れてみようと思います。経費削減とか言われながらも、
パフォーマンスを向上させなくちゃいけない！だからハードウェアを増設！！
そして思いっきり高額の見積書に「仕方ないなぁ・・・」と呟きながら・・・
稟議書に印を押しちゃってる方に、どのようなメッセージを伝えているのか？
その仕組みを探ってみようと思います。「ん？？？」って疑問を持つことがで
きるようなネタを見つけてきまーす！！！
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■どっぷり開発生活
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
以下は、システムをどのように分析し、どのようなメッセージを出力すべきな
のか？という開発段階での論議をまとめた備忘録です。
◆総合評価−課題2
◇データベースバッファのヒット率に関するコメント◇
┏─────────────────────────────────┓
┃総合評価欄 ┃
┗─────────────────────────────────┛
------------->> データベースバッファのチューニング <<-----------------
データベースバッファのヒット率が低いのは全件読み込みSQL文が多いためで
す。現状の状況だとデータベース・バッファのサイズ（nnMB）は小さすぎます
┏─────────────────────────────────┓
┃課題 ┃
┗─────────────────────────────────┛
データベースバッファのヒット率は指標としてしか使ってはいけない。ヒット
率が増えてもパフォーマンスが却って悪くなる場合があるからだ。このことは
当社発行のメルマガ「おら！ オラ！ Oracle - どっぷり検証生活」の
「Oracle 9i 関する検証」(Vol.097〜Vol.110)でも検証済みである。
http://www.insight-tec.com/html/mailmagazine/mail_back/mail_back_index.html
ヒット率だけを見てデータベースバッファを増やし、「ヒット率が数パーセン
ト上がった！」などというチューニングは、根拠に乏しい頼りない結論だ。
例えば、データベースバッファが100MBでヒット率80%であれば、200MBにする
と90%になり、300MBにすると100%になる（実際には100%はあり得ないから95%
としても）、、、などというような計算は実際には成り立たない。
ここで特に重要なのは、データベースバッファが300MBでも90%のヒット率を
キープできるにもかかわらず、1GBを獲得してヒット率が相変わらず90%強と
いうような設定を行っている場合だ。このようなケースの場合は、2GBにデー
タベースバッファを増やせば、ヒット率は95%になるかもしれない。けれど実
際の体感レスポンスは全く変わらない。
これが実際に物理メモリを増設してからやったとしたら、不幸の上乗せと言っ
てもいいかもしれない。また、2GBでヒット率をキープしてカットオーバーさ
せたようなシステムでは、データの増加と共に徐々にレスポンスダウンの悲劇
に見舞われる！なんてことが往々にして起きやすいということだ。
┏─────────────────────────────────┓
┃Oracleコンサルティング心得 ┃
┗─────────────────────────────────┛
そもそも大したセッション数（ユーザー数）もなく、メインのアクセステーブ
ルの数が20個程度のシステムで、GB単位のデータベースバッファでヒット率を
キープしているシステムが有れば「あやしい」と心得よ！
ただし、DSS系でないことが前提。
⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃
〔KA〕ところで、ディスクキャッシュがたくさんあれば問題ないって聞いたこ
とがあるんですけど本当ですか？
〔DV〕「そのような質問はよくお客さんからも出るんだけど、ギガバイトキャッ
シュの効果はすごく大きいよ。だけど今回の問題はもう少し違った意味
合いなんだ。データベースバッファを大きくすればディスクI/O はなく
なるけれど、足りないとディスクI/O になってしまうからデータベース
バッファのヒット率が下がる。だからGB単位のデータベースバッファを
設定して、足りない分をGB単位のディスクキャッシュで補う！！
でも、これって何となく矛盾を感じない？」
〔KA〕ん〜、データベースバッファのヒット率を上げるために、GB単位のデー
タベースバッファにするんだよね。そしたらヒット率は上がる筈だから、
ディスクキャッシュになんか頼らなくてもいいってことなの？？？
〔DV〕「1日に数回しか実行されない処理だったり、データウェアハウスなんて
呼ばれる処理の場合だったら仕方ないけど、実行回数の多いSQL文が多く
のデータアクセス(ディスクI/O)を必要としてる！っていうのが見つかっ
たら、そっちに目を向けるべきなんだ。」
〔KA〕確かに！ディスクキャッシュがたくさんついてると値段も高いだろうし、
これから買うのなら無駄な投資になりますモンね！
〔DV〕「いやいやそれは誤解！」
〔KA〕あぅ・・・そんな単純じゃないのね。。。
〔DV〕「ディスクキャッシュの効果はもっとトータルに考えなくちゃいけない
んだよ。大量のディスクI/O が発生する処理やユーザー数が多くて大量
トランザクションを処理しなくちゃいけないシステムだったら、ディス
クI/O は常に発生するだろ。そんな時は、データベースバッファなんて
「見せかけ」のキャッシュ域で満ちて、常に溢れ出してる！って状態な
んだよ。そしたらディスクI/O 速度が高い方が断然有利でしょ！」
〔KA〕なるほど〜。大量処理にはディスクキャッシュって感じですか？
〔DV〕「それだけじゃなくて、データベースはディスクI/O するから、チュー
ニングをきっちりやったシステムであればあるほど、トータルでディス
クキャッシュのメリットは大きいんだよ。」
〔KA〕そっか！ディスクキャッシュ効果は大きいけど、Oracleチューニングを
すべきところに目をつぶってディスクに頼るって姿勢がだめなのね！
〔DV〕「そんなとこだな。。。」
〔KA〕ということは、Oracleチューニングに必要な情報を提供することが必要
ね！
┏─────────────────────────────────┓
┃総合評価コラム ┃
┗─────────────────────────────────┛
「データベースバッファのヒット率が低いのは全件読み込みSQL文が多いため
です」
このメッセージはとても良い。処置すべきはSQLであって、その時の指標とし
てのみヒット率を取り入れているからだ。
┏─────────────────────────────────┓
┃Oracleチューニング ┃
┗─────────────────────────────────┛
PIではデータベース・バッファの調整はX$BHから行う：万能 X$BH( Buffer Header)
ビュー
select set_ds SET_DS , null POOL_NAME, obj DATAOBJ, count(1) BUFFERS,
lru_flag
,sum(tch) TCH_SUM
,sum(ceil(bitand(flag,2097185)/2097185)) WRITE_BUFFERS
,sum(bitand(flag,524288)/524288) SEQ_READ_BUFFERS
,sum(decode(state,0,1,0)) STATE_0_BUFFERS
,sum(x_to_null) X_TO_NULL_SUM
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
group by set_ds, obj, lru_flag
having count(1) > 1
SET_DS バッファのアドレス
[9i]のみ:cnv1と結合する時に使用
POOL_NAME バッファの種別
[8i]のみ:デフォルト、キープ、リサイクルのカテゴリ分けを行う
DATAOBJ データオブジェクトID
オブジェクトIDとは違うので注意
BUFFERS バッファ上のブロック数
LRU_FLAG LRU_FLAG(8:ホット 8未満:コールド 2:全件検索オブジェクト)
データベースバッファの過不足を言い当てるためのキー
TCH_SUM タッチの合計
これもデータベースバッファの過不足を言い当てる時に利用する
WRITE_BUFFERS 書込みが行われたことのあるブロックの数
SEQ_READ_BUFFERS 全件検索されたことのあるブロック数
STATE_0_BUFFERS 未使用ブロックの数
X_TO_NULL_SUM x_to_nullの合計
RAC環境でのロックダウンを測るためのキー
【注意点1】SET_DS、POOL_NAMEのロギングに関して
[8i]-------------
1つのバッファでバッファのアドレスが重複する為、バッファのアドレス
(SET_DS)を取得していません。変わりに、SET_DSをバッファ名（pool_name
[DEFAULT,KEEP,RECYCLE等]）に変換して取得しています。
[9i]-------------
1つのバッファでバッファのアドレスが重複することはない為、バッファの
アドレス(SET_DS)を取得し、後からバッファ名(POOL_NAME)に変換して取得
しています。
●RAC環境で取得した例●
SET_DS P DATAOBJ BUFFERS LRU_FLAG TCH_SUM WRITE_BUFFERS SEQ_READ_BUFFERS STATE_0_BUFFERS X_TO_NULL_SUM
-------- - ---------- ---------- ---------- ---------- ------------- ---------------- --------------- -------------
5A229F6C 7285 1209 0 2156 0 0 0 0
5A229F6C 7285 2010 8 4396 0 0 0 0
5A229F6C 7286 33 0 51 0 0 0 0
5A229F6C 7286 159 8 631 0 0 0 0
5A229F6C 7287 307 0 47 7 5 300 7
5A229F6C 7292 2 0 2 2 0 0 2
5A229F6C 7292 2 2 2 0 0 0 4
5A229F6C 7293 14 0 14 3 2 0 1
5A229F6C 7293 6 2 6 0 0 0 2
5A229F6C 7293 34 8 425 4 0 0 1
5A229F6C 7294 59 0 53 15 17 28 33
5A229F6C 7294 1288 2 4 0 1284 0 0
5A229F6C 7294 5 8 14 4 0 0 7
5A229F6C 7295 31 0 98 28 0 0 55
5A229F6C 7295 4 2 1 2 0 0 8
5A229F6C 7295 24 8 270 22 0 0 17
5A229F6C 7297 549 0 551 0 0 0 0
5A229F6C 7297 1387 8 1478 4 0 0 0
5A229F6C 7300 6 0 32 5 3 0 17
5A229F6C 7993 2 0 1 1 1 0 0
5A229F6C 7994 2 0 2 1 0 0 0
5A229F6C 7995 3 0 5 3 0 0 0
5A229F6C 7997 3 8 9 0 2 0 0
5A229F6C 7999 7 0 6 5 1 0 0
●バッファサイズ、プール名変換(cnv1)●
select b.bp_id, y.addr, b.bp_name, b.bp_blksz, b.bp_size
from sys.x_$kcbwbpd b, sys.x_$kcbwds y
where y.inst_id = USERENV('Instance')
and cnum_set > 0
and y.set_id >= b.bp_lo_sid
and y.set_id <= b.bp_hi_sid
and b.bp_size > 0
BP_ID ADDR BP_NAME BP_BLKSZ BP_SIZE
---------- -------- -------------------- ---------- ----------
1 88780850 KEEP 2048 7570
3 88780EF8 DEFAULT 2048 15140
7 88781C48 DEFAULT 16384 1013
＜LRU_8_RATE：ホットブロックの割合＞
（以下のSQL文で検索されるX$BHは実際にはスナップショットxprt_bhaを使用）
select set_ds SET_DS , null POOL_NAME, sum(decode(lru_flag,8,1,0)) /
count(1) LRU_8_RATE
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
group by set_ds
having count(1) > 1
＜STATE_0_RATE：FREEブロックの割合＞
select set_ds SET_DS , null POOL_NAME, sum(decode(state,0,1,0)) / count(1)
STATE_0_RATE
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
group by set_ds
having count(1) > 1
＜LRU_2_RATE：追い出し候補ブロックの割合＞
select set_ds SET_DS , null POOL_NAME, sum(decode(lru_flag,2,1,0)) /
count(1) LRU_2_RATE
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
group by set_ds
having count(1) > 1
＜SEQ_READ_RATE：全件検索ブロックの割合＞
select set_ds SET_DS , null POOL_NAME, sum(bitand(flag,524288)/524288) /
count(1) SEQ_READ_RATE
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
group by set_ds
having count(1) > 1
＜TCH_AVG：平均タッチ数＞
select set_ds SET_DS, sum(tch) / count(*) TCH_AVG
from sys.x_$bh
where (ts# > 0 or state =0)
and obj <> 4294967295
and tch > 0
group by set_ds
having count(1) > 1
●言い当てるためのロジック●
(a) 以下の条件に当てはまる場合バッファは余っている：
・lru_8_rate < 0.4 --- lru_flag=8(HOT)の割合が40%を下回っている
・lru_2_rate > 0.1 --- lru_flag=2(追い出し候補)の割合が10%を超えている
・state_0_rate > 0.1 --- state=0(未使用)のバッファの割合が 10%を上回っている
(b) 以下の条件に当てはまる場合バッファは不足している：
・上記aに当てはまらない時間帯であることが前提
・tch_avg < 3 --- 平均TCH数が3を下回っている
LRU_FLAG=8（ホット・ステータス）はバッファ・ビジー状態でなければ発生しない：
バッファが余っているような環境ではバッファからの追い出しが頻繁に発生
しないので、ホットな領域がほとんど発生しない。コールド−＞ホットのス
テータス変更はビジー状態であるからこそ必要な管理なのです。
STATE=0 FREEステータス：
FREEステータスはデータベースの起動直後などに観察できるステータスだが、
全件検索で使用された領域を開放する際にも発生する。バッファ・ビジー状
態であればほとんど一瞬しか存在しないはず。
TCH_AVG ホット領域の平均タッチ数が３以下ということは：
ホットな領域内で効率的な循環が行われない状態です。実際にはホットブ
ロックがコールドな領域に頻繁に追い出されている状況が発生しています。
時間ごとの集計：
データベース・バッファヒット率であれば１時間での合計アクティビティか
ら計算するのであまり気を遣う必要もないのだが、X$BHは瞬間的なバッファ
の状態のスナップショットであるためメッセージを出す場合は標準偏差内の
平均とします。
＜9iの場合＞
MSG_a:以下の時間帯でdb_BP_BLKSZ_cache_sizeは余っています。
（MEMORY_BUSY=TRUEの場合は重要度を上げる）
Keyword=db buffer
MEMORY_BUSY=TRUEの場合:
MSG_a2:メモリ節約のためdb_BP_BLKSZ_cache_sizeを縮小してください
->メモリ不足によるページングが発生しているサイトであれば無駄な
データベースバッファは節約のため切り離すように勧めることが最重要！
取得した時間ごとのHIT_RATIOの50%が90%を下回っている場合：
MSG_a3:データベースバッファ・ヒット率が90%を下回っているのは全
件検索オブジェクトが存在するためです。
MSG_b:以下の時間帯でdb_BP_BLKSZ_cache_sizeは不足しています。
Keyword=db buffer
SEQ_READ_RATE > 30, 20, 10
MSG_b2:全件検索オブジェクトがdb_BP_BLKSZ_cache_sizeの
SEQ_READ_RATE%を占めています
上記のメッセージが全時間の50%を超えている場合；
MSG_b3:現状の状況だとdb_BP_BLKSZ_cache_sizeのサイズ（nnMB）は
小さすぎます
＜8iの場合＞
MSG_a:以下の時間帯でデータベースバッファは余っています。
（MEMORY_BUSY=TRUEの場合は重要度を上げる）
Keyword=db buffer, db_buffer hit rate
MEMORY_BUSY=TRUEの場合:
MSG_a2:メモリ節約のためデータベースバッファを縮小してください
->メモリ不足によるページングが発生しているサイトであれば無駄な
データベースバッファは節約のため切り離すように勧めることが最重要！
取得した時間ごとのHIT_RATIOの50%が90%を下回っている場合：
MSG_a3:データベースバッファ・ヒット率が90%を下回っているのは全
件検索オブジェクトが存在するためです。
MSG_b:以下の時間帯でデータベースバッファは不足しています。
Keyword=db buffer
SEQ_READ_RATE > 30, 20, 10
MSG_b2:全件検索オブジェクトがデータベースバッファの
SEQ_READ_RATE%を占めています
上記のメッセージが全時間の50%を超えている場合；
MSG_b3:現状の状況だとデータベース・バッファのサイズ（nnMB）は
小さすぎます
上記のメッセージはデータベースバッファが「時間ごとに」足りているか？
不足しているか？を説明するものである。従って、これらの相反するメッセー
ジ両方が別々の時間で出る場合がある。
この過不足を言い当てる指標は、ヒット率のように0〜100%を基準としたもの
ではないため、チャート化することが難しいのでメッセージの下に時間を出す。
●Keepバッファプールについて●
Keepプールはアクティビティが少ないのでX$BHで評価する必要はない。ヒット
率の指標だけで十分評価できる。
AVG_KEEP_HIT_RATE<90
MSG:Keep Buffer Poolの平均ヒット率が90%を下回っています。
[9iの場合] db_keep_cache_sizeを増やしてください。
[8iの場合] buffer_pool_keepを増やしてください。
[KEEP_HIT_RATE time chart]
┏─────────────────────────────────┓
┃PI Knowledge Center ─ コンテンツ ─ ┃
┗─────────────────────────────────┛
●データベースバッファ●
＜KnowledgeCenter:keyword=db_buffer＞
データベースバッファ関係の設定はOracle9iで変更されています:
＜Oracle9iのinit.ora＞
db_block_size 2048
db_keep_cache_size 16777216
db_recycle_cache_size 0
db_2k_cache_size 0
db_4k_cache_size 0
db_8k_cache_size 0
db_16k_cache_size 16777216
db_32k_cache_size 0
db_cache_size 33554432
＜Oracle8iのinit.ora＞
db_block_size 2048
db_block_buffers
＜KnowledgeCenter:keyword=db_buffer hit rate＞
データベースバッファのヒット率が低くても「データベースバッファは余って
います」と出てくる場合があります。
それは、Oracle8i以降のデータベースバッファの管理機構の仕組みによりHot
ブロックがデータベースバッファ上に十分維持されているからです。ヒット率
を下げている要因は頻繁に発生する全件検索が原因です。全件検索オブジェク
トは少々データベースバッファを増やしてもパフォーマンス改善には影響しな
いためこのようなメッセージになります。
全件検索を行うSQL文を改善できない場合はディスク読み取りスピードを改善
させるストライピングやキャッシュディスクを検討しデータベースバッファを
使用しないパラレルクエリーを検討すべきです。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■実録 −開発日記− 〔by 鈴木 壽人〕
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
監視として、PIでは新分野となる、セキュリティに関する項目を盛り込んでい
きます。
セキュリティツールというと「防御」するという概念が一般的ですが、PIでは
まず「セキュリティ監視」というものを行っていきたいと思います。
セキュリティの世界は「イタチごっこ」であるとよく言われますが、最新のセ
キュリティツールが入っている環境が必ずしも堅固であるとは言えません。
なぜならば、セキュリティの強さは人の「意識」がもっとも大きく影響するか
らです。
高度な認証システムを設備したビルでも中の人が不用意に招き入れれば、まっ
たくの意味をなさないし、認証システムの設定を誤れば、当然、十分に機能し
ません。
サーバのセキュリティーも同様に、単にセキュリティ・ポリシーのルール付け
や最新のファイアーウォールよりも、それを運用する人の意識の持ち方こそが
重要であり、それがあってこそ、初めて最新のセキュリティツールも有効に機
能します。PIで行っていくセキュリティ監視の第一の焦点はそこにあります。
秒進分歩と言われるこの業界で、セキュリティのチェック項目も日々変化して
おりますが、基本的なチェック項目というのは実際ほとんど変わっていません。
例えばログイン情報はセキュリティを意識する上で、かかすことの出来ない項
目ですが、情報の取得の仕方によってはログインの履歴情報にととまらず、非
常に有力な情報となります。
俗に言うハッキングもそのほとんどがログインなくしては行われません。
ログインを試行した痕跡や、時間外にログインしているユーザーもわかります。
また、外部からのハッキングが日々困難になっている現在、内部ハッキングや
その予兆を警告としてみてとることも可能です。
・夜中に日中業務のオペレーションユーザーが入っている
・管理者ユーザーになろうとして何度も失敗しているユーザーがいる
・9時間でログアウトするはずのユーザーが15時間入っている
・・・等々
ログイン情報はあくまでも一例ですが、予期しないポート（サービス）の変更
情報であったり、重要なファイルの改ざん検知であったり、基本的な情報だか
らこそ、見逃しがちで、基本だからこそ、重要である項目がいくつもあります。
PIのセキュリティ監視は有用で役に立つ情報という位置付けだけでなく、運用
者または管理者が日々の業務に追われて、つい忘れがちなセキュリティ意識に
Alertを出してあげられるそんなツールを提供したいと考えています。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■お知らせ・・・
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
＜セミナーのご案内＞
めるまが読者の皆様に２０％割引でのご優待サービスを行います。
また、めるまが読者からのご紹介であれば、同様に２０％割引の対象とさせ
て頂きます。この機会をお見逃しなく！
お申し込み方法は、以下URLの[セミナー申し込み]フォームから
http://www.insight-tec.com/html/seminar/oratech.html
ご紹介の場合は「ご質問やお問い合わせがありましたら．．． 」欄に、
「紹介」と記載し、ご紹介者のメールアドレスを記載の上お申し込みくだ
さい。記載がない場合は割引対象とはなりませんのでご注意ください。
＜ご意見・ご感想をお寄せください＞
メルマガに関するご意見・ご感想をお送りください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
夏はやっぱり江ノ島にいかなくちゃっ！ってことで、友達と一緒に江ノ島に遊
びに行ってきたんです。まだ夏休み前なのに人がた〜くさんいてちょっとびっ
くり！！！浜崎あゆみの海の家があるんだって〜とか言いながら、どこにある
のかも見つけられず、美味しいご飯を食べただけで帰ってきちゃいました！！
あっ、展望台は立派になってました！！！ 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
製品・サービスに関するお問い合わせは