 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / Oracle / Oracle Server / January 2006Using RAC for 25+ small to medium sized database
Hello, My company is considering moving some development databases to a new hardware platform. There are two proposals under consideration: a) 5 blade servers, using VMware to create 25 virtual servers with each virtual servers running a single instance of Oracle 10g on each. b) 5 blade servers with each running 25 instances of a database using RAC. I'd like to find out if anyone has any comments as to which would be the most efficient and what they would recommend. Thanks very much. Paul > Hello, > [quoted text clipped - 12 lines] > > Paul B. Why have the overhead of all those virtual servers? (not against VMware in general) Jim The alternative would be to have 25 instances running on each server each with buffer cache, large pool, shared pool, java pool, redo buffers plus each of these instances would have up to 20 oracle processes and there would also be 25 different database caches talking to each other from one blade server to another. Finally there's additional licensing cost plus some possible changes when moving a non-RAC database to RAC, 5 sets of archive/redo logs, 5 alert log files / database. I think that makes for a lot of overhead which is why I'm thinking the non RAC idea of the virtual servers would be the way to go. I should also mention that high availability is important but not critical for these databases. > The alternative would be to have 25 instances running on each server > each with buffer cache, large pool, shared pool, java pool, redo [quoted text clipped - 7 lines] > go. I should also mention that high availability is important but not > critical for these databases. Why so many instances? If possible use schema's. But doing all that in VMware doesn't reduce overhead it makes it much larger. (additional OS processes etc.) Do you need rac for develpment? Do you need that many different instances? Why not different schema's? Jim >The alternative would be to have 25 instances running on each server >each with buffer cache, large pool, shared pool, java pool, redo [quoted text clipped - 7 lines] >go. I should also mention that high availability is important but not >critical for these databases. Likely they just don't know how Oracle works, and they are mistaking schema for database. -- Sybrand Bakker, Senior Oracle DBA It's 25 different single instance databases that are currently on 25 different servers. If these 25 (proof of concept) work out then there are many more that could follow. These are all legacy applications, a bit of everything so there's no opportunity to consolidate the databases without making major application changes. Wish there was but it's just not possible. Either way it seems to me that they will be overhead with VMware virtual servers, a database / server (what we have now) or with RAC. There's always the other option of just loading up a server with a few database instances and not using VMware but that makes it difficult for us to move a database from one server to another. With VMware and Vmotion I'm led to believe that moving a virtual server from one server to another is very easy. > It's 25 different single instance databases that are currently on 25 > different servers. If these 25 (proof of concept) work out then there [quoted text clipped - 8 lines] > another. With VMware and Vmotion I'm led to believe that moving a > virtual server from one server to another is very easy. Why does it make it difficult to move one instance from one machine to another? copy works pretty well. You can consolidate into multiple schemas, the applications don't need to know that it is sharing an instance. it can't tell. I think the problem is that you have already decided what solution you want. Jim Hi, I'm working in a very large company where changing the name of a database is something that takes months of planning and in some cases is just not possible. All I have to work with is the very fixed requirement that the databases remain completely as they are. So from that respect I have decided that I can't change that. Given that situation I then need to come up with a suggestion for the RAC or VMware options. We'll probably end up trying both in a POC but I need to try and get some ideas. Ideally if anyone out there has had them same problem then I'd like to hear feedback from them. thanks, > Hi, I'm working in a very large company where changing the name of a > database is something that takes months of planning and in some cases [quoted text clipped - 5 lines] > to try and get some ideas. Ideally if anyone out there has had them > same problem then I'd like to hear feedback from them. thanks, This sounds like a really bad idea from start to finish. 1. I would never use VMWare as I doubt Oracle would support what you are doing in production and to test in anything other than a replicant of the production environment is not significantly better than not testing at all. 2. With respect to name changes ... database names are irrelevant. Let people use the same name in their TNSNAMES.ORA and the database/ service names can be anything you want: They are invisible. 3. Blades are a waste of money until such time as there is an industry standard. One vendors has changed their blade specification three times in five or so years. Buy blades now and you will have zero confidence of getting compatible hardware a few years down the road. My recommendation would be to have your company management read Oracle's RAC message until they get it. Build systems from inexpensive commodity hardware.  SignatureDaniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond) |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.