BE Learing 7 测试, 7.11 根据策略创建JOBoracle全备，差异到磁带，恢复

1.1 根据策略创建JOB-oracle全备，差异到磁带，恢复（OK）

这次测试是在实际的生成环境，使用的是磁带库进行备份。然后根据时间点恢复，SCN恢复到源oracle数据库。

1.1.1.1 磁带管理

BE介质服务器是BAK01.

1.1.1.2 贴标签

1.1.1.3 放置磁带

使用磁带库的import命令，导入10盒磁带。

1.1.1.4 BE管理磁带

1.1.1.4.1 Scan

扫面前的磁带，如下图，

扫面后的磁带，如下图，

扫描后的磁带还是不可识别的，如下图

1.1.1.4.2 Inventory

在Robotic Libraries的slot上右键，运行Inventory，完成后，Online Media如下图：

其中BLP34，BLP038，BLP039的3盒磁带因为以前使用过，备份过数据，所以他们的Allocated Date与Media Label的图标都是不一样的。现在所有的磁带都是Blank Media。

1.1.1.4.3 Quick Erase

这个步骤只有也只能在第一次加载磁带时做，因为磁带里没有数据。

1.1.1.4.3.1 Before Erase

1.1.1.4.3.2 Right-Click Menu -> Quick Erase

1.1.1.4.3.3 After Erase

1.1.1.5 备份作业BKDB01-PlcDB01

1.1.1.5.1 备份计划

将DB01, DB02上的数据备份到tape上。介质服务器是BAK01.

1.1.1.5.2 备份前的准备

1.1.1.5.2.1 将DB01,DB02转为归档模式

Step 1， 停止APP01，APP02上所有weblogic服务。

因为weblogic服务使用的数据库是DB01和DB02。

Step 2， 登陆DB01的sqlplus

1.1.1.5.3 BE Agent安装与配置

安装：

1. copy //BAK01/C:/Program Files/Symantec/Backup Exec/Agents/RAWS32到DB01，DB02任意目录。

2. 运行RAWS32/SETUPAA.exe。

DB01的配置：

run agent

Change Settings

增加oracle实例，如下图

使用OS 系统登陆帐户，如下图

1.1.1.5.4 介质集与策略管理

1.1.1.5.4.1 策略名称：PlcDB01

此策略对应的Selection List为BKSelDB01。

模板一：全备模板TplDB01Full

要求：1盒磁带做全备。

设备名称：ADIC 1。

介质集名称：MSDB01Full，附加周期为1天，覆盖周期为1天。

运行周期：每天2:00:00 PM开始运行，2:59:59 PM结束。

模板二：差异模板TplDB01Diff

要求：1盒磁带做差异备份。

设备名称：ADIC 1。

介质集名称：MSDB01Diff，附加周期为1天，覆盖周期为1天。

运行周期：每天2:30:00 PM开始运行，2:59:59 PM结束。

1.1.2 BE的设置

1.1.2.1 重要的设置

1.1.2.1.1 设置可覆盖介质的搜索顺序

Menu： Tools -> Option –> Media Management

本案例的顺序为：

从暂存介质集搜索可以覆盖的介质。

从本介质集搜索可以覆盖的介质。

从其他介质集搜索可以覆盖的介质。

1.1.2.1.2 登陆帐户设置

Menu: Network->Logon Accounts,添加以下帐户:

DB01 OS帐户与Oracle登陆帐户

1.1.2.1.3 Oracle 登陆列表设置

1.1.2.2 BE Device设置

略，见Policy设置。

1.1.2.3 BE Media设置

全备Media Set，如下图

差异Media Set，如下图

1.1.2.4 BE Policy设置

1.1.2.4.1 新建策略

1.1.2.4.2 新建全备模板

1.1.2.4.2.1 新建Backup Template

1.1.2.4.2.2 Device and Media

这里我们可以选择的Device有ADIC 1,IBM 1,IBM 2。ADIC 1是磁带库，IBM1，IBM2是ADIC1的2个driver。如果选择ADIC 1，BE将自己选择driver，即使有1个driver发生故障，JOB也能够继续进行。

这里我们指定IBM1。

1.1.2.4.2.3 General

1.1.2.4.2.4 Advanced Open File

无，此为ORACLE备份。

1.1.2.4.2.5 Oracle

1.1.2.4.2.6 Schedule

Click Button “Edit Schedule Details”

Recurring Week days, click button “select all”

Time Window,

1.1.2.4.3 新建复制全备模板

无，此备份无复制备份。

1.1.2.4.3.1 新建Duplicate Backup Sets Template

1.1.2.4.3.2 Templates

1.1.2.4.3.3 Device and Media

1.1.2.4.3.4 General

//Preferred source device就是要复制的对象。

1.1.2.4.3.5 Schedule

//选择Run only according to rules for this template.

//查看rules

//点击Edit Ruels

1.1.2.4.4 新建差异模板

1.1.2.4.4.1 新建Backup Template

