1

I recently spotted 3 very old archivelog directories on disk that do not appear within RMAN.

[oracle@ORACLE01 archivelog]$ du -sh *
122M    2017_02_25
4.9G    2017_02_26
2.5G    2017_02_27
1.6G    2017_06_28
474M    2017_06_29

Within RMAN, archivelogs appear from the 28th June (as I would expect)

RMAN> list archivelog all;  (list truncated for brevity)
using target database control file instead of recovery catalog
List of Archived Log Copies for database with db_unique_name R2CI
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
30329   1    81000   A 28/06/2017 10:45:26
        Name: /u01/.../archivelog/2017_06_28/o1_mf_1_81000_do72c0ng_.arc

30330   1    81001   A 28/06/2017 10:48:00
        Name: /u01/.../archivelog/2017_06_28/o1_mf_1_81001_do73f110_.arc

If I run a crosscheck archivelog all, this picks up only the recent archivelog files that I expect to be there:

RMAN> crosscheck archivelog all;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
validation succeeded for archived log
archived log file name=/u01/.../archivelog/2017_06_28/o1_mf_1_81000_do72c0ng_.arc RECID=30329 STAMP=947846881
validation succeeded for archived log
archived log file name=/u01/.../archivelog/2017_06_28/o1_mf_1_81001_do73f110_.arc RECID=30330 STAMP=947847970
validation succeeded for archived log
archived log file name=/u01/.../archivelog/2017_06_28/o1_mf_1_81002_do74pzcw_.arc RECID=30331 STAMP=947849313
validation succeeded for archived log
(list truncated for brevity)

A "list archivelog all" after this point does not show these old files.

Questions:

  1. Where are these files likely to have have come/why weren't they eventually expired and deleted like the rest of the archivelogs?

  2. Why does crosscheck archivelog all not detect them and add them back? is it because there is a 4 month gap between them and the next most recent files?

  3. Is it safe to just delete these files off disk?

Thanks

Improve this question
9
  • What's your backup retention policy? as well as what value the control_file_record_keep_time parameter is set to? – JSapkota Jun 29 '17 at 4:05
  • Did you check this post? dba.stackexchange.com/questions/171008/… – JSapkota Jun 29 '17 at 4:38
  • @JSapkota - control_file_record_keep_time is currently set to 7, and retention policy is 'recovery window of 3 days'. No - I hadn't read that post as it didn't look relevant from the question title - reading it now thanks. – Dave Smylie Jun 29 '17 at 4:41
  • Do you have a full backup on disk of that time period which requires these archived logs? – JSapkota Jun 29 '17 at 4:43
  • no - oldest backup is from the 19th June. (archivelogs are from february). I see from your comment on that other post that the control_file_record_keep_time value is too small. I will increase this to (3 + 7 + 1) = 11 days – Dave Smylie Jun 29 '17 at 4:47
2

Why does crosscheck archivelog all not detect them and add them back?

Because that's not what crosscheck does. Crosscheck reads the records of the archlogs that are recorded in the repository - the ones that rman reports. It reads a record from the repository, then checks to see if that file exists. If not, the record is marked 'expired'. If rman shows no sign of knowing of these files, I'd say it's safe to delete them.

Improve this answer
1

Where are these files likely to have have come/why weren't they eventually expired and deleted like the rest of the archivelogs?

I would suspect that these files vanished from your repo because the following conditions were met: The files where not needed anymore to meet your recovery policy (rman policy) and they also exceeded the parameter controlfile_record_keep_time. At this point Oracle would overwrite the records in your controlfile. If you backup and delete archivelogs on daily terms, you should not have any "dead" archivelogs.

EdStevens already answered the other two questions...

Improve this answer
1
  • 2
    ahhh. Yeah I do backup and delete daily, but conceivably there could have been a lapse for a few days when the control_file_record_keep_time parameter was set too low of a value. (increased now). Thanks! – Dave Smylie Jul 5 '17 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.