Fw about undo and rollback segment corruption

nmgzw

刚才在论坛里看到 lovexueer做了个试验http://www.itpub.net/533872.html，用这个隐含参数不能恢复！试了半天，发现情况一样，于是就查了下，发现他说的这种情况根本就不能用这个参数恢复成功！原文参见1013221.6（metalink）。

这个主要针对8i，对于9i有些涉及到rollback 色光segment的地方注意下，但大体不变！

一、当由于undo的原因数据库down了后，当你试图启动的时候遇到了ora-1157和ora-1110，在这种情况下依赖数据库down的时候，是否在undo里留下了未提交的事务！

1、如果没有遗留的事务在undo内，那么最简单的恢复办法就是offline drop这个文件，然后以restricted模式打开数据库，删除这个undo表空间，下面是步骤：

a、在alert.log中查看数据库是否干净的关闭。

b、注释掉(8i)rollback_segments或则加(9i)_corrupted_rollback_segments = ( ,...., ) 同时把undo_management改为manual

c、startup restrict mount

d、alter database datafile 'file_name' offline drop;

e、recover database until cancel;(这步可能用到redo，多试几次）

f、alter database open resetlogs;

ｇ、导出全库

ｈ、重建数据库

ｉ、导入新库

２、如果数据库并不是干净的关闭，也就是说undo内留有未提交的事务，那么这时候不能够简单的利用offline drop这个回滚文件，你必须从一个备份中恢复这个文件，并进行介质恢复！如果是在非归档模式下，仅当在线日志包含恢复过程中需要的日志信息，以下是步骤：

a、从备份中恢复丢失的文件

b、mount数据库

c、查看文件状态，如果为offline，那么你必须online它

select file#,name,status from v$datfile;

alter database datafile 'full_name' online;

d、查看日志文件信息

select v1.group#,member,sequence#,first_change#

from v$log v1,v$logfile v2

where v1.group#=v2.group#;

e、如果是在非归档模式下

select file#,change# from v$recover_file;

如果change#大于在线日志文件的最小的first_change#，那么这个数据文件将能恢复。如果chage#小于最小的first_chage#，那么不能恢复

f、recover datafile 'full_name'

g、确认所有在线日志文件都被应用

h、打开数据库

二、如果数据库是打开状态

如果在数据库处于运行状态，你发现了丢失会滚数据文件，那么有两种办法：

1、offline drop,并从备份中恢复

a、alter database datafile 'full_name' offline ;

b、恢复丢失的文件

c、select v1.group#,member,sequence# from v$log v1,v$logfile v2where v1.group#=v2.group#;

e、recover datafile 'full_name';

f、alter database datafile 'full_name' online';

2、重新创建会滚表空间

a、alter rollback segment offline;

b、查看所有回滚段是否都已offline

select segment_name,status from dba_rollback_segswhere tablespace_name='';

c、删除offline的回滚段

drop rollback segment ;

e、查看所有剩余仍为online的会滚段

SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '' AND SEGMENT_ID = USN;

如果没有返回行，说明所有的已经offline；如果返回行，状态显示为pending offline，那么查看active_tx,如果为0，那么没有悬挂的事务，很快就会变为offline，如果大于0，那么看下一步


f、SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME "ROLLBACK"
FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
WHERE R.NAME IN ('', ... , '')
AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;

杀死上面发现的这些会话：
alter system kill session 'sid,serial#';

g、drop tablespace ... including contents;

h、重新创建表空间和回滚段！

RMAN: 制御ファイルが壊れてしまった場合のリカバリ方法 (8.0/8.1)

文書番号 15912 最終更新日 2005-04-21
製品名(バージョン)[コンポーネント] Oracle Server - Enterprise Edition (8.0 - ) [Recovery Manager]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 15854 　
概要 RMAN: 制御ファイルが壊れてしまった場合のリカバリ方法 (8.0/8.1)
内容:

[Problem]
制御ファイルが壊れてしまいました。
他のデータファイルやオンラインREDOログファイルは壊れていません。
RMANでバックアップを取得しています。
RMANによる復旧方法について教えてください。

[To reproduce]
制御ファイルが壊れた場合、このようなエラーが発生します。

SVRMGR> select * from v$datafile;
FILE# CREATION_C CREATION_ TS# RFILE# STATUS ENABLED CHECKPO
INT CHECKPOIN UNRECOVERA UNRECOVER LAST_CHANG LAST_TIME OFFLINE_CH ONLINE_CHA ON
LINE_TI BYTES BLOCKS CREATE_BYT BLOCK_SIZE NAME
PLUGGED_IN
---------- ---------- --------- ---------- ---------- ------- ---------- -------
--- --------- ---------- --------- ---------- --------- ---------- ---------- --
------- ---------- ---------- ---------- ---------- ----------------------------
---------------------------------------------------- ----------
ORA-00210: 指定された制御ファイルをオープンできません。
ORA-00202: 制御ファイル: '/rman/oradata/tar816/control01.ctl'
ORA-27041: ファイルをオープンできません。
SVR4 Error: 2: No such file or directory
Additional information: 3
SVRMGR>

[Action]
以下は、データベースの制御ファイルのみが壊れてしまった場合の対処方法です。
制御ファイル以外のデータファイルやオンラインREDOファイルが壊れていない
ということが前提となっています。ご注意ください。

1. データベースをshutdownします。
制御ファイルが壊れているので、shutdown normalはできません。
shutdown abortをします。

2. データベースをnomount状態にします。
SVRMGR> startup nomount

3. RMANを起動しカタログとターゲットに接続します。
% rman target system/manager@target catalog rman/rman@catalog

Recovery Manager: リリース 8.1.6.0.0 - Production

RMAN-06006: ターゲット・データベース: tar816(マウントされていません)に接続されました。
RMAN-06008: リカバリ・カタログ・データベースに接続されました。

RMAN>

nomount状態なので、上記のような出力になります。

4. RMANで制御ファイルをrestoreし、データベースをmountします。
RMAN> run {
2> allocate channel ch1 type disk;
3> restore controlfile;
4> sql 'alter database mount';
5> }

実行ログの一部：
===============================================================================
RMAN-03022: コンパイル・コマンド: restore

RMAN-03022: コンパイル・コマンド: IRESTORE
RMAN-03023: 実行コマンド: IRESTORE
RMAN-08016: チャネル ch1: データファイル・バックアップ集合の復旧を開始しています。
RMAN-08502: set_count=3 set_stamp=405026127 creation_time=20000807 19:15:27
RMAN-08021: チャネル ch1: 制御ファイルをリストアしています。
RMAN-08505: 出力ファイル名=/rman/oradata/tar816/control01.ctl
RMAN-08023: チャネル ch1: バックアップ部分: 1がリストアされました。
RMAN-08511: 部分ハンドル=/rman/backup/fullTAR816_3_1 タグ=null パラメー
タ=NULL
RMAN-08024: チャネル ch1: リストア完了
RMAN-08058: 制御ファイルをレプリケートしています。
RMAN-08506: 入力ファイル名=/rman/oradata/tar816/control01.ctl
RMAN-08505: 出力ファイル名=/rman/oradata/tar816/control02.ctl
RMAN-08505: 出力ファイル名=/rman/oradata/tar816/control03.ctl
===============================================================================

Oracle8.1.xでは、restore controlfile; と実行するだけで、
initパラメータファイルの control_files に書かれているすべてのファイルを
指定された位置にリストアします。
Oracle8.0.xをお使いの場合には、restore controlfile to xxx と
replicate controlfile from xxxx を実行する必要があります。
replicate controlfile コマンドを実行するためにはTYPE DISKのチャネルを
追加して下さい。

5. バックアップから戻した制御ファイルのためにリカバリを行うのですが、
その前にリカバリのための準備(リカバリカタログにアーカイブログファイルを登録)
をします。

まず、確認のために以下のコマンドを実行します。

RMAN> change archivelog all crosscheck;

実行ログの一部：
===============================================================================
RMAN-03022: コンパイル・コマンド: change
RMAN-06158: アーカイブログの妥当性チェックが正常に終了しました。
RMAN-08514: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_3.
arc レコードID=28 スタンプ=405273299
===============================================================================

Oracle8.1.x では、crosscheckですが、Oracle8.0.x では、
RMAN> change archivelog all validate;
とします。
このコマンド実行時に、ある条件を満たしていないと RMAN-6038、RMAN-20242 が発生します。
エラーの発生についての詳細は Krown#26779をご覧下さい。
また Oracle8.1.6.0-8.1.6.2 をお使いの場合には、このコマンドが正常に機能しないことが
あります。詳細については、Krown#26779 と Krown#18715 をご参照ください。

ここで、出力があったアーカイブログファイルについては、
log_archive_dest に存在し、かつ、リカバリカタログに情報が格納されています。
次に initパラメータ log_archive_dest で指定されているディレクトリを確認してください。
log_archive_destにあるが、
RMAN> change archivelog all crosscheck;
で出力がなかったファイルについては、リカバリカタログに登録されていません。
それらのアーカイブログファイルは、catalogコマンドでリカバリカタログに登録しなくて
はいけません。

catalogコマンドの使用例)

