Archive

Archive for November, 2013

Data Simplicity

November 22nd, 2013

Complexity costs us a lot. Managing data in databases is a big chunk of that cost. Applications voraciously consume ever-larger quantities of data, driving storage spend and increased IT budget scrutiny. Delivering application environments is already so complex that the teams of experts dedicated to that delivery demand many control points, and much coordination. The flood of data and the complex delivery process makes delivery of environments slower and more difficult, and can lengthen refresh times so much that stale data becomes the norm. Complexity also grows as IT tries to accommodate the flood of data while their application owners expect Service Level Agreements, backup/recovery protections, and compliance requirements to remain constant.

What’s the result? Even our most critical projects can get behind schedule and stay there because delivery of environments is so slow. We find ourselves accepting and even anticipating production outages and their reputation risk because we just couldn’t test long enough on data that’s fresh enough or on environments big enough to find those problems before we went live. The cost and complexity of mobilizing our data to fewer platforms and datacenters has grown so high that we’re stuck year after year with a patchwork of datacenters, database versions, and old infrastructure draining already over-strained IT budgets. Our processes for data management are a patchwork, with no central point of control to provide the accountability and controls needed to insure compliance.

When we talk to the folks who support these applications, they tell us that data management is complex, and that’s the way it is. And, it’s not just these high visibility problems. We have a lot of highly paid experts that spend a lot of time copying, moving and babysitting bits for complex architectures like Business Intelligence or Master Data Management. The striking thing about many of these situations is that we don’t think there is a data management problem. We’ve concluded that data management must be complex.
But, that conclusion is the problem. And, instead of entertaining the idea that data management can be simpler, we find that many leading technologists and business leaders shake their heads and say, “We’ve got the best tools, the best technology, and the latest processes. Our data management problems just aren’t that extreme.” Really?

We recently deployed Data Virtualization technology for a company on its own internal MDM project. Now, that company is clearly expert at MDM, and they were certainly using the best tools and processes since they are industry leaders. They cut their own delivery timeline by 50%. We also deployed Data Virtualization technology for a fortune 500 Company with a large SAP implementation. Instead of delivering 2 similar sized SAP releases every 6 months, they are delivering 11 with the same team. Industry leaders are unlocking tremendous value because they are realizing that their processes can evolve and simplify, and the bottlenecks can be removed.

Will you experience the same benefits? Maybe. Maybe Not. But, you’d agree that ignoring that amount of potential value is always a wrong decision. Disruptive technology is never well understood at first, because the essence of disruptive technology is that it finds a lever that no one else can see to unlock value no one knew was there. It requires a new kind of thinking that will challenge the way we’ve managed data. Data Virtualization can help you reduce workloads, streamline data management processes, remove bottlenecks by pushing work closer to end users, reduce the critical path, shorten the application delivery cycle, deliver more features to market sooner, and gain competitive advantage. With Data Virtualization technology, we can massively simplify. And that’s where the value is.

Uncategorized

Why Data Agility is more valuable than schema consolidation.

November 20th, 2013

If you’ve been an Oracle data professional for any length of time, you’ve undoubtedly had a conversation about reducing your total number of databases by consolidating applications schemas from each individual database into separate schemas in one monolith database. Certainly, in the days before shared dictionaries, pluggable databases, and thin cloning this argument could be made easily because of the high price of the database license. Consolidation is a winning argument, but doing it at the cost of data agility turns it into a loser. Let’s explore why.

The argument For Schema Consolidation

Essentially, the pro-side of this argument is cost driven. Using 18 schemas in 1 database instead of 18 databases with 1 schema each means:
• Fewer database licenses – and this usually this holds true even if you use CPU-based pricing.
• Fewer hosts – even if you need a slightly larger host to handle the traffic, its usually cheaper than N individual hosts – especially when you consider the managed cost.
• Less Storage – The binaries and dictionary objects are often exactly similar, but we end up storing them on disk and in memory N times, and then backing them up to disk even more times.
• Less CPU and I/O – 18 databases simply require more CPU and I/O than 18 schemas in one database even if you push the same traffic to the 18 schemas.
• Less Database Management Overhead – fewer databases to manage means less time managing.

The argument Against Schema Consolidation

