备份SQL Server数据库后,SQL Server ErrorLog错误日志也会备份吗

教你如何清除SQL日志

1．打开查询分析器，输入命令

DUMP TRANSACTION 数据库名 WITH NO_LOG

2再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。

清除Log有两种方法：

1自动清除法

开放数据库选项 Trunc Log on Chkpt，使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预，由SQL Server自动执行，并且一般不会出现Log溢满的情况；缺点是只清除Log而不做备份。

2手动清除法

执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志：

dump transaction with truncate_only

dump transaction with no_log

通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令，这条命令写进事务日志时，还要做必要的并发性检查。SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况，使用这条命令有很大的危险性，SQL Server会d出一条警告信息。为了尽量确保数据库的一致性，你应将它作为“最后一招”。

以上两种方法只是清除日志，而不做日志备份，若想备份日志，应执行“dump transaction database_name to dumpdevice”命令。

清除后对数据库没有影响

No1：先在行程电脑上备份：

backup database 数据库名 to disk='文件路径'

然后把备件的文件复制到自己电脑上：

restore database 数据库名 from disk='文件路径'

No2：

备份远程SQLSERVER数据库到本地

1 知道远程MSSQL IP 用户名 密码

2 在本地MSSQL企业管器里新注册 远程数据库

3 选中所有远程数据库的用户表,右键 所有任务 生成SQL脚本 并在选项里选中 编写主键 外键

4 在本地新建一数据库，在新建数据库中执行新生成的SQL脚本，注意脚本中的所属用户 一般全部替换为[dbo] 然后全部执行。

5 然后在新建数据库中点 右键 所有任务 导入数据，先填源数据库，也就是远程数据库，后填目的数据库，也就是新数据库 最后确定。这样就可以把远程的数据库备份到本地

No3:服务器上的SQLSERVER2000数据库导到本地

一，备份SQLSERVER2000，生成bak文件，压缩成包，下载到本地，解压，还原数据库，

二，本sql客户端远程链接服务器，备份，或导出到本地数据库（这个看你网速了），同时要开放服务器1433端口，很不安全

三，分离数据库，考下_dat和log,，考下这两个文件，服务器上再附加，本地用这两个文件附加

在SQL Server 70和SQL Server2000中，可以用下面的命令查看： DBCC log ( {dbiddbname}, [, type={01234}] )参数:Dbid or dbname - 任一数据库的ID或名字type - 输出结果的类型:0 - 最少信息(operation, context, transaction id)1 - 更多信息(plus flags, tags, row length)2 - 非常详细的信息(plus object name, index name,page id, slot id)3 - 每种 *** 作的全部信息4 - 每种 *** 作的全部信息加上该事务的16进制信息默认 type = 0要查看MSATER数据库的事务日志可以用以下命令： DBCC log (master)释放日志空间1清空日志　 DUMP TRANSACTION 库名 WITH NO_LOG 2截断事务日志：　 BACKUP LOG 数据库名 WITH NO_LOG3收缩数据库文件(如果不压缩,数据库的文件不会减小　 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件　 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了　 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了　 也可以用SQL语句来完成　 --收缩数据库　 DBCC SHRINKDATABASE(客户资料)　 --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select from sysfiles　 DBCC SHRINKFILE(1)4为了最大化的缩小日志文件(如果是sql 70,这步只能在查询分析器中进行)　 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\pubsmdf'5为了以后能自动收缩,做如下设置:　 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"　 --SQL语句设置方式:　 E X E C sp_dboption '数据库名', 'autoshrink', 'TRUE'6如果想以后不让它日志增长得太大　 企业管理器--服务器--右键数据库--属性--事务日志　 --将文件增长限制为xM(x是你允许的最大数据文件大小)　 --SQL语句的设置方式:　 alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)特别注意：　 请按步骤进行,未进行前面的步骤,请不要做后面的步骤　 否则可能损坏数据库　 一般不建议做第4,6两步　 第4步不安全,有可能损坏数据库或丢失数据　 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复另外提供一种更简单的方法，建议大家使用。更简单的方法： 1。右建数据库属性窗口--故障还原模型--设为简单 2。右建数据库所有任务--收缩数据库 3。右建数据库属性窗口--故障还原模型--设为大容量日志记录

日志处理方法:

/--特别注意

请按步骤进行,未进行前面的步骤,请不要做后面的步骤

否则可能损坏你的数据库

一般不建议做第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 70,这步只能在查询分析器中进行)

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)

