oracle怎么用rda oracle怎么用sql語句把一個表的所有字段名轉(zhuǎn)為大寫

oracle rac awr報告中std怎么分析

AWR 是 Oracle 10g 版本 推出的新特性， 全稱叫Automatic Workload Repository-自動負(fù)載信息庫

公司主營業(yè)務(wù)：網(wǎng)站建設(shè)、成都網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出隆化免費做網(wǎng)站回饋大家。

AWR 是通過對比兩次快照(snapshot)收集到的統(tǒng)計信息，來生成報表數(shù)據(jù)，生成的報表包括多個部分。

WORKLOAD REPOSITORY report for

DB Name

DB Id

Instance

Inst num

Release

RAC

Host

ICCI

1314098396

ICCI1

1

10.2.0.3.0

YES

HPGICCI1

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

2678

25-Dec-08 14:04:50

24

1.5

End Snap:

2680

25-Dec-08 15:23:37

26

1.5

Elapsed:

78.79 (mins)

DB Time:

11.05 (mins)

DB Time不包括Oracle后臺進(jìn)程消耗的時間。如果DB Time遠(yuǎn)遠(yuǎn)小于Elapsed時間，說明數(shù)據(jù)庫比較空閑。

db time= cpu time + wait time（不包含空閑等待） （非后臺進(jìn)程）

說白了就是db time就是記錄的服務(wù)器花在數(shù)據(jù)庫運算(非后臺進(jìn)程)和等待(非空閑等待)上的時間

DB time = cpu time + all of nonidle wait event time

在79分鐘里（其間收集了3次快照數(shù)據(jù)），數(shù)據(jù)庫耗時11分鐘，RDA數(shù)據(jù)中顯示系統(tǒng)有8個邏輯CPU（4個物理CPU），

平均每個CPU耗時1.4分鐘，CPU利用率只有大約2%（1.4/79）。說明系統(tǒng)壓力非常小。

列出下面這兩個來做解釋：

Report A:

Snap Id Snap Time Sessions Curs/Sess

--------- ------------------- -------- ---------

Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1

End Snap: 4612 24-Jul-08 23:00:25 17 1.7

Elapsed: 59.51 (mins)

DB Time: 466.37 (mins)

Report B:

Snap Id Snap Time Sessions Curs/Sess

--------- ------------------- -------- ---------

Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6

End Snap: 3102 13-Nov-07 22:00:15 40 16.4

Elapsed: 59.63 (mins)

DB Time: 19.49 (mins)

服務(wù)器是AIX的系統(tǒng)，4個雙核cpu,共8個核:

/sbin bindprocessor -q

The available processors are: 0 1 2 3 4 5 6 7

先說Report A,在snapshot間隔中，總共約60分鐘，cpu就共有60*8=480分鐘，DB time為466.37分鐘

則：cpu花費了466.37分鐘在處理Oralce非空閑等待和運算上(比方邏輯讀)

也就是說cpu有 466.37/480*100% 花費在處理Oracle的操作上，這還不包括后臺進(jìn)程

看Report B，總共約60分鐘，cpu有 19.49/480*100% 花費在處理Oracle的操作上

很顯然，Report B中服務(wù)器的平均負(fù)載很低。

從awr report的Elapsed time和DB Time就能大概了解db的負(fù)載。

可是對于批量系統(tǒng)，數(shù)據(jù)庫的工作負(fù)載總是集中在一段時間內(nèi)。如果快照周期不在這一段時間內(nèi)，

或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時間，所得出的分析結(jié)果是沒有意義的.

這也說明選擇分析時間段很關(guān)鍵，要選擇能夠代表性能問題的時間段。

Report Summary

Cache Sizes

Begin

End

Buffer Cache:

3,344M

3,344M

Std Block Size:

8K

Shared Pool Size:

704M

704M

Log Buffer:

14,352K

顯示SGA中每個區(qū)域的大小（在AMM改變它們之后），可用來與初始參數(shù)值比較。

shared pool主要包括library cache和dictionary cache。

library cache用來存儲最近解析（或編譯）后SQL、PL/SQL和Java classes等。

