ITPub博客

在数据仓库的一个应用中，有一个这样的案例：1. 源表很大，且是根据天做的分区表2. 正常情况下，每天凌晨往源表一次性导入上一天的数据3. 正常情况下，数据导入后不会做任何的修改和删除操作4. 有其他的应用需要对这个源表的数据做聚合查询(group by)，其他一个维度是分区键[@more@]PCT快速刷新是Oracle的的一个新特性，可以让基于分区表的物化视图在不需要物化视图日志的情况下，实现快速刷新。当然这种刷新的粒度是分区级的，不能精确到行级。要启用PCT快速刷新，无需特别设置。原来其他同事创建了物化视图日志来实现快速刷新，实际上，

一个SQL会包含很多个子句，在写SQL时，理解SQL个部分子句执行的优先级非常重要，否则可能会导致简单的SQL变成多个嵌套的SQL，更可能导致错误的返回结果。下面通过一个例子说明各子句的优先级：[@more@]select a,b,count(sum(c)) over ()from twhere t.d=1start with e is not null connect by prior f=ggroup by a,bhaving sum(c)>100order by 3;这个SQL包含：1. SELECT 子句2. group by子句3. 分析函数4. from子句5. where子句6. start with...connect by子句7. having子句8. order by子句对于FROM子句，可以简单理解为表或者扫描扫描

今天在处理一个会话满了的数据库，需要释放部分无用的session。根据V$SESSION的program可以简单确定PL/SQLDEV连过去的会话基本是无效会话，需要把这些会话都kill掉：[@more@]SQL> select 'alter system kill session '''||sid||','||SERIAL#||''';' from v$session where program like 'PlSqlDev.exe%';'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||''';'--------------------------------------------------------------------------------------------------------------alter system kill session '12,14459';alter system kill

今天帮助同事优化了一个SQL，效果显著。优化方式很简单，没有修改执行计划，没有添加hint，只是根据实际情况增加一些条件。[@more@]原来的SQL是这样的：sys@dwrac1> select b.*, a.login_date 2 from user1.tb1 a, user1.tb2 b 3 where 4 a.login_date >= b.call_date 5 and a.login_date < to_char(to_date(b.call_date,'yyyy-mm-dd')+30,'yyyy-mm-dd') 6 and a.game_name = b.game_id 7 and a.popt_id = b.popt_id;Elapsed: 00:00:00.01Execution Plan----------------------------------------------------

Nologging在提高性能的同时，会给恢复带来一定的影响。下面通过两个案例来说明它是怎么影响恢复的。第二个案例要验证在先备份数据文件，再发生nologging操作的情况下，是否可以完全恢复数据。[@more@]1. 建表CREATE TABLE SUK.PLOGGING ( A NUMBER, B NUMBER ) PARTITION BY LIST (A) (PARTITION P1 VALUES (1) TABLESPACE SUK , PARTITION P2 VALUES (2) TABLESPACE SUK ) ; CREATE TABLE SUK.PNOLOGGING ( C NUMBER, D NUMBER ) PARTITION BY LIST (C) (PARTITION P1 VALU

今天遇到一个很奇怪的问题，在同一个数据库上，一条简单SQL访问同样的表，一个用常量，一个用变量，但执行计划看起来一样，返回相同的数据，性能差别很大，经过一番研究，终于发现原因。下面通过实验模拟这个问题。[@more@]由于我遇到问题的表是分区表，故在实验中也用分区表模拟。drop table test purge;create table test(id int, big_col char(2000))partition by range(id)(partition p0 values less than(1),partition p1 values less than(2),partition p2 values less than(3),partition p3 values less than(4),partition p4 valu

二、后续处理上面的步骤解决了坏块对数据库的潜在影响，但是此时v$database_block_corruption的信息是还没有清除的，需要清除，需要再运行RMAN，如果没有坏块已经修复，才会从v$database_block_corruption删除对应记录。但是在大部分情况下，即使删除了原来的对象，数据块的状态让人是标识损坏的，但是不影响一般的数据库操作，可以忽略。如果你看不顺眼或者担心它影响RMAN的备份，可以用以下方法格式化这个数据块，只有被正常格式化后，数据块状态才会恢复正常。[@more@]1. 首先创建一个新表create table s (n number,c varchar2(4000))

今天帮同事优化了一条含distinct操作的SQL，因为这个SQL在数据仓库环境中非常经典，因此有比较拿出来说一说。 [@more@]原SQL：sys@dwrac1> select count(distinct a.ip) 2 from (select t.ip 3 from creater_user.popt_total_login_month_his t 4 where t.data_desc = '2010-02-01') a, (select t.ip 5 from creater_user.popt_total_login_month_his t 6 where t.data_desc between 7 '2010-03-01' and 8 '2011-12-31') b 9 where