当前位置:首页 » 数据仓库 » sql数据库日志备份
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

sql数据库日志备份

发布时间: 2023-06-28 12:45:29

sqlServer2008数据库怎样备份还原和数据恢复

在完整恢复模式或大容量日志恢复模式下,必须先备份活动事务日志(称为日志尾部),然后才能在SQLServerManagementStudio中还原数据库。有关详细信息,请参阅如何备份事务日志(SQLServerManagementStudio)。若要还原已加密的数据库,您必须有权访问用于加密数据库的证书或非对称密钥。如果没有证书或非对称密钥,数据库将无法还原。

认识数据库备份和事务日志备份

数据库备份与日志备份是数据库维护的日常工作,备份的目的是在于当数据库出现故障或者遭到破坏时可以根据备份的数据库及事务日志文件还原到最近的时间点将损失降到最低点。

数据库备份

数据库备份可以手动备份和语句备份

一.手动备份数据库

1.鼠标右键选择你要进行备份的数据库-任务-备份

可以在常规选项页面你可以选择备份类型是进行完整数据库备份还是差异数据库备份

2.点击添加选项,选择数据库文件的存放路径

注意文件名记得加后缀.bak,便于恢复时的查找

3.你还可以在选项页面是追加到现有的备份集,还是覆盖所有的现有备份集,还可以选择备份验证完整性(建议选择),还可以选择是否压缩备份等。

二.语句备份数据库

use master goBACKUP DATABASE [test] TO DISK = N'D:Microsoft sql serverMSSQL10.MSSQLSERVERMSSQLBackup est.bak' WITH NOFORMAT, NOINIT, NAME = N'test-完整 数据库 备份', SKIP, NOREWIND, NOUNLOAD, STATS = 10GO

数据库日志备份

首先需要注意,数据库日志的备份是基于数据库完整备份,也就是说你备份数据库日志之前你首先要先对数据库进行一次完整的备份,因为之间会涉及到坚持到检查点 lsn, 这也是本文接下来要讲的重点。

一.手动备份数据库日志

1.右键数据库-任务-备份-选择备份类型(事务日志)

2.点添加,添加日志文件备份存储路径

3.同数据库完整备份一样,你也可以选择覆盖现有备份集或者追加到现有备份集,这里现在覆盖现有备份集、验证完整性,然后确认备份

二.语句备份数据库事务日志

BACKUP LOG [test] TO DISK = N'D: est.trn' WITH NOFORMAT, INIT, NAME = N'test-事务日志 备份', SKIP, NOREWIND, NOUNLOAD, STATS = 10GO

数据库还原

右键数据库-还原数据库-添加需要进行还原的数据库文件路径

在还原源选项中你可以选择‘源数据库’,‘源设备’。1.选择源数据库工具会自动显示该数据库之前的一些备份,然后直接选择需要还原的数据库备份集。

2.选择源设备点击后面的...,添加需要还原的数据库文件

2.点击确认还原数据库

数据库恢复

数据库恢复的前提是1.一个完整的数据库备份2.包含这个完整数据库备份的事务日志备份3.完整备份之间也可以存在数个差异备份

对于数据库维护空间始终是一个比较头疼的问题,特别是对于大型数据库而言,每天的日志文件增长是庞大的,很多数据库管理员会定时对数据库日志文件进行收缩,但是经常收缩会存在收缩完日志文件还是不能减少,这是因为存在很多活动的日志无法收缩可以用

DBCC LOGINFO('数据库名称')

我们看到
status=0的日志,代表已经备份到磁盘的日志文件;而
status=2的日志还没有备份。当我们收缩日志文件时,收缩掉的空
间其实就是
status=0的空间,如果日志物理文件无法减小,这里一
定能看到非常多status=2的记录

解决办法:1.可以分离要收缩的数据库,然后手动删除日志文件,然后附加数据库,数据库就会产生一个很小的日志文件(不推荐使用这种方法)

2.右键要出来的数据库选择“属性”-"选项",将恢复模式改成"简单",然后利用收缩工具可以讲日志文件收缩到很小,收缩完记得讲恢复模式改成"完整"

也可以用语句进行处理(dbname是你要进行收缩的数据库名,dbname_log是你要进行收缩的数据库的逻辑日志名称)

