分类目录归档：RAC

11.2单机数据库转换为RAC-1-使用rconfig完成转换

发表于 2015 年 5 月 4 日 由 Lunar

将单机数据库转换为RAC数据库，有好几种方法： 1，使用DBCA 2，手工添加thread（这个方法最经典，从9i到10g，到11.1，到11.2都可以，不过11.2以后，Oracle不推荐使用这个方法） 3，使用rconfig 4，ODA上有专门的工具进行转换，号称无敌脚本，O(∩_∩)O哈哈~（本次我没有测试，因为上面的方法已经足够多选择了） . rconfig功能还是比较强大的，除了单机转换为RAC，还可以单机转换为Standalone，Standalone转换为RAC，RAC转换为Standalone等等。 . 这里我们使用Oracle 11.2推荐的方法，体验一下rconfig的强大之处。 首先，我们要从一个单机数据库备份，然后恢复到到RAC环境中： 然后将这个数据库恢复到已经安装了GI的环境中，就是普通的将数据文件恢复到ASM的操作，没什么难度，主要命令如下： . 在ORACLE_HOME下有一个xml脚本，通常我们只需要修改这个脚本，就可以完成转换： 即： $ORACLE_HOME/assistants/rconfig/sampleXMLs/ConvertToRAC_AdminManaged.xml 1，我们先复制一个过来，进行修改： 其中，Convert verify=”ONLY”表示只测试转换过程，不实际转换。 Convert verify=”YES”，表示真实的执行转换。 测试过程这里略过了，我们看一年他是如何转换的。 我这里xml的内容如下： 具体的转换过程如下： 从这里我们清晰的看到，rconfig进行转换的时候，主要执行了如下步骤： 转换结果如下，lunar数据库已经是RAC数据库了，且已经在两个节点都启动了： 但是我个人并不喜欢rconfig的操作，原因是，他要进行backup as copy database的操作。 那么，就意味着，如果数据库巨大的话，需要的空间也会是双倍的 但是用传统的方法，手工添加第二个实例就不会有这个需求，比如我的数据库30T，怎么弄？

发表在 RAC | 标签为 , | 留下评论

11.2中修改私有网络的private ip对应的主机名

发表于 2015 年 4 月 13 日 由 Lunar

Oracle Clusterware使用oifcfg来管理网络信息（网卡，子网，网络接口的角色等等），但是他不管理每个网卡实际的IP地址。 因此，不能使用oifcfg来修改IP地址(只能修改子网)。 可以使用oifcfg getif来显示当前OCR里面的网卡信息，例如： 在UNIX和linux系统中，网络接口的名称通常由OS来分配。 Windows系统中有所不同（不熟悉Windows上的RAC，职业生涯中，安装不超过10次Windows平台的RAC……） 数据库对外提供服务的网络，我们通常称为PUBLIC网络，VIP也是存储在OCR里面跟PUBLIC同一网段上的IP地址 注意：VIP是绑定在public ip上的虚拟IP，只有CRS启动后，才有VIP。 用于RAC中节点间通信或者RDBMS跟ASM实例通信的网络，我们称之为Private网络（私有网络），用于内部互联。 从11.2开始，cluster_interconnect也被用来做clusterware hearbeats 在11.2之前（11.1和10g），RACA使用私有IP对应的主机名（例如 lunar-priv）来作为集群的心跳（在安装RAC时有界面让指定的） . 当修改了私有网络的IP或者主机名，就需要修改CRS（10g和11.1）或者GI(11.2以后)。 8i和9i没这个问题，因为那时候，Oracle没有自己的集群软件，只有“集群数据库”，所有的集群功能都是第三方集群软件完成的。 例如 : HP的MC SERVERS GUARD/OPS OPTION AIX的HACMP Solaris的SUN Cluster Tru64 UNIX的TruCluster ……………… . 在11.2之前，私有IP对应的主机名保存在OCR中，我们不能修改私有网络的主机名。 但是正因为如此，修改了私有IP，而私有IP对应的主机名其实并没有发生改变。 如果要修改主机名就简单的执行rootdelete.sh和rootdeinstall.sh重新配置CRS就可以了。 具体的例子请参考《在10.2 RAC中重建CRS的过程》 . 从11.2开始，CRS（Cluster Ready Service）升级为GI（Grid … 继续阅读 →

