執筆した本が発売になりました。(パチパチパチ)

久しぶりの投稿になりますが、
このたび同僚と共同で執筆した本が発売になったので、
宣伝したいと思います。

Oracleの現場を効率化する100の技

というタイトルで技術評論社さんから出版されています。
目次の確認は技術評論社さんのサイトで可能です。
単行本でも電子版でも購入可能です。
(Kindle版も、もう2～3日で出るようです。)

アマゾンはこちら↓
http://www.amazon.co.jp/dp/4774173320


内容は、性能安定化からトラブル時の調査技、
安定運用のための技や分析技などバラエティーに
飛んだ内容になっています。

それぞれの技は現場を効率化するという題にふさわしく、
我々がデータベースの安定稼働や性能安定化のために使用する技や
トラブル対応で使用する分析技、経験した内容を書いています。

400ページを越えるボリューミーな本になってしまったのですが、
各技自体は2～3ページ程度に抑えてあるので、
必要な時や興味のある内容をぱぱっと読むことも可能です。

サンプルSQLを豊富に載せているので、
電子書籍版の方が便利かもしれません。
(電子版からコピペって出来るのかしら？？？)


さて、私が執筆した技ですが、
以下の観点で内容を執筆しました。

・私が過去に対応したようなトラブルを起こさない為の技
・ライセンスに関係なく使えて、知っていると便利な技
・トラブル原因の調査や検証を行うための技


とくに三点目の原因調査や検証を行うための技ですが、
マニュアル読んでもMOSを読んでも分からないことって、
少なくないですよね。

そんな時は、やっぱり自分で検証してみるのが一番手っ取り早いし、確実です。
我々、中の人も情報を読んでも不安が残るような内容は、
実際に検証しますし、同僚同士でも「やってみりゃ早い」とよくなります。


もしも実行計画が変わってしまったら、
オプティマイザが何を考えて判断したのかを見てみればいいし、
12cの新機能がどんな風に動いているのかを知りたければ、
中で何をしてるのか追跡しちゃえばいい。


お伝えした技で、一人でも自分なりに検証して、
ブログやらJPOUGで情報を発信する人が増えたら嬉しいです。

・・・

もう少し本について色々書きたいのですが、
長くなってきたのでまた別の投稿で。


少しでも興味がわいた方は、技術評論社さんのサイトで
 目次だけでも確認頂けると幸いです。

Oracle DBA & Developer Days 2014の資料が公開されたようです。

JPOUG Advent Calendar 2014の13日目のエントリです。
だいぶ遅れたプレゼントになりすみません。
ちょっと欲張ってJPOUG Advent Calendar 2014 二回目の登場になります。
1回目はこちら
今回も1nmくらい役に立つプレゼントになればと思ってエントリします。


さて、本記事のタイトルにあるように、
「Oracle DBA & Developer Days 2014 (DDD 2014)」の資料が公開されたようです。
以下サイトから資料がダウンロード出来るようです。

http://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x14073486e5

役立つ資料が山ほど入手出来るので、
サイトを紹介してこの記事を終わってもいいかなと思いましたが、
人の褌でうんぬんと言われそうなので、
私が担当したセッション内容についてポイントを説明しようと思います。


私が担当したセッションは
B1-4「クラウド：事例から見えてきたマルチテナント・アーキテクチャとOracle Database 12c新機能の活用ポイント」の
後半パート「Oracle Database 12c新機能の活用ポイント」になります。
39スライド辺りからです。

はじめに、41スライドの注意事項を読んで資料を活用頂きたいと思います。
この資料の内容や以下に記載する内容も、
PSUや個別パッチを適用することにより動作が変わるかもしれないので
気をつけて下さい。

まずFlex ASMについて話しをしました。
・Oracle Database 12c リリース1 (12.1.0.1)から、Oracle DatabaseやClusterwareにおいて、
　RAWストレージ・デバイスの直接の使用がサポートされなくなった※1
・ASMインスタンスの使用メモリはデフォルトで約1GB、推奨は1.5GBほど。
・Flex ASMを使用していれば、接続先のASMインスタンスが停止しても
　他ノードのASMインスタンスに自動的に接続してくれて、
　DBのダウンやエラーを返さず業務を継続できる。
・2ノードRACで(カーディナリティ)をALLに設定するとASMインスタンスは2つになります。
　※デフォルトではASMインスタンスが3つリソース登録されます。
・10.1～のDBと共存できるが、12.1以前のリリースのインスタンスはFlex ASM機能に対応していないので、
　その場合はカーディナリティ数をALLに設定する必要がある