USE [master]
GO ALTER DATABASE [dbname] SET recovery SIMPLE WITH NO_WAIT GO
ALTER DATABASE [dbname] SET RECOVERY SIMPLE --简单模式
GO
USE [dbname]
GO
DBCC SHRINKFILE (N'dbname_log' , 11, TRUNCATEONLY) GO
USE [master]
GO
ALTER DATABASE [dbname] SET RECOVERY FULL WITH NO_WAIT ALTER DATABASE [dbname] SET RECOVERY FULL

对于第一种方法不赞同使用,首先对于数据库的分离与附加有时候会破坏数据库,造成数据库无法还原,还有就是对于在线数据库也不允许进行分离操作。

对于第二种方法是slq2008收缩日志文件的一种方法,但是此方法也不能使用过于频繁,因为进行数据库恢复模式的更改会截断事务日志文件,这样的话当时利用事务日志文件进行恢复的时候检查点不能包含数据库文件,而且当你要对事务日志进行备份的时候会重新提示你需要对数据库进行完整备份。

举个例子:比如你昨天晚上进行了一次完整备份,然后同时你也进行了一次日志备份(提前日志未被截断),然后你每个小时进行过一次差异备份,最近的差异备份时间点是14点,如果此时数据库错误修改了数据,你可以立马备份一个日志文件将数据库恢复到日志备份开始到日志备份终点前的任意时间点 。

如果此时你进行了修改数据库模式,截断日志进行了收缩,那么你的数据只能恢复到昨天晚上备份的那个日志备份时间前的任意时间点,也就是今天所做的数据库更改无法再恢复了,因为日志文件已经被截断了,不知道这样解释是否明白

因为日志文件的检查点(lsn)是连续的,每一次日志备份都是在上一次备份的基础上lsn往后增加的,lsn的范围也包括了数据库文件的lsn,也只有日志文件的lsn包括了数据库文件的lsn,才能将数据库文件进行回滚。

上图中总共有三个备份文件,一个完整备份、一个差异备份、一个日志备份,大家可以注意观察完整备份的第一个lsn与最后一个lsn,和检查点

第二个差异备份文件的的第一个lsn与最后一个lsn,和检查点,最后的日志备份的第一个lsn和最后一个lsn包含了前面两个备份文件的lsn,这种情况数据库就可以恢复到日志文件备份前的任意时间点,如果日志文件没有包含数据库文件的最后一个lsn也就无法恢复了。

⑵ 如何快速掌握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监控。

注释:数据库登录必须在原始数据库与备份数据库之间同时进行。

;

⑶ SQLserver数据库备份后,怎么查询备份的日志

SQL Server的备份有三种形式:

一是全备份(full backup)

这个备份里面包含的内容是值得商榷的,我们知道数据库有两种文件,数据文件与日志文件,全备份是不是将所有的数据文件与日志文件打包,备份成一个文件? 那么还原的时候是不是需要做恢复,将备份过后发生的事务接着备份时间点重新执行一边? 上面的问题细想都是肯定的。全备份做的事情,就是将所有的缓存先flush到磁盘上,不管在进行的事务是否提交,这样保证了日志的连续性,数据与日志的一致性,如果事务没提交 ,在日志文件上的标记是active的,这段日志也就不会被清空,下次恢复的时候,就从这段日志开始,接着使用新的日志执行。因此 全备份之前肯定会执行一次checkpoint;、

二是差异备份(differential backup)

这个备份会不会也重复full backup的过程,先执行checkpoint,然后再将上一次备份之后,发生数据页变化的这些数据页都备份起来,这部分备份就不会有日志。但是和全备份一样,备份的容积体量比较大,差异备份备份的是数据页,不管这一页是不是只有一条数据更改了,还是全部更改了;

三是日志备份(transaction log backup)

日志备份中需要注意的就是对未提交事务的理解,没有提交的事务其实还是占用日志文件的VLF,shrink并不能回收日志空间;提交事务的日志如被备份之后,就会将日志VLF打上unactive或者truncated标记,这个时候执行shrink就可以回收这部分日志VLF了。日志备份体量小,比较适合频率高的执行,比如每5分钟执行一次。

全备份:

全备份用到的命令,涉及到两方面的参数,一是指定相应的备份设备,可以是磁盘,也可以是磁带;另一方面 就是备份可用的选项,比如是否压缩,是否加密。

BACKUP DATABASE database

TO backup_device [ ,...n ]

[ WITH with_options [ ,...o ] ] ;


备份设备很讲究,可以事先定义好逻辑设备,也可以直接指定物理设备。磁带备份机倒是没见过,但是常规的磁盘备份还是可以讨论一下的:

我们可以将一个本机带路径的物理文件名指定为备份设备:

backup database lenistest

to disk = 'E:Data_BUlenistest5__backup.bck';


也可以将网络上的一个带路径的物理文件名指定为备份设备:

backup database AdventureWorks2012

to disk = '\BackupSystemBackupDisk1AW_backupsAdventureWorksData.Bak';


这里有个有趣的现象,如果我们在全备份之后 ,没有备份好日志,这个时候故障突然发生了,我们需要作恢复,但是恢复的时候因为会重写日志,这样就会丢失数据,如果不采取额外地措施,系统是会报错的:


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup.bck'


Msg 3159, Level 16, State 1, Line 6

The tail of the log for the database “lenistest” has not been backed
up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains
work you do not want to lose. Use the WITH REPLACE or WITH STOPAT
clause of the RESTORE statement to just overwrite the contents of the
log.

Msg 3013, Level 16, State 1, Line 6

RESTORE DATABASE is terminating abnormally.



所以如果对丢失的数据不关心或者认为不会丢失数据,可以采用with replace选项来重写原来的日志文件进行强制恢复。


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup.bck'

with replace;



差异备份:

差异备份相对全备份,优越的地方在于备份数据量少,但是有趣的是差异备份不能独立存在(日志备份也不能独立存在,他俩只能依附于全备份,也就是说在执行差异备份和日志备份的时候,必须先有一个全备份做好在那里), 差异备份必须以一个全备份做基准,在这基础之上再判断哪些数据页是有过更新的,这些更新的数据页计算出来并被备份起来。

use master;


go


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup.bck';


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup.bck'

with differential;


假如我们没有事先做好全备份,就直接作差异备份了,那么这是不成功的:


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup2.bck'

with differential;


Msg 3035, Level 16, State 1, Line 11

Cannot perform a differential backup for database “lenistest”, because
a current database backup does not exist. Perform a full database
backup by reissuing BACKUP DATABASE, omitting the WITH DIFFERENTIAL
option.

Msg 3013, Level 16, State 1, Line 11

BACKUP DATABASE is terminating abnormally.


日志备份:

日志备份相对差异备份来说,体量更小,同样它也需要全备份事先存在:

backup log lenistestto disk = 'E:Data_BUlenistest5__backup.bck';


假如我没有事先做好全备份,我们看看直接备份日志会出现什么结果:


Msg 4214, Level 16, State 1, Line 15

BACKUP LOG cannot be performed because there is no current database
backup.

Msg 3013, Level 16, State 1, Line 15

BACKUP LOG is terminating abnormally.


提示先做全备份!

备份我们都讨论完了,接下来我们看看还原。还原通常有两个步骤,一是还原,二是恢复。当然我们也可以直接还原不恢复,但是可能会丢失数据,除非全备份之后 ,没有任何操作。假设我们一天一个全备份,每15分钟做一个差异备份 ,每5分钟做一个日志备份,我们该如何还原我们的数据库呢?

通常我们首先要知道我们的备份文件名或者物理路径,这个地方涉及到很多术语很难理解,比如说backup device, backupset, backup media, media set ,media family.

MSDN上有一个解释,先看这个脚本:


backup database AdventureWorks2012

to tape = '\. ape0'

, tape = '\. ape1'

, tape = '\. ape2'

with format

, medianame = 'MyAdvWorks_MediaSet_1';


解释说到,这个备份操作产生了一个 media set, 这个media set就是命名为MyAdvWorks_MediaSet_1, 这个media set还有个media header, media header一旦生成,就可以往里面写入备份文件了。这段脚本也同时生成了一个横跨三个tape的备份文件, 他们统称为backup set.

当我们指定3个backup device作为backup set(备份集)并且执行第一次全备份的时候,接下来所有的备份都需要同时指定这3个backup device作为backup set:


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

with format

, medianame = 'lenistestbackupset';


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

with noinit

, differential

, medianame = 'lenistestbackupset';



Msg 3231, Level 16, State 1, Line 10

The media loaded on “E:Data_BUlenistest5__backup01.bck” is formatted
to support 3 media families, but 2 media families are expected
according to the backup device specification.

Msg 3013, Level 16, State 1, Line 10

BACKUP DATABASE is terminating abnormally.


上面我先作了一次全备份,指定了三个backup device作为一份backup set, 接下来作差异备份的时候,我只指定了其中两个backup device作为backup set, 操作失败,提示就是少了一个backup device.


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

with noinit

