JPOUG> SET EVENTS 20140907でお話した「DB思い出話いろいろ（仮）」の資料です。

1. DB思い出話いろいろ(仮)
北山貴広, @kitayama_t/ 2014年9月7日
JPOUG> SET EVENTS 20140907 @IIJ飯田橋公開版資料
1

2. 今日の話題
• 自己紹介
• Oracle Databaseの思い出
• ORACLE MASTER
• 書籍などの技術情報
• 事例紹介：DB移行
• 事例紹介：トラブル対応
• 事例紹介：パフォーマンスチューニング
2

3. 自己紹介
3

4. 自己紹介
• データベースエンジニア。インフラ系全般が範囲。
• Oracle Databaseのスペシャリスト。トラブル対応とOracle DBのチューニングが得意（大好き）。
• ORACLE MASTER Platinum Oracle 9i Database を保有。
• 生まれも育ちは大阪、就職（結婚）してから甲子園在住。現在東京に単身赴任中(6年目)。50歳。
• 現在所属の会社(2社目)は1998年1月入社。最初の会社は1989年4月入社、鉄鋼会社のシステム部門。
• 2008年7月まで約10年間、大阪南港の客先に常駐。システム開発と運用保守（障害対応含む）で、
アプリ開発*以外*を担当。夜間障害対応も嬉々として実施。
• 2008年9月から東京に出張ベースでOracle DBチューニングで出稼ぎ。
• 2009年5月から某アプライアンスの仕事をしに東京に単身赴任。しばらくOracle DB関連に従事。
• 現在の業務はDB全般(Oracle DB, Vertica, PostgreSQL, MySQL)とRed Hat Storageなどデータまわり。
• 2012年からPostgreSQLエンタープライズコンソーシアム(PGECons)で活動。
4

5. 自己紹介（社外活動）
技術系雑誌（Software Design）
• 2011年4月号特集でデータベース遅延について執筆。
• 2011年5月号から「温故知新ITむかしばなし」というタイトルで連載開始、
当初1年という話だったが既に3年を経過。
タイトル：マイコン世代、CP/M、パソコン通信、Linux、BSDなど
翻訳
• 2003～2004年、MySQLクックブック(Vol1,2)を共訳。
IT勉強会
• 2009年4月に東京に来てから「IT勉強会」に積極的に参加。
• DB関係では、Oracle Database, PostgreSQL, MySQLなどに参加。
⇒それぞれのコミュニティーの違いが興味深い
（服装：背広・ワイシャツor Tシャツ、
ノートPC：Mac or 非Mac、
Twitter：積極的に書込みor ほとんどない）
5

6. Oracle Databaseの思い出
6

7. Oracle Databaseって何？
• よく出来たデータベース。他のデータベースの目標。
• バージョンがあがるたびに、ONLINEのまま出来ることが増え
て、人手がかかることがだんだん自動化されていった。
SORT_AREA_SIZE⇒PGA_AGGREGATE_TARGETとなったり。覚えた知識がどれが有効で
どれが無効かをバージョンアップのたびに知識を更新させられた。
• 一番は統計情報。10g以降コストベースオプティマイザが必須に
なってから、予期せぬ実行計画の変化に振り回された。
• パフォーマンスチューニングでとにかくSQL文を速くしたい時は、
テーブルアクセスせずに用事が済むIndex Only Scanをするイン
デックスを張る。これでかなりの期間、仕事できた。
(参考)
• Mac De Oracle 「いん!、イン!、Index どっぷりIndex Only Scan 生活」http://discus-hamburg.
cocolog-nifty.com/mac_de_oracle/2012/04/index-inde-only.html
7

8. Oracle Database歴史
• 1992 Oracle7 7.0
• 1997 Oracle8 8.0
• 1999 Oracle8i
• 2001 Oracle9i Database
• 2003 Oracle Database 10g
• 2007 Oracle Database 11g
• 2013 Oracle Database 12c
8

9. 初めて触れたバージョン
• Oracle 7 1994年～1995年頃
• HP-UX on Serviceguard 7.3.2.1.0
• またWindows Server上ではOracle7 Workgroup ServerをEUC（エン
ドユーザコンピューティング）向けにDWHを構築した。
• Pro*COBOLでバッチプログラムを書いたりもした。
9