RMAN> catalog archivelog '/rman/admin/tar816/arch/arch_1_4.arc';

このコマンドで、log_archive_destにあるアーカイブログファイル arch_1_4.arc を
リカバリカタログに登録します。

・この実行がどのような役割を示しているかですが：
RMANでは、制御ファイルとリカバリカタログが同期を取ることにより、
ターゲットデータベースの情報をリカバリカタログに格納します。
そのためのRMANコマンドが resync catalog; です。
制御ファイルが壊れた場合、壊れる前の最後にresyncを行なった時からの後の
ターゲットデータベースの情報がまだリカバリカタログに入っていない状態になっています。
この状態のまま、RMANでrecoverコマンドを実行すると、
RMAN-08060: アーカイブログが見つかりません。
RMAN-08510: アーカイブログ・スレッド=1 順序=4
というエラーになり、recoverが途中で終了してしまいます。

log_archive_destにあるが、RMANのリカバリカタログにないというアーカイブログファイル
については、すべてcatalogコマンドを実行してください。
(ここで登録するファイルがたくさんあった場合には、resyncを定期的に行なっていなかった
ということになります。今後はresyncをまめに実行するようにしましょう。)

6. RMANでrecoverコマンドを実行し、データベースをopenします。
RMAN> run {
2> allocate channel ch1 type disk;
3> recover database;
4> sql 'alter database open resetlogs';
5> }

