サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
out2dev.blogspot.com
■エラー内容 ORA-12516: TNS: リスナーは、一致するプロトコル・スタックが使用可能なハンドラを 検出できませんでした。 ■原因 停電などでHUBの電源が落ちた際、クライアントPCとデータベースが一度にたくさん 切断される場合がある。このとき、データベース側には、これまで接続していた プロセス・セッションが残っている。復旧後に、クライアントPCから接続されると 新たにプロセス・セッションがデータベースのメモリに割り当てされる。 つまり、サーバ上のメモリ使用量が倍近くに膨らんでしまい、もうメモリ不足(正確には データベースのプロセス・セッション用に割り当て可能な上限値を超えてしまう) で新たな接続は認めないというエラーが返ってきている。 いわゆるゾンビプロセスは、時間が経てば無くなっていくため、下記の対処を 行わなくても、待てば解決する場合もある。(端末の台数によるが1時間半程度
「メッセージ 1205、レベル 13、状態 51、行 2」 「トランザクション (プロセス ID 99) が、ロック 個のリソースで 他のプロセスとデッドロックして、このトランザクションがそのデッドロックの対象となりました。 トランザクションを再実行してください。」 このエラーが出た場合は、どう対処すればよいだろうか? 順を追って説明する。 ■デットロックとは デットロックとは、相手(別のSQL)と自分(自分が流したSQL)とで、 ロックをかけ合い、お互い相手を待つことである。 これは、どういう事かというと、処理が一切できなくなることを意味する。 データベースは、それを自動的に解除する仕組みを持っていて、心配はいらない。 しかし、片方のSQLがロールバックされてしまう。どちらがロールバックされるかだが コストが小さい(戻す処理が少ない)方が優先されるようである。 上記のエラーが出た場合、デ
■原因について 「max server memory」を指定していない場合、 物理メモリをすべて食い尽くし、SQLServer自体で 利用するメモリが不足するためと考えられる。 SQLServerの仕様のようだが、本番で発生すると痛い。 ■対処法 「max server memory」を設定して下さい。 物理メモリより当然少なくし、OSが利用する分、 SQLServerが利用する分を差し引いた残りを設定する。 トラブル時で時間がないときは、とりあえずサーバ再起動が早道 ■詳細 「max server memory」の既定値は2,147,483,647Mbytes となっている。既定値のままだとどんどんメモリを食う。 消費したメモリは、どこに使われたかというと 「バッファキャッシュ」という所に割り当てられている。 これは、あらかじめディスクから読み込んだデータを メモリ上に展開しておき、次回
このページを最初にブックマークしてみませんか?
『out2dev.blogspot.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く