SlideShare uma empresa Scribd logo
1 de 45
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
第二章 Oracle 伺服器
前言
雖然 Oracle 資料庫是全世界第一個關聯式資料庫,但它畢竟是一個商業用的資料庫軟體,會
適度地修改或捨棄某些關聯式理論,以因應整個產業環境的變化。因此在學習與操作 Oracle
資料庫時,必須以 Oracle 公司所提供的建議為主,關聯式資料庫的理論為輔。本章的主要目
的就是要讓資料庫管理者了解 Oracle 資料庫的專有名詞,與 Oracle 資料庫的運作原理,幫助
資料庫管理者可以更快地學習及了解 Oracle 資料庫。
2.1 Oracle 伺服器(Oracle Server)
Oracle 伺服器是由執行處理(Instance)與資料庫(Database)所組成。其中執行處理是所謂的關
聯式資料庫管理系統(RDBMS-Relational Database Management System),提供相關的資料
庫管理功能。而資料庫則為 Oracle 資料庫檔案所組成,用來儲存資料。執行處理可以進一步
地細分為:系統整體區域(System Global Area)與背景處理作業(Background Processes)。
資料庫也可以再細分為:資料檔(Datafile)、控制檔(Control file)、線上重做日誌檔(Online
Redo Log file)。其中執行處理的系統整體區域(SGA)是使用作業系統的記憶體空間,而背景
處理作業則需使用到中央處理器(CPU)與記憶體的資源,而組成資料庫檔案則是放在磁碟機。
為什麼要使用這種架構呢?這必須由整個電腦系統的硬體架構看起,一個典型的電腦伺服器
硬體由中央處理器(Cpu)、記憶體(Ram)與磁碟機(Disk)所組成,其中依存取速度來排序為
CPU > RAM > Disk。因為中央處理器所內建的記憶體空間太小,不適合存放大量的資料。
因此可用來放置資料的結構只剩下記憶體與磁碟機。若所有資料都放在記憶體,資料操作的
速度較磁碟機快。但若伺服器發生某種問題,造成伺服器關閉。將可能導致存放在記憶體的
資料全數遺失。但若資料將全部都存放在磁碟機,即便伺服器發生某種問題,造成伺服器關
閉。也可以保證資料不會遺失(當然若是磁碟機發生問題,就另當別論,需要資料庫備份,方
能保證資料不會遺失),不過問題是磁碟機的存取速度太慢。因此 Oracle 伺服器將資料操作都
設計在執行處理進行,而資料則存放在資料庫。這樣的架構可以利用到記憶體的存取速度快
於磁碟機的好處,又可以利用磁碟機的保存性比記憶體佳的優點。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
在一個安裝 Oracle 資料庫軟體的電腦伺服器之上,可以同時啓動多個 Oracle 伺服器,只要這
台伺服器的硬體資源足夠即可。更甚至於可以在同一台電腦伺服器中,安裝多個不同版本的
Oracle 資料庫軟體,進而同時啓動多個不同版本的 Oracle 伺服器。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.2 執行處理(Instance)
執行處理是由系統整體區域(System Global Area)與許多的背景處理作業(Background
Processes)所組成。系統整體區域(縮寫為 SGA)由許多的不同用途的共用記憶體元件所組成,
例如:共用集區(Shared Pool)、緩衝區快取(Buffer Cache)、日誌緩衝區(Log Buffer)、大
型集區(Large Pool)、串流集區(Streams Pool)與 Java 集區(Java Pool)等等。而共用(Share)
的意義是表示系統整體區域可以被所有的背景處理作業與伺服器處理作業(Server process)讀
寫。
背景處理作業由許多不同功能的處理作業所組成,其中常見的:SMON、PMON、DBWR、
LGWR、CKPT、ARCH 等等。為何稱為背景(Background)?是因為這些處理作業在啟動後,
會依據事先所設定的情況,自動進行某些特定的操作(例如:DBWR 會自動將髒緩衝(Dirty
Buffer)寫回資料檔),不需要資料庫管理者介入。而且每個背景處理作業的功能彼此間不會重
複,而且有時後它們需要互相合作來完成某些操作(例如:檢查點事件(Checkpoint event)須
由 CKPT 與 DBWR 一起完成)。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.2.1 系統整體區域(System Global Area)
系統整體區域(為節省篇幅,以下縮寫為 SGA)事實上由多個共用記憶體元件所組成,以下將
介紹常見而且重要的共用記憶體區域元件。同時每個 SGA 至少要有共用集區、緩衝區快取與
日誌緩衝區這三個共用記憶體元件。
共用集區(Shared pool)
共用集區是 SGA 中相當重要的一部份,而共用集區的大小是由 SHARED_POOL_SIZE 設定,
但是個別的子元件大小,例如程式庫快取(Library Cache)、資料辭典快取(Data Dictionary
Cache)、結果集快取(Result Cache)的大小,由 Oracle 執行處理自行依照系統狀態動態調整。
程式庫快取(Library Cache)
程式庫快取(Library Cache)中存放最近用過的 SQL 敘述句或 PL/SQL 區塊的本文(Text)、
解析樹(Parse Tree)與執行計畫(Execution Plan)。主要的用途是希望當下一次執行相同的
SQL 敘述句或 PL/SQL 區塊時,可以直接由程式庫快取找到之前以使用過的執行計劃。而不
需要再次解析相同的 SQL 敘述句或 PL/SQL 區塊,因為解析相當消耗系統的資源。如此整
個資料庫的效能(Performance)將會更好、而擴充性(Scalability)也會更佳, 。
資料辭典快取(Data Dictionary Cache)
資料辭典快取(Data Dictionary Cache)存放最近用到的物件定義,而這些定義的來源是資料
庫的資料辭典(Data Dictionary)。當解析 SQL 敘述句時,首先需要知道所參考的表格或索引
的相關定義。因此先搜索程式庫快取,希望能夠找到這些物件的相關定義。若沒有在程式庫
快取中找到所需的資料,接著便會搜索資料辭典快取,看看所需的資料是否存在資料辭典快
取中。如果還是找不到所需的物件定義,則必須到資料辭典找到所需要的物件定義,然後將
它們讀到資料辭典快取,再將那些物件定義讀到程式庫快取,最後才開始進行解析。
從以上的敘述,便可以知道資料辭典快取是來減少因為硬解析(Hard Parse)所產生的實體讀取
(Physical Read)。因為解析所需的物件定義已經存在於資料辭典快取,此時的讀取為邏輯讀
取(Logical Read),其讀取的速度較快且成本較低。
結果集快取(Result Cache)
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
結果集快取(Result Cache)是 Oracle Database 11g 新增的記憶體元件,它用來放 SQL 敘述
句的執行結果。當使用者再次執行相同的 SQL 敘述句時,如果之前的執行結果有被快取在結
果集快取中,這時就不需經過解析與執行,便可以直接由結果集快取中取得執行結果。因此
SQL 敘述句的反應速度將變得更快,而且對 Oracle 伺服器來說,所消耗的資源也最少。
雖然結果集快取的最大值可以由 RESULT_CACHE_MAX_SIZE 設定,但因為結果集快取為
用共用集區的子元件。因此還是使用共用集區的空間,所以這個參數的大小不能超過
SHARED_POOL_SIZE 的 75%。
緩衝區快取(Buffer Cache)
用來存放最近使用過的資料區塊(Data Block),當未來需要使用相同的資料區塊時,就不需要
再從資料檔中讀取一次,而直接就由緩衝區快取即可得到所要的資料區塊。所以緩衝區快取
將邏輯地切割為一塊塊的緩衝(Buffer),每個緩衝同時只能存放一個與緩衝相同大小的資料區
塊。Oracle 資料庫允許多達 5 種的資料區塊大小(2K/4K/8K/16K/32K),所以當資料區塊
大小不同時,緩衝區快取也必須有相同大小的緩衝存在,才能放置這些不同大小的資料區塊。
緩衝區快取是多個子緩衝區的統稱,DB_CACHE_SIZE、DB_KEEP_CACHE_SIZE、
DB_RECYCLE_CACHE_SIZE 以標準區塊為切割單位,而 DB_2K_CACHE_SIZE 的緩衝為
2K 的大小,此外還有 DB_4K_CACHE_SIZE、DB_8K_CACHE_SIZE、
DB_16K_CACHE_SIZE 與 DB_32K_CACHE_SIZE 等。
若無法在緩衝區快取找到所需的資料區塊,則必須先將資料區塊由資料檔讀到緩衝區快取,
之後才能進行後續的操作,而這種資料區塊的讀取動作稱為實體讀取(Physical Read)。若可
以由緩衝區快取讀取所要的資料區塊,這種動作稱為邏輯讀取(Logical Read)。由於以存取速
度而看,記憶體的速度遠快於磁碟機,緩衝區快取的存在可以大幅減少實體讀取的數量,因
此可以提昇資料庫伺服器的效能。
日誌緩衝區(Log Buffer)
為保證已確認交易(committed transaction),在 Oracle 伺服器發生問題後,可以被復原。因
此每次伺服器處理作業(Server Process)進行資料異動之前,會先產生關於這個異動的重做項
目(Redo Entry),並先將重做項目複製到日誌緩衝區,之後伺服器處理作業才進行資料的異動。
至於日誌緩衝區的重做項目將由日誌寫入器(LGWR)寫到線上重做日誌檔(Online Redo
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
Logfile)中。若執行處理發生問題而崩潰(Crash),只要在下次重新啟動執行處理時,依照線
上重做日誌檔的重做項目,重新執行一次,便可以已經確認的交易全數復原。
為何不直接將重做日誌寫到線上重做日誌檔,卻要先將重做項目複製到日誌緩衝區暫存?因
為先產生重做項目後,才能進行異動。而記憶體的存取速度比磁碟機快,這種架構可以減少
執行 SQL 敘述句之前的等待重做項目寫入的時間。
若在重做項目被寫到線上重做日誌檔之前,執行處理便先崩潰,而導致日誌緩衝區的所有重
做項目遺失,難道不會有些已經確認的交易無法復原?這個問題是不可能發生的,因為執行
處理要求交易確認前,必須將交易確認的重做日誌寫到線上重做日誌檔後,才會回覆交易已
確認的訊息給使用者。也就是說當使用者看到交易已確認的訊息時,該交易的重做項目一定
已經被寫到線上重做日誌檔。所以即便執行處理突然中止運行,已經確認的交易還是可以透
過重做日誌檔的重做項目來復原。但如果執行處理不正常的中止時,那些尚未被寫到線上重
做日誌檔的重做項目一定屬於目前進行中的交易(尚未確認的交易),既然是未確認,無法復原
也無所謂。
而重做項目到底是什麼?其實重做項目是由一些記錄所組成,這些記錄包含異動發生在哪個
資料區塊的哪個資料列,以及異動後的值與異動的操作型態。所以當需要復原時,可以透過
重做項目將異動重新復原。
日誌緩衝區的大小是由 LOG_BUFFER 這個參數決定的,這邊需要提醒的是 LOG_BUFFER
的大小必須是檔案系統區塊(通常為 512/1024 bytes)的倍數。可以由以下的 SQL 敘述句得
知目前所使用的檔案系統的區塊大小為何?
SQL> SELECT max(lebsz) log_blk_size FROM sys.x$kccle;
LOG_BLK_SIZE
---------------------
512
這表示目前所使用的Logfile Block為512 Bytes
大型集區(Large Pool)
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
這個元件不是必要存在的共用記憶體元件,只是在某些狀況下,執行處理需要這個共用記憶
體元件來減輕共用集區的競爭。因為如果沒有設定大型集區,但使用到需要大型集區的操作
時,執行處理將使用共用集區來代替大型集區。
若有下列幾種情況,建議需要額外設定大型集區,以免造成共用集區的過度使用,造成共用
集區的空間競爭更加嚴重,造成執行處理的效能問題。
• 當使用共用伺服器(Shared Server)架構時,階段作業(Session)的使用者整體區域
(User Global Area)將存放在大型集區,以方便所有的共用伺服器作業(Shared Server
Process)存取。
• 使用 Oracle XA Interface 功能時。
• 使用 I/O Slave 模擬非同步 I/O 功能時,此時大型集區將被當作 I/O 緩衝區使用。
• 當使用復原管理程式(Recovery Manager)進行備份(Backup)與回存(Restore)操作時,
用來當作 I/O 緩衝區使用。
• 當使用平行查詢(Parallel Query)時,平行查詢處理作業(Parallel Query Process)彼此
交換訊息的地方。
大型集區的大小可以由 LARGE_POOL_SIZE 設定,可設定的大小由 300KB 到至少 2GB 以
上(依作業系統不同而有所差異)。
JAVA 集區(Java Pool)
用來提供記憶體空間給 Java 虛擬機器(Java Virtual Machine)使用。JAVA 集區的大小是由
JAVA_POOL_SIZE 參數來設定的。
串流集區(Streams Pool)
Oracle 串流(Oracle Streams)是 Oracle Database 10g 開始提供的功能,用在資料庫與資料
庫之間進行資訊分享(Information Sharing)。如果沒有用到 Oracle 串流,則不需要設定此空
間。
串留集區的大小是由參數 STREAMS_POOL_SIZE 所決定的。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.2.2 背景處理作業(Background Process)
每個執行處理啓動時,會同時啟動許多的背景處理作業(Background Process)。其中有五個
背景處理作業一定要被啟動,如果有這五個中任一背景處理作業無法啟動,則該執行處理也
無法啟動。然而即便執行處理已經啟動,這五個背景處理作業中的任一個因為發生錯誤而中
止運行,也會導致執行處理崩潰(Crash)。這五個重要的背景處理作業為 SMON、PMON、
DBWR、LGWR、CKPT。此外正常的 Oracle11g 執行處理還有其他的背景處理作業,如
ARCH、MMON、REC0、VKTM、DIAG、DBRM、MMAN、MMNL、FBDA、SMCO、
QMNC 等等,不過這些背景處理作業不是絕對必要存在,如果這些背景處理作業發生問題,
最多只是某些功能受到影響無法使用,而不會導致執行處理崩潰。
背景處理作業在 UNIX 平台上為一個獨立的行程(Process),行程的名字格式為 ora_背景處理
作業名字_執行處理名字,例如執行處理名字為 orcl,則可以使用 UNIX 作業系統的指令 ps -
ef|grep orcl 查詢與 orcl 執行處理相關的行程。
而 Windows 平台上的背景處理作業為 oracle.exe 內的執行緒。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
系統監督(System Monitor-SMON)
當每次執行處理被重新啟動,在掛載資料庫到開啓資料庫的過程,SMON 會檢查資料庫是否
為正常關閉。如果是不正常關閉,則會啓動執行處理復原(Instance Recovery)的機制,來復
原資料庫中所有已確認的交易,並退回(Rollback)未確認的交易。這是 SMON 最為人所知的
功能。
其實除執行處理復原外,SMON 需要處理相當多的狀況,以下為一些常見的操作。
• 每五分鐘進行回收可用的擴充區塊(Free Extent)或將相鄰的可用擴充區塊合併為一個
較大的可用擴充區塊,不過這是功能僅能在說明管理表格空間(Dictionary Managed
Tablespace)進行。
• 每兩小時清理一次暫時區段(Temporary segment),這個操作只有在暫時區段被放在
永久型態的表格空間(Permanent Tablespaces)才會發生。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
• 更新 SMON_SCN_TIME 中,系統改變號碼(System Change Number-SCN)與時間戳
記(TIMESTAMP)的對應資料,用在使用回溯(Flashback)功能的時候,可以用時間戳
記來代替系統改變號碼。Oracle Database 9i R2 為每 5 分鐘一次,Oracle Database
10g 以後為每 6 秒鐘一次。系統改變號碼為一個數字,用來表示重要事件發生的先後
順序,數字越大表示發生順序越後面。自資料庫建立後,由 SCN 開始由 1 遞增,每次
增加 1。每秒鐘裡最多可以產生 16284 次遞增,因為每個 SCN 佔 6 個 bytes 空間,
所以可以保證在 500 年內不會用玩。
• 每十二小時將 OBJ$中不存在的物件資訊清除一次。
• 每一小時檢查 IND$中是否有因為線上重建索引(rebuild index online)失敗所殘留內容。
• 每十二小時對還原區段(Undo Segment)進行收縮一次,就是將還原區段中可用的擴充
區塊收回。將狀態為”Pending Offline”的還原區段,再試圖離線(Offline)一次。
• 在真實應用程式叢集(Real Application Cluster-RAC)架構下,如果其中一個執行處理
突然崩潰,其他執行處理的 SMON 會對崩潰的執行處理進行執行處理復原,將已經確
認的交易復原與退回未確認的交易。
處理作業監督(Process Monitor-PMON)
PMON 是監控其他處理作業(Background Process 或 Server Process)的狀態,當有異常情
況發生,則會進行相對的復原動作。
• PMON 會定期發送訊息給使用者處理作業(User Process),當某個使用者處理作業很
久都沒有回應訊息,PMON 便會認定這個使用者處理作業已經死去。因此會退回該階
段作業進行中的交易,釋放已握有的鎖定(Lock)及相關的資源。
• 當 PMON 發現某個共用伺服器處理作業(Shared Server Process)或分配器
(Dispatcher)突然終止時,它會重新啓動一個新的共用伺服器處理作業或分配器。
• PMON 啓動後,會將執行處理的資訊向監聽器(LISTENER)註冊,並定時更新執行處
理的負載(Workload)資訊。如果有分配器存在,PMON 也會一併向監聽器註冊分配器
的相關資訊。至於向那些監聽器註冊,則依據 LOCAL_LISTENER 的設定,如果沒有
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
設定 LOCAL_LISTENER 參數,PMON 會自動向執行處理所在的機器,監聽 TCP 協
定 1521 埠的監聽器註冊。
資料庫寫入器(Database Writer-DBWR)
DBWR 的唯一功能就是將緩衝區快取的髒緩衝(Dirty Buffer)寫回到資料檔。在多 CPU 架構
下,可以啓動多個 DBWR 處理作業來管理緩衝區快取,最多可以有 20 個 DBWR。
何謂髒緩衝?因為緩衝區快取的內容都是伺服器處理作業由資料檔讀入的資料區塊,所以剛
讀入的緩衝內容應該與資料檔的資料區塊內容一致。但是經過 DML 敘述句的異動後,伺服器
處理作業將會修改緩衝的資料列內容,因而造成緩衝的內容與資料檔的資料區塊內容不一致
的情況,這種緩衝便稱為髒緩衝。
某些情況發生時,DBWR 會將某些髒緩衝的內容寫回(Write Back)資料檔,如果寫回動作完
成後,這些緩衝被稱做乾淨緩衝(Clean Buffer),因為緩衝的內容與資料區塊的內容一致。
何時 DBWR 會將髒緩衝的內容寫回資料檔:
• 緩衝區快取內有太多的髒緩衝存
當伺服器處理作業執行一個 SQL 敘述句時,首先會檢查其所需的資料區塊是否都已經
存在於緩衝區快取。如果存在則進行後續的操作。倘若所需的資料區塊無論是全部或
部份不在緩衝區快取,伺服器處理作業必須先將那些資料區塊由資料檔讀入緩衝區快
取。不過在讀取資料區塊之前,要先確定緩衝區快取內有足夠的可使用緩衝(可使用緩
衝包含乾淨緩衝、可用緩衝(Fee Buffer)與未使用緩衝(Unused Buffer),可以用來存
放由資料檔讀入的資料區塊。
注意:可用緩衝與未使用緩衝是相同意義,都表示緩衝內沒有任何資料存在。為統一
名詞,往後都使用可用緩衝。
因此伺服器處理作業搜尋可使用緩衝時,將由 LRU 串列(LRU List)的 LRU(Least
Recently Used)端開始向 MRU 端(Most Recently Used)尋找。如果在搜尋的過程中遇
到髒緩衝,便會將其移到檢查點佇列(Checkpoint Queue)。如果因此造成檢查點佇列
的髒緩衝數量超過其可容納數量,則伺服器處理作業會停止繼續搜尋可用緩衝的動作,
轉而呼叫 DBWR 將檢查點佇列的所有髒緩衝都寫回資料檔。因此伺服器處理作業會等
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
待 DBWR 進行寫入操作,當寫入操作完成後那些髒緩衝都變成乾淨緩衝,而且被移到
LRU 串列的 LRU 端。這時伺服器處理作業再次搜尋 LRU 串列,便順利地取得所需要
的可用緩衝。
注意:Oracle 伺服器使用 LRU 串列與檢查點佇列(Checkpoint Queue)來管理緩衝區
快取,每個緩衝同一時間只能位於一種串列之上(LRU List 或 Checkpoint Queue)。
不過檢查點佇列只能放置髒緩衝,髒緩衝則依被弄髒的時間排序。而 LRU 串列中可以
放置乾淨緩衝、髒緩衝、可用緩衝。每個位於 LRU 串列的緩衝依其最近被存取的時間
及次數排列,最近被存取的緩衝比最近未被存取的緩衝,更靠近 MRU 端。越靠近
LRU 端表示該緩衝的內容比其他更靠近 MRU 端的緩衝來說,其存取的時間比較早。
• 緩衝區快取的可使用緩衝數量太少
當伺服器處理作業開始尋找 LRU 串列的可使用緩衝之前,會先設定此次搜尋所能讀取
的最多緩衝數量。如果達到搜尋的最大個數依舊未找到足夠的可使用緩衝時,伺服器
處理作業會呼叫 DBWR 將檢查點佇列的髒緩衝全數寫回資料檔。將髒緩衝變為乾淨緩
衝後,再重新再尋找可使用緩衝,這時應該就可以順利地找到所需數量的可用緩衝。
• 當檢查點事件(Checkpoint)發生,CKPT 會要求 DBWR 將某些數量的髒緩衝寫回資料
檔。
• 每經過三秒鐘 DBWR 會自動將 LRU 串列裡部份的髒緩衝移到檢查點佇列,並將檢查
點佇列中的髒緩衝全數寫回資料檔。因為隨時都有可能有伺服器處理作業需要可使用
緩衝來容納由資料檔所讀入的資料區塊,如果能由 DBWR 並時產生一些可使用緩衝。
讓伺服器處理作業快速找到所需的可使用緩衝,不需要等待 I/O 操作,這樣可以減少
執行 SQL 敘述句的反應時間。
日誌寫入器(Log Writer-LGWR)
LGWR 的責任是將日誌緩衝區(Log Buffer)的重做項目(Redo Entry)寫到線上重做日誌檔中。
一但 LGWR 開始進行寫入操作,它會將所有尚未被寫到線上重做日誌檔的重做項目,都寫到
線上重做日誌檔。
以下為 LGWR 被觸發而進行寫入的情況:
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
• 當使用者要求確認(commit)交易時,伺服器處理作業(Sever Process)先將確認資訊寫
到日誌緩衝區,之後 LGWR 將立刻被觸發,將日誌緩衝區內尚未寫到線上重做日誌檔
的所有重做項目都寫到線上重做日誌檔。
• 日誌緩衝區內尚未被寫到線上重做日誌檔的重做項目,其所佔的空間已超過 1MB 或
1/3 以上的日誌緩衝區大小,LGWR 也會被觸發開始將重做項目寫到線上重做日誌檔。
• LGWR 每三秒會自動觸發寫入動作。
• 當 DBWR 將某些髒緩衝寫回資料檔之前,若髒緩衝的相關重做項目尚未寫到線上重做
日誌檔。這時執行處理先要求 LGWR 將重做項目寫到線上重做日誌檔,之後才允許
DBWR 將那些髒緩衝寫回資料檔。
檢查點(Checkpoint-CKPT)
當檢查點事件發生時,CKPT 會要求 DBWR 將某些髒緩衝寫回到資料檔,當 DBWR 完成工
作後,CKPT 會將檢查點資訊(Checkpoint Information)寫到控制檔(Controlfile)及資料檔標
頭(Datafile Header)。同時每 3 秒符 CKPT 會將重做位元組位置(Redo Byte Address)記錄到
控制檔中,所以當發生執行處理復原(Instance Recovery)時,便可以由控制檔所記錄的重做
位元組位置,讀取線上重做日誌檔的重做項目(Redo Entry),進行執行處理復原。
注意:重做位元組位置(Redo Byte Address)為當進行執行處理復原時,SMON 需要由線上重
做日誌檔的哪個位置開始讀取重做項目,這個位置其實是檢查點佇列裡最老的髒緩衝的最早
產生的重做項目在線上重做日誌檔的位置。從這個位置開始復原,一直到所有的重做項目都
已經重做完成,便保證所有的髒緩衝都能被復原。
何時會發生檢查點事件:
• 資料庫正常關閉
資料庫管理者使用 SHUTDOWN {NORMAL|TRANSACTIONAL|IMMEDIATE}關閉資
料庫。這些關閉指令會要求 DBWR 將所有的髒緩衝寫到資料檔,與要求 LGWR 將所
有的重做項目寫到線上重做日誌檔。當所有寫入動作都完成後,CKPT 才將檢查點資
訊寫到控制檔與資料檔標頭。之後才關閉資料檔與線上重做日誌檔。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
• 進行日誌檔切換(Logfile Switch)
這時以被切換的日誌群組的最後一個重做項目的 SCN 為基準,要求在此 SCN 之前已
經成為髒緩衝的緩衝,都必須變成乾淨緩衝。當 DBWR 完成所有的寫入動作後,
CKPT 會將檢查點資訊寫到控制檔與資料檔標頭,同時此日誌群組的狀態也設定為
INACTIVE,表示該日誌群組已經完成檢查點。
• 資料庫管理者執行 ALTER SYSTEM CHECKPOINT 指令
這個指令會要求所有的髒緩衝都必須被寫回資料檔。當寫入完成後,CKPT 會將檢查
點資訊寫到控制檔與資料檔標頭。
• 資料庫管理者執行 ALTER TABLESPACE tsname {OFFLINE|READ ONLY|BEGIN
BACKUP}
DBWR 會將屬於該表格空間的髒緩衝寫回資料檔。當 DBWR 完成這些寫入動作後,
CKPT 只會將檢查點資訊寫到該表格空間的資料檔標頭,而不會寫到控制檔。
因為並沒有將所有的髒緩衝都寫回資料檔,此種檢查點被稱做遞增檢查點(Incremental
Checkpoint)。
• FAST_START_MTTR_TARGET
如果資料庫管理者想要確保執行處理復原(Instance Recovery)的完成時間,可以將
FAST_START_MTTR_TARGET 設為所接受的秒數。這時執行處理會計算出緩衝區快
取內最多可允許幾個髒緩衝,這樣當執行處理崩潰(Instance Crash)時,才能保證執行
處理復原(Instance Recovery)可以在要求的期限內完成。因此 CKPT 每 3 秒鐘會檢查
一次髒緩衝的數量是否超過,如果超過限制,CKPT 會要求 DBWR 將超過數量的髒緩
衝寫回資料檔,讓緩衝區快取內髒緩衝的數量低於 FAST_START_MTTR_TARGET
的限制。這樣當進行執行處理復原時,所需要復原的髒緩衝數量便會減少,因此執行
處理復原的時間也就同步減少了。但是這種檢查點事件並不會將所有的髒緩衝寫回資
料檔,因此也稱為遞增檢查點(Incremental Checkpoint)。
當此種檢查點事件完成後,CKPT 只會將檢查點資訊寫到控制檔,不會寫到資料檔中。
這個參數值越小,CKPT 所造成 I/O 量就越大,可能會造成 I/O 超過資料庫系統的極
限,導致整體資料庫效能下滑,但是卻可以保證執行處理復原越快完成。若
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
FAST_START_MTTR_TARGET 越小,所造成的 I/O 量就越小,對整體資料庫效能的
影響就越小,但執行處理復原越慢才能完成。所以資料庫管理者要小心的設定此參數。
自動檢查點調校(Automatic Checkpoint Tuning)
Oracle Database10g 開始,資料庫管理者可以藉由不設定 FAST_START_MTTR_TARGET
參數,讓執行處理自動根據資料庫的 I/O 容量來決定要將多少個髒緩衝寫回資料檔。當目前
資料庫 I/O 量較大的時候,則寫回資料檔的髒緩衝數量就減少一點。但是如果目前資料庫的
I/O 數量不多,則 CKPT 會要求寫回多一點的髒緩衝。因此不會讓整體的 I/O 量超過資料庫
系統所能承受的極限,也不會造成 I/O 瓶頸發生。不過這時 Oracle 伺服器便不能保證執行處
理復原能夠在多少秒內完成,僅能說盡快完成。但是若明確地將
FAST_START_MTTR_TARGET 設為 0,則關閉自動檢查點調校的功能。
存檔器(Archiver-ARCH)
ARCH 的工作只有將線上重做日誌檔(Online Redo Logfile)複製為存檔日誌檔(Archived
Logfile)。這個存檔的動作只有當資料庫為為存檔日誌模式(Archive Log Mode)時,才會進行
此種操作。ARCH 行程的個數可由參數:LOG_ARCHIVE_MAX_PROCESSES 設定,在
Oracle Database 11g 最多可以有 30 個。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
1.3 其他的處理作業(Other Process)
雖然這些處理作業不屬於執行處理一部份,但是它們對使用者而言卻是最常接觸到的處理作
業,沒有它們使用者無法與執行處理溝通,這些處理作業稱為前景處理作業(Foreground
Process)。
2.3.1 使用者處理作業(User Process)
使用者處理作業指的是那些會產生 SQL 敘述句的應用程式,無論是 SQL*Plus 或任何使用者
自行開發的程式,只要能產生出 SQL 敘述句的程式,都稱做使用者處理作業。
2.3.2 伺服器處理作業(Server Process)
在專屬伺服器(Dedicated Server)模式下,每個使用者處理作業一定有一個專屬的伺服器處理
作業。這個伺服器處理作業代表使用者處理作業執行 SQL 敘述句,必要時回傳執行結果給使
用者處理作業。
在共用伺服器(Shared Server)模式下,每個使用者處理作業不會直接與伺服器處理作業連接,
而是連接到分配器(Dispatcher),每個分配器可以同時連接多個使用者處理作業。當使用者處
理作業有 SQL 敘述句需要執行時,它將 SQL 敘述句傳給分配器,但是分配器不負責執行
SQL 敘述句,因此分配器將 SQL 敘述句放到系統整體區域(System Global Area)的要求佇列
(Request Queue)中。放在要求佇列中的 SQL 敘述句,由事先啟動的共用伺服器作業處理們
(Shared Server Processes)依先進先出(First In First Out)的順序執行。當 SQL 敘述句執行
完成後,共用伺服器作業處理將執行結果傳給分配器所屬的反應佇列(Response Queue),而
分配器再傳給要求執行的使用者處理作業。因為伺服器處理作業不是專屬於某個使用者作業
系統,而是由使用者處理作業們共用,所以稱做共用伺服器模式。同時即便是同一個使用者
作業處理所產生的 SQL 敘述句,被分配器傳到要求佇列後,有極大的可能不是被同一個伺服
器處理作業執行。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.3.3 連線(Connection)
所謂的連線(Connect)是描述使用者處理作業與伺服器處理作業之間的連線方式,根據使用者
處理作業與伺服器處理作業的相對位置,有以下三種方式:
• 行程間通訊(Inter-Process Communication):使用者處理作業與伺服器處理作業位在
同一個作業系統中,兩個行程不需要透過網路便可以建立連線 。
• 主從架構(Client/Server):使用者處理作業與伺服器處理作業位在不同ㄧ個機器上,
兩個行程需要透過網路才可以建立連線。
• 三層式架構(3-Tier): 前端的使用者利用瀏覽器(Browser)連到應用程式伺服器
(Application Server),再由應用程式伺服器依據使用者的輸入資訊,產生出相對應的
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
SQL 敘述句,之後將 SQL 敘述句交由伺服器處理作業執行。在三層式架構下使用者
處理作業指的是應用程式伺服器,因為是由它產生 SQL 敘述句。
1.3.4 階段作業(Session)
當連線建立後,使用者處理作業接著將使用者帳戶(Username)與密碼(Password)傳給伺服器
處理作業要求建立一個階段作業(Session),而伺服器處理作業收到使用者帳號與密碼後,開
始進行使用者身分驗證,驗證通過後繼續確認該使用者是否有建立階段作業(CREATE
SESSION)的權限。如果使用者擁有 CREATE SESSION 的權限,則一個階段作業就此建立,
而此階段作業將一直持續直到使用者結束階段作業為止。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.4 資料庫(Database)
資料庫的結構可分為實體結構(Physical Structure)與邏輯結構(Logical Structure)。實體結
構為組成這個資料庫的實體檔案,共有以下三種型態:資料檔(Datafile)、控制檔(Controlfile)、
線上重做日誌檔(Online Redo Logfile)。而邏輯結構則是為讓資料庫的空間可以更有效率的使
用而產生的結構,邏輯結構先將資料檔的空間使用表格空間加以整合,再將表格空間的空間
分割為更小的單位:區段(Segment),而區段可以再細分為擴充區塊(Extent),擴充區塊再分
割為多個連續資料區塊(Data Block)。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.4.1 資料庫的實體結構(Physical Structure)
資料庫的實體結構為組成此資料庫的實體檔案,這些檔案有三種型態:資料檔、控制檔、線
上重做日誌檔。每種檔案都有不同的用途,而且缺一不可。
資料檔(Datafile)
從檔案的名稱就可以看出用途,用來放資料(Data)。不論是使用者所建立的表格(Table)、索
引(Index)、叢集(Cluster)、索引組織表格(Index Organized Table)等物件或執行處理所使用
的資料辭典(Data Dictionary),都放在資料檔內。在 Oracle Database 10g 之前,每個資料
庫至少需要 1 個資料檔,用來組成 SYSTEM 表格空間(System Tablespace)。從 Oracle
Database 10g 開始,每個資料庫至少需要 2 個資料檔,因為 Oracle Database 10g 有兩個
必要的表格空間(SYSTEM 與 SYSAUX),而每個表格空間至少要由一個資料檔組成,而同一
個資料檔只能屬於一個表格空間,所以 Oracle Database 10g 至少需要 2 個資料檔。
Oracle Database 11g 規定,每個資料庫最多不能有超過 65533 個資料檔存在,同時也不能
有超過 65533 個表格空間存在。
控制檔(Controlfile)
每個資料庫至少要有 1 個,最多不能超過 8 個控制檔存在。但不管有幾個控制檔,每個控制
檔的內容必須一致。而且當執行處理掛載(Mount)資料庫後,一直要到執行處理卸載
(Dismount)資料庫前,每份控制檔都要維持能夠被讀、寫(Read Write)的狀態。如果有任一
份控制檔因為某種原因無法被讀寫,則執行處理將因此而崩潰。所以建議控制檔應該要有兩
份以上,而且應該分別存放在不同磁碟控制卡所管理的不同磁碟機上,以免磁碟控制卡或磁
碟機發生毀損,導致所有的控制檔都遺失的情況發生。
為什麼控制檔這麼重要?需要維護這麼多份相同內容的檔案。主要是因為控制檔用來存放許
多資料庫相關的重要資訊,例如資料庫的實體結構,也就是此資料庫的資料檔與線上重做日
誌檔的位置。如果控制檔不小心全數遺失,則執行處理根本無法得知資料檔的位置,遑論能
夠存取資料檔的資料。
以下為控制檔內所儲存的重要資訊:
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
• 最多八個字的資料庫名字與十位數字組成的資料庫辨識號碼(Database Identifier-
DBID)。
• 資料庫的建立時間。
• 資料庫中所有表格空間的名字。
• 目前正在使用的日誌群組號碼(Log Group Number)與日誌順序號碼(Log Sequence
Number)。
• 檢查點資訊(Checkpoint Information),有關於資料庫與資料檔的兩種檢查點資訊。
• 日誌檔的歷史記錄。
• 使用復原管理程式(RMAN)所進行的備份及復原相關資訊。
在 Oracle Database 11g 的資料庫中,每個控制檔最大不能超過 20000 個資料區塊。
線上重做日誌檔(Online Redo Logfile)
線上重做日誌檔的內容是日誌緩衝區(Log Buffer)的重做項目(Redo Entry),這些內容是由
LGWR 所寫入,用在執行處理或資料庫需要被復原時,可以用來重新產生資料之用。也就是
說當 Oracle 伺服器是正常運行時,線上重做日誌檔根本沒有任何用處,只增加額外的成本(重
做項目的產生成本與 LGWR 將重做項目寫到線上重做日誌檔的 I/O 成本)。然而沒有任何人可
以(敢)保證 Oracle 伺服器永遠不會發生需要復原的錯誤。所以重做項目的產生及線上重做日
誌檔的存在,是絕對必要的。只是要如何面對它們呢?其實只要把握一個要點即可,”既要
馬兒好,又要馬兒不吃草”。也就是說在正常情況下,要讓它們的成本影響 Oracle 伺服器的
效能最少。但在需要復原時,它們卻可以提供最完整的復原,保證已經確認的交易不會遺失。
Oracle 資料庫至少需要兩個日誌群組(Log Groups),而每個日誌群組至少由一個日誌成員
(Log Member)組成。這裡所說的日誌成員就是之前所提到的線上重做日誌檔,所以每個資料
庫至少需要兩個線上重做日誌檔,不過這兩個日誌檔必須分屬不同的群組。日誌群組的個數
是由建立資料庫所使用的參數:MAXLOGFILES 決定,而每個日誌群組可以有幾個日誌成員
則有 MAXLOGMEMBERS 決定。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
建立資料庫後,如果日誌群組個數超過 MAXLOGFILES 的設定,Oracle Database 11g 會
自動增加這個設定值,以容納新增的日誌群組設定。一般來說 MAXLOGMEMBERS 也是如此,
不過 MAXLOGMEMBERS 最大值為 5,如果想要加入超過第 5 個日誌成員以上,則會出現
ORA-00357: too many members specified for log file, the maximum is 5。
多工(Multiplexing)
當儲存媒體錯誤(Media Failure),造成資料檔遺失時,可以透過之前對資料檔所做的備份與日
誌檔(存檔日誌檔與線上重做日誌)來復原資料檔。如果線上重做日誌檔、存檔日誌檔與資料檔
放在同一個磁碟機,那麼當發生儲存媒體錯誤時,可能同時失去的資料庫檔案為資料檔與日
誌檔。這時即便有資料檔的備份,但沒有足夠的日誌檔是無法復原資料檔。
那麼將線上重做日誌檔如同資料檔一般直接備份不就好了,可是線上重作日誌的內容不是最
新的重做項目,不論何時備份都無法備份到最新的重做項目(新產生的重做項目暫存在日誌緩
衝區)。因此線上重做日誌檔不適合使用備份的方式保護,所以 Oracle 執行處理要求 LGWR
將重做項目同時寫到同一個日誌群組的多個日誌成員上。
同時建議資料庫管理者將這些日誌成員分別放在不同磁碟控制卡所控制的不同磁碟機上。這
種架構稱為多工(Multiplexing),可以避免資料庫陷入單一點錯誤(Single Point Of Failure)的
危機。雖然越多的日誌成員,資料庫的安全保護越佳,但是 LGWR 寫入重作項目所需的時間
也越多,可能會影響到 Oracle 伺服器的效能,所以資料庫管理人員必須拿捏資料庫安全與效
能的最佳平衡。
1.4.2 邏輯結構(Logical Structure)
資料庫的邏輯結構主要用途是希望能夠更細微地管理、使用資料檔的空間,因為實體結構的
最小單位為一個檔案,對資料庫來說實在太大。因此 Oracle 將資料檔的空間邏輯地分割更小
的單位,以方便管理及提昇空間使用效率。
表格空間(Tablespace)
表格空間(Tablespace)由一個或多個資料檔組成的,主要用途是將資料檔的空間分割為更小
的單位。每個表格空間只能屬於一個資料庫,每個資料庫最多只能有 65533 個表格空間,但
Oracle11g 的資料庫最少要有兩個表格空間(SYSTEM 與 SYSAUX)資料庫。同時資料庫的所
有物件都放在表格空間中,例如︰物件定義存放在 SYSTEM 表格空間的資料辭典(Data
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
Dictionary)。如果該物件除了定義外,還需要額外的空間來放置此物件的資料,這些額外的
空間便稱之為區段(Segment),而該區段必須存在於某個表格空間之中。
區段(Segment)
區段並不是一種真正的空間結構,它只是一個集合,將屬於同一個物件的擴充區塊(Extent)集
合在一起成為一個單元就是區段。許多資料庫管理者所熟知的物件有相對應的區段,只是區
段的型態不同而已,例如表格(Table)、索引(Index)、叢集(Cluster)、索引組織表格(Index
Organized Table)、暫時(Temporary)、還原(Undo)等物件。
擴充區塊(Extent)
擴充區塊才是真正的空間配置主角。每當一個區段需要更多的空間時,資料庫將會配置一個
可用擴充區塊給該區段,以滿足該區段的空間需求。不過擴充區塊必須是由同ㄧ個資料檔的
連續資料區塊組成,而一個擴充區塊最小要由 2 個資料區塊組成。
以下為需要配置擴充區塊的幾種情況:
• 建立一個新的區段時,需要至少配置一個擴充區塊。
• 因為執行 DML 操作時,發現現有區段的可用空間不敷使用。因此將會要求配置一個可
用擴充區塊。
• 當資料庫管理者知道將有大量資料將被新增,可以在事先要求配置一些可用擴充區塊
給該區段,這樣可以避免未來因動態要求配置擴充區塊,而影響到資料新增的速度。
以下為需要收回擴充區塊的情形:
• 當區段被丟棄(Drop)時,所有配置給該區段的擴充區塊都將被收回。這些擴充區塊的
狀態將由已使用(Used)變為可用(Free),之後若有需要這些可用擴充區塊將配置給其他
的區塊使用
• 當區段被截斷(Truncate)時,除第一個擴充區塊外,該區段其他的擴充區塊都會被收
回。
• 當區段被縮小空間(Shrink Space)時,將會收回多餘的擴充區塊。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
• 資料庫管理者要求回收那些未曾用過的擴充區塊,指的是位在高水位標記(High Water
Mark)以上的擴充區塊。
資料區塊(Data Block)
資料區塊(Data Block)是資料庫 I/O 的最小單位,即便只想讀取某筆資料列(Row),但伺服器
處理作業還是必須將整個資料區塊讀到緩衝區快取(Buffer Cache)中,當然 DBWR 將髒緩衝
內容寫回到資料檔也是如此。為了讓資料庫整體的 I/O 動作更有效率,建議一個資料區塊的
大小應該是 OS 區塊的整數倍,可以使用的資料區塊大小為 2K、4K、8K、16K、32K 等五
種。在一般的作業環境下,常見的為 4K、8K、16K 三種。同時為了資料庫整體 I/O 的效率,
也可以一次讀取多個連續的資料區塊到緩衝區快取,可以使用
DB_FILE_MULTIBLOCK_READ_COUNT 設定在全表格掃描(Full Table Scan)或快速全索引
掃描(Fast Full Index Scan)時,一次讀取幾個資料區塊。
2.5 其他的相關檔案
Oracle 資料庫的實體結構雖然只有資料檔、控制檔、線上重做日誌檔這三種檔案,不過
Oracle 伺服器還需要一些其他型態的檔案,才能讓 Oracle 伺服器運行的更有效率。
2.5.1 密碼檔(Password File)
密碼檔存放被授與 SYSDBA、SYSOPER、SYSASM 等權限的使用者帳戶與密碼。當使用者
要求取得 SYSDBA、SYSOPER、SYSASM 權限時,首先將試圖使用作業系統驗證來判斷使
用者是否可以取得所要求的權限。如果使用者無法通過作業系統驗證,則必須提供使用者帳
戶與密碼,用來與密碼檔的使用者帳戶與密碼進行比對,若一致則讓使用者取得所要求的權
限。若不一致則出現權限不足的錯誤訊息。
2.5.2 參數檔(Parameter File)
每個執行處理都有一個生命週期。當執行處理被啓動後,就是其生命週期的開始,執行處理
的生命一直持續到這個執行處理被關閉,也表示這個執行處理的生命已經結束。資料庫管理
者重新啟動執行處理時,這個執行處理如何得知之前的執行處理所使用系統整體區域大小,
以及應該啟動那些背景處理作業,還有警示檔與追蹤檔的位置?
Oracle 伺服器將這些執行處理的相關設定儲存在參數檔中,因此執行處理關閉後,只要使用
相同的參數檔,便可以讓新啟動的執行處理與之前的執行處理有相同設定。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
依據參數檔的型態可分為 PFILE(Parameter File)-文字檔格式及 SPFILE(Server Parameter
File)-二進位格式(Binary)兩種,而由 Oracle Database 9i 開始 SPFILE 便成為預設的選項。
以 Oracle Database 11g 為例,可供設定的參數多達 289 個,資料庫管理者可由
V$SYSTEM_PARAMETER 得到執行處理目前所使用的參數值。若加上隱藏參數更多達
1920 個,所有的參數可由 X$KSPPI 與 X$KSPPCV 得到相關的資訊,所謂的隱藏參數是那
些參數名稱前面有加上”_”,例如:_disable_logging,不過這些參數通常不須特別設定,
也不建議使用,因為這些隱藏的參數不提供官方支援。同時每個參數都有預設值,所以不需
要也不應該在參數檔中設定每個參數,只要設定那些預設值不能滿足需求的參數即可。
--v$system_parameter的內容為Instance目前所使用的參數與餐數值
SQL> SELECT COUNT(*) FROM v$system_parameter;
COUNT(*)
-----------------
289
SQL> SELECT COUNT(*) FROM x$ksppi;
COUNT(*)
-----------------
1920
/*x$ksppi只有參數名稱,參數值則存放在x$ksppcv*/
SQL> SELECT n.indx,n.ksppinm,p.ksppstvl FROM x$ksppi n,x$ksppcv p
2 WHERE n.indx=p.indx AND n.ksppinm='_disable_logging';
INDX KSPPINM KSPPSTVL
------------------ --------------------------------- ------------------------------
678 _disable_logging FALSE
2.5.3 存檔日誌檔(Archived Logfile)
若資料庫為存檔日誌(Archive Log)模式,當日誌切換(Log Switch)發生時,ARCH 會將線上
重做日誌的內容複製為存檔日誌檔(Archived logfile)。因此當線上重做日誌檔(Online Redo
Logfile)的內容,因為日誌切換而被覆寫(Overwrite)後,則可由存檔日誌檔取得被覆寫的重做
項目。存檔日誌檔用在當資料庫發生儲存媒體錯誤(Media Failure)時,可以利用之前備份的資
料檔備份與日誌檔(存檔日誌檔與線上重做日誌檔)來復原已經毀損的資料檔內容。Oracle 公司
建議所有正式環境的資料庫都應該設定為存檔日誌模式。
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.5.4 警示日誌檔(Alert Logfile)
警示日誌檔記錄 Oracle 伺服器(執行處理與資料庫)所發生的重要事件,其內容依發生時間的
先後順序記載在警示日誌檔中,如執行處理啓動與關閉的時間、啟動執行處理時所使用的非
預設參數值、表格空間相關的操作記錄以及所發生的錯誤資訊(ORA-600、ORA-1578、
ORA-60 等)。不過警示日誌檔中的錯誤資訊只是簡要內容,詳細的錯誤訊息放在背景處理作
業所產生的追蹤檔中。警示日誌檔於 BACKGROUND_DUMP_DEST(11g 之前)或
DIAGNOSTIC_DEST(11g ADR)所指定的目錄,其檔案名稱格示為 alert_SID.log,SID 為執
行處理的名字(若執行處理名字為 orcl,則其警示日誌檔名字為 alert_orcl.log)。當有訊息需要
記錄到警示檔時,這些訊息將以建立或附加(Create or Append)的方式新增到警示日誌檔。
也就是若警示日誌檔已經存在,則將訊息附加到現有日誌檔的最後面。但若無法找到日誌檔,
這時將先建立新的警示日誌檔,並將訊息依序寫到警示日誌檔。
2.5.5 背景處理作業追蹤檔(Background Process Trace File)
背景處理作業追蹤檔是當伺服器處理作業或背景處理作業發生錯誤時,所記錄下來的詳細錯
誤資訊,有時甚至包含記憶體傾倒(Memory Dump)。這些訊息不是給資料庫管理者用來解決
目前的 Oracle 伺服器錯誤,而是提供 Oracle 公司的支援人員更詳細的資料庫錯誤資訊,用以
解決複雜的資料庫問題。背景處理作業追蹤檔將出現在 BACKGROUND_DUMP_DEST(11g
之前)或 DIAGNOSTIC_DEST(11g ADR)所指定的目錄下,以及檔案名稱格示為
SID_ProcessName_OsProcesSid.trc。SID 代表的是 Oracle Instance 的名字,
ProcessName 代表的是背景處理作業名稱縮寫,不過如果是由伺服器處理作業所產生的追蹤
檔,它的 ProcessName 為”ora”。UNIX 平台中 OsProcessSid 為該行程(Process)在作業
系統中的行程號碼,若在 Windows 平台中則為執行緒(Thread)的號碼。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
2.6 開啟或關閉執行處理
在 Oracle 伺服器架構中,所有儲存在資料庫內的資料,都必須透過執行處理才能被操作。如
果執行處理尚未開啟資料庫,此時資料庫使用者只能望資料庫興嘆,而不能存取、操作資料
庫的資料。
2.6.1 開啟執行處理
資料庫的所有資料都存放在資料檔內,資料庫使用者不能直接讀寫該資料檔的內容,必須使
用 SQL 敘述句,由伺服器處理作業透過執行處理才能存取或操作這些資料。而執行處理開啓
資料庫的過程可以分成三個階段:未掛載(NOMOUNT)、掛載(MOUNT)、開啟(OPEN),這三
種階段分別代表著執行處理與資料庫間的三種關係。
啓動啟動執行處理的指令為 STARTUP {NOMOUNT|MOUNT|OPEN}。 如果 STARTUP 指令
後面沒有加上其他參數,或是加上 OPEN 這個參數,都表示希望執行處理能夠開啟資料庫。
[ora11g@Elinux ~]$ echo $ORACLE_SID --設定所要連線的執行處理名字
orcl
[ora11g@Elinux ~]$ sqlplus / AS SYSDBA --需要sysdba權限,才能啓動或關閉Instance
Connected to an idle instance. --代表Instance(ora11g)尚未啓動
SQL> STARTUP --若沒有加上任何參數,表示為STARTUP OPEN
ORACLE instance started. --此時Instance已經啓動,但尚未開啟Database
Total System Global Area 318054400 bytes
Fixed Size 1299624 bytes
Variable Size 138414936 bytes
Database Buffers 171966464 bytes
Redo Buffers 6373376 bytes
Database mounted. /*此時Instance已經掛載(mount)Database中的所有controlfile*/
Database opened. /*此時Instance已經開啓(open)Database中的所有datafile與logfile*/
SQL> SELECT status FROM v$instance;
STATUS
------------
OPEN
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
未掛載(NOMOUNT)
當執行處理的狀態試圖由關閉(SHUTDOWN)轉到未掛載(NOMOUNT)時,也就是使用
STARTUP 指令將執行處理啟動。必須先取得 SYSDBA 或 SYSOPER 權限,之後依據參數
檔的設定,配置系統整體區域(System Global Area)與啓動背景處理作業(Background
Process)。這時執行處理會將相關訊息記錄到警示日誌檔,並可能會產生一些背景處理作業
追蹤檔。不過當執行處理狀況為未掛載時,執行處理並未與資料庫有任何關連。
在未掛載的狀態下,資料庫管理者只能做以下兩件事:
• 建立資料庫。
• 重建控制檔。
掛載(MOUNT)
當執行處理試圖掛載資料庫時,執行處理根據 control_files 的參數值,開啓所指定的所有控
制檔(controlfile)。當所有控制檔都能被開啟後,執行處理將繼續比對控制檔所記錄的資料庫
名字是否與參數檔的 DB_NAME 參數所指定的資料庫名字相同。如果兩者相同,執行處理便
Chapter 2 – Oracle 伺服器
Oracle Database Management Best Practice
成功地掛載資料庫,這個階段稱為掛載(MOUNT)。不過若有任何一個控制檔無法成功地開啓,
這時會有錯誤訊息出現以及執行處理繼續保持在未掛載狀態。
在掛載階段資料庫管理者能做的工作有以下幾種:
• 復原資料庫。
• 更改資料檔或線上重做日誌檔的名字。
• 變更資料庫日誌模式,可以在無存檔日誌(noarchive log)與存檔日誌(archive log)模式
間轉換。
• 開啓或關閉資料庫回溯(Flashback Database)功能。
開啓(Open)
當試圖將執行處理的狀態轉換為開啟時,執行處理依照控制檔所記載的資料庫實體結構(資料
檔與線上重做日誌檔的位置),開啓所有狀態為線上(Online)資料檔與所有的線上重做日誌檔。
執行處理開啟資料檔與線上重做日誌檔後,將比對控制檔的最後檢查點號碼(Last
Checkpoint Number)與每個線上、讀寫狀態的資料檔標頭(Datafile Header)的最後檢查點是
否一致。兩者相同則表示上一次的執行處理是被正常關閉,因此可以開啟資料庫中的所有檔
案。若不一致則 SMON 進行執行處理復原(Instance Recovery)。
只有執行處理的狀態為開啟(OPEN)時,使用者才能登入資料庫 。
[oracle@Elinux ~]$ echo $ORACLE_SID
orcl
[oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/
Connected to an idle instance. /*代表Instance(orcl)尚未啓動*/
--如果無有特別的目的,請使用STARTUP OPEN將執行處理啟動,並開啟資料庫
SQL> STARTUP NOMOUNT /*將Instance啟動,但不掛載資料庫。*/
SQL> SELECT status FROM v$instance;
STATUS
------------
STARTED
SQL> ALTER DATABASE OPEN; /*目前的狀態為NOMOUNT,不能直接提升到OPEN*/
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
ALTER DATABASE OPEN
*
ERROR at line 1:
ORA-01507: database not mounted
SQL> ALTER DATABASE MOUNT;
/*NOMOUNT之後,只能繼續向上MOUNT或向下SHUTDOWN*/
SQL> SELECT status FROM v$instance;
STATUS
------------
MOUNTED
SQL> ALTER DATABASE OPEN; /*MOUNT之後,只能繼續向上OPEN或SHUTDOWN*/
SQL> SELECT status FROM v$instance;
STATUS
------------
OPEN
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.6.2 關閉執行處理
關閉執行處理將導致使用者無法繼續操作資料庫,所以在關閉執行處理之前,請先確定是否
非要關閉執行處理不可。如同執行處理開啓資料庫的步驟分成:NOMOUNT、MOUNT、
OPEN 三種,執行處理關閉的步驟也可以分成三個階段: 關閉(CLOSE)資料庫、卸載
(DISMOUNT)資料庫、關閉(SHUTDOWN)執行處理。
關閉執行處理的指令為 SHUTDOWN {NORMAL|TRANSACTIONAL|IMMEDIATE|ABORT}
[oracle@Elinux ~]$ echo $ORACLE_SID
orcl
[oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/
Connected. /*代表Instance(orcl)已經啓動*/
SQL> SELECT status FROM v$instance;
STATUS
------------
OPEN
SQL> SHUTDOWN IMMEDIATE
--進行髒緩衝與重做項目寫回資料檔與線上重做日誌檔的操作
Database closed. /*此時datafile與logfile被關閉*/
Database dismounted. /*此時controlfile被關閉*/
ORACLE instance shut down. /*Instance被關閉*/
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
關閉資料庫(Close)
當資料庫管理者執行 SHUTDOWN 指令時,不管指令後面接的是 NORMAL、
TRANSACTIONAL 還是 IMMEDIATE。執行處理在關閉資料庫之前,都會要求 DBWR 將緩
衝區快取的髒緩衝都寫回資料檔,以及 LGWR 將重做日誌緩衝區的所有重做項目都寫到線上
重做日誌檔。之後 CKPT 將檢查點資訊寫到每個資料檔檔頭與控制檔中。當以上的動作都完
成後,執行處理才關閉所有的資料檔與線上重做日誌檔。
不同的 SHUTDOWN 參數:NORMAL、TRANSACTIONAL、IMMEDIATE 有著不同的準備
動作。
• NORMAL:當使用這個參數時,從執行關閉指令之後,不允許建立新的階段作業
(Session)。但已經建立的階段作業,依然可以繼續進行。這時並沒有強制要求階段作
業結束,是由階段作業自己決定結束與否。因此可能無法確定何時能夠開始關閉資料
庫的動作。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。當
SHUTDOWN 指令後面沒有加上其他參數,預設以 NORMAL 方式執行關閉指令。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
• TRANSACTIONAL:當使用這個參數時,從執行關閉指令之後,不允許建立新的階段
作業。但是現有的階段作業,可以繼續正在進行的交易。不過交易完成後,就強迫結
束該階段作業。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。
• IMMEDIATE: 當使用這個參數時, 從執行關閉指令之後,除不允許建立新的階段作
業外,而且所有進行中的交易,立刻開始退回。當交易退回完成後,就強迫結束現有
階段作業。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。
卸載資料庫(Dismount)
執行處理關閉所有的控制檔,加上關閉資料庫階段所關閉的資料檔與線上重做日誌檔,執行
處理已經完全與資料庫不存在任何關連。執行處理關閉控制檔後,表示控制檔的內容不會再
被改變。
關閉執行處理(Shutdown)
系統整體區域(System Global Area)的記憶體空間將被作業系統收回,而且所有的背景處理作
業也將被終止,所以現在的執行處理將不復存在。若執行 SHUTDOWN ABORT 指令,則會
直接跳到關閉執行處理這一個階段,而沒有經過關閉資料庫與卸載資料庫的過程。因此在緩
衝區快取的髒緩衝都還未寫回資料檔,而進行中的交易也沒有結束。所以當下一次啓動新的
執行處理時,必須先進行執行處理復原來修復資料庫不一致的狀況。
[oracle@Elinux ~]$ echo $ORACLE_SID
orcl
[oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/
Connected. /*代表Instance(orcl)已經啓動*/
SQL> SELECT status FROM v$instance;
STATUS
------------
OPEN
/*要求正常地關閉datafile與online redo logfile,此指令僅用在示範關閉資料庫的動作。平
常請使用SHUTSOWN指令來關閉資料庫*/
SQL> ALTER DATABASE CLOSE;
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
SQL> SELECT status FROM v$instance;
STATUS
------------
MOUNTED
SQL> ALTER DATABASE OPEN; /*不能使用現在的Instance再次開啓datafile與logfile*/
alter database open
*
ERROR at line 1:
ORA-16196: database has been previously opened and closed
SQL> ALTER DATABASE DISMOUNT; /*關閉controfile*/
SQL> SELECT status FROM v$instance;
STATUS
------------
STARTED
SQL> ALTER DATABASE MOUNT; /*不能使用現在的Instance再次掛載controlfile*/
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
SQL> SHUTDOWN IMMEDIATE
ORA-01507: database not mounted
ORACLE instance shut down.
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.6.3 執行處理復原(Instance Recovery)
當執行處理的狀態由掛載到開啟資料庫的過程中,執行處理先檢查資料檔及線上重做日誌檔
是否存在。若狀態為線上的資料檔不存在則需要先復原該資料檔,之後才能繼續開啟資料庫
的動作。若某一個日誌群組的日誌成員不存在,則要確定該日誌群組有幾個日誌成員。只要
每個日誌群組中,至少有一個日誌成員可以被開啟,便不需要在這個階段復原該日誌成員,
而可以順利地繼續進行開啟資料庫的動作。
此外執行處理還會檢查資料檔標頭的最後檢查點號碼(Least Checkpoint Number)與控制檔
的最後檢查點號碼是否一致。如果兩者一致,代表前次資料庫關閉操作為正常關閉,也就是
有經過關閉資料庫與卸載資料庫的步驟,也表示所使用的關閉指令為 SHUTDOWN NORMAL、
TRANSACTIONAL、IMMEDIATE 其中之一。因此當重新啟動的執行處理開啟資料庫時,不
需要進行執行處理復原來恢復資料庫的內容。
倘若兩者的最後檢查點號碼不一致,則代表資料庫沒有經過正常的關閉過程,而是直接將執
行處理關閉或發生執行處理崩潰。所以執行處理的髒緩衝(Dirty Buffer)並未寫回資料檔,而
且進行中交易也未被退回。所以需要進行執行處理復原將所有的髒緩衝復原,並將它們寫回
資料檔,之後還要退回未確認的交易。
執行處理復原分成三個階段:重做異動(Rollforward)、開啟資料庫(Open)、退回未確認交易
(Rollback),在每個階段進行不同復原操作。
重做異動(Roll forward)
重做異動用來將所有的髒緩衝復原,SMON 由控制檔取得重做位元位置(Redo Byte Address)
的位置後,將線上重做日誌檔所有位於重做位元位置以後的重做項目,重新執行一次,直到
將所有的重做項目都被執行過一次為止,這個動作可以將之前執行處理的緩衝區快取的所有
髒緩衝重新產生,這些髒緩衝的來源包括已確認的交易與進行中的交易。之後 CKPT 立刻進
行一次完整的檢查點事件(Full Checkpoint),要求 DBWR 將所有髒緩衝都寫回資料檔,
DBWR 完成工作後,CKPT 將檢查點資訊寫到所有的資料檔檔頭與控制檔,當資料檔檔頭與
控制檔的檢查點資訊一致後,執行處理便可以繼續開啟資料庫了。
開啟資料庫(Open)
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
當執行處理開啟資料庫後,資料庫使用者便可以登入資料庫,進行一般的資料庫操作。雖然
重做異動階段已經將所有的髒緩衝復原,因此將所有已確認的交易復原。但是重做異動階段
也將未確認的交易一同復原,所以 SMON 開始退回之前的未確認交易。
退回未確認交易(Roll back)
重做異動的結果是所有的髒緩衝都成功地復原,回到前一個執行處理關閉前的狀態。因此保
證所有已經確認交易的髒緩衝都成功地復原,然而未確認交易也同時被復原。此時 SMON 利
用所復原的還原區段(Undo Segment)內容,將未確認的交易全數退回。當退回交易操作完成
後,前一個執行處理不正常關閉所帶來的資料庫不一致狀態,便可以完全解決。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.7 SQL 敘述句的執行過程
在 Oracle 伺服器的架構下,只有使用 SQL 敘述句才能操作資料庫的資料。然而執行 SQL 敘
述句時,所使用到的共用記憶體元件、背景處理作業與資料庫檔案,將因為不同的 SQL 敘述
句而有所不同。以下使用最基本的 SQL 敘述句:Select、DML、Commit 進行說明,讓資料
庫管理者知道這些 SQL 敘述句如何進行。
每個 SQL 敘述句都必須先由使用者處理作業(User Process)產生,然後傳到相對應的伺服器
處理作業,之後由伺服器處理作業代表使用者處理作業執行該 SQL 敘述句。如果是 Select
指令,伺服器處理作業還需要將 Select 的結果回傳給使用者處理作業。
當伺服器處理作業收到每個 SQL 敘述句時,必須經過下列步驟才能完成操作: 解析
(Parse)→繫結(Bind)→執行(Exectue)→提取(Fetch,只有 Select 才需要此步驟)。
2.7.1 解析(Parse)
因為 SQL 敘述句的用途,是用來描述使用者所想要的資料為何?伺服器處理作業如何去執行
這個 SQL 敘述句。因此當伺服器處理作業收到一個 SQL 敘述句時,首先將其轉換成最有效
率的執行這個 SQL 敘述句的步驟,這些步驟被稱為執行計畫(Execution Plan)。而產生執行
計畫的過程,可以細分為以下的幾個步驟:
1.檢查共用集區(Shared Pool)是否有之前解析相同 SQL 敘述句後,所儲存的 SQL 本文
(SQL Text)、解析樹(Parse Tree)與執行計畫(Execution Plan)。
如果能在共用集區的程式庫快取(Library Cache)中找到之前解析過的執行計畫,則此 SQL 敘
述句便不需要再次解析,直接由程式庫快取得到之前所產生的執行計畫,便可以直接跳到執
行階段,這種解析動作稱做軟解析(Soft Parse)。
但是若沒有在程式庫快取中找到之前解析過的相關資料,則必須繼續進行解析步驟,這種解
析稱做硬解析(Hard Parse)。
伺服器處理作業要如何得知這個 SQL 敘述句有相關的資料儲存在共用集區中?當然不可能搜
索整個共用集區,因為這樣太耗系統資源。所以伺服器處理作業採用一種比較簡單的方式,
就是將 SQL 敘述句的每個字符(Character)都先轉為 ASCII Code,再使用特殊的雜湊函數將
ASCII Code 轉成雜湊值(Hash Value)。如果這個 SQL 敘述句曾經被解析過,那麼這個 SQL
敘述句的 SQL 本文、解析樹與執行計畫將會被存放在共用集區的某個位置。而這個雜湊值便
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
是這個位置表示值。因此使用這個雜湊值讀取共用集區該位置的內容,如果該位置真的有資
料,但也不代表所存放執行計畫可以直接使用,還要進一步比對 SQL 本文(SQL Text)是否一
致,因為可能會有一個以上的 SQL 敘述句的雜湊值恰巧相同。
SQL> select last_name from employees where employee_id=100;
SQL> select last_name from employees where employee_id=200;
SQL> SELECT hash_value,address,executions,sql_text
2> FROM v$sql
3> WHERE sql_text LIKE 'select last_name from employees where employee_id=
%';
HASH_VALUE ADDRESS EXECUTIONS
------------------- --------------- -------------------
SQL_TEXT
--------------------------------------------------------------------------------
2627784799 329AEEF4 1
select last_name from hr.employees where employee_id=200
280342537 2EBE0FA4 1
select last_name from hr.employees where employee_id=100
以上圖為例,這兩個 SQL 敘述句看似相同,只有文字(Literal)不一樣(一個為 100、另一個為
200),但是 100 與 200 的 ASCII Code 值就不相同了,所以整個雜湊後的結果自然也不相
同。所以這兩個 SQL 敘述句都將被解析,但解析的動作相當耗 CPU 的運算資源,所此硬解
析的次數越多,則 Oracle 伺服器的效能越差。
SQL> variable empid number;
SQL> execute :empid := 100;
SQL> select last_name from hr.employees where employee_id=:empid;
SQL> execute :empid := 200;
SQL> select last_name from hr.employees where employee_id=:empid
SQL> SELECT hash_value,address,executions,sql_text
2> FROM v$sql
3> WHERE sql_text LIKE 'select last_name from employees where employee_id=
%';
HASH_VALUE ADDRESS EXECUTIONS
------------------- --------------- -------------------
SQL_TEXT
--------------------------------------------------------------------------------
476476418 3290C280 2
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
select last_name from hr.employees where employee_id=:empid
/*雖然SQL敘述句被執行2次,卻只解析一次.因為這2個的SQL敘述句完全相同.所以Execute階
段時,才會將:empid以100或200的值取代*/
2.檢查 SQL 敘述句的語法是否有錯誤。
SQL> SELECT * FORM employees;
SELECT * FORM employees --FROM打字錯誤為FORM
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected
3.檢查 SQL 敘述句的語義是否有錯誤以及是否擁有足夠的權限。
SQL> SELECT ename FROM employees;
SELECT ename FROM employees --employees表格中沒有叫做ename的欄位
*
ERROR at line 1:
ORA-00904: "ENAME": invalid identifier
SQL> SELECT prod_id FROM sh.products;
SELECT prod_id FROM sh.products --使用者沒有SELECT該表格的權限
*
ERROR at line 1:
ORA-00942: table or view does not exist
4.決定最佳的執行計畫(Execution Plan)。最佳化處理程式(Optimizer)會先產生多個執行計畫,
再將統計值(Statistics)帶入,找出執行成本最低的執行計畫,為執行此 SQL 敘述句的執行計
畫。
5.將 SQL 本文(SQL Text)、解析樹(Parse Tree)、執行計畫(Execution Plan)儲存在程式庫
快取,存放位置以 SQL 敘述句所計算出的雜湊值為起始位置。
2.7.2 繫結(Bind)
若 SQL 敘述句有使用繫結變數(Bind Variable),將在此時將變數值帶入執行計畫。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
2.7.3 執行(Execute)
此階段為依據執行計畫進行的操作。不同型態的 SQL 敘述句,執行過程當然不同。
查詢(SELECT)
1.檢查所需的資料區塊(Data Block)是否已經存在於緩衝區快取(Buffer Cache)。如果已經存
在於緩衝區快取中,則直接讀取其內容即可。這種讀取方式,稱為邏輯讀取(Logical Read)。
2.若所需的資料區塊並不存在於緩衝區快取中,則伺服器處理作業(Server Process)將資料區
塊由資料檔讀到緩衝區快取。首先伺服器處理作業必須先找到足夠的可使用緩衝後,才能由
資料檔讀入所需的資料區塊。這種讀取方式,稱為實體讀取(Physical Read),相較於邏輯讀
取,所耗費的系統資源較多,所花費的時間也較長。資料庫管理者應該盡量減少此種讀取的
次數與數量。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
異動(INSERT/UPDATE/DELETE)
1.檢查所需的資料區塊是否已經被讀到緩衝區快取。如果已經存在於緩衝區快取中,則直接
進行步驟 3。
2.若所需的資料區塊並不存在於緩衝區快取中,則伺服器處理作業(Server Process)將資料區
塊由資料檔讀到緩衝區快取中。
3.對想要異動的表格取得資料列獨佔鎖定(Row Exclusive Lock),之後對所要異動的資料列
(Row)取得獨佔鎖定(Exclusive Lock)。
4.伺服器處理作業必須先將資料列的重做項目(Redo Entry)複製到日誌緩衝區(Log Buffer)後,
才能異動資料列。除了異動前要先產生重做項目外,伺服器處理作業還要將如何還原異動前
資料的還原資料儲存到還原區段(Undo Segment),當完成前述工作後才能開始異動。可是將
還原資料記錄到還原區段時,也需要產生相對的重做項目,才能將還原資料(Undo Data)記錄
到還原區段。不過不需要再對還原資料的異動產生還原記錄。
所以資料列異動時相關動作的順序如下:產生原資料的重做項目與資料列異動的重做項目→
將還原資料的重做項目與資料列異動的重做項目一同複製到日誌緩衝區→產生資料列的還原
資料→異動資料列。
5.複製資料列異動的重做項目到日誌緩衝區中。
6.產生資料列異動的還原資料。
7.異動資料列的內容,如果之前緩衝為乾淨緩衝(Clean Buffer),此時將變為髒緩衝。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
交易確認(COMMIT)
1. 當使用者確認交易的指令傳遞到伺服器處理作業時,伺服器處理作業將交易確認的重做項
目複製到日誌緩衝區。
2.此時 LGWR 立即被觸發,將所有在日誌緩衝區但尚未寫到線上重做日誌檔的重做項目,依
時間順序寫到線上重做日誌檔。
3.當 LGWR 完成寫入後。該交易就此結束,所以該交易所握有的所有鎖定(Lock)、執行處理
資源(Resource)也將被釋放。
Chapter 1 – Oracle Server 基本介紹
Oracle Database Management Best Practice
4.伺服器處理作業回應交易確認完成(Committed)的訊息使用者處理作業。
提取(FETCH)-僅查詢指令才需要此步驟
這個步驟只是提取 Select 敘述句的結果回應給使用者處理作業。
結論
本章節的內容著重於介紹組成 Oracle 伺服器的各個元件的的名字與其專門的功能,在進一步
學習 Oracle 資料庫之前,熟悉這些結構的用途與彼此間的關係是相當重要的先決條件。有了
這些基本的知識後,才能順利地由往後的章節中,學習到 Oracle 資料庫更深入的知識,進而
徹底的掌握住 Oracle 資料庫的特性。

Mais conteúdo relacionado

Mais procurados

Oracle Database Management - Backup/Recovery
Oracle Database Management - Backup/RecoveryOracle Database Management - Backup/Recovery
Oracle Database Management - Backup/RecoveryChien Chung Shen
 
Oracle Database Management Basic 1
Oracle Database Management Basic 1Oracle Database Management Basic 1
Oracle Database Management Basic 1Chien Chung Shen
 
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...オラクルエンジニア通信
 
Oracle data guard for beginners
Oracle data guard for beginnersOracle data guard for beginners
Oracle data guard for beginnersPini Dibask
 
Oracle Database Performance Tuning Concept
Oracle Database Performance Tuning ConceptOracle Database Performance Tuning Concept
Oracle Database Performance Tuning ConceptChien Chung Shen
 
Oracle Database SQL Tuning Concept
Oracle Database SQL Tuning ConceptOracle Database SQL Tuning Concept
Oracle Database SQL Tuning ConceptChien Chung Shen
 
Oracle Exadata Management with Oracle Enterprise Manager
Oracle Exadata Management with Oracle Enterprise ManagerOracle Exadata Management with Oracle Enterprise Manager
Oracle Exadata Management with Oracle Enterprise ManagerEnkitec
 
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力オラクルエンジニア通信
 
Oracle Cloud Infrastructure:2022年8月度サービス・アップデート
Oracle Cloud Infrastructure:2022年8月度サービス・アップデートOracle Cloud Infrastructure:2022年8月度サービス・アップデート
Oracle Cloud Infrastructure:2022年8月度サービス・アップデートオラクルエンジニア通信
 
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)Amazon Web Services Japan
 
Basic oracle-database-administration
Basic oracle-database-administrationBasic oracle-database-administration
Basic oracle-database-administrationsreehari orienit
 
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?AskTom: How to Make and Test Your Application "Oracle RAC Ready"?
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?Markus Michalewicz
 
Oracle Cloud Infrastructure:2021年6月度サービス・アップデート
Oracle Cloud Infrastructure:2021年6月度サービス・アップデートOracle Cloud Infrastructure:2021年6月度サービス・アップデート
Oracle Cloud Infrastructure:2021年6月度サービス・アップデートオラクルエンジニア通信
 
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...オラクルエンジニア通信
 
Oracle RAC 19c and Later - Best Practices #OOWLON
Oracle RAC 19c and Later - Best Practices #OOWLONOracle RAC 19c and Later - Best Practices #OOWLON
Oracle RAC 19c and Later - Best Practices #OOWLONMarkus Michalewicz
 
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)オラクルエンジニア通信
 

Mais procurados (20)

Oracle Database Management - Backup/Recovery
Oracle Database Management - Backup/RecoveryOracle Database Management - Backup/Recovery
Oracle Database Management - Backup/Recovery
 
Oracle Database Management Basic 1
Oracle Database Management Basic 1Oracle Database Management Basic 1
Oracle Database Management Basic 1
 
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
 
Oracle data guard for beginners
Oracle data guard for beginnersOracle data guard for beginners
Oracle data guard for beginners
 
Oracle Database Performance Tuning Concept
Oracle Database Performance Tuning ConceptOracle Database Performance Tuning Concept
Oracle Database Performance Tuning Concept
 
Oracle Database SQL Tuning Concept
Oracle Database SQL Tuning ConceptOracle Database SQL Tuning Concept
Oracle Database SQL Tuning Concept
 
Oracle Exadata Management with Oracle Enterprise Manager
Oracle Exadata Management with Oracle Enterprise ManagerOracle Exadata Management with Oracle Enterprise Manager
Oracle Exadata Management with Oracle Enterprise Manager
 
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力
[Oracle DBA & Developer Day 2012] 高可用性システムに適した管理性と性能を向上させるASM と RMAN の魅力
 
Oracle Database Vaultのご紹介
Oracle Database Vaultのご紹介Oracle Database Vaultのご紹介
Oracle Database Vaultのご紹介
 
Oracle Cloud Infrastructure:2022年8月度サービス・アップデート
Oracle Cloud Infrastructure:2022年8月度サービス・アップデートOracle Cloud Infrastructure:2022年8月度サービス・アップデート
Oracle Cloud Infrastructure:2022年8月度サービス・アップデート
 
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)
 
Basic oracle-database-administration
Basic oracle-database-administrationBasic oracle-database-administration
Basic oracle-database-administration
 
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?AskTom: How to Make and Test Your Application "Oracle RAC Ready"?
AskTom: How to Make and Test Your Application "Oracle RAC Ready"?
 
Oracle Cloud Infrastructure:2021年6月度サービス・アップデート
Oracle Cloud Infrastructure:2021年6月度サービス・アップデートOracle Cloud Infrastructure:2021年6月度サービス・アップデート
Oracle Cloud Infrastructure:2021年6月度サービス・アップデート
 
Oracle Data Masking and Subsettingのご紹介
Oracle Data Masking and Subsettingのご紹介Oracle Data Masking and Subsettingのご紹介
Oracle Data Masking and Subsettingのご紹介
 
Oracle SQL 1 Day Tutorial
Oracle SQL 1 Day TutorialOracle SQL 1 Day Tutorial
Oracle SQL 1 Day Tutorial
 
OCI Logging 概要
OCI Logging 概要OCI Logging 概要
OCI Logging 概要
 
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...
[Oracle Cloud Days Tokyo 2015] Oracle Database 12c最新情報 ~Maximum Availability ...
 
Oracle RAC 19c and Later - Best Practices #OOWLON
Oracle RAC 19c and Later - Best Practices #OOWLONOracle RAC 19c and Later - Best Practices #OOWLON
Oracle RAC 19c and Later - Best Practices #OOWLON
 
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)
OCI 購入モデルの整理と Universal Credit 最新情報(2021年2月17日版)
 

