-
Impact of two schemas sharing an oracle instance
Sorry guys I didn't put my question correclty
As of now I have two seperate databases (DB1, which is Oracle 8.1.7.4 & DB2, which is Orcale 8.1.7.2) on a single Solaris box. Lets assume that DB1 has schema S1 and DB2 has schema S2
now we want to move to a new Solaris box which has a single database instacne (9i) and put both S1 & S2 in it (i.e. an oracle database with two schemas, right?)
what will be the impact on performance, capacity? what areas should we consider to avoid any issues?
Regards
Nirupam
Last edited by nirupam; 11-03-2005 at 09:23 AM.
-
two databases cannot share the same instance, it is impossible
You need to work out what you really have got there
-
I think you 2 applications sharing the same database.....yes/no/maybe?
Dont go there.
-
Originally Posted by mrchrispy
I think you 2 applications sharing the same database.....yes/no/maybe?
Dont go there.
English please !!!
Able was I ere I saw Elba
-
Originally Posted by mrchrispy
I think you 2 applications sharing the same database.....yes/no/maybe?
Dont go there.
sorry, typo on my part.
I think hes asking about 2 applications sharing the same database and what are the implications. It would be possible but its hardly worth the stress
-
why? a single database takes up less resources than 2 databases.
Twi separate schemas in a single database is the cleanest option
-
Sorry guys I didn't put my question correclty
As of now I have two seperate databases (DB1, which is Oracle 8.1.7.4 & DB2, which is Orcale 8.1.7.2) on a single Solaris box. Lets assume that DB1 has schema S1 and DB2 has schema S2
now we want to move to a new Solaris box which has a single database instacne (9i) and put both S1 & S2 in it (i.e. an oracle database with two schemas, right?)
what will be the impact on performance, capacity? what areas should we consider to avoid any issues?
-
Originally Posted by davey23uk
why? a single database takes up less resources than 2 databases.
Twi separate schemas in a single database is the cleanest option
I know where your coming from but if they are 2 entirely different applications (with different business owners, business functions and such) I thinks it best to split them. Having them on the same server is bad enough (e.g. if one instance is burning up CPU) but if they are sharing the instance it'll be all the more difficult to isolate any problems.
I just don't think its worth the hassle doing this with two production systems.
-
Originally Posted by mrchrispy
I know where your coming from but if they are 2 entirely different applications (with different business owners, business functions and such) I thinks it best to split them. Having them on the same server is bad enough (e.g. if one instance is burning up CPU) but if they are sharing the instance it'll be all the more difficult to isolate any problems.
I just don't think its worth the hassle doing this with two production systems.
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|