10. Oracle7 Server / Oracle7 Workgroup Server
• 1995年頃、某電力会社のワンストップサービスシステム開発で出会う。
100名規模の大規模プロジェクト。電話一本で停止・開始が可能。
基幹DB(7万件)：Oracle7 (7.3.2.1.0)on HP-UX with Serviceguard
EUC用DB(35万件)：Oracle7 Workgroup Server on Windows NT 3.5
• 当時ちょうどソフトウェアが色々バージョンアップしていた。
• クライアントPC：Windows 3.1⇒Windows 95に変更
• 開発言語：Visual Basic 2.0⇒Visual Basic 4.0に変更
• DB接続用ソフト：Oracle Glue⇒OO4O(Oracle Object for OLE)に変更
• やってたこと：プログラマ
VBで共通ライブラリ開発、Pro*COBOLでバッチ、EUC用DBにデータ
ローディング、スキャナ用プログラム開発
SQL*Loaderのdirect=yオプションのローディングが速いことにビックリ。
10

11. Oracle8 Enterprise Edition for HP-UX
• 2000年6月本番のワークフローシステムで使用したバージョン。
• プロジェクト終了後、保守フェーズに入りそのまま基盤運用チー
ムのリーダーを担当。
• 夜間障害対応も含めて7年ほど更改まで面倒を見る。
• 8iからインストーラーがGUI必須になったので、CUIベースの一番
落ち着いたバージョン。
11

12. Oracle8 Enterprise Edition for Linux
• 1999年頃、米国OTNでOracle DatabaseのLinux版が公開された。
Oracle8 Enterprise Edition Release 8.0.5.1.0 for Intel LINUX
• 私物のSONY VAIO 505X(PCG-505X)に導入。
CPU:MMX Pentium 166MHz/Memory:64MB/
HDD:2.1GB/Display: SVGA(800x600)/Win95
• インストール要件としてglibc2が必要。
当時glibc2をサポートしていたのはDebian(Hamm)
Linux+DB用に600MBHDD領域を分割してインストール。
⇒貧弱なパソコンで本物のOracleが動いた！
12

13. Oracle8i Enterprise Edition for Linux R8.1.6
• 雑誌の広告
• Miracle Linux
Standard Edition V1.0
価格50,000円
出荷日2000年9月末日
Linux Journalで
’Linux Means Business’と
いうスローガンがあった
が、本当にそうなって
きたと感じた。
13

14. Oracle DBのマニュアルセット
• Oracle DBのマニュアルセットが数十万円。
• マニュアルと接点を持つことが出来るのがアドバンテージ。自分
が見たい時に自由に見れる環境（地位）に所属できるかどうか？
⇒昔はマニュアル一つ取っても限られた人のみアクセス可能であっ
て閉ざされた世界だった。
CD-ROM版のマニュアルが出た時は大喜び。
インターネットでマニュアルを見れるようになった時には時代の変
化を感じました。
14

15. ORACLE MASTER
15

16. ORACLE MASTER（旧制度）
CertViewにログインして取得した資格を確認
取得資格名認定日(当時の年齢)
• Oracle Silver Fellow 1999/08/31 (35)
• ORACLE MASTER Silver 1999/08/31 (35)
• ORACLE MASTER Gold 8 1999/10/13 (35)
• ORACLE MASTER Platimum 8 2000/03/01 (36)
• ORACLE MASTER Platinum 8i 2000/11/06 (36)
旧制度Platinum8iはCBT7科目(移行+1科目)で必須のトレーニングはなし。
黒本のおかげもあり、ペーパーGoldやペーパーPlatinumが数多く誕生。
ORACLE MASTERの集いで吉田育代さんに「全部自腹で受験w」と話す。

17. 1990年代終わりから2000年頃の資格の状況
• 情報処理技術者試験とベンダー試験の二つの流れがあった。
• オープンソースという言葉自体が定義されたのが1998年で、ベン
ダー製品（クローズドソース）が全盛期。
• マイクロソフト(MCP)、オラクル(ORACLE MASTER)、シスコ
(CCNA)の三大ベンダー試験。
• オープンシステムという言葉が流行って、マイクロソフトのOSの
Windows、オラクルのDBのOracle Database、シスコのネットワー
ク機器が出来ればよいという感じであまり悩みはなかった。
• 今はLPICやOSS-DBなどもありますね。
17

