Home » RDBMS Server » Server Administration » FRA & DIAG (CM merged 2) (Oracle 18c)
|
|
|
|
|
|
|
|
|
Re: FRA & DIAG (CM merged 2) [message #676275 is a reply to message #676267] |
Fri, 24 May 2019 07:55  |
 |
EdStevens
Messages: 1376 Registered: September 2013
|
Senior Member |
|
|
XChris wrote on Fri, 24 May 2019 01:18damned.
can you fix that?
Or is it best to export, rebuild and import the database?
Whoa, slow down there, Buckaroo! Would you tear your house down and rebuild it just because you parked your car on the lawn?
Just have your daily rman backup job (you do have a daily rman backup job, right?) include a backup of the archivelogs with the 'delete all input' option. You should be doing this anyway. All archivelogs will be backed up, regardless of where they are located and regardless of whether or not they were created under FRA control. That means that those that were created "in" the FRA but not under FRA management will be backed up and then deleted, thus freeing up the space they were taking - space they were taking without the FRA being aware of it. If a given archivelog was properly created under FRA management, then when rman backs it up and deletes it, the FRA management system will know about it and adjust its record keeping accordingly. "Problem" solved, no extra action being taken.
And here's a little extra information about backups and archivelogs, at no extra charge:
Whenever an archivelog is written, a record of that is written to the db control file. And that record of the archivelog contains the fully qualified name - the full directory path to the file, along with the file name. It is this record in the control file that rman uses to locate archivelogs during a recovery operation. Thus, if you were to manually (using os commands, outside of oracle) delete or move these files, they would no longer be where oracle thinks they are.
|
|
|
Goto Forum:
Current Time: Sun May 04 16:02:30 CDT 2025
|