10g RAC 通过NFS进行备份和恢复

最新推荐文章于 2024-06-03 15:42:05 发布
最新推荐文章于 2024-06-03 15:42:05 发布
阅读量180 收藏
点赞数
文章标签： 网络 数据库

10g RAC 通过NFS进行备份和恢复

1.先设好NFS，备份与恢复与单机基本没有差别了！下面是过程，记下来，以备查阅：
rac1-> rman target / nocatalog

Recovery Manager: Release 10.2.0.1.0 - Production on Tue Nov 25 23:36:24 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: RACDB (DBID=667104169)
using target database control file instead of recovery catalog

RMAN> run{
2>  backup database    format '/rmanset/full_%d%t%s%p'         tag 'fullbackup';
3>  sql 'alter system archive log current';
4>  BACKUP FORMAT '/rmanset/%d_arch_%s_%p_%h' ARCHIVELOG ALL;                                        
5>  backup format '/rmanset/cf_%d' current controlfile;                                                    
6>  }

Starting backup at 25-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=117 instance=racdb1 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=+RACDATA/racdb/datafile/system.259.669487425
input datafile fno=00003 name=+RACDATA/racdb/datafile/sysaux.261.669487497
input datafile fno=00002 name=+RACDATA/racdb/datafile/undotbs1.260.669487479
input datafile fno=00004 name=+RACDATA/racdb/datafile/undotbs2.263.669487539
input datafile fno=00006 name=+RACDATA/racdb/datafile/rman_backup.268.671103645
input datafile fno=00005 name=+RACDATA/racdb/datafile/users.264.669487561
channel ORA_DISK_1: starting piece 1 at 25-NOV-08
channel ORA_DISK_1: finished piece 1 at 25-NOV-08
piece handle=/rmanset/full_RACDB6717585971871 tag=FULLBACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:46
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 25-NOV-08
channel ORA_DISK_1: finished piece 1 at 25-NOV-08
piece handle=/rmanset/full_RACDB6717587631881 tag=FULLBACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09
Finished backup at 25-NOV-08

sql statement: alter system archive log current

Starting backup at 25-NOV-08
current log archived
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/25/2008 23:39:45
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /racdb2_arch/2_2_671755092.dbf
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

RMAN> run{
2>   sql 'alter system archive log current';
3>  BACKUP FORMAT '/rmanset/%d_arch_%s_%p_%h' ARCHIVELOG ALL;                                        
4>  backup format '/rmanset/cf_%d' current controlfile;                                                    
5>  }

sql statement: alter system archive log current

Starting backup at 25-NOV-08
current log archived
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/25/2008 23:41:43
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /racdb2_arch/2_2_671755092.dbf
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3

 


---从杨版主之摘之。。。。
从Metalink的查询看，这个错误还比较普遍。在文章Note:424785.1里面进行了比较详细的描述。

解决方法包括设置事件10298 level 32，打补丁：5146667，或者在mount的时候设置参数：rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0。

注意metalink上给出的参数并非对所有系统都适用，比如在Solaris8上就要去掉tcp参数。而去掉了tcp之后，似乎这种方法就不生效了。

剩下两种方式，打补丁需要将数据库关闭，而且一般使用NFS都是用在Rac的环境，补丁还需要在两个节点上同时打，比较麻烦。

而设置EVENT虽然简单，只是要重启系统才能生效。

设置Oracle的事件10298，并重启数据库：

$ sqlplus "/as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期二 5月 29 16:06:32 2007

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> alter system set event='10298 trace name context forever, level 32' scope = spfile;

系统已更改。

SQL> exit 从 Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

----------


rac1-> vi /etc/fstab

# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/                 /                       ext3    defaults        1 1
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0
rac2:/racdb2_arch /racdb2_arch  nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0
/dev/hdc                /media/cdrecorder       auto    pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0
/dev/fd0                /media/floppy           auto    pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0
~

rac1-> umount /racdb2_arch
rac1-> mount -all

 

rac1-> rman target / nocatalog

