ora-04021(ora04021 timeout)
求助：ORA-04042：过程，函数，程序包或程序包体不存在
ERROR 位于第 1 行:
ORA-06550: 第 1 行, 第 7 列:
PLS-00201: 必须说明标识符 'DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP'
ORA-06550: 第 1 行, 第 7 列:
PL/SQL: Statement ignored
SQL execute dbms_repcat_admin.grant_admin_any_schema(username = '"REPADMIN"');
BEGIN dbms_repcat_admin.grant_admin_any_schema(username = '"REPADMIN"'); END;
*
ORA-04031的产生原因及解决方法
现象： ORA-04031: unable to allocate 4096 bytes of shared memory
在查询一大的视图时出现的这个错误，视图里面套视图，效率很低，在采用了下面的第一种方法后解决，把 shared_pool_size 增大为150M，以前是40M.
具体原因及解决：
ORA-04031出现的问题有以下几个可能性：
1. 没有绑定编量造成shared_pool碎片过多，同时shared_pool_size太小
（1）这个情况是比较常见的。
（2）第二种情况通常会建议使用绑定变量，或者用简单的加大shared_pool，临时的解决方法就是alter system flush shared_pool。
2. Large_pool,Java_pool太小造成的
（1）这个通过错误 信息 的提示很容易判断(Ora-04031 cannot allocate .. memeory in [large_pool])
（2）解决方法就是简单的加大 Large_pool or Java_pool
3. 过度的开CURSOR而不关闭。
目前，此问题发生的越来越多，特别是在JAVA的运行环境中，屡见不鲜。加大Shared_pool或者flush shared_pool往往只能延迟问题出现的时间，而无法避免此问题。
判断方法：
假如出来的值特大（以万为单位）时，基本就可以确定是这个原因了。
解决这个问题的方法就是检查程序，看是否没有正常的关闭cursor(对于JAVA来说，就是没有关闭Statement)。或者select sql_text from v?$open_cursor,看看都是哪些cursor没关闭，再去检查车程序。
也有的程序使用了保持一定量的cursor一直open,从而避免cursor过多次的开启，来提高。对于这种情况，则应该选择适当的shared_pool_size和控制keep_opening的cursor的量。
另外，Oracle参数session_cached_cursors也有可能过大，解决的方法就是把它降低到适当的值。
oracle里我在自己包里建了一个函数，给其他用户赋使用权，一直报错ORA-04042过程程序或包体不存在为什么
可能你需要创建一个程序包主体 语法为 create or replace package body **** ......
Oracle ORA-04020锁死问题，请帮忙分析，并给出解决方法，小女子在此谢过！
1）用dba用户执行以下语句
select username,lockwait,status,machine,programfrom v$session where sid in
(select session_id from v$locked_object);
如果有输出的结果，则说明有死锁，且能看到死锁的机器是哪一台。字段说明：
Username：死锁语句所用的数据库用户；
Lockwait：死锁的状态，如果有内容表示被死锁。
Status： 状态，active表示被死锁
Machine： 死锁语句所在的机器。
Program： 产生死锁的语句主要来自哪个应用程序。
2）用dba用户执行以下语句，可以查看到被死锁的语句。
select sql_text from v$sql where hash_valuein (select sql_hash_value from v$session where sid in
(select session_id from v$locked_object));
四、死锁的解决方法
一般情况下，只要将产生死锁的语句提交就可以了，但是在实际的执行过程中。用户可能不知道产生死锁的语句是哪一句。可以将程序关闭并重新启动就可以了。经常在Oracle的使用过程中碰到这个问题，所以也总结了一点解决方法。
1）查找死锁的进程：
SELECTs.username,l.OBJECT_ID,l.SESSION_ID,s.SERIAL#,l.ORACLE_USERNAME,l.OS_USER_NAME,l.PROCESSFROM V$LOCKED_OBJECT l,V$SESSION S WHERE l.SESSION_ID=S.SID;
2）kill掉这个死锁的进程：
alter system kill session ‘sid,serial#’; （其中sid=l.session_id）
3）如果还不能解决：
select pro.spid from v$sessionses,v$process pro where ses.sid=XX and ses.paddr=pro.addr;
其中XX用死锁的sid替换:
ps -ef|grep spid
其中spid是这个进程的进程号，kill掉这个Oracle进程
select A.SQL_TEXT, B.USERNAME, C.OBJECT_ID,C.SESSION_ID, B.SERIAL#,C.ORACLE_USERNAME,C.OS_USER_NAME,C.Process,''''||C.Session_ID||','||B.SERIAL#||'''from v$sql A, v$session B, v$locked_object C where A.HASH_VALUE =B.SQL_HASH_VALUE and B.SID = C.Session_ID
编译存储过程时出现Ora-04021错误的如何解决
编译的存储过程的时候,程序死住,等待一会出现ora-04021错误解决办法:1.可能被锁住查看v$lockedselect b.sid,b.serial#,b.machine,b.terminal,b.program,b.process,b.status from v$lock a , v$session bwhere a.SID = b.SID得到死锁session的SID，SERIAL#参看这个是否为你自己用户下的,然后kill掉session2.可能被挂起查看v$session_waitselect b.serial#,a.* from v$session_wait a,v$session bwhere a.sid = b.sid得到等待的session的sid和serial#3.查看dba_ddl_locksselect session_id sid, owner, name, type,mode_held held, mode_requested requestfrom dba_ddl_lockswhere name = 'your_package_name'
如何解决ORA-04031错误
ORA-4031错误原理及诊断脚本汇总
4031_diag_script.zip
1. SGA中的内存池包含不同大小的内存块。当数据库启动时，就有一个大的内存块分配并被hush buckets 里的空闲列表追踪。随着时间推移，随着内存的分配和释放，内存块被按照大小在不同的hush buckets间移动。当SGA里任何一个内存池里出现不能满足内部分配请求的情况时，ORA-04031就出现了。
shared pool共享池的管理方式不同于其它的内存池。。共享池存放与数据字典和library cache有关的信息。但是，这些内存区域根据空闲列表和最近使用算法(LRU)管理。当在共享池的所有搜索结束后，从LRU列表清除所有的可能清除的对象， 多次扫描空闲列表后，仍没有找到内存块，ORA-04031就出现了。这意味着ORA-04031很难预测。
2. 对共享池的监测，可以看它是否包含许多类似的SQL,只有文字不同。 这种情况会占用更多的共享池内存并引共享池碎片，过多的共享池碎片(fragment)会导致虽然共享池中仍有大量的free memory，但都是尺寸较小的内存块(chunk)，当Oracle进程申请一些较大的连续内存空间(memory chunk)时，虽然共享池中的free memory大小远大于申请的连续空间大小，仍会引发ORA-4031错误。使用绑定变量可以使SQL 共享。使用本文所附的脚本可以查出内存中是否有许多类似SQL。
即使使用了绑定变量后，仍然可能存在高version count（子指针）的情况。为了使子指针共享，CURSOR_SHARING参数可能需要调整。metalink 文档Note 296377.1 和 261020.1可以提供详细信息。若造成4031的原因是由于未绑定变量或者游标无法共享导致的过度硬解析(Hard Parse)，则应当调整应用绑定变量或者调整初始化参数。