数据库备份恢复策略
 
 介绍 (Introduction)
 
 
 Following best practices, we should apply principles like segregation of duties. This implies the segregation of application environments. In particular, we might see for a given application that it incorporates at least two environments: a production environment and a non-production environment that exists for testing, Q/A, training, etc 
 
 遵循最佳实践，我们应该应用诸如职责分工之类的原则。 这意味着应用程序环境的隔离。 特别是，对于给定的应用程序，我们可能会看到它至少包含两个环境：生产环境和用于测试，Q / A，培训等的非生产环境 
 
 
 The value we give to each of these environments could be different, depending on multiple factors. For that reason, amongst other aspects, we won’t apply the same backups for each of these environments. For instance, the default strategy for production databases could be to take a FULL backup every night and a log backup every 3 hours. In contrast, we could decide that we won’t take backups at all for non-production environments except those related to development tasks. For these development databases, we could take a FULL backup once a week (but it should be more frequently). 
 
 
 我们为这些环境提供的价值可能会有所不同，具体取决于多个因素。 因此，除其他方面外，我们不会为每个环境都应用相同的备份。 例如，生产数据库的默认策略可能是每晚进行一次完整备份，每3小时进行一次日志备份。 相反，我们可以决定，除了与开发任务相关的环境以外，对于非生产环境完全不备份。 对于这些开发数据库，​​我们可以每周进行一次完整备份（但应该更频繁）。 
 
 
 Depending on the need for backup operations, we should adjust the Recovery Model option of each database so that we are able to only do the expected operations and there is no side effect with this setting. Let me explain. 
 
 
 根据备份操作的需要，我们应该调整每个数据库的“ 恢复模型”选项，以便我们只能执行预期的操作，并且此设置没有副作用。 让我解释。 
 
 
 In order to take a LOG backup for a given database, we need to define its recovery model either to FULL or BULK_LOGGED. 
 
 
 为了对给定的数据库进行LOG备份，我们需要将其恢复模型定义为FULL或BULK_LOGGED 。 
 
 
 Let’s prove this assumption simply by taking a database called [testJEL] which is in SIMPLE recovery model: 
 
 
 让我们简单地通过采用SIMPLE恢复模型中的[testJEL]数据库来证明这一假设： 
 
 
 
 

  
 
 
 
 Using SQL Server Management Studio (SSMS), let’s try to take a LOG backup for that database. 
 
 
 使用SQL Server Management Studio（SSMS），让我们尝试对该数据库进行LOG备份。 
 
 
 
 

  
 
 
 
 We can see that the LOG backup type is not on the list… 
 
 
 我们可以看到LOG备份类型不在列表中…… 
 
 
 
 

  
 
 
 
 So, for environments where LOG backups are mandatory, we should ensure that databases are not in SIMPLE recovery model. 
 
 
 因此，对于必须进行LOG备份的环境，我们应确保数据库不在SIMPLE恢复模型中。 
 
 
 But that’s not all! What happens if there are databases set with FULL recovery model in an environment which is not backed up? It’s pretty easy to understand that, sooner or later, either the transaction log or file system hosting this transaction log will be full. 
 
 
 但这还不是全部！ 如果在没有备份的环境中设置了FULL恢复模型的数据库会怎样？ 很容易理解，迟早，托管该事务日志的事务日志或文件系统将已满。 
 
 
 To prevent it from happening, we should ensure that every database in such an environment uses the SIMPLE recovery model. 
 
 
 为了防止发生这种情况，我们应该确保在这种环境中的每个数据库都使用SIMPLE恢复模型。 
 
 
 This article will present a solution that monitors if the recovery model for each database on a given SQL Server instance is adequate with the backup policy defined for that server. 
 
 
 本文将提供一种解决方案，该解决方案监视给定SQL Server实例上每个数据库的恢复模型是否适合为该服务器定义的备份策略。 
 
 
 To do so, we will first define some pretty common software environments and the backup policy that should be applied. Once it’s done, we will define a (simple) way to keep track of current server’s environment. Then, we will discuss a stored procedure that we will use in order not only to detect abnormal database settings (regarding its recovery model) but also to correct them. 
 
 
 为此，我们将首先定义一些非常常见的软件环境以及应应用的备份策略。 完成后，我们将定义一种（简单的）方法来跟踪当前服务器的环境。 然后，我们将讨论一个存储过程，该过程将不仅用于检测异常的数据库设置（关于其恢复模型），还用于纠正它们。 
 
 
 定义环境和示例备份策略 (Defining environments and a sample backup policy)
 
 
 Here is a table with some common environments and an example backup policy. 
 
 
 这是带有一些常见环境的表以及一个备份策略示例。 
 
 
 In summary, with this kind of backup policy, only production environments should be using a recovery model different from SIMPLE. 
 
 
 总之，使用这种备份策略，仅生产环境应使用不同于SIMPLE的恢复模型。 
 
 
 如何跟踪服务器环境变量 (How to keep track of server environment variables)
 
 
 In the most standardized environments, we might use different drive letters. For instance, we could use the D:\ drive for system databases, the P:\ drive for actual production ones and the E:\ drive for non-production data. But it’s not an absolute rule that everybody can use… 
 
 
 在最标准化的环境中，我们可能使用不同的驱动器号。 例如，我们可以将D：\驱动器用于系统数据库，将P：\驱动器用于实际生产数据库，将E：\驱动器用于非生产数据。 但这不是每个人都可以使用的绝对规则。 
 
 
 For that reason, we will keep it simple and store this information in a table, in a database dedicated to DBA tasks and tools. This table should help to answer two questions: 
 
 
 因此，我们将使其保持简单，并将此信息存储在专用于DBA任务和工具的数据库的表中。 该表应有助于回答两个问题： 
 
 
 which environment are we in? 
 我们在哪个环境中？ 
 which databases should I ignore? (i.e. which databases are considered as system databases) 
 我应该忽略哪些数据库？ （即哪些数据库被视为系统数据库） 
 
Storage description
 
 
 储存说明 
 
 
 We will use a table called [Common].[ApplicationParams] that I already introduced in an article entitled How to report on SQL Server deadlock occurrences. As indicated by its name, it’s a table that holds parameters for applications. Here is its structure: 
 
 
 我们将使用名为[Common]。[ApplicationParams]的表，该表已经在标题为“ 如何报告SQL Server死锁事件”的文章中介绍过。 顾名思义，它是一个表，其中包含应用程序的参数。 这是它的结构： 
 
 
 
[ApplicationName]   [varchar](128)  NOT NULL,
[ParamName]         [varchar](64)   NOT NULL,
[ParamValue]        [varchar](max),
[DefaultValue]      [varchar](max),
[ValueCanBeNULL]    [bit]           DEFAULT 0 NOT NULL,
[isDepreciated]     [bit]           NOT NULL,
[ParamDescription]  [varchar](max)  NULL,
[creationdate]      [datetime]      NOT NULL,
[lastmodified]      [datetime]      NOT NULL
 

 
 Its primary key is defined using [ApplicationName] and [ParamName] columns. You will find the code for this stored procedure in the Downloads section at the end of this article. 
 
 
 它的主键是使用[ApplicationName]和[ParamName]列定义的。 您可以在本文结尾的“ 下载”部分中找到此存储过程的代码。 
 
 
 This table comes with a stored procedure called Common.getApplicationParam that will return the value for a given application parameter. The code to create this stored procedure will also be attached to this article. 
 
 
 该表带有一个称为Common.getApplicationParam的存储过程，该存储过程将返回给定应用程序参数的值。 创建此存储过程的代码也将附在本文中。 
 
 
 Now we have a place to store the information, it’s time to define how this information will be stored. This, once again, will be pretty simple. We will actually define an application whose name is built based on two server properties which are: 
 
 
 现在我们有了一个存储信息的地方，该定义该信息的存储方式了。 再次，这将非常简单。 我们实际上将定义一个应用程序，该应用程序的名称基于两个服务器属性构建： 
 
 
 ServerName 
 服务器名称 
 InstanceName 
 实例名称 
 
 So, the value for ApplicationName column will be defined using following query: 
 
 
 因此，将使用以下查询定义ApplicationName列的值： 
 
 
 
select 
    @ApplicationName = CAST(
                           SERVERPROPERTY('ServerName') 
                       AS VARCHAR(256)) + 
                       CASE 
                           WHEN SERVERPROPERTY('InstanceName') IS NULL 
                               THEN '' 
                           ELSE  CHAR(92) /* backslash*/ + 
                                 CAST(
                                     SERVERPROPERTY('InstanceName') 
                                 AS VARCHAR(256)) 
    END
;
 

 
Storage of the information regarding software environment
 
 
 存储有关软件环境的信息 
 
 
 The parameter corresponding to the software environment will be called “Environment”. 
 
 
 与软件环境相对应的参数将称为“环境”。 
 
 
 Now, we just need to insert a record in that table using following query template: 
 
 
 现在，我们只需要使用以下查询模板在该表中插入一条记录： 
 
 
 
INSERT INTO Common.ApplicationParams (
    ApplicationName, ParamName, ParamValue, 
    DefaultValue, ValueCanBeNULL, isDepreciated,
    ParamDescription
)
VALUES (
    @ApplicationName, 'Environment','CHANGEME','CHANGEME',
    0,0,'Defines the software environment in which this server is'
)
 

 
Storage of the information regarding database exclusion list
 
 
 存储有关数据库排除列表的信息 
 
 
 We will simply use the same pattern as above but the value for ParamName column will be called “SystemDatabases” and the value of ParamValue column will be a comma separated list containing at least following databases: 
 
 
 我们将简单地使用与上述相同的模式，但是ParamName列的值将被称为“ SystemDatabases”，而ParamValue列的值将是一个逗号分隔的列表，其中至少包含以下数据库： 
 
 
 master 
 主 
 msdb 
 数据库 
 model 
 模型 
 tempdb 
 临时数据库 
 <Your DBA Toolkit database> 
 <您的DBA Toolkit数据库> 
 
Security concerns
 
 
 安全问题 
 
 
 There is an important thing to notice about this solution: it highly depends on the contents of Common.ApplicationParams table. One could modify this value without notifying you about this… For that reason, consider adding triggers that disallow the changes to these parameters or that keep track of any modification in that table, or both of them! 
 
 
 关于此解决方案，有一件重要的事情要注意：它高度依赖于Common.ApplicationParams表的内容。 可以在不通知您的情况下修改此值...出于这个原因，请考虑添加不允许更改这些参数或跟踪该表中的任何修改或两者的触发器！ 
 
 
 核对存储过程的设计 (Design of the checkup stored procedure)
 
 
 In this section, we will use the Common.ApplicationParams and its records discussed above. We will call this stored procedure [Administration].[CheckRecoveryModelToEnvAdequation]. It will be able to run in 3 modes: 
 
 在本节中，我们将使用上面讨论的Common.ApplicationParams及其记录。 我们将这个存储过程称为[Administration]。[CheckRecoveryModelToEnvAdequation] 。 它将能够在3种模式下运行： 
 
 
