MySQL 體系架構(gòu) 

一.邏輯模塊組成

總的來說，MySQL 可以看成是二層架構(gòu)，***層我們通常叫做SQL Layer，在MySQL 數(shù)據(jù)庫系統(tǒng)處理底層數(shù)據(jù)之前的所有工作都是在這一層完成的，包括權(quán)限判斷，sql 解析，執(zhí)行計(jì)劃優(yōu)化，querycache 的處理等等；    第二層就是存儲(chǔ)引擎層，我們通常叫做Storage Engine Layer，也就是底層數(shù)據(jù)存取操作實(shí)現(xiàn)部分，由多種存儲(chǔ)引擎共同組成。所以，可以用如下一張最簡單的架構(gòu)示意圖來表示MySQL 的基本架構(gòu)，如圖2-1 所示：

雖然從上圖看起來MySQL 架構(gòu)非常的簡單，就是簡單的兩部分而已，但實(shí)際上每一層中都含有各自的很多小模塊，尤其是***層SQL Layer，結(jié)構(gòu)相當(dāng)復(fù)雜的。下面我們就分別針對(duì)SQL Layer 和Storage Engine Layer 做一個(gè)簡單的分析。 

SQL Layer 中包含了多個(gè)子模塊，下面我將逐個(gè)做一下簡單的介紹：

1、初始化模塊

顧名思議，初始化模塊就是在MySQL Server 啟動(dòng)的時(shí)候，對(duì)整個(gè)系統(tǒng)做各種各樣的初始化操作，比如各種buffer，cache 結(jié)構(gòu)的初始化和內(nèi)存空間的申請(qǐng)，各種系統(tǒng)變量的初始化設(shè)定，各種存儲(chǔ)引擎的初始化設(shè)置，等等。 

2、核心API

核心API 模塊主要是為了提供一些需要非常高效的底層操作功能的優(yōu)化實(shí)現(xiàn)，包括各種底層數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)，特殊算法的實(shí)現(xiàn)，字符串處理，數(shù)字處理等，小文件I/O，格式化輸出，以及最重要的內(nèi)存管理部分。核心API 模塊的所有源代碼都集中在mysys和strings文件夾下面，有興趣的讀者可以研究研究。 

3、網(wǎng)絡(luò)交互模塊

底層網(wǎng)絡(luò)交互模塊抽象出底層網(wǎng)絡(luò)交互所使用的接口api，實(shí)現(xiàn)底層網(wǎng)絡(luò)數(shù)據(jù)的接收與發(fā)送，以方便其他各個(gè)模塊調(diào)用，以及對(duì)這一部分的維護(hù)。所有源碼都在vio 文件夾下面。 

4、Client& Server 交互協(xié)議模塊

任何C/S 結(jié)構(gòu)的軟件系統(tǒng)，都肯定會(huì)有自己獨(dú)有的信息交互協(xié)議，MySQL 也不例外。MySQL的Client & Server 交互協(xié)議模塊部分，實(shí)現(xiàn)了客戶端與MySQL 交互過程中的所有協(xié)議。當(dāng)然這些協(xié)議都是建立在現(xiàn)有的OS 和網(wǎng)絡(luò)協(xié)議之上的，如TCP/IP 以及Unix Socket。 

5、用戶模塊

用戶模塊所實(shí)現(xiàn)的功能，主要包括用戶的登錄連接權(quán)限控制和用戶的授權(quán)管理。他就像MySQL 的大門守衛(wèi)一樣，決定是否給來訪者“開門”。 

6、訪問控制模塊

造訪客人進(jìn)門了就可以想干嘛就干嘛么？為了安全考慮，肯定不能如此隨意。這時(shí)候就需要訪問控制模塊實(shí)時(shí)監(jiān)控客人的每一個(gè)動(dòng)作，給不同的客人以不同的權(quán)限。訪問控制模塊實(shí)現(xiàn)的功能就是根據(jù)用戶模塊中各用戶的授權(quán)信息，以及數(shù)據(jù)庫自身特有的各種約束，來控制用戶對(duì)數(shù)據(jù)的訪問。用戶模塊和訪問控制模塊兩者結(jié)合起來，組成了MySQL 整個(gè)數(shù)據(jù)庫系統(tǒng)的權(quán)限安全管理的功能。 

7、連接管理、連接線程和線程管理

