Oracle Communications MetaSolv Solution (MSS) provides several means of monitoring and maintaining the product at its intended capacity. For instance, regularly monitoring log files can assure continued high performance. Other normal maintenance tasks are required when changes or problems occur. This chapter provides detailed instructions about the following:
Starting and stopping the MetaSolv Solution application server
Managing the MetaSolv Solution log files
Monitoring the client logons
Managing the Oracle WebLogic server
Resetting the server-to-database connections
When tuning the Oracle WebLogic server, refer to "Oracle WebLogic Server Configuration Settings" for suggested settings.
When changing hardware, refer to the MetaSolv Solution Planning Guide for recommendations.
The MetaSolv Solution database and servers should always be up and running, ready for access by clients. Shutdown should occur only during normal system maintenance.
Components must be started in the following order:
Database
Application server
MetaSolv Solution client
After the database is up and running, use the MetaSolv Solution start script to start the Oracle WebLogic server. The script sets values for arguments and provides the settings required to make the Oracle WebLogic server start successfully.
The start scripts are located in the domain directory. The script name includes the server name. For example, if a server is named MSLV01, it will have a start script named startMSLV01.sh in the domain directory.
Note:
If you change the HTTP port for the server process (using the Oracle WebLogic domain wizard) without reinstalling MSS, you must also change it in the start script for the server process.To start MetaSolv Solution with a script:
MetaSolv Solution provides scripts to start a server. Use the following command depending on which type of machine you are using:
For UNIX/Linux:
./startMSLVServer.sh <server_name><host_admin_URL>
For Windows:
startMSLVServer.cmd <server_name><host_admin_URL>.
Use the following as the admin URL argument:
http://host_name:admin_port
Use the following as the admin URL argument when using SSL port:
https://host_name:admin_sslport
Note:
To start or stop the administration server and managed servers (in a cluster environment) using the SSL port, you must add an s after http in the ADMIN_URL argument in the startup/stop server scripts for the administration server and for each managed server. For example:
https://host_name:admin_sslport
If running in a cluster environment:
After managed servers are started, the Admin server can be shut down to release resources that the process would otherwise consume. However, the Admin server must be running to allow access to the Administration Console or to perform any administrative function.
To stop MetaSolv Solution on a Windows server, choose one of these options:
Close the application on the server by clicking the X box.
Use the Management console to stop a server: Right-click the server name in the left column and select Start/stop this server, then click Shutdown.
To stop MetaSolv Solution on a UNIX server, follow these steps:
Issue a ps command to show all the processes containing a java string in the description.
Issue a kill command to stop the selected process.
Memory amounts specified, when server process are started, identify servers. For example, to stop a managed server process, you might look for a process with java and Xms512m because the Xms512m identifies the managed server process. The admin server uses Xms32m instead of Xms512m.
To stop MetaSolv Solution with a script:
MetaSolv Solution provides scripts to shut down a server. Use the following command depending on which type of machine you are using:
For UNIX/Linux:
./stopMSLVServer.sh <server_name><host_admin_URL>
For Windows:
stopMSLVServer.cmd <server_name><host_admin_URL>.
Use the following as the admin URL argument:
http://host_name:admin_port
Use the following as the admin URL argument when using SSL port:
https://host_name:admin_sslport
The Oracle Administration Console is an administrative tool for managing resources, including such tasks as starting and stopping servers, balancing the load on servers or connection pools, tuning and monitoring the configuration of resources, detecting and correcting problems, monitoring and evaluating system performance, and making sure the application is correctly deployed to the target servers or to a cluster.
See the WebLogic Server documentation for more information.
See "Delivering File Changes" for specific configuration and tuning recommendations for MetaSolv Solution and the WebLogic Server. You can access the Oracle WebLogic server using a Web browser at:
https://host:port/console
Where:
Host is the name of the administration server machine.
Port is the administration server port number.
Note:
Oracle recommends that you access the WebLogic Server using Hypertext Transfer Protocol Secure (HTTPS).Or you can use the MetaSolv Solution Runtime page link to the WebLogic Administration Console. This link appears on the Runtime Page drop-down. "Getting Oracle WebLogic Server Runtime Information" for details about the Runtime page.
The Administration Console manages the following WebLogic Server tasks:
Configuring the server
Tuning the Oracle WebLogic server
Debugging and monitoring
Deployments
Managing WebLogic logs
Monitoring Oracle WebLogic server performance
Executing queues
Managing database connections
Managing Oracle WebLogic security
Follow directions in the Oracle documentation to perform specific WebLogic tasks. Follow instructions in the MetaSolv Solution Installation Guide regarding basic Oracle WebLogic settings before making changes.
The Administration Console is a web application that uses Java server Pages (JSPs) to access the management resources.
After starting the Administration server, you can start the Administration Console by using the following procedure.
To start the Administration Console:
From your browser, type the following URL:
http://host_name:port/console
The value of host_name is the DNS name or IP address of the Administration server. The value of port is the address of the port on which the Administration server is listening for requests.
When started, the Administration Console prompts for a password. The first time the Administration Console is started, you can use the user name and password under which the Administration server was started. The Administration Console appears.
Note:
The Administration server must be running before you can use the Administration Console.Among the key tasks you will perform using the Administration Console are:
Managing WebLogic logs
Executing queues
Managing database connections
Monitoring the Oracle WebLogic server through the Runtime page
Caution:
See "Delivering File Changes" before making any changes to the number of threads.The MetaSolv Solution Runtime page provides detailed Oracle WebLogic server information. It also provides links to important administrative tools that provide specialized information. See MetaSolv Solution Installation Guide for instructions on accessing the ZAC Start page links.
To use the Runtime Page:
Display the Start page by entering the following in your browser address field:
http://host_name:port/main
Note:
If you start the Administration server using Secure Socket Layer (SSL), you must add an s after http. For example:
https://host_name:port/main
Click on Runtime Information.
The MetaSolv Solution Appserver Runtime page provides a detailed snapshot of an Oracle WebLogic server, providing details about the following:
Client Information
Enterprise Archive (ear) Version
Server Information
WebLogic Server instance
URL
Stored Procedures with Invalid Version (if any)
JAR file information
Classpath JARs
Java System Properties
You can also use the Runtime page drop-down to:
Link to the Administration Console
View MetaSolv Solution log files
Reset connection pools
You can view a runtime page for each server in your MetaSolv Solution configuration. The information in each report should be the same. If it is not, the Oracle WebLogic server in your MetaSolv Solution system are out of sync and you may need to re-install the product.
MetaSolv Solution provides three consolidated log files for all modules. When system or user errors occur, you can review a file and discover the source of the problem.
Table 4-1 describes the log files.
| File name | Purpose |
|---|---|
|
appsrverlog.xml |
System-wide log file. |
|
appserverlog_misc.xml |
Miscellaneous catch-all log file. This file traces any activity not specified for |
|
appserver_auditlog.xml |
This file contains the records of log on and log off activities, and includes successful and failed client logon attempts. Each attempt to log on is recorded, whether it is successful or not. Since, the audit log file contains the logon and logoff information only, a large archive can be maintained for longer periods of time than when using appsrverlog.xml. The appserver_auditlog.xml configuration is independently controlled from the main log file's configuration (using the AuditFileApp element of loggingconfig.xml). |
You can use the Log Viewer for reviewing MetaSolv Solution log files created for the Oracle WebLogic server. (WebLogic Server log files are accessed through the WebLogic console.) The Log Viewer lets you find the kind of information you want quickly without manually searching through pages of log files. For example, you can use the filter to view error messages only.
To use the Log Viewer, JAVA 1.6_05 must be installed and you must be working on either a Windows or a UNIX workstation.
To open the Log Viewer:
Navigate to the following directory:
MetaSolv_home/server_name/appserver/bin
Start logviewer.
For Windows, double-click logviewer.cmd.
For UNIX, double-click logviewer.sh.
For UNIX users, please note that the following information is excerpted from the discussion on installing on UNIX platform in the MetaSolv Solution Installation Guide.
The following list contains special tasks required for graphics on a UNIX machine:
To execute the installation using a graphical user interface:
On a workstation, start Hummingbird Exceed or another X-Windows emulator.
On the UNIX machine, set the DISPLAY environment variable to send the graphical display to the workstation.
$DISPLAY=mymachinename:0.0;export DISPLAY
Enable xhost for Oracle WebLogic server that run on a UNIX machine.
To enable the lookup of graphic settings on the Oracle WebLogic server, you must enable xhost on the machine. Run the following command on the Oracle WebLogic server machine while logged on as root:
xhost +
As you work:
Leave the command window open.
Select the logviewer.cmd for Windows or logviewer.sh for UNIX/Linux to see a Log Viewer.
Choose a log file from the File menu.
Select a message severity level in the Level drop-down.
The display will include a list of events that occurred at the level selected and at all higher levels.
If you check the Exclusive Levels check box, only events at the level selected will display.
To make your search more specific:
Enter criteria in the fields at the top of the window.
For detailed information about any event, select it and view the details in the lower part of the window.
The Exit, Clear, Pause, and Refresh buttons control the Log Viewer. The Next, Previous, First/Newest and Last/Oldest buttons let you change the log file you are viewing from the current log file to one of the ten previous archived log files.
Table 4-2 describes each field of the appsrverlog.xml and appsrverlog_misc.xml log files.
Table 4-2 MetaSolv Solution Log File Fields
| Field | Description |
|---|---|
|
appServerName |
Application server where the event occurred. |
|
className |
Name of the JAVA class logging the message. This is typically where the problem occurred. If a developer has not specified this field, it appears as an indeterminate "DEF_CLASS." Provide this information if working with Oracle Global Customer Support. |
|
debugCode |
A message may simply contain a zero or an arbitrary number for this debug code. |
|
Events |
Occurrences of log messages that meet the criteria specified. |
|
Level |
Severity of the event. Severity levels are: Alert, Fatal, Error, Warning, Performance, Info, and Debug. (Performance is not currently in use.) |
|
machineName |
Identifies the hardware. |
|
Message |
Information provided about the event. |
|
messageID |
A unique ID for the message that may be useful if working with Oracle Global Customer Support. |
|
moduleName |
Specifies the product module in which the event occurred, such as PSR, Security, etc. Audit file logs occur only with the Security module. |
|
productName |
MetaSolv Solution. |
|
thread |
Debugging aid for internal development. |
|
Time |
Time the event occurred. |
|
userName |
Identifies the user associated with the event. |
When a MetaSolv Solution log file reaches the maximum size specified in Loggingconfig.xml, it is automatically archived. The default size is 1024 kB. The ten newest archived log files are maintained and older files are automatically deleted. As each log file is archived, the older files are renamed.
When a log file is archived, MetaSolv Solution appends a number to the file. The lowest number is the newest file. For instance, your company's three newest archived log files are named:
appsrverlog.xml.1 (Newest archive)
appsrverlog.xml.2
appsrverlog.xml.3 (Oldest archive)
The main logging directory to which log files will be written is specified in the start script startMSLVmanaged.sh or startMSLVsingle.sh in the domain directory. This value is determined by the mslv.log.dir setting specified in this script. By default this value will be set to the appserver/logs directory under each server's installation directory.
You can modify the mslv.log.dir value in the startMSLVmanaged.sh or startMSLVsingle.sh script after the installation is completed.
The new value must point to a directory, where the Oracle WebLogic server has permission to create and delete log files.
When troubleshooting, you can change settings in the logging configuration file so that more or less information is captured in the log file for any given module of the software.
To set the loggingconfig.xml parameters:
Access the loggingconfig.xml file in the Oracle WebLogic server config folder.
Make a backup copy.
Make any necessary parameter changes using any text editor.
For UNIX/Linux, a vi, emacs or /usr/dt/bin/dtpad editor may be used.
On the Windows platform, Notepad or WordPad may be used for this purpose.
Most parameters in appserverlog.xml should not be changed, and are reserved for error situations that may require assistance from Oracle Global Customer Support. However, as you encounter system or user problems in day-to-day operations, you will want to reset some parameters so you can screen for specific information.
The loggingconfig.xml file consists of several sections, listed in Table 4-3.
Table 4-3 Loggingconfig.xml Sections
| Section | Description and parameters |
|---|---|
|
Message Resourcebundles specification |
Defines the resource bundle names and their locations in the JAVA library packages. This section must never be modified unless instructed by Oracle Global Customer Support. |
|
Pluggable interface specification |
Implementation classes for the logging framework. This section must never be modified unless instructed by Oracle Global Customer Support. |
|
SQL Tracing configuration |
Captures SQL debugging messages when JDBCTrace module's debug value is also set to "on." Only one parameter can be changed:
<param name="debug" value="off"/>
|
|
Row Retrieval Specification |
Defines the number of rows that a user is allowed to retrieve and describes the threshold for the "too-many-rows" alert. The two parameters are: <param name="query-results-row-limit" value="32000"/> <param name="too-many-rows-alert-threshold" value=20000"/> |
|
Logging File specification and configuration |
Describes whether log file information is appended or written over, log file size, archiving specifications. See Table 4-4, "Logging File Editable Specifications" for information about editable parameters. |
|
Category |
Modules and components for which event levels can be set. Valid levels are fatal, error, warn, info, and debug in decreasing order of severity. See Table 4-5, "Logging Categories" for a complete list. |
The following table describes the editable logging file specifications that can be changed. Locate the listed keyword in the file and edit the parameters shown. Only the following log files can be edited:
appserverlog.xml
appserverlog_misc.xml
appserver_auditlog.xml
The last section of the Loggingconfig.xml file lets you specify the level at which you want to trace events for each category.
Table 4-4 lists the logging file editable specifications.
Table 4-4 Logging File Editable Specifications
| Keywords to search | Editable Logging File Specifications |
|---|---|
|
appender name="XMLFileApp" |
<param name="MaxFileSize" value="10000KB"/> <param name="append" value="true"/> <param name="MaxBackupIndex" value="10"/> <param name="File" value="${mslv.log.dir}/appserverlog.xml"/> |
|
<appender name="AuditFileApp" class="org.apache.log4j.RollingFileAppender"> |
<param name="append" value="true"/> <param name="MaxFileSize" value="10000KB"/> <param name="MaxBackupIndex" value="10"/><param name="File" value="${mslv.log.dir}/appserver_auditlog.xml"/> |
|
<appender name="XMLFileAppNew" class="org.apache.log4j.RollingFileAppender"> |
<param name="append" value="true"/> <param name="MaxFileSize" value="10000KB"/> <param name="MaxBackupIndex" value="10"/> <param name="File" value="${mslv.log.dir}/appserverlog_misc.xml"/> |
Table 4-5 lists the available modules for setting trace levels.
Caution:
Do not keep event severity levels at Info or Debug level during normal operations. Doing so would cause all events to be logged. Logging all events can have an adverse impact on system performance.| Category | Description or Direction |
|---|---|
|
CaCache |
Custom attributes (CAs) are characteristics end users can define generically and associate with network templates, element types, connection types, connection specifications, network systems, and allocations of connections or elements within a system. |
|
DLR |
Oracle's software supports two types of design layout reports (DLRs):
Internal DLRs have always existed for circuits designed in Oracle's software and have been referred to merely as DLRs. The external DLR process begins when a customer sends a service request to a provider requesting the use of part of their network for designing connections. The provider receives the service request and sends the customer a firm order confirmation (FOC) to verify the service request. See the Help for more information. |
|
DLR_Equipment |
When users edit equipment or equipment specifications, or move equipment with assigned connections, the design layout records (DLRs) for those connections are reconciled to reflect the change - including pending assignments. See the Help for more information. |
|
DLR_NGN_Activation |
References NGN activation. See the Help for more information. |
|
DLR_Circuit |
References DLR circuits. See the Help for more information. |
|
EventServer |
For MetaSolv Solution internal use only. Use the default settings. |
|
Event2Server |
For MetaSolv Solution internal use only. Use the default settings. |
|
Framework |
MSS internal framework code that is used/depended on extensively by the other modules. This consists of logging, security, desktop portlet related logging. |
|
Framework.Cache |
MSS internal framework code that specifically deals with database query caching. |
|
GLR |
GLR is a generic term used to refer to the Graphical Layout Record. The GLR provides information about a specific virtual connection, such as administrative information, design lines, and a graphical-view of the design. The report is generated from Connection Design. |
|
invFromPB |
For MetaSolv Solution internal use only. Use the default settings. |
|
Infrastructure |
Refers to application startup settings listed on the GUI navigation bar. |
|
Infrastructure_NetworkLocation |
Refers to Network Location settings in the GUI. |
|
INTEGRATION_CONVERSION |
For MetaSolv Solution internal use only. Use the default settings. |
|
WORK_MANAGEMENT_CONVERSION |
For MetaSolv Solution internal use only. Use the default settings. |
|
INTEGRATION_EVENT_SERVER |
For MetaSolv Solution internal use only. Use the default settings. |
|
INTEGRATION_MANAGER |
For MetaSolv Solution internal use only. Use the default settings. |
|
JDBCTrace |
The module which logs the SQL statements before they are executed for D/B bound operations. |
|
LSR |
Local Service Requests are managed by the LSR software and referenced by MetaSolv Solution. |
|
MSLVSessionBean |
This exists to log all the entry and exit messages regarding the invocations of various methods in all Stateless Session type Enterprise Java Beans in the MSS application. |
|
NetworkManagement |
For MetaSolv Solution internal use only. Use the default settings. |
|
NetProv |
For MetaSolv Solution internal use only. Use the default settings. |
|
NetProv_Plant |
For MetaSolv Solution internal use only. Use the default settings. |
|
NetProv_Activation |
For MetaSolv Solution internal use only. Use the default settings. |
|
NI |
For MetaSolv Solution internal use only. Use the default settings. |
|
PSR |
PSR provides service request tracking and provisioning functionality for products defined in the product catalog. |
|
E911 |
E911 functionality lets a user enter and maintain detailed information about a telephone number and its service location. |
|
CNAM |
Caller Name identification (CNAM) lets users view the calling name and telephone number of a caller on a caller ID display panel. |
|
LIDB |
Line Information Database (LIDB) lets users place restrictions on third-party calls. |
|
PSRAncillary |
For MetaSolv Solution internal use only. Use the default settings. |
|
PSREUB |
PSR End User Billing extracts billing information from the order to pass to an end user billing interface. |
|
Security |
For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings. |
|
SYSTEM |
MetaSolv Solution startup and shutdown and DB initialization module related logging. |
|
TEST |
For MetaSolv Solution internal use only. Use the default settings. |
|
TimedEventProcess |
For MetaSolv Solution internal use only. Use the default settings. |
|
TMS |
For MetaSolv Solution internal use only. Use the default settings. |
|
TroubleBatchWorkerThread |
For MetaSolv Solution internal use only. Use the default settings. |
|
KeepAliveTroubleBatch |
For MetaSolv Solution internal use only. Use the default settings. |
|
WDI |
For MetaSolv Solution internal use only. Use the default settings. |
|
WM |
For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings. |
|
WM_TskSv |
For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings. |
The following scenario demonstrates how to use a log file to resolve a common problem.
An incorrect database name, dNoSuch, is entered in the Session section of the Gateway.ini file. There is no such name in the Tnsnames.ora file.
When an attempt is made to start up the system, the WebLogic Server console log displays this message:
************************************* GenericStartup.init() failed. PLEASE CONSULT appserverlog.xml file in the C:\bea2\user_projects\domains \mslvhome\appserver\logs directory for detailed message! *************************************
A corresponding message appears in the appserverlog.xml file.
To determine the source of the problem, the administrator opens the appserverlog.xml file using the Log Viewer, and selects a level of Error. The administrator locates the event because the Log Viewer displays the following message:
<log4j:cause><![CDATA[Could not connect to database.]]></log4j:cause> <log4j:action><![CDATA[Could not connect to database.]]></log4j:action> <log4j:throwable><![CDATA[java.sql.SQLException: ORA-01017: invalid username/password; logon denied
The administrator must determine whether such an entry exists in the tnsnames.ora file or in the gateway.ini file.
Assuming that the gateway.ini file is incorrect, the administrator follows these steps:
Shut down the Oracle WebLogic server.
Modify the Gateway.ini entry and enter a correct database name.
Restart the Oracle WebLogic server.
Sample appserverlog.xml Log File Error Section
The appserverlog.xml log file contains the following information about this event:
<log4j:event logger="cmm.Framework" timestamp="1327054086515" level="ALERT" thread="kanlddev7110d_gateway_Main" dateTime="Fri Jan 20 02:08:06 PST 2012" appServerName="DEF_APPSERVER" machineName="tanxdev7110d" messageID="10071" moduleName="cmm.Framework" userName="User1" className="DEF_CLASS" debugCode="0" productName="nur"> <log4j:message><![CDATA[Could not connect to database - Problem using Session information in gateway.ini to access database.]]></log4j:message> <log4j:cause><![CDATA[Could not connect to database.]]></log4j:cause> <log4j:action><![CDATA[Could not connect to database.]]></log4j:action> <log4j:throwable><![CDATA[java.sql.SQLException: ORA-01017: invalid username/password; logon denied