oracle怎么看速度,oracle查詢速度提高方法

oracle查詢數(shù)據(jù)速度慢，已建索引的。求助

方法如下：

目前創(chuàng)新互聯(lián)公司已為成百上千的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站托管維護、企業(yè)網(wǎng)站設(shè)計、杜爾伯特網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

Oracle中建立索引，會提高查詢速度： create index 索引名 on 表名(列名);

例如：

create index index_userid on tbl_detail(userid);

如何找數(shù)據(jù)庫表的主鍵字段的名稱?

SELECT * FROM user_constraints WHERE CONSTRAINT_TYPE='P' and table_name='AAA'; select * from dba_cons_columns where CONSTRAINT_NAME='SYS_AAA';

Oracle 在創(chuàng)建主鍵（可以不加constraint SYS_AAA），會為庫表自動創(chuàng)建索引，

索引的列為主鍵列。 并且當(dāng)庫表某些列名或者庫表名改變時候，

Oracle自動創(chuàng)建的索引SYS_AAA,中的索引列也會自動更新（類似于視圖），并且SYS_AAA會與名字更改后的庫表還是保持索引關(guān)系。 關(guān)鍵系統(tǒng)庫表： desc dba_constraints desc dba_cons_columns

desc dba_indexes desc dba_ind_columns desc DBA_TAB_COLUMNS

例子1：更改庫表的列名

ALTER TABLE AAA RENAME COLUMN ID TO AAA_ID; create table AAA ( ID NUMBER(8), NAME CHAR(20),

constraint SYS_AAA primary key(ID) );

//查找約束名字

select c.CONSTRAINT_NAME,c.table_name,cc.COLUMN_NAME from user_constraints c, user_cons_columns cc

where c.constraint_name=cc.constraint_name and c.table_name ='AAA' AND C.CONSTRAINT_TYPE='P';

CONSTRAINT_NAME TABLE_NAME COLUMN_NAME ------------------------------ ------------ ------------- SYS_AAA AAA ID

//查找索引

select index_name,index_type,uniqueness from user_indexes where table_name='AAA'; INDEX_NAME INDEX_TYPE UNIQUENES

oracle中關(guān)于查詢速度

不會的，查詢view相當(dāng)于重新執(zhí)行創(chuàng)建view的語句，和直接拿語句查詢沒有區(qū)別的。兩者沒有任何差別。

如果你每次查詢的結(jié)果，只占整張表的1％－5％左右（這個沒有準(zhǔn)確的說法，完全是根據(jù)經(jīng)驗），那么你可以在你使用的條件字段上創(chuàng)建索引。如果大于這個比例，那么還是不要建索引全表掃描吧，建了索引反而會更慢。

如果你用的是oracle 10g，你可以建索引在上面先，如果效率沒提高就把索引刪掉。

如何分析為什么oracle速度慢

Oracle查詢速度慢的原因總結(jié)

查詢速度慢的原因很多,常見如下幾種:

1,沒有索引或者沒有用到索引(這是查詢慢最常見的問題,是程序設(shè)計的缺陷)

2,I/O吞吐量小,形成了瓶頸效應(yīng).

3,沒有創(chuàng)建計算列導(dǎo)致查詢不優(yōu)化.

4,內(nèi)存不足

5,網(wǎng)絡(luò)速度慢

6,查詢出的數(shù)據(jù)量過大(可以采用多次查詢,其他的方法降低數(shù)據(jù)量)

7,鎖或者死鎖(這也是查詢慢最常見的問題,是程序設(shè)計的缺陷)

8,sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源.

9,返回了不必要的行和列

10,查詢語句不好,沒有優(yōu)化

可以通過如下方法來優(yōu)化查詢 :

1,把數(shù)據(jù),日志,索引放到不同的I/O設(shè)備上,增加讀取速度,以前可以將Tempdb應(yīng)放在RAID0上,SQL2000不在支持.數(shù)據(jù)量(尺寸)越大,提高I/O越重要.

2,縱向,橫向分割表,減少表的尺寸(sp_spaceuse)

3,升級硬件

4,根據(jù)查詢條件,建立索引,優(yōu)化索引,優(yōu)化訪問方式,限制結(jié)果集的數(shù)據(jù)量.注意填充因子要適當(dāng)(最好是使用默認值0).索引應(yīng)該盡量小,使用字節(jié)數(shù)小的列建索引好(參照索引的創(chuàng)建),不要對有限的幾個值的字段建單一索引如性別字段

5,提高網(wǎng)速;

