❶ sql server需要做日志备份吗
请按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的数据库.
一般不建议做第4,6两步
第4步不安全,有可能损坏数据库或丢失数据
第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复.
--*/
--下面的所有库名都指你要处理的数据库的库名
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 = '库名'
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)
❷ 如何快速掌握SQL Server中的日志转移
如何快速掌握SQL Server中的日志转移
集群是一种实现高可用性的有效解决方案，有时它会适得其反。而且，它还非常昂贵。因此，数据库管理员可使用日志转移代替集群来提供较高的可用性。
日志转移是这样一种处理过程，它能将某一数据库中的事务日志文件依次转存到备份的数据库中，进而为这一数据库创建一个“近乎”热备份。SQL Server 2000的数据库引擎中设置了日志转移功能，并在其中进行处理。所以它会自动完成复原到备份服务器的进程，而不需要数据库管理员手动操作。只有你的产品服务器操作失败，你才需手动完成到备份服务器的复原进程。(注释：尽管SQL Server 7.0和2005中均有日志转移功能，但本文主要针对SQL Server 2000。)
为什么要使用日志转移?
日志转移是一种解决高可用性的措施，并且十分有效。同样作为高可用性的措施方案，日志转移相对集群来说，最大的.好处是它要便宜许多。这是因为，使用集群功能有硬件要求，而日志转移则不需要。
日志转移在数据库与数据库而非服务器与服务器之间进行;因此才有可能将备份数据库存储在你已用作其他用途的服务器上。但如果转移失败则有可能会出现问题，这时你可换用备份数据库，这种选择是可用的。
日志转移相对比较容易安装。SQL Server提供了非常完善的向导帮助你安装这个进程。
日志转移允许你保存分布在不同地理位置中的冗余数据，SQL Server的集群功能则很难做到这一点。这一特点十分出众，因为，当你的数据中心遭到灾难时，你仍能在备份服务器中将其恢复过来。而在相同的数据中心，如果你使用的是集群功能，你就会陷入麻烦。
日志转移的另一优点是你能将备份数据库作为报告数据库使用，这对许多公司来说是很不错的选择。但如果你决定了用这个备份数据库作报告使用，就必须注意它的局限性。使用原始数据库中的日志时，SQL Server 要求指定唯一的通道，所以，当日志文件正在被应用时，报告则不能同时进行。
使用日志转移要考虑的相关因素
在将日志转移作为高可用性的方案来使用时，我们必须考虑以下几点因素。由于从原始数据库到备份数据库有一个潜伏期，对你的公司而言，它并非一定是可行的实现高可用性的一种解决方案。潜伏期由数据库管理员设置，时间也因需要而缩短, 但永远不能避免。
日志转移中没有设置恢复功能，这就意味着在将日志转移到备份服务器上时，这些日志都暂时不可用。因此，数据库管理员必须在将备份数据库放到网上前完成一系列的操作，这些步骤包括:
将已存储在备份数据服务器上原始数据库里的备份标签存储起来。一旦所有的标签被存储后，数据库就必须得到恢复，然后放到网上。
一旦所有的数据库都已放在网上，所有需要访问数据库的应用程序就需要改变自身的链接。如果你不能将应用程序尽快指向刚刚恢复的数据库，你就前功尽弃了。
一个SQL Server的实例能用于监控日志转移。这个实例可以在原始数据库、备份数据库或单独的数据库中。任何一种版本的SQL Server都能用于SQL Server监控。
注释：数据库登录必须在原始数据库与备份数据库之间同时进行。
;❸ MS SQL SERVER 如何做日志备份和还原。
备份一个事务日志：
BACKUP LOG { database_name | @database_name_var }
{
TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
[ [ ,] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
}
还原事务日志：
RESTORE LOG { database_name | @database_name_var }
[ FROM < backup_device > [ ,...n ] ]
[ WITH
[ RESTRICTED_USER ]
[ [ , ] FILE = { file_number | @file_number } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ]
[ ,...n ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] KEEP_REPLICATION ]
[ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [= percentage ] ]
[ [ , ] STOPAT = { date_time | @date_time_var }
| [ , ] STOPATMARK = 'mark_name' [ AFTER datetime ]
| [ , ] STOPBEFOREMARK = 'mark_name' [ AFTER datetime ]
]
]
例如：restore log dbname from disk='filename'
❹ sql server 2014日志备份怎样恢复
NORECOVERY
指定不发生回滚。
从而使前滚按顺序在下一条语句中继续进行。
在这种情况下，还原顺序可还原其他备份，并执行前滚。
RECOVERY（默认值）表示，应在完成当前备份前滚之后执行回滚。
恢复数据库要求要还原的整个数据集（“前滚集”）必须与数据库一致。
如果前滚集尚未前滚到与数据库保持一致的地步，并且指定了
RECOVERY，则数据库引擎将发出错误。
也就是说，你还原一个文件后，后续还有文件要还原，就要使用NORECOVERY，如果后续没有文件，或是你不想还原后续的文件，就使用recovery。
如果你要还原事务日志，首先你要有一个完整备份，先还原完整备份，并使用NORECOVERY选项，然后，按顺序还原日志备份。只要后续还有文件要还原，就使用NORECOVERY选项，如果后续没有文件或是不想再还原其他文件了，就使用RECOVERY选项。使用RECOVERY选项后，还原过程就完成了，数据库就可以使用了。
❺ sql2008怎么备份日志文件
一、 结尾日志备份的含义。
由于结尾日志备份是SQLServer数据库特有的一个内容。所以对于从其他数据库转型过来的管理员可能并不了解这个结尾日志备份的含义。在大多数情况下，如在完成恢复模式或者大容量日志恢复模式下，SQLServer数据库要求管理员备份事务日志的结尾部分以获得尚未备份的日志记录。这个在还原操作之前对日志尾部执行的日志备份就叫做结尾日志备份。对于SQLServer数据库来说，在事务日志恢复之前进行事务日志的尾部备份是非常必要的。因为结尾日志备份作业可以防止用户修改数据的丢失并最终确保日志链的完整性。在利用事务日志将数据库恢复到某一个指定的点，如数据库故障点的时候，结尾日志备份是恢复计划中的最后一个相关备份。如果在还原之前无法备份日志的尾部，那么就只能够将数据库恢复为故障发生之前创建的最后一个备份。而不能够恢复到故障发生的那一点。所以说，结尾日志备份对于SQLServer数据库非常的重要。
二、 在何时该进行结尾日志备份?
从结尾日志备份的含义中，我们也可以看出，并不是在任何情况下都需要作结尾日志备份。也就是说，对于SQLServer数据库来说，并非所有的还原方案都需要执行结尾日志部分。如在数据库恢复的时候，不需要恢复到故障的那一点，就不需要进行结尾日志备份。同理，如果先前的日志备份中已经包含了恢复点，或者说管理员准备覆盖某个数据库或者移动数据库的时候，往往不需要进行结尾日志备份。另外需要的是，在某些特定情况下即使数据库管理员想进行事务日志尾部备份都不行。如当事务日志文件已经损坏时就无法继续进行事务日志尾部备份。此时虽然数据库管理员任人可以在不使用结尾日志备份的情况下恢复数据库，但是已经不能够恢复到故障发生的那一点。也就是说，最新日志备份后进行的任何数据修改工作与数据库结构调整工作都回丢失。
具体的来说，如果遇到如下两种情况，需要先对马上对事务日志进行尾部备份。
一是需要对数据库进行还原操作，而且是要还原到最近到的一个点时，那么需要先对数据库进行事务日志尾部备份。即在数据库处于联机状态时，如果数据库管理员需要对数据库进行的下一个操走就是还原操作，那么就需要在还原操作之前进行事务日志尾部备份。也就是说，在还原操作之前才能够进行事务日志尾部备份，即在事务日志备份备份与数据库还原之间不能够再进行任何的数据库修改作业。否则的话在还原后这个修改会丢失。另外需要注意的是，为了出现一些不必要的错误，最好在备份事务尾部日志的时候，采用NORECOVERY选项。这个选项主要是为了确保数据库事务日志尾部备份之后数据库不能够再被修改。也就是说，可以保证事务日志尾部备份到数据库还原中间的时间间隔之内，不再发生任何的数据库更改作业。以确保在利用事务日志尾部备份进行数据库还原的时候，能够还原到一个最近的时点。而不会有任何数据的丢失。这是在最正常的情况下对事务日志的尾部进行备份。
❻ sql server 2000 日志备份
日志处理方法:
/*--特别注意
请按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的数据库.
一般不建议做第4,6两步
第4步不安全,有可能损坏数据库或丢失数据
第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复.
--*/
--下面的所有库名都指你要处理的数据库的库名
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 = '库名'
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)