下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程。

MySQL 常见的备份工具主要分为三种：

这里先说一下 binlog 备份，它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复。

mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句。mysqldump 的备份流程大致如下：

从上面可以看出在 mysqldump 备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK），直到备份结束。当然我们可以选一个从库进行备份，这样就不会影响线上业务。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的。

但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸。例如，使用 mysqldump 常见的问题有：

所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么 *** 作，会对现有数据造成什么影响。

Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里不再单独介绍。

Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下：

Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题。

使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析。

通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首选；mysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响。

备份策略主要有：全量备份和增量备份，再加上 binlog 备份。

目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同，全量备份的频率不同。备份程序主要架构如下：

说明：

Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中，数据库可以进行正常的读写或者其他变更 *** 作，但是偶尔也会遇见备份引起的元数据锁，或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。

说明：以下对 Percona XtraBackup 的分析都是基于 2423 的版本，其他版本会略有差别，但是关键步骤基本相同。

XtraBackup 在备份开始时，会创建一个后台线程，专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部，找出当前的 checkpoint lsn ，然后从该 lsn 后顺序拷贝所有的 redo log ，包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成，才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下：

在拷贝ibd文件之前，会先扫描数据库的数据文件目录，获取ibdata1，undo tablespaces及所有的ibd文件列表，并会记录相应的 space id，因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容，以及对应的redo log条目。然后开始循环拷贝ibdata1，undo tablespaces及所有的ibd文件。

这里可通过设置--parallel进行多线程备份，提高物理文件的拷贝效率。不设置则默认为1。

在所有ibd文件拷贝完成后，XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂，因为备份非ibd文件前需要加锁，具体是否会加锁主要受到--no-lock 参数设置的影响。

若是设置了--no-lock为TRUE，则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁，但是若备份过程中对non-InnoDB表执行了DDL或者DML *** 作， 这会导致备份的不一致，恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE，默认值是FALSE，也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。

下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑：

流程图如下：

总结来看：

1）若--no-lock为FALSE（默认值），则先施加全局读锁，然后再进行拷贝文件，另外若 --safe-slave-backup 设置为TRUE ，则会在加全局锁之前关闭SQL_THREAD线程；

2）若--no-lock为TRUE，则不会施加锁，直接进行拷贝文件。

加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码，如下：

lock_tables_maybe 函数简化处理流程如下：

1）若备份实例上已经加锁（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者设置lock-ddl-per-table 则直接返回；

2）若支持备份锁，则执行LOCK TABLES FOR BACKUP；

3）若不支持备份锁，则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置，在执行该 *** 作前会判断是否有执行中的DDL/DML，以及等待超时时间，是否kill 对应的未结束的事务等。

从上文中我们还看到一个参数--safe-slave-backup ，该参数的主要作用是：

若是在从库执行的备份 *** 作时设置了该参数，可以防止因从库同步主库 *** 作，而导致XtraBackup长时间请求不到锁而造成备份失败。

若是设置了 --safe-slave-backup 为TRUE，那么会执行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件，Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成，这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。

备份完非 ibd 文件后，将会备份 slave 和 binlog 信息。

mysql-bin000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持备份锁的实例上备份，指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁（ LOCK BINLOG FOR BACKUP），这会阻塞任何会更改 binlog 位点的 *** 作。

备份完数据库的所有文件和binlog等相关信息，备份工作就基本完成了，之后主要执行的 *** 作如下：

1）执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘；

2）停止redo log复制线程；

3）释放全局读锁（备份锁），binlog锁；

4）开启SQL_THREAD；

5）拷贝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-mycnf；

7）打印备份信息到xtrabackup_info文件，这些信息主要包含备份时使用的参数信息，备份起止时间，binlog位点信息，以及将会回到的lsn点。

下面是xtrabackup_info记录的部分内容：

加锁对应的函数是 mdl_lock_tables ，释放锁对应的函数是 mdl_unlock_all，主要是执行COMMIT，结束 mdl_lock_tables 中开启的显式事务，来释放MDL锁。mdl_lock_tables 流程如下：

上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 248 之后添加的，因为 MySQL 57 新增了一个叫做 Sorted Index Builds 的功能，这会导致某些 DDL *** 作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁，阻止 DDL *** 作。

