Re: SYS can't own triggers?!

Hi Peter,

The way I describe this.

SYS is the "owner" of the database, at least the owner of the various internal tables and data structures that are used implicitly by Oracle during the general running of the database. SYS is like a special, hidden little chap that executes all this recursive code and ensures the database runs as required.

Now if we do anything that might interfere with SYS doing it's job, it could impact directly on the running of the database with obvious possible disastrous results.

Note SYS is also our "get in" user. No matter what might be occurring in the database, no matter what disastrous logon triggers are preventing everyone else from entering the database, SYS can always get in. Hey, this little guy is effectively God in the database. Locking SYS, dropping SYS, creating objects that SYS really shouldn't look after, creating objects as SYS that might take up space that's required for "real" sys objects, etc are all no nos (and not possible in many cases).

Lastly, ever tried exporting SYS ? Bit tricky, so objects that you create as SYS are not easily manipulated in this manner.

And lastly lastly, if you connect in as SYS and create things as SYS, you can also drop things as SYS. Why not, you're connected in as SYS right. Well such "accidents" such as dropping the wrong table when connected in as SYS can also have unwelcome repercussions. So I question even connecting in as SYS unless you are performing sysdba/sysoper type functions.

In summary, if you (could) create a trigger as SYS, you would probably end up shooting yourself with it :)

Cheers

Richard

Peter Chatterton wrote:
>
> > DON'T create anything, nothing, nada, nunca -- as SYS. Even these
> triggers!
>
> This is finally getting to my implied question: what is so special about SYS
> that you can't create anything?
> Peter.
Received on Thu Aug 15 2002 - 20:13:18 CDT