Semelhante a Oracle Instance 介紹

Oracle北大青鸟完全教程
Oracle北大青鸟完全教程Oracle北大青鸟完全教程
Oracle北大青鸟完全教程yiditushe
 
1, OCP - architecture intro
1, OCP - architecture intro1, OCP - architecture intro
1, OCP - architecture introted-xu
 
7, OCP - configure database for backup and recovery
7, OCP - configure database for backup and recovery7, OCP - configure database for backup and recovery
7, OCP - configure database for backup and recoveryted-xu
 
【Ask maclean技术分享】oracle dba技能列表 z
【Ask maclean技术分享】oracle dba技能列表 z【Ask maclean技术分享】oracle dba技能列表 z
【Ask maclean技术分享】oracle dba技能列表 zmaclean liu
 
4, OCP - oracle networking
4, OCP - oracle networking4, OCP - oracle networking
4, OCP - oracle networkingted-xu
 
MySQL5.6&5.7 Cluster 7.3 Review
MySQL5.6&5.7 Cluster 7.3 ReviewMySQL5.6&5.7 Cluster 7.3 Review
MySQL5.6&5.7 Cluster 7.3 Review郁萍 王
 
中远公司 Java培训资料
中远公司  Java培训资料中远公司  Java培训资料
中远公司 Java培训资料yiditushe
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践wuqiuping
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践drewz lin
 
