数据文件offline后unusable索引造成的问题

简介: 最近在做一个oracle入库速度测试时,想到将最近一个小时的索引放到内存中(表是按小时分区)是不是会提升入库的速度,索引的维护对io是一个不小的开销; 不过这个方案如果要使用的话数据库必须是 oracle 12c,因为在当前小时结束后,需要将相关索引移出内存,让下一个小时的索引留在内存,这样内存的使用情况基本是一个定量; 而在移动的过程中不能对业务有影响,这样需要用到12c的新功能,在线移动数据文件。



最近在做一个oracle入库速度测试时,想到将最近一个小时的索引放到内存中(表是按小时分区)是不是会提升入库的速度,索引的维护对io是一个不小的开销;
不过这个方案如果要使用的话数据库必须是 oracle 12c,因为在当前小时结束后,需要将相关索引移出内存,让下一个小时的索引留在内存,这样内存的使用情况基本是一个定量;
而在移动的过程中不能对业务有影响,这样需要用到12c的新功能,在线移动数据文件。

测试的结果是入库速度有很明显的提升,入库速度是之前的几倍,但这个不是本文的重点;本文的重点是在测试的过程中发现的一个小问题,不确定是不是bug(oracle 11.2.0.4也有这个问题),以下是过程。

1.准备工作

创建表空间、用户等
  1. create tablespace dasong datafile '/oradata/oracle/dasong.dbf' size 100m;
    create tablespace dasong_idx2 datafile '/oradata/oracle/dasong_idx2.dbf' size 100m;
    create tablespace dasong_idx3 datafile '/oradata/oracle/dasong_idx3.dbf' size 100m;

    create user dasong identified by dasong
    default tablespace dasong
    temporary tablespace temp;

    grant dba to dasong;
    grant create session to dasong;
    grant resource to dasong;
    grant debug connect session to dasong;
    grant debug any procedure to dasong;
    grant select_catalog_role to dasong;

2.创建表、索引,并插入数据

  1. create table t_idx_offline_test
    (
      c1 number,
      c2 number,
      c3 number
    )
    partition by range(c1) interval(1000)
    (
      partition part_0 values less than(0)
    ) tablespace dasong;

    create index idx_test_c2 on t_idx_offline_test(c2) tablespace dasong_idx2 local;
    create index idx_test_c3 on t_idx_offline_test(c3) tablespace dasong_idx3 local;

    insert into t_idx_offline_test
    select rownum, rownum+1, rownum+2 from dual connect by rownum<10000;
    commit;

3.offline数据文件

  1. alter database datafile '/oradata/oracle/dasong_idx2.dbf' offline for drop;
数据文件offline不会影响索引分区的状态,分区相关的段也是存在的,索引并没有察觉到相关的数据文件已离线
  1. select * from user_ind_partitions;


  1. select * from user_segments;


4.rebuild索引分区

  1. alter index idx_test_c2 rebuild partition sys_p872 tablespace dasong_idx3;
原索引所在数据文件如果不可用,则rebuild失败,因为rebuild会从原索引中读数据,暂不知道怎么样绕过
  1. SQL Error: ORA-00376: file 10 cannot be read at this time
    ORA-01110: data file 10: '/oradata/oracle/dasong_idx2.dbf'
    00376. 00000 -  "file %s cannot be read at this time"
    *Cause:    attempting to read from a file that is not readable. Most likely
               the file is offline.
    *Action:   Check the state of the file. Bring it online

先将原来索引分区unusable(SYS_P872)
  1. alter index idx_test_c2 modify partition sys_p872 unusable;
索引分区 SYS_P872状态变成UNUSABLE


