查看Oracle中表的索引是否存在

用user_indexes和user_ind_columns系统表查看已经存在的索引


对于系统中已经存在的索引我们可以通过以下的两个系统视图(user_indexes和user_ind_columns)来查看其具体内容,例如是属于那个表,哪个列和,具体有些什么参数等等。


user_indexes:     系统视图存放是索引的名称以及该索引是否是唯一索引等信息。

user_ind_column:  系统视图存放的是索引名称,对应的表和列等。

 

查看索引个数和类别:

SQL> select * from user_indexes where table='表名' ;

查看索引被索引的字段:


SQL> select * from user_ind_columns where index_name=upper('&index_name');

 

我们可以通过类似下面的语句来查看一个表的索引的基本情况:

select user_ind_columns.index_name,user_ind_columns.column_name,

user_ind_columns.column_position,user_indexes.uniqueness

from user_ind_columns,user_indexes

where user_ind_columns.index_name = user_indexes.index_name

and user_ind_columns.table_name = ‘你想要查询的表名字’;


通过这条SQL语句我们能查看到一个表的具体的索引的情况,如果你想对这表的索引进行进一步的探究你应该到user_indexes中去具体的看以下这个索引的基本情况。

 

 


完整性约束
  DBA_CONSTRAINTS、ALL_CONSTRAINTS和USER_CONSTRAINST  显示有关约束的一般信息。
  DBA_CONS_COLUMNS、ALL_CONS_COLUMNS和USER_CONS_COLUMNS 显示有关列的相关约束的一般信息。

 

ALL_CONS_COLUMNS 视图和DBA_CONS_COLUMNS 视图与USER_CONS_COLUMNS有相同的列定义。


ALL_CONS_COLUMNS 视图能够显示用户可以访问的所有表上约束的列信息,而不管所有者是谁。
DBA_CONS_COLUMNS 视图列出了整个数据库的列级约束信息。
USER_CONS_COLUMNS

 

user_constraints 和 user_cons_columns表得作用及其联系


user_constraints:  是表约束的视图,描述的是约束类型(constraint_type)是什么,属于哪些表(table_name),如果约束的类型为R(外键)的话,那么r_constraint_name字段存放的就是被引用主表中的主键约束名。  

user_cons_columns: 是表约束字段的视图,说明表中的和约束相关的列参与了哪些约束。这些约束有主键约束,外键约束,索引约束.
 

两者可以通过(owner,constraint_name,table_name)关联:


select 
a.owner 外键拥有者, 
a.table_name 外键表, 
substr(c.column_name,1,127) 外键列, 
b.owner 主键拥有者, 
b.table_name 主键表, 
substr(d.column_name,1,127) 主键列 
from 
user_constraints a, 
user_constraints b, 
user_cons_columns c, 
user_cons_columns d 
where 
    a.r_constraint_name=b.constraint_name 
and a.constraint_type='R' 
and b.constraint_type='P' 
and a.r_owner=b.owner 
and a.constraint_name=c.constraint_name 
and b.constraint_name=d.constraint_name 
and a.owner=c.owner 
and a.table_name=c.table_name 
and b.owner=d.owner 
and b.table_name=d.table_name

数据字典表列说明:

desc user_constraints

