Couple of thoughts - not all to Joe's or Rob's points. The thought that
Db2 for i5/OS does not need a DBA because a lot of the systems are using
a 1980's designed is not necessarily with merit. Granted a number of
systems may use some older fashioned designs. However, a 'modern' i5/OS
data base does not require a DBA. Nor does another DB. I find this
argument rather interesting because a lot of it depends on the company
and its style. Having said that I would say that DB2 for i5/OS
regularly requires less care and feeding than any other data base on the
market. Accept it or don't - I put much more merit on the OS than I do
the potential antiquidated design of the data base.
I'm not an expert in the areas of Oracle of SQL Server but have found
that while these data bases are relatively programmer friendly they are
generally speaking lacking in a lot of automated management functions.
As well as less standards driven - which can actually be rephrased as
PROPRIETARY. I've worked on certification in both of these and for the
time being have decided that the extra pay one might get as an Oracle
DBA isn't worth taking the steps back.
You won't hear it publicly but if you talk to the right person with SAP
knowledge an Oracle or SQL Server skilled BASIS person can easily work
with DB2 for i5/OS. Because they have less vendor specific data base
work to do. Same product, same data base architecture (whether that is
1980's or modern depends on your definition) - the data base and the OS
is the difference. The same goes for Kronos and some other
applications. Now you can't get them to admit it publicly because these
veondors are also in the market to provide services......
Sorry for the digression. Couple of thoughts on some other points made.
One, I'm not so sure that moving specific i5/OS data bases forward or
incorporating modern technology will actually require that much effort.
So, the thought that if it's simple and doesn't take a lot of time - why
not do it for certain protection points? Two, you do have do look at
the contrary - if it takes say 40 man hours per year but it saves you 20
man hours per year when issues arise - is it really worth it?
Unfortunately, I've lost many arguments where we will expend potentially
more hours than we will most likely save in event of a problem. But I
don't feel that is the case with a lot of the data base functions that
we are talking about. I think most of them don't require a lot of
effort or are difficult to implement.
I manage all things storage related on my systems - approximately 8TB of
data that is used for all sorts of things - 1980's database designs,
modern data base designs, Domino data, IPCS storage, stream file
support, etc. That accounts to a very small mount of an FTE for normal
duties. And it's not because I'm some great wizard. It comes supplied
that way via i5/OS. This year that amount of time will increase because
I believe we are not offering world class performance reporting and
management. Not that the tools aren't there - we just have not taken
advantage of them. Couple what comes with i5/OS and only one ISV
product (Centerfield HomeRun is my ace in the hole and worth the
shameless plug) I think we can make great strides in updating the DB,
improving performance, and improving performance monitoring/reporting
without a huge hit in man hours.
Michael Crump
Manager, Computing Services
Saint-Gobain Containers, Inc.
1509 S. Macedonia Ave.
Muncie, IN 47302
765.741.7696
765.741.7012 f
This email and its attachments may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views
or opinions expressed are solely those of the author and do not
necessarily represent those of Saint-Gobain. <redaction>. If you are
not the intended recipient of this email and its attachments, you must
take no action based upon them, nor must you copy or show them to
anyone. Please contact the sender if you believe you have received this
email in error.
When the pin is pulled, Mr. Grenade is not our friend.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, March 10, 2008 10:38 AM
To: Midrange Systems Technical Discussion
Subject: Re: Which of the SYSIBM tables/views show the row count for
rob@xxxxxxxxx wrote:
Joe,
System crashes do happen on the System i. Not very often, but they're
still there.
Can we agree to modify it to say "rarely" happen?
Based on rarely, (if ever, to coddle some), then I say the primary
reason
for these features is not for a system crash. But to prevent things
like:
- Orphaned children (items whose item class is not on file sort of
stuff).
- data auditing
- data recovery from program errors or 'hand' maintenance.
- data protection from hand maintenance.
If, you crash once every five years, is it necessary to add additional
system complexity? Or is going to yesterday's backup tape good enough?
It's a business decision.
Yes, RI is required. Even if your applications are "written
correctly".
Because as much as we'd like to force every one to use our stored
procedures to access data, but reserve the right for ourselves to
access
the data directly, the other developers won't follow that double
standard.
They have business needs, such as mergers and acquisitions, that may
not
fit so well into the model. I'll grant you that last statement may be
a
little conjecture.
We've hashed this out over and over. If you have programmers going at
your database and screwing it up, you need new programmers. The real
concern is unfettered ODBC access. If you allow updates via ODBC, you
probably need all of the above: RI, constraints, and so on, as well as
exit programs and audits and logs and every other darned thing, because
your database is an accident waiting to happen.
I'd also seriously look at check constraints. I see dates that pass
conversion into true date fields. However I fail to believe that we
have
any active employees that have a birth date back in the 1600's.
So why didn't your maintenance program pick this up?
This also is opinion so it's time for me to get out. If in your shop
you have developers who regularly screw up the production database, then
perhaps you need all those things. To me, it's another business
decision. I know shops where programmers aren't allowed to touch the
production database and there's no outside access, so it really is only
the application program. It's all a matter of your corporate
philosophy.
Joe
midrange.com