分区 SYS_P872对应的段消失,多出了一个10.130(这个是原来的SYS_P872对应的段


现在rebuild索引分区 到 其它表空间(dasong_idx3),可以成功

  1. alter index idx_test_c2 rebuild partition sys_p872 tablespace dasong_idx3;
rebuild成功可以看到索引分区状态为usable,tablespace是dasong_idx3


对应的新段在dasong_idx3表空间中,原来的10.130并不没有消失(即使将数据文件online,重启数据库,10.130也不会消失)


5.temporary段处理

所有使用索引unusable的操作都会使 索引原来的分区段变成temporary (unusable索引、删除索引、exchange索引分区对应的数据分区 等)
除非删除表空间,其它常规手段都不会删除temporary段(其实此时索引对应的段应该是已经没有了,或是访问不到的,因为数据文件不可用,此时看到的只是元数据)

  1. alter index idx_test_c2 unusable;
  2. alter index idx_test_c2 modify default attributes tablespace dasong_idx3;






  1. drop tablespace dasong_idx2 including contents and datafiles;
索引 idx_test_c2有一个分区在dasong_idx3分区中,所以删除表空间会报错(rebuild之前应该能删除掉表空间,但是including也会把索引删除,这不是我想要的结果)
  1. SQL Error: ORA-14405: partitioned index contains partitions in a different tablespace
    14405. 00000 -  "partitioned index contains partitions in a different tablespace"
    *Cause:    An attempt was made to drop a tablespace which contains indexes
               whose partitions are not completely contained in this tablespace,
               and which are defined on the tables which are completely contained
               in this tablespace.
    *Action:   find indexes with partitions which span the tablespace being
               dropped and some other tablespace(s). Drop these indexes, or move
               the index partitions to a different tablespace, or find the tables
               on which the indexes are defined, and drop (or move) them.

即使  手动删除seg$内容(不确定会不会造成其它问题),user_segments中不再有相关的temporary段 ,此时删除表空间 dasong_idx2 还是会报上面的错,说明数据字典没有清理完全,还是有一部分跟 dasong_idx2相关(数据库还是认为dasong_idx2有索引数据)
  1. delete from seg$ where file#=10 and type#=3;
    commit;



6.删除索引、删除表空间

最后只能先删除索引,再删除表空间,才能清理完对应的数据字典数据。
  1. drop index idx_test_c2;
    drop tablespace dasong_idx2 including contents and datafiles;

暂时没有想出其它的方法来解决这个问题,不过temporary没有清理,也不会影响索引部分分区的rebuild(先unusable,再rebuild),只是看起来比较不舒服,如果可以接受这个的话,此方案还是可以考滤的,毕竟入库速度有好几倍的提升。


目录
相关文章
|
存储 机器学习/深度学习 SQL
图解大数据 | 分布式平台Hadoop与Map-Reduce详解
Hadoop是最基础和场景的开源分布式计算平台,ShowMeAI在本节内容中给大家讲解Hadoop相关知识。
722 0
图解大数据 | 分布式平台Hadoop与Map-Reduce详解
|
12月前
|
数据可视化 Python
Visdom可视化学习笔记(一):通过visdom画曲线和显示图片总结
关于如何使用Visdom进行数据可视化的教程,包括画曲线、显示图片和文本等操作。
337 0
Visdom可视化学习笔记(一):通过visdom画曲线和显示图片总结
|
10月前
|
监控 Linux 网络安全
Zabbix Agent使用介绍
Zabbix Agent使用介绍
422 10
|
11月前
|
缓存 API PHP
PHP性能优化:从基础到高级策略####
深入探索PHP性能优化的多维度策略,本文旨在揭示通过代码优化、配置调整与现代最佳实践相结合的方式,显著提升PHP应用的响应速度和资源利用率。不涉及传统摘要细节,直接聚焦于技术深度与实用技巧,引领读者踏上PHP性能调优的高效之旅。 ####
|
SQL Java 应用服务中间件
Apache Doris 自定义C++ UDF之流程详解(1)
Apache Doris 自定义C++ UDF之流程详解(1)
471 0
|
编译器 C++
VS Code设置C++编译器路径
VS Code设置C++编译器路径
449 0
|
SQL 关系型数据库 MySQL
MySQL数据库——图形化界面工具(DataGrip),SQL(2)-DML(插入、修改和删除数据)
MySQL数据库——图形化界面工具(DataGrip),SQL(2)-DML(插入、修改和删除数据)
1251 1
|
存储 安全 数据安全/隐私保护
DP读书:鲲鹏处理器 架构与编程(九)鲲鹏920处理器片上系统
DP读书:鲲鹏处理器 架构与编程(九)鲲鹏920处理器片上系统
645 0
|
存储 关系型数据库 MySQL
【深入了解Nacos集群和持久化配置】 ——每天一点小知识
【深入了解Nacos集群和持久化配置】 ——每天一点小知识
781 0
|
存储 消息中间件 算法
课时1:可观测(Trace)相关介绍
课时1:可观测(Trace)相关介绍