Oracle视角:旁观某电信客户升级/迁移项目

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

本文永久地址:http://www.askmaclean.com/archives/oracle视角:旁观某电信客户升级迁移项目.html

 

 

  1. 不得已而为之的数据库升级和迁移项目

多年来,某省电信运营商虽然对其核心CRM系统进行了持续优化工作,但仍然满足不了业务高速发展需求,尤其是每月出账期系统压力越来越大,故障频频,以至于每当账期来临,局方各级领导、各业务部门和技术人员,以及应用开商和维护保障公司人员都是如坐针毡,甚至如临大敌。

在2015年下半年连续几个月账期均出现不稳定状况之后,各方一致认为数据库系统和应用软件优化工作已经持续了几年,优化空间已经非常有限了,是到了系统软硬件平台升级换代的时候了。

该系统现有硬件平台为HP PA-RISC小型机,数据库版本为10g R2,可见无论硬件还是系统软件都已经属于落后淘汰的技术了,现有硬件配置和性能甚至低于当下最新的X86服务器。作为Oracle公司服务部门,我们更是喋喋不休地讲述数据库升级到11g R2的必要性、可行性、方法论和风险控制策略等,特别是介绍了大量成功案例的实施经验。于是,领导终于下决心了!升级到11g R2并迁移到最高配置的X86服务器!项目实施周期确定为2个月,而且还横跨2016年春节!

本人无意点评领导决策的欠科学,甚至拍脑袋,其实我们深深理解领导的苦衷:已经连续优化这么长时间了,还是艰难度日,万一下个月账期系统彻底瘫痪,怎么办?

于是,尽管各方技术人员向领导和各业务部门力陈升级和迁移的难度和风险,但最后大家还是迫于业务压力,决定赶鸭子上架了!

 

  1. 麻雀虽小,五脏俱全

虽然项目实施周期非常短暂,但局方还是组建了由业务部门、应用开发商、运维团队等多方组成的项目组。在数据库迁移方面决定采用DSG公司的相关产品和技术,在应用测试方面也决定进行全面的功能和压力测试。喏,这就是该项目实施计划表的部分内容:

主要任务 序号 功能描述
准备工作 1 提供主机和数据库集成方案
2 梳理全场景测试方案
3 梳理系统所有的外围接口
4 统计梳理营业库中的所有表,按照表容量大小进行排名(刘书荣)。分析存储空间超过100m的表,若其为分区表,则继续细化到表空间,明确可以优先迁移的表。
5 梳理所有数据库主机的shell、C程序
6 梳理所有was主机的tns和数据源指向,提供上线时所有主机的tns和数据源修改方案。
7 梳理接口机的改造点。
8 梳理所有应用营业主机上部署的脚本,评估是否需要修改。
9 梳理所有应用账务主机上部署的脚本,评估是否需要修改。
10 梳理营业所有应用程序的配置文件和jar包,评估分析是否需要修改,包括BSS、爱营销(代理商)
11 梳理计费账务所有应用程序的配置文件和jar包,评估分析是否需要修改
12 梳理营业数据库所有配置表有无数据库IP指向,评估分析是否需要修改
13 梳理计费账务数据库所有配置表有无数据库IP指向,评估分析是否需要修改
14 梳理mq等内部接口改造点。
15 局方确认crm库上的job和dblink由应用开发商完成迁移
硬件部署 16 硬件到货
17 完成上架加电,达到可以交付实施集成标准
18 环境集成实施完毕,可以进行迁移工作
数据迁移 19 DSG队列规划,拆分复制同步范围
20 活动数据同步,活动数据部分,这里按照40%的数据量是静态数据估算,且按照6个并发任务估算,每小时能够导出的数据为250GB左右,CPU占用2个cpu,MEM为 1GB,IO资源估算为85MB/s。如果按现在CRM库的压力,我们建议使用1-2个通道来导出数据,可能时间上不能保障在2月14日前一定同步完成。
21 历史数据同步
测试环境应用搭建与联调 22 迁移应用开发商负责的数据库对象
23 数据库对象完整性核查
24 应用主机测试准备:将64主机从web页面群组拆下来,调整数据源和TNS指向,在主机上部署job、工作流、外围接口程序。
25 修改新搭建数据库内配置表
26 修改各个接口程序配置指向
27 在新搭建的数据库主机上部署shell、C程序进行测试;
28 调整测试环境MQ程序等内部接口配置指向;
29 调整账务测试环境dblink指向、账务主机TNS配置指向
30 协调oss、ocs配合测试
31 根据测试方案全流程测试
32 估算压力测试需要多少台主机,向局方提出申请,申请多台主机进行测试。

