⑴ 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，我一直都这样用，当然你可以依据实际情况设定大小