建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
MySQL 體系架構(gòu)
一.邏輯模塊組成
創(chuàng)新互聯(lián)專(zhuān)注于嘉峪關(guān)網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供嘉峪關(guān)營(yíng)銷(xiāo)型網(wǎng)站建設(shè)，嘉峪關(guān)網(wǎng)站制作、嘉峪關(guān)網(wǎng)頁(yè)設(shè)計(jì)、嘉峪關(guān)網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造嘉峪關(guān)網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供嘉峪關(guān)網(wǎng)站排名全網(wǎng)營(yíng)銷(xiāo)落地服務(wù)。
總的來(lái)說(shuō)，MySQL 可以看成是二層架構(gòu)，***層我們通常叫做SQL Layer，在MySQL 數(shù)據(jù)庫(kù)系統(tǒng)處理底層數(shù)據(jù)之前的所有工作都是在這一層完成的，包括權(quán)限判斷，sql 解析，執(zhí)行計(jì)劃優(yōu)化，querycache 的處理等等； 第二層就是存儲(chǔ)引擎層，我們通常叫做Storage Engine Layer，也就是底層數(shù)據(jù)存取操作實(shí)現(xiàn)部分，由多種存儲(chǔ)引擎共同組成。所以，可以用如下一張最簡(jiǎn)單的架構(gòu)示意圖來(lái)表示MySQL 的基本架構(gòu)，如圖2-1 所示：
雖然從上圖看起來(lái)MySQL 架構(gòu)非常的簡(jiǎn)單，就是簡(jiǎn)單的兩部分而已，但實(shí)際上每一層中都含有各自的很多小模塊，尤其是***層SQL Layer，結(jié)構(gòu)相當(dāng)復(fù)雜的。下面我們就分別針對(duì)SQL Layer 和Storage Engine Layer 做一個(gè)簡(jiǎn)單的分析。
SQL Layer 中包含了多個(gè)子模塊，下面我將逐個(gè)做一下簡(jiǎn)單的介紹：
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)了客戶(hù)端與MySQL 交互過(guò)程中的所有協(xié)議。當(dāng)然這些協(xié)議都是建立在現(xiàn)有的OS 和網(wǎng)絡(luò)協(xié)議之上的，如TCP/IP 以及Unix Socket。
5、用戶(hù)模塊
用戶(hù)模塊所實(shí)現(xiàn)的功能，主要包括用戶(hù)的登錄連接權(quán)限控制和用戶(hù)的授權(quán)管理。他就像MySQL 的大門(mén)守衛(wèi)一樣，決定是否給來(lái)訪(fǎng)者“開(kāi)門(mén)”。
6、訪(fǎng)問(wèn)控制模塊
造訪(fǎng)客人進(jìn)門(mén)了就可以想干嘛就干嘛么？為了安全考慮，肯定不能如此隨意。這時(shí)候就需要訪(fǎng)問(wèn)控制模塊實(shí)時(shí)監(jiān)控客人的每一個(gè)動(dòng)作，給不同的客人以不同的權(quán)限。訪(fǎng)問(wèn)控制模塊實(shí)現(xiàn)的功能就是根據(jù)用戶(hù)模塊中各用戶(hù)的授權(quán)信息，以及數(shù)據(jù)庫(kù)自身特有的各種約束，來(lái)控制用戶(hù)對(duì)數(shù)據(jù)的訪(fǎng)問(wèn)。用戶(hù)模塊和訪(fǎng)問(wèn)控制模塊兩者結(jié)合起來(lái)，組成了MySQL 整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的權(quán)限安全管理的功能。
7、連接管理、連接線(xiàn)程和線(xiàn)程管理
連接管理模塊負(fù)責(zé)監(jiān)聽(tīng)對(duì)MySQL Server 的各種請(qǐng)求，接收連接請(qǐng)求，轉(zhuǎn)發(fā)所有連接請(qǐng)求到線(xiàn)程管理模塊。每一個(gè)連接上MySQL Server 的客戶(hù)端請(qǐng)求都會(huì)被分配（或創(chuàng)建）一個(gè)連接線(xiàn)程為其單獨(dú)服務(wù)。而連接線(xiàn)程的主要工作就是負(fù)責(zé)MySQL Server 與客戶(hù)端的通信，接受客戶(hù)端的命令請(qǐng)求，傳遞Server 端的結(jié)果信息等。線(xiàn)程管理模塊則負(fù)責(zé)管理維護(hù)這些連接線(xiàn)程。包括線(xiàn)程的創(chuàng)建，線(xiàn)程的cache 等。
8、Query 解析和轉(zhuǎn)發(fā)模塊
在MySQL 中我們習(xí)慣將所有Client端發(fā)送給Server 端的命令都稱(chēng)為query，在MySQL Server 里面，連接線(xiàn)程接收到客戶(hù)端的一個(gè)Query 后，會(huì)直接將該query 傳遞給專(zhuān)門(mén)負(fù)責(zé)將各種Query 進(jìn)行分類(lèi)然后轉(zhuǎn)發(fā)給各個(gè)對(duì)應(yīng)的處理模塊，這個(gè)模塊就是query 解析和轉(zhuǎn)發(fā)模塊。其主要工作就是將query 語(yǔ)句進(jìn)行語(yǔ)義和語(yǔ)法的分析，然后按照不同的操作類(lèi)型進(jìn)行分類(lèi)，然后做出針對(duì)性的轉(zhuǎn)發(fā)。
9、QueryCache 模塊
Query Cache 模塊在MySQL 中是一個(gè)非常重要的模塊，他的主要功能是將客戶(hù)端提交給MySQL 的Select 類(lèi)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 失效。在讀寫(xiě)比例非常高的應(yīng)用系統(tǒng)中，Query Cache 對(duì)性能的提高是非常顯著的。當(dāng)然它對(duì)內(nèi)存的消耗也是非常大的。
10、Query 優(yōu)化器模塊
Query 優(yōu)化器，顧名思義，就是優(yōu)化客戶(hù)端請(qǐng)求的query，根據(jù)客戶(hù)端請(qǐng)求的query 語(yǔ)句，和數(shù)據(jù)庫(kù)中的一些統(tǒng)計(jì)信息，在一系列算法的基礎(chǔ)上進(jìn)行分析，得出一個(gè)***的策略，告訴后面的程序如何取得這個(gè)query 語(yǔ)句的結(jié)果。
11、表變更管理模塊
表變更管理模塊主要是負(fù)責(zé)完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語(yǔ)句的處理。
12、表維護(hù)模塊
表的狀態(tài)檢查，錯(cuò)誤修復(fù)，以及優(yōu)化和分析等工作都是表維護(hù)模塊需要做的事情。
13、系統(tǒng)狀態(tài)管理模塊
系統(tǒng)狀態(tài)管理模塊負(fù)責(zé)在客戶(hù)端請(qǐng)求系統(tǒng)狀態(tài)的時(shí)候，將各種狀態(tài)數(shù)據(jù)返回給用戶(hù)，像DBA 常用的各種showstatus 命令，showvariables 命令等，所得到的結(jié)果都是由這個(gè)模塊返回的。
14、表管理器
這個(gè)模塊從名字上看來(lái)很容易和上面的表變更和表維護(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 線(xiàn)程交互等工作。
Slave 模塊比Master 模塊所要做的事情稍多一些，在系統(tǒng)中主要體現(xiàn)在兩個(gè)線(xiàn)程上面。一個(gè)是負(fù)責(zé)從Master請(qǐng)求和接受binary 日志，并寫(xiě)入本地relay log 中的I/O 線(xiàn)程。另外一個(gè)是負(fù)責(zé)從relay log 中讀取相關(guān)日志事件，然后解析成可以在Slave 端正確執(zhí)行并得到和Master端完全相同的結(jié)果的命令并再交給Slave 執(zhí)行的SQL 線(xiàn)程。
17、存儲(chǔ)引擎接口模塊
存儲(chǔ)引擎接口模塊可以說(shuō)是MySQL 數(shù)據(jù)庫(kù)中最有特色的一點(diǎn)了。目前各種數(shù)據(jù)庫(kù)產(chǎn)品中，基本上只有MySQL 可以實(shí)現(xiàn)其底層數(shù)據(jù)存儲(chǔ)引擎的插件式管理。這個(gè)模塊實(shí)際上只是一個(gè)抽象類(lèi)，但正是因?yàn)樗晒Φ貙⒏鞣N數(shù)據(jù)處理高度抽象化，才成就了今天MySQL 可插拔存儲(chǔ)引擎的特色。
二.各模塊工作配合
在了解了MySQL 的各個(gè)模塊之后，我們?cè)倏纯碝ySQL各個(gè)模塊間是如何相互協(xié)同工作的。
接下來(lái)，我們通過(guò)啟動(dòng)MySQL，客戶(hù)端連接，請(qǐng)求query，得到返回結(jié)果，***退出，這樣一整個(gè)過(guò)程來(lái)進(jìn)行分析。
當(dāng)我們執(zhí)行啟動(dòng)MySQL 命令之后，MySQL 的初始化模塊就從系統(tǒng)配置文件中讀取系統(tǒng)參數(shù)和命令行參數(shù)，并按照參數(shù)來(lái)初始化整個(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)處理客戶(hù)端連接請(qǐng)求的監(jiān)聽(tīng)程序，包括tcp/ip 的網(wǎng)絡(luò)監(jiān)聽(tīng)，還有unix 的socket。這時(shí)候，MySQL Server 就基本啟動(dòng)完成，準(zhǔn)備好接受客戶(hù)端請(qǐng)求了。
當(dāng)連接管理模塊監(jiān)聽(tīng)到客戶(hù)端的連接請(qǐng)求（借助網(wǎng)絡(luò)交互模塊的相關(guān)功能），雙方通過(guò)Client & Server 交互協(xié)議模塊所定義的協(xié)議“寒暄”幾句之后，連接管理模塊就會(huì)將連接請(qǐng)求轉(zhuǎn)發(fā)給線(xiàn)程管理模塊，去請(qǐng)求一個(gè)連接線(xiàn)程。
線(xiàn)程管理模塊馬上又會(huì)將控制交給連接線(xiàn)程模塊，告訴連接線(xiàn)程模塊：現(xiàn)在我這邊有連接請(qǐng)求過(guò)來(lái)了，需要建立連接，你趕快處理一下。連接線(xiàn)程模塊在接到連接請(qǐng)求后，首先會(huì)檢查當(dāng)前連接線(xiàn)程池中是否有被cache 的空閑連接線(xiàn)程，如果有，就取出一個(gè)和客戶(hù)端請(qǐng)求連接上，如果沒(méi)有空閑的連接線(xiàn)程，則建立一個(gè)新的連接線(xiàn)程與客戶(hù)端請(qǐng)求連接。當(dāng)然，連接線(xiàn)程模塊并不是在收到連接請(qǐng)求后馬上就會(huì)取出一個(gè)連接線(xiàn)程連和客戶(hù)端連接，而是首先通過(guò)調(diào)用用戶(hù)模塊進(jìn)行授權(quán)檢查，只有客戶(hù)端請(qǐng)求通過(guò)了授權(quán)檢查后，他才會(huì)將客戶(hù)端請(qǐng)求和負(fù)責(zé)請(qǐng)求的連接線(xiàn)程連上。
在MySQL 中，將客戶(hù)端請(qǐng)求分為了兩種類(lèi)型：一種是query，需要調(diào)用Parser 也就是Query 解析和轉(zhuǎn)發(fā)模塊的解析才能夠執(zhí)行的請(qǐng)求；一種是command，不需要調(diào)用Parser 就可以直接執(zhí)行的請(qǐng)求。如果我們的初始化配置中打開(kāi)了Full QueryLogging 的功能，那么Query 解析與轉(zhuǎn)發(fā)模塊會(huì)調(diào)用日志記錄模塊將請(qǐng)求計(jì)入日志，不管是一個(gè)Query 類(lèi)型的請(qǐng)求還是一個(gè)command 類(lèi)型的請(qǐng)求，都會(huì)被記錄進(jìn)入日志，所以出于性能考慮，一般很少打開(kāi)Full QueryLogging 的功能。
當(dāng)客戶(hù)端請(qǐng)求和連接線(xiàn)程“互換暗號(hào)（互通協(xié)議）”接上頭之后，連接線(xiàn)程就開(kāi)始處理客戶(hù)端請(qǐng)求發(fā)送過(guò)來(lái)的各種命令（或者query），接受相關(guān)請(qǐng)求。它將收到的query語(yǔ)句轉(zhuǎn)給Query 解析和轉(zhuǎn)發(fā)模塊，Query 解析器先對(duì)Query 進(jìn)行基本的語(yǔ)義和語(yǔ)法解析，然后根據(jù)命令類(lèi)型的不同，有些會(huì)直接處理，有些會(huì)分發(fā)給其他模塊來(lái)處理。
如果是一個(gè)Query 類(lèi)型的請(qǐng)求，會(huì)將控制權(quán)交給Query解析器。Query 解析器首先分析看是不是一個(gè)select 類(lèi)型的query，如果是，則調(diào)用查詢(xún)緩存模塊，讓它檢查該query 在query cache 中是否已經(jīng)存在。如果有，則直接將cache 中的數(shù)據(jù)返回給連接線(xiàn)程模塊，然后通過(guò)與客戶(hù)端的連接的線(xiàn)程將數(shù)據(jù)傳輸給客戶(hù)端。如果不是一個(gè)可以被cache 的query類(lèi)型，或者cache 中沒(méi)有該query 的數(shù)據(jù)，那么query 將被繼續(xù)傳回query 解析器，讓query解析器進(jìn)行相應(yīng)處理，再通過(guò)query 分發(fā)器分發(fā)給相關(guān)處理模塊。
如果解析器解析結(jié)果是一條未被cache 的select 語(yǔ)句，則將控制權(quán)交給Optimizer，也就是Query 優(yōu)化器模塊，如果是DML 或者是DDL 語(yǔ)句，則會(huì)交給表變更管理模塊，如果是一些更新統(tǒng)計(jì)信息、檢測(cè)、修復(fù)和整理類(lèi)的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 處理器這些小模塊來(lái)負(fù)責(zé)不同的DML和DDL 的。
在各個(gè)模塊收到Query 解析與分發(fā)模塊分發(fā)過(guò)來(lái)的請(qǐng)求后，首先會(huì)通過(guò)訪(fǎng)問(wèn)控制模塊檢查連接用戶(hù)是否有訪(fǎng)問(wèn)目標(biāo)表以及目標(biāo)字段的權(quán)限，如果有，就會(huì)調(diào)用表管理模塊請(qǐng)求相應(yīng)的表，并獲取對(duì)應(yīng)的鎖。表管理模塊首先會(huì)查看該表是否已經(jīng)存在于table cache 中，如果已經(jīng)打開(kāi)則直接進(jìn)行鎖相關(guān)的處理，如果沒(méi)有在cache 中，則需要再打開(kāi)表文件獲取鎖，然后將打開(kāi)的表交給表變更管理模塊。
當(dāng)表變更管理模塊“獲取”打開(kāi)的表之后，就會(huì)根據(jù)該表的相關(guān)meta 信息，判斷表的存儲(chǔ)引擎類(lèi)型和其他相關(guān)信息。根據(jù)表的存儲(chǔ)引擎類(lèi)型，提交請(qǐng)求給存儲(chǔ)引擎接口模塊，調(diào)用對(duì)應(yīng)的存儲(chǔ)引擎實(shí)現(xiàn)模塊，進(jìn)行相應(yīng)處理。
不過(guò)，對(duì)于表變更管理模塊來(lái)說(shuō)，可見(jiàn)的僅是存儲(chǔ)引擎接口模塊所提供的一系列“標(biāo)準(zhǔn)”接口，底層存儲(chǔ)引擎實(shí)現(xiàn)模塊的具體實(shí)現(xiàn)，對(duì)于表變更管理模塊來(lái)說(shuō)是透明的。他只需要調(diào)用對(duì)應(yīng)的接口，并指明表類(lèi)型，接口模塊會(huì)根據(jù)表類(lèi)型調(diào)用正確的存儲(chǔ)引擎來(lái)進(jìn)行相應(yīng)的處理。
當(dāng)一條query 或者一個(gè)command 處理完成（成功或者失?。┲?，控制權(quán)都會(huì)交還給連接線(xiàn)程模塊。如果處理成功，則將處理結(jié)果（可能是一個(gè)Result set，也可能是成功或者失敗的標(biāo)識(shí)）通過(guò)連接線(xiàn)程反饋給客戶(hù)端。如果處理過(guò)程中發(fā)生錯(cuò)誤，也會(huì)將相應(yīng)的錯(cuò)誤信息發(fā)送給客戶(hù)端，然后連接線(xiàn)程模塊會(huì)進(jìn)行相應(yīng)的清理工作，并繼續(xù)等待后面的請(qǐng)求，重復(fù)上面提到的過(guò)程，或者完成客戶(hù)端斷開(kāi)連接的請(qǐng)求。
如果在上面的過(guò)程中，相關(guān)模塊使數(shù)據(jù)庫(kù)中的數(shù)據(jù)發(fā)生了變化，而且MySQL 打開(kāi)了binlog 功能，則對(duì)應(yīng)的處理模塊還會(huì)調(diào)用日志處理模塊將相應(yīng)的變更語(yǔ)句以更新事件的形式記錄到相關(guān)參數(shù)指定的二進(jìn)制日志文件中。
在上面各個(gè)模塊的處理過(guò)程中，各自的核心運(yùn)算處理功能部分都會(huì)高度依賴(lài)整個(gè)MySQL的核心API 模塊，比如內(nèi)存管理，文件I/O，數(shù)字和字符串處理等等。
了解到整個(gè)處理過(guò)程之后，我們可以將以上各個(gè)模塊畫(huà)成如圖2-2 的關(guān)系圖：
下面這個(gè)是官方文檔里的一個(gè)圖：
Oracle體系結(jié)構(gòu)介紹 --基礎(chǔ)篇
在學(xué)習(xí)oracle中，體系結(jié)構(gòu)是重中之重，掌握的越深入越好。在實(shí)際工作遇到疑難問(wèn)題，其實(shí)都可以歸結(jié)到體系結(jié)構(gòu)中來(lái)解釋?zhuān)晕覀兏鶕?jù)下面的示圖了解一下oracle體系結(jié)構(gòu)。
1. Summarize
根據(jù)示圖，便于我們記憶，示圖分三部分組成，左側(cè)User Process、Server Process、PGA可以看做成Clinet端，上面的實(shí)例（Instance）和下面的數(shù)據(jù)庫(kù)（Database）及參數(shù)文件（parameter file）、密碼文件（password file）和歸檔日志文件（archived logfiles）組成Oracle Server，所以整個(gè)示圖可以理解成一個(gè)C/S架構(gòu)。
Oracle Server 由兩個(gè)實(shí)體組成：實(shí)例（instance）與數(shù)據(jù)庫(kù)（database）。這兩個(gè)實(shí)體是獨(dú)立的，不過(guò)連接在一起。在數(shù)據(jù)庫(kù)創(chuàng)建過(guò)程中，實(shí)例首先被創(chuàng)建，然后才創(chuàng)建數(shù)據(jù)庫(kù)。在典型的單實(shí)例環(huán)境中，實(shí)例與數(shù)據(jù)庫(kù)的關(guān)系是一對(duì)一的，一個(gè)實(shí)例連接一個(gè)數(shù)據(jù)庫(kù)，實(shí)例與數(shù)據(jù)庫(kù)也可以是多對(duì)一的關(guān)系，即不同計(jì)算機(jī)上的多個(gè)實(shí)例打開(kāi)共享磁盤(pán)系統(tǒng)上的一個(gè)公用數(shù)據(jù)庫(kù)。這種多對(duì)一關(guān)系被稱(chēng)為實(shí)際應(yīng)用群集（Real Application Clusters，RAC）RAC極大提高了數(shù)據(jù)庫(kù)的性能、容錯(cuò)與可伸縮性（可能耗費(fèi)更多的存儲(chǔ)空間）并且是oracle網(wǎng)格（grid）概念的必備部分。
2. Client端
在Client端的作用是如何從客戶(hù)端創(chuàng)建服務(wù)器進(jìn)程與數(shù)據(jù)庫(kù)進(jìn)行交互的過(guò)程。
2.1 User process
用戶(hù)運(yùn)行一個(gè)應(yīng)用程序時(shí)與Oracle數(shù)據(jù)庫(kù)進(jìn)程交互（例如：sql/plus）時(shí)，oracle創(chuàng)建一個(gè)用戶(hù)進(jìn)程來(lái)運(yùn)行用戶(hù)的應(yīng)用程序。
2.2 Server process
Server Process是用來(lái)處理連接到實(shí)例的用戶(hù)進(jìn)程（User Process）提交的請(qǐng)求。當(dāng)應(yīng)用程序與Oracle服務(wù)器運(yùn)行在同一臺(tái)機(jī)器上時(shí)，某些用戶(hù)進(jìn)程（User Process）可以與Server Process合并為同一個(gè)進(jìn)程，即便減小系統(tǒng)開(kāi)銷(xiāo)。從邏輯層面來(lái)講，用戶(hù)進(jìn)程必須要通過(guò)一個(gè)Server Process來(lái)同Oracle進(jìn)行通信的.（只不過(guò)有些時(shí)候在同一臺(tái)機(jī)器的時(shí)候，某些User Process和Server Process會(huì)合并罷了）
2.3 PGA
PGA（Program Global Area）程序全局區(qū)，是用戶(hù)進(jìn)程連接到數(shù)據(jù)庫(kù)并創(chuàng)建一個(gè)會(huì)話(huà)時(shí)，由Oracle服務(wù)器進(jìn)程分配的專(zhuān)門(mén)用于當(dāng)前用戶(hù)會(huì)話(huà)的內(nèi)存區(qū)，該區(qū)域是私有的。
為每個(gè)用戶(hù)連接Oracle數(shù)據(jù)庫(kù)保留的內(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）用戶(hù)數(shù)據(jù)：用戶(hù)表、DML語(yǔ)句可調(diào)整；
2）數(shù)據(jù)字典數(shù)據(jù)：數(shù)據(jù)字典表記錄DB結(jié)構(gòu)、只讀不可修改、DDL語(yǔ)句調(diào)整
3）真實(shí)看到的文件
作用：
讀取數(shù)據(jù)
特點(diǎn)：
1）至少包含一個(gè)SYSTEM表空間、DDL語(yǔ)言
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ù)寫(xiě)出磁盤(pán)
3.2）SCN:（system change number），時(shí)間軸、生命線(xiàn)
4）當(dāng)前日志序列號(hào)
5）RMAN備份信息
作用：
1）記錄數(shù)據(jù)庫(kù)基本信息
2）記錄內(nèi)存下一些信息
特點(diǎn)：
1）大小一般不變（固定部分、可變部分）
2）個(gè)數(shù)，一個(gè)即可，分類(lèi)存放
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)覆寫(xiě)
4）至少兩組日志，日志成員冗余
5）提供恢復(fù)的手段
3.4 Parameter file
內(nèi)容：
1）記錄那些定制的DB參數(shù)
2）參數(shù)默認(rèn)值
3）pfile：需要重啟實(shí)例和spfile
作用：
定義數(shù)據(jù)庫(kù)實(shí)例的屬性
特點(diǎn)：
兩種類(lèi)型參數(shù)的特點(diǎn)
3.5 Password file
內(nèi)容：
特權(quán)身份用戶(hù)的口令
作用:
用于特權(quán)身份用戶(hù)登錄的驗(yàn)證
特點(diǎn)：
1）操作系統(tǒng)、密碼認(rèn)證方式登錄數(shù)據(jù)庫(kù)
2）特高、特權(quán)身份登錄到數(shù)據(jù)庫(kù)實(shí)例啟動(dòng)數(shù)據(jù)庫(kù)，跳過(guò)了數(shù)據(jù)字典的驗(yàn)證
3）O7：Oracle 7版本，啟用普通身份登錄
3.6 Archived logfiles
內(nèi)容：
重做日志（redo log）歷史
作用：
1）長(zhǎng)期保存日志以便恢復(fù)
2）保證redo log 不丟失
特點(diǎn)：
1）個(gè)數(shù)=當(dāng)前日志數(shù)-1
2）大小<=在線(xiàn)日志文件大小
3）命名需要具有唯一性：序列號(hào)、RAC節(jié)點(diǎn)號(hào)
4）離線(xiàn)文件可通過(guò)操作系統(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語(yǔ)句
2）最近使用的數(shù)據(jù)定義
由兩個(gè)與性能相關(guān)的部分組成：
1）庫(kù)緩存
2）數(shù)據(jù)字典緩存
由參數(shù)SHARED_POOL_SIZE決定大小
4.1.1.1 Library Cache
1.1）存儲(chǔ)最近使用的SQL和PL/SQL語(yǔ)句的信息（軟解析，緩存一次多次使用）
1.2）共享常用的語(yǔ)句
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ù)庫(kù)中最近使用的定義
2.2）包括數(shù)據(jù)文件、表、索引、列、用戶(hù)、權(quán)限和其他的數(shù)據(jù)庫(kù)對(duì)象
2.3）在分析階段，服務(wù)器進(jìn)程查找數(shù)據(jù)字典去驗(yàn)證對(duì)象的名字以及是否是合法訪(fǎng)問(wèn)
2.4）對(duì)于查詢(xún)和DML語(yǔ)句，如果數(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ù)庫(kù)的塊改變
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ì)話(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）用戶(hù)進(jìn)程：在用戶(hù)連接數(shù)據(jù)時(shí)產(chǎn)生
2）服務(wù)器進(jìn)程：當(dāng)連接到Oracle實(shí)例并且用戶(hù)建立會(huì)話(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)聽(tīng)器
4.2.2 SMON
SMON（系統(tǒng)檢測(cè)進(jìn)程）作用:
1）實(shí)例恢復(fù)：
1.1）前滾所有重做日志中的改變
1.2）打開(kāi)數(shù)據(jù)庫(kù)為了用戶(hù)能訪(fǎng)問(wèn)
1.3）回滾沒(méi)有提交的事務(wù)
2）釋放臨時(shí)表空間（deallocated）
4.2.3 DBWR
DBWn（數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程）寫(xiě)的條件：
1）發(fā)生檢查點(diǎn)
2）臟緩存到達(dá)限制（1/4滿(mǎn)）
3）沒(méi)有自由的緩存
4）超時(shí)發(fā)生
5）RACping請(qǐng)求（8i）
6）表空間離線(xiàn)
7）表空間只讀
8）熱備份表空間開(kāi)始動(dòng)作
9）表被刪除或者截?cái)?/p>
4.2.4 LGWR
LGWR（日志寫(xiě)進(jìn)程）的條件：
1）commit的時(shí)候
2）達(dá)到三分之一滿(mǎn)
3）日志的大小到1M
4）每隔三秒
5）在DBWn進(jìn)程寫(xiě)之前
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ù)庫(kù)服務(wù)器，在靈活的BSD-風(fēng)格許可證下發(fā)行的。PostgreSQL數(shù)據(jù)庫(kù)是一種幾乎可以運(yùn)行在各種平臺(tái)上的免費(fèi)的開(kāi)放源碼的對(duì)象關(guān)系數(shù)據(jù)庫(kù)，它是一種以關(guān)系數(shù)據(jù)庫(kù)和SQL為基礎(chǔ)，擴(kuò)展了抽象數(shù)據(jù)類(lèi)型，從而具備面向?qū)ο筇匦缘臄?shù)據(jù)庫(kù)。PostgreSQL數(shù)據(jù)庫(kù)由連接管理系統(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)由查詢(xún)編譯器、查詢(xún)執(zhí)行器組成，完成操作請(qǐng)求在數(shù)據(jù)庫(kù)中的分析處理和轉(zhuǎn)化工作，最終實(shí)現(xiàn)物理存儲(chǔ)介質(zhì)中數(shù)據(jù)的操作；存儲(chǔ)管理系統(tǒng)由索引管理器、內(nèi)存管理器、外存管理器組成，負(fù)責(zé)存儲(chǔ)和管理物理數(shù)據(jù)，提供對(duì)編譯查詢(xún)系統(tǒng)的支持；事務(wù)系統(tǒng)由事務(wù)管理器、日志管理器、并發(fā)控制、鎖管理器組成，日志管理器和事務(wù)管理器完成對(duì)操作請(qǐng)求處理的事務(wù)一致性支持，鎖管理器和并發(fā)控制提供對(duì)并發(fā)訪(fǎng)問(wèn)數(shù)據(jù)的一致性支持；系統(tǒng)表是PostgreSQL數(shù)據(jù)庫(kù)的元信息管理中心，包括數(shù)據(jù)庫(kù)對(duì)象信息和數(shù)據(jù)庫(kù)管理控制信息。系統(tǒng)表管理元數(shù)據(jù)信息，將PostgreSQL數(shù)據(jù)庫(kù)的各個(gè)模塊有機(jī)地連接在一起，形成一個(gè)高效的數(shù)據(jù)管理系統(tǒng)[1]。
網(wǎng)頁(yè)名稱(chēng)：一篇掌握MySQL，Oracle和PostgreSQL數(shù)據(jù)庫(kù)體系架構(gòu)
標(biāo)題網(wǎng)址：http://www.5511xx.com/article/dpcoijs.html