次にCHMですが、
・Oracle Database 12c リリース1 (12.1.0.2)から、管理者管理のRACでもMemoryGuardが動作する。
・MemoryGuardはノードの空きメモリが少ない状態になった場合などに、
　データベース・サービスリソースを自動的に停止する動きをする。
・リポジトリDBを停止してもMemoryGuardの動作は停止しない。
・メモリの設計に注意しよう。
・CHMの停止でMemoryGuardは停止する
・リポジトリDBやCHMを停止して良いかは念のためサポートに問い合わせて
　⇒その結果を誰かフィードバックしてほしい。

ADOについては書いてある内容通りを説明しました。
ADOを実装するのに必要となったのであろう以下機能を説明しました。
・オンラインデータファイル移動
　処理中は領域が2倍必要になるので注意。
　また、オラクル社でオンラインと名のつく機能はだいたい、、※2
・オンラインパーティション移動
　移動処理中に対象のパーティションに更新処理が実行されても、
　更新処理は待機しない。
　逆に、移動処理は更新処理がcommitやrollbackされるまで、
　enq:TX -row lock contentionで待機する。
　オンラインで実行出来るからと言っても、実行タイミングの考慮は必要。

コントロールグループ(プロセッサ・グループ)/
初期化パラメータPROCESSOR_GROUP_NAME※3
・OS(カーネル)の機能を利用している
・L1～L2キャッシュを特定インスタンスで占有できる？
・NUMA nodeも指定出来るようなので、遠くのRAMを見に行かなくていいかも。
・JPOUGのボードメンバーでもある新久保氏は、I/O制御も検証していた。※4
　夢が広がる。
・Standard Editionでも使える
・マルチスレッドアーキテクチャはNUMA nodeを指定してインスタンスとRAMを固定化した際に、
　固定化されたRAMを有効活用するために作られたのではないかと妄想している。

オプティマイザ周りの新機能については、スライド75のイメージで全体像で覚えることが
大切だという話をしました。※5
・適応計画
　バインド依存カーソルや述語(where句)が複雑な場合に非効率な実行計画を選択してしまっても、
　ましな実行計画に変更してくれる。
　駆動表からの取得行数が多い場合にネステッドループ結合が発生すると悲惨だが、
　この機能が動作するとハッシュ結合に変更してくれてまだましな状況となる。
・動的統計については前回の投稿に書いたような内容を説明
・自動再最適化
　統計が不正確である、述語が複雑な場合に統計情報を補ってくれる
　カーディナリティ・フィードバックの進化機能
・SQL計画ディレクティブ
　統計情報を取得してもディレクティブは残るが動作しない。(再解析、ディレクティブ評価後)
　ディクショナリにディレクティブが山ほどついていることがある
　OPTIMIZER_ADAPTIVE_FEATUREをFALSEにしても動的統計は無効化されないので注意
・オプティマイザ機能使用方針検討ポイント
　システムの要件に合わせて、これら機能を使うか止めるかを判断するのが良い
　適応計画はEEライセンスが必要だ
・バルク・ロードのためのオンライン統計収集
　CTASや空テーブルへのダイレクト・パス・インサートでも取得されるようになった。
　(索引は作成時に自動的に統計情報が取得されるのと似た動作だ)
　インデックス統計、ヒストグラムは収集されないので注意。
　あくまでも統計情報取得時間を短縮するための動作だ。

参考情報
※1:Oracle® Databaseプラットフォーム共通日本語README12cリリース1 (12.1)
　　  2.3 Oracle Databaseで非推奨またはサポート終了となった機能
※2:Oracle® Databaseライセンス情報　12cリリース1 (12.1) エディション別の使用可能な機能
※3:設定方法等は以下ドキュメントが参考になります。
　　My Oracle SupportドキュメントID 1585184.1
    「Using PROCESSOR_GROUP_NAME to bind a database instance to CPUs or NUMA nodes on Linux」
※4：10046 trace name context foreverブログ
　 　 12cでリソースの共有と非共有のはざまで... その3 
　　 JPOUG Advent Calendar 2013のネタです
※5：Oracle® Database SQLチューニング・ガイド12cリリース1(12.1) 適応問合せ最適化について


JPOUG Advent Calendar 2014、
明日の扉はsabotage さんです。よろしくお願いします。

optimizer_dynamic_sampling=11

久々の投稿となります。
今日は、JPOUG Advent Calendar 2014の6日目のエントリです。
1µmくらい役に立つプレゼントになればと思ってます。