6,擴大服務(wù)器的內(nèi)存,Windows 2000和SQL server 2000能支持4-8G的內(nèi)存.配置虛擬內(nèi)存:虛擬內(nèi)存大小應(yīng)基于計算機上并發(fā)運行的服務(wù)進行配置.運行 Microsoft SQL Server? 2000 時,可考慮將虛擬內(nèi)存大小設(shè)置為計算機中安裝的物理內(nèi)存的 1.5 倍.如果另外安裝了全文檢索功能,并打算運行 Microsoft 搜索服務(wù)以便執(zhí)行全文索引和查詢,可考慮:將虛擬內(nèi)存大小配置為至少是計算機中安裝的物理內(nèi)存的 3 倍.將 SQL Server max server memory 服務(wù)器配置選項配置為物理內(nèi)存的 1.5 倍(虛擬內(nèi)存大小設(shè)置的一半).

7,增加服務(wù)器 CPU個數(shù);但是必須明白并行處理串行處理更需要資源例如內(nèi)存.使用并行還是串行程是MsSQL自動評估選擇的.單個任務(wù)分解成多個任務(wù),就可以在處理器上運行.例如耽擱查詢的排序,連接,掃描和GROUP BY字句同時執(zhí)行,SQL SERVER根據(jù)系統(tǒng)的負載情況決定最優(yōu)的并行等級,復(fù)雜的需要消耗大量的CPU的查詢最適合并行處理.但是更新操作Update,Insert, Delete還不能并行處理.

8,如果是使用like進行查詢的話,簡單的使用index是不行的,但是全文索引,耗空間. like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時,查詢耗時和字段值總長度成正比,所以不能用CHAR類型,而是VARCHAR.對于字段的值很長的建全文索引.

9,DB Server 和APPLication Server 分離;OLTP和OLAP分離

10,分布式分區(qū)視圖可用于實現(xiàn)數(shù)據(jù)庫服務(wù)器聯(lián)合體.聯(lián)合體是一組分開管理的服務(wù)器,但它們相互協(xié)作分擔(dān)系統(tǒng)的處理負荷.這種通過分區(qū)數(shù)據(jù)形成數(shù)據(jù)庫服務(wù)器聯(lián)合體的機制能夠擴大一組服務(wù)器,以支持大型的多層 Web 站點的處理需要.有關(guān)更多信息,參見設(shè)計聯(lián)合數(shù)據(jù)庫服務(wù)器.(參照SQL幫助文件'分區(qū)視圖')

a,在實現(xiàn)分區(qū)視圖之前,必須先水平分區(qū)表

b,在創(chuàng)建成員表后,在每個成員服務(wù)器上定義一個分布式分區(qū)視圖,并且每個視圖具有相同的名稱.這樣,引用分布式分區(qū)視圖名的查詢可以在任何一個成員服務(wù)器上運行.系統(tǒng)操作如同每個成員服務(wù)器上都有一個原始表的復(fù)本一樣,但其實每個服務(wù)器上只有一個成員表和一個分布式分區(qū)視圖.數(shù)據(jù)的位置對應(yīng)用程序是透明的.

11,重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數(shù)據(jù)和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設(shè)置自動收縮日志.對于大的數(shù)據(jù)庫不要設(shè)置數(shù)據(jù)庫自動增長,它會降低服務(wù)器的性能.在T-sql的寫法上有很大的講究,下面列出常見的要點:首先, DBMS處理查詢計劃的過程是這樣的:

1, 查詢語句的詞法,語法檢查

2, 將語句提交給DBMS的查詢優(yōu)化器

3, 優(yōu)化器做代數(shù)優(yōu)化和存取路徑的優(yōu)化

4, 由預(yù)編譯模塊生成查詢規(guī)劃

5, 然后在合適的時間提交給系統(tǒng)處理執(zhí)行

6, 最后將執(zhí)行結(jié)果返回給用戶其次,看一下SQL SERVER的數(shù)據(jù)存放的結(jié)構(gòu):一個頁面的大小為8K(8060)字節(jié),8個頁面為一個盤區(qū),按照B樹存放.

12,Commit和rollback的區(qū)別 Rollback:回滾所有的事物. Commit:提交當(dāng)前的事物. 沒有必要在動態(tài)SQL里寫事物,如果要寫請寫在外面如: begin tran exec(@s) commit trans 或者將動態(tài)SQL 寫成函數(shù)或者存儲過程.

13,在查詢Select語句中用Where字句限制返回的行數(shù),避免表掃描,如果返回不必要的數(shù)據(jù),浪費了服務(wù)器的I/O資源,加重了網(wǎng)絡(luò)的負擔(dān)降低性能.如果表很大,在表掃描的期間將表鎖住,禁止其他的聯(lián)接訪問表,后果嚴重.

