Oracle:Document Library 10g 11g

Oracle Database オンライン・ドキュメント 11g リリース1（11.1）

日本語
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/index.htm
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/index.htm

英語
http://www.oracle.com/pls/db111/homepage
http://www.oracle.com/pls/db102/homepage

OracleCoding Tips － コネクション・プーリングのメリットデメリット

Coding Tips － コネクション・プーリングを利用するには

メリット：
CPU使用量や応答時間におけるコストが高い

デメリット：
メモリリソースを無駄に消費する


コネクションプーリングに付随する技術
・文キャッシュ
・共有サーバ構成、専用サーバ構造
共有サーバ構成は、ディスパッチャが共有サーバとの通信を中断し、SQL単位で共有サーバへ処理を振り分ける
共有サーバ構成でコネクションプール管理をモジュールに当たるのがディスパッチャである
→ディスパッチャは接続形態が専用サーバ構成とは異なり複雑です。
同一のセッションでも異なる共有サーバにまたがって処理が行われるためSQLトレースなどを取得して分析を行うなどの作業も困難となる。
そのため、アプリケーション側にコネクションプーリングが実装されることの多い現在ではほとんど使用されず、まれに大量のアイドル接続が存在するときや、物理接続の生成切断が頻繁に行われる場合に、コネクションプーリングと併用される程度。
→コネクションプーリングが使用されない場合は有効だが

・OCIコネクションプーリング

・Oracle Connection Cache

★WebLogicのJDBCプーリングは最大接続を超える場合は我慢型
→待ち行列の監視が必要
HighestNumWaiters
ConnectionReserveTimeoutSeconds
InactiveConnectionTimeoutSeconds

自動SQLチューニング

自動SQLチューニング: "自動チューニング・オプティマイザ"

自動チューニング・オプティマイザ

Oracle:動的サンプリング - オラクル・Oracleをマスターするための基本と仕

動的サンプリング - オラクル・Oracleをマスターするための基本と仕

■必要なし
1秒未満の高速なレスポンスが要求される
短期間で大きくデータが変更することのないシステム

■価値のある代表例
・TemporaryTableに対するアクセス
→動的サンプリングは最適！！！
・単一表の列堂氏に相関関係がある場合
→DWH

サンプリング・レベル
サンプリングレベルは OPTIMIZER_DYNAMIC_SAMPLING 初期化パラメータの値 または、
SQL に記述される /*+ DYNAMIC_SAMPLING(table_spec sampling_level) */ といったヒント句によって指定する。

Oracle:統計情報の戻し

統計情報の取得と実行計画の固定について - SQL> shutdown abort

user_tab_stats_historyを見れば、いつ統計情報取得のJOBがながれたか
select * from user_tab_stats_history order by stats_update_time

統計情報をリストアするには、
exec dbms_stats.restore_schema_stats
を使用する

Oracle:統計情報の自動収集 メンテナンス・ウィンドウを使用した自動システム・タスクの�

メンテナンス・ウィンドウを使用した自動システム・タスクの�: "自動統計収集ジョブ

Oracle10gでは、DBを作成するとデフォルトで
GATHER_STATS_JOB
と呼ばれる自動収集のためのスケジューラジョブが準備される。

■確認方法
select job_name,program_name, schedule_name, stop_on_window_close from dba_scheduler_jobs where JOB_NAME LIKE 'GATHER%'
→結果：
GATHER_STATS_JOB GATHER_STATS_PROG MAINTENANCE_WINDOW_GROUP TRUE

実際に実行されるストアドプロシージャは以下の通り
select * from dba_scheduler_programs where program_name = 'GATHER_STATS_PROG'

・スケジュールが、MAINTENANCE_WINDOW_GROUPとは？
select * from dba_scheduler_wingroup_members
→MAINTENANCE_WINDOW_GROUP WEEKNIGHT_WINDOW
MAINTENANCE_WINDOW_GROUP WEEKEND_WINDOW

select window_name, repeat_interval, duration from dba_scheduler_windows
→WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 0 8:0:0.0
WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 2 0:0:0.0

■自動統計時間にかかった時間を確認
select job_name, actual_start_date, run_duration from dba_scheduler_job_run_details
where job_name = 'GATHER_STATS_JOB'
→run_durationをみれば、どのくらい時間がかかったかわかる

★自動統計収集のメリット
・スケジュール済みなので、不注意による統計の取り忘れがなくなる
・ある程度変更があった表のみ統計が再収集されるため、１回の統計収集の負荷は最小限である
・内部的に記録した列の使用状況に基づいて網羅的に統計収集されるため、開発者が必要性に気付かなかった列にもヒストグラムが作成され、実行計画の精度が高くなる
・統計収集はウィンドウの範囲内でしか実行されないため、時間帯を区切った運用がしやすい