2, OCP - installing and creating a database
2, OCP - installing and creating a database2, OCP - installing and creating a database
2, OCP - installing and creating a databaseted-xu
 
CH16:整合資料庫
CH16:整合資料庫CH16:整合資料庫
CH16:整合資料庫Justin Lin
 
腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化areyouok
 
腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化topgeek
 
MySQL5.6新功能
MySQL5.6新功能MySQL5.6新功能
MySQL5.6新功能郁萍 王
 
诗檀软件 Oracle数据块损坏知识
诗檀软件 Oracle数据块损坏知识诗檀软件 Oracle数据块损坏知识
诗檀软件 Oracle数据块损坏知识maclean liu
 
Oracle雲端服務介紹 taiwan
Oracle雲端服務介紹   taiwanOracle雲端服務介紹   taiwan
Oracle雲端服務介紹 taiwanChieh-An Yu
 
Oracle saa s paas overview
Oracle saa s paas overviewOracle saa s paas overview
Oracle saa s paas overviewChris Lee
 
Basic oracle for developer&beginner
Basic oracle for developer&beginnerBasic oracle for developer&beginner
Basic oracle for developer&beginnermaclean liu
 
第4章 数据库管理
第4章 数据库管理第4章 数据库管理
第4章 数据库管理zhang shuren
 
