sql分配空間

『壹』 在sql Server資料庫中對象分配空間的基本單位是

SQL Server 存取數據的基本單位：頁（Page），大小為8KB
一個盤區（Extent）由8 個連續的頁組成。

『貳』 關於sql server資料庫分配空間的問題

哈哈，居然有這樣的問題，我都從來沒有遇到過。可能資料庫嚴重超過你原來注冊的限制容量2048，你先把資料庫收縮一下，然後再試一下擴容吧。
要是還不行，把數據分離了，然後再附加上去，呵呵。

『叄』 SQL資料庫怎麼為每個用戶分配不同的空間

在UserTB里加多一個欄位[user]存放在User里的用戶名,然後用篩選where [user]='A' --如果是A用戶,其它用戶類似
或是用篩選建立視圖也行

『肆』 如何設置SQL伺服器的內存分配

步驟如下：
點擊Start > Run
鍵入WINMSD。
選擇Memory選項。
記錄下來計算的一個內存值物理存儲器(k) SQL資料庫的。
初始化SQL企業管理器。
選擇為存儲器分配將配置的資料庫。
用滑鼠右鍵單擊在資料庫並且選擇配置。Server Configuration Options窗口打開。
選擇Configuration選項。
移下來對內存行。有三列：「最低、最大數量、運行和當前內存分配」。

『伍』 sql 2000資料庫文件可分配空間最大可為多少

跟操作系統對文件的管理有關，fat32最大4G,fnt為硬碟剩餘空間。

『陸』 SQL伺服器內存怎麼動態分配

SQL伺服器內存有兩種基本管理方法：動態分配和靜態分配

控製程序可使用的內存數量。動態分配允許管理員聲明一塊內存的大小；考慮到它的實際使用，SQL伺服器可以分配給其需要佔用的內存的最大值，並且（理論上）在沒有使用內存的情況下將其釋放。靜態分配則是創建一塊固定的內存空間，提供給SQL Server使用——不再進行分配。

在默認情況下，SQL Server被設置成動態分配，分配給其正在運行的計算機內所有可用的物理內存。許多管理員注意到SQL Server內存隨時間的流逝被逐漸消耗殆盡時，其原因很可能是故障或是內存漏洞，但這個程序正是被設計成這樣的。SQL Server就是要在任何可能的情況下在電腦中運行，並因此為達到其最佳性能而使用所有可用的內存。如果SQL Server在獨立的機器中運行，那麼就讓它分配和釋放其需要的內存吧。

在一個小型商業伺服器機器中，SQL可能與其他程序，如IIS，同時運行，管理員或許嘗試著進行設置，使SQL Server運行在一塊固定大小的內存，目的是控制其不會佔用用於共享的內存。但這並不一定能如願以償。一方面，將內存的最高限度設置得太低，並且沒有分配給SQL伺服器足夠的可用內存來用作類似事務日誌或查詢執行的緩存，所有這些都很難辦到。使SQL伺服器得到執行操作所需內存的惟一方法就是換出其他的頁面，這是個緩慢的過程。

有許多方法可以計算出最好的內存分配。如果你有可預知的用戶負載，依照用戶所需的最大數目分配給他們。微軟推薦至少用4 MB用作動態的最大空間，這已經成為一個可能的規則。如果你的用戶負載變化范圍很大——如以下情況，當你通過IIS 的前端連接到公共的網際網路來支持你的資料庫服務的時候——實時的統計數據將會比僅憑猜測所作的工作幫助更大。在高峰期，把SQL Server的高速緩存命中率和每秒缺頁率等性能數字搜集起來。如果這些數據表明SQL Server正在做大量的交換，那麼增加最大內存空間直到交換逐漸減少。每秒一次或更多次的交換是有壞處的。

