設計から運用まで、気をつけるべきことが網羅されている『教科書』と感じます。リファレンス的なものを想像するとちょっと違うかも。
内容は親切で、経験が浅い人にはおすすめできます。
この商品をお持ちですか?
マーケットプレイスに出品する
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません 。詳細はこちら
Kindle Cloud Readerを使い、ブラウザですぐに読むことができます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
SEのためのOracleチューニングハンドブック 単行本(ソフトカバー) – 2003/11/17
チューニングのキーポイントはこれだ!
データベースシステムとしてOracleを導入するとき、SEが考えなければならないチューニングのポイントを開発工程(要件定義、基本設計、詳細設計、開発、導入、パフォーマンスチューニング)にそって解説。現場で役立つシステムチューニングバイブル。
データベースシステムとしてOracleを導入するとき、SEが考えなければならないチューニングのポイントを開発工程(要件定義、基本設計、詳細設計、開発、導入、パフォーマンスチューニング)にそって解説。現場で役立つシステムチューニングバイブル。
- 本の長さ328ページ
- 出版社ソフトバンククリエイティブ
- 発売日2003/11/17
- ISBN-104797323132
- ISBN-13978-4797323139
商品の説明
商品説明
往々にして、システム開発においてパフォーマンスチューニングが話題となるのは、運用開始後に問題が発生したとき、もしくは試験時に充分なパフォーマンスが得られなかったときが多い。「後からパフォーマンスチューニングを行えば何とかなる」という考えが蔓延している場合すらある。もちろん、パフォーマンスチューニングの意味するところとして、悪いパフォーマンスを改善するという作業が含まれるのは否定しないが、後付けで考えればよいものではないのだ。
本書はOracle上でのパフォーマンスチューニングを開発の各フェーズ、すなわち要件定義、基本設計、詳細設計、開発、導入・移行、性能検証のそれぞれにおいて何を考えればよいか、そして開発以降のフェーズにおいては投入するコマンドなどの具体的な対策が例示される。特に設計フェーズではデータベースのアーキテクチャと、押さえておかなければならない与件を詳細に解説しており、すぐにでも実務に応用できるだろう。また、各フェーズの存在意義、行うべきことまでを掘り下げて解説しており、それらを再度確認することで、パフォーマンスチューニングについてもより深く理解できる。
使用データベースがOracleという前提で書かれているが、単にパフォーマンスの手法だけではなく、それを考慮、採用する理由が具体的に書かれているため、他のデータベースを使用している開発者にも是非一読をおすすめしたい。(大脇太一)
内容(「BOOK」データベースより)
知りたいのは要点だけ。長い解説は要らない。チューニングのポイントだけをさっと引ける本が欲しい。仕事に追われているSEのための、本当に役に立つチューニング解説書登場。
内容(「MARC」データベースより)
データベースシステムとしてOracleを導入するとき、SEが考えなければならないチューニングのポイントを開発工程(要件定義、基本設計、詳細設計、開発、導入・移行)に沿って解説。現場で役に立つ!
Kindle化リクエスト
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
このタイトルのKindle化をご希望の場合、こちらをクリックしてください。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
登録情報
- 出版社 : ソフトバンククリエイティブ (2003/11/17)
- 発売日 : 2003/11/17
- 単行本(ソフトカバー) : 328ページ
- ISBN-10 : 4797323132
- ISBN-13 : 978-4797323139
- Amazon 売れ筋ランキング: - 713,811位本 (の売れ筋ランキングを見る本)
- - 661位データベース処理
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。

