オフライン中のトランザクションについて

質問

表領域をオフラインにした場合、オフライン前に開始されたトランザクションは有効ですが、オフラインのまま、コミット、または、ロールバックして、表領域をオンラインにしても、整合がとれるのはなぜなのでしょうか。
コミットするか、ロールバックするかの情報はどこに保持してるのか疑問です。
(オフラインにしてから、ファイルをリネームし、
トランザクションをロールバックして、
ログをアーカイブし、DB再起動後に、ファイル名を戻して、
オンラインにすると、ちゃんとロールバックされています。
同じ操作で、コミットするとちゃんとコミットされています。
知っている方には当然なのでしょうが、私にとっては、不思議です)

詳しい方がみえましたらご教授お願いいたします。

回答No.6

ossan_hiro · ベストアンサー

データベース概要のマニュアルに

「表領域がオフラインになると、Oracleでは後続のSQL文でその表領域内に含まれるオブジェクトを参照できなくなります。表領域内のデータを参照する完了済の文を含むアクティブ・トランザクションは、トランザクション・レベルでは影響を受けません。それらの完了済の文に対応するロールバック・データは、SYSTEM表領域にある遅延ロールバック・セグメントに保存されます。表領域が再びオンライン化されると、このロールバック・データは必要に応じて表領域に適用されます。」

とあるので「SYSTEM表領域にある遅延ロールバック・セグメントに保存」されるようです。

お礼

ありがとうございます!!

まさに、知りたかった内容が、"遅延ロールバック・セグメント"
を検索することで知ることができました。

本当にありがとうございました!

回答No.5

ossan_hiro

>ひょっとして、オフラインの表領域のトランザクションが未確定の場合、
>ログスイッチによって、その部分のログがアーカイブされないで
>カレントログに残るってことでしょうか?
「オフラインの表領域のトランザクションが未確定の場合、」というのはcommit/rollbackしていないトランザクションを指しますか？
commit/rollbackしていないトランザクションはREDOログバッファにあって、REDOLOGファイルには基本的には入りません。
（例外：REDO ログ・バッファがいっぱいになるか、別のトランザクションがコミットされるなどでREDOログファイルに含まれます）

表領域をオフラインにする際(NORMAL(デフォルト)指定)、データベースは表領域のデータ・ファイルすべてのチェックポイントを取ってから、それらのファイルをオフライン化します。

補足

>ひょっとして、オフラインの表領域のトランザクションが未確定の場合、

すいません。

オフラインの表領域のトランザクションがコミット・ロールバックされた場合

の間違いでした。

>表領域をオフラインにする際(NORMAL(デフォルト)指定)、データベースは表領域のデータ・ファイルすべてのチェックポイントを取ってから、それらのファイルをオフライン化します。

そのとおりなのですが、、
わからないのは、オフライン化の後で、コミット・ロールバックした場合、
その情報をどこに保持してるかが知りたいのですが、、、。

回答No.4

ossan_hiro

あまり自身ないですが・・・。
変更の情報はREDOログにあります。
インスタンスリカバリに関してはcommitした／しないに関わらず、適用し、その後にcommitしていない情報をrollbackします。
REDOログに残っているのであれば、インスタンスリカバリでREDOが適用されてcommitされた内容が表示されているのだと思います。
＃REDOログが上書きされるタイミングで対象表領域すべてがOFFLINEだとどうなるかは不明ですけど・・・

また、トランザクションがコミットされると、ロールバックまたはトランザクション・リカバリの実行にUNDO データは不要になります。とマニュアル(10g)にあるのでcommit後のUNDOの変更は関係ないと思います。

補足

回答ありがとうございます。

>変更の情報はREDOログにあります。
>インスタンスリカバリに関してはcommitした／しないに関わらず、適用し、その後にcommitしていない情報をrollbackします。
>REDOログに残っているのであれば、インスタンスリカバリでREDOが適用されてcommitされた内容が表示されているのだと思います。

ひょっとして、オフラインの表領域のトランザクションが未確定の場合、
ログスイッチによって、その部分のログがアーカイブされないで
カレントログに残るってことでしょうか?
ただ、検証が難しそうですね、、。

回答No.3

MZ-80B

> 不完全リカバリになるのではないかな・・・

「ログをアーカイブし、～」と書かれていますから
アーカイブログ運用しているということですよね。

不完全リカバリになる。ではなくアーカイブを使って
完全リカバリ可能に訂正いたします。

回答No.2

MZ-80B

UNDO表領域を変更とは
正常なUNDO表領域の切り替えですか？メディアリカバリですか？
デフォルトの切り替えであればUNDOセグメントヘッダ情報が
移動したのではないでしょうか

補足

以下のようにUNDO表領域をUNDOTBS01 -> UNDOTBS02に変更しました。
shutdown immediate;
startup nomount;
alter system set undo_tablespace = 'UNDOTBS02' scope=spfile;
alter database mount;
alter database open;

オープン時には、UNDOTBS01にはoracleからアクセスできないと思うので、
UNDOセグメントヘッダ情報が移動はできないような気がするのですが、、

回答No.1

MZ-80B

質問内容はデータ表領域がオフラインなのになぜコミットできるかというと同じです。
コミット操作はUNDOセグメント（ロールバックセグメント）ヘッダの
トランザクション表にSCN付きで記録されますのでデータ表領域のIOは遅延することができます。
次の表アクセス時にUNDOセグメントヘッダからデータ表領域に書き込まれます。

シャットダウンしてUNDO表領域も同時に壊しておくと、たぶんオフライン前までの
不完全リカバリになるのではないかな・・・

補足

回答ありがとうございます。

早速、以下のように検証してみました。

更新処理 -> オフラインに変更 -> コミット -> シャットダウン
-> UNDO表領域を変更 -> オープン -> オンラインに変更

残念ながら、正しくコミットしたデータが確認できてしまいました。
ロールバックでも正しくロールバックしたデータが確認できました。

ひょっとして、SYSTEM表領域にこっそり情報を保持してるんでしょうか?