Report – an interactive mode that sums up databases that do not comply to the rules we defined. 报告 –一种交互式模式，用于汇总不符合我们定义的规则的数据库。 
Monitoring – designed to fail if any non-compliant database is found. Ideal for a SQL Server Agent Job with enabled notification when the job fails. 监视 –旨在在发现任何不兼容的数据库时失败。 当作业失败时启用通知SQL Server代理作业的理想选择。 
Correct – finds the databases that do not comply with the rules we defined, tries to set enforce compliance and reports about its execution. This mode will need a parameter that allow user to set a default recovery model to use in case of non-conformity. 正确 –查找不符合我们定义的规则的数据库，尝试设置强制性合规性并报告其执行情况。 此模式将需要一个参数，该参数允许用户设置默认恢复模型以在不合格的情况下使用。 
 
Note: We could also add other checks, like checking all databases uses CHECKSUM page verification, which we did using a parameter called @WithPageVerifyCheck. 
 
 
 注意 ：我们还可以添加其他检查，例如检查所有数据库都使用CHECKSUM页面验证，我们使用名为@WithPageVerifyCheck的参数进行了验证。 
 
 
 In summary, here is the interface for our stored procedure: 
 
 
 总而言之，这是存储过程的接口： 
 
 
 
ALTER PROCEDURE [Administration].[CheckRecoveryModelToEnvAdequation] (
    @ExecutionMode                  VARCHAR(64)  = 'REPORT', 
    -- Possible values: REPORT, MONITORING, CORRECT
    @WithPageVerifyCheck            BIT          = 1,
    @DefaultRecoveryMode4Production VARCHAR(256) = 'FULL',
    @Debug                          SMALLINT     = 0
)
 

 
 Its algorithm is pretty straight forwards: 
 
 
 它的算法非常简单： 
 
 
 Check parameters are valid 
 检查参数是否有效 
 Get back environment related information from Common.ApplicationParams table 
 从Common.ApplicationParams表中获取与环境相关的信息 
 Transform the comma-separated value for SystemDatabases parameter to a string that can be used in a dynamic T-SQL query
 This means:
   
Adding leading simple quote
Replacing any occurrence of comma character to escaped ‘,’
Adding trailing simple quote
 
 将SystemDatabases参数的逗号分隔值转换为可在动态T-SQL查询中使用的字符串 
 这表示： 
   
 添加前导简单报价 
 将任何出现的逗号替换为'，' 
 添加尾随简单报价 
 
 Create a temporary table #dbs 
 创建一个临时表#dbs 
 Build a dynamic T-SQL query that stores into #dbs temporary table 
 构建一个动态T-SQL查询，该查询存储到#dbs临时表中 
 Run this dynamic query 
 运行此动态查询 
 Take appropriate action depending on the value for @ExecutionMode parameter
   
If ‘MONITORING’ -> Fail if #dbs table has records
If ‘REPORT’ -> Return records in #dbs table
Else -> Loop on each record in #dbs table and try to solve the problem. Then show execution report
 根据@ExecutionMode参数的值采取适当的措施 
   
 如果'MONITORING' ->如果#dbs表包含记录，则失败 
 如果为'REPORT' ->返回#dbs表中的记录 
 否则->在#dbs表中的每个记录上循环并尝试解决该问题。 然后显示执行报告 
 
 
 You will find below part of the code for the operation 7.c: 
 
 
 您将在下面的代码7.c中找到部分操作： 
 
 
 
WHILE (1 = 1) /* in order to simulate a DO … WHILE*/
BEGIN
    SET @CurrentDbName  = NULL;
    SET @tsql           = NULL;
    SET @CurOutcome     = NULL;
    
    SELECT TOP 1 
        @CurrentDbName = DatabaseName,
        @tsql          = CorrectiveStatement
    FROM #dbs 
    WHERE CorrectionOutcome IS NULL
    ;
    
    IF(@CurrentDbName IS NULL) /* = Loop Condition */
    BEGIN
        BREAK;
    END;
    
    BEGIN TRY 
        EXEC @ExecRet = sp_executesql @tsql ;
        IF(@ExecRet <> 0) /* Check success*/
        BEGIN
            RAISERROR('An error occurred …',12,1);
        END;
        
        SET @CurOutcome = 'SUCCESS';
    END TRY
    BEGIN CATCH 
        SELECT 
            @ErrorNumber    = ERROR_NUMBER(),
            @ErrorLine      = ERROR_LINE(),
            @ErrorMessage   = ERROR_MESSAGE(),
            @ErrorSeverity  = ERROR_SEVERITY(),
            @ErrorState     = ERROR_STATE()
        ;
     
        /* Keep track of error message in @LogMsg */
        
        SET @CurOutcome = 'ERROR';
    END CATCH ;
    /* To be able to get out of this infinite loop! */
    UPDATE #dbs 
    SET 
        CorrectionOutcome = @CurOutcome,
        CorrectionLog     = @LogMsg 
    WHERE DatabaseName = @CurrentDbName
    ;
END;
 

 
 The T-SQL code to create the [Administration].[CheckRecoveryModelToEnvAdequation] stored procedure can be found in the ZIP file attached at the end of this article. 
 
 
 可在本文末尾的ZIP文件中找到用于创建[Administration]。[CheckRecoveryModelToEnvAdequation]存储过程的T-SQL代码。 
 
 
 Let’s run this stored procedure against a SQL Server instance which has one non-compliant database: 
 
 
 让我们针对具有一个不兼容数据库SQL Server实例运行此存储过程： 
 
 
In REPORT mode:
 
 在报告模式下： 
 
 
   

    
   
 
 
  
 
In MONITORING mode:
 
 在监视模式下： 
 
 
   

    
   
 
 
  
 
In CORRECT mode:
 
 在正确模式下： 
 
 
   

    
   
 
 
  
 
 
 自动执行程序 (Automating procedure execution)
 
 
 The [Administration].[CheckRecoveryModelToEnvAdequation] stored procedure won’t run without being called. We need a process that will call it regularly. To do so, we could create a PowerShell script that uses Invoke-SQLCmd commandlet and schedule it using Windows Tasks Scheduler… Or, we could create a SQL Server Job as SQL Server Agent is very handy! 
 
 
 如果不调用[Administration]。[CheckRecoveryModelToEnvAdequation]存储过程，则该过程将不会运行。 我们需要一个可以定期调用的过程。 为此，我们可以创建一个使用Invoke-SQLCmd Commandlet的PowerShell脚本，并使用Windows Tasks Scheduler对其进行调度……或者，因为SQL Server代理非常方便，所以我们可以创建一个SQL Server Job！ 
 
 
 Here is the procedure for the creation of a SQL Server Agent Job called “[Administration] Check Database Recovery Model”. 
 
 
 这是创建名为“ [Administration] Check Database Recovery Model”SQL Server代理作业的过程。 
 
 
Note: The following procedure assumes that a Database Mail Operator “The DBA Team” has already In SQL Server Management Studio (SSMS), connect to a SQL Server instance. 
 
 
 注意 ：以下过程假定数据库邮件操作员“ DBA团队”已经在SQL Server Management Studio（SSMS）中连接到SQL Server实例。 
 
 
 Go down to SQL Server Agent Node and expend it. 
 转到“ SQL Server代理节点”并扩展它。 
Right-click on Jobs node and select New Job.
 
 右键单击Jobs节点，然后选择New Job 。 
 
 
   

    
   
 
 
This opens a New Job dialog. Fill in the General step then go to the Page step.
 
 这将打开“ 新作业”对话框。 填写常规步骤，然后转到页面步骤。 
 
 
   

    
   
 
 
Click on the New button at the bottom. It will open a dialog called New Job Step.
 
 单击底部的“ 新建”按钮。 它将打开一个名为New Job Step的对话框。 
 
 
   

    
   
 
 
Fill in the General step as follows and go to the “Advanced” page.
 
 按照以下步骤填写“ 常规”步骤，然后转到“高级”页面。 
 
 
   

    
   
 
 
Select the “Include step output in history” checkbox then click on the “OK” button.
 
 选中“将步骤输出包括在历史记录中”复选框，然后单击“确定”按钮。 
 
 
   

    
   
 
 
Create a dedicated schedule. Choose to preferably run it once a day. For instance:a.
 
 创建一个专用的时间表。 选择最好每天运行一次。 例如： 
 
 
   

    
   
 
 
The most important part now, set the job to notify a Database Mail operator when it fails:
 
 现在，最重要的部分是，将作业设置为在失败时通知数据库邮件操作员： 
 
 
   

    
   
 
 
OK button and the job is created. 确定按钮，然后创建作业。 
 Test Job Execution 
 测试作业执行 
 
 资料下载 (Downloads)
 
 
 You’ll find all resources to implement this check on your SQL Server boxes using following link: 
 
 
 您将使用以下链接在SQL Server框中找到实现此检查的所有资源： 
 
 
All scripts bundle所有脚本包 
 
 In order to install it, open scripts one by one following ascending numbering (from 01 to 06). Be aware that the sixth file requires manual intervention for you to define both server environment and databases that should be ignored. 
 
 
 为了安装它，请按照升序编号（从01到06）一一打开脚本。 请注意，第六个文件需要手动干预才能定义服务器环境和应忽略的数据库。 
 
 
 参考资料 (References)
 
 
Recovery Models (SQL Server) 恢复模型（SQL Server） 
How to: Create a Job (SQL Server Management Studio) 如何：创建作业（SQL Server Management Studio） 
SERVERPROPERTY (Transact-SQL) 服务器属性（Transact-SQL） 
 

  
翻译自: https://www.sqlshack.com/how-to-choose-and-check-the-right-database-recovery-model-in-accordance-to-your-backup-strategy/
 
 
数据库备份恢复策略

 
 

  
　　数据库备份和恢复技术是数据库系统维护工作中的重要技术，不论是开发测试环境的数据库，还是生产环境的数据库，都要进行备份，而且要确保备份文件可用。对于数据库系统来说，当发生故障甚至是灾难性的故障的时候，数据库备份就是最有效的最后一道防线。对于数据中心运维人员来说，备份与恢复技术的熟练运用，加之规范性的操作，是企业数据中心的数据库系统正常运行的重要保障。
  
　　创建 Oracle 备份的目的是为了可以恢复已损坏的数据库。但是，备份和还原数据必须根据特定环境进行自定义，并且必须使用可用资源。因此，可靠使用备份和还原以实现恢复需要有一个备份和还原策略。设计良好的备份和还原策略在考虑到特定业务要求的同时，可以尽量提高数据的可用性并尽量减少数据的丢失。
  
　　设计备份与恢复策略
  
　　设计有效的备份和恢复策略需要仔细计划、实现和测试。测试是必需环节。直到成功还原了还原策略中所有组合内的备份后，才会生成备份策略。必须考虑各种因素。其中包括：
  
　　您的组织对数据库的生产目标，尤其是对可用性和防止数据丢失的要求。
  
　　每个数据库的特性，包括：大小、使用模式、内容特性以及数据要求等。
  
　　对资源的约束，例如：硬件、人员、备份媒体的存储空间以及所存储媒体的物理安全性等。
  
　　设计备份和还原计划时，应根据自身的特定环境和业务需求来考虑灾难恢复计划。例如：假如出现故障，是否有把握恢复数据?恢复系统并保证系统运行需要多长时间?用户能够承受丢失多少数据?
  
