Re: Recompiling invalid objects in PL/SQL

hpuxrac wrote:
> #hpuxrac wrote:
> #> Recommending people run utlrp.sql to fix invalid application objects
> is
> #> not just bad advice, it is terrible advice.
>
> # After a database upgrade.... oracle runs the same program.
>
> Is this what the OP asked about ... a database upgrade?

An update, actually - not sure whether the OP knows the difference in Oracle terms, but I stand corrected.

>
> Are there differences between a database upgrade and application
> changes that are relevant?
>
> #> It demonstrates a poor understanding of how to administer oracle
> based
> #> applications in my opinion. Posting this kind of advice by someone
> who
> #> probably knows better is sad.
>
> #> Many organizations monitor invalid objects in important application
> #> schema's and recompile them as needed ... just within the schema
> #> affected ... not all schema's.
>
> #Monitor for the sake of monitoring?
>
> Monitor to find out if recent application changes have somehow caused a
> problem.
>
> In other words, making sure that a set of one or more schemas and one
> or more applications that normally do not/should not have invalids have
> not changed.

Part of the update/upgrade strategy, not of monitoring
>
> Identifying application changes that may not be coded optimally that
> may now be causing invalid objects.
>
> # Besides - why would objects "suddenly" become invalid, and then valid
> again?
>
> You really don't know? Because of bad coding patterns or by developers
> that haven't yet mastered some of the finer oracle considerations. Tom

Guess my programming style is OK then. Never had any trouble with it.

> Kyte has covered this subject pretty well. Do you have a specific
> question here?

No other then already posed. Which you don't answer.

>
> #> It is possible to design many if not most oracle based applications
> so
> #> that no object goes invalid in an application schema. In production
> I
> #> don't expect any in my environment to go invalid and I will report
> and
> #> investigate any that do go invalid.
>
> # Just as there's no reason for objects to go invalid, there's no
> reason to monitor.
>
> If you don't monitor how do you catch problems caused by application
> changes? This is just basic DBA 101 here Frank.
>

No it's not - it's the TUSC/BCHR school of DBA here - monitor for monitoring sake.

Objects do not go invalid during normal operations, period. They could become invalid as a result of code changes (application update/upgrade, database update/upgrade, etc).

But checking that is part of the test and implementation plan. And that's maintenance, as simple as that, John. As a DBA, you do not monitor, you evaluate the vendors implementation plan, and give the green light, or not.
And that's preventive maintenance.

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...