解决SQL数据库日志已满的问题

解决SQL数据库日志已满的问题
解决SQL数据库日志已满的问题

解决SQL数据库日志已满的问题

1、右键数据库→属性→选项→故障还原模型→设为简单→确定;

2、右键数据库→所有任务→收缩数据库→确定;

3、右键数据库→属性→选项→故障还原模型→设为大容量日志记录→确定。

二、复杂方法

1、清空日志

DUMP TRANSACTION库名WITH NO_LOG

2、截断事务日志

BACKUP LOG数据库名WITH NO_LOG

3、收缩数据库文件(如果不压缩,数据库的文件不会减小)

企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件

--选择日志文件--在收缩方式里选择收缩至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.分离

EXEC sp_detach_db @dbname = 'pubs'

b.删除日志文件

c.再附加

EXEC sp_attach_single_file_db @dbname = 'pubs',@physname = 'c:\Program

Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'

5、为了以后能自动收缩,做如下设置

企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"

--SQL语句设置方式:

EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE'

6、如果想以后不让它日志增长得太大

企业管理器--服务器--右键数据库--属性--事务日志

--将文件增长限制为xM(x是你允许的最大数据文件大小)

--SQL语句的设置方式:

alter database 数据库名modify file(name=逻辑文件名,maxsize=20)

特别注意:

请按步骤进行,未进行前面的步骤,请不要做后面的步骤,否则可能损坏你的数据库。

一般不建议做第4、6两步,第4步不安全,有可能损坏数据库或丢失数据,第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复。

日志文件满而造成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 时才能进行。

注意:一般立成建立的数据库默认属性已设好,但碰到意外情况使数据库属性被更改,请用户清空日志后,检查数据库的以上属性,以防事务日志再次充满。

详解快速清除SQLServer日志的两种方.. Sqlserver 优化的方法删除无效的SQL SERVER组的几种方法sql server

添加数据库的方法sql server平台用存储过程进行分页.. SQL SERVER的数据类型获取SQL Server元数据的几种方法

SQL Server的有效安装ASP中server的方法SQL Server导出导入数据方法SQL Server各种日期计算方法之二

SQL Server的备份与还原

sql server日志文件总结及日志满的处理办法

