在AnySQL.net中搜索标签(Tags) 'Index' 的结果:
一周遇到两个Oracle Bug
来杭两周多一点, 扣去入职培训一周, 接触系统仅一周多一点的时间, 已经遇到了两个数据库方面的Bug了. 第一个是在10.2.0.2版本上遇到的, 和Oracle CBO优化器有关的, 在某些用了INDEX这个HINT的数据库中, Oracle居然选择了INDEX FULL SCAN的方法, 而不是效率更高的INDEX RANGE SCAN, 由于表及索引较大, 导致了SQL语句执成本过高, 引起了主机负荷超常. 4323868 INDEX hints can lead to INDEX SCAN FULL 另一个是在9i中遇到的, 和UNDO表空间有关的, 平时的事务都很小, 某一点作了一个比较大的事务, 引起了回滚段的扩展, 虽然UNDO中有大量的可用未分配的空间, 但这个扩展的过程却极慢. Oracle并不从可用未分配的空间中优先分配, 而是先去检查有没有已用的空间可以回收再加以利用, 导致一个操作比测试时间多了20分钟....
AUL恢复Oracle索引结构?
AUL的数据恢复主要关注于数据本身, 象索引结构之类的信息AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 列出表上的索引信息. 除了SYS.USER$和SYS.OBJ$外, 我们还要导出下面几个系统表的数据. unload table sys.ind$ to sys_ind.txt; unload table sys.icol$ to sys_icol.txt; unload table sys.col$ to sys_col.txt; 调用建表角本, 创建表. @IND$_syntax.sql @ICOL$_syntax.sql @COL$_syntax.sql 运行sqlldr将数据导入到新的库,...
Oracle CBO认为Cost为0
在一个分区表上去执行一个SQL时(在Where条件中用了分区列等于的条件, 分区列为主键索引的最后一列), 发现用错了执行计划, Oracle居然认为某个SQL的执行计划的成本为0, 实际上是肯定没有本为0的执行计划的, 因此是明显的不合理的现象. SQLPLAN COST CARD KBYTE PS PE ------------------------------------------------ ---- ---- ----- -- -- 0 SELECT STATEMENT Optimizer=RULE 0 1 0 1 0 SORT (GROUP BY) 1 0 2 1 PARTITION RANGE (SINGLE) 0 1 0 3 3 3 2 ...
TIMESTAMP类型上的索引
Oracle在进行值的大小比较时, 不是我们人脑所想象的那种值比较, 而是将这些值的物理存贮进行字典式的字节比较. 我们来看一下数值1和2的物理存贮. SQL> SELECT DUMP(1) FROM DUAL; Typ=2 Len=2: 193,2 SQL> SELECT DUMP(2) FROM DUAL; Typ=2 Len=2: 193,3 可以看到"1<2"就是象"AB<AC"这样比较的. 对于Timestamp类型也是这样的. SQL> select dump(current_timestamp) as col1 from dual; Typ=188 Len=20: 7,215,12,4,2,15,5,0,7,7,2,224,249,0,5,49,0,0,0,1 SQL> select dump(current_timestamp) as...
更改了Movable Type平台几个表上的索引
观看Movable Type后台的数据库, 发现有些索引建得不是很合理, 基本上是每个列上都建了一个单独的索引, 这一招是很多软件商都采用的办法, 而不管这个列上面的选择性如何. 我主要更改了以下三个表的索引. MT_PLACEMENT表记录了文章所属的类的信息, 更改后的索引结构如下: +--------------------------------+------+-----------------------+ | Key_name | Col | Column_name | +--------------------------------+------+-----------------------+ | PRIMARY | 1 | placement_id | | mt_placement_entry_id | 1 | placement_entry_id | | mt_placement_blog_category_id | 1 | placement_blog_id | | mt_placement_blog_category_id | 2 | placement_category_id | |...
用Stop List来缩小Oracle全文索引的大小
Oracle的全文索引是一个很好的搜索解决方案, 不过随着要搜索的内容的增加, 会发现全文搜索的索引会耗掉很多的空间, 也在一定的程度上影响了全文索引的查询速度. 我们可以用如下方法去看, Oracle是如何划分单词的, 如在CR_CTXDEMO表的COL2列上面建一了个CTXSYS.CONTENT类型的全文索引, 则可以用如下SQL语句去查询: SELECT TOKEN_TEXT, COUNT(*) FROM DR$IDX_CR_CTXDEMO_COL2$I WHERE ROWNUM < 1000000 GROUP BY TOKEN_TEXT HAVING COUNT(*) > 1000 可能会得到如下这样的结果: TOKEN_TEXT COUNT(*) -----------------...
如何获得X$表上的特殊索引信息?
充分利用X$表上的特殊索引, 可以加快对性能视图的访问速度, 从而编译高效的性能监控程序. Oracle提供了一个视图可以用来查询在X$表的那些列上有这样的索引存在, 如下所示: SQL> DESC V$INDEXED_FIXED_COLUMN Name Null? Type -------------------- -------- ------------- TABLE_NAME VARCHAR2(30) INDEX_NUMBER NUMBER COLUMN_NAME VARCHAR2(30) COLUMN_POSITION NUMBER 有时我感觉查询V$SYSSTAT中的记录都有些慢, 看看它上面有没有索引进技术, 先用AUTOTRACE看一下这个视图的X$表是那一个. SQL> SELECT * FROM V$SYSSTAT; ------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |...
USE_CONCAT对X$表有时并不工作
上一次发现访问X$KSLEI时, 用这个Hint很有效, 后来在更多的机器上测试, 发现有的数据库上这个Hint并不工作, 如下所示: SQL> SELECT /*+ USE_CONCAT */ * FROM X$KSLEI WHERE INDX IN (1,2); ---------------------------------------------------- | Id | Operation | Name | Rows | Bytes | ---------------------------------------------------- | 0 | SELECT STATEMENT | | 20 | 1680 | |* 1 | FIXED TABLE...
如何以较好的性能访问Oracle内核表?
Oracle通常在一些内核表的INDX列有特殊的索引, 如果能用到这些索引, 则访问很快, 否则在会话数很多的数据库上很慢. 最简单的访问就是用等于去访问. SQL> SELECT INDX, KSLESWTS,KSLESTIM FROM X$KSLEI WHERE INDX=1; INDX KSLESWTS KSLESTIM ---------- ---------- ---------- 1 0 0 Elapsed: 00:00:00.01 换成IN看看? 有点慢, 因为这时不能使用索引. SQL> SELECT INDX, KSLESWTS,KSLESTIM FROM X$KSLEI WHERE INDX IN (100,200);...
由compute statistics选项引起的性能问题
在数据库中有一个表, 在其上面有一个索引, 现在的情况是没有分析数据的. 如下所示: SQL> SELECT TABLE_NAME, NUM_ROWS, LAST_ANALYZED 2 FROM USER_TABLES WHERE TABLE_NAME='POS_SELL'; TABLE_NAME NUM_ROWS LAST_ANAL ------------------------------ ---------- --------- POS_SELL SQL> SELECT INDEX_NAME, NUM_ROWS, LAST_ANALYZED 2 FROM USER_INDEXES WHERE INDEX_NAME='POS_SELL_IX1'; INDEX_NAME NUM_ROWS LAST_ANAL ------------------------------ ---------- --------- POS_SELL_IX1 ...
Oracle应当增加一种基于Hash算法的索引
Hash是非常高效的一种查找算法, Oracle中的Hash Join更是声名远播, 还有Hash Cluster表, 可以获得很好的性能. 现在的B*Tree结构的索引, 虽然很好, 但在很繁忙的系统中, 还是有一些不足, 比较典型的是在索引的根结点上, 发生Split时很容易引起数据库的问题. 另外从Root块到Branch块, 再到Leaf块, 最后到获得表的记录, 需要访问比较多的结点. 既然Hash算法能用于表, 那么也能用于索引. 因为索引从另外一个角度来说, 也象一个表, 象一个包括了索引列加上ROWID组成的表. 通过这种Hash类型的索引, 第一个可以将读一条记录的Gets减少到2, 同时也没有了Root块和Branch块的Split问题, 实在是值得考虑的一种新的索引类型. 其实通过Context接口, 已经可以很容易地实现这样的功能, 谁有写过自定义的Context索引类型? 在Oracle中Hash Cluster不一定要求字段是数字类型的, 因此支持Hash Index并不需要改动很多吧?...
在Hash表上建普通的B*Tree索引
最近几个人都写Blog来关注Single Table Cluster, 我也来重复一下, 要说明的是可以在Hash表上加普通的索引, 以支持按范围的访问, 演示的角本如下: CREATE CLUSTER HASH_C_DEMO (OBJECT_ID NUMBER) SIZE 50 SINGLE TABLE HASHKEYS 1000; CREATE TABLE T_C_DEMO (OBJECT_ID NUMBER, OBJECT_NAME VARCHAR2(30)) CLUSTER HASH_C_DEMO (OBJECT_ID); CREATE INDEX IDX_T_C_DEMO ON T_C_DEMO (OBJECT_ID); INSERT INTO T_C_DEMO SELECT...
Enable/Disable行内存贮的LOB字段性能分析
定义LOB字段时可以加上ENABLE/DISABLE STORAGE IN ROW的存贮属性, 默认情况下是ENABLE STORAGE IN ROW的, 这种情况除了在值小于4000字节时会将值直接存在行内以提高性能外, 对于再大一点的LOB值的存取也是有性能影响的, 请看下面的在10g版本中做的测试例子, 先建一个表, 包括两个CLOB字段, 并插入一样一样的大于4000字节的值. SQL> create table t_lobtest (col1 clob, col2 clob) 2 lob (col2) store as (disable storage in row); Table created. ASQL> SELECT DBMS_LOB.GETLENGTH(COL1) COL1_LEN, 2 DBMS_LOB.GETLENGTH(COL2) COL2_LEN...
为Primary Key约束指定使用现有索引
几天前接到一个任务在现在的表上建一个索引, 发现这个表的现在有一个主键索引是建在(A,B)这两列上的, 而要建的索引是在(A,B,C)列上的, 主要目标是要让一个执行频率比较高的SQL不去访问表, 以减少逻辑读, 提升性能. 这时你会如何去考虑? 实际在增加约束时是可以指定约束使用那个索引的, 这个主键可以使用新建的这个三个列的索引, 从儿可以删除掉原来的建在两个列上的索引, 以节约空间. 看如下的演示: SQL> CREATE TABLE T_OBJECTS AS 2 SELECT * FROM ALL_OBJECTS WHERE ROWNUM < 1000; Table created. SQL> CREATE INDEX T_OBJECTS_IDX 2 ON T_OBJECTS (OBJECT_ID, OBJECT_NAME); Index...
处理Resource Busy情况的一段角本
对于一些建在更新比较频繁的列上的索引, 或者是有大量记录被删除表上的索引, 需要定期进行Rebuild, 对于比较大表上的索引一般会考虑用一定的并行度去建, 以让索引在更短的时间内建好. 但不要忘了将索引的并行度重新设置为1(禁用并行), 否则很容易让所有的SQL都用并行方式来执行, 从而引起主机崩溃. 在很忙的OLTP系统中, 可能常会遇到Resource Busy的错误, 如何确保修改能最后成功呢? 就需要一段角本来处理一下这个错误, 下面是我常用的一段角本: alter index ...... rebuild ... parallel ... ONLINE; declare resource_busy exception; pragma exception_init (resource_busy,-54); begin loop begin execute immediate 'alter index .........
Oracle 11g中有INDEX_COL这个Hint吗?
当我们进行索引的联机维护(重命名, 改结构, 或删除)时, 会让现有的SQL走了错误的路径, 因为在现有的索引的HINT中一般都直接指明了索引的确切名字, 为了让SQL走新的索引, 你可能不得不去更改SQL中的HINT, 或用Outline来实现, 这样其实并不方便. 另外对于开发人员来说, 他们或许不知道那个索引更好, 但他们一般知道这个表上那个列的可选择性(Selectivity)好一些. 如果有方法能让Oracle的优化器选择某些列或以某些列前导的索引, 对DBA及开发人员都将十分有利. 一年多以前我就想让Oracle加一个INDEX_COL的HINT, 在用时我们只需要指定"index_col(表名, 列, ...)"就行了. 为此我在Google讨论组上发了这个点子, 有人提示我Oracle已经有一个没有公开的HINT来实现这个功能了, 是Jonathan Lewis在10g版本中发现的, 对于这个用法, 我个人十分喜欢, 想不出大师是如何发现这个的? Oracle有内鬼和他相通? 下面是这个HINT的一个用法, 将让Oracle选择以COL1或COL1+COL2列开头的索引(需要做实验验证一下), 但不会选择以COL2列开始的索引, 这一点要注意了, 不过不同的版本中, Oracle会有所更改. 不知道这个功能在Oracle 11g中有没有作出改进?...
你用过Oracle的Global Partition Index吗?
Oracle的分区表也不是十分好用, 当分区的数目比较多时, 很可能让一些不能进行Partition Prune的SQL拥有很高的逻辑读(Consistent Gets), 解决的办法是将一些索引建成全局索引. 现在我们来看一下相反的例子, Oracle中的表是不分区的, 而且访问量最多的SQL是根据一个选择性很好的索引去走的, 每次执行的逻辑读也就只有4-6个了, 因为访问量很高, 如果能降底一个逻辑读的话, 也可能降底整个系统5%-10%的逻辑读, 我们应当从哪儿来考虑呢? 索引的层次(Level)绝对是一个值得研究的角度. 事实上如果我们能让索引的层次(Level)高度降一级, 就可以降低一个逻辑读了, 通过常有以下的方法可用: 1, Rebuild索引. 2, 删除一部份数据后重建索引. 3, 将索引建到一个较大Block Size的表空间中. 4, 建成Global Partitioned索引. 什么是Global Partitioned索引? 指的是在非分区表上建的分区索引, 或者是分区表上但分区方法和表不相同的索引. 通过分区技术, 我们可以将一个大的索引划分为小片, 从而降底索引的层次(Level). 下面来看一下如何在非分区表上建分区索引:...
IOT表中段的命名规律, 以及AUL对IOT的支持
AUL对于IOT表的恢复是支持的, 但需要手工修改一下生成的字典信息. 首先来看一下IOT表的数据段的命名规律. 考虑下面两个IOT表: CREATE TABLE T_IOT ( COL1 NUMBER NOT NULL PRIMARY KEY, COL2 VARCHAR2(20) ) ORGANIZATION INDEX; CREATE TABLE T_IOT2 ( COL1 NUMBER NOT NULL CONSTRAINT PK_T_IOT2 PRIMARY KEY, COL2 VARCHAR2(20) )...
ORA-00600 [qertbFetchBYRowid] & Orphan ROWID
绝对地来说Oracle在更新表时肯定会自动维护索引的, 不过由于程序的Bug(4258825, 4000840)在有些条件下Insert/Delete/Update表的记录后, Oracle没有维护索引, 就好象是这样的情况, 表中有5条记录(ID=1,2,3,4,5), 这时索引是好的, 现在删除ID=5的记录留下四条, 然后Oracle没有维护这个索引还是保留了5条, 当我们发出WHERE ID=5这样的查询时, 就出现问题了啊, 因为根据ROWID找出来的记录是不对的, 这个称为Orphan ROWID. 这样的信息其实在alert_sid.log中会有记录的, 还会报出ROWID的, 验证的方法就是如下所示: select /*+ full(t) */ count(*) from table t where id is not null select /*+ index(t,id列上的索引名) */ count(*)...
如何在较长的文本字段上建立有效的索引?
索引的键值太大的话会影响索引的效率, 还有可能出错. 但有时我们一定要为这字段建索引的话怎么办呢? 我们可以通过计算一个哈希值来实现. 比如有一个字段为NAME, 最长可能有1024个字符, 要在这个列上建一个索引的话, 可以有两种比较好的方法: 增加一个字段, 如HASH_NAME, 用于保存HASH值. 建一个函数索引. 第一种方法需要有一个建在Insert或Update上的触发器来更新HASH_NAME字段, 第二种方法相对简单, 在Oracle的高版本中, 可以用第二种方法. 需要注意的是, 理论上Oracle的这个计算哈希值的算法并不能保证唯一, 因此在查询时需要注意, 需要写两个条件, 如下所示: HASH_NAME = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME=:P_NAME DBMS_UTILITY.GET_HASH_VALUE(NAME) = DBMS_UTILITY.GET_HASH_VALUE(:P_NAME) AND NAME = :P_NAME 另外在数据库升级中,...
站内搜索 | Search
总数: 512 | 留言: 1562
- Name: Fangxin Lou
- MSN: anysql©live.com
- Mail:anysql©yahoo.com
anysql©gmail.com - Skype: anysql
- AIM: loufangxin
- Mobile:008615925611590
分类 | Categories
软件下载:
MSN: loufangxin(a)msn.com, Mail: anysql(at)126.com/support(at)iamdba.com, Skype ID:anysql