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 all shards of the entire schema, it is extremely important for these databases to be coordinated during backups and restores. So you maintain data consistency across all shards. That’s the purpose of the coordinated backup restore system we built together.
Now you don’t submit this through our main. You submit this through the Global Management tool that is used for the sharded database. And it’s the Global Management tool that actually submits your request to each database, while maintaining the consistency of when the actual backup is taken and which SCN.
So that SCN coordination across all shards is maintained for backups, you can create a consistent backup or restore to a consistent point in time across the sharded database. So now this system was enhanced in 23C to support multiple destinations.
So you can now send your backup to an object store. You can send it to SDLRA. You can send it to Amazon S3. So multiple locations can now be defined where you can send these backups to. You can also use multiple recovery catalogs.
Remember, we talked about data sovereignty. So let’s say I have data in different countries, and we have a requirement that the data for each country must remain in that country. So I also need to use a separate catalog to maintain that partition.
So now I can use multiple catalogs and define which catalog maintains which partition to satisfy those types of requirements, or any data administration requirements, when it comes to backup and recovery. In addition, you can also now specify a different type of encryption to be used, whether you want to have a different type of encryption algorithm for each of the databases that you’re backing up that are maintained. It can be identified and then set up for each one of those components.
So these advancements now allow you to manage coordinated backup and restore across the various specific configurations that may be required based on the data organization. So the encryption, as we talked about, can now also be done across that, as I mentioned, for different algorithms. And you can define different components.
Finally, there is much better error handling and response available through this global system. Since things have been synchronized, you get much better information for diagnosing any issues. So, what this is generally used for is number 1: having the capability to map backups to a separate storage location.
This can give us a good configuration, depending on the tool used in the given location. So I could have a ZDLRA in the United States, but use a regular storage or something used in Canada for that particular partition.
This could be Oracle Object Store if you’re on Oracle Cloud, or Amazon S3. When it comes to encryption, you can configure it as part of each shard specification when you’re setting up, and it’s defined with a separate algorithm and components that you can then define for those operations.
As I mentioned, you perform all backup and recovery operations using the global tool. So, using that global tool maintains consistency in how these jobs actually execute across the shards.
Now, in some use case spaces, similar to what we talked about, we can have multiple recovery catalogs, each identified by the partition, the shard, the catalog location, and detailed information that also provides a bit better security.
So the people who manage a particular shard that must be in a certain location with certain security now have all their backup information in a catalog they can maintain under the same security controls.
So you can go to your global tool. Once you get to the global tool, you can set up your backup configuration. You can identify the shard. Can you identify which catalog it will go to? Specify the catalog credentials. And then identify what type of encryption algorithm, if encryption is even enabled.
And then for another shard setup, another configuration. So this would be for shard space number 2, and so on. All right. Once all of those are done, this configuration is built behind the scenes. And know the components are getting routed.
So when you use the global tool to perform backups, restores, or queries, depending on what you are querying about, it knows exactly which catalog to use, where to go, and which specific information and settings are associated with that particular component.
And if any errors are associated with those jobs, we can use the global tool. And then, from there, we can review all RMAN output that is also funneled to that location, with a bit more detail on this coordinated backup and recovery and what the issue actually was across those components.
So when it comes to specifying, how do we identify and set up? Basically, we use the config backup, as shown on the previous slide. With that config backup, you can identify a specific shard, or you can do it for all of your shards. You can identify what recovery catalog, specify your connect string, the encryption associated with it, and the encryption algorithm.
What is the destination? Where are we sending it to? So all of those details can then be set up and configured using the config command in the global tool, GDSCTL. Now you can also back up to the ZDLRA. Here you will also see that I’m going back up to ZDLRA.
And then you’re going to identify the connection string and connection information for the ZDLRA, the user information, and the specifics of the ZDLRA operations required. Once you set up all components and identify all ZDLRA components, your backups can be automatically routed to the ZDLRA.
Now, if you’re going to have multiple recovery catalogs, as we talked about, you do a config backup here. This one you saw a couple of slides ago: instead of the shard being all, as you saw in the previous slide, you identify a particular shard space, then give a specification for that shard space, including the specific shard catalog. Then create another config for another shard space.
So you can either have this configuration built globally for all spaces or individually for each shard space and identify how the backup catalog and configuration are set up for that particular shard. When the backups are taken, remember is the global tool that actually submits the backup request.
So the backups are consistent across all of the shards. That consistency is maintained through SCN, an operation that runs in the background. So in the metadata for the backups, that information is written, so we know where this consistent point is in the backup.
Again, remember that all of this is maintained and used automatically behind the scenes to guarantee consistency. Therefore, you can centrally deploy your backup. And when it comes to recovery, again, it’s the same thing. You can use recovery to identify individual shards or recover data across all shards, with any granularity and data consistency to meet the application’s requirements.
Then you can also define the different storage locations and the operations for moving the chunks between them. And all of these are then maintained. So the metadata and all that are understood, as well as how these operations are used behind the scenes.
Therefore, to achieve all this coordination without individual database interactions, we use the global data service controller. And through that global data service controller, you kind of perform similarly to what we do within the Oracle Cloud or within fleet operations: you work with a set of databases in a consistent operational environment.
All right. So you go to the global data service tool, run a backup, and identify that you want it synchronized across all the shards, or is it a backup for a particular shard? And when you want to go ahead and restore, you can identify, OK, I want you to restore to a particular restore point, or do you want to restore the control file or a particular shard?
And do you want to make sure everything behind the scenes gets synchronized and set up? So all of these are different types of options you set up here, where the global tool then maintains the components across the shards to ensure consistent operation of your command.
Recent Comments