sql server日志文件总结及日志满的处理办法 交易日志(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志。交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中。对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。 出于性能上的考虑,SQL Server将用户的改动存入缓存中,这些改变会立即写入交易日志,但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后,它会查看日志中最新的标记点,并将这个标记点后面的交易记录抹去,因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。 维护交易日志 因为很多人经常遗忘交易日志,因此它也会给系统带来一些问题。随着系统的不断运行,日志记录的内容会越来越多,日志文件的体积也会越来越大,最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理,否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量,如果以这种配置工作,它就会不断膨胀,最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。 对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态,然后将新日志覆盖到旧日志的位置上,这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作,最好将数据库设置为"简单恢复模式"。在这种模式下,系统会强制交易日志在每次记录标记点时,自动进行截除操作,以新日志覆盖旧日志。 截除过程发生在备份或将旧标记点标为非活动状态时,它使得旧的交易记录可以被覆盖,但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志,它依然会占据一定的空间。因此在维护时,还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录,从而减少日志文件所占用的物理硬盘空间。 通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件,DBCC SHRINKFILE语句用来压缩指定的交易日志文件,另外也可以在数据库中激活自动压缩操作。当压缩日志时,首先会将旧记录标记为非活动状态,然后将带有非活动标记的记录彻底删除。根据所使用的压缩方式的不同,你可能不会立即看到结果。在理想情况下,压缩工作应该选在系统不是非常繁忙的时段进行,否则有可能影响数据库性能。 恢复数据库 交易记录备份可以用来将数据库恢复到某一指定状态,但交易记录备份本身不足以完成恢复数据库的任务,还需要备份的数据文件参与恢复工作。恢复数据库时,首先进行的是数据文件的恢复工作。在整个数据文件恢复完成前,不要将其设为完成状态,否则交易日志就不会被恢复。当数据文件恢复完成,系统会通过交易日志的备份将数据库恢复成用户希望的

解决SQL数据库日志已满的问题

解决SQL数据库日志已满的问题 1、右键数据库→属性→选项→故障还原模型→设为简单→确定; 2、右键数据库→所有任务→收缩数据库→确定; 3、右键数据库→属性→选项→故障还原模型→设为大容量日志记录→确定。 二、复杂方法 1、清空日志 DUMP TRANSACTION库名WITH NO_LOG 2、截断事务日志 BACKUP LOG数据库名WITH NO_LOG 3、收缩数据库文件(如果不压缩,数据库的文件不会减小) 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至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.分离 EXEC sp_detach_db @dbname = 'pubs' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = 'pubs',@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf' 5、为了以后能自动收缩,做如下设置 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE' 6、如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 数据库名modify file(name=逻辑文件名,maxsize=20)

SQL数据库的备份、还原、压缩与数据转移的方法.

当前,全国各级审计机关普遍应用AO系统进行现场审计,但由于被审计单位使用的财务软件种类太多,AO系统不可能提供全部财务软件数据导入模板,虽然AO现场审计实施系统2008版比2005版在模板数量上有所增加,但仍然不能完全解决各级审计机关在实际审计工作遇到的数据导入难题,只能通过后台备份数据库,然后还原到审计人员电脑中进行处理后,再一步一步导入AO中。由于审计人员大部分非计算机专业,对数据库的基本操作了解不是很多,无形中影响了计算机辅助审计的开展。为此,笔者分析了大量的被审计单位的财务系统后台数据库,其中大部分财务软件使用了SQL作为后台数据库,因此总结了SQL数据库的备份、压缩与SQL数据库数据处理的方法,供审计人员在审计工作中借鉴使用。 一、备份数据库1、打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server 2、SQL Server组——>双击打开你的服务器——>双击打开数据库目录3、选择你的数据库名称(如财务数据库cwdata)——>然后点上面菜单中的工具——>选择备份数据库4、备份选项选择完全备份,目的中的备份到如果原来有路径和名称则选中名称点删除,然后点添加,如果原来没有路径和名称则直接选择添加,接着指定路径和文件名,指定后点确定返回备份窗口,接着点确定进行备份。二、还原数据库1、打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server;2、SQL Server组——>双击打开你的服务器——>点图标栏的新建数据库图标,新建数据库的名字自行取; 3、点击新建好的数据库名称(如财务数据库cwdata)——>然后点上面菜单中的工具——>选择恢复数据库; 4、在弹出来的窗口中的还原选项中选择从设备——>点选择设备——>点添加——>然后选择你的备份文件名——>添加后点确定返回,这时候设备栏应该出现您刚才选择的数据库备份文件名,备份号默认为1(如果您对同一个文件做过多次备份,可以点击备份号旁边的查看内容,在复选框中选择最新的一次备份后点确定)——>然后点击上方常规旁边的选项按钮; 5、在出现的窗口中选择在现有数据库上强制还原,以及在恢复完成状态中选择使数据库可以继续运行但无法还原其它事务日志的选项。在窗口的中间部位的将数据库文件还原为这里要按照你SQL的安装进行设置(也可以指定自己的目录),逻

Oracle数据库归档日志日常管理与建议

Oracle数据库归档日志日常管理与建议 1.简介 近日,项目组偶有发生归档日志占满归档目录空间导致数据库hang住(无响应),导致系统不能正常应用的情况。针对此类问题,笔者从Oracle数据库归档模式、归档模式的优缺点、归档日志日常管理方法等各方面浅析并整理出归档日志日常管理与建议。请各项目组依据实际情况,规范管理归档日志,排查相关隐患,以保证系统的正常高效运营。 另外,对于已开启数据库归档模式的项目组,若数据库管理权限不在我方,可将相关归档管理建议与当地运维部门充分沟通,避免归档的不当管理引起事故。 2.数据库归档模式与归档日志 2.1数据库运行模式简介 Oracle数据库包括归档模式与非归档模式两种运行模式。 一般情况下Oracle数据库的联机重做日志会记录对数据库所做的所有的修改,如创建对象;插入、删除、更新对象;删除对象等,这些操作都会记录在联机重做日志里。Oracle 数据库至少要有2个联机重做日志组。当一个联机重做日志组被写满(假设为1)的时候,就会发生日志切换,这时联机重做日志组2(假设为2)成为当前使用的日志,当联机重做日志组2写满的时候,又会发生日志切换,去写联机重做日志组1,这样反复进行。 如果数据库处于非归档模式,联机日志在切换时就会被丢弃。而在归档模式下,当发生日志切换的时候,被切换的联机日志会被归档。 如当前在使用联机重做日志1,当1被写满时,发生日志切换,开始写联机重做日志2,这时联机重做日志1的内容会被拷贝到一个指定的目录下。这个目录为归档目录,这个过程称之为归档,拷贝的文件叫归档日志。 2.2归档模式优点与归档日志作用 数据库运行在归档模式时,后台进程ARCH会将联机日志的内容拷贝到归档目录生成归档日志。 当数据库出现介质失败时,使用数据文件备份,归档日志和重做日志可以完全恢复数据库。因此,开启归档模式及归档日志的益处与作用是非常明显的: 1.可以进行完全、不完全恢复。由于对数据库所做的全部改动都记录在日志文件中, 如果发生硬盘故障等导致数据文件丢失的故障,则可以利用物理备份和归档日志 完全恢复数据库,不会丢失任何数据。 2.可以进行联机热备。所谓联机热备,就是在数据库运行状态下,对数据库进行备 份,备份时用户对数据库的使用基本不受影响(不可避免的会对性能有负面影响)。 3.可以实施Data Guard。可以部署1个或多个备用数据库,从而最大限度地提供灾 难保护手段。

SQL Server的增量备份与还原方法

SQL Server的增量备份与还原方法.txt蜜蜂整日忙碌,受到赞扬;蚊子不停奔波,人见人打。多么忙不重要,为什么忙才重要。 备份步骤: 1.在“SQL Server企业管理器”中注册数据库所在的服务器,注意要使用sa用户名和口令,否则以后执行备份调度的时候,会出现权限不足,导致不能进行备份。 2.确保该服务器的SQL Server Agent服务是开启的,因为所有的调度都是通过该代理进行 执行的。 3.在“SQL Server企业管理器”中选中Test数据库,右键打开“备份数据库”窗口,指 定一个新的文件Test-daily.bak,选择“完全”进行一次完全备份。 4.再次打开“备份数据库”窗口,这次使用“差异备份”,“重写”选项设置为“追加到媒体”,目的文件仍然是前面步骤所指定的Test-daily.bak,并在“调度”选项中设置为每天 的19:00,这样,SQL Server会在每天的19:00将数据库自上次备份以来发生的变化,以 增量备份的方式追加到Test-daily.bak文件中。(测试的时候,可以设置为每天的每1分钟 进行一次备份,以便可以很快的看到备份结果) 在需要进行数据库恢复的时候,可以按照如下还原步骤进行操作: 1.新建一个数据库,比如名为Back, 右键打开“还原数据库”窗口,选择“从设备”进行 还原,然后在“选择设备…”中选定备份所使用的Test-daily.bak文件,回到“还原数据库”窗口,“备份号”默认为1(对应的就是备份步骤3中的初次完全备份),不必更改。在“选项”标签页中,选中“强制还原”,最关键的一步是,在“恢复完成状态”中,选中第2或第 3项,即保证“能还原其它事务日志”,这样还原之后,这个新的数据库就回到了我们进行第 一次完全备份时候的状态,此时,该Back数据库将处于“正在装载”或“只读”的状态,没 有关系,这是正常的,因为我们接下来还需要通过事务日志将该数据库恢复到指定的某个状态。 2.再次打开“还原数据库”窗口,同样选择“从设备”进行还原,然后在“选择设备…”中 选定备份所使用的Test-daily.bak文件,回到“还原数据库”窗口,点击“备份号”后面 的“查看内容…”按钮,在新的窗口中,可以看到里面列出了每天19:00左右备份过的备份 集(除了最顶上一个是我们初次的完全备份集,其它都是每天的增量备份集),选中想要恢复 的某个备份集,单击“确定”回到主窗口,可以看到“还原备份集”默认选中的是“差异”,再单击确定,这样,Back数据库就恢复到了我们选定的某个备份集了。 上述还原步骤可以重复进行,直到我们找到确切需要的某个备份集。 另外,恢复后的数据库名称是Back,如果想将其改名为Test,可以执行 EXEC sp_renamedb 'Back', 'Test' 在重命名数据库之前,应该确保没有人使用该数据库,而且数据库设置为单用户模式。 2005-08-25 16:37 更新 1.需要在"备份数据库"->"常规"选项卡里选中"重写现有媒体",这样在"选项"选项卡里才能 设定"备份集到期时间",并且发现,这样设定好"到期时间"之后,即使将"重写现有媒体"改为" 追加到媒体", 所设定的"到期时间"还是有效的,这可以在调度里的"步骤"脚本中看出来,如: BACKUP DATABASE [model] TO DISK = N'D:\test.bak' WITH NOINIT , NOUNLOAD , RETAINDAYS = 1, DIFFERENTIAL , NAME = N'model 备份', NOSKIP , STATS = 10, NOFORMAT,通过这种方式应该可以实现保留最近N天的备份,测试中....

DB2_数据库日志管理

1、load 方法装入数据: export to tempfile of del select * from tablename where not 清理条件; load from tempfile of del modified by delprioritychar replace into tablename nonrecoverable; 说明: 在不相关的数据表export数据时,可以采取并发的形式,以提高效率; tablename指待清理table的名称; modified by delprioritychar防止数据库记录中存在换行符,导致数据无法装入的情况; replace into对现数据库中的内容进行替换,即将现行的数据记录清理,替换为数据文件内容; nonrecoverable无日志方式装入; 2、查找当前的应用: db2 list application grep btpdbs; 3、删除当前正在使用的application: db2 "force application (id1,id2,id3)" id1,id2,id3 是list显示的应用号; 4、查看当前应用号的执行状态: db2 get snapshot for application agentid 299 grep row 5、查看数据库参数: db2 get db cfg for //当前数据库可以省略 6、修改数据库的log数据: db2 update db cfg using <参数名> <参数值> 7、db2stop force的用法: 在进行bind的时候出现如下错误: sql0082can error has occurred which has terminated processing. sql0092nno package was created because of previous errors. sql0091nbinding was ended with "3" errors and "0" warnings. 主要是表文件被加锁,不能继续使用; 在进行stop的时候报错:db2stop 8/03/2005 21:46:530 0 sql1025nthe database manager was not stopped because databases are still active.

K3数据库日志文件过大分析及解决方案V2.0

K/3数据库日志文件过大分析及解决方案 本期概述 ●本文档适用于金蝶k/3(使用SQL Server 2000、SQL Server 2005作为数据库)。 ●本文档主要阐述了,在K3备份过程中,遇到:”日志文件过 大,系统无法完成备份”的问题分析及解决方案。通过对本文档的学习,能够掌握这种问题产生的原因以及解决方法。 版本信息 ●2009年6月10日V11.0 编写人:周素帆 ●2009年6月日V11.0 修改人:

版权信息 本文件使用须知 著作权人保留本文件的内容的解释权,并且仅将本文件内容提供给阁下个人使用。对于内容中所含的版权和其他所有权声明,您应予以尊重并在其副本中予以保留。您不得以任何方式修改、复制、公开展示、公布或分发这些内容或者以其他方式把它们用于任何公开或商业目的。任何未经授权的使用都可能构成对版权、商标和其他法律权利的侵犯。如果您不接受或违反上述约定,您使用本文件的授权将自动终止,同时您应立即销毁任何已下载或打印好的本文件内容。 著作权人对本文件内容可用性不附加任何形式的保证,也不保证本文件内容的绝对准确性和绝对完整性。本文件中介绍的产品、技术、方案和配置等仅供您参考,且它们可能会随时变更,恕不另行通知。本文件中的内容也可能已经过期,著作权人不承诺更新它们。如需得到最新的技术信息和服务,您可向当地的金蝶业务联系人和合作伙伴进行咨询。 著作权声明著作权所有2009 金蝶软件(中国)有限公司。

所有权利均予保留。

目录 第一章报错现象及分析 (5) 一、报错现象 (5) 二、问题分析 (6) 三、关于日志文件 (6) 第二章解决方案 (8) 一、SQL 2000 (8) 1、执行数据库分离附加 (8) 2、数据库收缩操作 (18) 二、SQL 2005 (24) 1、分离附加数据库 (24) 2、收缩数据库 (27)

几种清除MSSQL日志方法

方法一、 1 / 4

2 / 4 方法二、

MS SQL清除日志的命令 如何清除sql server 日志? 设置数据库为简单模式,自动收缩 1.打开查询分析器,输入命令 backup log databasename with no_log 2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M 数,直接输入这个数,确定就可以了。 dbcc shrinkfile (databasename_log,truncateonly) 方法三、 1: 删除LOG 第1步:分离数据库企业管理器->服务器->数据库->右键->分离数据库 第2步:删除LOG文件 第3布:附加数据库企业管理器->服务器->数据库->右键->附加数据库 此法生成新的LOG,大小只有500多K 再将此数据库设置自动收缩 方法四、 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' 方法五、 Use Database_Name Backup Log Database_Name With No_log dbcc shrinkfile (Database_Name_Log,truncateonly) Go 方法六、 直接在查询分析那里执行backup log databasename with no_log 然后回到企业管理器把数据库收缩一下(可能需另外设置属性) 3 / 4

sqlserver日志已满处理方法

sql server日志已满处理方法 sql server日志已满处理方法学习2009-07-2615:42:33阅读323评论0字号:大中小 SQL数据库日志文件太大,或者使用软件时提示日志已满的处理方法. sql出现这种题提示,有二种情况,一你的电脑存放数据库文件的盘符不是NTFS格式的,而是别的格式,如FAT32只支持一个文件最大4G,所以超过4G就没有办法再写文件,sql 就会提示日志文件已满. 另外就是NTFS格式的,前台见一个卖服装的朋友店里数据库主文件只有100多M,而日志文件却有40G,幸亏是他的硬盘空间多,不然软件早不能用了 .估计软件数据库设计的有问题.后来给他重新建了一个日志收银速度明显加快. 一 --在SQL查询分析器执行 --按下边的步骤一步一步的做 --删除日志前要先对以前的数据库进行备份(这一步必须做,已免数据出现丢失) --1、使数据库脱机 use master exec sp_Detach_db test,true --2、把对应的.ldf文件删除或改名 --需手工做自己手工删除数据库文件的所在目录下的.ldf文件 --3、加载数据文件 exec sp_attach_single_file_db test,'D:\Program Files\Microsoft SQL Server\MSSQL\Data\test_Data.MDF' --4设置日志文件的增长方式

alter database test set recovery simple 二 1.清空日志 DUMP TRANSACTION库名WITH NO_LOG 2.截断事务日志: BACKUP LOG数据库名WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDATABASE(客户资料) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select*from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql7.0,这步只能在查询分析器中进行) a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库