A.oracle 查询结果的缓存问题
A.oracle 查询结果的缓存问题A.oracle 查询结果的缓存问题
A.oracle 查询结果的缓存问题WASecurity
 

Semelhante a Oracle Instance 介紹 (20)

Oracle北大青鸟完全教程
Oracle北大青鸟完全教程Oracle北大青鸟完全教程
Oracle北大青鸟完全教程
 
1, OCP - architecture intro
1, OCP - architecture intro1, OCP - architecture intro
1, OCP - architecture intro
 
7, OCP - configure database for backup and recovery
7, OCP - configure database for backup and recovery7, OCP - configure database for backup and recovery
7, OCP - configure database for backup and recovery
 
【Ask maclean技术分享】oracle dba技能列表 z
【Ask maclean技术分享】oracle dba技能列表 z【Ask maclean技术分享】oracle dba技能列表 z
【Ask maclean技术分享】oracle dba技能列表 z
 
4, OCP - oracle networking
4, OCP - oracle networking4, OCP - oracle networking
4, OCP - oracle networking
 
MySQL5.6&5.7 Cluster 7.3 Review
MySQL5.6&5.7 Cluster 7.3 ReviewMySQL5.6&5.7 Cluster 7.3 Review
MySQL5.6&5.7 Cluster 7.3 Review
 
