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) =
远程服务器的HADR 实例名(HADR_REMOTE_INST) =
HADR 超时值(HADR_TIMEOUT) = 120
HADR 日志写同步方式(HADR_SYNCMODE) = NEARSYNC
第一个日志归档方法(LOGARCHMETH1) = LOGRETAIN logarchmeth1 的选项(LOGARCHOPT1) =
第二个日志归档方法(LOGARCHMETH2) = OFF
logarchmeth2 的选项(LOGARCHOPT2) =
故障转移日志归档路径(FAILARCHPATH) =
错误时重试日志归档次数(NUMARCHRETRY) = 5
日志归档重试延迟（秒）(ARCHRETRYDELAY) = 20
供应商选项(VENDOROPT) =
启用的自动重新启动(AUTORESTART) = ON
索引重新创建时间和重做索引构建(INDEXREC) = SYSTEM (RESTART) 在索引构建期间记录页(LOGINDEXBUILD) = OFF
loadrec 会话的缺省数目(DFT_LOADREC_SES) = 1
要保留的数据库备份的数目(NUM_DB_BACKUPS) = 12
恢复历史保留时间（天数）(REC_HIS_RETENTN) = 366
TSM 管理类(TSM_MGMTCLASS) =
TSM 节点名(TSM_NODENAME) =
TSM 所有者(TSM_OWNER) =
TSM 密码(TSM_PASSWORD) =
自动维护(AUTO_MAINT) = OFF
自动数据库备份(AUTO_DB_BACKUP) = OFF
自动表维护(AUTO_TBL_MAINT) = OFF
自动runstats (AUTO_RUNSTATS) = OFF
自动统计信息概要分析(AUTO_STATS_PROF) = OFF
自动概要文件更新(AUTO_PROF_UPD) = OFF
自动重组(AUTO_REORG) = OFF
db2 => quit
DB20000I QUIT 命令成功完成。
C:\>db2 connect to testdatabase
数据库连接信息
数据库服务器= DB2/NT 8.2.4
SQL 授权标识= ADMINIST...
本地数据库别名= TESTDATABASE
connect to testdatabase
数据库连接信息
数据库服务器= DB2/NT 8.2.4
SQL 授权标识= ADMINIST...
本地数据库别名= TESTDATABASE
update db cfg for testdatabase using logfilsiz 6000
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 为立即修改而提交的一个或多个参数未动态更改。对于这些配置参数，必须在所有应用程序都与此数据库断开连接之后，更改才会生效。
update db cfg for testdatabase using logprimary 4
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 为立即修改而提交的一个或多个参数未动态更改。对于这些配置参数，必须在所有应用程序都与此数据库断开连接之后，更改才会生效。
update db cfg for testdatabase using logsecond 25
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
C:\>db2 ? sql964 (根据错误码查看错误解释)
SQL0964C数据库的事务日志已满。
解释:
已使用事务日志中的所有空间。
若使用具有辅助日志文件的循环日志，则尝试分配和使用这些日志。当文件
系统没有更多空间时，不能使用辅助日志。
若使用归档日志，则文件系统不提供空间来包含新日志文件。
不能处理该语句。
用户响应:
在接收到此消息(SQLCODE) 时，执行COMMIT 或
ROLLBACK，或重试该操作。
若并发应用程序正在更新数据库，则重试该操作。当另一个应用程序完成事务时，可能释放日志空间。
发出更频繁的落实操作。若事务还未落实，则当落实事务时，可能会释放日志空间。设计应用程序时，应考虑何时落实已更新的事务，以防止日志已满的情况。
若发生死锁，则更频繁地检查它们。这可以通过减小数据库配置参数DLCHKTIME 来实现。这将检测到死锁，并且很快解决（通过ROLLBACK），这将释放日志空间。
若经常发生这种情况，则增大数据库配置参数以允许更大的日志文件。更大的日志文件需要更多空间，但是减少了应用程序重试该操作的需要。
若正在安装样本数据库，则删除它并再次安装样本数据库。
sqlcode : -964
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)
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个或多个备用数据库，从而最大限度地提供灾 难保护手段。
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) =
清除数据库日志
清除数据库日志方法 方法一、(注意，此方法必须数据库文件所在的磁盘分区剩余空间足够，不少于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 分离数据库企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
数据库的事务日志已满
数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ，请参阅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)
统计数据库和日志每天的大小和增加量
CREATE TABLE[dbo].[db_size]( Id int identity, [vtime][datetime]NULL, [database_size][nvarchar](50)NULL, [database_sizeZ][nvarchar](50)NULL, [database_sizeB][nvarchar](50)NULL, [free_size][nvarchar](50)NULL, [free_sizeZ][nvarchar](50)NULL, [free_sizeB][nvarchar](50)NULL ) GO CREATE PROCEDURE[dbo].[get_db_size] AS BEGIN SET NOCOUNT ON; declare @pages bigint ,@dbsize bigint ,@logsize bigint ,@reservedpages bigint ,@usedpages bigint ,@dbsizePre decimal(18,4) ,@logsizePre decimal(18,4) ,@dbsizeB decimal(18,4) ,@logsizeB decimal(18,4) ,@dbsizeZ decimal(18,4) ,@logsizeZ decimal(18,4) ,@dbsizeBF decimal(18,4) ,@logsizeBF decimal(18,4) select@dbsize=sum(convert(bigint,case when status&64 =0 then size else 0 end)) ,@logsize=sum(convert(bigint,case when status&64 <>0 then size else 0 end)) from dbo.sysfiles select@reservedpages=sum(a.total_pages), @usedpages=sum(https://www.360docs.net/doc/163482788.html,ed_pages), @pages=sum( CASE
Sybase12日志满的解决办法2
Sybase12.5日志满问题的解决 日志满分为两种情况：1.非master(用户库或者其他系统库sybsystemprocs)库的日志满，导致用户库不能访问；2.系统库master日志满，导致服务都不能正常启动。针对以上情况要分别对待处理。 1.非master库日志满的处理： 重庆数据库后台sybsystemprocs库日志报满：09:00000:01631:2011/11/13 06:45:36.16 server Error: 3475, Severity: 21, State: 7 09:00000:01631:2011/11/13 06:45:36.16 server There is no space available in SYSLOGS to log a record for which space has been reserved. This process will retry at intervals of one minute. 11:00000:04104:2011/11/13 06:20:11.87 server Space available in the log segment has fallen critically low in database 'sybsystemprocs'. All future modifications to this database will be suspended until the log is successfully dumped and space becomes available. 00:00000:02407:2011/11/13 06:20:11.89 server Error: 2812, Severity: 16, State: 5 00:00000:02407:2011/11/13 06:20:11.89 server Stored procedure 'sp_thresholdaction' not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output). 或某个用户库etoh2_cq的日志空间满报： 00:00000:00001:2008/12/02 17:28:07.38 server
00:00000:00001:2008/12/02 17:28:07.38 server
00:00000:00001:2008/12/02 17:28:07.38 server
00:00000:00001:2008/12/02 17:28:07.38 server
SYBASE数据库日志详解
SYBASE数据库日志详解 开发者在线 https://www.360docs.net/doc/163482788.html,更新时间:2007-09-13作者：https://www.360docs.net/doc/163482788.html, 来 源:https://www.360docs.net/doc/163482788.html, 本文关键词：Sybase数据库日志 我们知道，SYBASE SQL Server用事务（Transaction）来跟踪所有数据库的变化。事务是SQL Server 的工作单元。一个事务包含一条或多条作为整体执行的 T-SQL语句。每个数据库都有自己的事务日志（Transaction Log），即系统表（Syslogs）。事务日志自动记录每个用户发出的每个事务。日志对于数据库的数据安全性、完整性至关重要，我们进行数据库开发和维护必须熟知日志的相关知识。 一、SYBASE SQL Server 如何记录和读取日志信息 SYBASE SQL Server是先记Log的机制。每当用户执行将修改数据库的语句时，SQL Server就会自动地把变化写入日志。一条语句所产生的所有变化都被记录到日志后，它们就被写到数据页在缓冲区的拷贝里。该数据页保存在缓冲区中，直到别的数据页需要该内存时，该数据页才被写到磁盘上。若事务中的某条语句没能完成，SQL Server将回滚事务产生的所有变化。这样就保证了整个数据库系统的一致性和完整性。 二、日志设备 Log和数据库的Data一样，需要存放在数据库设备上，可以将Log和Data存放在同一设备上，也可以分开存放。一般来说，应该将一个数据库的Data和Log存放在不同的数据库设备上。这样做有如下好处：一是可以单独地备份 Backup 事务日志；二是防止数据库溢满；三是可以看到Log的空间使用情况。 所建Log设备的大小，没有十分精确的方法来确定。一般来说，对于新建的数据库，Log的大小应为数据库大小的30%左右。Log的大小还取决于数据库修改的频繁程度。如果数据库修改频繁，则Log 的增长十分迅速。所以说Log 空间大小依赖于用户是如何使用数据库的。此外，还有其它因素影响Log大小，我们应该根据实际操作情况估计Log大小，并间隔一段时间就对Log进行备份和清除。 三、日志的清除 随着数据库的使用，数据库的Log是不断增长的，必须在它占满空间之前将它们清除掉。清除Log 有两种方法： 1.自动清除法 开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log 而不做备份。