oracle中如何脱敏,oracle 脱敏

静态数据脱敏有什么优势？

那我就以安华金和静态数据脱敏产品为例，简单介绍一下：

创新互联建站-专业网站定制、快速模板网站建设、高性价比休宁县网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式休宁县网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖休宁县地区。费用合理售后完善，十余年实体公司更值得信赖。

自动识别敏感数据，无须人工梳理

静态数据脱敏产品经过多年技术打磨与行业服务经验的积累，将大量敏感数据规则和识别算法内置于脱敏系统，具有识别准确率高、速度快等特点，节省了人工梳理敏感数据的工作，避免了由于人工梳理导致的遗漏。同时，灵活的自定义规则可以满足不同行业对各类敏感数据的个性化识别需求。

操作流程简单，脱敏性能更高

静态数据脱敏产品采用流程化的引导式操作，操作人员只需几步设置即可发起一个脱敏任务，在提升效率的同时降低对相关人员的技术要求。此外，脱敏任务的执行采用了多任务、多线程并行处理，大幅提高了数据脱敏的性能，缩短了数据交付时间。

支持常见及特定类型文件脱敏

静态数据脱敏产品不仅支持一般文件类型的数据脱敏，例如：CSV文件、TXT文件、Excel文件；同时，支持医疗行业常见文件类型的数据脱敏，包括XML、HTML格式的电子病历文件和DICOM格式的医学影像文件等；此外，系统还支持对Oracle数据库导出的DMP文件进行脱敏，并将脱敏后的数据写入目标数据库，或直接生成脱敏后的DMP文件发送给数据使用者。

通过集群部署，突破性能瓶颈

静态数据脱敏产品可采用多台脱敏节点横向扩展部署，由总控节点将脱敏任务拆分并发放至各脱敏节点进行分布式并行脱敏，从而突破单台部署的性能瓶颈。因此，当数据量大且对脱敏效率要求较高时，采用集群部署的方式可满足客户对于脱敏性能的要求。

API接口无缝对接，影响最小化

静态数据脱敏产品能够提供稳定、高效的API接口，可直接与客户已有的OA或ITSM系统实现无缝对接，在保证对现有管理流程影响最小化的前提下，实现系统的各项功能，以技术手段弥补管理中不易覆盖的“最后一步”。"

是一款具有高性能和高扩展性的数据屏蔽和脱敏产品，极力推荐他家~可以去百度咨询一下

身份证号脱敏处理一般隐藏哪几位

身份证号脱敏处理一般隐藏哪几位

身份证号脱敏处理，一般情况下是隐藏年月日那六位数字

1）、数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一。”

2）、本文介绍的脱敏数据报表查询将利用润乾集算器编写 SPL 脚本，对敏感信息字段 (如: 姓名、证件号、银行账户、住址、电话号码、企业名称、工商注册号、纳税人识别号) 等通过预定义的脱敏规则进行数据脱敏、变形，实现敏感隐私数据的保护。

3）、润乾集算器能使脱敏工作变得的简单易行，同时可以减少大量重复性工作。通过集算器 SPL 脚本实现的脱敏数据，可直接作为报表数据集进行查询分析，也可以作为开发、测试和其它非生产环境或外包环境下的真实数据集使用。

1.1 数据脱敏介绍

根据百度词条的解释，数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一，数据库安全技术主要包括：数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。”

随着信息时代的发展，我们对数据信息的安全要求越来越重视，比如对非生产环境下的敏感数据的脱敏保护。在金融、运营商、政府、能源等部门，非生产环境下数据脱敏已列入监管部门的法规要求。非生产环境数据多用于开发、测试、培训以及第三方数据分析、挖掘，如果不能有效实施敏感数据保护，极易造成敏感数据的泄露。所以，保证非生产数据的安全已经成为一个重要的课题，要求我们能够通过对敏感信息进行脱敏、变形，实现有效的数据保护。

1.2 对数据脱敏工具的要求