14,SQL的注釋申明對執(zhí)行沒有任何影響15,盡可能不使用光標(biāo),它占用大量的資源.如果需要row-by-row地執(zhí)行,盡量采用非光標(biāo)技術(shù),如:在客戶端循環(huán),用臨時表,Table變量,用子查詢,用Case語句等等.游標(biāo)可以按照它所支持的提取選項進行分類: 只進 必須按照從第一行到最后一行的順序提取行.FETCH NEXT 是唯一允許的提取操作,也是默認方式.可滾動性可以在游標(biāo)中任何地方隨機提取任意行.游標(biāo)的技術(shù)在SQL2000下變得功能很強大,他的目的是支持循環(huán).有四個并發(fā)選項 READ_ONLY:不允許通過游標(biāo)定位更新(Update),且在組成結(jié)果集的行中沒有鎖. OPTIMISTIC WITH valueS:樂觀并發(fā)控制是事務(wù)控制理論的一個標(biāo)準(zhǔn)部分.樂觀并發(fā)控制用于這樣的情形,即在打開游標(biāo)及更新行的間隔中,只有很小的機會讓第二個用戶更新某一行.當(dāng)某個游標(biāo)以此選項打開時,沒有鎖控制其中的行,這將有助于最大化其處理能力.如果用戶試圖修改某一行,則此行的當(dāng)前值會與最后一次提取此行時獲取的值進行比較.如果任何值發(fā)生改變,則服務(wù)器就會知道其他人已更新了此行,并會返回一個錯誤.如果值是一樣的,服務(wù)器就執(zhí)行修改.選擇這個并發(fā)選項OPTIMISTIC WITH ROW VERSIONING:此樂觀并發(fā)控制選項基于行版本控制.使用行版本控制,其中的表必須具有某種版本標(biāo)識符,服務(wù)器可用它來確定該行在讀入游標(biāo)后是否有所更改.在 SQL Server 中,這個性能由 timestamp 數(shù)據(jù)類型提供,它是一個二進制數(shù)字,表示數(shù)據(jù)庫中更改的相對順序.每個數(shù)據(jù)庫都有一個全局當(dāng)前時間戳值:@@DBTS.每次以任何方式更改帶有 timestamp 列的行時,SQL Server 先在時間戳列中存儲當(dāng)前的 @@DBTS 值,然后增加 @@DBTS 的值.如果某 個表具有 timestamp 列,則時間戳?xí)挥浀叫屑?服務(wù)器就可以比較某行的當(dāng)前時間戳值和上次提取時所存儲的時間戳值,從而確定該行是否已更新.服務(wù)器不必比較所有列的值,只需比較 timestamp 列即可.如果應(yīng)用程序?qū)]有 timestamp 列的表要求基于行版本控制的樂觀并發(fā),則游標(biāo)默認為基于數(shù)值的樂觀并發(fā)控制. SCROLL LOCKS 這個選項實現(xiàn)悲觀并發(fā)控制.在悲觀并發(fā)控制中,在把數(shù)據(jù)庫的行讀入游標(biāo)結(jié)果集時,應(yīng)用程序?qū)⒃噲D鎖定數(shù)據(jù)庫行.在使用服務(wù)器游標(biāo)時,將行讀入游標(biāo)時會在其上放置一個更新鎖.如果在事務(wù)內(nèi)打開游標(biāo),則該事務(wù)更新鎖將一直保持到事務(wù)被提交或回滾;當(dāng)提取下一行時,將除去游標(biāo)鎖.如果在事務(wù)外打開游標(biāo),則提取下一行時,鎖就被丟棄.因此,每當(dāng)用戶需要完全的悲觀并發(fā)控制時,游標(biāo)都應(yīng)在事務(wù)內(nèi)打開.更新鎖將阻止任何其它任務(wù)獲取更新鎖或排它鎖,從而阻止其它任務(wù)更新該行.然而,更新鎖并不阻止共享鎖,所以它不會阻止其它任務(wù)讀取行,除非第二個任務(wù)也在要求帶更新鎖的讀取.滾動鎖根據(jù)在游標(biāo)定義的 Select 語句中指定的鎖提示,這些游標(biāo)并發(fā)選項可以生成滾動鎖.滾動鎖在提取時在每行上獲取,并保持到下次提取或者游標(biāo)關(guān)閉,以先發(fā)生者為準(zhǔn).下次提取時,服務(wù)器為新提取中的行獲取滾動鎖,并釋放上次提取中行的滾動鎖.滾動鎖獨立于事務(wù)鎖,并可以保持到一個提交或回滾操作之后.如果提交時關(guān)閉游標(biāo)的選項為關(guān),則 COMMIT 語句并不關(guān)閉任何打開的游標(biāo),而且滾動鎖被保留到提交之后,以維護對所提取數(shù)據(jù)的隔離.所獲取滾動鎖的類型取決于游標(biāo)并發(fā)選項和游標(biāo) Select 語句中的鎖提示.鎖提示 只讀 樂觀數(shù)值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定未鎖定未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定未鎖定更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標(biāo)內(nèi)是只讀的.

16,用Profiler來跟蹤查詢,得到查詢所需的時間,找出SQL的問題所在;用索引優(yōu)化器優(yōu)化索引

17,注意UNion和UNion all 的區(qū)別.UNION all好

18,注意使用DISTINCT,在沒有必要時不要用,它同UNION一樣會使查詢變慢.重復(fù)的記錄在查詢里是沒有問題的

