DBA のお仕事

はじめに
Oracle に携わるようになって、どれくらい経つのでしょう。以前は DB2 という
データベースに関わっていましたが、今思えばあまり理解していなかったような
気がします。しかし Oracle に携わるようになって、データベースに関するいろい
ろなことがクリアになってきました。DB2 をやっていたわたしも、今こうして
Oracle をさわっているわたしも、同じわたしなのに何かが違ったのです。もちろ
ん DB2 での基礎があったから、というのは間違いありません。ですが、理解して
いく過程を楽しく感じたというか、理解している自分を感じられたのは Oracle で
した。それは多分、わからないことがあるときにとことん質問できる相手がいた
からだと思います。バカな質問をしても答えてくれる、わかるまで説明してくれ
る方々の存在と、自分で体験できる環境があるということが大きかったのでしょ
う。どんな技術者でも最初は初心者。理解していく過程があったはずです。その
過程をなるべくわかりやすく説明したい、という強い思いがこの書籍の根底にあ
ります。
そしてこの書籍に出てくる先輩と後輩はわたしの理想
（ちょっと大げさ？）
の形であり、Oracle に関わりはじめた人は好奇心を大切にし、そんな人を育てな
くてはいけない人は少し厳しくしつつも疑問の解決のためには助け舟をだしてね、
という気持ちもこめられています。まだまだ至らない点はあるとは思いますが、こ
の書籍が少しでもOracleに携わる人々のお役に立つことを願うばかりです（なお、
本書での内容は Oracle8 を前提としたものになっています）。
最後に、連載および出版の機会を与えてくださった（株）翔泳社の方々、
本当にあ
りがとうございました。そして連載からはじまり、書籍化されるまでを支えてく
ださった小幡一郎さん、
石川雅也さんをはじめとする
（株）
インサイトテクノロジー
の皆様方、そして中でもとくに、忙しい中でも嫌がらずに面倒をみてくださった
小林修（ちゃむ）さんに、心からの感謝を捧げます。
2000 年 11 月
住民となって 6 年目の茅ヶ崎にて
鵜飼淳代
目次
第 1 章 DBA のお仕事 --- Oracle の構成を知る --- ................................ 2
やっぱり。........................................................................................ 2
Oracle の構成 ................................................................................ 3
REDO ログ ..................................................................................... 6
コントロールファイル .................................................................... 8
インスタンス .................................................................................. 9
DBA のお仕事って ....................................................................... 12
本日の成果 ................................................................ 14
Oracle の構成 .............................................................................. 14
DBA の仕事 .................................................................................. 15
第 2 章ロック待ちトラブルの解消
--- データディクショナリを活用する --- ........................................ 18
トラブル発生！！ ......................................................................... 18
ロック状況の確認と対応 .............................................................. 21
ほかにできることは？ .................................................................. 24
DBA_DEPENDENCIES .............................................................. 26
DBA の醍醐味 .............................................................................. 29
本日の成果 ................................................................ 30
インスタンスリカバリ .................................................................. 30
ロック待ちによるユーザークレームへの対処 ............................. 30
必要なデータディクショナリを探す ........................................... 32
DBA_DEPENDENCY の活用 ...................................................... 32
DBA のお仕事の醍醐味（？）を垣間見る ....................................... 33
第 3 章 SQL の効率を考える
--- TRACE と EXPLAIN PLAN の活用 --- .................................... 34
終わらない！ ................................................................................ 34
iv
SQL_TRACE ............................................................................... 35
EXPLAIN PLAN .......................................................................... 37
本日の成果 ................................................................ 42
SQL_TRACE ............................................................................... 42
EXPLAIN PLAN .......................................................................... 43
アンチジョインは NOT EXISTS で ............................................. 44
第 4 章領域の管理 --- 拡張エラーに対応する --- .................................. 46
拡張エラー .................................................................................... 46
ADD DATAFILE .......................................................................... 47
今度はインデックス！ .................................................................. 52
インデックスのメンテナンス ...................................................... 54
ロールバックセグメント .............................................................. 57
本日の成果 ................................................................ 61
テーブルスペースの拡張 ............................................................. 61
PCTINCREASE ........................................................................... 62
インデックスのメンテナンス ...................................................... 63
ロールバックセグメントの使い分け ........................................... 64
ロールバックセグメントを適正サイズに .................................... 65
第 5 章メモリの効率を考える
--- いろいろなバッファのチューニング --- .................................... 68
バッファのヒット率 ..................................................................... 68
データベースバッファ .................................................................. 70
マルチバッファプール ................................................................. 72
ログバッファ ................................................................................ 74
共有プールエリア ......................................................................... 78
本日の成果 ................................................................ 82
データベースバッファのヒット率を調べよう ............................. 82
データベースバッファの管理機構 ............................................... 83
マルチバッファプール ................................................................. 83
ログバッファ ............................................................................... 84
チェックポイント ........................................................................ 85
共有プールエリアの効率化 .......................................................... 86
v
第 6 章パフォーマンスチューニングその 1
--- ANALYZE とオプティマイザの活用 --- ................................... 90
やってしまった？！ ..................................................................... 90
ANALYZE のオプション .............................................................. 94
オプティマイザ ............................................................................ 96
ジョインの方法 ............................................................................ 97
コストベースは正しい？ ........................................................... 101
ヒント ........................................................................................ 104
本日の成果 .............................................................. 107
ANALYZE .................................................................................. 107
オプティマイザ .......................................................................... 110
ジョインの方式 .......................................................................... 111
ヒント ........................................................................................ 112
第 7 章パフォーマンスチューニングその 2
--- インデックスをもっと活用する --- ........................................ 114
インデックスが使われない？ ..................................................... 114
DECODE .................................................................................. 118
ビットマップインデックス ........................................................ 120
インデックスのダンプ ............................................................... 125
本日の成果 .............................................................. 129
インデックスが使われない SQL ............................................... 129
DECODE ................................................................................... 130
ビットマップインデックス ........................................................ 132
インデックスのダンプ ............................................................... 134
第 8 章データベースの移行その 1
--- エクスポート時の注意点 --- ................................................... 136
データベース移行任務 ................................................................ 136
エクスポート .............................................................................. 137
ハイウォーターマーク（HWM）.................................................. 141
vi
本日の成果 .............................................................. 149
エクスポート ............................................................................. 149
ハイウォーターマーク ............................................................... 151
エクステントの拡張 ................................................................... 154
コアレス（COALESCE）............................................................ 155
第 9 章データベースの移行その 2
--- データベースの作成 --- .......................................................... 158
RAID ディスク ........................................................................... 158
データファイルの配置 ................................................................ 163
データベースの作成 ................................................................... 165
MINIMUM EXTENT .................................................................. 166
PCTFREE ................................................................................... 168
本日の成果 .............................................................. 172
RAID ディスク ........................................................................... 172
ファイルの配置 .......................................................................... 174
データベースの作成 ................................................................... 175
MINIMUM EXTENT .................................................................. 177
PCTFREE ................................................................................... 178
第 10 章データベースの移行その 3
--- インポートとテスト --- .......................................................... 180
インポート .................................................................................. 180
インポート時の COMMIT .......................................................... 183
FREE LIST ................................................................................. 185
本日の成果 .............................................................. 196
インポート ................................................................................. 196
競合の調査方法 .......................................................................... 197
FREE LIST ................................................................................. 199
OS レベルのロックリソース ...................................................... 202
vii
第 11 章ロールバックセグメントとテンポラリ
--- 一時使用領域についても考慮する --- ..................................... 204
ORA-01555 ............................................................................... 204
ロールバックセグメントの考慮点 .............................................. 206
テンポラリテーブルスペース ..................................................... 209
SORT_AREA_SIZE ................................................................... 210
ソートはメモリで ...................................................................... 212
本日の成果 .............................................................. 216
ロールバックセグメントの役割 ................................................. 216
ORA-01555 ............................................................................... 217
設定時の考慮点 .......................................................................... 218
テンポラリテーブルスペース .................................................... 220
ソートはメモリで ...................................................................... 221
第 12 章ユーザーの管理 --- 権限あれこれ --- .................................... 224
ユーザーと権限 ........................................................................... 224
ロール ......................................................................................... 226
オプション .................................................................................. 229
クォータ ..................................................................................... 234
縁の下の力持ち？ ....................................................................... 236
本日の成果 .............................................................. 239
ユーザーと権限 .......................................................................... 239
ロール ........................................................................................ 241
オプション ................................................................................. 242
クォータ ..................................................................................... 244
ビューおよび列ごとの権限の設定 ............................................. 246
第 13 章バックアップ＆リカバリ
--- いざというときに備える --- ................................................... 248
現在の運用状況 ........................................................................... 248
バックアップの練習 ................................................................... 252
viii
リカバリの練習 ........................................................................... 254
DROP しちゃった？ .................................................................. 256
普通にやってもだめ？ ............................................................... 257
DROP されたテーブルを戻すには？ ......................................... 259
リカバリ本番 ............................................................................. 261
Recovery Manager .................................................................. 264
眠気も吹っ飛ぶ！ ....................................................................... 265
本日の成果 .............................................................. 266
REDO ログの運用 ...................................................................... 266
バックアップ ............................................................................. 268
データベースのリカバリ ........................................................... 271
エラーでない状態のリカバリ .................................................... 273
リファレンス ................................................................. 276
DBA_DATA_FILES ................................................................... 276
DBA_DEPENDENCIES ............................................................ 277
DBA_EXETNTS ......................................................................... 277
DBA_INDEXES ......................................................................... 278
DBA_OBJECTS ........................................................................ 278
DBA_ROLLBACK_SEGS ........................................................ 278
DBA_ROLES ............................................................................. 279
DBA_SEGMENTS .................................................................... 279
DBA_SOURCE ......................................................................... 279
DBA_TABLESPACES .............................................................. 280
DBA_USERS ............................................................................. 280
DICTIONARY ............................................................................ 281
INDEX_STATS .......................................................................... 281
SESSION_PRIVS ...................................................................... 281
SESSION_ROLES .................................................................... 281
USER_ROLE_PRIVS ................................................................ 282
USER_SYS_PRIVS ................................................................... 282
USER_TS_QUOTAS ................................................................. 282
V$BACKUP ............................................................................... 283
V$DB_OBJECT_CACHE ......................................................... 283
V$LATCH_CHILDREN ............................................................. 284
ix
V$LOCK .................................................................................... 284
V$LOCKED_OBJECT .............................................................. 285
V$LOGFILE ............................................................................... 285
V$ROLLSTAT ............................................................................ 286
V$SESSION .............................................................................. 286
V$SESSION_WAIT ................................................................... 286
V$SQLAREA ............................................................................. 287
V$SYSSTAT .............................................................................. 287
V$SYSTEM_EVENT .................................................................. 288
V$TRANSACTION .................................................................... 288
V$WAITSTAT ............................................................................ 288
統計情報 ..................................................................................... 289
索引
x
......................................................................... 290
第
1
章
DBA のお仕事
--- Oracle の構成を知る ---
それは突然のことだった．
．
．
い、異動ですか？冗談．
．
．じゃないですよね。でも、システム部で開発をはじめてま
だ3ヶ月も経ってないんですよ？研修を受けて、ようやく何とか慣れてきて、これからっ
てときにどうしてなんでしょう？よくわからんって、課長冷たいなぁ。それでどこに異
動なんですか？運用管理．
．
．？オペレータってことかな？ほかに何かあったっけ？いっ
たいどんな仕事をするんだろう？すごく不安。あ、部長だ。部長に聞けばわかるかな？
ちょっと聞いてみよう。
データベース管理者の見習い、ですか？それって、いったいどんなことをするんで
しょうか。よくわからないんですけど．
．
．データベースを管理する仕事？そんなことを
聞いてるんじゃありませんよ。あーぁ、部長に聞いても無駄だな。聞いたわたしがバカ
だったよね。そりゃ確かに、毎日データベースにはアクセスしているけれど、そのデー
タベースの管理をするなんて考えたこともなかった。そんな仕事、わたしにできるんだ
ろうか．
．
．？心配だなぁ。でも、決まってしまったことは仕方ない。どうせやるんだっ
たら楽しくやらないと損だもんね。見習いっていうことは、とりあえず誰かが教えてく
れるんだろうし、一生懸命やればなんとかなるか。
Ｄ
Ｂ
Ａ
の
お
仕
事
やっぱり。
何もわからないまま異動の日を迎えてしまったけど、
大丈夫なのかな？新しい部
署って言うのは何だかとっても緊張する。開発の方には同期もいるけど、こっち
には同期もいないし．．．課長さんは優しそうな人だけど、わたしに直接いろいろ
教えてくれる予定のデータベース管理者、つまり DBA（Data Base Administrator）
はどの人なんだろう？今日は 10 時に出社予定ってことだから、まだ来ていないん
だな、きっと。
2
「売上リスト、取ってきて。」
ん？この人、無愛想でちょっと恐そうだけどかっこいいなぁ。背も高いし．．．
「あのさ、リスト取ってきて欲しいんだけど。」
え？わたし？わたしに向かって言ってたんだ。
でもリストってどこに取りにいけ
ば．．．、来たばっかりでよくわからないんです。
「あ？もしかしたら、新しく配属になった．．．」
はい、そうです。
「道理で見ない顔だなと思った。じゃ、これから DBA の勉強をするってわけだ。
で？ Oracle のことはどれくらい知ってる？」
どれくらいって言われても、
どう言えばいいんでしょう？ユーザーとして使って
いただけで、中身についてはよくわからないんです。
「あ、そう。じゃあとりあえず．．．場所教えるからリスト取ってきて。」
あ、はい。なんなんだ？この人は？
なんだかんだと用を言いつけられて、結局午前中は終わってしまった。
人遣いの
荒い人だったな。おかげでどこに何があるかは理解できたけど、結構たいへんだっ
た。ところで DBA の先輩はどうしたのかな。ていうか、この人遣いの荒い人がそ
の先輩のような気がしてるんだよねぇ。何となく．．．この人かっこいいんだけど、
こう人遣いが荒いんじゃあね。できればもっと優しそうな人がいいなぁ。
「それじゃ、午後は勉強でもするか。」
あーあ、やっぱりこの人だったのね。これは先が思いやられるなぁ。つらいDBA
修行になりそうだ。
Ｄ
Ｂ
勉強でもするか、っていうから一緒になって何かやってくれるのかと思ったら、Ａ
いきなり本を積み上げられてしまった．．．忙しいのはわかるけど、ちょっと冷たの
お
いんじゃない？開発に異動になったときに受けた研修で、Oracle については勉強仕
事
した。でも結局その後の仕事では、SQL を使ってデータを操作するっていうこと Oracle の構成
くらいしかやっていないんだよね。あ．．．、このあたりのことなんてあんまり覚え
3
てないなぁ。そういえば Oracle ってこういう構成だったのね。
＜Oracleの構成＞
SGA
(System Global Area)
初期化
パラメータ
バックグラウンドプロセス
起動時に
各種設定を
読み込み
Oracleインスタンス
データ
ファイル
制御
ファイル
REDOログ
Oracleデータベース
Oracleを機能させる中心部分をインスタンス、
Oracleを構成するファイル群をOracleデータベースと呼ぶ。
ファイル群は以下の3つより構成される。
データファイル：データおよびデータ構造、データディクショナリが収められている。
コントロールファイル：データベースの現状と物理構成が記録されている。
REDOログ：データベースに対して行われたすべての更新情報が記録される。
こうして改めて考えると、
プログラムでアクセスしていたのはデータファイルな
んだよね。で、その中にはユーザーのデータの入っているテーブルスペース、ソー
トとかで一時的に使用されるテンポラリテーブルスペース、それにロールバック
のために使うデータが入るロールバックセグメントがある。開発のときに使った
Ｄ
Ｂ
Ａ
の
お
仕
事
Product マスターなんかはユーザーデータのテーブルスペースに入ってたんだよ
ね。インデックス専用のテ−ブルスペースもこの仲間だな。でも SYSTEM テーブ
ルスペースのデータは、こういったユーザーのデータとは別物で管理のために使
われるらしい．．．ってことは、これからはこのデータを使って仕事をするってこ
とか。
「そうだな。」
あ、先輩。
4
「DBA の仕事には欠かせない管理用のデータは、SYSTEM テーブルスペースに
あって、データディクショナリっていうんだ。
」
SYSTEM テーブルスペースのデータディクショナリか．．．
「で、このデータディクショナリから自由にデータを取り出すことができるのは、
管理者としての権限を持ったユーザーだけなんだ。」
管理者としての権限、というとわたしにもそれがもらえるんですね？何だか、偉
くなった気分。
参考になる書籍
データベースの管理をするにあたって、
参考になる書籍をいくつかここであげてみ
よう。
「Oracle パフォーマンスチューニング」
●
Mark Gurry,Peter Corrigan 共著
オライリージャパン
「Oracle8 プロフェッショナルテクニック」
●
小幡一郎著
ソフト・リサーチ・センター
「Oracle8 新機能活用ガイド」
●
日本オラクル監修
ソフトバンクパブリッシング
「Oracle 実践 Q ＆ A 上級編」
●
日本オラクル編著
ソフト・リサーチ・センター
「Oracle ＆ UNIX パフォーマンスチューニング」
●
アハメド・アロマリ著
ピアソン・エデュケーション
「Oracle8DBA ハンドブック」
●
ケビン・ロニー著
翔泳社
Ｄ
Ｂ
Ａ
の
お
仕
事
5
「管理者権限を持ってると、
データベースをシャットダウンすることもできるし、
テーブルの DROP なんかも簡単にできてしまう。」
うーん。偉いっていうだけじゃなくて、一歩間違えばたいへんなことにもなりか
ねないってことですねぇ。うかつなことはできないなぁ。" 権限がありません " っ
て拒否されちゃう方がかえって気楽な面もあるんだな。
「そして、そういう権限を管理し、権限を付与したり取り上げたりするのも DBA
の仕事の 1 つということだ。」
なるほど、
具体的に言ってもらうとこれからの仕事がどんなものがイメージがわ
いてくるな。
REDO ログ
それからこの REDO ログっていうのも聞いたことはあるけど．．．データベース
に対して行われた更新情報をすべて記録しておくためのファイルで、障害からの
回復のために使われる．．．確かに、元の情報とすべての途中経過があれば、万が
一データがどうにかなってしまった場合でも復元できるもんね。
でも、すごーくたくさん更新があったりしたら、ログもたくさんになってしまっ
て回復するのが大変そうだ。それにずっと以前のログなんて、果たして取ってあ
るものなんだろうか？消えちゃってたりしないのかな？
「毎日バックアップをとっておけば、一日分のログを利用するだけで復元できる
だろ？」
バックアップね。要はその日のデータの状態をコピーしておくんだ。全部のデー
Ｄ
Ｂ
Ａ
の
お
仕
事
タを毎日バックアップしてるんですか？
「読取専用のテーブルスペースの場合、毎日バックアップする必要もないだろ。」
確かにそうだ。
「あとREDOっていうのはディスクにあるんだけど、古くなってきたものは順次
テープに書き出してとってあるんだよ。それのことをアーカイブログって言うん
だ。ま、これはうちの場合で、全部ディスクにあるっていう運用をしているとこ
ろもあるかもしれないし、アーカイブログは取っていないっていうところもある
6
だろうな。」
＜元のデータとログさえあれば＞
変更以前のデータ
EMPNO
NAME
DEPT
1111
1112
1113
1114
1115
・
・
・
・
鈴木
山田
富士
佐藤
高橋
第一営業
総務
経理
第二営業
企画部
・
・
・
・
XXXX
YYY
XXY
ZZZZ
OO
・
・
・
・
POST
課長
主任
・
・
・
・
MGR
2135
4545
3333
1287
3255
・
・
・
・
現在のデータ
EMPNO
NAME
DEPT
1111
1112
1113
1115
・
・
・
・
鈴木
山田
富士
高橋
第二営業
総務
経理
企画部
・
・
・
・
XXXX
YYY
XXY
OO
・
・
・
・
POST
部長
主任
・
・
・
・
MGR
3256
0117
3333
3255
・
・
・
・
障害により
データファイルが破損！
その後の変更はすべて
ログに記録される
REDOログ
・EMPNO=1111
第二営業へ異動、
異動に伴い上司も変更
・EMPNO=1112
課長から部長に昇進
それに伴い上司も変更
・EMPNO=1114
都合により退社
元のデータとログが揃っ
ていれば現在のデータへ
の復旧が可能。
元のデータから現在に至
るまでのすべてのログが
必要。
アーカイブログか．．．ログ 1つとっても、いろいろなやり方があるっていうこと
ですね。
「そう。こういうバックアップのプランとか、障害が起きたときにデータベース
を復旧するっていうのも DBA の仕事だな。」
じゃ、障害が起きたらすごくたいへんなんだ。夜中に障害が起こったりしたらど
うするんですか？
「呼び出されて対応することになるかもな。」
ひぇー！いやだなぁ。
「そんなことはめったにないよ、きっと。」
それならいいんですけど．．．不安だなぁ。
Ｄ
Ｂ
Ａ
の
お
仕
事
7
＜バックアップ頻度とログ＞
バックアップを毎日取る
月
火
水
木
金
土
日
月
Backup
Backup
Backup
Backup
Backup
Backup
Backup
Backup
ログ
ログ
ログ
ログ
ログ
ログ
ログ
何曜日に障害が起きても、どの時間帯であっても、復旧に必要なログは最大１日分。
そのログと前日のコピーから復旧することができる。
バックアップは週に1度
月
日
火
水
木
金
土
Backup
日
Backup
障害のタイミングによっては最大１週間分のログが必要。
バックアップ頻度により、必要となるログが変化する。
ログ
ログ
ログ
ログ
ログ
ログ
ログ
ログ
ログの量は更新量によって異なるため、たとえ一ヶ月に1度しかバックアップを取っていな
くても、ほとんど更新が発生しなければ、ほんのわずかのログを適用するだけで復旧するこ
とが可能になる（読取専用ならバックアップから戻すだけでOK。）つまりテーブルスペース
やアプリケーションの性格により、最適なバックアップ頻度も異なってくる。
コントロールファイル
そうそう、このコントロールファイルって馴染みがないんですよね。いったい何
なんですか？
「ユーザーの立場から見たら馴染みはないだろうな。でもOracleにとってはなく
Ｄ
Ｂ
Ａ
の
お
仕
事
てはならない、とても重要なものなんだ。
『制御ファイル』となっているマニュア
ルも多いかな。」
というと、大切な情報が入っているっていうことでしょうか？
「うん。何ていうか、データベースの整合性に関するデータが入ってるんだけ
ど．．．」
？？？？
「わからないよなぁ。たとえば、障害から回復するときにどのログを使うかって
8
いう情報が入っていたり、データベースを構成するデータファイルが、物理的に
どこにあるかっていう情報が入っているんだ。」
ということは、
このファイルが壊れちゃったりすると、ファイルの物理的な位置
がわからなくなってしまったりするんですね。
「そういうことだ。だから、バックアップもさることながら、ミラーリングする
場合が多いんだよ。」
ミラーリングって、同じものを 2 つ持つってことですよね。そうすれば片方が壊
れてもどうにかなりますもんね。
「だけど、ただ 2 つ持てばいいってもんじゃないからな。」
え？
＜ディスクの分散＞
Oracleインスタンス
Disk1
Disk2
コントロール
ファイル1
コントロール
ファイル2
Oracleインスタンス
Disk3
Disk1
Disk2
Disk3
コントロール
ファイル1
コントロール
ファイル2
ディスクが分散されていなければ、
コントロールファイルを2つ持っていても意味がない。
それはそうですよね。言われなくても気づいたと思いますよ、それくらいは、多
分．．．とにかく、それくらい大事なファイルだっていうことですね。
「そう、ちゃんとしたコントロールファイルがないと、Oracle は立ち上がってく
れないからな。」
覚えておきます。
インスタンス
Ｄ
Ｂ
Ａ
の
お
仕
事
インスタンスはバックグラウンドプロセスと SGA（System Global Area）から成
9
るっていうことだけど、このインスタンスを構成している SGA っていうのは．．．
メモリ上にとられる領域で Oracle の情報が入れられている。高速でやりとりする
ことができ、さまざまなプロセスからアクセスされる。うーん。だから何？って
感じだなあ。
「SGA っていうのはメモリ上に確保されるエリアで、Oracle の処理はこの SGA
を介して行われているんだ。ユーザーが使うデータっていうことで考えてみる
と．．．」
＜データを読み込む＞
SGA
ユーザー
共有
プール
エリア
制御情報 DBバッファ
上にあるので
DB
読み込み
バッファ
商品A
ログ
商品B
バッファ
商品T
DBバッファ上に
ないので
ディスクから
読み込み
ユーザー
データ
商品S
商品Aの
データが
欲しい
Oracleの処理はすべてこのSGAを介して行わ
れる。
アクセススピードは、ディスクに比べメモリ
の方が高速なので、SGAに必要なデータが読
み込まれていれば、ディスクにアクセスする
ことなく必要なデータを取り出すことができ
る。
SGA上にデータがない場合、ディスクから
SGAに読み込んでこなければならないため、
時間がかかることになる。
SGAが大きければ、SGA上に必要なデータが
存在する確率が高くなる。
ユーザー
商品Sの
データが
欲しい
ということは、
このエリアが大きければ高速に処理することができて、パフォー
Ｄ
Ｂ
Ａ
の
お
仕
事
マンスも良くなるってことでしょうか。
「確かに、データがすべてこの中に入ってたら速いだろうな。でも、資源は無限
ではないからな。限られた資源の中で最大のパフォーマンスを得られるように
チューニングするのも、DBA の仕事ってわけだ。データの種類によって、SGA の
どのエリアに入るかも違ってくるから、
そのあたりも考慮しないといけないしな。
」
はぁ．．．ということは、今まで遅いとか散々文句をいってたことを、解決しなけ
ればいけない立場だということか．．．厳しそうだ。
10
SGA 補足
SGA にある各エリアについて、もう少し補足することにしよう。
データベースバッファ：データファイルから読み出されたデータが格納されるエ
リア。読み込みは Oracle ブロック単位で行われるので、実際には必要とされた
データと同じブロックにあるデータも SGA 上に持って来られることになる。読み
込もうとしたデータが SGA 上に存在することを「ヒットする」といい、パフォー
マンスが悪いときにはこのヒット率をみたりする。
またデータの更新もここで行わ
れる。
共有プールエリア：ユーザーが使用する SQL が格納され、複数のユーザー間で
SQL 文を共有し、再利用する目的で使用されるほか、頻繁に参照されるデータ
ディクショナリの情報、ストアドプロシージャ等が格納される。やはりここでも、
効率良く再利用されることがパフォーマンスの向上につながる。
ログバッファ：ユーザーが更新処理を行うと、回復処理に必要となる REDO ログ
にその内容が書き出されるが、実際には書き出される前にいったんこのログバッ
ファに格納され、その後 REDO ログファイルに書き込まれている。
主要構成要素は以上のようなものだが、そのほかにも SGA には、Oracle のプロ
セスが処理を行う際に利用する、ユーザーとのセッション情報や、ロックの情報等が
格納される。SGA 内の動きに関しては、またの機会に。
「ついでに言っておくと、Oracleには初期化パラメータっていうパラメータファ
イルがあるんだ。そこに、このエリアの大きさをどれくらいにするか、とかって
いう指定があるんだよ。」
初期化パラメータ．．．ですか。聞いたことはありますね。その中に Oracle のさ
まざまな設定がしてあるんですよね。ということはそのパラメータを調整するっ
ていうのは、DBA の仕事なんでしょうね。
「そのとおり。いろんなパラメータがあるから知らずにすんでしまうものもある
んだけど、知っているに越したことはない。ま、そのうちいろいろわかってくる
Ｄ
Ｂ
Ａ
の
お
仕
事
よ。」
11
わかってくるよっていうか、わかるようにならなくっちゃいけないんだろうな。
DBA になる以上は．．．
初期化パラメータ
初期化パラメータは INITxxxx.ora（xxxx は SID 名）というファイルに記述されて
いて、Oracle がスタートするときに参照されている。初期化パラメータの設定には
動的に変えられるものもあれば、Oracle を再スタートさせないと変更できないもの
もある。この設定次第で Oracle の動き方が変わってくるので、DBA としてはこれ
をうまくコントロールする必要がある。代表的なものをいくつかあげてみよう。
DB_BLOCK_SIZE：Oracle ブロックのサイズを指定。Oracle はこの単位でデー
タを処理する。
DB_BLOCK_BUFFERS：データベースバッファのサイズを設定。データが読み
込まれるエリアなので、このサイズを増やせばディスク I/O が減少すると考えられ
るが、システム全体のメモリの余裕度、あるいは SHARED_POOL_SIZE との調
整は必須。実際の大きさはDB_BLOCK_SIZE×DB_BLOCK_BUFFERSとなる。
SHARED_POOL_SIZE：共有プールエリアのサイズ。この値が小さすぎると、
オブジェクトを読み込むために非常に多くのディスクアクセスが必要となり、パ
フォーマンスを低下させる。このエリアの不足による影響は大きい。
LOG_BUFFERS：REDO ログバッファに割当てるバイト数。更新の多いアプリ
ケーションでは、 REDO ログへの I/O はパフォーマンスに多大な影響を与える。
REDO ログが存在するディスク上で I/O が問題となった場合には、このバッファ
サイズを大きくすると効果が得られることがある。
Ｄ
Ｂ
Ａ
の
お
仕
事
DBA のお仕事って
それにしても、DBA の仕事はデータベースを管理することだって言われたと
きはどういうことかわからなかったけど、だんだんとわかってきたような気がす
る。今まで何も考えずにデータベースを使っていたけれど、その影で DBA が権限
12
をうまく管理してくれたり、パフォーマンスを調整してくれてたんだなぁ。それ
に、万が一に備えてバックアップも取っていてくれるんだもんね。
「そうそう、それから領域の管理っていうのも DBA の大事な仕事の 1 つだよ。」
領域の管理ですか？
「たとえば、お客さんがどんどん増えれば顧客マスターのデータはどんどん増え
るよな。」
そうですよね？あ、そうか。でもディスクの大きさとかには限界がありますよ
ね。そういうデータ量とディスクの領域との調整も DBA がやるってことですね。
なるほど。要するに、ユーザーが毎日ストレスを感じることなく、無意識のうち
にデータベースを使えるようにするためにがんばる。そしてデータベースで問題
が起こらないよう、問題が起こったらすばやく対処できるよう、日頃からあらゆ
る面で気を配っておく。そういうことですね？
「まぁな。加えて Oracle 自体のインストールやアップグレードなんかも DBA の
仕事になる。新バージョンが出たら新しい機能も追加されるだろうから、そういっ
た勉強もしなくちゃいけないしな。」
聞けば聞くほどたいへんそう。でもたいへんな割には目立たなくって、地味な存
在のような気もするなぁ．．
．あ、先輩に電話みたいですよ。向こうで呼ばれてます。
「ああ、本当だ．．．きっとクレームだな。」
クレーム？そういえばそうだ。データベースに不都合が起こったときなんかに、
システム部に電話したことがあったっけ。トラブルが起こった場合には、今まで
わたしたちがしてきたように、文句の電話がじゃんじゃんかかってきちゃうんだ。
つまり、クレームの電話を受けて状況説明するのもお仕事の1 つだし、クレームを
受けるだけじゃなくて対処しなくっちゃいけないんだな、これからは．．．
Ｄ
Ｂ
それはできれば避けたかったけど、そうもいかないって感じ．．．覚悟しなくっＡ
ちゃ。あーあ、何だか気が重くなってきたな。とてもたいへんそうなんだもん。の
お
仕
「ま、結構面白い面もあるよ。やっていけばわかるって。」
事
そうでしょうか．．．そういう境地に早く達することができるといいんですけど「そういうことだ。」
ね。とにかくがんばりますので、よろしくお願いします。
13
本日の成果
Oracle の構成
DBAとしてOracleを管理するためには、Oracleの構成に関する知識が必要不可
欠である。Oracle データベースは、複数のプロセスからなる「Oracle インスタン
ス」と、物理的なファイルからなる「Oracle データベース」で構成されている。
Oracleインスタンス
SGA（System Global Area）
制御情報
クライアント
プロセスからの要求
を受取り、処理を実行。
（要求されたデータがSGA
上にあるかどうかを判断し、
なければファイルから
読み込んでくる）
ユーザーの接続
状態を監視し、異常
終了時にはリソース
の解放等を行う
変更されたデータを
データファイルに
書き出すプロセス
ログバッファ
セッション情報、ロック情報等
共有プール
ディクショナリ、
スドアド
プロシージャ、
ディクショナリ等
SMON
PMON
データベース
バッファ
データ
REDOログへ
書き込む
更新データ
REDOログへの
書き込みを受け
持つプロセス
サーバー
プロセス
DBWR
LGWR
主なバックグラウンドプロセス
Oracleそのものを監視
システムの回復処理や
使わなくなった資源の
解放などをつかさどる
コントロール
ファイル
データベースの
物理構成ログ情報
データ
ファイル
ユーザーデータ
SYSTEMデータ等
Oracleデータベース
14
REDOログ
データベース
への変更を記録
DBA の仕事
DBAの仕事には、リソースの管理やバックアップ&リカバリといった一般的な
運用管理だけでなく、Oracleソフトウェアのインストールやアップグレード、パ
フォーマンスチューニングも含まれる。さらには、ユーザーからのクレームやリ
クエストに対応するのも DBA の仕事である。
リソースの管理
ユーザーのクォータやアクセス権限、ディスク領域、あるいはメモリといったリ
ソースの管理は DBA の仕事の重要な要素である。これらはセキュリティ、パ
フォーマンスに影響を与え、
ずさんな管理は業務自体にも支障をきたす可能性が
あるため、注意が必要である（個々の詳細については、本書の中で解説してい
く）
。またリソースの限界を見極め、キャパシティプランニングを行う必要もあ
る。
バックアップ＆リカバリ
トラブルが発生した場合にどのように対処するか？またそのときのためにどんな
準備をしておくか？バックアップとリカバリについての計画を立てるのも DBA
の役割である。実際にコトが起こったときに被害を最小限にとどめるためにも、
トラブル発生を想定したシミュレーションやリハーサルを行っておくとよい。
パフォーマンスの調整
初期化パラメータの設定やテーブルスペースの物理的配置、SQL の書き方はパ
フォーマンスに影響を及ぼす。DBA は効率よく資源を使い、最適なパフォーマ
ンスを得るための調整を行わなければならない。
15
Oracle ソフトウェアのインストールやアップグレード
Oracle をインストールしデータベースを作成する、あるいはアップグレードを行
いデータベースを移行するのも DBA の役割。新機能について勉強し、自分のシ
ステム環境にマッチするかどうか、
そして使用するかどうか判断することも必要。
クレームやリクエストへの対応
トラブルに伴うユーザークレームに対応するだけでなく、ユーザーからの要望
（リ
クエスト）にも対処する必要がある。リクエストに応えられるかどうか、あるいは
そのプライオリティ等を判断し、各部門と調整を行う必要もある。
16
第
2
章
ロック待ちトラブルの解消
--- データディクショナリを活用する ---
管理のことなんて考えたこともなかったのに、異動によりDBA見習いになってしまっ
た
（させられてしまった）
。
データベースがらみで何か起こればクレームをつければよかっ
たユーザーの立場から、クレームを受ける立場となって2ヶ月あまり。とりあえずマニュ
アルを読んだりして勉強してきたけれど身についているのか、いないのか。やはり実践
してみないと、自分のものにならないのではないかと感じている今日このごろ。なにし
ろ勉強をすすめながら今までにやる機会があったことといえば、ユーザー管理の一部で
あるユーザーの作成と権限付与やユーザーからのクレーム対応がほとんど。このクレー
ム対応って結構多い。DBA のお仕事って、ずーっとこんな感じなんだろうか．
．
．だとし
たら、ちょっとつまらないよねぇ。
トラブル発生！！
何だか、急に電話がたくさん鳴り出した。トラブルかな？Oracleに接続中のユー
ザー画面が突然終了してしまい、そのせいで管理部門に問合せが殺到しているよ
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
18
うだ。ユーザーの立場での経験はあるけれど、管理部門に来てからははじめてだ。
どうするんだろう？あ、先輩が呼んでる。
「こういう場合は、まずアラートログを確認するんだ。」
先輩に言われるままエラー状況を記録するアラートログを確認してみると次のよ
うなエラーメッセージが発生していた。
Errors in file /export/home1/oracle/app/oracle/admin/oracle1/bdump/oracle1_s001_16200.trc:
ORA-00600: 内部エラー・コード,引数:[729],[152],[space leak],[],[],[],[],[]
ここに表示されているファイルを見れば何かわかるのかな？中身を見てみよう。
Dump file /export/home1/oracle/app/oracle/admin/oracle1/bdump/oracle1_s001_16200.trc
Oracle7 Server Release 7.3.4.2.0 - Production
With the distributed option
PL/SQL Release 2.3.4.2.0 - Production
ORACLE_HOME = /export/home1/oracle/app/oracle/product/7.3.4
System name: SunOS
Node name:
p4epsv1
Release:
5.5.1
Version:
Generic_103640-03
Machine:
sun4u
Instance name: oracle1
Redo thread mounted by this instance: 1
Oracle process number: 11
Unix process pid: 16200, image: ora_s001_oracle1
*** 1999.07.09.16.38.22.000
*** SESSION ID:(71.1136) 1999.07.09.16.38.22.000
******** ERROR: UGA memory leak detected 152 ********
******************************************************
HEAP DUMP heap name="session heap" desc=0x8029a65c
extent sz=0x108c alt=32767 het=32767 rec=0 flg=3 opc=3
parent=8000001c owner=810bb7b4 nex=0 xsz=0x108c
EXTENT 0
Chunk 8156b114 sz= 3828 perm
"perm
" alo=3336
Chunk 8156c008 sz=
400 free
"
"
----- 中略 ----EXTENT 9
Chunk 803212e4 sz= 2808 perm
"perm
" alo=2808
Chunk 80321ddc sz= 1404 free
"
"
Total heap size
=
35376
FREE LISTS:
Bucket 0 size=76
Chunk 813634e4 sz=
120 free
"
"
Bucket 1 size=140
--- 中略 ---Bucket 7 size=8204
Bucket 8 size=16396
Bucket 9 size=32780
Total free space
= 24836
UNPINNED RECREATABLE CHUNKS (lru first):
PERMANENT CHUNKS:
Chunk 8156b114 sz= 3828 perm
"perm
" alo=3336
Chunk 804be474 sz=
112 perm
"perm
" alo=112
Chunk 8095cc5c sz=
144 perm
"perm
" alo=144
Chunk 8136273c sz= 3496 perm
"perm
" alo=3496
Chunk 803212e4 sz= 2808 perm
"perm
" alo=2808
Permanent space
=
10388
******************************************************
*** 1999.07.09.16.38.22.000
ksedmp: internal or fatal error
ORA-00600: 内部エラー・コード,引数:[729],[152],[space leak],[],[],[],[],[]
----- Call Stack Trace ----calling
call
entry
argument values in hex
location
type
point
(? means dubious value)
------------ --------- ------------ ----------------------------------------------ksedmp()+156 CALL
ksedst()+0 746CB4 ? 746CA0 ? 746C80 ? 44 ? EFFFC47C ? 0 ?
kgeriv()+220 PTR_CALL
3 ? 0 ? 0 ? 258 ? 0 ? 2D9 ?
kgesiv()+104 CALL
kgeriv()+0 821E90 ? 84ED9C ? 2D9 ? 2 ? EFFFCA90 ? 81BF90 ?
ksesic2()+48 CALL
kgesiv()+0 821E90 ? 84ED9C ? 2D9 ? 2 ? EFFFCA90 ? 2894 ?
ksmuhe()+476 CALL
ksesic2()+0 2D9 ? 0 ? 98 ? 1 ? A ? 74C1A8 ?
ksmugf()+452 CALL
ksmuhe()+0 74C1A8 ? 822C00 ? 8029A658 ? 1 ? 98 ? 82979C ?
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
19
何のことだかさっぱりわからない。
「どうすればいいかわかるか？」
うーん。とりあえず使えるようにするしかないですよねぇ。再起動するんじゃな
いでしょうか？
「じゃ、やってみてよ。」
ということは私が実行するってこと？普通にSTARTUPコマンドで立ち上げれば
いいんだよね。あれ？全然立ち上がってこない。いつもなら1分もあれば起動され
るのに、おかしいなあ。待つこと 5 分、ようやく正常に起動された。よかった。一
安心。でも、どうして時間がかかったんだろう？
「インスタンスリカバリを行っていたせいで時間がかかったんだよ。」
インスタンスリカバリですか？というと．．．
「正常にコミットされた情報がすべてディスク上に書き出されたことを保証し、
コミットされなかった情報をロールバックするために時間がかかったっていうこ
とだ。」
へぇ、こういう起動時のリカバリを指してインスタンスリカバリと呼ぶんだ。な
るほどね。ところでさっき見たファイルは？
「あれはだな、Oracle のダンプファイルっていうんだ。サポートに問合せる際に
使用するもので、この内容に関しては専門家に解析を依頼するしかないな。
」
さらに障害時のエラー番号として「ORA-00600：内部エラー・コード , 引数
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
20
:[729],[152],[space leak],[],[],[],[],[]」というのはサポートに問合せる際の重要な
キーワードであることも教えてもらった。この ORA-00600 の原因究明は Oracle の
サポートに依頼するしかないらしい。道理でよくわからないと思った（ほかのエ
ラーならわかるというわけでもないけれど．．
．）。
今日はいい勉強になった。と、感慨にふけっていたところにユーザーからのク
レームの電話を受けてしまった。画面が「お待ち下さい」状態で動かないので何
とかして下さい、という電話である。あれ？先輩どこに行ったんだろう？運の悪
いことに今日は人が出払ってしまっていて、今現在この業務が遂行できるのは見
習いの私しかいない！仕方がない。やってみるしかないか。実践、実践！
アラートログファイル
アラートログファイルは、/Oracle_home/RDMBSxx/SIDalert.log というファイ
ル名で自動的に作成されている。このアラートログには、Oracle の内部エラーに関
する情報が書き込まれている。どんどん蓄積されていくので、定期的にチェックした
方がよい。そして必要であれば削除しよう。アラートログファイルに書き出されるエ
ラーのうち、主なものを参考までに以下に挙げる。これらのエラーが頻発するようで
あれば、対応しなければならない。
ORA-0052
ORA-0055
ORA-0104
ORA-0270
ORA-0272
ORA-1630
ORA-1650
ORA-1653
最大エンキュリソース数 num が発生しました。
最大 DML ロック数を超えました。
デッドロックを検出したため共有サーバーはすべてブロックされ、リソース待機します。
アーカイブ・ログの作成でエラーが発生しました。
アーカイブ・ログの書込みでエラーが発生しました。
一時セグメントで最大エクステント:num に達しました( 表領域:name)
ロールバックセグメント:name を拡張できません(:num、表領域:name)
表領域 name で表 name.name のエクステントを num によって拡張できませんでした。
ロック状況の確認と対応
こういう状況になるときの原因として考えられるのは、ロック待ちだったっけ。
必要なリソースを要求したものの、ほかの人が使用中のため待たされてしまって
いるということだと思うんだよなあ。たとえば更新処理の途中でPCがハングアッ
プしてしまったので電源を切ってしまった、あるいは誰かがロックをかけたまま
COMMITもロールバックもしないままトランザクションを放りっぱなしにしてし
まっているなどが考えられる。自分では確認画面で OKにしたつもりなのに、その
ままだったっていう経験は誰でもあるはず。文書を印刷したつもりでしばらく席
をはずして戻ってきたら、印刷の確認画面がまだ出ていたとか。同じことを更新
系のトランザクションでやってしまうとロックがかかったままになってしまうん
だよね、これが。もちろんプログラムの組み方に問題がある場合もある。とにか
く、この状況から抜け出すためにまず状況を確認しなければ．．．
えーと、たぶんロックの問題ということで．．．現在ロック待ちしているユーザー
が存在するかどうかを確認してみればいいんだよね。ということは、データディ
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
クショナリの V$LOCK を確認するんだと思うんだけど、待たされている人はどん
21
な人で、どんな処理をしようとしていて、どれくらい待っているのかもわかると
いいよね。そのためには、セッション情報が入っている V$SESSION とか、共有
SQL 領域の情報が入っている V$SQLAREA なんていうデータディクショナリも使
えそうだ。必要な列を指定して．．．待ち時間は分単位にしてみようかな。で、条
件は待機中のロックのアドレスと、SQL のアドレスでいいかな。そして、待ち時
間の長いものから表示することにしよう。（でも、たくさん出てきたらいやだ
なぁ。）こうやってデータディクショナリを活用すると、必要な情報が得られるん
だよね。よし、実行だ！この結果からロック待ちをしている SQL 文とその状況が
わかる．．．
SQL> select a.sid, a.serial#, b.type, to_char(b.ctime/60,'999990.9') Min, c.sql_text
from v$session a, v$lock b, v$sqlarea c
where a.lockwait = b.kaddr
and a.sql_address = c.address
order by b.ctime desc;
SID
SERIAL#
TY
MIN SQL_TEXT
----- --------- ----- ------- ------------------------------------------12
46536
TX
21.2 update dept set loc='HQ'
あーっ！このSQL文はなんと21.2分間（！！）もロックが解除されるのを待って
いることになる。ユーザーが電話をかけたくなるのも当然だ。ていうか、よくこ
こまで我慢したなあって思う。上記のSQLの結果が複数だった場合
（あまりあって
はならないことだけど）にはどれが電話をかけてきた人のものか、あるいは表示さ
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
れたのが本当に当の電話の主なのかを確認するためにV$SESSIONを参照する必要
があるかもしれない。見習いDBA としては念には念を入れて確認することにしよ
う。
SQL> select username,osuser,machine,terminal,program,client_info from v$session
where sid=12 AND serial#=46536;
USERNAME
OSUSER
MACHINE
TERMINAL
PROGRAM
CLIENT_INFO
------------ ---------- ----------- ------------ ------------ --------------------E12345
kxb012
aix
pts/4
pe123
(TNS V1-V2)
よし、ユーザー名などから間違いないということはとりあえず確認できた。で
は、この人を待たせている犯人は誰なのか？それをつきとめなければ問題が解決
22
しないので犯人を見つけ出すための SQL を実行しなくては．．．前に先輩が使って
いた SQL をメモしておいたんだけど、どこだったかな？あ、あったあった。この
SQL文を実行すると待たせている側および待たされている側のセッション情報が
ペアになって表示されるはずなんだけど．．．ペアで表示されれば今問題となって
いるユーザーを待たせている犯人が一目でわかって便利だもんね。今待たされて
いるのはSID=12のユーザーだということはわかっているので、その情報とペアに
なってくるのが犯人というわけだ。
SQL> select b.id1,a.sid, a.serial#, b.type, to_char(b.ctime/60,'999990.9') MIN
,decode(b.lmode
,1,'null'
,2,'row share'
,3,'row exclusive'
,4,'share'
,5,'share row exclusive'
,6,'exclusive') LMODE
,decode(b.request
,1,'null'
,2,'row share'
,3,'row exclusive'
,4,'share'
,5,'share row exclusive'
,6,'exclusive') REQUEST
from v$session a, v$lock b
where a.sid = b.sid
and (b.id1,b.id2) in
(select d.id1,d.id2 from v$lock d
where d.id1=b.id1 and d.id2=b.id2
and d.request > 0)
order by b.id1,b.ctime desc;
ID1
SID
SERIAL# TY
MIN LMODE
REQUEST
--------- -------- ----------- --------- ------- ------------ -----------131077
7
34937 TX
25.0 exclusive
131077
12
46536 TX
22.0
exclusive
ロ
ッ
ク
待
お！表示されたぞ。LMODE が現在かかっているロックで、REQUEST が要求さち
ト
れているロックだから、この結果により先ほどの SID=12 を待たせているのは、ラ
ブ
SID=7であることが判明！SID=7はexclusiveモードのロックを25分も取得しつづ
ル
けているということになり、そのため SID=12 が 22 分も待たされているというわの
解
けだ。ユーザー情報を取得して SID=7 のユーザーに連絡をとるとしますか。以前消
実行したSELECT文を使えばユーザー情報が取得できるから本人に連絡がとれる
はず。そうすれば ROLLBACK もしくは COMMIT してもらってロックを解除する
23
ことができる．．．え？ハングアップしちゃったからPCの電源をOFF？そういうこ
とですか。なるほどね。今回みたいに PC の電源を切ってしまったことによりセッ
ションが中途半端に残ってしまっているような状況の場合、あるいは本人が外出
してしまった場合などはセッションをKILLするしかないんだよね。ということで
SID と SERIAL を使って．．．
SQL> alter
system
kill
session ‘7,34937’
これでとりあえず、
電話をかけてきたユーザーの要求には応えることができたよ
うだ。めでたし、めでたし。
ほかにできることは？
頻発するロック待ちによるクレームに、
毎回電話で対応していると嫌気がさして
くることがある（大きな声では言えないけど）
。今回みたいなケースは仕方がない
としても、プログラムに問題があったりする場合もあるわけだし。ロック待ちと
なる原因を追究して、
そこを解決してしまえばクレームは減るんじゃないかと思っ
たりするんだけど。何とかならないかなあ？ロック待ちの場合、必ず待たせてい
るトランザクションが1 つ存在し、待たされているトランザクションが1つあるい
は複数存在しているはず。待たせている側が使用しているオブジェクトがわかれ
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
ば、問題の解決に一歩近づくにちがいない。よし、どのオブジェクトがロックさ
れているのかをちょっと調べてみよう。時間もあることだしね。SQL はこんな感
じでいいかな。
SQL> select object_id, session_id, process, locked_mode
from v$Locked_object;
OBJECT_ID
SESSION_ID
PROCESS
LOCKED_MODE
------------- ------------- -------------- ----------------------------9398
10
24216
3
9398
25
25644
3
ここで使用している V$LOCKED_OBJECT を参照すれば、ロックされているオ
24
ブジェクトを簡単に見つけることができるけれど、具体的なリソース名判別のた
めには DBA_OBJECTS を参照した方が良さそうだ。ついでにロックしている時間
がでてくるともっとわかりやすいんだけどなあ。どのデータディクショナリを使
えばいいんだっけ？これがまだ、ぱっとひらめかないんだよねぇ。
「こんな感じだろうな。」
あ、先輩。いつの間に？
SQL> select to_char(sysdate,'HH24:MI') TIme,a.owner||'.'||a.object_name OBJECT
,decode(b.locked_mode
,1,'null'
,2,'row share'
,3,'row exclusive'
,4,'share'
,5,'share row exclusive'
,6,'exclusive') LOCKED_MODE
,to_char(c.ctime/60,'999990.9') MIN
from dba_objects a, v$locked_object b, v$lock c
where a.object_id = b.object_id
and b.session_id = c.sid
and b.xidsqn = c.id2
and b.xidusn > 0;
TIME
OBJECT
LOCKED_MODE
MIN
------------ -------------- ---------------------- ----------------13:24
INT.MTRM
row exclusive
12.0
なるほど。オブジェクト名もきちんとわかりますねえ。12 分間のロックか．．．
長々とロックをかけてしまっているということは、これだけでも十分大変なこと
だと思うんだけど、たくさん更新してるのかな？
「でもこれだけでは、本当にこのオブジェクトによって待たされている人がいる
かどうかわからないよな。待っている側を表示するように変えてみるか。」
SQL> select to_char(sysdate,'HH24:MI'), a.owner||'.'||a.object_name OBJECT,
to_char(c.ctime/60,'999990.9') Min
from dba_objects a, v$session b, v$lock c
where c.sid = b.sid
and c.id1 = a.object_id
and b.username = a.owner
and c.type = 'TM'
and c.sid = (select sid from v$lock d where d.type = 'TX' and
d.request>0);
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
TIME OBJECT
MIN
------------ ------------------ -------------13:25 INT.MTRM
3.0
25
結局先輩にやってもらってしまったけど、とにかくこれでテーブル MTRM を
待っているトランザクションが存在するということがわかったわけだ。モードは
表示されていないけど、とりあえずはこれで問題ないよね。けど、この結果から
該当テーブルに対する更新要求が結構あることがうかがえる。しかもほかの人が
ロックを取得したときに、同じテーブルを要求しようとした人は要求が拒否され
るのではなく、待たされてしまっているというわけだ。たしか SELECT FOR UPDATE NOWAIT と指定することにより、ロックで無意味に待たされる状況は避け
られるはずなんだけどな。いったいどんなふうにプログラムを組んでいるのか興
味がわいてきたなあ。このテーブルに対してアクセスしている SQL 文を発見する
方法はないものだろうか？ね、先輩。あれ？またいなくなっちゃった。
DBA_DEPENDENCIES
それでは、DBA らしくリファレンスマニュアルでも見てみるとしますか。デー
タディクショナリにそれらしい情報はないのかなあ？ここで見つからないとお手
上げって感じなんだけど。DBA_DEPENDENCIES？これはオブジェクト間の依存
性がわかるテーブル．．．そうか、どのプロシージャあるいはパッケージ、トリガ
が、どのテーブルを参照しているかがわかるんだ。なるほど、これを調べれば何
かわかるかもしれないなあ。問題となっているテーブルINT.MTRMを参照してい
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
るプログラムをピックアップしてみよう。
SQL> select * from dba_dependencies
where referenced_owner = 'INT'
and referenced_name = 'MTRM';
OWNER NAME
TYPE
REFERENCED
_OWNER
----- ------------ -------------- ----------INT
ACCESS_MTRM PACKAGE BODY INT
INT
REF$_MTRM
TRIGGER
INT
REFERENCED
_NAME
-----------MTRM
MTRM
REFERNECED REFERENCED
_TYPE
_LINK_NAME
------------ ----------TABLE
TABLE
これでテーブル INT.MTRM を参照しているのは ACCESS_MTRM というパッ
ケージとREF$_MTRMというトリガだということが判明！！正直なところここで
たくさんの行が返ってきたらたいへんだなあと思っていたけど、今回はたまたま
26
2 つだったから何とかなりそうだよね。よかった。たくさんの中からどれがこの
ロック待ち状況を作り出しているのかを判断するのは難しそう。けれどとりあえ
ず SELECT 文はロックとは関係なさそうだから、それ以外を対象とすればいいと
して、どうすればいいのかな？そういえばデータディクショナリにあるテーブル
名とその内容に関するコメント情報が入っているビューがあると先輩がいってい
たような気がする。そうそう、DICTIONARY！その中からソースがわかりそうな
ものが見つからないかな？
SQL> select * from dictionary
where table_name like '%SOURCE%';
TABLE_NAME
-------------------ALL_SOURCE
DBA_SOURCE
USER_RESOURCE_LIMITS
USER_SOURCE
RESOURCE_COST
V$RESOURCE
COMMENT
-------------------------------------------------------------Current source on stored objects that user is allowed to create
Source of all stored objects in the database
Display resource limit of the user
Source of stored objects accessible to the user
Cost for each resource
Synonym for V_$RESOURCE
うーん。そうだなあ。この DBA_SOURCE というのが使えそうだ。関係あるの
はとりあえず update と delete かな。
（insert も外部キー次第では関係あるかもしれ
ないけれど。）この 2 つに絞ってみるか。
SQL> select ltrim(text) from dba_source
where owner='INT'
and name='ACCESS_MTRM'
and type='PACKAGE BODY'
and (upper(text) LIKE '%UPDATE%'
or upper(text) LIKE '%DELETE%')
order by line;
LTRIM(TEXT)
----------------------------------------------------------------------------------UPDATE mtrm SET resv = 'Y' WHERE day = :resvday AND no=:rmno;
あ、出てきた出てきた。ということはこれが怪しいってことだよねぇ。こうやっ
てロック待ちオブジェクトを調べて修正できたら、電話が減るのかもしれない。け
ど、アクセスしているストアドオブジェクトがたくさんあったらちょっと面倒。ス
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
クリプトを作ってみるっていうのも手だけど。そもそもストアドオブジェクトに
27
なっていなかったらどうするのかな？プログラムを GREP してみるしかないの
か．．．けどまさにロック待ちしているっていう瞬間をねらえば、SQL 文まで特定
できるからそれと合わせればかなり絞り込めるということだよね。
外注さんが作っ
たプログラムが問題を起こしているときなんかは問題を発見するのがとくに難し
いけど、こうやっていけば何とかなりそうな気がしてくるのは私だけだろうか？
先輩に話したら「あまい！！」って言われるかもしれない．．．だけどこの
D B A _ D E P E N D E N C I E S ってほかにも使えるのではなかろうか？たとえば、
DBA_DEPENDENCIESによってどのストアドオブジェクトがどのテーブルを参照
しているかがわかるわけだから、アプリケーションの変更によって、影響を受け
る可能性のあるオブジェクトを調べるということもできるんじゃないかな？今日
変更されたオブジェクトにより影響を受ける可能性のあるオブジェクトをリスト
するには．．．うーん。一気に表示させようとすると何だか思ったより難しい SQL
になりそうだなあ。
SQL> select o.owner,o.object_name CHANGED_OBJECT,o.object_type
,o.created,o.last_ddl_time,o.status
,o2.owner,o2.object_name REFRENCE_OBJ,o2.object_type
from dba_objects o, dba_objects o2, dependency$ d
where o.last_ddl_time = sysdate
and o.owner not in ('SYS','SYSTEM')
and d.d_obj# = o.object_id
and d.p_obj# = o2.object_id
and o.object_name ！= o2.object_name
and o2.owner ！= 'SYS';
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
OWNER CHANGED_OBJECT
OBJECT_TYPE
CREATED
----INT
INT
INT
INT
INT
INT
XPRT
-----------VIEW
VIEW
PACKAGE BODY
PACKAGE BODY
PACKAGE BODY
PACKAGE BODY
TRIGGER
--------98-05-08
98-05-08
99-01-31
99-01-31
99-01-31
99-01-31
98-12-30
---------------SCOPE_USER_TAB
SCOPE_USER_IDX
ACCESS_MTRM
ACCESS_MTRM
ACCESS_MTRM
ACCESS_MTRM
EPI_SGA_SA
LAST_DDL
_TIME
---------99-06-21
99-06-21
99-06-21
99-06-21
99-06-21
99-06-21
99-06-21
STATUS OWNER
REFERNECED
_OBJECT
------- ------ ------------VALID INT
USER_TABLE
VALID INT
USER_INDEXES
VALID INT
MTRM_HQ
VALID INT
LOG_MTRM
VALID INT
MTRM
VALID INT
EMP
VALID XPRT XPRT_EPI_SGA
OBJECT
_TYPE
-------SYNONYM
SYNONYM
SYNONYM
SYNONYM
TABLE
TABLE
TABLE
ふぅー、やっとできた。それにしても知らなかった、こんなにあるなんて。この
変更による影響だとは知らないままクレームに対応するっていうのも何だか悲し
いな。けど、ある日を境に急にロック待ちが多くなったなんていうときは、その
日付で変更されたオブジェクトとロックの対象になっているオブジェクトを照ら
28
し合わせれば、役立つかもしれない。SYSDATE をその日付にすれば簡単にわかる
よね。逆にテーブルの方を変更したいときもあるだろうから、そんなときは前に
実行した SQL 文を使えば、このテーブルを変更したときに影響を受けてしまうス
トアドオブジェクトもピックアップできるといわけだ。うーん、使える、使える。
DBA の醍醐味
こうしていろいろとやってみると DBA の仕事って、ユーザーからのクレームに
対応するだけじゃなくて、自分でクレームを減らす働きかけもできるんだよね。ク
レームの原因を見つけ出したときとか、解決したときには達成感もある。DBA の
仕事としては領域の管理、チューニング、バックアップとほかにもいろいろある
けれど、今起きている問題を追究していくといろんなことが見えてくるんだろう
な。やっぱりマニュアルを読んでるだけではきちんと身につかない気がする。そ
れにしてもデータディクショナリってとっても重要。データディクショナリを活
用するとしないとでは DBA の仕事って大きく違ってくるよね、きっと。優秀な
DBA になるためにもデータディクショナリともっともっと仲良くなるぞ！！あ、
先輩が戻ってきた。よーし、今までやったことを報告してみよう。
え？そんなことわかってる？なーんだ。ちょっと自慢してみたのに、冷たいな
あ。ま、自分の理解が深まったからよしとするか．．．
ロ
ッ
ク
待
ち
ト
ラ
ブ
ル
の
解
消
29
本日の成果
インスタンスリカバリ
Oracle
（DBWR）
は通常、ディスクI/Oを減らすために、バッファが足りなくなっ
たときなどのタイミングにだけ、更新されたデータをファイルに書き込んでいる
（遅延書き込み）
。そのため、Oracle インスタンスが突然止まってしまったような
場合には、ファイル上のデータとバッファ上のデータに不整合が生じてしまう。
再起動時にこの不整合を解消するための処理をインスタンスリカバリという。
具体的には、正常にコミットされた情報をすべてディスク上に書き出し、コミッ
トされなかった情報についてはロールバックするという処理が行われる。このよ
うな処理が行われるため、インスタンスリカバリが行われると、通常より起動に
時間がかかる。
ロック待ちによるユーザークレームへの対処
トラブルの原因としてロック待ちが考えられる場合には、まず、どのセッショ
ンがロック待ちになっているのか状況を確認し、次に、ロックの原因になってい
るセッションはどれかを突き止める必要がある。ロック待ち状況とロックの原因
になっているセッションは次のようなSQLを使って確認することができる。確認
できたら、状況に応じて対処するまでが DBA の仕事である。
ロック待ち状況を確認する SQL
どのセッションが待たされているのかを調査するための SQL。同時に、どれくら
い待たされているかも知ることができる。
SQL> select a.sid, a.serial#, b.type,
to_char(b.ctime/60,'999990.9') Min, c.sql_text
from v$session a, v$lock b, v$sqlarea c
where a.lockwait = b.kaddr
and a.sql_address = c.address
order by b.ctime desc;
30
ユーザーから、「お待ち
ください」のまま動かな
いというクレームがあっ
たら試してみよう。
犯人を特定する SQL
原因となっているセッションを見つけるには以下の SQL を使う。待たされてい
るセッションとペアで表示されたのが原因のセッションである。
SQL> select b.id1,a.sid, a.serial#, b.type, to_char(b.ctime/60,'999990.9') MIN
,decode(b.lmode,1,'null',2,'row share',3,'row exclusive'
,4,'share',5,'share row exclusive',6,'exclusive') LMODE
,decode(b.request,1,'null',2,'row share',3,'row exclusive'
,4,'share',5,'share row exclusive',6,'exclusive') REQUEST
from v$session a, v$lock b
REQUEST=0の場合ロ
where a.sid = b.sid
ックを取得していない
and (b.id1,b.id2) in
ということになる。
(select d.id1,d.id2 from v$lock d
where d.id1=b.id1 and d.id2=b.id2 and d.request > 0)
order by b.id1,b.ctime desc;
状況に応じて対処
どのように対処するかは、状況によって変わってくる。COMMIT しないまま作
業を続けている場合には、ロックを取得しているユーザーに COMMIT してもら
うことになるし、PC の電源を切ってしまったために、セッションが中途半端に
残ってロックを取得したままになっているような場合には、該当セッションを
KILL する必要がある。
COMMIT;
ROLLBACK;
ALTER SYSTEM KILL SESSION sid, serial$ etc.
該当ユーザーに連絡をとる等、
状況に応じて対応しよう
31
必要なデータディクショナリを探す
数多くのデータディクショナリから自分が欲しい情報を見つけ出すためには、
以下のような SQL を、WHERE 条件に必要なキーワードを指定して実行する。
DICTIONARY ビューを使う
この例はソースに関する情報の入ったデータディクショナリを調べたい場合。名
前に SOURCE が含まれるテーブルを SELECT している。調べたい情報に応じ
てキーワードを変えてみる。
SQL> select * from dictionary
where table_name like '%SOURCE%';
DBA_DEPENDENCIES の活用
DBA_DEPENDENCIESを参照すれば、オブジェクト間の依存関係がわかる。こ
れを使えば、ロックされているテーブルに依存しているテーブルを調べることが
できる。また、アプリケーションの変更による影響を調べて事前に手を打つよう
な場合にも利用できる。
今日変更されたオブジェクトと影響を受けるオブジェクト
アプリケーションの変更を知らずにユーザーからのロック待ちに対するクレーム
対応をさせられるのではたまらない。下記の SQL のようにすれば、アプリケー
ションの変更による影響度を調査できる。
SQL> select o.owner,o.object_name CHANGED_OBJECT,o.object_type
,o.created,o.last_ddl_time,o.status
,o2.owner,o2.object_name REFRENCE_OBJ,o2.object_type
from dba_objects o, dba_objects o2, sys.dependency$ d
where o.last_ddl_time = sysdate
and o.owner not in ('SYS','SYSTEM')
and d.d_obj# = o.object_id
and d.p_obj# = o2.object_id
and o.object_name ！ = o2.object_name
and o2.owner ！ = 'SYS';
32
＝SYSDATEを＞＝
SYSDATE−10とすれば
10日以内に変更された
ものが対象となる。
ロックの競合が起きているテーブルにアクセスしているのは
ロックが多発している場合などは、
あるテーブルに対する更新が入り乱れている
かもしれない。SCOTT.EMP にアクセスしているオブジェクトは、以下のよう
にして調査できる。
SQL> select * FROM dba_dependencies
where referenced_owner = ‘SCOTT’
and referenced_name = ‘EMP';
テーブル定義の変更で影響を
受けるストアドオブジェクト
も調査できる
DBA のお仕事の醍醐味（？）を垣間見る
ユーザーからのクレームに対応する、要望に応える、といった受身の姿勢でな
く、いろいろな角度から常に先手をうっていく。それがDBAのお仕事の醍醐味？
33

Download Report