ITPub博客

下面执行计划的一部分，前者的谓词为非分区key, 后者的谓词为分区key, 反映在执行计划上是由不同，但从他们的上一级HASH JOIN的成本来看，在对全表作PARTITION RANGE ITERATOR时，有没有走PARTITION KEY对COST影响不大。 ------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | ------------------------------------------------------

之前一直都不是很清楚这个怎么在Nest Loop中指定驱动表(外部表) 和 内部表，经过了一些实验对这一部分有了一定的认识: 首先对于nest loop有两种机制: 内部表全表扫描和内部表索引扫描，9i开始对于内部表索引扫描的情况有存在两种方式: 内部表索引range scan & 内部表索引uniqu scan, 索引range scan这种方式可以减少大的嵌套循环连接中的逻辑IO，减少锁存，甚至物理IO, 这个过程称为Table Prefetching. 另外对于nest loop, 驱动表和内部表位置如下: 1) 两个表全表扫描 : NESTED LOOPS TABLE ACCESS (FU

为了证明index对null不会纪录，特别做了以下验证: 目的通过察看全为null的列，和非null的列上的索引的叶子块和总的block进行比较，得到索引是否会纪录null值，或者说index是纪录 null 相关的 rowid呢？还是任何与null相关的列都不纪录。 另外第二个实验用来说明直方图对存在null值的索引列的作用。 先把结论说一下: 1. 索引列不纪录任何null值相关的内容，如果是null,不会产生任何索引条目; 2. 索引列出现在谓词中，如果查找条件为is null, 走全表；如果条件为 is not null, <> 某个具体的值，走index full scan; 如果条件

今天一个脚本里面的一条build index老是出现ORA-00054: resource busy and acquire with NOWAIT specified 错误，错误本身比较容易理解，肯定是有排他锁限制了对Partition Index的DDL操作。 那么如何避免，以及使用分区索引需要注意的事情，都是需要去总结的,所以下面我结合实验，简单总结一下重建Local Index: 1. DML操作对index partition rebuild的影响。 如果在rebuild某一个分区的时候，有其他的进程在对这个index partition所对应的数据进行DML操作，rebuild会受影响: kl@k02> create table t_part_1 (a number, b v

Merge在plsql的脚本的出现频率还是很高的，这里做个简单的小实验，记录一下我对merge的使用，以防将来遗忘. 另外还有一个有趣的现象，当merge和hint /*+ append */合起来用的时候，就会出现一个比较怪的现象， select count(*) from ... 结果为0， 但select * from 有行返回: kl@k02> desc t1_1; Name Type ------------------ -------- ----- A NUMBER B VARCHAR2(128) kl@k02> select * from t1_1;

直方图分为两种类型，一种是比较常见的”高度均衡”，还有一种是”频率均衡”。 我在准备的时候一直是按照”高度均衡”这种情况介绍的，之前遇到的也都是高度均衡的。 所谓高度均衡—直方图的数量小于等于distinct+1值, ENDPOINT_NUMBER这一列表示平均分配的分数, 而频率均衡则相反，为大于distinct值，ENDPOINT_NUMBER这一列表示列distinct的数值，看如下试验: 如: kl@k02> create table t2341 as select mod(rownum,3) a from dba_objects; Table created. kl@k02> exec dbms_stats.gather_table_stats(u

在一次vpn账号过期以后，重新连oracle发现出现了如下问题：> conn bm0658@adw1d.na.pg.com Enter password: ERROR: ORA-28031: maximum of 148 enabled roles exceeded 在DBA_PRIVS_ROLE里面看，拥有两个role, 一个是公司的role,里面有137个子role， 另一个是DBA有12个子role； 加起来正好149个，超过了148，所以报这个错误；oracle对最大role数量的限制为148，即便是你将max_enabled_roles参数设为一个很大的值；这是如果你的account的default role为all, 即dba_privs_role里面全为yes,在登陆时就会检查所有的role是否超过148这个

在数据仓库环境中，复制一张dimension表是比较容易的事，但对于fact表，也许很多人更倾向于创建一个view，因为在新的环境里复制一张十几亿条记录的表，而且将来还要花心思去同步更新，其工作量是难以想象的。于是我们通常把MV的定义在IFCT对应的VIEW上，为了证明是否MV 定义语句里面包含VIEW,也 可以达到REWRITE的效果，我们做如下测试:1. 以SUM_SALES_PSCAT_WEEK_MV为原型，建立测试MV和定于语句中的所有Fact和dimension;###SUM_SALES_PSCAT_WEEK_MV### Definition: ######################SELECT p.prod_subcategory, t.week_ending_day

1. 首先了解一下local index 和 global index的创建过程:SQL> create table kl911_1 (no number, name varchar2(60)) 2 partition by range (no) 3 (partition p1 values less than (10) pctfree 50, 4 partition p2 values less than (20) pctfree 50, 5 partition max_values values less than (maxvalue));Table created.SQL> create index idx_kl911_1 on kl911_1(no) local;Index created.SQL> select index_name from dba_ind_partitions where index_name='IDX_KL911_1';INDEX_NAME---------------------------

Insert到一张聚合表时出现如下错误，显然是因为MVs建在该表上，所以不能改，通过查看Metalink的: 463025.1,420777.1尝试不删除的情况下直接修改，但失败了，这种方法只对View有用，对MV没用？如下测试:ERROR at line 1: ORA-01732: data manipulation operation not legal on this viewSQL> create table kl1 as select * from sh.sales where rownum<200; --- kl1 sales Table created. SQL> create table kl2 as select * from sh.products where rownum<200; ---kl2 products Table created. SQL> crea

当要执行explain plan时，发现schema下没有Plan table怎么办？toad会自动产生plan_table, 在一个弹出的窗口中输入: plan table schema, plan table name,(是否为gloable temporary table?) tablespace name, 然后就会为你创建一个plan_table, 注意这里默认的table名字为toad_plan_table,当然也可以改为习惯的plan_table。[@more@]

引自Johnathion的COB Fundamental:数学家的对话:“三个女儿年龄和36，年龄和是在场所有人的总数，大女儿又只宠物仓鼠”with age_list as( select rownum age from dba_objects where rownum <=36),product_check as( select age1.age youngest, age2.age middle, age3.age oldest, age1.age + age2.age + age3.age as summed, age1.age * age2.age * age3.age as product from age_list age1 ,age_list age2 ,age_list age3 where age2.age >= age1.age and age3.age >= age

对于查询转化，是优化器的一种功能，较简单的回答，优化器会根据它的推测将你的sql语句以另一种方式展现出来，当然查询结果肯定不变，但性能通常都是较优的。1. NO_UNNEST: 知道优化器关闭查询unnesting，也就是不让它将子查询保持在VIEW中，打散任何子查询。而unnest则是要求使用子查询转换。这里还必须提到一个隐藏参数 "_tablescan_cost_plus_one", 这个参数在8i里默认值是false的，到了9i，10g才变成true.这将导致9i以上的full scan的成本增加1，另外还有initrans这个表现出的变化，9i中其默认值为2，即使你指定为1，或者数

答案是肯定的，与DBA_TABLES和DBA_TAB_PARTITIONS不同，DBA_IND_PARTITIONS是DBA_INDEXES里面被分区的indexes内容的复制。 SQL> select count(0) from dba_indexes where table_name like '%MV' and table_owner='ADWGD'; COUNT(0) ---------- 2152 SQL> select COUNT(distinct(index_name)) from dba_ind_partitions where index_owner='ADWGD'; COUNT(DISTINCT(INDEX_NAME)) --------------------------- 2411 SQL> select distinct(index_name) from dba_ind_partitions w

我的第一桶金,这是个略显沉重的话题,因为到现在已到而立之年,我没有起来金库的钥匙,没有一个绝对饥饿的胃,也没有被大奖砸中的运气. 也许一辈子平平淡淡的生活真的要继续下去了.但是为什么一定要这样呢? 有时候总觉得...

SQL> create table t4 as select object_id, object_type,created, status from dba_objects where rownum<3000;SQL> select count(*) from t4;  COUNT(*)----------      2999SQ...

可能是宝宝给我带来的希望，我在老婆三个月的时候得到了HP-GDCC的offer,但是这意味着我要放弃一些现有的安稳的生活，从苏州跑到上海，每周过四天独居的生活，然后回苏州过两天周末。但这让我有机会在更广的舞台上充实自己，规划自己的未来。毕竟跳出了制造企业IT的圈子，到一个以IT为产业的公司是我眼下所希望的，为此希望还在他(她)妈妈肚子里的小家伙能原谅我，总之为了将来的生活，我必须在这个时候做出这样的选择，可能也是他(她)帮我做出的选择。 就要离开BS，而且未来的工作压力肯定比现在的大很多，也要辛苦很多，但心情却觉

----创建user:select 'create user ' || username || ' identified by values ''' || passwordfrom dba_users;----授权user:select 'grant ' || granted_role || ' to ' || grantee || ';'from DBA_ROLE_PRIVS;[@more@]

10月8号，今天计划两个小时投入Oracle和SAP技术，一个小时背单词，一个小时看一些"杂书"。如果顺利的话，应该有一定收获的。[@more@]

答案是否定的，不管怎样只要块的改变记录在undo segment里面，该动作就会作为flashback transaction的候选人:conn hr/hr;create table t1 as select employee_id, salary from employees;delete t1 where employees=197;commit;delete t1 where employees=196;(without commit)SQL> select operation,undo_sql,table_name from flashback_transaction_query 2 where table_name='T1';OPERATION--------------------------------UNDO_SQL----------------------------------------------------------------------------TABLE_NAME----