February 4, 2026

So how do we setup the True Cache and Application services. You’re going to create a database application service on the primary database. You might already have one created that you want to use for True Cache. But however, we’re going to operate under the concept that you don’t have one. You want to verify that your database application services are created. You’re going to make sure that those services are started. And then on the primary database, you’re going to use the DBMS_SERVICE. This is usually specific to a pluggable, so you’re going to connect to that PDB or make sure you set the correct PDB container in the session before you start the DBMS_SERVICE. For RAC, you’re going to use service control to configure it. So here we can see an example of the service control command utility to add that service. On the primary database, if you’re using one True Cache service, two services, one single database as the instance primary database, what are you going to do? So here, in this first example, we’re creating a database application service for the True Cache called SALES TC, using that as the name. Next, we have a create database application service SALES for the primary database using SALES as the name. And we are associating it to the SALES TC service using the TRUE_CACHE_SERVICE attribute. And then third, if you already have a service created, optionally, just modify an already existing primary database service called SALES. And here, we’re associating it to the SALES TC service, again using the TRUE_CACHE_SERVICE attribute. So create them, associate it. Or it’s already created, just associate it. We’re going to verify the service.  This is an example query with the possible output. So here we’re selecting, OK, what are the services I have? So here we can see that we have the SALES True Cache. We have the SALES service. And then we also– then on the TRUE_CACHE_SERVICE, we have the SALES True Cache. We can start the service on the True Cache instance. We’re going to launch SQL*Plus.  Here we connect to it. Check our role.  Yep, this is the one. This is where we have the True Cache. That is the role of this database. Then we’re going to start it. Start the service.  Then we’re going to verify the service. ...

Before we can configure, we’re going to have to install the database software on all the true cache nodes. We want to make sure, again, just like previously– even with the automatic DBCA, we want to make sure that the primary is an archive log mode.  And you want to make sure that you set archive log mode on that primary database. Do not set on the primary database that log archive config or the log archive destination on the primary database. That’s because true cache, again, is going to configure these for the primary database, just like it did if we were using the automatic– using the DBCA. Very similar there. You want to make sure you check the prerequisites. You want to make sure that you have a tnsnames file created with– on both the true cache and the primary database nodes with the correct information for both, so not only true cache instance information but also for the primary database. You need to have a listener. Local listeners use for that redo to be received from the primary database. It must exist and must be started. We previously saw about the password file. There are several different parameters required to start a true cache instance, so you’re going to have to create a p file. Then you’re going to create and start the true cache. We’re going to start up no mount. Verify the password file if you’re using it. Verify the status of the true cache instances. You’re going to create the application services on your primary database. You’re going to make sure the services are created if you don’t already have them created for that. Verify the application services are created on both the primary and the true cache, and make sure that they are both available. You do need to create or modify your tnsnames file. Again, you can do that manually, or you can use the NETCA– the Network Configuration Assistant. So you can use either one to do that. You’re going to add the application service names for the network names that we use for all the database instance participating in the true cache configuration. You’re going to add the database instances. In the tnsnames, you have to have– there’s basically three for True Cache and three for the primary. One is True Cache. You’re going to have the network name plus the application services. The primary database needs to have the instance network name and also the application service name. And then what about the listener for that primary database and also for your True Cache instances. So here’s a little sample entry. So you can see we have our TCDB1I, so our True Cache instance there identifying the protocol. What is the protocol? What is the host name? What is the host name? What is the port number, and what’s the system ID for that? We also have one for our primary database. Then we can see there’s for our True Cache service, the sales tc, and then also an entry. There’s an entry for that primary database application service name, sales. So for our tnsnames, there’s a sample entry for our listener, for the primary and also for our True Cache instance.  That listener.ora file is required, again, either manually or with the NETCA. Not only do we have to have the tnsnames, but we have to have the listener.ora file. You want to make sure your environment variables are set, that the Oracle home and Oracle cid are set properly. You can just do an env in Linux C environment. Rep one just for Oracle– however you want to do that. We want to make sure that home bin path directory is in our environment. You can just do an echo dollar path on that and see what paths are set for that. You’re going to want to make sure that the listener is running, if it’s not already, so here, just very simply. We’re going to start the listener, and we’re going to check the status. Or if you’re pretty sure it started, just go ahead and check the status. And if it’s not, then start it and check the status again– however you want to handle that.  For the password file, it does require to have that up to date password file. Previously, we looked at how we could copy that manually. All right? Or we can create the blob– use the DBCA for that. But it’s from that primary database. It’s needed in order to be able to apply that redo to the True Cache. If you update the password file, you do want to make sure that you recopy it– whenever administrative privileges, like the SYS DG, OPR, DBA is granted or revoked, you want to make sure you recopy it. If you’re using a wallet, copy the wallet inside the password file if you’re using the Transparent Layer Security, instead of a password file. If the primary database configures transparent data encryption, you need to make sure you copy it. So there’s the TLS certificate authentication if you’re using TDE. And you want to make sure that you only include the root container master key in the copy, and those are needed to decrypt the encrypted redo that shipped from the primary to the true cache to keep it consistent. You do need to prepare a PFILE for startup. So you’re going to– what is the True Cache? What’s the instance? What’s the name going to be? My primary database instance. What’s going to be your unique name for my True Cache? And my DB files the same as my primary database instance. How much memory are you going to allocate to the SJ for that? Where is my parameter for the primary database node listening then? And that FAL server– when I first saw that, I thought that’s a failover server or what? That’s just a fetch archive log. That’s the name for the primary database for that, so that way I can know where to connect to and then also the client network name for that. So fetch the archive log FAL. The DB create file destination to store the required internal True Cache instance files. Again, control file, temp files– where is that going to be at? I might need to set up my DB domain for where the node resides at and then also for my wallet route and the TDE configuration. So here is a very simple example for the PFILE. OK. This instance is going to be True Cache. Same value as the one for my primary database– where is that? What is the unique name for this True Cache going to be? The number of database files– you want the same as the primary database. How much SGA am I going to give it? There’s the fella FAL server. What’s the network name for my primary database? And the client is the True Cache network name. There’s my instance name for this True Cache. The directory where I’m going to store the internal files for the True Cache. Specify my network name that’s going to resolve that local listener. And what is the primary database listener– not needed to create the True Cache, but this one is needed if you’re going to use a JDBC. So we’re going to start up our True Cache using that PFILE in NOMOUNT.  We’re going to verify the password file. We’re going to create that True Cache, and it automatically creates those standby redo logs, the control files, temp files, SPFILE because then on the next shutdown start up, it’ll use the SPFILE.  We have to create that PFILE– one for it to start with. And then after that, our True Cache is ready to use.

