不可用索引

本文通过实验演示了在Oracle数据库中移动表后索引变为不可用的原因,并介绍了如何重建索引使其恢复可用状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    本文并不是要说明如何把索引标记为不可用(unusable)或者如何使不可用索引恢复到可用状态,而是要看看当索引变成不可用状态时会有什么出现什么情况。在进入主题之前,我们先来简单探讨一下什么是索引。表的索引是按一定顺序(默认为升序排列)存储表列值以及RowID值的数据结构,是供使用者快速查找数据的“指路人”。

  可以在索引创建脚本设置设置列排序,如下:

  create index temp_jp_idx on temp_jp(col1 asc);

  create index temp_jp_idx on temp_jp(col1 desc);

  那RowID又是什么呢?一个RowID就是用来标识表中一行的伪列,代表了这一行在表中的物理位置。在Oracle 9i以后的版本中,RowID的格式均为扩展RowID格式,如 <object id><file id><block id><row number>(对象ID>文件ID>块ID>行号),其显示形式为OOOOOOFFFBBBBBBRRR。

  如果在运行某项操作时,表中数据的物理位置改变了,那么数据库就会将该表的索引标记为不可用,为什么会这样呢?在表中的数据被移动后,当前的数据RowID指向了新的物理位置。而索引中旧的RowID还是和执行移动命令前的一样仍然指向旧的物理位置,而那个位置已经没有任何数据了。这样,Oracle就无法通过存有无效RowID的索引来访问检索数据了。因此,Oracle数据库会在执行了移动命令以后把该表的所有索引都标记为不可用。

  为了更好的理解这个问题,我们可以进行一个模拟测试。

 

drop table temp_jp;
drop table temp_rowids_jp;
create table temp_jp(col1 number,col2 varchar2(20)) tablespace users1;
insert into temp_jp values(1,'RAMA');
insert into temp_jp values(3,'SITA');
insert into temp_jp values(2,'LAKSHMAN');
commit;
set autot on exp
select * from temp_jp where col1=3;
      COL1 COL2
---------- --------------------
         3 SITA
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=1 Bytes=25)
   1    0   TABLE ACCESS (FULL) OF 'TEMP_JP' (TABLE) (Cost=3 Card=1 Bytes=25)

 

  Oracle对temp_jp表执行了一次全表扫描,显示该表没有索引。下面为temp_jp表创建一个索引。

 

create index temp_jp_idx on temp_jp(col1 asc);
set autot on exp
select * from temp_jp where col1=3;
      COL1 COL2
---------- --------------------
         3 SITA
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TEMP_JP' (TABLE) (Cost=2  Card=1 Bytes=25)
   2    1     INDEX (RANGE SCAN) OF 'TEMP_JP_IDX' (INDEX) (Cost=1 Card  =1)

 

接下来,使用temp_jp_idx索引来访问表temp_jp的数据。

 

select index_name, status  from dba_indexes where table_name='TEMP_JP';
INDEX_NAME                     STATUS
------------------------------ --------
TEMP_JP_IDX                    VALID

 

  temp_jp_idx索引是有效索引,在检索表temp_jp的数据时,Oracle会使用该索引。下面找出表temp_jp数据的当前RowID。

 

 

 

select rowid,a.* from temp_jp a;
ROWID                    COL1 COL2
------------------ ---------- --------------------
AAA16tAAEAAAADoAAA          1 RAMA
AAA16tAAEAAAADoAAB          3 SITA
AAA16tAAEAAAADoAAC          2 LAKSHMAN

 

  在移动表数据之前,我们先来保存从temp_jp表得到的当前RowID,以便稍后进行对照参考。

  create table temp_rowids_jp as select col1,rowid as before_move_rowid from temp_jp;

  从RowID找出相应的对象id、文件id和行号:

 

select dbms_rowid.rowid_object(rowid) "object",
      dbms_rowid.rowid_relative_fno(rowid) "file",
      dbms_rowid.rowid_block_number(rowid) "block",
      dbms_rowid.rowid_row_number(rowid) "row" from temp_jp
    /
    object       file      block        row
---------- ---------- ---------- ----------
    220845          4        232          0
    220845          4        232          1
    220845          4        232          2

 

  接着,从dba_object中找到ID为220845的对象所有者、对象名和对象类型。

 

select object_id,owner, object_name, object_type,created from dba_objects where object_id = 220845;
OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED
---------   ------ ---------------  ------------------- ---------
   220845   SCOTT  TEMP_JP          TABLE             30-MAR-08
select object_id,owner,object_name,object_type,created 
   from dba_objects  where created > trunc(sysdate) -1/24;
OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED
---------   ------ ---------------  ------------------- ---------
   220846   SCOTT  TEMP_JP_IDX       INDEX              30-MAR-08
   220845   SCOTT  TEMP_JP           TABLE              30-MAR-08
   220847   SCOTT  TEMP_ROWIDS_JP    TABLE              30-MAR-08
select object_id,owner,object_name,object_type,created 
from dba_objects   where object_id in (select max(object_id) from dba_objects);
OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED
---------   ------ ---------------  ------------------- ---------
   220847   SCOTT  TEMP_ROWIDS_JP    TABLE              30-MAR-08

 

接下来,让我们用当前的RowID来查询表temp_jp的数据。

 

select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB';
      COL1 COL2
---------- --------------------
         3 SITA

 

  结果显示,RowID正确地指向了表temp_jp相应行的位置。表temp_jp的temp_jp_idx索引存储了该表数据的正确RowID。从RowID算得的object_id已经转换到正确的表了。使用RowID可以准确的访问该表的数据。

  这样,我们就可以开始测试了,将该表移动到另外一个表空间,然后看看会出现什么情况。

 

 

alter table temp_jp move tablespace users2;
SQL> select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB';
select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'
              *
ERROR at line 1:
ORA-01410: invalid ROWID

 

  表被移走后,其RowID也改变了。旧的RowID不再指向该表的实际数据了。在移动之前,我们使用RowID对表temp_jp进行select查询是可以得到正确的查询结果的,而现在则出现查询失败的错误信息。

  现在让我们再来找找执行了move命令之后表temp_jp数据现在的RowID。

 

select rowid,a.* from temp_jp a;
ROWID                       COL1        COL2
------------------          ---------- --------------------
AAA16wAAMAAAC+MAAA          1           RAMA
AAA16wAAMAAAC+MAAB          3           SITA
AAA16wAAMAAAC+MAAC          2           LAKSHMAN

 

  从查询结果可以看到,执行完move命令后,该表的RowID也已经发生了变化。根据上文介绍的RowID定义,我们知道它的表现形式包含了。自该表从users1表空间移动到users2表空间后,这些行的物理属性,如file_id和block_id,都发生了改变。因此其该表的RowID也变了。我们可以从新的RowID计算出执行完move命令后该表的object_id、 file_id、block_id和行号。

 

select dbms_rowid.rowid_object(rowid) "object",
          dbms_rowid.rowid_relative_fno(rowid) "file",
          dbms_rowid.rowid_block_number(rowid) "block",
          dbms_rowid.rowid_row_number(rowid) "row" from temp_jp
 /
 object       file      block        row
 --------- ---------- ---------- ----------
 220848         12      12172          0
 220848         12      12172          1
 220848         12      12172          2

 

执行完move命令后,Oracle为该表指定了一个新的object_id。属于users2表空间的文件号为12。当前的块ID为12172。而行号还保持和原来一样。Move命令改变了表的位置,但没有改变表内行的排列顺序。接下来,我们还可以用新的object_id来查找该对象的详细信息。

  select object_id,owner, object_name, object_type,created from dba_objects where object_id = 220848;

  no rows selected

  从执行move命令后的新RowID得到了object_id没有检索到该对象的详细信息。相反,从dba_objects视图看该表的对象ID表现为执行move命令前的旧object_id。

 

 

select object_id,owner, object_name, object_type,created from dba_objects
where object_name = 'TEMP_JP';
OBJECT_ID   OWNER  OBJECT_NAME      OBJECT_TYPE         CREATED
---------   ------ --------------- -------------------  ---------
220845      SCOTT  TEMP_JP          TABLE               30-MAR-08

 

  这可能是Oracle数据库的一个漏洞。我们来查找一下在过去一小时内创建的对象:

 

select object_id,owner,object_name,object_type,created 
from dba_objects  where created > trunc(sysdate) -1/24;
OBJECT_ID OWNER  OBJECT_NAME     OBJECT_TYPE           CREATED
--------- ------ --------------- -------------------   ---------
220846    SCOTT  TEMP_JP_IDX      INDEX                30-MAR-08
220845    SCOTT  TEMP_JP          TABLE                30-MAR-08
220847    SCOTT  TEMP_ROWIDS_JP   TABLE                30-MAR-08
select object_id, owner, object_name, object_type, created 
from dba_objects where object_id in (select max(object_id) from dba_objects);
OBJECT_ID OWNER   OBJECT_NAME     OBJECT_TYPE          CREATED
--------- ------- -------------   -------------------  ---------
220847    SCOTT   TEMP_ROWIDS_JP  TABLE                30-MAR-08

 

  用新的RowID来查询表temp_jp:

 

select * from temp_jp where rowid = 'AAA16wAAMAAAC+MAAB';
      COL1 COL2
