SIOS TECHNOLOGY CORP.

SAP Recovery Kit – Known Issues / Restrictions

Description
A split brain may occur for ERS v2 resources while processing a restored comm path

If an SAP cluster is configured with quorum and both the ASCS and ERS v2 resources reside on the same node when the communication path is restored to an eligible node for the ERS v2 resource, then a split brain may occur while attempting to switch the ERS v2 resource to the eligible node. Please contact Support for a patch for this issue.
SAP resources fail to come in-service due to csh bug in RHEL 8

Due to a bug in the tcsh package available for RHEL 8, the SAP administrative user’s .cshrc and .login files are not sourced correctly in certain situations. Due to this, important environment variables that the SAP Recovery Kit depends on are not properly exported, which may cause SAP resources to fail to come in-service on RHEL 8. See RedHat Bug 1714267 for more details and a workaround.
SAP Dual Stack Environment Restriction

The redesigned ERS resource type introduced in LifeKeeper for Linux 9.4.0 (which operates in a hierarchy separate from the corresponding central services instance) does not support an SAP dual stack (ABAP+Java) environment where there are two pairs of central services and enqueue replication server instances (e.g., ASCS00/ERS10 and SCS01/ERS11) installed under the same SID. Customers with an SAP dual stack (ABAP+Java) environment installed under the same SID should continue to use the pre-9.4.0 ERS resource design (which is located at the top of the SAP hierarchy with a dependency on the corresponding ASCS/SCS resource).
Failed delete or unextend of a SAP hierarchy

Deleting or unextending a SAP hierarchy that contains the same IP resource in multiple locations within the hierarchy can sometimes cause a core dump that results in resources not being deleted.

To correct the problem, after the failed unextend or delete operation, manually remove any remaining resources using the LifeKeeper GUI. You may also want to remove the core file from the server.
Handle Warnings gives a syntax error at -e line 1

When changing the default behavior of No in Handle Warnings to Yes, an error is received.

Solution: Leave this option at the default setting of No. Note: It is highly recommended that this setting be left on the default selection of No as Yellow is a transient state that most often does not indicate a failure.
Choosing same setting causes missing button on Update Wizard

If user attempts to update the Handle Warning without changing the current setting, the next screen, which indicates that they must go back, is missing the Done button.
When changes are made to res_state, monitoring is disabled

If Protection Level is set to BASIC and SAP is taken down manually (i.e. for maintenance), it will be marked as FAILED and monitoring will stop.

Solution: In order for monitoring to resume, LifeKeeper will need to start up the resource instead of starting it up manually.
ERS in-service fails on remote host if ERS is not parent of Core/CI

Note: This only applies to the pre-9.4.0 ERS resource design (which is located at the top of the SAP hierarchy with a dependency on the corresponding ASCS/SCS resource). For more details see ERS Resource Types in LifeKeeper.

Creating an ERS resource without any additional SAP resource dependents will cause initial in-service to fail on switchover.

Solution: Create ERS as parent of CI/Core instance (SCS or ASCS), then retry in-service.
SAP instance processes in an inconsistent state

Issuing concurrent administrative commands while a migration of an SAP resource is in-progress may leave the SAP instance processes in an inconsistent state, which may require manual intervention to resolve.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment