| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: question about automatic undo management
Joel Garry wrote:
[snip]
>>As I said, if you want to get personal about things, and in particular if >>you wish to keep pushing the line that what I do is 'ivory tower', then go >>right ahead. >> >>But bear in mind: You don't know the half of what I do, or what I've done.
You don't. You either agree with advice I post here, or you don't, and can advance something better to replace it. My personal/professional history should have nothing to do with it.
>
> Sorry, I had a bad day that day, mean things wound up striking me as
> funny. And I should say, I agree quite a bit with your first answer
> to the OP of getting a giant disk.
>
>
>>>So, when will they get the bugs out of CBO? >>> >> >>Strawman.
I believe it is a strawman, because you are comparing apples with oranges. The complexity of the CBO is immense. The question of how SMON goes about its jobs is a magnitude of complexity smaller.
A better comparison would have been, for example, bitmap management in locally managed tablespaces. Bugs galore in 8.1.5, largely sorted out by 8.1.6, and (as far as I can tell) pretty comprehensively sorted by 8.1.7.
Like LMTs then, auto-undo is a new feature in 9i, and one which is destined to play an ever-larger role in most databases (Wouldn't surprise me if manual undo eventually (11i??) went the same way as DMT in 9.2... impossible to implement under particular configurations. It was bound to have some quirks in its early days. I believe they will be sorted if they are that major.
And before you (or someone else) says it, anyone who has read anything I've posted here will know that I'm no apologist for Oracle Corporation.
>
> The larger point is SMON does too much in the middle of too many
> critical paths, and this isn't being helped by giving it new things to
> do. There is often an inordinately large time lag between a bug
> coming out and the tar and the fix, especially in something that only
> gets hit sporadically in large systems. On unix systems, it is normal
> to kill things through PMON because SMON is often too busy to bother
> with it. And I believe OEM uses SMON still, correct me if I'm wrong.
To do what? As far as I know off the top of my head, SMON coalesces free space in DMT with pctincrease > 0, coalesces free space in temporary tablespace, checks database consistency at startup, performs instance recoveries when needed, populates the SMON_SCN_TIME view for flashbacks (and similar views), and now sorts out automatic undo segments. I'm sure there are one or two others, but I can't think of them off the top of my head. And perhaps one of those has some sort of relation to OEM, but you'd need to be a bit more specific as to *what* you think SMON and OEM are doing together.
> But even something as basic and aged as exp... broke in 8.1.7.3 and
> 9.0.1.2, noticed by some bank in Turkey or something last June, so fix
> didn't even make it into "final release" of 8.1.7 or until 9.2.
> Harumph! You call that "dealing with it?" Little solace to the guy
> trying to explain it to non-technical managers.
They have their priorities, and their release schedules. Doesn't mean it doesn't get fixed eventuality, which is all I claimed. As one who blew the whistle on the infamous LEFT OUTER JOIN debacle, I fully appreciate that occasionally the relevant people miss the significance of reported bugs, and schedule accordingly. They did a pretty good job once they realised the problem in that specific case, however.
>
> I think the Oracle bugfix cycle hit a complexity wall early in V7, and
> no matter what they do to re-engineer the support business processes,
> it won't get any better.
HJR Received on Fri Jan 24 2003 - 19:30:34 CST
 |
 |