連接管理模塊負(fù)責(zé)監(jiān)聽對(duì)MySQL Server 的各種請(qǐng)求，接收連接請(qǐng)求，轉(zhuǎn)發(fā)所有連接請(qǐng)求到線程管理模塊。每一個(gè)連接上MySQL Server 的客戶端請(qǐng)求都會(huì)被分配（或創(chuàng)建）一個(gè)連接線程為其單獨(dú)服務(wù)。而連接線程的主要工作就是負(fù)責(zé)MySQL Server 與客戶端的通信，接受客戶端的命令請(qǐng)求，傳遞Server 端的結(jié)果信息等。線程管理模塊則負(fù)責(zé)管理維護(hù)這些連接線程。包括線程的創(chuàng)建，線程的cache 等。 

8、Query 解析和轉(zhuǎn)發(fā)模塊

在MySQL 中我們習(xí)慣將所有Client端發(fā)送給Server 端的命令都稱為query，在MySQL Server 里面，連接線程接收到客戶端的一個(gè)Query 后，會(huì)直接將該query 傳遞給專門負(fù)責(zé)將各種Query 進(jìn)行分類然后轉(zhuǎn)發(fā)給各個(gè)對(duì)應(yīng)的處理模塊，這個(gè)模塊就是query 解析和轉(zhuǎn)發(fā)模塊。其主要工作就是將query 語句進(jìn)行語義和語法的分析，然后按照不同的操作類型進(jìn)行分類，然后做出針對(duì)性的轉(zhuǎn)發(fā)。 

9、QueryCache 模塊

Query Cache 模塊在MySQL 中是一個(gè)非常重要的模塊，他的主要功能是將客戶端提交給MySQL 的Select 類query 請(qǐng)求的返回結(jié)果集cache 到內(nèi)存中，與該query 的一個(gè)hash 值做一個(gè)對(duì)應(yīng)。該Query 所取數(shù)據(jù)的基表發(fā)生任何數(shù)據(jù)的變化之后，MySQL 會(huì)自動(dòng)使該query 的Cache 失效。在讀寫比例非常高的應(yīng)用系統(tǒng)中，Query Cache 對(duì)性能的提高是非常顯著的。當(dāng)然它對(duì)內(nèi)存的消耗也是非常大的。 

10、Query 優(yōu)化器模塊

Query 優(yōu)化器，顧名思義，就是優(yōu)化客戶端請(qǐng)求的query，根據(jù)客戶端請(qǐng)求的query 語句，和數(shù)據(jù)庫中的一些統(tǒng)計(jì)信息，在一系列算法的基礎(chǔ)上進(jìn)行分析，得出一個(gè)***的策略，告訴后面的程序如何取得這個(gè)query 語句的結(jié)果。 

11、表變更管理模塊

表變更管理模塊主要是負(fù)責(zé)完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語句的處理。 

12、表維護(hù)模塊

表的狀態(tài)檢查，錯(cuò)誤修復(fù)，以及優(yōu)化和分析等工作都是表維護(hù)模塊需要做的事情。 

13、系統(tǒng)狀態(tài)管理模塊

系統(tǒng)狀態(tài)管理模塊負(fù)責(zé)在客戶端請(qǐng)求系統(tǒng)狀態(tài)的時(shí)候，將各種狀態(tài)數(shù)據(jù)返回給用戶，像DBA 常用的各種showstatus 命令，showvariables 命令等，所得到的結(jié)果都是由這個(gè)模塊返回的。 

14、表管理器

這個(gè)模塊從名字上看來很容易和上面的表變更和表維護(hù)模塊相混淆，但是其功能與變更及維護(hù)模塊卻完全不同。大家知道，每一個(gè)MySQL 的表都有一個(gè)表的定義文件，也就是*.frm文件。表管理器的工作主要就是維護(hù)這些文件，以及一個(gè)cache，該cache 中的主要內(nèi)容是各個(gè)表的結(jié)構(gòu)信息。此外它還維護(hù)table 級(jí)別的鎖管理。 

15、日志記錄模塊

日志記錄模塊主要負(fù)責(zé)整個(gè)系統(tǒng)級(jí)別的邏輯層的日志的記錄，包括error log，binary log，slow query log 等。 

16、復(fù)制模塊

復(fù)制模塊又可分為Master 模塊和Slave 模塊兩部分， Master 模塊主要負(fù)責(zé)在Replication 環(huán)境中讀取Master 端的binary 日志，以及與Slave 端的I/O 線程交互等工作。

