True Cache is an in-memory cache. It is read only. True Cache is deployed in front of a primary database, and it is automatically managed. It keeps the most frequently accessed data in the cache, and it keeps the cache consistent with the primary database. They call it diskless, but it’s not. It does require some space for SP file, redo logs, control files, and such. But it’s very similar to Active Data Guard.
The queries can be offloaded to the True Cache for faster query response. And the data in the query cache is consistent. Unlike other mid tier caches like Redis or Memcached, a query to the True Cache returns only committed data, and the data is always consistent. It’s secure. Why? Because we implement our Oracle database security policies and you can control access to the cache.
Here in this diagram, we can see we have a True Cache configuration. We have four mid-tier sessions using a JDBC thin driver. We have the two True Caches along with one primary database. Now, the solid lines that we see here, they represent the frequent reads that go to the True Cache. So here we can see the solid line going to the True Cache there. Whereas the smaller dash lines, we can see, are going to the primary database. And then those larger lines is showing how, from the primary database, as the data in the true cache changes, it is updated.
So why use the True Cache? Well, improve application performance without having to rewrite any applications. That can save considerable amount of time, effort and expense. Reduces the application response time. So the closer the True Cache is to the application, the faster the response. Now, you do need a large amount of memory. We’re talking memory here. It’s an in-memory storage area, and depending on how you configure it, you can have it shared, you can have it divided. And we’ll look at some of the configuration options.
I mentioned it’s automatically maintained. So there’s no application changes required, and it is transparent to the application. Again, simplifies that development and maintenance. So at a high-level view, True Cache or primary database, the application configuration serves as other things that are going to decide where is it going to query the data from, from the true crash or from the primary database.
The True Cache satisfies that query. And that’s where the data will be fetched from. If not, then from the primary database. On Start up, True Cache is empty. So it starts reading large chunks of data to populate the True Cache. So after a block is cached, then again, it can be automatically updated, apply the redo to it– very similar to the Oracle Active Data Guard. In the data returned it is always going to be consistent.
So is it going to be current data? Well, maybe, maybe not. If it’s been updated in the primary, if they redo apply hasn’t occurred yet, then it’s not the most consistent. But as far as the query cache is concerned, it is the most current because we only display consistent. You can have multiple True Caches. You can save the same database application service to the True Cache as you can partition it. We’ll be discussing some of the different True Cache configurations options a little bit later.
So some things to know, you need to have significant amount of memory. Memory, memory, memory. So True Cache is completely memory, memory. So I want to have all my data possible in there. The more memory you have, the less likely something is going to age out. And of course, just like with the standard caching, you can also pin objects to stay in the true cache.
Yeah, like I said, there are some requirements for storage, even though it’s called diskless because of, again, redo log files, configuration files like the control files, SP file. And again it is read only. However, we’ll be discussing a little thing called DML redirection that you can apply the changes a little bit faster.
So with using the True Cache, we have two physical connections, and we can have one to the primary database and one to the two cache. Each connection has a database application service associated with it, and it’s going to choose which connection to use based, whether it’s going to go to the True Cache or to the primary database.
The second way is the application maintains one logical connection that uses the application service for the primary database. It’s the JDBC thin driver, starting with Oracle Database 23 is available. It’s going to maintain the physical connections to the primary database and the True Cache itself. Now, as you notice here, the logical connection, the one logical and one physical, is for Java applications only.
Applications that work with JSON, we extend the HTTP entity tag support for that. So a database GET request to the True Cache is going to compute the ETag, insert it into the return document. But what happens if there is a mismatch when the modified document is put back into the primary database? Well, then the database is going to verify. OK, what happens with that?
It’s going to verify the document row still matches that ETag for that. If with that put command, let’s say, I have new data here, the row is going to match that ETag that was automatically updated. If there’s no match, another user has changed the data and the PUT request is rejected. So the PUT request can be retired using the new data.
Recent Comments