実行ログの一部：
===============================================================================
RMAN-03022: コンパイル・コマンド: allocate
RMAN-03023: 実行コマンド: allocate
RMAN-08030: チャネル ch1が割り当てられました。
RMAN-08500: チャネル ch1: sid=8 devtype=DISK

RMAN-03022: コンパイル・コマンド: recover

RMAN-03022: コンパイル・コマンド: recover(1)
RMAN-03023: 実行コマンド: partial resync
RMAN-08003: リカバリ・カタログの部分再同期を開始します。
RMAN-08005: 部分再同期完了

RMAN-03022: コンパイル・コマンド: recover(2)

RMAN-03022: コンパイル・コマンド: recover(3)
RMAN-03023: 実行コマンド: recover(3)
RMAN-08054: メディアのリカバリを開始します。

RMAN-03022: コンパイル・コマンド: recover(4)
RMAN-06050: アーカイブログ・スレッド 1、順序 3は、ファイル /rman/admin/t
ar816/arch/arch_1_3.arcとしてディスクにあります。
RMAN-06050: アーカイブログ・スレッド 1、順序 4は、ファイル /rman/admin/t
ar816/arch/arch_1_4.arcとしてディスクにあります。
RMAN-06050: アーカイブログ・スレッド 1、順序 5は、ファイル /rman/admin/t
ar816/arch/arch_1_5.arcとしてディスクにあります。
<< 中略 >>
RMAN-06050: アーカイブログ・スレッド 1、順序 33は、ファイル /rman/admin/
tar816/arch/arch_1_33.arcとしてディスクにあります。
RMAN-06050: アーカイブログ・スレッド 1、順序 34は、ファイル /rman/oradat
a/tar816/redo03.logとしてディスクにあります。
RMAN-06050: アーカイブログ・スレッド 1、順序 35は、ファイル /rman/oradat
a/tar816/redo02.logとしてディスクにあります。
RMAN-06050: アーカイブログ・スレッド 1、順序 36は、ファイル /rman/oradat
a/tar816/redo01.logとしてディスクにあります。
RMAN-03023: 実行コマンド: recover(4)
RMAN-08017: チャネル ch1: デフォルトの宛先へのアーカイブログの復旧を開始しています。
RMAN-08022: チャネル ch1: アーカイブログをリストアしています。
RMAN-08510: アーカイブログ・スレッド=1 順序=2
RMAN-08023: チャネル ch1: バックアップ部分: 1がリストアされました。
RMAN-08511: 部分ハンドル=/chiyoda/rman/backup/arcTAR816_8_1 タグ=null パラメータ
=NULL
RMAN-08024: チャネル ch1: リストア完了
RMAN-08515: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_2.
arc スレッド=1 順序=2
RMAN-08515: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_3.
arc スレッド=1 順序=3
RMAN-08515: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_4.
arc スレッド=1 順序=4
RMAN-08515: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_5.
arc スレッド=1 順序=5
<< 中略 >>
RMAN-08515: アーカイブログ・ファイル名=/rman/admin/tar816/arch/arch_1_33
.arc スレッド=1 順序=33
RMAN-08515: アーカイブログ・ファイル名=/rman/oradata/tar816/redo03.log
スレッド=1 順序=34
RMAN-08515: アーカイブログ・ファイル名=/rman/oradata/tar816/redo02.log
スレッド=1 順序=35
RMAN-08515: アーカイブログ・ファイル名=/rman/oradata/tar816/redo01.log
スレッド=1 順序=36
RMAN-08055: メディアのリカバリが完了しました。

RMAN-03022: コンパイル・コマンド: sql
RMAN-06162: SQL文: alter database open resetlogs
RMAN-03023: 実行コマンド: sql
RMAN-08031: チャネル ch1をリリースしました。

RMAN>
===============================================================================

ログより、オンラインのREDOログについても適用できていることがわかります。

7. データベースをresetlogsオプションをつけてopenしたため、
リカバリカタログにもそれを通知します。

RMAN> reset database;

8. 今後の障害のために、必ずバックアップを取得してください。