另外，若备份时指定了--lock-ddl或--lock-ddl-per-table，则在备份非 ibd 文件时就不是再有加锁 *** 作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行，Percona Server for MySQL已经在 5616-640 版本开始支持这种更加轻量的备份锁。

Q1: 使用 XtraBackup 备份的文件进行恢复时，恢复到哪个时间点？ A1：恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点，因为这时任何改变 binlog 位点的 *** 作都会被阻塞，redo log和binlog 是一致的。

Q2: 在开启 binlog 的情况下，MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的，为什么XtraBackup 不用备份binlog？

A2：因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改变binlog位点的 *** 作，这样只需要根据redo log将有commit log 的事务提交，没有commit log的事务进行回滚即可。

Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些？

A3：通过分析备份流程可以发现备份 binlog 位点信息（加binlog锁）是发生在停止 redo 拷贝线程前，而释放锁是在停止 redo 拷贝线之后，所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息，未提交的事物也就没有对应的 commit log 的信息，即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ，但是事务无法提交，也就没有 commit log 的信息的，最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。

Q4：Percona XtraBackup什么时候会加锁，以及影响加锁时间长度的因素有哪些？

A4：上面进行了分析，加锁 *** 作只在备份非 ibd 文件时执行，加锁时长主要和非事务表的数量和大小有关，非事务表的数量越多，体积越大，拷贝文件所用的时间越长，那么加锁时间也就越长。也会和 redo log 生成的速度有关，只是 redo log 刷盘受到多个因素的影响，未及时刷盘的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump选择哪个更好？

A5：通过上面的的解析，若是整个实例备份，首先选择 Percona XtraBackup ，因为对数据库的影响最小。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump 。注意，对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务。

一 理解什么是数据库恢复

当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的 *** 作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此当发生上述故障后，希望能重构这个完整的数据库，该处理称为数据库恢复。恢复过程大致可以分为复原(Restore)与恢复(Recover)过程。

数据库恢复可以分为以下两类：

11实例故障的一致性恢复

当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM

ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况Oracle在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：

（1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，

包括对回滚段的内容恢复。

（2） 回滚未提交的事务，按步1重新生成回滚段所指定的 *** 作。

（3） 释放在故障时正在处理事务所持有的资源。

（4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。

12介质故障或文件错误的不一致恢复

介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都是不一致的，需要DBA手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行的归档方式和备份方式。

（1） 完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全恢复可使用，其决定于毁坏文件和数据库的可用性。

（2）

不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。

基于撤消(CANCEL)恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的 *** 作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复 *** 作。

基于时间(TIME)和基于修改(SCN)的恢复：如果DBA希望恢复到过去的某个指定点，是一种理想的不完全介质恢复，一般发生在恢复到某个特定 *** 作之前，恢复到如意外删除某个数据表之前。

第二章 数据库恢复案例测试环境

21 数据库环境

以下的所有案例都是通过测试经过，环境为：

OS：Windows 2000 Server

DB：Oracle 816

DBNAME：TEST

数据文件：

SQL> select file#,status,enabled,name from v$datafile;

FILE# STATUS ENABLED NAME

----------------------------------------------------------------

1 SYSTEM READ WRITE D:/Oracle/ORADATA/TEST/SYSTEM01DBF

2 ONLINE READ WRITE D:/Oracle/ORADATA/TEST/RBS01DBF

3 ONLINE READ WRITE D:/Oracle/ORADATA/TEST/USERS01DBF

4 ONLINE READ WRITE D:/Oracle/ORADATA/TEST/TEMP01DBF

5 ONLINE READ WRITE D:/Oracle/ORADATA/TEST/TOOLS01DBF

6 ONLINE READ WRITE D:/Oracle/ORADATA/TEST/INDX01DBF

控制文件：

SQL> select from v$controlfile;

STATUS NAME

---------------------------------------------------------------------

D:/Oracle/ORADATA/TEST/CONTROL01CTL

D:/Oracle/ORADATA/TEST/CONTROL02CTL

D:/Oracle/ORADATA/TEST/CONTROL03CTL

联机日志：

SQL> select from v$logfile;

GROUP# STATUS MEMBER

---------------------------------------------------------------------

1 STALE D:/Oracle/ORADATA/TEST/REDO01LOG

