以 下 の 事 項 は 弊 社 の 一 般 的 な 製 品 の 方 向 性 に 関 する 概 要 を 説 明 するものです また 情 報 提 供 を 唯 一 の 目 的 とするものであり いかなる 契 約 にも 組 み 込 むことは できません 以 下 の 事 項 は マテリアルやコード 機 能 を

津 島 博 士 のパフォーマンス 講 座 パフォーマンス 問 題 はなぜ 起 きるのか 日 本 オラクル 株 式 会 社 製 品 事 業 統 括 本 部 ディレクター 津 島 浩 樹

以 下 の 事 項 は 弊 社 の 一 般 的 な 製 品 の 方 向 性 に 関 する 概 要 を 説 明 するものです また 情 報 提 供 を 唯 一 の 目 的 とするものであり いかなる 契 約 にも 組 み 込 むことは できません 以 下 の 事 項 は マテリアルやコード 機 能 を 提 供 することをコミットメン ト' 確 約 (するものではないため 購 買 決 定 を 行 う 際 の 判 断 材 料 になさらないで 下 さ い オラクル 製 品 に 関 して 記 載 されている 機 能 の 開 発 リリースおよび 時 期 につい ては 弊 社 の 裁 量 により 決 定 されます OracleとJavaは Oracle Corporation 及 びその 子 会 社 関 連 会 社 の 米 国 及 びその 他 の 国 における 登 録 商 標 です 文 中 の 社 名 商 品 名 等 は 各 社 の 商 標 または 登 録 商 標 である 場 合 があります 2

Agenda 津 島 博 士 のパフォーマンス 講 座 について パフォーマンス 問 題 に 対 する 悩 み パフォーマンス 問 題 はなぜ 起 きるか バッチ 処 理 の 問 題 点 3