9. ローカル管理一時表領域を使用している場合には、TEMPファイルの追加が必要です。

補足：
RMANを使用しない制御ファイルの復旧方法については、Krown#15854にあります。
Oracle9iでは、リカバリカタログに最新のアーカイブログ情報がなかったとしても、
catalogコマンドでアーカイブログファイルを登録する必要はありませんので、
上記の手順とは異なります。

[更新履歴]
2003/10/06 Oracle9iについて補足事項を追記


キーワード：

制御ファイル 破壊 RMAN リカバリ RESTORE CONTROLFILE

71501 制御ファイルのリカバリ方法--全ての制御ファイルの障害の場合 (for UNIX)

文書番号 71501 最終更新日 2003-11-20
製品名(バージョン)[コンポーネント] Oracle Server - Enterprise Edition (ALL - ALL) [バックアップ＆リカバリ一般]
プラットフォーム(バージョン) すべてのプラットフォーム (UNIX - )
関連文書 71169 　 62436 　
概要 制御ファイルのリカバリ方法--全ての制御ファイルの障害の場合 (for UNIX)
内容:

[概要]
制御ファイルのリカバリ方法--全ての制御ファイルの障害の場合(for UNIX)

[内容]
本KROWNでは、全ての制御ファイルが壊れてしまった場合のリカバリ方法に
ついて説明します。多重化した制御ファイル内の一部が壊れた場合の
リカバリ方法については、KROWN#71169 を参照してください。
制御ファイル以外のデータファイルやオンラインREDOログが壊れていないことが
前提ですので、注意してください。

[対象リリース]
Oracle7 Server/Oracle7 Workgroup Server 7.x
Oracle8 Enterprise Edition/Oracle8 Standard Edition 8.0.x
Oracle8i Enterprise Edition/Oracle8i Standard Edition 8.1.x
Oracle9i Database Release1 (9.0.1.x)
Oracle9i Database Release2 (9.2.x)

[対象プラットフォーム]
Unixプラットフォーム

[エラー内容]

制御ファイルが壊れた場合には、以下のようなエラーが発生する可能性があります。
----------
ORA-00205: error in identifying controlfile, check alert log for more info

ORA-00210: cannot open the specified controlfile
ORA-00202: controlfile: '/home/oradata/ora920/control01.ctl'
ORA-27041: unable to open file

ORA-00202: controlfile: '/home/oradata/ora920/control01.ctl'
ORA-27037: unable to obtain file status

ORA-00202: controlfile: '/home/oradata/ora920/control01.ctl'
ORA-27046: file size is not a multiple of logical block size
----------

＃注意＃
上記はあくまでも例であり、破損状況によっては、その他のエラーが
発生する可能性もあります。

[リカバリ方法]
以下は、制御ファイルが全損した場合のリカバリ方法となります。

1. 制御ファイルのバックアップをどのように取得していたのか、そして
　 アーカイブログモード又はノーアーカイブログモードであるかを
確認してください。

・コールドバックアップを取得
・alter database backup controlfile to '/.../.../control.bak<ファイル名>' で取得
・アーカイブログモードでの運用
---> <手順A> を参照してください。

　 ・alter database backup controlfile to trace で取得
　 ・バックアップの取得なし
　 ・ノーアーカイブログモードでの運用
---> <手順B> を参照してください。

　 ・RMAN(Recovery Manager) を使用して取得
　　---> KROWN#15912 を参照してください。

---------------------------------------------------------------------------
<手順A>:
制御ファイルのコールドバックアップ 又は
alter database backup controlfile to '<ファイル名>'によるバックアップ 又は
アーカイブログモードでの運用の場合
---------------------------------------------------------------------------

1. インスタンスがまだ起動している場合、データベースを shutdown します。
　 制御ファイルが破損している時には、shutdown abort での停止を
　 行う必要があります。

SQL> shutdown abort;
ORACLE instance shut down.

2. バックアップしてあった制御ファイルをリストアします。
<例>バックアップしてあった制御ファイル：control.bak
壊れてしまった制御ファイル：control01.ctl control02.ctl control03.ctl

% cp /.../.../.../control.bak /home1/.../.../control01.ctl
% cp /.../.../.../control.bak /home2/.../.../control02.ctl
% cp /.../.../.../control.bak /home3/.../.../control03.ctl

3. 初期化パラメータファイル内の control_files 句がリストアした制御ファイルの
正しい位置を示しているのかを確認します。

　 <例> initora920.ora 内の control_files 句を確認します
---------------
control_files = /home1/.../.../control01.ctl,
/home1/.../.../control02.ctl,
/home1/.../.../control03.ctl
---------------

4. データベースを mount します。

SQL> startup mount;

　 ※制御ファイルのリストアを行った後の mount 時には、ORA-1991 が
　　 発生した場合には、KROWN#13452 を参照し、パスワードファイルの
　　 再作成を実行してください。

5. using backup controlfile 句を使用してリカバリを実行します。

