Is there a way to use purgeLogs perl script to handle these directories?
https://support.oracle.com/epmos/faces/DocContentDisplay?id=2081655.1
Em qua., 10 de jun. de 2020 às 06:25, Grønlien, Jan <
jan.gronlien@xxxxxxxxxxxxxxxx> escreveu:
Reported the very same issue, and the solution text is copy/paste of the
textx below.
The files are still created with 18.9
Scheduled a cron job, to remove these files until we are on 19.1
/Jan
*Fra:* oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> *På
vegne av* Chris Taylor
*Sendt:* tirsdag 9. juni 2020 22.01
*Til:* anthony Sanchez <anthonycsanchez@xxxxxxxxx>
*Kopi:* ORACLE-L <oracle-l@xxxxxxxxxxxxx>
*Emne:* Re: acfs.archive folders on Exadata and/or RAC ?
Noice!
No reply on my SR yet - and its a Sev 2. What category did you put that
under?
I put my in as a technical SR and went through all the Q&A bits and I got
the automated reply to please upload a TFA collection :/ And it's been
sitting there since.
Chris
On Tue, Jun 9, 2020 at 2:34 PM anthony Sanchez <anthonycsanchez@xxxxxxxxx>
wrote:
Hello Chris,
I happened to be in MOS and opened an SR to ask about those acfs archive
files. I got a quick response for a sev 3!
*************************
Hello,
The issue is due to a known bug.
BUG 27109757 - ON STACK STOP WE SHOULD NOT CREATE AN ACFS.ARCHIVE
DIRECTORY
Due to this bug every time stack stops we create and acfs.archive
directory with the contents of the current acfs directory.
Development has mentioned this bug will be fixed in Product Version 19.1
You can go ahead and delete the old files.
*************************
Anthony
On Tue, Jun 9, 2020 at 8:58 AM anthony Sanchez <anthonycsanchez@xxxxxxxxx>
wrote:
Hi Chris,
i am ExaCC (gen 1) as well and have had the same exact problem. I have
deleted those archive files without issue. I do not know their exact
purpose, but when I saw the really old dates I decided to give it a shot by
starting with the oldest. After no adverse effects I started deleting more
of them.
I heard that /u01 can be resized via a SR, but I have not tried that yet.
thanks,
Anthony
On Tue, Jun 9, 2020 at 8:18 AM Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> wrote:
So we're on Exadata Cloud at Customer and we find out that /u01 is not
resizeable.
Not only that, it's mostly a manual process to cleanup files.
In /u01 on Exadata C@C we have these two large directories that are
growing.
Overview:
Size:
/dev/mapper/VGExaDb-LVDbOra1 20G 15G 4.1G 79% / u01
Usage:
:/u01/app/grid
-------------------/diag (5.8G)
-------------------/crsdata (5.6G)
Under crsdata/<node name> we have a several of these acfs.archive
folders. Most of which are old.
Does anyone know what these acfs.archive folders are ? And can they be
safely removed if they are not in use?
MB Directory
----- -------------------------------------
1385 ./acfs.archive.200407002506
1083 ./acfs
994 ./acfs.archive.190219203711
987 ./acfs.archive.190624215336
741 ./acfs.archive.181111214215
126 ./acfs.archive.181116165415
108 ./acfs.archive.190626101824
...
...
Some of these have really old dates:
drwxrwxr-x 2 grid oinstall 4096 Oct 17 2018 acfs.archive.181017203630
drwxrwxr-x 2 grid oinstall 4096 Oct 17 2018 acfs.archive.181017223228
drwxrwxr-x 2 grid oinstall 4096 Oct 17 2018 acfs.archive.181017223727
drwxrwxr-x 2 grid oinstall 4096 Oct 17 2018 acfs.archive.181019232838
drwxrwxr-x 2 grid oinstall 4096 Nov 10 2018 acfs.archive.181111214215
drwxrwxr-x 2 grid oinstall 4096 Nov 11 2018 acfs.archive.181111220837
drwxrwxr-x 2 grid oinstall 4096 Nov 15 2018 acfs.archive.181116165415
drwxrwxr-x 2 grid oinstall 4096 Nov 16 2018 acfs.archive.181116172616
drwxrwxr-x 2 grid oinstall 4096 Feb 19 2019 acfs.archive.190219154236
drwxrwxr-x 2 grid oinstall 4096 Feb 19 2019 acfs.archive.190219160403
drwxrwxr-x 2 grid oinstall 4096 Jan 16 2019 acfs.archive.190219203711
drwxrwxr-x 2 grid oinstall 4096 Mar 13 2019 acfs.archive.190624215336
drwxrwxr-x 2 grid oinstall 4096 Jun 25 2019 acfs.archive.190626101824
drwxrwxr-x 2 grid oinstall 4096 Jun 6 22:39 acfs.archive.200407002506