Recovery Manager: Release 10.2.0.1.0 - Production on Wed Nov 26 00:16:52 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database (not started)

RMAN> startup nomount

Oracle instance started

Total System Global Area     171966464 bytes

Fixed Size                     1218340 bytes
Variable Size                121637084 bytes
Database Buffers              46137344 bytes
Redo Buffers                   2973696 bytes

RMAN> restore controlfile from '/rmanset/cf_RACDB'; 

Starting restore at 26-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 instance=racdb1 devtype=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:11
output filename=+RACDATA/racdb/controlfile/current.256.669487407
Finished restore at 26-NOV-08

 

RMAN> sql 'alter database mount';

sql statement: alter database mount
released channel: ORA_DISK_1

RMAN> run{
2> restore database;
3> recover database;
4> }

Starting restore at 26-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 instance=racdb1 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to +RACDATA/racdb/datafile/system.259.669487425
restoring datafile 00002 to +RACDATA/racdb/datafile/undotbs1.260.669487479
restoring datafile 00003 to +RACDATA/racdb/datafile/sysaux.261.669487497
restoring datafile 00004 to +RACDATA/racdb/datafile/undotbs2.263.669487539
restoring datafile 00005 to +RACDATA/racdb/datafile/users.264.669487561
restoring datafile 00006 to +RACDATA/racdb/datafile/rman_backup.268.671103645
channel ORA_DISK_1: reading from backup piece /rmanset/full_RACDB6717585971871
channel ORA_DISK_1: restored backup piece 1
piece handle=/rmanset/full_RACDB6717585971871 tag=FULLBACKUP
channel ORA_DISK_1: restore complete, elapsed time: 00:02:17
Finished restore at 26-NOV-08