The con-side of this argument is very sensitive on conditions. In some cases, I’ve seen these cons really amount to very little cost and effort. In other cases, even without the newer technologies, the cost was so high that the approach was abandoned. Key things that usually cause Consolidation efforts trouble include:
• Namespace Clobber – especially when you are consolidating applications that weren’t designed that way, all sorts of namespace conflicts can arise. I’ve seen synonyms, links, and packages wreak havoc on a consolidation effort, sometimes even requiring large re-coding because of the nature of the beast.
• No Isolability – traffic, resources, and limits are no longer fully isolated. A lot of traffic to one schema can affect the performance of another. A huge update may rob you of the ability to get good response rates. A crash in one application can cause a domino effect – whether the fail begins at the database tier or the app tier. One failure affects all.
• Conjoined Backup and Restore – Often, the database is backed up as a collective, and restored as one. So, great care must be exercised when only a single schema related to a single app needs a restore. Of course, you can work around this by creating separate tablespaces for each schema, and then using tablespace PIT Recovery, but that itself takes time and resources.
• Risky Planned and Unplanned Outages – If you’ve got to patch the database, everybody goes down. If someone pulls the plug on your database host in the data center, everyone is hosed.
• Resource Pool Management Complexity – if you’ve only got one database, then you’ve probably got one storage pool. So, unless you’re very carefully carving and monitoring it (which itself takes time and resources), you can cause all sorts of unintended side effects.
• One Attack Surface – If 18 apps share a database, then they share an attack surface. An exploit against one is an exploit against all.
• More Management Headaches – A lot more focus, concern, and worry about Quotas, Security, backing up/restoring schemas, isolation measures, and control. This is such a headache that a lot of work has gone into automation.

The Tide has Turned

First, the benefits aren’t as strong as they used to be. The marketing around Oracle 12c provides ample evidence that the same amount of work over a collection of databases takes up 6x less hardware. Pluggable databases, or databases with shared dictionaries make the cost side of the equation significantly less attractive. Thin cloning technology neutralizes most of the rest of the equation as it provides a way to have copies of the database at almost no cost, virtually eliminating the storage argument.

Then there are the cons. And, this is where I content that we have systematically ignored or under estimated the value of Data Agility.

The value of Data Agility

Getting the right data to the right person at the right time is such a key value for organizations because there are so many obstacles to doing it. And, instead of understanding the value of agility, we’ve spent a lot of time, energy and effort finding solutions to minimize the impact of not having that agility. Like what, for example? Letting developers code on smaller sets of data OR live with older data OR write their own custom “rollback” scripts. Encouraging testers to accept the idea that a rewind has to take 8 hours, or that they have to wait for a refresh because they might clobber someone else’s app, or that they can’t test in their schema today because another application is at a “critical” stage. Telling BI folks that they can’t get their data refreshed because other apps can’t be taken offline, and it just takes too long to ship the whole schema over. Telling all of the apps that they have to be down like it or not because we can’t patch one schema at a time.

Using Schema consolidation saves money at the cost of data agility, and shifts the burden in ways where we’ve been trained not to miss it, or where we think it’s an IT problem.

Delphix thin cloning lets you keep your individual databases, but pay the price of a consolidated one. Developers can code on a full and fresh set of data at a fraction of the cost and never write custom rollback scripts again. Testers can rewind in minutes without having a huge resource drain, avoiding wait times mostly required to avoid secondary effects outside their app. BI folks never have to go offline to get fresh data, and refresh is a minutes long operation every time. Patch and Upgrade can not only be accomplished on a rolling basis, but using intelligent refresh, can be performed once and distributed to all sorts of downstream systems.

So what?

If you’re considering schema consolidation, look hard at the ROI. What used to make sense even 3 years ago is completely upside down now. Pluggable databases destroy the cost argument at the memory tier, and Delphix Thin Cloning does the same at the storage tier. Schema Consolidation just doesn’t make the economic sense it used to make.

Uncategorized

What Delphix does in 1 minute 22 seconds

November 17th, 2013

 

 

For a quick write up on what Delphix and database virtualizaition is , see http://www.kylehailey.com/what-is-delphix/

For a quick writeup on the use cases for Delphix and database virtualization, see http://www.kylehailey.com/delphix-benefits-in-brief/

 

Screen Shot 2013-11-17 at 2.27.05 PM

Uncategorized

Designing IT for Data Manufacture

November 16th, 2013

5711362355_82a57b08c0_z

photo by Jason Mrachina

