Re: Service de-registration after switchover question

funny ;)

check for presence of *AFTER STARTUP* and *AFTER DB_ROLE_CHANGE* triggers

and if you have - post source code.

Best Regards,

     Oleksandr Denysenko

16.05.2018 18:19, Doug Kushner ïèøåò:
> All indications are that the service resources are not running:
> srvctl status service -d ABCR1 Service ABCR_PERL is not running. Service ABCR_TSAM is not running.
> Service ABCR_USR is not running. Service ABCR_WEB is not running. SQL> select name, database_role
> from v$database; NAME DATABASE_ROLE --------- ---------------- ABCR1 PHYSICAL STANDBY crsctl stat
> res -t -------------------------------------------------------------------------------- Name
> Target State Server State details
> --------------------------------------------------------------------------------
> -------------------------------------------------------------------------------- Cluster Resources
> --------------------------------------------------------------------------------
> ora.abcr1.abcr_perl.svc 1 OFFLINE OFFLINE STABLE ora.abcr1.abcr_tsam.svc 1 OFFLINE OFFLINE STABLE
> ora.abcr1.abcr_usr.svc 1 OFFLINE OFFLINE STABLE ora.abcr1.abcr_web.svc 1 OFFLINE OFFLINE STABLE
> ora.abcr1.db 1 ONLINE INTERMEDIATE server011 Mounted (Closed),HOM E=/u01/app/oracle/pr
> oduct/11.2.0.4/dbhom e_1,STABLE 2 ONLINE INTERMEDIATE server012 Mounted (Closed),HOM
> E=/u01/app/oracle/pr oduct/11.2.0.4/dbhom e_1,STABLE
>
> On 5/16/2018 2:15 AM, Oleksandr Denysenko wrote:
>>
>> so, actually, you have service *ABCR_USR*  started in some way on *ABCR1*
>>
>> what is result of
>>
>> srvctl status service -d *ABCR1*
>>
>> ABCR1 - is standby now ?
>>
>> SELECT database_role FROM v$database;
>>
>> Best Regards,
>>
>> Oleksandr Denysenko
>> 16.05.2018 11:55, Doug Kushner ïèøåò:
>>> Additional info as requested, all from the first node of the new standby RAC server.
>>>
>>> NAME TYPE        VALUE
>>> ------------------------------------ ----------- -------------------------------------------
>>> db_unique_name                       string ABCR1
>>> service_names                        string ABCR_PERL,ABCR_TSAM,ABCR_USR,ABCR_WEB,ABCR1
>>>
>>> The HOST names in the following ADDRESS_LIST are DNS cnames that alias the scan names on each of
>>> the platforms.
>>>
>>> ABCR_USR =
>>>   (DESCRIPTION =
>>>     (ADDRESS_LIST =
>>>       (ADDRESS = (PROTOCOL = TCP)(HOST = abcr-prim-scan)(PORT = 1521))  <<< This is new standby
>>>       (ADDRESS = (PROTOCOL = TCP)(HOST = abcr-stby-scan)(PORT = 1521))  <<< This is new primary
>>>     )
>>>     (CONNECT_DATA =
>>>       (SERVER = DEDICATED)
>>>       (SERVICE_NAME = ABCR_USR)
>>>     )
>>>   )
>>>
>>> Listener entries for the other ABCR_* services are identical to the ABCR_USR entry and have been
>>> omitted.
>>>
>>> LSNRCTL> services
>>> Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
>>> Services Summary...
>>> Service "ABCR1" has 1 instance(s).
>>>   Instance "ABCR11", status READY, has 1 handler(s) for this service...
>>>     Handler(s):
>>>       "DEDICATED" established:1504 refused:0 state:ready
>>>          LOCAL SERVER
>>> Service "ABCR1_DGB" has 1 instance(s).
>>>   Instance "ABCR11", status READY, has 1 handler(s) for this service...
>>>     Handler(s):
>>>       "DEDICATED" established:1504 refused:0 state:ready
>>>          LOCAL SERVER
>>> Service "ABCR1_DGMGRL" has 1 instance(s).
>>>   Instance "ABCR11", status UNKNOWN, has 1 handler(s) for this service...
>>>     Handler(s):
>>>       "DEDICATED" established:32 refused:1
>>>          LOCAL SERVER
>>> Service "ABCR_USR" has 1 instance(s).
>>>   Instance "ABCR11", status READY, has 1 handler(s) for this service...
>>>     Handler(s):
>>>       "DEDICATED" established:1504 refused:0 state:ready
>>>          LOCAL SERVER
>>> The command completed successfully
>>>
>>> On 5/16/2018 12:19 AM, Oleksandr Denysenko wrote:
>>>>
>>>> Hello.
>>>>
>>>> please, show from new standby:
>>>>
>>>> * show parameter db_unique_name
>>>> * show parameter service_name
>>>> * lsnrctl services
>>>> * full desctiption of used TNS connection string
>>>>
>>>> Best Regards,
>>>>
>>>> Oleksandr Denysenko
>>>> 16.05.2018 8:19, Doug Kushner ïèøåò:
>>>>> Hi all,
>>>>>
>>>>> Please be kind as this is my first posting to this list.
>>>>>
>>>>> We have two RAC platforms with 12.2.0.1 GI and 11.2.0.4 RDBMS replicating with Data Guard. 
>>>>> Switchover testing was successful using the broker with the roles switching successfully. 
>>>>> Services have been configured with the primary role on both platforms and as expected, after
>>>>> switchover the services are stopped on the new standby and started on the new primary.  The
>>>>> applications are not TAF/FAN aware, so these tests assume for the time being that we are
>>>>> shutting down the apps (external connections) and restarting them after the switchover.
>>>>>
>>>>> Now for the question...  We expected as part of this switchover, that the services which were
>>>>> stopped would automatically be de-registered from the listener on the new standby side. 
>>>>> However, they are still registered, and we are wondering if it is our expectations or our
>>>>> configuration that is at fault.
>>>>>
>>>>> With the services still registered on the standby side, sqlplus connection attempts to the
>>>>> service result in an ORA-01033 error, since the standby address is the first of the two
>>>>> addresses in the TNS alias.
>>>>>
>>>>> Have not been able to find any info regarding deregistration of services in the listener after
>>>>> a switchover, so thought I would ask the experts.
>>>>>
>>>>> Thanks,
>>>>> Doug
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.freelists.org/webpage/oracle-l
>>>>>
>>>>>
>>>>
>>>
>>
>

--
http://www.freelists.org/webpage/oracle-l