Home » RDBMS Server » Server Administration » FRA & DIAG (CM merged 2) (Oracle 18c)
FRA & DIAG (CM merged 2) [message #676208] Tue, 21 May 2019 01:56 Go to next message
XChris
Messages: 4
Registered: May 2019
Junior Member
Hello,

I put on a 18c. The DB is in operation. Now I have to change the following: In the FRA should also DIAG directory. Likewise the ARCHIVE LOG directory. This is so far outside. (Do not ask why ...)
My question:
If I put the directories into the FRA with ALTER SYSTEM, will the FRA then manage them? If e.g. If the FRA becomes too full, then e.g. saved logs automatically deleted?

best regards,
Chris
Re: FRA & DIAG (CM merged 2) [message #676218 is a reply to message #676208] Tue, 21 May 2019 06:37 Go to previous messageGo to next message
EdStevens
Messages: 1132
Registered: September 2013
Senior Member
XChris wrote on Tue, 21 May 2019 01:56
Hello,

I put on a 18c. The DB is in operation. Now I have to change the following: In the FRA should also DIAG directory. Likewise the ARCHIVE LOG directory. This is so far outside. (Do not ask why ...)
My question:
If I put the directories into the FRA with ALTER SYSTEM, will the FRA then manage them? If e.g. If the FRA becomes too full, then e.g. saved logs automatically deleted?

best regards,
Chris
I know you said not to ask why, but 'why' is crucial. So I'll start by asking 'why' we aren't supposed to ask "why".

Then I'll ask why you want the DIAG directory to be in the FRA. I don't believe this can be done. The FRA exists for some very specific uses, and to my knowledge, the DIAG directory structure isn't one of them.

Re: FRA & DIAG (CM merged 2) [message #676228 is a reply to message #676208] Tue, 21 May 2019 12:43 Go to previous messageGo to next message
John Watson
Messages: 8046
Registered: January 2010
Location: Global Village
Senior Member
XChris wrote on Tue, 21 May 2019 07:56
Hello,

I put on a 18c. The DB is in operation. Now I have to change the following: In the FRA should also DIAG directory. Likewise the ARCHIVE LOG directory. This is so far outside. (Do not ask why ...)
My question:
If I put the directories into the FRA with ALTER SYSTEM, will the FRA then manage them? If e.g. If the FRA becomes too full, then e.g. saved logs automatically deleted?

best regards,
Chris
You can certainly direct your archive logfiles and diagnostic_dest to the same directory that you are using for the FRA, but they will not be in the FRA. Just sharing the same directory.
Re: FRA & DIAG (CM merged 2) [message #676235 is a reply to message #676228] Wed, 22 May 2019 07:29 Go to previous messageGo to next message
EdStevens
Messages: 1132
Registered: September 2013
Senior Member
John Watson wrote on Tue, 21 May 2019 12:43
You can certainly direct your archive logfiles and diagnostic_dest to the same directory that you are using for the FRA, but they will not be in the FRA. Just sharing the same directory.
And thus consume space that the FRA thinks is available for its uses.

For the OP: The FRA is just a bookkeeping mechanism. It does not reserve actual space, it does not protect space from other uses, and if files that ARE under FRA management are deleted outside of FRA methods, it will not know that the space has been released.
Re: FRA & DIAG (CM merged 2) [message #676259 is a reply to message #676235] Thu, 23 May 2019 06:41 Go to previous messageGo to next message
XChris
Messages: 4
Registered: May 2019
Junior Member
I've thought about it. The DIAG directory should not be in the FRA. That's useless. Let's just take care of the archivelogs.

But the archivlogs should be in the FRA. Now I have done this:


ALTER SYSTEM SET log_archive_dest_1 = 'LOCATION = /oradata/CATPD1/archive';

SQL> alter system switch logfile;

System wurde geandert.

SQL>


SQL> archive log list
Database log mode Archive mode
Automatic Archiving Activated
Archiving target / oradata / fra / CATPD1 / archive
Oldest online log sequence 131
Next to be archived log sequence 133
Current log sequence 133
SQL>

SQL> set linesize 200
SQL> select * from v $ recovery_area_usage;


FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID
----------------------- ------------------ --------- ---------------- --------------- ----------
CONTROL FILE, 1 0 1 0
REDO LOG 0 0 0 0
[color=orangered]ARCHIVED LOG 0 0 0 0[/color]
BACKUP PIECE 0 0 0 0
IMAGE COPY 0 0 0 0
FLASHBACK LOG 0 0 0 0
FOREIGN ARCHIVED LOG 0 0 0 0
AUXILIARY DATAFILE COPY 0 0 0 0

8 lines selected.

SQL> SQL>


As you can see, the FRA does not care about the logs. What else do I have to do?
Re: FRA & DIAG (CM merged 2) [message #676261 is a reply to message #676259] Thu, 23 May 2019 06:47 Go to previous messageGo to next message
John Watson
Messages: 8046
Registered: January 2010
Location: Global Village
Senior Member
If you want your archive logfiles to be managed by the FRA, not just sitting in the same directory, you need to set

log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST'

or just not set it at all.
Re: FRA & DIAG (CM merged 2) [message #676262 is a reply to message #676261] Thu, 23 May 2019 06:56 Go to previous messageGo to next message
XChris
Messages: 4
Registered: May 2019
Junior Member
Thanks!
Re: FRA & DIAG (CM merged 2) [message #676264 is a reply to message #676262] Thu, 23 May 2019 10:07 Go to previous messageGo to next message
EdStevens
Messages: 1132
Registered: September 2013
Senior Member
XChris wrote on Thu, 23 May 2019 06:56
Thanks!
In addition to what John told you, please refer back to my previous post.
Those archivelogs that were written to the FRA directory, but without FRA management, are consuming space that the FRA thinks is free.
Re: FRA & DIAG (CM merged 2) [message #676267 is a reply to message #676264] Fri, 24 May 2019 01:18 Go to previous messageGo to next message
XChris
Messages: 4
Registered: May 2019
Junior Member
damned.

can you fix that?

Or is it best to export, rebuild and import the database?
Re: FRA & DIAG (CM merged 2) [message #676275 is a reply to message #676267] Fri, 24 May 2019 07:55 Go to previous message
EdStevens
Messages: 1132
Registered: September 2013
Senior Member
XChris wrote on Fri, 24 May 2019 01:18
damned.

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.
Previous Topic: Partitioning
Next Topic: Setting db_keep_cache_size
Goto Forum:
  


Current Time: Mon Nov 11 23:40:06 CST 2019