另一種選擇是使「為SQL Server預留物理內存」的選項可用，這可以防止SQL Server把已經分配給它的內存換出，即使當其他應用程序能夠使用它時。這可以叫做是一把雙刃劍：它既可以相當大程度的提高性能，也可能帶來更大的性能損害。在有許多RAM 可以共享的（1 GB 或更多）的系統中，這是值得一試的，但是當有其他關鍵的進程可能突然需要大量的內存時，這種辦法是不應該使用的。（並且如果需要的話，SQL Server可能會被迫放棄一些它自己的內存）。如果SQL Server是在獨立的機器上運行，用這種辦法最佳化性能則是值得的。

『柒』 SQL分配空間不足，請教如何解決

因SQL備份文件大小並不代表還原出來的資料庫文件大小。有時候日誌文件很大，其中大部分都是未使用的空間，而沒有進行收縮就進行備份的話，備份文件中記錄的還是日誌文件的大小，在還原的時候就還是很大。你可以執行restore filelistonly來查看備份中文件的大小。比如你的備份文件是d:\db.bak,語句就是restore filelistonly from disk='d:\db.bak'在結果集中，size是文件的位元組數。如果很大，最好還原到有足夠空間的分區，注意要加move選項。

『捌』 SqlServer是如何管理，分配存儲空間的呢

Sql Server 區管理(GAM,SGAM)

大家都知道Sql Server 中數據文件存儲的最小單位是頁面(Page),但實際SQLSERVE並不是以頁面為單位給數據分配空間的，Sql Server默認的存儲分配單位是盤區(Extend)。這樣做的主要原因是為了避免頻繁的讀寫IO，提升性能。在表或其它對象分配存儲空間，不是直接分配一個8K的頁面，而是以一個盤區(Extend)為存儲分配單位，一個盤區為8個頁面(Size = 8＊8K＝64K)。

這樣，對區得操作就會非常頻繁，也要求Sql Server有自己的一套系統管理著數量眾多的區。其中最突出的出一個問題，那就是在存儲那些只有少量數據，不足8K的對象，如果也是分配給一個盤區，就會存在存儲空間上的浪費，降低了空間分配效率。

為解決上述問題，SQLSERVER提供了一種解決方案，定義了兩種盤區類型,統一盤區和混合盤區。

全局分配映射表 (GAM)：統一盤區，GAM 頁記錄已分配的區。每個 GAM 包含 64,000 個區，相當於近 4 GB 的數據。GAM 用一個位來表示所涵蓋區間內的每個區的狀態。如果位為 1，則區可用；如果位為 0，則區已分配。

共享全局分配映射表 (SGAM)：由多個對象共同擁有該盤區，SGAM 頁記錄當前用作混合區且至少有一個未使用的頁的區。每個 SGAM 包含 64,000 個區，相當於近 4 GB 的數據。SGAM 用一個位來表示所涵蓋區間內的每個區的狀態。如果位為 1，則區正用作混合區且有可用頁。如果位為 0，則區未用作混合區，或者雖然用作混合區但其所有頁均在使用中。


在實際為對象分配存儲盤區時，為了提高空間利用率，默認的情況下，如果一個對象一開始大小小於8個頁面，就盡量放在混合盤區中，如果該對象大小增加到8個頁面後，SQLSERVER會為這個對象重新分配一個統一盤區。

據區當前的使用情況，GAM 和 SGAM 中每個區具有以下位模式：



第0個bit為保留位元組，始終為0

第1個bit表示該頁面是否已分配，我們知道GAM頁用來管理區是否已分配，但一個區包含8個頁面，所以用該bit用來准確定位該區的某個頁面是否已分配出去了。

第2個bit表示該頁面是否混合分區的一個頁面。

第3個bit表示該頁面是否是一個IAM(索引分配映射)頁面。

第4個bit表示該頁面中是否包含幻影或已刪除記錄，這有助於SQL Server定期清理幻影或已刪除記錄。

第5~7個頁面表示該頁面的空間使用率情況。

『玖』 如何釋放SQL表中己分配但又未使用的空間

