Oracle:optimizer_mode オプティマイザの判断ミスを疑ってみよう（1/3） － ＠IT

オプティマイザの判断ミスを疑ってみよう（1/3） － ＠IT

２つの最適化の方向性がある。

１．レスポンス重視（最初の数行を返すまでの時間を最適化）
２．スループット重視（最後の行を返すまでの時間を最適化）

Oracle10Gの場合デフォルトは、
optimizer_mode string ALL_ROWS
これは、２．のスループット重視に最適（データフェアハウスやバッチ処理に）

OLTP系のWebアプリはレスポンス重視
→FIRST_ROWS_nを指定
n:1,10,100,1000

詳しくはここを参照
↓
http://otndnld.oracle.co.jp/products/database/oracle10g/performance/htdocs/burleson_cbo_pt1/burleson_cbo_pt1_2.html

Oracleでは、最適な実行計画の定義を選択できる複数のオプティマイザ･モードを用意しています。

* optimizer_mode=first_rows_ このCBOモードは、他の計画に比べ全問合せの実行により長い時間がかかる、またはより多くのコンピューティング資源を使用しますが、可能な限り速く行を戻します。 索引へアクセスすると行を迅速に戻すことができるため、first_rows optimizer_modeでは通常フル・テーブル・スキャンより索引スキャンを選択します。 first_rowsモードでは、フル・テーブル・スキャンより索引スキャンが有効なため、first_rowsモードは、エンド･ユーザーに対して小さな結果セットの高速な表示が必要なOLTPシステムに適しています。

* optimizer_mode=all_rows_ このCBOモードでは、問合せ全体が完了するまで行が戻されませんが、コンピューティング資源全体が最小限に抑えられます。 all_rowsアクセス方法は、全索引スキャンよりパラレル・フル・テーブル・スキャンが有効な場合が多く、索引経由の事前ソートの取得よりソートが選択されます。 フル・テーブル・スキャンが有効なall_rowsモードは、リアルタイム表示のための中間の行が不要なデータ･ウェアハウス、意思決定システムおよびバッチ指向のデータベースに適しています。

* optimizer_mode=first_rows_nこのOracle9i Databaseオプティマイザ・モードの拡張機能は、予期された小さなリターン･セットの問合せを最適化します。 値はfirst_rows_1、first_rows_10、first_rows_100およびfirst_rows_1000です。 CBOは、問合せ結果セットのカーディナリティを判断するための重要なドライバとしてfirst_rows_nのnを使用します。 CBOに事前に問合せから特定の行を戻す指定をすることで、CBOは表の行にアクセスするために索引を使用するかどうかをより的確に判断できます。

* Optimizer_mode=ruleルールベース・オプティマイザ（RBO）は、Oracleデータベースの初期リリースからの古いオプティマイザ･モードです。ルールベース・オプティマイザは、約10年更新されておらず、RBOは1994年以降のOracleの新機能（ビットマップ索引、表パーティションおよびファンクション・ベースの索引など）をサポートしないため、本番使用はお薦めしません。

Oracle:[Oracle] インデックスに関するコスト計算の調整によるオプティマ�

[Oracle] インデックスに関するコスト計算の調整によるオプティマ�

OPTIMIZER_INDEX_CACHING
インデックス・ブロックが何％くらいバッファ・キャッシュに存在すると仮定するかを示します。0～100の範囲で指定し、デフォルトは 0 となっています。この値を高くすればするほど、インデックスのキャッシュヒット率が高いものとみなされ、インデックス・スキャンのコストが低く見積もられるようです。
OPTIMIZER_INDEX_COST_ADJ
インデックス・スキャンのコストを標準のコストの何％で計算するかを示します。0～100の範囲で指定し、デフォルトは100となっています。この値を小さくすればするほど、インデックス・スキャンのコストが低く見積もられるようです。

デフォルト値は、データフェアハウス系システムには最適
一般的なOLTPでは、次の値を目安にすると良い（Oracle現場ワザから）

OPTIMIZER_INDEX_CACHING=90
OPTIMIZER_INDEX_COST_ADJ=25

索引を作ったけど、フルテーブルスキャンの発生率が高いことが問題視されている場合に良い

Oracle：データベースを起動後に、spfileを使って起動したか、pfileを使って起動したのかを調べる手段

SQLPLUSから
show parameter spfile
を実行する

pfileを使用している場合には、show parameter spfileの結果が出力されない。

Oracle:初期化パラメータのまとめ

＠IT：Oracle管理者のためのSQLリファレンス

