oracle dataguard 进行switchover测试

       很久前测试搭建了dataguard 环境,到今天才抽空做了一次switchover的测试操作,现记录下测试的经过。

        首先,主库处于open状态,而备库则处于mounted 状态,另外,主库中先通过“SQL> alter system archive log current;”来强制切换主库的redo日志并归档。
再检查主备库归档日志:
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     0
Next log sequence to archive   0
Current log sequence           129

       主备库的archive的current log sequence 都应为129,证明主库产生的归档能正常传送到备库。
       在正常情况下,备库要通过“alter database recover managed standby database disconnect from session;”来使数据库处于应用日志的状态。
        现在开始switchover 操作。
        主库:
        检查数据库中除了当前会话外,还有没有其他非系统的活动会话,
        SQL> select count(*) from v$session where username is not null
               2  ;

         COUNT(*)
         ----------
               1
        检查主库状态,
        SQL> select open_mode,database_role,switchover_status from          
                    v$database;

        OPEN_MODE    DATABASE_ROLE    SWITCHOVER_STATUS
       ----------                 ----------------                --------------------
          READ WRITE   PRIMARY                   SESSIONS ACTIVE

        本来switchover_status 状态应该为 TO STANDBY,这里既然只有一个活动会话sys,则也是可以切换的。
        执行主库switchover切换操作,关闭数据库,启动到mount状态:
        SQL> alter database commit to switchover to physical standby;

                Database altered.

        SQL> shutdown immediate;
        ORA-01507: database not mounted

        ORACLE instance shut down.
        SQL> startup nomount;
        ORACLE instance started.

        Total System Global Area 1224736768 bytes
        Fixed Size                  2083560 bytes
        Variable Size             352322840 bytes
        Database Buffers          855638016 bytes
        Redo Buffers               14692352 bytes
        SQL> alter database mount standby database;

        Database altered.

        检查状态,数据库已经处于STANDBY 角色,
        SQL> select open_mode,database_role,switchover_status from               
                    v$database;

         OPEN_MODE  DATABASE_ROLE       SWITCHOVER_STATUS
         ----------              ----------------                   --------------------
         MOUNTED        PHYSICAL STANDBY RECOVERY NEEDED

        注:此处的“RECOVERY NEEDED”原本应为"TO PRIMARY" ,但只是因为当前备库(原主库)并没有处于应用日志状态,按前述重新执行“alter database recover managed standby database disconnect from session;”。

        SQL> select open_mode,database_role,switchover_status from            
                    v$database;

        OPEN_MODE  DATABASE_ROLE      SWITCHOVER_STATUS
        ----------              ----------------                  --------------------
        MOUNTED       PHYSICAL STANDBY SESSIONS ACTIVE

        session active状态并不影响当前备库下次切换为主库。
       
        登陆原备库操作:
        检查活动会话,
        SQL> select count(*) from v$session where username is not null;
         
         COUNT(*)
         ----------
               1
        SQL> select open_mode,database_role,switchover_status from
                    v$database;

        OPEN_MODE  DATABASE_ROLE      SWITCHOVER_STATUS
         ----------             ----------------                  --------------------
         MOUNTED      PHYSICAL STANDBY TO PRIMARY

         SQL> alter database commit to switchover to primary;

         Database altered.

         SQL> shutdown immediate                              
         ORA-01109: database not open

         Database dismounted.
         ORACLE instance shut down.
         SQL> startup
         ORACLE instance started.
         。。。
         Database mounted.
         Database opened.
         原备库经已切换成主库角色,同样SESSIONS ACTIVE并不影响它下次切换回备库角色。
         SQL> select open_mode,database_role,switchover_status from
                    v$database;

         OPEN_MODE  DATABASE_ROLE    SWITCHOVER_STATUS
         ----------              ----------------                --------------------
         READ WRITE   PRIMARY                    SESSIONS ACTIVE

         在切换的过程中,我们可以做一个小测试来验证原备库切换为主库后数据文件有否跟原主库同步:
         先在主库建立一张表,插入数据:
         SQL> create  table tanlong (c1 number,c2 date);

         SQL> insert into tanlong values(1,sysdate);

         SQL> select * from tanlong;
         C1         C2
         ---------- ---------
         1            10-APR-11

         SQL> commit;             //记得commit 一下,写到redo里。

         Commit complete.

         再切换日志,写归档,此时归档应该传送到备库。
         在完成switchover操作后,检查主库(原备库):
         SQL> select * from tanlong ;

          C1         C2
          ---------- ---------
          1           10-APR-11
         证明当它作为备库时,已经接收并应用了原主库传送过来的归档,两边数据库的数据是一致的。
         至此,完成测试。
              
          最后,学习好的方法。
          1,在主备切换测试的时候,开两个crt窗口,使用“tail -f alert.log” 来同步观察数据库操作的信息。
          2,当任何一个库切换成备库角色,或者一直担当备库角色时,应始终处于应用日志状态。(alter database recover managed standby database disconnect from session;)

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

转载于:http://blog.itpub.net/24582392/viewspace-692179/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
智慧校园建设方案旨在通过融合先进技术,如物联网、大数据、人工智能等,实现校园的智能化管理与服务。政策的推动和技术的成熟为智慧校园的发展提供了基础。该方案强调了数据的重要性,提出通过数据的整合、开放和共享,构建产学研资用联动的服务体系,以促进校园的精细化治理。 智慧校园的核心建设任务包括数据标准体系和应用标准体系的建设,以及信息化安全与等级保护的实施。方案提出了一站式服务大厅和移动校园的概念,通过整合校内外资源,实现资源共享平台和产教融合就业平台的建设。此外,校园大脑的构建是实现智慧校园的关键,它涉及到数据中心化、数据资产化和数据业务化,以数据驱动业务自动化和智能化。 技术应用方面,方案提出了物联网平台、5G网络、人工智能平台等新技术的融合应用,以打造多场景融合的智慧校园大脑。这包括智慧教室、智慧实验室、智慧图书馆、智慧党建等多领域的智能化应用,旨在提升教学、科研、管理和服务的效率和质量。 在实施层面,智慧校园建设需要统筹规划和分步实施,确保项目的可行性和有效性。方案提出了主题梳理、场景梳理和数据梳理的方法,以及现有技术支持和项目分级的考虑,以指导智慧校园的建设。 最后,智慧校园建设的成功依赖于开放、协同和融合的组织建设。通过战略咨询、分步实施、生态建设和短板补充,可以构建符合学校特色的生态链,实现智慧校园的长远发展。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值