18. オラクルマスタードットオルグ（OMO）
http://www.oracle-master.org/
• OMO：ORACLE-MASTER.ORGとは
ORACLE-MASTER.ORGは、オラクルマスター有資格者およびこれから資格を取得しようとす
る方に情報提供および相互交流を行ってもらう場です。
• 和服のライター吉田育代さんからお声がかかり、「街で見かけた
OMOな方」の第11回(2002/03/20)でインタビューが掲載された。
https://web.archive.org/web/20020812091946/http://oracle-master.org/talk/varie/omo11.html
• インタビューされた頃のORACLE MASTERはまだ旧制度で、同じ
Platinumでも実技試験はなく、PC試験で必要な科目を集めるだけで
OKだった(7科目×15000円/科目)
• 2003年10月からトレーニングや実技試験必須の新制度に移行。

21. ORACLE MASTER（新制度）
CertViewにログインして取得した資格を確認
取得資格名認定日(当時の年齢)
• ORACLE MASTER Gold Oracle 9i Database 2006/03/24 (42)
• ORACLE MASTER Platinum Oracle 9i Database 2006/05/24 (42)
• ORACLE MASTER Gold Oracle Database 10g 2007/05/01 (43)
• ORACLE MASTER Platinum Oracle Database 10g
（2007/08/09 (43) 受験予定だったがPJ多忙で前日キャンセル)
• Oracle Database 10g Real Application Clusters
Administrator Expert 2009/09/30 (45)
• ORACLE MASTER Platinum Oracle Database 11g
（2009/10/14 (45) 受験⇒不合格, 2010/10/15 (46) 受験⇒不合格)
（2011/05/16 (47)未受験）

22. Database Server Internals受講
• 2011年11月～2012年3月の期間、DSIを受講。東京に単身赴任して
よかった出来事のうちの最高の一つ。長年の夢が実現。
• Platinum Clubで「Database Server Internalsを受講したい人はリク
エストしてね！」というメールが来ると、「参加希望！」と返事。
• ずっと大阪だったので、もし受講となったら1ヶ月有給休暇を取っ
てでも行こうと思っていた。（現実的にはかなり無理…）
• 今までやってきたこと（サポートからのリクエストでの情報収集
など）が、なぜそうなのかの仕組みが根本的にわかってすっきり。
22

23. Software Design 2012年2月号
• 第1特集「技術力＋αで勝負！IT市場
の転換期を生き抜く」をライターの
吉田育代さんが担当。
• OMOの「街で見かけたOMOな方」
の時が38歳、このインタビューでは
47歳と約10年間経過。
• 苦手なことも含めてとても正直に答
えたので他社からのスカウトは皆無。
（このインタビュー以前から1人だ
けお声がけしていただいてました）
23

24. HP Oracle Database Machine
24

25. 書籍などの技術情報
25

26. 帰省先(自宅)で生き残っていた書籍
26
Oracle8の全盛期。
分厚い本が多かった。

