Trying Database

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

2015-05-27T07:00:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・・・

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

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

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

2014-12-17T19:27:00.000+09:00

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

2014-12-06T01:36:00.000+09:00

久々の投稿となります。
今日は、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

2013-12-05T19:00:00.000+09:00

前回の「続・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

2013-12-05T17:00:00.000+09:00

折角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

2013-12-05T07:00:00.000+09:00

今日は、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 = 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

2012-12-20T16:48:00.000+09:00

前回のつづきです。
前回は、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情報を書き換え、
推測が正しいかを確認します。

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

2012-12-19T20:33:00.000+09:00

前回の続きです。

消したはずのinit[SID].oraが蘇りました。
誰かの手によって。。

とても気になるので、悪戯してみます。

PFILEを作っちゃいます。

SQL> create pfile='D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011
.ora' from spfile;

ファイルが作成されました。


5.4 Oracle RACでのパラメータ・ファイルの検索順序
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

このルールなので、init%ORACLE_SID%.oraを読むはず。

C:\>srvctl stop instance -d strike01 -i strike011

C:\>crsctl stat res ora.strike01.db -t
--------------------------------------------------------------------------------

NAME           TARGET  STATE        SERVER                   STATE_DETAILS

--------------------------------------------------------------------------------

Cluster Resources
--------------------------------------------------------------------------------

ora.strike01.db
      1        OFFLINE OFFLINE                               Instance Shutdown

      2        ONLINE  ONLINE       strike-2                 Open


C:\>srvctl start instance -d strike01 -i strike011


C:\>crsctl stat res ora.strike01.db -t
--------------------------------------------------------------------------------

NAME           TARGET  STATE        SERVER                   STATE_DETAILS

--------------------------------------------------------------------------------

Cluster Resources
--------------------------------------------------------------------------------

ora.strike01.db
      1        ONLINE  ONLINE       strike-1                 Open

      2        ONLINE  ONLINE       strike-2                 Open


C:\>sqlplus sys/oracle as sysdba
に接続されました。
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora

なんだと・・・


C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora
======
strike012.__db_cache_size=671088640
strike011.__db_cache_size=570425344
strike012.__java_pool_size=16777216
strike011.__java_pool_size=33554432
　・
　・
　・
　・
strike011.undo_tablespace='UNDOTBS1'
SPFILE='+DATA/strike01/spfilestrike01.ora'  # line added by Agent
======

！！！！！！
最後の最後になんて罠を・・


C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\init*

2012/12/19  20:05             1,923 initstrike011.ora
2012/12/19  20:01             1,856 initstrike011.ora.bak.strike-1


なんと！！！

C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora.ba
k.strike-1
======
strike012.__db_cache_size=671088640
strike011.__db_cache_size=570425344
strike012.__java_pool_size=16777216
strike011.__java_pool_size=33554432
　・
　・
　・
　・
strike011.undo_tablespace='UNDOTBS1'

むむむむ

勝手に作られたファイルをリネームして、
バックアップにされたファイルを
リネームしてinit[SID].oraファイルに戻します。

C:\>sqlplus sys/oracle as sysdba
アイドル・インスタンスに接続しました。

SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area 2137886720 bytes
Fixed Size                  2254896 bytes
Variable Size            1560283088 bytes
Database Buffers          570425344 bytes
Redo Buffers                4923392 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------------------
spfile                               string

うん。init[SID].oraファイルで起動している。
どうやらAgentとやらは、RAC(GRID)関係で、
RAC(GRID)のどっかにSPFILEの情報もってるな・・


つづきます

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

2012-12-19T19:50:00.000+09:00

サーバー・パラメータ・ファイル(SPFILE)って、
SQL文で動的にパラメータを変えられて、便利です。
今だとデフォルトだとSPFILE使うようになってますよね。
RAC環境だとASM上に配置して、複数ノードで1つのファイルを
使用したりします。
(各ノードにあると、運用管理がちょっと煩雑だったりしますもんね)

今回はそんなSPFILE絡みで、ビックリしたことがあったので、
それを書きたいと思います。(僕だけですかね？びっくりするの)
いつも通り役には立ちません。

検証環境
[OS]
----
Microsoft Windows Server 2003 R2
Enterprise x64 Edition
Service Pack 2
----
[Oracle＆GRID]
----
11.2.0.2.0 - 64bit
----

[その他]
----
2ノードRAC、管理者型管理
----

パラメータファイルについて、
OracleR Real Application Clustersインストレーション・ガイド11g リリース2 (11.2) for Microsoft Windows x64 (64-Bit)に
以下の記載があります。


5.4 Oracle RACでのパラメータ・ファイルの検索順序
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

なるほど。
環境を見てみます。

SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora

上記のどれにも合致しません。
OS上を見てみます。

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\sp*

ファイルが見つかりません

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\init*

2012/12/18  14:04                90 initstrike011.ora

ありました。どうやら3番目のinitファイルは読み込みそうです。
中身を見てます。

C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

SPFILE='+DATA/strike01/spfilestrike01.ora'

この一行だけ書いてあります。

なるほど、旧来の初期化パラメータのファイルであるinit%ORACLE_SID%.oraファイルを読み込んで、

ASM上のSPFILEを読み込んでいると。


そもそも、このinitstrike011.oraとその中身はいつ作られているのでしょうか？
データベース作成スクリプトの1つである、

%ORACLE_BASE%\admin\[データベース名]\scripts\[データベース名].sqlを見てみると、

以下の部分で作っていることが分かります。
host "echo SPFILE='+DATA/strike01/spfilestrike01.ora' > D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora"


ところで、Oracle DB起動時のnomount状態では、パラメータファイルの内容を読み込み、
メモリ割り当てやプロセスの生成などを行います。

つまり、パラメータファイルがないと
「Oracle DBは起動出来ない。」
やってみます。

SQL> conn /as sysdba
接続されました。
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> exit
接続が切断されました。

C:\>del D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

ファイルが見つかりません

C:\>sqlplus sys/oracle as sysdba

