以下均是針對Window 32位系統環境下，64位的不在下面描述情況下。
使用者模式和核心模式(user mode& kernel mode)
為了防止使用者程式通路并篡改作業系統的關鍵部分，Windows使用了2種處理器存取模式：使用者模式和核心模式。顧名思義，核心模式是給作業系統核心代碼和基本驅動用的，使用者模式給使用者應用程式。在核心模式下程式可以通路所有的記憶體和硬體，并使用所有的處理器指令。作業系統程式比使用者程式有更高的權限，使得系統設計者可以確定使用者程式不會意外的破壞系統的穩定性。
實體記憶體(Physical Memory)
即實際購買的記憶體的大小，記憶體條上的容量。CPU的位址線可以直接進行尋址的記憶體空間大小，在32位作業系統平台上，CPU的最大尋址空間為4GB，也即可以支援最大4G的實體記憶體空間。在32位作業系統上即便你購買的是64G記憶體，也隻能說擁有4GB的實體記憶體空間
虛拟記憶體(Virtual Memory)
如果計算機缺少運作程式或操作所需的随機存儲記憶體，則Windows使用虛拟記憶體進行補償。虛拟記憶體将計算機的RAM和硬碟上的臨時空間組合在一起，當RAM不足時，虛拟記憶體将資料從RAM移動到稱為“分頁檔案”的空間中，将資料移入與移出分頁檔案可以釋放RAM，以便完成工作。
虛拟位址空間(Virtual Address Space，簡稱VAS)
在Windows系統中，任何一個程序都被賦予了其自己的虛拟位址空間，該虛拟位址空間覆寫了一個相當大的範圍，對于32位系統的虛拟位址空間範圍從0x00000000~0xffffffff(4GB)。Windows采用分頁機制，将4G的位址空間分成固定大小的頁，并且将虛拟位址中的每一頁映射到實體記憶體中。
在預設的情況下虛拟位址空間中的低2G，即0x0000000~0x7FFFFFFFF是使用者位址空間，而4G虛拟位址空間中的高2G即0x8000000~0xFFFFFFFF是配置設定給核心模式。實際上使用者程序擁有的虛拟位址空間隻有2GB。
虛拟記憶體管理器(Virtual Memory Manager)
虛拟記憶體管理器負責虛拟位址空間和實體記憶體的位址映射，如果缺乏足夠記憶體，則需要使用到page file檔案來保持臨時資料也即虛拟記憶體，同時使用page table entry(PTE)來跟蹤每一個位址映射關系。
到這裡為止，64G的記憶體有60G都無法通路，豈不是浪費了，那怎麼辦?
/3GB和increaseUserVA
通過/3GB的方式，可以減少核心模式占用位址空間，進而增加SQL Server程序的位址空間。預設情況下，使用者模式和核心模式各自占用2G尋址空間，3G選項可以使得SQL Server獲得多1G的虛拟位址空間。
/3GB開關用法：
在Boot.ini檔案中修改其中的段落即可：
或者使用bootcfg指令：
在Windows Server 2008中可以運作BCDEdit指令，加以調整。
實體位址擴充PAE(Physical Address Extension)
實體位址擴充(PAE)是32位Intel CPU的一種擴充，這樣可以在32位系統上支援最大64G的實體記憶體，即4GB以上實體記憶體允許将更多實體記憶體映射為應用程式的虛拟位址空間。
使用方式,在Boot.ini檔案中修改其中的段落即可：
在Windows Server 2008作業系統下也可以通過以下指令執行：
/PAE和/3GB
兩者的目标是不同的，又可以在同樣的地方進行配置，是以難免産生疑惑，簡單的來說就是如果計算機可用實體記憶體超過16GB，就需要確定boot.ini檔案中沒有/3gb參數即可。
位址視窗化擴充插件AWE(Address Windowing Extensions)
AWE是Windows的記憶體管理功能的一組擴充，它能夠使應用程式使用的記憶體量超過通過标準32位尋址可使用的2~3G記憶體。AWE允許應用程式擷取實體記憶體，然後将非分頁記憶體的視圖映射到32位位址空間。雖然32位位址空間限制為4GB，但是非分頁記憶體卻可以遠遠大于4GB。
在SQL Server 2008下，可以登入SQL Server Management Studio，找到相應的資料庫執行個體，點選右鍵選擇屬性，然後在“選擇頁”中點選記憶體，在伺服器記憶體選項中，複選使用AWE配置設定記憶體即可。
SQLServer的記憶體管理
SQL Server 主要的記憶體元件是緩沖池。其中高速資料緩沖區用以把資料從磁盤加載到記憶體中，實作資料的高速讀寫。而過程高速緩沖區則用來存儲相應的執行計劃，減少編譯過程，也是高速緩沖倉庫的主要構成部分。使用者倉庫高速緩沖是使用者倉庫的主要組成本部分。對象倉庫則僅僅是記憶體塊組成的記憶體池，不需要進行LRU或成本計算例如SQL Server網絡接口(SNI)利用對象存儲倉庫作為網絡緩沖池。
SQL Server 記憶體管理器由一個三層的層次結構組成。該層次結構的底層為記憶體節點。下一層由記憶體 Clerk、記憶體緩存和記憶體池組成。最後一層由記憶體對象組成。這些對象通常用于在 SQL Server 執行個體中配置設定記憶體。
記憶體節點(sys.dm_os_memory_nodes)提供低級配置設定器的界面和實作。在NUMA中記憶體節點和CPU節點可以對應起來的，在 SQL Server 中，隻有記憶體 Clerk 可通路記憶體節點。
記憶體 Clerk(sys.dm_os_memory_clerks) 通路記憶體節點界面以配置設定記憶體。記憶體節點還會跟蹤 Clerk 配置設定的記憶體以進行診斷。配置設定大量記憶體的每個元件，都必須使用 Clerk 界面來建立其自己的記憶體 Clerk 并配置設定其全部記憶體。各元件會在 SQL Server 啟動時建立其相應的 Clerk。
記憶體對象(sys.dm_os_memory_objects)是指多個堆。它們所提供的配置設定的粒度比記憶體 Clerk 所提供的配置設定的粒度更精細。SQL Server 元件使用記憶體對象，而不使用記憶體 Clerk。記憶體對象使用記憶體 Clerk 的頁配置設定器接口來配置設定頁。記憶體對象不使用虛拟記憶體接口或共享記憶體接口。根據配置設定模式的不同，元件可以建立不同的記憶體對象類型來配置設定任意大小的區域。
SQL Server的緩沖池隻提供8KB的記憶體塊;大于8KB的大記憶體塊需求是被單獨管理的，且一般是直接從作業系統或者說是從緩沖池外擷取到的，此外隻有資料高速緩沖頁面才能使用AWE記憶體，并且需要單獨跟蹤。
SQLServer的記憶體方面的系統視圖
sys.dm_os_memory_cache_clock_hands 傳回特定緩存時鐘的每個指針的狀态。提供給使用者關于每個緩存存儲區和使用者存儲區的時鐘指針資訊——指針是否正在轉動、圈數、被移除的條目數量等。此視圖對于查找目前時鐘指針的狀态以及時鐘指針的移動曆史非常有用。
sys.dm_os_memory_cache_counters 傳回緩存運作狀況的快照。提供有關已配置設定的緩存條目、緩存條目的使用情況以及記憶體源的運作時資訊。提供給使用者每個存儲區的總結資訊——使用的記憶體數量、條目數、正在使用的條目數。使用者可以使用該視圖找到緩存的記憶體使用，以及一個緩存中的條目數量。
sys.dm_os_memory_cache_hash_tables 針對 SQL Server 執行個體中的每個活動緩存傳回一行。即使用者關于緩存存儲區的散清單資訊——最大、最小、平均桶長等。此視圖對于查找緩存存儲區中每個緩存表的每個散列桶的條目分布非常有用。
sys.dm_os_memory_cache_entries 傳回有關緩存中所有條目的資訊。使用此視圖可對緩存條目進行跟蹤，直至它們的關聯對象。還可使用此視圖擷取有關緩存條目的統計資訊。
sys.dm_os_sys_info傳回一組有關計算機和有關 SQL Server 可用資源及其已占用資源的有用雜項資訊。
sys.dm_os_sys_memory 從作業系統傳回記憶體資訊。SQL Server 受作業系統級别的外部記憶體條件和基礎硬體實體限制的限制并對其有所響應。确定整個系統的狀态是評估 SQL Server 記憶體使用量的重要方面。
sys.dm_os_virtual_address_dump則傳回有關調用程序的虛拟位址空間中的頁範圍的資訊。
DBCC MemoryStatus指令提供了SQL Server的目前記憶體狀态的快照，也可以作為我們分析記憶體瓶頸的重要依據。
記憶體壓力
對于SQL Server占用記憶體資源的監控主要集中在頁面吞吐能力、頁面錯誤和可用記憶體上上，對虛拟記憶體的監控，則重點在于分頁檔案的使用率上。下面提供了幾種對象、計數器和相應的門檻值及描述。
SQL Server提供的sys.dm_os_performance_counters計數器視圖，主要對緩沖區管理器和記憶體管理器的一些計數器進行監控，比如頁面的生存周期、檢查點、惰性寫入器和緩沖命中率等名額。
以下為緩沖池内資料庫緩沖池中各個資料庫的分布情況。
以下為傳回目前資料庫中每個對象的緩存頁計數，加以适當的修改我們也可以得到資料緩沖池中對象資料頁和索引頁的分布情況。
以下為緩沖池中前十位消耗記憶體最大的記憶體元件。
我們需要重點關注的記憶體元件為以下：
sys.dm_exec_cached_plans針對 SQL Server 為了加快查詢執行而緩存的每個查詢計劃傳回一行。可以用此動态管理視圖來查找緩存的查詢計劃、緩存的查詢文本、緩存計劃占用的記憶體量，以及重新使用緩存計劃的計數。同樣我們還可以和sys.dm_exec_sql_text聯合起來進一步加工擷取到緩沖最大的前10條SQL。
CACHESTORE_SQLCP—SQL執行計劃(臨時緩存計劃、自動參數化計劃和預編譯計劃)
CACHESTORE_OBJCP—對象計劃(存儲過程、函數、觸發器等執行計劃)
CACHESTORE_PHDR—Bound Trees是在SQL Server中代數化的結構過程，被用于視圖、限制和預設值。
CACHESTORE_XPRO是預定義的系統存儲過程，這裡僅包含實作過程的函數名稱和DLL名稱。
以下SQL用來确認在緩沖區外進行配置設定了記憶體的内部元件(即通過多頁配置設定器請求記憶體)，借以了解記憶體是否存在壓力。
I/O性能診斷
SQL Server性能非常依賴于I/O子系統。除非你的資料庫适合實體記憶體，SQL Server經常地會有資料庫頁面進出緩存池。這樣就發生了實質的I/O流量。同樣，在事務被明确的送出前，日志記錄需要寫入磁盤。SQL Server為各種目的可以使用tempdb，例如存儲中間結果，排序，保持行的版本或其他。是以好的I/O子系統對于SQL Server性能非常重要。
I/O的性能取決于以下一些方面：
磁盤類型包括IDE、SATA、SCSI、SAS、Fibre Channel drive等類型，其中IDE、SATA一般用在個人電腦上。
同時為了在資料安全、資料性能和資料容量之間做平衡，又發展出了RAID，RAID是一種把多塊獨立的磁盤按不同的方式組合起來形成一個硬碟組，進而提供比單個硬碟更高的存儲性能和提高資料備份技術。RAID主要包括RAID0~RAID7等幾個規範，常用的RAID類型為RAID0、RAID1、RAID5,RAID10。
此外根據連接配接方式不同還可以分為：Direct Attached Storage(DAS)，Storage Area Networks(SAN)，Fibre Channel Storage Area Networks，iSCSI Storage Area Networks。
吞吐量和IOPS名額
吞吐量主要取決于陣列的架構，光纖通道的大小以及硬碟的個數。陣列的架構與每個陣列不同，但也都存在内部帶寬，不過在一般情況下，内部帶寬都設計的很充足，不是瓶頸所在。其次是光纖通道對資料流量的影響，為了達到1GB/s的資料流量要求，我們必須使用1GB*8=8GB的光纖卡，也可以用4塊2GB的光纖卡。其實是硬碟的個數，可以參考以下名額計算方式，假設為了滿足1GB的資料流量要求，所必須的磁盤個數。
IOPS(Input/Output Operations Per Second)，即每秒進行讀寫(I/O)操作的次數，多用于資料庫等場合，衡量随機通路的性能。
決定IOPS的主要取決于陣列的算法、cache命中率以及磁盤個數。Cache命中率取決于資料的分布、Cache Size的大小、資料的通路規則，以及Cache的算法。
磁盤的限制，每個磁盤能處理的IOPS是有限制的，通常情況下每個磁盤的最大IOPS是确定的，比如IDE和SATA硬碟的IOPS大緻在100以内(我們可以使用HD Tune工具進行IOPS測試)，而且IOPS的測試結果與測試方式(例如随機讀寫和順序讀寫、讀和寫的比例、傳輸資料庫尺寸的大小、磁盤的數量)有很大關系，盡管如此磁盤的IOPS名額還是對我們評估磁盤的壓力和是否能夠滿足系統的性能需求有着一定的指導意義。
假設現在的業務需求是10000 IOPS，120塊SCSI磁盤，那麼在不同的Cache命中率、不同的讀寫比例情況下，不同的RAID級别對每塊磁盤的IOPS需求是多少呢?
Raid 0 –每個磁盤的I/O計算= (讀+寫) /磁盤個數
Raid 1 --每個磁盤的I/O計算= [讀+(2*寫)]/2
Raid 5 --每個磁盤的I/O計算= [讀+(4*寫)]/磁盤個數
Raid 10 --每個磁盤的I/O計算= [讀+(2*寫)]/磁盤個數
此外當吞吐率超過85%時，會出現I/O瓶頸，是以單個磁盤IOPS計算規則為
((10000*(1-Cache命中率)*讀比例)+10000*寫比例*RAID系數)/磁盤數/0.85
即每塊磁盤的IOPS大約在200左右即可滿足RAID0、RAID5、RAID10的要求。
此外，關于SQL Server的部署一般規劃和建議如下：
作業系統和SQL Server單獨建構在RAID1的磁盤鏡像上;出于高速和安全的原則，日志檔案需要單獨安裝在RAID1/RAID10上;tempdb檔案最好放在RAID0上，而資料檔案出于安全、性能、容量、成本的綜合考慮一般則使用RAID5。
在微軟的technet上有一篇關于存儲的最佳實踐top 10(Storage Top 10 Best Practices)是這麼要求的：
1. 了解SQL Server的IO特性和應用系統的IO需求規格。
2. 使用更多/更快的磁盤驅動以擷取良好的性能
3. 不要過度優化存儲，簡單的設計通常能夠提供良好的性能和靈活性。
4. 部署前驗證配置。可以用SQLIO之類的工具模拟測試。
5. 始終把日志檔案放在RAID10/RAID1上。
6. 把日志檔案和資料檔案從實體磁盤上隔離。
7. 認真考慮TempDB的資料配置。
8. 在資料檔案的數量和CPU的容量之間平衡。
9. 不要忽視SQL Server的基礎。
10.不要忽視存儲的配置
對于SQL Server占用I/O資源的監控主要集中在磁盤響應時間、隊列長度、磁盤讀寫和傳輸速度上。下面提供了幾種對象、計數器和相應的門檻值及描述。
Sys.dm_io_virtual_file_stats能夠傳回資料和日志檔案的 I/O 統計資訊，這也為我們從整體上了解各磁盤和資料庫的吞吐量和等待時間有了一個直覺的認識。
sys.dm_io_pending_io_requests則對應SQL Server 中每個挂起的 I/O 請求，我們将sys.dm_io_pending_io_requests和Sys.dm_io_virtual_file_stats關聯起來，則可以檢視目前是否有等待的IO，然後進行去定位和識别。