Re: TimesTen and In Memory Databases.....

On Mar 6, 11:23 pm, Mark Townsend <markbtowns...@xxxxxxxxxxxxx> wrote:
Solomon_Man wrote:
All,
I have been assigned to evaluate the TimesTen in memory database
software.
Please note I am not a DBA but I do have quite a bit of systems
knowledge.

From what I have seen I have not been that impressed based on the
price point and some of the issues I have read about.

Times Ten is not magic - it enables a specific architecture to a
specific problem. There is no magic 'go faster' software. There is good
architecture design.



Such as

1. You can easily get resource contention (CPU, memory, I/O) between
oracle and TimesTen. This can hurt TimesTen performance (and Oracle
performance). So we can get around alot of this by putting the
TimesTen Databases on another Box. This is not a big issue in our case
as we are in a Grid configuration situation but still its additional
cost.

You are supposed to put it on another box. Why would you put it on the
same box as the backend Oracle database - you could just give the
resources to Oracle. Stick it on each box in your application tier.
That's the whole point of it. It enables a multi tier data architecture



2.The TimesTen should run on the same machine as the application and
be accessed using direct mode not client/server to maximise
performance. This could be a problem but not in our case.  This fact
could force some upgrades to existing machinery in our case and the
additional cost is a factor.

Right - link Times Ten into your application memory, then all SQL
statements happens in the same memory segment as the application - very,
very fast.



I am more worried about issues with data table sizes. We have very
large data tables. We are talking many millions of rows and hundreds
of columns is very typical in a few of our temporary tables.

Only load the data you want to process into each Times Ten cache. Leave
the rest of it sitting in the back end database. If you have lots of
machines in the middle tier, load subsets of data to each. Think scale out.



Anyone had experience using Times Ten with very large Data Tables?

3. Users must optimize the Times Ten Database besides the Oracle
Database.
Most likely not a problem but still a learning curve.

Two products, two learning curves. Neither are that difficult.



4. No Procedure on the TimesTen Database at this point (release). This
is a major issue, in my opinion, is there ways around this?

Not at the moment. But what do you need stored procedures to do in the
application memory that you can't already do in the application code.
The whole point about stored procedures in the database is that they are
remote - the whole point of Times Ten is that the data is not remote,
it's in the same memory space as the application.



What can I expect for speed improvements, 5X , 10X, 100X with Times
Ten?

10x ;-) But more importantly, millisecond response times for DML in your
application for the data it is caching locally. Note that if you do not
need millisecond DML, then you do not need Times Ten



 I understand the advantage of moving things into memory and avoiding
some of the I/O issues. Would I be better off adding an additional
processor or another rack then more memory instead of adding the
complexity of another piece of Software and machinery. Or even the
possibility of a data warehouse and update tables on X amount of
time.

If your data is remote (i.e across the network) from your application,
then you will never be able to remove the network latency from your
transaction. If the network latency is a problem for the speed of your
transaction, then use Times Ten and architect you application to remove
the need for the network - there is little alternative, and this is
exactly what TT is designed to do. If network latency isn't a problem in
your transaction, then consider other approaches to making the back end
database scale better, such as SQL  Tuning etc. Note that if your
application and database design doesn't scale, then adding more hardware
to the back end server is just going to make it scale even less, faster.





Opinions are welcome.

Thanks,
Chris- Hide quoted text -

- Show quoted text -

All,
First of all thanks for all the responses!

Secondly, I am in agreement with what Mark said about issues with
remote data, tuning, and how TimesTen should be used. I am not going
to lie and say our database is ultimately tuned. Like I said I am not
a DBA, so my opinion is not really worth a grain of salt, but gut
feeling tells me this is some of the problem and will be part of the
final solution. Unfortunately we need to be able to scale further as
we are really just getting started.

I will say that the systems I see in place will definetly support the
decision to purchase an In Memory Cache Database System. The company
has very decent web presence with very high traffic, all in house, not
to mention a few external pieces of software that interact with those
servers and other servers all by Oracle. External user interaction
through one of the applications alone can be in hundred thousands per
hour. Not the largest Oracle house I have work with but definetly
decent size.

With this in mind we currently have a few in house DBAs and a few
decent Oracle consultants. We had some very sharp DBAs but one guy
took a big title jump and relocation at another company, another
person jump ship after 25 yrs, and the recent recession has affected
our normal IT/Systems/DBA staff. So to say the least we are very tight
staff and due to the times tight on budget. Whether it makes a
difference or not now, the systems from the ground up were all
designed to perform under extremes with performance in mind. This
included Oracle tuning and design on every project.

I just wanted to note that the stored procedure issue could be
somewhat of a issue for us as a decent percentage of our Oracle form
code leverages Stored Procedures as their datasource. I am sure this
could be worked out in time but we are not talking 20-30 forms here so
this is a concern with our current staff. Also there are many PLSQL
jobs that are ran all through out the day and night which is one of
the many reasons why we are looking at In Memory Cache Database
System. The previous decision and architecture was all before my time
at the company. :)

I am now looking for a general feeling on how implementations of
TimesTen have gone. Also other options such as SolidDB from IBM.

I appreciate all the help,
Chris
.

Relevant Pages

  • Re: Utlizing /3GB and /PAE to go beyong 2GB limitaion of WIndows 32 bit
    ... I am using Windows 2000 Advanced Server and my database version is ... Oracle 9.2.0.6 32 bit. ... when I have multiple database instances using AWE. ... 512M bytes of memory will come from lower 3GB area. ...
    (comp.databases.oracle.server)
  • Interview Questions(Oracle9i DBA), help me
    ... The DBA is attempting to back up the Oracle database control file. ... The request queue is common, and the response queue is different ...
    (comp.databases.oracle.server)
  • Re: acceptable way to program
    ... Objective research by Oracle and IBM have both shown ... Backup isn't a query with any commercial relational database. ... written in Crsytal Reports or Cognos and not have Java front-end. ... weigh heavily against even the knowlegeable DBA insisting that the ...
    (comp.lang.java.programmer)
  • RE: How to call Oracle DBs via DBI ODBC
    ... This error will be returned if the (database) service has not been ... You need to speak with your DBA and have him/her fix it. ... How to call Oracle DBs via DBI ODBC ... sender of the delivery error by replying to this message, or notify us by ...
    (perl.dbi.users)
  • Re: dataset Performence Issue
    ... Microsoft that a DataSet is okay to abuse as a DataBase. ... Managed Code can never be as fast and as optimized ... very good for 90% of the situations i.e. normal memory usage, ... Merge/GetChanges - and oh lets not forget keeping your disconnected cache ...
    (microsoft.public.dotnet.framework.adonet)