アイドル・インスタンスに接続しました。

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: ?p?????[?^?E?t?@?C??'D:\APP\ORAUSER\PRODUCT\11.2.0\DBHOME_1\DATABASE\INITSTRIKE011.ORA'???I?[?v?????????????B
SQL> exit
切断しました。

うん。上がらない。
ファイルないし。

あ、そうそう、RACのリソース起動停止は
srvctlコマンドを使うのが一般的だよな。。

C:\>srvctl start instance -d strike01 -i strike011

C:\>


あれ？普通にプロンプト返ってきた。。

C:\>crsctl stat res ora.strike01.db -t
NAME           TARGET  STATE        SERVER                   STATE_DETAILS

---------------------------------------------------------------------------
Cluster Resources
---------------------------------------------------------------------------

ora.strike01.db
      1        ONLINE  ONLINE       strike-1                 Open

      2        ONLINE  ONLINE       strike-2                 Open

ん？？？？Open？


C:\>sqlplus sys/oracle as sysdba
接続されました。
SQL> select instance_name,status from v$instance;

INSTANCE_NAME    STATUS
---------------- ------------
strike011        OPEN

SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +DATA/strike01/spfilestrike01.ora


SQL> exit
接続が切断されました。

OPENしてて、ASM上のSPFILEを読んでるだと・・・

でも、マニュアルには、、、、
=====
Oracle RACは、次の順序でパラメータ・ファイルを検索します。
%ORACLE_HOME%\database\spfile%ORACLE_SID%.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\init%ORACLE_SID%.ora

んーなんだろう。。

C:\>dir D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

2012/12/19  18:27                67 initstrike011.ora
               

！！！！！


C:\>notepad D:\app\orauser\product\11.2.0\dbhome_1\database\initstrike011.ora

SPFILE='+DATA/strike01/spfilestrike01.ora'  # line added by Agent


# line added by Agentだと・・・

つづきます。。

Oracle Database作業時のちょっとしたテクニック

2012-12-11T00:00:00.000+09:00

最初に

今日は、JPOUG Advent Calendarの11日目のエントリです。

1nmくらい役に立つプレゼントになればと思ってエントリします。

データセンターでのトラブルシュートでは、幾つかの共通する懸念があります。

1.PCが持ち込めない or 通信カードが使えない　or サーバからはネット出来ない

2.トラブルシュートなので大体が緊急である

3.同様の障害が再発生した際に対応できるようにしておきたい。

これらの状況下で必要とされるのが「自力」

そんなとき使っているちょっとしたテクニックを紹介したいと思います。

1.PCが持ち込めない or 通信カードが使えない　or サーバからはネット出来ない

　DB内の何かを調査するには、データディクショナリ(DBA_)や動的パフォーマンス・ビュー(V$)を

　参照して色々な統計情報を参照します。ただ、あまり使用しないものはなかなか覚えていられません。

　Oracleのリファレンスマニュアルを確認できれば、どのビューのどの列を参照すればいいか分かりますが、
　自PCも使えないし・ネットにも繋がってない。

　みんなが@yoshikawさんの「CUIでOracle Databaseリファレンスマニュアルを参照する」を参考にして、

　マニュアルを見れるようにしておいてくれるととても有難いのですが、なかなかそうもいきません。

　さて、どうするか？

　ディクショナリ一覧表から、関係のありそうなビューを見つけ出します。

SQL> SELECT TABLE_NAME,COMMENTS FROM DICTIONARY
WHERE TABLE_NAME LIKE '%LINK%';

TABLE_NAME                     COMMENTS
------------------------------ ------------------------------------------------------------
DBA_DB_LINKS                   All database links in the database
DBA_STREAMS_TP_COMPONENT_LINK  DBA Streams Component Link (Streams Topology Links)
USER_DB_LINKS                  Database links owned by the user
ALL_DB_LINKS                   Database links accessible to the user
V$DBLINK                       Synonym for V_$DBLINK
GV$DBLINK                      Synonym for GV_$DBLINK

次に、関係のありそうな表に、どんな列があるのかを調べます。
SQL> DESC[RIBE] DBA_DB_LINKS

名前                                      NULL?    型
----------------------------------------- -------- ----------------
OWNER                                     NOT NULL VARCHAR2(30)
DB_LINK                                   NOT NULL VARCHAR2(128)
USERNAME                                           VARCHAR2(30)
HOST                                               VARCHAR2(2000)
CREATED                                   NOT NULL DATE

※[]内は省略できます。

TABLE_NAME LIKE '%調べたいキーワード%'という形で使用し、
あとは、関係のありそうな列を参照して調査します。

SQL>　SELECT OWNER,DB_LINK,USERNAME FROM DBA_DB_LINKS;

これで、DBA_XXやV$XXを覚えて無くても、ある程度必要な情報を調査出来ます。

2.トラブルシュートなので大体が緊急である
　すぐになんとかしなければいけないのに、値の異なる対処SQL文を大量に実行しないといけない。
　でも、ローカルにはいいエディターもないし、ましてやエクセルなんて・・・
　地道にコピペして一部を修正してなんてやってたら、時間がかかってしまう。。。

　さて、どうする？

　SQL文を使用してSQL文を生成します。

例)APからのセッション数が増えすぎてメモリが枯渇。セッションを破棄したい。
　　　※PGA_AGGREGATE_TARGETのない時代はある話でした。。

　SQL> SELECT USERNAME,SID,SERIAL# FROM V$SESSION WHERE USERNAME='SCOTT';

USERNAME     SID    SERIAL#
---------- ----- ----------
SCOTT          8         75
SCOTT          9         39
SCOTT         11         27
SCOTT         12        129
・
・
・

100行が選択されました。

(kill sessionのSQL)
SQL> ALTER SYSTEM KILL SESSION 'SID,SERIAL#';

SIDとSERIAL#を修正して何度も実行する？
SQL> ALTER SYSTEM KILL SESSION '8,75';
システムが変更されました。
SQL> c/8,75/9,39/
1* ALTER SYSTEM KILL SESSION '9,39'
SQL> /
システムが変更されました。

c/修正対象文字列/修正後文字列/で置換できますが、
100回繰り返すのはしんどいし、時間もかかる。

そこで、連結演算子「||」を活用して参照結果からSQL文を生成します。

SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
　　　 WHERE　USERNAME='SCOTT';

'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||''';'
--------------------------------------------------------------------------------
alter system kill session '8,75';
alter system kill session '9,39';
alter system kill session '11,27';
alter system kill session '12,129';
・
・
99行が選択されました。

コピペして実行してもいいですが、
spoolコマンドを使用してスクリプト化するのもありです。

SQL> set pages 2000
SQL> set head off
SQL> set feedback off
SQL> set trimspool on
SQL> spool kill_session.sql

SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
  2  WHERE　USERNAME='SCOTT';

alter system kill session '8,75';
alter system kill session '9,39';
alter system kill session '11,27';
alter system kill session '12,129';
・
・
・
SQL> spool off

ローカルフォルダに kill_session.sqlというファイルが出来るので、
editコマンドを使用して編集します。
SQL> edit kill_session.sql
Windowsだとノートパッドでファイルが開くので不要な部分を修正します。

Linuxの場合は、
SQL> define _editor=vi でエディターを定義してeditコマンドを実行します。
修正したファイルを実行します。

SQL> @kill_session
システムが変更されました。
システムが変更されました。
・
・
・

手動で繰り返し実行するよりとてもスマートですね。
INDEXのリビルドとか不要オブジェクトのdropとか使い道は様々です。

1.と2.を合わせて使えば、調査に必要な統計情報特定し、CSV形式で出力することも可能です。

SQL> SELECT USERNAME||','||TERMINAL||','||PROGRAM||','||EVENT FROM V$SESSION
  2  WHERE USERNAME IS NOT NULL;

USERNAME||','||TERMINAL||','||PROGRAM||','||EVENT
--------------------------------------------------------------------------------
SCOTT,SHIOSHIO,sqlplus.exe,enq: TX - row lock contention
SCOTT,SHIOSHIO,sqlplus.exe,SQL*Net message from client
SYS,SHIOSHIO,sqlplus.exe,SQL*Net message to client

3.同様の障害が再発生した際に対応できるようにしておきたい。

後日同様の障害が発生しても、SQL文を生成出来るようにしておきたいですよね。
　作ったSQL文はsaveコマンドを使用してスクリプトとして保存しましょう。

SQL> SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
  2  WHERE　USERNAME='SCOTT';

作ったSQL文を保存します。

SQL> save create_kill_session.sql
file create_kill_session.sqlが作成されました。

SQL> edit create_kill_session.sql

編集例)

==============ここから

-- ローカルフォルダにSCOTTユーザセッションを破棄する　※編集により追記した行
-- kill_session.sqlを生成します。　　　　　　　　　　 ※編集により追記した行
-- @kill_session.sqlを実行することにより、          　※編集により追記した行
-- セッションを破棄します。　　　　　　　　　　　　 　※編集により追記した行

set pages 2000                                        ※編集により追記した行
set head off                                          ※編集により追記した行
set feedback off                                      ※編集により追記した行
set term off                                          ※編集により追記した行
set trimspool on                                      ※編集により追記した行
spool kill_session.sql                                ※編集により追記した行

SELECT 'alter system kill session '''||SID||','||SERIAL#||''';' FROM V$SESSION
WHERE　USERNAME='SCOTT'
/

spool off                                         　　※編集により追記した行

==============ここまで

以上、つらつら書いてきましたが、
他にも有用なSQL*Plusコマンドはありますし、上記setコマンドの内容を知りたい方は
「SQL*Plus®ユーザーズ・ガイドおよびリファレンス」を参照ください。

SQL> help index　や help setも有用ですね。
SQL*Plusコマンドを活用したCSVデータ出力方法については、
@s4r_agentさんが初日に「csvってどうやって出力してますか？」というエントリを書いてますので、
併せて見てみてください。

最後に
明日の扉は Masashi_Matsushita さんです。よろしくお願いします。



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

INITIAL_EXTENTと遅延セグメント作成な話4

2012-09-11T11:53:00.001+09:00

前回でスッキリ！したのですが、まだちょっと気になるので、dumpを取得してみます。
やってみてがモットーのブログですしね。

では、やってきます。

SQL> create tablespace test_ext2 datafile 'C:\app\oracle\oradata\orcl\test_ext2_01.dbf' size 81K;

表領域が作成されました。

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name= 'TEST_EXT2';

TABLESPACE_NAME BLOCK_ID BYTES BLOCKS
--------------------- ---------- ---------- ----------
TEST_EXT2 4 　　 65536 　　　　 8 　　-------(1)