Slave 模塊比Master 模塊所要做的事情稍多一些，在系統(tǒng)中主要體現(xiàn)在兩個(gè)線程上面。一個(gè)是負(fù)責(zé)從Master請(qǐng)求和接受binary 日志，并寫入本地relay log 中的I/O 線程。另外一個(gè)是負(fù)責(zé)從relay log 中讀取相關(guān)日志事件，然后解析成可以在Slave 端正確執(zhí)行并得到和Master端完全相同的結(jié)果的命令并再交給Slave 執(zhí)行的SQL 線程。 

17、存儲(chǔ)引擎接口模塊

存儲(chǔ)引擎接口模塊可以說是MySQL 數(shù)據(jù)庫中最有特色的一點(diǎn)了。目前各種數(shù)據(jù)庫產(chǎn)品中，基本上只有MySQL 可以實(shí)現(xiàn)其底層數(shù)據(jù)存儲(chǔ)引擎的插件式管理。這個(gè)模塊實(shí)際上只是一個(gè)抽象類，但正是因?yàn)樗晒Φ貙⒏鞣N數(shù)據(jù)處理高度抽象化，才成就了今天MySQL 可插拔存儲(chǔ)引擎的特色。  

二.各模塊工作配合

在了解了MySQL 的各個(gè)模塊之后，我們?cè)倏纯碝ySQL各個(gè)模塊間是如何相互協(xié)同工作的。

接下來，我們通過啟動(dòng)MySQL，客戶端連接，請(qǐng)求query，得到返回結(jié)果，***退出，這樣一整個(gè)過程來進(jìn)行分析。

當(dāng)我們執(zhí)行啟動(dòng)MySQL 命令之后，MySQL 的初始化模塊就從系統(tǒng)配置文件中讀取系統(tǒng)參數(shù)和命令行參數(shù)，并按照參數(shù)來初始化整個(gè)系統(tǒng)，如申請(qǐng)并分配buffer，初始化全局變量，以及各種結(jié)構(gòu)等。同時(shí)各個(gè)存儲(chǔ)引擎也被啟動(dòng)，并進(jìn)行各自的初始化工作。當(dāng)整個(gè)系統(tǒng)初始化結(jié)束后，由連接管理模塊接手。連接管理模塊會(huì)啟動(dòng)處理客戶端連接請(qǐng)求的監(jiān)聽程序，包括tcp/ip 的網(wǎng)絡(luò)監(jiān)聽，還有unix 的socket。這時(shí)候，MySQL Server 就基本啟動(dòng)完成，準(zhǔn)備好接受客戶端請(qǐng)求了。

當(dāng)連接管理模塊監(jiān)聽到客戶端的連接請(qǐng)求（借助網(wǎng)絡(luò)交互模塊的相關(guān)功能），雙方通過Client & Server 交互協(xié)議模塊所定義的協(xié)議“寒暄”幾句之后，連接管理模塊就會(huì)將連接請(qǐng)求轉(zhuǎn)發(fā)給線程管理模塊，去請(qǐng)求一個(gè)連接線程。

線程管理模塊馬上又會(huì)將控制交給連接線程模塊，告訴連接線程模塊：現(xiàn)在我這邊有連接請(qǐng)求過來了，需要建立連接，你趕快處理一下。連接線程模塊在接到連接請(qǐng)求后，首先會(huì)檢查當(dāng)前連接線程池中是否有被cache 的空閑連接線程，如果有，就取出一個(gè)和客戶端請(qǐng)求連接上，如果沒有空閑的連接線程，則建立一個(gè)新的連接線程與客戶端請(qǐng)求連接。當(dāng)然，連接線程模塊并不是在收到連接請(qǐng)求后馬上就會(huì)取出一個(gè)連接線程連和客戶端連接，而是首先通過調(diào)用用戶模塊進(jìn)行授權(quán)檢查，只有客戶端請(qǐng)求通過了授權(quán)檢查后，他才會(huì)將客戶端請(qǐng)求和負(fù)責(zé)請(qǐng)求的連接線程連上。

在MySQL 中，將客戶端請(qǐng)求分為了兩種類型：一種是query，需要調(diào)用Parser 也就是Query 解析和轉(zhuǎn)發(fā)模塊的解析才能夠執(zhí)行的請(qǐng)求；一種是command，不需要調(diào)用Parser 就可以直接執(zhí)行的請(qǐng)求。如果我們的初始化配置中打開了Full QueryLogging 的功能，那么Query 解析與轉(zhuǎn)發(fā)模塊會(huì)調(diào)用日志記錄模塊將請(qǐng)求計(jì)入日志，不管是一個(gè)Query 類型的請(qǐng)求還是一個(gè)command 類型的請(qǐng)求，都會(huì)被記錄進(jìn)入日志，所以出于性能考慮，一般很少打開Full QueryLogging 的功能。