19,查詢時不要返回不需要的行,列

20,用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源.當(dāng)評估查詢消耗的資源超出限制時,服務(wù)器自動取消查詢,在查詢之前就扼殺掉. SET LOCKTIME設(shè)置鎖的時間.

21,用select top 100 / 10 Percent 來限制用戶返回的行數(shù)或者SET ROWCOUNT來限制操作的行

22,在SQL2000以前,一般不要用如下的字句: "IS NULL", "", "!=", "!", "!", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'",因為他們不走索引全是表掃描.也不要在Where字句中的列名加函數(shù),如Convert,substring等,如果必須用函數(shù)的時候,創(chuàng)建計算列再創(chuàng)建索引來替代.還可以變通寫法:Where SUBSTRING(firstname,1,1) = 'm'改為Where firstname like 'm%'(索引掃描),一定要將函數(shù)和列名分開.并且索引不能建得太多和太大.NOT IN會多次掃描表,使用EXISTS,NOT EXISTS ,IN , LEFT OUTER JOIN 來替代,特別是左連接,而Exists比IN更快,最慢的是NOT操作.如果列的值含有空,以前它的索引不起作用,現(xiàn)在2000的優(yōu)化器能夠處理了.相同的是IS NULL,"NOT", "NOT EXISTS", "NOT IN"能優(yōu)化她,而""等還是不能優(yōu)化,用不到索引.

23,使用Query Analyzer,查看SQL語句的查詢計劃和評估分析是否是優(yōu)化的SQL.一般的20%的代碼占據(jù)了80%的資源,我們優(yōu)化的重點是這些慢的地方.

24,如果使用了IN或者OR等時發(fā)現(xiàn)查詢沒有走索引,使用顯示申明指定索引: Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男','女')

25,將需要查詢的結(jié)果預(yù)先計算好放在表中,查詢的時候再Select.這在SQL7.0以前是最重要的手段.例如醫(yī)院的住院費計算.

26,MIN() 和 MAX()能使用到合適的索引.

27,數(shù)據(jù)庫有一個原則是代碼離數(shù)據(jù)越近越好,所以優(yōu)先選擇Default,依次為Rules,Triggers, Constraint(約束如外健主健CheckUNIQUE……,數(shù)據(jù)類型的最大長度等等都是約束),Procedure.這樣不僅維護工作小,編寫程序質(zhì)量高,并且執(zhí)行的速度快.

28,如果要插入大的二進制值到Image列,使用存儲過程,千萬不要用內(nèi)嵌Insert來插入 (不知JAVA是否).因為這樣應(yīng)用程序首先將二進制值轉(zhuǎn)換成字符串(尺寸是它的兩倍),服務(wù)器受到字符后又將他轉(zhuǎn)換成二進制值.存儲過程就沒有這些動作: 方法:Create procedure p_insert as insert into table(Fimage) values (@image), 在前臺調(diào)用這個存儲過程傳入二進制參數(shù),這樣處理速度明顯改善.

29,Between在某些時候比IN 速度更快,Between能夠更快地根據(jù)索引找到范圍.用查詢優(yōu)化器可見到差別. select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一樣的.由于in會在比較多次,所以有時會慢些.

30,在必要是對全局或者局部臨時表創(chuàng)建索引,有時能夠提高速度,但不是一定會這樣,因為索引也耗費大量的資源.他的創(chuàng)建同是實際表一樣.

31,不要建沒有作用的事物例如產(chǎn)生報表時,浪費資源.只有在必要使用事物時使用它.

32,用OR的字句可以分解成多個查詢,并且通過UNION 連接多個查詢.他們的速度只同是否使用索引有關(guān),如果查詢需要用到聯(lián)合索引,用UNION all執(zhí)行的效率更高.多個OR的字句沒有用到索引,改寫成UNION的形式再試圖與索引匹配.一個關(guān)鍵的問題是否用到索引.

33,盡量少用視圖,它的效率低.對視圖操作比直接對表操作慢,可以用stored procedure來代替她.特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度.我們看視圖的本質(zhì):它是存放在服務(wù)器上的被優(yōu)化好了的已經(jīng)產(chǎn)生了查詢規(guī)劃的SQL.對單個表檢索數(shù)據(jù)時,不要使用指向多個表的視圖,直接從表檢索或者僅僅包含這個表的視圖上讀,否則增加了不必要的開銷,查詢受到干擾.為了加快視圖的查詢,MsSQL增加了視圖索引的功能.

34,沒有必要時不要用DISTINCT和ORDER BY,這些動作可以改在客戶端執(zhí)行.它們增加了額外的開銷.這同UNION 和UNION ALL一樣的道理.

select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345','JCNAD00333138','JCNAD00303570','JCNAD00303569','JCNAD00303568','JCNAD00306698',

'JCNAD00231935','JCNAD00231933','JCNAD00254567','JCNAD00254585','JCNAD00254608','JCNAD00254607','JCNAD00258524',