SQL> alter user hoge quota unlimited on TEST_EXT2;

ユーザーが変更されました。

SQL> connect hoge/hoge
接続されました。

SQL> create table test_ext2(co1 number) tablespace TEST_EXT2;

表が作成されました。

SQL> connect /as sysdba
接続されました。

SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name= 'TEST_EXT2';

OWNER TABLESPACE_NAME TABLE_NAME SEGMENT_CREATED
---------- --------------- ---------- --------------------
HOGE TEST_EXT2 TEST_EXT2 NO　-------(2)

2話目で書きましたが、遅延セグメント作成な状態で、セグメントは作成されていません。

SQL> select tablespace_name,file_id from dba_data_files where tablespace_name='TEST_EXT2';
TABLESPACE_NAME FILE_ID
--------------- ----------
TEST_EXT2 　　　　14　　　-------(3)

(1)よりデータブロックの空きは4ブロック目(含む)から8ブロックなので、
11ブロック目が最期のブロックだと判断します。

ファイル番号14番のデータファイルの1ブロック目から11ブロックまでの
dumpを取得します。

SQL> alter system dump datafile 14 block min 1 block max 11;

システムが変更されました。

diag\<DB_NAME>\<INSTANCE_NAME>\trace配下に出力された
dumpファイルを確認します。

先頭辺り
--------

*** 2012-09-11 11:02:09.047
*** SESSION ID:(9.37) 2012-09-11 11:02:09.047
*** CLIENT ID:() 2012-09-11 11:02:09.047
*** SERVICE NAME:(SYS$USERS) 2012-09-11 11:02:09.047
*** MODULE NAME:(sqlplus.exe) 2012-09-11 11:02:09.047
*** ACTION NAME:() 2012-09-11 11:02:09.047

Start dump data blocks tsn: 12 file#:14 minblk 1 maxblk 11
Block 1 (file header) not dumped:use dump file header command　　　-------(4)

早々に注意されています。1ブロック目はファイルヘッダーブロックだから、

ファイルヘッダーをダンプするコマンド使いなさいと。

まあ、1ブロック目がファイルヘッダーブロックってことは分かりました。

2ブロック目を確認

rdba(相対データ・ブロック・アドレス)という文字列を検索して2ブロック目を探します。

----------------------------

Block dump from disk:

buffer tsn: 12 rdba: 0x03800002 (14/2) 　　　-------(5)

scn: 0x0000.00398ff6 seq: 0x03 flg: 0x04 tail: 0x8ff61d03

frmt: 0x02 chkval: 0x75b5 type: 0x1d=KTFB Bitmapped File Space Header　　　-------(6)

(5)がrdbaですね、(file_id/ブロック番号)なので、

14番のデータファイルの2ブロック目ということがわかります。

(6)を見てみると、「Bitmapped File Space Header」とあります。

このブロックが、ビットマップ・ヘッダ・ブロックと考えてよさそうです。

3ブロック目を確認

----------------------------

Block dump from disk:

buffer tsn: 12 rdba: 0x03800003 (14/3)　　　-------(7)

scn: 0x0000.0039ecd1 seq: 0x01 flg: 0x04 tail: 0xecd11e01

frmt: 0x02 chkval: 0x43ae type: 0x1e=KTFB Bitmapped File Space Bitmap　　　-------(8)

(7)より14番のデータファイルの3ブロック目ということがわかります。

(8)を見てみると、「Bitmapped File Space Bitmap」とあります。

このブロックが、ビットマップ・ブロックと考えてよさそうです。

4ブロック目を確認

----------------------------

Block dump from disk:

buffer tsn: 12 rdba: 0x00000004 (0/4)　　　-------(9)

scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001

frmt: 0x02 chkval: 0xa704 type: 0x00=unknown　　　-------(10)

14/4が見つかりません。ファイルの終わりまで見ると(9)の部分が、(0/11)まであります。

8ブロック。。(10)はunknownになっています。

遅延セグメント作成でセグメントが作成されていないので、

空き領域になっているんですかね。

一先ず、1～3ブロック目までは、技術文書通りだということが分かって、スッキリ！！

次回は、遅延セグメント作成のセグメントに行を追加して、どうなるかを見てみます。

INITIAL_EXTENTと遅延セグメント作成な話3

2012-09-11T10:25:00.000+09:00

前回で終わったーと思って寝たのですが。
前々回の先頭3ブロックが気になる。。

そして、OS上で1ブロック分領域が多く獲得されているのも気になる。。。

ということで続きます。

何度も書いてますが、役に立つ内容ではないですね。

ローカル管理表領域

ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域が割り当てられるか、解放されると、Oracle Databaseでは、ビットマップの値がブロックの新しい状態を反映する値に変更されます。

出典：OracleR Database概要　11gリリース2(11.2)　12章　論理記憶域構造

でした。でした。ディクショナリ管理と違って、エクステント内の領域を使用または解放について、
領域を管理するためのデータ・ディクショナリ表の更新をしなくてよくなったんですよね。
ディクショナリ管理時は、ディクショナリの更新のための再帰SQLの発行や競合による待ち、
redoの生成とか色々な課題があったんですよね。

ローカル管理表領域だと、自分の表領域内で領域の使用状況をビットマップで管理することによって、
エクステントの管理にデータ・ディクショナリを使用する必要がなくったので、
上記のような課題を解消してパフォーマンスがアップしたのでした。

ということで、使えない先頭3ブロックにはビットマップ情報の情報がきっと入ってるんだろうなぁ。。。

・・・KROWNの文書番号：29765に中にちゃんと書いてありますね。。

1ブロック目：データファイルヘッダー。デーファイル毎の1ブロック目
　　　　　　　　データファイルの管理情報を格納

2ブロック目：ビットマップ・ヘッダ・ブロック。ローカル管理表領域デーファイル毎の
　　　　　　　　2ブロック目※。ローカル管理するための管理情報を格納
　　　　　　　　※最初からローカル管理としてデータファイルを作った場合のみ

3ブロック目：ビットマップ・ブロック。ローカル管理表領域デーファイル毎の
　　　　　　　　3ブロック目移行に1個以上獲得される。
　　　　　　　　実際の領域管理のためのビットマップ情報を格納。

とすると88KBは、(上記3ブロック+セグメント用8ブロック)×8で88KBか。

96KBとOS上で見えている、残り1ブロック分の領域。
これもKROWNの文書番号：29765に書いてありました。

OS側でのファイル管理用領域なんですね。
以下のSQL文で確認ができます。

SQL> select a.FILE_NAME,b.BLOCK1_OFFSET from dba_data_files a,v$datafile b where a.file_id=b.file# and a.tablespace_name='TEST_EXT';

FILE_NAME 　　　　　　　　　　　　　　BLOCK1_OFFSET
--------------------------------------------- 　　　　　-------------
C:\APP\ORACLE\ORADATA\ORCL\TEST_EXT01.DBF 8192

BLOCK1_OFFSET：ファイルの最初からOracleの共通情報の開始点へのオフセット

確かにデータファイルの8KB以降からOracleの情報が開始されるみたいですね。

ということで、96KBの謎が解けた。

スッキリ！

でも、まだ、ちょっとだけ気になるのでしつこく続けます。

次回：INITIAL_EXTENTと遅延セグメント作成な話4

INITIAL_EXTENTと遅延セグメント作成な話２

2012-09-10T22:30:00.001+09:00

前回に引き続き、どうでもいい内容を検証していきます。

表領域にオブジェクトを作っていきます。

SQL> create table test_ext(co1 number) tablespace TEST_EXT;

表が作成されました。

SQL> select OWNER,SEGMENT_NAME,EXTENT_ID,BLOCKS,BYTES from dba_extents where TABLESPACE_NAME like 'TEST_EXT%';

OWNER SEGMENT_NAME EXTENT_ID BLOCKS BYTES
------- --------------- ---------- ---------- ----------
SYS TEST_EXT 　　 0 8 65536

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT';

レコードが選択されませんでした。

うんうん。データベース記憶域の割当ての論理単位はエクステント単位だもんね。
MIN_EXTENTSの1エクステント(8ブロック)使っちゃったもんね。うんうん。

うん・・・

ん？？

