[Top]
[Previous Page] [Next Page] [Bottom]
As an administrator, you must ensure that once your application is up and running, it meets (and continues to meet) the performance, availability, and security requirements your company has set for it. To perform this task, you need to monitor the resources (such as shared memory), activities (such as transactions), and potential problems (such as security breaches) in your configuration, and take any corrective actions that are necessary.
To help you meet this responsibility, the BEA TUXEDO system provides tools that enable you to oversee both system events and application events. This chapter explains how to use these tools to keep your application performing fast, well, and securely.
Specifically, this chapter discusses the following topics:
This section describes the types of data available for monitoring a running system and explains how to use that data.
Your BEA TUXEDO system maintains parameter settings and generates statistics for the following system components:
To ensure that you have the information necessary for monitoring your system, the BEA TUXEDO system provides the following three data repositories:
UBBCONFIG-an ASCII
file in which you define the parameters of your system and application This chapter describes the data stored in the UBBCONFIG file and in the Bulletin Board, and provides
instructions for monitoring that data. For a description of the log files, see
The administrative data provided by your BEA TUXEDO system allows you to monitor a multitude of potential trouble areas on your system. For example, this data allows you to:
Moreover, you can set up your system so that it is able to use the statistics in the Bulletin Board to make decisions and to modify system components dynamically, without your help. With proper configuration, your system may be able to do tasks such as the following (when indicated by Bulletin Board statistics):
Thus, by monitoring the administrative data for your system, you can prevent and resolve problems that threaten the performance, availability, and security of your application.
Two types of administrative data are available on every running BEA TUXEDO system: static and dynamic.
Static data about your configuration consists of configuration settings that you assign
when you first configure your system and application. These settings are never changed
without intervention (either in real-time or through a program you have provided).
Examples include system-wide parameters (such as the number of machines being used) and
the amount of IPC resources (such as shared memory) allocated to your system on your local
machine. Static data is kept in the UBBCONFIG
file and in the Bulletin Board.
At times you will need to check the static data about your configuration. For example:
MAXMACHINES). Dynamic data about your configuration consists of information that changes in real time, that is, while an application is running. For example, the load (the number of requests sent to a server) and the state of various configuration components (such as servers) change frequently. Dynamic data is kept in the Bulletin Board.
You will need to check the dynamic data about your configuration frequently. For example:
These numbers will help you determine whether adding more servers is likely to improve performance.
BLOCKTIME. To monitor a running application, you need to keep track of the dynamic aspects of your
configuration and sometimes check the static data. Thus, you need to be able to watch the
Bulletin Board on an ongoing basis and consult the UBBCONFIG file when necessary. The
BEA TUXEDO system provides the following methods of doing both tasks, as shown in this
table.
Which method is best for you? The answer depends on your answers to several questions.
If you have a lot of experience as an administrator (and shell programming expertise), you may prefer to write programs that automate your most frequently run commands.
If not, you may be most comfortable using the Web-based GUI.
If you examine the RESOURCES section of the UBBCONFIG file through the tmadmin command, you see only the
current values; the defaults are not displayed.
If you decide to monitor your system at run time through the tmadmin command interpreter,
continue reading; this chapter describes tmadmin and explains how to use it.
This section provides the following information:
tmadmin session, including: tmadmin sessions and instructions for invoking them tmadmin commands tmadmin
meta-commands: commands that help you make the best-and most efficient-use of the tmadmin commands tmadmin for most tasks Instructions for individual tasks are provided in later sections of this chapter.
The tmadmin command
is an interpreter for 50 commands that let you view and modify a Bulletin Board and its
associated entities.
Note: tmadmin
is supported on UNIX and Windows NT platforms.
How might you want to use tmadmin
to modify your system while it is running? Consider the following sample scenario. Suppose
you want to check the current values for all the parameters listed in the Bulletin Board,
such as maximum number of servers and services. You can do this by running the tmadmin command, bbparms.
tmadmin session
starts when you (the administrator) enter the tmadmin command at a shell prompt. The shell prompt($) is replaced
by the tmadmin prompt (>) which is used until you quit tmadmin. $ tmadmin [operating_mode_option]
>
You can request one of three operating modes on the command line:
the default mode (which allows you to view and change the Bulletin Board and associated
entities), read-only mode (-r),
or configuration mode (-c).
tmadmin verifies that
the configuration is running. If the configuration is not running the following message is
displayed: No bulletin board exists. Entering boot mode >
tmadmin checks the TUXCONFIG and TUXOFFSET environment variables to
get the location and offset at which the configuration file has been loaded. (Be sure you
have defined these variables before beginning a tmadmin session.) tmadmin enters the
Bulletin Board in one of the following three states, depending on which operating mode you
have requested. tmadmin with no options), tmadmin enters the Bulletin Board as
an administrative process, allowing you to view and make changes to configuration
components and/or activities listed in the Bulletin Board. tmadmin -r), tmadmin
enters the Bulletin Board as a client instead of as an administrator. This mode is useful
if you want to leave the administrator slot unoccupied. (Only one tmadmin process can be the
administrator at one time.) If the -r
option is specified by a user other than the BEA TUXEDO administrator and security is
turned on, the user is prompted for a password. tmadmin -c), tmadmin
enters the Bulletin Board as an administrative process, allowing you to make changes to
the configuration components and/or activities listed in the Bulletin Board. You can
request configuration mode on any machine, whether the machine is active or inactive. (A
machine is considered active if tmadmin
can join the application as an administrative process or as a client, via a running BBL.) > prompt is
displayed on your screen and you enter a tmadmin command. Not all tmadmin commands are available on
every machine at all times. Which commands are available depends on several factors:
tmadmin session For details, see the tmadmin(1) reference page in the BEA TUXEDO Reference Manual.
Whenever you start a tmadmin
session, you have a choice of operating modes for that session: read-only mode,
configuration mode, or the default operating mode. In addition, you can generate a report
of the BEA TUXEDO version and license numbers.
In this mode, you can view the data in the Bulletin Board, but you cannot make any
changes. The advantage of working in read-only mode is that your administrator process is
not tied up by tmadmin;
the tmadmin process
attaches to the Bulletin Board as a client, leaving your administrator slot available for
other work.
To start a tmadmin
session in read-only mode, specify the -r
option on the command line:
$ tmadmin -r
In this mode, you can view the data in the Bulletin Board and, if you are the BEA
TUXEDO application administrator, you can make changes. You can start a tmadmin session in configuration
mode on any machine, including an inactive machine. On most inactive machines,
configuration mode is required. (The only inactive machine on which you can start a tmadmin session without requesting
configuration mode is the MASTER
machine.)
To start a tmadmin
session in configuration mode, specify the -c option on the command line:
$ tmadmin -c
If you want to view and change Bulletin Board data during a tmadmin session, you must:
UID and GID must be those of the
administrator). $ tmadmin
To find out which version of the BEA TUXEDO system you are running and to get the
license number for it, specify the -v
option on the command line:
$ tmadmin -v
After displaying the version and license numbers, tmadmin exits, even if you have
specified -c or -r in addition to -v. When -v is requested, all other options
are ignored.
The tmadmin command
interpreter is equipped with a set of meta-commands, commands that help you use tmadmin.
tmadmin meta-commands.
Note: The tables and examples in this chapter include the abbreviated
forms of the tmadmin
command names.
The default
meta-command (d) lets
you set and unset defaults for the following frequently used parameters for most tmadmin commands: group name, server
ID, machine, user name, client name, queue address, service name, device blocks, device
offset, and UDL configuration device path. (For details, see the tmadmin(1) reference page in the BEA
TUXEDO Reference Manual.)
Note: You cannot assign defaults to any parameters for the boot and shutdown commands.
Once defaults are set, they remain in effect until the session ends or until the parameters are reset to different values. The remainder of this section provides a list of instructions for checking, setting, and unsetting defaults:
default meta-command without any
options. Listing 12-1 Default Output
> dDefault Settings: Group Name: (not set) Server ID: (not set) Machine ID: (not set) Queue Name: (not set) Client Name: (not set) Service Name: (not set) User Name: (not set) Blocks: 1000 Offset: 0 Path: /home/apps/bank/bankdll # Path defaults to value of FSCONFIG>
default command, specifying the
parameter, as follows: default -parameter new_value
For example, to change the default of the service name to "teller," enter the following command:
default -s teller
default
command with the appropriate option for the parameter in question, followed by the * wildcard argument. default -parameter*
For example, to unset the default for the service name (specified
with the -s argument),
enter the following command:
default -s *
For most parameters, when you unset the default setting without specifying a new one, the result is that you have no default for that parameter. This generalization does not apply to the machine ID parameter, however.
In a multiprocessor environment, the value of the machine ID can be a specific
processor, the DBBL, or all.
If the value of the machine ID is a specific processor, information is retrieved only from
that processor. To remind you of this fact, the logical machine ID is added to the tmadmin session prompt (LMID >), as shown in
Listing 12-2 Prompt When Machine ID Is Set to a Specific Processor
# 1. default mid not previously set> d -m SITE1 # 2. set SITE1 as default midSITE1 > # 3. prompt now shows default mid
If you unset the current default of the machine ID without specifying a new default, the DBBL is used, automatically, as the new default. In other words, if you enter
default -m *
DBBL becomes the machine ID. You can also simply specify DBBL as the new machine by entering the following:
default -m DBBL
Most tmadmin commands
require explicit information about the resource on which the command is to act. Required
arguments can always be specified on the command line, and can often be set via the default command, as well. tmadmin reports an error if the
required information is not available from either source.
Some tmadmin
statistical commands interpret unspecified default parameters as all.
This section provides the basic procedure for running tmadmin commands. Commands for doing
specific monitoring tasks through tmadmin
are provided in the section
Note: For complete details about tmadmin, see the tmadmin(1) reference page in the BEA
TUXEDO Reference Manual.
Perform the following steps to run the tmadmin commands.
TUXCONFIG
and TUXOFFSET
environment variables have been set. tmadmin in the
appropriate operating mode. -c
option on the tmadmin
command line. -r
option on the tmadmin
command line. tmadmin
session prompt (>) is
displayed, enter your first tmadmin
command. Specify, on the command line, how much information from the Bulletin Board you
want to have displayed. tmadmin_command -v For example: bbparms
-v
tmadmin_command -t For example: bbparms
-t
tmadmin command, continue entering tmadmin commands until you are ready
to end the session. tmadmin
session by entering: quit
tmadmin commands
that enable you to perform such a check. The table also suggests follow-up actions you
might take if the tmadmin
command you run generates a particular type of output.
Note: For a comprehensive list of the tmadmin commands, see the tmadmin(1) reference page in the BEA
TUXEDO Reference Manual.
.
This section provides examples of output from the following tmadmin monitoring commands:
printqueue printconn printnet printtrans Note: For a list of all 50 tmadmin commands, see the tmadmin(1) reference page in the BEA
TUXEDO Reference Manual.
The following output from the printqueue
command lets you check the distribution of work in the bankapp application.
printqueue [qaddress] tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved. >pq
Note: By default, information is supplied for all queues. If you want your output to be limited to information about only one queue, specify the address for the desired queue.
The output of this command includes the following information.
The following (verbose) output from the printconn command shows that the client process has:
printconn [-m machine]
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> echo
Echo now on.
> v
Verbose now on.
> pc
Originator
Group/pid: Client/29704
LMID: SITE1
Sends: 0
Subordinate
Group/server id: Group1/2
LMID: SITE1
Sends: -
Service: TOUPPER1
Originator
Group/pid: Client/29704
LMID: SITE1
Sends: 0
Subordinate
Group/server id: Group1/2
LMID: SITE1
Sends: -
Service: TOUPPER2
This section shows the output from the following procedure.
printnet command
was run. (The output shows the number of messages sent and received by both sites.) BRIDGE process at SITE2 was stopped. printnet command
was re-entered. (The output shows that SITE2
is no longer connected to the master machine, SITE1.)
printnet [-m machine_list]
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> echo
Echo now on.
> pnw
SITE1 Connected To: msgs sent msgs received
SITE2 100103
SITE2 Connected To: msgs sent msgs received
SITE1 104 101
> pnw
SITE1 Connected To: msgs sent msgs received
Could not retrieve status from SITE2
>
The printtrans
command reports statistics only for transactions that are currently in progress,
specifically, statistics on the number of rollbacks, commits, and aborts that have been
executed on your machine, group, or server.
This section shows the output produced by running the printtrans command in terse and
verbose modes:
GTRID
(a unique string that identifies a transaction across an application) and the transaction
state are shown. Note: The index shown in the example is used by the administrator to commit or abort the transaction.
printtrans [-m machine] [-g groupname]
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> pt
>> index=0>gtrid=x0 x2bb8f464 x1
: Machine id: SITE1, Transaction status: TMGACTIVE
Group count: 1
> v
Verbose now on.
> pt
>> index=0>gtrid=x0 x2bb8d464 x1
: Machine id: SITE1, Transaction status: TMGACTIVE
Group count: 1, timeout: 300, time left: 299
Known participants:
group: GROUP1, status: TMGACTIVE, local, coord
>
This section presents a sample configuration for a multiprocessor (MP) version of the bankapp application. This section
also shows the output that was returned when the local IPC resources and system-wide
parameters were checked by running the appropriate tmadmin commands.
For this case study, we will use the configuration defined in the UBBCONFIG file shown in
Listing 12-3 UBBCONFIG File for bankapp (MP Version)
#Copyright (c) 1997, 1998 BEA Systems, Inc.#All rights reserved RESOURCESIPCKEY 80952UID 4196GID 601PERM 0660MAXACCESSERS 40MAXSERVERS 35MAXSERVICES 75MAXCONV 10MAXGTT 20MASTER SITE1,SITE2 SCANUNIT 10SANITYSCAN 12BBLQUERY 180BLOCKTIME 30DBBLWAIT 6OPTIONS LAN,MIGRATEMODEL MPLDBAL Y#MACHINESmchn1 LMID=SITE1 TUXDIR="/home/tuxroot" APPDIR="/home/apps/bank" ENVFILE="/home/apps/bank/ENVFILE" TLOGDEVICE="/home/apps/bank/TLOG" TLOGNAME=TLOG TUXCONFIG="/home/apps/bank/tuxconfig" TYPE="3B2" ULOGPFX="/home/apps/bank/ULOG"wgs386 LMID=SITE2 TUXDIR="/home2/tuxroot" APPDIR="/home2/apps/bank" ENVFILE="/home2/apps/bank/ENVFILE" TLOGDEVICE="/home2/apps/bank/TLOG" TLOGNAME=TLOG TUXCONFIG="/home2/apps/bank/tuxconfig" TYPE="386" ULOGPFX="/home2/apps/bank/ULOG"#GROUPSDEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2# For NT/Netware, :bankdb: becomes ;bankdb;BANKB1 LMID=SITE1 GRPNO=1 OPENINFO="TUXEDO/SQL:/home/apps/bank/bankdl1:bankdb:readwrite"BANKB2 LMID=SITE2 GRPNO=2 OPENINFO="TUXEDO/SQL:/home2/apps/bank/bankdl2:bankdb:readwrite" NETWORKSITE1 NADDR="//mach1.beasys.com:1900" BRIDGE="/dev/tcp" NLSADDR="//mach1.beasys.com:1900"SITE2 NADDR="//mach386.beasys.com:1900" BRIDGE="/dev/tcp" NLSADDR="//mach386.beasys.com:1900"SERVERS#DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A" TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1 CLOPT="-A -- -T 100"TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1 CLOPT="-A -- -T 200"TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2 CLOPT="-A -- -T 600"TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2 CLOPT="-A -- -T 700"XFER SRVGRP=BANKB1 SRVID=5XFER SRVGRP=BANKB2 SRVID=6ACCT SRVGRP=BANKB1 SRVID=7ACCT SRVGRP=BANKB2 SRVID=8BAL SRVGRP=BANKB1 SRVID=9 BAL SRVGRP=BANKB2 SRVID=10BTADD SRVGRP=BANKB1BTADD SRVGRP=BANKB2 SRVID=12AUDITC SRVGRP=BANKB1 SRVID=13 CONV=Y MIN=1 MAX=10BALC SRVGRP=BANKB1 SRVID=24BALC SRVGRP=BANKB2 SRVID=25# SERVICESDEFAULT: LOAD=50 AUTOTRAN=NWITHDRAWAL PRIO=50 ROUTING=ACCOUNT_IDDEPOSIT PRIO=50 ROUTING=ACCOUNT_IDTRANSFER PRIO=50 ROUTING=ACCOUNT_IDINQUIRY PRIO=50 ROUTING=ACCOUNT_IDCLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_IDOPEN_ACCT PRIO=40 ROUTING=BRANCH_IDBR_ADD PRIO=20 ROUTING=BRANCH_IDTLR_ADD PRIO=20 ROUTING=BRANCH_IDABAL PRIO=30 ROUTING=b_idTBAL PRIO=30 ROUTING=b_idABAL_BID PRIO=30 ROUTING=b_idTBAL_BID PRIO=30 ROUTING=b_idABALC_BID PRIO=30 ROUTING=b_idTBALC_BID PRIO=30 ROUTING=b_id ROUTINGACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE="FML" RANGES="10000-59999:BANKB1, 60000-109999:BANKB2, *:*"BRANCH_ID FIELD=BRANCH_ID BUFTYPE="FML" RANGES="1-5:BANKB1, 6-10:BANKB2, *:*"b_id FIELD=b_id BUFTYPE="VIEW:aud" RANGES="1-5:BANKB1, 6-10:BANKB2, *:*"
To check the local IPC resources for this configuration, a tmadmin session was started, and the
bbsread command was run.
The output of bbsread is
shown in
Listing 12-4 bbsread Output
SITE1> bbsread
IPC resources for the bulletin board on machine SITE1:SHARED MEMORY: Key: 0x1013c38SEGMENT 0: ID: 15730 Size: 36924 Attached processes: 12 Last attach/detach by: 4181
This semaphore is the system semaphoreSEMAPHORE: Key: 0x1013c38 Id: 15666 | semaphore | current | last | # waiting | | number | status | accesser | processes | |----------------------------------------------| | 0 | free | 4181 | 0 | |------------|----------|----------|-----------|This semaphore set is part of the user-level semaphoreSEMAPHORE: Key: IPC_PRIVATE Id: 11572
| semaphore | current | last | # waiting | | number | status | accesser | processes | |----------------------------------------------| | 0 | locked | 4181 | 0 | | 1 | locked | 4181 | 0 | | 2 | locked | 4181 | 0 | | 3 | locked | 4181 | 0 | | 4 | locked | 4181 | 0 | | 5 | locked | 4181 | 0 | | 6 | locked | 4181 | 0 | | 7 | locked | 4181 | 0 | | 8 | locked | 4181 | 0 | | 9 | locked | 4181 | 0 | | 10 | locked | 4181 | 0 | | 11 | locked | 4181 | 0 | | 12 | locked | 4181 | 0 | | 13 | locked | 4181 | 0 | |------------|----------|----------|-----------|
Note: The display is the same with verbose mode on or off.
To check the current values of the system-wide parameters for this configuration, we
started a tmadmin
session and ran the bbparms
command. The output of bbparms
is shown in
Listing 12-5 Sample bbparms Output
> bbparmsBulletin Board Parameters: MAXSERVERS: 35 MAXSERVICES: 75 MAXACCESSERS: 40 MAXGTT: 20 MAXCONV: 10 MAXBUFTYPE: 16 MAXBUFSTYPE: 32 IPCKEY: 35384 MASTER: SITE1,SITE2 MODEL: MP LDBAL: Y OPTIONS: LAN,MIGRATE SCANUNIT: 10 SANITYSCAN: 12 DBBLWAIT: 6 BBLQUERY: 180 BLOCKTIME: 30
Note: The display is the same with verbose mode on or off.
[Top] [Previous Page] [Next Page] [Bottom]