Skip to content

Oracle - 60. page

RAC增加节点步骤

 

 

参考:http://space.itpub.net/35489/viewspace-563077

           Metalink  : [ID 1279891.1]

           http://www.itpub.net/thread-1361850-1-1.html

 详细文档稍后就会跟进。

 

 1、安装 节点的操作系统,与已经运行的节点一致。

2、配置系统参数和ORACLE的安装环境。

3、从运行节点的机器上把$ORACLE_HOME、$ORACLE-BASE、/etc/ora*复制到新安装机器上对应的目录,要同源地址一致。

4、运行新装机$ORACLE_HOME下的root.sh。

5、修改所有机器$ORACLE_HOME/oracm/admin下rac 配置、/etc/hosts配置。

6、确认当前数据库 的MAXINSTANCES大于等于您新加机器后的节点数,否则需重建控制文件(但一般都够,默认好像是16还是32来着);

7、配置spfile,可以用命令alter system set 参数名=值 scope=spfile;完成后重启就生效了。

也可以把spfile通过create pfile=… from spfile;生成pfile再修改,方便一点,如下所示要修改的内容。

<SID3>.instance_name=RAC3

<SID3>.instance_number=3

<SID3>.local_listener=LISTENER_RAC3

<SID3>.thread=3

<SID3>.undo_tablespace=UNDOTBS3

完成后要通过create spfile from pfile=…..建立回去后配置才生效哦。

8、在每个机器的$ORACLE_HOME/network/admin/tnsnames.ora中添加,并复制到各节点:

LISTENER_RAC3 = (ADDRESS = (PROTOCOL = TCP)(HOST = <node3>)(PORT = 1521))

9、在数据库中添加新的redo logfile:

alter database add logfile thread 3

group 5 (‘/dev/RAC/redo3_01_100.dbf’) size 100M,

group 6 (‘/dev/RAC/redo3_02_100.dbf’) size 100M;

alter database enable public thread 3;

10、在数据库添加新的undotbs:

CREATE UNDO TABLESPACE UNDOTBS3 DATAFILE ‘/dev/RAC/undotbs_03_210.dbf’ SIZE 200M AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED

11、确认新节点的环境变量(ORACLE_HOME、ORACLE_SID等),然后启动第三个实例。

12、可以通过srvctl的配置增加对新节点的管理 。具体查看srvctl帮助,例:srvctl -h   srvctl config -h

ORA-00350: log 2 of instance luda (thread 1) needs to be archived

 

 
 
 
ORA-00262: current log 1 of closed thread 1 cannot switch
ORA-00312: online log 1 thread 1:
'/oracle/oradata/LUDA/onlinelog/o1_mf_1_6zlkxrqf_.log'
ORA-00312: online log 1 thread 1:
'/oracle/flash_recovery_area/LUDA/onlinelog/o1_mf_1_6zlky0b9_.log'
ORA-00350: log 2 of instance luda (thread 1) needs to be archived
ORA-00312: online log 2 thread 1:
'/oracle/oradata/LUDA/onlinelog/o1_mf_2_6zlky76o_.log'
ORA-00312: online log 2 thread 1:
'/oracle/flash_recovery_area/LUDA/onlinelog/o1_mf_2_6zlkyghs_.log'
 
 
SQL> select GROUP#,ARCHIVED ,STATUS from v$log;
 
    GROUP# ARC STATUS
———- — —————-
         1 NO  CURRENT
         3 NO  INACTIVE
         2 NO  INACTIVE
 
 
配置DG时候强行关闭节点2,节点1 
再次启动节点一时候报错
 
[oracle@dg1 09:50:38|~]oerr ora 262
00262, 00000, "current log %s of closed thread %s cannot switch"
// *Cause:  The log cannot be cleared or manually archived because it is
//          the current log of a closed thread, and it is not possible to
//          switch logs so another log is current. All other logs for the
//          thread need to be archived, or cleared, and cannot be reused.
// *Action: Archive another log in the same thread first, or complete the
//          clearing. See attached errors for the reason the switch cannot
//          be completed.
[oracle@dg1 09:59:25|~]oerr ora 312
00312, 00000, "online log %s thread %s: '%s'"
// *Cause:  This message reports the filename for details of another message.
// *Action: Other messages will accompany this message. See the
//          associated messages for the appropriate action to take.
[oracle@dg1 09:59:30|~]oerr ora 350
00350, 00000, "log %s of instance %s (thread %s) needs to be archived"
// *Cause:  The command cannot be done because the log has not been archived,
//          and media recovery has been enabled.
// *Action: Archive the log or disable media recovery. If the command supports
//          an UNARCHIVED option then it can be used. However this may result
//          in making backups unuseable, and forcing the drop of some offline
//          files.
 
 
这里报2个日志组,快速解决办法:
 

alter database clear unarchived logfile group 2;
alter database clear unarchived logfile group 1;
alter database open;
 
当然这个报错的原因是首先关闭了dg2节点,当关闭节点1时候,rfs归档无法找到standby,从而传输失败,报错
 
clear =。= 不是很妥当的办法。

 

ORA-00600: 内部错误代码, 参数: [ktecgetsh-inc], [1], [], [], [], [], [], []

 

系统 :aix 53

版本: 10.2.0.3

 

