You can configure True Cache one of two ways. You can either use the Database Configuration Assistant, which actually makes it a little simpler to configure it, and you can also manually create it.
You have some environment options. One is a uniform configuration where you can deploy identical True Cache that use the same database application service. Another way is partition configuration. The data is going to be divided across multiple True Caches, which, each cache is a different subset of the data. You can also deploy True Cache in a RAC environment. As one might expect, there are some additional configuration steps for a RAC environment.
Uniform Configuration
Partition Configuration
Partition Configuration with Multiple Services
You want to make sure you verify your configuration, that the database application services are working as expected after you configure it. And then, optionally, you can enable DML redirection. What that will do, it writes data to the primary database, and that data is automatically updated in the cache. It’s very similar how to the Oracle Active Data Guard works. Because the DML redirection uses more resources, it’s not recommended for update-intensive applications.
There is a parameter, a ADG_REDIRECT_DML initialization parameter that you will set to True in order to do that. So in a uniform configuration, here, we see we have a primary database. We have identical True Caches. And then we have two application services. The clients are evenly distributed across the True Caches. Both the caches cache the same data.
We can also partition our True Cache. So here, the first we’re going to look at the colocation tag. So here we have our primary database. We have our two True Caches. And we have two applications. So we can see there’s a different subset of that data that’s going to those True Cache. And load balancing is going to be totally ignored. Why? Because we’re identifying which True Cache is for which service.
And here, we can see that’s done by this COLOCATION_TAG. So up here, we can see we have US, and we can see we have Europe. And if you notice, from this application service, there’s no reference going to the TCDB1 True Cache. So we are separating them.
Another partition option is to have multiple services. And here, we have one primary database. We have two True Caches. And then we have two applications. Notice the service names on the True Cache. So one True Cache is going to service one database application. Again, we can see there’s no reference from the application HR to go over to the application where the service is servicing sales.
You do need to make sure your network is configured for True Cache in the primary database. So optionally, you can create a remote listener for high availability. But you create your True Cache. You go ahead, and make sure that you have your primary database. You want the network configuration for both of those. And then you create the True Cache. Once the True Cache is created, you’re going to create the application services associated with the database. And then, you’re going to start the database application services on the True Cache.
When it comes to naming the application service names, each primary database application is going to be associated with a corresponding True Cache application service. To help simplify things a little bit, in the naming convention, you’ll notice in our examples– for example, if we have SALES as the primary database service, then we have the True Cache, we have SALES_TC, standing for True Cache, so it’s easily identified.
You don’t have to do that, but it’s kind of recommended to do that, some way that you’re going to identify it. So we’re going to start our True Cache services. And you only start the True Cache services on the True Cache instances. Because it’s the database services on the database that you need to make sure are started. And they are read-only.
So a couple best practices for the maximum availability– uniform configuration seems to be a popular one. Why? Because I am going to have the both True Caches can be shared. That way, hopefully, I’m getting full usage out of both. And maybe if I have one service going to one. It might be minimally used. Whereas, the other one might be over. Hey, I could use more memory over here.
We’ll also recommend use the JDBC 23ai UCP, Universal Connection Pool, for the application. So that can lessen the impact. If one True Cache becomes unavailable, as far as, OK, I need to reroute over here– benefit of uniform configuration also. Prepopulate the cache. You want to go ahead and run the critical workload for that. If you have a planned outage, and you need to shut down the True Cache, you want to make sure you stop the database application service on that True Cache.
And then, how are you going to design your True Cache? Are you going to partition it? Are you going to have uniform? Which partition option are you going to use? So you can try to design that to help minimize the number of fetches it has to do from the primary database. And the more you can keep in the True Cache, the better the performance is going to be.
Recent Comments