将好友的微信删除后再添加却显示此用户名不存在是怎么回事?

将好友的微信删除后再添加却显示此用户名不存在是怎么回事?,第1张

楼主\x0d\x0a打开微信,搭毕饥微信右下角,点击我。\x0d\x0a随后点击设数缺置,——隐私\x0d\x0a可以看到通过手知返机号搜索到我;通过微信号搜到我;通过qq号搜到我\x0d\x0a你要加的人把这几个关闭了你就搜不到了。

1、首先,您可以尝试重新输入您的账号,可能是您输入的时候出兆谈现了一些错误,重新输入一次可能就可以解决问题了。

2、如果您的账号已经被删除,您可盯迟以尝试重新注册一个新的账号,并使用新的账号登录原神游戏。

3、如果您的账号已经被删除,您可以联系原神客服,他们可以帮助您找回您的账凯猜李号。

好吧!我帮你搜索下得到以下内容

1. drop user出现问题

报出以下错误后退出

ORA-00604: error occurred at recursive SQL level 1

ORA-00942: table or view does not exist .

关于 recursive SQL 错误我们有必要做个简单说明。

我们知道,当我们发出一条简单的命令以后

Oracle数据库要在后台解析这条命令,并转换为Oracle数据库的一系列后台 *** 作。

这些后台 *** 作统称为递归sql.

比如create table这样一条简单的DDL命令,Oracle数据库在后台,实际上要把这个命令转换为对于obj$,tab$,col$等底层表的插入简穗 *** 作。Oracle所作的工作可能比我们有时候想的要复杂的多。

2.跟踪问题

我们知道Oracle提供sql_trace的功能

可以用于跟踪Oracle数据库的后台递归 *** 作。

通过跟踪文件,我们可以找到问题的所在

以下是格式化(tkprof)后的输出:

The following statement encountered a error during parse:

DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = 'WAPCOMM'

Error encountered: ORA-00942

Oracle把错误信息首先呈现出来,我们看到ORA-00942错误是由于

SDO_GEOM_METADATA_TABLE表/视图不存在所致,问题由此可以定位。

对于这一类的错误,定位问题以后解决的方法就要依据具体问题原拦则卜因而定了。

盯绝3.问题定位

对于本案例,通过Metalink获得以下解释:

Problem Description

The Oracle Spatial Option has been installed and you are encountering

the following errors while trying to drop a user, who has no spatial tables,

connected as SYSTEM:

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-00942: table or view does not exist

ORA-06512: at line 7

A 942 error trace shows the failing SQL statement as:

DELETE FROM SDO_GEOM_METADATA_TABLE WHERE SDO_OWNER = ''

Solution Description

(1)

Create a synonym for SDO_GEOM_METADATA_TABLE under SYSTEM which points to

MDSYS.SDO_GEOM_METADATA_TABLE.

对于本例,为MDSYS.SDO_GEOM_METADATA_TABLE创建一个同义词即可解决,是相对简单的情况。

(2)

Now the user can be dropped connected as SYSTEM.

Related Documents

ORA-604 and ORA-942 Reported During DROP USER CASCA

4.实际处理

MDSYS.SDO_GEOM_METADATA_TABLE为Spatial对象,如果未使用Spatial选项,可以删除

SQL>connect / as sysdbaConnected.

SQL>select * from dba_sdo_geom_metadata order by owner

select * from dba_sdo_geom_metadata order by owner

*

ERROR at line 1:

ORA-00942: table or view does not exist

ORA-04063: view "MDSYS.DBA_SDO_GEOM_METADATA" has errors

SQL>select object_name from dba_objects where object_name like '%SDO%'

OBJECT_NAME

ALL_SDO_GEOM_METADATA

ALL_SDO_INDEX_INFO

ALL_SDO_INDEX_METADATA

DBA_SDO_GEOM_METADATA

DBA_SDO_INDEX_INFO

DBA_SDO_INDEX_METADATA

....

DBA_SDO_GEOM_METADATA

DBA_SDO_INDEX_INFO

...

SDO_WITHIN_DISTANCE

USER_SDO_GEOM_METADATA

USER_SDO_INDEX_INFO

USER_SDO_INDEX_METADATA

88 rows selected.

SQL>drop user MDSYS cascade

User dropped.

SQL>select owner,type_name from dba_types where type_name like 'SDO%'

no rows selected

SQL>

SQL>alter session set sql_trace=true

Session altered.

SQL>drop user wapcomm

User dropped.

SQL>alter session set sql_trace=false

Session altered.

SQL>exit

Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production

With the Partitioning option

JServer Release 8.1.7.4.0 - 64bit Production

这时用户得以顺利drop

5.一点总结

使用sql_trace可以跟踪数据库的很多后台 *** 作有利于我们发现问题的所在,很多时候,我们想要研究Oracle的内部活动或后台 *** 作,也可以通过sql_trace跟踪,sql_trace/10046 是Oracle提供的最为有效的诊断工具之一。

案例四:表更新时发生递归SQL2级失败错误

问题描述:表更新的时候失败了,并且生成了一条ORA-00604 错误信息。这个错误发生在递归SQL 2级。

解决方案:不幸的是,这个错误并不能告诉你Oracle数据库在错误发生的时候正要做什么。当你执行一条SQL语句的时候,Oracle数据库会为你在幕后做很多事情。例如,考虑下面的SQL语句:

UPDATE emp SET sal = sal*1.05 WHERE empno=1001

这条SQL语句给号码为1001的雇员涨5%的工资。当你执行这条语句的时候,Oracle查询数据目录来确定是否有这个表或者你是否使用了同义字。一旦它找到了数据库对象,Oracle查询数据字典来判断你是否拥有访问这个对象的权限。那么,Oracle到底是如何与数据字典进行交互的呢?它执行一条自己的SQL 语句。这些Oracle为你执行的SQL语句被称为“递归”SQL语句。你最初的SQL 语句是0级。Oracle为你执行的递归SQL语句是1级。有时候,一条递归SQL语句又会引起自己的递归SQL语句,就是2级。

在你的案例中,有一个2级的递归SQL语句正在执行,并且产生了问题。为了解决问题,你需要找出执行的是什么递归SQL语句引起的错误。要做到这一点,你必须启动会话中的追踪。

首先,执行下面的SQL 语句:

ALTER SESSION SET sql_trace=TRUE

然后,执行你的更新语句。你会看到ORA-604 错误。接下来,执行下面的语句:

ALTER SESSION SET sql_trace=FALSE

现在到你为数据库定义的USER_DUMP_DEST 起始参数上的路径去。那里应该有一个时间戳为当前时间的文件。那个就是你生成的追踪文件。你可以打开文件并检查递归SQL语句,其中包括引起错误的一条。

来源 http://blog.csdn.net/tianlesoftware/article/details/4787074


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/bake/11980196.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-20
下一篇 2023-05-20

发表评论

登录后才能评论

评论列表(0条)

保存