Hello everyone and welcome to our session. I increase your database productivity in Google Cloud. I'm Oliver Krause. I'm your host today. I'm a technicalmarketing engineer in the Google Cloud team at NetApp. Um, before we start some housekeeping. So this session will be recorded and you can get the recordings later on. And second, um, please use the, um, question button, question functionality ofzoom to submit your questions and we will answer them at the end in our Q&A session. So without further ado, let's get started. Hi, I'm Oliver and we talk about databases in Google Cloud on NetApp volumes. So what are we talking about? Databases in the end are files Um and,there are different kinds of files. So a typical database consists out of roughly three file types. One is the binaries whichis your executables, your configuration files, everything. Uh the database needs to start. So executables and configuration files, log files sometimes two or usually two. The other one is data. That's the database files themselves. So that's your database. And the third kind is log files. That's redo logs and archive logs. Because databases usually work in a way that they, um, keep a redo log of all the writes, which are going to a database and they keep, they write it into log files and um, they and from time to time they take all these changes and commit them to a database files, but most of the time the database files don't change and they are used in a read only mode and only after a certain amount of transactions queued up or are committed. They are written to the database files, and the log files give you basically a change history, like the undo or redo functionality inyour, um, in your office documents. And um, it's a smart move to separate these different kinds of, um, data types into different places. In the case of Google Cloud NetApp volumes, it makes sense to separate them into different volumes. Because if you do that, you can snapshot these volumes. And so these data types individually. And then you can do very interesting things. And let's talk about these things. But first let's talk about what snapshotting means if you're using NetApp volumes. NetApp volumes has a functionality to snapshot a volume individually. What is a snapshot? A snapshot is basically a photo of your filesystem you're taking. It's like you.take a photo of your filesystem and um, it,and like a photo, it's a freeze a time freeze version. And later after the volume changed, you can go back to that photo and look at it and look how your volume, the content of your volume looked like back then when you took the photo. So it's basically if you're taking multiple snapshots, let's say you take a snapshot every hour and do that for ten days. You will have ten that ten days time, 24 pictures with how your volume looked like in each of his hours. And later you can go back to these photos and look into them. And that's basically what snapshots are. And you can take them per volume. A single volume can hold a few hundreds of them. Taking them is near instantaneous. It takes a few seconds to do that. And each of these snapshots represents a full copy of a volume, not a copy. Not copy, not in a sense that the data is copied every time. But basically it means you can look into each individual snapshot and see all the data which was there. This the snapshots themselves only store the change data. So basically what you have, you have a volume with all your data in it. And then you have the change data stored in your volume. But you can have 100 views point in time views into your volume andaccess them instantaneously in a read only manner, but without having 100 times the capacity. It's basically you have the capacity once and then only a few. The data were changed for each of the snapshots. Another cool feature is you can revert the volume back to any snapshot like a time machine. Travel back in time and everything which happened later just disappears. So you can revert the volume very quickly back to a given state. Or you can take a snapshot and create a new volume out of it also within a few seconds. So that means you can create a clone of your volume within a few seconds, and have a full data set available in a new volume to do stuff on it, like testing. And that's all independent of a volume size. So it doesn't matter ifyou have a volume with 100 GB of data, or if you have a volume with a petabyte of data, the time it takes is nearly the same. And now let's talk about a few things you can do with it. So the first thing is super fast database backups. So what you can do is you can simply create a snapshot of your database and log volumes, and then you have a copy of the data the way it is when you took the snapshot. Um. You can revert back or clone your snapshots. I already talked about that. And you can create backups of your data. There is a special trick if you just create a snapshot. Um, basically, you take a photo of the way your database is currently on the disks, which means there is a high probability that your database is in a non consistent state because your database application might have Right data still a memory or it's not aligned to consistency points of your database. So usually a more elegant way is tomake your database consistent. Create a snapshot and then continue. And a lot of databases have functionalities to make your database consistent. For Oracle it's called backup mode. For example MySQL it's lock tables. And then later unlock tables. So typical operation is enter and the hot backup mode for your Oracle database. Create a snapshot takes a few seconds. Leave hot backup mode, and then you have a consistent copy of your database in your snapshot. And if you. Yeah, let's talk about restore in a second. So here is a picture of a process. So inthe first version. So you,freeze your database, you freeze it, you put it in hotbackup mode. You lock the tables. There are different terminologies depending on the database you're using. But the main idea is always the same, right? All the outstanding data to the disks. Make sure the database doesn't change the data on the file system anymore. The second step create a snapshot of your database and log volumes, and then unfreeze your database to have it continue with normal operation. A very short operation and the advantage is um, while in hot backup mode, a database usually runs less performant, so you want to minimize the time it is in that special mode in that special consistency mode. And thanks to snapshots you can go into that mode quickly, create a snapshot and leave that mode quickly again. So you run in edit mode for a very short time. Next, each of these snapshots holds a full, consistent copy a full, consistent backup of your database. So it's unlike other backup mechanisms where you have a full backup and then incremental ones. And then you need to stitch everything back together again, which takes time. Here, every snapshot basically reflects a full version of your database without consuming the extra space of the full version. So it's very space efficient. Since this operation is so lightweight, it's actually pretty easy to do multiple of these backups per day. Usually you don't take multiple backups per day because it's a heavy weight operation, which puts a lot of strain on your database systems and your disk backup system. Disk systems, your backup systems. This operation is super lightweight, so it's easy to do multiple of these, um, database backups per day, like, for example, every hour. As I already mentioned, restores or clones of huge databases can be done in a yeah, in under a minute cloning operation takes 1020 30s. So it's pretty fast. And, um, we only caveat is you still want to copy create a copy of your data on a different media because the snapshots live inside the volume. And if you delete the volume, you will also delete all the snapshots. So all your version history is it's no replacement for an for a traditional backup to a different media, but it actually ties in pretty well, because what you can do is you can create a snapshot based backup of your database, and then instead of reading the data from the database files and keeping the database maybe consistent during that, which takes a long time, you can simply go to your consistent snapshot and take the backup and read the data, the database data from that snapshot and write it to a different backup system. So it's pretty efficient. And by the way, NetApp volumes has a backup system built in which you can use to create such backups. So now we have consistent, super fast, consistent backups of your database. Now let's say we want to do a restore.Pretty simple. Shut down the database. Revert your volume to a good snapshot or clone the volume to a different volume and point your database to that new volume. Start up your database and then you're up and running with the consistent state the database had when then the snapshot was created, and then you can use redo logs and archive logs to roll forward to whatever commit you like. That's, by the way, the reason why you want to keep database and logs in different volumes. Because if you roll back the data volume, you don't want to roll back the log volume, because then you would lose all the log changes which are stored in the logs to roll forward. Next use case. We already talked about it is clones. So basically you have a consistent backup in a snapshot You want to create a copy of your database, let's say for testing and upgrade or for test dev. And with this technology, you can simply create a clone of that consistent database snapshot. You get a new volume and then you can start up a new database on that data. That means you can have a copy of your production data in under a minute to do stuff on it, which can be super valuable. So here you create a new volume from an existing database snapshot. You attach a new database to the volume to a new VM which runs a database application. You start your database done. Due to all of these properties, by the way, it's always a smart idea to create a snapshot based backup of your database before you do upgrades of your database. It's like an insurance. It's done super quickly. It doesn't hold up your, um, your upgrade process. It takes a minute or so and you have the insurance, but you always can go back to this good version if something goes wrong. So super convenient insurance feature for upgrades. With that, I'm already near to the end of my, um, webinar of. For the presentation part. We will come to the Q&A part in a minute. Um, for databases, for Oracle databases, um, we have here two very good, um, technical reports which, um, tell you how to deploy, uh, Oracle in a performant way for vldb implementations on NetApp volumes with Dataguard. And the other one is Oracle Clone Lifecycle Management with ASM on Google Cloud NetApp volumes. So two very good technical reports with a lot of details on everything you want to know and all the caveats to do andsome tuning tips. So very good documents. So finally, by utilizing consistent database snapshot backups, your backups become faster because you do them very quickly. More flexible because you can clone stuff. You can revert stuff and more granular because they are so lightweight. You can easily do more per day and improve your RPO and RTO. And with that, I'm done. And I'm asking my colleague Dean to first say hello and introduce yourself, and then see if we have some questions in the chat. Awesome. Thank you. Oliver. Yeah, my name is Dean Steadman. I'm a product manager here on the Google Cloud NetApp volumes team. Uh, and I'm helping Oliver today with the Q&A functions. Um, we do have a handful of questions that came in. Uh, and so for folks that are on the line, you can still submit those in. We're still addressing some of those via chat, and we'll answer them here as well. Um, so the first one that we have in for you, Oliver, is, uh, what databases, uh, can be backed up and cloned with this approach? Well, that's a good question. Um, so basically, I know what of all of the big ones. So I saw it happen, I saw it. I know how it's done for Oracle or DB2, MySQL, which is MariaDB. Um, two Postgres anda few others. It's usually easy for the Unix based ones For everything, which runs on windows. Like Microsoft SQL, there is one complexity attached which is making the file system consistent. So you can make the Microsoft SQL database consistent, but you also need to flush the caches. Um, or you need to flush.and caches. And that requires an additional um. Talking to additional Microsoft API. And that's a little bit more complex. Awesome, great. And then during the presentation you said the words super fast for our abilities here. Can you kind of quantify and define how fast and what type of time frames folks can expect where these operations. Yeah,Good question. So taking a snapshot of a NetApp volume takes ten 15 minutes. Not minutes. Sorry. Seconds.So something. Let's say something between five to 20s. It's a little bit depending on the API load. Um, so that'sandthat's independent of the volume size. So be it a super small volume or a multi terabyte volume with multi terabytes of data. So andthe rest of the time is basically how quickly can you get your, put your database into hot backup mode and later out of hot backup mode. And that depends on your database size the horsepower of your VM these kind of things. So these are more related to the horsepower on the client side versusthe time it takes onthe NetApp volume side. But overall, um, thesethings usually take the whole operation together. Takes in under a minute. Excellent. And then, uh, last question we've got in here to the chat. Um, we've got someone who's using database exports today, uh, to compressed files. Um, what can they gain by switching over to a snapshot and backup approach versus working withexports to compressed? Yep. That'salso a pretty good question. So we see a lot of customers who simply dump their database once or a few times a day to files and,then to save storage costs, they,compress them, zip them. And um, and that's,a way to do it. Basically the objective here is create backups quickly and save storage costs by compressing the,results. Um, if you and for such customers actually let me go back to um, this slide, actually changing that approach to a snapshot based has a few advantages. Number one is. Snapshots are pretty quick to do, you know. So if you want to create a point in time copy backup of your database. This is creating a snapshot which takes half a minute or so under a minute. Half a minute is much faster than dumping the whole database to a file system and compressing the data, which can take many minutes or even hours, depending on the data set size. Here this is consistently quick, so it's faster. And second, um, since snapshots only consume additional space for changed data. The only additional data you need is the data were changed in your database, which is usually pretty small. Let's say you have a one terabyte database and 1% of the data changes within a day, which is already a lot. Usually then you have 1% of a terabyte, which changed between the backups, and that's the amount of additional space you need. If you create a dump of the database so you take a terabyte, you create a database dump one terabyte, dumping a terabyte takes pretty long and you compress it. Maybe you end up with, let's say 300GB, which is already a good case due to compression. So that means eachbackup requires 300 gigabyte and every additional one, another 300 gigabyte and so on. And that queues up while here 1% of a terabyte is how much? 100GB. gigabytes, is it? No. Ten.gigabytes. So, um, basically, it's much more space efficient and faster to use snapshots to create this series of backups versus writing, um, database dumps to file storage. That was a long answer. I hope it's clear what I meant. It was, um, next question here. Is it possible to use SnapCenter with Oracle on Google Cloud NetApp volumes? Yep. Um, so SnapCenter is an is a software which, um, allows creating consistent database backups for various databases on NetApp storage. Um, so it'sbasically your go to approach to create that such consistent backups. Um, we SnapCenter today doesn't support NetApp volumes. That's in the making. So, uh, unfortunately, it's not available today and you have to go a manual way. Basically, like I, like I mentioned, by using database commands to get the database, um, consistent. Excellent. All right. That's the questions we have. Uh, in the chat. Um, we are just at the almost at the top of the hour here. I want to thank everyone forjoining us today. Thank you, Oliver, for the presentation. And, uh, we'll go ahead and end today's webinar. This will there will be a follow up email to the attendees, uh, that will come out with links to some of these resources. Um, and this recording will also be available on our website. Thanks again to everyone for joining. Have a good day.