SFHA Solutions 6.0.1 (Solaris): Troubleshooting the dgdisabled error flag
The dgdisabled error flag indicates that configuration changes on a disk group are disabled. This can occur due to any error that prevents further configuration changes on the disk group. For example, this can occur if no good disks are found during the disk group import operation, if no valid configuration copies are found on the disks in the disk group, or if writes to all configuration copies fail during an update to the disk group configuration. The dgdisabled error flag displays when the Veritas Volume Manager configuration daemon, vxconfigd loses access to all enabled configuration copies for the disk group. Configuration copies let you back up and restore all configuration data fordisk groups, and for objects such as volumes that are configured within the disk groups. Loss of access can occur if power is disrupted or a network cable is disconnected. To recover from loss of access, fix any disk connectivity issues, then deport and re-import the disk group. Beginning with the Storage Foundation and High Availability (SFHA) Solaris 6.0 release, a node can join the cluster even if there is a shared disk group that is in the DGDISABLED state. In earlier releases the node failed to join the cluster. For more information on troubleshooting the dgdisabled error flag, see: Removing the error state for simple or nopriv disks in non-boot disk groups vxdarestore(1m) 6.0.1 manual page: Solaris For more information on using the vxdisk list command to display status and troubleshoot disk errors, see the following Symantec Connect article: SFHA Solutions 6.0.1: Using the vxdisk list command to display status and to recover from errors onVeritas Volume Manager disks Veritas Storage Foundation and High Availability documentation for other releases and platforms can be found on theSORT website.
vxdisk list
dear, i am getting the output of vxdisk list as DEVICE TYPE DISK GROUP STATUS c0t1d0s2 auto:none - - online invalid kindly advice what to do to make the disk valid?.i had installed the veritas volume manager in solaris 10 which is installed on vmware thanks in advance regards ritchie james
SFHA Solutions 6.0.1: About GAB seeding and its role in VCS and other SFHA products
Group Membership and Atomic Broadcast (GAB) is a kernel component of Veritas Cluster Server (VCS) that provides globally-ordered messages that keep nodes synchronized. GAB maintains the cluster state information and the correct membership on the cluster. However, GAB needs another kernel component, Low Latency Transport (LLT), to send messages to the nodes and keep the cluster nodes connected. How GAB and LLT function together in a VCS cluster? VCS uses GAB and LLT to share data among nodes over private networks. LLT is the transport protocol responsible for fast kernel-to-kernel communications. GAB carries the state of the cluster and the cluster configuration to all the nodes on the cluster. These components provide the performance and reliability that VCS requires. In a cluster, nodes must share the groups, resources and the resource states. LLT and GAB help the nodes communicate. For information on LLT, GAB, and private networks, see: About LLT and GAB About network channels for heartbeating GAB seeding The GAB seeding function ensures that a new cluster starts with an accurate membership count of the number of nodes in the cluster. It prevents your cluster from a preexisting network partition upon initial start-up. A preexisting network partition refers to the failure in the communication channels that occurs while the nodes are down and VCS cannot respond. When the nodes start, GAB seeding reduces the vulnerability to network partitioning, regardless of the cause of the failure. GAB services are used by all Veritas Storage Foundation and High Availability (SFHA) products. For information about preexisting network partitions, and how seeding functions in VCS, see: About preexisting network partitions About VCS seeding Enabling automatic seeding of GAB If I/O fencing is configured in the enabled mode, you can edit the /etc/vxfenmode file to enable automatic seeding of GAB. If the cluster is stuck with a preexisting split-brain condition, I/O fencing allows automatic seeding of GAB. You can set the minimum number of nodes to form a cluster for GAB to seed by configuring the Control port seed and Quorum flag parameters in the /etc/gabtab file. Quorum is the number of nodes that need to join a cluster for GAB to complete seeding. For information on configuring the autoseed_gab_timeout parameter in the /etc/vxfenmode file, see: About I/O fencing configuration files For information on configuring the control port seed and the Quorum flag parameters in GAB, see: About GAB run-time or dynamic tunable parameters For information on split-brain conditions, see: About the Steward process: Split-brain in two-cluster global clusters How I/O fencing works in different event scenarios Example of a preexisting network partition (split-brain) Role of GAB seeding in cluster membership For information on how the nodes gain cluster membership, seeding a cluster, and manual seeding of a cluster, see: About cluster membership Initial joining of systems to cluster membership Seeding a new cluster Seeding a cluster using the GAB auto-seed parameter through I/O fencing Manual seeding of a cluster Troubleshooting issues that are related to GAB seeding and preexisting network partitions For information on the issues that you may encounter when GAB seeds a cluster and preexisting network partitions, see: Examining GAB seed membership Manual GAB membership seeding Waiting for cluster membership after VCS start-up Summary of best practices for cluster communications System panics to prevent potential data corruption Fencing startup reports preexisting split-brain Clearing preexisting split-brain condition Recovering from a preexisting network partition (split-brain) Example Scenario I – Recovering from a preexisting network partition Example Scenario II – Recovering from a preexisting network partition Example Scenario III – Recovering from a preexisting network partition gabconfig (1M) 6.0.1 manual pages: AIX Solaris For more information on seeding clusters to prevent preexisting network partitions, see: Veritas Cluster Server Administrator's Guide Veritas Cluster Server Installation Guide Veritas Cluster Server documentation for other releases and platforms can be found on the SORT website.
Oracle Data Base Replication with VVR under SFCFSHA/DR
Hi All; we are looking for whether VVR can use for the oracle database replication instead of oracle data guard solution. If it is used, do you know veritas gives support for any problem faced. even VVR keeps the write order fidelity, it is not certain the database integrity will ve preserved at the disaster site. do you have any best practices and white papers, experience, anything you suggest for this deploymeny?