　　理想的情况是，灾难恢复计划应规定恢复所需的时间以及用户可以期望的最终数据库状态。例如，可以确定在获取指定的硬件后，在特定时间内内完成恢复，并且保证最多能恢复到某个特点时间点的数据。
  
　　灾难恢复计划可以通过多种方式构建，并且可以包含各种类型的信息。灾难恢复计划类型包括：
  
　　获取硬件计划。
  
　　通信计划。
  
　　发生灾难时的联系人名单。
  
　　与负责处理灾难的人员的联系方式。
  
　　对计划拥有管理权的人员的信息。
  
　　每个恢复方案所需执行的任务的清单。为了便于您检查灾难恢复的进度，将初始化已完成的任务，并在清单中指示任务完成时间。
  
　　以下是使用的数据库进行备份、恢复的计划：
  
　　1) 用户数据库
  
　　生产环境的用户数据库是企业的重要数据资源，必须根据企业的要求采取严密的数据库备份恢复策略。按照以下原则设计生产环境用户数据库的备份恢复策略：
  
　　完全备份
  
　　每天一次，如果数据库特别大，可考虑进行文件组备份，或者适当减少备份频率。
  
　　差异备份
  
　　每4小时一次，如果数据库事务特别频繁，可考虑取消差异备份，用日志备份代替。
  
　　日志备份
  
　　每15分钟一次，可以根据实际数据库的事务量适当调整。
  
　　以上备份的保留时间原则上本地至少保留一周，根据企业实际需求可以适当调整。根据某些数据库高可用架构的特点，可以适当调整以上备份策略，例如：
  
　　当存在LogShipping架构使用的时候，就需要取消相应库的日志备份;
  
　　当整体数据库系统或者某局部数据库系统是完全的分布式架构的时候，不必在每个数据库服务器都设置备份计划，而仅需在架构中的关键位置设计即可。
  
　　2) 系统数据库
  
　　系统数据库为用户数据库功能的正常运行提供了必要的基础环境，因此系统数据库必须采取必要的备份，尤其是master,msdb数据库。
  
　　按照以下原则设计生产环境中系统数据库的备份策略：
  
　　完全备份
  
　　每天一次，备份至少保留一个月
  
　　异地备份
  
　　设置异地备份是设计整个灾难恢复计划的重要步骤，“异地”主要是按照物理服务器所处位置决定的，可分为同机房，同城，异城。按照以下原则设计生产环境中异地备份策略：
  
　　采用拷贝或者其他同步工具软件
  
　　采用数据库技术，日志传送
  
　　3) 恢复计划
  
　　对于每一个备份计划都要知道相应的恢复计划，对于整体数据库系统，也有必要制定灾难性恢复计划。
  
　　4) 恢复或者切换演练
  
　　生产环境部署测试完毕后，要根据系统实际运行情况制定恢复和切换的演练策略，比如2周进行一次。
  
　　深圳木浪科技旗下多备份(dbfen.com)作为国内首家专注于企业、APP、网站数据云端备份、恢复、迁移、存储和归档的云平台(SaaS)应用提供商，在全球部署超过20个服务节点，备份数据超过P级，备份数据类型包括结构化数据(数据库类型如MySQL\Oracle\MS SQL Server\PostgreSQL\)和非结构化数据(文档类：pdf/doc/ppt/xlsx/zip等，目录类，多媒体类：图片、视频、音频等，镜像文件、各类应用程序)。提供上TB的数据单次备份能力，并能根据备份对象特点和所处的位置，采取智能化的数据传输优化通道，最优化提升备份性能。任何时候，当有需要时，可以通过多备份提供的一键下载功能下载加密后的备份数据或经过解密授权下载解密后的数据。
  


 
 
 
转载于:https://blog.51cto.com/9673367/1585462

　　主要介绍了Oracle数据库备份策略的相关概念及使用中的注意事项，详细内容请大家参考下文： 
 
　　一、了解备份的重要性 
 
　　可以说，从计算机系统出世的那天起，就有了备份这个概念，计算机以其强大的速度处理能力，取代了很多人为的工作，但是，往往很多时候，它又是那么弱不禁风，主板上的芯片、主板电路、内存、电源等任何一项不能正常工作，都会导致计算机系统不能正常工作。当然，这些损坏可以修复，不会导致应用和数据的损坏。但是，如果计算机的硬盘损坏，将会导致数据丢失，此时必须用备份恢复数据。 
 
　　其实，在我们的现实世界中，已经就存在很多备份策略，如RAID技术，双机热备，集群技术发展的不就是计算机系统的备份和高可用性吗？有很多时候，系统的备份的确就能解决数据库备份的问题，如磁盘介质的损坏，往往从镜相上面做简单的恢复，或简单的切换机器就可以了。 
 
　　但是，上面所说的系统备份策略是从硬件的角度来考虑备份与恢复的问题，这是需要代价的。我们所能选择备份策略的依据是：丢是数据的代价与确保数据不丢失的代价之比。还有的时候，硬件的备份有时根本满足不了现实需要，假如你误删了一个表，但是你又想恢复的时候，数据库的备份就变的重要了。Oracle本身就提供了强大的备份与恢复策略，这里我们只讨论ORACLE备份策略，以下的备份都是指Oracle数据库备份，恢复将放到下一讲中。 
 
　　所谓备份，就是把数据库复制到转储设备的过程。其中，转储设备是指用于放置数据库拷贝的磁带或磁盘。 
 
　　能够进行什么样的恢复依赖于有什么样的备份。作为 DBA，有责任从以下三个方面维护数据库的可恢复性： 
 
　　·使数据库的失效次数减到最少，从而使数据库保持最大的可用性； 
 
　　·当数据库不可避免地失效后，要使恢复时间减到最少，从而使恢复的效率达到最高； 
 
　　·当数据库失效后，要确保尽量少的数据丢失或根本不丢失，从而使数据具有最大的可恢复性。 
 
　　灾难恢复的最重要的工作是设计充足频率的硬盘备份过程。备份过程应该满足系统要求的可恢复性。例如，如果数据库可有较长的关机时间，则可以每周进行一次冷备份，并归档重做日志，对于24*7的系统，或许我们考虑的只能是热备份。 如果每天都能备份当然会很理想，但要考虑其现实性。企业都在想办法降低维护成本，现实的方案才可能被采用。只要仔细计划，并想办法达到数据库可用性的底线，花少量的钱进行成功的备份与恢复也是可能的。 
 
　　二、了解Oracle的运行方式 
 
　　ORACLE数据库有两种运行方式：一是归档方式（ARCHIVELOG），归档方式的目的是当数据库发生故障时最大限度恢复数据库，可以保证不丢失任何已提交的数据；二是不归档方式(NOARCHIVELOG)，只能恢复数据库到最近的回收点（冷备份或是逻辑备份）。我们根据数据库的高可用性和用户可承受丢失的工作量的多少，对于生产数据库，强烈要求采用为归档方式；那些正在开发和调试的数据库可以采用不归档方式。 
 
　　如何改变数据库的运行方式，在创建数据库时，作为创建数据库的一部分，就决定了数据库初始的存档方式。一般情况下为NOARCHIVELOG方式。当数据库创建好以后，根据我们的需要把需要运行在归档方式的数据库改成ARCHIVELOG方式。 
 
　　1、改变不归档方式为为归档方式 
 
　　a.关闭数据库，备份已有的数据，改变数据库的运行方式是对数据库的重要改动，所以要对数据库做备份，对可能出现的问题作出保护。 
 
　　b. 修改初试化参数，使能自动存档 
 
　　修改（添加）初始化文件init[SID].ora参数： 
 
　　log_archive_start=true #启动自动归档 
 
　　log_archive_format=ARC%T%S.arc #归档文件格式 
 
　　log_archive_dest=/arch12/arch #归档路径 
 
　　在8i中，可以最多有五个归档路径，并可以归档到其它服务器，如备用数据库(standby database)服务器 
 
　　c.启动Instance到Mount状态，即加载数据库但不打开数据库： 
 
　　$>SVRMGRL 
 
　　SVRMGRL >connect internal 
 
　　SVRMGRL >startup mount 
 
　　d.发出修改命令 
 
　　SVRMGRL >alter database archivelog; 
 
　　SVRMGRL>alter database open; 
 
　　2、改变归档状态为不归档状态 
 
　　与以上步骤相同，但有些操作不一样，主要是在以上的b操作中，现在为删除或注释该参数，在d操作中，命令为 
 
　　SVRMGRL >alter database noarchivelog; 
 
　　注意，从归档方式转换到非归档方式后一定要做一次数据库的全冷备份，防止意外事件的发生。 
 
　　三、Oracle备份的分类 
 
　　简单的按照备份进行的方式，可以分为逻辑备份、冷备份（脱机备份）、热备份（联机备份），其实冷备份与热备份又可以合称为物理备份 
 
　　按照备份的工具，可以分为EXP/IMP备份、OS拷贝、RMAN、第三方工具，如VERITAS 
 
　　以下我们将从多个角度来说明以上的各种备份方式 
 
　　1、EXP/IMP逻辑备份 
 
　　导入/导出是ORACLE幸存的最古老的两个命令行工具了，其实我从来不认为Exp/Imp是一种好的备份方式，正确的说法是Exp/Imp只能是一个好的转储工具，特别是在小型数据库的转储，表空间的迁移，表的抽取，检测逻辑和物理冲突等中有不小的功劳。当然，我们也可以把它作为小型数据库的物理备份后的一个逻辑辅助备份，也是不错的建议。 
 
　　对于越来越大的数据库，特别是TB级数据库和越来越多数据仓库的出现，EXP/IMP越来越力不从心了，这个时候，数据库的备份都转向了RMAN和第三方工具。下面我们还是简要介绍一下EXP/IMP的使用。 
 
　　i、使用方法 
 
　　Exp parameter_name=value 
 
　　Or Exp parameter_name=(value1,value2……) 
 
　　只要输入参数help=y就可以看到所有帮助 
 
　　如： 
 
　　C:/>set nls_lang=simplified chinese_china.zhs16gbk 
 
　　C:/>exp -help 
 
　　Export: Release 8.1.6.0.0 - Production on 星期四 4月 10 19:09:21 2003 
 
　　(c) Copyright 1999 Oracle Corporation. All rights reserved. 
 
　　 
 
　　通过输入 EXP 命令和用户名/口令，您可以 
 
　　在用户 / 口令之后的命令: 
 
　　 
 
　　实例: EXP SCOTT/TIGER 
 
　　或者，您也可以通过输入跟有各种参数的 EXP 命令来控制“导出” 
 
　　的运行方式。要指定参数，您可以使用关键字: 
 
　　 
 
　　格式: EXP KEYWORD=value 或 KEYWORD=(value1,value2,...,valueN) 
 
　　实例: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR) 
 
　　或 TABLES=(T1: P1,T1: P2)，如果 T1 是分区表 
 
　　USERID 必须是命令行中的第一个参数。 
 
　　关键字 说明（默认） 关键字 说明（默认） 
 
　　-------------------------------------------------------------------------- 
 
　　USERID 用户名/口令 FULL 导出整个文件 (N) 
 
