if one schema is your metadata and SMALL...cache it
if its a pre-live/load schema I would do nologging on tbs's
AND keep undo_tbs as a non-system tbspace
I work with 4 schemas in one db. No problems the past 4 years
Printable View
if one schema is your metadata and SMALL...cache it
if its a pre-live/load schema I would do nologging on tbs's
AND keep undo_tbs as a non-system tbspace
I work with 4 schemas in one db. No problems the past 4 years
Quote:
Originally Posted by mrchrispy
fair enough, judgement call needs to be made for each case then, but Id certinaly like to start with trying to put things together, my database here has 140 schemas in it without problem really, works for me but may not for others
Here's my general rule: Consolidate to share, Distribute to manage.
There's nothing better than having the data you need to share under the same memory (cache) structures.
Taking a system (application in your case) down that doesn't need to go down is bad design.
Do these applications have the same uptime and recovery requirements?
If you need to bounce the instance for an init param change, you'll take both "applications" down.
Any instance change, will mean that you need to test both effected applications, yadda, yadda, yadda
I'm all for consolidation and I don't believe in throwing hardware at a problem. But sometimes a little extra hardware may save you a lot of headaches down the road.
both the applications are pretty much related and the databases uses DB Link to access each other's dataQuote:
Originally Posted by mrchrispy
That sounds like they should be one Database instance then. Look at Oracle Application Servers Meta Data Repository - It installs 22 schemas just for that.Quote:
Originally Posted by nirupam
If thats the case then is sounds like sharing an instance is the logical approach, I was thinking worst case (as I tend to do :rolleyes:).Quote:
Originally Posted by nirupam