(upbeat music) >> Hello everyone, and welcome to this Cube conversation. We're going to dig into some of the more specific and sometimes gory details of managing the nuances of database, database management systems. You know, it's a lot of fun to get it to the daily buzz of cloud and database competition and get a little snarky on Twitter, but there are a lot of mundane issues that you have to address to really do proper database sizing, capacity planning, and you know whether or not database consolidation makes sense. These are not trivial issues. And decades ago they spawned an entire role around the database administrator. They had to do the dirty work of database management so that users and customers would be satisfied. And while automation and cloud are changing that role, at the end of the day, somebody actually has to make the databases work in the cloud and make sure that the business doesn't feel any impact on the transition along the way. So on that note, we have with us Oracle senior director of product management for mission critical databases. He works in Juan Loaiza's group, Chris Craft, and Steve Zivanic whom we know well on the cube says this guy is the Jedi master when it comes to consolidating databases in the cloud. Nobody knows more on the face of the planet Earth. So we're really excited Chris, to have you inside the Cube. Welcome. >> Thanks, thanks Dave. >> That's a very humble thanks. So when it comes to running databases in the cloud can you explain the difference between sizing and capacity planning? Aren't they two sides of the same coin? >> Yeah, you know, they really are. It's like, you know sizing is really part of capacity to planning. It's really, I look at sizing as a one-time effort whereas capacity planning is more your ongoing. You perform sizing initially when the application is deployed. And then, then when you're changing platforms, like going from on-prem to the Cloud you're going to go through a sizing exercise 'cause you're looking at going to a new platform. That's more of a one-time effort, and then ongoing, you're looking at your capacity management over time. So yeah, they are very related so. >> Okay, thank you. So we're going to talk about database consolidation. A lot of people would say, look the cloud makes consolidating databases maybe not irrelevant, but maybe not the best strategy because I got all these different purpose-built databases. Why consolidate databases if they're already going to consolidate it in the cloud in one location? >> Yeah. So, so we're really talking about in in the cloud, you're running virtual machines but consolidation still applies on the virtual machines. So if you have a virtual machine that's dedicated to a database that database is that server, that virtual machine is going to be under utilized over time. So what we're doing with consolidation is running multiple databases within a virtual machine or what it, Oracle virtual cluster. We do everything on clusters. So multiple machines multiple databases within that will drive up the utilization and improve your cost structure. So it's a sizing it's it's absolutely critical on even in the cloud. >> Okay. But, but wouldn't it, I might say to that, wouldn't it be better to have each database have a dedicated VM? I mean, from a performance perspective, it doesn't try to make the database do too much affect performance. >> Yeah. It, so whenever, so we know historically that a database on a dedicated server back in the day that was a physical server, today it's a virtual machine. When you do that, your utilization will be in the range of 15 to 20%. And that's, you know very highly under utilized systems when you do that. So we don't need to isolate things onto dedicated virtual machines for a performance perspective. There are other ways that we can manage that we have resource management built into Oracle and the Oracle database. And then on Exadata we have an integrated IO resource management as well so we can deal with that different ways. >> Okay. So you're basically proposing that you're putting these databases onto a single VM and managing it accordingly. Is there additional details you can provide on that? >> So, you know, we don't put everything into you know, literally one, one VM. You want to have some isolation built in there, but see and take a more pragmatic approach. You know, like every single database in one VM that's the wrong way to go. Each database in a dedicated VM is also the other extreme, also the wrong way to go. So we're kind of right down the middle and be more pragmatic about it, and do some level of consolidation to drive up utilization. >> I remember when I first started following tech I was studying up on, you know kind of how disc drives work and so forth. And there was probably like I can't even remember what it was. It was like probably like 10 megabytes under an actuator. And people were saying, Oh my God, that's so much data. You, you got your blast radius is, is so big. You got to split that up. So it's the same concept, apply with availability. Some would say, there's a problem because you're consolidating all this data and you've got this blast radius that increases. How do you address that? >> And so, you know, redundancy. So we have redundancy at all levels. So if you look at a single, so we're talking about Exadata here, taught in an Exadata machine we can lose up to 24 disc drives out of 30. 30 machines with 36 disc drives, we can use 24 of those. So that'd be 12 per storage cell. You can lose two storage cells as 24 out of 36 drives so we can lose and keep on running. We can also, we also cluster, we also do clustering. So the database servers are clustered together for high availability. So we can take, we can suffer multiple simultaneous failures and keep on running without performance impact either. So it's, so recovery, we handle that in different ways. So it's, look at blast radius from a standpoint, you want some, some isolation for blast radius but we have physical failures is just not something that we're concerned with. >> Why do you deal with taking down a VM? Doesn't that normally mean there's going to be some kind of disruption? >> Oh, so you know, the, so Oracle database, you're talking about real application clusters on on Oracle database, on Exadata. We've got, we have a very fast detection of of failures and then resolution of the failure. So we're looking at a small blip in performance, you know we're looking at a few milliseconds to detect failure and then maybe up around three seconds to actually affect the failover. So the applications that are not getting disconnected, they continue operating in the, in that kind of condition. So that's kind of unique to the Exadata platform. And so, you know, in our cloud, we're running Exadata. We have this built in there. So we're, we're resilient to that type of failure, so. >> And sorry, you mentioned real application clusters. You're saying because you're running real application clusters that's how you're able to become more resilient? >> So yeah, so we have, so Oracle database real application clusters runs on top of a clustered virtual machines on Exadata. We have integration then optimizes the fail over times of that clustering. So it's, it's not the cluster same, it's the optimizations are only built into Exadata. So we have much much faster, much better tighter integration, so much more scalability because of that, that integration that we have. >> Can I run rack in other clouds? Can I put that into Amazon's cloud? >> So, so real application clusters requires two things. It's a, you require shared storage in a fast interconnect, a fast networking interconnecting. And those things just don't exist in the other clouds. We have those built into Exadata in our cloud. And we also, we also allow real application clusters in our relational database, our database cloud service offering as well. But it's, really the highest implementation of that is in Exadata. >> Well, of course I was tongue in cheek joking but this is, this is why, you know, I was listening to Arvind Krishna the other day in IBM Think. And he was saying only 25% of mission critical applications have moved into the cloud. I didn't think it's that high. I mean, but, but what you're doing is basically building a mission critical, you know, cloud or a cloud for mission critical databases. And that's, that's unique. I mean, I would expect other cloud vendors that eventually you know, are going to get there, but you're kind of starting with the hard stuff and working backwards. But, that is what I've always interpreted is unique to Oracle, but how does that affect cost? Isn't that more expensive? >> Actually, no. We're taking services that that start out at a very similar price point. And then we drive. So what we've seen from other customers that are running in like Amazon, for example, we see databases on dedicated virtual machines that run anywhere from 15 to 20% utilization. So what we do is, that low, low utilization, what we do is take that and triple that. So we run, so we run maybe 50% utilization. At that point we still have full redundancy, but we've now made the service one third of the cost. So we're starting at a third, we're starting at a very similar cost. And then we drive it to, you know three times a utilization. This is not crazy numbers. This is, you know, 50% is, is fine and retain the redundancy at that level as well. >> Got it, well so. >> What we've seen is about a third the cost. >> Really? Okay. Well, so, but, what about, like for instance, on AWS, couldn't I run this in a multi availability zone, running RDS or some other cloud database? >> So, so you can run a Multi-AZ environment like in in Amazon, for example, you can run locals. That's what we call local standby. If you do that, you're now instead of being one third, instead of being three times more expensive, you're now six times more expensive. Because that is another copy of the entire platform, the entire instance, the storage, everything on the other availability zone instead of being three times more, it's now six. >> Because you're essentially replicating everything in a brute force mode, right? >> Yeah. It's a data guard standby, local standby in another AZ, or what we call availability domain in our cloud. >> So let's maybe geek out a little bit. So, let's talk more about availability. You know, for years, I mean, I remember going back to reading about this stuff with tandem computers, you know, coincident failures. How are you dealing with those in today's modern world? >> So what we call simultaneous failures is, so we, we deal with that with redundancy in the system. So we have redundancy at all layers in the storage. Like I said earlier, we can take across, you know, two storage cells and each storage cell has a dozen drives. So that's 24 disc drives. That's eight flashcard failures simultaneously. And we keep on running no data loss, no loss of service. That's at the storage layer. We have multiple, multiple redundant networking switches at that, at the networking layer, the internal network. Then we go up into the database server. We then have redundancy across the nodes of a cluster. You have multiple virtual machines that comprise a virtual cluster. So it's at each and every level, we have redundancy. And then we drive the redundancy into the application using what's called application continuity. So the application connections have knowledge of the failure, failure modes of the database. They can follow to the surviving node, and continue operating. >> And you do this with math, you're doing some kind of magic bit slicing, or how do you do that? >> That, so that is that particular thing, application continuity, so technology that's been built into Oracle database since, since 12c, and that it's been around for quite a long time. And it allows the application to follow the rack cluster, any kind of issues with the rack cluster. We can drain connections off. It's very well-proven technology in, you know, prior to to proactive maintenance, we can drain connections over and then it will also handle a failure of a connection as well. And the application following that, yes. >> I learned from my old mainframe days and hanging around with David Floyer. It's always ask, what happens when something goes wrong and it's all about recovery. And you guys have the gold standard there. I mean, we've talked about this a lot. So you got Exadata. That's what is behind your Exadata cloud service, X8M I think you call it, and you've got autonomous database. I'm not great with model numbers, but, but talk about the way you can handle simultaneous failures. I mean, are there like triple redundancies that you've built in? >> Yeah. So everything what we do in our cloud is everything is triple redundancy by default. So we, you can suffer, that way we can suffer two failures and continue operating. So the, the other thing, so recovery, if you look at transaction recovery, when a failure occurs a transaction will flip that session, will flip to the machine that keeps running. It'll reposition all in the work that's in flight, any kind of inflight transactions, any in flight queries that are going on, reposition and continue operating. >> So you've essentially created like the old three site data centers, but you're in a single platform because you're synchronous. But, that same concept in a package. >> It's, you know, it's a lot of times you show a picture of an Exadata. It looks like a single box, but in the box there's some redundancy built in the box. And in fact, in the cloud it's actually across an entire aisle. So it's, we kind of obscure that a little bit, from your provisioning, you know, our database nodes and our storage cells and in the cloud but it's actually across an entire aisle of a dataset. >> Okay, and of course, that's within a synchronous location. Let's talk about disaster recovery, and what you're doing in that area, around Oracle Cloud What are my options there? What's different from other cloud providers we were talking earlier about, AZs, how are you different and what are you doing there? >> Yeah, so we, we talked earlier about the Multi-AZ deployment, what we call it availability domain, AD, so a little different terminology. But we can deploy another, another copy of the database into another availability domain, if you like. It's not often that you lose an entire AZ or AD, it's more, we're protecting from regional failures. So across another region. And that's where we look at, we really look at that as that technology, as a standby, as a data, disaster recovery solution not for HA. HA, we build HA into the machine itself. >> So you're saying, we were talking earlier about AZ, you're saying that's for HA versus DR. Is that, is that what you're contending? >> Yeah, like, you know again, pick on Amazon for a second here. Amazon uses a standby database. What we would normally use for disaster recovery, they're using that for availability. And you're looking at a few minutes of time to flip over to another AZ, whereas within an Exadata frame, we can flip over in milliseconds. We keep continue running. There is no loss of conductivity. And then we use the standby in another region for disaster. That's a true disaster solution. >> As opposed to incurring that penalty of latency, or whatever, to spin up the other resource. >> Right, right. >> Okay, so that's clear how kind of you guys address that, that challenge. Last question, maybe you could give us your take, again folks, coming out of Oracle's mouth, but what's the bottom line cost Delta based on your experience between your service and competitive services? I love these conversations because you're not afraid to talk about the competition, so bring it on. >> I've seen, so we've just based on what we've seen with customers deploying databases in Amazon, versus what, you know we've replaced that within, in our cloud service. We're seeing from just a list price perspective. Now, you know, we discount, I know Amazon discounts, but the only thing I can really speak to is list price perspective. It's about a third the cost. So we're talking about a more powerful platform, runs faster. We get these incredible, we haven't even talked about performance here. Talk about availability, performance where we're getting IO rates, IO latencies in the 19 microsecond range. Now with Exadata, that's going to be 50 times faster than what you get with these traditional cloud vendors. So much, much faster, and a third the cost. >> So talk about discounts, I mean, I know Oracle discounts, Oracle from list price, Oracle provides significant discounts. I'm not as familiar with your cloud pricing but I mean, Amazon's discounts are really in the form of like reserved instances. Is your pricing similar in that regard or different? I mean, if I'm just paying on demand, I'm paying through the nose. I presume it's same with you. If I, but if I buy in bulk getting a discount, is that what you mean by discount? Or is it more similar to the way you've traditionally discounted, you know large customers, the more you spend, the more you you get kind of thing. >> It's a, there's a discount structure. So it's, we don't have the same kind of lock-in like with reserved instance structure, but yeah, it's, there are discounts and that's going to be very customer specific. >> Right. >> So, but I think that the end result we're starting at, a three X differential on the price. >> But the reason I'm asking the question is that the stats you gave me are for list price, right? >> Yeah, yes, yeah. >> Okay, and sure, you're saying that at list price you're, you're less expensive. I, and again, my contention would be just by experiences that your discounts would be more aggressive traditionally in Oracle's traditional business. You know, I've done a lot of Oracle negotiation in my days. And if you're, you know, if you're a big customer you can get good deals. And again, I'm not as familiar with the cloud pricing, but still that's, that's good. If you're doing it on a list price basis, to me, that's a conservative statement if that makes any sense. >> Right, that's where it starts. We know that's where it's starting out. So I, you know, once you get into discounts, it's very customer specific. >> Right. >> We know the starting point is at three X differential. Before you do something in the Multi-AZ would be a six X differential, by the way, so. >> Yeah, okay. All right, Chris. Well, Hey, I appreciate you taking us through this, good stuff, and best of luck, good work. You know, you guys keep, I always say Oracle invest you guys spend a lot of money in RD and, and, you know you're quiet for a while in the cloud and all of a sudden you came out like you invented it. So good job! >> All right. >> All right, thanks. Thanks for coming on. All right. >> Thanks. >> Thank you for watching everybody. This is Dave Vellante for Cube conversations. We'll see you next time. (upbeat music)