　　BUFFER 数据缓冲区的大小 OWNER 所有者用户名列表 
 
　　FILE 输出文件 (EXPDAT.DMP) TABLES 表名列表 
 
　　COMPRESS 导入一个范围 (Y) RECORDLENGTH IO 记录的长度 
 
　　GRANTS 导出权限 (Y) INCTYPE 增量导出类型 
 
　　INDEXES 导出索引 (Y) RECORD 跟踪增量导出 (Y) 
 
　　ROWS 导出数据行 (Y) PARFILE 参数文件名 
 
　　CONSTRAINTS 导出限制 (Y) CONSISTENT 交叉表一致性 
 
　　LOG 屏幕输出的日志文件 STATISTICS 分析对象 (ESTIMATE) 
 
　　DIRECT 直接路径 (N) TRIGGERS 导出触发器 (Y) 
 
　　FEEDBACK 显示每 x 行 (0) 的进度 
 
　　FILESIZE 各转储文件的最大尺寸 
 
　　QUERY 选定导出表子集的子句 
 
　　下列关键字仅用于可传输的表空间 
 
　　TRANSPORT_TABLESPACE 导出可传输的表空间元数据 (N) 
 
　　TABLESPACES 将传输的表空间列表 
 
　　在没有警告的情况下成功终止导出。 
 
　　C:/> 
 
　　帮助已经很详细的说明了参数的意义和使用方法，并列举了几个简单的例子，注意的是，从8i开始，已经开始支持数据子集的方法，就是可以指定自己的Where条件，可以从表中导出一行或多行数据。 
 
　　注意上面的set nls_lang=simplified chinese_china.zhs16gbk，通过设置环境变量，可以让exp的帮助以中文显示，如果set nls_lang=American_america.字符集，那么你的帮助就是英文的了。 
 
　　增量和累计导出必须在全库方式下才有效，而且，大多数情况下，增量和累计导出并没有想象中的那么有效。ORACLE从9i开始，不再支持增量导出和累计导出。 
 
　　ii、表空间传输 
 
　　表空间传输是8i新增加的一种快速在数据库间移动数据的一种办法，是把一个数据库上的格式数据文件附加到另外一个数据库中，而不是把数据导出成Dmp文件，这在有些时候是非常管用的，因为传输表空间移动数据就象复制文件一样快。 
 
　　关于传输表空间有一些规则，即： 
 
　　·源数据库和目标数据库必须运行在相同的平台上。 
 
　　·源数据库与目标数据库必须使用相同的字符集。 
 
　　·源数据库与目标数据库一定要有相同大小的数据块（9i已经不用） 
 
　　·目标数据库不能有与迁移表空间同名的表空间 
 
　　·SYS的对象不能迁移 
 
　　·必须传输自包含的对象集 
 
　　·有一些对象，如物化视图，基于函数的索引等不能被传输 
 
　　可以用以下的方法来检测一个表空间或一套表空间是否符合传输标准： 
 
　　exec sys.dbms_tts.transport_set_check(‘tablespace_name’,true); 
 
　　select * from sys.transport_set_violation; 
 
　　如果没有行选择，表示该表空间只包含表数据，并且是自包含的。对于有些非自包含的表空间，如数据表空间和索引表空间，可以一起传输。 
 
　　以下为简要使用步骤，如果想参考详细使用方法，也可以参考ORACLE联机帮助。 
 
　　a.设置表空间为只读（假定表空间名字为APP_Data 和APP_Index） 
 
　　alter tablespace app_data read only; 
 
　　alter tablespace app_index read only; 
 
　　b.发出EXP命令 
 
　　SQL>host exp userid=”””sys/password as sysdba””” 
 
　　transport_tablespace=y tablespace=(app_data, app_index) 
 
　　以上需要注意的是 
 
　　·为了在SQL中执行EXP，USERID必须用三个引号，在UNIX中也必须注意避免“/”的使用 
 
　　·在816和以后，必须使用sysdba才能操作 
 
　　·这个命令在SQL中必须放置在一行（这里是因为显示问题放在了两行） 
 
　　c.拷贝数据文件到另一个地点，即目标数据库 
 
　　可以是cp(unix)或copy(windows)或通过ftp传输文件（一定要在bin方式） 
 
　　d.把本地的表空间设置为读写 
 
　　e.在目标数据库附加该数据文件 
 
　　imp file=expdat.dmp userid=”””sys/password as sysdba””” 
 
　　transport_tablespace=y 
 
　　“datafile=(c:/temp/app_data,c:/temp/app_index)” 
 
　　f.设置目标数据库表空间为读写 
 
　　alter tablespace app_data read write; 
 
　　alter tablespace app_index read write; 
 
　　iii、导出/导入与字符集 
 
　　明白ORACLE的多国语言设置，ORACLE多国语言设置是为了支持世界范围的语言与字符集，一般对语言提示，货币形式，排序方式和CHAR,VARCHAR2,CLOB,LONG字段的数据的显示等有效。ORACLE的多国语言设置最主要的两个特性就是国家语言设置与字符集设置，国家语言设置决定了界面或提示使用的语言种类，字符集决定了数据库保存与字符集有关数据（如文本）时候的编码规则。正如刚才上面的一个小例子，环境变量NLS_LANG的不同，导致EXP帮助发生变化，这就是多国语言设置的作用（NLS_LANG包含国家语言设置与字符集设置，这里起作用的是国家语言设置，而不是字符集）。 
 
　　ORACLE字符集设定，分为数据库字符集和客户端字符集环境设置。在数据库端，字符集在创建数据库的时候设定，并保存在数据库props$表中，对于8i以上产品，已经可以采用“Alter database character set 字符集”来修改数据库的字符集，但也仅仅是从子集到超集，不要通过update props$来修改字符集，如果是不支持的转换，可能会失去所有与字符集有关的数据，就是支持的转换，也可能导致数据库的不正常工作。字符集分为单字节字符集与多字节字符集，US7ASCII就是典型的单字节字符集，在这种字符集中length=lengthb，而ZHS16GBK就是常用的双字节字符集，在这里lengthb=2*length。 
 
　　在客户端的字符集环境比较简单，主要就是环境变量或注册表项NLS_LANG，注意NLS_LANG的优先级别为：参数文件à注册表à环境变量àalter session。NLS_LANG的组成为“国家语言设置.字符集”，如nls_lang=simplified chinese_china.zhs16gbk。客户端的字符集最好与数据库端一样（国家语言设置可以不一样，如zhs16gbk的字符集，客户端可以是nls_lang =simplified chinese_china.zhs16gbk或Ameircan_America.zhs16gbk，都不影响数据库字符的正常显示），如果字符集不一样，而且字符集的转换也不兼容，那么客户端的数据显示与导出/导入的与字符集有关的数据将都是乱码。 
 
　　使用一点点技巧，就可以使导出/导入在不同的字符集的数据库上转换数据。这里需要一个2进制文件编辑工具即可，如uedit32。用编辑方式打开导出的dmp文件，获取2、3字节的内容，如00 01，先把它转换为10进制数，为1，使用函数NLS_CHARSET_NAME即可获得该字符集： 
 
　　SQL> select nls_charset_name(1) from dual; 
 
　　NLS_CHARSET_NAME(1) 
 
　　------------------- 
 
　　US7ASCII 
 
　　可以知道该dmp文件的字符集为US7ASCII，如果需要把该dmp文件的字符集换成ZHS16GBK，则需要用NLS_CHARSET_ID获取该字符集的编号： 
 
　　SQL> select nls_charset_id('zhs16gbk') from dual; 
 
　　NLS_CHARSET_ID('ZHS16GBK') 
 
　　-------------------------- 
 
　　852 
 
　　把852换成16进制数，为354，把2、3字节的00 01换成03 54，即完成了把该dmp文件字符集从us7ascii到zhs16gbk的转化，这样，再把该dmp文件导入到zhs16gbk字符集的数据库就可以了。（注意，十进制数与十六进制之间的转换，想明白其中的道理） 
 
　　Iv、跨版本使用Exp/Imp 
 
　　Exp/Imp很多时候，可以跨版本使用，如在版本7与版本8之间导出导入数据，但这样做必须选择正确的版本，规则为： 
 
　　·总是使用IMP的版本匹配数据库的版本，如果要导入到816，则使用816的导入工具。 
 
　　·总是使用EXP的版本匹配两个数据库中低的那个版本，如在815与816之间互导，则使用815的EXP工具。 
 
　　2、OS备份 
 
　　操作系统备份有两类，冷备份（Cold backup）与热备份（Hot backup），操作系统备份与以上的逻辑备份有本质的区别。逻辑备份提取数据库的数据内容，而不备份物理数据块。而操作系统备份则是拷贝整个的数据文件。 
 
　　i、冷备份 
 
　　在文件级备份开始前数据库必须彻底关闭。关闭操作必须用带有normal、immediate、transaction选项的shutdown来执行。 
 
　　数据库使用的每个文件都被备份下来，这些文件包括： 
 
　　☆所有数据文件 
 
　　☆所有控制文件 
 
　　☆所有联机REDO LOG 文件 
 
　　☆INIT.ORA文件(可选) 
 
　　作冷备份一般步骤是： 
 
　　a.正常关闭要备份的实例(instance); 
 
　　b.备份整个数据库到一个目录 
 
　　c.启动数据库 
 
　　如 
 
　　SVRMGRL>connect internal 
 
　　SVRMGRL >shutdown immediate 
 
　　SVRMGRL >! cp 
 
　　或 
 
　　SVRMGRL >!tar cvf /dev/rmt/0 /u01/oradata/prod 
 
　　SVRMGRL >startup 
 
　　注意：如果利用脚本对数据库进行冷备份，必须对关闭数据库的命令进行逻辑检查，如果发生关闭数据库的命令不能正常执行而导致数据库没有正常关闭，那么，所有的冷备份将回是无效的。 
 
　　ii、热备份 
 
　　热备份是当数据库打开并对用户有效是的OS级的数据备份。热备份只能用于ARCHIVELOG方式的数据库。在数据文件备份之前，对应的表空间必须通过使用ALTER TABLESPACE …… BEGIN BACKUP以备份方式放置。然后组成表空间的数据文件可以使用类似冷备份的操作系统命令进行拷贝。在数据文件用操作系统命令拷贝后，应使用ALTER TABLESPACE …… END BACKUP命令使表空间脱离热备份方式。 
 
　　热备份没有必要备份联机日志，但必须是归档状态，在实例恢复的时候，可能需要用到归档日志。当前联机日志一定要保护好或是处于镜相状态，当前联机日志的损坏，对于数据库的损坏是巨大的，只能以数据的丢失来进行数据库的恢复工作。 
 
　　对于临时表空间，存放的是临时信息，在热备份是也可以考虑不用备份，如果临时文件发生故障，可以删除该数据文件与表空间，重建一个临时表空间。 
 
　　热备份的优点是显而易见的 
 
　　---- a．可在表空间或数据文件级备份，备份时间短。 
 
　　---- b．备份时数据库仍可使用。 
 
　　---- c．可达到秒级恢复（恢复到某一时间点上）。 
 
　　---- d．可对几乎所有数据库实体作恢复。 
 
　　---- e．恢复是快速的，在大多数情况下在数据库仍工作时恢复。 
 