DB2报“数据库日志已满”问题解决

DB2报“数据库日志已满”问题解决 用控制中心直接改会比较容易一点,在数据库名称上点右键-->配置-->日志-->日志文件大小、主日志文件数、辅助日志文件数改大一点。 也可用命令行db2cmd db2 update db cfg for mymakro using LOGFILSIZ 512 --日志文件大小 db2 update db cfg for mymakro using LOGPRIMARY 20 --主日志 db2 update db cfg for mymakro using LOGSECOND5 10 --辅助日志 要将与此数据库的所有连接断开后才会生效。 执行批处理时,DB2 报数据库的事务日志已满的错误,解决办法 辅助日志文件的数目(LOGSECOND) = 25 已更改的至日志文件的路径(NEWLOGPATH) = 日志文件路径= D:\DB2\NODE0000\SQL00 003\SQLOGDIR\ 溢出日志路径(OVERFLOWLOGPATH) = 镜像日志路径(MIRRORLOGPATH) = 首个活动日志文件= S0000005.LOG 磁盘上已满的块日志(BLK_LOG_DSK_FUL) = NO 事务使用的最大活动日志空间的百分比(MAX_LOG) = 0 1 个活动UOW 的活动日志文件的数目(NUM_LOG_SPAN) = 0 组落实计数(MINCOMMIT) = 1 软检查点前回收的日志文件的百分比(SOFTMAX) = 100 启用的恢复的日志保留(LOGRETAIN) = RECOVERY 启用的日志记录的用户出口(USEREXIT) = OFF HADR 数据库角色= STANDARD HADR 本地主机名(HADR_LOCAL_HOST) = HADR 本地服务名称(HADR_LOCAL_SVC) = HADR 远程主机名(HADR_REMOTE_HOST) = HADR 远程服务名称(HADR_REMOTE_SVC) =

