February 5, 2026

let’s start by talking about what is database sharding and what is an Oracle Database Sharding. So the sharding of the database, this is basically an architecture to allow you to divide data for better computing and scaling across multiple environments instead of having a single system performing the work. So this allows you to do hyperscale computing and other different technologies that are included that will allow you to distribute your queries and all other requests across these multiple components to be able to get a very fast response. Now many times with this distributed segment across each kind of database that is called a shard allow you to have some geographical location component while you are not really sharing any of the servers or the components. So it allows you separation and data management for each of the shards separately. However, when it comes to the application, the sharded database is totally invisible. So as far as the application is concerned, they connect to a global service, submit their statements. Everything else is managed then by the sharded database underneath. Now with sharded tables, basically it gets distributed across each shard. Normally, this is done through horizontal partitioning. And then the data depending on the partitioning scheme will be distributed across like server A, server B, server C, which are independent servers that are running independent databases. Now the Oracle Database Sharding allows you to automate how the data is distributed, replicated, and maintain the kind of a directory that defines the complete sharding scheme, while everything is distributed across many servers with no sharing whether the hardware or software. It allows you to have a very good scaling to be able to scale based on this partitioning across all of these independent servers. And based on the subset and the discrete data configuration, you can go ahead and distribute this data across these components where each shard is an independent data location or data component, a subset of data that can be used, whether individually on its own or globally across all of the shards together. And as we said to the application, the Oracle Database Sharding also looks as a single component. So with Oracle Database, you basically have linear scaling capability across as many shards as you like. And all of the different database configurations are supported with this. So you can have rack databases across the shards, Oracle Data Guard, GoldenGate. So all of the different components are still used to give you all of the high availability and every other kind of functionality that we generally used to having a single database with. It provides you with fault toleration. So each component could be down. It could have its own replicated data. It doesn’t affect other location and availability of the data in those other locations. And finally, depending on data sovereignty and configuration, you could actually distribute data geographically across the different locations based on requirements and also data access to provide a higher speed for local data management. So some of the use case basis is having to have a very high OLTP environment. So with this OLTP environment, some other databases that has been used could have been Cassandra the MongoDB, the MariaDB. But with Oracle database, of course, you get all of this better administration of the transactional operation and data administration. You could have global databases, depending on data sovereignty, data locations, as we talked about, managing logs and text operations, dealing with metric time data that is partitioned based on locational aspect, and then could be sub-partitioned based on time basis, and data that is used for machine learning and also the big data for data analytics. And as you can see, there have been other databases that has been used to provide similar options, what Oracle can provide for the clients.

To deploy True Cache for an Oracle RAC primary database, there are some additional configuration, things you have to do. If you’re using the Database Configuration Assistant, you want to make sure that you set for the scan port service for that. For the manual configuration, you’re going to set the REMOTE_LISTENER parameter to the SCAN:port. You’re also going to configure that FAL_SERVER parameter to the SCAN:port/service_name. You’re going to add True Cache to the– True Cash node to the SCAN listener. You’re going to use the Service Control command. You’re not going to manually edit. Do not manually edit it. You use Service Control command to add that. When creating the database application service on the primary database, you can use the Service Control command line utility. And then you’ll start the service on the primary instance. You can verify is the True Cache instance actually applying the redo and making progress a couple different ways. First, we want to verify that our True Cache instances are OPEN, READ ONLY WITH APPLY. This means that the true Cache Instance we do apply is actively working or should be actively working.  Then you might check the SCN. And you might check it occasionally to see if it is advancing to letting you know that it is applying changes. We want to make sure we want to validate our remote listener. So we’ve seen these before where we have our service names. And there’s our True Cache instances. So here, we see we have True Cache registered with the SCAN listener for a RAC primary database. You can verify the application service on True Cache. Go to connect to True Cache instance and go ahead and select from the Active Services view.  And then we can also do the same thing on our primary database.  We’re going to go ahead and connect. And select from that v$active_services. In this case here, we’re just looking for our sales. And here, we can see there is our sales from our primary database and then the SALES_TC from our True Cache instance.