问题描述
嗨,汤姆,
正在通过第5.6.1.2节http://docs.oracle.com/database/121/DGBKR/sofo.htm#DGBKR3425
它说: “在数据库处于物理备用角色时,将处于活动状态的服务也必须在当前主数据库上创建和启动,无论该服务是否将在该数据库上启动。这是为了确保服务定义通过重做流,因此允许在物理备用数据库上启动服务。只有在应用了通过启动服务生成的重做后,才能在物理备用数据库上启动服务。重要的是,所有数据库上的所有SRVCTL add服务选项都必须相同,以便服务的行为角色改变前后的方式相同”。
两个问题:
1) 我们有一个FSFO配置,该配置具有1个主数据库和1个备用数据库。我们在两个数据库上添加主数据库服务 (示例) 和只读服务 (EXAMPLE_RO),如下所示:
=
主要
=
srvctl add service –db RAM_主要 –service EXAMPLE –role 主要
srvctl add service –db RAM_主要 –service EXAMPLE_RO –role PHYSICAL_待机
srvctl start service –db RAM_主要 –service EXAMPLE
=
待机
=
srvctl add service –db RAM_待机 –service EXAMPLE –role 主要
srvctl add service –db RAM_待机 –service EXAMPLE_RO –role PHYSICAL_待机
srvctl start service –db RAM_待机 –service EXAMPLE_RO
Assuming RAM_主要 is currently acting as primary in the configuration, we never had to start EXAMPLE_RO on RAM_主要 so that we will be able to start it on RAM_待机. Why does the documentation say otherwise?
2) 关于服务定义和重做流的全部问题是什么?有什么联系?
正在通过第5.6.1.2节http://docs.oracle.com/database/121/DGBKR/sofo.htm#DGBKR3425
它说: “在数据库处于物理备用角色时,将处于活动状态的服务也必须在当前主数据库上创建和启动,无论该服务是否将在该数据库上启动。这是为了确保服务定义通过重做流,因此允许在物理备用数据库上启动服务。只有在应用了通过启动服务生成的重做后,才能在物理备用数据库上启动服务。重要的是,所有数据库上的所有SRVCTL add服务选项都必须相同,以便服务的行为角色改变前后的方式相同”。
两个问题:
1) 我们有一个FSFO配置,该配置具有1个主数据库和1个备用数据库。我们在两个数据库上添加主数据库服务 (示例) 和只读服务 (EXAMPLE_RO),如下所示:
=
主要
=
srvctl add service –db RAM_主要 –service EXAMPLE –role 主要
srvctl add service –db RAM_主要 –service EXAMPLE_RO –role PHYSICAL_待机
srvctl start service –db RAM_主要 –service EXAMPLE
=
待机
=
srvctl add service –db RAM_待机 –service EXAMPLE –role 主要
srvctl add service –db RAM_待机 –service EXAMPLE_RO –role PHYSICAL_待机
srvctl start service –db RAM_待机 –service EXAMPLE_RO
Assuming RAM_主要 is currently acting as primary in the configuration, we never had to start EXAMPLE_RO on RAM_主要 so that we will be able to start it on RAM_待机. Why does the documentation say otherwise?
2) 关于服务定义和重做流的全部问题是什么?有什么联系?
专家解答
存储在群集层中的服务定义与数据库中的 * 之间存在相关性。
如果您查看该视图的DDL,您将看到它基于一个名为SERVICE $ 的内部表。因此,该表中的条目必须存在于主表中,才能存在于备用表中。
SQL> desc dba_services Name Null? Type ----------------------------------------------------------------------------------------------------------------- -------- ------------------- SERVICE_ID NUMBER NAME VARCHAR2(64) NAME_HASH NUMBER NETWORK_NAME VARCHAR2(512) CREATION_DATE DATE CREATION_DATE_HASH NUMBER FAILOVER_METHOD VARCHAR2(64) FAILOVER_TYPE VARCHAR2(64) FAILOVER_RETRIES NUMBER(10) FAILOVER_DELAY NUMBER(10) MIN_CARDINALITY NUMBER MAX_CARDINALITY NUMBER GOAL VARCHAR2(12) DTP VARCHAR2(1) ENABLED VARCHAR2(3) AQ_HA_NOTIFICATIONS VARCHAR2(3) CLB_GOAL VARCHAR2(5) EDITION VARCHAR2(128) COMMIT_OUTCOME VARCHAR2(3) RETENTION_TIMEOUT NUMBER REPLAY_INITIATION_TIMEOUT NUMBER SESSION_STATE_CONSISTENCY VARCHAR2(128) GLOBAL_SERVICE VARCHAR2(3) PDB VARCHAR2(128) SQL_TRANSLATION_PROFILE VARCHAR2(261) MAX_LAG_TIME VARCHAR2(128) GSM_FLAGS NUMBER PQ_SVC VARCHAR2(64) STOP_OPTION VARCHAR2(13) FAILOVER_RESTORE VARCHAR2(6) DRAIN_TIMEOUT NUMBER
如果您查看该视图的DDL,您将看到它基于一个名为SERVICE $ 的内部表。因此,该表中的条目必须存在于主表中,才能存在于备用表中。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