Starting recover at 26-NOV-08
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 7 is already on disk as file /racdb1_arch/1_7_671755092.dbf
archive log thread 1 sequence 8 is already on disk as file /racdb1_arch/1_8_671755092.dbf
archive log thread 1 sequence 9 is already on disk as file /racdb1_arch/1_9_671755092.dbf
archive log thread 1 sequence 10 is already on disk as file /racdb1_arch/1_10_671755092.dbf
archive log thread 1 sequence 11 is already on disk as file /racdb1_arch/1_11_671755092.dbf
archive log thread 1 sequence 12 is already on disk as file /racdb1_arch/1_12_671755092.dbf
archive log thread 1 sequence 13 is already on disk as file /racdb1_arch/1_13_671755092.dbf
archive log thread 1 sequence 14 is already on disk as file /racdb1_arch/1_14_671755092.dbf
archive log thread 1 sequence 15 is already on disk as file /racdb1_arch/1_15_671755092.dbf
archive log thread 1 sequence 16 is already on disk as file /racdb1_arch/1_16_671755092.dbf
archive log thread 1 sequence 17 is already on disk as file /racdb1_arch/1_17_671755092.dbf
archive log thread 1 sequence 18 is already on disk as file /racdb1_arch/1_18_671755092.dbf
archive log thread 1 sequence 19 is already on disk as file /racdb1_arch/1_19_671755092.dbf
archive log thread 1 sequence 20 is already on disk as file /racdb1_arch/1_20_671755092.dbf
archive log thread 1 sequence 21 is already on disk as file /racdb1_arch/1_21_671755092.dbf
archive log thread 1 sequence 22 is already on disk as file /racdb1_arch/1_22_671755092.dbf
archive log thread 1 sequence 23 is already on disk as file /racdb1_arch/1_23_671755092.dbf
archive log thread 1 sequence 24 is already on disk as file /racdb1_arch/1_24_671755092.dbf
archive log thread 1 sequence 25 is already on disk as file /racdb1_arch/1_25_671755092.dbf
archive log thread 1 sequence 26 is already on disk as file /racdb1_arch/1_26_671755092.dbf
archive log thread 1 sequence 27 is already on disk as file +RACDATA/racdb/onlinelog/group_1.257.669487411
archive log thread 1 sequence 28 is already on disk as file +RACDATA/racdb/onlinelog/group_2.258.669487419
archive log thread 2 sequence 6 is already on disk as file /racdb2_arch/2_6_671755092.dbf
archive log thread 2 sequence 7 is already on disk as file /racdb2_arch/2_7_671755092.dbf
archive log thread 2 sequence 8 is already on disk as file /racdb2_arch/2_8_671755092.dbf
archive log thread 2 sequence 9 is already on disk as file /racdb2_arch/2_9_671755092.dbf
archive log thread 2 sequence 10 is already on disk as file /racdb2_arch/2_10_671755092.dbf
archive log thread 2 sequence 11 is already on disk as file /racdb2_arch/2_11_671755092.dbf
archive log thread 2 sequence 12 is already on disk as file /racdb2_arch/2_12_671755092.dbf
archive log thread 2 sequence 13 is already on disk as file /racdb2_arch/2_13_671755092.dbf
archive log thread 2 sequence 14 is already on disk as file /racdb2_arch/2_14_671755092.dbf
archive log thread 2 sequence 15 is already on disk as file /racdb2_arch/2_15_671755092.dbf
archive log thread 2 sequence 16 is already on disk as file /racdb2_arch/2_16_671755092.dbf
archive log thread 2 sequence 17 is already on disk as file /racdb2_arch/2_17_671755092.dbf
archive log thread 2 sequence 18 is already on disk as file /racdb2_arch/2_18_671755092.dbf
archive log thread 2 sequence 19 is already on disk as file /racdb2_arch/2_19_671755092.dbf
archive log thread 2 sequence 20 is already on disk as file /racdb2_arch/2_20_671755092.dbf
archive log thread 2 sequence 21 is already on disk as file /racdb2_arch/2_21_671755092.dbf
archive log thread 2 sequence 22 is already on disk as file /racdb2_arch/2_22_671755092.dbf
archive log thread 2 sequence 23 is already on disk as file /racdb2_arch/2_23_671755092.dbf
archive log thread 2 sequence 24 is already on disk as file /racdb2_arch/2_24_671755092.dbf
archive log thread 2 sequence 25 is already on disk as file /racdb2_arch/2_25_671755092.dbf
archive log thread 2 sequence 26 is already on disk as file +RACDATA/racdb/onlinelog/group_3.265.669489319
archive log thread 2 sequence 27 is already on disk as file +RACDATA/racdb/onlinelog/group_4.266.669489327
archive log filename=/racdb1_arch/1_7_671755092.dbf thread=1 sequence=7
archive log filename=/racdb2_arch/2_6_671755092.dbf thread=2 sequence=6
archive log filename=/racdb2_arch/2_7_671755092.dbf thread=2 sequence=7
archive log filename=/racdb1_arch/1_8_671755092.dbf thread=1 sequence=8
archive log filename=/racdb2_arch/2_8_671755092.dbf thread=2 sequence=8
archive log filename=/racdb1_arch/1_9_671755092.dbf thread=1 sequence=9
archive log filename=/racdb1_arch/1_10_671755092.dbf thread=1 sequence=10
archive log filename=/racdb2_arch/2_9_671755092.dbf thread=2 sequence=9
archive log filename=/racdb2_arch/2_10_671755092.dbf thread=2 sequence=10
archive log filename=/racdb1_arch/1_11_671755092.dbf thread=1 sequence=11
archive log filename=/racdb1_arch/1_12_671755092.dbf thread=1 sequence=12
archive log filename=/racdb2_arch/2_11_671755092.dbf thread=2 sequence=11
archive log filename=/racdb1_arch/1_13_671755092.dbf thread=1 sequence=13
archive log filename=/racdb2_arch/2_12_671755092.dbf thread=2 sequence=12
archive log filename=/racdb2_arch/2_13_671755092.dbf thread=2 sequence=13
archive log filename=/racdb1_arch/1_14_671755092.dbf thread=1 sequence=14
archive log filename=/racdb2_arch/2_14_671755092.dbf thread=2 sequence=14
archive log filename=/racdb1_arch/1_15_671755092.dbf thread=1 sequence=15
archive log filename=/racdb2_arch/2_15_671755092.dbf thread=2 sequence=15
archive log filename=/racdb1_arch/1_16_671755092.dbf thread=1 sequence=16
archive log filename=/racdb1_arch/1_17_671755092.dbf thread=1 sequence=17
archive log filename=/racdb2_arch/2_16_671755092.dbf thread=2 sequence=16
archive log filename=/racdb2_arch/2_17_671755092.dbf thread=2 sequence=17
archive log filename=/racdb1_arch/1_18_671755092.dbf thread=1 sequence=18
archive log filename=/racdb1_arch/1_19_671755092.dbf thread=1 sequence=19
archive log filename=/racdb2_arch/2_18_671755092.dbf thread=2 sequence=18
archive log filename=/racdb1_arch/1_20_671755092.dbf thread=1 sequence=20
archive log filename=/racdb2_arch/2_19_671755092.dbf thread=2 sequence=19
archive log filename=/racdb1_arch/1_21_671755092.dbf thread=1 sequence=21
archive log filename=/racdb2_arch/2_20_671755092.dbf thread=2 sequence=20
archive log filename=/racdb2_arch/2_21_671755092.dbf thread=2 sequence=21
archive log filename=/racdb1_arch/1_22_671755092.dbf thread=1 sequence=22
archive log filename=/racdb1_arch/1_23_671755092.dbf thread=1 sequence=23
archive log filename=/racdb2_arch/2_22_671755092.dbf thread=2 sequence=22
archive log filename=/racdb2_arch/2_23_671755092.dbf thread=2 sequence=23
archive log filename=/racdb1_arch/1_24_671755092.dbf thread=1 sequence=24
archive log filename=/racdb2_arch/2_24_671755092.dbf thread=2 sequence=24
archive log filename=/racdb1_arch/1_25_671755092.dbf thread=1 sequence=25
archive log filename=/racdb1_arch/1_26_671755092.dbf thread=1 sequence=26
archive log filename=/racdb2_arch/2_25_671755092.dbf thread=2 sequence=25
archive log filename=+RACDATA/racdb/onlinelog/group_3.265.669489319 thread=2 sequence=26
archive log filename=+RACDATA/racdb/onlinelog/group_1.257.669487411 thread=1 sequence=27
archive log filename=+RACDATA/racdb/onlinelog/group_2.258.669487419 thread=1 sequence=28
archive log filename=+RACDATA/racdb/onlinelog/group_4.266.669489327 thread=2 sequence=27
media recovery complete, elapsed time: 00:00:21
Finished recover at 26-NOV-08