上述计划表由应用开发商主要从应用整体角度提出,尽管我们省略了原有表格中局方负责人、厂商负责人、预计完成时间等敏感信息,但大家还是一定能感受到升级/迁移项目的复杂性:硬件、网络、系统软件、数据库软件、应用软件… …面面俱到,一个也不能少,真是个庞大的系统工程。

数据由DSG迁移了,应用开发商负责应用功能和压力测试,作为Oracle服务团队的我们还能做什么呢?难道就是安装一下Linux平台的11g R2 RAC,然后提供一些现场技术支持吗?喏,这就是我们制定的Oracle服务计划:

 

序号 主要任务 功能描述
1 11g R2 RAC安装和配置检查和完善服务 负责2台新服务器的11.2.0.4 RAC软件安装,以及Oracle公司推荐的补丁安装,并基于Oracle最佳实践经验以及其它客户的实施经验,对数据库初始化参数和隐含参数进行检查和完善。
2 11g R2 RAC服务器的替换 通过RAC增加节点、删除节点操作,实现对RAC服务器的替换
3 性能优化和性能管理方案设计和测试 性能优化和性能管理方案设计,特别是11g SPA技术方案的设计和测试
4 正式环境上线前封装检查及性能基线收集 针对新建CRM系统,通过ORACHK等工具进行全面的配置检查和封版检查,并进行相应的完善,同时进行性能基线收集。
5 正式迁移和割接期间技术支持 新建CRM系统正式上线期间现场技术支持

 

可见,作为Oracle服务实施团队,我们的优势主要发挥在两个方面:第一就是在Oracle数据库环境安装和确保稳定性方面,包括11g R2 RAC专业化的安装、补丁分析和实施、初始化参数和隐含参数的设置等。第二个方面则是Oracle服务团队的另一个独特优势,因为我们深知升级和迁移项目最大的风险其实是来自于应用软件的性能衰减,而Oracle从11g开始推出了SPA工具,即通过该工具,可进行升级前后的应用性能对比分析,这样在测试阶段就能提前诊断出执行计划变化和性能衰减的SQL语句,并加以优化和改造,从而降低升级之后性能问题的出现概率,确保整个升级项目实施的成功。

各方不乏经验、方法论和人力资源投入,局方也提供了测试环境,但是大家都痛感最缺乏的只有一样东西:时间!时间!时间!在两个月的项目实施周期中,刨去春节假期,还有DSG的两次数据同步时间窗口(一次是将现有生产系统数据同步到测试环境,一次是正式割接前的数据同步),有效测试时间连一个月都不到!

 

  1. 艰难的测试过程

就在这一个月不到的时间里,各方要开展应用功能测试、应用压力测试,还有SPA测试。由于工期和项目计划组织问题,各项应用测试还与DSG的数据同步测试出现了时间上的重叠和冲突。于是,数据同步尚未完成,索引还未同步过去呢,压力测试和SPA测试就开始了,这些测试哪能跑得下去?于是,测试初期各方在不断磨合,尤其是解决各类数据同步问题,宝贵的测试时间又一点点流失掉了,真是欲速不达。经验啊!

测试期间正好横跨2016年春节,各方人员依然以饱满的工作激情、可贵的职业精神,协同作战,每天大家几乎都统一加班到晚上11:00,基本圆满完成了各类测试任务。作为Oracle服务团队,我们也第一次为该客户展现了SPA工具的价值:通过SPA测试,我们发现了若干条SQL语句出现了性能衰减,并加以有效解决,防止了这些问题在正式割接上线时爆发。

1个月的测试时间不知不觉就这么过去了。真是成也萧何,败也萧何。不久之后的正式割接期间的事实证明:大量的测试付出,的确有效地防范了各类问题的发生,但也正是因为测试时间太短,导致测试工作的不充分,尤其是当时对测试期间发现的问题没有深入探究,为正式割接埋下了深深的隐患!

 

  1. 惊心动魄的正式上线割接

大家在倾情投入了近两个月之后,终于以兴奋同时也是忐忑不安的心情,迎来了正式升级/迁移的割接上线日子。于是,各路神仙云集客户现场,本人作为旁观者也亲眼目睹了整个割接上线过程的跌宕起伏和惊心动魄。兴奋、刺激、纠结、无奈、痛苦、开心、喜悦、感慨,无数情感和心境在短短的2天多时间内不断变换,实乃精彩的人生写照!且听下面的娓娓到来。

