Month: March 2015

在BUG 13931044 – ORA-600 [13009], [5000], [1], [17]中  相关的语句： SELECT * FROM PART_BRANCH_PC_BATCH_VIEW2 WHERE PAB_BRA_BRANCH_CODE = :B1 FOR UPDATE   也是没有Nested Loop的，但是通过”_nlj_batching_enabled”=false 绕过了该问题， 所以还是建议先使一下使用“_nlj_batching_enabled”=false作为workaround的情况。 DIAGNOSTIC ANALYSIS =================== The same batch job fails on several databases but does not reproduce at will. The databases are not clones of eachother but are running the same batch job. The…

oracle中闪回数据库到还原点的操作 CREATE RESTORE POINT before_clean GUARANTEE FLASHBACK DATABASE;   ==>必须保证闪回回复区flashback recovery area有足够的磁盘空间   在standby 上，  注意 操作之前要记得 关闭redo传输   alter database recover managed standby database finish force;   alter database open;   操作   shutdown immediate; startup mount;   flashback database to RESTORE POINT before_clean;

oracle中以测试为目的人为制造物理坏块的方法 SQL> create table maclean_corrupt tablespace users as select * from dba_tables;   表已创建。   SQL> select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid) from maclean_corrupt where rownum<10;   DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) ———————————— ————————————                               382307                        …

Oracle ASM ACFS 安装失败问题   [client(10813644)]CRS-10001:29-Sep-13 14:07 ACFS-9200: Supported [client(7798872)]CRS-10001:29-Sep-13 14:07 ACFS-9300: ADVM/ACFS distribution files found. [client(7798880)]CRS-10001:29-Sep-13 14:07 ACFS-9312: Existing ADVM/ACFS installation detected. [client(7798888)]CRS-10001:29-Sep-13 14:07 ACFS-9314: Removing previous ADVM/ACFS installation. [client(7798896)]CRS-10001:29-Sep-13 14:07 ACFS-9361: Removing device ‘acfsctl’ failed with error code ‘5888’. [client(7798898)]CRS-10001:29-Sep-13 14:07 ACFS-9307: Installing requested ADVM/ACFS software. [client(7143672)]CRS-10001:29-Sep-13 14:07 ACFS-9308: Loading installed ADVM/ACFS drivers.…

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…