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