★実運用を考えると？
・スケジューラウィンド設定を変更し、オンライン時間帯やバッチ時間帯と重ならないようにすること
・バッチ処理後に統計情報をとる
・例外として、複雑な問い合わせを実行するようなバッチの場合は、バッチ実行前に統計情報をとる
・ウィンドウのオープン期間を短くしすぎない。サイズの翁オブジェクトの統計収集が期間何に完了しなくなる可能性がある

★自動統計収集のデメリット
・実際には必要のないオペレーションの可能性がある
→とはいえ、それが自動統計収集の本質であり、無駄であろうとも機械的に情報を収集して陳腐化を防ぐアプローチが重要

★自動統計収集の監査
--30日以上統計収集されていない表の確認
select * from user_tables where last_analyzed is not null
and last_analyzed < trunc(sysdate) -30
order by last_analyzed

--全く統計収集されていない表の確認
select * from user_tables where last_analyzed is null



スケジューラ・ジョブGATHER_STATS_JOBは、Oracle Databaseのインストール時に事前定義されます。 GATHER_STATS_JOBは、データベース内で、統計がないかまたは失効した統計のみがあるすべてのオブジェクトのオプティマイザ統計を収集します。

統計収集を手動で管理するほうがよい場合は、次のように、このスケジューラ・ジョブを使用禁止にします。

EXECUTE DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');

ONにする場合は
EXECUTE DBMS_SCHEDULER.ENABLE('GATHER_STATS_JOB');
とする

Oracle:CBOはどの情報を元に実行計画を決めるのか - SQL> shutdown abort

CBOはどの情報を元に実行計画を決めるのか - SQL> shutdown abort

--システムレベルの設定値
select * from v$SYS_OPTIMIZER_ENV order by name


--セッションごとの設定値
select * from v$SES_OPTIMIZER_ENV order by name


--SQLごとの設定値
select * from v$SQL_OPTIMIZER_ENV order by name

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）データが含まれている）場合は、大きなブロック・サイズを選択します。

PMBOK:リスク管理：プロジェクトマネジメントスキル 実践養成講座（8）

プロジェクトマネジメントスキル 実践養成講座（8）


回避 ・原因を根本的に取り除き、リスク事象が現実のものとならないようにすること。
・先述の例では、リスクとはテストができないことであり、回避とはI/Fプログラムを使ってテストできるようにすることである。
・具体的な対応策としては、例えば先方の開発が完了してからテストを実行するようリスケジュールを行う、あるいは先方に作業の優先度を上げてもらうことで、予定どおりにテストが実施できるようにするなどが考えられる。
軽減 ・リスクが現実化した場合に影響を小さくする、リスクの発生確度を下げるという2つの軽減策が考えられる。
・先述の例は、マニュアルで作ったI/Fファイルを用いてテストを実行しておくことで、全体への影響を小さくする軽減策である。
移転（転嫁） ・リスクも含めて第三者に責任の所在を移転すること。
・実際のプロジェクトでの活用法としては、外部へのアウトソーシングや保険への加入などが挙げられる。
・ただし、契約により責任を第三者に移転したとしても、金銭的な補償やさらなる人的支援など、契約に基づく責任の遂行にとどまることが多い。
・いい換えれば、責任を移転してもリスク自体は依然として残っており、リスクが現実化した場合に発注者（依頼側）への影響がゼロになるわけではないことを認識する必要がある。
受容 ・プロジェクト計画を変更しないこと。つまり、「何もしない」という決定を下すこと。
・リスクが現実化しても影響が少ない場合や発生確度が無視できるほど小さい場合、あるいはほかの対応策を見つけることができなかった場合に、リスクを受容することになる。
・また、リスクの現実化に備えて、コンティンジェンシープランを作成することも多い。

Oracle:DB-カーディナリティ

カーティナリティとは、"集合の要素の数・基数"である。
どれだけのキーの種類があるか、キーの偏りはないかといったことである。
キーの種類が多い場合を"カーディナリティが高い"、
キーの種類が少ない場合を"カーディナリティが低い"と表現する。

たとえば、社員コードは普通、全て一意性があるので"カーディナリティが高い"。
では、社員マスターの性別は男と女だけなので、"カーディナリティが低い"。

■カーディナリティのチェック方法

SQL>SELECT COUNT(*) from TABLE_A;
(全件件数を確認)
SQL>SELRCT COL1,COL2,COUNT(*) FROM TABLE_A GROUP BY COL1,COL2;
(キー種類数を確認)

キー種類数 / 全件件数 = カーディナリティ


この時の結果が30%以上のような場合は、意味の無い(負荷の低減どころか、負
荷を増加させている)インデックス利用といったことになる。

FW:RASISとは レイシス： - IT用語辞典バイナリ

RASISとは レイシス： - IT用語辞典バイナリ

http://q.hatena.ne.jp/1071039552

