One DB instead of two? (performance issue)

Question

Hi guys,
I am currently working on a system that has a not so good architecture (in my opinion) and I am trying to find arguments to convince the others that my way is better (or convince myself that my way is not so good :)).
the big questions is like this: in case we have two DBs, one is used by an OLTP system and the other one is used by a batch processing system with huge amount of data and with full table scans, the first one does not need any data from the second but the second needs almost all data from the first (FTS), should we have these two system on the same DB or we should separate this on separate DBs. so the huge FTS will not interact with the OLTS system, it will extract the needed data through db links and than work by itself? (here I think I may be wrong. any FTS done from the batch DB to the OLTP DB, will first load the blocks in the OLTP buffer cache than move the data over DB links, and put the data in batch DBs buffer cache. correct?)
Current situation:
We have two databases: CUST (customers) and RATE (calls).
- CUST has contracts table, their details, addresses, a lot of configuration tales (ref... system_settings), payments. There are around 200 k customers with their related details and the configuration tables have around 200 rows.
- RATE DB has the CALLS table that has around 100 000 mil records
The DBs communicate with each other using DB links and they are on the same machine
- On CUST DB we have a OLTP system like (this is not using any data from RATE): contracts creations, payments..etc.
- On RATE db we have the RATING module that is running continuously using big amounts of data. the RATE DB needs almost all tables from CUST: full table scans over DB link.
This is a telephony billing system.
This architecture was done way back and the idea was to have multiple CUST DBs and for each CUST to have a RATE DB. we did not reach to the point to have multiple CUST DBs and I believe that now we have other ways to scale: RAC.
Would not be a better idea to group these two so we will not have issues with DB links waits, with CBO statistics over DB links, with exec plans over DB links with the fact the some data(the entire CUST DB) is used for both DBs.
I believe that the FTS on CUST tables done by RATE process will not be such a big issue, because the buffers are already in buffer cache because of the OLTP actions. But what about the FTS on the huge CALLS table?. Will this interfere with the rest of the system; it will be a good idea to put the huge table in different caches?
What do you think?
Edited by: alinux on Jan 9, 2012 5:33 PM

Answer 1

alinux wrote:
I am not quite sure that I understand how a full table scan works over a db link. let’s say I go to RATE and I issue a FTS on a table from CUST DB
are those blocks put in memory on RATE or on CUST and RATE or just in CUST. I thought that they are only put in RATE and the buffer cache for CUST is not affected at all. I think I am wrong and the CUST buffer is affected. So you are right, the CUST is already affected by this and grouping the DBs will help in this case because we will not duplicate that table in two memories. We will use some data from buffer cache that is already used by OLTP system. Correct?A single large cache is better than multiple smaller caches. It scales and performs better.
If for example, a FTS was "bad" for other sessions, then why does Oracle not implement a buffer cache per session? Or why does the kernel not implement a file system buffer cache per process?
How many SQL shared pool caches does an Oracle instance use? One for all sessions.
I have yet to see server s/w designed to create a small private or dedicate cache per client - as this does not scale. Also, clients often deal with the same data and can benefit by using each other caches. For that basic reason, servers implements a single cache for all clients.
If someone says that this does not suffice and there can be conflict of some kind - then in my mind, that needs to be proven beyond any shadow of a doubt.
And at the same time, reasons must also be supplied that if 2 instances are required due to potential buffer cache conflict, why 2 servers are also not needed to address CPU conflict, memory conflict, conflict for server resources such as mutexes and semaphores and so on.
Why would the conflict (if it exists), be limited to only the buffer cache?
Merging these two DBs means that I need to increase memory structures.In what way? It means fewer memory structures. It means a single shared pool. Single buffer cache. Single library pool.
Multiple instances mean duplicating these (fairly sophisticated) memory structures - and as there are now more of these, it means using smaller structures. And a smaller buffer cache for example, is less capable than a larger one. Multiple ones mean more overheads are required to manage access to the memory structure (e.g. semaphores and mutexes).
in the past I remember that I had issues with OLTP system in case of to much memory. Do you see an issue here?Only if there are conflicts in the Oracle instance configuration settings. The buffer cache does not care if the SQL is OLAP or OLTP. It serves as a buffer to the physical data on disk.
I'm not saying that beyond a shadow of a doubt, you should be using a single instance.
I'm saying that a single instance is the norm and is what makes technical sense ito server performance and scalability. And that if 2 instances are to be used, then there must be sound and factual reasons for that exception.