As a (recovering) Mechanical Engineer, one of the things I’ve studied in the past is Design for Assembly (DFA). In a nutshell, the basic concepts of DFA are to reduce assembly time and cost by using fewer parts and process steps, making the parts and process steps you do use standard, automating, making it easy to grasp/insert/connect parts, removing time wasting process steps like having to orient the parts and so on.

In a meeting with a customer a couple of days ago, it struck me that out IT departments and increasingly our database and storage professionals have become very much like a database factory. What also become clear is that the processes that exist are cumbersome, expensive, and often burdened with low quality outputs.

Process complexity

If you think about the standard cycle to get a clone of a dataset provisioned in an organization, it can be long and expensive. There’s the process flow itself, which, although often automated, is also chock full of stop points, queues, wait times, and approvals. (At one major customer of mine on Wall St., a single request required 34 approvals.) Then, there are many decision points. For a simple clone, you might have to involve the project lead, the DBA, the storage team, the backup gut, the System Administrator, and in some cases even management just to get a simple clone made. And, each of these people has a queue, and has to decide how important your request is and if they have enough space and if there’s enough time, etc. etc. Then, even when it’s approved, maybe the Oracle RAC has a different methodology than the SQL Server, maybe we store our datasets locally whereas our sister application has to go get a backup from tape to use as a restore. All of this creates a process flow with lots of steps, moving parts, complexity, localizations and customizations, and potential for error and rework.

Principles of an efficient Data Factory

Considering IT as a data factory, we could apply the DFA principles to data and enumerate them as:
• Reduce the number of people, steps, and parts to get data clones provisioned.
• Simplify and standardize the steps that must remain
• Automated provision wherever possible
• Use standard Data Management Processes across data clones of all flavors.
• Simplify the process to connect data clones to the hosts and applications that need it.
• Encapsulate or eliminate the need for special knowledge to get a data clone to operate; Make it Dead Simple.

Delphix is the Data Factory

One great capability of the Delphix Engine is that it fulfills the tenets of an efficient Data Factory.

First, by automating 99% of the collection, storage, provision, and synchronization of data clones, it radically reduces the provisioning and refreshing process. Storage Administration often becomes a one-time activity, and provisioning or refreshing becomes a 3-click operation. Hours and Days (and sometimes even Weeks and Months) become minutes.

Second, it simplifies data clone management to such a degree that developers and even business application managers can build databases themselves – whether they are Oracle or SQL Server.

Third, in addition to radical provision and refresh automation, all of the housekeeping to gather change, integrate change, build snapshots, retain and release data, automate refresh are completely automated to such an extent that refreshing, rewinding, and restoring are also 3-click operations. And, doing things like a daily refresh for BI is a set-and-forget kind of operation.

Fourth, Data Management processes are standard across all flavors of supported databases. A refresh is a refresh. It shouldn’t matter to the end user that it’s a refresh for Oracle vs. a refresh for SQL Server or Postgres.

Fifth, by integrating with the mechanisms that let the database be ready for action (such as automatically registering with the Oracle Listener, or automatically applying masking scripts to make sure you’ve got obfuscated data to ship to your databases at Rackspace), the hosts and applications may not need to do anything except wait for the refresh to finish. No Request Necessary. No ticket to file. Nothing but fresh data in your database every morning ready to go!

Sixth, by encapsulating all of the difficult knowledge through automation or smart templating, it empowers a whole class of non-data professionals to perform their own Data Management. Letting Developers refresh for themselves completely takes the middle man out. No process needed at all.

So What?

If you’re a CIO, you may know that you’ve been operating your data factory like it’s 1965. You’ve been so far ahead of the game for so long that it has been inconceivable that there is a radically better way. That was the way that the American manufacturers thought before Deming and the other Total Quality Management gurus changed the way cars were manufactured in Japan. It’s time to bring your data factory into the 21st century. Stop trusting your data provisioning process to an outdated, overly complex, error-prone factory based on the IT organization of the 90s. Start trusting Delphix to deliver high quality database clones at much lower cost just-in-time for your needs.

Uncategorized

What Delphix does in 1 minute 22 seconds

November 15th, 2013

 

 

For a quick write up on what Delphix and database virtualizaition is , see http://www.kylehailey.com/what-is-delphix/

For a quick writeup on the use cases for Delphix and database virtualization, see http://www.kylehailey.com/delphix-benefits-in-brief/

 

Screen Shot 2013-11-17 at 2.27.05 PM

Uncategorized