发表在 RAC | 标签为 , | 留下评论

11.2中修复CRS不能启动的例子-1-使用正常节点的gpnp profile修复损坏节点

发表于 2015 年 4 月 13 日 由 Lunar

SSD上的一个11.2 RAC的其中一个节点OS不能起来了，鼓捣半天还是不行 想想这个是2013年买的，才两年啊……，不知道是不是这个原因，反正很无语…… 另一个10多年前的活动硬盘上那个RedHat 2上的Oracle 8.0.6都还可以使用 . 就这个环境，从其他活动硬盘上复制了节点1的老的备份到SSD上，尝试修复整个RAC。 由于只修改了节点1的IP跟我现在VBOX中的配置一致即可，且节点2是正常的，因此，无需大招。 只要两件事情; 1,在OS层面修改节点1的网络配置: 2,把节点2的gpnp profile传给节点1 . 具体如下： 1，将2个节点的crsd都关闭，把节点2的profile.xml复制到节点1： 确认节点2的crs是关闭的： 2，确认当前的节点2的gpnp profile信息是正确的： 我这里主要是私有网络的IP地址应该为192.168.20.0网段： 即 可见这里是正确的。 注意这里，当所有CRS进程都不启动时，gpnp的信息来自于他自己的一个cache（猜测这个是从文件上保存的profile中读取到他自己的所谓cache的） . 3，查看节点1当前的gpnp profile，注意，其中的net2的信息，是错误的： 4，确认节点1的crs全部都是关闭的： 5，备份节点1当前的gpnp profile： 6，将节点2的gpnp profile复制到节点1： 7，启动节点1和节点2的crs（正常启动即可）： 8，可以看到，节点1已经可以正常启动了： 这里看到节点1的网络信息也正常了 再启动节点2： 除了network2（用于ADG的网络，还没有修改相应的配置），其他都正常了。

发表在 RAC | 标签为 , , , | 留下评论

10.2.0.1 RAC中重建CRS的过程（比如错误的修改IP导致CRS不能启动）

发表于 2015 年 4 月 13 日 由 Lunar

VIP是oracle 10.1引入的一个绑定在public IP上的静态IP，它的信息岁PUBLIC网卡的信息一起保存在OCR(Oracle Cluster Registry)中。 很多时候客户有一个需求，比如在测试环境是一套IP，迁移到生产后是另一套IP。 这时如果客户不想重装系统，那么就需要修改RAC的IP。 . 通常这样的操作本身都是小操作，不需要大动干戈，但前提是一定按照官方流程操作，比如修改IP时，CRS是开启的还是关闭的？ 再或者一类常见错误是，修改IP时，需要的填写的是子网信息而不是IP地址，这也是一类常见的因为修改IP造成CRS不能启动的。 类似这些小地方不注意，就会造成CRS不能启动。 不论是10.2、11.1，还是11.2，这些东西基本的核心内容其实是变化不大的，不同的是11.2更加完善和提供了更多可选的修复方法（报错非官方支持的）。 . 总结一下大概的东西： 1，PUBLIC网络对应的主机名不能修改，如果要修改，官方说法是一定要重装CRS。 这里我感觉是这样的：如果把主机上那几个用主机名名门的目录名称修改为新的主机名，然后执行重新配置CRS的操作，理论上可以行。 比如10g是rootdelete.sh rootdeinstall.sh root.sh 11.2以后是deconfig和reconfig 不过测试环境和自己玩的也就算了，生产环境，我还是感觉按照官方说法靠谱，否则日后出现各种怪癖问题，那就是给自己挖坑了…… . 2，对于PUBLIC网络，不修改主机名，只修改PUBLIC IP，这个不需要修改CRS的配置，因为不论是10g, 11.1 ，还是11.2，CRS中都没有就具体IP 3，对于修改PUBLIC的网络接口名（interface）、子网（subnet）和掩码信息（netmask）等信息，需要使用oifcfg进行修改。 这个以前有客户问过，需要多久？ 答：理论上10分钟以内。如果需要验证和回退措施等检验，那么申请30分钟到1小时的停业务时间吧。 . 4，如果修改私有网络，在10.2和11.1，因为这些信息保存在CRS中，因此需要相应的修改CRS信息（使用oifcfg） 从11.2开始，CRS（Cluster Ready Service）升级为GI（Grid Infrastructure）。私有IP对应的私有主机名不再存储在OCR中了。 而是通过GNPN架构来管理（即 网络即插即用，后面会讲。OCR和私有IP对应的主机名也不再有依赖关系。 因此，可以随便修改而不需要在CRS层面改动任何东西。 . 5，如果修改错了，没关系，10.2和11.1的杀手锏是 … 继续阅读 →

