Re: Service de-registration after switchover question

DOUG, they are not needed until you are using GI, without it you have to use them for automation.

it any case, now we have situation when broker has stopped services at GI level, but they are up at instance level and registered with listener

so, it may be:

• manual service startup
• trigger
• some king of magic o like oracle BUG ... ;)

16.05.2018 19:31, DOUG KUSHNER �����:
>
> We have not implemented any fail-over triggers.� It was my understanding that they were required
> pre-11.2, before the role attribute had been added to service config, but in 11.2.0.4 and later
> are not needed.
>
>
>> On May 16, 2018 at 12:15 PM Oleksandr Denysenko <odenysenko_at_gmail.com> wrote:
>>
>> Niall,
>>
>> documentation says <https://docs.oracle.com/database/121/NETAG/advcfg.htm#sthref817> that it's
>> *ON *by default
>>
>> /Connect-time failover is turned //|on|//by default for multiple address lists
>> (ADDRESS_LIST), connect descriptors (DESCRIPTION), and multiple connect descriptors
>> (DESCRIPTION_LIST)./
>>
>> Best Regards,
>>
>> Oleksandr Denysenko
>> 16.05.2018 18:57, Niall Litchfield �����:
>>> If you are doing client-side failover your TNS entry would need to be (I think)
>>>
>>> ABCR_USR =
>>> � (DESCRIPTION =
>>> *(FAILOVER=ON)*
>>> ��� (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)
>>> ��� )
>>> � )
>>>
>>> You should check the Net Services Administration�Guide to make sure I've got that in the right
>>> place (I likely haven't). The principle being though that if you aren't using TAF/FAN then its
>>> up to the client to retry addresses until one succeeds.
>>>
>>> On Wed, May 16, 2018 at 9:55 AM, Doug Kushner <dougk5_at_cox.net <mailto:dougk5_at_cox.net>> wrote:
>>>
>>> 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>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Niall Litchfield
>>> Oracle DBA
>>> http://www.orawin.info
>>
>

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