In the past I've used Oracle with OCFS (Oracle Cluster File System) on a shared disk on a SAN.
In my experience it was always slow because of the safeties it requires for multiple instances using a shared disk. So its no surprise the performance on NFS wouldn't be great
That said under the hood whenever possible it loads whole files into RAM to extract data however it does misplace writes. So it may not perform as well on writes as you may hope, but neither will NFS.
The reason why Oracle has started supporting NFS is really to try to compete in the cloud market not because its a good idea.
In general distributed Databases using shared disk is a bad idea and should be avoided if possible.
That said consider talking to the people at EnterpriseDB they may have a better compatible alternative for you because the optimize the PostgreSQL stack to work in the cloud and provide a Oracle client compatibility layer.
In addition they can easily configure their version of PostgreSQL to do more efficient Hot spare (read write on the primary and read-only on the backup) replication via the databases journal which will be far more efficient as far as speed and your network utilization.
-- Sent from my HP Pre3
On Oct 7, 2013 18:26, Dan Mons <[email protected]> wrote:
What sort of read/write patterns are these global transaction logs?
I've found GlusterFS excels at use cases were you need to read or
write entire files at a time, and in great volume from many sources.
We use it as storage for our production users who read and write a lot
of large media files (mostly from our render farm, which can push a
lot of data around very quickly), and it works brilliantly.
However, we did attempt to run applications off it (as we were running
applications off an NFS share previously), and host our Linux user
home drives from it, and both of these cases didn't quite work out for
us. GlusterFS appears to not like reading portions of a file at a
time (say, when you load a binary or library, and Linux only requires
a small part of that file read). We ended up going back to NFS for
home and apps, but keeping GlusterFS where it excelled - for large
volume file writes and reads of entire files.
-Dan
On 8 October 2013 00:27, Dan Hawker <[email protected]> wrote:
>
> Hi All,
>
> We have a requirement for a common replicated filesystem between our two
> datacentres, mostly for DR and patching purposes when running Weblogic
> clusters.
>
> For those that are not acquainted, Weblogic has a persistent store that it
> uses for global transaction logs amongst other things. This store can be
> hosted on shared disk (usually NFS), or in recent versions within an Oracle
> DB. Unfortunately, some of the products that we use, have to use the disk
> option.
>
> Ordinarily I'd just follow Oracle's guidelines and use an Enterprise NAS
> head and NFS, however the NAS head we have at my present role, has rather
> lacklustre replication granularity (every 5mins), which just won't cut it,
> so we're looking at alternatives, including throwing more cash at the
> storage vendor.
>
> The Linux team here use GlusterFS to host and replicate their Puppet
> infrastructure between the datacentres. They like and understand it, and say
> it's got good performance, so we were wondering if we could also leverage
> Gluster for the persistent data stores that can't be DB hosted.
>
> Wondered if anyone has tried this kind of thing with Weblogic or any other
> JEE app server before, and if it is feasible. We'll obviously test this
> extensively, but before we do spend time and resource, we're just after some
> degree of confidence that it may work at all.
>
> Thanks
>
> Dan
>
> --
> Dan Hawker
> --
>
> _______________________________________________
> Gluster-users mailing list
> [email protected]
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
--
Dan Mons
R&D SysAdmin
Cutting Edge
http://cuttingedge.com.au
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