上线第一天上午业务刚开始,似乎总体还算正常,但作为Oracle服务团队,包括我自己在内还是发现了一些SQL语句出现了性能衰减,好在我们已经有预案,例如多数语句的性能衰减是由于优化器改变为CBO之后出现的执行计划变化,于是我们采取了删除相关表统计数据,暂时回退到RBO的策略,留待事后再解决。事实证明,相比后面将要表述的系统层面问题,SQL语句问题仅仅是局部性问题而已。

就在第一天上午10:00多业务压力逐渐增加之后,我们首先获悉了前台应用反应非常慢的投诉,其次我们发现数据库服务器压力并不大,而在数据库和中间件层面均发现了网络问题,例如数据库服务器的公网延时居然达到了50ms!而私网也出现了丢包问题。由于硬件厂商网络工程师第一天晚上才能赶到现场,大家只能在等待、无奈、无助,甚至煎熬的心情中度过第一个白天,业务更是缓慢爬行了一整天。

事后我们回想起来,其实在压力测试阶段,大家已经发现了公网延时和私网丢包问题,甚至还导致了RAC宕机,但的确由于测试周期太短,这些问题都没有深入探究其根本原因,就这么带病上岗了。经验教训啊!

好在网络工程师第一天晚上赶到现场之后,很快诊断出网络问题,在调整、配置了几个网络参数之后,网络延时和丢包问题解决了。于是,大家又以轻松、期盼的心情迎来了第二天的业务。可是,这种愉悦的心情几乎是稍纵即逝,第二天上午随着业务高峰的来临,数据库服务器不堪重负,Top显示的Load居然达到500以上,IO Wait更是高达50%!经验告诉我们,IO Wait超过10%就不正常了,难道I/O压力很大,抑或存储系统I/O能力不够、配置不当?大家很快就否定了这些判断,而事实上数据库服务器中最消耗资源的根本不是Oracle进程,而是root用户下的CPU调度程序,这属于主机或操作系统层面问题,硬件厂商工程师在倾力分析和解决中,而第二天的业务比第一天更加艰难,全省CRM系统前端几乎完全瘫痪!

到了第二天日终,问题依然如故,领导终于做出了最简单,事后也证明是最有效的决策:换机器!于是,各方又开始通宵达旦地协同工作了,Oracle服务团队具体负责RAC环境下的删除节点、增加节点操作。我们的同事事后自我调侃道:我已经成了RAC增删节点的高手了!

第三天立竿见影了:一切都恢复正常!原来的数据库服务器硬件或操作系统到底出现了什么问题?我们作为旁观者,无权评述。但听局方系统工程师介绍,这是由于Linux处理中断机制跟UNIX不一样,大部分资源都消耗在处理中断上了,并发越大、处理越慢、越来越恶化。测试阶段是否出现过该问题呢?据了解,还真没有出现过,原因就是测试环境的硬件条件有限,没有模拟出生产系统的真实压力。经验啊!真实模拟测试的重要性!

 

  1. 更多的感慨

本人讲述完这个刚刚发生的惊心动魄的升级/迁移故事,无意渲染升级/迁移项目的高风险和难度,更不是要吓退那些对升级操作本来就心存疑虑和担忧的决策者们,而是试图通过这个真实案例的总结,大家来共同来感悟如下的经验教训:

  • Oracle数据库系统升级和迁移的确是一项机遇和风险并存的系统工程,战略上藐视,战术上重视是基本策略。也就是说升级/迁移项目肯定是能成功的,但科学的升级/迁移方法论指导、需求的全面分析、完备的技术方案和全面测试是项目成功的重要保障。
  • 我们虽然一直强调应用性能问题是升级过程中需要特别关注的问题,但相比主机、操作系统、网络等层面而言,SQL语句问题只是局部性问题,而系统层面问题却是全局性问题。任何一个全局性问题的爆发,都将是灾难性的。
  • 真实模拟测试、测试方法、测试手段的重要性,不要放过测试中出现的每一个问题。最后再重复一句名言:无论如何强调测试工作的重要性都不为过。

 

2016年3月27日于高铁上

ANA日本全日空航空公司Oracle 4节点RAC集群性能问题所引发的航空系统故障

 

 

ANA全日空是日本最大的航空公司,亦是世界上少有的五星级航空公司之一。全日空的主要机场位于成田国际机场、东京国际机场、关西国际机场及大坂国际机场。

 

ana01

 

