ITIL：＠IT：SLAとサービスレベル管理

＠IT：SLAとサービスレベル管理

* サービスレベルを上げるためにはコストも上がる
* サービスレベルとコストは単純な比例関係ではない

5分で絶対に分かるITIL － ＠IT情報マネジメント

5分で絶対に分かるITIL － ＠IT情報マネジメント:

ITILでは、
プロセス（Process）★★
ピープル（People）★★★
プロダクト（Product）★
の「3つのP」が重要（重要度★）

Gmailが落ちたときに“アクセス”する方法を考える － ＠IT自分戦略

Gmailが落ちたときに“アクセス”する方法を考える － ＠IT自分戦略:

以下どれかのURL経由だと、Gmailが落ちてもメールがみられるかもしれない。

"ログインURL 備考
1 http://gmail.com/ 非SSL
2 http://mail.google.com/mail/ PC用URL。非SSL
3 https://mail.google.com/mail/ PC用URLのSSL版
4 https://mail.google.com/mail/?ui=1 旧バージョンを表示するURL
5 https://mail.google.com/mail/?ui=2 新バージョンを表示するURL
6 http://mail.google.com/mail/h/ 簡易バージョン。Ajax未対応ブラウザ用
7 https://mail.google.com/mail/h/ 簡易バージョンのSSL版
8 http://m.gmail.com/ モバイル用。非SSL
9 https://mail.google.com/mail/x/ モバイル用のSSL版
10 http://mail.google.com/mail/x/gdlakb-/gp/ iPhone用
11 https://mail.google.com/mail/x/gdlakb-/gp/ iPhone用のSSL版
12 https://mail.google.com/mail/feed/atom/ Atomフィード版"

Oracle:SQLチューニングの基盤となる統計情報（4/4） － ＠IT

SQLチューニングの基盤となる統計情報（4/4） － ＠IT: "SQLチューニングの基盤となる統計情報"

遅いSQLは、
SET AUTOTRACE ON
で確認せよ。

■SQL統計情報の基本的な見方

まずは、
・consistent gets：SQLが検索のためにアクセスしたブロック数
　　　　　　　　　→実行に費やすCPU時間はほぼこれに比例する
・physical reads：ディスクから読み込んだブロック数
を見る。

その後
・recursive calls：再帰SQLの実行を見る。
何回か同じSQLを実行しても、この値が大きい場合は、バッファキャッシュを使い果たしている
可能性が高い。

Linux:ユーザアプリ使用メモリサイズ

Linux、負荷まわりの話 - goungoun技術系雑記帳:
"ユーザアプリ使用メモリサイズ＝
MemTotal
-MemFree
-Buffers
-Cached
-SwapCached
-Slab
-PageTables
-VmallocUsed
"

Linux ページキャッシュ - naoyaのはてなダイアリー

Linux のページキャッシュ - naoyaのはてなダイアリー

* Linux はメモリがある限りページ単位でブロック型デバイスの入出力をキャッシュする
* I/O はページキャッシュに任せよう
* ページキャッシュの状態は sar -r で確認できる
* DB はメモリにフィットさせよう (http://d.hatena.ne.jp/stanaka/20070427/1177651323)
* ページキャッシュがクリアされてしまったら read してキャッシュに載せよう
* VFS 周りの実装はインタフェースにコールバックを登録していく実装になっている
* tmpfs は read / write が tmpfs 用に実装されている。I/Oに伴うページキャッシュの扱いが通常と違う。

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) */ といったヒント句によって指定する。