Database Virtualization video and slides

November 15th, 2013

Had a great time at the East Coast Oracle (ECO) users group conference last week in Durham, NC.

Here are the slides

Here the a video  of my presentation on virtual databases as well as the slides.

 

For a quick write up on what Delphix and database virtualizaition is , see http://www.kylehailey.com/what-is-delphix/

For a quick writeup on the use cases for Delphix and database virtualization, see http://www.kylehailey.com/delphix-benefits-in-brief/

Uncategorized

Delphix Benefits in Brief

November 15th, 2013

Twitter question: “Can anyone give me a link to a very short itemized list of Delphix benefits?”

First,  short   summary: Delphix is the most powerful product to improve development output and quality in the 20+ years I’ve been working with databases. It improves development by eliminating the enormous infrastructure, bureaucracy and time drag that it takes to provision databases for development environments. Development environments depend on having a copies of production databases and Delphix allows provisioning in a few minutes with almost no storage overhead by sharing duplicate blocks among all the copies. For more info see

Now for an itemized list of use cases and benefits

Screen Shot 2013-11-15 at 11.25.42 AM

Development Acceleration

Screen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PM

accelleration

 

Discussion of development and QA bottlenecks and how Delphix and Redgate eliminate them 

  • QA environment builds branched immediately from prod  or dev. Simply branch a vDB from the development vDB in minutes.
    • Instead of spending 90% of QA cycle building environment and 10% running QA suite, spend 99% running the QA suite and eliminate almost 90% of infrastructure costs
    • QA  faster, find bugs faster, avoiding dependent code written over bugs reducing code rework
    • Use Case: Presbyterian Health eliminated 95% of QA time building QA environments
    • Use Case: KLA-Tencor improved SAP  project output by 5x principally because of the speed up in QA
  •  Many vDBs for developers
    • Every developer can get a copy of the source DB parallelizing development, avoiding contention on a single shared copy. Instead of waiting 1-2 weeks for code review of schema changes, developers can change as fast  as they want and development can use a merge vDB to integrate and QA the changes.
    • similarly parallelize QA by running many QA suites in parallel since environments are fast and cheap
    • Use Case: Large auction house gave all  developers their own copy of the DB doubling dev output
  • Full copies of source DB for QA and Dev
    • instead of using subset databases which require complex scripting to create and more importantly allow bugs to slip into production, use full copies
    • Use Case Stubhub estimates eliminating 20% of production bugs going from subsets to full vDB copies
  • Fast environment builds – biggest project delay is building environments
    • Create a culture of yes
    • Eliminate huge bottlenecks in projects
    • Use Case: many, customers have reduced time to make DB copies from 10 hours 10 minutes, from 10 days to 10 minutes, from 10 weeks to 10 minutes. One large global bank took 3-6 months to provision copies and now does it in 10 minutes.
  • Federated DB cloning: applications that use multiple databases and all DBs need to be clone at the same point in time
    • getting copies of multiple database at the same point int time is extremely difficult, but with Delphix one can pull in the sources at any time, once they are all in, they can all be cloned down to the same second within minutes in a simple UI with a timeline
    • Use Case: Informatica reduced a project from 12 months to 6 months using Delphix to clone their federated databases
  • Free up DBA DBAs can be project bottlenecks
    • Interface is easy. A junior DBA can provision databases for an entire company freeing up senior DBAs to work on innovation
    • Use Cases:  Macys went from 4000 hours/year of database copying by senior DBAs to 8 hours by a junior DBA
  • Self Service
    • Delphix interface is so easy that developers can provision their own databases.
    • Use Case: “Self-service is awesome; if they can get work done without opening a ticket, we’re winning.” – Kelsey Hightower via Gene Kim, author of The Phoenix Project
  • Branching vDBs
    • vDBs can be branched from vDBs
    • like source control for code its data control for databases
    • Use Cases:  immediate build of QA database by branching from Dev database
    • Use Cases: support multiple parallel development tracks. Comcast has 9 parallel development tracks on different versions of the applications.

 Quality

Screen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PM