當(dāng)客戶端請(qǐng)求和連接線程“互換暗號(hào)（互通協(xié)議）”接上頭之后，連接線程就開始處理客戶端請(qǐng)求發(fā)送過來的各種命令（或者query），接受相關(guān)請(qǐng)求。它將收到的query語句轉(zhuǎn)給Query 解析和轉(zhuǎn)發(fā)模塊，Query 解析器先對(duì)Query 進(jìn)行基本的語義和語法解析，然后根據(jù)命令類型的不同，有些會(huì)直接處理，有些會(huì)分發(fā)給其他模塊來處理。

如果是一個(gè)Query 類型的請(qǐng)求，會(huì)將控制權(quán)交給Query解析器。Query 解析器首先分析看是不是一個(gè)select 類型的query，如果是，則調(diào)用查詢緩存模塊，讓它檢查該query 在query cache 中是否已經(jīng)存在。如果有，則直接將cache 中的數(shù)據(jù)返回給連接線程模塊，然后通過與客戶端的連接的線程將數(shù)據(jù)傳輸給客戶端。如果不是一個(gè)可以被cache 的query類型，或者cache 中沒有該query 的數(shù)據(jù)，那么query 將被繼續(xù)傳回query 解析器，讓query解析器進(jìn)行相應(yīng)處理，再通過query 分發(fā)器分發(fā)給相關(guān)處理模塊。

如果解析器解析結(jié)果是一條未被cache 的select 語句，則將控制權(quán)交給Optimizer，也就是Query 優(yōu)化器模塊，如果是DML 或者是DDL 語句，則會(huì)交給表變更管理模塊，如果是一些更新統(tǒng)計(jì)信息、檢測(cè)、修復(fù)和整理類的query 則會(huì)交給表維護(hù)模塊去處理，復(fù)制相關(guān)的query 則轉(zhuǎn)交給復(fù)制模塊去進(jìn)行相應(yīng)的處理，請(qǐng)求狀態(tài)的query 則轉(zhuǎn)交給了狀態(tài)收集報(bào)告模塊。實(shí)際上表變更管理模塊根據(jù)所對(duì)應(yīng)的處理請(qǐng)求的不同，是分別由insert 處理器、delete 處理器、update 處理器、create 處理器，以及alter 處理器這些小模塊來負(fù)責(zé)不同的DML和DDL 的。 

在各個(gè)模塊收到Query 解析與分發(fā)模塊分發(fā)過來的請(qǐng)求后，首先會(huì)通過訪問控制模塊檢查連接用戶是否有訪問目標(biāo)表以及目標(biāo)字段的權(quán)限，如果有，就會(huì)調(diào)用表管理模塊請(qǐng)求相應(yīng)的表，并獲取對(duì)應(yīng)的鎖。表管理模塊首先會(huì)查看該表是否已經(jīng)存在于table cache 中，如果已經(jīng)打開則直接進(jìn)行鎖相關(guān)的處理，如果沒有在cache 中，則需要再打開表文件獲取鎖，然后將打開的表交給表變更管理模塊。 

當(dāng)表變更管理模塊“獲取”打開的表之后，就會(huì)根據(jù)該表的相關(guān)meta 信息，判斷表的存儲(chǔ)引擎類型和其他相關(guān)信息。根據(jù)表的存儲(chǔ)引擎類型，提交請(qǐng)求給存儲(chǔ)引擎接口模塊，調(diào)用對(duì)應(yīng)的存儲(chǔ)引擎實(shí)現(xiàn)模塊，進(jìn)行相應(yīng)處理。

不過，對(duì)于表變更管理模塊來說，可見的僅是存儲(chǔ)引擎接口模塊所提供的一系列“標(biāo)準(zhǔn)”接口，底層存儲(chǔ)引擎實(shí)現(xiàn)模塊的具體實(shí)現(xiàn)，對(duì)于表變更管理模塊來說是透明的。他只需要調(diào)用對(duì)應(yīng)的接口，并指明表類型，接口模塊會(huì)根據(jù)表類型調(diào)用正確的存儲(chǔ)引擎來進(jìn)行相應(yīng)的處理。

