记一次云服务器转移数据挂载点/系统/数据盘切换

本文详细介绍了一台云服务器如何解决初始安装时未充分考虑的数据盘利用问题。具体步骤包括:检查磁盘状态、对未分配的数据盘进行分区、格式化新分区、迁移/www目录下数据到新分区并修改启动配置。

最近一台云服务器当初安装的时候没有考虑数据盘加载的问题,发现直接挂载的系统分区一共才40G,而站点数据所在的分区/www加上系统本身一共占用了将近一半的容量,这样长期运营,很快就会磁盘空间不够导致很大的隐患,于是决定把默认的数据盘充分利用起来。

默认云自带的数据盘是未格式化,未挂载的一块数据盘,这点对于Linux的新手来说足够坑爹,同样国外的linode就做得比这个要好,直接就挂载上去了,降低了使用门槛,当然话说回来,想自己折腾centos系统,提高水平,不会操作分区挂载分区就算没有入门,好了闲话少说言归正传:

云主机数据盘未做分区和格式化,可以根据以下步骤进行分区以及格式化操作。下面的操作将会把数据盘划分为一个分区来使用。

1、查看数据盘

在没有分区和格式化数据盘之前,使用 “df –h”命令,是无法看到数据盘的,可以使用“fdisk -l”命令查看。

得到信息如下:

2、 对数据盘进行分区

执行“fdisk /dev/xvdb”命令,对数据盘进行分区;

根据提示,依次输入“n”,“p”“1”,两次回车,“wq”,分区就开始了,很快就会完成。

3、 查看新的分区

使用“fdisk -l”命令可以看到,新的分区xvdb1已经建立完成了。

4、格式化新分区

使用“mkfs.ext3 /dev/xvdb1”命令对新分区进行格式化,格式化的时间根据硬盘大小有所不同。

5、接下来的步骤是关键,因为我这台云主机是正在运行wdcp的,因此/www里边的数据一定要转移出来,否则,贸然挂载很可能造成这个分区数据全部丢失的噩梦,先创建一个临时目录
mkdir /mnt/data
挂截
mount /dev/xvdb1 /mnt/data