Errors in file /oracle/app/oracle/admin/sxsi/udump/sxsi_ora_909628.trc:
ORA-00600: 内部错误代码, 参数: [ktecgetsh-inc], [1], [], [], [], [], [], []

处理过程:

 

3.1查看数据库等待事件:

确定当前session没有任何等待事件

SQL> select sid from v$mystat where rowed <=1;

SQL> select sid,event,p1,p1text from v$session

     

 

3.3定位出现问题的ACA的表:

SQL> select * from tab where tname like '%ACA6%';

 

TNAME                          TABTYPE  CLUSTERID

—————————— ——- ———-

ACA6                           TABLE

ACA60701                       TABLE

ACA6A                          TABLE

ACA6B                          TABLE

ACA6C                          TABLE

ACA6MERGE                      TABLE

ACA6MOVE                       TABLE

ACA6_BACKUP                    TABLE

ACA6_CW                        TABLE

ACA6_DEF                       TABLE

ACA6_TEMP                      TABLE

 

TNAME                          TABTYPE  CLUSTERID

—————————— ——- ———-

ACA6_TZ                        TABLE

F_ACA6                         TABLE

F_ACA6_1201                    TABLE

F_ACA6_BAK_20100629            TABLE

MLOG$_ACA6                     TABLE

ZZZ_ACA6_12                    TABLE

ZZZ_ACA6_DB                    TABLE

ZZZ_ACA6_YL                    TABLE

  找出ACA6

 

3.4  通过视图dba_indexes查看ACA6表上的索引

SQL> select INDEX_NAME,INDEX_TYPE from dba_indexes where table_name = 'ACA6';

 

INDEX_NAME                     INDEX_TYPE

—————————— —————————

IDX_ACA6_AAC001_AAE140         NORMAL

PK_ACA6                        NORMAL

IDX_ACA6_AAC001                NORMAL

IDX_ACA6_AAE063                NORMAL

IDX_ACA6_AAE074                NORMAL

IDX_ACA6_AAB001                NORMAL

IDX_ACA6_EAE038                NORMAL

IDX_ACA6_AAE002                NORMAL

IDX_ACA6_PRSENO                NORMAL

PK_ACA6                        NORMAL

IDX_ACA6_PRSENO                NORMAL

 

INDEX_NAME                     INDEX_TYPE

—————————— —————————

PK_ACA6                        NORMAL

IDX_ACA6_AAC001                NORMAL

IDX_ACA6_AAE002                NORMAL

IDX_ACA6_AAE063                NORMAL

IDX_ACA6_AAE074                NORMAL

IDX_ACA6_EAE038                NORMAL

IDX_ACA6_PRSENO                NORMAL

 

已选择18行。

  由上面的查询可以看出此表有18个索引,如果全部重建,那么需要的时间需要比较长,这里我们根据错误以及内部原理推出错误只局限在出现错误的对应的分区表上的索引,所以只要找出对应的分区表上的索引即可。

3.5  根据客户提供的aca6表的aca6_6分区进行拆分,那么报错也是这个分区表:

执行

SQL>Select * from aca6 partition(aca6_1) where ….;

 

SQL>select * from aca6 partition(aca6_6) where aae002='125485532354'; 

ORA-10632:invalid rowid

   得出的是 分区表aca6 1-5partition都是正常的,只有执行拆分操作的6号分区出现问题,根据查询到的ace002索引为此分区aae002字段上的索引,吕与我采用CATS尝试创建该表备份,并重建ACE002索引。

1.6    通过下面语句执行cats以及重建

 

Create table aca6_6bak as select * from aca6 partition(aca6_6);

报错:ora 10632.

终止业务服务器,尝试重建索引:

select dbms_metadata.get_ddl('index','IDX_ACA6_AAE002') from dual;

然后将结果粘贴执行,

报错:ora 10632

  

发现事故非常严重,已经无法访问表,无法用cats和重建索引方式解决这个问题,逐建议采用备份恢复,但是最后发现备份恢复不出

 3.7 执行hint全扫分析

 

select /*+ parallel(aca6,2) */ count(*) from aca6 partition(aca6_6);

 3725620 rows

ora  10632invaild rowid

这里标明,表数据还能扫描,还没全坏继续执行

SQL> select * from aca6 partition(aca6_6) where rownum <= 10000

观察等待事件

SQL> select sidevent,p1,p2 from v$session where sid in (select sid from v$mystat where

Rownum <=1);

SID EVENT

———- —————————————————————-

        P1         P2

———- ———-

       137 SQL*Net message to client

1650815232          1

…….

在这里结果标明扫描并没有从磁盘里读取数据块,任何的select的操作都不可能没有等待事件,向磁盘读取数据过程都需要一定的时间,并且会有相关的IO事件在event中显示,

这里分析:数据库并没有向硬盘读取数据,表的数据在硬盘中,数据是正常的,可能是由于这个bug引起内存错误造成oracle无法正确去读取硬盘数据块。

解决办法:

将共享池刷新一遍,尝试cats以及index rebuild

操作:

SQL >Alter system flush shared_pool;

SQL >Alter system flush buffer_cache;

 

然后执行CATS以及INDEX REBUILT成功。备有aca6_6bak一份,大约5G数据

 

学做人

为人要谦和,

要学会包容,

说话不要尖锐,

心平气和,才能胸有成竹。

技术 和 性格差无关,谦和。