在具體實現raid 0、raid 5或者基於軟體分條時，正確地決定最佳的分條結構 ( s t r i p )大
小非常關鍵。在決定分條大小時，有3個因素必須考慮：
* 主要應用程式（o lt p或者d s s）的內在特性。
* 作業系統與資料庫的資料塊大小。
* 分條列（磁碟陣列）中的硬碟數目。
幾乎每一本d b a手冊都會說明保證資料庫的資料塊大小是作業系統資料塊大小倍數的重
要性（筆者也贊成這種觀點，請參見第 7章）。因此，筆者在這裡將假設使用者可以很方便地讀
取資料，並且使用者作業系統的資料塊大小與資料庫的資料塊大小相容。這個規則同樣也適用
於所有分條集合中的分條大小：也就是說，分條大小必須是作業系統資料塊大小的整數倍。
如果使用的是原始裝置，那麼就可以僅僅考慮作業系統的物理資料塊大小。 u n i x系統中的物
理資料塊大小是5 1 2位元組，在使用logical volume manager(lv m )時，作業系統的邏輯資料塊
大小將覆蓋作業系統的物理資料塊大小。在 lv m中，邏輯資料塊的預設大小為 8 k b。這也許
不是乙個大問題，因為 5 1 2位元組與8 k b很容易整除通常使用的 s t r i p大小（6 4 k b、1 2 8 k b、
2 5 6 k b、5 1 2 k b等等）。因此，在這方面出問題的可能性不大。實際上，上面列出的第三個因
素才是大多數人需要進行深入考慮的。
分條可以按照水平方向（跨越每個硬碟控制器）進行，也可以按照垂直的方向（跨越硬
盤集合）進行。通常，對硬碟進行分條動作的目的是為了使用多個硬碟控制器以便達到對數
據的並行訪問，因此必須考慮系統中可用的硬碟控制器數目以及每個分條集合中的成員數目。
下面將假設系統中有四個硬碟控制器可供使用，並且每個分條集合中有四個成員（通常，不
應該使得分條集合中的成員數目多於系統中可用的硬碟控制器數目，否則將會不能很好地實
現進行硬碟分條的目標，這個目標就是將資料分散到系統中可用的多個資源上，以便實現數
據的併發訪問）。如果假設作業系統與資料庫的資料塊大小都是 8 k b，那麼系統為了實現對四
個分條集合的並行訪問，那麼每次就應該至少讀寫 3 2 k b（8 k b×4個硬碟控制器）的資料。
在這裡，需要假設這個容量的資料為當前被處理的流量，而在任何多使用者環境中，這並不是
一種很好的方法。但是，上面給出的這個簡單例子說明了在這種環境下，既使是系統需要進
行觸發並行訪問的操作企圖，也必須要求進行 3 2 k b分條大小的資料交換。這樣，對於少量信
息的訪問請求將不能達到訪問時間的優化。而在 o lt p環境下，資料訪問請求中的資料塊大小一般都比較小（只有少數大於 3 2 k b的）。在d s s應用程式中，資料訪問請求中的資料塊大小
一般都比較大，從而必須保證有較大的分條大小。關於資料庫資料塊大小與最佳分條大小
（基於每個分條集合中的硬碟數目）之間的關係
資料庫之作業系統 筆記
活躍就緒 是指程序在主存並且可被排程的狀態。靜止就緒 掛起就緒 是指程序被對換到輔存時的就緒狀態，是不能被直接排程的狀態，只有當主存中沒有活躍就緒態程序，或者是掛起就緒態程序具有更高的優先順序，系統將把掛起就緒態程序調回主存並轉換為活躍就緒。活躍阻塞 是指程序已在主存，一旦等待的事件產生便進入活躍就...
神話系列之一 C 開發的作業系統和資料庫
網上流傳很多c和c 神話 我聽了以後，決定打破這些美麗的神話。給大家開開眼界，更希望能說明乙個神話，解開我 最神秘的等待 我覺得好像不太可能 可是非有人說可以 大家給講講 行麼 睡著的時候才有可能吧。c 寫的系統怎麼操作底層硬體？很多需要的dll都是c或是c 寫好呼叫的。再說了，沒有 framewo...
作業系統過小，無法啟動資料庫
環境 linux5.3 redhat 記憶體1g oracle 12c 12.1.0.1.0 啟動資料庫時 sql startup ora 00845 memory target not supported on this system reason 從oracle11g開始，記憶體管理引數中新增m...