　　操作系统作热备份的一般步骤为： 
 
　　①连接数据库 
 
　　SVRMGRL>connect internal; 
 
　　②将需要备份的表空间（如User）设置为备份方式 
 
　　SVRMGRL>Alter tablespace User begin backup; 
 
　　③拷贝数据文件 
 
　　SVRMGRL>!cp /u01/oradata/prod/user01.ora /backup/prod/user01.ora 
 
　　Or 
 
　　$cp cp /u01/oradata/prod/user01.ora /backup/prod/user01.ora 
 
　　④在数据文件拷贝完成后，将表空间拖体备份方式 
 
　　SVRMGRL>Alter tablespace User end backup; 
 
　　⑤对所有需要备份的表空间重复2，3，4 
 
　　⑥使用如下的命令备份控制文件ALTER DATABSE …… BACKUP CONTROLFILE 
 
　　如备份成二进制文件 
 
　　alter database backup controlfile to ‘new fielname’;
 
 
 
　　备份成文本文件 
 
　　alter database backup controlfile to trace; 
 
　　因为热备份的时候，用户还在操作数据库，所以，最好是每个表空间处于备份状态的时间最短，这样就要求一个表空间一个表空间的备份，不要一起使表空间处于备份状态而同时拷贝数据文件。 
 
　　注意：如果在热备份的时候如果数据库中断（如断电），那么在重新启动数据库的时候，数据库将提示有数据文件需要恢复，你需要把正在断电时候的处于备份状态的数据文件通过ALTER TABLESPACE …… END BACKUP结束备份方式。具体哪个数据文件或表空间处于备份状态，可以通过v$backup与v$datafile来获得。 
 
　　3、RMAN（备份与恢复管理器） 
 
　　i.使用RMAN进行备份 
 
　　Recovery manager（RMAN）是ORACLE提供的DBA工具，用语管理备份和恢复操作。RMAN只能用于ORACLE8或更高的版本中。它能够备份整个数据库或数据库部件，其中包括表空间、数据文件，控制文件和归档文件。RMAN可以按要求存取和执行备份和恢复。 
 
　　RMAN备份有如下优点 
 
　　☆支持在线热备份 
 
　　☆支持多级增量备份 
 
　　☆支持并行备份、恢复 
 
　　☆减少所需要备份量 
 
　　☆备份、恢复使用简单 
 
　　重要的是，使用恢复管理器允许您进行增量数据块级的备份（这个与导出/导入的增量截然不同）。增量RMAN备份是时间和空间有效的，因为他们只备份自上次备份以来有变化的那些数据块。另一个空间有效的RMAN特性是它只备份数据文件中使用的数据块，忽略空的，未用的数据块，这个对于预分配空间的表空间有很大的好处。 
 
　　从9i开始，还增加了RMAN的数据块级别的恢复，可以进一步减少数据库恢复时间。 
 
　　RMAN支持以下不同类型的备份 
 
　　FULL 数据库全备份，包括所有的数据块 
 
　　INCREMENTAL 增量备份，只备份自上次增量备份以来修改过的数据块。需要一个0级的增量作为增量的基础，可以支持5级增量。 
 
　　OPEN 在数据库打开的时候使用 
 
　　CLOSED 在数据库安装(MOUNT)但不打开的时候备份，关闭备份可以是CONSISTENT或IN CONSISTENT类型的。 
 
　　CONSISTENT 在数据库安装，单不打开，并且在安装之前数据库被彻底关闭（而不是被破坏或异常退出）时使用。CONSISTENT备份可以简单的进行复原(RESTORE)而不是恢复(RECOVER) 
 
　　INCONSISTENT 在数据库打开或安装（但不打开）时使用。在该数据库正常关闭或崩溃后，INCONSISTENT备份需要恢复。 
 
　　理解BACKUP，RESTORE，RECOVER命令，这是RMAN最基本的三个命令，可以进行数据库的备份，复原以及恢复操作。 
 
　　理解恢复目录，RMAN可以在没有恢复目录(NOCATALOG)下运行，这个时候备份信息保存在控制文件。保存在控制文件的备份信息是很危险的，如果控制文件的破坏将导致备份信息的丢失与恢复的失败，而且，没有恢复目录，很多RMAN的命令将不被支持。所以对于重要的数据库，建议创建恢复目录，恢复目录也是一个数据库，只不过这个数据库用来保存备份信息，一个恢复目录可以用来备份多个数据库。 
 
　　创建RMAN目录，以下步骤说明了在一个数据库中尽力RMAN目录的过程。 
 
　　a.为目录创建一个单独的表空间 
 
　　SQL>Create tablespace tools datafile ‘fielname’ size 50m; 
 
　　b.创建RMAN用户 
 
　　SQL>Create user RMAN identified by RMAN default tablespace tools temporary tablespace temp; 
 
　　c.给RMAN授予权限 
 
　　SQL>Grant connect , resource , recovery_catalog_owner to rman; 
 
　　d.打开RMAN 
 
　　$>RMAN 
 
　　e.连接数据库 
 
　　RMAN>connect catalog rman/rman 
 
　　f.创建恢复目录 
 
　　RMAN>Create catalog tablespace rman 
 
　　注册目标数据库，恢复目录创建成功后，就可以注册目标数据库了，目标数据库就是需要备份的数据库，一个恢复目录可以注册多个目标数据库，注册目标数据库的命令为： 
 
　　$>RMAN target internal/password catalog rman/rman@rcdb; 
 
　　RMAN>Register database; 
 
　　数据库注册完成,就可以用RMAN来进行备份了，更多命令请参考ORACLE联机手册或《ORACLE8i备份与恢复手册》。 
 
　　RMAN使用脚本来备份数据库，以下是RMAN进行备份的几个例子。 
 
　　a.备份整个数据库 
 
　　backup full tag ‘basicdb’ format ‘/bak/oradata/full_%u_%s_%p’ database; 
 
　　b.备份一个表空间 
 
　　backup tag ‘tsuser’ format ‘/bak/oradata/tsuser_%u_%s_%p’ tablespace users; 
 
　　c.备份归档日志 
 
　　backup tag ‘alog’ format ‘/bak/archivebak/arcbak_%u_%s_%p’ archivelog all delete input; 
 
　　ii.维护RMAN 
 
　　RMAN的维护主要分为几个方面 
 
　　1、 查看RMAN的信息 
 
　　检查现有备份 
 
　　RMAN>list backup 
 
　　列出过期备份 
 
　　RMAN>report obsolete 
 
　　删除过期的备份 
 
　　RMAN>allocate channel for maintenance type disk; 
 
　　RMAN>change backupset id delete; 
 
　　RMAN>release channel; 
 
　　2、 同步或重置RMAN 
 
　　如果目标数据库物理对象发生了变化，如添加了一个数据文件，需要用如下命令同步： 
 
　　RMAN>resync catalog; 
 
　　如果目标数据库reset了数据库，需要用如下命令同步 
 
　　RMAN>reset database; 
 
　　当手工删除了数据库的归档文件后，要执行以下脚本同步 
 
　　RMAN>allocate channel for maintenance type disk; 
 
　　RMAN> change archivelog all crosscheck; 
 
　　RMAN>release channel; 
 
　　当手工删除了数据库的RMAN备份后，要执行以下脚本来同步 
 
　　RMAN>allocate channel for maintenance type disk; 
 
　　RMAN>crosscheck backup; 
 
　　RMAN>delete expired backup; 
 
　　RMAN>release channel; 
 
　　四、定制恰当的备份策略 
 
　　i.定制正确的策略 
 
　　正确的备份策略不仅能保证数据库服务器的24*7的高性能的运行，还能保证备份与恢复的快速性与可靠性。我们将以RMAN的多级增量备份作为一个备份策略的例子来讨论。采用多级备份就是为了减少每天备份所需要的时间，而又保证系统有良好的恢复性。恢复时间与备份时间要有一个权衡。比如只要进行一个数据库的全备份，然后就只备份归档也可以保证能把数据库恢复到最新的状态，但是这样的恢复时间将是不可容忍的。多级备份也正是 为了解决这种问题，以下就是一个多级备份的例子： 
 
　　每半年做一个数据库的全备份（包括所有的数据和只读表空间） 
 
　　每一个月做一次零级备份（不包含只读表空间） 
 
　　每个星期做一次一级备份 
 
　　每天做一次二级备份 
 
　　任何数据库的更改需要重新同步CATALOG目录并重新备份（如添加数据文件）或重新备份（如修改表空间为只读） 
 
　　每次备份后都可以备份归档日志或定期备份归档日志。 
 
　　如果可能，可以直接备份到磁带上。 
 
　　数据库全备份的脚本 
 
　　run{ 
 
　　allocate channel c1 type disk; 
 
　　allocate channel c2 type disk; 
 
　　allocate channel c3 type disk; 
 
　　backup full tag ‘dbfull’ format ‘/u01/oradata/backup/full%u_%s_%p’ database 
 
　　include current controlfile; 
 
　　sql ‘alter system archive log current’; 
 
　　backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ 
 
　　archivelog all delete input; #备份归档可选，可以单独定期备份 
 
　　release channel c1; 
 
　　release channel c2; 
 
　　release channel c3; 
 
　　} 
 
　　零级备份的脚本 
 
　　run{ 
 
　　allocate channel c1 type disk; 
 
　　allocate channel c2 type disk; 
 
　　allocate channel c3 type disk; 
 
　　backup incremental level 0 tag ‘db0’ format ‘/u01/oradata/backup/db0%u_%s_%p’ 
 
　　database skip readonly; 
 
　　sql ‘alter system archive log current’; 
 
　　backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ 
 
　　archivelog all delete input; #备份归档可选，可以单独定期备份 
 
　　release channel c1; 
 
　　release channel c2; 
 
　　release channel c3; 
 
　　} 
 
 
 
　　同理，我们可以得到一级备份，二级备份的脚本，如一级备份的脚本 
 
　　run{ 
 
　　allocate channel c1 type disk; 
 
　　allocate channel c2 type disk; 
 
　　allocate channel c3 type disk; 
 
　　backup incremental level 1 tag ‘db1’ format ‘/u01/oradata/backup/db1%u_%s_%p’ 
 
　　database skip readonly; 
 
　　sql ‘alter system archive log current’; 
 
　　backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ 
 
　　archivelog all delete input; #备份归档可选，可以单独定期备份 
 
　　release channel c1; 
 
　　release channel c2; 
 
　　release channel c3; 
 
　　} 
 
　　如果按照以上备份策略，则每天的所需要备份的数据量只有一天的改变量。而做恢复时最多要恢复当月的一个零级备份+三个一级备份+6个二级备份+当天的归档文件。如果不能接受这样的恢复时间，可以减少零级备份之间的时间间隔。 
 
　　在每次备份后，原则上在该备份点之前的归档日志就可以删除掉了，但是为了进一步的安全以及日后需要（如使用LOGMNR查找所需信息），建议有条件的话，归档日志保存一年，可以保存在磁带等廉价存取设备上。 
 
　　ii.与RMAN备份有关的优化 
 
　　备份操作主要是完成以下三个步骤 
 
　　1、从磁盘上读取数据 
 