发表在 RAC | 标签为 , , , | 留下评论

修复由于修改主机名造成Standbalone异常（ORA-29701 raised in ASM I/O path）

发表于 2015 年 4 月 5 日 由 Lunar

前不久，我同事修改standbalone的主机名，只是单纯的从主机层面修改了，has等并没有做调整，虽然数据库奇迹般的open了（有些时候，数据库在此情况下是不能open的，直接就会报错），但是数据库更改主机名以后，ASM和数据库的alert都有报错，而且分析后，觉得这个报错不解决，会在后期使用中造成数据库crash。 修复这个问题的程很简单，有几点说明： 1，8i和8i以前叫做OPS，Oracle Parallel Server，9.0.1~11.1之间叫做RAC（Real Application Cluster），11.2以后叫做GI（Grid Infrastructure） 2，Standbalone结构就是单实例数据库使用ASM的场景，他只需要db和asm通信的cssd等结构，不需要crs。 3，启动，关闭和管理has流程类似rac，但是千万别混淆，Standbalone的叫做crsctl start/stop has，RAC的叫做crsctl start/stop crs(整套架构中所有进程由ohasd创建)，如果弄错了，会出现一些异常情况，在其他案例中，我们遇到过直接ASM报错的，后续在总结了那个案例分享出来。 4，不管是Standbalone还是RAC，修改主机名和IP等都需要特别小心，因为他们不像单机数据库一样，单纯的主机层面就该就可以，他们需要分别在has和crs中进行重配或者修改。 5，无论发生了什么，只要没有动ASM和DB，那么不用担心丢数据。因为has或者crs的结构都跟db是独立的，一般不会丢数据，最差的结果，重装一下，也可以把asm和db拉起来。 6，很多时候，在做类似该ip或者主机名，或者升级crs或者has的版本，或者升级数据库软件时，都建议对现有环境进行备份，要么借助NBU之类的工具，要么使用tar命令。千万别用ftp或者直接copy，这类的否不靠谱，不能用于文件恢复。 具体过程如下： ASM ALERT: 数据库的日志，DB ALERT: CRS和ohasd也有明显报错： 我猜测，此时如果做类似增加/删除文件数据库都会crash，果然，我让同事做rman备份，数据库就crash了。 处理的方法很简单，就是修改has的相关配置，讲新主机名配置进去。具体步骤如下： 首先记录当前的系统关键信息，因为修改完has后，需要将asm，db，diskgroup等关键信息重新注册到has中： 这里还发现了一个问题，这个库的ASM的在has中的信息和实际使用的spfile不一致 在所有的磁盘组中，我们发现实际上是找不到在has中注册的ASM实例使用的spfile的： 使用kfod检查会发现，大量磁盘的报错： 接下来，我就开始重建has了，首先是使用force都无法停止has，因为已经异常了，这个在意料之中的，没关系： 这些进程已经停不掉了，于是只能重启主机（kill ocssd.bin 一样会导致主机重启，因此直接手工reboot了）。 起来后，先删除现有的has配置： 然后执行重新配置： 这过程很快，比GI快多了，HAS还是结构简单啊，O(∩_∩)O哈哈~。 配置完成后，检查一下，服务都正常，只是需要将下面的服务改为自动启动： 使用NETCA重建监听: 添加asm： 在has中添加db： … 继续阅读 →

发表在 RAC | 标签为 | 留下评论

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异

发表于 2014 年 11 月 6 日 由 Lunar