, differential

, medianame = 'lenistestbackupset';


这次我们指定了同样个数的backup device,但backup device的顺序颠倒了一下,操作成功。

到目前为止,我们的脚本已经新建了 1 个media set,名为 lenistestbackupset , 2 个backup set, 第一个backup set是全备份的backup set,另外一个backup set是差异备份。所以每一次备份都会产生一个backup set. Media set产生的时间则是第一次给数据库作全备份的时候。

这个时候我们需要恢复数据库,那么第一步就是要先还原全备份,但是先不恢复,等全备份还原过后,再用差异备份做恢复:

restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 1

, replace

, norecovery;


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 2

, recovery;


这里一定是用replace来重写日志。


select mf.media_set_id

, isnull(ms.name, 'no media name') as media_name

, mf.physical_device_name

, mf.family_sequence_number

, mf.media_family_id

, bs.database_name

, bs.backup_start_date

, bs.backup_finish_date

from backupmediafamily mf

inner join backupset bs

on mf.media_set_id = bs.media_set_id

left join backupmediaset ms

on bs.media_set_id = ms.media_set_id

where bs.database_name = 'lenistest';


上面的脚本可以抓出来这些media family, media set, backup set的信息,如果像上面的例子一样, 我们用3个backup device来承载备份,那么这3个backup device组成了一个media family, 按照family_sequence_number来编排,1,2,3。

下面实现一个备份到恢复的全过程例子,分别在full backup, differential backup, log backup之前各出入同样的数据,看看是不是还原的时候,能正确还原过来:


insert into dbo.dataloading

(

object_id

, object_name

)

select object_id

, name as object_name

from sys.objects;


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

with format

, medianame = 'lenistestbackupset';



insert into dbo.dataloading

(

object_id

, object_name

)

select object_id

, name as object_name

from sys.objects;


backup database lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

with noinit

, differential

, medianame = 'lenistestbackupset';



insert into dbo.dataloading

(

object_id

, object_name

)

select object_id

, name as object_name

from sys.objects;


backup log lenistest

to disk = 'E:Data_BUlenistest5__backup01.bck'

, disk = 'E:Data_BUlenistest5__backup03.bck'

, disk = 'E:Data_BUlenistest5__backup02.bck'

with noinit

, medianame = 'lenistestbackupset';


接着我们做还原与恢复:


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck', disk = 'E:Data_BUlenistest5__backup03.bck', disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 1

, replace

, norecovery;


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck', disk = 'E:Data_BUlenistest5__backup03.bck', disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 2

, norecovery;


restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck', disk = 'E:Data_BUlenistest5__backup03.bck', disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 3

, recovery;


这里的file选项就是backup set选项,表示第一个备份集,第二个备份集,第三个备份集。如果想还原到最新的故障发生时间点,前面的restore都不能recovery,只有在最后的时候才能作recovery.

如果我们只想恢复全备份的数据,只要执行recovery就可以了,但是数据肯定是少了:

restore database lenistest

from disk = 'E:Data_BUlenistest5__backup01.bck', disk = 'E:Data_BUlenistest5__backup03.bck', disk = 'E:Data_BUlenistest5__backup02.bck'

with file = 1

, replace

, recovery;

⑷ SqlServer备份数据库的4种方式有哪些

数据库备份可以分为4个备份类型。

l 全备份:创建备份完成时数据库内存在的数据的副本。

l 差异备份:只记录自上次数据库备份后发生更改的数据。差异数据库备份比数据库备份小,而且备份速度快,因此可以更经常地备份,经常备份将减少丢失数据的危险。

l 日志备份:是自上次备份事务日志后对数据库执行的所有事务的一系列记录。可以使用事务日志备份将数据库恢复到特定的即时点(如输入多余数据前的那一点)或恢复到故障点。

l 文件组备份:可以备份和还原数据库中的个别文件。可以只还原已损坏的文件,而不用还原数据库的其余部分,从而加快了恢复速度。

不同的备份类型适用的范围也不同。全备份,可以只用一步操作完成数据的全部备份,但执行时间比较长。差异备份和日志备份,都不能独立作为一个备份集来使用,需要进行一次全备份。文件备份必须与事务日志备份一起使用,所以文件备份只适用于完全恢复模型和大容量日志记录恢复模型。

每一种备份类型都有不足之处,要针对需要选择备份类型,或者使用几种备份方式的配合来完成数据库的备份。

经常使用备份方式组合有以下几种:

l 全备份+差异备份:以一周为周期,星期日进行全备份,星期一到星期六每天进行差异备份。

l 全备份+日志备份:以一周为周期,星期日进行全备份,星期一到星期六每天进行日志备份。

l 文件组备份+日志备份:备份周期取决于数据库的大小和能力,每周期分别进行一部分数据文件备份,每天进行日志备份。

⑸ 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的备份有哪几种增量备份和全局备份有社么区别

SQL Server2000主要有
1.完全数据库备份
2.数据库和事务日志备份
3.差异备份(即增量备份)
4.数据库文件或文件组备份

完全备份即备份整个数据库,包括事务日志
差异备份只备份自上次数据库备份后发生更改的部分数据库,它用来扩充完全数据库备份或数据库和事务日志备份方法

⑺ sql server 2014日志备份怎样恢复

NORECOVERY
指定不发生回滚。
从而使前滚按顺序在下一条语句中继续进行。
在这种情况下,还原顺序可还原其他备份,并执行前滚。
RECOVERY(默认值)表示,应在完成当前备份前滚之后执行回滚。
恢复数据库要求要还原的整个数据集(“前滚集”)必须与数据库一致。
如果前滚集尚未前滚到与数据库保持一致的地步,并且指定了
RECOVERY,则数据库引擎将发出错误。
也就是说,你还原一个文件后,后续还有文件要还原,就要使用NORECOVERY,如果后续没有文件,或是你不想还原后续的文件,就使用recovery。
如果你要还原事务日志,首先你要有一个完整备份,先还原完整备份,并使用NORECOVERY选项,然后,按顺序还原日志备份。只要后续还有文件要还原,就使用NORECOVERY选项,如果后续没有文件或是不想再还原其他文件了,就使用RECOVERY选项。使用RECOVERY选项后,还原过程就完成了,数据库就可以使用了。

⑻ SQL数据库备份

SQL语句里有.
备份
backupdatabase[数据库名]todisk=[磁盘路径]
例如
backupdatabasedatatodisk='D:\1.bak'
恢复
restoredatabase[数据库名]fromdisk=[磁盘路径]
例如
restoredatabasedatafromdisk='D:\1.bak'
createPROCEDUREGY_DBBak
@bakequipint,--备份设备:磁盘&磁带
@bakpathvarchar(50),--带全路径的备份文件名
@baktypeint,--完全备份&增量备份
@baklogint,--‘0’备份日志
@bakdbint,--‘0’备份数据库
@kindvarchar(7),--备份还是恢复
@retmsgvarchar(20)output--返回信息
AS
DECLARE@DevName_datavarchar(50)
DECLARE@DevName_logvarchar(50)
declare@db_pathvarchar(100)
declare@log_pathvarchar(100)
DECLARE@RCINT
SELECT@db_path=@bakpath+'.dat'
SELECT@log_path=@bakpath+'log.dat'
SELECT@RC=0
DBCCCHECKDB(Northwind)
/***********************************************************
**CREATEBACKUPANDRESTOREDEVICES
************************************************************/
IF@RC=0
BEGIN
EXECsp_admpdevice'disk',@DevName_data,@db_path
execsp_admpdevice'disk',@DevName_log,@log_path
select@rc=@@error
IF@RC<>0
begin
EXECSP_DropDevice@Devname_data
execsp_dropdevice@devname_log
SELECT@RC=-1000
return@rc
end
END
IF@kind='backup'
BEGIN
IF@bakequip=0
BEGIN
IF@baktype=0
BEGIN
IF@bakdb=0
BEGIN
BACKUPDATABASENorthwindTODISK=@Devname_data
WITHINIT
END
IF@baklog=0
BEGIN
BACKUPLOGNorthwindWITHNO_LOG
BACKUPLOGNorthwindTODISK=@DevName_log
WITHINIT,NO_TRUNCATE
END
END
ELSEBEGIN
IF@bakdb=0
BEGIN
BACKUPDATABASENorthwindTODISK=@DevName_data
WITHNOINIT
END
IF@baklog=0
BEGIN
BACKUPLOGNorthwindWITHNO_LOG
BACKUPLOGNorthwindTODISK=@DevName_log
WITHNOINIT,NO_TRUNCATE
END
END
END
SELECT@retmsg='数据库备份成功!'
END
IF@kind='restore'
BEGIN
=@DevName_dataWITHREPLACE
SELECT@retmsg='恢复数据库成功!'
END
RETURN0