事务日志备份与还原
数据库恢复的基本技术
数据库恢复的基本技术数据库恢复是指在数据库发生故障或损坏后，通过一系列的技术手段将数据库恢复到正常运行状态的过程。
数据库恢复技术主要包括备份和恢复、事务日志恢复以及物理和逻辑恢复等。
本文将分别介绍这些基本的数据库恢复技术。
1.备份和恢复技术备份和恢复是数据库恢复的最基本方法。
备份指将数据库的原始数据或者副本复制到其他存储介质中，以防止原始数据丢失或损坏。
常见的备份方式包括完全备份和增量备份。
完全备份是将整个数据库完全复制到备份介质，而增量备份则是只备份自上次备份以来发生变化的数据。
当数据库发生故障时，可以通过还原备份数据来恢复数据库。
2.事务日志恢复技术事务日志是数据库中记录每一次事务操作的日志，包括事务开始、事务结束和对数据库进行的修改操作。
事务日志恢复技术是通过分析事务日志记录来实现数据库的恢复。
当数据库发生故障时，可以通过重放事务日志中的操作来恢复数据库到故障发生前的状态。
事务日志恢复主要包括正向恢复和反向恢复两种方式。
正向恢复是从备份数据开始，按照日志记录的顺序逐步重放操作，直到故障点之后的操作。
反向恢复则是从故障点开始，按照日志记录的顺序逐步撤销操作，直到备份数据的状态。
3.物理恢复技术物理恢复是指将数据库的物理文件从损坏或错误状态恢复到正常状态的过程。
常见的物理恢复技术包括点备份和增量备份恢复、崩溃恢复以及校验和恢复等。
点备份和增量备份恢复是通过使用备份数据和增量备份数据来恢复数据库。
崩溃恢复是指在数据库崩溃、主机断电等突发情况下，通过恢复到最后一次一致状态来保护数据的完整性。
校验和恢复是通过校验和验证来检测和纠正物理文件的错误，以保证数据的一致性和完整性。
4.逻辑恢复技术逻辑恢复是指通过使用数据库的逻辑结构和操作来恢复数据库。
常见的逻辑恢复技术包括数据导入和导出、数据转换以及数据修复等。
数据导入和导出是将数据库中的数据导出为文本文件或其他格式，然后再将导出的数据导入到数据库中。
数据转换是指将数据库中的数据转换为其他数据库或应用程序所需的格式。
sql server日志文件丢失的恢复方法
sql server日志文件丢失的恢复方法SQL Server是一种关系型数据库管理系统，它提供了持久化存储数据的功能。
在使用SQL Server时，我们通常会遇到一些问题，例如日志文件丢失。
当日志文件丢失时，我们需要采取一些措施来恢复数据。
本文将一步一步地回答关于SQL Server日志文件丢失的恢复方法。
第一步：检查日志文件丢失的原因在采取任何措施之前，我们首先需要确定日志文件丢失的原因。
有几种可能的原因，例如磁盘损坏、人为删除、数据库服务中断等。
通过了解原因，我们可以更好地选择适当的恢复方法。
第二步：备份数据库在尝试恢复日志文件之前，我们应该确保已经备份了数据库。
这是非常重要的，因为如果在修复日志文件时出现问题，备份可以用来还原数据库至丢失日志文件之前的状态。
在进行任何恢复操作之前，请确保已经备份了数据库，以免造成不可逆的损失。
第三步：运行数据库完整性检查在恢复日志文件之前，我们应该运行数据库的完整性检查。
这可以帮助我们发现数据库中可能存在的一些问题，例如损坏的数据页、磁盘错误等。
通过运行完整性检查，我们可以修复这些问题，以确保数据库的稳定性。
第四步：使用备份日志恢复如果我们的数据库已经定期备份，并且丢失的日志文件在最近的备份中，我们可以使用备份日志来恢复数据库。
我们可以在SQL Server Management Studio中使用“恢复数据库”向导来完成此操作。
首先，我们选择要恢复的数据库，然后选择相应的备份文件和备份日志文件。
然后，我们可以选择恢复模式，例如完整恢复模式或简单恢复模式，并完成向导以恢复数据库。
第五步：使用事务日志恢复如果备份日志中没有包含所需的丢失日志文件，我们可以尝试使用事务日志来恢复数据库。
SQL Server将每个事务的详细信息记录在事务日志中，通过读取事务日志，我们可以逐个事务地恢复数据库。
首先，我们需要创建一个空数据库，并将其设置为恢复模式。
然后，我们可以使用恢复工具或编写T-SQL语句来读取事务日志，并逐个事务地执行以恢复数据库。
附加：SQL Server 备份和恢复
SQL Server 备份和还原事务日志中包含对数据库进行的操作如果出现错误提示：尚未备份数据库 "***" 的日志尾部。
如果该日志包含您不希望丢失的工作，请使用 BACKUP LOG WITH NORECOVERY 备份该日志。
请使用…要选择一、知识点完全备份：备份全部选中的文件夹，并不依赖文件的存档属性来确定备份那些文件。
（在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份，换言之，清除存档属性）。
完全备份也叫完整备份。
差异备份：差异备份是针对完全备份：备份上一次的完全备份后发生变化的所有文件。
（差异备份过程中，只备份有标记的那些选中的文件和文件夹。
它不清除标记，即：备份后不标记为已备份文件，换言之，不清除存档属性）。
增量备份：增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。
（增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，即：备份后标记文件，换言之，清除存档属性。
）事务日志备份：在特定事务日志备份之前执行的完整数据库备份和上次差异备份（如果有）。
在完整数据库备份之后执行的所有事务日志备份或在特定事务日志备份之前执行的差异备份（如果您还原了差异备份）。
如果你设置了恢复模式为【简单】，你将无法使用【事务日志】备份。
SQL Server 2000 和 SQL Server 2005：创建事务日志备份，您必须使用完整恢复或大容量日志记录恢复模型。
数据库→属性→选项—>恢复模式部分备份：通过指定 READ_WRITE_FILEGROUPS 创建的备份称为“部分备份”。
在简单恢复模式下，只允许对只读文件组执行文件组备份。
还原的数据备份类型：数据库备份、部分备份或文件备份。
对于数据库备份或部分备份，日志备份序列必须从数据库备份或部分备份的结尾处开始延续。
对于一组文件备份，日志备份序列必须从整组文件备份的开头开始延续。
数据库常用的备份和恢复方法
数据库常用的备份和恢复方法1. 定期全量备份：定期对数据库进行完整备份，可保证数据库的完整性和可恢复性。
2. 差异备份：在全量备份的基础上，只备份发生变化的数据部分，可以节省存储空间和备份时间。
3. 事务日志备份：备份数据库的事务日志，可以实现逐渐备份，精准的还原到某一时间点。
4. 复制备份：将数据库复制到其他设备或位置，以防主要数据库损坏或丢失。
5. 增量备份：只备份自上次备份以来发生的数据变化，可大幅减少备份时间和存储成本。
6. 数据库快照：生成数据库的快照，记录数据库在某个时间点的状态，用于快速恢复到该状态。
7. 物理备份：备份数据库的物理文件，包括数据文件、日志文件等，可快速恢复数据库的完整性。
8. 逻辑备份：备份数据库的逻辑结构，包括表、索引、视图等，方便跨平台导入导出。
9. 热备份：在数据库运行时进行备份，不停止数据库服务，可实现24/7的备份操作。
10. 冷备份：在数据库停止时备份，可以获得更稳定可靠的备份结果。
11. 数据库镜像：实时将数据库复制到另一个实例，确保备份数据的实时性和高可用性。
12. 数据库导出：将数据库中的数据导出为文本文件，以便迁移或重建数据库。
13. 数据库导入：从导出的文本文件中导入数据到数据库，用于恢复或迁移数据。
14. 增量同步备份：将增量数据同步到备份设备，以实现实时备份和恢复。
15. 压缩备份：对备份文件进行压缩，减小存储空间占用和备份速度。
16. 分布式备份：将备份数据分布保存在多个位置，提高数据的安全性和可靠性。
17. 数据库迁移：将数据库从一个平台迁移到另一个平台，需要备份和恢复数据。
18. 数据库克隆：创建数据库的副本，用于测试、开发或灾难恢复。
19. 自动备份计划：设定定时任务，自动执行备份操作，提高备份的可靠性和定期性。
20. 增量还原：在全量备份的基础上，只还原最近的增量备份，减少数据恢复的时间成本。
21. 数据库快速还原：通过快照或镜像技术，实现数据库的快速、即时恢复。
sqlserver drop table 恢复
在SQL Server中，一旦使用DROP TABLE语句删除了一个表，除非你有数据库备份，否则无法直接通过SQL Server提供的简单命令来恢复。
DROP TABLE 是一个不可逆操作，删除的表和其数据会永久丢失。
以下是一些可能的恢复方法：
1. 数据库备份和还原：
-如果你在删除表之前定期备份了数据库，可以使用数据库备份进行还原。
-使用SQL Server Management Studio (SSMS) 或Transact-SQL (T-SQL) 来还原之前的数据库备份。
2. 事务日志备份和还原：
-如果启用了事务日志备份，并且有相关的事务日志备份文件，你可以考虑使用事务日志备份来还原。
-使用RESTORE DATABASE命令来还原数据库。
3. 第三方工具：
-一些第三方工具可能提供了更灵活的恢复选项。
你可以考虑使用这些工具来恢复删除的表。
注意事项：
-在任何情况下，在进行任何数据库还原之前，请确保你理解可能导致数据丢失的风险。
还原数据库将覆盖当前数据库的内容。
--示例：使用数据库备份还原
USE master;
GO
RESTORE DATABASE YourDatabase
FROM DISK = 'XXX'
WITH REPLACE;
GO
请替换上述示例中的YourDatabase、XXX等信息为实际的数据库名称和备份文件路径。
重要提示：为了避免数据丢失，建议在执行任何对数据库结构进行更改的SQL语句之前，先进行备份。
备份是防范风险的有效手段。
数据库备份与恢复方法总结
数据库备份与恢复方法总结数据库备份是一个重要的数据管理任务，它可以确保数据的安全性和可恢复性。
数据库备份的目的是将数据库中的数据和结构导出并存档，以防止数据丢失或数据不一致性的问题。
恢复数据库则是将备份的数据重新导入，并使数据库恢复到故障发生之前的状态。
本文将总结几种常见的数据库备份与恢复方法，以及其优缺点。
1. 完全备份（Full Backup）完全备份是将整个数据库备份到磁盘或其他存储介质中，包括所有的表、视图、存储过程等。
这是最常见和最简单的备份方法，可以快速实施恢复，并保证数据的完整性。
但是，完全备份需要耗费较长的时间和存储空间，特别是当数据库庞大并且频繁更新时。
2. 增量备份（Incremental Backup）增量备份只备份上次完全备份之后的增量更新数据。
它可以大大减少备份时间和存储空间的开销。
增量备份记录了自上次完全备份以来所做的所有更改，当需要恢复数据时，需要依次恢复上次完全备份和增量备份中的更改。
由于增量备份不能直接提供完整的数据库镜像，恢复过程可能会更复杂一些。
3. 差异备份（Differential Backup）差异备份记录了自上次完全备份以来发生的所有更改，并与上次完全备份进行对比，只备份新的或更改的数据。
与增量备份不同的是，差异备份备份的是与上次完全备份的差异，而不是上次备份之后的增量更新。
差异备份在恢复数据时，只需要恢复上次完全备份和最近的差异备份，大大简化了恢复过程。
4. 日志备份（Log Backup）日志备份是备份数据库的事务日志，以确保数据操作的连续性和一致性。
日志备份可以提供更高级别的数据恢复，恢复可以精确到某个时段甚至某个特定事务。
通过定期备份事务日志，可以将数据库恢复到任意时间点之前的状态。
然而，日志备份通常需要更多的存储空间和备份时间。
总体来说，完全备份适用于小型数据库或需要紧急恢复的情况。
增量备份适用于频繁更新的大型数据库，可以减少备份时间和存储空间的开销。
sql server恢复方法
sql server恢复方法SQL Server是一种关系型数据库管理系统（RDBMS），用于存储和管理数据库。
在日常操作中，可能会遇到各种数据丢失或损坏的情况，因此需要进行恢复操作来恢复数据库的完整性和可用性。
下面将介绍SQL Server常见的恢复方法。
一、完整备份恢复完整备份是指备份整个数据库的过程，包括数据、存储过程、触发器、索引等。
如果数据库损坏或丢失，可以通过完整备份来恢复数据库。
1.创建完整备份：使用SQL Server Management Studio（SSMS）或T-SQL命令创建完整备份。
例如，使用SSMS，右键点击数据库->任务->备份，在“选择备份类型”中选择“完整”，并设置备份路径、名称等参数，然后点击“确定”开始备份。
2.恢复完整备份：使用SSMS或T-SQL命令进行恢复。
例如，使用SSMS，右键点击数据库->任务->还原->数据库，在“设备”中选择备份文件，设置恢复操作的目的数据库名称等参数，然后点击“确定”开始恢复。
二、差异备份恢复差异备份是指备份数据库中自上次完整备份以来的更改。
使用差异备份可以减少备份时间和存储空间。
如果数据库部分数据丢失或损坏，可以先恢复完整备份，然后再将差异备份应用到数据库中，以恢复数据到更精确的时间点。
1.创建差异备份：在完整备份后，可以使用SSMS或T-SQL命令创建差异备份。
例如，使用SSMS，在“选择备份类型”中选择“差异”，设置备份路径、名称等参数，然后点击“确定”开始备份。
2.恢复差异备份：使用SSMS或T-SQL命令进行恢复。
例如，使用SSMS，右键点击数据库->任务->还原->数据库，在“设备”中选择差异备份文件，设置恢复操作的目的数据库名称等参数，然后点击“确定”开始恢复。
三、事务日志备份恢复事务日志是用于记录数据库操作的日志文件，包括对数据库的修改、事务的提交和撤销等。
事务日志备份可以实时记录数据库操作，以便在数据库发生故障时进行恢复。
Linux下的数据库备份与恢复方法
Linux下的数据库备份与恢复方法数据库备份与恢复在Linux系统中是非常重要的任务，它能够保护数据库免受数据丢失和系统崩溃的影响。
本文将介绍一些常用的数据库备份和恢复方法，以帮助用户更好地管理他们的数据库。
一、文件级备份方法文件级备份是一种将数据库文件复制到另一个位置以创建备份的方法。
它适用于大多数数据库系统，并且可以手动或自动执行。
1. 使用cp命令进行备份cp命令是Linux系统中最简单的备份数据库文件的方法之一。
在终端中输入以下命令：```cp /path/to/source.db /path/to/backup.db```其中，`/path/to/source.db`是源数据库文件的路径，`/path/to/backup.db`是备份数据库文件的路径。
通过这个命令，源数据库文件将被复制到指定的备份位置。
2. 使用rsync命令进行增量备份rsync是一个强大的文件同步工具，能够将源数据库文件与备份位置之间的差异进行同步。
这使得增量备份成为可能，只备份与上次备份不同的部分。
以下是一个使用rsync进行增量备份的示例命令：```rsync -av --delete /path/to/source.db /path/to/backup/```这将对源数据库文件和备份位置进行比较，并只复制差异部分，节省了备份时间和存储空间。
二、数据库级备份方法数据库级备份是一种将数据库转储为可独立的备份文件的方法。
在备份文件中，包含了数据库内的所有表、数据和结构信息。
常见的数据库级备份方法包括使用mysqldump和pg_dump等工具。
1. 使用mysqldump备份MySQL数据库mysqldump是一种备份MySQL数据库的简单方法。
以下是一个使用mysqldump备份数据库的命令示例：```mysqldump -u username -p password database_name > backup.sql```其中，`username`和`password`分别是数据库的用户名和密码，`database_name`是需要备份的数据库名称，`backup.sql`是备份文件的名称。
尾日志备份
本章要点† 事务日志备份与恢复原理† 尾日志备份† 产生备份集† 将数据库恢复到故障点† 备份恢复中的疑难问题一个不懂事务日志的DBA，是很难掌握数据库的精髓的。
事务日志忠实地记录了数据库的活动，所以基于这些记录的活动就可以随心所欲地将数据库的状态恢复到特定的即时点或恢复到故障点。
然而，不是每个DBA都能够正确完成这些操作的。
其中的奥秘在哪里呢？本章深入研究事务日志备份与恢复操作。
14.1 事务日志备份与恢复原理下面我们首先来学习事务日志备份与恢复的原理。
14.1.1 事务日志备份与恢复原理事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。
在简单模型下，事务日志有可能被破坏，所以事务日志备份可能不连续，不连续的事务日志备份没有意义，因为基于日志的恢复要求日志是连续的。
可以使用事务日志备份将数据库恢复到特定的即时点（如输入多余数据前的那一点）或恢复到故障点。
恢复事务日志备份时，SQL Server 2005重做事务日志中记录的所有更改。
当SQL Server 2005到达事务日志的最后时，已重新创建了与开始执行备份操作的那一刻完全相同的数据库状态。
如果数据库已经恢复，则SQL Server 2005将回滚备份操作开始时尚未完成的所有事务。
一般情况下，事务日志备份比数据库备份使用的资源少。
因此可以比数据库备份更经常地创建事务日志备份。
经常备份将减少丢失数据的危险。
图14-1所示为基于完全恢复模型下的1个完全备份＋N个连续的事务日志备份的策略。
如果中间的日志备份02删除或者损坏，则数据库只能恢复到日志备份01的即时点。
图14-1 事务日志备份与恢复原理假如日志备份01、02和03都是完整的，那么在恢复时，先恢复数据库完全备份，然后依次恢复日志备份01、02和03。
如果要恢复到故障点，就需要看数据库的当前日志是否完整，如果是完整的，可以做一个当前日志的备份，然后依次恢复日志备份04就可以了。
数据库常用的备份和恢复方法
数据库常用的备份和恢复方法1. 备份方法：使用数据库管理系统自带的备份工具，如MySQL的mysqldump命令或SQL Server的Backup Database语句。
描述：数据库管理系统提供了备份工具，可以将数据库的数据和结构导出为一个备份文件，通常以.sql格式保存。
用户可以定期使用这些备份工具进行全量备份或增量备份。
2. 备份方法：使用文件系统级别的数据复制工具进行备份，如使用rsync或Windows 的文件复制功能。
描述：可以通过文件系统级别的复制工具将数据库的文件直接复制到其他存储设备上，实现备份目的。
这种备份方法适用于非常大的数据库，因为它可以减少备份和恢复所需的时间。
3. 备份方法：使用虚拟机快照进行备份。
描述：如果数据库运行在虚拟机上，可以使用虚拟机快照功能来创建数据库的备份。
快照是虚拟机当前状态的拷贝，可以在需要的时候还原到该状态。
4. 备份方法：使用存储级别的快照功能进行备份。
描述：一些存储设备提供了快照功能，可以在存储级别对数据库进行备份。
这种备份方法通常能够在不影响数据库性能的情况下实现备份，而且可以实现非常快速的恢复。
5. 备份方法：使用第三方备份工具进行备份。
描述：市面上有许多第三方备份工具，可以根据实际需求选择适合自己数据库的备份工具。
这些备份工具通常提供更加灵活和高级的备份和恢复功能。
6. 恢复方法：使用数据库管理系统自带的恢复工具进行数据库的还原。
描述：数据库管理系统自带的恢复工具可以将备份文件中的数据和结构导入到数据库中，还原成原来的状态。
7. 恢复方法：使用事务日志进行数据库的恢复。
描述：数据库管理系统中的事务日志记录了数据库的变更历史，可以利用事务日志进行数据库的恢复，还原到数据库崩溃前的状态。
8. 恢复方法：使用数据库管理系统提供的点对点恢复工具进行数据库的恢复。
描述：一些数据库管理系统提供了特殊的恢复工具，可以直接从备份文件中进行点对点恢复，即将备份数据直接还原到生产环境中。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
14.1 事务日志备份与恢复原理、本章要点† 事务日志备份与恢复原理† 尾日志备份† 产生备份集† 将数据库恢复到故障点† 备份恢复中的疑难问题一个不懂事务日志的DBA，是很难掌握数据库的精髓的。
事务日志忠实地记录了数据库的活动，所以基于这些记录的活动就可以随心所欲地将数据库的状态恢复到特定的即时点或恢复到故障点。
然而，不是每个DBA都能够正确完成这些操作的。
其中的奥秘在哪里呢？本章深入研究事务日志备份与恢复操作。
14.1 事务日志备份与恢复原理下面我们首先来学习事务日志备份与恢复的原理。
14.1.1 事务日志备份与恢复原理事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。
在简单模型下，事务日志有可能被破坏，所以事务日志备份可能不连续，不连续的事务日志备份没有意义，因为基于日志的恢复要求日志是连续的。
可以使用事务日志备份将数据库恢复到特定的即时点（如输入多余数据前的那一点）或恢复到故障点。
恢复事务日志备份时，SQL Server 2005重做事务日志中记录的所有更改。
当SQL Server 2005到达事务日志的最后时，已重新创建了与开始执行备份操作的那一刻完全相同的数据库状态。
如果数据库已经恢复，则SQL Server 2005将回滚备份操作开始时尚未完成的所有事务。
一般情况下，事务日志备份比数据库备份使用的资源少。
因此可以比数据库备份更经常地创建事务日志备份。
经常备份将减少丢失数据的危险。
图14-1所示为基于完全恢复模型下的1个完全备份＋N个连续的事务日志备份的策略。
如果中间的日志备份02删除或者损坏，则数据库只能恢复到日志备份01的即时点。
图14-1 事务日志备份与恢复原理假如日志备份01、02和03都是完整的，那么在恢复时，先恢复数据库完全备份，然后依次恢复日志备份01、02和03。
如果要恢复到故障点，就需要看数据库的当前日志是否完整，如果是完整的，可以做一个当前日志的备份，然后依次恢复日志备份04就可以了。
基于事务日志的备份还可以恢复到某个日志备份中间的时刻，称为时点恢复。
比如我们可以在恢复数据库完全备份后，恢复数据库在完全备份和日志备份01中间的某个时刻，这就是时点恢复。
这里的时点必须是合法的（看日志备份的时间），而不能超出日志备份的时间序列，否则系统不会执行。
比如现在只有日志备份01，其时刻为12:11，假如我们指定恢复到12:12，那么这样的时点是非法的。
14.1.2 事务日志备份连续的奥秘连续的事务日志备份是备份和恢复事务日志的基本要求。
那么，什么样的事务日志备份是连续的呢？LSN（日志序列号）是用于衡量事务日志备份是否连续的基本方法。
1．连续的事务日志备份当我们通过备份操作形成备份后，我们可以执行restore headeronly语句来查看备份集中的事务日志备份，判断其是否连续。
restore headeronly from disk='c:\test2.bak'查看的结果如图14-2所示。
我们可以得出结论：该事务日志备份序列是连续的！为什么呢？因为这些事务日志备份的LSN首尾连接，后一个日志备份的FirstLSN等于前一个日志备份的LastLSN。
—日志备份（编号2）：FirstLSN：290179，LastLSN：290001。
—日志备份（编号3）：FirstLSN：290001，LastLSN：300001。
—日志备份（编号4）：FirstLSN：300001，LastLSN：300001。
图14-2 实例的事务日志备份序列因为根据这3个日志备份序列，它记录的事务日志起点是第1个日志备份的FirstLSN：290179。
终点是最后一个日志备份的LastLSN：300001。
光盘视频：\视频\1402.exe（连续的事务日志备份）。
2．不连续的事务日志备份不连续的日志备份就是指在产生的日志备份序列中，出现了前后首尾不能续接的情况。
这种情况主要发生在初学或者刚开始做DBA的读者身上，不断切换数据库的恢复模型，比如从简单恢复模型切换到完全恢复模型，或者从完全恢复模型切换到大容量日志记录模型，这都是DBA的大忌！假如你的日志备份出现下列情况。
那么，这样的日志序列LSN首尾不能衔接，无法连接起来执行恢复操作！—日志备份（编号2）：FirstLSN：290179，LastLSN：290001。
—日志备份（编号3）：FirstLSN：300001，LastLSN：300001。
提示：DBA一定要千方百计确保当前日志和日志备份序列的安全，同时还要保证日志序列的完整，判断是否完整的方法就是执行restore headeronly语句。
14.1.3 恢复到即时点的奥秘正是因为有了连续的、完整的事务日志备份序列，配合一个完整数据库备份，我们可以将数据库的状态恢复在日志序列中间的任意一个即时点。
但是，这样做是有前提条件的。
1．正确的完整数据库备份首先，必须要有一个正确的完整数据库备份，为什么这里要强调“正确”二字呢？如果读者已经对事务日志的连续性概念有正确认识和理解的话，那么这里的“正确”二字就代表完整数据库备份必须是在第1个日志备份序列的时间点之间完成的。
本书配套光盘收录了一个bak备份文件，包括了1个完整数据库备份和3个连续的事务日志备份，我们看到编号为1的是完整数据库备份，其余3个是事务日志备份。
如图14-3所示。
图14-3 正确的完整数据库备份完整数据库备份的日志区间是：290179～290001。
第1个事务日志备份的区间是：290179～290001。
所以，这里的完整数据库备份就是正确的，因为恢复完整数据库备份，其状态会停留在事务日志备份1中间的某个即时点。
然后可以连续执行事务日志备份来进行恢复。
什么是不正确的完整数据库备份呢？就是完整数据库备份完成的即时点处于日志备份序列之外。
如图14-4所示。
图14-4 事务日志备份与恢复原理提示：永远也不能指望停留在日志备份之外，即时点的完整数据库备份和日志备份能够配合起来进行恢复，因为完整数据库备份和日志备份的日志序列之间产生了中断。
我们可以把这个过程理解为火车的工作机制。
火车头（完整数据库备份）和车厢（日志备份序列）之间首尾相接，所以我们可以从头走到尾。
如果车头和车厢之间发生断裂（不正确的完整数据库备份），我们就只能开走火车头了（将数据库恢复到完整数据库备份完成的即时点）！同样，如果车厢之间发生断裂（事务日志备份序列断裂），我们就只能走到相连接的部分（恢复连续的日志备份序列），其余部分没有任何意义！2．正确的即时点这句话的含义是，永远不要指望将数据库的状态恢复到日志序列记录的LSN区间之外！这很好理解，因为LSN没有记录的数据库活动，数据库的恢复机制无凭无据，如何恢复？14.1.4 恢复到故障点的奥秘无论我们翻阅SQL Server 2005的联机丛书，还是我们查阅有关的资料，都会告诉我们：SQL Server 2005拥有将数据库恢复到故障点的能力！然而，很遗憾的是，没有一本图书好好地告诉我们作者是如何将数据库恢复到故障点的！我们首先从原理上来理解恢复到故障点的奥秘，如图14-5所示。
图14-5 恢复到故障点的奥秘从图中我们可以看出，要将数据库恢复到故障点，必须满足3个条件。
1．正确的完整数据库备份这个很好理解，而且DBA一般都会做。
2．连续的事务日志备份序列除非存储设备出现故障，否则这个问题也很好解决。
3．正确备份最后一个日志备份和故障点之间的日志这一点在目前的SQL Server 2005的图书中几乎没有提到！稍微有点实际经验的DBA （这里是指真正从事大型数据库管理的DBA），肯定会意识到这个问题的严重性！如果我们按照目前的市面上的其他图书去操作，当某个故障发生的时候，我们永远无法将数据库恢复到故障点，因为我们最多只能将数据库恢复到最后一个日志备份完成的时刻，那么，在最后一个日志备份完成的时刻到故障点之间的日志呢？等待DBA的将是被老板炒鱿鱼的悲惨命运！提示：要想将数据库恢复到故障点，就必须深刻理解SQL Server 2005的尾日志备份的原理。
很显然，我们必须将这一段特殊的日志（最后日志备份完成时刻～故障点发生时刻）备份下来，从而使从完整数据库备份时刻到故障点时刻的所有日志备份序列是完整的！如图1 4-6所示。
图14-6 尾日志备份14.1.5 尾日志备份因此，要想完成故障点的恢复，就必须完成尾日志的备份。
接下来我们就来学习尾日志的相关话题。
1．尾日志的存储首先一个问题，尾日志存储在哪里？很显然，答案是当前的日志文件中。
当前日志文件保存的内容包括了最后一个成功的日志备份到当前故障点所有的事务。
所以，一旦最后一个日志文件备份和故障点之间数据库的日志文件不幸发生介质故障，比如存放日志文件的硬盘损坏，那么这种情况下，上帝也无法挽救一个DBA的命运！由此可以看出，日志文件对数据库，对DBA的重要性！所以如果无法完成尾日志备份，则只能将数据库恢复到创建最后一个事务日志备份时的点。
自上一次事务日志备份后对数据库所做的更改将丢失，必须手工重做。
2．与正常日志备份的区别与正常日志备份相似，尾日志备份将捕获所有尚未备份的事务日志记录。
但尾日志备份与正常日志备份在下列几个方面有所不同。
—如果数据库损坏或离线，则可以尝试进行尾日志备份。
仅当日志文件未损坏且数据库不包含任何大容量日志更改时，尾日志备份才会成功。
如果数据库包含要备份的、在记录间隔期间执行的大容量日志更改，则仅在所有数据文件都存在且未损坏的情况下，尾日志备份才会成功。
—尾日志备份可使用COPY_ONLY选项独立于定期日志备份进行创建。
仅复制备份不会影响备份日志链。
事务日志不会被尾日志备份截断，并且捕获的日志将包括在以后的正常日志备份中。
这样就可以在不影响正常日志备份过程的情况下进行尾日志备份，例如，为了准备进行在线还原。
—如果数据库损坏，则尾日志可能会包含不完整的元数据，这是因为某些通常可用于日志备份的元数据在尾日志备份中可能会不可用。
使用CONTINUE_AFTER_ ERROR进行的日志备份可能会包含不完整的元数据，这是因为此选项将通知进行日志备份而不考虑数据库的状态。
14.2 尾日志备份对于将数据库恢复到即时点，很好理解也很好操作。
下面我们重点来研究将数据库恢复到故障点时必不可少的操作，即尾日志备份。
但是，需要注意的是，如果在Management Studio中按照默认设置是永远无法完成尾日志备份的。
14.2.1 图形化尾日志备份操作图14-7所示为选择日志备份的数据库的【选项】选项卡。
默认情况下选择的是【截断事务日志】单选按钮，这样将永远无法备份尾日志。
提示：要完成尾日志备份，需要在图14-7中选择“备份日志尾部，并使数据库处于还原状态”选项。