On Jul 31, 2014, at 09:36 AM, "Wilson, Jonathan" <piercing_male@xxxxxxxxxxx> wrote:
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....
The only think more dangerous than a Programmer who thinks he is a DBA is a DBA who thinks he is a programmer. :)
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" ;-)
Part of that is historical. DB2 was developed on a Mainframe, which is in many ways, a superset of the "i". You didn't have many instances of programmers bringing a system down by some stupid design action, because you had design reviews and test systems and configuration management departments and a whole bunch of procedures needed to get software into production. Test systems were also managed by SYSADMs, DBAs, Programming Managers, etc. ;)
DB2 can be run very easily in most shops by a part time DBA, exactly the same as in most, or at least a large number of "i" shops. That's true even in relatively large shops, though not in very large shops with 10's of thousands of interactive users, or many millions of transactions per day. DB2 also lends itself well to being embedded - such as in Tivoli products.
The "i" is a shining example of a good implementation of DB2, again in my opinion. There are other such examples though. :)
-Paul
midrange.com