　　2、在内存中处理数据块 
 
　　3、写入数据到磁盘或磁带 
 
　　以上的读写操作可以同步或异步的完成，在同步I/O操作中，一个时间只允许有一个IO操作，但是在异步I/O操作中，一个时间允许有多个IO操作。因此，备份与恢复的调优主要集中在以下几个方面： 
 
　　1、 提高同步或异步I/O操作能力 
 
　　在支持异步操作的操作系统上，可以通过设置TAPE_AYSNCH_IO,DISK_ASYNCH_IO和BACKUP_TYPE_IO_SLAVES来支持异步操作，提高写的能力。 
 
　　2、 提高磁盘读能力 
 
　　可以在backup命令后通过设置DISKRATIO来保证从多个磁盘上读取数据，保证连续的数据流。 
 
　　3、 正确设置缓冲区与参数值 
 
　　设置LARGE_POOL_SIZE，使备份可以使用连续的缓冲池，通过设置DB_FIL_DIRECT_IO_COUNT可以提高缓冲区的利用。如果使用磁带备份，还可以设置BACKUP_TYPE_IO_SLAVES来提高磁带的写能力。 
 
　　4、采用并行备份 
 
　　开辟多个通道，可以实现并行备份与恢复 
 
　　 
 
　　iii.备份RMAN数据库 
 
　　RMAN自己的数据库也需要备份，但是本身很小，而且不是经常发生变化，所以在每次RMAN备份完成后，都可以用如下脚本对RMAN数据库备份。 
 
　　EXP pafile =exprman.sql 
 
　　exprman.sql为 
 
　　USERID=RMAN/RMAN 
 
　　BUFFER=32768 
 
　　OWNER=RMAN 
 
　　FILE=RMAN.DMP 
 
　　ROWS=Y 
 
　　GRANTS=Y 
 
　　COMPRESS=Y 
 
　　CONSISTENT=Y 
 
　　iv.使自动备份数据库 
 
　　自动备份数据库不外乎以下三种方式 
 
　　WINDOWS下的任务计划(At命令) 
 
　　UNIX下的Crontab 
 
　　第三方工具如Viritas 
 
　　在以上三种方式中Viritas属于第三方工具，很多人可能都没有接触，主要说一下windows的任务计划与unix的cron 
 
　　1、生成脚本文件，如backup.rcv 
 
　　假定文件内容如下： 
 
　　$>cat backup.rcv 
 
　　connect target sys/password rcvcat rman/rman@localname; 
 
　　run{ 
 
　　allocate channel c1 type disk; 
 
　　allocate channel c2 type disk; 
 
　　allocate channel c3 type disk; 
 
　　backup fileaperset 3 format ‘/u01/oradata/backup/arch%u_%s_%p’ 
 
　　archivelog all delete input; 
 
　　release channel c1; 
 
　　release channel c2; 
 
　　release channel c3; 
 
　　} 
 
　　2、生成执行文件 
 
　　在windows上生成backup_archive.bat，内容包括 
 
　　rman cmdfile = backup.rcv 
 
　　在unix下生成 backup_archive.sh，内容包括 
 
　　/oracle/ramn/rman cmdfile = backup.rcv 
 
　　3、加入调度 
 
　　在windows中用任务计划向导即可，或使用at命令。 
 
　　在unix中，在目标机器上编写一个文件，用以启动自动备份进程。假定文件名为ORACLE，文件将放在/var/spool/cron/crontabs目录下 
 
　　$>cat oracle 
 
　　0 23 * * 0 backup_archive.sh 
 
　　#表示星期天23点对数据库备份 
 
　　0 12,18 * * * backup_archive.sh 
 
　　#表示每天12点，18点备份 
 
　　Crontab文件的每一行由六个域(minutes,hours,day of month,month,day of week,command)组成，域之间用空格或Tab分隔开来 
 
　　 
 
　　1、使用EXP/IMP备份 
 
　　EXP/IMP不是一个良好的备份工具，在以后的发展之中，ORACLE对EXP/IMP用于备份的支持会越来越低。ORACLE只是把EXP/IMP当作一个好的工具而不是备份工具，在对于大型数据库，如TB级数据库或数据仓库，EXP/IMP肯定会力不从心。 
 
　　2、在应用程序中备份数据库 
 
　　在论坛上，有很多这样的要求，“我怎么在程序中备份与恢复数据库？”。首先说，这个并不是不可以实现，但是实现的过程会很复杂而且意外会很多。就我的感觉，提出这样问题的人，首先一点就是对ORACLE或DBA的不了解，如果ORACLE可以这么轻松的实现备份与恢复，那么我可以说，就不需要DBA了。 
 
　　3、冷备份比热备份更容易，效果会更好 
 
　　有人认为，冷备份是关闭数据库进行的一致性备份，肯定比热备份要好，使用也容易，其实不尽然，在热备份中，一样可以实现数据库的全备份，而且不会影响到数据库的运行。建议所有的生产机，都运行在归档方式下，采用热备份方式。 
 
　　六、常见问题 
 
　　1、我导出的数据为什么不能导入，提示不支持的字符集转换 
 
　　答：参考上面的字符集原则，导出数据时客户端与数据库字符集一致，导入时修改为与目标数据库字符集一致。 
 
　　2、我的归档日志越来越多，我什么时候可以删除归档日志？ 
 
　　答：在每一次全备份（如OS全冷备份或全热备份）或基于全备份的增量备份（如RMAN基于0级备份上的增量备份）后都可以删除该备份点之前的归档日志，建议在磁带上保留一年。 
 
　　3、全备份时一定需要备份所有数据文件吗？ 
 
　　答：不需要，起码有两类数据文件可以不备份，一类就是临时数据文件，如果丢失，可以删除后重建；一类是只读表空间数据文件，如果上次备份以来，没有修改过表空间的只读属性，就可以不需要备份。 
 
　　4、联机日志需要备份吗？ 
 
　　答：如果是归档方式热备份，就没有必要备份联机日志。但是对于冷备份，可以备份联机日志，特别是不归档状态。备份过联机日志后的冷备份，因为数据库是一致的，可以恢复到该备份点。 
 
　　小结 
 
　　1、什么是数据库备份，数据库备份就是把数据库复制到转储设备的过程。 
 
　　2、数据库的运行方式，可以分为归档方式和非归档方式，建议运行在归档方式下运行热备份。 
 
　　3、了解了数据库的备份方式，逻辑备份、冷备份、热备份 
 
　　4、了解数据库的备份工具，EXP/IMP执行逻辑备份，OS脚本可以执行冷备份或热备份，RMAN也可以执行冷备份或热备份 
 
　　5、了解Oracle的备份策略，并怎样选择最佳的备份策略 
 
　　6、知道怎么样启动自动备份，了解Windows的at命令与unix的cron进程。
 
 

 sql server数据库备份方案
 

 2008-08-05 13:15
 
 
    
 
     

      SQL Server 数据库备份方案
      
为了保证SQL Server 数据的安全，数据库管理员应定期备份数据库，在不同情况下应采用不同备份数据库备份策略，一方面维持数据的安全性，另一方面也可保持SQL Server 能顺畅运行。尽最大的努力减少由于数据的损坏对客户造成的损失。
      
概念
      
1) 备份工作规划
      
计算机软硬件的稳定性还未达到非常稳定的状态，计算机中的数据仍有损失或毁坏的情况发生。存在于计算机内的数据不安全，即使采用容错设备，也无法保证数据库 100%安全。 计算机硬件的费用可能很高，但计算机数据更珍贵，做好数据备份，可保证在各种意外发生情况时，仍能保持有数据库的完整性。 管理员必须花时间来备份数据库，但 SQL SERVER也提供不少自动化功能。 
      
2）备份方式 
      
数据库——完全
      
就是备份整个数据库的内容。若将整个数据库的内容都备份下来，需很多的存储空间来存放备份数据，但其好处是在还原数据库时，也只要将整个数据库从一份数据库备份还原到 SQL SERVER 中就可以了。它是其他备份的基础，在做其他备份之前，必须得做此种方式的备份。 
      
数据库——差异 （Differential）
      
只备份从上一次执行“完全”数据库备份后有改动的数据，因此所需要的备份时间和备份空间都比“完全” 方式少，所以此方式最适合作为经常性的备份方式。 
      
事务日志（Transaction Log）
      
只备份事务记录文件的内容，由于事务日志文件只会记录我们在前一次数据库备份或事务日志记录备份之后，对数据库所做的变动过程，也就是只记录某一段时间的数据库变动情况，因此在做事务记录备份之前，必须做一次“完全”的数据库备份 
      
文件和文件组：
      
如果数据库的内容分散存储于多个文件或文件组，而且数据库已非常大，大到进行一次完整的数据库备份会有时间和存储空间上的问题。这时就可以使用此方式来备份数据库的部分文件或文件组。由于每次只备份部分的文件或文件组，因此需做数次不同的备份才能完成整个数据库的备份。才用此方式备份也有个好处，就是当毁坏的数据只是数据库中的某个文件或文件组时，也只要还原坏的文件或文件组备份就可以了。
      
3）备份方案制订原则
      
规划数据库的备份策略，需要考虑备份的各项变量，必须同时考虑到还原作业的进行。在做备份时，可考虑以下几点。
      
(1) 有多少时间以及在那些时段可进行备份 
      
(2) 数据库变动的频率如何
      
(3) 数据库大小
      
(4) 当数据库出问题时，用户愿意等待多久让数据库还原完毕
      
(5) 应采用何种备份方式，做怎样的搭配
      
(6) 要使用哪种存储介质
      

      

      
4）备份方案
      
（1）完全数据库备份配合事务日志备份
      
对于数据库数据比较大，但每天的变动的内容小，可考虑采用此方式。可定期做一次完整的数据库备份，例如：每周或每月做一次“完全”数据库备份。然后再以较段短的周期，如每天或每两天做一此事务日志备份。这样平时备份工作负担比较轻，发生以外时，可将数据还原到最近期的状态。 
      
（2）完全数据库备份配合差异式备份
      
此方式是将前一种方式中的事务日志备份方式改成差异式备份。其优点是在做还原时，只需在做完最近一次数据库备份的还原后，再用前一天的差异备份来还原就可以了，不像使用事务记录备份时，需一天一天还原。缺点是在比较后的日子里，每次做差异备份所需的时间和空间会增加。 
      
（3）三种备份方式的综合使用
      
由于事务记录备份和差异备份各有其优缺点，因此我们可以将两种方法结合起来使用。对于数据信息非常重要，每1、2小时备份一次，可能的损失只是1、2个小时的数据。 
      
（4）当数据库过大，有不易备份的问题时，可以采用文件或文件组备份方式，可考虑将数据库分开存于不同的文件和文件组中，然后以文件和文件组的方式将整个数据库分数次备份。此外，如果数据库中只有部分表经常变动，另一部分很少变动，也可考虑将这两部分存于不同的文件和文件组中，然后用不同的备份频率来备份其内容。 采用此方式备份数据的缺点是：必须数次操作才能备份完数据。 
      
（5）使用备用服务器
      