著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
5つ星のうち3.5
星5つ中の3.5
9 件のグローバル評価
評価はどのように計算されますか?
全体的な星の評価と星ごとの割合の内訳を計算するために、単純な平均は使用されません。その代わり、レビューの日時がどれだけ新しいかや、レビューアーがAmazonで商品を購入したかどうかなどが考慮されます。また、レビューを分析して信頼性が検証されます。
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2014年12月29日に日本でレビュー済み
違反を報告する
Amazonで購入
1人のお客様がこれが役に立ったと考えています
役に立った
2011年9月12日に日本でレビュー済み
Amazonで購入
速いsqlを書くための実践的な方法
1 .不必要なソート、グループ化を避ける
1-1.Distinct句はExists句で代替する
理由)Distinct句は条件に一致する行を取り出し、暗黙のソート処理を行った後で重複行を取り除くため負荷が大きい。対してExists句は条件に一致する行が1件でもあれば以後の取り出しを行わないため負荷が小さい。
なお、Exists句は下記の書き方が速い。
EXISTS (SELECT * FROM …)
行へのポインタさえ得られれば、実際の行を読む必要がないことを、DBMS に明示してやる効果があるため。
1-2.Not In句はNot Exists句で代替する
理由)Not In句は内部でソートマージ結合が発生するため負荷が大きい。これに対しNot Existsは条件に一致する行が1行でもあれば以後の取り出しを行わないので負荷が小さい。
1-3.Union句はUnion All句で代替する
理由)Union句は取り出したすべての行に対してソートとマージを行い、重複行を取り除くため、負荷が大きい。これに対してUnion All句は取り出したすべての行を単純に返すため、負荷が小さい。
1-4.Having句はWhere句で代替する。
理由)Having句はすべての行を取り出した後で条件に一致する行を取り出す。これに対しWhere句は条件に一致する行だけを取り出すので負荷が小さい。
2 .索引の利用
索引を無効とする書き方を避ける。全表走査は特殊な場合(表が小さい、表全体の行数に対して問い合わせる行数の割合が多い)を除くと遅い。
2-1.索引列に対する加工の回避
理由)索引列に計算や連結sql関数の適用などがされている場合は索引が利用されない。
2-2.索引列に対する否定条件(<>, NOT EQUAL, NOT IN)の回避
理由)オプティマイザが全表操作を実行してしまう。
2-3.索引に対するNull条件の回避
理由)B*Tree索引においては、索引データにNullを含まないための評価が行えず索引は利用されない。ビットマップ索引の場合はこの限りではない。
2-4.索引列に対する中間一致検索と後方一致検索の回避
理由)前方一致検索のみ索引が利用される。
2-5.複合索引の利用
理由)データ操作量を減少させることが出来る。Where句で指定する場合は指定順序に注意すること。指定順序は索引の作成順でなければならない。
2-6.主キー索引の利用
理由)Count関数利用時には主キーを指定すると高速化できる。
2-7.索引を利用したソート
理由)OrderBy句に指定されている列がすべて索引列であり、かつNotNull制約か主キー制約である場合実際のソートを回避することが出来る。
2-8.ヒントの利用
理由)sqlにヒントを指定してオプティマイザの実行計画を意図的に制御することが出来る。
3 .Rowid疑似列を利用する
3-1.Rowid疑似列を利用する
理由)全データベースで一意に識別される列であるため、高速で検索が行われる
3-2.RowNum疑似列の利用
理由)RowNum疑似列はSelect結果の各行に対して振られる番号である。効率よくレコードにアクセスできる。
1 .不必要なソート、グループ化を避ける
1-1.Distinct句はExists句で代替する
理由)Distinct句は条件に一致する行を取り出し、暗黙のソート処理を行った後で重複行を取り除くため負荷が大きい。対してExists句は条件に一致する行が1件でもあれば以後の取り出しを行わないため負荷が小さい。
なお、Exists句は下記の書き方が速い。
EXISTS (SELECT * FROM …)
行へのポインタさえ得られれば、実際の行を読む必要がないことを、DBMS に明示してやる効果があるため。
1-2.Not In句はNot Exists句で代替する
理由)Not In句は内部でソートマージ結合が発生するため負荷が大きい。これに対しNot Existsは条件に一致する行が1行でもあれば以後の取り出しを行わないので負荷が小さい。
1-3.Union句はUnion All句で代替する
理由)Union句は取り出したすべての行に対してソートとマージを行い、重複行を取り除くため、負荷が大きい。これに対してUnion All句は取り出したすべての行を単純に返すため、負荷が小さい。
1-4.Having句はWhere句で代替する。
理由)Having句はすべての行を取り出した後で条件に一致する行を取り出す。これに対しWhere句は条件に一致する行だけを取り出すので負荷が小さい。
2 .索引の利用
索引を無効とする書き方を避ける。全表走査は特殊な場合(表が小さい、表全体の行数に対して問い合わせる行数の割合が多い)を除くと遅い。
2-1.索引列に対する加工の回避
理由)索引列に計算や連結sql関数の適用などがされている場合は索引が利用されない。
2-2.索引列に対する否定条件(<>, NOT EQUAL, NOT IN)の回避
理由)オプティマイザが全表操作を実行してしまう。
2-3.索引に対するNull条件の回避
理由)B*Tree索引においては、索引データにNullを含まないための評価が行えず索引は利用されない。ビットマップ索引の場合はこの限りではない。
2-4.索引列に対する中間一致検索と後方一致検索の回避
理由)前方一致検索のみ索引が利用される。
2-5.複合索引の利用
理由)データ操作量を減少させることが出来る。Where句で指定する場合は指定順序に注意すること。指定順序は索引の作成順でなければならない。
2-6.主キー索引の利用
理由)Count関数利用時には主キーを指定すると高速化できる。
2-7.索引を利用したソート
理由)OrderBy句に指定されている列がすべて索引列であり、かつNotNull制約か主キー制約である場合実際のソートを回避することが出来る。
2-8.ヒントの利用
理由)sqlにヒントを指定してオプティマイザの実行計画を意図的に制御することが出来る。
3 .Rowid疑似列を利用する
3-1.Rowid疑似列を利用する
理由)全データベースで一意に識別される列であるため、高速で検索が行われる
3-2.RowNum疑似列の利用
理由)RowNum疑似列はSelect結果の各行に対して振られる番号である。効率よくレコードにアクセスできる。
2006年3月16日に日本でレビュー済み
弊社の人事給与システムなどで、チューニング作業を
行いましたが、非常に難しい作業です。
問題点がどこにあるのか、DB側かアプリ側なのか
の判別もそうですが、DB側の場合、まず何をすれば
いいのか。本書では、優先順位をまとめて
書いてありますので、手詰まりになったとき(パニクってるとき)
非常に助かります。
私の経験では、Oracleはマニュアルのスポーツカー
SQLServerは、オートマのファミリーカーといったところでしょうか。
Oracleはスポーツカーのように、ドライバーの腕で
早くも遅くもなります。
ぜひ買ってみてください。
行いましたが、非常に難しい作業です。
問題点がどこにあるのか、DB側かアプリ側なのか
の判別もそうですが、DB側の場合、まず何をすれば
いいのか。本書では、優先順位をまとめて
書いてありますので、手詰まりになったとき(パニクってるとき)
非常に助かります。
私の経験では、Oracleはマニュアルのスポーツカー
SQLServerは、オートマのファミリーカーといったところでしょうか。
Oracleはスポーツカーのように、ドライバーの腕で
早くも遅くもなります。
ぜひ買ってみてください。
殿堂入り
チューニングという作業は、システム開発のどの段階で、何をすることなのか?Oracleの仕組み、チューニングのテクニック等です。
チューニングのテクニックがメインです。SQLのチューニングのテクニック、パフォーマンス情報の取得、メモリ、IOのチューニングを具体的に、何をどうするか?が解説してあります。
どのようなSQLやメモリ構成ならよいか、現状をどうやって調べるか?改善するためには、どうすれば良いか、OLTP系のシステムなら、どうか、等が具体的に書いてあり、個人的にはかなり役立ちました。
JOINの仕組み、OracleのSQL実行の仕組みなど、基本的なことろから解説してあるので、Oracleあんまり知らなくても読めました。
基本的に、Oracle9iR2 対応です。が、「R9から、新しくでました」とか「8iならこうです」という記述も多く、9i以外のバージョンでも役立つと思います。
最後のAppendeixに、Oracleの主な、初期化パラメータと、設定値の推奨があり、これまた、チェックリストとして役立ちました。
本の厚さのわりには、情報量も多かった印象です。読んで、ありがとう、ございました!と思わせる本でした。
チューニングのテクニックがメインです。SQLのチューニングのテクニック、パフォーマンス情報の取得、メモリ、IOのチューニングを具体的に、何をどうするか?が解説してあります。
どのようなSQLやメモリ構成ならよいか、現状をどうやって調べるか?改善するためには、どうすれば良いか、OLTP系のシステムなら、どうか、等が具体的に書いてあり、個人的にはかなり役立ちました。
JOINの仕組み、OracleのSQL実行の仕組みなど、基本的なことろから解説してあるので、Oracleあんまり知らなくても読めました。
基本的に、Oracle9iR2 対応です。が、「R9から、新しくでました」とか「8iならこうです」という記述も多く、9i以外のバージョンでも役立つと思います。
最後のAppendeixに、Oracleの主な、初期化パラメータと、設定値の推奨があり、これまた、チェックリストとして役立ちました。
本の厚さのわりには、情報量も多かった印象です。読んで、ありがとう、ございました!と思わせる本でした。