SQL Server 2000 自動收縮有大量可用空間的資料庫。該進程僅適用於那些 autoshrink 選項設置為 true 的資料庫。伺服器定期檢查每個資料庫中的空間使用情況。如果發現資料庫中有大量閑置空間，而且它的 autoshrink 選項設置為 true，SQL Server 就縮小該資料庫中的文件大小。也可以使用 SQL Server 企業管理器或 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE 語句，手工收縮資料庫中的文件。文件始終從末端開始收縮。例如，如果有個 5 GB 的文件並將 DBCC SHRINKDB 語句中的 target_size 指定為 4GB，則 SQL Server 將從文件的最後一個 1 GB 開始釋放盡可能多的空間。如果文件中被釋放的部分包含使用過的頁，則 SQL Server 首先將這些頁重新定位到保留的部分。只能將資料庫收縮到沒有剩餘的可用空間為止。例如，某個 5GB 的資料庫有 4 GB 的數據並且 DBCC SHRINKDATABASE 語句的 target_size 被指定為 3 GB，則只釋放 1 GB。如果 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 語句無法收回日誌文件中的所有空間，該語句將發出信息，指示必須執行什麼操作以釋放更多符合條件的空間。收縮事務日誌在下列情況下，日誌文件的物理大小將減少： 執行 DBCC SHRINKDATABASE 語句時。執行引用日誌文件的 DBCC SHRINKFILE 語句時。自動收縮操作發生時。 日誌收縮操作依賴於最初的日誌截斷操作。日誌截斷操作不減小物理日誌文件的大小，但減小邏輯日誌的大小，並將沒有容納邏輯日誌任何部分的虛擬日誌標記為不活動。日誌收縮操作會刪除足夠多的不活動虛擬日誌，將日誌文件減小到要求的大小。減小大小的單位是一個虛擬日誌文件。例如，如果有個 600 MB 的日誌文件被分成了 6 個 100 MB 的虛擬日誌，則該日誌文件的大小隻能按 100 MB 遞減。比如，文件可以減小到 500 MB 或 400 MB，但不能減小到 433 MB 或 525 MB。不能釋放容納邏輯日誌部分的虛擬日誌。如果某個日誌文件中的所有虛擬日誌都容納了邏輯日誌部分，則不能收縮該文件，直到截斷操作在物理日誌的末端將一個或更多的虛擬日誌標記為不活動。當收縮任何文件時，必須從文件的末端開始釋放空間。當收縮事務日誌文件時，從文件的末端開始釋放足夠的虛擬日誌以將日誌減小到用戶所要求的大小。用戶指定的 target_size 四捨五入為下一個最大的虛擬日誌邊界大小。例如，如果用戶為包含 6 個 100 MB 虛擬日誌文件的 600 MB 文件指定 325 MB 的 target_size，則刪除最後兩個虛擬日誌文件，因此新的文件大小為 400 MB。在 SQL Server 2000 中，DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 操作試圖立即將物理日誌文件收縮到所要求的大小（以四捨五入的值為准）： 如果虛擬日誌中的邏輯日誌部分沒有超出 target_size 標記，則釋放 target_size 標記之後的虛擬日誌，並且成功完成 DBCC 語句，不出現任何信息。如果虛擬日誌中的邏輯日誌部分超出 target_size 標記，則 SQL Server 2000 釋放盡可能多的空間並發出一條信息。該信息告訴您需要執行什麼操作以獲得文件末端超出虛擬日誌的邏輯日誌部分。執行完該操作後，可以重新發出 DBCC 語句以釋放剩餘的空間。

『拾』 資料庫創建後怎樣修改資料庫數據文件和日誌文件分配的空間大小

--修改資料庫文件增量

USE master
GO
Alter DATABASE Test
MODIFY FILE
(NAME = test,
-- SIZE = 1000MB,
--MAXSIZE = 10000MB,
FILEGROWTH = 100MB)
GO

--修改資料庫日誌文件增量

USE master
GO
Alter DATABASE Test
MODIFY FILE
(NAME = test_log,
-- SIZE = 1000MB,
--MAXSIZE = 10000MB,
FILEGROWTH = 100MB)
GO

