RE: Would you recommend such an application for production use? (just the bit about stuff in SYS)
Date: Thu, 18 Feb 2010 01:12:14 -0500
In the case of creating views and synonym and such (rather than objects that require segments) there isn't much added to the SYSTEM tablespace, and nothing that wouldn't be added by adding a view or synonym to any schema.
Of course that actually brings up a very old enchancement request which was partially serviced by adding SYSAUX to SYSTEM for things that vary greatly in size. Work was in progress on partitioning at the time, and the rest of the request was to partition things like source$ that could become very large. The idea being that only the stuff that was really required to start up the database would get into the partition(s) that lived in SYSTEM so that in recovery situations SYSTEM could remain as small as possible, which is good for too many reasons to list here. And of course activity in one partiton of source$ for one application might be segregated from activity for another application in a different partition in a different tablespace. Which I always thought would just naturally scale better. Of course since there is no way to test a feature that doesn't exist, we are reduced to speculation of how this might work better. Whether things would actually scale independently in actual implementation is an open question, but it does create the possibility that things might scale better in many respects.
And of course if an application had all its source in a single partition, it would seem likely that de-installing it could be streamlined as well, and in major release upgrades the "new" programs unit versions might be installed into a different partition, thus making it efficient to revert to the older versions and providing an efficient mechanism to delete or take the old versions off line when the new versions are thought to be safe.
What brought this to mind was your bit about fragmenting your SYSTEM tablespace, which I agree with, but which the poster's note about creating a view only does to the extent that views in any schema pollute SYSTEM, while we routinely accept the violence done to SYSTEM in the storage and access of PL/SQL all the time. I tip my hat to Oracle for managing that as well as they do, but I still think theory is on my side in thinking they could do much better with partitioning.
Now as for Jared's statement about the x$views changing, he's quite right. I usually try use the v$ views that Oracle provides to access the x$ "tables" because a long time ago they made a pronouncement that if you used the v$ views you'd be protected for compatibility going forward. Sometimes, though, it is just a lot less for the computer to do if you create a custom view of an x$ if the bits you need are only from a pretty baroque set of v$ views as supplied. Of course when you or a vendor indulges in that shortcut, the onus is on the creator of the view to keep up with forward compatibility. - And do you trust the vendor to do that? Still, if the information is in a v$view and Oracle can maintain that compatibility moving forward, it should be always possible to update the custom v$view. If you spew something from an x$ that they don't provide a v$ for, then I think you're on your own with no guarantee that information will even be in a future release.
At the very least I'd be asking for clear text scripts of the custom view creations for escrow, and I'd get really uppity if they replace an existing viewname.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Kellyn Pedersen
Sent: Thursday, February 18, 2010 12:09 AM To: ORACLE-L; development_at_the-playground.de Subject: Re: Would you recommend such an application for production use?
Creating objects in the SYS schema? Them's fightin' words in my book... Take the chance and fragment my SYSTEM tablespace with non-system objects? Someone had better be ready to do some serious explaining to me... :(
- the installation script furthermore creates objects in the sys schema, namely create view foo as select * from someX$view
This is disturbing for me