'JCNAD00332133','JCNAD00268618','JCNAD00279196','JCNAD00268613') order by postdate desc

35,在IN后面值的列表中,將出現(xiàn)最頻繁的值放在最前面,出現(xiàn)得最少的放在最后面,減少判斷的次數(shù).

36,當(dāng)用Select INTO時,它會鎖住系統(tǒng)表(sysobjects,sysindexes等等),阻塞其他的連接的存取.創(chuàng)建臨時表時用顯示申明語句,而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where ——commit 在另一個連接中Select * from sysobjects可以看到 Select INTO 會鎖住系統(tǒng)表,Create table 也會鎖系統(tǒng)表(不管是臨時表還是系統(tǒng)表).所以千萬不要在事物內(nèi)使用它!!!這樣的話如果是經(jīng)常要用的臨時表請使用實表,或者臨時表變量.

37,一般在GROUP BY 個HAVING字句之前就能剔除多余的行,所以盡量不要用它們來做剔除行的工作.他們的執(zhí)行順序應(yīng)該如下最優(yōu):select 的Where字句選擇所有合適的行,Group By用來分組個統(tǒng)計行,Having字句用來剔除多余的分組.這樣Group By 個Having的開銷小,查詢快.對于大的數(shù)據(jù)行進行分組和Having十分消耗資源.如果Group BY的目的不包括計算,只是分組,那么用Distinct更快

38,一次更新多條記錄比分多次更新每次一條快,就是說批處理好

39,少用臨時表,盡量用結(jié)果集和Table類性的變量來代替它,Table 類型的變量比臨時表好

40,在SQL2000下,計算字段是可以索引的,需要滿足的條件如下:

a,計算字段的表達是確定的

b,不能用在TEXT,Ntext,Image數(shù)據(jù)類型

c,必須配制如下選項 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….

41,盡量將數(shù)據(jù)的處理工作放在服務(wù)器上,減少網(wǎng)絡(luò)的開銷,如使用存儲過程.存儲過程是編譯好,優(yōu)化過,并且被組織到一個執(zhí)行規(guī)劃里,且存儲在數(shù)據(jù)庫中的SQL語句,是控制流語言的集合,速度當(dāng)然快.反復(fù)執(zhí)行的動態(tài)SQL,可以使用臨時存儲過程,該過程(臨時表)被放在Tempdb中.以前由于SQL SERVER對復(fù)雜的數(shù)學(xué)計算不支持,所以不得不將這個工作放在其他的層上而增加網(wǎng)絡(luò)的開銷.SQL2000支持UDFs,現(xiàn)在支持復(fù)雜的數(shù)學(xué)計算,函數(shù)的返回值不要太大,這樣的開銷很大.用戶自定義函數(shù)象光標(biāo)一樣執(zhí)行的消耗大量的資源,如果返回大的結(jié)果采用存儲過程

42,不要在一句話里再三的使用相同的函數(shù),浪費資源,將結(jié)果放在變量里再調(diào)用更快

43,Select COUNT(*)的效率教低,盡量變通他的寫法,而EXISTS快.同時請注意區(qū)別: select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!

44,當(dāng)服務(wù)器的內(nèi)存夠多時,配制線程數(shù)量 = 最大連接數(shù)+5,這樣能發(fā)揮最大的效率;否則使用 配制線程數(shù)量最大連接數(shù)啟用SQL SERVER的線程池來解決,如果還是數(shù)量 = 最大連接數(shù)+5,嚴重的損害服務(wù)器的性能.

45,按照一定的次序來訪問你的表.如果你先鎖住表A,再鎖住表B,那么在所有的存儲過程中都要按照這個順序來鎖定它們.如果你(不經(jīng)意的)某個存儲過程中先鎖定表B,再鎖定表A,這可能就會導(dǎo)致一個死鎖.如果鎖定順序沒有被預(yù)先詳細的設(shè)計好,死鎖很難被發(fā)現(xiàn)

46,通過SQL Server Performance Monitor監(jiān)視相應(yīng)硬件的負載 Memory: Page Faults / sec計數(shù)器如果該值偶爾走高,表明當(dāng)時有線程競爭內(nèi)存.如果持續(xù)很高,則內(nèi)存可能是瓶頸.

Process:

1,% DPC Time 指在范例間隔期間處理器用在緩延程序調(diào)用(DPC)接收和提供服務(wù)的百分比.(DPC 正在運行的為比標(biāo)準(zhǔn)間隔優(yōu)先權(quán)低的間隔). 由于 DPC 是以特權(quán)模式執(zhí)行的,DPC 時間的百分比為特權(quán)時間百分比的一部分.這些時間單獨計算并且不屬于間隔計算總數(shù)的一部 分.這個總數(shù)顯示了作為實例時間百分比的平均忙時.

2,%Processor Time計數(shù)器　如果該參數(shù)值持續(xù)超過95%,表明瓶頸是CPU.可以考慮增加一個處理器或換一個更快的處理器.

