Oracle9i如何監視索引並清除監視資訊(轉)
對於DML操作來說,索引對於資料庫是一個效能負擔.如果索引沒有被有效的使用,那麼其存在性就值得從新考慮.
1. 從Oracle9i開始,Oracle允許你監視索引的使用:
SQL> connect scott/tiger@connerConnected to Oracle9i Enterprise Edition Release 9.2.0.4.0 Connected as scottSQL> select index_name from user_indexes;INDEX_NAME------------------------------PK_DEPTPK_EMP開始監視pk_dept索引:SQL> alter index pk_dept monitoring usage;Index altered在此過程中,如果查詢使用索引,將會記錄下來:SQL> select * from dept where deptno=10;DEPTNO DNAME LOC------ -------------- ------------- 10 ACCOUNTING NEW YORK停止監視:SQL> alter index pk_dept nomonitoring usage;Index altered查詢索引使用情況,YES表示在監視過程中索引被使用到:SQL> select * from v$object_usage;INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING----------------- ------------------ ---------- ---- ------------------- -------------------PK_DEPT DEPT NO YES 10/28/2004 10:55:19 10/28/2004 10:55:47SQL>
2.Oracle9i的Bug
在9205之前,如果你不慎監控了SYS.I_OBJAUTH1索引,並且不幸在重起資料庫之前沒有停止它,那麼你的資料庫將會無法啟動,並且不會給出任何錯誤資訊。
以下這條簡單的語句可以輕易再現這個問題:
'ALTER INDEX SYS.I_OBJAUTH1 MONITORING USAGE'
如果你有了足夠好的備份(嚴重警告,請不要拿你的生產資料庫進行測試),你可以嘗試一下:
[oracle@jumper oradata]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Dec 4 10:09:30 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - ProductionWith the Partitioning optionJServer Release 9.2.0.4.0 - Production
SQL> alter index SYS.I_OBJAUTH1 monitoring usage ;
Index altered.
SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startupORACLE instance started.
Total System Global Area 80811208 bytesFixed Size 451784 bytesVariable Size 37748736 bytesDatabase Buffers 41943040 bytesRedo Buffers 667648 bytesDatabase mounted.
此時,資料庫掛起,而且不會有任何提示,在alert.log檔案中,你可以看到:
[oracle@jumper bdump]$ tail -f alert_conner.log Completed: ALTER DATABASE MOUNTSat Dec 4 10:09:49 2004ALTER DATABASE OPENSat Dec 4 10:09:49 2004LGWR: Primary database is in CLUSTER CONSISTENT modeThread 1 opened at log sequence 54 Current log# 2 seq# 54 mem# 0: /opt/oracle/oradata/conner/redo02.logSuccessful open of redo thread 1.Sat Dec 4 10:09:49 2004SMON: enabling cache recoverySat Dec 4 10:10:33 2004Restarting dead background process QMN0QMN0 started with pid=9
然後資料庫將會停在此處。
如果不知道此bug存在,你可能會一籌莫展的。
現在你能做的就是從備份中恢復,或者升級到9.2.0.5。
Oracle已經Release了這個Bug,你可以參考Metalink:Note:2934068.8,Oracle宣告在9.2.0.5 (Server Patch Set)和 10g Production Base Release中fixed了這個Bug。
[oracle@jumper oradata]$ rm -rf conner[oracle@jumper oradata]$ cp -R connerbak/ conner[oracle@jumper oradata]$ sqlplus '/ as sysdba'
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Dec 4 10:19:07 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to an idle instance.
SQL> startupORACLE instance started.
Total System Global Area 80811208 bytesFixed Size 451784 bytesVariable Size 37748736 bytesDatabase Buffers 41943040 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL>
3. 在特殊的情況下,你可能需要清除這個v$object_usage檢視中的資訊.
Oracle的說法是,在下一次收集該物件的索引使用情況時會自動覆蓋上一次的資訊,不提供清除手段.
稍微研究了一下.
v$object_usage是基於以下基表建立起來的:
create or replace view v$object_usage(index_name, table_name, monitoring, used, start_monitoring, end_monitoring)asselect io.name, t.name, decode(bitand(i.flags, 65536), 0, 'NO', 'YES'), decode(bitand(ou.flags, 1), 0, 'NO', 'YES'), ou.start_monitoring, ou.end_monitoringfrom sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ouwhere io.owner# = userenv('SCHEMAID') and i.obj# = ou.obj# and io.obj# = ou.obj# and t.obj# = i.bo#/
注意到v$object_usage關鍵資訊來源於OBJECT_USAGE表.另外我們可以注意一下,此處v$object_usage的查詢基於userenv('SCHEMAID')建立.所以以不同使用者登入,你是無法看到其他使用者的索引監視資訊的,即使是dba,但是可以從object_usage表中得到.
SQL> select * from v$object_usage;INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING------------------------------ ------------------------------ --- --- ------------------- -------------------PK_DEPT DEPT NO YES 10/28/2004 10:55:19 10/28/2004 10:55:47SQL> select * from object_usage;select * from object_usage *ERROR at line 1:ORA-00942: table or view does not existSQL> connect /as sysdbaConnected.SQL> / OBJ# FLAGS START_MONITORING END_MONITORING---------- ---------- ------------------- ------------------- 6288 1 10/28/2004 10:55:19 10/28/2004 10:55:47
實際上我們清除了object_usage表的記錄,實際上也就清空了v$object_usage的資訊.
SQL> delete from object_usage;1 row deleted.SQL> commit;Commit complete.SQL> select * from v$object_usage;no rows selected
此操作對資料庫沒有潛在的影響,但是請謹慎使用.作為實驗目的提供.
1. 從Oracle9i開始,Oracle允許你監視索引的使用:
SQL> connect scott/tiger@connerConnected to Oracle9i Enterprise Edition Release 9.2.0.4.0 Connected as scottSQL> select index_name from user_indexes;INDEX_NAME------------------------------PK_DEPTPK_EMP開始監視pk_dept索引:SQL> alter index pk_dept monitoring usage;Index altered在此過程中,如果查詢使用索引,將會記錄下來:SQL> select * from dept where deptno=10;DEPTNO DNAME LOC------ -------------- ------------- 10 ACCOUNTING NEW YORK停止監視:SQL> alter index pk_dept nomonitoring usage;Index altered查詢索引使用情況,YES表示在監視過程中索引被使用到:SQL> select * from v$object_usage;INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING----------------- ------------------ ---------- ---- ------------------- -------------------PK_DEPT DEPT NO YES 10/28/2004 10:55:19 10/28/2004 10:55:47SQL>
2.Oracle9i的Bug
在9205之前,如果你不慎監控了SYS.I_OBJAUTH1索引,並且不幸在重起資料庫之前沒有停止它,那麼你的資料庫將會無法啟動,並且不會給出任何錯誤資訊。
以下這條簡單的語句可以輕易再現這個問題:
'ALTER INDEX SYS.I_OBJAUTH1 MONITORING USAGE'
如果你有了足夠好的備份(嚴重警告,請不要拿你的生產資料庫進行測試),你可以嘗試一下:
[oracle@jumper oradata]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Dec 4 10:09:30 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - ProductionWith the Partitioning optionJServer Release 9.2.0.4.0 - Production
SQL> alter index SYS.I_OBJAUTH1 monitoring usage ;
Index altered.
SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startupORACLE instance started.
Total System Global Area 80811208 bytesFixed Size 451784 bytesVariable Size 37748736 bytesDatabase Buffers 41943040 bytesRedo Buffers 667648 bytesDatabase mounted.
此時,資料庫掛起,而且不會有任何提示,在alert
[oracle@jumper bdump]$ tail -f alert_conner.log Completed: ALTER DATABASE MOUNTSat Dec 4 10:09:49 2004ALTER DATABASE OPENSat Dec 4 10:09:49 2004LGWR: Primary database is in CLUSTER CONSISTENT modeThread 1 opened at log sequence 54 Current log# 2 seq# 54 mem# 0: /opt/oracle/oradata/conner/redo02.logSuccessful open of redo thread 1.Sat Dec 4 10:09:49 2004SMON: enabling cache recoverySat Dec 4 10:10:33 2004Restarting dead background process QMN0QMN0 started with pid=9
然後資料庫將會停在此處。
如果不知道此bug存在,你可能會一籌莫展的。
現在你能做的就是從備份中恢復,或者升級到9.2.0.5。
Oracle已經Release了這個Bug,你可以參考Metalink:Note:2934068.8,Oracle宣告在9.2.0.5 (Server Patch Set)和 10g Production Base Release中fixed了這個Bug。
[oracle@jumper oradata]$ rm -rf conner[oracle@jumper oradata]$ cp -R connerbak/ conner[oracle@jumper oradata]$ sqlplus '/ as sysdba'
SQL*Plus: Release 9.2.0.4.0 - Production on Sat Dec 4 10:19:07 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to an idle instance.
SQL> startupORACLE instance started.
Total System Global Area 80811208 bytesFixed Size 451784 bytesVariable Size 37748736 bytesDatabase Buffers 41943040 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL>
3. 在特殊的情況下,你可能需要清除這個v$object_usage檢視中的資訊.
Oracle的說法是,在下一次收集該物件的索引使用情況時會自動覆蓋上一次的資訊,不提供清除手段.
稍微研究了一下.
v$object_usage是基於以下基表建立起來的:
create or replace view v$object_usage(index_name, table_name, monitoring, used, start_monitoring, end_monitoring)asselect io.name, t.name, decode(bitand(i.flags, 65536), 0, 'NO', 'YES'), decode(bitand(ou.flags, 1), 0, 'NO', 'YES'), ou.start_monitoring, ou.end_monitoringfrom sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ouwhere io.owner# = userenv('SCHEMAID') and i.obj# = ou.obj# and io.obj# = ou.obj# and t.obj# = i.bo#/
注意到v$object_usage關鍵資訊來源於OBJECT_USAGE表.另外我們可以注意一下,此處v$object_usage的查詢基於userenv('SCHEMAID')建立.所以以不同使用者登入,你是無法看到其他使用者的索引監視資訊的,即使是dba,但是可以從object_usage表中得到.
SQL> select * from v$object_usage;INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING------------------------------ ------------------------------ --- --- ------------------- -------------------PK_DEPT DEPT NO YES 10/28/2004 10:55:19 10/28/2004 10:55:47SQL> select * from object_usage;select * from object_usage *ERROR at line 1:ORA-00942: table or view does not existSQL> connect /as sysdbaConnected.SQL> / OBJ# FLAGS START_MONITORING END_MONITORING---------- ---------- ------------------- ------------------- 6288 1 10/28/2004 10:55:19 10/28/2004 10:55:47
實際上我們清除了object_usage表的記錄,實際上也就清空了v$object_usage的資訊.
SQL> delete from object_usage;1 row deleted.SQL> commit;Commit complete.SQL> select * from v$object_usage;no rows selected
此操作對資料庫沒有潛在的影響,但是請謹慎使用.作為實驗目的提供.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/756652/viewspace-242140/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 在Oracle9i中,如何監視索引並清除監視資訊Oracle索引
- Oracle9i中監視索引的使用(轉)Oracle索引
- Oracle“並行執行”——監控檢視Oracle並行
- Redis Manager 如何檢視監控Redis
- (轉)Windows 效能監視器工具-perfmonWindows
- 監視映象資料庫的其他資訊源資料庫
- windows 事件監視器資訊查詢/寫入Windows事件
- 反NP監視原理並有例項說明
- --------監視你的 TCP/IP埠!!!(vb)----------- (轉)TCP
- 監視stale statistics(失真的統計資訊)的物件!物件
- 2 Day DBA-檢視監聽器配置-練習:使用Database Control檢視監聽器資訊Database
- vue 監視屬性Vue
- 製作資料庫映象監視器的警告資訊資料庫
- sar效能監視命令-實時監控CPU
- 網站是如何跟蹤監視你的網站
- ZooKeeper 監視點詳解
- 效能監視器- Performance MonitorORM
- SQL SERVER 效能監視器SQLServer
- SAP監視系統CCMS
- 024 監視簡寫
- synchronized的monitor監視器synchronized
- Java的物件監視器Java物件
- 監視磁碟使用情況
- 資訊化專案“監理”究竟“監理” (一)(轉)
- 資訊化專案“監理”究竟“監理” (二)(轉)
- mongodb 如何檢視索引MongoDB索引
- 016、Vue3+TypeScript基礎,使用watch監視和結束監視VueTypeScript
- 資訊化專案“監理”究竟“監理”什麼(轉)
- 如何監控oracle的索引是否使用Oracle索引
- Hystrix 監控視覺化頁面——Dashboard 流監控視覺化
- Mysql效能監控視覺化MySql視覺化
- linux 資源監視器Linux
- DB2快照監視器DB2
- 監視閃回資料庫資料庫
- db2top監視命令DB2
- DB2_狀態監視DB2
- Oracle SMON系統監視程式Oracle
- 監視index的使用情況Index