あえ、確か最近のバージョンからは、オブジェクト作成しただけじゃ、
セグメント作成(領域獲得)しなくて、行が挿入されたときに初めて、
セグメント作成されるんじゃなかったっけ、、、

えっとぉ、、、
そうそう、11.2.0.1.0からの新機能「遅延セグメント作成」
※パーティションは11.2.0.2.0からなので、要注意。

詳しくは、Oracle® Database概要　11gリリース2(11.2)　12章　論理記憶域構造　参照

確認してみます。

SQL> show parameter DEFERRED_SEGMENT_CREATION

NAME TYPE VALUE
----------------------- ----------- ------------------------------
deferred_segment_creation boolean TRUE

遅延セグメント圧縮機能は有効になっています。

SQL> select OWNER,TABLE_NAME,SEGMENT_CREATED from dba_tables where table_name='TEST_EXT';

OWNER TABLE_NAME SEGMENT_CREATED
---------　--------------- -------------------
SYS TEST_EXT YES

でもセグメント作られてますな。。。

そもそもSYSで作ったのがいけないのかなぁ。。怪しそう。。。

試します。

SQL> create tablespace test_ext2 datafile 'C:\app\oracle\oradata\orcl\test_ext2_01.dbf' size 81K;

表領域が作成されました。

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME BLOCK_ID BYTES BLOCKS
--------------------- ---------- ---------- ----------
TEST_EXT2 4 　　 65536 　　　　 8

SQL> alter user hoge quota unlimited on TEST_EXT2;

ユーザーが変更されました。

SQL> connect hoge/hoge
接続されました。

SQL> create table test_ext2(co1 number) tablespace TEST_EXT2;

表が作成されました。

SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name like 'TEST_EXT%';

OWNER TABLESPACE_NAME TABLE_NAME SEGMENT_CREATED
---------- --------------- ---------- --------------------
SYS TEST_EXT TEST_EXT YES
HOGE TEST_EXT2 TEST_EXT2 NO

お、HOGEのTEST_EXT2はセグメント作成されていない。

SQL> select OWNER,SEGMENT_NAME,EXTENT_ID,BLOCKS,BYTES from dba_extents where TABLESPACE_NAME like 'TEST_EXT%';

OWNER SEGMENT_NAME EXTENT_ID BLOCKS BYTES
------- --------------- ---------- ---------- ----------
SYS 　　 TEST_EXT 　　 0 　　　　 8 　　 65536

うんうん。HOGEのTEST_EXT2がない。
※dba_extentsはセグメントを含むエクステントの情報だから

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME BLOCK_ID BYTES BLOCKS
--------------- 　　　---------- ---------- ----------
TEST_EXT2 　　　　4 　　　 65536 8

うん。うん。空いてますな。

ということで、SYSのオブジェクトは遅延セグメント作成しないってことだな。

という内容が、KROWNの文書番号：137280が遅延セグメント作成機能についてですが、
やっぱりSYSは対象外と書いてありますね。

SQL> connect hoge/hoge
接続されました。
SQL> insert into test_ext2 values(1);

1行が作成されました。

SQL> commit;

コミットが完了しました。

SQL> connect /as sysdba
接続されました。
SQL> select owner,tablespace_name,table_name,segment_created from dba_tables where table_name like 'TEST_EXT%';

OWNER TABLESPACE_NAME TABLE_NAME SEGMENT_CREATED
---------- --------------- 　　---------- --------------------
SYS 　 TEST_EXT 　　　 TEST_EXT 　　　 YES
HOGE 　TEST_EXT2 　　　TEST_EXT2 　　　YES

SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

レコードが選択されませんでした。

SQL> CREATE TABLE TEST_EXT3(col1 number)
2 STORAGE(INITIAL 100M) TABLESPACE TEST_EXT2;

とかやっても、領域は取得しないし、表領域は拡張しないし、
データファイルも大きくならないので、勘違いは禁物ってことで。

SQL>　CREATE TABLE TEST_EXT3(col1 number) SEGMENT CREATION IMMEDIATE
STORAGE(INITIAL 100M) TABLESPACE TEST_EXT2;

データ挿入時に領域獲得させたくないとかであれば、
「SEGMENT CREATION IMMEDIATE」付けましょう。

ということで、だから何？って感じですが、満足したのでした。

次回：INITIAL_EXTENTと遅延セグメント作成な話3

INITIAL_EXTENTと遅延セグメント作成な話1

2012-09-10T21:00:00.000+09:00

ちょっと気になったのでやってみたのだけど、
個人的にはツボったのでメモしておく。
何の得もない内容です。

----
環境
----
Windows7 64bit
Oracle: 11.2.0.3.0 64bit

SQL> select TABLESPACE_NAME,INITIAL_EXTENT,MIN_EXTENTS from dba_tablespaces where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME INITIAL_EXTENT MIN_EXTENTS
--------------------------- -------------- -----------
TEST_EXT 　　　　　　　 65536 　　　 1

INITIAL_EXTENT ：初期エクステントのデフォルトのサイズ
MIN_EXTENTS：エクステントのデフォルトの最小数

それぞれよく見る数値です。

初期エクステントサイズは64KBで、1ブロック8KBとすると、
エクステントは1個で、初期エクステントは8ブロックですね。

じゃ、64KBで表領域作れるってこと？

SQL>create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 64K;

create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 64K
*
行1でエラーが発生しました。:
ORA-03214: 指定したファイル・サイズが必要最小値を下回っています。

うーん、エラー
まぁ、管理情報とかのオーバーヘッドもあるよね、
64KBから1KBずつ増やしていきます。

SQL> create tablespace test_ext datafile 'C:\app\oracle\oradata\orcl\test_ext01.dbf' size 81K;

表領域が作成されました。

81KBで作れました。

ちなみに、KROWNでエラー番号を検索すると、文書番号：35170に
表領域の最低値の目安が書いてあります。

使用可能エクステントを確認します。
SQL> select TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS from dba_free_space where tablespace_name like 'TEST_EXT%';

TABLESPACE_NAME BLOCK_ID BYTES BLOCKS
------------------- ---------- ---------- ----------
TEST_EXT 4 　　 65536 8

ブロックID4から8ブロック64KB使えるようです。
ブロックID4より前の3ブロックは管理用に使ってるんですかね。

あり？？
8KB×12ブロック=96KB。。。

81KBで作ったのに？？？

SQL> select tablespace_name,bytes/1024 from dba_data_files where tablespace_name ='TEST_EXT';

TABLESPACE_NAME BYTES/1024
------------------------ ----------
TEST_EXT 88

ん？88KB＝11ブロック？？

C:\app\oracle\oradata\orcl>dir TEST_EXT01.DBF

98,304 TEST_EXT01.DBF

！！

96KB！？　12ブロックだ。。

ぐぬぬぬ。油断ならん。。

次回は、表領域が出来たのでオブジェクトを作っていきます。

次回：INITIAL_EXTENTと遅延セグメント作成な話2

JPOUGのイベントでOracle設計について話しました。

2012-07-27T20:37:00.000+09:00

私は、Japan Oracle User Group (JPOUG)のメンバーであり、
Board Memberの一人でもあるのですが、

先日7/21(土)の「　JPOUG> SET EVENTS 20120721　」イベントのアンカンファレンス枠にて、

20分程度でOracle の設計関係(インフラ周り)の話をしました。

セッションの目的は以下2点です。

・Oracle設計の概要や注意点を知る

・Oracle設計への漠然とした不安の払拭

Oracle設計について話をしようと思った背景は、

仕事柄、設計を担当することが多いことと、

ちゃんと設計しておけばこんなことには、、、

というDBと出会ったりすることがあるため、

もっと多くの人が、設計を出来るように知識を共有したい、

うーん。。というDBが一つでも減ることを願ってでした。

セッションには50人前後の方が参加頂いたようですが、

何かしら得てもらえてたのなら幸いです。

色々伝えたいことが多過ぎて、20分では話し切れないこともあり、

飛ばしてしまった内容もあったので、

公開した資料をご確認頂ければと思います。

Oracle設計 from Kouta Shiobara

参加頂けなかったが、資料を確認される方へですが、

セッションでは以下の点を強くお話ししました。

・基本や機能は常々勉強しておこう

・システムをイメージし、よく考え、設計しよう

