Ⅰ 通過jdbc執行sql比在plsql中慢好多
大哥,plsql是只檢索出前面的20條,即rownum<20 的數據,JDBC是查全部。你把PLSQL的數據全展開,你看看要多少秒!
Ⅱ 近期資料庫出現共享池鎖等待(latch: shared pool)
解決共享池latch爭用
避免unnecessary heaps
避免和減少由於共享sql statements帶來的碎片
避免_kghdsidx_count=1
避免flush shared pool
避免shared pool reserved free list碎片
Ⅲ SQL Server中所說的「臟頁」是什麼意思
SQL Server的工作原理:不能直接修改硬碟上的數據,而是先將數據從硬碟讀入到內存的data cache,然後在內存中修改(被修改過的頁稱為臟數據頁),最後再從內存回寫到硬碟。下述進程都可能將臟頁回寫到硬碟。
一、Checkpoint(檢查點)
Checkpoint會搜索整個data cache,將臟頁回寫到硬碟。
以下情況通常會觸發checkpoint:
1、運行Checkpoint 命令。
2、使用alter database往資料庫中添加了文件,或者從資料庫中刪除了文件。
3、備份資料庫。在資料庫備份之前,資料庫引擎會自動執行檢查點,以便在備份中包含對資料庫數據頁面的全部更改。
4、正常關閉SQL Server,並且不使用NOWAIT選項。
5、SQL Server預計的恢復時間超過了恢復間隔(recovery interval)。該值默認為0,即由SQL Server自動配置,一般為1分鍾。一般情況下,按最低每分鍾10MB日誌進行設計。
以下特殊情況也會觸發checkpoint:
1、當恢復模式為簡單時,如果日誌文件的空閑空間低於70%。例外的情況是:如果日誌文件是由於一個事務長時間執行而且尚未結束(意味著沒有空間可釋放)導致空閑空間低於70%,則不會觸發checkpoint。
2、當恢復模式為大容量日誌時,對資料庫做了一個大容量操作。
checkpoint對資料庫的影響:
1、當資料庫重啟時,SQL Server將從checkpoint 完成的這個時間點開始恢復,即在此之後做redo(前滾)。這種機制加速了恢復的進度。
2、當恢復模式為簡單時,checkpoint在把臟頁回寫到硬碟後,就去截斷日誌(將VLF的狀態從2改為0)。
二、Lazywriter(惰性編輯器)
SQL
Server為每一個NUMA(非一致性內存訪問)配備一個Lazywriter線程。Lazywriter被定期喚醒後,就去掃描與NUMA節點中的
data cache,檢查自由列表(free list)。如果列表的大小低於某個閥值(這個閥值取決於data
cache的總大小)意味著內存壓力,Lazywriter就去掃描data
cache,將其中一些頁標記到自由列表,表示這是空閑內存;如果這些頁中有臟頁,就回寫到硬碟。
當Lazywriter察覺到系統有內存壓力時,它會增加或減少自由列表上的數據頁,使操作系統的可用物理內存保持在4.8~5.2MB,以防止分頁。
Lazywriter自SQL Server 2005被引入。它與checkpoint的主要區別:checkpoint不會去修改自由列表。
這是一個周期運行的線程,默認情況下,每隔一秒鍾運行一次。
三、Worker Thread(工作線程)
SQL Server 啟動時,同時啟動30~40個工作線程,用於完成客戶端連接提出的各種操作請求。當客戶端連接增加時,SQL
Server會自動啟動新的工作線程。當某個工作線程空閑15分鍾,就會被關閉;當空閑內存不夠時,某些工作線程也會被關閉(x86環境)。在x86環
境,每個工作線程至少佔用0.5MB內存;在x64環境,每個工作線程至少佔用2MB內存。
當worker線程察覺內存壓力時,它會掃描data cache,把一段時間內未被訪問的數據頁添加到自由列表;如果這些頁中有臟頁,就回寫到硬碟。
Ⅳ 如何識別SQL Server中的IO瓶頸
當數據頁經常從緩沖池中移進移出的時候,I/O子系統就會成為SQLServer性能問題的關鍵因素之一。事務日誌和tempdb同樣也會產生重大
的I/O壓力。因此,你必須確保你的I/O子系統能按照預期運行。否則你將會成為響應時間增長和頻繁超時的受害者。在這篇文章中,將描述如何使用內置工具
識別I/O相關瓶頸,並提供一些磁碟配置的方法:
性能計數器(Performance Monitor):
可以使用性能計數器來檢查I/O子系統的負荷。下面的計數器可用於檢查磁碟性能:
PhysicalDisk Object:Avg.DiskQueue Length:計算從物理磁碟中胡頃的平均
讀和寫的請求隊列。過高的值代表磁碟操作處於等待狀態。當這個值在SQLServer峰值時長期超過2,證明需要注意了。如果有多個硬碟,就需要把這些數
值除以2。比如,有4個硬碟,且隊列為10,那麼平均值就是10/4=2.5,雖然也證明需要關注,但不能使用10這個值。
Avg.Disk Sec/Read和Avg.Disk Sec/Write:顯示從磁碟讀或者寫入磁碟的平均時間。10ms內是很好的表現,20以下還算能接受。高於此值證明存在問題。
Physical Disk:%Disk Time:在磁碟忙於讀漏咐或者寫請求的時候持續時間的比率。根據拇指定律,此值應該小於50%。
Disk Reads/Sec和Disk Writes/Sec計數器顯示出在磁碟中讀寫操作的速率。這兩個值應該小於磁碟能力的85%。當超過此值,磁碟的訪問時間將以指數方式增長。
可以通過以下方式來計算逐漸增長的負載的能力。一種方法是使用SQLIO。你應該找到吞吐量比較穩定,但緩慢增長。
可以使用以下公式來計算RAID配置:
Raid 0: I/O per disk = (reads + writes) / number ofdisks
Raid 1: I/O per disk = [reads + (writes*2)] / 2
Raid 5: I/O per disk = [reads + (writes*4)] / number of disks
Raid 10: I/褲搜陸O per disk = [reads + (writes*2)] / number of disks
比如:對於RAID 1,如果得到下面的計數器:
Disk Reads/sec = 90
Disk Writes/sec =75
根據公式:[reads + (writes*2)] / 2 or [90 + (75*2)] / 2 = 120I/Os每個磁碟。
動態管理視圖(DMVs):
有很多游泳的DMVs可以用於檢查I/O瓶頸:
當一個頁面被用於讀或者寫訪問且頁面在緩沖池中不存在或不可用時,會引發一個I/O閂鎖等待(I/O
latch),它會在PAGEIOLATCH_EX/PAGEIOLATCH_SH(具體根據請求類型而定)。這些等待表明一個I/O瓶頸。可以使用
sys.dm_os_wait_stats找到閂鎖等待的信息。如果你保存了SQLServer正常運行下的waiting_task_counts和
wait_time_ms值,並且於此次的值做對比,可以識別出I/O問題:
select *
from sys.dm_os_wait_stats
where wait_type like 'PAGEIOLATCH%'
order by wait_type asc
掛起的I/O請求可以在下面查詢中查到,並且用於識別那個磁碟負責的這個瓶頸:
select database_id,
file_id,
io_stall,
io_pending_ms_ticks,
scheler_address
from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,
sys.dm_io_pending_io_requests as iopior
where iovfs.file_handle = iopior.io_handle
磁碟碎片(Disk Fragmentation):
建議你檢查磁碟碎片和配置用於SQLServer實例的磁碟。在NTFS文件系統中的碎片會產生嚴重的性能影響。磁碟需要經常整理碎片並且指定整理碎片計劃。研究表明,一些情況下SAN在整理碎片後性能更差。因此,SAN必須根據實際情況對待。
NTFS上的索引碎片同樣能引起高I/O好用。但是這和在SANs中的效果是不一樣的。
磁碟配置/最佳實踐:
常規情況,你應該把日誌文件和數據文件分開存放以獲得更好的性能。對於重負載的數據文件(包括tempdb)的I/O特性是隨機讀取。對於日誌文件,是順序訪問的,除非事務需要回滾。
對於內置磁碟僅僅可以用於資料庫日誌文件,因為它們對順序I/O有很好的性能,但是對隨機I/O性能低下。
資料庫的數據和日誌文件應該放在對應專用的磁碟中。確保良好的性能。建議日誌文件放在兩個內置磁碟,並配置為RAID 1。數據文件駐留在僅用於給SQLServer訪問的SAN系統中,並只被查詢和報表控制。特殊訪問應該被禁止。
寫緩沖在可能的情況下應該被允許,並保證斷電也能使用。
為了盡可能保證對於OLTP系統的I/O瓶頸影響最小化,不應該把OLAP和OLTP環境混合。並且保證你的代碼優化及有合適的索引來避免不必要的I/O。
Ⅳ Sql語句解析過程
為了將用戶寫的SQL文本轉化為Oracle認識的且可執行的語句 這個過程就叫做解析過程 解析分為硬解析和軟解析 一條SQL語句在第一次被執行時必須進行硬解析
當客戶端發出一條SQL語句(也可以是一個存儲過程或者一個匿名PL/SQL塊)進入shared pool時(注意 我們從前面已經知道 Oracle對這些SQL不叫做SQL語句 而是稱為游標 因為Oracle在處理SQL時 需要很多相關的輔助信息 這些輔助信息與SQL語句一起組成了游標) Oracle首先將SQL文本轉化為ASCII值 然後根據hash函數計算其對應的hash值(hash_value) 根據計算出的hash值到library cache中找到對應的bucket 然後比較bucket里是否存在該SQL語句
如果不存在 則需要按照我們前面所描述的 獲得shared pool latch 然後在shared pool中的可用chunk鏈表(也就是bucket)上找到一個可用的chunk 之後釋放shared pool latch 在獲得了chunk以後 這塊chunk就可以認為是進入了library cache 接下來 進行硬解析過程 硬解析包括以下幾個步驟
對SQL語句進行文法檢查 看是否有文法錯誤 比如沒有寫from select拼寫錯誤等 如果存在文法錯誤 則退出解析過程
到數據字典里校驗SQL語句涉及的對象和列是否都存在 如果不存在 則退出解析過程 這個過程會載入dictionary cache
將對象進行名稱轉換 比如將同名詞翻譯成實際的對象等 比如select * from t中 t是一個同名詞 指向hr t 於是Oracle將t轉換為hr t 如果轉換失敗 則退出解析過程
檢查發出SQL語句的用戶是否具有訪問SQL語句里所引用的對象的許可權 如果沒有許可權 則退出解析過程
通過優化器創建一個最優的執行計劃 這個過程會根據數據字典里記錄的對象的統計信息 來計算最優的執行計劃 這一步牽涉大量數學運算 是最消耗CPU資源的
將該游標所產生的執行計劃 SQL文本等裝載進library cache的heap中
在硬解析的過程中 進程會一直持有library cache latch 直到硬解析結束為止 硬解析結束以後 會為SQL語句產生兩個游標 一個是父游標 另一個是子游標 父游標里主要包含兩種信息 SQL文本以及優化目標(optimizer goal) 父游標在第一次打開時被鎖定 直到其他所有的session都關閉該游標後才被解鎖 當父游標被鎖定的時候是不能被交換出library cache的 只有在解鎖以後才能被交換出library cache 父游標被交換出內存時 父游標對應的所有子游標也被交換出library cache 子游標包括游標所有的信息 比如具體的執行計劃 綁定變數等 子游標隨時可以被交換出library cache 當子游標被交換出library cache時 Oracle可以利用父游標的信息重新構建出一個子游標來 這個過程叫reload 可以使用下面的方式來確定reload的比率
select *sum(reloads)/sum(pins) Reload_Ratio from v$librarycache;
一個父游標可以對應多個子游標 子游標具體的個數可以從視圖v$sqlarea的version_count欄位體現出來 而每個具體的子游標則全都在視圖v$sql里體現 當具體綁定變數的值與上次綁定變數的值有較大差異(比如上次執行的綁定變數值的長度是 位 而這次執行綁定變數的值的長度是 位)時或者當SQL語句完全相同 但是所引用的表屬於不同的用戶時 都會創建一個新的子游標
如果在bucket中找到了該SQL語句 則說明該SQL語句以前運行過 於是進行軟解析 軟解析是相對於硬解析而言的 如果解析過程中 可以從硬解析的步驟中去掉一個或多個的話 這樣的解析就是軟解析 軟解析分為以下三種類型
第一種是某個session發出的SQL語句與library? cache里其他session發出的SQL語句一致 這時 該解析過程中可以去掉硬解析中的 和 但是仍然要進行硬解析過程中的 也就是表名和列名檢查 名稱轉換和許可權檢查
* 第二種是某個session發出的SQL語句是該session之前發出的曾經執行過的SQL語句 這時 該解析過程中可以去掉硬解析中的 和 這四步 但是仍然要進行許可權檢查 因為可能通過grant改變了該session用戶的許可權
* 第三種是當設置了初始化參數session_cached_cursors時 當某個session第三次執行相同的SQL時 則會把該SQL語句的游標信息轉移到該session的PGA里 這樣 該session以後再執行相同的SQL語句時 會直接從PGA里取出執行計劃 從而跳過硬解析的所有步驟 這種情況下 是最高效的解析方式 但是會消耗很大的內存
我們舉一個例子來說明解析SQL語句的過程 在該測試中 綁定變數名稱相同 但是變數類型不同時 所出現的解析情況 如下所示
首先 執行下面的命令 清空shared pool里所有的SQL語句
SQL> alter system flush shared_pool;
然後 定義一個數值型綁定變數 並為該綁定變數賦一個數值型的值以後 執行具體的查詢語句
SQL> variable v_obj_id number;
SQL> exec :v_obj_id := ;
SQL> select object_id object_name from sharedpool_test
where object_id=:v_obj_id;
OBJECT_ID OBJECT_NAME
AGGXMLIMP
接下來 定義一個字元型的綁定變數 變數名與前面相同 為該綁定變數賦一個字元型的值以後 執行相同的查詢
SQL> variable v_obj_id varchar ( );
SQL> exec :v_obj_id := ;
SQL> select object_id object_name from sharedpool_test
where object_id=:v_obj_id;
OBJECT_ID OBJECT_NAME
AGGXMLIMP
然後我們到視圖v$sqlarea里找到該SQL的父游標的信息 並到視圖v$sql里找該SQL的所有子游標的信息
SQL> select sql_text version_count from v$sqlarea where
sql_text like %sharedpool_test% ;
SQL_TEXT
VERSION_COUNT
select object_id object_name from sharedpool_test where
object_id=:v_obj_id
SQL> select sql_text child_address address from v$sql
where sql_text like %sharedpool_test% ;
SQL_TEXT
CHILD_ADDRESS ADDRESS
select object_id object_name from sharedpool_test where
object_id=:v_obj_id F
B D
select object_id object_name from sharedpool_test where
object_id=:v_obj_id FC
B D
從記錄父游標的視圖v$sqlarea的version_count列可以看到 該SQL語句有 個子游標 而從記錄子游標的視圖v$sql里可以看到 該SQL文本確實有兩條記錄 而且它們的SQL文本所處的地址(ADDRESS列)也是一樣的 但是子地址(CHILD_ADDRESS)卻不一樣 這里的子地址實際就是子游標所對應的heap 的句柄
lishixin/Article/program/Oracle/201311/18653
Ⅵ 什麼是latch以及如何導致latch爭用
產生:在data buffer 有block 被access的時候產生; 解決: 減少這個latch 競爭就是要減少sql 的邏輯IOCache buffers LRU chain latch:
產生: 1、當一個新的block 被讀到data buffer 的時候 2、data 從databuffer 寫到disk 3、對Data buffer 進行scan 以獲逗搜桐得那些block是dirty 時候; 解決: 1、加大data buffer,但是這對於FTS 比較多的系統並不中用 2、設置Multiple buffer pools 3、加大DB_BLOCK_LRU_LATCHES 參數的值 4、always ensure DB_BLOCK_LRU_STATISTICS is set to FALSE
Redo allocation latch:
產生:在log buffer中分配空間的時候獲得,一個instance 只有一個Redo allocation latch; 解決:1、加大log buffer 2、設置 nologging 選項
Redo latch:
產生:當系統將redo records 寫到log buffer 的時候產生;
Library cache latch:
產生:The library cache latches 保護cached 的sql 語句,以及cached 的object 的定義,它是當將新的解析的sql 語句 插入到library cache 的時候產生,該值過大,表示hard parse 過多;山坦 解決: 1、綁定變數 2、適當加大shared pool 3、加大_KGL_LATCH_COUNT 參數
Library cache pin latch:
產生: 當cached sql 語句漏高再次被執行的時候產生,這個latch 的嚴重丟失表明sql 被嚴重的多次執行; 解決: 幾乎沒有辦法來解決該問題,一個效果不大的辦法是書寫:a.b 類似的sql
Ⅶ pl sql 工具中Compile Invalied Objects是什麼用處
這個是有關原理的東西;
在shared pool的脊世庫緩存中,有櫻顫肢latch,latch有種類型叫null
對於每句sql或plsql語句所涉及的object,該latch都會有個latch null在該對象洞敬上,一旦,該對象發生變化了,該latch null,就會消失,如果,你的plsql語句中執行時,發現該latch不在了,說明涉及的對象已經改變,需要重新compile。
Ⅷ 如何判斷MSSQL資料庫磁碟出現了瓶頸
具體問題具體分析,舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態,而是急劇下降。為什麼資料庫的性能有非常明顯的分界點,原因是什麼?
相信大部分做資料庫運維的朋友,都遇到這種情況。 資料庫在前一天性能表現的相當穩定,資料庫的響應時間也很正常,但就在今天,在業務人員反饋業務流量沒有任何上升的情況下,資料庫的變得不穩定了,有時候一個最簡單的insert操作, 需要幾十秒,但99%的insert卻又可以在幾毫秒完成,這又是為什麼了?
dba此時心中有無限的疑惑,到底是什麼原因呢? 磁碟IO性能變差了?還是業務運維人員反饋的流量壓根就不對? 還是資料庫內部出問題?昨天不是還好好的嗎?
當資料庫出現響應時間不穩定的時候,我們在操作系統上會看到磁碟的利用率會比較高,如果觀察仔細一點,還可以看到,存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的,但只要存在少量的讀IO,則性能開始出現抖動,存在大量的讀IO時(排除配備非常高速磁碟的機器),對於在線交易的資料庫系統來說,大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢?
如果親之前沒有注意到上述的現象,親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前,作者閱讀了大量跟的IO相關的代碼,如非同步IO線程的相關的,innodb_buffer池相關的,以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點,看起來不那麼累,因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁,可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦?
回答:去讀文件,將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數,作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數,我們知道其實通過首先自旋加鎖pin的方式,超過設定的自旋次數之後,進入等待,等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題: 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後,他需要修改這個頁,而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程,即使在數據頁1001被入讀buffer pool之後,將仍然處於等待中。因為在數據頁上讀取或者更新的時候,同樣需要上鎖,這樣才能保證數據頁並發讀取/更新的一致性。
由此可見,當一個高並發的系統,出現了熱點數據頁需要從磁碟上載入到buffer pool中時,造成的延遲,是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁,響應時間也就越長,這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題,mysql資料庫出現性能下降時,可以看到操作系統有讀IO。 原因是,在資料庫對數據頁的更改,是在內存中的,然後通過檢查點線程進行非同步寫盤,這個非同步的寫操作是不堵塞執行sql的會話線程的。所以,即使看到操作系統上有大量的寫IO,資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時,則會從磁碟上讀取,在一個熱點數據頁不是非常多的情況下,我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁,因此一般都不會出現缺頁的情況,也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時,原因時在執行buf_read_page_low函數,從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降,當出現大量的讀IO,資料庫的性能會非常差。
Ⅸ mysql中innodb引擎的行鎖是通過加在什麼上完成
行鎖的等待
在介紹如何解決行鎖等待問題前,先簡單介紹下這類問題產生的原因。產生原因簡述:當多個事務同時去操作(增刪改)某一行數據的時候,MySQL 為了維護 ACID 特性,就會用鎖的形式來防止多個事務同時操作某一行數據,避免數據不一致。只有分配到行鎖的事務才有權力操作該數據行,直到該事務結束,才釋放行鎖,而其他沒有分配到行鎖的事務就會產生行鎖等待。如果等待時間超過了配置值(也就是 innodb_lock_wait_timeout 參數的值,個人習慣配置成 5s,MySQL 官方默認為 50s),則會拋出行鎖等待超時錯誤。
如上圖所示,事務 A 與事務 B 同時會去 Insert 一條主鍵值為 1 的數據,由於事務 A 首先獲取了主鍵值為 1 的行鎖,導致事務 B 因無法獲取行鎖而產生等待,等到事務 A 提交後,事務 B 才獲取該行鎖,完成提交。這里強調的是行鎖的概念,雖然事務 B 重復插入了主鍵,但是在獲取行鎖之前,事務一直是處於行鎖等待的狀態,只有獲取行鎖後,才會報主鍵沖突的錯誤。當然這種 Insert 行鎖沖突的問題比較少見,只有在大量並發插入場景下才會出現,項目上真正常見的是 update&delete 之間行鎖等待,這里只是用於示例,原理都是相同的。
根據我之前接觸到的此類問題,大致可以分為以下幾種原因:
1. 程序中非資料庫交互操作導致事務掛起將介面調用或者文件操作等這一類非資料庫交互操作嵌入在 SQL 事務代碼之中,那麼整個事務很有可能因此掛起(介面不通等待超時或是上傳下載大附件)。
2. 事務中包含性能較差的查詢 SQL事務中存在慢查詢,導致同一個事務中的其他 DML 無法及時釋放佔用的行鎖,引起行鎖等待。
3. 單個事務中包含大量 SQL通常是由於在事務代碼中加入 for 循環導致,雖然單個 SQL 運行很快,但是 SQL 數量一大,事務就會很慢。
4. 級聯更新 SQL 執行時間較久這類 SQL 容易讓人產生錯覺,例如:update A set ... where ...in (select B) 這類級聯更新,不僅會佔用 A 表上的行鎖,也會佔用 B 表上的行鎖,當 SQL 執行較久時,很容易引起 B 表上的行鎖等待。
5. 磁碟問題導致的事務掛起極少出現的情形,比如存儲突然離線,SQL 執行會卡在內核調用磁碟的步驟上,一直等待,事務無法提交。綜上可以看出,如果事務長時間未提交,且事務中包含了 DML 操作,那麼就有可能產生行鎖等待,引起報錯。
Ⅹ 如何降低資料庫的latch
1、1、調整數據結構的設計。這一部分在開發信息系統之前完成,程序員需要考慮是否使用ORACLE資料庫的分區功能,對於經常訪問的資料庫表是否需要建立索引等。
2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成,程序員在這一步需要考慮應用程序使用什麼樣的體系結構,是使用傳統的Client/Server兩層體系結構,還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行,因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器(Oracle Optimizer)歷運和行鎖管理器(row-level manager)來調整優化SQL語句。
4、4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的,資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區(SGA區)的數據緩沖區、日誌緩沖區和共享池的大小;還可以調整程序全局區(PGA區)的大小。需要注意的是,SGA區不是越大越好,SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換,這樣反而會降低系統。
5、5、調整硬碟I/O,這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上,做到硬碟之間I/O負載均衡。
6、6、調整操作系統參數,例如:運行在UNIX操作系統上的ORACLE資料庫,可以調整UNIX數據緩沖池的大小,每個進程所能使用的內存大小等參數。
實際上,上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化數爛扮表現薯灶基本上都是用戶響應時間比較長,需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的,有時是多個因素共同造成了性能惡化的結果,這就需要資料庫管理員有比較全面的計算機知識,能夠敏感地察覺到影響資料庫性能的主要原因所在。另外,良好的資料庫管理工具對於優化資料庫性能也是很重要的。
ORACLE資料庫性能優化工具