When you perform a cluster operation (for example, moving from failover mode to normal companion mode), either companion may have attribute settings that prevent the cluster operation from succeeding. For example, the secondary companion may be configured with a stack size that is too small to accommodate both companions during fail over mode, or the companions may be configured for different languages.
To prevent these problems, sp_companion includes a do_advisory option that checks hundreds of attribute settings for each companion and issues warnings about any settings that may prevent a successful cluster operation. The attributes do not necessarily require the same values on both companions, but they must be compatible. sp_companion...do_advisory does not change any attributes; it only advises about potential problems.
sp_companion...do_advisory is not triggered automatically; run it periodically to verify that there are no compatibility issues between your companions.
do_advisory allows you to specify the attributes to investigate. You can either include all the attributes, or you can specify subsets of attributes.
You can select subsets of group, base, or quorum attributes. A group subset includes a broad set of server settings (for example, all the login attributes or all the space attributes); a base subset includes specific settings within the group subset (for example, user logins or CIS settings). do_advisory reports only the attributes of the specified subset that will prevent a successful cluster operation.
Quorum attributes are configuration parameters that sp_companion checks every time, whether or not you specify group or base attributes. If sp_companion finds that a quorum attribute is set such that it will prevent a successful cluster operation, the command fails. For more information, see “Quorum attributes”.
The following describes the server settings that make up each group:
Application group – checks to make sure the configuration settings for the applications running on the local companion are compatible with the remote companion. The application group includes the following:
Charsets – verifies that the character sets for which the secondary companion is configured include all the character sets for which the primary companion is configured.
Java archives – verifies that the Java archive on the primary companion has the same name and class definition on the secondary companion. If a class definition belongs to Java archive on the primary companion, it must belong to the same Java archive on the secondary companion.
The archives are not automatically synchronized; if
you configure one companion for Java, you must manually configure
the other.
Languages – verifies that the languages for which the secondary companion is configured include all the languages for which the primary companion is configured.
Remote servers – checks that remote server entries used by the application on the primary companion are the same on the secondary companion, if they exist. This ensures that server names and the associated server IDs used by the companions are unique and consistent within the cluster.
All default server entries (including SYB_BACKUP, local server name, companion server name, SYB_HACMP, local XP Server, and companion XP Server) are automatically synchronized.
Sort order – verifies that the sort orders for which the secondary companion is configured include all the sort orders for which the primary companion is configured.
Time ranges – verifies that time range definitions defined and used by the primary companion are the same as those used by the secondary companion, if they exist.
User types – verifies that all user-defined datatype definitions in the master database used by an application on the primary companion are defined the same way on the secondary companion, if they exist.
Config group – checks for compatibility between configuration parameters defined in the configuration file (located in $SYBASE/server_name.cfg). Configuring the Adaptive Server as companions does not automatically synchronize the configuration options. The config group includes the following base attributes:
CIS – verifies that CIS is correctly configured for the cluster operation.
DTM – verifies that the Distributed Transaction Manager parameters are compatible between the companions.
Disk i/o – makes sure the disk configuration (disk i/o structures, allow sql server async i/o, and so on) is compatible between the companions.
ESP – makes sure the extended stored procedures are compatible between the companions.
Errorlog – makes sure that the error log information (event logging, event log computer name, and so on) is compatible between the companions.
General config – verifies that all the general configuration parameters (those set in the configuration file) are correctly set for the cluster operation.
Java – makes sure that Java is either enabled or disabled for both companions.
Languages – makes sure that both companions have the same language, character set, and sort order.
Network – makes sure that the network related parameters (allow remote access, default network packet size, and so on) are compatible between the companions.
Parallel – verifies that the parallel configuration parameters (max parallel degree, memory per worker process, and so on) are compatible between the companions.
Q Diag – verifies that the Q Diagnostic attributes (autostart collector, sql text pipe active, and so on) are compatible between the companions.
Security – verifies that the security configuration (auditing, allow procedure grouping, and so on) for the companions is compatible.
Database group – checks that database attributes are compatible between the companions. The database group includes:
Unique dbid – verifies that database IDs on the primary companion are not used on the secondary companion.
If a user database ID conflicts with a system database
ID on the secondary companion, you must drop and re-create the system database
on the secondary companion.
Devices group – checks that device attributes are compatible between the companions. The devices group includes:
Devnames – verifies that logical device names on the primary companion are not used on the secondary companion.
Logins group – verifies that logins and permissions are consistent between the primary and secondary companions.
All user information (logins, permissions, and so on) defined on the primary companion must be defined, available, and compatible on the secondary companion, if it exists. Logins on the primary companion are checked to verify that they have unique names and suids on the secondary companions. The logins group also checks that remote logins, external logins, and aliases, and user names in master are compatible across the companions. do_advisory automatically corrects any issues that it finds.
Default login incompatibilities of probe, qcollector, qrepository, and so on are fixed automatically.
Roles group – verifies that all user-defined roles, login roles, and server-wide permissions are compatible between the primary and secondary companions.
Space group – verifies that the secondary companion has sufficient space available for the primary companion databases during failover.
Master Space – estimates the space required to synchronize the metadata during the initial configuration of the companion server or during sp_companion...resume.
Proxydb Space – estimates the space required for creating the proxy databases (when you configure the companion servers with with_proxydb in an asymmetric setup).