3,% Privileged Time 指非閑置處理器時間用于特權(quán)模式的百分比.(特權(quán)模式是為操作系統(tǒng)組件和操縱硬件驅(qū)動程序而設(shè)計的一種處理模式.它允許直接訪問硬件和所有內(nèi)存.另一種模式為用戶模式,它是一種為應(yīng)用程序,環(huán)境分系統(tǒng)和整數(shù)分系統(tǒng)設(shè)計的一種有限處理模式.操作系統(tǒng)將應(yīng)用程序線程轉(zhuǎn)換成特權(quán)模式以訪問操作系統(tǒng)服務(wù)).特權(quán)時間的 % 包括為間斷和 DPC 提供服務(wù)的時間.特權(quán)時間比率高可能是由于失敗設(shè)備產(chǎn)生的大數(shù)量的間隔而引起的.這個計數(shù)器將平均忙時作為樣本時間的一部分顯示.

4,% User Time表示耗費CPU的數(shù)據(jù)庫操作,如排序,執(zhí)行aggregate functions等.如果該值很高,可考慮增加索引,盡量使用簡單的表聯(lián)接,水平分割大表格等方法來降低該值. Physical Disk: Curretn Disk Queue Length計數(shù)器該值應(yīng)不超過磁盤數(shù)的1.5~2倍.要提高性能,可增加磁盤. SQLServer:Cache Hit Ratio計數(shù)器該值越高越好.如果持續(xù)低于80%,應(yīng)考慮增加內(nèi)存. 注意該參數(shù)值是從SQL Server啟動后,就一直累加記數(shù),所以運行經(jīng)過一段時間后,該值將不能反映系統(tǒng)當(dāng)前值.

47,分析select emp_name form employee where salary 3000 在此語句中若salary是Float類型的,則優(yōu)化器對其進行優(yōu)化為Convert(float,3000),因為3000是個整數(shù),我們應(yīng)在編程時使用3000.0而不要等運行時讓DBMS進行轉(zhuǎn)化.同樣字符和整型數(shù)據(jù)的轉(zhuǎn)換.

48,查詢的關(guān)聯(lián)同寫的順序

select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' (A = B ,B = '號碼')

select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' (A = B ,B = '號碼', A = '號碼')

select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' (B = '號碼', A = '號碼')

如何提高oracle視圖的查詢速度？

1、可以縮小到5張表，因為很多都是從一張表里取出來的數(shù)據(jù)；

2、不能子查詢因為是要顯示數(shù)據(jù)子查詢只是查詢條件；

3不能建立索引，因為這樣會影響表的增刪改，它里面都是導(dǎo)入進去的一次增加上千條都有可能；

4、定期結(jié)轉(zhuǎn)是什么意思，表示沒看懂。時間發(fā)的太長的話就算了；

5、定期結(jié)轉(zhuǎn)的意思就是，將你要建立視圖的幾種表數(shù)據(jù)“轉(zhuǎn)移”到一張新表里面去，不用視圖查詢。數(shù)據(jù)庫全文檢索是RDBMS自帶的擴展功能，可以實現(xiàn)高速查詢。全文檢索建議搜索下關(guān)鍵字，什么lucene之類的就出來了。

如何提高oracle的查詢速度

幾個簡單的步驟大幅提高Oracle性能--我優(yōu)化數(shù)據(jù)庫的三板斧。

數(shù)據(jù)庫優(yōu)化的討論可以說是一個永恒的主題。資深的Oracle優(yōu)化人員通常會要求提出性能問題的人對數(shù)據(jù)庫做一個statspack，貼出數(shù)據(jù)庫配置等等。還有的人認為要抓出執(zhí)行最慢的語句來進行優(yōu)化。但實際情況是，提出疑問的人很可能根本不懂執(zhí)行計劃，更不要說statspack了。而我認為，數(shù)據(jù)庫優(yōu)化，應(yīng)該首先從大的方面考慮：網(wǎng)絡(luò)、服務(wù)器硬件配置、操作系統(tǒng)配置、Oracle服務(wù)器配置、數(shù)據(jù)結(jié)構(gòu)組織、然后才是具體的調(diào)整。實際上網(wǎng)絡(luò)、硬件等往往無法決定更換，應(yīng)用程序一般也無法修改，因此應(yīng)該著重從數(shù)據(jù)庫配置、數(shù)據(jù)結(jié)構(gòu)上來下手，首先讓數(shù)據(jù)庫有一個良好的配置，然后再考慮具體優(yōu)化某些過慢的語句。我在給我的用戶系統(tǒng)進行優(yōu)化的過程中，總結(jié)了一些基本的，簡單易行的辦法來優(yōu)化數(shù)據(jù)庫，算是我的三板斧，呵呵。不過請注意，這些不一定普遍使用，甚至有的會有副作用，但是對OLTP系統(tǒng)、基于成本的數(shù)據(jù)庫往往行之有效，不妨試試。（注：附件是Burleson寫的用來報告數(shù)據(jù)庫性能等信息的腳本，本文用到）