---------- --------------------
         3 SITA

 

  我们用新RowID能够从该表查询到数据。但是,从新RowID得到的objectid并不能检索到对象的详细信息。从这点看来,Oracle并没有使用从目前的RowID得到的objectid来检索该表的数据,而是使用fileid、blockid和行号来访问表数据。

  那么让我们来看看执行完move命令后表temp_jp的索引状态。

 

select index_name, status from dba_indexes where table_name='TEMP_JP';
INDEX_NAME                     STATUS
------------------------------ --------
TEMP_JP_IDX                    UNUSABLE
 set autot on exp
 select * from temp_jp where col1=3;
      COL1    COL2
----------    --------------------
         3    SITA
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)
   1    0   TABLE ACCESS (FULL) OF 'TEMP_JP' (TABLE) (Cost=2 Card=1 Bytes=25)

 


由于表temp_jp已有的索引无法使用,我们先对该表进行了一次全表扫描。正如你所想到的,表temp_jp的索引仍然存储着无效的RowID。现在,让我们来看看我们用旧的RowID能不能检索到数据。

 

 

SQL> select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB';
select * from temp_jp where rowid = 'AAA16tAAEAAAADoAAB'
              *
ERROR at line 1:
ORA-01410: invalid ROWID

 

  旧的RowID不再指向该表各行的正确物理位置。而索引temp_jp_idx仍保留着执行move命令前旧的无效RowID,所以,Oracle把这些索引标记为不可用。不过,我们还是可以用新的RowID来访问该表的数据。

 

select * from temp_jp where rowid = 'AAA16wAAMAAAC+MAAB';
      COL1 COL2
---------- --------------------
         3   SITA

 

  让我们来比较一下执行move命令前后表temp_jp的RowID有什么不同。

 

select a.col1, a.before_move_rowid,b.rowid after_move_rowid
 from temp_rowids_jp a, temp_jp b where a.col1 = b.col1;
     COL1  BEFORE_MOVE_ROWID          AFTER_MOVE_ROWID
---------   ------------------         ------------------
        1   AAA16tAAEAAAADoAAA         AAA16wAAMAAAC+MAAA
        3   AAA16tAAEAAAADoAAB         AAA16wAAMAAAC+MAAB
        2   AAA16tAAEAAAADoAAC         AAA16wAAMAAAC+MAAC

 

  正如之前所说的,在执行了move命令之后,该表转移到了另外一个表空间,而objectid、fileid和blockid都已经发生了变化。由于表内的数据在表移动的过程中并没有发生改变,所以行号仍保留原样。

  为了修复不可用索引,用新的正确的RowID来重新生成temp_jp_idx索引即可

 

alter index temp_jp_idx rebuild online;
select index_name, status from dba_indexes where table_name='TEMP_JP';
INDEX_NAME                      STATUS
------------------------------  --------
TEMP_JP_IDX                     VALID
After rebuilding the unusable index, the index is validated.
set autot on exp
select * from temp_jp where col1=3;
      COL1       COL2
      ---------- --------------------
               3 SITA
      
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=25)
   1    0 TABLE ACCESS (BY INDEX ROWID) OF 'TEMP_JP' (TABLE) (Cost=2   Card=1 Bytes=25)
   2    1 INDEX (RANGE SCAN) OF 'TEMP_JP_IDX' (INDEX) (Cost=1 Card  =1)

 

  重新生成索引后,就可以使用该索引来对表temp_jp进行select查询了。

  记住,当你要移动一个表时,该表的索引会被标记为不可用,但通过重新生成指令来将索引转移到新的物理位置时,索引就可以恢复可用性了。

