Thanks for the information. I was thinking about replicating the FS more
for demo purposes than actual work. As you noted, there are probably
better methods of replicating a file system that dont require an Oracle
On Tue, Mar 24, 2020 at 3:09 PM Andy Wattenhofer <watt0012@xxxxxxx> wrote:
On Tue, Mar 24, 2020 at 12:55 PM Andrew Kerber <andrew.kerber@xxxxxxxxx>
First, all the examples for setting up DBFS talk about setting it up in
its own database. Is it mandatory to configure it in a single use database?
Or is there some advantage to doing that? I suppose one would be so you
dont have to shut it down every time you start your other database, but are
there other reasons?
If you're planning on mounting the DBFS file store as a filesystem on the
database server, I think you'll want a separate database. You'll be setting
up a cluster resource for the dbfs mount and it will have start- and stop
dependencies. You don't want "crsctl stop resource dbfs_mount" to stop the
DBFS database if it is also hosting things other than the DBFS mount.
If you're just planning on accessing the store via remote dbfs_clients, I
don't think you'll have that problem. It's effectively the same thing as
having database users connecting to a database and reading and writing
Overall I don't think it is mandatory to have a separate database just for
DBFS. All of the DBFS functionality is isolated via tablespaces and quotas,
DBFS file stores, and users and service accounts with specific permissions,
so there is the ability to fully segregate it from other activity in the
I saw an article referencing something called and Oracle File System
(OFS). I cant find reference to that except in one place. Can someone
point me to documentation on that if it exists.
Isn't that just the service that exports the DBFS filesystem for mounting
via NFS? 12.2 doc here:
Finally, I plan to put the DBFS system in dataguard. I dont see any
reason why I couldnt, just copy the OS configuration and otherwise set up
standard dataguard. Is there any reason why I coudn't do that?
Assuming you don't intend to mount the DBFS filesystem on the standby site
unless the standby database is switched over to primary mode, I don't see
why that wouldn't work. But any remote clients that are using the service
would need to switch to the standby hostname in the event of a failover or
You could also run a standalone DBFS setup at your standby site and rsync
between the primary site and it. That is the strategy I chose when I was
working with DBFS. The benefit is that you don't need to worry about
service dependencies between sites, because they're independent between the
sites. And you have a little more flexibility in storing files that are
unique to the standby site in there.