随笔分类 -  Oracle DBA

【原创】某银行综合报表系统优化片段
摘要：某行综合报表平台自上线以来，ETL耗时越来越长，日批处理耗时约为4小时30分钟到6小时，月批处理耗时约为12小时到14小时，并且耗时越来越长，RAC节点间流量达到80M/S，冲突非常大，CPU很高。库的问题非常多，比如该sql：Elapsed Time (s)CPU Time (s)Executions Elap per Exec (s) % Total DB TimeSQL IdSQL ModuleSQL Text19,57865836525.842.310w08q2c6s0dtxselect * from ( select row$_.*...可见该语句运行了6525.84秒，将近2个小时 阅读全文

posted @ 2013-12-27 17:59 迷途@书童 阅读(411) 评论(0) 推荐(0)

【原创】rman备份出现ORA-19625
摘要：[oracle@sunny stage]$ rman target /Recovery Manager: Release 10.2.0.1.0 - Production on Sun Mar 18 17:21:22 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.connected to target database: ORCL (DBID=1141870147)RMAN> backup archivelog all;Starting backup at 18-MAR-07current log archivedusi 阅读全文

posted @ 2013-12-27 17:19 迷途@书童 阅读(401) 评论(0) 推荐(0)

【原创】rman 全库备份脚本
摘要：rman 全库备份脚本run {allocate channel d1 type disk;allocate channel d2 type disk;backup full database format '$back_path/`date +%Y%m%d`_full_%d_%s_%p_%u.bak'tag='full' include current controlfile;sql 'alter system archive log current';backup archivelog all format '$back_path/` 阅读全文

posted @ 2013-12-27 17:18 迷途@书童 阅读(384) 评论(0) 推荐(0)

【原创】查询占CPU高的oracle进程
摘要：1：首先使用TOP命令传到占用CPU高的SPID号PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND3575 oracle 1 12 0 0K 0K run 748.6H 24.98% oracle3571 oracle 1 22 0 0K 0K sleep 706.2H 22.84% oracle2：使用DBA账户登录数据库，使用以下SQL语句查询:SELECT * FROM V$PROCESS WHERE spid=3575;查询到SQL相关信息3：根据以上查询到的信息使用以下SQL查询:SELECT sid, program 阅读全文

posted @ 2013-12-27 17:15 迷途@书童 阅读(606) 评论(0) 推荐(0)

【参考】查找Oracle最高的几个等待事件以及锁的信息
摘要：1.通过操作系统的命令找到系统资源的bottleneck，如:CPU, Memory, I/O, Network 同时主要关注IOWait, PI/PO, Memory的使用情况2.通过查询v$sys_time_model来观察系统整体在基于time的标准上整体的运行状况.SQL> select * from v$sys_time_model; STAT_ID STAT_NAME VALUE---------- ------------------------------ ----------3649082374 DB time 97725560232748282437 DB CPU 6 阅读全文

posted @ 2013-12-27 17:14 迷途@书童 阅读(1106) 评论(0) 推荐(0)

【原创】CQ数据库损坏修复
摘要：上周三中午CQ数据库数据文件损坏，导致登录时一张关键的表无法查询报错从而cq无法登录，此次故障和上次的一样，不过恢复的非常曲折，导致停机两天，现简单的通报下恢复过程：故障原因：oracle-902版本的一个BUG,数据文件大小逼近4G、8G临界点时无法自动扩展，该bug在903版本后得到修复，但是公司cq库迟迟未升级，14号数据文件上保存了大量的大对象数据以及大部分cq系统表，在执行修改操作段扩张时逼近4G大小临界点从而报错，导致数据文件头不一致，数据文件被offline。。。上次故障也是同样的问题。解决方案：最终的解决方案为重建14号数据文件所在的表空间，全部使用小数据文件(1.9G+10M 阅读全文

posted @ 2013-12-27 15:45 迷途@书童 阅读(772) 评论(0) 推荐(0)

导航