Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: In-Memory Databases..
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 Subject: In-Memory 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-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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Loughmiller, Greg
INET: Greg.Loughmiller_at_cingular.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). Received on Fri May 09 2003 - 11:52:24 CDT