数据脱敏工具应该具有对多种异构数据源的支持，从而将一个脱敏规则应用于不同的数据源，比如针对“客户名称”字段的修改，脱敏规则基本一致，所以应该可以在 Excel、TXT、Oracle、MS SQLServer、MySQL、Hadoop 等数据源上直接引用。另外，工具还应支持将脱敏数据完全不落地分发，提供文件到文件、文件到数据库、数据库到数据库、数据库到文件等方式，并且不需要在生产系统或本地安装任何客户端。

本文介绍的脱敏数据报表查询将利用润乾集算器编写 SPL 脚本，对敏感信息字段 ( 如: 姓名、证件号、银行账户、住址、电话号码、企业名称、工商注册号、纳税人识别号) 等通过预定义的脱敏规则进行数据脱敏、变形，实现敏感隐私数据的保护。

润乾集算器能使脱敏工作变得的简单易行，同时可以减少大量重复性工作。通过集算器 SPL 脚本实现的脱敏数据，可直接作为报表数据集进行查询分析，也可以作为开发、测试和其它非生产环境或外包环境下的真实数据集使用。

1.3 脱敏数据的特征

数据脱敏不仅要执行数据漂白，抹去数据中的敏感内容，同时也需要保持原有的数据特征、业务规则和数据关联性，保证开发、测试、培训以及大数据类业务不会受到脱敏的影响，达成脱敏前后的数据一致性和有效性：

l 保持原有数据特征

数据脱敏前后必须保证数据特征的保持，例如：身份证号码由十七位数字本体码和一位校验码组成，分别为区域地址码（6 位）、出生日期（8 位）、顺序码（3 位）和校验码（1 位）。那么身份证号码的脱敏规就需要保证脱敏后依旧保持这些特征信息。

l 保持数据之间的一致性

在不同业务中，数据和数据之间具有一定的关联性。例如：出生年月或年龄和出生日期之间的关系。同样，身份证信息脱敏后仍需要保证出生年月字段和身份证中包含的出生日期之间的一致性。

l 保持业务规则的关联性

保持数据业务规则的关联性是指数据脱敏时数据关联性以及业务语义等保持不变，其中数据关联性包括：主、外键关联性、关联字段的业务语义关联性等。特别是高度敏感的账户类主体数据往往会贯穿主体的所有关系和行为信息，因此需要特别注意保证所有相关主体信息的一致性。

l 多次脱敏之间的数据一致性

相同的数据进行多次脱敏，或者在不同的测试系统进行脱敏，需要确保每次脱敏的数据始终保持一致性，只有这样才能保障业务系统数据变更的持续一致性以及广义业务的持续一致性。

1.4 数据脱敏应用场景

一般常见的数据脱敏场景，是将生产数据或是生产数据文件按照脱敏规则，将数据不落地脱敏至测试数据库或是测试数据文件中，具体如下所示：

使用集算器的 SPL 可以按照业务场景要求自行定义和编写脱敏规则，比如针对上面的人员信息：姓名、身份证号、地址、电话号码、卡号等进行不落地脱敏，满足数据脱敏需要。

集算器是一个无框架，可快速部署开发的数据计算中间件工具，能够直接运行编写好的 SPL 数据脱敏脚本即时进行数据脱敏，支持各种常见的数据脱敏的处理方式，包括数据替换、无效化、随机化、偏移和取整、掩码屏蔽、灵活编码等，本文介绍的数据脱敏方法都可以在实际应用中混合替换使用

遇到大规模oracle坏块该怎么处理

最近一两个月，一直有场景化运维、场景化大数据分析的声音围绕在耳畔，以Gdevops全球敏捷运维峰会杭州站上新炬网络执行副总裁程永新的“ 一切没有场景驱动的运维平台建设都是假大空！ ”最为振聋发聩。我们一直在谈技术，谈原理，谈内核，总以为“懂了”这些的人，就势必能广阔天地大有所为。

技术固然重要，但偏离了业务/应用场景的技术，无法呈现业务价值的技术就非常不重要。

技术也应该是场景驱动的，对于运维技术人员来说，离开场景学习的所谓高深技术，只是浪费时间。所以新同事进入一个新团队后，能使技术更好发挥作用的环境、流程的考核会占据了另外的三分之二。