　 SQL> recover database using backup controlfile until cancel;
　　
　 この時、順番に Enter を押して、ORA-308 が発生するまで
　 アーカイブREDOログを適用してください。その後、アーカイブされていない
　 オンラインREDOログを順番に手動で指定し、適用します。

<実行例>
"Enter" を押してORA-308が出力されるまで、アーカイブREDOログの適用を行います。
　　----------
　　ORA-00279: 変更99866(10/23/2003 17:43:09で生成)にはスレッド1が必要です
　　ORA-00289: 検討すべきログ・ファイル:/home/oradata/arch/1_19.dbf
　　ORA-00280: 変更99866(スレッド1)は順序番号19に存在します。
　
　　ログの指定: {=suggested | filename | AUTO | CANCEL}
----------
　　
･･･

その後、ある時点で以下のように ORA-308 のエラーが発生しますので、再度
recover database using backup controlfile until cancel を実行し、
オンラインREDOログのフルパスを指定し、"Enter" を実行します。

-----------
　　ORA-00308:
　　アーカイブ・ログ/home/oradata/arch/1_25.dbfをオープンできません。
　　ORA-27037: ファイル・ステータスを取得できません。
　　SVR4 Error: 2: No such file or directory
　　Additional information: 3
-----------

再度 recover database using backup controlfile until cancel を実行し、
オンラインREDOログへのフルパスを指定し、"Enter" を押します。
"メディア・リカバリが完了しました" と表示されるまで、オンラインREDOログを順番に
指定し、適用していきます。

　　SQL> recover database using backup controlfile until cancel;
　　ORA-00279: 変更99912(10/23/2003 17:44:47で生成)にはスレッド1が必要です
　　ORA-00289: 検討すべきログ・ファイル:/home/oradata/arch/1_25.dbf
　　ORA-00280: 変更99912(スレッド1)は順序番号25に存在します。

　　ログの指定: {=suggested | filename | AUTO | CANCEL}
　　/home/oradata/ora920/redo01.log <--** オンラインREDOログへのパス
　　ログが適用されました。
　　メディア・リカバリが完了しました。<--** リカバリは完了したと表示されます。

　＃注意＃
　この時、NOARCHIVELOG モードで until cancel を指定してのリカバリは出来ません。
　ノーアーカイブログモードでの運用を行っている場合は、<手順B> の方法を
　 参照してください。

6. データベースを resetlogs で OPEN します。

　 SQL> alter database open resetlogs;
データベースが変更されました。

7. resetlogs 指定でデータベースを OPEN したので、速やかにコールド・バックアップを
　 取得します。resetlogs で OPEN する前のバックアップのデータファイルを使用して
resetlogs をまたがるメディア・リカバリは実行できません。

8. ローカル管理一時表領域を使用している場合には、後述の
　 [ローカル管理一時表領域が含まれる場合の注意]を参照し、一時ファイルを
　 追加します。
　

以上で作業は完了です。
制御ファイルの多重化していなかった場合には、多重化をしましょう。

------------------------------------------------------------------------
<手順B>:
alter database backup controlfile to trace でのバックアップ 又は
制御ファイルのバックアップが全く存在しない 又は
ノーアーカイブログモードでの運用の場合
------------------------------------------------------------------------

1. インスタンスがまだ起動している場合、データベースを shutdown します。
　 制御ファイルが破損している時には、shutdown abort での停止を行う必要があります。

SQL> shutdown abort;
ORACLE instance shut down.

2. create controlfile 文を作成します。

　・制御ファイルのバックアップをalter database backup controlfile to trace で
　 取得していた場合 --> 2-1 を参照してください。

・制御ファイルのバックアップが全く存在していない場合 --> 2-2 を参照してください

　2-1. alter database backup controlfile to trace で取得していた場合：

user_dump_dest 以下のトレースファイルを元にファイルを編集し、
　　 NORESETLOGS オプションを指定して create controlfile 文のみを
　　 create_cf.sql などとして保存し、制御ファイル作成スクリプトを生成します。

　　　 <例> create_cf.sql として保存した場合
CREATE CONTROLFILE REUSE DATABASE "ORA920" NORESETLOGS ARCHIVELOG
MAXLOGFILES 5　　　　　　　　　　　　　^^^^^^^^^^^ ^^^^^^^^^^
MAXLOGMEMBERS 3 ノーアーカイブログモード時は、NOARCHIVELOG に直します
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 (
'/home/oradata/ora920/redo01_1.log',
'/home/oradata/ora920/redo01_2.log'
) SIZE 100M,
GROUP 2 (
'/home/oradata/ora920/redo02_1.log',
'/home/oradata/ora920/redo02_2.log'
) SIZE 100M,
GROUP 3 (
'/home/oradata/ora920/redo03_1.log',
'/home/oradata/ora920/redo03_2.log'
) SIZE 100M
DATAFILE
'/home/oradata/ora920/system01.dbf',
'/home/oradata/ora920/undotbs01.dbf',
'/home/oradata/ora920/indx01.dbf',
'/home/oradata/ora920/tools01.dbf',
'/home/oradata/ora920/users01.dbf'
CHARACTER SET JA16EUC;

