リスナー・ログオン・ストーム・ハンドラ
• ログオン・ストーム
– 着信接続レートの急激なスパイク
•
正常–
中間層のリブート•
異常 – DoS攻撃– ストームにより、既存のセッションの CPU 不足が発生
• Connection Rate Limiter の機能の有効化
– スロットリングをエンドポイント・レベルで制御
ログオン・ストームの比較
150の同時接続
RATE_LIMIT = なし RATE_LIMIT = 3/ 秒
CP U
使用率%
セッション時間 時間
他のベスト・プラクティス
• エンドポイントごとの最大同時リクエスト数を増量
– listener.oraのQUEUESIZEパラメータ
–
希望するConnection Requestレートに設定– Windowsで設定
• リスナー・パスワードは設定しないこと
–
デフォルトでのリスナー管理の保護 – OSユーザー認証• oracle アカウントの環境変数を最適化
– PATH
が長いほどOracle
プロセスの分岐にかかる時間が長くなる• PATHが小さいことを確認
•
ネットワーク共有を含めないこと–
環境変数の数を削減データベース・サーバー
スケーラビリティ
Oracle サーバー・アーキテクチャの概要
• スケーラビリティの要件を満たすには正しいサーバー・
アーキテクチャの選択が重要
• Oracle Database サーバーでは以下の 3 つのアーキテクチャを サポート
– 専用サーバー（デフォルト）
– 共有サーバー （ MTS ）
– データベース常駐接続プール（ 11g ）
専用サーバー
• 各クライアント接続が独自のプロセスを 所有（ Windows のスレッド）
• 専用プロセスでは短い待機時間を保証
• 接続時に新しいプロセスを開始する 必要あり
• 切断時にプロセスを分解する必要あり
• スケーラビリティの限界
–
メモリ–
プロセスの数共有サーバー （ MTS ）
• 各サーバーが複数のクライアントに対応
• ディスパッチャがクライアントとサーバー間 のリクエストおよびレスポンスを中継
• アイドル接続によって大量のメモリを消費 しない
• アイドルが多い大量の接続に適切
• 介在者により待機時間が増加
データベース常駐接続プール（ 11g ）
– クライアント・システムおよび
プロセス間で共有されるプールされ た専用サーバー
– 低い接続 / 切断コスト
•
接続時にサーバーは“ロック”される•
切断時にサーバーは“リリース”される– 専用サーバーの低待機時間の パフォーマンス
– DRCP 対応のクライアント・ドライバ
による卓越したスケーラビリティ
専用サーバー vs. 共有サーバー vs. DRCP
• 専用サーバーを使用する対象
–
高パフォーマンスの接続–
アクティブ、長時間実行、およびデータ転送集中型のオペレーション• 共有サーバーを使用する対象
–
しばらくの間アイドル状態の続くセッション–
接続と切断がひんぱんに起こるクライアント• DRCP （ 11g ）を使用する場合
–
短期間にデータベース・サーバー・セッションにアクセスする必要があるクライアントが 多数ある場合–
アプリケーションがおもに同一のデータベース資格証明を使用し、同一のセッション 設定を持つ場合– OCI、OCCI、PHP（OCI8拡張）、Python（cx_Oracle）、Perl（DBI）
共有サーバーの使用
• init.ora パラメータで共有サーバーを有効化
–
新しいデフォルトになる• サーバー・タイプを強制するには、接続中にサーバー・タイプを指定
–
専用：sales-server/sales.us.example.com:dedicated
–
共有：sales-server/sales.us.example.com:shared
• おおよそのガイドライン
– 500セッションにつき20または30の共有サーバー、そこからチューニング – 50～100セッションごとに1つのディスパッチャ
• 11g のパフォーマンスが大幅に向上
DRCP の使用
• DBA の使用によりプーリングを有効化
ドキュメント内
PowerPoint Presentation
(ページ 41-51)