6、移动数据
先停上相关的服务,如
service mysqld stop
service httpd stop
service nginxd stop
service pureftpd stop
service wdapache stop
移动数据
mv /www/* /mnt/data

7、修改启动选项
vim /etc/fstab
增加一行,如下
/dev/xvdb1 /www ext3 defaults 1 2
保存退出,然后reboot一下,就顺利完成,是不是很简单,你也试试看吧。

<think>好的,我现在要解决用户的问题:如何在Oracle 19C服务器宕机后,将数据盘数据恢复到新购买的服务器上。用户需要的是迁移方案和数据恢复的方法,还提到了故障转移。首先,我需要回忆Oracle数据库迁移和恢复的常见方法,并结合用户提到的引用内容来寻找线索。 用户提供的引用中有提到TAF(透明应用程序故障转移)[^1],这可能和故障转移有关,但用户现在的情况是服务器宕机,需要迁移到新服务器,所以可能需要先恢复数据,再配置高可用性。引用[3]提到表空间脱机和数据文件处理,这可能与备份恢复有关。另外,引用中提到了数据泵和OGG迁移工具,这些可能是关键。 首先,考虑用户的数据盘是否完好。如果原服务器的数据文件、控制文件、在线日志等都在,可以采用物理备份恢复的方法。比如,冷备份:关闭数据库后复制所有文件到新服务器,或者热备份:在归档模式下进行备份。但原服务器已经宕机,可能无法正常关闭,所以可能需要利用已有的备份,比如RMAN备份。 如果用户没有备份,但数据盘还在,可能需要将数据文件直接拷贝到新服务器,然后进行恢复。这需要新服务器的Oracle版本和目录结构与原服务器一致,或者通过修改控制文件等方式调整路径。 另外,数据泵导出导入(expdp/impdp)是逻辑备份方法,适用于跨平台或同存储结构的情况,但需要数据库能够启动导出。如果原服务器宕机无法启动,可能无法使用这种方法。过,如果用户有之前的导出文件,可以用它来导入新库。 OGG(GoldenGate)是用于实时数据复制的工具,但需要在原服务器正常运行的时候配置,现在可能适用,除非之前已经设置好了OGG的复制环境。 引用中还提到使用rowid分片导出大表,这可能是在数据泵中处理大表的方法,但同样需要数据库可用。 接下来,步骤可能包括: 1. 确认原服务器数据盘的完整性,是否有所有必要的文件:数据文件、控制文件、在线重做日志、参数文件、密码文件等。 2. 如果数据盘完整,将整个ORACLE_HOME和数据文件目录结构复制到新服务器,确保Oracle软件版本相同,然后启动实例。可能需要调整参数文件中的目录路径,特别是如果新服务器的文件系统路径同的话。 3. 如果使用RMAN备份,需要将备份文件转移到新服务器,进行恢复。可能需要恢复控制文件,然后进行数据库恢复。 4. 如果原库无法启动,但数据文件完好,可以尝试在新服务器上通过启动到mount状态,进行恢复。例如,使用“recover database”命令应用归档日志,然后打开数据库。 5. 如果目录结构同,可能需要使用RMAN的catalog命令重新注册数据文件,并执行set newname修改路径,再恢复。 6. 配置监听和tnsnames.ora文件,确保新服务器的网络配置正确。 7. 测试数据库的可用性,检查数据完整性。 此外,用户提到故障转移,可能需要配置TAF或者Data Guard来实现高可用性,防止未来宕机的影响。引用[1]中的TAF配置可能在新服务器恢复后作为后续步骤。 还需要考虑归档模式:如果原数据库在归档模式下,恢复会更方便,因为可以使用归档日志进行完全恢复。如果是非归档模式,可能需要依赖在线日志,但如果宕机时日志损坏,可能会有数据丢失。 根据引用[3],在归档模式下,即使数据文件丢失,可能有办法恢复,但用户的情况是数据盘还在,所以可能需要处理这种情况。 可能的迁移方案步骤: - 物理冷迁移:关闭数据库,拷贝所有文件到新服务器,启动实例。但原服务器已宕机,可能无法正常关闭,导致需要恢复。 - RMAN恢复:使用之前的RMAN备份在新服务器上恢复。 - 数据泵逻辑导出/导入:如果原库无法启动,可能可行,除非有之前的导出文件。 现在,用户的情况是原服务器宕机,数据盘数据需要迁移到新服务器。假设数据盘未被损坏,可以直接访问,那么可能的方法是: 1. 在新服务器上安装相同版本的Oracle 19C软件,相同的ORACLE_HOME路径,或者调整参数文件中的路径。 2. 将原数据盘的所有数据文件、控制文件、在线日志、参数文件等复制到新服务器的相应位置。 3. 如果目录结构同,修改参数文件(pfile或spfile)中的控制文件路径,以及其他相关参数(如db_name等是否需要修改?通常db_name应相同,否则需要重建控制文件)。 4. 启动数据库到nomount状态,根据参数文件中的控制文件路径,找到控制文件,然后mount数据库。 5. 执行recover database,应用必要的归档日志和在线日志。 6. 打开数据库,可能需要使用resetlogs选项,特别是如果恢复过程中应用了归档日志。 但具体步骤可能因情况而异,比如是否在归档模式,是否有可用的归档日志。 如果原数据库的spfile丢失,可能需要手动创建pfile,指定正确的参数。 另外,如果原服务器和新服务器的操作系统或目录结构同,可能需要使用RMAN的跨平台迁移工具,例如使用RMAN的convert命令转文件格式或路径。 在用户引用中,提到使用数据泵利用rowid分片导出LOB大表,如果物理文件无法直接使用,可能需要用数据泵导出,但需要原库能够启动,否则可行。 因此,总结可能的方案: 方案一:物理文件迁移 1. 在新服务器安装相同版本的Oracle 19C,最好相同的目录结构。 2. 复制所有数据文件、控制文件、在线日志、参数文件等到新服务器。 3. 启动实例,检查路径是否需要调整,修改参数文件。 4. 恢复并打开数据库。 方案二:使用RMAN备份恢复 1. 将RMAN备份文件传输到新服务器。 2. 使用RMAN还原控制文件,恢复数据库。 方案三:数据泵导入导出(若原库无法启动则可行) 需要expdp导出文件,然后在新服务器impdp导入。 但用户的情况是原服务器宕机,可能无法导出,所以方案一或二更可行。 此外,故障转移方面,可以考虑在新服务器恢复后配置Data Guard或TAF,实现高可用性[^1]。 可能的问题:如果原数据库的在线日志未被归档,且数据库异常关闭,可能需要做完全恢复,导致数据丢失。因此,需要确认归档模式和日志的完整性。 另外,用户可能需要在新服务器上重新配置监听、tnsnames.ora等网络配置,确保客户端可以连接。 现在需要将上述思路整理成步骤,并参考用户提供的引用内容,特别是引用[1]中的TAF配置可能作为后续的高可用建议,引用[3]关于表空间和数据文件的操作可能涉及在恢复过程中处理脱机文件。 可能还需要注意权限问题,如文件所属用户和组是否正确,以及Oracle用户的环境变量配置。 最后,生成相关问题,帮助用户进一步了解迁移和恢复的其他方面。</think>### Oracle 19C 数据库迁移与数据恢复方案 #### 一、物理文件迁移(适用于数据盘完整) 1. **环境准备** - 新服务器安装相同版本的 Oracle 19C 软件,保持 `ORACLE_HOME` 路径与原服务器一致。若路径同,需修改参数文件中的相关路径[^3]。 - 确保操作系统版本和字符集与原服务器一致。 2. **数据文件迁移** - 将原服务器数据盘中的以下文件完整复制到新服务器对应路径: - 数据文件(`*.dbf`) - 控制文件(`*.ctl`) - 在线重做日志文件(`*.log`) - 参数文件(`spfile` 或 `pfile`) - 归档日志(若存在) 3. **参数文件调整** - 若目录结构同,手动修改 `pfile` 中的 `control_files` 参数指向新路径: ```sql control_files = '/new_path/control01.ctl' ``` - 通过 `pfile` 重新生成 `spfile`: ```sql CREATE SPFILE FROM PFILE='/path/to/init.ora'; ``` 4. **启动数据库** - 启动到 `nomount` 状态加载参数文件: ```sql STARTUP NOMOUNT; ``` - 加载控制文件并挂载数据库: ```sql ALTER DATABASE MOUNT; ``` - 执行恢复并打开数据库: ```sql RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; ``` #### 二、RMAN 备份恢复(适用于有可用备份) 1. **备份文件传输** - 将 RMAN 备份文件(包括数据文件、控制文件、归档日志)传输到新服务器。 2. **恢复控制文件** ```sql RESTORE CONTROLFILE FROM '/backup/control.bkp'; ALTER DATABASE MOUNT; ``` 3. **恢复数据文件** ```sql RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; ``` #### 三、故障转移与高可用配置(可选) 1. **配置 TAF(透明应用故障转移)** - 在 `tnsnames.ora` 中添加 `FAILOVER_MODE` 参数,实现客户端自动重连[^1]: ``` SERVICE_NAME = orcl (FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)) ``` 2. **部署 Data Guard** - 配置物理备库,实现实时数据同步,确保主库故障时快速切换[^3]。 #### 四、注意事项 - **归档模式**:若原库为归档模式,需确保所有归档日志已完整迁移,否则需进行完全恢复[^3]。 - **文件权限**:检查新服务器文件权限,确保 `oracle` 用户有读写权限。 - **日志验证**:恢复后执行 `SELECT * FROM v$database_block_corruption` 检查数据块完整性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值