一. 先看官網對這幾個視圖的說明(ORACLE 11gR2)
1.1 V$SQL
V$SQL
lists statistics on shared SQL areas without the
GROUP BY
clause and contains one row for each child of the original SQL text entered. Statistics displayed in
V$SQL
are normally updated at the end of query execution. However, for long running queries, they are updated every 5 seconds. This makes it easy to see the impact of long running SQL statements while they are still in progress.
Column | Datatype | Description |
| | First thousand characters of the SQL text for the current cursor |
| | Full text for the SQL statement exposed as a column. The full text of a SQL statement can be retrieved using this column instead of joining with the dynamic performance view. |
| | SQL identifier of the parent cursor in the library cache |
| | Amount of shared memory used by the child cursor (in bytes) |
| | Fixed amount of memory used for the lifetime of the child cursor (in bytes) |
| | Fixed amount of memory required during the execution of the child cursor |
| | Number of sorts that were done for the child cursor |
| | Indicates whether the context heap is loaded ( ) or not ( ) |
| | Indicates whether the child cursor is locked ( ) or not ( ) |
| | Number of users executing the statement |
| | Number of fetches associated with the SQL statement |
| | Number of executions that took place on this object since it was brought into the library cache |
| | Total number of executions performed by parallel execution servers ( when the statement has never been executed in parallel) |
| | Number of times this cursor was fully executed since the cursor was brought into the library cache. The value of this statistic is not incremented when the cursor is partially executed, either because it failed during the execution or because only the first few rows produced by this cursor are fetched before the cursor is closed or re-executed. By definition, the value of the column should be less or equal to the value of the column. |
| | Number of users executing the statement |
| | Number of times the object was either loaded or reloaded |
| | Timestamp of the parent creation time |
| | Number of times this child cursor has been invalidated |
| | Number of parse calls for this child cursor |
| | Number of disk reads for this child cursor |
| | Number of direct writes for this child cursor |
| | Number of buffer gets for this child cursor |
| | Application wait time (in microseconds) |
| | Concurrency wait time (in microseconds) |
| | Cluster wait time (in microseconds) |
| | User I/O Wait Time (in microseconds) |
| | PL/SQL execution time (in microseconds) |
| | Java execution time (in microseconds) |
| | Total number of rows the parsed SQL statement returns |
| | Oracle command type definition |
| | Mode under which the SQL statement was executed |
| | Cost of this query given by the optimizer |
| | Optimizer environment |
| | Hash value for the optimizer environment |
| | User ID of the user who originally built this child cursor |
| | Schema ID that was used to originally build this child cursor |
| | Schema name that was used to originally build this child cursor |
| | Indicates whether this child cursor has been marked to be kept pinned in the cache using the package |
| | Address of the handle to the parent for this cursor |
| | Descriptor of the type check heap for this child cursor |
| | Hash value of the parent statement in the library cache |
| | Old SQL hash value |
| | Numeric representation of the SQL plan for this cursor. Comparing one to another easily identifies whether or not two plans are the same (rather than comparing the two plans line by line). |
| | Number of this child cursor |
| | Service name |
| | Hash value for the name listed in the column |
| | Contains the name of the module that was executing at the time that the SQL statement was first parsed, which is set by calling |
| | Hash value of the module listed in the column |
| | Contains the name of the action that was executing at the time that the SQL statement was first parsed, which is set by calling |
| | Hash value of the action listed in the column |
| | Number of times the transaction failed to serialize, producing errors, per cursor |
| | If an outline was applied during construction of the cursor, then this column displays the category of that outline. Otherwise the column is left blank. |
| | CPU time (in microseconds) used by this cursor for parsing, executing, and fetching |
| | Elapsed time (in microseconds) used by this cursor for parsing, executing, and fetching |
| | Outline session identifier |
| | Address of the child cursor |
| | Denotes the version of the SQL language used for this statement |
| | Indicates whether the cursor is remote mapped ( ) or not ( ) |
| | Status of the cursor: · - Valid, authorized without errors · - Valid, authorized with authorization errors · - Valid, authorized with compilation errors · - Valid, unauthorized · - Invalid, unauthorized · - Invalid, unauthorized but keep the timestamp |
| | Hash value of the literals which are replaced with system-generated bind variables and are to be matched, when is used. This is not the hash value for the SQL statement. If is not used, then the value is . |
| | Time at which the query plan was loaded into the library cache |
| | Indicates whether the cursor has become obsolete ( ) or not ( ). This can happen if the number of child cursors is too large. |
| | Indicates whether the cursor is bind sensitive ( ) or not ( ). A query is considered bind-sensitive if the optimizer peeked at one of its bind variable values when computing predicate selectivities and where a change in a bind variable value may cause the optimizer to generate a different plan. |
| | Indicates whether the cursor is bind aware ( ) or not ( ). A query is considered bind-aware if it has been marked to use extended cursor sharing. The query would already have been marked as bind-sensitive. |
| | Indicates whether the cursor can be shared ( ) or not ( ) |
| | Child latch number that is protecting the cursor. This column is obsolete and maintained for backward compatibility. |
| | SQL profile used for this statement, if any |
| | SQL patch used for this statement, if any |
| | SQL plan baseline used for this statement, if any |
| | Program identifier |
| | Program line number |
| | Signature calculated on the normalized SQL text. The normalization includes the removal of white space and the uppercasing of all non-literal strings. |
| | Signature used when the parameter is set to |
| | TIme at which the query plan was last active |
| | Bind data |
| | Typecheck memory |
| | Number of I/O bytes which can be filtered by the Exadata storage system See Also: Oracle Exadata Storage Server Software documentation for more information |
| | Number of I/O bytes exchanged between Oracle Database and the storage system |
| | Number of physical read I/O requests issued by the monitored SQL |
| | Number of bytes read from disks by the monitored SQL |
| | Number of physical write I/O requests issued by the monitored SQL |
| | Number of bytes written to disks by the monitored SQL |
| | Number of physical read I/O requests from Database Smart Flash Cache issued by the monitored SQL |
| | Total number of times the child cursor has been locked |
| | Total number of times the child cursor has been pinned |
| | Number of uncompressed bytes (that is, size after decompression) that are offloaded to the Exadata cells See Also: Oracle Exadata Storage Server Software documentation for more information |
| | Number of bytes that are returned by the Exadata cell for smart scan only (that is, not including bytes for other database I/O) See Also: Oracle Exadata Storage Server Software documentation for more information |
1.2 V$SQLAREA
V$SQLAREA
displays statistics on shared SQL areas and contains one row per SQL string. It provides statistics on SQL statements that are in memory, parsed, and ready for execution.
Column | Datatype | Description |
| | First thousand characters of the SQL text for the current cursor |
| | All characters of the SQL text for the current cursor |
| | SQL identifier of the parent cursor in the library cache |
| | Amount of shared memory used by a cursor. If multiple child cursors exist, then the sum of all shared memory used by all child cursors. |
| | Fixed amount of memory used for the lifetime of an open cursor. If multiple child cursors exist, then the fixed sum of memory used for the lifetime of all the child cursors. |
| | Fixed amount of memory required during execution of a cursor. If multiple child cursors exist, then the fixed sum of all memory required during execution of all the child cursors. |
| | Sum of the number of sorts that were done for all the child cursors |
| | Number of child cursors that are present in the cache under this parent |
| | Number of child cursors that are present in the cache and have their context heap loaded |
| | Number of child cursors that are currently open under this current parent |
| | Number of users that have any of the child cursors open |
| | Number of fetches associated with the SQL statement |
| | Total number of executions, totalled over all the child cursors |
| | Total number of executions performed by parallel execution servers ( when the statement has never been executed in parallel) |
| | Number of times this cursor was fully executed since the cursor was brought into the library cache. The value of this statistic is not incremented when the cursor is partially executed, either because it failed during the execution or because only the first few rows produced by this cursor are fetched before the cursor is closed or re-executed. By definition, the value of the column should be less or equal to the value of the column. |
| | Total number of users executing the statement over all child cursors |
| | Number of times the object was loaded or reloaded |
| | Timestamp of the parent creation time |
| | Total number of invalidations over all the child cursors |
| | Sum of all parse calls to all the child cursors under this parent |
| | Sum of the number of disk reads over all child cursors |
| | Sum of the number of direct writes over all child cursors |
| | Sum of buffer gets over all child cursors |
| | Application wait time (in microseconds) |
| | Concurrency wait time (in microseconds) |
| | Cluster wait time (in microseconds) |
| | User I/O Wait Time (in microseconds) |
| | PL/SQL execution time (in microseconds) |
| | Java execution time (in microseconds) |
| | Total number of rows processed on behalf of this SQL statement |
| | Oracle command type definition |
| | Mode under which the SQL statement was executed |
| | Cost of this query given by the optimizer |
| | Optimizer environment |
| | Hash value for the optimizer environment |
| | User ID of the user that has parsed the very first cursor under this parent |
| | Schema ID that was used to parse this child cursor |
| | Schema name that was used to parse this child cursor |
| | Number of child cursors that have been marked to be kept using the package |
| | Address of the handle to the parent for this cursor |
| | Hash value of the parent statement in the library cache |
| | Old SQL hash value |
| | Numeric representation of the SQL plan for this cursor. Comparing one to another easily identifies whether or not two plans are the same (rather than comparing the two plans line by line). |
| | Contains the name of the module that was executing at the time that the SQL statement was first parsed as set by calling |
| | Hash value of the module that is named in the column |
| | Contains the name of the action that was executing at the time that the SQL statement was first parsed as set by calling |
| | Hash value of the action that is named in the column |
| | Number of times the transaction failed to serialize, producing errors, totalled over all the child cursors |
| | If an outline was applied during construction of the cursor, then this column displays the category of that outline. Otherwise the column is left blank. |
| | CPU time (in microseconds) used by this cursor for parsing, executing, and fetching |
| | Elapsed time (in microseconds) used by this cursor for parsing, executing, and fetching |
| | Outline session identifier |
| | Address (identifier) of the child cursor that was the last to be active in the group (that is, the child cursor on behalf of which statistics in were updated) |
| | Indicates whether the cursor is remote mapped ( ) or not ( ) |
| | Status of the cursor: · - Valid, authorized without errors · - Valid, authorized with authorization errors · - Valid, authorized with compilation errors · - Valid, unauthorized · - Invalid, unauthorized · - Invalid, unauthorized but keep the timestamp |
| | Hash value of the literals which are replaced with system-generated bind variables and are to be matched, when is used. This is not the hash value for the SQL statement. If is not used, then the value is . |
| | Time at which the query plan was loaded into the library cache |
| | Indicates whether the cursor has become obsolete ( ) or not ( ). This can happen if the number of child cursors is too large. |
| | Indicates whether the cursor is bind sensitive ( ) or not ( ). A query is considered bind-sensitive if the optimizer peeked at one of its bind variable values when computing predicate selectivities and where a change in a bind variable value may cause the optimizer to generate a different plan. |
| | Indicates whether the cursor is bind aware ( ) or not ( ). A query is considered bind-aware if it has been marked to use extended cursor sharing. The query would already have been marked as bind-sensitive. |
| | Child latch number that is protecting the cursor. This column is obsolete and maintained for backward compatibility. |
| | SQL profile used for this statement, if any |
| | SQL patch used for this statement, if any |
| | SQL plan baseline used for this statement, if any |
| | Program identifier |
| | Program line number |
| | Signature used when the parameter is set to |
| | Signature used when the parameter is set to |
| | Time at which the query plan was last active |
| | Bind data |
| | Typecheck memory |
| | Number of I/O bytes which can be filtered by the Exadata storage system See Also: Oracle Exadata Storage Server Software documentation for more information |
| | Number of I/O bytes exchanged between Oracle Database and the storage system |
| | Number of physical read I/O requests issued by the monitored SQL |
| | Number of bytes read from disks by the monitored SQL |
| | Number of physical write I/O requests issued by the monitored SQL |
| | Number of bytes written to disks by the monitored SQL |
| | Number of physical read I/O requests from Database Smart Flash Cache issued by the monitored SQL |
| | Total number of times the child cursor has been locked |
| | Total number of times the child cursor has been pinned |
| | Number of uncompressed bytes (that is, size after decompression) that are offloaded to the Exadata cells See Also: Oracle Exadata Storage Server Software documentation for more information |
| | Number of bytes that are returned by the Exadata cell for smart scan only (that is, not including bytes for other database I/O) See Also: Oracle Exadata Storage Server Software documentation for more information |
1.3 V$SQLTEXT
V$SQLTEXT
displays the text of SQL statements belonging to shared SQL cursors in the SGA.
Column | Datatype | Description |
| | Used with to uniquely identify a cached cursor |
| | Used with to uniquely identify a cached cursor |
| | SQL identifier of a cached cursor |
| | Code for the type of SQL statement ( , , and so on) |
| | Number used to order the pieces of SQL text |
| | A column containing one piece of the SQL text |
1.4 V$SQL_PLAN
V$SQL_PLAN contains the execution plan information for each child cursor loaded in the library cache.
Column | Datatype | Description |
| | Address of the handle to the parent for this cursor |
| | Hash value of the parent statement in the library cache. The two columns and can be used to join with to add the cursor-specific information. |
| | SQL identifier of the parent cursor in the library cache |
| | Numerical representation of the SQL plan for the cursor. Comparing one to another easily identifies whether or not two plans are the same (rather than comparing the two plans line by line). |
| | Address of the child cursor |
| | Number of the child cursor that uses this execution plan. The columns , , and can be used to join with to add the child cursor-specific information. |
| | Date and time when the execution plan was generated |
| | Name of the internal operation performed in this step (for example, ) |
| | A variation on the operation described in the column (for example, ) |
| | Name of the database link used to reference the object (a table name or view name). For local queries that use parallel execution, this column describes the order in which output from operations is consumed. |
| | Object number of the table or the index |
| | Name of the user who owns the schema containing the table or index |
| | Name of the table or index |
| | Alias for the object |
| | Type of the object |
| | Current mode of the optimizer for the first row in the plan (statement line), for example, . When the operation is a database access (for example, ), this column indicates whether or not the object is analyzed. |
| | A number assigned to each step in the execution plan |
| | ID of the next execution step that operates on the output of the current step |
| | Depth (or level) of the operation in the tree. It is not necessary to issue a statement to get the level information, which is generally used to indent the rows from the table. The root operation (statement) is level 0. |
| | Order of processing for all operations that have the same |
| | Number of index columns with start and stop keys (that is, the number of columns with matching predicates) |
| | Cost of the operation as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. |
| | Estimate, by the cost-based optimizer, of the number of rows produced by the operation |
| | Estimate, by the cost-based optimizer, of the number of bytes produced by the operation |
| | Describes the contents of the column. See for values. |
| | Start partition of a range of accessed partitions |
| | Stop partition of a range of accessed partitions |
| | Step that computes the pair of values of the and columns |
| | Other information specific to the execution step that users may find useful. See for values. |
| | Stores the method used to distribute rows from producer query servers to consumer query servers |
| | CPU cost of the operation as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. |
| | I/O cost of the operation as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. |
| | Temporary space usage of the operation (sort or hash-join) as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. |
| | Predicates used to locate rows in an access structure. For example, start or stop predicates for an index range scan. |
| | Predicates used to filter rows before producing them |
| | Expressions produced by the operation |
| | Elapsed time (in seconds) of the operation as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. |
| | Name of the query block |
| | Remarks |
| | Provides extra information specific to an execution step of the execution plan. The content of this column is structured using XML since multiple pieces of information can be stored there. This includes: · Name of the schema against which the query was parsed · Release number of the Oracle Database that produced the explain plan · Hash value associated with the execution plan · Name (if any) of the outline or the SQL profile used to build the execution plan · Indication of whether or not dynamic sampling was used to produce the plan · The outline data, a set of optimizer hints that can be used to regenerate the same plan |
二. 檢視GV$ 視圖的定義語句
SELECT view_definition
FROM v$fixed_view_definition
WHERE view_name = 'GV$SQL';
可以使用上面的語句查詢視圖的定義語句。 這裡查詢的是GV$, 因為V$視圖也是根據GV$出來的。 這個可以用上面的語句查詢下V$SQL 就可以驗證了。
GV$SQL的定義如下:
SELECT inst_id,kglnaobj,kglfnobj,kglobt03,kglobhs0
+ kglobhs1
+ kglobhs2
+ kglobhs3
+ kglobhs4
+ kglobhs5
+ kglobhs6
+ kglobt16,
kglobt08 + kglobt11,
kglobt10,
kglobt01,
DECODE (kglobhs6, 0, 0, 1),
DECODE (kglhdlmd, 0, 0, 1),
kglhdlkc,kglobt04,kglobt05,kglobt48, kglobt35,kglobpc6,kglhdldc,
SUBSTR (TO_CHAR (kglnatim, 'YYYY-MM-DD/HH24:MI:SS'), 1, 19),
kglhdivc, kglobt12, kglobt13, kglobwdw,
kglobt14, kglobwap, kglobwcc, kglobwcl,
kglobwui, kglobt42, kglobt43, kglobt15,
kglobt02,
DECODE (kglobt32, 0, 'NONE', 1, 'ALL_ROWS', 2, 'FIRST_ROWS',
3, 'RULE', 4, 'CHOOSE', 'UNKNOWN'),
kglobtn0, kglobcce, kglobcceh, kglobt17,
kglobt18, kglobts4, kglhdkmk, kglhdpar,
kglobtp0, kglnahsh, kglobt46, kglobt30,
kglobt09, kglobts5, kglobt48, kglobts0,
kglobt19, kglobts1, kglobt20, kglobt21,
kglobts2, kglobt06, kglobt07,
DECODE (kglobt28, 0, TO_NUMBER (NULL), kglobt28),
kglhdadr, kglobt29, DECODE (BITAND (kglobt00, 64), 64, 'Y', 'N'),
DECODE (kglobsta, 1, 'VALID', 2, 'VALID_AUTH_ERROR',
3, 'VALID_COMPILE_ERROR', 4, 'VALID_UNAUTH',
5, 'INVALID_UNAUTH', 6, 'INVALID'),
kglobt31,
SUBSTR (TO_CHAR (kglobtt0, 'YYYY-MM-DD/HH24:MI:SS'), 1, 19),
DECODE (kglobt33, 1, 'Y', 'N'),
DECODE (BITAND (kglobacs, 1), 1, 'Y', 'N'),
DECODE (BITAND (kglobacs, 2), 2, 'Y', 'N'),
DECODE (BITAND (kglobacs, 4), 4, 'Y', 'N'),
kglhdclt, kglobts3, kglobts7, kglobts6,
kglobt44, kglobt45, kglobt47, kglobt49,
kglobcla, kglobcbca, kglobt22, kglobt52,
kglobt53, kglobt54,kglobt55, kglobt56,
kglobt57, kglobt58, kglobt23, kglobt24,
kglobt59, kglobt53 - ( (kglobt55 + kglobt57) - kglobt52)
FROM x$kglcursor_child
GV$SQLTEXT 定義如下:
SELECT inst_id,
kglhdadr,
kglnahsh,
kglnasqlid,
kgloboct,
piece,
name
FROM x$kglna
WHERE kgloboct != 0
GV$SQLAREA 定義
SELECT inst_id, kglnaobj, kglfnobj, kglobt03,
kglobhs0 + kglobhs1 + kglobhs2 + kglobhs3
+ kglobhs4 + kglobhs5 + kglobhs6,
kglobt08 + kglobt11, kglobt10, kglobt01,
kglobccc, kglobclc, kglhdlmd, kglhdlkc,
kglobt04, kglobt05, kglobt48, kglobt35,
kglobpc6, kglhdldc,
SUBSTR (TO_CHAR (kglnatim, 'YYYY-MM-DD/HH24:MI:SS'), 1, 19),
kglhdivc, kglobt12, kglobt13, kglobwdw,
kglobt14, kglobwap, kglobwcc, kglobwcl,
kglobwui, kglobt42, kglobt43, kglobt15,
kglobt02,
DECODE (kglobt32, 0, 'NONE', 1, 'ALL_ROWS', 2, 'FIRST_ROWS',
3, 'RULE', 4, 'CHOOSE', 'UNKNOWN'),
kglobtn0, kglobcce, kglobcceh, kglobt17,
kglobt18, kglobts4, kglhdkmk, kglhdpar,
kglna hsh, kglobt46, kglobt30, kglobts0,
kglobt19, kglobts1, kglobt20, kglobt21,
kglobts2, kglobt06, kglobt07,
DECODE (kglobt28, 0, NULL, kglobt28),kglhdadr,
DECODE (BITAND (kglobt00, 64), 64, 'Y', 'N'),
DECODE (kglobsta, 1, 'VALID', 2, 'VALID_AUTH_ERROR', 3,
'VALID_COMPILE_ERROR',4, 'VALID_UNAUTH',5,
'INVALID_UNAUTH',6, 'INVALID'), kglobt31,kglobtt0,
DECODE (kglobt33, 1, 'Y', 'N'),
DECODE (BITAND (kglobacs, 1), 1, 'Y', 'N'),
DECODE (BITAND (kglobacs, 2), 2, 'Y', 'N'),
kglhdclt,kglobts3,kglobts7,kglobts6,
kglobt44,kglobt45,kglobt47,kglobt49,
kglobcla,kglobcbca,kglobt22,kglobt52,
kglobt53,kglobt54,kglobt55,kglobt56,
kglobt57, kglobt58, kglobt23,kglobt24,
kglobt59, kglobt53 - ( (kglobt55 + kglobt57) - kglobt52)
FROM x$kglcursor_child_sqlid
WHERE kglobt02 != 0
從上面的語句可以看出,這些視圖都是根據x$視圖來定義的。 對于X$視圖,在我以前的Blog裡有說明:
Oracle 動态性能視圖
http://www.cndba.cn/Dave/article/1449
在這篇blog的1.2節中對X$介紹:1.2 V$, V_$, GV$, X$ 視圖說明
X$表包含了特定執行個體的各方面的資訊,是Oracle資料庫的運作基礎,如目前的配置資訊,連接配接到執行個體的會話,以及豐富而有價值的性能資訊。 X$表并不是駐留在資料庫檔案的永久表或臨時表。X$表僅僅駐留在記憶體中,當執行個體啟動時,由Oracle應用程式動态建立,在記憶體中進行實時的維護。 它們中的大多數至少需要裝載或已經打開的資料庫。X$表為SYS使用者所擁有,并且是隻讀的。 不能進行DML(更新,插入,删除)。X$表對資料庫來說至關重要,是以Oracle不允許SYSDBA之外的使用者直接通路,顯示授權不被允許。
V$SQLTEXT:存儲的是完整的SQL, 但是SQL是被分割。
V$SQLAREA:存儲的SQL 和一些相關的資訊,比如累計的執行次數,邏輯讀,實體讀等統計資訊。
V$SQL: 存儲的是具體的SQL 和執行計劃相關資訊,實際上,v$sqlarea 可以看做 v$sql 根據 sqltext 等 做了 group by 之後的資訊。
v$sqltext中有記憶體中完整的sql語句,而其他兩個視圖都是部分sql語句;
但v$sqltext中沒有該語句的統計資訊,比如執行次數等。
這幾個視圖的小應用:
Oracle 實時查詢最耗CPU資源的SQL語句
http://www.cndba.cn/Dave/article/1227
三. v$sql, v$sql_plan 與執行計劃
有關執行計劃的東西,參考我的Blog:
Oracle Explain Plan
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5827245.aspx
Oracle Optimizer CBO RBO
http://www.cndba.cn/Dave/article/1458
實際上,看起來同樣的一句SQL ,往往具有不同的執行計劃, 如果是不同的資料庫使用者,那麼相應的涉及的 對象 可能都不一樣,如v$sql_plan下的:
| | Hash value of the parent statement in the library cache. The two columns and can be used to join with to add the cursor-specific information. |
| | Object number of the table or the index |
| | Name of the user who owns the schema containing the table or index |
| | Name of the table or index |
| | Current mode of the optimizer for the first row in the plan (statement line), for example, . When the operation is a database access (for example, ), this column indicates whether or not the object is analyzed. |
即使是相同的資料庫使用者,若 session 的優化模式、session 級的參數 等不一樣,執行計劃也能不同。是以即使相同的sql,也可能具有不同的執行計劃。
v$sql 和 v$sql_plan 就代表了具體的sql的執行計劃,他們通過下面3個字段做連接配接:
ADDRESS RAW(4)
HASH_VALUE NUMBER
CHILD_NUMBER NUMBER
而V$SQLAREA 忽略了 執行計劃 等差異,隻是在形式上sql文本看起來一樣。相當于做了個聚合,是多個不同執行計劃的sql的聚合和累計資訊。
------------------------------------------------------------------------------
QQ:492913789
Email:[email protected]
Blog: http://www.cndba.cn/dave
網上資源: http://tianlesoftware.download.csdn.net
相關視訊:http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
DBA1 群:62697716(滿); DBA2 群:62697977(滿)
DBA3 群:62697850 DBA 超級群:63306533;
聊天 群:40132017
--加群需要在備注說明Oracle表空間和資料檔案的關系,否則拒絕申請