2 D:/Oracle/ORADATA/TEST/REDO02LOG

3 STALE D:/Oracle/ORADATA/TEST/REDO03LOG

22 数据库备份脚本

冷备份脚本:

rem script:coldbaksql

rem creater:chenjiping

rem date:582003

rem desc:offline full backup database

--connect database

connect internal/password;

--shutdown database

shutdown immediate;

--Copy Data file

!xcopy d:/Oracle/oradata/test/dbf d:/database/H/R;

--Copy Control file

!xcopy d:/Oracle/oradata/test/ctl d:/database/H/R;

--Copy Log file

!xcopy d:/Oracle/oradata/test/log d:/database/H/R;

--startup database

startup;

说明：

1、以上脚本在数据库关闭状态下备份数据库所有的数据文件，联机日志，控制文件（在一个目

录下），如果成功备份，所有文件是一致的;

2、没有备份参数文件，参数文件可以另外备份，没有必要每次都备份，只需要在改变设置后备份一次;

3、如果以上命令没有成功依次执行，那么备份将是无效的，如连接数据库不成功，那么肯定关闭数据库也不成功，那么备份则无效;

4、冷备份建议下人工干预下执行。

数据库OS热全备份脚本

rem script:hotbaksql

rem creater:chenjiping

rem date:582003

rem desc:backup all database datafile in archive

--connect database

connect internal/password;

--archive

alter system archive log current;

--start

alter tablespace system begin backup;

!xcopy d:/Oracle/oradata/test/system01dbf d:/databak/H/R;

alter tablespace system end backup;

alter tablespace rbs begin backup;

!xcopy d:/Oracle/oradata/test/rbs01dbf d:/databak/H/R;

alter tablespace rbs end backup;

alter tablespace users begin backup;

!xcopy d:/Oracle/oradata/test/users01dbf d:/databak/H/R;

alter tablespace users end backup;

alter tablespace tools begin backup;

!xcopy d:/Oracle/oradata/test/tools01dbf d:/databak/H/R;

alter tablespace tools end backup;

alter tablespace indx begin backup;

!xcopy d:/Oracle/oradata/test/indx01dbf d:/databak/H/R;

alter tablespace indx end backup;

--end

--bak control file

--binary

alter database backup controlfile to 'd:/databak/controlbinbak000';

--ascii

alter database backup controlfile to trace;

alter system archive log current;

说明：

1、热备份必须在数据库归档方式下才可以运行；

2、以上脚本可以在数据库运行状态下备份数据库所有的数据文件（除了临时数据文件），没有必要备份联机日志；

3、归档日志至少需要一次完整备份之后的所有日志；

4、如果以上命令没有成功依次执行，那么备份也是无效的，如连接数据库不成功，那么备份则无效。

RMAN备份只讲叙有恢复目录的情况，如果没有恢复目录，情形大致相似。以下是RMAN的热备份全备份的脚本：

# script:bakuprcv

# creater:chenjiping

# date:582003

# desc:backup all database datafile in archive with rman

# connect database

connect rcvcat rman/rman@back;

connect target internal/virpure;

# start backup database

run{

allocate channel c1 type disk;

backup full tag 'dbfull' format 'd:/backup/full%u_%s_%p' database

include current controlfile;

sql 'alter system archive log current';

release channel c1;

}

# end

说明：

1、 数据库必须运行在归档模式下;

2、 RMAN将自动备份数据文件，运行可靠;

3、 归档日志另外备份处理，但至少需要保存一次备份来的日志;

4、 没有必要用RMAN做冷备份，效果不好。

以上举例说明了数据库的恢复案例的测试环境与部分备份测试脚本，其它的备份脚本可以根据以上脚本演变而来或在案例中加以说明。

数据库的自动实例将不加以说明，这里只举例说明媒体错误或人为错误造成的恢复可能。

以上包括以下案例都是在WINDOWS+Oracle816上测试验证的，在不同的 *** 作系统与不同的数据库版本中略有差别。

以上就是关于备份SQL Server数据库后,SQL Server ErrorLog错误日志也会备份吗全部的内容，包括:备份SQL Server数据库后,SQL Server ErrorLog错误日志也会备份吗、sqlserver怎么把服务器上的数据库备份到本地，不是局域网的服务器、sql server 2008 日志怎么备份等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！