Re: Service de-registration after switchover question

From: Oleksandr Denysenko <odenysenko_at_gmail.com>
Date: Wed, 16 May 2018 12:15:13 +0300
Message-ID: <90fe2e59-2b60-dca9-50dc-94f6279dc34d_at_gmail.com>



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
Received on Wed May 16 2018 - 11:15:13 CEST

Original text of this message