SQL SERVER数据库备份与恢复方案

SQL SERVER数据库备份与恢复方 案 世界上没有万无一失的信息安全措施。信息世界“攻击和反攻击”也永无止境。对信息的攻击和防护好似矛与盾的关系,螺旋式地向前发展。在信息的收集、处理、存储、传输和分发中经常会存在一些新的问题,其中最值得我们关注的就是系统失效、数据丢失或遭到破坏。 威胁数据的安全,造成系统失效的主要原因有以下几个方面:硬盘驱动器损坏;人为错误;黑客攻击;病毒;自然灾害;电源浪涌;磁干扰。因此,数据备份与数据恢复是保护数据的最后手段,也是防止主动型信息攻击的最后一道防线。 只要发生数据传输、数据存储和数据交换,就有可能产生数据故障。这时,如果没有采取数据备份和数据恢复手段与措施,就会导致数据的丢失。有时造成的损失是无法弥补与估量的。 数据故障的形式是多种多样的。通常,数据故障可划分为系统故障、事务故障和介质故障三大类。从信息安全数据库备份与恢复方案的角度出,实际上第三方或敌方的“信息攻击”,也会产生不同种类的数据故障。例如:计算机病毒型、特洛伊木马型、“黑客”入侵型、逻辑炸弹型等。这些故障将会造成的后果有:数据丢失、数据被修改、增加无用数据及系统瘫痪等。作为系统管理员,要千方百计地维护系统和数据的完整性与准确性。

通常采取的措施有:安装防火墙,防止“黑客”入侵;安装防病毒软件,采取存取控制措施;选用高可靠性的软件产品;增强计算机网络的安全性。 以下主要介绍SQL SERVER数据备份方案和数据库恢复方案。SQL SERVER数据备份方案 SQL SERVER数据库的备份方法主要有完整备份,差异备份,事务日志备份等。根据数据安全性的要求,推荐的备份方式为每周一次完整备份,每天一次差异备份,每半个小时一次事务日志备份。 默认情况下,为sysadmin 固定服务器角色以及db_owner 和db_backupoperator 固定数据库角色的成员授予BACKUP DATABASE 和BACKUP LOG 权限。 备份设备的物理文件的所有权和权限问题可能会妨碍备份操作。SQL Server 必须能够读取和写入设备;运行SQL Server 服务的帐户必须具有写入权限。 备份文件存放磁盘需要与数据库文件存放磁盘分开,避免磁盘IO冲突。备份执行时间与数据库作业执行时间错开,避免备份影响数据库作业的执行。 SQL SERVER 维护计划功能可以较好的实现自动化备份,在使用该功能前启动数据库管理器上的SQL SERVER 代理功能。

清除数据库日志

清除数据库日志方法 方法一、(注意,此方法必须数据库文件所在的磁盘分区剩余空间足够,不少于1.5G,,如没有达到此项要求,请使用第二种方法) 1.断开后台服务器的网络连接(最好是晚上歇业后)退出系统 2.打开SQL的企业管理器(开始程序Microsoft SQL Server 企业管理器) 3.选中当前所使用的数据库(假设数据库名为kmjxc_pro)右键所有任务,分离数据库,将 数据库分离如下图 步骤一: 步骤二

1.进入SQL数据库安装目录(假设安装在D盘)D:\Program Files\Microsoft SQL Server\MSSQL\Data,找到两个文件kmjxc_pro_Data.MDF和kmjxc_pro_Log.LDF,将kmjxc_pro_Log.LDF改为1kmjxc_pro_Log.LDF,kmjxc_pro_Data.MDF不动 2.附加数据如图示,选中D:\Program Files\Microsoft SQL Server\MSSQL\Data中的kmjxc_pro_Data.MDF 步骤三:

步骤五: 点确定后,系统将提示数据附加成功附加数据成功后,日志文件将被缩减有问题打电话

1. 打开SQL 的查询分析器,选择一个带机器名的服务名 2. 输入安装时的超级管理员密码,点“确定”进入查询分析器主界面 3. 在编辑窗口中输入如下语句 use master dump tran kmjxc with no_log DBCC SHRINKDATABASE (kmjxc, 10) go use kmjxc dump tran master with no_log go 选择带机器名的服务名

MSSQL2000中没有日志文件的数据库恢复方法

MSSQL2000 中没有日志文件的数据库恢复方法 由于种种原因, 我们如果当时仅仅备份了 mdf 文件,那么恢复起来就是一件 很麻烦的事情了。 如果您的 mdf 文件是当前数据库产生的,那么很侥幸,也许你使用 sp_attach_db 或者 sp_attach_single_file_db 可以恢复数据库,但是会出现类 似下面的提示信息 ########################################################## 设备激活错误。 物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。 已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。 ########################################################## 但是,如果您的数据库文件是从其他计算机上复制过来的,那么很不幸,也 许上述办法就行不通了。你也许会得到类似下面的错误信息 ########################################################## 服务器: 消息 1813,级别 16,状态 2,行 1 未能打开新数据库 'test'。CREATE DATABASE 将终止。 设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。 ########################################################## 当出现以上问题时,恢复的办法如下: A.我们使用默认方式建立一个供恢复使用的数据库(数据库名应该与要恢复 的数据库相同,如 test)。可以在 SQL Server Enterprise Manager 里面建立。 B.停掉数据库服务器。 C.将刚才生成的数据库的日志文件 test_log.ldf 删除,用要恢复的数据库 mdf 文件覆盖刚才生成的数据库数据文件 test_data.mdf。 D.启动数据库服务器。此时会看到数据库 test 的状态为“置疑”。这时候 不能对此数据库进行任何操作。 E.设置数据库允许直接操作系统表。此操 作可以在 SQL Server Enterprise Manager 里面选择数据库服务器,按右键,选 择“属性”, 在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。 也可以使用如下语句来实现。

数据库日志满的删除方法

解决SQL数据库日志已满的问题 2009年03月21日星期六上午 11:53 一、简单方法 1、右键数据库→属性→选项→故障还原模型→设为简单→确定; 2、右键数据库→所有任务→收缩数据库→确定; 3、右键数据库→属性→选项→故障还原模型→设为大容量日志记录→确定。 二、复杂方法 1、清空日志 DUMP TRANSACTION 库名WITH NO_LOG 2、截断事务日志 BACKUP LOG 数据库名WITH NO_LOG 3、收缩数据库文件(如果不压缩,数据库的文件不会减小) 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至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.分离 EXEC sp_detach_db @dbname = 'pubs' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = 'pubs',@physname = 'c:\Program Files\Microsoft SQL

附加数据库缺失日志

参考恢复方法: 1、停止数据库服务。 2、将需要恢复的数据库文件复制到另外的位置。 3、启动数据库服务。 4、确认要恢复的数据库文件已经成功复制到另外的位置,然后在SQL Server Management Studio中删除要恢复的数据库。 5、新建同名的数据库(数据库文件名也要相同)。 6、停止数据库服务。 7、用第2步中备份的.mdf文件覆盖新数据库的同名文件。 8、启动数据库服务。 9、运行alter database AIS20180828035121 set emergency,将数据库设置为emergency mode --2.设置为单用户模式 alter databaseAIS20180828035121 set single_user --3.检查并重建日志文件 dbcc checkdb('AIS20180828035121',REPAIR_ALLOW_DATA_LOSS) --4.第步操作如果有错误提示,运行第步,没有错误则跳过 dbcc checkdb('AIS20180828035121',REPAIR_REBUILD) --5.恢复成多用户模式 alter database AIS20180828035121 set multi_user 10、运行下面的命令就可以恢复数据库: use master declare @databasename varchar(255) set @databasename='你的数据库名' exec sp_dboption @databasename, N'single', N'true'--将目标数据库置为单用户状态dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD) exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态 ---------------------------------------------------------------------------------------------------------- 如果你一切都顺得的话就如上的步骤就可以成功了,下面我们将对特殊的状态进行分析 ---------------------------------------------------------------------------------------------------------- 1、一个或多个文件与数据库的主文件不匹配。如果是尝试附加数据库,请使用正确的文件重试该操作。如果这是现有数据库,则文件可能已损坏,应该从备份进行还原。 日志文件 'E:/Program Files/Microsoft SQL Server 2005/MSSQL.1/MSSQL/DATA/dnt2_db_log.ldf' 与主文件不匹配。该文件可能来自另一数据库,或者可能以前重新生成了日志。

SQL SERVER 日志已满的处理方法

