Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 3 Administration Guide

> ## Chapter 21
> Administering the High-Availability Database (Enterprise Edition)

> This chapter describes the high-availability database (HADB) in the Sun Java™ System Application Server Enterprise Edition 7 environment and explains how to configure and administer a database instance.

> The tasks described in this chapter fit into the overall steps to set up the HADB, which are summarized in the following table.

> Table 21-1 HADB Roadmap

> Step | Description of Task | Location of Instructions
> --- | --- | ---
> 1 | Decide on your high-availability topology and set up your systems | Sun Java System Application Server System Deployment Guide
> 2 | Install the HADB software with or without the Sun Java System Application Server software | Sun Java System Application Server Installation Guide
> 3 | Set up the following for HADB machines: Management Domains Environment variables | Current chapter
> 4 | Create and start the HADB* Administer the HADB | Current chapter
> 5 | Set up session persistence and the session persistence store* | Chapter 20, "Configuring Session Persistence (Enterprise Edition)"
> 6 | Tune the HADB for maximum performance | Sun Java System Application Server Performance Tuning Guide
> * Can be done as part of cluster setup using the clsetup command. See the Sun Java System Application Server Installation Guide.

> This chapter contains the following sections:

> - About the High-Availability Database
> - Configuring the HADB
> - Managing the HADB
> - Expanding the HADB
> - Monitoring the HADB
> - Maintaining the HADB Machines
> - Viewing and Modifying Configuration Attributes
> - Clearing and Archiving History Files
> - Recovering from Session Data Corruption
> - hadbm Environment Variables
> - Changes Between HADB 4.3 and 4.4
> - Using Sun Customer Support for the HADB

> ##

> About the High-Availability Database

> The high-availability database (HADB) is used to store persistent HTTP session and stateful session bean (SFSB) session information. Without a session persistence mechanism, the HTTP or SFSB session state, including the passivated session state, is lost when one web or EJB container fails over to another. Use of the HADB for session persistence overcomes this situation.

> For more details on the HADB architecture, see Sun Java System Application Server System Deployment Guide.

> This section contains procedures for setting up and configuring the HADB database for use by the Application Server.

> - Prerequisites
> - Starting Management Agents
> - Using the hadbm Command

> ### Prerequisites

> Before you can set up and configure HADB, make sure you meet the following requirements:

> - HADB supports IPv4 only: The IP addresses of the HADB management agent (configuration variable, ma.server.mainternal.interfaces) and HADB hosts (given as --hosts option to hadbm createdomain, hadbm create, hadbm extenddomain and hadbm addnodes) must be IPv4 addresses.
> - The network (routers, switches and network interfaces on the hosts) must be configured for UDP multicast. If HADB hosts span multiple subnets, the routers between the subnets must also be configured to forward UDP multicast messages between the subnets.
> - If firewalls are installed between HADB hosts and Application Server, they must allow UDP communication, since HADB uses UDP as the communication protocol.
> - Do not use dynamic IP addresses (DHCP) for hosts that are part of hadbm createdomain, hadbm extenddomain, hadbm create, or hadbm addnodes commands.
> - The management agent process, ma, must be running on the HADB hosts to execute any management command, including database creation.

> For more details and other installation related requirements, see Sun Java System Application Server Installation Guide.

> ### Starting Management Agents

> #### This section contains the following topics:

> - ma Command Syntax
> - Starting the Management Agent on Solaris and Linux
> - Starting the Management Agent on Windows
> - Management Agent Options
> - Management Agent Operands

> The management agent must be configured and started on all hosts where HADB is going to be deployed. If the management agents are not running, hadbm client commands will not be executed.

> The management agent can be started as:

> - Console mode: this is not recommended in production environments.
> - A service: The service mode will ensure the availability of the agent process ma and therefore is recommended for production systems.

> The management agent process ensures the availability of the HADB node supervisor processes by restarting them if they fail. However, for deployment, the availability of the ma process should be ensured when the process fails or the OS reboots. This can be achieved by the following methods:

> - On Windows: start the management agent as a service.
> - On Unix platform:
> - Use the ma-initd script.
> - Hardlink the ma-initd script located in the HADB_install_dir/bin directory to /etc/init.d. This allows the management agent to be started or stopped manually using the following command:

> ln ma-initd/etc/init.d/ma-initd

> The management agents can now be started or stopped with the following command:

> /etc/init.d/ma-initd {start/stop}

> #### ma Command Syntax

> ma [--define=assignment] [--javahome=JAVA_HOME] [--systemroot=root_path] [--version] [--help] [--install] [--remove] [--service] [--name=name_of_service] [agent-config-file]

> Note | The following options are available only on the Windows platform: --systemroot, --install, --remove, --service, --name. Management agent can be registered as a Windows service by using the service options: --install, --service, and --name.. For more information on these options, see Table 21-3.

> A sample management agent configuration file, called mgt.cfg, is installed in HADB_install_dir/lib directory. If you have not installed HADB in the default location, edit the mgt.cfg file to enter appropriate values that match your environment.

