Cloud Migration Strategy for Oracle Databases

Transcript

How to make it easier to ingest data during database creation? The hypothesis is that most Oracle databases which are provisioned in Exadata Cloud, especially on dedicated infrastructure services, Exadata BD and cloud at customer, they already have a presence on Oracle database somewhere else in a different environment. That other environment could be on-prem Exadata, it could be an on-prem bare metal machine on which the database is running, any general purpose machine, or it could be a virtualized environment on a VM, Oracle database is running. So there are different environments on-prem, different types of machines on which the database is running, and they are planning their migration to cloud. Some cases during the migration, they also are doing some modernization. But the premise is that every database which is created in that Exadata Cloud infrastructure and Exadata Cloud at customer service is a database which already exists on a different environment, which is already in Oracle. And if this is true, then if we can make the creation of database in Exadata Cloud services on dedicated infrastructure and cloud at customer infrastructure, make it so that during the creation of the infrastructure itself, we ask you about what is the environment where your source database is already running, and if we can make it so that if we can provide some kind of easy utility which lets you either install the utility on that source database, whether it is on-prem, whether it is running on, already on an Exadata machine, which is on-prem Exadata to cloud Exadata, or if it is running on just a general purpose, you know, bare metal machine, like whatever, like an IBM machine or other Dell server, or if it is running on some virtualized VM wherever on-prem, or it could be in some other cloud environment like Azure or GCP, it's running on a VM or a bare metal machine. If we can provide some mechanism which allows the customer to run a utility, discover the structure of that database as is. So when you say structure of the database, there are multiple facets to it, right? So one is how the database is configured. So configured includes like what is the parameters used to create the database, what is the structure in which the database exists, meaning what is the size of the different memory configurations, what are the control files, what are all the other things which are required or customized by the customer for that database to function on-prem, whichever on-prem or in a different cloud in their source environment, however the database is structured, we can learn about it. Then on the source database, whether it is a already running in a, is it a container database or a older non-container database, that is something we can learn about. Based on that, what is the version you're running? Some of these databases are running for a long time and they're running 11G or 12C. What is the point of you guys knowing about it so you can sell something else to them? No, the point of knowing about it is so that we can help them create the equivalent in cloud automatically. Because some of the time, what happens is when you are learning about the source database, this whole process of figuring out what the current database is, how it looks like, and how to migrate it and create in cloud is a three to six months project. And it requires deep expertise from somebody in sales and migration engineering. It's a solution which we offer and there is like high touch involvement. So if you were to automate that experience, the goal is to accelerate the zero to one in cloud. So usually what happens is once you learn about the structure, you learn about what... Don't you guys have like a generate report or something like that which tells you the... all the things that's running, how critical it is? No, criticality doesn't matter. On the source database, basically learning about the database which they want to migrate, we have lots of tools. Those are all tools and they are solutions, but they're not cloud services. Those are tools which the customer can use. One of the key tools in that space is, and depends on, first is to learn about the structure of the database. Second is what kind of software is running. It's what version, 11G, 12C. These are all older generations of Oracle software, database software. Newer cloud versions are 19C and 26 AI. So if they plan to migrate, are they going to use the same structure? Because cloud does not support the same structure, these legacy structures. So what transformations or structures do we allow? This is on the database configuration structure. Then what software versions we allow? And if they are coming from 11G and 12C, how will they... are they willing to upgrade to 19C or 26 AI? And during the upgrade, we'll have to help them kind of, you know, do some changes in their database to kind of validate if their old, you know, database structure will work with the new software. Sometime there is some validation, object validations. There are certain features which are not backward compatible. Those kinds of things you have to help with checks. The structure of the database, the software of the database. Third is the data itself. So sometimes the application which is running on-prem in the source database, you may want to get like a subset of the data into cloud. Because that usually it is some test database and you have some application connecting to the database and writing and reading from it. To start your POC or start your migration, you will either get the whole database or some parts of the database, like certain tables from the database or certain columns or rows from the database. So basically there is a subset or a transformation of the data itself which you bring into cloud. And once you bring, so what structure to bring as is or match cloud standards, what software version to use, software version to use, on-prem legacy or you will change it, then what data will you bring, the whole database or a subset of the database. Once you decide all these three things, then the last part is how do you want the migration to be? So you create this new database which is target is cloud and then will you connect, like you know, maybe 5-10% of the applications are now connecting to the new database and then you do some performance testing. Once the database is in cloud and let's say you say, are you doing a like a, there is a cutover where you keep on testing and then eventually all of the applications writing to the database at the source is fully now writing to the cloud version. So depending on how much time you want to dedicate to this migration process and what is your cutover strategy, so if you want it to be fully live, meaning you want to continue to use the on-prem database and continue to use the cloud database and only have some connections come here and then migrate without any downtime, then we have different tools. And if you want to do it with some downtime where you can afford to, you know, just migrate all the data here and after like, you know, a few hours, days, depending on how much time you have and then you have the applications connect to it, maybe it's a test database, then you have different tools. But the goal of this project is to abstract all the tools so you don't have to make the decision of what tool to use. You just give us the business outcome you need, what structure you need, what software you need, how much data to bring from the database, and what is your migration, like, you know, timing requirements are. Do you want it to be a zero downtime cutover? Can you afford some downtime? How much time do you want the migration to take? For example, if you have a big enough network connection then, and if you can afford downtime, you can take a backup of the database or a data pump and then dump it. Or you can have it live. So we have different technologies. Like, for example, if you want it to be live, then you can use DataGuard, which uses physical migration. Meaning whatever is the block storage in the database at the source, the same block-by-block copy will be done in cloud. That is through DataGuard. If you want other logical migration options and if you want live, both the target and source to continue to serve application traffic, we have GoldenGate. But all these options of whether you want to use backup and restore, whether you want to use data pump to export and import the whole backup and restore and data pump export-import are both like cold migration. It means you have to stop and then connect here once you import. There are also logical. Or you want physical migration where it is block-by-block, block copy, then it is DataGuard.

