|
•
|
EventBroker—a mechanism that informs administrators of system faults and exceptional happenings such as network failures. When an event is posted by clients or servers, the EventBroker matches the name of the posted event to a list of subscribers for that event, and takes appropriate action, determined by each subscription.
|
|
•
|
Log files—a set of files that make up a repository for error and warning messages, debugging messages, and informational messages helpful in tracking and resolving problems in the system.
|
|
•
|
MIB—an interface to a set of procedures for accessing and modifying information in the MIBs. Using the MIB, you can write programs that enable you to monitor your run-time application.
|
You can access these components using the MIB or tmadmin. You can set up your system so that it can use the statistics in the bulletin board to make decisions and to modify system components dynamically, without your intervention. With proper configuration, your system can perform the following tasks (when bulletin board statistics indicate that they are required):
|
•
|
Bulletin board—a segment of shared memory (on each machine in your network) to which your system writes statistics about the components and activities of your configuration
|
|
•
|
Log files—files to which your system writes messages
|
|
•
|
UBBCONFIG—a text file in which you define the parameters of your system and application
|
Table 2‑1 describes how to use each monitoring method.
|
|
|
Command-line utilities, such as txrpt and tmadmin
|
|
|
|
|
Log files (for example, ULOG, TLOG)
|
Viewing the ULOG with any text editor; checking the ULOG for tlisten messages; and converting the TLOG (a binary file) to a text file by running tmadmin dumptlog which downloads a TLOG to a text file.
|
|
|
|
|
|
|
The tmadmin command is an interpreter for 53 commands that enable you to view and modify a bulletin board and its associated entities. Using the
tmadmin commands, you can monitor statistical information in the system such as the state of services, the number of requests executed, the number of queued requests, and so on.
Using the tmadmin commands, you can also dynamically modify your Oracle Tuxedo system. You can, for example, perform the following types of changes while your system is running:
Whenever you start a tmadmin session, you can choose the following operating modes for that session: the default operating mode, read-only mode, or configuration mode:
The txrpt command analyzes the standard error output of a Oracle Tuxedo server and provides a summary of service processing time within the server. The report shows the number of times each service was dispatched and the average amount of time it took for each service to process a request during the specified period.
txrpt takes its input from the standard input or from a standard error file redirected as input. To create standard error files, have your servers invoked with the
-r option from the
servopts(5) selection; you can name the file by specifying it with the
-e servopts option. Multiple files can be concatenated into a single input stream for
txrpt.
The tmadmin command is an interpreter for 53 commands that enable you to view and modify a bulletin board and its associated entities.
Figure 2‑2 shows you how a typical
tmadmin session works.
|
•
|
Transaction log (TLOG)—a binary file that is not normally read by you (the administrator), but that is used by the Transaction Manager Server (TMS). A TLOG is created only on machines involved in Oracle Tuxedo global transactions.
|
|
•
|
User log (ULOG)—a log of messages generated by the Oracle Tuxedo system while your application is running. The ULOGMILLISEC environment variable is used to time stamp ulog message output intervals in milliseconds instead of seconds. The ULOGRTNSIZE environment variable is used to specify rotation files size. For more information on ULOGMILLISEC and ULOGRTNSIZE, see userlog(3c) in the Oracle Tuxedo Command Reference.
|
The transaction log (TLOG) keeps track of global transactions during the commit phase. At the end of the first phase of a 2-phase commit protocol, the participants in a global transaction issue a reply to the question of whether to commit or roll back the transaction. This reply is recorded in the
TLOG.
The TLOG file is used only by the Transaction Manager Server (TMS) that coordinates global transactions. It is not read by the administrator. The location and size of the
TLOG are specified by four parameters that you set in the
MACHINES section of the
UBBCONFIG file.
The user log (ULOG) is a file to which all messages generated by the Oracle Tuxedo system—error messages, warning messages, information messages, and debugging messages—are written. Application clients and servers can also write to the user log. A new log is created every day and there can be a different log on each machine. However, a
ULOG can be shared by multiple machines when a remote file system is being used.
The ULOG provides an administrator with a record of system events from which the causes of most Oracle Tuxedo system and application failures can be determined. You can view the
ULOG, a text file, with any text editor. The
ULOG also contains messages generated by the
tlisten process. The
tlisten process provides remote service connections for other machines in an application. Each machine, including the master machine, should have a
tlisten process running on it.
The TLOG is a binary file that contains only messages about global transactions that are in the process of being committed. To view the
TLOG, you must first convert it to text format so that it is readable. The Oracle Tuxedo system provides two
tmadmin operations to do this:
|
•
|
dumptlog ( dl) downloads (or dumps) the TLOG (a binary file) to a text file.
|
|
•
|
loadtlog uploads (or loads) an text version of the TLOG into an existing TLOG (a binary file).
|
The dumptlog and
loadtlog commands are also useful when you need to move the
TLOG between machines as part of a server group migration or machine migration.
Use the MIB T_TRANSACTION class to obtain the runtime transaction attributes within the system. The
tmadmin command
printtrans (
pt) can also be used to display this information. Information about each group in the transaction is printed only if
tmadmin is running in verbose mode as set by a previous
verbose (
v) command.
You can use the information in the ULOG to identify the cause of system or application failures. Multiple messages about a given problem can be placed in the user log. Generally, earlier messages provide more useful diagnostic information than later messages.
In the following example of Listing 2‑1, message 358 from the
LIBTUX_CAT catalog identifies the cause of the trouble reported in subsequent messages, namely, that there are not enough UNIX system semaphores to boot the application.
151550.gumby!BBL.28041.1.0: LIBTUX_CAT:262: std main starting
151550.gumby!BBL.28041.1.0: LIBTUX_CAT:358: reached UNIX limit on semaphore ids
151550.gumby!BBL.28041
.1.0: LIBTUX_CAT:248: fatal: system init function ...
151550.gumby!BBL.28040
.1.0: CMDTUX_CAT:825: Process BBL at SITE1 failed ...
151550.gumby!BBL.28040
.1.0: WARNING: No BBL available on site SITE1.
Will not attempt to boot server processes on that site.
|
Note:
|
System Messages contains complete descriptions of user log messages and recommendations for any actions that should be taken to resolve the problems indicated.
|
Part of the ULOG records error messages to the
tlisten process. You can view
tlisten messages using any text editor. Each machine, including the
MASTER machine contains a separate
tlisten process. Though separate
tlisten logs are maintained in the
ULOG on each machine, they can be shared across remote file systems.
The ULOG records
tlisten process failures.
tlisten is used, during the boot process, by
tmboot and, while an application is running, by
tmadmin.
tlisten messages are created as soon as the
tlisten process is booted. Whenever a
tlisten process failure occurs, a message is recorded in the
ULOG.
The Oracle Tuxedo System Messages CMDTUX Catalog contains the following information about
tlisten messages:
A ULOG message consists of a tag and text. The tag consists of the following:
|
Note:
|
Placeholders are printed in the thread_ID and context_ID field of entries for single-threaded and single-contexted applications. (Whether an application is multithreaded is not apparent until more than one thread is used.)
|
You can request such a log when a server is activated. The txrpt facility produces a summary of the time spent by the server, thus giving you a way to analyze the log output. Using this data, you can estimate the relative workload generated by each service, which will help you set workload parameters appropriately for the corresponding services in the MIB.
Use tpadmcall when you need to query the system or make administrative changes while your system is
not running.
tpadmcall queries the
TUXCONFIG file on behalf of your request. Data buffers that you put in, and data buffers that you receive (containing your queries and the replies to them) are exactly the same.
|
•
|
MIB(5) in File Formats, Data Descriptions, MIBs, and System Processes Reference
|
ud32 is a client program delivered with the Oracle Tuxedo system that reads input consisting of text representation of
FML buffers.
You can use
ud32 for ad hoc queries and updates to the MIB. It creates an
FML32 buffer, makes a service call with the buffer, receives a reply (also in an
FML32 buffer) from the service call, and displays the results on screen or in a file in text format.
ud32 builds an
FML32-type buffer with the
FML fields and values that you represent in text format, makes a service call to the identified service in the buffer, and waits for the reply. The reply then comes back in
FML32 format as a report. Now, because the MIB is
FML32-based,
ud32 becomes the scripting tool for the MIB.
The system may, for example, write a record in the ULOG, execute a system command, or terminate a trace process. A client process can also propagate the tracing facility with its requests. This capability is called
dyeing; the trace dye
colors all services that are called by the client.
For a simple tracing expression, define TMTRACE=on in the environment of the client. This expression enables tracing of ATMI functions on the client and on any server that performs a service on behalf of that client. The trace records are written to the
ULOG file.
|
•
|
Run-time Tracing Expression: TMTRACE=atmi:/tpservice/ulog. If you export this setting within a server environment, a record with general run-time trace information is created in the ULOG file for all service requests performed on that server.
|
|
•
|
User-Level Expression: TMTRACE=atmi:utrace. Specifying the utrace receiver automatically calls the user-defined tputrace(3c). If you export this setting within a server environment, a record with trace information and output location defined by the user is created for the ATMI functions running on that server.
|
You can activate or deactivate the tracing option using the changetrace command of
tmadmin. This command enables you to overwrite the tracing expression on active client or server processes. Administrators can enable global tracing for all clients and servers, or for a particular machine, group, or server.
|
•
|
tmtrace(5) in File Formats, Data Descriptions, MIBs, and System Processes Reference
|
|
•
|
userlog(3c) and tputrace(3c) in Oracle Tuxedo ATMI C Function Reference
|
|
•
|
DBBL—the Distinguished Bulletin Board Liaison server propagates global changes to the MIB and maintains the static part of the MIB. Specifically, the DBBL:
|
|
•
|
BBL—the Bulletin Board Liaison server maintains the bulletin board on its host machine, coordinating changes to the local MIB, and verifying the integrity of application programs active on its machine. Specifically, the bulletin board:
|
Figure 2‑3 shows the diagnosis and repair using the DBBL and BBLs.
With a system failure, such as a server crashing while performing a request, the client knows the service routine did not perform its task because of an underlying system error. The Oracle Tuxedo system notifies programs of system errors that occur as it monitors the application’s behavior and its own behavior.
A blocking timeout is a mechanism that ensures a blocked program waits no longer than the specified timeout value for something to occur. Once a timeout is detected, the waiting program is alerted with a system error informing it that a blocking timeout has occurred. The blocking timeout defines the duration of service requests, or how long the application is willing to wait for a reply to a service request. The timeout value is a global value defined in the
BLOCKTIME field of the
RESOURCES section of the
TUXCONFIG file.
A transaction timeout is another type of timeout that can occur because active transactions tend to be resource-intensive. A transaction timeout defines the duration of a transaction, which may involve several service requests. The timeout value is defined when the transaction is started (with
tpbegin(3c)). Transaction timeouts are useful when maximizing resources. For example, if database locks are held while a transaction progresses, an application programmer may want to limit the amount of time that the application’s transaction resources are held up. A transaction timeout always overrides a blocking timeout.
|
•
|
TRANTIME which is specified in the SERVICES section of the UBBCONFIG and controls the timeout value for a specific AUTOTRAN service.
|
|
•
|
MAXTRANTIME which is specified in the RESOURCES section of the UBBCONFIG and is used by the administrator to place a maximum upper bound on the timeout value of a transaction started via tpbegin(3c) or via an AUTOTRAN service invocation.
|
|
•
|
The T_SERVERCTXT class of the TM_MIB provides multiple instances of 14 fields if multiple server dispatch threads are active simultaneously. Specifically, the T_SERVERCTXT section includes an instance of each of the following fields for each active sever dispatch thread:
|
When multiple instances of T_SERVER class fields contain multiple values for different contexts of a multicontexted server, a “dummy” value is specified in the
T_SERVER class field and the
T_SERVERCTXT field contains an actual value for each context.
|
•
|
TM_MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference
|
