|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) Part No. B14082-01 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) Part No. B14082-01 |
|
|
Previous |
Next |
Oracle Internet Directory provides a comprehensive framework for enabling you to debug, audit, and monitor the directory. This chapter contains these topics:
This section contains these topics:
Oracle Internet Directory enables you to:
View logging information for the directory server, the directory replication server, and the directory integration server
Set the logging level
Specify one or more operations for which you want logging to occur
Search messages in a standard format to determine remedial action for fatal and serious errors
View trace messages according to their severity and order of importance
Diagnose Oracle Internet Directory components by examining trace messages with relevant information about, for example, entry DN, ACP evaluation, and the context of an operation
This section discusses log messages—those associated with specified LDAP operations and those not. It provides an example of a trace log and explains how to interpret it.
Log messages for a specified operation are stored as a trace object. This object tracks the operation from start to finish across the various Oracle Internet Directory modules. It is entered in the log file when one of the following occur:
An LDAP operation completes
A high priority message is logged
The trace messages buffer is full
Each thread has one contiguous block of information for each operation, and that block is clearly delimited. This makes it easy, in a shared server environment, to follow the messages of different threads, operations, and connections.
If, because of an internal message buffer overflow, a single trace object cannot contain all the information about an operation, then the information is distributed among multiple trace objects. Each distributed piece of information is clearly delimited and has a common header. To track the progress of the operation, you follow the trace objects and their common header to the end, which is marked with the trace message "Operation Complete".
Messages not associated with any LDAP operation are represented in a simple format, which is not object-based. It is entered in the log file when either the operation completes or a high priority message is encountered.
2003/01/28:13:44:27 * Main:1 * Starting up the OiD Server, on node dthakuri-sun 2003/01/28:13:44:27 * Main:1 * Oid Server Connected to DB store via inst1 connect string. 2003/01/28:13:44:27 * Main:1 * OiD LDAP server started. 2003/01/28:13:44:31 * ServerController:1 * INFO * slsfctSpawnDispatcher * Entry 2003/01/28:13:44:31 * ServerController:1 * INFO * gslsfctSpawnDispatcher * Spawned server dispatcher thread successfully. Thread id : 1 2003/01/28:13:44:31 * ServerController:1 * INFO * gslsfctSpawnDispatcher * Exit 2003/01/28:13:44:31 * ServerWorker:6 * INFO : ServerWorker : Entry 2003/01/28:13:44:31 * ServerWorker:6 * INFO : gslsfccRegisterThread : Entry 2003/01/28:13:44:31 * ServerWorker:6 * INFO : gslsfccRegisterThread : Exit 2003/01/28:13:44:31 * ServerWorker:6 * INFO * gslfsfAStr2Filter * Filter="(|(objectclass=referral))" 2003/01/28:13:44:31 * ServerWorker:6 * INFO * gslfsfAStr2Filter * Filter="(objectclass=referral)" 2003/01/28:13:44:31 * ServerWorker:6 * INFO * gslfsfCStr2Simple * Filter="objectclass=referral" 2003/01/28:13:44:31 * ServerWorker:6 * INFO * gslsbnrNormalizeString() String to Normalize: "objectclass" 2003/01/28:13:44:31 * ServerWorker:6 * INFO * gslsbnrNormalizeString() Normalized value: "objectclass" BEGIN 2003/01/28:13:45:49 * ServerWorker:6 * ConnID:0 * OpId:0 * OpName:bind 13:45:49 * INFO * gslfbiADoBind * Entry 13:45:49 * INFO * gslfbiGetControlInfo * Entry 13:45:49 * INFO * gslfbiGetControlInfo * Exit 13:45:49 * INFO * gslfbiADoBind * connID=0 opID=0 Version=3 BIND dn="" method=128 13:45:49 * INFO * gslfrsBSendLdapResult * Entry 13:45:49 * INFO * gslfrsASendLdapResult2 * Entry 13:45:49 * INFO * sgslunwWrite * Entry 13:45:49 * INFO * sgslunwWrite * Exit 13:45:49 * INFO * gslfrsASendLdapResult2 * Exit 13:45:49 * INFO * gslfrsBSendLdapResult * Exit 13:45:49 * INFO * gslfbiADoBind * Exit 13:45:49 * INFO * Total Bind operation time for dn=2588 micro sec and Total Worker time=3434 micro sec END 2003/01/28:13:45:49 * ServerWorker:6 * INFO * ServerWorker * Operation Complete 2003/01/28:13:44:31 * ServerWorker:7 * INFO * ServerWorker : Entry 2003/01/28:13:44:31 * ServerWorker:7 * INFO * gslsfccRegisterThread : Entry 2003/01/28:13:44:31 * ServerWorker:7 * INFO * gslsfccRegisterThread : Exit BEGIN 2003/01/28:13:48:53 * ServerWorker:13 * ConnID:0 * OpId:0 * OpName:bind 13:48:14 * INFO * gslfbiADoBind * Entry 13:48:53 * INFO * gslfbiGetControlInfo * Entry 13:48:53 * INFO * gslfbiGetControlInfo * Exit 13:48:53 * INFO * gslfbiADoBind * conn=0 op=0 Version=3 BIND dn="cn=proxy" method=128 13:48:53 * INFO * gslsbbBind * Entry 13:48:53 * INFO * gslsbnrNormalizeString * String to Normalize: "proxy" 13:48:53 * INFO * gslsbnrNormalizeString * Normalized value: "proxy" 13:48:53 * INFO * gslfrsBSendLdapResult * Entry 13:48:53 * INFO * gslfrsASendLdapResult2 * Entry 13:48:53 * INFO * sgslunwWrite * Entry 13:48:53 * INFO * sgslunwWrite * Exit 13:48:53 * INFO * gslfrsASendLdapResult2 * Exit 13:48:53 * INFO * gslfrsBSendLdapResult * Exit 13:48:53 * INFO * gslsbbBind * Exit 13:48:53 * INFO * gslfbiADoBind:Exit 13:48:53 * INFO * Total Bind operation time for dn = cn=proxy is 3710 micro sec Total Worker time = 4767 micro sec END 2003/01/28:13:48:53 * ServerWorker:13 * INFO * ServerWorker * Operation Complete 2003/01/28:14:05:56 * ServerWorker:6 * FATAL * ServerWorker * Processing shutdown notification 2003/01/28:14:05:56 * ServerWorker:6 * WARNING * ServerWorker * Shutting down worker ID : 6
As shown in the sample messages in the previous section, log information can be associated with either a thread that performs an operation or one that does not. In the case of a thread that performs an operation, the header of the log contains:
Date and time
Thread name and identifier for the particular connection
Connection identifier
The name and identifier of the associated operation
A thread that does not perform an operation logs normal trace messages. Its header contains the date, time, and the thread identifier. It does not contain connection and operation-related information.
A trace object starts with the keyword BEGIN and ends with the keyword END.
Table 10-1 describes each field in a trace message.
Table 10-1 Fields in Trace Messages
| Field 1 | Field 2 | Field 3 | Field 4 | Field 5 | Field 6 |
|---|---|---|---|---|---|
| For messages not based on objects: Date and time
For messages based on objects: Time only |
For non-object-based trace messages only, the thread identifier | Trace message criticality. This has four possible values:
|
Function name | Information about the operation performed. This information can be used to diagnose problems. | Error code, if available. The error code could be for the operating system, the Oracle database, or LDAP. |
You can set debug logging levels by using either Oracle Directory Manager or the OID Control Utility.
To set the debug logging level:
In the Navigator pane, expand Oracle Internet Directory Servers and select a server instance. The group of tab pages for that server appear in the right pane.
Select the Debug Flags tab.
Select Debug Flags.
To generate a log for a specific problem, specify the debug logging level on this tab page. Otherwise, you can leave the check boxes on this tab page deselected.
To set debug logging levels by using the OID Control Utility, restart the Oracle directory server using the -debug flag for an LDAP server, and the -d flag for the replication server. Use the debug level number based on Table 10-2.
Because debug levels are additive, you need to add the numbers representing the functions that you want to activate, and use the sum of those in the command-line option.
By default, debug logging is turned off. To turn it on, modify the directory-specific entry (DSE) attribute orcldebugflag to the level you want. You can configure debug levels to one of the following levels.
To see debug log files generated by the OID Control Utility, navigate to $ORACLE_HOME/ldap/log.
Table 10-2 provides the complete list of debug logging levels.
Table 10-2 Debug Logging Levels
| Logging Level Value | Provides Information Regarding |
|---|---|
| 1 | Heavy trace debugging |
| 128 | Debug packet handling |
| 256 | Connection management, related to network activities |
| 512 | Search filter processing |
| 1024 | Entry parsing |
| 2048 | Configuration file processing |
| 8192 | Access control list processing |
| 491520 | Log of communication with the back end - that is with the database |
| 524288 | Schema related operations |
| 4194304 | Replication specific operations |
| 8388608 | Log of entries, operations and results for each connection |
| 16777216 | Trace function call arguments |
| 67108864 | Number and identity of clients connected to this server |
| 117440511 | All possible operations/data |
For example, to trace search filter processing (512) and active connection management (256), enter 768 as the debug level (512 + 256 = 768) as follows:
oidctl server=oidldapd instance=1 flags='-debug 768' restart oidctl server=oidrepld instance=1 flags='-h my_host -p 389 -d 768' restart
This example restarts both the Oracle directory server as well as the Oracle directory replication server with the debugging flags.
To make logging more focused, use the debug dimensions in conjunction with the debug levels. For example, to limit logging to particular directory server operations, specify the debug dimension to those operations.
Table 10-3 shows these dimensions.
Table 10-3 Debug Dimension Values for LDAP Operations
| Operation Debug Dimension Value | Provides Information Regarding |
|---|---|
| 1 | ldapbind |
| 2 | ldapunbind |
| 4 | ldapadd |
| 8 | ldapdelete |
| 16 | ldapmodify |
| 32 | ldapmodrdn |
| 64 | ldapcompare |
| 128 | ldapsearch |
| 256 | ldapabandon |
| 511 | All LDAP operations |
You can set the debug operation dimension by using either Oracle Directory Manager or ldapmodify.
To set the operation debug dimension:
In the navigator pane, expand Oracle Internet Directory Servers and select a server instance. The group of tab pages for that server appear in the right pane.
Select the Debug Flags tab.
Select Debug Operation Flag.
By default, all operations are selected. To generate a log for a specific operation, select the corresponding operation. You can select more than one operation.
To log more than one operation, add the values of their dimensions. For example, if you want to trace ldapbind (1), ldapadd (4) and ldapmodify (16) operations, then create an LDIF file setting the orcldebugop attribute to 21 (1 + 4 + 16 = 21). The LDIF file is as follows:
dn: changetype:modify replace:orcldebugop orcldebugop:21
To load this file, enter:
ldapmodify -h host_name -p port_number -f file_name
To minimize the performance overhead in I/O operations, debug messages are flushed to the log file periodically instead of every time a message is logged by the directory server. Writing to the log file is performed when one of the following occur:
An LDAP operation completes
A high priority message is logged
The trace messages buffer is full
You can, however, view the trace messages in the log file as they are logged without having to wait for the periodic flush. To do this, set the DSA configuration attribute orcldebugforceflush to 1. Do this by using ldapmodify as shown in the following example.
Example 10-1 Enabling Force Flushing
To enable force flushing by using ldapmodify:
Create an LDIF file as follows:
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory changetype: modify replace: orcldebugforceflush orcldebugforceflush: 1
Load this file by entering the following:
ldapmodify -h host_name -p port_number -f file_name
|
Note:
|
The audit log records critical events on the Oracle directory server that are important from both a security and an operational point of view. Because the log generation depends on events on the directory server, you cannot create audit log entries. Only the directory server itself can create them.
The audit log is made up of regular directory entries, one entry for each event. You can query the audit log by using ldapsearch, and you can view the audit log entries by using Oracle Directory Manager.
By default, audit logging is disabled. To enable it, modify the directory-specific entry (DSE) attribute orclauditlevel to the level you want. You can configure audit levels to audit only selected events.
This section contains these topics:
|
See Also:
|
Each audit log entry contains the orclAuditoc object class. Like all other structural object classes, orclAuditoc inherits from top. Table 10-4 lists and describes the attributes of the orclAuditoc object class.
Table 10-4 Attributes of the orclAuditoc Object Class
| Attribute | Description |
|---|---|
orclsequence
|
Used to create the name of the entry. The name is generated using a database sequence. |
orcleventtype
|
Specifies the type of event that occurred. This is a cataloged attribute. |
orcleventtime
|
Specifies the time at which the event occurred. This is formatted in UTC (Coordinated Universal Time). UTC is indicated by a z at the end of the value. For example, orcleventtime: 199811281010z
|
orcluserdn
|
Specifies the identity of the user who logged into the Oracle directory server to perform the operation. This attribute is cataloged. |
orclopresult
|
Specifies the outcome of the operation. It states either SUCCESS if the operation succeeds, or the reason why the operation failed. |
orclauditmessage
|
Specifies the textual message. This attribute is not cataloged. |
objectclass
|
Contains the preset values top and orclauditoc.
|
Note that the audit log entries do not become part of a regular search result set even though the search filter can satisfy the query criteria. For example, a search with the condition objectclass=top does not yield results from the auditlog entries. Only a search with cn=auditlog as the base of the search can find audit log entries.
|
Note: By default, the attributesorcleventtype and orcluserdn are indexed at installation of Oracle Internet Directory. If you drop the indexes from these attributes, you cannot search for them. To re-create the index for these attributes, use the Catalog Management tool. See "Indexing an Attribute by Using Oracle Directory Manager".
|
|
See Also:
|
The audit log container is part of the DSE. As shown in Figure 10-1, it holds its entries as children organized according to the orclsequence attribute.
Table 10-5 shows the auditable events and their audit levels. The third column, Audit Levels, contains hexidecimal values. You can audit more than one event by adding their corresponding values found in this column.
Table 10-5 Auditable Events
| Event | Description | Audit Levels |
|---|---|---|
| Super user login | Super user bind to the server (successes or failures) | 0x0001 |
| Schema element add/replace | Addition of a new schema element (successes or failures) | 0x0002 |
| Schema element delete | Deletion of a schema (successes or failures) | 0x0004 |
| Bind | Unsuccessful bind cases | 0x0008 |
| Access violation | Access denied by access control policy point | 0x0010 |
| directory-specific entry (DSE) modification | Changes to a DSE (successes or failures) | 0x0020 |
| Replication login | Replication server authentication (successes or failures) | 0x0040 |
| ACL modification | Changes to an access control list (ACL) | 0x0080 |
| User password modification | Modification of user password attribute | 0x0100 |
| Add | ldapadd operation (successes or failures) | 0x0200 |
| Delete | ldapdelete operation (successes or failures) | 0x0400 |
| Modify | ldapmodify operation (successes or failures) | 0x0800 |
| ModifyDN | ldapModifyDN operation (successes or failures) | 0x1000 |
| bind | Successful user bind cases | 0x2000 |
The setting for the DSE attribute orclauditlevel indicates the current audit level. You can enable or disable the events described in the previous section. A value of 0 for this attribute, which is the default, disables auditing.
You can set the audit level by using either Oracle Directory Manager or ldapmodify. This section describes both methods.
To set the audit level by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers and select the directory server instance.
In the right pane, select the Audit Mask Levels tab page. This tab page lists the auditable events described in Table 10-6.
Table 10-6 Audit Mask Levels
| Audit Level | Description |
|---|---|
| Super user login | Super user bind to the server (successes or failures) |
| Schema element add/replace | Addition of a new schema element (successes or failures) |
| Schema element delete | Deletion of a schema (successes or failures) |
| Bind | Unsuccessful bind cases |
| Access violation | Access denied by ACP |
| DSE modification | Changes to DSE entry (successes or failures) |
| Replication login | Replication server authentication (successes or failures) |
| ACL modification | Changes to ACPs |
| User password modification | Modification of user password attribute |
| Add | ldapadd operation (successes or failures) |
| Delete | ldapdelete operation (successes or failures) |
| Modify | ldapmodify operation (successes or failures) |
| ModifyDN | ldapModifyDN operation (successes or failures) |
Select the audit level you want to use.
Both successful and unsuccessful events are entered into the audit log if they are selected, except:
Bind, which logs only unsuccessful bind attempts
Access Violation, which logs only events in which access is denied by an ACP
Choose Apply.
Restart the directory server instance for the changes to take effect.
|
See Also: "Restarting Oracle Internet Directory Server Instances by Using the OID Control Utility" for instructions on how to restart the directory server |
To audit more than one event, add the values of their audit masks. For example, suppose you want to audit the events in Table 10-7.
Table 10-7 Example: Setting the Audit Level
| Event | Audit Level | Value |
|---|---|---|
| Schema element delete | 0x0004 | 4 |
| DSE modification | 0x0020 | 32 |
| Add | 0x0200 | 512 |
The total value of the audit levels is 548. The ldapmodify command would therefore look something like this:
ldapmodify -p port -h host << EOF dn: changetype:modify replace: orclauditlevel orclauditlevel: 548 EOF
Restart the directory server instance after any changes are made to orclauditlevel for the changes to take effect.
|
See Also: "Restarting Oracle Internet Directory Server Instances by Using the OID Control Utility" for instructions on how to restart the directory server |
You can search for audit log entries by using either Oracle Directory Manager or ldapsearch.
To use Oracle Directory Manager to view audit log entries:
In the navigator pane, expand Oracle Internet Directory Servers and directory server instance.
Select Audit Log Management. The corresponding right pane appears.
In the Max Results (entries) field, type the maximum number of entries you want your search to retrieve. The default is 200. The directory server retrieves the number you specify, up to 1000.
In the Max Search Time (seconds) box, type the maximum number of seconds for the duration of your search. The value you enter here must be at least that of the default, namely, 25. The directory server searches for the amount of time you specify, up to one hour.
In the Search Criteria box, use the lists and text fields on the search criteria bar to focus your search.
From the list at the left end of the search criteria bar, select an attribute of the entry you want to search for. Because not all attributes are used in every entry, be sure that the attribute you specify actually corresponds to one in the entry that you are searching for. Otherwise, the search fails.
From the list in the middle of the search criteria bar, select a filter. These are described in Table C-39.
In the text box at the right end of the search criteria bar, type the value for the attribute you just selected. For example, if the attribute you selected was cn, you could type the particular common name you want to find.
To further refine your search, use the buttons in the Search Criteria box to enhance the search criteria bar. These are described in Table C-40.
Choose Search. The results of your search appear in the Distinguished Name box.
To view the properties of a particular audit log entry, select it in the Distinguished Name box, then choose to exploit the features of Oracle Internet Directory Server Manageability. The Audit Log Entry dialog box displays the properties for the audit log entry you selected.
|
See Also: "Configuring the Display and Duration of Searches in Oracle Directory Manager" for instructions on setting the number of entries to display in searches, and to set the time limit for searches |
The DN for the audit log container is cn=auditlog. To search for audit log entries, perform a subtree or one-level search, with the container object cn=auditlog as the base of the search.
Oracle Internet Directory Server Manageability enables you to monitor various types of information about Oracle Internet Directory servers. This section contains these topics:
Capabilities of Oracle Internet Directory Server Manageability
Oracle Internet Directory Server Manageability Architecture and Components
Location of Configuration Information for Oracle Internet Directory Server Manageability
The Oracle Internet Directory Server Manageability framework enables you to monitor the following directory server statistics:
Server health statistics about LDAP request queues, memory, LDAP sessions, and database sessions. For example, you can view the number of active database sessions over a period of time.
General statistics about specific server operations—for example, add, modify, or delete operations. For example, you can view the number of directory server operations over a period of time.
User statistics comprising successful and failed bind and compare operations to the directory and the user performing each one
Critical events related to system resources and security—for example, occasions when a user provided the wrong password or had inadequate access rights to perform an operation
Status information of the directory server and the directory replication server—for example, the date and time at which the directory replication server was invoked
Status information of Oracle directory integration and provisioning server and the integration profiles—for example, the number of times that the directory integration server failed, or whether an integration profile is enabled
|
See Also: The chapter on Oracle Directory Integration and Provisioning concepts and components in Oracle Identity Management Integration Guide |
You can view monitored information by using the Oracle Enterprise Manager 10g Application Server Control Console.
|
See Also:
|
The relationship between the various components of directory server manageability is explained in Figure 10-2 and the accompanying text in Table 10-8.
Table 10-8 Components of Oracle Internet Directory Server Manageability
| Component | Description |
|---|---|
| Oracle Internet Directory
|
A directory server responds to directory requests from clients. It has four kinds of functional threads: controller, worker, dispatcher, and listener. It accepts LDAP requests from clients, processes them, and sends the LDAP response back to the clients.
When you use the Oracle Internet Directory Server Manageability framework to set runtime monitoring, the four functional threads of the server record the specified information and store it in local memory. See Also: "An Oracle Directory Server Instance" for a description of the directory server |
| Memory Resident Storage | This is a local process memory. The Oracle Internet DirectoryServer Manageability framework assigns one each for statistics, tracing, and auditing. Each has its own separate data structure maintained in the local memory storage. |
| Low Priority Write Threads | These dedicated write threads differ from server functional threads in that they write server statistics, audit logging, and tracing information to the repository. To maintain reduced system overhead, their priorities are kept low. |
| External Monitoring Application | This module, which is proprietary and external to the server manageability framework, collects the gathered statistics through a standard LDAP interface with the directory server and stores it in its own repository. |
| External Repository for Server Management Information | This is the repository that the monitoring agent uses to store the gathered directory server statistics. The monitoring agent determines how this repository is implemented. |
| Oracle Enterprise Manager 10g Application Server Control Console
|
The Application Server Control Console extracts monitored data from the statistics and events repository, presenting it in a Web-based graphical user interface. Users can view the data in a normal browser. A repository can store the collected data for generic and custom queries. |
| Logging Repository (File System) | This repository uses a file system to store information traced across various modules of the directory server. By using a file system for this purpose, the Oracle Internet Directory Server Manageability framework uses the features and security of the operating system. |
| Directory Data Repository | This repository contains all user-entered data—for example, user and group entries. |
| Statistics and Events Repository | This repository is like the tracing repository except that it stores the information in the same database as the directory data repository rather than in a file system. In this way, the Oracle Internet Directory Server Manageability framework uses:
The directory manageability framework isolates the gathered information from the directory data by storing the two separately. |
The Oracle Internet Directory Server Manageability framework stores configuration parameters for all three modules—namely, server statistics, server tracing, and server auditing—in the DSE root of the directory. To specify periodicity, amount, and level of information to be gathered, you must set appropriate values for these parameters.
To configure the Oracle Internet Directory Server Manageability framework, you use ldapmodify to set positive integer values for various attributes in the root DSE.
To enable health and general statistics, set the orclStatsFlag and orclStatsPeriodicity attributes.
To enable user statistics:
Set the orclstatslevel attribute to 1
Set the orclStatsPeriodicity attribute
To enable critical events, set the OrclEventLevel attribute.
To enable events other than super user, proxy user, and replication administrator login:
Set the OrclEventLevel attribute to the appropriate value
Set the orclStatsFlag to 1
|
See Also: "Attributes for Oracle Internet Directory Server Manageability" for information about each of the attributes you set when using Oracle Internet Directory Server Manageability |
For example, to enable the Oracle Internet Directory Server Manageability framework, you create an LDIF file that looks like this:
dn: changetype: modify replace: orclstatsflag orclstatsflag:1
To upload this file, enter the following command:
ldapmodify -h host -p port_number -D bind_DN -w bind_DN_password -f file_name
where the bind DN authorized to perform server manageability configuration is cn=emd admin,cn=oracle internet directory.
|
See Also: Online help for Oracle Enterprise Manager 10g Application Server Control Console for more information about monitoring and managing Oracle Internet Directory servers by using Oracle Internet Directory Server Manageability |
To configure critical events, use ldapmodify to set the OrclEventLevel attribute to one or more of the event levels listed in Table 10-9.
Table 10-9 Critical Event Levels
| Level Value | Critical Event | Information It Provides |
|---|---|---|
| 1 | Super user login | Super uses bind (successes or failures) |
| 2 | Proxy user login | Proxy user bind (failures) |
| 4 | Replication login | Replication bind (failures) |
| 8 | Add access | Add access violation |
| 16 | Delete access | Delete access violation |
| 32 | Write access | Write access violation |
| 64 | ORA 3113 error | ORA-3113 Error |
| 128 | ORA 3114 error | ORA-3114 Error |
| 255 | All critical events |
|
To exploit the features of Oracle Internet Directory Server Manageability, you use Oracle Enterprise Manager 10g Application Server Control Console as explained in this section.
|
See Also: For information about stopping and starting Oracle Enterprise Manager 10g Application Server Control Console, see Oracle Application Server Administrator's Guide. |
To enable information collection by using Oracle Enterprise Manager 10g Application Server Control Console:
In the Oracle Internet Directory main window, select LDAP Metrics. This displays the LDAP Diagnostic Collection Configuration page.
Check Collect Metrics.
Select Interval.
Enter the required password.
Choose Apply.
|
Note: To enable critical events, use ldapmodify to set the attributeorclEventLevel to the appropriate value.
|
To start a server:
In the Oracle Internet Directory main window, choose Start New Instance. The Start a New LDAP Server Instance Window displays the fields in Table 10-10.
Table 10-10 Fields in the Start a New LDAP Server Instance Window of the Application Server Control Console
| Column | Description |
|---|---|
| Set Number | The configuration set number for the directory server instance |
| Default Port | The default port number for the directory server instance |
| Port Available | Indicator of whether the default port is available |
| Maximum Database Connections | The number of database connections this directory instance can accommodate |
| Server Processes | The number of server processes |
| Port Number | The port number you assign to the directory server instance if the default port number is not used |
In the Set Number column, select the configuration set you want to use.
If the default port is not available, then, in the Port Number column, specify a port number.
Choose Start.
To stop a directory server instance:
In the Oracle Internet Directory main window, in the LDAP Instances section, select the directory server instance you want to stop.
Choose Stop.
To restart a directory server instance:
In the Oracle Internet Directory main window, in the LDAP Instances section, select the server you want to restart.
Choose Restart. The Restart an LDAP Server Instance window displays the fields listed in Table 10-11.
Table 10-11 Fields in the Restart an LDAP Server Instance Window of the Application Server Control Console
| Column | Description |
|---|---|
| Set Number | The configuration set number for the directory server instance |
| Default Port | The default port number for the directory server instance |
| Port Available | Indicator of whether the default port is available |
| Maximum Database Connections | The number of database connections this directory instance can accommodate |
| Server Processes | The number of server processes |
| Port Number | The port number you assign to the directory server instance if the default port number is not used |
Select a configuration. If the default port is not available, then, in the Port Number column, enter a port number.
Choose Start.
To view directory server activities information:
In the Directory Server main window, select the directory server instance whose information you want to view.
Choose View Load. The LDAP Load window appears.
From the Select Load Characteristics list, select the information that you want to view about this instance. The options are:
LDAP Repository Database Sessions—Selecting this option displays two graphs—one for open database sessions, the other for active database sessions at the end of the specified time period of statistics collection.
Response Time vs. LDAP Operations—Selecting this option displays two graphs. The first shows the average LDAP operation response time over the course of the specified time period of statistics collection. The other shows the number of operations in progress at the end of that period
Active LDAP Sessions vs. New LDAP Sessions—Selecting this option displays two graphs. The first shows the number of active LDAP sessions—that is, those that remain open at the end of the specified time period of statistics collection. The second shows new LDAP sessions—that is, those that are opened over the course of the specified time period of statistics collection.
When you have made your selection, choose Go.
You can view directory server operations over the course of the specified time period of statistics collection by using Application Server Control Console. To do this:
In the Directory Server main window, select the directory server instance whose information you want to view.
Choose View Operations. This displays charts for all of the LDAP operations. Click any chart to see a larger image of it.