Or if you want live replication between source and destination, if you want live copy about source and destination, then there is something like GoldenGate. But all these tools usage and setup of the tools and the connectivity from the source to the target, these all things we want to abstract and just make it as part of Create database in cloud. So you don't have to pick all these things, you don't have to consider all these things, you don't have to figure these out. We will give you a utility. We will do the analysis and we will recommend based on your business outcome, this is what we can do and just automate that process and then it will be like a long running workflow. It will have multiple steps where first people validate your structure, validate the software, do some checks for connectivity, understand whether you want to do physical migration or logical migration, understand whether you want to do live, like, you know, both the source and data needs to be continuously serving traffic or are you okay with some downtime. And then how much time you have for the whole migration process, is it days, weeks. And based on that, we come up with a way to create the database in cloud, which is already aware of what data you're going to put in it. Today, the database which is created in cloud is like an empty database. It doesn't know anything about the purpose it is going to be used for. And the whole premise is that all databases which are in cloud, at least on dedicated, are not running new workloads. They're not being created as new databases. They're existing databases which are moved to cloud and they are appended with more data. So the hypothesis is that if you, instead of making empty database, if you make a database which can ingest data and we seed it with the right data, then that will make the adoption of the cloud sooner, faster. And the last part is even this database is just the first database, which is just to do the POC or the planning, right? After you do a little bit of testing is when you start migrating the rest of the databases for the same application. So that long-term first creating one database, testing, and then supporting further migrations of the company, supporting further migrations of the remaining database and how to kind of bring all of that data in as part of the core native cloud flow, the creation flow. Right now, all of this is outside, are separate utilities. You have to do this even before you come to cloud. You have to run the utilities separately. You have a tool called GDM, zero downtime migration. You have another tool called Data Migration Service. You have a separate service called GoldenGate Service. You have manual data guard setup. You have backup and restore tools. You have data pump as a separate tool. They have all their respective settings and all of that. These are five, six tools which exist. You just create the database here and you use any of these tools and you use the exports help from the migration service team to help you set up. They're trying to automate all of that as part of the cloud core service itself, which is part of the creation flow. So that is the project, meaning create database with data ingestion built in. And you can do this continuously as well. First, you ingestion data and you can continue to ingest more data. So that is a orchestration flow of all these tools which are abstracted for an end business outcome. And it's first class citizen inside of our service instead of being an external tool which you run with some specialist within cloud. That's the premise. Okay, other than the, oh, okay, say it, say it quickly.