On Thu, 2014-07-31 at 07:58 -0500, Paul Raulerson wrote:
I have to say, you do not see teams of nervously sweating DB Admins sitting around worrying about DB2 performance, like you do in every Oracle shop I have ever been in. There has to be a reason for that, and it usually revolves around DB2 doing whatever job it is tasked with reliably, quickly, and without getting in the user's way. Even if that job is emulating a file system or file system access method, as it does on "i".
I think that's because you have teams of nervously sweating programmers
sitting around doing the jobs of DBA's.
The above only half joking....
There is one serious difference between the "i" and other
databases/software set ups and that is the programmers usually sit in
both camps. On other systems, to varying degrees, the software is
usually written in isolation to the database but on the "i" any changes
to a program usually involve at the very least a cursory glance to the
db to see if an index exists if the program requires a new sequence of
access or some convoluted selection criteria.
Admittedly this dual camp system is a hangover from the old days of
record access file set ups, but it still exists even where other
applications may reside on say a PC using ODBC on sites that also have
"on box" software.
I can't speak for set ups using the "i" as a pure DB server, but I would
have thought that in such environments there would indeed be a group of
DBA's sweating profusely over the fact some young whippersnapper
programmer has brought production to its knees by doing a 30 file join
using a never before used sequence with a selection criteria that omits
half the records evenly interspersed in the master stock file who when
asked "why?" responds with the answer "well it worked really quickly
when I tested it with my local sql set up" ;-)
As an Amazon Associate we earn from qualifying purchases.