中远公司 Java培训资料
中远公司  Java培训资料中远公司  Java培训资料
中远公司 Java培训资料
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践
 
阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践阿里自研数据库 Ocean base实践
阿里自研数据库 Ocean base实践
 
2, OCP - installing and creating a database
2, OCP - installing and creating a database2, OCP - installing and creating a database
2, OCP - installing and creating a database
 
CH16:整合資料庫
CH16:整合資料庫CH16:整合資料庫
CH16:整合資料庫
 
腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化
 
腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化腾讯大讲堂38 oracle基础体系结构及性能优化
腾讯大讲堂38 oracle基础体系结构及性能优化
 
MySQL5.6新功能
MySQL5.6新功能MySQL5.6新功能
MySQL5.6新功能
 
诗檀软件 Oracle数据块损坏知识
诗檀软件 Oracle数据块损坏知识诗檀软件 Oracle数据块损坏知识
诗檀软件 Oracle数据块损坏知识
 
Oracle雲端服務介紹 taiwan
Oracle雲端服務介紹   taiwanOracle雲端服務介紹   taiwan
Oracle雲端服務介紹 taiwan
 
Oracle saa s paas overview
Oracle saa s paas overviewOracle saa s paas overview
Oracle saa s paas overview
 
Basic oracle for developer&beginner
Basic oracle for developer&beginnerBasic oracle for developer&beginner
Basic oracle for developer&beginner
 
第4章 数据库管理
第4章 数据库管理第4章 数据库管理
第4章 数据库管理
 
A.oracle 查询结果的缓存问题
A.oracle 查询结果的缓存问题A.oracle 查询结果的缓存问题
A.oracle 查询结果的缓存问题
 

Mais de Chien Chung Shen

Mais de Chien Chung Shen (8)

Databases on AWS
Databases on AWSDatabases on AWS
Databases on AWS
 
Awsomeday ntc
Awsomeday ntcAwsomeday ntc
Awsomeday ntc
 
MySQL SQL Tutorial
MySQL SQL TutorialMySQL SQL Tutorial
MySQL SQL Tutorial
 
Oracle 12cR1 In-Memory Column Store
Oracle 12cR1 In-Memory Column StoreOracle 12cR1 In-Memory Column Store
Oracle 12cR1 In-Memory Column Store
 
Mssql to oracle
Mssql to oracleMssql to oracle
Mssql to oracle
 
Oracle Database Undo Segment Operation Concept
Oracle Database Undo Segment Operation ConceptOracle Database Undo Segment Operation Concept
Oracle Database Undo Segment Operation Concept
 
Hadoop Essential for Oracle Professionals
Hadoop Essential for Oracle ProfessionalsHadoop Essential for Oracle Professionals
Hadoop Essential for Oracle Professionals
 
Understanding index
Understanding indexUnderstanding index
Understanding index
 