・当たり前のことををきっちりやろう
・要件はシステム全体で担保する。(Oracleだけで無理に担保しようとしない)
・サイジングでは悩み過ぎない。(悩む≠考える)

・分からなければ、実際に作ってみよう。やってみよう。

アーキテクチャや機能といった基本を身に付けていれば、

機能の詳細やパラメータなどについては、

オラクル社提供のマニュアルをきちんと確認しつつ進めればいいと思います。

(制限事項もちゃんと調べましょうね。)

それにより、新しい発見や再発見があるのも、

設計の楽しい部分の一つだと私は思います。

なお、資料について質問やご意見、うちの会社でちょっと話してよ。

みたいなのがあれば、コメントやメール等で気軽にご連絡下さい。

JPOUGに興味が湧いた人はこちらを確認ください。

http://www.jpoug.org/

イベントの報告や他の発表者の方の資料等については、

別途投稿しますね。

Oracle DB 移行作業おける事前検討1

2012-05-18T16:56:00.000+09:00

先日、日本オラクル社の無償セミナーである
「秘訣を直伝！最新オラクルデータベースへのアップグレードテクニック」を受講してきた。

アップグレードや移行に関するチップス・見ておくべき情報、
手法についてのケーススタディが詰め込まれており、かなり有益だった。

　以下、自分のメモ用に何点かポイントを書いておく。(私の意見も入っています。)
　※1.以下、文章が長くなるので、特定の理由がない限り
　　　アップグレードや移行を同義語として、移行とする。
　※2.移行≒アップグレードを含む移行として記載している。

　前回：アップグレードや移行作業前のお作法

今回はテスト計画とネットワークへの考慮について

1)テスト
　・移行テスト(リハーサル)
　　-手順通り問題なく実施できるか
　　-所要時間

　　大事ですよね。
　　手順に漏れがないか、所要時間を計測して計画停止時間の見積もりや
　　移行手順の再検討を行う。
　　あと、手順と計画停止時間に関連して、
　　切り戻し判定ポイントや切り戻し条件や
　　切り戻し手順を移行計画手順書に忘れずに含めることが必要。

　・移行後の環境でのパフォーマンステスト
　　　-移行前環境とのパフォーマンス比較
　　　-レスポンス要件やスループット要件を満たせているか、
　　　バッチがタイムスケジュール内に終了するか

　　　新しいOS、マシン、バージョンに移行して遅くなるケースはほとんどないと思うが、
　　　DB統合などで、複数のDBが1DBサーバ上or RAC上に相乗りするという場合は、
　　　パフォーマンステストの分析により、
　　　OSやOracleのパラメータの調整やSQLの実行計画の固定化、
　　　リソース制御などのチューニング、
　　　今後ボトルネックとなる箇所の想定などが必要。
　　　ファイルのレイアウト調整やRAID調整をその時点でやるとしたら、
　　　設計そのもののミスかしら。。
　　　ハードリソースの追加は避けたいところ。

　　　言うまでもないが、移行前の環境でパフォーマンス・データを取得しておかないと
　　　比較できない。また、移行の計画段階から移行先でどのようなパフォーマンステストを
　　　どのような手段で実施するのかなどを検討しておく必要がある。
　　　例)どの時点で？どのようなデータで？どのようなツールで？どのような処理を？

　　　※パフォーマンス・データの取得方法はSTATSPACKやAWR、
　　　　　サードベンダツールやOSSツールでの取得なんでもいい。

　2)ネットワーク環境の考慮
　　物理的な限界は超えられない。

ネットワークインターフェース	データボリューム	最大転送速度
100Mbit Ethernet	11MB/sec	40GB/hour(best case approach)
1Gbit Ethernet	110MB/sec	400GB/hour(best case approach)
10Gbit Ethernet	1.1GB/sec	4TB/hour(best case approach)
InfiniBand 4X QDR	4GB/sec(theoretical) 3GB/sec(realistic)	10.8TB/hour

・プロトコル転送

　-ftp,scp,NFSのパラレルコピーを検討

・ネットワーク機器やセキュリティ設定による制限

・外部ネットワークプロバイダによる制限と距離的な制限

Oracle DB アップグレードや移行作業前のお作法

2012-05-14T14:03:00.001+09:00

先日、日本オラクル社の無償セミナーである
「秘訣を直伝！最新オラクルデータベースへのアップグレードテクニック」を受講してきた。

アップグレードや移行に関するチップス・見ておくべき情報、
手法についてのケーススタディが詰め込まれており、かなり有益だった。

　以下、自分のメモ用に何点かポイントを書いておく。
　※1.以下、文章が長くなるので、特定の理由がない限り
　　　アップグレードや移行を同義語として、移行とする。
　※2.移行≒アップグレードを含む移行として記載している。
　※3.以下、SQL文は環境によっては少なくない負荷を掛ける可能性があるので、
　　　実行タイミングは考えましょう。

　　前回：OralceDB移行・アップグレード前に見ておきたい資料

■サニティ・オペレーション
　　ここで言うサニティ・オペレーションとは、
　　簡単に言うと、移行作業前に移行元の環境を整理・綺麗にしておこうね。
　　この作業は、すべてのアップグレードや移行作業にも有効。

１)INVALIDオブジェクトへの対応
　　1-1)INVALIDオブジェクトのチェック
　　　　　SQL> ｓelect unique OBJECT_NAME,OBJECT_TYPE,
　　　　　　　　　OWNER from DBA_OBJECTS where STATUS='INVALID';

　1-2)移行作業前にすべてのINVALIDオブジェクトを修正
　　　　と資料にはあるが、1-1)の結果を精査して不要なものは削除、
　　　　必要なものは、原因を調査してVALIDにいう感じが妥当かな。
　　　　そもそも、運用中にINVALIDになっているなら削除していんじゃない？
　　　　という考え方はありだと思う。

　1-3)SYSやSYSTEMスキーマのINVALIDオブジェクトをなくす。
　　　　移行作業前にutlrp.sqlでINVALIDオブジェクトを再コンパイルする。
　　　　うーん、1-2)の対応としてもutlrp.sqlは有益かも。

　　　　※utlrp.sqlは$ORACLE_HOME/rdbms/admin/utlrp.sql　SYSで実行。

2)SYS/SYSTEMの重複オブジェクトの対応
　　普通はこんなことはないだろうけど、
　　パッチ適用後の流し忘れや、特定コンポーネント使用時の流し忘れ、
　　実行ユーザ間違いとかで発生する。

　2-1)SYS/SYSTEMの重複オブジェクトをチェック
　　　　SQL> ｓelect OBJECT_NAME,OBJECT_TYPE　from
　　　　　　　　DBA_OBJECTS where OBJECT_NAME||OBJECT_TYPE
　　　　　　　　in (select OBJECT_NAME||OBJECT_TYPE from DBA_OBJECTS
　　　　　　　　where OWNER='SYS') and OWNER='SYSTEM' and
　　　　　　　　OBJECT_NAME not in ('AQ$_SCHEDULES_PRIMARY',
　　　　　　　　'AQ$_SCHEDULES','DBMS_REPCAT_AUTH');

　2-2)SYS/SYSTEMの重複オブジェクトの修正
　　　　基本は、2-1)で出力されたオブジェクトのSYSTEM側のものを
　　　　削除(drop)するようですが、HELP～というオブジェクトのみはSYSTEM側を残す模様。

　　　　・How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema [ID 1030426.6]
　　　　　も合わせて参照とのこと。※大体同じことしか書いてない。

3)INVALIDなコンポーネントの対応
　3-1)INVALIDオブジェクトのチェック
　　　　SQL> ｓelect substr(COMP_ID, 1, 10) compid,
　　　　　　　　substr(COMP_NAME,,24) compname, STATUS,VERSION
　　　　　　　　from DBA_REGISTRY where STATUS != 'INVALID';

　3-2)移行作業前に全てのVALIDではないオブジェクトを修正
　　　　と資料にはあるが、3-1)の結果を精査して不要なものは削除、
　　　　必要なものは、原因を調査してVALIDにいう感じが妥当かな。
　　　　そもそも、運用中にINVALIDになっているなら削除していんじゃない？
　　　　という考え方はありだと思う。

　3-3)utlrp.sqlで再コンパイルしても、ステータスが修正されない場合
　　　　以下の内容により追加の診断が必要

