您的位置：首页 > 数据库 > Oracle

Oracle数据库用户无法删除的处理案例

2020-01-15 08:53 288 查看

Oracle数据库用户无法删除的处理案例
删除用户提示信息

SQL> drop user jzfp cascade;

drop user jzfp cascade

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 2

ORA-01422: exact fetch returns more than requested number of rows

从错误提示信息可以看到，是sql递归出现多值条件或者重写sql语句。是由于执行一条SQL语句到导致，因此我们可以跟踪一下这个SQL语句的执行过程，希望可以得到一些蛛丝马迹。

以下是跟踪过程：

SQL> alter session set sql_trace=true;

Session altered.

SQL> alter session set events'10046 trace name context forever,level 4';

Session altered.

SQL> drop user jzfp cascade;

drop user jzfp cascade

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 2

ORA-01422: exact fetch returns more than requested number of rows

SQL> alter session set sql_trace-false;

alter session set sql_trace-false

ERROR at line 1:

ORA-00922: missing or invalid option

SQL> alter session set sql_trace=false;

Session altered.

跟踪文件文件目录：

/u01/app/oracle/diag/rdbms/jzfpysdb/jzfpysdb1/trace/jzfpysdb1_ora_25323.trc

这个目录可以根据user_dump_dest参数确定。

查看跟踪产生的trace文件发现在删除过程中有如下信息，注意表黑的语句：

=====================

PARSING IN CURSOR #140007753306960 len=61 dep=1 uid=0 oct=12 lid=0 tim=1471928680661235 hv=3312064677 ad='7f56186f5838' sqlid='4d8b5vg2qn655'

drop table "JZFP"."AH02_2014" cascade constraints purge force

END OF STMT

PARSE #140007753306960:c=0,e=162,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1471928680661235

PARSE #140007751881456:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=0,tim=1471928680661387

BINDS #140007748108528:

Bind#0

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f561818c1f0 bln=32 avl=04 flg=05

value="JZFP"

Bind#1

oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56184df238 bln=32 avl=09 flg=09

value="AH02_2014"

Bind#2

oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56184dfa68 bln=32 avl=21 flg=09

value="CHECKPRIVRLS_SELECTPF"

EXEC #140007748108528:c=0,e=90,p=0,cr=0,cu=0,mis=0,r=0,dep=3,og=1,plh=1049820942,tim=1471928680661567

FETCH #140007748108528:c=0,e=48,p=0,cr=8,cu=0,mis=0,r=1,dep=3,og=1,plh=1049820942,tim=1471928680661636

CLOSE #140007748108528:c=0,e=1,dep=3,type=3,tim=1471928680661664

BINDS #140007748108528:

Bind#0

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f561818c1f0 bln=32 avl=04 flg=05

value="JZFP"

Bind#1

oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56184df238 bln=32 avl=09 flg=09

value="AH02_2014"

Bind#2

oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56184dfa68 bln=32 avl=24 flg=09

value="CHECKPRIVRLS_SELECTPROPF"

EXEC #140007748108528:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=3,og=1,plh=1049820942,tim=1471928680661775

FETCH #140007748108528:c=0,e=19,p=0,cr=8,cu=0,mis=0,r=1,dep=3,og=1,plh=1049820942,tim=1471928680661803

CLOSE #140007748108528:c=0,e=1,dep=3,type=3,tim=1471928680661824

EXEC #140007751881456:c=1000,e=431,p=0,cr=16,cu=0,mis=0,r=1,dep=2,og=4,plh=0,tim=1471928680661837

CLOSE #140007751881456:c=0,e=9,dep=2,type=3,tim=1471928680661875

PARSE #140007749758088:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,plh=0,tim=1471928680661930

问题可能就出现在这条drop语句上，我们尝试手动执行该条删除信息：

SQL> drop table JZFP.AH02_2014 cascade constraints purge force;

drop table JZFP.AH02_2014 cascade constraints purge force

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01422: exact fetch returns more than requested number of rows

果不其然，删除这张表出现的错误信息与删除用户的错误信息时一致的，这绝对不是偶然，我们继续查看该表的相关信息：

首先查看表结构：

SQL> desc jzfp.ah02_2014;

Name Null? Type

----------------------------------------------------------------------------------------------------------------- -------- ----------------------------------------------------------------------------