> Note | When specifying paths for the Windows platform as property values (in the mgt.cfg file or on the command line), ensure that: Paths containing spaces are escaped with double quotes ("). The drive and directory separators, : and \, are escaped with double quotes and a backslash: "\:" and "\\".

> #### Starting the Management Agent on Solaris and Linux

> Use the following procedure to start the management agents manually, in a customized way, on each HADB host:

> 1. Edit the shell script file ma-initd located in HADB_install_dir/lib, and replace the default values for HADB_ROOT and HADB_MA_CFG, if necessary, to match your installation.
> 2. Use the command, ./ma-initd start, to start the agent, and ./ma-initd stop, to stop the agent.
> 3. To activate automatic restart of the management agent, for example, when rebooting the system, do the following:
> 1. Read operating system documentation on switching runlevels and system initialization.
> 2. Edit the shell script file ma-initd located in HADB_install_dir/lib, and and copy it to the /etc/init.d directory.
> 3. Create the following softlinks pointing to the file, /etc/init.d/ma-initd:

> /etc/rc0.d/K20ma-initd
> /etc/rc1.d/K20ma-initd
> /etc/rc2.d/K20ma-initd
> /etc/rc3.d/S99ma-initd
> /etc/rc5.d/S99ma-initd
> /etc/rcS.d/K20ma-initd

> 4. To deactivate automatic start and stop of the agent, remove or disable the softlinks.

> This procedure makes sure that the management agent is started only when the system enters runlevel 3, which is the default for Solaris, or 5, which is default for RedHat Linux running in the graphical mode. When entering other runlevels, the management agent is stopped. To check the default runlevel of your system, inspect the file, /etc/inittab, and look for a line near the top of the file, such as : id:5:initdefault:, that indicates a default runlevel 5.

> When you upgrade to later versions of HADB, you might have to replace the ma-initd file with a newer one.

> #### Starting the Management Agent on Windows

> Use the following procedure to start and stop the management agents manually:

> 1. Use the ma.exe executable file located in HADB_install_dir/bin:

> ma.exe config file

> 2. Kill the process to stop the agent.
> 3. Follow these procedures to install the management agent as a Windows service (to start automatically after a reboot ot service failure):
> 1. Use the ma.exe executable file located in HADB_install_dir/bin:

> ma.exe -i config file to start the agent and install it as a service. The agent is now in HA mode and will attempt a restart if it fails or the system is rebooted.

> 2. Use the command, ma.exe -r config file to stop the agent and remove it as a service. The service is stopped and unregistered.

> To administer the management agent, go to Windows’ Administrative Tools\Services and use the options provided.

> #### Management Agent configuration File Entries

> The configuration file, mgt.cfg, is useful for custom deployments, and can be re-used on all hosts within the same domain. The following table provides the entries available in the management agent configuration file.

> Table 21-2 Sample Configuration File Entries

> Variable | Type | Default | Values
> --- | --- | --- | ---
> console.loglevel | String | WARNING | SEVERE, ERROR, WARNING, INFO, FINE, FINER, FINEST
> logfile.loglevel | String | INFO | SEVERE, ERROR, WARNING, INFO, FINE, FINER, FINEST
> logfile.name | String | C:\Sun\SUNWhadb\ma\ma.log | Agent log file location: A valid path with read/write access.
> ma.server.type | String | jmxp | Client protocol. Currently, only JMXMP supported.
> ma.server.jmxmp.port | in | 1862 | Port number for internal (UDP) + external (TCP) communication. Recommended range: 1024-49151.
> ma.server.mainternal.interfaces | String | None | Select interface(s) for internal communication. Needed when running on machines with multiple interfaces. The interface addresses must be IPv4 addresses.
> ma.server.dbdevicepath | String | On Unix: /opt/SUNWappserver7/SUNWhadb/4.4.1-6 On Windows: C:\Sun\AppServer7\SUNWhadb\4.4.1-6 | Path to store HADB device information.
> ma.server.dbhistorypath | String | On Unix: /var/tmp On Windows: REPLACEDIR (REPLACEDIR is replaced by the actual URL at runtime.) | Path to store HADB history (textual log) files.
> ma.server.dbconfigpath | String | C:\Sun\SUNWhadb\dbdef | Path where node configuration data is stored,
> repository.dr.path | String | C:\Sun\SUNWhadb\repository | Path to domain repository files.

> #### Management Agent Options

> The following table identifies the options available with the management agent.

> Table 21-3 Management Agent Options

> Option | Description | Type/Value-ranges | Default
> --- | --- | --- | ---
> --version -V | Prints the version details of the management agent and exit | boolean | FALSE
> --javahome -j | Path to Java Runtime Environment to use for the agent (Version 1.4 or later). | Pathname | None
> --define -D | Property value assignment for an agent property defined in Table 21-2 can be repeated. | String | None
> --systemroot -y | Path to the operating system root as normally set in %SystemRoot%. For Windows platforms only. | String | None
> --service -s | Runs the agent in Windows service manger compliant mode. For Windows platforms only. | boolean | FALSE
> --name -n | Use this name for the service (when running multiple agents on a host). For Windows platforms only. | String | HADBMgmtAgent
> --install -i | Installs the agent as a Windows service and starts the service. For Windows platforms only. | boolean | FALSE
> --remove -r | Stops the service and deletes the agent from the Windows service manger. For Windows platforms only. | boolean | FALSE
> --help -? | Prints brief description about the management agent. | boolean | FALSE

> #### Management Agent Operands

> Table 21-4 Management Agent Operands

> Operands | Range of values
> --- | ---
> agent-config-file | Full path to a file with the agent configuration. Default on Unix: /etc/opt/SUNWhadb/mgt.cfg Default on Windows: C:\Sun\SUNWhadb\config\mgt.cfg

> ####

> ### Using the hadbm Command

> The hadbm command is the command-line interface used to manage the HADB domain and its database instances. This hadbm command-line interface is located in the install_dir/SUNWhadb/4/bin directory by default. The hadbm sends management requests to the specified management agent. The database configuration information is available to the management agent from the repository.

> The commands to administer HADB are subcommands of the hadbm command. The general syntax is as follows:

> hadbm subcommand [-short-option [option-value]]* [--long-option [option-value]]* [operands]*

> - Most commands have one operand (usually dbname).
> - Some commands do not have any operands (for example: list, listpackages, listdomain).
> - Some commands have two operands (for example: stopnode, restartnode, startnode (nodenumber and dbname).

> For example, the following is one use of the hadbm status subcommand, which checks the status of HADB:

> hadbm status --nodes

> The subcommand identifies the operation or task to perform. Subcommands are case-sensitive.

> Command options are also case-sensitive. Each option has a long form and a short form. Short forms have a single dash (-); while long forms have two dashes (--). Options modify how hadbm performs a subcommand. Most options require argument values, except for boolean options, which must be present to switch a feature on. Options are enclosed in square brackets [ ]and are not required for successful execution of the command.

> For subcommands that take a database name, if a database is not identified, the default database is used. The default database is hadb, all lowercase.

> For security reasons, all hadbm commands require an administrator password. This feature can be turned off for testing or evaluation during the pre-deployment phase by specifying the option, --no-adminauthentication for hadbm create, or hadbm createdomain if it is performed before hadbm create.

> For enhanced security, set the password for a subcommand from a file instead of entering the password at the command line. The --adminpasswordfile option takes the file containing the passwords. The valid contents for the file are:

> HADBM_ADMINPASSWORD=password

> The rest of the contents of the file are ignored. If both the --adminpassword and --adminpasswordfile options are specified, the --adminpassword takes precedence. If a password is required, but is not specified in the command, you are prompted for a password.

> Note | The administrator password option, adminpassword, can be set only during the creation of the database and cannot be changed later.

> HADB also requires a password to perform operations that modify database schema. Creating, deleting, or refragmenting tables, adding users and changing access privileges are few examples that require a database password. This password is denoted by the option --ddbpassword or --dbpasswordfile. hadbm create, hadbm addnodes and hadbm refragment commands require this password. If you specify the dbpassword in a file, ensure the file contains HADBM_DBPASSWORD=password.

> The hadbm general command options, used with any hadbm subcommand, are listed in the following table. All are booleans that are not present by default.

> Table 21-5 hadbm General Options

> Long Form | Short Form | Description
> --- | --- | ---
> --quiet | -q | Executes the subcommand silently without any descriptive messages.
> --help | -? | Displays a brief description of this command and all the supported subcommands. No subcommand is required.
> --version | -V | Displays the version details of the hadbm command. No subcommand is required.
> --yes | -y | Executes the subcommand in non-interactive mode.
> --force | -f | Executes the command non-interactively and does not throw an error if the command’s post condition is already achieved.
> --echo | -e | Displays the subcommand with all the options and their user-defined values or the default values, then executes the subcommand.

> ##

> Configuring the HADB

> This section describes the following basic HADB configuration tasks:

> - Creating Management Domains
> - Registering and Unregistering HADB Packages
> - Creating a Database
> - Setting Heterogeneous Device Paths
> - Configuring Double Networks
> - Setting Up the JDBC Connection Pool

> Note | The clsetup command creates an HADB database as part of cluster initialization and setup. This is the recommended way of creating a database. For details about clsetup, see Sun Java System Application Server Installation Guide. For details about setting user permissions, see Sun Java System Application Server Installation Guide.

> ### Creating Management Domains

> The command, hadbm createdomain, creates a management domain of HADB hosts listed in hostlist, by initializing the internal communication channels between hosts, along with the persistence configuration store.

> The following prerequisites must be met before using the hadbm createdomain command:

> - HADB management agents are running on the hosts.
> - The managements agents are not members of an existing domain.
> - All the management agents are configured to use the same port.
> - All the management agents can reach each other over UDP, TCP, and with IP multicast.

> All the hosts that are part of the desired domain must be included in the hostlist. To form a domain, the hostlist must consist of valid network addresses.

> After the management domain is successfully created, all the hosts in the domain are enabled and the management agents are ready to manage databases.

> Usage:

> hadbm createdomain [--adminpassword=password |--adminpasswordfile=file | --no-adminauthentication] --agent=maurl hostlist

> After creating the HADB domains, create the HADB database that will hold your data. For more information on creating HADB databases, see Creating a Database.

> Consult the following tables for more details on the options and operands used with hadbm createdomain command.

> Table 21-6 hadbm createdomain command options

> Option | Description | Type/Value-ranges | Default
> --- | --- | --- | ---
> -w --adminpassword=password | Use the administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command. | String | None
> -W --adminpasswordfile=file | Use the adminpasswordfile option to provide the password as a path to a file that contains the password. | Pathname | None
> -U --no-adminauthentication | The --no-adminauthentication option allows the administrator to use all hadbm commands without providing the administrator’s password. | String | None
> -m --agent=maurl | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port. | String | localhost:1862

> Table 21-7

> hostlist | Comma separated list of all hosts that are part of the management domain. | String | None

> hadbm createdomain command operands

> #### Example for Creating an HADB Management Domain

> hadbm createdomain --adminpassword=password host1,host2,host3,host4

> Domain host1,host2,host3, host4 created.

> After creating HADB domains, register the path and version of the HADB packages with the management agents.

> Registering HADB packages in the HADB management domain makes it easy to upgrade or change HADB packages. The management agent keeps track of where the software packages are located, as well as the version information, for the hosts in the domain. The default package name is a string starting with V and containing the version number of the hadbm program.

> After the software package is registered or unregistered in the domain registry, you can change the package the database is using by setting the database instance to use the newly installed package with hadbm set packageName=newpackage. This command is required when doing an online upgrade.

> The following sections describe how to register and unregister HADB packages:

> - Registering HADB Packages
> - Unregistering HADB Packages

> #### Registering HADB Packages

> Use the hadbm registerpackage command to register the HADB packages that are installed on the hosts in the management domain. HADB packages can also be registered when creating a database with hadbm create.

> Before using the hadm registerpackage command, ensure that all management agents are configured and running on all the hosts in the hostlist, the management agent’s repository is available for updates, and no software package is already registered with the same package name.

> The hadbm registerpackage command syntax is as follows:

> hadbm registerpackage --packagepath=path [--hosts=hostlist] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [package-name]

> Example:

> Registering a software package, v4, on specific hosts in the domain:

> hadbm registerpackage --packagepath=hadb_install_dir/SUNWHadb/4.4 --hosts=host1,host2,host3 v4

> Package successfully registered.

> If the --hosts option is omitted, the package is registered on all enabled hosts in the domain.

> The hadbm registerpackage command options are listed in the following table.

> Table 21-8 hadbm registerpackage Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --packagepath=path | -L | none | Path to the HADB software package.
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.

> #### Unregistering HADB Packages

> Use the hadbm unregisterpackage command to remove HADB packages that are registered with the management domain.

> Before using the hadbm unregisterpackage command, ensure that all management agents are configured and running on all the hosts in the hostlist, the management agent’s repository is available for updates, the package is registered in the management domain, and no existing databases are configured to run on the package about to be unregistered.

> The hadbm unregisterpackage command syntax is as follows:

> hadbm unregisterpackage --hosts=hostlist [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [package-name]

> Example:

> Unregistering a software package, v4, from specific hosts in the domain:

> hadbm unregisterpackage --hosts=host1,host2,host3 v4

> Package successfully unregistered.

> If the --hosts option is omitted, the hostlist defaults to the enabled hosts where the package is registered.

> The hadbm unregisterpackage command options are listed in the following table.

> Table 21-9 hadbm unregisterpackage Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --hosts=hostlist | -H | none | Comma or double quote enclosed space separated list of hosts.
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.

> ### Creating a Database

> The clsetup command creates an HADB database as part of cluster initialization and setup. This is the recommended way of creating a database. For details about clsetup, see the Sun Java System Application Server Installation Guide.

> However, you can create a database outside of clsetup to store session data. To manually create a database, use the hadbm create command. The syntax is as follows.

> hadbm create [--package=package name] [--packagepath=path] [--historypath=path] [--devicepath=path] [--datadevices=number of devices per node] [--portbase=base no] [--spares=number of spares] [--set=attr-name-value-list] [--agent=maurl] [--no-cleanup] [--no-clear] [--devicesize=size] [--dbpassword=password | --dbpasswordfile=file ] [--adminpassword=password | --adminpasswordfile=file | --no-adminauthentication] --hosts=host list [dbname]

> For example:

> hadbm create --spares 2 --devicesize 1024 --dbpassword secret123 --hosts n0,n1,n2,n3,n4,n5

> Note | Error messages from hadbm create will be written to the console, not to the Application Server’s log files. To create and start a database manually, do the following: Create the management domain, register the HADB package, and create the database.

> If you have difficulty creating a database, check the following:

> - You have started the management agents and defined an HADB domain. For details, see Starting Management Agents and Creating Management Domains.
> - File and directory permissions must be set to allow read, write, and execute access to the install, history, device, and config paths for the following users:
> - Sun Java System Application Server administrative user (set during installation)
> - HADB system user

> For details about setting user permissions, see the Sun Java System Application Server Installation Guide.

> - Sun Java System Application Server and HADB port assignments must not conflict with other port assignments on the same machine. Default and recommended port assignments are as follows:
> - Sun Java System Message Queue: 7676
> - IIOP: 3700
> - HTTP server: 80
> - Admin server: 4848
> - HADB nodes: Each node uses six consecutive ports. If the default portbase 15200 is used, node 0 uses 15200 through 15205, node 1 uses 15220 through 15225, and so on.
> - Disk space must be adequate; see the Sun Java System Application Server Installation Guide.

> Note | hadbm create can be run as a simple or composite command. If hadbm createdomain and hadbm registerpackage are not already executed, hadbm create implicitly executes these commands before executing create. Running the first two commands implicitly, by running hadbm create, will reduce work for the user if all commands complete successfully. However, failures in any of the commands might make debugging difficult. Besides, the composite hadbm create command is not atomic, that is, if one of the commands fails, the commands that successfully executed previously will not be rolled back. For example, if hadbm createdomain and hadbm registerpackage execute successfully but hadbm create database fails, the changes made by hadbm createdomain and hadbm registerpackage will persist. Therefore, you should run hadbm create after hadbm createdomain and hadbm registerpackage are completed successfully.

> The hadbm create command options are listed in the following table.

> Table 21-10 hadbm create Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --historypath | -t | On Unix: /var/tmp On Windows: REPLACEDIR (REPLACEDIR is replaced by the actual URL at runtime.) | Specifies the path to the history files. This path must already exist and be writable. For details about history files, see Clearing and Archiving History Files. If the --historypath option is not specified, the default value is the value specified for management agent. hadbm connects to the path specified in ma.server.dbhistorypath. For more details, see Sample Configuration File Entries.
> --devicepath | -d | On Unix: /opt/SUNWappserver7/SUNWhadb/4.4.1-6 On Windows: C:\Sun\AppServer7\SUNWhadb\4.4.1-6 | Specifies the path to the devices. There are three devices: the DataDevice, the NiLogDevice (node internal log device), and the RelalgDevice (relational algebra query device). This path must already exist and be writable. To set this path differently for each node or each device, see “Setting Heterogeneous Device Paths” on page 537. If the --devicepath option is not specified, the default value is the value specified for management agent. hadbm connects to the path specified in ma.server.dbdevicepath. For more details, see Sample Configuration File Entries.
> --datadevices | -a | 1 | Specifies the number of data devices on each node, between 1 and 8 inclusive. Data devices are numbered starting at 0.
> --portbase | -b | 15200 | Specifies the port base number used for node 0. Successive nodes are automatically assigned port base numbers in steps of 20 from this number. Each node uses its port base number and the next five consecutively numbered ports. If you want to run several databases on the same machine, you should have a plan for allocating port numbers and allocate them explicitly.
> --spares | -s | 0 | Specifies the number of spare nodes. This number must be even and must be less than the number of nodes specified in the --hosts option. Spare nodes are optional, but having two or more ensures high availability.
> --set | -S | none | Specifies a comma-separated list of database configuration attributes in name=value format. For explanations of valid database configuration attributes, see Viewing and Modifying Configuration Attributes. To use --set to set the --devicepath differently for each node or each device, see “Setting Heterogeneous Device Paths” on page 537.
> --devicesize | -z | 1024MB The maximum size is the maximum operating system file size or 256 GB, whichever is smaller. The minimum size is as follows: (4 x LogbufferSize + 16MB) / number of datadevices given by the option, --datadevicesize. | The devicesize is given for each node. It should be as large as possible. The recommended size = reserved space for HADB + (4 x user data /number of nodes). The reserved space for HADB is = LogbufferSize + 1% of the DataDeviceSize. You can increase the device size later as described in Adding Storage Space to Existing Nodes. For more information on setting the LogbufferSize, see Viewing and Modifying Configuration Attributes.
> --dbpassword | -p | none | Creates a password for the HADB system user. Must be at least 8 characters. You can use --dbpasswordfile instead. For details, see Using the hadbm Command.
> --dbpasswordfile | -P | none | Specifies a file that stores the password to be created for the HADB system user. For details, see Using the hadbm Command.
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --no-adminauthentication | -U | None | The --no-adminauthentication option allows the administrator to use all hadbm commands without providing the administrator’s password.
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agents. The syntax for the maurl is: hostlist:port. hostlist is a comma separated list of hostnames/IP-addresses.
> --hosts | -H | none | Specifies a comma-separated list of host names or IP addresses for the nodes in the database. Using IP addresses is recommended because there is no dependence on DNS lookups. Host names must be absolute. You cannot use localhost or 127.0.0.1 as a host name. One node is created for each comma-separated item in the list. The number of nodes must be even. Using duplicate host names creates multiple nodes on the same machine with different port numbers. Make sure that nodes on the same machine are not mirror nodes. Nodes are numbered starting at 0 in the order listed in this option. The first mirrored pair are nodes 0 and 1, the second 2 and 3, and so on. Odd numbered nodes are in one DRU, even numbered nodes in the other. If --spares is used, spare nodes are those with the highest numbers. For information about configuring double network interfaces, see Configuring Double Networks.

> dbname | none | hadb | Specifies the database name, which must be unique. To make sure the database name is unique, use the hadbm list command to list existing database names. Use the default database name unless you need to create multiple databases. For example, to create multiple clusters with independent databases on the same set of HADB machines, use a separate database name for each cluster.

> hadbm create Command Operands

> Note | Unlike the earlier HADB version 4.3.x, with HADB 4.4.x you can change devicepaths using hadbm set and hadbm addnodes commands. You can also change historypaths using hadbm set and hadbm addnodes.

> ### Configuring Double Networks

> To allow HADB to tolerate single network failures, you can use IP multipathing if the operating system (for example, Solaris) has this feature. For more details on configuring IP multipathing, see Sun Java System Application Server Installation Guide.

> If your operating system is not configured for IP multipathing, and the HADB hosts are equipped with two NIC cards, you can configure HADB to use double networks. For every host, the IP addresses of each of the NIC cards must be on separate IP subnets.

> Note | Routers between the subnets must be configured to forward UDP multicast messages between subnets.

> During database creation, you specify two IP addresses or host names for each node, one for each NIC card IP address, using the --hosts option. For each node, the first IP address is on net-0 and the second on net-1. The syntax is as follows, with host names for the same node separated by a plus sign (+):

> --hosts=node0net0name+node0net1name,node1net0name+node1net1name,node2net0name+node2net1name, ...

> For example, the following creates two nodes, each with two host names. The host names for node 0 are n0a and n0b, and the host names for node 1 are n1a and n1b. The n0a and n1a hosts are on net-0, and the n0b and n1b hosts are on net-1.

> --hosts n0a+n0b,n1a+n1b

> Within a database, all nodes must be connected to a single network, or all nodes must be connected to two networks.

> ### Setting Up the JDBC Connection Pool

> The Sun Java System Application Server communicates with the HADB in the same way that it communicates with relational databases used for data storage, therefore you need to set up a JDBC connection pool for the HADB as you would for any other database.

> Using the clsetup command is recommended for configuring a JDBC connection pool and JDBC resource for the HADB in the Sun Java System Application Server. This command is described in the Sun Java System Application Server Installation Guide.

> Manual configuration of a JDBC connection pool and JDBC resource for the HADB is briefly summarized in these sections:

> - Getting the JDBC URL
> - Creating a Connection Pool
> - Connection Pool Example
> - Creating a JDBC Resource

> For general information about connection pools and JDBC resources, see About JDBC Resources.

> #### Getting the JDBC URL

> Before you can set up the JDBC connection pool, you need to determine the JDBC URL of the HADB using the hadbm get command as follows:

> hadbm get JdbcUrl [dbname]

> For example:

> hadbm get JdbcUrl

> The JDBC URL is displayed on the standard output device in the following form:

> jdbc:sun:hadb:host:port,host:port,...

> Remove the jdbc:sun:hadb: prefix and use the host:port,host:port... part as the value of the serverList connection pool property, described in the next section.

> For a list of all attributes for hadbm get, see Table 21-27.

> #### Creating a Connection Pool

> The following table summarizes connection pool settings required for the HADB. Change Steady Pool Size when adding nodes, but do not change other settings.

> Table 21-11 HADB Connection Pool Settings

> Setting | Required Value for HADB
> --- | ---
> Name | The HADB JDBC resource’s Pool Name setting must refer to this name
> Database Vendor | HADB 4.4
> Global Transaction Support | Unchecked/false
> DataSource Classname | com.sun.hadb.jdbc.ds.HadbDataSource
> Steady Pool Size | Use 8 connections for each active HADB node. For more detailed information, see the System Deployment Guide.
> Connection Validation Required | Checked/true
> Validation Method | meta-data
> Table Name | Do not specify
> Fail All Connections | Unchecked/false
> Transaction Isolation | repeatable-read
> Guarantee Isolation Level | Checked/true

> The following table summarizes connection pool properties required for the HADB. Change serverList when adding nodes, but do not change other properties.

> Table 21-12 HADB Connection Pool Properties

> Property | Description
> --- | ---
> username | Specifies the name of the storeuser to be specified in the asadmin create-session-store command. See Creating the Session Store.
> password | Specifies the storepassword to be specified in the asadmin create-session-store command. See Creating the Session Store.
> serverList | Specifies the JDBC URL of the HADB. To determine this value, see Getting the JDBC URL. You must change this value if you add nodes to the database. See Adding Nodes to the HADB.
> cacheDatabaseMetaData | Setting this property to false as required ensures that calls to Connection.getMetaData() make calls to the database, which ensures that the connection is valid.
> eliminateRedundantEndTransaction | Setting this property to true as required improves performance by eliminating redundant commit and rollback requests and ignoring these requests if no transaction is open.
> maxStatement | Specifies the maximum number of statements per open connection that are cached in the driver statement pool. Set this property to 20.

> #### Connection Pool Example

> Here is an example asadmin create-jdbc-connection-pool command that creates an HADB JDBC connection pool. For more details about this command, see the Sun Java System Application Server Developer’s Guide to J2EE Services and APIs.

> asadmin create-jdbc-connection-pool --user adminname --password secret --datasourceclassname com.sun.hadb.jdbc.ds.HadbDataSource --steadypoolsize=32 --isolationlevel=repeatable-read --isconnectvalidatereq=true --validationmethod=meta-data --property username=storename:password=secret456:serverList=host\\:port,host\\:port,host\\:p ort,host\\:port,host\\:port,host\\:port:cacheDatabaseMetaData=false:eliminateRedund antEndTransaction=true hadbpool

> Note that colon characters (:) within property values must be escaped with double backslashes (\\) on Solaris™ platforms, because otherwise they are interpreted as property delimiter. On Windows platforms, colon characters (:) must be escaped with single backslashes (\). For details about using escape characters, see Using Escape Characters.

> #### Creating a JDBC Resource

> The following table summarizes JDBC resource settings required for the HADB.

> Table 21-13 HADB JDBC Resource Settings

> Setting | Description
> --- | ---
> JNDI Name | The following JNDI name is the default in the session persistence configuration: jdbc/hastore. You can use the default name or a different name. You must also specify this JNDI name as the value of the store-pool-jndi-name Persistence Store property when you activate the availability service. See Referencing the HADB Database’s JDBC Resource.
> Pool Name | Select from the list the name (or ID) of the HADB connection pool used by this JDBC resource. For more information, see Configuring Double Networks.
> Data Source Enabled | Checked/true

> ##

> Managing the HADB

> In general, management operations are not necessary unless you are replacing or upgrading your network, hardware, operating system, or HADB software. The following sections explain various management operations:

> - Starting a Node
> - Stopping a Node
> - Restarting a Node
> - Starting the HADB
> - Stopping the HADB
> - Restarting the HADB
> - Listing Databases
> - Clearing the HADB
> - Removing a Database

> ### Starting a Node

> You will have to start a node in the following circumstances:

> - A node was stopped and its host has undergone a hardware or software upgrade or replacement successfully.
> - An HADB node was stopped or fails to restart for some reason, other than double failures. For more information on how to recover from double failures, see Clearing the HADB.

> In most cases, you should first attempt to start the node using the normal start level. You must use the repair start level if starting a node using the normal start level fails or times out.

> To start a node in the database, use the hadbm startnode command. The syntax is as follows:

> hadbm startnode [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [--startlevel=level] nodeno [dbname]

> For example:

> hadbm startnode 1

> The hadbm startnode command options are listed in the following table.

> Table 21-14 hadbm startnode Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.
> --startlevel | -l | normal | Valid levels are normal, repair and clear. Start level normalstarts the node with the data found locally on the node (in the memory and in the data device file on the disk) and it synchronizes with the mirror for the recent updates it missed. Start level repair is used to force the node to discard the local data content and copy it from its mirror. Start level clear should be used when the device files need to be initialized. This will be necessary if they are damaged or the disk that contained the device files is replaced.

> Table 21-15

> nodeno | none | none | Specifies the node you want to start. You can use the hadbm status command to display the numbers of all nodes in a database.
> dbname | none | hadb | Specifies the database name.

> hadbm startnode Operands

> ### Stopping a Node

> You might have to stop a node if you want to stop the machine for hardware or software replacement or upgrade.

> To stop a node in the database, use the hadbm stopnode command. The syntax is as follows:

> hadbm stopnode [--adminpassword=password | --adminpasswordfile=file] [--agent=<maurl>] [--no-repair] nodeno [dbname]

> For example:

> hadbm stopnode 1

> The hadbm stopnode command options are listed in the following table.

> Table 21-16 hadbm stopnode Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.
> --no-repair | -R | not present | If present, the node is stopped and no spare node replaces the stopped node. By default, a spare node starts up and takes over the functioning of the stopped node.

> Table 21-17 hadbm stopnode Operands

> Long Form | Short Form | Default | Description
> nodeno | none | none | Specifies the node you want to stop. You can use the hadbm status command to display the numbers of all nodes in a database. The mirror node of this node number must be running.
> dbname | none | hadb | Specifies the database name.

> ### Restarting a Node

> You might have to restart a node if you notice strange behavior in a node (for example excessive CPU consumption) and want to check whether a restart cures the problem.

> To restart a node in the database, use the hadbm restartnode command. The syntax is as follows:

> hadbm restartnode [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [--startlevel=level] nodeno [dbname]

> For example:

> hadbm restartnode 1

> The hadbm restartnode command options are listed in the following table.

> Table 21-18 hadbm restartnode Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.
> --startlevel | -l | normal | Specifies the level at which you want to start the node. Valid levels are normal, repair and clear. Starting a node at the level repair forces an active node to repair data from its mirror node. Starting a node at level clear will reinitialize the devices for the node, and force a repair of data from its mirror node.

> Table 21-19

> Long Form | Short Form | Default | Description
> nodeno | none | none | Specifies the node you want to start. You can use the hadbm status command to display the numbers of all nodes in a database.
> dbname | none | hadb | Specifies the database name.

> hadbm restartnode Operands

> ### Starting the HADB

> To start a database, use the hadbm start command. The syntax is as follows:

> hadbm start [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> For example:

> hadbm start

> The default dbname is hadb, all lowercase.

> This command starts all nodes that were running before the database was stopped. Individually stopped (offline) nodes are not started when the database is started after a stop.

> ### Stopping the HADB

> When you stop and start the HADB in separate operations, data is unavailable while the HADB is stopped. To keep data available, you can restart the HADB as described in Restarting the HADB.

> You may want to stop the HADB in the following circumstances:

> - If you want to remove the HADB database.
> - If you want to perform system maintenance that affects all HADB nodes.

> Before stopping the HADB, you should either stop dependent Sun Java System Application Server instances or configure them to use a different persistence method.

> To stop a database, use the hadbm stop command. The syntax is as follows:

> hadbm stop [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> For example:

> hadbm stop

> The default dbname is hadb, all lowercase. For more information about database states, see Getting the Status of the HADB.

> When you stop the database, all the running nodes in the database are stopped and the status of the database is Stopped.

> ### Restarting the HADB

> You may want to restart the HADB if you notice strange behavior in the HADB (for example consistent timeout problems) and want to check whether a restart cures the problem.

> When you restart the HADB, data and database services remain available. When you stop and start the HADB in separate operations, data and database services are unavailable while the HADB is stopped. This is because hadbm restart performs a rolling restart of nodes: it stops and starts the nodes one by one. In contrast, hadbm stop stops all nodes simultaneously.

> To restart a database, use the hadbm restart command. The syntax is as follows:

> hadbm restart [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [--no-rolling] [dbname]

> For example:

> hadbm restart

> The default dbname is hadb, all lowercase. By default, this command restarts each of the nodes in the database to the current state or a better state. If you specify the --no-rolling or -g option, this command restarts all nodes at once, with loss of service.

> ### Listing Databases

> To list all the databases that have been created, use the hadbm list command. The syntax is as follows:

> hadbm list [--agent=maurl] [--adminpassword=password | --adminpasswordfile=file]

> ### Clearing the HADB

> You should clear the HADB in the following circumstances:

> - If the hadbm status command reveals that the database is Non Operational or if multiple nodes are not responding and are in the waiting state for a long time. See Getting the Status of the HADB.
> - If you are recovering from session data corruption. See Recovering from Session Data Corruption.

> The hadbm clear command stops the database nodes, clears the database devices, then starts the nodes. The syntax is as follows.

> hadbm clear [--fast] [--spares=sparecount] --dbpassword=password | --dbpasswordfile=file [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl][dbname]

> For example:

> hadbm clear --fast --spares=2 --dbpassword secret123

> hadbm clear will erase all the Application Server schema data store in HADB: the Application Server tables, users, dbpasswords. You must recreate the data schema after running hadbm clear.

> The hadbm clear command options are listed in the following table.

> Table 21-20 hadbm clear Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --fast | -F | not present | If present, skips device initialization while initializing the database. Do not use if the disk storage device is corrupted.
> --spares | -s | previous number of spares | Specifies the number of spare nodes the reinitialized database will have. This number must be even and must be less than the number of nodes in the database. Spare nodes are optional, but having two or more ensures high availability.
> --dbpassword | -p | none | Specifies the HADB system user password. You can use --dbpasswordfile instead. For details, see Using the hadbm Command.
> --dbpasswordfile | -P | none | Specifies a file that stores the password for the HADB system user. For details, see Using the hadbm Command.
> --adminpassword | -w | none | The administrator password to manage the domain. If you use the adminpassword option with hadbm createdomain or hadbm create, then you must enter this password each time you use any hadbm command.
> --adminpasswordfile | -W | None | Use the adminpasswordfile option to provide the password as a path to a file that contains the password
> --agent=maurl | -m | localhost:1862 | This is the URL to the management agent. It is a comma separated list of hostnames/IP-addresses. The syntax for the maurl is: hostlist:port.

> ### Removing a Database

> The database you want to remove must exist and must be in the Stopped state. See Stopping the HADB. To remove an existing database from the HADB system, use the hadbm delete command. The syntax is as follows:

> hadbm delete [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> For example:

> hadbm delete

> The default database name is hadb, all lowercase. When you execute this command, the configuration files, device files, and history files of the database are deleted, and shared memory resources are freed.

> ##

> Expanding the HADB

> There are two situations where your original HADB configuration becomes inadequate and you have to scale up the HADB:

> - The user data to persist has increased beyond the storage space allocated in the data device files. Transactions may start aborting due to full data devices.
> - The user load has increased and the existing system resources have exhausted. You want to add more hosts.

> This section describes how you can expand the HADB without shutting down your Sun Java System Application Server cluster or the HADB.

> - Adding Storage Space to Existing Nodes
> - Adding Machines
> - Adding Nodes to the HADB
> - Refragmenting the HADB
> - Adding Nodes by Recreating the Database

> You should also read Maintaining the HADB Machines.

> ### Adding Storage Space to Existing Nodes

> You may want to add storage space to the HADB in the following circumstances:

> - If the user transactions abort with one of the following error messages and this persists:

> 4592: No free blocks on data devices

> 4593: No unreserved blocks on data devices

> - If hadbm deviceinfo command reports insufficient free size and this situation persists. See Getting Device Information.

> If there is unused space on the disks on which the HADB nodes reside, or if you have added/upgraded the disks with larger capacity, you can increase the device size in MB using the following hadbm set commands:

> hadbm set DataDeviceSize=size

> For example:

> hadbm set DataDeviceSize=1024

> The DataDeviceSize should be as large as possible. The recommended size is four times the expected size of the user data, and in addition to space reserved for the HADB. The user data is based on the number of users and the size of each user record. The reserved space is four times the size of logBufferSize.

> Changing the DataDeviceSize on a database in a FaultTolerant or higher state means that the system is upgraded without loss of data, and the database remains in an Operational state during the reconfiguration. If you change device size on a system that is not FaultTolerant or better, data is lost. For more information about database states, see Database Status.

> ### Adding Machines

> You may want to add machines if the HADB requires more processing or storage capacity. For an explanation of node topology alternatives, see the Sun Java System Application Server System Deployment Guide.

> To add a new machine on which to run the HADB, install the HADB packages with or without the Sun Java System Application Server as described in the Sun Java System Application Server Installation Guide.

> To integrate new machines into the existing HADB instance, perform the following tasks:

> 1. Start management agents on these nodes.
> 2. Extend the management domain to the new hosts. For details, see hadbm extenddomain command.
> 3. Start the new nodes on these hosts. For more details, see Adding Nodes to the HADB.

> ### Adding Nodes to the HADB

> When you create new nodes and add them to the database, you increase processing and storage capacity. To add nodes, use the hadbm addnodes command. The syntax is as follows:

> hadbm addnodes [--no-refragment][--spares=sparecount] [--historypath=path] [--devicepath=path] [--set=attr-name-value-list] [--dbpassword=password | --dbpasswordfile=file ] [--adminpassword=password | --adminpasswordfile=file] --hosts=hostlist [dbname]

> For example:

> hadbm addnodes --dbpassword secret123 -adminpassword=password --hosts n6,n7,n8,n9

> If the --devicepath and --historypath option is not specified on the addnodes command, the new nodes will have the same devicepath and historypath as the existing database.

> After you have added nodes, you must perform these additional tasks:

> - Update the serverlist property in the HADB’s JDBC connection pool.
> - Adjust the Steady Pool Size of the HADB’s JDBC connection pool. Generally, you add 8 more connections for each new node. For more detailed information, see the Sun Java System Application Server System Deployment Guide.

> For details, see Setting Up the JDBC Connection Pool.

> The hadbm addnodes command options are listed in the following table.

> Table 21-21 hadbm addnodes Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --no-refragment | -r | not specified | If specified, does not refragment the database during node creation; In this case you have to refragment the database later using the hadbm refragment command to use the new nodes. For details about refragmentation, see Refragmenting the HADB. If you do not have sufficient device space for a refragmentation, you can recreate the database with more nodes. See Adding Nodes by Recreating the Database.
> --spares | -s | 0 | Specifies the number of new spare nodes in addition to those that already exist. This number must be even and must not be greater than the number of nodes added. Spare nodes are optional, but having two or more ensures high availability.
> --DevicePath |  | On Unix: /opt/SUNWappserver7/SUNWhadb/4.4.1-6 On Windows: C:\Sun\AppServer7\SUNWhadb\4.4.1-6 | Location of the devices. There are three devices: the DataDevice, the NiLogDevice (node internal log device), and the RelalgDevice (relational algebra query device).
> --dbpassword | -p | none | Specifies the HADB system user password. You can use --dbpasswordfile instead. For details, see Using the hadbm Command.
> --dbpasswordfile | -P | none | Specifies a file that stores the password for the HADB system user. For details, see Using the hadbm Command.
> --hosts | -H | none | Specifies a comma-separated list of new host names for the new nodes in the database. One node is created for each comma-separated item in the list. The number of nodes must be even. Using duplicate host names creates multiple nodes on the same machine with different port numbers. Make sure that nodes on the same machine are not mirror nodes. Odd numbered nodes are in one DRU, even numbered nodes in the other. If --spares is used, new spare nodes are those with the highest numbers. If the database was created with double network interfaces, the new nodes must be configured in the same way. See Configuring Double Networks.

> Table 21-22

> dbname | none | hadb | Specifies the database name. The database must be in the HA Fault Tolerant or Fault Tolerant state. For more information about database states, see Getting the Status of the HADB.

> hadbm addnodes Operands

> ### Refragmenting the HADB

> You must refragment the database to store data in the newly created nodes. Refragmentation is required to store data evenly across all active nodes. To refragment the database, use the hadbm refragment command. The syntax is as follows:

> hadbm refragment --dbpassword=password | --dbpasswordfile=file [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> For example:

> hadbm refragment --dbpassword secret123

> Note | You should add nodes to HADB at a time when your system is lightly loaded. Adding nodes performs a refragmentation and redistribution of the existing data to include the new nodes in the system. ’Online’ refragmenting requires that the disks for the HADB nodes have enough space to keep the old data and the new data simultaneously until refragmenting is finished, that is, the user data size not exceed 50% of the space available for user data. For details, see Getting Device Information.

> If this command fails even after multiple attempts, see Adding Nodes by Recreating the Database.

> The hadbm refragment command options are listed in the following table.

> Table 21-23 hadbm refragment Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --dbpassword | -p | none | Specifies the HADB system user password. You can use --dbpasswordfile instead. For details, see Using the hadbm Command.
> --dbpasswordfile | -P | none | Specifies a file that stores the password for the HADB system user. For details, see Using the hadbm Command.

> Table 21-24

> dbname | none | hadb | Specifies the database name. The database must be in the HA Fault Tolerant or Fault Tolerant state. For more information about database states, see Getting the Status of the HADB.

> hadbm refragment Operands

> ### Adding Nodes by Recreating the Database

> If the ’online’ refragment fails persistently when new nodes are added, either due to lack of data device space or other reasons, recreate the database with new nodes. This will lead to the loss of existing user data, as well as schema data.

> To add nodes by recreating the database, perform the following tasks:

> 1. Perform the following tasks for each server instance:
> 1. Disable the server instance in the load balancer, as described in Known Issues in Load Balancing Requests.
> 2. Disable session persistence as described in Basic Session Persistence Configuration Steps.
> 3. Restart the server instance.
> 4. Re-enable the server instance in the load balancer.

> If you do not need to maintain availability, you can disable and re-enable all the server instances at once in the load balancer. This saves time and prevents failover of outdated session data.

> 2. Stop the database as described in Stopping the HADB.
> 3. Delete the database as described in Removing a Database.
> 4. Recreate the database with the additional nodes as described in Creating a Database.
> 5. Reconfigure the JDBC connection pool as described in Setting Up the JDBC Connection Pool. You can also use the cladmin command. See Appendix F, "Using the cladmin Command for Administration (Enterprise Edition)."
> 6. Reload the session persistence store as described in Basic Session Persistence Configuration Steps. You can also use the cladmin command.
> 7. Perform the following tasks for each server instance:
> 1. Disable the server instance in the load balancer.
> 2. Enable session persistence as described in Basic Session Persistence Configuration Steps.
> 3. Restart the server instance.
> 4. Re-enable the server instance in the load balancer.

> If you do not need to maintain availability, you can disable and re-enable all the server instances at once in the load balancer. This saves time and prevents failover of outdated session data.

> ##

> Monitoring the HADB

> You can monitor the activities in the HADB by performing the following tasks:

> - Getting the Status of the HADB
> - Getting Device Information
> - Getting HADB Runtime Resource Usage Information

> These sections briefly describe the hadbm status, hadbm deviceinfo, and hadbm resourceinfo commands. For details about interpreting HADB information, see the Sun Java System Application Server Performance Tuning Guide.

> ### Getting the Status of the HADB

> To display the status of the database or its nodes, use the hadbm status command. The syntax is as follows:

> hadbm status [--nodes] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl][dbname]

> For example:

> hadbm status --nodes

> The hadbm status command options and operands are listed in the following tables.

> Table 21-25 hadbm status Options

> Long Form | Short Form | Default | Description
> --- | --- | --- | ---
> --nodes | -n | not present | If present, displays node status information. See Node Status.

> Table 21-26 hadbm status Operands

> dbname | none | hadb | Specifies the database name.

> #### Database Status

> The possible states of a database are as follows:

> - High-Availability Fault Tolerant (HAFaultTolerant) - The database is fault tolerant and has at least one spare node on each DRU.
> - Fault Tolerant (FaultTolerant) - All the mirrored node pairs are up and running.
> - Operational (Operational) - At least one node in each mirrored node pair is running.
> - Non Operational (NonOperational) - One or more mirrored node pairs is missing both nodes.
> - Stopped (Stopped) - No nodes are running in the database.
> - Unknown (Unknown) - The command cannot determine the state of the database.

> If the database is Non Operational, clear the database using hadbm clear as described in Clearing the HADB.

> #### Node Status

> If you specify the --nodes option, the following information is displayed for each node in the database:

> - Node number
> - Name of the machine where the node is running
> - Port number of the node
> - Role of the node. For a list of possible roles and their meanings, see Roles of a Node.
> - State of the node. For a list of possible states and their meanings, see States of a Node.
> - Number of the corresponding mirror node.

> A node’s role and state can change as described in these sections:

> - Roles of a Node
> - States of a Node

> ##### Roles of a Node

> A node is assigned a role during its creation and can take any one of these roles:

> - Active: An active node allows data storage and client access. Active nodes are in mirrored pairs.
> - Spare: After having their data devices initialized, spare nodes monitor other data nodes to initiate repair if another node becomes unavailable. A spare node allows client access, but not data storage.
> - Offline: Offline nodes provide no services until their role changes. An offline node’s role can change back to its former role.
> - Shutdown: An intermediate step between active and offline, which a node occupies while waiting for a spare node to take over its functioning. After the spare node has taken over, the node is taken offline.

> ##### States of a Node

> A node can be in any one of the following states:

> - Starting: The node is starting.
> - Waiting: The node cannot decide its start level and is offline. If a single node is in this state for more than two minutes, stop the node and then start it at the repair level; see Stopping a Node and Starting a Node. If multiple nodes are in this state, clear the database as described in Clearing the HADB.
> - Running: The node is providing all services that are appropriate for its role.
> - Stopping: The node is in the process of stopping.
> - Stopped: The node is inactive. Repair of a stopped node is prohibited.
> - Recovering: The node is being recovered. When a node fails, the mirror node takes over the functions of the failed node. The failed node tries to recover by using the data and log records in main memory or on disk. The failed node uses the log records from the mirror node to catch up with the transactions performed when it was down. If recovery is successful, the node becomes active. If recovery fails, the node state changes to Repairing.
> - Repairing: The node is being repaired. This operation reinitializes the node and copies the data and log records from the mirror node. Repair is more time consuming than recovery.

> ### Getting Device Information

> Another aspect that can be monitored is the free space in the HADB data devices. You may want to check this in the following situations:

> - As one of the daily routines: check the disk space usage trend.
> - As part of preventive maintenance: if the user load has increased in your business and you want to resize/scale the database configuration.
> - As part of scaling up the database: you want to run hadbm addnodes to add new nodes to the system and you want to check whether there is enough device space. (Remember, you need around 40-50% free space on the existing nodes to perform this operation).
> - No free blocks on data devices or No unreserved blocks on data devices messages start appearing in the history files as well as server.log.

> To get information about disk storage devices on each active node, use the hadbm deviceinfo command. The syntax is as follows:

> hadbm deviceinfo [--details] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> For example:

> hadbm deviceinfo --details

> The default dbname is hadb.

> The information displayed for each node of the database includes:

> - Total device size (allocated in MB).
> - Free size (in MB).
> - Usage (in percent).

> To determine the space available for user data, take the total device size, then subtract the space reserved for HADB: four times the LogBufferSize + 1% of the device size. If you do not know the size of the log buffer, use the command hadbm get logbufferSize. For example, if the total device size is 128 MB and the LogBufferSize is 24 MB, the space available for user data is 128 – (4 x 24) = 32 MB. Of the 32 MB, 50% is used for replicated data and around one % is used for the indices, and only 25 % is available for the real user data.

> For a list of all attributes for hadbm get, see Table 21-27.

> The space available for user data is the difference between the total size and reserved size. If the data is refragmented in the future, the free size must be approximately equal to 50% of the space available for user data.If refragmentation is not relevant, the data devices can be exploited to their maximum. Resource consumption warnings are written to the history files when the system is running short on device space.

> For more information about tuning the HADB, see the Sun Java System Application Server Performance Tuning Guide.

> If the --details option is specified, additional information is displayed:

> - Number of reads.
> - Number of writes.
> - Name of the device.

> For example:

> NodeNO Totalsize Freesize Usage NReads NWrites DeviceName

> 0 128 120 6% 10000 5000 C:\Sun\SUNWhadb\hadb.data.0

> 1 128 124 3% 10000 5000 C:\Sun\SUNWhadb\hadb.data.1

> 2 128 126 2% 9500 4500 C:\Sun\SUNWhadb\hadb.data.2

> 3 128 126 2% 9500 4500 C:\Sun\SUNWhadb\hadb.data.3

> ### Getting HADB Runtime Resource Usage Information

> If you need additional information, you can use the hadbm resourceinfo command. This command displays HADB runtime resource information that helps to identify resource contention, which you can use to reduce performance bottlenecks. For details, see the Sun Java System Application Server System Deployment Guide and the Sun Java System Application Server Performance Tuning Guide. The syntax is as follows:

> hadbm resourceinfo [--databuf] [--locks] [--logbuf] [--nilogbuf] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]

> The following database information is displayed based on the options you specify:

> - --databuf displays the data buffer pool information.
> - --locks displays the locks information.
> - --logbuf displays the log buffer information.
> - --nilogbuf displays the node internal log buffer information.
> - Data Buffer Pool
> - Locks
> - Log Buffer
> - Node Internal Log Device

> #### Data Buffer Pool

> Data buffer pool information contains the following:

> - NodeNo: Node number.
> - Avail: Total space available in the pool, in MB.
> - Free: Free space available.
> - Access: Number of accesses to the data device from database, from start until now. This is cumulative.
> - Misses: Number of page faults that have occurred from database start until now. This is cumulative.
> - Copy-on-Write: Number of pages copied internally in the data buffer due to checkpointing. This is cumulative.

> When a user transaction performs an operation on a record, the page containing the record must be in the data buffer pool. If it is not there, a miss or a page fault has occurred. The transaction then has to wait until the page is retrieved from the data device file on the disk.

> If the miss rate is high, it indicates that the data buffer pool needs to be increased. Since the misses are cumulative, hadbm resourceinfo should be run periodically and the difference between two runs should be used to see the trend of miss rate.

> The administrator does not need to worry if the free space is very small, since new blocks will be made available by the checkpointing mechanism.

> An example data buffer pool information is as follows:

> NodeNO Avail Free Access Misses Copy-on-Write

> 0 256 128 100000 50000 1000

> 1 256 128 110000 45000 950

> #### Locks

> Locks information is as follows:

> - NodeNo: Node Number.
> - Avail: Total number of locks available on the node.
> - Free: Number of free locks.
> - Waits: Number of transactions waiting to acquire locks. This is cumulative.

> For example:

> NodeNO Avail Free Waits

> 0 50000 20000 10

> 1 50000 20000 0

> One single transaction cannot use more than 25% of the available locks on a node. Therefore, transactions performing operations in large scale should be aware of this limitation.The best practice is to perform such transactions in batches, where each batch must be treated as a separate transaction, that is, each batch commits. This is needed because read operations running with repeatable read isolation level, and delete, insert, and update operations use locks that are released only after the transaction terminates.

> To change the NumberOfLocks, see Viewing and Modifying Configuration Attributes.

> #### Log Buffer

> Log buffer information is as follows:

> - NodeNo: Node Number
> - Available: amount of memory allocated for the log buffer in MB
> - Free: amount of free memory in MB

> The administrator does not need to worry if the free space is very small, since HADB starts compressing the log buffer. The compression is started from the head of the ring buffer and is performed on consecutive log records. The compression procedure cannot proceed when a log record, that has not been executed by the node or has not been received by the mirror node, is encountered.

> For example:

> NodeNO Avail Free

> 0 16 2

> 1 16 3

> #### Node Internal Log Device

> Node internal log device information is as follows:

> - Node Number
> - Available: amount of memory allocated for the log device in MB
> - Free: amount of free memory in MB

> For example:

> NodeNO Avail Free

> 0 16 2

> 1 16 3

> ##

> Maintaining the HADB Machines

> The HADB achieves fault tolerance by replicating data on mirror nodes. Mirror nodes should be placed on separate DRUs in a production environment as described in Sun Java System Application Server System Deployment Guide.

> A failure is an unexpected event such as a hardware failure, power failure, or operating system reboot. The HADB tolerates single failures: of one node, one machine (that has no mirror node pairs), one or more machines belonging to the same DRU, or even one entire DRU. However, the HADB does not automatically recover from a double failure, which is the simultaneous failure of one or more mirror node pairs. If a double failure occurs, you must clear the HADB and recreate its session store, which erases all its data.

> ### Maintaining HADB on a Single Machine

> To perform planned or unplanned maintenance on a single machine without interrupting HADB service:

> 1. Perform the maintenance procedure and get the machine up and running.
> 2. Ensure that ma is running: If ma runs as a Windows service or under init.d scripts (recommended for deployment), it should have been started by the operating system. If not start it manually.

> See Starting Management Agents.

> 3. Start all nodes on the machine.

> See Starting a Node.

> 4. Check whether the nodes are active and running. See Getting the Status of the HADB.

> To perform planned maintenance, such as hardware or software upgrade, on all HADB machines without interrupting HADB service:

> 1. For each spare machine in the first DRU, repeat the single machine procedure as described in Maintaining HADB on a Single Machine, one by one, for each machine.
> 2. For each active machine in the first DRU, repeat the single machine procedure as described in Maintaining HADB on a Single Machine, one by one, for each machine.
> 3. Repeat Step 1 and Step 2 for the second DRU.

> To perform planned maintenance with HADB service interruption on all HADB machines, or when the entire HADB is on a single machine:

> 1. Stop the HADB. See Stopping the HADB.
> 2. Perform the maintenance procedure and get all the machines up and running.
> 3. Ensure ma is running.
> 4. Start the HADB. See Starting the HADB. The data stored in the database before the stop is available again.

> To perform unplanned maintenance in the event of a failure, first check the database status. See Getting the Status of the HADB.

> - If the database state is Operational or better, this means the machines needing unplanned maintenance do not include mirror nodes. Follow the single machine procedure for each failed machine, one DRU at a time. HADB service is not interrupted.
> - If the database state is Non-Operational, this means the machines needing unplanned maintenance include mirror nodes. One such case is when the entire HADB is on a single failed machine. Get all the machines up and running first. Then clear the HADB and recreate the session store. See Clearing the HADB. This interrupts HADB service.

> ##

> Viewing and Modifying Configuration Attributes

> You can modify database configuration attributes. This section describes the following tasks:

> - Getting the Values of Configuration Attributes
> - Setting the Values of Configuration Attributes
> - Configuration Attributes

> ### Getting the Values of Configuration Attributes

> To get the values of configuration attributes (for a list, see Configuration Attributes), use the hadbm get command. The syntax is as follows:

> hadbm get attribute-list | --all [dbname]

> For example:

> hadbm get JdbcUrl,NumberOfSessions

> The default dbname is hadb. The attribute-list is a comma-separated or quote-enclosed space-separated list of attributes. The --all option displays values for all attributes. For a list of all attributes for hadbm get, see Table 21-27.

> ### Setting the Values of Configuration Attributes

> To set the values of configuration attributes (for a list, see Configuration Attributes), use the hadbm set command. The syntax is as follows:

> hadbm set [dbname] attribute=value,attribute=value...

> The default dbname is hadb. The attribute=value list is a comma-separated or quote-enclosed space-separated list of attributes.

> If execution of this command is successful, the database is restarted in the state it was in previously, or in a better state. For information about database states, see Getting the Status of the HADB.

> If execution of this command is unsuccessful, restart the HADB as described in Restarting the HADB.

> The following attributes cannot be set by hadbm set, but can be set during database creation using --set or other options of hadbm create: DatabaseName, DevicePath, HistoryPath, NumberOfDatadevices, and Portbase. For information about hadbm create, see Creating a Database.

> The JdbcUrl attribute value is derived from the --hosts and --portbase options during database creation with hadbm create and cannot be set by hadbm set or the --set option.

> All other attributes listed in Table 21-27 can be set using hadbm set.

> Note | Using hadbm set to set any configuration attribute, except ConnectionTrace or SQLTraceMode, causes a rolling restart of the HADB. In a rolling restart, each node is stopped, and started with the new configuration, one at a time. Advantage of a rolling restart is that the services are not interrupted. If you set ConnectionTrace or SQLTraceMode, no rolling restart occurs, but the change only takes effect for new HADB connections made from a Sun Java System Application Server instance.

> ### Configuration Attributes

> The following table lists the configuration attributes for hadbm get and hadbm set. hadm get does not use DatabaseName, PortBase and JdbcUrl.

> Except where noted, sizes are in MB, and times are in seconds.

> Table 21-27 Configuration Attributes

> Attribute | Default | Range | Description
> --- | --- | --- | ---
> ConnectionTrace | FALSE | TRUE/FALSE | If true, records a message in the HADB history files when a client connection (JDBC, ODBC) is initiated or terminated.
> CoreFile | FALSE | TRUE/FALSE | Do not change the default value.
> DatabaseName | hadb |  | Name of the database.
> DataBufferPoolSize | 200MB | 16 - 2047 MB | Size of the data buffer pool allocated in shared memory.
> DataDeviceSize | 1024MB | 32 - 262144 MB The maximum value is the smaller of 256GB or the maximum operating system file size. The minimum value is: (4 x LogbufferSize + 16MB) / NumberOfDatadevices. | The DataDeviceSize is given for each node. It should be as large as possible. The recommended size = reserved space for HADB + (4 x user data /number of nodes). The reserved space for HADB is = LogbufferSize + 1% of the DataDeviceSize. The former is based on the number of users and the size of each user record. The latter is reserved for HADB system use. If you want to run hadbm addnodes online, you will need eight times the expected size of the user data.
> PackageName | V4.x.x.x | None | Name identifying HADB software package used by the database.
> DevicePath | On Unix: /opt/SUNWappserver7/SUNWhadb/4.4.1-6 On Windows: C:\Sun\AppServer7\SUNWhadb\4.4.1-6 |  | Location of the devices. There are three devices: the DataDevice, the NiLogDevice (node internal log device), and the RelalgDevice (relational algebra query device).
> EagerSessionThreshold | 50 (% of NumberOfSessions) | 0 - 100 | Determines whether normal or eager idle session expiration is used. In normal idle session expiration, sessions that are idle for more than SessionTimeout seconds are expired. When the number of concurrent sessions exceeds the EagerSessionThreshold percentage of the maximum number of sessions, sessions that are idle for more than EagerSessionTimeout seconds are expired.
> EagerSessionTimeout | 120 seconds | 0-2147483647 seconds | The time in seconds a database connection can be idle before it expires when eager session expiration is used.
> EventBufferSize | 0 MB | 0-2097152 MB | Size of the event buffer, where database events are logged. If set to 0, no event buffer logging is performed. During failures, the event buffer is dumped. This gives valuable information on the cause of the failures and is useful during trial deployment. Writing events to memory has a performance penalty.
> HistoryPath | On Unix: /var/tmp On Windows: REPLACEDIR (REPLACEDIR is replaced by the actual URL at runtime.) |  | (get only) Location of the HADB history files, which contain information, warnings, and error messages.
> InternalLogbufferSize | 12MB | 4 - 128 MB | Size of the node internal log device, which keeps track of operations related to storing data.
> JdbcUrl | none |  | (get only) The JDBC connection URL for the database.
> LogbufferSize | 48MB | 4 - 2048 MB | Size of the log buffer, which keeps track of operations related to data.
> MaxTables | 1100 | 100 - 1100 | Maximum number of tables allowed in an HADB database.
> NumberOfDatadevices | 1 | 1 - 8 | (get only) Number of data devices used by an HADB node.
> NumberOfLocks | 50000 | 20000-1073741824 | Number of locks allocated by an HADB node.
> NumberOfSessions | 100 | 1 - 10000 | Maximum number of sessions (database connections) that can be opened for an HADB node.
> PortBase | 15200 | 10000 - 63000 | (get only) Base port number used to create different port numbers for different HADB processes.
> RelalgDeviceSize | 128 MB | 32 - 262144 MB | Size of the device used in relational algebra queries.
> SessionTimeout | 1800 seconds | 0-2147483647 seconds | Amount of time a database connection can be idle before it expires when normal session expiration is used.
> SQLTraceMode | NONE | NONE/SHORT/ FULL | Amount of information about executed SQL queries written to the history files. If SHORT, login and logout of SQL sessions are recorded. If FULL, all SQL queries being prepared and executed, including parameter values, are recorded.
> StartRepairDelay | 20 seconds | 0 - 100000 seconds | Maximum time a spare node allows for a failed active node to perform a node recovery. If the failed node cannot recover within this time interval, the spare node starts copying data from the failed node’s mirror and becomes active. Changing the default value is not recommended.
> StatInterval | 600 seconds | 0 - 600 seconds | Interval at which an HADB node writes throughput and response time statistics to its history file. To disable, set to 0. An example statistics line is as follows: "Req-reply time: # 123, min= 69 avg= 1160 max= 9311 %=100.0" The # is the number of requests serviced over the StatInterval. The next three numbers are the minimum, average, and maximum time in microseconds taken by transactions completed over the StatInterval. The % is the number of transactions completed successfully within 15 milliseconds over the StatInterval.
> SyslogFacility | local0 | local0, local1, local2, local3, local4, local5, local6, local7, kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, none | Facility used when reporting to syslog (see man syslog for details). The syslog daemon should be configured (see man syslogd.conf for details). Use a facility that is not in use by other applications running on the same machine. Set to none to disable syslog logging.
> SysLogging | TRUE |  | Set to true if an HADB node should write any information to the operating system’s syslog files.
> SysLogLevel | warning | none, alert, error, warning, info | Lets you to fine tune which HADB messages are reported to the operating system’s syslog files. Higher levels include lower levels. For example, the error level includes alert messages, and the info level includes all messages.
> SyslogPrefix | hadb -dbname |  | Text string that is prepended to all syslog messages written by the HADB.
> TakeoverTime | 10000 (milliseconds) | 500 - 16000 milliseconds | Time between when a node fails and when its mirror takes over. Changing the default value is not recommended.

> ##

> Clearing and Archiving History Files

> HADB history files contain a record of database operations and error messages. The location of these files is determined by the --historypath option of the hadbm create command. The default location is /var/tmp. These files have names of the format dbname.out.nodeno. For details about hadbm create, see Creating a Database.

> These history files grow over time. To save space and prevent files from getting too large, you should periodically clear and archive older history files. To clear the history files of a database, use the hadbm clearhistory command. The syntax is as follows:

> hadbm clearhistory [--saveto=path] [dbname]

> The default dbname is hadb.

> Use the --saveto or -o option to specify a directory you want to store the old history files. This directory must have write permissions set.

> Each message in the history file contains the following information:

> - The name, in abbreviated form, of the HADB process that produced the message.
> - The type of message. Possible values are as follows:
> - INF - general information
> - WRN - warnings
> - ERR - errors
> - DBG - debug information
> - A timestamp. The time is obtained from the system clock on the machine used for the node.
> - The service set changes occurring in the system when a node stops or starts.

> Messages about resource shortages contain HIGH LOAD.

> You do not need a detailed knowledge of all the various types of entries in the history file. If for any reason you need to study a history file in greater detail, you should obtain help from Sun customer support. See hadbm Environment Variables.

> ##

> Recovering from Session Data Corruption

> The following are indications that session data may be corrupted:

> - Error messages appear in the Sun Java System Application Server system log (server.log) every time you try to save the session state.
> - Error messages are written to the server log indicating that the session could not be found or could not be loaded during session activation.
> - Sessions that are activated after previously being passivated contain empty or incorrect session data.
> - When an instance fails, failed-over sessions contain empty or incorrect session data.
> - When an instance fails, instances that try to load a failed-over session cause an error in the server log indicating the session could not be found or could not be loaded.

> To bring the session store back to a consistent state if you determine that the data has been corrupted, do the following:

> 1. Clear the session store.
> 2. If clearing the session store doesn’t work or you continue to see errors in the server log, reinitialize the data space on all the nodes and clear the data in the database. See Clearing the HADB.
> 3. If clearing the database doesn’t work, delete and then recreate the database. See Removing a Database and Creating a Database.

> ##

> hadbm Environment Variables

> This table lists environment variables that correspond to hadbm command options.

> Table 21-28 HADB Options and Environment Variables

> Long Form | Short Form | Default | Environment Variable
> --- | --- | --- | ---
> --adminpassword | -w | none | HADBM_ADMINPASSWORD
> --agent | --m | localhost:1862 | $HADBM_AGENT
> --datadevices | -a | 1 | $HADBM_DATADEVICES
> --dbname | none | hadb | $HADBM_DB
> --dbpassword | -p | none | $HADBM_DBPASSWORD
> --dbpasswordfile | -F | none | $HADBM_DBPASSWORDFILE
> --devicepath | -d | On Unix: /opt/SUNWappserver7/SUNWhadb/4.4.1-6 On Windows: C:\Sun\AppServer7\SUNWhadb\4.4.1-6 | $HADBM_DEVICEPATH
> --devicesize | -z | none | $HADBM_DEVICESIZE
> --echo | -e | FALSE | $HADBM_ECHO
> --fast | -F | FALSE | $HADBM_FAST
> --force | -f | FALSE | $HADBM_FORCE
> --help | -? | FALSE | $HADBM_HELP
> --historypath | -t | On Unix: /var/tmp On Windows: REPLACEDIR (REPLACEDIR is replaced by the actual URL at runtime.) | $HADBM_HISTORYPATH
> --hosts | -H | none | $HADBM_HOSTS
> --interactive | -i | TRUE | $HADBM_INTERACTIVE
> --no-refragment | -r | FALSE | $HADBM_NOREFRAGMENT
> --portbase | -b | 15200 | $HADBM_PORTBASE
> --quiet | -q | FALSE | $HADBM_QUIET
> --repair | -R | TRUE | $HADBM_REPAIR
> --rolling | -g | TRUE | $HADBM_ROLLING
> --saveto | -o | none | $HADBM_SAVETO
> --set | -S | none | $HADBM_SET
> --spares | -s | 0 | $HADBM_SPARES
> --startlevel | -l | normal | $HADBM_STARTLEVEL
> --version | -V | FALSE | $HADBM_VERSION
> --yes | -y | FALSE | $HADBM_YES

> ##

> Changes Between HADB 4.3 and 4.4

> Sun Java System Application Server Enterprise Edition 7 2004 Update 2 bundles HADB version 4.4.x compared to HADB 4.3.x shipped in the earlier versions of the Application Server (except on the Windows edition of Update 1 which contained HADB 4.4.x). Although, the HADB core remains the same as in HADB 4.3, the 4.4 version contains a completely new management system.

> The management of the HADB is improved by changing the underlying components of the management system. The old hadbm interface functions are maintained with minor modifications. These changes also removes the dependency on SSH/RSH.

> In HADB 4.4.x, a server-side management process called management agent is introduced. The management agents constitute a domain and keep the database configuration in a repository. The repository information is distributed among all agents.

> The following topics provide more details on the changes between HADB 4.4 and 4.3:

> - General Improvements
> - Specific Changes

> ### General Improvements

> - The dependency on SSH/RSH is removed.
> - The administrator password for HADB management enhances security.
> - Automatic online upgrade to future versions.
> - Dependency on a single host is removed.
> - Heterogeneous configurations of the database is supported. The device paths and history paths can be set individually.
> - Ability to manage multi-platforms uniformly, since HADB V4.4 is available on Solaris, Linux, and Windows.
> - Improved and consolidated error messages from hadbm. Now, the user need not read the HADB history files to find out why an hadbm admin command failed.
> - New options for existing hadbm commands provide more features and flexibility.

> ### Specific Changes

> - UDP multicast is a new requirement for network configuration. (See install guide).
> - New prerequisite introduced: The management agent, ma, must be running on all HADB hosts.
> - New hadbm commands introduced for domain management:
> - hadbm deletedomain
> - hadbm extenddomain
> - hadbm reducedomain
> - hadbm listdomain
> - hadbm disablehost
> - hadbm registerpackage
> - hadbm unregisterpackage
> - hadbm listpackage
> - All the hadbm commands have the following new options:
> - adminpassword
> - adminpasswordfile
> - agent
> - javahome
> - Changes made to hadbm create:
> - New options:
> - no-clear
> - no-cleanup
> - package
> - packagepath
> - agent
> - Extended options
> - hosts (This option will register hosts in the domain).
> - set (see get/set below)
> - Options removed:
> - inetd
> - inetdsetupdir
> - configpath
> - installpath
> - set TotalDataDevideSizePerNode
> - set managementProtocol
> - Modified Options

> devicesize is optional in HADB V4.4 copared to mandatory in HADB V4.3.

> - Changes made to hadbm startnode and hadbm restartnode.
> - Modified option:

> startlevel - A new value, clear, is added in V4.4.

> - Changes made to hadbm addnodes.
> - New option:

> set, historypath, devicepath

> - Options removed:

> inetdsetupdir

> - Changes made to hadbm get and hadbm set.
> - New attributes:
> - historypath - Heterogeneous path for history files
> - packagename
> - Removed attributes:
> - managementProtocol
> - TotalDeviceSizePerNode
> - installpath
> - syslogging

> ##

> Using Sun Customer Support for the HADB

> Before calling Sun customer support about HADB issues, you should gather as much of the following information about your system as possible:

> - Usage profile
> - Number of active concurrent users
> - Number of passive users
> - Number of users entering the system per second
> - Average session size
> - Session state timeout period (SessionTimeout value)
> - Transaction rate per user per second
> - Machine properties
> - Physical RAM size
> - Number of CPUs
> - CPU speed
> - Operating system version
> - Number of physical disks
> - Total disk size
> - Available disk space
> - Data transfer capacity
> - Network properties
> - Transfer capacity
> - Number of host names (network interfaces) per node
> - HADB data
> - History files
> - cfg and meta files, located in dbconfigpath/databasename/nodeno directory. dbconfigpath is defined in the variable ma.server.dbconfigpath in the management agent configuration file.
> - Version information (hadbm --version)

> Previous Contents Index Next

> Copyright 2005 Sun Microsystems, Inc. All rights reserved.