diamond

 

  • Forensics
    • if a problems show up on production due to certain data sets and then disappear one can spin up a vDB in minutes of the production database as it was during the time of anomolie
    • Use Case:  large online ticket seller would see code anomolies when they released 60,000 new tickets for a football game, but the anomolies would go away as tickets sold. Didn’t want to let developers on production plus the problems would disappear. Now with Delphix they can spin up a copy of prod as it was during the problem and give it to a developer for investigation
  • Rewind for upgrade and patch testing and QA testing
    • one of the most stressful things for me as a DBA is upgrade and patching
    • with Delphix I can practice upgrade and patching as many times as I want until I’m sure of the procedure. I spin up a vDB, upgrade or patch, throw it way and do it again
    • For QA testing that requires setup, say credit card number obfuscation, that can be done once then destructive QA tests run and then I an rewind the vDB to just after the obfuscation work was done, then run the test again
  • A/B testing
    • allows me to create indexs on one vDB, drop indexs on another vDB, change init.ora parameters on anothe vDB and keep all these vDBs as I compare the performance
  • Surgical recovery
    • pull out data before a problem happened. Delphix keeps a multi week time window of changes from the source
    • Use Case: two days after a larger cable company installed Delphix, someone dropped the movies title table and 40 million subscribers couldn’t rent streaming movies. Dataguard applied the drop instantly as well, of course, it’s for HA failover. Going to a backup takes 8 hours, but they had Delphix and pulled out the table in minutes and put it back into prod
  • Automatic backup for developement databases
    • if development uses vDBs they are automatically backed up. Development often isn’t backed up because “they are just development databases”
    • Use Case: many examples of developers droping the wrong table, updating the wrong data etc. To recover we just branch vDB from just before the wrong command.
  • Physical recovery of source
    • If data files get corrupted on the source database they can be copied from Delphix
  • Backup 50 days of  in the size of the source database
    • example: 9 TB source database. When pulled into Delphix it’s compressed to 3TB. (average compression of 1/3). Now we have 6TBs left over before we even reach the size of the original database, but it’s not just 6 TB, but because of compression it’s 18TB  of changes we can pull in before we even reach the size of the initial database.

Business Intelligence

Screen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PMScreen Shot 2013-09-05 at 9.52.45 PM

MP900303009

  • Reporting database refreshes in minutes
    • instead of refreshing reporting once a night or once a week, they can be refreshed in minutes multiple times a day
  • Network traffic reduction
    • because Delphix only brings in changes from the source database and Delphix provides backup and reporting, Delphix basically eliminates huge saturations of network because of backups and reporting database refreshes
  • Temporal data access
    • being able to run a query in the past is often a powerful capability and often asked for by developers. With Delphix one can startup up a vDB as the source was yesterday, the day before, for the last 30 days etc and run queries and find the results in the past
  • Confidence testing
    • Ever change or optimize a massive reporting query and then wonder if that change was valid? It can be hard to QA that kind of change. One approach is building confidence. By startup vDBs over past X days and running the new query or report one can compare it to the old query or report and see if the correspond, building up confidence that the change was correct
  • 24×7 ETL windows
    • often ETL is only run in nightly windows when the load of the ELT job won’t impact production. These windows are becoming too small as data sets grow, jobs run longer and even more importantly as globalization happens and databases don’t even have nightly windows. With Delphix one can have a 24×7 vDB from the source that can be used for the ETL. The vDB is read/write as opposed to dataguard and active data guard allowing one to run reports that have to create temporary objects.

 

Performance

Screen Shot 2013-09-05 at 9.52.45 PM

  • Super caching
    • Delphix shares it’s memory cache across all the vDBs
    • If one vDB loads data in memory, it’s available to all the other vDBs
    • If one vDB caches entire database, then it’s cached for all the other vDBs
  •  Leveraging Flash arrays
    • Combining Delphix with Pure Storage showed same performance at 1/10 the price

 

Uncategorized

Theory of Constraints: the DBA

November 15th, 2013

 

9627525993_af43154455_z

photo Celestine Chua

“Do you think the great Skeeve has nothing to do with his time but guard your borders? Do you want to tie up your high-cost magician doing the job a low-cost soldier could do?” – Aahz, MYTH Conceptions by Robert Asprin

The book The Phoenix Project is the story of sorting out a company’s development and IT problems. In the book there is a character Brent. Brent is the go to IT guy who can fix things no one else can, like broken databases. Brent is also the bottleneck for required deliverables to move the company’s Phoenix Project forward. The Phoenix project is a make or break project. Either the Phoenix project succeeds and the company succeeds or it fails and the company goes down.

For the project to move forward there are very crucial deliverables, such as environment builds for QA and development. Without these deliverables the project gets blocked.

