技术标签： Oracle禁止用户delete
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
这儿说明该表示正常存在的，而且只有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
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
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 theSYS.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
文章浏览阅读1k次。通过使用ajax方法跨域请求是浏览器所不允许的，浏览器出于安全考虑是禁止的。警告信息如下：不过jQuery对跨域问题也有解决方案，使用jsonp的方式解决，方法如下：$.ajax({ async:false, url: 'http://www.mysite.com/demo.do', // 跨域URL ty..._nginx不停的xhr
文章浏览阅读2k次。关于在 Oracle 中配置 extproc 以访问 ST_Geometry，也就是我们所说的 使用空间SQL 的方法，官方文档链接如下。http://desktop.arcgis.com/zh-cn/arcmap/latest/manage-data/gdbs-in-oracle/configure-oracle-extproc.htm其实简单总结一下，主要就分为以下几个步骤。..._extproc
文章浏览阅读1.5w次。linux下没有上面的两个函数，需要使用函数 mbstowcs和wcstombsmbstowcs将多字节编码转换为宽字节编码wcstombs将宽字节编码转换为多字节编码这两个函数，转换过程中受到系统编码类型的影响，需要通过设置来设定转换前和转换后的编码类型。通过函数setlocale进行系统编码的设置。linux下输入命名locale -a查看系统支持的编码_linux c++ gbk->utf8
文章浏览阅读750次。今天准备从生产库向测试库进行数据导入，结果在imp导入的时候遇到“ IMP-00009:导出文件异常结束” 错误，google一下，发现可能有如下原因导致imp的数据太大，没有写buffer和commit两个数据库字符集不同从低版本exp的dmp文件，向高版本imp导出的dmp文件出错传输dmp文件时，文件损坏解决办法：imp时指定..._imp-00009导出文件异常结束
文章浏览阅读143次。当下是一个大数据的时代，各个行业都离不开数据的支持。因此，网络爬虫就应运而生。网络爬虫当下最为火热的是Python，Python开发爬虫相对简单，而且功能库相当完善，力压众多开发语言。本次教程我们爬取前程无忧的招聘信息来分析Python程序员需要掌握那些编程技术。首先在谷歌浏览器打开前程无忧的首页，按F12打开浏览器的开发者工具。浏览器开发者工具是用于捕捉网站的请求信息，通过分析请求信息可以了解请..._初级python程序员能力要求
文章浏览阅读7.6k次，点赞2次，收藏6次。@Service标注的bean，类名：ABDemoService查看源码后发现，原来是经过一个特殊处理：当类的名字是以两个或以上的大写字母开头的话，bean的名字会与类名保持一致public class AnnotationBeanNameGenerator implements BeanNameGenerator { private static final String C..._@service beanname
文章浏览阅读6.9w次，点赞73次，收藏463次。1.前序创建#include<stdio.h>#include<string.h>#include<stdlib.h>#include<malloc.h>#include<iostream>#include<stack>#include<queue>using namespace std;typed_二叉树的建立
文章浏览阅读7.1k次。在Asp.net上使用Excel导出功能，如果文件名出现中文，便会以乱码视之。 解决方法： fileName = HttpUtility.UrlEncode(fileName, System.Text.Encoding.UTF8);_asp.net utf8 导出中文字符乱码
文章浏览阅读2.1k次，点赞4次，收藏23次。第一次实验 词法分析实验报告设计思想词法分析的主要任务是根据文法的词汇表以及对应约定的编码进行一定的识别，找出文件中所有的合法的单词，并给出一定的信息作为最后的结果，用于后续语法分析程序的使用；本实验针对 PL/0 语言 的文法、词汇表编写一个词法分析程序，对于每个单词根据词汇表输出： (单词种类, 单词的值) 二元对。词汇表：种别编码单词符号助记符0beginb..._对pl/0作以下修改扩充。增加单词
文章浏览阅读773次。我在使用adb.exe时遇到了麻烦.我想使用与bash相同的adb.exe shell提示符,所以我决定更改默认的bash二进制文件(当然二进制文件是交叉编译的,一切都很完美)更改bash二进制文件遵循以下顺序> adb remount> adb push bash / system / bin /> adb shell> cd / system / bin> chm..._adb shell mv 权限
文章浏览阅读6.8k次，点赞12次，收藏125次。1. 单目相机标定引言相机标定已经研究多年，标定的算法可以分为基于摄影测量的标定和自标定。其中，应用最为广泛的还是张正友标定法。这是一种简单灵活、高鲁棒性、低成本的相机标定算法。仅需要一台相机和一块平面标定板构建相机标定系统，在标定过程中，相机拍摄多个角度下（至少两个角度，推荐10~20个角度）的标定板图像（相机和标定板都可以移动），即可对相机的内外参数进行标定。下面介绍张氏标定法（以下也这么称呼）的原理。原理相机模型和单应矩阵相机标定，就是对相机的内外参数进行计算的过程，从而得到物体到图像的投影_相机-投影仪标定
文章浏览阅读2.2k次。文章目录Wayland 架构Wayland 渲染Wayland的 硬件支持简 述： 翻译一篇关于和 wayland 有关的技术文章, 其英文标题为Wayland Architecture .Wayland 架构若是想要更好的理解 Wayland 架构及其与 X (X11 or X Window System) 结构；一种很好的方法是将事件从输入设备就开始跟踪, 查看期间所有的屏幕上出现的变化。这就是我们现在对 X 的理解。 内核是从一个输入设备中获取一个事件，并通过 evdev 输入_wayland