<think>好的,我现在需要解决用户在JetBrains IntelliJ IDEA中遇到的“索引更新意图可用”的问题。用户提到在更新索引时出现这个问题,我需要给出有效的解决方案。首先,我应该回忆一下常见的IDEA索引问题及其解决方法。 首先,索引问题通常与缓存有关。IDEA在运行过程中会生成许多缓存文件,这些文件如果损坏可能导致各种问题,包括索引更新失败。因此,清理缓存并重启是一个常见的初步解决方案。用户可以通过“File”菜单下的“Invalidate Caches”选项来执行此操作,然后选择“Invalidate and Restart”。这能确保所有缓存文件被删除并重新生成,可能解决索引问题。 接下来,需要检查项目的文件系统是否正常。如果项目中有损坏的文件或符号链接,可能会影响索引过程。用户可以通过“File”菜单中的“Repair IDE”来尝试修复这些问题。此外,手动检查项目目录中的异常文件,如过大的文件或无法读取的文件,也是一个好方法。 然后,考虑重新构建索引。IDEA有时在索引大型项目时可能卡住或出错,手动触发重新索引可能有效。用户可以在“File”菜单中选择“Invalidate Caches”,然后勾选“Clear file system cache and Local History”和“Clear VCS Log caches and indexes”,再重启IDEA。这会让IDEA从头开始重建索引,可能解决中断或损坏的索引。 如果问题依旧,可能需要检查IDE的日志文件。日志通常位于用户主目录下的“~/.IntelliJIdeaXX/log”(XX代表版本号),查看最近的日志是否有错误信息,例如内存足或文件权限问题。根据日志中的具体错误,可以进一步调整内存设置或检查文件权限。 另外,确保IDEA和项目插件都是最新版本也很重要。过时的软件可能存在已知的bug,更新到最新版本可以修复这些问题。用户可以通过“Help”菜单中的“Check for Updates”来检查更新。 如果问题仍然存在,可能需要重新导入项目。关闭当前项目,选择“File”->“Close Project”,然后重新导入项目,让IDEA重新建立索引。有时候项目配置可能损坏,重新导入可以解决。 最后,如果所有方法都无效,可能需要联系JetBrains支持。提供日志文件和问题描述,他们可以给出更专业的帮助。同时,用户提到的引用中提到了.idea目录的潜在问题,检查是否有权限问题或目录损坏也是必要的。例如,确保项目目录没有访问限制,或者尝试从备份中恢复.idea文件夹。 总结以上步骤,用户需要逐步排查缓存、文件系统、索引重建、日志检查、软件更新、项目重新导入等方面,以解决索引更新意图可用的问题。</think>### 解决IntelliJ IDEA索引更新意图可用的分步指南 #### 1. **清理缓存并重启IDE** - **步骤**:点击菜单栏 `File` → `Invalidate Caches` → 选择 `Invalidate and Restart`。 - **原因**:索引文件可能因缓存损坏导致更新失败,清理缓存能强制IDE重新生成索引[^1]。 #### 2. **检查文件系统完整性** - **步骤**: 1. 通过 `File` → `Repair IDE` 运行修复工具。 2. 手动检查项目目录中是否存在损坏的符号链接或超大文件(如日志文件)。 - **原因**:异常文件可能导致索引中断[^3]。 #### 3. **手动触发完整索引重建** - **步骤**: 1. 关闭当前项目。 2. 删除项目目录下的 `.idea` 文件夹(备份后操作)[^3]。 3. 重新导入项目,IDE会自动重新生成索引。 - **替代方法**:在 `File` → `Invalidate Caches` 中勾选 `Clear VCS Log caches and indexes` 后重启。 #### 4. **检查IDE日志** - **日志路径**:`~/.IntelliJIdea<版本>/log/idea.log` - **操作**:搜索日志中的 `Indexing` 相关错误,如: ```log 2023-10-01 12:00:00,123 ERROR - index.CorruptedException: Corrupted index for file xxx ``` - **解决方法**:根据日志提示调整内存(如修改 `Help` → `Edit Custom VM Options` 中的 `-Xmx` 参数)或修复文件权限。 #### 5. **更新IDE和插件** - **步骤**:通过 `Help` → `Check for Updates` 升级到最新版本。 - **原因**:旧版本可能存在索引相关的已知问题,JetBrains在2024.2版本优化了云代码补全的索引机制[^1]。 #### 6. **重新导入项目** - **步骤**: 1. 关闭当前项目。 2. 通过 `File` → `New` → `Project from Existing Sources` 重新选择项目目录。 - **效果**:避免因`.idea`配置损坏导致的索引问题。 #### 7. **检查防病毒/防火墙设置** - **场景**:若索引卡在特定文件,可能是安全软件阻止了IDE的读写权限。 - **操作**:将IDE安装目录和项目目录加入白名单。 #### 8. **联系JetBrains支持** - **步骤**:通过 `Help` → `Submit Feedback` 提交日志和问题描述。 - **补充**:附上可复现问题的示例项目(如敏感信息需脱敏)。 --- ### 相关问题 1. **如何优化IntelliJ IDEA的索引速度?** - 可调整内存分配、排除非代码目录(如`build/`)、使用更快的存储设备。 2. **`.idea`目录泄露会导致哪些安全风险?** - 可能暴露项目结构、API密钥路径等敏感信息,需在部署时删除[^2][^3]。 3. **索引失败是否会影响代码补全功能?** - 是的,JetBrains AI依赖完整索引提供准确的代码建议。 --- : JetBrains AI Assistant 2024.2 对云代码补全引入了重大增强,以提供更准确、更快速的建议。 : GitHub - lijiejie/idea_exploit: Gather sensitive information from (.idea) folder for pentesters [^3]: JetBrains .idea项目目录泄露。网站存在JetBrains系列IDE的工作区文件,可以泄露整个工程的目录结构信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值