Re: DBFS and periodic reorganization

Hi

I have had similar problems in ACFS such as:

2020-04-01 14:39:43 ERROR OGG-01184 Oracle GoldenGate Capture for Oracle, e03x.prm: Expected 4 bytes, but got 0 bytes, in trail ./dirdat/BB055227, seqno 55227, reading record trailer token at RBA 99946661.

When the server crashes. We were hoping DBFS would avoid similar issues but so far DBFS does not seem a mature product or perhaps it is but not improved continuously.

We will move to ACFS most probably and replicate the ACFS disk with Storage.

Thanks

On Wed, Nov 11, 2020 at 8:24 AM Shane Borden <sborden76_at_yahoo.com> wrote:

> This blog talks about it. Just search for DBFS.
>
> https://mdinh.wordpress.com/?s=Dbfs+&submit=Search
>
> If you want to replicate trails, consider ACFS snapshot replication. Might
> have a lag, but OGG can certainly rebuild trails in most cases within a
> reasonable time frame.
>
> May also consider running the extract on the data guard standby and just
> periodically delete trails and replicate nothing.
>
> Shane Borden
> sborden76_at_yahoo.com
> Sent from my iPhone
>
> On Nov 11, 2020, at 1:43 AM, Ls Cheng <exriscer_at_gmail.com> wrote:
>
> 
> Hi
>
> Does anyone use DBFS and observe that periodic reorganization is required?
> We are deciding which filesystem to use to store the goldengate trails, we
> are deciding between ACFS and DBFS.
>
> DBFS was being considered because we need to replicate the trails to a
> disaster recovery site, since DBFS is part of the database it seemed
> suitable. But if DBFS needs periodic reorganization then it is definitely a
> NO candidate because the reorganization needs twice space, another
> tablespace etc. Not a simple task.
>
> Any experiences with DBFS and periodic reorganization?
>
> BR
>
>

--
http://www.freelists.org/webpage/oracle-l