Re: CONTROL_FILE_RECORD_KEEP_TIME and MAXLOGHISTORY

Yup. Time to give in gracefully. KEEP_TIME is king.

Good little bit of testing, this.

Incidentally, forget that SQL*Net stuff (I believe we've moved on to something called Net8 these days, anyway). Your brain should be adopting IIOP, and using the Aurora ORB. Otherwise, it's just plain old-fashioned. Are you CORBA-compliant?

;-)
HJR "Brian Peasland" <peasland_at_usgs.gov> wrote in message news:3A893C8C.3691C406_at_usgs.gov...
> Howard,
>
> > What version is this again, Brian (my BRAIN_RECORD_KEEP_TIME is
> > significantly under 21 days!!)?
>
> The version of db that I tested this on was Oracle 8.0.6!
>
> As I posted yesterday, the number of records in V$ARCHIVED_LOG was more
> than the MAXLOGHISTORY parameter from the previous night's control file
> dump to trace. So I check last night's dump to trace and *VOILA* the
> MAXLOGHISTORY jumped again!!!!
>
> On occasion, my BRAIN_RECORD_KEEP_TIME is more than 21 days and other
> times it's around 21 minutes. And there seems to be no pattern as to
> which BRAIN_RECORD_KEEP_TIME applies to which records. I'd fill out an
> iTAR on the problem, but I'm sure that Oracle would have me spend two
> weeks just verify that my SQL*Net connection between the two halves of
> the brain worked.
>
> That being said, if memory serves me right you had mentioned in the
> beginning that it was MAXLOGHISTORY which was the driving force behind
> this whole thing. I would agree that it appears that way on the surface.
> But upon further examination, it must be the KEEP_TIME parameter which
> drives the whole thing and the MAXLOGHISTORY adjusts itself to keep
> pace.
>
> It was a fun little experiment nontheless.
>
> Cheers!
> Brian
Received on Tue Feb 13 2001 - 09:16:46 CST