　　　　※これは、アーカイブログモード時、データベースのキャラクタセットが JA16EUC の場合の
　　　　　例です。

　2-2. 制御ファイルのバックアップが全く存在しない場合：

　　 2-1. の create controlfile 文を参考に、create control 文を手動で作成する必要があります。
オンラインREDOログのサイズは、OSコマンドから確認し、指定する必要があります。
　　 存在しているデータファイルやオンラインREDOログの場所を OS 上で確認する必要が
　　 あります。

3. データベースを nomount します。

SQL> startup nomount;
　 ORACLEインスタンスが起動しました。

4. 制御ファイルを再作成するためのスクリプトを実行します。
　
　 SQL> @create_cf.sql
制御ファイルが作成されました。

5. 前の shutdown が abort によるものだったので、リカバリを実行します。

　 SQL> recover database;
　 リカバリが完了しました。

6. データベースを OPEN します。

SQL> alter database open;
データベースが変更されました。

7. ローカル管理一時表領域を使用している場合には、後述の
　 [ローカル管理一時表領域が含まれる場合の注意]を参照し、一時ファイルを
　 追加します。

以上で作業は終了です。
作業終了後、次回の障害に備えて制御ファイルのバックアップを取得しましょう。
また、制御ファイルの多重化していなかった場合には、多重化をしましょう。


