Author: mac

Oracle 12c可插拔数据库通用架构图

Oracle12c新增强特性学习列表

  针对来自Oracle的不同的schema元素，是否存在自动转换到MYSQL的可能呢？ 这里我们列出了相关的元素的转换情况。 SELECT:   子句 自动转换？ 细节 WITH No 使用自定义存储过程来做准备数据，或重写查询以避免with子句 AS No SELECT Yes DISTINCT | UNIQUE | ALL Yes select_list Yes BULK COLLECT INTO No 用INTO替代 INTO Yes record_name No FROM Yes @dblink No materialized view No TABLE (collection_expression) No MODEL No MySQL 不支持MODEL START WITH No MySQL 不支持树形查询，要用存储过程替代 CONNECT BY No MySQL…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   1 问题现象描述 2015年3月20日 接运维同事反馈南宁富士康工厂有异常，前台web界面输入账号密码无反应，这边试了下登录数据库发现数据库无监听，登录外协厂服务器检查发现数据库挂了。 2 问题根因说明 事前巡检同事发现南宁富士康系统存储有异常，有个盘处于即将失效状态，存储中只剩下一个热备盘，如果该盘失效后热备盘将会启用，期间将不允许坏第二块盘。根据事件的紧急层度决定把配件交由将会去南宁的同事帮忙带过去。备件送达南宁工厂但由于工厂流程问题未能及时更换。存储中另一块硬盘损坏，热备盘给启用，该天下午，即将失效的磁盘失效，导致数据库异常系统无法启动。定位到是存储一个硬盘异常导致数据库DATA文件缺失，无法启动数据库。 3 问题判断方法 1、定位到是存储一个硬盘异常导致数据库DATA文件缺失，无法启动数据库。 2、找南宁富士康同事把寄过去的存储备件插上，发现由于之前的备份盘已经给使用了，无备份盘，导致一块硬盘数据缺失，找公司负责存储的同事分析确认通过常规手段恢复不了了，只能把盘拔出来找数据恢复公司恢复了。 3、DBA检查发现由于磁盘损坏数据库无法启动，需要根据备份文件恢复，与DBA沟通，把损坏的磁盘从映射的主机组中去除，并把新到的存储备件插入开始划分LUN并格式化， 预计3个小时能格式化完。格式化完后DBA开始帮忙把新LUN添加到数据库文件组中，并开始根据备份文件还原数据库。 4、DBA检查控制文件发现参数异常没有备份成功，并且数据文件备份好像也有些问题，无法通过备份文件恢复，DBA帮忙协调资源看能否在磁盘损坏的情况下把数据库mount起来，至于丢失数据通过业务方案来补充。 5、DBA通知根据他们那边能协调到的资源无法在部分磁盘损坏的情况下启动数据库，需要项目组看看能否找oracle顾问能否解决。 6、项目组召开紧急会议决定，为了尽快恢复工厂的生产，在原来南宁富士康工厂的服务器上面新建instance，重新部署系统。 4 解决方案 阶段一：恢复产线生产 异常当天组织技术讨论发现无法快速的恢复异常的数据库，项目组决定给南宁富士康工厂新建数据库来使用。DBA开始帮忙新建DATA组并创建instance。新数据库部署完毕，开始导入数据文件，初始化sequence。数据库表结构导入完成，修改was数据源测试通过。开始开始跑数据库的脚本及新系统的部署。系统部署完成，内部及工厂产线开始验证。 内部及工厂产线开始验证完成，工厂开始根据业务方案进行返工处理。 阶段二：对故障库进行数据恢复 1、数据库存储中有一块硬盘损坏，通过raid机制无法对其数据进行恢复，需要找专业的磁盘恢复公司进行硬盘修复。通过公司采购流程采购了存储设备修复服务，将损坏硬盘恢复为能正常使用的硬盘，未对硬盘内部底层数据进行更改。 2、硬盘恢复好后插回原存储中，找DBA帮忙对数据库进行修复和启动。 经过努力，现在grid已经能够起来，几个disk group也已mount上去，但是在打开数据库的时候报ora 600 [2662]错误，这个是由于当前的scn远小于数据块的scn号： 尝试使用了alter session set events ‘10015 trace name adjust_scn level X’;方法来提升scn号，遇到如下问题： 由于出现了ora-00283和ora-16433，尝试重建了控制文件，再重新进行操作，在open的时候它会要求必须使用resetlogs或noresetlogs选项： 最后还是报了ora 600 [2662]错误，scn看上去也没有提升上去。 其实还有一种方式可以提升scn号，即把数据库反复的shutdown和open，但是这只适用于当前scn号与数据文件中的scn号相差不大的场景，这个案例中的当前scn号是4150989410,需要提升到的scn号是4151687346，相差69万多，而每次启停数据库仅能提升4，意味着要打开需要启停10几万次，因此人工方式是不现实的。   这个问题有点棘手，常规方法试了都不起作用，按理说这已经是恢复数据库的最后一步了，但不知道打开后还会不会有其他的问题，恢复出来的磁盘上的数据组织形式是否正确只有在打开后才能验证。…