在3月22日上午8:20开始由于系统故障,羽田、大阪以及福冈等地区的机场出现日本国内航线无法办理登机手续的问题。由此,一部分航线被迫取消,大量航班延误。

 

 3月30日、ANAホールディングス(ANAHD)傘下の全日本空輸は30日、22日に発生したシステム不具合を踏まえ、30日付で役員の報酬減額処分を実施したと発表した。全日空の篠辺修社長を1カ月20%、内薗幸一副社長と幸重孝典執行役員を10%の減額とした。写真は都内で2013年1月撮影(2016年 ロイター/Toru Hanai)

 

在ANA的记者会上已经发布了相关事故原因。因为全日本航空的系统故障,导致了刚刚结束节假日连休的机场陷入了混乱状态。

在当日上午11点半左右,系统修复完成。然后办理搭乘手续的业务也终于得以恢复。对此,全日空航空公司表示:“非常抱歉,给大家添麻烦了。”

根据全日本航空给出的数据,受到系统故障影响,羽田机场的航线总计取消116条航班。大约对一万五千人造成影响。

 

QQ截图20160406135309

 

全日空在上个月24号也同样出现了类似的问题,导致全国的机场约30分钟无法办理搭乘手续。

 

具消息人士指出本次的故障是由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致。而并非有网友指出的是ORACLE RAC心跳网络的交换器出现了故障而出现了ORA-29740错误。

 

有日本本土的消息人士指出此次故障时由于ANA的核心业务系统,一个4节点的ORACLE RAC中;由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致,导致其中一个节点出现严重的性能问题。运维工程师在接到系统告警和投诉后进入了慌乱状态,按照既定的故障诊断手册来修复也完全修复不好。于是到处打电话问对应方法,得到的回答也都与手册相同。

 

对于Oracle数据库你是否有这样一本故障诊断手册? 还没有?

下载 《ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册》: http://t.cn/Rq4BzBY

 

日本本土的网友对此次全日空的系统故障吐槽说:

 

这时,像我这样的系统工程师都会发出这样的感叹:”哎呀,出现这样的故障的话,现场估计乱得不得了吧?“(我想现场如今就像祭典一样,,系统工程师们要三天不眠不休进行修复工作。而且就算完成了修复,之后还有一系列的工作……)

实际上,比起影响,我更在意幕后的一些隐情。这时说起来可能有点不太准确,但我想,如今在系统故障现场还是一派繁忙景象吧。系统工程师倒是要多少有多少,但我想还没有哪个项目能像这次大故障一样如此繁忙吧。(受到此次影响的客人们也感到非常麻烦吧。)

现场状况用”祭典盛景“来形容是最好不过了。控制中心聚集了大量人员,几乎动员了公司内部所有战斗力量。再没哪次故障能汇集这么多人才了。(在此进行一系列会议,大家在白板上激烈讨论了故障过程、原因、以及修复对策。)

以往办公室都是比较安静的,但故障时,却是一片异样的繁忙盛景。经历过一次故障,系统工程师的能力可以连升很多级。由于大家目标一致,努力奋进于是就出现了这样的景象。(虽然善后要更加令人头疼……)

由此,这次的主题就是介绍系统工程师现场会遭遇的各种情况。

 

是否是系统供应商的人为失误!?

 

这次4台服务器同时终止的原因可能就是因为人为错误。

无论是硬件或者软件出现问题都不可能造成如此的故障。果然原因只可能是人为失误。报导中提到,“控制四台服务器的设备出现了故障”,可能还误操作了负载均衡器SLB。

果然无论最后是操作系统还是终止系统,最终还是人为使然。

无论对设备以及软件进行怎样的优化,也会由于人的使用方法以及使用顺序错误导致出错。并且,无论如何都需要定期维护,维护的同时也经常伴随着误操作的危险。当然,接触到系统的工作也都有一定的操作顺序,因为都会对其进行反复检查,所以基本不会有问题,但并不是不可能发生。

只要基于人来操作的话,无论如何都是会发生错误的。如果这样的失误重复多次,就会导致如这次一样的大规模的故障。

并不是我反复强调,而是系统的确是无法避免地会出现故障。

当然,我们每天也在为了不再出现这样的情况而努力着,但仅凭现在的技术水平来说,还是必须要人工操作的,所以还是必然会有类似故障发生。

我希望大家能够理解,不理解现状,却一味地抨击系统工程师“不像话”的无知评论家以及无良媒体是多么可恶。我对媒体和评论家这些人一提到就开始批判的态度也是实在没有办法,想说什么就说什么,明明自己没有一点点相关知识。

