那是最好的时代，最糟糕的时代。。。正如Redditor"cscareerthrowaway567"所写，他/她最近在全国各地找到了一份令人兴奋的新工作——他/她的第一份工作——初级软件开发人员。一切都很顺利，直到上班的第一天。在遵循他/她的新团队的指示时，新开发人员无意中破坏了一个生产数据库。（阅读更多信息：https://redd.it/6ez8ag)哎呀！以下是一个小节选的第一手叙述发生了什么：我基本上得到了一份详细说明如何设置本地开发环境的文档。这需要运行一个小脚本，从一些测试数据创建我自己的个人数据库实例。运行命令之后，我应该复制命令输出的数据库url/password/username，并配置我的dev环境以指向该数据库。不幸的是，我没有复制工具输出的值，而是出于任何原因使用了文档中的值。不幸的是，显然这些值实际上是用于生产数据库的（为什么它们会记录在dev setup guide中，我不知道）。然后根据我的理解，测试会添加假数据，并在测试运行之间清除现有数据，这基本上清除了生产数据库中的所有数据。老实说，我根本不知道我做了什么，大约30分钟后有人发现/意识到我做了什么。现在，有很多事情促成了这场灾难：文档不足、明文存储的生产密码、防火墙限制不足等等，这些都不是这个可怜的开发人员的责任。但所有这些因素都只是真正问题的征兆：数据是沉重的。虽然数据的大小让您感到压力重重，但实际上是围绕数据分发和处理的所有因素都在阻碍您的业务：备份、恢复、掩蔽、刷新、归档、闪回、配置。时不时地，体重会压到你身上，这样的事情就会发生。在Delphix，我们让所有人都可以使用无重量的数据。安全。我们为开发人员提供访问数据的自助服务。通过简单的基于角色的访问控制模型，根据策略定义对数据的访问。开发人员应该只访问被屏蔽的数据吗？没问题。只需单击几下，cscareerthrowaway567就可以在他/她的环境中提供数据库的副本。这些数据只需几分钟就可以准备好，甚至可以达到万亿字节。他/她只需点击一下就可以重置或刷新他们的数据库。而且由于Delphix只从生产中读取数据，所以您已经将生产与数据请求（以及所有可能出错的事情）的影响隔离开来。事实上，Delphix通常被用来挽救类似cscareerthrowaway567事件的一天。最近在伦敦的一个Delphix用户小组，我召开了一个由世界三大银行组成的四个客户小组会议。这三家银行都表示，尽管他们现在使用Delphix进行应用程序开发和测试，但他们最初购买Delphix是为了恢复生产，因为开发人员和DBA在生产上犯了错误。为了结束这篇文章，我将给你留下一个关于甲骨文英雄和德尔菲斯用户鲍比·德雷特的故事，他是如何在德尔菲斯的帮助下度过这一天的。简而言之，一个批处理工作摧毁了美国食品公司5.4 TB数据库中的10张表。鲍比利用德尔菲斯在不到15分钟的时间内创造了一个复制品，整个事件在不到3个小时内就结束了，全靠他自己。下面是鲍比完整的一个接一个的链接。https://www.bobbydurrettdba.com/2014/07/08/used-delphix-to-quickly-recover-ten-production-tables/有兴趣学习如何保护生产数据（并保住你的工作？）请收听本月晚些时候的网络研讨会。在此处注册：https://pages.delphix.com/Production-Support-Webinar-registration.html生产支持网络研讨会日期：2017年6月29日时间：北京时间上午10:00演讲人：David Ruthven，Delphix高级解决方案工程师