SQL load direct path load index 无效的原因

2024-04-20 14:44

本文主要是介绍SQL load direct path load index 无效的原因,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Index (unique) state changing to unusable status after data loading using SQL*Loader. The steps below are executed to load the data:

1/ disable constraint--如果不是单独建的index, 对应index会drop掉的
2/ load data using SQL*Loader
3/ remove duplicate records
4/ enable constraint

The execution of step 3 fails due to an index in unusable state:

\n removing duplicate records from the table ... \n
DELETE FROM <TABLE_NAME1> WHERE rowid not in (SELECT MIN(rowid) FROM <TABLE_NAME1> GROUP BY <COLUMN_NAME>)---rowid在期间不能有table move 操作
*
ERROR at line 1:
ORA-01502: index '<INDEX_NAME>_PK' or partition of such index is
in unusable state

Checking the available indexes and their status from dba_indexes, we have:

INDEX_NAMEINDEX_TYPESTATUSTABLE_NAME
<INDEX_NAME>_PKNORMALUNUSABLE<TABLE_NAME1>
<INDEX_NAME>_PKNORMALVALID<TABLE_NAME2>

CHANGES

CAUSE

Some integrity constraints are automatically disabled During a direct path load. The constraints that remain enabled during a direct path load are:

- NOT NULL
- UNIQUE
- PRIMARY KEY (unique-constraints on not-null columns)--PK自动not null

这么说不就是外键 check disable了


- NOT NULL constraints are checked at column array build time. Any row that violates the NOT NULL constraint is rejected.

Even though UNIQUE constraints remain enabled during direct path loads, any row that violates those constraints is loaded anyway (this is different than in conventional path in which such rows would be rejected).
When indexes are rebuilt at the end of the direct path load, UNIQUE constraints are verified and if a violation is detected, then the index will be left in an unusable state.

不拒绝

Indexes Left in an Unusable State
------------------------------------------------
SQL*Loader leaves indexes in an Index Unusable state when the data segment being loaded becomes more up-to-date than the index segments that index it.
Any SQL statement that tries to use an index that is in an Index Unusable state returns an error. The following conditions cause a direct path load to leave an index or a partition of a partitioned index in an Index Unusable state:

  - SQL*Loader runs out of space for the index and cannot update the index.
  - The data is not in the order specified by the SORTED INDEXES clause.
  - There is an instance failure, or the Oracle shadow process fails while building the index.
  - There are duplicate keys in a unique index.
  - Data savepoints are being used, and the load fails or is terminated by a keyboard interrupt after a data savepoint occurred.

Hence this is a expected behavior as:

- Some duplicate rows are getting loaded and indexes are going to unusable state when unique indexes are used.
  - Or -
- SQL*Loader leaves indexes in an Index Unusable state when the data segment being loaded becomes more up-to-date than the index segments that index it.
 

SOLUTION

To overcome the issue:

  • In few cases using conventional path load has resolved the issue.

          - Or -

  • Using normal index instead of unique index will not affect the index status.
  • 先建立普通index 加unique key 控制

          - Or -

  • One can follow below workaround for unique indexes.
  • 本来是个死局,重复的删不了,index不能rebuild,只有drop,

    - Drop the offending index and load the data.
    - Detect duplicate rows
    - Remove the duplicate rows and recreate the index.

这篇关于SQL load direct path load index 无效的原因的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/920543

相关文章

MySQL的JDBC编程详解

《MySQL的JDBC编程详解》:本文主要介绍MySQL的JDBC编程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录前言一、前置知识1. 引入依赖2. 认识 url二、JDBC 操作流程1. JDBC 的写操作2. JDBC 的读操作总结前言本文介绍了mysq

java.sql.SQLTransientConnectionException连接超时异常原因及解决方案

《java.sql.SQLTransientConnectionException连接超时异常原因及解决方案》:本文主要介绍java.sql.SQLTransientConnectionExcep... 目录一、引言二、异常信息分析三、可能的原因3.1 连接池配置不合理3.2 数据库负载过高3.3 连接泄漏

Linux下MySQL数据库定时备份脚本与Crontab配置教学

《Linux下MySQL数据库定时备份脚本与Crontab配置教学》在生产环境中,数据库是核心资产之一,定期备份数据库可以有效防止意外数据丢失,本文将分享一份MySQL定时备份脚本,并讲解如何通过cr... 目录备份脚本详解脚本功能说明授权与可执行权限使用 Crontab 定时执行编辑 Crontab添加定

MySQL中On duplicate key update的实现示例

《MySQL中Onduplicatekeyupdate的实现示例》ONDUPLICATEKEYUPDATE是一种MySQL的语法,它在插入新数据时,如果遇到唯一键冲突,则会执行更新操作,而不是抛... 目录1/ ON DUPLICATE KEY UPDATE的简介2/ ON DUPLICATE KEY UP

MySQL分库分表的实践示例

《MySQL分库分表的实践示例》MySQL分库分表适用于数据量大或并发压力高的场景,核心技术包括水平/垂直分片和分库,需应对分布式事务、跨库查询等挑战,通过中间件和解决方案实现,最佳实践为合理策略、备... 目录一、分库分表的触发条件1.1 数据量阈值1.2 并发压力二、分库分表的核心技术模块2.1 水平分

Python与MySQL实现数据库实时同步的详细步骤

《Python与MySQL实现数据库实时同步的详细步骤》在日常开发中,数据同步是一项常见的需求,本篇文章将使用Python和MySQL来实现数据库实时同步,我们将围绕数据变更捕获、数据处理和数据写入这... 目录前言摘要概述:数据同步方案1. 基本思路2. mysql Binlog 简介实现步骤与代码示例1

使用shardingsphere实现mysql数据库分片方式

《使用shardingsphere实现mysql数据库分片方式》本文介绍如何使用ShardingSphere-JDBC在SpringBoot中实现MySQL水平分库,涵盖分片策略、路由算法及零侵入配置... 目录一、ShardingSphere 简介1.1 对比1.2 核心概念1.3 Sharding-Sp

深度剖析SpringBoot日志性能提升的原因与解决

《深度剖析SpringBoot日志性能提升的原因与解决》日志记录本该是辅助工具,却为何成了性能瓶颈,SpringBoot如何用代码彻底破解日志导致的高延迟问题,感兴趣的小伙伴可以跟随小编一起学习一下... 目录前言第一章:日志性能陷阱的底层原理1.1 日志级别的“双刃剑”效应1.2 同步日志的“吞吐量杀手”

MySQL 表空却 ibd 文件过大的问题及解决方法

《MySQL表空却ibd文件过大的问题及解决方法》本文给大家介绍MySQL表空却ibd文件过大的问题及解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考... 目录一、问题背景:表空却 “吃满” 磁盘的怪事二、问题复现:一步步编程还原异常场景1. 准备测试源表与数据

Mac电脑如何通过 IntelliJ IDEA 远程连接 MySQL

《Mac电脑如何通过IntelliJIDEA远程连接MySQL》本文详解Mac通过IntelliJIDEA远程连接MySQL的步骤,本文通过图文并茂的形式给大家介绍的非常详细,感兴趣的朋友跟... 目录MAC电脑通过 IntelliJ IDEA 远程连接 mysql 的详细教程一、前缀条件确认二、打开 ID