⑴ sql日誌文件太大會影響性能嗎
你的資料庫的數據量大嗎？如果大，肯定的。 你的數據操作很頻繁嗎？如果頻繁，一定的。 如果這兩項都不符合，那沒有道理。
⑵ 資料庫滿了怎麼辦
問題一：資料庫空間滿了怎麼處理 1：分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫
2：刪除LOG文件
3：附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫
此法生成新的LOG，大小隻有500多K
再將此資料庫設置自動收縮
或用代碼分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器：
EXEC sp_detach_db @dbname = 'pubs'
EXEC sp_attach_single_file_db @dbname = 'pubs',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'
問題二：資料庫滿了怎麼辦？ 資料庫是只讀的(Readonly),也即不可以修改(增加\刪除\修改都不行)
問題三：SQL server資料庫日誌滿了怎麼處理？ 解決方法
日誌文件滿而造成SQL資料庫無法寫入文件時，可用兩種方法：
一種方法：清空日誌。
1．打開查詢分析器，輸入命令
DUMP TRANSACTION 資料庫名 WITH NO_LOG
2.再打開企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。
另一種方法有一定的風險性，因為SQL SERVER的日誌文件不是即時寫入資料庫主文件的，如處理不當，會造成數據的損失。
1: 刪除LOG
分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫
2：刪除LOG文件
附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫
此法生成新的LOG，大小隻有500多K。
注意：建議使用第一種方法。
如果以後,不想要它變大。
SQL2000下使用：
在資料庫丁點右鍵->屬性->選項->故障恢復-模型-選擇-簡單模型。
或用SQL語句：
alter database 資料庫名 set recovery simple
另外，如上圖中資料庫屬性有兩個選項，與事務日誌的增長有關：
Truncate log on checkpoint
(此選項用於SQL7.0，SQL 2000中即故障恢復模型選擇為簡單模型)
當執行CHECKPOINT 命令時如果事務日誌文件超過其大小的70% 則將其內容清除在開發資料庫時時常將此選項設置為True
Auto shrink
定期對資料庫進行檢查當資料庫文件或日誌文件的未用空間超過其大小的25%時，系統將會自動縮減文件使其未用空間等於25% 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日誌文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行。
注意：一般立成建立的資料庫默認屬性已設好，但碰到意外情況使資料庫屬性被更改，請用戶清空日誌後，檢查資料庫的以上屬性，以防事務日誌再次充滿。
問題四：資料庫空間滿了怎麼處理 各資料庫空間滿處理方法
wenku./...YexzIW
問題五：網站的虛擬空間，資料庫滿了怎麼辦？ 肯定有影響啦，你自己說的，每天發很多文章，最終資料庫滿了，就是說文章保存在資料庫中，一般來說資料庫保存釘東西都是內存不是很大的東西，除了網站cms所必要的數據和系統日誌之外，就是你文章的文字啦，至於圖片和視頻等等佔用空間很多的東西就保存在網頁空間裡面了，和數據沒有關系。
就如樓上的所說，問題不大，增加資料庫的容量就行了，現在一般的IDC都會提供這樣的服務，對你現在的網站不會有影響的。此外聯系客服也很重要的。祝你早日解決問題！
問題六：SQL數據磁碟滿了怎麼解決？ -- 清空日誌
--壓縮日誌及資料庫文件大小
/*--特別注意
請按步驟進行,未進行前面的步驟,請不要做後面的步驟
否則可能損壞你的資料庫.
--*/
select*fromsysfiles
--1.清空日誌
DUMPTRANSACTIONusernameWITHNO_LOG
--2.截斷事務日誌：
BACKUPLOGusernameWITHNO_LOG
--3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小
-- 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件
--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
--選擇數據文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
-- 也可以用SQL語句來完成
--收縮資料庫
DBCCSHRINKDATABASE(username)
--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select*fromsysfiles
DBCCSHRINKFILE(2)
--4.為了最大化的縮小日誌文件(如果是sql7.0,這步只能在查詢分析器中進行)
-- a.分離資料庫:
-- 企業管理器--伺服器--資料庫--右鍵--分離資料庫
-- b.在我的電腦中刪除LOG文件
-- c.附加資料庫:
-- 企業管理器--伺服器--資料庫--右鍵--附加資料庫
-- 此法將生成新的LOG，大小隻有500多K
-- 或用代碼：
-- 下面的示例分離username，然後將username中的一個文件附加到當前伺服器。
execsp_dboptionusername,'singleuser',true
a.分離
[email protected] ='username'
b.刪除日誌文件
execmaster..xp_cmdshell'delD:\ProgramFiles\SQL\database\username_LOG.ldf'
c.再附加
[email protected] ='username',
@physname='D:\ProgramFiles\SQL\database\username_Data.MDF'
--5.為了以後能自動收縮,做如下設置:
-- 企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇自動收縮
--SQL語句設置方式:
EXECsp_dboption'資料庫名','autoshrink','TRUE'
--6.如果想以後不讓它日誌增長得太大
-- 企業管理器--伺服器--右鍵數據......>>
問題七：資料庫日誌已滿，如何處理？ 先提供一種復雜的方法壓縮日誌及資料庫文件如下：1.清空日誌 mp transaction 庫名 with no_log2.截斷事務日誌： backup log 資料庫名 with no_log3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件 --選擇日誌文件--在收縮方式里選擇收縮至xxm,這里會給出一個允許收縮到的最小m數,直接輸入這個數,確定就可以了 --選擇數據文件--在收縮方式里選擇收縮至xxm,這里會給出一個允許收縮到的最小m數,直接輸入這個數,確定就可以了 也可以用sql語句來完成 --收縮資料庫 dbcc shrinkdatabase(客戶資料) --收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfiles dbcc shrinkfile(1)4.為了最大化的縮小日誌文件(如果是sql 7.0,這步只能在查詢分析器中進行) a.分離資料庫: 企業管理器--伺服器--資料庫--右鍵--分離資料庫 b.在我的電腦中刪除log文件 c.附加資料庫: 企業管理器--伺服器--資料庫--右鍵--附加資料庫 此法將生成新的log，大小隻有500多k 或用代碼： 下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器。 a.分離 e x e c sp_detach_db @dbname = 'pubs' b.刪除日誌文件 c.再附加 e x e c sp_attach_single_file_db @dbname = 'pubs', @physname = 'c:\program files\microsoft sql server\mssql\data\pubs.mdf'5.為了以後能自動收縮,做如下設置: 企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇自動收縮 --sql語句設置方式: e x e c sp_dboption '資料庫名', 'autoshrink', 'true'6.如果想以後不讓它日誌增長得太大 企業管理器--伺服器--右鍵資料庫--屬性--事務日誌 --將文件增長限制為xm(x是你允許的最大數據文件大小) --sql語句的設置方式: alter database 資料庫名 modify file(name=邏輯文件名,maxsize=20) 我來完善答案完善答案通過審核後，可獲得3點財富值最新回答：2012-06-20 05:01 版本：1個歷史版本
問題八：如何從根本上解決SQL資料庫日誌已滿的問題 1、你設置了日誌文件的最大數，資料庫的恢復模式是完整恢復模式，所有的針對資料庫的改動都會記錄到日誌，不僅僅是你的改動資料庫，資料庫本身的操作也有記錄到日誌，所以，日誌文件才會不斷增長。
2、那是因為大部分的電腦上的資料庫，基本沒怎麼變過，但生產用的資料庫經常變動，所以日誌記錄也變得巨大，我見過資料庫200MB，但是日誌文件50GB，因為本來資料庫有10GB，因為測試需要刪除了大部分的數據，結果導致日誌文件增長到了50GB。
3、定時備份日誌並收縮日誌文件。
4、通過備份日誌，並收縮日誌文件，這個語句你自己網路。
5、日誌是一個以事務編號連續的記錄，比如，我第一次備份的日誌事務編號為1-1000，那麼日誌就會被截斷，並從1001開始，之後的日誌備份就從1001開始了，所以，初始備份一直到最後一次備份都不能刪除，否則使用日誌恢復時會出現問題。
問題九：oracle資料庫空間占滿了，怎麼辦 1、刪除無用文件或數據，騰空間。
2、將空間緊張的數據移到其他空閑空間。
3、增加新存儲空間。
問題十：如何清理sql server 已滿的資料庫日誌 SQLSERVER的資料庫日誌佔用很大的空間，下面提供三種方法用於清除無用的資料庫日誌文件
方法一：
1、打開查詢分析器，輸入命令
backup log database_name WITH NO_log
2、再打開企業管理器--右鍵要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至xxm,這里會給出一個允許收縮到的最小m數,直接輸入這個數,確定就可以了。
方法二：
設置檢查點，自動截斷日誌
一般情況下，SQL資料庫的收縮並不能很大程度上減小資料庫大小，其主要作用是收縮日誌大小，應當定期進行此操作以免資料庫日誌過大
1、設置資料庫模式為簡單模式：打開SQL企業管理器，在控制台根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的伺服器-->雙擊打開資料庫目錄-->選擇你的資料庫名稱（如用戶資料庫cwbase1）-->然後點擊右鍵選擇屬性-->選擇選項-->在故障還原的模式中選擇「簡單」，然後按確定保存
2、在當前資料庫上點右鍵，看所有任務中的收縮資料庫，一般裡面的默認設置不用調整，直接點確定
3、收縮資料庫完成後，建議將您的資料庫屬性重新設置為標准模式，操作方法同第一點，因為日誌在一些異常情況下往往是恢復資料庫的重要依據
方法三：通過SQL收縮日誌
把代碼復制到查詢分析器里，然後修改其中的3個參數(資料庫名，日誌文件名，和目標日誌文件的大小)，運行即可
SET NOCOUNT on
DECLARE @logicalFileName sysname,
@MaxMinutes int,
@NewSize int
USE tablename -- 要操作的資料庫名
select @logicalFileName = 'tablename_log', -- 日誌文件名
@MaxMinutes = 10, -- Limit on time allowed to wrap log.
@NewSize = 1 -- 你想設定的日誌文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
select @OriginalSize = size
from sysfiles
WHERE name = @logicalFileName
select 'Original Size of ' + db_name() + ' log is ' +
ConVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
ConVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'mb'
from sysfiles
WHERE name = @logicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)
DECLARE @Counter int,
@StartTime DATETIME,
@Trunclog VARCHAR(255)
select @StartTime = getdate(),
@Trunclog = 'backup log ......>>
⑶ SQL Server日誌文件總結及日誌滿的處理
交易日誌（Transaction logs）是資料庫結構中非常重要但又經常被忽略的部分 由於它並不像資料庫中的schema那樣活躍 因此很少有人關注交易日誌 交易日誌是針對資料庫改變所做的記錄 它可以記錄針對資料庫的任何操作 並將記錄結果保存在獨立的文件中 對於任何每一個交易過程 交易日誌都有非常全面的記錄 根據這些記錄可以將數據文件恢復成交易前的狀態 從交易動作開始 交易日誌就處於記錄狀態 交易過程中對資料庫的任何操作都在記錄范圍 直到用戶點擊提交或後退後才結束記錄 每個資料庫都擁有至少一個交易日誌以及一個數據文件 出於性能上的考慮 SQL Server將用戶的改動存入緩存中 這些改變會立即寫入交易日誌 但不會立即寫入數據文件 交易日誌會通過一個標記點來確定某個交易是否已將緩存中的數據寫入數據文件 當SQL Server重啟後 它會查看日誌中最新的標記點 並將這個標記點後面的交易記錄抹去 因為這些交易記錄並沒有真正的將緩存中的數據寫入數據文件 這可以防止那些中斷桐桐畢的交易修改數據文件 維護交易日誌 因為很多人經常遺忘交易日誌 因此它也會給系統帶來一些問題 隨著系統的不斷運行 日誌記錄的內容會越來越多 日誌文件的體積也會越來越大 最終導致可用磁碟空間不足 除非日常工作中經常對日誌進行清理 否則日誌文件最終會侵佔分區內的全部可用空間 日誌的默認配置為不限容量 如果以這種配置工作 它就會不斷膨脹 最終也會占據全部可用空間 這兩種情況都會導致資料庫停止工作 對交易日誌的日常備份工作可以有效的防止日誌文件過分消耗磁碟空間 備份過程會將日誌中不再需要的部分截除 截除的方法是首先把舊記錄標記為非活動狀態 然後將新日誌覆蓋到舊日誌的位置上 這樣就可以防止交易日誌的體積不斷局芹膨脹 如果無法對日誌進行經常性的備份工作 最好將資料庫設置為 簡單恢復模式 在這種模式下 系統會強制交易日誌在每次記錄標記點時 自動進行截除操作 以新日誌覆蓋舊日誌 截除過程發生在備份或將舊標記點標為非活動狀態時 它使得舊的交易記錄可以被覆蓋 但這並不會減少交易日誌實際佔用的磁碟空間 就算不再使用日誌 它依然會占據一定的空間 因此在維護時 還需要對交易日誌進行壓縮 壓縮交易日誌的方法是刪除非活動記錄 從而減少日誌文件所佔用的物理硬碟空間 通過使用DBCC SHRINKDATABASE語句可以壓縮當前資料庫的交易日誌文件 DBCC SHRINKFILE語句用來壓縮指定的交易日誌文件 另外也可以在資料庫中激活自動壓縮操作 當壓縮日誌時 首先會將舊記錄標記為非活動狀態 然後將帶有非活動標記的記錄徹底刪除 根據所使用的壓縮方式的不同 你可能不會立即看到結果 在理想情況下 壓縮工作應該選在系統不是非常繁忙的時段進行 否則有可能影響資料庫性能 恢復資料庫 交易記錄備份可以用來將資料庫恢復到某一指定狀態 但交易記錄備份本身不足以完成恢復資料庫的任務 還需要備份的數據文件參與恢復工作 恢復資料庫時 首先進行的輪斗是數據文件的恢復工作 在整個數據文件恢復完成前 不要將其設為完成狀態 否則交易日誌就不會被恢復 當數據文件恢復完成 系統會通過交易日誌的備份將資料庫恢復成用戶希望的狀態 如果在資料庫最後一次備份後 存在多個日誌文件的備份 備份程序會按照它們建立的時間依次將其恢復 另一種被稱為log shipping的過程可以提供更強的資料庫備份能力 當log shipping配置好後 它可以將資料庫整個復制到另一台伺服器上 在這種情況下 交易日誌也會定期發送到備份伺服器上供恢復數據使用 這使得伺服器一直處於熱備份狀態 當數據發生改變時它也隨之更新 另一個伺服器被稱作監視（monitor）伺服器 可以用來監視按規定時間間隔發送的shipping信號 如果在規定時間內沒有收到信號 監視伺服器會將這一事件記錄到事件日誌 這種機制使得log shipping經常成為災難恢復計劃中使用的方案 性能優化 交易日誌對資料庫有重要作用 同時它對系統的整體性能也有一定影響 通過幾個選項 我們可以對交易日誌的性能進行優化 由於交易日誌是一個連續的磁碟寫入過程 在這當中不會發生讀取動作 因此將日誌文件放在一個獨立的磁碟 對優化性能有一定作用 另一項優化措施與日誌文件的體積有關 我們可以設置日誌文件的體積不超過硬碟空間的百分之幾 或者確定它的大小 如果將其設置的過大會浪費磁碟空間 而如果設置的過小則會強制記錄文件不斷嘗試擴展 導致資料庫性能下降 事務日誌文件Transaction Log File是用來記錄資料庫更新情況的文件 擴展名為ldf 在 SQL Server 和 SQL Server 中 如果設置了自動增長功能 事務日誌文件將會自動擴展 一般情況下 在能夠容納兩次事務日誌截斷之間發生的最大數量的事務時 事務日誌的大小是穩定的 事務日誌截斷由檢查點或者事務日誌備份觸發 然而 在某些情況下 事務日誌可能會變得非常大 以致用盡空間或變滿 通常 在事務日誌文件占盡可用磁碟空間且不能再擴展時 您將收到如下錯誤消息 Error: Severity: State: The log file for database % *ls is full 除了出現此錯誤消息之外 SQL Server 還可能因為缺少事務日誌擴展空間而將資料庫標記為 SUSPECT 有關如何從此情形中恢復的其他信息 請參見 SQL Server 聯機幫助中的 磁碟空間不足 主題 另外 事務日誌擴展可能導致下列情形 · 非常大的事務日誌文件 · 事務可能會失敗並可能開始回滾 · 事務可能會用很長時間才能完成 · 可能發生性能問題 · 可能發生阻塞現象 原因 事務日誌擴展可能由於以下原因或情形而發生 · 未提交的事務· 非常大的事務· 操作 DBCC DBREINDEX 和 CREATE INDEX· 在從事務日誌備份還原時· 客戶端應用程序不處理所有結果· 查詢在事務日誌完成擴展之前超時 您收到假的 Log Full 錯誤消息· 未復制的事務 解決方法 日誌文件滿而造成SQL資料庫無法寫入文件時 可用兩種方法 一種方法 清空日誌 ．打開查詢分析器 輸入命令DUMP TRANSACTION 資料庫名 WITH NO_LOG 再打開企業管理器 右鍵你要壓縮的資料庫 所有任務 收縮資料庫 收縮文件 選擇日誌文件 在收縮方式里選擇收縮至XXM 這里會給出一個允許收縮到的最小M數 直接輸入這個數 確定就可以了 另一種方法有一定的風險性 因為SQL SERVER的日誌文件不是即時寫入資料庫主文件的 如處理不當 會造成數據的損失 : 刪除LOG分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫 刪除LOG文件附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫此法生成新的LOG 大小隻有 多K 注意 建議使用第一種方法 如果以後 不想要它變大 SQL 下使用 在資料庫上點右鍵 >屬性 >選項 >故障恢復 模型 選擇 簡單模型 或用SQL語句 alter database 資料庫名 set recovery simple另外 如上圖中資料庫屬性有兩個選項 與事務日誌的增長有關 Truncate log on checkpoint(此選項用於SQL SQL 中即故障恢復模型選擇為簡單模型)當執行CHECKPOINT 命令時如果事務日誌文件超過其大小的 % 則將其內容清除在開發資料庫時時常將此選項設置為True Auto shrink定期對資料庫進行檢查當資料庫文件或日誌文件的未用空間超過其大小的 %時 系統將會自動縮減文件使其未用空間等於 % 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日誌文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行 注意 一般立成建立的資料庫默認屬性已設好 但碰到意外情況使資料庫屬性被更改 請用戶清空日誌後 檢查資料庫的以上屬性 以防事務日誌再次充滿 lishixin/Article/program/SQLServer/201311/22123
⑷ sql server 2000 tempdb日誌已滿有什麼影響
肯定有影響，先說說tempdb資料庫的作用吧：
Tempdb 資料庫保存系統運行過程中產生的臨時表和存儲過程。當然，它還滿足其他的臨時存儲要求，比如保存SQL Server生成的存儲表等。Tempdb 資料庫是一個全局咨詢，任何連接到系統的用戶都可以在該資料庫中產生臨時表和存儲過程。Tempdb 資料庫在每次SQL Server啟動的時候，都會清空該資料庫中的內容，所以每次啟動SQL Server後，該表都是干凈的。臨時表和存儲過程在連接斷開後會自動除去，而且當系統關閉後不會有任何活動連接，因此，tempdb 資料庫中沒有任何內容會從SQL Server的一個會話保存到另外一個會話中。
默認情況下，在 SQL Server 在運行時 tempdb 資料庫會根據需要自動增長。不過，與其它資料庫不同，每次啟動資料庫引擎時，它會重置為其初始大小。如果為 tempdb 資料庫定義的大小較小，則每次重新啟動 SQL Server時，將tempdb 資料庫的大小自動增加到支持工作負荷所需的大小這一工作可能會成為系統處理負荷的一部分。為避免這種開銷，可以使用 ALTER DATABASE 增加 tempdb 資料庫的大小。
其實總體來說TempDB資料庫是很重要的，也是你提升SQL運行速度的一個手段，所以，TempDB的日誌已滿，說明的資料庫文件初始化設定值太小，建議你增大到500MB，我一直都這樣用，當然你可以依據實際情況設定大小