采用此方式是再准备一台服务器，先在原服务器上做完全的备份，再把此备份放到备份服务器上做还原，使两边的数据同步，以后可以定期对原数据库做事务日志备份，把事务日志放到备份服务器上还原。当原服务器出现问题既可使用备份服务器接上网络提供服务。
      

      
注意：系统数据库的备份与还原是很多用户在定义数据库备份方案中容易忽略的，系统数据库中虽然不保存业务数据，但它保存了很多SQL Server的设置，如果不备份系统数据库，那么在服务器发生故障导致系统损坏时，重新配置所有的SQL Server设置将是一个噩梦DEMO
      
方案一 数据库备份（常用方案）
      
在SQL Server备份窗口，可以通过调度设置，将当前进行的备份处理设置为定时自动处理的作用。具体的步骤如下：
      
1. 展开一个服务器组。
      
2. 展开一个服务器( SQL Server实例)。
      
3. 展开【数据库】，右单击要备份的数据库，在弹出的菜单中选择【所有任务】—〉【备份数据库】命令。
      
4. 在随后打开的SQL Server备份窗口中，设置备份的相关选项。参见前面的备份方案
      
单击【常规】选项卡，在【调度】项中，选中【调度】复选框，然后单击【调度】复选框后的【…】按钮。在随后出现的【编辑调度】对话框中，设置时间调度安排。 
      
5. 设置完成后，单击【确定】按钮，SQL Server将执行备份操作，同时在【SQL Server 代理】—〉【作业 】中自动建立对应的作业。
      
6. 在【SQL Server 代理】—〉【作业 】窗口中，可以像处理普通作业一样修改或删除数据库备份窗口中定义的备份计划。
      
演示 
      
方案二 数据转换法（DTS）
      
具体的方案就是：
      
1.主服务器和备份服务器装载完全一样的操作系统和数据库软件，以及相应编制的管理软件；
      
2.事先选定需要定期更新的表、视图、存储过程等等，必要时可选择全部数据库更新；
      
　　3.使用SQL Server 提供的数据转换服务导入/ 导出向导(以SQL Server2000 为例) ，利用复制 SQL Server 对象任务，将 Microsoft SQL Server 对象从SQL Server 的一个实例复制到另一个SQL Server 中；
      
　　4.编辑反复出现的作业调度，确定发生的频率和具体时间，一般情况下，由于数据量较大，不提倡每日发生多次，尽量安排在网络空余时间发生。
      
这个方案优点是：
      
　　1.成本低、可靠性高，操作简单，较易维护；
      
　　2.系统转换时间短，备份系统替换主服务器只需几分钟。即使出现意外，备份系统很快就会恢复正常，只损失少量数据，重新输入即可；
      
　　3.本地和异地备份都是利用晚上网络空闲时间进行的，没有增加日常网络流量，不会增加网络负担。
      
　　注意选择传输对象，相同版本的SQL Server 可以相互，或者由低版本向高版本SQL Server 备份，如：
      
　　SQL Server 7.0 的实例备份到 SQLServer 2000 的实例。
      
　　SQL Server 2000 的实例备份到另一个 SQL Server 2000 的实例。
      
备份的操作步骤：
      
1.打开企业管理器，选择SQLServer 服务器的数据库，单击鼠标右键，选择“所有任务”，并点选“导入数据”或“导出数据”。 如果是在主服务器上进行操作，选导出数据；在备份服务器上进行操作，则选导入数据。
      
2.第一步操作后，调出“数据转换服务导入/ 导出向导”界面，单击“下一步”，进入“DTS 导入/ 导出向导”的选择数据源界面，选择“目的”，选择“制定表复制或查询”，选择要复制的对象。 弱
      
做选择时，首先根据具体的客户端选择数据源，如果是OLE DB客户端，选择“用于SQL Server的Microsoft提供的OLEDB 程序”。
      
然后选择提供数据源的服务器，接下来选择进入数据库的方式，可选择“使用Windows 身份验证”或“使用SQL Server 身份验证”。 如果选“使用SQL Server 身份验证”，须填写SQL Server 认可并对数据有修改权的用户，一般可选“SA”及其密码。最后选择要复制的数据库。
      
　　3.在“制定表复制和查询”中，选择“在SQL Server数据库之间复制对象和数据”，然后单击下一步。选择具体复制对象和相应的选项等等.。
      
　　4.通过保存调度和复制包，定制进行复制的时间和频率。
      
　　5.全部设置完成后，提示会列出源、目的、采用的方式、数据库等选项，由你确认完成。
      
　　6.如果设置结束后要进行定制时间修改，在企业管理器中，通过服务器、数据库、管理、SQL server 代理、作业，然后选择具体的作业，调出界面进行修改。
      
至此，你就可以在自己的中小企业环境中，轻松实现多台数据库服务器间的定时自动数据备份了。
      
演示
      
方案三 数据库维护计划+Xcopy命令（推荐使用）
      
1. 展开一个服务器组
      
2. 展开一个服务器实例（SQL Server实例）。
      
3. 展开【管理】，右击【数据库维护计划】，在弹出的快捷菜单中选择【新建维护计划】命令。
      
4. 在随后出现的【数据库维护计划 —（Local）】对话框中，单击【下一步】按钮跳过欢迎页，在接下来的【选择数据库】步骤中，定义要备份的数据库。
      
5. 单击【下一步】按钮，跳过与数据库备份无关的步骤，在【指定数据库备份计划】步骤中，选择【作为维护计划的一部分来备份数据库】复选框；通过单击【磁带】或者【磁盘】单选按钮来选择备份设备；单击【调度】选项右边的【更改】按钮，可以在随后出现的【编辑反复出现的作业调度】对话框中设置维护计划的时间安排。
      
6. 单击【下一步】按钮，如果在步骤（5）中，备份设备选择的是【磁盘】设备，则会进入【指定备份磁盘目录】步骤，根据实际情况，设置此步骤中的内容。
      
7. 单击【下一步】按钮，进入【指定事务日志备份计划】步骤，如果需要进行事务日志备份，则选择【作为维护计划的一部分来备份事务日志】复选框。备份事务日志的其他设置步骤参考（5）～（6）。
      
8. 根据需要设置其他步骤，最后进入【正在完成数据库维护计划向导】步骤，设置好【计划名】，单击【完成】按钮完成数据库维护计划的定义。
      
9. 完成步骤（1）～（8）后，单击【数据库维护计划】，在企业管理器控制台右边的详细信息窗口中就可以看到定义好的数据库维护计划，同时，展开【SQL Server代理】—〉【作业】，可以【作业】右边的详细窗口中，可以看到维护计划自动建立的备份出路作业。
      
10. 通过有机维护计划，选择【属性】命令，可以修改已经定义的维护计划。
      
11. 通过右击维护计划，选择【删除】命令，可以删除已经定义的维护计划，同时【SQL Server 代理】—〉【作业】中的相关作业也会自动删除。
      
新建一个批文件 Copy.bat具体脚本如下：
      
@echo off
      
title 正在传输数据库备份文件到远程备份服务器上！
      
echo 提示：开始验证服务器上是否存在备份文件！
      
echo 请稍候！
      
if exist F:/DBback/*.bak (goto Process ) else goto UnFound
      
:Process
      
echo 提示：在服务器上找到了备份文件！
      
echo -------------------------------------------------------------------------------
      
echo 提示：开始删除远程备份服务器上的原始文件！
      

      
rem 备注：下列IP地址为远程备份服务器的IP地址！ 
      
del //192.168.244.24/DBback /q /s /f
      
del //192.168.244.24/DBback/*.* /q /s /f
      
if errorlevel 0 goto success
      
:success
      
echo 提示：成功删除原始文件！
      
echo -------------------------------------------------------------------------------
      
echo 提示：开始复制数据库备份文件到远程备份服务器//192.168.244.24/DBback！
      
echo 请稍候！
      
rem 备注：请具体更改//192.168.244.1/DBback为服务器备份文件存放的位置。//192.168.244.24/DBback为备份服务器上存放的位置！
      
xcopy //192.168.244.1/DBback //192.168.244.24/DBback /y /f
      
rem 备注：当Xcopy命令结束后返回的Errorlevel为4说明磁盘控件不足。当Xcopy命令返回0时说明成功完成操作！
      
if errorlevel 4 goto lowmemory 
      
if errorlevel 0 goto showmessage
      
:lowmemory
      
echo 警告：请查看磁盘空间是否不足！
      

      
:UnFound
      
echo 警告：在服务器上找不到备份文件，批任务将要结束。服务器备份工作似乎没有正常进行，请确认服务器是否正常生成备份文件！
      
goto exit
      

      
:showmessage
      
echo 提示：批任务完成！ 
      
echo 提示：成功复制数据库备份到远程服务器//192.168.244.24/DBback！ 
      
echo 按任意键结束退出！
      
echo --------------------------------------------------------------------------------
      
:exit
      
pause
      
echo 成功复制PersonnelM数据库备份到远程服务器//192.168.244.24/1上！ 
      
Pause
      

      
利用Windows 任务计划来调度批任务
      
1. 单击“开始”—〉“程序”—〉“附件”—〉“系统工具”—〉“任务计划”
      
2. 双击“新建任务计划”，弹出“任务计划向导”单击“下一步”。在选择任务窗体中选择“浏览”。我们选择要调度执行的Copy.bat文件。
      
3. 在接下来弹出的窗体中为我们的任务计划起个名称并且选择执行频率。这里我们选择“每天”
      
4. 在密码确认窗体中输入本机的密码。单击“下一步”选择“完成”。至此任务计划设置完成。（有需要的话可以单击选择“在单击完成时，打开此任务的高级属性”复选框以便对此任务进行高级设置！）
      

      

      

      
方案四 同步备份服务器（脚本）
      
/*该部分参考了邹建的脚本*/
      
/*--说明：
      
下面的代码演示了如何利用日志还原功能，将主数据库中的数据变化及时反馈到备用数据库中
      
备用数据库的数据可以随时用于查询，但不能被更新（备用数据库
      只读）。
      
--*/
      
--首先,创建一个演示用的数据库(主数据库)
      
CREATE DATABASE Db_test
      
ON
      
( NAME = Db_test_DATA,
      
FILENAME = 'c:/Db_test.mdf' )
      
LOG ON 
      
( NAME = Db_test_LOG,
      
FILENAME = 'c:/Db_test.ldf')
      
GO
      
--对数据库进行备份
      
BACKUP DATABASE Db_test TO DISK='c:/test_data.bak' WITH FORMAT
      
GO
      
--把数据库还原成备用数据库(演示主数据库与这个备用数据库之间的同步)
      
RESTORE DATABASE Db_test_bak FROM DISK='c:/test_data.bak' 
      
WITH REPLACE,STANDBY='c:/db_test_bak.ldf'
      
,MOVE 'Db_test_DATA' TO 'c:/Db_test_data.mdf'
      
,MOVE 'Db_test_LOG' TO 'c:/Db_test_log.ldf'
      
GO
      
--启动 SQL Agent 服务
      
EXEC master..xp_cmdshell 'net start sqlserveragent',no_output
      
GO
      
--创建主服务器数据训与备用服务器数据库之间同步的作业
      
DECLARE @jogid uniqueidentifier
      
EXEC msdb..sp_add_job
      
@job_id = @jogid OUTPUT,
      