當(dāng)一條query 或者一個(gè)command 處理完成（成功或者失?。┲螅刂茩?quán)都會(huì)交還給連接線程模塊。如果處理成功，則將處理結(jié)果（可能是一個(gè)Result set，也可能是成功或者失敗的標(biāo)識(shí)）通過連接線程反饋給客戶端。如果處理過程中發(fā)生錯(cuò)誤，也會(huì)將相應(yīng)的錯(cuò)誤信息發(fā)送給客戶端，然后連接線程模塊會(huì)進(jìn)行相應(yīng)的清理工作，并繼續(xù)等待后面的請(qǐng)求，重復(fù)上面提到的過程，或者完成客戶端斷開連接的請(qǐng)求。

如果在上面的過程中，相關(guān)模塊使數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生了變化，而且MySQL 打開了binlog 功能，則對(duì)應(yīng)的處理模塊還會(huì)調(diào)用日志處理模塊將相應(yīng)的變更語句以更新事件的形式記錄到相關(guān)參數(shù)指定的二進(jìn)制日志文件中。

在上面各個(gè)模塊的處理過程中，各自的核心運(yùn)算處理功能部分都會(huì)高度依賴整個(gè)MySQL的核心API 模塊，比如內(nèi)存管理，文件I/O，數(shù)字和字符串處理等等。 

了解到整個(gè)處理過程之后，我們可以將以上各個(gè)模塊畫成如圖2-2 的關(guān)系圖：

 

下面這個(gè)是官方文檔里的一個(gè)圖：

Oracle體系結(jié)構(gòu)介紹   --基礎(chǔ)篇

在學(xué)習(xí)oracle中，體系結(jié)構(gòu)是重中之重，掌握的越深入越好。在實(shí)際工作遇到疑難問題，其實(shí)都可以歸結(jié)到體系結(jié)構(gòu)中來解釋，所以我們根據(jù)下面的示圖了解一下oracle體系結(jié)構(gòu)。

1. Summarize

根據(jù)示圖，便于我們記憶，示圖分三部分組成，左側(cè)User Process、Server Process、PGA可以看做成Clinet端，上面的實(shí)例（Instance）和下面的數(shù)據(jù)庫（Database）及參數(shù)文件（parameter file）、密碼文件（password file）和歸檔日志文件（archived logfiles）組成Oracle Server，所以整個(gè)示圖可以理解成一個(gè)C/S架構(gòu)。

Oracle Server 由兩個(gè)實(shí)體組成：實(shí)例（instance）與數(shù)據(jù)庫（database）。這兩個(gè)實(shí)體是獨(dú)立的，不過連接在一起。在數(shù)據(jù)庫創(chuàng)建過程中，實(shí)例首先被創(chuàng)建，然后才創(chuàng)建數(shù)據(jù)庫。在典型的單實(shí)例環(huán)境中，實(shí)例與數(shù)據(jù)庫的關(guān)系是一對(duì)一的，一個(gè)實(shí)例連接一個(gè)數(shù)據(jù)庫，實(shí)例與數(shù)據(jù)庫也可以是多對(duì)一的關(guān)系，即不同計(jì)算機(jī)上的多個(gè)實(shí)例打開共享磁盤系統(tǒng)上的一個(gè)公用數(shù)據(jù)庫。這種多對(duì)一關(guān)系被稱為實(shí)際應(yīng)用群集（Real Application Clusters，RAC）RAC極大提高了數(shù)據(jù)庫的性能、容錯(cuò)與可伸縮性（可能耗費(fèi)更多的存儲(chǔ)空間）并且是oracle網(wǎng)格（grid）概念的必備部分。

2. Client端

在Client端的作用是如何從客戶端創(chuàng)建服務(wù)器進(jìn)程與數(shù)據(jù)庫進(jìn)行交互的過程。

2.1 User process

用戶運(yùn)行一個(gè)應(yīng)用程序時(shí)與Oracle數(shù)據(jù)庫進(jìn)程交互（例如：sql/plus）時(shí)，oracle創(chuàng)建一個(gè)用戶進(jìn)程來運(yùn)行用戶的應(yīng)用程序。

2.2 Server process

Server Process是用來處理連接到實(shí)例的用戶進(jìn)程（User Process）提交的請(qǐng)求。當(dāng)應(yīng)用程序與Oracle服務(wù)器運(yùn)行在同一臺(tái)機(jī)器上時(shí)，某些用戶進(jìn)程（User Process）可以與Server Process合并為同一個(gè)進(jìn)程，即便減小系統(tǒng)開銷。從邏輯層面來講，用戶進(jìn)程必須要通過一個(gè)Server Process來同Oracle進(jìn)行通信的.（只不過有些時(shí)候在同一臺(tái)機(jī)器的時(shí)候，某些User Process和Server Process會(huì)合并罷了）

