This section describes known high availability database (HADB) issues and associated solutions.
Bug ID |
Summary |
|||
---|---|---|---|---|
no ID |
HADB Configuration with Double Networks. HADB configured with double networks on two subnets works properly on Solaris SPARC. However, due to problems in the operating system or network drivers on some hardware platforms, it has been observed that Solaris x86 and Linux platforms do not always handle double networks properly. This causes the following problems with HADB:
|
|||
no ID |
HADB Database Creation Fails. Creating a new database may fail with the following error, stating that too few shared memory segments are available: HADB-E-21054: System resource is unavailable: HADB-S-05512: Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message: Too many open files. Solution Verify that shared memory is configured and the configuration is working. In particular, on Solaris 8, inspect the file /etc/system, and check that the value of the variable shmsys:shminfo_shmseg is at least six times the number of nodes per host. |
|||
5091280 |
hadbm set does not check resource availability (disk and memory space). When increasing device or buffer sizes using hadbm set, the management system checks resource availability when creating databases or adding nodes, but does not check if there are sufficient resources available when device or main-memory buffer sizes are changed. Solution Verify that there is enough free disk/memory space on all hosts before increasing any of the devicesize or buffersize configuration attributes. |
|||
5091349 |
Heterogeneous paths for packagepath not supported. It is not possible to register the same software package with the same name with different locations at different hosts; for example:
Solution HADB does not support heterogeneous paths across nodes in a database cluster. Make sure that the HADB server installation directory (--packagepath) is the same across all participating hosts. |
|||
6173886, 6253132 |
createdomain may fail. If running the management agent on a host with multiple netwrok interfaces, the createdomain command may fail if not all network interfaces are on the same subnet:
The management agents will (if not configured otherwise) use the "first" interface for UDP multicasts ("first" as defined by the result from java.net.NetworkInterface.getNetworkInterfaces()). Solution The best solution is to tell the management agent which subnet to use (set ma.server.mainternal.interfaces in the configuration file, e.g., ma.server.mainternal.interfaces=10.11.100.0). Alternatively one may configure the router between the subnets to route multicast packets (the management agent uses multicast address 228.8.8.8). Before retrying with a new configuration of the management agents, you may have to clean up the management agent repository. Stop all agents in the domain, and delete all files and directories in the repository directory (identified by repository.dr.path in the management agent configuration file). This must be done on all hosts before restarting the agents with a new configuration file. |
|||
6230792, 6230415 |
Starting, stopping, and reconfiguring HADB may fail or hang. On Solaris 10 Opteron, starting, stopping or reconfiguring HADB using the hadbm command may fail or hang with one of the following errors:
This may happen if there are inconsistencies reading/writing to a file (nomandevice) which the clu_noman_srv process uses. This problem can be detected by looking for the following messages in the HADB history files:
Solution The following workaround is unverified, as the problem has not been reproduced manually. However, running this command for the affected node should solve the problem.
Note that all devices for the node will be reinitialized. You may have to stop the node before reinitializing it. |
|||
6232140 |
The management agent terminates with the exception "IPV6_MULTICAST_IF failed" When starting on a host running Solaris 8 with several NIC cards installed, if there is a mixture of cards with IPv6 and IPv4 enabled, the management agent may terminate with the exception "IPV6_MULTICAST_IF failed." Solution Set the environment variable JAVA_OPTIONS to -Djava.net.preferIPv4Stack=true; for example:
Alternatively, use Solaris 9 or later, which do not exhibit this problem. |
|||
6249685 |
clu_trans_srv cannot be interrupted. There is a bug in the 64-bit version of Red Hat Enterprise Linux 3.0 that makes the clu_trans_srv process end up in an uninterruptible mode when performing asynchronous I/O. This means that kill -9 does not work and the operating system must be rebooted. Solution Use a 32-bit version of Red Hat Enterprise Linux 3.0. |
|||
6262824 |
hadbm does not support passwords containing capital letters. Capital letters in passwords are converted to lowercase when the password is stored in hadb. Solution Do not use passwords containing capital letters. |
|||
6265419 |
Downgrading from HADB Version 4.4.2.5 to HADB Version 4.4.1.7 causes ma to fail with different error codes. When downgrading to a previous HADB version, the management agent may fail with different error codes. Solution It is possible to downgrade the HADB database, however the management agent cannot be downgraded if there changes have been made in the repository objects. After a downgrade, you must keep use the management agent from the latest HADB version. |
|||
6271063 |
Install/removal and symlink preservation. Regarding install/removal of HADB c package (Solaris: SUNWhadbc, Linux: sun-hadb-c) version <m.n.u-p>, the symlink /opt/SUNWhadb/<m> is never touched once it exists. Thus, it is possible that an orphaned symlink will exist. Solution Delete the symlink before install or after uninstall unless in use. |
|||
6273681 |
Management agents in global and local zones may interfere. On Solaris 10, stopping a management agent by using the ma-initd script in a global zone stops the management agent in the local zone as well. Solution Do not install the management agent both in the global and local zone. |
|||
6275103 |
hadbm/ma should give a better error message when a session object has timed out and deleted at MA. Sometimes, a resource contention problem on the server may cause a management client to become disconnected, When reconnecting, a misleading error message "hadbm:Error 22184: A password is required to connect to the management agent" may be returned. Solution Check if there is a resource problem on the server, take proper action (e.g., add more resources), and retry the operation. |
|||
6275319 |
Non-root users cannot manage HADB. Installing with Java Enterprise System (as root) does not permit non-root users to manage HADB. Solution Always login as root to manage HADB. |
|||
6293912 |
The Management Agent should not use special-use interfaces. Special use interfaces with IP addresses like 0.0.0.0 should not be registered as valid interfaces to be used for HADB nodes in the Management Agent. Registering such interfaces may cause problems if HADB nodes are set up on these interfaces by means of a user issuing a hadbm create command using host names instead of IP addresses. The nodes will then be unable to communicate, causing the create command to hang. Solution When using hadbm create on hosts with multiple interfaces, always specify the IP addresses explicitly using DDN notation. |
|||
6291562 |
Reassembly failures on Windows. On the Windows platform, with certain configurations and loads, there may be a large number of reassembly failures in the operating system. The problem has been seen with configurations of more than twenty nodes when running several table scans (select *) in parallel. The symptoms may be that transactions abort frequently, repair or recovery may take a long time to complete, and there may be frequent timeouts in various parts of the system. Solution To fix the problem, the Windows registry variable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters can be set to a value higher than the default 100. It is recommended that you increase this value to 0x1000 (4096). For more information, see. article 811003 from the Microsoft support pages. |
|||
6453946 |
Load balancer plugin healthcheck generates a large number of connection/disconnection at the background (load). For health check purposes, a runDaemonMonitor thread performs connect/disconnect for every Application Server listener. This can lead to connection saturation on Application Server. Solution A new attribute, monitor-interval-in-seconds, has been developed for the loadbalancer.xml file. This attribute can be used to insert a pause between connect/disconnect events in the case where hundreds of listeners are configure for the load balancer plugin. Default pause value is 0. |