普通索引转HASH分区索引报ORA-01408

       ORA-01408:such column list already indexed问题的原因是当新建一个索引时,索引对应的字段和字段顺序和已经存在的索引相同。
       最近一个需求,是将主键索引转成HASH分区的主键索引,需要新建一个索引,然后将现有的主键索引去掉。如果直接新建一个字段相同且字段顺序相同的索引,就会报ORA-01408。当然,可以将现有的主键索引先删掉,但这样在新索引建立之前,无法保证数据的唯一性,并且按主键的更新删除操作会因为无索引而变的很慢。
       我们可以通过建一个中间索引,来保证新建索引前数据的唯一性及按索引更新删除操作的性能。

以下测试:
db:oracle 11.2.0.4

#新建测试表
--DROP TABLE SCOTT.TB_SJ01;
CREATE TABLE SCOTT.TB_SJ01
AS SELECT * FROM DBA_OBJECTS WHERE OBJECT_ID IS NOT NULL;

#为测试表增加主键索引
ALTER TABLE SCOTT.TB_SJ01 ADD CONSTRAINT PK_TB_SJ01 PRIMARY KEY (OBJECT_ID);

#如果直接新建一个索引,报ORA-01408
CREATE UNIQUE INDEX SCOTT.IDX_TB_SJ01 ON SCOTT.TB_SJ01(OBJECT_ID)
GLOBAL PARTITION BY HASH(OBJECT_ID) PARTITIONS 8 ONLINE;
/*
ORA-01408:such column list already indexed
*/

#先新建一个中间索引
CREATE UNIQUE INDEX SCOTT.IDX_TB_SJ01 ON SCOTT.TB_SJ01(OBJECT_ID,1) ONLINE;

#删除原有的主键索引
ALTER TABLE SCOTT.TB_SJ01 DROP CONSTRAINT PK_TB_SJ01 CASCADE;

#新建HASH分区的唯一索引
CREATE UNIQUE INDEX SCOTT.PK_TB_SJ01 ON SCOTT.TB_SJ01(OBJECT_ID)
GLOBAL PARTITION BY HASH(OBJECT_ID) PARTITIONS 8 ONLINE;

#添加新的主键
ALTER TABLE SCOTT.TB_SJ01 ADD CONSTRAINT PK_TB_SJ01 PRIMARY KEY (OBJECT_ID) USING INDEX ;

#删除中间索引
DROP INDEX SCOTT.IDX_TB_SJ01;

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
继续上次分析的一个问题,一个简单的SQL语句执行计划有些奇怪,明明可以走唯一性索引但是却走了另外一个索引。 当然了,最后逐步定位,发现是在直方图的地方有一些差别。取消直方图之后,执行计划立刻恢复了正常。 当然问题来了,这个是为什么呢,收集统计信息中的auto选项是什么含义呢。为什么两个数据类型一样的(varchar2(64))的列,境遇却大大不同。 我们来看看一些统计信息的数据。 为了跟进一步验证数据的分布律和选取代价,我们查询它的直方图信息。 SQL   select to_char(endpoint_v
首先说明_fairness_threshold参数仅在RAC环境下才有意义,让我对这个参数引起关注是在某一次查询v$cr_block_server时,发现该视图有一个名为FAIRNESS_DOWN_CONVERTS的字段,官方文档里将其解释为:Number of times an instance receiving a request has down-converted an X lock on a block because it was not modifying the block 该参数相关性
    今天看到有一个网友提了一个问题,描述很简短     测试DG时,主库不能宕机,如何测试failover?     其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。 而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以

简单分析percona-zabbix-templates - 2016-09-01 04:09:15

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。     我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------

Oracle之不可见索引 - 2016-08-27 17:08:09

Oracle 之不可见索引 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  Oracle 不可见索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新
【故障处理】序列 cache 值过小导致 CPU 利用率过高 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① enq: SQ - contention 等待事件的解决 ② 一般等待事件的解决办法 ③  DFS lock handle 等待事件 ④ 与序列有关的等待事件   Tips: ① 本文在 ITpub ( http://blog.itpub.
这两天做性能测试碰见一个问题,比较有意思。 一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2,  查看V$SQL,发现有两条记录,分别对应了0和1两个child cursor:  再查看这两个child cursor对应的执行计划:  child cursor:0 -----------------------------------------------------------------------------------------------------| I