| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: In-Memory Databases..
Off hand I don't think that this is a good idea. Your IO device is buffering it's output via a cache, the CPU has a cache and Oracle is caching data in the db_buffers. Adding a custom application on top of all of that ... I'm not sure that it will gain anything. Plus you will have to maintain data integrity, ensure that all changes are written to the disk or rolled back, recover from disk failures, protect against data loss in a power outage, and I don't know all what else. Are your developers up to the challenge?
And it won't gain you anything if each transaction causes the cached database to be reloaded.
An in-memory database is very fast but it needs to be tuned not only to the business data but also the business practices. It works best with a well established business process where the data input can be batched and pre-sorted to minimize database reloads. Not very many businesses operate in that fashion any more.
On the other hand --- if you have a monster machine with a huge memory
(such that the database does not need to be partitioned) and every
component is fault tolerant, such that you don't have to worry about
transaction interruptions and data loss, and your developers have a lot of
spare time on their hands, then I'd say to go for it.
"Loughmiller,
Greg" To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
<Greg.Loughmille cc:
r Subject: RE: In-Memory Databases..
@cingular.com>
Sent by: root
05/09/2003 12:52
PM
Please respond
to ORACLE-L
actually-thinking in terms of a "cache" database. For example, TimesTen, that would sit in front of Oracle and act as a "solid state" in-memory database.. It would interact with Oracle as required.. Refresh from the database as defined,etc.. It would bypass a lot of the read-consistency efforts and other "block" mechanics Oracle would use in an effort to provide an image of the data..
Does it gain a lot? Open different can's of worms? dunno...... Lot's a duhvelopement folks have been pushing to use it front of the physical database.....
greg
-----Original Message-----
Sent: Friday, May 09, 2003 10:58 AM
To: Multiple recipients of list ORACLE-L
Many years ago. The big thing was to partition the database so that each piece could fit in memory and still provide functionality. We would divide
the database horizontally; i.e., group tables together so that a given organization could perform it's function with just the data that was in memory. If that was too big then we would also partition the database vertically; i.e., by date range or by last digit of SSN or some other function related to the main table's primary key. If the work to be done was ordered in the same manner then this was OK --- the organization would only have to reload the database a limited number of times as they progressed through the primary key.
However, if the data came in in a random order then this was a nightmare since the database would have to be reloaded for every transaction.
If you think of trying to pin Oracle's most frequently used tables in the db_buffer --- that's basically the issues that you will face.
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail for such purpose.
"Loughmiller,
Greg" To: Multiple recipients
of list ORACLE-L <ORACLE-L_at_fatcity.com>
<Greg.Loughmille cc:
r Databases..
@cingular.com>
Sent by: root
05/09/2003 09:56
AM
Please respond
to ORACLE-L
Anyone out there using in-memory databases as part of their Database infrastructure? Curious as to what extent the "experiences" have been with
some of these tools..
TIA
Greg
Greg Loughmiller
Sr Manager - Enterprise Data Architecture
gloughmiller (IPS)
678.893.3217 (office)
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Thomas Day INET: tday6_at_csc.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Fri May 09 2003 - 14:58:46 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Thomas Day INET: tday6_at_csc.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |