減少信息重復、更新異常、插入異常、刪除異常等等。
『貳』 sql2000資料庫太大備份不動怎麼辦
1680M雖然不小，但也不會備份了這么久，
如果資料庫能暫停，那可以重啟一下資料庫，然後再嘗試備份，
如果重啟了還不行，那就先分離掉，然後復制一份出來。
如果不能暫停，那試試添加備份計劃看能不能行得通
『叄』 ACCESS資料庫的體積多大時操作會卡呢
ACCESS資料庫的體積是有限制的，單個ACCESS資料庫文件的SIZE最大限制是2G。對於一般單機用戶來說，如果不存儲圖片、音樂等數據文件，它足夠您存儲n多年的數據了。
ACCESS一般來說幾百M不在話下，設計良好的資料庫存儲幾百甚至上千萬行數據也可以飛快地運行，但是設計不佳的資料庫可能存儲幾千行數據就跑不太動的情況也會發生。當然您電腦配置的高低也對運行是否順暢有重要影響。不過請注意，ACCESS資料庫的最大問題是穩定性不太好，容易崩潰，對於前台和後台都在一起的資料庫應用系統更是如此。如果您的數據非常重要，強烈建議建議將前台應用程序和後台資料庫分開。根據我們多年使用ACCESS資料庫的經驗來看，前台與後台分開的ACCESS資料庫應用系統因為崩潰而導致數據丟失的情況絕少發生，而兩者合在一起的因系統崩潰而導致數據丟失則是大概率事件！
良好設計是資料庫順暢運行的前提，這對所有資料庫都適用，否則即使是ORACLE、MSSQL這些大型資料庫系統也一樣跑不動
『肆』 MSSQL資料庫 數據量過200萬，怎麼樣可以加速、穩定
隨著記錄的越來越多，訪問效率有所降低那是正常的，但像你的「200萬條記錄,100MB的」資料庫,應該效率很高才對的
估計是你哪裡出現了瓶頸問題了
首先,問題可能由以下方面引起的:
1、磁碟io速度慢?
2、你的庫中一些大表（記錄比較多的表）的索引建立得不合理?
3、你的一些sql語句寫法不夠優化?
4、可能涉及到資料庫操作的一些邏輯處理操作比較復雜?
5、分配給SQL SERVER的可用內存過小，造成數據緩存命中率過低?（即大部分數據每次都要讀自硬碟，而不是讀自內存緩沖）
6、是否有一些涉及到操作資料庫的大計劃任務在頻繁的執行著?
7、是否表的索引產生了大量的碎片，造成命中率過低？
下面列出一些檢查解決辦法：
1、通過「windows 任務管理器」中的「進程」項添加io列檢查io的變化及處理速度。
2、如果你系統是多個磁碟的，考慮在資料庫的文件組下建立多個文件（這多個文件分散到不同的磁碟上去，以提高io處理速度）。
3、檢查你的庫中，哪些表的記錄多，然後著重分析這些大表的結構、索引等是否建立得合理（註：索引不是越多越好的，因為索引在提高查詢效率的同時，也會增加維護索引的代價的，如：update表、insert表、delete表等時需要維護索引）。
4、利用sql server自帶的「事件探查器」去跟蹤資料庫中哪些語句的執行最為耗時（通過這個基本上可以定位整個系統慢在哪些語句上）？
5、找到一些下率低下耗時的語句，分析其涉及到的表的索引是否合理，可以把語句拷貝到「查詢分析器」上，然後按"ctrl+K"顯示語句的「執行計劃」，然後按F5執行語句，看其「執行計劃」的結果，跟蹤分析這些語句慢在那裡（這里有便於引導你去建立一些合理的索引）。
6、建議你的伺服器只跑資料庫，然後給其分配合理足夠的內存讓SQL SERVER獨占，在「企業管理器」里，選中你注冊的SQL SERVER伺服器，右鍵，然後在彈出的窗口裡選「屬性」，進去再選「內存」那項，把內存的最大值設為一個合理的值（如：你的伺服器只跑SQL 服務的話，那可以選80%的內存給SQL server)。
7、檢查SQL server的作業，看是否常有一些大作業調度在執行？這些調度是否可以優化或合並？
8、定期對表的索引進行重建（特別是對一些頻繁變化記錄的大表），另外，在重建時，對一些頻繁變化記錄的表，其填充因子要填合適的值（如，一個表的記錄是不斷增加的，那填充因子就不能填100%了，這樣容易引起頁拆分而使效率降低），下面舉個例子：
下例使用填充因子值 70 重建 authors 表上的所有索引。
DBCC DBREINDEX (authors, '', 70)
9、利用系統自帶的一些存儲過程去跟蹤系統每個連接的cpu、io等情況或資源鎖定情況，這樣容易定位一些連接或操作或對象等。如：
sp_who2
sp_lock
『伍』 SQL資料庫文件太大怎麼處理
處理方法：
1、用BACKUP LOG database WITH NO_LOG清除日誌
把資料庫屬性中的故障還原模型改為「簡單」可以大大減慢日誌增長的速度。
用BACKUP LOG database WITH NO_LOG命名後，會截斷不活動日誌，不減小物理日誌文件的大小，但邏輯日誌會減小，收縮資料庫後會把不活動虛擬日誌刪除來釋放空間，不會損壞數據。
如果日誌被截斷並收縮資料庫後，就不能直接用最近的一個全庫備份做時間點還原，建議立即備份資料庫，以防萬一。
2、sql server運行中，刪除主資料庫事務日誌文件，步驟如下：
(1)、分離資料庫管理器－資料庫－右擊要刪除日誌的資料庫－所有任務－分離資料庫
(2)、然後刪除日誌文件
(3)、然後再附加資料庫
企業管理器－資料庫－右擊資料庫－所有任務－附加資料庫時只附加mdf.
3、壓縮SQL資料庫及日誌的詳細方法
可以在資料庫屬性選項中選擇「Auto shrink」選項，讓系統自動壓縮資料庫，也可以用人工的方法來壓縮。
『陸』 SQL資料庫容量大，查詢速度慢，有何解決方案
首先應該確定是誰慢的，往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容，比如可以查詢返回ID，然後再根據ID一條一條的查詢具體內容，看似慢了，在數據量達的時候快很多
對於數據可以參照下面幾點
1、優化SQL語句，SQL語句對查詢速度影響最大
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化SQLServer，比如給其分配固定的內存，預先分配查詢內存，調整CPU使用率等。
5、優化硬體資源，比如使用更高的伺服器或者硬碟，獨立安排資料庫的數據文件和索引文件，將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
另外，2G的資料庫應該不算很大了，我處理過18G的資料庫，8000萬條記錄，查詢速度可以被接受
『柒』 SQL資料庫問題（為什麼我後面四個運行不了啊）求救
這里，你要理解主鍵和外鍵的基本含義，簡單來說就是：
1、主鍵是用來唯一地標識一行數據。主鍵列必須包含唯一的值，且不能包含空值（null）。
2、外鍵用於與另一張表的關聯。是能確定另一張表記錄的欄位，用於保持數據的一致性。
你的後面外鍵的定義可以錯誤報錯信息已經很清楚的告訴你問題在哪了，【在被引用表 'staff' 中沒有與外鍵 'fk_room_sID_staff_sID' 中的引用列列表匹配的主鍵或候選鍵。】，你的staff表是復合主鍵，但是你外鍵定義時沒有加上所有主鍵碼，這樣的外鍵是無法創建成功的。
原因還是從上面主外鍵定義來分析，主外鍵最終數據都是同步級聯更新的，你的定義不同步，就會導致你沒法更新，舉個例子
表1（列1, 列2）主鍵【列1，列2】
表2（列A，列B）外鍵【列A】對應主鍵碼 【列1】
如果是這樣定於的話，當你刪除表2記錄時，因為時級聯刪除，表1可能會刪除掉其他不需要刪除的信息，因為不是根據表1主鍵刪除的。
你按照各表主鍵去重新修改定義下你的外鍵問題就解決了。
『捌』 SQL資料庫太大怎麼辦
我有個大的 SQL 文件要回放，需要馬上做，但又怕壓死業務，怎麼辦？
先來建一個測試庫：
可以看到 CPU 已經非常冷靜，並且緩慢的處理數據。
💡小貼士：pv 工具既可以用於顯示文件流的進度，也可以用於文件流的限速。在本實驗中，我們用 PV 來限制 SQL 文件發到 MySQL client 的速度，從而限制 SQL 的回放速度，達到不影響其他業務的效果。
『玖』 SQL資料庫太大怎麼辦
資料庫重組，分多表。注意數據安全轉移