即使修复了系统故障也不会就此终止

我认为,作为全日本航空的系统供应商应该会非常头疼,希望他们好好努力啊。因为即使修复了故障,之后的善后工作也非常麻烦。

修复了基础层的系统后,应用团队就登场了。由于系统故障,需要确认的问题实在太多了:数据状态如何?现有数据是否完好?是否可以继续进行业务?等等等等。

估计至少得通宵达旦2-3天吧。之前提到过的不可思议的祭典状态还将持续。不仅是修复工作最集中的时候,其他时候系统工程师也必须时刻保持昂扬的战斗状态。

之后,就需要检讨这次故障的对策以及开始道歉了。

虽然我们都认为系统故障是不应该发生的,但还是希望大家能够理解,系统是不可能永远不发生故障的。希望大家做的不仅仅是谴责,也不要认为系统正常运行是理所当然的。但这次的故障影响波及范围实在太广泛了,这也是我们必须反省的。

 

 

PRM-DUL终极Oracle数据库恢复工具

PRM-DUL 下载地址:http://7xl1jo.com2.z0.glb.qiniucdn.com/DUL3206.zip

诗檀软件自主开发的PRM-DUL可以脱离Oracle数据库软件实例的存在直接读取Oracle数据文件datafile中的行数据和LOB等大对象。

当你的数据库因为ORA-00600/ORA-07445或其他ORA-报错,或丢失关键的system表空间数据文件,或ASM diskgroup损坏时均可以考虑采用PRM-DUL来做恢复。PRM-DUL采用独创的DataBridge恢复技术,直接从数据文件中抽取数据后可以像DBLINK那样直接插入到新建数据库中,而无需数据落地成为DMP文件占用空间。

经过诗檀软件4年的研发改进,PRM-DUL的功能已经十分完善,且因为其采用全称GUI图形化界面的方式,对用户而言学习成本非常低,可以说从头到尾只需要点鼠标即可。支持从Oracle 7.3.4到Oracle 12c的所有版本数据库。

到目前为止已经有多大十多个国外企业级别用户购买PRM-DUL 作为其终极恢复工具,所恢复的数据超过100TB。同时也有单库超过10TB的使用例子,这得益于PRM-DUL 内置了小型嵌入式数据库,当索要恢复的ORACLE数据库很大时,PRM-DUL采用嵌入的数据库来存放找到的ORACLE 源数据,这样可以对源数据做索引和灵活的查询。

PRM-DUL软件由诗檀软件自主研发,研发团队自行研究了Oracle datafile的数据结构同时也参考了ORACLE RDBMS数据库软件的内核代码,研发团队具有基于Oracle Kernel内核代码二次开发的技术能力。

欢迎技术合作!

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 400-690-3643 备用电话: 13764045638 邮箱:service@parnassusdata.com.

 

Oracle DUL_PRM_重建对象实验报告

PRM-DUL抽数据

 

也是就只导入EASKINGDEE用户下,以”T_GL”开头的表:

有70张表被导入,但是其中也就28个表有数据,各个有数据的表的行数和dul的结果是一样的。

 

prmz21

 

SQL> exec

dbms_stats.GATHER_SCHEMA_STATS(OWNNAME=>’test4′);

select table_name,num_rows from user_tables order by num_rows desc;

结果如下:

prmz22

 

4.2 重建database link

 

SELECT ‘create ‘||DECODE(U.NAME,’PUBLIC’,’public ‘)||’database link ‘||CHR(10)

||DECODE(U.NAME,’PUBLIC’,Null, U.NAME||’.’)|| L.NAME||chr(10)

||’connect to ‘ || L.USERID || ‘ identified by ‘

||L.PASSWORD||’ using ”’ || L.host || ””

||chr(10)||’;’ TEXT

FROM link$ L, user$ U

WHERE L.OWNER# = U.USER#;

没有返回行,说明没有database link

4.3 重建synonym

 