前日の第三の柴田ことgonsuke777さんが「Bind Peek を もっと使おうぜ！」という
煽り記事を書いていましたので、
私も呪文のように唱えられるoptimizer_dynamic_sampling=0で有名な
動的統計(動的サンプリング)の12cの今について書こうと思います。

動的統計は12c(または11.2.0.4.0リリース)以前は動的サンプリングという名前でした。
機能を単純に説明すると、オプティマイザ統計(俗に言う統計情報)が
不十分な場合にそれを補完(補填？)するための機能です。

第三の柴田がBind Peekを使おうと言っていますが、
それだって不十分な統計情報のもと使っても何の意味もありません！
なぜなら、Bind Peekは与えられたバインド変数をもとに実行計画を生成しますが、
その元ネタとなるのは統計情報だからです。
そんな不十分な統計情報を補うための機能、動的統計こそ至高！！


のはずですが、
・実行計画が変わる要素となる
・この機能が動くと実行計画の生成時間(解析時間)が長くなる

という理由でBind Peekと同じ道を歩むかのように無効化されてきました。。
(optimizer_dynamic_sampling=0設定)
※2個目の理由はシビアなレスポンスが求められるシステムでは
　止めることもよいとは思います。



そんな動的統計が12c(11.2.0.4.0含む)で進化を遂げます。
それがoptimizer_dynamic_sampling=11設定です。
11に設定するとどのような動作になるか。


Oracle® Database SQLチューニング・ガイド12cリリース1(12.1) B71277-02　では
オプティマイザで動的統計を使用するタイミングは「オプティマイザが必要と判断した場合は、
自動的に動的統計が使用されます。結果の統計は統計リポジトリ内で永続的であり、
他の問合せに対しても利用できます。」
サンプル・サイズ(ブロック)は「自動的に決定」となっています。

分かり難いですよね。
私が検証した結果からは、以下のように言いかえられると思いました。
-----
今までのレベル1～4の条件に合致した場合やSQLがパラレル実行された場合に動作するとともに、
SQL計画ディレクティブで動的統計の収集が登録されている場合や、
統計情報が失効した場合にも収集するようになった。
※通常、最後に統計情報が収集されて以降、表内の10%以上の行が変更されると、
　統計情報は失効したとみなされます。

また、動的統計として動的統計取得対象のSQLについて共有プールのSQL領域内、
または自動ワークロード・リポジトリ(DBA_HIST_XXX)から
過去のSQL実行時の統計を取得することにより、
他の問合せでも利用できる。
-----


端的に書くと以下がポイントになると思います。
=====
★統計情報が失効している場合にも動的統計が取得出来るようになった
　11.2.0.3.0までは統計情報が取得されていない場合には動的統計が動きましたが、
　統計情報が陳腐化した場合にも動作してくれるようになった。
　⇒バッチ処理時などのワーク表やデータ量・割合の変動が大きい表も
　　取得対象となります。
　　(今までは統計情報NULLでロックし、動的統計を動かすというような手法で対応していた)


★動的統計は過去の実行時統計を再利用している
　DBA_HIST_SQLSTATやV$SQLなどから過去の実行結果を参照して、
　動的統計情報を取得しているように見えます。
　※詳細を調査したい人はSQLトレースを取得するといいと思います。
　いうなれば、第三の柴田が言っていた、
　カーディナリティフィードバック(12cでの名称は自動再最適化の統計フィードバック)が
　動作するようなイメージです。
　⇒12cより前のリリースでは、動的統計もカーディナリティフィードバックもSQLカーソルが
　　エージアウトすると折角取得した統計情報補完情報が失われていた。
　　※カーディナリティフィードバックの補完情報は今のリリースでも失われます。
===


