Re: Adjusting to DB2

From: Bjarke Wedemeijer <bjarke_at_wedemeijer.dk>
Date: 24 Oct 2005 10:45:45 -0700
Message-ID: <1130175944.976195.121260@g14g2000cwa.googlegroups.com>

Hi Mark and others,

normally i do not respond to such fooliness in these kind of threads but Marks remarks about the instrumentation is not incorrect it is also

misleading.

Mark wrote:
""I don't know what specifically you mean by "Oracle's instrumentation", but
that is also false. ""

This typically shows that Mark does not now what he is talking about, and that this thread is more about religion that facts.

There *ARE* only 2 database systems in the world that are properly instrumented, they are Oracle (yes) and my beloved DB2 z/OS. If you really want to know what instrumentation is within the DBMS world,
you should read optimising Oracle, from Cary Millsap (see hotsos.com, or my good friend Mogens Nørgaards www.miracleas.dk)

The problem with DB2 LUW is that no instrumentation exists on behalf of the code, db2trc gives you some clues, and good enough within DB2 8.2 you can trace a single PID, but you cannot like in Oracle or DB2 z/OS start a 10046 trace, or within DB2 z/OS use the IFCIDs to give you the same results. So tuning DB2 LUW is a far more daunting task than tuning oracle or db2 on z/os. So, within db2 z/os and oracle it is possible to tune by response times, and you know where time flies that is not possible yet on db2 luw, although we are working hard for toronto to look into these matters, infact there are internal requests for changes towards the toronto lab to make this instrumentation
available within v9 or v9-next, they are though internal IBM enhancements
requests.

SQL Server 2005 will as within oracle be partly instrumented (See Gert Drapers site, www.sqldev.net, and the dmv views.),

//bjarke.

Mark A skrev:

> "DA Morgan" <damorgan_at_psoug.org> wrote in message
> news:1130087707.157293_at_yasure...
> >>>I think a week is unrealistic if anything requires tuning or an
> >>>understanding of DB2 deeper than starting and stopping the server
> >>>though since DB2 is not one product on all operating systems which
> >>>o/s is a critical yet unanswered question.
> >>>
> >>>Most of your Oracle skills will be transportable but much of what you
> >>>take for granted is not. You won't find MVCC, you won't find
> >>>partitioning, you won't find RAC, you won't find RMAN, you won't find
> >>>DataGuard, you won't find SQL*Loader, you won't find anything remotely
> >>>approaching the richness of Oracle's instrumentation.
> >>>
> >>>I'd suggest you hire in, for 90 days, a DB2 contractor to hold your
> >>>hands until you are ready to stand on your own.
> >>>--
> >>>Daniel A. Morgan
> >>
> >>
> >> I would suggest that you get advice from someone who actually knows
> >> something about DB2, rather than Daniel Morgan.
> >
> > And your opinion is based upon what knowledge of my background?
> >
> > If you disagree with something I said then address it. Is there a point
> > of fact I got wrong? Lets hear it!
> > --
> > Daniel A. Morgan

>

> My post was based on frequent reading of your completely inaccurate and
> biased assessments of DB2.

>

> In this thread, you mention several features of Oracle which you claim are
> not available in DB2. In fact, DB2 does have equivalents to most of items
> you mentioned. DB2 does not have MVCC, but since the application is already
> developed, and the OP only has to support it, it is probably safe to assume
> that the developers either don't need MVCC or found an equivalent way to
> deal with concurrency.

>

> DB2 has HADR which is the equivalent (and better) than Data Guard. RMAN is
> nice when compared to the old way of backing up Oracle, but DB2 backups are
> very simple one line commands that backup everything (including logs active
> during the on-line backup) into a single file. When you restore DB2 you
> don't need to rename any log files.

>

> The DB2 export, import and load commands are far superior to SQL*Loader,
> which is primitive by comparison.

>

> I don't know what specifically you mean by "Oracle's instrumentation", but
> that is also false.

>

> Your usable diatribe about DB2 not being the same on other platforms is
> another half-truth. True, DB2 for iSeries (AS400), DB2 for z/OS, and DB2 for
> LUW (Linux, UNIX, Windows) are not identical, but Oracle does not even run
> on AS/400, and it runs poorly on z/OS. I doubt that OP was referring to DB2
> for iSeries (AS400), DB2 for z/OS, because those require specific knowledge
> of the OS's.

>

> DB2 for Linux, UNIX (AIX, Solaris, and HP/UX), and Windows is a single
> product that is same on all of its many supported OS's. When a new release
> or fixpack comes out for DB2 for Linux, UNIX, and Windows , it is always
> simultaneously available on all of its supported OS's, something which
> Oracle does not even approach.

>

> The application in question is already developed, and the OP just has to
> support it. Anyone who is familiar with Oracle can easily support an
> existing DB2 application on the same OS with one week training. The only
> exception would be if the application developer/vendor did not supply the
> optimum db and dbm config parms, but a consultant could set that up in a few
> days max. A few extra days to set up cron jobs for backups, runstats, and
> reorgs, and you are all set.
Received on Mon Oct 24 2005 - 12:45:45 CDT