SELECT ‘create or replace ‘ || decode(o.owner#, 1, ‘ public ‘) ||

‘ synonym ‘ || decode(o.owner#, 1, ”, u.name || ‘.’) || o.name ||

‘ for ‘ || s.owner || ‘.’ || s.name|| NVL2(S.NODE,’@’,”)||S.NODE|| ‘;’

FROM SYN$ S, OBj$ o, USER$ U

where s.obj# = o.obj#

AND o.dataobj# is null

and s.owner=upper(‘EASKINGDEE’)   and u.user# = o.owner#

没有返回行,说明没有synonym

4.4 重建 view

 

select

‘CREATE OR REPLACE VIEW ‘||O.NAME||’ (‘||

replace(c.cols,’,’,’,’||chr(10))||’)’||CHR(10)||

‘as’||chr(10), v.text

from

user$ u, obj$ o, view$ v,

( SELECT COL.OBJ#, COL.COLS

FROM

(SELECT

OBJ#, COL#, substr(SYS_CONNECT_BY_PATH(NAME,’,’),2) COLS

FROM COL$

WHERE COL# > 0

START WITH COL# = 1

CONNECT BY PRIOR OBJ# = OBJ# AND PRIOR COL# = COL# – 1 ) COL,

(SELECT OBJ#, COUNT(*) COLCNT FROM COL$

WHERE COL# > 0 GROUP BY OBJ#) CN

WHERE COL.OBJ# = CN.OBJ# AND COL.COL# = CN.COLCNT

) C

where u.user#=o.owner# and o.obj# = c.obj#

and v.obj# = o.obj# and u.name=upper(‘EASKINGDEE’);

 

 

结果如下

prmz23

重建job

 

select job,LOWNER,INTERVAL#,next_date,WHAT,SCHEDULER_FLAGS from job$

prmz24

重建index

 

 

SELECT

‘CREATE ‘||decode(bitand(IDX.property, 1), 1, ‘UNIQUE’, ”)||

‘ INDEX ‘||I.NAME||’ ON ‘||T.NAME||'(‘||IDX.PATH||’);’ INDEX_DDL

FROM

USER$ U, OBJ$  T, OBJ$ I,

(

select I.PROPERTY, I.BO#, I.OBJ#, C.POS#,

SUBSTR(sys_connect_by_path(CN.NAME,’,’),2) path

from IND$ I, ICOL$ C, COL$ CN

WHERE I.OBJ# = C.OBJ# AND I.BO# = C.BO#

AND I.BO# = CN.OBJ# AND C.COL# = CN.INTCOL#

start with C.POS#=1

connect by nocycle PRIOR I.OBJ# = I.OBJ#

AND prior C.POS# = C.POS# ) IDX,

(SELECT I.BO#, I.OBJ#, COUNT(*) COLCNT

FROM ICOL$ I GROUP BY I.BO#, I.OBJ# )  IDXC

WHERE

U.USER# = T.OWNER# AND

IDX.BO# = T.OBJ# AND

IDX.OBJ# = I.OBJ# AND

IDX.BO# =  IDXC.BO# AND

IDX.OBJ# = IDXC.OBJ# AND

IDX.POS# = IDXC.COLCNT AND

u.name=upper(‘EASKINGDEE’)

ORDER BY T.NAME, I.NAME;

结果如下:

prmz25

重建trigger

 

select

‘CREATE OR REPLACE TRIGGER ‘|| trigger_name || chr(10)||

decode( substr( trigger_type, 1, 1 ),

‘A’, ‘AFTER ‘, ‘B’, ‘BEFORE ‘, ‘I’,

‘INSTEAD OF ‘ ) ||

triggering_event || ‘ ON ‘ || table_owner || ‘.’ ||

table_name || chr(10) || REF_CLAUSE || chr(10) ||

decode( instr( trigger_type, ‘EACH ROW’ ), 0, null,

‘FOR EACH ROW’), trigger_body

from  (

select trigusr.name owner, trigobj.name trigger_name,

decode(t.type#, 0, ‘BEFORE STATEMENT’,

1, ‘BEFORE EACH ROW’,  2, ‘AFTER STATEMENT’,

3, ‘AFTER EACH ROW’,    4, ‘INSTEAD OF’,

‘UNDEFINED’) trigger_type,

decode(t.insert$*100 + t.update$*10 + t.delete$,

100, ‘INSERT’, 010, ‘UPDATE’, 001, ‘DELETE’,

110, ‘INSERT OR UPDATE’, 101, ‘INSERT OR DELETE’,

011, ‘UPDATE OR DELETE’,

111, ‘INSERT OR UPDATE OR DELETE’,

‘ERROR’) triggering_event,

tabusr.name table_owner, tabobj.name table_name,

‘REFERENCING NEW AS ‘||t.refnewname||’ OLD AS ‘||t.refoldname REF_CLAUSE,

t.whenclause,decode(t.enabled, 0, ‘DISABLED’, 1, ‘ENABLED’, ‘ERROR’) STATUS,

t.definition , t.action# trigger_body

from obj$ trigobj, obj$ tabobj, trigger$ t,

user$ tabusr, user$ trigusr

where (trigobj.obj#  = t.obj# and

tabobj.obj#    = t.baseobject and

tabobj.owner#  = tabusr.user# and

trigobj.owner# = trigusr.user# and

bitand(t.property, 63)    < 8 ))

where table_owner=upper(‘EASKINGDEE’)

order by owner, trigger_name

 

没有返回行,表名在用户EASKINGDEE下的表上没有触发器

4.8 重建sequence

 

SELECT

‘CREATE SEQUENCE ‘|| SEQ_NAME ||

‘ MINVALUE ‘||minval ||

‘ MAXVALUE ‘||MAXVAL ||

‘ START WITH ‘||LASTVAL ||

‘ ‘ || CYC || ‘ ‘ || ORD ||

DECODE(SIGN(CACHE), 1,’ CACHE ‘|| CACHE, ‘NOCACHE’) ||

‘;’ SEQ_DDL

from

(select u.name OWNER, o.name SEQ_NAME,

s.minvalue MINVAL, s.maxvalue MAXVAL,

s.increment$ INC,

decode (s.cycle#, 0, ‘NOCYCLE’, 1, ‘CYCLE ‘) CYC,

decode (s.order$, 0, ‘NOORDER’, 1, ‘ORDER ‘) ORD,

s.cache, s.highwater LASTVAL

from seq$ s, obj$ o, user$ u

where u.user# = o.owner#

and o.obj# = s.obj#

and u.name=upper(‘EASKINGDEE’))

 

没有返回行,表名在用户EASKINGDEE下的表上没有序列

4.9 重建procedurce

 

SELECT DECODE(S.LINE,1,’CREATE OR REPLACE ‘ )||SOURCE SOURCE

FROM

USER$ U, OBJ$  O, SOURCE$ S

WHERE

U.USER# = O.OWNER# AND

O.OBJ# = S.OBJ# and U.NAME =’EASKINGDEE’

ORDER BY S.OBJ#, S.LINE;

结果如下:

prmz26

诗檀软件与 Solix 合作大数据项目

诗檀软件与 Solix 合作大数据项目

中国领先的数据库服务公司,基于Apache Hadoop的平台,提供信息生命周期管理(ILM通用数据平台和先进分析。

 

2016 — Santa Clara, Calif. — Solix Technologies, Inc.,  Solix Technologies,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商在今天宣布,中国的数据库服务公司诗檀数据已经选择了Solix的大数据套件,基于Apache Hadoop进行交付归档,应用停用和先进分析。

 

Apache Hadoop是ILM的理想平台,因为它为企业级数据提供了高度可扩展,低成本,大容量存储。诗檀数据将为客户提供Solix的大数据套件,以提高应用程序的性能,降低成本,并满足管理,风险和合规性要求。Solix的大数据套件作为企业共同的数据平台,对大型数据集的结构化和非结构化数据进行高级分析。

 

“Apache Hadoop作为一个通用数据平台,是先进企业分析和ILM应用的理想工具。” John Ottman,Solix Technologies, Inc执行主席说道。“我们非常期待与诗檀数据在大中国区市场的合作。”

 

Solix是目前唯一一家为所有企业数据提供全面的信息生命周期管理(ILM)解决方案的供应商。我们很幸运在中国有这样强大的合作伙伴,诗檀数据CEO Maclean Liu说道。

 

要了解有关Solix大数据套件的更多信息, 点击这里

 

关于Solix Technologies

Solix Technologies, Inc.,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商,通过其优化的基础设施,安全保障和先进分析,帮助企业管理自己的企业信息。 Solix Big Data Suite 是一个ILM应用解决方案架构,包括 Enterprise Archiving Enterprise Data Lake,  Application Retirement, Database Archiving, Test Data Management (数据库子集)和 Data Masking。 Solix Technologies, Inc. 总部位于美国加州的圣克拉拉,通过增值经销商(VAR)和系统集成商构建的网络遍及全球。要了解更多信息,请访问 www.solix.com

 

关于 Parnassus Data

Parnassus Data 是位于上海的一家Oracle 数据库服务公司,提供数据库开发,实施,管理和紧急支持服务。诗檀数据是数据库优化和监控工具开发方面的专家,同时也为Oracle数据库用户提供远程和现场服务。

 

联系 Solix

访问我们的网站:http://www.solix.com

在Twitter上关注我们:@solixedms

加入我们的Facebook: http://www.facebook.com/solixtechnologies

 

媒体联系

Jessica Hasson

PulpPR for Solix

jessica@pulppr.com

Oracle PRM-DUL Undelete Oracle record/rows

Download PRM-DUL http://www.parnassusdata.com/en

On scenarios without valid physical or logical backups, when a mistaken delete occurred in Oracle, it will be given priority to use techniques such as flashback or logminer to recover the data rows in Oracle tables in general, but in many cases even flashback or logminer could not turn the tide.

For the row piece in the underlying data block of Oracle, delete operation only modify the row flag and mark them as deleted. It allows records of the subsequent INSERT to override these data marked as delete, and also allows to destroy the structure of these data that are deleted. In other words, if no operations has been done on tables after delete, it is possible to read the complete data by directly reading those records that are marked as deleted in blocks.

 

In a word, whether it can recover the deleted data or not all depends on whether the deleted data rows in oracle block on the disk have been eventually cleared or not.

 

As soon as it has not been cleared, ORACLE PRM-DUL can attempt to recover the data, and the specific steps has little difference with the ordinary data dictionary mode.

 

Start up the PRM – DUL, click the restore wizard in dictionary mode
 

prm-undelete1

prm-undelete2

 

 

 

prm-undelete4

prm-undelete5

 

Add all of the Oracle data files, no TEMPFILE, UNDO data files, control files, log files is required.

prm-undelete6

 

Click the load button, PRM will automatically load the data dictionary, i.e. bootstrap operation

 

prm-undelete7

ow on the left of PRM, you will see the object tree, select the corresponding data table under the user that you need to recover, right-click the object and then select unload deleted data.

prm-undelete8

 

prm-undelete9

After completing the recovery of the deleted data, PRM-DUL will write the data to the location of File path in the picture above, the Sample data recovery is as follows.

prm-undelete10

 

Parnassus Data Partners with Solix for Big Data

solix1

Leading Chinese database services company to offer common data platform for Information Lifecycle Management (ILM) and advanced analytics based on Apache Hadoop.

2016 — Santa Clara, Calif. — Solix Technologies, Inc.,  Solix Technologies, the leading provider of Information Lifecycle Management (ILM) solutions for Apache Hadoop, announced today that Chinese database service company Parnassus Data has selected the Solix Big Data Suite to deliver archiving, application retirement and advanced analytics on Apache Hadoop.

 

Apache Hadoop is an ideal platform for ILM because it offers highly scalable, low-cost, bulk storage for enterprise data. Parnassus Data will offer the Solix Big Data Suite to its customers to improve application performance, reduce costs, and meet governance, risk and compliance requirements. As a common data platform for the enterprise, the Solix Big Data Suite provides advanced analytics against large data sets of structured and unstructured data.

 

“As a common data platform Apache Hadoop is ideal for advanced enterprise analytics and ILM applications, “ said John Ottman Executive Chairman at Solix Technologies, Inc.. “We look forward to working with Parnassus Data in the Greater China market.”

 

Solix is the only vendor today providing a solution that provides comprehensive Information Lifecycle Management (ILM) for all enterprise data. It’s lucky for us to have so strong partner in China said Maclean Liu, CEO at Parnassus Data.

 

To learn more about Solix Big Data Suite, click here.

 

About Solix Technologies

Solix Technologies, Inc., the leading provider of Information Lifecycle Management (ILM) for Apache Hadoop, helps businesses organize their Enterprise Information with optimized infrastructure, security and advanced analytics. Solix Big Data Suite is an ILM application solution framework including Enterprise Archiving and Enterprise Data Lake,  Application Retirement, Database Archiving, Test Data Management (database subsetting) and Data Masking. Solix Technologies, Inc. is headquartered in Santa Clara, California and operates worldwide through an established network of value added resellers (VARs) and systems integrators. To learn more, please visit www.solix.com.

 

About Parnassus Data

Parnassus Data is an Oracle database service company based in Shanghai, China, providing  database development, implementation, administration and emergency support services.  Parnassus Data is an expert on database optimization and monitor tool development, and also  provides remote and onsite services for Oracle database users.

 

Connect with Solix

Visit our website: http://www.solix.com

Follow us on Twitter: @solixedms

Join us on Facebook: http://www.facebook.com/solixtechnologies

 

Press Contact

Jessica Hasson

PulpPR for Solix

jessica@pulppr.com

PRM-DUL Works on Oracle 12c

PRM-DUL Works on Oracle 12c

prm works on oracle 12c

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569