Continuous Database Operations for Your DevOps Infrastructure

Hi, everyone. This John Pocknell. I'm speaking to you from Oracle OpenWorld 2019. And I'm going to talk about database DevOps. So what we're hearing from a lot of customers is their businesses are putting pressure on IT to deliver their database changes faster. Their applications are already moving to Agile The database is the bottleneck in the whole equation. And so what we're trying to do is help customers get their database operations into DevOps. How do we do that? Simple, automation. Automation is a way to take database processes like unit testing and code reviews and make them so they're repeatable, make them so you can automate them, make them so that you can call them from a build automation process the same way that application developers take their application changes into a build automation process. While we do this, we also consider the fact that we're making a lot of changes faster in the DevOps pipeline. And database changes carry a lot of risks because databases contain the business data. And so what we try and do, as well, is try to monitor those changes through the DevOps pipeline so the DBA can understand the consequence of these changes and what impact they could have on performance. Finally, we consider that, since we're moving the change into production a lot faster than before, we may need to replicate these changes out to other databases, like offload reporting databases, in the cloud, maybe. How do we do that? And so what we do is, we help these customers make these changes happen through our Toad product line, so Toad for Oracle, Toad DevOps Toolkit, is a way to take these development operations and transform them into automating processes so they can be brought into a build process. In terms of monitoring changes, we use our Foglight product line, our Foglight for databases. We'll be able to track these changes, determine the impact of these changes on performance before they get to production. Why is that important? Because a lot of times DBAs wait until they go to production. And then they find that some change happen that adversely affect your performance. So it's critical that these changes are picked up before they go to production. Performance testing is essential. DBAs know all about perform testing, but often times they find it difficult to actually implement a really good performance testing solution. So a benchmark factory is a way that you can take a database workload and replay it in a test database against the changes that are coming through your DevOps pipeline, to see if your changes will scale in production, very important. Finally, when it comes to moving data, no better solution out there than SharePlex. SharePlex can take your Oracle database changes that hit production and replay them straight away out to a reporting database, or a database in the cloud, or some other environment in pretty much real time. So really, from a Quest standpoint, we've got database DevOps for Oracle pretty much covered. If you want to learn more about how Quest can help you bring your Oracle database operation to DevOps, go to Quest.com/solutions/DevOps. Thank you for listening.