We have been hitting some issues with Optim jobs abending while Oracle maintenance is being applied. All our Oracle DBs are set up on RACs (ie: clusters) so while one server is being updated, another one is available to accept the DB traffic. "RAC Awareness" is the ability of a tool to understand the error message from Oracle which says essentially "we're doing maintenance now, so please disconnect and reconnect and you'll get routed to another server." 

Currently, Optim just abends the job as soon as it gets an 'DB unavailable' error due to the maintenance. It'd be great if there was some setting/option to let Optim retry the connection before issuing an abend. I got nothing from the documentation on this after various searches. 

I'm guessing this is wishful thinking, but I figured it was worth posing to the group. Thanks for the input. 

-Keith



------------------------------
Keith Tidball
Progressive Insurance
------------------------------

#InfoSphereOptim
#Optim

Keith, 

In my experience, I would bypass the RAC Cluster VIP (url/host alias) and go straight to a physical node DB SID if possible. The only downside to doing this is factoring in how current the Oracle RAC Cluster is replicating the data back and forth between nodes. If this is for archiving purposes and the Oracle DB is relatively quite or not changing at all, then configuring your Optim ODBC and DB Alias to connect directly to a physical Oracle DB node is preferred. 

If your RAC cluster is actively updating physical DB nodes and actively being used by apps or users while you're connecting Optim to the database then you may be out of sync but only just a wee-bit depending on the frequency of updates between nodes. 

I once had an Oracle RAC cluster that just had a preference for the 1st node in the series. (4 physical db's behind the RAC). Node 1 was being hit like 90 percent of the time by all read/write/etc. So I just used that one "preferred node" but there is obviously risk in only using one node for data extraction.

------------------------------
Danny Lankford
3M - IT Manager
------------------------------

Thanks for the input, Danny. We have to connect at the RAC level and they do replication frequently between the nodes. Ideally, when Optim hits a connection issue, it would attempt a reconnect and would then get routed to the active node as opposed to just issuing a RC=16 and failing. Like I said, wishful thinking... 

-Keith

------------------------------
Keith Tidball
Progressive Insurance
------------------------------

Original Message:
Sent: Tue November 16, 2021 12:45 PM
From: Danny Lankford
Subject: Can Optim be RAC Aware?

Keith, 

In my experience, I would bypass the RAC Cluster VIP (url/host alias) and go straight to a physical node DB SID if possible. The only downside to doing this is factoring in how current the Oracle RAC Cluster is replicating the data back and forth between nodes. If this is for archiving purposes and the Oracle DB is relatively quite or not changing at all, then configuring your Optim ODBC and DB Alias to connect directly to a physical Oracle DB node is preferred. 

If your RAC cluster is actively updating physical DB nodes and actively being used by apps or users while you're connecting Optim to the database then you may be out of sync but only just a wee-bit depending on the frequency of updates between nodes. 

I once had an Oracle RAC cluster that just had a preference for the 1st node in the series. (4 physical db's behind the RAC). Node 1 was being hit like 90 percent of the time by all read/write/etc. So I just used that one "preferred node" but there is obviously risk in only using one node for data extraction.

------------------------------
Danny Lankford
3M - IT Manager
------------------------------