AHH002 NOT NULL VARCHAR2(50)

AAA001 VARCHAR2(50)

AAD001 VARCHAR2(50)

AAD002 VARCHAR2(20)

AAD003 VARCHAR2(50)

AAD004 VARCHAR2(50)

AAD005 VARCHAR2(50)

AAD006 VARCHAR2(50)

AAD007 VARCHAR2(100)

AAD008 VARCHAR2(100)

AAD009 VARCHAR2(100)

AAD010 VARCHAR2(100)

AAD011 VARCHAR2(20)

AAD012 VARCHAR2(100)

AAD013 VARCHAR2(100)

AAH007 VARCHAR2(50)

AAH001 VARCHAR2(50)

AAH002 DATE

AAH008 VARCHAR2(50)

AAH003 VARCHAR2(50)

AAH004 DATE

AAH005 VARCHAR2(200)

AAH006 VARCHAR2(10)

AAD015 VARCHAR2(10)

AAD014 VARCHAR2(10)

AAD016 VARCHAR2(10)

MEMBER_NO VARCHAR2(50)

CHANGE_TIME VARCHAR2(20)

CREATE_TIME VARCHAR2(20)

DELETE_TIME VARCHAR2(20)

STATUS CHAR(1)

HELP_TYPE CHAR(2)

POLITICS_STATUS VARCHAR2(2)

AZC005 VARCHAR2(12)

XYJR CHAR(2)

DBYLBX CHAR(2)

OLD_AAD015 VARCHAR2(10)

REDUCE_STATE CHAR(1)

SQL> select count(*) from jzfp.ah02_2014;

COUNT(*)

----------

这儿说明该表示正常存在的，而且只有0条信息，接着查看该表的统计信息：

END OF STMT

PARSE #140007749758088:c=7999,e=8907,p=0,cr=16,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1471929977717985

PARSE #140007751390232:c=0,e=19,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=1471929977718142

BINDS #140007747989728:

Bind#0

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=03 fl2=1206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56186d3f68 bln=32 avl=04 flg=05

value="JZFP"

Bind#1

oacdty=01 mxl=32(19) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

kxsbbbfp=7f56184df238 bln=32 avl=19 flg=09

value="PK_AH02_2014_AHH002"

Bind#2

oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00

oacflg=13 fl2=206001 frm=01 csi=852 siz=32 off=0

内容2：

=====================

PARSING IN CURSOR #140007749746360 len=56 dep=1 uid=0 oct=26 lid=0 tim=1471930052112942 hv=2415965579 ad='edaf19e00' sqlid='5mrrd3f801dcb'

LOCK TABLE "JZFP"."AH02_2014" IN EXCLUSIVE MODE NOWAIT

END OF STMT

PARSE #140007749746360:c=2000,e=2810,p=0,cr=17,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1471930052112941

EXEC #140007749746360:c=0,e=39,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=1471930052113043

CLOSE #140007749746360:c=0,e=3,dep=1,type=0,tim=1471930052113080

CLOSE #140007749732656:c=0,e=5,dep=1,type=0,tim=1471930052113156

我们手动执行以上内容1中标黑的部分，执行都会提示错误信息，由于网络原因，断开连接导致部分信息未能粘出来，但是这两条信息都是无关紧要的，我接着查询一下该表的定义信息：

