Solaris中dd命令还原系统记录

近日,由于项目中的需要对HP
UNIX下的Oracle的集群模式进行了研究。Oracle拥有VG共享存储模式和独占模式两种集群模式,本文结合在实际项目,详细介绍了实现oracle数据库服务器的双机热备和动态负载均衡的过程,具体如下:

 

由于SUN
Solaris系统更改root下的一些东西导致系统崩溃,采取以下策施进行系统还原。

1、双机热备(VG共享存储模式)及负载均衡方案

一、什么是高可用(High Availability)

1、为了不重新安装Oracle数据库系统和x1000用户下面的软件和需要进行一系列配置,首先需要把oracle用户和x1000用户所在的文件夹打包,使用的命令为

双机热备的含义就是设置两台互为备份的服务器,并且在同一时间内只有一台服务器运行。当出现意外情况时候,其中一台运行着的服务器出现意外故障而无法启动时,另一台备份的服务器就会自动的并迅速的启动运行,从而保证整个应用系统的正常运行。双机热备的工作机制实际上是为整个网络系统的中心服务器提供了一种故障自动恢复能力。

        在高可用的解释方面,有人给出了如下的诠释:

# cd /export/home

  这里需要清楚阵列盘信息、双机软件信息、HP
unix双机系统集群技术层次构架、负载均衡和单点故障自动切换:

        (1)系统失败或崩溃 (system faults and crashes)

# tar cvf oracle.tar /export/home/oracle    //打包oracle用户文件夹

1)阵列盘就是盘阵上的硬盘,就是双机热备要用到的物理存储。

        (2)应用层或者中间层错误 (application and middleware failures)

# tar cvf x1000.tar /export/home/x1000    //打包x1000用户文件夹

2)操作系统双机软件:roseha,IBM的AIX小机的HACMP,HP-UNIX的SGMC/service
guard)。windows的mscs等等。这里用HP-UNIX的SGservice guard)。

        (3)网络失败 (network failures)

(注:由于oracle中回滚数据库表空间很大,这里有32G的大小,打包程序将忽略不执行这个文件的打包,所以需要单独拷贝)

3)oracle数据库集群软件Serviceguard
Extension for RAC

        (4)介质失败,一般指存放数据的媒体故障 (media failures)

2、把打包的文件拷贝到windows系统中保存。

4)HP
unix双机系统集群技术层次构架由HP unix 11.31操作系统、HP UX service guard
集群组件、Oracle数据库集群等三部分组成,请看示意图“HP
unix双机系统集群技术层次构架”。

        (5)人为失误 (Human Error)

3、把Sun1服务器的硬盘拆下来,安装的在Sun2的硬盘安装位置1处(Sun2的硬盘安装在0处)。

a)HP unix
11.31操作系统重要信息内容是由系统内核和卷组管理器组成。在安装数据库集群软件(Serviceguard
Extension for RAC)和操作系统集群软件service guard)的时候,需要修改HP
unix的内核参数信息,所以这里信息比较重要。

        (6)容灾 (Disasters and extended outages)

4、启动Sun2服务器,进入root用户,在终端中使用命令进行系统分区文件备份,把原来Sun2服务器硬盘中的数据按分区完全备份到Sun1服务器硬盘中,首先可以使用format命令查看两块硬盘分区是否一致(dd拷贝必须保证两块硬盘的分区结构一致)。可以看到,我们的系统分区有5个,分别是

b)MC/service
guard 是HP
RX系列服务器的高可用性集群,在计算机软硬件出现故障时候,可以继续执行应用系统服务,是一种基于应用的可迁移方法。

        (7)计划宕机与维护 (Planned downtime, maintenance and management
tasks)

c1t0d0s0          /

c)卷组管理器是管理阵列盘,就是盘阵上的硬盘,就是双机热备要用到的物理存储。在HP
UX系统中对应关系是这样:LUN——VG(逻辑磁盘)——对应多个LV(逻辑卷),并挂在文件系统和未格式化裸设备(raw
device)——共享存储裸设备(shared raw device)。

       
可见,高可用不仅仅包含了系统本身故障,应用层的错误,人为错误等等,还应当包括数据冗余、容灾以及计划的维护时间,也就是说,一个真正的高可用环境,不仅仅是能避免系统本身的问题,还应当能防止天灾人祸,以及有一个简单可靠的系统维护方法(如微码升级、软件升级等等计划停机维护)。