今天来谈谈Oracle坏块问题。 坏块问题，相信做过两三年Oracle维护、支持的DBA都会遇到过，即使从来没遇到过的，看过Oracle 官方文档的甚至是会度娘或者谷哥的，应该也知道基本的处理手段。

这是我内部分享的一个简单思维导图，如果有遗漏，欢迎在后面评论补充。

面试的时候通常是这么问的：你了解Oracle坏块么？坏块为什么会产生？描述一下你处理过的坏块案例细节？如果你负责的好几个数据库都突然发生了坏块，你会怎么做？

通常，前面几个问题的回答都不会太差。但是最后一个问题的回答，鲜有能出众的。原因在于面太窄，思维太窄。如果这个时候你还要一个个库的去看alert日志，那么显然就走错了方向。

现实情况就是，我们的数据库可能是五六十套，或者上百套，你一套套库的去看这些日志里的报错的块，再根据块找到对象，确定是表还是索引，再去用坏块的修复手段去修复…….那么，所有人都会被你害了。

我们经历过，花了两天的时间，都没修复完一个库中几万个坏块的情况，在其他大牛还在哼哧哼哧做恢复的时候，我向领导提议启用了新的方案，在大老板没有完全失去耐性的情况下恢复了业务。

真正正确的做法是，如果确定坏块数量为数众多，赶紧停业务，切灾备，后面再补数据。 灾备是干什么吃的，养库千日，用库一时，就在这个时候了！

非常可惜的是，大多数来面试的DBA会非常纠结于用block recover，还是用dbms_repair，还是用BBED，还是……

那么，什么时候往上申报，要切灾备？

且不谈许多公司的灾备形同虚设，关键时候不敢切的事情。就算这些灾备都是实实在在可用的，恐怕也不是说切立即就能切的，切灾备涉及到应用、网络、主机、存储等多方面的调整。

那么多久应该切呢？ 一般的企业从故障处理开始，预估2小时之内不能让业务恢复正常运行的，应该申报切灾备。当然，如果是金融行业，特别是证券基金行业，1分钟之内故障还没恢复，就要知会证监会，半个小时没有恢复就会受到同行业通报，所以要切就应该在这个时间之内申报。

问题又回到了原点。你得先有规划，作为企业的重要系统，你得先建设灾备环境，而且是有效的灾备，并且应该事先有一个灾备切换预案。

作为DBA来说，动作敏捷的检查数据库的情况，并及时汇报非常重要。其实这里，又想说自动运维平台了。通过简单的按钮点点，就能快速知道告警日志里的坏块涉及什么对象，是不是就好很多呢？

继续往回看，面试的问题是什么？是多个数据库同时发现大量坏块。

作为一个经验丰富的运维管理人员，第一反应应该是，为什么会同时发生呢？显然是由于外因导致的。因此做好容灾切换，业务恢复使用的第一时间，应该去看看这些数据库共同的基础是不是同样的存储、同样的存储管理软件、卷管理软件。

依我的经验，大部分多个库同时出现坏块，都坏在存储管理软件身上。

有一次是Storage Foundation做卷复制的时候出现了软件bug，IBM、Oracle、symentec等众多厂家在“问题作战室”里整整呆了一个月，各家公司二线、三线出具各种证据自己没问题，最后最后才找到蛛丝马迹，揪出来。

还有一次稍微容易些，存储软件状态恢复后坏块没有恢复，一个个系统通过fsck命令来进行的修复。你说，这是什么类型的坏块呢？

作为有经验的DBA，要解决问题，但不要急着去敲命令，站在更高点的位置来看待问题，可能会事半功倍。

很不幸的前两天，某个朋友公司核心数据库“莫名奇妙”地遇到中止了。原因不方便说，但是据说等故障恢复完之后，朋友已经抽了好几包烟了。

我们先来看看，是由于LGWR终止了数据库（ 注：做了一些脱敏处理 ）。

但是，重启数据库却发现数据库启动不了，发现众多数据文件发生了坏块，数据库根本不能open：

同时伴随着类似的内部错误：

怎么破？通过当天的数据库备份结合归档进行恢复，远远比去修复坏块要快。