那是不是我們每當遇到性能問題的時候都要patch到9.2.0.3呢?
我們已經(jīng)知道他的真實情況依然在v$session_wait的p1、p2、p3參數(shù)里體現(xiàn),所以,我們可以根據(jù)這些參數(shù),找出這個null event究竟是什么等待事件。
相關信息:
1. lck processes to pick up extra or missed 'posts' (messages)。
in all cases that can be identified the wait time is zero,
although on most ports this is changed to 1/100th second in
order to force the process to be rescheduled.
2. multiple db writers.
two cases:
- when the master has sent i/o requests to the slaves, it
waits on this event for up to 6 seconds until the slaves
signal that the i/o is complete.
- the slaves wait on this event for up to 3 seconds whilst
waiting for requests from the master db writer.
目前已經(jīng)被證實的會涉及到null event
的等待事件還有有sql.net message to client、
db file scattered (or sequential) read
與無壓縮格式下存儲數(shù)據(jù)相比,新的Oracle數(shù)據(jù)壓縮技術能夠確保以較小的開銷節(jié)省三倍以上的磁盤存儲空間。這一點比僅節(jié)省磁盤空間要具有更大的優(yōu)勢,因為它能夠使企業(yè)節(jié)約更多的開支,以便有更多的資金來鞏固自己的地位。自動診斷知識庫(Automatic Diagnostic Repository,ADR)是專門針對嚴重錯誤的知識庫。該知識庫基本上能夠自動完成一些以往需要由數(shù)據(jù)庫管理員來手動完成的操作。
作為ADR的一部分,SQL性能分析器(SQL Performance Analyzer,SPA)是最讓人驚喜的特性之一。SQL性能分析器是一個整體調整工具,管理員可以通過該工具在數(shù)據(jù)庫上定義和重演(replay) 一個典型的工作負載,之后管理員可以調節(jié)整體參數(shù)來使數(shù)據(jù)庫盡快的達到最佳性能——而這一任務同樣也是許多年以來由數(shù)據(jù)庫管理員手動完成的。
由于獲得了最優(yōu)的初始參數(shù),數(shù)據(jù)庫管理員就不需要調整數(shù)以萬計的SQL語句。管理員需要做的就是給定一個典型的負載 ,由SAP根據(jù)歷史記錄來決定SQL的最終設置,而不用管理員來檢測哪一個SQL設置是最合理的。
多年以來,甲骨文公司一直在努力完成地另一個新特性便是“聯(lián)機更新”(在不down機的情況下更新軟件)。實際上,很難從軟件工程的角度來設計一個運行時能自動升級的軟件。由于真正的應用集群(Real Application Clusters ,RAC)特性,甲骨文公司再一次對其他的數(shù)據(jù)庫供應商造成了更大的壓力。在實際的使用過程中,數(shù)據(jù)庫產(chǎn)品的用戶總是希望產(chǎn)品有持續(xù)的高可用性,這并不是說只需滿足下次補丁更新之前的3年的時間就夠了。
自動內存管理特性可以追根溯源至Oracle 9i,那時甲骨文公司推出首款自動調節(jié)存儲池的工具。AMM工具其實就是一種探測機制。實際上,Oracle 11g 有很多隨機訪問存儲池,當AMM探測到某個存儲池中已滿時,它將整個RAM從一個區(qū)域分配到其他相對合適的區(qū)域。