High Version Count Issues
In this Document
Purpose |
Ask Questions, Get Help, And Share Your Experiences With This Article |
Troubleshooting Steps |
What is a 'High' Version Count? |
What is shared SQL ? |
What is 'SQL Metadata'? |
Why should I be concerned about 'High' Versions? |
How do I see the versions and why they are not shared ? |
What do the reasons given in v$SQL_SHARED_CURSOR mean? |
UNBOUND_CURSOR |
SQL_TYPE_MISMATCH |
**OPTIMIZER_MISMATCH |
OUTLINE_MISMATCH |
STATS_ROW_MISMATCH |
LITERAL_MISMATCH |
SEC_DEPTH_MISMATCH |
EXPLAIN_PLAN_CURSOR |
BUFFERED_DML_MISMATCH |
PDML_ENV_MISMATCH |
INST_DRTLD_MISMATCH |
SLAVE_QC_MISMATCH |
TYPECHECK_MISMATCH |
AUTH_CHECK_MISMATCH |
**BIND_MISMATCH |
DESCRIBE_MISMATCH |
LANGUAGE_MISMATCH |
TRANSLATION_MISMATCH |
ROW_LEVEL_SEC_MISMATCH |
INSUFF_PRIVS |
INSUFF_PRIVS_REM |
REMOTE_TRANS_MISMATCH |
LOGMINER_SESSION_MISMATCH |
INCOMP_LTRL_MISMATCH |
OVERLAP_TIME_MISMATCH |
SQL_REDIRECT_MISMATCH |
MV_QUERY_GEN_MISMATCH |
USER_BIND_PEEK_MISMATCH |
TYPCHK_DEP_MISMATCH |
NO_TRIGGER_MISMATCH |
FLASHBACK_CURSOR |
ANYDATA_TRANSFORMATION |
INCOMPLETE_CURSOR |
TOP_LEVEL_RPI_CURSOR |
DIFFERENT_LONG_LENGTH |
LOGICAL_STANDBY_APPLY |
DIFF_CALL_DURN |
BIND_UACS_DIFF |
PLSQL_CMP_SWITCHS_DIFF |
CURSOR_PARTS_MISMATCH |
STB_OBJECT_MISMATCH |
ROW_SHIP_MISMATCH |
PQ_SLAVE_MISMATCH |
TOP_LEVEL_DDL_MISMATCH |
MULTI_PX_MISMATCH |
BIND_PEEKED_PQ_MISMATCH |
MV_REWRITE_MISMATCH |
ROLL_INVALID_MISMATCH |
OPTIMIZER_MODE_MISMATCH |
PX_MISMATCH |
MV_STALEOBJ_MISMATCH |
FLASHBACK_TABLE_MISMATCH |
LITREP_COMP_MISMATCH |
PLSQL_DEBUG |
LOAD_OPTIMIZER_STATS |
ACL_MISMATCH |
FLASHBACK_ARCHIVE_MISMATCH |
LOCK_USER_SCHEMA_FAILED |
REMOTE_MAPPING_MISMATCH |
LOAD_RUNTIME_HEAP_FAILED |
HASH_MATCH_FAILED |
PURGED_CURSOR |
BIND_LENGTH_UPGRADEABLE |
USE_FEEDBACK_STATS |
BIND_EQUIV_FAILURE |
Version_rpt script: |
What further tracing is available. |
Are there any times when a high version count is expected even though BINDS are being used? |
Explanation: |
Enhancement to obsolete parent cursors if Version Count exceeds a threshold |
High Version Count with Adaptive Cursor Sharing |
Known Issues |
Troubleshooting Other Issues |
Discuss High Version Count Issues |
References |
APPLIES TO:
Oracle Database - Enterprise Edition - Version 10.2.0.1 and later
Oracle Database - Personal Edition - Version 10.2.0.1 and later
Oracle Database - Standard Edition - Version 10.2.0.1 and later
Information in this document applies to any platform.
PURPOSE
The Troubleshooting Guide is provided to assist in debugging SQL sharing issues. When possible, diagnostic tools are included in the document to assist in troubleshooting problems. This document does not contain bugs/patches as these topics are addressed in the articles referenced at the bottom of this document.
Ask Questions, Get Help, And Share Your Experiences With This Article
Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry Experts?
Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.
Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Community page for Database Tuning.
TROUBLESHOOTING STEPS
What is a 'High' Version Count?
There is no definitive definition of what a 'High' number of versions for a particular cursor is, different systems may be able to deal with different ranges of versions, However, AWR reports start reporting versions over 20 for a particular cursor and so that is as good an indicator of a potential problem as any.
Once you start getting into the hundreds or thousands range, then these are definitely 'High' counts and the causes should be examined and the numbers reduced so as to encourage the SQL to be shared. It is important to understand that sometimes high version counts are expected and not a result of any defect.
What is shared SQL ?
The first thing to remember is that all SQL is implicitly sharable. When a SQL statement is entered, the RDBMS will create a hash value for text of the statement and that hash value then helps the RDBMS to easily find SQL already in the shared pool. It is not in the scope of this article to discuss this in any great detail, so let's just assume entering a series of text results in a hash value being created.
For instance :- 'select count(*) from emp' hashes to the value 4085390015
We now create a parent cursor for this sql and a single child. It does not matter that a SQL statement may never be shared - when it is first parsed a parent and a single child are created. The easy way to think of this is that the PARENT cursor is a representation of the hash value and the child cursor(s) represent the metadata for that SQL
What is 'SQL Metadata'?
Metadata is all the information which enables a statement to run. For instance, in the example I have given EMP is owned by scott and therefore has an OBJECT_ID which points to the EMP table owned by this user. When the user SCOTT logged in, optimizer parameters are initialised in that session for use by the statement, so this too is used by the optimizer and is therefore metadata. There are other examples of Metadata which will be mentioned further in this document.
Let's say this session logs out and back in again now. It then runs the same command again (as the same user). This time we already have the SQL in the shared pool (but we don't know this yet). What we do is hash the statement and then search for that hash value in the shared pool. If we find it, we can then search through the children to determine if any of them are usable by us (ie the metadata is the same). If it is, then we can share that SQL statement
I would still have one version of that SQL in the shared pool because the metadata enabled me to share the statement with the already existent child. The fundamentals are that the parent is not shared, it is the children which determine shareability.
Now - another user 'TEST' has it's own version of EMP. If that user was to now run the select statement above then what would happen is :-
1. The statement is hashed - it is hashed to the value 4085390015
2. The SQL will be found in the shared pool as it already exists
3. The children are scanned (at this point we have one child)
4. Because the OBJECT_ID of the EMP table owned by TEST is different the OBJECT_ID owned by scott we have a 'mismatch'
(Essentially, what happens here is that we have a linked list of children which we move through in turn, comparing the metadata of the current SQL with that of all the children. If there were 100 children then we would scan each of them (looking for a possible mismatch and moving on) until we found one we could share. If we cannot share any (ie. have exhausted the list of children) then we need to create a new child)
5. We therefore have to create a new child - we now have 1 PARENT and 2 CHILDREN.
Why should I be concerned about 'High' Versions?
Unnecessary non-sharing of SQL, and the resultant versions of SQL, is a primary cause of library cache contention. Contention reduces the performance of your database and, in extreme cases, can cause it to appear to 'hang'. When you have unnecessary versions of a cursor, each time that cursor is executed, the parse engine has to search through the list of versions to see which is the cursor that you want. This wastes CPU cycles that you could be using on something else.
How do I see the versions and why they are not shared ?
The easiest way to get version information in a clear format is to use the script in the following article:
To find the reasons for mismatches see the following section: What do the reasons given in v$SQL_SHARED_CURSOR mean?
If you are unable to use that script then you can select the same information from the base views as illustrated in the examples below.
Lets use the example above and take a look at what SQL we can use to see this in the shared pool.
SCOTT runs select count(*) from emp
I can now run the following to see the PARENT statement and it's hash value and address
SQL_TEXT HASH_VALUE ADDRESS
------------------------ ------------ ----------------
select count(*) from emp 4085390015 0000000386BC2E58
To see the CHILDREN (I expect to see 1 at this point) :-
- Version 9.2.X.X and below :
select * from v$sql_shared_cursor where kglhdpar = '0000000386BC2E58'
- Version 10.0.X.X and above:
select * from v$sql_shared_cursor where address = '0000000386BC2E58'
Output:
ADDRESS KGLHDPAR U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F ---------------- ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0000000386BC2D08 0000000386BC2E58 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
We can see we have a single child (ADDRESS 0000000386BC2D08).
The mismatch information (U S O O S L etc) is all N because this is the first child. Now, if I log in as another user and run the same select (select count(*) from emp) and look again I will get the following output:-
ADDRESS KGLHDPAR U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F ---------------- ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0000000386BC2D08 0000000386BC2E58 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N 0000000386A91AA0 0000000386BC2E58 N N N N N N N N N N N N N Y N N N Y N N N N N N N N N N N N N
We can now see the 2nd child ( 0000000386A91AA0) and also the reasons why it could not be shared with the first (The 'Y's denote a mismatch). The reasons are:
(1) AUTH_CHECK_MISMATCH and
(2) TRANSLATION_MISMATCH
This is because the objects under my new user do not map to those of SCOTT (the current child). A mismatch occurs because I cannot access SCOTTs objects and translation fails since we have different object_ids for the objects in each of our schemas.
What do the reasons given in v$SQL_SHARED_CURSOR mean?
Below are the list of reasons as well as some worked examples (Those denoted by ** are the ones most often seen) :-
UNBOUND_CURSOR
The existing child cursor was not fully built (in other words, it was not optimized)
SQL_TYPE_MISMATCH
**OPTIMIZER_MISMATCH
The optimizer environment does not match the existing child cursor (The optimizer mode has changed and therefore the existing child cannot be re-used).
For example:select count(*) from emp; ->> 1 PARENT, 1 CHILD
alter session set optimizer_mode=ALL_ROWS
select count(*) from emp; ->> 1 PARENT, 2 CHILDRENNote: The behavior applies with the setting of trace events. for example, if I turned on tracing with 10046 than I would get an OPTIMIZER_MISMATCH and another child cursorOUTLINE_MISMATCH
The outlines do not match the existing child cursor. For example, if a user had created stored outlines previously for this command and they were stored in separate categories (say "OUTLINES1" and "OUTLINES2"), if they then executed the following:
alter session set use_stored_outlines = OUTLINES1;
select count(*) from emp;alter session set use_stored_oulines= OUTLINES2;
select count(*) from emp;The second execution of the select from emp would create another child since the outline used is different than the first run. This child would be marked as an OUTLINE_MISMATCH.
STATS_ROW_MISMATCH
The existing statistics do not match the existing child cursor. Check that 10046/sql_trace is not set on all sessions as this can cause this.
LITERAL_MISMATCH
Non-data literal values do not match the existing child cursor
SEC_DEPTH_MISMATCH
Security level does not match the existing child cursor
EXPLAIN_PLAN_CURSOR
BUFFERED_DML_MISMATCH
Buffered DML does not match the existing child cursor
PDML_ENV_MISMATCH
INST_DRTLD_MISMATCH
Insert direct load does not match the existing child cursor
SLAVE_QC_MISMATCH
TYPECHECK_MISMATCH
The existing child cursor is not fully optimized
AUTH_CHECK_MISMATCH
**BIND_MISMATCH
The bind metadata does not match the existing child cursor. For example, in the following, the definition of the bind variable 'a' has changed between the 2 statements:
variable a varchar2(100);
select count(*) from emp where ename = :a ->> 1 PARENT, 1 CHILDvariable a varchar2(400);
select count(*) from emp where ename = :a ->> 1 PARENT, 2 CHILDRENDESCRIBE_MISMATCH
The type-check heap is not present during the describe for the child cursor
LANGUAGE_MISMATCH
The language handle does not match the existing child cursor
TRANSLATION_MISMATCH
The base objects of the existing child cursor do not match.
The definition of the object does not match any current version. Usually this is indicative of the same issue as "AUTH_CHECK_MISMATCH" where the object is different.ROW_LEVEL_SEC_MISMATCH
INSUFF_PRIVS
Insufficient privileges on objects referenced by the existing child cursor
INSUFF_PRIVS_REM
Insufficient privileges on remote objects referenced by the existing child cursor
REMOTE_TRANS_MISMATCH
The remote base objects of the existing child cursor do not match. For example:
USER1:select count(*) from table@remote_dbUSER2:
select count(*) from table@remote_dbAlthough the SQL is identical, the dblink pointed to by remote_db may be a private dblink which resolves to a different object altogether
LOGMINER_SESSION_MISMATCH
INCOMP_LTRL_MISMATCH
OVERLAP_TIME_MISMATCH
Error_on_overlap_time mismatch
SQL_REDIRECT_MISMATCH
MV_QUERY_GEN_MISMATCH
Materialized view query generation
USER_BIND_PEEK_MISMATCH
TYPCHK_DEP_MISMATCH
Cursor has type-check dependencies
NO_TRIGGER_MISMATCH
FLASHBACK_CURSOR
No cursor sharing for flashback
ANYDATA_TRANSFORMATION
INCOMPLETE_CURSOR
Incomplete cursor. When bind length is upgradeable (i.e. we found a child cursor that matches everything else except that the bind length is not long enough), we mark the old cursor is not usable and build a new one. This means the version can be ignored.
TOP_LEVEL_RPI_CURSOR
DIFFERENT_LONG_LENGTH
Different long length
LOGICAL_STANDBY_APPLY
DIFF_CALL_DURN
Different call duration
BIND_UACS_DIFF
PLSQL_CMP_SWITCHS_DIFF
PL/SQL compiler switches mismatch
CURSOR_PARTS_MISMATCH
STB_OBJECT_MISMATCH
STB object different (now exists). For explanation of STB_OBJECT_MISMATCH, please read following blog:https://blogs.oracle.com/optimizer/entry/my_cursor_wasn_t_shared
ROW_SHIP_MISMATCH
Row shipping capability mismatch
PQ_SLAVE_MISMATCH
TOP_LEVEL_DDL_MISMATCH
Top-level DDL cursor
MULTI_PX_MISMATCH
BIND_PEEKED_PQ_MISMATCH
Bind-peeked PQ cursor
MV_REWRITE_MISMATCH
ROLL_INVALID_MISMATCH
Rolling invalidation window exceeded. This is caused by the rolling invalidation capability in DBMS_STATS. The child cannot be shared as it's invalidation window is exceeded. See:
Document 557661.1 Rolling Cursor Invalidations with DBMS_STATS in Oracle10gOPTIMIZER_MODE_MISMATCH
Optimizer mode mismatch
PX_MISMATCH
MV_STALEOBJ_MISMATCH
Materialixed View stale object mismatch
FLASHBACK_TABLE_MISMATCH
LITREP_COMP_MISMATCH
Literal replacement compilation mismatch
New in 11g :
PLSQL_DEBUG
Debug mismatch Session has debugging parameter plsql_debug set to true
LOAD_OPTIMIZER_STATS
Load optimizer stats for cursor sharing
ACL_MISMATCH
Check ACL mismatch
FLASHBACK_ARCHIVE_MISMATCH
Flashback archive mismatch
LOCK_USER_SCHEMA_FAILED
Failed to lock user and schema
REMOTE_MAPPING_MISMATCH
Remote mapping mismatch
LOAD_RUNTIME_HEAP_FAILED
Runtime heap mismatch
HASH_MATCH_FAILED
Hash mismatch. Set to "Y" if sharing fails due to a hash mismatch, such as the case with mismatched histogram data or a range predicate marked as unsafe by literal replacement (See Bug 3461251)
PURGED_CURSOR
Cursor marked for purging. The cursor has been marked for purging with dbms_shared_pool.purge
BIND_LENGTH_UPGRADEABLE
Bind length upgradeable and could not be shared because a bind variable size was smaller than the new value being inserted (marked as BIND_MISMATCH in earlier versions).
USE_FEEDBACK_STATS
Cardinality feedback. Cardinality feedback is being used and therefore a new plan could be formed for the current execution.
BIND_EQUIV_FAILURE
The bind value's selectivity does not match that used to optimize the existing child cursor. When adaptive cursor sharing is used and the cursor is bind aware, then if the selectivity is outside of the current ranges and a new plan is desirable then a new child is raised with this as the reason code for non-sharing of the previous plan. For an example, see Document 836256.1. After each execution in the example, run:
select sql_id, address, child_address, child_number, BIND_EQUIV_FAILURE from v$sql_shared_cursor where sql_id='19sxt3v07nzm4';... once the cursor is marked as bind aware and a second plan is seen then the following will be the resultant output:
SQL_ID ADDRESS CHILD_ADDRESS CHILD_NUMBER B
------------- ---------------- ---------------- ------------ -
19sxt3v07nzm4 000000007A1C0DE0 000000007A1BF980 0 N
19sxt3v07nzm4 000000007A1C0DE0 000000007A10DDB0 1 YAs can be seen, the new version is created due to BIND_EQUIV_FAILURE
There is no longer ROW_LEVEL_SEC_MISMATCH in 11.2.
Version_rpt script:
The script version_rpt can also be run to produce a summary report of the v$sql_shared_cursor view with additional diagnostic information. The script can be found in:
Running the Script:
Generate reports for all cursors with more than 100 versions using SQL_ID (10g and up):
Generate reports for all cursors with more than 100 versions using HASH_VALUE:
Generate the report for cursor with sql_id cyzznbykb509s:
What further tracing is available.
In 10G it is possible to use CURSORTRACE to aid the investigation of why cursors are not being shared. This event should only be used under the guidance of support and the resultant trace file is undocumented. To get the trace for a particular SQL statement you first of all need to get the hash_value (See the above select from v$sqlarea). You then set the trace on using:-
(levels 578-580 can be used for high level tracing (577=level 1, 578=level 2, 580=level 3)
This will write a trace file to user_dump_dest each time we try to reuse the cursor.
To turn off tracing use:-
'immediate trace name cursortrace level 2147483648, address 1';
Please note: Bug 5555371 exists in 10.2 (fixed in 10.2.0.4) where cursor trace cannot fully be turned off and single line entries will still be made to the trace file as a result. The w/a is to restart the instance. How invasive this BUG is depends on the executions of the cursor (and the size of the resultant trace file additions)
In 11.2 there is also cursordump:
(please ensure system , not session, is used as the level meaning changes)
This dumps some additional information such as expanding on the parameters for 'optimizer_mismatch' issues.
In later versions of the RDBMS there are also enhancements which dump more information as to the actual reason a child cursor could not share (ie the parameter differences). This information can be found in the REASON column of v$sql_shared_cursor and is in XML format. See Bug 16770590 for example.
Are there any times when a high version count is expected even though BINDS are being used?
Consider the following where cursor_sharing=SIMILAR
select /* TEST */ * from emp where sal > 101;
select /* TEST */ * from emp where sal > 102;
select /* TEST */ * from emp where sal > 103;
select /* TEST */ * from emp where sal > 104;
SELECT sql_text,version_count,address
FROM V$SQLAREA
WHERE sql_text like 'select /* TEST */%';
SELECT * FROM V$SQL_SHARED_CURSOR WHERE kglhdpar = '&my_addr';
You will see several versions , each with no obvious reason for not being shared
Explanation:
One of the cursor sharing criteria when literal replacement is enabled with cursor_sharing as similar is that bind value should match initial bind value if the execution plan is going to change depending on the value of the literal. The reason for this is we _might_ get a sub optimal plan if we use the same cursor. This would typically happen when depending on the value of the literal optimizer is going to chose a different plan. Thus in this test case we have a predicate with > , if this was a equality we would always share the same child cursor. If application developers are ready to live with a sub-optimal plan and save on memory , then they need to set the parameter to force.
"The difference between SIMILAR and FORCE is that SIMILAR forces similar statements to share the SQL area without deteriorating execution plans.
Setting CURSOR_SHARING to FORCE forces similar statements to share the SQL area potentially deteriorating execution plans."
It is also possible to tell from 10046 trace (level 4/12 - BINDS) if a bind is considered to be unsafe
The flag oacfl2 in 9i and fl2 in 10g will show if a variable is unsafe.
bind 0: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24
offset=0
bfp=1036d6408 bln=22 avl=04 flg=09
value=16064
bind 1: dty=2 mxl=22(04) mal=00 scl=00 pre=00 oacflg=10 oacfl2=500 size=24
offset=0
bfp=1036d4340 bln=22 avl=04 flg=09
In 10g (10.2.0.5) and 11g using the example query above this looks like:
alter session set events '10046 trace name context forever,level 12';
select /* TEST */ * from emp where sal > :"SYS_B_0"
END OF STMT
..
BINDS #3071441600:
Bind#0
oacdty=02 mxl=22(03) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0300 frm=00 csi=00 siz=24 off=0
kxsbbbfp=295c96f0 bln=22 avl=03 flg=09
value=103
The "fl2=0300" entry indicates that this is and Unsafe literal and the bind was generated by replacement :
#define UACFUNSL 0x00000200 /* UNSafe Literal */
The 0x200 entry being the important flag for determination of literal 'safety'.
For additional details on this topic see:
Document 261020.1 High Version Count with CURSOR_SHARING = SIMILAR or FORCE
Enhancement to obsolete parent cursors if Version Count exceeds a threshold
In 11gr2, an issue of Child cursors growing very long was introduced. An enhancement request was filed to address this issue Bug 10187168. When the child cursors grow beyond certain count be it 20 or 100, it obsoletes the parent cursors. In order to activate this enhancement bug set following:
1. If 11.2.0.3 and above, set the following parameters:
2. If 11.2.0.2.2, then set:
event 106001 with value 100 (as the parameter _cursor_obsolete_threshold is not present)
To show obsoleted cursor, run following query:
from v$sql
where is_obsolete = 'N'
group by sql_id
having count(*) > 125;
For more information, please read the following article regarding the enhancement involved:
High Version Count with Adaptive Cursor Sharing
With introduction of adaptive cursor sharing in 11g, there may be increased version count due to more child cursors. The adaptive cursor sharing is meant to adapt execution plans, depending on the selectivity of the bind variable. For more information on adaptive cursor sharing, please review following note:
Some known issues with Adaptive Cursor Sharing Overview:
Document 8491399.8 Bug 8491399 - Adaptive Cursor Sharing does not match the correct cursor version for queries using CHAR datatype
Known Issues
A list of known issues can be found in:
Troubleshooting Other Issues
For guidance troubleshooting other performance issues take a look at:
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12798004/viewspace-1718575/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12798004/viewspace-1718575/
High Version Count Issues相关推荐
- High Version Count Issues(SQL高Version Count) (文档 ID 296377.1)
Troubleshooting: High Version Count Issues (文档 ID 296377.1) In this Document Purpose Ask Questions ...
- Troubleshooting: High Version Count Issues (文档 ID 296377.1)
In this Document Purpose Ask Questions, Get Help, And Share Your Experiences With This Article ...
- BIND_MISMATCH导致过多VERSION COUNT的问题
并不是用了绑定变量就一定都会游标共享,下面我们介绍的就是一种例子.BIND_MISMATCH导致VERSION COUNT过多的原因解释: This is due to the bind buffer ...
- oracle父游标和子游标,诊断Oracle high version count(高版本游标)问题
什么是high version cursor(高版本游标)?对于一个特定的游标有多少个版本就属于高版本游标是没有明确定义的.对于不同的系统有不同 什么是high version cursor(高版本游 ...
- SQL性能健康检查脚本
2019独角兽企业重金招聘Python工程师标准>>> QL性能健康检查脚本 (SQLHC)(文档 ID 1626277.1) 2017-07-10 10:37:47 分类: Ora ...
- Oracle SQL 高版本相关
本文翻译自Troubleshooting: High Version Count Issues (文档 ID 296377.1),有删改 主要内容: 什么是高版本问题 什么是共享SQL? 什么是&qu ...
- Three.js光源梳理3——平行光(DirectionalLight)
平行光本质是一个方向向量,在shader中计算时直接与模型顶点的法线方向进行dot点乘操作. 如果L(平行光)的向量与N(顶点法线方向)一样(N Dot L=1),那么表示模型的这个点正对着光源,应该 ...
- 【转载】Oracle ACE总监对Oracle 12c的一些新特性总结
2019独角兽企业重金招聘Python工程师标准>>> 本文是Oracle ACE总监Syed Jaffer Hussain对Oracle数据库12c的一些新特性总结,包括数据库管理 ...
- Oracle 高 Version counts 问题说明
一. version count 说明 MOS上有文档说明此问题,参考:[ID296377.1] Oracle里的所有SQL 语句都是implicitly sharable的. 当用户提交了一个SQL ...
最新文章
- html Frame、Iframe、Frameset 的区别 详细出处参考:http://www.jb51.net/web/22785.html
- Linux学习笔记三【文件及目录的权限管理篇】
- 口语学习Day2:今天来说说我的小客厅!
- openssl qt 生成秘钥_关于openssl作的rsa生成密钥及加解密
- 用 JavaScript 操作字符串
- android真机调式问题之offline target
- oracle em界面监控出来的奇怪图像_监控工程常见的5大难题,项目中都会遇到
- 机器学习PAI快速入门
- 如何用php开启企业微信开发的回调模式
- php点击表格单元格链接,详解PhpSpreadsheet单元格设置样式、图片、超链接等
- bilibili弹幕下载方法
- matlab功能特点,MATLAB的特点及应用领域
- 云服务器网站logo,云服务器 logo
- Matlab里fprintf个人理解(fprintf、display、%f、%f\n)
- linux中sed提取ip,通过sed命令获取IP地址
- 9月24号面试总结(康拓普2面)
- configure命令的使用
- 王学岗——————H265实现低延时投屏,从零实现高清无损投屏(对应第六节课)
- Matlab坐标轴正负指数显示
- java bbs论坛管理系统_BBS论坛管理系统
热门文章
- C++设计模式 - 单例模式(Singleton)
- 2022阿里P7级面试,掌握这份路线图上的技术点,So easy(Java岗)
- 一度智信电商是真的假的?
- iOS上传图片方向不对处理
- php如何删除文件夹里的图片,php如何删除文件夹
- 浙江大学计算机2020分数线,2021年浙江大学录取分数线(含2019-2020分数线)
- 浅谈RabbitMQ的基石—高级消息队列协议(AMQP)
- python ppt 图片_python ppt 转 pdf 图片
- 仁兄:腾讯区块链学习后的一些粗浅观点
- 谷歌 火狐 主页被篡改,修改文件名解决