Re: Service de-registration after switchover question

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 

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
class="quotelev2">>>          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