リスクに備えたログ管理の重要性
～DB特権ユーザのモニタリング～
2010年8月25日
株式会社インサイトテクノロジー
エンジニアリング本部
テクノロジーコンサルティング部
松尾 亮
☆おら！オラ！Oracle -どっぷり検証生活-★
Oracle Database
現場で役立つパフォーマンスチューニング
はじめに
Oracle のチューニングポイントは・・・
待機イベントを減らすこと！！
待機イベントとは？
プロセスがCPUを使用していない時間
User I/O、ロック競合、etc
…
バック グラウンド プロセス サーバ プロセスSQL
解析
User I/O
SQL実行
Commit実行
Redo
生成
commit
Redoログ書き込み
CPU Time
待機イベント
ロック待ち
待機イベントの確認方法
ある期間における
インスタンス全体
の待機イベントを確認したい
→ パフォーマンス統計レポート(STATSPACK or AWR)を確認
- STATSPACK ・・・ Oracle 8.1.6 ～
- AWR ・・・ Oracle 10.1.0 ～、EE のみ利用可
※今回のセミナーでは、Standerd Edition でも利用可能な STATSPACK を
例にして説明します。
ある
特定の処理
おける待機イベントを確認したい
STATSPACK 概要
snap#1
定期的にスナップショットをDBに保存 (手動)
ある期間(snapshot間)のデータベース処理の統計情報
をレポートする
snap#2
snap#3
time
#1～#3間のレポート取得
#2～#3間のレポート取得
Standard Edition
で利用可能！
待機イベント統計
SGAのヒット率
セッション統計
etc…
STATSPACK の使用方法
SQL> -- STATSPACK 環境のインストール SQL> conn / as sysdba SQL> @$ORACLE_HOME/rdbms/admin/spcreate.sql → STATSPACK管理ユーザ（perfstat）のパスワード、オブジェクト格納表領域、 一時表領域を指定 SQL> -- スナップショットの取得 SQL> conn perfstat/password SQL> exec statspack.snap(i_snap_level=>7); ※スナップショットレベルについては次ページに記載 SQL> -- レポートの取得 SQL> conn perfstat/password SQL> @$ORACLE_HOME/rdbms/admin/spreport.sql → レポートの開始ID、終了ID、レポートファイル名を指定STATSPACK の取得レベル(9iR2～)
level
収集データ
基本統計 アドバイス情報 SQL統計 SQL詳細 セグメント情報 ラッチ詳細
0
○
○
5
○
○
○
6
○
○
○
○
7
○
○
○
○
○
10
○
○
○
○
○
○
デフォルトは level 5 だが level 7 の情報が役立つことが多い。
Level 10 は情報量が多くスナップショット取得にかかる負荷が高く
なる為、サポートから依頼された場合を除き、基本的に使用しない。
STATSPACK レポートで最も注目すべきポイント
Top 5 待機イベント
が、レポートで最も注目すべきポイント！
Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time
--- --- ---enq: TX - row lock contention 14,858 3,925 264 26.3 gc buffer busy acquire 419,613 2,921 7 19.6 shared server idle wait 453,775 1,978 4 13.3 enq: TX - index contention 32,020 1,757 55 11.8 CPU time 1,312 8.8
Waits ： イベントのために待機した合計回数
Time(s) ： 合計待機時間(秒)
Avg wait(ms) ： 平均待機時間
%Total Call Time ： 全ての待機時間に対する占有比率
STATSPACK での調査ステップ
1. Top 5 待機イベントを確認
2. 上位の待機イベントの意味を確認(マニュアル、KROWN 等)
3. 待機イベントの発生要因に関連するセクションを調査
ex)
・ db file scattered read 、db file sequential read 等
→ SQL Ordered By XXX セクションを確認
→ SQLチューニング？
・ enqueue
→ Enqueue activity、Segments by Row Lock Waits セクションを確認
→ アプリ処理の見直し？
・ buffer busy waits
→ Segments by Buffer Busy Waits セクションを確認
→ 空きリスト競合？逆キー索引、パーティション化？
調査例 ステップ①
待機イベントの上位に以下2つのイベントが出現
db file scattered read
マルチブロック読込(Full Scan、Index Fast Full Scan など)
db file sequential read
単一ブロック読込(Index Scan)
→ SQL の I/O 関連イベントなので、SQL ordered by Elapsed time、
SQL ordered by Gets 等を確認
SQL ordered by Elapsed time for DB:
Elapsed Elap per CPU Old
Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value -- --- --- ---4071.23 50 81.4 52.4 500.71 7530123 1234567890 Module: httpd@WEB001.test.local (TNS V1-V3)
調査例 ステップ②
SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql Snap Snap
Instance DB Name Id Snap Started Level Comment
--- --- --- --- --- ---orcl ---orcl 1 23 Aug 2010 19:00 7
2 23 Aug 2010 19:30 7 3 23 Aug 2010 20:00 7 4 23 Aug 2010 20:30 7 Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ begin_snapに値を入力してください: 1
Begin Snapshot Id specified: 1 end_snapに値を入力してください: 2
End Snapshot Id specified: 2 Specify the Hash Value
~~~~~~~~~~~~~~~~~~~~~~
hash_valueに値を入力してください: 1234567890
Hash Value specified is: 1234567890
調査例 ステップ③
First First Last Plan
Snap Id Snap Time Active Time Hash Value Cost --- --- --- --
---21 16-11月-09 23:00 17-11月-09 11:42 1503752779 130
22 17-11月-09 10:43 17-11月-09 11:11 4265373922 2 ～ 略 ～
---| Operation ---| PHV/Object Name ---| Rows ---| Bytes---| Cost ---| ---|SELECT STATEMENT |--- 1503752779 ----| | | 130 | |FOR UPDATE | | | | | | PARTITION HASH ALL | | 1 | 360 | 130 | | TABLE ACCESS BY LOCAL INDEX RO|TAB1 | 1 | 360 | 130 | | INDEX RANGE SCAN |TAB1_IDX2 | 1 | | 129 | |SELECT STATEMENT |--- 4265373922 ----| | | 2 | |FOR UPDATE | | | | | | PARTITION HASH SINGLE | | 1 | 60 | 2 | | TABLE ACCESS BY LOCAL INDEX RO|TAB1 | 1 | 60 | 2 | | INDEX RANGE SCAN |TAB1_IDX1 | 1 | | 1 |
---SQL レポートを確認
実行計画が
変更された
タイミングが
確認できる
STATSPACK での分析に向かないケース
ある
特定の処理
が遅かった・・・
ある
特定の瞬間
だけ遅かった・・・
スナップショットの取得間隔が30分間で、
- 通常、1秒で終了する処理が1分かかった
- ある1分間の間だけ高負荷状態になった
etc
…
このような場合、STATSPACK でボトルネックを
検出することは困難。
特定のSQL調査(SQLトレースを取得)
特定のSQLの待機イベント情報を含めたSQLトレースを取得
SQL> alter session set events '10046 trace name context forever, level 8'; ～ 問題のSQLを実行 ～
SQL> alter session set events '10046 trace name context off';
実行中のセッションに対してSQLトレースを取得
-- v$session 等の情報からセッションを特定
alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';
select username,program,server,status,sid,serial#,last_logon_time from v$session where username is notnull;
-- 特定した sid、serial# に対して SQLトレースを取得
exec sys.dbms_system.set_ev(&sid, &serial, 10046, 8, ''); exec sys.dbms_system.set_ev(&sid, &serial, 10046, 0, '');
取得したトレースファイルを整形
(初期化パラメータ user_dump_dest or background_dump_dest に出力される)
特定のSQL調査(SQLトレースを確認①)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows --- --- --- ---Parse 2 0.59 0.66 0 656 0 0 Execute 2 0.00 0.00 0 0 0 0 Fetch 2 6.54 48.45 5599 18502 0 1 --- --- --- ---total 6 7.13 49.11 5599 19158 0 1 Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited --- Waited --- ---SQL*Net message to client 4 0.00 0.00
SQL*Net message from client 4 25.87 56.30
row cache lock 2 0.00 0.00 ges message buffer allocation 2776 0.00 0.02 library cache lock 9 0.00 0.00 KJC: Wait for msg sends to complete 5 0.00 0.00 library cache pin 9 0.00 0.00 SQL*Net break/reset to client 2 0.00 0.00 gc cr grant 2-way 4 0.00 0.00 Disk file operations I/O 3 0.00 0.00
特定のSQL調査(SQLトレースを確認②)
～ 略 ～
WAIT #2: nam='db file sequential read' ela= 1211 file#=2 block#=18914 blocks=1 obj#=-1 tim=1282568692243420 WAIT #2: nam='ges message buffer allocation' ela= 8 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692244398 WAIT #2: nam='gc cr disk read' ela= 226 p1=2 p2=18922 p3=4 obj#=-1 tim=1282568692244717
WAIT #2: nam='db file sequential read' ela= 1338 file#=2 block#=18922 blocks=1 obj#=-1 tim=1282568692246167 WAIT #2: nam='ges message buffer allocation' ela= 9 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692247118 WAIT #2: nam='gc cr disk read' ela= 204 p1=2 p2=18930 p3=4 obj#=-1 tim=1282568692247414
WAIT #2: nam='db file sequential read' ela= 6934 file#=2 block#=18930 blocks=1 obj#=-1 tim=1282568692254461 WAIT #2: nam='db file sequential read' ela= 2327 file#=2 block#=18946 blocks=1 obj#=-1 tim=1282568692257806 WAIT #2: nam='db file sequential read' ela= 5903 file#=2 block#=18954 blocks=1 obj#=-1 tim=1282568692264806 WAIT #2: nam='db file sequential read' ela= 507 file#=2 block#=18962 blocks=1 obj#=-1 tim=1282568692266332 WAIT #2: nam='db file sequential read' ela= 2536 file#=2 block#=18970 blocks=1 obj#=-1 tim=1282568692270202 WAIT #2: nam='db file sequential read' ela= 5483 file#=2 block#=18978 blocks=1 obj#=-1 tim=1282568692276741 WAIT #2: nam='db file sequential read' ela= 3660 file#=2 block#=18986 blocks=1 obj#=-1 tim=1282568692281452 WAIT #2: nam='db file sequential read' ela= 496 file#=2 block#=18994 blocks=1 obj#=-1 tim=1282568692282994 WAIT #2: nam='db file sequential read' ela= 499 file#=2 block#=19002 blocks=1 obj#=-1 tim=1282568692284503 WAIT #2: nam='db file sequential read' ela= 504 file#=2 block#=19010 blocks=1 obj#=-1 tim=1282568692286000
～ 略 ～
特定のSQL調査(SQL実行計画を確認)
実行計画の確認は、個人的には
Explain Plan
がお薦め！
※SQL を実行せずにPlanを表示する。実際に実行するとPlanが変わることがあるので注意。
Predicate Information に出力される ID による紐付け、索引使用可否の判断、
該当の where 句の判断が容易。
-- PLAN_TABLE を作成 SQL> @?/rdbms/admin/utlxplan.sql -- SQL を解析SQL> explain plan for 解析したいSQL文; Explained.
-- 解析結果を表示
SQL> select * from table(dbms_xplan.display());
チューニング事例紹介
事例1 ～概要～
•
システム概要
–
モバイルコンテンツ配信システムのDB
–
Oracle11gR1 2node RAC
•
状況
–
テスト期間中、アプリの改修に伴い
索引を新規追加
。
追加後の動作検証（負荷テスト）で遅延
が発生。
（追加前：400処理/秒→追加後：200処理/秒）
–
追加した表は、
複数セッションから insert
（1処理1件）
が
大量に行われる
という特性がある。
•
要望
–
索引を追加した状態で追加前と同等のパフォーマンスに
戻したい。
CPU使用率は減少。（CPUが使えていない）
ロック関連の待機イベントが多発！
事例1 ～状況～
索引追加前
索引追加後
待機イベント
待機イベント
CPU使用率
CPU使用率
事例1 ～状況(STATSPACKでは)～
索引追加後
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time --- ---
---enq: TX - row lock contention 14,858 3,925 264 26.3 gc buffer busy acquire 419,613 2,921 7 19.6
shared server idle wait 453,775 1,978 4 13.3 enq: TX - index contention 32,020 1,757 55 11.8 CPU time 1,312 8.8
---Host CPU (CPUs: 16 Cores: 8 Sockets: 2) ~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU --- --- --- --- --- ---
事例1 ～状況～
索引追加前
索引追加後
追加した索引に関連する表、索引に対する
ロック、buffer busy が多発している！
ロック発生オブジェクト
ロック発生オブジェクト
事例1 ～状況(STATSPACKでは)～
索引追加後
Segments by Row Lock Waits
Row
Subobject Obj. Lock Pct Owner Tablespace Object Name Name Type Waits Total -- -- ---SCOTT TS_INDEX TEST1_PKEY INDEX 10,524 24.8 SCOTT TS_INDEX TEST2_PKEY INDEX 8,422 19.8 SCOTT TS_INDEX TEST3_PKEY INDEX 7,243 17.1 SCOTT TS_INDEX TEST4_IDX1 INDEX 1,420 3.3 SCOTT TS_DATA TEST2_TAB TABLE 336 .8
Segments by Buffer Busy Waits
Buffer
Subobject Obj. Busy Pct Owner Tablespace Object Name Name Type Waits Total -- -- ---SCOTT TS_INDEX TEST1_PKEY INDEX 20,117 31.1 SCOTT TS_INDEX TEST2_PKEY INDEX 18,626 28.7 SCOTT TS_INDEX TEST3_PKEY INDEX 16,787 25.9 SCOTT TS_INDEX TEST3_IDX2 INDEX 3,499 5.4 SCOTT TS_INDEX TEST4_IDX1 INDEX 3,334 5.1
事例1 ～現場の様子～
この時の現場の様子をお届けします・・・
アプリ担当者（以下、アプリ）
「アプリ改修したので、使いそうな索引を追加しました。」
DBA 「分かりました。確認します。
・・・って、めちゃくちゃいっぱいあるじゃないですか！
この索引、全部使うんですか？？」
アプリ 「いやー、ちょっと分からないんですけど、使うかもしれ
ないとこには全部作ってみました。
事例1 ～現場の様子～
DBA 「そ、そうですか・・・
確か、今回索引を追加する表って、どれも insert が
大量に実行されるテーブルですよね？
索引があると insert は遅くなるんですよ。
だから、検索に使われない索引は削除したいですね。」
アプリ 「はー、そうですか・・・」
DBA 「ま、とりあえず負荷テストしてみますか。
そんなに影響出ないかもしれないし。」
事例1 ～現場の様子～
パフォーマンス50%にDown！
DBA 「あらら・・・ちょっと想像以上に遅くなりましたね。。。
まずは使われてない索引を削除しましょうか。
想定される一連の処理を実行してもらえますか？」
アプリ 「はい、分かりました。」
しばし待ち、実行終了・・・
事例1 ～現場の様子～
DBA 「使われてない索引がいくつかあったので削除しますね。
これとこれと・・・
これらは削除しても影響なさそうですか？
確実に使う筈、というものがあれば教えて下さい。」
アプリ 「うーん、削除しても大丈夫だと思います。」
DBA 「じゃ、削除しますねー」
そして、再度負荷テスト・・・
１０%くらいパフォーマンス回復。まだ、あと40%・・・
事例1 ～現場の様子～
（ちょっとbreak）
使用されていない索引の確認方法として索引のモニタリング機能
がありますが、v$sql_plan でメモリに存在する実行計画を参照し、
現在、実行計画に使用されていないインデックスを確認するという
方法も可能です。短期間のテスト等ではお手軽に確認できます。
SQL> select object_name,object_type,hash_value 1 from v$sql_plan2 where object_type like 'INDEX%' and object_name like '%EMP%' 3 group by object_name,object_type,hash_value
4 order by 1,2;
OBJECT_NAME OBJECT_TYPE HASH_VALUE --- --- ---IDX_EMP_1 INDEX 4000148954 PK_EMP INDEX (UNIQUE) 1933697836 PK_EMP INDEX (UNIQUE) 4074557984
出力されてない
事例1 ～現場の様子～
DBA 「insert 競合を解消するには・・・
フリーリストを増やす！かな。試してみるか！
と思ったけど、、、
この表がある表領域は自動セグメント領域管理だった。
フリーリストの調整はできないじゃん・・・
えーっと、この表は連番で insert されていくから、
どうしても索引のブロックは競合するんだろうな。。。」
00001 00002 00003 00004 00005 ： 索引ブロック insert insert insert insert insert索引は順番に並んで格納される為、
このシステムの処理特性上、同一
ブロックへの競合が発生しやすい！
事例1 ～現場の様子～
（またまた、ちょっとbreak）
フリーリストとは、 insert 可能な空きブロックの情報を管理している
領域。insert 時にはフリーリストの空きブロック情報を参照する為、
insert の多重度が高いとフリーリストへのアクセスが競合する。
その場合、フリーリストを増加させることでパフォーマンスが向上する
可能性がある。自動セグメント領域管理（ASSM）では、ビットマップ
情報で空きブロック情報が管理され、明示的に調整はできない。
insert可能な ブロックのリスト block#1 block#5 block#7 Insert #1 （空き） #2 #3 #4 #5 （空き） #6 #7 （空き） #8 Insert Insert Insert Insert フリーリスト事例1 ～現場の様子～
DBA 「連番で次々と insert されてくるデータを同一ブロックに
集中させない為には・・・
ハッシュパーティションだな！
逆キー索引も有効か？？？
でも、逆キー索引は範囲検索できないんだよな、確か。
パーティションオプション持ってるし、パーティショニング
してみるか！」
問題となっていそうな表と索引をハッシュパーティション化・・・
性能改善！更に、以前より20%程度の性能向上！
事例1 ～解説～
[原因]
連番データの insert が多重実行されるという特性であった為、
同一ブロックへの競合が発生しやすい状況であった。
そのような状況で過剰に索引を追加したことにより、ブロック競合
が多発した。
[対処]
1．丌要な索引の削除。
2．ハッシュパーティショニング。
事例1 ～解説～
索引がボトルネック
になる場合もある。
- 更新系処理では、表データと同様に索引データの
更新も必要となる為、オーバヘッドがかかる。
- 連番データの insert が多重実行されるような場合
索引ブロックの競合が発生しやすい。
事例２ ～概要～
•
システム概要
–
金融系システムのDB
–
Oracle10gR1 4node RAC
•
状況
–
取引は月曜午前7時から土曜午前7時まで
–
土曜の日中にメンテナンス作業実施
–
月曜午前7時のオープン直後からDBの負荷が急上昇
–
サーバハングによる障害発生
•
要望
–
障害調査を依頼
事例２ ～状況～
待機イベント
CPU使用率
復旧
障害
enqueue の TS(Temp Segment)、
SS(Sort Segment)が増加している。
事例２ ～状況～
TEMP表領域への物理アクセスが多い。
過剰なソートを実行しているSQLがある？？
事例２ ～状況～
CPU_TIME と ELAPSED_TIME の差が大きい
→ 待機イベント時間が長いということ！
高負荷 SQL
SQL [Hash Value=XXXXXXXXXX] ---SELECT ･･･ FROM TAB1 WHERE ･･･DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME
(YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec)
--- --- --- --- --- ---
---2009/11/02 07:45:15 652 1 20,836 21,654 8.542 38.334
SQL [Hash Value=??????????]
---SELECT ･･･ FROM TAB2 WHERE ･･･
DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME
(YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec)
--- --- --- --- --- ---
事例２ ～現場の様子～
この時の現場の様子をお届けします・・・
【土曜の日中】
Aさん 「古いデータを大量に削除したからフラグメンテーションを
解消しとかないとな。」
SQL> alter table EMP move;
SQL> alter index PK_EMP rebuild;
SQL> alter index IDX_EMP_1 rebuild;
SQL> alter index IDX_EMP_2 rebuild;
事例２ ～現場の様子～
【月曜7時】
Aさんの携帯に運用監視オペレータから電話が・・・
OP 「Aさんっ！DBサーバのCPUが100%に張り付きっぱなしで
サービスが停まってます！」
Aさん 「えぇ！？すぐ確認します！」
Aさんはリモート接続してすぐに調査を開始。
事例２ ～現場の様子～
【月曜7時30分頃】
Aさん 「土曜にメンテナンスした表にアクセスしているSQLが
遅いみたいだな。実行計画が変わっちゃったみたい・・・
よし、統計情報を収集しよう！」
SQL> exec dbms_stats.gather_table_stats(
ownname => 'SCOTT',
tabname => 'EMP',
-cascade => true);
Aさん 「どうかなぁ・・・。」
事例２ ～現場の様子～
駄目だ！！
実行計画も変わってないようだ。
Aさん 「統計情報を再収集したから、再解析してる筈なんだ
けどなぁ・・・何で実行計画が変わってくれないんだろ。
ブツブツ・・・」
その後しばらく試行錯誤するも状況は改善せず・・・
事例２ ～現場の様子～
【月曜8時頃】
Aさん 『どうしよう・・・何か他に手はないかな。。。
あ、実行計画の問題だから共有プールも関係あるか？
とりあえずフラッシュしてみよう。』
SQL> alter system flush shared_pool;
Aさん 『ん？ちょっと負荷が下がってきたか？
おぉー！下がった下がった！よかった～』
これで一安心・・・
事例２ ～解説～
[原因]
以下のメンテナンス作業によって、表の
オプティマイザ統計情報が
削除
された。
1．表の再編成（move処理）
2．索引の再編成（rebuild処理）
その後、統計情報再収集を行わなかった為、デフォルトの統計情報
が利用され、結果的に適切な実行計画が選択されなかった。
（補足）
move処理後は索引が使用丌可（STATUS=UNUSABLE）となる為、
rebuild処理が必須。
事例２ ～解説～
[統計情報の収集後、実行計画が変わらなかったワケ]
dbms_stats.gather_table_stats の no_invalidate オプションが
auto_invalidate （10gR1以降のデフォルト値） だった為。
この auto_invalidate の場合、新しい統計情報を利用した再解析が
行われるまでにタイムラグがある。
（しばらくの間は既存のカーソルを再利用する）
[対策]
1．no_invalidate を false にして実行する ↓（実行例）
or
2．共有プールをフラッシュする
SQL> exec dbms_stats.gather_table_stats( ownname => 'SCOTT', tabname => 'EMP', cascade => true, -no_invalidate => false);製品のご紹介
データベース監査ツール
•
データベースログ管理に必要なすべてを提供
するツール
•
300社、1,800ライセンスを超える販売実績
でJ-SOXおよび情報漏洩対策ツールのシェ
アNo.1
•
大規模顧客、大規模システムへの導入に強
み
•
対応データベース
Oracle Database EE/SE
Microsoft SQL Server
（2000_32bit.2005_32bit）Fujitsu Symfoware Server
パフォーマンス管理ツール
•
パフォーマンス管理、パフォーマンスチューニ
ングを実現するツール
•
実績
1995年の販売以来、1,000社、8,000ライ
センスを超える販売実績。オラクルデータ
ベースの６本に１本の割合で導入されるパ
フォーマンスツールのデファクトスタンダード
•
対応データベース
Oracle Database EE/SE/SE1
※オラクルデータベースの６本に１本という数字は、 特定パートナー様からの報告内容より引用しております。
おら！オラ！Oracle どっぷり検証生活
Oracleを徹底検証した結果を、隔週水曜日に配信しています。
ご登録はこちらから（無料！）
http://www.insight-tec.com/mailmagazine/mailmagazine_index.html
本日のセミナーに関するお問い合わせなどご自由に・・・
rmatsuo@insight-tec.co.jp
無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。