參考以下內容：

[c-sharp]view plainprint?
/*
一般的虛擬主機上，附送的sql server資料庫都是限制了大小，比如100M。當你的資料庫空間達到了指定的100M時，插入新數據就會報錯：

未能為資料庫 'a1116173958' 中的對象 'fc_Info' 分配空間，因為文件組 'PRIMARY' 已滿

其實，有些主機商的資料庫大小是可以自己修改的。當然，修改之前你需要知道資料庫名（這里是邏輯名稱），一般的這個名稱是很容易知道的，就是資料庫名稱。

你可以嘗試下在自己編寫的程序中，或空間的管理後台中等可以執行sql語句的地方試一下下面的語句：

Alter DATABASE 資料庫名
modify FILE
( NAME = 資料庫名,
MAXSIZE = 200MB,
FILEGROWTH = 5MB)

如果執行成功，那麼恭喜你了。

========我是分割線============================================

下面是Alter DATABASE的一些參考資料，詳細可以查看sql server幫助。

在資料庫中添加或刪除文件和文件組。也可用於更改文件和文件組的屬性，例如更改文件的名稱和大小。Alter DATABASE 提供了更改資料庫名稱、文件組名稱以及數據文件和日誌文件的邏輯名稱的能力。

Alter DATABASE 支持資料庫選項的設置。在早期版本的 Microsoft® SQL Server™ 中，這些選項可以通過 sp_dboption 存儲過程來設置。在此次發布的版本中，SQL Server 繼續支持 sp_dboption存儲過程，但在未來版本中可能不再支持。可使用 DATABASEPROPERTYEX 函數檢索資料庫選項的當前設置。

語法
Alter DATABASE database
{ ADD FILE < filespec > [ ,...n ] [ TO FILEGROUP filegroup_name ]
| ADD LOG FILE < filespec > [ ,...n ]
| REMOVE FILE logical_file_name
| ADD FILEGROUP filegroup_name
| REMOVE FILEGROUP filegroup_name
| MODIFY FILE < filespec >
| MODIFY NAME = new_dbname
| MODIFY FILEGROUP filegroup_name {filegroup_property | NAME = new_filegroup_name }
| SET < optionspec > [ ,...n ] [ WITH < termination > ]
| COLLATE < collation_name >
}

< filespec > ::=

( NAME = logical_file_name
[ , NEWNAME = new_logical_name ]
[ , FILENAME = 'os_file_name' ]
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] )

< optionspec > ::=

<state_option>
| < cursor_option >
| < auto_option >
| < sql_option >
| < recovery_option >
< state_option > ::=
{ SINGLE_USER | RESTRICTED_USER | MULTI_USER }
| { OFFLINE | ONLINE }
| { READ_ONLY | READ_WRITE }

< termination > ::=
ROLLBACK AFTER integer [ SECONDS ]
| ROLLBACK IMMEDIATE
| NO_WAIT
< cursor_option > ::=
CURSOR_CLOSE_ON_COMMIT { ON | OFF }
| CURSOR_DEFAULT { LOCAL | GLOBAL }
< auto_option > ::=
AUTO_CLOSE { ON | OFF }
| AUTO_Create_STATISTICS { ON | OFF }
| AUTO_SHRINK { ON | OFF }
| AUTO_Update_STATISTICS { ON | OFF }
< sql_option > ::=
ANSI_NULL_DEFAULT { ON | OFF }
| ANSI_NULLS { ON | OFF }
| ANSI_PADDING { ON | OFF }
| ANSI_WARNINGS { ON | OFF }
| ARITHABORT { ON | OFF }
| CONCAT_NULL_YIELDS_NULL { ON | OFF }
| NUMERIC_ROUNDABORT { ON | OFF }
| QUOTED_IDENTIFIER { ON | OFF }
| RECURSIVE_TRIGGERS { ON | OFF }
< recovery_option > ::=
RECOVERY { FULL | BULK_LOGGED | SIMPLE }
| TORN_PAGE_DETECTION { ON | OFF }