dictionary cache用來存儲最近引用的數(shù)據(jù)字典。

發(fā)生在library cache或dictionary cache的cache miss代價要比發(fā)生在buffer cache的代價高得多。

因此shared pool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache。

Load Profile

Per Second

Per Transaction

Redo size:

918,805.72

775,912.72

Logical reads:

3,521.77

2,974.06

Block changes:

1,817.95

1,535.22

Physical reads:

68.26

57.64

Physical writes:

362.59

306.20

User calls:

326.69

275.88

Parses:

38.66

32.65

Hard parses:

0.03

0.03

Sorts:

0.61

0.51

Logons:

0.01

0.01

Executes:

354.34

299.23

Transactions:

1.18

% Blocks changed per Read:

51.62

Recursive Call %:

51.72

Rollback per transaction %:

85.49

Rows per Sort:

########

顯示數(shù)據(jù)庫負(fù)載概況，將之與基線數(shù)據(jù)比較才具有更多的意義，如果每秒或每事務(wù)的負(fù)載變化不大，說明應(yīng)用運行比較穩(wěn)定。

單個的報告數(shù)據(jù)只說明應(yīng)用的負(fù)載情況，絕大多數(shù)據(jù)并沒有一個所謂“正確”的值，然而

Logons大于每秒1~2個、Hard parses大于每秒100、全部parses超過每秒300表明可能有爭用問題。

Redo size：每秒產(chǎn)生的日志大小(單位字節(jié))，可標(biāo)志數(shù)據(jù)變更頻率, 數(shù)據(jù)庫任務(wù)的繁重與否。

Logical reads：每秒/每事務(wù)邏輯讀的塊數(shù).平?jīng)Q每秒產(chǎn)生的邏輯讀的block數(shù)。Logical Reads= Consistent Gets + DB Block Gets

Block changes：每秒/每事務(wù)修改的塊數(shù)

Physical reads：每秒/每事務(wù)物理讀的塊數(shù)

Physical writes：每秒/每事務(wù)物理寫的塊數(shù)

User calls：每秒/每事務(wù)用戶call次數(shù)

Parses：SQL解析的次數(shù).每秒解析次數(shù)，包括fast parse，soft parse和hard parse三種數(shù)量的綜合。

軟解析每秒超過300次意味著你的"應(yīng)用程序"效率不高，調(diào)整session_cursor_cache。

在這里，fast parse指的是直接在PGA中命中的情況（設(shè)置了session_cached_cursors=n）；

soft parse是指在shared pool中命中的情形；hard parse則是指都不命中的情況。

Hard parses：其中硬解析的次數(shù)，硬解析太多，說明SQL重用率不高。

每秒產(chǎn)生的硬解析次數(shù), 每秒超過100次，就可能說明你綁定使用的不好，也可能是共享池設(shè)置不合理。

這時候可以啟用參數(shù)cursor_sharing=similar|force，該參數(shù)默認(rèn)值為exact。但該參數(shù)設(shè)置為similar時，存在bug，可能導(dǎo)致執(zhí)行計劃的不優(yōu)。

Sorts：每秒/每事務(wù)的排序次數(shù)

Logons：每秒/每事務(wù)登錄的次數(shù)

Executes：每秒/每事務(wù)SQL執(zhí)行次數(shù)

Transactions：每秒事務(wù)數(shù).每秒產(chǎn)生的事務(wù)數(shù)，反映數(shù)據(jù)庫任務(wù)繁重與否。

Blocks changed per Read：表示邏輯讀用于修改數(shù)據(jù)塊的比例.在每一次邏輯讀中更改的塊的百分比。

Recursive Call：遞歸調(diào)用占所有操作的比率.遞歸調(diào)用的百分比，如果有很多PL/SQL，那么這個值就會比較高。

Rollback per transaction：每事務(wù)的回滾率.看回滾率是不是很高，因為回滾很耗資源 ,如果回滾率過高,

可能說明你的數(shù)據(jù)庫經(jīng)歷了太多的無效操作 ,過多的回滾可能還會帶來Undo Block的競爭

該參數(shù)計算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。