2.3 PGA

PGA（Program Global Area）程序全局區(qū)，是用戶進(jìn)程連接到數(shù)據(jù)庫并創(chuàng)建一個(gè)會(huì)話時(shí)，由Oracle服務(wù)器進(jìn)程分配的專門用于當(dāng)前用戶會(huì)話的內(nèi)存區(qū)，該區(qū)域是私有的。

為每個(gè)用戶連接Oracle數(shù)據(jù)庫保留的內(nèi)存

當(dāng)進(jìn)程創(chuàng)建時(shí)分配

進(jìn)程結(jié)束后被釋放

只能被一個(gè)進(jìn)程使用

參數(shù)：PGA_AGGREGATE_TARGET指定PGA的總共大小

3. Database

 "3+3"結(jié)構(gòu)，3個(gè)必要文件+3個(gè)可選文件。

3.1 Data files

內(nèi)容：

1）用戶數(shù)據(jù)：用戶表、DML語句可調(diào)整；

2）數(shù)據(jù)字典數(shù)據(jù)：數(shù)據(jù)字典表記錄DB結(jié)構(gòu)、只讀不可修改、DDL語句調(diào)整

3）真實(shí)看到的文件

作用：

讀取數(shù)據(jù)

特點(diǎn)：

1）至少包含一個(gè)SYSTEM表空間、DDL語言

2）各種不同表空間 數(shù)據(jù)字典信息

3）我的數(shù)據(jù)保存在表空間上，表空間是以多個(gè)數(shù)據(jù)文件的形式體現(xiàn)的。

3.2 Control files

內(nèi)容：

1）DB基本信息：DBID

2）DB結(jié)構(gòu)信息

3）***一次同步的SCN信息

3.1）同步：內(nèi)存區(qū)域database buffer cache的臟數(shù)據(jù)寫出磁盤

3.2）SCN:（system change number），時(shí)間軸、生命線

4）當(dāng)前日志序列號(hào)

5）RMAN備份信息

作用：

1）記錄數(shù)據(jù)庫基本信息

2）記錄內(nèi)存下一些信息

特點(diǎn)：

1）大小一般不變（固定部分、可變部分）

2）個(gè)數(shù)，一個(gè)即可，分類存放

3.3 Redo log files

內(nèi)容：

按時(shí)間順序記錄著DB中的改變（redo entry條目），數(shù)據(jù)塊改變就會(huì)生成redo

作用：

提供數(shù)據(jù)的可恢復(fù)性

特點(diǎn)：

1）大小不變

2）順序?qū)?/p>

3）容量有限，循環(huán)覆寫

4）至少兩組日志，日志成員冗余

5）提供恢復(fù)的手段

3.4 Parameter file

內(nèi)容：

1）記錄那些定制的DB參數(shù)

2）參數(shù)默認(rèn)值

3）pfile：需要重啟實(shí)例和spfile

作用：

定義數(shù)據(jù)庫實(shí)例的屬性

特點(diǎn)：

兩種類型參數(shù)的特點(diǎn)

3.5 Password file

內(nèi)容：

特權(quán)身份用戶的口令

作用:

用于特權(quán)身份用戶登錄的驗(yàn)證

特點(diǎn)：

1）操作系統(tǒng)、密碼認(rèn)證方式登錄數(shù)據(jù)庫

2）特高、特權(quán)身份登錄到數(shù)據(jù)庫實(shí)例啟動(dòng)數(shù)據(jù)庫，跳過了數(shù)據(jù)字典的驗(yàn)證

3）O7：Oracle 7版本，啟用普通身份登錄

3.6 Archived logfiles

內(nèi)容：

重做日志（redo log）歷史

作用：

1）長期保存日志以便恢復(fù)

2）保證redo log 不丟失

特點(diǎn)：

1）個(gè)數(shù)=當(dāng)前日志數(shù)-1

2）大小<=在線日志文件大小

3）命名需要具有唯一性：序列號(hào)、RAC節(jié)點(diǎn)號(hào)

4）離線文件可通過操作系統(tǒng)命令管理

4. Instance

實(shí)例由存儲(chǔ)結(jié)構(gòu)和進(jìn)程組成，并且只短暫存在于RAM和CPU中。

4.1 SGA

內(nèi)存結(jié)構(gòu)包括兩個(gè)部分