一．設(shè)置合適的SGA

常常有人抱怨服務(wù)器硬件很好，但是Oracle就是很慢。很可能是內(nèi)存分配不合理造成的。(1)假設(shè)內(nèi)存有512M，這通常是小型應(yīng)用。建議Oracle的SGA大約240M，其中：共享池（SHARED_POOL_SIZE）可以設(shè)置60M到80M，根據(jù)實際的用戶數(shù)、查詢等來定。數(shù)據(jù)塊緩沖區(qū)可以大致分配120M-150M，8i下需要設(shè)置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數(shù)據(jù)塊緩沖區(qū)大小。9i 下的數(shù)據(jù)緩沖區(qū)可以用db_cache_size來直接分配。

(2)假設(shè)內(nèi)存有1G，Oracle 的SGA可以考慮分配500M：共享池分配100M到150M，數(shù)據(jù)緩沖區(qū)分配300M到400M。

(3)內(nèi)存2G，SGA可以考慮分配1.2G，共享池300M到500M，剩下的給數(shù)據(jù)塊緩沖區(qū)。

(4)內(nèi)存2G以上：共享池300M到500M就足夠啦，再多也沒有太大幫助；(Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大，但是一定要注意兩個問題：一是要給操作系統(tǒng)和其他應(yīng)用留夠內(nèi)存，二是對于32位的操作系統(tǒng)，Oracle的SGA有1.75G的限制。有的32位操作系統(tǒng)上可以突破這個限制，方法還請看Biti的大作吧。

二．分析表和索引，更改優(yōu)化模式

Oracle默認優(yōu)化模式是CHOOSE，在這種情況下，如果表沒有經(jīng)過分析，經(jīng)常導(dǎo)致查詢使用全表掃描，而不使用索引。這通常導(dǎo)致磁盤I/O太多，而導(dǎo)致查詢很慢。如果沒有使用執(zhí)行計劃穩(wěn)定性，則應(yīng)該把表和索引都分析一下，這樣可能直接會使查詢速度大幅提升。分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。對于少于100萬的表，可以考慮分析整個表，對于很大的表，可以按百分比來分析，但是百分比不能過低，否則生成的統(tǒng)計信息可能不準(zhǔn)確?？梢酝ㄟ^DBA_TABLES的LAST_ANALYZED列來查看表是否經(jīng)過分析或分析時間，索引可以通過DBA_INDEXES的LAST_ANALYZED列。

下面通過例子來說明分析前后的速度對比。（表CASE_GA_AJZLZ大約有35萬數(shù)據(jù)，有主鍵）首先在SQLPLUS中打開自動查詢執(zhí)行計劃功能。(第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan.sql來創(chuàng)建PLAN_TABLE這個表)

SQL SET AUTOTRACE ON

SQLSET TIMING ON

通過SET AUTOTRACE ON 來查看語句的執(zhí)行計劃，通過SET TIMING ON 來查看語句運行時間。

SQL seleCT count(*) from CASE_GA_AJZLZ;

COUNT(*)

----------

346639

已用時間: 00: 00: 21.38

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF 'CASE_GA_AJZLZ'

……………………

請注意上面分析中的TABLE ACCESS(FULL)，這說明該語句執(zhí)行了全表掃描。而且查詢使用了21.38秒。這時表還沒有經(jīng)過分析。下面我們來對該表進行分析：

SQL analyze table CASE_GA_AJZLZ compute statistics;

表已分析。已用時間: 00: 05: 357.63。然后再來查詢：

SQL select count(*) from CASE_GA_AJZLZ;

COUNT(*)

----------

346639

已用時間: 00: 00: 00.71

Execution Plan

0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1)

1 0 SORT (AGGREGATE)

2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351

Card=346351)

…………………………

請注意，這次時間僅僅用了0.71秒！這要歸功于INDEX(FAST FULL SCAN)。通過分析表，查詢使用了PK_AJZLZ索引，磁盤I/O大幅減少，速度也大幅提升！下面的實用語句可以用來生成分析某個用戶的所有表和索引，假設(shè)用戶是GAXZUSR：

SQL set pagesize 0

SQL spool d:\analyze_tables.sql;

SQL select 'analyze table '||owner||'.'||table_name||'

compute statistics;' from dba_tables where owner='GAXZUSR';

SQL spool off

SQL spool spool d:\analyze_indexes.sql;

SQL select 'analyze index '||owner||'.'||index_name||'

compute statistics;' from dba_indexes where owner='GAXZUSR';

SQL spool off

SQL @d:\analyze_tables.sql

SQL @d:\analyze_indexes.sql