RMAN>

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10834762/viewspace-503310/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10834762/viewspace-503310/

cka6619
关注
利用nfs实现数据库的异地备份与恢复
云原生运维圈
10-11 1609
mysql（mariadb）数据库备份的重要性： 数据是一个数据库最重要的文件之一，当我们的数据库损坏时我们的很多程序都会受到影响，以至于影响公司的正常运转。现在越来越多的企业开始越来越重视数据库了，所以就要求我们对数据库进行备份，甚至要实现数据库表要放在远程服务器中。 本次实验利用nfs的数据共享来实现对数据库表放在远程和备份到远程的操作 nfs服务端： [root@localhost ~]# ...
Easticsearch从0学到1之nfs快照备份与恢复
yang52017的博客
03-30 780
Easticsearch从0学到1之nfs快照备份与恢复背景软件环境nfs挂载服务端客户端测试nfs是否挂载成功问题解决办法快照与恢复快照恢复跨集群恢复参考文献 背景 无论使用哪个存储数据的软件，定期备份你的数据都是很重要的。Elasticsearch 副本提供了高可靠性；它们让你可以容忍零星的节点丢失而不会中断服务。 但是，副本并不提供对灾难性故障的保护。对这种情况，你需要的是对集群真正的备份—...
ES备份数据-快照模式-并恢复---NFS篇
最新发布
cz124560的博客
06-03 1066
我这边采用快照的模式进行备份数据 备份源的es 版本要等于低于恢复elasticsearch集群的版本； 先看下： ES集群快照存在版本兼容性问题：https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html 首先为快照目录建立共享 我这边用的是nfs
Centos7.4在vmware6.5下基于nfs和dd实现虚机的备份恢复
kadwf123的专栏
12-27 687
目录 1、背景说明... 2 2、搭建nfs服务器... 2 2.1、nfs服务端安装包... 2 2.2、关闭防火墙... 3 2.3、创建共享目录... 3 2.4、挂载数据盘... 3 2.4.1、磁盘分区... 3 2.4.2、创建pv. 3 2.4.3、创建vg. 3 2.4.4、创建lv. 4 2.4.5、格式化lv. 4 2.4.6、挂载lv. 4 2.4....
oracle rac mount,rac归档日志放在本地使用NFS MOUNT方式解决（生产慎用）
weixin_39804059的博客
04-09 201
三、归档日志放在本地，使用NFS解决NFS MOUNT方式来实现。准备部分：采用这个方法需要保证每个节点的归档目的地都是唯一的，并将这个归档目的地以NFS MOUNT方式加载到远端站点。首先在两个节点上分别建立归档的目的目录：# su - oracleSun Microsystems Inc. SunOS 5.8 Generic Patch October 2001$ mkdir /data1/a...
oracle11g rac+redhat5.5集群配置
10-17
Oracle 11g RAC（Real Application Clusters）是一种高可用性和可伸缩性的数据库解决方案，它允许多个实例共享同一个数据库，以提供无中断的服务和数据访问。在Red Hat Enterprise Linux 5.5（RHEL 5.5）上配置...
Oracle10g RAC切换到归档模式详细步骤
"Oracle10g RAC归档模式的修改和管理，涉及数据库的状态检查、参数修改、归档日志处理" Oracle10g Real Application Clusters (RAC) 是一个高可用性的数据库解决方案，它允许多个实例同时访问同一个物理数据库。在...
Oracle 10G RAC在Linux上的安装与配置指南
RAC的日常管理也包括监控资源使用情况，定期进行维护和更新，以及备份和恢复策略的制定。 Oracle 10G RAC的实施是一项复杂但强大的技术，它可以提供高可用性，增强系统的稳定性和性能。然而，正确配置和管理RAC需要...
Oracle 11gR1 RAC On Linux Using NFS
01-03
RAC通过共享存储来实现数据的一致性和高可用性，提高了系统的整体性能和容错能力。 二、Oracle 11gR1版本特性 Oracle 11g Release 1是Oracle数据库的一个重要版本，引入了诸如快速应用故障切换、自动工作负载管理、...
手把手教你用VMware在Linux下安装Oracle 10g RAC
04-21
**Oracle 10g RAC (Real Application Clusters)** 是Oracle数据库的一个高级特性，它允许多个数据库实例同时运行在一个集群环境中，提供高可用性和负载均衡的能力。RAC环境下的每个节点都可以独立地访问共享数据，而...
Oracle数据库备份与恢复 - RMAN备份
田攀的日志
07-05 8468
如果要说DBA工作中最重要的职责（没有之一），那无疑就是保证客户数据的安全和完整，可以看到几乎任何一本Oracle DBA的技术书籍一定都会把大篇幅来介绍数据库的备份与恢复，从中也可以看到备份和恢复的重要程度。eygle曾经总结了DBA生存之四大守则的第一条就是：备份重于一切我们必需知道,系统总是要崩溃的，没有有效的备份只是等哪一天死！我经常开玩笑的说,唯一会使DBA在梦中惊醒的就是,没有有效的备
nfs服务检测与自动恢复
茗迹周的博客
12-09 3220
nfs服务检测与自动恢复nfs服务检测与自动恢复场景分析 检测思路 测试用例验证 实现代码 场景分析平台目前使用的存储为nfs和gluster网络文件系统，出现的问题一般是C/S端服务异常。nfs服务异常时会导致目录列表（df -h 或者cd）无法输出，主要是因为系统后台一直在尝试挂载，虽然nfs有retry尝试次数选项，但是服务端恢复就没法及时挂载上（目录依旧无法显示）。看来只能自己动手，丰衣足食
NFS或iSCSI哪个更好
热门推荐
远有青山
09-10 2万+
难以做出的抉择：NFS或iSCSI哪个更好? 2012-05-31 16:05  来源:网界网  Matt Prigge   http://tech.watchstor.com/storage-network-138184.htm 摘要：与NFS和iSCSI是虚拟化所使用的两大IP存储协议。而与很多引起热烈争论的IT话题一样，NFS或iSCSI，哪个更好?要在任何两种
一文读懂 OceanBase 数据库的启动恢复代码解析
OceanBase分布式数据库的博客
09-22 394
作者简介：镜水，一个致力于无限进步的数据库学徒。 作者简介：海芊，一个致力于当网红的 OceanBase 文档工程师。个人频道：Amber loves OB 本文主要介绍 OceanBase 数据库启动时是如何将已持久化的日志和数据恢复到内存，重新形成各类信息（如租户信息、分区信息等）的内存映像，从而回到宕机前的状态。 在介绍具体的恢复流程之前，我们首先来了解一些与之相关的存储结构。 存储数据结构 MacroBlock OceanBase 数据库将数据分为增量数据和基线数据，基线数据是几乎占满整
RAC 之 RMAN 恢复
David Dai -- Focus on Oracle
09-27 1万+
之前整理的RMAN 有关还原的文章：         RMAN 系列（五） ---- RMAN 还原与恢复      http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5700474.aspx      RMAN 备份与恢复实例      http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4699320.aspx         Oracle Rman跨resetlogs版本恢复
Oracle10g RAC的安装(使用NFS代替共享存储)
李超的专栏
09-22 1776
说起Oracle10g RAC的安装,由于个人缺少设备(但是还想学),所以出现了很多版本.单机版 :  安装起来相对简单,适合初学的时候先熟悉一下安装过程.iscsi双节点版 :   比较理想的一种方案(官方推荐的嘛)以上都是使用ocfs2 + asm,今天心血来潮用nfs代替共享存储装一个双节点的RAC安装过程中大部分步骤与iscsi双节点版相同,只是在设置共享存储时不用安装oc
利用nfs网络文件系统实现共享资源
lilygg的博客
11-28 2777
使用cifs方式的多用户挂载，不论所否使用共享资源，共享目录都挂载着的，这样很占用内存。 想要达到使用共享资源时，共享目录自动挂载，而在不使用共享资源时，共享目录便会自动卸载。 而 cifs是无法做到的，此任务可以由nfs文件系统实现 1.nfs文件系统方式永久性挂载 在服务端： ##1.安装nfs服务 [root@service ~]# yum install -y nfs-utils ...
Docker no space left on device 10G限制 nfs块 devicemapper
q742971636的博客
12-29 1063
有一个nfs盘挂载到本机，本机docker想用这个nfs盘存储。 此时docker自动用起了devicemapper 。 docker 用 devicemapper 这个后备存储有个默认卷的限制，是10g。现在都用overlay2了。 dd 解决，首先在nfs盘里面dd出一个500G大文件系统出来： dd if=/dev/zero of=/home/kevin_xie/yifeinfs/docker.data bs=1G count=500 dd 用来复制、抽取、转换文件，这里复制、抽取的大小可以以具体
ORACLE数据库备份管理-rman备份到NFS
oradbm的博客
11-12 858
1 linux -linux mkdir-p/data chown-R nfsnobody:nfsnobody/data chmod 777 /data vi /etc/exports /data/nfs192.168.86.131(rw) /data/nfs192.168.1.0/24(rw) /data/nfs192.168.1.0/24(rw) 192...
Oracle RAC+ASM 数据库备份与恢复实战
在Oracle 10g RAC + ASM环境下，归档日志文件存储在ASM磁盘上，这意味着它们对于所有实例都是可见的。进行备份时，通常只需要在一个节点上执行相关操作即可。以下是一个简单的备份示例： 1. **备份过程**： 在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值