Brent is the gating factor on these deliverables and therefore the entire project.

Unfortunately Brent is used for all sorts of tasks. He’s like the go to guy for everyone.  Everyone’s requests turn into unscheduled interruptions and all these unscheduled interruptions cause delays in Brent delivering the crucial project deliverables for the Phoenix project.

Part of the book is how this crucial resource and bottleneck, Brent, is optimized. A clear first step of course is to take anything off his plate that someone else can do. Unfortunately much of what Brent can do, only Brent can do. One solution is to get Brent to train other people to do what he can do.  Couple of problems with that. One, Brent often doesn’t  know how he accomplishes some of the things he does (or so he says) and two, he doesn’t have time to train others because of the enormous amount of backlog and pressures to get the Phoenix project moving forward.

Now my question is this: if there is a huge, complex, time consuming task that only Brent can do, would you ever make Brent do it when there is an automated, self service solution that does a better job than Brent and can do it faster and be run by anyone?!

Of course not ! Right ?!

Well, wrong. It’s happening all the time. Companies are relying on expert DBAs to copy and clone massive databases over and over again.

DBAs are generally the most expensive resource in the IT department and often the hardest to justify because the business just doesn’t get what the DBAs do, but DBAs are crucial and foundational to companies. The business on the other hand only knows that it wants this data now and if the DBAs can’t give it to them then the IT department must be broken.

Speaking to companies like RBS, they said that DBA teams spend up to 50% of their time making database copies. Macys said their DBAs spend 4,000 hours a year making database copies.

But guess what. All that can be eliminated with database virtualization. Macys went from manual copying to database virtualization and reduced that 4,000 hours of expert DBA time down to 8 hours of Junior DBA time.

 

8456186741_437a7234a7

photo Steve Jurvetson

 

 

Uncategorized

Database Upgrade – What’s the Bottleneck?

November 15th, 2013

I met with a customer today who described for me the challenges they had in their previous 10g to 11g Oracle database upgrade. Their requirements boiled down to this:
• The business can’t afford a lengthy cutover time for the upgrade.
• The business can’t afford any data loss.
• They business had to be able to rollback the upgrade in the event of a fail.
• The 8-10 downstream systems need to be upgraded very quickly soon after.

To meet these requirements, they had to make a whole variety of difficult choices that exacerbated all of the limitations and bottlenecks that an upgrade can pose. Instead of upgrading their 10g in place, they had to make a full copy, upgrade that backup to 11g, figure out how to ship the changes from the old 10g to the new 11g during which both databases were essentially down. And then, once the cutover was complete, there was still the job of making a backup of the new 11g that could be used to create all of the downstream systems. They faced most of the typical bottlenecks of an upgrade:

1. For databases in the 5 TB+ range, the time it take to run a database upgrade can be significant.
2. An upgrade is typically a one-way transformation on a physical file system.
3. Downstream systems either go through the upgrade as well or have to be restored or cloned from the “new” database, which can be very expensive as well.

What’s the real bottleneck?

An Oracle database is just a collection of blocks. Even if you go from 10g to 11g, typically you’re only changing a few of those blocks in that database. And, the reason why we’re faced with choices such as upgrade or re-clone on our downstream environments is because we just don’t have the data agility to be able to rapidly reproduce the change – we are forced to pay a tax in time, copy, or transmission to make it happen. But, again, the real change in the data is very minimal. What’s the real bottleneck? Data Agility.

Delphix to the rescue

I like to think of a database upgrade as made up of 3 distinct process steps. First, there’s the rehearsal where you create copies of your existing database and rehearse the upgrades until you’re happy and secure that everything went well. Second, there’s the cutover where you either quiesce and convert in place or stand up a new target and quiesce and apply the delta to the new target. And, third, there’s the propagate where you take the newly minted environment and copy it around for Prod Support, Reporting, Dev, Test, QA, etc. to bring everyone up to the same version.

Delphix has several powerful features that cut through the noise and get to the data agility problem: Virtual-to-Physical, Any Point In Time Database Clones on Demand, Database Rewind, and upgradeable source and virtual databases.