また、統計情報が失効しているオブジェクトを参照する他のSQLや
SQLカーソルがエージアウトされて、カーディナリティフィードバックの情報が失われても、
統計情報を補完した状態でSQLを実行出来るようにするために追加された機能が、
そう、SQL計画ディレクティブ！！(のはず）


と、12cではオプティマイザ周りの機能が色々と進化していますが、
長くなるので今日はここまで。
これら機能を使う使わないなどの考え方は、
第三の柴田がDDDで説明した資料を参考にするとよいと思います。



最後に注意点を記載しておくと、

・統計情報が失効している場合や過去のSQL実行統計から情報を取得する動作は
　optimizer_dynamic_samplingが11に設定されている場合のみ動く

・DYNAMIC_SAMPLINGヒントでは11を指定しても無効(有効範囲は0～10)
　Oracle® Database SQL言語リファレンス 12cリリース1 (12.1)

・SQL計画ディレクティブにより動的統計収集が実行される場合は、
　optimizer_dynamic_sampling=2が設定されていても11の動作となる。
　停止したい場合には、optimizer_dynamic_sampling=0の設定が必要。

・OPTIMIZER_ADAPTIVE_FEATURES=FALSEを設定しても動的統計の機能は停止しない


また、とても重要な点として、
レベル11の設定は11.2.0.4.0や12cからの新機能(機能拡張)なので、
検証を十分に実施してから使用するのが良いと思います。
※デフォルトの設定はoptimizer_dynamic_sampling=2となっています。


ではでは、「第三の柴田」というキーワードが流行ることを願いつつ
これを機会に今後は12cネタをぽつぽつ書いていこうと思います。



JPOUG Advent Calendar 2014、
明日の扉は渡辺 剛 さんです。よろしくお願いします！

続・HugePages_3

前回の「続・HugePages_2」の続きです。
前回はvm.nr_hugepagesはsga_targetの値を検討するところまででした。
今回は設定していきます。


1.vm.nr_hugepagesを設定します。
/etc/sysctl.confにvm.nr_hugepages=算出した値を記述します。
私の環境ではSGAを5GBと見積り、2560(5120MB/2)とします。
sysctl -p で反映します。


自動メモリ管理(AMM)環境とHugepagesの理解を深めるため、
寄り道をすると、
自動メモリ管理(AMM)環境で/dev/shmを使用している場合と、
Hugepagesを使用する場合には空きメモリの見え方が異なります。

■自動メモリ管理(AMM)環境(DB起動前)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020        558       9461          0         85        185
-/+ buffers/cache:        288       9732
Swap:        16383          0      16383


■自動メモリ管理(AMM)環境(DB起動後)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6078       3941          0         85       5400
-/+ buffers/cache:        592       9428
Swap:        16383          0      16383

DB起動後にはmemory_targetが6GBのためMemのfreeが6GB近く減少し、
usedが増えていますが、buffers/cacheのfreeに変化はありません。
/dev/shmにmemory_targetのファイルを作ったのでMemのusedが増えた。
というのがイメージできます。


▲Hugepages環境(DB起動前)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       5927       4093          0         85        425
-/+ buffers/cache:       5415       4604
Swap:        16383          0      16383

[root@s112040 /]# grep Huge /proc/meminfo
AnonHugePages:      6144 kB
HugePages_Total:    2560
HugePages_Free:     2560
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

▲Hugepages環境(DB起動後)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6001       4019          0         85        436
-/+ buffers/cache:       5479       4541
Swap:        16383          0      16383

[root@s112040 /]# grep Huge /proc/meminfo
AnonHugePages:     12288 kB
HugePages_Total:    2560
HugePages_Free:        5
HugePages_Rsvd:        5
HugePages_Surp:        0
Hugepagesize:       2048 kB

Hugepagesを獲得(sysctl -p)したタイミングでMemもbuffers/cacheも
freeが減少していますが、DBの起動による変化ありません。
Hugepagesとして獲得した領域をSGAが使いにいった感じがわかりますね。


では、寄り道を終えて、

2)DBの初期化パラメータを変更、反映します。

SQL> alter system set memory_target=0 scope=spfile;
システムが変更されました。

SQL> alter system set sga_target=5120 M scope=spfile;
システムが変更されました。

SQL> alter system set pga_aggregate_target=1024 M  scope=spfile;
システムが変更されました。

DBを再起動します。


これで完了！！！



・・・・と思いきや！


alert.logを確認すると

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5120 MB

Total Shared Global Region in Large Pages = 5120 MB (99%)