1）系統(tǒng)全局（SGA）：在實(shí)例啟動(dòng)時(shí)候分配，是Oracle實(shí)例的基礎(chǔ)組件。

2）程序全局（PGA)：當(dāng)服務(wù)器進(jìn)程生成分配。

4.1.1 Shared Pool

用于存儲(chǔ)：

1）最近執(zhí)行的SQL語句

2）最近使用的數(shù)據(jù)定義

由兩個(gè)與性能相關(guān)的部分組成：

1）庫緩存

2）數(shù)據(jù)字典緩存

由參數(shù)SHARED_POOL_SIZE決定大小

4.1.1.1 Library Cache

1.1）存儲(chǔ)最近使用的SQL和PL/SQL語句的信息（軟解析，緩存一次多次使用） 

1.2）共享常用的語句

1.3）管理上遵循LRU規(guī)則

1.4）包括兩個(gè)部分

1.4.1）共享SQL區(qū)

1.4.2）共享PL/SQL區(qū)

1.5）大小由Shared Pool的大小決定

4.1.1.2 Data Dictionary Cache

2.1）存儲(chǔ)在數(shù)據(jù)庫中最近使用的定義

2.2）包括數(shù)據(jù)文件、表、索引、列、用戶、權(quán)限和其他的數(shù)據(jù)庫對(duì)象

2.3）在分析階段，服務(wù)器進(jìn)程查找數(shù)據(jù)字典去驗(yàn)證對(duì)象的名字以及是否是合法訪問

2.4）對(duì)于查詢和DML語句，如果數(shù)據(jù)字典的信息在緩存中能夠提高響應(yīng)時(shí)間

2.5）大小由Shared Pool 的大小決定

4.1.2 Database Buffer Cache

1）存儲(chǔ)從數(shù)據(jù)文件中獲得的數(shù)據(jù)塊的鏡像

2）當(dāng)獲取和更新數(shù)據(jù)的時(shí)候能夠大幅度的提高性能

3）管理上遵循LRU規(guī)則

4）參數(shù)DB_BLOCK_SIZE其塊的大小

5）包括以下獨(dú)立的子緩存：

DB_CACHE_SIZE

DB_KEEP_CACHE_SIZE

DB_RECYCLE_CACHE_SIZE

6）能夠動(dòng)態(tài)的調(diào)整大小

4.1.3 Redo Log Buffer

1）記錄所有數(shù)據(jù)庫的塊改變

2）主要的目的是用于恢復(fù)

3）大小由參數(shù)LOG_BUFFER（不可動(dòng)態(tài)調(diào)整）決定

4.1.4 Large Pool

1）是系統(tǒng)全局區(qū)中可選的一個(gè)部分

2）用于：

2.1）RMAN備份恢復(fù)操作

2.2）I/0并行進(jìn)程

2.3）共享服務(wù)器的會(huì)話內(nèi)存（UGA），以減輕在共享池中的負(fù)擔(dān)

3）大小由參數(shù)LARGE_POOL_SIZE決定

4）能夠被動(dòng)態(tài)的改變大小

4.1.5 Java Pool

1）Java命令的分析

2）如果要安裝和使用Java

3）大小由參數(shù)JAVA_POOL_SIZE決定，如果granule是4M，默認(rèn)是24M,granule是16M，默認(rèn)大小是32M

4.1.6 Streams Pool

流相關(guān)的數(shù)據(jù)在流池中，提高緩存效果。目前oracle較為弱化，提高采用Oracle Golden Gate（OGG），高級(jí)復(fù)制功能。

4.2 Process structure

Oracle有以下幾種進(jìn)程：

1）用戶進(jìn)程：在用戶連接數(shù)據(jù)時(shí)產(chǎn)生

2）服務(wù)器進(jìn)程：當(dāng)連接到Oracle實(shí)例并且用戶建立會(huì)話的時(shí)候產(chǎn)生

3）后臺(tái)進(jìn)程：Oracle實(shí)例啟動(dòng)的時(shí)候產(chǎn)生

4）維持物理和內(nèi)存之間的聯(lián)系

4.1）必須要有的后臺(tái)進(jìn)程：DBWn、PMON、CKPT、LGWR、SMON

4.2）可選的后臺(tái)進(jìn)程：ARCn、CJQn、Jnnn、RECO、MMAN、MMON、Snnn、Dnnn、Pnnn

4.2.1 PMON

PMON（進(jìn)程監(jiān)測(cè)進(jìn)程）：

1）清除失敗的進(jìn)程