Rows per Sort：每次排序的行數(shù)

注:

Oracle的硬解析和軟解析

提到軟解析(soft prase)和硬解析(hard prase)，就不能不說一下Oracle對sql的處理過程。

當(dāng)你發(fā)出一條sql語句交付Oracle，在執(zhí)行和獲取結(jié)果前，Oracle對此sql將進(jìn)行幾個步驟的處理過程：

1、語法檢查(syntax check)

檢查此sql的拼寫是否語法。

2、語義檢查(semantic check)

諸如檢查sql語句中的訪問對象是否存在及該用戶是否具備相應(yīng)的權(quán)限。

3、對sql語句進(jìn)行解析(prase)

利用內(nèi)部算法對sql進(jìn)行解析，生成解析樹(parse tree)及執(zhí)行計劃(execution plan)。

4、執(zhí)行sql，返回結(jié)果(execute and return)

其中，軟、硬解析就發(fā)生在第三個過程里。

Oracle利用內(nèi)部的hash算法來取得該sql的hash值，然后在library cache里查找是否存在該hash值；

假設(shè)存在，則將此sql與cache中的進(jìn)行比較；

假設(shè)“相同”，就將利用已有的解析樹與執(zhí)行計劃，而省略了優(yōu)化器的相關(guān)工作。這也就是軟解析的過程。

誠然，如果上面的2個假設(shè)中任有一個不成立，那么優(yōu)化器都將進(jìn)行創(chuàng)建解析樹、生成執(zhí)行計劃的動作。這個過程就叫硬解析。

創(chuàng)建解析樹、生成執(zhí)行計劃對于sql的執(zhí)行來說是開銷昂貴的動作，所以，應(yīng)當(dāng)極力避免硬解析，盡量使用軟解析。

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:

100.00

Redo NoWait %:

100.00

Buffer Hit %:

98.72

In-memory Sort %:

99.86

Library Hit %:

99.97

Soft Parse %:

99.92

Execute to Parse %:

89.09

Latch Hit %:

99.99

Parse CPU to Parse Elapsd %:

7.99

% Non-Parse CPU:

99.95

本節(jié)包含了Oracle關(guān)鍵指標(biāo)的內(nèi)存命中率及其它數(shù)據(jù)庫實例操作的效率。其中Buffer Hit Ratio 也稱Cache Hit Ratio，

Library Hit ratio也稱Library Cache Hit ratio。

同Load Profile一節(jié)相同，這一節(jié)也沒有所謂“正確”的值，而只能根據(jù)應(yīng)用的特點判斷是否合適。

在一個使用直接讀執(zhí)行大型并行查詢的DSS環(huán)境，20%的Buffer Hit Ratio是可以接受的，而這個值對于一個OLTP系統(tǒng)是完全不能接受的。

根據(jù)Oracle的經(jīng)驗，對于OLTP系統(tǒng)，Buffer Hit Ratio理想應(yīng)該在90%以上。

Buffer Nowait表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。在緩沖區(qū)中獲取Buffer的未等待比率

Buffer Nowait的這個值一般需要大于99%。否則可能存在爭用，可以在后面的等待事件中進(jìn)一步確認(rèn)。

buffer hit表示進(jìn)程從內(nèi)存中找到數(shù)據(jù)塊的比率，監(jiān)視這個值是否發(fā)生重大變化比這個值本身更重要。

對于一般的OLTP系統(tǒng)，如果此值低于80%，應(yīng)該給數(shù)據(jù)庫分配更多的內(nèi)存。

數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率，通常應(yīng)在95%以上。否則，小于95%，需要調(diào)整重要的參數(shù)，小于90%可能是要加db_cache_size。

一個高的命中率，不一定代表這個系統(tǒng)的性能是最優(yōu)的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的db file sequential read）

但是一個比較低的命中率，一般就會對這個系統(tǒng)的性能產(chǎn)生影響，需要調(diào)整。命中率的突變，往往是一個不好的信息。

如果命中率突然增大，可以檢查top buffer get SQL，查看導(dǎo)致大量邏輯讀的語句和索引，