Oracle Instance 介紹

  • 1. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 第二章 Oracle 伺服器 前言 雖然 Oracle 資料庫是全世界第一個關聯式資料庫,但它畢竟是一個商業用的資料庫軟體,會 適度地修改或捨棄某些關聯式理論,以因應整個產業環境的變化。因此在學習與操作 Oracle 資料庫時,必須以 Oracle 公司所提供的建議為主,關聯式資料庫的理論為輔。本章的主要目 的就是要讓資料庫管理者了解 Oracle 資料庫的專有名詞,與 Oracle 資料庫的運作原理,幫助 資料庫管理者可以更快地學習及了解 Oracle 資料庫。 2.1 Oracle 伺服器(Oracle Server) Oracle 伺服器是由執行處理(Instance)與資料庫(Database)所組成。其中執行處理是所謂的關 聯式資料庫管理系統(RDBMS-Relational Database Management System),提供相關的資料 庫管理功能。而資料庫則為 Oracle 資料庫檔案所組成,用來儲存資料。執行處理可以進一步 地細分為:系統整體區域(System Global Area)與背景處理作業(Background Processes)。 資料庫也可以再細分為:資料檔(Datafile)、控制檔(Control file)、線上重做日誌檔(Online Redo Log file)。其中執行處理的系統整體區域(SGA)是使用作業系統的記憶體空間,而背景 處理作業則需使用到中央處理器(CPU)與記憶體的資源,而組成資料庫檔案則是放在磁碟機。 為什麼要使用這種架構呢?這必須由整個電腦系統的硬體架構看起,一個典型的電腦伺服器 硬體由中央處理器(Cpu)、記憶體(Ram)與磁碟機(Disk)所組成,其中依存取速度來排序為 CPU > RAM > Disk。因為中央處理器所內建的記憶體空間太小,不適合存放大量的資料。 因此可用來放置資料的結構只剩下記憶體與磁碟機。若所有資料都放在記憶體,資料操作的 速度較磁碟機快。但若伺服器發生某種問題,造成伺服器關閉。將可能導致存放在記憶體的 資料全數遺失。但若資料將全部都存放在磁碟機,即便伺服器發生某種問題,造成伺服器關 閉。也可以保證資料不會遺失(當然若是磁碟機發生問題,就另當別論,需要資料庫備份,方 能保證資料不會遺失),不過問題是磁碟機的存取速度太慢。因此 Oracle 伺服器將資料操作都 設計在執行處理進行,而資料則存放在資料庫。這樣的架構可以利用到記憶體的存取速度快 於磁碟機的好處,又可以利用磁碟機的保存性比記憶體佳的優點。
  • 2. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 在一個安裝 Oracle 資料庫軟體的電腦伺服器之上,可以同時啓動多個 Oracle 伺服器,只要這 台伺服器的硬體資源足夠即可。更甚至於可以在同一台電腦伺服器中,安裝多個不同版本的 Oracle 資料庫軟體,進而同時啓動多個不同版本的 Oracle 伺服器。
  • 3. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.2 執行處理(Instance) 執行處理是由系統整體區域(System Global Area)與許多的背景處理作業(Background Processes)所組成。系統整體區域(縮寫為 SGA)由許多的不同用途的共用記憶體元件所組成, 例如:共用集區(Shared Pool)、緩衝區快取(Buffer Cache)、日誌緩衝區(Log Buffer)、大 型集區(Large Pool)、串流集區(Streams Pool)與 Java 集區(Java Pool)等等。而共用(Share) 的意義是表示系統整體區域可以被所有的背景處理作業與伺服器處理作業(Server process)讀 寫。 背景處理作業由許多不同功能的處理作業所組成,其中常見的:SMON、PMON、DBWR、 LGWR、CKPT、ARCH 等等。為何稱為背景(Background)?是因為這些處理作業在啟動後, 會依據事先所設定的情況,自動進行某些特定的操作(例如:DBWR 會自動將髒緩衝(Dirty Buffer)寫回資料檔),不需要資料庫管理者介入。而且每個背景處理作業的功能彼此間不會重 複,而且有時後它們需要互相合作來完成某些操作(例如:檢查點事件(Checkpoint event)須 由 CKPT 與 DBWR 一起完成)。
  • 4. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice
  • 5. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.2.1 系統整體區域(System Global Area) 系統整體區域(為節省篇幅,以下縮寫為 SGA)事實上由多個共用記憶體元件所組成,以下將 介紹常見而且重要的共用記憶體區域元件。同時每個 SGA 至少要有共用集區、緩衝區快取與 日誌緩衝區這三個共用記憶體元件。 共用集區(Shared pool) 共用集區是 SGA 中相當重要的一部份,而共用集區的大小是由 SHARED_POOL_SIZE 設定, 但是個別的子元件大小,例如程式庫快取(Library Cache)、資料辭典快取(Data Dictionary Cache)、結果集快取(Result Cache)的大小,由 Oracle 執行處理自行依照系統狀態動態調整。 程式庫快取(Library Cache) 程式庫快取(Library Cache)中存放最近用過的 SQL 敘述句或 PL/SQL 區塊的本文(Text)、 解析樹(Parse Tree)與執行計畫(Execution Plan)。主要的用途是希望當下一次執行相同的 SQL 敘述句或 PL/SQL 區塊時,可以直接由程式庫快取找到之前以使用過的執行計劃。而不 需要再次解析相同的 SQL 敘述句或 PL/SQL 區塊,因為解析相當消耗系統的資源。如此整 個資料庫的效能(Performance)將會更好、而擴充性(Scalability)也會更佳, 。 資料辭典快取(Data Dictionary Cache) 資料辭典快取(Data Dictionary Cache)存放最近用到的物件定義,而這些定義的來源是資料 庫的資料辭典(Data Dictionary)。當解析 SQL 敘述句時,首先需要知道所參考的表格或索引 的相關定義。因此先搜索程式庫快取,希望能夠找到這些物件的相關定義。若沒有在程式庫 快取中找到所需的資料,接著便會搜索資料辭典快取,看看所需的資料是否存在資料辭典快 取中。如果還是找不到所需的物件定義,則必須到資料辭典找到所需要的物件定義,然後將 它們讀到資料辭典快取,再將那些物件定義讀到程式庫快取,最後才開始進行解析。 從以上的敘述,便可以知道資料辭典快取是來減少因為硬解析(Hard Parse)所產生的實體讀取 (Physical Read)。因為解析所需的物件定義已經存在於資料辭典快取,此時的讀取為邏輯讀 取(Logical Read),其讀取的速度較快且成本較低。 結果集快取(Result Cache)
  • 6. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 結果集快取(Result Cache)是 Oracle Database 11g 新增的記憶體元件,它用來放 SQL 敘述 句的執行結果。當使用者再次執行相同的 SQL 敘述句時,如果之前的執行結果有被快取在結 果集快取中,這時就不需經過解析與執行,便可以直接由結果集快取中取得執行結果。因此 SQL 敘述句的反應速度將變得更快,而且對 Oracle 伺服器來說,所消耗的資源也最少。 雖然結果集快取的最大值可以由 RESULT_CACHE_MAX_SIZE 設定,但因為結果集快取為 用共用集區的子元件。因此還是使用共用集區的空間,所以這個參數的大小不能超過 SHARED_POOL_SIZE 的 75%。 緩衝區快取(Buffer Cache) 用來存放最近使用過的資料區塊(Data Block),當未來需要使用相同的資料區塊時,就不需要 再從資料檔中讀取一次,而直接就由緩衝區快取即可得到所要的資料區塊。所以緩衝區快取 將邏輯地切割為一塊塊的緩衝(Buffer),每個緩衝同時只能存放一個與緩衝相同大小的資料區 塊。Oracle 資料庫允許多達 5 種的資料區塊大小(2K/4K/8K/16K/32K),所以當資料區塊 大小不同時,緩衝區快取也必須有相同大小的緩衝存在,才能放置這些不同大小的資料區塊。 緩衝區快取是多個子緩衝區的統稱,DB_CACHE_SIZE、DB_KEEP_CACHE_SIZE、 DB_RECYCLE_CACHE_SIZE 以標準區塊為切割單位,而 DB_2K_CACHE_SIZE 的緩衝為 2K 的大小,此外還有 DB_4K_CACHE_SIZE、DB_8K_CACHE_SIZE、 DB_16K_CACHE_SIZE 與 DB_32K_CACHE_SIZE 等。 若無法在緩衝區快取找到所需的資料區塊,則必須先將資料區塊由資料檔讀到緩衝區快取, 之後才能進行後續的操作,而這種資料區塊的讀取動作稱為實體讀取(Physical Read)。若可 以由緩衝區快取讀取所要的資料區塊,這種動作稱為邏輯讀取(Logical Read)。由於以存取速 度而看,記憶體的速度遠快於磁碟機,緩衝區快取的存在可以大幅減少實體讀取的數量,因 此可以提昇資料庫伺服器的效能。 日誌緩衝區(Log Buffer) 為保證已確認交易(committed transaction),在 Oracle 伺服器發生問題後,可以被復原。因 此每次伺服器處理作業(Server Process)進行資料異動之前,會先產生關於這個異動的重做項 目(Redo Entry),並先將重做項目複製到日誌緩衝區,之後伺服器處理作業才進行資料的異動。 至於日誌緩衝區的重做項目將由日誌寫入器(LGWR)寫到線上重做日誌檔(Online Redo
  • 7. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice Logfile)中。若執行處理發生問題而崩潰(Crash),只要在下次重新啟動執行處理時,依照線 上重做日誌檔的重做項目,重新執行一次,便可以已經確認的交易全數復原。 為何不直接將重做日誌寫到線上重做日誌檔,卻要先將重做項目複製到日誌緩衝區暫存?因 為先產生重做項目後,才能進行異動。而記憶體的存取速度比磁碟機快,這種架構可以減少 執行 SQL 敘述句之前的等待重做項目寫入的時間。 若在重做項目被寫到線上重做日誌檔之前,執行處理便先崩潰,而導致日誌緩衝區的所有重 做項目遺失,難道不會有些已經確認的交易無法復原?這個問題是不可能發生的,因為執行 處理要求交易確認前,必須將交易確認的重做日誌寫到線上重做日誌檔後,才會回覆交易已 確認的訊息給使用者。也就是說當使用者看到交易已確認的訊息時,該交易的重做項目一定 已經被寫到線上重做日誌檔。所以即便執行處理突然中止運行,已經確認的交易還是可以透 過重做日誌檔的重做項目來復原。但如果執行處理不正常的中止時,那些尚未被寫到線上重 做日誌檔的重做項目一定屬於目前進行中的交易(尚未確認的交易),既然是未確認,無法復原 也無所謂。 而重做項目到底是什麼?其實重做項目是由一些記錄所組成,這些記錄包含異動發生在哪個 資料區塊的哪個資料列,以及異動後的值與異動的操作型態。所以當需要復原時,可以透過 重做項目將異動重新復原。 日誌緩衝區的大小是由 LOG_BUFFER 這個參數決定的,這邊需要提醒的是 LOG_BUFFER 的大小必須是檔案系統區塊(通常為 512/1024 bytes)的倍數。可以由以下的 SQL 敘述句得 知目前所使用的檔案系統的區塊大小為何? SQL> SELECT max(lebsz) log_blk_size FROM sys.x$kccle; LOG_BLK_SIZE --------------------- 512 這表示目前所使用的Logfile Block為512 Bytes 大型集區(Large Pool)
  • 8. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 這個元件不是必要存在的共用記憶體元件,只是在某些狀況下,執行處理需要這個共用記憶 體元件來減輕共用集區的競爭。因為如果沒有設定大型集區,但使用到需要大型集區的操作 時,執行處理將使用共用集區來代替大型集區。 若有下列幾種情況,建議需要額外設定大型集區,以免造成共用集區的過度使用,造成共用 集區的空間競爭更加嚴重,造成執行處理的效能問題。 • 當使用共用伺服器(Shared Server)架構時,階段作業(Session)的使用者整體區域 (User Global Area)將存放在大型集區,以方便所有的共用伺服器作業(Shared Server Process)存取。 • 使用 Oracle XA Interface 功能時。 • 使用 I/O Slave 模擬非同步 I/O 功能時,此時大型集區將被當作 I/O 緩衝區使用。 • 當使用復原管理程式(Recovery Manager)進行備份(Backup)與回存(Restore)操作時, 用來當作 I/O 緩衝區使用。 • 當使用平行查詢(Parallel Query)時,平行查詢處理作業(Parallel Query Process)彼此 交換訊息的地方。 大型集區的大小可以由 LARGE_POOL_SIZE 設定,可設定的大小由 300KB 到至少 2GB 以 上(依作業系統不同而有所差異)。 JAVA 集區(Java Pool) 用來提供記憶體空間給 Java 虛擬機器(Java Virtual Machine)使用。JAVA 集區的大小是由 JAVA_POOL_SIZE 參數來設定的。 串流集區(Streams Pool) Oracle 串流(Oracle Streams)是 Oracle Database 10g 開始提供的功能,用在資料庫與資料 庫之間進行資訊分享(Information Sharing)。如果沒有用到 Oracle 串流,則不需要設定此空 間。 串留集區的大小是由參數 STREAMS_POOL_SIZE 所決定的。
  • 9. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.2.2 背景處理作業(Background Process) 每個執行處理啓動時,會同時啟動許多的背景處理作業(Background Process)。其中有五個 背景處理作業一定要被啟動,如果有這五個中任一背景處理作業無法啟動,則該執行處理也 無法啟動。然而即便執行處理已經啟動,這五個背景處理作業中的任一個因為發生錯誤而中 止運行,也會導致執行處理崩潰(Crash)。這五個重要的背景處理作業為 SMON、PMON、 DBWR、LGWR、CKPT。此外正常的 Oracle11g 執行處理還有其他的背景處理作業,如 ARCH、MMON、REC0、VKTM、DIAG、DBRM、MMAN、MMNL、FBDA、SMCO、 QMNC 等等,不過這些背景處理作業不是絕對必要存在,如果這些背景處理作業發生問題, 最多只是某些功能受到影響無法使用,而不會導致執行處理崩潰。 背景處理作業在 UNIX 平台上為一個獨立的行程(Process),行程的名字格式為 ora_背景處理 作業名字_執行處理名字,例如執行處理名字為 orcl,則可以使用 UNIX 作業系統的指令 ps - ef|grep orcl 查詢與 orcl 執行處理相關的行程。 而 Windows 平台上的背景處理作業為 oracle.exe 內的執行緒。
  • 10. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 系統監督(System Monitor-SMON) 當每次執行處理被重新啟動,在掛載資料庫到開啓資料庫的過程,SMON 會檢查資料庫是否 為正常關閉。如果是不正常關閉,則會啓動執行處理復原(Instance Recovery)的機制,來復 原資料庫中所有已確認的交易,並退回(Rollback)未確認的交易。這是 SMON 最為人所知的 功能。 其實除執行處理復原外,SMON 需要處理相當多的狀況,以下為一些常見的操作。 • 每五分鐘進行回收可用的擴充區塊(Free Extent)或將相鄰的可用擴充區塊合併為一個 較大的可用擴充區塊,不過這是功能僅能在說明管理表格空間(Dictionary Managed Tablespace)進行。 • 每兩小時清理一次暫時區段(Temporary segment),這個操作只有在暫時區段被放在 永久型態的表格空間(Permanent Tablespaces)才會發生。
  • 11. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice • 更新 SMON_SCN_TIME 中,系統改變號碼(System Change Number-SCN)與時間戳 記(TIMESTAMP)的對應資料,用在使用回溯(Flashback)功能的時候,可以用時間戳 記來代替系統改變號碼。Oracle Database 9i R2 為每 5 分鐘一次,Oracle Database 10g 以後為每 6 秒鐘一次。系統改變號碼為一個數字,用來表示重要事件發生的先後 順序,數字越大表示發生順序越後面。自資料庫建立後,由 SCN 開始由 1 遞增,每次 增加 1。每秒鐘裡最多可以產生 16284 次遞增,因為每個 SCN 佔 6 個 bytes 空間, 所以可以保證在 500 年內不會用玩。 • 每十二小時將 OBJ$中不存在的物件資訊清除一次。 • 每一小時檢查 IND$中是否有因為線上重建索引(rebuild index online)失敗所殘留內容。 • 每十二小時對還原區段(Undo Segment)進行收縮一次,就是將還原區段中可用的擴充 區塊收回。將狀態為”Pending Offline”的還原區段,再試圖離線(Offline)一次。 • 在真實應用程式叢集(Real Application Cluster-RAC)架構下,如果其中一個執行處理 突然崩潰,其他執行處理的 SMON 會對崩潰的執行處理進行執行處理復原,將已經確 認的交易復原與退回未確認的交易。 處理作業監督(Process Monitor-PMON) PMON 是監控其他處理作業(Background Process 或 Server Process)的狀態,當有異常情 況發生,則會進行相對的復原動作。 • PMON 會定期發送訊息給使用者處理作業(User Process),當某個使用者處理作業很 久都沒有回應訊息,PMON 便會認定這個使用者處理作業已經死去。因此會退回該階 段作業進行中的交易,釋放已握有的鎖定(Lock)及相關的資源。 • 當 PMON 發現某個共用伺服器處理作業(Shared Server Process)或分配器 (Dispatcher)突然終止時,它會重新啓動一個新的共用伺服器處理作業或分配器。 • PMON 啓動後,會將執行處理的資訊向監聽器(LISTENER)註冊,並定時更新執行處 理的負載(Workload)資訊。如果有分配器存在,PMON 也會一併向監聽器註冊分配器 的相關資訊。至於向那些監聽器註冊,則依據 LOCAL_LISTENER 的設定,如果沒有
  • 12. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 設定 LOCAL_LISTENER 參數,PMON 會自動向執行處理所在的機器,監聽 TCP 協 定 1521 埠的監聽器註冊。 資料庫寫入器(Database Writer-DBWR) DBWR 的唯一功能就是將緩衝區快取的髒緩衝(Dirty Buffer)寫回到資料檔。在多 CPU 架構 下,可以啓動多個 DBWR 處理作業來管理緩衝區快取,最多可以有 20 個 DBWR。 何謂髒緩衝?因為緩衝區快取的內容都是伺服器處理作業由資料檔讀入的資料區塊,所以剛 讀入的緩衝內容應該與資料檔的資料區塊內容一致。但是經過 DML 敘述句的異動後,伺服器 處理作業將會修改緩衝的資料列內容,因而造成緩衝的內容與資料檔的資料區塊內容不一致 的情況,這種緩衝便稱為髒緩衝。 某些情況發生時,DBWR 會將某些髒緩衝的內容寫回(Write Back)資料檔,如果寫回動作完 成後,這些緩衝被稱做乾淨緩衝(Clean Buffer),因為緩衝的內容與資料區塊的內容一致。 何時 DBWR 會將髒緩衝的內容寫回資料檔: • 緩衝區快取內有太多的髒緩衝存 當伺服器處理作業執行一個 SQL 敘述句時,首先會檢查其所需的資料區塊是否都已經 存在於緩衝區快取。如果存在則進行後續的操作。倘若所需的資料區塊無論是全部或 部份不在緩衝區快取,伺服器處理作業必須先將那些資料區塊由資料檔讀入緩衝區快 取。不過在讀取資料區塊之前,要先確定緩衝區快取內有足夠的可使用緩衝(可使用緩 衝包含乾淨緩衝、可用緩衝(Fee Buffer)與未使用緩衝(Unused Buffer),可以用來存 放由資料檔讀入的資料區塊。 注意:可用緩衝與未使用緩衝是相同意義,都表示緩衝內沒有任何資料存在。為統一 名詞,往後都使用可用緩衝。 因此伺服器處理作業搜尋可使用緩衝時,將由 LRU 串列(LRU List)的 LRU(Least Recently Used)端開始向 MRU 端(Most Recently Used)尋找。如果在搜尋的過程中遇 到髒緩衝,便會將其移到檢查點佇列(Checkpoint Queue)。如果因此造成檢查點佇列 的髒緩衝數量超過其可容納數量,則伺服器處理作業會停止繼續搜尋可用緩衝的動作, 轉而呼叫 DBWR 將檢查點佇列的所有髒緩衝都寫回資料檔。因此伺服器處理作業會等
  • 13. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 待 DBWR 進行寫入操作,當寫入操作完成後那些髒緩衝都變成乾淨緩衝,而且被移到 LRU 串列的 LRU 端。這時伺服器處理作業再次搜尋 LRU 串列,便順利地取得所需要 的可用緩衝。 注意:Oracle 伺服器使用 LRU 串列與檢查點佇列(Checkpoint Queue)來管理緩衝區 快取,每個緩衝同一時間只能位於一種串列之上(LRU List 或 Checkpoint Queue)。 不過檢查點佇列只能放置髒緩衝,髒緩衝則依被弄髒的時間排序。而 LRU 串列中可以 放置乾淨緩衝、髒緩衝、可用緩衝。每個位於 LRU 串列的緩衝依其最近被存取的時間 及次數排列,最近被存取的緩衝比最近未被存取的緩衝,更靠近 MRU 端。越靠近 LRU 端表示該緩衝的內容比其他更靠近 MRU 端的緩衝來說,其存取的時間比較早。 • 緩衝區快取的可使用緩衝數量太少 當伺服器處理作業開始尋找 LRU 串列的可使用緩衝之前,會先設定此次搜尋所能讀取 的最多緩衝數量。如果達到搜尋的最大個數依舊未找到足夠的可使用緩衝時,伺服器 處理作業會呼叫 DBWR 將檢查點佇列的髒緩衝全數寫回資料檔。將髒緩衝變為乾淨緩 衝後,再重新再尋找可使用緩衝,這時應該就可以順利地找到所需數量的可用緩衝。 • 當檢查點事件(Checkpoint)發生,CKPT 會要求 DBWR 將某些數量的髒緩衝寫回資料 檔。 • 每經過三秒鐘 DBWR 會自動將 LRU 串列裡部份的髒緩衝移到檢查點佇列,並將檢查 點佇列中的髒緩衝全數寫回資料檔。因為隨時都有可能有伺服器處理作業需要可使用 緩衝來容納由資料檔所讀入的資料區塊,如果能由 DBWR 並時產生一些可使用緩衝。 讓伺服器處理作業快速找到所需的可使用緩衝,不需要等待 I/O 操作,這樣可以減少 執行 SQL 敘述句的反應時間。 日誌寫入器(Log Writer-LGWR) LGWR 的責任是將日誌緩衝區(Log Buffer)的重做項目(Redo Entry)寫到線上重做日誌檔中。 一但 LGWR 開始進行寫入操作,它會將所有尚未被寫到線上重做日誌檔的重做項目,都寫到 線上重做日誌檔。 以下為 LGWR 被觸發而進行寫入的情況:
  • 14. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice • 當使用者要求確認(commit)交易時,伺服器處理作業(Sever Process)先將確認資訊寫 到日誌緩衝區,之後 LGWR 將立刻被觸發,將日誌緩衝區內尚未寫到線上重做日誌檔 的所有重做項目都寫到線上重做日誌檔。 • 日誌緩衝區內尚未被寫到線上重做日誌檔的重做項目,其所佔的空間已超過 1MB 或 1/3 以上的日誌緩衝區大小,LGWR 也會被觸發開始將重做項目寫到線上重做日誌檔。 • LGWR 每三秒會自動觸發寫入動作。 • 當 DBWR 將某些髒緩衝寫回資料檔之前,若髒緩衝的相關重做項目尚未寫到線上重做 日誌檔。這時執行處理先要求 LGWR 將重做項目寫到線上重做日誌檔,之後才允許 DBWR 將那些髒緩衝寫回資料檔。 檢查點(Checkpoint-CKPT) 當檢查點事件發生時,CKPT 會要求 DBWR 將某些髒緩衝寫回到資料檔,當 DBWR 完成工 作後,CKPT 會將檢查點資訊(Checkpoint Information)寫到控制檔(Controlfile)及資料檔標 頭(Datafile Header)。同時每 3 秒符 CKPT 會將重做位元組位置(Redo Byte Address)記錄到 控制檔中,所以當發生執行處理復原(Instance Recovery)時,便可以由控制檔所記錄的重做 位元組位置,讀取線上重做日誌檔的重做項目(Redo Entry),進行執行處理復原。 注意:重做位元組位置(Redo Byte Address)為當進行執行處理復原時,SMON 需要由線上重 做日誌檔的哪個位置開始讀取重做項目,這個位置其實是檢查點佇列裡最老的髒緩衝的最早 產生的重做項目在線上重做日誌檔的位置。從這個位置開始復原,一直到所有的重做項目都 已經重做完成,便保證所有的髒緩衝都能被復原。 何時會發生檢查點事件: • 資料庫正常關閉 資料庫管理者使用 SHUTDOWN {NORMAL|TRANSACTIONAL|IMMEDIATE}關閉資 料庫。這些關閉指令會要求 DBWR 將所有的髒緩衝寫到資料檔,與要求 LGWR 將所 有的重做項目寫到線上重做日誌檔。當所有寫入動作都完成後,CKPT 才將檢查點資 訊寫到控制檔與資料檔標頭。之後才關閉資料檔與線上重做日誌檔。
  • 15. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice • 進行日誌檔切換(Logfile Switch) 這時以被切換的日誌群組的最後一個重做項目的 SCN 為基準,要求在此 SCN 之前已 經成為髒緩衝的緩衝,都必須變成乾淨緩衝。當 DBWR 完成所有的寫入動作後, CKPT 會將檢查點資訊寫到控制檔與資料檔標頭,同時此日誌群組的狀態也設定為 INACTIVE,表示該日誌群組已經完成檢查點。 • 資料庫管理者執行 ALTER SYSTEM CHECKPOINT 指令 這個指令會要求所有的髒緩衝都必須被寫回資料檔。當寫入完成後,CKPT 會將檢查 點資訊寫到控制檔與資料檔標頭。 • 資料庫管理者執行 ALTER TABLESPACE tsname {OFFLINE|READ ONLY|BEGIN BACKUP} DBWR 會將屬於該表格空間的髒緩衝寫回資料檔。當 DBWR 完成這些寫入動作後, CKPT 只會將檢查點資訊寫到該表格空間的資料檔標頭,而不會寫到控制檔。 因為並沒有將所有的髒緩衝都寫回資料檔,此種檢查點被稱做遞增檢查點(Incremental Checkpoint)。 • FAST_START_MTTR_TARGET 如果資料庫管理者想要確保執行處理復原(Instance Recovery)的完成時間,可以將 FAST_START_MTTR_TARGET 設為所接受的秒數。這時執行處理會計算出緩衝區快 取內最多可允許幾個髒緩衝,這樣當執行處理崩潰(Instance Crash)時,才能保證執行 處理復原(Instance Recovery)可以在要求的期限內完成。因此 CKPT 每 3 秒鐘會檢查 一次髒緩衝的數量是否超過,如果超過限制,CKPT 會要求 DBWR 將超過數量的髒緩 衝寫回資料檔,讓緩衝區快取內髒緩衝的數量低於 FAST_START_MTTR_TARGET 的限制。這樣當進行執行處理復原時,所需要復原的髒緩衝數量便會減少,因此執行 處理復原的時間也就同步減少了。但是這種檢查點事件並不會將所有的髒緩衝寫回資 料檔,因此也稱為遞增檢查點(Incremental Checkpoint)。 當此種檢查點事件完成後,CKPT 只會將檢查點資訊寫到控制檔,不會寫到資料檔中。 這個參數值越小,CKPT 所造成 I/O 量就越大,可能會造成 I/O 超過資料庫系統的極 限,導致整體資料庫效能下滑,但是卻可以保證執行處理復原越快完成。若
  • 16. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice FAST_START_MTTR_TARGET 越小,所造成的 I/O 量就越小,對整體資料庫效能的 影響就越小,但執行處理復原越慢才能完成。所以資料庫管理者要小心的設定此參數。 自動檢查點調校(Automatic Checkpoint Tuning) Oracle Database10g 開始,資料庫管理者可以藉由不設定 FAST_START_MTTR_TARGET 參數,讓執行處理自動根據資料庫的 I/O 容量來決定要將多少個髒緩衝寫回資料檔。當目前 資料庫 I/O 量較大的時候,則寫回資料檔的髒緩衝數量就減少一點。但是如果目前資料庫的 I/O 數量不多,則 CKPT 會要求寫回多一點的髒緩衝。因此不會讓整體的 I/O 量超過資料庫 系統所能承受的極限,也不會造成 I/O 瓶頸發生。不過這時 Oracle 伺服器便不能保證執行處 理復原能夠在多少秒內完成,僅能說盡快完成。但是若明確地將 FAST_START_MTTR_TARGET 設為 0,則關閉自動檢查點調校的功能。 存檔器(Archiver-ARCH) ARCH 的工作只有將線上重做日誌檔(Online Redo Logfile)複製為存檔日誌檔(Archived Logfile)。這個存檔的動作只有當資料庫為為存檔日誌模式(Archive Log Mode)時,才會進行 此種操作。ARCH 行程的個數可由參數:LOG_ARCHIVE_MAX_PROCESSES 設定,在 Oracle Database 11g 最多可以有 30 個。
  • 17. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 1.3 其他的處理作業(Other Process) 雖然這些處理作業不屬於執行處理一部份,但是它們對使用者而言卻是最常接觸到的處理作 業,沒有它們使用者無法與執行處理溝通,這些處理作業稱為前景處理作業(Foreground Process)。 2.3.1 使用者處理作業(User Process) 使用者處理作業指的是那些會產生 SQL 敘述句的應用程式,無論是 SQL*Plus 或任何使用者 自行開發的程式,只要能產生出 SQL 敘述句的程式,都稱做使用者處理作業。 2.3.2 伺服器處理作業(Server Process) 在專屬伺服器(Dedicated Server)模式下,每個使用者處理作業一定有一個專屬的伺服器處理 作業。這個伺服器處理作業代表使用者處理作業執行 SQL 敘述句,必要時回傳執行結果給使 用者處理作業。 在共用伺服器(Shared Server)模式下,每個使用者處理作業不會直接與伺服器處理作業連接, 而是連接到分配器(Dispatcher),每個分配器可以同時連接多個使用者處理作業。當使用者處 理作業有 SQL 敘述句需要執行時,它將 SQL 敘述句傳給分配器,但是分配器不負責執行 SQL 敘述句,因此分配器將 SQL 敘述句放到系統整體區域(System Global Area)的要求佇列 (Request Queue)中。放在要求佇列中的 SQL 敘述句,由事先啟動的共用伺服器作業處理們 (Shared Server Processes)依先進先出(First In First Out)的順序執行。當 SQL 敘述句執行 完成後,共用伺服器作業處理將執行結果傳給分配器所屬的反應佇列(Response Queue),而 分配器再傳給要求執行的使用者處理作業。因為伺服器處理作業不是專屬於某個使用者作業 系統,而是由使用者處理作業們共用,所以稱做共用伺服器模式。同時即便是同一個使用者 作業處理所產生的 SQL 敘述句,被分配器傳到要求佇列後,有極大的可能不是被同一個伺服 器處理作業執行。
  • 18. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.3.3 連線(Connection) 所謂的連線(Connect)是描述使用者處理作業與伺服器處理作業之間的連線方式,根據使用者 處理作業與伺服器處理作業的相對位置,有以下三種方式: • 行程間通訊(Inter-Process Communication):使用者處理作業與伺服器處理作業位在 同一個作業系統中,兩個行程不需要透過網路便可以建立連線 。 • 主從架構(Client/Server):使用者處理作業與伺服器處理作業位在不同ㄧ個機器上, 兩個行程需要透過網路才可以建立連線。 • 三層式架構(3-Tier): 前端的使用者利用瀏覽器(Browser)連到應用程式伺服器 (Application Server),再由應用程式伺服器依據使用者的輸入資訊,產生出相對應的
  • 19. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice SQL 敘述句,之後將 SQL 敘述句交由伺服器處理作業執行。在三層式架構下使用者 處理作業指的是應用程式伺服器,因為是由它產生 SQL 敘述句。 1.3.4 階段作業(Session) 當連線建立後,使用者處理作業接著將使用者帳戶(Username)與密碼(Password)傳給伺服器 處理作業要求建立一個階段作業(Session),而伺服器處理作業收到使用者帳號與密碼後,開 始進行使用者身分驗證,驗證通過後繼續確認該使用者是否有建立階段作業(CREATE SESSION)的權限。如果使用者擁有 CREATE SESSION 的權限,則一個階段作業就此建立, 而此階段作業將一直持續直到使用者結束階段作業為止。
  • 20. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.4 資料庫(Database) 資料庫的結構可分為實體結構(Physical Structure)與邏輯結構(Logical Structure)。實體結 構為組成這個資料庫的實體檔案,共有以下三種型態:資料檔(Datafile)、控制檔(Controlfile)、 線上重做日誌檔(Online Redo Logfile)。而邏輯結構則是為讓資料庫的空間可以更有效率的使 用而產生的結構,邏輯結構先將資料檔的空間使用表格空間加以整合,再將表格空間的空間 分割為更小的單位:區段(Segment),而區段可以再細分為擴充區塊(Extent),擴充區塊再分 割為多個連續資料區塊(Data Block)。
  • 21. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.4.1 資料庫的實體結構(Physical Structure) 資料庫的實體結構為組成此資料庫的實體檔案,這些檔案有三種型態:資料檔、控制檔、線 上重做日誌檔。每種檔案都有不同的用途,而且缺一不可。 資料檔(Datafile) 從檔案的名稱就可以看出用途,用來放資料(Data)。不論是使用者所建立的表格(Table)、索 引(Index)、叢集(Cluster)、索引組織表格(Index Organized Table)等物件或執行處理所使用 的資料辭典(Data Dictionary),都放在資料檔內。在 Oracle Database 10g 之前,每個資料 庫至少需要 1 個資料檔,用來組成 SYSTEM 表格空間(System Tablespace)。從 Oracle Database 10g 開始,每個資料庫至少需要 2 個資料檔,因為 Oracle Database 10g 有兩個 必要的表格空間(SYSTEM 與 SYSAUX),而每個表格空間至少要由一個資料檔組成,而同一 個資料檔只能屬於一個表格空間,所以 Oracle Database 10g 至少需要 2 個資料檔。 Oracle Database 11g 規定,每個資料庫最多不能有超過 65533 個資料檔存在,同時也不能 有超過 65533 個表格空間存在。 控制檔(Controlfile) 每個資料庫至少要有 1 個,最多不能超過 8 個控制檔存在。但不管有幾個控制檔,每個控制 檔的內容必須一致。而且當執行處理掛載(Mount)資料庫後,一直要到執行處理卸載 (Dismount)資料庫前,每份控制檔都要維持能夠被讀、寫(Read Write)的狀態。如果有任一 份控制檔因為某種原因無法被讀寫,則執行處理將因此而崩潰。所以建議控制檔應該要有兩 份以上,而且應該分別存放在不同磁碟控制卡所管理的不同磁碟機上,以免磁碟控制卡或磁 碟機發生毀損,導致所有的控制檔都遺失的情況發生。 為什麼控制檔這麼重要?需要維護這麼多份相同內容的檔案。主要是因為控制檔用來存放許 多資料庫相關的重要資訊,例如資料庫的實體結構,也就是此資料庫的資料檔與線上重做日 誌檔的位置。如果控制檔不小心全數遺失,則執行處理根本無法得知資料檔的位置,遑論能 夠存取資料檔的資料。 以下為控制檔內所儲存的重要資訊:
  • 22. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice • 最多八個字的資料庫名字與十位數字組成的資料庫辨識號碼(Database Identifier- DBID)。 • 資料庫的建立時間。 • 資料庫中所有表格空間的名字。 • 目前正在使用的日誌群組號碼(Log Group Number)與日誌順序號碼(Log Sequence Number)。 • 檢查點資訊(Checkpoint Information),有關於資料庫與資料檔的兩種檢查點資訊。 • 日誌檔的歷史記錄。 • 使用復原管理程式(RMAN)所進行的備份及復原相關資訊。 在 Oracle Database 11g 的資料庫中,每個控制檔最大不能超過 20000 個資料區塊。 線上重做日誌檔(Online Redo Logfile) 線上重做日誌檔的內容是日誌緩衝區(Log Buffer)的重做項目(Redo Entry),這些內容是由 LGWR 所寫入,用在執行處理或資料庫需要被復原時,可以用來重新產生資料之用。也就是 說當 Oracle 伺服器是正常運行時,線上重做日誌檔根本沒有任何用處,只增加額外的成本(重 做項目的產生成本與 LGWR 將重做項目寫到線上重做日誌檔的 I/O 成本)。然而沒有任何人可 以(敢)保證 Oracle 伺服器永遠不會發生需要復原的錯誤。所以重做項目的產生及線上重做日 誌檔的存在,是絕對必要的。只是要如何面對它們呢?其實只要把握一個要點即可,”既要 馬兒好,又要馬兒不吃草”。也就是說在正常情況下,要讓它們的成本影響 Oracle 伺服器的 效能最少。但在需要復原時,它們卻可以提供最完整的復原,保證已經確認的交易不會遺失。 Oracle 資料庫至少需要兩個日誌群組(Log Groups),而每個日誌群組至少由一個日誌成員 (Log Member)組成。這裡所說的日誌成員就是之前所提到的線上重做日誌檔,所以每個資料 庫至少需要兩個線上重做日誌檔,不過這兩個日誌檔必須分屬不同的群組。日誌群組的個數 是由建立資料庫所使用的參數:MAXLOGFILES 決定,而每個日誌群組可以有幾個日誌成員 則有 MAXLOGMEMBERS 決定。
  • 23. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 建立資料庫後,如果日誌群組個數超過 MAXLOGFILES 的設定,Oracle Database 11g 會 自動增加這個設定值,以容納新增的日誌群組設定。一般來說 MAXLOGMEMBERS 也是如此, 不過 MAXLOGMEMBERS 最大值為 5,如果想要加入超過第 5 個日誌成員以上,則會出現 ORA-00357: too many members specified for log file, the maximum is 5。 多工(Multiplexing) 當儲存媒體錯誤(Media Failure),造成資料檔遺失時,可以透過之前對資料檔所做的備份與日 誌檔(存檔日誌檔與線上重做日誌)來復原資料檔。如果線上重做日誌檔、存檔日誌檔與資料檔 放在同一個磁碟機,那麼當發生儲存媒體錯誤時,可能同時失去的資料庫檔案為資料檔與日 誌檔。這時即便有資料檔的備份,但沒有足夠的日誌檔是無法復原資料檔。 那麼將線上重做日誌檔如同資料檔一般直接備份不就好了,可是線上重作日誌的內容不是最 新的重做項目,不論何時備份都無法備份到最新的重做項目(新產生的重做項目暫存在日誌緩 衝區)。因此線上重做日誌檔不適合使用備份的方式保護,所以 Oracle 執行處理要求 LGWR 將重做項目同時寫到同一個日誌群組的多個日誌成員上。 同時建議資料庫管理者將這些日誌成員分別放在不同磁碟控制卡所控制的不同磁碟機上。這 種架構稱為多工(Multiplexing),可以避免資料庫陷入單一點錯誤(Single Point Of Failure)的 危機。雖然越多的日誌成員,資料庫的安全保護越佳,但是 LGWR 寫入重作項目所需的時間 也越多,可能會影響到 Oracle 伺服器的效能,所以資料庫管理人員必須拿捏資料庫安全與效 能的最佳平衡。 1.4.2 邏輯結構(Logical Structure) 資料庫的邏輯結構主要用途是希望能夠更細微地管理、使用資料檔的空間,因為實體結構的 最小單位為一個檔案,對資料庫來說實在太大。因此 Oracle 將資料檔的空間邏輯地分割更小 的單位,以方便管理及提昇空間使用效率。 表格空間(Tablespace) 表格空間(Tablespace)由一個或多個資料檔組成的,主要用途是將資料檔的空間分割為更小 的單位。每個表格空間只能屬於一個資料庫,每個資料庫最多只能有 65533 個表格空間,但 Oracle11g 的資料庫最少要有兩個表格空間(SYSTEM 與 SYSAUX)資料庫。同時資料庫的所 有物件都放在表格空間中,例如︰物件定義存放在 SYSTEM 表格空間的資料辭典(Data
  • 24. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice Dictionary)。如果該物件除了定義外,還需要額外的空間來放置此物件的資料,這些額外的 空間便稱之為區段(Segment),而該區段必須存在於某個表格空間之中。 區段(Segment) 區段並不是一種真正的空間結構,它只是一個集合,將屬於同一個物件的擴充區塊(Extent)集 合在一起成為一個單元就是區段。許多資料庫管理者所熟知的物件有相對應的區段,只是區 段的型態不同而已,例如表格(Table)、索引(Index)、叢集(Cluster)、索引組織表格(Index Organized Table)、暫時(Temporary)、還原(Undo)等物件。 擴充區塊(Extent) 擴充區塊才是真正的空間配置主角。每當一個區段需要更多的空間時,資料庫將會配置一個 可用擴充區塊給該區段,以滿足該區段的空間需求。不過擴充區塊必須是由同ㄧ個資料檔的 連續資料區塊組成,而一個擴充區塊最小要由 2 個資料區塊組成。 以下為需要配置擴充區塊的幾種情況: • 建立一個新的區段時,需要至少配置一個擴充區塊。 • 因為執行 DML 操作時,發現現有區段的可用空間不敷使用。因此將會要求配置一個可 用擴充區塊。 • 當資料庫管理者知道將有大量資料將被新增,可以在事先要求配置一些可用擴充區塊 給該區段,這樣可以避免未來因動態要求配置擴充區塊,而影響到資料新增的速度。 以下為需要收回擴充區塊的情形: • 當區段被丟棄(Drop)時,所有配置給該區段的擴充區塊都將被收回。這些擴充區塊的 狀態將由已使用(Used)變為可用(Free),之後若有需要這些可用擴充區塊將配置給其他 的區塊使用 • 當區段被截斷(Truncate)時,除第一個擴充區塊外,該區段其他的擴充區塊都會被收 回。 • 當區段被縮小空間(Shrink Space)時,將會收回多餘的擴充區塊。
  • 25. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice • 資料庫管理者要求回收那些未曾用過的擴充區塊,指的是位在高水位標記(High Water Mark)以上的擴充區塊。 資料區塊(Data Block) 資料區塊(Data Block)是資料庫 I/O 的最小單位,即便只想讀取某筆資料列(Row),但伺服器 處理作業還是必須將整個資料區塊讀到緩衝區快取(Buffer Cache)中,當然 DBWR 將髒緩衝 內容寫回到資料檔也是如此。為了讓資料庫整體的 I/O 動作更有效率,建議一個資料區塊的 大小應該是 OS 區塊的整數倍,可以使用的資料區塊大小為 2K、4K、8K、16K、32K 等五 種。在一般的作業環境下,常見的為 4K、8K、16K 三種。同時為了資料庫整體 I/O 的效率, 也可以一次讀取多個連續的資料區塊到緩衝區快取,可以使用 DB_FILE_MULTIBLOCK_READ_COUNT 設定在全表格掃描(Full Table Scan)或快速全索引 掃描(Fast Full Index Scan)時,一次讀取幾個資料區塊。 2.5 其他的相關檔案 Oracle 資料庫的實體結構雖然只有資料檔、控制檔、線上重做日誌檔這三種檔案,不過 Oracle 伺服器還需要一些其他型態的檔案,才能讓 Oracle 伺服器運行的更有效率。 2.5.1 密碼檔(Password File) 密碼檔存放被授與 SYSDBA、SYSOPER、SYSASM 等權限的使用者帳戶與密碼。當使用者 要求取得 SYSDBA、SYSOPER、SYSASM 權限時,首先將試圖使用作業系統驗證來判斷使 用者是否可以取得所要求的權限。如果使用者無法通過作業系統驗證,則必須提供使用者帳 戶與密碼,用來與密碼檔的使用者帳戶與密碼進行比對,若一致則讓使用者取得所要求的權 限。若不一致則出現權限不足的錯誤訊息。 2.5.2 參數檔(Parameter File) 每個執行處理都有一個生命週期。當執行處理被啓動後,就是其生命週期的開始,執行處理 的生命一直持續到這個執行處理被關閉,也表示這個執行處理的生命已經結束。資料庫管理 者重新啟動執行處理時,這個執行處理如何得知之前的執行處理所使用系統整體區域大小, 以及應該啟動那些背景處理作業,還有警示檔與追蹤檔的位置? Oracle 伺服器將這些執行處理的相關設定儲存在參數檔中,因此執行處理關閉後,只要使用 相同的參數檔,便可以讓新啟動的執行處理與之前的執行處理有相同設定。
  • 26. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 依據參數檔的型態可分為 PFILE(Parameter File)-文字檔格式及 SPFILE(Server Parameter File)-二進位格式(Binary)兩種,而由 Oracle Database 9i 開始 SPFILE 便成為預設的選項。 以 Oracle Database 11g 為例,可供設定的參數多達 289 個,資料庫管理者可由 V$SYSTEM_PARAMETER 得到執行處理目前所使用的參數值。若加上隱藏參數更多達 1920 個,所有的參數可由 X$KSPPI 與 X$KSPPCV 得到相關的資訊,所謂的隱藏參數是那 些參數名稱前面有加上”_”,例如:_disable_logging,不過這些參數通常不須特別設定, 也不建議使用,因為這些隱藏的參數不提供官方支援。同時每個參數都有預設值,所以不需 要也不應該在參數檔中設定每個參數,只要設定那些預設值不能滿足需求的參數即可。 --v$system_parameter的內容為Instance目前所使用的參數與餐數值 SQL> SELECT COUNT(*) FROM v$system_parameter; COUNT(*) ----------------- 289 SQL> SELECT COUNT(*) FROM x$ksppi; COUNT(*) ----------------- 1920 /*x$ksppi只有參數名稱,參數值則存放在x$ksppcv*/ SQL> SELECT n.indx,n.ksppinm,p.ksppstvl FROM x$ksppi n,x$ksppcv p 2 WHERE n.indx=p.indx AND n.ksppinm='_disable_logging'; INDX KSPPINM KSPPSTVL ------------------ --------------------------------- ------------------------------ 678 _disable_logging FALSE 2.5.3 存檔日誌檔(Archived Logfile) 若資料庫為存檔日誌(Archive Log)模式,當日誌切換(Log Switch)發生時,ARCH 會將線上 重做日誌的內容複製為存檔日誌檔(Archived logfile)。因此當線上重做日誌檔(Online Redo Logfile)的內容,因為日誌切換而被覆寫(Overwrite)後,則可由存檔日誌檔取得被覆寫的重做 項目。存檔日誌檔用在當資料庫發生儲存媒體錯誤(Media Failure)時,可以利用之前備份的資 料檔備份與日誌檔(存檔日誌檔與線上重做日誌檔)來復原已經毀損的資料檔內容。Oracle 公司 建議所有正式環境的資料庫都應該設定為存檔日誌模式。
  • 27. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.5.4 警示日誌檔(Alert Logfile) 警示日誌檔記錄 Oracle 伺服器(執行處理與資料庫)所發生的重要事件,其內容依發生時間的 先後順序記載在警示日誌檔中,如執行處理啓動與關閉的時間、啟動執行處理時所使用的非 預設參數值、表格空間相關的操作記錄以及所發生的錯誤資訊(ORA-600、ORA-1578、 ORA-60 等)。不過警示日誌檔中的錯誤資訊只是簡要內容,詳細的錯誤訊息放在背景處理作 業所產生的追蹤檔中。警示日誌檔於 BACKGROUND_DUMP_DEST(11g 之前)或 DIAGNOSTIC_DEST(11g ADR)所指定的目錄,其檔案名稱格示為 alert_SID.log,SID 為執 行處理的名字(若執行處理名字為 orcl,則其警示日誌檔名字為 alert_orcl.log)。當有訊息需要 記錄到警示檔時,這些訊息將以建立或附加(Create or Append)的方式新增到警示日誌檔。 也就是若警示日誌檔已經存在,則將訊息附加到現有日誌檔的最後面。但若無法找到日誌檔, 這時將先建立新的警示日誌檔,並將訊息依序寫到警示日誌檔。 2.5.5 背景處理作業追蹤檔(Background Process Trace File) 背景處理作業追蹤檔是當伺服器處理作業或背景處理作業發生錯誤時,所記錄下來的詳細錯 誤資訊,有時甚至包含記憶體傾倒(Memory Dump)。這些訊息不是給資料庫管理者用來解決 目前的 Oracle 伺服器錯誤,而是提供 Oracle 公司的支援人員更詳細的資料庫錯誤資訊,用以 解決複雜的資料庫問題。背景處理作業追蹤檔將出現在 BACKGROUND_DUMP_DEST(11g 之前)或 DIAGNOSTIC_DEST(11g ADR)所指定的目錄下,以及檔案名稱格示為 SID_ProcessName_OsProcesSid.trc。SID 代表的是 Oracle Instance 的名字, ProcessName 代表的是背景處理作業名稱縮寫,不過如果是由伺服器處理作業所產生的追蹤 檔,它的 ProcessName 為”ora”。UNIX 平台中 OsProcessSid 為該行程(Process)在作業 系統中的行程號碼,若在 Windows 平台中則為執行緒(Thread)的號碼。
  • 28. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice
  • 29. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 2.6 開啟或關閉執行處理 在 Oracle 伺服器架構中,所有儲存在資料庫內的資料,都必須透過執行處理才能被操作。如 果執行處理尚未開啟資料庫,此時資料庫使用者只能望資料庫興嘆,而不能存取、操作資料 庫的資料。 2.6.1 開啟執行處理 資料庫的所有資料都存放在資料檔內,資料庫使用者不能直接讀寫該資料檔的內容,必須使 用 SQL 敘述句,由伺服器處理作業透過執行處理才能存取或操作這些資料。而執行處理開啓 資料庫的過程可以分成三個階段:未掛載(NOMOUNT)、掛載(MOUNT)、開啟(OPEN),這三 種階段分別代表著執行處理與資料庫間的三種關係。 啓動啟動執行處理的指令為 STARTUP {NOMOUNT|MOUNT|OPEN}。 如果 STARTUP 指令 後面沒有加上其他參數,或是加上 OPEN 這個參數,都表示希望執行處理能夠開啟資料庫。 [ora11g@Elinux ~]$ echo $ORACLE_SID --設定所要連線的執行處理名字 orcl [ora11g@Elinux ~]$ sqlplus / AS SYSDBA --需要sysdba權限,才能啓動或關閉Instance Connected to an idle instance. --代表Instance(ora11g)尚未啓動 SQL> STARTUP --若沒有加上任何參數,表示為STARTUP OPEN ORACLE instance started. --此時Instance已經啓動,但尚未開啟Database Total System Global Area 318054400 bytes Fixed Size 1299624 bytes Variable Size 138414936 bytes Database Buffers 171966464 bytes Redo Buffers 6373376 bytes Database mounted. /*此時Instance已經掛載(mount)Database中的所有controlfile*/ Database opened. /*此時Instance已經開啓(open)Database中的所有datafile與logfile*/ SQL> SELECT status FROM v$instance; STATUS ------------ OPEN
  • 30. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 未掛載(NOMOUNT) 當執行處理的狀態試圖由關閉(SHUTDOWN)轉到未掛載(NOMOUNT)時,也就是使用 STARTUP 指令將執行處理啟動。必須先取得 SYSDBA 或 SYSOPER 權限,之後依據參數 檔的設定,配置系統整體區域(System Global Area)與啓動背景處理作業(Background Process)。這時執行處理會將相關訊息記錄到警示日誌檔,並可能會產生一些背景處理作業 追蹤檔。不過當執行處理狀況為未掛載時,執行處理並未與資料庫有任何關連。 在未掛載的狀態下,資料庫管理者只能做以下兩件事: • 建立資料庫。 • 重建控制檔。 掛載(MOUNT) 當執行處理試圖掛載資料庫時,執行處理根據 control_files 的參數值,開啓所指定的所有控 制檔(controlfile)。當所有控制檔都能被開啟後,執行處理將繼續比對控制檔所記錄的資料庫 名字是否與參數檔的 DB_NAME 參數所指定的資料庫名字相同。如果兩者相同,執行處理便
  • 31. Chapter 2 – Oracle 伺服器 Oracle Database Management Best Practice 成功地掛載資料庫,這個階段稱為掛載(MOUNT)。不過若有任何一個控制檔無法成功地開啓, 這時會有錯誤訊息出現以及執行處理繼續保持在未掛載狀態。 在掛載階段資料庫管理者能做的工作有以下幾種: • 復原資料庫。 • 更改資料檔或線上重做日誌檔的名字。 • 變更資料庫日誌模式,可以在無存檔日誌(noarchive log)與存檔日誌(archive log)模式 間轉換。 • 開啓或關閉資料庫回溯(Flashback Database)功能。 開啓(Open) 當試圖將執行處理的狀態轉換為開啟時,執行處理依照控制檔所記載的資料庫實體結構(資料 檔與線上重做日誌檔的位置),開啓所有狀態為線上(Online)資料檔與所有的線上重做日誌檔。 執行處理開啟資料檔與線上重做日誌檔後,將比對控制檔的最後檢查點號碼(Last Checkpoint Number)與每個線上、讀寫狀態的資料檔標頭(Datafile Header)的最後檢查點是 否一致。兩者相同則表示上一次的執行處理是被正常關閉,因此可以開啟資料庫中的所有檔 案。若不一致則 SMON 進行執行處理復原(Instance Recovery)。 只有執行處理的狀態為開啟(OPEN)時,使用者才能登入資料庫 。 [oracle@Elinux ~]$ echo $ORACLE_SID orcl [oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/ Connected to an idle instance. /*代表Instance(orcl)尚未啓動*/ --如果無有特別的目的,請使用STARTUP OPEN將執行處理啟動,並開啟資料庫 SQL> STARTUP NOMOUNT /*將Instance啟動,但不掛載資料庫。*/ SQL> SELECT status FROM v$instance; STATUS ------------ STARTED SQL> ALTER DATABASE OPEN; /*目前的狀態為NOMOUNT,不能直接提升到OPEN*/
  • 32. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice ALTER DATABASE OPEN * ERROR at line 1: ORA-01507: database not mounted SQL> ALTER DATABASE MOUNT; /*NOMOUNT之後,只能繼續向上MOUNT或向下SHUTDOWN*/ SQL> SELECT status FROM v$instance; STATUS ------------ MOUNTED SQL> ALTER DATABASE OPEN; /*MOUNT之後,只能繼續向上OPEN或SHUTDOWN*/ SQL> SELECT status FROM v$instance; STATUS ------------ OPEN
  • 33. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.6.2 關閉執行處理 關閉執行處理將導致使用者無法繼續操作資料庫,所以在關閉執行處理之前,請先確定是否 非要關閉執行處理不可。如同執行處理開啓資料庫的步驟分成:NOMOUNT、MOUNT、 OPEN 三種,執行處理關閉的步驟也可以分成三個階段: 關閉(CLOSE)資料庫、卸載 (DISMOUNT)資料庫、關閉(SHUTDOWN)執行處理。 關閉執行處理的指令為 SHUTDOWN {NORMAL|TRANSACTIONAL|IMMEDIATE|ABORT} [oracle@Elinux ~]$ echo $ORACLE_SID orcl [oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/ Connected. /*代表Instance(orcl)已經啓動*/ SQL> SELECT status FROM v$instance; STATUS ------------ OPEN SQL> SHUTDOWN IMMEDIATE --進行髒緩衝與重做項目寫回資料檔與線上重做日誌檔的操作 Database closed. /*此時datafile與logfile被關閉*/ Database dismounted. /*此時controlfile被關閉*/ ORACLE instance shut down. /*Instance被關閉*/
  • 34. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 關閉資料庫(Close) 當資料庫管理者執行 SHUTDOWN 指令時,不管指令後面接的是 NORMAL、 TRANSACTIONAL 還是 IMMEDIATE。執行處理在關閉資料庫之前,都會要求 DBWR 將緩 衝區快取的髒緩衝都寫回資料檔,以及 LGWR 將重做日誌緩衝區的所有重做項目都寫到線上 重做日誌檔。之後 CKPT 將檢查點資訊寫到每個資料檔檔頭與控制檔中。當以上的動作都完 成後,執行處理才關閉所有的資料檔與線上重做日誌檔。 不同的 SHUTDOWN 參數:NORMAL、TRANSACTIONAL、IMMEDIATE 有著不同的準備 動作。 • NORMAL:當使用這個參數時,從執行關閉指令之後,不允許建立新的階段作業 (Session)。但已經建立的階段作業,依然可以繼續進行。這時並沒有強制要求階段作 業結束,是由階段作業自己決定結束與否。因此可能無法確定何時能夠開始關閉資料 庫的動作。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。當 SHUTDOWN 指令後面沒有加上其他參數,預設以 NORMAL 方式執行關閉指令。
  • 35. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice • TRANSACTIONAL:當使用這個參數時,從執行關閉指令之後,不允許建立新的階段 作業。但是現有的階段作業,可以繼續正在進行的交易。不過交易完成後,就強迫結 束該階段作業。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。 • IMMEDIATE: 當使用這個參數時, 從執行關閉指令之後,除不允許建立新的階段作 業外,而且所有進行中的交易,立刻開始退回。當交易退回完成後,就強迫結束現有 階段作業。等到所有的階段作業都結束後,才開始進行關閉資料庫的動作。 卸載資料庫(Dismount) 執行處理關閉所有的控制檔,加上關閉資料庫階段所關閉的資料檔與線上重做日誌檔,執行 處理已經完全與資料庫不存在任何關連。執行處理關閉控制檔後,表示控制檔的內容不會再 被改變。 關閉執行處理(Shutdown) 系統整體區域(System Global Area)的記憶體空間將被作業系統收回,而且所有的背景處理作 業也將被終止,所以現在的執行處理將不復存在。若執行 SHUTDOWN ABORT 指令,則會 直接跳到關閉執行處理這一個階段,而沒有經過關閉資料庫與卸載資料庫的過程。因此在緩 衝區快取的髒緩衝都還未寫回資料檔,而進行中的交易也沒有結束。所以當下一次啓動新的 執行處理時,必須先進行執行處理復原來修復資料庫不一致的狀況。 [oracle@Elinux ~]$ echo $ORACLE_SID orcl [oracle@Elinux ~]$ sqlplus / AS SYSDBA /*需要sysdba權限,才能啓動或關閉Instance*/ Connected. /*代表Instance(orcl)已經啓動*/ SQL> SELECT status FROM v$instance; STATUS ------------ OPEN /*要求正常地關閉datafile與online redo logfile,此指令僅用在示範關閉資料庫的動作。平 常請使用SHUTSOWN指令來關閉資料庫*/ SQL> ALTER DATABASE CLOSE;
  • 36. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice SQL> SELECT status FROM v$instance; STATUS ------------ MOUNTED SQL> ALTER DATABASE OPEN; /*不能使用現在的Instance再次開啓datafile與logfile*/ alter database open * ERROR at line 1: ORA-16196: database has been previously opened and closed SQL> ALTER DATABASE DISMOUNT; /*關閉controfile*/ SQL> SELECT status FROM v$instance; STATUS ------------ STARTED SQL> ALTER DATABASE MOUNT; /*不能使用現在的Instance再次掛載controlfile*/ alter database mount * ERROR at line 1: ORA-00750: database has been previously mounted and dismounted SQL> SHUTDOWN IMMEDIATE ORA-01507: database not mounted ORACLE instance shut down.
  • 37. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.6.3 執行處理復原(Instance Recovery) 當執行處理的狀態由掛載到開啟資料庫的過程中,執行處理先檢查資料檔及線上重做日誌檔 是否存在。若狀態為線上的資料檔不存在則需要先復原該資料檔,之後才能繼續開啟資料庫 的動作。若某一個日誌群組的日誌成員不存在,則要確定該日誌群組有幾個日誌成員。只要 每個日誌群組中,至少有一個日誌成員可以被開啟,便不需要在這個階段復原該日誌成員, 而可以順利地繼續進行開啟資料庫的動作。 此外執行處理還會檢查資料檔標頭的最後檢查點號碼(Least Checkpoint Number)與控制檔 的最後檢查點號碼是否一致。如果兩者一致,代表前次資料庫關閉操作為正常關閉,也就是 有經過關閉資料庫與卸載資料庫的步驟,也表示所使用的關閉指令為 SHUTDOWN NORMAL、 TRANSACTIONAL、IMMEDIATE 其中之一。因此當重新啟動的執行處理開啟資料庫時,不 需要進行執行處理復原來恢復資料庫的內容。 倘若兩者的最後檢查點號碼不一致,則代表資料庫沒有經過正常的關閉過程,而是直接將執 行處理關閉或發生執行處理崩潰。所以執行處理的髒緩衝(Dirty Buffer)並未寫回資料檔,而 且進行中交易也未被退回。所以需要進行執行處理復原將所有的髒緩衝復原,並將它們寫回 資料檔,之後還要退回未確認的交易。 執行處理復原分成三個階段:重做異動(Rollforward)、開啟資料庫(Open)、退回未確認交易 (Rollback),在每個階段進行不同復原操作。 重做異動(Roll forward) 重做異動用來將所有的髒緩衝復原,SMON 由控制檔取得重做位元位置(Redo Byte Address) 的位置後,將線上重做日誌檔所有位於重做位元位置以後的重做項目,重新執行一次,直到 將所有的重做項目都被執行過一次為止,這個動作可以將之前執行處理的緩衝區快取的所有 髒緩衝重新產生,這些髒緩衝的來源包括已確認的交易與進行中的交易。之後 CKPT 立刻進 行一次完整的檢查點事件(Full Checkpoint),要求 DBWR 將所有髒緩衝都寫回資料檔, DBWR 完成工作後,CKPT 將檢查點資訊寫到所有的資料檔檔頭與控制檔,當資料檔檔頭與 控制檔的檢查點資訊一致後,執行處理便可以繼續開啟資料庫了。 開啟資料庫(Open)
  • 38. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 當執行處理開啟資料庫後,資料庫使用者便可以登入資料庫,進行一般的資料庫操作。雖然 重做異動階段已經將所有的髒緩衝復原,因此將所有已確認的交易復原。但是重做異動階段 也將未確認的交易一同復原,所以 SMON 開始退回之前的未確認交易。 退回未確認交易(Roll back) 重做異動的結果是所有的髒緩衝都成功地復原,回到前一個執行處理關閉前的狀態。因此保 證所有已經確認交易的髒緩衝都成功地復原,然而未確認交易也同時被復原。此時 SMON 利 用所復原的還原區段(Undo Segment)內容,將未確認的交易全數退回。當退回交易操作完成 後,前一個執行處理不正常關閉所帶來的資料庫不一致狀態,便可以完全解決。
  • 39. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.7 SQL 敘述句的執行過程 在 Oracle 伺服器的架構下,只有使用 SQL 敘述句才能操作資料庫的資料。然而執行 SQL 敘 述句時,所使用到的共用記憶體元件、背景處理作業與資料庫檔案,將因為不同的 SQL 敘述 句而有所不同。以下使用最基本的 SQL 敘述句:Select、DML、Commit 進行說明,讓資料 庫管理者知道這些 SQL 敘述句如何進行。 每個 SQL 敘述句都必須先由使用者處理作業(User Process)產生,然後傳到相對應的伺服器 處理作業,之後由伺服器處理作業代表使用者處理作業執行該 SQL 敘述句。如果是 Select 指令,伺服器處理作業還需要將 Select 的結果回傳給使用者處理作業。 當伺服器處理作業收到每個 SQL 敘述句時,必須經過下列步驟才能完成操作: 解析 (Parse)→繫結(Bind)→執行(Exectue)→提取(Fetch,只有 Select 才需要此步驟)。 2.7.1 解析(Parse) 因為 SQL 敘述句的用途,是用來描述使用者所想要的資料為何?伺服器處理作業如何去執行 這個 SQL 敘述句。因此當伺服器處理作業收到一個 SQL 敘述句時,首先將其轉換成最有效 率的執行這個 SQL 敘述句的步驟,這些步驟被稱為執行計畫(Execution Plan)。而產生執行 計畫的過程,可以細分為以下的幾個步驟: 1.檢查共用集區(Shared Pool)是否有之前解析相同 SQL 敘述句後,所儲存的 SQL 本文 (SQL Text)、解析樹(Parse Tree)與執行計畫(Execution Plan)。 如果能在共用集區的程式庫快取(Library Cache)中找到之前解析過的執行計畫,則此 SQL 敘 述句便不需要再次解析,直接由程式庫快取得到之前所產生的執行計畫,便可以直接跳到執 行階段,這種解析動作稱做軟解析(Soft Parse)。 但是若沒有在程式庫快取中找到之前解析過的相關資料,則必須繼續進行解析步驟,這種解 析稱做硬解析(Hard Parse)。 伺服器處理作業要如何得知這個 SQL 敘述句有相關的資料儲存在共用集區中?當然不可能搜 索整個共用集區,因為這樣太耗系統資源。所以伺服器處理作業採用一種比較簡單的方式, 就是將 SQL 敘述句的每個字符(Character)都先轉為 ASCII Code,再使用特殊的雜湊函數將 ASCII Code 轉成雜湊值(Hash Value)。如果這個 SQL 敘述句曾經被解析過,那麼這個 SQL 敘述句的 SQL 本文、解析樹與執行計畫將會被存放在共用集區的某個位置。而這個雜湊值便
  • 40. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 是這個位置表示值。因此使用這個雜湊值讀取共用集區該位置的內容,如果該位置真的有資 料,但也不代表所存放執行計畫可以直接使用,還要進一步比對 SQL 本文(SQL Text)是否一 致,因為可能會有一個以上的 SQL 敘述句的雜湊值恰巧相同。 SQL> select last_name from employees where employee_id=100; SQL> select last_name from employees where employee_id=200; SQL> SELECT hash_value,address,executions,sql_text 2> FROM v$sql 3> WHERE sql_text LIKE 'select last_name from employees where employee_id= %'; HASH_VALUE ADDRESS EXECUTIONS ------------------- --------------- ------------------- SQL_TEXT -------------------------------------------------------------------------------- 2627784799 329AEEF4 1 select last_name from hr.employees where employee_id=200 280342537 2EBE0FA4 1 select last_name from hr.employees where employee_id=100 以上圖為例,這兩個 SQL 敘述句看似相同,只有文字(Literal)不一樣(一個為 100、另一個為 200),但是 100 與 200 的 ASCII Code 值就不相同了,所以整個雜湊後的結果自然也不相 同。所以這兩個 SQL 敘述句都將被解析,但解析的動作相當耗 CPU 的運算資源,所此硬解 析的次數越多,則 Oracle 伺服器的效能越差。 SQL> variable empid number; SQL> execute :empid := 100; SQL> select last_name from hr.employees where employee_id=:empid; SQL> execute :empid := 200; SQL> select last_name from hr.employees where employee_id=:empid SQL> SELECT hash_value,address,executions,sql_text 2> FROM v$sql 3> WHERE sql_text LIKE 'select last_name from employees where employee_id= %'; HASH_VALUE ADDRESS EXECUTIONS ------------------- --------------- ------------------- SQL_TEXT -------------------------------------------------------------------------------- 476476418 3290C280 2
  • 41. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice select last_name from hr.employees where employee_id=:empid /*雖然SQL敘述句被執行2次,卻只解析一次.因為這2個的SQL敘述句完全相同.所以Execute階 段時,才會將:empid以100或200的值取代*/ 2.檢查 SQL 敘述句的語法是否有錯誤。 SQL> SELECT * FORM employees; SELECT * FORM employees --FROM打字錯誤為FORM * ERROR at line 1: ORA-00923: FROM keyword not found where expected 3.檢查 SQL 敘述句的語義是否有錯誤以及是否擁有足夠的權限。 SQL> SELECT ename FROM employees; SELECT ename FROM employees --employees表格中沒有叫做ename的欄位 * ERROR at line 1: ORA-00904: "ENAME": invalid identifier SQL> SELECT prod_id FROM sh.products; SELECT prod_id FROM sh.products --使用者沒有SELECT該表格的權限 * ERROR at line 1: ORA-00942: table or view does not exist 4.決定最佳的執行計畫(Execution Plan)。最佳化處理程式(Optimizer)會先產生多個執行計畫, 再將統計值(Statistics)帶入,找出執行成本最低的執行計畫,為執行此 SQL 敘述句的執行計 畫。 5.將 SQL 本文(SQL Text)、解析樹(Parse Tree)、執行計畫(Execution Plan)儲存在程式庫 快取,存放位置以 SQL 敘述句所計算出的雜湊值為起始位置。 2.7.2 繫結(Bind) 若 SQL 敘述句有使用繫結變數(Bind Variable),將在此時將變數值帶入執行計畫。
  • 42. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 2.7.3 執行(Execute) 此階段為依據執行計畫進行的操作。不同型態的 SQL 敘述句,執行過程當然不同。 查詢(SELECT) 1.檢查所需的資料區塊(Data Block)是否已經存在於緩衝區快取(Buffer Cache)。如果已經存 在於緩衝區快取中,則直接讀取其內容即可。這種讀取方式,稱為邏輯讀取(Logical Read)。 2.若所需的資料區塊並不存在於緩衝區快取中,則伺服器處理作業(Server Process)將資料區 塊由資料檔讀到緩衝區快取。首先伺服器處理作業必須先找到足夠的可使用緩衝後,才能由 資料檔讀入所需的資料區塊。這種讀取方式,稱為實體讀取(Physical Read),相較於邏輯讀 取,所耗費的系統資源較多,所花費的時間也較長。資料庫管理者應該盡量減少此種讀取的 次數與數量。
  • 43. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 異動(INSERT/UPDATE/DELETE) 1.檢查所需的資料區塊是否已經被讀到緩衝區快取。如果已經存在於緩衝區快取中,則直接 進行步驟 3。 2.若所需的資料區塊並不存在於緩衝區快取中,則伺服器處理作業(Server Process)將資料區 塊由資料檔讀到緩衝區快取中。 3.對想要異動的表格取得資料列獨佔鎖定(Row Exclusive Lock),之後對所要異動的資料列 (Row)取得獨佔鎖定(Exclusive Lock)。 4.伺服器處理作業必須先將資料列的重做項目(Redo Entry)複製到日誌緩衝區(Log Buffer)後, 才能異動資料列。除了異動前要先產生重做項目外,伺服器處理作業還要將如何還原異動前 資料的還原資料儲存到還原區段(Undo Segment),當完成前述工作後才能開始異動。可是將 還原資料記錄到還原區段時,也需要產生相對的重做項目,才能將還原資料(Undo Data)記錄 到還原區段。不過不需要再對還原資料的異動產生還原記錄。 所以資料列異動時相關動作的順序如下:產生原資料的重做項目與資料列異動的重做項目→ 將還原資料的重做項目與資料列異動的重做項目一同複製到日誌緩衝區→產生資料列的還原 資料→異動資料列。 5.複製資料列異動的重做項目到日誌緩衝區中。 6.產生資料列異動的還原資料。 7.異動資料列的內容,如果之前緩衝為乾淨緩衝(Clean Buffer),此時將變為髒緩衝。
  • 44. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 交易確認(COMMIT) 1. 當使用者確認交易的指令傳遞到伺服器處理作業時,伺服器處理作業將交易確認的重做項 目複製到日誌緩衝區。 2.此時 LGWR 立即被觸發,將所有在日誌緩衝區但尚未寫到線上重做日誌檔的重做項目,依 時間順序寫到線上重做日誌檔。 3.當 LGWR 完成寫入後。該交易就此結束,所以該交易所握有的所有鎖定(Lock)、執行處理 資源(Resource)也將被釋放。
  • 45. Chapter 1 – Oracle Server 基本介紹 Oracle Database Management Best Practice 4.伺服器處理作業回應交易確認完成(Committed)的訊息使用者處理作業。 提取(FETCH)-僅查詢指令才需要此步驟 這個步驟只是提取 Select 敘述句的結果回應給使用者處理作業。 結論 本章節的內容著重於介紹組成 Oracle 伺服器的各個元件的的名字與其專門的功能,在進一步 學習 Oracle 資料庫之前,熟悉這些結構的用途與彼此間的關係是相當重要的先決條件。有了 這些基本的知識後,才能順利地由往後的章節中,學習到 Oracle 資料庫更深入的知識,進而 徹底的掌握住 Oracle 資料庫的特性。