建站
咨詢
售后
建站咨詢
新聞中心
隨著互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)的不斷發(fā)展，數(shù)據(jù)庫成為了大數(shù)據(jù)處理的核心。在應用程序中，數(shù)據(jù)庫可用于存儲、訪問和修改數(shù)據(jù)。在數(shù)據(jù)庫系統(tǒng)中，高命中率是一項重要的指標，它反映了數(shù)據(jù)庫的性能和效率，并對應用程序的響應時間產(chǎn)生直接影響。因此，提高數(shù)據(jù)庫實例命中率就成了數(shù)據(jù)庫管理員不可回避的重要任務。本文就帶領大家深入了解如何提高數(shù)據(jù)庫實例命中率。
一、什么是數(shù)據(jù)庫實例命中率？
在數(shù)據(jù)庫系統(tǒng)中，實例指的是運行在計算機上的數(shù)據(jù)庫進程。命中率指的是緩存中的數(shù)據(jù)在數(shù)據(jù)庫的訪問中所占的比例。因此，數(shù)據(jù)庫實例命中率就是數(shù)據(jù)庫實例中緩存中的數(shù)據(jù)被命中而不需要在磁盤中進行訪問的比例。
二、提高數(shù)據(jù)庫實例命中率的方法
1. 使用高速硬件
數(shù)據(jù)庫緩存通常使用高速存儲器來存儲數(shù)據(jù)，如RAM。因此，使用高速硬件裝備服務器可以提高緩存的速度，從而提高數(shù)據(jù)庫實例命中率。此外，使用固態(tài)硬盤(SSD)來替換傳統(tǒng)的機械硬盤也是一種有效的方法。
2. 使用適當?shù)臄?shù)據(jù)庫調(diào)度策略
有些數(shù)據(jù)庫采用了訪問策略，比如先進先出、最近最少使用等。然而，這些策略不一定都是最為合適的。因此，需要根據(jù)實際情況選擇適當?shù)臄?shù)據(jù)庫調(diào)度策略，以提高命中率。一些數(shù)據(jù)庫產(chǎn)品還提供了一些更為高級的調(diào)度策略，如自適應調(diào)度。
3. 加倍緩存
為了提高數(shù)據(jù)庫實例命中率，還可以嘗試增加緩存的大小。這可以通過調(diào)整數(shù)據(jù)庫的緩存參數(shù)實現(xiàn)。要注意的是，緩存過大可能會導致緩存效率低下，因此建議在實驗性階段逐步增加緩存的大小，并根據(jù)實際需要作出相應的調(diào)整。
4. 優(yōu)化查詢
對于大型數(shù)據(jù)庫來說，查詢優(yōu)化是提高數(shù)據(jù)庫性能的關(guān)鍵。可以使用索引、提高SQL語句執(zhí)行效率等方式來優(yōu)化查詢。同時，也需要避免經(jīng)常使用全表掃描的語句。優(yōu)化查詢，可以減少磁盤讀寫操作，從而提高命中率。
5. 使用數(shù)據(jù)分區(qū)
數(shù)據(jù)分區(qū)可以將一個大表劃分成更小的數(shù)據(jù)塊，每個數(shù)據(jù)塊都存儲在不同的硬盤上。這可以提高磁盤訪問的效率，從而提高命中率。數(shù)據(jù)分區(qū)還可以為應用程序提供更好的性能，并減少鎖的競爭。
6. 定期維護數(shù)據(jù)庫
定期維護數(shù)據(jù)庫可以避免數(shù)據(jù)過期、索引失效、空閑空間不足等問題。這可以幫助緩存保持高效，并提高命中率。一些數(shù)據(jù)庫系統(tǒng)也提供了自動維護功能，可以自動處理這些任務。
三、
為了提高數(shù)據(jù)庫實例命中率，需要使用高速硬件、適當?shù)臄?shù)據(jù)庫調(diào)度策略、加倍緩存、優(yōu)化查詢、使用數(shù)據(jù)分區(qū)和定期維護數(shù)據(jù)庫。數(shù)據(jù)庫管理員應該根據(jù)實際情況選擇適合自己的策略，并根據(jù)緩存的效率和實際需要對策略進行相應的調(diào)整。這樣可以確保數(shù)據(jù)庫系統(tǒng)的高性能，同時提高應用程序的響應速度，提高應用程序的用戶體驗。
相關(guān)問題拓展閱讀：
- 如何在 SAP 系統(tǒng)中監(jiān)控和分析 DB2 UDB 性能
- oracle性能檢測sql語句
如何在 SAP 系統(tǒng)中監(jiān)控和分析 DB2 UDB 性能
性能問題總是數(shù)據(jù)庫領域里面永恒的話題，使用 DB2 作為底層數(shù)據(jù)平臺的 SAP 系統(tǒng)為我們提供了許多方法監(jiān)控和檢測數(shù)據(jù)庫性能問題。本文從數(shù)據(jù)庫性能問題檢測的一般思路和方法論入手，介紹了如何通過 SAP 系統(tǒng)對 DB2 的性能進行監(jiān)控和分析?；仨撌讛?shù)據(jù)庫性能問題檢測的思路及方法論在數(shù)據(jù)庫運維工作中遇到性能問題時，通常會讓數(shù)據(jù)庫管理員感到無從下手，不容易斷定問題的根源所在。如果能有一種可操作的一般性的方法作為指導，我們通常就能夠發(fā)現(xiàn)大部分數(shù)據(jù)庫性能問題的根源。那么，首先根據(jù)我們對數(shù)據(jù)庫性能監(jiān)控的一些實踐經(jīng)驗來總結(jié)一下在遇到性能問題時應該進行哪些檢查。我們不能保證通過文中介紹的方法就能找到所有性能瓶頸，性能問題的原因很多，解決方法也多種多樣，我們在這里只是提供一些普遍的，一般性的方法，具體的實施還需要根據(jù)系統(tǒng)的具體情況和不斷的實踐經(jīng)驗積累。同時，通過進行這些監(jiān)控，也有利于為技術(shù)支持人員提供更詳細診斷信息，以便于快速定位性能問題。當遇到一個性能問題，我們首先進塌兆行以下排查： 性能問題是在何時發(fā)生的； 性能問題持續(xù)存在的還是間斷性的； 系統(tǒng)范疇的性能問題還是數(shù)據(jù)庫本身的性能問題； 性能問題是否只存在于某一個應用； 性能問題是隨機出現(xiàn)的還是必然出現(xiàn)的。如果性能問題存在于所有應用，我們可以進行以下排查： 如果發(fā)現(xiàn)系統(tǒng)存在大量的 I/O 操作： 檢查設備磨辯使用情況； 檢查排序情況和臨時表空間； 檢查查詢性能是否有效的得到優(yōu)化； 檢查緩沖池的使用狀況。 如果發(fā)現(xiàn) CPU 具有很高的負載： 檢查排序狀況； 檢查緩沖池的使用狀況。 如果發(fā)現(xiàn) CPU 和 I/O 操作的負荷都很大： 檢查用戶數(shù)量； 檢查排序狀況。 如果發(fā)現(xiàn) CPU 和 I/O 操作的負荷都很小而數(shù)據(jù)庫響應仍然很慢： 檢查并發(fā)性和鎖的使用狀況； 檢查緩沖池的使用狀況。如果性能問題可以被定位在一個應用，我們可以進行以下排查： 檢查排序情況。 檢查并發(fā)性和團游租鎖的使用狀況。 檢查統(tǒng)計信息是否更新?；仨撌淄ㄟ^SAP 系統(tǒng)的工具對 DB2 UDB 進行監(jiān)控通過前一部分的描述，我們了解到了在遇到性能問題以后應該用什么思路尋找性能的瓶頸，從而想辦法解決性能問題。在對數(shù)據(jù)庫進行檢查的過程中，我們通常會用到數(shù)據(jù)管理工具，命令行以及操作系統(tǒng)的工具，還要結(jié)合 SAP 的自身特點尋找性能問題的根源，這將是一個比較繁瑣和費事的工作。在使用 SAP 作為底層數(shù)據(jù)庫的 SAP 系統(tǒng)中，由于 SAP 實現(xiàn)了與 DB2 緊密的結(jié)合。SAP 的 DBA Cockpit 提供了許多功能來支持數(shù)據(jù)庫的管理工作，使得數(shù)據(jù)庫性能監(jiān)控和分析變得更加簡單。下面我們就來看看，SAP 為 DB2 性能監(jiān)控和分析提供了哪些支持。磁盤I/O 性能監(jiān)控概念對于數(shù)據(jù)庫來說，最消耗時間的操作實際上是從磁盤中檢索數(shù)據(jù)。這是由磁盤的物理特性決定的。盡管磁盤存儲技術(shù)已經(jīng)取得了極大的進步，但磁盤的讀寫速度與內(nèi)存的讀寫速度仍然相差幾個數(shù)量級。從性能調(diào)整的角度來說，如果一個機器的磁盤出現(xiàn)問題，那么其他的任何優(yōu)化工作都無法提供幫助。因此我們應該保證運行數(shù)據(jù)庫的磁盤系統(tǒng)是健康的。SAP 系統(tǒng)為我們提供了監(jiān)控磁盤讀寫速度的功能，讓我們可以直接了解當前磁盤的性能狀況。監(jiān)控我們首先進入 SAP 的 DBA Cockpit ( 可以直接輸入 st04)，然后在 Performance 的目錄下雙擊 Database, Buffer Pool 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫磁盤的讀寫狀況。圖1. 磁盤 I/O 信息從圖中我們可以看到磁盤物理平均讀速度為 3.25ms，寫速度為 7.45ms。分析磁盤物理讀寫速度反應了磁盤子系統(tǒng)的性能。一般情況下，磁盤讀寫速度應該小于 5ms，讀速度一般要大于寫速度，但在一些具有大量緩存的存儲系統(tǒng)中，寫速度可能會快于讀速度。磁盤性能的優(yōu)化已經(jīng)超出了本文討論的范圍，這里只是提供一些基本的指導。緩沖池監(jiān)控概念緩沖池是數(shù)據(jù)庫單獨開辟的一塊存儲區(qū)域，這片區(qū)域用來緩存從磁盤讀出的包含數(shù)據(jù)表和索引的數(shù)據(jù)頁。當數(shù)據(jù)之一次被檢索出來以后便被暫時緩存在緩沖池中，當數(shù)據(jù)下次被訪問時，數(shù)據(jù)庫將直接從緩沖池中讀取數(shù)據(jù)，這樣減少了相對緩慢的磁盤 I/O 操作。因此，緩沖池的配置對于數(shù)據(jù)庫性能十分重要。在緩沖池中，目前還不支持存儲大對象和長數(shù)據(jù)記錄。反映緩沖池質(zhì)量的一個重要性能指標是緩沖池命中率。緩沖池命中率指數(shù)據(jù)庫管理器不需從磁盤讀入頁就能處理頁請求的時間百分比。其計算方法為：緩沖池命中率 = (1 – (( 緩沖池數(shù)據(jù)物理讀 + 緩沖池索引物理讀 ) / ( 緩沖池數(shù)據(jù)邏輯讀 + 緩沖池索引邏輯讀 ) ) ) * 100%另外兩個重要性能指標是索引命中率和數(shù)據(jù)命中率。索引命中率反映了可以在緩沖池中找到的頁面能夠滿足的對索引頁的所有讀請求所占的百分比。其計算方法為：索引命中率 = (1 – ( 緩沖池索引物理讀 / 緩沖池索引邏輯讀 ) ) ) * 100%數(shù)據(jù)命中率說明了可以在緩沖池中找到的頁面能夠滿足的對數(shù)據(jù)頁的所有讀請求所占的百分比。其計算方法為：數(shù)據(jù)命中率 = (1 – ( 緩沖池數(shù)據(jù)物理讀 / 緩沖池數(shù)據(jù)邏輯讀 ) ) ) * 100%監(jiān)控我們可以從三個級別來看緩沖池的質(zhì)量，這三個層次分別是數(shù)據(jù)庫級，緩沖池級，表空間級。在 SAP 系統(tǒng)中我們可以使用 DBA Cockpit 來查看不同級別的緩沖池質(zhì)量。首先可以在數(shù)據(jù)庫級查看緩沖池的質(zhì)量，我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Database, 在 Buffer Pool 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫總體的緩沖池質(zhì)量。圖2. 緩沖池總體狀況我們從圖中可以看出，數(shù)據(jù)庫緩沖池的總體命中率是 99.81%，數(shù)據(jù)命中率為 99.86%，索引命中率為 99.70%。如果在 st04 中選中 Performance -> Buffer pools， 我們也可以在緩沖池級別看到命中率，如果一個數(shù)據(jù)庫只有一個緩沖池，那么這個命中率與我們在數(shù)據(jù)庫級別看到的命中率相同。圖3. 數(shù)據(jù)庫級別緩沖池信息如果在 st04 中選中 Performance -> Tablespaces，我們就可以在表空間級別看到緩沖池的命中率。圖4. 表空間級別緩沖池信息分析緩沖池的理想命中率對于索引應該大于 90%, 對于數(shù)據(jù)應該大于 95%。要提高緩沖池的命中率，可以增加緩沖池的大小，也可以為不同類型數(shù)據(jù)分配不同緩沖池，可以為每個經(jīng)常訪問的具有自己的表空間的大型表使用一個緩沖池，也可以為一組小型表使用一個緩沖池。緩存監(jiān)控概念數(shù)據(jù)庫的緩存主要有包緩存 (Package Cache) 和編目錄緩存 (Catalog Cache)。它們與數(shù)據(jù)庫的查詢性能息息相關(guān)。包緩存(Package Cache) ：SQL 語句編譯通常消耗的資源比較大，為了提高系統(tǒng)性能，動態(tài) SQL 語句在被編譯后一般存放于包緩存中。當用戶下一次請求同一條 SQL 語句，就無需再次編譯 SQL 語句。包緩存的質(zhì)量一般通過包緩存命中率來衡量，它表明了包緩存的設置是否成功的避免了 SQL 語句的重新編譯。其計算方法為：包緩存命中率 = (1 – ( 在包緩存中的插入次數(shù) / 查詢包緩存的次數(shù) )) * 100編目錄緩存 (Catalog Cache)：編目錄緩存用來緩存系統(tǒng)編目錄信息，如系統(tǒng)表，權(quán)限，系統(tǒng)存儲過程。系統(tǒng)編目錄的訪問速度對于系統(tǒng)的性能有著十分重要的影響。在 DPF 環(huán)境下，系統(tǒng)編目錄的訪問速度至關(guān)重要。通過使用編目錄緩存可以大大提高訪問系統(tǒng)編目錄的速度。編目錄緩存質(zhì)量一般通過編目錄命中率來衡量，它表明了編目錄緩存是否成功的避免了從磁盤中讀取編目錄信息。其計算方法為：包緩存命中率 = (1 – ( 在編目錄緩存中的插入次數(shù) / 查詢編目錄緩存的次數(shù) )) * 100監(jiān)控我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Database, 在 Cache 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫緩存的統(tǒng)計信息。圖5. 數(shù)據(jù)庫緩存信息從圖中我們可以看到編目錄緩存的質(zhì)量是 99.93%，在圖中的 quality 就是我們前面所說的命中率。當前數(shù)據(jù)庫編目錄緩存的大小為 10240KB，沒有緩存溢出。在左邊一欄，我們可以看到，包緩存的質(zhì)量是 97.64%，包緩存的大小為 62023KB，沒有緩存溢出。分析包緩存的理想命中率應該大于 98%，用戶通常不用關(guān)注包緩存的大小，如果 PCKCACHESZ 被設置為 automatic，其大小由 DB2 自動調(diào)節(jié)。編目錄緩存的理想命中率也應該大于 98%，其大小應該保證編目錄緩存不應該發(fā)生任何溢出。我們可以調(diào)整數(shù)據(jù)庫配置參數(shù) CATALOGCACHE_SZ 來改變編目錄緩存大小，由于編目錄緩存是從數(shù)據(jù)庫堆中分配的，因此，在改變 CATALOGCACHE_SZ 變量的同時，應該注意到數(shù)據(jù)庫堆的大小也會相應改變。排序監(jiān)控概念DB2 在運行過程中時經(jīng)常要做排序操作。一般說來，在 OLTP 類型的數(shù)據(jù)庫中，排序操作通常少于 OLAP 類型的數(shù)據(jù)庫環(huán)境。排序操作通常會在三種情況下發(fā)生，之一種情況是數(shù)據(jù)的查詢處理，比如 order by, group, 哈希連接，索引操作，內(nèi)存的表操作等等。第二種是當我們載入操作的對象是帶有索引的表時，再載入操作過程中就會涉及到對索引鍵的列表和排序，這樣就會產(chǎn)生排序操作。第三種情況發(fā)生在創(chuàng)建索引的時候。排序的效率因而直接影響到數(shù)據(jù)庫的響應時間，我們必須對排序進行有效監(jiān)控。監(jiān)控我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Database, 在 Sorts 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫的排序狀況。圖6. 數(shù)據(jù)庫排序狀況可以從圖中看出，共享排序堆的大小為 1676KB, 私有排序堆的大小為 1340KB。如果沒有索引滿足所取的行的要求順序，或者 DB2 查詢優(yōu)化器認為排序的代價低于索引掃描，那么就需要在排序堆中進行排序。DB2 的排序分為私有排序和共享排序。私有排序發(fā)生在代理的私有代理內(nèi)存中，而共享排序發(fā)生在數(shù)據(jù)庫的數(shù)據(jù)庫共享內(nèi)存中。我們還可以看出，排序堆溢出次數(shù) 1174 次，總的排序次數(shù)為次。分析如果數(shù)據(jù)庫分配的排序堆大小不夠大，就會出現(xiàn)排序溢出的情況，這樣就需要動用臨時表空間來輔助排序的進行，由于臨時表空間存在于磁盤，這將大大影響排序的速度。理想情況下，排序溢出率 ((Sort overflows * 100) / Total sorts ) 不應該超過 1%。如果這個溢出率過高，那么數(shù)據(jù)庫中很可能發(fā)生了大的排序，我們就需要調(diào)查出現(xiàn)過度排序的原因。在發(fā)現(xiàn)根源之前，一個簡易的解決方案是增加 SORTHEAP 的大小。然而，這樣做通常是治標不治本并且掩蓋了真實的性能問題。比較徹底的解決方案應該是確定引起排序的 SQL 并更改該語句，或通過增加索引來避免或減少排序開銷。并發(fā)性和鎖的監(jiān)控概念數(shù)據(jù)庫的鎖是數(shù)據(jù)庫管理器用來控制應用程序并發(fā)訪問數(shù)據(jù)庫數(shù)據(jù)并且保證數(shù)據(jù)庫數(shù)據(jù)的一致性的重要機制，數(shù)據(jù)庫中行和表都可以上鎖。數(shù)據(jù)庫的鎖在保證了數(shù)據(jù)庫數(shù)據(jù)一致性同時也在一定程度上降低了數(shù)據(jù)庫的響應速度。鎖等待和死鎖是影響數(shù)據(jù)庫相應速度的重要因素，糟糕的應用程序設計和不合理的 SQL 查詢計劃的生成都會導致鎖等待和死鎖。鎖升級 (Lock Escalation)：一個鎖通常作為一個記錄存儲在內(nèi)存鎖表中，鎖表的大小可以由數(shù)據(jù)庫自動調(diào)節(jié)。鎖升級一般發(fā)生在鎖的數(shù)量超過了數(shù)據(jù)庫配置參數(shù) MAXLOCKS 所指定的大小，為了減少鎖的數(shù)量，數(shù)據(jù)庫會把若干行一級的鎖合并為表鎖。這樣數(shù)據(jù)庫的并發(fā)性就會受到影響。監(jiān)控我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Database, 在 Locks and Deadlocks 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫的鎖的狀況。圖7. 數(shù)據(jù)庫鎖狀況從圖中可以看到，當前鎖表的大小為 22144KB，已經(jīng)使用了 94KB。鎖等待的平均時間為 10.40ms，沒有鎖升級和死鎖被檢測到。分析影響數(shù)據(jù)性能的有關(guān)鎖的問題主要集中在鎖等待，死鎖和鎖升級。這些問題的根源很可能是數(shù)據(jù)庫應用的設計問題。因此，我們應該仔細調(diào)查造成死鎖，鎖等待和鎖升級的應用程序，以及其用到的 SQL 語句。同時，在問題定位之前，我們也可以通過下面方法來解決數(shù)據(jù)庫鎖造成的性能問題。鎖等待和死鎖：如果要避免鎖等待和死鎖的問題我們需要注意數(shù)據(jù)庫參數(shù)中的 DLCHKTIME 和 LOCKTIMEOUT 兩個參數(shù)的設置。其中 DLCHKTIME 單位是毫秒，是 DB2 檢查死鎖的間隔時間，如果該值為 10000ms，則表明每隔 10 秒鐘數(shù)據(jù)庫會檢查一下有無死鎖存在，如有死鎖，會選擇回滾其中的某一個事務，讓另外一個事務完成交易。LOCKTIMEOUT 單位是秒，是鎖等待最長時間，超過該時間仍未獲得鎖，則返回錯誤。LOCKTIMEOUT 的默認值為 -1，這意味著鎖等待時間無限大，一般不推薦這種設置。DLCHKTIME 時間通常要設得比 LOCKTIMEOUT 時間小一些，否則還未發(fā)現(xiàn)死鎖，就會返回鎖等待超時錯誤 (SQL0911N 返回碼 68) 。鎖升級：要避免鎖升級，我們應該正確設置數(shù)據(jù)庫參數(shù) LOCKLIST 和 MAXLOCKS。LOCKLIST 表明分配給鎖表的內(nèi)存大小。每個數(shù)據(jù)庫都有一個鎖表，鎖表包含了并發(fā)連接到該數(shù)據(jù)庫的所有應用程序所持有的鎖。MAXLOCKS 定義了應用程序可以占有鎖表空間的百分比，當一個應用程序所使用的鎖表百分比達到 MAXLOCKS 時，數(shù)據(jù)庫管理器會升級這些鎖，用表鎖代替行鎖，從而減少列表中鎖的數(shù)量。我們一般可以通過增加鎖表大小的方法解決鎖升級問題。日志性能監(jiān)控概念DB2 事務日志對于恢復來說極其重要。它們記錄對數(shù)據(jù)庫對象和數(shù)據(jù)所做的更改。在 DB2 中數(shù)據(jù)和索引的改變都會先被寫入日志緩沖區(qū)，保證對數(shù)據(jù)所做的修改在記錄到數(shù)據(jù)庫之前，總是被具體化為日志文件。日志緩沖區(qū)的數(shù)據(jù)由日志處理器寫入磁盤。在下列情況下，查詢處理必須等待日志數(shù)據(jù)寫入磁盤后才能進行： 事務提交時。
在將相應數(shù)據(jù)頁寫入磁盤之前，因為 DB2 使用預寫日志記錄。預寫日志記錄的好處是當執(zhí)行 COMMIT 語句完成事務之后，并非所有更改的數(shù)據(jù)和索引頁都需要寫入磁盤。 在元數(shù)據(jù)更改（一般通過執(zhí)行 DDL 語句產(chǎn)生的）之前。 日志緩沖區(qū)已滿。DB2 以這種方法管理向磁盤寫入日志數(shù)據(jù)的目的是盡可能地縮短處理延遲時間。在存在許多較小的并發(fā)事務的環(huán)境中，許多處理延遲是由 COMMIT 造成的，因為它必須等待日志數(shù)據(jù)寫入磁盤后才能進行。因此，日志處理器進程頻繁地將少量日志數(shù)據(jù)寫入磁盤會造成大量處理延遲，另外一些延遲是由日志 I/O 開銷造成的。監(jiān)控我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Database, 在 Logging 的標簽內(nèi)，可以看到當前數(shù)據(jù)庫日志的狀況。圖8. 數(shù)據(jù)庫日志狀況我們在圖中可以看到日志文件以及日志緩沖區(qū)的情況。包括日志文件的數(shù)量，大小，數(shù)據(jù)庫使用的日志空間以及可用日志空間的大小。還可以看到日志緩沖區(qū)的情況，當前日志緩沖區(qū)的命中率為 100%。分析由于數(shù)據(jù)庫中的處理必須等待日志數(shù)據(jù)寫入磁盤才能進行，日志文件的讀寫速度對數(shù)據(jù)庫的響應速度也會產(chǎn)生很大影響。因此，應該把日志文件放到速度比較快的磁盤上，以減少磁盤 I/O 開銷。日志文件寫入的性能可以通過平均寫時間來觀察。另外，我們可以通過調(diào)整數(shù)據(jù)庫配置參數(shù) LOGBUFSZ 來指定日志緩沖區(qū)的大小。如果數(shù)據(jù)庫對于日志磁盤有相當多的讀操作，或者希望有較高的磁盤利用率。一般來說，如果日志緩沖區(qū)的命中率小于 98%，那么可以增加這個緩沖區(qū)的大小以提高命中率。當增加這個參數(shù)的值時，也要考慮 DBHEAP 參數(shù)，日志緩沖區(qū)使用的空間是 DBHEAP 參數(shù)所定義的內(nèi)存空間的一部分。數(shù)據(jù)庫統(tǒng)計信息監(jiān)控概念數(shù)據(jù)庫的統(tǒng)計信息反映了表及其相關(guān)索引的物理特點。統(tǒng)計信息主要包含： 表信息：表的行數(shù)，使用的數(shù)據(jù)頁，溢出的行數(shù)，列的平均長度，列的更大最小值等。 索引信息：索引條目的數(shù)量，索引所關(guān)聯(lián)列的不同值的數(shù)量，索引的層數(shù)等。這些信息被數(shù)據(jù)庫查詢優(yōu)化器用來生成查詢計劃。好的訪問計劃對于 SQL 語句的快速執(zhí)行至關(guān)重要。我們需要想辦法保證統(tǒng)計信息準確地反映了當前數(shù)據(jù)庫的狀況。由于數(shù)據(jù)庫的表和索引總是隨著數(shù)據(jù)庫處理各種更新請求而不斷發(fā)生變化的，因此，總會出現(xiàn)統(tǒng)計信息過時，而不能正確反映數(shù)據(jù)庫數(shù)據(jù)現(xiàn)狀的情況。這時，數(shù)據(jù)庫查詢優(yōu)化器生成的查詢計劃可能不是更優(yōu)的，這將大大影響數(shù)據(jù)庫的查詢性能。我們應該經(jīng)常檢查數(shù)據(jù)庫的統(tǒng)計信息是否為最新的，并及時更新統(tǒng)計信息。SAP 系統(tǒng)為我們提供了監(jiān)控和執(zhí)行統(tǒng)計信息收集的方法。監(jiān)控我們進入 SAP 的 DBA Cockpit，然后在 Performance 的目錄下雙擊 Tables, 在 Table 列表中雙擊要監(jiān)控的表，在 Table 的標簽中，我們可以看到當前表的基本信息。這時，如果我們點擊 Count 按鈕，就會看到統(tǒng)計信息的質(zhì)量。圖9. 表的統(tǒng)計信息狀況從圖中我們看到，表的當前行數(shù)為 27，Deviation 為 8%。分析如果我們監(jiān)控到一個表的 Deviation 超過了 15%，我們就應該重新收集這個表的統(tǒng)計信息。在 SAP 中我們可以選擇手動收集統(tǒng)計信息。我們也可將系統(tǒng)配置成自動收集統(tǒng)計信息，這樣大大減少了系統(tǒng)手動維護的工作量。自動統(tǒng)計信息收集通常每隔 2 個小時觸發(fā)一次，它會自動選擇在 24 小時之內(nèi)沒有收集過統(tǒng)計信息的持久的基表。如果 SAP 系統(tǒng)進行 Client Copy 或在 BI 表中加載大量數(shù)據(jù)，由于這些操作在短時間就可以改變表的數(shù)據(jù)狀況及分布，因此會導致統(tǒng)計信息的過時。在 DB2 V9.5 中，為了解決這個問題，提供了一種 RTS (Real Time Statistics) 的特性，該特性可以允許在查詢被處理并優(yōu)化前對表的統(tǒng)計信息進行收集或采樣，如果優(yōu)化器認為重新收集統(tǒng)計信息比用過時的統(tǒng)計信息進行查詢的速度快，那么會在處理該查詢之前重新收集表的統(tǒng)計信息，從而達到實時收集統(tǒng)計信息的目的。我們一般需要將數(shù)據(jù)庫配置參數(shù) AUTO_STMT_STATS 設為 ON 來開啟 RTS 特性，但在 SAP 系統(tǒng)中，RTS 已經(jīng)是默認設置，我們無需進行任何改變?；仨撌捉Y(jié)束語本文從數(shù)據(jù)庫問題檢測的一般思路和方法論出發(fā)，介紹了如何通過 SAP 系統(tǒng)對 DB2 的性能進行監(jiān)控。
oracle性能檢測sql語句
監(jiān)控事例的等待
select event sum(decode(wait_Time )) Prev
sum(decode(wait_Time )) Curr count(*) Tot
from v$session_Wait
group by event order by ;
回滾段的爭用情況
select name waits gets waits/gets Ratio
from v$rollstat a v$rollname b
where a usn = b usn;
監(jiān)控表空間的 I/O 比例
select df tablespace_name name df file_name file f phyrds pyr
f phyblkrd pbr f phywrts pyw f phyblkwrt pbw
from v$filestat f dba_data_files df
where f file# = df file_id
order by df tablespace_name;
耐好 監(jiān)控文件系統(tǒng)的 I/O 比例
select substr(a file# ) # substr(a name ) Name
頃銀a status a bytes b phyrds b phywrts
from v$datafile a v$filestat b
where a file# = b file#;
在某個用戶下找所有的索引
select user_indexes table_name user_indexes index_name uniqueness column_name
from user_ind_columns user_indexes
where user_ind_columns index_name = user_indexes index_name
and user_ind_columns table_name = user_indexes table_name
order by user_indexes table_type user_indexes table_name
user_indexes index_name column_position;
監(jiān)控 SGA 的命中率
select a value + b value logical_reads c value phys_reads
round( * ((a value+b value) c value) / (a value+b value)) BUFFER HIT RATIO
from v$sysstat a v$sysstat b v$sysstat c
where a statistic# = and b statistic# =
and c statistic# = ;
監(jiān)控 SGA 中字典緩沖區(qū)的命中率
select parameter gets Getmisses getmisses/(gets+getmisses)* miss ratio
( (sum(getmisses)/ (sum(gets)+sum(getmisses))))* Hit ratio
from v$rowcache
where gets+getmisses
group by parameter gets getmisses;
監(jiān)控 SGA享雀畝宴緩存區(qū)的命中率 應該小于 %
select sum(pins) Total Pins sum(reloads) Total Reloads
sum(reloads)/sum(pins) * libcache
from v$librarycache;
select sum(pinhits reloads)/sum(pins) hit radio sum(reloads)/sum(pins) reload percent
from v$librarycache;
顯示所有數(shù)據(jù)庫對象的類別和大小
select count(name) num_instances type sum(source_size) source_size
sum(parsed_size) parsed_size sum(code_size) code_size sum(error_size) error_size
sum(source_size) +sum(parsed_size) +sum(code_size) +sum(error_size) size_required
from dba_object_size
group by type order by ;
監(jiān)控 SGA 中重做日志緩存區(qū)的命中率 應該小于 %
SELECT name gets misses immediate_gets immediate_misses
Decode(gets misses/gets* ) ratio
Decode(immediate_gets+immediate_misses
immediate_misses/(immediate_gets+immediate_misses)* ) ratio
FROM v$latch WHERE name IN ( redo allocation redo copy );
監(jiān)控內(nèi)存和硬盤的排序比率 更好使它小于 增加 sort_area_size
SELECT name value FROM v$sysstat WHERE name IN ( sorts (memory) sorts (disk) );
監(jiān)控當前數(shù)據(jù)庫誰在運行什么SQL語句
SELECT osuser username sql_text from v$session a v$sqltext b
where a sql_address =b address order by address piece;
監(jiān)控字典緩沖區(qū)
SELECT (SUM(PINS RELOADS)) / SUM(PINS) LIB CACHE FROM V$LIBRARYCACHE;
SELECT (SUM(GETS GETMISSES USAGE FIXED)) / SUM(GETS) ROW CACHE FROM V$ROWCACHE;
SELECT SUM(PINS) EXECUTIONS SUM(RELOADS) CACHE MISSES WHILE EXECUTING FROM V$LIBRARYCACHE;
后者除以前者 此比率小于 % 接近 %為好
SELECT SUM(GETS) DICTIONARY GETS SUM(GETMISSES) DICTIONARY CACHE GET MISSES
FROM V$ROWCACHE
找ORACLE字符集
select * from sys props$ where name= NLS_CHARACTERSET ;
監(jiān)控 MTS
select busy/(busy+idle) shared servers busy from v$dispatcher;
此值大于 時 參數(shù)需加大
select sum(wait)/sum(totalq) dispatcher waits from v$queue where type= dispatcher ;
select count(*) from v$dispatcher;
select servers_highwater from v$mts;
servers_highwater接近mts_max_servers時 參數(shù)需加大
碎片程度
select tablespace_name count(tablespace_name) from dba_free_space group by tablespace_name
having count(tablespace_name)> ;
alter tablespace name coalesce;
alter table name deallocate unused;
create or replace view ts_blocks_v as
select tablespace_name block_id bytes blocks free space segment_name from dba_free_space
union all
select tablespace_name block_id bytes blocks segment_name from dba_extents;
select * from ts_blocks_v;
select tablespace_name sum(bytes) max(bytes) count(block_id) from dba_free_space
group by tablespace_name;
查看碎片程度高的表
SELECT segment_name table_name COUNT(*) extents
FROM dba_segments WHERE owner NOT IN ( SYS SYSTEM ) GROUP BY segment_name
HAVING COUNT(*) = (SELECT MAX( COUNT(*) ) FROM dba_segments GROUP BY segment_name);
表 索引的存儲情況檢查
select segment_name sum(bytes) count(*) ext_quan from dba_extents where
tablespace_name= &tablespace_name and segment_type= TABLE group by tablespace_name segment_name;
select segment_name count(*) from dba_extents where segment_type= INDEX and owner= &owner
group by segment_name;
找使用CPU多的用戶session
是cpu used by this session
select a sid spid status substr(a program ) prog a terminal osuser value/ / value
from v$session a v$process b v$sesstat c
where c statistic#= and c sid=a sid and a paddr=b addr order by value desc;
lishixinzhi/Article/program/Oracle/202311/17800
數(shù)據(jù)庫實例命中率檢測的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫實例命中率檢測,如何提高數(shù)據(jù)庫實例命中率？,如何在 SAP 系統(tǒng)中監(jiān)控和分析 DB2 UDB 性能,oracle性能檢測sql語句的信息別忘了在本站進行查找喔。
成都網(wǎng)站營銷推廣找創(chuàng)新互聯(lián)，全國分站站群網(wǎng)站搭建更好做SEO營銷。
創(chuàng)新互聯(lián)（www.cdcxhl.com）四川成都IDC基礎服務商，價格厚道。提供成都服務器托管租用、綿陽服務器租用托管、重慶服務器托管租用、貴陽服務器機房服務器托管租用。
當前名稱：如何提高數(shù)據(jù)庫實例命中率？ (數(shù)據(jù)庫實例命中率檢測)
網(wǎng)址分享：http://www.5511xx.com/article/dhdsjej.html