c1t0d0s1          /usr

图片 1
图 1 HP unix双机系统集群技术层次构架

       
现在高可用的计算方法一般以年在线率来计算,如规定一年之中的可用环境要达到99.95%,那么24*365*(1-99.95%)=4.38小时(包括维护时间)。那么假定一个系统本身一年之中故障时间是1小时,但是计划维护时间却花了20小时,那么这个系统也不能算是一个满足设计要求的高可用环境。

c1t0d0s3          /swap

5)本次实施负载均衡方案是建立在加强网络数据处理能力,自动调节应用服务对两台节点上数据库的响应请求,分别对共享存储数据的读写服务操作,实现增加数据吞吐量和提高效率。

       
现阶段使用环境中,基本没有真正的100%的在线环境,或者说,如果达到100%的在线能力,将花费非常多的代价,所以一般能达到99.95%以上的可用性的环境,一般都可以认为是高可用环境。

c1t0d0s4          /opt

6)单点故障自动切换:2台主机(node1:40、node2:42)连接共享裸设备存储,同时只有一台主机对一个物理设备进行读写操作。系统定时发送heartbeat信息,一旦node1发生故障,系统自动切换到node2上。

        对于高可用性在线效率的计算,我们可以参考如下方法:

c1t0d0s7          /home

首先进行相应的网络规划,每台主机需要有4个局域网IP和2个私有IP,公共ip地址和浮动ip地址要在同一网段。如下表: 

 

然后使用dd命令进行备份

节点

主机名

IP

描述

1

node1

10.150.70.40

公共ip地址,管理用

1

node1-vip

10.150.70.41

浮动ip地址,提供对外的数据库服务

1

node1_priv

192.168.10.31

心跳ip地址,节点间通讯和数据同步用

2

node2

10.150.70.42

公共ip地址,管理用

2

node2-vip

10.150.70.43

浮动ip地址,提供对外的数据库服务

2

node2_priv

192.168.10.32

心跳ip地址,节点间通讯和数据同步用

 

# dd if=/dev/dsk/c1t0d0s0 of=/dev/dsk/c1t1d0s0 bs=1024k

 
随后以本次双机集群设置为例(如图示:集群硬件故障时-单点故障自动切换示意图-正常状态),node1包含一个应用服务包、一个浮动IP(node1-vip)和若干系统进程及应用占用的硬盘。同样,node
2也包含一个应用服务包、一个浮动IP(node2-vip)和若干系统进程及应用占用的硬盘。node1-vip、node2-vip地址是固定的,node1、node2可以保证各自稳定的为前端用户提供服务所对应的数据服务。同时,集群系统中没有任何一台机器都在时刻运行,没有闲置,各自运行自己的应用,资源利用得到合理配置,性能得到最大发挥。

图片 2

当备份结束时,将提示

如果node1在集群系统中出现软硬件或者网络故障,MC/service
guard自动将程序包控制权转移给node2。保证应用服务继续进行,同时所有负载压力加载到node2上。(如图示:集群硬件故障时-单点故障自动切换示意图-切换状态)

 

******+1 记录进入

图片 3
 图2 集群硬件故障时-单点故障自动切换示意图正常状态)

       
在公司收益与投入成本计算方面取得一个平衡,则是我们所希望的在线效率,但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题了,也是我们下面希望能试图解释的问题。

******+1 记录调出

图片 4
图3 集群硬件故障时-单点故障自动切换示意图切换状态)

        二、Oracle高可用相关功能的产品概述

然后依次备份其他分区

1.1 HP unix阵列盘信息

       
因为高可用的范围定义太广泛,本文我们只讨论与Oracle数据库有关系的高可用设计,如数据库主机的错误,数据所在的存储错误,介质损坏以及主机与数据的冗余保护等等,并不讨论应用层的设计,Oracle
提供支持high availability 相关产品主要有下面几种:

# dd if=/dev/dsk/c1t0d0s1 of=/dev/dsk/c1t1d0s1 bs=1024k

HP unix阵列盘信息:一共有10个磁盘设备: /dev/dsk/ c0t6d0、/dev/dsk/
c1t2d0、 /dev/dsk/ c2t6d0、/dev/dsk/ c5t15d0、
/dev/dsk/c4t15d1、/dev/dsk/ c4t15d2、/dev/dsk/ c4t15d3、/dev/dsk/
c4t15d4、/dev/dsk/c4t15d5、/dev/dsk/c4t15d6。

        (1) Oracle Parallel Server(8i)/ Real Application
Cluster(9i/10g)

# dd if=/dev/dsk/c1t0d0s3 of=/dev/dsk/c1t1d0s3 bs=1024k

Class     I  H/W Path       Driver S/W State   H/W Type     Description

=======================================================================

disk      0  0/0/0/2/0.6.0  sdisk   CLAIMED     DEVICE       HP 300 GMBA3300NC

                           /dev/dsk/c0t6d0     /dev/rdsk/c0t6d0 

                           /dev/dsk/c0t6d0s1   /dev/rdsk/c0t6d0s1

                           /dev/dsk/c0t6d0s2   /dev/rdsk/c0t6d0s2

                           /dev/dsk/c0t6d0s3   /dev/rdsk/c0t6d0s3

disk      1  0/0/0/2/1.2.0  sdisk   CLAIMED     DEVICE       HL-DT-STDVD-RAM GH40L

                           /dev/dsk/c1t2d0   /dev/rdsk/c1t2d0

disk      2  0/0/0/3/0.6.0  sdisk   CLAIMED     DEVICE       HP 300 GMBA3300NC

                           /dev/dsk/c2t6d0     /dev/rdsk/c2t6d0 

                           /dev/dsk/c2t6d0s1   /dev/rdsk/c2t6d0s1

                           /dev/dsk/c2t6d0s2   /dev/rdsk/c2t6d0s2

                           /dev/dsk/c2t6d0s3   /dev/rdsk/c2t6d0s3

disk      3  1/0/12/0/0/0/0.1.0.255.14.15.0  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d0   /dev/rdsk/c4t15d0

disk      4  1/0/12/0/0/0/0.1.0.255.14.15.1  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d1   /dev/rdsk/c4t15d1

disk      5  1/0/12/0/0/0/0.1.0.255.14.15.2  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d2   /dev/rdsk/c4t15d2

disk      6  1/0/12/0/0/0/0.1.0.255.14.15.3  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d3   /dev/rdsk/c4t15d3

disk      7  1/0/12/0/0/0/0.1.0.255.14.15.4  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d4   /dev/rdsk/c4t15d4

disk      8  1/0/12/0/0/0/0.1.0.255.14.15.5  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d5   /dev/rdsk/c4t15d5

disk      9  1/0/12/0/0/0/0.1.0.255.14.15.6  sdisk   CLAIMED   DEVICE   HITACHI DF600F

                           /dev/dsk/c4t15d6   /dev/rdsk/c4t15d6

        (2) Oracle Standby Database(8i)/Oracle Data Guard(9i/10g)

# dd if=/dev/dsk/c1t0d0s4 of=/dev/dsk/c1t1d0s4 bs=1024k

1.2 存储规划 

        (3) Oralce Advanced Replication(8i)/Oracle Stream(9i/10g)

# dd if=/dev/dsk/c1t0d0s7 of=/dev/dsk/c1t1d0s7 bs=1024k

HITACHI DF600F(日立存储)磁盘阵列划分为7个vDiskLUN)全部映射到两台主机。

        (4) Oracle Server HA

5、把备份完成的硬盘安装到Sun1服务器中,启动机器,将能够正确进入系统,说明系统还原成功。

具体划分如下: 

        (5) Other: Mv/RMAN/Oracle Log Miner/Oracle Flashback
Query(9/10gi)

6、把备份的两个用户文件包通过fpt传到Sun1上面。(这里由于ftp访问Solaris不能登录root用户,所以先要上传到其他用户中去,如这里上传到oracle用户目录下,然后在登录root用户把这个包拷贝到目录/export/home下面)

