SEO

Recently read an article by Felix Lee: Setting up DB2 for UNIX and
Linux on NFS mounted file systems ( http://tinyurl.com/yuxbk3 ).

I was wondering why would anyone want to setup things like this. About
6 months beck, in my previous engagement, the system architect asked
if this was possible. I told him offhand that it is and that I 'll
confirm from IBM. Had opened a PMR with IBM regarding the same and the
techrep replied the same thing as Felix notes. That it is possible,
but has its open issues and performance problems. After hearing this,
the architect abandoned the idea.

I think the reason why the architect asked the question in the first
place was that he wanted to have a standard operating environment for
applications and for databases that meant working with only one (or
worst case two) code base (version). Well, there were so many versions
in the company (from v7.1 to v8.2 FP14) because there were so many
different packaged applications with their own requirements. Even
generic 3-tier webapps sometimes had their specific environment
requirements. It is almost impossible to always have one version (and
one code base) for all applications. Sure it creates a nightmare for
the DBA to manage all that, but we take the reasons behind it with a
grain of salt and live with it.

One other reason he was so excited with NFS mounted code base was
because, apparently the then Oracle DBA had informed him that its
seamless and without-problems in Oracle. Don't know how right he was.

Cheers
~sanjuro

Sanjuro wrote:

> Recently read an article by Felix Lee: Setting up DB2 for UNIX and
> Linux on NFS mounted file systems ( http://tinyurl.com/yuxbk3 ).
>
> I was wondering why would anyone want to setup things like this. About

To have central control over your code base. The downsides are:
* you're using NFS. I don't care if it's DB2 or Oracle running, NFS does
not have the same stability requirements as mission-critical database
software.
* you're using NFS. All your program code must go through a small pipe
(ethernet) instead of a big pipe (SATA or SCSI).
* you're using a central hard disk. All your machines must fetch their
program data from the same physical media, and thus compete with each other
both on the hard disk access times and the small pipe(s) coming from the
NFS server
* you're using a central hard disk. Single point of failure and all that
(ok, now you have failovers for your NFS server, in addition to your
database servers, and I'm not sure how good NFS clients are at following a
failover cleanly).
* fixpack upgrade and db2iupdt are on different machines. This usually
means longer downtimes during fixpack upgrade and harder to figure out if
you've stopped all instances on all machines prior to starting the fixpack.

As you may be able to tell, I'm not convinced there is a business case for
this ;-) The cost in downtime and DBA duties far outweigh the cost of
extra disk space, so there needs to be more reasons than this to justify
it.

Note that clients are different. Having a central client makes much more
sense - you still need to ensure all client applications are stopped, but
that's easier to do overnight or over a weekend, and the dataloss if they
aren't stopped usually isn't going to be of a critical nature (i.e.,
unfinished transactions only on that client).

> One other reason he was so excited with NFS mounted code base was
> because, apparently the then Oracle DBA had informed him that its
> seamless and without-problems in Oracle. Don't know how right he was.

That'd be interesting to find out. I'm not sure they're being completely
honest with you, or, if they are, if they've tried as many corner cases as
Felix Lee and his fellow developers did.