很多用友ERP NC/HR系统的后台 ORACLE 数据库都处于无备份且未打开归档的状态，由于一般企业对于NC或HR系统的后台数据库没有专职的DBA维护，所以实际也不推荐真的开归档并基于归档做备份维护，因为这样做会多一点维护的工作量（如果你是大企业 那么理应打开归档并维护归档以满足自身的备份恢复要求，例如大企业要求数据能回溯到一个月前，那么有归档才是合适的。） 对于中小企业使用用友NC或HR系统而言，视乎系统后台ORACLE数据库的大小和可容忍的数据丢失时间，可以自主选择逻辑备份周期。这里说的逻辑备份主要是指ORACLE自带的EXPDP 数据泵导出工具，一般来说目前的用友NC/HR用户的后台ORACLE数据库都是大于版本9i的版本（例如10g和11g等），则都可以选择使用EXPDP，其好处是逻辑导出备份要比传统export/import工具的exp速度上要快很多，且其导出格式也比exp周全。 一般来说中小企业大多可以容忍一天到半天的数据丢失，这部分的数据丢失一般可以基于财务或人力部分的同事通过手工补录来弥补，则对于这种场景下可以规划每12小时或24小时做一次逻辑备份：注意逻辑备份的频率就决定了数据丢失的量，因为逻辑备份是就是一次对数据的全量备份，每一次逻辑备份都是对现有数据的全量备份；所以周一中午12点备份的数据，在周二上午12点备份前的周一下午6点发生了数据库损坏/毁灭等问题，则周一中午到下午6点间产生的数据将可能丢失。 对于逻辑备份而言，其实维护的命令很简单： expdp DIRECTORY=(备份存放的目录，需要在ORACLE内以CREATE DIRECTORY创建) dumpfile=(备份的文件名，会放在DIRECTORY下) schemas=(NC或HR所在的Schema) logfile=(日志的文件名，会放在DIRECTORY下） parallel=2 例如 备份的目录叫DMP，NC或HR所在schema伟NC1和SHR1 则 expdp DIRECTORY=DMP dumpfile=nc50_20170315.dmp schemas=NC1,shr1 logfile=exp_20170315.log parallel=2 对于Windows可以使用计划任务，对于Unix/Linux可以使用crontab自动调度以上备份脚本；另脚本内一般要考虑删除多久之前的备份文件。 此外要考虑 逻辑备份一般都是备份在数据库所在服务器，若服务器出现主机故障则恢复将较为麻烦，因此一般会考虑则EXPDP逻辑备份后FTP或COPY到其他远程服务器的磁盘上，以便冗余备份。 例如在 Linux下 定期备份并传到到FTP服务器上： #!/bin/sh ORACLE_HOME=/home/app/oracle/product/11.2.0/dbhome_1 export ORACLE_HOME export PATH=$ORACLE_HOME/bin:$PATH ORACLE_SID=orcl; export ORACLE_SID HOST=’IP地址’ USER=’ftpuser’ PASSWD=’password’ expdp NC/SHITANRUANJIAN DIRECTORY=backdir DUMPFILE=NC-$(date +%Y%m%d%H) VERSION=10.2 LOGFILE=NCLOG-$(date +%Y%m%d%H).log zip -r /home/app/oracle/admin/orcl/dpdump/NC-$(date +%Y%m%d%H).zip…

ROW CR确实是10g以后引入的一个新特性，该特性针对fetch by key的数据访问优化减少一致性读Consistent read。但该特性也造成了一些问题 例如出现ORA-600错误、SQL性能下降等。  有不少客户选择关闭了 “_ROW_CR”特性， 其性能影响主要体现在 fetch by key的查询的逻辑读可能略微上升。 注：实际上这类问题已经登记过bug 10425196，但最后oracle认定为“not a bug” From the customers point of view, the root cause of this is the ROW_CR optimization. ROW_CR is enabled by default. Solution: Either require some sort of application changes to avoid such issue; OR go back to the original behavior…

1. 使用expdp+TRANSPORT_TABLESPACES时默认会导出相关表空间上对象的统计信息。 可以用exclude=TABLE_STATISTICS,INDEX_STATISTICS禁止导出统计信息。 2. 使用dbms_stats.lock_table_stats锁住的统计信息， 在TTS导入后仍保持锁定状态 SQL> SQL> create tablespace fortts datafile size 20M; 表空间已创建。 SQL> conn maclean/oracle 已连接。 SQL> create table tvbs as select * from dba_objects; 表已创建。 SQL> exec dbms_stats.gather_table_stats(USER,’TVBS’); PL/SQL 过程已成功完成。 SQL> alter table tvbs move tablespace fortts; 表已更改。 SQL> alter tablespace fortts read only; 表空间已更改。 C:\Users\xiangbli>expdp maclean/oracle TRANSPORT_TABLESPACES=FORTTS dumpfile=temp:tts.dmp Export: Release…

ORACLE RAC中最主要存在2种clusterware集群件心跳 &  RAC超时机制分析： 1、Network Heartbeat 网络心跳 每秒发生一次； 10.2.0.4以后网络心跳超时misscount为60s,；11.2以后网络心跳超时misscount为30s。 2、Disk Heartbeat 磁盘心跳  每秒发生一次； 10.2.0.4以后 磁盘心跳超时DiskTimeout为200s。 注意不管是磁盘心跳还是网络心跳都依赖于cssd.bin进程来实施这些操作，在真实世界中任何造成cssd.bin这个普通用户进程无法正常工作的原因均可能造成上述2种心跳超时， 原因包括但不局限于 CPU无法分配足够的时间片、内存不足、SWAP、网络问题、Votedisk IO问题、本次磁盘IO问题等等（askmac.cn)。   此外在使用ASM的情况下，DB作为ASM实例的Client客户； ASM实例会对DB实例的ASMB等进程进行监控， 以保证DB与ASM之间通信正常。 若DB的ASMB进程长期无响应(大约为200s)则ASM实例将考虑KILL DB的ASMB进程，由于ASMB是关键后台进程所以将导致DB实例重启。 也存在其他可能的情况，例如由于ASMB 被某些latch block, 会阻塞其他进程，导致PMON进行强制清理。   综上所述不管是Clusterware的 cssd.bin进程还是ASMB进程，他们都是OS上的普通用户进程，OS本身出现的问题、超时、延迟均可能造成它们无法正常工作导致。建议在确认对造成OS长时间的网络、IO延时的维护操作，考虑先停止节点上的Clusterware后再实施。 另可以考虑修改misscount、Disktimeout等 心跳超时机制为更大值，但修改这些值并不能保证就可以不触发Node Evication。   关于RAC /CRS对于本地盘的问题，详见如下的SR回复： Does RAC/CRS monitor Local Disk IO ?   Oracle software use local ORACLE_HOME / GRID_HOME library files…