以下のようにすることで、Oracleのパラメータを一括で取得する
・OracleParameter一括取得=========
spool xx_parameters.txt
select to_char(sysdate,'yyyy/mm/dd hh:mi:ss') パラメータ値取得時間 from dual;
show parameters;
spool off

==================================

Linux:rinn@wiki - Linux 最大ファイルディスクリプタの数を変更する

rinn@wiki - Linux 最大ファイルディスクリプタ設定

echo "65536 " > /proc/sys/fs/file-max
または
# sysctl -w fs.file-max=65535
<確認>
# sysctl -a | grep file-max

経営戦略入門: 流動性の罠

経営戦略入門: 流動性の罠: "流動性の罠"

金利を下げても、金融政策が機能しなくなる減少を「流動性の罠」と経済学
では呼ばれる。
つまり、金利が低く、景気が回復する見込みが無いと判断すると、人は金を
使わずに溜め込むのだ。（長期的に利子率が下がりきるのを債券相場が天井
に達し、誰も債権を買わなくなる）
現金が結局流動性が最も高いので、金を使わず、現金として溜め込む。

三面等価の原則 ～ インフォバンク マネー百科

三面等価の原則 ～ インフォバンク　マネー百科

GDPは、生産面、分配面、支出面の３つの観点から計算されるが、
この3つは統計上必ず一致する。

GDP
＝総生産額-中間投入額
＝所得の合計
＝最終需要の合計

Oracle:db_block_size

db_block_size


Operating system block size. Good performance can be achieved by ensuring that the Oracle block size is equal to or a multiple of the operating system block size. If this is not the case, the OS may end up performing extra reads and writes during the processing of Oracle blocks, resulting in wasted CPU cycles.See finding block size
♦ Size of buffer cache used. Larger database block size means that you are using up more memory for the same number of db_block_buffers. This also means that more rows are cached. If your rows are small and you use a large block size, a block fetch will result in a lot of rows being fetched (and you may not be interested in all of them). The end result is that the OS is doing more work to fetch things that you don't need. On the other hand, if the row length is large, a large block size may prevent chaining.
♦ Balancing of index branches. Large Oracle block sizes can result in better index balancing, as there are more rows in each branch. A bigger block size means more space for key storage in the branch nodes of B-tree indexes, which reduces index height and improves the performance of indexed queries.


>See finding block size
# df -g | grep "block size" -- to display O/S block size in bytes in Solaris. For Linux run dumpe2fs ( must be root ).
# grep /usr/include/sys/param.h file (NOTE 1024 is the default for DEV_BSIZE)

Oracle:データブロックサイズの選定 - オラクル・Oracleをマスターするため

データブロックサイズの選定 - オラクル・Oracleをマスターするため

データブロックが小さいことによるメリット

* インデックス経由の単一のブロック IO が速い
* 同一ブロックでのトランザクションの競合が起こりにくい
⇒ Interested Transaction List 参照

逆にデータブロックが大きい場合に得意なことは苦手となる。

データブロックを小さくする場合の注意点
行移行、行連鎖を避けるのは優先事項である。この状態になっているデータブロックは、ブロック IO 性能、更新性能、同時実行性能の各性能を低下させる要注意なブロックである。

データブロックが大きいことによるメリット

* テーブルフルスキャンが速い
* 格納効率が良い
* COMPRESS(※) の効果が高い

逆にデータブロックが小さい場合に得意なことは苦手となる。

(※) COMPRESS とは表のデータをブロック完結型の圧縮方式で圧縮する機能、表の再構築やダイレクト･パス･インサートで表データを作成した場合にだけ行われる。 ALTER TABLE にて設定を変更しても既存のデータは圧縮されないので ALTER TABLE ～ MOVE で再作成の必要がある。
但し 256 以上のカラムをもつテーブルにはその効果がない。おそらく行連鎖、プロック内連鎖している行も同じ物理配置になっているであろうから、その仕組み上圧縮できないと考えられる。

Oracle:I/O構成および設計

I/O構成および設計

データ・ブロック・サイズの選択

8KBのブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTPシステムではより小さなブロック・サイズを、DSSシステムではより大きなブロック・サイズを使用することがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・サイズを選択するときの考慮事項を説明します。

注意:

管理性の問題があるため、単一データベース・インスタンスでの複数のブロック・サイズの使用はお薦めしません。
読込み

データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読込み回数を最小にすることです。

* 行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択します。

* 行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択します。

* 行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選択するのが有効です。

* 行が大きい（たとえば、ラージ・オブジェクト（LOB）データが含まれている）場合は、大きなブロック・サイズを選択します。