代码输入错误造成的，操作方法如下：
1、首先在电脑中打开oracle之后，如下图所示，查看表中重复的数据。
2、然后使用distinct去除函数查询出去掉重复后的数据，如下图所示。
3、接着创建新表把去掉重复的数据插入到新表中，如下图所示。
4、然后使用truncate清空原表中的数据，如下图所示。
5、最后再向原表中插入新表中重复的数据，即可达到去重复数据的效果。
温馨提示：答案为网友推荐，仅供参考
第1个回答 推荐于2017-12-16
我以前在做merge操作时也出现这个问题，因为在merge into 时需要一个唯一的key值来决定merge into的操作是insert into还是update，而我merge的临时表中的key值不唯一，所以报这个错误了，解决办法是将临时表按照一定的规则先搂一遍全部数据并且key值唯一。
比如：
select a.* from MERGE_TEST_TMP a where a.mid = (select max(MERGE_TEST_TMP.Mid) from MERGE_TEST_TMP where MERGE_TEST_TMP.MKEY=a.mkey) order by a.Mid desc;本回答被提问者和网友采纳
比如：
select a.* from MERGE_TEST_TMP a where a.mid = (select max(MERGE_TEST_TMP.Mid) from MERGE_TEST_TMP where MERGE_TEST_TMP.MKEY=a.mkey) order by a.Mid desc;本回答被提问者和网友采纳
第2个回答 2021-03-28
1.编译Java代码时出现的ORA-4031
在你编译Java代码的时候如果内存溢出，你会看到错误：
A SQL exception occurred while compiling: :
ORA-04031: unable to allocate bytes of shared memory
("shared pool","unknown object","joxlod: init h", "JOX: ioc_allocate_pal")
解决办法是关闭数据库然后把参数 JAVA_POOL_SIZE 设定为一个较大的值。这里错误信息中提到的 "shared pool" 其实共享全局区(SGA)溢出的误导，并不表示你需要增加SHARED_POOL_SIZE，相反，你必须加大 JAVA_POOL_SIZE 参数的值，然后重启动系统，再试一下。参考: <Bug:2736601> 。
2.小的共享池尺寸
很多情况下，共享池过小能够导致ORA-04031错误。下面信息有助于你调整共享池大小：
a.库高速缓冲命中率
命中率有助于你衡量共享池的使用，有多少语句需要被解析而不是重用。下面的SQL语句有助于你计算库高速缓冲的命中率：
SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;
如果丢失超过1%,那么尝试通过加大共享池的大小来减少库高速缓冲丢失。
b.共享池大小计算
要计算最适合你工作负载的共享池大小
3.共享池碎片
每一次，需要被执行的SQL 或者PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽，数据库要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用，就继续按照如下标准寻找：
i.大块(chunk)大小比请求的大小大
ii.空间是连续的
iii.大块内存是可用的(而不是正在使用的)
这样大块的内存被分开，剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时间之后，共享池结构就会出现碎片。
当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操作的过程中，"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。
如果SHARED_POOL_SIZE 足够大，大多数的 ORA-04031 错误都是由共享池中的动态SQL 碎片导致的。可能的原因如下：
i.非共享的SQL
ii.生成不必要的解析调用 (软解析)
iii.没有使用绑定变量
要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法，当然不只局限于这几种: 应用调整、数据库调整或者实例参数调整。
在你编译Java代码的时候如果内存溢出，你会看到错误：
A SQL exception occurred while compiling: :
ORA-04031: unable to allocate bytes of shared memory
("shared pool","unknown object","joxlod: init h", "JOX: ioc_allocate_pal")
解决办法是关闭数据库然后把参数 JAVA_POOL_SIZE 设定为一个较大的值。这里错误信息中提到的 "shared pool" 其实共享全局区(SGA)溢出的误导，并不表示你需要增加SHARED_POOL_SIZE，相反，你必须加大 JAVA_POOL_SIZE 参数的值，然后重启动系统，再试一下。参考: <Bug:2736601> 。
2.小的共享池尺寸
很多情况下，共享池过小能够导致ORA-04031错误。下面信息有助于你调整共享池大小：
a.库高速缓冲命中率
命中率有助于你衡量共享池的使用，有多少语句需要被解析而不是重用。下面的SQL语句有助于你计算库高速缓冲的命中率：
SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;
如果丢失超过1%,那么尝试通过加大共享池的大小来减少库高速缓冲丢失。
b.共享池大小计算
要计算最适合你工作负载的共享池大小
3.共享池碎片
每一次，需要被执行的SQL 或者PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽，数据库要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用，就继续按照如下标准寻找：
i.大块(chunk)大小比请求的大小大
ii.空间是连续的
iii.大块内存是可用的(而不是正在使用的)
这样大块的内存被分开，剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时间之后，共享池结构就会出现碎片。
当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操作的过程中，"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。
如果SHARED_POOL_SIZE 足够大，大多数的 ORA-04031 错误都是由共享池中的动态SQL 碎片导致的。可能的原因如下：
i.非共享的SQL
ii.生成不必要的解析调用 (软解析)
iii.没有使用绑定变量
要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法，当然不只局限于这几种: 应用调整、数据库调整或者实例参数调整。
第3个回答 2012-05-22
是在insert into 时报的错么？ 估计是你插入到表中的数据中，主键不唯一，你先把要插入的数据 distinct 主键下，去掉重复的行。