诗檀软件成功帮助山西某公安系统恢复了超过3TB的数据库   由于客户数据库使用裸设备，且数据量高达3T。这里仅对整个system表空间文件及部分数据文件头进行备份。 相应备份被放置在/oracle/backup目录下。 1) 备份spfile create pfile=’/home/oracle/pfile1′ from spfile; 2) 备份system表空间文件及数据文件头 SQL> select bytes/1024/1024 from v$datafile where file#=1; — 2040 $ mkdir /oracle/backup $ dd if=/dev/rrac_system01 of=/oracle/backup/rrac_system01.bak bs=1024000 $ dbv file=rrac_system01.bak blocksize=8192 SQL> set echo off SQL> set heading off SQL> set linesize 300 pagesize 0 SQL> select ‘dd if=’||name||’ of=/oracle/backup/header_’||file# || ‘ bs=1024000…

更新你的Oracle数据库认证，保持证书有效 新的重新认证政策出台: 号召大家升级 在2014年10月7日, Oracle认证团队宣告了一项新的重新认证政策。   政策要求Oracle数据库证书持有者保持其证书当前有效性。 如果你仍持有Oracle7.3, Oracle8, Oracle8i或Oracle9i数据库证书作为你当前的Oracle数据库认证，那么你需要赶在2015年11月1日前升级到当前有效版本来保持你的Oracle数据库证书有效性。 如果你正持有一张Oracle数据库10g认证作为你当前最新的Oracle数据库证书，那么你需要在2016年3月1日前将证书升级至Oracle数据库11g或12c版本以保持Oracle数据库证书的有效性。   查看更多重新认证政策信息 现在升级   持有一份当前有效证书的好处   为什么我应该升级？ 保持你的技能和知识是最新的。 展现你时刻与当前最新趋势，技术和最佳实践同行的承诺。 维护市场信誉 。 确保你正和你的同行说着相同的技术语言，永不落伍。 致力于一个更强有力的认证程序来增加你证书的价值。   为什么我应该让我的雇员升级？ 一个拥有当前有效认证知识的DBA可以即时有效地引导公司的技术升级。 一个拥有最新技能的DBA工作将更优效率。 一个拥有最新技能的DBA更了解当前技术且能做出更好的商业决定。 一个拥有最新技能的DBA将对理想的团队表现起到支撑并具有战略价值。   关于升级路线   参加一门考试即可从Oracle7.3, 8, 8i, 9i, 10g或11g DBA OCP升级至12c DBA OCP – Oracle数据库12c升级(1Z0-060) 现在注册 查看考试详情   只需通过一门简单的考试和一项培训课程即可从Oracle9i，10g，11g DBA OCA升级至12c DBA OCP – Oracle 9i/10g/11g…