vDisk序号

容量/单位

磁盘设备

VG(逻辑磁盘)

用途说明

3

1GB

/dev/dsk/c4t15d0

/dev/datavg

ASM spfile

4

1GB

/dev/dsk/c4t15d1

/dev/datavg

OCR

5

1GB

/dev/dsk/c4t15d2

/dev/datavg

ORC镜像

6

1GB

/dev/dsk/c4t15d3

/dev/datavg

RAC表决盘

7

1GB

     /dev/dsk/c4t15d4

/dev/datavg

RAC表决盘镜像1

8

1GB

/dev/dsk/c4t15d5

/dev/datavg

RAC表决盘镜像2

9

700GB

/dev/dsk/c4t15d6

/dev/vg00/lvoracle

ASM 磁盘

       
等等,还有其他很多小的功能,如在线表的重定义,新的安全审计功能等,也都是为在线系统而设计的,但是,我们这里主要只考虑构架方面的高可用设计,也就是与成本有关系的高可用设计,怎么样达到成本与收益的最大平衡。

把原来的x1000用户和oracle用户目录的名称改变,然后在root用户下使用tar命令解包两个文件包

1.3 VG共享模式shared)状态

        所以,我们将主要讨论的是Oracle OPS/RAC、Standby/Ddata
guard、Advanced Replocation/Stream以及与Oracle Server相关的OS
HA(双机)。

# tar xvf oracle.tar

VG同时在两台的主机上(40和42)被激活。在应用Oracle
OPS时,这里卷组被以一种共享的方式激活,数据的完整性必须由应用程序来保证。

        1、OPS /RAC
        OPS/RAC 最原始的设计初衷就是system/application high
availability。与其他产品相比较: OPS/RAC
是多个服务器的cluster,组成具有更大计算处理能力与故障处理能力的集群。cluster
里面不同的 node 使用一个(一般是一个)或多个oracle instances
与一个database 连接(Shared Storage)。

# tar xvf x1000.tar

因为操作系统本身无法保证数据的完整性,所以设成共享模式激活的卷组必须使用裸设备,这样OS不会对该设备进行缓冲,而完全交给应用程序处理。

        主要的技术特点:

解包之后的两个文件夹的属性为root用户,所以需要更改为各自用户所拥有,使用命令进行修改

应用VG的共享方式需要安装MC/SG OPS edition.,其控制命令是vgchange –a s/n
 /dev /datavg。

        (1) database 所有的data files 是建立在共享存储(Shared
Storage)上面的,一般可以采用raw设备,共享文件系统或者是ASM(10g提供),因此在技术方面对OS
的设置有很高的依赖性,需要有OS支持的cluster软件。

# chown -R x1000:other x1000

