Timesten Queries

Question

Dear Forum,
Background: We have single database instance, 22 application instances - (RAC is not allowed solution as per higher management decision)
If we implement IMDB Cache:
1. Will there be any overhead associated with reads and writes (Synchronous) ? If yes, how do we quantify the same.
2. Application demands the use of the global cache (as transactional data). Will there be latency issues owing to multiple nodes. How oracle manages the node in the cache grid.
3. What is the optimum grid size to be proposed. Is there any guideline (for e.g. 8 grid, 16 or for all 22 grids)
4. What is the minimum infrastructure required
5. The application uses XML file in terms of BLOB/CLOB. Is Timesten okay to handle BLOB/CLOB.
Sorry for flooding with the queries. But any pointer/advise/guidance would be greatly appreciated.
Thanks
ORA_IMPL

Answer 1

Thanks for your detailed answer. This really helps and gives me an insight into the TT. Appreciate if you can answer the following cross queries tagged as 'DM and underlined text'
thanks for sharing experience, your contribution is very helpful for junior collegues like us.
Hi,
Thes questions are not easily answerd in isolation. A decision to adopt TimesTen, and especially TimesTen Grid, needs to take int oaccoutn many factors. For example, adding TimesTen into the picture will not be transparent to the applicaiton. Application code changes, possibly significant ones, will be needed. Also, the beyhaviour and characteristics of cache grid impose constraints on the kind of SQL that is grid capable. Also, application data access needs to be (a) mostly localised to the grid node wher the data currently rsides and (b) have a strong temporal locality of reference if good performance is to be achieved. So, there is a lot to consider and investigate before you can make an informed decision as to whether TT cache grid is the correct solution for you. Having said that, I will try to answer your questions as best I can:
1. Will there be any overhead associated with reads and writes (Synchronous) ? If yes, how do we quantify the same.
CJ>> I don't really understand this question. Reads would normally be satisfied from the IMDB Cache and so will be much, much faster than reading from Oracle. For grid capable queries that reference data not present in the local grid node the data will be retrieved from another grid node (preferentially) or if the data is not in any grid node then it will be retrieved from oracle. Clearly there is significant overhead in thsi case compared to the case where the data is already present in the local grid node. There are many factors thta can affect the relative performance but let us say that typically a local access will take a few microseconds, a retrieval from another grid member a millisecond or two and a retrieval from oracle may take several milliseconds. The only way to know is to test your queries with your schema on your typical hardware and measure it. For write operations, all changes are propagated asynchronously to Oracle (there is no synchronous option) and so overhead is very small and updates are very fast (much faster than in Oracle). However, if a query/DML tries to access a row located in a different grid member and for which there are comitted, unpropagated updates then that access will block until those updates have rached Oracle (to ensure data consistency). In this case there could be a large overhead. Again, this depends very much on your specific setup and data access patterns and so you need to measure it.
DM: if there are any unpropogated changes in node 1, node 2 tries to read the same data. Which data the node 2 will read (the old data or the node 2 read will be blocked OR the node 1 unpropogated changes are committed & node 2 read is facilitated)
2. Application demands the use of the global cache (as transactional data). Will there be latency issues owing to multiple nodes. How oracle manages the node in the cache grid.
CJ>> That question has a big answer! Best to read some of the information on Cache Grid in the documentation. Essentially cache grid implements the concept of data ownership and enforces that there will only ever be one copy of any piece of cached data within the grid at any one time. Only the grid node that 'owns' the data can read/write it. If a different grid node needs access to the data the data itself is transferred to that grid node and the ownership updated. Depednin on how data is distributed and the application access pattern there may be very little overhead or a great deal of overhead. Your application must be designed in a 'grid aware' fashion to gain full benefit from grid.
DM: The database contains around 60 % of semi static reference data. This data is used by all different applications dynamically to validate their work content. Essentially all of these application are reading the same data. It is a prime requirement that any changes to the semi static ref data is propogated in timely fashion to all downstream processing
3. What is the optimum grid size to be proposed. Is there any guideline (for e.g. 8 grid, 16 or for all 22 grids)
CJ>> There is no one optimum size. It dpends on data volumes, type of hardware and the workload to be supported.
4. What is the minimum infrastructure required
CJ>> Realistically you need to use replicated grid nodes and Oracle Clusterware for grid management. The very smallest grid that could be configyured is therefore two physical machines (each acting as the replicaiton standby for the other) running TimesTen and Clusterware. You also need,m for Clusterware, some supported shared stirage for OCR and voting disks (e.g. NetAPp filers or some kind of SAN).
5. The application uses XML file in terms of BLOB/CLOB. Is Timesten okay to handle BLOB/CLOB.
CJ>> TimesTen does not currently support XML nor CLOB/BLOBs. You can cache Oracle CLOB/BLOB data in TimesTen VARCHAR2/VCARBINARY columns. Access to this data in TimesTen will be via the SQL API and you must retrieve / update the entoire CLOB/BLOB value. Any XML interpretation must be done by the application.
DM: Currently all the applications to and fro communications are happening in CLOB/BLOB and XML. If we have to rely on SQL API and update the whole CLOB/BLOB value, it seems that it will increase the processing time. I see this may be a constraining factor to use the TT.
Context: Application deals majority of the times with XML files. It receives payment in XML, conversion to internal format (again xml), applying business logics and converting it again to the outbound formats (xml) and sending across. They are currently stored as BLOBS and CLOBS in database. Size of database is 4TB.
There is one single database instance and 20 application instances. Application uses JDO as their ORM framework. With the growing volumes of data, JDO along with multiple times calls to database during the processing of each transaction(mainly due to blobs/clobs) is known bottleneck for the performance.
I am trying to find the improvement solution. TT may not fit the bill. Any other oracle feature worth investinging.