　　　・Information On Installed Database Components and Schemas [ID 472937.1]
　　　　 -各コンポーネントの説明や参考noteが示されており、とても便利。
　　　・How To Diagnose Components With NON VALID Status In DBA_REGISTRY
　　　　After an Upgrade [ID 753041.1]

4)ゴミ箱を空っぽに
　　10g以降のバージョンからの移行である場合は移行元にてrecyclebinをパージする。
　　SQL> purge DBA_RECYCLEBIN;

5)古いパラメータや隠しパラメータ、イベントパラメータの設定解除
　　アップグレード時間が49分⇒7分になった事例もあるとのこと。

　　-----

　　以上だけど、基本は不要なものやゴミを綺麗にしておきましょうってことですね。
　　アップグレード時や移行時のコンパイル対象や移行対象が減るだけでも、
　　処理時間は短くなるだろうし。
　　そもそも、INVALIDなオブジェクトを事前にチェックしておかないと、
　　アップグレードや移行後に作業によりオブジェクトがINVALIDになったか
　　判断できなくて混乱するよね。

　　一手間の事前準備で作業時間の短縮や作業失敗のリスクを低減出来るなら、
　　是非実施しておきたい作業ですね。

Oracle DB 移行・アップグレード前に見ておきたい資料

2012-05-13T09:00:00.000+09:00

昨日、日本オラクル社の無償セミナーである
「秘訣を直伝！最新オラクルデータベースへのアップグレードテクニック」を受講してきた。

個人的にはセミナーによって、当たり外れの落差が激しいと感じているのだけど、
昨日は当たりだった。ありがとうございました。

アップグレードや移行に関するチップス・見ておくべき情報、
手法についてのケーススタディが詰め込まれており、かなり有益だった。

以下、自分のメモ用に何点かポイントを書いておく。

1.パッチセットのロードマップ
・Release Schedule of Current Database Releases [ID 742060.1]
-Release 10.1 to 11.2までのPatch Set Release(PSR)のリリース日やら
　サポート予定が書いてある。
予定だと11.2.0.4.0は来年かぁ。。

2.アップグレード手引書
11.1.0.X(11gR1)
・Oracle 11gR1 Upgrade Companion [ID 601807.1]
・Oracle Database 11gR1 Upgrade Companion - 目次[KROWN#134166]

11.2.0.X(11gR2)
・Oracle 11gR2 Upgrade Companion [ID 785351.1]
・Oracle Database 11gR2 Upgrade Companion - 目次[KROWN#141177]

-KROWNめちゃめちゃ分かりやすい。
移行方法別のメリットとデメリットも載ってる。
3.のマニュアルと共に移行の話が上がった際に事前に目を通して
おくべき資料だ。

3.アップグレードマニュアル
Oracle Databaseアップグレード・ガイド11g リリース2(11.2)

　-やっぱりチェックしとかないとね。

4.その他の重要なノート
・Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]
・Complete checklist for manual upgrades of Oracle databases
　　from any version to any version on any platform (documents only from
　　7.3.x>>8.0.x>>8.1.x>>9.0.x>>9.2.x>>10.1.x>>10.2.x>>11.1.x>>11.2.x) [ID 421191.1]

-2.よりも、もっと実際的な手順や内容が多い。
移行にくらべ、同一筐体内でのアップグレード案件はあまりないような気がするが、
事前・事後の内容はお作法としても知っておきたい。

5.OTNのOracle Database Upgrade
-中段には今回のセミナー資料の元資料のダウンロードページに行けます。
560ページのPDF資料って、、、

バージョンアップや移行(バージョンアップを含む)のどちらも、
バージョンが変わることによる仕様や動作の変更点や、
バージョンアップ後のリリースのバグ等を押えておくべきなのは変わらない。
移行の場合には、さらに移行方法の検討というタスクが重要。

上の資料だけど、
時間がない場合は、上記資料2のKROWNと4の内容の事前事後の作業部分を
さらさら読むのがいいだろう。

時間があって本腰を入れて取り組む人は、5から入るのが良いと思う。

言うまでもないけど、1,2,4の資料は保守契約がないと読めないのでご注意を。

次回以降もこのセミナーネタをメモメモしていく予定。
※いずれ、セミナー資料自体が公開されると思いますが。

Oracle OpenWorld 2012 Unconference presented by JPOUG

2012-04-10T07:20:00.017+09:00

久しぶりの記事になります。
なぜ久しぶりかというと、タイトルにもありますが、
「Oracle OpenWorld 2012 Unconference presented by JPOUG」の準備や、
私もセッションを持っていたことから、そちらに集中していたことがあります。

今回のイベントは、JPOUGにとって初めての公の大きな舞台での活動だったのですが、
Unconferenceの運営を任せて頂いた関係者の皆様、ありがとうございました。

また、お越し頂いた皆さんもありがとうございました。
楽しめたでしょうか？

私の担当セッションは、トップバッターということもあり、
最初は緩いネタがいいだろうということで、Oracleのマニュアルについて話しました。
しかも40分間も(笑)

伝えたかったのは、
　「マニュアルの面白さや有益さ」
　「ググってるだけでは見えてこないこと」
　「英語サイトの有効活用のすゝめ」
　「スマートなマニュアル活用術」
になります。

誰得？とも思ったのですが、
一応、デモ部分も含めて分かるように、加筆した資料を公開しました。
誰かの役に立てば幸いです。

実はとても面白い...Documentation library

View more presentations from Kouta Shiobara

また、セッション後のフィードバックとして、
JPOUGサポートメンバーである日本オラクルの小田さんからアドバイスを頂き、
資料で紹介した以外のマニュアルの検索情報も載っているサイトがありましたので、
記載しておきます。(小田さん、ありがとうございます。)

Oracleエンジニア通信-Oracle マニュアル

最後になりますが、JPOUGの活動としては、次回は初夏に大きなセミナーを検討しています。
是非、そちらも楽しみにしててくださいね。

JPOUG公式サイト
JPOUG Facebookページ
※「Oracle OpenWorld 2012 Unconference presented by JPOUG」僕以外の人の
　セッション資料も見れますよ。

Japan Oracle User Group(JPOUG)について#3

2012-03-09T02:12:00.004+09:00

前回に引き続き、Japan Oracle User Group(JPOUG)について書きたいと思います。

ブログを更新した旨をRTして下さった皆さん、ありがとうございます。<(_ _)>
沢山の方にJPOUGを紹介出来てとても嬉しいです。
今回が最終回なので、、、ね！ね！(笑)

RTやらブログ見て「いいね」してくれた人、
はじめましてです。これから一緒に楽しくやっていきましょう。
もちろん、RTしてくれて良くってよщ(ﾟ▽ﾟщ)

ということで、今回は最後に、僕からのお願いと楽しみ方の続きについて書きます。

1.みんなの声を聞かせてくださいщ(ﾟ▽ﾟщ)
　既に何度か紹介していますが、
　「Oracle OpenWorld Unconference presented by JPOUG」と題して、
　JPOUGはOracle OpenWorldをハイジャック!?することにしました。

　そのUnconferenceで僕はセッションを担当するのですが、
　みんなと一緒に楽しめるUnconferenceをやりたいと考えています。
　そのネタの一つとして、現在FBのJPOUGページでアンケート2つ行っています。

　-Japan Oracle User Group (JPOUG)の質問-
　自由にいくつでも投票してほしいし、なければドンドン追加してくださいщ(ﾟ▽ﾟщ)

　
　知らないものがあったら調べてみるのもいいかもですﾟ+.(･∀･)ﾟ+.ﾟ

　あと、FBをやってない方はGoogleDocsからも投票が可能です。
　-Oracler意識調査のお願い♪-

　こちらは名前とかは記入不要ですので、FBやってるけどちょっとね。。。
　という方はこちらに投票下さい。

　Unconferenceでは結果を考察するとともに、
　なぜそれが好きなのか？を熱く語る時間も用意しようと思っています。
　是非是非、アンケートもUnconferenceもよろしくです。

　鼓動枠もまだ何枠か残っている様なので、興味のある人は是非応募してみて下さい。
　“鼓動枠”オーガナイザーの募集
　OracleOpenWorldTokyo
　wmo6hash::blog Oracle OpenWorld Unconference presented by JPOUG
　※三年前の様子も分かります。

2.書いてみる、聞いてみる、やってみる、集まってみる
　JPOUGはユーザ会であり、みなさんそのものです。
　たまたま僕はBoard Memberをやっていますが、
　僕も一人のユーザ会のメンバーにすぎません。

　FBのウォールに、自分のブログをリンクするのも、
　共有したいこと書くのも、企画を提案してみるのも、
　僕がユーザ会のメンバーとしてやりたいからやっているだけです。

　みんなも先ずはやりたいように使ってみてください。
　(問題がありそうなものであれば、運営の方でサックリ行くので　笑)

　ただ、もし、やりたいことがFBの管理者じゃないと出来ないとか、
　FBとかではなく、もっと大きなこんなことしたんいんだ、
　こんなことはできないのか？というものがあれば是非連絡を下さいね。

　例)FBでクエスチョンしたいけど、管理者じゃないから出来ないとか

