ITPub博客

在系统升级的过程中，准备了大量的脚本，分成几个窗口来分别执行。在碰到问题的时候，一定要很细心和冷静，不经意的错误可以需要几倍，几十倍的努力来挽回。准生产环境中有一个表。TREATMENT_ACTIVITY,现在需要从另外一个临时的schema中insert一部分数据。 Name              ...

生产系统中有一条sql语句，目前执行的时间有点长了,SELECT COUNT(1)  FROM (         SELECT /*+ leading (payment_temp_table payment PAYMENT_DETAILS account memo) use_nl (payment_temp_table ar1_payment PAYMENT_DETAILS account memo) index (payment payment_pk) index (P...

在数据迁移中，经常会碰到null值的问题，比如在源库中，某些列可能是null值，但是在目标库中，却有非空约束。这样在数据的迁移过程中就会发生问题。为了更好的对数据的非空问题进行判断，我写了如下的脚本来生成检查的脚本，基本的思路就是生成动态sql，类似 select count(1) from xxx where xxx is null,如果输出结果不为...

今天在从生产环境中做一个数据抽取，为了提高效率，加了并行。发现了一些小的细节。首先，抽取数据时，对于并行度的指定我是设定200M为一个单位，如果表有1G，那么就需要启5个并行，结果有一个表有40G，按照这个单位，需要200个并行。但是在实际中,ddl的执行并行度，数据库不一定会买账，首先从数据库实例层面有一些参数...

在生产系统中有些时候需要保证一些表的只读特性，不允许表的数据被轻易修改。可能有一下的场景比较适用。1） 一些系统中有一些类似数据字典信息的表。这些表的信息基本都是稳定的，不会轻易的改变。2） 可能需要从一些外部系统中拷贝一些数据做比对和参考，不希望这些“临时”表的数据被认为修改。3） 系统的核心表...

今天在生产环境中,开发人员提交了一个脚本，是做update操作的，但是update操作的时候过滤条件有些大，本来预计修改的数据只有5000条，结果这个语句运行下来更改了500万条数据。对生产系统来说算是一个数据灾难，赶紧和开发确认了问题发生的时间，结果说是在半夜11点多，刚好在后半夜才开始做数据备份，这样这个变更也同时影...

设计模式中的很多思想还是很有意思的，刚毕业的时候接触设计模式感觉有点高深，坐而论道，感觉还是有些虚，平时做的小练习还能自己捣鼓一番，自己使用一下设计模式，然后大刀阔斧的改动代码，随心所欲，写完以后还能热乎劲上来高兴几天，时间长了就忘了很多的东西，只是感觉设计模式就是抽象，自己感觉也抽象。如果死磕着问...

今天在生产环境中发现一条sql语句尽管走了主键索引，但是查询还是很慢。sql语句类似下面的形式：SELECT /*+ index (bl1_cyc_payer_pop BL1_CYC_PAYER_POP_PK) */ T_TAX.BA_NO, T_TAX.TOTAL_TAX_AMT, T_TAX.TAX_RELATION, T_TAX_ITEM.TAX_ITEM_SEQ_NO, T_TAX_ITEM.TAX_SEQ_NO, T_TAX_...

生产中有一条sql语句消耗了大量的cpu资源，执行时间在18秒左右，Session:PRODBUSER (1560:61133)SQL ID:1hg2wcuapy3y3SQL Exec...

append data from MIG_TEST.MO1_MEMO_EXT_2 to MIG_TEST.MO1_MEMO1936470 rows created.Elapsed: 00:01:01.53Commit complete.Elapsed: 00:00:00.03append data from MIG_TEST.MO1_MEMO_EXT_3 to MIG_TEST.MO1_MEMO873897 rows created.Elapsed: 00:00:22.67Commit complete.Elapsed: 00:00:00.02append data f...

在linux中有经常做文件的操作，今天有个同事在生产环境统计数据，发现有很多日志文件都是空的，文件太多了，他想查看一下有哪些文件不是空文件。而且还不想使用脚本，就想用一个命令来搞定，确实够懒的一个人。简单模拟了下。我只想查看e.lst 因为它的大小不是空的。DUM1102 /oravl01/oracle> ll *.lst-rw-r--r-- &nb...

通过v$sql_monitor能够实时采集可能存在的sql性能问题，但是每次问题发生的时候采取采取措施就有点“晚”了，我们需要防患于未然，把一些潜在问题提前发现，并加以解决。如果有些sql执行很频繁，我们需要得到一个执行的报告，但是因为sql执行很频繁，每次都生成一个报告就显得有些过于消耗资源了。现在想达到的目标就是...

生产环境有一条sql语句执行比较频繁，占用了大量的cpu资源。在一次排查中引起了我的注意，决定看看cpu消耗到底在哪儿？sql语句是比较简单的，通过查询SUBSCRIBER_FA_V是一个视图。在视图中关联了几个和业务核心表。SELECT TO_CHAR(SUBSCRIBER_NO) SUBSCRIBER_ID,       SUB_STATUS,    ...

全表扫描 vs 索引

oracle的sql monitor是一个很有用的工具集。但是通过sql命令和反复去调用dbms_tune来传入参数等等操作感觉挺费事的。可以通过如下的脚本来定位sql monitor中的性能sql，发现一些潜在的性能问题。这个脚本可以定位正在sql monitor监控范围内的sql语句。MONITOR_OWNER=`sqlplus -silent $DB_CONN_STR@$SH_DB_SID <<ENDse...

并行特性在数据库里对于性能的提升很有帮助，尤其是大批量的数据处理。今天对于并行的性能情况进行了简单的图表分析。为了能够比较合理的比较数据，对数据库里的2张大表进行了比对分析。测试的场景有以下两个。1.并行生成dump文件，比如一个大表有100G，使用并行，并行度为50 ，那么很可能会生成50个dump文件，每个dump...

使用sql*loader是大型项目中数据迁移的利器。如果是外部系统，其他数据库到oracle的数据迁移，使用文本式文件是最兼容的方式。sqlldr的加载效率是很高的，同时在oracle 10g以后推出的oracle_loader效率也不容小视。sqlldr提供了额外的功能来生成external_table的创建和insert脚本,不过control file是关键，今天尝试的时...

针对之前在生产环境中使用sql*loader的性能问题，最近一直在想使用外部表的oracle_datapump来替代它。昨天下午做了大量数据的测试，比较了这两种方案。最后发现在一定的限定条件下，从很多细节来看 oracle_datapump要更胜一筹。首先使用sql*loader对于clob,blob的数据相比普通表的处理要一些额外的工作，但是这些限制或者...

今天需要在测试环境中做一些性能测试，为了不影响原有的数据，准备创建一个临时的schema。但是创建的时候报了如下的错误。SQL> create user mig_perf identified by mig_perf;create user mig_perf identified by mig_perf*ERROR at line 1:ORA-28003: password verification for the specified password failedORA-2...

对于clob的数据，很多场合中都使用xml的格式，但是对于数据的查取和处理总是感觉力不从心。在条件允许的情况下，如果能够巧妙的使用xmltype来做数据处理，无意中是对于clob的一个处理利器。简单说下需求。数据库里存放的clob类似下面的格式<ObjectInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://...