You can configure and deploy True Cache with the Database Configuration Assistant. Even when using the Database Configuration Assistant to set up, there are items that need to be completed prior to configuring True Cache. One thing you need to make sure that your network path access to the primary database has set up with an Easy Connect string from the True Cache node. You’ll need to install the software on all the Two Cache, and you want to make sure that your primary database is running in archive log mode. It’s needed to ship the redo log files to the True Cache node for that. Of course, if your primary database is not running an archive log mode that you want to use for True Crash, you will have to change that. And do not set these two parameters on your primary database. That’s because True Cache is going to automatically configure these for the primary database for its use. If you’re using a password file, you can copy the password file from the primary database. Or, if you’re using transparent data encryption, you can copy the wallet. You can either do this manually or you can also create a blob with the Database Configuration Assistant. So here, you can see the command to create the blob on the primary database.  So you’re going to prepare the True Crash config file. That is the option that says, hey, I’m going to create that blob that’s going to have that password file or the wallet. You’re going to identify what is the primary database system ID, and then the location, the path where you’re going to save the blob on that primary database. You want to make sure that the file that you copied to the True Cache and ensure that the file is owned by the Oracle home user. So then when you configure True Cash, if you’ve manually copied the password file, you want to identify what is the True cash unique name, the database unique name, or in this case, we use the global database name. Either one of those will work. What is the system identifier for the True Cache? And here is that connection string to the source, to the primary database using that Easy Connect. The password file, that’s the path to the primary database password file that was copied. You’re going to copy to the True Cache node. If you’re using a blob, then basically the same, very identical, except now we have the True Cache blob from source.  This is the full path and file name for the configuration for the blob file that contains that password file or the wallet. This is the path where that file is located. You can use the JDBC thin driver for each primary database application service that you want to cache or create a corresponding True Cache database application service for. It’s going to make it easy for the applications to switch an existing JDBC connection from a primary database to a True Cache instance without having to change the JDBC URL. You want to make sure that you have a listener configured. You can check to see if Valid Node Checking for Registration, the VNCR, is configured for the listener. If so, then you’re going to want to make sure that you add True Cash to the REGISTRATION_INVITED_NODES_LISTENER parameter, and that’s in the listener ORA file. If you’re using a RAC environment, you want to make sure that you use service control to add it.  Do not manually edit the listener ORA file as the grid owner. Best to use service control. You’re going to create and start your primary database service. Here, we’re creating a service called Sales.  We’re starting on the primary database. If you’re using RAC, you’re using service control utility to do that.  You can verify this service with a very simple SELECT. Here, we’re selecting from active services, and we can see there’s our sales service that’s running on the primary database. You can run the silent mode, the DBCA configuration command. In this case here, we’re going to what? We’re going to configure a database. So here, we’re going to use this option to configure the database application service on the primary and start the service on the True Cache.  Where is my primary database? What’s the unique name of that? Here’s my connection string in. We’re going to have that Easy Connect connection string for that. What is the True Cash service name? Remember, I have mentioned about want to have whatever your primary database service name. Most likely, make sure that we have True Cash, tc on that so that way we can identify it as True Cash very simply. What is my primary database service name? So there we can see the sales and it relates to the sales through cash, and the primary pluggable database name for the True Cash. And then, of course, we run it in silent mode. After the application service starts on the True Cache, we want to make sure we can use the listener control command to validate the remote listeners. So here, we can see we have our two True Cash registered with the SCAN listener. We’re using the SCAN listener.  So this would be a RAC primary database, and we can see we have the True Cache instances available there. For the uniform True Cash configuration with multiple True Cash service in the same service, we want to start. We’re going to start the service on all, all the True Cash instances.

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...