不經意發現的dba_objects和dba_tables中的細節
今天有一個同學問我一個問題,因為白天比較忙也沒有在意,在下班後坐地鐵的時候抽空看了這個問題,感覺還是蠻有意思的。但是當時也沒有任何答案,就準備自己回去好好實驗一下再做答覆,至少不能敷衍別人嘛。
他的問題大體思路如下,檢視sys使用者下object_type為TABLE的物件
SQL> select owner,count(*) from dba_objects where object_type='TABLE' and owner='SYS' group by owner;
OWNER COUNT(*)
------------------------------ ----------
SYS 1007
然後檢視dba_tables中owner為sys的表
SQL> select owner,count(*)from dba_tables where owner='SYS' group by owner;
OWNER COUNT(*)
------------------------------ ----------
SYS 994
這兩個語句看起來表達的意思應該相同,但是查出來的結果卻出人意料,這位同學的疑問也再次。
於是我寫了下面這個語句,可以看到確實有10多個不同的物件,但是object_type確實為TABLE
select owner,object_name,object_type from dba_objects where object_type='TABLE' and owner='SYS' and object_name not in (select table_name from dba_tables where owner='SYS') ;
OWNER OBJECT_NAME OBJECT_TYPE
--------------- ------------------------------ -------------------
SYS KOTTD$ TABLE
SYS KOTTB$ TABLE
SYS KOTAD$ TABLE
SYS KOTMD$ TABLE
SYS KOTTBX$ TABLE
SYS KOTADX$ TABLE
SYS S_PROPS_TAB TABLE
SYS PROPERTIES_TAB TABLE
SYS USR_PROPERTIES_TAB TABLE
SYS SCHEDULER$_RJQ_ANT TABLE
SYS SCHEDULER$_FWQ_ANT TABLE
SYS SYSNTIzu9FjIBDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIDDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIFDzDgUy2FfwrwMA== TABLE
SYS SYSNT5LbVzBZPECLgQ6yq6ApJJw== TABLE
SYS SYSNT5LbVzBZRECLgQ6yq6ApJJw== TABLE
SYS SYSNT5LbVzBZTECLgQ6yq6ApJJw== TABLE
SYS SYSNTIzu9FjIKDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIMDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIODzDgUy2FfwrwMA== TABLE
20 rows selected.
這個結果是在11.2.0.4.0的環境中的,在12c中會有一些差別。
而且更奇怪的是使用desc命令直接無效,也不提示錯誤,也沒有輸出結果。
SQL> desc "KOTAD$"
SQL> desc KOTADX$
當然使用count(*)來檢視資料條數,卻能顯示出來。
SQL> select count(*)from KOTADX$;
COUNT(*)
----------
3
如果嘗試檢視這個table的內容,也給出ORA錯誤。
SQL> select * from KOTADX$;
select * from KOTADX$
*
ERROR at line 1:
ORA-30732: table contains no user-visible columns
SQL> select count(*)from KOTAD$;
COUNT(*)
----------
22511
對於這個錯誤,官方的解釋如下:
SQL> !oerr ora 30732
30732, 00000, "table contains no user-visible columns"
// *Cause: An attempt was made to query on a system table which has no
// user-visible columns.
// *Action: Do not query on a system table that has no user-visible
// columns.
那麼這個問題看起來是一個蠻神秘的細節,是不是和回收站有關係呢,我隨機用了一個環境測試。
檢視一個普通使用者下,回收站中存在幾個表。
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
BIN$JGiHLuOWWNvgUy2FfwrNqg==$0 TABLE
BIN$JGiHLuOXWNvgUy2FfwrNqg==$0 TABLE
CS_MONGO_SYNC_ID TABLE
。。。
19 rows selected.
然後使用同樣的語句來測試,使用dba_objects,以object_type='TABLE'過濾,得到17條紀錄。
SQL> select owner,count(*) from dba_objects where object_type='TABLE' and owner='TEST' group by owner;
OWNER COUNT(*)
------------------------------ ----------
TEST 17
使用dba_tables來過濾,得到17條紀錄。
SQL> select owner,count(*)from dba_tables where owner='TEST' group by owner;
OWNER COUNT(*)
------------------------------ ----------
TEST 17
所以兩者的資料條數是一致的,可見這個問題不是因為回收站導致的,那麼問題的原因在哪呢。
其實還有一個部分可能會被遺忘,那就是物件表,我們使用下面的語句來檢視。使用的是sys使用者。可以看到這些都是物件表。
SQL> select table_name,table_type from user_object_tables;
TABLE_NAME TABLE_TYPE
------------------------------ ------------------------------
SYSNTIzu9FjIBDzDgUy2FfwrwMA== KUPC$_FILEINFO
SYSNTIzu9FjIDDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIFDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIKDzDgUy2FfwrwMA== KUPC$_FILEINFO
SYSNTIzu9FjIMDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIODzDgUy2FfwrwMA== KU$_LOGLINE1010
KOTTD$ KOTTD
KOTTB$ KOTTB
KOTAD$ KOTAD
KOTMD$ KOTMD
KOTTBX$ KOTTBX
KOTADX$ KOTADX
S_PROPS_TAB DBMS_DBFS_CONTENT_PROPERTY_T
PROPERTIES_TAB DBMS_DBFS_CONTENT_PROPERTY_T
USR_PROPERTIES_TAB DBMS_DBFS_CONTENT_PROPERTY_T
SCHEDULER$_RJQ_ANT SCHEDULER$_REMOTE_ARG
SCHEDULER$_FWQ_ANT SCHEDULER_FILEWATCHER_REQUEST
SYSNT5LbVzBZPECLgQ6yq6ApJJw== KUPC$_FILEINFO
SYSNT5LbVzBZRECLgQ6yq6ApJJw== KU$_LOGLINE1010
SYSNT5LbVzBZTECLgQ6yq6ApJJw== KU$_LOGLINE1010
20 rows selected.
這個時候,可以從官網得到一些更詳細的資訊。官方的解釋如下:
SELECT dbms_metadata.get_ddl('TABLE', 'KOTAD$', 'SYS') FROM DUAL;
CREATE TABLE "SYS"."KOTAD$" OF "SYS"."KOTAD"
OIDINDEX ( PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" )
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM"
所以這些資訊就會一覽無餘的暴露在我們面前,如果想了解更多的資訊,就看看物件表的內容吧。這也是關係型之外的相容,也可以說擴充套件吧。
他的問題大體思路如下,檢視sys使用者下object_type為TABLE的物件
SQL> select owner,count(*) from dba_objects where object_type='TABLE' and owner='SYS' group by owner;
OWNER COUNT(*)
------------------------------ ----------
SYS 1007
然後檢視dba_tables中owner為sys的表
SQL> select owner,count(*)from dba_tables where owner='SYS' group by owner;
OWNER COUNT(*)
------------------------------ ----------
SYS 994
這兩個語句看起來表達的意思應該相同,但是查出來的結果卻出人意料,這位同學的疑問也再次。
於是我寫了下面這個語句,可以看到確實有10多個不同的物件,但是object_type確實為TABLE
select owner,object_name,object_type from dba_objects where object_type='TABLE' and owner='SYS' and object_name not in (select table_name from dba_tables where owner='SYS') ;
OWNER OBJECT_NAME OBJECT_TYPE
--------------- ------------------------------ -------------------
SYS KOTTD$ TABLE
SYS KOTTB$ TABLE
SYS KOTAD$ TABLE
SYS KOTMD$ TABLE
SYS KOTTBX$ TABLE
SYS KOTADX$ TABLE
SYS S_PROPS_TAB TABLE
SYS PROPERTIES_TAB TABLE
SYS USR_PROPERTIES_TAB TABLE
SYS SCHEDULER$_RJQ_ANT TABLE
SYS SCHEDULER$_FWQ_ANT TABLE
SYS SYSNTIzu9FjIBDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIDDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIFDzDgUy2FfwrwMA== TABLE
SYS SYSNT5LbVzBZPECLgQ6yq6ApJJw== TABLE
SYS SYSNT5LbVzBZRECLgQ6yq6ApJJw== TABLE
SYS SYSNT5LbVzBZTECLgQ6yq6ApJJw== TABLE
SYS SYSNTIzu9FjIKDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIMDzDgUy2FfwrwMA== TABLE
SYS SYSNTIzu9FjIODzDgUy2FfwrwMA== TABLE
20 rows selected.
這個結果是在11.2.0.4.0的環境中的,在12c中會有一些差別。
而且更奇怪的是使用desc命令直接無效,也不提示錯誤,也沒有輸出結果。
SQL> desc "KOTAD$"
SQL> desc KOTADX$
當然使用count(*)來檢視資料條數,卻能顯示出來。
SQL> select count(*)from KOTADX$;
COUNT(*)
----------
3
如果嘗試檢視這個table的內容,也給出ORA錯誤。
SQL> select * from KOTADX$;
select * from KOTADX$
*
ERROR at line 1:
ORA-30732: table contains no user-visible columns
SQL> select count(*)from KOTAD$;
COUNT(*)
----------
22511
對於這個錯誤,官方的解釋如下:
SQL> !oerr ora 30732
30732, 00000, "table contains no user-visible columns"
// *Cause: An attempt was made to query on a system table which has no
// user-visible columns.
// *Action: Do not query on a system table that has no user-visible
// columns.
那麼這個問題看起來是一個蠻神秘的細節,是不是和回收站有關係呢,我隨機用了一個環境測試。
檢視一個普通使用者下,回收站中存在幾個表。
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
BIN$JGiHLuOWWNvgUy2FfwrNqg==$0 TABLE
BIN$JGiHLuOXWNvgUy2FfwrNqg==$0 TABLE
CS_MONGO_SYNC_ID TABLE
。。。
19 rows selected.
然後使用同樣的語句來測試,使用dba_objects,以object_type='TABLE'過濾,得到17條紀錄。
SQL> select owner,count(*) from dba_objects where object_type='TABLE' and owner='TEST' group by owner;
OWNER COUNT(*)
------------------------------ ----------
TEST 17
使用dba_tables來過濾,得到17條紀錄。
SQL> select owner,count(*)from dba_tables where owner='TEST' group by owner;
OWNER COUNT(*)
------------------------------ ----------
TEST 17
所以兩者的資料條數是一致的,可見這個問題不是因為回收站導致的,那麼問題的原因在哪呢。
其實還有一個部分可能會被遺忘,那就是物件表,我們使用下面的語句來檢視。使用的是sys使用者。可以看到這些都是物件表。
SQL> select table_name,table_type from user_object_tables;
TABLE_NAME TABLE_TYPE
------------------------------ ------------------------------
SYSNTIzu9FjIBDzDgUy2FfwrwMA== KUPC$_FILEINFO
SYSNTIzu9FjIDDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIFDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIKDzDgUy2FfwrwMA== KUPC$_FILEINFO
SYSNTIzu9FjIMDzDgUy2FfwrwMA== KU$_LOGLINE1010
SYSNTIzu9FjIODzDgUy2FfwrwMA== KU$_LOGLINE1010
KOTTD$ KOTTD
KOTTB$ KOTTB
KOTAD$ KOTAD
KOTMD$ KOTMD
KOTTBX$ KOTTBX
KOTADX$ KOTADX
S_PROPS_TAB DBMS_DBFS_CONTENT_PROPERTY_T
PROPERTIES_TAB DBMS_DBFS_CONTENT_PROPERTY_T
USR_PROPERTIES_TAB DBMS_DBFS_CONTENT_PROPERTY_T
SCHEDULER$_RJQ_ANT SCHEDULER$_REMOTE_ARG
SCHEDULER$_FWQ_ANT SCHEDULER_FILEWATCHER_REQUEST
SYSNT5LbVzBZPECLgQ6yq6ApJJw== KUPC$_FILEINFO
SYSNT5LbVzBZRECLgQ6yq6ApJJw== KU$_LOGLINE1010
SYSNT5LbVzBZTECLgQ6yq6ApJJw== KU$_LOGLINE1010
20 rows selected.
這個時候,可以從官網得到一些更詳細的資訊。官方的解釋如下:
USER_OBJECT_TABLES describes the object tables owned by the current user. This view does not display the OWNER column.
那麼我們想得到更明細的資訊,其實還是有辦法的,比如使用metadata得到ddl語句。SELECT dbms_metadata.get_ddl('TABLE', 'KOTAD$', 'SYS') FROM DUAL;
CREATE TABLE "SYS"."KOTAD$" OF "SYS"."KOTAD"
OIDINDEX ( PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" )
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM"
所以這些資訊就會一覽無餘的暴露在我們面前,如果想了解更多的資訊,就看看物件表的內容吧。這也是關係型之外的相容,也可以說擴充套件吧。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1880204/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- dba_objects 中不包含 constraintObjectAI
- Layer的實現細節
- oracle中update的細節Oracle
- java: web應用中不經意的記憶體洩露JavaWeb記憶體洩露
- dba_tables 和 dba_segments 表中 blocks 的區別BloC
- 產品經理應該如何培養產品細節意識?
- 細節解析 JavaScript 中 bind 函式的模擬實現JavaScript函式
- TCP 中的兩個細節點TCP
- Python中list的切片細節Python
- Android CardView 開發過程中要注意的細節AndroidView
- 理解virtual dom的實現細節-snabbdom
- AutoMapper中的Map和DynamicMap——高手注重細節,思考和總結APP
- 筆記——Android 中的小細節筆記Android
- MySQL Xtrabackup備份原理和實現細節MySql
- Vue.js 和 MVVM 的小細節Vue.jsMVVM
- UITableView中發現的小技巧(不斷更新)UIView
- JVM(四)垃圾回收的實現演算法和執行細節JVM演算法
- iOS開發細節iOS
- 利用 CocoaPod 和 Git 管理元件中的一些細節梳理Git元件
- 簡單對比MySQL和Oracle中的一個sql解析細節MySqlOracle
- 迴圈佇列的實現及細節佇列
- PHP7中需要記住的細節PHP
- 深度學習 SSD的理解和細節分析深度學習
- 深度解析dba_segments和sys.seg$中的細節差異(上)
- 深度解析dba_segments和sys.seg$中的細節差異(下)
- 揭曉Model 3電動車5大“不為人知”的細節
- Dubbo2.7的Dubbo SPI實現原理細節
- 你所不瞭解的javascript操作DOM的細節知識點(一)JavaScript
- 專案管理中各環節的方法和實踐經驗(轉)專案管理
- Java 異常處理中的種種細節!Java
- 詳解APP介面設計中的微妙細節APP
- 那些蘋果、谷歌、微軟系統中的魔鬼細節蘋果谷歌微軟
- dba_tables中的avg_row_len是如何被計算的?
- Java中類繼承、介面實現的一些細節(長期更新)Java繼承
- Spartacus 註冊和登入頁面的實現細節
- Oracle dba_objects和all_objects 最大的區別OracleObject
- WAS 開發需要注意的一些細節
- 過度抽象和關注細節的弊端 (轉)抽象