如果命中率突然減小，可以檢查top physical reads SQL，檢查產(chǎn)生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。

Redo NoWait表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。

當(dāng)redo buffer達(dá)到1M時，就需要寫到redo log文件，所以一般當(dāng)redo buffer設(shè)置超過1M，不太可能存在等待buffer空間分配的情況。

當(dāng)前，一般設(shè)置為2M的redo buffer，對于內(nèi)存總量來說，應(yīng)該不是一個太大的值。

library hit表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當(dāng)應(yīng)用程序調(diào)用SQL或存儲過程時，

Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執(zhí)行語句；如果不存在，Oracle解析此語句，并在Library Cache中為它分配共享SQL區(qū)。

低的library hit ratio會導(dǎo)致過多的解析，增加CPU消耗，降低性能。

如果library hit ratio低于90%，可能需要調(diào)大shared pool區(qū)。

STATEMENT在共享區(qū)的命中率，通常應(yīng)該保持在95%以上，否則需要要考慮：加大共享池；使用綁定變量；修改cursor_sharing等參數(shù)。

Latch Hit：Latch是一種保護(hù)內(nèi)存結(jié)構(gòu)的鎖，可以認(rèn)為是SERVER進(jìn)程獲取訪問內(nèi)存數(shù)據(jù)結(jié)構(gòu)的許可。

要確保Latch Hit99%，否則意味著Shared Pool latch爭用，可能由于未共享的SQL，或者Library Cache太小，可使用綁定變更或調(diào)大Shared Pool解決。

要確保99%，否則存在嚴(yán)重的性能問題。當(dāng)該值出現(xiàn)問題的時候，我們可以借助后面的等待時間和latch分析來查找解決問題。

Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。

計算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。

即：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)。如果該比率為100%，意味著CPU等待時間為0，沒有任何等待。

Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。

計算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個值比較小，表示解析消耗的CPU時間過多。

與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執(zhí)行的大部分工作是執(zhí)行查詢的工作，而不是分析查詢的工作。

Execute to Parse：是語句執(zhí)行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多。

計算公式為：Execute to Parse =100 * (1 - Parses/Executions)。

本例中，差不多每execution 5次需要一次parse。所以如果系統(tǒng)Parses Executions，就可能出現(xiàn)該比率小于0的情況。

該值0通常說明shared pool設(shè)置或者語句效率存在問題，造成反復(fù)解析，reparse可能較嚴(yán)重,或者是可能同snapshot有關(guān)，通常說明數(shù)據(jù)庫性能存在問題。

In-memory Sort：在內(nèi)存中排序的比率，如果過低說明有大量的排序在臨時表空間中進(jìn)行。

考慮調(diào)大PGA(10g)。如果低于95%，可以通過適當(dāng)調(diào)大初始化參數(shù)PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，

注意這兩個參數(shù)設(shè)置作用的范圍時不同的，SORT_AREA_SIZE是針對每個session設(shè)置的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。

Soft Parse：軟解析的百分比（softs/softs+hards），近似當(dāng)作sql在共享區(qū)的命中率，太低則需要調(diào)整應(yīng)用使用綁定變量。

sql在共享區(qū)的命中率，小于95%,需要考慮綁定，如果低于80%，那么就可以認(rèn)為sql基本沒有被重用。

Shared Pool Statistics

Begin

End

Memory Usage %:

47.19

47.50

% SQL with executions1:

88.48

79.81

% Memory for SQL w/exec1:

79.99

73.52

Memory Usage %：對于一個已經(jīng)運行一段時間的數(shù)據(jù)庫來說，共享池內(nèi)存使用率，應(yīng)該穩(wěn)定在75%-90%間，

如果太小，說明Shared Pool有浪費，而如果高于90，說明共享池中有爭用，內(nèi)存不足。

這個數(shù)字應(yīng)該長時間穩(wěn)定在75%～90%。如果這個百分比太低，表明共享池設(shè)置過大，帶來額外的管理上的負(fù)擔(dān)，從而在某些條件下會導(dǎo)致性能的下降。