1.1）回滾事務(wù)

1.2）釋放鎖

1.3）釋放其他資源

1.4）重啟死掉的dispatchers

1.5）動(dòng)態(tài)注冊(cè)監(jiān)聽器

4.2.2 SMON

SMON（系統(tǒng)檢測(cè)進(jìn)程）作用:

1）實(shí)例恢復(fù)：

1.1）前滾所有重做日志中的改變

1.2）打開數(shù)據(jù)庫為了用戶能訪問

1.3）回滾沒有提交的事務(wù)

2）釋放臨時(shí)表空間（deallocated）

4.2.3 DBWR

DBWn（數(shù)據(jù)庫寫進(jìn)程）寫的條件：

1）發(fā)生檢查點(diǎn)

2）臟緩存到達(dá)限制（1/4滿）

3）沒有自由的緩存

4）超時(shí)發(fā)生

5）RACping請(qǐng)求（8i）

6）表空間離線

7）表空間只讀

8）熱備份表空間開始動(dòng)作

9）表被刪除或者截?cái)?/p>

4.2.4 LGWR

LGWR（日志寫進(jìn)程）的條件：

1）commit的時(shí)候

2）達(dá)到三分之一滿

3）日志的大小到1M

4）每隔三秒

5）在DBWn進(jìn)程寫之前

4.2.5 CKPT

CKPT（檢查點(diǎn)進(jìn)程）作用：

1）給DBWn信號(hào)

2）更新數(shù)據(jù)文件頭

3）更新控制文件

4.2.6 ARCn

ARCn（歸檔進(jìn)程）：

1）可選的后臺(tái)進(jìn)程

2）當(dāng)啟用歸檔方式后自動(dòng)歸檔重做日志文件

PostgreSQL 體系架構(gòu)

PostgreSQL是自由的對(duì)象-關(guān)系數(shù)據(jù)庫服務(wù)器，在靈活的BSD-風(fēng)格許可證下發(fā)行的。PostgreSQL數(shù)據(jù)庫是一種幾乎可以運(yùn)行在各種平臺(tái)上的免費(fèi)的開放源碼的對(duì)象關(guān)系數(shù)據(jù)庫，它是一種以關(guān)系數(shù)據(jù)庫和SQL為基礎(chǔ)，擴(kuò)展了抽象數(shù)據(jù)類型，從而具備面向?qū)ο筇匦缘臄?shù)據(jù)庫。PostgreSQL數(shù)據(jù)庫由連接管理系統(tǒng)（系統(tǒng)控制器）、編譯執(zhí)行系統(tǒng)、存儲(chǔ)管理系統(tǒng)、事務(wù)系統(tǒng)、系統(tǒng)表五大部分組成，其組成結(jié)構(gòu)和關(guān)系如圖2-3所示。

 

圖  PostgreSQL體系結(jié)構(gòu) 

連接管理系統(tǒng)接受外部操作對(duì)系統(tǒng)的請(qǐng)求，對(duì)操作請(qǐng)求進(jìn)行預(yù)處理和分發(fā)，起系統(tǒng)邏輯控制作用；編譯執(zhí)行系統(tǒng)由查詢編譯器、查詢執(zhí)行器組成，完成操作請(qǐng)求在數(shù)據(jù)庫中的分析處理和轉(zhuǎn)化工作，最終實(shí)現(xiàn)物理存儲(chǔ)介質(zhì)中數(shù)據(jù)的操作；存儲(chǔ)管理系統(tǒng)由索引管理器、內(nèi)存管理器、外存管理器組成，負(fù)責(zé)存儲(chǔ)和管理物理數(shù)據(jù)，提供對(duì)編譯查詢系統(tǒng)的支持；事務(wù)系統(tǒng)由事務(wù)管理器、日志管理器、并發(fā)控制、鎖管理器組成，日志管理器和事務(wù)管理器完成對(duì)操作請(qǐng)求處理的事務(wù)一致性支持，鎖管理器和并發(fā)控制提供對(duì)并發(fā)訪問數(shù)據(jù)的一致性支持；系統(tǒng)表是PostgreSQL數(shù)據(jù)庫的元信息管理中心，包括數(shù)據(jù)庫對(duì)象信息和數(shù)據(jù)庫管理控制信息。系統(tǒng)表管理元數(shù)據(jù)信息，將PostgreSQL數(shù)據(jù)庫的各個(gè)模塊有機(jī)地連接在一起，形成一個(gè)高效的數(shù)據(jù)管理系統(tǒng)[1]。