1.1.2.4.4.2 Device and Media

1.1.2.4.4.3 General

1.1.2.4.4.4 Advanced Open File

无。

1.1.2.4.4.5 Oracle

1.1.2.4.4.6 Schedule

1.1.2.4.5 新建复制差异模板

无。

1.1.2.4.5.1 Templates

1.1.2.4.5.2 Device and Media

1.1.2.4.5.3 General

1.1.2.4.5.4 Schedule

1.1.2.5 BE Selection list设置

新建选择项列表

Selections

Resource Credential 测试，

1.1.2.6 BE Job设置

New jobs using policy

Moniter

作业建好后，2个作业开始等待运行。

1.1.3 BE backup Job运行结果（？？）

1.1.3.1 运行时遇到的异常

1.1.3.1.1 Final error: 0xe0000340

Final error: 0xe0000340 - The Database script returned an error. Refer to the Database script output section in job logs for more details.

Final error category: Resource Errors

BE log info:

RMAN-12001: could not open channel ch0

RMAN-10008: could not create channel context

RMAN-10003: unable to connect to target database

ORA-12560: TNS:protocol adapter error

将数据库转为归档后，没有重启oracle服务。

打开service 管理器，重启OracleServiceEGOV01

重启监听器

1.1.3.1.2 Final error: 0xe0000340

Final error: 0xe0000340 - The Database script returned an error. Refer to the Database script output section in job logs for more details.

Final error category: Resource Errors

BE log info:

Starting backup at 25-APR-09

current log archived

channel ch0: starting archive log backupset

channel ch0: specifying archive log(s) in backup set

input archive log thread=1 sequence=357 recid=1 stamp=685118319

input archive log thread=1 sequence=358 recid=2 stamp=685118512

channel ch0: starting piece 1 at 25-APR-09

released channel: ch0

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of backup plus archivelog command at 04/25/2009 14:41:54

ORA-04030: out of process memory when trying to allocate 1049100 bytes (KSFQ heap,KSFQ Buffers)

1. 官方的描述如下

ORA-04030 out of process memory when trying to allocate string bytes (string,string)

Cause: Operating system process private memory has been exhausted.

Action: See the database administrator or operating system administrator to increase process memory quota. There may be a bug in the application that causes excessive allocations of process memory space.

这使我想起我当初在安装数据库时分配的内存可以过大，下图是我安装的配置：

安装后的oracle的内存分配如下图：（large_pool_size原来是0，后来修改到800M）

通过sql命令查看得知sga_target=1800M,pga_aggregate_target=600和我设置的一致，对于Share Memory Management设为automatic，oracle的说法是oracle会自己自行管理，看来是没有管理好，还得手动分配的好。

2. 网上搜的信息

现象：ORA-04030: 在尝试分配...字节 (hash-join subh,kllcqas:kllsltba) 时进程内存不足。

ORA-04030:out of process memory when trying to allocate string bytes

ORA-04030的出现原因及解决方法：

ORA-04030出现的基本都是过多的使用memory造成的

Oracle process使用的内存数量是有一定限制的：

A. 对于32 BIT系统，有SGA 1.7G限制

B. 某些OS系统本身也有一些内存参数限制

--运行 ulimit 看看

C. OS系统本身物理内存+Swap的限制

现在我们应该检查DB使用的SGA + PGA是否超过上面的限制。