27. Oracleパフォーマンスチューニング
定番のオライリー本、これでDBからのパフォーマンスチューニングの基礎を作った
Oracleパフォーマンスチューニング第2版（1998年6月発売、1074p）
• Oracle8に対応
• スナップショット取得はUTILBSTAT.sql/UTILESTAT.sql
• statspackはまだ無い(Oracle9iで登場）
第2版の前に、少し小さい大きさ（A5判）の第1版があり、それを一通り読んだ
• オラクルパフォーマンスチューニング(A nutshell handbook) 薄緑色
(1994年10月発売、728p)インターナショナルトムソンパブリッシングジャパン
日本の書籍では、入門書は薄っぺらくて範囲が狭く、専門書は深くて説明不足。
この書籍で、入門から上級までわかりやすく全部解説するという書籍の存在を知った。
27

28. Oracle8 プロフェッショナルテクニック
• インサイトテクノロジーの小幡さんの書いた本。
• データベースブロックとか内部表とか、外に出ていない情報が満
載。Oracle Database Internalsという感じの本。
• 出版社はソフト・リサーチ・センター、全盛期。
• 内部構造がわかることが非常に楽しいのを
気付かせてくれた。
• INSIGHT OUT 2011の時にサインもらった。
28

29. 門外不出のOracle現場ワザ
• なぜか書籍化されている門外不出というタイトルの付いた本。
• パフォーマンスチューニング、内部構造、オプティマイザの仕組
みなど、大変わかりやすい本で本当に役立った。
• 一番お世話になった本だと思う。
29
社内セミナーでの解説
• オラクルコンサルタントが現場で実践した事柄をベース
に解説。オプティマイザの解説、統計情報の取り方をど
う考えるかのパターンなどこの本にしかない情報が満載。
Oracle DB技術者としてあるレベル以上を目指すなら必読
の本。

30. Expert Oracle Database Architecture 2nd Edition
• Ask Tomのトムカイトの著書。
• オライリー本のOracleパフォーマンスチューニングと同様、
とても分厚いけど分かりやすく初心者から上級者までの広い
範囲でわかりやすく教えてくれる本。
• Apress出版。インターネットでE-booksも簡単に買える。
• 現在は、3rd Editionが発売されている。
• サインもらった。
30

31. OTN（Oracle Technology Network）
31
• OTN Professionalという有償プログラム。
• OTN Software KitでCD-ROMが送られてきた。
• 開発ライセンスが使えた。

32. 事例紹介（データベース移行）
32

33. データベース移行
2009年に実施したデータベース移行のお話
2011年3月号の日経SYSTEMSの「成功するデータ移行」に掲載
○概要
システム：インターネット上で旅行サービスを提供、24時間365日。
○相違点
データベースバージョン：9iR2から11gR1
OS：Windows Server からHP-UX
CPU：リトルエンディアンからビックエンディアン
(TTSにおけるクロスプラットフォームは10g以上から)

34. 34

35. 移行対象のデータベース
2011年3月号の日経SYSTEMSの「成功するデータ移行」に掲載
• 移行対象データベースのバージョン
– 移行元：Oracle9i Database Release 2 (9.2.0.8) 2ノードRAC
– 移行先：Oracle Database 11g Release 1 (11.1.0.7.3) 2ノードRAC
• 移行対象オペレーティングシステム
– 移行元：Microsoft Windows Server 2003
– 移行先：HP-UX Version 11i v2
• 移行対象データベースの規模
– データ量(DataPump Full Exportサイズ)：約170GB
– テーブル数：約670
– LOB保有テーブル：1/Oracle Textテーブル：1
• 移行対象データベースのキャラクタ・セットは同一
– 移行元、移行先ともJA16SJIS

36. データベース移行の要件
• データベース移行に要する時間は７時間以内（６時間以内）とする。
• 現行本番データベースに影響を与えないこと。
• レプリケーションをするための空きディスク容量無し
• レプリケーションをするためのCPU使用率の余裕なし
• 可能な限り安全な方法で移行を行うこと。
• システム切替は一括切替。並行稼働は実施しない。
36

37. データベース移行のシステム構成
37
移行元データベース中間データベース移行先データベース
Oracle9i
既存DBサーバ
Windows2003
SANARENA
P-Vol
SANARENA
S-Vol
Backupサーバ
Windows2003
Oracle11g
新DBサーバ
HP-UX11iv2
H12K
P-Vol
H12K
S-Vol
Backupサーバ
HP-UX11iv2
Oracle9i&11g
中間サーバ
Windows2003
EVA
本番NW(100Mbps)

38. データベース移行
2009年に実施したデータベース移行のお話
○使ったワザ
1. ストレージコピーのバックアップに直接FC接続して読み出し
2. トランスポータブル表領域
3. DataPump
4. ファイル転送用ソフト活用

39. データベース移行の特徴
• 一括移行方式を採用
• 現行本番機上にある本番DBに対する参照・変更は一切無し
• 唯一実施していただいたのはストレージへのDBのホットバックアップをコール
ドバックアップに変更(※)
• 移行用に使用する中間サーバを用意
• 現行本番機とOS/Oracle Databaseを同一にする
• トランスポータブル表領域(9i⇒11g)+Data Pump Export(11g Windows)
/Import(11g HP-UX)と、従来型Export(9i Windows)/Import(11g HP-UX)
を併用
• 全てのテーブルをData Pumpで処理したかったが2テーブルでORA-8103エラーが
発生したため従来型Export/Importを併用。
Bug 8754670(IMP-17 / ORA-8103 transporting a large dictionary managed
tablespace [ID 8754670.8])
ディクショナリ管理表領域に格納されている大規模表で障害が発生するバグを踏
んでしまった
39

40. 一括移行方式
40
現行本番環境新本番環境
事前作業Export ファイル転送Import 事後作業
•並列処理化
•ツール検討
•移行対象絞
り込み
•並列処理化
•ツール検討
•並列処理化
３処理のパイプライン
実行処理
•並列処理化

41. 今回のデータベース移行のステップ
1. 中間サーバから現行本番のストレージ副ボリューム(S-Vol)をFCで接
続し現行DBのファイルを参照
• S-Vol領域にある現行DBのファイル(rawイメージ)を「参照」するのですが、
Oracle Databaseは起動するとヘッダ情報を更新するので、ファイルは読み書き
モードでアクセスされます
2. 先に従来型Exportを使って2テーブルをExport、dmpファイルを転送
3. トランスポータブル表領域を使って9i⇒11gにメタ情報をコピーして
11gインスタンスから9i領域にアクセス可能としてData PumpでExport
4. 出力されたdmpファイルを順次ファイル転送
• (*)4並列実行で5GB単位で分割して出力。
5. 転送されたdmpファイルを従来型ImportData PumpでImport
6. インデックス作成/PK制約作成/外部キー作成/統計情報Import
7. 現行DBと新DBのテーブル件数とディクショナリ情報を取得して比較41

42. 「トランスポータブル表領域+ 従来Export/Import 」方式
• 中間サーバからS-Volのrawファイルにてインスタンス起動
Oracle9i
既存DBサーバ
Windows2003
SANARENA
P-Vol
SANARENA
S-Vol
Backupサーバ
Windows2003
Oracle11g
新DBサーバ
HP-UX11iv2
H12K
P-Vol
H12K
S-Vol
Backupサーバ
HP-UX11iv2
Oracle9i&11g
中間サーバ
Windows2003
本番NW(100Mbps)
④ 11gDBインスタン
ス起動、9iDB表領域
情報をTTSで11gDB
に組み込み
実データ
dmp
ファイル
⑦DataPump Import
⑤11gからと従来型Importを実行
DataPump
Exportと9iから
従来型
Exportを実行
EVA
⑥dmpファイル
転送
実データ
dmp
ファイル
⑧インデックス、制約、トリ
ガー、シーケンスの作成、
統計情報の適用
③9iDB
インスタンス起動
①DB停止・S-Vol
にコールドバックアッ
プをsync,split
②FC敷設・結線
中間ｻｰﾊﾞ起動
⑨移行データ整合性
検証、最終確認
42

43. 本番移行時のDB移行想定時間
DB移行ステップ本番DB
移行想定
1 現行システムサービス停止&本番DB停止、S-VolをFC接続中間サーバ
起動1時間3分
2 中間サーバ上で9iDB起動15分
3-a Oracle9i上で表領域情報抽出/読込専用に変更、従来型Expで2テーブ
ルdmp出力22分
4時間15分
3-
b
TTSで11gR1に表領域をアタッチ、2テーブル以外をDataPumpでdmp
出力55分
4 中間DBから新本番DBサーバにdmpファイルを転送52分
5 DataPumpと従来型Impを使って新本番DBにローディング1時間30分
6 新DB上でインデックスと制約とトリガーを作成2時間55分
40分/5分
7 移行整合性確認と最終確認30分
合計6時間15分
43

44. データベース移行で工夫したこと
• ファイル転送はFileZillaを使用
• 当初はWindows標準のftpクライアントソフトを複数同時実行では、1GbpsのNW使用
率が30%～60%程度と低かった。ファイルの並列転送が出来るソフトを探して使用
⇒並列度を4に設定、NW使用率が80%～90%平均となってファイル転送時間が短縮
• Data Pump Importと従来型ImportをRACの別々のマシンで実行
• 11g Release 1まではRAC構成でも1台でのみData Pumpが実行可能という制限あり
• Bugを踏んでしまって仕方なしに２つのテーブル（しかも１つはDB中最大のテーブ
ル）を１台のマシンで実行し、もう１台でData Pump Importを実行（CPU数の8で
PARALLEL=8）
• Export/ファイル転送/Importをパイプライン処理出来るようData Pumpの処
理対象テーブルを4つのグループに分割して処理
• 最もボトルネックである最大テーブルの従来型Export/Importを最優先した
• コマンドラインを手入力していたのをスクリプトで自動実行してリターン
キー入力のみで確認して実行出来るように実装44

45. 事例紹介（トラブル対応）
45

46. トラブル事例その１：社内ポータルログイン不可障害
ある日突然DBサーバの負荷が高くなる
○事象
社内システムの玄関口（ポータル）でユーザ情報を管理しているDB
サーバのCPU使用率が高騰し、ログインできない状況となった。
○調べてみると
とある特定のSQL文のCPU使用率と論理読み込みが通常と比べて非
常に高くなっていた。一言でいうと、暴走していた。
○とりあえずやった対応
統計情報を新規に取得。暴走していたSQL文は通常に戻った。

47. トラブル事例その１：社内ポータルログイン不可障害
ある日突然DBサーバの負荷が高くなる
○どのようなSQL文か？
二つのテーブルからJOINするSELECT文。
○実行計画は？
NEST LOOPで、通常時と暴走時では、駆動表が入れ替わっていた。
○統計情報はどのようにしていたか？
デフォルトのまま。つまり、毎日夜に統計情報が自動的に更新。
○統計情報取得の暫定対応
自動実行は停止して、明示的にコマンド実行で取得に変更。
取得サイクルも日次から週次に変更。

48. トラブル事例その１：社内ポータルログイン不可障害
ある日突然DBサーバの負荷が高くなる
○原因は？
暴走の時の統計情報ではDATE型のとある列(START_DATEと
END_DATE)のヒストグラムが取得されなかったことが原因。
○なぜヒストグラムが取られなかったの？
METHOD_OPT引数の設定値はデフォルトのまま（特に指定せず）。
該当カラムに4000年という現時点とは乖離した日付が入ると、
Oracleはヒストグラムを取らない判断をした。そのため、通常とは異
なる実行計画となった。（当時は「仕様」という回答が後に来た）
(Bug 9823080 - Incomplete histograms generated)
○暫定対応
FOR ALL COLUMNS SIZE 254と明示的に指定。

49. トラブル事例その２：
ORA-00054 リソースビジー、NOWAITが指定されていました。
とある業務の処理をしようとするとORAエラー発生。
○どのような業務処理か？
不備管理といって、業務処理の書類を点検、訂正する業務
DBのテーブルからデータを取り出して10分以上かかって更新
○原因
DBブロック中のITL領域不足。同時アクセス数より少なかった。
一つ一つのレコードは比較的小さく、1つのDBブロックに15件程度
入ってた。初期値からUPDATEでレコード長が大きくなっていった。
○対応
当初ALTER TABLE文でINITRANS値を増やす。既存ブロック変更されず。
⇒結局export/create table/importを実施。

50. トラブル事例その３：インデックスを使ってくれない。
WebのURLを保存したテーブルでインデックスを使ってくれない。
○DBへの保存形式
VARCHAR2型の列にURLを保存。
○原因
文字列型のヒストグラムは先頭32バイトまでが対象。URLをそのまま保
存すると、殆ど同一の値となる。門外不出のヒストグラム説明より。

51. 事例紹介：チューニング
51

52. 実例:システム保守での改善対応
• 要求：ディスク高負荷を解消したい
• 制約：インデックス付加は不可
• アプリ保守が複数の会社で、影響調査・テストが出来ない
1. SQL文の特定(AWRレポート)
2. 検索条件と検索テーブル(件数)&インデックス情報をもとに、インデック
ス案と検索条件追加案作成
3. 結果：検索条件として= のものをひとつ付加
• 1SQLあたり改善前改善後2
• Elapsed Time 306.5 84.5
• CPU Time 5.4 2.2
• Buffer Gets 769834 311785
• Disk Reads 60375 24318
52

53. 性能検証/DBパフォーチューで注意すべき点
• (SQL文の)性能検証は本番データ(相当)を使おう。
• 負荷性能テストはデータに気をつけよう。開発プロジェクトでは、テストデータ
の内容が大事。
• データ件数相違：100件と100万件
• データ内容相違：100万件でもすべて別々の値か同一かでインデックス使用が異
なる。本番と同じばらつきの度合いが必要。
• ex. インデックスを使わない!となってデータを調べたら、ログインIDが100万すべて値が1
であるとか…
• (SQL文の)性能検証は本番での検索条件を使おう。
• 検索条件のバインド変数にどんな値が入るかでインデックス使用有無が変わる。
• 負荷性能検証は本番の検索更新負荷をかけよう。
• 実行回数や同時アクセス数等
• 実行ごとに検索条件の値を変える(異なるログインID)など
• 統計情報は本番想定できちんと更新しよう。
• 統計情報が違うと実行計画が違ってきたりしますので注意。
データと同じぐらい統計情報
も大事です。統計情報には
ほんと振り回されましたし、
今だに振り回されています。
• ex.データが少ない時に更新して実行計画がインデックスFFS、その後大量データをinsert
でCPU張り付き...
53
特に開発プロジェクトやテスト環境の性能検証での注意点

54. ありがとうございました！
54