@job_name = N'数据同步处理'
      
--创建同步处理步骤
      
EXEC msdb..sp_add_jobstep 
      
@job_id = @jogid,
      
@step_name = N'数据同步',
      
@subsystem = 'TSQL',
      
@command = N''
      
--主数据库中进行日志备份
      
BACKUP LOG Db_test TO DISK="c:/test_log.bak" WITH FORMAT
      
--备用数据库中还原主数据库的日志备份(应用主数据库中的最新变化
      
--实际应该时主数据库备份与备用数据库的还原作业应该分别在主服务器和备用服务器上建立，并且备份文件应该放在主服务器和备用都能访问的共享目录中
      
RESTORE LOG Db_test_bak FROM DISK='c:/test_log.bak' WITH STANDBY='c:/test_log.ldf',
      
@retry_attempts = 5,
      
@retry_interval = 5
      
--创建调度(每分钟执行一次)
      
EXEC msdb..sp_add_jobschedule
      
@job_id = @jogid,
      
@name = N'时间安排',
      
@freq_type=4,
      
@freq_interval=1,
      
@freq_subday_type=0x4,
      
@freq_subday_interval=1,
      
@freq_recurrence_factor=1
      
-- 添加目标服务器
      
EXEC msdb.dbo.sp_add_jobserver 
      
@job_id = @jogid,
      
@server_name = N'(local)' 
      
GO
      

      
--通过上述处理,主数据库与备用数据库之间的同步关系已经设置完成
      
--下面开始测试是否能实现同步
      
--在主数据库中创建一个测试用的表
      
CREATE TABLE Db_test.dbo.TB_test(ID int)
      
GO
      
--等待1分钟30秒（由于同步的时间间隔设置为1分钟,所以要延时才能看到效果）
      
WAITFOR DELAY '00:01:30'
      
GO
      
--查询一下备用数据库,看看同步是否成功
      
SELECT * FROM Db_test_bak.dbo.TB_test
      
/*--结果:
      
ID 
      
----------- 
      
（所影响的行数为 0 行）
      
--*/
      
--测试成功
      
GO
      

      
--最后删除所有的测试
      
DROP DATABASE Db_test,Db_test_bak
      
EXEC msdb..sp_delete_job @job_name=N'数据同步处理'
      
GO
      
/*===========================================================*/
      
/*--服务器宕机处理说明
      
使用这种方式建立的数据库同步，当主数据库不可用时（例如，主数据库损坏或者停机检修）
      
可以使用以下两种方法使备用数据库可用。
      
--*/
      
--1. 如果主数据库损坏，无法备份出最新的日志，可以直接使用下面的语句使备用数据库可读写（丢失最近一次日志还原后的所有数据）。
      
RESTORE LOG Db_test_bak WITH RECOVERY
      
--2. 如果主数据库可以备份出最新日志，则可以使用下面的语句。
      
--先备份主数据库的最新的事务日志
      
BACKUP LOG Db_test TO DISK=''c:/test_log.bak'' WITH FORMAT
      
--再在备用数据库中恢复最新的事务日志，并且使备用数据库可读写（升级为主数据库）
      
RESTORE LOG Db_test_bak FROM DISK='c:/test_log.bak'
      

      
方案五 复制订阅
      
开始学习之前我们先搞清楚以下几个概念：
      
复制（Replication）就是将数据由某处复制到一个或多个目的地，由于对数据库分散式应用的需求日渐增加，SQL Sever也提供了复制的功能。
      
SQL Server 的复制功能基本上是使用“发布服务器(Publisher) ”和“订阅服务器”（Subscriber）的结构，这整个结构中包含了数个不同的组件。
      
（1） 发布服务器（Publisher）：在复制中，发布服务器就是负责发布数据库内容给其他服务器的SQL Server (一般的我们把主服务器当作发布服务器，形象一点比喻发布服务器就好像是一本书的作者)
      
（2） 订阅服务器（Subscriber）：订阅服务器就是指受发布服务器所发布数据的SQL SERVER，通常发布服务器只有一个，但订阅服务器可以有多个。（形象比喻订阅服务就像是读者，购买相同图书的读者可以有很多。） 
      
（3） 分发服务器（Distributor）：除了发布服务器和订阅服务器这两个基本外，另一个可以由 SQL SERVER 在整个复制结构中扮演的角色就是分发服务器。分发服务器是负责将发布服务器所发布的数据库发布、传输到各订阅服务器的服务器。在简单的复制结构中，发布服务器和分发服务器通常是使用同一个 SQL SERVER。设置为分发服务器的 SQL SERVER，会有个名为 distribution 的系统数据库存放复制信息。
      
（4） 发布项（Article）：发布服务器所发布的数据称为发布项，发布项是进行复制时的复制单位，发布项可以是表或存储过程等数据库对象，也可以知识表中的某几列或某几项数据。 
      
（5） 发布（Publish）：一组特定的发布项组合就称为发布，也就是 SQL SERVER进行复制时所复制的数据合。当订阅服务器向发布服务器订阅数据时，是以发布为单位，而不是以发布项为单位的。即，订阅服务器只能接收整个发布中的所有 article。而不能只选择其中几个发布项类订阅，每个发布只有来自单一数据库的内容，但我们可以为数据库设置多个发布。
      
（6） 为适应不同的复制需求，SQL SERVER提供了发送（Push）和请求(Pull)两种不同的订阅方式。区别如下：
      
（a） 发送订阅（Push Subscription也称为强制订阅）：所谓的发送订阅就是由发布服务器主动传送发布给订阅服务器，也就是由发布服务器控制复制的操作，只要指定进行复制的时间一到，不管订阅服务器有没有提出要求，发布服务器都会将数据传送给订阅服务器。 
      
（b） 请求订阅（Pull Subscription）：请求订阅和发送订阅相反，是由订阅服务器自行根据排定的日程向发布服务器要求订阅发布，通常在订阅服务器数量较多，或是不需要即时取的最新的数据内容时，可采用此种订阅方式。 
      

      

      
步骤：
      
下介绍实现复制的步骤。(以快照复制为例)
      
准备工作:
      
1.发布服务器,订阅服务器都创建一个同名的windows用户,并设置相同的密码,做为发布快照文件夹的有效访问用户
      
--我的电脑
      
--控制面板
      
--管理工具
      
--计算机管理
      
--用户和组
      
--右键用户
      
--新建用户
      
--建立一个隶属于administrator组的登陆windows的用户
      
2.在发布服务器上,新建一个共享目录,做为发布的快照文件的存放目录,操作:
      
我的电脑--D:/ 新建一个目录,名为: BakPUB
      
--右键这个新建的目录
      
--属性--共享
      
--选择"共享该文件夹"
      
--通过"权限"按纽来设置具体的用户权限,保证第一步中创建的用户具有对该文件夹的所有权限
      
--确定
      

      
3.设置SQL代理(SQLSERVERAGENT)服务的启动用户(发布/订阅服务器均做此设置)
      
开始--程序--管理工具--服务
      
--右键SQLSERVERAGENT
      
--属性--登陆--选择"此账户"
      
--输入或者选择第一步中创建的windows登录用户名
      
--"密码"中输入该用户的密码
      
4.设置SQL Server身份验证模式,解决连接时的权限问题(发布/订阅服务器均做此设置)
      
企业管理器
      
--右键SQL实例--属性
      
--安全性--身份验证
      
--选择"SQL Server 和 Windows"
      
--确定
      
5.在发布服务器和订阅服务器上互相注册
      
企业管理器
      
--右键SQL Server组
      
--新建SQL Server注册...
      
--下一步--可用的服务器中,输入你要注册的远程服务器名--添加
      
--下一步--连接使用,选择第二个"SQL Server身份验证"
      
--下一步--输入用户名和密码
      
--下一步--选择SQL Server组,也可以创建一个新组
      
--下一步--完成
      
6.对于只能用IP,不能用计算机名的,为其注册服务器别名
      
(在连接端配置,比如,在订阅服务器上配置的话,服务器名称中输入的是发布服务器的IP)
      
开始--程序--Microsoft SQL Server--客户端网络实用工具
      
--别名--添加
      
--网络库选择"tcp/ip"--服务器别名输入SQL服务器名
      
--连接参数--服务器名称中输入SQL服务器ip地址
      
--如果你修改了SQL的端口,取消选择"动态决定端口",并输入对应的端口号
      
==============================================================================
      
正式开始:
      
1.配置发布服务器
      
a. 选中指定 [服务器] 节点
      
b. 从 [工具] 下拉菜单的 [复制] 子菜单中选择 [发布、订阅服务器和分发] 命令
      
c. 系统弹出一个对话框点 [下一步] 然后看着提示操作
      
--直到"指定快照文件夹"
      
--在"快照文件夹"中输入准备工作中创建的目录: //<服务器名>/ BakPUB
      
一[下一步] 直操作到完成。
      
d. 当完成了出版服务器的设置以后系统会为该服务器的树形结构中添加一个复制监视器
      
同时也生成一个分发数据库(distribution)
      

      
---------------------------------------------------------------------------
      
2.创建发布
      
a. 选中指定的服务器
      
b. 从 [工具] 菜单的 [复制] 子菜单中选择 [创建和管理发布] 命令。此时系统会弹出
      
一个对话框
      
c. 选择要创建发布的数据库，然后单击 [创建发布]
      
d. 在 [创建发布向导] 的提示对话框中单击 [下一步] 系统就会弹出一个对话框。对话
      
框上的内容是复制的三个类型。我们现在选第一个也就是默认的快照发布(其他两个
      
大家可以去看看帮助) 
      
e. 单击 [下一步] 系统要求指定可以订阅该发布的数据库服务器类型，SQLSERVER允许在
      
不同的数据库如 ORACLE或ACCESS之间进行数据复制。但是在这里我们选择运行
      
"SQL SERVER 2000"的数据库服务器
      
f. 单击 [下一步] ,选择要发布的对象(如表,视图,存储过程,一般是表)
      
g. 然后 [下一步] 直到操作完成。当完成出版物的创建后创建出版物的数据库也就变成了
      
一个共享数据库。
      

      
---------------------------------------------------------------------------
      
3.设计订阅
      
a. 选中指定的订阅服务器
      
b. 从 [工具] 下拉菜单中选择 [复制] 子菜单的 [请求订阅]
      
c. 按照提示单击 [下一步] 操作直到系统会提示检查SQL SERVER代理服务的运行状态，执行
      
复制操作的前提条件是SQL SERVER代理服务必须已经启动。
      
d. 单击 [完成] 完成订阅操作。
      

      
----------------------------------------------------------------------------
      
完成上面的步骤其实复制也就是成功了。但是如何来知道复制是否成功了呢？
      
这里可以通过这种方法来快速看是否成功。
      
展开出版服务器下面的复制——发布内容——右键发布内容——属性——击活——状态然后点立即运行代理程序接着点代理程序属性击活调度
      
把调度设置为每一天发生，每一分钟，在0：00：00和23：59：59之间。
      
接下来就是判断复制是否成功了打
      
开C:/Program Files/Microsoft SQL Server/MSSQL/REPLDATA/下面
      
看是不是有一些以时间做为文件名的文件夹差不多一分中就产生一个。