Re: acfs.archive folders on Exadata and/or RAC ?

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Tue, 9 Jun 2020 16:00:40 -0400
Message-ID: <CAP79kiQAKDdcoBEeGppOX+QhX6z6fQ7KTqoZZCgGb88pyZsc-g_at_mail.gmail.com>



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_at_gmail.com> 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_at_gmail.com>
> 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_at_gmail.com> 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_at_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
>>>
>>>
>>>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 09 2020 - 22:00:40 CEST

Original text of this message