Large Pages used by this instance: 2560 (5120 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2560 (5120 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 5122 MB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
 at least 1 (page size 2048 KB, total size 2048 KB) system wide to
  get 100% of the System Global Area allocated with large pages
  2. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 5130 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************


5122MB！？Hugepagesは5120MBしか用意していないので、
1ページ 2MB分をデフォルトのページ管理領域から取得しています。
SGAのサイズに合わせたのに。。
そもそも、memlockに5130MB設定しろって。。

試しに、hugepages_settings.shを実行して
hugepages構成の推奨値を確認してみると。。
[oracle@s112040 ~]$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 2565

2565ページ、5130 MB！？


[oracle@s112040 ~]$ ipcs -m

------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x00000000 327685     oracle     640        33554432   24
0x00000000 360454     oracle     640        5335154688 24
0x5bb52b60 393223     oracle     640        2097152    24

33554432/(2048*1024) =16
5335154688/(2048*1024) =2544
2097152/(2048*1024) =1

NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`

(1+16+1)+(2544+1)+(1+1)=2565

2565ページとなり、メモリに直すと530MBですね。

ちなみに、私の11.2.0.2環境では
------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x031e4588 688143     oracle     660        5370806272 21

5370806272/(2048*1024) =2561
(1+2561+1)=2563
Recommended setting: vm.nr_hugepages = 2563でした。

よくよくシェルを読むと、
# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1
むぐぐ・・・

このNUM_PGがないと、11.2.0.4.0では2564で11.2.0.2.0は2562。
そもも謎の+1ってなんだよ。。
謎の+1も省くと2561で両バージョンとも同じ値になります。

じゃ、その+1ページなんなんだよ！？

というのは今回追いきれませんでした。。。orz

vm.nr_hugepagesを2561に設定して起動すると、正常起動を確認出来ました。

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5122 MB

Total Shared Global Region in Large Pages = 5122 MB (100%)

Large Pages used by this instance: 2561 (5122 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2561 (5122 MB)
Large Page size = 2048 KB
********************************************************************

今回SGA_TARGETを5GBから1GBまで1GBずつ減らして検証しましたが、
常にSGA_TARGET+2MB(1ページ)足りませんでした。
ipcs -mは計算してなかったのです、多分同じ傾向なのでしょうか。。



ということで、結論としては、

自動メモリ管理(AMM)を使用している環境から
Hugepagesを使用した環境に変更するには、

　2)hugepagesのページ数検討＆設定
　　2-1)sga_targetやpga_aggregate_targetの検討
　　2-2)sga_targetやpga_aggregate_targetを設定
　　　　　memory_targetを0にしてDB再起動
　　　　　※memory_max_targetが明示的に設定されている場合には、
　　　　　　 自動メモリ管理(AMM)が無効になったと判定されません。
　　　　　　 memory_max_targetを削除して下さい。
　　　　
　　2-3)hugepages_settings.shの実行
　　　　または、ipcs -mのバイトを(2048*1024)で割った値の合計にて算出
　　2-4)hugepagesのページの決定
　
　もしくは、2-2)、2-3)を省きた場合は、SGA_TARGET/2+1ページの値を設定


11.2.0.2.0の環境で、ざっくりSGA_TARGETを2で割った値で
vm.nr_hugepagesやmemlockを設定した環境では、
ひょっとしたらHugepageを全く使えてないかもしれません！？

まずはgrep Huge /proc/meminfoやalert.logを確認しみてはどうでしょうか？


次回は、気になるこいつ「AnonHugePages」に迫ります。

続・HugePages_2

折角HugePagesネタを久しぶりに書いたので、
Oracle社のマニュアルよりもグーグルの上位に立つため、
前回の「続・HugePages_1」に書ききれなかった、
Hugepagesネタに関する雑多な内容を書こうと思います。


Oracle® Database管理者リファレンス11.2では、
以下の様な設定手順が書かれていますが、
実際にはそんなに思い通りにはいかないこともあります。

1)memlockの設定変更
2)hugepagesのページ数検討＆設定
3)DB再起動により獲得

しかしながら、自動メモリ管理(AMM)を使用している環境を考えた場合、
現実的には2)の部分をもう少し考える必要があります。

共有メモリー・セグメントのhugepages構成の推奨値を計算するスクリプトですが、
自動メモリ管理(AMM)環境では以下の様な出力になります。

[oracle@s112040 ~]$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 1
ん？1ページなの？となります。

hugepages_settings.shスクリプトの内容を確認すれば分かりますが、
ipcs -mの結果を元にvm.nr_hugepagesを算出しています。

[oracle@s112040 ~]$ ipcs -m
------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x00000000 1114117    oracle     640        4096       0
0x00000000 1146886    oracle     640        4096       0
0x5bb52b60 1179655    oracle     640        4096       0
※SEG_BYTESは4096となる。

この結果から、SEG_BYTESは4096となり、HPG_SZは2048のため、
echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -qの結果は0となり、
if文を抜けて、初期値の1が出力されたことが分かります。

SEG_BYTESが4096となっているのは、自動メモリ管理(AMM)環境では、
/dev/shmにマウントされた共有メモリー・ファイルシステム(ramfs/tmpfs/shmfs)に
グラニュルサイズでファイルを作成して使用しているため、
共有メモリセグメントを使用していないことに起因しています。

このことから、自動メモリ管理(AMM)環境からHugepagesを使用した環境に変更するには、
現時的には以下の手順の実施を検討する必要があります。

2)hugepagesのページ数検討＆設定
　2-1)sga_targetやpga_aggregate_targetの検討
　2-2)hugepagesのページ数検討


2-1)についてですが、まずは現状の確認が必要ですね。
Hugepasesに関係する初期化パラメータを確認します。
memory_targetのみが設定されている場合には、
以下の様な状態になっているかもしれません。

SQL> col name_col_plus_show_param for a20
SQL> col value_col_plus_show_param for a10
SQL> col type for a15

SQL> show parameter memory_max_target memory_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
memory_max_target    big integer     6G

SQL> show parameter memory_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
memory_target        big integer     6G

SQL> show parameter sga_max
NAME            TYPE            VALUE
--------------- --------------- ----------
sga_max_size    big integer     6G
※設定されていない場合には、memory_targetの値になります。

SQL> show parameter sga_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
sga_target           big integer     0

SQL> show parameter pga_aggregate_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
pga_aggregate_target big integer     0G

SQL> show parameter use_large_pages
NAME                 TYPE            VALUE
-------------------- --------------- ----------
use_large_pages      string          TRUE


sga_targetやpga_aggregate_targetを決定するには、
以下のSQLで現状や変動を確認し、設定値を検討します。

SQL>select COMPONENT,CURRENT_SIZE,MIN_SIZE,MAX_SIZE
     　from V$MEMORY_DYNAMIC_COMPONENTS
     　where COMPONENT IN ('SGA Target','PGA Target');

SQL> select COMPONENT,PARAMETER,INITIAL_SIZE,TARGET_SIZE,
     　FINAL_SIZE,START_TIME from V$MEMORY_RESIZE_OPS
     　where COMPONENT IN ('SGA Target','PGA Target')

以下のアドバイスを参考にするのもありですね。
V$SGA_TARGET_ADVICE
V$PGA_TARGET_ADVICE

hugepagesを使用できるのはSGAだけなので、
vm.nr_hugepagesはsga_targetの値をHPG_SZである2048で
割った値となります。


長くなってきたので、一旦切ります。
実際の設定作業については次のエントリに記載します。

続・HugePages_1

今日は、JPOUG Advent Calendar 2013の5日目のエントリです。
1nmくらい役に立つプレゼントになればと思ってエントリします。


以前書いたHugepagesに関するエントリが検索すると上位に来るようで、
その地位を盤石なものにするべく、今回追加でHugepagesネタを書こうと思います。


前回のエントリ日付は2011年11月10日で以下の環境でした。
前回から二年。皆さんが導入するOracleバージョンも変わってきていると思うので、
今回はそのバージョンの違いについて調べてみます。


============
前回の環境
CPU: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz×4
メモリ：24GB
OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga)
カーネル：2.6.18-164.el5 x86_64
Oracle:11.2.0.2.0
============

今回の検証環境は以下となります。
カーネルとDBのバージョンが異なります。
============
今回の環境
CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz×2
メモリ：10GB
Oracle Linux Server release 6.4 x86_64
カーネル：2.6.39-400.17.1.el6uek.x86_64 #1
Oracle:11.2.0.4.0
SGA_TARGET:5GB
============

一言で言うと、Oracle Release 11.2.0.3.0から、
alert.logへの出力メッセージと初期化パラメータ「USE_LARGE_PAGES」の
設定値の動作と種類が少なからず変更になりました。

1.デフォルト値である「TRUE」の動作変更

動作の変更として、デフォルト値である「TRUE」の動きが変更になっています。
Oracle Database 11gリリース2 (11.2.0.2)では、
Hugepageに関する設定に失敗するとHugepage用領域が一切使用されず、
残りの物理メモリからSGAが割り当てられます。
これにより意図しない物理メモリ不足が発生し、エラーの発生やSWAPによる
パフォーマンス低下が発生する場合があります。

Oracle Database 11gリリース2 (11.2.0.3)では、
Oracleによって可能なかぎり多くのSGAがHugepage用領域に割り当てられ、
不足した場合は不足分を物理メモリの残りである通常サイズのページを使用して
割り当てられます。


★11.2.0.2のalert.log出力メッセージ★

■Hugpagesの設定がされていない場合
特にメッセージなし

■正常に取得できた場合
(vm.nr_hugepages=2561,memlock=5244928)

Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2561 free: 2561)
DFLT Huge Pages allocation successful (allocated: 2561)
***********************************************************

■SGAに対してHugpages用領域が不足している場合
(vm.nr_hugepages=2560,memlock=5244928)

****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2560 free: 2560)
Huge Pages allocation failed (free: 2560 required: 2561)
Allocation will continue with default/smaller page size
**********************************************************

■Hugpages用領域に対してmemlockの設定が小さい場合
(vm.nr_hugepages=2561,memlock=5242880)

Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2561 free: 2561)
Memlock limit too small: 5368709120 to accommodate segment size: 5370806272
Huge Pages allocation failed (free: 2561 required: 2561)
Allocation will continue with default/smaller page size
**********************************************************


★11.2.0.3以降のalert.log出力メッセージ★

■Hugpagesの設定がされていない場合
(vm.nr_hugepages= ,memlock=5244928)

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5120 MB

Total Shared Global Region in Large Pages = 0 KB (0%)

Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 5122 MB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
 at least 2561 (page size 2048 KB, total size 5122 MB) system wide to
  get 100% of the System Global Area allocated with large pages
  2. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 5130 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************

■正常に取得できた場合
(vm.nr_hugepages=2561,memlock=5244928)

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5122 MB

Total Shared Global Region in Large Pages = 5122 MB (100%)

Large Pages used by this instance: 2561 (5122 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2561 (5122 MB)
Large Page size = 2048 KB
********************************************************************

■SGAに対してHugpages用領域が不足している場合
(vm.nr_hugepages=2560,memlock=5244928)

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5122 MB

Total Shared Global Region in Large Pages = 5120 MB (99%)

Large Pages used by this instance: 2560 (5120 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2560 (5120 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 5122 MB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
 at least 1 (page size 2048 KB, total size 2048 KB) system wide to
  get 100% of the System Global Area allocated with large pages
  2. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 5130 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************


■Hugpages用領域に対してmemlockの設定が小さい場合
(vm.nr_hugepages=2561,memloc=5242880)

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5120 MB

Total Shared Global Region in Large Pages = 5120 MB (99%)

Large Pages used by this instance: 2560 (5120 MB)
Large Pages unused system wide = 1 (2048 KB)
Large Pages configured system wide = 2561 (5122 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 5122 MB. For optimal performance,
  prior to the next instance restart:
  1. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 5130 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************


2.設定値「AUTO」動作変更(有効)
種類の変更としては「AUTO」の場合の動きが変更(有効)になっています。
AUTOが設定されている場合、Hugepages用領域にSGAが取得できる場合には
同領域を使用します。
SGAに対してHugepages用領域が不足している場合には、
oradismプロセスを起動しHugepages用領域を動的に拡張(追加割り当て)します。※1.2
※1.memlockの設定値が低い場合にはTRUEの場合と同様の動きとなります。
※2.Hugepages用領域割り当てられた領域は、インスタンスを停止しても、
　物理メモリ上の通常ページには戻されません。(Hugepage用として獲得されっぱなし)


■vm.nr_hugepages未設定(または0)、DB起動前
[root@s112040 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020        955       9065          0        104        515
-/+ buffers/cache:        335       9685
Swap:        16383          0      16383
　→物理メモリは10GB弱空いています。

[root@s112040 ~]# grep Huge /proc/meminfo
AnonHugePages:      2048 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
　→HugePages用領域は0ページ。


■SGA_TRAGETを5GB、「AUTO」を設定してDBを起動した場合
(vm.nr_hugepages=0,memloc=5244928)

(alert.log)
Starting ORACLE instance (normal)
DISM started, OS id=4294　←←←←←←oradismプロセスの起動
************************ Large Pages Information *******************
Parameter use_large_pages = AUTO
Per process system memlock (soft) limit = 5122 MB

Total Shared Global Region in Large Pages = 5122 MB (100%)

Large Pages used by this instance: 2561 (5122 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2561 (5122 MB)
Large Page size = 2048 KB
Time taken to allocate Large Pages = 0.100901 sec
********************************************************************

[oracle@s112040 ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6157       3862          0        104        526
-/+ buffers/cache:       5527       4493
Swap:        16383          0      16383
　→物理メモリが5GB程度使用されています。


[oracle@s112040 ~]$ grep Huge /proc/meminfo
AnonHugePages:      38912 kB
HugePages_Total:    2561
HugePages_Free:        5
HugePages_Rsvd:        5
HugePages_Surp:        0
Hugepagesize:       2048 kB
　→HugePages用領域は2561ページ獲得されている


[oracle@s112040 trace]$ ps -edf|grep dism
root      4294     1  0 02:51 ?        00:00:00 ora_dism_s11204
　→プロセスがrootで起動されている。


～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

というところで長くなってきたのでココらへんで終わりますが、
どちらの変更も使う側が意識しないで使用するとトラブルの元になりますね。
動作状況について、OSコマンドやログからしっかり把握しておくことが大事ですね。

そういえば、AnonHugePagesって前のエントリにいましたっけ？
要注意なヤツなのですが、それはまた別のお話・・


JPOUG Advent Calendar 2013、
明日の扉は tyuma さんです。よろしくお願いします。



o＜(ｏ'∀')ﾉ☆*:;;;:*☆Merry Christmas☆*:;;;:*☆ヽ('∀'ｏ)＞o



続・HugePages_2につづく

蘇るパラメータファイルその3

前回のつづきです。
前回は、SPFILEの記述のないinit[SID].oraファイルを
%ORACLE_HOME%\database\配下に配置しても、
勝手にSPFILEの記述を追記される。

それも、SQL*PlusのSTARTUPコマンドじゃなくて、
srvctlコマンドで起動してみた場合に起きている。
# line added by Agentというメッセージを残して。。
そう、Oracle Grid Infrastructure(以下Grid)がなんかやっそうだ。

さて、本題。
Gridでcrsに関係するagentと言えば、oraagentかorarootagentですよね
でもあってOracleなので、なんかやってるとすればoraagentが怪しい。
ということで、「init[SID名]」でログを検索します。
%GRID_HOME%\log\strike-1\agent\crsd\oraagent\配下の\oraagent.XXXを検索

やっぱりなんか出てる。

2012-12-19 20:05:13.130: [ora.strike01.db][4876] {1:28408:2364} [start] sModifyConfig for strike01
2012-12-19 20:05:13.145: [ora.strike01.db][4876] {1:28408:2364} [start] ConfigFile::update file D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora is updated

sModifyConfigっての実行した後に、initstrike011.oraを更新したと。
しれっとやっとる。。

sModifyconfigというキーワードと、
srvctlの実行によって出力されているということから
srvctl configやmodify辺りが怪しい！！(強引ですが)
と言うことで、configを確認します。


C:\>srvctl config database -d strike01 -a
====
一意のデータベース名: strike01
データベース名: strike01
Oracleホーム: D:\app\orauser\product\11.2.0\dbhome_1
Oracleユーザー: nt authority\system
spfile: +DATA/strike01/spfilestrike01.ora
ドメイン:
開始オプション: open
停止オプション: immediate
データベース・ロール: PRIMARY
管理ポリシー: AUTOMATIC
サーバー・プール: strike01
データベース・インスタンス: strike011,strike012
ディスク・グループ: DATA
マウント・ポイントのパス:
サービス:
タイプ: RAC
データベースは有効です
データベースは管理者によって管理されています
====

SPFILE、定義されてます。

そもそもSRVCTLって？？？

OracleR Real Application Clusters管理およびデプロイメント・ガイド11g リリース2 (11.2)より
====
SRVCTLを使用してクラスタの構成操作を実行すると、
SRVCTLは構成データをOracle Cluster Registry(OCR)に格納します。
SRVCTLは、Oracle Clusterwareリソース(Oracle Call Interface APIを使用して
データベースの起動および停止操作を実行するエージェントを定義)を構成および管理することによって、
インスタンスの起動および停止のようなその他の操作を実行します。
====

どうやら定義はOCRに入ってるようです。

いつ、定義したんだろう。。。
と、よくよくDB作成スクリプト([Database名].sql)を確認してみると

host D:\app\orauser\product\11.2.0\dbhome_1\bin\srvctl.bat add database -d strike01 -o D:\app\orauser\product\11.2.0\dbhome_1 -p +DATA/strike01/spfilestrike01.ora -n strike01 -a DATA

srvctlコマンドを使用したデータベースリソース追加時のオプションで、
-p +DATA/strike01/spfilestrike01.oraというのを指定して実行しています。

OracleR Real Application Clusters管理およびデプロイメント・ガイド11g リリース2 (11.2)より

-p spfile
データベース・サーバー・パラメータ・ファイルのパス名

なるほど。

だんだん見えてきました。

次回は、srvctlコマンドを実行してOCR内のSPFILE情報を書き換え、
推測が正しいかを確認します。