津 島 博 士 のパフォーマンス 講 座 について oracletech.jpで 連 載 しています'http://oracletech.jp/products/tsushima/( 第 1 回 パフォーマンス 問 題 はなぜ 起 きるか (2011.01.19) 第 2 回 RAC 時 のバッチ 処 理 ついて (2011.02.01) 第 3 回 Statspackから 探 る パフォーマンス 問 題 の 原 因 特 定 方 法 (2011.02.14) 第 4 回 パフォーマンスFAQ: 良 く 聞 かれる 疑 問 点 にお 答 えします (2011.03.01) 第 5 回 オプティマイザとオプティマイザ 統 計 の 収 集 について (2011.04.05) 第 6 回 パフォーマンスの 基 礎 である 索 引 について (2011.04.19) 第 7 回 共 有 プールについて (2011.06.21) 第 8 回 断 片 化 について (2011.07.20) 第 9 回 良 いSQLについて (2011.8.30) 第 10 回 パーティションについて (2011.09.13) 第 11 回 良 いSQLについて'2( (2011.10.26) 4

パフォーマンス 問 題 に 対 する 悩 み なぜ 起 きるのか? 事 前 にテストを 行 っているのに テストの 量 が 不 足 している どう 解 決 するのか? 何 から 調 べるのか 特 定 するのも 難 しい 特 定 できても 解 決 方 法 が すべてを 速 くすることはできないことを 忘 れずに! なぜ 起 きるのか? どう 解 決 するのか? 5

パフォーマンス 問 題 はなぜ 起 きるか パフォーマンス 問 題 とは パフォーマンス 問 題 は 下 記 に 示 すとおり さまざまな 原 因 が 考 えられます ネットワーク 負 荷 が 高 い バグにより 正 常 動 作 していない クライアントPCが 遅 い DBの 設 定 が 悪 い OS 負 荷 が 高 い リソース 不 足 リソースが 使 用 されない 効 率 の 悪 いSQLが 実 行 されている アプリケーションが 遅 い CPU 負 荷 が 高 い メモリが 足 りない ディスクI/O 負 荷 が 高 い リソースの 無 駄 使 用 6

パフォーマンス 問 題 はなぜ 起 きるか パフォーマンス 問 題 とは リソース 不 足 すべてのH/Wリソースを 効 率 よく 使 用 できないと そこがボトルネ ックになる リソースを 使 用 できない これはCPUリソースのことです 待 機 が 発 生 するから 他 のリソース 不 足 でも 起 きる'I/O 待 ちなど( ロック'エンキュー ラッチ mutexなど( 待 ち 正 常 でも 待 機 は 発 生 することを 忘 れずに I/O' 読 込 み( 待 ちは 必 ず 発 生 する リソースの 無 駄 な 使 用 SQL 文 が 悪 い 7

パフォーマンス 問 題 はなぜ 起 きるか パフォーマンス 問 題 とは I/O' 読 込 み( 待 ちは 必 ず 発 生 する I/Oは 必 ず 発 生 する'キャッシュヒット 率 が100%でない 限 り( 書 込 みは 非 同 期 ですが'DBWRが 行 う( 読 込 みは 同 期 なため 'サーバープロセスが 行 う( 非 同 期 読 込 み'フルスキャンの 先 読 み 索 引 スキャンのData Block Prefetching(などはあるがCPUよりI/Oは 遅 い 同 期 I/O 非 同 期 I/O CPU 処 理 I/O 処 理 CPU 処 理 CPU 処 理 I/O 処 理 (usr+sys) (wio) (usr+sys) (usr+sys) (wio) ディスクI/O (%busy) ディスクI/O (%busy) ディスクI/O (%busy) 8

パフォーマンス 問 題 はなぜ 起 きるか パフォーマンス 問 題 とは 多 重 化 することで 使 用 率 は 向 上 する CPUコア 数 より 多 い 多 重 度 でも ディスクネックでないこと 同 期 I/O CPU 処 理 (usr+sys) I/O 処 理 (wio) プロセス CPU 処 理 (usr+sys) I/O 処 理 (wio) ディスクI/O ディスクI/O (%busy) (%busy) プロセス CPU 処 理 (usr+sys) I/O 処 理 (wio) 9

パフォーマンス 問 題 はなぜ 起 きるか どんな 時 に 発 生 するか ユーザ 数 の 増 加 による データ 量 の 増 加 による 長 期 運 用 による その 他 'そもそも が 悪 い( データベース 設 計 が 悪 い' 業 務 アプリの 知 識 不 足 ( SQL 文 が 悪 い'SQLの 知 識 不 足 ( 10

パフォーマンス 問 題 はなぜ 起 きるか ユーザ 数 の 増 加 による 競 合 が 多 発 する' 主 に 更 新 処 理 に 対 して( セグメントのブロック 同 一 ブロックにアクセスしてしまう 可 能 性 が 高 くなる 行 ロック'エンキュー( 同 一 データにアクセスしてしまうから エンキューは 他 にもあります HW'エクステントの 拡 張 が 多 い( SQ' 順 序 番 号 の 獲 得 が 多 い( など メモリ 上 のラッチ'mutex( 共 有 メモリは 全 てのプロセスからアクセスできる メモリ 上 の 整 合 性 を 保 つ 必 要 があるから 11

パフォーマンス 問 題 はなぜ 起 きるか ユーザ 数 の 増 加 による' 解 決 策 ( ブロックの 競 合 ブロック 内 の 行 数 を 少 なくする ブロックサイズを 小 さくする PCTFREEを 大 きく 圧 縮 は 逆 効 果 同 一 ブロックにアクセスしないようにする Freelist/FreelistGroupまたはASSM'デフォルト( これはINSERTのみ パーティション 化 12

パフォーマンス 問 題 はなぜ 起 きるか ユーザ 数 の 増 加 による' 解 決 策 ( 行 ロックの 競 合 アプリケーションのロジック' 又 はデータベース 設 計 (を 検 討 同 一 行 を 更 新 しなくても 良 いようにする SELECT FOR UPDATEを 行 っていないか Oracleは 共 有 ロックがないので 競 合 は 少 ない 頻 繁 に 更 新 される 列 が 同 じテーブルになっていないか メモリ 上 のラッチ 競 合 ユーザ 数 を 調 整 効 率 よい 数 'CPUコア 数 から(を 自 動 的 に 計 算 しているので 基 本 は 調 整 できない 13

パフォーマンス 問 題 はなぜ 起 きるか データ 量 の 増 加 による アクセス'CPU 使 用 率 I/O(が 増 加 する データ 量 と 比 例 して 増 加 するのか? 結 合 時 にはアクセスデータが 更 に 増 大 'ここが 勘 違 いしている( アクセスする 件 数 が10 10=100だとすると 10 倍 になると100 100=10,000になる 1 行 2 行 3 行 10 行 1 行 2 行 データ 増 加 した 割 合 のリソースを 増 強 しただけでは 性 能 は 同 じ にならないのです データを 絞 り 込 んでアクセスする 必 要 がある' 索 引 などで( 索 引 'Bツリー(の 階 層 が 増 える 階 層 はキーサイズと 行 数 によるので 3 行 10 行 1 行 2 行 3 行 100 行 1 行 2 行 3 行 100 行 14

パフォーマンス 問 題 はなぜ 起 きるか データ 量 の 増 加 による 索 引 'Bツリー(の 階 層 が 増 える ブロック 内 行 数 = 'ブロックサイズ キーサイズ( リーフブロック 数 = 行 数 ブロック 内 行 数 ツリー 階 層 = 'リーフブロック 数 ブロック 内 行 数 ( Bツリー ルートブロック 階 層 レベル ブランチブロック ブロック 内 行 数 が100の 場 合 のデータ 行 数 10,000(100x100) 行 までは2 階 層 リーフブロック 1,000,000(100x100x100) 行 までは3 階 層 100,000,000(100x100x100x100) 行 までは4 階 層 データブロック 15

パフォーマンス 問 題 はなぜ 起 きるか データ 量 の 増 加 による' 解 決 策 ( I/Oの 増 加 キャッシュヒット 率 の 改 善 メモリ 追 加 ディスク 性 能 の 改 善 ディスク 追 加 ディスク 配 置 の 改 善 ASM' 自 動 ストレージ 管 理 ( パーティション 化 CPU 時 間 の 増 加 CPUの 性 能 アップ' 性 能 アップするのは 難 しい( パラレル 処 理 実 行 計 画 に 影 響 オプティマイザ 統 計 の 精 度 を 上 げる 索 引 の 追 加 パーティション 化 16

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による 構 造 の 劣 化 や 情 報 の 陳 腐 化 によって 表 の 断 片 化 'エクステントの 断 片 化 ( I/O 効 率 が 低 下 索 引 の 断 片 化 索 引 アクセスのI/Oが 増 加 オプティマイザ 統 計 が 正 しくない 効 率 の 悪 い 実 行 計 画 I/O 時 間 'I/O 待 ちが(が 増 加 する 17

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による 表 の 断 片 化 'エクステントの 断 片 化 ( エクステントサイズが 同 一 でないため 領 域 が 取 れない アクセスが 飛 び 飛 びになる'シークが 多 くなる( 表 領 域 = 未 使 用 領 域 = 使 用 済 み 領 域 追 加 エクステント ローカル 管 理 表 領 域 により 削 減 18

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による ローカル 管 理 表 領 域 AUTOALLOCATE'デフォルト( セグメントサイズに 従 い64KB,1MB,8MB,64MBのエクステントを 確 保 'ビットマップの 管 理 は64KB 固 定 ( UNIFORM 表 領 域 作 成 時 に 指 定 したエクステントサイズ 固 定 デフォルト1MB ローカル 管 理 表 領 域 1 0 0 0 1 0 0 1 ビットマップ 19

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による 索 引 の 断 片 化 'ブロック 内 使 用 率 の 低 下 ( ブロックの 分 割 キーの 削 除 Bツリー 索 引 の 分 割 方 法 は 追 加 されるキーの 値 によって 異 なります 追 加 キーが 最 大 値 の 場 合 追 加 キーが 最 大 値 でない 場 合 10 20 30 40 50 60 10 20 30 40 50 45 < 60 < 40 10 20 30 40 50 60 10 20 30 40 45 50 オンライン 再 構 築 索 引 の 結 合 'COALESCE( 20

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による < 50 < 20 30 < 60 70 10 11 12 20 21 30 31 50 51 60 61 70 71 ALTER INDEX < 索 引 名 > COALESCE < 50 < 30 < 71 10 11 12 20 21 30 31 50 51 60 61 70 71 21

パフォーマンス 問 題 はなぜ 起 きるか 長 期 運 用 による オプティマイザ 統 計 が 古 い' 実 行 計 画 が 悪 くなる( 自 動 オプティマイザ 統 計 収 集 と 手 動 収 集 ' 大 量 の 更 新 (で 自 動 オプティマイザ 統 計 収 集 取 得 されていないオブジェクト 10% 以 上 データが 更 新 されて いるオブジェクト デフォルトの スケジューラのウィンドウ の 設 定 : 月 曜 日 ~ 金 曜 日 は22 時 から 翌 朝 2 時 までと 土 曜 日 日 曜 日 は6 時 から 翌 朝 2 時 まで SPM'SQL 実 行 計 画 管 理 ( 常 にSQL 計 画 ベースラインに ある 実 行 計 画 が 使 用 される 実 行 ' 運 用 時 ( SYSAUX 表 領 域 SQL Management Base 実 行 計 画 履 歴 SQL 計 画 ベースライン プランA プランA 実 行 'システム 変 更 後 ( プランA プランB プランC プラン 変 更 を 検 証 し パフォー マンスが 低 下 する 場 合 は 防 止 22

パフォーマンス 問 題 はなぜ 起 きるか データベース 設 計 が 悪 い これは 昔 から 考 え 方 は 変 わらない 正 規 化 しすぎて 結 合 が 多 いなど できるだけ 結 合 しないように 逆 正 規 化 などを 行 う 冗 長 データなどを 持 つ データ 管 理 が 複 雑 になる 23

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い 実 行 計 画 が 悪 くなる 索 引 を 使 用 しない 無 駄 な 処 理 を 行 っている データアクセスが 多 い 同 じデータを 何 回 もアクセスしている 24

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い 改 善 可 能 なSQL 文 について 索 引 を 使 用 しない 記 述 である INとEXISTSについて 結 合 は 件 数 を 絞 り 込 んでから ソート 処 理 はできるだけ 少 ない 件 数 で'できれば 行 わない( 繰 り 返 し 副 問 合 せはWITH 句 で 25

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い' 索 引 を 使 用 しない 記 述 ( NULL 比 較 やNOT'!=(を 使 用 'Bツリー 索 引 使 用 時 ( SQL> SELECT * FROM tab1 WHERE c1 IS NULL; SQL> SELECT * FROM tab1 WHERE c1 IS NOT NULL; SQL> SELECT * FROM tab1 WHERE c1!= 10; 26

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い' 索 引 を 使 用 しない 記 述 ( 列 を 演 算 している SQL> SELECT * FROM tab1 WHERE c1 / 10 < 10000; SQL> SELECT * FROM tab1 WHERE substr(c2,3,4) = AAAA ; SQL> SELECT * FROM tab1 WHERE c1 < 1000; SQL> CREATE INDEX ix_c2 ON tab1 (sunstr(c2,3,4)); 27

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い' 索 引 を 使 用 しない 記 述 ( 後 方 一 致 ' 中 間 一 致 ( 条 件 SQL> CREATE INDEX ix_tab11 ON tab1 (c1,c2); SQL> CREATE INDEX ix_tab12 ON tab1 (c3); SQL> SELECT * FROM tab1 WHERE c3 LIKE %AA ; SQL> SELECT * FROM tab1 WHERE c3 LIKE %A% ; SQL> SELECT * FROM tab1 WHERE c2 = 10; 索 引 スキップスキャンはする'Oracle9iから( 28

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い' 索 引 を 使 用 しない 記 述 ( INリストやORを 使 用 SQL> SELECT * FROM tab1 2 WHERE c1 = 100 OR c2 = 200 OR c3 =300; SQL> SELECT * FROM tab1 WHERE c1 = 100 2 UNION ALL 3 SELECT * FROM tab1 WHERE c2 = 200 4 UNION ALL 5 SELECT * FROM tab1 WHERE c3 = 300; 29

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い INとEXISTSについて INは 一 意 性 処 理 'HASH UNIQUE(を 行 う SQL> SELECT * FROM tab1 WHERE c1 IN (SELECT c1 FROM tab2); SQL> SELECT * FROM tab1 WHERE EXISTS 2 (SELECT * FROM tab2 WHERE tab1.c1 = tab2.c1); 結 合 は 件 数 を 絞 り 込 んでから SQL> SELECT A.c2, count(*) FROM tab1 A, tab2 B 2 WHERE A.c1 = B.c1 AND c2 = 10 GROUP BY A.c2; SQL> SELECT A.c2, sum(ct) FROM tab1 A, 2 (SELECT c1,count(*) ct FROM tab2 WHERE c2 = 10 GROUP BY c1)b 3 WHERE A.c1 = B.c1 GROUP BY A.c2; 30

パフォーマンス 問 題 はなぜ 起 きるか SQL 文 が 悪 い ソート 処 理 はできるだけ 少 ない 件 数 で'できれば 行 わない( SQL> SELECT * FROM (SELECT FROM tab1 ORDER BY c1) WHERE ROWNUM < 101; SQL> SELECT c1, count(*) FROM tab1 GROUP BY c1 ORDER BY c1; SQL> SELECT /*+ NO_MERGE(A) */* FROM (SELECT c1, count(*) 2 FROM tab1 GROUP BY c1) A ORDER BY A.c1; 繰 り 返 し 副 問 合 せはWITH 句 で SQL> SELECT * FROM (SELECT 部 門,sum( 売 上 ) 部 門 売 上 2 FROM 売 上 表 GROUP BY 部 門 ) w_abc 3 WHERE 部 門 売 上 < (SELECT avg( 部 門 売 上 ) FROM 4 (SELECT 部 門,sum( 売 上 ) 部 門 売 上 FROM 売 上 表 GROUP BY 部 門 )); SQL> WITH w_abc AS (SELECT 部 門, sum( 売 上 ) FROM 売 上 表 GROUP BY 部 門 ) 2 SELECT * FROM w_abc 3 WHERE 部 門 売 上 < (SELECT avg( 部 門 売 上 ) FROM w_abc); 31

バッチ 処 理 の 問 題 点 バッチ 処 理 に 対 する 悩 み バッチ 処 理 を 速 くしたいのだが どうすれば 良 いか? 時 間 内 に 終 わらない だんだん 遅 くなってきた 難 しいので 諦 めている 並 列 化 しても 性 能 が 向 上 しないが? 逆 に 遅 くなった CPUは 余 っているのに 並 列 化 を 最 初 から 考 えていますか! バッチ 処 理 を 速 くしたのだが どうすれば 良 いか? 32

バッチ 処 理 の 問 題 点 並 列 処 理 で 性 能 アップ 並 列 処 理 とは なぜ 並 列 化 が 必 要 なのか マルチCPUコア 環 境 では 性 能 アップするためには 並 列 処 理 する 上 での 注 意 点 どんな 問 題 が 発 生 するか バッチ 処 理 などでは 更 新 がメインなので 競 合 が 発 生 し 易 い RACでの 注 意 点 更 にRACでは 33

バッチ 処 理 の 問 題 点 並 列 処 理 とは データ 量 の 増 加 とともに 処 理 時 間 も 増 加 する 並 列 化 で 処 理 時 間 を 短 縮 マルチCPUコアを 有 効 活 用 実 施 方 法 プログラム 分 割 パラレルDML'SQL 文 で( 34

バッチ 処 理 の 問 題 点 並 列 処 理 とは プログラム 分 割 データが 分 割 されていないので 各 プログラムですべてのデータに アクセスする DELETE FROM taba where cal1 < xxxxx and col2 = 1 DELETE FROM taba where cal1 < xxxxx and col2 = 2 DELETE FROM taba where cal1 < xxxxx and col2 = 3 プロセス プロセス プロセス プロセス DELETE FROM taba where cal1 < xxxxx and col2 = 4 テーブルtabA 35

バッチ 処 理 の 問 題 点 並 列 処 理 とは パラレルDML 内 部 的 にデータが 分 割 されて 並 列 に 処 理 する QCプロセス DELETE FROM taba where col1 < xxxxx プロセス プロセス プロセス プロセス 削 除 削 除 削 除 削 除 テーブルtabA 領 域 1 領 域 2 領 域 3 領 域 4 36

バッチ 処 理 の 問 題 点 並 列 処 理 する 上 での 注 意 点 並 列 化 することで 競 合 が 発 生 する バッチ 処 理 は 更 新 がメインなのでより 発 生 し 易 い ユーザ 数 が 増 加 する 場 合 と 同 じ ブロック 競 合 行 ロック 競 合 I/O 競 合 など これ 以 外 のも 様 々な 競 合 が 発 生 する 競 合 以 外 に 読 み 取 り 一 貫 性 によるUNDO 読 込 みが 多 発 する 表 分 割 又 はパーティション 化 する 37

バッチ 処 理 の 問 題 点 並 列 化 する 上 での 注 意 点 ' 競 合 の 例 ( 読 み 取 り 一 貫 性 によるUNDO 読 込 みが 多 発 する 更 新 中 データを 別 プロセスで 検 索 するため 行 ロックが 発 生 しないから 気 にしなくても 良 いと 思 ったら 大 間 違 い 更 新 前 確 定 データ バッチA バッチB 更 新 中 更 新 中 更 新 前 確 定 データ 更 新 中 検 索 中 38

バッチ 処 理 の 問 題 点 並 列 処 理 する 上 での 注 意 点 表 分 割 本 部 単 位 に 別 テーブルにするためアプリケーションでアクセスする データごとにテーブル 名 を 変 える 必 要 がある SELECT.. FROM 通 信 本 部 WHERE 事 業 本 部 = 通 信 SELECT.. FROM 通 信 本 部 UNION ALL SELECT.. FROM 製 造 本 部 UNION ALL SELECT.. FROM 流 通 本 部 通 信 本 部 テーブル 製 造 本 部 テーブル 流 通 本 部 テーブル 事 業 本 部 通 信 通 信 社 員 番 号 500 1000 売 上 目 標 200 万 80 万 売 上 実 績 100 万 50 万 事 業 本 部 製 造 社 員 番 号 1500 売 上 目 標 50 万 売 上 実 績 30 万 事 業 本 部 流 通 社 員 番 号 1200 売 上 目 標 70 万 売 上 実 績 45 万 それぞれのパッチプロセスで 別 々のテーブルにアクセスする 39

バッチ 処 理 の 問 題 点 並 列 処 理 する 上 での 注 意 点 パーティション 化 事 業 本 部 テーブルを 本 部 単 位 ' 通 信 製 造 流 通 (にパーティショ ン 化 することでアクセスするデータを 意 識 する 必 要 がない 'WHERE 句 の 条 件 でそれぞれのパーティションだけにアクセス( SELECT.. FROM 事 業 本 部 WHERE 事 業 本 部 = 通 信 SELECT.. FROM 事 業 本 部 事 業 本 部 テーブル 通 信 製 造 流 通 事 業 本 部 通 信 通 信 社 員 番 号 500 1000 売 上 目 標 200 万 80 万 売 上 実 績 100 万 50 万 事 業 本 部 製 造 社 員 番 号 1500 売 上 目 標 50 万 売 上 実 績 30 万 事 業 本 部 流 通 社 員 番 号 1200 売 上 目 標 70 万 売 上 実 績 45 万 それぞれのバッチプロセスで 別 々のパーティションにアクセスする 40

バッチ 処 理 の 問 題 点 並 列 化 する 上 での 注 意 点 'RACでの 注 意 点 ( RACではキャッシュフュージョンが 発 生 する 更 に 性 能 ダウンする シングルノード' 非 RAC(より 遅 くなる 場 合 も Instance 1 キャッシュフュージョン Instance 2 41

並 列 処 理 の 問 題 点 RACでの 注 意 点 どうするのか パラレルDML パーティション 化 ' 表 分 割 でも 可 ( シングルノードで 実 行 'どうしようもできなければ( パーティション 化 パラレルDMLによる 事 例 ログなどのデータ 削 除 名 寄 せ 処 理 による 差 分 更 新 外 部 ファイルの 取 り 込 み'マスタデータのチェック 含 む( 並 列 化 が 難 しいと 思 う 処 理 もパーティション 化 することで 簡 単 に 改 善 できたりします 42

並 列 処 理 の 問 題 点 RACでの 注 意 点 'パーティション 化 による 事 例 ( ログなどのデータ 削 除 アクセスログを 定 期 的 に 削 除 するバッチ 処 理 をRACで 行 うと 逆 に 遅 くなる 'キャッシュフュージョンが 多 発 する(のでシングルで 行 っていた 事 例 です 改 善 策 削 除 する 単 位 にパーティション 化 してDROP PARTITIONを 行 う ことで 一 瞬 で 削 除 できます 削 除 バッチA 削 除 バッチB 削 除 バッチZ 大 量 削 除 大 量 削 除 大 量 削 除 インスタンス#1 共 有 プール 共 有 プール インスタンス#2 キャッシュ フュージョン ALTER TABLE ログ 表 DROP PARTITION 201001 削 除 プロセス ログテーブル 201012 201011 201002 201001 43

並 列 処 理 の 問 題 点 RACでの 注 意 点 'パーティション 化 による 事 例 ( 名 寄 せ 処 理 による 差 分 更 新 ' 存 在 しないものは 挿 入 ( 定 期 的 に 顧 客 の 名 寄 せを 行 うバッチ 処 理 をRACで 行 うと 逆 に 遅 くなる'キャ ッシュフュージョンが 多 発 する(のでシングルで 行 っていた 事 例 です 改 善 策 並 列 処 理 する 単 位 でパーティション 化 して2ノードから 並 列 実 行 し てもキャッシュフュージョンが 発 生 しないようにします'それぞれのプロセス で 更 新 するデータは 別 々のパーティションになるようにします( 名 寄 せバッチA 大 量 更 新 インスタンス#1 キャッシュ フュージョン インスタンス#1 名 寄 せプロセス 処 理 結 果 名 寄 せバッチB 名 寄 せバッチC 大 量 更 新 共 有 プール 共 有 プール 名 簿 X 名 簿 Y 名 簿 Z 処 理 結 果 名 簿 X 名 簿 Y 名 簿 Z 名 寄 せプロセス インスタンス#2 名 寄 せプロセス 名 寄 せプロセス P_a P_k P_s 名 寄 せバッチZ 大 量 更 新 インスタンス#2 44

並 列 処 理 の 問 題 点 RACでの 注 意 点 'パラレルDMLによる 事 例 ( 外 部 ファイルの 取 り 込 み'マスタデータのチェック 含 む( 外 部 ファイルをマスタテーブルと 整 合 性 チェックをして 格 納 先 テーブルに 差 分 更 新 するバッチ 処 理 をRACで 行 うと 逆 に 遅 くなる'キャッシュフュー ジョンが 多 発 する(のでシングルで 行 っていた 事 例 です 改 善 策 外 部 ファイルを 外 部 表 としてパラレルDML'MERGE 文 で 差 分 更 新 (を 整 合 性 チェックをしながら 行 うことで キャッシュフュージョンを 発 生 しないようにします 取 込 みバッチA 取 込 みバッチB 取 込 みバッチC 取 込 みバッチZ 大 量 更 新 大 量 更 新 大 量 更 新 インスタンス#1 共 有 プール 共 有 プール インスタンス#2 キャッシュ フュージョン マスタX マスタY マスタZ 格 納 先 MERGE INTO 格 納 先 A USING (SELECT b.* FROM wtab b LEFT JOIN マスタX X ON (b.x1 = X.x1) ) B ON (A.a1 = B.a1) WHEN MATCH THEN wtab ( 外 部 表 ) インスタンス#1 外 部 ファイル 読 込 みプロセス インスタンス#2 外 部 ファイル 読 込 みプロセス マスタX マスタY マスタZ 格 納 先 45

最 後 に 津 島 博 士 のパフォーマンス 講 座 質 問 お 待 ちしていますので よろしくお 願 いします 46

OTNセミナーオンデマンド コンテンツに 対 する ご 意 見 ご 感 想 を 是 非 お 寄 せください OTNオンデマンド 感 想 http://blogs.oracle.com/oracle4engineer/entry/otn_ondemand_questionnaire 上 記 に 簡 単 なアンケート 入 力 フォームをご 用 意 しております セミナー 講 師 / 資 料 作 成 者 にフィードバックし コンテンツのより 一 層 の 改 善 に 役 立 てさせていただきます 是 非 ご 協 力 をよろしくお 願 いいたします 47

OTNセミナーオンデマンド 日 本 オラクルのエンジニアが 作 成 したセミナー 資 料 動 画 ダウンロードサイト 掲 載 コンテンツカテゴリ( 一 部 抜 粋 ) Database 基 礎 Database 現 場 テクニック Database スペシャリストが 語 る Java WebLogic Server/アプリケーショングリッド EPM/BI 技 術 情 報 サーバー ストレージ 100 以 上 のコンテンツをログイン 不 要 でダウンロードし 放 題 データベースからハードウェアまで 充 実 のラインナップ 毎 月 旬 なトピックの 新 作 コンテンツが 続 々 登 場 例 えばこんな 使 い 方 製 品 概 要 を 効 率 的 につかむ 基 礎 を 体 系 的 に 学 ぶ/ 学 ばせる 時 間 や 場 所 を 選 ばず'オンデマンド(に 受 講 スマートフォンで 通 勤 中 にも 受 講 可 能 毎 月 チェック! コンテンツ 一 覧 はこちら http://www.oracle.com/technetwork/jp/ondemand/index.html 新 作 &おすすめコンテンツ 情 報 はこちら http://oracletech.jp/seminar/recommended/000073.html OTNオンデマンド 48

オラクルエンジニア 通 信 オラクル 製 品 に 関 わるエンジニアの 方 のための 技 術 情 報 サイト 技 術 資 料 インストールガイド 設 定 チ ュートリアルetc. 欲 しい 資 料 への 最 短 ルート アクセス ランキング 他 のエンジニアは 何 を 見 て いるのか? 人 気 資 料 のラン キングは 毎 月 更 新 特 集 テーマ Pick UP 性 能 管 理 やチューニングな ど 月 間 テーマを 掘 り 下 げて 詳 細 にご 説 明 技 術 コラム SQLスクリプト 索 引 メンテ ナンスetc. 当 たり 前 の 運 用 / 機 能 が 見 違 える!? http://blogs.oracle.com/oracle4engineer/ オラクルエンジニア 通 信 49

oracletech.jp ITエンジニアの 皆 様 に 向 けて 旬 な 情 報 を 楽 しくお 届 け 製 品 / 技 術 情 報 Oracle Databaseっていく ら?オプション 機 能 も 見 積 れる 簡 単 ツールが 大 活 躍 セミナー 基 礎 から 最 新 技 術 まで お 勧 めセミナーで 自 分 にあ った 学 習 方 法 が 見 つかる スキルアップ ORACLE MASTER! 試 験 頻 出 分 野 の 模 擬 問 題 と 解 説 を 好 評 連 載 中 Viva! Developer 全 国 で 活 躍 しているエンジ ニアにスポットライト きらり と 輝 くスキルと 視 点 を 盗 もう http://oracletech.jp/ oracletech 50

あなたにいちばん 近 いオラクル Oracle Direct まずはお 問 合 せください Oracle Direct システムの 検 討 構 築 から 運 用 まで ITプロジェクト 全 般 の 相 談 窓 口 としてご 支 援 いたします ステム 構 成 やライセンス/ 購 入 方 法 などお 気 軽 にお 問 い 合 わせ 下 さい Web 問 い 合 わせフォーム 専 用 お 問 い 合 わせフォームにてご 相 談 内 容 を 承 ります http://www.oracle.co.jp/inq_pl/inquiry/quest?rid=28 フリーダイヤル 0120-155-096 フォームの 入 力 にはログインが 必 要 となります こちらから 詳 細 確 認 のお 電 話 を 差 し 上 げる 場 合 がありますので ご 登 録 の 連 絡 先 が 最 新 のものになっているかご 確 認 下 さい 月 曜 ~ 金 曜 9:00~12:00 13:00~18:00 ' 祝 日 および 年 末 年 始 除 く( 51

53