missing sequnece number in Archived log files

[samdba]

Hi guys,

How come I see the missing sequence numbers in Archive log file names.

There are files as follows.

ARC0001.LOG
ARC0002.LOG
ARC0500.LOG
ARC0501.LOG

Pl. tell how could this have happened and also how can I correct it to start it from 1 again?

Thanks,

[newbie]

Hi there,
You can try to query v$archived_log to determine the locations of your missing logs and its first change/next change number. If you have accidently removed one of your archived files then its best to perform full database backup of your database right away. To reset the sequence you have to shutdown and open the db with resetlog option. Hope this helps

[mkumarnk]

U will get all the archive log inforamtion from v$archived_log since startup.Check about the format also(log_archive_format in init.ora).If u found any discripancy b/w files available in the archive directry and the sequence available in v$archived_log there is a possibility of loss of file or it must have copied to some other directry(manually).

Manoj

[samdba]

Hi,

Following is from v$archived_log. I remember that I had switched to NOARCHIVELOG in the middle of 11i upgrade and then switched back to ARCHIVELOG. Could it have happened due to that?

Now, as I understand I have to open the database in the RESETLOG mode. Will it reset it to 1?

M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00001.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00002.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00003.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00004.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00005.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00006.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00007.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00008.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00009.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00010.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00513.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00514.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00515.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00516.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00517.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00518.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00519.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00520.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00521.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00522.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00523.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00524.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00525.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00526.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00527.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00528.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00529.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00530.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00531.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00532.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00533.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00534.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00535.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00536.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00537.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00538.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00539.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00540.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00541.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00542.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00543.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00544.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00545.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00546.001
M:\OA\PRODDB\8.1.7\DATABASE\ARCHIVE\ARC00547.001

Thanks,

Samir.

[vastdba]

Hi,

I would like to add to this good discussion.

If the database is running in NOARCHIVELOG mode and the archives which are generated and subsequently changed to ARCHIVE LOG MODE then the previous logs were not to be considered.

Alternative is to take BACKUP.

Then generate the logs here afterwards and these logs will be considered in future RECOVERY PROCESS.

ok.

As the problem stands will these new archs will be missed out then, it could be retrieved from the backup scenario and at the time of recovery it will take it in sequential order.

otherwise,

If the said archs were released and utilised then they good for nothing.

At the operating system levels the path plays major role.

For example if it is in main server residing database then the same copy in application server is extracting then the path must be maintained.
It is very much taken into consideration. Otherwise it won't consider its path and subsequently will pave way for the NO-EXISTENT or else as you have faced the MISSING ARCHIVES location.

Hope it will give good understanding in your present imbroglio.

VAST

[pando]

sequence number == log sequence number

so if you have switched to noarchive log then it´s normal you seegaps

if you reset log the sequence number is reset to 1

[samdba]

Hi,

great help so far.

Does it mean that this gap is really not to worry about?

And, now if I want my ARCH logs to start from 1, do I have to open the database with resetlogs option? Here, What should I do in the RMAN catalog if I open it with resetlogs option?

Thanks,

[gandolf989]

I'm not sure why you want to change the sequence number to 1. You turned off archivelog, did a few log switches and turned in back on, and there is a gap in the sequences. I don't see a problem. As long as you have a good full backup from right after you enabled archivelog the last time you should be fine. If you need something to do then you should do a test restore of that backup on another system and roll the changes forward to the current log. I would hae for you to be one of those people trying to do a restore without a backup.

Just my opinion.