SGA 包括 db_cache,shared_pool,large_pool,java_pool session的PGA包括sort_area_size/Hash_area_size/*_area_size 或者 pga_aggregate_target

还有执行的CODE以及一些data也会占用空间。

然后再根据情况降低里面的某些值了，比如db_cache，sort_area_size等等。

假如是OS系统的某Limited造成的，大家可以考虑放开限制man ulimit来观察如何放开限制……

根据以上的2点，确定需要调整内存大小小于1.7G。

1. 设置rman从SGA取内存

alter system set dbwr_io_slaves=2 scope=spfile;

alter system set backup_tape_io_slaves=true scope=spfile;

2. 调整SGA大小

alter system set sga_target=1200m;

alter system set sga_max_size=1200m scope=spfile;

3. 设置使用内存最大大小

alter system set large_pool_size=80m;

4. 重启oracle service。

5. 查看sga,pga,pool的大小。

1.1.3.2 异常后的Schedule调整

全备

差异

1.1.3.3 全备运行后，模拟差异

1.1.3.4 运行前的Monitor

1.1.3.5 第1次运行

1.1.3.5.1 全备后模拟增量

登陆DB01，向数据库插入记录

1.1.3.5.2 Job Monitor

1.1.3.5.3 运行后MediaSet

1.1.3.6 第2次运行

1.1.3.6.1 模拟增量

登陆DB01，向数据库插入记录

手动运行差异JOB

1.1.3.6.2 Job Monitor

注意此时的时间是11:17:57.

1.1.3.6.3 运行后MediaSet

1.1.3.7 第3次运行

1.1.3.7.1 模拟增量

登陆DB01，向数据库插入记录

手动运行差异JOB

1.1.3.7.2 Job Monitor

注意此时的时间是11:23:32.

1.1.3.7.3 运行后MediaSet

1.1.3.8 第4次运行

1.1.3.8.1 模拟增量

登陆DB01，向数据库插入记录

手动运行差异JOB

1.1.3.8.2 Job Monitor

注意此时的时间是11:33:32.

1.1.3.8.3 运行后MediaSet

1.1.3.9 结论

无。

1.1.4 恢复一：根据SCN恢复到第3次备份时间点

介质服务器：BAK01。

DB服务器：DB01。

使用备份数据恢复到第3次备份时间点。

1.1.4.1 恢复前的准备

无。

1.1.4.2 目标服务器DB01设置

无。

1.1.4.3 DB01介质管理

1.1.4.3.1 移动复制备份介质到新的服务器

无。

1.1.4.3.2 BE上新建一个相同Device

无。

1.1.4.3.3 覆盖介质目录

无。

1.1.4.3.4 扫描，清点，编录Device

无。

1.1.4.4 BE还原Job设置

新建还原JOB，RestoreDB01NAST.

1.1.4.4.1 General

1.1.4.4.2 Selection

一定要从表空间还原。

解读上图：

从控制文件（Controll Files）看出，你可以恢复到列出的任何一个时间点。

从控制文件（Controll Files）看出，10:41:30是全备，11:04:14是第1次差异备份，11:19:53是第2次差异备份，11:25:47是第3次差异备份，11:36:04是第4次差异备份。

从控制文件（Controll Files）看出，可以恢复到的时间点比备份计划的时间点推迟了几分钟。

把鼠标放在任何一个表空间，便会有提示。

解读上图：

现在可以一目了然地看出哪个时间点的备份,而且是按备份的时间顺序排列的，一目了然，想怎么恢复就怎么恢复。

能看出源oracle的数据库文件的存放目录。

选中第3次备份时间点的控制文件。

解读上图：

1. 时间点或者SCN，在恢复时能够用到，让恢复时精确的恢复到这个点。

2. DatabaseID，在oracle Redirection还原时能够用到，目标数据库的ID要与源相同，否则无法恢复。

了解了以上的信息，那么我们就选择表空间进行恢复吧，如下图

1.1.4.4.3 Resource Credentials测试

这一步不能少，结果必须是成功的。

1.1.4.4.4 Device and Media

1.1.4.4.5 Oracle Redirection设置

无。

1.1.4.4.6 Oracle设置

选择第3次备份的SCN。

1.1.4.4.7 Schedule，Run Now

Monitor:

1.1.4.5 后续工作

Step 1，登陆到目标oracle服务器DB01,打开cmd，输入SQLPLUS sys/password@SID as sysdba。

Step 2，检查数据。

因为还原到第3次备份的时间点，记录应该是400W。

呵呵，完全正确。

1.1.4.6 结论

差异恢复是成功的，可以恢复到任何一个时间点。

1.1.5 恢复二：根据SCN恢复到第2次备份时间点

介质服务器：BAK01。

DB服务器：DB01。

使用备份数据恢复到第2次备份时间点。

1.1.5.1 恢复前的准备

无。

1.1.5.1.1 Oracle设置

直接双击作业RestoreDB01NAST.

查询第2次差异备份的SCN。

选择第2次备份的SCN。

1.1.5.1.2 Schedule，Run Now

Monitor:

遇到异常

Final error: 0xe0000340 - The Database script returned an error. Refer to the Database script output section in job logs for more details.

Final error category: Resource Errors

BE Log Info：

Starting recover at 26-APR-09

released channel: ch0

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 04/26/2009 00:36:55

RMAN-20208: UNTIL CHANGE is before RESETLOGS change

上一次的恢复，rman做了一次resetlogs，所以不可以恢复到resetlog之前的数据。

1. 直接恢复难以实现，据说oracle10g的rman可以还原到resetlogs之前的时间点，但是BE是不可以的，起码12.5这个版本不可以。

2. 删除DB01数据库，再重建相同的数据库，再做oracle Redirection恢复，这样肯定是可以的。

1.1.5.2 后续工作

Step 1，登陆到目标oracle服务器DB01,打开cmd，输入SQLPLUS username/password@SID as sysdba。

Step 2，检查数据库是否正常。

由于最后一次恢复失败，导致数据库在关闭后，没有正常打开。

Step 3，rman登陆到DB01，rman target sys/password@sid.

运行命令：

>restore database;

>recover database;

>alter database open;

当完成命令后，数据库就有回到了最后一次归档状态，明显，最后一次归档的时间是第一次恢复的时间，所以现在的数据库数据应该是和第一次恢复时的一致。

Step 4，检查数据,SQLPLUS username/password@SID

1.1.5.3 结论

同一个备份数据只能恢复一次，如果再次恢复只能做oracle Redirection恢复了。