“When I talk to IT and Dev teams, one of the areas that I see over and over again, is what we at Actifio call the “Big Database Problem.” The big database problem comes into the copies that are created for doing things like application development, release cycle of development and agile workflows that there are agile test data management workflows that we see. So, the biggest problem with the database is that as databases keep getting bigger and the time it takes to clone these databases takes longer and longer, it begins to affect the release of applications.
From there, either one of two things happens. Either the database is so big, it takes too long to clone, it breaks, it allows the developers and testers to be using data that is much older than what could be current. The other thing that we see here is that it could be very storage intensive. If I have a 10-terabyte production database and I make 10 copies of it, I’m going to be consuming 100 terabytes of capacity for that that data, that copy for those 10 copies of the production of 10-terabyte database, multiply that out across multiple databases as you could see that there’s a large storage problem.
The other thing that we see is that because application databases keep getting larger and larger, when there is a problem in production, how to do a recovery from it can also take longer. The recovery time objective gets much and much longer when you’re trying to restore a 10-terabyte or even a 1- or 20-terabyte database. So, the impact is, is that if this is a mission critical application that has a corruption, if it takes 10 to 20 hours to restore it, this can have a large impact to the business, especially if it’s the moneymaker of the business.
And then the other problem that we see is the databases in the Cloud, how do we get good cloud support? There is no agnostic solution from cloud providers to do simple cloning and recovery, so this also delays Cloud adoption when the tools haven’t matured as much.
The old way of doing database cloning is slow and costly, which I kind of touched on. No matter the database, when I have a one-terabyte production database, there is a process to create these development copies. Usually it’s a manual cloning process, either It could be done through scripting, or it could be done by a DBA, manually doing a backup, manually doing every store and export or import.
I mentioned the capacity utilization. Multiple copies are taking an additional eight terabytes of space on top of the production workload for a total of nine terabytes of storage usage, but if it takes me two or three hours to run through a manual restore of a one-terabyte database, or in some cases, it could be a whole day, if I’m having to provision storage or if I’m having to request an environment to use for this, including the storage, this time can take longer and longer as you’re having more people be part of the creation of a database copy. Sometimes, it’s not just the DBA, maybe it’s the system administrator, the SAN administrator, maybe it’s even the developer, because they need to run some post process to the database after it’s been created.
What we’ve seen is this old, slow way needs to have a better approach and this is where the use case that Actifio solves for. Actifio takes a one-terabyte production database. We do an application consistent database copy of these databases by interfacing with API with these applications and what this allows us to do is make a copy of a production database and that can be either be on the production side or the replicated side if you’re using SQL replication or using Oracle Data Guard or some other transaction log replication. We could do it from either location.”
The above was delivered by David Larson, Actifio Solutions Architect during a Pure and Actifio webinar on managing large databases.
Learn more about the very large database problem and how to solve it.