VG对应多个LV(逻辑卷,并挂在文件系统和共享裸设备(shared raw
device)。这里对应系统VG逻辑磁盘是:/dev/datavg,包含oracle数据库安装、升级、加载信息等文件存储位置,都在这个/dev/datavg逻辑磁盘下,并划分进行相应的LV逻辑卷。以下是系统中oracle数据库文件对应的存储位置。

        (2)
OPS/RAC在共享存储方面并没有冗余保护,不具备在共享存储阵列损坏的情况下具有切换的能力,因此
media failure 方面,要依靠RAID (redundant array of inexpensive disk)
Subsystem、LV镜相(LV Mirror)、卷复制(Volume
Replication)或者是Standby/Data guard来实现数据的冗余保护。

# chown -R oracle:dba oracle

ll /dev/datavg/r*

crw-r—–   1 oracle     dba      64 0x020008 Sep 24 16:37 /dev/datavg/rdb_control01

crw-r—–   1 oracle     dba      64 0x020009 Sep 24 16:37 /dev/datavg/rdb_control02

crw-r—–   1 oracle     dba      64 0x02000a Sep 24 16:37 /dev/datavg/rdb_control03

crw-r—–   1 oracle     dba      64 0x020020 Sep 24 16:37 /dev/datavg/rdb_fwms_01

crw-r—–   1 oracle     dba      64 0x02001e Sep 24 16:37 /dev/datavg/rdb_lcam_01

crw-r—–   1 oracle     dba      64 0x02001f Sep 24 16:37 /dev/datavg/rdb_lcam_02

crw-r—–   1 oracle     dba      64 0x020014 Sep 24 16:37 /dev/datavg/rdb_redo1_01

crw-r—–   1 oracle     dba      64 0x020015 Sep 24 16:37 /dev/datavg/rdb_redo1_02

crw-r—–   1 oracle     dba      64 0x020016 Sep 24 16:37 /dev/datavg/rdb_redo1_03

crw-r—–   1 oracle     dba      64 0x020017 Sep 24 16:37 /dev/datavg/rdb_redo1_04

crw-r—–   1 oracle     dba      64 0x020018 Sep 24 16:37 /dev/datavg/rdb_redo1_05

crw-r—–   1 oracle     dba      64 0x020019 Sep 24 16:37 /dev/datavg/rdb_redo2_01

crw-r—–   1 oracle     dba      64 0x02001a Sep 24 16:37 /dev/datavg/rdb_redo2_02

crw-r—–   1 oracle     dba      64 0x02001b Sep 24 16:37 /dev/datavg/rdb_redo2_03

crw-r—–   1 oracle     dba      64 0x02001c Sep 24 16:37 /dev/datavg/rdb_redo2_04

crw-r—–   1 oracle     dba      64 0x02001d Sep 24 16:37 /dev/datavg/rdb_redo2_05

crw-r—–   1 oracle     dba      64 0x02000c Sep 24 16:37 /dev/datavg/rdb_sysaux01

crw-r—–   1 oracle     dba      64 0x02000d Sep 24 16:37 /dev/datavg/rdb_system01

crw-r—–   1 oracle     dba      64 0x02000e Sep 24 16:37 /dev/datavg/rdb_temp01

crw-r—–   1 oracle     dba      64 0x02000f Sep 24 16:37 /dev/datavg/rdb_temp02

crw-r—–   1 oracle     dba      64 0x020010 Sep 24 16:37/dev/datavg/rdb_undo1_01

crw-r—–   1 oracle     dba     64 0x020011 Sep 24 16:37 /dev/datavg/rdb_undo1_02

crw-r—–   1 oracle     dba     64 0x020012 Sep 24 16:37 /dev/datavg/rdb_undo2_01

crw-r—–   1 oracle     dba     64 0x020013 Sep 24 16:37 /dev/datavg/rdb_undo2_02

crw-r—–   1 oracle     dba     64 0x02000b Sep 24 16:37 /dev/datavg/rdb_users01

crw-r—–   1 oracle     dba     64 0x020026 Sep 24 16:37 /dev/datavg/rlvexp

crw-r—–   1 oracle     dba         64 0x02002b Sep 24 16:37 /dev/datavg/rlvwz_01

crw-r—–   1 oracle     dba         64 0x02002c Sep 24 16:37 /dev/datavg/rlvwz_02

crw-r—–   1 oracle     dba         64 0x02002d Sep 24 16:37 /dev/datavg/rlvwz_03

crw-r—–   1 oracle     dba         64 0x02002e Sep 24 16:37 /dev/datavg/rlvwz_04

crw-r—–   1 oracle     dba         64 0x02002f Sep 24 16:37 /dev/datavg/rlvwz_05

crw-r—–   1 oracle     dba         64 0x020030 Sep 24 16:37 /dev/datavg/rlvwz_06

crw-r—–   1 oracle     dba         64 0x020031 Sep 24 16:37 /dev/datavg/rlvwz_07

crw-r—–   1 oracle     dba         64 0x020032 Sep 24 16:37 /dev/datavg/rlvwz_08

crw-r—–   1 oracle     dba         64 0x020033 Sep 24 16:37 /dev/datavg/rlvwz_09

crw-r—–   1 oracle     dba         64 0x020034 Sep 24 16:37 /dev/datavg/rlvwz_10

crw-r—–   1 oracle     dba         64 0x020035 Sep 24 16:37 /dev/datavg/rlvwz_11

crw-r—–   1 oracle     dba         64 0x020036 Sep 24 16:37 /dev/datavg/rlvwz_12

crw-r—–   1 oracle     dba         64 0x020037 Sep 24 16:37 /dev/datavg/rlvwz_13

crw-r—–   1 oracle     dba         64 0x020038 Sep 24 16:37 /dev/datavg/rlvwz_14

crw-r—–   1 oracle     dba         64 0x020021 Sep 24 16:37 /dev/datavg/rlvwz_15

crw-r—–   1 oracle     dba         64 0x020022 Sep 24 16:37 /dev/datavg/rlvwz_16

crw-r—–   1 oracle     dba         64 0x020023 Sep 24 16:37 /dev/datavg/rlvwz_17

crw-r—–   1 oracle     dba         64 0x020024 Sep 24 16:37 /dev/datavg/rlvwz_18

crw-r—–   1 oracle     dba         64 0x020025 Sep 24 16:37 /dev/datavg/rlvwz_19

crw-r—–   1 oracle     dba    64 0x02003f Sep 24 16:37 /dev/datavg/rlvwz_archives01

crw-r—–   1 oracle     dba    64 0x020039 Sep 24 16:37/dev/datavg/rlvwz_archives02

crw-r—–   1 root       oinstall    64 0x020004 Sep 24 16:37 /dev/datavg/rora_crs01

crw-r—–   1 root       oinstall    64 0x020005 Sep 24 16:37 /dev/datavg/rora_crs02

crw-r—–   1 oracle     dba         64 0x020007 Sep 24 16:37 /dev/datavg/rora_pwd

crw-r—–   1 oracle     dba         64 0x020006 Sep 24 16:37 /dev/datavg/rora_spfile

crw-r—–   1 oracle     dba      64 0x020001 Sep 24 16:37 /dev/datavg/rora_vote01

crw-r—–   1 oracle     oinstall    64 0x020002 Sep 24 16:37 /dev/datavg/rora_vote02

crw-r—–   1 oracle     oinstall    64 0x020003 Sep 24 16:37 /dev/datavg/rora_vote03

       
(3)该技术是Oracle近来主推的技术,特别是10g以后的网格计算与线型扩展能力,在电信、移动、银行行业使用广泛。如果还是老的OPS,则不建议再使用,但是9i以后的Rac技术逐渐成熟,可以使用在高可用环境下,但是其管理成本与技术的复杂性,则也是需要考虑的。

7、登陆Oracle用户检查oracle是否启动成功,如果成功,则登陆x1000用户启动x1000监控系统,观察是否成功。

2、双机热备(VG独占模式)方案

        2、Advanced Replication /Stream

这样,就完成了Solaris系统的恢复工作。

此类是纯应用服务器的集群,即各个应用服务器都访问统一的数据库服务器,但彼此间并不需要文件共享存储等,这种集群是比较简单的。

        Advanced Replication 的设计初是分散异地的application access
database
locally
。这种技术可以将一个数据库中的objects复制到另一数据库中。如果是整个数据库的复制,也可用于高可用环境。

图片 5

2.1 VG独占模式exclusive)状态

        从Oracle
9i开始,Oracle更倾向使用Stream的技术,通过对归档日志的挖掘,可以在对主系统没有任何压力的情况下,实现对数据库的objects甚至整个数据库的同步。

当2台主机共享一个VG时,可以在2台主机上激活VG,那么其中随意一台主机都可以对数据进行修改,而其他的主机却不知道数据已被改变,这样数据的完整性无法保证。

        主要的技术特点:

所以在Cluster环境下,将共享VG的属性置为exclusive模式。这样,当一台主机已经以exclusive模式激活VG之后,在其他的主机上无法再激活这个VG,这样就保证了数据的完整性。应用VG独享方式需要安装MC/SG,其控制命令是vgchange
–c y/n vgXX。

       
(1)技术相对灵活,可以对单独的object,或者是整个数据库进行复制,而且作为stream,复制的压力更小,对主库没有压力,著名的复制软件share
plex就是采用类似的技术进行数据的复制的。