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<mailto: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<mailto: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<mailto: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
