ITPub博客

利用 Oracle Database 10g 实用工具数据移动得到了很大的提高。 迄今为止，导出/导入工具集仍是跨多个平台转移数据所需劳动强度最小的首选实用工具，尽管人们常常抱怨它速度太慢。导入只是将每条记录从导出转储文件中读出来，然后使用常见的 INSERT INTO 命令将其插入到目标表中，因此导入可能是个很慢的过程，这一点并不让人感到吃惊。 [@more@]进入 Oracle Data Pump，Oracle Database 10g 中的导出/导入工具包的更新更快的同类工具，它被设计来成倍地加速这个过程。 Data Pump 反映了整个导出/导入过程的彻底革新。它不是使用常见的 SQ

在oracle对象的重命名始终都是个麻烦的事情，这些对象主要是指表名，索引名，列名，表空间名。[@more@]在8i的时候提供了对表名和索引名的重命名功能：SQL> alter table sunwg rename to sunwg01;表已更改。SQL> alter index ind_sunwg rename to ind_sunwg01;索引已更改。在9i的时候提供对表中的列的重命名功能：SQL> desc sunwg 名称 是否为空? 类型 ----------------------------------------- -------- -------------- OWNER VARCHAR2(3

大家应该都有等女朋友的经历吧。想想下面两种情况哪种会更让你着急，一是知道她20分钟后肯定到，二是不确定到底她会什么时候来（可能5分钟，也可能50分钟）。我想对大部分人来说第二种会更让人发狂。[@more@]在oracle的使用过程中，大家也一定会有下面的经历，先前执行了一个错误的大规模操作，幸好没有提交，现在需要做的回滚。等发出了rollback的命令后，迎接我们的是不可预知的等待，我们不知道到底现在回滚进行到了什么程度，大概还要需要多少才可能完成（这个更加值得关心）。也有很多人，经不这样的漫漫的折磨，把窗口关闭，进而导致

由于粗心大意，在数据库中误操作数据的情况经常的发生。在9i之前，一般只能通过logminer或者时间点恢复来找回丢失的数据。在9i中出现了一种新的恢复技术——flashback，这样我们有了一种强有力的恢复工具，可以在不影响系统的情况下在最短的时间内找到丢失的数据。但是9i中的flashback还有很多的不足，使用起来并不是很方便。在10g中对flashback进行增强，使用简单明了，并且增加了对闪回版本查询的支持。[@more@]先举例说明下10g中的flashbakSQL> select * from v$version;BANNER---------------------------------------------------

延伸1， 直方图的分类直方图可以分为两类：FREQUENCY（频率）和HEIGHT BALANCED（高度平衡）在弄明白这两类直方图，首先得知道什么直方图。用上面的例子来说明下：[@more@]SQL> select ENDPOINT_NUMBER, 2 ENDPOINT_VALUE 3 from user_tab_histograms 4 where table_name ='SUNWG' 5 and column_name = 'ID' 6 order by ENDPOINT_NUMBER;ENDPOINT_NUMBER ENDPOINT_VALUE--------------- -------------- 6 1 7 201 8 801

1， 存在表和索引上的统计信息，存在直方图为了更明显的说明直方图的作用，我修改一下上面的创建的表，进一步的增加列ID的倾斜性。[@more@]SQL> drop table sunwg purge;表已删除。SQL> create table sunwg (id number);表已创建。SQL> create index ind_sunwg on sunwg(id);索引已创建。SQL> insert into sunwg select 1 from dba_objects where rownum < 4000;已创建3999行。SQL> insert into sunwg select rownum from dba_objects where rownum < 2002;已创建4001行。SQL> commit;在表SUNWG中ID = 1的记录一共

1， 存在表和索引上的统计信息，没有直方图这是最一般的情况，定期对表和索引进行分析，但是并不分析直方图信息。大部分时候，这种统计信息收集策略都会很好的工作。我们这的大部分指得是，列上数据分布很平均的情况下。为了更好的演示，我需要创建一个存在倾斜列的表[@more@]SQL> drop table sunwg purge;表已删除。SQL> create table sunwg (id number);表已创建。SQL> create index ind_sunwg on sunwg(id);索引已创建。SQL> insert into sunwg select 1 from dba_objects where rownum<2001;已创建2000行。SQL> ins

三，正文1， 没有任何统计信息（包括表，索引，直方图等）在ORACLE 10g中，RBO已经彻底的被抛弃了，取而代之的是CBO。我们知道CBO的基础就是统计信息，那么在10g中如果没有收集统计信息，CBO是怎么工作的呢？我们看下面的这个例子。[@more@]Create table sunwg (Id number);Create index ind_sunwg on sunwg(id);BeginFor I in 1..100 loopFor j in 1..i loopInsert into sunwg values (i);End loop;End loop;Commit;End;这样我们就创建了一张有5050条记录的测试表。例1， 不存在统计信息SQL> select * from sunwg where id = 10;已选择

一，概述关于CBO优化器你上网可以搜到一大堆的介绍。用一句话来解释CBO：CBO是一种根据执行代价来选择执行计划的机制。对于CBO来说，最重要的就是各种不同的执行计划的代价的计算。和RBO比较起来，CBO确实要聪明很多。CBO会根据对象上的统计信息来进行执行计划的代价评估，选择出较为高效的。而不是象RBO那样根据一些既有的规则来选择执行计划，愣头青一样的。[@more@]既然是根据对象上的统计信息来计算代价，那么统计信息对于CBO的重要性就不用多说了。所以在CBO的数据库上，统计信息一定要定期收集，保证不光要有统计信息，而且也要尽量

学习oracle最好的方法就是多做测试。书上写的知识都是别人的，只有经过自己严格测试的东西才是自己的。这是个很简单的道理。但是很多人都知道测试的重要性，也都做了测试，但是进步却不明显呢？首先，测试的过程应该是一个思考的过程。如果仅仅是简单的重复别人的过程，那这个测试是没有任何意思的。其次，测试用例的选择也是很重要的。这点是我最近体会最深刻的。对于一个问题，选择特殊的测试用例和选择一般的测试用例得到的结果可能不大相同，有时会是大相径庭的。我觉得测试的时候应该选择常见的普通的测试用例，这样才会更有代表性。

最近变得很浮躁，总不能静心下来做点什么。经常利用自己的臆测来代替缜密的实验，得到了一些看似正确，实则错误的结果。关于CBO基数的文章就是个很好的例子，漏洞百出。这篇有问题的文章我就留下了，给自己提个醒。[@more@]

一篇文章应该有个主题，这篇文章的主题就是关于BLOCK的，不过可能内容会杂一些，涉及的东西会多一些。[@more@]BLOCK是ORACLE中最小的物理单位，在BLOCK上面是EXTENT，SEGMENT，DATAFILE。在ORACLE中的BLOCK的必须是操作系统的块大小的整数倍，下面是关于BLOCK大小的说明：DB_BLOCK_SIZECaution: Set this parameter at the time of database creation. Do not alter it afterward.DB_BLOCK_SIZE specifies (in bytes) the size of Oracle database blocks. Typical values are 4096 and 8192. The value of this parameter must be a mult

马上就过年了，火车票还没有着落，估计今年十有八九是回不了家了。头一次知道火车票居然是这么抢手的东西。每天晚上，各个售票点门口都会聚集大群人，他们会在门口等一个通宵，然后买第二天的票。可其中的绝大部分还是失望而归。真的有那么难么，两方面吧，一方面铁路的运力确实有缺口，春运的压力大得很，这方面大家都会理解。另一方面，就是黄牛票的问题，这个问题不知道多少年了，没有得到一点的解决，每年春运的时候黄牛都变成了主角，高高在上。我还是喜欢叫他们“票贩子”。车票紧张是事实，可真的紧张到这个程度了么？我想

今年是我来杭州的第一年，今天的冬天也是我在杭州过的第一个冬天。 杭州的冬天并不冷，很少有低过零度的时候，但给我的感觉是阴冷无比。原来在东北的时候，虽然外面有零下三十多度，可是只要回到家，由于有了暖气，室内的温度都是二十多度的。而一天大部分的时间都是在屋子度过的，所以北方的冬天给我的印象是很温暖的。而南方却不是这样的，外面虽然不冷，屋子里面也不热，没有暖气，屋子里面和外面的温度差不多，而且南方的湿度很大，显得更加的阴冷。北方人在这边就比南方人更加的怕冷。 另一个方面，南方的冬天

v$type_size该视图列出各种数据库组件的尺寸以估计数据块的容量。使用这个视图可以很方便的知道各个组件的大小。以前不知道这个视图，为了得到TRANSACTION VARIABLE HEADER和DATA HEADER进行了大量的实验，呵呵。[@more@]SQL> select * from v$type_size;COMPONEN TYPE DESCRIPTION TYPE_SIZE-------- -------- -------------------------------- ----------S EWORD EITHER WORD 4S EB1 EITHER BYTE 1 1S EB2 EITHER BYTE 2 2S EB4 EITHER BYTE 4 4S UWORD UNSIGNED WORD 4S UB1 UNSIGNED BYTE 1 1S UB2 UNSIGNED BYTE 2 2S UB4 UNSIGN

在ORACLE10G中提供了一个新的功能，ORA_ROWSCN。ORACLE会在表中记录每条记录的最后的变化的SCN。[@more@]默认的情况下，每个块中所有的记录的ORA_ROWSCN都是相同的，当块中任意一条记录发生改变的情况下，块中所有记录的ORA_ROWSCN都会变化为最新值，ORA_ROWSCN的最小粒度是块。当我们使用create table …… rowdependencies;建表的时候，每条记录会有自己的ORA_ROWSCN段，在这种情况下块内的一条记录的更改仅仅会影响该记录的ORA_ROWSCN，不会对块内其他记录的ORA_ROWSCN产生影响。这个时候，ORA_ROWSCN的最小粒度是记录。这个功能比较适

有两个ORACLE的文件我是一直放到桌面上的，作为很好的帮助文档来使用的他们分别是：$ORACLE_HOME/rdbms/admin/sql.bsq$ORACLE_HOME/rdbms/admin/catalog.sql[@more@]sql.bsq主要记录了ORACLE中的系统字典表的定义，比如过tab$,col$等，通过查询这个文件我可以知道数据字典表的定义，更好的了解一些操作对系统字典表的更改，对ORACLE的内部操作会有更加深刻的认识。比如：create table obj$ /* object table */( obj# number not null, /* object number

ORACLE终于在10G中提供了对正则表达式的支持，以前那些需要通过LIKE来进行的复杂的匹配就可以通过使用正则表达式更简单的实现。ORACLE中的支持正则表达式的函数主要有下面四个：[@more@]1，REGEXP_LIKE ：与LIKE的功能相似2，REGEXP_INSTR ：与INSTR的功能相似3，REGEXP_SUBSTR ：与SUBSTR的功能相似4，REGEXP_REPLACE ：与REPLACE的功能相似在新的函数中使用正则表达式来代替通配符‘%’和‘_’。正则表达式由标准的元字符（metacharacters）所构成：'^' 匹配输入字符串的开始位置，在方括号表达式中使用，此时它表示不接受该字

本来不想测试DBMS_OBFUSCATION_TOOLKIT.md5的效率的，可是事先没有想到dbms_crypto.hash与dbms_utility.get_hash_value的效率会差距这么大，所以看来还是有必要测试下DBMS_OBFUSCATION_TOOLKIT.md5的效率。[@more@]还是那用个很大表的SUNWG来测试吧。SQL> select count(*) from sunwg; COUNT(*)---------- 5000000SQL> create table sunwg_md5 as select md5(id) id from sunwg;Table createdExecuted in 148.062 secondsSQL> create table sunwg_get_hash as select dbms_utility.get_hash_value(utl_raw.cast_to_raw(id),1,

The following is a list of all hints available in Oracle9i. Many of the hints are also available in earlier releases of Oracle. The purpose of this list is not to exhaustively describe the syntax of each hint, but to show the way each hint is most commonly used. [@more@]ALL_ROWS Optimizes for least resource usageto return all rows required by the query. This hint will sometimes override a NESTED LOOP with a SORT MERGE or a HASH JOIN if applied to a SELECT, UPDATE, or DELETE statement when OPTIMI