Reliability　＝　結果が正確であること，エラーが起こらないこと
Availability　＝　システムダウンが起こらないこと
Serviceability　＝　メンテナンスやリペアなどの保守に必要な工数が少ないこと
Integrity　＝　外部から干渉をうけないこと
Security　＝　自然災害や不正なアクセス，情報漏えいの対策がとられていること

Reliability：信頼性＝障害が発生しないこと。
Availability：可用性＝使用可能な状態であること。
Serviceability：保守性＝保守が容易であること。
Integrity：保全性＝他から干渉されないこと。
Security：安全性＝災害などから安全であること。

Linux:I/Oスケジューラ

カーネル2.6.10からいか4種類のI/Oスケジューラを選択できるようになった。
（それ以前は、”エレベータ”のみ）

	I/Oスケジューラ	説明
1	deadline	読み込み処理と書き込み処理の両方をバランスよく処理することに長けておりRDBMSに最も向いている
2	noop	特別なスケジューリングをしないため、オーバーヘッドは非常に小さい。高性能なストレージ製品やSSDのようなシーク待ちの発生しないストレージに向いている
3	anticipatory	将来的に発行されるI/Oを予測するｌｐｔｐで。シーク待ち時間を小さくする
4	cfq	I/O要求の偏りを防ぐスケジューラ。デスクトップ環境のように多数のアプリを常時起動させておくような環境で効率的。多くのディストリビューションでデフォルト

その他参考URL
http://itpro.nikkeibp.co.jp/article/COLUMN/20080613/308032/?ST=lin-os&P=4

Linux:4.メモリ使用率(第5章 パフォーマンス管理～上級:基本管理コースII)

4.メモリ使用率(第5章 パフォーマンス管理～上級:基本管理コースII)

vmstat
等の説明

Oracle:＠IT：Oracle管理者のためのSQLリファレンス-索引の確認／作成／削除

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

SELECT * FROM user_indexes;
SELECT * FROM user_ind_columns;

Oracle:＠IT：Oracle管理者のためのSQLリファレンス-制約の確認／作成／削除

＠IT：Oracle管理者のためのSQLリファレンス: "制約の確認／作成／削除"

SELECT * FROM user_constraints;
-- または
SELECT * FROM all_constraints;
-- または
SELECT * FROM dba_constraints;

Oracle:代表的なヒント句

ヒント句の使い方：SELECTの後に”/*+ ”を書き、”*/”で閉じる

・INDEX：インデックスを使って処理する
select /*+ index(aidx) */ con1 from tbl1 where a = 'x'

・FULL：表をフルスキャンする
　
・ORDERED：複数表を結像している場合、表の処理の順序をFROM句の順番どおりにする

・USE_NL：Nested Loop結合プランにする。インデックスを使用した結合向き。

・USE_HASH：ハッシュ結合結合プランにする。大量データを扱う結合向き

・INDEX_ASC,INDEX_DESC：インデックスを使用して、降順・昇順にデータを検索する

・LEADING：結合順序の最初の表を指定する

その他は＞
http://www.atmarkit.co.jp/fdb/rensai/orasql03/orasql03_3.html

例）
SELECT /*+ LEADING(d e)
INDEX(d dept_ix2)
INDEX(e emp_ix1)
USE_NL(e) */
empno,ename,job
FROM emp e, dept d
WHERE e.deptno=d.deptno
AND d.dname = 'RESEARCH'
ORDER BY empno;

Oracle:おら! オラ! Oracle - どっぷり検証生活メールマガジン - バックナンバー

おら! オラ! Oracle - どっぷり検証生活メールマガジン - バックナンバー

おら! オラ! Oracle - どっぷり検証生活

Oracle:門外不出のOracle現場ワザ

門外不出のOracle現場ワザ

Oracleにて順次公開拡大

Oracle:Oracle9i ステップマスター

Oracle9i ステップマスター-Oracleのサンプルスキーマ

Oracleのサンプルスキーマは以下５つ

# Human Resources（HR）スキーマ
従業員、部門、職種などの人事関係のデータの取り扱いを定義したものです。

# Order Entry（OE）スキーマ
製品や顧客の情報、製品の受注に関するデータの取り扱いを定義したものです。

# Sales History（SH）スキーマ
後に意思決定を支援するレポートや分析を行うために蓄積しておきたい業務上のさまざまな履歴に関するデータの取り扱いを定義したものです。

# Product Media（PM）スキーマ
販売促進用に利用する画像や音声といったさまざまなタイプのデータの取り扱いを定義したものです。

# Queued Shipping（QS）スキーマ
各部門間での、注文情報のやりとりを定義したものです。
→11gでは？

整理：顧客に提供したファイルには

●
をつける。BY会社の達人

Oracle:Oracle JDeveloperでERD作成

Oracle JDeveloperを使用したデータベース開発: "HR"

Oracle JDeveloperでERD作成