Oracle从10.1开始推出了自己真正意义的集群软件（9i和9i之前的版本，Oracle只有集群数据库，集群的存储和网络是由第三方厂商维护的，比如IBM的HACMP，HPUX的MC SERVICE GUARD /OA，SUN的suncluster，True64的Trucluster，linux就用ocfs和check-timer等等）。 因此，从10.1开始，oracle的集群有了自己的管理网络和存储的机制，ocr存放集群配置信息，voting disk用于磁盘心跳。 本文就简单的汇总一下各版本对于ocr和voting disk在一些维护操作和安装需求大致做个总结。 更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC 1，各个版本ocr和vot的空间需求： 2，各个版本ocr和vot的磁盘组权限： 3，voting disk个数的要求： For Voting disks (never use even number of voting disks): External redundancy requires minimum of 1 voting disk (or 1 failure group) Normal … 继续阅读 →

发表在 RAC | 标签为 , , | 留下评论

更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC

发表于 2014 年 11 月 6 日 由 Lunar

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异 检查当前的ocr所在磁盘： 添加+DBFS_DG作为新的存放ocr的磁盘组： 删除+DATA_DG上的ocr： 查看voting disk当前存放在哪个磁盘组（N中方法，这里直接在ASM里面看的）： [oracle@dm01db01 ~]$ . ./env/grid.env [oracle@dm01db01 ~]$ asmcmd ASMCMD> ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED NORMAL N 512 4096 4194304 16625664 16624360 1511424 7556468 … 继续阅读 →

发表在 RAC | 标签为 , | 留下评论

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-2-使用root.sh重构crs

发表于 2014 年 10 月 8 日 由 Lunar

因此，下面我尝试比这个方法稍微科学一点点的方法2：重新执行节点1的root.sh，来尝试修复节点1的权限问题。 使用rootcrs.pl -deconfig删除crs配置信息： 使用root.sh重新配置crs： 配置结束后，可以看到，节点1的数据库是不能正常启动的： 这个原因是很明显的，跟手工修改u01目录权限一文中的类似： 修改oracle二进制文件的权限： 再次尝试启动数据库： 再回过头看看root.sh修改了哪些主要目录的权限： 这些目录是11.2 RAC的基本服务资源。从11.2开始，GI中不再显示类似上面的基础服务资源，需要使用init参数来看： 从修改过程可以看出，感觉上，root.sh比第一种手工修改的方法科学一点，但是居然oracle二进制文件的权限还是没有修改好，那么其他的是否有细节问题，不好说。 总之，Oracle建议的方法，还是加减节点，让Oracle完全的重构这个节点的所有文件，以防止日后任何的CRS异常终止或者异常宕机等行为。

发表在 RAC | 标签为 , , | 留下评论

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法–使用rootcrs.pl -init修复

发表于 2014 年 10 月 8 日 由 Lunar

还原节点损坏的场景： 可以看到，此时crs起不来了，后台报错： 可以看到，卡在ora.mdnsd服务不能启动： 使用rootcrs.pl的init选项尝试修复，结果是不行的： 后台日志的报错信息，跟上面的是雷同的。 可见，使用rootcrs.pl -init修复目录权限，在chown -R /u01面前，作用不大。

发表在 RAC | 标签为 , , | 留下评论

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法–手工修复权限之总结

发表于 2014 年 10 月 8 日 由 Lunar

正如在11.2 RAC 上所有grid环境需要的文件的权限配置文件：crsconfig_fileperms 和 11.2 RAC 上所有grid环境需要的目录的权限配置文件：crsconfig_dirs中描述的，理论上，根据这两个文件，自己写一个shell脚本修改全部grid环境所需的权限，看上去是可以的。 也正如11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-1-手工修复错误的权限中所证明的，其实真要是手工修改，只为了让crs可以起来，完全不必要那么麻烦，只要简单的几条命令即可，但是上面的3种手工修改权限的方法，都是oracle官方所不支持的，以前也有人log SR专门问过这类问题，官方给的推荐方法就是remove nodes and add nodes： 这种解释是很好理解的，11.2 RAC相对10.2来说可以说是重新设计的，相对复杂很多的庞然大物，其附带的功能也非常多，因此，手工修改后，到底会有什么风险，稳定性如何保证都是问题…… 因此，明天我用加减节点的方法来重现故障后，再减节点和加节点的方法修复试试看，O(∩_∩)O哈哈~

发表在 RAC | 标签为 , , | 留下评论