SQL SERVER 日志已满的处理方法(转) 事务日志文件Transaction Log File是用来记录数据库更新情况的文件,扩展名为ldf。在SQL Server 7.0 和SQL Server 2000 中,如果设置了自动增长功能,事务日志文件将会自动扩展。 一般情况下,在能够容纳两次事务日志截断之间发生的最大数量的事务时,事务日志的大小是稳定的,事务日志截断由检查点或者事务日志备份触发。 然而,在某些情况下,事务日志可能会变得非常大,以致用尽空间或变满。通常,在事务日志文件占尽可用磁盘空间且不能再扩展时,您将收到如下错误消息: Error:9002, Severity:17, State:2 The log file for database ?%.*ls? is full. 除了出现此错误消息之外,SQL Server 还可能因为缺少事务日志扩展空间而将数据库标记为SUSPECT。有关如何从此情形中恢复的其他信息,请参见SQL Server 联机帮助中的“磁盘空间不足”主题。 另外,事务日志扩展可能导致下列情形: ·非常大的事务日志文件。 ·事务可能会失败并可能开始回滚。 ·事务可能会用很长时间才能完成。 ·可能发生性能问题。 ·可能发生阻塞现象。 原因 事务日志扩展可能由于以下原因或情形而发生: ·未提交的事务 ·非常大的事务 ·操作:DBCC DBREINDEX 和CREATE INDEX ·在从事务日志备份还原时 ·客户端应用程序不处理所有结果 ·查询在事务日志完成扩展之前超时,您收到假的“Log Full”错误消息 ·未复制的事务 解决方法 日志文件满而造成SQL数据库无法写入文件时,可用两种方法: 一种方法:清空日志。 1.打开查询分析器,输入命令 DUMP TRANSACTION 数据库名WITH NO_LOG 2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。 另一种方法有一定的风险性,因为SQL SERVER的日志文件不是即时写入数据库主文件的,如处理不当,会造成数据的损失。 1: 删除LOG 分离数据库企业管理器->服务器->数据库->右键->分离数据库

mysql数据库备份与恢复

my sql数据库备份与恢复 windows下实现mysql数据库定时备份功能一、进入mysql的bin目录 二、导出: [mysql bin path]>mysqldump--opt-d-u root-p dbn> backup-file.sql Enter password:****** 三、导入: [mysql bin path]>mysql-u root-p dbn<backup-file.sql Enter password:****** 四、收尾工作:清理sql文件,导出时会在bin目录下生成backup-file.sql 文件,在导入工作完成后就没用了,可以删了,当然留着也可以。

我自己的用的备份语句: d: cd\mysql\mysql5.1.30\bin mysqldump--opt-uroot-p123456 bbs_sikaozhoubao_com>E:\backup\bbs_sikaozhoubao_com\%date:~ 0,4%%date:~5,2%%date:~8,2%%time:~0,2%%time:~3,2%%time:~6,2%.sq l 更多的说明: 导出要用到MySQL的mysqldump工具,基本用法是: shell>mysqldump[OPTIONS]database[tables] 如果你不给定任何表,整个数据库将被导出。 通过执行mysqldump--help,你能得到你mysqldump的版本支持

的选项表。 注意,mysqldump没有--quick或--opt选项,mysqldump将在导出结果前装载整个结果集到内存中,如果你正在导出一个大的数据库,这将可能是一个问题。 mysqldump支持下列选项: --add-locks 在每个表导出之前增加LOCK TABLES并且之后UNLOCK TABLE。(为了使得更快地插入到MySQL)。 --add-drop-table 在每个create语句之前增加一个drop table。

数据库的事务日志已满

数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ,请参阅sys.databases 中的log_reuse_wait_desc 列 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. 1、清空日志 DBCC SHRINKFILE(库名_log,0) DUMP TRANSACTION 库名WITH NO_LOG 2、截断事务日志: 如果出现“未能在sysfiles 中找到文件库名_log'。 DBCC 执行完毕。如果DBCC 输出了错误信息,请与系统管理员联系。” 则使用这句SQL操作 BACKUP LOG 库名WITH NO_LOG DBCC SHRINKFILE(2,0) 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 a、选择日志文件--收缩文件至,这里会给出一个允许收缩到的最小M数,确定就可以了 b、选择数据文件--收缩文件至,这里会给出一个允许收缩到的最小M数,,确定就可以了也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDA TABASE(库名) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)

a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG,大小只有500多K 或用代码: 下面的示例分离pubs,然后将pubs 中的一个文件附加到当前服务器。a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩,做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '库名','autoshrink','TRUE' 6.如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 库名modify file(name=逻辑文件名,maxsize=20)

相关文档
最新文档