忘れかけのIT備忘録

今まで学んできた知識や小技、なるほど!と思ったことをメモするブログです。

システム権限とオブジェクト権限

●第三者にも付与できるようシステム権限を付与する場合

GRANT システム権限 TO ユーザ名 WITH ADMIN OPTION;
※SYSユーザで実施する
※取り消しても(REVOKEしても)第三者に付与された権限は残る

●第三者にも付与できるようオブジェクト権限を付与する場合

GRANT オブジェクト権限 ON オブジェクト名 TO ユーザ名 WITH GRANT OPTION;
※下記ユーザで実施する
 ・オブジェクトの所有者
 ・GRANT ANY OBJECTS PRIVILEGEシステム権限を付与されたユーザー
 ・GRANT OPTION付きでオブジェクト権限を付与されたユーザー
※取り消した(REVOKEした)場合、第三者に付与されたオブジェクト権限も取り消される

UNDOデータの管理(11g)

UNDOデータとは変更前のデータ(コミット前のデータ)を指す

主に
・読み取り一貫性
ロールバック
・フラッシュバック機能(一部)
インスタンスリカバリ
の目的で使用する

UNDOデータは自動UNDO管理と手動UNDO管理に分けられるがここでは自動UNDO管理(9iから推奨になった)について記載する

自動UNDO管理は必要なUNDOセグメント数やサイズを自動的に管理してくれる
下記の初期化パラメータ設定が必要
・UNDO_MANAGEMENT(自動UNDO管理の場合、AUTOにする)
・UNDO_TABLESPACE(UNDO表領域名)
・UNDO_RETENTION(UNDOデータの保存期間)

UNDO表領域にはUNDOデータ以外は格納できない
1つのトランザクションのUNDOデータは1つのUNDOセグメントで管理されるが、1つのUNDOセグメントで複数のトランザクションのUNDOデータを管理できる(トランザクション 1..*:UNDOセグメント 1)
UNDOセグメントはエクステントを循環的に使用し、自動的にエクステントの取得・解放を行う

自動UNDO管理の場合、UNDO_RETENTIONに指定された期間(デフォルト900秒)はUNDOデータが保存される
ただし、UNDO_RETENTIONは努力値であり、UNDO保存の保証(デフォルト無効)が無効の場合、UNDO_RETENTIONで指定された期間内でも表領域サイズ不足等でUNDOデータが上書きされる可能性がある
※アクティブなUNDO(未コミットのトランザクションのUNDOデータ)は絶対に上書きされないが、期限切れではないUNDO(UNDO_RETENTION期間内だがコミット済みトランザクションのUNDOデータ)は上書きされる可能性がある
尚、期限切れのUNDO(UNDO_RETENTION期間内かつコミット済みトランザクションのUNDOデータ)は上書き可能なのでこれから優先的に上書きされていく

例えば、
長時間掛かるSELECT開始後、UNDO_RETENTION経過またはSELECT中に別トランザクションで該当データをDML・コミットした場合、UNDOデータが上書きされる
→長時間掛かるSELECTセッションはUNDOデータが参照できないため、「ORA-01555」が発生する

上記の対策として、
・UNDO_RETENTION値を増やす
・UNDO保存の保証を有効にする(alter tablespace UNDO表領域 retention guarantee;)
がよくある手段だが、物理的にUNDO表領域がサイズ不足になると今度は「ORA-30036」エラーが発生する。諸刃の剣である。

尚、UNDOアドバイザを活用すると良い
UNDOアドバイザを使用する前に考慮しておくこととして
・最も長くかかるSELECTの実行時間
・フラッシュバック機能をサポートするためのUNDO保存期間
の考慮が必要となる

ちなみに自動UNDO管理であっても下記ケースはUNDO_RETENTIONが無視されるので注意
・UNDO表領域が固定サイズ(UNDO表領域の自動拡張が無効)
・UNDO保存の保証が無効

一時UNDOを使うとUNDO表領域の使用量は減るが、一時表領域の使用量が増えるので注意

表領域の作成時に指定する項目

表領域の作成時に指定する項目は下記の通り
・エクステント管理方法
・タイプ
・ステータス
・エクステント割当てサイズ
・セグメント領域管理方法
・ロギング

エクステント管理方法
表領域のデータファイル(エクステントの使用状況)の管理方法を指定する
・ローカル管理表領域(EXTENT MANAGEMENT LOCAL) ※推奨
ビットマップで管理する(0:空き、1:使用中)

・ディクショナリ管理表領域(EXTENT MANAGEMENT DICTIONARY)
SYSTEM表領域のデータディクショナリで管理する
表更新の都度、UNDOセグメントが生成される等のデメリットがある

タイプ
・永続表領域(PARMANENT)
・一時表領域(TEMPORARY)
・UNDO表領域(UNDO)

ステータス
・READ WRITE
・READ ONLY(SYSTEM表領域とSYSAUX表領域はREAD ONLYにできない)
・オフライン(バックアップやリカバリ等で使用する)

エクステント割当てサイズ
・自動(AUTOALLOCATE)
デフォルト64KB単位で割当てるが、オブジェクトのサイズが1MBを超える場合、1MB単位で割当てる

・均一(UNIFORM)
ユーザーが指定したサイズ単位で割当てる
デフォルト1MB

セグメント領域管理
空きブロック(ブロックの使用状況)の管理方法
ローカル管理表領域の場合、自動セグメント領域管理となる

・自動セグメント領域管理
ビットマップで管理する
ASSM(自動セグメント領域管理)で管理される

・手動セグメント領域管理
空きリストで管理する

ロギング
表領域のオブジェクト更新時のREDOログを生成するか否か指定する

サーバープロセス

サーバープロセスはUGAに格納されるが「専用サーバー接続モード」と「共有サーバー接続モード」で格納先が変わる

サーバープロセス
サーバープロセスが使用する領域は下記の通り
①ユーザーセッションデータ
②カーソル領域(SQLの実行時に使用するカーソルを格納する領域)
③ソート領域
④スタック領域(ローカル変数を格納する領域)
※上記のうち、①~④がUGAに格納される

専用サーバー接続モード
UGAはすべてPGAに格納される
ユーザープロセスとサーバープロセスは1対1の関係

共有サーバー接続モード
スタック領域はPGAに格納される
他(ユーザーセッションデータ、カーソル領域、ソート領域)はSGA(共有プール)に格納される
尚、ラージプールを構成している場合、共有プールではなくラージプールに格納される
ユーザープロセスとサーバープロセスは1対多の関係
共有サーバー接続の場合、ユーザープロセスとサーバープロセスが直接通信するのではなく、ディスパッチャを経由して通信する(ユーザープロセス⇔ディスパッチャ⇔サーバープロセス)

Oracle Databaseの起動シーケンス

Oracle Databaseの起動シーケンスは4段階ある。

①SHUTDOWN→②NOMOUNT→③MOUNT→④OPEN

①SHUTDOWN
データベースが停止している状態

②NOMOUNT
初期化パラメータを読み込んで処理をする段階
・初期化パラメータを読み込む
・SGAを展開する
・バックグラウンドプロセスを起動する
・アラートログをオープンする

このモードでは下記作業が可能
・データベース作成
・制御ファイルの再作成

③MOUNT
制御ファイルを読み込んで処理をする段階
・制御ファイルを読み込む(ここでデータファイルやREDOログファイルの格納先をOracleが把握する)
・(必要に応じて)インスタンスリカバリを行う

このモードでは下記作業が可能
・データファイル名の変更
・データベースのリカバリ
アーカイブログモードの切り替え

④OPEN
・データファイル、REDOログファイルをオープンする