Consider this same client’s situation if they had used Delphix. Since Delphix has on-tap a Near-Real-Time version of the database to be upgraded, and can spin up a copy of that database in minutes, it’s easy to reduce the cycle time of each iteration of testing. So, the big gorilla in the room – the time it takes to rollback and reset for each rehearsal – just goes away with Delphix. Second, if you’re using Delphix to virtualize all of the downstream copies of the databases, then they will take up minimal space BOTH before AND after the upgrade (again, since the upgrade typically doesn’t change more than a small %ge of blocks.) Third, if you upgrade your primary data source from 10g to 11g, then the operation to “upgrade” virtual downstream systems can literally be a couple of clicks and a few minutes.

So What?

In my experience, the vast majority of the time people spend on their upgrade projects is not for the execution of the actual upgrade script, it’s in fact mostly around migration and cutover – moving bits, synchronizing bits, etc. When you see these things as the Data Agility problems that they are – and find ways to optimize those operations with a tool like Delphix, then you realize that the only real bottleneck in the operation is the actual upgrade script – and that’s the one thing you can’t change anyway.

The power of this sort of approach to upgrading databases is significant. I can recall a customer who had put together an entire 6-week timeline to prepare, test, and execute their cutover of a large multi TB data warehouse. With Delphix, that entire operation was complete in 6 hours. With thin cloning from Delphix, you can remove bottlenecks related to your Data Agility, and focus on the true bottleneck and by so doing reduce your Total Cost of Data by delivering your upgrades faster at a fraction of the cost you pay today.

Uncategorized

Data Management from a Theory of Constraints Perspective

November 14th, 2013

1098176_10202046154420479_2047307696_n

When I read Eliyahu Goldratt’s the Goal in Grad School, one of the key things that stuck with me is that there’s always a bottleneck and that the process only moves as fast as the bottleneck allows it to move. The Theory of Constraints methodology posits three key measures for an organization: Throughput, Inventory, and Operational Expense. Sitting down to think about this, I reasoned that we could use those same metrics to measure the total cost of data for copies, clones and backups.

For every bit of data that enters the door through Production, we could offer that the Throughput represents the data generated to create or update the copies, clones and backups. Inventory could represent the number of copies of each bit of production data that sits on a copy, clone, or backup. And, Operational Expense represents all of the Labor and Resources spent creating and transmitting that data from Production to its final resting place.

When expressed in these terms, the compelling power of thin cloning is clear. Let me show you what I mean by a little Thought Experiment:

Thought Experiment

If I had a fairly standard application with 1 Production Source, 8 downstream copies, and a 4 week – Weekly Full / Daily Incremental backup scheme and a plan to refresh the downstream systems on average 1/week, what would the metrics look like with and without thin cloning?

TOC Metrics for Cloned/Copies/Backed-up Data

Throughput
8 * Daily Change Rate of Production

Inventory
Copies
8 * Full Size of Production
+
Backups
4 * Full Size of Prod (1/week for 4 Weeks)
24 * Daily Change Rate of Production (6/week for 4 weeks)

Operational Expense
Copies
8 shipments and applications of change data / day
+
Backups
1 Backup Operation/Day

With Delphix thin cloning, these metrics change significantly. The shared data footprint eliminates most of the shipment and application and redundancy. So:

TOC Metrics for Cloned/Copies/Backed-up Data using thin clones

Throughput
1 * Daily Change Rate of Production

Why?
Change is shipped and applied to the shared footprint once.

Inventory
Copies
1 * Full Size of Production (Before being Compressed)
+
Backups
28 * Daily Change Rate of Production

Why?
A full copy is only ever taken once. (Otherwise, it is incremental forever.)

Operational Expense
Copies
1shipments and applications of change data / day
+
Backups
0 Backup Operation/Day

Why?
Since change is applied to the common copy, backups are just redundant operations.

So what?

The thought experiment reflects what we see every day with Delphix. The Throughput of data that has to move through a system is significantly less (8x less in our experiment). And, it gets relatively more efficient as you scale. The Inventory of data that has to be kept by the system is not driven by the number of copies, but rather is driven by the change rate and the amount of change kept. Unless you are completely flopping over your copies downstream (in which case you have different problems), this also gets relatively more efficient as you scale. And finally, when it comes to Operational Expense, you’re not just getting more efficient, you’re actually eliminating whole classes of effort and radically simplifying others.

The bottom line here is that Data has been THE BIG BOTTLENECK for a long time in our applications. And, with thin cloning from Delphix, you’ve finally got the power to take control of that bottleneck, measure the true impact, and reduce your Total Cost of Data by delivering the right data to the right person at a fraction of the cost you pay today.

 

Uncategorized