db思い出話いろいろ（仮）
DESCRIPTION
JPOUG> SET EVENTS 20140907でお話した「DB思い出話いろいろ（仮）」の資料です。TRANSCRIPT
DB思い出話いろいろ(仮)北山 貴広, @kitayama_t/ 2014年9月7日
JPOUG> SET EVENTS 20140907 @IIJ飯田橋公開版資料
1
今日の話題
•自己紹介
• Oracle Databaseの思い出
• ORACLE MASTER
•書籍などの技術情報
•事例紹介：DB移行
•事例紹介：トラブル対応
•事例紹介：パフォーマンスチューニング
2
自己紹介
3
自己紹介• データベースエンジニア。インフラ系全般が範囲。
• 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
自己紹介（社外活動）
技術系雑誌（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
Oracle Databaseの思い出
6
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
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
初めて触れたバージョン
• Oracle 7 1994年～1995年頃
• HP-UX on Serviceguard 7.3.2.1.0
•またWindows Server上ではOracle7 Workgroup ServerをEUC（エンドユーザコンピューティング）向けにDWHを構築した。
• Pro*COBOLでバッチプログラムを書いたりもした。
9
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
Oracle8 Enterprise Edition for HP-UX
• 2000年6月本番のワークフローシステムで使用したバージョン。
•プロジェクト終了後、保守フェーズに入りそのまま基盤運用チームのリーダーを担当。
•夜間障害対応も含めて7年ほど更改まで面倒を見る。
• 8iからインストーラーがGUI必須になったので、CUIベースの一番落ち着いたバージョン。
11
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
Oracle8i Enterprise Edition for Linux R8.1.6
•雑誌の広告
• Miracle LinuxStandard Edition V1.0価格 50,000円出荷日 2000年9月末日
Linux Journalで’Linux Means Business’というスローガンがあったが、本当にそうなってきたと感じた。
13
Oracle DBのマニュアルセット
• Oracle DBのマニュアルセットが数十万円。
•マニュアルと接点を持つことが出来るのがアドバンテージ。自分が見たい時に自由に見れる環境（地位）に所属できるかどうか？
⇒昔はマニュアル一つ取っても限られた人のみアクセス可能であって閉ざされた世界だった。
CD-ROM版のマニュアルが出た時は大喜び。
インターネットでマニュアルを見れるようになった時には時代の変化を感じました。
14
ORACLE MASTER
15
CertViewにログインして取得した資格を確認
ORACLE MASTER（旧制度）
取得資格名 認定日 (当時の年齢)
• 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」と話す。
1990年代終わりから2000年頃の資格の状況
•情報処理技術者試験とベンダー試験の二つの流れがあった。
•オープンソースという言葉自体が定義されたのが1998年で、ベンダー製品（クローズドソース）が全盛期。
•マイクロソフト(MCP)、オラクル(ORACLE MASTER)、シスコ(CCNA)の三大ベンダー試験。
•オープンシステムという言葉が流行って、マイクロソフトのOSのWindows、オラクルのDBのOracle Database、シスコのネットワーク機器が出来ればよいという感じであまり悩みはなかった。
•今はLPICやOSS-DBなどもありますね。
17
http://www.oracle-master.org/
オラクルマスタードットオルグ（OMO）
• 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月からトレーニングや実技試験必須の新制度に移行。
CertViewにログインして取得した資格を確認
ORACLE MASTER（新制度）
取得資格名 認定日 (当時の年齢)
• 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)未受験）
Database Server Internals受講
• 2011年11月～2012年3月の期間、DSIを受講。東京に単身赴任してよかった出来事のうちの最高の一つ。長年の夢が実現。
• Platinum Clubで「Database Server Internalsを受講したい人はリクエストしてね！」というメールが来ると、「参加希望！」と返事。
•ずっと大阪だったので、もし受講となったら1ヶ月有給休暇を取ってでも行こうと思っていた。（現実的にはかなり無理…）
•今までやってきたこと（サポートからのリクエストでの情報収集など）が、なぜそうなのかの仕組みが根本的にわかってすっきり。
22
Software Design 2012年2月号
•第1特集「技術力＋αで勝負！IT市場の転換期を生き抜く」をライターの吉田育代さんが担当。
• OMOの「街で見かけたOMOな方」の時が38歳、このインタビューでは47歳と約10年間経過。
•苦手なことも含めてとても正直に答えたので他社からのスカウトは皆無。（このインタビュー以前から1人だけお声がけしていただいてました）
23
HP Oracle Database Machine
24
書籍などの技術情報
25
帰省先(自宅)で生き残っていた書籍
26
Oracle8の全盛期。
分厚い本が多かった。
Oracleパフォーマンスチューニング
定番のオライリー本、これでDBからのパフォーマンスチューニングの基礎を作った
Oracleパフォーマンスチューニング第2版（1998年6月発売、1074p）
• Oracle8に対応
• スナップショット取得はUTILBSTAT.sql/UTILESTAT.sql
• statspackはまだ無い(Oracle9iで登場）
第2版の前に、少し小さい大きさ（A5判）の第1版があり、それを一通り読んだ
• オラクルパフォーマンスチューニング (A nutshell handbook) 薄緑色
(1994年10月発売、728p)インターナショナルトムソンパブリッシングジャパン
日本の書籍では、入門書は薄っぺらくて範囲が狭く、専門書は深くて説明不足。
この書籍で、入門から上級までわかりやすく全部解説するという書籍の存在を知った。
27
Oracle8 プロフェッショナルテクニック
•インサイトテクノロジーの小幡さんの書いた本。
•データベースブロックとか内部表とか、外に出ていない情報が満載。Oracle Database Internalsという感じの本。
•出版社はソフト・リサーチ・センター、全盛期。
•内部構造がわかることが非常に楽しいのを気付かせてくれた。
• INSIGHT OUT 2011の時にサインもらった。
28
門外不出のOracle現場ワザ
•なぜか書籍化されている門外不出というタイトルの付いた本。
•パフォーマンスチューニング、内部構造、オプティマイザの仕組みなど、大変わかりやすい本で本当に役立った。
•一番お世話になった本だと思う。
29
社内セミナーでの解説
• オラクルコンサルタントが現場で実践した事柄をベースに解説。オプティマイザの解説、統計情報の取り方をどう考えるかのパターンなどこの本にしかない情報が満載。Oracle DB技術者としてあるレベル以上を目指すなら必読の本。
• Ask Tomのトムカイトの著書。
• オライリー本のOracleパフォーマンスチューニングと同様、とても分厚いけど分かりやすく初心者から上級者までの広い範囲でわかりやすく教えてくれる本。
• Apress出版。インターネットでE-booksも簡単に買える。
• 現在は、3rd Editionが発売されている。
• サインもらった。
Expert Oracle Database Architecture 2nd Edition
30
OTN（Oracle Technology Network）
31
• OTN Professionalという有償プログラム。
• OTN Software KitでCD-ROMが送られてきた。
• 開発ライセンスが使えた。
事例紹介（データベース移行）
32
2009年に実施したデータベース移行のお話
データベース移行
2011年3月号の日経SYSTEMSの「成功するデータ移行」に掲載
○概要
システム：インターネット上で旅行サービスを提供、24時間365日。
○相違点
データベースバージョン：9iR2から11gR1
OS：Windows Server から HP-UX
CPU：リトルエンディアンからビックエンディアン
(TTSにおけるクロスプラットフォームは10g以上から)
34
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
データベース移行の要件
•データベース移行に要する時間は７時間以内（６時間以内）とする。
•現行本番データベースに影響を与えないこと。• レプリケーションをするための空きディスク容量無し
• レプリケーションをするためのCPU使用率の余裕なし
•可能な限り安全な方法で移行を行うこと。
•システム切替は一括切替。並行稼働は実施しない。
36
データベース移行のシステム構成
37
SANARENA
P-Vol
既存DBサーバ
Windows2003
Oracle9i
Backupサーバ
Windows2003
SANARENA
S-Vol
H12K
P-Vol
新DBサーバ
HP-UX11iv2
Oracle11g
H12K
S-Vol
Backupサーバ
HP-UX11iv2
中間サーバ
Windows2003
Oracle9i&11g
EVA
移行元データベース 移行先データベース中間データベース
本番NW(100Mbps)
2009年に実施したデータベース移行のお話
データベース移行
○使ったワザ
1. ストレージコピーのバックアップに直接FC接続して読み出し
2. トランスポータブル表領域
3. DataPump
4. ファイル転送用ソフト活用
データベース移行の特徴
• 一括移行方式を採用
• 現行本番機上にある本番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
事前作業 ファイル転送 事後作業Export Import
現行本番環境 新本番環境
•並列処理化•ツール検討
•移行対象絞り込み
•並列処理化•ツール検討
•並列処理化
３処理のパイプライン実行処理
•並列処理化
今回のデータベース移行のステップ
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
SANARENA
P-Vol
既存DBサーバ
Windows2003
Oracle9i
Backupサーバ
Windows2003
SANARENA
S-Vol
H12K
P-Vol
新DBサーバ
HP-UX11iv2
Oracle11g
H12K
S-Vol
Backupサーバ
HP-UX11iv2
中間サーバ
Windows2003
Oracle9i&11g
本番NW(100Mbps)
実データdmpファイル
⑦DataPump Importと従来型Importを実行⑤11gから
DataPump Exportと9iから従来型Exportを実行
EVA
⑥dmpファイル転送
実データdmpファイル
⑧インデックス、制約、トリガー、シーケンスの作成、統計情報の適用
④ 11gDBインスタンス起動、9iDB表領域情報をTTSで11gDBに組み込み
③9iDBインスタンス起動
①DB停止・S-Volにコールドバックアップをsync,split
②FC敷設・結線中間ｻｰﾊﾞ起動
⑨移行データ整合性検証、最終確認
「トランスポータブル表領域 + 従来Export/Import 」方式• 中間サーバからS-Volのrawファイルにてインスタンス起動
42
本番移行時の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
データベース移行で工夫したこと
• ファイル転送は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
ある日突然DBサーバの負荷が高くなる
トラブル事例その１：社内ポータルログイン不可障害
○事象
社内システムの玄関口（ポータル）でユーザ情報を管理しているDBサーバのCPU使用率が高騰し、ログインできない状況となった。
○調べてみると
とある特定のSQL文のCPU使用率と論理読み込みが通常と比べて非常に高くなっていた。一言でいうと、暴走していた。
○とりあえずやった対応
統計情報を新規に取得。暴走していたSQL文は通常に戻った。
ある日突然DBサーバの負荷が高くなる
トラブル事例その１：社内ポータルログイン不可障害
○どのようなSQL文か？
二つのテーブルからJOINするSELECT文。
○実行計画は？
NEST LOOPで、通常時と暴走時では、駆動表が入れ替わっていた。
○統計情報はどのようにしていたか？
デフォルトのまま。つまり、毎日夜に統計情報が自動的に更新。
○統計情報取得の暫定対応
自動実行は停止して、明示的にコマンド実行で取得に変更。
取得サイクルも日次から週次に変更。
ある日突然DBサーバの負荷が高くなる
トラブル事例その１：社内ポータルログイン不可障害
○原因は？
暴走の時の統計情報ではDATE型のとある列(START_DATEとEND_DATE)のヒストグラムが取得されなかったことが原因。
○なぜヒストグラムが取られなかったの？
METHOD_OPT引数の設定値はデフォルトのまま（特に指定せず）。
該当カラムに4000年という現時点とは乖離した日付が入ると、Oracleはヒストグラムを取らない判断をした。そのため、通常とは異なる実行計画となった。（当時は「仕様」という回答が後に来た）
(Bug 9823080 - Incomplete histograms generated)
○暫定対応
FOR ALL COLUMNS SIZE 254と明示的に指定。
とある業務の処理をしようとするとORAエラー発生。
トラブル事例その２：ORA-00054 リソースビジー、NOWAITが指定されていました。
○どのような業務処理か？
不備管理といって、業務処理の書類を点検、訂正する業務
DBのテーブルからデータを取り出して10分以上かかって更新
○原因
DBブロック中のITL領域不足。同時アクセス数より少なかった。
一つ一つのレコードは比較的小さく、1つのDBブロックに15件程度入ってた。初期値からUPDATEでレコード長が大きくなっていった。
○対応
当初ALTER TABLE文でINITRANS値を増やす。既存ブロック変更されず。
⇒結局export/create table/importを実施。
WebのURLを保存したテーブルでインデックスを使ってくれない。
トラブル事例その３：インデックスを使ってくれない。
○DBへの保存形式
VARCHAR2型の列にURLを保存。
○原因
文字列型のヒストグラムは先頭32バイトまでが対象。URLをそのまま保存すると、殆ど同一の値となる。門外不出のヒストグラム説明より。
事例紹介：チューニング
51
実例:システム保守での改善対応
•要求：ディスク高負荷を解消したい
•制約：インデックス付加は不可• アプリ保守が複数の会社で、影響調査・テストが出来ない
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
性能検証/DBパフォーチューで注意すべき点
• (SQL文の)性能検証は本番データ(相当)を使おう。• 負荷性能テストはデータに気をつけよう。開発プロジェクトでは、テストデータの内容が大事。
• データ件数相違：100件と100万件• データ内容相違：100万件でもすべて別々の値か同一かでインデックス使用が異なる。本番と同じばらつきの度合いが必要。• ex. インデックスを使わない!となってデータを調べたら、ログインIDが100万すべて値が1であるとか…
• (SQL文の)性能検証は本番での検索条件を使おう。• 検索条件のバインド変数にどんな値が入るかでインデックス使用有無が変わる。
• 負荷性能検証は本番の検索更新負荷をかけよう。• 実行回数や同時アクセス数等• 実行ごとに検索条件の値を変える (異なるログインID)など
• 統計情報は本番想定できちんと更新しよう。• 統計情報が違うと実行計画が違ってきたりしますので注意。
• ex.データが少ない時に更新して実行計画がインデックスFFS、その後大量データをinsertでCPU張り付き...
53
データと同じぐらい統計情報も大事です。統計情報にはほんと振り回されましたし、今だに振り回されています。
特に開発プロジェクトやテスト環境の性能検証での注意点
ありがとうございました！
54