我一直在尋找我們爲客戶端設置的新數據庫服務器，並注意每次文件已滿並且初始大小爲100 MB時，數據庫文件都設置爲增長1 meg 。按大小SQL Server 2005自動增長
我一直在考慮這件事，它聽起來不對。我檢查了一些關於數據庫考慮因素的網站，他們沒有正確解釋這些數據。
我可能只想讓數據庫文件每月擴展一次我們應該說什麼？
所以，如果我是計算數據，我期望在兆每天插入，只是乘以30，我應該找到一個合適的數字是多少？
即我知道大約1行的大小以及大約有多少行會在每桌平均每週插入。我知道這些是從頭開始估計的，所以你認爲每月一次是文件擴展的合適近似值，還是最好每小時擴展一次？或從不？
我們使用的是後衛，所以我們可以恢復到的時間和事務日誌備份點是存在的，並在恢復過程似乎是100％有效。這些類型的變化是否會以任何方式影響備份和恢復？
謝謝。
你提出的建議非常重要。你希望自動增長是基於你期望看到的。
具有自動增長的1Mb每次它是完全將遇到巨大的性能問題，因爲每次數據庫已滿數據庫，無論交易過程中，將不得不暫停，直到它已成長。
我試圖找到一個文章我關於這個問題的早期閱讀，所以當我找到它，我將添加一個鏈接...
編輯：http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1330922,00.html 這篇文章是關於縮小你的數據庫，但它詳細說明了數據庫自動增長時發生的情況，並顯示了它可能具有的性能影響。
你絕對不希望你的數據庫的增長速度與1Mb一樣快！
對於嘗試將數據庫不斷增長的次數降至最低時，通常是正確的。
我無法給你任何確切的值，但是最好是讓數據庫文件的大小如此之大，你只需要偶爾增大它，然後它必須大幅增長，以免頻繁更改文件大小。
數據文件已經增長時，它都會佔用一些資源量，因爲它抓起額外的磁盤空間和擴展數據文件。所以，理想情況下你想限制增長的數量。
我個人試圖確保我的數據庫不必自動增長。我試圖在下班時間主動增長它們。這也讓我監視磁盤空間更好，因爲這不能輕易「自動成長」;）
每月如果他們自動增長，一旦它應該罰款。每分鐘你都會看到性能影響。
除了可能佔用更多空間和填滿備份位置的備份之外，我無法想出任何會導致備份過程出現問題的原因。我更像是一名SQL開發人員，而不是DBA，所以我不能發誓。
除了一些冗餘的分配空間之外，大尺寸增量幾乎沒有或沒有缺點。將增量設置爲使其每月或幾個月增長的大小都是正確的。
無論如何，您應該有一個定期的工作來監視磁盤卷和文件中的可用空間，並生成一份報告，以便您可以看到即將發生的磁盤短缺。
我剛剛在SQL Server Management Studio 2008中進行了檢查，創建新數據庫時的默認增長是1MB ......這可能是您的1MB設置來自哪裏（我敢打賭它在2005年是一樣的）。
我記得很久以前讀過一篇文章，可以考慮將其數據庫文件設置爲在每次需要增長時加倍。現在，如果你有一個5TB的數據庫，你可能不希望它有一天增加一倍，但對於一個大小爲1GB的數據庫來說，它可能是很酷的，如果它需要的時候它翻倍（如果你的話你會有一個衰退的增長事件率具有恆定的數據輸入速率）。
只是想呈現我認爲可能是一個可行的策略，當然取決於你的情況。
當我們不確定在一天或一週內可能添加的數據的實際大小時，可以設置文件增長百分比（最佳爲5％到10％）。在這種情況下，文件增長將與數據庫的大小成比例。
在我看來，我不會設置數據庫以百分比增長，而是讓數據庫在100 MB增長一週，然後將增長設置更改爲一週增長，比如5 GB。我們有這樣做的系統。
否則，您可以獲得真正的技術，並查看每週向系統添加多少條記錄，考慮歸檔或刪除的記錄，然後計算每條記錄所需的空間量，並設置自動增長基於那個時間的記錄數量。
我將引導一個人遠離百分比增長的原因是，當系統爲1000 MB時，它將增長100 MB。然後，下一次，系統是1100 MB，並將增加我的110 MB。大小將是1210，數據庫將增長到121 MB。那麼規模將是1331，增長將是133 MB。隨着這種不均衡的增長，它將很難計算剩餘的磁盤空間以及何時需要重新調整最大設置。
只要我2美分。
此外，上述默認增長在MODEL數據庫中設置。當你創建一個新的數據庫時，你的MODEL數據庫有什麼設置是新數據庫默認的。