AristaDBA's Oracle Blog....

Microservices architecture is a better approach than the monolith approach to application development. The question is, how do you pull it off? One extremely beneficial method is the 12-factor app methodology. It was created by developers at Heroku back in 2011. So let’s get started. The 12-factor methodology is a set of 12 best practices for developing applications to run as services. The 12-factor app...

So basically, when we talk about a coordinated backup and restore, remember that in a sharded database, I have different databases. Each database is a shard. When you take a backup, each database creates its own backup. To ensure consistent data across...

If you’ve been in software development for a while, you’ve probably heard the term “microservices” thrown around a lot. Let me break it down for you...

what is a directory-based sharding?  Directory-based sharding basically allows the user to define the values used and combined across different partitions, providing better control over data location, in which partition,...

Now let’s move to sharding native replication, which is RAFT-based, that means reliable and fault-tolerant, usually providing subzero or subsecond zero data loss replication support. Generally, what is sharding in native replication? This is a completely transparent, built-in Oracle sharding that duplicates data across the different shards. So data are generally put into chunks. And then the chunks are replicated across three or five shards, depending on the level of fault tolerance required. This is completely provided by the Oracle sharding database and does not require...

When it comes to dealing with Oracle Database architecture, the components include, first, your shards. The shards —each an independent Oracle Database —depend on the partitioning. You decide on a partition key and how the actual data is divided across those shards. Then you have a shard catalog. Shard catalog as it what the name says is a catalog of your sharding configuration is aware of all of the components in the shard and any kind of replicated object, that master object exists in the shard catalog to be maintained from there. It also manages global queries, as we will see later, acting as a proxy. So queries can be distributed across multiple shards. The data from...

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.

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.