解釋：上面的語句生成了兩個sql文件，分別分析全部的GAXZUSR的表和索引。如果需要按照百分比來分析表，可以修改一下腳本。通過上面的步驟，我們就完成了對表和索引的分析，可以測試一下速度的改進啦。建議定期運行上面的語句，尤其是數(shù)據(jù)經(jīng)過大量更新。

當(dāng)然，也可以通過dbms_stats來分析表和索引，更方便一些。但是我仍然習(xí)慣上面的方法，因為成功與否會直接提示出來。

另外，我們可以將優(yōu)化模式進行修改。optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。對于OLTP系統(tǒng)，可以改成FIRST_ROWS，來要求查詢盡快返回結(jié)果。這樣即使不用分析，在一般情況下也可以提高查詢性能。但是表和索引經(jīng)過分析后有助于找到最合適的執(zhí)行計劃。

三．設(shè)置cursor_sharing=FORCE 或SIMILAR

這種方法是8i才開始有的，oracle805不支持。通過設(shè)置該參數(shù)，可以強制共享只有文字不同的語句解釋計劃。例如下面兩條語句可以共享：

SQL SELECT * FROM MYTABLE WHERE NAME='tom'

SQL SELECT * FROM MYTABLE WHERE NAME='turner'

這個方法可以大幅降低緩沖區(qū)利用率低的問題，避免語句重新解釋。通過這個功能，可以很大程度上解決硬解析帶來的性能下降的問題。個人感覺可根據(jù)系統(tǒng)的實際情況，決定是否將該參數(shù)改成FORCE。該參數(shù)默認是exact。不過一定要注意，修改之前，必須先給ORACLE打補丁，否則改之后oracle會占用100%的CPU,無法使用。對于ORACLE9i，可以設(shè)置成SIMILAR，這個設(shè)置綜合了FORCE和EXACT的優(yōu)點。不過請慎用這個功能，這個參數(shù)也可能帶來很大的負面影響！

四．將常用的小表、索引釘在數(shù)據(jù)緩存KEEP池中

內(nèi)存上數(shù)據(jù)讀取速度遠遠比硬盤中讀取要快，據(jù)稱，內(nèi)存中數(shù)據(jù)讀的速度是硬盤的14000倍！如果資源比較豐富，把常用的小的、而且經(jīng)常進行全表掃描的表給釘內(nèi)存中，當(dāng)然是在好不過了。可以簡單的通過ALTER TABLE tablename CACHE來實現(xiàn)，在ORACLE8i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP)。一般來說，可以考慮把200數(shù)據(jù)塊之內(nèi)的表放在keep池中，當(dāng)然要根據(jù)內(nèi)存大小等因素來定。關(guān)于如何查出那些表或索引符合條件，可以使用本文提供的access.sql和access_report.sql。這兩個腳本是著名的Oracle專家 Burleson寫的，你也可以在讀懂了情況下根據(jù)實際情況調(diào)整一下腳本。對于索引，可以通過ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)來釘在KEEP池中。

將表定在KEEP池中需要做一些準(zhǔn)備工作。對于ORACLE9i 需要設(shè)置DB_KEEP_CACHE_SIZE，對于8i，需要設(shè)置buffer_pool_keep。在8i中，還要修改db_block_lru_latches，該參數(shù)默認是1，無法使用buffer_pool_keep。該參數(shù)應(yīng)該比2*3*CPU數(shù)量少，但是要大于1，才能設(shè)置DB_KEEP_CACHE_BUFFER。buffer_pool_keep從db_block_buffers中分配，因此也要小于db_block_buffers。設(shè)置好這些參數(shù)后，就可以把常用對象永久釘在內(nèi)存里。

五．設(shè)置optimizer_max_permutations

對于多表連接查詢，如果采用基于成本優(yōu)化(CBO)，ORACLE會計算出很多種運行方案，從中選擇出最優(yōu)方案。這個參數(shù)就是設(shè)置oracle究竟從多少種方案來選擇最優(yōu)。如果設(shè)置太大，那么計算最優(yōu)方案過程也是時間比較長的。Oracle805和8i默認是80000，8建議改成2000。對于9i，已經(jīng)默認是2000了。

六．調(diào)整排序參數(shù)

(1) SORT_AREA_SIZE:默認的用來排序的SORT_AREA_SIZE大小是32K，通常顯得有點小，一般可以考慮設(shè)置成1M（1048576）。這個參數(shù)不能設(shè)置過大，因為每個連接都要分配同樣的排序內(nèi)存。

(2) SORT_MULTIBLOCK_READ_COUNT:增大這個參數(shù)可以提高臨時表空間排序性能，該參數(shù)默認是2，可以改成32來對比一下排序查詢時間變化。注意，這個參數(shù)的最大值與平臺有關(guān)系。

網(wǎng)頁標(biāo)題：oracle怎么看速度,oracle查詢速度提高方法
分享路徑：http://muchs.cn/article12/hcgpgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、服務(wù)器托管、微信小程序、標(biāo)簽優(yōu)化、定制開發(fā)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)