株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
＼_〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜_／
^^＼_ 2003.07.03 _／^^
^^^^＼_ 海の見える開発室 −解き放てmind！− _／^^^^
^^^^^^＼_ Vol.001 _／^^^^^^
^^^^^^^^＼_〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜_／^^^^^^^^
はじめまして。このたびは「海の見える開発室 −解き放てmind！−」にご登
録いただきありがとうございます。
ソフトウェアの開発現場というと、納期に追われ殺伐とした雰囲気の中、余裕
を無くした人たちが必死にディスプレイとにらめっこしている、そんな風景を
想像していました。しかし、ここでは海を見ることができます。そして、自由
にアイディアを出し合い、新たな閃きがあり、それを製品に取り入れ、夢のよ
うな話が次々と実現していく。苦悩が笑顔に変わる瞬間の目の輝き、それはと
ても情熱的であり魅力的です。そんな空気を少しでもお伝えできたらと思って
います。どうぞよろしくお願いします。
≪目次≫
■ディベロッパーX 〜開発者たちの挑戦〜
◆システムを正確に評価する
■どっぷり開発生活
■実録 −開発日記−
■お知らせ・・・
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■ディベロッパーX 〜開発者たちの挑戦〜
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
◆システムを正確に評価する
前回、PI(Performance Insight)は、専門知識を持たないユーザーがSIやSEに
泣き寝入りしなくてもいいようなツールとして誕生したことを知りました。
(初回にして既にバックナンバーなんですけど、サンプル誌として掲載してお
きました内容の続きとなっています。サンプル誌をご覧になられていない方は、
http://www.insight-tec.com/html/mailmagazine/d_mail.html へどうか足を
お運びくださいませ！)
ユーザーが泣き寝入りしなくてもいいようなツールを作るって言っても、どこ
から手を付けていったらいいのかしら・・・
でもその前に、投下資金がパフォーマンス向上に見合っているか、それすら気
が付いていないユーザーも多いと思うんだけど。営業部にいた頃、『システム
開発やシステム運用には多額の費用がかかるというのは常識！』なんて思って
いる人が多かった気がするんだよね。
ユーザーが騙されないシステム運用と、無意味なシステム・リソースの追加投
資を避けるために、専門知識を持つSIやSEがしてることを考えると・・・。
システムの状況を正確に評価し、ユーザーに分かり易く伝え、ユーザーが今何
をすべきか・これからどのようにしていったらいいのか、というアドバイスを
すると思うんだけど、そんな役割をパッケージソフトができるのかなぁ？
そもそも、システムを正確に評価するっていったいどんなこと？？？
「だからいつも『瞬間的なシステムの状況から全てを見渡したつもりになっ
てはいけない！』と言ってるんです。」
きゃ〜！！！今回は何やら難しい話しになりそうな予感が・・・
「システムの評価は『誰がやっても同じような結果がでる？』と思っている人
も多いと思うけど、次にやるべき行動計画を明確にしないとまずいことになる。
もし、行動計画を誤ると効果の上がらない徒労が続くばかりではなく、無駄な
投資を生んでしまうからね。」
うむ。。。この行動計画の誤りというのが、結局はユーザーが泣き寝入りする
原因に繋がっていくのね。次にやるべき行動計画を明確にすれば、ユーザーは
「今何をすべきか」「これからどうしていけばいいか」ということが分かるし。
でも、次にやるべき行動計画を明確するって具体的にどんなことなの？
「PI(Perfroamcne Insight)は、システムを常時監視し、そのロギングデータを
分析して評価レポートを出力しているんだけど、次期バージョンではその評価
レポートを大幅に変えようとしてるんだ。特に『総合評価コラム』というもの
を現在開発中なんだけど、総合評価コラムで一番大切なことは：
・トッププライオリティが明確
・処置すべき内容が明確
・今後の展開が明確
ってことなんだよね。」
確かに、システムの総合評価としてこれらのことが明確になれば、次にやるべ
き行動計画も明確になるのかな。システムを正確に評価するっていう一要素で
はあるような気がする。。。なるほど、パッケージソフトでもできそうな気が
してきた。。。でも、どうやって総合評価コラムを作るの？
「システム診断の『総合評価』欄で記述されたコラムを使って説明しよう。」
うむ！これは開発現場にどっぷり浸からないと・・・行きますっ！！！
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■どっぷり開発生活
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
以下は、システム診断の「総合評価欄」で記述されたコラムを使い、PI5.2の
レポートに盛り込まれるやりとりの備忘録です。
◆総合評価−課題1
◇問題があるお客様でありがちなコメント◇
┏─────────────────────────────────┓
┃総合評価欄 ┃
┗─────────────────────────────────┛
-------->> SQL文チューニング、ディスクI/O待ちの解消、
データベース・バッファ・サイズの見直しが必要です <<--------
CPUの使用率が非常に高く、ディスクのI/O待ちが起きている状態です。
しかし、以下の問題が根本的な原因の可能性があります。
1.負荷の高いSQL文
2.ディスクI/Oの負荷が一本のディスクに集中
3.データベース・バッファのサイズが小さすぎる
1.負荷の高いSQLに関して：いくつかの負荷の高いSQL文が存在し、これらが原
因で、ディスクI/Oの発生 → ディスクI/O待ちの発生 → レスポンスの低下
が発生しています。
2.ディスクI/Oの負荷が一本のディスクに集中している点に関して：ディスク
へのI/O負荷が一本のディスクに集中しています。そのために、ディスクI/O
待ちが発生しています。I/Oを分散させることにより、パフォーマンスの向
上が期待できます。
3.データベース・バッファのサイズに関して："ディスクI/Oの多いSQL"によっ
てデータベース・バッファのヒット率が低くなっていますが、現状のデータ
ベース・バッファのサイズ（187MB）は、小さいです。SQL文のチューニング
とデータベース・バッファのサイズ変更を行う事によってヒット率の向上が
期待出来ます。
┏─────────────────────────────────┓
┃課題 ┃
┗─────────────────────────────────┛
これは「明確化」という点でなってない総評だと思う。SQL文がまずいのか、
ディスクI/Oが問題なのか、CPUが限界なのか、データベースバッファなのか？
このようなケースは「Aが悪いからB,Cが連動している。B,Cも問題だがAを直す
と問題は変わってくる」というパターンで、Aが直すと
”様子が一変します！！！”というところが強調されてなければならない。
1.物理I/Oの多いSQL文という、全てを根底からひっくり返すボトルネックが
存在している。
2.SQL文が問題である場合はその性質を述べる：
a.インデックス検索を検討すべきSQL文か？（場合によっては実行計画を変
更すべき）
b.全件検索が前提のSQL文か？
・パラレルクエリへの移行が提案できるか？
・Recycleバッファプールを使うように提案できるか？
c.Range検索で負荷が高い、あるいはカーディナリティーの低いインデック
スを使っていないか？
上記a,b,cに関してはPI52-Action Tools（開発コード：SCAT）から答えが得
られる。
3.ディスクI/Oに関して以下のように提案すべき：
「ディスクI/Oはボトルネックですが、SQLチューニングを先に検討すべきで
す」とすればハード資源としてのボトルネックはディスクI/Oであるという
ことが明確化できる。
4.データベースバッファが小さい、
ここでもディスクと同様に以下のように報告するべき：
「データベースバッファのヒット率が低いのは全件読み込みSQL文が多いためです」
「現状の状況だとデータベース・バッファのサイズ（187MB）は小さすぎます」
総評は：Aが悪いからB,Cに連動しているということを印象づけられる文章にする！
┏─────────────────────────────────┓
┃PI5.2詳細メッセージ ┃
┗─────────────────────────────────┛
1.SQLリストの後に以下のコメントで該当するものを出力：
MSG_a:インデックス検索を検討すべき、あるいは実行計画を検討すべきSQL文
がnn件検出されました。
[keyword=Full Table Scan]
MSG_b:パラレルクエリに移行すべき、あるいはRecycleバッファプールを使用
すべきSQL文がnn件検出されました。
[keyword=Parallel Query, buffer_pool_recycle]
MSG_c:レンジ検索負荷が高い、あるいはカーディナリティーの低いインデッ
クスを使用したSQL文がnn件検出されました。
[keyword=Cardinarity, Range Scan]
2.上記1が発生した時間帯で、Full Scan (sec/hour) > Normal Scan (sec/hour)
and Full Scan (sec/hour) > 1000
MSG:ディスクI/Oはボトルネックですが、SQLチューニングを先に検討すべき
です。
3.上記1が発生した時間帯で、DB_BUFFER_HITR（？） < 90
MSG:データベースバッファのヒット率が低いのは全件読み込みSQL文が多い
ためです。
MSG:現状の状況だとデータベース・バッファのサイズ（nnMB）は小さすぎま
す。
┏─────────────────────────────────┓
┃SCATの機能 ┃
┗─────────────────────────────────┛
SCATとは、負荷の高いSQL文をカテゴライズし「処置すべき手順」をナビゲー
トするためのAction Toolsの開発コード名です。
1.負荷の高いSQL文は以下の3つにカテゴライズされる。
a.インデックス検索を行えば効率化ができるのに全件検索をしている
b.インデックス検索を行っても効率化ができない
c.インデックス検索を行っているが効率が悪い
2.カテゴライズされたSQL分を評価レポート内で言い当てるSCATの仕様とは：
2-1.Heavyであるという条件：
条件1=DISK_READS/EXEC >= 1000
条件2=条件1を満たさない場合は、BUFFER_GETS/EXEC>=1000
2-2.条件1,2を満たす場合、次の条件で3つにカテゴライズされる。
a.インデックス検索を行えば効率化ができるのに全件検索をしている
⇒ROWS_PROCESSED/DISK_READS<=1.5（条件1）or
ROWS_PROCESSED/BUFFER_GETS<=1.5（条件2）
(全体の中で1.5%が対象であれば、インデックスを作成するとすっ
きりするってことね(ﾟ○ﾟ)!
b.インデックス検索を行っても効率化ができない
⇒上記a以外で対象オブジェクトのインデックスがバッファ上から検
出されないもの。
(インデックスが作られてないってことを確認するのかな(ﾟゝﾟ)?
c.インデックス検索を行っているが効率が悪い
⇒a,b以外
3.SQL Minderでカテゴリをtab化したときの命名アイデア：
a.FTS(Full Table Scan) index not found ⇒適切なインデックスがありません
b.FTS(Full Table Scan) ⇒インデックス検索は不可能
c.IIS(Ineficient Index Scanの非一般用語)⇒非効率インデックス検索
┏─────────────────────────────────┓
┃PI Knowledge Center ─ コンテンツ ─ ┃
┗─────────────────────────────────┛
●フルテーブルスキャン●
＜KnowledgeCenter:keyword=Index Scan, Full Table Scan＞
Primary Keyが使われないケース：
主キーが複合キーからなるケースは少なくありません。下記のケースでは複合
キーを所属部署などの組織データから作成しています：
SQL> CREATE TABLE 売上計画 (部 VARCHAR2(10), 課 VARCHAR2(10), 担当者
VARCHAR2(20), 月 VARCHAR2(2), 売上計画金額 NUMBER);
SQL> ALTER TABLE 売上計画 ADD PRIMARY KEY(部,課,担当者,月);
->ある担当者の5月の計画を検索をしてみます：
SQL> SELECT 担当者,月,売上計画金額 from 売上計画 WHERE 担当者='私' and
月='05';
このSELECT文はWHERE句に”部,課”がないのでインデックスは使用されません。
担当者(営業マン)が500人いて、1年間のデータ件数は6000件になる場合、1件
を持ってくるだけなのに毎回6000件のを検索しなければなりません。また、製
品・顧客などの分類も入るとその何倍にもなるかもしれません。
−＞制約をDROPして作り直す：
SQL> SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = '売上計画';
INDEX_NAME
------------------------------
SYS_C00906
SQL> ALTER TABLE 売上計画 DROP CONSTRAINT SYS_C00906;
SQL> ALTER TABLE 売上計画 ADD PRIMARY KEY(担当者,月,部,課);
●カーディナリティ●
＜KnowledgeCenter:keyword=Cardinarity, Range Scan＞
カーディナリティとは何か？日本語にすると"集合の要素の数・基数"というこ
とになります。実際の意味合いは「どれだけのキーの種類があるか」「キーの
偏りはないか」といったところです。キーの種類が多い場合を"カーディナリ
ティが高い"、キーの種類が少ない場合を"カーディナリティが低い"と表現し
ます。
->社員マスターの社員コードはどっち？
社員コードは普通、全て一意性があるので"カーディナリティが高い"です。
対して”性別”は男と女だけなので"カーディナリティは低い"です。
ではちょっと捻って、上の社員マスターを持つ企業は日本の企業です。しかも
日本だけにあります。このとき、社員マスターにある国籍のカーディナリティ
はどっち？この場合、国はたくさんあります。しかし、国籍はほとんど日本に
なると思います。このようなケースでは種類がたくさんあっても、偏りがひど
いので"カーディナリティが低い"です。
SQL文:DELETE FROM TABLE_A WHERE COL1=10 AND COL2='A' AND COL3<>'Y' AND
COL4='NO0121'
アクセスパス:(0)DELETE STATEMENT (Cost=4)
(1)-- TABLE_A から削除(DELETE)
(2)----UNIQUE索引 TABLE_A_IDX(複数行)を使用(RANGE SCAN)
(Cost=4 Card=1 Bytes=81 )
INDEX:TABLE_A_IDX ON TABLE_A(COL1,COL2,COL3,COL4)
見た感じはユニークインデックスを使用して削除処理を行っているので非常に
いいSQLが作成できた様に見えます。でもこれだけの情報で最適なSQLができた
ことにはならないのです。実際のところこのケースでは数行を削除するのに700
ブロックも読み込んでいたのです。では何がいけないのでしょう？
SQL文のパフォーマンスを向上させるために一番重要なことは、できるだけ少
ないI/Oで求める行(レコード)を取得することです。
上記のSQL文は実際COL3を <> で条件指定しています。つまりインデックス
TABLE_A_IDEXはCOL2まででRANGE SCANを行っています。
また、SQLを見ていただければ判ると思いますが COL3='Y' が多分 'Y' か 'N'
がCOL3には設定されていそうです。COL4は番号のように見えますので種類は多
そうです。このインデックスはCOL4によってカーディナリティが高まっている
はずです。だからCOL4までを正しく条件設定すれば有効なインデックスとなり
ます。(COL1からCOL3は=条件で設定しなければ意味の無い状態です)
●パラレルクエリ●
＜KnowledgeCenter:keyword=PARALLEL QUERY, PARALLEL_MIN_SERVERS,
PARALLEL_MAX_SERVERS＞
PARALLEL QUERYのチューニングはシステムリソースのバランスから、
・CPU を使い切っているようなら並列度を下げ、余裕があるようなら並列度を
上げる
・少なくとも並列度と同じ台数のDISK にデータがストライピングされている
事が望ましい
・問合わせサーバ毎にSORT_AREA_SIZE 、HASH_AREA_SIZE で設定したメモリを
使用する事に注意
重要なことは「パラレルクエリはデータベースバッファを使わない！」
すなわち他のOLTP処理のアクティビティを下げないという二次的効果がある
チューニングです。
パラレルクエリの並列度の設定は以下の順番で決められる、
・最優先 SQL 文でのヒント句での並列度
‐SELECT /*+ FULL(emp) PARALLEL(emp,5)*/ 〜
・2番目 表定義でのパラレル句での並列度
‐CREATE TABLE 〜PARALLEL (DEGREE3 )
・3番目 データベースのデフォルト並列度
パラレルクエリ関連の重要パラメータ
PARALLEL_MIN_SERVERS … インスタンス起動時に作成する問合せサーバ数
PARALLEL_MAX_SERVERS … システムで使用できる最大の問合せサーバ数
目安：
PARALLEL_MAX_SERVERS=(使用する最大の並列度)×(問合せの同時実行数)×2
●パーティション・バッファ●
＜KnowledgeCenter:keyword=Partition Buffer, Keep, Recycle, Buffer_Pool,
buffer_pool_recycle, buffer_pool_keep＞
パーティション・バッファの設定：
Oracle7では、ひとつのバッファ・キャッシュですべてのオブジェクトをキャッ
シュしていました。このため、大規模なセグメントをランダム・アクセスした
ときに、他のセグメントのデータを含むバッファがキャッシュから除去(Aged out)
される可能性が高くなっていました。この時、除去されたバッファが本当にア
クセス頻度の低いものであれば問題ないのですが、これが「比較的頻繁にアク
セスされるが、大規模セグメントの読み込みにおけるバッファ・フラッシュを
免れうるほど頻繁にはアクセスされない」セグメントのデータであれば、パ
フォーマンスを悪化させる可能性が高くなります。
Oracle8では、複数のバッファ・キャッシュを定義できるようになりました。
従来のバッファの他に、大規模セグメントの再利用専用のバッファと、
ウォーム・セグメント専用のバッファを設定しておくことで、このウォーム・
バッファの問題を回避することが可能になります。
再利用を目的としたバッファは「RECYCLEバッファ」、ウォーム・セグメント
保持を目的としたバッファは「KEEPバッファ」、従来のキャッシュ・バッファ
は「DEFAULTバッファ」と呼ばれます。ただし、これらは定義を行うときの名
称が異なるだけで、バッファ・キャッシュのアルゴリズムは同じものが適用さ
れます。つまり単に「バッファ・キャッシュを3つに分割して使い分ける」機
能に過ぎないので、ユーザー側で適切に使い分けていく必要があります。
パーティション・バッファは、"buffer_pool_recycle"と"buffer_pool_keep"
のふたつのパラメータで設定します。
例えば次のように設定されているバッファ・キャッシュがあるとしましょう。
db_block_buffers = 200
db_block_lru_latches = 4
パーティション・バッファを設定する場合は次のように、"buffer_pool_recycle"
と"buffer_pool_keep"で、バッファ・キャッシュのバッファ数とラッチ・セッ
ト数を分け合うことになります。
buffer_pool_recycle = (buffers:100,lru_latches:2)
buffer_pool_keep = (buffers:50,lru_latches:1)
残りのバッファ数とラッチ・セット数は、DEFAULTバッファに割り当てられます。
パーティション・バッファの設定：
CREATE TABLE table_name (col_1 number, col_2 number)
PARTITION BY RANGE (col_1)
(PARTITION A VALUES LESS THAN(10) STORAGE (INITIAL 10k BUFFER_POOLRECYCLE),
PARTITION B VALUES LESS THAN(20) STORAGE (BUFFER_POOL KEEP));
CREATE INDEX index_name ... STORAGE (buffer_pool_clause)
CREATE CLUSTER cluster_name...STORAGE (buffer_pool_clause)
ALTER TABLE table_name ... STORAGE (buffer_pool_clause)
ALTER INDEX index_name ... STORAGE (buffer_pool_clause)
ALTER CLUSTER cluster_name ... STORAGE (buffer_pool_clause)
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■実録 −開発日記− 〔by 内田加代子〕
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
私は、設定処理などの一部分を担当していますが、今はアラート設定・しきい
値設定という機能を担当しています。
どんな機能かというと、
PIのデータベース監視項目の1つに、あるSQL文がメモリを指定KB以上消費した
場合に警告を出す、というものがあります。
例えば、この監視項目の「指定KB」や、異常があった場合の警告を通知する
メールアドレスなどを時間別に設定できる機能です。
これらの機能によって、
■データベースを管理している人が会社に居ない時間には携帯電話のメールア
ドレスに警告を通知する。（→効率よく管理ができる。）
■土日はアクセスが少ないのでいつもより多くメモリを消費しても大丈夫なの
で150KB消費したら警告を通知するようにする。（→本当に重要な問題が発
生した時に対処ができる。）
などができるので、無駄な作業を減らすことにつながります。
なので、「もっと効率よく働きたい」、「楽したい」と思っている人に是非
使ってみてほしい！思いつつ開発しています。
また、製品を開発する上でいかに使い易い製品にしていけるかというのが課題
ですが、使い易く！というのは、とっても難しくて奥が深いと日々感じます。
簡単に使えて、それでいてとっても仕事の役に立つ！そんな製品を目指したい
です。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■お知らせ
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
＜ご意見・ご感想をお寄せください＞
メルマガに関するご意見・ご感想・ご要望等をお送りください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
創刊号はいかがでしたか？是非、ご意見、ご感想をお寄せください。
また、読者の方からの質問も受け付けています。このメルマガが読者の方との
語らいの場に、そして自由に参加していけるフレキシブルなものになっていく
といいなぁと思っています。このメルマガの存在を知人の方にもお知らせ頂け
たら嬉しいです！それでは次回をお楽しみに！！！ 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
製品・サービスに関するお問い合わせは