如果這個百分率太高，會使共享池外部的組件老化，如果SQL語句被再次執(zhí)行，這將使得SQL語句被硬解析。

在一個大小合適的系統(tǒng)中，共享池的使用率將處于75%到略低于90%的范圍內(nèi).

SQL with executions1：執(zhí)行次數(shù)大于1的sql比率，如果此值太小，說明需要在應(yīng)用中更多使用綁定變量，避免過多SQL解析。

　

　

　

如何分析Oracle

DB Time不包括Oracle后臺進(jìn)程消耗的時間。如果DB Time遠(yuǎn)遠(yuǎn)小于Elapsed時間，說明數(shù)據(jù)庫比較空閑。

在79分鐘里（其間收集了3次快照數(shù)據(jù)），數(shù)據(jù)庫耗時11分鐘，RDA數(shù)據(jù)中顯示系統(tǒng)有8個邏輯CPU（4個物理CPU），平均每個CPU耗時1.4分鐘，CPU利用率只有大約2%（1.4/79）。說明系統(tǒng)壓力非常小。

可是對于批量系統(tǒng)，數(shù)據(jù)庫的工作負(fù)載總是集中在一段時間內(nèi)。如果快照周期不在這一段時間內(nèi)，或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時間，所得出的分析結(jié)果是沒有意義的。這也說明選擇分析時間段很關(guān)鍵，要選擇能夠代表性能問題的時間段。

指標(biāo)公式:

每個CPU耗時:=DB Time / 邏輯cpu個數(shù)=11.05/8=1.4

CPU利用率:DB Time / (邏輯cpu個數(shù)*Elapsed)=11.05/(8*78.19) *100%=2%

我想學(xué)oracle數(shù)據(jù)庫，請教如何安裝單機版．怎么使用啊

服務(wù)器與客戶端可以裝在一臺電腦上，裝上oracle數(shù)據(jù)庫服務(wù)器就足夠了，這時你已經(jīng)擁有oracle客戶端的功能。（1）你可以通過第三方軟件：如 PLSQL Developer（非常強大的Oracle數(shù)據(jù)庫操作軟件）來操作Oracle數(shù)據(jù)庫；（2）當(dāng)然裝完Oracle數(shù)據(jù)庫服務(wù)器以后，你也可以通過控制臺來操作，步驟如下：開始-〉運行-〉cmd（打開控制臺窗口）-〉敲入 sqlplus -輸入正確的用戶名密碼（如scott/tiger）就可以操作了。

裝完Oracle數(shù)據(jù)庫服務(wù)器以后，如果你還裝Oracle客戶端（Client），那么你在連接數(shù)據(jù)庫的時候記得加上完整的數(shù)據(jù)庫服務(wù)名：如scott/tiger@127.0.0.1:1521/YourInstanceName

這樣也能保證正確的操作數(shù)據(jù)庫了。

oracle 里面declare怎么用啊?

1、啟動plsql并登陸oracle數(shù)據(jù)庫。

2、創(chuàng)建測試表-- 創(chuàng)建表create table TestTable(? id? ? ? varchar2(36) not null,? colcode nvarchar2(50),colname nvarchar2(50));-- 給表名添加備注 comment on table TestTable is '測試表';-- 添加主鍵alter table TestTable add constraint ID primary key (ID)。

3、插入測試數(shù)據(jù)（除了F8執(zhí)行SQL之外，還需要點擊【提交】按鈕才能將數(shù)據(jù)插入到數(shù)據(jù)庫）。

4、desc 作為降序排序的關(guān)鍵字，按照COLCODE 列降序展示表數(shù)據(jù)SELECT * FROM TESTTABLE ORDER BY COLCODE DESC。

5、【DESC + 表名】：顯示表的詳細(xì)字段（直接在Plsql的sql窗口中執(zhí)行會報錯）。

名稱欄目：oracle怎么用rda oracle怎么用sql語句把一個表的所有字段名轉(zhuǎn)為大寫
本文路徑：http://muchs.cn/article20/hjohco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、品牌網(wǎng)站建設(shè)、網(wǎng)站收錄、云服務(wù)器

廣告

聲明：本網(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)