Name                                                                                   Comments                                                                    
-----------------                --------------------------------------------------------------------------- 
OWNER                                                                   Owner of the table                                                          
CONSTRAINT_NAME                                             Name associated with constraint definition                                  
CONSTRAINT_TYPE                                              Type of constraint definition                                               
TABLE_NAME                                                          Name associated with table with constraint definition                       
SEARCH_CONDITION                                             Text of search condition for table check                                   
R_OWNER                                                                 Owner of table used in referential constraint                               
R_CONSTRAINT_NAME                                          Name of unique constraint definition for referenced table                   
DELETE_RULE                                                          The delete rule for a referential constraint                                
STATUS                                                                      Enforcement status of constraint -  ENABLED or DISABLED                     
DEFERRABLE                                                           Is the constraint deferrable - DEFERRABLE or NOT DEFERRABLE                 
DEFERRED                                                                 Is the constraint deferred by default -  DEFERRED or IMMEDIATE              
VALIDATED                                                       Was this constraint system validated? -  VALIDATED or NOT VALIDATED         
GENERATED                                         Was the constraint name system generated? -  GENERATED NAME or USER NAME    
BAD                                                                        Creating this constraint should give ORA-02436.  Rewrite it before 2000 AD. 
RELY                                                                                       If set, this flag will be used in optimizer                                 
LAST_CHANGE                                                               The date when this column was last enabled or disabled                      
INDEX_OWNER                                                                The owner of the index used by the constraint                               
INDEX_NAME                                                                    The index used by the constraint                                            
INVALID                                                                                          
VIEW_RELATED      
desc user_cons_columns;


Name                                                                                Comments                                                                                         
--------------- -------------- -------- ------- ------------------------------------------------------------------------------------------------ 
OWNER                                                                         Owner of the constraint definition                                                               
CONSTRAINT_NAME                                               Name associated with the constraint definition                                                   
TABLE_NAME                                                        Name associated with table with constraint definition                                            
COLUMN_NAME                    Name associated with column or attribute of object column specified in the constraint definition 
POSITION                                                                      Original position of column or attribute in definition  


ORACLE的索引和约束详解数据库


Oracle的约束

* 如果某个约束只作用于单独的字段,即可以在字段级定义约束,也可以在表级定义约束,但如果某个约束作用于多个字段,

必须在表级定义约束

* 在定义约束时可以通过CONSTRAINT关键字为约束命名,如果没有指定,ORACLE将自动为约束建立默认的名称

定义primary key约束(单个字段)

create table employees (empno number(5) primary key,...)

指定约束名

create table employees (empno number(5) constraint emp_pk primary key,...)

定义primary key约束(多个字段,在表级定义约束)

create table employees

(empno number(5),

deptno number(3) not null,

constraint emp_pk primary key(empno,deptno)

using index tablespace indx

storage (initial 64K

next 64K

)

)

ORACLE自动会为具有PRIMARY KEY约束的字段(主码字段)建立一个唯一索引和一个NOT NULL约束,定义PRIMARY KEY约束时可以为它的索引

指定存储位置和存储参数

alter table employees add primary key (empno)

alter table employees add constraint emp_pk primary key (empno)

alter table employees add constraint emp_pk primary key (empno,deptno)

not null约束(只能在字段级定义NOT NULL约束,在同一个表中可以定义多个NOT NULL约束)

alter table employees modify deptno not null/null

unique约束

create table employees

( empno number(5),

ename varchar2(15),

phone varchar2(15),

email varchar2(30) unique,

deptno number(3) not null,

constraint emp_ename_phone_uk unique (ename,phone)

)

alter table employees

add constraint emp_uk unique(ename,phone)

using index tablespace indx

定义了UNIQUE约束的字段中不能包含重复值,可以为一个或多个字段定义UNIQUE约束,因此,UNIQUE即可以在字段级也可以在表级定义,

在UNIQUED约束的字段上可以包含空值.

foreign key约束

* 定义为FOREIGN KEY约束的字段中只能包含相应的其它表中的引用码字段的值或者NULL值

* 可以为一个或者多个字段的组合定义FOREIGN KEY约束

* 定义了FOREIGN KEY约束的外部码字段和相应的引用码字段可以存在于同一个表中,这种情况称为"自引用"

* 对同一个字段可以同时定义FOREIGN KEY约束和NOT NULL约束

定义了FOREIGN KEY约束的字段称为"外部码字段",被FORGIEN KEY约束引用的字段称为"引用码字段",引用码必须是主码或唯一码,包含外部码的表称为子表,

包含引用码的表称为父表.

A:

create table employees

(.....,

deptno number(3) NOT NULL,

constraint emp_deptno_fk foreign key (deptno)

references dept (deptno)

)

如果子表中的外部码与主表中的引用码具有相同的名称,可以写成:

B:

create table employees

(.....,

deptno number(3) NOT NULL

constraint emp_deptno_fk references dept

)

注意: 
上面的例子(B)中not null后面没有加逗号,因为这一句的contraint是跟在那一列deptno后面的,属于列定义,所以都无需指明列。而A例中的是表定义,需要指明那一列,所以要加逗号,不能在列后面定义,还可以写成:

create table employees 
(empno char(4), 
deptno char(2) not null constraint emp_deptno_fk references dept, 
ename varchar2(10) 

表定义contraint的只能写在最后,再看两个例子:

create table employees 
(empno number(5), 
ename varchar2(10), 
deptno char(2) not null constraint emp_deptno_fk references dept, 
constraint emp_pk primary key(empno,ename) 
)

create table employees 
( empno number(5), 
ename varchar2(15), 
phone varchar2(15), 
email varchar2(30) unique, 
deptno number(3) not null, 
constraint emp_pk primary key(empno,ename), 
constraint emp_phone_uk unique (phone) 
)

添加foreign key约束(多字段/表级) 
alter table employees 
add constraint emp_jobs_fk foreign key (job,deptno) 
references jobs (jobid,deptno) 
on delete cascade

更改foreign key约束定义的引用行为(delete cascade/delete set null/delete no action), 默认是delete on action

引用行为(当主表中一条记录被删除时,确定如何处理字表中的外部码字段): 
delete cascade : 删除子表中所有的相关记录 
delete set null : 将所有相关记录的外部码字段值设置为NULL 
delete no action: 不做任何操作

先删除原来的外键约束,再添加约束 
ALTER TABLE employees DROP CONSTRAINT emp_deptno_fk; 
ALTER TABLE employees ADD CONSTRAINT emp_deptno_fk FOREIGN KEY(deptno) REFERENCES dept(deptno) ON DELETE CASCADE;

check约束 
* 在CHECK约束的表达式中必须引用到表中的一个或多个字段,并且表达式的计算结果必须是一个布尔值 
* 可以在表级或字段级定义 
* 对同一个字段可以定义多个CHECK约束,同时也可以定义NOT NULL约束 
  
create table employees 
(sal number(7,2) 
constraint emp_sal_ck1 check (sal > 0) 
)

alter table employees 
add constraint emp_sal_ck2 check (sal < 20000)

删除约束

alter table dept drop unique (dname,loc) --指定约束的定义内容 
alter table dept drop constraint dept_dname_loc_uk --指定约束名

删除约束时,默认将同时删除约束所对应的索引,如果要保留索引,用KEEP INDEX关键字 
alter table employees drop primary key keep index

如果要删除的约束正在被其它约束引用,通过ALTER TABLE..DROP语句中指定CASCADE关键字能够同时删除引用它的约束

利用下面的语句在删除DEPT表中的PRIMARY KEY约束时,同时将删除其它表中引用这个约束的FOREIGN KEY约束: 
alter table dept drop primary key cascade

禁用/激活约束(禁用/激活约束会引起删除和重建索引的操作) 
alter table employees disable/enable unique email 
alter table employees disable/enable constraint emp_ename_pk 
alter tabel employees modify constraint emp_pk disable/enable 
alter tabel employees modify constraint emp_ename_phone_uk disable/enable


如果有FOREIGN KEY约束正在引用UNIQUE或PRIMARY KEY约束,则无法禁用这些UNIQUE或PRIMARY KEY约束,

这时可以先禁用FOREIGN KEY约束,然后再禁用UNIQUE或PRIMARY KEY约束;或者可以在ALTER TABLE...DISABLE

语句中指定CASCADE关键字,这样将在禁用UNIQUE或PRIMARY KEY约束的同时禁用那些引用它们的FOREIGN KEY约束,如:

alter table employees disable primary key cascade

约束数据字典

all_constraints/dba_constraints/user_constraints 约束的基本信息,包括约束的名称,类型,状态

(约束类型:C(CHECK约束),P(主码约束),R(外部码约束),U(唯一码约束))

all_cons_columns/dba/user 约束对应的字段信息

Oracle的索引

    索引和对应的表应该位于不同的表空间中,oracle能够并行读取位于不同硬盘上的数据,可以避免产生I/O冲突

B树索引:在B树的叶节点中存储索引字段的值与ROWID。

唯一索引和不唯一索引都只是针对B树索引而言.

Oracle最多允许包含32个字段的复合索引

索引创建策略

1.导入数据后再创建索引

2.不需要为很小的表创建索引

3.对于取值范围很小的字段(比如性别字段)应当建立位图索引

4.限制表中的索引的数目

5.为索引设置合适的PCTFREE值

6.存储索引的表空间最好单独设定

创建不唯一索引

create index emp_ename on employees(ename)

tablespace users

storage(......)

pctfree 0;

创建唯一索引

create unique index emp_email on employees(email)

tablespace users;

创建位图索引

create bitmap index emp_sex on employees(sex)

tablespace users;

创建反序索引

create unique index order_reinx on orders(order_num,order_date)

tablespace users

reverse;

创建函数索引(函数索引即可以是普通的B树索引,也可以是位图索引)

create index emp_substr_empno

on employees(substr(empno,1,2))

tablespace users;

修改索引存储参数(与表类似,INITIAL和MINEXTENTS参数在索引建立以后不能再改变)

alter index emp_ename storage(pctincrease 50);

由于定义约束时由oracle自动建立的索引通常是不知道名称的,对这类索引的修改经常是利用alter table ..using index语句进行的,而不是alter index语句

利用下面的语句将employees表中primary key约束对应的索引的PCTFREE参数修改为5

alter table employees enable primary key using index pctfree 5;

清理索引碎片

1.合并索引(只是简单的将B树叶结点中的存储碎片合并在一起,并不会改变索引的物理组织结构)

alter index emp_pk coalesce;

2.重建索引(不仅能够消除存储碎片,还可以改变索引的全部存储参数设置,并且可以将索引移动到其它的表空间中,重建索引

实际上就是再指定的表空间中重新建立一个新的索引,然后删除原来的索引)

alter index emp_pk rebuild;

删除索引

drop index emp_ename;

如果索引中包含损坏的数据块,或者包含过多的存储碎片,需要首先删除这个索引,然后再重建它.

如果索引是在创建约束时由oracle自动产生的,可以通过禁用约束或删除约束的方法来删除对应的索引.

在删除一个表时,oracle会自动删除所有与该表相关的索引.

索引数据字典

all_indexes/dba_indexes/user_indexes 索引的基本信息

all_ind_columns/dba_ind_columns/user_ind_columns 索引对应的字段信息

 

 

1. 查询一张表里面索引

 

select * from user_indexes where table_name=upper('tableName');

 

2. 查询被索引字段

 

select * from user_ind_columns where index_name=('indexName');

3. 给某一字段创建索引

create index index_name on table_name(col_name);

 

 

1.查看所有用户

     select * from all_users; -------查看所有的用户

     select * from user_users; --------查看当前用户

2.查看用户或角色系统权限:

     select * from user_sys_privs; --------查看当前用户的权限

3.查看角色所包含的权限

     select * from role_sys_privs;   -------

4.查看用户对象权限

     select * from all_tab_privs;   --------查看所用的用户的可操作表权限
     select * from user_tab_privs; --------查看当前用户的表可操作权限

5.查看用户或角色所拥有的角色

     select * from user_role_privs;   ------查看当前用户的角色

     select * from user_constraints where TABLE_NAME='?';    -----查看某一个表的约束

6.查看用户下的索引

   1.  select  * from user_indexes-          -----查看当前用户下的所有索引

   2.  select  * from user_indexes where table_name='A';      -----查看当前用户下表A的索引
      (drop index index_name去掉索引) 

   3. select index_name,index_type,status,blevel from user_indexes where table_name = '?';  

           -----查看某一个表的所有索引

   4.  select table_name, index_name, column_name, column_position from        user_ind_columns where  table_name='?';    ----查看索引的构成

 7. 建索引

       create unique clustered index 索引名on 表名(字段1)  --单索引

       Create index 索引名 on 表名(字段1,字段2)  -------复合索引


  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
一、重建索引的前提 1、表上频繁发生update,delete操作; 2、表上发生了alter table ..move操作(move操作导致了rowid变化)。 二、重建索引的标准 1、索引重建是否有必要,一般看索引是否倾斜的严重,是否浪费了空间, 那应该如何才可以判断索引是否倾斜的严重,是否浪费了空间, 对索引进行结构分析(如下): SQL>Analyze index index_name validate structure; 2、在执行步骤1的session中查询index_stats表,不要到别的session去查询SQL>select height,DEL_LF_ROWS/LF_ROWS from index_stats; 说明:当 查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 。 举例: (t_gl_assistbalance 26 万多条信息 ) SQL> select count(*) from t_gl_assistbalance ; 输出结果: COUNT(*) ---------- 265788 SQL> Analyze index IX_GL_ASSTBAL_1 validate structure; Index analyzed SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; 输出结果: HEIGHT DEL_LF_ROWS/LF_ROWS ---------- ------------------- 4 1 三、重建索引的方式 1、drop 原来的索引,然后再创建索引; 举例: 删除索引:drop index IX_PM_USERGROUP; 创建索引:create index IX_PM_USERGROUP on T_PM_USER (fgroupid); 说明:此方式耗时间,无法在24*7环境中实现,不建议使用。 2 、直接重建: 举例: alter index indexname rebuild; 或alter index indexname rebuild online; 说明:此方式比较快,可以在24*7环境中实现,建议使用此方式。 四、alter index rebuild 内部过程和注意点 alter index rebuild 和alter index rebuil online的区别 1、扫描方式不同 1.1、Rebuild以index fast full scan(or table full scan) 方式读取原索引中的数据来构建一个新的索引,有排序的操作; 1.2、rebuild online 执行表扫描获取数据,有排序的操作; 说明:Rebuild 方式 (index fast full scan or table full scan 取决于统计信息的cost) 举例1 SQL> explain plan for alter index IX_GL_ASSTBAL_1 rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | INDEX FAST FULL SCAN | IDX_POLICY_ID2 | 999K| 4882K| | --------------------------------------------------------------------- 举例2 SQL> explain plan for alter index idx_policy_id rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 2072K| 9M| 461 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID | | | | | 2 | SORT CREATE INDEX | | 2072K| 9M| | | 3 | TABLE ACCESS FULL | TEST_INDEX | 2072K| 9M| 461 | 举例3 ( 注意和 举例1 比较 ) Rebuil online 方式 : SQL> explain plan for alter index idx_policy_id2 rebuild online; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------| 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | TABLE ACCESS FULL | TEST_INDEX2 | 999K| 4882K| 3219 | 2 、rebuild 会阻塞 dml 操作 ,rebuild online 不会阻塞 dml 操作 ; 3 、rebuild online 时系统会产生一个 SYS_JOURNAL_xxx 的 IOT 类型的系统临时日志表 , 所有 rebuild online 时索引的变化都记录在这个表中 , 当新的索引创建完成后 , 把这个表的记录维护到新的索引中去 , 然后 drop 掉旧的索引 ,rebuild online 就完成了。 注意点: 1、 执行rebuild操作时,需要检查表空间是否足够; 2、虽然说rebuild online操作允许dml操作,但是还是建议在业务不繁忙时间段进行; Rebuild操作会产生大量redo log ; 五、重建分区表上的分区索引 重建分区索引方法: Alter index indexname rebuild partition paritionname tablespace tablespacename; Alter index indexname rebuild subpartition partitioname tablespace tablespacename; Partition name 可以从user_ind_partitions查找 Tablepace 参数允许alter index操作更改索引的存储空间; 六、索引状态描述 在数据字典中查看索引状态,发现有三种: valid:当前索引有效 N/A :分区索引 有效 unusable:索引失效 七、术语 1、高基数:简单理解就是表中列的不同值多。 2、低基数:建单理解就是表中的列的不同值少。 3、以删除的叶节点数量:指得是数据行的delete操作从逻辑上删除的索引节点 的数量,要记住oracle在删除数据行后,将 “ 死 “ 节点保留在索引中,这样做可以加快sql删除操作的速度,因此oracle删除数据行后可以不必重新平衡索引。 4、索引高度:索引高度是指由于数据行的插入操作而产生的索引层数,当表中添加大量数据时,oracle将生成索引的新层次以适应加入的数据行,因此,oracle索引可能有4层,但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目,而具备4层或是更多层的需要重建。 5、每次索引访问的读取数:是指利用索引读取一数据行时所需要的逻辑I/O操作数,逻辑读取不必是物理读取,因为索引的许多内容已经保存在数据缓冲区,然而,任何数据大于10的索引都需要重建。 6、什么时候重建呢? 察看 dba_indexes 中的 blevel 。这列是说明索引从根块到叶快的级别,或是深度。如果级别大于等于4。则需要重建, 如下 :Select index_name,blevel from dba_indexes where blevel>=4. 另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时,也应当重建,如下 SQL>analyze index index_name validate structure SQL>select (del_lf_rows_len/lf_rows_len)*100 from index_stats where name= ’ index_name ’ 就能看到是否这个索引被删除的百分比。 7、什么样的重建方式更好? (1)、建索引的办法: 1.1、删除并从头开始建立索引。 1.2 、 使用 alter index index_name rebuild 命令重建索引。 1.3 、 使用 alter index index_name coalesce 命令重建索引。 (2)、下面讨论一下这三种方法的优缺点: 2.1、删除并从头开始建索引:方法是最慢的,最耗时的。一般不建议。 2.2、Alter index index_name rebuild 快速重建索引的一种有效的办法,因为使用现有索引项来重建新索引,如果客户操作时有其他用户在对这个表操作,尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题,alter index index_name rebuild online。 但是,由于新旧索引在建立时同时存在,因此,使用这种技巧则需要有额外的磁盘空间可临时使用,当索引建完后把老索引删除,如果没有成功,也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的表空间。 Alter index index_name rebuild tablespace tablespace_name 。 这个命令的执行步骤如下: 首先,逐一读取现有索引,以获取索引的关键字。 其次,按新的结构填写临时数据段。 最后,一旦操作成功,删除原有索引树,降临时数据段重命名为新的索引。 需要注意的是alter index index_name rebuild 命令中必须使用tablespace字句,以保证重建工作是在现有索引相同的表空间进行。 2.3、alter index index_name coalesce 使用带有coalesce参数时重建期间不需要额外空间,它只是在重建索引时将处于同一个索引分支内的叶块拼合起来,这最大限度的减少了与查询过程中相关的潜在的加锁问题,但是,coalesce选项不能用来将一个索引转移到其他表空间。 八、其他 1、truncate 分区操作和truncate 普通表的区别? 1.1、Truncate 分区操作会导致全局索引失效; truncate 普通表对索引没有影响; 1.2、Truncate 分区操作不会释放全局索引中的空间,而truncate 普通表会释放索引所占空间; 2、rename 表名操作对索引没有影响,因为rename操作只是更改了数据字典,表中数据行的rowid并没有发生变化 总结: 1、判断是否需要重建索引SQL>analyze index index_name validate structure; SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; ( 或 Select index_name,blevel from dba_indexes where blevel>=4 ); 说明 : 当查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 ; 2 、重建索引方法 : 方法一、 Alter index index_name rebuild tablespace tablespace_name; 优点:是快速重建索引的一种有效的办法,可以用来将一个索引移到新的表空间。 缺点:重建期间需要额外空间。 方法二、 alter index index_name coalesce; 优点:重建期间不需要额外空间。 缺点:coalesce选项不能用来将一个索引转移到其他表空间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值