　あと、FB以外のコミュニケーション方法も用意しているので、
　こちらも是非見てくださいね。
　コミュニケーション

・・・・

　また今日も長くなってしまいました。。

　でも今回でJPOUGの紹介記事はお終いにします。

　最後に一言だけ。

　僕らBoard Memberはみんなと出会い、一緒に何かをしたい。
　その思い一つを胸に、去年の夏から準備をしてきました。

　「はじめまして、こんにちは。これからよろしくね。」

KROWN、有効活用したいよね。

2012-03-08T12:00:00.002+09:00

FBのJPOUGページに書いた
KROWN#136531ネタに「いいね」してくれた人がいたので、
父ちゃん浮かれて、張り切ってブログなんか書いちゃいますよ(*ﾟ∀ﾟ)=3

何かあるといきなりGoogleやKROWNを検索しがちですが、
情報が断片的だし時間がかかるのでやめた方がいいです。

と、
そんな思いからやるのが、
「Oracle OpenWorld Unconference presented by JPOUG」の僕のセッションです。

宣伝しつこい？(笑)

と、まぁそれは置いといて、

まとめKROWNですが、[マスターノート]って言うんですね、
マスターノートって、まぁ索引みたいなものじゃないですか、
有効活用しない手はないと思います。

KROWN検索画面のキーワード部分にマスターノートを指定して
文書タイプの「マニュアル・パッチについての文書」にチェックを入れて検索すると、
純粋なマスターノートだけを検索できます。

闇雲にKROWNを検索して時間を潰しちゃうくらいなら、
有効活用したいですよね。

まぁ、エキスパートの方々はMOS(My Oracle Support)一択とか言っちゃうんですけど。。。

こんなネタが豊富にあるよ。そう、JPOUGならね。

Japan Oracle User Group(JPOUG)について#2

2012-03-07T23:24:00.006+09:00

前回に引き続き、Japan Oracle User Group(JPOUG)について書きたいと思います。

ブログを更新した旨をRTして下さった皆さん、ありがとうございます。<(_ _)>
今回も宜しくお願いします(笑)

RTやらブログ見て「いいね」してくれた人、
はじめまして。これから楽しくやっていきましょう。
もちろん、RTしてくれて良くってよщ(ﾟ▽ﾟщ)

ということで、今回は、例えばどんなことしている？できるの？
について書きたいと思います。

1.JPOUGはみんなの出会いや語らう場を創出します。
http://www.facebook.com/jpougfan?sk=wall

使い方は、、、まぁ、自由に書き込んでください(笑)
感動したことや、共有したい技術情報、
飲み会の企画やOracle技術者同士の合コン企画なんかも面白いかもしれません。
是非、結婚式で出会いは「JPOUGでした」とお披露目してください(笑)

気軽に書き込みやコメントしてくださいね。

例えばですが、僕は今日こんなことを書き込みました。
「KROWN#136531っていいよね。STATSPACKに読み替えても理解が深まるし。
他にも、まとめKROWN増えたよねー」

・・・。

まだ、誰もコメントくれていません(´Д`)
そんな知ってて当たり前！とかもっといいの知ってるぜ！とか。"φ(･ｪ･o)~ﾒﾓﾒﾓ
とか反応がないと寂しいなぁ・・・('･_･`)

・・・。気軽に書き込みやコメントしてくださいね。
Board Memberも楽しみにしています。

2.知識や発見、感動などをみんなへ発信する場を創出します。
JPOUGは初夏に大規模なセミナーを企画していますが、
まずは、デビュー戦(みんなへの挨拶の場と)して、
「Oracle OpenWorld Unconference presented by JPOUG」と題して、
Oracle OpenWorldをハイジャック!?することにしました。

Unconferenceとは誰もが参加できるカンファレンスで、
オーガナイザーの話を一方的に聴くのではなく、参加者の意見や質問によってインタラクティブに
進行する技術セミナーです。

僕は、2セッションを持つ予定です。

です。。。。

でした。。。。。。

が、

やはりそこは、JPOUG！
「場」や「機会」を創出するのが意義！！

小生のつまらない(嘘ですよ嘘。きっと。。)セッションを1つ解放して
“鼓動枠”と題して、発表者を募集します！！！
「誰かと何かを共有したい!」と思う人は是非手を挙げてみて下さい。
5分でも10分でも20分でも、発表を楽しみにしています。

詳細についてはこちらを確認してくださいね。
“鼓動枠”オーガナイザーの募集
OracleOpenWorldTokyo

・・・・

また今日も長くなってしまいました。。

僕からのお願いやら、まだまだJPOUGの楽しみ方があるのですが、
それはまた次回の記事で。

Japan Oracle User Group(JPOUG)について#1

2012-03-06T23:25:00.007+09:00

僕はJPOUGのBoard Memberの一人なんですが、
本投稿はいつもの技術ネタじゃなくて、Japan Oracle User Group(JPOUG)について
ちょっと書きたいと思います。

Japan Oracle User Group(JPOUG)は去年の10月に発足した、
IOUC(International Oracle Users Group Community)にも参加している
日本のOracleユーザグループです。

設立趣旨はJPOUGサイトを見てもらえればと思います。
Board Memberによっても少しずつ思いが違うところもあるかもしれないのだけど、
簡単に言うと、OracleユーザやOracle好きな人同士で繋がったり、楽しんだり、
一緒に何かしたりする、「機会」や「場」を創出する活動を行っています。

大切にしているのは、「面白いこと」や「ためになること」ではなく「機会」や「場」を
「与える」のではなく「創出」することです。

JPOUGとはなんなのか？どう楽しめばいいのかは、うまく説明できません。
Board Member自身、オラクルという単語を中心とした出会いや化学反応を
楽しみにしているユーザ会の一員なのです。

例えばとして、個人的なエピソードを1つお話しすると

Board Memberで打ち合わせしたり、飲んだりしている時に、
僕は、ふと不思議な気持ちになることがあります。

Oracleのユーザ会だから、Oracleの話ばかりしていると思いきや、会話は多岐に亘ります。
家族のことや趣味のこと、働き方や技術動向。
もちろん異性の話もしたりしなかったり。

年上のメンバーから、色々な人生経験やアドバイスをもらったり
年下のメンバーの初々しさに若さや懐かしい思いをもらったり(笑)

JPOUGをやっていなかったら、Oracleの技術力アップはさることながら、
こんな風に色々な経験もなかったんだろうなぁ、、、と

年齢や仕事もバラバラな僕らは、
Oracleというものを共通に知り合い、集っているんだなぁと。

とても不思議な気持ちなります。

もっと沢山の人に同じように不思議な気持ちになってほしいなと思います。

・・・

ちょっと長くなってしまったので、具体的に例えばどんなことしているの？
という説明はまた次回に。

一緒にOracleで楽しんだり、新しい何かに出会ってみたい人は、
JPOUGファンページ　でイイねを押してください。

押さなくてもウォールは見れるけど、色々言葉を交わしませんか？

facebookやってない人は、グーグルで繋がってみませんか？
JPOUGのGoogle グループ

あ、最後になっちゃいましたが、
僕らBoard Memberは、それぞれちゃんと生業があり(当たり前ですが)、
JPOUGのファンページが「イイね」されたからといって、何の得もありません(笑)

Oracleのユーザ会のメンバーだからといって、Oracleを褒め称えているでもありません。
特に僕は？f(^^);

なんか質問があったら、気軽にコメントでもTiwtterでもメールでも連絡下さいね。

