我發現我已經很久沒有更新Blog了..這是我在升級數據庫時出現的問題.現在分享我的成果.
J2EE技術交流群:8883709
舉例:
A數據庫的A_User用戶指定的表空間是tablespace1,B數據庫的B_User用戶指定的空間指定為tablespace2;使用用戶A_User導出DMP文件導入到數據庫B的用戶B_User.用戶B擁有DBA權限,這樣會導致導入B_User用戶時,存儲的表空間為tablespace1,而不是tablespace2.
解決方法:
在B_User上執行
revoke unlimited tablespace from B_User;
--數據庫B的B_User用戶在tablespace1的限額為0
alter user B_User quota 0 on tablespace1;
--自己的默認表空間tablespace1的限額為無限
alter user B_User quota unlimited on tablespace2;
從數據庫A中導出的dmp文件里記錄了每個表的定義語句,這里邊包括表空間信息的,也就是說記錄了這個表的storage parameter,表空間是源數據庫的,即tablespace1。
這時候需要讓目標數據庫,即數據庫B的B_User用戶在tablespace1的限額為0,而在其自己的默認表空間tablespace2的限額為無限,這樣在導入時就會放在tablespace2表空間里了。
posted @
2007-06-25 21:38 Ken.Lee 閱讀(709) |
評論 (0) |
編輯 收藏
在過去的十年中, Oracle 已經成為世界上最專業的數據庫之一。對于 IT 專家來說,就是要確保利用 Oracle 的強大特性來提高他們公司的生產力。最有效的方法之一是通過 Oracle 調優。它有大量的調整參數和技術來改進你的 Oracle 數據庫的性能。
Oracle 調優是一個復雜的主題。關于調優可以寫整整一本書,不過,為了改善 Oracle 數據庫的性能,有一些基本的概念是每個 Oracle DBA 都應該遵從的。
在這篇簡介中,我們將簡要地介紹以下的 Oracle 主題:
-- 外部調整:我們應該記住 Oracle 并不是單獨運行的。因此我們將查看一下通過調整 Oracle 服務器以得到高的性能。
--Row re-sequencing 以減少磁盤 I/O :我們應該懂得 Oracle 調優最重要的目標是減少 I/O 。
--Oracle SQL 調整。 Oracle SQL 調整是 Oracle 調整中最重要的領域之一,只要通過一些簡單的 SQL 調優規則就可以大幅度地提升 SQL 語句的性能,這是一點都不奇怪的。
-- 調整 Oracle 排序:排序對于 Oracle 性能也是有很大影響的。
-- 調整 Oracle 的競爭:表和索引的參數設置對于 UPDATE 和 INSERT 的性能有很大的影響。
我們首先從調整 Oracle 外部的環境開始。如果內存和 CPU 的資源不足的話,任何的 Oracle 調整都是沒有幫助的。
外部的性能問題
Oracle 并不是單獨運行的。 Oracle 數據庫的性能和外部的環境有很大的關系。這些外部的條件包括有:
. CPU--CPU 資源的不足令查詢變慢。當查詢超過了 Oracle 服務器的 CPU 性能時,你的數據庫性能就受到 CPU 的限制。
.內存 -- 可用于 Oralce 的內存數量也會影響 SQL 的性能,特別是在數據緩沖和內存排序方面。
.網絡 -- 大量的 Net8 通信令 SQL 的性能變慢。
許多新手都錯誤的認為應該首先調整 Oracle 數據庫,而不是先確認外部資源是否足夠。實際上,如果外部環境出現瓶頸,再多的 Oracle 調整都是沒有幫助的。
在檢查 Oracle 的外部環境時,有兩個方面是需要注意的:
1 、當運行隊列的數目超過服務器的 CPU 數量時,服務器的性能就會受到 CPU 的限制。補救的方法是為服務器增加額外的 CPU 或者關閉需要很多處理資源的組件,例如 Oracle Parallel Query 。
2 、內存分頁。當內存分頁時,內存容量已經不足,而內存頁是與磁盤上的交換區進行交互的。補救的方法是增加更多的內存,減少 Oracle SGA 的大小,或者關閉 Oracle 的多線程服務器。
可以使用各種標準的服務器工具來得到服務器的統計數據,例如 vmstat,glance,top 和 sar 。 DBA 的目標是確保數據庫服務器擁有足夠的 CPU 和內存資源來處理 Oracle 的請求。
以下讓我們來看一下 Oracle 的 row-resequencing 是如何能夠極大地減少磁盤 I/O 的。
Row-resequencing (行的重新排序)
就象我們上面提到的,有經驗的 Oracle DBA 都知道 I/O 是響應時間的最大組成部分。其中磁盤 I/O 特別厲害,因為當 Oracle 由磁盤上的一個數據文件得到一個數據塊時,讀的進程就必須等待物理 I/O 操作完成。磁盤操作要比數據緩沖慢 10,000 倍。因此,如果可以令 I/O 最小化,或者減少由于磁盤上的文件競爭而帶來的瓶頸,就可以大大地改善 Oracle 數據庫的性能。
如果系統響應很慢,通過減少磁盤 I/O 就可以有一個很快的改善。如果在一個事務中通過按一定的范圍搜索 primary-key 索引來訪問表,那么重新以 CTAS 的方法組織表將是你減少 I/O 的首要策略。通過在物理上將行排序為和 primary-key 索引一樣的順序,就可以加快獲得數據的速度。
就象磁盤的負載平衡一樣,行的重新排序也是很簡單的,而且也很快。通過與其它的 DBA 管理技巧一起使用,就可以在高 I/O 的系統中大大地減少響應的時間。
在高容量的在線事務處理環境中( online transaction processing , OLTP ),數據是由一個 primary 索引得到的,重新排序表格的行就可以令連續塊的順序和它們的 primary 索引一樣,這樣就可以在索引驅動的表格查詢中,減少物理 I/O 并且改善響應時間。這個技巧僅在應用選擇多行的時候有用,或者在使用索引范圍搜索和應用發出多個查詢來得到連續的 key 時有效。對于隨機的唯一 primary-key (主鍵)的訪問將不會由行重新排序中得到好處。
讓我們看一下它是如何工作的??紤]以下的一個 SQL 的查詢,它使用一個索引來得到 100 行:
selectsalaryfromemployeewherelast_name like 'B%';
這個查詢將會使用 last_name_index ,搜索其中的每一行來得到目標行。這個查詢將會至少使用 100 次物理磁盤的讀取,因為 employee 的行存放在不同的數據塊中。
不過,如果表中的行已經重新排序為和 last_name_index 的一樣,同樣的查詢又會怎樣處理呢?我們可以看到這個查詢只需要三次的磁盤 I/O 就讀完全部 100 個員工的資料(一次用作索引的讀取,兩次用作數據塊的讀取),減少了 97 次的塊讀取。
重新排序帶來的性能改善的程度在于在你開始的時候行的亂序性如何,以及你需要由序列中訪問多少行。至于一個表中的行與索引的排序鍵的匹配程度,可以查看數據字典中的 dba_indexes 和 dba_tables 視圖得到。
在 dba_indexes 的視圖中,查看 clustering_factor 列。如果 clustering_factor 的值和表中的塊數目大致一樣,那么你的表和索引的順序是一樣的。不過,如果 clustering_factor 的值接近表中的行數目,那就表明表格中的行和索引的順序是不一樣的。
行重新排序的作用是不可以小看的。在需要進行大范圍的索引搜索的大表中,行重新排序可以令查詢的性能提高三倍。
一旦你已經決定重新排序表中的行,你可以使用以下的工具之一來重新組織表格。
. 使用 Oracle 的 Create Table As Select (CTAS) 語法來拷貝表格
. Oracle9i 自帶的表格重新組織工具
以下,我們來看以下 SQL 語句的調優。
SQL 調優
Oracle 的 SQL 調優是一個復雜的主題,甚至是需要整本書來介紹 Oracle SQL 調優的細微差別。不過有一些基本的規則是每個 Oracle DBA 都需要跟從的,這些規則可以改善他們系統的性能。 SQL 調優的目標是簡單的:
. 消除不必要的大表全表搜索:不必要的全表搜索導致大量不必要的 I/O ,從而拖慢整個數據庫的性能。調優專家首先會根據查詢返回的行數目來評價 SQL 。在一個有序的表中,如果查詢返回少于 40% 的行,或者在一個無序的表中,返回少于 7% 的行,那么這個查詢都可以調整為使用一個索引來代替全表搜索。對于不必要的全表搜索來說,最常見的調優方法是增加索引??梢栽诒碇屑尤霕藴实?B 樹索引,也可以加入 bitmap 和基于函數的索引。要決定是否消除一個全表搜索,你可以仔細檢查索引搜索的 I/O 開銷和全表搜索的開銷,它們的開銷和數據塊的讀取和可能的并行執行有關,并將兩者作對比。在一些情況下,一些不必要的全表搜索的消除可以通過強制使用一個 index 來達到,只需要在 SQL 語句中加入一個索引的提示就可以了。
. 在全表搜索是一個最快的訪問方法時,將小表的全表搜索放到緩存中,調優專家應該確保有一個專門的數據緩沖用作行緩沖。在 Oracle7 中,你可以使用 alter table xxx cache 語句,在 Oracle8 或以上,小表可以被強制為放到 KEEP 池中緩沖。
. 確保最優的索引使用 :對于改善查詢的速度,這是特別重要的。有時 Oracle 可以選擇多個索引來進行查詢,調優專家必須檢查每個索引并且確保 Oracle 使用正確的索引。它還包括 bitmap 和基于函數的索引的使用。
. 確保最優的 JOIN 操作:有些查詢使用 NESTED LOOP join 快一些,有些則是 HASH join 快一些,另外一些則是 sort-merge join 更快。
這些規則看來簡單,不過它們占 SQL 調優任務的 90% ,并且它們也無需完全懂得 Oracle SQL 的內部運作。以下我們來簡單概覽以下 Oracle SQL 的優化。
我們首先簡要查看 Oracle 的排序,并且看一看排序操作是如何影響性能的。
調整 Oracle 的排序操作
排序是 SQL 語法中一個小的方面,但很重要,在 Oracle 的調整中,它常常被忽略。當使用 create index 、 ORDER BY 或者 GROUP BY 的語句時, Oracle 數據庫將會自動執行排序的操作。通常,在以下的情況下 Oracle 會進行排序的操作:
使用 Order by 的 SQL 語句
使用 Group by 的 SQL 語句
在創建索引的時候
進行 table join 時,由于現有索引的不足而導致 SQL 優化器調用 MERGE SORT
當與 Oracle 建立起一個 session 時,在內存中就會為該 session 分配一個私有的排序區域。如果該連接是一個專用的連接 (dedicated connection) ,那么就會根據 init.ora 中 sort_area_size 參數的大小在內存中分配一個 Program Global Area (PGA) 。如果連接是通過多線程服務器建立的,那么排序的空間就在 large_pool 中分配。不幸的是,對于所有的 session ,用做排序的內存量都必須是一樣的,我們不能為需要更大排序的操作分配額外的排序區域。因此,設計者必須作出一個平衡,在分配足夠的排序區域以避免發生大的排序任務時出現磁盤排序( disk sorts )的同時,對于那些并不需要進行很大排序的任務,就會出現一些浪費。當然,當排序的空間需求超出了 sort_area_size 的大小時,這時將會在 TEMP 表空間中分頁進行磁盤排序。磁盤排序要比內存排序大概慢 14,000 倍。
上面我們已經提到,私有排序區域的大小是有 init.ora 中的 sort_area_size 參數決定的。每個排序所占用的大小由 init.ora 中的 sort_area_retained_size 參數決定。當排序不能在分配的空間中完成時,就會使用磁盤排序的方式,即在 Oracle 實例中的臨時表空間中進行。
磁盤排序的開銷是很大的,有幾個方面的原因。首先,和內存排序相比較,它們特別慢;而且磁盤排序會消耗臨時表空間中的資源。 Oracle 還必須分配緩沖池塊來保持臨時表空間中的塊。無論什么時候,內存排序都比磁盤排序好,磁盤排序將會令任務變慢,并且會影響 Oracle 實例的當前任務的執行。還有,過多的磁盤排序將會令 free buffer waits 的值變高,從而令其它任務的數據塊由緩沖中移走。
接著,讓我們看一下 Oracle 的競爭,并且看一下表的存儲參數的設置是如何影響 SQL UPDATE 和 INSERT 語句的性能的。
調整 Oracle 的競爭
Oracle 的其中一個優點時它可以管理每個表空間中的自由空間。 Oracle 負責處理表和索引的空間管理,這樣就可以讓我們無需懂得 Oracle 的表和索引的內部運作。不過,對于有經驗的 Oracle 調優專家來說,他需要懂得 Oracle 是如何管理表的 extent 和空閑的數據塊。對于調整擁有高的 insert 或者 update 的系統來說,這是非常重要的。
要精通對象的調整,你需要懂得 freelists 和 freelist 組的行為,它們和 pctfree 及 pctused 參數的值有關。這些知識對于企業資源計劃( ERP )的應用是特別重要的,因為在這些應用中,不正確的表設置通常是 DML 語句執行慢的原因。
對于初學者來說,最常見的錯誤是認為默認的 Oracle 參數對于所有的對象都是最佳的。除非磁盤的消耗不是一個問題,否則在設置表的 pctfree 和 pctused 參數時,就必須考慮平均的行長和數據庫的塊大小,這樣空的塊才會被有效地放到 freelists 中。當這些設置不正確時,那些得到的 freelists 也是 "read" 塊,因為它們沒有足夠的空間來存儲一行,這樣將會導致明顯的處理延遲。
Freelists 對于有效地重新使用 Oracle 表空間中的空間是很重要的,它和 pctfree 及 pctused 這兩個存儲參數的設置直接相關。通過將 pctused 設置為一個高的值,這時數據庫就會盡快地重新使用塊。不過,高性能和有效地重新使用表的塊是對立的。在調整 Oracle 的表格和索引時,需要認真考慮究竟需要高性能還是有效的空間重用,并且據此來設置表的參數。以下我們來看一下這些 freelists 是如何影響 Oracle 的性能的。
當有一個請求需要插入一行到表格中時, Oracle 就會到 freelist 中尋找一個有足夠的空間來容納一行的塊。你也許知道, freelist 串是放在表格或者索引的第一個塊中,這個塊也被稱為段頭( segment header )。 pctfree 和 pctused 參數的唯一目的就是為了控制塊如何在 freelists 中進出。雖然 freelist link 和 unlink 是簡單的 Oracle 功能,不過設置 freelist link (pctused) 和 unlink (pctfree) 對 Oracle 的性能確實有影響。
由 DBA 的基本知識知道, pctfree 參數是控制 freelist un-links 的(即將塊由 freelists 中移除)。設置 pctfree=10 意味著每個塊都保留 10% 的空間用作行擴展。 pctused 參數是控制 freelist re-links 的。設置 pctused=40 意味著只有在塊的使用低于 40% 時才會回到表格的 freelists 中。
許多新手對于一個塊重新回到 freelists 后的處理都有些誤解。其實,一旦由于一個刪除的操作而令塊被重新加入到 freelist 中,它將會一直保留在 freelist 中即使空間的使用超過了 60% ,只有在到達 pctfree 時才會將數據塊由 freelist 中移走。
表格和索引存儲參數設置的要求總結
以下的一些規則是用來設置 freelists, freelist groups, pctfree 和 pctused 存儲參數的。你也知道, pctused 和 pctfree 的值是可以很容易地通過 alter table 命令修改的,一個好的 DBA 應該知道如何設置這些參數的最佳值。
有效地使用空間和高性能之間是有矛盾的,而表格的存儲參數就是控制這個方面的矛盾:
. 對于需要有效地重新使用空間,可以設置一個高的 pctused 值,不過副作用是需要額外的 I/O 。一個高的 pctused 值意味著相對滿的塊都會放到 freelist 中。因此,這些塊在再次滿之前只可以接受幾行記錄,從而導致更多的 I/O 。
. 追求高性能的話,可以將 pctused 設置為一個低的值,這意味著 Oracle 不會將數據塊放到 freelists 中直到它幾乎是空的。那么塊將可以在滿之前接收更多的行,因此可以減少插入操作的 I/O 。要記住 Oracle 擴展新塊的性能要比重新使用現有的塊高。對于 Oracle 來說,擴展一個表比管理 freelists 消耗更少的資源。
讓我們來回顧一下設置對象存儲參數的一些常見規則:
.經常將 pctused 設置為可以接收一條新行。對于不能接受一行的 free blocks 對于我們來說是沒有用的。如果這樣做,將會令 Oracle 的性能變慢,因為 Oracle 將在擴展表來得到一個空的塊之前,企圖讀取 5 個 "read" 的 free block 。
.表格中 chained rows 的出現意味著 pctfree 太低或者是 db_block_size 太少。在很多情況下, RAW 和 LONG RAW 列都很巨大,以至超過了 Oracle 的最大塊的大小,這時 chained rows 是不可以避免的。
.如果一個表有同時插入的 SQL 語句,那么它需要有同時刪除的語句。運行單一個一個清除的工作將會把全部的空閑塊放到一個 freelist 中,而沒有其它包含有任何空閑塊的 freelists 出現。
. freelist 參數應該設置為表格同時更新的最大值。例如,如果在任何時候,某個表最多有 20 個用戶執行插入的操作,那么該表的參數應該設置為 freelists=20 。
應記住的是 freelist groups 參數的值只是對于 Oracle Parallel Server 和 Real Application Clusters 才是有用的。對于這類 Oracle , freelist groups 應該設置為訪問該表格的 Oracle Parallel Server 實例的數目。
posted @
2008-07-27 23:43 Ken.Lee 閱讀(1632) |
評論 (1) |
編輯 收藏
一、問題的提出
在應用系統開發初期,由于開發數據庫數據比較少,對于查詢SQL語句,復雜視圖的的編
寫等體會不出SQL語句各種寫法的性能優劣,但是如果將應用系統提交實際應用后,隨著
數據庫中數據的增加,系統的響應速度就成為目前系統需要解決的最主要的問題之一。
系統優化中一個很重要的方面就是SQL語句的優化。對于海量數據,劣質SQL語句和優質
SQL語句之間的速度差別可以達到上百倍,可見對于一個系統不是簡單地能實現其功能就
可,而是要寫出高質量的SQL語句,提高系統的可用性。
在多數情況下,Oracle使用索引來更快地遍歷表,優化器主要根據定義的索引來提高性
能。但是,如果在SQL語句的where子句中寫的SQL代碼不合理,就會造成優化器刪去索引
而使用全表掃描,一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應
清楚優化器根據何種原則來刪除索引,這有助于寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中
,即使某些列存在索引,但是由于編寫了劣質的SQL,系統在運行該SQL語句時也不能使
用該索引,而同樣使用全表掃描,這就造成了響應速度的極大降低。
1. IS NULL 與 IS NOT NULL
不能用null作索引,任何包含null值的列都將不會被包含在索引中。即使索引有多列這
樣的情況下,只要這些列中有一列含有null,該列就會從索引中排除。也就是說如果某
列存在空值,即使對該列建索引也不會提高性能。
任何在where子句中使用is null或is not null的語句優化器是不允許使用索引的。
2. 聯接列
對于有聯接的列,即使最后的聯接值為一個靜態值,優化器是不會使用索引的。我們一
起來看一個例子,假定有一個職工表(employee),對于一個職工的姓和名分成兩列存
放(FIRST_NAME和LAST_NAME),現在要查詢一個叫比爾.克林頓(Bill Cliton)的職工
。
下面是一個采用聯接查詢的SQL語句,
select * from employss
where
first_name||''||last_name ='Beill Cliton';
上面這條語句完全可以查詢出是否有Bill Cliton這個員工,但是這里需要注意,系統優
化器對基于last_name創建的索引沒有使用。
當采用下面這種SQL語句的編寫,Oracle系統就可以采用基于last_name創建的索引。
Select * from employee
where
first_name ='Beill' and last_name ='Cliton';
遇到下面這種情況又如何處理呢?如果一個變量(name)中存放著Bill Cliton這個員工
的姓名,對于這種情況我們又如何避免全程遍歷,使用索引呢?可以使用一個函數,將
變量name中的姓和名分開就可以了,但是有一點需要注意,這個函數是不能作用在索引
列上。下面是SQL查詢腳本:
select * from employee
where
first_name = SUBSTR('&&name',1,INSTR('&&name',' ')-1)
and
last_name = SUBSTR('&&name',INSTR('&&name’,' ')+1)
3. 帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的,要求在職工表中查詢名字中包
含cliton的人。可以采用如下的查詢SQL語句:
select * from employee where last_name like '%cliton%';
這里由于通配符(%)在搜尋詞首出現,所以Oracle系統不使用last_name的索引。在很
多情況下可能無法避免這種情況,但是一定要心中有底,通配符如此使用會降低查詢速
度。然而當通配符出現在字符串其他位置時,優化器就能利用索引。在下面的查詢中索
引得到了使用:
select * from employee where last_name like 'c%';
4. Order by語句
ORDER BY語句決定了Oracle如何將返回的查詢結果排序。Order by語句對要排序的列沒
有什么特別的限制,也可以將函數加入列中(象聯接或者附加等)。任何在Order by語
句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order by語句以找出非索引項或者表達式,它們會降低性能。解決這個問題的
辦法就是重寫order by語句以使用索引,也可以為所使用的列建立另外一個索引,同時
應絕對避免在order by子句中使用表達式。
5. NOT
我們在查詢時經常在where子句使用一些邏輯表達式,如大于、小于、等于以及不等于等
等,也可以使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取
反。下面是一個NOT子句的例子:
... where not (status ='VALID')
如果要使用NOT,則應在取反的短語前面加上括號,并在短語前面加上NOT運算符。NOT運
算符包含在另外一個邏輯運算符中,這就是不等于(<>)運算符。換句話說,即使不在
查詢where子句中顯式地加入NOT詞,NOT仍在運算符中,見下例:
... where status <>'INVALID';
再看下面這個例子:
select * from employee where salary<>3000;
對這個查詢,可以改寫為不使用NOT:
select * from employee where salary<3000 or salary>3000;
雖然這兩種查詢的結果一樣,但是第二種查詢方案會比第一種查詢方案更快些。第二種
查詢允許Oracle對salary列使用索引,而第一種查詢則不能使用索引。
6. IN和EXISTS
有時候會將一列和一系列值相比較。最簡單的辦法就是在where子句中使用子查詢。在w
here子句中可以使用兩種格式的子查詢。
第一種格式是使用IN操作符:
... where column in(select * from ... where ...);
第二種格式是使用EXIST操作符:
... where exists (select 'X' from ...where ...);
我相信絕大多數人會使用第一種格式,因為它比較容易編寫,而實際上第二種格式要遠
比第一種格式的效率高。在Oracle中可以幾乎將所有的IN操作符子查詢改寫為使用EXIS
TS的子查詢。
第二種格式中,子查詢以‘select 'X'開始。運用EXISTS子句不管子查詢從表中抽取什
么數據它只查看where子句。這樣優化器就不必遍歷整個表而僅根據索引就可完成工作(
這里假定在where語句中使用的列存在索引)。相對于IN子句來說,EXISTS使用相連子查
詢,構造起來要比IN子查詢困難一些。
通過使用EXIST,Oracle系統會首先檢查主查詢,然后運行子查詢直到它找到第一個匹配
項,這就節省了時間。Oracle系統在執行IN子查詢時,首先執行子查詢,并將獲得的結
果列表存放在在一個加了索引的臨時表中。在執行子查詢之前,系統先將主查詢掛起,
待子查詢執行完畢,存放在臨時表中以后再執行主查詢。這也就是使用EXISTS比使用IN
通常查詢速度快的原因。
同時應盡可能使用NOT EXISTS來代替NOT IN,盡管二者都使用了NOT(不能使用索引而降
低速度),NOT EXISTS要比NOT IN查詢效率更高。
posted @
2008-07-23 10:24 Ken.Lee 閱讀(2129) |
評論 (2) |
編輯 收藏