CREATE TABLE "JZFP"."AH02_2014"
   (    "AHH002" VARCHAR2(50) NOT NULL ENABLE,
        "AAA001" VARCHAR2(50),
        "AAD001" VARCHAR2(50),
        "AAD002" VARCHAR2(20),
        "AAD003" VARCHAR2(50),
        "AAD004" VARCHAR2(50),
        "AAD005" VARCHAR2(50),
        "AAD006" VARCHAR2(50),
        "AAD007" VARCHAR2(100),

DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
        "AAD008" VARCHAR2(100),
        "AAD009" VARCHAR2(100),
        "AAD010" VARCHAR2(100),
        "AAD011" VARCHAR2(20),
        "AAD012" VARCHAR2(100),
        "AAD013" VARCHAR2(100),
        "AAH007" VARCHAR2(50),
        "AAH001" VARCHAR2(50),
        "AAH002" DATE,
        "AAH008" VARCHAR2(50),
        "AAH003" VARCHAR2(50),

DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
        "AAH004" DATE,
        "AAH005" VARCHAR2(200),
        "AAH006" VARCHAR2(10),
        "AAD015" VARCHAR2(10),
        "AAD014" VARCHAR2(10),
        "AAD016" VARCHAR2(10),
        "MEMBER_NO" VARCHAR2(50),
        "CHANGE_TIME" VARCHAR2(20),
        "CREATE_TIME" VARCHAR2(20),
        "DELETE_TIME" VARCHAR2(20),
        "STATUS" CHAR(1) DEFAULT 1,

DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
        "HELP_TYPE" CHAR(2),
        "POLITICS_STATUS" VARCHAR2(2),
        "AZC005" VARCHAR2(12),
        "XYJR" CHAR(2),
        "DBYLBX" CHAR(2),
        "OLD_AAD015" VARCHAR2(10),
        "REDUCE_STATE" CHAR(1),
         CONSTRAINT "PK_AH02_2014_AHH002" PRIMARY KEY ("AHH002")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

DBMS_METADATA.GET_DDL('TABLE','AH02_2014','JZFP')
--------------------------------------------------------------------------------
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "GSJZFP"  ENABLE
   ) SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
  STORAGE(INITIAL 1207959552 NEXT 8192 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "GSJZFP"

通过该表的定义信息，查看不到有什么异常，我们联系开发尝试重建该表，过了几分钟，开发反馈回来的信息时该表无法创建，也无法删除。好吧，到此真的是很无奈，我们只能继续查看跟踪文件，看能不能查到蛛丝马迹，果然，黄天不负有心人啊，O(∩_∩)O哈哈~，通过不断的尝试，在跟踪文件中发现如下信息：

=====================

PARSING IN CURSOR #140559996906600 len=123 dep=1 uid=0 oct=3 lid=0 tim=1471936427212820 hv=2356131727 ad='edc06fc30' sqlid='1h1ymb266zdwg'

select log, flag, to_date('4000-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS') from sys.mlog$ where mowner = :1 and master = :2

END OF STMT

PARSE #140559996906600:c=1000,e=70,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3625463896,tim=1471936427212820

BINDS #140559996906600:

Bind#0

oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00

oacflg=10 fl2=0001 frm=01 csi=00 siz=64 off=0

kxsbbbfp=7fd6acaf5fc8 bln=32 avl=04 flg=05

value="JZFP"

Bind#1

oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00

oacflg=10 fl2=0001 frm=01 csi=00 siz=0 off=32

kxsbbbfp=7fd6acaf5fe8 bln=32 avl=09 flg=01

value="AH02_2014"

EXEC #140559996906600:c=0,e=69,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3625463896,tim=1471936427212922

FETCH #140559996906600:c=0,e=75,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,plh=3625463896,tim=1471936427213005

STAT #140559996906600 id=1 cnt=2 pid=0 pos=1 obj=650 op='TABLE ACCESS CLUSTER MLOG$ (cr=2 pr=0 pw=0 time=60 us cost=1 size=57 card=1)'

STAT #140559996906600 id=2 cnt=1 pid=1 pos=1 obj=649 op='INDEX UNIQUE SCAN I_MLOG# (cr=1 pr=0 pw=0 time=21 us cost=0 size=0 card=1)'

CLOSE #140559996906600:c=0,e=3,dep=1,type=1,tim=1471936427213061

EXEC #140559997371296:c=19997,e=19527,p=0,cr=34,cu=9,mis=0,r=0,dep=0,og=1,plh=0,tim=1471936427213085

ERROR #140559997371296:err=604 tim=1471936427213094

*** 2016-08-23 15:14:02.256

CLOSE #140559997371296:c=0,e=8,dep=0,type=0,tim=1471936442256880

=====================

PARSING IN CURSOR #140559997371296 len=33 dep=0 uid=0 oct=42 lid=0 tim=1471936442257737 hv=525901419 ad='7fd6acb3fe00' sqlid='aam2chsgpj7mb'

alter session set sql_trace=false

END OF STMT

PARSE #140559997371296:c=1000,e=740,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1471936442257736

EXEC #140559997371296:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1471936442257904

*** 2016-08-23 15:14:20.842

CLOSE #140559997371296:c=0,e=7,dep=0,type=0,tim=1471936460841995

执行以上信息中标黑的部分：

SQL> select log, flag,MASTER from sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014';

LOG FLAG MASTER

------------------------------ ---------- ------------------------------

MLOG$_AH02_2014 270369 AH02_2014

发现居然出来两条结果一模一样的记录，根据之前的错误提示中，可知出现递归错误的原因就是出现多值条件，这也许就是问题的根源了，好吧，先来介绍一下sys.mlog$。

Changing a Materialized View Group's Master Site

To change the master site of a materialized view group at a level 1 materialized view site to another master site, call the SWITCH_MVIEW_MASTERprocedure in the DBMS_REPCAT package, as shown in the following example:

BEGIN

   DBMS_REPCAT.SWITCH_MVIEW_MASTER (

      gname  => 'hr_repg',

      master => 'orc3.example.com');

END;

In this example, the master site for the hr_repg replication group is changed to the orc3.example.com master site. You must call this procedure at the materialized view site whose master site you want to change. The new database must be a master site in the replication environment. When you call this procedure, Oracle uses the new master to perform a full refresh of each materialized view in the local materialized view group. Ensure that you have set up the materialized view site to use the new master site before you run the SWITCH_MVIEW_MASTER procedure.

The entries in the SYS.SLOG$ table at the old master site for the switched materialized view are not removed. As a result, the materialized view log (MLOG$ table) of the switched updatable materialized view at the old master site has the potential to grow indefinitely, unless you purge it by callingDBMS_MVIEW.PURGE_LOG.

Note:

You cannot switch the master of materialized views that are based on other materialized views (level 2 and greater materialized views). Such a materialized view must be dropped and re-created to base it on a different master.

这是从Oracle官方文档上找到的相关信息，大概意思就是说该表中的数据是oracle 为了同步基表和物化视图之间的数据的，当基表的数据发生变化，在日志表中就会产生数据。等oracle将变化同步到物化视图后，日志表中的数据会自动清除。一般情况下不建议手工删除该表中的数据。

这个表一般是通过create materialized view log on 与drop materialized view log操作产生，只要有这样的表存在，就一定是做过类似的操作，不是你做的也是别人做的。

通过跟开发交流，这张表上确实存在物化视图，而且将物化视图删掉之后，该表还是删除不掉，那么先删除sys.mlog$中的重复记录：

SQL> select log, flag,MASTER from sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014' and rownum=1;

LOG FLAG MASTER

------------------------------ ---------- ------------------------------

MLOG$_AH02_2014 270369 AH02_2014

SQL> delete from sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014' and rownum=1;

1 row deleted.

SQL> commit;

Commit complete.

SQL> select log, flag,MASTER from sys.mlog$ where mowner = 'JZFP' and master = 'AH02_2014';

LOG FLAG MASTER

------------------------------ ---------- ------------------------------

MLOG$_AH02_2014 270369 AH02_2014

删除完确认值留存一条日志记录，然后再删除该表：

SQL> drop table jzfp.ah02_2014;

Table dropped.

SQL>

可以看到该表正常删除。还有几张表也是删除不掉，按照这个过程均一一删除，接着删除用户再试试：

SQL> drop user jzfp cascade;

drop user jzfp cascade

ERROR at line 1:

ORA-01940: cannot drop a user that is currently connected

错误提示信息已经不是之前的信息，这个错误信息的意思是该用户有当前正在链接的会话，查询与该用户有关的会话，kill即可。过程如下：

SQL> select sid,serial# from v$session where USERNAME='JZFP';

SID SERIAL#

---------- ----------

862 1597

912 857

2147 4509

2954 32089

SQL> alter system kill session '862,1597';

System altered.

SQL> alter system kill session '912,857';

System altered.

SQL> alter system kill session '2147,4509';

System altered.

SQL> alter system kill session '2954,32089';

System altered.

SQL> drop user jzfp cascade;

User dropped.

可以看到jzfp用户正常删除。

Trace文件名：

jzfpysdb1_ora_18493.trc

jzfpysdb1_ora_25323.trc

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31403259/viewspace-2137325/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31403259/viewspace-2137325/

点赞
收藏
分享
文章举报

cucany584825 发布了0 篇原创文章 · 获赞 0 · 访问量 2527 私信关注

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航