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 failover mode, or the companions may be configured for different languages.
To prevent these problems, the sp_companion command includes a do_advisory option which checks hundreds of attribute settings for each of the companions and issues warnings about any settings that will prevent a successful cluster operation. The attributes do not necessarily have to have the same values on both companions; for many attributes, the values must only be compatible between the two companions. sp_companion do_advisory does not change any of the attributes, it only advises you about any potential problems.
sp_companion...do_advisory is not triggered automatically (for example, during a sp_companion...resume). You should run sp_companion...do_advisory periodically to make sure there are no compatibility issues between your companions that will prevent a successful failover.
do_advisory allows you to specify the granularity of the attributes you want to investigate. You can either look at all the attributes, or you can specify subsets of attributes. When you specify that you want to look at all the attributes, sp_companion issues a list of all the attributes that will prevent a successful cluster operation.
The subset consists of group, base, or quorum attributes. A group attribute comprises a broad set of server settings (for example, all the login attributes or all the space attributes); a base attribute comprises specific settings within the group attributes (for example, user logins or CIS settings). When you specify that you want to investigate a subset of attributes, do_advisory only reports the attributes of this subset that will prevent a successful cluster operation.
Quorum attributes are configuration parameters that sp_companion checks every time it is run, regardless of 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”.
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 includes all the character sets for which the primary companion is configured.
Java Archives – Checks to make sure 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.
These are not automatically synchronized; if you configure
one companion for Java, you must manually configure the other as
well.
Languages – Verifies that the languages for which the secondary companion is configured includes 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, 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 includes 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 must be the same used by the secondary companion, if they exist.
User types – Checks to make sure that all user-defined data type definitions in master used by an application on the primary companion are defined the same 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 (for example sybsystemprocs),
you must drop and recreate 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 login and permissions are consistent between the primary and secondary companions.
Logins – 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 that they have unique names and suids on the secondary companions, if they exist. The logins group also checks that remote logins, external logins, aliases, (in master), and user names (in master) are compatible across the companions. do_advisory automatically corrects any issues that it finds with a value of 1 (for example, a login that exists on the primary companion that does not conflict with any logins on the secondary companion, but does not exists in secondary).
Default login incompatibilities of probe, qcollector, qrepositiry, and so on are fixed automatically.
Roles group – Verifies that roles are consistent between the primary and secondary companions.
Roles – Verifies that all user-defined roles, login roles and server wide permissions are compatible.
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).
