(cache) 意味わかんないけどなんとかなった。今日もなんだかいい天気♪/ウェブリブログ

意味わかんないけどなんとかなった。

<< 作成日時： 2009/06/22 23:42 >>

先週の木曜くらいから、またしてもデータベースの構築作業をやっていて、特に問題もなくデータベース自体はできた。
で、設計書とか構築手順書とかを、「構築後修正」ってことでちまちまと修正する。

で、特にエラーは出てなかったんだけど、アラートログを見ていたら、

WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x000（メモリのアドレスと思う）　[flag=0x4000]

とかいう警告が出ていた。
ふむふむ、「十分な物理メモリが確保できないよ」とかいうことか。
このサーバ、私が作ったDBのほかに、あと2つDBが動いている。
そっちの方のアラートログを見てみたら、やっぱり同じ警告が出てる。
しかも構築時から。

ということは、単に「メモリが足りない」ということではなさそうだ。
でも、shmmaxの値がSGA_MAX_SIZEより小さいわけでもない。
んー、なんだろー？？？

というわけで、明日サポートに投げてみようかと思う。
（今日は既に遅かった。おねむの時間。）

で、このサーバにはあと１コ、データベースを作らないといけない。
それでマトモに動くんか、コイツ？
という根本的な不安。
（シングルCPUでメモリ8GB）

SGAやPGAは、既存DBの設定値に合わせて構築したが、実際どのくらいメモリを使っているのかを見積もってみることにした。

PGAの使用量はV$PROCESSを見ればすぐわかるが、SGAは難しい。
「現在割り当てられているサイズ」はV$SGASTATとかを見ればいいが、「どのくらい使ってるか」はどうすればわかるのか。
せめて、共有プールとバッファキャッシュの使用量は知っておきたい気がする。

共有プールの方は、コレで出るような感じがする（保証はしない）。

select to_char(sysdate,'YY/MM/DD HH24:MI:SS') "DATE",
a.USER_MEM "ユーザ使用量(MB)",
a.SQL_MEM "SQLエリア使用量(MB)",
b.CACHE_MEM "DBオブジェクトキャッシュ(MB)",
a.user_mem+a.sql_mem+b.cache_mem "共有プール使用量(MB)"
from (select sum(250*users_opening)/1024/1024 "USER_MEM", sum(sharable_mem)/1024/1024 "SQL_MEM" from v$sqlarea) a,
(select sum(sharable_mem)/1024/1024 "CACHE_MEM" from v$db_object_cache) b;

ちと不恰好なSQLだけれども、これで出るらしい。
（ORA-00972とか出たら、列別名をローマ字にするといいです。）

これを定期的に実行して、推移を生温かく見守った。
（STATSPACKで取ればいいじゃん？というツッコミが入りそうだが、そこはもちろん忘れてた。ま、レポートを見るのもめんどくさいし。）

バッファキャッシュの方は、キャッシュヒット率が99.00～99.05％くらいをウロウロしてたので、まぁいいかということで放置。
で、余ってる（と思われる）共有プールの分をちょこっと（100MBくらい）減らして、一応DBを再起動。

すると・・・

起動しない。

「ORA-24324：サービス･ハンドルが初期化されていません。」
「ORA-01041：内部エラーが発生しました。hostdefエクステンションが存在しません。」

とかわけわかんないエラーが出た。
無免許だからハンドルはないっつーの。
エクステもつけてないし。
もしかしてプレステか？
それも持ってないぞ。

というわけで、エラーメッセージを調べてみると、やっぱり意味わかんねぇ。
ORA-01041に至っては、「この問題はバグとしてオラクル社カスタマ・サポート・センターに連絡してください。」とか書いてある。
ほう、そうかそうか。いい度胸してるじゃねぇか。
明日連絡してやってもいいが、午後9時なんだっつーの。
さっさと帰りたいんだっつーの。

とりあえず、セッションを切断。
もう一度接続しなおして、STARTUPしてみる。
すると、さっきのわけのわからんエラーは出なかったが、かわりに、

「ORA-03113：通信チャネルでend-of-fileが検出されました。」

が出てきた。
あぁ、キミの方がまだなじみがあるねぇ。
キミの場合は、接続をきっちりとやり直したら直る気がする。そんな気がする。
今までだってそうだった。これからだって、そうに違いない。

だって、「3113」は、いいヤツなんだよ。
昔のオイラの自転車のカギの番号が「3113」だったんだからねぇ。

というわけで、セッションを切断。
リスナーもSTOPしてSTARTしなおす。
LSNRCTL STATUSで、元気に動いていることを確認。

再度接続して、データベースの起動を試みる。
・・・が、失敗。
ありゃ困ったなぁ、と思って、PFILEで起動を試みたら、あっさり起動した。

【6/24追記】PFILEで起動したっていうことからもわかるけれど、「記述ミスではないが整合性がない、あるいは設定できないような記述」がある場合に上記のことが発生するらしい。

ふむ・・・。メモリの設定を変えたせいかなぁ・・・。
また明日、ちょっくら考えてみることにしよう。
ダメだったら元に戻すかぁ。