11gにおける一時表領域がSYSTEM表領域なユーザに関する考察#3

2012-02-16T00:54:00.001+09:00

(今回はいつにも増して下らないネタ…)

11.2.0.3.0時代、あるところに、ユーザのデフォルト表領域がSYSTEM表領域で、
一時表領域もSYSTEM表領域のユーザがおったそうな。。

前回はDBを新規に作ってみました。
SYSTEM表領域をディクショナリ管理表領域で作成すると、
TEMP表領域を作成しないという選択が出来ることが分かりました。

また、SQLリファレンスにある通り、
ユーザの作成時に一時表領域の指定を省略した場合、かつ
データベースのデフォルトの一時表領域が指定しなかった場合は、
ユーザの一時セグメントはSYSTEM表領域に格納されました。

検証を通して分かったことを纏めます。
1)DBCAでDBを作成しようとするとSYSTEM表領域の
　エクステント管理はローカル管理
2)データベースがローカル管理となっている場合は、一時表領域が必要
3)データベース作成時に一時表領域が作成される場合は
　ユーザ作成時に一時表領域の指定を省略しても
　ユーザの一時表セグメントはデータベース作成時の一時表領域に格納される

つまり、何らかの理由でディクショナリ管理のSYSTEM表領域で
データベースを作成したが、
その際に一時表領域は作成しなかった。という状況が考えられる。

11gのSYSTEM表領域のエクステント管理のデフォルトはローカル管理であること、
管理者が意図的にユーザの一時表領域に、SYSTEM表領域を指定する可能性は
低いと考えられることから、
「過去環境のDBを作成したDB作成スクリプトを再利用して新環境のDBを作成した。」
というのが原因なのだろうか。
ただ、過去のバージョンにおいてもユーザの一時セグメントの格納先が
SYSTEM表領域だった可能性は少ないと思うので(のはず)、
ユーザの作成スクリプトかなんかを流す順序に問題があり、
追加でデータベースのデフォルト表領域を作成するスクリプトを流す前に、
ユーザ作成スクリプトを実行してしまっていた。
というところだろうか。。

なんとなく、ありそうな話だ。。。

で、何が言いたいかというと、

移行前の過去バージョンのDB作成スクリプトが、
SYSTEM表領域をディクショナリ管理で作っているようなことがなく、
一時表領域を作っていないようなもので、
それをそのまま使って新環境に11gのDBを作ろうとしない限りは、
ユーザの一時セグメントの格納先がSYSTEM表領域になっていて、
気が付いたら一般ユーザのソート処理をくらっていて、
気が付いたらSYSTEM表領域が肥大化しているということは、
まずありえない。

かなりまぐれとかなんやかんやが続かない限りは、きっとね。

11gにおける一時表領域がSYSTEM表領域なユーザに関する考察#2

2012-02-16T00:01:00.004+09:00

(今回はいつにも増して下らないネタ…)

11.2.0.3.0時代、あるところに、ユーザのデフォルト表領域がSYSTEM表領域で、
一時表領域もSYSTEM表領域のユーザがおったそうな。。

前回は既存のDB環境で色々やってみましたが、
一時表領域がSYSTEM表領域なユーザは作れませんでした。
どうやらデータベースのデフォルトの一時表領域が関係してそうなのは
分かりましたが、その設定をSYSTEM表領域に変えられません。

うまくいかないので、DBそのものから作り直してみます。


■環境
Windows7 64Bit
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64Bit

データベースの作成⇒カスタムデータベースの作成⇒表領域作成画面
TEMP表領域をGUIから削除します。


むかっ。


じゃあいい、DB作成スクリプト生成して、
スクリプト編集してTEMP作成する部分を削除して実行してやるっ！

CREATEDB.SQL抜粋
=========================================================================
・・・
MAXDATAFILES 100
 DATAFILE 'C:\app\oracle\oradata\orcl2\system01.dbf' SIZE 700M REUSE
 AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED　EXTENT MANAGEMENT LOCAL
  SYSAUX DATAFILE 'C:\app\oracle\oradata\orcl2\sysaux01.dbf' SIZE 600M REUSE
  AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
   SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE 
   'C:\app\oracle\oradata\orcl2\undotbs01.dbf' SIZE 200M REUSE
    AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED

CHARACTER SET JA16SJISTILDE

・・・
=========================================================================
行1でエラーが発生しました。:
ORA-12900: ?????????????????????????????????????? 


=========================================================================
ORA-12900: ローカル管理データベース用のデフォルトの
　　　　　 一時表領域を指定する必要があります。
原因: ローカル管理データベースには、SYSTEM表領域以外に一時表領域が必要です
処置: ローカル管理データベースの作成時に、
      デフォルトの一時表領域を指定してください。
=========================================================================


むかむかっ。

SQLリファレンスのCREATE DB文を確認します。
=========================================================================
extent_management_clause

この句を使用すると、ローカル管理SYSTEM表領域を作成できます。
この句を指定しない場合、SYSTEM表領域はディクショナリ管理となります。

注意:
ローカル管理SYSTEM表領域を作成すると、
この表領域をディクショナリ管理に変更することはできません。
このデータベース内に別のディクショナリ管理表領域を作成することも
できません。
この句を指定した場合、ローカル管理のSYSTEM表領域には
一時セグメントを格納できないため、データベースにデフォルトの
一時表領域が必要になります。

EXTENT MANAGEMENT LOCALを指定して、DATAFILE句を指定しない場合は、
default_temp_tablespace句を省略できます。
Oracle Databaseは、データファイル・サイズが10MBで、
自動拡張を使用禁止にした状態で、TEMPという一時表領域を作成します。

EXTENT MANAGEMENT LOCALおよびDATAFILEの両方の句を指定する場合は、
default_temp_tablespaceを指定し、その表領域のデータファイルを
明示的に指定する必要があります。

default_temp_tablespace
この句を指定すると、データベースのデフォルトの一時表領域を作成できます。
Oracle Databaseは、この一時表領域に対して、別の一時表領域を指定していない
ユーザーを割り当てます。
この句を指定しないと、
データベースがローカル管理のSYSTEM表領域の作成時に、
デフォルトの一時表領域を自動的に作成しない場合、
SYSTEM表領域がデフォルトの一時表領域になります。
==========================================================================

なんか最後の三行は矛盾している気もするけど、
とにかくSYSTEM表領域がローカルだと、ローカル管理データベースとなり、
SYSTEM表領域以外に一時表領域が必要というなら、
ディクショナリ管理でSYSTEM表領域作ってやろうじゃない。


CREATEDB.SQL抜粋
・・・
MAXDATAFILES 100
 DATAFILE 'C:\app\oracle\oradata\orcl2\system01.dbf' SIZE 700M REUSE
 AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED　
 EXTENT MANAGEMENT LOCAL　←削除
  SYSAUX DATAFILE 'C:\app\oracle\oradata\orcl2\sysaux01.dbf' 
  SIZE 600M REUSE　AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
   SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE 
   'C:\app\oracle\oradata\orcl2\undotbs01.dbf' SIZE 200M REUSE
    AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED

CHARACTER SET JA16SJISTILDE

・・・

DBが作成されました。

データベースのデフォルトの表領域を確認します。

SQL> select property_value,property_name from database_properties
   2 where property_name like '%TABLESPACE%';

PROPERTY_VALUE  PROPERTY_NAME
--------------- -----------------------------
SYSTEM          DEFAULT_TEMP_TABLESPACE
SYSTEM          DEFAULT_PERMANENT_TABLESPACE

いい感じ。

SQL> create user hoge2 identified by hoge2;

ユーザーが作成されました。

SQL> select username,default_tablespace,temporary_tablespace from dba_users
  2  where username='HOGE2';
  
  
USERNAME   DEFAULT_TABLESPACE        TEMPORARY_TABLESPACE
---------- ------------------------- -------------------------
HOGE2      SYSTEM                    SYSTEM

1行が選択されました。



そう。これ。これ待ってた。


冷静になって、DBCAの表領域作成箇所で、
SYSTEM表領域のエクステント管理をディクショナリ管理に変更して、
TEMP表領域の削除を実施したら。エラーなく削除できました。
(わざとDB作成スクリプトの例を出しているのですが。念のため)


次回、検証を通して一時表領域がSYSTEMなユーザがなぜできたかを考えます。