Re: Stale procedures?

for future reference, off-line enough, is defined as severing the CREATE SESSION privilege until the upgrade is completed.

Daniel A. Morgan

Greg Weston wrote:

> In article <3AD7DE48.E9B0EA58_at_exesolutions.com>, Daniel A. Morgan
> <dmorgan_at_exesolutions.com> wrote:
>
> > Thanks for the clarification but what you are describing is a production
> > system.
> > And you should not be modifying code except during a clearly defined window
> > during which the other system is off-line.
>
> It is a production system, yes. Upgrades do happen during a clearly
> defined window. The other side is, effectively, offline. Apparently
> it's not offline enough, but we had no reason to expect that was the
> case until we banged into it.
>
> > There is nothing going on, with
> > respect to UserB, that could not be automated using dynamic SQL so I don't buy
> > more than a few minutes to have the system back on-line.
>
> Except for things that are going on in the program unrelated to the DB.
> I shouldn't have said "tearing down and setting up the connections."
> The complete process of shutdown and startup takes an unpleasant, in
> terms of exposure, amount of time even though its in the small hours of
> local time. Unfortunately, stopping and starting the process is the
> only way to actually tear down the connections (short of yanking a
> network cable) and I'm uncertain of the timeframe for getting that
> shortcoming addressed.
>
> > As I said before. If someone reporting to me did this they would it would be
> > treated as a serious infraction of good practice and I would question whether
> > I wanted them to remain in on the project.
>
> I understand your point of view. I'm just a bit confused about the
> behavior, and not one of our DBAs (me, the duffer, or either of the two
> substantially more experienced ones) expected or knew of the behavior
> until 36 hours after the first time it happened when a report was
> generated showing the disparity. Having found a behavior that we can't
> find documentation for, I was curious as to whether there was a known,
> minimally disruptive way to address it.
>
> Come to that, is there documentation you can recommend indicating
> specifically that users can't reliably call procedures that have been
> updated while were connected. I'd like to have something to show my
> peers and higher ups.
>
> G
Received on Sat Apr 14 2001 - 22:04:41 CDT