[ローカル管理一時表領域が含まれる場合の注意]
制御ファイルをバックアップから戻してリカバリを行う場合、制御ファイルで管理されている
一時ファイルの情報が古い可能性があるため、一時ファイルの情報が削除されます。
このため、制御ファイルのリストア、又は再作成を行なった後には、
一時ファイルを再度追加してください。(詳細は、KROWN#62436 を参照してください。）

<実行例>
SQL> alter tablespace <一時表領域名> add tempfile '<ファイル名>'
　size <ファイルサイズ> reuse;

[参照情報]

「Oracle7 Server 管理者ガイド リリース7.3」p.24-54
「Oracle8 Server バックアップおよびリカバリ リリース 8.0」p.11-50
「Oracle8i バックアップおよびリカバリ・ガイド リリース8.1」p.15-12
「Oracle9i ユーザー管理バックアップおよびリカバリ・ガイド リリース1」p.3-9
「Oracle9i ユーザー管理バックアップおよびリカバリ・ガイド リリース2」p.3-10


キーワード：

CONTROLFILE CONTROL 制御ファイル　破損　全損　V$CONTROLFILE CONTROLFILES

Control file old ORA-1122,ORA-1110,ORA-1207が発生してDBが起動できない

文書番号 49471 最終更新日 2002-08-09
製品名(バージョン)[コンポーネント] Oracle Server - Enterprise Edition (ALL - ALL) [RDBMS]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 　
概要 ORA-1122,ORA-1110,ORA-1207が発生してDBが起動できない
内容:

[質問]
DBのOPEN時に以下のエラーが発生します。

SQL> startup
ORACLE instance started.
Total System Global Area 57483672 bytes
Fixed Size 38980 bytes
Variable Size 42240340 bytes
Database Buffers 13107200 bytes
Redo Buffers 2097152 bytes
Database mounted.
ORA-01122: database file 5 failed verification check
ORA-01110: data file 5: 'D:\ORA817\ORADATA\ORA817\USERS01.DBF'
ORA-01207: file is more recent than control file - old control file

[回答]
原因となるエラーは、ORA-1207 ファイルが制御ファイルより新しくなっています(制御ファイルが古い)　です。
このエラーは、制御ファイルとデータファイルヘッダの持つSCNが一致しないために発生します。
制御ファイルだけを過去のbackupから戻した場合や、マシンクラッシュなどの障害によって
データファイルヘッダの情報と制御ファイルの情報に不整合が生じてしまったようなケースもあります。

このような状態は、ログファイルの適用でリカバリすることができます。
但し、以下のものが必要です。
　-最新の状態のオンラインREDOログ
　-アーカイブログモードの場合は、最新までのアーカイブログすべて
　　(ノーアーカイブログモードでも起動できる可能性がありますので下記をご確認ください)

-----
mountモードで起動後

recover database using backup controlfile;
　このコマンドを実行すると、以下が表示されます。

ORA-00279: 変更: 363383(08/09/02 10:46:35で生成)にはスレッド番号: 1が必要です。
ORA-00289: 検討すべきログ・ファイル: D:\ORA817\ORADATA\ORA817\archive\arch1_335.dbf
ORA-00280: 変更: 363383(スレッド: 1)は順序番号: 335に存在します。
ログを指定してください: {=suggested | filename | AUTO | CANCEL}

　ここでアーカイブログの指定を行います。　
　検討すべきログファイルで問題なければリターンキーを押します。
　別の場所に該当のアーカイブログがある場合は、フルパスでファイル名を指定してリターンキーを押します。

　ログの適用を続けていくと、最新のアーカイブログを適用したにもかかわらず
　まだリカバリ完了のメッセージが出力されない(次のログを要求される)状態になります。
　これは、using backup controlfile句を使用した場合は
　現在のオンラインREDOログの情報がないためで、アーカイブログのsuggestionのみ行われます。
　(using backup controlfile/until cancelを指定していないリカバリでは自動で
　　オンラインREDOを参照し、リカバリが行われます。)
　上記のログ指定プロンプトで、オンラインREDOログ名をフルパスで指定する必要があります。
　
　どのREDOログが必要かをディクショナリ等で確認できませんので
　うまくいかない場合は、別のREDOlogを指定してご確認ください。
　誤ったREDOログの指定をした場合には、以下のエラーが発生しますが
　誤ったREDOログが適用されてしまうようなことはございません。
　
　　ORA-310:アーカイブログは順序番号nnnを含んでいますが、順序番号nnnが必要です。

　再度　recover database using backup controlfile;　を実行して
　正しいREDOログファイル名を指定すれば問題ありません。

　最新の状態までログの適用が完了すれば、以下のメッセージが表示されます。

　ログが適用されました。
　メディア・リカバリが完了しました。
　
上記の対処は基本的にアーカイブログモードの場合にアーカイブログを適用していく手順ですが、
ノーアーカイブログモードの場合でも、リカバリに必要なオンラインREDOログが
まだ上書きされていなければ、オンラインREDOログの適用だけでリカバリできます。

recover database using backup controlfile;
を実行後、ログの指定でオンラインREDOログをフルパスで指定してください。　



　ログが適用されました。
　メディア・リカバリが完了しました。

このメッセージが表示されたら、以下のコマンドを使用してDBをOPENしてください。
alter database open resetlogs;

上記でうまくリカバリができない場合は、制御ファイルの再作成による復旧をご検討ください。

[参考資料]
DSI Advanced Backup, Restore and Recovery Techniques　の資料を一部参照

[Error#]
ORA-1207

Dealwith Oracle Enterprise Manager Database Control (dbconsole) Japanese Font

just download a font from other successfully oracle-installed machine.

cd $ORACLE_HOME/jdk/jre/lib/fonts/

ftp ...
cd $ORACLE_HOME/jdk/jre/lib/fonts/
bin
prompt
mget ALBANWTJ.TTF
quit

emctl stop dbconsole
emctl start dbconsole

expansion controlfile section 19 failed

the control file section 19 is the archive log section.
it caused by too many invalid archive log entries are kept in control file.
to resolve the problem just run the following command with RMAN.

RMAN> delete NOPROMPT expired archivelog all ; 

the following message could be found in alert.log

...
kccrsz: denied expansion of controlfile section 19 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #14147320 Recno 46258 Record timestamp
05/09/07 05:20:02
Object type=245 Object recid=24025 Object timestamp=
04/05/07 12:25:34
kccrsz: denied expansion of controlfile section 19 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #14147321 Recno 46259 Record timestamp
05/09/07 05:20:02
Object type=245 Object recid=24026 Object timestamp=
04/05/07 13:01:33
kccrsz: denied expansion of controlfile section 19 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #14147322 Recno 46260 Record timestamp
05/09/07 05:20:02
Object type=245 Object recid=24027 Object timestamp=
04/05/07 18:42:45
...

kccrsz: denied expansion of controlfile section 19 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #4125758 Recno 41618 Record timestamp

controlfile has two sections. The reusable and the non-reusable sections. The reusable section is used by rman. The non-reusable section should never be overwritten if you provided enough space for the controlfile.

alter system set control_file_record_keep_time=0 scope=spfile;

附metalink上的解释：

Problem Descrīption
-------------------

In the "alert.log", you find the following warning messages:

kccrsz: denied expansion of controlfile section 9 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #520891 Recno 53663 Record timestamp
...
kccrsz: denied expansion of controlfile section 9 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
RECID #520892 Recno 53664 Record timestamp

The database is still running.

The CONTROL_FILE_RECORD_KEEP_TIME init parameter is set to 7.

If you display the records used in the LOG HISTORY section 9 of the controlfile:

SQL> select * from v$controlfile_record_section where type='LOG HISTORY' ;

TYPE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
------------- ------------- ------------ ----------- ---------- ----------
LOG HISTORY 65535 65535 33864 33863 520892

The number of RECORDS_USED has reached the maximum allowed in RECORDS_TOTAL.

Solution Descrīption
--------------------

Set the CONTROL_FILE_RECORD_KEEP_TIME to 0:

* Insert the parameter CONTROL_FILE_RECORD_KEEP_TIME = 0 IN "INIT.ORA"

-OR-

* Set it momentarily if you cannot shut the database down now:

SQL> alter system set control_file_record_keep_time=0;

Explanation
-----------

The default value for

* the CONTROL_FILE_RECORD_KEEP_TIME is 7 days.

SQL> select value from v$parameter
2 where name='control_file_record_keep_time';

VALUE
-----
7

* the MAXLOGHISTORY database parameter has already reached the maximum of
65535 and it cannot be increased anymore.

SQL> alter database backup controlfile to trace;
=> in the trace file, MAXLOGHISTORY is 65535

The MAXLOGHISTORY increases dynamically when the
CONTROL_FILE_RECORD_KEEP_TIME is set to a value different from 0,
but does not exceed 65535. Once reached, the message appears in the
alert.log warning you that a controlfile record is written over.

Remark
~~~~~~
Though, setting control_file_record_keep_time to zero is dangerous for users
making RMAN backups: RMAN users might not be able to restore backups.

References
----------
Note 1057885.6 RDBMS: KCCRSZ, ORA-470, ORA-449, ORA-1092, DENIED EXPANSION
CONTROL FILE

Did this article help solve your problem? Select Yes No Does Not Apply Would you recommend this document to others? Select Yes No Not Sure

TIP: Click help for a detailed explanation of this page.
Bookmark Go to End

Subject: RDBMS: KCCRSZ, ORA-470, ORA-449, ORA-1092, DENIED EXPANSION CONTROL FILE
Doc ID: Note:1057885.6 Type: PROBLEM
Last Revision Date: 13-MAY-2002 Status: PUBLISHED

Problem Descrīption:
====================

While running Oracle 8.0.X you try to bring the database up after a shutdown
and receive the following error messages related to denied expansion of the
control file:

ORA-470: LGWR process terminated with error
Cause: The log writer process terminated abnormally.
Action: Check the accompanying messages, if any, and the background
process trace file.
Correct the problem mentioned in the other messages.
Then shut down and restart the instance.
If the trace file mentions any other background process errors,
check the trace file for the mentioned process until the root
error is found.

ORA-449: background process '' unexpectedly terminated with error ''
Cause: A foreground process needing service from a background process has
discovered the background process died.
Action: Refer to the message code given in the message and the trace file
for the foreground and the background processes.

ORA-1092: ORACLE instance terminated. Disconnection forced.
Cause: The instance connected to was terminated abnormally, probably due to
a SHUTDOWN ABORT.
The current process was forced to disconnect from the instance.
Action: Contact the database administrator to determine when the instance is
restarted.
Attempt to reconnect after the instance is running again.

In your "alert.log" you see the following:

kccrsz: denied expansion of controlfile section ## by ## record(s)
the number of records is already at maximum value (65535)

kccrsz: expanded control file section ## from # to # records
requested to grow by # records added #blocks of records

Solution Descrīption:
=====================

Records in some sections of the control file are circularly reusable while
records in other sections are never reused. The "INIT.ORA" parameter
"CONTROL_FILE_RECORD_KEEP_TIME" applies to reusable sections. It specifies the
minimum age in days that a record must have before it can be reused. This value
defaults to 7 days if not specified in your "INIT.ORA". In the event a new
record needs to be added to a reusable section and the oldest record has not
aged enough, then the record section expands.

The parameter that controls the expansion of this file is specified during
database creation, namely "MAXLOGHISTORY". In Oracle8 versions prior to 8.0.6,
there is a known issue whenever MAXLOGHISTORY = 65535. This issue is recorded
in Bug 636522. You can avoid this issue by stopping the expansion of the
control file by setting CONTROL_FILE_RECORD_KEEP_TIME = 0. If
"CONTROL_FILE_RECORD_KEEP_TIME" is set to 0, then reusable sections never
expand and records are reused as needed.

Explanation:
============

In Oracle versions prior to 8.0.6, there was a problem associated with
controlfile expansion. If MAXLOGHISTORY is set to 65535 (64K) during database
creation (this is the default value), then when log sequence number reaches
65535, LGWR dies. This problem is now fixed in 8.0.6.

If a patch for Bug 636522 is available, you should look into the feasibility
of applying to your database instance or upgrade to a release of Oracle 8.0.6
or higher. If this is not an option, check the "MAXLOGHISTORY" value. This
value can be retrieved by issuing the command "alter database backup
controlfile to trace" and examining the resulting trace file in your
"USER_DUMP_DEST" directory. If it is set to 65535 then you may want to consider
setting it to a lower value. Changing the "MAXLOGHISTORY" requires recreating
control file. Aftwards, you should set the parameter
"CONTROL_FILE_RECORD_KEEP_TIME" to 0 in your "INIT.ORA" and restart the
database. You can also use "ALTER SYSTEM" to change the parameter's value to an
one time only basis.

References:
===========

Bug 636522

Search Words:
=============

CONTROL FILE KCCRSZ ORA-470 ORA-449 ORA-1092